Le Batch V1.1 du XRP Ledger est resté au-dessus de son seuil requis de validateurs alors que Ripple affirme que des gestionnaires d'actifs et des projets commerciaux se préparent à utiliser la fonctionnalité de transaction si elle s'active plus tard ce mois-ci.
Résumé
- Le Batch V1.1 a 30 votes de validateurs, maintenant le compte à rebours d'activation du 29 septembre du XRP Ledger sur la bonne voie.
- Ripple affirme que des gestionnaires d'actifs construisent autour de Batch, bien que les partenaires spécifiques restent non divulgués pour l'instant.
- Batch peut regrouper huit transactions, permettant aux transferts d'actifs et de paiements liés de se régler atomiquement ensemble.
- Les développeurs ont remplacé le Batch original après que des chercheurs ont découvert une faille critique de validation de signature en février.
- La version 3.3.0 du XRPL a livré Batch V1.1 après des examens approfondis et des correctifs à d'autres problèmes de sécurité.
CoinDesk a rapporté le 19 septembre que le responsable de l'ingénierie de RippleX, Ayo Akinyele, a déclaré que des travaux impliquant des gestionnaires d'actifs sont en préparation autour de Batch V1.1, qui peut regrouper jusqu'à huit transactions en une seule opération Batch. Ripple n'a pas publiquement nommé les gestionnaires d'actifs ni divulgué de dates de lancement fermes.
Les données d'amendement en direct examinées le 20 septembre ont montré que 30 des 35 validateurs de confiance suivis soutenaient Batch V1.1. Le XRP Ledger exige au moins 80 % de soutien maintenu pendant 14 jours consécutifs avant qu'un amendement ne s'active, ce qui place le seuil actuel à 28 votes. Le compte à rebours a commencé le 15 septembre à 14:06:41 UTC et indique une activation possible peu après la même heure le 29 septembre si le soutien se maintient.
Le Batch V1.1 du XRP Ledger peut lier les étapes de règlement ensemble
La spécification XLS-56 définit Batch comme une transaction qui regroupe entre deux et huit transactions internes. Elle prend en charge quatre modes de traitement : Tout ou Rien, Un Seul, Jusqu'à l'Échec et Indépendant. Le paramètre Tout ou Rien exige que le groupe complet s'exécute avec succès ou empêche le batch de prendre effet.
Ripple concentre une partie de la discussion commerciale sur la livraison contre paiement, ou DvP. Dans une telle transaction, un transfert d'actif et son paiement peuvent être placés dans la même opération atomique. Un paiement échoué empêcherait le transfert d'actif lié de se terminer sous le paramètre tout ou rien.
Akinyele a déclaré à CoinDesk que « Nous partagerons plus une fois la fonctionnalité en ligne, y compris le travail avec des gestionnaires d'actifs clés. » Ripple n'a pas identifié ces entreprises, donc la déclaration reste une description par l'entreprise d'un travail qui n'a pas encore été documenté publiquement par des annonces de partenaires nommés.
La spécification XLS-56 répertorie les échanges multi-comptes sans confiance, les frais de plateforme et les structures de prêt flash parmi les utilisations potentielles. Un marché ou un portefeuille pourrait, par exemple, regrouper un paiement client avec des frais de service au lieu d'exiger des transactions séparées, tandis que différents comptes peuvent autoriser des étapes individuelles du même Batch.
Akinyele a déclaré que « certains projets sont déjà construits avec Batch à l'esprit », mais les identités des partenaires et les calendriers de production restent non divulgués. Ripple a déclaré que les détails suivraient une fois les plans finalisés.
Le soutien des validateurs maintient la fenêtre du 29 septembre ouverte
Selon la dernière lecture du 20 septembre, Batch V1.1 avait 30 votes de soutien parmi 35 validateurs suivis par XRPLDashboard, soit environ 85 %. Le soutien est donc resté au-dessus du seuil de 28 votes requis pour poursuivre la fenêtre d'activation.
La date projetée du 29 septembre est conditionnelle. Les amendements XRPL ne s'activent pas simplement parce qu'ils dépassent 80 % une fois. Les validateurs doivent maintenir la supermajorité pendant toute la période de 14 jours, et les validateurs peuvent changer leurs votes pendant que le compte à rebours est en cours. Si le soutien tombe en dessous du niveau requis, la fenêtre actuelle s'arrête et une autre période ininterrompue serait nécessaire après que le seuil soit rétabli.
Le dernier décompte prolonge une hausse rapide du soutien ce mois-ci. Batch V1.1 avait alors 24 des 35 votes de validateurs, soit 68,57 %, ce qui le laissait sous le seuil d'activation. Le soutien était passé à 27 votes le 15 septembre, avant que suffisamment de validateurs soutiennent l'amendement pour lancer le compte à rebours.
L'amendement lui-même a été livré avec la version 3.3.0 de xrpld le 6 août. Les notes de version officielles du XRP Ledger décrivent Batch V1.1 comme le remplacement de l'amendement Batch original et indiquent qu'il prend en charge jusqu'à huit transactions internes, y compris des structures d'échange atomique.
Depuis, la XRP Ledger Foundation a publié xrpld 3.4.0. La version logicielle du 16 septembre introduit des amendements distincts sur le prêt et le nettoyage et ne remplace pas Batch V1.1, qui reste dans son propre processus de vote sur le mainnet. Les opérateurs de serveurs ont été invités à mettre à niveau vers la version 3.4.0 pour assurer la continuité du service.
Batch V1.1 a suivi une faille critique dans la première version
L'amendement actuel est arrivé après que les développeurs ont arrêté la proposition Batch originale en février. La divulgation officielle de vulnérabilité de XRPL indique que la chercheuse en sécurité Pranamya Keshkamat et l'outil Apex de Cantina AI ont identifié une faille critique de validation de signature le 19 février.
Dans des conditions spécifiques, le code vulnérable pouvait cesser de vérifier les signataires de Batch après avoir rencontré un compte nouvellement créé. XRPL Labs a déclaré qu'un attaquant aurait alors pu inclure une transaction non autorisée provenant d'un autre compte sans posséder les clés privées du propriétaire de ce compte. Les transactions potentielles auraient pu inclure des paiements et certaines modifications de l'état du registre.
La faille n'a jamais été active sur le mainnet du XRP Ledger. L'amendement original était encore au stade de vote, et XRPL Labs a déclaré qu'aucun fonds n'était en danger. Les validateurs ont été invités à voter contre, tandis que la version 3.1.1 de rippled, publiée le 23 février, a rendu Batch et fixBatchInnerSigs non pris en charge afin qu'ils ne puissent pas s'activer.
Les développeurs ont ensuite modifié la logique de signature et d'autorisation pour le remplacement. Le rapport de vulnérabilité indiquait que la remédiation supprimait la condition de succès prématurée, ajoutait des garanties d'autorisation et renforçait les règles de vérification des signatures. Batch V1.1 a ensuite été intégré à xrpld 3.3.0 après développement et examen.
Le travail de sécurité s'est poursuivi avant le vote actuel des validateurs. Comme crypto.news l'a rapporté dans sa couverture de l'examen de sécurité de Batch V1.1, les développeurs ont corrigé 11 autres problèmes impliquant des signatures, des contrôles d'autorisation et d'éventuels plantages de serveur avant que l'amendement n'atteigne son stade de vote actuel.
Akinyele a déclaré à CoinDesk que l'examen comprenait des tests adversariaux internes, une analyse assistée par IA, un concours de sécurité Sherlock et des évaluations impliquant Halborn et Common Prefix. CoinDesk a attribué ces détails à RippleX ; les rapports publics des partenaires couvrant chaque partie de cet examen n'étaient pas inclus dans les documents examinés pour ce rapport.
L'écosystème de développeurs XRPL a apporté des modifications de soutien à mesure que la conception de signature évoluait. Un problème de juin dans le dépôt officiel xrpl.js documentait que l'ancienne logique de signature Batch ne correspondait pas au format révisé de Batch V1.1, car des informations supplémentaires sur le compte et la séquence avaient été liées aux signatures. L'historique des versions du codec binaire JavaScript indique que la prise en charge de la signature Batch V1.1 a été ajoutée dans la version 2.9.0 en août.
Les gestionnaires d'actifs testent davantage de règlement tokenisé sur XRPL
Les commentaires de Ripple sur Batch arrivent alors que des entreprises financières et des développeurs utilisent l'infrastructure du XRP Ledger pour des actifs tokenisés et des projets de règlement institutionnel. En juin, JPMorgan, Mastercard, Ondo Finance et Ripple ont participé à un test de rachat de bons du Trésor américain tokenisés utilisant le XRP Ledger.
La présidente de Ripple, Monica Long, a déclaré en août que les institutions financières faisaient passer certains travaux sur les actifs tokenisés de programmes pilotes vers la production. Crypto.news a rapporté sur les projets de tokenisation institutionnelle de Ripple qu'Aviva Investors avait lancé une classe d'actions de fonds tokenisées sur XRPL en juillet et que Ripple considérait RLUSD comme une jambe de trésorerie possible pour un règlement atomique livraison contre paiement.
L'activité des actifs onchain a progressé parallèlement à ce développement. Une autre analyse de crypto.news des données RWA du XRP Ledger a rapporté en juillet que le réseau avait ajouté environ 2,6 milliards de dollars de valeur d'actifs du monde réel tokenisés sur six mois, hors stablecoins, selon les chiffres de RWA.xyz. Le même rapport avertissait que la valeur des actifs représentés et les actifs activement distribués étaient des mesures matériellement différentes.
Batch V1.1 lui-même n'exige pas que les gestionnaires d'actifs utilisent XRP comme actif transféré. La fonctionnalité opère au niveau de la couche de transaction et peut regrouper des transactions XRPL prises en charge provenant de différents comptes. XRP reste pertinent pour les frais de transaction du registre, tandis que les transactions sous-jacentes peuvent impliquer d'autres actifs pris en charge et structures de tokens.
Le prochain événement procédural est la fin de la fenêtre d'amendement actuelle. XRPLDashboard projette l'activation de Batch V1.1 pour le 29 septembre à environ 14:06:41 UTC si au moins 80 % du soutien des validateurs reste ininterrompu pendant tout le compte à rebours. Le dernier décompte publié le 20 septembre restait à 30 votes en faveur sur 35 validateurs suivis.
