*Teruskan Judul Asli：Menjelajahi Jembatan Ethereum Canonical Eclipse dan Sistem Pembuktian

Gambaran Umum Jembatan Kanonik Kami

Gerhana terdiri dari tiga lapisan:

1. Eksekusi: Sebuah cabang dari klien Solana Labs(v1.17) untuk eksekusi transaksi SVM
2. Penyelesaian: Jembatan kanonik kami yang mendefinisikan aturan fork-choice Eclipse ada di Ethereum, di mana bukti-bukti penipuan juga akan dikirimkan
3. Ketersediaan Data: Eclipse menerbitkan data yang diperlukan untuk menghasilkan bukti-bukti penipuan sebagai gumpalan data di Celestia

Diagram di bawah ini mengilustrasikan bagaimana modul-modul ini berinteraksi:

Sisa artikel ini akan berfokus pada jembatan Ethereum Eclipse, seperti yang ditunjukkan pada diagram. Blobstream akan menyampaikan pengesahan yang ditandatangani oleh validator Celestia yang ditetapkan untuk menyatakan kepada Ethereum bahwa data untuk sekumpulan slot Eclipse telah diterbitkan dengan benar. Hal ini memungkinkan jembatan Eclipse untuk memverifikasi data yang disediakan untuk bukti penipuan terhadap akar data yang ditandatangani dari Celestia. Pada bagian selanjutnya, kami akan menguraikan proses yang digunakan:

1. dana disetorkan melalui jembatan kami,
2. gumpalan data dari kumpulan blok Eclipse diposting di Celestia,
3. penarikan melalui jembatan ditangani, dan
4. bukti-bukti penipuan dibuat dalam skenario terburuk.

Menyetor melalui Eclipse's Native Ethereum Bridge

Alur ketika pengguna melakukan deposit ke Eclipse melalui jembatan Ethereum asli dirangkum sebagai berikut:

1. Seorang pengguna memanggil kontrak Deposit Bridge Eclipse di Ethereum
2. Dari dalam eksekutor SVM Eclipse [1], relayer [2] mengamati setoran pengguna dan alamat tujuan
3. Selanjutnya, relayer memanggil program jembatan SVM, yang bertanggung jawab untuk mentransfer setoran pengguna ke alamat tujuan yang berlaku
4. Relayer memverifikasi transaksi setoran melalui klien zk-light (akan diimplementasikan)
5. Terakhir, blok yang berisi transaksi transfer pasca deposit berikutnya diselesaikan dan diterbitkan melalui PluginSolana Geyser

Diagram di bawah ini menunjukkan interaksi antara Ethereum, Celestia, dan Eksekutor SVM selama alur setoran yang dijelaskan di atas:

Menerbitkan Slot Eclipse ke Celestia sebagai Gumpalan Data

Alur untuk menerbitkan sejumlah slot Eclipse ke Celestia sebagai gumpalan data dirangkum di bawah ini:

1. Eksekutor SVM menerbitkan setiap slot Eclipse ke antrean pesan melalui Geyser
2. Eksekutor SVM memposting kumpulan slot Eclipse ke Celestia sebagai gumpalan data
3. Set validator Celestia menghasilkan komitmen pada gumpalan data yang dikirimkan, yang dapat digunakan untuk membuktikan penyertaan transaksi pada rantai Eclipse terhadap akar data
4. Akar data yang terkandung dalam setiap header blok Celestia diteruskan ke kontrak jembatan Eclipse di Ethereum melalui Blobstream

Diagram di bawah ini dari Celestia menjelaskan bagaimana komitmen data dalam blok Celestia tertentu disimpan dalam header blok:

Menarik dan Mengirimkan Bukti Penipuan ke Jembatan Ethereum Eclipse

Sama halnya dengan L2 lain yang menggunakan bukti kecurangan (Arbitrum, Fuel, dan banyak lainnya), penarikan dari Eclipse membutuhkan periode tantangan di mana verifikator dapat mengirimkan bukti kecurangan jika terjadi transisi state yang tidak valid:

1. Dengan irama yang teratur, eksekutor SVM memposting komitmen untuk sebuah epoch (jumlah batch yang telah ditentukan) dari slot Eclipse ke Ethereum, bersama dengan jaminan
2. Kontrak jembatan Eclipse melakukan beberapa pemeriksaan dasar untuk memastikan bahwa data yang diposting terbentuk dengan baik (dijelaskan di bagian Desain Bukti Penipuan)
3. Jika batch yang dikirimkan lolos dari pemeriksaan dasar ini, ada jendela yang telah ditentukan di mana verifikator dapat memposting bukti kecurangan jika komitmen batch mengimplikasikan transisi state yang tidak valid
4. Jika verifikator memposting bukti penipuan yang berhasil, mereka memenangkan jaminan eksekutor, batch yang diposting ditolak, dan status kanonik Eclipse L2 dikembalikan ke komitmen batch terakhir yang valid. Di sini, tata kelola Eclipse akan memiliki kemampuan untuk memilih pelaksana baru
5. Jika periode tantangan berlalu tanpa bukti penipuan yang berhasil, eksekutor akan mendapatkan agunannya bersama dengan hadiah
6. Akibatnya, kontrak jembatan Eclipse sekarang akan menyelesaikan setiap transaksi penarikan yang termasuk dalam kelompok yang telah difinalisasi

Desain Anti Penipuan

Pada bagian terakhir ini, kami akan merinci desain sistem anti-penipuan Eclipse, yang terinspirasi oleh Anatoly Yakovenko dan John Adler. Umumnya, untuk setiap bukti kecurangan, seorang verifikator harus melakukannya:

1. Mengidentifikasi transaksi yang mengandung transisi state yang tidak valid
2. Berikan input ke transaksi tersebut dengan transisi state yang tidak valid
3. Tunjukkan bahwa mengeksekusi ulang transaksi tersebut dengan input yang diberikan akan menghasilkan output yang tidak sama dengan apa yang dilakukan secara on-chain

Dalam kasus Eclipse, (1) Celestia merklisasi gumpalan kumpulan blok yang dikirim oleh eksekutor SVM Eclipse, yang memungkinkan bukti penyertaan transaksi melalui saksi Merkle. Untuk (2), tidak seperti L2 berbasis EVM, yang memposting akar Merkle ke pohon state global, untuk alasan kinerja, Eclipse tidak memperbarui pohon state global berdasarkan transaksi per transaksi, tetapi kami akan menjelaskan bagaimana kami memastikan kebenaran input secara lebih rinci di bawah ini. Terakhir, dalam kasus (3), verifier Eclipse menghasilkan zk-proof dari output untuk transaksi yang diberikan, tidak seperti pendekatan permainan verifikasi interaktif yang umum digunakan pada L2 berbasis EVM.

Semua transaksi Eclipse dapat direpresentasikan sebagai mengambil daftar akun input, mengeksekusi transaksi, dan menghasilkan daftar akun output yang dihasilkan:

Pengamatan penting untuk desain bukti penipuan kami adalah bahwa untuk eksekusi transaksi, selalu ada kasus bahwa setiap S_InputAccount haruslah S_OutputAccount dari beberapa transaksi sebelumnya. Hal ini memungkinkan kita untuk mereferensikan transaksi terakhir dalam rantai yang menghasilkan akun input tertentu alih-alih memberikan saksi Merkle ke pohon negara global. Sebagai hasil dari desain kami, kami memperkenalkan jenis tuduhan penipuan tambahan, seperti referensi ke transaksi sebelumnya yang tidak valid atau akun input yang telah "dibelanjakan" oleh beberapa transaksi selanjutnya. Kami akan menjelaskan proses ini secara lebih rinci di bawah ini:

Input Transaksi yang Dikirim ke Celestia

1. Data transaksi (diposting oleh sequencer)
2. Data transaksi (diposting oleh eksekutor SVM) yang berisi hal-hal berikut:
   1. Jumlah transaksi [3]
   2. Lokasi ruang nama Celestia dari data transaksi
   3. Hash akun [4] untuk setiap input, dengan jumlah transaksi yang dihasilkan di masing-masing
   4. Daftar sysvar yang digunakan dan nilai masing-masing, dengan jumlah transaksi yang dihasilkan dari masing-masing sysvar (jika ada) [5]
   5. Output transaksi, jika transaksi berhasil; jika tidak, indikator bahwa transaksi gagal (baik karena gagal diurai atau karena tidak dapat dieksekusi)

Komitmen Batch Diposting ke Jembatan Ethereum

Selain itu, kumpulan data transaksi yang diposting ke Celestia memiliki komitmen yang disampaikan ke kontrak Ethereum. Komitmen-komitmen tersebut terdiri dari:

1. Lokasi ruang nama Celestia dari data transaksi dari transaksi terakhir yang termasuk dalam batch
2. Lokasi ruang nama Celestia dari data eksekusi [6] dari semua transaksi yang disertakan
3. Daftar deposit, penarikan, dan penggantian, yang masing-masing dilengkapi dengan jumlah transaksi dari transaksi Eclipse terkait

Kriteria untuk Batch yang Tidak Valid

Seperti yang dijelaskan di atas, ada beberapa cara yang dapat menyebabkan suatu batch menjadi tidak benar:

1. Salah satu lokasi ruang nama Celestia yang ditautkan salah atau tidak mengarah ke data dengan tipe yang diperlukan
2. Ada transaksi di Celestia yang tidak memiliki data eksekusi terkait, yang dapat disebabkan oleh dua alasan:
   1. Transaksi yang seharusnya merupakan transaksi terbaru dalam batch, tidak memiliki data eksekusi yang terkait.
      1. Dalam kasus seperti itu, verifikator akan memverifikasi bahwa ini adalah kasusnya dan kontrak jembatan Ethereum memeriksa bahwa entri terbaru dalam daftar data eksekusi tidak sesuai dengan data transaksi yang benar
   2. Data eksekusi dari transaksi yang berbeda hilang
      1. Verifikator memposting lokasi ruang nama Celestia dari data transaksi dari transaksi yang menyinggung dan transaksi sebelum dan sesudahnya dalam urutan yang berhasil dieksekusi. Setelah itu, kontrak jembatan akan memeriksa bahwa transaksi ini dilewati
3. Terdapat transaksi yang data eksekusinya salah, yang dapat disebabkan oleh beberapa hal berikut:
   1. Hitungan transaksi yang terkait dengan hash akun atau sysvar tidak menghasilkan output yang diklaim.
      1. Dalam hal ini, verifier memposting lokasi namespace Celestia dari data eksekusi untuk transaksi yang diberikan dengan hitungan yang sesuai, dan kontrak jembatan memeriksa bahwa nilai yang diberikan salah.
   2. Hitungan transaksi yang terkait dengan hash atau sysvar akun sudah kedaluwarsa
      1. Verifikator memposting lokasi ruang nama Celestia dari data eksekusi untuk transaksi yang lebih baru, memodifikasi nilai yang dipermasalahkan, dan kontrak jembatan memeriksa bahwa ini memang lebih baru.
   3. Output transaksi salah, atau transaksi menggunakan input yang tidak terdaftar:
      1. Dalam kasus ini, diperlukan zk-proof dari eksekusi transaksi yang benar atau zk-proof bahwa transaksi tersebut menggunakan input yang tidak terdaftar. Hal ini dapat diperoleh dengan dua cara:
         1. Seorang verifikator memposting bukti, atau
         2. Verifikator memposting indeks transaksi yang diklaim sebagai penipuan, dan kontrak jembatan Eclipse menggunakan ini untuk meminta bukti zk dari RISC Zero's Bonsai
   4. Ada setoran dari Ethereum lebih dari N batch yang lalu, tetapi tidak ada setoran yang sesuai dalam daftar transaksi (termasuk dalam komitmen batch yang diposting ke kontrak jembatan) untuk N batch sebelumnya. Atau, ada setoran dalam daftar transaksi tanpa transaksi setoran Ethereum yang terkait, atau transaksi tersebut ada tetapi telah dimasukkan dalam batch Eclipse lainnya
      1. Kontrak jembatan dalam semua kasus ini dapat menentukan bahwa hal ini telah terjadi dan menganggap kumpulan tersebut tidak sah
   5. Ada deposit atau penarikan yang dilakukan tanpa entri yang sesuai dalam daftar transaksi
      1. Dalam kasus seperti itu, verifikator memposting lokasi ruang nama Celestia dari data eksekusi yang diberikan, dan kontrak jembatan memeriksa fakta ini untuk menilai transaksi sebagai tidak valid
   6. Terdapat deposit atau penarikan dalam daftar transaksi yang transaksi Eclipse terkait tidak melakukan tindakan yang diharapkan atau jumlah transaksinya tidak berada dalam kisaran jumlah transaksi yang diharapkan. Dalam kasus seperti itu, salah satu dari yang berikut ini akan terjadi:
      1. Jembatan akan secara otomatis menentukan bahwa ini adalah masalahnya dan menolak batch yang sesuai
      2. Verifikator memperhatikan transisi status yang tidak valid dan memposting bukti transaksi yang melanggar, yang kemudian diverifikasi oleh kontrak jembatan

Jika ada batch komitmen yang ditemukan tidak benar, kontrak jembatan Eclipse akan mengembalikan jembatan ke komitmen batch terakhir yang terbukti benar. Perhatikan bahwa transaksi tidak pernah dihapus dari rantai, bahkan dalam kasus penipuan, sehingga hanya komitmen yang perlu dihitung ulang.

Pikiran Perpisahan

Artikel ini bertujuan untuk memberikan panduan tingkat tinggi untuk jembatan kepercayaan Eclipse di Ethereum dan menjelaskan beberapa detail tentang desain bukti penipuan kami. Mengingat sifat modular dari L2 kami dan banyaknya teknologi yang kami miliki, kami akan terus merilis artikel dan dokumentasi tentang berbagai aspek Eclipse dalam beberapa minggu ke depan.

Untuk terlibat dengan Eclipse Testnet, silakan ikuti petunjuk kami di sini. Anda bisa menghubungi kami di Twitter atau Discord untuk pertanyaan spesifik tentang Testnet, bridge, atau pertanyaan teknis.

Catatan kaki

[1]: Node yang menghitung hasil dari transaksi SVM dan menerapkan keluaran akhirnya ke state baru Eclipse

[2]: Operator yang meneruskan peristiwa on-chain antara Ethereum dan Eclipse

[3]: Perhatikan, bahwa eksekutor, bukan sequencer, yang memposting ini. Jika disertakan dalam data yang diposkan oleh sequencer, ini akan menambah kerumitan, karena sequencer dapat melewatkan satu hitungan, sehingga tidak mungkin bagi eksekutor untuk melakukan tugasnya dengan benar. Hal ini dapat dikompensasi dalam desain bukti penipuan, tetapi akan menambah kerumitan. Keuntungan kedua dengan hanya memiliki eksekutor yang memposting penghitungan adalah memudahkan untuk mengizinkan penggantian transaksi untuk diposting ke Celestia, jika diinginkan.

[4]: Akun SVM dapat diwakili dengan hash yang unik. Satu-satunya cara hash ini dimodifikasi adalah melalui transaksi.

[5]: Untuk melakukan hal ini tanpa melakukan hashing yang berlebihan, kita akan menjalankan trace pada setiap program yang dieksekusi untuk melihat bagian mana dari setiap sysvar yang digunakan yang benar-benar diakses. Hal ini dimungkinkan, tetapi akan membutuhkan modifikasi pada penerjemah BPF Solana.

[6]: Ini termasuk data untuk percobaan transaksi yang gagal dieksekusi.

Penafian: Penafian

1. Artikel ini dicetak ulang dari [[mirror]], Semua hak cipta adalah milik penulis asli[Eclipse]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.