La fonctionnalité Smart Escrow proposée sur le XRP Ledger a franchi une étape dans sa phase de test. Le 5 octobre, Mayukha Vadari, ingénieure logicielle chez RippleX dont le travail porte sur la programmabilité du XRPL, a annoncé la neuvième version de la Smart Escrow Devnet. Selon sa note de version, le réseau de test est passé à une nouvelle infrastructure, remplaçant les points d'accès retirés wasm.devnet.rippletest.net par wasm-devnet.dev.ripplex.io. La fonctionnalité proposée permettrait aux paiements sous séquestre sur le registre de suivre des règles personnalisées limitées.

Une nouvelle Devnet offre à Smart Escrow un champ de test élargi

Le changement d'adresse n'est qu'une partie de la mise à jour. Les développeurs ont besoin d'un environnement partagé où leurs contrats, portefeuilles, bibliothèques et configurations de nœuds peuvent être exécutés selon les mêmes règles — un travail qui devient particulièrement important lorsque du code intervient dans la décision de débloquer ou non des fonds bloqués.

Vadari a indiqué que le projet reste en phase d'examen et de test pendant que l'équipe renforce le cadre et le code. La Devnet fournit un lieu pour découvrir les problèmes de compatibilité et de sécurité avant que Smart Escrow puisse être envisagé pour le réseau principal.

Smart Escrow ajoute une condition programmable aux fonds bloqués

Le XRPL prend déjà en charge des paiements sous séquestre avec des conditions de libération simples, une capacité offerte par le mainnet depuis fin 2017. Les fonds peuvent devenir disponibles après un délai défini, ou lorsqu'une personne fournit le fulfillent cryptographique requis. Ces règles conviennent aux arrangements simples, mais une application peut avoir besoin d'un approbateur désigné, d'un événement vérifié, ou de plusieurs conditions vérifiées ensemble.

Prenons l'exemple d'un acheteur qui bloque des XRP pour un vendeur : le séquestre ne se libère qu'après qu'un notaire désigné a vérifié la livraison, tandis qu'une échéance permet à l'acheteur de récupérer les fonds si cette confirmation n'arrive jamais. Smart Escrow est conçu pour de tels cas. Un petit programme WebAssembly serait joint lors de la création du séquestre, puis exécuté lorsqu'une personne tente de le conclure. Le programme évalue la règle convenue et détermine si la libération peut avoir lieu.

Les modifications proposées au XRP Ledger sont documentées dans des propositions publiques XLS (XRP Ledger Standard). La spécification XLS-0100 Smart Escrows énumère les usages possibles, allant des blocages de conformité et des paiements par jalons au vesting de tokens, en passant par les mécanismes'enchères et les conditions basées sur des oracles. Chaque cas d'usage repose sur la même idée fondamentale : les règles de libération des fonds sont écrites dans le séquestre avant que l'argent ne soit bloqué.

Des restrictions conçues pour protéger le réseau et les fonds

Tout système exécutant du code autour d'un paiement a besoin de limites claires. Chaque validateur XRPL doit aboutir au même résultat lorsqu'un séquestre est conclu ; sinon, le réseau ne pourrait pas s'accorder sur l'état du registre.

Le code Smart Escrow s'exécute donc dans un environnement restreint. Il ne peut pas librement appeler des services externes ni accéder à des fichiers, et il est soumis à des limites de mémoire et de calcul. Ces frontières aident à empêcher un contrat mal rédigé de consommer des ressources excessives ou de produire des résultats contradictoires entre les validateurs, et visent à éviter que les fonds ne restent piégés.

La proposition exige également que chaque Smart Escrow contenant du bytecode inclue un temps CancelAfter. Les utilisateurs disposeraient ainsi d'une voie pour récupérer les fonds bloqués si une condition ne peut être remplie, si une contrepartie ne donne pas suite, ou si le code contient une erreur.

La bibliothèque de développement Smart Escrow de Ripple comprend déjà des exemples impliquant l'approbation par un notaire, la vérification d'identifiants, les données d'oracle et la propriété de NFT. Ces exemples montrent les types de règles que les développeurs peuvent tester, tandis que la Devnet révèle si le système sous-jacent les traite de manière cohérente.

La neuvième version actualise la mécanique derrière ces règles

La neuvième version réorganise la manière dont le réseau exécute le code Smart Escrow. Vadari a indiqué que l'intégration WebAssembly est passée de C++ à Rust, regroupant la comptabilité du gas, la gestion des erreurs et les vérifications de validation via un point d'entrée unique. Sa note de version estime une amélioration de 30 % à 50 % des appels de fonctions hôtes, une mesure technique pertinente pour les développeurs qui construisent et testent la logique des séquestres. WebAssembly lui-même est un format de code isolé utilisé bien au-delà du XRP Ledger — Polkadot, NEAR et plusieurs chaînes basées sur Cosmos y exécutent des smart contracts — et Rust figure parmi les langages les plus courants pour le cibler.

Les bibliothèques logicielles ont également évolué. Les développeurs sont invités à abandonner le package tout-en-un obsolète au profit de bibliothèques distinctes, une commune et une dédiée aux séquestres, puis à retester leurs applications sur la nouvelle Devnet. Un contrat qui se compile localement doit néanmoins fonctionner avec le réseau, son format de transaction et les outils qui l'entourent.

C'est là la valeur pratique de cette version : elle offre aux équipes un environnement plus stable pour identifier les problèmes qui n'apparaissent que lorsque plusieurs composants d'infrastructure doivent fonctionner ensemble.

Le séquestre conditionnel pourrait compléter les paiements automatisés

Les règles de libération contrôlée pourraient également compléter les travaux du XRP Ledger sur les paiements par IA en XRP et RLUSD, le stablecoin adossé au dollar de Ripple. Un agent peut préparer un paiement, tandis que Smart Escrow pourrait définir les circonstances dans lesquelles les fonds déjà placés sous séquestre sont autorisés à circuler.

Cette répartition donne aux applications la possibilité d'automatiser les étapes courantes sans laisser floues les conditions de libération des fonds. Le portefeuille, la demande de paiement et le séquestre jouent chacun un rôle distinct, ce qui facilite l'identification du point de décision en cas de problème.

Smart Escrow doit encore trouver un chemin vers le mainnet

Smart Escrow reste une proposition en cours de rédaction plutôt qu'une fonctionnalité active du XRP Ledger. Une version en production nécessiterait un amendement formel — le mécanisme du registre pour adopter des changements de protocole, dans lequel les validateurs signalent leur soutien et les mises à niveau ne s'activent qu'après un large consensus — ainsi que des travaux d'implémentation et des examens de sécurité supplémentaires, suivis d'un processus d'activation sur le mainnet.\nLa neuvième version de la Devnet offre aux développeurs un meilleur environnement pour tester les règles proposées. Ses progrès seront mesurés à travers les migrations réussies, les découvertes de sécurité et la réaction de la communauté XRPL au sens large, à mesure que la fonctionnalité avance vers un éventuel chemin vers le mainnet.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil en investissement. Smart Escrow est en cours de développement, et ses spécifications, son calendrier et son chemin vers le mainnet sont susceptibles de changer.