Walidatorzy XRP Ledger włączyli poprawkę fixCleanup3_4_0 4 listopada o 14:52 UTC, zamykając blisko czterotygodniową lukę, w której delegowane spalenie tokenów mogło doprowadzić saldo konta poniżej zera. Coindoo potwierdziło transakcję aktywacji w zwalidowanym ledgerze 108,112,129, a publiczny serwer Mainnet firmy Ripple wskazuje poprawkę jako włączoną.

Aktywacja nastąpiła po głosowaniu, które pod koniec października na krótko utraciło superwiększość — to niepowodzenie odnotowano w przedaktywacyjnym raporcie Coindoo. Raport ten przedstawiał listę czynności, które zalecano wykonać emitentom. Kod i test przesłane wraz z poprawką odpowiadają na węższe pytanie: czyje tokeny faktycznie utworzyła nadwyżka.

Prawie Cztery Tygodnie Bez Kontroli Zerowego Salda

Delegowanie uruchomiono 8 października w ramach poprawki PermissionDelegationV1_1, według pulpitu poprawek XRPL. Od tego momentu do 4 listopada delegat posiadający uprawnienie PaymentBurn mógł, w pewnych konfiguracjach, doprowadzić spalenie poniżej zera. Dokumentacja uprawnień XRPL zalecała zatem oddelegowanie tego uprawnienia do czasu włączenia tej poprawki. Warunek został spełniony 4 listopada.

Commit w rippled, na którym opiera się poprawka, autorstwa użytkownika GitHub o identyfikatorze yinyiqian1, dodaje brakującą kontrolę. Gdy delegat posiada wyłącznie PaymentBurn, ledger porównuje kwotę płatności z saldem faktycznie posiadanym przez konto i odrzuca kwoty większe. Dokumentacja XRPL już wcześniej opisywała spalanie jako zatrzymujące się na zerze; w przypadku płatności delegowanych kod nie wymuszał tego limitu do czasu tej poprawki.

Wewnątrz Testu: Alice, Gateway i Zawyżona Płatność

Test w commicie wykorzystuje trzy konta. Alice posiada 50 USD emitowane przez konto o nazwie gateway. Gateway z kolei otworzył linię zaufania akceptującą do 200 USD emitowanych przez alice, co komentarze w kodzie opisują jako zapewnienie silnikowi płatności „płynności emisyjnej dostępnej po osiągnięciu zera na trustline”.

Alice następnie przyznaje trzeciemu kontu, bob, uprawnienie PaymentBurn, a bob wysyła płatność od alice do gateway na dwukrotność jej salda. Ślad pokazuje, jak ledger obsłużył tę płatność oraz kolejne kroki w ramach każdego zestawu zasad.

Stare zasady · tylko PaymentBurn

• 100 USD: zaakceptowane
• 50 alice spalone, następnie utworzono 50 USD emitowanych przez alice
• Stan końcowy: gateway posiada 50 USD emitowanych przez alice

Nowe zasady · tylko PaymentBurn

• 100 USD: odrzucone
• 20 USD: zaakceptowane, zostało 30
• 30 USD: zaakceptowane, saldo na zerze
• 1 USD: odrzucone

Nowe zasady · PaymentBurn + PaymentMint

• 100 USD: zaakceptowane
• Przekracza zero, ponieważ emisja jest autoryzowana, a gateway akceptuje IOU alice

Nowe Tokeny Były Długiem Alice

Zgodnie ze starymi zasadami płatność nie dodawała żadnych jednostek USD gateway. Zobowiązanie gateway wobec alice spadło z 50 do zera. Zamiast tego pojawiło się 50 USD emitowanych przez alice i posiadanych przez gateway: alice zakończyła transakcję jako dłużnik emitenta, na podstawie płatności podpisanej przez delegata, którego upoważniła wyłącznie do spalania.

Ledger traktuje te kwoty jako dwa różne aktywa. Dokumentacja formatu aktywów XRPL identyfikuje token trust-line po kodzie waluty i koncie emitującym, więc USD alice i USD gateway mają wspólny kod, ale nie emitenta. Natywne XRP, które nie ma emitenta, w ogóle nie podlegało tej luce.

W opisanym przypadku ryzyko dotyczyło zatem dwóch stron: konta, które oddelegowało uprawnienie do spalania i mogło przejąć zobowiązanie, którego nigdy nie zatwierdziło, oraz emitenta przyjmującego te IOU. Posiadacze USD gateway nie mieli do czynienia z nowymi jednostkami posiadanego tokenu.

Warunek Wstępny, Który Ograniczał Lukę

Przekroczenie zera zależało od jednego ustawienia po stronie gateway. Bez linii zaufania akceptującej IOU alice płatność nie miała sposobu na utworzenie USD emitowanych przez alice. Emitent musi samodzielnie założyć tę linię zaufania, co jest najsilniejszym argumentem, że luka miała ograniczony zasięg praktyczny.

Ten argument ma jednak swój margines. Dokumentacja delegowania XRPL wymieniała także Multi-Purpose Tokens (MPT) wśród aktywów, które delegat burn-only mógł emitować przed poprawką, podczas gdy test w commicie obejmuje wyłącznie przypadek trust-line. Żadne z obu źródeł nie opisuje rzeczywistego incydentu, ale lektury dotyczącej trust-line nie należy rozciągać na emitentów MPT bez odrębnego testu.

Jedno Uprawnienie Nadal Obejmuje Wszystkie Waluty

Poprawka ogranicza, ile delegat burn-only może spalić. Nie dotyka natomiast tego, których tokenów dotyczy uprawnienie. Uprawnienia granularne są zapisane na stałe w kodzie, a ta sama dokumentacja stanowi, że konto nie może przyznać delegatowi prawa do wysyłania niektórych walut z pominięciem innych.

Dla konta operacyjnego posiadającego tokeny USD i EUR lub stablecoiny od dwóch emitentów jedno nadanie PaymentBurn pozwala delegatowi spalić wszystkie z nich, każde do wysokości salda. Ewentualny podział według waluty musi wynikać z podziału posiadłości między konta. Uprawnienie typu transakcji Payment sięga jeszcze dalej, obejmując ogólnie płatności tego typu, więc weryfikacja sprawdzająca tylko dwie wartości granularne może je przeoczyć. Wcześniejszy artykuł Coindoo o tym, jak XRPL dzieli uprawnienia operacyjne między konta opisuje, jak instytucje strukturyzują te role.

Co Wskazywałoby, Czy Luka Była Wykorzystywana

Każde nadanie uprawnienia jest jawne. Wpis ledgera Delegate rejestruje konto nadające, delegata oraz jego listę uprawnień, co sprawia, że kwestia nadużycia jest pytaniem, które każdy może zweryfikować on-chain.

Wzorzec on-chain:

• Płatność zwalidowana po 8 października i przed ledgerem 108,112,129.
• Podpisana przez delegata posiadającego w danym momencie PaymentBurn, ale ani PaymentMint, ani Payment.
• Wysłana do emitenta tokenu, pozostawiająca konto delegujące z ujemnym saldem na tej linii zaufania.

Płatność spełniająca wszystkie trzy warunki potwierdziłaby, że do przekroczenia zera doszło na Mainnecie. Przegląd wszystkich nadań PaymentBurn w tym oknie, który nie wykazałby żadnej, wykluczyłby to dla tokenów trust-line, przy czym MPT stanowią odrębne sprawdzenie. Ponieważ DelegateSet zastępuje listę uprawnień w całości, jak wyjaśniał raport przedaktywacyjny, weryfikacja musi wykorzystywać uprawnienia obowiązujące w momencie walidacji każdej płatności.

Poprawka obowiązuje od ledgera 108,112,129 wzwyż. Każda płatność zwalidowana wcześniej pozostaje dokładnie tak, jak została zarejestrowana, łącznie z tymi, które przekroczyły zero. Dla operatorów przeglądających transakcje wokół tej zmiany numer zwalidowanego ledgera jest zatem właściwą granicą dla określenia, które zasady obowiązywały.

Źródło: Coindoo