Artikel ini adalah interpretasi teknis Arbitrum One oleh Luo Benben, mantan duta teknis Arbitrum dan mantan salah satu pendiri perusahaan audit otomatisasi kontrak pintar Goplus Security.
Ditulis oleh: Luo Benben, mantan duta teknis Arbitrum dan kontributor geek web3
**Artikel ini adalah interpretasi teknis Arbitrum One oleh Luo Benben, mantan duta teknis Arbitrum dan mantan salah satu pendiri perusahaan audit otomatisasi kontrak pintar Goplus Security. **
Karena kurangnya interpretasi profesional Arbitrum dan bahkan OP Rollup dalam artikel atau materi terkait Layer 2 di kalangan Tionghoa, artikel ini mencoba mengisi kesenjangan di bidang ini dengan mempopulerkan mekanisme operasi Arbitrum. Karena struktur Arbitrum sendiri terlalu rumit, teks lengkapnya masih melebihi 10.000 kata meskipun telah disederhanakan semaksimal mungkin, sehingga terbagi menjadi dua bagian. Disarankan untuk dikumpulkan dan diteruskan sebagai referensi! **
Deskripsi singkat penyortir rollup
Prinsip perluasan Rollup dapat diringkas menjadi dua poin:
**Optimalisasi biaya: Mentransfer sebagian besar tugas komputasi dan penyimpanan ke rantai L1, yaitu L2. **L2 sebagian besar merupakan rantai yang berjalan pada satu server, yaitu sequencer/operator.
Penyortir terlihat dan terasa dekat dengan server terpusat. Dalam “tiga aspek blockchain yang mustahil”, “desentralisasi” ditinggalkan dengan imbalan TPS dan keunggulan biaya. Pengguna dapat membiarkan L2 memproses instruksi transaksi alih-alih Ethereum, dan biayanya jauh lebih rendah daripada berdagang di Ethereum.
(Sumber: Rantai BNB)
Jaminan Keamanan: **Konten transaksi dan status pasca-transaksi di L2 akan disinkronkan ke Ethereum L1, dan validitas transisi status akan diverifikasi melalui kontrak. **Pada saat yang sama, catatan sejarah L2 akan disimpan di Ethereum. Bahkan jika sequencer mati secara permanen, orang lain dapat memulihkan seluruh status L2 melalui catatan di Ethereum.
**Pada dasarnya, keamanan Rollup didasarkan pada Ethereum. **Jika sequencer tidak mengetahui kunci pribadi suatu akun, ia tidak dapat memulai transaksi atas nama akun tersebut, atau tidak dapat mengubah saldo aset akun tersebut (meskipun demikian, hal tersebut akan segera diketahui).
Meskipun penyortir dipusatkan sebagai hub sistem,** dalam solusi Rollup yang relatif matang, penyortir terpusat hanya dapat menerapkan perilaku jahat ringan seperti peninjauan transaksi, atau waktu henti yang berbahaya,** namun dalam solusi rollup yang ideal, terdapat cara-cara yang sesuai untuk penahanan (seperti mekanisme yang tahan sensor seperti penarikan paksa atau pemilahan bukti).
(Protokol Loopring menetapkan fungsi penarikan paksa dalam kode sumber kontrak di L1 untuk dihubungi pengguna)
Metode verifikasi status untuk mencegah sequencer Rollup melakukan kejahatan dibagi menjadi dua kategori: Bukti Penipuan dan Bukti Validitas. Skema Rollup yang menggunakan bukti penipuan disebut OP Rollup (Optimistic Rollup, OPR), sedangkan karena beberapa bagasi historis, skema Rollup yang menggunakan bukti validitas sering disebut ZK Rollup** (Zero-knowledge Proof Rollup, ZKR ) dan bukan Validity Rollup .
Arbitrum One merupakan tipikal OPR yang menyebarkan kontrak pada L1 dan tidak secara aktif memverifikasi data yang dikirimkan, optimis tidak ada masalah dengan data tersebut. Jika data yang dikirimkan salah, node verifikasi L2 akan secara aktif memulai tantangan.
Oleh karena itu, **OPR juga menyiratkan asumsi kepercayaan: setidaknya ada satu node pemverifikasi L2 yang jujur setiap saat. **Kontrak ZKR menggunakan perhitungan kriptografi untuk memverifikasi data yang dikirimkan oleh sequencer secara aktif namun hemat biaya.
(Metode operasi Rollup Optimis)
(Mode operasi ZK Rollup)
Artikel ini akan memberikan pengenalan mendalam tentang Arbitrum One, proyek terkemuka dalam rollup optimis, yang mencakup semua aspek dari keseluruhan sistem. Setelah membacanya dengan cermat, Anda akan memiliki pemahaman mendalam tentang Arbitrum dan rollup optimis/OPR.
Komponen inti dan alur kerja Arbitrum
Kontrak Inti:
Kontrak Arbitrum yang paling penting mencakup **SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, dll. **Detail akan diperkenalkan nanti.
Pengurut:
Menerima dan mengurutkan transaksi pengguna, menghitung hasil transaksi, dan mengembalikan kuitansi kepada pengguna dengan cepat (biasanya <1 detik). Pengguna sering kali dapat melihat transaksi mereka terdaftar di L2 dalam beberapa detik, dan pengalamannya sama seperti platform Web2.
Pada saat yang sama, sequencer juga akan menyiarkan Blok L2 terbaru langsung di bawah rantai Ethereum, dan setiap node Layer2 dapat menerimanya secara asinkron. Namun saat ini, Blok L2 tersebut belum final dan dapat dibatalkan oleh sequencer.
Setiap beberapa menit, sequencer akan mengompresi data transaksi L2 yang diurutkan, menggabungkannya ke dalam batch, dan mengirimkannya ke kontrak kotak masuk SequencerInbox pada Layer1 untuk memastikan ketersediaan data dan pengoperasian protokol Rollup. . Secara umum, data L2 yang dikirimkan ke Layer1 tidak dapat dibatalkan dan bersifat final.
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 keamanannya sangat buruk dan harus terjamin dengan mengandalkan Ethereum Keandalan rilis data dan efektivitas transisi negara. **
Protokol Rollup Arbitrum:
Serangkaian kontrak yang menentukan struktur blok RBlock dari 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 sebuah “struktur data seperti rantai” abstrak yang dibuat secara independen oleh Arbitrum One untuk menerapkan mekanisme bukti penipuan. **
Satu RBlock dapat 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 daftar putih.
Validator membuat RBlock baru (blok Rollup, juga disebut pernyataan) berdasarkan batch transaksi yang dikirimkan oleh sequencer ke kontrak SequencerInbox,** dan memantau status rantai Rollup saat ini, dan mengevaluasi transaksi yang dikirimkan oleh sequencer Tantangan dengan data yang salah. **
Validator yang aktif perlu menjaminkan aset pada rantai ETH terlebih dahulu, terkadang kami juga menyebutnya Staker. Meskipun node Layer 2 yang tidak berjanji juga dapat memantau dinamika Rollup yang sedang berjalan 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 “**Bukti satu langkah subdivisi multi-putaran” dianggap oleh pengembang Arbitrum sebagai penerapan bukti penipuan yang paling menghemat bahan bakar. **Semua aspek 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. **Jendela waktu ini adalah periode tantangan, yaitu 1 minggu di jaringan utama Arbitrum One. Setelah periode tantangan berakhir, RBlock akhirnya akan dikonfirmasi, dan pesan terkait yang diteruskan dari L2 ke L1 di blok ** (seperti operasi penarikan yang dilakukan melalui jembatan resmi) 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 pada perangkat lunak tersebut. **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 L2
Alur pemrosesan transaksi L2 adalah sebagai berikut:
1. Pengguna mengirimkan instruksi perdagangan ke sequencer.
2. Penyortir terlebih dahulu memverifikasi transaksi yang akan diproses menjadi tanda tangan digital dan data lainnya, menghilangkan transaksi yang tidak valid, serta melakukan penyortiran dan perhitungan.
3. Sequencer mengirimkan tanda terima transaksi kepada pengguna (biasanya sangat cepat), ** tetapi ini hanyalah “pemrosesan awal” yang dilakukan oleh sequencer di bawah rantai ETH. Ini berada dalam status Soft Finality dan sedang tidak dapat diandalkan. **. Namun bagi pengguna yang mempercayai sequencer (sebagian besar pengguna), mereka bisa optimis bahwa transaksi telah selesai dan tidak akan dibatalkan.
4. Penyortir 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 Pengurut
Kontrak akan menerima kumpulan transaksi yang dikirimkan oleh sequencer untuk memastikan ketersediaan data. Melihat lebih dalam, data batch di SequencerInbox secara lengkap mencatat informasi input transaksi Lapisan 2. **Bahkan jika sequencer tidak aktif secara permanen, siapa pun dapat memulihkan status Layer 2 saat ini berdasarkan catatan batch dan mengganti sequencer yang gagal/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 juga disebut fast box. Sequencer secara khusus mengirimkan transaksi yang telah diproses sebelumnya ke sana, dan hanya sequencer yang dapat mengirimkan data ke sana. **Kotak cepat yang bersangkutan adalah kotak lambat Delayer Inbox, fungsinya akan dijelaskan pada proses selanjutnya.
Validator akan selalu memantau kontrak SequencerInbox. **Setiap kali sequencer merilis Batch ke kontrak, peristiwa on-chain akan dilempar. Setelah Validator mendengarkan terjadinya peristiwa ini, ia akan mengunduh data batch dan mengeksekusinya secara lokal Terakhir, terbitkan RBlock ke kontrak protokol Rollup di rantai ETH.
Ada parameter yang disebut akumulator dalam kontrak jembatan Arbitrum, 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 SequencerInbox)
*
(Informasi spesifik batch, bidang data sesuai dengan data Batch, 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.
force Inclusion(), 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 akumulator parameter akumulator dalam kontrak jembatan.
Harga Bahan Bakar
Tentunya transaksi L2 tidak bisa gratis, karena akan menimbulkan serangan DoS, selain itu ada biaya operasional untuk penyortir L2 itu sendiri, dan akan ada overhead untuk pengiriman data di L1. Saat pengguna memulai transaksi dalam jaringan Lapisan 2, struktur biaya bahan bakar adalah sebagai berikut:
Biaya penerbitan data yang timbul karena menempati sumber daya Layer1 sebagian besar berasal dari batch yang dikirimkan oleh penyortir (setiap batch memiliki banyak transaksi pengguna), dan biaya tersebut pada akhirnya dibagi rata oleh pemrakarsa transaksi. Algoritme penetapan harga biaya yang dihasilkan oleh rilis data bersifat dinamis, dan penyortir akan menentukan harga berdasarkan status untung dan rugi terkini, ukuran batch, dan harga gas Ethereum saat ini.
Biaya yang dikeluarkan oleh pengguna karena menempati sumber daya Lapisan 2 menetapkan batas gas yang dapat diproses per detik untuk memastikan pengoperasian sistem yang stabil (saat ini Arbitrum One adalah 7 juta). Harga panduan gas L1 dan L2 dilacak dan disesuaikan oleh ArbOS, dan rumusnya tidak akan dijelaskan 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 batch input transaksi yang diserahkan oleh sorter di fast box, yaitu:
Input Transaksi -> STF -> Output Status. Input telah ditentukan dan STF tidak berubah, sehingga hasil output juga ditentukan.**Sistem anti penipuan dan protokol Arbitrum Rollup menerbitkan status output root ke L1 dalam bentuk RBlock (alias pernyataan) dan Ini adalah a sistem untuk bukti optimis. **
Pada L1, terdapat data masukan yang diterbitkan oleh sequencer dan status keluaran yang diterbitkan oleh verifier. Mari kita pertimbangkan baik-baik, apakah perlu mempublikasikan status Layer 2 ke rantai?
Karena masukan sudah sepenuhnya menentukan keluaran, dan data masukan dapat dilihat oleh publik, lalu mengirimkan status hasil keluaran tampaknya mubazir? Namun gagasan ini mengabaikan kebutuhan aktual penyelesaian keadaan antara dua sistem L1-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 memublikasikan data masukan seluruh transaksi, namun tidak bertanggung jawab menghitung keadaan L2.
**Perilaku penarikan pada dasarnya adalah mengikuti pesan lintas rantai yang diberikan oleh L2, membuka kunci dana terkait dari kontrak L1, mentransfernya ke akun L1 pengguna, atau menyelesaikan hal lainnya. **
Saat ini, kontrak Layer1 akan menanyakan: **Apa status Anda di Layer2, 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, dan secara optimis yakin bahwa semuanya akurat. **Sistem pembuktian optimis akan mengasumsikan bahwa setidaknya ada satu Validator yang jujur setiap saat. Jika terjadi keadaan yang salah, 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 perlu dieksekusi ulang di L1. Tidak ada bedanya dengan mengeksekusi transaksi L2 langsung di L1, yang kalah arti perluasan Layer 2.
ZKR tidak mempunyai masalah ini, karena ZK Proof sederhana dan hanya perlu memverifikasi Bukti yang sangat kecil. Tidak perlu melakukan banyak transaksi yang sesuai dengan Bukti tersebut. Oleh karena itu ZKR tidak beroperasi secara optimis, setiap status dilepas akan ada kontrak Verfier untuk verifikasi matematis.
**Meskipun bukti penipuan tidak bisa sesingkat bukti tanpa pengetahuan, Arbitrum menggunakan proses interaktif berbasis giliran “pembuktian multi-putaran, bukti satu langkah”, dan pada akhirnya yang perlu dibuktikan hanyalah satu Mesin virtual kode operasi, biayanya relatif kecil. **
Protokol Penggabungan
Pertama mari kita lihat cara kerja protokol Rollup, yang merupakan titik masuk untuk memulai tantangan dan memulai pembuktian.
**Kontrak inti protokol Rollup adalah RollupProxy.sol. **Dalam kondisi memastikan struktur data yang konsisten, struktur agen ganda yang jarang digunakan. Satu agen berhubungan dengan dua implementasi RollupUserLogic.sol dan RollupAdminLogic.sol. Dalam alat seperti Scan Ini belum dapat dianalisis dengan baik.
Ada juga kontrak **ChallengeManager.sol yang bertanggung jawab untuk mengelola tantangan, dan rangkaian kontrak OneStepProver untuk menentukan bukti penipuan. **
(Sumber foto: situs resmi L2BEAT)
Di RollupProxy, serangkaian RBlock (alias pernyataan) yang dikirimkan oleh Validator berbeda dicatat, yaitu 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 demikian apabila terjadi bukti tantang/penipuan maka jaminan pihak yang kalah akan hangus, hal ini menjadi dasar ekonomi untuk menjamin perilaku jujur verifikator.
Blok biru No. 111 di pojok kanan bawah gambar pada akhirnya akan dipalsukan karena blok induknya No. 104 salah (kuning).
**Selain itu, verifikator A mengusulkan Rollup Block No. 106, namun B tidak setuju dan menentangnya. **
Setelah B memulai tantangan, kontrak ChallengeManager bertanggung jawab untuk memverifikasi perincian langkah-langkah tantangan:
-
Segmentasi adalah suatu proses dimana kedua belah pihak saling berinteraksi secara bergiliran, satu pihak melakukan segmentasi data historis yang terdapat pada suatu Rollup Block tertentu, dan pihak lainnya menunjukkan bagian mana dari fragmen data yang bermasalah. Sebuah proses yang mirip dengan dikotomi (sebenarnya N/K) yang terus menerus dan bertahap mempersempit ruang lingkupnya.
-
Setelah itu, Anda dapat melanjutkan mencari lokasi transaksi dan hasil yang bermasalah, lalu membaginya lagi menjadi instruksi mesin yang disengketakan dalam transaksi tersebut.
-
Kontrak ChallengeManager hanya memeriksa apakah “fragmen data” yang dihasilkan setelah mengelompokkan data asli valid.
-
Setelah penantang dan tertantang menemukan instruksi mesin yang akan ditantang, penantang memanggil oneStepProveution() 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 bukti penipuan Arbitrum. Mari kita lihat apa yang secara spesifik dibuktikan oleh bukti satu langkah.
Hal ini memerlukan pemahaman terlebih dahulu tentang WAVM, **Wasm Arbitrum Virtual Machine, yang merupakan mesin virtual yang dikompilasi oleh modul ArbOS dan modul inti Geth (klien Ethereum). **Karena L2 benar-benar berbeda dari L1, inti Geth asli harus sedikit dimodifikasi dan berfungsi 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.
**Lalu 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 memproses 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 subdivisi interaktif sebelumnya, pembuktian satu langkah akhirnya membuktikan instruksi satu langkah dalam set instruksi WAVM. **
Seperti dapat dilihat pada kode di bawah ini, OneStepProofEntry harus terlebih dahulu 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 afterHash akan dikembalikan ke ChallengeManager. Jika hash tidak konsisten dengan hash setelah operasi instruksi dicatat di Rollup Block, maka tantangan berhasil. Jika konsisten, berarti tidak ada masalah dengan hasil eksekusi perintah ini yang tercatat di Blok Rollup, dan tantangannya gagal.
Pada artikel berikutnya, kami akan menganalisis Arbitrum dan bahkan modul kontrak yang menangani pesan lintas rantai/fungsi penghubung antara Layer2 dan Layer1, dan memperjelas lebih lanjut bagaimana Layer2 yang sebenarnya harus mencapai ketahanan sensor.
