Trudnym wyzwaniem nie jest zmuszenie sztucznej inteligencji do pisania w Solidity. Trudnym wyzwaniem jest wiedza, czy wynik jest wystarczająco bezpieczny, by przechowywać prawdziwą wartość.
AI może przeglądać kod, sugerować poprawki, tworzyć testy, porównywać projekty i sporządzać dokumentację. Może to zwiększyć prędkość pracy deweloperów. Może też sprawić, że błędne decyzje szybciej przenikną przez system. W inżynierii blockchain ten błąd może pozostać aktywny, dopóki ktoś go nie znajdzie.
Dlaczego blockchain zmienia ryzyko
Kontrakt inteligentny to oprogramowanie działające na blockchainie. Może przechowywać aktywa, egzekwować zasady i przemieszczać środki. Po wdrożeniu zmiana jego działania może być trudna lub niemożliwa, chyba że projekt przewiduje ścieżkę aktualizacji.
To sprawia, że kontrakt różni się od zwykłej usługi internetowej. Zespół webowy często może łatka serwer i wdrożyć go ponownie. Kontrakt może wymagać pełnej wymiany, migracji lub awaryjnego zatrzymania. Każda opcja dodaje koszt i ryzyko.
Kod ma również publiczny cel. Umieszczone łańcuchowo kontrakty są czytelne dla ludzi i maszyn. Jeśli błąd może odblokować skrytkę, wyemitować tokeny, ominąć kontrolę dostępu lub przemieścić środki, motywacja do jego znalezienia jest jasna.
Mały błąd może cicho czekać. Może umknąć ludzkiej kontroli, narzędziom zautomatyzowanym i innym systemom AI. Problem pozostaje, dopóki ktoś go nie zauważy lub nie wykorzysta.
Co AI dobrze robi w audycie
AI jest użyteczna, ponieważ może szybko przetwarzać kod. Może przeczytać plik, wyjaśnić funkcję, wskazać podejrzane ścieżki i zasugerować przypadki testowe. Może również porównać dwie wybory implementacyjne.
Działa to najlepiej, gdy zadanie ma wyraźną granicę. Deweloper może poprosić system AI o sprawdzenie logiki wypłaty pod kątem brakujących kontroli. System może wymienić przypadki brzegowe, takie jak zerowe kwoty, wielokrotne wypłaty, nieudane transfery i niespodziewane callbacki.
AI może również pomóc w dokumentacji. Może zamienić złożone funkcje na prosty język. Może powiązać metody publiczne ze zmianami stanu. Może stworzyć pierwszy szkic modelu zagrożeń lub planu testów.
Szkic nadal wymaga przeglądu technicznego. AI często pisze tekst, który brzmi kompletnie. Brzmienie kompletnie nie jest tym samym co bycie poprawnym.
Przydatny przepływ audytu traktuje AI jako szybka warstwę analizy. Nie traktuje AI jako ostatecznej autorytetu.
Mały przykład re-entrancy
Rozważ skrytkę z funkcją withdraw. Funkcja sprawdza saldo użytkownika, wysyła pieniądze, a następnie zmniejsza zapisane saldo.
Taka kolejność stwarza problem. Odbiorca może być kontraktem, który wywołuje withdraw ponownie przed zakończeniem pierwszego wywołania. Skrytka nadal pokazuje stare saldo podczas tego drugiego wywołania. Te same środki mogą zostać wtedy wypłacone więcej niż raz.
Recenzent AI może zidentyfikować ten wzorzec. Może zasugerować kolejność Checks-Effects-Interactions (Sprawdź-Wpływy-Wzajemne Oddziaływania) stosowaną w wytycznych bezpieczeństwa Solidity: sprawdź żądanie, zaktualizuj wewnętrzny stan, a następnie wywołaj inny kontrakt.
Ważnym szczegółem nie jest fraza. To reguła systemowa za nią stojąca. Saldo musi ulec zmianie przed przekazaniem kontroli kodowi zewnętrznemu.
System AI może nadal przeoczyć problem, jeśli istotny stan znajduje się w innym kontrakcie. Może również zasugerować poprawkę, która naruszy niezmiennik w innym miejscu. Funkcja może wyglądać bezpiecznie w izolacji, a pozostawać niebezpieczna w całym systemie.
To jest centralne ograniczenie. AI często działa na pliku lub krótkim oknie kontekstu. Bezpieczeństwo blockchaina zależy od relacji między kontraktami, uprawnieniami, tokenami, oraklami, ścieżkami aktualizacji i założeniami ekonomicznymi.
Szybszy kod przesuwa wąskie gardło
Generowanie kodu staje się tanie. Narzędzia oparte na dużych modelach językowych mogą produkować funkcje Solidity, testy, komentarze i alternatywne projekty w kilka sekund.
To zmienia to, gdzie idzie czas inżynierski. Rzetelna praca staje się przegląd i rozumowanie.
Wygenerowana funkcja może się kompilować i nadal łamać zasady produktu. Może używać starego wzorca. Może umieścić sprawdzanie w złej funkcji. Może chronić jedną ścieżkę wywołań, pozostawiając inną odsłoniętą.
AI ma również nawyk pewnych błędów. Może opisać nieprawdopodobny wynik spokojnym głosem. Tworzy to niebezpieczną formę fałszywego zaufania. Recenzent może obniżyć czujność, ponieważ wyjaśnienie brzmi precyzyjnie.
Problemem nie jest to, że AI popełnia błędy. Każde narzędzie popełnia błędy. Problemem jest bias automatyzacji. Ludzie zaczynają traktować odpowiedź zautomatyzowaną jako zweryfikowaną odpowiedź.
Krótki prompt może zmniejszyć to ryzyko. Może stwierdzić niezmienniki kontraktu, granice zaufania, zasady dostępu, zachowanie przy awarii i zabronione założenia. Im ważniejsze ograniczenie, tym bardziej dosłownie trzeba je napisać.
Gdzie ludzkie osądzanie pozostaje pod kontrolą
Niektóre decyzje należą do projektanta systemu. Należą do nich kluczowe niezmienniki, model uprawnień, elementy sterujące awarią i warunki bezpiecznych aktualizacji.
Niezmiennik to reguła, która musi zawsze obowiązywać. Dla skrytki może to oznaczać, że zapisane salda użytkowników nie mogą przekraczać aktywów trzymanych przez skrytkę, z zastrzeżeniem wyraźnie zdefiniowanych warunków zewnętrznych.
AI może pomóc w testowaniu tej reguły. Nie powinna wymyślać reguły bez ludzkiego właścicielstwa.
Autonomiczne wdrożenie to kolejna granica. Pozwolenie AI na uruchomienie wdrożenia produkcyjnego tworzy dużą powierzchnię ataku. Skompromitowany prompt, fałszywe wyjście, skradziony klucz portfela lub słabe sprawdzenie pipeline’u może zamienić błąd recenzji w zdarzenie on-chain.
Przerzutniki (circuit breakers) pomagają zawierać awarię. Funkcja pauzy, limit wydawnictwa, opóźnione wykonanie lub zatwierdzenie wielostronne mogą zmniejszyć szkody spowodowane złą wersją. Te kontrolki nie czynią niebezpiecznego kodu bezpiecznym. Stwarzają czas na wykrycie i zawarcie problemu.
Ta sama zasada dotyczy projektu. AI może eksplorować opcje. Nie powinna podejmować ostatecznej decyzji bezpieczeństwa dla systemu, który kontroluje pieniądze lub wpływa na bezpieczeństwo ludzi.
Praktyczny podział pracy
Silny proces daje zadania AI, które korzystają z szybkości, a zadania inżynierom, które wymagają odpowiedzialności.
AI może eksplorować dwa projekty i porównywać ich kompromisy. Może generować przypadki brzegowe z sygnatury funkcji. Może przeglądać powtarzalne wzorce w plikach. Może sporządzić dokumentację i wyjaśniać nieznany kod.
Inżynierowie definiują niezmienniki. Sprawdzają, czy proponowany projekt pasuje do pełnej architektury. Weryfikują zachowanie Solidity, przeglądają wywołania zewnętrzne, kwestionują dziwne założenia i zatwierdzają warunki wydania.
Ten podział poprawia również jakość przeglądu. Zamiast pytać „Czy ten kod wygląda OK?”, recenzent może spytać „Jaki niezmiennik chroni ta linia?” i „Co się stanie, jeśli to wywołanie zewnętrzne zawiedzie lub wywoła callback?”
Te pytania wymuszają na przeglądzie skupienie na zachowaniu. To ma znaczenie, ponieważ AI optymalizuje pod kątem prawdopodobnego tekstu i prawdopodobnego kodu. Poprawność wymaga dowodu, testów i kontekstu systemowego.
Bezpieczeństwo kontraktów inteligentnych już teraz wykorzystuje kilka warstw obrony. Analiza statyczna może znaleźć powszechne wzorce. Testy jednostkowe i integracyjne mogą sprawdzić oczekiwane zachowanie. Testy fuzz mogą eksplorować nietypowe wejścia. Testy niezmienników mogą sprawdzać, czy kluczowe reguły obowiązują w wielu akcjach. Przegląd ludzki łączy te wyniki z intended design (zamierzonym projektem).
Żadna pojedyncza warstwa nie wychwytuje wszystkiego. AI dodaje kolejną użyteczną warstwę, gdy jej rola jest jasna.
AI zmienia inżynierię blockchain, redukując koszt eksploracji. Nie usuwa kosztu odpowiedzialności. Szybki asystent może wyprodukować więcej opcji, więcej testów i bardziej czytelny kod. Może również szybciej wyprodukować zły kontrakt.
Praktyczna lekcja jest prosta. Używaj AI, aby poszerzyć poszukiwanie błędów i alternatyw projektowych. Zachowaj ludzi odpowiedzialnymi za niezmienniki, architekturę, decyzje bezpieczeństwa i zatwierdzenie wdrożenia.
To jest roboczy pomysł stojący za The Model Log: jeden praktyczny koncept AI, jeden działający przykład i jeden szczery spojrzenie na to, co naprawdę działa.
