Winst:
- Vermogen om kunstmatige intelligentie te gebruiken om raamwerken, tests en review-concepten te produceren op basis van bewezen bibliotheken (bijv. OpenZeppelin) en te begrijpen dat mensen de productieveiligheid garanderen
- Mogelijkheid om de codeversie, het patroon en de toegangscontrole geproduceerd door kunstmatige intelligentie te verifiëren door middel van compilatie, testen en testnet
- Het kunnen onderscheiden van die compilatie betekent niet dat je veilig bent en dat testnet en auditing essentieel zijn.
Het schrijven van een slim contract verschilt van gewone software: de code die je schrijft is openbaar, onveranderlijk en een programma dat rechtstreeks geld verplaatst. In deze unit leer je hoe je AI kunt gebruiken als assistent voor de ontwikkeling van slimme contracten; We zullen leren van de conceptproductie tot het schrijven van tests, van het terugroepen van patronen tot de optimalisatie van gas (transactiekosten). Maar laten we vanaf het begin duidelijk zijn: AI produceert blauwdrukken; Mensen zorgen voor veilige code die in productie gaat.
Eerste punt: taal en omgeving
De meest voorkomende slimme contracttaal is Solidity (de taal van Ethereum en EVM – Ethereum Virtual Machine, de virtuele machine waarop contracten draaien – compatibele ketens). Het alternatief is Vyper (een Python-achtige taal die meer beperkt en leesbaar wil zijn). Uw code verbruikt gas (de kosten van elke transactie naar de blockchain); Inefficiënte code is duur. Het duidelijk houden van deze termen in de context die u aan de AI geeft, is de sleutel tot het verkrijgen van nauwkeurige output.
Waar AI het meest waardevol is, is niet ‘vanaf het begin schrijven’, maar het produceren van het raamwerk + een goede mal: een start die voldoet aan de standaarden, een blauwdruk waaraan u uw expertise kunt toevoegen.
Lagen van het gebruik van AI bij het coderen
1. Skeletten genereren. AI ontgint snel het skelet van een standaardtoken (ERC-20) of NFT (ERC-721 – een unieke standaard voor digitale activa). Maar zorg ervoor dat de AI een beproefde bibliotheek gebruikt: bijvoorbeeld OpenZeppelin (de vertrouwde, gecontroleerde standaardcontractbibliotheek van de gemeenschap). De regel is om het geteste blok te gebruiken in plaats van de beveiliging helemaal opnieuw te schrijven.
2. Functiebeschrijving en beoordeling. Door een bestaande functie aan AI uit te leggen, kun je logische fouten vroegtijdig opsporen.
3. Testgeneratie. AI is goed in het genereren van testgevallen voor randgevallen: nul invoer, zeer groot aantal, ongeautoriseerde beller, herhaalde oproep. Dit doet denken aan de scenario’s die je overslaat.
4. Gas en leesbaarheid. AI signaleert dure patronen, zoals onnodige opslagschrijfbewerkingen, en stelt alternatieven voor.
Tip: geef de AI de opdracht om "voort te bouwen op de gecontroleerde contracten van OpenZeppelin, de beveiliging helemaal opnieuw te schrijven." Het is voor een AI veel riskanter om originele beveiligingscode te schrijven dan een geteste bibliotheek te gebruiken.
Zwakke prompt/sterke prompt
Zwakke prompt:
Schrijf mij een symbolisch contract.
Deze prompt is gevaarlijk: het is niet duidelijk welke standaard, welke keten, welke bibliotheek, welke beveiligingsvereiste. De AI genereert willekeurige, mogelijk verouderde of onveilige code.
Krachtige prompt:
Jouw rol: senior Solidity ontwikkelaar. Genereer een ERC-20-tokenconcept voor een EVM-compatibele keten. Regels: - Gebaseerd op de gecontroleerde ERC20- en Ownable-contracten van OpenZeppelin. - Schrijf de regel Solidity-versie en licentie (SPDX) expliciet. - Alleen de eigenaar heeft toestemming om te minten; voeg een dop toe tegen oneindig drukken. - Voeg NatSpec-commentaar toe aan elke functie. - Schrijf beveiliging vanaf het begin; Gebruik het standaardblok. - Voeg aan het einde een waarschuwing toe: "Dit is een concept; auditing en testen zijn vereist". Markeer de gebieden waar u niet zeker van bent met // TODO.
Verschil: sterke prompt geeft duidelijke rol-, standaard-, bibliotheek-, beveiligingsgrens, documentatie en validatieverwachtingen.
Vier kopieerbare sjablonen
1) Op standaarden gebaseerd skelet:
Jouw rol: Solidity-ontwikkelaar. Genereer een [ERC-20 / ERC-721 / staking]contractraamwerk op basis van de door OpenZeppelin gecontroleerde bibliotheek. Schrijf SPDX-licentie en pragma-versie. Voeg toegangscontrole (wie kan bellen) toe aan elke externe functie. Beveiliging opnieuw uitvinden; Gebruik standaardblokken. Dit is een ontwerp.
2) Functiebeoordeling:
Bestudeer de volgende functie als een senior ontwikkelaar: wat doet het, welke toestanden verandert het, wie kan het noemen? Markeer mogelijke logische fouten en veiligheidsrisico's als HYPOTHESE en koppel ze allemaal aan een regel in de code. Zeg niet ronduit 'veilig'; noem gewoon de aandachtspunten.
3) Concept testscenario:
Testcases voor dit contract voorstellen (kan een concept zijn voor Foundry/Hardhat). Bestrijk specifiek de limietgevallen: nul invoer, zeer groot aantal, ongeautoriseerde oproep, hernieuwde oproep, onvoldoende saldo. Schrijf op WAT elke test bevestigt.
4) Beoordeling van gas en leesbaarheid:
Markeer in dit contract de patronen die de gaskosten kunnen verlagen: onnodig schrijven naar opslag, externe oproep in de lus, repetitieve berekeningen. Leg het voor/na-verschil in elke suggestie uit. Beveiligingsbrekende optimalisaties aanbevelen; Als het niet duidelijk is, zeg dan 'vraag het aan de auditor'.
Drie minikoffers (in aantallen)
Geval 1 — Skelet heeft 4 uur bespaard. Eén team heeft in 30 minuten het skelet van een gecontroleerd bibliotheekgebaseerd verwervingscontract met AI gedolven; Het duurde ~4 uur handmatig. Het team besteedde tijd aan beveiliging en testen. De winst kwam niet voort uit het overdragen van de beveiliging, maar uit het versnellen van het vervelende raamwerk.
Geval 2 – Verouderde versieval. De AI produceerde een patroon dat ruwe Ether via overdracht verstuurt, wat niet langer wordt aanbevolen omdat de trainingsgegevens verouderd zijn. De ontwikkelaar merkte dit op en veranderde het in het huidige op oproepen gebaseerde en herintredingsbeveiligde patroon. Les: Er wordt altijd bevestigd dat de bibliotheek/het patroon van de AI up-to-date is; AI weet het niet na de sluitingsdatum van de training.
Geval 3 — Testconcept bracht een verborgen bug naar voren. Uit de ‘unauthorized caller’-test die de AI produceerde bleek dat de ontwikkelaar de toegangscontrole in een functie was vergeten. onlyOwner mist 1 regel, betrapt in 5 minuten op testnet; Er zou sprake kunnen zijn van geldverlies op het mainnet. Les: AI bedekt de menselijke blinde vlek bij het testen.
Beveiligingspatronen onthouden met AI
AI is goed in het herinneren aan bekende kwetsbaarheidspatronen, zoals een checklist. De meest voorkomende patronen:
- Opnieuw binnenkomen: een extern gesprek voeren zonder de status bij te werken. Oplossing: volgorde van controles-effecten-interacties, herintredingswacht.
- Gebrek aan toegangscontrole: iedereen kan de kritieke functie oproepen.
- Overflow/underfall van gehele getallen: Modern Solidity vangt de meeste van deze problemen op, maar is nog steeds een risico in code op laag niveau.
- Ontoereikende invoervalidatie: nuladres, nulhoeveelheidscontrole.
- Oracle-afhankelijkheid: blind vertrouwen in externe gegevens (zoals prijs).
Let op: AI kan deze lijst oproepen, maar kan niet garanderen of een item in de lijst in uw specifieke code voorkomt. De checklist is een begin; Het is geen vervanging voor containercontrole.
De juiste context krijgen: het geheim van goede code van AI
De kwaliteit van de code die de AI produceert, hangt rechtstreeks af van de kwaliteit van de context die je eraan geeft. In Web3 is dit vooral van cruciaal belang omdat één klein detail (welke keten, welke Solidity-versie, welke tokenstandaard) de hele uitvoer verandert. Een goede context omvat:
- Doelketen en omgeving: Ethereum-mainnet of een Layer 2 (goedkopere sidechain die bovenop de mainchain draait)? De gaskosten en sommige kenmerken variëren per keten.
- Versie en bibliotheek: Welke Solidity-versie, welke OpenZeppelin-versie? Als er geen versie is opgegeven, kan AI verouderde, verouderde patronen produceren.
- Beveiligingseisen: Is er een limiet, kan deze worden gepauzeerd, kan deze worden verhoogd? Deze moeten vanaf het allereerste begin worden gezegd.
- Beperkingen: duidelijke limieten zoals "gebruik geen montage", "vermijd extern bellen", "optimaliseer gas maar behoud de leesbaarheid".
Een andere krachtige techniek is om de AI eerst om het plan te vragen en vervolgens om de code: "Maak eerst een lijst van de functies van dit contract en wat elk contract zal doen; schrijf de code zodra ik deze goedkeur." Hierdoor wordt vroegtijdig opgemerkt dat de AI de verkeerde kant op gaat en kun je de architecturale beslissing behouden.
Tip: Vraag de AI "waarom heb je deze code zo geschreven?" vragen. Het uitleggen van de grondgedachte zal zowel uw leerproces versnellen als eventuele logische fouten aan de oppervlakte brengen (bijvoorbeeld een valse veiligheidsaanname). Vertrouw niet op de uitvoer van een AI die zijn eigen code niet kan verdedigen.
Veel voorkomende fouten
- Beveiliging vanaf het begin in AI aanbrengen. Gebruik een geteste bibliotheek.
- Het niet bevestigen van de versie/het patroon geproduceerd door de AI. Trainingsgegevens kunnen oud zijn.
- Testnet omzeilen. Elk concept moet op het testnetwerk worden uitgevoerd voordat het live gaat.
- Geen NatSpec/documentatie toegevoegd. Inspectie en onderhoud worden lastig.
- "Het is samengesteld, dus het is veilig", misvatting. Gecompileerd zijn betekent niet dat u veilig bent.
- Toegangscontrole vergeten. Het is een van de meest voorkomende en dure fouten.
Samengevat
- Bij het schrijven van slimme contracten produceert AI raamwerken, tests en beoordelingsconcepten; De mens garandeert de productieveiligheid.
- Bouw beveiliging niet vanaf het begin, maar op basis van beproefde bibliotheken (bijvoorbeeld OpenZeppelin).
- De actualiteit van de door YZ geproduceerde versies en patronen wordt altijd bevestigd.
- Teststrookjes zijn waardevol bij het vastleggen van menselijke blinde vlekken (limietgevallen, toegangscontrole).
- Gecompileerd zijn betekent niet dat u veilig bent; testnet en auditing zijn een must.
Applicatie taak
Voor een eenvoudig ERC-20-token genereert u een concept met behulp van de bovenstaande prompt "op standaarden gebaseerd skelet". Vervolgens: (1) controleer of er een gecontroleerde bibliotheek wordt gebruikt, (2) controleer de toegangscontroles, (3) genereer tests met de "test case draft"-prompt en voer daadwerkelijk ten minste één rogue-caller-test uit. Zoek en noteer ten minste één beveiligingspunt dat de AI heeft gemist.
controlelijst
- [ ] Ik heb de standaard en keten duidelijk vermeld in de prompt.
- [ ] Ik wilde een bewezen bibliotheekgebaseerde productie.
- [ ] SPDX-licentie en pragma-versie beschikbaar.
- [ ] In elke kritische functie is toegangscontrole aanwezig.
- [ ] Ik heb tests gemaakt en uitgevoerd voor limietgevallen.
- [ ] Ik heb bevestigd dat de bibliotheek/het patroon up-to-date is.
- [ ] Ik heb de code gemarkeerd voor auditing en testen; Ik heb het niet zonder toezicht op Mainnet gekregen.