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

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

Dalam artikel sebelumnya, “Mantan Duta Teknis Arbitrum Menjelaskan Struktur Komponen Arbitrum (Bagian I)”, kami memperkenalkan peran sequencer, validator, kontrak SequencerInbox, Blok Rollup, dan bukti penipuan non-interaktif dalam komponen inti Arbitrum, dan dalam artikel hari ini, kami akan fokus pada komponen komponen inti Arbitrum yang terkait dengan pesan interaksi lintas rantai dan pintu masuk transaksi yang tahan sensor.

Tubuh: Dalam artikel sebelumnya, kami menyebutkan bahwa kontrak Kotak Masuk Sequencer secara khusus menerima batch paket transaksi yang diterbitkan oleh sequencer pada Layer 1. Pada saat yang sama, kami menunjukkan bahwa Kotak Masuk Sequencer juga dikenal sebagai Kotak Cepat, sebagai lawan dari Kotak Masuk Tertunda Kotak Lambat (disingkat Kotak Masuk). **Di bawah ini, kita akan melihat lebih dekat komponen yang terkait dengan pesan interaksi lintas rantai, seperti Kotak Masuk Tertunda.

Prinsip Interaksi dan Jembatan Lintas Rantai

Transaksi interaksi Cross-Chain dapat dibagi menjadi L1 hingga L2 (deposit) dan L2 hingga L1 (penarikan). Perhatikan bahwa setoran dan penarikan yang disebutkan di sini tidak selalu terkait dengan interaksi lintas rantai aset, dan dapat berupa pesan yang tidak secara langsung melampirkan aset. Jadi dua kata ini hanya berarti dua arah perilaku terkait interaksi lintas rantai.

Transaksi Cross-Chain Interaction lebih rumit daripada transaksi L2 murni, transaksi Cross-Chain Interaction memiliki informasi yang ditukar dalam dua sistem yang berbeda, L1 dan L2.

Selain itu, apa yang biasa kita sebut perilaku interaksi lintas rantai adalah interaksi lintas rantai pada dua jaringan yang tidak terkait dengan jembatan Interaksi Lintas Rantai dalam mode saksi, dan keamanan Interaksi Lintas rantai ini tergantung pada operator Jembatan Interaksi Lintas Rantai, dan pencurian jembatan Interaksi Lintas Rantai berdasarkan model saksi telah sering terjadi dalam sejarah.

Perilaku Interaksi Lintas Rantai antara Rollup dan ETHMainnet pada dasarnya berbeda dari Interaksi Lintas Rantai di atas, karena keadaan Lapisan 2 ditentukan oleh data yang direkam pada Lapisan 1, selama Anda menggunakan jembatan Interaksi Lintas Rantai Rollup resmi, itu benar-benar aman dalam hal struktur operasi. **

Ini juga menyoroti esensi Rollup, itu hanya dari sudut pandang pengguna, seperti rantai independen, tetapi pada kenyataannya, apa yang disebut ** “Layer2” hanyalah jendela tampilan cepat Rollup yang terbuka untuk pengguna, dan struktur rantai aslinya masih terbakar di Layer 1. Oleh karena itu, kita dapat menganggap L2 sebagai setengah rantai, atau “rantai yang dibuat pada Layer 1”.

Tiket yang dapat dicoba kembali Dapat dicoba kembali

Perlu dicatat bahwa interaksi lintas rantai tidak sinkron dan non-atomik, tidak mungkin untuk mengetahui hasilnya setelah menyelesaikan konfirmasi transaksi seperti pada rantai, dan tidak ada jaminan bahwa sesuatu akan terjadi di sisi lain pada titik waktu tertentu. Oleh karena itu, Interaksi Lintas Rantai mungkin gagal karena beberapa masalah lunak, tetapi selama cara yang tepat digunakan, seperti Tiket yang Dapat Dicoba Kembali, masalah sulit seperti dana macet tidak akan terjadi.

**Tiket yang dapat dicoba kembali adalah alat dasar yang digunakan saat menyetor melalui jembatan Arbitrum resmi, **ETH dan setoran ERC20 digunakan. Siklus hidupnya dibagi menjadi tiga langkah:

**1. Kirim 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 tagihan untuk pengguna, tanpa perlu operasi manual berikutnya.

**3. L2. **Dalam beberapa kasus marjinal, seperti lonjakan harga gas yang tiba-tiba pada L2 dan gas prabayar yang tidak mencukupi pada nota, itu tidak akan ditebus secara otomatis. Dalam hal ini, perlu dilakukan secara manual oleh pengguna.

Perhatikan bahwa jika penebusan otomatis gagal, Anda harus menebus catatan secara manual dalam waktu 7 hari, jika tidak, tagihan akan dihapus (dana akan hilang secara permanen), atau Anda harus membayar biaya untuk memperbarui sewa untuk pelestarian tagihan.

Selain itu, meskipun ada kesamaan simetris tertentu antara proses penarikan jembatan resmi Arbitrum dan perilaku deposit, tidak ada konsep Retryables, yang dapat dipahami dari protokol Rollup itu sendiri di satu sisi, dan beberapa perbedaan di sisi lain:

Tidak ada penebusan otomatis dalam proses penarikan, karena tidak ada timer atau otomatisasi dalam EVM, dan penebusan otomatis dapat direalisasikan pada L2, yang dicapai dengan bantuan sequencer, sehingga pengguna di L1 perlu berinteraksi secara manual dengan kontrak Kotak Keluar untuk mengambil aset dengan Klaim. Tidak ada masalah tagihan jatuh tempo untuk penarikan, selama periode tantangan telah berlalu, itu dapat diklaim kapan saja.

Gateway interaksi lintas rantai aset ERC-20

• Interaksi lintas rantai aset ERC-20 sangat kompleks. Ada beberapa pertanyaan yang dapat kita renungkan:
• Token digunakan pada L1, bagaimana itu digunakan pada L2?
• Apakah mitra L2-nya perlu digunakan secara manual terlebih dahulu, atau dapatkah sistem secara otomatis menyebarkan kontrak aset untuk Token yang menyeberang tetapi belum menerapkan kontrak?
• Apa Alamat kontrak aset ERC-20 pada L1 yang sesuai dengan L2? Haruskah konsisten dengan L1?
• Bagaimana Interaksi Lintas Rantai ke L1 untuk Token yang dikeluarkan secara native di L2?
• Token dengan fungsi khusus, seperti jumlah Token Rebase yang dapat disesuaikan, Token berbunga yang tumbuh sendiri, bagaimana cara Interaksi Lintas Rantai?

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

Saat ini, banyak solusi penskalaan menggunakan solusi daftar yang diizinkan + inventaris manual untuk menghindari berbagai masalah kompleks dan situasi batas.

Arbitrum menggunakan sistem Gateway untuk menyelesaikan sebagian besar titik nyeri interaksi lintas rantai ERC20, dengan fitur-fitur berikut:

• Komponen gateway muncul berpasangan di L1 dan L2. Gateway Router bertanggung jawab untuk memelihara pemetaan Alamat antara Token L1<->Token L2, serta antara beberapa token <-> beberapa gateway.
• Gateway dapat dibagi menjadi gateway StandardERC20, gateway kustom generik, gateway Kustom, dll., Untuk menyelesaikan berbagai jenis dan masalah menjembatani ERC20 fungsional.

Mari kita ambil Interaksi Lintas Rantai WETH yang relatif sederhana sebagai contoh untuk menggambarkan perlunya gateway khusus.

WETH adalah ERC20 setara dengan ETH. Karena Ether adalah koin utama, banyak fungsi kompleks di dApps tidak dimungkinkan, jadi diperlukan setara ERC20. Transfer beberapa ETH ke dalam kontrak WETH, mereka akan dikunci dalam kontrak dan jumlah WETH yang sama akan dihasilkan.

Dengan cara yang sama, juga dimungkinkan untuk membakar WETH dan mengeluarkan ETH. **Jelas, jumlah WETH yang beredar dan jumlah Posisi Lock-up ETH akan selalu 1:1. **

** Jika kita sekarang interaksi lintas rantai WETH langsung ke L2, kita akan menemukan beberapa masalah aneh: **

• Tidak mungkin untuk membuka WETH ke dalam ETH di L2 karena tidak ada posisi penguncian yang sesuai dengan ETH di L2.
• Fungsi Wrap dapat digunakan, tetapi WETH yang baru dihasilkan ini tidak dapat didekapsulasi sebagai ETH pada L1 jika mereka menyeberang kembali ke L1, karena kontrak WETH pada L1 dan L2 tidak “simetris”.

Jelas, ini melanggar prinsip desain WETH. **Kemudian ketika WETH adalah interaksi lintas rantai, apakah itu setoran atau penarikan, itu perlu dibuka ke dalam ETH terlebih dahulu, dan kemudian disilangkan ke sisi yang berlawanan, dan kemudian dibungkus ke dalam WETH. Di sinilah WETH Gateway masuk.

Token lain dengan logika yang lebih kompleks melakukan hal yang sama, membutuhkan gateway yang lebih kompleks dan dirancang dengan baik untuk bekerja dengan baik dalam lingkungan interaksi lintas rantai. Gateway kustom Arbitrum mewarisi logika interaksi lintas rantai gateway biasa dan memungkinkan pengembang untuk menyesuaikan perilaku interaksi lintas rantai yang terkait dengan logika token, yang dapat memenuhi sebagian besar kebutuhan.

Kotak Masuk Tertunda

Mitra untuk SequencerInbox adalah Kotak Masuk Tertunda (Delayed Inbox). Karena kotak cepat didedikasikan untuk menerima batch transaksi L2 yang diterbitkan oleh sequencer, semua transaksi yang belum diproses sebelumnya oleh sequencer di jaringan L2 tidak boleh muncul dalam kontrak kotak cepat.

**Fungsi pertama dari slow box adalah untuk menangani perilaku top-up dari L1 ke L2. **Pengguna melakukan deposit melalui Kotak Lambat, dan sequencer mendengarkannya dan kemudian mencerminkannya di L2, dan akhirnya catatan deposit akan dimasukkan dalam urutan transaksi L2 oleh sequencer dan dikirimkan ke Kotak Masuk Sequencer.

Dalam contoh ini, tidak tepat bagi pengguna untuk mengirimkan transaksi deposit langsung ke Kotak Masuk Sequencer, karena transaksi yang dikirimkan ke Kotak Masuk Sequencer akan mengganggu urutan transaksi normal Layer 2, dan kemudian mempengaruhi pekerjaan sequencer.

Fungsi kedua dari slow box adalah untuk melawan sensor. **Transaksi yang dikirimkan langsung oleh pengguna ke kontrak Slowbox akan dikumpulkan oleh sequencer dalam waktu 10 menit. Tetapi jika sequencer dengan jahat mengabaikan permintaan Anda, slowbox juga memiliki fungsi inklusi paksa:

Jika transaksi dikirimkan ke Kotak Masuk Tertunda, setelah 24 jam, transaksi di Slowbox belum dimasukkan dalam urutan transaksi oleh sequencer, Pengguna dapat secara manual memicu fungsi inklusi kekuatan pada Layer 1, dan permintaan transaksi yang diabaikan oleh sequencer secara paksa dikelompokkan ke dalam Kotak Masuk Sequencer Fastbox, dan kemudian mereka akan dipantau oleh semua Node Arbitrum One dan akan dimasukkan secara paksa dalam urutan transaksi Layer 2.

Seperti yang kami sebutkan sebelumnya, data di fastbox adalah entitas data historis L2. Oleh karena itu, dalam kasus sensor berbahaya, ** akhirnya dapat menyertakan instruksi transaksi dalam buku besar L2 melalui kotak lambat, yang mencakup skenario seperti penarikan paksa untuk melarikan diri dari Layer 2. **

Dapat dilihat dari sini bahwa untuk segala arah dan tingkat transaksi, sequencer tidak akan dapat meninjau Anda secara permanen pada akhirnya.

Beberapa fungsi inti Kotak Masuk Slowbox:

• depositETH (), fungsi paling sederhana untuk menyetor ETH.
• createRetryableTicket(), yang dapat digunakan untuk menyetor ETH dan ERC20 serta pesan. Dibandingkan dengan depositETH (), ia memiliki fleksibilitas yang lebih tinggi, seperti kemampuan untuk menentukan alamat penerima L2 setelah deposit.
• forceInclusion(), yang merupakan fungsi agregasi paksa, dapat dipanggil oleh siapa saja. Fungsi ini memverifikasi apakah transaksi yang dikirimkan ke kontrak Slowbox belum diproses setelah 24 jam. Jika kondisi terpenuhi, pesan akan dikumpulkan secara paksa.

Namun, perlu dicatat bahwa fungsi Force Inclusion sebenarnya terletak di kontrak Slowbox, hanya untuk membuatnya lebih mudah dipahami, kami akan meletakkannya di sini di Slowbox dan menjelaskannya bersama.

Kotak keluar

Outbox hanya terkait dengan penarikan, yang dapat dipahami sebagai catatan dan sistem manajemen untuk perilaku penarikan:**

• Kita tahu bahwa penarikan dari jembatan resmi Arbitrum harus menunggu akhir periode tantangan sekitar 7 hari sebelum penarikan dapat dilaksanakan setelah Rollup Block diselesaikan. Pada akhir periode tantangan, pengguna mengirimkan Bukti Merkle yang sesuai ke kontrak Kotak Keluar pada Lapisan 1, yang berkomunikasi dengan kontrak fungsional lainnya (seperti membuka kunci aset yang terkunci dalam kontrak lain) dan akhirnya menyelesaikan penarikan.
• Kontrak OutBox akan mencatat pesan interaksi lintas rantai L2 hingga L1 mana yang telah diproses untuk mencegah seseorang berulang kali mengirimkan permintaan penarikan yang dieksekusi. Ini menggunakan pemetaan (uint256 = > byte32) spen publik untuk merekam Indeks yang dihabiskan dari permintaan penarikan dan korespondensi antara informasi, jika pemetaan[spentIndex] != bytes32(0), permintaan telah ditarik. Prinsipnya mirip dengan nonce counter transaksi yang mencegah serangan replay.

Di bawah ini kami akan mengambil ETH sebagai contoh untuk sepenuhnya menjelaskan proses deposit dan penarikan. Perbedaan antara ERC20 dan ERC20 adalah bahwa ia hanya melewati Gateway, jadi saya tidak akan mengulanginya.

ETH setoran

1. Pengguna memanggil fungsi depositETH () dari Slowbox.

2. Fungsi akan terus memanggil bridge.enqueueDelayedMessage (), merekam pesan dalam kontrak bridge, dan mengirim ETH ke kontrak bridge. **Semua dana deposit ETH disimpan dalam kontrak jembatan, yang setara dengan Alamat deposit. **

3. Sequencer mendengarkan pesan deposit di kotak lambat dan mencerminkan operasi deposit ke database L2, sehingga pengguna dapat melihat aset yang telah mereka simpan di jaringan L2.

4. Sequencer akan menyertakan catatan setoran ke dalam batch dan mengirimkannya ke kontrak Express di L1.

ETH penarikan

1. Pengguna memanggil fungsi withdrawEth() dari kontrak ArbSys pada L2 untuk membakar jumlah ETH yang sesuai pada L2.

2. Sequencer mengirimkan permintaan penarikan ke Quickbox.

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

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

5. Setelah kontrak Kotak Keluar mengonfirmasi bahwa itu benar, jumlah ETH yang sesuai di jembatan yang tidak terkunci dikirim ke pengguna.

Pembayaran cepat

Penarikan menggunakan jembatan resmi Optimistic Rollup akan menghasilkan masa tunggu untuk periode tantangan. Kami dapat menghindari masalah ini dengan jembatan Interaksi Lintas Rantai pihak ketiga pribadi:

• Kunci atom swapping. Metode ini hanya memungkinkan kedua pihak untuk menukar aset dalam rantai masing-masing, dan itu atom, selama satu pihak memberikan Preimage, kedua belah pihak pasti akan mendapatkan aset yang layak mereka dapatkan. Tetapi masalahnya adalah likuiditas relatif langka, dan perlu untuk menemukan rekanan peer-to-peer.
• Saksikan Jembatan Interaksi Lintas Rantai. **Jenis umum jembatan interaksi lintas rantai adalah jembatan saksi. Pengguna mengirimkan permintaan penarikan mereka sendiri ke operator bridge pihak ketiga atau kumpulan likuiditas. Setelah saksi menemukan bahwa interaksi lintas rantai telah diserahkan ke kontrak kotak cepat L1, ia dapat langsung mentransfer uang ke pengguna di sisi L1. Pendekatan ini pada dasarnya menggunakan sistem konsensus lain untuk memantau Layer 2 dan beroperasi pada data yang telah dikomitmenkan ke Layer 1. **Masalahnya adalah faktor keamanan dalam mode ini tidak setinggi jembatan Rollup resmi. **

Pembayaran paksa

force Inclusion() digunakan untuk melawan sensor sequencer dan dapat digunakan untuk transaksi lokal L2, L1-ke-L2, dan L2-ke-L1. Sensor berbahaya dari sequencer telah sangat mempengaruhi pengalaman perdagangan, dan dalam kebanyakan kasus kami akan memilih untuk menarik dan meninggalkan L2, jadi berikut ini adalah contoh penarikan paksa untuk memperkenalkan penggunaan forceInclusion.

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

• Panggil inbox.sendL2Message() dalam kontrak slowbox pada L1, dan parameter input adalah parameter yang perlu dimasukkan saat memanggil withdrawEth() pada L2. Pesan dibagikan dengan kontrak jembatan di L1.
• Setelah menunggu masa tunggu agregasi paksa 24 jam, panggil force Inclusion() di kotak cepat untuk memaksa pengumpulan, dan kontrak kotak cepat akan memeriksa apakah ada pesan yang sesuai di bridge.

Pengguna akhir dapat menarik diri di Kotak Keluar, dan langkah-langkah lainnya sama dengan penarikan normal.

Selain itu, arbitrum-tutorials juga memiliki tutorial terperinci tentang cara menggunakan Arb SDK untuk memandu pengguna tentang cara menggunakan forceInclusion() untuk melakukan transaksi lokal L2 dan transaksi L2 ke L1.