Sebelumnya baca: "Vitalik tentang Kemungkinan Masa Depan ETH (Bagian 1): The Merge", "Vitalik tentang Kemungkinan Masa Depan ETH (Bagian 2): The Surge", "Vitalik tentang Kemungkinan Masa Depan ETH (Bagian 3): The Scourge"

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

Salah satu fitur terkuat dari Blokchain adalah bahwa siapa pun dapat menjalankan Node di komputernya sendiri dan memverifikasi kebenaran Blokchain. Bahkan jika 9596 Node yang menjalankan konsensus (PoW, PoS) segera setuju untuk mengubah aturan dan mulai memproduksi Blok sesuai dengan aturan baru, setiap orang yang menjalankan Node yang melakukan verifikasi penuh akan menolak rantai tersebut. Para penambang yang tidak terlibat dalam konspirasi semacam ini akan secara otomatis berkumpul ke rantai on-chain yang terus mengikuti aturan lama, dan melanjutkan pembangunan rantai tersebut, sementara pengguna yang melakukan verifikasi penuh akan mengikuti rantai tersebut.

Ini adalah perbedaan kunci antara blockchain dan sistem terpusat. Namun, untuk menjadikan fitur ini terwujud, menjalankan Node verifikasi penuh memang membutuhkan keterlibatan yang cukup banyak orang. Ini berlaku baik untuk pembuat dan juga pengguna reguler (karena jika pembuat tidak memverifikasi rantai, mereka tidak memberikan kontribusi untuk menjalankan aturan protokol), juga berlaku untuk pengguna reguler. Saat ini, menjalankan Node pada laptop konsumen (termasuk laptop yang digunakan saat menulis artikel ini) memungkinkan, namun sulit untuk melakukannya. The Verge bertujuan untuk mengubah situasi ini, dengan menurunkan biaya komputasi untuk verifikasi rantai penuh, sehingga setiap dompet ponsel, dompet browser, bahkan smartwatch akan secara default melakukan verifikasi.

The Verge 2023 Roadmap

Pada awalnya, "Verge" merujuk pada transfer status Ethereum ke pohon Verkle - struktur pohon yang memungkinkan bukti yang lebih padat - untuk melakukan verifikasi tanpa status pada blok Ethereum. Node dapat memverifikasi blok Ethereum tanpa menyimpan status Ethereum (saldo akun, kode kontrak, ruang penyimpanan, dll.) di hard disknya, dengan biaya data bukti sekitar beberapa ratus KB dan beberapa ratus milidetik waktu tambahan untuk memverifikasi bukti tersebut. Saat ini, Verge mewakili visi yang lebih besar, dengan fokus pada mencapai efisiensi sumber daya maksimum pada rantai Ethereum, termasuk teknologi verifikasi tanpa status dan verifikasi SNARK untuk semua eksekusi Ethereum.

Selain ikuti panjang jangka panjang dari verifikasi SNARK ke seluruh rantai, permasalahan baru lainnya terkait dengan apakah Verkle tree merupakan teknologi terbaik. Verkle tree rentan terhadap serangan Komputer Kuantum, sehingga jika kita mengganti Verkle tree dalam KECCAK Merkle Patricia tree saat ini, kita harus menggantinya lagi di masa depan. Metode self-replacement dari Merkle tree adalah dengan langsung melewati penggunaan branch Merkle dan menggunakan STARK, sehingga memasukkannya ke dalam pohon biner. Secara historis, metode ini dianggap tidak layak karena biaya dan kompleksitas teknis. Namun, baru-baru ini, kita melihat Starkware membuktikan 1,7 juta hash Poseidon per detik menggunakan ckcle STARKs di laptop, dan dengan kemunculan teknologi seperti GKB, waktu bukti hash "tradisional" juga cepat berkurang. Oleh karena itu, dalam setahun terakhir, "Verge" telah menjadi lebih terbuka dan memiliki beberapa kemungkinan.

The Verge: Target Utama

· Mesin Pelanggan Tanpa Status: Ruang penyimpanan yang diperlukan untuk memvalidasi sepenuhnya mesin pelanggan dan tanda Node tidak boleh melebihi beberapa GB.

· (Lama) Validasi lengkap rantai (Konsensus dan eksekusi) di smartwatch. Unduh beberapa data, verifikasi SNARK, selesai.

Di bab ini

· Klien Tanpa Status: Verkle atau STARKs

· bukti validitas yang dilaksanakan oleh EVM

· Konsensus bukti validitas

Verifikasi Tanpa Status: Verkle atau STARKs

Apa masalah yang ingin kita selesaikan?

Saat ini, klien ETH blok perlu menyimpan ratusan ribu megabita data status untuk memverifikasi Blok, dan jumlah ini terus meningkat setiap tahun. Data status asli meningkat sekitar 30GB setiap tahun, klien tunggal harus menyimpan beberapa data tambahan di atasnya untuk dapat memperbarui triplet secara efektif.

Ini mengurangi jumlah pengguna yang dapat menjalankan Node Ethereum verifikasi penuh: meskipun hard disk yang cukup untuk menyimpan semua status Ethereum bahkan sejarah multi-tahun tersedia di mana-mana, komputer yang umumnya dibeli orang hanya memiliki beberapa ratus hingga beberapa ribu megabita ruang penyimpanan. Ukuran status juga memberikan gesekan besar dalam proses pertama kali membangun Node: Node perlu mengunduh seluruh status, yang mungkin memerlukan beberapa jam atau bahkan beberapa hari waktu. Ini akan menimbulkan berbagai reaksi berantai. Misalnya, ini secara signifikan meningkatkan kesulitan pembuat Node dalam mengupgrade pengaturan Node mereka. Secara teknis, upgrade dapat diselesaikan tanpa downtime - mulai klien baru, tunggu sinkronisasi, kemudian matikan klien lama dan transfer Kunci Rahasia - tetapi dalam praktiknya, ini sangat rumit secara teknis.

Bagaimana cara kerjanya?

Verifikasi tanpa status adalah teknologi yang memungkinkan Node untuk memverifikasi Blok tanpa memiliki seluruh status. Sebagai gantinya, setiap Blok dilengkapi dengan saksi yang mencakup: (i) nilai, kode, saldo, dan penyimpanan pada posisi tertentu dalam status yang akan diakses oleh Blok tersebut; (ii) bukti enkripsi yang menunjukkan bahwa nilai-nilai ini benar.

Sebenarnya, untuk menerapkan verifikasi tanpa status, perlu mengubah struktur pohon status Ethereum. Hal ini karena pohon Merkle Patricia saat ini sangat tidak ramah terhadap implementasi skema enkripsi apa pun, terutama dalam kasus terburuk. Baik itu cabang Merblk "asli" maupun kemungkinan untuk "membungkus" menjadi STARK, semuanya begitu. Kesulitan utamanya berasal dari beberapa kelemahan MPT:

1. Ini adalah pohon hexa (yaitu setiap Node memiliki 16 Node anak). Ini berarti, dalam pohon berukuran N, bukti rata-rata memerlukan 32*(16-1)*log16(N) = 120* log2(N) byte, atau sekitar 3840 byte dalam pohon dengan 2^32 item. Untuk pohon biner, hanya memerlukan 32*(2-1)*log2(N) = 32* log2(N) byte, atau sekitar 1024 byte.

2. Kode tidak termerkleisasi. Ini berarti untuk membuktikan aksesibilitas akun kode, seluruh kode harus disediakan, dengan maksimal 24000 byte.

Kita dapat menghitung situasi terburuk sebagai berikut:

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

Biaya cabang sedikit berkurang (menggunakan 5480 daripada 8480), karena saat cabang lebih banyak, bagian atasnya akan muncul berulang. Namun demikian, jumlah data yang harus diunduh dalam satu slot adalah tidak realistis. Jika kita mencoba menggunakan STARK untuk mengemasnya, kita akan menghadapi dua masalah: (i) KECCAK tidak ramah terhadap STARK; (ii) 330MB data berarti kita harus membuktikan 5 juta panggilan fungsi putaran KECCAK, yang mungkin tidak bisa dibuktikan oleh semua perangkat keras kecuali perangkat keras konsumen terkuat, meskipun kita dapat meningkatkan efisiensi STARK dalam membuktikan KECCAK.

Jika kita menggantikan pohon heksadesimal dengan pohon biner dan melakukan pemrosesan Merkle tambahan pada kode, maka dalam kasus terburuk akan menjadi sekitar 30000000/240032(32-14+8) = 10400000 byte (14 adalah pengurangan redundansi bit dari 2^14 cabang, dan 8 adalah panjang bukti yang masuk ke dalam blok kode). Perlu diperhatikan bahwa ini akan mengubah biaya gas, dengan membebankan biaya untuk mengakses setiap blok kode secara terpisah; EIP-4762 melakukan hal ini. Kapasitas sebesar 10,4 MB lebih baik, tetapi masih terlalu banyak data yang diunduh dalam satu slot untuk banyak Node. Oleh karena itu, kita perlu memperkenalkan teknologi yang lebih kuat. Dalam hal ini, ada dua solusi unggulan: pohon Verkle dan pohon hash biner STARKed.

Pohon Verkle

Verkle Tree menggunakan komitmen vektor berbasis kurva eliptik untuk bukti yang lebih pendek. Kunci untuk membuka adalah, tidak peduli seberapa lebar pohonnya, setiap bagian bukti yang sesuai dengan hubungan induk-anak hanya memiliki 32 byte. Satu-satunya batasan lebar pohon bukti adalah, jika pohon bukti terlalu lebar, efisiensi perhitungan bukti akan menurun. Implementasi yang diusulkan untuk Ethereum memiliki lebar 256.

Oleh karena itu, bukti ukuran satu cabang dalam 32 - 1og256(N) = 4* log2(N) byte. Jadi, secara teoritis, ukuran bukti maksimum sekitar 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 byte (karena distribusi blok status tidak merata, hasil perhitungan aktual sedikit berbeda, tetapi sebagai nilai perkiraan pertama itu bisa diterima).

Perlu diingat bahwa dalam semua contoh yang diberikan di atas, 'kasus terburuk' tersebut bukanlah yang paling buruk: yang lebih buruk adalah ketika penyerang dengan sengaja 'menggali' dua Alamat sehingga mereka memiliki awalan yang sama yang panjang di dalam pohon dan kemudian membaca data dari salah satu Alamat tersebut, yang akan memperpanjang panjang cabang dalam kasus terburuk sebesar dua kali lipat. Namun bahkan dengan kasus seperti ini, panjang bukti terburuk Verkle Tree adalah 2,6MB, yang hampir sama dengan data verifikasi dalam kasus terburuk saat ini.

Kami juga menggunakan perhatian ini untuk melakukan hal lain: kami membuat biaya akses ke ruang penyimpanan 'tetangga' menjadi sangat rendah: entah banyak blok kode dari kontrak yang sama, atau slot penyimpanan yang berdekatan. EIP - 4762 memberikan definisi tetangga, dan hanya mengenakan biaya 200 gas untuk akses tetangga. Dalam kasus akses tetangga, ukuran bukti dalam kasus terburuk menjadi 30000000 / 200*32 - 4800800 byte, yang masih dalam kisaran toleransi. Jika untuk alasan keamanan, kami ingin mengurangi nilai ini, kita dapat sedikit meningkatkan biaya akses tetangga.

Pohon Hash Binary STARKed

Prinsip teknologi ini jelas: Anda hanya perlu membuat pohon biner, mendapatkan bukti maksimum 10.4 MB, buktikan nilai dalam blok, dan gantikan bukti dengan STARK. Dengan demikian, bukti hanya berisi data yang dibuktikan, ditambah biaya tetap 100-300kB dari STARK aktual.

Tantangan utama di sini adalah verifikasi waktu. Kami dapat melakukan perhitungan yang sama dengan yang di atas, hanya saja yang kami hitung bukanlah jumlah byte, melainkan nilai hash. Sebuah Blok dengan ukuran 10,4 MB berarti terdapat 330.000 nilai hash. Jika ditambahkan kemungkinan adanya serangan "penambangan" Alamat dengan awalan umum yang panjang, maka nilai hash dalam kasus terburuk akan mencapai sekitar 660.000 nilai hash. Oleh karena itu, jika kami dapat membuktikan bahwa nilai hash per detik adalah 200.000, maka tidak ada masalah.

Pada laptop konsumen yang menggunakan fungsi hash Poseidon, angka-angka ini telah mencapai 01928374656574839201, sementara fungsi hash Poseidon dirancang khusus untuk ke-Stark-an. Namun demikian, sistem Poseidon masih tergolong belum matang sehingga banyak orang masih meragukan keamanannya. Oleh karena itu, ada dua jalur kemajuan yang nyata:

1. Melakukan analisis keamanan besar-besaran terhadap Poseidon dengan cepat dan cukup memahaminya untuk dideploy pada L1.

2. Menggunakan fungsi hash yang lebih "konservatif", seperti SHA256 atau BLAKE

Jika Anda perlu membuktikan fungsi hash yang konservatif, lingkaran STARK dari Starkware hanya dapat membuktikan 10-30k nilai hash per detik pada laptop konsumen saat ini saat artikel ini ditulis. Namun, teknologi STARK sedang mengalami peningkatan yang cepat. Bahkan hari ini, teknologi berbasis GKR juga menunjukkan peningkatan kecepatan hingga 100-200k.

Studi kasus penggunaan saksi di luar wilayah verifikasi blok

Selain memverifikasi Blok, ada tiga kasus penggunaan kunci lain yang memerlukan verifikasi tanpa keadaan yang lebih efisien:

· Memory Pool: Ketika transaksi disiarkan, Node dalam jaringan P2P perlu memverifikasi apakah transaksi tersebut valid sebelum disiarkan ulang. Verifikasi saat ini meliputi verifikasi tanda tangan, serta memeriksa apakah saldo mencukupi dan apakah awalan benar. Di masa depan (misalnya, menggunakan abstraksi akun asli, seperti EIP-7701), ini mungkin melibatkan menjalankan beberapa kode EVM yang melakukan akses status. Jika Node tidak memiliki status, transaksi perlu dilengkapi dengan bukti status objek.

· Daftar Inklusi: Ini adalah fitur yang diusulkan yang memungkinkan validator Proof of Stake (mungkin dengan skala kecil dan tidak rumit) untuk memaksa Blok berikutnya mengandung transaksi, terlepas dari keinginan pembangun Blok (mungkin dengan skala besar dan rumit). Ini akan melemahkan kemampuan pemegang kekuasaan untuk memanipulasi rantai Blok melalui transaksi penundaan. Namun, validator perlu memiliki cara untuk memverifikasi validitas transaksi dalam daftar inklusi.

· light client: Jika kami ingin pengguna mengakses rantai melalui dompet (seperti Metamask, Rainbow, Rabby, dll), untuk mencapai ini, mereka perlu menjalankan klien ringan (seperti Helios). Modul inti Helios menyediakan pengguna dengan akar status yang diverifikasi. Dan untuk mendapatkan pengalaman yang sepenuhnya tidak terpercaya, pengguna perlu memberikan bukti untuk setiap panggilan RPC yang mereka lakukan (misalnya, permintaan panggilan jaringan ETH (pengguna perlu membuktikan akses ke semua status yang diakses selama pemanggilan)).

Semua kasus penggunaan ini memiliki satu kesamaan, yaitu mereka membutuhkan banyak bukti, tetapi setiap bukti itu kecil. Oleh karena itu, bukti STARK tidak memiliki arti yang sebenarnya untuk mereka; sebaliknya, pendekatan yang paling realistis adalah menggunakan cabang Merkle langsung. Keuntungan lain dari cabang Merkle adalah dapat diperbarui: dengan diberikan bukti objek status X dengan akar Blok B, jika menerima Blok B2 anak dan kesaksian Blok B2, bukti dapat diperbarui sehingga menggunakan Blok B2 sebagai akar. Bukti Verkle juga dapat diperbarui secara asli.

Hubungan dengan penelitian yang ada:

pohon Verkle

· John Kuszmaul tentang makalah asli pohon Verkle

· Starkware

· Kertas Poseidon2

· Ajtai (fungsi hash alternatif cepat berbasis kekerasan kisi kristal)

· Verkle.info

Apa yang masih bisa dilakukan?

Tugas utama yang tersisa adalah

1. Analisis lebih lanjut tentang Konsekuensi EIP-4762 (Perubahan Biaya Gas Tanpa Status)

2. Melakukan lebih banyak pekerjaan untuk menyelesaikan dan menguji program transisi, ini adalah bagian utama dari kompleksitas pelaksanaan solusi lingkungan tanpa kewarganegaraan

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

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

Selain itu, kami akan segera memutuskan untuk memilih salah satu dari tiga pilihan berikut: (i) Pohon Verkle, (ii) Fungsi hash Ramah STARK, dan (iii) Fungsi hash Konservatif. Karakteristik mereka dapat secara kasar dirangkum dalam tabel di bawah ini:

Selain itu, ada beberapa pertimbangan penting lainnya selain "nomor judul" ini:

· Saat ini, kode Verkle tree sudah cukup matang. Selain Verkle, penggunaan kode lain akan menunda implementasi, dan kemungkinan besar akan menunda hardfork. Ini tidak masalah, terutama jika kita membutuhkan waktu tambahan untuk analisis fungsi hash atau implementasi validator, atau jika kita memiliki fitur penting lain yang ingin dimasukkan lebih awal ke dalam Ethereum.

· Menggunakan nilai hash untuk memperbarui akar status lebih cepat daripada menggunakan pohon Verkle. Ini berarti metode berbasis nilai hash dapat mengurangi waktu sinkronisasi Node penuh.

Verkle tree memiliki sifat saksi yang menarik - saksi Verkle dapat diperbarui. Properti ini berguna untuk mempool, daftar transaksi, dan penggunaan lainnya, dan mungkin juga membantu meningkatkan efisiensi implementasi: jika objek status diperbarui, saksi lapisan kedua dari belakang dapat diperbarui tanpa perlu membaca konten lapisan terakhir.

· Verkle Tree lebih sulit untuk melakukan bukti SNARK. Jika kita ingin mengurangi ukuran bukti menjadi beberapa ribu byte, bukti Verkle akan menghadirkan beberapa kesulitan. Hal ini dikarenakan verifikasi bukti Verkle melibatkan operasi 256-bit yang banyak, yang membutuhkan biaya besar dalam sistem bukti atau struktur internal yang disesuaikan dengan bagian bukti Verkle 256-bit. Ini bukan masalah bagi non-stateful, tetapi akan menimbulkan lebih banyak kesulitan.

Jika kita ingin mendapatkan keamanan kuantum dan kebaruan saksi Verkle secara efisien dan efektif, cara lain yang mungkin adalah menggunakan pohon Merkle berbasis lattice.

Jika dalam keadaan terburuk, membuktikan bahwa efisiensi sistem tidak cukup tinggi, maka kita masih dapat menggunakan alat gas multidimensi yang tidak terduga ini untuk mengatasi kekurangan ini: dengan (i) calldata; (ii) komputasi; (iii) akses status dan kemungkinan pengaturan sumber daya lainnya dengan batasan gas yang terpisah. Gas multidimensi menambah kompleksitas, tetapi sebagai pertukaran, itu secara ketat membatasi rasio antara kasus rata-rata dan kasus terburuk. Dengan gas multidimensi, secara teoritis jumlah cabang maksimum yang perlu dibuktikan dapat berkurang dari 12500 menjadi misalnya 3000. Ini akan membuat BLAKE3 cukup (meskipun dengan susah payah) bahkan pada saat ini.

Gas multi-dimensi memungkinkan batasan sumber daya Blok menjadi lebih dekat dengan batasan sumber daya perangkat keras dasar

Alat lain yang tak terduga adalah menghitung latensi dari root state ke Blok setelah timeslot. Dengan begitu, kita memiliki waktu 12 detik untuk menghitung root state, yang berarti bahkan dalam situasi paling ekstrim, waktu bukti hanya 60000 hash per detik sudah cukup, ini sekali lagi membuat kita berpikir bahwa BLAKE3 hanya bisa memenuhi persyaratan dengan susah payah.

Kekurangan metode ini adalah akan menambahkan latensi pada light client, tetapi ada juga teknik yang lebih canggih yang dapat mengurangi latensi ini menjadi hanya latensi pembuatan bukti. Misalnya, bukti dapat segera disiarkan di jaringan setelah dihasilkan oleh node mana pun, bukan menunggu blok berikutnya.

Bagaimana itu berinteraksi dengan bagian lain dari peta jalan?

Menyelesaikan masalah tanpa status secara signifikan meningkatkan kesulitan dalam menetapkan titik tunggal. Jika ada teknologi yang dapat menurunkan keseimbangan minimum titik tunggal, seperti strategi Orbit SSF atau Layer Aplikasi seperti tim titik, ini akan menjadi lebih memungkinkan.

Jika EOF diperkenalkan secara bersamaan, analisis gas multidimensi akan menjadi lebih mudah. Ini karena kompleksitas eksekusi gas multidimensi terutama berasal dari penanganan panggilan anak yang tidak melalui gas induk yang disampaikan sepenuhnya, sementara EOF hanya perlu mengatur panggilan anak semacam ini sebagai ilegal, masalah ini menjadi sepele (dan abstraksi akun lokal ini akan menyediakan solusi alternatif untuk penggunaan gas utama saat ini yang sebagian).

Antara verifikasi tanpa status dan masa berlaku sejarah, terdapat sinergi penting. Saat ini, klien harus menyimpan data sejarah hingga 1TB; data ini beberapa kali lipat dari data status. Meskipun klien bersifat tanpa status, kecuali kita dapat melepaskan tanggung jawab klien dalam menyimpan data sejarah, mimpi untuk hampir tanpa penyimpanan klien tidak akan tercapai. Langkah pertama dalam hal ini adalah EIP-4444, yang juga berarti menyimpan data sejarah dalam torrent atau Portal Network.

Bukti validitas yang dilakukan oleh EVM

Apa masalah yang ingin kita selesaikan?

Tujuan jangka panjang verifikasi Blok ETH yang jelas - dapat memverifikasi Blok ETH dengan cara berikut: (i) Mengunduh Blok atau bahkan hanya mendownload sebagian kecil sampel ketersediaan data Blok; (ii) Memverifikasi bukti kecil yang valid untuk Blok. Ini akan menjadi operasi yang sangat hemat sumber daya yang dapat diselesaikan di aplikasi seluler, Dompet browser, atau bahkan di jaringan lain (tanpa bagian ketersediaan data).

Untuk mencapai ini, perlu bukti SNARK atau STARK pada (i) lapisan konsensus (yaitu bukti kepemilikan saham) dan (ii) lapisan eksekusi (yaitu EVM). Yang pertama itu sendiri merupakan tantangan dan seharusnya diselesaikan dalam proses terus-menerus untuk meningkatkan lapisan konsensus (misalnya, terhadap finalitas tunggal). Yang kedua memerlukan bukti eksekusi EVM.

Apa itu, bagaimana cara kerjanya?

Dari segi bentuk, dalam spesifikasi Ethereum, EVM didefinisikan sebagai fungsi perubahan status: Anda memiliki beberapa status sebelum S, sebuah Blok B, dan Anda sedang menghitung status setelah S' = STF(S, B). Jika pengguna menggunakan light client, mereka tidak sepenuhnya memiliki S dan S', bahkan E; sebaliknya, mereka memiliki akar status sebelum R, akar status setelah R', dan nilai hash Blok H.

· Input publik: akar status sebelumnya R, akar status selanjutnya R', hash blok H

· Input pribadi: blok tubuh B, objek dalam keadaan diakses oleh blok Q, objek yang sama setelah blok Q 'dieksekusi, bukti keadaan (misalnya cabang Merkle) P

· Klaim 1: P adalah bukti valid bahwa Q berisi beberapa bagian dari keadaan yang diwakili R

· Pendapat 2: Jika STF dijalankan pada Q, (i) proses eksekusi hanya mengakses objek internal Q, (ii) blok data valid, (iii) hasil adalah Q'

· Klaim 3: Jika menggunakan informasi Q' dan P untuk menghitung kembali akar status baru, maka akan mendapatkan R'

Jika situasi seperti itu ada, maka dapat memiliki klien ringan yang sepenuhnya memvalidasi eksekusi EVM Ethereum. Ini membuat sumber daya klien cukup rendah. Untuk mencapai klien Ethereum yang sepenuhnya divalidasi, perlu melakukan pekerjaan yang sama dalam hal Konsensus.

Implementasi bukti validitas untuk perhitungan EVM sudah ada dan banyak digunakan di L2. Namun, ada banyak pekerjaan yang harus dilakukan untuk membuat bukti validitas EVM layak digunakan di L1.

Apa hubungan dengan penelitian yang sudah ada?

· EFPSE ZK-EVM (telah dinonaktifkan karena ada pilihan yang lebih baik)

· Zeth, prinsip kerjanya adalah mengkompilasi EVM ke dalam RISC-0 ZK-VM

· Proyek Verifikasi Formal ZK-EVM

Apa yang masih bisa dilakukan?

Saat ini, sistem pencatatan elektronik memiliki kekurangan dalam dua hal: keamanan dan waktu verifikasi.

Sebuah bukti validitas yang aman harus memastikan bahwa SNARK benar-benar memvalidasi perhitungan EVM dan tidak ada kerentanan. Dua teknologi utama untuk meningkatkan keamanan adalah multi-verifikator dan verifikasi formal. Multi-verifikator merujuk pada adanya implementasi bukti validitas yang independen yang banyak, seperti memiliki banyak klien, jika sebuah Blok dibuktikan oleh sebuah subset yang cukup besar dari implementasi-implementasi ini, klien akan menerima Blok tersebut. Verifikasi formal melibatkan penggunaan alat yang biasanya digunakan untuk membuktikan teorema matematika, seperti Lean4, untuk membuktikan bahwa bukti validitas hanya menerima spesifikasi EVM yang dijalankan dengan benar (misalnya semantik EVM K atau spesifikasi lapisan eksekusi ETH yang ditulis dengan python (EELS)).

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

· Paralelisme - Validasi EVM tercepat saat ini rata-rata dapat membuktikan sebuah Blok Ethereum dalam waktu 15 detik. Ini dicapai dengan memparallelkan di ratusan GPU, kemudian menggabungkan hasil kerjanya secara bersamaan. Secara teoritis, kita benar-benar tahu bagaimana cara membuat validasi EVM yang dapat membuktikan komputasi dalam waktu O(log(N)): biarkan satu GPU menyelesaikan setiap langkah, kemudian lakukan 'pohon agregat'.

Ada tantangan untuk mencapai hal ini. Bahkan dalam skenario terburuk, di mana transaksi yang sangat besar memakan seluruh blok, partisi perhitungan tidak dapat dilakukan satu kali, tetapi harus dilakukan berdasarkan per-opcode (opcode dari mesin virtual yang mendasarinya seperti EVM atau RISC-V). Memastikan bahwa "memori" Mesin Virtual konsisten di berbagai bagian bukti merupakan tantangan utama dalam proses implementasi. Namun, jika kita dapat menerapkan bukti rekursif semacam ini, maka kita tahu bahwa meskipun tidak ada perbaikan lain, setidaknya masalah Larensi prover telah terpecahkan.

· Sistem bukti yang dioptimalkan - Sistem bukti baru seperti Orion, Binius, GRK, dan informasi lainnya kemungkinan besar akan menyebabkan pengurangan besar dalam waktu verifikasi komputasi umum.

· Perubahan biaya gas EVM lainnya - Banyak hal di dalam EVM yang dapat dioptimalkan untuk menjadi lebih menguntungkan bagi para validator, terutama dalam situasi terburuk. Jika penyerang dapat membangun sebuah Blok yang menghalangi validator selama sepuluh menit, maka hanya bisa membuktikan satu Blok ETH biasa dalam 4 detik tidak akan cukup. Perubahan EVM yang diperlukan dapat secara kasar dibagi menjadi beberapa kategori berikut:

Perubahan biaya gas - Jika suatu operasi memerlukan waktu yang sangat lama untuk dibuktikan, maka biaya gasnya harus tinggi, meskipun kecepatan komputasinya relatif cepat. EIP-7667 adalah sebuah EIP yang diajukan untuk menangani masalah yang paling serius dalam hal ini: ini secara signifikan meningkatkan biaya gas dari fungsi hash (tradisional) karena opcode dan prekompilasinya relatif murah. Untuk menutupi peningkatan biaya gas ini, kita dapat menurunkan biaya gas opcode EVM yang membuktikan relatif murah, sehingga menjaga throughput rata-rata tetap sama.

• Penggantian Struktur Data - Selain mengganti pohon status dengan metode yang lebih ramah STARK, kami juga perlu mengganti daftar transaksi, pohon kwitansi, dan struktur yang mahal untuk dibuktikan. Langkah Etan Kissling dalam memindahkan struktur transaksi dan kwitansi ke SSZ adalah langkah menuju arah ini.

Selain itu, dua alat yang disebutkan dalam bagian sebelumnya (gas multi-dimensi dan root status latensi) juga dapat membantu dalam hal ini. Namun, perlu diperhatikan bahwa berbeda dengan verifikasi tanpa status, menggunakan kedua alat ini berarti kita sudah memiliki teknologi yang cukup untuk menyelesaikan pekerjaan yang kita perlukan saat ini, dan meskipun menggunakan teknologi ini, verifikasi ZK-EVM lengkap juga membutuhkan lebih banyak pekerjaan - hanya saja pekerjaan yang dibutuhkan lebih sedikit.

Satu hal yang tidak disebutkan sebelumnya adalah perangkat keras validator: menggunakan GPU, FPGA, dan ASIC untuk menghasilkan bukti lebih cepat. Fabric Cryptography, Cysic, dan Accseal adalah tiga perusahaan yang membuat kemajuan dalam hal ini. Ini sangat berharga untuk L2, tetapi tidak mungkin menjadi faktor penentu bagi L1 karena orang-orang sangat ingin L1 tetap Desentralisasi, yang berarti pembangkitan bukti harus berada dalam jangkauan wajar pengguna ETH, dan tidak boleh dibatasi oleh batasan perangkat keras perusahaan tunggal. L2 dapat membuat pertimbangan yang lebih positif.

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

· Bukti paralelisasi membutuhkan sistem bukti bahwa bagian-bagian yang berbeda dari sistem dapat 'membagikan memori' (misalnya tabel pencarian). Kami tahu teknik ini, tetapi perlu diimplementasikan.

· Kami perlu melakukan analisis lebih lanjut untuk menemukan kumpulan perubahan biaya gas yang ideal sehingga waktu verifikasi dalam situasi terburuk dapat dikurangi sebanyak mungkin.

Kita perlu melakukan lebih banyak kerja dalam hal sistem pembuktian

Kemungkinan biayanya adalah:

· Keamanan dan waktu verifikator: Jika memilih fungsi hash yang lebih agresif, sistem bukti yang lebih kompleks, asumsi keamanan yang lebih agresif, atau skema desain lainnya, maka kemungkinan waktu verifikator dapat dipersingkat.

· Desentralisasi dan waktu validator: Komunitas perlu mencapai 'spesifikasi' terhadap perangkat keras validator yang ditargetkan. Apakah validator dapat dilakukan oleh entitas besar? Apakah kita menginginkan laptop konsumen high-end untuk memvalidasi blok Rangkaian ETH dalam 4 detik? Atau di antara keduanya?

· Tingkat pelanggaran kompatibilitas mundur: Kekurangan lain dapat diatasi dengan perubahan biaya gas yang lebih aktif, tetapi ini lebih mungkin secara tidak proporsional meningkatkan biaya beberapa aplikasi, memaksa pengembang untuk menulis ulang dan mendeploy ulang kode untuk menjaga keberlanjutan ekonomi. Demikian juga, kedua alat ini memiliki kompleksitas dan kerugian sendiri.

Bagaimana itu berinteraksi dengan bagian lain dari peta jalan?

Implementasi teknologi inti yang diperlukan untuk bukti validitas L1 EVM secara besar-besaran berbagi banyak kesamaan dengan dua bidang lainnya:

· Bukti validitas L2 (disebut juga 'ZK rollup')

· Metode bukti hash biner "STARK" tanpa status

Jika bukti validitas berhasil diimplementasikan di L1, maka akan memungkinkan untuk melakukan stake tunggal dengan mudah: bahkan komputer yang paling lemah pun (termasuk ponsel atau jam tangan pintar) dapat melakukan stake. Ini lebih meningkatkan nilai dari solusi lain untuk memecahkan batasan stake tunggal (seperti minimum 32ETH).

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

Konsensus b证明validitas

Apa masalah yang ingin kita selesaikan?

Jika kita ingin sepenuhnya memverifikasi sebuah blok ETH menggunakan SNARK, maka eksekusi EVM bukanlah satu-satunya bagian yang perlu kita buktikan. Kita juga perlu membuktikan Konsensus, yaitu bagian sistem yang menangani deposit, penarikan, penandatanganan, pembaruan saldo validator, dan elemen lain dari bagian Proof of Stake ETH blok.

Konsensus jauh lebih sederhana daripada EVM, tetapi tantangannya adalah kita tidak memiliki konvolusi L2 EVM, jadi sebagian besar pekerjaan harus dilakukan dengan cara apa pun. Oleh karena itu, implementasi Konsensus Ethereum memerlukan 'memulai dari awal', meskipun sistem konsensus itu sendiri dapat dibangun dengan kerja bersama.

Apa itu, bagaimana ini bekerja?

beacon chain didefinisikan sebagai fungsi peralihan status, sama seperti EVM. Fungsi peralihan status terutama terdiri dari tiga bagian:

· ECADD（digunakan untuk memverifikasi tanda tangan BLS）

· Pasangan (digunakan untuk memverifikasi tanda tangan BLS)

· Nilai hash SHA256 (untuk membaca dan memperbarui status)

Di setiap blok, kita perlu membuktikan 1-16 BLS12-381 ECADD untuk setiap validator (mungkin lebih dari satu, karena tanda tangan mungkin terkandung dalam beberapa koleksi). Ini dapat dikompensasi dengan teknik precomputation subset, sehingga kita dapat mengatakan bahwa setiap validator hanya perlu membuktikan satu ECADD BLS12-381. Saat ini, ada 30.000 tanda tangan validator per slot. Di masa depan, ini bisa berubah dalam dua arah karena finalitas slot tunggal diterapkan: jika kita mengambil rute "brute force", jumlah validator per slot bisa meningkat menjadi 1 juta. Pada saat yang sama, jika Orbit SSF diadopsi, jumlah validator akan tetap di 32.768 atau bahkan menurun menjadi 8.192.

Bagaimana BLS Aggregates Bekerja: Verifikasi tanda tangan total hanya memerlukan satu ECADD dari setiap peserta, bukan satu ECMUL. Namun, 30000 ECADD masih merupakan jumlah yang besar untuk dibuktikan.

Dalam hal pasangan, saat ini setiap slot memiliki maksimal 128 bukti, yang berarti perlu memverifikasi 128 pasangan. Dengan ElP-7549 dan modifikasi lebih lanjut, setiap slot dapat dikurangi menjadi 16. Jumlah pasangan sangat sedikit, tetapi biayanya sangat tinggi: waktu operasi (atau bukti) setiap pasangan lebih dari k kali lebih lama daripada ECADD.

Salah satu tantangan utama dalam membuktikan operasi BLS12-381 adalah tidak adanya kurva yang memiliki orde yang sama dengan ukuran bidang BLS12-381, yang menambah biaya yang cukup besar bagi setiap sistem bukti. Di sisi lain, Pohon Verkle yang diajukan untuk Ethereum dibangun dengan menggunakan kurva Bandersnatch, yang menjadikan BLS12-381 itu sendiri sebagai sub-kurva untuk membuktikan cabang Verkle dalam sistem SNARK. Implementasi yang relatif sederhana dapat membuktikan 100 G1 tambahan per detik; untuk membuat kecepatan pembuktian cukup cepat, hampir pasti diperlukan teknik canggih seperti GKR.

Untuk nilai hash SHA256, kasus terburuk saat ini adalah blok transisi era, seluruh pohon seimbang pendek validator dan banyak pohon seimbang validator akan diperbarui. Setiap pohon seimbang pendek validator hanya memiliki satu byte, sehingga ada 1 MB data yang akan di-hash ulang. Ini setara dengan 32768 panggilan SHA256. Jika ada seribu saldo validator yang lebih tinggi atau lebih rendah dari ambang batas, perlu memperbarui saldo efektif dalam catatan validator, ini setara dengan seribu cabang Merkle, sehingga mungkin membutuhkan sepuluh ribu hash. Mekanisme pengacakan membutuhkan 90 Bit untuk setiap validator (sehingga membutuhkan 11 MB data), tetapi ini dapat dihitung kapan saja dalam suatu era. Dalam kasus terminasi slot tunggal, angka-angka ini mungkin berfluktuasi tergantung pada situasi spesifik. Pengacakan menjadi tidak perlu, meskipun Orbit mungkin mengembalikan kebutuhan ini dalam beberapa tingkat.

Tantangan lainnya adalah perlu untuk memperoleh ulang semua status validator, termasuk Kunci Publik, sebelum Blok dapat diverifikasi. Untuk 1 juta validator saja, membaca Kunci Publik memerlukan 48 juta byte, ditambah dengan cabang Merkle. Ini memerlukan jutaan nilai hash pada setiap epoch. Jika kita harus membuktikan keefektifan PoS, metode yang realistis adalah bentuk perhitungan verifikasi bertambah: menyimpan struktur data terpisah dalam sistem bukti, struktur data ini dioptimalkan untuk pencarian efisien dan bukti pembaruan pada struktur tersebut.

Secara keseluruhan, ada banyak tantangan. Untuk menghadapi tantangan ini secara efektif, mungkin perlu dilakukan desain ulang yang mendalam terhadap beacon chain, yang mungkin dilakukan bersamaan dengan beralih ke terminasi slot tunggal. Fitur dari desain ulang tersebut mungkin mencakup:

· Perubahan fungsi hash: Sekarang digunakan fungsi hash SHA256 "lengkap", oleh karena itu, karena alasan padding, setiap panggilan harus sesuai dengan dua kali panggilan fungsi kompresi dasar. Jika menggunakan fungsi kompresi SHA256, setidaknya kita dapat mendapatkan keuntungan 2 kali lipat. Jika menggunakan Poseidon, kita mungkin akan mendapatkan keuntungan 100 kali lipat, sehingga dapat sepenuhnya mengatasi semua masalah kita (setidaknya dalam hal nilai hash): dalam 1,7 juta nilai hash per detik (54MB), bahkan seratus ribu catatan verifikasi pun dapat "dibaca" dalam beberapa detik.

· Jika itu Orbit, maka catat verifikator yang telah di-shuffle langsung: Jika dipilih sejumlah verifikator tertentu (misalnya 8192 atau 32768) sebagai komite untuk slot yang diberikan, maka letakkan mereka secara langsung di sebelah status masing-masing, sehingga hanya perlu hash minimum untuk membaca Kunci Publik dari semua verifikator ke dalam bukti. Ini juga dapat menyelesaikan semua pembaruan keseimbangan secara efisien.

· Agregasi Tanda Tangan: Setiap skema agregasi tanda tangan yang tinggi kinerjanya akan melibatkan bukti rekursif tertentu, di mana Node yang berbeda dalam jaringan akan memberikan bukti tengah untuk subset tanda tangan. Hal ini secara alami membagi kerja bukti ke beberapa Node dalam jaringan, sehingga secara signifikan mengurangi beban kerja 'pemohon akhir'.

· Skema tanda tangan lainnya: Untuk tanda tangan Lamport+ Merkle, kita membutuhkan 256 + 32 nilai hash untuk memverifikasi tanda tangan; dikalikan dengan 32768 penandatangan, kita mendapatkan 9437184 nilai hash. Setelah mengoptimalkan skema tanda tangan, kita dapat memperbaiki hasil ini lebih lanjut melalui faktor konstan yang sangat kecil. Jika kita menggunakan Poseidon, ini dapat dibuktikan dalam satu slot tunggal. Namun sebenarnya, menggunakan skema agregasi rekursif akan lebih cepat.

Apa hubungan dengan penelitian yang sudah ada?

· Proof of Konsensus Ethereum yang ringkas (hanya untuk Komite Sinkronisasi)

· Helios di dalam SP1 yang sederhana

· Kompilasi Awal BLS12-381 yang Ringkas

· Verifikasi Tanda Tangan Koleksi BLS berbasis Halo2

Masih ada pekerjaan apa yang perlu dilakukan dan bagaimana memilihnya:

Sebenarnya, kita memerlukan beberapa tahun untuk mencapai bukti validitas Ethereum Konsensus ETH. Ini sekitar waktu yang sama yang diperlukan untuk mencapai finalitas slot tunggal, Orbit, memodifikasi Algoritme Tanda Tangan, dan analisis keamanan yang membutuhkan kepercayaan yang cukup untuk menggunakan fungsi hash yang "agresif" seperti Poseidon. Oleh karena itu, pendekatan yang paling bijaksana adalah menyelesaikan masalah-masalah lain ini dan mempertimbangkan keberpihakan STARK saat menyelesaikan masalah-masalah ini.

Kompromi utama mungkin terletak pada urutan operasi, antara pendekatan yang lebih progresif dalam reformasi lapisan konsensus Ethereum dan pendekatan 'satu perubahan banyak'. Pendekatan progresif adalah masuk akal untuk EVM karena dapat meminimalkan gangguan pada kompatibilitas ke belakang. Bagi lapisan konsensus, dampak pada kompatibilitas ke belakang lebih kecil dan ada manfaat dalam mempertimbangkan ulang berbagai detail dalam membangun beacon chain untuk mengoptimalkan kebersahajaan SNARK secara optimal.

Bagaimana interaksi dengan bagian lain dari peta jalan?

Ketika merancang ulang PoS Ethereum dalam jangka panjang, kejelasan STARK harus menjadi faktor yang sangat penting, terutama dalam hal finalitas satu slot, Orbit, perubahan skema tanda tangan, dan agregasi tanda tangan.

Tautan Asli