Mantan Duta Teknologi Arbitrum: Struktur Komponen Arbitrum (Bagian 2)

PemulaFeb 27, 2024
Artikel ini memberikan interpretasi teknis dari Arbitrum One oleh Luo Benben (罗奔奔), mantan duta besar teknis Arbitrum dan mantan salah satu pendiri Goplus Security, sebuah perusahaan audit otomatisasi kontrak pintar.
Mantan Duta Teknologi Arbitrum: Struktur Komponen Arbitrum (Bagian 2)

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.

Prinsip rantai silang dan menjembatani

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."

Dapat ditarik kembali

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:

  1. Mengirimkan tiket pada L1: Buat tiket deposit menggunakan metode createRetryableTicket() dalam kontrak Kotak Masuk Tertunda dan kirimkan.

  2. Penukaran otomatis pada L2: Dalam sebagian besar kasus, sequencer dapat secara otomatis menukarkan tiket untuk pengguna tanpa campur tangan manual lebih lanjut.

  3. 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.

Gerbang Lintas Rantai Aset ERC-20

Transaksi lintas rantai yang melibatkan aset ERC-20 sangat kompleks. Kita dapat mempertimbangkan beberapa pertanyaan:

  • Bagaimana token digunakan di L2 jika digunakan di L1?
  • Haruskah kontrak yang sesuai pada L2 digunakan secara manual terlebih dahulu, atau dapatkah sistem secara otomatis menggunakan kontrak aset untuk token yang telah ditransfer tetapi belum digunakan?
  • Apakah alamat kontrak aset ERC-20 di L2 yang sesuai dengan alamatnya di L1? Haruskah alamat tersebut sesuai dengan alamat di L1?
  • Bagaimana token dikeluarkan secara native pada L2 dirantai silang ke L1?
  • Bagaimana token dengan fungsi khusus, seperti token Rebase pasokan yang dapat disesuaikan atau token staking otomatis, lintas rantai?

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:

  • Komponen Gateway muncul berpasangan pada L1 dan L2.
  • Gateway Router bertanggung jawab untuk menjaga pemetaan alamat antara Token L1 <-> Token L2 dan beberapa token <-> beberapa gateway.
  • Gateway itu sendiri dapat dibagi menjadi berbagai jenis, seperti gateway StandardERC20, gateway Generik-khusus, gateway khusus, dll., Untuk mengatasi masalah yang menjembatani berbagai jenis dan fungsi token ERC20.

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:

  • Tidak mungkin untuk membuka WETH menjadi ETH di L2 karena tidak ada ETH yang sesuai untuk mengunci di L2.
  • Fungsi Bungkus dapat digunakan, tetapi jika WETH yang baru dibuat ini disilangkan kembali ke L1, mereka tidak dapat dibuka menjadi ETH di L1 karena kontrak WETH di L1 dan L2 tidak "simetris".

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.

Kotak Masuk Tertunda

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:

  • depositETH(): Fungsi ini adalah metode paling sederhana untuk menyetor ETH.
  • createRetryableTicket(): Fungsi ini dapat digunakan untuk menyimpan ETH, token ERC20, dan pesan. Dibandingkan dengan depositETH(), ia menawarkan fleksibilitas yang lebih besar, seperti menentukan alamat penerima pada L2 setelah deposit.
  • forceInclusion(): Juga dikenal sebagai fungsi penyertaan gaya, yang dapat dipanggil oleh siapa saja. Fungsi ini memverifikasi apakah transaksi yang dikirimkan ke kontrak slow box belum diproses setelah 24 jam. Jika kondisi terpenuhi, fungsi ini akan secara paksa menggabungkan pesan.

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.

Kotak keluar

Outbox hanya terkait dengan penarikan dan dapat dipahami sebagai sistem pencatatan dan manajemen untuk perilaku penarikan:

  • Kita tahu bahwa penarikan di jembatan resmi Arbitrum harus menunggu sekitar 7 hari hingga periode tantangan berakhir, dan penarikan hanya dapat dilakukan setelah Rollup Block selesai. Setelah periode tantangan berakhir, pengguna mengirimkan Merkle Proof yang sesuai ke kontrak Outbox di Layer1, yang kemudian berkomunikasi dengan kontrak untuk fungsi lain (seperti membuka aset yang terkunci dalam kontrak lain), dan akhirnya menyelesaikan penarikan.
  • Kontrak OutBox mencatat pesan lintas rantai L2 ke L1 mana yang telah diproses untuk mencegah seseorang berulang kali mengirimkan permintaan penarikan yang telah dieksekusi. Hal ini dicapai melalui pemetaan yang disebut spent, yang mengaitkan indeks spent permintaan penarikan dengan informasi terkait. Jika mapping[spentIndex] != bytes32(0), ini mengindikasikan bahwa permintaan telah ditarik. Prinsipnya mirip dengan transaction counter nonce, yang digunakan untuk mencegah serangan replay.

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.

Setoran ETH

  1. Pengguna memanggil fungsi depositETH() dari Kotak Masuk Tertunda.
  2. Fungsi ini kemudian memanggil bridge.enqueueDelayedMessage(), yang mencatat pesan dalam kontrak penghubung dan mengirimkan ETH ke kontrak penghubung. Semua dana ETH yang disetorkan disimpan dalam kontrak jembatan, yang bertindak sebagai alamat setoran.
  3. Sequencer memantau pesan setoran di Kotak Masuk Tertunda dan merefleksikan operasi setoran dalam database L2. Pengguna dapat melihat aset yang disimpan di jaringan L2.
  4. Sequencer menyertakan catatan setoran dalam kumpulan transaksi dan mengirimkannya ke kontrak Fast Inbox pada L1.

Penarikan ETH

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

  2. Sequencer mengirimkan permintaan penarikan ke kotak cepat.

  3. Node Validator membuat Rollup Block 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.execute Transaction() pada L1 untuk membuktikan bahwa parameter diberikan oleh kontrak ArbSys yang disebutkan di atas.

  5. Setelah kontrak Outbox dikonfirmasi benar, jumlah ETH yang sesuai di dalam bridge akan dibuka dan dikirimkan kepada pengguna.

Penarikan Cepat

Menggunakan jembatan resmi Rollup yang optimis melibatkan menunggu periode tantangan. Untuk mengatasi masalah ini, kita dapat memanfaatkan jembatan lintas rantai pihak ketiga:

  • Pertukaran Pertukaran Atomik (Atomic Swap Exchange): Dalam pendekatan ini, aset dipertukarkan antara pihak-pihak dalam rantai masing-masing, dan bersifat atomik, yang berarti jika salah satu pihak memberikan preimage, kedua pihak dapat memperoleh aset yang sesuai. Namun, likuiditas relatif langka, sehingga membutuhkan pencarian rekanan secara peer-to-peer.
  • Jembatan Rantai Silang Berbasis Saksi: Sebagian besar jenis jembatan rantai silang termasuk dalam kategori ini. Pengguna mengirimkan permintaan penarikan mereka, dengan menentukan tujuan sebagai operator atau kumpulan likuiditas dari jembatan pihak ketiga. Setelah saksi menemukan bahwa transaksi lintas rantai telah dikirimkan ke kontrak Fast Inbox di L1, mereka dapat langsung mentransfer dana ke pengguna di L1. Pada dasarnya, metode ini menggunakan sistem konsensus lain untuk memonitor Layer 2 dan melakukan operasi berdasarkan data yang dikirimkan ke Layer 1. Namun demikian, tingkat keamanan dalam mode ini lebih rendah dibandingkan dengan jembatan resmi Rollup.

Penarikan paksa

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:

  • Panggil inbox.sendL2Message() dalam kontrak Kotak Masuk Tertunda pada L1, dengan parameter yang diperlukan saat memanggil withdrawEth() pada L2. Pesan ini dibagikan dengan kontrak jembatan pada L1.
  • Setelah menunggu masa tunggu penyertaan paksa selama 24 jam, panggil forceInclusion() dalam kontrak Fast Inbox untuk memaksa penyertaan. Kontrak Kotak Masuk Cepat akan memeriksa apakah ada pesan yang sesuai di jembatan.

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.

Penafian: Penafian

  1. Artikel ini dicetak ulang dari [Geek Web3], Semua hak cipta adalah milik penulis asli[Luo Benben, mantan duta besar teknis Arbitrum, kontributor Geek Web3]]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
  2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
  3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.

Mantan Duta Teknologi Arbitrum: Struktur Komponen Arbitrum (Bagian 2)

PemulaFeb 27, 2024
Artikel ini memberikan interpretasi teknis dari Arbitrum One oleh Luo Benben (罗奔奔), mantan duta besar teknis Arbitrum dan mantan salah satu pendiri Goplus Security, sebuah perusahaan audit otomatisasi kontrak pintar.
Mantan Duta Teknologi Arbitrum: Struktur Komponen Arbitrum (Bagian 2)

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.

Prinsip rantai silang dan menjembatani

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."

Dapat ditarik kembali

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:

  1. Mengirimkan tiket pada L1: Buat tiket deposit menggunakan metode createRetryableTicket() dalam kontrak Kotak Masuk Tertunda dan kirimkan.

  2. Penukaran otomatis pada L2: Dalam sebagian besar kasus, sequencer dapat secara otomatis menukarkan tiket untuk pengguna tanpa campur tangan manual lebih lanjut.

  3. 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.

Gerbang Lintas Rantai Aset ERC-20

Transaksi lintas rantai yang melibatkan aset ERC-20 sangat kompleks. Kita dapat mempertimbangkan beberapa pertanyaan:

  • Bagaimana token digunakan di L2 jika digunakan di L1?
  • Haruskah kontrak yang sesuai pada L2 digunakan secara manual terlebih dahulu, atau dapatkah sistem secara otomatis menggunakan kontrak aset untuk token yang telah ditransfer tetapi belum digunakan?
  • Apakah alamat kontrak aset ERC-20 di L2 yang sesuai dengan alamatnya di L1? Haruskah alamat tersebut sesuai dengan alamat di L1?
  • Bagaimana token dikeluarkan secara native pada L2 dirantai silang ke L1?
  • Bagaimana token dengan fungsi khusus, seperti token Rebase pasokan yang dapat disesuaikan atau token staking otomatis, lintas rantai?

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:

  • Komponen Gateway muncul berpasangan pada L1 dan L2.
  • Gateway Router bertanggung jawab untuk menjaga pemetaan alamat antara Token L1 <-> Token L2 dan beberapa token <-> beberapa gateway.
  • Gateway itu sendiri dapat dibagi menjadi berbagai jenis, seperti gateway StandardERC20, gateway Generik-khusus, gateway khusus, dll., Untuk mengatasi masalah yang menjembatani berbagai jenis dan fungsi token ERC20.

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:

  • Tidak mungkin untuk membuka WETH menjadi ETH di L2 karena tidak ada ETH yang sesuai untuk mengunci di L2.
  • Fungsi Bungkus dapat digunakan, tetapi jika WETH yang baru dibuat ini disilangkan kembali ke L1, mereka tidak dapat dibuka menjadi ETH di L1 karena kontrak WETH di L1 dan L2 tidak "simetris".

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.

Kotak Masuk Tertunda

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:

  • depositETH(): Fungsi ini adalah metode paling sederhana untuk menyetor ETH.
  • createRetryableTicket(): Fungsi ini dapat digunakan untuk menyimpan ETH, token ERC20, dan pesan. Dibandingkan dengan depositETH(), ia menawarkan fleksibilitas yang lebih besar, seperti menentukan alamat penerima pada L2 setelah deposit.
  • forceInclusion(): Juga dikenal sebagai fungsi penyertaan gaya, yang dapat dipanggil oleh siapa saja. Fungsi ini memverifikasi apakah transaksi yang dikirimkan ke kontrak slow box belum diproses setelah 24 jam. Jika kondisi terpenuhi, fungsi ini akan secara paksa menggabungkan pesan.

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.

Kotak keluar

Outbox hanya terkait dengan penarikan dan dapat dipahami sebagai sistem pencatatan dan manajemen untuk perilaku penarikan:

  • Kita tahu bahwa penarikan di jembatan resmi Arbitrum harus menunggu sekitar 7 hari hingga periode tantangan berakhir, dan penarikan hanya dapat dilakukan setelah Rollup Block selesai. Setelah periode tantangan berakhir, pengguna mengirimkan Merkle Proof yang sesuai ke kontrak Outbox di Layer1, yang kemudian berkomunikasi dengan kontrak untuk fungsi lain (seperti membuka aset yang terkunci dalam kontrak lain), dan akhirnya menyelesaikan penarikan.
  • Kontrak OutBox mencatat pesan lintas rantai L2 ke L1 mana yang telah diproses untuk mencegah seseorang berulang kali mengirimkan permintaan penarikan yang telah dieksekusi. Hal ini dicapai melalui pemetaan yang disebut spent, yang mengaitkan indeks spent permintaan penarikan dengan informasi terkait. Jika mapping[spentIndex] != bytes32(0), ini mengindikasikan bahwa permintaan telah ditarik. Prinsipnya mirip dengan transaction counter nonce, yang digunakan untuk mencegah serangan replay.

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.

Setoran ETH

  1. Pengguna memanggil fungsi depositETH() dari Kotak Masuk Tertunda.
  2. Fungsi ini kemudian memanggil bridge.enqueueDelayedMessage(), yang mencatat pesan dalam kontrak penghubung dan mengirimkan ETH ke kontrak penghubung. Semua dana ETH yang disetorkan disimpan dalam kontrak jembatan, yang bertindak sebagai alamat setoran.
  3. Sequencer memantau pesan setoran di Kotak Masuk Tertunda dan merefleksikan operasi setoran dalam database L2. Pengguna dapat melihat aset yang disimpan di jaringan L2.
  4. Sequencer menyertakan catatan setoran dalam kumpulan transaksi dan mengirimkannya ke kontrak Fast Inbox pada L1.

Penarikan ETH

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

  2. Sequencer mengirimkan permintaan penarikan ke kotak cepat.

  3. Node Validator membuat Rollup Block 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.execute Transaction() pada L1 untuk membuktikan bahwa parameter diberikan oleh kontrak ArbSys yang disebutkan di atas.

  5. Setelah kontrak Outbox dikonfirmasi benar, jumlah ETH yang sesuai di dalam bridge akan dibuka dan dikirimkan kepada pengguna.

Penarikan Cepat

Menggunakan jembatan resmi Rollup yang optimis melibatkan menunggu periode tantangan. Untuk mengatasi masalah ini, kita dapat memanfaatkan jembatan lintas rantai pihak ketiga:

  • Pertukaran Pertukaran Atomik (Atomic Swap Exchange): Dalam pendekatan ini, aset dipertukarkan antara pihak-pihak dalam rantai masing-masing, dan bersifat atomik, yang berarti jika salah satu pihak memberikan preimage, kedua pihak dapat memperoleh aset yang sesuai. Namun, likuiditas relatif langka, sehingga membutuhkan pencarian rekanan secara peer-to-peer.
  • Jembatan Rantai Silang Berbasis Saksi: Sebagian besar jenis jembatan rantai silang termasuk dalam kategori ini. Pengguna mengirimkan permintaan penarikan mereka, dengan menentukan tujuan sebagai operator atau kumpulan likuiditas dari jembatan pihak ketiga. Setelah saksi menemukan bahwa transaksi lintas rantai telah dikirimkan ke kontrak Fast Inbox di L1, mereka dapat langsung mentransfer dana ke pengguna di L1. Pada dasarnya, metode ini menggunakan sistem konsensus lain untuk memonitor Layer 2 dan melakukan operasi berdasarkan data yang dikirimkan ke Layer 1. Namun demikian, tingkat keamanan dalam mode ini lebih rendah dibandingkan dengan jembatan resmi Rollup.

Penarikan paksa

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:

  • Panggil inbox.sendL2Message() dalam kontrak Kotak Masuk Tertunda pada L1, dengan parameter yang diperlukan saat memanggil withdrawEth() pada L2. Pesan ini dibagikan dengan kontrak jembatan pada L1.
  • Setelah menunggu masa tunggu penyertaan paksa selama 24 jam, panggil forceInclusion() dalam kontrak Fast Inbox untuk memaksa penyertaan. Kontrak Kotak Masuk Cepat akan memeriksa apakah ada pesan yang sesuai di jembatan.

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.

Penafian: Penafian

  1. Artikel ini dicetak ulang dari [Geek Web3], Semua hak cipta adalah milik penulis asli[Luo Benben, mantan duta besar teknis Arbitrum, kontributor Geek Web3]]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
  2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
  3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.
Mulai Sekarang
Daftar dan dapatkan Voucher
$100
!