Dziesięcioletni błąd mógł wygenerować miliardy dodatkowych XRP

iEXExchanger
Dziesięcioletni błąd mógł wygenerować miliardy dodatkowych XRP

Deweloperzy XRP Ledger w trybie awaryjnym załatali błąd, który tkwił w kodzie prawie dekadę i teoretycznie pozwalał tworzyć tokeny powyżej limitu 100 mld monet. Nie znaleziono dowodów na realny atak.

XRP od zawsze sprzedawano w oparciu o jedną prostą obietnicę: sztywną, stałą emisję 100 mld monet, wykopanych jednorazowo w 2012 roku, bez wydobycia i bez stopniowej inflacji. Przez ponad dekadę ta liczba była głównym argumentem przeciwko powolnej emisji bitcoina. Okazuje się, że ten limit cały czas opierał się na arytmetyce, której nikt na serio nie próbował złamać.

Błąd tkwił w kodzie rozliczania ofert silnika płatności od 2015 roku. Gdy jedna płatność jednorazowo pochłaniała dużą partię ofert z wbudowanej giełdy XRP Ledger, kwota do zapłaty była liczona jako 64-bitowa liczba całkowita. Wystarczyło zebrać dość ofert z absurdalną ceną, by ta suma się przepełniła i "zawinęła" do znacznie mniejszej liczby — sprzedający otrzymywali pełną zapłatę, a kupujący płacił praktycznie nic. Różnica między tymi kwotami była w praktyce nowymi XRP, które nigdy wcześniej nie istniały.

Wykorzystanie tego byłoby prawie darmowe: według RippleX atakujący potrzebowałby jedynie kilkuset XRP jako rezerw rozłożonych na kilka kont, plus zwykłe opłaty transakcyjne.

Błąd wykrył nie wewnętrzny audyt, a badacz Cayden Liao wraz z zespołem Veria AI — zgłosili go 22 września w ramach programu bug bounty XRPL. Dalej wszystko potoczyło się nietypowo szybko dla zdecentralizowanej sieci: RippleX potwierdziła krytyczność w ciągu doby, a łatka xrpld 3.4.1 trafiła do sieci 25 września, pomijając zwykłe głosowanie w sprawie poprawki protokołu, które normalnie wymaga zgody ponad 80% zaufanych walidatorów przez dwa tygodnie z rzędu. Dla sieci, która chwali się rozproszonym zarządzaniem, był to wyjątek celowy: zamknięcie okna ryzyka było ważniejsze niż czekanie na standardową procedurę.

Problem upubliczniono dopiero 9 października, dwa tygodnie po faktycznej naprawie. XRPL Operations oświadczyła, że nie znaleziono dowodów na wykorzystanie błędu w publicznej sieci, choć z zewnątrz trudno to zweryfikować — udany atak wyglądałby po prostu jak duża, zupełnie zwyczajna płatność.

To nie jest historia o jednym incydencie. To przypomnienie, że nawet dojrzały, ponad dziesięcioletni blockchain, sprzedawany na idei stałej i przewidywalnej emisji, może kryć arytmetykę, której nikt naprawdę nie próbował złamać, zanim nie zrobił tego łowca nagród. Stały limit jest tak solidny, jak kod, którego jeszcze nikt nie doprowadził do granicy.

Pytania i odpowiedzi

Często zadawane pytania na temat artykułu

Na czym polegała dokładnie podatność XRP Ledger?

Błąd w kodzie silnika płatności przy odpowiednich warunkach pozwalał na przepełnienie 64-bitowej liczby używanej do obliczenia kwoty transakcji, dzięki czemu sprzedający otrzymywał pełną zapłatę, a kupujący prawie nic — różnica stawała się nowymi, nieujętymi nigdzie XRP.

Kto znalazł błąd i jak?

Niezależny badacz Cayden Liao wraz z zespołem Veria AI znalazł podatność i zgłosił ją 22 września 2026 roku w ramach programu bug bounty XRPL, który płaci zewnętrznym badaczom za wykrycie krytycznych błędów.

Czy ktoś realnie poniósł szkody?

XRPL Operations oświadczyła, że nie znaleziono dowodów na wykorzystanie błędu w publicznej sieci. Trudno to jednak zweryfikować niezależnie, bo udany atak wyglądałby po prostu jak duża, skądinąd zwyczajna płatność.

Czemu łatkę wydano bez zwykłego głosowania walidatorów?

Standardowa zmiana protokołu XRP Ledger wymaga zgody ponad 80% zaufanych walidatorów przez dwa tygodnie z rzędu. Z uwagi na krytyczność błędu deweloperzy wydali xrpld 3.4.1 w trybie awaryjnym, by jak najszybciej zamknąć okno ryzyka, nie czekając na pełną procedurę głosowania.