XRP Ledger sluit bug die accounts in schuld kon brengen
Belangrijkste punten
- •De fixCleanup3_4_0-amendment ging op 4 november om 14:52 UTC live in gevalideerde ledger 108,112,129, waarmee een kwetsbaarheidsvenster eindigde dat begon toen delegatie op 8 oktober live ging onder PermissionDelegationV1_1.
- •Vóór de fix kon een gedelegeerde met alleen de PaymentBurn-permissie een terugbetaling versturen die het saldo van het account overschreed, en het overschot verscheen als schuldtokens uitgegeven door het delegerende account, wat een nooit goedgekeurde verplichting creëerde.
- •De fout vereiste dat de ontvangende uitgever een trustline had geopend die de IOUs van het delegerende account accepteerde, native XRP was niet getroffen, en Multi-Purpose Tokens waren gemarkeerd als een gerelateerd geval dat niet door de test van de fix werd gedekt.
- •De amendment begrenst hoeveel een burn-only gedelegeerde kan terugbetalen, maar beperkt niet welke valuta's de permissie dekt, aangezien XRPL's gedetailleerde permissies niet per valuta kunnen worden gesplitst.
- •Omdat Delegate-ledgerentries openbaar zijn, kan elk misbruik vóór ledger 108,112,129 onchain worden gecontroleerd door betalingen te identificeren die zijn ondertekend door burn-only gedelegeerden en negatieve trustline-saldi achterlieten.

Validators op de XRP Ledger hebben de amendment fixCleanup3_4_0 op 4 november om 14:52 UTC ingeschakeld, waarmee een gat van bijna vier weken werd gesloten waarin een gedelegeerde token burn het saldo van een account onder nul kon duwen. Coindoo bevestigde de activatietransactie in gevalideerde ledger 108,112,129, en Ripple's publieke Mainnet-server vermeldt de amendment als ingeschakeld.
De activatie volgde op een stemming die eind oktober kort haar supermeerderheid verloor, een tegenslag die is bijgehouden in Coindoo's pre-activatierapport. Dat rapport beschreef de checklist die uitgevers werden aangeraden uit te voeren. De code en test die met de fix zijn meegeleverd, beantwoorden een beperktere vraag: wiens tokens de overschrijding daadwerkelijk heeft aangemaakt.
Bijna Vier Weken Zonder een Nulsaldocontrole
Delegatie ging op 8 oktober live onder de PermissionDelegationV1_1-amendment, volgens het XRPL-amendmentdashboard. Vanaf dat moment tot 4 november kon een gedelegeerde met PaymentBurn in sommige configuraties een terugbetaling onder nul duwen. XRPL's permissiereferentie adviseerde daarom om die permissie niet te delegeren totdat deze amendment was ingeschakeld. Die voorwaarde werd op 4 november vervuld.
De rippled-commit achter de fix, geschreven onder de GitHub-handle yinyiqian1, voegt de ontbrekende controle toe. Wanneer een gedelegeerde alleen PaymentBurn heeft, vergelijkt de ledger het betalingsbedrag met het saldo dat het account daadwerkelijk aanhoudt en weist alles dat groter is af. XRPL's documentatie beschreef verbranding al als stoppend op nul; voor gedelegeerde betalingen handhaafde de code die limiet pas met deze amendment.
In de Test: Alice, een Gateway en een Te Grote Betaling
De test in de commit gebruikt drie accounts. Alice houdt 50 USD uitgegeven door een account genaamd gateway. Gateway heeft op zijn beurt een trustline geopend die tot 200 USD uitgegeven door alice accepteert, wat de code-opmerkingen beschrijven als "issuing liquidity available once the trustline reaches zero" voor de betalingsengine.
Alice verleent vervolgens een derde account, bob, de PaymentBurn-permissie, en bob stuurt een betaling van alice naar gateway voor het dubbele van wat zij aanhoudt. De trace toont hoe de ledger die betaling en de vervolgbetalingen behandelde onder elke set regels.
Oude regels · alleen PaymentBurn
- 100 USD: geaccepteerd
- Alice's 50 terugbetaald, daarna 50 door alice uitgegeven USD aangemaakt
- Eindsituatie: gateway houdt 50 USD uitgegeven door alice
Nieuwe regels · alleen PaymentBurn
- 100 USD: geweigerd
- 20 USD: geaccepteerd, 30 over
- 30 USD: geaccepteerd, saldo op nul
- 1 USD: geweigerd
Nieuwe regels · PaymentBurn + PaymentMint
- 100 USD: geaccepteerd
- Overschrijdt nul, omdat aanmaken is geautoriseerd en gateway alice's IOUs accepteert
De Nieuwe Tokens Waren Alice's Schulden
Volgens de oude regels voegde de betaling geen eenheden van gateway's USD toe. Gateway's verplichting aan alice daalde van 50 naar nul. Wat in plaats daarvan verscheen, was 50 USD uitgegeven door alice en aangehouden door gateway: alice eindigde de transactie met een schuld aan de uitgever, op basis van een betaling ondertekend door een gedelegeerde die zij alleen had geautoriseerd om terug te betalen.
De ledger behandelt die als twee verschillende assets. XRPL's documentatie over asset-formaten identificeert een trustline-token aan de hand van de valutacode en het uitgevende account, dus alice's USD en gateway's USD delen een code maar niet een uitgever. Native XRP, dat geen uitgever heeft, viel volledig buiten de fout.
In het gedocumenteerde geval rustte het risico dus op twee partijen: het account dat burn-autoriteit had gedelegeerd en een verplichting kon oplopen die het nooit had goedgekeurd, en de uitgever die die IOUs ontving. Houders van gateway's USD kregen niet te maken met nieuwe eenheden van het token dat zij aanhielden.
De Voorwaarde Die de Fout Beperkte
De overschrijding hing af van één instelling aan de kant van gateway. Zonder een trustline die alice's IOUs accepteerde, had de betaling geen manier om door alice uitgegeven USD aan te maken. Een uitgever moet die trustline zelf aanmaken, en dat is het sterkste argument dat de fout een beperkte praktische reikwijdte had.
Dat argument heeft een kanttekening. XRPL's delegatiedocumentatie vermeldde ook Multi-Purpose Tokens (MPTs) als assets die een burn-only gedelegeerde vóór de fix kon aanmaken, terwijl de test in de commit alleen het trustline-geval dekt. Geen van beide bronnen beschrijft een daadwerkelijk incident, maar de trustline-interpretatie mag niet worden uitgesmeerd naar MPT-uitgevers zonder een eigen test.
Eén Permissie Dekkt Nog Steeds Elke Valuta
De amendment begrenst hoeveel een burn-only gedelegeerde kan terugbetalen. Ze laat onaangetast tot welke tokens de permissie reikt. Gedetailleerde permissies zijn hard gecodeerd, en dezelfde documentatie stelt dat een account een gedelegeerde niet het recht kan geven om sommige valuta's te versturen terwijl andere worden uitgesloten.
Voor een operations-account dat USD- en EUR-tokens aanhoudt, of stablecoins van twee uitgevers, laat een enkele PaymentBurn-toewijzing de gedelegeerde alle daarvan terugbetalen, elk tot zijn saldo. Elke splitsing per valuta moet komen uit hoe holdings over accounts zijn verdeeld. De Payment-transactietypepermissie reikt nog verder, omdat die betalingen van dat type in het algemeen dekt, zodat een controle die alleen de twee gedetailleerde waarden bekijkt deze kan missen. Coindoo's eerdere stuk over hoe XRPL de operationele autoriteit tussen accounts verdeelt beschrijft hoe instellingen die rollen structureren.
Wat Zou Laten Zien of de Fout Is Gebruikt
Elke toewijzing is openbaar. De Delegate-ledgerentry registreert het toekennende account, de gedelegeerde en zijn permissielijst, wat misbruik tot een vraag maakt die iedereen onchain kan controleren.
Het onchain-patroon:
- Een betaling gevalideerd na 8 oktober en vóór ledger 108,112,129.
- Ondertekend door een gedelegeerde die op dat moment PaymentBurn had, maar niet PaymentMint of Payment.
- Verzonden naar de uitgever van het token, waarbij het delegerende account een negatief saldo op die trustline achterliet.
Een betaling die aan alle drie voldoet, zou bevestigen dat de overschrijding op het Mainnet heeft plaatsgevonden. Een controle van elke PaymentBurn-toewijzing in dat venster die er geen vindt, zou het uitsluiten voor trustline-tokens, met MPTs als aparte controle. Omdat DelegateSet een permissielijst als geheel vervangt, zoals het pre-activatierapport uitlegde, moet de controle de permissies gebruiken die van kracht waren op het moment dat elke betaling werd gevalideerd.
De amendment geldt vanaf ledger 108,112,129. Elke betaling die daarvoor is gevalideerd, blijft exact staan zoals geregistreerd, inclusief betalingen die onder nul gingen. Voor operators die transacties rond de wijziging beoordelen, is het gevalideerde ledgernummer daarom de relevante grens om te bepalen welke regels golden.
Bron: Coindoo