Jelaskan lima jenis ZK-EVM secara rinci: arsitektur, kelebihan dan kekurangan serta solusi

Pengarang Asli: s

Kompilasi teks asli: Deep Tide TechFlow

Artikel ini membahas lima jenis ZK-EVM secara mendetail, masing-masing dengan arsitektur unik, kelebihan dan kekurangan, serta kemungkinan solusinya.

Selain itu, artikel ini juga mencantumkan beberapa contoh proyek praktis agar pembaca dapat lebih memahami kinerja jenis ini dalam aplikasi praktis. Apakah Anda seorang pengembang blockchain atau pembaca yang tertarik dengan teknologi blockchain, artikel ini akan memberi Anda wawasan yang mendalam dan ringkas.

Mari jelajahi jenis-jenis ZK-EVM, pro dan kontranya.

1. Tipe 1: sepenuhnya setara dengan Ethereum;

2. Tipe 2: sepenuhnya setara dengan EVM;

3. Tipe 2.5: Sebagian setara dengan EVM;

4. Tipe 3: hampir setara dengan EVM;

5. Tipe 4: di mana bahasa tingkat tinggi setara.

Tipe 1: sepenuhnya setara dengan Ethereum

Arsitektur: Ini persis sama dengan Ethereum dan tidak mengubah bagian mana pun dari sistem Ethereum.

keuntungan

Kompatibilitas Sempurna:

• Kemampuan untuk memverifikasi blok Ethereum;
• Bantu membuat Ethereum L1 lebih terukur;
• Cocok untuk Rollups karena dapat menggunakan kembali banyak infrastruktur.

kekurangan

Kompatibilitas Sempurna:

• Ethereum pada awalnya tidak dirancang untuk fungsionalitas ZK;
• Banyak komponen Ethereum memerlukan banyak perhitungan untuk menghasilkan bukti ZK (ZKP);
• Bukti untuk blok Ethereum membutuhkan waktu berjam-jam untuk dihasilkan.

Pemecahan masalah:

• Prover paralelisasi skala besar;
• ZK-SNARK ASIC.

Tipe 2: sepenuhnya setara dengan EVM

Arsitektur:

• Struktur data (struktur blok dan pohon status) sangat berbeda dari Ethereum;
• Sepenuhnya kompatibel dengan aplikasi yang ada;
• Modifikasi kecil pada Ethereum untuk pengembangan yang lebih mudah dan pembuatan bukti yang lebih cepat.

keuntungan

• Memberikan waktu pembuktian yang lebih cepat daripada Tipe 1;
• Struktur data tidak diakses langsung oleh EVM;
• Aplikasi yang berjalan di Ethereum: cenderung berjalan di Tipe 2;
• Dukungan untuk alat debugging EVM yang ada dan infrastruktur pengembangan lainnya.

kekurangan

Sebelum memahami kekurangannya, pahami dulu apa itu "Keccak":

• Algoritma hashing dari blockchain Ethereum;
• Digunakan untuk melindungi data di Ethereum;
• Pastikan pesan diubah menjadi hash.

Tipe 2 tidak kompatibel dengan aplikasi yang memverifikasi bukti blok historis Merkle untuk memverifikasi informasi tentang riwayat transaksi, tanda terima/status. Ini karena jika algoritma hashing berubah (tidak lagi Keccak), buktinya menjadi tidak valid.

Kita dapat menganggap Keccak sebagai bahasa yang menggunakan bukti Merkle (abjad) Jika ZK-EVM menggantikan Keccak dengan algoritme hashing lain (seperti Poseidon), bukti Merkle akan menjadi asing dan aplikasi tidak akan dapat membacanya dan memvalidasi klaimnya.

Solusi potensial untuk kekurangan: Ethereum dapat menambahkan prakompilasi akses sejarah yang dapat diskalakan di masa mendatang.

proyek

• Menggulir;
• Poligon Hermez.

Namun, proyek-proyek ini belum mengimplementasikan prekompilasi yang lebih canggih, oleh karena itu, mereka dapat dianggap sebagai Tipe 2 yang tidak lengkap.

Tipe 2.5: Sebagian setara dengan EVM

Arsitektur:

Meningkatkan biaya gas untuk operasi EVM tertentu yang sulit dibuktikan ZK;

• Terkompilasi sebelumnya;
• Keccak opcode;
• Cara memanggil kontrak;
• Akses memori;
• penyimpanan.

keuntungan

• Secara signifikan meningkatkan waktu pembuktian kasus terburuk;
• Lebih aman daripada membuat perubahan lebih dalam pada tumpukan EVM.

kekurangan

• Kompatibilitas alat pengembangan berkurang;
• Beberapa aplikasi tidak akan berfungsi.

Tipe 3: Hampir setara dengan EVM

Arsitektur:

• Dalam implementasi ZK-EVM, beberapa fungsi yang sangat sulit diimplementasikan dihapus, biasanya dikompilasi sebelumnya;
• ZK-EVM memiliki sedikit perbedaan dalam cara menangani kode kontrak, memori, atau tumpukan.

keuntungan

• mempersingkat waktu verifikasi;
• Membuat EVM lebih mudah untuk dikembangkan;
• Tujuannya adalah untuk meminta penulisan ulang minimal untuk aplikasi yang kurang kompatibel.

kekurangan

• Lebih banyak ketidakcocokan;
• Aplikasi yang menggunakan prakompilasi yang dihapus di Tipe 3 perlu ditulis ulang.

proyek

Saat ini, Scroll dan Polygon dianggap Tipe 3, namun, tim ZK-EVM tidak boleh puas dengan Tipe 3, Tipe 3 adalah tahap transisi di mana ZK-EVM menambahkan prakompilasi untuk meningkatkan kompatibilitas dan berpindah ke Tipe 2.5.

Tipe 4: padanan bahasa tingkat tinggi

Arsitektur:

• Terima kode kontrak pintar yang ditulis dalam bahasa tingkat tinggi (seperti Solidity, Vyper);
• Dikompilasi ke bahasa yang dirancang agar ramah ZK-SNARK.

keuntungan

• Waktu pembuktian yang sangat cepat;
• Mengurangi biaya overhead (biaya, waktu dan usaha komputasi);
• Turunkan penghalang untuk menjadi pembukti: tingkatkan derajat desentralisasi.

kekurangan

• Dalam sistem tipe 4, alamat kontrak mungkin berbeda dari alamat di EVM, karena alamat bergantung pada bytecode yang tepat;
• Ini berarti bahwa jika ZK-EVM tipe 4 tidak memiliki bytecode, mereka tidak akan dapat membuat alamat;
• Tipe 4 tidak akan kompatibel dengan aplikasi yang mengandalkan kontrak kontrafaktual dalam kasus di atas;
• Banyak infrastruktur debug yang tidak portabel karena dijalankan pada kode byte EVM.

proyek

• zkSync

Terakhir, kita dapat membandingkan tipe-tipe di atas bersama-sama untuk membantu semua orang memahami zkEVM yang berbeda secara sekilas.