Il 14 febbraio 2026, il protocollo cross-chain Hyperbridge nell'ecosistema Polkadot ha improvvisamente smesso di funzionare. Questa notizia ha suscitato un notevole dibattito nella comunità.
Tuttavia, è importante sottolineare che questo evento non è stato un attacco hacker, né è stata sfruttata una vulnerabilità, e non ci sono stati perdite di fondi da parte degli utenti.
La ragione è che il team di Hyperbridge ha scoperto durante la migrazione dal modello Parachain a quello Parathread che l'attuale implementazione di Polkadot Runtime non genera prove di finalità di consenso utilizzabili per la validazione cross-chain.
Per un protocollo che dipende dalla prova di Polkadot per validare i messaggi cross-chain, questo significa che l'intera catena di validazione è stata interrotta. Pertanto, per prevenire l'invio da parte degli utenti di messaggi cross-chain che potrebbero non essere mai consegnati, il team di Hyperbridge ha scelto di sospendere attivamente il sistema fino a quando il problema non sarà risolto.
In termini di risultati, questa è stata una decisione ingegneristica tipica focalizzata sulla sicurezza. Ma questa questione ha anche nuovamente posto un problema più grande di fronte al settore: perché i ponti cross-chain sono sempre bersagli di eventi di sicurezza?
Nella discussione di oggi, Seun di Hyperbridge ha condiviso un punto di vista molto franco e persino un po' acuto.
Secondo lui, molte delle ragioni fondamentali dei problemi di sicurezza non sono davvero complesse: molte persone non comprendono realmente il sistema che stanno costruendo.
I sistemi blockchain coinvolgono crittografia, sistemi distribuiti e design meccanico complesso, e sono ancora un campo di ricerca in continua evoluzione. Ma nel frattempo, la motivazione di molti progetti che entrano in questo settore è, in effetti, lanciare rapidamente prodotti e ottenere rapidamente profitti. Quando l'obiettivo è 'lanciarlo il prima possibile' piuttosto che 'capire a fondo il sistema', alcune decisioni tecniche possono diventare comprensibili, ma spesso pongono anche rischi per la sicurezza.
Se decidi di costruire un protocollo, devi davvero capirlo e assumerti la responsabilità a lungo termine. Perché una volta che il sistema è in funzione, le questioni che affronterai non riguardano solo problemi tecnici, ma anche rischi di sicurezza, sicurezza dei fondi e la fiducia dell'intero ecosistema.
Quindi, nel programma di oggi, non solo ripercorreremo cosa è successo nell'evento di Hyperbridge, ma discuteremo anche alcuni problemi più fondamentali:
Perché gli attacchi ai ponti cross-chain continuano a verificarsi nel settore?
Audit, audit AI e audit della comunità, quale di queste è più efficace?
E in un settore che continua a svilupparsi rapidamente, come possono gli sviluppatori assumersi veramente la responsabilità della sicurezza?
Oggi abbiamo invitato Seun, un membro chiave di Hyperbridge, a parlare dei dettagli tecnici dietro questo evento e di alcune riflessioni più profonde sul design della sicurezza cross-chain.
Kristen: Benvenuti alla diretta di PolkaWorld, in questo episodio ci concentreremo su questo tema della sicurezza. Oggi abbiamo invitato Seun di Hyperbridge a partecipare alla discussione.
Il 14 febbraio 2026, Hyperbridge ha sospeso il funzionamento del suo ponte cross-chain dopo aver scoperto un limite tecnico nel Runtime di Polkadot. Questo problema è stato successivamente risolto e il funzionamento è stato ripristinato il 19 febbraio, senza alcuna perdita di fondi durante l'intero processo.
Innanzitutto, per aiutare gli ascoltatori a comprendere meglio il contesto, voglio sottolineare che non si è trattato di un attacco di vulnerabilità, né di un'intrusione da parte di hacker, né di un fallimento effettivo del sistema.
Ma anche così, questa sospensione ha suscitato alcune preoccupazioni nella comunità.
Quindi, per fornire un contesto alla discussione successiva, vorrei chiedere a Sean di presentarci in dettaglio cosa sia effettivamente accaduto e come il team ha affrontato il problema.
Seun: Bene, grazie per l'invito. Sono anche felice di condividere alcuni dettagli su questo evento, specialmente perché è accaduto mentre stavamo passando dal modello Parachain al modello Parathread.
In breve, Polkadot è una blockchain che può fornire verifiche per altre blockchain. Non entrerò nei dettagli su come viene implementato, ma in generale, esiste una 'relazione di protocollo' tra Polkadot e le blockchain che verifica.
In altre parole, il meccanismo di consenso di Polkadot e le prove di finalità che produce (prove di finalità) possono anche fungere da prove di finalità per queste chain verificate. Indipendentemente dal fatto che queste chain siano Parachain o Parathread, teoricamente dovrebbe essere così. Io stesso ho partecipato allo sviluppo del protocollo Polkadot, quindi sono abbastanza familiare con i suoi meccanismi interni.
Quando siamo passati dal modello Parachain al modello Parathread, il nostro CTO David ha menzionato in chat di team che il nostro Prover (generatore di prove) non funzionava più. Tra l'altro, il nostro Prover è open source, se qualcuno è interessato può trovarlo nel nostro repository di codice.
Il motivo per cui il sistema ha segnalato un errore è che non riusciva a trovare il nostro Para ID su Polkadot.
La mia prima reazione è stata: 'è normale, perché non siamo più Parachain, ma Parathread.'
All'inizio pensavo che non fosse un problema serio, significava solo che dovevamo adattare il modo in cui otteniamo le prove di Polkadot per adattarci al nuovo modello Parathread. Ma dopo un esame più approfondito, abbiamo scoperto un problema più grave; una delle nostre ipotesi fondamentali era stata infranta.
L'ipotesi è che Polkadot fornisca prove di finalità per le catene che valida (ad esempio parachain).
Ma nel modello Parathread, questo meccanismo è stato effettivamente compromesso.
A dire il vero, di solito non seguo frequentemente gli aggiornamenti del repository di codice di Polkadot. Poiché il nostro team attualmente concentra la propria energia principalmente sulla costruzione della propria infrastruttura, sviluppo di applicazioni, lavoro di integrazione e espansione commerciale. Dal nostro punto di vista, l'infrastruttura esistente può funzionare normalmente. Di solito, dobbiamo solo aggiornare periodicamente strumenti come il Polkadot SDK. Teoricamente, non dovremmo dover seguire continuamente i dettagli dello sviluppo del protocollo Polkadot stesso.
Tuttavia, dopo ulteriori indagini, abbiamo scoperto che il protocollo Polkadot, nell'attuale implementazione, esclude esplicitamente i Parathread dalle prove di consenso.
Quando non siamo più una Parachain, Hyperbridge non può più ricevere prove da Polkadot. Ricorda, Hyperbridge è essenzialmente un co-processore che esegue una grande quantità di lavoro di validazione per conto della rete collegata. E per permettere alle reti esterne di vedere ciò che sta accadendo su Hyperbridge o ricevere messaggi da Hyperbridge, devono prima validare la prova di Polkadot, e questa prova dimostra ulteriormente che lo stato di Hyperbridge è valido.
Quindi, quando questa catena di prove è stata interrotta, Hyperbridge è effettivamente rimasta bloccata.
Quindi non è che abbiamo 'sospeso' attivamente il sistema.
Certo, abbiamo anche la capacità di sospendere contratti su tutte le diverse reti per impedire alle applicazioni di continuare a inviare messaggi; è una misura di prevenzione della sicurezza.
In generale, molti contratti intelligenti hanno un meccanismo di sospensione per proteggere il sistema in caso di attacchi o situazioni impreviste.
Non avevamo mai utilizzato questo meccanismo prima, ma per precauzione lo abbiamo progettato in anticipo. A dire il vero, non pensavo davvero che lo avremmo usato, ma durante il nostro audit di sicurezza, il team di audit ci ha effettivamente suggerito di avere un meccanismo del genere, quindi lo abbiamo implementato.
In termini di risultati, la situazione era che il ponte non poteva più trasferire messaggi tra le diverse reti.
Certo, puoi ancora inviare messaggi a Hyperbridge, ma Hyperbridge non può inoltrare quei messaggi alla catena di destinazione, perché non può più dimostrare l'efficacia di quei messaggi alla rete di destinazione.
Pertanto, l'intero ponte cross-chain è stato effettivamente bloccato. Abbiamo iniziato a sospendere i nostri contratti su tutte le reti coinvolte per impedire agli utenti di continuare a effettuare transazioni.
In altre parole, se qualcuno prova a utilizzare token cross-chain o se un'app di terze parti prova a inviare messaggi cross-chain tramite Hyperbridge, i nostri contratti annulleranno direttamente quelle transazioni, impedendo così la spedizione del messaggio.
Lo scopo di questo è evitare che gli utenti inviino messaggi che potrebbero non essere mai consegnati, almeno fino a quando non risolviamo questo problema.
In sostanza, il nucleo di questo evento è che il 'contratto di protocollo' tra Polkadot e le sue chain superiori (parachains) è stato rotto.
Per quanto riguarda il motivo per cui i Fellows e il team di sviluppo di Polkadot hanno deciso di escludere i Parathread dal meccanismo di consenso, non posso commentare. Penso che sia una questione più adatta da chiedere direttamente al team di Polkadot.
Kristin: Guardando l'intero processo, il team di Hyperbridge ha risposto molto rapidamente; avete sospeso il ponte cross-chain tempestivamente, evitando così potenziali perdite di fondi.
Quindi, vorrei chiedere ulteriormente, per garantire la sicurezza di Hyperbridge, questo meccanismo di sospensione è una funzione integrata in Hyperbridge? In quali circostanze verrebbe attivato?
Seun: Sul network di Hyperbridge stesso (cioè la parachain di Hyperbridge), non esiste un meccanismo per sospendere direttamente l'intero ponte. In altre parole, non abbiamo alcun pallet a livello di runtime che possa forzare la sospensione di tutte le transazioni. Tuttavia, a livello dei contratti intelligenti distribuiti su diverse reti, possiamo controllare.
Questi contratti ci permettono di sospendere:
Inviare messaggi
Ricevere messaggi
O sospendere entrambi
Come ho detto in precedenza, non abbiamo mai utilizzato questo meccanismo. E il motivo per cui questo meccanismo esiste è proprio a causa dei suggerimenti del team di audit.
Quando Hyperbridge ha subito un audit di sicurezza, è stato gestito da SR Labs. SR Labs è anche l'ente di audit di Polkadot, responsabile dell'audit del protocollo Polkadot stesso. Durante il processo di audit, ci hanno suggerito di dover costruire un sistema in grado di sospendere il ponte cross-chain, in modo da poter proteggere rapidamente i fondi degli utenti in caso di problemi.
Questo è stato anche un suggerimento del nostro team di audit. Ritengono che per sistemi come protocolli cross-chain e protocolli DeFi, sia una prassi standard.
Il principio di base è molto semplice: ogni volta che un protocollo coinvolge fondi o asset, deve avere la capacità di sospendere i contratti in caso di problemi.
Come ho detto in precedenza, in oltre un anno da quando Hyperbridge è stato lanciato, non abbiamo mai utilizzato questo meccanismo—fino all'evento del 14 febbraio.
Kristin: Vorrei porre una domanda che potrebbe essere un po' sensibile.
Sappiamo che Hyperbridge ha subito un audit di terze parti e che l'ente di audit ha già segnalato alcuni rischi potenziali. Ma nel settore, molti protocolli di grandi dimensioni subiscono più cicli di audit di sicurezza; tuttavia, alcuni dei più grandi eventi di hacking nella storia della crittografia si sono verificati proprio in progetti che erano già stati ripetutamente auditati.
Quindi, dalla tua prospettiva, quanto è efficace l'audit di sicurezza?
Seun: A dire il vero, siamo piuttosto cauti e persino un po' scettici nei confronti degli enti di audit stessi. Proprio per questo, siamo stati molto chiari nella scelta di SR Labs come ente di audit. SR Labs è anche il team di audit per il protocollo Polkadot. Crediamo che abbiano una vasta esperienza nell'audit di protocolli multi-chain.
In effetti, il nostro team ha una grande conoscenza di questo sistema.
Personalmente, ho lavorato in Polkadot e poi sono entrato in Composable Finance, dove abbiamo costruito la prima implementazione del protocollo IBC al di fuori dell'ecosistema Cosmos. Quindi, in termini di protocolli multi-chain, abbiamo accumulato molta esperienza.
In un certo senso, potremmo anche essere più adatti ad auditare protocolli multi-chain di altri.
Dai dati operativi reali, in oltre un anno di funzionamento di Hyperbridge, sono state elaborate oltre 500 milioni di dollari in volume di transazioni, completando quasi 100.000 transazioni. E in quel periodo, non abbiamo avuto alcun evento di sicurezza.
Inoltre, il nostro sistema è progettato per essere completamente decentralizzato. In altre parole, chiunque può inviare messaggi a Hyperbridge.
Molte persone in realtà non comprendono che la sicurezza del nostro sistema è strutturalmente molto forte.
Molti ponti cross-chain esterni richiedono:
Stabilire una whitelist
Consentire solo a nodi fidati specifici di inviare messaggi
Dichiarare quali messaggi dovrebbero essere trasmessi da questi nodi
Ma Hyperbridge è completamente diverso. Il nostro sistema è completamente open source, puoi vederlo sull'esploratore di blocchi, ci sono già più di 130 relayer (nodi di intermediazione).
Il ruolo di questi relayer è determinare come i messaggi dovrebbero essere inoltrati a Hyperbridge, e l'intero processo è completato tramite prove crittografiche.
Quindi, dalla nostra esperienza, i migliori auditor sono in realtà le persone che scrivono il codice. Se tu stesso non comprendi veramente il sistema che stai costruendo, allora probabilmente non dovresti costruirlo. Soprattutto ora che viviamo nell'era della 'scrittura di codice AI' e 'vibe coding'.
Questo è anche il principio ingegneristico del nostro team: devi avere una chiara comprensione di come funziona il tuo protocollo.
Kristin: Parlando di audit, ora oltre agli audit tradizionali, stanno emergendo anche strumenti di audit AI. Hai menzionato che gli sviluppatori devono comprendere il proprio protocollo. Pensi che l'audit AI possa contribuire a migliorare la sicurezza del protocollo?
Se in futuro ci saranno strumenti di audit AI maturi, li prendereste in considerazione?
Seun: Dal nostro punto di vista, il miglior modo di audit è: una competizione di audit o un meccanismo di ricompensa per i bug. In altre parole, creeremo un pool di premi; chiunque possa scoprire un bug nel protocollo può ricevere una ricompensa. Penso che sia uno dei modi più efficaci di audit.
Molti protocolli conducono test 'pratici' adeguati in questo modo prima di lanciare sulla mainnet.
Per esempio, Uniswap, uno dei protocolli DeFi con il TVL più grande. Prima di lanciare Uniswap V4, hanno condotto una competizione di audit che è durata diversi mesi; ricordo che l'intero processo di audit è durato circa sei mesi. Durante questo periodo, molti ricercatori hanno scoperto un gran numero di bug, alcuni dei quali erano anche vulnerabilità molto gravi. Questi problemi sono stati risolti prima del lancio sulla mainnet.
Quindi, alla fine, quando il protocollo è stato lanciato sulla mainnet, la sicurezza era già stata testata in modo molto approfondito.
Quindi, dal nostro punto di vista, il miglior modo di audit è coinvolgere l'intera comunità nell'audit, piuttosto che fare affidamento solo su pochi enti di audit.
Molti enti di audit tradizionali in realtà applicano solo modelli comuni di vulnerabilità che hanno trovato in altri protocolli al tuo protocollo, senza analizzare veramente il tuo sistema, pensando a come il tuo protocollo potrebbe essere sfruttato o attaccato strutturalmente.
Kristin: Sono d'accordo con te. I membri della comunità spesso hanno più passione per il protocollo stesso e, in una certa misura, la loro comprensione del protocollo può essere più profonda di quella degli enti di audit di terze parti. Ora nel settore ci sono audit di terze parti, audit AI e persino competizioni di audit della comunità. Ma nel frattempo, nel settore Web3, gli attacchi ai ponti cross-chain continuano a verificarsi frequentemente. Sembra che non ci siano state vere lezioni apprese dal passato.
Ad esempio, quest'anno abbiamo visto diversi eventi significativi. Quindi, dalla tua prospettiva, perché gli attacchi ai ponti cross-chain continuano a verificarsi? Perché il settore sembra non aver realmente appreso lezioni dagli incidenti passati? Strutturalmente, cosa rende i ponti cross-chain obiettivi così ambiti per gli aggressori?
Seun: Penso che la realtà sia che molte persone non comprendono realmente ciò che stanno costruendo. So che può sembrare arrogante dirlo, ma il fatto è che i sistemi blockchain sono in molti modi ancora un campo di ricerca nuovo, come la crittografia, i sistemi distribuiti e il design meccanico, che sono tutti campi molto complessi. Ma molte persone che sviluppano prodotti sulla blockchain in realtà non comprendono veramente la scala, la complessità e la profondità del sistema con cui stanno lavorando.
Molte persone entrano in questo settore solo per guadagnare rapidamente. Quando guardi l'intero settore da questo punto di vista, significa che, rendendoti conto che molte persone vogliono solo sfruttare rapidamente, ti renderai conto che le decisioni tecniche fatte da molti progetti diventano 'comprensibili'.
Per gli sviluppatori, se decidi di costruire un protocollo, devi assumerti la responsabilità di quel protocollo, perché in seguito si presenteranno molti problemi di sicurezza e operativi.
Questo articolo è la prima parte della diretta; la seconda parte sarà pubblicata domani!
Video originale: https://x.com/i/broadcasts/1OGwblnyglvKB
PolkaWorld Telegram group: https://t.me/polkaworld_org
PolkaWorld YouTube channel:
https://www.youtube.com/c/PolkaWorld
PolkaWorld Twitter:
@polkaworld_org