Ripple annonce renforcer le processus d'amendement du XRP Ledger après qu'une faille critique a été découverte dans l'amendement Batch proposé (XLS-56), un incident qui a exposé des lacunes dans l'examen même si les sauvegardes de dernier recours du réseau ont empêché tout impact sur le mainnet.
Dans un post sur X, le responsable de l'ingénierie de RippleX, J. Ayo Akinyele, a déclaré que le bogue avait été identifié la semaine dernière par Cantina AI, signalé de manière responsable et rapidement validé comme critique. Le problème n'est jamais devenu exploitable sur le mainnet car l'amendement n'avait pas encore été activé, et un correctif a été publié pour désactiver à la fois Batch et l'amendement de correctif associé pendant qu'une remédiation plus large est examinée.
Ripple Répond au Bogue Critique
Akinyele n'a pas tenté de minimiser l'importance de cette défaillance. « L'amendement Batch a progressé plus qu'il n'aurait dû », a-t-il écrit. « En tant que participants actifs au cycle de vie des amendements, nous partageons la responsabilité de garantir que les examens, les signalements et les sauvegardes d'activation répondent aux normes les plus élevées. Dans ce cas, nous devons faire mieux. »
Dans le même temps, Ripple présente cet épisode comme un échec de l'examen en phase initiale plutôt que du modèle de gouvernance du XRPL lui-même. Akinyele a déclaré que « le processus d'amendement a fonctionné comme prévu », notant que le verrous d'activation ont empêché tout dommage au mainnet et que la voie de divulgation du programme de bug bounty a fonctionné comme prévu. Mais il a ajouté un avertissement plus sévère : « Ces sauvegardes sont importantes, mais elles devraient servir de dernière ligne de défense, et non de principale. »
Cette distinction traverse le reste de la réponse de Ripple. Plutôt que de suggérer un contrôle centralisé plus strict, Akinyele a soutenu que la sécurité des amendements sur le XRPL doit rester distribuée entre les contributeurs principaux, les validateurs, la XRPL Foundation et les chercheurs externes. « Aucune entité unique ne contrôle l'activation. Aucune entité unique ne porte le risque de manière isolée », a-t-il écrit, décrivant cette structure comme une conséquence de la décentralisation et une force, à condition qu'elle soit assortie de défenses en couches et d'une meilleure coordination.
Les correctifs proposés par Ripple sont larges. Akinyele a déclaré que les futures versions introduisant des fonctionnalités présentant un « risque théorique de perturbation » passeront par plusieurs audits indépendants auprès de sociétés de sécurité réputées, en coordination avec la XRPL Foundation. L'idée est simple : différentes équipes détectent différentes classes de problèmes, et la redondance réduit les angles morts lorsque le code touche à des comportements critiques pour le consensus.
La société prévoit également d'étendre le programme de bug bounty et de formaliser des campagnes de tests adversariaux avant l'activation. Akinyele a pointé des initiatives comme le Lending attackathon et un hackathon sponsorisé par UBRI comme modèles pour cette approche, affirmant qu'inciter les attaquants white-hat avant le lancement est bien moins coûteux que de réagir après coup. Il a ajouté que les leçons de l'incident Batch ont déjà affecté d'autres éléments de la feuille de route, disant que Ripple a « délibérément retardé le lending » pour permettre plus d'examen, de tests et de scrutiny avant de se diriger vers l'activation.
Une partie de cette prochaine phase s'appuiera plus lourdement sur l'IA. Akinyele a déclaré que Ripple intègre la revue de code assistée par IA, la découverte automatisée d'invariants, le fuzzing agentique et des scénarios d'attaque simulés dans son cycle de développement logiciel. « L'IA ne remplace pas les ingénieurs C++ experts, mais elle les augmente », a-t-il écrit, surtout lorsque « des interactions logiques subtiles à des points critiques peuvent créer un risque démesuré. »
À plus long terme, Ripple déclare vouloir que la vérification formelle devienne la norme pour les composants à haut risque du ledger. Cela inclut la modélisation du comportement des amendements avant activation, la preuve des propriétés de sécurité pour les composants critiques et l'intégration de méthodes formelles de la spécification XLS jusqu'à l'implémentation et aux tests. L'objectif plus large, a déclaré Akinyele, est une assurance de bout en bout que le code de l'amendement est non seulement fonctionnellement correct mais aussi aligné sur des propriétés de sécurité et de sûreté définies.
Au moment de la rédaction, le XRP s'échangeait à 1,3698 $.
