Lompat ke konten
Financial Context Wiki

Penarikan paksa L2

Panduan berbasis protokol tentang inklusi paksa, penarikan paksa, dan jalur keluar darurat: jaminan, ketergantungan, serta cara memverifikasi jalur keluar.

Diperbarui

Hanya untuk edukasi; bukan nasihat keuangan atau keamanan. Mekanisme keluar, waktu tunggu, biaya, izin kontrak, dan asumsi ketersediaan data berbeda pada tiap L2 dan dapat berubah setelah peningkatan.

Jawaban langsung

Penarikan paksa L2 adalah jalur protokol yang memungkinkan pengguna memulai atau menyelesaikan keluar tanpa persetujuan operator L2. Istilah ini tidak baku. Pada sebagian sistem, artinya mengirim permintaan penarikan langsung ke kontrak L1; pada sistem lain, fungsi yang tersedia hanya inklusi paksa, yang sekadar menjamin transaksi asal L1 masuk antrean eksekusi L2. Pengguna masih harus mengikuti alur penarikan dan finalisasi normal pada jembatan kanonis.

Jalur keluar darurat adalah jalur yang lebih kuat ketika pembaruan status normal berhenti. Jalur ini dapat membekukan aplikasi dan mengizinkan pengguna membuktikan saldo terhadap akar status yang telah dikomit. Mekanisme tersebut tidak menjamin keluar seketika, nilai aset tertentu, atau bebas dari bug kontrak dan wewenang tata kelola. Jaminan sebenarnya berasal dari kode yang diterapkan, konfigurasi saat ini, data status yang tersedia, serta kemampuan pengguna membuat dan mengirim transaksi atau bukti yang diperlukan.

Cara kerja

  • Kenali fungsi dasarnya. Inklusi paksa, penarikan paksa, dan mode keluar menangani masalah berbeda. Inklusi paksa melewati sequencer yang menyensor atau tidak aktif. Permintaan penarikan paksa mewajibkan protokol atau operator memproses keluar atau membuktikan permintaan tidak valid. Mode keluar biasanya pilihan terakhir: pembaruan normal berhenti dan pengguna menarik dengan bukti status.
  • Masuk melalui L1. Pengguna mengirim transaksi ke inbox, portal, atau kontrak penyelesaian L1 yang didokumentasikan. Pada OP Stack, deposit L1 diturunkan menjadi blok L2 dalam jendela sequencing. Pada Arbitrum Nitro, pesan dapat masuk Delayed Inbox dan, setelah jeda yang dikonfigurasi, dipaksa ke inbox utama jika sequencer belum memasukkannya.
  • Tunggu pemrosesan protokol. Konfirmasi L1 hanya titik pemeriksaan awal. Permintaan mungkin harus menjadi bagian rantai L2 kanonis, berhasil dieksekusi, muncul dalam status terbukti atau terkonfirmasi, melewati periode sanggahan atau tenggang, lalu difinalisasi di L1. Transaksi paksa tetap dapat revert karena nonce salah, Gas kurang, calldata keliru, pembatasan token, atau perubahan status L2.
  • Penuhi syarat keluar. StarkEx Spot menunjukkan alur penarikan paksa dan keluar yang sebenarnya. Pengguna mengirim fullWithdrawalRequest; aplikasi harus memenuhinya atau membuktikan bahwa permintaan tidak valid. Jika tetap tertunda setelah FREEZE_GRACE_PERIOD, pembekuan dapat diminta. Keluar lalu memerlukan jalur Merkle terhadap akar vault beku, verifikasi bukti, panggilan escape, dan panggilan on-chain normal withdraw.
  • Periksa ketersediaan data. Akar status adalah komitmen, bukan saldo atau jalur Merkle di bawahnya. Jika data untuk membangun ulang status dipublikasikan di L1, pihak independen pada prinsipnya dapat membuat bukti keluar. Pada Validium atau rancangan data off-chain, pengguna mungkin bergantung pada komite atau operator untuk merilis data. Validitas bukti dan ketersediaan data adalah jaminan berbeda.
  • Periksa kendali dan alat. Tinjau wewenang jeda, pembekuan, peningkatan, dan tata kelola; alamat kontrak serta implementasi proxy yang tepat; aset yang didukung; kunci; Gas L1 dan L2; perangkat lunak pembuat bukti; serta antarmuka independen. Mekanisme yang benar di atas kertas dapat tidak praktis tanpa data, alat, atau dana L1 yang cukup.

Contoh

Misalkan sequencer dan antarmuka resmi suatu Rollup tidak tersedia, tetapi L1 terus final. Pengguna terlebih dahulu memverifikasi chain ID dan kontrak L1 kanonis dari dokumentasi resmi. Jika sistem hanya menawarkan inklusi paksa, pengguna mengirim transaksi L1-ke-L2 yang memanggil fungsi penarikan L2 pada jembatan kanonis. Setelah itu, pengiriman L1, inklusi paksa, eksekusi L2, komitmen status, tahap sanggahan atau bukti, serta finalisasi L1 dilacak terpisah. Pengiriman L1 yang berhasil tidak membuktikan panggilan penarikan berhasil.

Pada sistem bergaya StarkEx, urutannya berbeda: kirim permintaan paksa yang didokumentasikan, tunggu masa tenggang yang dikonfigurasi, periksa apakah permintaan dipenuhi atau dibuktikan tidak valid, dan gunakan pembekuan serta keluar hanya jika syarat kontrak terpenuhi. ID vault, kunci, dan jalur Merkle harus cocok dengan status beku. Menyalin prosedur Arbitrum atau OP Stack ke sistem ini adalah keliru meski semuanya kadang disebut “penarikan paksa”.

Sebelum bergantung pada jalur mana pun, latih dengan jumlah kecil saat sistem sehat. Catat alamat kontrak, signature fungsi, peristiwa yang diharapkan, timer, dan hash transaksi. Verifikasi status memakai RPC atau penjelajah tepercaya lain. Jangan pernah memasukkan seed phrase atau private key ke situs “penarikan darurat”, dan jangan mengirim biaya “pembukaan kunci” tambahan kepada akun dukungan atau pesan langsung.

Risiko

  • Protokol memiliki inklusi paksa tetapi tidak memiliki fungsi penarikan paksa langsung.
  • Permintaan L1 terkonfirmasi, tetapi panggilan L2 revert atau belum dieksekusi.
  • Periode sanggahan, bukti, tenggang, atau finalisasi menunda akses dana.
  • Data status atau jalur Merkle tidak tersedia, terutama pada data off-chain.
  • Chain, kontrak, implementasi proxy, fungsi, atau ID vault yang dipakai salah.
  • Kontrak keluar dijeda, ditingkatkan, salah dibekukan, atau terdampak bug.
  • Tata kelola, dewan keamanan, atau pihak berwenang lain dapat mengubah jalur.
  • Aset tidak didukung, nonstandar, tidak likuid, atau tunduk pada aturan margin.
  • Lonjakan Gas L1 atau kekurangan Gas native mencegah pengiriman atau finalisasi.
  • Antarmuka, RPC, pengindeks, atau alat bukti tidak tersedia saat dibutuhkan.
  • Antarmuka palsu, iklan, atau dukungan palsu mencuri kredensial atau dana.
  • Nilai pasar dapat turun selama penundaan; kemampuan keluar bukan pelindung harga.

Kesalahpahaman umum

  • “Penarikan paksa” memiliki alur universal. Nama dan jaminan khusus tiap protokol; baca dokumentasi dan kontrak versi yang diterapkan.
  • Inklusi paksa langsung mengembalikan dana ke L1. Biasanya hanya menjamin akses pengurutan atau eksekusi; penarikan jembatan tetap memiliki siklus sendiri.
  • Hash transaksi L1 membuktikan keluar berhasil. Hash hanya membuktikan inklusi L1; eksekusi L2 dan finalisasi L1 harus diperiksa terpisah.
  • Bukti validitas menjamin data keluar tersedia. Kebenaran bukti dan ketersediaan data berbeda; rancangan off-chain menambah ketergantungan.
  • Jalur darurat trustless karena fungsinya ada. Kegunaan juga bergantung pada izin, konfigurasi, data, perangkat lunak, Gas, dan kunci.
  • Jalur keluar darurat menghapus risiko keuangan. Jalur ini menangani kegagalan keaktifan atau sensor, bukan risiko harga, likuiditas, kontrak, atau kebocoran kunci.

Topik terkait

Sumber

Navigasi

Cari di wiki...