Przegląd
Krytyczna luka w XRP Ledger, która pozostawała w silniku płatności przez około dekadę, mogła teoretycznie pozwolić atakującemu na tworzenie wydawalnych XRP poza zamierzonymi zasadami podaży księgi. XRPL ujawniło problem 9 października 2026 r., po tym jak został on prywatnie zgłoszony przez Program Bug Bounty XRPL 22 września. Luka dotyczyła xrpld 3.4.0 i wcześniejszych wersji i została naprawiona w xrpld 3.4.1, wydanej 25 września.
Luka w XRP Ledger polegała na przepełnieniu liczby całkowitej, gdy płatność zużywała setki specjalnie skonstruowanych ofert księgi zleceń. Indywidualni właściciele ofert mogli otrzymać pełne kwoty XRP, podczas gdy nabywca został obciążony jedynie niewielką, zawiniętą sumą. Co poważniejsze, istniejący w księdze niezmiennik „nie tworzy się XRP” wykorzystywał podobną ścieżkę arytmetyczną i mógł przepełnić się w ten sam sposób, uniemożliwiając tej kontroli bezpieczeństwa wykrycie rozbieżności.
XRPL twierdzi, że nie znalazło dowodów na wykorzystanie luki w jakiejkolwiek sieci publicznej, a normalne płatności nie mogły przypadkowo jej wywołać. Atak wymagał celowo zaprojektowanych ofert o ekonomicznie nierealistycznych cenach. Mimo to incydent rodzi głębsze pytanie o bezpieczeństwo: stała polityka monetarna blockchaina jest tak silna, jak oprogramowanie egzekwujące każdą zmianę salda.
Najważniejsze wnioski
- Błąd wydaje się istnieć od czasu napisania obecnego silnika płatności XRPL w 2015 r.
- Celowo skonstruowana transakcja mogła teoretycznie utworzyć wydawalne XRP.
- XRPL nie znalazło dowodów na wykorzystanie w sieci publicznej.
- Istniejący niezmiennik podaży mógł zawieść, ponieważ odtwarzał to samo zachowanie przepełnienia.
xrpld 3.4.1dodał arytmetykę z kontrolą i silniejszą, niezależną kontrolę podaży.
Czym była luka w XRP Ledger?
Luka tkwiła w sposobie, w jaki silnik płatności XRP Ledger obsługiwał płynność księgi zleceń. Gdy płatność przechodzi przez wiele ofert, silnik musi obliczyć, ile XRP płatnik jest winien łącznie. Każda pojedyncza kwota mogła być prawidłowa, ale obliczenie sumy wykorzystywało 64-bitową liczbę całkowitą bez wystarczającej ochrony przed przepełnieniem.
W zwykłych warunkach było to praktycznie nieosiągalne. Normalna podaż XRP i rzeczywiste ceny rynkowe nie zbliżają się nawet odlegle do granicy numerycznej wymaganej do przepełnienia licznika. Problem pojawiał się tylko wtedy, gdy atakujący celowo skonstruował setki ofert, w których każde konto żądało ekstremalnie dużej ilości XRP za maleńką ilość innego tokena.
Złośliwy przepływ mógł wyglądać mniej więcej tak:
- Utwórz kilkaset kontrolowanych kont.
- Złóż z tych kont celowo nierealistyczne oferty.
- Skonstruuj jedną płatność zaprojektowaną tak, aby zużyła te oferty razem.
- Wypchnij sumę obliczeń XRP poza limit liczby całkowitej.
- Spowoduj, że suma zawinie się do znacznie mniejszej liczby.
Silnik mógł następnie indywidualnie uznać należność właścicielom ofert, obciążając nabywcę jedynie zawiniętą sumą. Ponieważ atakujący mógł kontrolować również konta właścicieli ofert, różnica skutecznie stawała się nowymi XRP.
Inżynierowie XRPL odtworzyli atak lokalnie i potwierdzili, że powstałe XRP mogły następnie zostać przeniesione. W związku z tym problem został podniesiony z poziomu Major do krytycznej wagi.
Czy luka w XRP Ledger naprawdę mogła tworzyć XRP?
Tak, teoretycznie. To nie był jedynie błąd w wyświetlaniu księgowym. Ujawnienie techniczne XRPL mówi, że exploit mógł utworzyć XRP, które zachowywałyby się jak zwykłe XRP po zatwierdzeniu złośliwej transakcji. Te salda mogłyby zostać przeniesione, wymienione lub wysłane na giełdy.
Nie oznacza to, że XRP zostało historycznie nadmiernie wyemitowane. XRPL podaje, że nie znalazło żadnych dowodów, że exploit wystąpił w jakiejkolwiek sieci publicznej. Różnica między tymi dwoma stwierdzeniami jest istotna: luka mogła naruszyć zamierzone ograniczenie podaży, ale obecnie nie ma potwierdzonego historycznego zdarzenia dotyczącego podaży z nią związanego.
Atak nie mógł również wystąpić przypadkowo podczas normalnego handlu na DEX. Oferty w księdze zleceń musiały być wycenione tak nierealistycznie, że normalna płynność rynkowa zostałaby wykonana przed ich osiągnięciem. Płatność musiała być również celowo skonstruowana, aby zużyć wystarczająco dużo z tych ofert razem, by wywołać przepełnienie.
Należy to zatem rozumieć przede wszystkim jako ścieżkę wykonania o niskim prawdopodobieństwie i ekstremalnie wysokim teoretycznym wpływie, a nie jako błąd, który zwykli użytkownicy XRP mogliby nieświadomie wywołać.
Dlaczego kontrola bezpieczeństwa podaży XRPL zawiodła?
Najważniejszą technicznie częścią incydentu nie jest samo istnienie przepełnienia liczby całkowitej. Dojrzałe oprogramowanie finansowe często zawiera wiele warstw obronnych zaprojektowanych specjalnie do wychwytywania właśnie tego rodzaju nieoczekiwanego wyniku.
XRPL miał jedną: niezmiennik transakcji mający na celu zapewnienie, że transakcja nie może tworzyć XRP. W zasadzie, nawet gdyby silnik płatności popełnił błąd księgowy, niezmiennik powinien zauważyć, że całkowite salda XRP wzrosły, i odrzucić transakcję.
Nie zrobił tego.
Powodem jest klasyczne niepowodzenie rzekomo niezależnych systemów bezpieczeństwa. Niezmiennik obliczał zmiany netto XRP przy użyciu podobnego typu niesprawdzonej arytmetyki. Gdy silnik płatności uległ przepełnieniu, obliczenie niezmiennika mogło ulec przepełnieniu w tym samym kierunku, sprawiając, że wynikowa transakcja wydawała się zmieniać podaż XRP jedynie o zwykłą opłatę transakcyjną.
Kontrola bezpieczeństwa nie jest naprawdę niezależna, gdy może odtworzyć ten sam tryb awarii co system, który sprawdza.
Druga ochrona sprawdzała, czy saldo pojedynczego konta przekracza całkowitą podaż XRP. To również nie powstrzymało ataku, ponieważ nowo utworzone XRP mogło zostać rozdzielone na setki kont, utrzymując saldo każdego pojedynczego konta poniżej limitu.
Środek naprawczy dotyczył zatem zarówno bezpośredniego błędu, jak i architektury obronnej. xrpld 3.4.1 dodał jawne kontrole przepełnienia, gdy kwoty są agregowane w ofertach i ścieżkach płatności. XRPL zmienił również niezmiennik braku utworzenia XRP, aby używać szerszego licznika, który nie może się zawinąć w tych samych warunkach.
Dlaczego błąd z 2015 roku pozostał ukryty tak długo?
Odpowiedź leży częściowo w różnicy między realistycznymi wartościami ekonomicznymi a teoretycznymi limitami komputerów. Pojedyncze płatności XRP działają o wiele rzędów wielkości poniżej zakresu wymaganego do przepełnienia sumy 64-bitowej. Normalny trader mógłby używać XRPL przez lata, nie tworząc niczego przypominającego złośliwe warunki numeryczne.
To sprawiło, że wada była trudna do ujawnienia poprzez rutynowe użytkowanie. Podatna logika mogła działać poprawnie w miliardach normalnych operacji, a jednocześnie katastrofalnie zawodzić na sztucznej granicy.
Luka ta pokazuje również, dlaczego długowieczny kod blockchain nie powinien być automatycznie uważany za bezpieczny tylko dlatego, że działał przez wiele lat. Historia produkcyjna jest użytecznym dowodem, ale testuje głównie typowe stany. Atakujący celowo szukają stanów, których normalni użytkownicy nigdy nie tworzą.
XRPL przypisał swojemu Programowi Bug Bounty znalezienie tego problemu i przedstawił szersze podejście obrony w głąb, które obejmuje niezależne audyty, publiczne attackathony, fuzzing, czerwone zespoły wspomagane sztuczną inteligencją i weryfikację formalną. Dodaje również ponowną weryfikację poprawek bezpieczeństwa względem kandydatów do wydania, zanim ustalenia zostaną formalnie zamknięte.
To podejście ma znaczenie, ponieważ lekcja z tego incydentu nie polega na tym, że dojrzały kod nie może być zaufany. Polega na tym, że dojrzały kod nadal wymaga testowania adversatywnego względem założeń, które deweloperzy przestali kwestionować lata wcześniej.
Co ten błąd oznacza dla stałej podaży XRP?
XRP rozpoczęło się od zdefiniowanej początkowej podaży 100 miliardów tokenów, bez mechanizmu protokołu analogicznego do kopania proof-of-work, który stale tworzy dodatkowe XRP. Opłaty transakcyjne są niszczone, a nie wypłacane walidatorom, więc zamierzona ścieżka podaży jest nieinflacyjna.
Luka w XRP Ledger ujawnia ważne rozróżnienie między polityką monetarną jako regułą a polityką monetarną jako egzekwowaniem przez oprogramowanie.
Specyfikacja blockchain może stwierdzać, że nowe XRP nie mogą być tworzone, ale węzły ostatecznie egzekwują tę właściwość poprzez kod. Jeśli logiką przejść salda można manipulować tak, aby naruszyć regułę, wówczas sama polityka ekonomiczna może zawieść, nawet jeśli udokumentowana polityka się nie zmieniła.
Ten incydent nie wykazał, że rzeczywista podaż w obiegu XRP została potajemnie zwiększona. XRPL twierdzi, że nie znaleziono wykorzystania w publicznej sieci. Wykazał jednak, że przed poprawką istniała teoretyczna ścieżka wykonania zdolna obejść jedno z najbardziej fundamentalnych ograniczeń monetarnych księgi.
To czyni tę lukę bardziej istotną niż tymczasowa awaria RPC lub problem z łącznością węzłów. Sieć może tolerować pewne zakłócenia infrastruktury bez naruszania integralności aktywów. Błąd zdolny generować jednostki do wydania dotyka samego fundamentu księgowego księgi.
Dlaczego poprawka ma większe znaczenie niż brak wykorzystania luki
Kuszące jest zlekceważenie luki, gdy śledczy twierdzą, że nigdy nie została wykorzystana. To jednak pomija bardziej użyteczną lekcję bezpieczeństwa.
Oś czasu reakcji XRPL była stosunkowo skompresowana: problem został zgłoszony i odtworzony 22 września, poprawka została opracowana i przejrzana w dniach 22–23 września, scalona do gałęzi wydania 3.4.1 i wydana 25 września. XRPL poinformował, że ponad 80% domyślnych walidatorów Unique Node List uruchamiało chronioną wersję tego samego dnia.
Poprawka silnika płatności również weszła w życie bezpośrednio wraz z aktualizacją oprogramowania, zamiast czekać na normalny proces aktywacji poprawek. Było to możliwe, ponieważ odrzucanie przepełnienia arytmetycznego zostało potraktowane jako naprawa niezdefiniowanego lub niebezpiecznego zachowania, a nie wprowadzenie nowej zamierzonej reguły transakcyjnej.
W przypadku bezpieczeństwa blockchaina czas ujawnienia informacji jest częścią obrony. Opublikowanie exploita, zanim walidatory zostały zabezpieczone, zamieniłoby teoretyczną podatność w instrukcję operacyjną dla atakujących. Dlatego XRPL ujawnił szczegóły techniczne dopiero po tym, jak załatana wersja została już rozpowszechniona.
Ryzyka i ograniczenia
Incydent jest poważny, ale kilka granic powinno pozostać jasnych.
- Brak potwierdzonego zdarzenia inflacyjnego: XRPL twierdzi, że nie znalazł dowodów na wykorzystanie luki w publicznej sieci.
- Brak przypadkowego wyzwolenia: normalne płatności i realistyczne arkusze zleceń nie osiągają wymaganych wartości.
- Adopcja poprawki ma znaczenie: od operatorów serwerów oczekuje się uruchamiania
xrpld 3.4.1lub nowszego. - Jedna poprawka nie dowodzi pełnego bezpieczeństwa: inne stare założenia arytmetyczne wciąż wymagają testowania w warunkach adversarialnych.
- Historyczny brak nadużyć nie może zastąpić formalnej weryfikacji: niektóre klasy błędów są zbyt nietypowe, aby ujawnić się poprzez normalną aktywność sieciową.
Innym ograniczeniem jest retrospektywna pewność. Śledczy mogą analizować historię księgi i znane wzorce exploitów, ale udowodnienie, że podatność nigdy nie została wykorzystana, z natury różni się od matematycznego dowodu, że nie mogła zostać wykorzystana. Oficjalny wniosek jest zatem odpowiednio sformułowany jako brak znalezionych dowodów, a nie absolutne twierdzenie o każdym historycznym stanie.
Perspektywa MEXC: Stała podaż jest właściwością bezpieczeństwa oprogramowania
Polityka monetarna blockchaina nie jest zabezpieczona wyłącznie liczbą podaży zapisaną w dokumentacji. Jest zabezpieczona przez oprogramowanie, które waliduje każdą zmianę salda, ścieżkę transakcji i stan księgi.
Incydent z XRPL ilustruje, dlaczego to rozróżnienie ma znaczenie. Zamierzona reguła protokołu zabraniała tworzenia nowych XRP, a jednak wada w arytmetyce mogła teoretycznie naruszyć tę regułę. Co ważniejsze, defensywny invariant zaprojektowany do wychwytywania tworzenia podaży początkowo dzielił ten sam tryb awarii.
Dla dojrzałych sieci blockchain bezpieczeństwo musi zatem wyjść poza testowanie, czy normalne transakcje zachowują się poprawnie. Niezależne invariants, fuzzing, adversarialne testowanie granic i metody formalne stają się coraz ważniejsze właśnie dlatego, że najbardziej szkodliwe podatności mogą istnieć w ścieżkach kodu, których zwykli użytkownicy nigdy nie dotykają.
Wskaźnikiem wartym obserwacji po tym ujawnieniu nie jest reakcja ceny XRP. Jest nim to, czy rozszerzone procesy weryfikacji XRPL konsekwentnie znajdują i izolują podobne klasy ukrytego ryzyka protokołu, zanim zrobią to atakujący.
Dziesięcioletni błąd był krytyczny, ale nie jest udowodnionym zdarzeniem inflacji XRP
Podatność XRP Ledger zasługuje na określenie „krytyczna”, ponieważ teoretycznie mogła podważyć jedną z najbardziej fundamentalnych gwarancji XRPL. Starannie zaprojektowana płatność mogła wymusić 64-bitowe przepełnienie arytmetyczne, zapisać setkom właścicieli ofert XRP i obciążyć kupującego tylko ułamkiem łącznej kwoty. Nowo utworzone salda były możliwe do wydania w odtworzeniu ataku przez XRPL.
Ale druga połowa historii jest równie ważna. XRPL nie znalazł żadnych dowodów na wykorzystanie w publicznej sieci, transakcja wymagała celowo nienormalnych warunków arkusza zleceń, a podatność została załatana w xrpld 3.4.1 przed publicznym ujawnieniem szczegółów technicznych.
Incydent nie powinien więc być przepisywany jako dowód, że podaż XRP była historycznie zawyżona. Jego znaczenie jest bardziej strukturalne. Pokazuje, że nawet blockchain o stałej podaży ostatecznie zależy od oprogramowania, które poprawnie egzekwuje ograniczenia monetarne w przypadkach brzegowych, które mogą pozostać niewidoczne przez lata.
Najsilniejszy wniosek z tej podatności XRP Ledger dotyczy zatem inżynierii protokołu, a nie nagłówków o podaży tokena. Invariants monetarne wymagają niezależnej implementacji, stary kod wciąż wymaga adversarialnego przeglądu, a pomyślne działanie sieci przez dekadę nie eliminuje możliwości ukrytych awarii warunków brzegowych. Błąd nie dowiódł, że XRP zostało nadmiernie wyemitowane; dowiódł, dlaczego integralność podaży musi być stale weryfikowana.
Źródła
Oficjalne ujawnienie podatności XRPL:
https://xrpl.org/es-es/blog/2026/vulnerabilitydisclosurereport-bug-20261009
Informacje o wydaniu XRPL 3.4.1:
https://xrpl.org/blog
Chcesz najszybciej otrzymywać najnowsze informacje o MEXC? Dołącz do naszej oficjalnej grupy na Telegramie już teraz!
Platforma MEXC: Pobierz aplikację | Handel bez opłat | Kup USDT teraz Dołącz do społeczności MEXC: X (Twitter) | Telegram | Discord
Uzyskaj informacje: Akademia dla początkujących | Warunki świadczenia usług | MEXC Blog | MEXC News
Weryfikacja konta: Dowiedz się o KYC | Jak przeprowadzić KYC
Ostrzeżenie o ryzyku: Treść tego artykułu ma charakter wyłącznie informacyjny i nie stanowi żadnej porady inwestycyjnej. Rynek walut cyfrowych charakteryzuje się dużą zmiennością, podejmuj decyzje ostrożnie, biorąc pod uwagę własną sytuację.
