Decisione di Sicurezza Straordinaria degli Sviluppatori di XRP Ledger
Gli sviluppatori di XRP Ledger stanno difendendo una decisione di sicurezza straordinaria, avendo implementato una correzione critica del protocollo senza attendere il consueto processo di approvazione dei validatori, che dura due settimane. L’aggiornamento di emergenza, rilasciato il 25 settembre, ha affrontato una vulnerabilità di 11 anni che avrebbe potuto consentire agli attaccanti di creare XRP spendibili oltre il limite di fornitura previsto della criptovaluta. Sebbene gli investigatori non abbiano trovato prove di sfruttamento, il metodo utilizzato per eliminare la minaccia ha suscitato dibattiti su come le reti decentralizzate dovrebbero rispondere alle emergenze.
Procedura di Aggiornamento e Vulnerabilità
Sotto il normale framework di governance di XRPL, le modifiche che influenzano l’elaborazione delle transazioni devono ricevere il supporto di oltre l’80% dei validatori fidati per due settimane consecutive prima dell’attivazione. Tuttavia, la patch di sicurezza di settembre ha seguito una procedura diversa. Secondo il rapporto ufficiale sulla vulnerabilità, la correzione è diventata efficace immediatamente su ciascun server dopo l’aggiornamento a xrpld 3.4.1, piuttosto che attivarsi simultaneamente attraverso un emendamento approvato. Gli sviluppatori hanno affermato che la gravità della vulnerabilità della fornitura di XRP rendeva il processo normale troppo rischioso. Pubblicare la patch lasciando il difetto sfruttabile durante un periodo di voto prolungato avrebbe potuto fornire agli attaccanti informazioni sufficienti per riprodurre lo sfruttamento.
Il problema sottostante riguardava un overflow di interi nel motore di pagamento. Transazioni costruite in modo speciale avrebbero potuto causare al sistema di accreditare più XRP di quanto il mittente avesse effettivamente pagato, creando potenzialmente nuovi token. I ricercatori hanno rintracciato il codice vulnerabile fino al 2015, sebbene non abbiano trovato prove che fosse stato sfruttato su una rete pubblica.
Conseguenze Tecniche e Risposta della Comunità
La decisione non è stata priva di conseguenze tecniche. Normalmente, gli emendamenti si attivano simultaneamente su server compatibili, garantendo che i validatori applichino regole di transazione identiche. L’aggiornamento di emergenza ha invece creato un periodo temporaneo in cui i server aggiornati avrebbero rifiutato alcune transazioni dannose, mentre le versioni più vecchie avrebbero potuto ancora accettarle. Questo disaccordo avrebbe potuto teoricamente interrompere la validazione del libro mastro se gli attaccanti avessero tentato di sfruttare la vulnerabilità prima che un numero sufficiente di validatori si fosse aggiornato. Tuttavia, il rapido rollout ha ridotto quell’esposizione. Più dell’80% degli operatori sulla Default Unique Node List aveva installato la versione 3.4.1 entro il 25 settembre, secondo la divulgazione del team di sviluppo.
La risposta è stata diversa rispetto alla separata correzione di sicurezza Batch, che ha seguito la normale procedura di emendamento e si è attivata il 9 ottobre. L’incidente ha sollevato domande su quanto potere dovrebbero esercitare gli sviluppatori e gli operatori di validatori durante gravi emergenze di rete. Le critiche si sono concentrate in parte sulla distribuzione temporanea del software prima che il codice sorgente sensibile alla sicurezza fosse reso pubblico. I sostenitori sostengono che una coordinazione immediata fosse necessaria per prevenire che gli attaccanti sfruttassero una debolezza divulgata. La XRPL Foundation ha respinto le insinuazioni secondo cui gli operatori fossero stati costretti a installare l’aggiornamento, sottolineando che i validatori hanno preso le proprie decisioni di aggiornamento.
Conclusioni e Prospettive Future
Il dibattito arriva anche mentre i prossimi aggiornamenti di prestito di XRPL continuano a muoversi attraverso il normale processo di voto, dimostrando che le modifiche di protocollo di routine richiedono ancora un supporto sostenuto dei validatori. Gli sviluppatori sostengono che bypassare gli emendamenti dovrebbe rimanere riservato a minacce di sicurezza eccezionalmente gravi, piuttosto che diventare un’alternativa standard alla governance della rete. Per i detentori di XRP, la preoccupazione immediata è stata affrontata: la vulnerabilità è stata corretta e gli investigatori hanno riportato nessuno sfruttamento noto. La domanda a lungo termine è come XRPL possa mantenere decisioni decentralizzate mentre risponde abbastanza rapidamente a future minacce critiche.
