Struktur Komponen Arbitrum Ditafsirkan oleh Mantan Duta Teknis Arbitrum (Bagian 1)

Karena kurangnya interpretasi profesional terhadap artikel atau materi terkait protokol Layer2, khususnya untuk Arbitrum dan OP Rollup, di komunitas Tiongkok, artikel ini bertujuan untuk mengisi kesenjangan tersebut dengan menjelaskan mekanisme operasional Arbitrum. Karena kerumitan Arbitrum itu sendiri, teks lengkapnya, bahkan setelah disederhanakan sebanyak mungkin, masih melebihi 10.000 kata. Oleh karena itu, dibagi menjadi dua bagian, dan disarankan untuk disimpan dan dibagikan sebagai bahan referensi.”

Ikhtisar Rollup Sequencer

Prinsip penskalaan Rollup dapat diringkas dalam dua poin:

Optimasi Biaya: Mentransfer sebagian besar tugas komputasi dan penyimpanan ke Lapisan 2, yang dioperasikan di bawah L1. L2 sebagian besar berjalan pada satu server, disebut sebagai sequencer/operator, membentuk rantai terpisah.

Sequencer tampak hampir seperti server terpusat dalam hal persepsi, meninggalkan desentralisasi dalam 'trinitas blockchain yang mustahil' untuk mendapatkan keuntungan dalam TPS dan biaya. Pengguna dapat menggunakan L2 untuk menangani instruksi transaksi dibandingkan Ethereum, dengan biaya yang jauh lebih rendah dibandingkan transaksi di Ethereum.

(Sumber: Rantai BNB)

Jaminan Keamanan: Konten transaksi dan status pasca-transaksi di L2 disinkronkan ke Ethereum L1, dan validitasnya diverifikasi melalui kontrak transisi status. Pada saat yang sama, Ethereum mempertahankan sejarah L2, sehingga bahkan jika sequencer crash secara permanen, orang lain dapat merekonstruksi seluruh keadaan L2 melalui catatan Ethereum.

Pada dasarnya, keamanan Rollup bergantung pada Ethereum. Jika sequencer tidak mengetahui kunci pribadi suatu akun, maka sequencer tidak dapat memulai transaksi atas nama akun tersebut atau memanipulasi saldo aset akun (meskipun dicoba, hal ini akan terdeteksi dengan cepat).

Meskipun sequencer, sebagai hub pusat, memiliki aspek terpusat, dalam solusi Rollup yang matang, sequencer terpusat hanya dapat terlibat dalam aktivitas berbahaya ringan, seperti sensor transaksi atau kerusakan berbahaya. Dalam skenario Rollup yang ideal, terdapat langkah-langkah yang sesuai untuk membatasi tindakan tersebut, seperti penarikan wajib atau pengurutan bukti untuk mekanisme anti-sensor.

(Protokol Loopring menetapkan fungsi penarikan paksa dalam kode sumber kontrak di L1 untuk dihubungi pengguna)

Mekanisme verifikasi negara untuk mencegah tindakan jahat oleh sequencer Rollup dibagi menjadi dua kategori: Bukti Penipuan dan Bukti Validitas. Solusi Rollup yang menggunakan Bukti Penipuan disebut sebagai OP Rollup (Optimistic Rollup, OPR), sedangkan solusi yang menggunakan Bukti Validitas sering disebut ZK Rollup (Zero-knowledge Proof Rollup, ZKR) daripada Validity Rollup karena bagasi historis.

Arbitrum One adalah OPR tipikal, diterapkan pada L1 dengan kontrak yang tidak secara aktif memvalidasi data yang dikirimkan, dengan asumsi optimis bahwa data tersebut benar. Jika ada kesalahan pada data yang dikirimkan, node validator L2 akan secara aktif memulai tantangan.

Oleh karena itu, OPR menyiratkan asumsi kepercayaan: pada waktu tertentu, setidaknya ada satu node validator L2 yang jujur. Di sisi lain, kontrak ZKR secara aktif dan murah memvalidasi data yang dikirimkan oleh sequencer melalui perhitungan kriptografi.

(Metode operasi Rollup Optimis)

(Metode operasi ZK Rollup)

Artikel ini memberikan pengenalan mendalam tentang proyek terkemuka di Optimistic Rollup—Arbitrum One, yang mencakup semua aspek keseluruhan sistem. Setelah membacanya dengan cermat, Anda akan memiliki pemahaman mendalam tentang Arbitrum dan Optimistic Rollup/OPR.

Komponen Inti dan Alur Kerja Arbitrum

Kontrak Inti:

Kontrak paling penting di Arbitrum termasuk SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, dll. Hal ini akan dirinci pada bagian berikut.

Pengurut:

Sequencer menerima transaksi pengguna, mengurutkannya, menghitung hasil transaksi, dan dengan cepat (biasanya <1 detik) mengembalikan tanda terima kepada pengguna. Pengguna sering kali melihat transaksi mereka di L2 dalam beberapa detik, memberikan pengalaman yang mirip dengan platform Web2.

Secara bersamaan, sequencer segera menyiarkan Blok L2 terbaru yang dihasilkan di bawah Ethereum off-chain. Setiap node Layer2 dapat menerima Blok L2 ini secara asinkron. Namun, Blok L2 ini belum memiliki finalitas pada saat ini dan dapat dibatalkan oleh sequencer.

Setiap beberapa menit, sequencer mengompresi data transaksi L2 yang diurutkan, menggabungkannya ke dalam batch, dan mengirimkannya ke kontrak SequencerInbox pada Layer1 untuk memastikan ketersediaan data dan pengoperasian protokol Rollup. Secara umum, data L2 yang dikirimkan ke Layer1 tidak dapat dibatalkan dan dapat memiliki determinisme akhir.

Dari proses di atas kita dapat menyimpulkan: Layer2 memiliki jaringan node sendiri, namun jumlah node ini jarang, dan umumnya tidak ada protokol konsensus yang biasa digunakan oleh rantai publik, sehingga memberikan keamanan yang sangat buruk. Ia harus bergantung pada Ethereum untuk memastikan keandalan rilis data dan efektivitas transisi negara. seks.

Protokol Penggabungan Arbitrum:

Ini adalah serangkaian kontrak yang menentukan struktur RBlock blok rantai Rollup, metode kelanjutan rantai, pelepasan RBlock, dan proses mode tantangan. Perhatikan bahwa rantai Rollup yang disebutkan di sini bukanlah buku besar Lapisan 2 yang dipahami semua orang, tetapi “struktur data seperti rantai” abstrak yang dibuat secara independen oleh Arbitrum One untuk menerapkan mekanisme bukti penipuan.

Satu RBlock bisa berisi hasil beberapa blok L2, dan datanya juga sangat berbeda. Entitas datanya RBlock disimpan dalam serangkaian kontrak di RollupCore. Jika ada masalah dengan RBlock, Validator akan menantang pengirim RBlock tersebut.

Validator:

Node validator Arbitrum sebenarnya adalah subset khusus dari node penuh Layer 2, dan saat ini memiliki akses ke daftar putih.

Validator membuat RBlock baru (blok Rollup, juga disebut pernyataan) berdasarkan kumpulan transaksi yang dikirimkan oleh sequencer ke kontrak SequencerInbox, serta memantau status rantai Rollup saat ini dan menantang data yang salah yang dikirimkan oleh sequencer.

Validator Aktif perlu mempertaruhkan aset pada rantai ETH terlebih dahulu. Terkadang kami juga menyebutnya Staker. Meskipun node Lapisan 2 yang tidak dipertaruhkan juga dapat memantau dinamika operasi Rollup dan mengirimkan alarm abnormal kepada pengguna, mereka tidak dapat secara langsung melakukan intervensi terhadap data kesalahan yang dikirimkan oleh sequencer pada rantai ETH.

Tantangan:

Langkah-langkah dasar dapat diringkas sebagai beberapa putaran segmentasi interaktif dan pembuktian satu langkah. Dalam proses segmentasi, pihak-pihak yang menantang terlebih dahulu melakukan beberapa putaran segmentasi pada data transaksi yang bermasalah hingga mereka menguraikan instruksi kode operasi yang bermasalah dan melakukan verifikasi. Paradigma “beberapa putaran segmentasi-satu langkah bukti” dianggap oleh pengembang Arbitrum sebagai implementasi bukti penipuan yang paling menghemat bahan bakar. Semua tautan berada di bawah kendali kontrak, dan tidak ada pihak yang dapat menipu.

Periode tantangan:

Karena sifat optimis dari OP Rollup, setelah setiap RBlock dikirimkan ke rantai, kontrak tidak diperiksa secara aktif, sehingga menyisakan periode jendela bagi pemverifikasi untuk memalsukan. Periode jendela ini merupakan periode tantangan yang memakan waktu 1 minggu di jaringan utama Arbitrum One. Setelah periode tantangan berakhir, RBlock akhirnya akan dikonfirmasi. Hanya pesan terkait yang diteruskan dari L2 ke L1 dalam blok (seperti operasi penarikan yang dilakukan melalui jembatan resmi) yang dapat dilepaskan.

ArbOS, Geth, WAVM：

Mesin virtual yang digunakan oleh Arbitrum disebut AVM, yang mencakup Geth dan ArbOS. Geth adalah perangkat lunak klien yang paling umum digunakan di Ethereum, dan Arbitrum telah melakukan sedikit modifikasi padanya. ArbOS bertanggung jawab atas semua fungsi khusus terkait L2, seperti manajemen sumber daya jaringan, menghasilkan blok L2, bekerja dengan EVM, dll. Kami menganggap kombinasi keduanya sebagai Native AVM, yaitu mesin virtual yang digunakan oleh Arbitrum. WAVM merupakan hasil kompilasi kode AVM ke dalam Wasm. Dalam proses tantangan Arbitrum, “pembuktian satu langkah” terakhir memverifikasi instruksi WAVM.

Di sini, kita dapat menggunakan gambar berikut untuk mewakili hubungan dan alur kerja antara komponen-komponen di atas:

Siklus hidup transaksi di L2

Alur pemrosesan transaksi di L2 adalah sebagai berikut:

1. Pengguna mengirimkan instruksi perdagangan ke sequencer.

2. Sequencer terlebih dahulu memverifikasi transaksi yang akan diproses menjadi tanda tangan digital dan data lainnya, menghilangkan transaksi yang tidak valid, dan melakukan pengurutan dan perhitungan.

3. Sequencer mengirimkan tanda terima transaksi kepada pengguna (biasanya sangat cepat), yang merupakan “pemrosesan awal” yang dilakukan oleh penyortir di bawah rantai ETH. Ini berada dalam status Soft Finality dan tidak dapat diandalkan. Namun bagi pengguna (sebagian besar pengguna) yang mempercayai sequencer, mereka bisa optimis bahwa transaksi telah selesai dan tidak akan dibatalkan.

4. Sequencer sangat mengompresi data transaksi asli yang telah diproses sebelumnya dan merangkumnya menjadi Batch.

5. Sesekali (dipengaruhi oleh faktor-faktor seperti volume data dan kemacetan ETH), sequencer akan mempublikasikan batch transaksi ke kontrak Sequencer Inbox di L1. Pada titik ini, dapat dianggap bahwa transaksi tersebut memiliki Hard Finality.

Kontrak Kotak Masuk Sequencer

Kontrak akan menerima kumpulan transaksi yang dikirimkan oleh sequencer untuk memastikan ketersediaan data. Jika kita melihatnya lebih dalam, data batch di Sequencer Inbox secara lengkap mencatat informasi input transaksi Layer2. Sekalipun sequencer tidak aktif secara permanen, siapa pun dapat memulihkan status Layer 2 saat ini berdasarkan catatan batch dan mengganti sequencer yang rusak/berjalan.

Untuk memahaminya secara fisik, L2 yang kita lihat hanyalah proyeksi batch di SequencerInbox, dan sumber cahayanya adalah STF. Karena STF sumber cahaya tidak mudah berubah, bentuk bayangan hanya ditentukan oleh kumpulan yang bertindak sebagai objek.

Kontrak Sequencer Inbox disebut kotak cepat. Sequencer secara khusus mengirimkan transaksi yang telah diproses sebelumnya, dan hanya sequencer yang dapat mengirimkan data ke sana. Kotak cepat yang bersangkutan adalah kotak lambat Delayer Inbox, dan fungsinya akan dijelaskan pada proses selanjutnya.

Validator akan selalu memantau kontrak Sequencer Inbox. Setiap kali sequencer merilis batch ke dalam kontrak, acara on-chain akan diproduksi. Setelah Validator mendeteksi terjadinya peristiwa ini, Validator akan mengunduh data batch. Setelah eksekusi lokal, RBlock akan diterbitkan ke kontrak protokol Rollup di rantai ETH.

Kontrak jembatan Arbitrum memiliki parameter yang disebut akumulator, yang mencatat batch L2 yang baru dikirimkan, serta jumlah dan informasi transaksi yang baru diterima di Kotak Masuk yang lambat.

（Sequencer terus mengirimkan batch ke Kotak Masuk Sequencer）

（Informasi spesifik dari Batch; bidang data sesuai dengan data Batch. Ukuran bagian data ini sangat besar, dan tangkapan layar tidak ditampilkan sepenuhnya.）

Kontrak SequencerInbox memiliki dua fungsi utama:

tambahkan Sequencer L2Batch Dari Asal()

Sequencer akan memanggil fungsi ini setiap kali mengirimkan data Batch ke kontrak Sequencer Inox.

memaksa Inklusi()

Fungsi ini dapat dipanggil oleh siapa saja dan digunakan untuk mengimplementasikan transaksi yang tahan sensor. Cara penerapan fungsi ini akan dijelaskan secara rinci nanti ketika kita berbicara tentang kontrak Kotak Masuk Tertunda.

Dua fungsi di atas akan memanggil 'bridge.enqueueSequencerMessage()' untuk memperbarui parameter akumulator dalam kontrak jembatan.

Penetapan harga bahan bakar

Jelasnya, transaksi L2 tidak bisa gratis, karena hal ini akan mengakibatkan serangan DoS. Selain itu, terdapat biaya operasional untuk penyortir L2 itu sendiri, dan akan ada overhead untuk pengiriman data pada L1. Saat pengguna memulai transaksi dalam jaringan Layer 2, struktur biaya bahan bakar adalah sebagai berikut:

Biaya penerbitan data yang dikeluarkan dengan menempati sumber daya Layer1

Biaya ini terutama berasal dari batch yang dikirimkan oleh sequencer (setiap batch memiliki banyak transaksi pengguna), dan biaya tersebut pada akhirnya dibagi rata di antara pemrakarsa transaksi. Algoritme penetapan harga biaya yang dihasilkan oleh rilis data bersifat dinamis, dan sequencer akan menentukan harga berdasarkan status untung dan rugi terkini, ukuran batch, dan harga gas Ethereum saat ini.

Biaya yang dikeluarkan oleh pengguna yang menempati sumber daya Lapisan 2

Batasan gas untuk TPS ditetapkan untuk memastikan pengoperasian sistem yang stabil (saat ini 7 juta di Arbitrum One). Harga panduan gas untuk L1 dan L2 dilacak dan disesuaikan oleh ArbOS, dan formulanya tidak dirinci di sini untuk saat ini.

Meskipun proses penghitungan harga gas secara spesifik relatif rumit, pengguna tidak perlu mengetahui detail ini dan dapat dengan jelas merasakan bahwa biaya transaksi Rollup jauh lebih murah daripada mainnet ETH.

Bukti penipuan yang optimis

Mengingat hal di atas, L2 sebenarnya hanyalah proyeksi dari batch input transaksi yang dikirimkan oleh sequencer di fast box, yaitu:

Input Transaksi -> STF -> Output Status. Inputnya sudah ditentukan dan STFnya tidak berubah, sehingga hasil outputnya juga ditentukan. Sistem bukti penipuan dan protokol Arbitrum Rollup adalah sistem yang menerbitkan akar status keluaran dalam bentuk RBlock (alias pernyataan) ke L1 dan melakukan pembuktian optimis terhadapnya.

Pada L1, terdapat data masukan yang diterbitkan oleh sequencer dan status keluaran yang diterbitkan oleh verifier. Mari kita pertimbangkan dengan hati-hati: Apakah perlu untuk mempublikasikan status Layer 2 ke rantai?

Karena masukan telah sepenuhnya menentukan keluaran, dan data masukan dapat dilihat oleh publik, apakah tampaknya berlebihan jika mengirimkan status hasil keluaran? Namun gagasan ini mengabaikan kebutuhan aktual penyelesaian keadaan antara dua sistem L1 dan L2, yaitu perilaku penarikan L2 ke L1 memerlukan pembuktian keadaan.

Saat membangun Rollup, salah satu ide intinya adalah menempatkan sebagian besar komputasi dan penyimpanan di L2 untuk menghindari tingginya biaya L1. Artinya L1 tidak mengetahui status L2, hanya membantu L2. Sequencer menerbitkan data input dari semua transaksi, tetapi tidak bertanggung jawab untuk menghitung status L2.

Perilaku penarikan pada dasarnya adalah untuk membuka kunci dana terkait dari kontrak L1, mentransfernya ke akun L1 pengguna atau menyelesaikan hal lain dengan mengikuti pesan lintas rantai yang diberikan oleh L2.

Saat ini, kontrak Layer1 akan menanyakan: Apa status Anda di Layer 2, dan bagaimana membuktikan bahwa Anda benar-benar pemilik aset yang Anda nyatakan akan dialihkan? Saat ini, pengguna harus memberikan Bukti Merkle yang sesuai, dll.

Oleh karena itu, jika kita membuat Rollup tanpa fungsi penarikan, secara teori dimungkinkan untuk tidak menyinkronkan status ke L1, dan tidak diperlukan sistem pembuktian status seperti bukti penipuan (meskipun hal ini dapat menyebabkan masalah lain). Namun dalam penerapan nyata, hal ini jelas tidak mungkin dilakukan.

Dalam apa yang disebut bukti optimis, kontrak tidak memeriksa apakah status keluaran yang diserahkan ke L1 sudah benar, tetapi secara optimis yakin bahwa semuanya akurat. Sistem pembuktian optimis mengasumsikan bahwa setidaknya ada satu Validator yang jujur setiap saat. Jika terjadi kesalahan keadaan, maka akan ditantang melalui bukti penipuan.

Keuntungan dari desain ini adalah tidak perlu memverifikasi secara aktif setiap RBlock yang dikeluarkan ke L1 untuk menghindari pemborosan gas. Faktanya, untuk OPR, tidak realistis untuk memverifikasi setiap pernyataan, karena setiap Rblock berisi satu atau lebih blok L2, dan setiap transaksi harus dieksekusi ulang di L1. Hal ini tidak berbeda dengan mengeksekusi transaksi L2 langsung di L1, yang membuat perluasan Layer 2 menjadi tidak ada artinya.

ZKR tidak mengalami masalah ini, karena ZK Proof ringkas. Ia hanya perlu memverifikasi Bukti yang sangat kecil, dan tidak perlu melakukan banyak transaksi yang terkait dengan Bukti tersebut. Oleh karena itu, ZKR tidak beroperasi secara optimis. Setiap kali status dilepas, akan ada kontrak Verifikator untuk verifikasi matematis.

Meskipun bukti penipuan tidak bisa sesingkat bukti tanpa pengetahuan, Arbitrum menggunakan proses interaktif berbasis giliran “multi-rounds of segmentation-one-step proof”. Pada akhirnya yang perlu dibuktikan hanyalah satu kode pengoperasian mesin virtual, dan biayanya relatif kecil.

Protokol rollup

Pertama mari kita lihat pintu masuk untuk memulai tantangan dan memulai pembuktian, yaitu cara kerja protokol Rollup.

Kontrak inti dari protokol Rollup adalah RollupProxy.sol, yang menggunakan struktur agen ganda yang langka sambil memastikan bahwa struktur datanya konsisten. Satu agen berhubungan dengan dua implementasi RollupUserLogic.sol dan RollupAdminLogic.sol, yang tidak dapat diurai dengan baik oleh alat seperti Scan.

Selain itu, kontrak ChallengeManager.sol bertanggung jawab untuk mengelola tantangan, dan kontrak seri OneStepProver digunakan untuk menentukan bukti penipuan.

(Sumber: situs resmi L2BEAT)

Ini menunjukkan rekaman serangkaian RBlocks (alias pernyataan), di RollupProxy, yang dikirimkan oleh Validator berbeda, yang merupakan kotak pada gambar di bawah ini: Hijau-dikonfirmasi, biru-belum dikonfirmasi, kuning-dipalsukan.

RBlock berisi keadaan akhir setelah eksekusi satu atau lebih blok L2 sejak RBlock terakhir. RBlock ini membentuk Rollup Chain formal (perhatikan bahwa buku besar L2 itu sendiri berbeda). Dalam keadaan optimis, Rollup Chain ini seharusnya tidak memiliki fork, karena fork berarti Validator telah mengirimkan Rollup Block yang bertentangan.

Untuk mengusulkan atau menyetujui suatu pernyataan, verifikator harus terlebih dahulu mempertaruhkan sejumlah ETH untuk pernyataan tersebut dan menjadi Staker. Dengan cara ini, ketika terjadi bukti tantangan/penipuan, jaminan pihak yang kalah akan terpotong. Hal ini merupakan landasan ekonomi untuk menjamin perilaku jujur verifikator.

Blok biru no.111 di pojok kanan bawah gambar nantinya akan terpotong karena blok induk no.104 (kuning) salah.

Selain itu, verifikator A mengusulkan Rollup Block No. 106, namun B tidak setuju dan menentangnya.

Setelah B memulai tantangan, kontrak ChallengeManager akan bertanggung jawab untuk memverifikasi segmentasi langkah-langkah tantangan:

1. Segmentasi merupakan suatu proses dimana kedua belah pihak saling berinteraksi secara bergiliran. Satu pihak mengelompokkan data historis yang terdapat dalam Rollup Block tertentu, dan pihak lain menunjukkan bagian mana dari fragmen data yang bermasalah, sebuah proses yang mirip dengan dikotomi (sebenarnya N/K) yang secara terus menerus dan bertahap mempersempit cakupannya.

2. Setelah itu, Anda dapat terus mencari transaksi dan hasil yang bermasalah, lalu membaginya lagi menjadi instruksi mesin yang disengketakan dalam transaksi tersebut.

3. Kontrak ChallengeManager hanya memeriksa apakah “fragmen data” yang dihasilkan setelah mengelompokkan data asli valid.

4. Ketika penantang dan pihak yang ditantang menemukan instruksi mesin yang akan ditantang, penantang memanggil fungsi 'oneStepProveExecution()' dan mengirimkan bukti penipuan satu langkah untuk membuktikan bahwa ada masalah dengan hasil eksekusi instruksi mesin ini.

Bukti satu langkah

Bukti satu langkah adalah inti dari keseluruhan bukti penipuan Arbitrum. Mari kita lihat apa yang secara spesifik dibuktikan oleh bukti satu langkah.

Ini memerlukan pemahaman WAVM terlebih dahulu. Mesin Virtual Wasm Arbitrum adalah mesin virtual yang dikompilasi oleh modul ArbOS dan modul inti Geth (klien Ethereum). Karena L2 sangat berbeda dari L1, inti Geth asli harus sedikit dimodifikasi dan bekerja dengan ArbOS.

Oleh karena itu, transisi status pada L2 sebenarnya merupakan hasil kerja sama ArbOS+Get Core.

Klien node Arbitrum (sequencer, verifier, full node, dll.) mengkompilasi program pemrosesan ArbOS+Get Core yang disebutkan di atas ke dalam kode mesin asli yang dapat langsung diproses oleh host node (untuk x86/ARM/PC/Mac/etc.).

Jika Anda mengubah bahasa target yang diperoleh setelah kompilasi ke Wasm, Anda akan mendapatkan WAVM yang digunakan oleh verifikator saat membuat bukti penipuan, dan kontrak untuk memverifikasi bukti satu langkah juga mensimulasikan fungsi mesin virtual WAVM.

Jadi mengapa perlu dikompilasi ke dalam bytecode Wasm saat membuat bukti penipuan? Alasan utamanya adalah, untuk memverifikasi kontrak bukti penipuan satu langkah, perlu menggunakan kontrak pintar Ethereum untuk mensimulasikan mesin virtual VM yang dapat menangani serangkaian set instruksi tertentu, dan WASM mudah untuk mengimplementasikan simulasi pada kontrak.

Namun, WASM berjalan sedikit lebih lambat dibandingkan kode mesin Asli, sehingga node/kontrak Arbitrum akan menggunakan WAVM hanya saat membuat dan memverifikasi bukti penipuan.

Setelah putaran segmentasi interaktif sebelumnya, pembuktian satu langkah akhirnya membuktikan instruksi satu langkah dalam set instruksi WAVM.

Seperti dapat dilihat pada kode di bawah ini, OneStepProofEntry pertama-tama menentukan kategori mana dari kode operasi dari instruksi yang akan dibuktikan, dan kemudian memanggil pembuktian yang sesuai seperti Mem, Math, dll., untuk meneruskan instruksi satu langkah ke dalam kontrak pembuktian.

Hasil akhir setelahHash akan dikembalikan ke ChallengeManager. Jika hash tidak konsisten dengan hash setelah operasi instruksi dicatat di Blok Rollup, maka tantangan berhasil. Jika konsisten berarti tidak ada masalah dengan hasil eksekusi instruksi ini yang tercatat di Rollup Block, dan tantangannya gagal.

Di bagian 2, kami akan menganalisis Arbitrum dan bahkan modul kontrak yang menangani fungsi perpesanan/penjembatan lintas rantai antara Layer2 dan Layer1, dan memperjelas lebih lanjut bagaimana Layer2 yang sebenarnya harus mencapai ketahanan sensor.

Penafian:

1. Artikel ini dicetak ulang dari [WeChat]. Semua hak cipta milik penulis asli [Luo Benben]. Jika ada keberatan terhadap cetak ulang ini, silakan menghubungi tim Gate Learn , dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini adalah sepenuhnya milik penulis dan bukan merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.