Deweloperzy XRP Ledger wydali awaryjną poprawkę bezpieczeństwa w odpowiedzi na krytyczny błąd, który mógł pozwolić złośliwym podmiotom na wygenerowanie dodatkowych, wydawalnych tokenów XRP — pomimo stałej podaży sieci wynoszącej 100 miliardów tokenów.

Poprawka ominęła standardowy dwutygodniowy proces głosowania walidatorów — decyzję tę deweloperzy uzasadniali tym, że czekanie dałoby potencjalnym atakującym czas na wykorzystanie słabości. Poprawka została wdrożona z natychmiastowym skutkiem trzy dni po zgłoszeniu błędu w ramach programu bug bounty sieci, który nagradza badaczy za odpowiedzialne ujawnianie luk w zabezpieczeniach, a deweloperzy powiedzieli, że było to pierwsze celowe ominięcie procesu nowelizacji od ponad dziesięciu lat.

Reakcja wywołała od tego czasu szeroką dyskusję na temat tego, jak XRP Ledger radzi sobie z sytuacjami krytycznymi, a także na temat jego zobowiązania do decentralizacji.

Awaryjna poprawka ominęła zatwierdzanie przez walidatorów

Nowelizacje protokołu w XRP Ledger zazwyczaj wymagają ponad 80% konsensusu wśród walidatorów w okresie dwóch tygodni, zanim zmiana wejdzie w życie — próg ten ma zapewnić, że zmiany zasad sieci cieszą się szeroką zgodą przed ich aktywacją. Deweloperzy zauważyli, że oczekiwanie na wynik głosowania nad poprawką bezpieczeństwa mogłoby pozostawić lukę otwartą na wykorzystanie.

Według wpisu na blogu opublikowanego w niedzielę przez deweloperów XRP Ledger normalny proces nowelizacji mógłby pozostawić poprawkę jawną przez kilka tygodni przed aktywacją nowelizacji, narażając tym samym sieć na niebezpieczeństwo.

Chociaż awaryjna poprawka zapewniła szybkie rozwiązanie problemu, decyzja o ominięciu regularnego procesu wzbudziła pytania o rolę, jaką zespoły deweloperskie odgrywają w reagowaniu na naruszenia bezpieczeństwa.

Fundacja wyjaśnia, że nie powstał żaden XRP

XRP Ledger Foundation przystąpiła do rozwiania nieporozumień po wprowadzeniu poprawki:

The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let's clear them up. 1. Was any XRP created? No. XRP's supply was fixed at 100 billion when the XRP Ledger launched, and transaction is allowed to create more. This bug was a way around… — XRP Ledger Foundation (@XRPLF) October 11, 2026

Poprawka wywołała debatę o decentralizacji

Awaryjna reakcja ponownie wywołała kontrowersje wokół kwestii, czy XRP Ledger jest zdecentralizowany — pytania, które było jednym z głównych tematów przy ustalaniu statusu prawnego XRP. Stopień kontroli, jaką zespół podstawowy sprawuje nad siecią, był powracającym czynnikiem, gdy regulatorzy rozważają, jak klasyfikować aktywo cyfrowe.

Justin Bons, współzałożyciel Cyber Capital, ostro skrytykował awaryjną aktualizację, argumentując, że mówienie o decentralizacji XRP jest wprowadzające w błąd:

Selling XRP to retail as "decentralized" is straight-up fraud! 🚩 XRP has been running closed-source code for the last two weeks Tomorrow, this code becomes mandatory & anyone who disagrees will get kicked off the chain! A permissioned node list means validators must obey: 🧵… pic.twitter.com/3nIcRiid8S — Justin Bons (@Justin_Bons) October 8, 2026

We wpisie Bons stwierdził, że sieć przez dwa tygodnie przed obowiązkową aktualizacją działała na kodzie zamkniętym oraz że uprawniona lista węzłów faktycznie wymuszała posłuszeństwo walidatorów.

Kolejnym zmartwieniem jest to, że dystrybucje binarne to pliki wykonywalne: w przypadku braku niezwłocznego udostępnienia kodu źródłowego niezależni deweloperzy mają ograniczony czas na analizę dokonanych zmian.

XRP Ledger Foundation wyjaśniła, że awaryjna poprawka została „wspólnie uzgodniona” przez Fundację, RippleX, deweloperów i walidatorów ze względu na powagę wykrytego w kodzie błędu. Podkreślono, że nikt nie narzucał procesu podejmowania decyzji, a operatorzy wciąż mogą korzystać z dowolnego oprogramowania.

Operator walidatora XRP Kuwait również poprzył proces awaryjnego łatkowania, stwierdzając, że współpraca nie oznacza centralizacji:

Our Statement on xrpld 3.4.1 At XRP Kuwait, our journey has always been about infrastructure and purpose. Our purpose is decentralization. We pursue that purpose through independently operated infrastructure and responsible participation in the XRP Ledger. Following the… pic.twitter.com/Oo7qClwpgi — XRPKuwait (@XRPKuwait) October 11, 2026

Kontrowersje ponownie podważyły kwestie przejrzystości i rozliczalności podczas awaryjnych poprawek.

Przepełnienie liczby całkowitej w silniku płatności

Usterka stojąca za awaryjną poprawką została szczegółowo opisana w ujawnieniu zespołu XRP Ledger. Według raportu o podatności problemem było przepełnienie liczby całkowitej w silniku płatności, obecne od 2015 roku. Przepełnienia liczby całkowitej to od dawna znana klasa błędów oprogramowania, w których obliczenie przekracza maksymalną wartość, jaką system może przechować, i „zawija się” do znacznie mniejszej liczby; w tym przypadku obliczenia powyżej stałego limitu maksymalnego dawały mniejsze wyniki.

Atakujący mógł wykorzystać błąd, wysyłając setki ofert z prośbą o ogromne ilości XRP w zamian. Po wadliwym obliczeniu atakujący otrzymałby te kwoty, podczas gdy kupujący zapłaciłby mniej niż wymagana kwota — co mogło skutować dodatkowym, wydawalnym XRP.

Ponieważ zasady sieci ustaliły całkowitą podaż XRP na 100 miliardów tokenów przy starcie, każda droga do wytworzenia dodatkowego, wydawalnego XRP podważyłaby podstawową gwarancję księgi — zasadę stałej podaży, na której opiera się rzadkość aktywa.

Atak wymagał specjalnie spreparowanych ofert i nie mógł nastąpić podczas zwykłego handlu. Poprawka została zaprojektowana tak, aby zapobiec wykorzystaniu błędu obliczeniowego do ominięcia zasad podaży sieci.

RippleX rozszerza działania w zakresie bezpieczeństwa

RippleX zamierza wzmocnić bezpieczeństwo XRP Ledger poprzez wykrywanie podatności z wykorzystaniem AI, testy adwersaryjne, weryfikację formalną oraz współpracę z zewnętrznymi ekspertami ds. bezpieczeństwa.

Cele tych działań obejmują znajdowanie błędów w kodzie, testowanie możliwych ataków i identyfikowanie podatności, zanim zostaną wykorzystane. RippleX określił te prace jako dążenie do zwiększenia bezpieczeństwa całego systemu kodu, a nie jedynie naprawiania wykrytych podatności.

Równowaga między bezpieczeństwem a przejrzystością

Awaryjna poprawka uwypukla wyzwanie, jakim jest utrzymanie bezpieczeństwa blockchain przy zachowaniu przejrzystości procesów decyzyjnych. Chociaż szybkie wdrożenie jest niezbędne do ochrony przed potencjalnymi atakami, rodzi kwestie dotyczące procesów zarządzania i dostępu do kodu źródłowego.

Deweloperzy utrzymywali, że podatność wymusiła pominięcie standardowej procedury, podczas gdy Fundacja twierdziła, że koordynacja między zaangażowanymi stronami nie wpłynęła na niezależność walidatorów.

Zdarzenie podkreśla potrzebę opracowania protokołów awaryjnych, które pogodzą szybką reakcję z otwartością sieci.

Źródło: Tron Weekly