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

Pada artikel sebelumnya, “Struktur Komponen Arbitrum Ditafsirkan oleh Mantan Duta Teknis Arbitrum (Bagian 1),” kami memperkenalkan peran komponen utama dalam Arbitrum, termasuk sequencer, validator, kontrak kotak masuk sequencer, blok rollup, dan peran bukti penipuan non-interaktif. Dalam artikel hari ini, kami akan fokus menjelaskan komponen yang terkait dengan penyampaian pesan lintas rantai dan entri untuk transaksi anti-sensor di komponen inti Arbitrum.

Teks Utama: Pada artikel sebelumnya, kami menyebutkan bahwa kontrak Sequencer Inbox dirancang khusus untuk menerima kumpulan data transaksi yang diterbitkan oleh sequencer pada Lapisan 1. Pada saat yang sama, kami menunjukkan bahwa Kotak Masuk Sequencer juga disebut sebagai “kotak cepat”, dan sebaliknya, ada “kotak lambat” atau Kotak Masuk Tertunda (disebut sebagai Kotak Masuk). Di bawah ini, kami akan memberikan interpretasi rinci tentang komponen yang terkait dengan penyampaian pesan lintas rantai, termasuk Kotak Masuk Tertunda.

Prinsip cross-chain dan bridging

Transaksi lintas rantai dapat dibagi menjadi transaksi dari L1 ke L2 (deposit) dan transaksi dari L2 ke L1 (penarikan). Penting untuk dicatat bahwa istilah “penyetoran” dan “penarikan” di sini belum tentu melibatkan transfer aset lintas rantai; mereka dapat merujuk pada penyampaian pesan tanpa mentransfer aset secara langsung. Oleh karena itu, istilah-istilah ini hanya mewakili dua arah tindakan yang terkait lintas rantai.

Dibandingkan dengan transaksi L2 murni, transaksi lintas rantai melibatkan pertukaran informasi antara dua sistem berbeda, L1 dan L2, sehingga membuat prosesnya lebih kompleks.

Selain itu, ketika kita berbicara tentang tindakan lintas rantai, biasanya mengacu pada persilangan antara dua jaringan yang sama sekali tidak terkait menggunakan jembatan lintas rantai dalam model gabungan. Keamanan operasi lintas rantai tersebut bergantung pada operator jembatan lintas rantai, dan secara historis, insiden pencurian sering terjadi di jembatan lintas rantai berbasis saksi.

Di sisi lain, tindakan lintas rantai antara Rollup dan mainnet ETH pada dasarnya berbeda dari proses lintas rantai yang disebutkan di atas. Hal ini karena keadaan Layer2 ditentukan oleh data yang tercatat pada Layer1. Selama Anda menggunakan jembatan lintas rantai Rollup resmi, jembatan tersebut aman secara struktural dalam pengoperasiannya.

Hal ini menyoroti esensi Rollup, yang, dari sudut pandang pengguna, tampak sebagai rantai independen, namun kenyataannya, apa yang disebut "Layer2" hanyalah jendela tampilan cepat yang dibuka oleh Rollup kepada pengguna, dan strukturnya yang seperti rantai sebenarnya masih direkam pada Layer1. Oleh karena itu, kita dapat menganggap L2 sebagai setengah rantai atau “rantai yang dibuat pada Layer1.”

Dapat dicoba ulang

Harap dicatat bahwa transaksi lintas rantai bersifat asinkron dan non-atomik. Berbeda dengan transaksi dalam satu rantai, menyelesaikan transaksi dan mengonfirmasi hasilnya setelah satu transaksi dalam satu rantai tidak mungkin dilakukan dalam transaksi lintas rantai. Juga tidak ada jaminan bahwa sesuatu yang spesifik akan terjadi di sisi lain pada suatu waktu tertentu. Oleh karena itu, transaksi lintas rantai mungkin gagal karena beberapa masalah ringan, namun dengan penggunaan teknik yang tepat, seperti tiket yang dapat dicoba ulang, masalah sulit seperti dana tertahan tidak akan terjadi.

Tiket yang dapat dicoba ulang adalah alat dasar yang digunakan di jembatan resmi Arbitrum selama penyetoran, berlaku untuk penyetoran ETH dan ERC20. Siklus hidup terdiri dari tiga langkah:

1. Mengirimkan tiket di L1: Gunakan metode 'createRetryableTicket()' dalam kontrak Kotak Masuk Tertunda untuk membuat tiket deposit dan mengirimkannya.
2. Penukaran otomatis di L2: Dalam kebanyakan kasus, sequencer dapat secara otomatis menukarkan tiket untuk pengguna tanpa memerlukan tindakan manual tambahan.
3. Penukaran manual di L2: Dalam kasus ekstrim tertentu, seperti lonjakan harga bahan bakar secara tiba-tiba di L2, jika bahan bakar prabayar pada tiket tidak mencukupi, penukaran otomatis tidak dapat dilakukan. Dalam skenario ini, intervensi manual oleh pengguna diperlukan. Penting untuk diperhatikan bahwa jika penukaran otomatis gagal, pengguna harus menukarkan tiket secara manual dalam waktu 7 hari; jika tidak, tiket akan dihapus (mengakibatkan hilangnya dana secara permanen) atau pengguna harus membayar biaya tertentu untuk memperbarui penyimpanan tiket.

Lebih jauh lagi, mengenai proses penarikan di jembatan resmi Arbitrum, meskipun terdapat kemiripan simetris tertentu dalam prosesnya dibandingkan dengan penyetoran, namun tidak ada konsep tiket yang dapat dicoba kembali. Hal ini dapat dipahami dari sudut pandang protokol Rollup itu sendiri, dan beberapa perbedaan dapat disorot:

• Tidak ada penukaran otomatis selama proses penarikan karena EVM tidak memiliki pengatur waktu atau otomatisasi. Di L2, penukaran otomatis dapat diterapkan, dan difasilitasi oleh sequencer. Oleh karena itu, pengguna di L1 perlu berinteraksi secara manual dengan kontrak Kotak Keluar untuk mengklaim kembali aset mereka.
• Tidak ada masalah masa berlaku tiket selama penarikan. Selama periode tantangan telah berlalu, pengguna dapat mengklaim asetnya kapan saja.

Gerbang Lintas Rantai untuk Aset ERC-20

Cross-chaining aset ERC-20 sangatlah kompleks. Kita dapat memikirkan beberapa pertanyaan:

• bagaimana cara menyebarkan token yang diterapkan di L1 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 berpindah tetapi belum menerapkan kontrak?
• Untuk aset ERC-20 di L1, apa alamat kontrak terkait di L2? Haruskah itu konsisten dengan L1?
• Bagaimana token yang diterbitkan secara asli di L2 dapat dirantai silang 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 penskalaan yang menggunakan solusi daftar putih dan daftar manual untuk menghindari berbagai masalah kompleks dan kondisi batas.

Arbitrum menggunakan sistem Gateway untuk menyelesaikan sebagian besar masalah yang sulit pada lintas rantai ERC20. Ini memiliki beberapa fitur berikut:

• Komponen gateway muncul berpasangan di L1 dan L2.
• Gateway Router bertanggung jawab untuk menjaga pemetaan alamat antara Token L1<->Token L2. Selain itu, pemetaan antara beberapa token<->beberapa gateway.
• Gateway itu sendiri dapat dibagi menjadi gateway ERC20 Standar, gateway kustom Generik, gateway Kustom, dll., untuk menyelesaikan 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 dibakar dan ETH bisa ditarik. Jelasnya, rasio WETH yang beredar dan ETH yang terkunci selalu 1:1.

Jika sekarang kita langsung melakukan cross-chain WETH 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. Oleh karena itu, ketika WETH di-cross-chain, baik itu deposit atau penarikan, WETH harus dibuka menjadi ETH terlebih dahulu, kemudian disilangkan ke sisi lain, dan kemudian dibungkus menjadi WETH. Inilah 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

Mitra dari kotak masuk cepat, yang dikenal sebagai Sequencer Inbox, adalah kotak masuk lambat (bernama lengkap Delayed Inbox). Mengapa membedakan antara cepat dan lambat? Hal ini karena kotak masuk cepat didedikasikan untuk menerima kumpulan transaksi L2 yang diterbitkan oleh sequencer, dan transaksi apa pun yang tidak diproses sebelumnya oleh sequencer dalam jaringan L2 tidak akan muncul dalam kontrak kotak masuk cepat.

Fungsi slow inbox yang pertama adalah menangani proses deposit dari L1 ke L2. Pengguna memulai penyetoran melalui kotak masuk yang lambat, dan setelah sequencer mengamati hal ini, hal ini tercermin pada L2. Pada akhirnya, catatan setoran ini dimasukkan dalam urutan transaksi L2 oleh sequencer dan diserahkan ke kontrak kotak masuk cepat (Sequencer Inbox).

Dalam skenario ini, tidak pantas bagi pengguna untuk langsung mengirimkan transaksi deposit ke kotak masuk cepat (Kotak Masuk Sequencer) karena transaksi yang dikirimkan ke kotak masuk cepat dapat mengganggu pengurutan transaksi normal di Layer2, sehingga mempengaruhi pengoperasian sequencer.

Fungsi kedua dari kotak masuk lambat adalah tahan sensor. Transaksi yang dikirim langsung ke kontrak kotak masuk lambat umumnya dikumpulkan ke dalam kotak masuk cepat dalam waktu 10 menit oleh sequencer. Namun, jika sequencer dengan sengaja mengabaikan permintaan Anda, kotak masuk yang lambat memiliki fitur penyertaan paksa:

Jika suatu transaksi dikirimkan ke Kotak Masuk Tertunda dan, setelah 24 jam, transaksi tersebut tetap tidak dimasukkan ke dalam urutan transaksi oleh sequencer, pengguna dapat secara manual memicu fungsi penyertaan paksa pada Layer1. Tindakan ini memaksa transaksi yang diabaikan oleh sequencer untuk digabungkan secara paksa ke dalam kotak masuk cepat (Sequencer Inbox). Selanjutnya, mereka akan terdeteksi oleh semua node Arbitrum One dan secara paksa dimasukkan dalam urutan transaksi Layer2.

Kami baru saja menyebutkan bahwa data di kotak masuk cepat mewakili entitas data historis L2. Oleh karena itu, dalam kasus sensor berbahaya, penggunaan kotak masuk yang lambat memungkinkan instruksi transaksi pada akhirnya dimasukkan ke dalam buku besar L2, yang mencakup skenario seperti penarikan paksa untuk keluar dari Layer2.

Dari sini terlihat bahwa untuk segala arah dan tingkat transaksi, sequencer pada akhirnya tidak dapat menyensor Anda secara permanen.

Beberapa fungsi inti dari kotak masuk lambat (Inbox):

• depositETH(): Fungsi paling sederhana untuk menyetor ETH.
• createRetryableTicket(): Digunakan untuk menyetorkan ETH, ERC20, dan pesan. Ini menawarkan fleksibilitas yang lebih besar dibandingkan dengan depositETH(), memungkinkan spesifikasi seperti alamat penerima di L2 setelah deposit.
• forceInclusion(): Fungsi ini, fitur penyertaan paksa, dapat dipanggil oleh siapa saja. Fungsi tersebut memverifikasi apakah transaksi yang dikirimkan ke kontrak kotak masuk lambat belum diproses setelah 24 jam. Jika syaratnya terpenuhi, pesan tersebut akan disertakan secara paksa.

Namun, penting untuk dicatat bahwa fungsi penyertaan paksa sebenarnya terletak di kontrak kotak masuk cepat. Untuk memudahkan pemahaman, kami menjelaskannya bersama dengan inbox lambat.

Kotak keluar

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

• Kita tahu bahwa penarikan di jembatan resmi Arbitrum perlu menunggu sekitar 7 hari hingga periode tantangan berakhir, dan penarikan hanya dapat dilaksanakan setelah Rollup Block selesai. 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. Ini mencatat korespondensi antara Indeks pembelanjaan dan informasi permintaan penarikan dengan menggunakan 'mapping(uint256 => bytes32) pembelanjaan publik'. Jika pemetaan[spentIndex] != bytes32(0), 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 penyetoran dan penarikan secara lengkap. Satu-satunya perbedaan antara ERC20 dan ETH adalah ERC20 menggunakan Gateway. Kami tidak akan menjelaskannya secara detail.

Setoran ETH

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

2. Fungsi ini akan terus memanggil 'bridge.enqueueDelayedMessage()', catat pesan dalam kontrak jembatan, dan kirim ETH ke kontrak jembatan. Semua dana setoran ETH disimpan dalam kontrak jembatan, yang setara dengan alamat setoran.

3. Sequencer memonitor pesan deposit di slow box dan merefleksikan operasi deposit ke database L2. Pengguna dapat melihat aset yang mereka simpan di jaringan L2.

4. Sequencer memasukkan catatan deposit ke dalam batch transaksi dan mengirimkannya ke kontrak fast box di L1.

Penarikan ETH

1. Pengguna memanggil fungsi penarikanEth() dari kontrak ArbSys di L2, dan jumlah ET yang sesuai dibakar di L2.

2. Sequencer mengirimkan permintaan penarikan ke kotak ekspres.

3. Node Validator membuat Rollup Block baru berdasarkan urutan transaksi di fast box, yang akan berisi transaksi penarikan di atas.

4. Setelah Rollup Block melewati masa tantangan yang juga dikonfirmasi, pengguna dapat memanggil fungsi Outbox.execute 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 akan dibuka dan dikirim ke pengguna.

Penarikan tunai cepat

Saat 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 mengatasi masalah ini:

• Pertukaran kunci atom. Metode ini hanya mempertukarkan aset antara kedua pihak dalam rantai 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 dengan metode peer-to-peer.F
• Saksi melintasi jembatan rantai. Jenis jembatan lintas rantai yang umum 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 langsung mentransfer uang 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 tingkat keamanan dalam mode ini tidak setinggi jembatan Rollup resmi. \

Penarikan paksa

Fungsi force Inclusion() digunakan untuk menolak sensor sequencer. Setiap transaksi lokal L2, transaksi L1 ke L2, dan transaksi L2 ke L1 dapat diimplementasikan menggunakan fungsi ini. Sensor berbahaya pada 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.

Melihat kembali langkah-langkah penarikan ETH, hanya langkah 1 dan 2 yang melibatkan sensor sequencer, jadi hanya dua langkah ini yang perlu diubah:

• Saat memanggil 'inbox.sendL2Message()' dalam kontrak kotak lambat di L1, parameter masukan adalah parameter yang perlu dimasukkan saat memanggil penarikanEth() di L2. Pesan ini akan dibagikan ke kontrak jembatan di L1.
• Setelah masa tunggu penyertaan paksa selama 24 jam, force Inclusion() di kotak cepat dipanggil 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, terdapat juga tutorial mendetail tentang penggunaan Arb SDK dalam tutorial arbitrum untuk memandu pengguna tentang cara melakukan transaksi lokal L2 dan transaksi L2 ke L1 melalui fungsi forceInclusion().

Penafian:

1. Artikel ini dicetak ulang dari [极客 Web3]. Semua hak cipta milik penulis asli [极客 Web3]. 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.