Voitot:
- Kyky käyttää tekoälyä tuottamaan kehyksiä, testejä ja tarkastelemaan luonnoksia todistettujen kirjastojen (esim. OpenZeppelin) perusteella ja ymmärtää, että ihminen takaa tuotantoturvan
- Kyky tarkistaa tekoälyn tuottama koodiversio, kuvio ja pääsynhallinta kokoamisen, testauksen ja testiverkon avulla
- Kyky erottaa, että kokoaminen ei tarkoita turvallisuutta ja että testnet ja auditointi ovat välttämättömiä.
Älysopimuksen kirjoittaminen eroaa tavallisesta ohjelmistosta: kirjoittamasi koodi on julkinen, muuttumaton ja ohjelma, joka siirtää suoraan rahaa. Tässä osiossa opit käyttämään tekoälyä älykkään sopimuskehitysassistenttina; Opimme luonnostuotannosta testikirjoitukseen, kuvion palauttamisesta kaasun (transaktiomaksun) optimointiin. Mutta tehdään selväksi alusta alkaen: AI tuottaa piirustuksia; Ihmiset varmistavat turvallisen koodin, joka menee tuotantoon.
Maa ensin: kieli ja ympäristö
Yleisin älykkäiden sopimusten kieli on Solidity (Ethereumin ja EVM:n kieli – Ethereum Virtual Machine, virtuaalikone, jolla sopimukset toimivat – yhteensopivat ketjut). Vaihtoehtona on Vyper (Pythonin kaltainen kieli, jonka tavoitteena on olla rajoitetumpi ja luettavampi). Koodisi kuluttaa kaasua (jokaisen tapahtuman hinta lohkoketjulle); Tehoton koodi on kallista. Näiden termien pitäminen selkeinä kontekstissa, jonka annat tekoälylle, on avainasemassa tarkan tulosteen saamiseksi.
Tekoäly ei ole arvokkainta "alusta kirjoittamisessa", vaan kehyksen + hyvän muotin tuottamisessa: standardien mukainen alku, suunnitelma, johon voit lisätä asiantuntemustasi.
Tekoälyn käytön kerrokset koodauksessa
1. Luurangojen luominen. Tekoäly louhii nopeasti vakiotunnuksen (ERC-20) tai NFT:n (ERC-721 – ainutlaatuisen digitaalisen omaisuusstandardin) rungon. Mutta varmista, että tekoäly käyttää todistettua kirjastoa: esimerkiksi OpenZeppelin (yhteisön luotettava, tarkastettu standardisopimuskirjasto). Sääntönä on käyttää testattua lohkoa sen sijaan, että kirjoitat suojausta tyhjästä.
2. Toiminnan kuvaus ja katsaus. Olemassa olevan funktion selittäminen tekoälylle mahdollistaa logiikkavirheiden havaitsemisen ajoissa.
3. Testisukupolvi. Tekoäly on hyvä luomaan testitapauksia reunatapauksille: nollasyöttö, erittäin suuri määrä, luvaton soittaja, toistuva puhelu. Tämä muistuttaa yhtä skenaarioista, jotka ohitetaan.
4. Kaasu ja luettavuus. AI ilmoittaa kalliista kuvioista, kuten tarpeettomista tallennuskirjoituksista, ja ehdottaa vaihtoehtoja.
Vihje: Käske tekoälyä rakentamaan OpenZeppelinin tarkastettuihin sopimuksiin, kirjoittamaan tietoturva uudelleen tyhjästä. Tekoälylle on paljon riskialtisempaa kirjoittaa alkuperäinen suojakoodi kuin käyttää testattua kirjastoa.
Heikko kehote / Vahva kehote
Heikko kehote:
Kirjoita minulle merkkisopimus.
Tämä kehote on vaarallinen: ei ole selvää, mikä standardi, mikä ketju, mikä kirjasto, mikä tietoturvavaatimus. Tekoäly tuottaa satunnaista, mahdollisesti vanhentunutta tai epävarmaa koodia.
Tehokas kehotus:
Tehtäväsi: vanhempi Solidity-kehittäjä. Luo ERC-20-merkkiluonnos EVM-yhteensopivalle ketjulle. Säännöt:- Perustuu OpenZeppelinin auditoituihin ERC20- ja Ownable-sopimuksiin.- Kirjoita Solidity version ja -lisenssin (SPDX) rivi selvästi.- Vain omistajalla on lupa lyödä; lisää korkki loputonta painamista vastaan. - Lisää NatSpec-kommentti jokaiseen toimintoon. - Kirjoita suojaus tyhjästä; Käytä vakiolohkoa. - Lisää varoitus loppuun: "Tämä on luonnos; tarkastus ja testaus vaaditaan". Merkitse alueet, joista et ole varma //TODO-painikkeella.
Ero: vahva kehote antaa selkeän roolin, standardin, kirjaston, suojausrajan, dokumentaatio- ja validointiodotukset.
Neljä kopioitavaa mallia
1) Standardeihin perustuva luuranko:
Roolisi: Solidity-kehittäjä. Luo [ERC-20 / ERC-721 / staking]sopimuskehys OpenZeppelinin auditoituun kirjastoon. Kirjoita SPDX-lisenssi ja pragma-versio. Lisää kulunvalvonta (kuka voi soittaa) jokaiseen ulkoiseen toimintoon. Turvallisuuden uusiminen; Käytä vakiolohkoja. Tämä on luonnos.
2) Toimintojen tarkistus:
Tutki seuraavaa toimintoa kuin vanhempi kehittäjä: mitä se tekee, mitä tiloja se muuttaa, kuka voi kutsua sitä? Merkitse mahdolliset logiikkavirheet ja tietoturvariskit HYPOTEESIN linkittämällä jokainen koodin riville. Älä sano suoraan "turvallinen"; luettele vain huomion kohteet.
3) Testiskenaarion luonnos:
Ehdota testitapauksia tälle sopimukselle (voi olla Foundryn/Hardhatin luonnos). Erityisesti kattaa rajatapaukset: nolla syöttöä, erittäin suuri numero, luvaton puhelu, uudelleentulopuhelu, riittämättömät varat. Kirjoita MITÄ kukin testi vahvistaa.
4) Kaasu- ja luettavuuskatsaus:
Merkitse tähän sopimukseen kuviot, jotka voivat alentaa kaasukustannuksia: tarpeeton tallennustila, ulkopuhelu silmukassa, toistuva laskenta. Selitä kunkin ehdotuksen ennen/jälkeen ero. Suosittele turvallisuutta rikkovia optimointeja; Jos se ei ole selvää, sano "kysy tilintarkastajalta".
Kolme minikoteloa (numeroina)
Tapaus 1 – Luuranko säästi 4 tuntia. Yksi ryhmä louhi tarkastetun kirjastopohjaisen tekoälysopimuksen rungon 30 minuutissa; Käsin kesti ~4 tuntia. Tiimi käytti aikaa turvallisuuteen ja testaukseen. Hyöty ei tullut tietoturvan siirtämisestä, vaan työläskehyksen nopeuttamisesta.
Tapaus 2 — Vanhentunut versiolukko. Tekoäly tuotti kuvion, joka lähettää raakaeetterin siirrolla, jota ei enää suositella, koska harjoitustiedot ovat vanhentuneita. Kehittäjä huomasi tämän ja vaihtoi sen nykyiseen puhelupohjaiseen ja uudelleentulosuojattuun malliin. Oppitunti: Tekoälyn kirjaston/mallin vahvistetaan aina olevan ajan tasalla; Tekoäly ei tiedä harjoittelun päättymispäivää pidemmältä.
Tapaus 3 – Testiluonnos ponnahti piiloon. Tekoälyn tuottama "luvaton soittajan" testi paljasti, että kehittäjä oli unohtanut kulunvalvonnan johonkin toimintoon. vainOmistajalta puuttuu 1 rivi, kiinni 5 minuutissa testiverkosta; Verkon varoja saattoi menettää. Oppitunti: AI kattaa ihmisen kuolleen kulman testauksessa.
Tietoturvamallien muistaminen tekoälyn avulla
Tekoäly on hyvä muistuttamaan tunnetuista haavoittuvuuksista, kuten tarkistuslistasta. Yleisimmät mallit:
- Palautus: Ulkopuhelun soittaminen tilaa päivittämättä. Ratkaisu: tarkastukset-vaikutukset-vuorovaikutusjärjestys, paluuturva.
- Kulunvalvonnan puute: Kuka tahansa voi kutsua kriittistä toimintoa.
- Kokonaisluvun ylivuoto/alipudotus: Modern Solidity sieppaa useimmat niistä, mutta silti riski matalan tason koodissa.
- Riittämätön syötteen validointi: Nollaosoite, nollamäärän valvonta.
- Oracle-riippuvuus: Sokea luottamus ulkoisiin tietoihin (kuten hintaan).
Huomio: AI voi muistaa tämän luettelon, mutta se ei voi taata, onko luettelossa oleva kohde sinun koodissasi. Tarkistuslista on alku; Se ei korvaa kontin valvontaa.
Oikea konteksti: tekoälyn hyvän koodin salaisuus
Tekoälyn tuottaman koodin laatu riippuu suoraan sille antamasi kontekstin laadusta. Web3:ssa tämä on erityisen tärkeää, koska yksi pieni yksityiskohta (mikä ketju, mikä Solidity-versio, mikä merkkistandardi) muuttaa koko tulosteen. Hyvä konteksti sisältää:
- Kohdeketju ja -ympäristö: Ethereum-mainnet vai Layer 2 (halvempi sivuketju, joka kulkee pääketjun päällä)? Kaasun hinta ja jotkin ominaisuudet vaihtelevat ketjuittain.
- Versio ja kirjasto: Mikä Solidity-versio, mikä OpenZeppelin-versio? Jos versiota ei ole määritetty, tekoäly saattaa tuottaa vanhentuneita, vanhentuneita malleja.
- Turvallisuusvaatimukset: Onko yläraja, voidaanko se keskeyttää, voiko sitä nostaa? Nämä pitäisi sanoa heti alusta alkaen.
- Rajoitukset: Selkeät rajat, kuten "älä käytä kokoonpanoa", "vältä ulkopuhelua", "optimoi kaasu, mutta säilytä luettavuus".
Toinen tehokas tekniikka on kysyä tekoälyltä ensin suunnitelma ja sitten koodi: "Luettelo ensin tämän sopimuksen toiminnot ja mitä kukin tekee; kirjoita koodi, kun hyväksyn sen." Tämä havaitsee varhain tekoälyn menevän väärään suuntaan ja antaa sinun säilyttää arkkitehtonisen päätöksen.
Vihje: Kysy tekoälyltä "miksi kirjoitit tämän koodin tällä tavalla?" kysyä. Perustelun selittäminen sekä nopeuttaa oppimistasi että tuo pintaan mahdolliset loogiset virheet (esim. väärän turvallisuusoletuksen). Älä luota sellaisen tekoälyn tuotteeseen, joka ei pysty puolustamaan omaa koodiaan.
Yleisiä virheitä
- Turvallisuuden lisääminen tekoälyyn tyhjästä. Käytä testattua kirjastoa.
- Ei vahvista tekoälyn tuottamaa versiota/mallia. Harjoitustiedot voivat olla vanhoja.
- Ohitetaan testiverkko. Jokaisen luonnoksen tulee toimia testiverkossa ennen julkaisemista.
- NatSpec/dokumentaatiota ei lisätä. Tarkastus ja huolto vaikeutuvat.
- "Se on koottu, joten se on turvallista" väärinkäsitys. Kokoaminen ei tarkoita turvallisuutta.
- Kulunvalvonta unohtuu. Se on yksi yleisimmistä ja kalliimmista virheistä.
Yhteenvetona
- Älykkäässä sopimuskirjoituksessa tekoäly tuottaa kehyksiä, testejä ja tarkistusluonnoksia; Ihminen takaa tuotannon turvallisuuden.
- Rakenna turvallisuutta ei tyhjästä, vaan todistettujen kirjastojen (esim. OpenZeppelin) perusteella.
- YZ:n valmistamien versioiden ja kuvioiden ajantasaisuus vahvistetaan aina.
- Testityngät ovat arvokkaita ihmisen kuolleiden kulmien kaappaamisessa (rajatapaukset, kulunvalvonta).
- Kokoonpano ei tarkoita turvallisuutta; testnet ja auditointi ovat pakollisia.
Sovellustehtävä
Luo luonnos yksinkertaiselle ERC-20-tunnukselle käyttämällä yllä olevaa "standardeihin perustuvaa luurankoa" -kehotetta. Sitten: (1) tarkista, käyttääkö se tarkistettua kirjastoa, (2) tarkista pääsyn hallinta, (3) luo testejä "testitapausluonnos" -kehotteen avulla ja suorita ainakin yksi rogue-soittaja -testi. Etsi ja merkitse vähintään yksi turvapiste, jonka tekoäly ei ole huomannut.
tarkistuslista
- [ ] Olen selkeästi ilmaissut standardin ja ketjun kehotteessa.
- [ ] Halusin todistetun kirjastopohjaisen tuotannon.
- [ ] SPDX-lisenssi ja pragma-versio saatavilla.
- [ ] Jokaisessa kriittisessä toiminnossa on kulunvalvonta.
- [ ] Loin ja suoritin testejä rajatapauksille.
- [ ] Vahvistin, että kirjasto/malli on ajan tasalla.
- [ ] Merkkasin koodin auditointia ja testausta varten; En saanut sitä valvomatta pääverkossa.