Artikel Baru Vitalik: Masa Depan dan Tantangan ZK-EVM

Judul asli: “Seperti apa bentuk “ZK-EVM yang diabadikan”?”

Penulis asli: Vitalik

Kompilasi asli: Luccy, BlockBeats

*Catatan editor: Pada 13 Desember, Vitalik Buterin, salah satu pendiri ETH Place, menerbitkan sebuah artikel yang menyelidiki kemungkinan implementasi “ZK-EVM” (Mesin Virtual Ethereum Tanpa Pengetahuan) dan membahas desain berbagai versi ZK-EVM. *

*Konsep ZK-EVM Vitalik bertujuan untuk mengurangi duplikasi fitur protokol Ethereum oleh proyek Layer-2 dan meningkatkan efisiensinya dalam memvalidasi blok Ethereum Layer-1. Artikel tersebut menunjukkan bahwa protokol EVM Layer-2 saat ini (seperti Optimistic Rollups dan ZK Rollups) bergantung pada mekanisme verifikasi EVM, tetapi ini juga berarti bahwa mereka harus mempercayai basis kode yang besar. Begitu ada kerentanan dalam basis kode, komputer virtual ini dapat berisiko diserang. *

*Selain itu, ia menyebutkan dukungan untuk “hampir-EVM”, yang memungkinkan L2 VM untuk menggunakan ZK-EVM dalam protokol dengan hanya perbedaan kecil dari EVM, sementara juga memberikan fleksibilitas untuk beberapa penyesuaian EVM. *

Protokol EVM layer-2 pada ETH, termasuk rollup op dan rollup ZK, bergantung pada validasi EVM. Namun, ini mengharuskan mereka untuk mempercayai basis kode yang besar, dan jika stok kode itu berada dalam celah, VM ini berisiko diretas. Selain itu, bahkan ZK-EVM, yang ingin sepenuhnya setara dengan L1 EVM, memerlukan beberapa bentuk tata kelola untuk mereplikasi perubahan dari L1 EVM ke dalam implementasi EVM mereka sendiri.

Situasi ini tidak ideal, karena proyek-proyek ini mereplikasi fungsionalitas yang sudah ada dalam protokol ETH Fang, dan tata kelola ETH Fang sudah bertanggung jawab untuk meningkatkan dan memperbaiki bug: ZK-EVM pada dasarnya melakukan pekerjaan yang sama seperti memvalidasi blok ETH L1! Selain itu, dalam beberapa tahun ke depan, kami berharap klien ringan menjadi semakin kuat, dan segera sepenuhnya memvalidasi eksekusi L1 ETH Fang menggunakan ZK-SNARKs. Pada titik ini, jaringan ETH akan secara efektif memiliki ZK-EVM bawaan. Jadi muncul pertanyaan: mengapa tidak membuat lokalisasi ZK-EVM ini tersedia untuk proyek rollup?

Artikel ini akan menjelaskan beberapa kemungkinan versi “ZK-EVM yang diabadikan” dan mengeksplorasi trade-off dan tantangan desain, serta alasan untuk tidak memilih arah tertentu. Keuntungan dari penerapan fitur protokol harus ditimbang terhadap manfaat yang tersisa untuk ekosistem dan manfaat menjaga protokol yang mendasarinya tetap sederhana.

Apa atribut utama yang bisa kita harapkan dari ZK-EVM yang diabadikan sebagai standar?

Fungsi dasar: Validasi blok ETH. Fitur protokol (yang masih belum pasti apakah itu opcode, prakompilasi, atau mekanisme lainnya) setidaknya harus menerima root pre-state, blok, dan root post-state sebagai input, dan memverifikasi bahwa root post-state memang hasil dari mengeksekusi blok di atas root pre-state.

Kompatibilitas dengan konsep multi-klien ETH. Ini berarti bahwa kami ingin menghindari mengejar sistem pengesahan tunggal dan sebagai gantinya mengizinkan klien yang berbeda untuk menggunakan sistem pengesahan yang berbeda. Ini, pada gilirannya, berarti beberapa poin:

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

· Bukti ada di luar EVM dan struktur data potongan: Fitur ZK-EVM tidak secara langsung menggunakan SNARKs sebagai input dalam EVM, karena klien yang berbeda mengharapkan berbagai jenis SNARKs. Sebaliknya, ini mungkin mirip dengan validasi blob: transaksi dapat berisi pernyataan yang perlu dibuktikan (pra-status, badan blok, pasca-status), konten yang dapat diakses oleh opcode atau prakompilasi, dan aturan konsensus sisi klien akan memeriksa ketersediaan data dan keberadaan bukti untuk setiap klaim yang dibuat di blok, masing-masing.

Kemampuan audit. Jika ada eksekusi yang terbukti, kami ingin data yang mendasarinya dapat digunakan sehingga jika terjadi kesalahan, pengguna dan pengembang dapat memeriksanya. Dalam praktiknya, ini menambah alasan lain pentingnya persyaratan ketersediaan data.

Kemampuan upgrade. Jika kami menemukan kerentanan dalam solusi ZK-EVM tertentu, kami ingin dapat memperbaikinya dengan cepat. Ini berarti bahwa tidak perlu hard fork untuk memperbaikinya. Ini menambahkan alasan lain untuk membuktikan pentingnya ada di luar EVM dan struktur data blok.

Jaringan yang mendukung hampir-EVM. Salah satu daya tarik L2 adalah kemampuan untuk berinovasi pada lapisan eksekusi dan menskalakan EVM. Jika mesin virtual (VM) dari L2 yang diberikan hanya sedikit berbeda dari EVM, alangkah baiknya jika L2 masih bisa menggunakan ZK-EVM dalam protokol asli yang sama dengan EVM, hanya mengandalkan kodenya sendiri untuk bagian EVM yang sama dan kode mereka sendiri untuk bagian yang berbeda. Ini dapat dicapai dengan merancang fitur ZK-EVM yang memungkinkan pemanggil untuk menentukan beberapa opcode, alamat, atau bitfield yang ditangani oleh tabel yang disediakan secara eksternal, bukan oleh EVM itu sendiri. Kami juga dapat membuat biaya gas terbuka untuk penyesuaian sampai batas tertentu.

Sistem multi-klien “terbuka” dan “tertutup”

“Konsep multi-klien” mungkin adalah persyaratan yang paling ditegaskan dalam daftar ini. Ada pilihan untuk meninggalkan ide ini dan berkonsentrasi pada solusi ZK-SNARK, yang akan menyederhanakan desain, tetapi dengan biaya “pergeseran filosofis” yang lebih besar pada Lokakarya ETH (karena ini sebenarnya akan menjadi keberangkatan dari filosofi multiklien jangka panjang ETH Workshop) dan pengenalan risiko yang lebih besar. Di masa depan jangka panjang, misalnya, jika teknik verifikasi formal menjadi lebih baik, mungkin lebih baik memilih jalur ini, tetapi untuk saat ini, risikonya tampak 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 perlu membawa bukti dua dari tiga ini agar dianggap 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 diketahui, pasti ada proses tata kelola politik untuk memasukkan sistem bukti baru, dan sebagainya.

Ini membuat saya lebih memilih sistem multi-klien terbuka, di mana bukti ditempatkan “di luar blok” dan diverifikasi secara terpisah oleh klien. Pengguna individu dapat memvalidasi blok dengan klien yang mereka inginkan, selama setidaknya ada satu prover yang menghasilkan bukti sistem. Sistem pengesahan akan mendapatkan pengaruh dengan meyakinkan pengguna untuk menjalankannya, bukan dengan meyakinkan proses tata kelola protokol. Namun, pendekatan ini memang memiliki lebih banyak biaya kompleksitas yang akan kita lihat.

Apa fitur utama yang kami inginkan dari implementasi ZK-EVM?

Selain fungsionalitas dasar yang benar dan jaminan keamanan, fitur terpenting adalah kecepatan. Meskipun dimungkinkan untuk merancang fitur ZK-EVM dalam protokol yang tidak sinkron dan hanya mengembalikan satu jawaban untuk setiap klaim setelah penundaan slot waktu N, masalah bahwa segala sesuatu yang terjadi di setiap blok mandiri akan lebih mudah jika kami dapat menjamin bahwa bukti akan dihasilkan dalam hitungan detik.

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

Seperti apa fitur ZK-EVM dalam protokol?

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

Mirip dengan EIP-4844, objek yang diteruskan dalam mempool akan menjadi versi modifikasi dari transaksi:

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 dibuat dalam satu blok.

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

Di atas lapisan konsensus, kami menambahkan aturan validasi bahwa blok hanya akan diterima jika klien melihat bukti yang valid dari setiap klaim di blok. Bukti harus berupa pernyataan pengesahan ZK-SNARK, yaitu, rangkaian transaksi \ _and \ _witness \ _blobs adalah serialisasi pasangan (Blok, Saksi), blok eksekusi berlaku pada pra \ _state \ _root menggunakan Saksi (i), dan (ii) menghasilkan posting yang benar \ _state \ _root. Secara potensial, klien dapat memilih untuk menunggu M-of-N untuk beberapa jenis pengesahan.

Ada catatan filosofis di sini bahwa eksekusi blok itu sendiri dapat diperlakukan sebagai sesuatu yang hanya perlu diperiksa bersama dengan salah satu dari triples (σpre, σpost, Proof) yang disediakan dalam objek ZKEVMClaimTransaction. 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.

Verifikasi dan pengesahan 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 untuk setiap sistem bukti, ada cukup banyak sukarelawan independen yang menjalankan perangkat keras untuk menghasilkan bukti.

Sayangnya, karena sistem pengesahan individu tidak diformalkan, mereka tidak dapat diberi insentif dalam protokol, namun, kami mengantisipasi bahwa biaya menjalankan node proof-of-proof akan lebih rendah dibandingkan dengan biaya penelitian dan pengembangan, sehingga kami dapat dengan mudah mendanai node proof-of-proof melalui pendanaan badan umum untuk barang publik.

Katakanlah seseorang menerbitkan ZKEvmClaimNetworkTransaction, kecuali mereka hanya menerbitkan bukti versi PSE ZK-EVM. Melihat ini, simpul Bukti Poligon ZK-EVM menghitung dan menerbitkan ulang objek dengan Bukti Poligon ZK-EVM.

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

Kabar baiknya, bagaimanapun, adalah bahwa jika kita mengambil determinisme slot tunggal, kita hampir pasti dapat “menyalurkan” latensi ekstra 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: Mendukung “hampir-EVM”

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

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

· Tabel biaya gas khusus (pengguna tidak diizinkan untuk mengurangi biaya gas, tetapi dapat meningkatkannya)

· Nonaktifkan opcode tertentu

· Tetapkan nomor blok (ini berarti akan ada aturan yang berbeda tergantung pada hard fork)

· Tetapkan bendera yang mengaktifkan set lengkap perubahan EVM yang telah distandarisasi untuk penggunaan L2 alih-alih penggunaan L1, atau perubahan sederhana lainnya

Untuk memungkinkan pengguna menambahkan fungsionalitas baru dengan memperkenalkan prakompilasi baru (atau opcode) dengan cara yang lebih terbuka, kita dapat menambahkan konten yang berisi transkrip input/output yang telah dikompilasi sebelumnya ke bagian blob ZKEVMClaimNetworkTransaction:

Eksekusi EVM akan dimodifikasi sebagai berikut. Input array akan diinisialisasi sebagai kosong. Setiap kali alamat di used_precompile_addresses dipanggil, kami 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 serialisasi SSZ dari komitmen blob yang dihasilkan ke input. Tujuan mengekspos input _commitments adalah untuk memfasilitasi 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 dinyatakan, yang hanya memerlukan pemeriksaan hash. Namun, output harus diberikan kepada mereka dalam bentuk penuh, sehingga harus tersedia data.

Fitur lain yang berguna mungkin untuk memungkinkan “transaksi istimewa”, yaitu, transaksi yang memulai panggilan dari akun pengirim mana pun. Transaksi ini dapat berjalan di antara dua transaksi lain, atau saat memanggil prakompilasi dalam transaksi lain (dan mungkin istimewa). Ini dapat digunakan untuk memungkinkan mekanisme non-EVM memanggil 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 sangat kuat. Sebagai contoh:

· Dengan mengatur _precompile_addresses yang digunakan, termasuk daftar alamat akun reguler dengan bendera tertentu yang diatur dalam objek akun mereka di negara bagian, dan membuat SNARK untuk membuktikan bahwa itu dibangun dengan benar, Anda dapat mendukung fitur gaya Arbitrum Stylus di mana kode untuk kontrak dapat ditulis dalam EVM atau WASM (atau VM lainnya). Transaksi istimewa dapat digunakan untuk memungkinkan akun WASM dipanggil kembali ke EVM.

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

· Jenis keempat ZK-EVM dapat bekerja dengan memiliki beberapa implementasi: satu yang mengubah Solidity atau bahasa tingkat tinggi lainnya langsung menjadi VM SNARK-friendly, dan yang lain yang mengkompilasinya menjadi kode EVM dan mengeksekusinya di ZK-EVM yang diabadikan. Implementasi kedua (dan pasti lebih lambat) hanya berjalan jika prover kesalahan mengirimkan transaksi yang menyatakan bahwa ada kesalahan, dan jika mereka mampu memberikan transaksi yang ditangani secara berbeda oleh keduanya, mereka dapat diberi imbalan.

· VM asinkron murni dapat dicapai dengan membuat semua panggilan mengembalikan nol dan memetakan panggilan ke transaksi istimewa yang ditambahkan ke akhir blok.

Ekstensi: Dukungan untuk penguji stateful

Salah satu tantangan dengan desain di atas adalah bahwa hal itu benar-benar stateless, yang membuatnya kurang efisien dalam hal pemanfaatan data. Dengan mendukung kompresi stateful, pengiriman ERC 20 dapat menghemat ruang hingga 3x lebih banyak daripada saat menggunakan kompresi stateless saja, menggunakan kompresi data yang ideal.

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

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

1. Mengharuskan σpre kosong, atau daftar data yang tersedia untuk pasangan kunci-nilai yang telah dideklarasikan sebelumnya, atau beberapa σpost yang dieksekusi sebelumnya.

2. Tambahkan komitmen blob dari tanda terima R yang dihasilkan blok ke tupel (σpre, σpost, Proof). Setiap janji blob yang dibuat atau digunakan sebelumnya, termasuk yang mewakili blok, saksi, tanda terima, atau bahkan transaksi blob EIP-4844 reguler, yang mungkin memiliki batas waktu, dapat dirujuk dalam ZKEVMClaimTransaction dan diakses selama pelaksanaannya (mungkin melalui serangkaian instruksi: "Masukkan byte N komitmen i pada posisi j blok + data saksi… N+k− 1 」)。

(1) Pada dasarnya mengatakan: alih-alih memperkuat verifikasi EVM tanpa kewarganegaraan, kami akan memperkuat rantai anak EVM. (2) Pada dasarnya membuat algoritma kompresi stateful minimal bawaan yang menggunakan blob yang sebelumnya digunakan atau dihasilkan sebagai kamus. Kedua hal ini menambah beban menyimpan lebih banyak informasi ke simpul bukti, yang hanya merupakan simpul bukti, dan dalam kasus (2), lebih mudah untuk membatasi beban ini hingga jangka waktu tertentu daripada dalam kasus (1).

Perdebatan antara sistem multi-bukti tertutup dan data off-chain

Sistem multi-prover tertutup menghindari banyak kompleksitas di atas dengan memperbaiki sejumlah bukti dalam struktur M-of-N. 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 plasma EVM.

Namun, sistem multi-prover tertutup meningkatkan kompleksitas tata kelola dan mengurangi auditabilitas, yang merupakan trade-off antara biaya tinggi dan manfaat ini.

Jika kita menetapkan ZK-EVM sebagai fitur protokol, apa peran berkelanjutan dari “proyek L2”?

Protokol ini akan menangani fitur verifikasi EVM yang saat ini diterapkan sendiri oleh tim L2, tetapi proyek L2 masih akan bertanggung jawab atas sejumlah fitur penting:

Pra-konfirmasi cepat: Finalitas slot tunggal dapat memperlambat slot L1, dan proyek L2 sudah menyediakan pengguna mereka dengan “pra-konfirmasi” yang didukung oleh keamanan L2 sendiri, dengan latensi yang jauh lebih rendah daripada satu slot. Layanan ini akan terus menjadi kewajiban L2 murni.

Strategi mitigasi MEV: Ini mungkin termasuk mempool terenkripsi, pemilihan berurutan berbasis reputasi, dan fitur lain yang enggan diterapkan L1.

Ekstensi ke EVM: Proyek L2 dapat menggabungkan ekstensi substansial ke EVM untuk memberikan nilai yang signifikan bagi penggunanya. Ini termasuk “hampir-EVM” dan pendekatan yang berbeda secara fundamental seperti dukungan WASM Arbitrum Stylus dan bahasa Kairo SNARK yang ramah.

Kenyamanan bagi pengguna dan pengembang: Tim L2 melakukan banyak pekerjaan untuk menarik pengguna dan proyek ke ekosistem mereka dan membuat mereka merasa diterima, dan mereka diberi kompensasi dengan memperoleh MEV dan biaya kemacetan dalam jaringan mereka. Hubungan ini akan tetap ada.

Link ke artikel asli