Escape Hatch

Apa Itu Escape Hatch dalam Kripto?

Escape hatch adalah mekanisme cadangan yang memungkinkan pengguna kripto, administrator, atau sistem otomatis memulihkan aset atau keluar dari protokol ketika jalur operasional normal tidak tersedia atau tidak aman.

Mekanisme ini dirancang untuk kondisi luar biasa seperti aplikasi yang membeku, operator yang tidak tersedia, sequencer yang melakukan sensor, kerentanan smart contract serius, kegagalan tata kelola, atau gangguan layanan berkepanjangan.

Dalam smart contract, escape hatch dapat memungkinkan pengguna menarik aset yang telah disetorkan setelah status darurat atau timeout diaktifkan.

Dalam sistem Layer 2, escape hatch dapat memungkinkan pengguna membuktikan kepemilikan dan menarik aset melalui kontrak Layer 1 tanpa bergantung pada operator Layer 2 yang biasanya digunakan.

Dalam pengaturan wallet atau kustodi, istilah ini dapat merujuk pada jalur pemulihan yang melibatkan kunci cadangan, beberapa tanda tangan, transaksi tertunda, atau alamat pemulihan yang ditentukan.

Dokumentasi Layer 2 Ethereum menggunakan istilah escape hatch untuk menjelaskan kemampuan pemulihan yang memungkinkan pengguna menarik aset melalui kontrak Layer 1 sekalipun sistem Layer 2 gagal.

Istilah ini tidak merujuk pada satu standar smart contract yang universal.

Makna tepatnya bergantung pada protokol, aset, model otorisasi, blockchain, dan skenario kegagalan yang terlibat.

Mengapa Protokol Kripto Memerlukan Escape Hatch

Aplikasi kripto dapat menahan aset di dalam smart contract dalam waktu lama.

Pengguna mungkin tidak dapat memulihkan aset tersebut jika fungsi penarikan normal bergantung pada server yang gagal, penanda tangan yang tidak tersedia, oracle yang rusak, administrator yang disusupi, atau sequencer yang tidak aktif.

Kode yang tidak dapat diubah juga dapat membuat kesalahan sulit diperbaiki setelah deployment.

Escape hatch menyediakan jalur pemulihan yang direncanakan sebelum keadaan darurat terjadi.

Mekanisme ini dapat menjaga liveness dengan memastikan pengguna tetap memiliki cara untuk keluar dari sistem.

Mekanisme ini juga dapat melindungi dana dengan menghentikan operasi yang rentan sementara penarikan berlanjut melalui jalur yang lebih aman.

Mekanisme yang dirancang dengan baik mengurangi ketergantungan pada janji bahwa tim akan selalu tersedia.

Mekanisme yang dirancang buruk dapat menjadi backdoor yang kuat dan memungkinkan akun dengan hak istimewa menyita atau mengalihkan aset pengguna.

Nilai keamanan escape hatch bergantung pada pihak yang dapat mengaktifkannya, tindakan yang dapat dilakukannya, dan kemampuan pengguna memverifikasi aturannya secara on-chain.

Makna Escape Hatch yang Umum

Escape hatch dapat menggambarkan beberapa mekanisme kripto yang saling berkaitan, tetapi berbeda.

Fungsi penarikan darurat memungkinkan pengguna menarik aset mereka sendiri ketika operasi protokol normal dijeda.

Forced exit memungkinkan pengguna Layer 2 menarik aset melalui bridge Layer 1 ketika operator Layer 2 menolak atau gagal memproses permintaan.

Pengembalian dana berbatas waktu mengembalikan dana terkunci setelah pihak lain gagal menyelesaikan tindakan sebelum tenggat waktu.

Kunci pemulihan memungkinkan pemilik wallet mendapatkan kembali kendali setelah kehilangan kunci penandatanganan rutin.

Upgrade darurat memungkinkan tata kelola yang berwenang mengganti logika kontrak yang rentan.

Proses penghentian menutup protokol secara tertib dan mendistribusikan sisa aset sesuai aturan yang telah ditentukan.

Circuit breaker membatasi atau menjeda aktivitas ketika harga, saldo, atau volume transaksi bergerak melampaui kondisi yang diperkirakan.

Semua mekanisme ini dapat disebut escape hatch, tetapi masing-masing menimbulkan asumsi kepercayaan dan konsekuensi keamanan yang berbeda.

Escape Hatch Smart Contract

Escape hatch smart contract adalah fungsi atau sekumpulan fungsi yang tersedia saat protokol berada dalam kondisi abnormal.

Kontrak dapat beralih dari operasi normal ke status darurat, jeda, penyelesaian, atau hanya-penarikan.

Aktivitas berisiko seperti deposit baru, peminjaman, trading, minting, atau leverage dapat dinonaktifkan.

Pengguna mungkin tetap diizinkan menarik aset yang menurut catatan kontrak menjadi milik mereka.

Kontrak harus menentukan saldo yang dapat ditarik dan cara penghitungannya.

Jalur darurat sebaiknya tidak bergantung pada komponen yang menyebabkan kegagalan.

Misalnya, kegagalan oracle seharusnya tidak menghalangi pengguna menarik aset jika jumlah penarikan dapat ditentukan tanpa oracle.

Escape hatch smart contract tidak dapat mengatasi setiap situasi karena akuntansi yang rusak atau aset yang dicuri dapat membuat dana tidak cukup untuk penarikan penuh.

Escape Hatch Layer 2

Escape hatch Layer 2 adalah metode untuk memulihkan aset melalui lapisan penyelesaian yang mendasarinya ketika pemrosesan Layer 2 normal gagal.

Sistem Layer 2 umumnya menggunakan operator atau sequencer untuk mengurutkan transaksi dan memberikan konfirmasi cepat.

Jika operator tersebut tidak tersedia atau menyensor pengguna, permintaan penarikan normal mungkin tidak diproses.

Escape hatch yang kuat memberi pengguna jalur alternatif melalui bridge Layer 1 atau kontrak penyelesaian.

Pengguna dapat mengirim transaksi, bukti status, bukti penarikan, atau permintaan penyertaan paksa langsung ke Layer 1.

Panduan pemulihan rollup Ethereum menjelaskan bahwa publikasi data transaksi ke Layer 1 dapat membuat aset tetap dapat dipulihkan sekalipun operator Layer 2 menghilang.

Escape hatch sangat penting ketika satu operator dapat mengendalikan sementara urutan transaksi.

Tanpa jalur forced exit, saldo pengguna dapat tetap terdampar meskipun aset yang mendasarinya masih ada di kontrak bridge.

Cara Kerja Forced Exit Layer 2

Forced exit biasanya dimulai ketika pengguna tidak dapat menyelesaikan penarikan Layer 2 biasa.

Pengguna memperoleh informasi status yang diperlukan untuk membuktikan saldo atau kepemilikan akun.

Pengguna kemudian mengirim permintaan atau bukti yang diperlukan ke kontrak Layer 1.

Kontrak memverifikasi bukti tersebut terhadap komitmen status Layer 2 yang diterima.

Jika bukti dan persyaratan penarikan valid, kontrak mengotorisasi pelepasan aset Layer 1 terkait.

Beberapa sistem mewajibkan masa tunggu atau masa tantangan sebelum penarikan menjadi final.

Sistem lain menggunakan validity proof yang memungkinkan kontrak memverifikasi transisi status yang diterima secara kriptografis.

Proses tepatnya bergantung pada desain Layer 2 dan mungkin memerlukan software khusus yang tidak tersedia di antarmuka wallet biasa.

Escape hatch teoretis kurang bermanfaat jika pengguna tidak dapat memperoleh data yang diperlukan atau membuat bukti yang dibutuhkan saat darurat.

Ketersediaan Data dan Escape Hatch

Ketersediaan data sangat penting karena pengguna memerlukan informasi yang cukup untuk merekonstruksi saldo dan membuktikan penarikan yang valid.

Komitmen status saja mungkin menunjukkan bahwa suatu status ada, tetapi tidak mengungkap data yang diperlukan untuk membuktikan posisi pengguna tertentu.

Jika data transaksi dan status yang diperlukan tersedia secara andal di Layer 1, software independen dapat merekonstruksi status Layer 2.

Hal ini memungkinkan upaya pemulihan berlanjut tanpa kerja sama operator awal.

Panduan forced exit Ethereum memperingatkan bahwa pengguna dapat terdampar ketika sequencer terpusat dapat memblokir transaksi dan tidak tersedia jalur penarikan paksa Layer 1.

Sistem yang menyimpan data penting di tempat lain dapat menimbulkan ketergantungan tambahan pada ketersediaan.

Jika sumber data eksternal tersebut menghilang, kontrak bridge mungkin tetap memiliki dana sementara pengguna tidak dapat membuat bukti exit yang valid.

Escape Hatch vs. Penarikan Normal

Penarikan normal merupakan bagian dari operasi harian protokol yang diharapkan.

Biasanya, proses ini bergantung pada kontrak, antarmuka, operator, proses akuntansi, dan sistem pesan standar aplikasi.

Escape hatch adalah jalur cadangan untuk kondisi abnormal.

Jalur ini mungkin memerlukan penundaan lebih lama, bukti tambahan, biaya gas lebih tinggi, atau antarmuka pengguna yang berbeda.

Jalur normal dapat memberikan penyelesaian lebih cepat dan pengalaman pengguna yang lebih sederhana.

Jalur darurat memprioritaskan kemampuan pemulihan ketika layanan normal tidak tersedia.

Protokol sebaiknya mendokumentasikan kedua jalur agar pengguna memahami bahwa kecepatan penarikan biasa belum tentu mencerminkan waktu pemulihan darurat.

Escape Hatch vs. Fungsi Jeda

Fungsi jeda menghentikan aktivitas kontrak tertentu, sedangkan escape hatch menyediakan jalur keluar dari sistem.

Jeda dapat mencegah kerentanan aktif menimbulkan kerugian tambahan.

Jeda yang memblokir semua penarikan juga dapat menjebak pengguna dan membuat mereka bergantung pada administrator yang mengendalikan fungsi jeda.

Desain yang lebih aman dapat menjeda deposit baru dan tindakan berisiko tinggi sambil mempertahankan penarikan terbatas.

Pihak yang memiliki wewenang untuk menjeda harus diidentifikasi dengan jelas dan dilindungi melalui kontrol akses yang kuat.

Protokol juga harus menjelaskan cara keluar dari status jeda dan apa yang terjadi jika akun berwenang tidak tersedia.

Tombol jeda tanpa jalur pemulihan bukanlah escape hatch yang lengkap.

Escape Hatch vs. Circuit Breaker

Circuit breaker membatasi aktivitas secara otomatis atau manual setelah kondisi risiko tertentu muncul.

Mekanisme ini dapat membatasi penarikan, menghentikan peminjaman, membatasi ukuran transaksi, atau menonaktifkan pasar tertentu.

Escape hatch lebih berfokus pada kemampuan pengguna atau protokol untuk pulih dari kegagalan.

Kedua mekanisme dapat digunakan bersama.

Circuit breaker dapat lebih dulu menghentikan aktivitas yang tidak aman, kemudian proses penarikan darurat memungkinkan pengguna keluar.

Ambang batas yang keliru dapat membuat circuit breaker aktif saat volatilitas pasar normal atau gagal aktif saat keadaan darurat sungguhan.

Karena itu, kondisi otomatis harus diuji dengan insiden nyata dan skenario ekstrem yang disimulasikan.

Escape Hatch vs. Upgrade Kontrak

Upgrade kontrak mengubah kode yang digunakan aplikasi, sedangkan escape hatch dapat memungkinkan pengguna menarik dana tanpa memperbaiki aplikasi.

Upgrade darurat dapat menghapus kerentanan dan memulihkan operasi normal.

Upgrade juga memberikan kewenangan besar kepada pihak yang mengendalikan mekanismenya.

Otoritas upgrade yang berbahaya atau disusupi dapat memasang kode yang mengalihkan dana atau mengubah aturan penarikan.

Escape hatch dapat menyediakan alternatif bagi pengguna yang tidak ingin memercayai upgrade yang diusulkan.

Upgrade yang ditunda dapat memberi pengguna kesempatan meninjau perubahan dan keluar sebelum perubahan berlaku.

Panduan kontrol akses smart contract terkini menjelaskan bahwa operasi yang ditunda dapat memberi pengguna waktu untuk meninjau tindakan pemeliharaan dan keluar dari sistem sebelum tindakan dijalankan.

Escape Hatch yang Dikendalikan Pengguna

Escape hatch yang dikendalikan pengguna memungkinkan setiap pengguna memulihkan aset mereka yang memenuhi syarat tanpa persetujuan administrator.

Desain ini mengurangi ketergantungan pada ketersediaan tim, perusahaan, atau kelompok tata kelola.

Kontrak harus memverifikasi bahwa pemanggil berhak atas aset yang diminta.

Bukti dapat bergantung pada saldo yang tersimpan, komitmen kriptografis, tanda tangan, Merkle proof, atau data status final.

Pengguna tidak boleh dapat menarik saldo akun lain atau menggunakan bukti yang sama lebih dari sekali.

Nonce, nullifier, catatan penarikan, atau pembaruan status dapat mencegah klaim berulang.

Pemulihan yang dikendalikan pengguna umumnya lebih kuat jika siapa pun dapat mengirim transaksi dan hasilnya hanya bergantung pada aturan protokol publik.

Escape Hatch yang Dikendalikan Administrator

Escape hatch yang dikendalikan administrator memungkinkan akun istimewa mengaktifkan fungsi darurat atau memindahkan aset.

Pendekatan ini dapat merespons insiden kompleks dengan cepat ketika dibutuhkan pertimbangan khusus.

Pendekatan ini juga dapat menimbulkan risiko penyitaan atau sensor terpusat.

Kontrak sebaiknya membatasi administrator pada kewenangan minimum yang diperlukan untuk keadaan darurat.

Contohnya, administrator dapat diizinkan menjeda deposit tanpa diizinkan memindahkan saldo pengguna ke alamat sewenang-wenang.

Peran terpisah dapat diberikan untuk menjeda, meng-upgrade, menarik aset milik protokol, dan menyelesaikan klaim pengguna.

Perubahan peran dan tindakan darurat sebaiknya menghasilkan log peristiwa agar sistem pemantauan dapat mendeteksinya.

Pengguna sebaiknya meninjau izin on-chain yang sebenarnya, bukan hanya mengandalkan klaim bahwa administrator tidak dapat mengakses dana.

Kontrol Darurat Multisignature

Pengaturan multisignature memerlukan persetujuan dari beberapa kunci berwenang sebelum tindakan darurat dapat dilakukan.

Hal ini mengurangi risiko satu kunci yang dicuri dapat mengaktifkan escape hatch atau mengalihkan aset.

Manfaat keamanannya bergantung pada independensi para penanda tangan.

Beberapa kunci yang dipegang satu orang, disimpan di satu lokasi, atau dikelola melalui satu layanan dapat mengalami kegagalan bersamaan.

Ambang tanda tangan harus menyeimbangkan kecepatan respons darurat dengan perlindungan terhadap kolusi atau kompromi.

Sistem harus menentukan tindakan yang dilakukan jika terlalu banyak penanda tangan kehilangan akses ke kunci mereka.

Desain multisignature tetap dapat rentan jika para penanda tangan menyetujui transaksi berbahaya tanpa memahami dampak sepenuhnya.

Time Lock dan Jendela untuk Keluar

Time lock menunda tindakan sensitif setelah diumumkan secara on-chain.

Penundaan tersebut memberi pengguna, developer, auditor, dan layanan pemantauan waktu untuk memeriksa perubahan yang diusulkan.

Pengguna yang menolak perubahan mungkin dapat menarik aset sebelum perubahan berlaku.

Jendela untuk keluar hanya bermanfaat jika penarikan tetap tersedia dan ada cukup waktu untuk menyelesaikannya.

Penundaan singkat dapat menjadi tidak efektif saat jaringan padat atau banyak pengguna mencoba keluar bersamaan.

Penundaan yang terlalu lama dapat menghambat perbaikan kerentanan mendesak.

Beberapa sistem menggunakan prosedur terpisah untuk upgrade biasa dan tindakan darurat.

Kemampuan melewati time lock saat darurat harus diperlakukan sebagai hak istimewa besar dan diungkapkan dengan jelas.

Escape Hatch Otomatis

Escape hatch otomatis aktif ketika kondisi yang telah ditentukan terpenuhi.

Pemicu yang mungkin mencakup tenggat pembaruan yang terlewat, operator yang tidak tersedia, masa tantangan yang berakhir, feed harga yang gagal, atau ketidakseimbangan akuntansi.

Aktivasi otomatis dapat mengurangi ketergantungan pada administrator manusia untuk mengenali dan merespons masalah.

Pemicu harus dapat diukur melalui data yang bisa diverifikasi kontrak.

Oracle yang tidak andal dapat mengaktifkan atau mencegah mekanisme secara keliru.

Penyerang juga dapat mencoba memanipulasi kondisi pemicu jika aktivasi memberikan keuntungan finansial.

Logika pemulihan otomatis harus menentukan cara sistem kembali beroperasi normal setelah insiden berakhir.

Mode Hanya-Penarikan

Mode hanya-penarikan menonaktifkan pengambilan risiko baru sambil mengizinkan pengguna menarik aset yang didukung.

Sistem dapat menolak deposit baru, pinjaman, trading, penerbitan token, atau penambahan posisi.

Pengguna yang sudah ada dapat mengurangi eksposur atau menarik aset sesuai aturan akuntansi yang masih berlaku.

Mode ini dapat mendukung penghentian tertib atau memberi waktu untuk menyelidiki kerentanan.

Protokol harus menentukan penanganan pinjaman terbuka, posisi leverage, trading tertunda, biaya yang belum diselesaikan, dan aset yang tidak dapat ditransfer secara normal.

Status hanya-penarikan tidak menjamin pemulihan penuh jika protokol sudah mengalami kekurangan agunan.

Pengguna sebaiknya memahami apakah penarikan diproses secara proporsional, berdasarkan urutan permintaan, atau dengan aturan alokasi lain.

Penarikan Darurat Berbasis Pull

Desain berbasis pull mencatat jumlah yang dapat diklaim setiap pengguna dan mengharuskan pengguna mengirim transaksi penarikan terpisah.

Desain ini menghindari pengiriman aset kepada semua pengguna dalam satu transaksi besar.

Desain ini juga mencegah transfer yang gagal ke satu penerima menghambat pembayaran kepada semua pihak lainnya.

Panduan pola penarikan Solidity merekomendasikan pembaruan saldo tertunda pengguna sebelum melakukan transfer eksternal.

Kontrak harus menandai jumlah sebagai telah diklaim sebelum memanggil penerima untuk mengurangi risiko reentrancy.

Pengguna harus memiliki cukup mata uang asli blockchain untuk membayar biaya transaksi yang diperlukan guna mengklaim aset.

Protokol mungkin perlu menyediakan metode yang didukung bagi pengguna yang tidak dapat mengakses antarmuka aplikasi normal.

Risiko Penanganan Token

Escape hatch harus menangani perilaku aktual setiap token yang didukung.

Beberapa token mengenakan biaya transfer, mengubah saldo secara otomatis, memblokir alamat tertentu, menjeda transfer, atau memberikan nilai balik yang tidak lazim dari pemanggilan kontrak.

Penerbit token dapat membekukan kontrak escrow atau pemulihan meskipun logika escape hatch benar.

Saldo token rebasing dapat berubah tanpa transfer langsung.

Token dengan callback transfer dapat menjalankan kode eksternal selama penarikan.

Kontrak harus mengukur aset dengan cermat dan tidak berasumsi bahwa semua token mengikuti model saldo tetap yang sederhana.

Pengujian darurat harus mencakup perilaku token yang tidak lazim dan transfer yang gagal.

Reentrancy dan Panggilan Eksternal

Fungsi penarikan darurat dapat rentan terhadap reentrancy jika mentransfer aset sebelum memperbarui klaim pengguna yang tercatat.

Kontrak penerima yang berbahaya dapat memanggil fungsi penarikan lagi selama transfer pertama berlangsung.

Protokol harus memperbarui akuntansi internal sebelum melakukan panggilan eksternal.

Protokol juga dapat menggunakan pengaman reentrancy dan fungsi penarikan dengan cakupan terbatas.

Dokumentasi keamanan Solidity menjelaskan bahwa panggilan eksternal dapat memberikan kendali kepada kontrak lain sehingga harus ditangani dengan cermat.

Escape hatch tidak boleh menimbulkan kerentanan baru saat berupaya mengatasi kerentanan yang sudah ada.

Oracle Harga dan Penyelesaian Darurat

Protokol pinjaman atau derivatif mungkin memerlukan harga aset untuk menentukan klaim akhir setiap pengguna.

Jika oracle harga adalah komponen yang gagal, penggunaan harga terakhir yang dilaporkan dapat menghasilkan penyelesaian yang tidak adil atau tidak aman.

Escape hatch dapat menggunakan harga tertunda, proses referensi terpisah, harga penyelesaian yang disetujui tata kelola, atau aturan cadangan yang telah ditentukan.

Setiap alternatif menimbulkan kompromi terkait manipulasi, penundaan, dan diskresi.

Protokol harus menetapkan metode valuasi darurat sebelum insiden terjadi.

Mengubah aturan setelah kerugian terlihat dapat menguntungkan satu kelompok pengguna dengan merugikan kelompok lainnya.

Insolvensi dan Pemulihan Proporsional

Escape hatch tidak dapat mendistribusikan aset melebihi jumlah yang dikendalikan sistem.

Jika aset dicuri, hilang, dibekukan, atau digunakan untuk menutup utang macet, protokol dapat menjadi insolven.

Memproses penarikan berdasarkan urutan kedatangan dapat membuat pengguna awal menerima nilai penuh sementara pengguna berikutnya tidak menerima apa pun.

Penyelesaian proporsional dapat mendistribusikan aset yang tersisa berdasarkan klaim yang tercatat.

Pendekatan ini mungkin mengharuskan sistem menghentikan penarikan biasa saat saldo dihitung.

Klaim yang disengketakan dan perubahan nilai aset dapat menyulitkan penghitungan.

Pengguna sebaiknya membedakan escape hatch yang menjamin akses teknis dari mekanisme yang menjamin pengembalian dana sepenuhnya.

Tata Kelola dan Escape Hatch

Tata kelola dapat mengendalikan kapan mode darurat dimulai, cara memilih aturan penyelesaian, dan waktu operasi normal dilanjutkan.

Voting token dapat memberi partisipasi yang lebih luas, tetapi mungkin lambat saat eksploit sedang berlangsung.

Komite yang didelegasikan atau kelompok multisignature dapat merespons lebih cepat, tetapi menimbulkan asumsi kepercayaan yang lebih besar.

Penyerang tata kelola dapat mencoba mengaktifkan escape hatch demi keuntungan pribadi.

Kekuatan voting yang dipinjam atau diperoleh sementara juga dapat memengaruhi proposal darurat yang dirancang buruk.

Perubahan tata kelola yang penting mungkin memerlukan aturan kuorum, penundaan voting, time lock eksekusi, dan kewenangan yang dibatasi dengan jelas.

Tata kelola darurat harus diuji secermat fungsi smart contract biasa.

Safety vs. Liveness

Safety berarti mencegah perpindahan aset yang tidak valid atau tanpa izin.

Liveness berarti memastikan pengguna yang sah pada akhirnya dapat menyelesaikan tindakan seperti penarikan.

Escape hatch yang sangat ketat dapat melindungi dari pencurian, tetapi membiarkan dana terkunci tanpa batas waktu.

Escape hatch yang terlalu longgar dapat mempertahankan penarikan cepat, tetapi memungkinkan klaim palsu.

Desain yang kuat menyeimbangkan tujuan ini melalui bukti, penundaan, kewenangan terbatas, pemantauan, dan prosedur cadangan.

Keseimbangan yang tepat bergantung pada nilai aset yang ditahan, kompleksitas protokol, mode kegagalan yang diperkirakan, dan kemampuan pengguna membuat bukti secara mandiri.

Menguji Escape Hatch

Escape hatch harus diuji sebelum dana bergantung padanya.

Developer sebaiknya menyimulasikan kegagalan operator, kegagalan oracle, penanda tangan yang tidak tersedia, jeda kontrak, kemacetan jaringan, kegagalan transfer token, dan insolvensi parsial.

Pengujian harus memastikan akun tanpa izin tidak dapat mengaktifkan mekanisme atau menarik aset pengguna lain.

Pengujian juga harus memastikan pengguna yang sah dapat menyelesaikan pemulihan tanpa persetujuan off-chain tersembunyi.

Sistem besar dapat mengadakan simulasi publik menggunakan testnet atau deployment bernilai terbatas.

Software pemulihan harus tetap dipelihara meskipun jarang digunakan.

Dokumentasi, alat pembuatan bukti, alamat kontrak, dan petunjuk transaksi sebaiknya disimpan di lebih dari satu lokasi.

Mekanisme darurat yang belum diuji dapat gagal tepat ketika sistem pengembangan dan dukungan biasa tidak tersedia.

Cara Pengguna Mengevaluasi Escape Hatch

Langkah pertama adalah mengidentifikasi skenario kegagalan spesifik yang hendak ditangani mekanisme tersebut.

Langkah kedua adalah menentukan apakah pengguna dapat mengaktifkannya langsung atau memerlukan persetujuan administrator.

Langkah ketiga adalah memeriksa aset yang dapat ditarik dan cara menghitung jumlah klaim.

Langkah keempat adalah memeriksa apakah mekanisme bergantung pada sequencer, oracle, situs web, server, kelompok penanda tangan, atau penyedia data eksternal.

Langkah kelima adalah meninjau time lock, masa tunggu, persyaratan bukti, biaya transaksi, dan batas penarikan.

Langkah keenam adalah memverifikasi izin administrator, jeda, upgrade, dan transfer aset secara on-chain.

Langkah ketujuh adalah memastikan data yang cukup dan software open-source tersedia untuk pemulihan independen.

Langkah kedelapan adalah memeriksa apakah mekanisme telah diaudit dan diuji dalam simulasi kegagalan yang realistis.

Langkah kesembilan adalah memahami tindakan yang dilakukan saat insolvensi atau ketika kontrak tidak memiliki aset yang cukup.

Langkah kesepuluh adalah menyimpan alamat kontrak resmi dan petunjuk pemulihan sebelum keadaan darurat membuat antarmuka normal tidak tersedia.

Contoh Escape Hatch

Misalkan pengguna menyetorkan token ke kontrak bridge Layer 2 dan menerima saldo yang setara di jaringan eksekusi yang lebih cepat.

Sequencer normal memproses transfer dan permintaan penarikan.

Sequencer kemudian berhenti memproses transaksi dalam waktu lama.

Pengguna tidak dapat mengirim penarikan melalui antarmuka biasa, tetapi data transaksi dan komitmen status yang diterima tetap tersedia di Layer 1.

Pengguna menjalankan software pemulihan independen dan membuat bukti saldo valid terbaru miliknya.

Pengguna mengirim bukti tersebut ke kontrak bridge Layer 1.

Kontrak memverifikasi bukti dan mencatat permintaan keluar.

Setelah masa tunggu atau verifikasi yang diwajibkan, pengguna mengklaim token Layer 1 terkait.

Kerja sama operator tidak diperlukan untuk pelepasan aset terakhir.

Jalur pemulihan ini merupakan escape hatch karena memungkinkan pengguna keluar ketika jalur Layer 2 normal gagal.

Kesalahan Umum terkait Escape Hatch

Salah satu kesalahan umum adalah berasumsi bahwa setiap fungsi jeda memungkinkan pengguna menarik aset.

Kesalahan lainnya adalah menyebut fungsi transfer yang dikendalikan administrator sebagai escape hatch tanpa izin.

Kesalahan ketiga adalah menganggap exit Layer 2 dapat dilakukan tanpa akses ke data status dan software pembuat bukti.

Kesalahan keempat adalah memberi satu hot wallet kewenangan darurat tanpa batas.

Kesalahan kelima adalah mengizinkan administrator melewati time lock tanpa mengungkapkan kewenangan tersebut dengan jelas.

Kesalahan keenam adalah tidak menguji escape hatch dengan token nonstandar dan kontrak penerima berbahaya.

Kesalahan ketujuh adalah menggunakan proses penarikan berdasarkan urutan kedatangan saat insolvensi tanpa menjelaskan konsekuensinya.

Kesalahan kedelapan adalah menganggap audit menjamin mekanisme darurat dapat berfungsi dalam setiap kondisi kegagalan.

Kesalahan kesembilan adalah menunggu sampai insiden terjadi untuk mencari alamat kontrak dan petunjuk yang benar.

Kesalahan kesepuluh adalah meyakini bahwa akses penarikan teknis menjamin pemulihan penuh setelah aset hilang.

FAQ

Apa arti escape hatch dalam kripto?

Escape hatch adalah mekanisme cadangan yang memungkinkan aset dipulihkan atau ditarik ketika jalur operasi normal sistem kripto gagal.

Apakah escape hatch sama dengan penarikan darurat?

Penarikan darurat adalah salah satu jenis escape hatch, tetapi istilah ini juga dapat merujuk pada forced exit Layer 2, pengembalian dana berbatas waktu, kunci pemulihan, atau sistem penyelesaian darurat.

Apa itu escape hatch Layer 2?

Escape hatch Layer 2 adalah jalur pemulihan yang memungkinkan pengguna menarik aset melalui kontrak Layer 1 ketika operator atau sequencer Layer 2 normal tidak tersedia atau menyensor transaksi.

Mengapa ketersediaan data penting?

Pengguna memerlukan data status dan transaksi yang cukup untuk membuktikan saldo dan membuat penarikan pemulihan yang valid.

Apakah fungsi jeda merupakan escape hatch?

Fungsi jeda menjadi escape hatch hanya jika disertai metode yang andal agar pengguna dapat memulihkan atau menarik aset yang memenuhi syarat.

Bisakah escape hatch mencegah semua kerugian?

Tidak. Escape hatch tidak dapat mengganti kerugian pengguna sepenuhnya jika aset sudah dicuri, dibekukan, dihancurkan, atau hilang akibat insolvensi.

Siapa yang dapat mengaktifkan escape hatch?

Aktivasi dapat dikendalikan oleh pengguna individu, kondisi smart contract, tata kelola, kelompok multisignature, administrator, atau kombinasi metode tersebut.

Bisakah escape hatch menjadi backdoor?

Ya. Mekanisme yang terlalu kuat atau tidak terlindungi dengan baik dapat memungkinkan akun berhak istimewa menyita dana, mengubah aturan, atau melewati kontrol keamanan normal.

Apa itu penarikan paksa?

Penarikan paksa memungkinkan pengguna mengirim permintaan pemulihan melalui kontrak base layer tanpa bergantung pada operator normal untuk menyertakan transaksi.

Apakah escape hatch memerlukan time lock?

Tidak selalu, tetapi time lock dapat memberi pengguna kesempatan meninjau perubahan sensitif dan keluar sebelum perubahan tersebut berlaku.

Bisakah pengguna mengaktifkan escape hatch Layer 2 dari wallet biasa?

Beberapa sistem mendukung transaksi sederhana, sedangkan sistem lainnya memerlukan bukti, data, atau software pemulihan khusus.

Apakah escape hatch menjamin penarikan instan?

Tidak. Pemulihan darurat dapat melibatkan masa tantangan, antrean, pembuatan bukti, biaya gas, atau langkah penyelesaian manual.

Bisakah oracle mengendalikan escape hatch?

Oracle dapat menyediakan pemicu atau nilai penyelesaian, tetapi hal ini menambah risiko bahwa data yang keliru atau tidak tersedia menghasilkan keputusan yang salah.

Apa yang terjadi jika protokol insolven?

Escape hatch hanya dapat mendistribusikan aset yang tersisa, sehingga sistem mungkin memerlukan penyelesaian proporsional atau proses alokasi kerugian lainnya.

Bagaimana cara pengguna memverifikasi escape hatch?

Pengguna sebaiknya memeriksa kontrak, pihak yang berwenang mengaktifkan, logika penarikan, time lock, persyaratan data, alat bukti, izin upgrade, dan tinjauan keamanan independen.

Bisakah tata kelola menonaktifkan escape hatch?

Tata kelola mungkin dapat mengubah atau menonaktifkannya jika kontrak dapat di-upgrade, sehingga pengguna harus meninjau kewenangan tata kelola dan upgrade yang sebenarnya.

Apakah audit membuktikan escape hatch akan berfungsi?

Tidak. Audit dapat mengidentifikasi sebagian risiko, tetapi tidak dapat menjamin operasi yang benar dalam setiap kegagalan teknis, ekonomi, atau tata kelola.

Apa itu mode hanya-penarikan?

Mode hanya-penarikan memblokir aktivitas pengambilan risiko baru sambil memungkinkan pengguna yang memenuhi syarat menarik aset dari protokol.

Apakah escape hatch sebaiknya menggunakan wallet multisignature?

Pengaturan multisignature dapat mengurangi risiko kunci tunggal, tetapi manfaatnya bergantung pada independensi penanda tangan, desain ambang, keamanan kunci, dan batas kewenangan yang transparan.

Apa tujuan utama escape hatch?

Tujuan utamanya adalah mempertahankan jalur pemulihan yang dapat diandalkan ketika sistem kripto normal tidak dapat memproses pengguna yang ingin keluar dengan aman atau andal.

Kesimpulan

Escape hatch adalah mekanisme pemulihan kripto yang dirancang untuk melindungi pengguna ketika operasi protokol normal tidak tersedia atau tidak aman.

Mekanisme ini dapat berupa penarikan darurat, forced exit Layer 2, pengembalian dana berbatas waktu, kunci pemulihan, mode hanya-penarikan, atau proses penyelesaian darurat.

Escape hatch yang kuat menjaga liveness tanpa memberi satu akun berhak istimewa kendali tanpa batas atas aset pengguna.

Escape hatch Layer 2 sangat bergantung pada ketersediaan data yang andal, komitmen status yang valid, alat bukti yang dapat diakses, dan kontrak bridge Layer 1 yang berfungsi.

Escape hatch smart contract memerlukan akuntansi yang aman, kontrol akses yang cermat, panggilan eksternal yang aman, perlindungan replay, dan dukungan untuk perilaku token yang tidak lazim.

Time lock, otorisasi multisignature, pemisahan peran, log peristiwa publik, dan kewenangan darurat yang terbatas dapat mengurangi risiko yang timbul dari kendali istimewa.

Escape hatch tidak dapat menggantikan aset yang telah dicuri atau menjamin pengembalian penuh dari protokol yang insolven.

Pengguna sebaiknya mengetahui pihak yang dapat mengaktifkan mekanisme, aset yang dapat ditarik, dependensi yang masih ada, dan apakah pemulihan dapat dilakukan tanpa operator awal.

Developer sebaiknya menguji jalur darurat dalam kondisi kegagalan yang realistis, bukan memperlakukannya sebagai kode cadangan yang tidak pernah digunakan.

Memahami escape hatch membantu pengguna kripto membedakan kemampuan pemulihan tanpa izin yang nyata dari tombol jeda, janji administrator, atau backdoor darurat.