Gli sviluppatori di XRP Ledger (XRPL) hanno difeso la patch di sicurezza di emergenza distribuita per correggere un bug in grado di creare XRP al di là dell'offerta fissa della rete, sostenendo che non potevano attendere il consueto voto dei validatori di due settimane senza esporre la vulnerabilità a potenziali attaccanti.

A differenza delle reti che generano nuove monete nel tempo, XRP Ledger è stato lanciato con l'intera offerta di 100 miliardi di XRP già in esistenza — ed è per questo che un percorso di codice capace di coniare token aggiuntivi metteva in gioco una proprietà fondamentale dell'asset.

La patch è stata rilasciata il 25 settembre, tre giorni dopo una segnalazione tramite bug bounty, ed è entrata in vigore immediatamente su qualsiasi server che l'avesse installata. Secondo gli sviluppatori, ha segnato il primo scavalcamento deliberato del processo di emendamento standard della rete da quando tale sistema è stato introdotto oltre dieci anni fa. Secondo tale processo, le modifiche al protocollo vengono distribuite come emendamenti e si attivano solo dopo che più dell'80% dei validatori li ha supportati per due settimane consecutive — la stessa soglia successivamente citata dalla XRPL Foundation per difendere la migrazione obbligatoria alla versione 3.4.1.

"Con un normale voto di emendamento, la correzione sarebbe stata pubblica per settimane prima di entrare in vigore, rischiando la sicurezza della rete", hanno dichiarato gli sviluppatori di XRPL in un post su X domenica.

La correzione accelerata ha sollevato domande sul grado di decentralizzazione di XRP Ledger. Sul suo sito web, XRPL si descrive come una blockchain pubblica completamente decentralizzata — una caratterizzazione che è stata centrale negli argomenti secondo cui il suo token nativo, XRP, non dovrebbe essere classificato come security. Questi argomenti hanno un peso normativo: la Securities and Exchange Commission statunitense ha citato in giudizio Ripple a dicembre 2020, allegations di offerte di titoli non registrate di XRP, e il grado di decentralizzazione di XRP è stato un punto ricorrente in quel caso.

La correzione di sicurezza ha "sollevato molte domande"

Justin Bons, fondatore di Cyber Capital, ha dichiarato giovedì che commercializzare XRP presso gli investitori retail come decentralizzato equivale a "propria e semplice frode". Ha sostenuto che il rilascio di emergenza del 25 settembre è stato distribuito solo come binari, trattenendo temporaneamente il codice sorgente facendo pressione sugli operatori per l'aggiornamento.

La XRPL Foundation, tuttavia, ha dichiarato che la decisione di saltare il processo di emendamento standard è stata presa congiuntamente dalla Foundation, RippleX, dagli sviluppatori core e dai validatori dopo aver valutato la gravità del bug.

"Nessuna singola parte poteva prendere quella decisione da sola. Ogni validatore e operatore di nodo sceglie quale software eseguire, e la 3.4.1 è diventata obbligatoria solo tramite un normale voto di emendamento con più dell'80% di supporto dei validatori per due settimane. Le modifiche al protocollo passano ancora attraverso gli emendamenti", ha dichiarato la fondazione.

XRP Kuwait, un operatore di validatore indipendente, ha anch'esso respinto le affermazioni secondo cui gli aggiornamenti coordinati sarebbero un segnale di controllo centralizzato.

"Non concordiamo con l'affermazione secondo cui il fatto che gli operatori coordinino un aggiornamento sia di per sé prova di controllo centralizzato", ha dichiarato in un post su X. "Coordinamento non significa controllo. Operatori indipendenti possono valutare una situazione, comunicare tra loro e giungere alla stessa conclusione senza rinunciare alla propria indipendenza."

Il bug avrebbe potuto coniare XRP illimitati

Secondo il rapporto di divulgazione delle vulnerabilità del progetto, il bug era un integer overflow nel motore di pagamento di XRP Ledger, presente dal 2015.

I saldi XRP sono memorizzati come interi a 64 bit con un massimo fisso. Quando una somma superava tale massimo, il calcolo tornava a un numero più piccolo invece di fallire.

Un attaccante poteva sfruttare la vulnerabilità creando centinaia di offerte con prezzi particolari, ciascuna richiedente una quantità molto elevata di XRP, e poi inviando un unico pagamento che le consumava tutte. Il motore avrebbe accreditato a ciascun proprietario di offerta l'intero importo addebitando all'acquirente solo il piccolo totale ricavato dal wrap-around — con la differenza che si materializzava in XRP appena creati e spendibili.

L'attacco richiedeva offerte costruite deliberatamente e non poteva essere innescato dall'attività di trading normale, secondo il rapporto. Gli sviluppatori hanno dichiarato di non aver trovato prove che il problema sia mai stato sfruttato su nessuna rete pubblica.

Come una vulnerabilità in uno dei componenti principali del ledger sia rimasta non rilevata per circa un decennio resta una domanda aperta nel dibattito scaturito dalla divulgazione.