Un nouvel outil XRP Ledger transforme les tests des amendements du protocole en tableau de résultats public

Le développeur XRPL Denis Angell a lancé cette semaine un tableau de bord en direct qui évalue chaque amendement du XRP Ledger selon la part de ses fonctionnalités réellement exercée sur devnet avant son arrivée sur le réseau principal.

L’outil transforme l’état de préparation des amendements, auparavant une question de confiance dans le processus, en un tableau de suivi public qui indique précisément quels types de transactions, champs et codes de résultat n’ont encore jamais été utilisés dans une transaction réelle.

Ce que suit réellement le tableau de bord

Angell a conçu l’outil, hébergé à l’adresse amendments-staging.xrpl.foundation, pour récupérer directement auprès du nœud l’intégralité des spécifications de chaque amendement, plutôt que de les tenir à jour manuellement. Cela comprend chaque type de transaction, champ facultatif, indicateur, code de résultat et entrée de registre introduits par l’amendement.

Le tableau de bord surveille ensuite l’activité sur devnet et vérifie si une transaction validée a déjà exercé chacun de ces éléments. Les cellules vertes renvoient à la première transaction à l’avoir fait, tandis que les cellules rouges signalent ce qui n’a pas encore été testé.

Le développeur a expliqué directement le raisonnement derrière le projet :

« Chaque nouvelle fonctionnalité XRPL est déployée sous la forme d’un amendement. Les validateurs votent pour son adoption et, une fois activée, elle fait définitivement partie du protocole. Il faut donc des preuves concrètes que la fonctionnalité a été exercée de bout en bout sur devnet, et pas seulement testée isolément. »

Cette semaine, le tableau de bord suit en direct 16 amendements sur devnet, dont 13 présentent encore des éléments non testés.

Les écarts les plus importants concernent les amendements les plus récents : 65 des 107 vérifications possibles de Sponsor n’ont jamais été effectuées, XChainBridge en compte 30 manquantes sur 40, et il en manque 27 sur 102 pour MPTokensV1.

L’analyse de cette semaine a également relevé 59 problèmes dans l’ensemble : deux bugs dans les spécifications, 23 lacunes dans la documentation et 34 lacunes dans les tests.

Cette semaine, un amendement, XLS-75 (délégation des autorisations), qui permet à un compte de transférer des pouvoirs limités à une autre clé — comme le gel de lignes de confiance, et rien d’autre — a comblé les lacunes restantes dans ses tests.

Selon Angell, l’équipe a ajouté une logique qui associe chaque transaction déléguée à l’autorisation précise qui la sous-tend, puis a testé sur devnet toutes les cellules restantes, portant ainsi à 100 % la couverture des 122 vérifications réparties entre ses 12 autorisations granulaires.

Il a présenté cette initiative comme un effort collectif, encourageant les développeurs XRPL à « aller repérer les cellules rouges » et à exécuter eux-mêmes les transactions manquantes, puisque le tableau de bord détecte les nouvelles activités en quelques secondes.

Les tests des amendements se multiplient alors que leur adoption tarde

La volonté de procéder à des tests plus rigoureux avant l’activation fait suite à un cycle de mise à niveau mouvementé. Alors queCryptoPotato signalée en juillet, la mise à jour v3.2.0 de Ripple, qui a renommé le logiciel serveur principal de rippled en xrpld et réduit de 30 % à 40 % l’utilisation de la mémoire des nœuds, n’avait toujours pas été adoptée par plus de la moitié des nœuds XRPL plusieurs semaines après sa publication, alors même que 89 % de l’ensemble des validateurs de confiance du réseau l’avaient adoptée.

Source : CryptoPotato