Un nouveau rapport de bug montre que la v3.2.0 du XRP Ledger journalise une clé de validateur tout en en exécutant une autre, alors qu’environ 30 % des nœuds adoptent le serveur renommé.
Points clés :
- Un opérateur de nœud a signalé que la v3.2.0 journalise la nouvelle clé d’un validateur migré alors que le serveur utilise encore l’ancienne.
- Le défaut apparaît sur Ubuntu 22.04 lorsqu’un jeton de validateur existant est ajouté à un nœud RPC déjà en service.
- L’adoption de la mise à niveau avoisine 30 %, la plupart des opérateurs restant sur la version précédente.
Un bug du XRP Ledger révèle un décalage de clé
Le défaut, signalé sous le numéro #7581 sur le suivi GitHub du projet, apparaît après qu’un opérateur migre un validateur existant vers un nœud RPC déjà en fonctionnement, puis redémarre le service. Le journal de service indique la nouvelle identité du validateur migré, tandis que l’endpoint server_info continue de renvoyer l’ancienne clé stockée dans le fichier local wallet.db. Les deux enregistrements ne correspondent plus.
Reproduire cette divergence demande peu d’efforts. L’opérateur explique qu’ajouter un jeton de validateur existant à un nœud actif puis redémarrer le serveur déclenche le problème sur Ubuntu 22.04, une séquence courante lors de migrations de routine.
À lire aussi : La vente de perpétuels Anthropic est‑elle un avertissement pour les paris crypto pré‑IPO ?
L’identité des validateurs ancre le consensus du réseau
L’identité des validateurs est au cœur du mécanisme par lequel le XRP Ledger s’accorde sur chaque nouveau registre. Les propositions d’un nœud ne pèsent que lorsque les autres serveurs font confiance à sa clé via leurs listes uniques de nœuds, de sorte qu’une identité obsolète ou incohérente peut perturber quiconque inspecte la machine. Un journal confus peut ralentir cette confiance.
Jusqu’à présent, ce décalage n’a provoqué aucune panne. Néanmoins, il allonge la liste de défauts que les développeurs ont signalés depuis la sortie à la mi‑mois, allant des échecs de synchronisation à un crash de l’analyseur de configuration.
Le rapporteur a proposé un correctif, demandant que les journaux de service affichent la clé réellement utilisée par le serveur ou montrent ensemble la clé dérivée et la clé active. Aucun mainteneur n’a encore été affecté à ce rapport. Plusieurs signalements antérieurs ont déjà été confirmés comme des bugs et placés en file d’examen, tandis que d’autres restent ouverts le temps que les contributeurs les évaluent.
L’adoption traîne tandis que le vote sur l’amendement se poursuit
L’adoption de cette version reste lente. Environ 30 % des nœuds exécutent maintenant la version 3.2.0, tandis que la plupart des opérateurs restent sur la version 3.1.3 précédente, selon les données publiques du réseau.
Le déploiement a commencé le 15 juin, lorsque la mise à jour a renommé le logiciel principal de rippled en xrpld et promis des économies de mémoire de 30 % à 40 %. Depuis, les opérateurs ont signalé des ruptures de synchronisation, des erreurs de relais et désormais ce décalage de clé dans la nouvelle version, sans correctif publié pour l’instant. Les retardataires risquent aussi de se retrouver dans un état bloqué par amendement une fois que les validateurs auront ratifié fixCleanup3_2_0, le changement de nettoyage que Ripple soutient déjà dans le vote en cours.
À lire ensuite : Mane City Mobile arrive sur iOS et Android dans plus de 100 pays