Dobici:
- Sposobnost korištenja umjetne inteligencije za izradu okvira, testova i pregleda nacrta zasnovanih na dokazanim bibliotekama (npr. OpenZeppelin) i razumijevanje da ljudi garantuju sigurnost proizvodnje
- Sposobnost provjere verzije koda, uzorka i kontrole pristupa koju proizvodi umjetna inteligencija putem kompilacije, testiranja i testne mreže
- Biti u stanju razlikovati tu kompilaciju ne znači biti siguran i da su testnet i revizija od suštinskog značaja.
Pisanje pametnog ugovora razlikuje se od običnog softvera: kod koji pišete je javan, nepromjenjiv i program koji direktno prenosi novac. U ovoj jedinici ćete naučiti kako koristiti AI kao pomoćnika za razvoj pametnih ugovora; Učićemo od izrade nacrta do pisanja testa, od opoziva šablona do optimizacije gasa (transakciona naknada). Ali budimo jasni od početka: AI proizvodi nacrte; Ljudi osiguravaju siguran kod koji ide u proizvodnju.
Prvo: jezik i okruženje
Najčešći jezik pametnih ugovora je Solidity (jezik Ethereuma i EVM — Ethereum Virtual Machine, virtuelna mašina na kojoj se pokreću ugovori — kompatibilni lanci). Alternativa je Vyper (jezik sličan Pythonu koji ima za cilj da bude ograničeniji i čitljiviji). Vaš kod troši plin (cijena svake transakcije u blockchainu); Neefikasan kod je skup. Održavanje ovih termina jasnim u kontekstu koji dajete AI ključno je za dobijanje tačnih rezultata.
Ono što je AI najvrednije nije u "pisanju od nule", već u stvaranju okvira + dobrog kalupa: početak u skladu sa standardima, nacrt na koji možete dodati svoju stručnost.
Slojevi korištenja AI u kodiranju
1. Generisanje skeleta. AI brzo rudari kostur standardnog tokena (ERC-20) ili NFT (ERC-721 — jedinstveni standard digitalnih sredstava). Ali budite sigurni da AI koristi provjerenu biblioteku: na primjer, OpenZeppelin (pouzdana, revidirana standardna biblioteka za ugovaranje zajednice). Pravilo je da se koristi testirani blok radije nego da se sigurnost piše od nule.
2. Opis i pregled funkcije. Objašnjenje postojeće funkcije AI omogućava vam da rano uočite logičke greške.
3. Generisanje testa. AI je dobar u generiranju test slučajeva za rubne slučajeve: nula unosa, vrlo veliki broj, neovlašteni pozivatelj, ponovljeni poziv. Ovo podsjeća na jedan od scenarija koji se preskače.
4. Gas i čitljivost. AI označava skupe obrasce kao što je nepotrebno upisivanje u pohranu i predlaže alternative.
Savjet: Uputite AI da "nagradi na revidiranim ugovorima OpenZeppelina, prepiše sigurnost od nule." Mnogo je rizičnije za AI da napiše originalni sigurnosni kod nego da koristi testiranu biblioteku.
Slaba prompt / Jaka prompt
Slab upit:
Napišite mi simbolični ugovor.
Ovaj upit je opasan: nije jasno koji standard, koji lanac, koja biblioteka, koji sigurnosni zahtjev. AI generira nasumični, možda zastarjeli ili nesigurni kod.
Snažan upit:
Vaša uloga: viši Solidity developer. Generirajte ERC-20 nacrt tokena za EVM kompatibilan lanac. Pravila: - Na osnovu revidiranih OpenZeppelin ERC20 i Ownable ugovora. - Eksplicitno napišite Solidity verziju i licencu (SPDX). - Samo vlasnik ima dozvolu za kovanje; dodajte poklopac protiv beskonačnog pritiska. - Dodajte NatSpec komentar svakoj funkciji. - Napišite sigurnost od nule; Koristite standardni blok. - Dodajte upozorenje na kraju: "Ovo je nacrt; potrebna je revizija i testiranje". Označite područja za koja niste sigurni sa // TODO.
Razlika: jak prompt daje jasnu ulogu, standard, biblioteku, sigurnosne granice, dokumentaciju i očekivanja validacije.
Četiri šablona za kopiranje
1) Standardni skelet:
Vaša uloga: Solidity developer. Generirajte [ERC-20 / ERC-721 / staking] okvir ugovora zasnovan na OpenZeppelin revidiranoj biblioteci. Napišite SPDX licencu i pragma verziju. Dodajte kontrolu pristupa (ko može zvati) svakoj eksternoj funkciji. Reinventing security; Koristite standardne blokove. Ovo je nacrt.
2) Pregled funkcije:
Proučite sljedeću funkciju poput starijeg programera: šta radi, koja stanja mijenja, ko je može pozvati? Označite moguće logičke greške i sigurnosne rizike kao HIPOTEZE, povezujući svaku sa linijom u kodu. Nemojte direktno reći "sigurno"; samo navedite tačke pažnje.
3) Nacrt scenarija testa:
Predložite probne slučajeve za ovaj ugovor (može biti nacrt za Foundry/Hardhat). Posebno pokrijte granične slučajeve: nula unosa, veoma veliki broj, neovlašćeni poziv, ponovni poziv, nedovoljno sredstava. Napišite ŠTA svaki test potvrđuje.
4) Pregled plina i čitljivosti:
U ovom ugovoru označite obrasce koji mogu smanjiti trošak plina: nepotrebno skladištenje, vanjski poziv u petlji, ponavljajući proračun. Objasnite razliku prije/poslije u svakom prijedlogu. Preporučite optimizacije koje probijaju sigurnost; Ako nije jasno, recite "pitajte revizora".
Tri mini kofera (u brojevima)
Slučaj 1 — Skelet je ušteđen 4 sata. Jedan tim je za 30 minuta iskopao kostur revidiranog bibliotečkog ugovora o preuzimanju prava sa AI; Ručno je trebalo ~4 sata. Tim je posvetio vrijeme sigurnosti i testiranju. Dobitak nije došao od prenošenja sigurnosti, već od ubrzanja dosadnog okvira.
Slučaj 2 — Zamka zastarjela verzija. AI je proizveo obrazac koji šalje sirovi Eter prijenosom, što se više ne preporučuje jer su podaci o obuci zastarjeli. Programer je to primijetio i promijenio ga u trenutni obrazac zasnovan na pozivu i zaštićen od ponovnog ulaska. Lekcija: Biblioteka/obrazac AI uvijek se potvrđuje da je ažuriran; AI ne zna dalje od datuma prekida obuke.
Slučaj 3 — Probni nacrt iskočio je skrivenu grešku. Test "neovlaštenog pozivaoca" koji je proizvela AI otkrio je da je programer zaboravio kontrolu pristupa u funkciji. onlyOwner nedostaje 1 linija, uhvaćen za 5 minuta na testnetu; Mogao je doći do gubitka sredstava na glavnoj mreži. Lekcija: AI pokriva ljudsku slijepu tačku u testiranju.
Prisjećanje sigurnosnih obrazaca pomoću AI
AI je dobar u podsjećanju na poznate obrasce ranjivosti kao što je kontrolna lista. Najčešći uzorci:
- Ponovni ulazak: Upućivanje eksternog poziva bez ažuriranja statusa. Rješenje: red provjere-efekti-interakcije, zaštita ponovnog ulaska.
- Nedostatak kontrole pristupa: Svako može pozvati kritičnu funkciju.
- Integer overflow/underfall: Modern Solidity hvata većinu njih, ali i dalje predstavlja rizik u kodu niskog nivoa.
- Neadekvatna validacija unosa: nulta adresa, nulta kontrola količine.
- Oracle zavisnost: Slijepo povjerenje u vanjske podatke (kao što je cijena).
Pažnja: AI može opozvati ovu listu, ali ne može garantirati da li je stavka na listi u vašem specifičnom kodu. Kontrolna lista je početak; Nije zamjena za kontrolu kontejnera.
Ispravan kontekst: Tajna dobrog koda od AI
Kvalitet koda koji AI proizvodi zavisi direktno od kvaliteta konteksta koji mu dajete. U Web3 ovo je posebno kritično jer jedan mali detalj (koji lanac, koja verzija Solidityja, koji token standard) mijenja cijeli izlaz. Dobar kontekst uključuje:
- Ciljni lanac i okruženje: Ethereum mainnet ili Layer 2 (jeftiniji bočni lanac koji radi na vrhu glavnog lanca)? Trošak plina i neke karakteristike variraju u zavisnosti od lanca.
- Verzija i biblioteka: Koja verzija Solidityja, koja verzija OpenZeppelina? Ako nije navedena nijedna verzija, AI može proizvesti zastarjele, zastarjele obrasce.
- Sigurnosni zahtjevi: Postoji li ograničenje, može li se pauzirati, može li se povećati? Ovo treba reći od samog početka.
- Ograničenja: Jasna ograničenja poput "nemojte koristiti sklop", "izbjegavajte vanjski poziv", "optimizirajte plin, ali održavajte čitljivost".
Još jedna moćna tehnika je da prvo od AI zatražite plan, a zatim šifru: "Prvo navedite funkcije ovog ugovora i šta će svaki raditi; napišite kod kada ga ja odobrim." Ovo rano hvata AI kako ide u pogrešnom smjeru i omogućava vam da zadržite arhitektonsku odluku.
Savjet: Pitajte AI "zašto ste napisali ovaj kod ovako?" pitaj. Objašnjenje obrazloženja će ubrzati vaše učenje i iznijeti na površinu sve logičke greške (npr. lažnu sigurnosnu pretpostavku). Ne vjerujte rezultatu AI koji ne može braniti vlastiti kod.
Uobičajene greške
- Postavljanje sigurnosti u AI od nule. Koristite testiranu biblioteku.
- Ne potvrđuje verziju/uzorak proizveden od strane AI. Podaci o obuci mogu biti stari.
- Zaobilaženje testneta. Svaki nacrt bi trebao biti pokrenut na probnoj mreži prije objavljivanja.
- Ne dodaje se NatSpec/dokumentacija. Inspekcija i održavanje postaju teški.
- "Sastavljen je, tako da je siguran" zabluda. Biti sastavljen ne znači biti siguran.
- Zaboravljam kontrolu pristupa. To je jedna od najčešćih i najskupljih grešaka.
Ukratko
- U pisanju pametnih ugovora, AI proizvodi okvire, testove i recenzira nacrte; Ljudi garantuju sigurnost proizvodnje.
- Izgradite sigurnost ne od nule, već na osnovu dokazanih biblioteka (npr. OpenZeppelin).
- Ažurnost verzija i uzoraka koje proizvodi YZ uvijek se potvrđuje.
- Test stubovi su vrijedni u hvatanju ljudskih mrtvih uglova (ograničeni slučajevi, kontrola pristupa).
- Biti sastavljen ne znači biti siguran; testnet i revizija su obavezni.
Zadatak aplikacije
Za jednostavan ERC-20 token, generirajte nacrt koristeći "kostur zasnovan na standardima" iznad. Zatim: (1) provjerite da li koristi provjerenu biblioteku, (2) provjerite kontrole pristupa, (3) generirajte testove sa promptom "test case draft" i stvarno pokrenite barem jedan test lažnog pozivaoca. Pronađite i zabilježite barem jednu sigurnosnu točku koju je AI propustio.
kontrolna lista
- [ ] Jasno sam naveo standard i lanac u promptu.
- [ ] Želio sam dokazanu bibliotečku produkciju.
- [ ] Dostupna SPDX licenca i pragma verzija.
- [ ] U svakoj kritičnoj funkciji postoji kontrola pristupa.
- [ ] Kreirao sam i pokrenuo testove za granične slučajeve.
- [ ] Potvrdio sam da je biblioteka/šablon ažuriran.
- [ ] Označio sam kod za reviziju i testiranje; Nisam ga dobio bez nadzora na glavnoj mreži.