Les retombées de l'alerte BatchGate sur le XRP Ledger se transforment en un débat plus large sur la responsabilité réelle en matière de sécurité du protocole et sur le niveau de contrôle que devraient subir les amendements majeurs avant d'approcher le mainnet. Dans une déclaration publiée lundi, l'opérateur historique de validateurs Daniel Keller a déclaré que la quasi-erreur autour du XLS-56 avait exposé « un échec systémique dans les processus d'examen » et l'a incité à retirer son soutien à tous les amendements actuellement à l'étude.
Le post de Keller était présenté comme une clarification du rôle des validateurs dUNL, après ce qu'il a décrit comme une confusion généralisée suite à l'incident Batch. Son point central était que les validateurs sont des participants à la gouvernance, et non des auditeurs non rémunérés. « Le rôle des validateurs dUNL est spécifique et limité : Nous coordonnons l'activation (ou le rejet) des amendements en émettant des votes 'Pour' ou 'Contre' une fois qu'un amendement est proposé », a-t-il écrit. « Nous sommes supposés juger les amendements en attente. C'est notre fonction de gouvernance principale. »
Cette distinction est importante car le XLS-56, également connu sous le nom de Batch, n'a été arrêté qu'après qu'une faille logique dans la validation des signatures ait été découverte peu avant l'activation sur le mainnet. Le bug aurait pu permettre l'exécution de transactions non autorisées et potentiellement mis des milliards de XRP en danger avant que l'amendement ne soit suspendu et corrigé dans rippled 3.1.1.
Préoccupations concernant la gouvernance du XRP Ledger, avec Ripple en point de mire
Pour Keller, cet épisode n'était pas une erreur isolée mais le dernier exemple d'un problème structurel plus profond. « Le dUNL n'est pas un organisme gratuit d'examen de code ou d'audit de protocole. S'attendre à ce que les validateurs passent des dizaines d'heures non rémunérées à examiner un code d'amendement complexe n'a jamais fait partie de la conception et ne le sera jamais », a-t-il écrit. « Au lieu de cela, les parties proposant des amendements devraient être tenues de fournir une documentation complète, des suites de tests, des analyses de sécurité et des preuves formelles sur demande. Si vous voulez mon vote, prouvez que le changement est sûr et bénéfique. »
Il a soutenu que la charge retombe désormais sur Ripple pour financer ce processus plus activement. « Je ne voterai en faveur d'aucun amendement futur tant que Ripple n'aura pas pris un engagement crédible et concret d'augmenter substantiellement les investissements dans l'ingénierie du protocole central du XRPL, l'examen de sécurité et la durabilité à long terme », a déclaré Keller. « Si XRP est véritablement l'« étoile du Nord » de Ripple, comme cela a été répété, alors la sécurité fondamentale et la décentralisation du réseau doivent recevoir l'attention et les ressources qu'elles méritent. »
La réponse immédiate de Keller a été sans équivoque : retirer tous les votes « Pour » actuels, à l'exception des correctifs en attente, et refuser de passer à rippled 3.1.1 à moins que le fait de rester sur la version antérieure ne risque d'entraîner une exclusion du réseau. Il a également déclaré que le fait qu'un chercheur indépendant et un outil d'IA aient finalement été nécessaires pour éviter un préjudice soulignait à quel point le filet de sécurité actuel était devenu mince.
D'autres voix importantes du XRPL ont convenu que le processus devait changer, bien que tous n'aient pas soutenu un ralentissement. Vet, un validateur XRPL bien connu, a qualifié l'incident Batch d'« opportunité massive » pour la communauté et la XRPL Foundation de repenser l'évolution du protocole. Il a plaidé pour un calendrier d'amendement plus lent, plus d'examens rémunérés, des audits multiples pour les changements majeurs, des « attackathons » sur le testnet, et un programme de primes aux bugs suffisamment important pour attirer des chercheurs d'élite.
Keller, cependant, a contesté l'idée que la solution soit simplement de ralentir. « À court terme, nous avons besoin d'une sorte d'accord avec Cantina. Ils ont fait leurs preuves et c'est le meilleur que nous ayons pour le moment », a-t-il écrit. « À moyen terme, les primes aux bugs doivent être rehaussées et payer des sommes sérieuses. Premièrement, les gens doivent être incités à examiner le code ; deuxièmement, il doit être rentable de faire une divulgation responsable. »
Il est allé plus loin dans un suivi qui a capturé l'humeur du débat : « Je ne veux pas ralentir notre vitesse de développement ; il nous a fallu des années pour atteindre le niveau actuel, et nous sommes encore lents. Plus de ressources doivent être allouées, et le processus aurait dû commencer hier. »
Cela place le XRP Ledger dans une situation tendue mais familière : un réseau qui tente d'ajouter des fonctionnalités sans compromettre la crédibilité de sa couche de base. BatchGate ne s'est pas transformé en exploitation active. Mais cela a forcé une question plus pressante à être ouverte : est-ce que le pipeline d'amendements du XRPL fonctionne encore avec une profondeur d'examen suffisante pour l'ampleur des changements maintenant proposés.
Au moment de la rédaction, le XRP s'échangeait à 1,3566 $.
