Ripple lance XRPL 3.0.0 avec une avancée majeure dans la comptabilité des dépôts fiduciaires

Ripple a publié la version 3.0.0 du XRP Ledger et a exhorté les validateurs et les opérateurs de nœuds à effectuer la mise à niveau rapidement afin d'éviter les perturbations. Il ne s'agit pas seulement d'une mise à niveau. En effet, elle corrige un problème technologique fondamental lié au séquestre de tokens.

Il s'agit de l'une des fonctions clés utilisées pour le règlement ainsi que pour les transactions planifiées sur le XRPL. Les acteurs impliqués dans le développement d'applications d'entreprise ont considéré le séquestre comme l'un des piliers essentiels de la confiance.

À lire également : Le T2 du XRPL enregistre une adoption record de 154 % du RLUSD dans un contexte de hausse de la capitalisation boursière du XRP

Pourquoi le séquestre de tokens est important pour le XRPL

Cependant, le séquestre a toujours été une partie intégrante des services de règlement du XRPL. Pendant longtemps, il a exclusivement pris en charge l'utilisation du XRP. Mais cela signifiait que si une entreprise devait émettre ses tokens sur le XRPL, elle aurait du mal à tirer parti des fonctionnalités avancées.

La proposition appelée XLS-85 Token Escrow a introduit le service de séquestre pour les actifs émis, tels que les IOUs et les Multi-Purpose Tokens.

Les Multi-Purpose Tokens sont particulièrement pertinents dans la tokenisation. Ils combinent des tokens fongibles et non fongibles et contiennent également une grande quantité de métadonnées.

Les développeurs du XRPL citent les Multi-Purpose Tokens comme une solution pour un environnement hautement conforme, car ils peuvent inclure des règles et des cycles de vie sans utiliser de Smart Contracts externes.

Le bug comptable qui a suscité des inquiétudes

Les testeurs internes de la conception originale du Token Escrow ont remarqué le problème concernant les MPTs, qui contiennent des frais de transfert. Ce problème est apparu après l'achèvement du processus de séquestre et le déverrouillage des tokens. 

Lorsque 100 tokens étaient déverrouillés, avec des frais de transfert de 1 token, le destinataire recevait effectivement 99 tokens.

Le problème résidait dans la comptabilité des émetteurs. Le Ledger diminuait le LockedAmount de l'émetteur de seulement 99 au lieu de la totalité des 100 initialement séquestrés. Ainsi, un token restait dans l'état verrouillé. Finalement, ce problème mineur peut s'accumuler et entraîner des écarts dans les montants d'approvisionnement sur le réseau.

Les experts qui suivent l'infrastructure du XRPL ont constamment souligné les dangers des moindres écarts comptables dans le contexte des réseaux de tokens et comment ils peuvent compromettre la confiance dans ces réseaux.

Comment TokenEscrowV1 corrige le problème

Ce problème a été résolu dans l'amendement TokenEscrowV1, dans lequel la logique de séquestre brut a été isolée de la livraison nette. Une fois le séquestre terminé, le LockedAmount diminuera de la totalité de sa valeur précédemment verrouillée.

Les frais de transfert seront traités indépendamment afin que seule la valeur nette impacte l'approvisionnement. Aucun token ne restera verrouillé et les valeurs d'approvisionnement total seront maintenues avec précision.

À lire également : Le portefeuille XRPL de nouvelle génération d'Anodos simplifie l'intégration et récompense les utilisateurs