---
title: "Bridge cross-chain"
description: "Guida orientata alla verifica delle rotte cross-chain per asset e messaggi, dei modelli di fiducia, degli stati dei messaggi, della protezione dai replay, della copertura, della liquidità, delle commissioni, dei tentativi e della riconciliazione finale."
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 cross-chain
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Un bridge cross-chain è un sistema che consente a un trasferimento di asset o a un messaggio osservato in un dominio di esecuzione di produrre un risultato autorizzato in un altro. Blockchain indipendenti non considerano automaticamente attendibile lo stato reciproco. Una rotta richiede quindi un modello di verifica, regole di esecuzione sulla destinazione e, per gli asset, un modello di emissione, custodia o liquidità.
Queste dimensioni vanno separate. Gli asset possono seguire schemi lock-and-mint, burn-and-release, burn-and-mint da parte dell’emittente o consegna tramite fornitori di liquidità. I messaggi possono essere accettati mediante light client o validity proof, procedura di contestazione ottimistica, soglia di attestatori o validatori oppure verificatore specifico dell’applicazione. Ogni combinazione può presentare rischi diversi di finalità, replay, upgrade, disponibilità e solvibilità. Una transazione di origine, un’attestazione, un saldo a destinazione e il riscatto economico sono stati distinti.
## Come funziona
1. Fissare lo snapshot della rotta: protocollo e versione, `chainId` o dominio di origine e destinazione, indirizzi di gateway, router, messenger o adapter, coppia di token, destinatario, importo, decimali, scadenza, riferimenti dei blocchi e documentazione ufficiale. Nome, icona o etichetta di un aggregatore non stabiliscono l’identità.
2. Classificare due dimensioni indipendenti. Registrare se il percorso dell’asset utilizza lock-and-mint, burn-and-release, burn-and-mint dell’emittente o consegna di liquidità, e se il percorso del messaggio usa prove di consenso, light client, verifica ottimistica, attestazioni, soglia di validatori o altro verificatore.
3. Mappare le radici di fiducia e controllo. Includere finalità della fonte, disponibilità dei dati, ipotesi della prova o degli attestatori, executor di destinazione, protezione dai replay, implementazione del proxy, amministratore o security council, ritardo di upgrade, pausa e limiti di tasso. Canonico, ufficiale, sottoposto ad audit o basato su prove non è una conclusione completa sul rischio.
4. Costruire la macchina a stati del messaggio per ciascuna direzione: invio all’origine, inclusione e finalità richiesta; ID, nonce o sequenza del messaggio; prova o attestazione; relay; esecuzione a destinazione; conferma; ed eventuali nuovo tentativo, timeout, rimborso o richiesta. I percorsi di deposito e prelievo possono essere asimmetrici.
5. Costruire i registri dell’asset e del messaggio in unità grezze. Riconciliare escrow idoneo, offerta viva della rappresentazione, crediti bloccati ma non ancora emessi, crediti bruciati ma non ancora liberati, burn e mint dell’emittente, ID di messaggio consumati e autorizzazioni residue. Non contare mai escrow e sua rappresentazione come due asset indipendenti.
6. Costruire un registro economico eseguibile. Separare capitale in token e commissione di protocollo dal gas di origine e destinazione, dalla commissione del relayer o fornitore di liquidità, dalla capacità quotata, dall’output minimo, dallo slippage, dall’impatto sul prezzo e dal costo di attesa. Una quotazione non è un’esecuzione e il gas pagato in token nativo non viene automaticamente sottratto dall’output del token trasferito.
7. Riconciliare la rotta con prove effettive: ricevuta e blocco finale all’origine, stato del messaggio o pacchetto, risultato del verificatore, ricevuta e variazioni di stato a destinazione, contratto esatto del token ricevuto, saldo, riscattabilità e liquidità. Revocare le autorizzazioni eccedenti, conservare gas per il recupero e fermarsi invece di ripetere un trasferimento non spiegato.
## Esempi svolti
- **Copertura con crediti in transito.** L’escrow idoneo è `10,000 units`; la rappresentazione viva a destinazione è `9,700 units`; i crediti bloccati ma non ancora emessi sono `200 units`; e i crediti bruciati ma non ancora liberati sono `100 units`. I crediti economici sono `9,700 + 200 + 100 = 10,000 units`, quindi la copertura rettificata è `10,000 / 10,000 = 100.0000000000%`. Dividere soltanto per l’offerta viva indica erroneamente `10,000 / 9,700 = 103.0927835052%`. La copertura non dimostra la sicurezza del contratto né la liquidità immediata.
- **Output in token rispetto al costo economico.** Un utente invia `5,000 USDC`; viene dedotta una commissione di protocollo di `5 USDC`, quindi l’output in token a destinazione è `4,995 USDC`. Il gas all’origine è `0.003 ETH` e quello per la richiesta a destinazione è `0.001 ETH`; al prezzo esplicito di `2,000 USD/ETH`, questi flussi di cassa separati costano `$6` e `$2`. Il costo economico totale è `$5 + $6 + $2 = $13` e la ricchezza netta ricevuta è `$4,987`, ma il saldo a destinazione resta `4,995 USDC`.
- **Compromissione della soglia e deficit di riserva.** Un ipotetico bridge con attestatori `3-of-5` detiene `$5,000,000` in escrow e `5,000,000` unità wrapped legittime. Se tre chiavi autorizzate falsificano un mint non coperto di `1,000,000-unit`, l’offerta sale a `6,000,000`, il deficit è `$1,000,000` e la copertura pro quota è `5,000,000 / 6,000,000 = 83.3333333333%`, ossia `$0.8333333333` di riserva per token. È un risultato contabile, non un prezzo di mercato o recupero garantito.
- **Capacità di una rotta di liquidità.** La richiesta è `100,000 units`. La rotta A ha capacità `60,000` e applica `0.20%`, consegnando `60,000 * (1 - 0.002) = 59,880 units`. Una rotta B indipendente gestisce `40,000` allo `0.35%` più `20 units`, consegnando `40,000 * (1 - 0.0035) - 20 = 39,840 units`. L’output totale è `99,720 units`; il costo è `280 units`, ovvero `280 / 100,000 = 0.2800000000%`. Ogni rotta ha ipotesi di sicurezza separate e l’esecuzione parziale esiste solo se protocollo e ricevute effettivi la consentono.
## Rischi
- Selezionare origine, destinazione, `chainId` o dominio errati.
- Usare un’interfaccia, sito di documentazione o aggregatore di rotte di phishing.
- Inviare tramite gateway, router, messenger o adapter contraffatti.
- Accettare coppia di token, destinatario o rappresentazione con lo stesso simbolo errati.
- Interpretare male decimali, unità grezze o comportamento dei token fee-on-transfer e rebasing.
- Lasciare un’approval, un permit o un’autorizzazione dell’operatore eccessivi.
- Fare affidamento su una transazione di origine prima di sufficiente finalità o dopo una riorganizzazione.
- Fidarsi di chiavi compromesse di verificatori, validatori, attestatori o membri della soglia.
- Accettare light client, verificatore di prove o meccanismo di contestazione difettosi.
- Consentire errori di replay, doppio mint, sequenza, ordinamento o idempotenza.
- Trattare il successo all’origine come prova dell’esecuzione a destinazione.
- Finanziare insufficientemente il gas a destinazione per esecuzione, nuovo tentativo, richiesta o rimborso.
- Dipendere da relayer, prover, attestatori o executor non disponibili.
- Perdere disponibilità per censura del sequencer o indisponibilità dei dati.
- Non rilevare upgrade, cambio di amministratore, pausa, limite di tasso o elusione di un timelock.
- Ignorare insolvenza dell’escrow, riserve condivise o divergenze contabili in transito.
- Presumere che hook di token non standard siano compatibili con il bridge.
- Superare la capacità di liquidità o affidarsi a quotazione e percorso di ribilanciamento obsoleti.
- Subire depeg, slippage, MEV o un percorso di riscatto inutilizzabile.
- Fraintendere regole di timeout, rimborso, recupero, imposizione fiscale, sanzioni o custodia.
## Errori comuni
- La stessa moneta si sposta fisicamente da una blockchain a un’altra.
- Canonico, ufficiale, sottoposto ad audit o basato su prove significa automaticamente privo di rischio.
- Una transazione di origine riuscita garantisce l’accredito a destinazione e il regolamento finale.
- La copertura uno a uno garantisce riscatto immediato uno a uno e liquidità di mercato.
- Un bridge rapido è soltanto la stessa rotta di regolamento eseguita più velocemente.
## Argomenti correlati
- [Bridge canonico](/it/crypto/canonical-bridge/)
- [Come verificare un token ricevuto dopo un trasferimento via bridge](/it/crypto/bridge-token-verification/)
- [Rischio di disponibilità dei relayer cross-chain](/it/crypto/bridge-relayer-liveness-risk/)
## Fonti
- [Bridges](https://ethereum.org/developers/docs/bridges/) - Ethereum.org (consultato: 2026-08-12)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (consultato: 2026-08-12)
- [Messengers](https://specs.optimism.io/protocol/messengers.html) - OP Stack Specification (consultato: 2026-08-12)
- [CCTP technical guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Docs (consultato: 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 (consultato: 2026-08-12)
- [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164) - Ethereum Improvement Proposals (consultato: 2026-08-12)
- [ERC-7786: Cross-Chain Messaging Gateway](https://eips.ethereum.org/EIPS/eip-7786) - Ethereum Improvement Proposals (consultato: 2026-08-12)
- [CCIP Concepts](https://docs.chain.link/ccip/concepts) - Chainlink Documentation (consultato: 2026-08-12)
Source: https://wiki.fcontext.com/it/crypto/cross-chain-bridge/index.mdx