Les validateurs du XRP Ledger ont placé l'amendement BatchV1_1, corrigé, sur une voie d'activation conditionnelle à 14:06:41 UTC le 29 septembre. Trente des 35 validateurs de confiance ont soutenu l'amendement, au-dessus de son seuil de 28 voix, la majorité ayant fait son apparition on-ledger le 15 septembre. Selon les règles du XRPL, le soutien doit rester supérieur à 80 % pendant deux semaines, la date demeure donc conditionnelle. L'amendement remplace une version antérieure retirée après que des chercheurs ont découvert une faille critique d'autorisation en février, avant même qu'elle n'atteigne le mainnet.
Pourquoi c'est important
Cet épisode a validé le pare-feu d'amendements du XRPL. L'amendement Batch original était encore en phase de vote lorsque des chercheurs ont révélé un bug de boucle de signature qui renvoyait un succès prématurément au lieu de vérifier les signataires restants. S'il était entré en vigueur, une entrée falsifiée aurait pu exécuter la transaction d'une victime sans ses clés, même si la divulgation de XRPL Labs confirme qu'aucun fonds n'a jamais été menacé.
BatchV1_1 remplace ce chemin par un schéma d'autorisation réécrit selon la spécification XLS-56. Chaque signature BatchSigner lie désormais le compte externe, son numéro de séquence ou ticket, le mode de batch, les hachés ordonnés de toutes les transactions internes et tout signataire imbriqué, fermant à la fois le bug révélé et les vecteurs de rejeu adjacents.
Impact sur le marché
Le correctif protocolaire déplace le risque vers l'implémentation. Un Batch externe peut renvoyer tesSUCCESS même lorsque des transactions internes échouent, les clients doivent donc inspecter chaque code de résultat interne. La prise en charge de BatchV1_1 est livrée avec xrpld 3.3.0 le 6 août, et les serveurs qui ne font pas la mise à niveau deviennent amendment-blocked dès son activation. xrpl.js 5.0.0 construisait les signatures sur l'ancien format de charge utile et se voit rejeté avec temBAD_SIGNATURE, une prise en charge compatible arrivant en 5.1.0.
L'activation prouve la disponibilité du protocole, pas l'adoption ni la demande de XRP. Les signaux à surveiller ensuite sont de savoir si les nœuds obsolètes se retrouvent bloqués, si les échecs de signature se concentrent autour des anciennes versions de clients, et si les wallets et explorateurs présentent les batches multi-comptes de manière intelligible.
Questions fréquemment posées
-
Quand l'amendement BatchV1_1 du XRPL s'activera-t-il ?
De manière conditionnelle, à 14:06:41 UTC le 29 septembre, à condition que le soutien des validateurs reste supérieur à 80 % pendant la période requise de deux semaines. Trente des 35 validateurs de confiance soutiennent actuellement l'amendement, au-dessus de son seuil de 28 voix.
-
Quelle était la faille de l'amendement Batch original du XRPL ?
Un bug de boucle de signature renvoyait un succès prématurément lorsqu'il rencontrait un signataire pour un compte nouvellement créé, si bien qu'une entrée falsifiée prétendant autoriser un compte victime aurait pu s'exécuter sans les clés de la victime. Aucun fonds n'était menacé.
-
Pourquoi un Batch XRPL peut-il afficher un succès alors que des transactions internes échouent ?
Un Batch externe peut renvoyer tesSUCCESS même lorsqu'une ou plusieurs transactions internes échouent, et en dehors du mode ALLORNOTHING, l'exécution partielle est intentionnelle. Les clients doivent inspecter les métadonnées et le code de résultat de chaque transaction interne.
-
Quelles versions logicielles prennent en charge BatchV1_1 ?
xrpld 3.3.0 a livré la prise en charge de BatchV1_1 le 6 août, et xrpl.js 5.1.0 a ajouté le format de signature révisé. La version 5.0.0 produit des signatures rejetées par les nœuds BatchV1_1 avec temBAD_SIGNATURE, et les serveurs obsolètes risquent de devenir amendment-blocked.
-
L'activation de BatchV1_1 signifie-t-elle une demande accrue pour XRP ?
Pas en soi. Le vote et les publications logicielles établissent uniquement la disponibilité du protocole. Les signaux utiles viendront après l'activation, comme les nœuds bloqués, les échecs de signature sur les anciens clients, et la façon dont les wallets et explorateurs présentent les batches.
CoinTelegraph
WatcherGuru
WuBlockchain
TheBlock
Crypto Rank News
CoinDesk