XRP Ledger ha rilasciato la versione 3.2.1 di xrpld, un hotfix di produzione mirato a fermare il flooding dei manifest dei validatori che ha messo sotto sforzo alcune parti dell'infrastruttura peer-to-peer della rete il 31 luglio 2026. xrpld è il software server di riferimento che i partecipanti eseguono per gestire nodi e validatori su XRPL. La blockchain ha continuato a chiudere i ledger senza interruzioni, confermando che il consenso è rimasto pienamente operativo anche mentre i singoli nodi sperimentavano carichi di dati anomali.

XRP Ledger Operations ha annunciato il rilascio tramite il suo account X ufficiale:

XRP Ledger 3.2.1 is now available. This fixes the manifest flood observed on Friday, July 31. The XRPL continued closing ledgers normally throughout. A post-mortem will follow soon for the community. Nodes previously accepted, stored and re-broadcast an unlimited number of… pic.twitter.com/ZOdT8REQCw — XRP Ledger Operations (@XRPLOperations) August 1, 2026

Gli amministratori dei nodi sono stati indirizzati a installare l'hotfix senza ritardo e ad eseguire un secondo riavvio poco dopo l'installazione iniziale. La build aggiornata introduce controlli che impediscono ai dati dei validatori non attendibili di consumare quantità sproporzionate di memoria, larghezza di banda, archiviazione e capacità di elaborazione.

Come il Flooding dei Manifest Ha Messo Sotto Sforzo l'Infrastruttura Peer di XRPL

XRPL si affida a un insieme di validatori che ogni operatore designa come attendibili tramite una Unique Node List (UNL). Solo i validatori presenti nella UNL di un nodo partecipano direttamente al processo decisionale di consenso di quel nodo. I manifest dei validatori collegano l'identità master permanente di un validatore alla chiave di firma temporanea utilizzata durante i round di consenso. Questa architettura consente agli operatori di ruotare periodicamente le chiavi di lavoro mantenendo le credenziali master offline e preservando l'identità di rete stabilita del validatore.

Le versioni precedenti di xrpld non avevano alcun limite al numero di manifest associati a chiavi di validatore sconosciute che un nodo poteva accettare, memorizzare e ritrasmettere. Poiché ogni nodo trasmette i dati del manifest ai propri peer connessi a prescindere dallo stato di attendibilità, un eccesso di dati non attendibili si è propagato attraverso la rete accumulandosi nelle cache locali.

L'incidente ha avuto un impatto sulla propagazione dei messaggi del livello peer piuttosto che sui saldi dei conti, sulle singole transazioni o sulle regole di validazione del ledger. Questa distinzione è significativa per l'architettura blockchain in generale: i guasti del livello di consenso possono bloccare una catena, mentre i guasti del livello peer degradano la connettività senza compromettere l'integrità del ledger. Sebbene XRPL abbia continuato a elaborare le transazioni e a finalizzare i ledger nei tempi previsti, lo sforzo sulle connessioni peer ha degradato la connettività e rallentato la distribuzione delle informazioni attraverso la rete.

Quattro Misure di Sicurezza nella Versione 3.2.1

La versione 3.2.1 introduce sei commit che interessano 13 file. Le modifiche implementano controlli in quattro punti critici in cui un traffico di manifest eccessivo o ripetuto potrebbe sovraccaricare un nodo:

1. Rifiuto delle dimensioni pre-decoding. xrpld ora respinge i singoli manifest che superano la dimensione codificata prevista prima che inizi il processo di decodifica, impedendo che input eccessivi attivino un lavoro computazionale non necessario.

2. Scarto dei batch non attendibili. I nodi ora scartano i batch in arrivo contenenti un numero eccessivo di manifest non attendibili. È importante notare che il software evita di disconnettere automaticamente i peer meno recenti che trasmettono batch di dimensioni eccessive, il che riduce il rischio di frammentazione della rete durante il periodo di aggiornamento.

3. Limiti per i saluti tra peer. L'hotfix limita il saluto in blocco dei manifest scambiato quando due nodi stabiliscono una nuova connessione peer. I record attendibili rimangono completamente disponibili, mentre le voci non attendibili sono ridotte sia sui percorsi di invio che su quelli di ricezione.

4. Limite di archiviazione per chiavi sconosciute. Ciascun nodo può memorizzare un massimo di 100 manifest legati a chiavi di validatore sconosciute. Una volta raggiunto questo limite, le ulteriori immissioni vengono rifiutate e i manifest non attendibili cessano di essere salvati su disco.

Secondo Riavvio Obbligatorio e Verifica della Chiave di Firma

In seguito all'installazione dell'aggiornamento, gli amministratori sono stati istruiti ad aspettare circa uno o due minuti e a confermare che xrpld rimanesse operativo. Non è richiesta la piena sincronizzazione prima di procedere al passaggio successivo.

Una volta confermato che il servizio aggiornato è in esecuzione, gli operatori devono riavviare xrpld una seconda volta. Il team delle operazioni ha descritto questo secondo riavvio come un passaggio finale essenziale nella procedura di aggiornamento.

Gli amministratori che utilizzano installazioni in pacchetto dovrebbero inoltre verificare l'attuale chiave di firma del software di Ripple. Ripple ha ruotato la chiave GPG utilizzata per firmare i pacchetti xrpld a febbraio 2026, il che significa che i sistemi che non hanno ancora affidato il trust alla chiave sostitutiva potrebbero non ricevere aggiornamenti automatici.

L'hotfix non introduce alcun emendamento di rete e non altera alcuna regola di elaborazione delle transazioni. Stabilisce invece dei limiti rigorosi sui dati peer non attendibili ad ogni tappa — prima della decodifica, della ritrasmissione, del caching o dell'archiviazione permanente. Limitando le dimensioni del manifest, il volume dei batch, i saluti di connessione e l'archiviazione di chiavi sconosciute, XRP Ledger ha chiuso i quattro percorsi di sfruttamento utilizzati durante il flooding del 31 luglio. L'incidente ha dimostrato che gli abusi del livello peer possono mettere sotto sforzo i singoli server anche mentre il consenso continua a funzionare normalmente, una classe di vulnerabilità che anche altre reti blockchain hanno affrontato tramite il rafforzamento del protocollo peer.

Si prevede che una completa analisi post-mortem sarà condivisa con la community.