Najtrudniejszy problem jest prosty do opisania. Jak zaufać kodowi blockchain napisanemu przez AI, zanim trafi on na niezmienne środowisko?
Traktuję wyniki działania AI jako hipotezę. To słowo ma znaczenie. Hipoteza to trafne zgadywanie, które brzmi rozsądnie, a nie dowód poprawności kodu. Model AI może wygenerować czyste Solidity, Rust, Pythona czy JavaScript, a mimo to ukryć błędne założenie, niesprawdzony przypadek brzegowy czy lukę bezpieczeństwa.
Różnica między pewnością siebie a poprawnością to sedno sprawy. AI często wypowiada się bardzo pewnie. Ale kodowi zupełnie obojętne jest, jak pewnie brzmi jego autor. Systemy on-chain są szczególnie bezlitosne, bo zły kod może stać się trwałą, kosztowną i jawną rzeczywistością.
Dlatego weryfikacja nie jest kwestią wyboru. W blockchainie błąd może zamienić się w nieodwracalną stratę. Kilka godzin poświęconych na sprawdzenie kodu to ułamek tego, co przyniesie awaria niszcząca skarbiec, blokująca kontrakt lub otwierająca drogę do kradzieży. Różnica w kosztach jest bolesna i absolutnie realna.
Lubię myśleć o tym procesie przez pryzmat czterech warstw. Każda z nich wychwytuje inny rodzaj błędu. Żadna z nich nie wystarczy samodzielnie.
1. Przegląd przez człowieka stoi na pierwszym miejscu
Przegląd przez człowieka to pierwsza brama. Nie jest to jedynie formalne potwierdzenie. To moment, w którym ktoś czyta logikę i zastanawia się, czy kod w ogóle ma sens.
Taki przegląd weryfikuje założenia. Sprawdza zasady niezmiennicze, czyli warunki, które muszą zawsze pozostawać spełnione. Analizuje przypadki brzegowe, gdzie kod najczęściej się sypie. Jeśli AI twierdzi, że przelew jest bezpieczny, recenzent pyta, co się stanie, gdy salda wynoszą zero, dane wejściowe są nietypowe, albo wywołania funkcji zawiodą w połowie procesu.
Ten etap jest kluczowy, ponieważ AI jest szybkie, a nie mądre. Potrafi sklejać wzorce z danych treningowych, a mimo to przegapić ten jeden szczegół, który naprawdę ma znaczenie. Przeglądający nie musi ufać modelowi. Musi przetestować ideę stojącą za kodem.
Mały przykład robi to jasnym. Załóżmy, że AI pisze funkcję wypłat dla aukcji tokenów. Kod wygląda schludnie. Przeglądający zauważa jednak, że funkcja aktualizuje stan dopiero po wysłaniu środków, co tworzy lukę umożliwiającą atak reentrancy. Błąd nie rzucał się w oczy. Po prostu na niego czekał.
2. Zautomatyzowane testy wychwytują zachowanie, a nie intencje
Kolejną warstwą są testy zautomatyzowane. Obejmują one testy jednostkowe, integracyjne, oparte na właściwościach, wariantowe oraz fuzzing. Każde z nich przygląda się kodowi z innej perspektywy.
Testy jednostkowe sprawdzają drobne fragmenty w izolacji. Testy integracyjne weryfikują, jak poszczególne elementy współpracują ze sobą. Testy oparte na właściwościach szukają zasad, które muszą obowiązywać przy dużej liczbie danych wejściowych. Fuzzing rzuca na kod nietypowe dane i śledzi ewentualne awarie. Testy wariantowe sprawdzają, czy drobne zmiany nie zaburzają oczekiwanego działania.
W systemach blockchain to nie dodatkowy szlif. To podstawowa higiena programistyczna. Kontrakty i kod protokołu wymagają dowodów behawioralnych, zanim zyskają zaufanie. Zestaw testów nie gwarantuje bezpieczeństwa, ale wychwytuje awarie jeszcze przed użytkownikami. O to właśnie chodzi.
Sprawdzenia bezpieczeństwa również pasują do tej kategorii, nawet w swojej minimalnej wersji podczas zatwierdzania zmian. Niebezpieczny kod nie powinien wpłynąć do głównej gałęzi tylko dlatego, że nikomu nie chciało się uruchomić podstawowego skanowania. Testy zautomatyzowane są szybkie, wielokrotnie powtarzalne i proste. Nie są eleganckie, ale to całkowicie wystarczające.
3. Niezależne narzędzia wychwytują inne błędy
Trzecią warstwą są niezależne narzędzia. Chodzi o rozwiązania, które nie analizują kodu tak samo jak AI, które je wygenerowało. Analiza statyczna, linterzy, skanery bezpieczeństwa oraz weryfikacje formalne każda z nich dostrzega inny aspekt problemu.
Analiza statyczna pozwala namierzyć wzorce sugerujące zagrożenia. Linterzy wychwytują problemy stylistyczne i strukturalne, które często maskują głębsze błędy. Skanery bezpieczeństwa poszukują znanych luk. Weryfikacje formalne, tam gdzie są dostępne, mogą potwierdzić, czy ściśle określone twierdzenie faktycznie obowiązuje.
Taka wzajemna weryfikacja jest kluczowa, ponieważ każde pojedyncze narzędzie ma swoje ślepe plamy. Tak samo każdy pojedynczy model. Jeśli AI zaproponuje poprawkę, a to samo AI pomoże ją zweryfikować, system po prostu odbije własne błędy. To zła praktyka w programowaniu, a w blockchainie wręcz niebezpieczna.
Niezależne narzędzia dają drugą i trzecią opinię, wolną od tych samych uprzedzeń co pierwotny model. Nie zastępują ludzkiego osądu. Nie zastępują testów. Znacznie redukują ryzyko, że pozornie schludne rozwiązanie prześlizgnie się bez kontroli.
4. Myślenie w kategoriach ataku jest częścią weryfikacji
Ostatnią warstwą jest modelowanie zagrożeń. To moment, w którym zespół przestaje zadawać pytanie „Czy to działa?”, a zaczyna pytać: „Jak zawiedzie w warunkach ataku?”.
Dotyczy to zarówno początkujących atakujących, jak i zorganizowanych grup dysponujących rzeczywistym warsztatem. Chodzi też o brzydkie, choć powszechne scenariusze, w których exploit znajduje ktoś nie tyle sprytny, co po prostu szczęśliwy. W systemach blockchain powierzchnia ataku nie jest abstrakcją. Jest publiczna, trwała i często bardzo dochodowa.
Istotną rolę odgrywa tu MEV. MEV (Maximum Extractable Value, czyli maksymalna wartość możliwa do wydobycia) to zysk, jaki uczestnik sieci może czerpać z kolejności transakcji i działania samego łańcucha. Jeśli twój kod stwarza możliwość nadużyć związanych z MEV, może być „poprawny” w teoretycznym sensie, a jednocześnie niebezpieczny w praktyce.
Modelowanie zagrożeń wymusza też uwzględnienie faktu nieodwracalności wdrożenia. Raz umieszczony w łańcuchu kod zmienia się ciężko, wolno lub wcale. Dlatego weryfikacja musi nastąpić przed publikacją. Po wdrożeniu cena żalu rośnie błyskawicznie.
Najprościej powiedzieć to wprost. Jeśli wysiłek wart 20 tysięcy dolarów pozwala uniknąć utraty 2 miliardów dolarów w skarbcu, matematyka jest trywialna. Kosztowne nie jest sprawdzanie. Kosztowne jest jego brak.
Czego weryfikacja nie jest
Weryfikacja to nie jedno magiczne narzędzie. Nie sprowadza się do pojedynczego skanowania, jednego audytu czy zielonego znaczka od modelu. To także nie pieczęć operacyjna gwarantująca bezpieczeństwo na wieki.
To proces przeprowadzany przed wdrożeniem. Zachodzi zanim kod wejdzie w skład działającego systemu. Zadaje pytanie, czy wynik działania AI to użyteczny punkt startowy, czy niebezpieczne zgadywanie w schludnym opakowaniu.
Nie oznacza też autoryzacji wyniku AI przez AI. Brzmi to wydajnie. W praktyce zwykle jest lenistwem. Model może pomóc w szkicu kodu, zasugerować testy lub zwrócić uwagę na pewne wzorce. Nie może jednak przejąć odpowiedzialności za ryzyko.
To fundamentalna zasada w moim rozumieniu. AI to programista junior, który pracuje szybko, ale nie ma żadnych uprawnień. Przydatny, owszem. Zasługujący na pełne zaufanie – nie. Każda poważna linia kodu wymaga przed publikacją przeglądu przez człowieka, testów, niezależnych narzędzi oraz myślenia w kategoriach zagrożeń.
Praktyczna lekcja jest prosta. Traktuj kod generowany przez AI jako szkic, a weryfikację jako prawdziwą pracę. W blockchainie, gdzie błędy są trwałe, ta praca to po prostu cena prowadzenia biznesu. Dzięki takiemu podejściu cały proces staje się znacznie łatwiejszy do ogarnięcia. „Model Log” powstał właśnie dla takiej jasności: jeden praktyczny koncept AI, jeden działający przykład i jedno szczere spojrzenie na to, co naprawdę działa.
