Un rapport de bug récemment déposé montre que le logiciel XRP Ledger v3.2.0 enregistre une clé de validateur tandis qu’il en exécute une autre, alors qu’environ 30 % des nœuds adoptent le serveur rebaptisé.
Points clés :
- Un opérateur de nœud a signalé que la v3.2.0 consigne dans les journaux 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 est d’environ 30 %, la plupart des opérateurs restant sur la version précédente.
Un bug du XRP Ledger révèle une incohérence de clé
Le défaut, déclaré sous le numéro #7581 sur le traqueur GitHub du projet, apparaît lorsqu’un opérateur migre un validateur existant vers un nœud RPC déjà en cours d’exécution 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 indique qu’ajouter un jeton de validateur existant à un nœud actif puis redémarrer le serveur déclenche le bug sur Ubuntu 22.04, une séquence courante lors de migrations de routine.
À lire aussi : La liquidation des perpétuels Anthropic est‑elle un avertissement pour les paris crypto pré‑IPO ?
L’identité des validateurs au cœur du consensus du réseau
L’identité des validateurs est au centre 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 ; une identité obsolète ou incohérente peut donc dérouter quiconque examine la machine. Des journaux confus peuvent ralentir l’établissement de cette confiance.
Jusqu’à présent, cette incohérence n’a provoqué aucune panne. Elle allonge toutefois 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, suggérant que les journaux du service affichent la clé effectivement 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 précédents 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 alors 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 demeurent 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 à 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 maintenant cette incohérence de clé sur la nouvelle version, sans correctif publié à ce jour. Les retardataires risquent également 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