Les opérateurs de nœuds exécutant le XRP Ledger sont invités à agir rapidement. Le directeur de l’ingénierie de Ripple, Vijay Khanna, a exhorté les fournisseurs d’infrastructure, le 2 août, à terminer une mise à niveau des nœuds du XRP Ledger vers la version xrpld 3.2.1 après que les développeurs ont repéré, le 31 juillet, un déluge de manifestes de validateurs frappant le réseau. Le registre a continué à produire des blocs pendant tout l’incident, mais l’épisode a mis en évidence une faiblesse d’épuisement des ressources que Ripple a désormais entrepris de corriger avec un correctif ciblé (hotfix).
Summary
Points clés à retenir
- Un déluge de manifestes de validateurs le 31 juillet a poussé Ripple à publier xrpld 3.2.1 comme correctif d’urgence (hotfix) le 1er août.
- Le XRP Ledger a continué à clôturer les registres normalement pendant tout l’événement, sans perte de fonds confirmée, ni transactions modifiées, ni échec de consensus.
- Quatre nouveaux garde-fous limitent désormais la taille des manifestes, la taille des lots de messages, la croissance du cache pour les clés de validateurs inconnues et le partage sortant de données non fiables.
- Les opérateurs doivent effectuer la mise à niveau, confirmer que xrpld est en cours d’exécution, puis redémarrer une seconde fois pour effacer tout manifeste persistant avant le correctif.
- Ripple a fait tourner sa clé GPG de signature de paquets le 18 février, de sorte que les opérateurs doivent approuver la nouvelle clé pour que la mise à jour s’installe correctement.
Ce qui a déclenché la mise à niveau des nœuds du XRP Ledger
Le déluge s’est concentré sur les manifestes de validateurs, les enregistrements signés cryptographiquement qui lient l’identité maîtresse permanente d’un validateur à la clé temporaire qu’il utilise pour le trafic de validation au quotidien. Lorsqu’un validateur fait tourner cette clé temporaire, il diffuse un nouveau manifeste signé par sa clé maîtresse afin que les pairs du réseau puissent vérifier que le changement est légitime.
Avant le correctif, les nœuds acceptaient, mettaient en cache et rediffusaient les manifestes liés à des clés de validateurs qu’ils n’avaient jamais vues auparavant, tant que les données étaient structurellement valides. Cela créait une brèche : quelqu’un pouvait générer un grand nombre d’identités inconnues et forcer chaque nœud connecté à consommer de la mémoire, du stockage, de la bande passante et de la puissance de calcul rien qu’en traitant ce bruit. L’enregistrement de code public lié à l’incident le décrit comme une faille de propagation de manifestes plutôt qu’une compromission de compte ou de clé.
Malgré la pression sur les ressources des nœuds, XRP Ledger Operations a indiqué que le réseau a continué à clôturer les registres normalement pendant toute la durée de l’incident. Cette distinction est importante : le déluge a mis l’infrastructure à rude épreuve, mais il n’a jamais atteint le point de perturber le consensus ou de corrompre l’historique des transactions.
À l’intérieur du correctif xrpld 3.2.1
La réponse de Ripple, datée du 31 juillet et publiée sous forme de version signée tôt le 1er août, regroupe six commits sur 13 fichiers modifiés, dont quatre restreignent directement la manière dont les nœuds gèrent les manifestes provenant de validateurs non reconnus. Ensemble, ils forment quatre garde-fous conçus pour empêcher qu’un déluge similaire ne vide à nouveau les ressources des nœuds.
Le premier rejette un manifeste surdimensionné avant même qu’un nœud ne termine de le décoder, ce qui coupe le coût de traitement d’objets anormalement volumineux dès l’entrée. Le deuxième limite le nombre de manifestes non fiables pouvant circuler dans un seul message réseau, qu’un nœud reçoive des données ou les prépare pour ses pairs ; les lots surdimensionnés sont abandonnés sans rompre automatiquement la connexion, ce qui permet aux nœuds corrigés et non corrigés de continuer à communiquer pendant le déploiement.
Une troisième modification limite le nombre d’identités de validateurs inconnues que le cache de manifestes d’un nœud peut contenir, le code final fixant ce plafond à 100. Une fois le cache plein, les nouvelles clés non répertoriées sont refusées tandis que les validateurs de confiance et déjà reconnus continuent de fonctionner sans interruption. Le quatrième ajustement modifie la façon dont les données de manifestes non fiables se propagent sur le réseau, en resserrant le partage sortant des rumeurs (gossip) provenant de pairs non répertoriés tout en laissant intactes les données liées aux validateurs configurés ou approuvés. Cet équilibre est intentionnel : la rotation normale des clés de validateurs continue de fonctionner, mais la croissance incontrôlée du cache en provenance d’inconnus, elle, ne fonctionne plus.
Ce que les opérateurs de nœuds doivent faire maintenant
Les consignes de Khanna sont simples mais doivent être suivies dans l’ordre. Les opérateurs doivent installer la mise à jour standard, attendre une à deux minutes, confirmer que xrpld est effectivement en cours d’exécution, puis redémarrer le service une seconde fois.
Ce second redémarrage n’est pas une formalité. Tous les manifestes qu’un nœud d’opérateur a absorbés et stockés avant le correctif peuvent encore se trouver en mémoire ou sur le disque. L’installation de la 3.2.1 modifie la façon dont le logiciel gère les nouveaux manifestes à l’avenir, mais seul un redémarrage complet efface les données que le nœud a récupérées alors qu’il était encore vulnérable. Sauter cette étape risque de laisser en place des manifestes obsolètes et non fiables même après la correction du code lui-même.
Il y a un deuxième point de vigilance : la confiance dans les paquets. Ripple a fait tourner la clé GPG qu’il utilise pour signer les paquets xrpld le 18 février, et les installations qui n’ont pas déjà approuvé cette clé de remplacement peuvent ne pas récupérer automatiquement la mise à jour. Toute personne gérant une infrastructure XRPL devrait vérifier sa configuration de clé de signature avant de supposer que la mise à niveau s’appliquera sans accroc.
Il est important de noter que cette mise à niveau des nœuds du XRP Ledger vise exclusivement l’infrastructure, et non les détenteurs individuels. Les plateformes d’échange, dépositaires, back-ends de portefeuilles, fournisseurs de données et toute entreprise exploitant ses propres serveurs XRPL doivent confirmer la version de leurs nœuds et l’état des redémarrages. Les détenteurs ordinaires de XRP n’ont pas besoin de déplacer leurs fonds, de changer les clés de leurs portefeuilles ou d’ouvrir de nouveaux comptes à cause de ce problème — le correctif se situe entièrement au niveau des serveurs.
Pourquoi l’absence de dégâts reste importante
Aucun identifiant CVE ni estimation de pertes financières n’a été publié en lien avec ce déluge, et les éléments disponibles pointent vers une pression sur les ressources des nœuds et sur le trafic pair-à-pair plutôt que vers un vol confirmé, une transaction modifiée ou une rupture de consensus. C’est un résultat réellement rassurant pour un réseau qui règle des milliards en valeur, mais cela ne signifie pas que l’incident a été sans coût. Les attaques par épuisement des ressources qui ne touchent pas les fonds peuvent tout de même dégrader le service, ralentir les fournisseurs d’infrastructure et créer des ouvertures pour des tentatives ultérieures si les correctifs tardent à être appliqués.
C’est la pièce qui manque encore au dossier public. XRP Ledger Operations a indiqué qu’un rapport technique post-mortem suivrait, mais au 2 août, ce rapport n’avait pas encore été publié. Tant qu’il n’est pas disponible, l’identité de la personne à l’origine du déluge, le volume réel de manifestes impliqués et la rapidité avec laquelle les opérateurs de nœuds du réseau ont adopté la 3.2.1 restent des questions ouvertes. Le rapport devrait également préciser à quel moment les développeurs ont détecté le trafic inhabituel et si certains nœuds individuels sont devenus injoignables, même si le registre partagé lui-même n’a jamais cessé de produire des blocs.
Ce n’est pas la première transition logicielle forcée du réseau cette année. Le correctif 3.2.1 fait suite au déploiement plus large de la 3.2.0 le 15 juin, qui a renommé le serveur de référence de rippled à xrpld et a nécessité sa propre série de mises à jour de configuration — la même version qui a poussé l’opérateur d’infrastructure XRPL David Schwartz à migrer son installation avant les nouveaux changements de nommage et de protocole. Les opérateurs de nœuds ont également dû respecter une précédente échéance 3.1.3 liée à l’activation d’un amendement. Pris ensemble, ces éléments suggèrent que la couche d’infrastructure de XRPL est invitée à suivre un cycle de mises à jour de plus en plus serré, et que les opérateurs qui prennent du retard sur une seule version risquent de conserver des vulnérabilités que le réseau a déjà corrigées ailleurs.
FAQ
Qu’est-ce qui a rendu nécessaire la mise à niveau des nœuds du XRP Ledger ?
Un déluge de manifestes de validateurs s’est produit le 31 juillet, provoquant un épuisement des ressources sur les nœuds, ce qui a nécessité le correctif xrpld 3.2.1 pour atténuer le problème.
Le déluge de manifestes a-t-il entraîné des pertes de fonds ou des échecs de consensus sur le XRP Ledger ?
Aucune perte financière confirmée, aucune transaction modifiée ni aucun échec de consensus du registre n’ont été observés pendant le déluge, selon XRP Ledger Operations.
Quelles sont les principales protections introduites dans xrpld 3.2.1 ?
La mise à jour limite la taille des manifestes, la taille des lots de messages, la croissance du cache pour les clés inconnues (plafonnée à 100 entrées) et le partage sortant de manifestes non fiables.
Qui doit mettre à niveau vers xrpld 3.2.1 et quelles sont les étapes opérationnelles ?
Les fournisseurs d’infrastructure exécutant des nœuds XRPL — y compris les plateformes d’échange, les dépositaires et les opérateurs de portefeuilles — doivent effectuer la mise à niveau, vérifier que le logiciel est en cours d’exécution, puis effectuer un second redémarrage pour effacer tout manifeste persistant.
{« @context »: »https://schema.org », »@type »: »FAQPage », »mainEntity »:[{« @type »: »Question », »name »: »Qu’est-ce qui a rendu nécessaire la mise à niveau des nœuds du XRP Ledger ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Un déluge de manifestes de validateurs s’est produit le 31 juillet, provoquant un épuisement des ressources sur les nœuds, ce qui a nécessité le correctif xrpld 3.2.1 pour atténuer le problème. »}},{« @type »: »Question », »name »: »Le déluge de manifestes a-t-il entraîné des pertes de fonds ou des échecs de consensus sur le XRP Ledger ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Aucune perte financière confirmée, aucune transaction modifiée ni aucun échec de consensus du registre n’ont été observés pendant le déluge, selon XRP Ledger Operations. »}},{« @type »: »Question », »name »: »Quelles sont les principales protections introduites dans xrpld 3.2.1 ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »La mise à jour limite la taille des manifestes, la taille des lots de messages, la croissance du cache pour les clés inconnues (plafonnée à 100 entrées) et le partage sortant de manifestes non fiables. »}},{« @type »: »Question », »name »: »Qui doit mettre à niveau vers xrpld 3.2.1 et quelles sont les étapes opérationnelles ? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Les fournisseurs d’infrastructure exécutant des nœuds XRPL — y compris les plateformes d’échange, les dépositaires et les opérateurs de portefeuilles — doivent effectuer la mise à niveau, vérifier que le logiciel est en cours d’exécution, puis effectuer un second redémarrage pour effacer tout manifeste persistant. »}}]}
Article produit avec l’aide de l’intelligence artificielle et relu par l’équipe éditoriale.
