Jalur menuju zkVM yang aman dan efisien: Bagaimana melacak kemajuan
Penulis asli: a16z crypto
原文编译：Golem，Odaily 星球日报
zkVM (Zero Knowledge Virtual Machine) berkomitmen untuk "membuat SNARK populer", memungkinkan siapa pun (bahkan yang tidak memiliki pengetahuan profesional tentang SNARK) untuk membuktikan bahwa mereka telah menjalankan program apa pun dengan benar pada input yang diberikan (atau saksi). Keunggulan inti mereka ada dalam pengalaman pengembang, tetapi saat ini mereka menghadapi tantangan besar dalam hal keamanan dan kinerja. Untuk mewujudkan visi zkVM, para perancang harus mengatasi tantangan-tantangan ini. Dalam artikel ini, saya mencantumkan kemungkinan tahapan pengembangan zkVM, yang akan memerlukan beberapa tahun untuk diselesaikan.
Tantangan
Dalam hal keamanan, zkVM adalah proyek perangkat lunak yang sangat kompleks dan masih penuh dengan kerentanan. Dari segi kinerja, kecepatan pembuktian bahwa program berjalan dengan benar mungkin jauh lebih lambat daripada menjalankannya secara lokal, yang membuat sebagian besar aplikasi saat ini tidak dapat diterapkan dalam dunia nyata.
Meskipun menghadapi tantangan nyata ini, sebagian besar perusahaan di industri blockchain menggambarkan zkVM sebagai sesuatu yang dapat didisain dan diterapkan secara instan. Bahkan, beberapa proyek telah membayar biaya komputasi yang besar untuk menghasilkan bukti aktivitas di rantai. Namun, karena zkVM masih belum sempurna, ini hanya merupakan cara mahal untuk pura-pura melindungi sistem dengan SNARK, padahal sebenarnya itu hanya dilindungi melalui izin, atau yang lebih buruk, rentan terhadap serangan.
Kami masih beberapa tahun lagi dari mewujudkan zkVM yang aman dan berkinerja tinggi. Artikel ini menyajikan serangkaian tujuan spesifik bertahap untuk melacak kemajuan zkVM - tujuan-tujuan ini dapat menghilangkan sensasionalisme dan membantu komunitas fokus pada kemajuan yang sebenarnya.
Tahap Keamanan
Berdasarkan SNARK, zkVM umumnya terdiri dari dua komponen utama:
· Bukti Interaktif Oracle untuk Polinomial (PIOP): Kerangka bukti interaktif untuk menyatakan tentang polinomial (atau kendala yang diperoleh darinya).
Skema Komitmen Polinomial (PCS): Memastikan bahwa pembuktian tidak dapat berbohong dalam mengevaluasi polinomial tanpa terdeteksi.
zkVM pada dasarnya mengkodekan pelaksanaan yang efektif ke dalam sistem kendala - secara luas berarti mereka memaksa mesin virtual untuk menggunakan register dan memori dengan benar - kemudian menerapkan SNARK untuk membuktikan bahwa kendala-kendala ini dipenuhi.
Pastikan satu-satunya cara untuk memastikan sistem yang kompleks seperti zkVM tidak ada kesalahan adalah melalui verifikasi formal. Berikut adalah pembagian tahap keamanan. Tahap 1 berfokus pada protokol yang benar, sementara Tahap 2 dan Tahap 3 berfokus pada implementasi yang benar.
Tahap Keamanan 1: Protokol yang Benar
1、Bukti verifikasi resmi kehandalan PIOP;
2、PCS memverifikasi bukti dalam bentuk yang mengikat di bawah beberapa asumsi kriptografi atau model ideal;
3、Jika menggunakan Fiat-Shamir, maka bukti formal yang aman dalam model ramalan acak diperoleh dengan menggabungkan PIOP dan PCS (diperkuat dengan asumsi enkripsi lain yang diperlukan);
4、Sistem kendali yang digunakan oleh PIOP setara dengan bukti verifikasi formal semantik VM;
Menggabungkan semua bagian-bagian tersebut secara menyeluruh menjadi bukti SNARK keamanan yang terverifikasi secara formal, untuk menjalankan program apapun yang ditentukan oleh bytecode VM. Jika protokol bertujuan untuk mewujudkan zero-knowledge, properti ini juga harus diverifikasi secara formal untuk memastikan tidak ada informasi sensitif yang bocor tentang saksi.
Peringatan Rekursif: Jika zkVM menggunakan rekursif, maka setiap PIOP, skema komitmen, dan sistem konstrain yang terlibat di mana pun dalam rekursif tersebut harus diverifikasi sebelum tahap ini dianggap selesai.
Tahap Keselamatan 2: Implementasi Validator yang Benar
Verifikasi formal membuktikan bahwa implementasi aktual dari validator zkVM (menggunakan Rust, Solidity, dll.) sesuai dengan protokol verifikasi tahap 1. Melakukan hal ini dapat memastikan bahwa protokol yang diimplementasikan adalah rasional (bukan hanya desain di atas kertas, atau spesifikasi yang tidak efisien yang ditulis dengan Lean, dll.).
Fase 2 hanya fokus pada implementasi validator (bukan prover) karena ada dua alasan. Pertama, penggunaan validator yang benar sudah cukup untuk menjamin keandalan (yaitu memastikan validator tidak dapat percaya bahwa pernyataan palsu apa pun sebenarnya benar). Kedua, implementasi validator zkVM lebih dari satu urutan besarnya lebih sederhana daripada prover.
Tahap Keamanan 3: Implementasi Verifier yang Benar
Implementasi nyata dari zkVM Prover menghasilkan bukti verifikasi Fase 1 dan Fase 2 dari sistem bukti, yaitu verifikasi resmi. Ini memastikan integritas, artinya tidak ada pernyataan yang tidak dapat dibuktikan yang akan 'membekukan' sistem yang menggunakan zkVM. Jika Prover bermaksud menerapkan zero knowledge, properti ini harus diverifikasi secara resmi.
Jadwal Perkiraan
· Kemajuan Tahap 1: Kita dapat mengharapkan pencapaian bertahap tahun depan (misalnya ZKLib). Tetapi setidaknya dalam dua tahun, tidak ada zkVM yang dapat sepenuhnya memenuhi persyaratan Tahap 1;
· Tahap 2 dan Tahap 3: Tahap-tahap ini dapat berjalan seiring dengan beberapa aspek Tahap 1. Sebagai contoh, beberapa tim telah membuktikan implementasi Verifier Plonk sesuai dengan protokol dalam makalah (meskipun protokol dalam makalah mungkin belum sepenuhnya diverifikasi). Namun, saya memperkirakan bahwa tidak ada zkVM yang akan mencapai Tahap 3 dalam waktu kurang dari empat tahun — dan mungkin lebih lama lagi.
Perhatian Penting: Keamanan Fiat-Shamir dan Bytecode yang Diverifikasi
Salah satu faktor kompleks utama adalah, ada masalah penelitian yang belum terselesaikan seputar keamanan konversi Fiat-Shamir. Ketiga tahap tersebut menganggap Fiat-Shamir dan orakel acak sebagai bagian keamanannya yang tak terkalahkan, tetapi pada kenyataannya paradigma keseluruhan mungkin memiliki celah. Hal ini disebabkan oleh perbedaan yang terlalu idealis antara orakel acak dan fungsi hash yang digunakan secara nyata. Dalam kasus terburuk, karena masalah Fiat-Shamir, sistem yang telah mencapai tahap ke-2 kemungkinan besar kemudian ditemukan tidak aman sama sekali. Hal ini menimbulkan kekhawatiran serius dan penelitian yang berkelanjutan. Kemungkinan kita perlu memodifikasi konversi itu sendiri untuk lebih baik mencegah celah semacam itu.
Sistem tanpa rekursi secara teoritis lebih stabil karena beberapa serangan yang diketahui melibatkan sirkuit yang mirip dengan sirkuit yang digunakan dalam bukti rekursi.
Hal lain yang perlu diperhatikan adalah, jika bytecode itu sendiri memiliki cacat, maka bukti bahwa program komputer telah berjalan dengan benar (yang ditentukan oleh bytecode) memiliki nilai yang terbatas. Oleh karena itu, kegunaan zkVM sangat bergantung pada metode pembuatan bytecode verifikasi formal - ini adalah tantangan besar yang melebihi lingkup pembahasan dalam artikel ini.
Tentang Keamanan di Era Pasca-Kuantum
Setidaknya dalam lima tahun ke depan (mungkin lebih lama), komputer kuantum tidak akan menjadi ancaman serius, sedangkan kerentanan merupakan risiko kelangsungan hidup. Oleh karena itu, fokus utama saat ini seharusnya memenuhi tahap keamanan dan kinerja yang dibahas dalam teks ini. Jika kita dapat memenuhi persyaratan keamanan ini lebih cepat dengan menggunakan SNARK yang tidak aman dari segi kuantum, maka kita harus melakukannya hingga SNARK kuantum kemudian mencapai, atau orang-orang mulai serius khawatir tentang munculnya komputer kuantum terkait enkripsi saat mempertimbangkan yang lain.
Kinerja zkVM saat ini
Saat ini, biaya yang dihasilkan oleh verifier zkVM mendekati 1 juta kali biaya eksekusi asli. Jika program memerlukan X siklus untuk berjalan, biaya eksekusi yang benar sekitar X kali 1 juta siklus CPU. Ini berlaku satu tahun yang lalu dan tetap berlaku hari ini.
Cerita populer biasanya menggambarkan pengeluaran ini dengan cara yang terdengar dapat diterima. Misalnya:
·「Biaya untuk menghasilkan bukti konsensus di jaringan utama Ethereum kurang dari satu juta dolar per tahun.」
·「Kita hampir dapat menghasilkan bukti blok Ethereum secara real-time menggunakan klaster yang terdiri dari puluhan GPU.」
· "zkVM terbaru kami 1000 kali lebih cepat dari pendahulunya."
Meskipun secara teknis pernyataan tersebut akurat, namun tanpa latar belakang yang tepat, dapat menimbulkan kebingungan. Contohnya:
· Dibandingkan dengan zkVM versi sebelumnya, kecepatannya meningkat 1000 kali, namun kecepatan absolutnya masih sangat lambat. Ini lebih banyak menunjukkan seberapa buruknya situasi daripada seberapa baiknya.
Seseorang telah mengusulkan peningkatan 10 kali lipat dalam jumlah komputasi yang ditangani oleh jaringan utama Ethereum. Ini akan membuat kinerja zkVM saat ini menjadi lebih lambat.
Bukti hampir real-time dari blok Ethereum masih jauh lebih lambat daripada yang dibutuhkan oleh banyak aplikasi blockchain (misalnya, waktu blok Optimism adalah 2 detik, jauh lebih cepat dari waktu blok Ethereum 12 detik).
· 'Beberapa puluh GPU berjalan terus-menerus tanpa kesalahan' tidak mencapai jaminan aktivitas yang dapat diterima.
· Pengeluaran kurang dari satu juta dolar per tahun untuk membuktikan bahwa semua aktivitas di jaringan Ethereum mencerminkan fakta bahwa setiap tahun hanya diperlukan sekitar 25 dolar untuk menjalankan node lengkap Ethereum.
Untuk aplikasi di luar blockchain, biaya ini jelas terlalu tinggi. Tidak ada paralelisme atau rekayasa yang dapat menutupi biaya sebesar ini. Kita harus menganggap kecepatan zkVM tidak lebih dari 100.000 kali lebih lambat dibandingkan eksekusi asli sebagai dasar yang mendasar—meskipun ini hanya langkah pertama. Adopsi mainstream yang sebenarnya mungkin memerlukan biaya mendekati 10.000 kali atau bahkan lebih rendah.
Cara Mengukur Kinerja
Kinerja SNARK terdiri dari tiga komponen utama:
· Efisiensi intrinsik dari sistem bukti dasar.
Optimisasi khusus aplikasi (misalnya pra-kompilasi).
· Percepatan perangkat lunak dan perangkat keras (misalnya GPU, FPGA, atau CPU multi-inti).
Meskipun kedua hal tersebut sangat penting untuk implementasi praktis, tetapi biasanya mereka dapat diterapkan pada sistem bukti apa pun, sehingga tidak selalu mencerminkan biaya dasar. Misalnya, menambahkan akselerasi GPU dan pra-penyusunan dalam zkEVM dapat dengan mudah mencapai percepatan 50 kali lipat, yang jauh lebih cepat daripada metode tanpa pra-penyusunan yang murni berbasis CPU - cukup untuk membuat sistem yang secara mendasar kurang efisien terlihat lebih unggul daripada sistem yang tidak diolah dengan cara yang sama.
Oleh karena itu, berikut ini akan dijelaskan kinerja SNARK tanpa perangkat keras khusus dan pra-kompilasi. Ini berbeda dengan metode pengujian dasar saat ini, yang biasanya menggabungkan ketiga faktor tersebut ke dalam satu 'angka benchmark'. Ini seolah-olah menilai nilai berlian berdasarkan waktu poles daripada kemurniannya yang sejati. Tujuan kami adalah untuk menghilangkan biaya internal dari sistem bukti umum - membantu komunitas untuk menghilangkan faktor-faktor bercampur, dan fokus pada kemajuan nyata dari desain sistem bukti.
Tahapan Kinerja
Berikut adalah 5 tonggak kinerja yang dicapai. Pertama, kita perlu mengurangi biaya verifikator pada CPU secara signifikan. Hanya dengan begitu, fokus bisa beralih ke pengurangan lebih lanjut melalui perangkat keras. Tingkat penggunaan memori juga harus ditingkatkan.
Pada semua tahap di bawah ini, pengembang tidak perlu mengimplementasikan kode yang disesuaikan dengan pengaturan zkVM untuk mencapai kinerja yang diperlukan. Pengalaman pengembang adalah keuntungan utama dari zkVM. Mengorbankan DevEx untuk memenuhi standar kinerja akan melanggar makna sejati zkVM itu sendiri.
Indikator ini menekankan pada biaya validator. Namun, jika biaya validator tidak terbatas diperbolehkan (yaitu tidak ada batasan pada ukuran bukti atau waktu verifikasi), maka mudah memenuhi setiap indikator validator. Oleh karena itu, untuk sistem yang ingin memenuhi tahap yang disebutkan, ukuran bukti dan waktu verifikasi harus ditetapkan dengan nilai maksimum.
Persyaratan Kinerja
Persyaratan Tahap 1: 'Biaya verifikasi yang wajar dan tidak biasa':
· Ukuran bukti: Ukuran bukti harus lebih kecil dari ukuran saksi.
· Waktu verifikasi: Kecepatan verifikasi bukti tidak boleh lebih lambat dari program yang berjalan di mesin lokal (yaitu, melakukan perhitungan tanpa bukti kebenaran).
Ini adalah persyaratan sederhana minimum. Mereka memastikan bahwa ukuran bukti dan waktu verifikasi tidak lebih buruk daripada mengirimkan saksi ke pemeriksa dan membiarkan pemeriksa memeriksanya secara langsung.
Persyaratan Tahap 2 dan seterusnya:
· Ukuran bukti maksimum: 256 KB.
· Waktu verifikasi maksimum: 16 milidetik.
Nilai-nilai ambang ini sengaja diperbesar untuk menyesuaikan dengan teknologi bukti cepat yang mungkin memiliki biaya verifikasi yang lebih tinggi. Pada saat yang sama, mereka mengecualikan bukti yang sangat mahal sehingga jarang ada proyek yang bersedia menyertakan mereka dalam blockchain.
Tahap Kecepatan 1
Bukti single-thread harus berjalan paling lambat sepuluh ribu kali lebih lambat dari eksekusi lokal, diukur dalam serangkaian aplikasi (bukan hanya blok Ethereum) tanpa mengandalkan pra-kompilasi.
Secara khusus, bayangkan menjalankan proses RISC-V pada sekitar 30 miliar siklus per detik di laptop modern. Melakukan Tahap 1 berarti Anda dapat membuktikan sekitar 30.000 siklus RISC-V (single-thread) per detik pada laptop yang sama. Namun, biaya verifikasi harus 'wajar dan tidak biasa' seperti yang disebutkan sebelumnya.
Tahap Kecepatan 2
Bukti satu utas harus paling lambat satu juta kali lebih lambat dari eksekusi lokal.
Atau, karena beberapa metode SNARK yang menjanjikan (terutama yang didasarkan pada bidang biner) terhalang oleh CPU dan GPU saat ini, Anda dapat mencapai tahap ini dengan membandingkan penggunaan FPGA (bahkan ASIC).
FPGA dapat mensimulasikan jumlah inti RISC-V pada kecepatan lokal;
Simulasikan dan buktikan jumlah FPGA yang diperlukan untuk menjalankan RISC-V (hampir) secara real-time.
Jika yang terakhir paling banyak 10.000 kali lebih besar dari yang pertama, maka Anda memenuhi syarat untuk masuk ke tahap 2. Pada CPU standar, ukuran bukti harus maksimal 256 KB, dan waktu verifikasi maksimal 16 milidetik.
Tahap Kecepatan 3
Selain mencapai Tahap 2 kecepatan, juga dapat menggunakan pra-penggabungan otomatis dan verifikasi bentuk untuk mengimplementasikan pembuktian dengan pengeluaran kurang dari 1000 kali (cocok untuk aplikasi yang luas). Pada dasarnya, setiap program dapat disesuaikan secara dinamis dengan set instruksi untuk mempercepat pembuktian, namun harus dilakukan dengan cara yang mudah digunakan dan diverifikasi bentuknya.
Tahap Memori 1
Kecepatan tahap 1 dicapai dengan membutuhkan kurang dari 2 GB memori pada validator (sambil tetap mempertahankan zero-knowledge).
Hal ini sangat penting untuk banyak perangkat mobile atau browser, sehingga membuka banyak kasus penggunaan zkVM klien. Bukti klien sangat penting karena ponsel kita adalah hubungan berkelanjutan kita dengan dunia nyata: mereka melacak lokasi kita, kredensial, dll. Jika menghasilkan bukti membutuhkan lebih dari 1-2 GB memori, itu terlalu banyak untuk sebagian besar perangkat mobile saat ini. Perlu klarifikasi dua hal:
· Batas ruang 2 GB berlaku untuk pernyataan yang besar (perlu puluhan triliun siklus CPU untuk dijalankan secara lokal). Sistem bukti batas ruang hanya diterapkan pada pernyataan kecil kurang memiliki aplikasi yang luas.
Jika pembuktinya sangat lambat, maka sangat mudah untuk menjaga ruang pembuktinya di bawah 2 GB memori. Oleh karena itu, untuk membuat tahap memori 1 menjadi tidak sederhana, saya meminta agar tahap kecepatan 1 dipenuhi dalam batas ruang 2 GB.
Tahap Memori 2
Kecepatan Tahap 1 dicapai dengan penggunaan memori kurang dari 200 MB (10 kali lebih baik dari Tahap 1 memori).
Mengapa harus turun di bawah 2 GB? Pertimbangkan contoh non-blockchain: setiap kali mengakses situs web melalui HTTPS, Anda akan mengunduh sertifikat untuk otentikasi dan enkripsi. Sebagai alternatif, situs web dapat mengirimkan bukti zk yang memiliki sertifikat tersebut. Situs web besar mungkin menghasilkan jutaan bukti seperti itu setiap detik. Jika setiap bukti memerlukan 2 GB RAM untuk dibuat, maka secara keseluruhan akan memerlukan RAM tingkat PB. Menurunkan lebih lanjut penggunaan memori sangat penting untuk implementasi non-blockchain.
Pra-kompilasi: Apakah tetap tongkat di ujung jalan terakhir?
Dalam desain zkVM, pra-kompilasi merujuk pada SNARK yang disesuaikan khusus untuk fungsi tertentu, misalnya hash Keccak/SHA untuk tanda tangan digital atau operasi grup kurva elips. Di Ethereum (di mana sebagian besar pekerjaan berat melibatkan hash Merkle dan pemeriksaan tanda tangan), beberapa pra-kompilasi buatan tangan dapat mengurangi biaya verifikator. Namun, bergantung pada mereka sebagai tongkat tidak akan membuat SNARK mencapai tujuan yang diinginkan. Alasannya adalah sebagai berikut:
· Untuk sebagian besar aplikasi (baik di dalam maupun di luar rantai blok), masih terlalu lambat: Meskipun menggunakan pra-kompilasi hash dan tanda tangan, zkVM saat ini masih terlalu lambat (baik di dalam maupun di luar lingkungan rantai blok) karena efisiensi sistem bukti inti yang rendah.
· Kegagalan Keamanan: Pra-pengkodean tulisan tangan yang tidak diverifikasi secara resmi hampir pasti penuh dengan kesalahan, yang dapat menyebabkan kegagalan keamanan yang menghancurkan.
· Pengalaman Pengembang Tidak Memuaskan: Dalam kebanyakan zkVM saat ini, menambahkan prekompilasi baru berarti menulis ulang sistem constraint secara manual untuk setiap fitur - pada dasarnya kembali ke alur kerja gaya 1960-an. Bahkan dengan menggunakan prekompilasi yang ada, pengembang harus refactor kode untuk memanggil setiap prekompilasi. Kita harus mengoptimalkan keamanan dan pengalaman pengembang, bukan mengorbankan keduanya demi meningkatkan kinerja secara inkremental. Melakukan hal itu hanya akan membuktikan bahwa kinerja tidak mencapai tingkat yang seharusnya.
· Biaya I/O dan Tanpa RAM: Meskipun pra-kompilasi dapat meningkatkan kinerja tugas enkripsi yang berat, namun mungkin tidak dapat memberikan akselerasi yang bermakna untuk beban kerja yang lebih beragam, karena mereka menghasilkan biaya yang besar saat mentransfer input/output, dan mereka tidak dapat menggunakan RAM. Bahkan dalam lingkungan blockchain, begitu Anda melampaui L1 tunggal seperti Ethereum (misalnya, Anda ingin membangun serangkaian jembatan lintas rantai), Anda akan menghadapi fungsi hash dan skema tanda tangan yang berbeda. Mengulang pra-kompilasi berulang kali pada masalah tidak dapat diperluas dan membawa risiko keamanan yang besar.
Dengan alasan-alasan ini, tugas utama kita harus meningkatkan efisiensi zkVM yang mendasar. Teknologi terbaik zkVM juga akan menghasilkan pra-kompilasi terbaik. Saya benar-benar percaya bahwa pra-kompilasi tetap sangat penting dalam jangka panjang, tetapi asalkan mereka disintesis secara otomatis dan diverifikasi secara resmi. Dengan cara ini, kita dapat menjaga keunggulan pengalaman pengembang zkVM, sambil menghindari risiko keamanan yang menghancurkan. Pandangan ini tercermin dalam tahap kecepatan 3.
Jadwal Perkiraan
Saya memperkirakan bahwa sebagian kecil zkVM akan mencapai Tahap Kecepatan 1 dan Tahap Memori 1 lebih lambat tahun ini. Saya berpikir kita juga akan mencapai Tahap Kecepatan 2 dalam dua tahun ke depan, tetapi saat ini tidak jelas apakah kita dapat mencapai tujuan ini tanpa beberapa ide baru yang belum muncul. Saya memperkirakan sisa tahapan (Tahap Kecepatan 3 dan Tahap Memori 2) akan memerlukan beberapa tahun lagi untuk dicapai.
Ringkasan
Meskipun saya telah secara terpisah menetapkan tahapan keamanan dan kinerja zkVM dalam artikel ini, namun aspek-aspek zkVM ini tidak sepenuhnya independen. Dengan penemuan lebih banyak kerentanan dalam zkVM, diperkirakan beberapa kerentanan hanya dapat diperbaiki dengan penurunan kinerja yang signifikan. Performa harus ditunda hingga zkVM mencapai tahap keamanan 2.
zkVM berpotensi untuk membuat bukti pengetahuan nol benar-benar populer, tetapi mereka masih berada dalam tahap awal - penuh dengan tantangan keamanan dan biaya kinerja yang besar. Sensasi dan pemasaran membuat penilaian kemajuan yang sebenarnya menjadi sulit. Dengan menguraikan tonggak keamanan dan kinerja yang jelas, diharapkan dapat memberikan peta jalan tanpa gangguan. Kami akan mencapai tujuan tersebut, tetapi ini memerlukan waktu dan upaya yang berkelanjutan.
Tautan Asli
：
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: Bagaimana Mengimplementasikan zkVM yang Aman dan Efisien Secara Bertahap (Penting untuk Pengembang)
zkVM (Zero Knowledge Virtual Machine) berkomitmen untuk "membuat SNARK populer", memungkinkan siapa pun (bahkan yang tidak memiliki pengetahuan profesional tentang SNARK) untuk membuktikan bahwa mereka telah menjalankan program apa pun dengan benar pada input yang diberikan (atau saksi). Keunggulan inti mereka ada dalam pengalaman pengembang, tetapi saat ini mereka menghadapi tantangan besar dalam hal keamanan dan kinerja. Untuk mewujudkan visi zkVM, para perancang harus mengatasi tantangan-tantangan ini. Dalam artikel ini, saya mencantumkan kemungkinan tahapan pengembangan zkVM, yang akan memerlukan beberapa tahun untuk diselesaikan.
Tantangan
Dalam hal keamanan, zkVM adalah proyek perangkat lunak yang sangat kompleks dan masih penuh dengan kerentanan. Dari segi kinerja, kecepatan pembuktian bahwa program berjalan dengan benar mungkin jauh lebih lambat daripada menjalankannya secara lokal, yang membuat sebagian besar aplikasi saat ini tidak dapat diterapkan dalam dunia nyata.
Meskipun menghadapi tantangan nyata ini, sebagian besar perusahaan di industri blockchain menggambarkan zkVM sebagai sesuatu yang dapat didisain dan diterapkan secara instan. Bahkan, beberapa proyek telah membayar biaya komputasi yang besar untuk menghasilkan bukti aktivitas di rantai. Namun, karena zkVM masih belum sempurna, ini hanya merupakan cara mahal untuk pura-pura melindungi sistem dengan SNARK, padahal sebenarnya itu hanya dilindungi melalui izin, atau yang lebih buruk, rentan terhadap serangan.
Kami masih beberapa tahun lagi dari mewujudkan zkVM yang aman dan berkinerja tinggi. Artikel ini menyajikan serangkaian tujuan spesifik bertahap untuk melacak kemajuan zkVM - tujuan-tujuan ini dapat menghilangkan sensasionalisme dan membantu komunitas fokus pada kemajuan yang sebenarnya.
Tahap Keamanan
Berdasarkan SNARK, zkVM umumnya terdiri dari dua komponen utama:
· Bukti Interaktif Oracle untuk Polinomial (PIOP): Kerangka bukti interaktif untuk menyatakan tentang polinomial (atau kendala yang diperoleh darinya).
zkVM pada dasarnya mengkodekan pelaksanaan yang efektif ke dalam sistem kendala - secara luas berarti mereka memaksa mesin virtual untuk menggunakan register dan memori dengan benar - kemudian menerapkan SNARK untuk membuktikan bahwa kendala-kendala ini dipenuhi.
Pastikan satu-satunya cara untuk memastikan sistem yang kompleks seperti zkVM tidak ada kesalahan adalah melalui verifikasi formal. Berikut adalah pembagian tahap keamanan. Tahap 1 berfokus pada protokol yang benar, sementara Tahap 2 dan Tahap 3 berfokus pada implementasi yang benar.
Tahap Keamanan 1: Protokol yang Benar
1、Bukti verifikasi resmi kehandalan PIOP;
2、PCS memverifikasi bukti dalam bentuk yang mengikat di bawah beberapa asumsi kriptografi atau model ideal;
3、Jika menggunakan Fiat-Shamir, maka bukti formal yang aman dalam model ramalan acak diperoleh dengan menggabungkan PIOP dan PCS (diperkuat dengan asumsi enkripsi lain yang diperlukan);
4、Sistem kendali yang digunakan oleh PIOP setara dengan bukti verifikasi formal semantik VM;
Peringatan Rekursif: Jika zkVM menggunakan rekursif, maka setiap PIOP, skema komitmen, dan sistem konstrain yang terlibat di mana pun dalam rekursif tersebut harus diverifikasi sebelum tahap ini dianggap selesai.
Tahap Keselamatan 2: Implementasi Validator yang Benar
Verifikasi formal membuktikan bahwa implementasi aktual dari validator zkVM (menggunakan Rust, Solidity, dll.) sesuai dengan protokol verifikasi tahap 1. Melakukan hal ini dapat memastikan bahwa protokol yang diimplementasikan adalah rasional (bukan hanya desain di atas kertas, atau spesifikasi yang tidak efisien yang ditulis dengan Lean, dll.).
Fase 2 hanya fokus pada implementasi validator (bukan prover) karena ada dua alasan. Pertama, penggunaan validator yang benar sudah cukup untuk menjamin keandalan (yaitu memastikan validator tidak dapat percaya bahwa pernyataan palsu apa pun sebenarnya benar). Kedua, implementasi validator zkVM lebih dari satu urutan besarnya lebih sederhana daripada prover.
Tahap Keamanan 3: Implementasi Verifier yang Benar
Implementasi nyata dari zkVM Prover menghasilkan bukti verifikasi Fase 1 dan Fase 2 dari sistem bukti, yaitu verifikasi resmi. Ini memastikan integritas, artinya tidak ada pernyataan yang tidak dapat dibuktikan yang akan 'membekukan' sistem yang menggunakan zkVM. Jika Prover bermaksud menerapkan zero knowledge, properti ini harus diverifikasi secara resmi.
Jadwal Perkiraan
· Kemajuan Tahap 1: Kita dapat mengharapkan pencapaian bertahap tahun depan (misalnya ZKLib). Tetapi setidaknya dalam dua tahun, tidak ada zkVM yang dapat sepenuhnya memenuhi persyaratan Tahap 1;
· Tahap 2 dan Tahap 3: Tahap-tahap ini dapat berjalan seiring dengan beberapa aspek Tahap 1. Sebagai contoh, beberapa tim telah membuktikan implementasi Verifier Plonk sesuai dengan protokol dalam makalah (meskipun protokol dalam makalah mungkin belum sepenuhnya diverifikasi). Namun, saya memperkirakan bahwa tidak ada zkVM yang akan mencapai Tahap 3 dalam waktu kurang dari empat tahun — dan mungkin lebih lama lagi.
Perhatian Penting: Keamanan Fiat-Shamir dan Bytecode yang Diverifikasi
Salah satu faktor kompleks utama adalah, ada masalah penelitian yang belum terselesaikan seputar keamanan konversi Fiat-Shamir. Ketiga tahap tersebut menganggap Fiat-Shamir dan orakel acak sebagai bagian keamanannya yang tak terkalahkan, tetapi pada kenyataannya paradigma keseluruhan mungkin memiliki celah. Hal ini disebabkan oleh perbedaan yang terlalu idealis antara orakel acak dan fungsi hash yang digunakan secara nyata. Dalam kasus terburuk, karena masalah Fiat-Shamir, sistem yang telah mencapai tahap ke-2 kemungkinan besar kemudian ditemukan tidak aman sama sekali. Hal ini menimbulkan kekhawatiran serius dan penelitian yang berkelanjutan. Kemungkinan kita perlu memodifikasi konversi itu sendiri untuk lebih baik mencegah celah semacam itu.
Sistem tanpa rekursi secara teoritis lebih stabil karena beberapa serangan yang diketahui melibatkan sirkuit yang mirip dengan sirkuit yang digunakan dalam bukti rekursi.
Hal lain yang perlu diperhatikan adalah, jika bytecode itu sendiri memiliki cacat, maka bukti bahwa program komputer telah berjalan dengan benar (yang ditentukan oleh bytecode) memiliki nilai yang terbatas. Oleh karena itu, kegunaan zkVM sangat bergantung pada metode pembuatan bytecode verifikasi formal - ini adalah tantangan besar yang melebihi lingkup pembahasan dalam artikel ini.
Tentang Keamanan di Era Pasca-Kuantum
Setidaknya dalam lima tahun ke depan (mungkin lebih lama), komputer kuantum tidak akan menjadi ancaman serius, sedangkan kerentanan merupakan risiko kelangsungan hidup. Oleh karena itu, fokus utama saat ini seharusnya memenuhi tahap keamanan dan kinerja yang dibahas dalam teks ini. Jika kita dapat memenuhi persyaratan keamanan ini lebih cepat dengan menggunakan SNARK yang tidak aman dari segi kuantum, maka kita harus melakukannya hingga SNARK kuantum kemudian mencapai, atau orang-orang mulai serius khawatir tentang munculnya komputer kuantum terkait enkripsi saat mempertimbangkan yang lain.
Kinerja zkVM saat ini
Saat ini, biaya yang dihasilkan oleh verifier zkVM mendekati 1 juta kali biaya eksekusi asli. Jika program memerlukan X siklus untuk berjalan, biaya eksekusi yang benar sekitar X kali 1 juta siklus CPU. Ini berlaku satu tahun yang lalu dan tetap berlaku hari ini.
Cerita populer biasanya menggambarkan pengeluaran ini dengan cara yang terdengar dapat diterima. Misalnya:
·「Biaya untuk menghasilkan bukti konsensus di jaringan utama Ethereum kurang dari satu juta dolar per tahun.」
·「Kita hampir dapat menghasilkan bukti blok Ethereum secara real-time menggunakan klaster yang terdiri dari puluhan GPU.」
· "zkVM terbaru kami 1000 kali lebih cepat dari pendahulunya."
Meskipun secara teknis pernyataan tersebut akurat, namun tanpa latar belakang yang tepat, dapat menimbulkan kebingungan. Contohnya:
· Dibandingkan dengan zkVM versi sebelumnya, kecepatannya meningkat 1000 kali, namun kecepatan absolutnya masih sangat lambat. Ini lebih banyak menunjukkan seberapa buruknya situasi daripada seberapa baiknya.
Seseorang telah mengusulkan peningkatan 10 kali lipat dalam jumlah komputasi yang ditangani oleh jaringan utama Ethereum. Ini akan membuat kinerja zkVM saat ini menjadi lebih lambat.
Bukti hampir real-time dari blok Ethereum masih jauh lebih lambat daripada yang dibutuhkan oleh banyak aplikasi blockchain (misalnya, waktu blok Optimism adalah 2 detik, jauh lebih cepat dari waktu blok Ethereum 12 detik).
· 'Beberapa puluh GPU berjalan terus-menerus tanpa kesalahan' tidak mencapai jaminan aktivitas yang dapat diterima.
· Pengeluaran kurang dari satu juta dolar per tahun untuk membuktikan bahwa semua aktivitas di jaringan Ethereum mencerminkan fakta bahwa setiap tahun hanya diperlukan sekitar 25 dolar untuk menjalankan node lengkap Ethereum.
Untuk aplikasi di luar blockchain, biaya ini jelas terlalu tinggi. Tidak ada paralelisme atau rekayasa yang dapat menutupi biaya sebesar ini. Kita harus menganggap kecepatan zkVM tidak lebih dari 100.000 kali lebih lambat dibandingkan eksekusi asli sebagai dasar yang mendasar—meskipun ini hanya langkah pertama. Adopsi mainstream yang sebenarnya mungkin memerlukan biaya mendekati 10.000 kali atau bahkan lebih rendah.
Cara Mengukur Kinerja
Kinerja SNARK terdiri dari tiga komponen utama:
· Efisiensi intrinsik dari sistem bukti dasar.
Optimisasi khusus aplikasi (misalnya pra-kompilasi).
· Percepatan perangkat lunak dan perangkat keras (misalnya GPU, FPGA, atau CPU multi-inti).
Meskipun kedua hal tersebut sangat penting untuk implementasi praktis, tetapi biasanya mereka dapat diterapkan pada sistem bukti apa pun, sehingga tidak selalu mencerminkan biaya dasar. Misalnya, menambahkan akselerasi GPU dan pra-penyusunan dalam zkEVM dapat dengan mudah mencapai percepatan 50 kali lipat, yang jauh lebih cepat daripada metode tanpa pra-penyusunan yang murni berbasis CPU - cukup untuk membuat sistem yang secara mendasar kurang efisien terlihat lebih unggul daripada sistem yang tidak diolah dengan cara yang sama.
Oleh karena itu, berikut ini akan dijelaskan kinerja SNARK tanpa perangkat keras khusus dan pra-kompilasi. Ini berbeda dengan metode pengujian dasar saat ini, yang biasanya menggabungkan ketiga faktor tersebut ke dalam satu 'angka benchmark'. Ini seolah-olah menilai nilai berlian berdasarkan waktu poles daripada kemurniannya yang sejati. Tujuan kami adalah untuk menghilangkan biaya internal dari sistem bukti umum - membantu komunitas untuk menghilangkan faktor-faktor bercampur, dan fokus pada kemajuan nyata dari desain sistem bukti.
Tahapan Kinerja
Berikut adalah 5 tonggak kinerja yang dicapai. Pertama, kita perlu mengurangi biaya verifikator pada CPU secara signifikan. Hanya dengan begitu, fokus bisa beralih ke pengurangan lebih lanjut melalui perangkat keras. Tingkat penggunaan memori juga harus ditingkatkan.
Pada semua tahap di bawah ini, pengembang tidak perlu mengimplementasikan kode yang disesuaikan dengan pengaturan zkVM untuk mencapai kinerja yang diperlukan. Pengalaman pengembang adalah keuntungan utama dari zkVM. Mengorbankan DevEx untuk memenuhi standar kinerja akan melanggar makna sejati zkVM itu sendiri.
Indikator ini menekankan pada biaya validator. Namun, jika biaya validator tidak terbatas diperbolehkan (yaitu tidak ada batasan pada ukuran bukti atau waktu verifikasi), maka mudah memenuhi setiap indikator validator. Oleh karena itu, untuk sistem yang ingin memenuhi tahap yang disebutkan, ukuran bukti dan waktu verifikasi harus ditetapkan dengan nilai maksimum.
Persyaratan Kinerja
Persyaratan Tahap 1: 'Biaya verifikasi yang wajar dan tidak biasa':
· Ukuran bukti: Ukuran bukti harus lebih kecil dari ukuran saksi.
· Waktu verifikasi: Kecepatan verifikasi bukti tidak boleh lebih lambat dari program yang berjalan di mesin lokal (yaitu, melakukan perhitungan tanpa bukti kebenaran).
Ini adalah persyaratan sederhana minimum. Mereka memastikan bahwa ukuran bukti dan waktu verifikasi tidak lebih buruk daripada mengirimkan saksi ke pemeriksa dan membiarkan pemeriksa memeriksanya secara langsung.
Persyaratan Tahap 2 dan seterusnya:
· Ukuran bukti maksimum: 256 KB.
· Waktu verifikasi maksimum: 16 milidetik.
Nilai-nilai ambang ini sengaja diperbesar untuk menyesuaikan dengan teknologi bukti cepat yang mungkin memiliki biaya verifikasi yang lebih tinggi. Pada saat yang sama, mereka mengecualikan bukti yang sangat mahal sehingga jarang ada proyek yang bersedia menyertakan mereka dalam blockchain.
Tahap Kecepatan 1
Bukti single-thread harus berjalan paling lambat sepuluh ribu kali lebih lambat dari eksekusi lokal, diukur dalam serangkaian aplikasi (bukan hanya blok Ethereum) tanpa mengandalkan pra-kompilasi.
Secara khusus, bayangkan menjalankan proses RISC-V pada sekitar 30 miliar siklus per detik di laptop modern. Melakukan Tahap 1 berarti Anda dapat membuktikan sekitar 30.000 siklus RISC-V (single-thread) per detik pada laptop yang sama. Namun, biaya verifikasi harus 'wajar dan tidak biasa' seperti yang disebutkan sebelumnya.
Tahap Kecepatan 2
Bukti satu utas harus paling lambat satu juta kali lebih lambat dari eksekusi lokal.
Atau, karena beberapa metode SNARK yang menjanjikan (terutama yang didasarkan pada bidang biner) terhalang oleh CPU dan GPU saat ini, Anda dapat mencapai tahap ini dengan membandingkan penggunaan FPGA (bahkan ASIC).
FPGA dapat mensimulasikan jumlah inti RISC-V pada kecepatan lokal;
Simulasikan dan buktikan jumlah FPGA yang diperlukan untuk menjalankan RISC-V (hampir) secara real-time.
Jika yang terakhir paling banyak 10.000 kali lebih besar dari yang pertama, maka Anda memenuhi syarat untuk masuk ke tahap 2. Pada CPU standar, ukuran bukti harus maksimal 256 KB, dan waktu verifikasi maksimal 16 milidetik.
Tahap Kecepatan 3
Selain mencapai Tahap 2 kecepatan, juga dapat menggunakan pra-penggabungan otomatis dan verifikasi bentuk untuk mengimplementasikan pembuktian dengan pengeluaran kurang dari 1000 kali (cocok untuk aplikasi yang luas). Pada dasarnya, setiap program dapat disesuaikan secara dinamis dengan set instruksi untuk mempercepat pembuktian, namun harus dilakukan dengan cara yang mudah digunakan dan diverifikasi bentuknya.
Tahap Memori 1
Kecepatan tahap 1 dicapai dengan membutuhkan kurang dari 2 GB memori pada validator (sambil tetap mempertahankan zero-knowledge).
Hal ini sangat penting untuk banyak perangkat mobile atau browser, sehingga membuka banyak kasus penggunaan zkVM klien. Bukti klien sangat penting karena ponsel kita adalah hubungan berkelanjutan kita dengan dunia nyata: mereka melacak lokasi kita, kredensial, dll. Jika menghasilkan bukti membutuhkan lebih dari 1-2 GB memori, itu terlalu banyak untuk sebagian besar perangkat mobile saat ini. Perlu klarifikasi dua hal:
· Batas ruang 2 GB berlaku untuk pernyataan yang besar (perlu puluhan triliun siklus CPU untuk dijalankan secara lokal). Sistem bukti batas ruang hanya diterapkan pada pernyataan kecil kurang memiliki aplikasi yang luas.
Jika pembuktinya sangat lambat, maka sangat mudah untuk menjaga ruang pembuktinya di bawah 2 GB memori. Oleh karena itu, untuk membuat tahap memori 1 menjadi tidak sederhana, saya meminta agar tahap kecepatan 1 dipenuhi dalam batas ruang 2 GB.
Tahap Memori 2
Kecepatan Tahap 1 dicapai dengan penggunaan memori kurang dari 200 MB (10 kali lebih baik dari Tahap 1 memori).
Mengapa harus turun di bawah 2 GB? Pertimbangkan contoh non-blockchain: setiap kali mengakses situs web melalui HTTPS, Anda akan mengunduh sertifikat untuk otentikasi dan enkripsi. Sebagai alternatif, situs web dapat mengirimkan bukti zk yang memiliki sertifikat tersebut. Situs web besar mungkin menghasilkan jutaan bukti seperti itu setiap detik. Jika setiap bukti memerlukan 2 GB RAM untuk dibuat, maka secara keseluruhan akan memerlukan RAM tingkat PB. Menurunkan lebih lanjut penggunaan memori sangat penting untuk implementasi non-blockchain.
Pra-kompilasi: Apakah tetap tongkat di ujung jalan terakhir?
Dalam desain zkVM, pra-kompilasi merujuk pada SNARK yang disesuaikan khusus untuk fungsi tertentu, misalnya hash Keccak/SHA untuk tanda tangan digital atau operasi grup kurva elips. Di Ethereum (di mana sebagian besar pekerjaan berat melibatkan hash Merkle dan pemeriksaan tanda tangan), beberapa pra-kompilasi buatan tangan dapat mengurangi biaya verifikator. Namun, bergantung pada mereka sebagai tongkat tidak akan membuat SNARK mencapai tujuan yang diinginkan. Alasannya adalah sebagai berikut:
· Untuk sebagian besar aplikasi (baik di dalam maupun di luar rantai blok), masih terlalu lambat: Meskipun menggunakan pra-kompilasi hash dan tanda tangan, zkVM saat ini masih terlalu lambat (baik di dalam maupun di luar lingkungan rantai blok) karena efisiensi sistem bukti inti yang rendah.
· Kegagalan Keamanan: Pra-pengkodean tulisan tangan yang tidak diverifikasi secara resmi hampir pasti penuh dengan kesalahan, yang dapat menyebabkan kegagalan keamanan yang menghancurkan.
· Pengalaman Pengembang Tidak Memuaskan: Dalam kebanyakan zkVM saat ini, menambahkan prekompilasi baru berarti menulis ulang sistem constraint secara manual untuk setiap fitur - pada dasarnya kembali ke alur kerja gaya 1960-an. Bahkan dengan menggunakan prekompilasi yang ada, pengembang harus refactor kode untuk memanggil setiap prekompilasi. Kita harus mengoptimalkan keamanan dan pengalaman pengembang, bukan mengorbankan keduanya demi meningkatkan kinerja secara inkremental. Melakukan hal itu hanya akan membuktikan bahwa kinerja tidak mencapai tingkat yang seharusnya.
· Biaya I/O dan Tanpa RAM: Meskipun pra-kompilasi dapat meningkatkan kinerja tugas enkripsi yang berat, namun mungkin tidak dapat memberikan akselerasi yang bermakna untuk beban kerja yang lebih beragam, karena mereka menghasilkan biaya yang besar saat mentransfer input/output, dan mereka tidak dapat menggunakan RAM. Bahkan dalam lingkungan blockchain, begitu Anda melampaui L1 tunggal seperti Ethereum (misalnya, Anda ingin membangun serangkaian jembatan lintas rantai), Anda akan menghadapi fungsi hash dan skema tanda tangan yang berbeda. Mengulang pra-kompilasi berulang kali pada masalah tidak dapat diperluas dan membawa risiko keamanan yang besar.
Dengan alasan-alasan ini, tugas utama kita harus meningkatkan efisiensi zkVM yang mendasar. Teknologi terbaik zkVM juga akan menghasilkan pra-kompilasi terbaik. Saya benar-benar percaya bahwa pra-kompilasi tetap sangat penting dalam jangka panjang, tetapi asalkan mereka disintesis secara otomatis dan diverifikasi secara resmi. Dengan cara ini, kita dapat menjaga keunggulan pengalaman pengembang zkVM, sambil menghindari risiko keamanan yang menghancurkan. Pandangan ini tercermin dalam tahap kecepatan 3.
Jadwal Perkiraan
Saya memperkirakan bahwa sebagian kecil zkVM akan mencapai Tahap Kecepatan 1 dan Tahap Memori 1 lebih lambat tahun ini. Saya berpikir kita juga akan mencapai Tahap Kecepatan 2 dalam dua tahun ke depan, tetapi saat ini tidak jelas apakah kita dapat mencapai tujuan ini tanpa beberapa ide baru yang belum muncul. Saya memperkirakan sisa tahapan (Tahap Kecepatan 3 dan Tahap Memori 2) akan memerlukan beberapa tahun lagi untuk dicapai.
Ringkasan
Meskipun saya telah secara terpisah menetapkan tahapan keamanan dan kinerja zkVM dalam artikel ini, namun aspek-aspek zkVM ini tidak sepenuhnya independen. Dengan penemuan lebih banyak kerentanan dalam zkVM, diperkirakan beberapa kerentanan hanya dapat diperbaiki dengan penurunan kinerja yang signifikan. Performa harus ditunda hingga zkVM mencapai tahap keamanan 2.
zkVM berpotensi untuk membuat bukti pengetahuan nol benar-benar populer, tetapi mereka masih berada dalam tahap awal - penuh dengan tantangan keamanan dan biaya kinerja yang besar. Sensasi dan pemasaran membuat penilaian kemajuan yang sebenarnya menjadi sulit. Dengan menguraikan tonggak keamanan dan kinerja yang jelas, diharapkan dapat memberikan peta jalan tanpa gangguan. Kami akan mencapai tujuan tersebut, tetapi ini memerlukan waktu dan upaya yang berkelanjutan.
Tautan Asli
：