Artikel ini ditulis oleh Insinyur ZK Taiko, CeciliaZ_ .
Beberapa waktu yang lalu, kami membagikan artikel mendetail berjudul “Mengapa multi-bukti itu penting,” menjelaskan pentingnya multi-bukti dan berfokus pada SGX sebagai salah satu opsi untuk multi-bukti. Artikel ini terinspirasi oleh ruang X (Twitter) kami bersama Vitalik dan postingan blog yang ia terbitkan kemudian, yang menyajikan peta jalan umum Taiko tentang multi-bukti: bagaimana hubungannya dengan permainan akhir, apa visi kami, dan bagaimana kami akan mencapainya.
Dalam pandangan kami, multi-bukti di ZK diterjemahkan menjadi multi-klien yang dikompilasi dengan multi-SNARK, yang akan meletakkan dasar bagi keragaman klien SNARK di masa depan Ethereum L1. Untuk memberikan alasan singkat mengenai multi-bukti, kami perlu menyebutkan dua hal:
- Pendekatan multi-bukti dapat melindungi risiko bug dan kerentanan dalam implementasi klien dan sistem pembuktian. Kemudian, jika terjadi bug, bahkan jika satu bukti rusak, bukti lain tidak akan membiarkan kerentanan yang sama dieksploitasi.
- Endgame Ethereum mengasumsikan blok L1 yang membuktikan ZK.
Sumber: https://twitter.com/vitalikbuterin/status/1741190491578810445.
Mirip dengan pendekatan multi-klien Ethereum , yang telah beberapa kali menyelamatkan jaringan dari kehancuran, pembuktian blok L1 akan memerlukan pendekatan multi-bukti. Hal ini, baik untuk skenario ZK maupun non-ZK, berarti multiklien + berbagai sistem pembuktian.
Sistem multi-klien & L1 Endgame
Seperti yang dijelaskan Vitalik dalam artikelnya, “Seperti apa bentuk “ZK-EVM yang diabadikan”?” , ada dua pendekatan terhadap sistem multiklien: “terbuka” vs. “tertutup.”
Get nop’s stories in your inbox
Join Medium for free to get updates from this writer.
Dalam sistem multiklien tertutup, serangkaian bukti tetap diketahui dalam protokol dan “dimasukkan ke dalam daftar putih” untuk menghasilkan bukti. Semua ZK L2 “tertutup” mengikuti kategorisasinya karena hanya menerima pembuktian penerapannya sendiri.
Dalam sistem multiklien terbuka, bukti ditempatkan “di luar blok” dan diverifikasi oleh klien secara terpisah. Pengguna individu akan menggunakan klien apa pun yang mereka inginkan untuk memverifikasi blok.
Dalam kasus yang naif, mereka akan mengeksekusi ulang blok tersebut menggunakan klien yang diinginkan, atau mereka dapat menanyakan bukti validitas eksekusi dari beberapa pembukti. Pengguna akan yakin jika jumlah bukti valid yang dilihat lebih dari yang diharapkan. Namun, jika tidak ada ZKP yang “diputihkan” dan kita ingin menghindari eksekusi ulang, ZKP mana yang sebaiknya kita gunakan? Dalam visi Vitalik, masalah ini diselesaikan melalui konsensus sosial (atau ekonomi kripto) di luar protokol.
Pada lapisan konsensus, kami menambahkan aturan validasi bahwa sebuah blok hanya diterima setelah klien melihat bukti valid untuk setiap klaim di blok tersebut. Buktinya harus berupa ZK-SNARK yang membuktikan klaim bahwa rangkaian
transaction_and_witness_blobsadalah serialisasi pasangan(Block, Witness), dan mengeksekusi blok di atas menggunakanpre_state_root(Witnessi) valid, dan (ii) menghasilkan output yang benarpost_state_root. Secara potensial, klien dapat memilih untuk menunggu M-of-N dari berbagai jenis bukti.
Bayangkan seorang pembangun jujur dengan blok tipe-1 yang ingin memberikan validitas; beberapa opsi sudah tersedia dari L2, seperti Polygon, zkSync, dan Scroll. Dengan asumsi bahwa ZK-EVM mereka telah berevolusi ke tipe-1, dan mereka memiliki reputasi baik dan teruji dalam pertempuran. Pembangun kemudian akan memilih dari sistem bukti yang tersedia, sementara siapa pun yang memverifikasi bloknya akan menjalankan perangkat lunak verifikasi yang sesuai. Sebaiknya, beberapa jenis bukti dibuat, dan beberapa verifikasi dilewati. Mengingat spesifikasi rantai L1 yang sama dan jika ada verifikator yang tidak setuju, hal ini menjadi masalah konsensus.
Sistem pembuktian akan mendapatkan pengaruh dengan meyakinkan pengguna untuk memercayainya, dan bukan dengan meyakinkan proses tata kelola protokol.
Menurut Vitalik, hal ini berarti ekosistem ZKP terbuka untuk pemasaran langsung. Penerapan L2 yang ada berpotensi bersaing untuk pasar bukti L1 jika diberi insentif.
Kelayakan Taiko untuk Multi-Bukti
Dalam protokol Taiko , pengusul harus menemukan pembukti untuk mengusulkan blok, dan pembukti yang ditugaskan akan menyetorkan jaminan TKO untuk menjamin bukti penyerahan. Taiko tidak mendikte bagaimana pengusul menemukan dan memberikan kompensasi kepada pemberi, sehingga mereka bahkan dapat bertemu langsung dan bertransaksi dengan uang tunai. Hasilnya, rantai pasokan kami beroperasi sebagai pasar bebas. Pengusul dapat memilih peribahasa mana pun yang mereka sukai.
Selain keunggulan ekonomi, beberapa fitur teknis lainnya menjadikan Taiko cocok untuk sistem multiklien:
- Taiko adalah ZK-EVM tipe-1, yang memiliki dua keunggulan:Untuk keragaman eksekusi, implementasi EVM yang ada (Geth, Besu, Reth,…) dapat langsung dibawa ke L2.
- Untuk menguji desain yang diabadikan L1, kita memerlukan ZK-EVM standar untuk verifikasi multiklien terbuka, karena pemverifikasi perlu memeriksa transisi yang sama untuk mencapai konsensus mengenai hasil validasinya. Dalam hal ini, ZK-EVM tipe-1 akan menjadi yang paling cocok karena jelas mengikuti Spesifikasi Ethereum. Untuk logika khusus rollup, Vitalik juga menyebutkan bagaimana ZK-EVM dapat dimodifikasi melalui dukungan prakompilasi, dan ini akan cukup memanfaatkan prakompilasi ini untuk mendukung desain BBR (Based Booster Rollup) Taiko .
- Taiko memposting data di Ethereum, tidak seperti beberapa L2 yang mengeksplorasi opsi ketersediaan data alternatif. Selama data diposting ke L1, Taiko dapat dengan mudah beradaptasi dengan proposal implementasi Vitalik, yang disajikan
ZKEVMClaimTransactionuntuk mencakup transisi keadaan, bukti, dan ketersediaan data.
Sumber: https://notes.ethereum.org/@vbuterin/enshrined_zk_evm.
- Taiko bekerja pada banyak sistem pembuktian. Testnet yang ada sudah mendukung ZK-EVM , SGX, dan Reth PSE . Infrastruktur dikonfigurasi untuk mengakomodasi beberapa klien eksekusi dan sistem pembuktian, yang akan dibahas di bagian terakhir. Berdasarkan infrastruktur ini, posisi kami di ZKP akan berkisar pada kompilasi modular.
Peta Jalan Modularitas & Keterbukaan
Multi-prover Taiko mengutamakan modularitas dan keterbukaan.
Modularitas
Mengingat banyak klien dalam konteks ZKP, kami memanfaatkan kompiler modern untuk mendapatkan rakitan tujuan umum seperti Risc-V atau WASM . Instruksi ini kemudian diterjemahkan ke dalam aritmetisasi untuk berbagai sistem pembuktian ( AIR atau PIL ), dan jejak eksekusi aritmatika pada akhirnya dikodekan dengan SNARK yang berbeda.
Execution Clients -> Assembly Languages -> Arithmetizations -> SNARKs
multi-clients | multi-proofsSingkatnya, jalur pipa ini adalah yang paling layak untuk sistem multi-bukti karena memanfaatkan yang terbaik dari kedua dunia. Selama kompilasi klien, kompiler modern memberi kita manfaat berikut:
- Pemutakhiran klien tidak sesuai dengan buktinya karena tidak perlu mengimplementasikan sirkuit untuk EIP atau hard fork terbaru ; kita hanya perlu selalu memperbarui kode sumbernya.
- Kami mendapatkan pengoptimalan kode secara gratis dari rantai alat seperti LLVM .
- Kompilasi silang menghasilkan lebih banyak keragaman; Berdasarkan contoh di atas, kita memiliki kompilasi Geth atau Reth ke instruksi RICS-V atau WASM, yang sudah memiliki empat set bukti.
Kompilasi SNARKs adalah penekanan kami untuk bergerak maju. Perhatikan bahwa metode aritmetisasi seperti pengkodean PLONK dan R1CS dengan backend seperti Halo2, eSTARK , atau Supernova tidak membatasi kita pada satu protokol ZK, sedangkan * monolitik* ZK-VM/EVM s berkomitmen pada ZKP tertentu untuk implementasi backend. Karena semakin banyak proyek yang mengadopsi komponen satu sama lain untuk kinerja yang lebih baik, tumpukan teknologi monolitik mungkin menjadi termodulasi. Bidang penelitian ZKP bergerak sangat cepat sehingga fleksibilitas lebih penting daripada menerapkan hasil terbaru secara langsung. Agar tetap fleksibel, kami berkolaborasi dengan proyek seperti Powdr Labs dan Risc Zero dalam jalur kompilasi silang mereka, mencapai modularitas sebanyak mungkin. Bagi pembaca yang paham teknologi, berikut manfaat spesifiknya:
- Kita dapat menerapkan pengoptimalan pada kompiler untuk menargetkan backend yang berbeda, seperti memilih gerbang tingkat tinggi atau menggunakan lebih banyak argumen pencarian .
- Sirkuit yang dipercepat seperti fungsi hash keccak dan Poseidon dapat diimplementasikan sebagai perpustakaan.
- Kami mungkin secara bertahap menambahkan fitur ZK seperti LogUp ke bahasa tersebut dan mengaktifkan dukungan backend yang sesuai.
- Mengintegrasikan kerangka kerja ZK baru untuk backend menjadi lebih cepat. Dalam beberapa proyek ZK yang berorientasi pada penelitian, hanya bukti konsep yang dikembangkan dalam kode, sehingga sulit digunakan dalam produksi. Dengan meminta kompiler melakukan pekerjaan berat, kita dapat dengan mudah menerapkan kerangka kerja tahap awal.
- Sirkuit backend yang ada, seperti komponen PSE ZK-EVM yang ditulis dalam Halo2 , masih dapat digunakan kembali melalui pemanggilan langsung.
Dalam upaya kolaboratif, Taiko telah mengintegrasikan zeth dan ZK-VM Risc Zero sambil mengembangkan backend SGX tambahan untuknya. Insinyur Taiko juga akan mengintegrasikan Powdr ke dalam sistem multi-bukti kami, mengembangkan bahasa dan pustaka PIL, mengoptimalkan kompilasi, menambahkan lebih banyak backend, dan melakukan akselerasi tingkat rendah secara umum. Pada tingkat perangkat keras, ZK Acceleration Layer (ZAL) kami bertujuan untuk menstandardisasi kerja sama antara sistem bukti (Halo2, Arkworks, Risc Zero, Polygon, dll.) dan perpustakaan akselerator (CPU, GPU, FPGA, dll.).
Keterbukaan
Semakin banyak klien, sistem pembuktian, dan backend yang terintegrasi — semakin baik, jadi kami berupaya untuk menyatukan seluruh komunitas. Tim kami memiliki sejarah panjang dalam bekerja dengan pihak lain, misalnya, PSE pada ZK-EVM dan Risc Zero. Sekarang, dengan membangun tumpukan ZK yang lebih termodulasi, kita dapat secara efektif mengerjakan abstraksi API untuk generalisasi dan integrasi yang lebih baik. Taiko akan berfungsi sebagai pintu gerbang untuk sistem bukti pengiriman dalam produksi dan mengujinya secara on-chain. Kami dengan sepenuh hati mengundang semua proyek untuk bergabung dengan kami demi ZK yang lebih baik.
Tumpukan Taiko
Infrastruktur yang terukur dan fleksibel sangat penting bagi paradigma multi-bukti kami. Bahan baku pembuktian keabsahan ZK adalah bukti penelusuran dan penyimpanan negara klien, yang digunakan untuk mengkonstruksi saksi dan masukan masyarakat. Perhatikan bahwa kesaksian saksi bersifat spesifik, sedangkan masukan masyarakat bersifat protokoler. Penting untuk memiliki infrastruktur yang kuat untuk menangani pembuatan saksi. Oleh karena itu, kami menggunakan host yang ringan untuk mengambil jejak dari multiklien dan melacak umpan ke multi-prover. Pada akhirnya, desain mendukung tumpukan modular dan monolitik sementara kami mengekstrak input publik yang sama dari klien yang ditargetkan (saat ini Geth).
Nantinya, Geth sebagai node Taiko dapat digantikan oleh node lain jika format jejaknya kompatibel. Selain itu, klien ringan yang berjalan pada sistem bukti (saat ini Reth) juga dapat digantikan oleh implementasi apa pun yang dikompilasi ke bahasa rakitan yang diterima.
Poin Penting
- Kami percaya bahwa multi-bukti = multi-klien + multi-SNARK (dan TEE seperti SGX).
- Protokol Taiko sangat cocok untuk sistem multiklien karena memiliki rantai pasokan multi-bukti terbuka dengan eksekusi tipe-1, yang memposting ketersediaan data di L1.
- Taiko membayangkan arsitektur multi-bukti dengan modularitas dan keterbukaan. Kami bekerja dengan Powdr Labs untuk memanfaatkan kompilasi silang dengan klien dan ZKP, dan berkolaborasi dengan Risc Zero untuk mengimplementasikan eksekusi Taiko pada ZK-VM dan TEE mereka. Kami juga akan melanjutkan upaya kami dengan PSE untuk meningkatkan proyek ZK-EVM.
- Infrastruktur fleksibel Taiko mencakup tumpukan ZKP modular dan monolitik.
Bergabunglah dengan TAIKO💗
Jelajahi posisi terbuka di papan pekerjaan kami .
Ikuti TAIKO🥁
Dapatkan kabar terbaru dari Taiko:
- Situs web: https://taiko.xyz .
- Perselisihan: https://discord.gg/taikoxyz .
- GitHub: https://github.com/taikoxyz .
- Twitter: https://twitter.com/taikoxyz .
- Forum komunitas: https://community.taiko.xyz .
- Youtube: https://www.youtube.com/@taikoxyz .
Disclaimer: This account is not an official Taiko account and this post is a post translated by the community by taking it from the official TAIKO post (https://taiko.mirror.xyz/j_zUGgLDwb1FY18fzh7bJQz2Qt5xbUlqov4n-vm6IC0)
