Il Batch V1.1 di XRP Ledger è rimasto al di sopra della soglia richiesta di validatori mentre Ripple afferma che i gestori patrimoniali e i progetti commerciali si stanno preparando a utilizzare la funzionalità di transazione se verrà attivata più avanti questo mese.
- Batch V1.1 ha 30 voti dei validatori, mantenendo in carreggiata il conto alla rovescia per l'attivazione del 29 settembre di XRP Ledger.
- Ripple afferma che i gestori patrimoniali stanno costruendo attorno a Batch, sebbene i partner specifici rimangano per ora non divulgati.
- Batch può raggruppare otto transazioni, consentendo a trasferimenti di asset e pagamenti collegati di regolarsi atomicamente insieme.
- Gli sviluppatori hanno sostituito il Batch originale dopo che i ricercatori hanno trovato una falla critica nella validazione delle firme a febbraio.
- La versione 3.3.0 di XRPL ha distribuito Batch V1.1 dopo revisioni ampliate e correzioni ad ulteriori problemi di sicurezza.
CoinDesk ha riportato il 19 settembre che il responsabile dell'ingegneria di RippleX, Ayo Akinyele, ha affermato che il lavoro che coinvolge i gestori patrimoniali viene preparato attorno a Batch V1.1, che può raggruppare fino a otto transazioni in un'unica operazione Batch. Ripple non ha reso pubblici i nomi dei gestori patrimoniali né divulgato date di lancio definitive.
I dati sulle modifiche live esaminati il 20 settembre hanno mostrato 30 dei 35 validatori fidati monitorati a supporto di Batch V1.1. XRP Ledger richiede almeno l'80% di supporto mantenuto per 14 giorni consecutivi prima che una modifica si attivi, portando la soglia attuale a 28 voti. Il conto alla rovescia è iniziato il 15 settembre alle 14:06:41 UTC e indica una possibile attivazione poco dopo la stessa ora del 29 settembre se il supporto regge.
XRP Ledger Batch V1.1 può legare insieme le fasi di regolamento
La specifica XLS-56 definisce Batch come una transazione che raggruppa tra due e otto transazioni interne. Supporta quattro modalità di elaborazione: Tutto o Niente, Solo Uno, Fino al Fallimento e Indipendente. L'impostazione Tutto o Niente richiede che il gruppo completo venga eseguito con successo o impedisce che il batch abbia effetto.
Ripple sta concentrando parte della discussione commerciale sul delivery-versus-payment, o DvP. In tale transazione, un trasferimento di asset e il suo pagamento possono essere inseriti nella stessa operazione atomica. Un pagamento fallito impedirebbe il completamento del trasferimento di asset collegato con l'impostazione tutto-o-niente.
Akinyele ha detto a CoinDesk che "Condivideremo di più una volta che la funzionalità sarà attiva, incluso il lavoro con i principali gestori patrimoniali." Ripple non ha identificato tali società, quindi l'affermazione rimane una descrizione aziendale di un lavoro che non è ancora stato documentato pubblicamente attraverso annunci di partner nominati.
La specifica XLS-56 elenca tra i potenziali usi swap multi-account trustless, commissioni di piattaforma e strutture di prestiti lampo. Un marketplace o un wallet potrebbe, ad esempio, raggruppare il pagamento di un cliente con un costo di servizio invece di richiedere transazioni separate, mentre account diversi possono autorizzare singole fasi dello stesso Batch.
Akinyele ha affermato che "alcuni progetti sono già in fase di costruzione pensando a Batch", ma le identità dei partner e i programmi di produzione rimangono non divulgati. Ripple ha affermato che i dettagli sarebbero seguiti dopo la finalizzazione dei piani.
Il supporto dei validatori mantiene aperta la finestra del 29 settembre
All'ultima lettura del 20 settembre, Batch V1.1 aveva 30 voti di supporto tra i 35 validatori monitorati da XRPLDashboard, pari a circa l'85%. Il supporto è quindi rimasto al di sopra della soglia di 28 voti richiesta per continuare la finestra di attivazione.
La data prevista del 29 settembre è condizionale. Le modifiche di XRPL non si attivano semplicemente perché superano l'80% una volta. I validatori devono mantenere la supermaggioranza per l'intero periodo di 14 giorni, e i validatori possono cambiare i loro voti mentre il conto alla rovescia è in corso. Se il supporto scende al di sotto del livello richiesto, la finestra attuale si interrompe e sarebbe necessario un altro periodo ininterrotto dopo il ripristino della soglia.
L'ultimo conteggio estende una rapida ascesa del supporto questo mese. Batch V1.1 aveva allora 24 voti su 35 validatori, ovvero il 68,57%, lasciandolo al di sotto della soglia di attivazione. Il supporto era aumentato a 27 voti entro il 15 settembre, prima che abbastanza validatori sostenessero la modifica per avviare il conto alla rovescia.
La modifica stessa è stata distribuita con la versione xrpld 3.3.0 il 6 agosto. Le note di rilascio ufficiali di XRP Ledger descrivono Batch V1.1 come il sostituto della modifica Batch originale e affermano che supporta fino a otto transazioni interne, incluse strutture di atomic-swap.
Da allora, la XRP Ledger Foundation ha rilasciato xrpld 3.4.0. Il rilascio software del 16 settembre introduce modifiche separate per prestiti e pulizia e non sostituisce Batch V1.1, che rimane nel proprio processo di voto sulla mainnet. Gli operatori dei server sono stati invitati ad aggiornare alla versione 3.4.0 per la continuità del servizio.
Batch V1.1 è seguito a una falla critica nella prima versione
La modifica attuale è arrivata dopo che gli sviluppatori hanno fermato la proposta Batch originale a febbraio. La divulgazione ufficiale delle vulnerabilità di XRPL afferma che il ricercatore di sicurezza Pranamya Keshkamat e lo strumento Apex di Cantina AI hanno identificato una falla critica nella validazione delle firme il 19 febbraio.
In condizioni specifiche, il codice vulnerabile poteva smettere di controllare i firmatari di Batch dopo aver incontrato un account appena creato. XRPL Labs ha affermato che un attaccante avrebbe quindi potuto includere una transazione non autorizzata da un altro account senza possedere le chiavi private del proprietario di quell'account. Le potenziali transazioni avrebbero potuto includere pagamenti e alcune modifiche allo stato del ledger.
La falla non è mai diventata attiva sulla mainnet di XRP Ledger. La modifica originale era ancora nella sua fase di voto, e XRPL Labs ha affermato che nessun fondo era a rischio. I validatori sono stati invitati a votare contro di essa, mentre la versione rippled 3.1.1, rilasciata il 23 febbraio, ha reso Batch e fixBatchInnerSigs non supportati in modo che non potessero attivarsi.
Gli sviluppatori hanno poi modificato la logica di firma e autorizzazione per il sostituto. Il rapporto sulla vulnerabilità ha affermato che la correzione ha rimosso la condizione di successo prematuro, aggiunto salvaguardie di autorizzazione e rafforzato le regole di controllo delle firme. Batch V1.1 è stato successivamente incorporato in xrpld 3.3.0 dopo sviluppo e revisione.
Il lavoro sulla sicurezza è continuato prima dell'attuale voto dei validatori. Come riportato da crypto.news nella sua copertura della revisione di sicurezza di Batch V1.1, gli sviluppatori hanno corretto altri 11 problemi riguardanti firme, controlli di autorizzazione e possibili crash del server prima che la modifica raggiungesse la sua attuale fase di voto.
Akinyele ha detto a CoinDesk che la revisione includeva test avversariali interni, analisi assistita dall'IA, un concorso di sicurezza Sherlock e valutazioni che coinvolgevano Halborn e Common Prefix. CoinDesk ha attribuito tali dettagli a RippleX; i rapporti pubblici dei partner che coprono ogni parte di tale revisione non sono stati inclusi nel materiale esaminato per questo rapporto.
L'ecosistema di sviluppatori di XRPL ha apportato modifiche di supporto man mano che il design della firma evolveva. Un problema di giugno nel repository ufficiale xrpl.js ha documentato che la vecchia logica di firma di Batch non corrispondeva al formato rivisto di Batch V1.1 perché ulteriori informazioni su account e sequenza erano state legate alle firme. La cronologia delle versioni di JavaScript binary-codec afferma che il supporto alla firma di Batch V1.1 è stato aggiunto nella versione 2.9.0 ad agosto.
I gestori patrimoniali stanno testando più regolamenti tokenizzati su XRPL
I commenti di Ripple su Batch arrivano mentre le società finanziarie e gli sviluppatori stanno utilizzando l'infrastruttura di XRP Ledger per asset tokenizzati e progetti di regolamento istituzionale. A giugno, JPMorgan, Mastercard, Ondo Finance e Ripple hanno partecipato a un test di rimborso di Treasury statunitensi tokenizzati utilizzando XRP Ledger.
La presidente di Ripple Monica Long ha affermato in agosto che le istituzioni finanziarie stavano spostando parte del lavoro sugli asset tokenizzati dai programmi pilota verso la produzione. Crypto.news ha riportato sui progetti di tokenizzazione istituzionale di Ripple che Aviva Investors aveva lanciato una classe di quote di fondo tokenizzate su XRPL a luglio e che Ripple considerava RLUSD come possibile gamba di liquidità per il regolamento atomico delivery-versus-payment.
L'attività degli asset onchain è cresciuta insieme a quello sviluppo. Un'altra revisione di crypto.news dei dati RWA di XRP Ledger ha riportato a luglio che la rete aveva aggiunto circa 2,6 miliardi di dollari in valore di asset del mondo reale tokenizzati in sei mesi, escludendo le stablecoin, sulla base delle cifre di RWA.xyz. Lo stesso rapporto avvertiva che il valore degli asset rappresentati e gli asset attivamente distribuiti erano misure sostanzialmente diverse.
Batch V1.1 di per sé non richiede ai gestori patrimoniali di utilizzare XRP come asset trasferito. La funzionalità opera a livello di transazione e può raggruppare transazioni XRPL supportate da account diversi. XRP rimane rilevante per le commissioni di transazione del ledger, mentre le transazioni sottostanti possono coinvolgere altri asset e strutture di token supportati.
Il prossimo evento procedurale è la fine dell'attuale finestra di modifica. XRPLDashboard prevede l'attivazione di Batch V1.1 per il 29 settembre alle circa 14:06:41 UTC se almeno l'80% del sostegno dei validatori rimane ininterrotto per l'intero conto alla rovescia. L'ultimo conteggio pubblicato il 20 settembre rimaneva di 30 voti a favore su 35 validatori monitorati.