Zyski:
- Umiejętność wykorzystania sztucznej inteligencji do tworzenia frameworków, testów i recenzowania wersji roboczych w oparciu o sprawdzone biblioteki (np. OpenZeppelin) oraz zrozumienie, że bezpieczeństwo produkcji gwarantuje człowiek
- Możliwość weryfikacji wersji kodu, wzorca i kontroli dostępu wytwarzanej przez sztuczną inteligencję poprzez kompilację, testowanie i testnet
- Możliwość rozróżnienia tej kompilacji nie oznacza, że jest bezpieczna i że sieć testowa i audyt są niezbędne.
Pisanie inteligentnej umowy różni się od zwykłego oprogramowania: kod, który piszesz, jest publiczny, niezmienny i jest programem, który bezpośrednio przenosi pieniądze. W tej części dowiesz się, jak wykorzystywać sztuczną inteligencję jako inteligentnego asystenta opracowywania kontraktów; Będziemy uczyć się od produkcji projektu po pisanie testów, od przypominania wzorców po optymalizację gazu (opłaty transakcyjnej). Ale od początku postawmy sprawę jasno: sztuczna inteligencja tworzy plany; Ludzie zapewniają bezpieczny kod, który trafia do produkcji.
Najpierw podstawa: język i środowisko
Najpopularniejszym językiem inteligentnych kontraktów jest Solidity (język Ethereum i EVM – Ethereum Virtual Machine, maszyna wirtualna, na której uruchamiane są kontrakty – kompatybilne łańcuchy). Alternatywą jest Vyper (język podobny do Pythona, który ma być bardziej ograniczony i czytelny). Twój kod zużywa gaz (koszt każdej transakcji w łańcuchu bloków); Nieefektywny kod jest kosztowny. Zapewnienie przejrzystości tych terminów w kontekście, w jakim przekazujesz je sztucznej inteligencji, jest kluczem do uzyskania dokładnych wyników.
Najcenniejsza sztuczna inteligencja nie polega na „pisaniu od zera”, ale na tworzeniu ram + dobrej formy: początek zgodny ze standardami, plan, na którym możesz dodać swoją wiedzę specjalistyczną.
Warstwy wykorzystania AI w kodowaniu
1. Generowanie szkieletów. Sztuczna inteligencja szybko wydobywa szkielet standardowego tokena (ERC-20) lub NFT (ERC-721 — unikalny standard zasobów cyfrowych). Pamiętaj jednak, aby sztuczna inteligencja korzystała ze sprawdzonej biblioteki: na przykład OpenZeppelin (zaufana przez społeczność, kontrolowana standardowa biblioteka kontraktowa). Zasadą jest użycie testowanego bloku, a nie pisanie zabezpieczeń od zera.
2. Opis i przegląd funkcji. Wyjaśnienie AI istniejącej funkcji pozwala wcześnie wykryć błędy logiczne.
3. Generowanie testów. Sztuczna inteligencja dobrze radzi sobie z generowaniem przypadków testowych dla przypadków brzegowych: zero danych wejściowych, bardzo duża liczba, nieautoryzowany rozmówca, powtarzane połączenie. Przypomina to jeden ze scenariuszy, który się pomija.
4. Gaz i czytelność. Sztuczna inteligencja sygnalizuje kosztowne wzorce, takie jak niepotrzebne zapisy w pamięci, i sugeruje alternatywy.
Wskazówka: poinstruuj sztuczną inteligencję, aby „Opierała się na skontrolowanych kontraktach OpenZeppelin i przepisała zabezpieczenia od zera”. Dla sztucznej inteligencji napisanie oryginalnego kodu zabezpieczającego jest znacznie bardziej ryzykowne niż użycie przetestowanej biblioteki.
Słaba zachęta/silna zachęta
Słaba zachęta:
Napisz mi umowę symboliczną.
Ten monit jest niebezpieczny: nie jest jasne, jaki standard, jaki łańcuch, jaka biblioteka, jakie wymagania bezpieczeństwa. Sztuczna inteligencja generuje losowy, prawdopodobnie nieaktualny lub niepewny kod.
Potężny monit:
Twoja rola: starszy programista Solidity. Wygeneruj wersję roboczą tokena ERC-20 dla łańcucha kompatybilnego z EVM. Zasady: – Na podstawie skontrolowanych przez OpenZeppelin umów ERC20 i Ownable. – Zapisz wyraźnie wersję Solidity i linię licencyjną (SPDX). – Tylko właściciel ma pozwolenie na bicie; dodaj czapkę przed nieskończonym naciśnięciem. - Dodaj komentarz NatSpec do każdej funkcji. - Napisz zabezpieczenia od podstaw; Użyj standardowego bloku. - Dodaj ostrzeżenie na końcu: „To jest wersja robocza; wymagany jest audyt i testowanie”. Zaznacz obszary, których nie jesteś pewien za pomocą // TODO.
Różnica: silna zachęta zapewnia jasną rolę, standard, bibliotekę, granicę bezpieczeństwa, dokumentację i oczekiwania dotyczące walidacji.
Cztery szablony do kopiowania
1) Szkielet oparty na standardach:
Twoja rola: Programista Solidity. Generuj ramy kontraktowe [ERC-20 / ERC-721 / staking] w oparciu o bibliotekę kontrolowaną przez OpenZeppelin. Napisz licencję SPDX i wersję pragmy. Dodaj kontrolę dostępu (kto może dzwonić) do każdej funkcji zewnętrznej. Nowe podejście do kwestii bezpieczeństwa; Użyj standardowych bloków. To jest projekt.
2) Przegląd funkcji:
Przeanalizuj jak starszy programista następującą funkcję: co ona robi, jakie stany zmienia, kto może ją wywołać? Oznacz możliwe błędy logiczne i zagrożenia bezpieczeństwa jako HIPOTEZĘ, łącząc je z linią w kodzie. Nie mów wprost „bezpieczny”; po prostu wymień punkty uwagi.
3) Projekt scenariusza testowego:
Zaproponuj przypadki testowe dla tego kontraktu (może to być wersja robocza dla Foundry/Hardhat). W szczególności obejmują przypadki graniczne: zero danych wejściowych, bardzo duża liczba, nieautoryzowane połączenie, ponowne połączenie, niewystarczające środki. Napisz CO potwierdza każdy test.
4) Przegląd gazu i czytelności:
W umowie tej zaznacz wzorce, które mogą obniżyć koszt gazu: niepotrzebne zapisywanie w pamięci, wywołanie zewnętrzne w pętli, powtarzalne obliczenia. Wyjaśnij różnicę przed i po w każdej sugestii. Polecaj optymalizacje naruszające bezpieczeństwo; Jeśli nie jest to jasne, powiedz „zapytaj audytora”.
Trzy mini etui (w liczbach)
Przypadek 1 — Szkielet uratował 4 godziny. Jeden zespół w ciągu 30 minut zapoznał się ze szkieletem skontrolowanej umowy dotyczącej nabywania uprawnień w oparciu o biblioteki ze sztuczną inteligencją; Ręcznie zajęło to ~4 godziny. Zespół poświęcił czas na bezpieczeństwo i testowanie. Zysk nie wynikał z przeniesienia bezpieczeństwa, ale z przyspieszenia nudnego frameworku.
Przypadek 2 — Przestarzała wersja pułapki. Sztuczna inteligencja stworzyła wzór, który wysyła surowy Ether poprzez transfer, co nie jest już zalecane, ponieważ dane treningowe są nieaktualne. Deweloper zauważył to i zmienił go na bieżący wzorzec oparty na połączeniach i chroniony przed ponownym wejściem. Lekcja: Zawsze potwierdzana jest aktualność biblioteki/wzorca sztucznej inteligencji; AI nie zna daty zakończenia szkolenia.
Przypadek 3 — W wersji testowej pojawił się ukryty błąd. Test „nieautoryzowanego rozmówcy” przeprowadzony przez sztuczną inteligencję ujawnił, że programista zapomniał o kontroli dostępu do funkcji. onlyOwner brakuje 1 linii, złapany w sieci testowej w ciągu 5 minut; Mogła nastąpić utrata środków w sieci głównej. Lekcja: Sztuczna inteligencja obejmuje ludzki martwy punkt podczas testów.
Zapamiętywanie wzorców bezpieczeństwa dzięki sztucznej inteligencji
Sztuczna inteligencja dobrze radzi sobie z przypominaniem o znanych wzorcach luk w zabezpieczeniach, niczym lista kontrolna. Najczęstsze wzory:
- Reentrancy: Wykonywanie połączenia zewnętrznego bez aktualizacji statusu. Rozwiązanie: kolejność kontroli-efektów-interakcji, ochrona przed ponownym wejściem.
- Brak kontroli dostępu: Każdy może wywołać funkcję krytyczną.
- Przepełnienie/niedobór liczb całkowitych: Modern Solidity wychwytuje większość z nich, ale nadal stanowi ryzyko w kodzie niskiego poziomu.
- Nieodpowiednia walidacja danych wejściowych: adres zerowy, kontrola ilości zerowej.
- Zależność od Oracle: ślepe zaufanie do danych zewnętrznych (takich jak cena).
Uwaga: sztuczna inteligencja może przywołać tę listę, ale nie może zagwarantować, czy pozycja na liście znajduje się w Twoim konkretnym kodzie. Lista kontrolna to początek; Nie zastępuje kontroli kontenerów.
Właściwe ustawienie kontekstu: sekret dobrego kodu oparty na sztucznej inteligencji
Jakość kodu generowanego przez sztuczną inteligencję zależy bezpośrednio od jakości nadanego mu kontekstu. W Web3 jest to szczególnie istotne, ponieważ jeden mały szczegół (który łańcuch, która wersja Solidity, jaki standard tokena) zmienia cały wynik. Dobry kontekst obejmuje:
- Łańcuch docelowy i środowisko: sieć główna Ethereum czy warstwa 2 (tańszy łańcuch boczny działający na szczycie łańcucha głównego)? Koszt gazu i niektóre funkcje różnią się w zależności od sieci.
- Wersja i biblioteka: Która wersja Solidity, która wersja OpenZeppelin? Jeśli nie określono żadnej wersji, sztuczna inteligencja może generować przestarzałe, przestarzałe wzorce.
- Wymogi bezpieczeństwa: Czy istnieje limit, czy można go wstrzymać, czy można go zwiększyć? Należy to powiedzieć od samego początku.
- Ograniczenia: Jasne ograniczenia, takie jak „nie używaj zestawu”, „unikaj połączeń zewnętrznych”, „optymalizuj gaz, ale zachowaj czytelność”.
Inną skuteczną techniką jest poproszenie sztucznej inteligencji najpierw o plan, a następnie o kod: „Najpierw wypisz funkcje tej umowy i co każda z nich będzie robić; napisz kod, gdy go zatwierdzę”. To wcześnie wychwytuje sztuczną inteligencję zmierzającą w złym kierunku i pozwala zachować decyzję architektoniczną.
Wskazówka: zapytaj sztuczną inteligencję „dlaczego napisałeś ten kod w ten sposób?” zapytać. Wyjaśnienie uzasadnienia zarówno przyspieszy naukę, jak i wykryje wszelkie błędy logiczne (np. fałszywe założenia dotyczące bezpieczeństwa). Nie ufaj wynikom sztucznej inteligencji, która nie jest w stanie obronić własnego kodu.
Typowe błędy
- Bezpieczeństwo w sztucznej inteligencji od podstaw. Użyj przetestowanej biblioteki.
- Nie potwierdzanie wersji/wzoru wyprodukowanego przez sztuczną inteligencję. Dane treningowe mogą być stare.
- Omijanie sieci testowej. Każda wersja robocza powinna zostać uruchomiona w sieci testowej przed publikacją.
- Nie dodawanie NatSpec/dokumentacji. Przeglądy i konserwacja stają się trudne.
- Błędne przekonanie „Jest skompilowany, więc jest bezpieczny”. To, że jest skompilowany, nie oznacza, że jest bezpieczne.
- Zapominając o kontroli dostępu. Jest to jeden z najczęstszych i kosztownych błędów.
Podsumowując
- Podczas pisania inteligentnych umów sztuczna inteligencja tworzy ramy, testy i wersje robocze recenzji; Człowiek gwarantuje bezpieczeństwo produkcji.
- Buduj bezpieczeństwo nie od zera, ale w oparciu o sprawdzone biblioteki (np. OpenZeppelin).
- Zawsze potwierdzana jest aktualność wersji i wzorów produkowanych przez YZ.
- Fragmenty testów są cenne w wychwytywaniu ludzkich martwych punktów (przypadki graniczne, kontrola dostępu).
- Bycie skompilowanym nie oznacza bycia bezpiecznym; testnet i audyt są koniecznością.
Zadanie aplikacji
W przypadku prostego tokena ERC-20 wygeneruj wersję roboczą, korzystając z powyższego monitu „szkielet oparty na standardach”. Następnie: (1) sprawdź, czy korzysta ze sprawdzonej biblioteki, (2) sprawdź kontrolę dostępu, (3) wygeneruj testy z podpowiedzią „wersja robocza przypadku testowego” i faktycznie przeprowadź co najmniej jeden test nieuczciwego dzwoniącego. Znajdź i zanotuj przynajmniej jeden punkt bezpieczeństwa, który przeoczyła sztuczna inteligencja.
lista kontrolna
- [ ] W monicie wyraźnie określiłem standard i łańcuch.
- [ ] Chciałem sprawdzonej produkcji opartej na bibliotekach.
- [ ] Dostępna licencja SPDX i wersja pragma.
- [ ] W każdej krytycznej funkcji istnieje kontrola dostępu.
- [ ] Stworzyłem i uruchomiłem testy dla przypadków granicznych.
- [ ] Potwierdziłem, że biblioteka/wzorzec jest aktualny.
- [ ] Zaznaczyłem kod do audytu i testowania; Nie dostałem tego bez nadzoru w sieci głównej.