Lompat ke konten
Financial Context Wiki

Apa yang harus dilakukan saat sequencer L2 tidak aktif

Rencana praktis menghadapi downtime sequencer L2: verifikasi gangguan, hindari transaksi ganda, periksa jalur cadangan L1 rollup, dan perhitungkan risiko pemulihan serta likuidasi.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Perlakukan gangguan sequencer sebagai hilangnya akses L2 normal, bukan bukti bahwa rollup atau aset Anda gagal. Hentikan tindakan yang sensitif terhadap waktu, verifikasi insiden melalui halaman status resmi chain serta data RPC atau explorer independen, dan pahami jalur cadangan L1 khusus rollup tersebut sebelum menandatangani apa pun.

  1. Catat chain, alamat dompet, hash transaksi tertunda, blok terakhir yang terlihat, dan waktu kegagalan.
  2. Jangan mengirim ulang berkali-kali atau menaikkan biaya saat status transaksi belum diketahui.
  3. Periksa apakah unsafe head bergerak sementara safe atau finalized head terhenti; ini dapat menunjukkan gangguan publikasi batch, bukan penghentian total.
  4. Gunakan jalur transaksi paksa atau penarikan di L1 hanya dari dokumentasi resmi dan alamat kontrak terverifikasi.
  5. Setelah pulih, tunggu antrean, status oracle, status bridge, dan masa tenggang aplikasi kembali normal sebelum menambah leverage atau menganggap transaksi sudah final.

Cara kerjanya

Sequencer biasanya menerima, mengurutkan, dan mengonfirmasi transaksi L2 dengan cepat, lalu menerbitkan data yang diperlukan untuk menurunkan chain ke lapisan ketersediaan data. Downtime dapat mencegah pengiriman RPC biasa. Dalam gangguan publikasi terpisah, sequencer dapat terus menghasilkan blok unsafe sementara publikasi ke L1, beserta head safe dan finalized, berhenti. Kedua kondisi memiliki risiko reorganisasi dan pemulihan yang berbeda.

Jalur cadangan bergantung pada implementasi. Pada chain OP Stack, pengguna dapat mengirim transaksi L2 melalui OptimismPortal terverifikasi milik chain di L1; jendela pengurutan default adalah 12 jam, tetapi dapat berbeda menurut chain. Arbitrum Nitro memakai Delayed Inbox di L1, dan desain yang dipublikasikan menjelaskan penyertaan paksa setelah ambang 24 jam. Mekanisme ini memberi penyertaan pada akhirnya, bukan jalan keluar instan atau universal, serta tetap memerlukan Gas L1 dan kontrak khusus chain yang benar.

Aplikasi juga memerlukan kontrol sendiri. Feed uptime sequencer dapat menandai downtime, tetapi berbeda dari feed harga. Protokol pinjaman dan derivatif dapat menjeda operasi sensitif selama gangguan dan menerapkan masa tenggang pemulihan agar pembaruan oracle serta transaksi pengguna yang mengantre tidak langsung menjadi likuidasi yang tidak adil.

Contoh

Seorang peminjam memiliki agunan ETH dalam protokol pinjaman L2. Sequencer tidak tersedia selama 2 jam ketika ETH turun 15%, sehingga peminjam tidak dapat menambah agunan melalui RPC normal. Protokol mendeteksi gangguan, menjeda likuidasi, dan mempertahankan jeda selama masa tenggang terkonfigurasi 1 jam setelah feed uptime melaporkan pemulihan.

Peminjam mencatat hash tertunda, memeriksa pengumuman insiden resmi dan safe head rollup, serta tidak memercayai pesan dukungan yang menawarkan tautan “pencairan”. Jika tindakan masih diperlukan, peminjam mengikuti jalur L1 resmi rollup dan memverifikasi alamat portal atau inbox. Setelah pulih, peminjam menunggu transaksi paksa, feed harga, dan kesehatan akun tercermin dalam blok safe sebelum mengandalkan hasilnya.

Risiko

  • Likuidasi saat pemulihan: transaksi dan pembaruan harga yang mengantre dapat diproses berdekatan; tanpa masa tenggang, pengguna yang tidak bisa bertransaksi saat downtime dapat segera dilikuidasi.
  • Reorganisasi status unsafe: RPC dapat menampilkan blok terbaru yang belum diterbitkan ke L1 dan mungkin direorganisasi jika jendela publikasi berakhir.
  • Sinyal usang atau tidak selaras: feed harga yang bergerak tidak membuktikan pengguna dapat bertransaksi, dan feed uptime tidak membuktikan harga masih terkini.
  • Risiko eksekusi jalur paksa: panggilan L1 langsung lebih teknis dan mahal; jaringan, kontrak, calldata, nonce, atau batas Gas yang salah dapat gagal atau menjebak dana.
  • Keterlambatan sistem terkait: bridge, bursa, keeper, pengindeks, dan frontend dapat pulih pada jadwal berbeda meski sequencer sudah kembali.

Kesalahpahaman umum

  • “Sequencer mati, jadi aset hilang.” Status rollup yang ditegakkan L1 dapat tetap utuh walaupun akses normal tidak tersedia.
  • “Semua rollup memiliki penundaan penyertaan paksa yang sama.” Jendela, kontrak, dan tindakan yang didukung berbeda menurut implementasi dan konfigurasi chain.
  • “Transaksi paksa langsung dieksekusi.” Pengiriman L1 membentuk jalur menuju penyertaan pada akhirnya; ini tidak menghapus jeda pengurutan, bukti, atau penarikan.
  • “Begitu blok berjalan lagi, risiko likuidasi selesai.” Antrean, pembaruan oracle, dan keeper dapat membuat fase pemulihan paling berisiko.
  • “Tautan status dari dukungan aman.” Verifikasi domain dan alamat kontrak secara independen; jangan pernah mengungkap seed phrase atau kunci pribadi.

Topik terkait

Sumber

Navigasi

Cari di wiki...