Mantan Duta Besar Teknis Arbitrum Menjelaskan Struktur Komponen Arbitrum (Bagian I)

Penulis: Benben Luo, mantan duta teknis Arbitrum dan kontributor geek web3

**Artikel ini adalah interpretasi teknis dari Arbitrum One oleh Benben Luo, mantan duta teknis Arbitrum dan mantan salah satu pendiri Goplus Security, sebuah perusahaan audit otomatisasi Kontrak Cerdas. **

Karena artikel atau materi yang melibatkan Layer 2 di lingkaran Cina tidak memiliki interpretasi profesional tentang Arbitrum dan bahkan OP Rollup, artikel ini mencoba mengisi celah di bidang ini dengan mempopulerkan mekanisme operasi Arbitrum. Karena kompleksitas struktur Arbitrum itu sendiri, teks lengkapnya masih lebih dari 10.000 kata atas dasar penyederhanaan sebanyak mungkin, sehingga dibagi menjadi dua artikel, yang direkomendasikan untuk dikumpulkan dan diteruskan sebagai bahan referensi!**

Deskripsi singkat tentang sequencer Rollup

Prinsip penskalaan rollup dapat diringkas dalam dua poin:

Optimalisasi biaya: Memindahkan sebagian besar tugas komputasi dan penyimpanan ke L1 off-chain, yaitu, L2. **L2 sebagian besar adalah rantai yang berjalan pada satu server, yaitu sequencer / operator.

Sequencer terlihat dekat dengan server terpusat, meninggalkan “Desentralisasi” dalam “Blockchain Impossible Three Times” dengan imbalan TPS dan keuntungan biaya. Pengguna dapat membiarkan L2 memproses instruksi transaksi alih-alih Ethereum dengan biaya yang jauh lebih rendah daripada berdagang di Ethereum.

**Keamanan: Konten transaksi pada L2 dan status setelah transaksi akan disinkronkan ke Ethereum L1, dan validitas transisi status akan diverifikasi melalui kontrak. Pada saat yang sama, riwayat L2 akan disimpan di Ethereum, dan bahkan jika sequencer turun secara permanen, orang lain dapat memulihkan seluruh status L2 melalui catatan di Ethereum.

Pada dasarnya, keamanan Rollups didasarkan pada Ethereum. Jika sequencer tidak mengetahui kunci pribadi akun, ia tidak dapat memulai transaksi atas nama akun itu, atau merusak saldo aset di akun itu (dan bahkan jika ya, itu dengan cepat dikenali).

Meskipun sequencer terpusat sebagai tulang punggung sistem, dalam skema Rollup yang relatif matang, sequencer terpusat hanya dapat menerapkan perilaku jahat lunak seperti tinjauan transaksi, atau downtime berbahaya, tetapi dalam skema Rollup yang ideal, ada cara yang sesuai untuk mengekangnya (seperti mekanisme resistensi sensor seperti penarikan paksa atau bukti pesanan).

Metode verifikasi negara untuk mencegah sequencer rollup menjadi jahat dibagi menjadi dua jenis: Bukti Penipuan dan Bukti Validitas. Rollup yang menggunakan bukti penipuan disebut OP Rollup (Optimistic Rollups, OPRs), dan karena beberapa bagasi historis, Rollups yang menggunakan bukti validitas sering disebut ZK Rollups (Zero-knowledge Proof Rollups, ZKR) alih-alih Validity Rollups.

Arbitrum One adalah OPR khas yang menyebarkan kontrak pada L1 dan tidak secara aktif memvalidasi data yang dikirimkan, secara optimis percaya bahwa tidak ada masalah dengan data. Jika ada kesalahan dalam data yang dikirimkan, Node validator L2 memulai tantangan.

Jadi OPR juga menyiratkan asumsi kepercayaan: setidaknya ada satu Node validator L2 yang jujur pada waktu tertentu. Kontrak ZKR, di sisi lain, menggunakan kriptografi untuk secara aktif tetapi hemat biaya memverifikasi data yang dikirimkan oleh sequencer.

Pada artikel ini, kami akan Mendalam memperkenalkan Arbitrum One, proyek terkemuka dalam rollup optimis, yang mencakup semua aspek dari keseluruhan sistem, dan setelah membaca dengan cermat, Anda akan memiliki pemahaman mendalam tentang Arbitrum dan rollup/OPR optimis.

Komponen inti dan alur kerja Arbitrum

Kontrak Inti:

Kontrak terpenting Arbitrum termasuk SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, dll. Lebih lanjut tentang itu nanti.

Sequencer:

Transaksi pengguna diterima dan diurutkan, hasil transaksi dihitung, dan tanda terima dikembalikan ke pengguna dengan cepat (biasanya < 1 detik). Pengguna sering dapat melihat transaksi mereka di rantai L2 dalam hitungan detik, seperti platform Web2.

Pada saat yang sama, sequencer juga akan menyiarkan Blok L2 terbaru secara real time di bawah rantai Ethereum, dan setiap Node Layer2 dapat menerimanya secara asinkron. Tetapi pada titik ini, Blok L2 ini belum selesai dan dapat Rollback oleh sequencer.

Setiap beberapa menit, sequencer akan memampatkan data transaksi L2 yang diurutkan, menggabungkannya menjadi batch, dan mengirimkannya ke kontrak kotak masuk SequencerInbox pada Layer 1 untuk memastikan ketersediaan data dan pengoperasian protokol Rollup. Secara umum, data L2 yang dikirimkan ke Layer 1 tidak dapat dikembalikan dan dapat diselesaikan.

Dari proses di atas, kita dapat meringkas: Layer2 memiliki jaringan node sendiri, tetapi jumlah node ini langka, dan umumnya tidak ada protokol konsensus yang digunakan oleh rantai publik, sehingga keamanannya sangat buruk, dan harus dilampirkan ke Ethereum untuk memastikan keandalan rilis data dan efektivitas transisi negara.

Protokol Rollup Arbitrum:

Serangkaian kontrak yang menentukan struktur Blok RBlock dari rantai Rollup, kelanjutan rantai, pelepasan RBlock, dan proses mode tantangan. Perhatikan bahwa rantai Rollup yang disebutkan di sini bukanlah buku besar Layer2 seperti yang kita pahami, tetapi “struktur data rantai” abstrak yang dibuat oleh Arbitrum One untuk menerapkan mekanisme bukti penipuan.

RBlock dapat berisi hasil beberapa blok L2, dan datanya juga sangat berbeda, dan entitas datanya RBlock disimpan dalam serangkaian kontrak di RollupCore. Jika ada masalah dengan RBlock, Validator akan menantang committer RBlock tersebut.

Validator:

Node validator Arbitrum sebenarnya adalah subset khusus dari Layer2 Full Nodes, saat ini dengan akses Allowlist.

Validator membuat RBlock baru (Rollup Block, juga dikenal sebagai pernyataan) berdasarkan batch transaksi yang dikirimkan oleh sequencer ke kontrak SequencerInbox, dan memantau status rantai Rollup saat ini untuk menantang data yang salah yang dikirimkan oleh sequencer.

Validator aktif memerlukan staking aset sebelumnya pada rantai ETH, terkadang disebut sebagai staker. Meskipun Node Layer2 yang tidak mempertaruhkan juga dapat memantau dinamika Rollup yang sedang berjalan, mengirim alarm abnormal kepada pengguna, dll., Mereka tidak dapat secara langsung campur tangan dalam data kesalahan yang dikirimkan oleh sequencer pada rantai ETH.

Tantangan:

Langkah-langkah dasar dapat diringkas sebagai segmentasi interaktif multi-putaran dan bukti satu langkah. Dalam sesi segmentasi, kedua belah pihak ditantang untuk melakukan beberapa putaran pembagian berbasis giliran dari data transaksi yang bermasalah sampai instruksi Kode Operasi langkah yang bermasalah dipecah dan diverifikasi. Paradigma “segmentasi multi-putaran - bukti satu langkah” dianggap oleh pengembang Arbitrum sebagai implementasi bukti penipuan yang paling hemat gas. Semuanya berada di bawah kendali kontrak, dan tidak ada pihak yang bisa menipu.

Periode Tantangan:

Karena sifat optimis dari OP Rollup, setelah setiap RBlock diserahkan ke rantai, kontrak tidak secara aktif memeriksanya, meninggalkan jendela waktu bagi validator untuk memalsukan. Jendela waktu ini adalah periode tantangan, yaitu 1 minggu di Arbitrum One Mainnet. Setelah periode tantangan berakhir, RBlock akan diselesaikan, dan pesan yang sesuai dari L2 ke L1 di blok (seperti operasi penarikan yang dilakukan melalui jembatan resmi) dapat dirilis.

ArbOS, Geth, WAVM:

Mesin virtual yang digunakan oleh Arbitrum disebut AVM, yang terdiri dari dua bagian: Geth dan ArbOS. Geth adalah perangkat lunak klien Ethereum yang paling umum digunakan, 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, bekerja dengan EVM, dll. 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 mengilustrasikan hubungan dan alur kerja antara komponen di atas dalam diagram berikut:

Siklus hidup transaksi L2

Berikut cara kerja transaksi L2:

1. Pengguna mengirimkan instruksi perdagangan ke sequencer.

2. Sequencer terlebih dahulu memverifikasi data seperti Tanda Tangan Digital dari transaksi yang akan diproses, menghilangkan transaksi yang tidak valid, serta mengurutkan dan menghitung.

3. sequencer mengirimkan tanda terima transaksi ke pengguna (biasanya sangat cepat), tetapi ini hanya “preprocessing” dari sequencer off-ETH chain, yang dalam keadaan Soft Finality dan tidak dapat diandalkan. Tetapi bagi pengguna yang mempercayai sequencer (sebagian besar pengguna), optimis bahwa transaksi telah selesai dan tidak akan rollback.

4. Sequencer merangkum data mentah transaksi yang telah diproses sebelumnya ke dalam batch setelah kompresi tinggi.

5. Sesekali (dipengaruhi oleh faktor-faktor seperti volume data, kemacetan ETH, dll.), sequencer akan mempublikasikan batch transaksi ke kontrak Kotak Masuk Sequencer di L1. Pada titik ini, transaksi dapat dianggap memiliki Finalitas Keras.

Kontrak Kotak Masuk Sequencer

Kontrak akan menerima batch transaksi yang diajukan oleh sequencer untuk memastikan ketersediaan data. Melihat lebih dalam, data batch di SequencerInbox sepenuhnya mencatat informasi input transaksi Layer 2, bahkan jika sequencer turun secara permanen, siapa pun dapat mengembalikan status Layer 2 saat ini berdasarkan catatan batch, menggantikan sequencer tarik yang rusak / Rug.

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

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

Validator akan selalu mendengarkan kontrak SequencerInbox, dan setiap kali sequencer merilis batch ke kontrak, ia akan melempar peristiwa on-chain, dan setelah Validator mendengar peristiwa ini, ia akan mengunduh data batch, dan setelah eksekusi lokal, ia akan melepaskan RBlock ke kontrak protokol Rollup pada rantai ETH.

Kontrak jembatan Arbitrum memiliki parameter yang disebut akumulator, yang akan mencatat jumlah batch L2 yang baru dikirimkan, serta jumlah transaksi yang baru diterima dan informasi tentang kotak masuk yang lambat.

Kontrak SequencerInbox memiliki dua fungsi utama:

tambahkan Sequencer L2Batch From Origin(), yang dipanggil sequencer setiap kali mengirimkan data Batch ke kontrak Sequencer Inox.

force Inclusion(), yang dapat dipanggil oleh siapa saja dan digunakan untuk menerapkan transaksi yang tahan sensor. Cara kerja fungsi ini akan dijelaskan secara lebih rinci nanti ketika kita berbicara tentang kontrak Kotak Masuk Tertunda.

Kedua fungsi memanggil bridge.enqueueSequencerMessage() untuk memperbarui akumulator parameter akumulator dalam kontrak bridge.

Harga gas

Jelas, transaksi L2 tidak dapat gratis karena serangan DoS, biaya operasional sequencer L2 itu sendiri, dan overhead pengiriman data pada L1. Ketika pengguna memulai transaksi dalam jaringan Layer 2, biaya gas disusun sebagai berikut:

Biaya penerbitan data yang dihasilkan dengan menempati sumber daya Layer 1 terutama berasal dari batch yang dikirimkan oleh sequencer (setiap batch memiliki banyak transaksi pengguna), dan biaya tersebut pada akhirnya dibagi rata oleh inisiator transaksi. Algoritma untuk penetapan harga biaya yang dihasilkan oleh penerbitan data bersifat dinamis, dan sequencer akan memberi harga berdasarkan laba rugi baru-baru ini, ukuran batch, dan harga gas Ethereum saat ini.

Biaya yang dikeluarkan oleh pengguna karena pendudukan sumber daya Lapisan 2 diatur ke jumlah maksimum gas per detik yang dapat memastikan operasi sistem yang stabil (saat ini 7 juta untuk Arbitrum One). Harga panduan gas untuk L1 dan L2 dilacak dan disesuaikan oleh ArbOS, dan formulanya tidak akan diulang di sini untuk saat ini.

Meskipun proses perhitungan harga gas spesifik lebih rumit, pengguna tidak perlu melihat detail ini, dan jelas bahwa Biaya Transaksi Rollup jauh lebih murah daripada ETH Mainnet.

Bukti penipuan yang optimis

Untuk rekap, L2 benar-benar hanya proyeksi input batch dari transaksi yang disampaikan oleh sequencer di Fastbox, yaitu:

Input Transaksi -> STF -> Output Negara。 Input ditentukan, STF konstan, dan output juga ditentukan, dan sistem bukti penipuan dan protokol Arbitrum Rollup adalah sistem yang menerbitkan akar keadaan output ke L1 dalam bentuk RBlock (alias pernyataan) dan secara optimis membuktikannya.

Pada L1 ada data input yang diterbitkan oleh sequencer, dan ada juga status output yang diterbitkan oleh validator. Mari kita lihat lebih dekat, apakah perlu untuk mempublikasikan keadaan Layer 2 on-chain?

Karena input telah sepenuhnya menentukan output, dan data input terlihat oleh publik, mengirimkan output - state tampaknya berlebihan, tetapi ide ini mengabaikan fakta bahwa penyelesaian state sebenarnya diperlukan antara sistem L1-L2, yaitu, perilaku yang diusulkan L2 ke arah L1, dan perlu ada bukti state.

Saat membangun rollup, salah satu ide intinya adalah menempatkan sebagian besar komputasi dan penyimpanan pada L2 untuk menghindari tingginya biaya L1, yang berarti bahwa L1 tidak mengetahui keadaan L2, itu hanya membantu sequencer L2 mempublikasikan data input dari semua transaksi, tetapi tidak bertanggung jawab untuk menghitung keadaan L2.

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

Pada titik ini, kontrak Layer 1 akan bertanya: apa keadaan Anda di Layer 2, dan bagaimana Anda bisa membuktikan bahwa Anda benar-benar memiliki aset yang Anda klaim untuk dilewati. Pada saat ini, pengguna harus memberikan Bukti Merkle yang sesuai, dll.

Jadi, jika kita membangun rollup tanpa fungsi penarikan, secara teoritis mungkin untuk tidak menyinkronkan state ke L1, dan tidak perlu sistem proof-of-state seperti bukti penipuan (walaupun dapat menyebabkan masalah lain). Namun dalam praktiknya, ini jelas tidak layak.

Dalam apa yang disebut bukti optimis, kontrak tidak memeriksa apakah output yang diserahkan ke L1 dalam keadaan benar, dan optimis bahwa semuanya benar. Sistem bukti optimis mengasumsikan bahwa setidaknya ada satu validator jujur pada waktu tertentu, dan jika ada keadaan yang salah, itu ditantang oleh bukti penipuan.

Keuntungan dari desain ini adalah tidak perlu secara aktif memvalidasi setiap RBlock yang diterbitkan ke L1 untuk menghindari pemborosan gas. Faktanya, tidak praktis bagi OPR untuk memverifikasi setiap pernyataan, karena setiap rblock berisi satu atau lebih Blok L2, dan tidak ada bedanya dengan mengeksekusi transaksi L2 secara langsung pada L1 untuk mengeksekusi kembali setiap transaksi pada L1, yang kehilangan arti penskalaan Layer 2.

ZKR tidak memiliki masalah ini, karena ZK Proof memiliki kesederhanaan dan hanya perlu memverifikasi Bukti kecil, dan tidak perlu benar-benar melakukan banyak transaksi di balik Bukti. Oleh karena itu, ZKR tidak optimis, dan setiap kali status rilis diverifikasi secara matematis oleh kontrak Verfier.

Meskipun bukti penipuan tidak dapat sesingkat Bukti Tanpa Pengetahuan, Arbitrum menggunakan proses interaksi turn-by-turn “multi-round split-single-step proof”, dan pada akhirnya hanya satu Kode Operasi mesin virtual yang perlu dibuktikan, yang biayanya relatif kecil.

Protokol Rollup

Mari kita lihat bagaimana protokol Rollup, titik masuk untuk memulai tantangan dan meluncurkan bukti, bekerja.

Kontrak inti dari protokol Rollup adalah RollupProxy.sol, yang menggunakan struktur proxy ganda yang langka untuk memastikan konsistensi struktur data, satu proxy sesuai dengan dua implementasi RollupUserLogic.sol dan RollupAdminLogic.sol, yang tidak dapat diuraikan dengan baik dalam alat seperti Pindai.

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

Di RollupProxy, serangkaian RBlocks (alias pernyataan) yang dikirimkan oleh validator yang berbeda dicatat, yang merupakan kotak dalam diagram berikut: hijau - dikonfirmasi, biru - belum dikonfirmasi, kuning - dipalsukan.

RBlock berisi status akhir dari satu atau lebih blok L2 setelah eksekusi sejak RBlock terakhir. RBlocks ini secara morfologis membentuk Rollup Chain formal (perhatikan bahwa buku besar L2 itu sendiri berbeda). Dalam skenario optimis, Rollup Chain ini tidak boleh bercabang, karena memiliki fork berarti ada validator yang telah mengirimkan Rollup Block yang bertentangan.

Untuk membuat atau menyetujui pernyataan, validator harus terlebih dahulu mempertaruhkan sejumlah ETH untuk pernyataan dan menjadi staker. Dengan cara ini, jika terjadi bukti tantangan / penipuan, jaminan yang kalah akan dipotong, yang merupakan dasar ekonomi untuk menjamin perilaku jujur validator.

Blok biru 111 di sudut kanan bawah gambar pada akhirnya akan dipalsukan karena blok induknya 104 adalah Blok salah (kuning).

Selain itu, validator A mengusulkan Rollup Block 106, sementara B tidak setuju, menantangnya.

Setelah B memulai tantangan, kontrak ChallengeManager bertanggung jawab untuk memvalidasi rincian langkah-langkah tantangan:

1. Segmentasi adalah proses di mana dua pihak bergantian berinteraksi, dengan satu pihak mengelompokkan data historis yang terkandung dalam blok rollup dan pihak lainnya menunjukkan bagian mana dari fragmen data yang bermasalah. Mirip dengan proses dikotomi (N / K, sebenarnya) yang secara bertahap mempersempit jangkauan.

2. Setelah itu, Anda dapat terus mencari transaksi mana dan hasilnya bermasalah, dan kemudian membaginya lagi menjadi instruksi mesin yang diperdebatkan dalam transaksi itu.

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

4. Ketika penantang dan pihak yang ditantang 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.

Bukti satu langkah

Bukti satu langkah adalah jantung dari bukti penipuan di seluruh Arbitrum. Mari kita lihat apa yang dibuktikan oleh bukti langkah.

Ini membutuhkan pemahaman tentang WAVM, Mesin Virtual Wasm Arbitrum, yang merupakan mesin virtual yang dikompilasi dari modul ArbOS dan modul inti Geth (klien Ethereum). Karena L2 sangat berbeda dari L1 dalam banyak hal, inti Geth asli harus dimodifikasi ringan dan bekerja dengan ArbOS.

Jadi, transisi state pada L2 sebenarnya adalah fitur umum dari ArbOS + Geth Core.

Klien Node Arbitrum (Sequencer, Validator, Full Node, dll.) mengkompilasi program yang diproses oleh ArbOS + Geth Core di atas menjadi kode mesin asli (untuk x86 / ARM / PC / Mac / dll.) yang dapat langsung diproses oleh host Node.

Jika Anda mengubah bahasa target yang dikompilasi ke Wasm, Anda mendapatkan WAVM yang digunakan validator untuk menghasilkan bukti penipuan, dan kontrak yang memverifikasi bukti satu langkah juga mengemulasi fungsionalitas mesin virtual WAVM.

Alasan utamanya adalah bahwa kontrak yang memverifikasi bukti penipuan satu langkah menggunakan Kontrak EthereumSmart untuk mensimulasikan VM mesin virtual yang dapat menangani serangkaian set instruksi tertentu, dan WASM mudah diterapkan pada kontrak.

Namun, WASM sedikit lebih lambat dari kode mesin asli, jadi WAVM hanya akan digunakan oleh Node/Kontrak Arbitrum ketika bukti penipuan dihasilkan dan diverifikasi.

Setelah putaran segmentasi interaksi sebelumnya, bukti satu langkah akhirnya terbukti menjadi instruksi satu langkah dalam set instruksi WAVM.

Seperti yang dapat Anda lihat dalam kode berikut, OneStepProofEntry pertama-tama menentukan kategori mana Kode Operasi instruksi yang akan dibuktikan, dan kemudian memanggil prover yang sesuai seperti Mem, Matematika, dll., Dan meneruskan instruksi langkah demi langkah ke dalam kontrak prover.

Hasil akhir afterHash akan kembali ke ChallengeManager, dan jika hash tidak konsisten dengan hash yang tercatat di Rollup Block, tantangan akan berhasil. Jika konsisten, itu berarti bahwa hasil eksekusi instruksi yang dicatat pada Rollup Block baik-baik saja, dan tantangannya gagal.

Pada artikel berikutnya, kita akan menganalisis modul kontrak yang menangani fungsi interaksi/jembatan lintas rantai antara Arbitrum dan bahkan Layer 2 dan Layer 1, dan mengklarifikasi lebih lanjut bagaimana Layer 2 yang sebenarnya harus tahan sensor.