Come i bridge crypto spostano miliardi e perché gli hacker continuano a violarli

I bridge cross-chain hanno perso più denaro a causa di exploit di quasi qualsiasi altra categoria nel mondo crypto.

Il bridge Ronin ha perso 625 milioni di dollari nel 2022. Wormhole ha perso 320 milioni nello stesso anno. Nomad ha perso 190 milioni solo pochi mesi dopo.

Eppure i bridge oggi sono più importanti che mai.

TAC, Celo e dozzine di altri progetti si affidano a loro per collegare ecosistemi blockchain separati che altrimenti non potrebbero comunicare tra loro.

Capire perché i bridge sono allo stesso tempo indispensabili e pericolosi parte dal comprendere che cosa fanno davvero a livello tecnico.

TL;DR

Un bridge blockchain è un software che blocca asset su una chain e conia rappresentazioni equivalenti su un’altra, permettendo al valore di muoversi tra reti isolate.

I bridge sono obiettivi ad alto valore perché detengono in custodia asset bloccati, a volte miliardi di dollari, in smart contract o wallet multisig.

Esistono quattro principali design di bridge (lock-and-mint, burn-and-mint, pool di liquidità e verifica light client), ognuno con diversi compromessi di sicurezza.

La maggior parte dei grandi hack ha sfruttato compromissioni di chiavi dei validatori, manipolazione di oracoli o bug logici negli smart contract, non le blockchain sottostanti.

I nuovi design “trust-minimized” che usano prove a conoscenza zero stanno riducendo la superficie d’attacco, ma oggi nessun bridge è privo di rischio.

Che cosa fa davvero un bridge blockchain

Due blockchain sono, per impostazione predefinita, sistemi completamente isolati.

Bitcoin (BTC) non ha alcuna consapevolezza di Ethereum (ETH). Ethereum non può leggere nativamente un aggiornamento di stato di Solana (SOL).

Ogni chain elabora le proprie transazioni, mantiene il proprio registro e raggiunge il consenso in modo indipendente. Non esiste memoria condivisa tra loro.

Un bridge è lo strato software che crea l’illusione del movimento cross-chain.

In pratica, gli asset non “si muovono” letteralmente da una chain all’altra. Quello che succede davvero è un processo in due fasi: un asset viene bloccato (o bruciato) sulla chain di origine e una rappresentazione corrispondente viene coniata (o rilasciata) sulla chain di destinazione.

Il protocollo del bridge coordina questi due eventi e garantisce che siano collegati.

Un bridge non teletrasporta i tuoi token. Li blocca da una parte e stampa una cambiale (IOU) dall’altra — la domanda di sicurezza è sempre: chi controlla il lucchetto e chi autorizza la stampa?

Questa distinzione è enormemente importante per la sicurezza.

L’asset originale rimane in custodia da qualche parte. Quella custodia è la superficie d’attacco.

Che si tratti di uno smart contract, di un wallet multisig controllato da un comitato di validatori o di un sistema di prove crittografiche determina quasi tutto riguardo a quanto sia sicuro il bridge.

Da leggere anche: Bitget ha bloccato 150 milioni di attacchi informatici in un anno, rivela un nuovo report

I quattro principali design di bridge

Non tutti i bridge funzionano allo stesso modo. Esistono quattro pattern architetturali dominanti oggi in produzione, e ciascuno opera diversi compromessi tra sicurezza, velocità, efficienza del capitale e decentralizzazione.

Il modello Lock-and-Mint è il design più comune. Un utente invia token a uno smart contract sulla chain di origine, dove vengono bloccati. Il set di validatori del bridge osserva questo deposito e istruisce la chain di destinazione a coniare una versione “wrapped” di quel token. Wrapped Bitcoin (WBTC) su Ethereum funziona così. Lo stesso vale per la maggior parte dell’ETH bridgiato sulle prime reti Layer 2. Il token wrapped rappresenta una pretesa sull’originale bloccato. Quando un utente vuole tornare indietro, brucia il token wrapped e il lock sulla chain di origine si sblocca.

Il modello Burn-and-Mint viene usato quando l’emittente di un token controlla direttamente l’offerta su più chain. Invece di fare wrapping, il token viene bruciato sulla chain di origine (riducendo lì l’offerta totale) e coniato ex novo sulla chain di destinazione. Il Cross-Chain Transfer Protocol (CCTP) di Circle per USD Coin (USDC) funziona in questo modo. Poiché è Circle stessa ad autorizzare la mint, non esiste un pool di token bloccati che un attaccante possa rubare, ma stai affidando completamente la fiducia a Circle.

I bridge con pool di liquidità, come quelli usati da Hop Protocol e Across Protocol, funzionano in modo diverso. Invece di bloccare asset e coniare rappresentazioni, si basano su fornitori di liquidità che detengono il token nativo su entrambi i lati. Un utente deposita sulla chain di origine e un fornitore di liquidità sulla chain di destinazione gli invia immediatamente l’equivalente token nativo. L’LP viene poi rimborsato tramite il protocollo. Questo approccio è più veloce ed evita i token wrapped, ma dipende da liquidità sufficiente e introduce un rischio di controparte per i liquidity provider.

La verifica tramite light client è il design più “trust-minimized” e il più difficile da costruire. Qui la chain di destinazione esegue una prova crittografica del consenso della chain di origine direttamente all’interno di uno smart contract o di un circuito ZK. Non è richiesto alcun comitato esterno di validatori, è la matematica a dimostrare che il deposito è avvenuto. IBC (Inter-Blockchain Communication), lo standard di bridge usato tra le chain Cosmos (ATOM), approssima questo modello. I bridge basati su ZK come SP1 di Succinct e zkBridge di Polyhedra spingono questo concetto oltre, usando prove a conoscenza zero per verificare le transizioni di stato a basso costo.

Da leggere anche: HIVE ha appena preso in prestito 115 milioni di dollari a tasso zero per scommettere contro il mining di Bitcoin

Perché i bridge concentrano così tanto rischio

La superficie d’attacco di un bridge è fondamentalmente diversa da quella di una singola blockchain. Una chain come Ethereum è protetta da centinaia di miliardi di dollari in ETH in staking e da centinaia di migliaia di validatori. Comprometterla richiede compromettere una grande frazione di quel set di validatori contemporaneamente, un attacco quasi impossibilmente costoso.

Un set di validatori di un bridge è spesso molto più piccolo. Il bridge Ronin, che serviva il gioco Axie Infinity sulla sua sidechain dedicata, era protetto da soli nove nodi validatori. Un attaccante aveva bisogno del controllo di cinque di essi per autorizzare i prelievi. Il Lazarus Group, l’organizzazione di hacker sponsorizzata dallo Stato nordcoreano, ha compromesso cinque chiavi private tramite una combinazione di phishing e una falsa offerta di lavoro. Ha autorizzato prelievi fraudolenti per 625 milioni di dollari. Le chain sottostanti Ethereum e Ronin non sono mai state toccate.

L’hack di Ronin non ha violato una blockchain. Ha violato un comitato di nove validatori in cui cinque chiavi erano custodite in modo insicuro. Il bridge era l’anello più debole per design.

Questo è il problema strutturale dei bridge con validatori esterni. La loro sicurezza non è ereditata dalle chain che collegano, è un sistema separato, spesso più piccolo e meno collaudato. Più valore detiene un bridge, più diventa attraente come bersaglio, ma il modello di sicurezza non scala automaticamente con gli asset in custodia.

L’exploit di Wormhole del febbraio 2022 è stato diverso nel meccanismo ma simile nel risultato. Un attaccante ha trovato un bug nello smart contract di Wormhole su Solana che gli ha permesso di falsificare un evento di “guardian signature verification”. Ha convinto il contratto che 120.000 ETH fossero stati depositati su Ethereum quando non era vero, e ha coniato 320 milioni di dollari in ETH wrapped su Solana. Nessun validatore è stato compromesso. La vulnerabilità era nella logica del contratto stesso. Jump Crypto, il backer di Wormhole, ha rimpiazzato i fondi entro 24 ore, evitando un crollo di mercato ma senza risolvere il difetto di fondo.

Da leggere anche: Gli utenti di Polymarket perdono 3,1 milioni di dollari in un attacco al frontend mentre continua l’indagine CFTC

Il ruolo di validatori e oracoli

La maggior parte dei bridge che non sono sistemi puri basati su light client si affida a qualche forma di osservatore esterno per confermare che un deposito è avvenuto e per autorizzare la corrispondente mint o il rilascio.

Questi osservatori hanno nomi diversi — validator, relayer, guardian, attestor — ma svolgono la stessa funzione: osservano una chain e riportano lo stato a un’altra.

La domanda di fiducia è sempre: che cosa serve per far sì che questi osservatori mentano?

In un modello multisig, la risposta è “compromettere abbastanza chiavi”. In un modello basato su oracoli, la risposta può essere “manipolare il price feed o i dati di blocco che l’oracolo riporta”. In un modello di validatori proof-of-stake, la risposta è “acquisire abbastanza stake da controllare una supermaggioranza”.

LayerZero usa un modello in cui ogni applicazione configura il proprio set di oracoli e relayer, creando una sicurezza specifica per applicazione invece di un set condiviso di validatori del bridge. Questo sposta il rischio da “se un bridge fallisce, fallisce tutto” a “ogni applicazione sopporta il proprio rischio”, il che è un miglioramento significativo in termini di isolamento ma pone maggiore responsabilità sugli sviluppatori nel configurare correttamente la sicurezza.

Axelar usa una rete proof-of-stake di propri validatori per osservare gli eventi cross-chain. La sicurezza del bridge è quindi legata al valore del token di Axelar messo in staking dai validatori, un modello simile a quello di una blockchain Layer 1, ma focalizzato sulla messaggistica cross-chain.

La sfida fondamentale è che non puoi verificare nativamente lo stato di una chain esterna senza eseguire il full node di quella chain, il che è costoso. Gli approcci light client e ZK risolvono questo problema crittograficamente. Tutto il resto implica fidarsi di un intermediario che riporti onestamente.

Da leggere anche: Ethereum è diretto a 1.000 dollari dopo aver perso un supporto chiave?

Come le prove ZK stanno cambiando la sicurezza dei bridge

Le prove a conoscenza zero sono la soluzione a lungo termine più promettente al problema di fiducia dei bridge. Una prova ZK permette a una parte di dimostrare a un’altra che un’affermazione è vera, ad esempio “questa transazione è stata inclusa in un blocco finalizzato su Ethereum”, senza che il verificatore debba rieseguire tutta la computazione da solo.

Applicato ai bridge, questo significa che una chain di destinazione può verificare un evento sulla chain di origine crittograficamente, senza dover affidarsi a validatori esterni. La prova stessa è l’attestazione. Un validatore compromesso non può falsificare una prova ZK valida. Non ci sono chiavi private da rubare. La sicurezza deriva dalla matematica.

La sfida pratica è il costo computazionale. Generare prove ZK per il consenso dell’intera chain (come l’aggregazione di firme BLS del Proof of Stake di Ethereum su migliaia di validatori) richiede un lavoro computazionale sostanziale, anche se questo costo è diminuito drasticamente con la maturazione della tecnologia di proving ZK. Team come Succinct Labs, =nil; Foundation e Polyhedra stanno costruendo sistemi di proving specificamente ottimizzati per la verifica dello stato della blockchain.

TAC, la Layer 1 ora in trend su CoinGecko, adotta un approccio specifico a questo problema: mette in collegamento l’ecosistema di sviluppatori EVM di Ethereum con TON (The Open Network) e la base utenti di Telegram, utilizzando un modello ibrido di validatori e prove. Progetti come TAC illustrano la domanda pratica per i bridge: Telegram ha circa 950 milioni di utenti attivi mensili, e collegare quel pubblico alle applicazioni compatibili con Ethereum richiede esattamente il tipo di infrastruttura cross-chain che i bridge forniscono.

Il compromesso con i bridge ZK oggi è la latenza. Generare una prova per un blocco finale di Ethereum può richiedere minuti. Per applicazioni che richiedono finalità rapida, i bridge ottimistici con finestre di fraud-proof sono spesso ancora preferiti, accettando un ritardo maggiore nel prelievo (tipicamente 7 giorni sui principali optimistic rollup) in cambio di semplicità.

Also Read: Il Record Dei Wallet Chainlink Trasforma Il Rimbalzo Di LINK A 9$ Nel Test Principale

Bridge Nativi Versus Bridge Di Terze Parti

Quando sposti asset tra un Layer 1 e il suo rollup di Layer 2, in genere stai usando un "bridge nativo", un bridge costruito e mantenuto direttamente dal team del rollup, profondamente integrato con il modello di sicurezza del rollup stesso. Il bridge nativo di Arbitrum (ARB), il bridge nativo di Optimism (OP) e il bridge nativo di zkSync rientrano tutti in questa categoria.

I bridge nativi ereditano gran parte delle garanzie di sicurezza del rollup. Su un optimistic rollup, un prelievo fraudolento può essere contestato durante la finestra di 7 giorni per la fraud proof. Su un rollup ZK, un prelievo viene finalizzato solo quando una prova ZK valida del batch di transazioni è pubblicata su Ethereum. Queste sono garanzie significativamente più forti rispetto alla maggior parte dei bridge di terze parti.

Il compromesso è che i bridge nativi vanno solo in una direzione: da L1 a L2 e ritorno. Non possono portare asset di Ethereum su Solana, né spostare asset direttamente tra due L2 distinte. Per il movimento cross-ecosistema, da Ethereum a Solana o da Arbitrum a Polygon (POL), gli utenti devono usare bridge di terze parti, che comportano i rischi per validatori e smart contract descritti sopra.

Questo crea una tassonomia pratica: usare i bridge nativi per il movimento L1‑verso‑L2 quando la priorità è la sicurezza, e usare bridge di terze parti auditati, con uno storico consolidato, per il movimento cross-ecosistema quando si accetta il rischio aggiuntivo. Verificare se un bridge è stato sottoposto ad audit da una società di sicurezza rinomata (Trail of Bits, OpenZeppelin, Certik, Spearbit) e controllare eventuali precedenti di exploit è il minimo di due diligence prima di usare qualsiasi servizio di trasferimento cross-chain.

Also Read: Hacker Russi Hanno Trovato Un Punto Debole Di Signal Nelle Recovery Key

Chi Ha Davvero Bisogno Di Usare Un Bridge

I bridge non sono necessari per la maggior parte degli utenti crypto occasionali. Se possiedi Bitcoin (BTC) o Ethereum (ETH) su un exchange centralizzato e vuoi semplicemente esposizione al movimento di prezzo, non tocchi mai un bridge.

Hai bisogno di un bridge quando vuoi usare un’applicazione che vive su una chain diversa da quella in cui si trovano i tuoi asset. Se il tuo ETH è su Ethereum mainnet ma vuoi usare un protocollo DeFi su Arbitrum, usi il bridge nativo di Arbitrum. Se vuoi usare un’applicazione nativa Solana con USDC che è nato su Ethereum, usi un bridge di terze parti.

Gli sviluppatori che costruiscono applicazioni cross-chain sono i maggiori utilizzatori di bridge. Qualsiasi protocollo che voglia aggregare liquidità su più chain, o qualsiasi gioco che voglia permettere ai giocatori di usare asset su reti diverse, ha bisogno che l’infrastruttura di bridging sia integrata nel prodotto. Questo è il motivo per cui progetti come LayerZero, Axelar, Wormhole e Hyperlane si presentano come "protocollo di messaggistica omnichain" piuttosto che semplici bridge: sono infrastruttura per sviluppatori, non soltanto per utenti finali che spostano token.

Per gli utenti regolari, le indicazioni pratiche sono semplici. Usa i bridge canonici nativi quando ti sposti tra L1 e un L2 principale. Per i bridge di terze parti, limita l’esposizione a ciò che sei disposto a perdere, controlla la storia degli audit e preferisci i bridge che operano senza incidenti da almeno un anno con un TVL significativo. L’approccio "fare bridge lentamente, fare bridge con piccoli importi" non è timidezza, riflette il profilo di rischio onesto della tecnologia così come esiste oggi.

Also Read: Claude Fable 5 Potrebbe Tornare Mentre Washington Allenta Lo Stallo Con Anthropic

Considerazioni Finali

I bridge cross-chain risolvono un problema reale e inevitabile.

Le blockchain sono sistemi sovrani. Senza i bridge, il crypto sarebbe una raccolta di silos isolati in cui asset e applicazioni non interagiscono mai.

L’interoperabilità che i bridge abilitano è alla base della maggior parte della DeFi, del gaming e dell’ecosistema multi-chain che progetti come TAC stanno attivamente costruendo.

Gli hack non sono la prova che i bridge siano intrinsecamente difettosi.

Sono la prova che i primi design dei bridge hanno fatto scelte di sicurezza troppo aggressive — piccoli comitati di validatori, logica degli smart contract non auditata, dipendenze da oracoli — non proporzionate al valore che sono arrivati a detenere.

Ogni exploit di rilievo ha spinto il settore verso design migliori: set di validatori più ampi, verifica formale, sistemi di proof basati su ZK e bridge nativi dei rollup che ereditano direttamente la sicurezza di L1.