XRP News: Gli sviluppatori di XRP Ledger si attivano per risolvere quattro vulnerabilità di sicurezza sui token
Gli sviluppatori di XRP Ledger propongono quattro correzioni di sicurezza per migliorare l'autorizzazione dei token e prevenire accessi non autorizzati, rafforzando i controlli sugli asset digitali istituzionali.
Correzioni di Sicurezza per XRP Ledger
Gli sviluppatori di XRP Ledger stanno lavorando a quattro correzioni di sicurezza progettate per prevenire che asset digitali riservati possano raggiungere conti non autorizzati, affrontando potenziali debolezze nell'infrastruttura sempre più utilizzata per la tokenizzazione istituzionale.
Proposta di Emendamento
Le modifiche sono raggruppate sotto una proposta di emendamento chiamata fixCleanup3_5_0, con la proposta di codice sottostante su GitHub aggiornata il 27 ottobre. Le correzioni rafforzerebbero i permessi sui token controllati dagli emittenti attraverso pagamenti, market maker automatizzati e altre transazioni.
Focus sulle Autorizzazioni
La proposta si concentra su token che richiedono un'autorizzazione esplicita dell'emittente prima che un conto possa detenerli. Queste restrizioni sono particolarmente rilevanti per stablecoin regolamentate e titoli tokenizzati, dove gli emittenti potrebbero dover verificare l'identità degli investitori o far rispettare i requisiti di idoneità.
Identificazione delle Vulnerabilità
Sotto l'architettura esistente, l'approvazione è registrata attraverso una linea di fiducia che collega un conto a un emittente di token. Gli sviluppatori hanno identificato diverse circostanze in cui le transazioni potrebbero eludere i controlli di autorizzazione previsti. Un problema riguarda i token di liquidità dei market maker automatizzati, che rappresentano diritti su asset depositati in pool di trading.
"La correzione proposta richiederebbe ai destinatari di avere autorizzazione per entrambi gli asset sottostanti prima di acquisire un token di pool."
Modifiche Aggiuntive
Un'altra modifica affronta un'esenzione che influisce sulle linee di fiducia con saldi esistenti. In precedenza, alcuni controlli si applicavano solo quando una linea di fiducia deteneva zero token, consentendo potenzialmente a un saldo non autorizzato di aumentare attraverso transazioni successive.
Il pacchetto più ampio cerca anche di prevenire che saldi di token non autorizzati vengano utilizzati in trasferimenti diversi dalla redenzione all'emittente e introduce controlli di coerenza aggiuntivi.
Espansione delle Istituzioni Finanziarie
Queste modifiche seguono un lavoro precedente su pool di liquidità autorizzati, dove gli sviluppatori hanno esplorato la possibilità di limitare la partecipazione a controparti istituzionali verificate. Le modifiche proposte arrivano mentre le istituzioni finanziarie tradizionali espandono il loro utilizzo di XRP Ledger per asset digitali.
"BNY ha recentemente ampliato le sue capacità di custodia per XRP e RLUSD, mentre Ripple ha perseguito relazioni riguardanti la liquidazione di stablecoin, titoli tokenizzati e finanziamenti istituzionali."
Controllo degli Asset
Per le istituzioni regolamentate, la capacità di controllare quali conti possono legalmente ricevere o detenere specifici asset è essenziale. Un emittente che distribuisce quote di fondi tokenizzati, ad esempio, potrebbe dover garantire che quei token rimangano con investitori idonei.
Se una transazione di mercato secondario o un meccanismo di pool di liquidità elude i controlli di autorizzazione, i controlli di conformità del sistema diventano meno affidabili. Le correzioni proposte rafforzerebbero quelle protezioni senza modificare il modello di proprietà nativo di XRP o richiedere ai normali detentori di XRP di ottenere il permesso dell'emittente.
Stato delle Correzioni
Il lavoro segue anche un precedente rilascio di sicurezza di XRPL, che ha introdotto protezioni separate per la funzionalità di transazione Batch della rete. Le quattro modifiche non sono state ancora integrate nel software principale di XRP Ledger né attivate su mainnet.
Una volta completata l'implementazione e la revisione, l'emendamento avrebbe comunque bisogno del supporto di oltre l'80% dei validatori fidati per due settimane consecutive prima dell'attivazione. Il processo è separato dalla precedente finestra di aggiornamento del 4 novembre, che riguarda fixCleanup3_4_0 piuttosto che il nuovo fixCleanup3_5_0 proposto.