Mantan duta teknis Arbitrum menjelaskan struktur komponen Arbitrum (Bagian 2)

Bagaimana Arbitrum menangani pengiriman pesan lintas rantai dan transaksi yang tahan sensor? Apa model jembatan lintas rantainya?

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

Pada artikel sebelumnya* “Mantan Duta Teknis Arbitrum Menafsirkan Struktur Komponen Arbitrum (Bagian 1)”**, kami memperkenalkan sequencer, Validator, kontrak Sequencer Inbox, Rollup Block, dan bukti penipuan non-interaktif dalam komponen inti Arbitrum Dalam artikel hari ini, kami akan fokus pada komponen yang terkait dengan pesan lintas rantai dan pintu masuk transaksi yang tahan sensor di antara komponen inti Arbitrum. *

Pada artikel sebelumnya, kami telah menyebutkan bahwa kontrak Sequencer Inbox secara khusus menerima paket data transaksi Batch yang diterbitkan oleh sequencer pada Layer1. Pada saat yang sama, kami menunjukkan bahwa Kotak Masuk Sequencer juga disebut kotak cepat, bukan kotak masuk lambat Kotak Masuk Tertunda (disebut Kotak Masuk). Di bawah ini kami akan memberikan penjelasan detail mengenai komponen terkait pesan lintas rantai seperti Delayed Inbox.

Prinsip lintas rantai dan menjembatani

Transaksi lintas rantai dapat dibagi menjadi L1 ke L2 (isi ulang) dan L2 ke L1 (penarikan). Perhatikan bahwa pengisian ulang dan penarikan yang disebutkan di sini tidak selalu terkait dengan aset lintas rantai, tetapi dapat berupa pesan yang tidak menyertakan aset secara langsung. Jadi kedua kata ini hanya mewakili dua arah perilaku terkait lintas rantai.

Dibandingkan dengan transaksi L2 murni, transaksi lintas rantai bertukar informasi dalam dua sistem berbeda, L1 dan L2, sehingga prosesnya lebih rumit.

Selain itu, yang biasa kita sebut dengan perilaku lintas rantai adalah lintas rantai pada dua jaringan yang tidak terkait menggunakan jembatan lintas rantai mode saksi. Keamanan lintas rantai ini bergantung pada jembatan lintas rantai tersebut. Operator, pencurian lintas rantai jembatan rantai berdasarkan model saksi telah sering terjadi dalam sejarah.

Perilaku lintas rantai antara Rollup dan jaringan utama ETH pada dasarnya berbeda dari lintas rantai yang disebutkan di atas, karena status Layer2 ditentukan oleh data yang dicatat pada Layer1,** selama Anda menggunakan Rollup resmi. jembatan lintas rantai benar-benar aman dalam struktur operasionalnya. **

Ini juga menyoroti esensi dari Rollup. Ini hanya terlihat seperti rantai independen dari sudut pandang pengguna, namun sebenarnya yang disebut “**Layer2” hanyalah jendela tampilan cepat yang dibuka oleh Rollup kepada pengguna. Jenis rantai aslinya Struktur masih terbakar di Layer1. **Jadi, kita dapat menganggap L2 sebagai setengah rantai, atau “rantai yang dibuat pada Layer1”.

Tiket yang dapat dicoba lagi. Dapat dicoba lagi

Perlu dicatat bahwa rantai silang bersifat asinkron dan non-atom. Tidak mungkin mengetahui hasil setelah mengkonfirmasi transaksi seperti pada satu rantai, juga tidak dapat menjamin bahwa sesuatu akan terjadi di sisi lain pada titik waktu tertentu. . Oleh karena itu, lintas rantai mungkin gagal karena beberapa masalah ringan, namun selama cara yang benar digunakan, seperti Tiket yang Dapat Dicoba Ulang, masalah sulit seperti kemacetan dana tidak akan terjadi.

Tiket yang dapat dicoba ulang adalah alat dasar yang digunakan saat melakukan deposit melalui jembatan resmi Arbitrum. Deposit ETH dan ERC20 akan digunakan. Siklus hidupnya dibagi menjadi tiga langkah:

**1. Kirimkan tiket ke L1. **Gunakan metode createRetryableTicket() dalam kontrak Kotak Masuk Tertunda untuk membuat tiket isi ulang dan mengirimkannya.

**2. Penukaran otomatis pada L2. **Dalam kebanyakan kasus, penyortir dapat secara otomatis membantu pengguna membayar tagihan tanpa operasi manual selanjutnya.

**3. Penukaran manual pada L2. **Dalam beberapa kasus darurat, seperti lonjakan harga bahan bakar secara tiba-tiba di L2 dan jumlah bahan bakar yang dibayar di muka pada tiket tidak mencukupi, pembayaran otomatis tidak dapat dilakukan. Saat ini, pengoperasian manual oleh pengguna diperlukan.

Perhatikan bahwa jika penebusan otomatis gagal, wesel harus ditebus secara manual dalam waktu 7 hari, jika tidak, wesel tersebut akan dihapus (dana akan hilang secara permanen), atau biaya harus dibayar untuk menyimpan wesel guna memperbarui sewa.

Selain itu, meskipun proses penarikan jembatan resmi Arbitrum memiliki kesamaan simetris tertentu dengan perilaku isi ulang, tidak ada konsep Retryables, di satu sisi dapat dipahami dari protokol Rollup itu sendiri, dan di sisi lain, kita dapat memahaminya dari beberapa perbedaan:

• **Tidak ada penukaran otomatis selama proses penarikan, **karena EVM tidak memiliki timer atau otomatisasi, dan penukaran otomatis dapat dilakukan di L2, yang diimplementasikan dengan bantuan sequencer, sehingga pengguna di L1 harus secara manual berinteraksi dengan kontrak Kotak Keluar untuk mengklaim Ambil aset.
• **Tidak ada masalah masa berlaku tiket saat penarikan tunai. **Selama periode tantangan telah berlalu, Anda dapat menerimanya kapan saja.

Gerbang Lintas Rantai Aset ERC-20

Aset ERC-20 lintas rantai itu kompleks. Kita dapat memikirkan beberapa pertanyaan:

• Token diterapkan di L1, bagaimana cara menerapkannya di L2?
• Apakah kontrak terkait L2-nya perlu diterapkan secara manual terlebih dahulu, atau dapatkah sistem secara otomatis menerapkan kontrak aset untuk token yang telah menyeberang tetapi belum menerapkan kontrak?
• Untuk aset ERC-20 di L1, di manakah alamat kontrak terkait di L2? Haruskah itu konsisten dengan L1?
• Bagaimana cara token lintas rantai yang diterbitkan secara asli di L2 ke L1?
• Bagaimana token dengan fungsi khusus, seperti token rebase dengan jumlah yang dapat disesuaikan dan token berbunga sendiri, dapat di-cross-chain?

Kami tidak akan menjawab semua pertanyaan ini karena terlalu rumit untuk diungkapkan. Pertanyaan-pertanyaan ini hanya digunakan untuk menggambarkan kompleksitas lintas rantai ERC20.

Saat ini, banyak solusi perluasan yang menggunakan solusi daftar putih + daftar manual untuk menghindari berbagai masalah kompleks dan kondisi batas.

**Arbitrum menggunakan sistem Gateway untuk menyelesaikan sebagian besar masalah lintas rantai ERC20. **Arbitrum memiliki beberapa fitur berikut:

• Komponen gateway muncul berpasangan di L1 dan L2.
• **Gateway Router bertanggung jawab untuk memelihara pemetaan alamat antara Token L1<->Token L2, ** dan pemetaan antara beberapa token<->beberapa gateway.
• Gateway itu sendiri dapat dibagi menjadi gateway StandardERC20, gateway kustom Generik, gateway kustom, dll. untuk memecahkan berbagai jenis dan fungsi masalah penghubung ERC20.

Mari kita ambil cross-chain WETH yang relatif sederhana sebagai contoh untuk mengilustrasikan perlunya penyesuaian gateway.

WETH adalah ERC20 yang setara dengan ETH. Sebagai mata uang utama, Ether tidak dapat mengimplementasikan fungsi kompleks di banyak dApps, sehingga diperlukan ERC20 yang setara. Transfer sejumlah ETH ke dalam kontrak WETH, mereka akan dikunci dalam kontrak, dan jumlah WETH yang sama akan dihasilkan.

Dengan cara yang sama, WETH juga bisa dihancurkan dan ETH dikeluarkan. Tentunya jumlah WETH yang beredar dan ETH yang terkunci selalu 1:1. **

Jika sekarang kita melakukan cross-link WETH langsung ke L2, kita akan menemukan beberapa masalah aneh:

• Tidak mungkin untuk membuka bungkus WETH menjadi ETH di L2 karena tidak ada ETH yang sesuai untuk mengunci di L2.
• Fungsi Wrap dapat digunakan, tetapi jika WETH yang baru dihasilkan ini disilangkan kembali ke L1, maka WETH tersebut tidak dapat didekapsulasi menjadi ETH di L1 karena kontrak WETH di L1 dan L2 tidak “simetris”**.

Jelas sekali hal ini melanggar prinsip desain WETH. **Kemudian jika WETH bersifat cross-chain, baik itu isi ulang atau penarikan, perlu dibuka bungkusnya menjadi ETH terlebih dahulu, lalu disilangkan ke sisi lain, lalu dibungkus menjadi WETH. **Ini adalah peran WETH Gateway.

Hal yang sama berlaku untuk token lain dengan logika yang lebih kompleks, yang memerlukan Gateway yang lebih kompleks dan dirancang dengan cermat agar berfungsi dengan baik di lingkungan lintas rantai. Gateway khusus Arbitrum mewarisi logika komunikasi lintas rantai dari Gateway biasa dan memungkinkan pengembang untuk menyesuaikan perilaku lintas rantai yang terkait dengan logika token, yang dapat memenuhi sebagian besar kebutuhan.

Kotak Masuk Tertunda

Sesuai dengan kotak cepat, juga dikenal sebagai SequencerInbox, adalah kotak masuk lambat (nama lengkap Kotak Masuk Tertunda)**. Mengapa harus ada perbedaan antara kecepatan dan kelambatan? Karena fast box didedikasikan untuk menerima batch transaksi L2 yang dikeluarkan oleh sequencer, semua transaksi yang belum diproses sebelumnya oleh sequencer di jaringan L2 tidak akan muncul dalam kontrak fast box.

**Fungsi pertama dari slow box adalah untuk menangani perilaku isi ulang dari L1 ke L2. **Pengguna mengisi ulang melalui kotak lambat, dan sequencer memonitornya dan kemudian mencerminkannya di L2. Terakhir, catatan isi ulang akan dimasukkan dalam urutan transaksi L2 oleh sequencer dan diserahkan ke Kotak Masuk Sequencer kontrak kotak cepat.

Dalam contoh ini, tidak tepat bagi pengguna untuk mengirimkan transaksi isi ulang langsung ke kotak ekspres, karena transaksi yang dikirimkan ke kotak ekspres Kotak Masuk Sequencer akan mengganggu penyortiran transaksi normal Lapisan 2, dan kemudian mempengaruhi kerja sequencer.

Fungsi kedua dari kotak lambat adalah untuk menolak sensor. Pengguna langsung mengirimkan transaksi ke kontrak kotak lambat, dan penyortir biasanya akan menggabungkannya ke dalam kotak cepat dalam waktu 10 menit. Namun jika penyortir dengan sengaja mengabaikan permintaan Anda, kotak lambat juga memiliki fungsi inklusi paksa:

Jika transaksi dikirimkan ke Kotak Masuk Tertunda, dan setelah 24 jam, transaksi di kotak lambat belum dimasukkan dalam urutan transaksi oleh sequencer, ** pengguna dapat secara manual memicu fungsi penyertaan paksa pada Layer1, ** ke abaikan oleh sequencer Permintaan transaksi dikumpulkan secara paksa ke dalam Kotak Masuk Sequencer, dan kemudian akan dipantau oleh semua node Arbitrum One, dan akan dimasukkan secara paksa ke dalam urutan transaksi Layer 2. **

Seperti yang baru saja kami sebutkan, data di fast box adalah entitas data historis L2. Oleh karena itu, jika terjadi sensor jahat, instruksi transaksi akhirnya dapat dimasukkan ke dalam buku besar L2 melalui kotak lambat, yang mencakup skenario seperti penarikan paksa dan keluar dari Lapisan 2. **

Terlihat dari hal ini bahwa untuk transaksi ke segala arah dan level, sequencer pada akhirnya tidak akan dapat meninjau Anda secara permanen.

Beberapa fungsi inti Kotak Masuk kotak lambat:

• depositETH(), fungsi paling sederhana untuk menyetor ETH.
• createRetryableTicket(), yang dapat digunakan untuk ETH, ERC20 dan isi ulang pesan. Dibandingkan dengan depositETH(), ini memiliki fleksibilitas yang lebih tinggi, misalnya, Anda dapat menentukan alamat pembayaran L2 setelah deposit, dll.
• forceInclusion(), yang merupakan fungsi pengumpulan paksa, dapat dipanggil oleh siapa saja. Fungsi ini akan memverifikasi apakah transaksi yang dikirimkan ke kontrak slow box belum diproses setelah 24 jam. Jika persyaratan terpenuhi, pesan akan dikumpulkan secara paksa.

Namun perlu diperhatikan bahwa fungsi force Inclusion sebenarnya terletak pada fast box contract, untuk memudahkan pemahaman akan kami jelaskan bersama-sama pada slow box.

Kotak Keluar Kotak Keluar

Kotak keluar hanya terkait dengan penarikan dan dapat dipahami sebagai sistem pencatatan dan pengelolaan penarikan:

• Kami mengetahui bahwa penarikan dari jembatan resmi Arbitrum perlu menunggu sekitar 7 hari hingga akhir periode tantangan dan Rollup Block diselesaikan sebelum penarikan dapat dilaksanakan. Setelah periode tantangan berakhir, pengguna mengirimkan Bukti Merkle yang sesuai ke kontrak Kotak Keluar di Layer1, yang kemudian berkomunikasi dengan kontrak untuk fungsi lain (seperti membuka kunci aset yang dikunci dalam kontrak lain), dan akhirnya menyelesaikan penarikan.
• Kontrak OutBox akan mencatat pesan lintas rantai mana dari L2 ke L1 yang telah diproses untuk mencegah seseorang berulang kali mengirimkan permintaan penarikan yang dieksekusi. itu berlalu
• pemetaan(uint256 => bytes32) pembelanjaan publik, mencatat korespondensi antara Indeks pembelanjaan dari permintaan penarikan dan informasi, jika pemetaan [spentIndex] != bytes32(0) maka permintaan telah ditarik. Prinsipnya mirip dengan penghitung transaksi Nonce untuk mencegah serangan replay.

Di bawah ini kami akan mengambil ETH sebagai contoh untuk menjelaskan proses deposit dan penarikan secara lengkap. Satu-satunya perbedaan antara ERC20 dan Gateway adalah tidak akan dijelaskan secara detail.

Setoran ETH

1. Pengguna memanggil fungsi depositETH() dari kotak lambat.

2. Fungsi ini akan terus memanggil bridge.enqueueDelayedMessage(), mencatat pesan dalam kontrak jembatan, dan mengirimkan ETH ke kontrak jembatan. **Semua dana isi ulang ETH disimpan dalam kontrak jembatan, yang setara dengan alamat isi ulang. **

3. Sequencer memonitor pesan isi ulang di kotak lambat dan merefleksikan operasi isi ulang ke database L2. Pengguna dapat melihat aset yang telah mereka isi ulang di jaringan L2.

4. Sequencer memasukkan catatan isi ulang ke dalam batch transaksi dan menyerahkannya ke kontrak fast box di L1.

Penarikan ETH

1. Pengguna memanggil fungsi penarikanEth() dari kontrak ArbSys di L2 untuk menghancurkan jumlah ETH yang sesuai di L2.

2. Sequencer mengirimkan permintaan penarikan ke kotak ekspres.

3 **Node Validator membuat Blok Rollup baru berdasarkan urutan transaksi di kotak cepat, yang akan berisi transaksi penarikan di atas. **

4. Setelah Rollup Block melewati periode tantangan dan dikonfirmasi, pengguna dapat memanggil fungsi Outbox.ute Transaction() di L1 untuk membuktikan bahwa parameter diberikan oleh kontrak ArbSys yang disebutkan di atas.

5. Setelah kontrak Kotak Keluar dipastikan benar, jumlah ETH yang sesuai di jembatan yang tidak terkunci akan dikirimkan ke pengguna.

Penarikan cepat

**Jika Anda menggunakan jembatan resmi Optimistic Rollup untuk menarik uang tunai, akan ada masalah menunggu periode tantangan. Kita dapat menggunakan jembatan lintas rantai pihak ketiga swasta untuk menghindari masalah ini: **

• Pertukaran kunci atom. Cara ini hanya mempertukarkan aset antara kedua pihak dalam rantainya masing-masing, dan bersifat atomik.Selama salah satu pihak memberikan Preimage, kedua belah pihak pasti akan mendapatkan aset yang layak mereka dapatkan. Namun masalahnya adalah likuiditas relatif langka dan Anda perlu mencari rekanan secara langsung.
• **Saksikan jembatan lintas rantai. **Jenis umum jembatan lintas rantai adalah jembatan saksi. Pengguna mengajukan permintaan penarikan mereka sendiri, dan tujuan penarikan mengarah ke operator jembatan pihak ketiga atau kumpulan likuiditas. Setelah saksi mengetahui bahwa transaksi lintas rantai telah diserahkan ke kontrak fast box L1, ia dapat mentransfer uang langsung ke pengguna di sisi L1. Pendekatan ini pada dasarnya menggunakan sistem konsensus lain untuk memantau Lapisan 2 dan beroperasi berdasarkan data yang telah diserahkan ke Lapisan 1. **Masalahnya adalah faktor keamanan dalam mode ini tidak setinggi jembatan Rollup resmi. **

Penarikan paksa

force Inclusion() Fungsi force inclusion digunakan untuk menolak peninjauan sequencer. Setiap transaksi lokal L2, transaksi L1 ke L2, dan transaksi L2 ke L1 dapat diimplementasikan menggunakan fungsi ini. Ulasan berbahaya dari sequencer sangat mempengaruhi pengalaman transaksi. Dalam kebanyakan kasus, kami akan memilih untuk menarik uang dan meninggalkan L2. Oleh karena itu, berikut ini menggunakan penarikan paksa sebagai contoh untuk memperkenalkan penggunaan forceInclusion.

**Ingat bahwa dalam langkah penarikan ETH, hanya langkah 1 dan 2 yang melibatkan peninjauan sequencer, jadi hanya dua langkah ini yang perlu diubah: **

• Panggil inbox.sendL2Message() pada kontrak slow box di L1. Parameter masukan adalah parameter yang perlu dimasukkan saat memanggil penarikanEth() di L2. Pesan ini akan dibagikan ke kontrak jembatan di L1.
• Setelah menunggu masa tunggu penyertaan paksa selama 24 jam, panggil force Inclusion() di kotak cepat untuk melakukan penyertaan paksa. Kontrak kotak cepat akan memeriksa apakah ada pesan yang sesuai di jembatan.

Pengguna akhir dapat menarik uang di Kotak Keluar, dan langkah selanjutnya sama dengan penarikan biasa.

Selain itu, tutorial arbitrum juga memiliki tutorial mendetail tentang penggunaan Arb SDK untuk memandu pengguna tentang cara melakukan transaksi lokal L2 dan transaksi L2 ke L1 melalui forceInclusion().