La Liquid Network, una sidechain Bitcoin federata sviluppata e mantenuta da Blockstream dal suo lancio nel 2018 e utilizzata da exchange e società di trading per regolare più rapidamente i trasferimenti tra piattaforme Bitcoin, ha reso pubblico un incidente di sicurezza dopo che circa 4.000 BTC — circa 320 milioni di dollari all'epoca — hanno lasciato un wallet controllato dalla sua federazione. Secondo Liquid, il prelievo è stato eseguito utilizzando la Peg-Out Authorization Key (PAK) di SideSwap, eppure la rete insiste sul fatto che né questa chiave né le altre chiavi di autorizzazione siano state compromesse. Liquid ha definito i destinatari presunti hacker white-hat, e Blockstream sta cercando di contattarli tramite messaggi firmati registrati su Bitcoin.

In risposta, la rete ha disabilitato i suoi bridge node, impedendo l'invio di nuove transazioni. Agli exchange è stato inoltre chiesto di sospendere depositi e prelievi di L-BTC mentre i membri della federazione investigano. Le conseguenze di questa sospensione sono significative per la base di utenti della sidechain: poiché i movimenti di L-BTC tra gli exchange partecipanti avvengono molto più velocemente ed economicamente rispetto a quelli onchain su Bitcoin, una sospensione prolungata dei peg-out e del supporto degli exchange incide direttamente sui flussi di regolamento su cui quelle aziende si affidano.

SideSwap collega i L-BTC a un bug di Elements

Una dichiarazione successiva di SideSwap ha descritto come il suo servizio di peg-out abbia ricevuto i L-BTC e rilasciato i Bitcoin corrispondenti. Blockstream, tuttavia, non ha ancora pubblicato un post-mortem tecnico completo che identifichi la vulnerabilità o confermi ogni fase di questo resoconto, quindi la spiegazione di SideSwap va considerata preliminare.

Come chiavi sicure hanno potuto comunque rilasciare i Bitcoin

Il design di Liquid separa la validità di un asset dall'autorizzazione della sua destinazione. Secondo la documentazione di Blockstream per i L-BTC, ogni unità dovrebbe essere garantita da una quantità equivalente di Bitcoin detenuta dalla federazione. Un peg-out normale brucia i L-BTC prima di rilasciare i BTC corrispondenti.

Una PAK svolge un compito più ristretto: autorizza l'indirizzo Bitcoin che può ricevere un peg-out. Non è il meccanismo che determina se i L-BTC riscattati siano stati emessi correttamente in origine.

L'accordo multifirma della federazione richiede 11 dei 15 funzionari per autorizzare la spesa dal wallet Bitcoin. Se il resoconto di SideSwap fosse confermato, quelle firme avrebbero potuto essere crittograficamente valide anche se un precedente errore di validazione ha permesso a L-BTC creati in modo improprio di raggiungere il processo di peg-out. Una PAK sicura non avrebbe quindi impedito il prelievo se la rete avesse già accettato i L-BTC contestati come validi — l'autorizzazione poteva approvare la destinazione prevista mentre il processo di validazione degli asset non riusciva a individuare L-BTC che non avrebbero mai dovuto esistere.

Se il resoconto di SideSwap fosse confermato, i controlli dell'offerta non sono riusciti a rifiutare L-BTC creati senza un deposito Bitcoin corrispondente. Ciò spiegherebbe come chiavi di autorizzazione sicure e firme federative valide abbiano comunque potuto produrre una perdita di riserve reali.

Bitcoin stesso non è stato compromesso

L'incidente riguarda Liquid, una sidechain federata costruita con Elements, il codebase open-source che sta alla base anche di altre implementazioni basate su Liquid. Non indica che le regole di consenso di Bitcoin siano state violate né che un attaccante abbia aggirato la sicurezza della rete Bitcoin stessa. Bitcoin ha semplicemente elaborato una transazione con le firme necessarie per spendere dal wallet della federazione. Il fallimento apparente si è verificato in precedenza, all'interno del sistema responsabile dell'emissione, della validazione e del riscatto dei L-BTC.

Definire l'evento un "hack di Bitcoin" oscurerebbe quindi il punto in cui il problema si è effettivamente verificato. I BTC trasferiti erano reali, ma la spiegazione preliminare di SideSwap indica il software della sidechain di Liquid e i controlli dei peg.

I messaggi onchain mostrano un contatto, non un recupero

Messaggi allegati a transazioni Bitcoin mostrano uno scambio tra Blockstream e l'indirizzo che controlla i fondi prelevati. Blockstream ha fornito un indirizzo di restituzione, e il destinatario ha poi indicato che i Bitcoin sarebbero stati restituiti una volta corretta la vulnerabilità. I lettori possono seguire le transazioni relative all'indirizzo di restituzione indicato su Mempool.

La comunicazione è coerente con la dichiarazione white-hat del destinatario, ma non verifica l'identità o le intenzioni della persona. Una promessa di restituire i Bitcoin non equivale a un recupero completato — la conferma richiede una transazione di restituzione identificabile e il riconoscimento da parte di Liquid o Blockstream che i fondi previsti sono stati ricevuti.

Liquid afferma che gli altri asset non erano coinvolti, ma l'accesso è stato interrotto

Liquid ha dichiarato che gli altri asset emessi, tra cui USDT, DePix e asset reali tokenizzati, non erano coinvolti nell'incidente di sicurezza. In questo contesto, "non coinvolti" significa che Liquid non aveva identificato quegli asset come creati o prelevati in modo improprio.

L'interruzione operativa, tuttavia, è stata più ampia. La disabilitazione dei bridge node ha di fatto messo in pausa la sidechain, mentre gli exchange sospendevano o si preparavano a sospendere i trasferimenti di L-BTC. Un asset può rimanere intatto nel registro mentre il suo proprietario perde temporaneamente la capacità di muoverlo o riscattarlo — l'integrità dell'asset e la disponibilità dell'asset sono rischi distinti.

Il caso Coldcard ha esposto un diverso livello di sicurezza di Bitcoin

L'evento segue un separato incidente di sicurezza Bitcoin che ha coinvolto dispositivi Coldcard interessati. I due casi non sono collegati, ma illustrano fallimenti a livelli diversi: il problema di Coldcard riguardava la gestione delle transazioni del wallet, mentre il resoconto preliminare di Liquid riguarda la validazione e il riscatto di un asset di sidechain garantito da Bitcoin.

Cosa Liquid deve dimostrare prima di riavviare

Il ripristino dell'elaborazione delle transazioni non risolverebbe ogni interrogativo sollevato dal prelievo. Prima che gli utenti possano valutare in modo indipendente un riavvio, Liquid dovrebbe fornire informazioni sufficienti a verificare quanto segue:

• Un post-mortem tecnico che identifichi la vulnerabilità di Elements.
• Le versioni del software interessate e l'aggiornamento correttivo esatto.
• La conferma che il software corretto sia stato distribuito su tutta l'infrastruttura dei funzionari.
• Una riconciliazione dei L-BTC legittimi in circolazione rispetto ai Bitcoin detenuti dalla federazione.
• La conferma se i circa 3.996 BTC siano stati restituiti.
• Una spiegazione del motivo per cui il processo di peg-out ha accettato i L-BTC contestati.
• L'avviso che i bridge node e la normale elaborazione delle transazioni sono ripresi.
• La conferma degli exchange del ripristino di depositi e prelievi di L-BTC.

Una patch software risolverebbe la vulnerabilità, ma da sola non dimostrerebbe che la contabilità di Liquid sia stata ripristinata. Gli utenti necessitano inoltre di prove che le riserve Bitcoin rimanenti coprano tutti i L-BTC legittimi ancora in circolazione.

Cosa Liquid deve ancora spiegare

La domanda rimanente è perché i L-BTC contestati abbiano superato i controlli che hanno preceduto le firme della federazione. Finché Blockstream non identificherà la vulnerabilità, non riconcilierà i L-BTC legittimi in circolazione con le riserve rimanenti e non confermerà se i circa 3.996 BTC siano stati restituiti, l'esito tecnico e finanziario dell'incidente non potrà essere valutato in modo indipendente.

Questo articolo ha finalità informative e non costituisce consulenza finanziaria, legale o di investimento.