Meneruskan judul asli:

Artikel ini memberikan interpretasi teknis Arbitrum One oleh Luo Benben (罗奔奔), mantan duta teknis Arbitrum dan mantan salah satu pendiri Goplus Security, sebuah perusahaan audit otomatisasi kontrak pintar.

Karena kurangnya interpretasi profesional tentang Arbitrum dan bahkan OP Rollup dalam artikel atau materi berbahasa Cina terkait Layer 2, artikel ini berusaha untuk mengisi kesenjangan dalam bidang ini dengan mempopulerkan mekanisme operasional Arbitrum. Karena struktur Arbitrum sendiri terlalu kompleks, meskipun teks lengkap telah disederhanakan sebanyak mungkin, tetapi tetap melebihi 10.000 kata, sehingga dibagi menjadi dua bagian. Disarankan untuk mengumpulkannya dan meneruskannya sebagai referensi!

Pengantar singkat penata ulang sekuensial

Prinsip ekspansi Rollup dapat dirangkum menjadi dua poin:

Otimisasi biaya: Pindahkan sebagian besar tugas komputasi dan penyimpanan ke offchain L1, yaitu, L2. L2 sebagian besar adalah rantai yang berjalan pada satu server, yaitu, sequencer/operator.

Sequencer ini dalam arti tertentu dekat dengan server terpusat. Dalam “trinitas yang mustahil dari blockchain”, “desentralisasi” ditinggalkan demi TPS dan keuntungan biaya. Pengguna dapat membiarkan L2 memproses instruksi transaksi daripada Ethereum, dan biayanya jauh lebih rendah daripada bertransaksi di Ethereum.

(Sumber: Rantai BNB)

Jaminan Keamanan: Konten transaksi dan status yang dihasilkan pada Layer 2 disinkronkan ke Ethereum Layer 1, di mana validitasnya diverifikasi melalui kontrak. Sementara itu, Ethereum menyimpan catatan sejarah L2, jadi bahkan jika sequencer crash secara permanen, orang lain dapat merekonstruksi seluruh keadaan L2 dari catatan di Ethereum.

Secara mendasar, keamanan Rollup didasarkan pada Ethereum. Jika seorang pengurut tidak mengetahui kunci pribadi dari sebuah akun, ia tidak dapat menginisiasi transaksi atas nama akun tersebut atau merusak saldo aset dari akun tersebut (bahkan jika dicoba, hal itu akan segera terdeteksi).

Meskipun sequencer, sebagai hub pusat sistem, mungkin memiliki rona terpusat, dalam solusi Rollup yang matang, sequencer terpusat hanya dapat terlibat dalam perilaku berbahaya yang lembut seperti sensor transaksi atau crash berbahaya. Namun, dalam solusi Rollup yang ideal, ada langkah-langkah yang sesuai untuk menahan perilaku tersebut (seperti penarikan paksa atau menyortir bukti sebagai mekanisme anti-sensor).

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

Untuk mencegah perilaku jahat oleh pengurutan Rollup, ada dua jenis metode verifikasi state: Bukti Kecurangan dan Bukti Kewajaran. Solusi Rollup yang menggunakan Bukti Kecurangan disebut Optimistic Rollup (OPR), sementara yang menggunakan Bukti Kewajaran sering disebut sebagai ZK Rollup (Zero-knowledge Proof Rollup, ZKR), bukan Validity Rollup, karena beban sejarah.

Arbitrum One adalah OPR tipikal, digunakan pada kontrak L1, yang tidak secara aktif memvalidasi data yang dikirimkan tetapi secara optimis menganggap bahwa data tersebut benar. Jika ada kesalahan dalam data yang dikirimkan, validator L2 akan memulai tantangan.

Oleh karena itu, OPR juga mengimplikasikan asumsi kepercayaan: setidaknya ada satu node validator L2 yang jujur setiap saat. Di sisi lain, kontrak ZKR secara proaktif dan efisien memverifikasi data yang dikirim oleh sequencer melalui perhitungan kriptografis.

(Metode operasi Optimistic Rollup)

(Metode operasi ZK Rollup)

Artikel ini akan memberikan pengantar mendalam tentang proyek terkemuka di Optimistic Rollup — Arbitrum One, mencakup semua aspek sistem. Setelah membaca dengan cermat, Anda akan memperoleh pemahaman yang mendalam tentang Arbitrum dan Optimistic Rollup (OPR).

Komponen inti dan alur kerja Arbitrum:

Kontrak inti:

Kontrak-kontrak paling penting dalam Arbitrum termasuk SequencerInbox, DelayedInbox, Gerbang L1, Gerbang L2, Outbox, RollupCore, Jembatan, dll. Ini akan dijelaskan lebih lanjut.

Sequencer:

Menerima transaksi pengguna dan mengurutkannya, menghitung hasil transaksi, dan dengan cepat (biasanya <1s) mengembalikan struk kepada pengguna. Pengguna biasanya dapat melihat transaksi mereka dikonfirmasi di L2 dalam hitungan detik, memberikan pengalaman mirip Web2.

Selain itu, pengurutan secara langsung menyiarkan Blok L2 terbaru yang dihasilkan di bawah rantai Ethereum, yang dapat diterima secara asinkron oleh node Layer 2 mana pun. Namun, pada titik ini, Blok L2 ini belum memiliki kepastian dan dapat dibatalkan oleh pengurut.

Setiap beberapa menit, urutan kompresor mengompres data transaksi L2 yang disusun, menggabungkannya ke dalam batch, dan mengirimkannya ke kontrak SequencerInbox di Layer 1 untuk memastikan ketersediaan data dan operasi protokol Rollup. Umumnya, data L2 yang dikirimkan ke Layer 1 tidak dapat dibatalkan dan memiliki finalitas.

Dari proses di atas, kita dapat menyimpulkan bahwa Layer 2 memiliki jaringan node sendiri, tetapi node-node ini sedikit jumlahnya dan umumnya kurang memiliki protokol konsensus yang umum digunakan dalam blockchain publik. Oleh karena itu, keamanan mereka kurang baik, dan mereka harus mengandalkan Ethereum untuk memastikan kehandalan publikasi data dan validitas transisi keadaan.

Protokol Arbitrum Rollup:

Mendefinisikan struktur blok, yang disebut RBlocks, pada rantai Rollup, kelanjutan rantai, penerbitan RBlocks, dan proses mode tantangan, dll., Melalui serangkaian kontrak. Penting untuk dicatat bahwa rantai Rollup yang disebutkan di sini bukanlah buku besar yang umumnya dipahami sebagai Lapisan 2, melainkan "struktur data seperti rantai" abstrak yang dibuat secara independen oleh Arbitrum One untuk menerapkan mekanisme bukti penipuan.

Sebuah RBlock dapat berisi hasil dari beberapa blok L2, dan entitas datanya, RBlock, disimpan dalam serangkaian kontrak di dalam RollupCore. Jika terdapat isu dengan RBlock, validator akan menantangnya berdasarkan pengajuan dari pembuat RBlock tersebut.

Validator:

Validator di Arbitrum sebenarnya adalah subset khusus dari node penuh Layer 2, saat ini dengan penerimaan daftar putih.

Validator membuat RBlocks baru (blok Rollup, juga disebut sebagai asersi) berdasarkan kelompok transaksi yang dikirimkan ke kontrak SequencerInbox oleh sequencer, dan memantau status terkini rantai Rollup untuk menantang data yang salah yang dikirimkan oleh sequencer.

Validator aktif perlu mempertaruhkan aset di rantai Ethereum di muka, dan terkadang disebut sebagai stakers. Meskipun node Layer 2 yang tidak mempertaruhkan aset dapat memantau operasi Rollup dan mengirimkan peringatan kepada pengguna tentang anomali, mereka tidak dapat secara langsung campur tangan dalam data yang salah yang disampaikan oleh sequencer di rantai Ethereum.

Tantangan:

Langkah-langkah dasar dapat dirangkum sebagai subdivisi interaktif multi-putaran dan bukti dalam satu langkah. Pada tahap subdivisi, kedua pihak yang menantang pertama-tama terlibat dalam subdivisi interaktif multi-putaran dari data transaksi bermasalah hingga instruksi opcode bermasalah terurai dan diverifikasi. Paradigma 'subdivisi-multi-putaran-bukti satu langkah' dianggap oleh pengembang Arbitrum sebagai implementasi bukti penipuan yang paling efisien gas. Semua langkah dikendalikan oleh kontrak pintar, dan tidak ada pihak yang dapat menipu.

Periode Tantangan:

Karena sifat optimis OP Rollup, setelah setiap RBlock dikirimkan ke rantai, kontrak tidak secara aktif memeriksanya, meninggalkan periode waktu bagi validator untuk memalsukannya. Jendela waktu ini adalah periode tantangan, yang berlangsung satu minggu di mainnet Arbitrum One. Setelah periode tantangan berakhir, RBlock akan akhirnya dikonfirmasi, dan pesan yang sesuai dengan transaksi dari L2 ke L1 (seperti operasi penarikan yang dilakukan melalui jembatan resmi) dapat dirilis.

ArbOS, Geth, WAVM:

Arbitrum menggunakan mesin virtual yang disebut AVM, yang terdiri dari Geth dan ArbOS. Geth adalah perangkat lunak klien yang paling umum digunakan untuk Ethereum, dan Arbitrum telah membuat modifikasi ringan untuk itu. ArbOS bertanggung jawab atas semua fungsi khusus terkait L2, seperti manajemen sumber daya jaringan, menghasilkan blok L2, dan bekerja dalam koordinasi dengan EVM. Kami menganggap kombinasi keduanya sebagai AVM Asli, yang merupakan mesin virtual yang digunakan oleh Arbitrum. WAVM adalah hasil kompilasi kode AVM ke dalam Wasm. Dalam proses tantangan Arbitrum, "bukti satu langkah" terakhir memverifikasi instruksi WAVM.

Di sini, kita dapat merepresentasikan hubungan dan alur kerja antara berbagai komponen menggunakan diagram di bawah ini:

Siklus Transaksi L2

Alur pemrosesan transaksi L2 adalah sebagai berikut:

1. Pengguna mengirimkan instruksi transaksi ke penjurut.
2. Sequencer pertama memverifikasi data, termasuk tanda tangan digital, transaksi yang akan diproses, menyaring transaksi tidak valid, dan kemudian mengurutkan dan menghitungnya.
3. Sequencer mengirimkan tanda terima transaksi kepada pengguna (biasanya sangat cepat), tetapi ini hanya "pra-pemrosesan" yang dilakukan oleh sequencer pada rantai Ethereum, dan dalam keadaan Finalitas Lunak dan tidak dapat diandalkan. Namun, bagi pengguna yang mempercayai sequencer (sebagian besar pengguna), mereka dapat dengan optimis berasumsi bahwa transaksi telah selesai dan tidak akan dibatalkan.
4. Sequencer mengkapsulasi data transaksi yang telah diproses sebelumnya ke dalam Batch setelah dikompresi secara intensif.
5. Pada interval reguler (dipengaruhi oleh faktor-faktor seperti volume data dan kemacetan Ethereum), penjadwal menerbitkan Batch transaksi ke kontrak Sequencer Inbox di L1. Pada titik ini, transaksi dapat dianggap memiliki Finalitas Keras.

Kontrak Kotak Masuk Sequencer

Kontrak menerima sekelompok transaksi yang dikirim oleh penentu urutan untuk memastikan ketersediaan data. Secara mendalam, data kelompok di Kotak Masuk Penentu Urutan sepenuhnya mencatat informasi input transaksi Layer2. Bahkan jika penentu urutan mengalami kerusakan permanen, siapapun dapat memulihkan status saat ini Layer2 berdasarkan catatan kelompok dan mengambil alih penentu urutan yang gagal/hilang.

Dalam analogi fisik, apa yang kita lihat sebagai L2 hanyalah proyeksi dari batch di Kotak Masuk Pemutus, sementara sumber cahaya adalah Finalitas Lunak. Karena sumber cahaya Finalitas Lunak tidak berubah dengan mudah, bentuk bayangan hanya ditentukan oleh batch yang bertindak sebagai objek.

Kontrak Kotak Masuk Sequencer juga disebut kotak cepat, dan sequencer secara khusus mengirimkan transaksi yang telah diproses sebelumnya, dan hanya sequencer yang dapat mengirimkan data ke dalamnya. Kotak lambat yang sesuai adalah Kotak Masuk Delayer, yang fungsinya akan dijelaskan dalam proses selanjutnya.

Validator akan terus memantau kontrak Kotak Masuk Sequencer. Setiap kali sequencer menerbitkan Batch ke kontrak ini, sebuah acara on-chain dipicu. Setelah mendeteksi acara ini, validator akan mengunduh data batch, mengeksekusinya secara lokal, dan kemudian menerbitkan RBlock ke kontrak protokol Rollup pada rantai Ethereum.

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

(Pengurut terus-menerus mengirimkan batch ke SequencerInbox)

（Informasi khusus 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 Origin()，Sequencer akan memanggil fungsi ini setiap kali untuk mengirimkan data Batch ke kontrak Sequencer Inox.

force Inclusion(), Fungsi ini dapat dipanggil oleh siapa pun dan digunakan untuk melaksanakan transaksi tahan sensor. Cara fungsi ini berlaku akan dijelaskan secara detail nanti saat kita membicarakan kontrak Delayed Inbox.

Kedua fungsi di atas akan memanggil “bridge.enqueueSequencerMessage()” untuk memperbarui parameter akumulator dalam kontrak bridge.

Harga Gas

Tentu saja, transaksi L2 tidak bisa gratis, karena ini akan mengakibatkan serangan DoS. Selain itu, ada biaya operasional untuk sequencer L2 itu sendiri, dan akan ada overhead untuk mengirimkan data ke L1. Ketika pengguna memulai transaksi dalam jaringan Layer 2, struktur biaya gasnya adalah sebagai berikut:

Biaya publikasi data yang dihasilkan dengan menguasai sumber daya Layer1 terutama berasal dari batch yang dikirim oleh pengurut (setiap batch berisi transaksi dari banyak pengguna), dan biaya tersebut pada akhirnya dibagi di antara inisiator transaksi. Algoritma penetapan harga untuk biaya transaksi yang dihasilkan oleh publikasi data bersifat dinamis. Pengurut menyesuaikan penetapan harga berdasarkan kondisi laba rugi terkini, ukuran batch, dan harga gas Ethereum saat ini.

Biaya yang dikeluarkan oleh pengguna untuk menduduki sumber daya Layer2 ditentukan dengan menetapkan batas maksimum gas yang diproses per detik untuk memastikan operasi sistem yang stabil (saat ini Arbitrum One adalah 7 juta). Harga panduan gas untuk kedua L1 dan L2 dilacak dan disesuaikan oleh ArbOS, dan rumusnya tidak dijelaskan di sini.

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

Bukti penipuan optimis

Jika melihat kembali teks sebelumnya, jelas bahwa Layer2 (L2) pada dasarnya hanya proyeksi dari transaksi input batch yang dikirimkan oleh penyeleksi di Kotak Masuk Penyeleksi:

Masukan Transaksi -> Fungsi Transisi Status (STF) -> Keluaran Status

Input sudah ditentukan, dan STF tidak dapat diubah, sehingga hasil output juga sudah ditentukan. Bukti kecurangan dan sistem protokol Arbitrum Rollup menerbitkan status output, yang direpresentasikan oleh RBlock (juga dikenal sebagai asersi), ke Layer1 dan memberikan bukti optimis untuk itu.

Di L1, ada data masukan yang dipublikasikan oleh pengurut dan status keluaran yang dipublikasikan oleh validator. Setelah mempertimbangkan dengan cermat, apakah perlu untuk mempublikasikan status Layer2 on-chain? Karena data masukan sudah sepenuhnya menentukan keluaran, dan data masukan secara publik terlihat, mengirimkan hasil keluaran atau status terlihat berlebihan. Namun, ide ini mengabaikan kenyataan bahwa perlu ada penyelesaian status antara sistem L1 dan L2. Hal ini terutama diperlukan untuk tindakan penarikan dari L2 ke L1, yang memerlukan bukti status.

Saat membangun Rollup, ide inti adalah untuk memindahkan sebagian besar komputasi dan penyimpanan ke L2 untuk menghindari biaya tinggi dari L1. Hal ini menyiratkan bahwa L1 tidak mengetahui status L2; itu hanya membantu penentu urutan L2 dalam mempublikasikan data input untuk semua transaksi tetapi tidak bertanggung jawab untuk menghitung status L2.

Tindakan penarikan pada dasarnya melibatkan membuka kunci aset yang sesuai dari kontrak L1 berdasarkan pesan lintas-rantai yang disediakan oleh L2 dan mentransfernya ke akun L1 pengguna atau menyelesaikan tugas lainnya.

Pada titik ini, kontrak Layer1 akan menanyakan: apa keadaan Anda di Layer2, dan bagaimana Anda membuktikan bahwa Anda benar-benar memiliki aset yang Anda klaim untuk ditransfer? Pada tahap ini, pengguna perlu memberikan Merkle Proofs yang sesuai, dll.

Oleh karena itu, jika kita membangun Rollup tanpa fungsi penarikan, secara teoritis mungkin untuk tidak menyinkronkan negara ke L1, dan tidak perlu sistem bukti negara seperti bukti penipuan (meskipun dapat menyebabkan masalah lain). Tetapi dalam aplikasi nyata, ini jelas tidak layak.

Dalam apa yang disebut sebagai bukti optimis, kontrak tidak memeriksa apakah status output yang dikirimkan ke L1 benar, tetapi dengan optimis percaya bahwa semuanya akurat. Sistem bukti optimis mengasumsikan bahwa setidaknya ada satu Validator jujur setiap saat. Jika terjadi keadaan yang tidak benar, hal itu akan ditantang melalui bukti penipuan.

Keuntungan dari desain ini adalah bahwa tidak perlu memverifikasi setiap RBlock yang diterbitkan ke L1 secara aktif untuk menghindari pemborosan gas. Bahkan, untuk OPR, tidak realistis untuk memverifikasi setiap pernyataan, karena setiap Rblock berisi satu atau lebih blok L2, dan setiap transaksi harus dijalankan ulang di L1. Ini sama saja dengan menjalankan transaksi L2 secara langsung di L1, yang kehilangan makna skalabilitas Lapisan 2.

ZKR tidak menghadapi masalah ini karena Bukti ZK memiliki kekompakan, hanya memerlukan validasi dari bukti kecil tanpa perlu benar-benar mengeksekusi banyak transaksi di balik bukti tersebut. Oleh karena itu, ZKR tidak beroperasi secara optimis; setiap publikasi keadaan disertai dengan verifikasi matematis oleh kontrak Verifier.

Meskipun bukti penipuan tidak dapat mencapai tingkat kekompakan sebagaimana bukti pengetahuan nol, Arbitrum menggunakan proses interaktif 'pembagian multi-putaran - bukti langkah tunggal', di mana pada akhirnya hanya satu opcode mesin virtual perlu dibuktikan, yang mengakibatkan biaya yang relatif lebih rendah.

protokol Rollup

Mari kita pertama-tama melihat pintu masuk untuk memulai tantangan dan memulai bukti, yaitu, bagaimana protokol Rollup bekerja.

Kontrak inti dari protokol Rollup adalah RollupProxy.sol. Sambil memastikan struktur data konsisten, digunakan struktur agen ganda yang jarang. Satu agen sesuai dengan dua implementasi RollupUserLogic.sol dan RollupAdminLogic.sol, yang tidak dapat diparsing dengan baik oleh alat seperti Scan.

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

(Sumber: situs web resmi L2BEAT)

Di RollupProxy, serangkaian RBlocks (juga dikenal sebagai asersi) yang diajukan oleh validator yang berbeda direkam, diwakili oleh blok-blok dalam diagram: hijau untuk yang dikonfirmasi, biru untuk yang belum dikonfirmasi, dan kuning untuk yang dibantah.

RBlock berisi keadaan akhir yang dihasilkan dari eksekusi satu atau lebih blok L2 sejak RBlock sebelumnya. RBlocks ini membentuk Rantai Rollup dalam penampilan (perhatikan perbedaan dari ledger L2 itu sendiri). Dalam skenario optimis, Rantai Rollup ini seharusnya tidak memiliki fork, karena forking menunjukkan validator mengirimkan Rollup Blocks yang bertentangan.

Untuk mengajukan atau menyetujui sebuah pernyataan, validator perlu bertaruh sejumlah ETH tertentu, menjadi Staker. Hal ini memastikan dasar ekonomi untuk perilaku jujur di antara validator, karena taruhan kalah akan disita dalam kasus tantangan/bukti penipuan.

Blok biru yang bernomor 111 di sudut kanan bawah diagram pada akhirnya akan dibantah karena blok induknya, blok nomor 104, tidak benar (kuning).

Selain itu, Validator A telah mengusulkan Rollup Blok 106, yang tidak disetujui oleh Validator B dan menantangnya.

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

1. Segmentasi adalah proses di mana kedua pihak saling bergantian berinteraksi. Salah satu pihak membagi data historis yang terdapat dalam Blok Rollup tertentu, dan pihak lain menunjukkan bagian mana dari fragmen data yang bermasalah. Proses yang mirip dengan dikotomi (sebenarnya N/K) yang terus menerus dan secara bertahap menyempitkan ruang lingkup.

2. Selanjutnya, dapat lebih diperinci transaksi dan hasilnya yang bermasalah, kemudian lebih dibagi-bagi menjadi instruksi mesin spesifik dalam transaksi tersebut yang dipertentangkan.

3. Kontrak ChallengeManager hanya memverifikasi apakah "segmen data" yang dihasilkan setelah membagi data asli valid.

4. Ketika pihak yang menantang dan pihak yang ditantang mengidentifikasi instruksi mesin yang akan ditantang, pihak yang menantang memanggil oneStepProveExecution() untuk mengirim bukti penipuan satu langkah, menunjukkan bahwa hasil eksekusi dari instruksi mesin ini bermasalah.

Bukti satu langkah

Bukti satu langkah adalah inti dari seluruh bukti penipuan Arbitrum. Mari kita lihat apa yang secara khusus dibuktikan oleh bukti satu langkah tersebut.

Ini memerlukan pemahaman WAVM terlebih dahulu. Mesin Virtual Arbitrum Wasm 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 negara di L2 sebenarnya adalah hasil kerja sama ArbOS+Geth Core.

Klien node Arbitrum (penyusun, validator, node penuh, dll.) mengkompilasi program pemrosesan ArbOS+Geth Core di atas ke dalam kode mesin asli yang dapat diproses langsung oleh host node (untuk x86/ARM/PC/Mac/dll.).

Jika Anda mengubah bahasa sasaran yang diperoleh setelah kompilasi menjadi Wasm, Anda akan mendapatkan WAVM yang digunakan oleh verifikasi saat menghasilkan bukti kecurangan, dan kontrak untuk memverifikasi bukti langkah tunggal juga mensimulasikan fungsi mesin virtual WAVM.

Jadi mengapa perlu dikompilasi ke bytecode Wasm saat menghasilkan bukti penipuan? Alasan utamanya adalah untuk memverifikasi kontrak bukti penipuan langkah tunggal, diperlukan untuk menggunakan kontrak pintar Ethereum untuk mensimulasikan mesin virtual VM yang dapat menangani seperangkat instruksi tertentu, dan WASM mudah untuk menerapkan simulasi pada kontrak.

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

Setelah putaran interaktif sebelumnya dari subdivisi, bukti langkah tunggal akhirnya membuktikan instruksi langkah tunggal dalam set instruksi WAVM.

Seperti yang terlihat dalam kode di bawah, OneStepProofEntry pertama-tama menentukan kategori kode operasi dari instruksi yang akan dibuktikan, dan kemudian memanggil prover yang sesuai seperti Mem, Math, dll., untuk meneruskan instruksi langkah tunggal ke kontrak prover.

Hasil akhir setelahHash akan dikembalikan ke ChallengeManager. Jika hash tidak konsisten dengan hash setelah operasi instruksi yang tercatat pada Blok Rollup, tantangan berhasil. Jika keduanya konsisten, itu berarti tidak ada masalah dengan hasil eksekusi perintah ini yang tercatat pada Blok Rollup, dan tantangan gagal.

Penyangkalan:

1. Artikel ini dicetak ulang dari [Geek Web3], Semua hak cipta milik penulis asli [Luo Benben, mantan duta teknis Arbitrum, kontributor web3 geek]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan cepat.
2. Penafian Tanggung Jawab: Pandangan dan opini yang diungkapkan dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.