Konkurs audytu społecznościowego o wartości 550 000 dolarów ujawnił dwie krytyczne luki w funkcjach XRP Ledger, które mogły opróżnić konta użytkowników bez kluczy prywatnych. Ustalenia pokazują, jak model Ripple oparty na audycie przed wydaniem znacznie odbiega od powszechnej w branży kryptowalut normy „łat po eksploatacji”.
Podsumowanie
- Dwutygodniowy konkurs audytu Sherlocka, który rozpoczął się 13 kwietnia 2026 r., wykrył 96 ważnych luk w pięciu proponowanych poprawkach XRP Ledger, w tym 2 krytyczne i 6 o wysokim stopniu zagrożenia, zanim którakolwiek z nich trafiła do mainnetu.
- Ripple wypłacił 309 000 dolarów w nagrodach RLUSD z puli 550 000 dolarów, co stanowi pierwszą współpracę między Sherlockiem a Ripple i jeden z największych konkursów audytowych w 2026 r.
- Najpoważniejsze ustalenie dotyczyło wady walidacji podpisu w poprawce Batch, która umożliwiłaby atakującym wykonanie transakcji z dowolnego konta bez posiadania jego kluczy prywatnych; po raz pierwszy zidentyfikowana 19 lutego 2026 r. przez badacza Pranamya Keshkamat i narzędzie AI Cantiny Apex.
- Osobny krytyczny błąd w delegowaniu uprawnień pozwalał złośliwym podmiotom na ciche opróżnianie sald XRP poprzez wielokrotne opłaty za nieprawidłowe delegowane transakcje, ponieważ kod sprawdzał uprawnienia przed weryfikacją podpisów.
- Exploity DeFi przekroczyły 840 milionów dolarów w ponad 50 incydentach w ciągu pierwszych pięciu miesięcy 2026 r., co oznacza wzrost o 70% rok do roku, a 70% wykorzystanych kontraktów było audytowanych, ale brakowało im monitorowania po wdrożeniu.
XRP Ledger w wersji 3.3.0 został wydany 6 sierpnia 2026 r. i zawierał pięć proponowanych poprawek oraz pakiet poprawek porządkujących. Na papierze wyglądało to na rutynowe wydanie infrastrukturalne. W rzeczywistości aktualizacja stanowiła zakończenie sześciomiesięcznego toru przeszkód bezpieczeństwa, który wykrył dwa błędy opróżniające konta, przepisał od podstaw dwie całe implementacje funkcji i wypłacił setki tysięcy dolarów zewnętrznym badaczom, którzy znaleźli problemy, których wewnętrzny zespół nie zauważył. Proces ten rodzi zasadnicze pytanie dla szerszego przemysłu blockchain: skoro Ripple potrafi wykryć krytyczne wady przed wdrożeniem, dlaczego tak duża część kryptowalut nadal traktuje audyty bezpieczeństwa jako pole do odhaczenia po uruchomieniu?
Ten artykuł rozkłada na czynniki pierwsze, czym były te dwie krytyczne luki na poziomie technicznym, analizuje, jak potok audyt-głosowanie-aktywacja wypada w porównaniu z modelami bezpieczeństwa konkurencyjnych łańcuchów, oraz ocenia, czy ustalenia wzmacniają, czy osłabiają argument za XRPL jako infrastrukturą klasy instytucjonalnej.
Co faktycznie znalazł konkurs Sherlocka
Zakres obejmował pięć filarów nadchodzącej funkcjonalności XRPL: transakcje wsadowe, delegowanie uprawnień, integrację DEX dla tokenów wielofunkcyjnych (MPT), poufne transfery dla MPT oraz opłaty i rezerwy sponsorowane. Sherlock, firma z branży bezpieczeństwa Web3, która rankuje badaczy według wyników i organizuje zaangażowania jako konkursy adversarialne, otworzył audyt 13 kwietnia 2026 r. z pulą nagród 550 000 dolarów w RLUSD. Strona konkursu na platformie Sherlocka wymieniała zaangażowanie jako „XRP Ledger – April 2026 Contest – 550,000 RLUSD”, co sygnalizowało, że Ripple płacił nagrody w swoim własnym stablecoinie.
W ciągu dwóch tygodni uczestnicy zgłosili 96 ważnych ustaleń: 2 krytyczne, 6 wysokich, 29 średnich i 59 o niskim stopniu zagrożenia. Ripple rozdzielił 309 000 dolarów w RLUSD wśród współpracowników. Pozostała pula pokryła koszty operacyjne Sherlocka i ustalenia niższego poziomu, które nie spełniły progu wypłat.
Konkurs był pierwszą formalną współpracą między Sherlockiem a Ripple i odbył się w momencie, gdy potok funkcji XRP Ledger rozwijał się szybciej niż kiedykolwiek w historii. Pięć poprawek wydanych jednocześnie oznaczało pięć odrębnych powierzchni ataku, każda z własną logiką transakcji, modelem autoryzacji i wymaganiami kryptograficznymi. Dla kontekstu, model konkursów audytowych Sherlocka był wcześniej używany przez protokoły takie jak Aave, Euler i Olympus DAO, ale zaangażowanie obejmujące kod na poziomie protokołu w C++ dla blockchaina warstwy pierwszej było nietypowe dla platformy częściej kojarzonej z inteligentnymi kontraktami Solidity.
Sam rozkład dotkliwości opowiada historię. 29 ustaleń o średnim stopniu zagrożenia sugeruje kategorię błędów, które nie naruszyłyby indywidualnie kont, ale mogłyby powodować nieoczekiwane zachowanie w określonych sekwencjach transakcji. 59 ustaleń o niskim stopniu zagrożenia prawdopodobnie obejmuje problemy z jakością kodu, luki w dokumentacji i przypadki brzegowe, które mogłyby się kumulować w warunkach adversarialnych. Jednak dwa krytyczne i sześć błędów o wysokim stopniu zagrożenia stanowiły luki możliwe do wykorzystania, które wymagały natychmiastowej naprawy.
Błąd w poprawce Batch, który mógł opróżnić konta
Najniebezpieczniejsza luka pojawiła się dwa miesiące przed konkursem Sherlock. 19 lutego 2026 roku badacz bezpieczeństwa Pranamya Keshkamat oraz autonomiczne narzędzie AI do audytu Cantina, Apex, niezależnie zidentyfikowali wadę walidacji podpisów w oryginalnej poprawce Batch, gdy ta była jeszcze w fazie głosowania walidatorów.
Usterka techniczna była precyzyjna. Transakcje Batch pozwalają na atomowe wykonanie do ośmiu operacji w ramach jednej transakcji zewnętrznej. Kod walidacji podpisu transakcji zewnętrznej zawierał warunek wcześniejszego wyjścia, który mógł zostać spełniony bez właściwego zweryfikowania, kto autoryzuje transakcje wewnętrzne. W praktyce atakujący mógł skonstruować transakcję Batch zawierającą wewnętrzne operacje Payment skierowane na konto ofiary, opróżniając je do salda rezerwowego, bez posiadania kluczy prywatnych tego konta. Ta sama luka logiczna umożliwiłaby nieautoryzowane operacje AccountSet, TrustSet lub AccountDelete.
Raport o ujawnieniu luki opublikowany na xrpl.org szczegółowo opisywał mechanizm: sprawdzenie podpisującego w transakcji zewnętrznej mogło przejść bez potwierdzenia, że podmiot przesyłający transakcję Batch faktycznie kontrolował konta, do których odnosiły się transakcje wewnętrzne. Oznaczało to, że funkcja atomowości zaprojektowana w celu poprawy doświadczeń użytkownika mogła zostać wykorzystana do opróżnienia dowolnego konta w sieci w jednej transakcji.
RippleX odpowiedział awaryjną wersją. Rippled w wersji 3.1.1, opublikowany 23 lutego 2026 roku, cztery dni po odkryciu, oznaczył zarówno oryginalną poprawkę Batch, jak i jej towarzyszącą poprawkę fixBatchInnerSigs jako nieobsługiwane, uniemożliwiając walidatorom głosowanie nad nimi lub ich aktywację. Żadne środki nie zostały utracone, ponieważ poprawka nie przekroczyła jeszcze progu 80% walidatorów wymaganego do aktywacji. Zastępca, BatchV1_1, został dostarczony w wersji 3.3.0 z usuniętym warunkiem wcześniejszego wyjścia, dodanymi dodatkowymi zabezpieczeniami autoryzacji oraz zaostrzonym zakresem sprawdzania podpisów, aby niezależnie weryfikować każdą transakcję wewnętrzną względem właściwego podpisującego.
Cichy exploit drenażu opłat w Permission Delegation
Druga krytyczna luka działała poprzez subtelniejszy mechanizm. Ujawnienie z września 2025 roku dokumentowało, jak oryginalna implementacja Permission Delegation pozwalała atakującemu na ciche uszczuplanie salda XRP ofiary bez dostępu do jej kluczy.
Exploit opierał się na funkcji projektowej przetwarzania transakcji w XRP Ledger, która istnieje od najwcześniejszych dni sieci. W XRPL transakcja, która kończy się błędem klasy „tec”, nadal podlega opłacie, podczas gdy błędy wykryte wcześniej w potoku, przed weryfikacją podpisu, nie. To rozróżnienie istnieje, ponieważ błędy klasy tec oznaczają transakcje, które były poprawnie sformułowane i podpisane, ale nie powiodły się z powodów logiki biznesowej, a opłata zapobiega spamowi. Oryginalny kod Permission Delegation sprawdzał, czy konto delegowane posiada odpowiednie uprawnienia, zanim zweryfikował podpis transakcji. Atakujący mógł wielokrotnie przesyłać nieprawidłowe transakcje podpisane offline z podwyższonymi opłatami przeciwko kontu delegowanemu, a każda nieudana transakcja nadal potrącała opłatę z salda ofiary.
Wpływ ekonomiczny szybko by się kumulował. Ponieważ atakujący mógł ustawić arbitralnie wysokie opłaty na tych transakcjach, ciągły atak mógł opróżnić konto znacznie szybciej, niż sugerowałyby normalne opłaty transakcyjne. Ofiara widziałaby spadek swojego salda bez odpowiadających płatności wychodzących, co utrudniało zdiagnozowanie ataku bez analizy surowych metadanych transakcji.
Poprawka przeklasyfikowała odpowiedni błąd z tec na ter i zmieniła kolejność sprawdzeń, tak aby żadna opłata nie mogła zostać potrącona przed przejściem weryfikacji podpisu. Zastępcza poprawka, PermissionDelegationV1_1, ma domyślne oznaczenie „Nie” w rejestrze 3.3.0, co oznacza, że walidatorzy muszą aktywnie głosować za jej włączeniem. Ten konserwatywny domyślny wybór odzwierciedla wrażliwość oryginalnej wady: nawet po przepisaniu Ripple zdecydował się wymagać wyraźnej zgody walidatorów na tę funkcję.
Dlaczego obie przepisane poprawki trafiły do jednego wydania
Pakowanie dwóch poprawek po przepisaniu pod kątem bezpieczeństwa wraz z trzema całkowicie nowymi funkcjami w jednej wersji było celowym wyborem. RippleX opublikował xrpld 3.3.0 6 sierpnia 2026 roku, z kodem dla wszystkich sześciu propozycji (w tym dołączonej poprawki porządkującej o nazwie fixCleanup3_3_0), ale żadna z nich nie została aktywowana. Zgodnie z procesem poprawek XRP Ledger, każda propozycja musi utrzymać ponad 80% wsparcia walidatorów przez dwa kolejne tygodnie, zanim wejdzie w życie.
To rozdzielenie dostępności kodu od aktywacji funkcji jest strukturalną przewagą, której brakuje większości platform inteligentnych kontraktów. Na Ethereum wdrożony kontrakt jest aktywny w momencie trafienia do blockchaina. Na XRPL kod może zostać opublikowany, przejść dalszą weryfikację w oknie głosowania i nadal zostać zablokowany, jeśli walidatorzy stracą zaufanie. Przepisane poprawki Batch i Permission Delegation przetrwały już konkurs Sherlock, ponowny audyt Halborn, który nie wykazał żadnych krytycznych ani wysokich zagrożeń, oraz miesiące testów wewnętrznych. Okres głosowania dodaje kolejną warstwę ochrony, zanim jakikolwiek kod dotknie prawdziwych środków.
Wersja wycofała również pięć starszych poprawek, w tym Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve i fixUniversalNumber, usuwając martwe ścieżki kodu, które mogłyby z czasem gromadzić się jako ukryta powierzchnia ataku.
Pięć poprawek funkcjonalnych w wersji 3.3.0 stanowi najszerszą pojedynczą ekspansję możliwości XRPL do tej pory. Poufne transfery wprowadzają szyfrowanie EC-ElGamal i dowody wiedzy zerowej do tokenów wielofunkcyjnych, chroniąc indywidualne salda i kwoty transferów przed publicznym widokiem, jednocześnie zachowując dostęp zgodności dla upoważnionych stron. Opłaty sponsorowane pozwalają aplikacjom pokrywać koszty sieciowe w imieniu użytkowników, rozwiązując problem tarcia przy wdrażaniu, który trzymał aplikacje skierowane do konsumentów z dala od zdecentralizowanych sieci. DynamicMPT umożliwia emitentom modyfikację właściwości tokenów po ich utworzeniu, wspierając ewoluujące wymagania regulacyjne i biznesowe. Wraz z przepisanymi poprawkami Batch i Permission Delegation, te funkcje są skierowane do konkretnej grupy odbiorców: regulowanych instytucji finansowych, które potrzebują prywatności, atomowego rozliczania i delegowanych operacji bez poświęcania możliwości audytu.
Audyt przed wydaniem a łatka po wykorzystaniu luki
Kontrast między podejściem Ripple a szerszymi osiągnięciami branży w zakresie bezpieczeństwa jest uderzający. Wykorzystanie luk w DeFi przekroczyło 840 milionów dolarów w ponad 50 incydentach w pierwszych pięciu miesiącach 2026 roku, co stanowi 70% wzrost rok do roku w porównaniu z tym samym okresem w 2025 roku. Podmioty powiązane z Koreą Północną odpowiadały za 76% globalnych strat z tytułu hacków kryptowalutowych w pierwszych czterech miesiącach roku. A najbardziej potępiająca statystyka: 70% wykorzystanych kontraktów było audytowanych, ale brakowało im jakiejkolwiek formy monitorowania po wdrożeniu. Tylko 4% śledzonych projektów łączyło audyty, aktywne programy bug bounty i monitorowanie przez strony trzecie.
Ekostystem Ethereum, będący domem dla największej koncentracji wartości inteligentnych kontraktów, działa w oparciu o fundamentalnie inny model bezpieczeństwa. Kontrakty wdrażane są do mainnetu poprzez niezmienną transakcję. Jeśli później pojawi się luka, opcje są ograniczone: wdrożenie nowego kontraktu i migracja użytkowników, wdrożenie wzorca proxy upgrade, który wprowadza własną powierzchnię ataku, lub zaakceptowanie ryzyka. Hack mostu Wormhole w 2022 roku kosztował 320 milionów dolarów, ponieważ przestarzała funkcja weryfikacyjna pozostała w kodzie produkcyjnym. Wykorzystanie luki w Ronin w sierpniu 2024 roku kosztowało 12 milionów dolarów, ponieważ aktualizacja kontraktu nie zainicjowała poprawnie wag operatorów. W obu przypadkach przeprowadzono audyty; awarie nastąpiły po wdrożeniu.
Hack KelpDAO 18 kwietnia 2026 roku, który wyprowadził około 293 milionów dolarów, był największym pojedynczym wykorzystaniem luki w DeFi w tym roku. Wykorzystanie luki w Drift Protocol na Solanie 1 kwietnia, które kosztowało około 286 milionów dolarów, było największym odnotowanym na tym łańcuchu. Te liczby nie są marginalnymi zdarzeniami. Reprezentują one podstawowy wskaźnik awaryjności branży, która łącznie straciła 16,69 miliarda dolarów na hacki, wykorzystanie mostów i incydenty bezpieczeństwa według danych DeFiLlama.
Proces głosowania nad poprawkami XRPL odwraca tę sekwencję. Kod trafia do wydania, ale funkcje pozostają uśpione, dopóki walidatorzy ich nie zatwierdzą. W oknie głosowania badacze, operatorzy węzłów i konkurujący audytorzy mogą zbadać działający kod źródłowy z pełnym kontekstem. Jeśli pojawi się problem, walidatorzy po prostu wstrzymują swoje głosy. Żadnej awaryjnej łatki, żadnej migracji, żadnej umowy proxy. Błąd Batch z lutego 2026 r. przeszedł dokładnie tą ścieżką: poprawka była w fazie głosowania, luka została zidentyfikowana, a awaryjne wydanie zapobiegło aktywacji. Zero środków zagrożonych, zero wpływu na użytkowników.
Nie oznacza to, że model XRPL jest bezbłędny. Proces poprawek działa w przypadku funkcji na poziomie protokołu, ale nie obejmuje aplikacji zbudowanych na bazie księgi. Źle napisana linia zaufania lub integracja MPT nadal może prowadzić do utraty środków. A próg 80% walidatorów stwarza własne ryzyko: jeśli zbyt mało walidatorów zaktualizuje się do nowej wersji, uzasadnione poprawki bezpieczeństwa mogą utknąć. Jednak w przypadku zmian w rdzeniu protokołu potok audyt-głosowanie-aktywacja stanowi zasadniczo inną postawę bezpieczeństwa niż wdrażaj-i-miej-nadzieję.
Co to oznacza dla instytucjonalnej oferty XRPL
Ripple spędził rok 2026 na agresywnym budowaniu instytucjonalnej infrastruktury. Przejęcie Hidden Road za 1,25 miliarda dolarów, multi-aktywnego brokera pierwotnego przemianowanego na Ripple Prime, dało firmie regulowane wejście dla tradycyjnych finansów. RLUSD osiągnął kapitalizację rynkową 1,72 miliarda dolarów w niecały rok i w samym pierwszym kwartale przetworzył ponad 18 miliardów dolarów wolumenu transakcji. Goldman Sachs ujawnił pozycję o wartości 153,8 miliona dolarów w czterech ETF-ach XRP. Ripple uzyskał pełną licencję instytucji pieniądza elektronicznego od Luksemburga w lutym, uprawnienia brytyjskiego Urzędu Nadzoru Finansowego w styczniu oraz licencję MiCA Crypto-Asset Service Provider 6 lipca.
Funkcje instytucjonalnego DeFi pojawiające się w wersji 3.3.0 są technicznym odpowiednikiem tego rozwoju biznesowego. Poufne transfery odpowiadają na wymogi prywatności banków, które nie mogą ujawniać szczegółów transakcji na publicznej księdze. Sponsorowane opłaty rozwiązują problem tarcia przy wdrażaniu, który powstrzymywał aplikacje bankowości detalicznej przed korzystaniem z sieci zdecentralizowanych. Delegowanie uprawnień, po przejściu przepisania przez proces głosowania, umożliwi modele kontrolowanego dostępu, których wymagają działy zgodności.
Ale instytucjonalna adopcja zależy od zaufania, a zaufanie do infrastruktury blockchain ostatecznie sprowadza się do historii bezpieczeństwa. Fakt, że Ripple wykrył dwa krytyczne błędy, przepisał dwie całe implementacje funkcji, zapłacił zewnętrznym badaczom 309 000 dolarów za znalezienie problemów i nadal dostarczył wszystkie pięć funkcji zgodnie z harmonogramem, jest silniejszym argumentem instytucjonalnym niż jakakolwiek pojedyncza funkcja. Sugeruje to kulturę bezpieczeństwa, w której znajdowanie błędów jest nagradzane, a dostarczanie jest podporządkowane weryfikacji.
Ponad 300 instytucji finansowych z 55 krajów korzysta obecnie z RippleNet, z aktywnymi korytarzami płynności na żądanie na ponad 70 rynkach. Dla tych instytucji wyniki audytu Sherlocka nie są abstrakcyjne. Są dowodem na to, że kod obsługujący ich płatności transgraniczne został przetestowany pod kątem przeciwników przez badaczy z finansowymi zachętami do jego złamania. Czterofazowa mapa drogowa odporności kwantowej Ripple, której celem jest ukończenie do 2028 r., dodatkowo sygnalizuje, że firma projektuje z myślą o instytucjonalnych horyzontach czasowych mierzonych w dekadach, a nie cyklach wdrożeniowych.
Przeciwny argument: dlaczego sceptycy nie są przekonani
Najsilniejszy argument przeciwko nadmiernemu interpretowaniu audytu Sherlocka przebiega w dwóch kierunkach.
Po pierwsze, znalezienie 96 błędów przed wydaniem można przedstawić jako dowód dokładnych testów lub dowód niedbałego rozwoju. Zarówno luki Batch, jak i Permission Delegation znajdowały się w oryginalnych implementacjach, co oznacza, że przeszły wewnętrzny przegląd, zanim wyłapali je zewnętrzni badacze. Błąd Batch z lutego 2026 r. nie został zidentyfikowany przez zespół Ripple, ale przez niezależnego badacza i narzędzie AI. Jeśli zewnętrzni audytorzy są główną siatką bezpieczeństwa, wewnętrzny proces rozwoju może mieć luki jakościowe, które ostatecznie doprowadzą do luki, której żaden zewnętrzny recenzent nie zdąży wychwycić.
Po drugie, siła modelu poprawek XRPL, czyli możliwość zapobiegania aktywacji w oknie głosowania, jest jednocześnie ograniczeniem szybkości. Gotowość Ethereum do wdrażania i iteracji umożliwiła tempo innowacji, którego XRPL nie może dorównać. Pięć poprawek w wersji 3.3.0 było w fazie rozwoju i przeglądów przez miesiące. Oryginalna poprawka Batch została zaproponowana w 2025 roku. Dla protokołów konkurujących o uwagę programistów na szybko zmieniających się rynkach, sześciomiesięczny proces bezpieczeństwa może być zbyt wolny, aby przyciągnąć ekosystem deweloperski, który napędza efekty sieciowe.
Istnieje również ryzyko koncentracji w zestawie walidatorów. Próg aktywacji wynoszący 80% oznacza, że stosunkowo niewielka liczba walidatorów, z których wiele jest obsługiwanych przez podmioty ściśle powiązane z Ripple, kontroluje, czy poprawki wejdą w życie. Krytycy twierdzą, że nie jest to prawdziwie zdecentralizowane zarządzanie, ale proces zatwierdzania pod nadzorem, ubrany w język konsensusu. Gdy walidator Ripple zagłosował „tak” w sprawie poprawek dotyczących pożyczek w ostatnich tygodniach, podkreśliło to, jak duży wpływ firma zachowuje na swoją nominalnie zdecentralizowaną sieć.
Wreszcie, wypłata 309 000 dolarów z puli 550 000 dolarów rodzi praktyczne pytanie o zgodność zachęt. Najlepsi badacze bezpieczeństwa żądają stawek, które przekraczają to, co modele konkursowe zazwyczaj płacą za godzinę pracy. Jeśli najbardziej wykwalifikowani audytorzy pomijają konkursy XRPL, ponieważ oczekiwana wypłata za znalezisko jest niższa niż w przypadku prywatnych zleceń, przegląd kontradyktoryjny może być szeroki, ale niewystarczająco dogłębny, aby wychwycić najbardziej wyrafinowane wektory ataków.
Te zastrzeżenia mają znaczenie. XRP handlowano w okolicach 1,03 dolara pod koniec lipca 2026 roku, około 71% poniżej cyklicznego maksimum wynoszącego 3,65 dolara z 17 lipca 2025 roku, co sugeruje, że rynek nie uwzględnił jeszcze instytucjonalnej narracji. To, czy historia bezpieczeństwa przełoży się na adopcję, zależy od czynników wykraczających poza jakość kodu: jasności regulacyjnej, pozycji konkurencyjnej wobec rozwiązań warstwy 2 Ethereum oraz tego, czy instytucje bardziej dbają o audyty przed wdrożeniem niż o wielkość ekosystemu.
Na co zwrócić uwagę
Progi głosowania walidatorów dla pięciu poprawek 3.3.0: jeśli BatchV1_1 i PermissionDelegationV1_1 przekroczą 80% wsparcia w pierwszym cyklu głosowania, będzie to sygnał zaufania walidatorów do przepisanych wersji. Zatrzymanie sugerowałoby utrzymujące się obawy co do przepisanego kodu.
Raporty o błędach po aktywacji: prawdziwym testem dokładności audytu Sherlocka jest moment po uruchomieniu funkcji. Zero krytycznych ustaleń w pierwszych 90 dniach potwierdziłoby model przedpremierowy; jakakolwiek podatność po aktywacji podważyłaby całą tezę.
Adopcja RLUSD w poufnych transferach: instytucjonalne użycie stablecoinów na chronionych torach potwierdziłoby popyt na rozliczenia zgodne z prywatnością. Wskaźniki wolumenu w pierwszym kwartale po aktywacji będą najwyraźniejszym sygnałem, czy banki są gotowe do transakcji na publicznym rejestrze z gwarancjami prywatności.
Następne zaangażowanie Sherlocka w XRPL: to, czy Ripple będzie kontynuować konkursy audytów kontradyktoryjnych dla przyszłych poprawek, czy wróci do tradycyjnych prywatnych audytów, wskaże, jak głęboko model przedpremierowy jest zakorzeniony w kulturze rozwoju.
Konkurencyjne incydenty bezpieczeństwa łańcuchów: każdy poważny exploit na Ethereum lub Solanie, który można prześledzić do podatności po wdrożeniu, wzmacnia argument za potokiem audyt-głosowanie-aktywacja XRPL. Porównanie jest tak silne, jak ciągła porażka branży w przyjęciu podobnych procesów.
Co wykrył audyt Sherlock XRP Ledger?
Dwutygodniowy konkurs audytowy, który rozpoczął się 13 kwietnia 2026 roku, ujawnił 96 prawidłowych podatności w pięciu proponowanych poprawkach XRPL: 2 krytyczne, 6 wysokich, 29 średnich i 59 niskich problemów. Ripple wypłacił 309 000 dolarów w nagrodach RLUSD z puli nagród wynoszącej 550 000 dolarów. Wszystkie ustalenia zostały rozwiązane przed aktywacją jakichkolwiek dotkniętych funkcji w sieci głównej.
Jaki był krytyczny błąd w poprawce Batch?
Oryginalna poprawka Batch zawierała wadę weryfikacji podpisu, która pozwalała atakującemu na wykonanie wewnętrznych transakcji z dowolnego konta bez posiadania jego kluczy prywatnych. Błąd polegał na warunku wczesnego wyjścia w sprawdzaniu podpisu transakcji zewnętrznej, który mógł być spełniony bez odpowiedniej weryfikacji autoryzacji. Badacz Pranamya Keshkamat oraz narzędzie AI Cantiny, Apex, zidentyfikowali go 19 lutego 2026 roku. RippleX naprawił go w awaryjnej wersji 3.1.1 cztery dni później.
Jak działała podatność Permission Delegation?
Oryginalna implementacja sprawdzała uprawnienia delegata przed weryfikacją podpisów transakcji. Na XRPL transakcje, które kończą się błędami klasy „tec”, nadal pobierają opłaty. Atakujący mógł wielokrotnie przesyłać nieprawidłowe transakcje z podwyższonymi opłatami przeciwko kontu delegowanemu, wyczerpując jego saldo XRP bez posiadania kluczy. Poprawka przeklasyfikowała typ błędu i zmieniła kolejność kontroli weryfikacyjnych.
Czy jakiekolwiek środki zostały utracone z powodu tych podatności?
Żadne środki nie zostały utracone. Obie krytyczne podatności zostały zidentyfikowane przed aktywacją odpowiednich poprawek w sieci głównej. Błąd Batch został wykryty podczas fazy głosowania walidatorów, a wada Permission Delegation została ujawniona i naprawiona przed aktywacją. Proces poprawek XRP Ledger, który wymaga 80% wsparcia walidatorów przez dwa kolejne tygodnie, zapewnił strukturalną bufor, który zapobiegł wykorzystaniu.
Czym jest Sherlock i jak działa jego model audytu?
Sherlock to firma zajmująca się bezpieczeństwem Web3, która organizuje audyty jako konkursy adversarialne, rankingując badaczy według wyników i oferując zachęty finansowe poprzez pule nagród. Zaangażowanie XRP Ledger było pierwszą współpracą Sherlocka z Ripple i jednym z największych konkursów audytowych 2026 roku. Model różni się od tradycyjnych prywatnych audytów, zapraszając szerokie grono niezależnych badaczy bezpieczeństwa konkurujących o nagrody, co ujawnia szerszy zakres wektorów ataków niż mały wewnętrzny zespół.
Czym model bezpieczeństwa XRPL różni się od Ethereum?
Proces poprawek XRPL oddziela wdrażanie kodu od aktywacji funkcji. Nowe funkcje są dostarczane w wersji oprogramowania, ale pozostają uśpione, dopóki walidatorzy nie zagłosują za ich aktywacją, tworząc okno przeglądu, w którym można wychwycić podatności bez awaryjnych łat. Inteligentne kontrakty Ethereum są aktywne natychmiast po wdrożeniu, a naprawa podatności wymaga wdrożenia nowych kontraktów, migracji użytkowników lub implementacji uaktualnień proxy. W pierwszych pięciu miesiącach 2026 roku exploity DeFi przekroczyły 840 milionów dolarów, a 70% wykorzystanych kontraktów było audytowanych, ale brakowało im monitorowania po wdrożeniu.
Jakie funkcje zawiera wersja 3.3.0 XRP Ledger?
Wersja 3.3.0, wydana 6 sierpnia 2026 roku, zawiera kod dla pięciu poprawek funkcji oraz łatkę porządkową. Funkcje obejmują Poufne Transfery dla Tokenów Wielofunkcyjnych z wykorzystaniem dowodów wiedzy zerowej, przepisane Transakcje Partii dla atomowego rozliczania wielu operacji, przepisaną Delegację Uprawnień dla kontrolowanego dostępu do konta, Opłaty Sponsorowane umożliwiające aplikacjom pokrywanie kosztów użytkowników oraz DynamicMPT umożliwiające emitentom modyfikację właściwości tokenów po ich utworzeniu.
Czy ten audyt czyni XRPL bezpieczną inwestycją?
Audyt Sherlocka odzwierciedla rygorystyczny proces bezpieczeństwa przed wydaniem, ale jakość kodu jest jednym z wielu czynników wpływających na wyniki inwestycyjne. XRP handlowano w okolicach 1,03 dolara pod koniec lipca 2026 roku, około 71% poniżej cyklicznego maksimum, a wyniki rynkowe zależą od rozwoju regulacji, wskaźników adopcji instytucjonalnej, dynamiki konkurencji i warunków makroekonomicznych. To analiza edukacyjna, a nie porada inwestycyjna. **Zastrzeżenie**: Ten artykuł został opublikowany 14 sierpnia 2026 roku. Jest przeznaczony wyłącznie do celów edukacyjnych i informacyjnych i nie powinien być interpretowany jako porada finansowa, inwestycyjna ani prawna. Rynki kryptowalut są zmienne i niosą znaczne ryzyko. Czytelnicy powinni przeprowadzić własne badania i skonsultować się z wykwalifikowanymi specjalistami przed podjęciem jakichkolwiek decyzji inwestycyjnych.
