Contenu éditorial de confiance, examiné par des experts de l'industrie et des éditeurs expérimentés. Divulgation publicitaire
Les répercussions de la crise BatchGate du 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 degré de contrôle que doivent subir les modifications majeures avant d'atteindre le réseau principal. Dans une déclaration publiée lundi, Daniel Keller, un opérateur de validateurs de longue date, a déclaré que le quasi-accident autour de XLS-56 avait révélé « une défaillance systémique dans les processus de revue » et l’a poussé à retirer son soutien à toutes les modifications actuellement à l’étude.
Le message de Keller était présenté comme une clarification de ce que les validateurs dUNL sont censés faire, 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 précis et limité : nous coordonnons l’activation (ou le rejet) des modifications en votant ‘Pour’ ou ‘Contre’ lorsqu’une modification est proposée », a-t-il écrit. « Nous devons juger les modifications en attente. C’est notre fonction principale de gouvernance. »
Lecture connexe : XRP reflète le Russell 2000, ce que cela signifie et pourquoi c’est important Cette distinction est importante car XLS-56, aussi appelé Batch, a été arrêté seulement après la découverte d’un défaut logique dans la validation des signatures, peu avant l’activation du réseau principal. La faille aurait pu permettre l’exécution non autorisée de transactions et potentiellement mettre en danger des milliards de XRP avant que la modification ne soit suspendue et corrigée dans rippled 3.1.1.
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 de revue de code ou d’audit de protocole gratuit. S’attendre à ce que les validateurs passent des dizaines d’heures non rémunérées à examiner un code de modification complexe n’a jamais fait partie du design et ne le sera jamais », a-t-il écrit. « Au lieu de cela, les parties proposant des modifications 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 responsabilité incombe désormais à Ripple de financer ce processus de manière plus agressive. « Je ne voterai pour aucune modification future tant que Ripple ne s’engagera pas de manière crédible et concrète à augmenter substantiellement l’investissement dans l’ingénierie du protocole XRPL, la revue de sécurité et la durabilité à long terme », a déclaré Keller. « Si XRP est vraiment la ‘North Star’ de Ripple, comme cela a été répété, alors la sécurité fondamentale du réseau et sa décentralisation doivent recevoir l’attention et les ressources qu’ils méritent. »
La réponse immédiate de Keller a été claire : retirer tous les votes « Pour » en cours, sauf pour les correctifs en attente, et refuser de mettre à jour vers rippled 3.1.1 à moins que rester sur la version précédente ne risque d’être exclu du réseau. Il a également souligné que le fait qu’un chercheur indépendant et un outil d’IA aient finalement été nécessaires pour éviter un dommage montre à quel point le filet de sécurité actuel est mince.
D’autres voix importantes du XRPL ont convenu que le processus doit changer, bien que tous ne soutiennent pas un ralentissement. Vet, un validateurs XRPL bien connu, a qualifié l’incident Batch de « opportunité massive » pour la communauté et la Fondation XRPL de repenser l’évolution du protocole. Il a plaidé pour un calendrier de modifications plus lent, plus de revues payantes, plusieurs audits pour les changements importants, des « attackathons » sur le testnet, et un programme de récompenses pour bugs suffisamment attractif pour les chercheurs d’élite.
Lecture connexe : Le financement des constructeurs XRP évolue en 2026 alors que Ripple soutient un nouveau modèle Cependant, Keller a rejeté l’idée que la solution consiste simplement à ralentir. « À court terme, nous devons parvenir à un accord avec Cantina. Ils ont fait leurs preuves et c’est la meilleure option que nous ayons pour le moment », a-t-il écrit. « À moyen terme, les récompenses pour bugs doivent être augmentées et payer des sommes sérieuses. Premièrement, il faut inciter les gens à examiner le code ; deuxièmement, il doit être rentable de faire une divulgation responsable. »
Il a approfondi dans une suite qui reflète l’état d’esprit 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. Davantage de ressources doivent être allouées, et le processus doit commencer dès hier. »
Cela laisse le XRP Ledger dans une position 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 n’est pas devenu une exploitation en direct. Mais il a posé une question plus aiguë : le pipeline de modifications du XRPL fonctionne-t-il toujours avec suffisamment de profondeur de revue pour l’ampleur des changements proposés ?
Au moment de la rédaction, le XRP se négociait à 1,3566 $.
XRP tombe en dessous de la EMA sur 200 semaines à nouveau, graphique sur 1 semaine | Source : XRPUSDT sur TradingView.comImage principale créée avec DALL.E, graphique de TradingView.com
Processus éditorial pour bitcoinist est centré sur la livraison d’un contenu rigoureusement recherché, précis et impartial. Nous respectons des normes strictes de sourcing, et chaque page est soumise à une revue attentive par notre équipe d’experts en technologie et d’éditeurs expérimentés. Ce processus garantit l’intégrité, la pertinence et la valeur de notre contenu pour nos lecteurs.