XRP Ledger 3.3.0 apporte des améliorations en matière de confidentialité et de traitement par lots

Les développeurs de XRP Ledger ont publié la version 3.3.0 de xrpld le 6 août, rapprochant plusieurs modifications du protocole d'une activation possible sur le réseau principal.
Résumé

• XRPL 3.3.0 introduit un code de protocole, mais l'approbation des validateurs reste nécessaire avant toute activation sur le réseau principal.
• ConfidentialTransfer protégerait les soldes MPT et les montants de transfert tout en préservant l'accès de conformité pour les parties autorisées.
• BatchV1_1 rétablit la fonctionnalité de transaction atomique après qu'une version antérieure ait été interrompue en raison d'un défaut de sécurité.
• Sponsor permettrait à des tiers de couvrir les frais et les réserves tout en permettant aux utilisateurs de conserver le contrôle total de leur compte.
• DynamicMPT permettrait aux émetteurs de modifier ultérieurement certaines propriétés de jetons, soutenant ainsi les besoins commerciaux et de conformité évolutifs.

La publication officielle sur GitHub confirme le travail sur ConfidentialTransfer, BatchV1_1, Sponsor et DynamicMPT, ainsi que des corrections et d'autres modifications du protocole. La publication du logiciel elle-même n'active pas ces fonctionnalités sur le réseau.

La distinction est importante car certains rapports décrivent six mises à jour comme déjà en ligne. Dans le cadre du processus d'amendement de XRP Ledger, les nouvelles fonctionnalités du protocole nécessitent le soutien des validateurs avant l'activation. Un amendement doit maintenir plus de 80 % de soutien de la part des validateurs de confiance pendant deux semaines consécutives avant de prendre effet.

XRP Ledger 3.3.0 ajoute des outils de confidentialité et de transaction atomique

ConfidentialTransfer est conçu pour ajouter de la confidentialité aux jetons multi-usages, ou MPT. La documentation XRPL indique que l'amendement utilise la cryptographie pour protéger les soldes individuels et les montants de transfert tout en préservant les mécanismes permettant aux parties autorisées, y compris les émetteurs ou les auditeurs, de vérifier les informations nécessaires à la conformité.

La fonctionnalité reste soumise à l'activation de l'amendement, donc les transferts MPT privés ne doivent pas encore être décrits comme actifs sur le réseau principal XRPL.

BatchV1_1 est un autre composant majeur. La norme XLS-56 permet de regrouper et de traiter plusieurs transactions ensemble, y compris des transactions impliquant différents comptes. L'exécution atomique peut aider les flux de règlement où plusieurs actions doivent réussir ensemble plutôt que de laisser un côté complété tandis qu'un autre échoue.

Les fonctionnalités révisées suivent des découvertes de sécurité antérieures

Batch a une histoire importante. Une version antérieure a été désactivée avant l'activation sur le réseau principal après qu'un problème de sécurité ait été découvert dans la logique de signature des transactions. La fondation XRPL s'est ensuite orientée vers BatchV1_1 comme remplacement corrigé. Comme précédemment rapporté dans la couverture de sécurité XRPL, les développeurs ont intensifié l'examen formel autour des mises à jour récentes.

La délégation de permission a suivi un chemin similaire. XRPL a divulgué en septembre 2025 qu'un bogue dans l'amendement antérieur aurait pu permettre à une transaction non autorisée de facturer des frais à un autre compte dans des conditions spécifiques. Les validateurs ont été conseillés de voter non, et la fonctionnalité vulnérable n'a jamais été activée. PermissionDelegationV1_1 a été développé comme son remplacement.

Le concept révisé permet à un compte d'accorder des permissions de transaction définies sans remettre sa clé privée principale, soutenant ainsi les portefeuilles opérationnels avec une autorité limitée.

Sponsor et DynamicMPT visent l'intégration institutionnelle

Sponsor, basé sur XLS-68, est conçu pour permettre à un autre compte de couvrir les frais de transaction ou les exigences de réserve tout en permettant à l'utilisateur de garder le contrôle du compte et des clés. La fonctionnalité pourrait permettre aux applications d'intégrer des utilisateurs sans exiger qu'ils acquièrent des XRP uniquement pour couvrir les coûts du réseau. La proposition XLS-68 soutient explicitement le parrainage des frais et des réserves tout en préservant le contrôle des clés par l'utilisateur.

DynamicMPT cible les émetteurs de jetons. La proposition XLS-94 permet aux émetteurs de désigner certaines propriétés de MPT comme modifiables lors de la création d'un jeton, puis de mettre à jour ces champs autorisés ultérieurement. La norme est destinée à s'adapter aux exigences commerciales ou de conformité changeantes sans rendre chaque propriété de jeton librement modifiable.

Ensemble, ces fonctionnalités s'inscrivent dans l'accent croissant du XRPL sur la finance tokenisée. Dans une couverture connexe sur la tokenisation, crypto.news a rapporté que JPMorgan, Mastercard, Ondo Finance et Ripple ont testé un remboursement de Trésorerie tokenisé utilisant le XRPL.

Toutes les mises à jour citées n'appartiennent pas à la version 3.3.0

Une correction est nécessaire concernant le cadre largement diffusé des "six mises à jour". fixCleanup3_2_0 appartient au cycle précédent xrpld 3.2.0, et non au nouveau package de fonctionnalités 3.3.0 récemment publié. Le changelog GitHub de la version 3.3.0 montre plutôt des travaux autour de LendingProtocolV1_1 et une piste distincte fixCleanup3_3_0 aux côtés des fonctionnalités principales.

La publication ne doit donc pas être interprétée comme six capacités finies devenant disponibles simultanément. C'est une étape importante pour le logiciel serveur qui fournit aux validateurs et aux opérateurs le code nécessaire pour les décisions d'amendement. Les amendements individuels peuvent avoir des délais de vote différents et peuvent échouer à s'activer si le soutien tombe en dessous du seuil requis.

Ce processus de gouvernance a déjà eu de l'importance. Les amendements originaux Batch et Permission Delegation ont été arrêtés après que des bogues ont été identifiés avant l'activation du mainnet, montrant que l'inclusion dans le logiciel ou le vote des validateurs n'est pas la même chose que le déploiement en production.

Que se passe-t-il ensuite pour les validateurs XRPL

Les opérateurs de nœuds doivent maintenant évaluer la version 3.3.0 et décider s'ils souhaitent mettre à niveau et soutenir des amendements individuels. Les dates d'activation exactes dépendent du vote des validateurs, plutôt que de la publication du logiciel du 6 août. Les règles d'amendement du XRPL exigent que la supermajorité persiste continuellement pendant deux semaines.

Pour les détenteurs de XRP, le changement immédiat est technique plutôt que monétaire. La version 3.3.0 élargit l'arsenal potentiel du réseau pour la confidentialité, le règlement en plusieurs étapes, l'autorité déléguée, l'intégration sponsorisée et l'émission de tokens configurables, mais aucune ne garantit une demande accrue de XRP ou une appréciation de prix.

Les prochaines étapes vérifiables seront l'adoption de la version 3.3.0 par les validateurs, les niveaux de soutien aux amendements et les dates d'activation programmées. Jusqu'à ce que ces seuils soient atteints, les nouvelles capacités doivent être décrites comme publiées dans le logiciel des nœuds et en cours de gouvernance, et non comme des fonctionnalités pleinement actives du mainnet XRP Ledger.

Les décisions des validateurs, plutôt que le marketing de la publication, détermineront quand chaque fonctionnalité devient utilisable sur le mainnet.