Gevinster:
- Evne til å bruke kunstig intelligens til å produsere rammeverk, tester og gjennomgå utkast basert på dokumenterte biblioteker (f.eks. OpenZeppelin) og forstå at mennesker garanterer produksjonssikkerhet
- Evne til å verifisere kodeversjon, mønster og tilgangskontroll produsert av kunstig intelligens gjennom kompilering, testing og testnett
- Å kunne skille at kompilering betyr ikke at man er sikker og at testnett og revisjon er avgjørende.
Å skrive en smart kontrakt er forskjellig fra vanlig programvare: koden du skriver er offentlig, uforanderlig og et program som direkte flytter penger. I denne enheten lærer du hvordan du bruker AI som en smart kontraktutviklingsassistent; Vi vil lære fra utkastproduksjon til testskriving, fra mønstergjenkalling til gass (transaksjonsgebyr) optimalisering. Men la oss være klare fra starten: AI produserer tegninger; Mennesker sørger for sikker kode som går i produksjon.
Bakgrunn først: språk og miljø
Det vanligste smarte kontraktsspråket er Solidity (språket til Ethereum og EVM — Ethereum Virtual Machine, den virtuelle maskinen som kontrakter kjøres på — kompatible kjeder). Alternativet er Vyper (et Python-lignende språk som har som mål å være mer begrenset og lesbart). Koden din bruker gass (kostnaden for hver transaksjon til blokkjeden); Ineffektiv kode er dyrt. Å holde disse begrepene klare i konteksten du gir dem til AI er nøkkelen til å få nøyaktig utgang.
Der AI er mest verdifullt er ikke i å "skrive fra bunnen av", men i å produsere rammeverket + god form: en standard-kompatibel start, en plan for å legge til ekspertisen din.
Lag med bruk av AI i koding
1. Generering av skjeletter. AI miner raskt skjelettet til en standard token (ERC-20) eller NFT (ERC-721 – en unik standard for digitale aktiva). Men sørg for å få AI til å bruke et velprøvd bibliotek: for eksempel OpenZeppelin (fellesskapets pålitelige, reviderte standard kontraktsbibliotek). Regelen er å bruke den testede blokken i stedet for å skrive sikkerhet fra bunnen av.
2. Funksjonsbeskrivelse og gjennomgang. Ved å forklare en eksisterende funksjon til AI kan du oppdage logiske feil tidlig.
3. Testgenerering. AI er flink til å generere testtilfeller for edge-tilfeller: null inngang, veldig stort antall, uautorisert oppringer, gjentatt anrop. Dette minner en om scenariene man hopper over.
4. Gass og lesbarhet. AI flagger dyre mønstre som unødvendige lagringsskrivinger og foreslår alternativer.
Hint: Instruer AI om å "bygge på OpenZeppelins reviderte kontrakter, omskrive sikkerhet fra bunnen av." Det er mye mer risikabelt for en AI å skrive original sikkerhetskode enn å bruke et testet bibliotek.
Svak forespørsel / Sterk forespørsel
Svak melding:
Skriv meg en symbolsk kontrakt.
Denne meldingen er farlig: det er ikke klart hvilken standard, hvilken kjede, hvilket bibliotek, hvilket sikkerhetskrav. AI genererer tilfeldig, muligens utdatert eller usikker kode.
Kraftig ledetekst:
Din rolle: senior Solidity-utvikler. Generer et ERC-20-tokenutkast for en EVM-kompatibel kjede. Regler:- Basert på OpenZeppelins reviderte ERC20 og Ownable-kontrakter.- Skriv Solidity-versjonen og lisenslinjen (SPDX) eksplisitt.- Bare eieren har tillatelse til å prege; legg til en hette mot uendelig pressing. - Legg til NatSpec-kommentar til hver funksjon. - Skriv sikkerhet fra bunnen av; Bruk standardblokken. - Legg til en advarsel på slutten: "Dette er et utkast; revisjon og testing er nødvendig". Merk områdene du ikke er sikker på med // TODO.
Forskjell: sterk forespørsel gir klare forventninger om rolle, standard, bibliotek, sikkerhetsgrense, dokumentasjon og validering.
Fire kopierbare maler
1) Standardbasert skjelett:
Din rolle: Soliditetsutvikler. Generer [ERC-20 / ERC-721 / staking]kontraktsramme basert på OpenZeppelin reviderte bibliotek. Skriv SPDX-lisens og pragmaversjon. Legg til tilgangskontroll (hvem kan ringe) til hver ekstern funksjon. Gjenoppfinne sikkerhet; Bruk standardblokker. Dette er et utkast.
2) Funksjonsgjennomgang:
Undersøk følgende funksjon som en seniorutvikler: hva gjør den, hvilke tilstander endrer den, hvem kan kalle den? Merk mulige logiske feil og sikkerhetsrisikoer som HYPOTESE, og koble hver til en linje i koden. Ikke si "trygt" rett ut; bare oppgi oppmerksomhetspunktene.
3) Testscenarioutkast:
Foreslå testcases for denne kontrakten (kan være et utkast for Foundry/Hardhat). Dekker spesifikt grensetilfeller: null inndata, veldig stort antall, uautorisert anrop, reentrant-anrop, utilstrekkelig midler. Skriv HVA hver test bekrefter.
4) Gjennomgang av gass og lesbarhet:
Marker i denne kontrakten mønstrene som kan redusere gasskostnadene: unødvendig lagringsskriving, eksternt anrop i sløyfen, repeterende beregning. Forklar før/etter-forskjellen i hvert forslag. Anbefal sikkerhetsbrytende optimaliseringer; Hvis det ikke er klart, si "spør revisor".
Tre minietuier (i antall)
Tilfelle 1 - Skjelett spart 4 timer. Ett team gruvede skjelettet til en revidert bibliotekbasert opptjeningskontrakt med AI på 30 minutter; Det tok ~4 timer manuelt. Teamet viet tid til sikkerhet og testing. Gevinsten kom ikke fra å overføre sikkerhet, men fra å fremskynde det kjedelige rammeverket.
Tilfelle 2 — Utdatert versjonsfelle. AI produserte et mønster som sender rå Ether ved overføring, som ikke lenger anbefales fordi treningsdataene er utdaterte. Utvikleren la merke til dette og endret det til det nåværende anropsbaserte og reentrancy-beskyttede mønsteret. Leksjon: AI-biblioteket/-mønsteret er alltid bekreftet å være oppdatert; AI vet ikke utover treningsavbruddsdatoen.
Tilfelle 3 - Testutkast dukket skjult feil. "Uautorisert oppringer"-testen som AI produserte avslørte at utvikleren hadde glemt tilgangskontroll i en funksjon. eneste eier mangler 1 linje, fanget på 5 minutter på testnettet; Det kunne ha vært tap av midler på hovednettet. Leksjon: AI dekker menneskelig blindsone i testing.
Husk sikkerhetsmønstre med AI
AI er flink til å minne deg om kjente sårbarhetsmønstre som en sjekkliste. De vanligste mønstrene:
- Reentrancy: Foreta et eksternt anrop uten å oppdatere statusen. Løsning: sjekk-effekter-interaksjonsordre, reentrancy guard.
- Mangel på tilgangskontroll: Hvem som helst kan ringe den kritiske funksjonen.
- Heltallsoverløp/underfall: Modern Solidity fanger de fleste av dem, men fortsatt en risiko i lavnivåkode.
- Utilstrekkelig inndatavalidering: Null adresse, null mengdekontroll.
- Oracle-avhengighet: Blind tillit til eksterne data (som pris).
OBS: AI kan huske denne listen, men den kan ikke garantere om et element på listen er i din spesifikke kode. Sjekklisten er en start; Det er ikke en erstatning for containerkontroll.
Få konteksten riktig: Hemmeligheten bak god kode fra AI
Kvaliteten på koden AI produserer avhenger direkte av kvaliteten på konteksten du gir den. I Web3 er dette spesielt kritisk fordi en liten detalj (hvilken kjede, hvilken Solidity-versjon, hvilken token-standard) endrer hele utgangen. En god kontekst inkluderer:
- Målkjede og miljø: Ethereum-nettverk eller et Layer 2 (billigere sidekjede som går på toppen av hovedkjeden)? Gasskostnad og enkelte funksjoner varierer fra kjede.
- Versjon og bibliotek: Hvilken Solidity-versjon, hvilken OpenZeppelin-versjon? Hvis ingen versjon er spesifisert, kan AI produsere utdaterte, utdaterte mønstre.
- Sikkerhetskrav: Er det et tak, kan det settes på pause, kan det økes? Disse bør sies helt fra begynnelsen.
- Begrensninger: Tydelige grenser som "ikke bruk montering", "unngå eksternt anrop", "optimalisere gass, men opprettholde lesbarheten".
En annen kraftig teknikk er å spørre AI om planen først, deretter koden: "Først liste opp funksjonene til denne kontrakten og hva hver av dem vil gjøre; skriv koden når jeg godkjenner den." Dette fanger opp AI som går i feil retning tidlig og lar deg beholde den arkitektoniske avgjørelsen.
Hint: Spør AI-en "hvorfor skrev du denne koden slik?" spørre. Å forklare begrunnelsen vil både øke hastigheten på læringen din og bringe til overflaten eventuelle logiske feil (f.eks. en falsk sikkerhetsantagelse). Ikke stol på utdataene til en AI som ikke kan forsvare sin egen kode.
Vanlige feil
- Setter sikkerhet i AI fra bunnen av. Bruk et testet bibliotek.
- Bekrefter ikke versjonen/mønsteret produsert av AI. Treningsdata kan være gamle.
- Omgå testnett. Hvert utkast bør kjøres på testnettverket før det publiseres.
- Legger ikke til NatSpec/dokumentasjon. Inspeksjon og vedlikehold blir vanskelig.
- "Det er kompilert, så det er trygt" misforståelse. Å bli kompilert betyr ikke å være trygg.
- Glem tilgangskontroll. Det er en av de vanligste og mest kostbare feilene.
Oppsummert
- I smart kontraktskriving produserer AI rammer, tester og gjennomgangsutkast; Mennesket garanterer produksjonssikkerhet.
- Bygg sikkerhet ikke fra bunnen av, men basert på dokumenterte biblioteker (f.eks. OpenZeppelin).
- Oppdateringen av versjonene og mønstrene produsert av YZ er alltid bekreftet.
- Teststubber er verdifulle for å fange menneskelige blindsoner (limit cases, adgangskontroll).
- Å bli kompilert betyr ikke å være trygg; testnett og revisjon er et must.
Søknadsoppgave
For et enkelt ERC-20-token, generer et utkast ved å bruke "standardbasert skjelett"-prompten ovenfor. Deretter: (1) sjekk om den bruker et sjekket bibliotek, (2) sjekk tilgangskontrollene, (3) generer tester med "testcase draft"-ledeteksten og kjør faktisk minst én rogue-call-test. Finn og legg merke til minst ett sikkerhetspunkt som AI-en gikk glipp av.
sjekkliste
- [ ] Jeg har tydelig angitt standard og kjede i ledeteksten.
- [ ] Jeg ville ha bevist bibliotekbasert produksjon.
- [ ] SPDX-lisens og pragmaversjon tilgjengelig.
- [ ] Det er tilgangskontroll i alle kritiske funksjoner.
- [ ] Jeg opprettet og kjørte tester for grensetilfeller.
- [ ] Jeg bekreftet at biblioteket/mønsteret er oppdatert.
- [ ] Jeg merket koden for revisjon og testing; Jeg fikk det ikke uten tilsyn på mainnet.