Proposta di Ritardi Obbligatori per i Prelievi di Bitcoin
Il co-fondatore di Rootstock, Sergio Lerner, ha proposto che i bridge di Bitcoin adottino ritardi obbligatori per i prelievi, dopo che circa 4.000 BTC sono stati prelevati dal portafoglio federato di Liquid Network attraverso un peg-out non autorizzato. Lerner, scienziato capo e co-fondatore di Rootstock Labs, ha dichiarato a crypto.news che un’immediata liquidazione può trasformare un singolo errore di validazione in una perdita prima che gli operatori del bridge abbiano il tempo di reagire.
“Senza un blocco temporale, un singolo bug di validazione e una perdita totale diventano esattamente lo stesso evento, perché i fondi si muovono nel momento in cui il software dice ‘sì'”
ha affermato Lerner.
Incidente di Peg-out Non Autorizzato
I suoi commenti seguono un incidente in cui alcuni attori hanno creato L-BTC non garantiti e hanno utilizzato il servizio di peg-out di SideSwap per prelevare quasi 4.000 BTC dal portafoglio della Liquid Federation. Liquid ha descritto questi attori come presunti hacker white-hat, mentre SideSwap ha dichiarato che il suo servizio ha elaborato la richiesta perché l’L-BTC sembrava valido. Gli attori hanno successivamente restituito 3.400 BTC dopo che Blockstream ha confermato che i nodi del bridge interessati erano stati riparati. Circa 598 BTC sono rimasti in sospeso, mentre Liquid ha ripreso la produzione di blocchi senza ripristinare le transazioni o le operazioni di peg a partire dal 10 settembre.
Proposta di Lerner per un Ritardo Obbligatorio
Lerner ha affermato che un ritardo obbligatorio tra la creazione dell’L-BTC non garantito e il rilascio del BTC reale avrebbe potuto ridurre i danni. In un tale sistema, l’approvazione del software avvierebbe un periodo di attesa piuttosto che completare immediatamente il prelievo. Strumenti di monitoraggio automatizzati potrebbero confrontare il peg-out richiesto con il BTC a supporto dell’L-BTC e segnalare eventuali squilibri prima della liquidazione.
“Se Liquid avesse avuto un blocco temporale — dove i fondi non possono muoversi per un periodo specificato, indipendentemente da ciò che dice il software o gli operatori — il bug avrebbe portato a un incidente gestibile piuttosto che a una catastrofe immediata e su larga scala.”
Meccanismi di Sicurezza di Rootstock
Rootstock utilizza già un meccanismo di ritardo per i prelievi di BTC attraverso il suo peg bidirezionale, sebbene le regole di consenso di Bitcoin non impongano un periodo di attesa. Il sistema si basa su moduli di sicurezza hardware specializzati chiamati PowHSM. Prima di firmare un peg-out, i dispositivi verificano indipendentemente che 4.000 blocchi di Rootstock siano stati superati, rappresentando circa 36 ore di prova di lavoro cumulativa. Le chiavi private rimangono all’interno dei dispositivi, secondo Lerner, e i funzionari non possono istruire l’hardware a bypassare il periodo richiesto.
Controlli di Revoca e Sicurezza
Lerner ha affermato che funzionari compromessi potrebbero interrompere le operazioni di peg, creando un problema di vitalità, ma le regole HSM impedirebbero loro di forzare un prelievo non autorizzato. Quando gli strumenti di monitoraggio identificano attività sospette, i funzionari possono spegnere i loro HSM in modo che il peg-out in sospeso non riceva alcuna firma. Lerner ha descritto la pausa come un modo per proteggere il BTC sottostante mentre gli operatori esaminano il problema e decidono come procedere.
“Una maggioranza collusa può, nel peggiore dei casi, fermare il peg, ma non può forzare un prelievo non autorizzato”
ha detto.
Proposte per Migliorare la Sicurezza dei Bridge
Lerner ha affermato che casseforti Bitcoin native e chiavi di revoca potrebbero spostare controlli comparabili nel protocollo di base. Un possibile mattone di costruzione è BIP-443, una proposta di bozza per un opcode chiamato OP_CHECKCONTRACTVERIFY, o OP_CCV. La proposta consentirebbe a un output di Bitcoin di trasportare dati e limitare come i suoi fondi possono muoversi attraverso transazioni future. BIP-443 descrive OP_CCV come un cambiamento di consenso che richiede un soft fork.
Lerner ha citato OP_CCV e BIP-443 come esempi di come le casseforti native potrebbero dare agli utenti o alle parti designate tempo per annullare un prelievo dopo aver rilevato credenziali rubate, software alterato o un altro evento anomalo. Spostare il meccanismo nel consenso di Bitcoin ridurrebbe la dipendenza dalle politiche HSM specifiche per il bridge, secondo Lerner. I miner, i funzionari o gli amministratori dovrebbero seguire le condizioni di spesa collegate all’output di Bitcoin, piuttosto che applicare una pausa discrezionale dopo che i fondi erano già stati trasferiti.
