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.
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.”
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:
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:
Cross-chaining aset ERC-20 sangatlah kompleks. Kita dapat memikirkan beberapa pertanyaan:
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:
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:
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.
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):
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 hanya terkait dengan penarikan dan dapat dipahami sebagai sistem pencatatan dan pengelolaan perilaku penarikan:
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.
Pengguna memanggil fungsi depositETH() dari kotak lambat.
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.
Sequencer memonitor pesan deposit di slow box dan merefleksikan operasi deposit ke database L2. Pengguna dapat melihat aset yang mereka simpan di jaringan L2.
Sequencer memasukkan catatan deposit ke dalam batch transaksi dan mengirimkannya ke kontrak fast box di L1.
Pengguna memanggil fungsi penarikanEth() dari kontrak ArbSys di L2, dan jumlah ET yang sesuai dibakar di L2.
Sequencer mengirimkan permintaan penarikan ke kotak ekspres.
Node Validator membuat Rollup Block baru berdasarkan urutan transaksi di fast box, yang akan berisi transaksi penarikan di atas.
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.
Setelah kontrak Kotak Keluar dipastikan benar, jumlah ETH yang sesuai di jembatan akan dibuka dan dikirim ke pengguna.
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:
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:
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().
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.
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.”
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:
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:
Cross-chaining aset ERC-20 sangatlah kompleks. Kita dapat memikirkan beberapa pertanyaan:
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:
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:
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.
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):
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 hanya terkait dengan penarikan dan dapat dipahami sebagai sistem pencatatan dan pengelolaan perilaku penarikan:
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.
Pengguna memanggil fungsi depositETH() dari kotak lambat.
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.
Sequencer memonitor pesan deposit di slow box dan merefleksikan operasi deposit ke database L2. Pengguna dapat melihat aset yang mereka simpan di jaringan L2.
Sequencer memasukkan catatan deposit ke dalam batch transaksi dan mengirimkannya ke kontrak fast box di L1.
Pengguna memanggil fungsi penarikanEth() dari kontrak ArbSys di L2, dan jumlah ET yang sesuai dibakar di L2.
Sequencer mengirimkan permintaan penarikan ke kotak ekspres.
Node Validator membuat Rollup Block baru berdasarkan urutan transaksi di fast box, yang akan berisi transaksi penarikan di atas.
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.
Setelah kontrak Kotak Keluar dipastikan benar, jumlah ETH yang sesuai di jembatan akan dibuka dan dikirim ke pengguna.
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:
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:
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().