zisky:
- Schopnost používat umělou inteligenci k vytváření rámců, testů a revizních návrhů na základě osvědčených knihoven (např. OpenZeppelin) a pochopení, že lidé zaručují bezpečnost výroby
- Schopnost ověřit verzi kódu, vzor a řízení přístupu vytvořené umělou inteligencí prostřednictvím kompilace, testování a testovací sítě
- Umět rozlišit, že kompilace neznamená být zabezpečená a že testnet a auditování jsou zásadní.
Psaní chytré smlouvy se liší od běžného softwaru: kód, který píšete, je veřejný, neměnný a jde o program, který přímo přesouvá peníze. V této lekci se naučíte používat umělou inteligenci jako inteligentního asistenta pro rozvoj smluv; Naučíme se od výroby návrhu po psaní testů, od stažení vzoru po optimalizaci plynu (transakční poplatek). Ale aby bylo jasno hned od začátku: AI produkuje plány; Lidé zajišťují bezpečný kód, který jde do výroby.
První bod: jazyk a prostředí
Nejběžnějším jazykem chytrých kontraktů je Solidity (jazyk Etherea a EVM — Ethereum Virtual Machine, virtuálního stroje, na kterém smlouvy běží — kompatibilní řetězce). Alternativou je Vyper (jazyk podobný Pythonu, jehož cílem je být omezenější a čitelnější). Váš kód spotřebovává plyn (náklady na každou transakci do blockchainu); Neefektivní kód je drahý. Klíčem k získání přesného výstupu je zachování těchto výrazů jasných v kontextu, který je dáte AI.
Umělá inteligence není nejcennější v „psaní od nuly“, ale ve vytváření rámce + dobré formy: začátek v souladu se standardy, plán, do kterého můžete přidat své odborné znalosti.
Vrstvy použití AI v kódování
1. Generování koster. Umělá inteligence rychle vydoluje kostru standardního tokenu (ERC-20) nebo NFT (ERC-721 – jedinečný standard digitálních aktiv). Ujistěte se však, že umělá inteligence používá osvědčenou knihovnu: například OpenZeppelin (důvěryhodná a auditovaná standardní smluvní knihovna komunity). Pravidlem je použít testovaný blok spíše než psát zabezpečení od začátku.
2. Popis a přehled funkcí. Vysvětlení existující funkce AI vám umožní včas odhalit logické chyby.
3. Generování testu. Umělá inteligence je dobrá při generování testovacích případů pro okrajové případy: nulový vstup, velmi velký počet, neoprávněný volající, opakované volání. To připomíná jeden ze scénářů, které člověk přeskočí.
4. Plyn a čitelnost. Umělá inteligence označuje drahé vzory, jako jsou zbytečné zápisy do úložiště, a navrhuje alternativy.
Tip: Instruujte AI, aby „Stavěte na auditovaných smlouvách OpenZeppelin, přepište zabezpečení od nuly“. Pro umělou inteligenci je mnohem riskantnější napsat originální bezpečnostní kód než používat testovanou knihovnu.
Slabá výzva / Silná výzva
Slabá výzva:
Napište mi symbolickou smlouvu.
Tato výzva je nebezpečná: není jasné, který standard, který řetězec, která knihovna, který požadavek na zabezpečení. AI generuje náhodný, možná zastaralý nebo nezabezpečený kód.
Výkonná výzva:
Vaše role: senior vývojář Solidity. Vygenerujte návrh tokenu ERC-20 pro řetězec kompatibilní s EVM. Pravidla:- Na základě auditovaných smluv OpenZeppelin ERC20 a Ownable.- Napište explicitně řádek Solidity verze a licence (SPDX).- Pouze vlastník má povolení razit; přidat uzávěr proti nekonečnému lisování. - Ke každé funkci přidejte komentář NatSpec. - Zabezpečení zápisu od nuly; Použijte standardní blok. - Na konec přidejte upozornění: „Toto je návrh; je vyžadován audit a testování“. Označte oblasti, kterými si nejste jisti, pomocí // TODO.
Rozdíl: silná výzva dává jasnou roli, standard, knihovnu, bezpečnostní hranici, dokumentaci a očekávání ověření.
Čtyři kopírovatelné šablony
1) Kostra založená na standardech:
Vaše role: Vývojář Solidity. Vygenerujte [ERC-20 / ERC-721 / staking] smluvní rámec založený na auditované knihovně OpenZeppelin. Napište SPDX licenci a pragma verzi. Ke každé externí funkci přidejte řízení přístupu (kdo může volat). Znovuobjevení bezpečnosti; Použijte standardní bloky. Toto je návrh.
2) Kontrola funkce:
Prozkoumejte následující funkci jako starší vývojář: co dělá, jaké stavy mění, kdo ji může volat? Označte možné logické chyby a bezpečnostní rizika jako HYPOTÉZU, každou propojte s řádkem v kódu. Neříkejte „bezpečné“ přímo; stačí uvést body pozornosti.
3) Návrh testovacího scénáře:
Navrhněte testovací případy pro tuto smlouvu (může to být návrh pro Foundry/Hardhat). Konkrétně pokrýt limitní případy: nulový vstup, velmi vysoký počet, neautorizované volání, opakované volání, nedostatek finančních prostředků. Napište CO každý test potvrzuje.
4) Kontrola plynu a čitelnosti:
V této smlouvě označte vzory, které mohou snížit náklady na plyn: zbytečné zápisy do úložiště, externí volání ve smyčce, opakované výpočty. Vysvětlete rozdíl před/po v každém návrhu. Doporučit optimalizace narušující zabezpečení; Pokud to není jasné, řekněte „zeptejte se auditora“.
Tři mini pouzdra (v číslech)
Případ 1 – Kostra ušetřena 4 hodiny. Jeden tým vytěžil kostru auditované smlouvy s AI založené na knihovnách za 30 minut; Ručně to trvalo ~4 hodiny. Tým věnoval čas bezpečnosti a testování. Zisk nepocházel z přenosu zabezpečení, ale z urychlení únavného rámce.
Případ 2 – Zastaralá verze pasti. Umělá inteligence vytvořila vzor, který posílá surový ether přenosem, což se již nedoporučuje, protože trénovací data jsou zastaralá. Vývojář si toho všiml a změnil to na aktuální vzor založený na volání a chráněný proti opětovnému vstupu. Lekce: Knihovna/vzor AI je vždy potvrzena jako aktuální; Umělá inteligence po datu ukončení školení neví.
Případ 3 – Testovací návrh objevil skrytou chybu. Test „neoprávněného volajícího“, který vytvořila AI, odhalil, že vývojář zapomněl řízení přístupu ve funkci. onlyOwner chybí 1 řádek, chyceno za 5 minut na testnetu; Mohlo dojít ke ztrátě prostředků na mainnetu. Lekce: Umělá inteligence při testování pokrývá lidský slepý úhel.
Pamatování bezpečnostních vzorů pomocí AI
Umělá inteligence vám dobře připomene známé vzorce zranitelnosti jako kontrolní seznam. Nejběžnější vzory:
- Reentrancy: Uskutečnění externího hovoru bez aktualizace stavu. Řešení: kontrola-efekty-pořadí interakcí, reentrancy guard.
- Nedostatek kontroly přístupu: Kdokoli může zavolat kritickou funkci.
- Integer overflow/underfall: Modern Solidity zachytí většinu z nich, ale stále je to riziko v nízkoúrovňovém kódu.
- Nedostatečné ověření vstupu: Nulová adresa, kontrola nulového množství.
- Závislost na Oracle: Slepá důvěra v externí data (jako je cena).
Pozor: AI si může tento seznam vyvolat, ale nemůže zaručit, zda je položka v seznamu ve vašem specifickém kódu. Kontrolní seznam je začátek; Nenahrazuje ovládání kontejnerů.
Správný kontext: Tajemství dobrého kódu z AI
Kvalita kódu, který AI vytváří, závisí přímo na kvalitě kontextu, který mu dáte. Ve Web3 je to obzvláště důležité, protože jeden malý detail (který řetězec, která verze Solidity, který standard tokenu) mění celý výstup. Dobrý kontext zahrnuje:
- Cílový řetězec a prostředí: Ethereum mainnet nebo Layer 2 (levnější sidechain, který běží nad mainchainem)? Cena plynu a některé funkce se liší podle řetězce.
- Verze a knihovna: Která verze Solidity, která verze OpenZeppelin? Pokud není specifikována žádná verze, AI může vytvářet zastaralé, zastaralé vzory.
- Bezpečnostní požadavky: Existuje strop, lze jej pozastavit, lze jej zvýšit? To by mělo být řečeno od samého začátku.
- Omezení: Jasné limity jako „nepoužívat montáž“, „vyhýbat se externímu volání“, „optimalizovat plyn, ale zachovat čitelnost“.
Další mocnou technikou je požádat AI nejprve o plán a poté o kód: „Nejprve vyjmenujte funkce této smlouvy a to, co každá udělá; napište kód, jakmile jej schválím.“ To brzy zachytí AI, která jde špatným směrem, a umožní vám zachovat architektonické rozhodnutí.
Nápověda: Zeptejte se AI "proč jste tento kód napsali takto?" požádat. Vysvětlení zdůvodnění urychlí vaše učení a vyplaví na povrch jakékoli logické chyby (např. falešný bezpečnostní předpoklad). Nevěřte výstupům AI, která nedokáže bránit svůj vlastní kód.
Časté chyby
- Vložení bezpečnosti do AI od nuly. Použijte testovanou knihovnu.
- Nepotvrzuje verzi/vzor vytvořený AI. Tréninková data mohou být stará.
- Obcházení testnetu. Každý koncept by měl před spuštěním běžet v testovací síti.
- Bez přidání NatSpec/dokumentace. Kontrola a údržba jsou obtížné.
- "Je to zkompilované, takže je to bezpečné" mylná představa. Být zkompilován neznamená být v bezpečí.
- Zapomínání na kontrolu přístupu. Je to jedna z nejčastějších a nejdražších chyb.
V souhrnu
- Při psaní inteligentních smluv AI vytváří rámce, testy a návrhy revizí; Člověk zaručuje bezpečnost výroby.
- Budujte zabezpečení nikoli od začátku, ale na základě osvědčených knihoven (např. OpenZeppelin).
- Vždy je potvrzena aktuálnost verzí a vzorů vyráběných YZ.
- Testovací pahýly jsou cenné při zachycení lidských slepých míst (limitní případy, kontrola přístupu).
- Být zkompilován neznamená být v bezpečí; testnet a auditování jsou nutností.
Aplikační úkol
Pro jednoduchý token ERC-20 vygenerujte koncept pomocí výše uvedené výzvy „kostra založená na standardech“. Poté: (1) zkontrolujte, zda používá zaškrtnutou knihovnu, (2) zkontrolujte řízení přístupu, (3) vygenerujte testy s výzvou „test case draft“ a skutečně spusťte alespoň jeden test nečestného volajícího. Najděte a poznamenejte si alespoň jeden bezpečnostní bod, který AI vynechala.
kontrolní seznam
- [ ] Ve výzvě jsem jasně uvedl standard a řetězec.
- [ ] Chtěl jsem osvědčenou produkci založenou na knihovnách.
- [ ] K dispozici licence SPDX a verze pragma.
- [ ] V každé kritické funkci existuje kontrola přístupu.
- [ ] Vytvořil jsem a spustil jsem testy pro limitní případy.
- [ ] Potvrdil jsem, že knihovna/vzor je aktuální.
- [ ] Označil jsem kód pro auditování a testování; Nedostal jsem to bez dozoru na mainnetu.