Teks Utama: Pada artikel sebelumnya, kami telah menyebutkan bahwa kontrak Sequencer Inbox dirancang khusus untuk menerima kumpulan data transaksi yang diterbitkan oleh sequencer pada Layer 1. Pada saat yang sama, kami menunjukkan bahwa Kotak Masuk Sequencer juga disebut sebagai "kotak cepat", dengan padanannya adalah Kotak Masuk Tertunda (disebut sebagai Kotak Masuk). Selanjutnya, kami akan memberikan penjelasan rinci tentang komponen yang terkait dengan pengiriman pesan lintas rantai, seperti Kotak Masuk Tertunda.
Transaksi lintas rantai dapat dibagi menjadi L1 ke L2 (setoran) dan L2 ke L1 (penarikan). Harap diperhatikan bahwa setoran dan penarikan yang disebutkan di sini tidak selalu terkait dengan aset cross-chain, tetapi dapat berupa pesan yang tidak secara langsung menyertakan aset. Jadi, dua kata ini hanya mewakili dua arah perilaku terkait lintas rantai.
Dibandingkan dengan transaksi L2 murni, transaksi cross-chain bertukar informasi dalam dua sistem yang berbeda, L1 dan L2, sehingga prosesnya lebih rumit.
Selain itu, apa yang biasanya kita sebut sebagai perilaku rantai silang adalah rantai silang pada dua jaringan yang tidak terkait menggunakan jembatan rantai silang mode-saksi. Keamanan rantai silang ini tergantung pada jembatan rantai silang. Secara historis, jembatan lintas rantai yang didasarkan pada modus saksi sering mengalami insiden pencurian.
Sebaliknya, perilaku lintas rantai antara Rollup dan mainnet Ethereum pada dasarnya berbeda dari operasi lintas rantai yang disebutkan di atas. Hal ini karena status Layer 2 ditentukan oleh data yang direkam pada Layer 1. Selama Anda menggunakan jembatan rantai silang Rollup resmi, struktur operasionalnya benar-benar aman.
Hal ini juga menyoroti esensi Rollup, yang, dari sudut pandang pengguna, muncul sebagai rantai independen. Namun demikian, pada kenyataannya, apa yang disebut "Layer 2" hanyalah jendela tampilan cepat yang dibuka oleh Rollup untuk pengguna, dan struktur seperti rantai yang sebenarnya masih terekam pada Layer 1. Oleh karena itu, kita dapat menganggap L2 sebagai setengah rantai, atau sebagai "rantai yang dibuat pada Layer 1."
Penting untuk dicatat bahwa operasi lintas rantai bersifat asinkron dan non-atomik. Tidak seperti pada rantai tunggal di mana hasil transaksi diketahui setelah dikonfirmasi, transaksi lintas rantai tidak dapat menjamin bahwa peristiwa tertentu akan terjadi di sisi lain pada waktu tertentu. Oleh karena itu, transaksi cross-chain dapat gagal karena masalah lunak, tetapi dengan metode yang benar, seperti Retryable Ticket, tidak akan ada masalah seperti dana yang macet.
Tiket yang dapat ditarik kembali adalah alat dasar yang digunakan saat menyetor dana melalui jembatan resmi Arbitrum untuk token ETH dan ERC20. Siklus hidupnya terdiri dari tiga langkah:
Mengirimkan tiket pada L1: Buat tiket deposit menggunakan metode createRetryableTicket() dalam kontrak Kotak Masuk Tertunda dan kirimkan.
Penukaran otomatis pada L2: Dalam sebagian besar kasus, sequencer dapat secara otomatis menukarkan tiket untuk pengguna tanpa campur tangan manual lebih lanjut.
Penukaran manual pada L2: Dalam kasus-kasus tertentu, seperti kenaikan harga gas secara tiba-tiba di L2 di mana gas prabayar pada tiket tidak mencukupi, penukaran otomatis mungkin gagal. Dalam kasus seperti itu, diperlukan intervensi manual oleh pengguna. Harap diperhatikan bahwa jika penukaran otomatis gagal, tiket harus ditukarkan secara manual dalam waktu 7 hari; jika tidak, tiket akan dihapus (mengakibatkan hilangnya dana secara permanen) atau memerlukan pembayaran biaya untuk memperbarui masa berlakunya.
Selain itu, dalam proses penarikan jembatan resmi Arbitrum, meskipun ada beberapa kesamaan simetris dengan perilaku setoran dalam hal prosesnya, tidak ada konsep Retryables. Hal ini dapat dipahami baik dari perspektif protokol Rollup itu sendiri maupun dengan memeriksa beberapa perbedaan:
Tidak ada penebusan otomatis selama penarikan karena EVM tidak memiliki pengatur waktu atau otomatisasi. Meskipun penebusan otomatis dapat diimplementasikan di L2 dengan bantuan sequencer, pengguna di L1 perlu berinteraksi secara manual dengan kontrak Outbox untuk mengklaim aset mereka.
Juga tidak ada masalah kedaluwarsa tiket selama penarikan; selama periode tantangan telah berlalu, aset dapat diklaim kapan saja.
Transaksi lintas rantai yang melibatkan aset ERC-20 sangat kompleks. Kita dapat mempertimbangkan beberapa pertanyaan:
Kami tidak bermaksud untuk menjawab semua pertanyaan ini karena terlalu rumit untuk dibahas secara komprehensif. Pertanyaan-pertanyaan ini hanya dimaksudkan untuk menggambarkan kompleksitas transaksi lintas rantai ERC-20.
Saat ini, banyak solusi penskalaan menggunakan solusi daftar putih + daftar manual untuk menghindari berbagai masalah dan kondisi batas yang rumit.
Arbitrum menggunakan sistem Gateway untuk mengatasi sebagian besar masalah dalam transaksi lintas rantai ERC20, dengan karakteristik sebagai berikut:
Untuk mengilustrasikan perlunya gateway khusus, mari kita pertimbangkan contoh yang relatif sederhana dari transfer WETH lintas rantai.
WETH adalah ERC20 yang setara dengan ETH. Karena Ether berfungsi sebagai mata uang utama, banyak fungsi kompleks dalam dApps yang tidak mungkin dicapai secara langsung. Oleh karena itu, diperlukan padanan ERC20 seperti WETH. Dengan menyetor sejumlah ETH ke dalam kontrak WETH, mereka terkunci di dalam kontrak, menghasilkan jumlah WETH yang setara.
Demikian juga, WETH dapat dibakar untuk menarik ETH. Yang jelas, jumlah WETH yang beredar dan jumlah ETH yang terkunci akan selalu mempertahankan rasio 1:1.
Jika kita sekarang langsung melakukan cross-chain WETH ke L2, kita akan menemukan beberapa masalah yang aneh:
Jelas, hal ini melanggar prinsip-prinsip desain WETH. Oleh karena itu, saat menyeberangi rantai silang WETH, baik penyetoran atau penarikan, Anda harus membukanya menjadi ETH terlebih dahulu, lalu menyeberang, dan membungkusnya kembali menjadi WETH. Di sinilah WETH Gateway berperan.
Demikian pula, untuk token lain dengan logika yang lebih kompleks, mereka membutuhkan Gateway yang lebih canggih dan dirancang dengan hati-hati agar berfungsi dengan baik dalam lingkungan cross-chain. Gateway khusus Arbitrum mewarisi logika komunikasi lintas rantai dari Gateway standar dan memungkinkan pengembang untuk menyesuaikan perilaku lintas rantai yang terkait dengan logika token, yang memenuhi sebagian besar persyaratan.
Pasangan dari SequencerInbox, juga dikenal sebagai kotak cepat, adalah Kotak Masuk (secara resmi bernama Kotak Masuk Tertunda). Mengapa ada perbedaan antara kotak cepat dan kotak yang tertunda? Karena fast box secara khusus dirancang untuk menerima kumpulan transaksi L2 yang diterbitkan oleh sequencer, dan setiap transaksi yang tidak diproses sebelumnya oleh sequencer dalam jaringan L2 tidak akan muncul dalam kontrak fast box.
Peran pertama dari slow box adalah untuk menangani perilaku deposit dari L1 ke L2. Pengguna memulai deposit melalui slow box, yang kemudian direfleksikan oleh sequencer pada L2. Pada akhirnya, catatan setoran ini akan dimasukkan ke dalam urutan transaksi L2 oleh sequencer dan dikirimkan ke kontrak kotak cepat, SequencerInbox.
Dalam skenario ini, tidak tepat bagi pengguna untuk langsung mengirimkan transaksi deposit ke fast box karena transaksi yang dikirimkan ke SequencerInbox akan mengganggu urutan transaksi normal Layer 2, sehingga mempengaruhi operasi sequencer.
Peran kedua dari kotak tunda adalah ketahanan terhadap sensor. Transaksi yang langsung dikirimkan ke kontrak kotak tertunda biasanya digabungkan ke dalam kotak cepat dalam waktu 10 menit oleh sequencer. Namun, jika sequencer secara jahat mengabaikan permintaan Anda, kotak yang tertunda memiliki fitur penyertaan paksa:
Jika transaksi dikirimkan ke Kotak Masuk Tertunda dan tetap tidak diagregasi ke dalam urutan transaksi oleh sequencer setelah 24 jam, pengguna dapat secara manual memicu fungsi penyertaan paksa pada Layer 1. Tindakan ini memaksa permintaan transaksi yang diabaikan oleh sequencer untuk dikumpulkan ke dalam kotak cepat, SequencerInbox, dan kemudian dideteksi oleh semua node Arbitrum One, sehingga secara paksa dimasukkan ke dalam urutan transaksi Layer 2.
Seperti yang telah kami sebutkan sebelumnya, data dalam kotak cepat mewakili entitas data historis L2. Oleh karena itu, dalam kasus penyensoran yang berbahaya, transaksi pada akhirnya dapat dimasukkan ke dalam buku besar L2 dengan menggunakan kotak yang ditunda, yang mencakup skenario seperti penarikan paksa dari Layer 2.
Dari sini, dapat dilihat bahwa sequencer pada akhirnya tidak dapat menyensor transaksi secara permanen ke arah atau lapisan mana pun.
Beberapa fungsi inti Kotak Masuk kotak lambat adalah sebagai berikut:
Namun, penting untuk dicatat bahwa fungsi forceInclusion() sebenarnya berada di dalam kontrak kotak cepat. Untuk kejelasan, kami membahasnya di sini bersama dengan fungsi slow box.
Outbox hanya terkait dengan penarikan dan dapat dipahami sebagai sistem pencatatan dan manajemen untuk perilaku penarikan:
Di bawah ini, kami akan menjelaskan proses penyetoran dan penarikan menggunakan ETH sebagai contoh. Proses untuk token ERC20 serupa, dengan penambahan Gateway, tetapi kami tidak akan menjelaskannya di sini.
Pengguna memanggil fungsi withdrawEth() dari kontrak ArbSys di L2 dan membakar jumlah ETH yang sesuai di L2.
Sequencer mengirimkan permintaan penarikan ke kotak cepat.
Node Validator membuat Rollup Block baru berdasarkan urutan transaksi di kotak cepat, yang akan berisi transaksi penarikan di atas.
Setelah Rollup Block melewati periode tantangan dan dikonfirmasi, pengguna dapat memanggil fungsi Outbox.execute Transaction() pada L1 untuk membuktikan bahwa parameter diberikan oleh kontrak ArbSys yang disebutkan di atas.
Setelah kontrak Outbox dikonfirmasi benar, jumlah ETH yang sesuai di dalam bridge akan dibuka dan dikirimkan kepada pengguna.
Menggunakan jembatan resmi Rollup yang optimis melibatkan menunggu periode tantangan. Untuk mengatasi masalah ini, kita dapat memanfaatkan jembatan lintas rantai pihak ketiga:
Fungsi forceInclusion() digunakan untuk melawan sensor sequencer. Ini dapat diterapkan pada transaksi lokal L2, transaksi L1 ke L2, dan transaksi L2 ke L1. Karena sensor berbahaya dari sequencer secara signifikan memengaruhi pengalaman transaksi, kita sering memilih untuk menarik dari L2. Di bawah ini adalah contoh penggunaan forceInclusion() untuk penarikan paksa:
Dalam konteks penarikan ETH, hanya langkah 1 dan 2 yang melibatkan sensor sequencer. Oleh karena itu, kita hanya perlu memodifikasi kedua langkah ini:
Terakhir, pengguna dapat menarik dana dari Outbox, dan langkah-langkah selanjutnya sama seperti proses penarikan normal.
Selain itu, ada tutorial terperinci dalam repositori arbitrum-tutorials yang memandu pengguna tentang cara melakukan transaksi lokal L2 dan transaksi L2 ke L1 menggunakan forceInclusion() melalui Arb SDK.
Teks Utama: Pada artikel sebelumnya, kami telah menyebutkan bahwa kontrak Sequencer Inbox dirancang khusus untuk menerima kumpulan data transaksi yang diterbitkan oleh sequencer pada Layer 1. Pada saat yang sama, kami menunjukkan bahwa Kotak Masuk Sequencer juga disebut sebagai "kotak cepat", dengan padanannya adalah Kotak Masuk Tertunda (disebut sebagai Kotak Masuk). Selanjutnya, kami akan memberikan penjelasan rinci tentang komponen yang terkait dengan pengiriman pesan lintas rantai, seperti Kotak Masuk Tertunda.
Transaksi lintas rantai dapat dibagi menjadi L1 ke L2 (setoran) dan L2 ke L1 (penarikan). Harap diperhatikan bahwa setoran dan penarikan yang disebutkan di sini tidak selalu terkait dengan aset cross-chain, tetapi dapat berupa pesan yang tidak secara langsung menyertakan aset. Jadi, dua kata ini hanya mewakili dua arah perilaku terkait lintas rantai.
Dibandingkan dengan transaksi L2 murni, transaksi cross-chain bertukar informasi dalam dua sistem yang berbeda, L1 dan L2, sehingga prosesnya lebih rumit.
Selain itu, apa yang biasanya kita sebut sebagai perilaku rantai silang adalah rantai silang pada dua jaringan yang tidak terkait menggunakan jembatan rantai silang mode-saksi. Keamanan rantai silang ini tergantung pada jembatan rantai silang. Secara historis, jembatan lintas rantai yang didasarkan pada modus saksi sering mengalami insiden pencurian.
Sebaliknya, perilaku lintas rantai antara Rollup dan mainnet Ethereum pada dasarnya berbeda dari operasi lintas rantai yang disebutkan di atas. Hal ini karena status Layer 2 ditentukan oleh data yang direkam pada Layer 1. Selama Anda menggunakan jembatan rantai silang Rollup resmi, struktur operasionalnya benar-benar aman.
Hal ini juga menyoroti esensi Rollup, yang, dari sudut pandang pengguna, muncul sebagai rantai independen. Namun demikian, pada kenyataannya, apa yang disebut "Layer 2" hanyalah jendela tampilan cepat yang dibuka oleh Rollup untuk pengguna, dan struktur seperti rantai yang sebenarnya masih terekam pada Layer 1. Oleh karena itu, kita dapat menganggap L2 sebagai setengah rantai, atau sebagai "rantai yang dibuat pada Layer 1."
Penting untuk dicatat bahwa operasi lintas rantai bersifat asinkron dan non-atomik. Tidak seperti pada rantai tunggal di mana hasil transaksi diketahui setelah dikonfirmasi, transaksi lintas rantai tidak dapat menjamin bahwa peristiwa tertentu akan terjadi di sisi lain pada waktu tertentu. Oleh karena itu, transaksi cross-chain dapat gagal karena masalah lunak, tetapi dengan metode yang benar, seperti Retryable Ticket, tidak akan ada masalah seperti dana yang macet.
Tiket yang dapat ditarik kembali adalah alat dasar yang digunakan saat menyetor dana melalui jembatan resmi Arbitrum untuk token ETH dan ERC20. Siklus hidupnya terdiri dari tiga langkah:
Mengirimkan tiket pada L1: Buat tiket deposit menggunakan metode createRetryableTicket() dalam kontrak Kotak Masuk Tertunda dan kirimkan.
Penukaran otomatis pada L2: Dalam sebagian besar kasus, sequencer dapat secara otomatis menukarkan tiket untuk pengguna tanpa campur tangan manual lebih lanjut.
Penukaran manual pada L2: Dalam kasus-kasus tertentu, seperti kenaikan harga gas secara tiba-tiba di L2 di mana gas prabayar pada tiket tidak mencukupi, penukaran otomatis mungkin gagal. Dalam kasus seperti itu, diperlukan intervensi manual oleh pengguna. Harap diperhatikan bahwa jika penukaran otomatis gagal, tiket harus ditukarkan secara manual dalam waktu 7 hari; jika tidak, tiket akan dihapus (mengakibatkan hilangnya dana secara permanen) atau memerlukan pembayaran biaya untuk memperbarui masa berlakunya.
Selain itu, dalam proses penarikan jembatan resmi Arbitrum, meskipun ada beberapa kesamaan simetris dengan perilaku setoran dalam hal prosesnya, tidak ada konsep Retryables. Hal ini dapat dipahami baik dari perspektif protokol Rollup itu sendiri maupun dengan memeriksa beberapa perbedaan:
Tidak ada penebusan otomatis selama penarikan karena EVM tidak memiliki pengatur waktu atau otomatisasi. Meskipun penebusan otomatis dapat diimplementasikan di L2 dengan bantuan sequencer, pengguna di L1 perlu berinteraksi secara manual dengan kontrak Outbox untuk mengklaim aset mereka.
Juga tidak ada masalah kedaluwarsa tiket selama penarikan; selama periode tantangan telah berlalu, aset dapat diklaim kapan saja.
Transaksi lintas rantai yang melibatkan aset ERC-20 sangat kompleks. Kita dapat mempertimbangkan beberapa pertanyaan:
Kami tidak bermaksud untuk menjawab semua pertanyaan ini karena terlalu rumit untuk dibahas secara komprehensif. Pertanyaan-pertanyaan ini hanya dimaksudkan untuk menggambarkan kompleksitas transaksi lintas rantai ERC-20.
Saat ini, banyak solusi penskalaan menggunakan solusi daftar putih + daftar manual untuk menghindari berbagai masalah dan kondisi batas yang rumit.
Arbitrum menggunakan sistem Gateway untuk mengatasi sebagian besar masalah dalam transaksi lintas rantai ERC20, dengan karakteristik sebagai berikut:
Untuk mengilustrasikan perlunya gateway khusus, mari kita pertimbangkan contoh yang relatif sederhana dari transfer WETH lintas rantai.
WETH adalah ERC20 yang setara dengan ETH. Karena Ether berfungsi sebagai mata uang utama, banyak fungsi kompleks dalam dApps yang tidak mungkin dicapai secara langsung. Oleh karena itu, diperlukan padanan ERC20 seperti WETH. Dengan menyetor sejumlah ETH ke dalam kontrak WETH, mereka terkunci di dalam kontrak, menghasilkan jumlah WETH yang setara.
Demikian juga, WETH dapat dibakar untuk menarik ETH. Yang jelas, jumlah WETH yang beredar dan jumlah ETH yang terkunci akan selalu mempertahankan rasio 1:1.
Jika kita sekarang langsung melakukan cross-chain WETH ke L2, kita akan menemukan beberapa masalah yang aneh:
Jelas, hal ini melanggar prinsip-prinsip desain WETH. Oleh karena itu, saat menyeberangi rantai silang WETH, baik penyetoran atau penarikan, Anda harus membukanya menjadi ETH terlebih dahulu, lalu menyeberang, dan membungkusnya kembali menjadi WETH. Di sinilah WETH Gateway berperan.
Demikian pula, untuk token lain dengan logika yang lebih kompleks, mereka membutuhkan Gateway yang lebih canggih dan dirancang dengan hati-hati agar berfungsi dengan baik dalam lingkungan cross-chain. Gateway khusus Arbitrum mewarisi logika komunikasi lintas rantai dari Gateway standar dan memungkinkan pengembang untuk menyesuaikan perilaku lintas rantai yang terkait dengan logika token, yang memenuhi sebagian besar persyaratan.
Pasangan dari SequencerInbox, juga dikenal sebagai kotak cepat, adalah Kotak Masuk (secara resmi bernama Kotak Masuk Tertunda). Mengapa ada perbedaan antara kotak cepat dan kotak yang tertunda? Karena fast box secara khusus dirancang untuk menerima kumpulan transaksi L2 yang diterbitkan oleh sequencer, dan setiap transaksi yang tidak diproses sebelumnya oleh sequencer dalam jaringan L2 tidak akan muncul dalam kontrak fast box.
Peran pertama dari slow box adalah untuk menangani perilaku deposit dari L1 ke L2. Pengguna memulai deposit melalui slow box, yang kemudian direfleksikan oleh sequencer pada L2. Pada akhirnya, catatan setoran ini akan dimasukkan ke dalam urutan transaksi L2 oleh sequencer dan dikirimkan ke kontrak kotak cepat, SequencerInbox.
Dalam skenario ini, tidak tepat bagi pengguna untuk langsung mengirimkan transaksi deposit ke fast box karena transaksi yang dikirimkan ke SequencerInbox akan mengganggu urutan transaksi normal Layer 2, sehingga mempengaruhi operasi sequencer.
Peran kedua dari kotak tunda adalah ketahanan terhadap sensor. Transaksi yang langsung dikirimkan ke kontrak kotak tertunda biasanya digabungkan ke dalam kotak cepat dalam waktu 10 menit oleh sequencer. Namun, jika sequencer secara jahat mengabaikan permintaan Anda, kotak yang tertunda memiliki fitur penyertaan paksa:
Jika transaksi dikirimkan ke Kotak Masuk Tertunda dan tetap tidak diagregasi ke dalam urutan transaksi oleh sequencer setelah 24 jam, pengguna dapat secara manual memicu fungsi penyertaan paksa pada Layer 1. Tindakan ini memaksa permintaan transaksi yang diabaikan oleh sequencer untuk dikumpulkan ke dalam kotak cepat, SequencerInbox, dan kemudian dideteksi oleh semua node Arbitrum One, sehingga secara paksa dimasukkan ke dalam urutan transaksi Layer 2.
Seperti yang telah kami sebutkan sebelumnya, data dalam kotak cepat mewakili entitas data historis L2. Oleh karena itu, dalam kasus penyensoran yang berbahaya, transaksi pada akhirnya dapat dimasukkan ke dalam buku besar L2 dengan menggunakan kotak yang ditunda, yang mencakup skenario seperti penarikan paksa dari Layer 2.
Dari sini, dapat dilihat bahwa sequencer pada akhirnya tidak dapat menyensor transaksi secara permanen ke arah atau lapisan mana pun.
Beberapa fungsi inti Kotak Masuk kotak lambat adalah sebagai berikut:
Namun, penting untuk dicatat bahwa fungsi forceInclusion() sebenarnya berada di dalam kontrak kotak cepat. Untuk kejelasan, kami membahasnya di sini bersama dengan fungsi slow box.
Outbox hanya terkait dengan penarikan dan dapat dipahami sebagai sistem pencatatan dan manajemen untuk perilaku penarikan:
Di bawah ini, kami akan menjelaskan proses penyetoran dan penarikan menggunakan ETH sebagai contoh. Proses untuk token ERC20 serupa, dengan penambahan Gateway, tetapi kami tidak akan menjelaskannya di sini.
Pengguna memanggil fungsi withdrawEth() dari kontrak ArbSys di L2 dan membakar jumlah ETH yang sesuai di L2.
Sequencer mengirimkan permintaan penarikan ke kotak cepat.
Node Validator membuat Rollup Block baru berdasarkan urutan transaksi di kotak cepat, yang akan berisi transaksi penarikan di atas.
Setelah Rollup Block melewati periode tantangan dan dikonfirmasi, pengguna dapat memanggil fungsi Outbox.execute Transaction() pada L1 untuk membuktikan bahwa parameter diberikan oleh kontrak ArbSys yang disebutkan di atas.
Setelah kontrak Outbox dikonfirmasi benar, jumlah ETH yang sesuai di dalam bridge akan dibuka dan dikirimkan kepada pengguna.
Menggunakan jembatan resmi Rollup yang optimis melibatkan menunggu periode tantangan. Untuk mengatasi masalah ini, kita dapat memanfaatkan jembatan lintas rantai pihak ketiga:
Fungsi forceInclusion() digunakan untuk melawan sensor sequencer. Ini dapat diterapkan pada transaksi lokal L2, transaksi L1 ke L2, dan transaksi L2 ke L1. Karena sensor berbahaya dari sequencer secara signifikan memengaruhi pengalaman transaksi, kita sering memilih untuk menarik dari L2. Di bawah ini adalah contoh penggunaan forceInclusion() untuk penarikan paksa:
Dalam konteks penarikan ETH, hanya langkah 1 dan 2 yang melibatkan sensor sequencer. Oleh karena itu, kita hanya perlu memodifikasi kedua langkah ini:
Terakhir, pengguna dapat menarik dana dari Outbox, dan langkah-langkah selanjutnya sama seperti proses penarikan normal.
Selain itu, ada tutorial terperinci dalam repositori arbitrum-tutorials yang memandu pengguna tentang cara melakukan transaksi lokal L2 dan transaksi L2 ke L1 menggunakan forceInclusion() melalui Arb SDK.