Gevinster:
- Evne til at bruge kunstig intelligens til at producere rammer, test og gennemgå udkast baseret på dokumenterede biblioteker (f.eks. OpenZeppelin) og forstå, at mennesker garanterer produktionssikkerhed
- Evne til at verificere kodeversion, mønster og adgangskontrol produceret af kunstig intelligens gennem kompilering, test og testnet
- At kunne skelne denne kompilering betyder ikke at være sikker, og at testnet og auditering er afgørende.
At skrive en smart kontrakt er anderledes end almindelig software: Den kode, du skriver, er offentlig, uforanderlig og et program, der direkte flytter penge. I denne enhed lærer du, hvordan du bruger kunstig intelligens som en smart kontraktudviklingsassistent; Vi vil lære fra kladdeproduktion til testskrivning, fra mønstergenkaldelse til optimering af gas (transaktionsgebyr). Men lad os være klare fra starten: AI producerer tegninger; Mennesker sikrer sikker kode, der går i produktion.
Grunden først: sprog og miljø
Det mest almindelige smarte kontraktsprog er Solidity (sproget i Ethereum og EVM - Ethereum Virtual Machine, den virtuelle maskine, som kontrakterne kører på - kompatible kæder). Alternativet er Vyper (et Python-lignende sprog, der sigter mod at være mere begrænset og læsbart). Din kode bruger gas (omkostningerne for hver transaktion til blockchain); Ineffektiv kode er dyr. At holde disse udtryk klare i den kontekst, du giver dem til AI, er nøglen til at få nøjagtigt output.
Hvor AI er mest værdifuldt, er ikke i at "skrive fra bunden", men i at producere rammen + god form: en standard-kompatibel start, en plan, som du kan tilføje din ekspertise til.
Lag af brug af AI i kodning
1. Generering af skeletter. AI miner hurtigt skelettet af en standard token (ERC-20) eller NFT (ERC-721 - en unik digital aktivstandard). Men sørg for at få AI til at bruge et gennemprøvet bibliotek: for eksempel OpenZeppelin (fællesskabets betroede, reviderede standardkontraktbibliotek). Reglen er at bruge den testede blok i stedet for at skrive sikkerhed fra bunden.
2. Funktionsbeskrivelse og gennemgang. Ved at forklare en eksisterende funktion til AI kan du opdage logiske fejl tidligt.
3. Testgenerering. AI er god til at generere testcases for edge cases: nul input, meget stort antal, uautoriseret opkald, gentagne opkald. Dette minder et om de scenarier, man springer over.
4. Gas og læsbarhed. AI markerer dyre mønstre såsom unødvendige lagerskrivninger og foreslår alternativer.
Tip: Instruer AI om at "Bygge på OpenZeppelins reviderede kontrakter, omskrive sikkerhed fra bunden." Det er meget mere risikabelt for en AI at skrive original sikkerhedskode end at bruge et testet bibliotek.
Svag prompt / Stærk prompt
Svag prompt:
Skriv en symbolsk kontrakt til mig.
Denne prompt er farlig: det er ikke klart, hvilken standard, hvilken kæde, hvilket bibliotek, hvilket sikkerhedskrav. AI'en genererer tilfældig, muligvis forældet eller usikker kode.
Kraftig prompt:
Din rolle: Senior Solidity-udvikler. Generer et ERC-20-tokenudkast til en EVM-kompatibel kæde. Regler:- Baseret på OpenZeppelins reviderede ERC20 og Ownable-kontrakter.- Skriv Solidity-versionen og licenslinjen (SPDX) eksplicit.- Kun ejeren har tilladelse til at præge; tilføje en hætte mod uendelig presning. - Tilføj NatSpec-kommentar til hver funktion. - Skriv sikkerhed fra bunden; Brug standardblokken. - Tilføj en advarsel til sidst: "Dette er et udkast; revision og test er påkrævet". Marker de områder, du ikke er sikker på, med // TODO.
Forskel: stærk prompt giver klare forventninger til rolle, standard, bibliotek, sikkerhedsgrænse, dokumentation og validering.
Fire kopierbare skabeloner
1) Standardbaseret skelet:
Din rolle: Soliditetsudvikler. Generer [ERC-20 / ERC-721 / staking]kontraktramme baseret på OpenZeppelin-reviderede bibliotek. Skriv SPDX-licens og pragmaversion. Tilføj adgangskontrol (hvem kan ringe) til hver ekstern funktion. Genopfinde sikkerhed; Brug standardblokke. Dette er et udkast.
2) Funktionsgennemgang:
Undersøg følgende funktion som en seniorudvikler: hvad gør den, hvilke tilstande ændrer den, hvem kan kalde den? Marker mulige logiske fejl og sikkerhedsrisici som HYPOTESE, og kæde hver enkelt til en linje i koden. Sig ikke "sikker" direkte; bare opregn opmærksomhedspunkterne.
3) Testscenarieudkast:
Foreslå testcases for denne kontrakt (kan være et udkast til Foundry/Hardhat). Dæk specifikt grænsetilfælde: nul input, meget stort antal, uautoriseret opkald, reentrant-opkald, utilstrækkelige midler. Skriv HVAD hver test bekræfter.
4) Gennemgang af gas og læsbarhed:
I denne kontrakt skal du markere de mønstre, der kan reducere gasomkostningerne: unødvendig lagerskrivning, eksternt opkald i løkken, gentagne beregninger. Forklar før/efter forskellen i hvert forslag. Anbefal sikkerhedsbryderende optimeringer; Hvis det ikke er klart, så sig "spørg revisoren".
Tre minisager (i antal)
Case 1 - Skelet sparet 4 timer. Et hold udvindede skelettet af en revideret biblioteksbaseret optjeningskontrakt med AI på 30 minutter; Det tog ~4 timer manuelt. Holdet brugte tid på sikkerhed og test. Gevinsten kom ikke fra at overføre sikkerhed, men fra at fremskynde de kedelige rammer.
Tilfælde 2 — Forældet version fælde. AI producerede et mønster, der sender rå Ether ved overførsel, hvilket ikke længere anbefales, fordi træningsdataene er forældede. Udvikleren bemærkede dette og ændrede det til det nuværende opkaldsbaserede og reentrancy-beskyttede mønster. Lektion: AI's bibliotek/mønster er altid bekræftet at være opdateret; AI kender ikke længere end træningsdatoen.
Tilfælde 3 - Testudkast poppet skjult fejl. Den "uautoriserede opkalds"-test, som AI producerede, afslørede, at udvikleren havde glemt adgangskontrol i en funktion. eneste ejer mangler 1 linje, fanget på 5 minutter på testnet; Der kunne have været et tab af midler på mainnettet. Lektion: AI dækker den menneskelige blinde vinkel i test.
Husk sikkerhedsmønstre med AI
AI er god til at minde dig om kendte sårbarhedsmønstre som en tjekliste. De mest almindelige mønstre:
- Reentrancy: Foretage et eksternt opkald uden at opdatere status. Løsning: checks-effects-interactions order, reentrancy guard.
- Manglende adgangskontrol: Alle kan kalde den kritiske funktion.
- Heltalsoverløb/underfald: Modern Solidity fanger de fleste af dem, men stadig en risiko i lav-niveau kode.
- Utilstrækkelig inputvalidering: Nul adresse, nul mængdekontrol.
- Oracle-afhængighed: Blind tillid til eksterne data (såsom pris).
Bemærk: AI kan genkalde denne liste, men den kan ikke garantere, om et element på listen er i din specifikke kode. Tjeklisten er en start; Det er ikke en erstatning for containerkontrol.
Få konteksten rigtig: Hemmeligheden bag god kode fra AI
Kvaliteten af den kode, AI producerer, afhænger direkte af kvaliteten af den kontekst, du giver den. I Web3 er dette især kritisk, fordi en lille detalje (hvilken kæde, hvilken Solidity-version, hvilken token-standard) ændrer hele outputtet. En god kontekst omfatter:
- Målkæde og miljø: Ethereum mainnet eller et Layer 2 (billigere sidechain, der løber oven på mainchain)? Gasomkostninger og nogle funktioner varierer efter kæde.
- Version og bibliotek: Hvilken Solidity-version, hvilken OpenZeppelin-version? Hvis der ikke er angivet nogen version, kan AI producere forældede, forældede mønstre.
- Sikkerhedskrav: Er der et loft, kan det sættes på pause, kan det øges? Disse skal siges fra begyndelsen.
- Begrænsninger: Klare grænser som "brug ikke samling", "undgå eksternt opkald", "optimer gas, men bevar læsbarheden".
En anden kraftfuld teknik er at bede AI om planen først, derefter koden: "Først liste over funktionerne i denne kontrakt, og hvad hver vil gøre; skriv koden, når jeg godkender den." Dette fanger AI i at gå i den forkerte retning tidligt og giver dig mulighed for at bevare den arkitektoniske beslutning.
Tip: Spørg AI'en "hvorfor skrev du denne kode sådan?" spørge. Forklaring af begrundelsen vil både fremskynde din læring og bringe eventuelle logiske fejl til overfladen (f.eks. en falsk sikkerhedsantagelse). Stol ikke på outputtet fra en AI, der ikke kan forsvare sin egen kode.
Almindelige fejl
- Sætte sikkerhed i AI fra bunden. Brug et testet bibliotek.
- Bekræfter ikke versionen/mønsteret produceret af AI. Træningsdata kan være gamle.
- Omgå testnet. Hvert udkast skal køre på testnetværket, før det går live.
- Tilføjer ikke NatSpec/dokumentation. Eftersyn og vedligeholdelse bliver vanskeligt.
- "Det er kompileret, så det er sikkert" misforståelse. At blive kompileret betyder ikke at være sikker.
- Glemte adgangskontrol. Det er en af de mest almindelige og dyre fejl.
Sammenfattende
- I smart kontraktskrivning producerer AI rammer, tests og gennemgangsudkast; Human garanterer produktionssikkerhed.
- Byg sikkerhed ikke fra bunden, men baseret på dokumenterede biblioteker (f.eks. OpenZeppelin).
- Ajourføringen af versioner og mønstre produceret af YZ er altid bekræftet.
- Teststubber er værdifulde til at fange menneskelige blinde vinkler (grænsetilfælde, adgangskontrol).
- At blive kompileret betyder ikke at være sikker; testnet og revision er et must.
Ansøgningsopgave
For et simpelt ERC-20-token skal du generere et udkast ved hjælp af "standardbaseret skelet"-prompten ovenfor. Derefter: (1) kontroller, om den bruger et kontrolleret bibliotek, (2) kontroller adgangskontrollerne, (3) generer tests med prompten "testcase draft" og kør faktisk mindst én rogue-caller-test. Find og noter mindst ét sikkerhedspunkt, som AI’en gik glip af.
tjekliste
- [ ] Jeg har tydeligt angivet standarden og kæden i prompten.
- [ ] Jeg ville have dokumenteret biblioteksbaseret produktion.
- [ ] SPDX-licens og pragmaversion tilgængelig.
- [ ] Der er adgangskontrol i enhver kritisk funktion.
- [ ] Jeg oprettede og kørte test for grænsetilfælde.
- [ ] Jeg bekræftede, at biblioteket/mønsteret er opdateret.
- [ ] Jeg markerede koden for revision og test; Jeg fik det ikke uden opsyn på mainnet.