---
title: "Bridge canonico"
description: "Una guida orientata alla verifica dei bridge designati dal protocollo, della copertura degli asset, degli stati dei messaggi cross-domain, dei prelievi con fault proof o validity proof, dei controlli di upgrade, delle commissioni e del confronto con i bridge rapidi."
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 canonico
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Un bridge canonico è la rotta per asset o messaggi designata da uno specifico rollup o ecosistema blockchain. Di norma collega contratti che pongono un asset in escrow o lo bruciano su una rete, trasmettono un messaggio riconosciuto dal protocollo e coniano, sbloccano o rilasciano l'asset corrispondente sull'altra rete. Il termine canonico è un'etichetta dell'ecosistema, non uno standard universale, una garanzia crittografica o la prova che sito e indirizzo siano autentici.
La sua sicurezza non è una formula additiva. Dipende congiuntamente da finalità della rete di origine, disponibilità dei dati, verifica dello stato o del messaggio, contabilità del bridge, esecuzione a destinazione, protezione dai replay, poteri di upgrade e pausa e disponibilità di un percorso di uscita. Un bridge rapido può pagare prima gli utenti con liquidità e regolare in seguito attraverso la rotta canonica, ma ciò aggiunge ipotesi su fornitore di liquidità, solver, verificatore ed esecuzione, anziché accelerare gratuitamente la stessa macchina a stati.
## Come funziona
1. Fissa l'istantanea della rotta: `chainId` di origine e destinazione, direzione, stack e versione del rollup, indirizzi di bridge, portal, messenger, inbox o gateway, indirizzi dei token, destinatario, importo, riferimenti ai blocchi e documentazione ufficiale. Non affidarti mai solo a un risultato di ricerca o all'etichetta ufficiale.
2. Determina il modello di sicurezza e controllo. Registra regole di fault proof ottimistiche o validity proof, modalità di disponibilità dei dati, sequencer e percorso forzato, implementazione del proxy, amministratore o security council, timelock, stato di pausa, limiti di frequenza e ritardo di upgrade. Canonico non significa immutabile.
3. Classifica il registro dell'asset. Distingui il valore nativo dai token ERC-20 e identifica il comportamento lock-and-mint, burn-and-release o burn-and-mint. Verifica coppia di token registrata, unità grezze, decimali, custom gateway e supporto per asset fee-on-transfer, rebasing o soggetti a denylist.
4. Costruisci la macchina a stati dei messaggi specifica per la direzione. Un deposito può attraversare approvazione, escrow o burn all'origine, finalità all'origine, derivazione o relay e mint o sblocco a destinazione. Un prelievo può richiedere burn o escrow a destinazione, inclusione del messaggio, state commitment, prova, contestazione o accettazione della prova, finalizzazione e rilascio all'origine.
5. Segui separatamente tre orologi: inclusione della transazione, regolamento del protocollo o finalità dello stato e disponibilità dell'asset per l'uso o il prelievo. Registra hash della transazione di origine, hash del messaggio o del prelievo, riferimento a output o prova e ogni transazione di relay, prove, finalize, claim, retry o refund.
6. Costruisci il registro economico. Separa capitale trasferito, gas su origine e destinazione, gas di prova o finalizzazione, commissione del protocollo o del relayer, commissione del fornitore di liquidità, slippage e costo opportunità dell'attesa. Confronta bridge rapido e rotta canonica come diritti e modelli di fiducia diversi.
7. Riconcilia la rotta completata con ricevute, eventi, saldi in escrow, offerta della rappresentazione, diritti pendenti, saldi del destinatario e allowance residue. Attendi la finalità richiesta, mantieni gas di emergenza, prova i percorsi permissionless o forzati quando applicabile e fermati invece di ripetere un deposito il cui stato del messaggio non è spiegato.
## Esempi svolti
- **Registro del deposito di un asset nativo.** Un utente parte con `5.0000 ETH`, deposita `2.5000 ETH` e paga `0.0042 ETH` di gas sulla rete di origine. Il wallet di origine termina con `5.0000 - 2.5000 - 0.0042 = 2.4958 ETH`; l'escrow aumenta di `2.5000 ETH`; e, dopo un relay riuscito uno a uno, la rappresentazione a destinazione aumenta di `2.5000 ETH`. Il rapporto di copertura è `2.5000 / 2.5000 = 100%`. Escrow e rappresentazione sono copertura e diritto, non `5 ETH` di nuovo valore economico.
- **Unità grezze e mappatura del token.** Un utente deposita `1,250.000000 USDC`. Il contratto di origine verificato usa `6 decimals`, quindi l'importo grezzo è `1,250 * 10^6 = 1,250,000,000`. Con una mappatura verificata uno a uno e senza commissioni del token, l'escrow all'origine e il mint a destinazione variano ciascuno di `1,250,000,000 raw units`, visualizzati a destinazione come `1,250.000000 USDC`. Un token con lo stesso simbolo a un altro indirizzo non costituisce una prova equivalente.
- **Gli orologi di prelievo sono distinti.** Supponiamo che un deployment registri un prelievo alle `2026-08-01 12:00:00 UTC` e applichi un periodo di contestazione di `604,800-second = 7-day` a partire da quell'inizio definito dal protocollo. La soglia temporale è `2026-08-08 12:00:00 UTC`; una transazione di prove o finalize, il gas e la politica scelta di conferma della rete di origine possono aggiungere altro tempo. Questo esempio parametrico non afferma che ogni bridge attenda sette giorni e la finalità della transazione a destinazione non rilascia da sola i fondi all'origine.
- **Quotazione della rotta rapida rispetto al costo di attesa.** Per `10,000 USDC`, un bridge rapido addebita `0.08%` più `3 USDC`, ignorando gas e slippage. Il costo è `10,000 * 0.0008 + 3 = 11 USDC` e il ricavo immediato è `9,989 USDC`. Rispetto a un'attesa canonica ipotetica di `7-day`, il prezzo annualizzato semplice dell'accesso anticipato è `(11 / 9,989) * (365 / 7) = 5.7420305193%`. Il confronto non è un rendimento né un tasso privo di rischio ed esclude rischi di solver, liquidità, insolvenza e regolamento.
## Rischi
- Usare un'interfaccia di phishing o un dominio di documentazione non verificato.
- Selezionare rete di origine o destinazione e `chainId` sbagliati.
- Inviare a bridge, portal, messenger, gateway o destinatario contraffatti.
- Accettare un token con lo stesso simbolo ma una mappatura di controparte registrata diversa.
- Interpretare male decimali, unità grezze o comportamento di trasferimento non standard.
- Confondere asset nativi, wrapped gas token e rappresentazioni trasferite tramite bridge.
- Esporre un'allowance eccessiva o approvare lo spender errato.
- Non rilevare upgrade del proxy, compromissione dell'amministratore, intervento del security council o modifica del timelock.
- Incontrare una pausa, denylist, limite di frequenza o rotta di prelievo bloccata.
- Trattare una ricevuta all'origine come prova che l'esecuzione a destinazione sia riuscita.
- Finanziare insufficientemente il gas di esecuzione, retry, prove, claim o refund a destinazione.
- Perdere un messaggio per scadenza del retry, gestione errata del refund o address aliasing.
- Ignorare una riorganizzazione della rete di origine o una finalità insufficiente.
- Dipendere da un sequencer che censura o non è disponibile senza un percorso forzato funzionante.
- Perdere la disponibilità dei dati necessaria per provare, ricostruire o abbandonare lo stato.
- Accettare una state root, prova del messaggio, nullifier o condizione di replay non validi.
- Dipendere da proposer, prover, challenger o finalizer permissioned non disponibili.
- Interpretare male un parametro di contestazione, maturità o accettazione della prova dopo un upgrade.
- Subire insolvenza dell'escrow, divergenza contabile, depeg del token o illiquidità a destinazione.
- Aggiungere rischi di bridge rapido, aggregatore, verificatore, LP, solver, slippage, imposte e sanzioni.
## Idee errate comuni
- Canonico è uno standard universale e significa automaticamente trustless o privo di rischio.
- Una transazione riuscita all'origine o un saldo apparso nella UI dimostrano il regolamento definitivo.
- Ogni prelievo da rollup prevede lo stesso periodo di attesa di sette giorni.
- Escrow all'origine e rappresentazioni a destinazione possono essere sommati come TVL indipendente.
- Un bridge rapido è semplicemente lo stesso bridge canonico con un'impostazione di velocità.
## Argomenti correlati
- [Bridge cross-chain](/it/crypto/cross-chain-bridge/)
- [Rollup](/it/crypto/rollup/)
- [Meccanismo di uscita del rollup](/it/crypto/rollup-escape-hatch/)
## Fonti
- [Bridges](https://ethereum.org/developers/docs/bridges/) - Ethereum.org (consultato il: 2026-08-12)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (consultato il: 2026-08-12)
- [Withdrawals](https://specs.optimism.io/protocol/withdrawals.html) - OP Stack Specification (consultato il: 2026-08-12)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (consultato il: 2026-08-12)
- [L1 to L2 messaging](https://docs.starknet.io/learn/protocol/messaging) - Starknet Documentation (consultato il: 2026-08-12)
- [StarkGate](https://docs.starknet.io/learn/protocol/starkgate) - Starknet Documentation (consultato il: 2026-08-12)
- [Bridging assets](https://docs.zksync.io/zksync-protocol/rollup/bridging-assets) - ZKsync Docs (consultato il: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
Source: https://wiki.fcontext.com/it/crypto/canonical-bridge/index.mdx