- XRPLD 3.2.1 corrige les risques liés au manifeste du validateur, tandis que 3.3.0 développe les fonctionnalités du protocole.
- BatchV1_1 restaure les transactions groupées avec une validation de signature interne corrigée.
- Les transferts confidentiels et les frais sponsorisés sont en cours de développement et ne sont pas actifs.
Le prochain cycle logiciel XRP Ledger sépare une réparation de sécurité ciblée d’un ensemble plus large de modifications de protocole pour les validateurs, les plateformes et les développeurs d’applications. Au 1er août 2026, xrpld 3.2.1 restait la dernière version, tandis que le jalon 3.3.0 affichait 122 éléments sans date de sortie.
Ce statut crée une distinction pour les validateurs, les plateformes et les développeurs préparant un plan de mise à niveau xrpld 2026. Essentiellement, la version 3.2.1 renforce la résilience des nœuds en traitant les problèmes de propagation des manifestes validateurs et en limitant les risques liés aux messages pairs non fiables.
En revanche, XRPL 3.3.0 vs. 3.2.1 propose un ensemble plus large incluant le batching des transactions, des outils de confidentialité, des fonctions de sponsoring et des garanties opérationnelles.
BatchV1_1 apporte des transactions groupées plus sûres sur XRPL 3.3.0
La version 3.2.1 a été publiée le 31 juillet en réponse ciblée aux risques dans le manifeste du validateur. Il limitait le cache de manifestes non fiables, rejetait les manifestes de validateur surdimensionnés, et limitait le nombre de manifestes non fiables transportés dans les messages pairs. Ces changements réduisaient l’exposition à des données malformées ou excessives sans introduire des fonctions protocolaires plus larges.
Face à cette approche plus étroite de la sécurité, la première différence majeure dans le jalon 3.3.0 est BatchV1_1, qui remplace l’amendement de la série retirée. XRPL avait précédemment désactivé Batch et fixBatchInnerSigs dans la version 3.1.1 après que des chercheurs ont découvert une faille d’autorisation interne à la transaction. Comme les transactions internes ne possèdent pas de signatures indépendantes, certaines conditions auraient pu permettre l’exécution d’instructions non autorisées.
Pour remédier à cette faiblesse, le jalon de développement de la 3.3.0 inclut la fusion de BatchV1_1 la mise en œuvre et le code permettant des modifications. La conception conserve l’approche XLS-56 consistant à combiner plusieurs transactions selon des règles d’exécution définies. Cependant, il ajoute une validation de signature corrigée au lieu de s’appuyer sur l’amendement obsolète fixBatchInnerSigs.
| Zone de comparaison | XRPLD 3.2.1 | XRPLD 3.3.0 attendu |
| Statut de sortie | Dernière version stable en production | Jalon de développement avec 122 éléments achevés |
| Objectif principal | Correctif de sécurité manifest du validateur | Mise à jour plus large du protocole et de la fiabilité |
| Transactions par lots | La promotion retirée reste désactivée | BatchV1_1 ajoute des vérifications d’autorisation repensées |
| Transferts confidentiels | Non supporté | Le code de développement prend en charge le transfert confidentiel. |
| Frais sponsorisés | Non actif | Les travaux liés aux sponsors sont toujours en cours de développement |
Les fonctionnalités XRPL 3.3.0 nécessitent toujours l’approbation des validateurs
La deuxième différence concerne l’activation. Le support logiciel n’active pas automatiquement les modifications du registre XRP sur le réseau principal. Un amendement doit maintenir le soutien de plus de 80 % des validateurs de confiance pendant deux semaines. Par conséquent, les opérateurs doivent séparer la disponibilité du code de l’activation réseau lors de la révision du bug des transactions batch XRPL.
Transferts confidentiels : Ajouter des outils de confidentialité à XRPL 3.3.0
La troisième différence est ConfidentialTransfer, basé sur XLS-96. Les travaux de développement fusionnés permettent l’amendement à l’intérieur de la branche 3.3.0. La proposition masquerait les soldes multi-usages des jetons et les montants transférés via la cryptographie EC-ElGamal et des preuves à connaissance nulle.
Les émetteurs autorisés, auditeurs ou entités désignées pouvaient toujours bénéficier d’un accès à la divulgation. Cette structure Confidential MPT XRP Ledger cible les actifs tokenisés réglementés tout en réduisant l’exposition publique aux détails des transactions. Néanmoins, la documentation officielle indique toujours ConfidentialTransfer comme « en développement », tandis que la version stable maintient par défaut un vote « Non ».
Les frais sponsorisés pourraient supprimer les barrières d’intégration du XRP
La quatrième différence concerne l’amendement sur les frais et réserves sponsorisés, également appelé Sponsor ou XLS-68. Cela permettrait aux entreprises, aux applications ou aux émetteurs de couvrir les frais de transaction, les exigences de réserve ou les deux d’un autre compte. Les utilisateurs sponsorisés continueraient à contrôler leurs comptes et leurs clés privées.
En lien : La communauté XRP se concentre sur l’utilitaire XRPL avant les mises à jour majeures
Cette approche pourrait réduire les barrières d’intégration car les nouveaux utilisateurs n’auraient pas immédiatement besoin de XRP pour les frais ou les réserves de registres d’objets. Pourtant, Sponsor reste en développement et n’est pas actif dans la version 3.2.1. Son inclusion dans le package final 3.3.0 reste également non confirmée jusqu’à ce que les notes officielles de version définissent l’ensemble des fonctionnalités.
XRPL 3.3.0 étend la fiabilité et les protections du registre
Au-delà de ces caractéristiques proposées, la cinquième différence concerne la gamme plus large d’améliorations opérationnelles. Le jalon 3.3.0 inclut le filtrage des transactions déléguées pour les account_tx, les corrections d’arrondi numérique, les invariants de suppression de pseudo-comptes, les contrôles de gel alignés et les protections AMM impliquant les partages de coffre.
Ensemble, ces changements étendent la mise à niveau au-delà des modifications individuelles vers des améliorations plus larges de la fiabilité et de la cohérence du registre. En conséquence, XRPL 3.3.0 vs. 3.2.1 représente un passage de la maintenance défensive à des capacités protocolaires plus larges.
Pourtant, la 3.2.1 reste la cible stable pour les opérateurs. De plus, la clé de signature de paquets rotative de Ripple doit être fiable pour les mises à jour automatiques. Pendant ce temps, les tests devraient rester séparés jusqu’à ce que les paquets signés et les notes finales confirment la version XRP Ledger 3.3.0.
Disclaimer: The information presented in this article is for informational and educational purposes only. The article does not constitute financial advice or advice of any kind. Coin Edition is not responsible for any losses incurred as a result of the utilization of content, products, or services mentioned. Readers are advised to exercise caution before taking any action related to the company.
