Interpretasi sistem anti-gagal yang akan diluncurkan oleh OP Stack: Terinspirasi oleh Ethereum, sebuah langkah besar menuju desentralisasi teknologi

Penulis: protolambda, peneliti di OP Labs

Disusun oleh: Frank, Foresight News

Untuk menciptakan jaringan Layer 2 yang paling kuat dan aman yang dapat dioperasikan, Optimism Collective sedang mengupayakan desentralisasi melalui berbagai cara.

Sistem anti-gagal OP Stack yang akan datang akan menjadi langkah besar menuju desentralisasi teknologi. Sumber terbuka dan desain modular OP Stack menciptakan tahap desentralisasi sosial yang belum pernah terjadi sebelumnya di ekosistem L2.

Dalam artikel ini, kami mengeksplorasi prinsip desentralisasi sosial, bagaimana arsitektur L2 memungkinkan Lapisan 2 memperluas prinsip ini untuk mencakup keragaman pengesahan dan keragaman klien, dan menjelaskan bagaimana Optimism Collective memanfaatkan arsitektur ini untuk membangun sistem yang aman dari kegagalan.

“Desentralisasi Sosial” Terinspirasi oleh Ethereum

Protokol Ethereum mendapat manfaat dari desentralisasi sosial, khususnya dengan memberikan opsionalitas dalam solusi yang memungkinkan berbagai kontributor untuk berpartisipasi dalam membangun jaringan terdesentralisasi yang kuat.

Untuk perangkat lunak node, ini berarti keragaman klien: semakin banyak klien yang Anda miliki, semakin kecil dampak satu titik kegagalan pada jaringan validator.

Pengembang inti Layer1 menggambarkan model kontribusi ini sebagai “bazaar”, yang berisik dan tampak kacau, namun sangat efisien dan dinamis. Dengan mengadopsi pendekatan yang sangat terbuka terhadap pengembangan protokol, kontributor seluas-luasnya dapat berpartisipasi dan meningkatkan protokol.

Optimism Collective diposisikan secara unik untuk menerapkan dan mengulangi pendekatan Ethereum terhadap desentralisasi sosial: OP Stack mencapai desentralisasi sosial dengan menyediakan spesifikasi terbuka dan perangkat lunak sumber terbuka di bawah lisensi MIT, dan Optimism Collective dapat mencapai desentralisasi sosial dengan membuat rantai super yang mengulanginya.

Pemahaman lebih detail tentang arsitektur L2

Ethereum memiliki spesifikasi terbuka di L1, dan arsitektur klien modular yang memisahkan lapisan konsensus dan lapisan eksekusi.

OP-Stack mengimplementasikan arsitektur yang sama di L2:

Lapisan konsensus didukung oleh op-node dan Magi, dua klien yang mengikuti L1 dan mengekspor input eksekusi;

Lapisan eksekusi didukung oleh op-geth, op-erigon dan op-reth;

Namun, arsitektur L2 menambahkan lapisan baru ke tumpukan ini: lapisan pembuktian.

Ini adalah lapisan yang secara aman menjembatani keluaran L2 kembali ke L1. Sama seperti memiliki banyak klien adalah praktik terbaik untuk memastikan konsensus dan eksekusi pada L1 dan L2, untuk lapisan validasi L2, memiliki beberapa metode pengesahan dapat memastikan keamanan yang optimal.

Mirip dengan validator dengan klien berbeda yang mencapai konsensus, kuorum pengesahan on-chain dapat menunjukkan bahwa klaim negara bagian L2 telah diverifikasi dengan cara yang berbeda, sehingga sangat mengurangi kemungkinan kesalahan yang menyebabkan kegagalan total.

Saat ini ada tiga jenis bukti yang umum: pengesahan, bukti kesalahan (juga dikenal sebagai bukti penipuan), dan bukti validitas tanpa pengetahuan. Dua yang terakhir memiliki pola yang sama yaitu mengekspresikan transisi keadaan L2 dalam bentuk sinkron dan membuktikan eksekusinya dengan data L1 dan keadaan sebelumnya L2 sebagai input.

Pisahkan komponen sistem pembuktian untuk mencapai keragaman bukti

Tunjukkan bahwa sistem dapat didekomposisi lebih lanjut menjadi komponen-komponen independen:

• Sebuah “program” yang mendefinisikan transisi keadaan L2 sinkron;
• Sebuah “mesin virtual” (VM) untuk menjalankan dan memverifikasi program;
• Sebuah “oracle pra-gambar” yang mengambil data L1 dan pra-status L2 sebagai masukan;

Banyak dari bukti tanpa pengetahuan saat ini masih memasangkan komponen-komponen ini dengan erat, menciptakan ZK-EVM yang berjalan pada satu data transaksi L1. Namun, tumpukan OP memisahkannya untuk mengisolasi kompleksitas dan memungkinkan keragaman klien, menjadikan keseluruhannya lebih kuat.

Pembuktian kesalahan interaktif menambahkan permainan bagi dua ke jejak mesin virtual untuk memverifikasi bukti on-chain, sementara bukti tanpa pengetahuan berbasis mesin virtual melakukan aritmatika dan melipatgandakan eksekusi serta memberikan bukti validitas. (Lihat bukti tanpa pengetahuan berbasis mesin virtual yang dirancang Risc0 dan O(1)-Labs sebagai respons terhadap RFP Optimisme ZK).

Program ini mendefinisikan transisi keadaan aktual sebagai “klien” dan akuisisi input (data L1 dan pra-keadaan L2) sebagai “server”. Program ini berjalan secara independen dari server/klien tanpa mesin virtual, seperti node blockchain biasa, dan berbagi banyak kode.

Misalnya, klien program op Go dibuat dengan mengimpor fork op-node dan EVM dari op-geth, sementara server mendapatkan datanya dari RPC Ethereum L1 dan L2.

Ikhtisar fungsional FPVM

Mesin virtual anti kesalahan (FPVM) adalah salah satu modul tumpukan anti kesalahan di OP Stack.

VM ini tidak mengimplementasikan apa pun yang spesifik untuk Ethereum atau L2 selain menyediakan antarmuka yang benar (terutama yang terkait dengan oracle pra-gambar). Klien Fault Proofing Program (FPP) yang berjalan dalam FPVM adalah untuk mengekspresikan bagian konversi status L2.

Dengan pemisahan ini, mesin virtual tetap minimalis: perubahan pada protokol Ethereum (seperti penambahan opcode EVM) tidak memengaruhi mesin virtual.

Sebaliknya, ketika protokol berubah, FPP dapat dengan mudah diperbarui untuk mengimpor komponen transisi status baru ke dalam perangkat lunak node. Mirip dengan memainkan versi baru game di konsol game yang sama, sistem pengesahan L1 dapat diperbarui untuk membuktikan program yang berbeda.

Mesin virtual bertanggung jawab untuk menjalankan instruksi tingkat rendah dan perlu mensimulasikan FPP. Persyaratan mesin virtual lebih rendah: program dijalankan secara sinkron dan semua input dimuat melalui oracle pra-gambar yang sama, tetapi semua ini masih harus dibuktikan pada rantai L1 EVM.

Untuk melakukan hal ini, hanya satu instruksi yang dapat dibuktikan dalam satu waktu. Permainan bagi dua akan mengurangi tugas membuktikan jejak eksekusi yang lengkap menjadi hanya satu instruksi.

Bukti instruksi mungkin terlihat berbeda untuk setiap FPVM, tetapi biasanya terlihat mirip dengan Cannon, yang membuktikan instruksinya sebagai berikut:

• Untuk menjalankan instruksi ini, mesin virtual mensimulasikan sesuatu yang mirip dengan siklus instruksi konteks thread: instruksi dibaca dari memori, diinterpretasikan, dan beberapa perubahan mungkin terjadi pada file register dan memori;
• Untuk mendukung kebutuhan runtime program dasar seperti oracle pra-image dan alokasi memori, eksekusi juga mendukung subset panggilan sistem Linux. Panggilan sistem baca/tulis memungkinkan interaksi dengan oracle pra-gambar: program menulis hash sebagai permintaan untuk mendapatkan pra-gambar, dan kemudian membacanya dalam beberapa bagian sekaligus;

Cannon, FPVM pertama, mengimplementasikan mesin virtual MIPS dengan cara ini. Untuk informasi selengkapnya tentang mesin virtual, lihat dokumentasi terkait dan spesifikasi meriam. Antarmuka antara program FPVM dan FP distandarisasi dan didokumentasikan dalam spesifikasi.

Dari FPVM ke ZKVM

Bukti kegagalan bukan satu-satunya jenis bukti transisi keadaan, bukti validitas ZK adalah pilihan yang menarik karena potensinya untuk menjembatani lintas rantai dengan cepat (karena bukti validitas ZK tidak memiliki permainan tantangan on-chain, tidak ada jendela perselisihan). Untuk mendukung tumpukan Ethereum tingkat lanjut dan menghosting implementasi klien yang berbeda, kita masih perlu memisahkan mesin virtual dan programnya.

Ini adalah pendekatan yang diambil oleh proyek ZK RFP untuk membuktikan bahwa mesin virtual minimal RISC-V (oleh Risc0) atau MIPS (oleh O(1) Labs) dapat meng-host program yang sama yang digunakan dalam bukti kegagalan.

Mendukung ZK-VM memang memerlukan beberapa penyesuaian kecil untuk memungkinkan oracle pra-gambar memuat data secara non-interaktif, tetapi dengan menggeneralisasi mesin virtual, ZK terbukti lebih tahan terhadap masa depan dalam menghadapi perubahan OP Stack.

Peluang untuk kontributor eksternal

OP Stack menyambut opsi mesin virtual dan program tambahan, serta sistem pembuktian independen tambahan, mulai dari pembuktian hingga pembuktian tanpa pengetahuan. Sama seperti keberagaman klien, keberagaman bukti adalah upaya kolektif.

Penambahan pada lapisan bukti OP Stack yang sedang berlangsung meliputi:

• RISC-V FPVM “Asterisc” dikembangkan oleh protolambda dan ditulis dalam bahasa Go;
• Program Rust FP berdasarkan Magi dan op-reth yang dibangun oleh kontributor Base dan OP Labs;
• Program Rust ZK berdasarkan zeth (cabang ZK-reth) yang dibangun oleh Risc0;

Seiring berkembangnya meriam, program operasi, permainan bagi-bagi, dan kreativitas tak terbatas dari komunitas sumber terbuka, akan ada banyak peluang tambahan untuk berkontribusi pada tumpukan melalui implementasi pengujian dan partisipasi dalam program bug bounty.