La proposta di funzionalità Smart Escrow dell'XRP Ledger ha compiuto progressi nella sua fase di test. Il 5 ottobre, Mayukha Vadari, Staff Software Engineer di RippleX il cui lavoro si concentra sulla programmabilità dell'XRPL, ha annunciato la nona release dello Smart Escrow Devnet. Secondo la sua nota di release, la rete di test è migrata su una nuova infrastruttura, sostituendo i retired endpoint wasm.devnet.rippletest.net con wasm-devnet.dev.ripplex.io. La funzionalità proposta consentirebbe ai pagamenti in escrow sul ledger di seguire regole personalizzate limitate.

Un nuovo Devnet offre a Smart Escrow un test più ampio

La modifica dell'indirizzo è solo una parte dell'aggiornamento. Gli sviluppatori necessitano di un ambiente condiviso in cui contratti, wallet, librerie e configurazioni dei nodi possano essere eseguiti secondo le stesse regole — un lavoro che diventa particolarmente importante quando il codice è coinvolto nella decisione di sbloccare fondi bloccati.

Vadari ha dichiarato che il progetto rimane in fase di revisione e test mentre il team rafforza il framework e il codice. Il Devnet offre un luogo in cui individuare problemi di compatibilità e sicurezza prima che Smart Escrow possa essere preso in considerazione per la rete attiva.

Smart Escrow aggiunge una condizione programmabile ai fondi bloccati

L'XRPL supporta già pagamenti in escrow con condizioni di rilascio semplici, una capacità offerta dalla mainnet dalla fine del 2017. I fondi possono diventare disponibili dopo un tempo prestabilito, o quando qualcuno fornisce la fulfillment crittografica richiesta. Queste regole si adattano ad accordi semplici, sebbene un'applicazione possa necessitare di un approvatore designato, un evento verificato o più condizioni verificate insieme.

Si consideri un acquirente che blocca XRP per un venditore: l'escrow viene rilasciato solo dopo che un notaio designato ha verificato la consegna, mentre una scadenza consente all'acquirente di recuperare i fondi se tale conferma non arriva mai. Smart Escrow è pensato per questi casi. Un piccolo programma WebAssembly verrebbe allegato alla creazione dell'escrow, per poi essere eseguito quando qualcuno tenta di completarlo. Il programma valuta la regola concordata e determina se il rilascio può procedere.

Le modifiche proposte all'XRP Ledger sono documentate in proposte pubbliche XLS (XRP Ledger Standard). La specifica XLS-0100 Smartrows elenca possibili usi che vanno dai blocchi di conformità e dai pagamenti per traguardi fino al vesting di token, alle dinamiche d'asta e alle condizioni basate su oracle. Ogni caso d'uso si basa sulla stessa idea centrale: le regole per il rilascio dei fondi vengono scritte nell'escrow prima che il denaro venga bloccato.

Le restrizioni sono pensate per proteggere la rete e i fondi

Qualsiasi sistema che esegue codice attorno a un pagamento necessita di limiti chiari. Ogni validatore XRPL deve giungere allo stesso risultato al completamento di un escrow; in caso contrario, la rete non potrebbe concordare lo stato del ledger.

Il codice Smart Escrow gira quindi in un ambiente ristretto. Non può chiamare liberamente servizi esterni né accedere a file, e affronta limiti su memoria e calcolo. Questi confini aiutano a impedire che un contratto scritto male consumi risorse eccessive o produca risultati conflittuali tra i validatori, e mirano a evitare che i fondi restino intrappolati.

La proposta richiede inoltre che ogni Smart Escrow contenente bytecode includa un tempo CancelAfter. Gli utenti avrebbero una via per recuperare i fondi bloccati se una condizione non può essere soddisfatta, una controparte non agisce o il codice contiene un errore.

La libreria per sviluppatori Smart Escrow di Ripple include già esempi che coinvolgono approvazione notarile, verifica di credenziali, dati da oracle e proprietà di NFT. Questi esempi mostrano i tipi di regole che gli sviluppatori possono testare, mentre il Devnet rivela se il sistema sottostante le gestisce in modo coerente.

La nona release aggiorna i meccanismi alla base di quelle regole

La release nove riorganizza il modo in cui la rete esegue il codice Smart Escrow. Vadari ha dichiarato che l'integrazione WebAssembly è migrata da C++ a Rust, portando gas accounting, gestione degli errori e controlli di validazione attraverso un unico punto di ingresso. La sua nota di release stima un miglioramento del 30% al 50% nelle chiamate alle host function, una misura tecnica rilevante per gli sviluppatori che costruiscono e testano la logica di escrow. WebAssembly stesso è un formato di codice isolato usato ben oltre l'XRP Ledger — Polkadot, NEAR e diverse catene basate su Cosmos eseguono smart contract su di esso — e Rust è tra i linguaggi più comuni per compilarlo.

Anche le librerie software sono cambiate. Gli sviluppatori sono invitati a abbandonare il pacchetto all-in-one deprecato a favore di librerie separate comuni e dedicate all'escrow, per poi ritestare le loro applicazioni sul nuovo Devnet. Un contratto che compila localmente deve comunque funzionare con la rete, il suo formato di transazione e gli strumenti che lo circondano.

Questo è il valore pratico della release: offre ai team un ambiente più stabile per individuare i problemi che emergono solo quando più componenti dell'infrastruttura devono lavorare insieme.

L'escrow condizionato potrebbe integrare i pagamenti automatizzati

Le regole di rilascio controllato potrebbero inoltre integrare il lavoro dell'XRP Ledger sui pagamenti AI in XRP e RLUSD, la stablecoin agganciata al dollaro di Ripple. Un agente può preparare un pagamento, mentre Smart Escrow potrebbe definire le circostanze in cui i fondi già collocati in escrow autorizzati a muoversi.

Questa divisione dà alle applicazioni spazio per automatizzare i passaggi di routine senza lasciare vaghe le condizioni di rilascio del denaro. Il wallet, la richiesta di pagamento e l'escrow svolgono ciascuno ruoli diversi, rendendo più facile identificare dove è stata presa una decisione se qualcosa va storto.

Smart Escrow necessita ancora di un percorso verso la mainnet

Smart Escrow resta una bozza di proposta piuttosto che una funzionalità attiva dell'XRP Ledger. Una versione attiva richiederebbe un emendamento formale — il meccanismo del ledger per adottare modifiche al protocollo, in cui i validatori segnalano il supporto e gli upgrade si attivano solo dopo un ampio consenso — insieme a ulteriore implementazione e revisione di sicurezza, seguite da un processo di attivazione sulla mainnet.

La nona build Devnet offre agli sviluppatori un posto migliore per testare le regole proposte. I suoi progressi saranno misurati attraverso le migrazioni riuscite, i risultati sulla sicurezza e la reazione della più ampia comunità XRPL man mano che la funzionalità si avvicina a un possibile percorso verso la mainnet.

Questo articolo ha finalità informative e non costituisce consulenza finanziaria. Smart Escrow è in fase di sviluppo, e le sue specifiche, la tempistica e il percorso verso la mainnet possono cambiare.