Ripple affirme que les gestionnaires d'actifs se préparent à utiliser XRP Ledger Batch. Ce type de transaction peut faire réussir ou échouer plusieurs actions du registre ensemble, mais une version logicielle d'urgence a détourné l'attention d'une activation attendue le 29 septembre vers un amendement de sécurité du 9 octobre. La capacité est spécifique. Les preuves que l'adoption institutionnelle reste prospective le sont aussi.
Résumé
- Selon sa spécification publiée, un Batch peut contenir entre 2 et 8 transactions internes.
- Quatre modes déterminent si toutes, une seule, un préfixe ou n'importe quelle transaction interne éligible s'exécute.
- La version 3.4.1 du XRP Ledger a introduit un correctif Batch sensible à la sécurité le 25 septembre.
- La fondation s'attend à ce que fixBatchV1_2 soit activé le 9 octobre si le soutien des validateurs persiste.
- Un Batch externe réussi peut masquer des transactions internes échouées, sauf si l'application vérifie leurs résultats.
La promesse centrale est simple : faire régler des étapes liées en une seule clôture de registre. Un gestionnaire d'actifs qui doit livrer un jeton et recevoir un paiement peut préférer un échange tout ou rien plutôt que d'envoyer l'actif d'abord en espérant que l'argent arrive. RippleX a décrit des gestionnaires d'actifs et des projets commerciaux se préparant à cette fonctionnalité, comme indiqué dans le rapport précédent sur l'intérêt institutionnel. Il n'a pas nommé publiquement de gestionnaire d'actifs en production avec une transaction Batch en direct sur le mainnet dans ce compte.
Le statut a changé avant l'attente initiale de fin septembre. L'avis de publication de la XRPL Foundation qualifie la version 3.4.1 de mise à jour d'urgence pour des problèmes sensibles à la sécurité. Elle ajoute fixBatchV1_2, demande aux serveurs de mettre à niveau rapidement et indique que l'amendement devrait être activé le 9 octobre si un soutien à la supermajorité persiste. C'est une attente conditionnelle, pas une promesse de lancement fixe.
Batch coordonne les actions au sein d'une seule clôture de registre
La spécification XLS-0056 décrit une transaction externe contenant entre deux et huit transactions internes. Les comptes impliqués approuvent l'ensemble. Un mode sélectionné contrôle ce qui se passe lorsqu'une action interne échoue. Le registre traite l'ensemble en une seule clôture, évitant l'écart entre des soumissions non liées qui pourrait laisser un participant avec seulement la moitié d'un accord.
Supposons qu'un fonds transfère une créance obligataire tokenisée et reçoive un jeton dollar. Deux transactions ordinaires pourraient être soumises séparément. Si la première réussit et que la seconde échoue, les contreparties ont un litige opérationnel et une perte potentielle. Avec le mode tout ou rien, les deux actions internes doivent réussir pour que l'échange prévu soit complet. C'est le cas d'usage institutionnel convaincant, à condition que le jeton, l'instrument de paiement, les contreparties et les autorisations soient déjà en place.
Batch ne crée pas une obligation, ne vérifie pas sa propriété hors chaîne et ne force pas une banque à rembourser le jeton de paiement. Il coordonne les actions du registre. La finalité du règlement juridique, les restrictions de transfert, la garde et le remboursement dépendent encore des instruments et institutions concernés. La distinction est importante car un transfert techniquement atomique n'est qu'une partie de la livraison contre paiement.
Le tutoriel sur un compte unique présente le cas le plus simple. Plusieurs actions provenant d'un seul compte peuvent être regroupées dans un mode spécifié. Les transactions multi-comptes ajoutent les signatures des comptes dont les soldes ou les autorisations sont affectés. Le tutoriel multi-comptes décrit ce processus de signature coordonnée.
Quatre modes produisent quatre marchés différents
ALLORNOTHING est l'échange bilatéral propre. Chaque action interne requise doit réussir, sinon le groupe prévu ne se règle pas. ONLYONE essaie des alternatives et s'arrête après le premier succès, comme des ordres à différentes tolérances. UNTILFAILURE traite une séquence jusqu'à un échec. INDEPENDENT permet aux actions du même wrapper de réussir ou d'échouer indépendamment. Qualifier les quatre modes d'atomiques au sens courant masquerait la possibilité d'une exécution partielle.
Les modes modifient la conception des produits. Un fonds déplaçant deux actifs contre un seul paiement doit décider si un seul transfert échoué doit annuler l'ensemble du package. Un teneur de marché soumettant des offres de repli pourrait préférer ONLYONE. Un émetteur distribuant plusieurs paiements pourrait tolérer des résultats indépendants, mais son équipe opérationnelle doit alors réconcilier quels destinataires ont été payés. Le mode est une décision de risque, pas un choix de formatage.
La limite de huit actions est une autre contrainte réelle. Un gestionnaire tentant de régler 1 000 transferts d'investisseurs ne peut pas regrouper les 1 000 dans un seul Batch selon la proposition actuelle. Au minimum théorique de 125 packages de huit actions, ces groupes ne seraient pas eux-mêmes atomiques entre eux. Les frais, les signatures, la gestion de la séquence des comptes et la capacité de service deviennent des contraintes pratiques avant même que le processus métier hors chaîne ne soit pris en compte.
Le rapport technique précédent mentionnait le long historique de développement et d'audit de la mise à niveau. Ce contexte est pertinent pour le calendrier, mais ne doit pas être confondu avec l'affirmation que chaque application construite au-dessus a été auditée.
Le code de succès externe est un piège comptable
La spécification indique qu'une transaction Batch externe peut rapporter tesSUCCESS même lorsque les transactions internes échouent. Son résultat externe couvre le traitement de la séquence et des frais. Pour savoir si un paiement ou une livraison a eu lieu, le logiciel doit inspecter les métadonnées des transactions internes et les codes de résultat individuels. C'est un risque d'intégration particulièrement concret pour toute institution dont le back-office traduit un statut de succès générique en un mouvement d'actif comptabilisé.
Imaginez un flux de transactions qui ne lit que le résultat externe et crédite un client avec un titre tokenisé. Si le transfert interne concerné n'a pas réussi, le flux et le registre divergent. Le système doit associer chaque action interne à son parent et à son propre résultat. La spécification recommande d'utiliser la relation ParentBatchID dans les explorateurs et les indexeurs. Un desk devrait tester les échecs dans chaque mode, pas seulement le scénario favorable.
L'erreur peut survivre aux contrôles ordinaires parce que la transaction externe est réelle et possède un identifiant de transaction. Un système de réconciliation conçu pour une transaction équivalant à une action métier peut passer sa première vérification. Le contrôle approprié relie l'instruction métier au mode, au package signé complet, à chaque résultat interne et aux soldes d'actifs finaux. C'est un travail qu'un gestionnaire d'actifs doit effectuer même si la couche réseau est correcte.
L'arithmétique est modeste mais révélatrice. Un Batch maximal contenant huit transactions internes constitue une seule soumission externe, mais peut nécessiter au moins huit vérifications de résultat, plus les frais externes et la vérification de séquencement. Pour 125 packages complets représentant 1 000 actions internes, le back-office a besoin de 1 000 résultats au niveau des actions, et non de 125 voyants verts.
Le correctif de sécurité change l'histoire de l'activation
L'avis du 25 septembre de la fondation indique que fixBatchV1_2 rejette les transactions internes avec le mauvais wrapper et inclut des correctifs supplémentaires de sécurité et de stabilité. Il retient temporairement le code source en raison de la nature sensible pour la sécurité de la modification, promettant une publication et une rétrospective ultérieurement. Cela limite la capacité des tiers à inspecter le correctif exact avant sa divulgation. C'est une raison pour une attribution précise, non une raison de spéculer sur une exploitabilité non divulguée.
L'avis indique que les serveurs inférieurs à la version 3.4.1 deviendraient bloqués par l'amendement si le correctif s'active alors qu'ils n'ont pas été mis à niveau. Les votes des validateurs et les mises à niveau des nœuds importent donc pour l'accès en production. Un quorum signalant son soutien n'est pas la même chose que chaque portefeuille, dépositaire, fournisseur d'API et outil comptable étant prêt pour Batch. La couverture antérieure de la mise à niveau des nœuds XRPL illustre l'effet opérationnel d'un blocage d'amendement dans une version précédente.
Il y a aussi un historique qu'un journaliste ne peut omettre. Une divulgation de vulnérabilité de février décrit une faille dans une conception antérieure de Batch qui aurait pu contourner les vérifications d'autorisation pour d'autres signataires lorsqu'un signataire non financé apparaissait en premier. L'amendement n'était pas encore entré en vigueur. Le compte rendu de l'audit de sécurité a examiné comment un examen indépendant a détecté des problèmes avant l'utilisation en production. Le correctif de septembre concerne un problème de wrapper décrit séparément ; aucun des deux incidents ne prouve que la conception actuelle est dangereuse, mais les deux expliquent pourquoi le calendrier de déploiement mérite un examen minutieux.
Ce que les institutions pourraient gagner, et ce dont elles ont encore besoin
La livraison atomique contre paiement est le cas le plus solide. Un gestionnaire pourrait coordonner un transfert de jetons avec un paiement sur le même registre, limitant l'exposition temporaire créée par des transferts séquentiels. Un émetteur pourrait regrouper les étapes de création de compte, d'autorisation et d'émission lorsque le protocole permet ces types de transactions. Les sociétés de trading pourraient utiliser des voies d'exécution alternatives. Ce sont des capacités, non des preuves d'actifs et de transactions en direct.
Les actifs tokenisés nécessitent des émetteurs, des agents de transfert ou d'autres entités responsables, des règles sur les détenteurs éligibles, des procédures de conservation et un instrument de paiement avec des conditions de remboursement acceptables. Un Batch peut faire exécuter les segments on-chain selon une règle choisie. Il ne peut pas rendre un titre juridiquement valide dans une autre juridiction, obtenir le consentement du client pour une action non liée ou garantir un segment de trésorerie externe auprès d'une banque commerciale.
Le dossier de Ripple mérite sa version la plus forte. Un mécanisme au niveau du registre peut réduire le travail de coordination pour les développeurs et éliminer une véritable classe de défaillances de règlement partiel. L'aperçu des fonctionnalités du XRPL décrivait Batch aux côtés d'autres fonctionnalités institutionnelles, bien que chaque amendement suive son propre processus. Si des gestionnaires nommés démontrent ultérieurement un règlement réel, répété, d'actifs tokenisés authentiques avec des résultats internes correctement réconciliés, l'affirmation d'adoption aura des preuves solides à l'appui.
La limite est tout aussi claire. Une entreprise préparant un pilote n'est pas un gestionnaire d'actifs utilisant Batch en production. Aucune affirmation publique de préparation ne nous indique les volumes, les frais économisés, les litiges de règlement évités ou quelle institution assume les obligations hors chaîne. Une annonce peut être vraie et rester trop prématurée pour étayer ces conclusions plus larges.
Le vote du registre n’est que le premier test de préparation
L’activation attendue de fixBatchV1_2 le 9 octobre dépend d’un soutien soutenu des validateurs. Les opérateurs doivent exécuter un logiciel compatible. Les portefeuilles doivent montrer aux utilisateurs toutes les actions internes et le mode sélectionné avant de recueillir une signature, comme le recommande la spécification. Les indexeurs doivent exposer les résultats parents et enfants. Les dépositaires ont besoin de contrôles de politique pour les signatures multi-comptes. Les gestionnaires d’actifs ont besoin de rapprochement et de documentation juridique.
Il n’existe pas de pourcentage unique montrant toute cette préparation. Le vote des validateurs mesure l’accord sur un changement de protocole. Le test de production consiste à savoir si de vrais utilisateurs peuvent préparer, signer, soumettre, inspecter et récupérer d’un Batch échoué sans enregistrements désaccordés. La question commerciale sans réponse est de savoir quelle institution nommée présentera un cas d’usage reproductible une fois l’amendement et l’outillage en production.
Ce qu’il faut surveiller
- Statut de l’amendement : Si fixBatchV1_2 conserve le soutien et s’active à la date attendue du 9 octobre.
- Mises à niveau des serveurs : La part des opérateurs exécutant la version 3.4.1 avant que l’amendement de sécurité ne devienne obligatoire.
- Divulgation : La publication du code source du correctif retenu et la rétrospective promise.
- Résultats internes : Le support des portefeuilles et des indexeurs pour l’affichage du mode, les liens parents et les résultats au niveau des actions.
- Preuves de production : Un gestionnaire d’actifs nommé rapportant un volume de Batch en direct et ses contrôles de règlement.
FAQ
XRPL Batch est-il maintenant en production sur le mainnet ?
Les amendements pertinents et leur statut en direct doivent être vérifiés au moment de la publication. La version du 25 septembre décrivait un correctif de sécurité censé s’activer le 9 octobre si le soutien des validateurs persistait.
Combien de transactions un Batch peut-il contenir ?
La spécification XLS-0056 publiée fixe un minimum de deux et un maximum de huit transactions internes dans la conception actuelle.
Batch garantit-il que chaque action interne réussit ?
Seul le mode tout-ou-rien est conçu autour de la réussite de l’ensemble du groupe. D’autres modes permettent délibérément un schéma différent d’exécution partielle.
Un gestionnaire d’actifs peut-il signer pour chaque contrepartie ?
Non. Dans un Batch multi-comptes, les comptes concernés doivent approuver la collection signée conformément aux règles de signature du protocole.
tesSUCCESS signifie-t-il que la transaction a été réglée ?
Pas à lui seul. Le résultat externe peut réussir alors qu’une action interne échoue, donc les systèmes doivent inspecter chaque résultat interne et les soldes.
Batch rendra-t-il les titres tokenisés juridiquement réglés ?
Il peut coordonner les étapes on-chain. Les droits juridiques, le remboursement et toute jambe de paiement externe dépendent encore des conditions de l’actif et de l’infrastructure applicable.
Qu’est-ce qui a changé dans la version 3.4.1 ?
La fondation a décrit une version de sécurité d’urgence ajoutant fixBatchV1_2, incluant le rejet des transactions internes avec le mauvais wrapper.
Les gestionnaires d’actifs ont-ils démontré une utilisation en direct ?
Ripple a rapporté des préparatifs, mais le compte public cité n’a pas nommé de gestionnaire de production avec un règlement Batch en direct reproductible. Il s’agit d’une analyse éducative, pas d’un conseil en investissement.
