Jalur Menuju Verifikasi

Keunggulan inti Web3 adalah verifikasi - pengguna dapat memverifikasi bagaimana sistem benar-benar beroperasi. Fitur ini menjelaskan mengapa banyak orang dalam dan luar industri kripto menggambarkan web3 sebagai langkah menuju internet yang lebih transparan dan dapat diverifikasi.

Tidak seperti platform Web2 seperti Facebook atau Instagram, di mana algoritma dan aturan tetap tidak transparan bahkan ketika didokumentasikan, protokol kripto dirancang untuk auditabilitas yang lengkap. Bahkan jika mereka dibagikan, Anda tidak memiliki kemampuan untuk memverifikasi apakah platform beroperasi sesuai yang ditentukan. Ini bertolak belakang dengan kripto, di mana setiap protokol dirancang untuk bisa diaudit sebanyak mungkin, atau setidaknya diharapkan demikian.

Hari ini, kita akan menjelajahi “The Verge”, sebuah bagian dari yang baru-baru ini diterbitkan oleh Vitalik.seri enam bagian tentang masa depan Ethereum, untuk menganalisis langkah-langkah yang diambil Ethereum menuju pencapaian verifikasi, keberlanjutan, dan skalabilitas di masa depan. Di bawah judul ‘The Verge,’ kita akan membahas bagaimana arsitektur blockchain dapat dibuat lebih diverifikasi, inovasi-inovasi yang dibawa perubahan tersebut pada tingkat protokol, dan bagaimana hal ini memberikan kepada pengguna ekosistem yang lebih aman. Mari kita mulai!

Apa yang dimaksud dengan “verifiability”?

Aplikasi Web2 berfungsi sebagai “kotak hitam” - pengguna hanya dapat melihat masukan mereka dan keluaran yang dihasilkan, tanpa visibilitas terhadap cara kerja aplikasi tersebut. Sebaliknya, protokol cryptocurrency umumnya membuat kode sumber mereka tersedia untuk umum, atau setidaknya memiliki rencana untuk melakukannya. Transparansi ini memiliki dua tujuan: ini memungkinkan pengguna berinteraksi langsung dengan kode protokol jika mereka memilih, dan membantu mereka memahami dengan tepat bagaimana sistem beroperasi dan aturan apa yang mengaturnya.

“Desentralisasikan apa yang Anda bisa, verifikasi sisanya.”

Verifiability memastikan bahwa sistem-sistem bertanggung jawab dan, dalam banyak kasus, menjamin bahwa protokol berfungsi sebagaimana yang dimaksudkan. Prinsip ini menekankan pentingnya meminimalkan sentralisasi, karena sering kali menghasilkan struktur yang tidak transparan dan tidak dapat dipertanggungjawabkan di mana pengguna tidak dapat memverifikasi operasi. Sebaliknya, kita harus berusaha untuk mendekentralisasikan sebanyak mungkin dan membuat elemen-elemen yang tersisa dapat diverifikasi dan dipertanggungjawabkan di mana desentralisasi tidak memungkinkan.

Komunitas Ethereum tampaknya sejalan dengan pandangan ini, seperti rencana jalantermasuk tonggak (disebut “The Verge”) bertujuan membuat Ethereum lebih dapat diverifikasi. Namun, sebelum terjun ke The Verge, kita perlu memahami aspek-aspek apa dari blockchain yang harus diverifikasi dan bagian mana yang penting dari sudut pandang pengguna.

Blockchain pada dasarnya berfungsi sebagai jam global. Dalam jaringan terdistribusi dengan sekitar 10.000 komputer, dapat memakan waktu yang signifikan bagi sebuah transaksi untuk menyebar dari node asal ke semua node lainnya. Oleh karena itu, node-node di seluruh jaringan tidak dapat menentukan urutan transaksi secara tepat—baik transaksi mana yang tiba lebih dulu atau kemudian—karena mereka hanya memiliki perspektif subjektif mereka sendiri.

Karena urutan transaksi itu penting, jaringan blockchain menggunakan metode khusus yang disebut “algoritma konsensus” untuk memastikan bahwa node-node tetap disinkronkan dan memproses urutan transaksi dengan cara yang sama. Meskipun node-node tidak dapat menentukan urutan transaksi secara global, mekanisme konsensus memungkinkan semua node untuk sepakat pada urutan yang sama, sehingga jaringan dapat berfungsi sebagai satu unit komputer yang terpadu.

Di luar lapisan konsensus, ada juga lapisan eksekusi yang ada dalam setiap blockchain. Lapisan eksekusi dibentuk oleh transaksi yang ingin dilakukan oleh pengguna.

Setelah transaksi berhasil diurutkan berdasarkan konsensus, setiap transaksi harus diterapkan ke keadaan saat ini pada lapisan eksekusi. Jika Anda bertanya-tanya, “Apa itu keadaan?”, Anda mungkin pernah melihat perbandingan antara blockchain dengan database—atau lebih spesifik lagi, dengan database bank karena blockchain, seperti bank, menjaga catatan saldo setiap orang.

Jika Anda memiliki $100 dalam keadaan yang kita sebut “S” dan ingin mengirim $10 kepada orang lain, saldo Anda di keadaan berikutnya, “S+1”, akan menjadi $90. Proses menerapkan transaksi untuk pindah dari satu keadaan ke keadaan lain inilah yang kita sebut sebagai STF (Fungsi Transisi Keadaan).

Di Bitcoin, STF terutama terbatas pada perubahan saldo, sehingga relatif sederhana. Namun, berbeda dengan Bitcoin, STF Ethereum jauh lebih kompleks karena Ethereum adalah blockchain yang sepenuhnya dapat diprogram dengan lapisan eksekusi yang mampu menjalankan kode.

Dalam sebuah blockchain, ada tiga komponen dasar yang perlu atau dapat Anda verifikasi:

1. Status: Anda mungkin ingin membaca sebuah data di blockchain, tetapi tidak memiliki akses ke status karena Anda tidak menjalankannya.node penuhOleh karena itu, Anda meminta data melalui penyedia RPC (Remote Procedure Call) seperti Alchemy atau Infura. Namun, Anda harus memverifikasi bahwa data tidak telah dimanipulasi oleh penyedia RPC.
2. Eksekusi: Seperti yang disebutkan sebelumnya, blockchain menggunakan STF. Anda harus memverifikasi bahwa transisi keadaan dieksekusi dengan benar—tidak pada basis per-transaksi tetapi pada basis per-blok.
3. Konsensus: Entitas pihak ketiga, seperti RPC, dapat memberi Anda blok valid yang belum dimasukkan ke dalam blockchain. Oleh karena itu, Anda harus memverifikasi bahwa blok-blok ini telah diterima melalui konsensus dan ditambahkan ke dalam blockchain.

Jika ini terlihat membingungkan atau tidak jelas, jangan khawatir. Kami akan menjelaskan setiap aspek ini secara detail. Mari kita mulai dengan cara memverifikasi keadaan blockchain!

Bagaimana cara memverifikasi keadaan blockchain?

Kata “state” pada Ethereum merujuk pada kumpulan data yang tersimpan dalam blockchain pada setiap waktu. Ini mencakup saldo akun (akun kontrak dan akun yang dimiliki secara eksternal atau EOAs), kode kontrak pintar, penyimpanan kontrak, dan lainnya. Ethereum adalah mesin berbasis keadaan karena transaksi yang diproses dalam Mesin Virtual Ethereum (EVM) mengubah keadaan sebelumnya dan menghasilkan keadaan baru.

Setiap blok Ethereum mengandung nilai yang merangkum keadaan terkini jaringan setelah blok tersebut: stateRoot. Nilai ini merupakan representasi ringkas dari seluruh keadaan Ethereum, terdiri dari hash 64 karakter.

Karena setiap transaksi baru memodifikasi status, stateRoot yang dicatat dalam blok selanjutnya diperbarui sesuai. Untuk menghitung nilai ini, validator Ethereum menggunakan kombinasi fungsi hash Keccak dan struktur data yang disebutPohon Merkleuntuk mengatur dan merangkum bagian-bagian berbeda dari negara.

Fungsi hash adalah fungsi satu arah yang mengubah masukan menjadi keluaran berpanjang tetap. Dalam Ethereum, fungsi hash seperti Keccakdigunakan untuk menghasilkan ringkasan data, berfungsi sebagai semacam sidik jari untuk masukan. Fungsi hash memiliki empat properti mendasar:

1. Determinisme: Input yang sama akan selalu menghasilkan output yang sama.
2. Panjang output tetap: Terlepas dari panjang input, panjang output selalu tetap.
3. Properti satu arah: Sangat sulit untuk mendapatkan input asli dari output.
4. Keunikan: Bahkan perubahan kecil pada masukan menghasilkan keluaran yang benar-benar berbeda. Dengan demikian, masukan tertentu memetakan ke keluaran yang praktis unik.

Berkat sifat-sifat ini, validator Ethereum dapat melakukan STF (Fungsi Transisi State) untuk setiap blok—mengeksekusi semua transaksi dalam blok dan menerapkannya ke dalam status—dan kemudian memverifikasi apakah status yang tertera dalam blok sesuai dengan status yang diperoleh setelah STF. Proses ini memastikan bahwa penyarankan blok telah bertindak secara jujur, menjadikannya salah satu tanggung jawab kunci validator.

Namun, validator Ethereum tidak menghash seluruh state secara langsung untuk mencari ringkasannya. Karena sifat satu arah dari fungsi hash, menghash langsung state akan menghilangkan verifikabilitas, karena satu-satunya cara untuk menghasilkan ulang hash adalah dengan memiliki seluruh state.

Karena ukuran status Ethereum adalah beberapa terabyte, menyimpan seluruh status pada perangkat sehari-hari seperti ponsel atau komputer pribadi tidak praktis. Oleh karena itu, Ethereum menggunakan struktur pohon Merkle untuk menghitung stateRoot, menjaga verifikasi status sebanyak mungkin.

A pohon Merkleadalah struktur data kriptografis yang digunakan untuk memverifikasi integritas dan kebenaran data dengan aman dan efisien. Pohon Merkle dibangun di atas fungsi hash dan mengorganisir hash dari dataset secara hierarkis, memungkinkan verifikasi integritas dan kebenaran data ini. Struktur pohon ini terdiri dari tiga jenis node:

1. Node daun: Node-node ini berisi hash dari potongan data individual dan terletak di level paling bawah dari pohon. Setiap node daun mewakili hash dari potongan data tertentu di pohon Merkle.
2. Node cabang: Node-node ini berisi gabungan hash dari node-node anaknya. Misalnya, dalam pohon Merkle biner (dimana N=2), hash dari dua node anak digabungkan dan di-hash kembali untuk menghasilkan hash dari node cabang pada level yang lebih tinggi.
3. Node akar: Node akar berada pada level paling atas dari pohon Merkle dan mewakili ringkasan kriptografi dari seluruh pohon. Node ini digunakan untuk memverifikasi integritas dan kebenaran semua data dalam pohon.

Jika Anda bertanya-tanya bagaimana cara membuat pohon seperti itu, itu melibatkan hanya dua langkah sederhana:

• Pembuatan simpul daun: Setiap bagian data diproses melalui fungsi hash, dan hash yang dihasilkan membentuk simpul daun. Simpul ini berada pada level paling rendah dari pohon dan mewakili ringkasan kriptografi dari data.

• Gabungkan dan hash: Hash dari simpul daun dikelompokkan (misalnya, berpasangan) dan digabungkan, kemudian dihash. Proses ini membuat simpul cabang pada level berikutnya. Proses yang sama diulang untuk simpul cabang hingga hanya tersisa satu hash.

Hash terakhir yang diperoleh di bagian atas pohon disebut dengan akar Merkle. Akar Merkle mewakili ringkasan kriptografi dari seluruh pohon dan memungkinkan verifikasi keamanan integritas data.

Bagaimana kita menggunakan akar Merkle untuk memverifikasi keadaan Ethereum?

Bukti Merkle memungkinkan Verifier untuk secara efisien memvalidasi bagian-bagian data tertentu dengan menyediakan serangkaian nilai hash yang membuat jalur dari data yang dituju (node daun) ke Merkle Root yang disimpan di header blok. Rantai hash intermediate ini memungkinkan Verifier untuk mengonfirmasi keaslian data tanpa perlu menghash seluruh status.

Dimulai dari titik data tertentu, Verifier menggabungkannya dengan setiap hash “saudara” yang disediakan dalam Merkle Proof dan menghash mereka langkah demi langkah ke atas pohon. Proses ini terus berlanjut sampai satu hash tunggal dihasilkan. Jika hash yang dihitung ini cocok dengan Merkle Root yang disimpan, data dianggap valid; jika tidak, Verifier dapat menentukan bahwa data tersebut tidak sesuai dengan keadaan yang diklaim.

Contoh: Memverifikasi titik data dengan bukti Merkle

Misalkan kita telah menerima Data #4 dari RPC dan ingin memverifikasi keasliannya menggunakan Bukti Merkle. Untuk melakukannya, RPC akan menyediakan serangkaian nilai hash di sepanjang jalur yang diperlukan untuk mencapai Akar Merkle. Untuk Data 4, hash saudara akan mencakup Hash #3, Hash #12, dan Hash #5678.

1. Mulai dengan Data 4: Pertama, kami menghash Data #4 untuk mendapatkan Hash #4.
2. Gabung dengan Saudara Kandung: Kami kemudian menggabungkan Hash #4 dengan Hash #3 (saudaranya di tingkat daun) dan menghash keduanya bersama untuk menghasilkan Hash #34.
3. Naik Pohon: Selanjutnya, kita mengambil Hash #34 dan menggabungkannya dengan Hash #12 (saudaranya di level yang lebih tinggi) dan menghash mereka untuk mendapatkan Hash #1234.
4. Langkah Terakhir: Akhirnya, kita menggabungkan Hash #1234 dengan Hash #5678 (sibling terakhir yang disediakan) dan menggabungkannya bersama. Hash yang dihasilkan harus cocok dengan Merkle Root (Hash #12345678) yang disimpan dalam header blok.

Jika Merkle Root yang dihitung cocok dengan state root dalam blok, kami mengonfirmasi bahwa Data #4 memang valid dalam state ini. Jika tidak, kami tahu bahwa data tersebut tidak termasuk ke dalam state yang diklaim, menunjukkan adanya potensi pemalsuan. Seperti yang dapat Anda lihat, tanpa menyediakan hash dari semua data atau mengharuskan Verifier untuk merekonstruksi seluruh Merkle Tree dari awal, Prover dapat membuktikan bahwa Data #4 ada dalam state dan tidak mengalami perubahan selama perjalanan—hanya dengan menggunakan tiga hash. Ini adalah alasan utama mengapa Merkle Proofs dianggap efisien.

Meskipun Merkle Trees tanpa diragukan lagi efektif dalam menyediakan verifikasi data yang aman dan efisien dalam sistem blockchain besar seperti Ethereum, apakah mereka benar-benar cukup efisien? Untuk menjawab ini, kita harus menganalisis bagaimana kinerja dan ukuran Merkle Tree mempengaruhi hubungan Prover-Verifier.

Dua Faktor Kunci yang Mempengaruhi Kinerja Pohon Merkle: ⌛

1. Faktor Cabang: Jumlah simpul anak per cabang.
2. Ukuran Data Total: Ukuran dataset yang direpresentasikan dalam pohon.

Efek Faktor Percabangan:

Mari kita gunakan contoh untuk lebih memahami dampaknya. Faktor percabangan menentukan berapa banyak cabang yang muncul dari setiap simpul dalam pohon.

• Faktor Cabang Kecil (misalnya, Pohon Merkle Binari):
  Jika Pohon Merkle biner (faktor percabangan 2) digunakan, ukuran bukti sangat kecil, membuat proses verifikasi lebih efisien bagi Verifier. Dengan hanya dua cabang di setiap node, Verifier hanya perlu memproses satu hash sibling per tingkat. Hal ini mempercepat verifikasi dan mengurangi beban komputasi. Namun, faktor percabangan yang lebih rendah meningkatkan tinggi pohon, memerlukan lebih banyak operasi hashing selama konstruksi pohon, yang dapat membebani validator.
• Faktor Cabang yang Lebih Besar (misalnya, 4):
  Faktor percabangan yang lebih besar (misalnya, 4) mengurangi tinggi pohon, menciptakan struktur yang lebih pendek dan lebih lebar. Hal ini memungkinkan Node Penuh untuk membangun pohon lebih cepat karena lebih sedikit operasi hash yang diperlukan. Namun, bagi Verifier, hal ini meningkatkan jumlah hash saudara yang harus mereka proses di setiap tingkat, menyebabkan ukuran bukti yang lebih besar. Lebih banyak hash per langkah verifikasi juga berarti biaya komputasi dan bandwidth yang lebih tinggi bagi Verifier, yang efektif memindahkan beban dari validator ke verifier.

Efek Ukuran Data Total:

Seiring dengan pertumbuhan blockchain Ethereum, dengan setiap transaksi baru, kontrak, atau interaksi pengguna yang ditambahkan ke dataset, Pohon Merkle juga harus berkembang. Pertumbuhan ini tidak hanya meningkatkan ukuran pohon tetapi juga mempengaruhi ukuran bukti dan waktu verifikasi.

• Node Penuh harus memproses dan memperbarui kumpulan data yang berkembang secara teratur untuk mempertahankan Pohon Merkle.
• Verifiers, pada gilirannya, harus memvalidasi bukti yang lebih panjang dan kompleks seiring bertambahnya dataset, membutuhkan waktu pemrosesan dan bandwidth tambahan. \
  Ukuran data yang semakin berkembang ini meningkatkan permintaan pada Full Nodes dan Verifiers, sehingga mempersulit skalabilitas jaringan secara efisien.

Secara ringkas, meskipun Pohon Merkle menawarkan tingkat efisiensi, mereka tidak cukup menjadi solusi optimal untuk kumpulan data Ethereum yang terus berkembang. Untuk alasan ini, selama fase The Verge, Ethereum bertujuan untuk menggantikan Pohon Merkle dengan struktur yang lebih efisien yang dikenal sebagaiPohon VerkleVerkle Trees memiliki potensi untuk memberikan ukuran bukti yang lebih kecil sambil mempertahankan tingkat keamanan yang sama, membuat proses verifikasi lebih berkelanjutan dan dapat diskalakan baik untuk Prover maupun Verifier.

Bab 2: Revolusi Verifiabilitas di Ethereum - The Verge

Verge dikembangkan sebagai tonggak dalam peta jalan Ethereum yang bertujuan untuk meningkatkan verifikasi, memperkuat struktur terdesentralisasi blockchain, dan meningkatkan keamanan jaringan. Salah satu tujuan utama jaringan Ethereum adalah memungkinkan siapa pun untuk dengan mudah menjalankan validator untuk memverifikasi rantai, menciptakan struktur di mana partisipasi terbuka untuk semua orang tanpa sentralisasi. Aksesibilitas proses verifikasi ini adalah salah satu fitur utama yang membedakan blockchain dari sistem terpusat. Sementara sistem terpusat tidak menawarkan kemampuan verifikasi, kebenaran blockchain sepenuhnya berada di tangan penggunanya. Namun, untuk mempertahankan jaminan ini, menjalankan validator harus dapat diakses oleh semua orang—tantangan yang, dalam sistem saat ini, terbatas karena persyaratan penyimpanan dan komputasi.

Sejak beralih ke model konsensus Proof-of-Stake dengan The Merge, validator Ethereum memiliki dua tanggung jawab utama:

1. Menjamin Konsensus: Mendukung fungsi yang tepat dari protokol konsensus probabilistik dan deterministik serta menerapkan algoritma pemilihan fork.
2. Memeriksa Akurasi Blok: Setelah menjalankan transaksi dalam sebuah blok, memverifikasi bahwa akar pohon keadaan hasil cocok dengan akar keadaan yang dinyatakan oleh penyarankan.

Untuk memenuhi tanggung jawab kedua, validator harus memiliki akses ke status sebelum blok. Ini memungkinkan mereka untuk menjalankan transaksi blok dan mendapatkan status berikutnya. Namun, persyaratan ini memberikan beban berat pada validator, karena mereka perlu menangani persyaratan penyimpanan yang signifikan. Meskipun Ethereum dirancang untuk memungkinkan hal tersebut dan biaya penyimpanan telah menurun secara global, masalahnya lebih sedikit tentang biaya dan lebih tentang ketergantungan pada perangkat keras khusus untuk validator. Verge bertujuan untuk mengatasi tantangan ini dengan menciptakan infrastruktur di mana verifikasi penuh dapat dilakukan bahkan pada perangkat dengan penyimpanan terbatas, seperti ponsel, dompet browser, dan bahkan smartwatch, memungkinkan validator untuk berjalan pada perangkat-perangkat tersebut.

Langkah Pertama Verifiabilitas: Negara

Beralih ke Pohon Verkle adalah bagian kunci dari proses ini. Awalnya, Verge fokus pada penggantian struktur Pohon Merkle Ethereum dengan Pohon Verkle. Alasan utama mengadopsi Pohon Verkle adalah bahwa Pohon Merkle menjadi hambatan signifikan bagi verifiabilitas Ethereum. Meskipun Pohon Merkle dan bukti mereka dapat bekerja dengan efisien dalam skenario normal, kinerjanya menurun drastis dalam skenario terburuk.

Menurut perhitungan Vitalik, ukuran bukti rata-rata sekitar 4 KB, yang terdengar dapat dikelola. Namun, dalam skenario terburuk, ukuran bukti dapat melonjak hingga 330 MB. Ya, Anda membacanya dengan benar—330 MB.

Ketidakmampuan ekstrem Merkle Trees Ethereum dalam skenario terburuk berasal dari dua alasan utama:

1. Penggunaan Pohon Hexary: Saat ini Ethereum menggunakan Pohon Merkle dengan faktor percabangan 16. Ini berarti bahwa untuk memverifikasi satu node, diperlukan penyediaan 15 hash tersisa di cabang tersebut. Mengingat besarnya status Ethereum dan jumlah cabang, ini menciptakan beban substansial dalam skenario terburuk.

1. Non-Merkelization of Code: Alih-alih menyertakan kode kontrak ke dalam struktur pohon, Ethereum hanya menghash kode tersebut dan menggunakan nilai hasilnya sebagai node. Mengingat ukuran maksimum kontrak adalah 24 KB, pendekatan ini memberlakukan beban yang signifikan untuk mencapai verifikasi penuh.

Ukuran bukti secara langsung berbanding lurus dengan faktor percabangan. Mengurangi faktor percabangan akan mengurangi ukuran bukti. Untuk mengatasi masalah-masalah ini dan meningkatkan skenario terburuk, Ethereum dapat beralih dari Hexary Trees ke Binary Merkle Trees dan mulai merklizing kode kontrak. Jika faktor percabangan di Ethereum dikurangi dari 16 menjadi 2 dan kode kontrak juga dimerklikan, ukuran bukti maksimum bisa menyusut menjadi 10 MB. Meskipun ini merupakan peningkatan yang signifikan, penting untuk dicatat bahwa biaya ini berlaku untuk memverifikasi hanya satu data. Bahkan transaksi sederhana yang mengakses beberapa data akan memerlukan bukti yang lebih besar. Mengingat jumlah transaksi per blok dan keadaan Ethereum yang terus bertumbuh, solusi ini, meskipun lebih baik, masih belum sepenuhnya memungkinkan.

Untuk alasan-alasan ini, komunitas Ethereum telah mengusulkan dua solusi yang berbeda untuk mengatasi masalah ini:

1. Pohon Verkle
2. Bukti STARK + Pohon Merkle Binari

Pohon Verkle & Komitmen Vektor

Pohon Verkle, seperti namanya, adalah struktur pohon yang mirip dengan Pohon Merkle. Namun, perbedaan yang paling signifikan terletak pada efisiensi yang mereka tawarkan selama proses verifikasi. Pada Pohon Merkle, jika suatu cabang mengandung 16 potongan data dan kita ingin memverifikasi hanya salah satunya, rantai hash yang mencakup 15 potongan lain juga harus disediakan. Hal ini secara signifikan meningkatkan beban komputasi verifikasi dan menghasilkan ukuran bukti yang besar.

Sebaliknya, Pohon Verkle menggunakan struktur khusus yang dikenal sebagai “Elliptic Curve-based Vector Commitments”, lebih spesifik lagi, Vector Commitment berbasis Argumen Inner Product (IPA). Vektor pada dasarnya adalah daftar elemen data yang diorganisir dalam urutan tertentu. Status Ethereum dapat dianggap sebagai vektor: sebuah struktur di mana banyak bagian data disimpan dalam urutan tertentu, dengan setiap elemen menjadi penting. Status ini terdiri dari berbagai komponen data seperti alamat, kode kontrak, dan informasi penyimpanan, di mana urutan elemen-elemen ini memainkan peran penting dalam akses dan verifikasi.

Komitmen Vektor adalah metode kriptografi yang digunakan untuk membuktikan dan memverifikasi elemen data dalam sebuah dataset. Metode ini memungkinkan verifikasi baik keberadaan maupun urutan setiap elemen dalam sebuah dataset secara simultan. Sebagai contoh, Merkle Proofs, yang digunakan dalam Merkle Trees, juga dapat dianggap sebagai bentuk Komitmen Vektor. Sementara Merkle Trees membutuhkan semua rantai hash terkait untuk memverifikasi sebuah elemen, struktur tersebut secara inheren membuktikan bahwa semua elemen dari sebuah vektor terhubung dalam urutan tertentu.

Tidak seperti Pohon Merkle, Pohon Verkle menggunakan komitmen vektor berbasis kurva eliptik yang menawarkan dua keunggulan kunci:

• Komitmen vektor berbasis kurva elips menghilangkan kebutuhan akan detail elemen selain data yang diverifikasi. Pada Pohon Merkle dengan faktor percabangan 16, memverifikasi satu cabang memerlukan penyediaan 15 hash lainnya. Mengingat besarnya ukuran status Ethereum, yang melibatkan banyak cabang, hal ini menciptakan ketidakefisienan yang signifikan. Namun, komitmen vektor berbasis kurva elips menghilangkan kompleksitas ini, memungkinkan verifikasi dengan data dan upaya komputasi yang lebih sedikit.
• Melalui multi-bukti, bukti yang dihasilkan oleh komitmen vektor berbasis kurva eliptik dapat dikompresi menjadi bukti ukuran konstan tunggal. Status Ethereum tidak hanya besar tetapi juga terus berkembang, yang berarti jumlah cabang yang memerlukan verifikasi untuk mengakses Merkle Root meningkat seiring waktu. Namun, dengan Verkle Trees, kita dapat “memampatkan” bukti untuk setiap cabang menjadi satu bukti ukuran konstan menggunakan metode yang dirinci dalam Artikel Dankrad Feist. Ini memungkinkan Verifier untuk memvalidasi seluruh pohon dengan satu bukti kecil daripada memverifikasi setiap cabang secara individual. Ini juga berarti bahwa Pohon Verkle tidak terpengaruh oleh pertumbuhan negara Ethereum.

Fitur-fitur dari komitmen vektor berbasis kurva eliptik secara signifikan mengurangi jumlah data yang dibutuhkan untuk verifikasi, memungkinkan Verkle Trees untuk menghasilkan bukti dengan ukuran kecil dan tetap bahkan dalam skenario terburuk. Hal ini mengurangi beban data dan waktu verifikasi, meningkatkan efisiensi jaringan berskala besar seperti Ethereum. Sebagai hasilnya, penggunaan komitmen vektor berbasis kurva eliptik dalam Verkle Trees memungkinkan penanganan Ethereum yang lebih mudah dan efisien dengan keadaan yang semakin berkembang.

Seperti semua inovasi, Pohon Verkle memiliki keterbatasan mereka. Salah satu kelemahan utama mereka adalah bahwa mereka bergantung pada kriptografi kurva eliptik, yang rentan terhadap komputer kuantum. Komputer kuantum memiliki daya komputasi yang jauh lebih besar daripada metode klasik, yang merupakan ancaman signifikan bagi protokol kriptografi berbasis kurva eliptik. Algoritma kuantum berpotensi merusak atau melemahkan sistem kriptografi ini, yang meningkatkan kekhawatiran tentang keamanan jangka panjang Pohon Verkle.

Oleh karena itu, meskipun Pohon Verkle menawarkan solusi yang menjanjikan terhadap keadaan tanpa negara, mereka bukan solusi yang mutlak. Namun, tokoh seperti Dankrad Feist telah menekankan bahwa, meskipun perlu pertimbangan yang hati-hati saat mengintegrasikan kriptografi tahan kuanta ke Ethereum, perlu dicatat bahwa komitmen KZG yang saat ini digunakan untuk blob di Ethereum juga tidak tahan kuanta. Dengan demikian, Pohon Verkle dapat menjadi solusi sementara, memberikan jaringan waktu tambahan untuk mengembangkan alternatif yang lebih tangguh.

Bukti STARK + Pohon Merkle Biner

Pohon Verkle menawarkan ukuran bukti yang lebih kecil dan proses verifikasi yang efisien dibandingkan dengan Pohon Merkle, sehingga lebih mudah untuk mengelola keadaan Ethereum yang terus berkembang. Berkat Komitmen Vektor Berbasis Kurva Eliptik, bukti skala besar dapat dihasilkan dengan data yang jauh lebih sedikit. Namun, meskipun memiliki keunggulan yang mengesankan, kerentanan Pohon Verkle terhadap komputer kuantum membuatnya hanya sebagai solusi sementara. Sementara komunitas Ethereum melihat Pohon Verkle sebagai alat jangka pendek untuk membeli waktu, fokus jangka panjang adalah beralih ke solusi tahan terhadap komputer kuantum. Inilah tempat di mana Bukti STARK dan Pohon Merkle Biner menawarkan alternatif yang kuat untuk membangun infrastruktur verifikasi yang lebih kokoh untuk masa depan.

Dalam proses verifikasi status Ethereum, faktor percabangan Pohon Merkle dapat dikurangi (dari 16 menjadi 2) dengan menggunakan Pohon Merkle Biner. Perubahan ini adalah langkah kritis untuk mengurangi ukuran bukti dan membuat proses verifikasi lebih efisien. Namun, bahkan dalam skenario terburuk, ukuran bukti masih bisa mencapai 10 MB, yang signifikan. Di sinilah Bukti STARK berperan, yang mengompres Bukti Merkle Biner besar ini menjadi hanya 100-300 kB saja.

Optimasi ini sangat penting terutama saat mempertimbangkan batasan-batasan pengoperasian validator pada klien ringan atau perangkat dengan perangkat keras terbatas, terutama jika Anda mempertimbangkan bahwa kecepatan unduh dan unggahan mobile global rata-rata adalah sekitar 7,625 MB/s dan 1,5 MB/s. Pengguna dapat memverifikasi transaksi dengan bukti kecil yang mudah dibawa tanpa perlu mengakses seluruh status, dan validator dapat melakukan tugas verifikasi blok tanpa menyimpan seluruh status.

Pendekatan dual-manfaat ini mengurangi kebutuhan bandwidth dan penyimpanan untuk validator, sambil mempercepat verifikasi, tiga peningkatan kunci yang secara langsung mendukung visi Ethereum untuk skalabilitas.

Tantangan Utama untuk Bukti STARK:

1. Beban Komputasi Tinggi untuk Provers: \
   Proses menghasilkan bukti STARK membutuhkan komputasi yang intensif, terutama di sisi pemberi bukti, yang dapat meningkatkan biaya operasional.
2. Ketidakcukupan dalam Bukti Data Kecil:

Sementara bukti STARK unggul dalam menangani kumpulan data besar, mereka kurang efisien saat membuktikan jumlah data kecil, yang dapat menghambat aplikasi mereka dalam beberapa skenario tertentu. Ketika berurusan dengan program yang melibatkan langkah-langkah atau kumpulan data yang lebih kecil, ukuran bukti yang relatif besar dari STARK dapat membuatnya kurang praktis atau efisien biaya.

Keamanan Kuantum Datang dengan Biaya: Beban Komputasi Pihak Prover

Merkle Proof sebuah blok dapat mencakup sekitar 330.000 hash, dan dalam skenario terburuk, jumlah ini dapat meningkat menjadi 660.000. Dalam kasus seperti itu, bukti STARK perlu memproses sekitar 200.000 hash per detik.

Di sinilah fungsi hash yang ramah zk seperti Poseidon berperan, yang dioptimalkan khusus untuk bukti STARK untuk mengurangi beban ini. Poseidon dirancang untuk bekerja lebih lancar dengan ZK-proofs dibandingkan dengan algoritma hash tradisional seperti SHA256 dan Keccak. Alasan utama kompatibilitas ini terletak pada bagaimana algoritma hash tradisional beroperasi: mereka memproses masukan sebagai data biner (0 dan 1). Di sisi lain, ZK-proofs bekerja dengan bidang prima, struktur matematika yang secara mendasar berbeda. Situasi ini analog dengan komputer yang beroperasi secara biner sementara manusia menggunakan sistem desimal dalam kehidupan sehari-hari. Menerjemahkan data berbasis bit menjadi format yang kompatibel dengan ZK melibatkan beban komputasi yang signifikan. Poseidon memecahkan masalah ini dengan mengoperasikan dalam bidang prima, secara dramatis mempercepat integrasinya dengan ZK-proofs.

Namun, karena Poseidon adalah fungsi hash yang relatif baru, diperlukan analisis keamanan yang lebih mendalam untuk memastikan tingkat kepercayaan yang sama dengan fungsi hash tradisional seperti SHA256 dan Keccak. Untuk mencapai tujuan ini, inisiatif seperti Inisiatif Kriptografi Poseidon, diluncurkan oleh Ethereum Foundation, mengundang para ahli untuk secara ketat menguji dan menganalisis keamanan Poseidon, memastikan bahwa Poseidon dapat bertahan dari pemeriksaan musuh dan menjadi standar yang kuat untuk aplikasi kriptografi. Di sisi lain, fungsi-fungsi yang lebih tua seperti SHA256 dan Keccak telah diuji secara ekstensif dan memiliki catatan keamanan yang terbukti namun tidak bersahabat dengan ZK, sehingga mengakibatkan penurunan performa ketika digunakan dengan bukti STARK.

Misalnya, bukti STARK menggunakan fungsi hash tradisional ini saat ini hanya dapat memproses 10.000 hingga 30.000 hash. Untungnya, kemajuan dalam teknologi STARK menunjukkan bahwa throughput ini dapat segera meningkat menjadi 100.000 hingga 200.000 hash, yang secara signifikan meningkatkan efisiensinya.

Ketidakefisienan STARKs dalam membuktikan data kecil

Sementara bukti STARK sangat baik dalam skalabilitas dan transparansi untuk kumpulan data besar, mereka menunjukkan keterbatasan saat bekerja dengan elemen data yang kecil dan banyak. Dalam skenario seperti ini, data yang dibuktikan seringkali kecil, tetapi kebutuhan akan banyak bukti tetap tidak berubah. Contohnya meliputi:

1. Validasi transaksi pasca-AA: \
   Dengan Abstraksi Akun (AA), dompet dapat menunjuk ke kode kontrak, melewati atau menyesuaikan langkah-langkah seperti nonce dan verifikasi tanda tangan, yang saat ini wajib di Ethereum. Namun, fleksibilitas dalam validasi ini memerlukan pemeriksaan kode kontrak atau data terkait lainnya di negara bagian untuk membuktikan validitas transaksi.
2. Panggilan RPC klien ringan: \
   Klien ringan mengambil data status dari jaringan (misalnya, selama permintaan eth_call) tanpa menjalankan node penuh. Untuk menjamin kebenaran dari status ini, bukti harus mendukung data yang ditanyakan dan mengonfirmasi bahwa data tersebut sesuai dengan status saat ini dari jaringan.
3. Daftar inklusi: \
   Validator yang lebih kecil dapat menggunakan mekanisme daftar inklusi untuk memastikan transaksi disertakan dalam blok berikutnya, membatasi pengaruh produsen blok yang kuat. Namun, memvalidasi inklusi transaksi ini memerlukan memverifikasi kebenaran mereka.

Dalam kasus penggunaan seperti itu, bukti STARK memberikan sedikit keuntungan. STARK, menekankan skalabilitas (seperti yang disorot oleh “S” dalam namanya), berkinerja baik untuk kumpulan data besar tetapi berjuang dengan skenario data kecil. Sebaliknya, SNARKs, dirancang untuk ringkas (seperti yang ditekankan oleh “S” dalam nama mereka), fokus pada meminimalkan ukuran bukti, menawarkan keuntungan yang jelas dalam lingkungan dengan bandwidth atau kendala penyimpanan.

Bukti STARK biasanya berukuran 40-50 KB, sekitar 175 kali lebih besar dari bukti SNARK yang hanya berukuran 288 byte. Perbedaan ukuran ini meningkatkan waktu verifikasi dan biaya jaringan. Alasan utama bukti STARK yang lebih besar adalah ketergantungan mereka pada transparansi dan komitmen polinomial untuk memastikan skalabilitas, yang memperkenalkan biaya kinerja dalam skenario data kecil. Dalam kasus seperti itu, metode yang lebih cepat dan lebih efisien seperti Merkle Proof mungkin lebih praktis. Merkle Proof menawarkan biaya komputasi rendah dan pembaruan cepat, sehingga cocok untuk situasi-situasi tersebut.

Namun, bukti STARK tetap penting untuk masa depan Ethereum yang tidak memiliki negara karena keamanan kuantumnya.

Seperti yang dirangkum dalam tabel, Ethereum memiliki empat jalur potensial yang dapat dipilih:

• Pohon Verkle
  1. Verkle Trees telah menerima dukungan luas dari komunitas Ethereum, dengan pertemuan dua mingguan diadakan untuk memfasilitasi perkembangan mereka. Berkat kerja dan pengujian yang konsisten ini, Verkle Trees menonjol sebagai solusi yang paling matang dan diteliti dengan baik di antara alternatif saat ini. Selain itu, sifat homomorfik aditifnya menghilangkan kebutuhan untuk menghitung ulang setiap cabang untuk memperbarui root state, tidak seperti Merkle Trees, menjadikan Verkle Trees pilihan yang lebih efisien. Dibandingkan dengan solusi lain, Verkle Trees menekankan kesederhanaan, mengikuti prinsip-prinsip teknik seperti “tetap sederhana” atau “sederhana adalah yang terbaik.” Kesederhanaan ini memfasilitasi integrasi ke dalam Ethereum dan analisis keamanan.
  2. Namun, Pohon Verkle tidak aman terhadap kuantum, sehingga menghalangi penggunaannya sebagai solusi jangka panjang. Jika diintegrasikan ke Ethereum, teknologi ini kemungkinan besar perlu diganti di masa depan ketika solusi tahan kuantum diperlukan. Bahkan Vitalik melihat Pohon Verkle sebagai tindakan sementara untuk membeli waktu bagi STARK dan teknologi lain untuk berkembang. Selain itu, komitmen vektor berbasis kurva eliptik yang digunakan dalam Pohon Verkle memberikan beban komputasi yang lebih tinggi dibandingkan dengan fungsi hash sederhana. Pendekatan berbasis hash dapat menawarkan waktu sinkronisasi yang lebih cepat untuk node lengkap. Selain itu, ketergantungan pada operasi 256-bit yang banyak membuat Pohon Verkle lebih sulit dibuktikan menggunakan SNARK dalam sistem pembuktian modern, yang mempersulit upaya di masa depan untuk mengurangi ukuran bukti.

Namun, penting untuk dicatat bahwa Pohon Verkle, karena tidak bergantung pada hashing, jauh lebih dapat dibuktikan daripada Pohon Merkle.

• STARKs + Fungsi Hash Konservatif
  1. Menggabungkan STARKs dengan fungsi hash konservatif yang mapan seperti SHA256 atau BLAKE menyediakan solusi yang kuat yang memperkuat infrastruktur keamanan Ethereum. Fungsi hash ini telah banyak digunakan dan diuji secara ekstensif baik dalam domain akademis maupun praktis. Selain itu, ketahanan kuantum mereka meningkatkan ketangguhan Ethereum terhadap ancaman masa depan yang ditimbulkan oleh komputer kuantum. Untuk skenario yang kritis terhadap keamanan, kombinasi ini menawarkan landasan yang dapat diandalkan.
  2. Namun, penggunaan fungsi hash yang konservatif dalam sistem STARK menghadirkan keterbatasan kinerja yang signifikan. Persyaratan komputasi dari fungsi hash ini menghasilkan keterlambatan prover yang tinggi, dengan pembuatan bukti memakan waktu lebih dari 10 detik. Ini adalah kelemahan utama, terutama dalam skenario seperti validasi blok yang membutuhkan latensi rendah. Meskipun upaya seperti proposal gas multidimensi mencoba untuk menyelaraskan latensi kasus terburuk dan kasus rata-rata, hasilnya terbatas. Selain itu, meskipun pendekatan berbasis hash dapat memfasilitasi waktu sinkronisasi yang lebih cepat, efisiensinya mungkin tidak sejalan dengan tujuan skalabilitas yang lebih luas dari STARKs. Waktu komputasi yang lama dari fungsi hash tradisional mengurangi efisiensi praktis dan membatasi aplikabilitasnya.
• STARKs + Fungsi Hash yang Relatif Baru
  1. STARKs yang digabungkan dengan fungsi hash ramah STARK generasi baru (misalnya, Poseidon) secara signifikan meningkatkan kinerja teknologi ini. Fungsi hash ini dirancang untuk terintegrasi dengan lancar dengan sistem STARK dan secara drastis mengurangi latensi prover. Tidak seperti fungsi hash tradisional, mereka memungkinkan generasi bukti dalam waktu secepat 1-2 detik. Efisiensi dan overhead komputasi rendah mereka meningkatkan potensi skalabilitas STARKs, menjadikannya sangat efektif untuk menangani set data besar. Kemampuan ini membuatnya sangat menarik untuk aplikasi yang membutuhkan kinerja tinggi.
  2. Namun, kebaruan relatif dari fungsi hash ini memerlukan analisis dan pengujian keamanan yang ekstensif. Kurangnya pengujian komprehensif menimbulkan risiko ketika mempertimbangkan penerapannya di ekosistem kritis seperti Ethereum. Selain itu, karena fungsi hash ini belum diadopsi secara luas, proses pengujian dan validasi yang diperlukan dapat menunda tujuan verifikasi Ethereum. Waktu yang dibutuhkan untuk sepenuhnya memastikan keamanan mereka mungkin membuat opsi ini kurang menarik dalam jangka pendek, berpotensi menunda ambisi skalabilitas dan verifikasi Ethereum.
• Pohon Merkle berbasis Jaringan Kisi
  1. Pohon Merkle berbasis lattice menawarkan solusi berpikir ke depan yang menggabungkan keamanan kuantum dengan efisiensi pembaruan dari Pohon Verkle. Struktur ini menangani kelemahan dari Pohon Verkle dan STARKs dan dianggap sebagai opsi jangka panjang yang menjanjikan. Dengan desain berbasis lattice, mereka memberikan resistensi kuat terhadap ancaman komputasi kuantum, sejalan dengan fokus Ethereum pada masa depan dari ekosistemnya. Selain itu, dengan mempertahankan keunggulan pembaruan dari Pohon Verkle, mereka bertujuan untuk memberikan keamanan yang ditingkatkan tanpa mengorbankan efisiensi.
  2. Namun, penelitian tentang Pohon Merkle berbasis kisi-kisi masih dalam tahap awal dan sebagian besar bersifat teoritis. Hal ini menciptakan ketidakpastian yang signifikan tentang implementasi dan kinerja praktisnya. Mengintegrasikan solusi tersebut ke dalam Ethereum akan membutuhkan penelitian dan pengembangan yang luas, serta pengujian yang ketat untuk memvalidasi manfaat potensialnya. Ketidakpastian dan kompleksitas infrastruktur ini membuat Pohon Merkle berbasis kisi-kisi tidak mungkin menjadi pilihan yang layak untuk Ethereum dalam waktu dekat, yang berpotensi menghambat kemajuan terhadap tujuan verifikasi jaringan.

Bagaimana dengan eksekusi: Bukti keabsahan eksekusi EVM

Semua yang telah kita bahas sejauh ini berkaitan dengan menghilangkan kebutuhan validator untuk menyimpan keadaan sebelumnya, yang mereka gunakan untuk beralih dari satu keadaan ke keadaan berikutnya. Tujuannya adalah untuk menciptakan lingkungan yang lebih terdesentralisasi di mana validator dapat melakukan tugas mereka tanpa mempertahankan terabyte data keadaan. Meskipun dengan solusi yang telah kita sebutkan, validator tidak perlu menyimpan seluruh keadaan, karena mereka akan menerima semua data yang diperlukan untuk eksekusi melalui saksi yang disertakan dengan blok. Namun, untuk beralih ke keadaan berikutnya - dan dengan demikian memverifikasi stateRoot di atas blok - validator masih harus mengeksekusi STF sendiri. Persyaratan ini, pada gilirannya, menimbulkan tantangan lain bagi sifat tanpa izin dan terdesentralisasi Ethereum.

Awalnya, The Verge dibayangkan sebagai tonggak sejarah yang hanya berfokus pada transisi pohon negara Ethereum dari Merkle Trees ke Verkle Trees untuk meningkatkan verifikasi negara. Namun, seiring waktu, ini telah berkembang menjadi inisiatif yang lebih luas yang bertujuan untuk meningkatkan verifikasi transisi dan konsensus negara. Di dunia di mana trio Negara, Eksekusi, dan Konsensus sepenuhnya dapat diverifikasi, validator Ethereum dapat beroperasi di hampir semua perangkat dengan koneksi internet yang dapat dikategorikan sebagai Klien Ringan. Ini akan membawa Ethereum lebih dekat untuk mencapai visinya tentang “desentralisasi sejati.”

Apa definisi masalahnya?

Seperti yang telah kami sebutkan sebelumnya, validator menjalankan fungsi yang disebut STF (State Transition Function) setiap 12 detik. Fungsi ini mengambil input berupa state sebelumnya dan blok, dan menghasilkan state berikutnya sebagai output. Validator harus menjalankan fungsi ini setiap kali blok baru diajukan dan memverifikasi bahwa hash yang mewakili state di atas blok - biasanya disebut dengan state root - benar.

Persyaratan sistem yang tinggi untuk menjadi validator utamanya berasal dari kebutuhan untuk melakukan proses ini dengan efisien.

Jika Anda ingin mengubah lemari es pintar—ya, bahkan lemari es—menjadi validator Ethereum dengan bantuan beberapa perangkat lunak yang diinstal, Anda akan menghadapi dua hambatan utama:

1. Kulkas Anda kemungkinan besar tidak akan memiliki internet yang cukup cepat, yang berarti tidak dapat mengunduh data dan bukti yang diperlukan untuk eksekusi bahkan dengan solusi verifiabilitas negara yang telah kita bahas sejauh ini.
2. Meskipun memiliki akses ke data yang diperlukan untuk STF, itu tidak akan memiliki kekuatan komputasi yang diperlukan untuk melakukan eksekusi dari awal hingga akhir atau membangun pohon status baru.

Untuk mengatasi masalah yang disebabkan oleh Klien Ringan yang tidak memiliki akses ke keadaan sebelumnya atau seluruh blok terakhir, The Verge mengusulkan bahwa penentu harus melakukan eksekusi dan kemudian melampirkan bukti ke blok. Bukti ini akan mencakup transisi dari root keadaan sebelumnya ke root keadaan selanjutnya serta hash blok. Dengan ini, Klien Ringan dapat memvalidasi transisi keadaan menggunakan hanya tiga hash 32-byte, tanpa perlu zk-proof.

Namun, karena bukti ini bekerja melalui hash, tidak benar untuk mengatakan bahwa ini hanya memvalidasi transisi keadaan. Sebaliknya, bukti yang terlampir pada blok harus memvalidasi beberapa hal secara simultan:

Akar state di blok sebelumnya = S, Akar state di blok berikutnya = S + 1, Hash blok = H

1. Blok itu sendiri harus valid, dan bukti keadaan di dalamnya—baik itu Verkle Proof atau STARKs—harus secara akurat memverifikasi data yang menyertainya.
   Singkatnya: Validasi blok dan bukti keadaan yang menyertainya.
2. Ketika STF dieksekusi menggunakan data yang diperlukan untuk dieksekusi dan disertakan dalam blok yang sesuai dengan H, data yang seharusnya berubah dalam keadaan harus diperbarui dengan benar.
   Singkatnya: Validasi dari transisi keadaan.
3. Ketika pohon status baru dibangun dengan data yang diperbarui dengan benar, nilai akarnya harus sesuai dengan S + 1.
   Singkatnya: Validasi proses konstruksi pohon.

Dalam analogi Prover-Verifier yang telah kami sebutkan sebelumnya, dapat dikatakan bahwa ada keseimbangan komputasi antara kedua aktor tersebut. Meskipun kemampuan bukti yang diperlukan untuk membuat STF yang dapat diverifikasi untuk memvalidasi beberapa hal secara simultan menawarkan keuntungan signifikan bagi Verifier, hal ini juga menunjukkan bahwa menghasilkan bukti-bukti tersebut untuk memastikan kebenaran eksekusi akan relatif sulit bagi Prover. Dengan kecepatan Ethereum saat ini, sebuah blok Ethereum harus terbukti dalam waktu kurang dari 4 detik. Namun, bahkan Prover EVM tercepat yang ada saat ini hanya dapat membuktikan sebuah blok rata-rata dalam waktu sekitar 15 detik.[1]

Dengan dikatakan demikian, ada tiga jalur yang berbeda yang dapat kita ambil untuk mengatasi tantangan utama ini:

1. Paralelisasi dalam Membuktikan & Agregasi: Salah satu keuntungan signifikan dari ZK-proofs adalah kemampuan mereka untuk diagregasi. Kemampuan untuk menggabungkan beberapa bukti menjadi satu bukti yang kompak memberikan efisiensi yang substansial dalam hal waktu pemrosesan. Hal ini tidak hanya mengurangi beban pada jaringan tetapi juga mempercepat proses verifikasi secara terdesentralisasi. Untuk jaringan besar seperti Ethereum, ini memungkinkan generasi bukti yang lebih efisien untuk setiap blok.

Selama pembuatan bukti, setiap bagian kecil dari proses eksekusi (misalnya, langkah-langkah komputasi atau akses data) dapat dibuktikan secara individual, dan bukti-bukti ini dapat dikumpulkan menjadi satu struktur. Dengan mekanisme yang tepat, pendekatan ini memungkinkan bukti blok yang dihasilkan dengan cepat dan secara terdesentralisasi oleh berbagai sumber yang berbeda (misalnya, ratusan GPU). Ini meningkatkan kinerja sambil juga berkontribusi pada tujuan terdesentralisasi dengan melibatkan lebih banyak peserta.

1. Menggunakan Sistem Bukti Teroptimasi: Sistem bukti generasi baru memiliki potensi untuk membuat proses komputasi Ethereum lebih cepat dan efisien. Sistem yang canggih seperti Orion, Binius, dan GKRdapat secara signifikan mengurangi waktu pengguna untuk komputasi umum. Sistem-sistem ini bertujuan untuk mengatasi keterbatasan teknologi saat ini, meningkatkan kecepatan pemrosesan sambil mengonsumsi sumber daya yang lebih sedikit. Bagi jaringan yang fokus pada skalabilitas dan efisiensi seperti Ethereum, optimisasi semacam ini memberikan keuntungan yang signifikan. Namun, implementasi penuh dari sistem-sistem baru ini memerlukan pengujian menyeluruh dan upaya kompatibilitas dalam ekosistem.
2. Perubahan Biaya Gas: Secara historis, biaya gas untuk operasi pada Mesin Virtual Ethereum (EVM) biasanya ditentukan berdasarkan biaya komputasionalnya. Namun, saat ini, metrik lain juga semakin diperhatikan: kompleksitas pembuktian. Sementara beberapa operasi relatif mudah untuk dibuktikan, yang lain memiliki struktur yang lebih kompleks dan membutuhkan waktu lebih lama untuk diverifikasi. Menyesuaikan biaya gas tidak hanya berdasarkan upaya komputasional tetapi juga kesulitan pembuktian operasi sangat penting untuk meningkatkan keamanan dan efisiensi jaringan.

Pendekatan ini dapat meminimalkan kesenjangan antara skenario kasus terburuk dan rata-rata, memungkinkan kinerja yang lebih konsisten. Misalnya, operasi yang lebih sulit untuk dibuktikan dapat memiliki biaya gas yang lebih tinggi, sementara yang lebih mudah untuk dibuktikan dapat memiliki biaya lebih rendah. Selain itu, penggantian struktur data Ethereum (seperti pohon status atau daftar transaksi) dengan alternatif yang ramah STARK dapat lebih mempercepat proses bukti. Perubahan seperti itu akan membantu Ethereum mencapai tujuan skalabilitas dan keamanannya sambil membuat visi verifikasinya lebih realistis.

Upaya Ethereum untuk memungkinkan bukti eksekusi mewakili peluang signifikan untuk mencapai tujuannya yang terverifikasi. Namun, mencapai tujuan ini tidak hanya memerlukan inovasi teknis tetapi juga peningkatan upaya teknik dan keputusan kritis dalam komunitas. Membuat proses eksekusi dapat diverifikasi di Layer 1 harus menemukan keseimbangan antara dapat diakses oleh pengguna yang luas sambil mempertahankan desentralisasi dan selaras dengan infrastruktur yang ada. Membangun keseimbangan ini meningkatkan kompleksitas metode yang digunakan untuk membuktikan operasi selama eksekusi, menyoroti kebutuhan akan kemajuan seperti generasi bukti paralel. Selain itu, persyaratan infrastruktur dari teknologi-teknologi ini (misalnya, )tabel pencarian) harus diimplementasikan dan dioperasikan, yang masih membutuhkan penelitian dan pengembangan yang besar.

Di sisi lain, sirkuit khusus (misalnya, ASIC, FPGA, GPU) yang dirancang khusus untuk tugas-tugas tertentu memiliki potensi signifikan untuk mempercepat proses pembangkitan bukti. Solusi ini memberikan efisiensi yang jauh lebih tinggi dibandingkan dengan perangkat keras tradisional dan dapat mempercepat proses eksekusi. Namun, tujuan desentralisasi Ethereum di tingkat Layer 1 mencegah perangkat keras tersebut hanya dapat diakses oleh sekelompok aktor tertentu. Akibatnya, solusi ini diharapkan untuk melihat penggunaan yang lebih luas dalam sistem Layer 2. Namun demikian, masyarakat juga harus mencapai konsensus tentang persyaratan perangkat keras untuk pembuatan bukti. Pertanyaan desain utama muncul: haruskah pembangkitan bukti bekerja pada perangkat keras kelas konsumen seperti laptop kelas atas, atau memerlukan infrastruktur industri? Jawabannya membentuk seluruh arsitektur Ethereum – memungkinkan pengoptimalan agresif untuk solusi Layer 2 sambil menuntut pendekatan yang lebih konservatif untuk Layer 1.

Akhirnya, implementasi bukti eksekusi terkait langsung dengan tujuan roadmap Ethereum lainnya. Pengenalan bukti keabsahan tidak hanya akan mendukung konsep seperti tanpa keadaan tetapi juga meningkatkan desentralisasi Ethereum dengan membuat area seperti staking solo lebih mudah diakses. Tujuannya adalah memungkinkan staking bahkan pada perangkat yang paling rendah spesifikasinya. Selain itu, restrukturisasi biaya gas pada EVM berdasarkan kesulitan komputasi dan kebuktian dapat meminimalkan kesenjangan antara kasus rata-rata dan kasus terburuk. Namun, perubahan seperti itu dapat memutuskan kompatibilitas mundur dengan sistem saat ini dan memaksa pengembang untuk menulis ulang kode mereka. Oleh karena itu, implementasi bukti eksekusi bukan hanya tantangan teknis - ini adalah perjalanan yang harus dirancang untuk menjunjung nilai-nilai jangka panjang Ethereum.

Langkah terakhir untuk keberhasilan verifikasi penuh sejati: Konsensus

Mekanisme konsensus Ethereum berusaha untuk menetapkan keseimbangan unik yang mempertahankan desentralisasi dan aksesibilitas sambil mencapai tujuan verifikasi. Dalam kerangka ini, metode konsensus probabilistik dan deterministik menawarkan keunggulan dan tantangan yang berbeda.

Konsensus probabilistik dibangun berdasarkan model komunikasi gossiping. Dalam model ini, alih-alih berkomunikasi langsung dengan semua node yang mewakili jaringan, sebuah node membagikan informasi dengan sekumpulan node yang dipilih secara acak sebanyak 64 atau 128 node. Pemilihan rantai sebuah node didasarkan pada informasi terbatas ini, yang memperkenalkan kemungkinan terjadinya kesalahan. Namun, seiring waktu berjalan, seiring kemajuan blockchain, pemilihan-pemilihan ini diharapkan akan konvergen menuju rantai yang benar dengan tingkat kesalahan 0%.

Salah satu keuntungan dari struktur probabilitas adalah bahwa setiap node tidak menyiarkan pandangannya atas rantai sebagai pesan terpisah, mengurangi overhead komunikasi. Konsekuensinya, struktur seperti ini dapat beroperasi dengan banyak node terdesentralisasi tanpa izin dengan persyaratan sistem yang lebih rendah. Sebaliknya, konsensus deterministik beroperasi melalui model komunikasi satu-ke-semua. Di sini, sebuah node mengirimkan pandangannya atas rantai sebagai suara kepada semua node lainnya. Pendekatan ini menghasilkan intensitas pesan yang lebih tinggi, dan seiring dengan bertambahnya jumlah node, sistem pada akhirnya mungkin mencapai batasnya. Namun, keuntungan terbesar dari konsensus deterministik adalah ketersediaan suara konkret, memungkinkan Anda untuk mengetahui dengan pasti node mana yang memilih fork mana. Hal ini menjamin finalitas rantai yang cepat dan definitif, menjamin bahwa blok tidak dapat mengubah urutannya dan membuatnya dapat diverifikasi.

Untuk menyediakan mekanisme konsensus yang dapat diverifikasi sambil mempertahankan desentralisasi dan struktur tanpa izin, Ethereum telah mencapai keseimbangan antara slot dan epoch. Slot, yang mewakili interval 12 detik, adalah unit dasar di mana validator bertanggung jawab untuk menghasilkan blok. Meskipun konsensus probabilistik yang digunakan pada level slot memungkinkan rantai beroperasi dengan lebih fleksibel dan secara desentralisasi, namun memiliki batasan dalam hal pengurutan definitif dan keverifikasian.

Epoch, yang mencakup 32 slot, memperkenalkan konsensus yang deterministik. Pada tingkat ini, validator memilih untuk memfinalisasi urutan rantai, memastikan kepastian dan membuat rantai dapat diverifikasi. Namun, meskipun struktur deterministik ini memberikan verifikasi melalui suara konkret pada tingkat epoch, ia tidak dapat menawarkan verifikasi penuh dalam epoch itu sendiri karena struktur probabilistik. Untuk mengatasi kesenjangan ini dan memperkuat struktur probabilistik dalam epoch, Ethereum telah mengembangkan solusi yang dikenal sebagai Komite Sinkronisasi.

Protokol Klien Ringan Altair: Komite Sinkronisasi

Komite Sinkronisasi adalah mekanisme yang diperkenalkan dengan upgrade Altair untuk mengatasi keterbatasan konsensus probabilistik Ethereum dan meningkatkan keverifikasian rantai untuk klien ringan. Komite ini terdiri dari 512 validator yang dipilih secara acak yang melayani selama 256 epoch (~27 jam). Validator ini menghasilkan tanda tangan yang mewakili kepala rantai, memungkinkan klien ringan untuk memverifikasi keabsahan rantai tanpa perlu mengunduh data rantai historis. Operasi Komite Sinkronisasi dapat diringkas sebagai berikut:

1. Pembentukan Komite:
   512 validator dipilih secara acak dari semua validator di jaringan. Pemilihan ini secara teratur diperbarui untuk menjaga desentralisasi dan mencegah ketergantungan pada kelompok tertentu.
2. Pembuatan Tanda Tangan:
   Anggota komite menghasilkan tanda tangan yang mewakili keadaan terkini dari rantai. Tanda tangan ini adalah tanda tangan BLS kolektif yang dibuat oleh para anggota dan digunakan untuk memverifikasi validitas rantai.
3. Verifikasi Klien Ringan:
   Klien ringan dapat memverifikasi kebenaran rantai dengan hanya memeriksa tanda tangan dari Komite Sinkronisasi. Hal ini memungkinkan mereka untuk melacak rantai secara aman tanpa harus mengunduh data rantai sebelumnya.

Namun, Komite Sinkronisasi telah menjadi sasaran kritik di beberapa area. Terutama, protokol kekurangan mekanisme untuk memotong validator atas perilaku berbahaya, bahkan jika validator yang dipilih bertindak dengan sengaja melawan protokol. Sebagai hasilnya, banyak yang menganggap Komite Sinkronisasi sebagai risiko keamanan dan menahan diri untuk sepenuhnya mengklasifikasikannya sebagai Protokol Klien Ringan. Namun demikian, keamanan Komite Sinkronisasi telah terbukti secara matematis, dan rincian lebih lanjut dapat ditemukan di artikel ini tentang Sync Committee Slashings.

Ketidakhadiran mekanisme pemotongan dalam protokol bukanlah pilihan desain tetapi kebutuhan yang timbul dari sifat konsensus probabilistik. Konsensus probabilistik tidak memberikan jaminan mutlak tentang apa yang diamati validator. Bahkan jika mayoritas validator melaporkan cabang tertentu sebagai yang lebih berat, masih ada validator yang luar biasa yang mengamati cabang yang berbeda sebagai yang lebih berat. Ketidakpastian ini membuat sulit untuk membuktikan niat jahat dan, dengan demikian, tidak mungkin menghukum perilaku yang salah.

Dalam konteks ini, daripada menyebut Sync Committee sebagai yang tidak aman, akan lebih akurat untuk menggambarkannya sebagai solusi yang tidak efisien. Masalahnya bukan berasal dari desain atau operasi mekanis Sync Committee tetapi dari sifat inheren dari konsensus probabilistik. Karena konsensus probabilistik tidak dapat menawarkan jaminan definitif tentang apa yang diamati oleh node, Sync Committee adalah salah satu solusi terbaik yang dapat dirancang dalam model seperti itu. Namun, ini tidak menghilangkan kelemahan konsensus probabilistik dalam menjamin finalitas rantai. Masalahnya bukan terletak pada mekanisme tetapi dalam struktur konsensus Ethereum saat ini.

Karena keterbatasan ini, ada upaya terus-menerus dalam ekosistem Ethereum untuk merancang kembali mekanisme konsensus dan menerapkan solusi yang memberikan finalitas yang ditentukan secara deterministik dalam periode yang lebih singkat. Proposal seperti Orbit-SSFdan3SFbertujuan untuk mengubah struktur konsensus Ethereum dari dasar, menciptakan sistem yang lebih efektif untuk menggantikan konsensus probabilistik. Pendekatan-pendekatan seperti ini tidak hanya bertujuan untuk memperpendek waktu finalitas rantai, tetapi juga untuk memberikan struktur jaringan yang lebih efisien dan dapat diverifikasi. Komunitas Ethereum terus aktif mengembangkan dan mempersiapkan proposal-proposal ini untuk implementasi di masa depan.

Snarkifikasi Konsensus

Verge bertujuan untuk meningkatkan mekanisme konsensus saat ini dan masa depan Ethereum dengan membuatnya lebih dapat diverifikasi melalui teknologi zk-proof, daripada menggantikannya sepenuhnya. Pendekatan ini bertujuan untuk memodernisasi proses konsensus Ethereum sambil mempertahankan prinsip inti desentralisasi dan keamanannya. Mengoptimalkan semua proses konsensus historis dan saat ini dari rantai dengan teknologi zk memainkan peran penting dalam mencapai tujuan skalabilitas dan efisiensi jangka panjang Ethereum. Operasi mendasar yang digunakan dalam lapisan konsensus Ethereum sangat penting dalam transformasi teknologi ini. Mari kita lihat lebih dekat operasi-operasi ini dan tantangan yang mereka hadapi.

• ECADDs:
  • Tujuan: Operasi ini digunakan untuk menggabungkan kunci publik validator dan sangat penting untuk memastikan keakuratan dan efisiensi dari rantai. Berkat sifat yang dapat digabungkan dari tanda tangan BLS, beberapa tanda tangan dapat digabungkan ke dalam struktur tunggal. Hal ini mengurangi overhead komunikasi dan membuat proses verifikasi pada rantai lebih efisien. Memastikan sinkronisasi di antara kelompok validator besar secara lebih efektif membuat operasi ini menjadi kritis.
  • Tantangan: Seperti yang disebutkan sebelumnya, validator Ethereum memilih urutan rantai selama epoch. Saat ini, Ethereum adalah jaringan dengan sekitar 1,1 juta validator. Jika semua validator mencoba menyebarkan suara mereka secara bersamaan, itu akan menciptakan tekanan yang signifikan pada jaringan. Untuk menghindari hal ini, Ethereum memungkinkan validator untuk memilih berdasarkan slot selama sebuah epoch, di mana hanya 1/32 dari semua validator memilih per slot. Meskipun mekanisme ini mengurangi beban komunikasi jaringan dan membuat konsensus lebih efisien, dengan jumlah validator saat ini, sekitar 34.000 validator memilih dalam setiap slot. Hal ini berarti sekitar 34.000 operasi ECADD per slot.
• Pairings:
  • Tujuan: Operasi perpasangan digunakan untuk memverifikasi tanda tangan BLS, memastikan validitas epok di rantai. Operasi ini memungkinkan verifikasi tanda tangan secara berkelompok. Namun, hal ini tidak ramah terhadap zk, sehingga sangat mahal untuk dibuktikan menggunakan teknologi bukti-zk. Hal ini merupakan tantangan besar dalam menciptakan proses verifikasi terintegrasi dengan teknologi zero-knowledge.
  • Tantangan: Operasi pasangan di Ethereum terbatas hingga maksimal 128 penetapan (tanda tangan yang diagregasi) per slot, mengakibatkan lebih sedikit operasi pasangan dibandingkan dengan ECADDs. Namun, kurangnya keterkaitan zk dalam operasi-operasi ini menimbulkan tantangan signifikan. Membuktikan operasi pasangan dengan bukti-zk ribuan kali lebih mahal daripada membuktikan operasi ECADD [2]. Hal ini membuat penyesuaian operasi pasangan untuk teknologi zero-knowledge menjadi salah satu hambatan terbesar dalam proses verifikasi konsensus Ethereum.
• Hash SHA256:
  • Tujuan: Fungsi hash SHA256 digunakan untuk membaca dan memperbarui status rantai, memastikan integritas data rantai. Namun, kurangnya kesesuaian zk menyebabkan ketidak efisienan dalam proses verifikasi berbasis zk-proof, menjadi hambatan besar bagi tujuan verifikasi Ethereum di masa depan.
  • Tantangan: Fungsi hash SHA256 sering digunakan untuk membaca dan memperbarui status rantai. Namun, ketidakramahannya terhadap zk-kompatibilitas bertentangan dengan tujuan verifikasi berbasis bukti zk Ethereum. Misalnya, antara dua zaman, setiap validator menjalankan STF Lapisan Konsensus Ethereum untuk memperbarui status dengan imbalan dan hukuman berdasarkan kinerja validator selama zaman tersebut. Proses ini sangat bergantung pada fungsi hash SHA256, yang signifikan meningkatkan biaya dalam sistem berbasis bukti zk. Hal ini menciptakan hambatan yang signifikan untuk menyelaraskan mekanisme konsensus Ethereum dengan teknologi zk.

Operasi ECADD, Pairing, dan SHA256 yang digunakan dalam lapisan konsensus saat ini memainkan peran penting dalam tujuan verifikasi Ethereum. Namun, kurangnya kesesuaian dengan zk menimbulkan tantangan signifikan dalam mencapai tujuan ini. Operasi ECADD menciptakan beban yang mahal karena volume tinggi suara validator, sementara operasi Pairing, meskipun jumlahnya lebih sedikit, ribuan kali lebih mahal untuk dibuktikan dengan zk-proofs. Selain itu, ketidakramahan zk dari fungsi hash SHA256 membuat membuktikan transisi keadaan rantai beacon sangat menantang. Masalah-masalah ini menyoroti kebutuhan akan transformasi komprehensif untuk menyelaraskan infrastruktur eksisting Ethereum dengan teknologi zero-knowledge.

Solusi ‘Beam Chain’: Mengubah Lapisan Konsensus Ethereum

Pada 12 November 2024, dalam presentasinya di Devcon, Justin Drake memperkenalkan proposal yang disebut “Beam Chain” yang bertujuan untuk secara mendasar dan komprehensif mengubah Lapisan Konsensus Ethereum. Beacon Chain telah menjadi inti jaringan Ethereum selama hampir lima tahun. Namun, selama periode ini, tidak ada perubahan struktural utama pada Beacon Chain. Sebaliknya, kemajuan teknologi telah berkembang pesat, jauh melampaui sifat statis Beacon Chain.

Dalam presentasinya, Justin Drake menekankan bahwa Ethereum telah belajar pelajaran penting selama lima tahun ini di area-area kritis seperti pemahaman MEV, terobosan dalam teknologi SNARK, dan kesadaran retrospektif tentang kesalahan teknologi. Desain-desain yang dipengaruhi oleh pembelajaran baru ini dikategorikan ke dalam tiga pilar utama: Produksi Blok, Staking, dan Kriptografi. Visual berikut merangkum desain-desain ini dan roadmap yang diusulkan:

• Kotak hijau dan abu-abu mewakili perkembangan bertahap yang dapat diimplementasikan satu per satu setiap tahun. Jenis perbaikan seperti ini, seperti peningkatan sebelumnya, dapat diintegrasikan secara bertahap tanpa mengganggu arsitektur Ethereum yang sudah ada.
• Di sisi lain, kotak merah menandakan perubahan sinergi tinggi, skala besar, dan dasar yang harus diimplementasikan bersama-sama. Menurut Drake, perubahan ini bertujuan untuk meningkatkan kapasitas dan verifikasi Ethereum dalam satu lompatan besar.

Dalam bagian ini, kami telah meneliti Langkah Konsensus, Status, dan Eksekusi The Verge secara rinci, dan salah satu masalah paling menonjol yang disorot selama proses ini adalah penggunaan fungsi hash SHA256 dalam Rantai Beacon Ethereum. Sementara SHA256 memainkan peran sentral dalam memastikan keamanan jaringan dan memproses transaksi, kurangnya kesesuaian dengan zk menjadi hambatan signifikan dalam mencapai tujuan verifikasi Ethereum. Biaya komputasi yang tinggi dan ketidakcocokan dengan teknologi zk membuatnya menjadi masalah kritis yang harus diatasi dalam pengembangan masa depan Ethereum.

Jalan raya Justin Drake, yang disajikan dalam pidatonya di Devcon, membayangkan mengganti SHA256 di Beacon Chain dengan fungsi hash yang bersahabat dengan zk seperti Poseidon. Usulan ini bertujuan untuk memodernisasi lapisan konsensus Ethereum, membuatnya lebih dapat diverifikasi, efisien, dan selaras dengan teknologi zk-proof.

Dalam konteks ini, kita melihat bahwa Ethereum tidak hanya menghadapi tantangan dengan fungsi hash yang tidak bersahabat terhadap zk tetapi juga perlu mengevaluasi kembali tanda tangan digital yang digunakan dalam lapisan konsensusnya untuk keamanan jangka panjang. Dengan kemajuan komputasi kuantum, algoritma tanda tangan digital seperti ECDSA yang saat ini digunakan dapat menghadapi ancaman yang signifikan. Seperti yang dicatat dalam panduan yang diterbitkan oleh NIST, variasi dari ECDSA dengan tingkat keamanan 112-bit akan ditinggalkan mulai tahun 2030 dan dilarang sepenuhnya pada tahun 2035. Hal ini menuntut transisi bagi Ethereum dan jaringan serupa menuju alternatif yang lebih tangguh seperti tanda tangan yang aman terhadap kuantum di masa depan.

Pada titik ini, tanda tangan berbasis hash muncul sebagai solusi tahan kuanta yang dapat memainkan peran kritis dalam mendukung tujuan keamanan dan verifikasi jaringan. Mengatasi kebutuhan ini juga menghilangkan hambatan utama kedua dalam membuat Beacon Chain dapat diverifikasi: Tanda tangan BLS. Salah satu langkah paling signifikan yang dapat diambil Ethereum untuk memastikan keamanan kuanta adalah mengadopsi solusi pasca-kuanta seperti tanda tangan berbasis hash dan SNARK berbasis hash.

Seperti yang disoroti oleh Justin Drake dalampresentasi Devcon ini, fungsi hash secara inheren tahan terhadap komputer kuantum karena bergantung pada resistensi praima-gambar, menjadikannya salah satu blok bangunan fundamental kriptografi modern. Properti ini memastikan bahwa bahkan komputer kuantum tidak dapat dengan efisien membalikkan rekayasa ulang input asli dari hash yang diberikan, menjaga keamanan mereka. Sistem tanda tangan berbasis hash memungkinkan validator dan pemberi kesaksian untuk menghasilkan tanda tangan sepenuhnya berdasarkan fungsi hash, memastikan keamanan pasca-kuantum sambil juga memberikan tingkat verifikasi yang lebih tinggi di seluruh jaringan—terutama jika fungsi hash yang ramah SNARK digunakan. Pendekatan ini tidak hanya meningkatkan keamanan jaringan tetapi juga membuat infrastruktur keamanan jangka panjang Ethereum lebih kokoh dan tahan masa depan.

Sistem ini bergantung pada kombinasi tanda tangan berbasis hash dan SNARK berbasis hash (bukti seperti STARK) untuk membuat skema tanda tangan yang dapat diagregatkan. Tanda tangan yang dapat diagregatkan mengompres ribuan tanda tangan menjadi satu struktur, menguranginya menjadi hanya beberapa ratus kilobita bukti. Kompresi ini secara signifikan mengurangi beban data pada jaringan sambil mempercepat proses verifikasi secara besar-besaran. Misalnya, ribuan tanda tangan validator yang dihasilkan untuk satu slot di Ethereum dapat diwakili oleh satu tanda tangan agregat, menghemat ruang penyimpanan dan daya komputasi.

Namun, fitur paling mencolok dari skema ini adalah agregasi secara rekursif yang tak terbatas. Artinya, satu kelompok tanda tangan dapat digabungkan lebih lanjut di bawah kelompok lain, dan proses ini dapat terus berlanjut melintasi rantai. Dengan mekanisme ini dan mempertimbangkan kemajuan teknologi di masa depan, dapat dikatakan bahwa ini membuka pintu untuk kemungkinan yang saat ini tidak dapat dicapai dengan BLS.

Pemikiran Akhir dan Kesimpulan

Jalur Ethereum menuju verifikasi mewakili pergeseran mendasar dalam teknologi blockchain. Inisiatif Verge menangani ketidakefisienan inti melalui Pohon Verkle untuk verifikasi status dan bukti STARK untuk transisi yang dapat diskalakan.

Salah satu proposal paling ambisius adalah Beam Chain, suatu desain ulang komprehensif dari lapisan konsensus Ethereum. Dengan mengatasi keterbatasan Beacon Chain dan menggabungkan alternatif yang ramah zk, pendekatan ini bertujuan untuk meningkatkan skalabilitas Ethereum sambil mempertahankan prinsip inti desentralisasi dan aksesibilitasnya. Namun, transisi ini juga menyoroti tantangan yang dihadapi Ethereum dalam menyeimbangkan tuntutan komputasi dengan tujuannya untuk menjaga jaringan tanpa izin dan inklusif.

Dengan NIST berencana untuk menghentikan kriptografi kurva elips saat ini pada tahun 2035, Ethereum harus mengadopsi solusi tahan kuanta seperti tanda tangan berbasis hash dan Poseidon. Solusi-solusi ini memiliki kompromi efisiensi mereka sendiri.

Penggunaan STARKs dalam rencana jangka panjang Ethereum lebih menekankan skalabilitas dan verifikasi. Meskipun mereka sangat baik dalam menyediakan bukti transparan dan tahan terhadap kuantum, integrasi mereka memperkenalkan tantangan terkait biaya komputasi sisi prover dan ketidakefisienan data kecil. Hambatan-hambatan ini harus diatasi untuk sepenuhnya mewujudkan visi Ethereum tentang tanpa keadaan dan verifikasi blok yang efisien, memastikan jaringan tetap tangguh di tengah meningkatnya permintaan.

Meskipun kemajuan ini, tantangan kunci tetap ada. Ethereum harus menavigasi masalah kesahabatan zk, skalabilitas konsensus, dan kompleksitas integrasi kriptografi tahan kuanta. Selain itu, kompatibilitas mundur infrastruktur yang ada menimbulkan hambatan praktis yang memerlukan solusi rekayasa yang hati-hati untuk mencegah gangguan bagi pengembang dan pengguna.

Yang membedakan Ethereum bukan hanya inovasi teknisnya tetapi pendekatan iteratifnya dalam memecahkan beberapa masalah terberat dalam blockchain. Langkah ke depan - baik melalui teknologi seperti Beam Chain, Verkle Trees, atau bukti STARK - bergantung pada upaya kolaboratif oleh pengembang, peneliti, dan komunitas yang lebih luas. Kemajuan ini bukan tentang mencapai kesempurnaan dalam semalam tetapi tentang menciptakan dasar untuk internet yang transparan, terdesentralisasi, dan dapat diverifikasi.

Evolusi Ethereum menggarisbawahi perannya sebagai pemain kunci dalam membentuk era Web3. Dengan mengatasi tantangan saat ini dengan solusi praktis, Ethereum semakin mendekati masa depan di mana verifikabilitas, ketahanan kuantum, dan skalabilitas menjadi standar, bukan pengecualian.

Disclaimer:

1. Artikel ini diambil dari [[](https://research.2077.xyz/the-verge-making-ethereum-verifiable-and-sustainable#the-path-to-verifiability)[Penelitian 2077](https://research.2077.xyz/)\]. Semua hak cipta milik penulis asli [Koray Akpinarr]. Jika ada keberatan terhadap cetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata merupakan milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan sebaliknya, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.