Ieguvumi:
- Spēja izmantot mākslīgo intelektu, lai izveidotu ietvarus, testus un pārskatītu melnrakstus, pamatojoties uz pārbaudītām bibliotēkām (piemēram, OpenZeppelin), un saprast, ka cilvēki garantē ražošanas drošību
- Spēja pārbaudīt koda versiju, modeli un piekļuves kontroli, ko rada mākslīgais intelekts, izmantojot kompilāciju, testēšanu un testnet
- Spēja atšķirt, ka kompilācija nenozīmē būt drošam un ka testnet un auditēšana ir būtiska.
Viedā līguma rakstīšana atšķiras no parastās programmatūras: jūsu rakstītais kods ir publisks, nemainīgs un programma, kas tieši pārvieto naudu. Šajā nodaļā jūs uzzināsit, kā izmantot AI kā viedo līgumu izstrādes palīgu; Mācīsimies no uzmetuma izgatavošanas līdz testa rakstīšanai, no modeļa atsaukšanas līdz gāzes (darījuma maksas) optimizācijai. Bet būsim skaidrs jau no paša sākuma: AI izstrādā rasējumus; Cilvēki nodrošina drošu kodu, kas tiek nodots ražošanā.
Vispirms zeme: valoda un vide
Visizplatītākā viedo līgumu valoda ir Solidity (Ethereum un EVM valoda — Ethereum virtuālā mašīna, virtuālā mašīna, kurā darbojas līgumi — saderīgas ķēdes). Alternatīva ir Vyper (Python līdzīga valoda, kuras mērķis ir būt ierobežotākai un lasāmākai). Jūsu kods patērē gāzi (katra darījuma izmaksas blokķēdē); Neefektīvs kods ir dārgs. Lai iegūtu precīzu izvadi, ir svarīgi, lai šie termini būtu skaidri saprotami kontekstā, ko sniedzat AI.
AI ir visvērtīgākā nevis “rakstīšana no nulles”, bet gan ietvara + labas formas izveide: standartiem atbilstošs sākums, projekts, kurā pievienot savas zināšanas.
AI izmantošanas slāņi kodēšanā
1. Skeletu ģenerēšana. AI ātri iegūst standarta marķiera (ERC-20) vai NFT (ERC-721 — unikāla digitālā īpašuma standarta) skeletu. Taču noteikti lieciet AI izmantot pārbaudītu bibliotēku: piemēram, OpenZeppelin (kopienas uzticama, pārbaudīta standarta līgumu bibliotēka). Noteikums ir izmantot pārbaudīto bloku, nevis rakstīt drošību no nulles.
2. Funkciju apraksts un apskats. Esošas funkcijas izskaidrošana AI ļauj agri pamanīt loģikas kļūdas.
3. Testa ģenerēšana. AI labi ģenerē pārbaudes gadījumus malas gadījumiem: nulles ievade, ļoti liels skaits, nesankcionēts zvanītājs, atkārtots zvans. Tas atgādina vienu no scenārijiem, ko cilvēks izlaiž.
4. Gāze un lasāmība. AI atzīmē dārgus modeļus, piemēram, nevajadzīgus krātuves ierakstus un iesaka alternatīvas.
Padoms: norādiet AI “Pārrakstīt uz OpenZeppelin pārbaudītajiem līgumiem, pārrakstīt drošību no nulles”. AI ir daudz riskantāk rakstīt oriģinālo drošības kodu nekā izmantot pārbaudītu bibliotēku.
Vāja uzvedne / spēcīga uzvedne
Vāja uzvedne:
Uzrakstiet man simbolisku līgumu.
Šī uzvedne ir bīstama: nav skaidrs, kurš standarts, kura ķēde, kura bibliotēka, kura drošības prasība. AI ģenerē nejaušu, iespējams, novecojušu vai nedrošu kodu.
Spēcīga uzvedne:
Jūsu loma: Solidity vecākais izstrādātājs. Ģenerējiet ERC-20 marķiera uzmetumu ķēdei, kas ir saderīga ar EVM. Noteikumi:- Pamatojoties uz OpenZeppelin auditētajiem ERC20 un Ownable līgumiem.- Skaidri ierakstiet Solidity versijas un licences (SPDX) rindiņu.- Tikai īpašniekam ir atļauja kalt; pievienojiet vāciņu pret bezgalīgu nospiešanu. - Katrai funkcijai pievienojiet NatSpec komentāru. - rakstiet drošību no nulles; Izmantojiet standarta bloku. - Beigās pievienojiet brīdinājumu: "Šis ir melnraksts; ir nepieciešama pārbaude un pārbaude". Atzīmējiet jomas, par kurām neesat pārliecināts, izmantojot // TODO.
Atšķirība: spēcīga uzvedne sniedz skaidru lomu, standartu, bibliotēku, drošības robežu, dokumentācijas un validācijas cerības.
Četras kopējamas veidnes
1) Uz standartiem balstīts skelets:
Jūsu loma: Solidity izstrādātājs. Izveidojiet [ERC-20 / ERC-721 / staking] līguma ietvaru, pamatojoties uz OpenZeppelin auditēto bibliotēku. Uzrakstiet SPDX licenci un pragma versiju. Katrai ārējai funkcijai pievienojiet piekļuves kontroli (kurš var zvanīt). Drošības atjaunošana; Izmantojiet standarta blokus. Šis ir melnraksts.
2) Funkciju apskats:
Pārbaudiet šo funkciju kā vecākais izstrādātājs: ko tā dara, kādus stāvokļus tā maina, kas to var nosaukt? Iespējamās loģikas kļūdas un drošības riskus atzīmējiet kā HIPOTĒZI, katru saistot ar koda rindiņu. Nesakiet "drošs" tieši; vienkārši uzskaitiet uzmanību.
3) Testa scenārija projekts:
Ierosiniet testa gadījumus šim līgumam (varētu būt Foundry/Hardhat projekts). Īpaši aptveriet limita gadījumus: nulles ievade, ļoti liels skaits, nesankcionēts zvans, atkārtots zvans, nepietiekami līdzekļi. Uzrakstiet KO katrs tests apstiprina.
4) Gāzes un lasāmības pārskats:
Šajā līgumā atzīmējiet modeļus, kas var samazināt gāzes izmaksas: nevajadzīga uzglabāšanas rakstīšana, ārējais zvans lokā, atkārtots aprēķins. Izskaidrojiet atšķirību pirms/pēc katrā ieteikumā. Ieteikt drošību pārkāpjošas optimizācijas; Ja tas nav skaidrs, sakiet "jautājiet auditoram".
Trīs mini futrāļi (skaitļos)
1. gadījums — skelets saglabāts 4 stundas. Viena komanda 30 minūšu laikā ieguva revidēta, bibliotēkā balstīta tiesību piešķiršanas līguma skeletu ar AI; Manuāli pagāja ~4 stundas. Komanda veltīja laiku drošībai un testēšanai. Ieguvums tika gūts nevis no drošības nodošanas, bet gan no garlaicīgās sistēmas paātrināšanas.
2. gadījums — novecojušas versijas slazds. AI izveidoja modeli, kas nosūta neapstrādātu ēteri, izmantojot pārsūtīšanu, kas vairs nav ieteicams, jo apmācības dati ir novecojuši. Izstrādātājs to pamanīja un nomainīja to uz pašreizējo uz zvanu balstītu un ar atkārtotu ieeju aizsargātu modeli. Nodarbība: AI bibliotēka/modelis vienmēr tiek apstiprināts kā atjaunināts; AI nezina tālāk par apmācības beigu datumu.
3. gadījums — testa melnraksts atklāja slēpto kļūdu. AI veiktais "neautorizētā zvanītāja" tests atklāja, ka izstrādātājs ir aizmirsis piekļuves kontroli kādā funkcijā. onlyOwner trūkst 1 rindiņas, noķerts 5 minūšu laikā testnetā; Varēja būt zaudēti līdzekļi galvenajā tīklā. Nodarbība: AI testēšanā aptver cilvēka aklo zonu.
Atcerēties drošības modeļus ar AI
AI labi atgādina par zināmiem ievainojamības modeļiem, piemēram, kontrolsarakstu. Visizplatītākie modeļi:
- Atkārtota ienākšana: ārēja zvana veikšana, neatjauninot statusu. Risinājums: čeku-efektu-mijiedarbības kārtība, atgriešanās apsardze.
- Piekļuves kontroles trūkums: ikviens var izsaukt kritisko funkciju.
- Vesela skaitļa pārpilde/nepietiekamība: Modern Solidity uztver lielāko daļu no tiem, taču joprojām pastāv risks zema līmeņa kodā.
- Nepietiekama ievades validācija: nulles adrese, nulles daudzuma kontrole.
- Oracle atkarība: akla uzticēšanās ārējiem datiem (piemēram, cenai).
Uzmanību: AI var atsaukt šo sarakstu, taču tas nevar garantēt, vai sarakstā iekļautais vienums ir jūsu konkrētajā kodā. Kontrolsaraksts ir sākums; Tas neaizstāj konteineru kontroli.
Pareiza konteksta noteikšana: AI laba koda noslēpums
AI radītā koda kvalitāte ir tieši atkarīga no konteksta kvalitātes, ko tam piešķirat. Web3 tas ir īpaši svarīgi, jo viena maza detaļa (kura ķēde, kura Solidity versija, kurš marķiera standarts) maina visu izvadi. Labs konteksts ietver:
- Mērķa ķēde un vide: Ethereum tīkls vai Layer 2 (lētāka sānu ķēde, kas darbojas virs galvenās ķēdes)? Gāzes izmaksas un dažas funkcijas atšķiras atkarībā no ķēdes.
- Versija un bibliotēka: kura Solidity versija, kura OpenZeppelin versija? Ja versija nav norādīta, mākslīgais intelekts var radīt novecojušus, novecojušus modeļus.
- Drošības prasības: vai ir ierobežojums, vai to var apturēt, vai to var palielināt? Tie būtu jāsaka jau pašā sākumā.
- Ierobežojumi: skaidri ierobežojumi, piemēram, "neizmantot montāžu", "izvairieties no ārēja zvana", "optimizējiet gāzi, bet saglabājiet lasāmību".
Vēl viens spēcīgs paņēmiens ir vispirms lūgt AI plānu, pēc tam kodu: "Vispirms uzskaitiet šī līguma funkcijas un to, ko katrs darīs; ierakstiet kodu, kad es to apstiprināšu." Tas agri pieķer AI virzību nepareizā virzienā un ļauj saglabāt arhitektonisko lēmumu.
Padoms: pajautājiet AI "kāpēc jūs uzrakstījāt šo kodu šādi?" jautāt. Pamatojuma izskaidrošana gan paātrinās jūsu mācīšanos, gan parādīs visas loģiskas kļūdas (piemēram, kļūdains drošības pieņēmums). Neuzticieties tāda AI izvadei, kas nevar aizstāvēt savu kodu.
Biežas kļūdas
- Drošības ieviešana AI no nulles. Izmantojiet pārbaudītu bibliotēku.
- Neapstiprina AI izstrādāto versiju/modeli. Apmācības dati var būt veci.
- Testneta apiešana. Katrs melnraksts pirms tiešraides ir jāpalaiž testa tīklā.
- Nepievienojot NatSpec/dokumentāciju. Pārbaude un apkope kļūst sarežģīta.
- "Tas ir apkopots, tāpēc tas ir droši" maldīgs priekšstats. Būt apkopotam nenozīmē būt drošam.
- Aizmirstot piekļuves kontroli. Tā ir viena no visizplatītākajām un dārgākajām kļūdām.
Rezumējot
- Viedajā līgumu rakstīšanā AI izstrādā ietvarus, testus un pārskata projektus; Cilvēks garantē ražošanas drošību.
- Izveidojiet drošību nevis no nulles, bet pamatojoties uz pārbaudītām bibliotēkām (piemēram, OpenZeppelin).
- YZ ražoto versiju un modeļu aktualitāte vienmēr tiek apstiprināta.
- Pārbaudes elementi ir vērtīgi cilvēku aklo zonu fiksēšanai (ierobežojumi, piekļuves kontrole).
- Būt apkopotam nenozīmē būt drošam; testnet un auditēšana ir obligāta.
Lietojumprogrammas uzdevums
Lai iegūtu vienkāršu ERC-20 pilnvaru, ģenerējiet melnrakstu, izmantojot iepriekš norādīto uzvedni uz standartiem. Pēc tam veiciet tālāk norādītās darbības. Atrodiet un atzīmējiet vismaz vienu drošības punktu, kuru AI palaida garām.
kontrolsaraksts
- [ ] Uzvednē esmu skaidri norādījis standartu un ķēdi.
- [ ] Es gribēju pārbaudītu bibliotēku produkciju.
- [ ] Pieejama SPDX licence un pragma versija.
- [ ] Katrai svarīgai funkcijai ir piekļuves kontrole.
- [ ] Es izveidoju un izpildīju limita gadījumu testus.
- [ ] Es apstiprināju, ka bibliotēka/raksts ir atjaunināts.
- [ ] Es atzīmēju kodu auditēšanai un testēšanai; Es to nesaņēmu bez uzraudzības galvenajā tīklā.