Penulis: Faust, Geek Web3
Di dunia nyata, hampir setiap gedung tinggi memiliki bahan yang sangat diperlukan: pintu keluar yang aman. Ketika keadaan darurat seperti kebakaran dan gempa bumi jatuh, pintu keluar keselamatan adalah penyelamat untuk memastikan keselamatan hidup orang-orang. Dalam sistem platform tahanan Ethereum Layer 2, yang membawa aset puluhan miliar dolar, fungsi “penarikan paksa”, yang memungkinkan pengguna untuk menarik aset dengan aman ke Layer 1, telah menjadi fasilitas yang sangat diperlukan dan diperlukan.
Dalam artikel terbarunya “Berbagai jenis layer 2”, Vitalik juga menekankan bahwa kemampuan pengguna untuk menarik aset dengan lancar dari Layer 2 ke Layer 1 adalah indikator keamanan yang sangat penting.
Namun, masalah “penarikan lancar” tampaknya tidak mendapat banyak perhatian dari kebanyakan orang di masa lalu, dan bahkan banyak proyek Layer 2 belum meluncurkan fungsi “penarikan paksa” atau “escape pod”. Di era ketika ekosistem L2 tidak berjalan lancar, mengabaikan “penarikan tanpa izin” tampaknya tidak menjadi masalah. Tapi sekarang Layer 2 memiliki aset lebih dari $ 12 miliar, itu telah menjadi bangunan yang “terlalu besar untuk gagal”. Jika gedung pencakar langit seperti itu tidak memiliki jalan keluar yang aman, konsekuensinya tidak terbayangkan.
Dengan tujuan membuat pembaca memperhatikan risiko keamanan Layer 2, “Geek Web3” akan mengambil Loopring Protocol V3 dan Arbitrum sebagai contoh di bawah ini untuk menjelaskan mengapa “fungsi penarikan tanpa izin” seperti penarikan paksa dan escape hatch adalah bagian tak terpisahkan dari Layer 2.
(Menurut browser L2BEAT dYdX, fungsi transaksi/penarikan paksa dYdX telah digunakan 152 kali sejauh ini, dan telah terjadi 7 penarikan besar lebih dari $1 juta.)
Perlawanan Sensor adalah Masalah Besar: Apa yang Harus Dilakukan Jika Sequencer Sengaja Menolak Permintaan Anda ****
Di masa lalu, artikel sains populer tentang Layer 2 sering memiliki masalah, yaitu, sebagian besar waktu mereka berfokus pada “keamanan” dan “kegunaan” di permukaan, tetapi mengabaikan “resistensi sensor”. Bahkan ketika berbicara tentang solusi sequencer terdesentralisasi, banyak orang memperhatikan apakah MEV terdesentralisasi, bukan resistensi sensor.
Dengan kata lain, kebanyakan orang cenderung fokus pada apakah transisi status Layer 2 valid, apakah sequencer dapat mencuri koin, dan apakah sistem bukti validitas penipuan / validitas sedang digunakan, tetapi mereka mengabaikan risiko yang tidak boleh diabaikan: bagaimana jika Sequencer terus menolak permintaan transaksi Anda, atau gagal untuk waktu yang lama, atau bahkan turun? **
Anda tahu, selama pemadaman Solana, ada orang yang tidak dapat menutupi posisi mereka tepat waktu karena aset mereka menghadapi likuidasi, membahayakan aset jutaan dolar. **Setelah penolakan permintaan pengguna terjadi, kerugian ekonomi yang ditimbulkan tidak dapat diabaikan.
Bahkan jika hanya beberapa orang yang bisa berada dalam situasi ini, jika jatuh pada paus dengan banyak uang, seluruh pasar bisa menderita (katakanlah seseorang memiliki aset ratusan juta dolar pada protokol pinjaman Defi di Ethereum yang dapat dilikuidasi dalam seminggu, tetapi dia ada dalam daftar sanksi OFAC karena menggunakan Tornado). Sebagian besar dana orang ini ada di OP, dan sequencer OP bekerja dengan OFAC untuk menolak permintaannya)
Kami mungkin juga memproyeksikan masalah ini ke rantai publik seperti longsoran salju atau poligon, yang tidak bergantung pada Ethereum. Jika lebih dari 2/3 node konsensus validator di Avalanche memutuskan untuk menyensor transaksi Anda, mereka dapat menolak untuk memasukkan Txn Anda ke dalam blok, atau tidak mengenali blok yang berisi Txn Anda. Saat ini, uang Anda pada dasarnya terkubur dalam rantai ini dan tidak bisa keluar: **
Kecuali Anda dapat mengkooptasi beberapa validator sehingga kurang dari 2/3 validator terlibat dalam serangan sensor, atau Anda dapat meminta beberapa orang untuk melakukan fork Avalanche melalui konsensus sosial. Jelas, pada titik ini, Anda masih memiliki cara untuk menarik dana dengan cepat dari Avalanche, dan kami harus mempertimbangkan bahwa lebih dari 2/3 Validator bergabung untuk memulai peninjauan transaksi terhadap alamat tertentu, yang dengan sendirinya membutuhkan waktu untuk dicapai, yang akan menyisakan cukup waktu bagi pengguna yang disensor untuk “melarikan diri”.
Tetapi pada Layer 2, situasinya bisa sangat berbeda. Layer 2 Sequencer umumnya dijalankan oleh pejabat itu sendiri, dan jika Sequencer ingin meluncurkan serangan sensor pada Anda, ia dapat “membekukan uang Anda di Layer 2”, yaitu, sepenuhnya menolak permintaan transaksi Anda untuk melintasi aset dari L2 ke L1. Jelas, menurut mekanisme operasi L2, jika Anda tidak dapat melewati sequencer untuk melakukan operasi penarikan, sangat mungkin bahwa Sequencer akan membekukan aset di L2 dan tidak dapat ditransfer.
Jadi bagaimana cara mengatasi masalah seperti ini? Bahkan, terus terang, bagaimana menerapkan fungsi penarikan “tanpa izin”, sehingga pengguna dapat menarik aset mereka ke Layer 1 tanpa membahayakan ketika mereka ditinjau oleh Sequencer atau pihak proyek Layer 2? Ada beberapa proyek yang telah mengusulkan Sequencer terdesentralisasi, tetapi ini bukan solusi paliatif, dan jika jumlah sequencer yang sangat terbatas bergabung untuk meninjau Anda, Anda masih dapat “membekukan” aset Anda, dan anti-penyihir node POS juga merupakan masalah rumit (lihat Peristiwa multichain).
Cara paling efektif untuk melakukan ini adalah dengan mengatur “keluar” langsung di rantai L1, memungkinkan pengguna untuk menarik dana dari L2 melalui pintu keluar khusus di L1 jika mereka tidak mendapatkan respons dari Sequencer untuk waktu yang lama. **
Protokol Loopring V3 Penarikan Paksa dan Model Likuidasi Kebangkrutan
Di sini kita mengambil versi V3 dari protokol Loopring sebagai contoh, yang mencantumkan dua skenario berbeda untuk penarikan paksa yang dimulai pengguna, kasus pertama adalah:
Pengguna dapat memulai penarikan paksa langsung pada Layer 1 melalui fungsi forcedWithdraw dalam kontrak ExchangeV3, dan menyatakan akun L2 mana yang mereka miliki dalam protokol Loopring dan jenis token apa yang ingin mereka tarik. Setelah itu, kontrak ExchangeV3 melempar acara on-chain untuk menunjukkan bahwa seseorang telah memulai permintaan penarikan paksa. Karena semua node protokol Loopring (termasuk Sequencer) menjalankan klien Geth, diketahui dari blok Ethereum bahwa seseorang memulai penarikan paksa dan memicu peristiwa on-chain yang sesuai.
Penting untuk dicatat bahwa penarikan paksa tidak segera diproses, tetapi ditempatkan dalam antrian pendingForcedWithdrawals dan tertunda. **Sequencer memperhatikan bahwa setelah seseorang memulai penarikan paksa di Layer 1, fungsi Proses dalam kontrak ExchangeV3 dipicu dalam waktu 15 hari untuk mentransfer token ke inisiator penarikan pada rantai Ethereum (dari alamat setoran pihak proyek L2 pada rantai Ethereum untuk mentransfer uang ke penarikan).
Jika Sequencer tidak menanggapi permintaan penarikan paksa pengguna dalam waktu 15 hari, pengguna dapat memanggil fungsi notifyForcedRequestTooOld agar kontrak ExchangeV3 mengadakan acara yang disebut WithdrawalModeActivated untuk memberi tahu simpul penuh protokol Loopring bahwa mode likuidasi kebangkrutan diaktifkan. **
**Jika mode likuidasi diaktifkan, Loopring V3 akan berhenti menerima blok L2 baru yang dikirimkan oleh Sequencer, yang berarti seluruh protokol Loopring akan berhenti bekerja. Proses ini berlangsung setidaknya 30 hari.
Namun, dalam mode likuidasi kebangkrutan, pengguna masih dapat menarik aset mereka di Layer 1, tetapi mereka perlu menyerahkan bukti merkle untuk membuktikan status/status aset mereka, yang dapat diperiksa pada pohon status L2. (Buktikan bahwa saldo aset Anda di Lapisan 2 konsisten dengan jumlah yang Anda nyatakan saat memulai penarikan)
Model likuidasi kebangkrutan dari Protokol Loopring ini juga dikenal sebagai mekanisme Escape Hatch pada L2BEAT. Mode ini dipicu pada prasyarat untuk sequencer yang tidak menanggapi permintaan penarikan paksa pengguna dalam waktu yang ditentukan, atau jika sequencer mengalami kegagalan atau waktu henti jangka panjang. Pada saat ini, pengguna dapat secara manual memicu kontrak Rollup ke mode beku/berhenti berjalan. Kemudian, pengguna dapat membuat bukti merkle untuk membuktikan aset mereka pada Layer 2, dan menarik aset mereka sendiri dari alamat deposit pihak proyek L2 di L1. **
Dalam dokumentasi StarkEx, diagram skematik khusus dari proses ini juga digambar. Jika pengguna L2 tidak menerima respons sequencer pada akhir jendela 7 hari ketika pengguna L2 mengajukan permintaan penarikan paksa pada L1, pengguna L2 dapat memanggil fungsi permintaan pembekuan untuk menyebabkan L2 memasuki periode pembekuan. Dalam hal ini, sequencer L2 tidak akan dapat memperbarui status L2 pada L1, dan akan memakan waktu 1 tahun setelah status L2 dibekukan untuk dibekukan. Setelah itu, pengguna dapat mengirimkan Bukti Merkle dan menarik uang.
Namun, untuk membangun Merkle Proof, Anda perlu mengetahui pohon status L2 lengkap terlebih dahulu, yaitu, Anda perlu menemukan node penuh L2 untuk meminta data, dan pada saat yang sama, Anda memerlukan sepotong kode untuk menghasilkan merkle Proof, yang jelas membutuhkan ambang teknis tertentu. Untuk kenyamanan sebagian besar pengguna, L2BEAT sebelumnya telah menyatakan bahwa Layer 2 harus menyiapkan sejumlah node penuh dengan izin terbuka dan kode sumber terbuka untuk membantu pengguna mengetahui status semua akun di L2 (termasuk saldo, jumlah transaksi, dll.). Langkah ini juga menggambarkan pentingnya penarikan wajib dan mekanisme escape pod.
Fitur “Forced Include Transactions” Arbitrum
Tetapi penarikan paksa / pod pelarian tampaknya bukan satu-satunya solusi yang tahan sensor. Misalnya, Arbitrum menggunakan metode “memaksa penyertaan transaksi”, pengguna dapat terlebih dahulu mengirimkan Txn/penarikan yang perlu diproses oleh Sequencer dalam kontrak Kotak Masuk tertunda di L1, dan jika Sequencer belum memprosesnya selama lebih dari 24 jam, pengguna dapat memanggil fungsi Inklusi paksa dari kontrak Kotak Masuk Sequencer di L1. Biarkan Txn dimasukkan langsung ke dalam urutan transaksi Arbitrum** (lemparkan acara on-chain untuk memberi tahu node penuh Arbitrum bahwa Txn dengan beberapa catatan kotak masuk yang tertunda perlu dimasukkan dalam buku besar L2).
Sebaliknya, pendekatan Arbitrum lebih sederhana, tetapi masih agak kurang: itu hanya melempar acara on-chain yang memberi tahu node Arbitrum bahwa ada beberapa transaksi yang diabaikan sequencer yang perlu dimasukkan dalam rantai terpanjang L2, daripada memungkinkan pengguna untuk menarik uang langsung di L1 seperti yang dilakukan Loopring Protocol dan mode kebangkrutan StarkEx/pod melarikan diri. Jika node penantang Arbitrum bersatu untuk meluncurkan serangan sensor, tampaknya masih mungkin untuk membekukan uang pengguna di L2. **
Jadi force Inclusion Arbitrum tidak cukup tanpa izin, dan meskipun akan menyenangkan untuk mengatakan bahwa sequencer mengabaikan permintaan forceInclusion pengguna selama ada node jujur yang bersedia memposting bukti penipuan, ini masih memperkenalkan tingkat asumsi kepercayaan tertentu, meskipun pada tingkat lebih rendah.
Lebih tepatnya, “transaksi yang perlu dimasukkan secara wajib” harus diakui oleh setidaknya satu node penantang ARB, yang saat ini memiliki 9 node yang memiliki hak untuk memutuskan pesan lintas rantai L2-L1 mana yang diizinkan, dan sekarang hanya mereka yang dapat mengeluarkan bukti penipuan. **Selama 9 node ini berkolusi bersama, secara teoritis “transaksi paksa” pengguna masih dapat dibatalkan. **
Oleh karena itu, penyertaan wajib transaksi/penarikan saat ini di Arbitrum tidak seperti model likuidasi kebangkrutan Loopring dan StarkEx yang tidak memerlukan izin node L2. Namun, L2BEAT masih memberi Arbitrum peringkat tinggi untuk solusi ini. Karena di masa depan, Arbitrum akan meluncurkan mekanisme pelepasan bukti penipuan Tanpa Izin yang disebut BOLD, dan akan sulit atau tidak mungkin bagi node penantang untuk berkolusi pada saat itu (sebenarnya sulit untuk berkolusi sekarang).
Menurut L2BEAT, TVL saat ini lebih dari $ 50 juta, dan tidak ada tanggapan terhadap Kegagalan Sequencer atau Kegagalan Pengusul: **OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM, Metis. L2 ini dapat menyebabkan aset pengguna dibekukan di L2 dalam kasus ekstrim. **
Jadi jelas, model penarikan paksa atau likuidasi kebangkrutan memiliki kebutuhannya, meskipun saat ini hanya mengandalkan sequencer pengguna sebagai permainan counterparty untuk berfungsi, ** tidak benar-benar “siap untuk menarik” ** (Arbitrum memiliki penundaan 24 jam dan dapat gagal, Loopring memiliki penundaan maksimum 15 hari, StarkEx memiliki penundaan maksimum 7 hari), tetapi jelas bahwa “sesuatu lebih baik daripada tidak sama sekali”. Selain itu, masalah keterlambatan penarikan paksa diyakini dapat diselesaikan dengan benar di masa depan dengan desain mekanisme yang lebih canggih ** (saat ini, ini terutama disebabkan oleh fakta bahwa beberapa ilmuwan MEV dapat menggunakan forceInclusion untuk memulai transaksi front-running, sehingga perlu untuk memperkenalkan penundaan.) Untuk lebih jelasnya, silakan merujuk ke dokumen resmi dari pihak-pihak proyek L2 utama).
Dengan dimasukkannya Sequencer terdesentralisasi dalam semakin banyak peta jalan L2, dan Yayasan Ethereum yang dipimpin oleh Vitalik terus mendidik orang-orang tentang keamanan Layer 2, fitur transaksi yang tahan sensor seperti penarikan paksa pasti akan semakin diperhatikan, yang akan membuat sistem Ethereum Layer2 lebih dekat ke sistem infrastruktur keuangan yang tahan sensor dan tidak dapat dipercaya. Jika Layer 2 menerapkan akses tanpa kepercayaan ke dana, diyakini bahwa lebih banyak pembuat pasar dan penyedia likuiditas akan memasuki infrastruktur L2, dan adopsi massal seluruh web3 akan didorong selangkah lebih maju.
