Les constructeurs XRPL peuvent utiliser le tableau de bord pour identifier les cas extrêmes non testés sans avoir à inspecter manuellement chaque spécification de modification.
Le développeur XRPL, Denis Angell, a lancé cette semaine un tableau de bord en direct qui note chaque modification du XRP Ledger en fonction de la quantité de fonctionnalités réellement exercées sur le devnet avant d'atteindre le réseau principal.
L'outil transforme la préparation aux modifications, auparavant une question de confiance dans le processus, en une carte de pointage publique qui montre exactement quels types de transactions, champs et codes de résultat n'ont jamais été touchés par une transaction réelle.
Ce que le tableau de bord suit réellement
Angell a construit l'outil, hébergé sur Amendments-staging.xrpl.foundation, pour lire la surface complète des spécifications de chaque amendement directement à partir du nœud plutôt que de la maintenir à la main. Cela inclut chaque type de transaction, champ facultatif, indicateur, code de résultat et écriture comptable introduit par l’amendement.
Le tableau de bord surveille ensuite l'activité de Devnet et vérifie si une transaction validée a déjà été exécutée, avec des cellules vertes liées à la transaction qui l'a effectuée en premier et des cellules rouges marquant ce qui ne s'est pas encore produit.
Le développeur a expliqué directement le raisonnement derrière le projet en disant :
« Chaque nouvelle fonctionnalité XRPL est livrée sous forme d'amendement. Les validateurs la votent, et une fois active, elle fait partie du protocole pour de bon. Cela mérite une preuve réelle que la fonctionnalité a été utilisée de bout en bout sur Devnet, et pas seulement testée de manière isolée. «
Depuis cette semaine, le tableau de bord surveille 16 amendements en direct sur Devnet, et 13 d'entre eux ont encore une surface non testée.
Les écarts les plus importants résident dans les modifications les plus récentes : le sponsor n'a jamais exercé 65 de ses 107 contrôles possibles, XChainBridge en manque 30 sur 40 et MPTokensV1 est à court de 27 sur 102.
Vous aimerez peut-être aussi :
L'analyse de cette semaine a également révélé 59 résultats sur l'ensemble de l'ensemble : deux bogues de spécifications, 23 lacunes dans la documentation et 34 lacunes dans les tests.
Un amendement, la délégation d'autorisation XLS-75, qui permet à un compte de transférer des pouvoirs étroits à une autre clé, comme le gel des lignes de confiance et rien d'autre, a comblé les lacunes restantes des tests cette semaine.
Selon Angell, l'équipe a ajouté une logique mappant chaque transaction déléguée à l'autorisation spécifique qui la sous-tend, puis a exercé chaque cellule restante sur Devnet, apportant ainsi les 122 contrôles sur ses 12 autorisations granulaires à une couverture complète.
Il a décrit cet effort comme étant participatif, encourageant les constructeurs XRPL à « aller chercher les globules rouges » et à exécuter eux-mêmes les transactions manquantes, puisque le tableau de bord détecte une nouvelle activité en quelques secondes.
Les tests d’amendement surviennent alors que l’adoption est en retard
La poussée en faveur de tests de pré-activation plus rigoureux fait suite à un cycle de mise à niveau difficile. Comme CryptoPomme de terre rapporté en juillet, la mise à jour v3.2.0 de Ripple, qui a renommé le logiciel serveur principal de rippled en xrpld et réduit l'utilisation de la mémoire des nœuds de 30 à 40 %, n'était pas adoptée par plus de la moitié des nœuds XRPL des semaines après sa sortie, même si 89 % de l'ensemble des validateurs de confiance du réseau l'avait déplacé.