Come riportato questa settimana, un indirizzo associato all'exploit FTX ha spostato fondi attraverso una serie di progetti cross-chain.
Mentre la maggior parte dei fondi è passata attraverso Thorchain, alcuni di essi sono stati instradati attraverso tBTC. Nel processo, sono stati scoperti due bug.
Nessuno dei due bug mette a rischio i fondi degli utenti. Il primo è stato patchato e rilasciato ieri, mentre il secondo richiede la discussione e il consenso della comunità.
Il primo bug: un vettore di negazione del servizio
Sabato 30 settembre, un indirizzo associato a FTX ha richiesto il riscatto di 76,81431578 BTC.
In tBTC oggi, i riscatti possono essere richiesti da qualsiasi utente con un saldo tBTC L1. Dopo un po' di tempo, un responsabile off-chain delegato dal Threshold DAO nel
Coordinatore del portafoglio
contratto verifica una richiesta di riscatto, spingendo i firmatari a considerare valida una richiesta di riscatto. Se 51 dei 100 firmatari di un particolare portafoglio sono d'accordo, firmano e rilasciano congiuntamente quei fondi sulla blockchain di Bitcoin.
Dopo un po' di tempo, questa richiesta di riscatto è stata approvata dal responsabile dei riscatti. Almeno 51 dei firmatari nel portafoglio associato hanno accettato e il riscatto è stato completato.
9 ore dopo, un indirizzo diverso associato all'exploit FTX ha richiesto un altro riscatto, questa volta per 76,62186419 BTC.
Poco dopo accadde qualcosa di incredibile.
Una terza parte sconosciuta ha inviato transazioni BTC a due dei portafogli dietro tBTC.
Ora, questo accade di continuo: tBTC viene creato depositando BTC, dopotutto. Ma invece di una normale transazione di deposito, queste transazioni sono state create manualmente in modo tale che i client firmatari di tBTC pensassero che i wallet fossero "occupati" a spostare fondi e incapaci di soddisfare le richieste di riscatto. Il responsabile dell'approvazione ha atteso che i wallet non fossero più "occupati", cosa che non è mai accaduta.
Di fatto, queste transazioni BTC hanno bloccato tutti i riscatti tBTC in sospeso.
Non sappiamo chi ha inviato queste transazioni. Ma chiunque fosse, ne sapeva abbastanza da mettere in pausa forzatamente il bridge tBTC, bruciando un semplice exploit 0-day nel processo e impedendo l'approvazione del secondo riscatto associato a FTX.
Questa è una novità per me. Nessun white hat si è fatto avanti, nessuno ha offerto spiegazioni, ma il tempismo è incredibile.
A questo punto, i sistemi di allerta e monitoraggio utilizzati dai collaboratori in tutto il DAO erano a tutto volume. Il team di sviluppo di Keep ha iniziato a preparare una patch per risolvere il denial-of-service nel weekend.
A quel punto avevamo anche capito che uno dei riscatti bloccati era associato a FTX.
Il secondo bug: difetto di progettazione del meccanismo di riscatto
Il secondo bug è diventato evidente mentre preparavamo la prima patch.
La soglia DAO può delegare a più indirizzi di approvazione in
Coordinatore del portafoglio
contratto.
Sfortunatamente, fino ad oggi, c'è stata una sola delega a un singolo indirizzo di maintainer, un singolo punto di errore. Oggi, quell'indirizzo è controllato da una società di proprietà statunitense, a cui è vietato approvare il riscatto associato a FTX.
Correzione del design del meccanismo
Avere un solo approvatore delegato con 25 milioni di $ in TVL è stata una svista. Tuttavia, il problema più grande è la progettazione del meccanismo stesso.
Ogni sistema che si basa sull'approvazione esplicita di un riscatto è destinato ad avere un altro problema come questo. Quando il protocollo è stato distribuito per la prima volta, la logica di un meccanismo di approvazione era la velocità e la facilità d'uso: le alternative significavano un'esperienza utente peggiore.
Non credo che il sistema attuale abbia fatto i giusti compromessi.
Esistono due approcci chiari per correggere questo difetto
Passare da un flusso basato sull'approvazione a un flusso basato sul veto
Rimuovere tutte le revisioni di riscatto a livello di protocollo
Credo che il meccanismo di progettazione più sicuro, in futuro, sia qualcosa che chiamo "riscatti ottimistici". Invece di un elenco di indirizzi che finalizzano i riscatti, abbiamo un elenco di indirizzi che possono porre il veto su un riscatto, simile al ruolo del Guardian nel conio ottimistico.
Con questo meccanismo in atto, tutti i riscatti sono validi per impostazione predefinita. Se un riscatto viene bloccato a causa di un sospetto hack del bridge, può essere ritardato. Se viene bloccato da un numero sufficiente di guardiani, può ricorrere al voto del detentore del token. Se il veto viene confermato dal voto del detentore del token, il riscatto tBTC rifiutato può essere automaticamente restituito all'utente che ha effettuato il riscatto.
Lo svantaggio è che questo meccanismo ipotetico richiede un ritardo aggiuntivo per ogni riscatto. Nel tempo, però, quel ritardo potrebbe essere ridotto a soli 15 minuti, e completamente annullato per le piccole transazioni.
Infine, se e quando la comunità giudicherà il sistema sicuro senza un periodo di revisione del riscatto, potrebbe eliminare del tutto il ritardo, migrando senza problemi dal primo approccio al secondo. In effetti, penso che un programma chiaro per rimuovere la revisione del riscatto aiuterebbe a creare fiducia nella comunità.
Indipendentemente da come questo difetto di progettazione del meccanismo verrà risolto, abbiamo imparato molto da questa esperienza e sono contento che l'abbiamo imparato questa settimana anziché 10 volte da qui.
E ora?
La DAO e la comunità devono prendere delle decisioni.
Che la community decida di aggiungere un altro indirizzo di approvazione, di aggiornare i contratti a un meccanismo di "riscatto ottimistico" o di ricercare e valutare altre opzioni, come team di sviluppo siamo qui per consigliare e aiutare a costruire insieme un futuro della finanza più solido, sicuro e neutrale.