Teks asli: (IOSG Weekly Brief | Cara bertahan dari ZKVM, penjelasan rinci tentang perselisihan antar faksi #159)
Penulis: Bryan, IOSG Ventures
Daftar isi
Implementasi rangkaian sistem pembuktian ZKP - berbasis sirkuit VS berbasis mesin virtual (berbasis vm)
Prinsip desain ZKVM
Perbandingan antara VM berbasis STARK
Mengapa Risc0 menarik
Fokus utama pembahasan rollup pada tahun 2022 lalu sepertinya terfokus pada ZkEVM, namun jangan lupa bahwa ZkVM juga merupakan sarana ekspansi lainnya. Meskipun ZkEVM bukan fokus artikel ini, ada baiknya mengingat kembali perbedaan antara ZkVM dan ZkEVM dalam beberapa dimensi:
Kompatibilitas: Meskipun keduanya merupakan ekspansi, namun fokusnya berbeda. Fokus ZkEVM adalah untuk secara langsung mencapai kompatibilitas dengan EVM yang ada, sedangkan posisi ZkVM adalah untuk mencapai ekspansi penuh, yaitu mengoptimalkan logika dan kinerja dapps, kompatibilitas bukanlah prioritas. Setelah lapisan bawah diatur, kompatibilitas EVM juga dapat dicapai. Kinerja: Keduanya memiliki hambatan kinerja yang relatif dapat diperkirakan. Hambatan utama ZkEVM adalah biaya tambahan yang timbul ketika kompatibilitas dengan EVM tidak cocok untuk pengemasan dalam sistem sertifikasi ZK. Hambatan dari ZkVM adalah karena diperkenalkannya set instruksi ISA, batasan pada hasil akhir menjadi lebih kompleks. Pengalaman pengembang: ZkEVM Tipe II (seperti Scroll, Taiko) berfokus pada kompatibilitas dengan Bytecode EVM. Dengan kata lain, kode EVM pada level Bytecode dan di atasnya dapat menghasilkan bukti tanpa pengetahuan yang sesuai melalui ZkEVM. Untuk ZkVM, ada dua arah: Satu arah adalah membuat DSL sendiri (seperti Kairo), dan arah lainnya adalah kompatibel dengan bahasa yang lebih matang seperti C++/Rust (seperti Risc0). Di masa depan, kami berharap pengembang Ethereum soliditas asli akan dapat bermigrasi ke ZkEVM tanpa biaya, dan aplikasi yang lebih baru dan lebih kuat akan berjalan di ZkVM. Banyak orang yang masih mengingat gambaran ini. CairoVM tidak ada hubungannya dengan ZkEVM. Alasan penting dari perjuangan antar faksi adalah perbedaan ide desain.
Sebelum membahas ZkVM, pertama-tama kita memikirkan bagaimana cara mengimplementasikan sistem bukti ZK di blockchain. Secara garis besar, ada dua cara untuk mengimplementasikan sirkuit - sistem berbasis sirkuit dan sistem berbasis mesin virtual (berbasis vm).
Pertama-tama, fungsi sistem berbasis sirkuit adalah untuk secara langsung mengubah program menjadi batasan dan mengirimkannya ke sistem pembuktian; sistem berbasis mesin virtual mengeksekusi program melalui set instruksi (ISA). jejak. Jejak eksekusi ini kemudian akan dipetakan ke dalam batasan dan kemudian dikirim ke sistem pembuktian.
Untuk sistem berbasis sirkuit, komputasi suatu program dibatasi oleh setiap mesin yang menjalankan program tersebut. Untuk sistem berbasis mesin virtual, ISA tertanam dalam generator sirkuit dan menghasilkan batasan program. Pada saat yang sama, generator sirkuit memiliki keterbatasan pada set instruksi, siklus proses, memori, dll. Mesin virtual memberikan keserbagunaan, yaitu mesin apa pun dapat menjalankan suatu program selama kondisi menjalankan program tersebut berada dalam batasan di atas.
Program zkp di mesin virtual mungkin melewati proses berikut:
Sumber gambar: Bryan, IOSG Ventures
Keuntungan dan Kerugian:
Dari sudut pandang pengembang, pengembangan sistem berbasis sirkuit seringkali memerlukan pemahaman mendalam tentang biaya setiap kendala. Namun, untuk menulis program mesin virtual, sirkuitnya statis, dan pengembang harus lebih memperhatikan instruksinya. Dari sudut pandang verifikator, sistem berbasis sirkuit dan mesin virtual berbeda secara signifikan dalam keumuman sirkuit, dengan asumsi SNARK murni yang sama digunakan sebagai backend. Sistem rangkaian menghasilkan rangkaian yang berbeda untuk setiap program, sedangkan mesin virtual menghasilkan rangkaian yang sama untuk program yang berbeda. Artinya, dalam satu rollup, sistem sirkuit perlu menerapkan beberapa kontrak verifikator di L1. Dari perspektif aplikasi, mesin virtual membuat logika aplikasi lebih kompleks dengan menyematkan model memori ke dalam desain, dan tujuan penggunaan sistem sirkuit adalah untuk meningkatkan kinerja program. Dari perspektif kompleksitas sistem, mesin virtual memasukkan lebih banyak kompleksitas ke dalam sistem, seperti model memori, komunikasi antara host dan tamu, dll. Sebagai perbandingan, sistem sirkuit lebih sederhana.
Berikut ini adalah pratinjau berbagai proyek berbasis sirkuit dan berbasis mesin virtual yang saat ini ada di L1/L2:
Kredit Gambar: Bryan, Prinsip Desain Mesin Virtual IOSG Ventures
Di mesin virtual, ada dua prinsip desain utama. Pertama, pastikan program dijalankan dengan benar. Dengan kata lain, keluaran (yaitu batasan) dan masukan (yaitu program) harus cocok dengan benar. Biasanya ini dilakukan melalui set instruksi ISA. Kedua, pastikan kompiler berfungsi dengan benar saat mengonversi dari bahasa tingkat tinggi ke format batasan yang sesuai.
1. Kumpulan instruksi ISA
Menentukan cara kerja generator sirkuit. Tanggung jawab utamanya adalah memetakan instruksi dengan benar ke dalam batasan, yang kemudian dimasukkan ke dalam sistem pembuktian. sistem zk semuanya menggunakan RISC (set instruksi yang dikurangi). Ada dua opsi ISA:
Yang pertama adalah membangun ISA khusus (custom ISA), seperti terlihat pada desain Kairo. Secara umum, ada empat jenis logika kendala sebagai berikut.
Fokus desain dasar ISA kustom adalah untuk memastikan bahwa terdapat sesedikit mungkin kendala sehingga eksekusi dan verifikasi program berjalan dengan cepat.
Yang kedua adalah menggunakan ISA yang ada (Existing ISA), yang diadopsi dalam desain Risc0. Selain menargetkan waktu eksekusi yang bersih, ISA yang ada seperti Risc-V menawarkan manfaat tambahan seperti ramah terhadap bahasa front-end dan perangkat keras backend. Salah satu pertanyaan (yang mungkin belum dijawab) adalah apakah ISA yang ada akan tertinggal dalam waktu verifikasi (karena waktu verifikasi bukan merupakan tujuan desain utama Risc-V).
2. Penyusun
Secara garis besar, compiler secara bertahap menerjemahkan suatu bahasa pemrograman ke dalam kode mesin. Dalam konteks ZK, ini mengacu pada representasi kode tingkat rendah yang dikompilasi ke dalam sistem batasan (R1CS, QAP, AIR, dll.) menggunakan bahasa tingkat tinggi seperti C, C++, Rust, dll. Ada dua metode,
Rancang kompiler berdasarkan representasi sirkuit yang ada di ZK - misalnya, di ZK, representasi sirkuit dimulai dari perpustakaan yang dapat dipanggil langsung seperti Bellman dan bahasa tingkat rendah seperti Circom. Untuk menggabungkan representasi yang berbeda, kompiler seperti Zokrates (yang merupakan DSL) bertujuan untuk menyediakan lapisan abstraksi yang dapat dikompilasi menjadi representasi tingkat rendah yang sewenang-wenang. Membangun infrastruktur kompiler (yang sudah ada). Logika dasarnya adalah menggunakan representasi perantara untuk beberapa frontend dan backend.
Kompiler Risc0 didasarkan pada representasi perantara multi-level (MLIR) dan dapat menghasilkan banyak IR (mirip dengan LLVM). IR yang berbeda memberikan fleksibilitas bagi pengembang, karena IR yang berbeda memiliki prioritas desainnya sendiri. Misalnya, beberapa di antaranya dioptimalkan secara khusus untuk perangkat keras, sehingga pengembang dapat memilih sesuai keinginannya. Ide serupa dapat dilihat di vnTinyRAM dan TinyRAM menggunakan GCC. ZkSync adalah contoh lain dari pemanfaatan infrastruktur kompiler.
Selain itu, Anda juga dapat melihat beberapa infrastruktur kompiler untuk zk, seperti CirC, yang juga meminjam beberapa ide desain dari LLVM.
Selain dua langkah desain paling penting di atas, ada beberapa pertimbangan lain:
1. Trade-off antara keamanan sistem (security) dan biaya verifikasi (verifier cost)
Semakin tinggi jumlah bit yang digunakan oleh sistem (yaitu semakin tinggi keamanannya), semakin tinggi pula biaya verifikasinya. Keamanan tercermin dalam generator kunci (seperti kurva elips yang direpresentasikan dalam SNARK).
2. Kompatibilitas dengan front-end dan back-end
Kompatibilitas tergantung pada ketersediaan representasi perantara untuk rangkaian. IR memerlukan keseimbangan antara kebenaran (apakah keluaran program cocok dengan masukan + apakah keluaran sesuai dengan sistem pembuktian) dan fleksibilitas (mendukung banyak front-end dan back-end). Jika IR awalnya dirancang untuk menyelesaikan sistem kendala tingkat rendah seperti R1CS, kompatibilitas dengan sistem kendala tingkat tinggi lainnya seperti AIR akan sulit dilakukan.
3. Sirkuit buatan tangan diperlukan untuk meningkatkan efisiensi
Kerugian menggunakan model tujuan umum adalah kurang efisien untuk beberapa operasi sederhana yang tidak memerlukan instruksi rumit.
Mari kita uraikan secara singkat beberapa teori sebelumnya,
Sebelum protokol Pinokio: Menerapkan perhitungan yang dapat diverifikasi, tetapi waktu verifikasi sangat lambat. Protokol Pinokio: Memberikan kelayakan teoritis dalam hal verifikasi dan tingkat keberhasilan verifikasi (yaitu, waktu verifikasi lebih pendek dari waktu pelaksanaan program), dan didasarkan pada pada sistem Sirkuit Protokol TinyRAM: Dibandingkan dengan protokol Pinocchio, TinyRAM lebih seperti mesin virtual, memperkenalkan ISA, sehingga menghilangkan beberapa batasan, seperti akses memori (RAM), aliran kontrol (aliran kontrol), dll. protokol vnTinyRAM : memungkinkan pembuatan kunci ( pembuatan kunci) tidak bergantung pada setiap program, memberikan fleksibilitas tambahan. Perluas generator sirkuit, yaitu mampu menangani program yang lebih besar.
Semua model di atas menggunakan SNARK sebagai sistem bukti back-endnya, tetapi terutama ketika berhadapan dengan mesin virtual, STARK dan Plonk tampaknya merupakan back-end yang lebih cocok. Pada dasarnya, ini karena sistem batasan mereka lebih cocok untuk mengimplementasikan CPU-. seperti logika.
Selanjutnya, artikel ini akan memperkenalkan tiga mesin virtual berbasis STARK - Risc0, MidenVM, dan CairoVM. Singkatnya, kecuali keduanya menggunakan STARK sebagai sistem pembuktiannya, masing-masing memiliki beberapa perbedaan:
Risc0 memanfaatkan Risc-V untuk kesederhanaan set instruksi. R0 dikompilasi dalam MLIR, varian dari LLVM-IR yang dirancang untuk mendukung beberapa bahasa pemrograman tujuan umum yang ada seperti Rust dan C++. Risc-V juga memiliki beberapa keunggulan tambahan, seperti lebih ramah perangkat keras.
Miden bertujuan agar kompatibel dengan Ethereum Virtual Machine (EVM) dan pada dasarnya merupakan gabungan dari EVM. Miden sekarang memiliki bahasa pemrogramannya sendiri, tetapi juga berupaya mendukung Move di masa depan.
Kairo VM dikembangkan oleh Starkware. Sistem bukti STARK yang digunakan oleh ketiga sistem ini ditemukan oleh Eli Ben-Sasson, yang saat ini menjabat sebagai presiden Starkware.
Mari kita lihat lebih dekat perbedaannya:
* Bagaimana cara membaca tabel di atas? Beberapa catatan...
Ukuran kata - Karena sistem batasan yang menjadi dasar mesin virtual ini adalah AIR, fungsinya serupa dengan arsitektur CPU. Jadi lebih tepat memilih panjang kata CPU (32/64 bit).
Akses memori - Risc0 menggunakan register terutama karena set instruksi Risc-V berbasis register. Miden terutama menggunakan tumpukan untuk menyimpan data karena AIR berfungsi seperti tumpukan. CairoVM tidak menggunakan register tujuan umum karena biaya akses memori (memori utama) dalam model Kairo rendah.
Umpan program (eksekusi program) - Ada trade-off antara metode yang berbeda. Misalnya, untuk metode mast root, metode ini perlu didekodekan saat instruksi diproses, sehingga biaya pembuktiannya lebih tinggi pada program dengan langkah eksekusi yang lebih banyak. Metode bootloading berupaya mencapai keseimbangan antara biaya pemverifikasi dan biaya pemverifikasi dengan tetap menjaga privasi.
Non-determinisme - Non-determinisme adalah properti penting dari masalah NP-complete. Memanfaatkan non-determinisme membantu memverifikasi eksekusi di masa lalu dengan cepat. Di sisi lain, hal ini menambah lebih banyak batasan dan oleh karena itu beberapa kompromi dalam validasi.
Akselerasi pada operasi yang kompleks - Beberapa perhitungan berjalan sangat lambat di CPU. Misalnya, operasi bit seperti XOR dan AND, program hash seperti ECDSA, dan pemeriksaan jangkauan...sebagian besar berasal dari teknologi blockchain/enkripsi tetapi bukan operasi asli CPU (kecuali operasi bit). Menerapkan operasi ini secara langsung melalui DSL dapat dengan mudah menyebabkan habisnya siklus pembuktian.
Permutasi/multiset - banyak digunakan di sebagian besar zkVM untuk dua tujuan - 1. Mengurangi biaya verifikator dengan mengurangi kebutuhan untuk menyimpan jejak eksekusi lengkap 2. Buktikan bahwa verifikator mengetahui jejak eksekusi lengkap
Di akhir artikel, saya ingin berbicara tentang perkembangan Risc0 saat ini dan mengapa hal itu membuat saya bersemangat.
R0 perkembangan saat ini:
a. Infrastruktur kompiler "Zirgen" yang dikembangkan sendiri sedang dalam pengembangan. Menarik untuk membandingkan kinerja Zirgen dengan beberapa kompiler khusus zk yang ada.
b. Beberapa inovasi menarik, seperti perluasan lapangan, dapat mencapai parameter keamanan yang lebih solid dan beroperasi pada bilangan bulat yang lebih besar.
c. Menyaksikan tantangan yang terlihat dalam integrasi antara perusahaan ZK Hardware dan ZK Software, Risc0 menggunakan lapisan abstraksi perangkat keras untuk memungkinkan pengembangan yang lebih baik di sisi perangkat keras.
d.Masih dalam proses! Masih dalam pengembangan!
Mendukung sirkuit buatan tangan dan mendukung beberapa algoritma hashing. Saat ini, sirkuit SHA256 khusus telah diterapkan, namun tidak memenuhi semua kebutuhan. Penulis percaya bahwa pilihan spesifik jenis sirkuit mana yang akan dioptimalkan bergantung pada kasus penggunaan yang disediakan oleh Risc0. SHA256 adalah tempat yang sangat baik untuk memulai. Di sisi lain, ZKVM diposisikan untuk memberikan keleluasaan kepada masyarakat, misalnya tidak perlu khawatir dengan Keccak jika tidak mau :)
Rekursi: Ini adalah topik besar dan saya memilih untuk tidak membahasnya dalam laporan ini. Yang penting untuk diketahui adalah karena Risc0 cenderung mendukung kasus/program penggunaan yang lebih kompleks, kebutuhan akan rekursi menjadi lebih mendesak. Untuk lebih mendukung rekursi, mereka saat ini sedang mengerjakan solusi akselerasi GPU sisi perangkat keras.
Menangani non-determinisme: Ini adalah properti yang harus ditangani ZKVM, sedangkan mesin virtual tradisional tidak mengalami masalah ini. Non-determinisme dapat membantu mesin virtual bekerja lebih cepat. MLIR relatif lebih baik dalam menangani masalah yang terkait dengan mesin virtual tradisional, dan patut dinantikan bagaimana Risc0 menyematkan non-determinisme ke dalam desain sistem ZKVM.
YANG MEMBUAT SAYA GEMBIRA:
a.Sederhana dan dapat diverifikasi!
Dalam sistem terdistribusi, PoW memerlukan tingkat redundansi yang tinggi karena masyarakat tidak mempercayai orang lain sehingga perlu melakukan perhitungan yang sama berulang kali untuk mencapai konsensus. Dan dengan memanfaatkan bukti tanpa pengetahuan, mewujudkan keadaan semudah menyetujui bahwa 1+1=2.
b.Kasus penggunaan yang lebih praktis:
Selain perluasan paling langsung, kasus penggunaan yang lebih menarik akan menjadi mungkin dilakukan, seperti pembelajaran mesin tanpa pengetahuan, analisis data, dll. Dibandingkan dengan bahasa ZK tertentu seperti Kairo, Rust/C++ memiliki fungsi yang lebih universal dan kuat, dan lebih banyak kasus penggunaan web2 yang dijalankan di VM Risc0.
c. Komunitas pengembang yang lebih inklusif/dewasa:
Pengembang yang tertarik dengan STARK dan blockchain tidak perlu lagi mempelajari ulang DSL, mereka cukup menggunakan Rust/C++.
Terima kasih kepada Xin Gao, Boyuan dari p0xeidon, Daniel dari Taiko, dan Sin7Y atas dukungan dan sarannya untuk revisi artikel ini!