---
title: "Jembatan lintas chain"
description: "Panduan yang mengutamakan verifikasi untuk rute aset dan pesan lintas chain, model kepercayaan, state pesan, perlindungan replay, backing, likuiditas, biaya, percobaan ulang, dan rekonsiliasi akhir."
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.
# Jembatan lintas chain
> Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.
## Jawaban langsung
Jembatan lintas chain adalah sistem yang membuat transfer aset atau pesan yang diamati pada satu domain eksekusi menghasilkan tindakan terotorisasi pada domain lain. Chain independen tidak otomatis memercayai state satu sama lain. Karena itu, rute memerlukan model verifikasi, aturan eksekusi tujuan, serta model penerbitan, kustodi, atau likuiditas untuk aset.
Dimensi tersebut harus dipisahkan. Aset dapat memakai lock-and-mint, burn-and-release, burn-and-mint oleh penerbit, atau pengiriman penyedia likuiditas. Pesan dapat diterima melalui light client atau validity proof, proses sengketa optimistis, atestasi atau ambang validator, maupun verifier khusus aplikasi. Setiap kombinasi memiliki risiko finalitas, replay, upgrade, liveness, dan solvabilitas berbeda. Transaksi sumber, atestasi, saldo tujuan, dan penebusan ekonomis adalah state yang berbeda.
## Cara kerja
1. Tetapkan snapshot rute: protokol dan versi, `chainId` atau domain sumber dan tujuan, alamat gateway, router, messenger atau adapter, pasangan token, penerima, jumlah, desimal, tenggat, referensi blok, dan dokumentasi resmi. Nama, ikon, atau label agregator bukan identitas.
2. Klasifikasikan dua dimensi independen. Catat apakah jalur aset memakai lock-and-mint, burn-and-release, burn-and-mint penerbit, atau pengiriman likuiditas; serta apakah jalur pesan memakai bukti konsensus, light client, verifikasi optimistis, atestasi, ambang validator, atau verifier lain.
3. Petakan akar kepercayaan dan kendali: finalitas sumber, ketersediaan data, asumsi proof atau attester, executor tujuan, perlindungan replay, implementasi proxy, admin atau dewan keamanan, jeda upgrade, pause, dan rate limit. Label canonical, resmi, diaudit, atau berbasis proof bukan kesimpulan risiko lengkap.
4. Bangun state machine pesan khusus arah: pengiriman sumber, inclusion dan finalitas wajib; ID pesan, nonce atau sequence; proof atau atestasi; relay; eksekusi tujuan; acknowledgement; serta retry, timeout, refund, atau claim. Jalur deposit dan withdrawal dapat asimetris.
5. Bangun ledger aset dan pesan dalam unit mentah. Rekonsiliasi escrow yang memenuhi syarat, suplai representasi aktif, klaim terkunci-belum-mint, klaim burn-belum-release, burn dan mint penerbit, ID pesan terpakai, serta allowance tersisa. Jangan menghitung escrow dan representasinya sebagai dua aset independen.
6. Bangun ledger ekonomi yang dapat dieksekusi. Pisahkan pokok token dan biaya protokol dari gas sumber dan tujuan, biaya relayer atau penyedia likuiditas, kapasitas quote, output minimum, slippage, price impact, dan biaya menunggu. Quote bukan fill, dan gas dalam token native tidak otomatis mengurangi output token yang dijembatani.
7. Rekonsiliasi rute dari bukti aktual: receipt sumber dan blok final, status pesan atau packet, output verifier, receipt tujuan dan perubahan state, kontrak token yang benar-benar diterima, saldo, redeemability, dan likuiditas. Cabut otoritas berlebih, sisakan gas pemulihan, dan hentikan alih-alih mengulang transfer yang tidak dapat dijelaskan.
## Contoh perhitungan
- **Backing dengan klaim dalam perjalanan.** Escrow yang memenuhi syarat `10,000 units`; representasi aktif di tujuan `9,700 units`; klaim terkunci-belum-mint `200 units`; dan klaim burn-belum-release `100 units`. Klaim ekonomi adalah `9,700 + 200 + 100 = 10,000 units`, sehingga coverage tersesuaikan `10,000 / 10,000 = 100.0000000000%`. Membagi hanya dengan suplai aktif secara keliru memberi `10,000 / 9,700 = 103.0927835052%`. Coverage tidak membuktikan keamanan kontrak atau likuiditas langsung.
- **Output token versus biaya ekonomi.** Pengguna mengirim `5,000 USDC`; biaya protokol `5 USDC` dipotong, sehingga output token tujuan `4,995 USDC`. Gas sumber `0.003 ETH` dan gas claim tujuan `0.001 ETH`; pada harga eksplisit `2,000 USD/ETH`, arus kas terpisah itu bernilai `$6` dan `$2`. Total biaya ekonomi `$5 + $6 + $2 = $13`, kekayaan bersih diterima `$4,987`, tetapi saldo tujuan tetap `4,995 USDC`.
- **Kompromi ambang dan kekurangan cadangan.** Jembatan atestasi hipotetis `3-of-5` memiliki escrow `$5,000,000` dan `5,000,000` unit wrapped sah. Jika tiga kunci berwenang memalsukan mint tanpa backing sebesar `1,000,000-unit`, suplai menjadi `6,000,000`, kekurangan `$1,000,000`, dan coverage pro-rata `5,000,000 / 6,000,000 = 83.3333333333%`, atau cadangan `$0.8333333333` per token. Ini hasil akuntansi, bukan harga pasar atau pemulihan yang dijamin.
- **Kapasitas rute likuiditas.** Permintaan `100,000 units`. Rute A berkapasitas `60,000` dengan biaya `0.20%`, menghasilkan `60,000 * (1 - 0.002) = 59,880 units`. Rute independen B menangani `40,000` dengan `0.35%` plus `20 units`, menghasilkan `40,000 * (1 - 0.0035) - 20 = 39,840 units`. Total output `99,720 units`; biaya `280 units`, atau `280 / 100,000 = 0.2800000000%`. Setiap rute memiliki asumsi keamanan terpisah, dan eksekusi parsial hanya ada jika protokol aktual serta receipt mengizinkannya.
## Risiko
- Memilih sumber, tujuan, `chainId`, atau domain yang salah.
- Memakai antarmuka phishing, situs dokumentasi, atau agregator rute palsu.
- Mengirim melalui gateway, router, messenger, atau adapter tiruan.
- Menerima pasangan token, penerima, atau representasi bersimbol sama yang salah.
- Salah membaca desimal, unit mentah, atau perilaku fee-on-transfer dan rebasing.
- Membiarkan approval, permit, atau izin operator berlebihan.
- Mengandalkan transaksi sumber sebelum finalitas cukup atau setelah reorganisasi.
- Memercayai kunci verifier, validator, attester, atau anggota ambang yang disusupi.
- Menerima light client, proof verifier, atau mekanisme sengketa yang cacat.
- Membiarkan replay, double mint, kesalahan sequence, ordering, atau idempotensi.
- Menganggap sukses di sumber membuktikan eksekusi tujuan.
- Kekurangan gas untuk eksekusi tujuan, retry, claim, atau refund.
- Bergantung pada relayer, prover, attester, atau executor yang tidak tersedia.
- Kehilangan liveness akibat sensor sequencer atau data tidak tersedia.
- Melewatkan upgrade, perubahan admin, pause, rate limit, atau bypass timelock.
- Mengabaikan insolvabilitas escrow, cadangan gabungan, atau drift akuntansi in-flight.
- Menganggap hook token nonstandar kompatibel dengan jembatan.
- Melebihi kapasitas likuiditas atau mengandalkan quote dan jalur rebalance usang.
- Mengalami depeg, slippage, MEV, atau jalur penebusan yang tidak dapat digunakan.
- Salah memahami timeout, refund, pemulihan, pajak, sanksi, atau aturan kustodi.
## Kesalahpahaman umum
- Koin identik secara fisik berpindah dari satu blockchain ke blockchain lain.
- Canonical, resmi, diaudit, atau berbasis proof otomatis berarti bebas risiko.
- Transaksi sumber yang sukses menjamin kredit tujuan dan penyelesaian final.
- Backing satu banding satu menjamin penebusan langsung dan likuiditas pasar satu banding satu.
- Jembatan cepat hanyalah rute penyelesaian yang sama tetapi berjalan lebih cepat.
## Topik terkait
- [Jembatan canonical](/id/crypto/canonical-bridge/)
- [Cara memverifikasi token setelah bridging](/id/crypto/bridge-token-verification/)
- [Risiko liveness relayer lintas chain](/id/crypto/bridge-relayer-liveness-risk/)
## Sumber
- [Bridges](https://ethereum.org/developers/docs/bridges/) - Ethereum.org (diakses: 2026-08-12)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (diakses: 2026-08-12)
- [Messengers](https://specs.optimism.io/protocol/messengers.html) - OP Stack Specification (diakses: 2026-08-12)
- [CCTP technical guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Docs (diakses: 2026-08-12)
- [ICS-4: Channel and Packet Semantics](https://github.com/cosmos/ibc/blob/main/spec/core/ics-004-channel-and-packet-semantics/README.md) - Inter-Blockchain Communication Protocol (diakses: 2026-08-12)
- [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164) - Ethereum Improvement Proposals (diakses: 2026-08-12)
- [ERC-7786: Cross-Chain Messaging Gateway](https://eips.ethereum.org/EIPS/eip-7786) - Ethereum Improvement Proposals (diakses: 2026-08-12)
- [CCIP Concepts](https://docs.chain.link/ccip/concepts) - Chainlink Documentation (diakses: 2026-08-12)
Source: https://wiki.fcontext.com/id/crypto/cross-chain-bridge/index.mdx