Vitalik: Diskusikan berbagai jenis versi "built-in ZK-EVM" dan tantangan desain

Kata-kata: Vitalik Buterin

Kompilasi: 1912212.eth, Berita Foresight

Protokol EVM lapisan 2 di atas ETH, termasuk rollup optimis dan rollup ZK, bergantung pada validasi EVM. Namun, ini mengharuskan mereka untuk mempercayai basis kode yang sangat besar, dan jika ada bug dalam basis kode itu, VM ini berisiko diretas. Selain itu, ini berarti bahwa bahkan ZK-EVM, yang ingin sepenuhnya setara dengan L1 EVM, memerlukan beberapa bentuk tata kelola untuk mereplikasi perubahan pada L1 EVM ke dalam praktik EVM mereka sendiri.

Situasi ini tidak ideal, karena proyek-proyek ini mereplikasi fungsionalitas yang sudah ada dalam protokol Lokakarya ETH, dan Tata Kelola ETH sudah bertanggung jawab untuk meningkatkan dan memperbaiki bug: ZK-EVM pada dasarnya adalah pekerjaan yang sama dengan memvalidasi blok Layer 1 ETH Workshop!Selain itu, di tahun-tahun mendatang, kami berharap klien ringan menjadi semakin kuat, dan segera mencapai titik di mana ZK-SNARKs digunakan untuk sepenuhnya memvalidasi eksekusi EVM Layer 1. Pada saat itu, jaringan ETH akan secara efektif membangun ZK-EVM built-in. Jadi, muncul pertanyaan: mengapa tidak membuat ZK-EVM itu sendiri cocok untuk rollup juga?

Dalam artikel ini, kita akan melihat beberapa versi “built-in ZK-EVM” yang dapat diimplementasikan, dan membahas trade-off dan tantangan desain, serta alasan untuk tidak pergi ke arah tertentu. Manfaat menerapkan fitur protokol harus ditimbang terhadap manfaat meninggalkan hal-hal ke ekosistem dan menjaga protokol yang mendasarinya tetap sederhana.

Fitur utama apa yang kami inginkan dari ZK-EVM bawaan?

• Fungsi dasar: Validasi blok ETH. Fungsi protokol (yang belum jelas apakah itu opcode, prakompilasi, atau mekanisme lainnya) harus menerima setidaknya satu root pra-state, satu blok, dan satu root post-state sebagai input, dan memverifikasi bahwa root post-state sebenarnya adalah hasil dari eksekusi blok.
• Kompatibel dengan beberapa klien ETH Square. Ini berarti bahwa kami ingin menghindari hanya satu sistem pengesahan dan sebagai gantinya mengizinkan klien yang berbeda untuk menggunakan sistem pengesahan yang berbeda. Ini mengarah ke poin-poin berikut:
• Persyaratan ketersediaan data: Untuk setiap eksekusi EVM yang menggunakan ZK-EVM bawaan untuk bukti, kami ingin menjamin ketersediaan data yang mendasarinya sehingga prover yang menggunakan sistem pengesahan yang berbeda dapat membuktikan kembali eksekusi dan memungkinkan klien yang mengandalkan sistem pengesahan tersebut untuk memvalidasi bukti yang baru dihasilkan.
• Bukti ada di luar EVM dan struktur data potongan: Fitur ZK-EVM bawaan tidak mengambil SNARKs sebagai input dalam EVM, karena klien yang berbeda akan mengharapkan berbagai jenis SNARKs. Sebaliknya, ini mungkin mirip dengan validasi blob: transaksi dapat mencakup klaim (pra-status, badan blok, pasca-status) yang perlu dibuktikan, konten yang dapat diakses oleh opcode atau precompiler, dan aturan konsensus sisi klien akan memeriksa ketersediaan data dan bukti keberadaan untuk setiap klaim secara terpisah.
• Auditabilitas. Jika ada eksekusi yang terbukti, kami ingin data yang mendasarinya dapat digunakan sehingga jika terjadi masalah, pengguna dan pengembang dapat memeriksanya. Bahkan, ini menambah alasan lain mengapa persyaratan ketersediaan data sangat penting.
• Upgradeability. Jika solusi ZK-EVM ditemukan memiliki bug, kami ingin dapat memperbaikinya dengan cepat. Ini berarti bahwa tidak perlu garpu keras untuk diperbaiki. Ini menambah mengapa bukti ada di luar EVM dan struktur data blok.
• Mendukung hampir semua EVM. Salah satu daya tarik L2 adalah berinovasi pada lapisan eksekusi dan menskalakan EVM. Jika VM untuk L2 tertentu hanya sedikit berbeda dari EVM, maka alangkah baiknya jika L2 masih bisa menggunakan ZK-EVM dalam protokol asli di bagian yang sama dengan EVM, dan hanya mengandalkan kodenya sendiri di bagian yang berbeda. Ini dapat dicapai dengan merancang fungsi ZK-EVM yang memungkinkan pemanggil untuk menentukan bidang bit atau daftar opcode atau alamat yang ditangani oleh tabel yang disediakan secara eksternal daripada EVM itu sendiri. Kami juga dapat membuat biaya gas terbuka untuk pengeditan sampai batas tertentu.

Sistem multi-klien “Terbuka” dan “tertutup”

“Filosofi multi-klien” mungkin merupakan persyaratan paling subjektif dalam daftar ini. Ada pilihan untuk meninggalkannya dan fokus pada skema ZK-SNARK, yang akan menyederhanakan desain, tetapi dengan biaya menjadi “titik balik filosofis” yang lebih besar untuk Lokakarya ETH (karena secara efektif meninggalkan filosofi multiklien lama ETH Workshop) dan memperkenalkan risiko yang lebih besar. Di masa depan, ketika teknologi verifikasi formal menjadi lebih baik, mungkin lebih baik memilih jalur ini, tetapi sekarang tampaknya risikonya terlalu besar.

Pilihan lain adalah sistem multiclient tertutup di mana satu set tetap sistem pengesahan dikenal dalam protokol. Misalnya, kami mungkin memutuskan untuk menggunakan tiga ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM, dan Kakarot. Sebuah blok membutuhkan bukti yang diberikan oleh dua dari tiga ini agar valid. Ini lebih baik daripada sistem bukti tunggal, tetapi itu membuat sistem kurang mudah beradaptasi karena pengguna harus mempertahankan validator untuk setiap sistem bukti yang ada, dan pasti akan ada proses tata kelola politik untuk memasukkan sistem bukti baru, dll.

Ini memotivasi saya untuk lebih memilih sistem multiklien terbuka, di mana bukti ditempatkan “di luar blok” dan diverifikasi oleh klien secara individual. Pengguna individu dapat menggunakan klien apa pun yang mereka inginkan untuk memvalidasi blok, selama setidaknya satu prover membuat bukti untuk sistem pengesahan tersebut. Sistem pengesahan akan mendapatkan pengaruh dengan meyakinkan pengguna untuk menjalankannya, bukan dengan meyakinkan proses tata kelola protokol. Namun, pendekatan ini memang memiliki biaya kompleksitas yang lebih tinggi, seperti yang akan kita lihat.

Properti utama apa yang ingin kita peroleh dari implementasi ZK-EVM?

Selain kebenaran fungsional dasar dan jaminan keamanan, atribut yang paling penting adalah kecepatan. Meskipun kami dapat merancang fitur ZK-EVM dalam protokol, yang tidak sinkron dan hanya mengembalikan setiap jawaban yang dinyatakan setelah penundaan slot N, masalahnya menjadi lebih mudah jika kami dapat dengan andal menjamin bahwa bukti akan dihasilkan dalam hitungan detik, tidak peduli apa yang terjadi di setiap blok mandiri.

Meskipun dibutuhkan beberapa menit atau jam hari ini untuk menghasilkan bukti untuk blok ETH, kita tahu bahwa tidak ada alasan teoritis untuk mencegah paralelisasi massa: kita selalu dapat menggabungkan GPU yang cukup untuk membuktikan bagian-bagian individual dari eksekusi blok secara terpisah dan kemudian menempatkan bukti bersama-sama menggunakan SNARKs rekursif. Selain itu, akselerasi perangkat keras melalui FPGA dan ASIC dapat membantu lebih mengoptimalkan bukti. Namun, mencapai titik ini adalah tantangan teknik besar yang tidak boleh diremehkan.

Seperti apa tampilan fitur ZK-EVM dalam protokol?

Mirip dengan transaksi blob EIP-4844, kami telah memperkenalkan jenis transaksi baru yang berisi klaim ZK-EVM:

Penting untuk dicatat bahwa dalam praktiknya, kita mungkin ingin membagi sideload menjadi dua sideload terpisah, satu untuk blob dan satu untuk bukti, dan menyiapkan subnet terpisah untuk setiap jenis bukti (dan subnet tambahan untuk blob).

Pada lapisan konsensus, kami menambahkan aturan validasi yang hanya menerima blok jika klien melihat bukti yang valid dari setiap klaim di blok. Bukti harus ZK-SNARK, membuktikan bahwa rangkaian transaksi \ _and \ _witness \ _blobs adalah serialisasi pasangan (Blok, Saksi), dan bahwa blok dieksekusi dengan pra \ _state \ _root pada Saksi

(i) valid, dan

(ii) Keluarkan posting \ _state \ _root yang benar. Mungkin, klien dapat memilih untuk menunggu beberapa jenis bukti M-of-N.

Penting untuk dicatat di sini bahwa eksekusi blok itu sendiri dapat dengan mudah dianggap sebagai salah satu dari tiga kali lipat yang perlu diperiksa bersama dengan tiga kali lipat yang disediakan dalam objek ZKEVMClaimTransaction (σpre, σpost, Proof). Akibatnya, implementasi ZK-EVM pengguna dapat menggantikan klien eksekusinya; klien eksekusi akan tetap dieksekusi

(i) Provers dan Block Builder dan:

dan (ii) node yang peduli tentang pengindeksan dan penyimpanan data untuk penggunaan lokal.

Selain itu, karena arsitektur ini memisahkan eksekusi dari validasi, arsitektur ini dapat memberikan lebih banyak fleksibilitas dan efisiensi untuk peran yang berbeda dalam ekosistem ETH. Misalnya, prover dapat fokus pada menghasilkan bukti tanpa khawatir tentang spesifikasi eksekusi, sementara klien eksekusi dapat dioptimalkan untuk memenuhi kebutuhan pengguna tertentu, seperti sinkronisasi cepat atau kemampuan pengindeksan lanjutan.

Verifikasi dan pengesahan ulang

Misalkan ada dua klien ETH, satu menggunakan PSE ZK-EVM dan yang lainnya menggunakan Polygon ZK-EVM, pada titik ini, kedua implementasi telah berkembang ke titik di mana mereka dapat membuktikan eksekusi blok ETH dalam waktu kurang dari 5 detik, dan untuk setiap sistem bukti, ada cukup banyak sukarelawan independen yang menjalankan perangkat keras untuk menghasilkan bukti.

Sayangnya, karena sistem proof-of-the-box individu tidak diformalkan, mereka tidak dapat diberi insentif dalam protokol, namun, kami mengantisipasi bahwa biaya menjalankan bukti akan lebih rendah dibandingkan dengan penelitian dan pengembangan, sehingga kami dapat dengan mudah mendanai provers melalui lembaga yang didanai untuk barang publik.

Katakanlah seseorang menerbitkan ZKEvmClaimNetworkTransaction, tetapi mereka hanya menerbitkan bukti versi PSE ZK-EVM. Simpul Bukti Poligon ZK-EVM melihat ini, menghitung dan menerbitkan ulang objek, bersama dengan Bukti Poligon ZK-EVM.

Ini akan meningkatkan total penundaan maksimum antara node jujur paling awal yang menerima blok dan node jujur terbaru yang menerima blok yang sama dari δ menjadi 2δ+Tprove (dengan asumsi Tprove<5s di sini).

Kabar baiknya, bagaimanapun, adalah bahwa jika kita mengadopsi finalitas slot tunggal, kita hampir pasti dapat “menyalurkan” penundaan tambahan ini bersama dengan latensi konsensus multi-putaran yang melekat pada SSF. Misalnya, dalam proposal 4 slot ini, langkah “suara kepala” mungkin hanya perlu memeriksa validitas blok dasar, tetapi langkah “membekukan dan mengonfirmasi” akan membutuhkan adanya bukti.

Ekstensi: Dukungan untuk “hampir-EVM”

Tujuan yang diinginkan untuk fitur ZK-EVM adalah mendukung “hampir-EVM”: EVM dengan fitur tambahan. Ini dapat mencakup prakompilasi baru, opcode baru, kontrak yang dapat berupa EVM atau VM yang sama sekali berbeda (misalnya di Arbitrum Stylus), atau bahkan beberapa EVM paralel dengan komunikasi silang sinkron.

Beberapa modifikasi dapat didukung dengan cara yang sederhana: kita dapat mendefinisikan bahasa yang memungkinkan ZKEVMClaimTransaction untuk melewati deskripsi lengkap dari aturan EVM yang dimodifikasi. Ini dapat digunakan dalam situasi berikut:

1. Tabel biaya gas yang disesuaikan (pengguna tidak diizinkan untuk mengurangi biaya gas, tetapi mereka dapat meningkatkannya)
2. Nonaktifkan opcode tertentu
3. Tetapkan nomor blok (ini berarti ada aturan yang berbeda tergantung pada hard fork)
4. Atur bendera untuk mengaktifkan set lengkap perubahan EVM yang sudah distandarisasi untuk L2 tetapi tidak untuk penggunaan L1, atau perubahan sederhana lainnya

Untuk memungkinkan pengguna menambahkan fungsionalitas baru dengan cara yang lebih terbuka, misalnya dengan memperkenalkan prakompilasi baru (atau opcode), kita dapat menambahkan cara untuk menyertakan catatan input/output yang telah dikompilasi sebelumnya di bagian blob ZKEVMClaimNetworkTransaction:

kelas PrecompileInputOutputTran(Container):used_precompile_addresses: Daftar[Address][VersionedHash]inputs_commitments: Daftar[Bytes]Keluaran: Daftar

Eksekusi EVM akan dimodifikasi sebagai berikut. Array yang disebut input akan diinisialisasi sebagai kosong. Setiap kali alamat di used_precompile_addresses dipanggil, kita menambahkan objek InputsRecord(callee_address, Gas, input_calldata) ke input dan mengatur RETURNDATA yang disebut ke output[i]。 Akhirnya, kami memeriksa bahwa used_precompile_addresses disebut len(outputs) beberapa kali, dan inputs_commitments cocok dengan hasil komitmen blob yang dihasilkan untuk serialisasi input SSZ. Tujuan mengekspos input _commitments adalah untuk memungkinkan SNARK eksternal membuktikan hubungan antara input dan output.

Perhatikan asimetri antara input dan output, di mana input disimpan dalam hash dan output disimpan dalam byte yang harus disediakan. Ini karena eksekusi perlu dilakukan oleh klien yang hanya melihat input dan memahami EVM. Eksekusi EVM telah menghasilkan input untuk mereka, jadi mereka hanya perlu memeriksa apakah input yang dihasilkan cocok dengan input yang dinyatakan, yang hanya memerlukan pemeriksaan hash. Namun, output harus sepenuhnya disediakan untuk mereka, sehingga ketersediaan data harus tersedia.

Fitur lain yang berguna mungkin untuk memungkinkan “transaksi istimewa” dipanggil dari akun pengirim mana pun. Transaksi ini dapat dijalankan antara dua transaksi lain, atau dalam transaksi lain (dan mungkin istimewa), sambil memanggil prakompilasi. Ini dapat digunakan untuk memungkinkan mekanisme non-EVM memanggil kembali ke EVM.

Desain dapat dimodifikasi untuk mendukung opcode baru atau yang dimodifikasi, selain prakompilasi baru atau yang dimodifikasi. Bahkan dengan hanya prakompilasi, desainnya sangat kuat. Sebagai contoh:

Fungsionalitas seperti Arbitrum Stylus dapat didukung dengan mengatur used_precompile_addresses untuk menyertakan daftar alamat akun reguler dengan bendera tertentu yang ditetapkan dalam objek akun mereka di negara bagian, dan menghasilkan SNARKs yang membuktikan bahwa mereka dibangun dengan benar, di mana kontrak dapat menulis kodenya dalam EVM atau WASM (atau VM lainnya). Transaksi istimewa dapat digunakan untuk memungkinkan akun WASM memanggil kembali EVM.

Dengan menambahkan pemeriksaan eksternal untuk memastikan bahwa catatan input/output dan transaksi istimewa yang dilakukan oleh beberapa EVM dicocokkan dengan cara yang benar, sistem paralel dari beberapa EVM yang berkomunikasi satu sama lain melalui saluran sinkronisasi dapat ditunjukkan.

ZK-EVM tipe 4 dapat bekerja dengan memiliki beberapa implementasi: satu yang mengubah Soliditas atau bahasa tingkat tinggi lainnya langsung menjadi VM yang ramah SNARK, dan yang lain yang mengkompilasinya menjadi kode EVM dan mengeksekusinya di ZK-EVM yang ditentukan. Implementasi kedua (dan pasti lebih lambat) hanya dapat berjalan jika prover kegagalan mengirim transaksi yang mengklaim memiliki kesalahan, dan jika mereka dapat menawarkan bahwa keduanya menangani transaksi yang berbeda, hadiah dapat dikumpulkan.

Anda dapat menerapkan VM asinkron murni dengan mengembalikan nol ke semua panggilan dan memetakan panggilan ke transaksi istimewa yang ditambahkan ke akhir blok.

Ekstensi: Dukungan untuk Bukti Negara

Tantangan dengan desain di atas adalah bahwa ia benar-benar stateless, yang membuatnya miskin dalam hal efisiensi data. Dengan kompresi data yang ideal, kompresi stateful dapat membuat ERC20 mengirimkan lebih banyak ruang hemat hingga 3x dibandingkan dengan kompresi stateless saja.

Selain itu, EVM stateful tidak diharuskan untuk memberikan data saksi. Dalam kedua kasus, prinsipnya sama: adalah sia-sia untuk meminta data tersedia ketika kita sudah tahu bahwa data tersedia karena itu dimasukkan atau diproduksi oleh eksekusi EVM sebelumnya. **

Jika kita ingin membuat fitur ZK-EVM stateful, kita memiliki dua opsi:

Mengharuskan σpre menjadi null, atau daftar kunci dan nilai yang telah dideklarasikan sebelumnya yang datanya tersedia, atau beberapa σpost yang dieksekusi sebelumnya.

Tambahkan komitmen blob ke tupel (σpre, σpost, proof) untuk tanda terima R yang dihasilkan oleh blok. Setiap komitmen blob yang dibuat atau digunakan sebelumnya yang dapat dirujuk dalam ZKEVMClaimTransaction dan diakses selama pelaksanaannya, termasuk komitmen yang mewakili blok, saksi, tanda terima, atau bahkan transaksi blob EIP-4844 reguler (mungkin ada beberapa batas waktu, yang dapat dirujuk oleh serangkaian instruksi: “Masukkan byte N komitmen i pada posisi j blok + data saksi… N+k-1”)

(1) Arti dasarnya adalah: alih-alih menetapkan verifikasi EVM tanpa kewarganegaraan, kami akan membuat rantai anak EVM.

dan (2) pada dasarnya membuat algoritma kompresi stateful bawaan minimal yang menggunakan blob yang sebelumnya digunakan atau dihasilkan sebagai kamus. Kedua hal ini menempatkan beban pada node prover, dan hanya node prover untuk menyimpan lebih banyak informasi;

Dalam kasus (2), lebih mudah untuk membatasi waktu beban ini, sedangkan dalam kasus (1) lebih sulit.

Argumen untuk sistem multi-prover tertutup dan data off-chain

Sistem multi-prover tertutup, di mana ada sejumlah bukti tetap dalam struktur M-of-N, menghindari banyak kompleksitas yang dijelaskan di atas. Secara khusus, sistem multi-attester tertutup tidak perlu khawatir tentang memastikan bahwa data ada secara on-chain. Selain itu, sistem multi-attester tertutup akan memungkinkan bukti ZK-EVM dieksekusi secara off-chain, membuatnya kompatibel dengan solusi plasma EVM.

Namun, sistem multi-attester tertutup meningkatkan kompleksitas tata kelola dan melemahkan kemampuan audit, yang merupakan biaya tinggi yang perlu ditimbang terhadap keunggulan ini.

Jika kita membangun ZK-EVM dan menjadikannya fitur protokol, apa peran berkelanjutan dari proyek L2?

Fungsi validasi EVM yang saat ini diterapkan oleh tim L2 sendiri akan ditangani oleh protokol, tetapi proyek L2 akan tetap bertanggung jawab atas sejumlah fungsi penting:

• Pra-konfirmasi cepat: Finalitas slot tunggal dapat memperlambat slot L1, sedangkan L2 sudah menyediakan pengguna dengan layanan yang didukung pra-konfirmasi dengan keamanannya sendiri, dengan latensi kurang dari satu slot. Layanan ini akan terus menjadi tanggung jawab L2.
• Strategi mitigasi MEV: Ini mungkin termasuk fitur seperti mempool terenkripsi, pemilihan berurutan berbasis reputasi, dll., Yang enggan diterapkan oleh L1.
• Ekstensi ke EVM: Proyek Tingkat 2 dapat memperkenalkan ekstensi signifikan ke EVM yang memberikan nilai signifikan bagi penggunanya. Ini termasuk “hampir-EVM” dan pendekatan yang sama sekali berbeda, seperti dukungan WASM Arbitrum Stylus dan bahasa Kairo SNARK yang ramah.
• Kenyamanan bagi pengguna dan pengembang: Tim Tingkat 2 berupaya keras untuk menarik pengguna dan proyek ke dalam ekosistem mereka dan membuat mereka merasa diterima; mereka dibayar dengan menangkap MEV dan biaya kemacetan dalam jaringan mereka. Hubungan ini akan tetap ada.