Le XRP Ledger a publié la version 3.2.1 d'xrpld, un correctif de production visant à arrêter l'inondation de manifestes de validateurs qui a mis à rude épreuve certaines parties de l'infrastructure pair à pair du réseau le 31 juillet 2026. xrpld est le logiciel de serveur de référence que les participants exécutent pour faire fonctionner des nœuds et des validateurs sur le XRPL. La blockchain a continué à clôturer les registres sans interruption, confirmant que le consensus est resté pleinement opérationnel même si des nœuds individuels ont subi des charges de données anormales.

XRP Ledger Operations a annoncé la version via son compte X officiel :

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

Les administrateurs de nœuds ont été invités à installer le correctif sans délai et à effectuer un second redémarrage peu après l'installation initiale. La version mise à jour introduit des contrôles qui empêchent les données de validateurs non approuvées de consommer des quantités disproportionnées de mémoire, de bande passante, de stockage et de capacité de traitement.

Comment l'inondation de manifestes a mis à rude épreuve l'infrastructure pair du XRPL

Le XRPL s'appuie sur un ensemble de validateurs que chaque opérateur désigne comme approuvés via une Unique Node List (UNL). Seuls les validateurs figurant sur l'UNL d'un nœud participent directement au processus de prise de décision de consensus de ce nœud. Les manifestes de validateurs lient l'identité maîtresse permanente d'un validateur à la clé de signature temporaire utilisée pendant les tours de consensus. Cette architecture permet aux opérateurs de faire tourner les clés de travail périodiquement tout en gardant les identifiants maîtres hors ligne et en maintenant l'identité réseau établie du validateur.

Les versions antérieures d'xrpld n'avaient pas de plafond sur le nombre de manifestes associés à des clés de validateurs inconnues qu'un nœud pouvait accepter, stocker et rediffuser. Étant donné que chaque nœud relaie les données de manifeste à ses pairs connectés sans tenir compte du statut de confiance, des données non approuvées excessives se sont propagées sur le réseau et se sont accumulées dans les caches locaux.

L'incident a affecté la propagation des messages de la couche pair plutôt que les soldes des comptes, les transactions individuelles ou les règles de validation du registre. Cette distinction est importante pour l'architecture de la blockchain en général : les failles de la couche de consensus peuvent arrêter une chaîne, tandis que les failles de la couche pair dégradent la connectivité sans compromettre l'intégrité du registre. Bien que le XRPL ait continué à traiter les transactions et à finaliser les registres à temps, la pression sur les connexions entre pairs a dégradé la connectivité et ralenti la distribution d'informations sur le réseau.

Quatre mesures de sécurité dans la version 3.2.1

La version 3.2.1 introduit six commits couvrant 13 fichiers. Les modifications mettent en œuvre des contrôles à quatre points critiques où un trafic de manifestes surdimensionné ou répété pourrait surcharger un nœud :

1. Rejet de la taille avant décodage. xrpld rejette désormais les manifestes individuels qui dépassent la taille encodée attendue avant le début du processus de décodage, empêchant ainsi les entrées surdimensionnées de déclencher un travail de calcul inutile.

2. Élimination des lots non approuvés. Les nœuds ignorent désormais les lots entrants contenant un nombre excessif de manifestes non approuvés. Il est important de noter que le logiciel évite de déconnecter automatiquement les pairs plus anciens qui transmettent des lots surdimensionnés, ce qui réduit le risque de fragmentation du réseau pendant la fenêtre de mise à niveau.

3. Limites de salutation des pairs. Le correctif restreint la salutation de manifeste en bloc échangée lorsque deux nœuds établissent une nouvelle connexion pair. Les enregistrements approuvés restent entièrement disponibles, tandis que les rumeurs non approuvées sont réduites sur les chemins d'envoi et de réception.

4. Plafond de stockage des clés inconnues. Chaque nœud peut stocker un maximum de 100 manifestes liés à des clés de validateurs inconnues. Une fois ce plafond atteint, les entrées supplémentaires sont rejetées et les manifestes non approuvés cessent d'être conservés sur le disque.

Second redémarrage requis et vérification de la clé de signature

Après l'installation de la mise à jour, les administrateurs ont été invités à attendre environ une à deux minutes et à confirmer qu'xrpld restait opérationnel. Une synchronisation complète n'est pas nécessaire avant de passer à l'étape suivante.

Une fois le service mis à jour confirmé comme étant en cours d'exécution, les opérateurs doivent redémarrer xrpld une seconde fois. L'équipe des opérations a qualifié ce second redémarrage d'étape finale essentielle de la procédure de mise à niveau.

Les administrateurs exécutant des installations empaquetées devraient également vérifier la clé de signature logicielle actuelle de Ripple. Ripple a modifié la clé GPG utilisée pour signer les paquets xrpld en février 2026, ce qui signifie que les systèmes qui n'ont pas encore approuvé la clé de remplacement pourraient ne pas recevoir de mises à niveau automatiques.

Le correctif n'introduit aucun amendement au réseau et ne modifie aucune règle de traitement des transactions. Au lieu de cela, il établit des limites strictes sur les données de pairs non approuvées à chaque étape — avant le décodage, la rediffusion, la mise en cache ou le stockage permanent. En restreignant la taille des manifestes, le volume des lots, les salutations de connexion et le stockage des clés inconnues, le XRP Ledger a fermé les quatre voies d'exploitation utilisées lors de l'inondation du 31 juillet. L'incident a démontré que l'abus de la couche pair peut surcharger des serveurs individuels même lorsque le consensus continue de fonctionner normalement, une classe de vulnérabilités que d'autres réseaux blockchain ont également traitée par le renforcement du protocole pair.

Un post-mortem complet devrait être partagé avec la communauté.