Penulis: Justin Thaler Sumber: a16z Terjemahan: Shanooba, Golden Finance
Mesin Virtual Pengetahuan Nol (zkVMs) bertujuan untuk "membawa SNARKs ke arah yang lebih umum," memungkinkan orang yang tidak memiliki pengetahuan khusus tentang SNARK dapat membuktikan bahwa mereka menjalankan program tertentu dengan benar pada input (atau saksi) tertentu. Keunggulan inti dari zkVMs adalah pengalaman pengembang, namun saat ini zkVMs masih menghadapi tantangan besar dalam keamanan dan kinerja. Jika zkVMs ingin memenuhi janjinya, perancang harus mengatasi hambatan-hambatan ini. Artikel ini akan menjelajahi kemungkinan tahapan perkembangan zkVM, yang seluruh prosesnya mungkin memerlukan beberapa tahun untuk diselesaikan - jangan percaya jika ada yang mengatakan ini bisa terwujud dengan cepat.
Tantangan yang Dihadapi
Dalam hal keamanan, zkVMs adalah proyek perangkat lunak yang sangat kompleks dan masih penuh dengan kerentanan.
Dalam hal kinerja, membuktikan bahwa sebuah program berjalan dengan benar mungkin akan jauh lebih lambat puluhan ribu kali lipat daripada berjalan secara asli, membuat sebagian besar aplikasi tidak dapat diterapkan di dunia nyata untuk sementara waktu.
Meskipun begitu, banyak suara dalam industri blockchain masih mengklaim bahwa zkVMs dapat diterapkan secara langsung, bahkan beberapa proyek telah membayar biaya komputasi yang tinggi untuk menghasilkan bukti pengetahuan nol atas aktivitas rantai. Namun, karena masih banyak kelemahan dalam zkVMs, pendekatan ini sebenarnya hanyalah pakaian mahal yang membuat sistem terlihat dilindungi oleh SNARK, padahal sebenarnya itu bergantung pada kontrol izin, atau bahkan lebih buruk - terpapar risiko serangan.
Kenyataannya, kita masih beberapa tahun jauhnya dari membangun zkVM yang benar-benar aman dan efisien. Artikel ini menetapkan serangkaian tujuan spesifik dan berjenjang untuk membantu kita melacak perkembangan nyata zkVM, meredam spekulasi, dan mengarahkan perhatian komunitas pada terobosan teknologi yang sebenarnya.
Tahap Pengembangan Keamanan
Latar Belakang
zkVMs berbasis SNARK biasanya terdiri dari dua komponen inti:
Bukti Orakel Interaktif Polinomial (Polynomial Interactive Oracle Proof, PIOP): digunakan untuk membuktikan kerangka bukti interaktif polinomial (atau kendala yang berasal dari polinomial).
Skema Komitmen Polinomial (Polynomial Commitment Scheme, PCS): Memastikan bahwa pembuktian tidak dapat memalsukan hasil evaluasi polinomial tanpa terdeteksi.
zkVM memastikan penggunaan yang benar dari register dan memori mesin virtual dengan mengkodekan jalur eksekusi yang efektif ke dalam sistem kendala, dan kemudian membuktikan kepatuhan terhadap kendala-kendala ini dengan menggunakan SNARK.
Dalam sistem yang begitu kompleks, satu-satunya cara untuk memastikan bahwa zkVM bebas dari kerentanan adalah dengan verifikasi formal. Berikut adalah berbagai tahapan keamanan zkVM, di mana tahap pertama fokus pada kebenaran protokol, sedangkan tahap kedua dan ketiga fokus pada kebenaran implementasi.
Tahap Keamanan 1: Protokol yang Benar
Bukti Verifikasi Resmi Keandalan PIOP;
PCS memiliki bentuk pembuktian yang mengikat di bawah beberapa asumsi kriptografi atau model ideal;
Jika menggunakan Fiat-Shamir, maka bukti formal yang aman dalam model ramalan acak diperoleh dengan menggabungkan PIOP dan PCS (diperkuat dengan asumsi enkripsi lain jika diperlukan);
Sistem kendali yang digunakan oleh PIOP setara dengan bukti formalitas semantik VM;
Menggabungkan semua bagian di atas secara menyeluruh menjadi bukti SNARK yang aman yang terverifikasi secara formal, untuk menjalankan program apa pun yang ditentukan oleh bytecode VM. Jika protokol bertujuan untuk mencapai zero knowledge, properti ini juga harus diverifikasi secara formal untuk memastikan tidak ada informasi sensitif tentang saksi yang bocor.
Jika zkVM menggunakan rekursif, maka PIOP, skema komitmen, dan sistem keterikatan yang terlibat dalam proses rekursif harus diverifikasi sebelum subfase tersebut dapat dianggap selesai.
Tahap Keamanan 2: Implementasi Validator yang Benar
Tahap ini membutuhkan verifikasi formal implementasi praktis zkVM (seperti Rust, Solidity, dll.) untuk memastikan kesesuaian dengan protokol yang diverifikasi pada tahap pertama. Menyelesaikan tahap ini berarti implementasi zkVM konsisten dengan desain teoritis, bukan hanya merupakan protokol keamanan di atas kertas, atau spesifikasi yang tidak efisien yang ditulis dalam bahasa seperti Lean.
Mengapa hanya fokus pada validator, bukan pemastik memiliki dua alasan utama: pertama, memastikan validator benar, dapat menjamin integritas sistem bukti zkVM (yaitu: memastikan validator tidak bisa ditipu untuk menerima bukti yang salah). Kedua, implementasi validator zkVM lebih dari satu tingkat lebih sederhana daripada implementasi pemastik, keabsahan validator lebih mudah dipastikan dalam jangka pendek.
Tahap Keamanan 3: Implementasi Verifier yang Benar
Tahap ini melibatkan verifikasi formal dari implementasi pembuktian zkVM, untuk memastikan bahwa itu dapat menghasilkan dengan benar bukti dari sistem pembuktian yang telah diverifikasi pada Tahap Pertama dan Kedua. Tujuan tahap ini adalah kesempurnaan, yaitu: tidak ada sistem yang menggunakan zkVM yang akan tersendat karena tidak dapat membuktikan pernyataan yang sah. Jika zkVM perlu memiliki sifat pengetahuan nol, maka verifikasi formal harus disediakan untuk memastikan bahwa bukti tidak akan mengungkapkan informasi apa pun tentang kesaksian.
Jadwal perkiraan
Tahap 1 Kemajuan: Kita bisa mengharapkan beberapa kemajuan tahun depan (misalnya, ZKLib adalah salah satu upaya tersebut). Tetapi setidaknya dua tahun ke depan, tidak ada satu pun zkVM yang dapat sepenuhnya memenuhi persyaratan Tahap 1.
Tahap 2 dan Tahap 3 : Tahap-tahap ini dapat dilakukan secara bersamaan dengan beberapa aspek Tahap 1. Sebagai contoh, beberapa tim telah membuktikan implementasi validator Plonk sesuai dengan protokol dalam makalah (meskipun protokol dalam makalah itu sendiri mungkin belum sepenuhnya diverifikasi). Meskipun demikian, saya memperkirakan tidak ada zkVM yang akan mencapai Tahap 3 dalam waktu kurang dari empat tahun - bahkan mungkin lebih lama.
Perhatian Kunci: Keamanan Fiat-Shamir dan Kode Byte yang Terverifikasi
Salah satu masalah kompleks utama adalah, keamanan Transformasi Fiat-Shamir masih memiliki masalah penelitian yang belum terpecahkan. Ketiga tahap keamanan menganggap Fiat-Shamir dan mesin ramalan acak sebagai keamanan mutlak, tetapi pada kenyataannya paradigma keseluruhan mungkin memiliki kelemahan. Hal ini disebabkan oleh perbedaan antara model idealisasi mesin ramalan acak dan fungsi hash yang digunakan secara aktual.
Dalam skenario terburuk, sebuah sistem yang telah mencapai tahap keamanan 2 mungkin ditemukan sepenuhnya tidak aman karena masalah terkait Fiat-Shamir. Hal ini patut mendapat perhatian kita secara serius, dan penelitian harus terus dilakukan. Mungkin perlu memodifikasi transformasi Fiat-Shamir itu sendiri untuk lebih baik dalam melindungi kerentanan semacam itu.
Sistem tanpa pengulangan secara teori lebih aman, karena beberapa serangan yang diketahui melibatkan sirkuit yang mirip dengan sirkuit yang digunakan dalam bukti pengulangan. Namun risiko ini masih merupakan masalah dasar yang belum terpecahkan.
Masalah lain yang perlu diperhatikan adalah, bahkan jika zkVM membuktikan bahwa sebuah program komputasi (yang ditentukan oleh bytecode) telah dieksekusi dengan benar, namun jika bytecode itu sendiri memiliki kekurangan, maka nilai dari bukti ini sangat terbatas. Oleh karena itu, praktikalitas zkVM sangat bergantung pada bagaimana menghasilkan bytecode yang diverifikasi secara formal, dan tantangan ini sangat besar, dan di luar jangkauan diskusi dalam artikel ini.
Tentang Keamanan Anti-Kuantum
Dalam setidaknya 5 tahun ke depan (bahkan lebih lama), komputer kuantum tidak akan menjadi ancaman serius, sementara kerentanan perangkat lunak adalah masalah hidup dan mati. Oleh karena itu, tugas utama saat ini harus mencapai tujuan keamanan dan kinerja yang diajukan dalam artikel ini. Jika SNARKs yang tidak tahan terhadap kuantum dapat lebih cepat memenuhi tujuan ini, kita harus memberi prioritas pada penggunaannya. Tunggu sampai SNARKs yang tahan terhadap kuantum mengejar perkembangan, atau ada tanda-tanda bahwa komputer kuantum yang merupakan ancaman nyata akan segera muncul, baru pertimbangkan untuk beralih.
Tingkat Keamanan yang Spesifik
100-bit keamanan klasik adalah standar minimum yang digunakan oleh SNARK untuk melindungi aset berharga (**namun masih ada beberapa sistem yang tidak memenuhi standar ini). Meskipun demikian, hal ini tidak boleh diterima, praktik kriptografi standar biasanya membutuhkan keamanan 128-bit atau lebih. Jika kinerja SNARK sudah memenuhi standar, kita tidak boleh mengorbankan keamanan demi meningkatkan kinerja.
Tahap Kinerja
Current Situation
Saat ini, biaya komputasi verifier zkVM sekitar 1.000.000 kali eksekusi asli. Dengan kata lain, jika eksekusi asli program membutuhkan X siklus CPU, maka menghasilkan bukti eksekusi yang benar butuh sekitar X × 1.000.000 siklus CPU. Keadaan ini sama seperti setahun yang lalu, dan tetap sama hari ini (meskipun ada beberapa kekeliruan).
Beberapa istilah populer dalam industri saat ini mungkin menyesatkan, misalnya:
"Biaya menghasilkan bukti untuk seluruh mainnet Ethereum kurang dari $1 juta per tahun." ”**
"Kami hampir mencapai pembangkitan bukti real-time blok Ethereum, hanya memerlukan beberapa puluh GPU."
"zkVM terbaru kami 1000 kali lebih cepat dari generasi sebelumnya."
Namun, pernyataan-pernyataan ini mungkin menyesatkan tanpa konteks:
• Dibandingkan dengan zkVM versi sebelumnya, 1000 kali lebih cepat, tetapi masih mungkin sangat lambat, ini lebih menunjukkan seberapa buruknya masa lalu, bukan seberapa baiknya sekarang.
Jumlah komputasi di mainnet Ethereum dapat meningkat hingga 10 kali di masa depan, hal ini akan membuat kinerja zkVM saat ini jauh tertinggal dari permintaan.
Generasi bukti yang disebut "hampir real-time" masih terlalu lambat untuk banyak aplikasi blockchain (misalnya, waktu blok Optimism adalah 2 detik, jauh lebih cepat dari Ethereum 12 detik).
• "Puluhan GPU berjalan 24/7 untuk jangka waktu yang lama" tidak memberikan jaminan aktivitas yang memadai.
• Waktu pembuatan bukti ini biasanya ditujukan untuk ukuran bukti lebih dari 1MB, yang terlalu besar untuk banyak aplikasi.
• "Biaya kurang dari $ 1 juta per tahun" hanya karena node penuh Ethereum hanya melakukan sekitar $ 25 dalam perhitungan setahun.
Untuk skenario aplikasi di luar blockchain, biaya komputasi ini jelas terlalu tinggi. Tidak peduli seberapa banyak komputasi paralel atau optimisasi rekayasa, tidak akan dapat mengimbangi biaya komputasi yang begitu besar ini.
Tujuan dasar yang harus kita tetapkan adalah: biaya kinerja tidak boleh melebihi 100.000 kali dari eksekusi asli. Namun demikian, ini hanya langkah pertama. Jika kita ingin mewujudkan aplikasi besar yang benar-benar massal, mungkin kita perlu menurunkan biaya hingga 10.000 kali atau bahkan lebih sedikit dari eksekusi asli.
Pengukuran Kinerja
Kinerja SNARK terdiri dari tiga komponen utama:
Efisiensi tetap dari sistem bukti dasar.
Optimasi untuk aplikasi tertentu (misalnya, pra-kompilasi).
Pertambahan Engineering dan Percepatan Perangkat Keras (seperti GPU, FPGA, atau CPU multi-core).
Meskipun (2) dan (3) penting untuk implementasi aktual, namun mereka berlaku untuk setiap sistem bukti, sehinggatidak selalu mencerminkan perbaikan biaya dasar. Misalnya, menambahkan akselerasi GPU dan pra-kompilasi ke zkEVM dapat dengan mudah meningkatkan kecepatan hingga 50 kali dibanding hanya bergantung pada CPU - ini mungkin membuat sistem yang efisien tetapi rendah terlihat lebih baik daripada sistem lain yang belum mengalami optimasi yang sama.
Oleh karena itu, artikel ini secara khusus mengukur kinerja dasar SNARK tanpa perangkat keras khusus dan pra-kompilasi. Ini berbeda dengan metode pengujian dasar saat ini, yang biasanya menggabungkan ketiga faktor tersebut menjadi satu 'nilai keseluruhan'. Ini mirip dengan menilai berlian berdasarkan waktu poles, bukan mengevaluasi kejernihan alaminya.
Tujuan kami adalah mengisolasi biaya tetap dari sistem bukti umum, menurunkan ambang batas teknologi yang belum terdalam penelitiannya, dan membantu komunitas menghilangkan gangguan untuk fokus pada kemajuan desain sistem bukti yang sebenarnya.
Tahap Kinerja
Berikut adalah lima tonggak kinerja yang saya usulkan. Pertama, kami perlu secara signifikan mengurangi biaya validator pada CPU sebelum kita dapat lebih lanjut mengandalkan perangkat keras untuk mengurangi biaya. Selain itu, penggunaan memori juga harus ditingkatkan.
Pada semua tahap, pengembang tidak boleh menyesuaikan kode untuk kinerja zkVM. Pengalaman pengembang adalah keuntungan inti dari zkVM. Jika mengorbankan DevEx untuk memenuhi standar kinerja, bukan hanya kehilangan makna pengujian standar, tetapi juga melanggar tujuan awal zkVM.
Indikator-indikator ini utamanya berkaitan dengan biaya pembuktian. Namun, jika diperbolehkan bagi validator untuk biaya tumbuh tak terbatas (yaitu ukuran bukti atau waktu verifikasi tanpa batas), maka semua indikator pembuktian dapat dengan mudah dipenuhi. Oleh karena itu, untuk memenuhi persyaratan tahapan berikut, maka harus membatasi ukuran bukti maksimum dan waktu verifikasi maksimum secara bersamaan.
Tahap 1 Persyaratan: "Biaya Verifikasi Non-Trivial yang Masuk Akal"
• Ukuran bukti: Harus lebih kecil dari ukuran bukti.
• Waktu Verifikasi : Kecepatan verifikasi bukti tidak boleh lebih lambat dari eksekusi asli program (yaitu, tidak boleh lebih lambat dari perhitungan langsung).
Ini adalah persyaratan kejelasan minimal untuk memastikan ukuran bukti dan waktu verifikasi tidak lebih buruk daripada mengirimkan bukti langsung ke verifikator untuk diperiksa langsung.
Tahap 2 dan seterusnya
• Ukuran Bukti Maksimum : 256 KB.
• Waktu Verifikasi Maksimum : 16 milidetik.
Batasan-batasan ini sengaja ditetapkan dengan longgar untuk menyesuaikan dengan teknologi bukti cepat yang inovatif, meskipun hal itu mungkin mengakibatkan biaya verifikasi yang lebih tinggi. Sementara itu, batasan-batasan ini juga mengesampingkan bukti yang begitu mahal sehingga hampir tidak ada proyek yang bersedia menggunakannya di blockchain.
Tahap Kecepatan 1
Bukti Tunggal Kecepatan Tidak Boleh Lebih Dari 100.000 Kali Lebih Lambat Dari Eksekusi Asli (Berlaku untuk berbagai aplikasi, bukan hanya bukti blok Ethereum), dan tidak boleh bergantung pada pra-kompilasi.
Secara khusus, asumsikan bahwa kecepatan processor RISC-V pada laptop modern adalah sekitar 30 miliar siklus/detik, maka mencapai tahap 1 berarti laptop tersebut dapat menghasilkan bukti dengan kecepatan 30.000 siklus RISC-V/detik (single thread).
Biaya validator harus memenuhi standar "biaya validasi yang wajar dan tidak biasa" yang telah ditetapkan sebelumnya.
Tahap Kecepatan 2
Bukti tunggal tidak boleh lebih dari 10.000 kali lebih lambat dari eksekusi asli.
Atau, karena beberapa metode SNARK yang menjanjikan (terutama SNARK domain biner) terbatas oleh CPU dan GPU saat ini, bisa dipenuhi dengan FPGA (bahkan ASIC) pada tahap ini:
Hitung jumlah inti RISC-V yang disimulasikan oleh FPGA pada kecepatan aslinya.
Hitung dan buktikan jumlah FPGA yang diperlukan untuk mensimulasikan dan membuktikan eksekusi RISC-V (hampir real-time).
Jika jumlah (2)tidak melebihi 10.000 kali (1), maka memenuhi tahap 2.
• Ukuran bukti：maksimal 256 KB。
• Waktu verifikasi: maksimum 16 milidetik pada CPU standar.
Tahap Kecepatan 3
Pada dasarnya, dengan mencapai Tahap Kecepatan 2, mencapai biaya bukti di bawah 1000× (berlaku untuk berbagai aplikasi), dan harus menggunakan pra-kompilasi otomatis dan verifikasi formal. Secara esensial, mencustom setiap set instruksi program secara dinamis untuk mempercepat pembangkitan bukti, tetapi harus memastikan kemudahan penggunaan dan verifikasi formal. (Tentang mengapa pra-kompilasi adalah pedang bermata dua, dan mengapa pra-kompilasi 'manual' bukan metode yang berkelanjutan, lihat bagian berikutnya.)
Tahap Memori 1
Dalam kurang dari 2 GB memori, mencapai tahap kecepatan 1, dan pada saat yang sama memenuhi persyaratan pengetahuan nol. Tahap ini sangat penting untuk perangkat seluler atau browser, dan membuka pintu untuk banyak kasus penggunaan zkVM di sisi klien. Misalnya, ponsel pintar digunakan untuk privasi lokasi, kredensial identitas, dll. Jika pembuatan bukti memerlukan lebih dari 1-2 GB memori, sebagian besar perangkat seluler tidak akan dapat menjalankannya.
Dua Poin Penting:
Bahkan untuk komputasi berskala besar (yang memerlukan eksekusi asli selama miliaran siklus CPU), sistem bukti harus tetap mempertahankan batas atas 2 GB memorinya, jika tidak, kegunaannya akan terbatas.
Jika kecepatan terbukti sangat lambat, maka menjaga batas atas memori 2 GB sangat mudah. Oleh karena itu, untuk membuat tahap memori 1 bermakna, harus mencapai tahap kecepatan 1 dalam batas memori 2 GB.
Tahap Memori 2
Mencapai Tahap Kecepatan 1 (10 kali lipat dari Tahap Memori 1) dalam kurang dari 200 MB memori.
Mengapa harus turun menjadi 200 MB? Pertimbangkan sebuah skenario diluar blockchain: ketika Anda mengakses situs web HTTPS, Anda akan mengunduh sertifikat otentikasi dan enkripsi. Jika situs web beralih untuk mengirimkan bukti zk dari sertifikat ini, situs web besar mungkin perlu menghasilkan jutaan bukti setiap detik. Jika setiap bukti memerlukan 2 GB memori, kebutuhan sumber daya komputasi akan mencapai tingkat PB, yang jelas tidak dapat dilakukan. Oleh karena itu, menurunkan penggunaan memori lebih lanjut sangat penting bagi aplikasi diluar blockchain.
**Prakompilasi: Mil terakhir, atau kruk? **
Pre-kompilasi merujuk pada **sistem kendali SNARK yang dioptimalkan khusus untuk fungsi tertentu (seperti hash, tanda tangan kurva elips) **. Di Ethereum, pre-kompilasi dapat mengurangi biaya hash Merkle dan verifikasi tanda tangan, namun ketergantungan berlebihan pada pre-kompilasi tidak benar-benar meningkatkan efisiensi inti SNARK.
Masalah Kompilasi Pra-
1. Masih Terlalu Lambat: Meskipun menggunakan prakompilasi hash dan tanda tangan, zkVM masih menghadapi masalah efisiensi inti dari sistem bukti di dalam dan di luar rantai blok.
2.安全漏洞：Jika pra-kompilasi manual tidak diverifikasi secara formal, hampir pasti akan ada kerentanan yang dapat menyebabkan kegagalan keamanan yang fatal.
3. Pengalaman Pengembang Buruk: Saat ini, banyak zkVM memerlukan pengembang menulis ulang sistem constraint, mirip dengan cara pemrograman tahun 1960-an, yang sangat memengaruhi pengalaman pengembangan.
4.测试基准误导：Jika pengujian basis bergantung pada optimisasi pra-kompilasi tertentu, ini mungkin menyesatkan orang untuk fokus pada sistem kendali optimisasi manual, bukan meningkatkan desain SNARK itu sendiri.
5.Overhead I/O dan Tanpa Akses RAM**Meskipun prakompilasi dapat meningkatkan performa tugas kriptografi yang berat, prakompilasi mungkin tidak memberikan akselerasi yang berarti untuk beban kerja yang lebih beragam karena menimbulkan overhead yang signifikan saat meneruskan input/output, dan mereka tidak dapat menggunakan RAM.
Meskipun berada dalam lingkungan blockchain, begitu Anda melampaui L1 tunggal seperti Ethereum (misalnya, Anda ingin membangun serangkaian jembatan lintas-rantai), Anda akan dihadapkan pada fungsi hash dan skema tanda tangan yang berbeda. Untuk mengatasi masalah ini, terus melakukan pra-penyusunan, ini tidak dapat diperluas dan akan membawa risiko keamanan yang besar.
Saya benar-benar percaya bahwa pra-kompilasi tetap sangat penting dalam jangka panjang, tetapi hanya jika mereka disintesis secara otomatis dan diverifikasi secara resmi. Dengan demikian, kita dapat mempertahankan keunggulan pengalaman pengembang zkVM, sambil menghindari risiko keamanan yang berpotensi merugikan. Pandangan ini tercermin dalam tahap 3.
Jadwal yang Diharapkan
Saya memperkirakan beberapa zkVM akan mencapai Fase Kecepatan 1 dan Fase Memori 1 dalam tahun ini. Saya berpikir bahwa dalam dua tahun ke depan, kita juga dapat mencapai Fase Kecepatan 2, tetapi saat ini belum jelas apakah kita dapat mencapai tujuan ini tanpa ide penelitian baru.
Saya memperkirakan tahap-tahap yang tersisa (Tahap Kecepatan 3 dan Tahap Memori 2) akan memerlukan beberapa tahun lagi untuk dicapai.
Meskipun artikel ini secara terpisah mencantumkan tahap keamanan dan kinerja zkVM, keduanya tidak sepenuhnya independen. Seiring dengan terus ditemukannya kerentanan dalam zkVM, saya memperkirakan perbaikan beberapa kerentanan tersebut akan tak terhindarkan menyebabkan penurunan kinerja yang signifikan. Oleh karena itu, hasil uji kinerja zkVM sebelum mencapai Tahap Keamanan 2 harus dianggap sebagai data sementara.
zkVM memiliki potensi besar dalam mendorong penyebaran bukti pengetahuan nol yang sebenarnya, tetapi saat ini masih berada dalam tahap awal - penuh dengan tantangan keamanan dan menghadapi hambatan kinerja yang serius. Spekulasi pasar dan promosi pemasaran membuat penilaian kemajuan yang sebenarnya menjadi sulit. Melalui tonggak keamanan dan kinerja yang jelas, saya berharap dapat menyediakan peta jalan yang dapat membantu menjelaskan. Kami pasti akan mencapai tujuan ini, tetapi hal itu memerlukan waktu, serta upaya penelitian dan rekayasa yang berkelanjutan.
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
a16z：Menjelajahi jalan efisien dan aman zkVM
Penulis: Justin Thaler Sumber: a16z Terjemahan: Shanooba, Golden Finance
Mesin Virtual Pengetahuan Nol (zkVMs) bertujuan untuk "membawa SNARKs ke arah yang lebih umum," memungkinkan orang yang tidak memiliki pengetahuan khusus tentang SNARK dapat membuktikan bahwa mereka menjalankan program tertentu dengan benar pada input (atau saksi) tertentu. Keunggulan inti dari zkVMs adalah pengalaman pengembang, namun saat ini zkVMs masih menghadapi tantangan besar dalam keamanan dan kinerja. Jika zkVMs ingin memenuhi janjinya, perancang harus mengatasi hambatan-hambatan ini. Artikel ini akan menjelajahi kemungkinan tahapan perkembangan zkVM, yang seluruh prosesnya mungkin memerlukan beberapa tahun untuk diselesaikan - jangan percaya jika ada yang mengatakan ini bisa terwujud dengan cepat.
Tantangan yang Dihadapi
Dalam hal keamanan, zkVMs adalah proyek perangkat lunak yang sangat kompleks dan masih penuh dengan kerentanan.
Dalam hal kinerja, membuktikan bahwa sebuah program berjalan dengan benar mungkin akan jauh lebih lambat puluhan ribu kali lipat daripada berjalan secara asli, membuat sebagian besar aplikasi tidak dapat diterapkan di dunia nyata untuk sementara waktu.
Meskipun begitu, banyak suara dalam industri blockchain masih mengklaim bahwa zkVMs dapat diterapkan secara langsung, bahkan beberapa proyek telah membayar biaya komputasi yang tinggi untuk menghasilkan bukti pengetahuan nol atas aktivitas rantai. Namun, karena masih banyak kelemahan dalam zkVMs, pendekatan ini sebenarnya hanyalah pakaian mahal yang membuat sistem terlihat dilindungi oleh SNARK, padahal sebenarnya itu bergantung pada kontrol izin, atau bahkan lebih buruk - terpapar risiko serangan.
Kenyataannya, kita masih beberapa tahun jauhnya dari membangun zkVM yang benar-benar aman dan efisien. Artikel ini menetapkan serangkaian tujuan spesifik dan berjenjang untuk membantu kita melacak perkembangan nyata zkVM, meredam spekulasi, dan mengarahkan perhatian komunitas pada terobosan teknologi yang sebenarnya.
Tahap Pengembangan Keamanan
Latar Belakang
zkVMs berbasis SNARK biasanya terdiri dari dua komponen inti:
Bukti Orakel Interaktif Polinomial (Polynomial Interactive Oracle Proof, PIOP): digunakan untuk membuktikan kerangka bukti interaktif polinomial (atau kendala yang berasal dari polinomial).
Skema Komitmen Polinomial (Polynomial Commitment Scheme, PCS): Memastikan bahwa pembuktian tidak dapat memalsukan hasil evaluasi polinomial tanpa terdeteksi.
zkVM memastikan penggunaan yang benar dari register dan memori mesin virtual dengan mengkodekan jalur eksekusi yang efektif ke dalam sistem kendala, dan kemudian membuktikan kepatuhan terhadap kendala-kendala ini dengan menggunakan SNARK.
Dalam sistem yang begitu kompleks, satu-satunya cara untuk memastikan bahwa zkVM bebas dari kerentanan adalah dengan verifikasi formal. Berikut adalah berbagai tahapan keamanan zkVM, di mana tahap pertama fokus pada kebenaran protokol, sedangkan tahap kedua dan ketiga fokus pada kebenaran implementasi.
Tahap Keamanan 1: Protokol yang Benar
Jika zkVM menggunakan rekursif, maka PIOP, skema komitmen, dan sistem keterikatan yang terlibat dalam proses rekursif harus diverifikasi sebelum subfase tersebut dapat dianggap selesai.
Tahap Keamanan 2: Implementasi Validator yang Benar
Tahap ini membutuhkan verifikasi formal implementasi praktis zkVM (seperti Rust, Solidity, dll.) untuk memastikan kesesuaian dengan protokol yang diverifikasi pada tahap pertama. Menyelesaikan tahap ini berarti implementasi zkVM konsisten dengan desain teoritis, bukan hanya merupakan protokol keamanan di atas kertas, atau spesifikasi yang tidak efisien yang ditulis dalam bahasa seperti Lean.
Mengapa hanya fokus pada validator, bukan pemastik memiliki dua alasan utama: pertama, memastikan validator benar, dapat menjamin integritas sistem bukti zkVM (yaitu: memastikan validator tidak bisa ditipu untuk menerima bukti yang salah). Kedua, implementasi validator zkVM lebih dari satu tingkat lebih sederhana daripada implementasi pemastik, keabsahan validator lebih mudah dipastikan dalam jangka pendek.
Tahap Keamanan 3: Implementasi Verifier yang Benar
Tahap ini melibatkan verifikasi formal dari implementasi pembuktian zkVM, untuk memastikan bahwa itu dapat menghasilkan dengan benar bukti dari sistem pembuktian yang telah diverifikasi pada Tahap Pertama dan Kedua. Tujuan tahap ini adalah kesempurnaan, yaitu: tidak ada sistem yang menggunakan zkVM yang akan tersendat karena tidak dapat membuktikan pernyataan yang sah. Jika zkVM perlu memiliki sifat pengetahuan nol, maka verifikasi formal harus disediakan untuk memastikan bahwa bukti tidak akan mengungkapkan informasi apa pun tentang kesaksian.
Jadwal perkiraan
Tahap 1 Kemajuan: Kita bisa mengharapkan beberapa kemajuan tahun depan (misalnya, ZKLib adalah salah satu upaya tersebut). Tetapi setidaknya dua tahun ke depan, tidak ada satu pun zkVM yang dapat sepenuhnya memenuhi persyaratan Tahap 1.
Tahap 2 dan Tahap 3 : Tahap-tahap ini dapat dilakukan secara bersamaan dengan beberapa aspek Tahap 1. Sebagai contoh, beberapa tim telah membuktikan implementasi validator Plonk sesuai dengan protokol dalam makalah (meskipun protokol dalam makalah itu sendiri mungkin belum sepenuhnya diverifikasi). Meskipun demikian, saya memperkirakan tidak ada zkVM yang akan mencapai Tahap 3 dalam waktu kurang dari empat tahun - bahkan mungkin lebih lama.
Perhatian Kunci: Keamanan Fiat-Shamir dan Kode Byte yang Terverifikasi
Salah satu masalah kompleks utama adalah, keamanan Transformasi Fiat-Shamir masih memiliki masalah penelitian yang belum terpecahkan. Ketiga tahap keamanan menganggap Fiat-Shamir dan mesin ramalan acak sebagai keamanan mutlak, tetapi pada kenyataannya paradigma keseluruhan mungkin memiliki kelemahan. Hal ini disebabkan oleh perbedaan antara model idealisasi mesin ramalan acak dan fungsi hash yang digunakan secara aktual.
Dalam skenario terburuk, sebuah sistem yang telah mencapai tahap keamanan 2 mungkin ditemukan sepenuhnya tidak aman karena masalah terkait Fiat-Shamir. Hal ini patut mendapat perhatian kita secara serius, dan penelitian harus terus dilakukan. Mungkin perlu memodifikasi transformasi Fiat-Shamir itu sendiri untuk lebih baik dalam melindungi kerentanan semacam itu.
Sistem tanpa pengulangan secara teori lebih aman, karena beberapa serangan yang diketahui melibatkan sirkuit yang mirip dengan sirkuit yang digunakan dalam bukti pengulangan. Namun risiko ini masih merupakan masalah dasar yang belum terpecahkan.
Masalah lain yang perlu diperhatikan adalah, bahkan jika zkVM membuktikan bahwa sebuah program komputasi (yang ditentukan oleh bytecode) telah dieksekusi dengan benar, namun jika bytecode itu sendiri memiliki kekurangan, maka nilai dari bukti ini sangat terbatas. Oleh karena itu, praktikalitas zkVM sangat bergantung pada bagaimana menghasilkan bytecode yang diverifikasi secara formal, dan tantangan ini sangat besar, dan di luar jangkauan diskusi dalam artikel ini.
Tentang Keamanan Anti-Kuantum
Dalam setidaknya 5 tahun ke depan (bahkan lebih lama), komputer kuantum tidak akan menjadi ancaman serius, sementara kerentanan perangkat lunak adalah masalah hidup dan mati. Oleh karena itu, tugas utama saat ini harus mencapai tujuan keamanan dan kinerja yang diajukan dalam artikel ini. Jika SNARKs yang tidak tahan terhadap kuantum dapat lebih cepat memenuhi tujuan ini, kita harus memberi prioritas pada penggunaannya. Tunggu sampai SNARKs yang tahan terhadap kuantum mengejar perkembangan, atau ada tanda-tanda bahwa komputer kuantum yang merupakan ancaman nyata akan segera muncul, baru pertimbangkan untuk beralih.
Tingkat Keamanan yang Spesifik
100-bit keamanan klasik adalah standar minimum yang digunakan oleh SNARK untuk melindungi aset berharga (**namun masih ada beberapa sistem yang tidak memenuhi standar ini). Meskipun demikian, hal ini tidak boleh diterima, praktik kriptografi standar biasanya membutuhkan keamanan 128-bit atau lebih. Jika kinerja SNARK sudah memenuhi standar, kita tidak boleh mengorbankan keamanan demi meningkatkan kinerja.
Tahap Kinerja
Current Situation
Saat ini, biaya komputasi verifier zkVM sekitar 1.000.000 kali eksekusi asli. Dengan kata lain, jika eksekusi asli program membutuhkan X siklus CPU, maka menghasilkan bukti eksekusi yang benar butuh sekitar X × 1.000.000 siklus CPU. Keadaan ini sama seperti setahun yang lalu, dan tetap sama hari ini (meskipun ada beberapa kekeliruan).
Beberapa istilah populer dalam industri saat ini mungkin menyesatkan, misalnya:
"Biaya menghasilkan bukti untuk seluruh mainnet Ethereum kurang dari $1 juta per tahun." ”**
"Kami hampir mencapai pembangkitan bukti real-time blok Ethereum, hanya memerlukan beberapa puluh GPU."
"zkVM terbaru kami 1000 kali lebih cepat dari generasi sebelumnya."
Namun, pernyataan-pernyataan ini mungkin menyesatkan tanpa konteks:
• Dibandingkan dengan zkVM versi sebelumnya, 1000 kali lebih cepat, tetapi masih mungkin sangat lambat, ini lebih menunjukkan seberapa buruknya masa lalu, bukan seberapa baiknya sekarang.
Jumlah komputasi di mainnet Ethereum dapat meningkat hingga 10 kali di masa depan, hal ini akan membuat kinerja zkVM saat ini jauh tertinggal dari permintaan.
Generasi bukti yang disebut "hampir real-time" masih terlalu lambat untuk banyak aplikasi blockchain (misalnya, waktu blok Optimism adalah 2 detik, jauh lebih cepat dari Ethereum 12 detik).
• "Puluhan GPU berjalan 24/7 untuk jangka waktu yang lama" tidak memberikan jaminan aktivitas yang memadai.
• Waktu pembuatan bukti ini biasanya ditujukan untuk ukuran bukti lebih dari 1MB, yang terlalu besar untuk banyak aplikasi.
• "Biaya kurang dari $ 1 juta per tahun" hanya karena node penuh Ethereum hanya melakukan sekitar $ 25 dalam perhitungan setahun.
Untuk skenario aplikasi di luar blockchain, biaya komputasi ini jelas terlalu tinggi. Tidak peduli seberapa banyak komputasi paralel atau optimisasi rekayasa, tidak akan dapat mengimbangi biaya komputasi yang begitu besar ini.
Tujuan dasar yang harus kita tetapkan adalah: biaya kinerja tidak boleh melebihi 100.000 kali dari eksekusi asli. Namun demikian, ini hanya langkah pertama. Jika kita ingin mewujudkan aplikasi besar yang benar-benar massal, mungkin kita perlu menurunkan biaya hingga 10.000 kali atau bahkan lebih sedikit dari eksekusi asli.
Pengukuran Kinerja
Kinerja SNARK terdiri dari tiga komponen utama:
Efisiensi tetap dari sistem bukti dasar.
Optimasi untuk aplikasi tertentu (misalnya, pra-kompilasi).
Pertambahan Engineering dan Percepatan Perangkat Keras (seperti GPU, FPGA, atau CPU multi-core).
Meskipun (2) dan (3) penting untuk implementasi aktual, namun mereka berlaku untuk setiap sistem bukti, sehinggatidak selalu mencerminkan perbaikan biaya dasar. Misalnya, menambahkan akselerasi GPU dan pra-kompilasi ke zkEVM dapat dengan mudah meningkatkan kecepatan hingga 50 kali dibanding hanya bergantung pada CPU - ini mungkin membuat sistem yang efisien tetapi rendah terlihat lebih baik daripada sistem lain yang belum mengalami optimasi yang sama.
Oleh karena itu, artikel ini secara khusus mengukur kinerja dasar SNARK tanpa perangkat keras khusus dan pra-kompilasi. Ini berbeda dengan metode pengujian dasar saat ini, yang biasanya menggabungkan ketiga faktor tersebut menjadi satu 'nilai keseluruhan'. Ini mirip dengan menilai berlian berdasarkan waktu poles, bukan mengevaluasi kejernihan alaminya.
Tujuan kami adalah mengisolasi biaya tetap dari sistem bukti umum, menurunkan ambang batas teknologi yang belum terdalam penelitiannya, dan membantu komunitas menghilangkan gangguan untuk fokus pada kemajuan desain sistem bukti yang sebenarnya.
Tahap Kinerja
Berikut adalah lima tonggak kinerja yang saya usulkan. Pertama, kami perlu secara signifikan mengurangi biaya validator pada CPU sebelum kita dapat lebih lanjut mengandalkan perangkat keras untuk mengurangi biaya. Selain itu, penggunaan memori juga harus ditingkatkan.
Pada semua tahap, pengembang tidak boleh menyesuaikan kode untuk kinerja zkVM. Pengalaman pengembang adalah keuntungan inti dari zkVM. Jika mengorbankan DevEx untuk memenuhi standar kinerja, bukan hanya kehilangan makna pengujian standar, tetapi juga melanggar tujuan awal zkVM.
Indikator-indikator ini utamanya berkaitan dengan biaya pembuktian. Namun, jika diperbolehkan bagi validator untuk biaya tumbuh tak terbatas (yaitu ukuran bukti atau waktu verifikasi tanpa batas), maka semua indikator pembuktian dapat dengan mudah dipenuhi. Oleh karena itu, untuk memenuhi persyaratan tahapan berikut, maka harus membatasi ukuran bukti maksimum dan waktu verifikasi maksimum secara bersamaan.
Tahap 1 Persyaratan: "Biaya Verifikasi Non-Trivial yang Masuk Akal"
• Ukuran bukti: Harus lebih kecil dari ukuran bukti.
• Waktu Verifikasi : Kecepatan verifikasi bukti tidak boleh lebih lambat dari eksekusi asli program (yaitu, tidak boleh lebih lambat dari perhitungan langsung).
Ini adalah persyaratan kejelasan minimal untuk memastikan ukuran bukti dan waktu verifikasi tidak lebih buruk daripada mengirimkan bukti langsung ke verifikator untuk diperiksa langsung.
Tahap 2 dan seterusnya
• Ukuran Bukti Maksimum : 256 KB.
• Waktu Verifikasi Maksimum : 16 milidetik.
Batasan-batasan ini sengaja ditetapkan dengan longgar untuk menyesuaikan dengan teknologi bukti cepat yang inovatif, meskipun hal itu mungkin mengakibatkan biaya verifikasi yang lebih tinggi. Sementara itu, batasan-batasan ini juga mengesampingkan bukti yang begitu mahal sehingga hampir tidak ada proyek yang bersedia menggunakannya di blockchain.
Tahap Kecepatan 1
Bukti Tunggal Kecepatan Tidak Boleh Lebih Dari 100.000 Kali Lebih Lambat Dari Eksekusi Asli (Berlaku untuk berbagai aplikasi, bukan hanya bukti blok Ethereum), dan tidak boleh bergantung pada pra-kompilasi.
Secara khusus, asumsikan bahwa kecepatan processor RISC-V pada laptop modern adalah sekitar 30 miliar siklus/detik, maka mencapai tahap 1 berarti laptop tersebut dapat menghasilkan bukti dengan kecepatan 30.000 siklus RISC-V/detik (single thread).
Biaya validator harus memenuhi standar "biaya validasi yang wajar dan tidak biasa" yang telah ditetapkan sebelumnya.
Tahap Kecepatan 2
Bukti tunggal tidak boleh lebih dari 10.000 kali lebih lambat dari eksekusi asli.
Atau, karena beberapa metode SNARK yang menjanjikan (terutama SNARK domain biner) terbatas oleh CPU dan GPU saat ini, bisa dipenuhi dengan FPGA (bahkan ASIC) pada tahap ini:
Hitung jumlah inti RISC-V yang disimulasikan oleh FPGA pada kecepatan aslinya.
Hitung dan buktikan jumlah FPGA yang diperlukan untuk mensimulasikan dan membuktikan eksekusi RISC-V (hampir real-time).
Jika jumlah (2)tidak melebihi 10.000 kali (1), maka memenuhi tahap 2.
• Ukuran bukti：maksimal 256 KB。
• Waktu verifikasi: maksimum 16 milidetik pada CPU standar.
Tahap Kecepatan 3
Pada dasarnya, dengan mencapai Tahap Kecepatan 2, mencapai biaya bukti di bawah 1000× (berlaku untuk berbagai aplikasi), dan harus menggunakan pra-kompilasi otomatis dan verifikasi formal. Secara esensial, mencustom setiap set instruksi program secara dinamis untuk mempercepat pembangkitan bukti, tetapi harus memastikan kemudahan penggunaan dan verifikasi formal. (Tentang mengapa pra-kompilasi adalah pedang bermata dua, dan mengapa pra-kompilasi 'manual' bukan metode yang berkelanjutan, lihat bagian berikutnya.)
Tahap Memori 1
Dalam kurang dari 2 GB memori, mencapai tahap kecepatan 1, dan pada saat yang sama memenuhi persyaratan pengetahuan nol. Tahap ini sangat penting untuk perangkat seluler atau browser, dan membuka pintu untuk banyak kasus penggunaan zkVM di sisi klien. Misalnya, ponsel pintar digunakan untuk privasi lokasi, kredensial identitas, dll. Jika pembuatan bukti memerlukan lebih dari 1-2 GB memori, sebagian besar perangkat seluler tidak akan dapat menjalankannya.
Dua Poin Penting:
Bahkan untuk komputasi berskala besar (yang memerlukan eksekusi asli selama miliaran siklus CPU), sistem bukti harus tetap mempertahankan batas atas 2 GB memorinya, jika tidak, kegunaannya akan terbatas.
Tahap Memori 2
Mencapai Tahap Kecepatan 1 (10 kali lipat dari Tahap Memori 1) dalam kurang dari 200 MB memori.
Mengapa harus turun menjadi 200 MB? Pertimbangkan sebuah skenario diluar blockchain: ketika Anda mengakses situs web HTTPS, Anda akan mengunduh sertifikat otentikasi dan enkripsi. Jika situs web beralih untuk mengirimkan bukti zk dari sertifikat ini, situs web besar mungkin perlu menghasilkan jutaan bukti setiap detik. Jika setiap bukti memerlukan 2 GB memori, kebutuhan sumber daya komputasi akan mencapai tingkat PB, yang jelas tidak dapat dilakukan. Oleh karena itu, menurunkan penggunaan memori lebih lanjut sangat penting bagi aplikasi diluar blockchain.
**Prakompilasi: Mil terakhir, atau kruk? **
Pre-kompilasi merujuk pada **sistem kendali SNARK yang dioptimalkan khusus untuk fungsi tertentu (seperti hash, tanda tangan kurva elips) **. Di Ethereum, pre-kompilasi dapat mengurangi biaya hash Merkle dan verifikasi tanda tangan, namun ketergantungan berlebihan pada pre-kompilasi tidak benar-benar meningkatkan efisiensi inti SNARK.
Masalah Kompilasi Pra-
1. Masih Terlalu Lambat: Meskipun menggunakan prakompilasi hash dan tanda tangan, zkVM masih menghadapi masalah efisiensi inti dari sistem bukti di dalam dan di luar rantai blok.
2.安全漏洞：Jika pra-kompilasi manual tidak diverifikasi secara formal, hampir pasti akan ada kerentanan yang dapat menyebabkan kegagalan keamanan yang fatal.
3. Pengalaman Pengembang Buruk: Saat ini, banyak zkVM memerlukan pengembang menulis ulang sistem constraint, mirip dengan cara pemrograman tahun 1960-an, yang sangat memengaruhi pengalaman pengembangan.
4.测试基准误导：Jika pengujian basis bergantung pada optimisasi pra-kompilasi tertentu, ini mungkin menyesatkan orang untuk fokus pada sistem kendali optimisasi manual, bukan meningkatkan desain SNARK itu sendiri.
5.Overhead I/O dan Tanpa Akses RAM**Meskipun prakompilasi dapat meningkatkan performa tugas kriptografi yang berat, prakompilasi mungkin tidak memberikan akselerasi yang berarti untuk beban kerja yang lebih beragam karena menimbulkan overhead yang signifikan saat meneruskan input/output, dan mereka tidak dapat menggunakan RAM.
Meskipun berada dalam lingkungan blockchain, begitu Anda melampaui L1 tunggal seperti Ethereum (misalnya, Anda ingin membangun serangkaian jembatan lintas-rantai), Anda akan dihadapkan pada fungsi hash dan skema tanda tangan yang berbeda. Untuk mengatasi masalah ini, terus melakukan pra-penyusunan, ini tidak dapat diperluas dan akan membawa risiko keamanan yang besar.
Saya benar-benar percaya bahwa pra-kompilasi tetap sangat penting dalam jangka panjang, tetapi hanya jika mereka disintesis secara otomatis dan diverifikasi secara resmi. Dengan demikian, kita dapat mempertahankan keunggulan pengalaman pengembang zkVM, sambil menghindari risiko keamanan yang berpotensi merugikan. Pandangan ini tercermin dalam tahap 3.
Jadwal yang Diharapkan
Saya memperkirakan beberapa zkVM akan mencapai Fase Kecepatan 1 dan Fase Memori 1 dalam tahun ini. Saya berpikir bahwa dalam dua tahun ke depan, kita juga dapat mencapai Fase Kecepatan 2, tetapi saat ini belum jelas apakah kita dapat mencapai tujuan ini tanpa ide penelitian baru.
Saya memperkirakan tahap-tahap yang tersisa (Tahap Kecepatan 3 dan Tahap Memori 2) akan memerlukan beberapa tahun lagi untuk dicapai.
Meskipun artikel ini secara terpisah mencantumkan tahap keamanan dan kinerja zkVM, keduanya tidak sepenuhnya independen. Seiring dengan terus ditemukannya kerentanan dalam zkVM, saya memperkirakan perbaikan beberapa kerentanan tersebut akan tak terhindarkan menyebabkan penurunan kinerja yang signifikan. Oleh karena itu, hasil uji kinerja zkVM sebelum mencapai Tahap Keamanan 2 harus dianggap sebagai data sementara.
zkVM memiliki potensi besar dalam mendorong penyebaran bukti pengetahuan nol yang sebenarnya, tetapi saat ini masih berada dalam tahap awal - penuh dengan tantangan keamanan dan menghadapi hambatan kinerja yang serius. Spekulasi pasar dan promosi pemasaran membuat penilaian kemajuan yang sebenarnya menjadi sulit. Melalui tonggak keamanan dan kinerja yang jelas, saya berharap dapat menyediakan peta jalan yang dapat membantu menjelaskan. Kami pasti akan mencapai tujuan ini, tetapi hal itu memerlukan waktu, serta upaya penelitian dan rekayasa yang berkelanjutan.