Les validateurs du XRP Ledger se rapprochent de l'approbation de BatchV1_1, mais les données de vote en direct du 8 septembre ont montré que l'amendement restait en dessous du seuil requis pour commencer sa période d'activation de deux semaines.
Résumé
- BatchV1_1 dispose actuellement de 24 votes sur 35 validateurs, soit un soutien de 68,57% sur le mainnet XRPL.
- L'activation nécessite plus de 80% de soutien en continu pendant quatorze jours, et aucun compte à rebours n'a commencé.
- Les transactions par lots peuvent contenir jusqu'à huit opérations et prendre en charge quatre modes d'exécution après activation.
- La version 3.3.0 de XRPL a introduit BatchV1_1 après que les développeurs ont désactivé le code Batch original en raison d'une vulnérabilité.
- Une faille antérieure aurait pu permettre des paiements non autorisés, mais l'amendement vulnérable n'a jamais été activé sur le mainnet XRPL.
BatchV1_1 avait le soutien de 24 des 35 validateurs sur la liste de nœuds uniques par défaut, soit 68,57%, selon XRPScan. Au moins 29 votes affirmatifs seraient nécessaires pour dépasser 80% avec le nombre actuel de validateurs.
L'amendement permettrait aux comptes de regrouper jusqu'à huit transactions en une seule opération coordonnée. Cependant, les rapports suggérant qu'il s'activera en septembre restent spéculatifs car la majorité requise n'a pas été atteinte.
Une activation en septembre n'est possible que si le soutien dépasse d'abord 80% et reste à ce niveau en continu pendant quatorze jours.
Le vote Batch du XRP Ledger n'a pas commencé son compte à rebours
Les amendements XRPL ne s'activent qu'après avoir maintenu le soutien de plus de 80% des validateurs de confiance pendant deux semaines consécutives. Si le soutien tombe en dessous de ce niveau pendant la période, le minuteur se réinitialise.
BatchV1_1 a donc besoin d'au moins cinq votes affirmatifs supplémentaires dans la configuration actuelle de 35 validateurs. Des changements dans l'ensemble des participants pourraient modifier le nombre exact requis.
L'amendement n'a pas de date d'activation confirmée. Même s'il franchissait immédiatement le seuil, il ne pourrait pas s'activer avant la fin de la période continue de deux semaines.
Les votes des validateurs peuvent également changer. Les opérateurs peuvent retirer leur soutien si les tests révèlent des problèmes de compatibilité, de sécurité ou opérationnels.
BatchV1_1 combinerait huit transactions
La documentation officielle du XRPL indique que les transactions par lots peuvent contenir jusqu'à huit transactions internes. Les opérations sont emballées dans une transaction externe qui gère la séquence, les frais et l'autorisation.
Quatre modes d'exécution seraient disponibles. « Tout ou rien » exige que chaque transaction interne réussisse. « Un seul » applique la première opération réussie, tandis que « jusqu'à échec » traite les transactions jusqu'à ce que l'une échoue. « Indépendant » tente chaque transaction incluse indépendamment des autres résultats.
Les utilisations potentielles incluent les échanges de jetons atomiques, la frappe de NFT suivie d'une offre, les frais de plateforme groupés et les actions coordonnées impliquant plusieurs comptes. Les lots multi-comptes exigent que chaque compte participant autorise la collection complète.
La fonctionnalité pourrait réduire l'infrastructure externe nécessaire aux applications pour coordonner les actions dépendantes. Chaque transaction interne validée conserverait des métadonnées séparées et une référence à son lot parent.
Comme crypto.news l'a rapporté lors de la sortie de la version 3.3.0, l'expédition du code n'a pas activé la fonctionnalité. L'approbation des validateurs restait nécessaire.
L'amendement corrigé remplace le code Batch vulnérable
La version 3.3.0 de XRPL a introduit BatchV1_1 le 6 août en remplacement de l'amendement Batch original. Les développeurs ont désactivé cette version antérieure en février après que des chercheurs ont découvert une faille d'autorisation critique.
Pranamya Keshkamat et l'outil de sécurité Apex de Cantina AI ont identifié une erreur dans la logique utilisée pour vérifier les signataires de batch. La faille aurait pu permettre à un attaquant de contourner les vérifications pour certains participants et de soumettre des transactions non autorisées depuis le compte d'une victime.
XRPL Labs a déclaré que l'amendement vulnérable n'avait pas été activé sur le réseau principal et qu'aucun fonds d'utilisateur n'avait été mis en danger. Les validateurs ont été invités à voter contre, tandis que la version 3.1.1 de rippled a marqué le Batch original et son correctif associé comme non pris en charge.
La version corrigée élimine l'erreur de sortie anticipée, ajoute des garanties d'autorisation et restreint la manière dont chaque signataire est vérifié. Un audit indépendant a ensuite examiné le remplacement avant sa publication.
Dans la couverture connexe de l'examen de sécurité, crypto.news a rapporté que la faille originale avait été détectée avant l'activation et que BatchV1_1 avait été réécrit pour la version 3.3.0.
L'activation dépend entièrement des validateurs
Les opérateurs de nœuds doivent exécuter un logiciel prenant en charge BatchV1_1 avant de voter pour celui-ci. XRPL a également averti les opérateurs de Clio de mettre à niveau vers la version 2.8.0 afin que leur infrastructure API puisse traiter les nouveaux formats de transactions et de registre si les amendements sont activés.
Le prochain jalon confirmé est le seuil de 80 % des validateurs. Ce n'est qu'alors que le registre enregistrera le début de la période de majorité de deux semaines.
Une activation fin septembre reste mathématiquement possible, mais elle n'est pas planifiée. Le calendrier exact dépend de votes supplémentaires des validateurs et d'un soutien ininterrompu par la suite.
Aucun mouvement de prix vérifié de XRP ne peut être attribué spécifiquement au vote BatchV1_1. L'amendement modifie la fonctionnalité des transactions plutôt que l'offre de XRP ou ses règles d'émission.
