V Shen Xinwen: Setelah ETH Fang built-in ZK, ke mana arah Layer2?

Diproduksi | Oharian

Kompilasi | Lu Gila

Hari ini, Vitalik Buterin menerbitkan sebuah artikel baru di komunitas ETH berjudul “Seperti apa bentuk ZK-EVM built-in?”. Artikel ini membahas bagaimana ETH Workshop akan memiliki ZK-EVM sendiri yang dibangun ke dalam peningkatan jaringan di masa mendatang.

Seperti yang kita ketahui bersama, dalam konteks lambatnya perkembangan ETH, hampir semua mainstream Layer 2 sudah memiliki ZK-EVM, namun ketika mainnet bengkel ETH merangkum ZK-EVM-nya sendiri, apakah akan terjadi konflik antara role positioning mainnet dan Layer 2?

Dalam artikel ini, Vitalik Buterin menekankan pentingnya kompatibilitas, ketersediaan data, dan auditabilitas, dan mengeksplorasi kemungkinan penerapan penguji yang efisien dan stateful. Selain itu, artikel ini mengeksplorasi kemungkinan penerapan bukti stateful untuk efisiensi, dan membahas peran proyek Layer 2 dalam menyediakan strategi pra-konfirmasi dan mitigasi MEV yang cepat. Artikel ini mencerminkan keseimbangan dalam memajukan pengembangan jaringan ETH melalui ZK-EVM sambil mempertahankan fleksibilitasnya.

Odaily Planet Daily telah menyusun artikel asli, dan teks lengkap artikel tersebut adalah sebagai berikut:

rollup optimis dan rollup ZK, sebagai protokol EVM Layer-2 di atas ETH, keduanya mengandalkan verifikasi EVM. Namun, ini mengharuskan mereka untuk mempercayai basis kode yang besar, dan jika ada bug dalam basis kode ini, maka VM ini berisiko diretas. Ini juga berarti bahwa ZK-EVM, bahkan jika mereka ingin sepenuhnya setara dengan L1 EVM, akan memerlukan beberapa bentuk tata kelola untuk mereplikasi perubahan L1 EVM ke dalam implementasi EVM mereka sendiri.

Ini bukan situasi yang ideal. Karena proyek-proyek ini mereplikasi fungsionalitas yang sudah ada di ETH Workshop Protocol untuk diri mereka sendiri - ETH Governance sudah bertanggung jawab untuk meningkatkan dan memperbaiki bug, dan apa yang pada dasarnya dilakukan ZK-EVM adalah memvalidasi blok ETH Layer 1. Selama beberapa tahun ke depan, kami berharap klien ringan menjadi lebih dan lebih kuat, dan akan segera dapat menggunakan ZK-SNARKs untuk sepenuhnya memvalidasi eksekusi L1 EVM. Pada saat itu, jaringan ETH sebenarnya akan memiliki ZK-EVM dalam satu paket. Jadi, muncul pertanyaan: mengapa tidak membuat ZK-EVM ini tersedia secara native untuk rollup juga?

Artikel ini akan menjelaskan beberapa versi “Encapsulated ZK-EVM”, menganalisis trade-off mereka, tantangan desain, dan alasan untuk tidak pergi ke arah tertentu. Manfaat menerapkan fungsionalitas protokol harus dibandingkan dengan manfaat membiarkan ekosistem menangani transaksi dan menjaga protokol yang mendasarinya tetap sederhana.

Fitur utama apa yang ingin kita dapatkan dari ZK-EVM yang dienkapsulasi?

Apa atribut utama yang dapat kita harapkan dari paket ZK-EVM?

Fungsi dasar: Validasi blok ETH. Fungsi protokol (yang belum ditentukan apakah itu opcode, prakompilasi, atau mekanisme lainnya) harus dapat menerima setidaknya root pre-state, blok, dan root post-state sebagai input, dan memverifikasi bahwa root post-state sebenarnya adalah hasil dari mengeksekusi blok itu di atas root pre-state. Kompatibel dengan multi-klien ETH Workshop. Ini berarti bahwa kami ingin menghindari sistem pengesahan tunggal bawaan, dan sebagai gantinya mengizinkan klien yang berbeda untuk menggunakan sistem pengesahan yang berbeda.

Ini juga berarti beberapa hal:

Persyaratan ketersediaan data: Untuk setiap eksekusi EVM yang menggunakan bukti ZK-EVM yang dienkapsulasi, kami ingin menjamin bahwa data yang mendasarinya dapat digunakan sehingga prover yang menggunakan sistem pengesahan yang berbeda dapat membuktikan kembali eksekusi, dan klien yang mengandalkan sistem pengesahan tersebut dapat memvalidasi bukti yang baru dihasilkan tersebut.

Bukti berada di luar EVM dan struktur data potongan:* Fungsi ZK-EVM tidak benar-benar mengambil SNARKs sebagai input di 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, yang isinya dapat diakses oleh opcode atau prakompilasi, dan aturan konsensus sisi klien memeriksa ketersediaan data dan bukti klaim yang dibuat di blok, masing-masing.

Auditabilitas: Jika ada eksekusi yang terbukti, kami ingin data yang mendasarinya dapat digunakan sehingga jika terjadi kesalahan, baik pengguna maupun pengembang dapat memeriksanya. Bahkan, ini menambah satu alasan lagi mengapa persyaratan ketersediaan data itu penting.

Kemampuan upgrade: Jika kami menemukan bug dalam solusi ZK-EVM tertentu, kami ingin dapat memperbaikinya dengan cepat. Ini berarti bahwa tidak perlu hard fork untuk memperbaiki masalah. Ini menambahkan alasan lain mengapa bukti di luar EVM dan struktur data blok penting.

Salah satu daya tarik untuk mendukung “perkiraan EVM” :**L2 adalah kemampuan untuk berinovasi pada lapisan eksekusi dan menskalakan EVM. Jika VM L2 hanya sedikit berbeda dari EVM, maka alangkah baiknya jika L2 dapat menggunakan ZK-EVM dalam protokol asli untuk bagian yang sama dengan EVM, dan hanya mengandalkan kode mereka sendiri untuk menangani bagian yang berbeda. Ini dapat dicapai dengan merancang fungsi ZK-EVM yang memungkinkan pemanggil untuk menentukan bidang bit atau opcode atau daftar alamat, yang akan ditangani oleh formulir yang disediakan secara eksternal daripada EVM itu sendiri. Kami juga dapat membuat biaya gas dapat disesuaikan sampai batas tertentu.

Sistem multiklien “Terbuka” vs. “tertutup”

“Mentalitas multi-klien” mungkin merupakan persyaratan paling kontroversial dalam daftar ini. Salah satu pilihannya adalah meninggalkan multiklien dan fokus pada satu skema ZK-SNARK, yang akan menyederhanakan desain. Tetapi dengan mengorbankan “pergeseran filosofis” yang lebih besar di ETH Workshop (karena ini secara efektif meninggalkan mentalitas multiklien lama ETH Workshop) dan memperkenalkan risiko yang lebih besar. Di masa depan jangka panjang, misalnya, ketika teknik verifikasi formal menjadi lebih baik, mungkin lebih baik untuk menempuh rute ini, tetapi untuk saat ini tampaknya terlalu berisiko.

Pilihan lain adalah sistem multiklien tertutup dengan seperangkat sistem pengesahan tetap yang dikenal dalam protokol. Misalnya, kami mungkin memutuskan untuk menggunakan tiga ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM, dan Kakarot. Sebuah blok membutuhkan bukti dari setidaknya dua dari tiga ini agar valid. Ini lebih baik daripada sistem bukti tunggal, tetapi itu membuat sistem kurang mudah beradaptasi karena fakta bahwa pengguna harus mempertahankan validator untuk setiap sistem bukti yang ada, akan ada proses tata kelola yang tak terhindarkan untuk memasukkan sistem bukti baru, dll.

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

Fitur utama apa yang kita inginkan dalam implementasi ZK-EVM?

Selain kebenaran fungsional dasar dan jaminan keamanan, atribut yang paling penting adalah kecepatan. Meskipun dimungkinkan untuk merancang protokol asinkron dengan fungsionalitas ZK-EVM bawaan di mana setiap klaim hanya mengembalikan hasil setelah slot N, masalahnya menjadi lebih mudah jika kami dapat dengan andal menjamin bahwa bukti akan dihasilkan dalam hitungan detik, sehingga apa yang terjadi di setiap blok mandiri.

Meskipun dibutuhkan beberapa menit atau jam untuk menghasilkan bukti untuk blok ETH hari ini, kita tahu bahwa tidak ada alasan teoritis untuk mencegah paralelisasi massa: kita selalu dapat merakit GPU yang cukup untuk membuktikan bagian-bagian yang berbeda dari eksekusi blok secara terpisah dan kemudian menggunakan SNARKs rekursif untuk menyatukan bukti-bukti itu. Selain itu, proses pembuktian dapat lebih dioptimalkan melalui akselerasi perangkat keras FPGA dan ASIC. Sebenarnya sampai di sana, bagaimanapun, adalah tantangan teknik yang tidak boleh diremehkan.

Seperti apa sebenarnya fungsi ZK-EVM dalam protokol?

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

kelas ZKEVMClaimTransaction(Container):
pra_state_root: byte 32
post_state_root: byte 32
transaction_and_witness_blob_pointers: Daftar[VersionedHash]
…

Seperti EIP-4844, objek yang diteruskan dalam mempool adalah versi modifikasi dari transaksi:

kelas ZKEvmClaimNetworkTransaction(Container):
pra_state_root: byte 32
post_state_root: byte 32
Bukti >: byte
transaksi_and_witness_blobs: Daftar[Bytes[FIELD_ELEMENTS_PER_BLOB * 31 ]]

Yang terakhir dapat dikonversi ke yang pertama, tetapi tidak sebaliknya. Kami juga telah memperluas objek sespan blok (diperkenalkan dalam EIP-4844) untuk menyertakan daftar bukti yang dinyatakan dalam blok.

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

Pada lapisan konsensus, kami telah menambahkan aturan validasi yang hanya akan menerima blok jika klien melihat bukti yang valid dari setiap klaim di blok. Bukti harus merupakan rangkaian dari bukti ZK-SNARK, diserialkan sebagai sepasang transaksi \ _and \ _witness \ _blobs, dan pra \ _state \ _root valid dengan (i) dan Saksi (ii) menghasilkan posting yang benar \ _state \ _root. (Blokir, Saksikan) Secara potensial, pelanggan dapat memilih untuk menunggu M-of-N untuk beberapa jenis bukti.

Catatan di sini adalah bahwa eksekusi blok itu sendiri dapat dengan mudah dianggap sebagai triplet yang perlu diperiksa bersama dengan triple yang disediakan dalam objek ZKEVMClaimTransaction (σpre, σpost, Proof).

Akibatnya, implementasi ZK-EVM pengguna dapat menggantikan klien eksekusinya, yang masih akan digunakan oleh (i) provers dan pembangun blok, dan (ii) node yang peduli tentang pengindeksan dan penyimpanan data untuk penggunaan lokal.

Validasi dan validasi ulang

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

Sayangnya, karena sistem pengesahan independen tidak built-in, mereka tidak dapat diberi insentif dalam protokol, namun, kami mengantisipasi bahwa biaya menjalankan prover lebih rendah dibandingkan dengan biaya R&D, sehingga kami dapat menggunakan badan generik untuk mendanai barang publik untuk provers.

Katakanlah seseorang merilis ZKEvmClaimNetworkTransaction, tetapi mereka hanya merilis versi bukti PSE ZK-EVM. Simpul bukti Polygon ZK-EVM melihat ini dan menggunakan bukti Polygon ZK-EVM untuk menghitung dan menerbitkan ulang objek.

Ini meningkatkan total penundaan maksimum antara node jujur tertua yang menerima blok dan node jujur terbaru yang menerima blok yang sama δ: 2 δ+Tprove (dengan asumsi Tprove<5 s).

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

Ekstensi: Dukungan untuk “Perkiraan EVM”

Tujuan ideal untuk fitur ZK-EVM adalah mendukung “perkiraan EVM”: yaitu, EVM dengan beberapa fungsi tambahan bawaan. Ini dapat mencakup prakompilasi baru, opcode baru, atau bahkan opsi di mana kontrak dapat ditulis dalam EVM atau mesin virtual yang sama sekali berbeda (misalnya, seperti 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 bisa dilakukan:

• Tabel gas khusus (pengguna tidak dapat mengurangi biaya gas, tetapi dapat meningkatkannya)
• Nonaktifkan opcode tertentu
• Mengatur nomor blok (ini akan menyiratkan aturan yang berbeda tergantung pada hard fork)
• Tetapkan bendera yang mengaktifkan set lengkap perubahan EVM yang telah dinormalisasi untuk penggunaan L2 daripada penggunaan L1, atau perubahan sederhana lainnya

Untuk memungkinkan pengguna menambahkan fitur baru dengan cara yang lebih terbuka, dengan memperkenalkan precompile (atau opcode) baru, kita dapat menyertakan catatan input/output yang telah dikompilasi sebelumnya dalam blob ZKEVMClaimNetworkTransaction:

kelas PrecompileInputOutputTran(Container):
digunakan_precompile_addresses: Daftar[Address]
masukan_commitments: Daftar[VersionedHash]
output: Daftar[Bytes]

Eksekusi EVM akan dimodifikasi sebagai berikut. Menginisialisasi array input kosong. Setiap kali alamat di used_precompile_addresses dipanggil, kita menambahkan objek InputsRecord(callee_address, gas, input_calldata) ke input dan mengatur RETURNDATA panggilan ke output[i]。 Akhirnya, kami memeriksa bahwa used_precompile_addresses telah disebut len(outputs) beberapa kali, dan inputs_commitments cocok dengan hasil yang dijanjikan dengan membuat serialisasi SSZ pada input. Tujuan mengekspos input \ _commitments adalah untuk memudahkan SNARKs eksternal untuk 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 diklaim, yang hanya memerlukan pemeriksaan hash. Namun, output harus diberikan kepada mereka secara keseluruhan dan oleh karena itu harus menjadi data yang dapat digunakan.

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

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

• Dengan mengatur _precompile_addresses yang digunakan untuk menyertakan daftar alamat akun normal dengan bendera tertentu di negara bagian, dan membuat SNARK untuk membuktikan bahwa itu dibangun dengan benar, Anda dapat mendukung fitur gaya Arbitrum Stylus di mana kontrak dapat ditulis dalam EVM atau WASM (atau VM lain). Transaksi istimewa dapat digunakan untuk memungkinkan akun WASM dipanggil kembali ke EVM.
• Dengan menambahkan pemeriksaan eksternal untuk memastikan bahwa catatan input/output dan transaksi istimewa yang dilakukan oleh beberapa EVM dicocokkan dengan cara yang benar, Anda dapat mendemonstrasikan sistem paralel dari beberapa EVM yang berbicara satu sama lain melalui saluran sinkronisasi.
• ZK-EVM Tipe 4 dapat dioperasikan dengan memiliki beberapa implementasi: satu yang secara langsung mengubah Solidity atau bahasa tingkat tinggi lainnya menjadi VM ramah SNARK, dan satu lagi yang mengkompilasinya menjadi kode EVM dan mengeksekusinya di ZK-EVM bawaan. Implementasi kedua (dan pasti lebih lambat) hanya dapat berjalan jika fault prover mengirimkan transaksi yang menyatakan bahwa ada bug, dan mengumpulkan hadiah jika mereka dapat menawarkan bahwa keduanya menangani transaksi yang berbeda. VM asinkron murni dapat dicapai dengan mengembalikan nol ke semua panggilan dan memetakan panggilan ke transaksi istimewa yang ditambahkan ke akhir blok.

Ekstensi: Dukungan untuk pemberi sertifikasi stateful

Salah satu tantangan dengan desain di atas adalah bahwa hal itu benar-benar stateless, yang membuatnya data-tidak efisien. Dalam kasus kompresi data yang ideal, pengiriman ERC 20 menggunakan kompresi stateful dapat mencapai 3x lebih hemat ruang daripada kompresi state-only.

Selain itu, EVM stateful tidak perlu memberikan data saksi. Dalam kedua kasus, prinsipnya sama: ketika kita sudah tahu bahwa data dapat digunakan karena dimasukkan atau dihasilkan dalam eksekusi EVM sebelumnya, maka sia-sia untuk meminta data tersebut tersedia.

Jika kita ingin fitur ZK-EVM memiliki status, maka kita memiliki dua opsi:

1. Persyaratan σpre Entah itu kosong, itu adalah daftar data yang tersedia dengan kunci dan nilai yang dideklarasikan, atau dieksekusi sebelum waktu tertentu σpost 。

2. Menuju ( σpre, σpos, Bukti ) Tiga kali lipat untuk menambahkan tanda terima yang dibuat untuk blok R komitmen blob. Setiap komitmen blob yang dibuat atau digunakan sebelumnya, termasuk yang mewakili blok, saksi, tanda terima, atau bahkan transaksi blob EIP-4844 biasa, mungkin memiliki beberapa batasan waktu yang dapat dirujuk dalam ZKEVMClaimTransaction dan diakses selama pelaksanaannya (mungkin melalui serangkaian instruksi: "Akan dilakukan I Byte dari N… N+k-1 dimasukkan ke dalam potongan+data saksi J "）。

Opsi 1 berarti bahwa alih-alih memiliki verifikasi EVM stateless built-in, lebih baik memiliki EVM child chain built-in. Opsi dua pada dasarnya membuat algoritma kompresi stateful bawaan minimal yang menggunakan blob yang sebelumnya digunakan atau dihasilkan sebagai kamus. Kedua pendekatan menempatkan beban pada simpul prover, yang merupakan satu-satunya yang perlu menyimpan lebih banyak informasi, dan dalam kasus kedua, lebih mudah untuk memiliki batas waktu pada beban ini daripada dalam kasus satu.

Parameter untuk multi-cerverser tertutup dan data off-chain

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

Namun, sistem multi-prover tertutup menambah kompleksitas tata kelola dan menghilangkan kemampuan audit, yang merupakan biaya tinggi yang perlu ditimbang terhadap manfaat ini.

Jika kita membangun ZK-EVM ke dalamnya dan menjadikannya fitur protokol, apa peran “proyek Layer 2”?

Fungsi verifikasi EVM yang saat ini diterapkan oleh tim Layer 2 sendiri akan ditangani oleh protokol, tetapi proyek Layer 2 masih bertanggung jawab atas sejumlah fitur penting:

• Pra-konfirmasi cepat: Finalitas slot tunggal dapat memperlambat slot Layer 1, sementara proyek Layer 2 sudah menyediakan pengguna mereka dengan “pra-konfirmasi” yang didukung oleh keamanan Layer 2 sendiri dengan latensi yang jauh lebih rendah daripada slot tunggal. Layanan ini akan terus sepenuhnya berada di bawah tanggung jawab Layer 2.
• Strategi mitigasi MEV (Miner Extractable Value): Ini dapat mencakup mempool terenkripsi, pemilihan sequencer berbasis reputasi, dan fitur lain yang enggan diterapkan oleh Layer 1.
• Ekstensi ke EVM: Proyek Layer 2 dapat memberikan ekstensi yang signifikan ke EVM bagi penggunanya. Ini termasuk “perkiraan EVM” dan pendekatan yang berbeda secara fundamental seperti dukungan WASM Arbitrum Stylus dan bahasa Kairo yang ramah SNARK.
• Kenyamanan bagi pengguna dan pengembang: Tim Layer 2 telah melakukan banyak hal untuk menarik pengguna dan proyek ke ekosistem mereka dan membuat mereka merasa diterima; mereka diberi kompensasi dengan menangkap MEV dan biaya kemacetan dalam jaringan mereka. Hubungan ini akan tetap ada.