---
title: "Risiko kelangsungan relayer lintas chain"
description: "Risiko kelangsungan relayer adalah risiko pesan lintas chain yang terautentikasi tidak dikirim atau dieksekusi tepat waktu; diagnosis harus memisahkan finalitas sumber, ketersediaan bukti, pengiriman, eksekusi tujuan, dan pencatatan aset."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Risiko kelangsungan relayer lintas chain
> Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.
## Jawaban langsung
Risiko kelangsungan relayer lintas chain adalah risiko pesan valid dan terautentikasi tidak dikirim atau dieksekusi tepat waktu di tujuan. Relayer biasanya mengangkut pesan beserta bukti atau metadata; relayer tidak membuat peristiwa sumber final maupun mengotorisasi payload. Konsensus sumber, pembuatan bukti atau atestasi, verifikasi tujuan, dan eksekusi penerima merupakan dependensi terpisah.
Pengiriman terlambat pada awalnya adalah masalah ketersediaan, bukan bukti aset dicuri. Namun, keterlambatan dapat menimbulkan biaya pendanaan, tenggat terlewat, tiket kedaluwarsa, likuiditas tak dapat digunakan, atau kerugian permanen menurut aturan produk. Sebaliknya, receipt sumber dan label antarmuka `Pending` tidak membuktikan relayer bermasalah: sumber mungkin belum final, bukti belum tersedia, tujuan dijeda, gas kurang didanai, atau penerima revert.
Pengiriman permissionless bergantung pada protokol. Hyperlane dan Wormhole menjelaskan jalur tempat pihak ketiga dapat mengirim pesan terautentikasi, sedangkan deployment lain membatasi executor, pemanggil tujuan, atau fungsi pemulihan. Pengiriman terbuka tidak membuat relayer dapat mengubah payload terautentikasi, dan allowlist relayer tidak menggantikan verifikasi tujuan atau perlindungan replay.
## Cara kerjanya
Lifecycle yang berguna memisahkan `source submitted`, `source finalized`, `proof pending`, `ready`, `destination submitted`, `failed/retryable`, `executed`, dan `expired/cancelled`. Label itu bersifat analitis; setiap protokol memiliki field on-chain sendiri. Withdrawal OP Stack, pesan burn-and-mint CCTP, VAA Wormhole, dan pesan Hyperlane mempunyai aturan bukti, waktu, biaya, serta retry berbeda.
Pertama, pastikan apakah tindakan sumber benar-benar mengunci, membakar, atau mengirim nilai dan mencapai finalitas yang disyaratkan. Berikutnya, pastikan root, tanda tangan validator, VAA guardian, atau atestasi yang diharapkan tersedia dan mutakhir. Baru setelah itu periksa apakah relayer mengamati pesan, menerima kebijakan biaya, membangun metadata yang benar, dan mengirimkannya ke kontrak tujuan yang tepat.
Eksekusi tujuan memiliki mode kegagalan mandiri: chain atau sequencer mati, RPC usang, kontrak dijeda, versi penerima salah, gas kurang, nonce berurutan terhalang, kedaluwarsa, atau aplikasi revert. Hash transaksi hanya referensi pengiriman. Penyelesaian membutuhkan receipt berhasil, state processed protokol, peristiwa atau perubahan state penerima, identitas token benar, dan dampak saldo yang diharapkan di bawah finalitas tujuan yang disyaratkan.
Relay manual bukan tombol penyelamat universal. Jalur itu hanya mungkin bila deployment protokol menyediakan entry point yang memenuhi syarat, pesan dan bukti asli tersedia, pemanggil diizinkan, pesan belum dikonsumsi dan belum kedaluwarsa, serta pemanggil mampu mendanai gas dan nilai tujuan. Simulasikan panggilan tujuan resmi. Jangan membuat lock atau burn sumber baru hanya untuk memperbaiki pesan pertama yang belum dijelaskan.
Retry berbeda dari replay. Retry yang terdokumentasi mengirim ulang pesan kanonis yang sama setelah dampak tujuan gagal; state consumed atau nonce yang benar hanya membolehkan paling banyak satu dampak berhasil. Beberapa relayer dapat berlomba dan memboroskan gas walau perlindungan replay menjaga keamanan. Pembatalan tugas lokal tidak dapat menarik kembali transaksi tujuan yang sudah disiarkan atau dimasukkan ke blok.
Gunakan alur kerja berikut:
1. Sematkan protokol, lane dan versi deployment, domain serta kontrak sumber dan tujuan, transaksi dan log sumber, ID pesan atau nonce, tindakan aset, jumlah mentah, penerima, serta kedaluwarsa.
2. Verifikasi receipt dan peristiwa sumber, lalu terapkan aturan konfirmasi atau finalitas chain dan protokol tersebut; periksa identitas blok dan status reorganisasi, bukan mempercayai antarmuka.
3. Temukan bukti, VAA, atestasi, checkpoint, atau root yang ditentukan protokol; verifikasi state sumber, versi, set penanda tangan, ketersediaan, serta status invalidasi atau kedaluwarsanya.
4. Periksa kesehatan chain tujuan, versi messenger dan penerima, status pause, nonce atau state processed, syarat pendahulu, tenggat, dan kebutuhan gas native.
5. Tentukan apakah pengiriman permissionless, masuk allowlist, atau dibatasi pemanggil; untuk jalur manual yang memenuhi syarat, bangun dan simulasikan ulang payload, bukti, dan panggilan tujuan resmi yang persis.
6. Perbarui limit dan harga gas, markup nilai tukar, batas biaya, refund, dan quote kedaluwarsa; kirim atau retry pesan yang sama, tangani race duplikat dan replacement, lalu simpan receipt tujuan.
7. Rekonsiliasi escrow atau burn sumber, liabilitas in-flight, mint, unlock, atau panggilan tujuan, biaya protokol dan gas, refund, serta state akhir; eskalasi melalui kanal terdokumentasi tanpa membagikan seed phrase atau kunci privat.
## Contoh
- **Atribusikan keterlambatan per tahap.** Finalitas sumber memerlukan `12 minutes`, pembuatan bukti atau atestasi `8 minutes`, antrean relayer `35 minutes`, dan inclusion tujuan `5 minutes`. Waktu total ialah `12 + 8 + 35 + 5 = 60 minutes`. Hanya antrean `35-minute` yang termasuk kelangsungan pengiriman; `20 minutes` pertama dan `5 minutes` terakhir dimiliki pihak berbeda.
- **Quote gas tujuan menjadi tidak cukup.** Limit gas `300,000`. Pada `25 gwei`, quote ialah `300,000 * 25 * 10^-9 = 0.0075 ETH`. Saat eksekusi, `60 gwei` memerlukan `0.018 ETH`, sehingga kurang `0.018 - 0.0075 = 0.0105 ETH`. Membayar gas chain sumber lebih tinggi tidak selalu mendanai eksekusi tujuan.
- **Relayer duplikat menghabiskan gas, bukan pokok.** Tiga relayer mengirim pesan `100,000 USDC` yang sama. Pemenang memakai `180,000 gas * 30 gwei = 0.0054 ETH`; dua transaksi kalah masing-masing revert setelah `70,000 gas * 30 gwei = 0.0021 ETH`. Total gas relay `0.0054 + 0.0021 + 0.0021 = 0.0096 ETH`, sedangkan state replay yang benar mengizinkan satu dampak `100,000 USDC`, bukan `300,000 USDC`.
- **Lacak liabilitas in-flight.** Rute lock-and-mint mengunci `25 ETH`, tetapi panggilan tujuan gagal: escrow `+25 ETH`, supply wrapped `+0 ETH`, dan liabilitas in-flight `25 ETH`. Retry berhasil atas pesan yang sama mempertahankan escrow `25 ETH`, menaikkan supply wrapped menjadi `25 ETH`, dan menurunkan liabilitas in-flight menjadi `0 ETH`. Deposit sumber baru `25 ETH` justru menciptakan escrow `50 ETH` dan dua kewajiban.
## Risiko
- Transaksi sumber tetap pending atau revert sementara antarmuka melaporkan terkirim.
- Peristiwa sumber ditindak sebelum finalitas memadai.
- Reorganisasi sumber menghapus atau mengubah peristiwa.
- Data bukti, atestasi, checkpoint, atau tanda tangan tidak tersedia.
- Root atau set penanda tangan yang usang, salah, atau dibatalkan digunakan.
- Kunci atau layanan relayer dalam allowlist tidak tersedia.
- Pengiriman permissionless dianggap menjamin pengiriman cepat.
- Entry point terbatas dianggap jalur manual publik.
- Chain tujuan, sequencer, RPC, atau pengindeks tidak tersedia atau usang.
- Messenger atau penerima tujuan dijeda.
- Upgrade atau ketidakcocokan alamat penerima membuat panggilan revert.
- Limit gas tujuan terlalu rendah.
- Asumsi quote gas, kurs, batas biaya, atau refund menjadi usang.
- Wallet tidak memiliki aset gas native tujuan yang benar.
- Tenggat pesan, tiket, bukti, atau eksekusi kedaluwarsa.
- Celah nonce berurutan menghalangi pesan berikutnya.
- Logika retry atau state consumed membolehkan duplikasi atau mencegah pemulihan.
- Race pengiriman duplikat, pembatalan, atau replacement memboroskan gas.
- Jalur dukungan palsu memberikan kontrak, bukti, atau calldata berbahaya.
- Lock atau burn sumber, klaim in-flight, dampak tujuan, biaya, dan refund salah direkonsiliasi.
## Kesalahpahaman umum
- **Relayer mengautentikasi pesan.** Pengiriman membawa bukti; verifier tujuan dan aplikasi menegakkan aturan sumber, pengirim, payload, dan replay.
- **Relayer mati berarti aset sudah hilang atau otomatis dikembalikan.** Dampak pertama adalah keterlambatan; konsekuensi kedaluwarsa, pemulihan, solvabilitas, dan refund bergantung pada produk.
- **Relay permissionless berarti siapa pun dapat mengubah payload atau menjamin eksekusi segera.** Autentikasi mencegah mutasi, sementara bukti, gas, chain, dan ketersediaan penerima tetap menentukan kelangsungan.
- **Setiap retry menyebabkan mint ganda.** Retry yang benar menggunakan kembali satu pesan dan hanya membolehkan satu dampak berhasil; transfer sumber baru menciptakan kewajiban baru.
- **Hash transaksi tujuan atau label antarmuka selesai membuktikan penerimaan.** Konfirmasikan receipt berhasil, state processed, peristiwa penerima, saldo, identitas token, dan finalitas yang disyaratkan.
## Topik terkait
- [Bridge lintas chain](/id/crypto/cross-chain-bridge/)
- [Perlindungan replay pesan lintas chain](/id/crypto/bridge-message-replay-protection/)
- [Bridge kanonis](/id/crypto/canonical-bridge/)
## Sumber
- [Relayer](https://docs.hyperlane.xyz/docs/protocol/agents/relayer) - Hyperlane Documentation (diakses: 2026-08-13)
- [Mailbox](https://docs.hyperlane.xyz/docs/protocol/core/mailbox) - Hyperlane Documentation (diakses: 2026-08-13)
- [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs (diakses: 2026-08-13)
- [Executor Framework](https://docs.wormhole.com/protocol/infrastructure/relayers/executor-framework/) - Wormhole Docs (diakses: 2026-08-13)
- [Withdrawals](https://specs.optimism.io/protocol/withdrawals.html) - OP Stack Specification (diakses: 2026-08-13)
- [Cross Domain Messengers](https://specs.optimism.io/protocol/messengers.html) - OP Stack Specification (diakses: 2026-08-13)
- [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (diakses: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (diakses: 2026-08-13)
Source: https://wiki.fcontext.com/id/crypto/bridge-relayer-liveness-risk/index.mdx