Oficjalna dokumentacja XRP Ledger (XRPL) zaleca posiadaczom kont, aby nie delegować uprawnienia PaymentBurn do czasu włączenia poprawki o nazwie fixCleanup3_4_0 w sieci. Ostrzeżenie dotyczy błędu na granicy między spalaniem a emisją tokenów — w pewnych okolicznościach pozwalał on delegatowi mającemu wyłącznie uprawnienie do spalania na emisję nowych tokenów zamiast ich niszczenia. Błąd nie może tworzyć nowego XRP, ale dotyka tego jednego zadania, które delegowanie uprawnień miało trzymać za kluczami offline.

Do czego miał służyć delegat tylko do spalania

Delegowanie uprawnień pozwala kontu przekazać określone zadania drugiemu kontu, które podpisuje je własnymi kluczami. Dokumentacja XRPL wprost opisuje cel: praca rutynowa odbywa się na kluczach utrzymywanych online, podczas gdy klucze z pełną kontrolą pozostają offline na potrzeby specjalnych zadań, takich jak emisja tokenów. Przewodnik Coindoo po delegowanych kontrolach kont XRPL opisuje, jak instytucje mogą podzielić te role.

Dwa z dwunastu szczegółowych uprawnień księgi dotyczą podaży tokenów. PaymentMint obejmuje płatności tworzące tokeny zbywalne lub Multi-Purpose Tokens (MPT). PaymentBurn obejmuje płatności je niszczące, a dokumentacja precyzyjnie wyznacza jego granicę: spalanie kończy się na zerowym saldzie.

Błąd tkwi właśnie na tej granicy. Przed poprawką płatność wysłana w ramach PaymentBurn mogła w pewnych okolicznościach przekroczyć zero i wyemitować nowe tokeny trust-line lub MPT. fixCleanup3_4_0 odrzuca każdą delegowaną płatność tylko-do-spalania, której kwota przekraczałaby granicę emisji, chyba że ten sam delegat posiada również PaymentMint. Pozostałe jedenaście szczegółowych uprawnień pozostaje nieobjęte.

To sprawia, że zasięg błędu jest wąski, ale to, czego dotyka, jest problematyczne. Może go wykorzystać wyłącznie konto, które emitent już wybrał jako delegata, ale odblokowuje on emisję — czyli właśnie to zadanie, które delegowanie miało trzymać za kluczami offline.

Zimny magazyn nie obejmuje kluczy delegata

Zdelegowane transakcje są podpisywane własnym kluczem głównym delegata, kluczem regularnym lub listą multi-signing. Emitent może przechowywać swoje główne poświadczenia całkowicie offline, a mimo to być narażony, jeśli delegat posiadający PaymentBurn zostanie skompromitowany, będzie źle skonfigurowany albo przekroczy swoje kompetencje.

Dla tokenu opartego na walucie fiducjarnej ryzyko ekonomiczne to jednostki w obiegu bez pokrycia w rezerwach. Atest rezerw pokazuje aktywa trzymane w stosunku do niewyemitowanych tokenów na dzień sprawozdawczy. Nie mówi nic o tym, które konta mogłyby zmienić tę liczbę między raportami — a to właśnie ta kontrola jest osłabiana przez ten błąd.

Delegowanie uruchomiono, zanim poprawka uzyskała poparcie

To drugi błąd wykryty w funkcji delegowania XRPL. Pierwotna wersja została wycofana w 2025 roku, gdy testujący ze społeczności odkrył na devnecie, że może ona naliczać opłaty transakcyjne kontom, które nie podpisały transakcji, a oficjalne ujawnienie potwierdza, że nigdy nie trafiła na Mainnet. Jej następca, PermissionDelegationV1_1, uruchomiono 8 października, według pulpitu poprawek XRPL, podczas gdy korekta PaymentBurn wciąż zbierała poparcie walidatorów.

Ekspozycja dotyczy zatem pojedynczych kont: dotknięci są wyłącznie emitenci, którzy przyznali PaymentBurn od momentu uruchomienia. Każde przyznanie jest jawne, ponieważ wpisy Delegate w księdze rejestrują konto przyznające, delegata oraz jego listę uprawnień. W chwili pisania tego tekstu ani dokumentacja XRPL, ani opublikowane doniesienia nie wskazują dotkniętego emitenta ani żadnego nadużycia.

Sam wzrost podaży niczego by nie udowodnił, ponieważ emitent mógł świadomie przyznać PaymentMint. Wyjaśnienia wymagałby delegat posiadający wyłącznie PaymentBurn, którego płatności dodawały tokeny.

Co emitenci mogą sprawdzić przed środą

Opublikowane zalecenie XRPL to zaprzestanie delegowania PaymentBurn do czasu włączenia poprawki. Dla emitentów, którzy już ją przyznali, prace przebiegają w tej kolejności:

1. Pobrać każdy wpis Delegate na koncie emitenta i oznaczyć każdą listę uprawnień zawierającą PaymentBurn.
2. Ponownie wysłać DelegateSet z pełną listą uprawnień do zachowania. Nowa lista zastępuje starą, więc wszystko, czego na niej zabraknie, zostaje usunięte.
3. Uznać przyznanie za cofnięte dopiero po pojawieniu się zmiany w zwalidowanej księdze.
4. Osobno przeprowadzić audyt przeszłych płatności delegata, ponieważ cofnięcie uprawnień blokuje przyszłe użycie, ale nie odwraca wcześniejszych transakcji.
5. Ponownie delegować PaymentBurn dopiero po tym, jak fixCleanup3_4_0 będzie widoczny jako włączony w Mainnecie.

Dlaczego głosowanie nadal może się opóźnić

Zgodnie z oficjalnymi zasadami poprawek, zmiana wymaga superwiększości zaufanych walidatorów utrzymanej przez dwa nieprzerwane tygodnie. Przy 35 walidatorach w śledzonym zbiorze próg wynosi 29, a jego przekroczenie w dół zeruje licznik. To resetowanie już raz nastąpiło; obecnie poparcie dla poprawki wynosi 33 z 35 zaufanych walidatorów.

Nawet przy zachowanym wsparciu godzina 14:46 UTC wyznacza otwarcie dwutygodniowego okna. Aktywacja następuje w punkcie głosowania księgi, więc zmiana może wejść w życie jakiś czas później.

Walidatorzy głosują także nad znacznie więcej niż ta jedna korekta. fixCleanup3_4_0 łączy 25 zmian dotyczących skarbców, pożyczek, automatycznych animatorów rynku, NFT, escrow i sponsoringu, a poprawka PaymentBurn jest ostatnią pozycją na liście. Łata kod pożyczkowy bez włączania samego Lending Protocol, który ma własną poprawkę wciąż otwartą pod głosowanie.

Dla emitentów liczy się potwierdzenie, że fixCleanup3_4_0 figuruje jako włączony w Mainnecie. Do tego czasu przyznanie PaymentBurn daje więcej uprawnień, niż wskazuje jego nazwa.

Ten artykuł pierwotnie ukazał się na Coindoo.