Salah satu pendiri Scroll, Zhang Ye, berbicara tentang empat bagian. Di bagian pertama, Zhang Ye memperkenalkan latar belakang pengembangan dan mengapa kita membutuhkan zkEVM dan mengapa zkEVM menjadi begitu populer dalam dua tahun terakhir menjelaskan caranya melalui proses yang lengkap. Membangun zkEVM dari awal termasuk sistem aritmatika dan pembuktian. Bagian ketiga membahas tentang masalah yang dihadapi Scroll saat membangun zkEVM melalui beberapa pertanyaan penelitian yang menarik, dan akhirnya memperkenalkan beberapa aplikasi lain menggunakan zkEVM.
Blockchain Layer 1 tradisional akan memiliki beberapa node yang dikelola bersama melalui jaringan P2P. Ketika mereka menerima transaksi pengguna, mereka akan mengeksekusinya di mesin virtual EVM, membaca kontrak panggilan dan penyimpanan, dan memperbarui pohon keadaan global sesuai dengan transaksi tersebut.
Keuntungan dari arsitektur seperti ini adalah desentralisasi dan keamanan. Kerugiannya adalah biaya transaksi pada L1 mahal dan konfirmasi transaksi lambat.
Pada arsitektur ZK-Rollup, jaringan L2 hanya perlu mengunggah data dan pembuktiannya untuk memverifikasi kebenaran data ke L1, dimana pembuktiannya dihitung melalui rangkaian zero-knowledge proof.
Pada awal ZK-Rollup, sirkuit dirancang untuk aplikasi tertentu. Pengguna perlu mengirim transaksi ke server yang berbeda, dan kemudian ZK-Rollup dari aplikasi yang berbeda mengirimkan data dan bukti mereka sendiri ke L1. Masalah yang ditimbulkannya adalah komposisi kontrak L1 asli hilang.
Apa yang dilakukan Scroll adalah solusi zkEVM asli, yang merupakan ZK-Rollup untuk tujuan umum. Ini tidak hanya lebih ramah pengguna, tetapi juga memberi pengembang pengalaman pengembangan yang lebih baik di L1. Tentu saja, pengembangan di balik hal ini sangat sulit, dan biaya pembuatan bukti saat ini juga sangat tinggi.
Untungnya, efisiensi pembuktian tanpa pengetahuan telah meningkat secara signifikan dalam dua tahun terakhir, itulah sebabnya zkEVM menjadi sangat populer dalam dua tahun terakhir. Setidaknya ada empat alasan mengapa hal ini menjadi mungkin dilakukan. Yang pertama adalah munculnya komitmen polinomial. Di bawah sistem pembuktian Groth16 yang asli, skala kendalanya sangat besar, namun komitmen polinomial dapat mendukung kendala tingkat tinggi dan mengurangi skala kendala tersebut. bukti; kedua, Munculnya tabel pencarian dan gerbang khusus dapat mendukung desain yang lebih fleksibel dan membuat pembuktian lebih efisien; yang ketiga adalah terobosan dalam akselerasi perangkat keras, yang dapat mempersingkat waktu pembuktian sebesar 1-2 kali lipat melalui GPU, FPGA, dan ASIC; Yang keempat Di bawah pembuktian rekursif, beberapa bukti dapat dikompres menjadi satu bukti, menjadikan bukti lebih kecil dan lebih mudah untuk diverifikasi. Jadi dengan menggabungkan keempat faktor ini, efisiensi pembuatan bukti tanpa pengetahuan adalah tiga kali lipat lebih tinggi dibandingkan dua tahun lalu, yang juga merupakan asal mula Scoll.
Menurut definisi Justin Drake, zkEVM dapat dibagi menjadi tiga kategori. Kategori pertama adalah kompatibilitas tingkat bahasa. Alasan utamanya adalah EVM tidak dirancang untuk ZK dan memiliki banyak opcode yang tidak bersahabat dengan ZK, sehingga akan menyebabkan a. banyak overhead tambahan. Oleh karena itu, perusahaan seperti Starkware dan zkSync memilih untuk mengkompilasi Solidity atau Yul menjadi kompiler ramah ZK di tingkat bahasa.
Tipe kedua adalah kompatibilitas tingkat bytecode yang dilakukan Scroll, yang secara langsung membuktikan apakah pemrosesan bytecode EVM benar atau tidak, dan secara langsung mewarisi lingkungan eksekusi Ethereum. Beberapa trade-off yang dapat dilakukan di sini adalah dengan menggunakan state root yang berbeda dari EVM, seperti menggunakan struktur data yang ramah ZK. Hermez dan Consensys melakukan hal serupa.
Kategori ketiga adalah kompatibilitas pada tingkat konsensus. Keuntungannya di sini adalah bahwa EVM tidak hanya perlu diubah, tetapi juga mencakup struktur penyimpanan untuk mencapai kompatibilitas penuh dengan Ethereum, dengan mengorbankan waktu pembuktian yang lebih lama. Scroll sedang dibangun bekerja sama dengan tim PSE dari Ethereum Foundation untuk mewujudkan ZKisasi Ethereum.
Di bagian kedua, Zhang Ye menunjukkan kepada semua orang cara membangun ZKVM dari awal.
Proses lengkap
Pertama-tama, di bagian front-end ZKP, Anda perlu mengekspresikan perhitungan Anda melalui aritmatika matematika. Yang paling umum digunakan adalah R1CS linier, serta Plonkish dan AIR. Setelah mendapatkan batasan melalui aritmatika, Anda perlu menjalankan algoritma pembuktian di backend ZKP untuk membuktikan kebenaran perhitungan. Berikut adalah pembuktian oracle interaktif polinomial (IOP Polinomial) dan skema komitmen polinomial (PCS) yang paling umum digunakan.
Disini kita perlu membuktikan bahwa zkEVM dan Scroll menggunakan kombinasi Plonkish, Plonk IOP, dan KZG.
Untuk memahami mengapa kami menggunakan ketiga solusi ini. Pertama-tama kita mulai dengan R1CS yang paling sederhana. Kendala dalam R1CS adalah kombinasi linier dikalikan kombinasi linier sama dengan kombinasi linier. Anda dapat menambahkan kombinasi variabel linier apa pun tanpa overhead tambahan, tetapi urutan maksimum di setiap batasan adalah 2. Oleh karena itu, untuk operasi tingkat tinggi, diperlukan lebih banyak batasan.
Di Plonkish, Anda perlu mengisi semua variabel ke dalam tabel, termasuk input, output, dan saksi untuk variabel perantara. Selain itu, Anda dapat menentukan batasan yang berbeda. Ada tiga jenis kendala yang tersedia di Plonkish.
Jenis batasan pertama adalah gerbang khusus. Anda dapat menentukan hubungan batasan polinomial antara sel yang berbeda, seperti va3 * vb3 * vc3 - vb4 =0. Dibandingkan dengan R1CS, urutannya bisa lebih tinggi karena Anda dapat menentukan batasan pada variabel apa pun, dan Anda dapat menentukan beberapa batasan yang sangat berbeda.
Jenis batasan kedua adalah Permuasi, atau pemeriksaan kesetaraan. Ini dapat digunakan untuk memeriksa kesetaraan sel yang berbeda, dan sering digunakan untuk menghubungkan gerbang yang berbeda dalam suatu rangkaian, seperti membuktikan bahwa keluaran dari gerbang sebelumnya sama dengan masukan dari gerbang berikutnya.
Jenis batasan terakhir adalah tabel pencarian. Tabel pencarian dapat kita pahami sebagai hubungan antar variabel, yang dapat dinyatakan dalam bentuk tabel. Misalnya, kami ingin membuktikan bahwa vc7 berada dalam kisaran 0-15. Di R1CS, pertama-tama Anda perlu menguraikan nilai ini menjadi biner 4-bit, lalu membuktikan bahwa setiap bit berada dalam kisaran 0-1, yang mana akan memerlukan empat kendala. Di Plonkish, Anda dapat membuat daftar semua rentang yang mungkin dalam kolom yang sama dan hanya perlu membuktikan bahwa vc7 termasuk dalam kolom tersebut. Ini sangat efisien untuk pembuktian rentang. Di zkEVM, tabel pencarian sangat berguna untuk membuktikan pembacaan dan penulisan memori.
Singkatnya, Plonkish juga mendukung gerbang khusus, pemeriksaan kesetaraan, dan tabel pencarian, yang bisa sangat fleksibel untuk memenuhi kebutuhan sirkuit yang berbeda. Perbandingan sederhana dari STARK. Setiap baris di STARK adalah sebuah batasan. Batasan tersebut harus mewakili transisi keadaan antar baris, tetapi fleksibilitas batasan khusus di Plonkish jelas lebih tinggi.
Pertanyaannya sekarang adalah bagaimana kita memilih front end di zkEVM. Ada empat tantangan utama untuk zkEVM. Tantangan pertama adalah bidang EVM adalah 256 bit, yang berarti bahwa variabel harus dibatasi rentangnya secara efisien; tantangan kedua adalah bahwa EVM memiliki banyak opcode yang tidak ramah ZK, sehingga diperlukan batasan berskala sangat besar untuk membuktikan operasi ini. .kode, seperti Keccak-256; tantangan ketiga adalah masalah baca dan tulis memori, Anda memerlukan pemetaan yang efektif untuk membuktikan bahwa apa yang Anda baca konsisten dengan apa yang Anda tulis sebelumnya; berubah secara dinamis, jadi kita memerlukan gerbang khusus untuk beradaptasi dengan jejak eksekusi yang berbeda. Kami memilih Plonkish karena pertimbangan di atas.
Selanjutnya, mari kita lihat proses lengkap zkEVM. Berdasarkan pohon keadaan global awal, setelah transaksi baru masuk, EVM akan membaca bytecode kontrak yang disimpan dan dipanggil, dan menghasilkan jejak eksekusi yang sesuai berdasarkan transaksi tersebut, seperti sebagai PUSH, PUSH , STORE, CALLVALUE, lalu perbarui status global secara bertahap untuk mendapatkan pohon status global setelah transaksi. zkEVM mengambil pohon keadaan global awal, transaksi itu sendiri, dan pohon keadaan global setelah transaksi sebagai masukan, dan menggunakan spesifikasi EVM untuk membuktikan kebenaran jejak eksekusi.
Menggali detail sirkuit EVM, setiap langkah jejak eksekusi memiliki batasan sirkuit yang sesuai. Secara khusus, batasan rangkaian setiap langkah mencakup Konteks Langkah, Pengalihan Kasus, dan Saksi Spesifik Opcode. Konteks Langkah berisi codehash, sisa gas, dan penghitung yang sesuai dengan jejak eksekusi; Case Switch berisi semua opcode, semua kondisi kesalahan, dan operasi terkait dari langkah tersebut; Opcode Spesifik Witness berisi saksi tambahan yang diperlukan oleh opcode, seperti operan tunggu.
Mengambil penjumlahan sederhana sebagai contoh, Anda perlu memastikan bahwa variabel kontrol sADD dari opcode penambahan diatur ke 1, dan variabel kontrol dari opcode lainnya semuanya nol. Dalam Konteks Langkah, gas yang dikonsumsi dibatasi menjadi sama dengan 3 dengan mengatur gas' - gas - 3 = 0. Demikian pula, penghitung dibatasi. Penunjuk tumpukan mengumpulkan 1 setelah langkah; variabel dikontrol ke 1 melalui opcode. Untuk membatasi langkah ini menjadi operasi penambahan; dalam Opcode Spesifik Witness, membatasi penambahan operan yang sebenarnya.
Selain itu, batasan rangkaian tambahan diperlukan untuk memastikan kebenaran operan yang dibaca dari memori. Di sini pertama-tama kita perlu membuat tabel pencarian untuk membuktikan bahwa operan tersebut milik memori. Dan verifikasi kebenaran tabel memori melalui rangkaian memori (RAM Circuit).
Metode yang sama dapat diterapkan pada fungsi hash yang tidak ramah zk. Buat tabel pencarian fungsi hash, petakan input dan output hash dalam jejak eksekusi ke tabel pencarian, dan gunakan sirkuit hash tambahan untuk memverifikasi fungsi hash kebenaran tabel pencarian.
Sekarang mari kita lihat arsitektur sirkuit zkEVM. Sirkuit inti EVM digunakan untuk membatasi kebenaran setiap langkah jejak eksekusi. Di beberapa tempat di mana batasan sirkuit EVM sulit, kami menggunakan tabel pencarian untuk memetakan, termasuk Tabel Tetap, Keccak Tabel, Tabel RAM, Bytecode, Transaksi, Konteks Blok, dan kemudian gunakan sirkuit terpisah untuk membatasi tabel pencarian ini, seperti sirkuit Keccak untuk membatasi tabel Keccak.
Singkatnya, alur kerja lengkap zkEVM ditunjukkan pada gambar di bawah.
sistem bukti
Karena memverifikasi secara langsung sirkuit EVM, sirkuit memori, sirkuit penyimpanan, dll. yang disebutkan di atas pada L1 mahal, sistem pembuktian Scroll mengadopsi arsitektur dua lapis.
Lapisan pertama bertanggung jawab untuk membuktikan secara langsung EVM itu sendiri, yang memerlukan sejumlah besar komputasi untuk menghasilkan bukti. Oleh karena itu, sistem pembuktian tingkat pertama diperlukan untuk mendukung gerbang khusus dan tabel pencarian, ramah terhadap akselerasi perangkat keras, menghasilkan perhitungan secara paralel di bawah memori puncak rendah, dan memiliki sirkuit verifikasi kecil yang dapat diverifikasi dengan cepat. Alternatif yang menjanjikan termasuk Plonky2, Starky, dan eSTARK. Semuanya pada dasarnya menggunakan Plonk di bagian depan, tetapi mungkin menggunakan FRI di bagian belakang, dan semuanya memenuhi empat karakteristik di atas. Jenis solusi alternatif lainnya termasuk Halo2 yang dikembangkan oleh Zcash dan Halo2 versi KZG.
Ada juga beberapa sistem pembuktian baru yang menjanjikan, seperti HyperPlonk, yang baru-baru ini menghapus FFT, dan sistem pembuktian NOVA dapat menghasilkan pembuktian rekursif yang lebih kecil. Tapi mereka hanya mendukung R1CS dalam penelitian. Jika mereka bisa mendukung Plonkish di masa depan dan menerapkannya dalam praktik, itu akan sangat praktis dan efisien.
Sistem pembuktian tingkat kedua digunakan untuk membuktikan kebenaran pembuktian tingkat pertama dan perlu diverifikasi secara efisien di EVM. Idealnya, sistem tersebut harus ramah akselerasi perangkat keras dan mendukung pengaturan transparan atau universal. Alternatif yang menjanjikan termasuk Groth16 dan sistem pembuktian Plonkish tanpa kolom. Groth16 masih mewakili efisiensi pembuktian yang sangat tinggi dalam penelitian saat ini, dan sistem pembuktian Plonkish juga dapat mencapai efisiensi pembuktian yang tinggi bahkan dengan jumlah kolom yang sedikit.
Di Scroll, kami menggunakan sistem bukti Halo2-KZG di kedua sistem bukti dua lapis kami. Karena Halo2-KZG dapat mendukung gerbang khusus dan tabel pencarian, ia bekerja dengan baik di bawah akselerasi perangkat keras GPU, dan sirkuit verifikasi berukuran kecil dan dapat diverifikasi dengan cepat. Bedanya, kami menggunakan hashing Poseidon pada sistem bukti lapisan pertama untuk lebih meningkatkan efisiensi pembuktian, sedangkan sistem bukti lapisan kedua masih menggunakan hashing Keccak karena diverifikasi langsung di Ethereum. Scroll juga menjajaki kemungkinan sistem pembuktian berlapis untuk lebih mengagregasi bukti agregat yang dihasilkan oleh sistem pembuktian tingkat kedua.
Di bawah implementasi saat ini, sirkuit EVM sistem bukti tingkat pertama Scroll memiliki 116 kolom, 2496 gerbang khusus, 50 tabel pencarian, urutan tertinggi adalah 9, dan membutuhkan 2^18 baris di bawah 1M Gas; rangkaian agregasi hanya memiliki 23 kolom, 1 gerbang khusus, 7 tabel pencarian, dan urutan tertinggi adalah 5. Untuk mengagregasi rangkaian EVM, rangkaian memori, dan rangkaian penyimpanan, diperlukan 2^25 baris.
Scroll juga telah melakukan banyak penelitian dan pengoptimalan pada akselerasi perangkat keras GPU. Untuk sirkuit EVM, pembuktian GPU yang dioptimalkan hanya membutuhkan waktu 30 detik, yang 9 kali lebih efisien daripada pembuktian CPU. Untuk rangkaian agregasi, setelah pengoptimalan Pembuktian GPU saja membutuhkan waktu 149 detik, yang 15 kali lebih efisien dibandingkan CPU. Dalam kondisi optimasi saat ini, sistem pembuktian tingkat pertama Gas 1M membutuhkan waktu sekitar 2 menit, dan sistem pembuktian tingkat kedua membutuhkan waktu sekitar 3 menit.
Pada bagian ketiga, Zhang Ye berbicara tentang beberapa masalah penelitian menarik dalam proses Scroll membangun zkEVM, mulai dari rangkaian aritmatika front-end hingga implementasi pembuktian.
sirkuit
Yang pertama adalah keacakan dalam rangkaian. Karena bidang EVM adalah 256 bit, kita perlu membaginya menjadi 32 bidang 8-bit untuk melakukan pembuktian jangkauan dengan lebih efisien. Kemudian kita menggunakan metode Random Linear Combination (RLC) untuk mengkodekan 32 field menjadi 1 menggunakan angka acak. Kita hanya perlu memverifikasi field ini untuk memverifikasi field 256-bit asli. Namun masalahnya adalah nomor acak perlu dihasilkan setelah kolom dipecah untuk memastikan bahwa nomor tersebut tidak dirusak. Oleh karena itu, Scroll dan tim PSE mengusulkan solusi pembuktian multi-tahap untuk memastikan bahwa setelah pemisahan bidang, angka acak digunakan untuk menghasilkan RLC. RLC memiliki banyak skenario aplikasi di zkEVM. RLC tidak hanya dapat mengompresi bidang EVM menjadi satu bidang, tetapi juga mengenkripsi input dengan panjang variabel atau mengoptimalkan tata letak tabel pencarian.
Pertanyaan penelitian menarik kedua dalam rangkaian adalah tata letak rangkaian. Alasan mengapa Scroll front-end menggunakan Plonkish adalah karena jejak eksekusi EVM berubah secara dinamis dan harus mampu mendukung berbagai batasan dan mengubah pengujian kesetaraan, dan gerbang standar R1CS memerlukan skala sirkuit yang lebih besar untuk diterapkan. Namun, Scroll saat ini menggunakan lebih dari 2.000 gerbang khusus untuk memenuhi jejak eksekusi yang berubah secara dinamis, dan juga mengeksplorasi cara mengoptimalkan tata letak sirkuit lebih lanjut, termasuk membagi Opcode menjadi Micro Opcode, atau menggunakan kembali sel dalam tabel yang sama.
Pertanyaan penelitian menarik ketiga dalam sirkuit adalah penskalaan dinamis. Karena skala rangkaian opcode yang berbeda berbeda, tetapi untuk memenuhi jejak eksekusi yang berubah secara dinamis, opcode setiap langkah harus memenuhi skala rangkaian maksimum, seperti hashing Keccak, jadi kami sebenarnya membayar overhead ekstra. Dengan asumsi kita dapat membuat zkEVM beradaptasi secara dinamis terhadap jejak eksekusi yang berubah secara dinamis, hal ini akan menghemat overhead yang tidak diperlukan.
pepatah
Dalam hal pembuktian, Scroll telah melakukan banyak optimasi untuk MSM dan NTT dalam hal akselerasi GPU, namun kini hambatannya telah bergeser ke pembuatan saksi dan penyalinan data. Karena diasumsikan bahwa MSM dan NTT menempati 80% waktu pembuktian, meskipun akselerasi perangkat keras dapat meningkatkan efisiensi ini hingga beberapa kali lipat, 20% waktu pembuktian awal untuk menghasilkan dan menyalin data akan menjadi hambatan baru. Masalah lain dengan Prover adalah memerlukan banyak memori, sehingga solusi perangkat keras yang lebih murah dan terdesentralisasi perlu dieksplorasi.
Pada saat yang sama, Scroll juga mengeksplorasi akselerasi perangkat keras dan algoritma pembuktian untuk meningkatkan efisiensi pembuktian. Saat ini ada dua arah utama, beralih ke domain yang lebih kecil, seperti menggunakan domain Goldilocks 64-bit, Mersenne Prime 32-bit, dll., atau tetap menggunakan sistem pembuktian baru berdasarkan kurva elips (EC). . Tentu saja, ada kemungkinan jalan lain, dan teman yang punya ide dipersilakan untuk menghubungi Scroll secara langsung.
keamanan
Saat membangun zkEVM, keamanan adalah yang terpenting. ZkEVM yang dibangun bersama oleh PSE dan Scroll memiliki sekitar 34.000 baris kode Dari perspektif rekayasa perangkat lunak, basis kode yang kompleks ini tidak mungkin bebas dari kerentanan untuk waktu yang lama. Scroll saat ini sedang meninjau basis kode zkEVM melalui sejumlah besar audit, termasuk dari firma audit terkemuka di industri.
Bagian 4 mengeksplorasi aplikasi lain yang menggunakan zkEVM.
Dalam arsitektur zkRollup, kami memverifikasi bahwa n transaksi di L2 valid melalui kontrak pintar di L1.
Jika kita memverifikasi langsung blok L1, maka node L1 tidak perlu melakukan eksekusi transaksi berulang kali, melainkan hanya perlu memverifikasi keabsahan setiap sertifikat blok. Solusi arsitektur seperti ini disebut Enshrine Blockchain. Saat ini, sangat sulit untuk menerapkan secara langsung pada Ethereum karena seluruh blok Ethereum perlu diverifikasi, yang mencakup verifikasi tanda tangan dalam jumlah besar, yang mengakibatkan waktu verifikasi lebih lama dan keamanan lebih rendah. Tentu saja, sudah ada beberapa rantai publik lain yang menggunakan bukti rekursif untuk memverifikasi seluruh blockchain menggunakan satu bukti, seperti Mina.
Karena zkEVM dapat membuktikan transisi negara, zkEVM juga dapat digunakan oleh kelompok topi putih untuk membuktikan bahwa mereka mengetahui kerentanan kontrak pintar tertentu dan mencari imbalan dari pihak proyek.
Kasus penggunaan terakhir adalah untuk membuktikan klaim tentang data historis melalui bukti tanpa pengetahuan dan menggunakannya sebagai ramalan yang saat ini dibuat oleh Aksioma di bidang ini. Pada Hackathon ETHBeijing baru-baru ini, tim GasLockR memanfaatkan fitur ini untuk membuktikan overhead Gas historis.
Terakhir, Scroll sedang membangun solusi penskalaan universal zkRollup untuk Ethereum, menggunakan sirkuit aritmatika dan sistem pembuktian yang sangat canggih, dan membangun verifikator cepat melalui akselerasi perangkat keras untuk membuktikan rekursi. Saat ini, jaringan pengujian Alpha telah online dan berjalan stabil dalam waktu yang lama.
Tentu saja, masih ada beberapa masalah menarik yang perlu diselesaikan, termasuk desain protokol dan desain mekanisme, rekayasa tanpa pengetahuan, dan efisiensi aktual. Setiap orang dipersilakan untuk bergabung dengan Scroll untuk membangun bersama!
