Vitalik Artikel Baru: Masa Depan Kemungkinan Protokol Ethereum The Verge

Sebenarnya, kita membutuhkan waktu bertahun-tahun untuk mendapatkan bukti validitas konsensus Ethereum.

Judul Asli: "Possible futures of the Ethereum protocol, part 4: The Verge"

Penulis: Vitalik Buterin

Penerjemah: Mensh, ChainCatcher

 

Terima kasih khusus kepada Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy Ryan Sean Adams, dan Uma Roy atas masukan dan peninjauannya.

Salah satu fitur terkuat dari blockchain adalah siapa pun dapat menjalankan node di komputernya sendiri dan memverifikasi kebenaran blockchain. Bahkan jika 9596 node yang menjalankan konsensus chain (PoW, PoS) langsung setuju untuk mengubah aturan dan mulai memproduksi blok berdasarkan aturan baru, setiap orang yang menjalankan node verifikasi penuh akan menolak untuk menerima chain tersebut. Para pembuat blok yang tidak termasuk dalam kelompok konspirasi ini akan secara otomatis berkumpul pada chain yang masih mengikuti aturan lama, dan terus membangun chain tersebut, sementara pengguna yang sepenuhnya melakukan verifikasi akan mengikuti chain itu.

Ini adalah perbedaan utama antara blockchain dan sistem terpusat. Namun, agar fitur ini berlaku, menjalankan node verifikasi penuh harus benar-benar memungkinkan bagi cukup banyak orang. Ini berlaku untuk pembuat blok (karena jika pembuat blok tidak memverifikasi chain, mereka tidak berkontribusi pada pelaksanaan aturan protokol), juga untuk pengguna biasa. Saat ini, menjalankan node di laptop konsumen (termasuk laptop yang digunakan untuk menulis artikel ini) adalah mungkin, tetapi cukup sulit untuk dilakukan. The Verge bertujuan untuk mengubah situasi ini, membuat biaya komputasi untuk verifikasi chain penuh menjadi sangat rendah, sehingga setiap wallet ponsel, wallet browser, bahkan jam tangan pintar secara default akan melakukan verifikasi.

Roadmap The Verge 2023

Pada awalnya, "Verge" mengacu pada pemindahan penyimpanan status Ethereum ke pohon Verkle—sebuah struktur pohon yang memungkinkan bukti lebih ringkas, memungkinkan verifikasi blok Ethereum tanpa status. Node dapat memverifikasi satu blok Ethereum tanpa harus menyimpan status Ethereum apa pun (saldo akun, kode kontrak, ruang penyimpanan...) di hard disk mereka, dengan biaya beberapa ratus KB data bukti dan beberapa ratus milidetik waktu tambahan untuk memverifikasi satu bukti. Saat ini, Verge mewakili visi yang lebih besar, berfokus pada pencapaian verifikasi efisiensi sumber daya maksimum untuk chain Ethereum, yang tidak hanya mencakup teknologi verifikasi tanpa status, tetapi juga penggunaan SNARK untuk memverifikasi seluruh eksekusi Ethereum.

Selain perhatian jangka panjang pada verifikasi SNARK untuk seluruh chain, masalah baru lainnya adalah apakah pohon Verkle adalah teknologi terbaik. Pohon Verkle rentan terhadap serangan komputer kuantum, jadi jika kita mengganti pohon Merkle Patricia KECCAK saat ini dengan pohon Verkle, kita mungkin harus mengganti pohon itu lagi di masa depan. Metode penggantian pohon Merkle adalah langsung melewati penggunaan cabang Merkle dengan STARK, memasukkannya ke pohon biner. Secara historis, karena overhead dan kompleksitas teknis, metode ini dianggap tidak layak. Namun baru-baru ini, kita melihat Starkware membuktikan 1,7 juta hash Poseidon per detik di laptop, dan dengan munculnya teknologi seperti GKB, waktu pembuktian untuk hash "tradisional" juga semakin singkat. Oleh karena itu, dalam setahun terakhir, "Verge" menjadi lebih terbuka, dengan beberapa kemungkinan.

The Verge: Tujuan Utama

• Klien tanpa status: ruang penyimpanan yang dibutuhkan oleh klien verifikasi penuh dan node beacon tidak boleh melebihi beberapa GB.
• (Jangka panjang) Verifikasi chain penuh (konsensus dan eksekusi) di jam tangan pintar. Unduh beberapa data, verifikasi SNARK, selesai.

Dalam bab ini

• Klien tanpa status: Verkle atau STARKs
• Bukti validitas eksekusi EVM
• Bukti validitas konsensus

Verifikasi Tanpa Status: Verkle atau STARKs

Masalah apa yang ingin kita selesaikan?

Saat ini, klien Ethereum perlu menyimpan ratusan gigabyte data status untuk memverifikasi blok, dan jumlah ini bertambah setiap tahun. Data status mentah bertambah sekitar 30GB per tahun, dan setiap klien harus menyimpan beberapa data tambahan di atasnya untuk memperbarui trie secara efisien.

Ini mengurangi jumlah pengguna yang dapat menjalankan node verifikasi penuh Ethereum: meskipun hard disk besar yang cukup untuk menyimpan semua status Ethereum bahkan sejarah bertahun-tahun tersedia di mana-mana, komputer yang biasanya dibeli orang hanya memiliki beberapa ratus gigabyte ruang penyimpanan. Ukuran status juga membawa gesekan besar pada proses membangun node untuk pertama kalinya: node perlu mengunduh seluruh status, yang bisa memakan waktu berjam-jam atau berhari-hari. Ini menghasilkan berbagai efek berantai. Misalnya, ini sangat meningkatkan kesulitan bagi pembuat node untuk meningkatkan pengaturan node mereka. Secara teknis, ini dapat dilakukan tanpa downtime—memulai klien baru, menunggu sinkronisasi, lalu mematikan klien lama dan mentransfer kunci—tetapi dalam praktiknya, ini sangat kompleks secara teknis.

Bagaimana cara kerjanya?

Verifikasi tanpa status adalah teknologi yang memungkinkan node memverifikasi blok tanpa memiliki seluruh status. Sebagai gantinya, setiap blok disertai dengan sebuah witness, yang mencakup: (i) nilai, kode, saldo, penyimpanan di lokasi tertentu dari status yang akan diakses blok tersebut; (ii) bukti kriptografi yang membuktikan nilai-nilai tersebut benar.

Pada kenyataannya, menerapkan verifikasi tanpa status memerlukan perubahan pada struktur pohon status Ethereum. Ini karena pohon Merkle Patricia saat ini sangat tidak ramah untuk menerapkan skema bukti kriptografi apa pun, terutama dalam kasus terburuk. Baik cabang Merkle "asli", maupun kemungkinan "dibungkus" dengan STARK, sama-sama bermasalah. Kesulitan utama berasal dari beberapa kelemahan MPT:

1. Ini adalah pohon heksadesimal (setiap node memiliki 16 anak). Ini berarti, dalam pohon berukuran N, satu bukti rata-rata membutuhkan 32*(16-1)*log16(N) = 120*log2(N) byte, atau sekitar 3840 byte dalam pohon dengan 2^32 entri. Untuk pohon biner, hanya membutuhkan 32*(2-1)*log2(N) = 32*log2(N) byte, atau sekitar 1024 byte.

2. Kode tidak di-Merkle-kan. Ini berarti untuk membuktikan akses ke kode akun mana pun, seluruh kode harus disediakan, maksimal 24000 byte.

 

Kita dapat menghitung kasus terburuk sebagai berikut:

30000000 gas / 2400 (biaya pembacaan akun dingin) * (5 * 488 + 24000) = 330000000 byte

Biaya cabang sedikit lebih rendah (menggunakan 5*480 menggantikan 8*480), karena ketika ada banyak cabang, bagian atasnya akan berulang. Namun demikian, jumlah data yang harus diunduh dalam satu slot tetap tidak realistis. Jika kita mencoba membungkusnya dengan STARK, kita akan menghadapi dua masalah: (i) KECCAK relatif tidak ramah untuk STARK; (ii) 330MB data berarti kita harus membuktikan 5 juta panggilan fungsi round KECCAK, yang mungkin tidak dapat dibuktikan oleh semua perangkat keras kecuali perangkat keras konsumen terkuat, bahkan jika kita dapat membuat STARK membuktikan KECCAK lebih efisien.

Jika kita langsung mengganti pohon heksadesimal dengan pohon biner, dan melakukan Merkleisasi tambahan pada kode, maka kasus terburuknya kira-kira menjadi 30000000/2400*32*(32-14+8) = 10400000 byte (14 adalah pengurangan untuk bit cabang 2^14 yang redundan, dan 8 adalah panjang bukti masuk ke daun kode). Perlu dicatat bahwa ini memerlukan perubahan biaya gas, mengenakan biaya untuk setiap blok kode yang diakses; EIP-4762 melakukan hal ini. Kapasitas 10,4 MB jauh lebih baik, tetapi untuk banyak node, data yang harus diunduh dalam satu slot masih terlalu banyak. Oleh karena itu, kita perlu memperkenalkan teknologi yang lebih kuat. Dalam hal ini, ada dua solusi utama: pohon Verkle dan pohon hash biner STARKed.

Pohon Verkle

Pohon Verkle menggunakan komitmen vektor berbasis kurva eliptik untuk menghasilkan bukti yang lebih pendek. Kuncinya adalah, berapapun lebar pohonnya, setiap bagian bukti untuk hubungan induk-anak hanya 32 byte. Satu-satunya batasan lebar pohon adalah, jika pohon terlalu lebar, efisiensi komputasi bukti akan menurun. Implementasi yang diusulkan untuk Ethereum memiliki lebar 256.

Oleh karena itu, ukuran satu cabang dalam bukti menjadi 32 - 1og256(N) = 4*log2(N) byte. Jadi, ukuran bukti maksimum secara teori kira-kira 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 byte (karena distribusi status yang tidak merata, hasil perhitungan sebenarnya sedikit berbeda, tetapi sebagai pendekatan pertama ini cukup baik).

Perlu juga dicatat bahwa dalam semua contoh di atas, "kasus terburuk" ini bukanlah yang terburuk: kasus yang lebih buruk adalah penyerang sengaja "menambang" dua alamat sehingga mereka memiliki prefiks bersama yang panjang di pohon, dan membaca data dari salah satu alamat tersebut, yang dapat memperpanjang panjang cabang dalam kasus terburuk hingga 2 kali lipat. Namun bahkan dalam kasus seperti itu, panjang bukti terburuk pohon Verkle adalah 2,6MB, yang secara umum masih dapat diterima dibandingkan dengan data verifikasi saat ini.

Kita juga memanfaatkan catatan ini untuk melakukan hal lain: kita membuat biaya akses ke ruang penyimpanan "berdekatan" menjadi sangat murah: baik itu banyak blok kode dari kontrak yang sama, atau slot penyimpanan yang berdekatan. EIP-4762 memberikan definisi adjacency, hanya mengenakan biaya 200 gas untuk akses adjacency. Dalam kasus akses adjacency, ukuran bukti terburuk menjadi 30000000 / 200*32 - 4800800 byte, yang masih dalam kisaran toleransi. Jika demi keamanan kita ingin mengurangi nilai ini, kita bisa sedikit menaikkan biaya akses adjacency.

Pohon Hash Biner STARKed

Teknologi ini cukup jelas: Anda hanya perlu membuat pohon biner, mendapatkan bukti maksimal 10,4 MB, membuktikan nilai dalam blok, lalu mengganti bukti dengan STARK. Dengan demikian, bukti itu sendiri hanya berisi data yang dibuktikan, ditambah overhead tetap 100-300kB dari STARK yang sebenarnya.

Tantangan utama di sini adalah waktu verifikasi. Kita dapat melakukan perhitungan yang hampir sama seperti di atas, hanya saja yang kita hitung adalah jumlah hash. Satu blok 10,4 MB berarti 330000 hash. Jika kita menambahkan kemungkinan penyerang "menambang" alamat dengan prefiks umum yang panjang di pohon, maka jumlah hash terburuk akan mencapai sekitar 660000 hash. Jadi, jika kita dapat membuktikan 200.000 hash per detik, itu tidak masalah.

Di laptop konsumen dengan fungsi hash Poseidon, angka-angka ini sudah tercapai, dan fungsi hash Poseidon memang dirancang khusus untuk ramah STARK. Namun, sistem Poseidon masih relatif belum matang, sehingga banyak orang belum mempercayai keamanannya. Oleh karena itu, ada dua jalan realistis ke depan:

1. Melakukan analisis keamanan besar-besaran pada Poseidon dengan cepat, dan cukup familiar untuk diterapkan di L1
2. Menggunakan fungsi hash yang lebih "konservatif", seperti SHA256 atau BLAKE

Jika ingin membuktikan fungsi hash konservatif, lingkaran STARK Starkware pada saat penulisan ini hanya dapat membuktikan 10-30k hash per detik di laptop konsumen. Namun, teknologi STARK berkembang pesat. Bahkan hari ini, teknologi berbasis GKR menunjukkan peningkatan kecepatan hingga kisaran 100-200k.

Kasus Penggunaan Witness Selain Verifikasi Blok

Selain verifikasi blok, ada tiga kasus penggunaan utama lain yang membutuhkan verifikasi tanpa status yang lebih efisien:

• Mempool: Ketika transaksi disiarkan, node di jaringan P2P perlu memverifikasi validitas transaksi sebelum menyiarkannya kembali. Saat ini, verifikasi termasuk memeriksa tanda tangan, saldo yang cukup, dan nonce yang benar. Di masa depan (misalnya, dengan native account abstraction seperti EIP-7701), ini mungkin melibatkan menjalankan beberapa kode EVM yang melakukan beberapa akses status. Jika node tanpa status, transaksi perlu disertai bukti status objek yang dibuktikan.
• Daftar inklusi: Ini adalah fitur yang diusulkan yang memungkinkan validator proof-of-stake (mungkin yang lebih kecil dan tidak kompleks) memaksa blok berikutnya untuk memasukkan transaksi, terlepas dari keinginan pembuat blok (yang mungkin lebih besar dan kompleks). Ini akan mengurangi kemampuan pihak berkuasa untuk memanipulasi blockchain dengan menunda transaksi. Namun, ini memerlukan validator memiliki cara untuk memverifikasi validitas transaksi dalam daftar inklusi.
• Light client: Jika kita ingin pengguna mengakses chain melalui wallet (seperti Metamask, Rainbow, Rabby, dll.), mereka perlu menjalankan light client (seperti Helios). Modul inti Helios memberikan state root yang telah diverifikasi kepada pengguna. Untuk pengalaman tanpa kepercayaan penuh, pengguna perlu menyediakan bukti untuk setiap panggilan RPC yang mereka lakukan (misalnya, untuk permintaan panggilan Ethereum, pengguna perlu membuktikan semua status yang diakses selama panggilan).

Semua kasus penggunaan ini memiliki kesamaan: mereka membutuhkan cukup banyak bukti, tetapi setiap bukti sangat kecil. Oleh karena itu, bukti STARK tidak masuk akal untuk mereka; sebaliknya, pendekatan paling realistis adalah menggunakan cabang Merkle secara langsung. Keuntungan lain dari cabang Merkle adalah dapat diperbarui: dengan bukti untuk objek status X yang berakar pada blok B, jika menerima sub-blok B2 dan witness-nya, bukti dapat diperbarui agar berakar pada blok B2. Bukti Verkle juga dapat diperbarui secara native.

Apa hubungan dengan penelitian yang ada:

• Verkle trees
• Makalah asli John Kuszmaul tentang pohon Verkle
• Starkware
• Makalah Poseidon2
• Ajtai (fungsi hash cepat alternatif berbasis hardness lattice)
• Verkle.info

Apa lagi yang bisa dilakukan?

Pekerjaan utama yang tersisa adalah

1. Analisis lebih lanjut tentang konsekuensi EIP-4762 (perubahan biaya gas tanpa status)

2. Lebih banyak pekerjaan untuk menyelesaikan dan menguji program transisi, yang merupakan bagian utama dari kompleksitas implementasi lingkungan tanpa status apa pun

3. Analisis keamanan lebih lanjut untuk Poseidon, Ajtai, dan fungsi hash "ramah STARK" lainnya

4. Pengembangan lebih lanjut fitur protokol STARK yang sangat efisien untuk hash "konservatif" (atau "tradisional"), misalnya berdasarkan pendekatan Binius atau GKR.

Selain itu, kita akan segera memutuskan untuk memilih salah satu dari tiga opsi berikut: (i) pohon Verkle, (ii) fungsi hash ramah STARK, dan (iii) fungsi hash konservatif. Karakteristik mereka dapat dirangkum dalam tabel berikut:

Selain "angka utama" ini, ada beberapa pertimbangan penting lainnya:

• Saat ini, kode pohon Verkle sudah cukup matang. Selain Verkle, menggunakan kode lain akan menunda deployment, kemungkinan besar menunda hard fork. Ini juga tidak masalah, terutama jika kita membutuhkan waktu tambahan untuk analisis fungsi hash atau implementasi validator, atau jika kita memiliki fitur penting lain yang ingin kita masukkan ke Ethereum lebih awal.
• Menggunakan hash untuk memperbarui state root lebih cepat daripada menggunakan pohon Verkle. Ini berarti metode berbasis hash dapat mengurangi waktu sinkronisasi full node.
• Pohon Verkle memiliki sifat pembaruan witness yang menarik—witness pohon Verkle dapat diperbarui. Sifat ini berguna untuk mempool, daftar inklusi, dan kasus penggunaan lain, serta dapat membantu meningkatkan efisiensi implementasi: jika objek status diperbarui, witness lapisan kedua terakhir dapat diperbarui tanpa membaca konten lapisan terakhir.
• Pohon Verkle lebih sulit untuk dibuktikan dengan SNARK. Jika kita ingin ukuran bukti terus dikurangi hingga beberapa ribu byte, bukti Verkle akan membawa beberapa kesulitan. Ini karena verifikasi bukti Verkle memperkenalkan banyak operasi 256-bit, yang mengharuskan sistem bukti memiliki overhead besar, atau memiliki struktur internal khusus yang mencakup bagian bukti Verkle 256-bit. Ini bukan masalah untuk tanpa status itu sendiri, tetapi membawa lebih banyak kesulitan.

Jika kita ingin mendapatkan pembaruan witness Verkle dengan cara yang aman terhadap kuantum dan cukup efisien, pendekatan lain yang mungkin adalah pohon Merkle berbasis lattice.

Jika dalam kasus terburuk, efisiensi sistem bukti tidak cukup tinggi, kita juga dapat memanfaatkan alat tak terduga berupa multi-dimensional gas: menetapkan batas gas terpisah untuk (i) calldata; (ii) komputasi; (iii) akses status, dan mungkin sumber daya berbeda lainnya. Multi-dimensional gas menambah kompleksitas, tetapi sebagai gantinya, membatasi rasio antara kasus rata-rata dan terburuk dengan lebih ketat. Dengan multi-dimensional gas, jumlah cabang maksimum yang perlu dibuktikan secara teori dapat dikurangi dari 12500 menjadi misalnya 3000. Ini akan membuat BLAKE3 bahkan hari ini (hampir) cukup.

Multi-dimensional gas memungkinkan batas sumber daya blok lebih mendekati batas sumber daya perangkat keras dasar

Alat tak terduga lainnya adalah menunda perhitungan state root hingga setelah slot blok. Dengan demikian, kita memiliki waktu 12 detik penuh untuk menghitung state root, yang berarti bahkan dalam kasus paling ekstrem, waktu pembuktian 60000 hash per detik sudah cukup, sekali lagi membuat BLAKE3 hanya cukup.

Kekurangan pendekatan ini adalah menambah latensi light client satu slot, tetapi ada teknik yang lebih cerdik untuk mengurangi latensi ini hanya menjadi latensi pembuatan bukti. Misalnya, bukti dapat disiarkan di jaringan segera setelah dihasilkan oleh node mana pun, tanpa menunggu blok berikutnya.

Bagaimana interaksinya dengan bagian lain dari roadmap?

Menyelesaikan masalah tanpa status sangat meningkatkan kesulitan staking solo. Jika ada teknologi yang dapat menurunkan saldo minimum staking solo, seperti Orbit SSF atau kebijakan lapisan aplikasi seperti staking squad, ini akan menjadi lebih layak.

Jika EOF juga diperkenalkan, analisis multi-dimensional gas menjadi lebih mudah. Ini karena kompleksitas utama eksekusi multi-dimensional gas berasal dari penanganan subpanggilan yang tidak meneruskan seluruh gas induk, sedangkan EOF hanya perlu membuat subpanggilan semacam itu ilegal, sehingga masalah ini menjadi sepele (dan native account abstraction akan memberikan alternatif dalam protokol untuk penggunaan gas parsial saat ini).

Ada juga sinergi penting antara verifikasi tanpa status dan penghapusan riwayat. Saat ini, klien harus menyimpan hampir 1TB data riwayat; data ini beberapa kali lipat lebih besar dari data status. Bahkan jika klien tanpa status, kecuali kita dapat membebaskan klien dari tanggung jawab menyimpan data riwayat, impian klien hampir tanpa penyimpanan tidak akan terwujud. Langkah pertama dalam hal ini adalah EIP-4444, yang juga berarti menyimpan data riwayat di torrents atau Portal Network.

Bukti Validitas Eksekusi EVM

Masalah apa yang ingin kita selesaikan?

Tujuan jangka panjang verifikasi blok Ethereum sangat jelas—harus memungkinkan untuk memverifikasi blok Ethereum dengan: (i) mengunduh blok, atau bahkan hanya sebagian kecil dari sampling data availability blok; (ii) memverifikasi satu bukti kecil bahwa blok tersebut valid. Ini akan menjadi operasi dengan konsumsi sumber daya sangat rendah, dapat dilakukan di klien mobile, wallet browser, bahkan di chain lain (tanpa bagian data availability).

Untuk mencapai ini, diperlukan pembuktian SNARK atau STARK untuk (i) lapisan konsensus (yaitu proof-of-stake) dan (ii) lapisan eksekusi (yaitu EVM). Yang pertama sendiri adalah tantangan, dan harus diselesaikan seiring perbaikan berkelanjutan pada lapisan konsensus (misalnya, untuk single-slot finality). Yang kedua membutuhkan bukti eksekusi EVM.

Apa itu, bagaimana cara kerjanya?

Secara formal, dalam spesifikasi Ethereum, EVM didefinisikan sebagai fungsi transformasi status: Anda memiliki status awal S, sebuah blok B, Anda menghitung status akhir S' = STF(S, B). Jika pengguna menggunakan light client, mereka tidak memiliki S dan S' secara lengkap, bahkan E; sebaliknya, mereka memiliki state root awal R, state root akhir R', dan hash blok H.

• Input publik: state root awal R, state root akhir R', hash blok H
• Input privat: isi blok B, objek dalam status yang diakses oleh blok Q, objek yang sama setelah eksekusi blok Q', bukti status (seperti cabang Merkle) P
• Klaim 1: P adalah bukti valid yang membuktikan Q mencakup bagian tertentu dari status yang diwakili oleh R
• Klaim 2: Jika menjalankan STF pada Q, (i) proses eksekusi hanya mengakses objek dalam Q, (ii) blok valid, (iii) hasilnya adalah Q'
• Klaim 3: Jika menggunakan informasi dari Q' dan P untuk menghitung ulang state root baru, hasilnya adalah R'

Jika kondisi ini terpenuhi, maka kita dapat memiliki light client yang sepenuhnya memverifikasi eksekusi EVM Ethereum. Ini membuat sumber daya klien sudah sangat rendah. Untuk mencapai light client Ethereum yang benar-benar sepenuhnya memverifikasi, kita juga perlu melakukan hal yang sama untuk konsensus.

Implementasi bukti validitas untuk komputasi EVM sudah ada, dan banyak digunakan di L2. Namun, agar bukti validitas EVM dapat diterapkan di L1, masih banyak pekerjaan yang harus dilakukan.

Apa hubungan dengan penelitian yang ada?

• EFPSE ZK-EVM (sudah tidak digunakan karena ada pilihan yang lebih baik)
• Zeth, yang bekerja dengan mengkompilasi EVM ke RISC-0 ZK-VM
• Proyek verifikasi formal ZK-EVM

Apa lagi yang bisa dilakukan?

Saat ini, bukti validitas sistem pencatatan elektronik memiliki dua kekurangan: keamanan dan waktu verifikasi.

Bukti validitas yang aman harus memastikan SNARK benar-benar memverifikasi komputasi EVM, dan tidak ada celah. Dua teknik utama untuk meningkatkan keamanan adalah multi-validator dan verifikasi formal. Multi-validator berarti ada beberapa implementasi bukti validitas yang ditulis secara independen, seperti ada beberapa klien; jika sebuah blok dibuktikan oleh subset cukup besar dari implementasi tersebut, klien akan menerima blok tersebut. Verifikasi formal melibatkan penggunaan alat yang biasanya digunakan untuk membuktikan teorema matematika, seperti Lean4, untuk membuktikan bukti validitas hanya menerima eksekusi yang benar dari spesifikasi EVM dasar (misalnya EVM K semantics atau spesifikasi eksekusi Ethereum yang ditulis dalam python (EELS)).

Waktu verifikasi yang cukup cepat berarti setiap blok Ethereum dapat diverifikasi dalam waktu kurang dari 4 detik. Saat ini, kita masih jauh dari target ini, meskipun kita sudah lebih dekat daripada yang dibayangkan dua tahun lalu. Untuk mencapai target ini, kita perlu membuat kemajuan di tiga arah:

• Paralelisasi—Saat ini, validator EVM tercepat rata-rata dapat membuktikan satu blok Ethereum dalam 15 detik. Ini dicapai dengan paralelisasi di ratusan GPU, lalu menggabungkan pekerjaan mereka di akhir. Secara teori, kita sepenuhnya tahu bagaimana membuat validator EVM yang dapat membuktikan komputasi dalam waktu O(log(N)): satu GPU menangani setiap langkah, lalu membuat "pohon agregasi":

Mewujudkan ini memiliki tantangan. Bahkan dalam kasus terburuk, yaitu satu transaksi besar mengisi seluruh blok, pembagian komputasi tidak dapat dilakukan per transaksi, melainkan harus per opcode (opcode dari EVM atau RISC-V atau VM dasar lainnya). Memastikan "memori" VM tetap konsisten di antara bagian-bagian bukti adalah tantangan utama dalam implementasi. Namun, jika kita dapat mewujudkan pembuktian rekursif semacam ini, kita tahu bahwa setidaknya masalah latensi pembuktian telah teratasi, bahkan jika tidak ada perbaikan lain.

• Optimasi sistem bukti—Sistem bukti baru seperti Orion, Binius, GRK, dan lainnya kemungkinan besar akan secara signifikan memperpendek waktu verifikasi komputasi umum.
• Perubahan biaya gas EVM lainnya—Banyak hal di EVM dapat dioptimalkan agar lebih ramah bagi pembuktian, terutama dalam kasus terburuk. Jika penyerang dapat membangun blok yang memblokir pembuktian selama sepuluh menit, maka membuktikan satu blok Ethereum biasa dalam 4 detik tidak cukup. Perubahan EVM yang diperlukan dapat dibagi menjadi beberapa kategori:
• Perubahan biaya gas—Jika suatu operasi membutuhkan waktu lama untuk dibuktikan, maka meskipun komputasinya relatif cepat, biaya gasnya harus tinggi. EIP-7667 diajukan untuk menangani masalah terburuk ini: secara signifikan meningkatkan biaya gas untuk fungsi hash (tradisional), karena opcode dan precompile-nya relatif murah. Untuk mengimbangi kenaikan biaya gas ini, kita dapat menurunkan biaya gas untuk opcode EVM yang biaya pembuktiannya relatif rendah, sehingga throughput rata-rata tetap sama.
• Pergantian struktur data—Selain mengganti pohon status dengan metode yang lebih ramah STARK, kita juga perlu mengganti daftar transaksi, pohon receipt, dan struktur lain yang mahal untuk dibuktikan. EIP oleh Etan Kissling yang memindahkan struktur transaksi dan receipt ke SSZ adalah langkah ke arah ini.

Selain itu, dua alat yang disebutkan di bagian sebelumnya (multi-dimensional gas dan state root tertunda) juga dapat membantu di sini. Namun, perlu dicatat bahwa, berbeda dengan verifikasi tanpa status, penggunaan dua alat ini berarti kita sudah memiliki teknologi yang cukup untuk menyelesaikan pekerjaan yang kita butuhkan saat ini, dan bahkan dengan teknologi ini, verifikasi ZK-EVM penuh tetap membutuhkan lebih banyak pekerjaan—hanya saja pekerjaan yang dibutuhkan lebih sedikit.

Satu hal yang belum disebutkan di atas adalah perangkat keras pembuktian: menggunakan GPU, FPGA, dan ASIC untuk menghasilkan bukti lebih cepat. Fabric Cryptography, Cysic, dan Accseal adalah tiga perusahaan yang membuat kemajuan di bidang ini. Ini sangat berharga untuk L2, tetapi tidak mungkin menjadi pertimbangan utama untuk L1, karena ada keinginan kuat agar L1 tetap sangat terdesentralisasi, yang berarti pembangkitan bukti harus berada dalam jangkauan wajar pengguna Ethereum, dan tidak boleh dibatasi oleh perangkat keras satu perusahaan. L2 dapat membuat trade-off yang lebih agresif.

Di bidang-bidang ini, masih banyak pekerjaan yang harus dilakukan:

• Paralelisasi pembuktian memerlukan bagian-bagian berbeda dari sistem bukti dapat "berbagi memori" (seperti lookup table). Kita tahu tekniknya, tetapi perlu diimplementasikan.
• Kita perlu melakukan lebih banyak analisis untuk menemukan set perubahan biaya gas ideal, guna meminimalkan waktu verifikasi dalam kasus terburuk.
• Kita perlu melakukan lebih banyak pekerjaan pada sistem bukti

Biaya yang mungkin adalah:

• Keamanan vs waktu validator: Jika memilih fungsi hash yang lebih agresif, sistem bukti yang lebih kompleks, atau asumsi keamanan yang lebih agresif atau desain lain, waktu validator dapat dipersingkat.
• Desentralisasi vs waktu validator: Komunitas perlu menyepakati "spesifikasi" perangkat keras validator yang ditargetkan. Apakah boleh validator adalah entitas besar? Apakah kita ingin laptop konsumen kelas atas dapat membuktikan satu blok Ethereum dalam 4 detik? Atau di antara keduanya?
• Tingkat pelanggaran kompatibilitas ke belakang: Kekurangan di bidang lain dapat diimbangi dengan perubahan biaya gas yang lebih agresif, tetapi ini lebih mungkin secara tidak proporsional meningkatkan biaya beberapa aplikasi, memaksa pengembang untuk menulis ulang dan menerapkan ulang kode agar tetap layak secara ekonomi. Demikian pula, kedua alat ini juga memiliki kompleksitas dan kekurangan sendiri.

Bagaimana interaksinya dengan bagian lain dari roadmap?

Teknologi inti yang diperlukan untuk membuktikan validitas EVM L1 sangat banyak berbagi dengan dua bidang lain:

• Bukti validitas L2 (yaitu "ZK rollup")
• Metode "STARK binary hash proof" tanpa status

Jika bukti validitas berhasil diterapkan di L1, kita akhirnya dapat mewujudkan staking solo dengan mudah: bahkan komputer terlemah (termasuk ponsel atau jam tangan pintar) dapat melakukan staking. Ini semakin meningkatkan nilai penyelesaian batasan staking solo lainnya (seperti batas minimum 32ETH).

Selain itu, bukti validitas EVM L1 dapat secara signifikan meningkatkan batas gas L1.

Bukti Validitas Konsensus

Masalah apa yang ingin kita selesaikan?

Jika kita ingin sepenuhnya memverifikasi satu blok Ethereum dengan SNARK, maka eksekusi EVM bukan satu-satunya bagian yang perlu kita buktikan. Kita juga perlu membuktikan konsensus, yaitu bagian sistem yang menangani deposit, penarikan, tanda tangan, pembaruan saldo validator, dan elemen lain dari bagian proof-of-stake Ethereum.

Konsensus jauh lebih sederhana daripada EVM, tetapi tantangannya adalah, kita tidak memiliki konvolusi EVM L2, jadi bagaimanapun juga, sebagian besar pekerjaan harus dilakukan. Oleh karena itu, implementasi bukti konsensus Ethereum mana pun perlu "dibangun dari awal", meskipun sistem bukti itu sendiri dapat dibangun di atas pekerjaan bersama.

Apa itu, bagaimana cara kerjanya?

Beacon chain didefinisikan sebagai fungsi transformasi status, seperti EVM. Fungsi transformasi status terutama terdiri dari tiga bagian:

• ECADD (untuk memverifikasi tanda tangan BLS)
• Pairing (untuk memverifikasi tanda tangan BLS)
• Hash SHA256 (untuk membaca dan memperbarui status)

Di setiap blok, kita perlu membuktikan 1-16 ECADD BLS12-381 untuk setiap validator (mungkin lebih dari satu, karena tanda tangan dapat termasuk dalam beberapa set). Ini dapat diimbangi dengan teknik prekomputasi subset, jadi kita dapat mengatakan setiap validator hanya perlu membuktikan satu ECADD BLS12-381. Saat ini, ada 30000 tanda tangan validator per slot. Di masa depan, dengan implementasi single-slot finality, jumlah validator per slot bisa meningkat menjadi 1 juta jika kita mengambil pendekatan "brute force". Sementara itu, jika menggunakan Orbit SSF, jumlah validator akan tetap di 32768, atau bahkan turun ke 8192.

Bagaimana agregasi BLS bekerja: verifikasi tanda tangan total hanya membutuhkan satu ECADD per peserta, bukan satu ECMUL. Namun 30000 ECADD tetap merupakan jumlah bukti yang besar.

Untuk pairing, saat ini ada maksimal 128 bukti per slot, artinya perlu memverifikasi 128 pairing. Dengan ElP-7549 dan modifikasi lebih lanjut, per slot dapat dikurangi menjadi 16. Jumlah pairing sedikit, tetapi biayanya sangat tinggi: menjalankan (atau membuktikan) satu pairing memakan waktu ribuan kali lebih lama daripada ECADD.

Salah satu tantangan utama dalam membuktikan operasi BLS12-381 adalah, tidak ada kurva dengan order sama dengan ukuran field BLS12-381, yang menambah overhead besar pada sistem bukti mana pun. Di sisi lain, pohon Verkle yang diusulkan untuk Ethereum dibangun dengan kurva Bandersnatch, yang membuat BLS12-381 sendiri menjadi kurva dalam sistem SNARK yang digunakan untuk membuktikan cabang Verkle. Implementasi sederhana dapat membuktikan 100 penjumlahan G1 per detik; untuk membuat kecepatan bukti cukup cepat, hampir pasti diperlukan teknik canggih seperti GKR.

Untuk hash SHA256, kasus terburuk saat ini adalah blok transisi epoch, di mana seluruh pohon saldo pendek validator dan banyak saldo validator akan diperbarui. Pohon saldo pendek setiap validator hanya satu byte, jadi ada 1 MB data yang akan di-hash ulang. Ini setara dengan 32768 panggilan SHA256. Jika ada seribu validator dengan saldo di atas atau di bawah ambang batas, perlu memperbarui saldo efektif dalam catatan validator, ini setara dengan seribu cabang Merkle, jadi mungkin perlu sepuluh ribu hash. Mekanisme shuffling membutuhkan 90 bit per validator (jadi 11 MB data), tetapi ini dapat dihitung kapan saja dalam satu epoch. Dalam single-slot finality, angka-angka ini bisa naik atau turun tergantung pada kasusnya. Shuffling menjadi tidak perlu, meskipun Orbit mungkin mengembalikan kebutuhan ini sampai batas tertentu.

Tantangan lain adalah perlunya mengambil ulang semua status validator, termasuk kunci publik, untuk memverifikasi satu blok. Untuk 1 juta validator, hanya membaca kunci publik membutuhkan 48 juta byte, ditambah cabang Merkle. Ini berarti setiap epoch membutuhkan jutaan hash. Jika kita harus membuktikan validitas PoS, pendekatan realistis adalah semacam perhitungan verifikasi inkremental: menyimpan struktur data terpisah dalam sistem bukti, yang dioptimalkan untuk pencarian efisien, dan membuktikan pembaruan pada struktur tersebut.

Singkatnya, tantangannya banyak. Untuk mengatasinya secara paling efisien, kemungkinan besar diperlukan redesain mendalam pada beacon chain, yang mungkin dilakukan bersamaan dengan peralihan ke single-slot finality. Redesain ini mungkin mencakup:

• Perubahan fungsi hash: Saat ini menggunakan fungsi hash SHA256 "penuh", sehingga karena padding, setiap panggilan setara dengan dua panggilan fungsi kompresi dasar. Jika diganti dengan fungsi kompresi SHA256, kita setidaknya mendapat keuntungan 2x. Jika diganti dengan Poseidon, kita mungkin mendapat keuntungan 100x, sehingga masalah hash kita benar-benar teratasi (setidaknya untuk hash): pada 1,7 juta hash per detik (54MB), bahkan satu juta catatan validator dapat "dibaca" ke dalam bukti dalam beberapa detik.
• Jika Orbit, langsung menyimpan catatan validator yang sudah di-shuffle: Jika memilih sejumlah validator (misalnya 8192 atau 32768) sebagai komite untuk slot tertentu, langsung menempatkan mereka bersebelahan dalam status, sehingga hanya perlu hash minimal untuk membaca semua kunci publik validator ke dalam bukti. Ini juga memungkinkan pembaruan saldo dilakukan secara efisien.
• Agregasi tanda tangan: Skema agregasi tanda tangan berkinerja tinggi mana pun akan melibatkan semacam pembuktian rekursif, di mana node berbeda di jaringan membuktikan subset tanda tangan secara menengah. Ini secara alami membagi pekerjaan pembuktian ke banyak node di jaringan, sangat mengurangi beban "validator akhir".
• Skema tanda tangan lain: Untuk tanda tangan Lamport+Merkle, kita perlu 256 + 32 hash untuk memverifikasi satu tanda tangan; dikalikan 32768 penanda tangan, menjadi 9437184 hash. Setelah optimasi skema tanda tangan, hasil ini dapat diperbaiki dengan faktor konstan kecil. Jika kita menggunakan Poseidon, ini dapat dibuktikan dalam satu slot. Namun, dalam praktiknya, menggunakan skema agregasi rekursif akan lebih cepat.

Apa hubungan dengan penelitian yang ada?

• Bukti konsensus Ethereum ringkas (hanya untuk sync committee)
• Helios dalam SP1 ringkas
• Precompile BLS12-381 ringkas
• Verifikasi tanda tangan agregat BLS berbasis Halo2

Apa lagi yang harus dilakukan, bagaimana trade-off-nya:

Sebenarnya, kita membutuhkan waktu bertahun-tahun untuk mendapatkan bukti validitas konsensus Ethereum. Ini sejalan dengan waktu yang dibutuhkan untuk mewujudkan single-slot finality, Orbit, perubahan skema tanda tangan, dan analisis keamanan yang diperlukan untuk cukup percaya diri menggunakan fungsi hash "agresif" seperti Poseidon. Oleh karena itu, langkah paling bijak adalah menyelesaikan masalah lain ini, dan mempertimbangkan ramah STARK saat menyelesaikan masalah tersebut.

Trade-off utama kemungkinan besar adalah urutan operasi, antara pendekatan bertahap untuk mereformasi lapisan konsensus Ethereum dan pendekatan "sekali ubah banyak" yang lebih agresif. Untuk EVM, pendekatan bertahap masuk akal karena meminimalkan gangguan pada kompatibilitas ke belakang. Untuk lapisan konsensus, dampak pada kompatibilitas ke belakang lebih kecil, dan ada manfaat dari pemikiran ulang yang lebih "menyeluruh" tentang detail cara beacon chain dibangun, untuk mengoptimalkan ramah SNARK dengan cara terbaik.

Bagaimana interaksinya dengan bagian lain dari roadmap?

Saat melakukan redesain jangka panjang pada PoS Ethereum, ramah STARK harus menjadi pertimbangan utama, terutama single-slot finality, Orbit, perubahan skema tanda tangan, dan agregasi tanda tangan.