I validatori dell'XRP Ledger hanno abilitato l'emendamento fixCleanup3_4_0 il 4 novembre alle 14:52 UTC, chiudendo una finestra di quasi quattro settimane durante la quale un burn delegato di token poteva spingere il saldo di un account oltre lo zero. Coindoo ha confermato la transazione di attivazione nel ledger validato 108,112,129, e il server Mainnet pubblico di Ripple elenca l'emendamento come abilitato.

L'attivazione è arrivata dopo una votazione che aveva brevemente perso la supermaggioranza a fine ottobre, una battuta d'arresto segnalata nel report pre-attivazione di Coindoo. Quel report descriveva la checklist che gli emittenti erano invitati a eseguire. Il codice e il test committati con la correzione rispondono a una domanda più stretta: i token dell'eccedenza appartenevano effettivamente a chi.

Quasi Quattro Settimane Senza un Controllo del Saldo Zero

La delega è diventata operativa l'8 ottobre sotto l'emendamento PermissionDelegationV1_1, secondo la dashboard degli emendamenti XRPL. Da allora fino al 4 novembre, un delegato in possesso di PaymentBurn poteva, in alcune configurazioni, spingere un riscatto oltre lo zero. Il riferimento ai permessi XRPL sconsigliava quindi di delegare quel permesso finché l'emendamento non fosse stato abilitato. La condizione si è verificata il 4 novembre.

Il commit rippled alla base della correzione, realizzato sotto l'handle GitHub yinyiqian1, aggiunge il controllo mancante. Quando un delegato possiede solo PaymentBurn, il ledger confronta l'importo del pagamento con il saldo effettivamente detenuto dall'account e rifiuta qualsiasi importo superiore. La documentazione XRPL descriveva già il burn come arrestato a zero; per i pagamenti delegati, il codice non applicava quel limite fino a questo emendamento.

Dentro il Test: Alice, un Gateway e un Pagamento Eccessivo

Il test nel commit utilizza tre account. Alice detiene 50 USD emessi da un account chiamato gateway. Il gateway, a sua volta, ha aperto una trust line che accetta fino a 200 USD emessi da alice, cosa che i commenti del codice descrivono come la fornitura al motore di pagamento di una "liquidità di emissione disponibile una volta che la trustline raggiunge lo zero".

Alice concede quindi a un terzo account, bob, il permesso PaymentBurn, e bob invia un pagamento da alice a gateway per il doppio di quanto lei detiene. La traccia mostra come il ledger ha gestito quel pagamento, e i follow-up, sotto ciascun set di regole.

Vecchie regole · Solo PaymentBurn

• 100 USD: accettato
• I 50 di alice riscattati, poi creati 50 USD emessi da alice
• Stato finale: gateway detiene 50 USD emessi da alice

Nuove regole · Solo PaymentBurn

• 100 USD: rifiutato
• 20 USD: accettato, ne restano 30
• 30 USD: accettato, saldo a zero
• 1 USD: rifiutato

Nuove regole · PaymentBurn + PaymentMint

• 100 USD: accettato
• Oltrepassa lo zero, poiché il minting è autorizzato e gateway accetta le IOU di alice

I Nuovi Token Erano il Debito di Alice

Con le vecchie regole, il pagamento non aggiungeva unità degli USD di gateway. L'obbligazione di gateway verso alice scendeva da 50 a zero. Quella che appariva invece era una cifra di 50 USD emessi da alice e detenuti da gateway: alice chiudeva la transazione debendo all'emittente, in forza di un pagamento firmato da un delegato che aveva autorizzato solo a riscattare.

Il ledger tratta questi come due asset distinti. La documentazione sul formato degli asset XRPL identifica un token su trust line tramite il codice valuta e l'account emittente, così gli USD di alice e quelli di gateway condividono un codice ma non un emittente. L'XRP nativo, che non ha emittente, era completamente fuori dalla vulnerabilità.

Nel caso documentato, il rischio ricadeva quindi su due soggetti: l'account che aveva delegato l'autorità di burn, che poteva assumere una passività mai approvata, e l'emittente che riceveva quelle IOU. I detentori degli USD di gateway non si trovavano di fronte a nuove unità del token che detenevano.

La Precondizione Che Ha Limitato la Vulnerabilità

L'eccedenza dipendeva da un'impostazione lato gateway. Senza una trust line che accettasse le IOU di alice, il pagamento non aveva modo di creare USD emessi da alice. Un emittente deve sottoporre quella trust line egli stesso, ed è l'argomento più forte a favore di una portata pratica limitata della vulnerabilità.

Quell'argomento ha un limite. La documentazione sulla delega XRPL elencava anche i Multi-Purpose Token (MPT) tra gli asset che un delegato con soli poteri di burn poteva emettere prima della correzione, mentre il test del commit copre solo il caso della trust line. Nessuna delle due fonti descrive un incidente reale, ma la lettura basata sulla trust line non dovrebbe essere estesa agli emittenti di MPT senza un test dedicato.

Un Permesso Copre Ancora Ogni Valuta

L'emendamento limita quanto un delegato con soli poteri di burn può riscattare. Non tocca quali token il permesso raggiunge. I permessi granulari sono hard-coded, e la stessa documentazione indica che un account non può concedere a un delegato il diritto di inviare alcune valute trattenendone altre.

Per un account operativo che detiene token USD ed EUR, o stablecoin di due emittenti, un'unica concessione PaymentBurn consente al delegato di riscattarli tutti, ciascuno fino al proprio saldo. Qualsiasi suddivisione per valuta deve derivare da come le partecipazioni sono ripartite tra gli account. Il permesso sul tipo di transazione Payment arriva ancora più lontano, coprendo i pagamenti di quel tipo in generale, così una revisione che controlla solo i due valori granulari può trascurarlo. Un precedente articolo di Coindoo su come XRPL divide l'autorità operativa tra gli account descrive come le istituzioni strutturano quei ruoli.

Cosa Mostrerebbe Se la Vulnerabilità È Stata Sfruttata

Ogni concessione è pubblica. La voce di ledger Delegate registra l'account concedente, il delegato e la sua lista di permessi, il che rende l'eventuale uso improprio una questione che chiunque può verificare onchain.

Il pattern onchain:

• Un pagamento validato dopo l'8 ottobre e prima del ledger 108,112,129.
• Firmato da un delegato in possesso di PaymentBurn, ma né di PaymentMint né di Payment, in quel momento.
• Inviato all'emittente del token, lasciando l'account delegante con un saldo negativo su quella trust line.

Un pagamento corrispondente a tutti e tre i punti confermerebbe che l'eccedenza si è verificata sulla Mainnet. Una revisione di ogni concessione PaymentBurn in quella finestra che non ne trovi nessuna lo escluderebbe per i token su trust line, con gli MPT come verifica separata. Poiché DelegateSet sostituisce una lista di permessi nella sua interezza, come spiegato nel report pre-attivazione, il controllo deve usare i permessi in vigore al momento della validazione di ciascun pagamento.

L'emendamento si applica dal ledger 108,112,129 in avanti. Qualsiasi pagamento validato prima resta esattamente come registrato, inclusi quelli che hanno superato lo zero. Per gli operatori che esaminano le transazioni attorno al cambiamento, il numero del ledger validato è quindi il confine rilevante per determinare quali regole si applicavano.

Fonte: Coindoo