Älykkäiden sopimusten itsetarkastus ChatGPT:n avulla

Älykkäitä sopimuksia auditoitaessa on käsiteltävä monenlaisia asioita, jotta voidaan varmistaa, että koodi on turvallista. Nämä kysymykset kattavat erilaisia näkökohtia, kuten pääsynvalvonta, varojen hallinta, tiedonhallinta, oletukset, riippuvuudet ja tietoturvatarkistuslistat. Alla on yksityiskohtainen tarkistuslista ja ohjeet ChatGPT-kyselyihin, jotka opastavat sinua älysopimusten auditointiprosessissa.

Jos haluat itse tutkia älysopimusta haavoittuvuuksien ja piilotettujen huijaustekniikoiden varalta, ensimmäinen askel on oikein muotoiltu ChatGPT-kysely.

Hyödyllinen kysely ChatGPT:tä varten olisi seuraava komento:

Tarjoa kattava luettelo kaikista ongelmista ja haavoittuvuuksista seuraavassa älysopimuksessa. Kuvaile ongelmat ja mahdolliset haavoittuvuudet yksityiskohtaisesti. Anna yksi hyväksikäyttöskenaario kullekin haavoittuvuudelle. Tulosta kelvollisena markdown-muotoisena taulukkona, jossa on luettelo objekteista, joissa jokaisessa on sarakkeet 'description', 'action', 'severity', 'actors', 'scenario', 'type' ja 'line'. 'type', jossa voi olla 'usability', 'vulnerability', 'optimization' tai 'suggestion'. 'actors' on luettelo mukana olevista toimijoista. 'severity' voi olla 'low', 'medium' tai 'high'. 'row' on ongelman rivinumero. Varmista, että kaikki taulukon kentät on täytetty.

Selvitä sitten älysopimusta syvällisemmin seuraavien kysymysten avulla.

Käyttöskenaariot:

1. Keitä ovat järjestelmän toimijat?


2. Mitä toimintoja järjestelmällä on?


3. Mitkä ovat järjestelmän rajoitukset?


4. Mitkä ovat mahdollisia tapoja murtaa järjestelmä?


5. Millä puolustuksilla hyökkäyksiä torjutaan?


6. Kuvaile rajoitusten perusteella kunkin toiminnon tilamuutokset.


7. Anna tietoa käytetyistä Solidity- ja DeFi-malleista.


8. Kirjoita positiivisia ja negatiivisia aksioomeja järjestelmää koskevien tietojen perusteella.


9. Luettele tapoja optimoida ja muokata koodia luotettavammaksi (koodinpätkien avulla).


10. Luettele koodissa käytetyt piilohuijausmenetelmät (koodinpätkien avulla).

Vinkki: Tietojen visuaalinen esittäminen antaa usein selkeämmän käsityksen järjestelmän toiminnasta. Kun työskentelet ChatGPT:n kanssa, on suositeltavaa pyytää visualisointeja lähtötiedoista, kuten tilamuutoksista ASCII-merkkikaavioina. Vaikka kaikki visualisoinnit eivät ehkä olekaan järkeviä, jotkin niistä voivat tarjota erittäin arvokasta tietoa älykkään sopimuksen toiminnasta.

Asiaatteessa, vaikka ChatGPT ei voi korvata inhimillistä tarkastajaa, se täydentää merkittävästi tarkastusprosessia tarjoamalla selkeämmän ymmärryksen protokollan tilasiirroista, rajoitteista, invarianteista ja yhteensopivuudesta. Tämä työkalu on erityisen tehokas protokollan tilasiirtymien ja rajoitusten ymmärtämisessä.

Vinkki: Ennen auditoinnin aloittamista, jos chatbotille annetaan dokumentaatiota auditoitavasta protokollasta, voidaan vastausten tarkkuutta ja relevanssia parantaa huomattavasti. Mainitse vain: "Tämä on dokumentaatio, joka tarjoaa parhaan kontekstin auditoimalleni 'protokollan_nimi'-protokollalle", ja lisää dokumentti."

Voidaan sanoa, että ChatGPT on tehokas avustaja auditoijille, joka tarjoaa jäsennellyn ja syvällisen lähestymistavan älykkäiden sopimusten auditointiin. On kuitenkin pidettävä mielessä, että ChatGTP (ja vastaavat palvelut) ovat vain monimutkaisia tulkintoja todennäköisyyksillä työskentelevästä koneanalyysistä, joten se tuottaa usein virheitä ja epätarkkuuksia. Näin ollen ChatGPT:n tulokseen ei voi täysin luottaa - se on vain hyvä työkalu oikeissa käsissä ja "lähtökohta" älykkäiden sopimusten tutkimuksessa.

Siten mahdollisilta riskeiltä suojautuakseen älysopimukset tulisi tutkia tarkemmin mahdollisten haavoittuvuuksien ja petollisten järjestelmien varalta.

Miten tehdä perusteellinen älysopimustarkastus? Top 100 kyselyä ChatGPT:lle

Yllä olemme tarkastelleet yleistä kyselyä (prompt) ChatGPT:lle, josta voit aloittaa älysopimuksen analysoinnin. Mutta yksityiskohtainen analyysi ei tietenkään rajoitu vain johdantokehotukseen.

Huijarit parantavat jatkuvasti taktiikkaansa, joten sinun on oltava tietoinen ja varovainen monessa asiassa - nämä ovat olennaisia strategioita, jotta voit suojella token-sijoitustasi.

Katsotaanpa listaa sadasta tärkeimmästä kyselystä, joiden avulla saat ammattimaisen lähestymistavan älysopimusten tarkastukseen:

1. Kompiloidaanko koodi onnistuneesti?
2. Mitä Solidityn versiota koodissa käytetään? Onko se nykyinen vakaa versio?
3. Onko mukana selkeitä kommentteja, joissa selitetään funktioiden ja muuttujien tarkoitus?
4. Käytetäänkö sopimuksessa "Ownable"-järjestelmää? Jos kyllä, niin minkä funktioiden osalta?
5. Ovatko tilamuuttujat oikein allokoitu näkyvyyden muokkaajia käyttäen?
6. Käytetäänkö tapahtumia asianmukaiseen lokitukseen?
7. Ovatko virheilmoitukset käyttäjäystävällisiä?
8. Tarkistetaanko matalan tason kutsujen paluuarvo?
9. Onko olemassa skenaarioita, joissa omistaja voi valtuuttaa itsensä, mikä voi johtaa maton vetämiseen?
10. Kuka valvoo etuoikeutettuja tilejä ja mitkä ovat valvontamekanismit?
11. Mitä hallintamekanismeja sopimuksessa on, ja onko hallinto täysin avoin vai rajoitettu?
12. Käytetäänkö järjestelmässä muita sopimuksia ja mitä rooleja ne täyttävät (esim. proxy-sopimus)?
13. Onko käytössä aikalukitusmekanismi ja voiko sen ohittaa?
14. Onko saatavilla riittävä dokumentaatio?
15. Onko koodissa mahdollisia haavoittuvuuksia DoS- tai reentrancy-hyökkäyksille?
16. Ovatko kaikki funktiot sisäisiä lukuun ottamatta niitä, joiden nimenomaisesti edellytetään olevan julkisia/ulkoisia?
17. Ei aritmeettisia ylivuodotuksia/alijuoksutuksia matemaattisissa operaatioissa?
18. Käytetäänkö suojattua OpenZeppelin-kirjastoa?
19. Eetteriä tai poletteja ei voi lähettää vahingossa nollaosoitteeseen (0x0)?
20. Ehdot tarkistetaan require-ohjelmalla ennen operaatioita ja tilamuutoksia?
21. Säädetäänkö tila ennen operaatioiden suorittamista ja niiden aikana?
22. Käytetäänkö suojausta reentry-hyökkäyksiltä (A kutsuu B:tä kutsuu A:ta)?
23. Onko ERC20-rajapinta toteutettu asianmukaisesti?
24. Käytetäänkö modifiointia useissa paikoissa vain, jos se on todella tarpeen?
25. Säädetäänkö kaikki tyypit eksplisiittisesti (esim. uint256 käytetään uintin sijasta)?
26. Ovatko kaikki metodit ja syklit suurimman sallitun kaasun rajan sisällä?
27. Ei tarpeettomia alustuksia konstruktorissa (muista, että oletusarvot on asetettu)?
28. Testaus on kattava: jokainen älysopimusmetodi ja kaikki mahdolliset syötetietotyypit on testattu?
29. Onko fuzz-testausta suoritettu satunnaisten syötteiden avulla?
30. Testataanko kaikki mahdolliset tilat, joissa sopimus voi olla?
31. Eetterin ja tokeneiden oletusmäärät on määritelty wei-yksiköissä?
32. Seurataanko crowdsale-loppulohkoa/-aikaa alkulohkon/ajan jälkeen (kaupankäynnin aloittaminen / mahdollistaminen)?
33. Onko crowdsale-tokenien vaihtokurssi/muunnoskurssi asetettu oikein?
34. Onko asetettu pehmeä/kovaa crowdsale-rajaa?
35. Onko crowdsaleen sallittu vähimmäis-/maksimiosuus asetettu ja testattu?
36. Onko crowdsalen whitelisting-toiminnallisuus testattu?
37. Onko crowdsalen palautuslogiikka todennettu?
38. Saavatko crowdsale-osallistujat suhteutetun määrän tokeneita vai voivatko he vaatia panostaan?
39. Onko crowdsalen kunkin vaiheen kesto (esim, ennakkomyynti, julkinen myynti) oikein määritetty?
40. Määritelläänkö, mitä toimintoja vain omistaja saa hallita (esim, crowdsalen keskeyttäminen, siirtyminen crowdsalen toiseen vaiheeseen, tokenien jakelun mahdollistaminen jne.)?
41. Onko crowdsalen vesting- (vesting-) logiikka tarkistettu?
42. Crowdsalessa on vikasietotila, joka omistajan ottaessa sen käyttöön rajoittaa ominaisuuksien kutsuja ja sisältää palautustoiminnon?
43. Crowdsale on varotoiminto, jos se on järkevää.
44. Onko tuodut kirjastot tarkistettu etukäteen, eivätkä ne sisällä ei-toivottuja osia, jotka voidaan korvata tulevissa versioissa ja joita voidaan käyttää haitallisiin tarkoituksiin?
45. Token-siirtomenetelmät (transfer) kääritty requireen?
46. Käytetäänkö require- ja assert-menetelmiä oikein? Assert-metodia käytetään vain asioihin, joita ei saisi koskaan tapahtua, yleensä sitä käytetään tilan tarkistamiseen muutosten jälkeen.
47. Onko rekursiivisen kutsun hyökkäyksiä vastaan suojauduttu?
48. Ovatko syötteessä olevien mielivaltaisten merkkijonojen pituudet rajoitettuja?
49. Mahdollisuuksien mukaan vältetään matriisien käyttämistä ja käytetään sen sijaan mappingsia?
50. Ei lohko-hasheja käytetä satunnaisarvojen käsittelyyn (kaivostyöläiset voivat vaikuttaa tähän)?
51. Ei käytetä missään tx.origin:ia?
52. Maastojen elementtejä siirretään alaspäin, kun elementti poistetaan, jotta ei jätetä aukkoja?
53. Käytetäänkö revert:iä throw:n sijasta?
54. Toiminnot päättyvät välittömästi, jos ehdot eivät täyty?
55. Onko kääntäjän varoitukset korjattu?
56. Käytetäänkö SafeMath-kirjastoa laskutoimituksissa?
57. Luetaanko mitään muistipaikkoja (tallennuspisteitä) useammin kuin kerran?
58. Käytetäänkö rajoittamattomia silmukoita/jonoja, jotka voivat aiheuttaa DoS:n?
59. Käytetäänkö block.timestamp:ia vain pitkien aikavälien kohdalla?
60. Käytetäänkö block. number laskettaessa kulunutta aikaa?
61. Vältetäänkö delegatecall-kutsua, erityisesti ulkoisten (vaikka luotettavien) sopimusten osalta?
62. Eikö array:n pituus päivity, kun sen yli iteroidaan?
63. Onko allekirjoitukset suojattu toistolta nonce ja block.chainid:llä?
64. Varmista, että kaikki allekirjoitukset käyttävät EIP-712:ta?
65. abi.encodePacked():n tulosta ei pitäisi hashata, jos käytetään enemmän kuin 2 dynaamista tyyppiä. Yleensä on parempi käyttää abi.encode().
66. Tarkista huolellisesti assembly-koodin lisäykset.
67. Vältä riittämätöntä kaasunkulutusta (gas griefing).
68. Onko kaikki yksityinen tieto todella yksityistä?
69. Rakenteen/määrän päivittäminen muistissa (memory) ei muuta sitä tallennuksessa (stage)?
70. Ovatko stage-muuttujat varjostettuja?
71. Onko muuttujan arvon laskeminen lennossa halvempaa kuin sen tallentaminen?
72. Luetaanko kaikki tilamuuttujat oikeasta sopimuksesta (master vs. klooni)?
73. Käytetäänkö vertailuoperaattoreita (>, <, >=, <=) oikein, erityisesti estetäänkö off-by-one-virheet?
74. Käytetäänkö loogisia operaattoreita (==, ! =, &&, ||, !) käytetään oikein, erityisesti virheiden välttämiseksi?
75. Käytetäänkö kertolaskua aina ennen jakoa (ellei kertolasku voi ylivuotaa)?
76. Korvataanko maagiset luvut vakiolla, jolla on intuitiivinen nimi?
77. Jos ETH-vastaanottajalla on fallback (fallback ) -funktio, joka voidaan palauttaa, voiko tämä johtaa DoS:ään?
78. Käytetäänkö SafeERC20-standardia ja tarkistetaanko palautusarvot turvallisella tavalla?
79. oletetaanko, että msg. lähettäjä on aina relevantti käyttäjä?
80. Eikö tx.origin:ia käytetä auktorisointiin?
81. Eikö address.transfer() tai address.send() käytetä .call.value():n sijasta?
82. Matalan tason kutsuja käytettäessä on varmistettava, että sopimus on olemassa ennen kutsua.
83. Käytetäänkö assembly-koodia chainid- tai sopimuskoodin/size/hash-koodin käyttämiseen Solidity-syntaksin sijaan?
84. Käytetäänkö delete-avainsanaa, kun muuttuja asetetaan nolla-arvoon (0, false, "" jne.)?
85. Loogisille operaattoreille/vertailuille (&&/|||/>=/==/jne) välitetyillä lausekkeilla ei saa olla sivuvaikutuksia.
86. Käsitellessäsi useita osoitteita, kysy itseltäsi, mitä tapahtuu, jos ne ovat samoja?
87. Miten hyvin dokumentoitu koodi on? Annetaanko kommentteja ja esimerkkejä aina, kun käytetään epästandardia koodia?
88. Jos käytetään ulkoista kutsua, varmista, että ulkoisen sopimuksen kutsu on todella tarpeen?
89. Tarkistetaanko ulkoisen kutsun tulos ja käsitelläänkö virheet?
90. Mitä tapahtuu, jos ulkoinen kutsu käyttää kaiken tarjotun kaasun?
91. Jos ulkoinen kutsu kutsuu tiettyä funktiota, varmista, että funktio on todella olemassa (fantom-funktiot).
92. Varmista, ettei ulkoisia kutsuja käytetä muokkaajissa (modifikaattorit)
93. Kirjoitetaanko tapahtumia jokaiselle funktiolle, joka muuttaa varastoa?
94. Tarkista oletuksesi siitä, mitä pääkäytössä käytettävät ulkoiset sopimukset tekevät ja palauttavat.
95. Varoittelen merkkejä, joissa käytetään liian monta tai liian vähän desimaaleja. Varmista, että suurimmat ja pienimmät tuetut arvot on dokumentoitu.
96. Onko rooleihin liittyvät valtuudet dokumentoitu?
97. Mitkä ovat riskit, kun käyttöoikeuksia rikotaan, ja miten tämä voi vaikuttaa järjestelmän eri komponentteihin?
98. Voiko omistaja manipuloida tokeneita ja ETH:ta sopimuksessa?
99. Miten oraakkelin (Oracle) osoite asetetaan ja mikä prosessi on sen takana? Onko vara-orakkeleita varmuuskopiointia varten?
100. Miten vastaavat toiminnot on toteutettu muissa projekteissa, onko parhaat käytännöt otettu huomioon?

Tämän tarkistuslistan avulla varmistat, että suoritat Solidity-älysopimusten perusteellisen tietoturvatarkastuksen. Se kattaa laajan valikoiman kriittisiä näkökohtia, joiden avulla voit tunnistaa ja lieventää mahdollisia haavoittuvuuksia ja riskejä koodissa ja siihen liittyvissä järjestelmissä.

 

Toivomme, että nämä esimerkit ovat auttaneet sinua ymmärtämään paremmin älysopimusten auditointimenetelmää.

 

Koska kaikki lohkoketjussa oleva tieto on avointa (edellyttäen tietenkin, että sopimuksen lähdekoodi on todennettu), voit tämän tiedon avulla varustautuneena tutkia itsenäisesti älysopimuksia ja tunnistaa erilaisia huijausjärjestelmiä.

Me olemme kuitenkin jo tehneet kaiken tämän puolestasi! Tilaa premium-tilaus ja saat käyttöösi yksinoikeudella suodattimia älykkäiden sopimusten ominaisuuksista ja tuoretta analytiikkaa. Lisää mahdollisuuksiasi sijoittaa menestyksekkäästi kannattaviin tokeneihin.

Hyvästi, Lotus Market -tiimi.

All posts