﻿---
title: "Bridge Kanonis"
description: "Panduan berorientasi verifikasi untuk bridge yang ditetapkan protokol, backing aset, state pesan lintas domain, penarikan berbasis fault proof dan validity proof, kendali upgrade, biaya, dan perbandingan fast bridge."
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.

# Bridge Kanonis

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

<a id="answer"></a>

## Jawaban langsung

Bridge kanonis adalah rute aset atau pesan yang ditetapkan oleh ekosistem rollup atau chain tertentu. Biasanya, rute ini menghubungkan kontrak yang mengunci atau membakar aset di satu chain, meneruskan pesan yang diakui protokol, lalu mencetak, membuka kunci, atau melepaskan aset terkait di chain lain. Istilah kanonis adalah label suatu ekosistem, bukan standar universal, jaminan kriptografis, atau bukti bahwa situs dan alamatnya asli.

Keamanannya bukan rumus penjumlahan. Keamanan bergantung secara bersama pada finalitas chain sumber, ketersediaan data, verifikasi state atau pesan, pembukuan bridge, eksekusi tujuan, perlindungan replay, wewenang upgrade dan pause, serta jalur keluar yang dapat digunakan. Fast bridge dapat membayar pengguna lebih awal dari likuiditas, lalu menyelesaikan transaksi melalui rute kanonis, tetapi hal ini menambah asumsi atas penyedia likuiditas, solver, verifier, dan eksekusi, bukan mempercepat state machine yang sama secara gratis.

<a id="mechanism"></a>

## Cara kerjanya

1. Kunci snapshot rute: `chainId` sumber dan tujuan, arah, stack serta versi rollup, alamat bridge, portal, messenger, inbox atau gateway, alamat token, penerima, jumlah, referensi blok, dan dokumentasi resmi. Jangan hanya mengandalkan hasil pencarian atau label resmi.
2. Uraikan model keamanan dan kendali. Catat aturan optimistic fault proof atau validity proof, mode ketersediaan data, sequencer dan forced path, implementasi proxy, admin atau security council, timelock, state pause, rate limit, dan jeda upgrade. Kanonis tidak berarti immutable.
3. Klasifikasikan ledger aset. Bedakan nilai native dari token ERC-20 dan identifikasi perilaku lock-and-mint, burn-and-release, atau burn-and-mint. Verifikasi pasangan token terdaftar, unit mentah, decimals, custom gateway, serta dukungan bagi aset fee-on-transfer, rebasing, atau denylist.
4. Susun state machine pesan yang spesifik untuk arahnya. Deposit dapat melewati approval, escrow atau burn di sumber, finalitas sumber, derivation atau relay, lalu mint atau unlock di tujuan. Penarikan dapat memerlukan burn atau escrow di tujuan, penyertaan pesan, state commitment, proof, challenge atau penerimaan proof, finalisasi, lalu pelepasan di sumber.
5. Lacak tiga waktu secara terpisah: inclusion transaksi, settlement protokol atau finalitas state, dan ketersediaan aset untuk dipakai atau ditarik. Catat hash transaksi sumber, hash pesan atau penarikan, referensi output atau proof, serta setiap transaksi relay, prove, finalize, claim, retry, atau refund.
6. Susun ledger ekonomi. Pisahkan pokok yang dijembatani, gas sumber dan tujuan, gas proof atau finalisasi, biaya protokol atau relayer, biaya penyedia likuiditas, slippage, dan opportunity cost waktu tunggu. Bandingkan fast bridge dan rute kanonis sebagai klaim serta model kepercayaan yang berbeda.
7. Rekonsiliasikan rute selesai dengan receipt, event, saldo escrow, suplai representasi, klaim tertunda, saldo penerima, dan allowance tersisa. Tunggu finalitas yang diperlukan, simpan gas darurat, uji permissionless atau forced path jika tersedia, dan berhenti alih-alih mengulang deposit yang state pesannya tidak dapat dijelaskan.

<a id="example"></a>

## Contoh terhitung

- **Ledger deposit aset native.** Pengguna mulai dengan `5.0000 ETH`, mendepositkan `2.5000 ETH`, dan membayar `0.0042 ETH` gas di chain sumber. Dompet sumber berakhir pada `5.0000 - 2.5000 - 0.0042 = 2.4958 ETH`; escrow naik `2.5000 ETH`; setelah relay satu-banding-satu berhasil, representasi tujuan naik `2.5000 ETH`. Rasio backing adalah `2.5000 / 2.5000 = 100%`. Escrow dan representasi adalah backing serta klaim, bukan `5 ETH` nilai ekonomi baru.
- **Unit token mentah dan mapping.** Pengguna mendepositkan `1,250.000000 USDC`. Kontrak asal yang diverifikasi menggunakan `6 decimals`, sehingga jumlah mentahnya `1,250 * 10^6 = 1,250,000,000`. Dalam mapping satu-banding-satu terverifikasi tanpa biaya token, escrow sumber dan mint tujuan masing-masing berubah `1,250,000,000 raw units`, menampilkan `1,250.000000 USDC` di tujuan. Token bersimbol sama pada alamat lain bukan bukti yang dapat dipertukarkan.
- **Waktu penarikan tidak sama.** Asumsikan suatu deployment mencatat penarikan pada `2026-08-01 12:00:00 UTC` dan menerapkan periode challenge `604,800-second = 7-day` dari titik awal yang ditentukan protokol. Ambang waktunya `2026-08-08 12:00:00 UTC`; transaksi prove atau finalize, gas, dan kebijakan konfirmasi chain sumber dapat menambah waktu. Contoh berparameter ini tidak menyatakan setiap bridge menunggu tujuh hari, dan finalitas transaksi tujuan tidak otomatis melepaskan dana sumber.
- **Quote rute cepat dibanding biaya menunggu.** Untuk `10,000 USDC`, fast bridge membebankan `0.08%` ditambah `3 USDC`, tanpa gas dan slippage. Biayanya `10,000 * 0.0008 + 3 = 11 USDC` dan penerimaan langsung `9,989 USDC`. Dibanding penantian kanonis hipotetis `7-day`, harga tahunan sederhana untuk akses lebih awal adalah `(11 / 9,989) * (365 / 7) = 5.7420305193%`. Perbandingan ini bukan yield atau risk-free rate dan mengecualikan risiko solver, likuiditas, gagal bayar, serta settlement.

<a id="risks"></a>

## Risiko

- Menggunakan antarmuka phishing atau domain dokumentasi yang belum diverifikasi.
- Memilih chain sumber atau tujuan dan `chainId` yang salah.
- Mengirim ke bridge, portal, messenger, gateway, atau penerima palsu.
- Menerima token bersimbol sama dengan mapping pasangan terdaftar yang salah.
- Salah membaca decimals, unit mentah, atau perilaku transfer token nonstandar.
- Mencampur aset native, wrapped gas token, dan representasi bridged.
- Membuka allowance berlebih atau menyetujui spender yang salah.
- Melewatkan upgrade proxy, kompromi admin, tindakan security council, atau perubahan timelock.
- Menghadapi pause, denylist, rate limit, atau rute penarikan yang dibekukan.
- Menganggap receipt sumber sebagai bukti eksekusi tujuan berhasil.
- Kekurangan gas untuk eksekusi tujuan, retry, prove, claim, atau refund.
- Kehilangan pesan akibat retry kedaluwarsa, refund keliru, atau address aliasing.
- Mengabaikan reorganisasi chain sumber atau finalitas yang belum cukup.
- Bergantung pada sequencer tersensor atau tidak tersedia tanpa forced path yang bekerja.
- Kehilangan ketersediaan data yang diperlukan untuk membuktikan, membangun ulang, atau keluar dari state.
- Menerima state root, message proof, nullifier, atau kondisi replay yang tidak valid.
- Bergantung pada proposer, prover, challenger, atau permissioned finalizer yang tidak tersedia.
- Salah membaca parameter challenge, maturity, atau proof acceptance setelah upgrade.
- Mengalami insolvency escrow, accounting drift, token depeg, atau illikuiditas tujuan.
- Menambah risiko fast bridge, aggregator, verifier, LP, solver, slippage, pajak, dan sanksi.

<a id="misconceptions"></a>

## Kesalahpahaman umum

- Kanonis adalah standar universal dan otomatis berarti trustless atau bebas risiko.
- Transaksi sumber yang berhasil atau saldo yang muncul di UI membuktikan settlement final.
- Setiap penarikan rollup memiliki waktu tunggu tujuh hari yang sama.
- Escrow sumber dan representasi tujuan dapat dijumlahkan sebagai TVL independen.
- Fast bridge hanyalah bridge kanonis yang diberi pengaturan kecepatan.

<a id="related"></a>

## Topik terkait

- [Bridge lintas chain](/id/crypto/cross-chain-bridge/)
- [Rollup](/id/crypto/rollup/)
- [Jalur keluar darurat rollup](/id/crypto/rollup-escape-hatch/)

<a id="sources"></a>

## 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)
- [Withdrawals](https://specs.optimism.io/protocol/withdrawals.html) - OP Stack Specification (diakses: 2026-08-12)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (diakses: 2026-08-12)
- [L1 to L2 messaging](https://docs.starknet.io/learn/protocol/messaging) - Starknet Documentation (diakses: 2026-08-12)
- [StarkGate](https://docs.starknet.io/learn/protocol/starkgate) - Starknet Documentation (diakses: 2026-08-12)
- [Bridging assets](https://docs.zksync.io/zksync-protocol/rollup/bridging-assets) - ZKsync Docs (diakses: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (diakses: 2026-08-12)

Source: https://wiki.fcontext.com/id/crypto/canonical-bridge/index.mdx
