XRP Ledger retire cinq amendements dans la version 3.3.0 sans affecter les utilisateurs
Les développeurs du XRP Ledger ont retiré cinq amendements de protocole anciens dans la version xrpld 3.3.0, mais cette évolution ne supprime pas leurs fonctionnalités et n’exige aucune action particulière de la part des détenteurs de XRP.
Les cinq amendements concernés sont Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve et fixUniversalNumber.
Le terme « retrait » peut prêter à confusion. Dans ce contexte, il ne signifie pas que les fonctions sont supprimées du réseau. Il signifie que leur comportement est devenu une partie permanente et inconditionnelle du protocole XRP Ledger.
Autrement dit, le réseau abandonne simplement l’ancien code qui décrivait son fonctionnement avant l’activation de ces amendements.
Le retrait rend les nouvelles règles permanentes
Le système d’amendements du XRP Ledger permet d’introduire de nouvelles règles sans les imposer immédiatement au réseau principal.
Les validateurs votent sur chaque amendement.
Pour qu’une proposition soit activée sur le Mainnet, elle doit conserver le soutien de plus de 80 % des validateurs de confiance pendant deux semaines consécutives.
Une fois activé, l’amendement devient la nouvelle règle de fonctionnement.
Pendant une période donnée, le logiciel xrpld conserve toutefois également une partie de l’ancien code.
Cette architecture permet notamment aux développeurs de reproduire le comportement historique du réseau lorsqu’ils analysent d’anciennes transactions.
Pourquoi conserver l’ancien code pendant plusieurs années
Après l’activation d’un amendement, l’ancien comportement peut encore être utile pour le débogage.
Les développeurs peuvent avoir besoin de reproduire précisément les conditions dans lesquelles une transaction ancienne a été traitée.
Cependant, conserver pendant plusieurs années des branches de code devenues obsolètes augmente progressivement la complexité du logiciel.
La documentation officielle du XRP Ledger permet donc de retirer un amendement lorsqu’il est actif sur le Mainnet depuis au moins deux ans.
À ce stade, l’ancien chemin de code est supprimé et la nouvelle règle devient simplement une composante normale du protocole.
Un nettoyage du code plutôt qu’une suppression de fonctionnalités
Mayukha Vadari, ingénieure logicielle chez RippleX, a décrit cette opération comme un nettoyage de la base de code.
Selon son explication, les utilisateurs ne devraient constater aucun changement dans le fonctionnement habituel du réseau.
Le comportement introduit par les amendements reste actif.
Ce qui disparaît est uniquement la logique correspondant à l’état antérieur du XRP Ledger.
Cette distinction est particulièrement importante pour Clawback, l’amendement le plus visible parmi les cinq concernés.
Clawback reste disponible sur XRP Ledger
Le retrait de Clawback ne signifie pas que la fonction Clawback disparaît.
Cette fonctionnalité est active sur le Mainnet depuis le 8 février 2024.
Elle permet à certains émetteurs de récupérer des jetons qu’ils ont eux-mêmes émis, à condition que le compte émetteur ait activé les paramètres nécessaires.
Elle ne permet pas de récupérer du XRP natif.
Après le retrait de l’amendement, ce comportement reste exactement intégré au protocole.
Le réseau supprime simplement l’ancien code correspondant à une version de XRP Ledger dans laquelle Clawback n’était pas encore disponible.
Les quatre autres amendements suivent le même principe
fixDisallowIncomingV1 avait corrigé un problème concernant l’autorisation des trust lines.
fixInnerObjTemplate avait traité des erreurs impliquant certains objets internes liés aux AMM.
fixNFTokenReserve avait ajouté des vérifications de réserve lors de l’acceptation d’offres de NFT.
fixUniversalNumber avait harmonisé certaines parties des calculs en virgule flottante décimale du XRP Ledger.
Dans chaque cas, la règle introduite reste active après le retrait.
Seule l’ancienne logique antérieure à l’amendement disparaît du logiciel moderne.
Ce processus n’est pas nouveau pour XRPL
La version 3.3.0 n’est pas la première à retirer d’anciens amendements.
XRP Ledger a déjà appliqué cette méthode dans des versions précédentes.
La version 3.2.0 avait par exemple retiré des modifications plus anciennes liées aux Checks, à Deposit Authorization, à la suppression de comptes et à d’autres fonctions du protocole.
Le retrait constitue donc une étape normale du cycle de vie d’un amendement lorsqu’il est devenu suffisamment ancien et stable.
La version 3.3.0 ouvre aussi un nouveau cycle d’amendements
Alors que cinq anciens amendements quittent leur statut conditionnel, xrpld 3.3.0 introduit six nouvelles propositions.
Il s’agit de BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, Sponsor et fixCleanup3_3_0.
Leur présence dans le logiciel ne signifie pas qu’elles sont déjà actives sur le Mainnet.
Chacune doit encore passer par le processus de validation du réseau.
Les nouvelles fonctions nécessitent encore un vote
Pour être activé, chaque nouvel amendement doit obtenir plus de 80 % de soutien parmi les validateurs de confiance pendant deux semaines consécutives.
Si le soutien tombe sous ce seuil, le compteur est réinitialisé.
Cela signifie qu’aucune des nouvelles fonctionnalités mentionnées dans la version 3.3.0 ne doit être considérée comme définitivement active simplement parce que son code existe déjà.
La différence avec les cinq amendements retirés est donc importante.
Les nouveaux attendent encore l’approbation du réseau.
Les anciens ont déjà été activés depuis des années et deviennent maintenant des règles permanentes du protocole.
ConfidentialTransfer cible des transferts plus privés
Parmi les nouveaux amendements, ConfidentialTransfer pourrait permettre des transferts de Multi-Purpose Tokens avec davantage de confidentialité.
Cette fonctionnalité s’inscrit dans les efforts visant à élargir l’utilisation du XRP Ledger pour des actifs tokenisés et des applications institutionnelles.
Elle reste toutefois conditionnée au vote des validateurs.
Son inclusion dans xrpld 3.3.0 constitue seulement une étape technique permettant au réseau de l’activer ultérieurement si le seuil requis est atteint.
BatchV1_1 veut regrouper plusieurs transactions
BatchV1_1 permettrait à un compte de soumettre jusqu’à huit transactions internes dans un seul ensemble.
Cette possibilité pourrait rendre certaines opérations plus efficaces lorsque plusieurs actions doivent être exécutées ensemble.
Mais, comme pour les autres nouveaux amendements, cette fonction n’est pas automatiquement disponible sur le Mainnet.
Elle doit d’abord obtenir suffisamment de soutien des validateurs.
Sponsor pourrait modifier la gestion des frais
L’amendement Sponsor prévoit qu’un tiers puisse couvrir certains frais et exigences de réserve pour un autre utilisateur.
Une telle fonction pourrait faciliter certains usages en permettant à une entreprise ou à une application de prendre en charge une partie des coûts techniques pour ses clients.
Là encore, il s’agit d’une proposition en attente d’approbation.
Le fait que son code soit intégré à xrpld ne signifie pas que la règle est déjà utilisée par le réseau principal.
DynamicMPT vise davantage de flexibilité
DynamicMPT cherche à apporter davantage de flexibilité à certaines propriétés des Multi-Purpose Tokens.
Ces actifs font partie des outils du XRP Ledger destinés à prendre en charge différents modèles de tokenisation.
La capacité à modifier ou gérer certaines propriétés plus dynamiquement pourrait être utile pour des applications institutionnelles ou financières.
Cependant, l’effet réel dépendra de l’activation ou non de l’amendement.
Aucun changement requis pour les détenteurs de XRP
Pour les utilisateurs ordinaires, le retrait des cinq amendements n’impose aucune migration.
Il n’est pas nécessaire de déplacer ses XRP.
Aucune transaction particulière n’est requise.
Les wallets n’ont pas besoin d’être modifiés uniquement en raison de ces retraits.
Clawback et les autres règles concernées continuent de fonctionner normalement.
Le changement se situe principalement au niveau du code du serveur.
Les opérateurs de nœuds doivent mettre à jour xrpld
La situation est différente pour les opérateurs de serveurs.
La version 3.3.0 recommande aux opérateurs de mettre leur logiciel à jour rapidement afin de maintenir la continuité du service.
Un serveur doit disposer du code correspondant aux amendements qui pourraient être activés à l’avenir.
S’il reste sur une version trop ancienne et qu’un amendement non pris en charge devient actif, il peut devenir « amendment blocked ».
Dans cet état, le serveur ne peut plus participer normalement au réseau jusqu’à sa mise à jour.
Un précédent récent montre l’importance des mises à jour
La source rappelle qu’en juillet, l’activation de fixCleanup3_2_0 avait bloqué des nœuds fonctionnant avec des versions incompatibles antérieures à 3.2.0.
Cet épisode illustre pourquoi les opérateurs doivent suivre les nouvelles versions du logiciel.
La mise à jour vers xrpld 3.3.0 ne sert donc pas uniquement à retirer du code ancien.
Elle prépare également les serveurs aux éventuelles activations futures des nouveaux amendements.
Le retrait simplifie le protocole à long terme
Supprimer les anciens chemins de code présente plusieurs avantages pour les développeurs.
Une base de code plus simple peut être plus facile à maintenir.
Elle réduit le nombre de comportements historiques à gérer dans les versions actuelles.
Elle peut aussi diminuer le risque de bugs liés à des branches de logique devenues inutiles.
Le compromis est que certains tests historiques précis peuvent nécessiter l’utilisation d’anciennes versions du logiciel.
Le comportement historique peut nécessiter d’anciens logiciels
La documentation de test du XRP Ledger précise que reproduire exactement certaines anciennes transactions peut nécessiter la version de xrpld qui les avait initialement traitées.
Une fois un amendement retiré, les versions modernes ne conservent plus nécessairement toutes les conditions antérieures.
Cela ne pose pas de problème pour les transactions actuelles.
Mais pour les développeurs ou chercheurs qui analysent l’historique avec précision, conserver l’accès aux anciennes versions du logiciel peut rester utile.
Le prochain enjeu concerne les six nouveaux amendements
L’attention se déplace désormais vers les propositions introduites dans xrpld 3.3.0.
Les validateurs devront décider lesquelles méritent d’être activées.
ConfidentialTransfer pourrait être particulièrement suivi en raison de son potentiel pour les actifs tokenisés institutionnels.
BatchV1_1, Sponsor et DynamicMPT pourraient également modifier la manière dont certaines applications utilisent le réseau.
Leur avenir dépendra toutefois entièrement du processus de gouvernance du XRP Ledger.
Conclusion
XRP Ledger 3.3.0 retire cinq amendements anciens, mais cette opération ne supprime aucune de leurs fonctionnalités.
Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve et fixUniversalNumber restent intégrés au fonctionnement du réseau.
Le retrait signifie simplement que leur comportement est désormais permanent et que l’ancien code pré-amendement peut être supprimé.
Pour les détenteurs de XRP, aucune action n’est requise.
Les opérateurs de nœuds, en revanche, doivent maintenir leur logiciel à jour afin de rester compatibles avec les prochaines évolutions du protocole.
Point clé final
Le retrait de cinq amendements dans xrpld 3.3.0 représente une simplification technique, pas un recul fonctionnel. Les règles restent actives et deviennent une partie permanente du protocole, tandis que l’attention du réseau se tourne désormais vers six nouveaux amendements qui devront encore obtenir l’approbation des validateurs.



