Come funzionano i ponti cross-chain e perché sono stati rubati 4 miliardi di dollari

Introduzione

Le blockchain non comunicano tra loro. Ethereum non può leggere lo stato di Solana. Arbitrum non può verificare una transazione su Avalanche. Ogni catena mantiene il proprio libro mastro, il proprio consenso e le proprie regole di finalità. Questa isolamento è una caratteristica del design della sicurezza, ma crea un problema pratico: gli utenti detengono asset su una catena e vogliono usarli su un'altra.

I ponti esistono per risolvere questo problema. Un ponte è un sistema che consente a un utente di depositare asset sulla catena A e ricevere asset corrispondenti sulla catena B. Il concetto sembra semplice. L'implementazione è dove sono stati persi miliardi di dollari.

La difficoltà principale è la verifica. Quando un utente afferma di aver depositato 100 ETH su Ethereum e chiede 100 ETH su Arbitrum, qualcuno o qualcosa deve verificare che il deposito sia effettivamente avvenuto. Il meccanismo scelto per questa verifica determina il modello di sicurezza del ponte, la sua velocità, il suo costo e la sua superficie di attacco. Come ha notato un'analisi di Coinbase sugli hack dei ponti, i fallimenti nella sicurezza dei ponti derivano costantemente dal divario tra le assunzioni di fiducia che un ponte dichiara e quelle che effettivamente applica.

Questa guida copre come funzionano le principali architetture dei ponti, perché ciascuno dei più grandi exploit ha avuto successo e cosa controllare prima di fidarsi di un ponte con i propri fondi.

Lock-and-mint: il meccanismo originale del ponte

Il design di ponte più antico e comune è il lock-and-mint. Il meccanismo funziona in tre fasi:

1. Lock. L'utente invia token a un contratto intelligente sulla catena sorgente. I token vengono bloccati (trattenuti) in quel contratto, non bruciati o trasferiti.
2. Verify. Un insieme di validatori, relayer o un oracolo osserva il deposito sulla catena sorgente e attesta la sua validità sulla catena di destinazione.
3. Mint. Un contratto intelligente sulla catena di destinazione conia una versione sintetica del token bloccato. L'utente riceve "wrapped ETH" o "bridged USDC" che rappresenta un diritto sul originale bloccato.

Per tornare indietro, il processo si inverte: l'utente brucia il token sintetico sulla catena di destinazione, i validatori attestano la bruciatura e i token originali vengono sbloccati sulla catena sorgente.

La sicurezza del lock-and-mint dipende interamente dal passaggio di verifica. Se un attaccante può convincere la catena di destinazione che un deposito è avvenuto quando non è avvenuto, può coniare token non garantiti. Questo è esattamente ciò che è successo nei più grandi exploit dei ponti.

Il problema aritmetico. I ponti lock-and-mint devono mantenere un rapporto 1:1 tra originali bloccati e sintetici coniati. Se 10.000 ETH sono bloccati su Ethereum, esattamente 10.000 bridged ETH dovrebbero esistere sulla catena di destinazione. Qualsiasi discrepanza significa che alcuni token bridged non sono garantiti. Quando gli exploit creano sintetici non garantiti, gli ultimi utenti a riscattare trovano il vault vuoto. Questo crea una dinamica da corsa agli sportelli: una volta che la notizia di un exploit si diffonde, ogni detentore del token avvolto si precipita a riscattare, sapendo che solo i primi ad arrivare riceveranno asset reali.

Burn-and-mint: token cross-chain nativi

Burn-and-mint elimina il problema del token avvolto distruggendo l'originale e creando uno nuovo.

1. Burn. Il token viene distrutto permanentemente sulla catena sorgente.
2. Verify. L'evento di bruciatura viene verificato sulla catena di destinazione.
3. Mint. Nuovi token vengono coniati nativamente sulla catena di destinazione.

Questo modello funziona solo per token i cui emittenti controllano la coniazione su più catene. Il Protocollo di Trasferimento Cross-Chain (CCTP) di Circle per USDC è la più grande implementazione. Quando un utente trasferisce USDC da Ethereum ad Avalanche tramite CCTP, l'USDC di Ethereum viene bruciato e l'USDC nativo viene coniato su Avalanche. Non ci sono token avvolti, nessuna frammentazione della liquidità e nessun sintetico non garantito.

La limitazione è che il meccanismo di burn-and-mint richiede all'emittente del token di implementare e gestire infrastrutture su ogni catena supportata. Non è un meccanismo di uso generale. I token ERC-20 arbitrari non possono utilizzare burn-and-mint a meno che i loro sviluppatori non costruiscano l'infrastruttura di minting cross-chain. CCTP attualmente supporta oltre una dozzina di catene, ma ogni integrazione richiede il coinvolgimento diretto di Circle.

Ponte di liquidità: velocità attraverso il capitale

Un terzo modello evita sia il wrapping che il burning utilizzando pool di liquidità prefinanziati su ogni catena.

Il meccanismo:

1. Deposito. L'utente deposita token in un pool sulla catena sorgente.
2. Prelievo. L'utente (o un relayer che agisce per suo conto) preleva token equivalenti da un pool sulla catena di destinazione.
3. Ribilanciamento. Il protocollo ribilancia periodicamente i pool tra le catene per mantenere una liquidità adeguata.

Stargate (costruito su LayerZero) e Across Protocol utilizzano variazioni di questo modello. Il vantaggio è la velocità: poiché i token esistono già sulla catena di destinazione, non ci sono ritardi di minting. L'utente riceve immediatamente token reali e nativi.

Il compromesso è l'efficienza del capitale. La liquidità deve essere pre-posizionata su ogni catena supportata, e quel capitale guadagna un ritorno solo quando i ponti sono attivamente utilizzati. Durante i periodi di basso volume, i fornitori di liquidità guadagnano poco mentre il loro capitale rimane inattivo. I requisiti di capitale aggregati su tutte le catene supportate possono raggiungere centinaia di milioni di dollari, creando una barriera all'ingresso e un rischio di concentrazione se un singolo fornitore di liquidità domina.

L'hack del ponte Ronin: 624 milioni di dollari da chiavi compromesse

Il 23 marzo 2022, gli attaccanti hanno drenato 624 milioni di dollari in ETH e USDC dal ponte Ronin, che collegava Ethereum alla sidechain Ronin utilizzata dal gioco Axie Infinity.

Il ponte di Ronin utilizzava uno schema di validazione multisig. Nove nodi validatori verificavano le transazioni del ponte, e qualsiasi cinque potevano autorizzare un prelievo. L'assunzione di sicurezza era che compromettere cinque dei nove validatori indipendenti sarebbe stato impraticabile.

L'assunzione era sbagliata. Sky Mavis, l'azienda dietro Axie Infinity, controllava quattro dei nove nodi validatori. Un quinto validatore aveva concesso a Sky Mavis un permesso temporaneo di firmare per suo conto durante un periodo di alto volume di transazioni e non aveva mai revocato il permesso.

Gli attaccanti (successivamente attribuiti al gruppo Lazarus della Corea del Nord dall'FBI) hanno compromesso i sistemi di Sky Mavis e ottenuto le chiavi private per tutti e cinque i validatori. Con cinque firme su nove, hanno autorizzato due prelievi fraudolenti: 173.600 ETH e 25,5 milioni di USDC.

L'exploit non è stato scoperto per sei giorni. È emerso solo quando un utente ha cercato di prelevare 5.000 ETH e ha scoperto che il ponte non aveva fondi sufficienti.

La lezione. La sicurezza multisig è forte solo quanto l'indipendenza dei suoi firmatari. Quando un'unica organizzazione controlla la maggior parte delle chiavi, il multisig diventa un singolo punto di fallimento con passaggi aggiuntivi.

L'hack di Wormhole: 326 milioni di dollari da un bypass di verifica

Il 2 febbraio 2022, un attaccante ha sfruttato il ponte Wormhole per mintare 120.000 wETH (wrapped ETH) su Solana senza depositare alcun ETH su Ethereum. L'exploit valeva circa 326 milioni di dollari.

Il ponte di Wormhole si basava su un insieme di 19 guardiani per verificare i messaggi cross-chain. I guardiani avrebbero osservato un deposito su Ethereum, prodotto un'attestazione firmata (chiamata VAA, Verified Action Approval), e il contratto sul lato Solana avrebbe verificato le firme prima di mintare.

La vulnerabilità era nella verifica della firma sul lato Solana. Il contratto di Wormhole su Solana utilizzava un'istruzione di sistema deprecata (verify_signatures) che non convalidava correttamente gli account passati. L'attaccante ha creato un falso insieme di guardiani, ha presentato un VAA contraffatto con firme di quel falso insieme, e il contratto l'ha accettato come valido.

In effetti, l'attaccante ha detto al contratto Solana "questi guardiani hanno approvato questa mint" e il contratto non ha verificato se i guardiani fossero reali.

Jump Crypto, che ha sostenuto Wormhole, ha sostituito i 120.000 ETH rubati dalle proprie riserve. Il ripristino completo è avvenuto entro 24 ore, una risposta senza precedenti che ha impedito perdite a cascata nei protocolli DeFi di Solana che detenevano wETH.

La lezione. Il codice di verifica del bridge è una superficie di attacco di alto valore. Un singolo errore logico nel modo in cui vengono convalidate le firme può consentire una minting non autorizzata illimitata.

L'hack di Nomad: 190 milioni di dollari da un aggiornamento difettoso

Il 1° agosto 2022, il bridge Nomad è stato prosciugato di circa 190 milioni di dollari. A differenza di Ronin e Wormhole, Nomad non è stato attaccato da un gruppo sofisticato. È stato prosciugato da centinaia di singoli imitatori dopo che l'exploit iniziale è diventato pubblico.
Potresti anche essere interessato: L'hack del protocollo Cetus e l'exploit di Sui: la storia completa dietro l'attacco da 260 milioni di dollari.

Nomad utilizzava un modello di verifica ottimistica. I messaggi cross-chain venivano inviati e si assumevano validi a meno che non venissero contestati entro una finestra di 30 minuti. Un aggiornamento di routine del contratto ha introdotto un bug: il contratto è stato inizializzato con una radice fidata di 0x00, il valore bytes32 zero.

Nella logica di verifica di Nomad, ogni messaggio veniva controllato rispetto alla radice fidata. Poiché 0x00 è il valore predefinito per lo storage non inizializzato in Solidity, ogni messaggio superava automaticamente la verifica. Qualsiasi utente poteva inviare qualsiasi messaggio e il contratto lo accettava come provato.

Una volta che il primo attaccante ha dimostrato che i messaggi arbitrari venivano accettati, altri hanno copiato la transazione, cambiato l'indirizzo del destinatario e la hanno ripetuta. Il bridge è stato prosciugato da un branco di attaccanti opportunisti, compresi hacker white-hat che in seguito hanno restituito circa 36 milioni di dollari in fondi recuperati.

La lezione. I bug di inizializzazione nei contratti bridge possono essere catastrofici. Un singolo parametro configurato in modo errato ha trasformato il modello di sicurezza di Nomad da "verifica ottimistica con prove di frode" a "nessuna verifica affatto."

L'hack di Harmony Horizon: 100 milioni di dollari da un multisig due su cinque

Nel giugno 2022, il bridge Harmony Horizon ha perso 100 milioni di dollari quando gli attaccanti hanno compromesso le chiavi private di due dei cinque validatori nel multisig del bridge. Il bridge di Harmony richiedeva solo due dei cinque firmatari per approvare una transazione, una soglia insolitamente bassa per un bridge che detiene 100 milioni di dollari.

L'attacco ha rafforzato la lezione di Ronin: i bridge multisig sono sicuri solo quanto il loro set di firmatari più debole. Quando la soglia è bassa rispetto al numero di firmatari, una singola compromissione dell'infrastruttura può essere sufficiente. I ricercatori di sicurezza avevano criticato pubblicamente la soglia due su cinque di Harmony prima che si verificasse l'attacco.

La lezione. La selezione della soglia è importante quanto il numero di validatori. Un multisig cinque su nove offre una sicurezza significativamente diversa rispetto a un due su cinque, anche se entrambi utilizzano lo stesso meccanismo sottostante.

Perdite cumulative e schemi di attacco

L'entità delle perdite dei bridge è senza precedenti nella sicurezza dei contratti intelligenti. Gli exploit dei bridge rappresentano circa 3 miliardi di dollari dei 17 miliardi di dollari totali in hack di criptovalute nell'ultimo decennio, rendendo i bridge la categoria di contratti intelligenti più attaccata.

Gli schemi di attacco si raggruppano in tre categorie:

Compromissione delle chiavi. L'attaccante ottiene abbastanza chiavi di validatori o firmatari per falsificare i messaggi del bridge. Ronin e Harmony hanno seguito questo schema. La vulnerabilità non è nel codice ma nella sicurezza operativa dell'infrastruttura dei firmatari.

Bypass della verifica. L'attaccante trova un bug nella logica di verifica che consente ai messaggi falsificati di passare. Wormhole ha seguito questo schema. La vulnerabilità è un errore a livello di codice nella funzione più critica del contratto del bridge.

Errori di inizializzazione o aggiornamento. L'attaccante sfrutta una configurazione errata introdotta durante il deployment o l'aggiornamento. Nomad ha seguito questo schema. La vulnerabilità è procedurale: il team ha commesso un errore durante un'operazione di routine.

Ogni schema richiede una difesa diversa. Il compromesso della chiave è mitigato aumentando la diversità dei firmatari e utilizzando moduli di sicurezza hardware. Il bypass della verifica è mitigato attraverso audit e verifica formale. Gli errori di inizializzazione sono mitigati da procedure di aggiornamento che includono esecuzioni di test obbligatorie su reti forkate.

Un quarto schema emergente merita menzione: attacchi di governance. Un attaccante che accumula abbastanza token di governance per controllare il meccanismo di aggiornamento di un ponte può modificare il contratto del ponte per drenare fondi. Questo attacco è più lento e più visibile rispetto agli altri, ma prende di mira i ponti la cui governance è concentrata o il cui tempo di blocco sugli aggiornamenti è troppo breve. I team dei ponti utilizzano sempre più spesso blocchi temporali di diversi giorni (48-72 ore) sugli aggiornamenti dei contratti per dare agli utenti il tempo di ritirarsi prima che una modifica malevola abbia effetto.

L'alternativa basata sull'intento ai ponti tradizionali

Un approccio più recente evita completamente i contratti dei ponti utilizzando trasferimenti cross-chain basati sull'intento. Across Protocol e la modalità cross-chain di UniswapX consentono agli utenti di esprimere un intento di bridging: "Ho 1.000 USDC su Ethereum e voglio 1.000 USDC su Arbitrum." Un risolutore (chiamato relayer) invia immediatamente token dal proprio inventario sulla catena di destinazione, per poi richiedere il rimborso in un secondo momento.

Questo modello riduce la superficie di fiducia. L'utente non deposita mai token in un contratto di ponte che detiene fondi in pool. Il risolutore si assume il rischio di rimborso e il contratto di regolamento garantisce che l'utente abbia ricevuto l'output promesso. Non c'è un grande pool di asset bloccati su cui un attaccante possa mirare.

Il compromesso è la dipendenza dal risolutore: se nessun risolutore è disposto a soddisfare l'intento a un prezzo accettabile, il trasferimento non viene eseguito. Per le rotte ad alto traffico (Ethereum ad Arbitrum, Ethereum a Base), la competizione tra risolutori è forte. Per le rotte a basso volume, i risolutori potrebbero non essere attivi.

Ponti con client leggeri e verifica a conoscenza zero

Gli exploit sopra condividono una debolezza comune: si basano su validatori esterni o multisig per attestare che qualcosa sia accaduto su un'altra catena. Se quegli attestatori sono compromessi, il ponte fallisce.

I ponti con client leggeri adottano un approccio diverso. Invece di fidarsi di un insieme di validatori, la catena di destinazione esegue un client leggero che verifica direttamente il consenso della catena sorgente.

Un ponte client leggero verso Ethereum, ad esempio, seguirebbe l'insieme di validatori di Ethereum e verificherebbe gli header dei blocchi e le prove di stato on-chain. Quando un utente afferma di aver depositato token su Ethereum, il contratto del ponte verifica la prova Merkle contro l'header del blocco di Ethereum che ha già validato.

Questo approccio minimizza la fiducia: il ponte si fida del consenso della catena sorgente, non di un comitato esterno. Ma è costoso. Verificare il consenso di Ethereum su un'altra catena richiede un notevole calcolo, il che si traduce in costi di gas elevati.

Le prove a conoscenza zero offrono una soluzione al problema dei costi. Invece di verificare ogni firma di validatore on-chain, una prova ZK può comprimere la verifica in un'unica prova succinta. La catena di destinazione verifica una prova invece di centinaia di firme.

Progetti come Succinct Labs, Polymer e Lagrange stanno costruendo ponti verificati da ZK. Questi sono ancora in fase di maturazione, ma rappresentano il modello di sicurezza più forte per la comunicazione cross-chain: fidati della matematica, non del comitato. Le prime implementazioni mostrano che i costi di verifica stanno diminuendo man mano che i sistemi di prova ZK diventano più efficienti, con alcuni ponti già operativi su mainnet con tempi di prova inferiori a 30 secondi.

Cosa non copre questo

Questa guida spiega i meccanismi dei bridge e le principali vulnerabilità. Non copre:

• Strategie di bridging specifiche per token o quale bridge utilizzare per un dato asset
• Confronto dettagliato degli aggregatori di bridge (Li.Fi, Socket, Bungee)
• L'economia della fornitura di liquidità per i pool di bridge
• Protocolli di messaggistica cross-chain oltre alla loro funzione di bridging (LayerZero, Axelar, Chainlink CCIP come livelli di messaggistica generali)

Controlli pratici prima di utilizzare un bridge

Controlla il meccanismo di verifica. I bridge multisig sono il modello più debole. I bridge verificati tramite client leggeri e ZK sono i più forti. I bridge ottimisti si collocano nel mezzo. Sappi a cosa stai dando fiducia.

Guarda il set di validatori o guardiani. Per i bridge multisig, controlla quanti firmatari esistono, chi li gestisce e se sono realmente indipendenti. Se la maggior parte dei firmatari appartiene alla stessa organizzazione o giurisdizione geografica, il multisig offre una sicurezza limitata.

Esamina la storia degli audit. I contratti dei bridge sono obiettivi di alto valore. Cerca più audit indipendenti da aziende rispettabili. Un bridge che non è stato auditato, o che è stato auditato solo una volta, richiede maggiore cautela. Fai attenzione all'ambito degli audit: un audit del contratto del token non copre la logica di verifica.

Considera il valore totale bloccato rispetto al budget di sicurezza. Un bridge che detiene 500 milioni di dollari con un multisig cinque su nove presenta un profilo di rischio molto diverso rispetto a un bridge che detiene 5 milioni di dollari. Gli attaccanti prendono di mira i bridge dove il potenziale guadagno giustifica lo sforzo. L'attaccante razionale calcola se il costo di compromettere un numero sufficiente di chiavi è inferiore al valore che può essere estratto.

Testa prima con piccole somme. Prima di effettuare un bridging di valore significativo, invia una piccola transazione di prova. Verifica che l'indirizzo di ricezione, il token e l'importo siano corretti. Le transazioni di bridge sono tipicamente irreversibili.

Preferisci i bridge nativi per i rollup. Per i rollup Ethereum L2 (Arbitrum, Optimism, Base), il bridge canonico eredita la sicurezza direttamente dal consenso di Ethereum. I bridge di terze parti possono essere più veloci ma introducono ulteriori assunzioni di fiducia. Usa bridge canonici per trasferimenti di grandi dimensioni dove la sicurezza è più importante della velocità.
Leggi di più: Cosa sono i bridge cross-chain? Perché continuano a essere hackerati

Cos'è un bridge cross-chain? {#faq-question-4160687517}

Un bridge cross-chain è un sistema che trasferisce asset o dati tra due blockchain che non possono comunicare nativamente. Il bridge blocca, brucia o raggruppa token su una catena e emette token corrispondenti su un'altra, utilizzando un meccanismo di verifica per garantire che il trasferimento sia legittimo.

Perché i bridge sono stati hackerati così spesso? {#faq-question-1765570890}

I bridge sono obiettivi di alto valore perché detengono grandi pool di asset bloccati. Introducono anche complesse assunzioni di fiducia al confine tra due diversi modelli di sicurezza. Una vulnerabilità nel meccanismo di verifica (chiavi compromesse, controlli di firma difettosi, bug di inizializzazione) può consentire a un attaccante di prosciugare l'intero pool in una singola transazione.

Qual è la differenza tra lock-and-mint e burn-and-mint? {#faq-question-0293370535}

Lock-and-mint mantiene il token originale sulla catena sorgente e conia una versione sintetica (wrappata) sulla catena di destinazione. Burn-and-mint distrugge l'originale e conia un nuovo token nativo sulla destinazione. Burn-and-mint produce token nativi piuttosto che sintetici, ma richiede che l'emittente del token controlli la coniazione su entrambe le catene.

I token wrappati sono sicuri? {#faq-question-3820965888}

I token wrappati sono sicuri solo quanto il bridge che li ha emessi. Se il bridge viene sfruttato e gli asset di supporto vengono prosciugati, i token wrappati diventano privi di supporto e perdono il loro peg. Gli utenti che detengono token wrappati sopportano il rischio di sicurezza del bridge, non solo il rischio dell'asset sottostante.

Quanto tempo ci vuole per effettuare un bridging? {#faq-question-8084085272}

Varia a seconda del meccanismo. I ponti delle pool di liquidità e i ponti basati sull'intento (Across) possono completarsi in pochi secondi. I ponti lock-and-mint con verifica multisig richiedono tipicamente da 10 a 30 minuti. I ponti ottimistici con finestre di prova di frode possono richiedere 7 giorni per i prelievi da rollup ottimistici a Ethereum, anche se i ponti veloci possono anticipare la liquidità per ridurre questo tempo.

Che cos'è un ponte client leggero? {#faq-question-5264913434}

Un ponte client leggero verifica il consenso della catena sorgente direttamente sulla catena di destinazione, piuttosto che fare affidamento su un set di validatori esterni. Controlla le intestazioni dei blocchi e le prove di stato, fidandosi della sicurezza della catena sorgente. Questo è più minimizzato in termini di fiducia rispetto alla verifica multisig o ottimistica, ma costa più gas per funzionare.

Posso perdere soldi usando un ponte? {#faq-question-7660039976}

Sì. Se il ponte viene sfruttato dopo che hai depositato ma prima che tu abbia prelevato, i tuoi token bloccati potrebbero essere rubati. Se possiedi token avvolti e il ponte viene hackerato, i tuoi token avvolti potrebbero diventare privi di valore. Inoltre, indirizzi di destinazione errati o tipi di token non supportati possono comportare una perdita permanente.

Quale ponte dovrei usare? {#faq-question-1819675312}

Nessun ponte singolo è il migliore per tutte le situazioni. Per USDC, il CCTP di Circle è l'opzione più sicura perché utilizza burn-and-mint senza token avvolti. Per trasferimenti generali di ERC-20, confronta i meccanismi di verifica dei ponti disponibili. Preferisci i ponti con verifica client leggera o ZK, più audit indipendenti e una storia di operazioni sicure. Gli aggregatori di ponti come Li.Fi possono aiutare a confrontare le rotte.

*Disclaimer: Questo articolo è solo a scopo informativo e non costituisce consulenza finanziaria, d'investimento o legale. Le criptovalute comportano rischi significativi e dovresti condurre le tue ricerche prima di prendere qualsiasi decisione. Le informazioni sono accurate a partire da agosto 2026.*