Kasu:
- Võimalus kasutada tehisintellekti tõestatud teekide (nt OpenZeppelin) põhjal raamistike, testide ja mustandite ülevaatamiseks ning mõista, et inimesed tagavad tootmise turvalisuse
- Võimalus kontrollida tehisintellekti loodud koodi versiooni, mustrit ja juurdepääsu juhtimist kompileerimise, testimise ja testneti kaudu
- Oskus eristada, et kompileerimine ei tähenda turvalisust ning et testnet ja auditeerimine on hädavajalikud.
Nutika lepingu kirjutamine erineb tavalisest tarkvarast: teie kirjutatud kood on avalik, muutumatu ja programm, mis liigutab otseselt raha. Selles üksuses saate teada, kuidas kasutada tehisintellekti nutika lepingu arendusassistendina; Õpime mustandite tootmisest testide kirjutamiseni, mustri tagasikutsumist gaasi (tehingutasu) optimeerimiseni. Kuid olgem algusest peale selged: tehisintellekt toodab jooniseid; Inimesed tagavad turvalise koodi, mis läheb tootmisse.
Esmalt maa: keel ja keskkond
Levinuim nutikas lepingukeel on Solidity (Ethereumi ja EVM-i keel — Ethereumi virtuaalmasin, virtuaalne masin, millel lepingud töötavad — ühilduvad ketid). Alternatiiviks on Vyper (Pythoni-laadne keel, mille eesmärk on olla piiratum ja loetavam). Teie kood tarbib gaasi (iga tehingu maksumus plokiahelale); Ebaefektiivne kood on kallis. Täpse väljundi saamise võtmeks on nende mõistete selge hoidmine kontekstis, mille annate AI-le.
Tehisintellekt pole kõige väärtuslikum mitte nullist kirjutamine, vaid raamistiku + hea vormi loomine: standarditele vastav algus, plaan, millele oma teadmisi lisada.
AI kasutamise kihid kodeerimisel
1. Skelettide genereerimine. Tehisintellekt kaevandab kiiresti standardse märgi (ERC-20) või NFT (ERC-721 – ainulaadne digitaalsete varade standard) skeleti. Kuid veenduge, et tehisintellekt kasutaks tõestatud raamatukogu: näiteks OpenZeppelin (kogukonna usaldusväärne, auditeeritud standardne lepinguteek). Reegel on kasutada testitud plokki, mitte kirjutada turvalisust nullist.
2. Funktsiooni kirjeldus ja ülevaade. Olemasoleva funktsiooni selgitamine tehisintellektile võimaldab teil varakult märgata loogikavigu.
3. Testi genereerimine. AI suudab hästi luua testjuhtumeid servajuhtumite jaoks: null sisend, väga suur arv, volitamata helistaja, korduv kõne. See tuletab meelde üht stsenaariumi, mille vahele jääb.
4. Gaas ja loetavus. Tehisintellekt märgib kallid mustrid (nt mittevajalikud salvestuskirjad) ja soovitab alternatiive.
Vihje: andke tehisintellektile käsk "Ehitada OpenZeppelini auditeeritud lepingutele, kirjutada turvalisus nullist ümber." Tehisintellektil on palju riskantsem kirjutada originaalset turvakoodi kui kasutada testitud teeki.
Nõrk viip / Tugev viip
Nõrk viip:
Kirjutage mulle sümboolne leping.
See viip on ohtlik: pole selge, milline standard, milline kett, milline raamatukogu, milline turbenõue. AI genereerib juhuslikku, võib-olla aegunud või ebaturvalist koodi.
Võimas viip:
Teie roll: Solidity'i vanemarendaja. Looge EVM-iga ühilduva keti jaoks ERC-20 märgi mustand. Reeglid:- Põhineb OpenZeppelini auditeeritud ERC20 ja Ownable lepingutel.- Kirjutage Solidity versiooni ja litsentsi (SPDX) rida selgesõnaliselt.- Vermimiseks on luba ainult omanikul; lisage lõputu vajutamise vastu kork. - Lisage igale funktsioonile NatSpeci kommentaar. - Kirjuta turvalisus nullist; Kasutage standardplokki. - Lisage lõppu hoiatus: "See on mustand; vajalik on auditeerimine ja testimine". Märkige valdkonnad, milles te pole kindel, kasutades // TODO.
Erinevus: tugev viip annab selge rolli, standardi, teegi, turbepiiri, dokumentatsiooni ja valideerimise ootused.
Neli kopeeritavat malli
1) Standarditel põhinev skelett:
Teie roll: Solidity arendaja. Looge OpenZeppelini auditeeritud teegi põhjal [ERC-20 / ERC-721 / staking]lepingu raamistik. Kirjutage SPDX litsents ja pragma versioon. Lisage juurdepääsukontroll (kes saab helistada) igale välisele funktsioonile. Turvalisuse taasleiutamine; Kasutage standardseid plokke. See on mustand.
2) Funktsioonide ülevaade:
Uurige järgmist funktsiooni nagu vanemarendaja: mida see teeb, milliseid olekuid see muudab, kes saab seda nimetada? Märkige võimalikud loogikavead ja turvariskid HÜPOTEESINA, sidudes igaüks koodi reaga. Ärge öelge otse "turvaline"; lihtsalt loetlege tähelepanupunktid.
3) Testi stsenaariumi mustand:
Pakkuge selle lepingu jaoks välja testjuhtumid (võib olla Foundry/Hardhati mustand). Täpsemalt katta limiitjuhtumid: null sisend, väga suur arv, volitamata kõne, uuesti sisenev kõne, ebapiisavad rahalised vahendid. Kirjutage, MIDA iga test kinnitab.
4) Gaasi ja loetavuse ülevaade:
Märgistage selles lepingus mustrid, mis võivad gaasikulusid vähendada: tarbetu salvestusruumi kirjutamine, ahela väliskõne, korduv arvutamine. Selgitage iga soovituse enne/pärast erinevust. soovitada turvalisust rikkuvaid optimeerimisi; Kui see pole selge, öelge "küsi audiitorilt".
Kolm miniümbrist (numbrites)
Juhtum 1 – skelett säästis 4 tundi. Üks meeskond kaevandas 30 minutiga tehisintellektiga sõlmitud auditeeritud raamatukogupõhise üleandmislepingu luustiku; Käsitsi kulus ~4 tundi. Meeskond pühendas aega turvalisusele ja testimisele. Kasu ei tulnud mitte turvalisuse ülekandmisest, vaid tüütu raamistiku kiirendamisest.
Juhtum 2 – aegunud versioonilõks. AI koostas mustri, mis saadab tooreetri ülekande teel, mida enam ei soovitata, kuna treeningandmed on aegunud. Arendaja märkas seda ja muutis selle praegusele kõnepõhisele ja taassisenemiskaitsega mustrile. Õppetund: tehisintellekti teek/muster kinnitatakse alati olevat ajakohane; AI ei tea pärast koolituse lõppkuupäeva.
Juhtum 3 – testmustand avanes peidetud vea. Tehisintellekti loodud "volitamata helistaja" test näitas, et arendaja oli unustanud funktsiooni juurdepääsukontrolli. onlyOmanner puudu 1 rida, püütud 5 minutiga testnetist; Põhivõrgus võis raha kaduda. Õppetund: AI katab testimisel inimese pimeala.
Turvamustrite meeldejätmine tehisintellektiga
AI tuletab teile hästi meelde teadaolevaid haavatavuse mustreid, näiteks kontrollnimekirja. Kõige tavalisemad mustrid:
- Taassisenemine: väliskõne tegemine ilma olekut värskendamata. Lahendus: kontrollide-efektide-interaktsioonide järjekord, taassisenemise valvur.
- Juurdepääsukontrolli puudumine: kriitilisele funktsioonile saab helistada igaüks.
- Täisarvude ületäitumine/allalangemine: Modern Solidity püüab enamiku neist kinni, kuid madala taseme koodi puhul on siiski oht.
- Ebapiisav sisendi valideerimine: nullaadress, nullkoguse kontroll.
- Oracle'i sõltuvus: pime usaldus väliste andmete (nt hinna) vastu.
Tähelepanu: AI võib selle loendi meelde tuletada, kuid ei saa garanteerida, kas loendis olev üksus on teie konkreetses koodis. Kontrollnimekiri on algus; See ei asenda konteineri kontrolli.
Konteksti õigsus: tehisintellekti hea koodi saladus
AI toodetava koodi kvaliteet sõltub otseselt sellele antud konteksti kvaliteedist. Web3-s on see eriti kriitiline, kuna üks väike detail (milline kett, milline Solidity versioon, milline märgi standard) muudab kogu väljundit. Hea kontekst sisaldab järgmist:
- Sihtkett ja keskkond: Ethereumi põhivõrk või Layer 2 (odavam külgahel, mis jookseb peaahela peal)? Gaasi hind ja mõned funktsioonid on ahelati erinevad.
- Versioon ja teek: milline Solidity versioon, milline OpenZeppelini versioon? Kui versiooni pole määratud, võib AI toota aegunud, aegunud mustreid.
- Turvanõuded: Kas piirang on olemas, kas seda saab peatada, kas seda saab suurendada? Neid tuleks öelda kohe algusest peale.
- Piirangud: selged piirangud, nagu "ära kasuta montaaži", "vältige väliskõnet", "optimeerige gaasi, kuid säilitage loetavus".
Veel üks võimas tehnika on küsida esmalt AI-lt plaani ja seejärel koodi: "Kõigepealt loetlege selle lepingu funktsioonid ja mida igaüks teeb; kirjutage kood pärast selle kinnitamist." See tabab tehisintellekti vales suunas liikumas varakult ja võimaldab teil säilitada arhitektuurilise otsuse.
Vihje: Küsige tehisintellektilt "miks sa selle koodi niimoodi kirjutasite?" küsi. Põhjenduse selgitamine kiirendab teie õppimist ja toob pinnale kõik loogikavead (nt vale turvaeeldus). Ärge usaldage tehisintellekti väljundit, mis ei suuda oma koodi kaitsta.
Levinud vead
- Turvalisus AI-sse nullist peale. Kasutage testitud raamatukogu.
- Ei kinnita AI loodud versiooni/mustrit. Treeningu andmed võivad olla vanad.
- Testvõrgust möödasõit. Iga mustand peaks enne avaldamist testvõrgus töötama.
- NatSpec/dokumentatsiooni ei lisata. Ülevaatus ja hooldus muutuvad keeruliseks.
- "See on koostatud, nii et see on ohutu" eksiarvamus. Koostatud olemine ei tähenda turvalisust.
- Juurdepääsukontrolli unustamine. See on üks levinumaid ja kulukamaid vigu.
Kokkuvõttes
- Nutika lepingute kirjutamise puhul toodab AI raamistikke, testib ja vaatab üle kavandeid; Inimene tagab tootmisohutuse.
- Ehitage turvalisust mitte nullist, vaid põhinedes tõestatud teekidel (nt OpenZeppelin).
- YZ toodetud versioonide ja mustrite ajakohasus on alati kinnitatud.
- Katsetükid on väärtuslikud inimeste pimealade jäädvustamisel (piirjuhtumid, juurdepääsukontroll).
- Koostatud olemine ei tähenda turvalisust; testnet ja auditeerimine on kohustuslikud.
Rakenduse ülesanne
Lihtsa ERC-20 märgi jaoks looge mustand, kasutades ülaltoodud viipa "standardipõhine skelett". Seejärel: (1) kontrollige, kas see kasutab kontrollitud teeki, (2) kontrollige juurdepääsu juhtelemente, (3) genereerige testid viipaga "testjuhtumi mustand" ja käivitage tegelikult vähemalt üks petturitest helistaja test. Otsige üles ja märkige üles vähemalt üks turvapunkt, millest tehisintellekt märkimata jäi.
kontrollnimekiri
- [ ] Olen viipas standardi ja ahela selgelt välja öelnud.
- [ ] Tahtsin tõestatud raamatukogupõhist tootmist.
- [ ] Saadaval on SPDX-litsents ja pragma-versioon.
- [ ] Igas kriitilises funktsioonis on juurdepääsukontroll.
- [ ] Lõin ja käivitasin piirjuhtumite testid.
- [ ] Kinnitasin, et raamatukogu/muster on ajakohane.
- [ ] Märkisin koodi auditeerimiseks ja testimiseks; Ma ei saanud seda põhivõrgus järelevalveta.