Zespół bezpieczeństwa Ethereum Foundation przez kilka miesięcy testował agentów AI jako łowców błędów w kodzie, na którym opiera się cała sieć. Znaleźli realną lukę zdolną wyłączać walidatory, ale prawdziwym odkryciem okazało się coś innego: maszyna produkuje fałszywe alarmy równie przekonująco jak prawdziwe zagrożenia.
Kluczowe fakty:
- Zespół Protocol Security z Ethereum Foundation przez kilka miesięcy testował agentów AI jako łowców błędów w kodzie sieci Ethereum, w tym w systemie operacyjnym, kodzie kryptograficznym i smart kontraktach.
- Agenty AI wykryły realną lukę w komponencie gossipsub (CVE-2026-34219), która pozwalała zdalnie wywołać awarię węzła i wyłączyć walidatora z sieci do czasu ręcznego restartu – błąd został naprawiony.
- Największym wyzwaniem okazało się nie znajdowanie błędów, lecz odróżnianie prawdziwych luk od fałszywych alarmów, które wyglądały równie przekonująco jak rzeczywiste zagrożenia.
Piszę o tym, bo raport, który Ethereum Foundation opublikowała 9 lipca, to jeden z pierwszych publicznych, szczegółowych opisów tego, jak agentowe AI radzi sobie w konfrontacji z kodem odpowiedzialnym za miliardy dolarów. Nie jest to marketingowa zapowiedź „AI znalazło błąd”, tylko chłodny opis metody, w tym jej ograniczeń.
Znajdź dostawcę, partnera lub narzędzie dla swojego biznesu, a jeśli prowadzisz firmę, która w swoim DNA ma AI, skorzystaj z możliwości bezpłatnego dodania swojej firmy.
Co dokładnie znaleziono
Zespół Protocol Security z Ethereum Foundation skierował skoordynowane agenty AI przeciwko oprogramowaniu, na którym pracują węzły sieci: system operacyjny, kod kryptograficzny, kontrakty wymagające bezbłędnego działania. Agenty znalazły błąd w gossipsub, komponencie warstwy peer-to-peer odpowiedzialnym za przekazywanie wiadomości między węzłami. Luka pozwalała zdalnie wywołać awarię (panic), przez którą oprogramowanie węzła trafiało na niemożliwe do wykonania obliczenie i samo się wyłączało, zabierając walidatora z sieci do czasu ręcznego restartu.
Błąd otrzymał oznaczenie CVE-2026-34219, został naprawiony i ujawniony z podziękowaniem dla zespołu. To konkretny, wymierny efekt eksperymentu.
Autor raportu, Nikos Baxevanis z Ethereum Foundation, napisał wprost, gdzie leżało zaskoczenie. Jak ujął to w oryginale: „Zaskoczeniem było to, jak mało pracy poszło w znajdowanie błędów i jak dużo w odróżnianie prawdziwych od tych, które tylko wyglądały na prawdziwe” / „The surprise was how little of the work went into finding them, and how much went into telling the real bugs from the ones that just looked real.”
Agent to narzędzie do szukania, nie wyrocznia
Kluczowe zdanie z raportu brzmi: agent wskazany na kod działa jak fuzzer, czyli standardowe narzędzie zasypujące oprogramowanie zniekształconymi danymi, aż coś się wysypie. Różnica jest w tym, co dostajesz na wyjściu.
Fuzzer zwraca awarię i ślad, gdzie do niej doszło. Inżynier potwierdza to w kilka minut. Agent zwraca coś znacznie bardziej rozbudowanego: opis ścieżki ataku, uzasadnienie, dlaczego to ma znaczenie, proponowaną ocenę powagi błędu i działający kod demonstrujący atak. Wszystko podane płynną prozą, brzmiącą identycznie niezależnie od tego, czy błąd jest prawdziwy, czy zmyślony.
Zespół zidentyfikował trzy powtarzające się typy fałszywych alarmów:
- awaria występująca wyłącznie w wersji testowej (debug), gdzie kompilator włącza dodatkowe zabezpieczenia nieobecne w wersji produkcyjnej, więc u realnego użytkownika nic się nie psuje
- atak działający tylko wtedy, gdy niebezpieczną wartość wstrzykuje się ręcznie do programu, bo każda ścieżka dostępna dla atakującego z zewnątrz odrzuca tę wartość wcześniej
- dowód formalny (formal verification), który przechodzi weryfikację, ale dowodzi czegoś trywialnie prawdziwego i nic nie mówi o rzeczywistym zachowaniu kodu
Każdy z tych przypadków to test, który w praktyce niczego nie sprawdza. Problem w tym, że agent pisze taką pustą wersję równie szybko i równie przekonująco jak tę prawdziwą.
Sztuczna inteligencja w bezpieczeństwie protokołów to temat, przy którym łatwo o skrajne reakcje. Jedni ogłaszają koniec zawodu audytora, drudzy odrzucają całą metodę jako zabawkę generującą śmieci. Ten raport pokazuje trzecią drogę, dużo mniej efektowną, ale bardziej wiarygodną. Agent realnie poszerza pole poszukiwań, bo potrafi przeczesać znacznie więcej kodu niż zespół ludzi w tym samym czasie. Ale nie da się go zostawić bez nadzoru, bo produkuje fałszywe trafienia z taką samą pewnością siebie jak prawdziwe. To oznacza, że koszt bezpieczeństwa się nie zmniejsza, tylko przesuwa: mniej płacimy za szukanie, więcej za weryfikację. Firmy wdrażające podobne rozwiązania powinny zadać sobie pytanie, czy mają w zespole kogoś zdolnego odróżnić dobrze napisaną fikcję od realnego zagrożenia. Bo jeśli nie, to agent AI nie obniży ryzyka, tylko je zamaskuje warstwą profesjonalnie wyglądającej dokumentacji.
Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
Chcesz czytać więcej treści związanych z AI?
Dodaj AIPORT.pl do preferowanych źródeł Google
Gdzie agent zawodzi najbardziej
Raport wskazuje jeszcze jedną słabość, poważniejszą niż fałszywe alarmy. Agent radzi sobie dobrze z rozumowaniem o pojedynczym momencie w kodzie, a słabo z błędami rozciągniętymi na sekwencję kroków, z których każdy z osobna jest poprawny i dopiero kolejność tworzy lukę.
To dokładnie wzorzec, który opisuje większość tegorocznych włamań na protokoły DeFi. Atak na Edel Finance ominął poprawny system wycen Chainlink przez warstwę pośredniczącą nad nim, a w ataku na skarbiec BONK zakup tokenów, głosowanie i wykonanie uchwały były z osobna zwyczajnymi transakcjami. Dopiero razem złożyły się na kradzież.
Odpowiedzią Ethereum Foundation jest ograniczenie roli agenta: proponuje on sekwencje warte przetestowania, ale samo testowanie wykonuje tradycyjny, stanowy harness, nie sam model.
Metoda: role generowane przez pracę
Zespół nie buduje centralnego koordynatora zarządzającego agentami. Zamiast tego wiele agentów pracuje równolegle nad jednym celem, koordynując się przez samo repozytorium kodu, wzorem podejścia opisanego wcześniej przez Anthropic przy budowie kompilatora C siłami floty agentów. Role wyłaniają się z samej pracy:
- rekonesans zamienia powierzchnię ataku na konkretne, testowalne hipotezy
- polowanie bierze jedną hipotezę, śledzi ścieżkę w kodzie i buduje reproduktor
- wypełnianie luk analizuje, co zostało zaakceptowane, a co odrzucone, i pisze kolejną porcję hipotez
- walidacja niezależnie sprawdza każdego kandydata, usuwa duplikaty i podejmuje decyzję
Zasada nadrzędna brzmi: kandydat nie liczy się jako odkrycie, dopóki nie istnieje samodzielny artefakt odtwarzający awarię na prawdziwym kodzie, uruchamialny przez kogoś, kto go nie napisał.
Ethereum nie jest osamotniony w tym podejściu
Zespoły dochodzą do podobnego przepisu niezależnie od siebie. Zespół Anthropic Frontier Red Team zbudował agenta piszącego testy oparte na właściwościach programu, który znalazł realne błędy w bibliotekach Pythona, wygenerował około tysiąca kandydatów, z czego po rankingu i przeglądzie eksperckim utrzymała się grupa trafna w około 86 procentach przypadków. Cloudflare przepuścił model klasy frontier przez własny system audytowy skierowany na wewnętrzne systemy firmy i doszedł do tego samego wniosku: wąski zakres bije szerokie skanowanie.
Co to oznacza dla polskich firm?
Ethereum zabezpiecza dziś ponad 39,6 miliona ETH ulokowanych w ponad 1,2 miliona walidatorów, co odpowiada mniej więcej jednej trzeciej całej krążącej podaży tokena. To pokazuje skalę, w jakiej pojedynczy błąd w warstwie sieciowej może przełożyć się na realne pieniądze, bo wartość tego zabezpieczenia liczona jest w dziesiątkach miliardów dolarów.
Dla polskiego rynku, gdzie firmy zajmujące się audytem smart kontraktów i bezpieczeństwem Web3 rosną razem z regulacjami MiCA i wymogami NIS2, ten raport ma konkretne przełożenie praktyczne. Krajowe zespoły red teamowe coraz częściej oferują testy kontraktów i infrastruktury blockchain jako osobną usługę, a doświadczenie Ethereum Foundation pokazuje, że samo dorzucenie agenta AI do procesu audytu nie skraca automatycznie czasu pracy zespołu. Zmienia tylko jej charakter, z szukania błędów na ocenę, które z setek znalezisk faktycznie coś znaczą.
Za każdą polską firmą AI stoi konkretny człowiek z imieniem i nazwiskiem, często ten sam w kilku miejscach naraz, i to właśnie ludzie, nie tabelki finansowania, są prawdziwym bohaterem tego artykułu.
Widzę w tym sygnał dla polskich firm rozwijających własne kontrakty czy infrastrukturę blockchainową: warto pytać dostawcę audytu nie o to, ile narzędzi AI wykorzystał, tylko jaki ma proces odsiewania fałszywych trafień i kto podejmuje ostateczną decyzję o realności błędu.
Źródła i metodologia
Artykuł powstał na podstawie analizy redakcji AIPORT.pl oraz dodatkowych źródeł, w tym oficjalnego wpisu zespołu Protocol Security Ethereum Foundation Blog z dnia 09.07.2026 oraz materiału CoinDesk z dnia 11.07.2026. Dane rynkowe dotyczące liczby walidatorów i wolumenu stakowanego ETH pochodzą z analiz agregujących dane beaconcha.in i Dune. Cytat Nikosa Baxevanisa został zweryfikowany z oryginalnym anglojęzycznym materiałem źródłowym z bloga Ethereum Foundation. Komentarz redakcyjny i ocena kontekstu branżowego: Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl. Artykuł będzie aktualizowany w miarę pojawiania się nowych informacji na temat wykorzystania AI w audytach bezpieczeństwa protokołów blockchain.
