Les développeurs du XRP Ledger ont publié la version 3.3.0 de xrpld le 6 août, rapprochant plusieurs modifications de protocole d'une éventuelle activation sur le réseau principal.
Résumé
- XRPL 3.3.0 introduit le code du 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 à la conformité pour les parties autorisées.
- BatchV1_1 restaure la fonctionnalité de transactions atomiques après qu'une version antérieure a été interrompue en raison d'une faille de sécurité.
- Sponsor permettrait à des tiers de couvrir les frais et les réserves tandis que les utilisateurs conservent le contrôle total de leur compte.
- DynamicMPT permettrait aux émetteurs de modifier ultérieurement certaines propriétés de jetons, répondant aux besoins évolutifs des entreprises et de la conformité.
La version officielle sur GitHub confirme le travail sur ConfidentialTransfer, BatchV1_1, Sponsor et DynamicMPT, ainsi que des correctifs et d'autres modifications de protocole. La publication du logiciel elle-même n'active pas ces fonctionnalités sur le réseau.
Cette distinction est importante car certains rapports décrivent six mises à niveau comme déjà en vigueur. Selon le processus d'amendement du XRP Ledger, les nouvelles fonctionnalités du protocole nécessitent le soutien des validateurs avant leur activation. Un amendement doit maintenir plus de 80 % de soutien 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 transactions atomiques
ConfidentialTransfer est conçu pour ajouter de la confidentialité aux Multi-Purpose Tokens, ou MPT. La documentation XRPL indique que l'amendement utilise la cryptographie pour masquer 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 une étape terminée tandis qu'une autre échoue.
Fonctionnalités révisées suite à 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 la découverte d'un problème de sécurité dans la logique de signature de transactions. La Fondation XRPL a ensuite évolué vers BatchV1_1 comme remplacement corrigé. Comme précédemment rapporté dans la couverture de la sécurité XRPL, les développeurs ont renforcé l'examen formel autour des récentes mises à niveau.
La délégation de permission a suivi un chemin similaire. XRPL a divulgué en septembre 2025 qu'un bug dans l'amendement précédent aurait pu permettre à une transaction non autorisée de facturer des frais à un autre compte dans des conditions spécifiques. Les validateurs ont été invités à voter non, et la fonctionnalité vulnérable n'a jamais été activée. PermissionDelegationV1_1 a été développé comme remplacement.
Le concept révisé permet à un compte d'accorder des permissions de transaction définies sans céder sa clé privée principale, prenant en charge 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 pendant que l'utilisateur garde 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 XRP uniquement pour couvrir les coûts 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 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 à l'évolution des exigences commerciales ou de conformité sans rendre chaque propriété de jeton librement modifiable.
Ensemble, ces fonctionnalités correspondent à l'accent croissant de 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 rachat de bons du Trésor tokenisés en utilisant XRPL.
Toutes les mises à niveau citées n'appartiennent pas à la version 3.3.0
Une correction est nécessaire concernant le cadre largement diffusé des « six mises à niveau ». fixCleanup3_2_0 appartient au cycle antérieur de xrpld 3.2.0, pas au package de fonctionnalités 3.3.0 nouvellement publié. Le journal des modifications GitHub de 3.3.0 montre plutôt des travaux autour de LendingProtocolV1_1 et une piste distincte fixCleanup3_3_0 en plus des fonctionnalités principales.
La version ne doit donc pas être lue comme six capacités terminées devenant disponibles simultanément. C'est un jalon logiciel serveur qui donne aux validateurs et aux opérateurs le code nécessaire pour les décisions d'amendement. Les amendements individuels peuvent avoir des calendriers de vote différents et peuvent ne pas être activés si le soutien tombe en dessous du seuil requis.
Ce processus de gouvernance a déjà compté. Les amendements originaux Batch et Permission Delegation ont été arrêtés après que des bugs ont été identifiés avant l'activation sur le réseau principal, 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.
Quelle est la prochaine étape pour les validateurs XRPL
Les opérateurs de nœuds doivent maintenant évaluer la version 3.3.0 et décider de mettre à niveau et de soutenir les 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 de 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 la boîte à outils potentielle 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 configurable de jetons, mais rien ne garantit une demande plus élevée de XRP ou une appréciation du prix.
Les prochains jalons vérifiables seront l'adoption de la 3.3.0 par les validateurs, les niveaux de soutien aux amendements et les dates d'activation prévues. Tant que ces seuils ne sont pas atteints, les nouvelles capacités doivent être décrites comme publiées dans le logiciel de nœud et en cours de gouvernance, et non comme des fonctionnalités pleinement actives du réseau principal XRP Ledger.
Les décisions des validateurs, plutôt que le marketing de la version, détermineront quand chaque fonctionnalité deviendra utilisable sur le réseau principal.
