Dari Type1 hingga Type4, apa perbedaan berbagai tipe ZK-EVM?

Penulis asli| Lisa Akselrod

Dikompilasi | Odaily Planet Harian 0xAyA

*Catatan Editor: Penulis menyusunnya berdasarkan artikel pengenalan ZK-EVM yang sebelumnya ditulis oleh Vitalik, dan memperkenalkan secara detail berbagai jenis ZK-EVM dan perbedaan di antara keduanya. *

Sekitar setahun yang lalu, sekelompok ZK-EVM mengumumkan bahwa mereka akan meluncurkan testnet. Langkah-langkah ini telah membangkitkan rasa ingin tahu komunitas Ethereum dan memicu diskusi tentang perbedaan di balik istilah-istilah seperti kesetaraan Ethereum dan kesetaraan EVM.

Demi kejelasan, Vitalik menulis artikel penting berjudul "Berbagai Jenis ZK-EVM" yang mengklasifikasikan berbagai ZK-EVM menjadi empat jenis dan menjelaskan perbedaannya.

Ide intinya adalah: Tipe 1 (misalnya Taiko) sepenuhnya setara dengan Ethereum, sedangkan Tipe 4 (misalnya zkSync) unggul dalam pembuatan bukti yang efisien. Semua tipe lainnya, Tipe 2, Tipe 2.5 dan Tipe 3, berada di antara keduanya (misalnya Polygon zkEVM, Scroll, Linea).

Sebagian besar ZK-EVM pada awalnya adalah Tipe 2.5 dan Tipe 3, dengan beberapa niat untuk berevolusi menuju Tipe 1 atau Tipe 2 terungkap, meskipun proyek-proyek ini belum memberikan jadwal atau komitmen khusus untuk hal ini.

**Artikel ini berfokus pada perbedaan antara Tipe 1 dan Tipe 2/Tipe 2.5, dan menjelaskan kemungkinan konsekuensi dari pelanggaran kesetaraan Ethereum. Kami juga akan membahas secara singkat jenis lainnya. **

Tujuan utama ZK-EVM adalah untuk menskalakan Ethereum, yaitu meningkatkan throughput Ethereum sambil mempertahankan fitur lainnya (keamanan, pengalaman pengembang, dll.). Idealnya, ZK-EVM harus mampu:

• Mendemonstrasikan eksekusi bytecode asli yang tidak dimodifikasi (mencakup 100% opcode Ethereum) sesuai dengan spesifikasi Mesin Virtual Ethereum di Buku Kuning.
• Hasilkan bukti dengan cepat dengan biaya rendah.
• Memungkinkan 100% penggunaan kembali alat dan infrastruktur yang dikembangkan untuk Ethereum.
• Izinkan dApp Ethereum apa pun untuk diterapkan ulang di ZK-EVM "apa adanya" ("apa adanya" berarti tidak diperlukan perubahan, tidak ada kompromi).

Perbedaan antara tipe ZK-EVM

Di dunia ZK-EVM, perbedaannya terutama berasal dari tingkat kesetaraan Ethereum/EVM, dampak elemen yang tidak bersahabat dengan ZK pada biaya dan kecepatan pembuatan bukti, dan kompleksitas implementasi sirkuit (seperti konstruksi atau status VM pohon).

Mari kita analisa perbedaan-perbedaan ini, khususnya membedakan Tipe 1 dari Tipe 2/Tipe 2.5. Kami juga akan membahas kasus penggunaan yang paling relevan untuk setiap jenis.

Saat membandingkan berbagai jenis, tabel berikut sering digunakan:

Bagi mereka yang tidak bekerja penuh waktu di bidang ZK-EVM, tabel ini mungkin tampak membingungkan, jadi mari kita terjemahkan istilah-istilah ini ke dalam istilah awam dan lihat:

Diagram ini memberikan gambaran yang lebih jelas tentang tampilan masing-masing tipe sebenarnya, namun masih sedikit kabur. Mari kita jelajahi dunia ZK-EVM sepenuhnya dengan menjelaskan masing-masing tipe satu per satu.

Tipe 1: Setara dengan Ethereum

Vitalik Buterin：

“ZK-EVM Tipe 1 adalah hal yang pada akhirnya kami perlukan untuk membuat lapisan Ethereum 1 itu sendiri lebih terukur.”

Tipe 1 berarti tidak mengubah bagian mana pun dari sistem Ethereum untuk memudahkan pembuatan bukti. Tidak ada perubahan pada Ethereum berarti tidak ada kompromi pada keamanan, karena sebagian besar kriptografi primitif (misalnya fungsi hash), infrastruktur pengembang (misalnya debugger) atau infrastruktur rantai (misalnya klien eksekusi) sudah menjalani pengujian lapangan selama 9 tahun.

ZK-EVM tipe 1 tidak menggantikan apa pun: hash, pohon status, pohon transaksi, prakompilasi, atau logika konsensus lainnya, semuanya persis sama dengan EVM mainnet.

• Tipe 1 adalah satu-satunya tipe yang dapat memverifikasi rantai Ethereum itu sendiri - mulai dari seluruh blok hingga eksekusi transaksi, kontrak pintar, dan logika akun.

Tipe 2: Setara dengan EVM

Tipe 2 membuat pembuatan bukti lebih cepat dan pengembangan sirkuit lebih mudah dengan menghilangkan beberapa bagian yang tidak mendukung ZK. Namun, karena konsekuensinya, hal ini mungkin membuat pengembangan bagian lain dari ZK-rollup (seperti perangkat lunak node) menjadi lebih kompleks. Kompleksitas ini mungkin disebabkan oleh ketidaksesuaian antara praktik terbaik yang ada dan alat pengujian serta perubahan yang diterapkan (seperti perubahan pohon status).

*Catatan: Setara dengan Ethereum dan setara dengan EVM tidaklah sama. Meskipun kesetaraan dengan Ethereum berarti tidak ada bagian dari Ethereum yang diubah, yang berarti bahwa Ethereum sepenuhnya kompatibel dengan semua dApps Ethereum, kesetaraan dengan EVM memungkinkan perubahan pada struktur data (seperti struktur blok atau pohon status). *

Meskipun penyesuaian ini mungkin tampak kecil, namun berdampak pada kompatibilitas Ethereum. Mengubah struktur data dapat menyebabkan dApps Ethereum tidak kompatibel dengan ZK-EVM Tipe 2, terutama saat memvalidasi bukti Merkle tentang transaksi, penerimaan, atau status masa lalu (seperti jembatan lintas rantai).

Hapus elemen tidak ramah ZK

Modifikasi pada Ethereum dimaksudkan untuk menyederhanakan pengembangan dan meningkatkan kecepatan pembuatan bukti. Tujuannya adalah untuk memangkas bagian-bagian Ethereum yang mengandalkan kriptografi tanpa pengetahuan yang tidak bersahabat. Dalam istilah yang lebih teknis, bagian yang memerlukan sejumlah besar gerbang (operasi penjumlahan dan perkalian) karena domain non-lokal (seperti fungsi hash), sejumlah besar perkalian multi-skalar dan/atau transformasi Fourier cepat (FFT); atau Hanya bagian yang memerlukan banyak manipulasi.

Contoh spesifik elemen tanpa pengetahuan yang tidak bersahabat yang dapat dimodifikasi oleh Tipe 2 ZK-EVM:

• Fungsi hash: Meskipun Ethereum menggunakan fungsi hash Keccak, banyak ZK-EVM menggunakan fungsi hash Poseidon, yang memerlukan jumlah gerbang yang jauh lebih kecil. Misalnya, mari kita perkirakan berapa banyak fungsi hash dari setiap jenis yang dapat dihitung per detik (yaitu perbandingan yang menunjukkan kecepatan pembangkitan).

Fungsi hash Poseidon memiliki keunggulan kecepatan yang signifikan dalam pembuatan bukti.

Namun, penting untuk dicatat bahwa primitif kriptografi yang lebih baru tidak sepopuler kriptografi primitif yang sudah dikenal luas oleh komunitas. Meskipun Poseidon mungkin menawarkan kecepatan, karakteristik Keccak yang telah teruji dalam pertempuran membuatnya lebih kuat dan aman karena diadopsi secara luas.

Inilah sebabnya mengapa Keccak, meskipun lebih tua dan diadopsi oleh komunitas yang lebih luas (di industri lain, seperti sistem keamanan atau sensor pada perangkat pintar), dapat dianggap lebih teruji dan teruji dibandingkan Poseidon, yang tentunya ada dalam komunitas ZK. Hash baru berfungsi untuk membuat dan menggunakan.

• Pohon status untuk penyimpanan data: Misalnya, ketika Ethereum menggunakan pohon Merkle Patricia (menggunakan hashing Keccak), beberapa ZK-EVM Tipe 2 memilih pohon Merkle yang jarang (menggunakan hashing Poseidon). Mengubah pohon status dapat menyebabkan beberapa ketidakcocokan. Misalnya, pohon Merkle Ethereum memiliki tipe node yang berbeda dan menggunakan RLP untuk menyandikan data, yang merupakan hal yang sulit dilakukan di ZK.
• Struktur blok: Blok berisi sejumlah besar informasi. Namun, saat menjelajahi L2, kami hanya peduli pada ution_payload_header (yaitu hash blok). Pada gambar di bawah ini terdapat struktur (block hash) dari seluruh data yang terdapat pada ution_payload_header.

**Harap diperhatikan: mengubah salah satu komponen ini akan merusak kesetaraan Ethereum. **

Tipe 2.5: Setara dengan EVM, dengan mempertimbangkan biaya bahan bakar

Tipe 2.5 ZK-EVM meningkatkan biaya gas untuk operasi tertentu yang sulit dibuktikan dengan menggunakan teknologi ZK di EVM.

Mengingat batas gas Ethereum per blok (30 juta gas), meningkatkan biaya gas per opcode akan menghasilkan lebih sedikit opcode per blok. Oleh karena itu, opcode yang tidak terlalu rumit dapat dimasukkan ke dalam sebuah blok. Opcode yang lebih sederhana memungkinkan sirkuit menjadi lebih kecil dan bukti dihasilkan lebih cepat.

• gas adalah satuan ukuran kerja.
• Harga Opcode dihitung dalam gas.
• Opcode menentukan operasi dalam instruksi bahasa mesin.
• Sebuah program adalah daftar opcode statis. Eksekusi program adalah jejak eksekusi.
• Jejak eksekusi adalah daftar opcode tertentu yang dieksekusi oleh suatu program.

Bagian yang sulit dibuktikan ZK antara lain:

• Opcode Keccak dan beberapa opcode lain yang bergantung pada Keccak.
• Prakompilasi: fungsi yang dapat diakses oleh EVM. Beberapa di antaranya memberikan tugas yang kompleks atau rumit secara matematis, seperti fungsi kriptografi (seperti blake 2 f atau sha 256). Mereka tidak dieksekusi di dalam EVM, melainkan sebagai fungsi yang dikodekan secara keras di klien eksekusi dan diekspos ke EVM menggunakan PANGGILAN ke alamat khusus.
• Akses memori: misalnya, meningkatkan ukuran slot memori (misalnya, Ethereum menggunakan memori yang selaras dengan byte, sedangkan Polygon zkEVM menggunakan slot memori 32-byte). Untuk memungkinkan perubahan ini, logika internal opcode tertentu (seperti MLOAD) harus diubah.
• Penyimpanan (yaitu mengubah fungsi hash atau pohon status seperti dijelaskan di atas).

Perubahan biaya bahan bakar dapat mengurangi kompatibilitas alat pengembang dan merusak beberapa dApps. Misalnya, kontrak pintar yang sering mengeksekusi opcode dengan meningkatnya biaya bahan bakar mungkin melebihi batas blok gas dan gagal dijalankan.

Tipe 3: Hampir setara dengan EVM

Tipe 3 ZK-EVM menghilangkan prakompilasi yang tidak berlaku untuk ZK dan dapat menyesuaikan akses memori dan penyimpanan.

dApps yang mengandalkan aplikasi terkompilasi yang telah dihapus perlu ditulis ulang. Dalam kasus yang tidak biasa, perbedaan dalam cara penanganan kasus edge oleh Tipe 3 ZK-EVM dan EVM asli mungkin memerlukan penyesuaian pada dApp.

Tipe 4 (setara dengan bahasa tingkat tinggi)

Tipe 4 sudah jauh dari EVM.

Kode sumber kontrak pintar yang ditulis dalam bahasa tingkat tinggi (misalnya, Solidity, Zinc) dikompilasi menjadi representasi perantara, menghasilkan opcode yang cocok untuk mesin virtual ramah ZK.

• Metode ini menghindari pembuatan bukti ZK untuk setiap langkah eksekusi EVM, sehingga sangat mengurangi pekerjaan pembuktian.
• Meskipun kontrak dapat dikompilasi, pekerjaan lebih lanjut diperlukan jika dApp menggunakan bytecode tulisan tangan EVM. *ZK-EVM Tipe 4 juga memerlukan alat pengembangnya sendiri (hanya level opcode) seperti debugger dan pelacak.

Di sirkuit ZK yang membuktikan lintasan eksekusi, setiap langkah mengimplementasikan batasan, dan biaya setiap langkah adalah jumlah dari semua opcode. Oleh karena itu, Tipe 4 ZK-EVM dirancang untuk menggunakan opcode kompleks sesedikit mungkin untuk mengoptimalkan efisiensi.

Perlu disebutkan bahwa opcode khusus (opcode yang tidak tercakup dalam Ethereum) memungkinkan untuk meneruskan fitur-fitur baru yang tidak mungkin dilakukan pada Ethereum secara default. Misalnya, melakukan beberapa panggilan untuk eksekusi melalui fitur abstraksi akun, atau meluncurkan dompet kontrak pintar menggunakan solusi siap pakai seperti Argent.

Ringkaslah

Tipe ZK-EVM yang berbeda memprioritaskan tujuan dan karakteristik yang berbeda. Tipe 1 berfokus pada kesetaraan Ethereum, sedangkan Tipe 4 memprioritaskan pembuatan bukti yang efisien. Tipe lain berada di antara kedua ekstrem ini, dan banyak protokol ZK-EVM Tipe 2 dan 3 telah mengumumkan niat mereka untuk beralih ke setara Ethereum.

Keempat jenis klasifikasi ini mungkin bukan keadaan akhir dari ZK rollup dan mungkin memerlukan modifikasi lebih lanjut di masa mendatang. Misalnya, beberapa ZK-EVM dapat menjadi hybrid, Tipe 1/2 dapat mengembangkan solusi Tipe 4 (dengan efisiensi setinggi mungkin) dan menyediakan dApps dengan kedua opsi tersebut, sedangkan ZK-EVM Tipe 3 dan 4 dapat menambahkan opsi yang setara dengan Ethereum.