Samorevizijske pametne pogodbe s ChatGPT

Pri revidiranju pametnih pogodb je treba zajeti številne zadeve, da se zagotovi varnost kode. Ta vprašanja zajemajo različne vidike, vključno z nadzorom dostopa, upravljanjem sredstev, upravljanjem podatkov, predpostavkami, odvisnostmi in varnostnimi kontrolnimi seznami. V nadaljevanju navajamo podroben kontrolni seznam in navodila za poizvedbe ChatGPT, ki vas bodo vodili skozi postopek revidiranja pametnih pogodb.

Če želite sami raziskati pametno pogodbo za ranljivosti in skrite tehnike prevar, je prvi korak pravilno oblikovana poizvedba ChatGPT.

Uporabna poizvedba za ChatGPT bo naslednji ukaz:

Predstavite izčrpen seznam vseh težav in ranljivosti naslednje pametne pogodbe. Podrobno opišite težave in morebitne ranljivosti. Za vsako ranljivost navedite en scenarij izkoriščanja. Izhodni rezultat je veljavna tabela v formatu markdown s seznamom objektov, vsak s stolpci "opis", "ukrep", "resnost", "akterji", "scenarij", "vrsta" in "vrstica". "type", kjer je lahko "usability" (uporabnost), "vulnerability" (ranljivost), "optimization" (optimizacija) ali "suggestion" (predlog). "actors" (akterji) je seznam vključenih akterjev. "resnost" je lahko "nizka", "srednja" ali "visoka". "vrstica" je številka vrstice problema. Prepričajte se, da so izpolnjena vsa polja v preglednici.

Potem z naslednjimi vprašanji podrobneje raziščite pametno pogodbo.

Scenariji uporabe:

1. Kateri so akterji v sistemu?


2. Katera dejanja ima sistem?


3. Katere so omejitve sistema?


4. Kateri so možni načini za zlom sistema?


5. Katera obramba se uporablja za preprečevanje napadov?


6. Na podlagi omejitev opišite spremembe stanja vsake funkcije.


7. Podajte informacije o uporabljenih predlogah Solidity in DeFi.


8. Napišite pozitivne in negativne aksiome na podlagi informacij o sistemu.


9. Navedite načine za optimizacijo in spreminjanje kode, da bo bolj zanesljiva (z izseki kode).


10. Navedite metode skritih prevar, ki se uporabljajo v kodi (z izseki kode).

Nasvet: Vizualna predstavitev podatkov pogosto omogoča jasnejše razumevanje delovanja sistema. Pri delu z aplikacijo ChatGPT je priporočljivo, da zahtevate vizualizacijo izhodnih podatkov, kot so spremembe stanja, v obliki znakovnih diagramov ASCII. Čeprav vse vizualizacije niso smiselne, lahko nekatere zagotovijo zelo dragocen vpogled v delovanje pametne pogodbe.

Sicer ChatGPT ne more nadomestiti človeškega revizorja, vendar pomembno dopolnjuje postopek revizije, saj omogoča jasnejše razumevanje prehodov stanj protokola, omejitev, invariant in združljivosti. To orodje je še posebej učinkovito pri razumevanju prehodov stanja protokola in omejitev.

Nasvet: Če pred začetkom revizije klepetalnemu robotu zagotovite dokumentacijo o revidiranem protokolu, lahko močno izboljšate natančnost in ustreznost odgovorov. Samo omenite: "To je dokumentacija, ki zagotavlja najboljši kontekst za 'ime_protokola', ki ga revidiram," in vstavite dokument.

Razumemo lahko, da je ChatGPT močan pomočnik za revizorje, ki zagotavlja strukturiran in poglobljen pristop k revidiranju pametnih pogodb. Vendar je treba upoštevati, da je ChatGTP (in podobne storitve) le zapletena interpretacija strojne analize, ki dela z verjetnostmi, zato pogosto proizvaja napake in netočnosti. V skladu s tem se na rezultate ChatGPT ni mogoče v celoti zanesti - so le dobro orodje v pravih rokah in "izhodišče" pri raziskovanju pametnih pogodb.

Zato je treba za zaščito pred morebitnimi tveganji pametne pogodbe natančneje pregledati glede morebitnih ranljivosti in goljufivih shem.

Kako izvesti poglobljeno revizijo pametnih pogodb? Top 100 zahtevkov za ChatGPT

Zgoraj smo obravnavali splošno poizvedbo (poziv) za ChatGPT, na podlagi katere lahko začnete analizirati pametno pogodbo. Seveda pa podrobna analiza ni omejena le na uvodni poziv.

Prevaranti nenehno izboljšujejo svoje taktike, zato morate biti informirani in previdni v številnih vidikih - to so bistvene strategije za zaščito naložbe v žetone.

Poglejmo si seznam 100 najpomembnejših poizvedb, s katerimi boste strokovno pristopili k reviziji pametne pogodbe:

1. Ali je koda uspešno sestavljena?
2. Katera različica Solidityja je uporabljena v kodi? Ali je to trenutna stabilna različica?
3. Ali so prisotni jasni komentarji, ki pojasnjujejo namen funkcij in spremenljivk?
4. Ali pogodba uporablja shemo "Ownable"? Če da, za katere funkcije?
5. Ali so spremenljivke stanja pravilno dodeljene z uporabo modifikatorjev vidljivosti?
6. Ali se dogodki uporabljajo za pravilno beleženje?
7. Ali so na voljo uporabniku prijazna sporočila o napakah?
8. Ali je preverjena povratna vrednost klicev na nizki ravni?
9. Ali obstajajo scenariji, pri katerih se lahko lastnik pooblasti, kar bi lahko vodilo do vlečenja preproge?
10. Kdo ima nadzor nad privilegiranimi računi in kakšni so nadzorni mehanizmi?
11. Kateri mehanizmi upravljanja obstajajo v pogodbi in ali je upravljanje popolnoma odprto ali omejeno?
12. Ali se v sistemu uporabljajo druge pogodbe in kakšne vloge opravljajo (npr. pogodba pooblaščenca)?
13. Ali obstaja mehanizem časovne blokade in ali ga je mogoče zaobiti?
14. Ali je na voljo ustrezna dokumentacija?
15. Ali so v kodi možne ranljivosti za napade DoS ali reentrancy?
16. Ali so vse funkcije notranje, razen tistih, za katere se izrecno zahteva, da so javne/zunanje?
17. Ali ni aritmetičnih prelivov/podlivov pri matematičnih operacijah?
18. Ali se uporablja varna knjižnica OpenZeppelin?
19. Eterja ali žetonov ni mogoče pomotoma poslati na ničelni naslov (0x0)?
20. Pred operacijami in spremembami stanja se pogoji preverijo z ukazom require?
21. Se stanje nastavi pred in med izvajanjem dejanj?
22. Se uporablja zaščita pred napadi ponovnega vstopa (reentry) (A pokliče B pokliče A)?
23. Ali je vmesnik ERC20 ustrezno implementiran?
24. Ali se modifikator uporablja na več mestih le, če je to res potrebno?
25. Ali so vsi tipi eksplicitno določeni (npr. namesto uint se uporablja uint256)?
26. Ali so vse metode in cikli znotraj največje dovoljene meje plina?
27. V konstruktorju ni nepotrebnih inicializacij (ne pozabite, da so nastavljene privzete vrednosti)?
28. Popolna pokritost s testi: testirane so vse metode pametne pogodbe in vse možne vrste vhodnih podatkov?
29. Izvedeno je bilo fuzz testiranje z uporabo naključnih vhodov?
30. I so testirana vsa možna stanja, v katerih je lahko pogodba?
31. Privzete količine etrov in žetonov so določene v enotah wei?
32. Ali blok/čas konca množične prodaje sledi bloku/času začetka (začetek/povezava trgovanja)?
33. Ali je menjalni/konverzijski tečaj žetonov množične prodaje pravilno določen?
34. Ali je določena mehka/trda omejitev množične prodaje?
35. Ali je določen in preizkušen najmanjši/najvišji dovoljeni prispevek za množično prodajo?
36. Ali je bila preizkušena funkcionalnost bele liste množične prodaje?
37. Ali je bila preverjena logika vračila v množični prodaji?
38. Ali udeleženci množične prodaje prejmejo sorazmerno število žetonov ali lahko zahtevajo svoj prispevek?
39. Ali je trajanje vsake faze množične prodaje (npr, predprodaja, javna prodaja) ustrezno konfigurirano?
40. I je določeno, katere funkcije lahko nadzira samo lastnik (npr, zaustavitev množične prodaje, prehod na drugo fazo množične prodaje, omogočanje razdeljevanja žetonov itd.")?
41. Ali je preverjena logika dodeljevanja pravic (vesting) v množični prodaji?
42. Ima množična prodaja varen način, ki, če ga omogoči lastnik, omeji klice funkcij in vključuje funkcijo vračila?
43. Crowdsale ima funkcijo povratnega delovanja, če je to smiselno.
44. Ali so bile uvožene knjižnice predhodno preverjene in ne vsebujejo nezaželenih delov, ki bi jih lahko v prihodnjih različicah zamenjali in uporabili v zlonamerne namene?
45. Metode prenosa žetonov (transfer) zavite v require?
46. So require in assert uporabljeni pravilno? Metoda assert se uporablja samo za stvari, ki se ne bi smele nikoli zgoditi, običajno se uporablja za preverjanje stanja po izvedenih spremembah.
47. Ali obstaja obramba pred napadi z rekurzivnimi klici?
48. Ali so dolžine poljubnih nizov v vhodu omejene?
49. Kjer je mogoče, se izogibajte uporabi polj in namesto njih uporabite preslikave?
50. Ali se blokovni heši ne uporabljajo za obdelavo naključnih vrednosti (rudarji lahko vplivajo na to)?
51. Nikjer se ne uporablja tx.origin?
52. Elemente matrike se ob brisanju elementa premakne navzdol, da ne bi ostale vrzeli?
53. Ali se namesto meta uporablja revert?
54. Funkcije se končajo takoj, če pogoji niso izpolnjeni?
55. So bila opozorila prevajalnika odpravljena?
56. Se pri izračunih uporablja knjižnica SafeMath?
57. Se kakšne pomnilniške reže (shranjevalne reže) berejo več kot enkrat?
58. Se uporabljajo neomejene zanke/plošče, ki bi lahko povzročile DoS?
59. Se block.timestamp uporablja samo za dolge intervale?
60. Se ne uporablja block. number za izračun pretečenega časa?
61. Se izogibamo klicu delegatecall, zlasti za zunanje (tudi če zaupanja vredne) pogodbe?
62. Se dolžina polja ne posodablja, medtem ko ga iteriramo?
63. Ali so podpisi zaščiteni pred ponovnim predvajanjem z nonce in block.chainid?
64. Preveri, ali vsi podpisi uporabljajo EIP-712?
65. Izhod abi.encodePacked() se ne sme hashirati, če se uporabljata več kot 2 dinamična tipa. Na splošno je bolje uporabiti abi.encode().
66. Skrbno preverite vstavljanje kode sklopa.
67. Izogibajte se nezadostni porabi plina (gas griefing).
68. I so vsi zasebni podatki res zasebni?
69. Ak posodobitev strukture/mape v pomnilniku (memory) je ne spremeni v shrambi (stage)?
70. Ali so spremenljivke stage zasenčene?
71. Ali je izračun vrednosti spremenljivke na poti cenejši od shranjevanja?
72. Ali se vse spremenljivke stanja berejo iz pravilne pogodbe (master proti klonu)?
73. Ali se primerjalni operatorji (>, <, >=, <=) uporabljajo pravilno, zlasti za preprečevanje napak zunaj ene vrednosti?
74. Ali se logični operatorji (==, ! =, &&, ||, !) uporabljajo pravilno, zlasti za preprečevanje napak pri deljenju?
75. Ali se množenje vedno izvede pred deljenjem (razen če se množenje lahko prelije)?
76. Ali so magična števila nadomeščena s konstanto z intuitivnim imenom?
77. Če ima prejemnik ETH povratno funkcijo (fallback ), ki jo je mogoče vrniti, bi to lahko vodilo v DoS?
78. Ali se uporablja standard SafeERC20 in ali se povratne vrednosti preverjajo na varen način?
79. Ali se predpostavlja, da je msg. pošiljatelj vedno ustrezen uporabnik?
80. Kolikor se za avtorizacijo ne uporablja parameter.origin?
81. Kolikor se namesto .call.value() ne uporablja address.transfer() ali address.send()?
82. Ko uporabljate klice na nizki ravni, se prepričajte, da pred klicem obstaja pogodba.
83. Ali se za dostop do chainid ali pogodbene kode/velikosti/pomnilnika namesto sintakse Solidity uporablja zbirna koda?
84. Ali se pri nastavitvi spremenljivke na ničelno vrednost (0, false, "" itd..) uporablja ključna beseda delete?
85. Izrazi, posredovani logičnim operatorjem/primerjavam (&&/|||/>=/==/itd.), ne smejo imeti stranskih učinkov.
86. Ko imate opravka z več naslovi, se vprašajte, kaj se zgodi, če so enaki?
87. Kako dobro je dokumentirana koda? Ali so na voljo komentarji in primeri povsod, kjer se uporablja nestandardna koda?
88. Če se uporablja zunanji klic, se prepričajte, da je klic zunanje pogodbe res potreben?
89. Ali je rezultat zunanjega klica preverjen in ali se obravnavajo napake?
90. Kaj se zgodi, če zunanji klic uporabi vse zagotovljene pline?
91. Če zunanji klic kliče določeno funkcijo, se prepričajte, da ta funkcija dejansko obstaja (fantomske funkcije).
92. Prepričajte se, da se v modifikatorjih ne uporabljajo zunanji klici (modifikatorji)
93. Ali se izdajo dogodki za vsako funkcijo, ki spreminja skladišče?
94. Preverite svoje predpostavke o tem, kaj počnejo in vračajo zunanje pogodbe, uporabljene v glavnem.
95. Pozorite na žetone, ki uporabljajo preveč ali premalo decimalk. Zagotovite, da so dokumentirane največje in najmanjše podprte vrednosti.
96. Ali so dokumentirana pooblastila, povezana z vlogami?
97. Katera so tveganja pri kršitvi pravic dostopa in kako lahko to vpliva na različne komponente sistema?
98. Ali lahko lastnik manipulira z žetoni in ETH znotraj pogodbe?
99. Kako je določen naslov Oracle (Orakelj) in kakšen je postopek v ozadju? Ali obstajajo rezervna oraklja za varnostno kopijo?
100. Kako se podobne funkcije izvajajo v drugih projektih, ali so bile upoštevane najboljše prakse?

Ta kontrolni seznam vam bo pomagal zagotoviti izvedbo temeljite varnostne revizije pametnih pogodb Solidity. Zajema številne kritične vidike za prepoznavanje in zmanjševanje morebitnih ranljivosti in tveganj v kodi in povezanih sistemih.

 

Doufamo, da so vam ti primeri pomagali bolje razumeti metodologijo revizije pametnih pogodb.

 

Ker so vse informacije v verigi blokov odprte (seveda če je izvorna koda pogodbe preverjena), lahko oboroženi s tem znanjem samostojno preučite pametne pogodbe in prepoznate različne goljufive sheme.

Vse to smo za vas že storili! Prijavite se na premijsko naročnino in pridobite dostop do ekskluzivnih filtrov o funkcijah pametnih pogodb in sveže analitike. Povečajte svoje možnosti za uspešno vlaganje v donosne žetone.

Zdravljeni, ekipa Lotus Market.

All posts