A Web3 Smart Contract Security tesztelése és formális ellenőrzése

Olvasási idő: 9 jegyzőkönyv

Képzeld el, hogy ejtőernyőzni fogsz. Mielőtt leugrasz a gépről, százszor is megnézed az ejtőernyődet, igaz? Az ellenőrzés és tesztelés a biztonság szerves részét képezi; gondoljon bármilyen biztonsággal kapcsolatos dologra. Valószínűleg lenne egy utólagos tesztelési mechanizmus, legyen szó CCTV felszereléséről vagy a tollban lévő tinta ellenőrzéséről az iskolai írásbeli vizsga előtt, mindannyian betartjuk a biztonsági intézkedéseket. Minél nagyobb a kockázat, annál jobban teszteljük a dolgokat. És ha intelligens szerződésekről beszélünk, a kockázat HATALMAS. Nem lehet hanyag, amikor az intelligens szerződésbiztonságról van szó.

1. A biztonságra mindig szükség van.

Nem számít, hogy kétszer vagy háromszor bezárhatod az ajtót. Biztos lehet benne, hogy a házát nem lehet kirabolni, amíg távol van? Nem teheti meg, mert nem tudja, mit tehet a rabló, hogy behatoljon a házba – ugyanez igaz minden általunk megtett biztonsági intézkedésre. Nincs teljesen biztonságos módszer, amely garantálná a biztonságot. Ennek ellenére a gyors cselekvésünk növeli az esélyeinket a biztonságra, ami a játék lényege. Különféle intézkedésekkel szeretnénk növelni a biztonság esélyét.

A Web3 világa nem más. Nincs biztonságos módszer arra, hogy megmentse magát, de a QuillAudits tapasztalt auditorai rendkívüli mértékben megnövelhetik annak esélyét, hogy protokollja biztonságban legyen, és biztosítja a naprakész biztonságot. A web3-ban két fontos mechanizmus segít megérteni, mennyire biztonságos a protokollja tesztelésével: -

1. Intelligens szerződés tesztelése
2. Intelligens szerződések formális ellenőrzése

Ismerjük meg ezeket részletesen, és tanuljuk meg, hogyan segítenek megismerni szerződéseink gyenge pontjait vagy sebezhetőségeit.

2. Intelligens szerződés tesztelése

Egy tapasztalt fejlesztő kóddal el tudja magyarázni a munkát a gépnek. Ennek ellenére előfordul, hogy a gép a kód hibája vagy logikai hibája miatt nem pontosan azt a mechanizmust ábrázolja, amelyre a fejlesztő gondolt. A tesztelés az a folyamat, amely segít azonosítani, hol hibás a kódunk, és mit tehetünk annak érdekében, hogy megfeleljen a szükséges műveletnek.

Intelligens szerződés tesztelése a fejlesztési ciklus egy szakasza, amelyben részletes elemzést végzünk szerződéseinkről, és megpróbáljuk kideríteni, hol és miért hibásodik meg a kódunk. Szinte minden intelligens szerződés átesik ezen a fázison. Az intelligens szerződések tesztelésének két módja van. Fedezzük fel őket.

2.1 Automatizált

Ahogy a neve is sugallja, az intelligens szerződések tesztelésének ezt a módszerét parancsfájltesztek végrehajtására használják. Ez olyan automatizált szoftvereket foglal magában, amelyek ismételt teszteket hajtanak végre az intelligens szerződések sebezhetőségeinek és hibáinak feltárására. Ezek az automatizált tesztelőeszközök a tesztadatokkal és a várt eredményekkel konfigurálhatók. Ezután a tényleges eredményt összehasonlítják a várttal, hogy ellenőrizzék, megfelelően működik-e a szerződés. Az automatizált tesztelés további három kategóriába sorolható.

2.1.1. Funkcionális tesztelés

Tegyük fel, hogy írunk egy programot, amely két számot, a-t és b-t vesz fel, majd mindkét szám összeadását adja vissza. Tehát a program ellenőrzéséhez adjon meg 2-t és 8-at, és a várt eredményt 10-nek adja. Most, amikor a program fut, 10-et is kell visszaadnia. Ha igen, akkor jól működik, és a kódunk helyes, de ha az nem, akkor valami hiba van a kódunkban. 

A funkcionális teszteléshez meg kell érteni, hogyan kell a szerződésnek bizonyos feltételek mellett viselkednie. Tesztelhetjük úgy, hogy egy számítást futtatunk a kiválasztott értékekkel és összehasonlítjuk a visszaadott kimenetet. A funkcionális tesztelésnek három osztálya van:

1. Egység tesztelése:- Ez az intelligens szerződés egyes összetevőinek helyességének ellenőrzésével foglalkozik. Asszertív, vagy változókra vonatkozó utasításokat igényel.

2. Integráció tesztng: – Ezek több egyedi komponens együttes tesztelésével foglalkoznak. Az integrációs tesztelés magasabb szinten van a hierarchiában, mint az egységteszt. Segít meghatározni a különböző funkciók interakciójából adódó hibákat, amelyek más intelligens szerződések részét képezhetik.

3. rendszer tesztng: – Ez a legmagasabb a hierarchiában. Ennek során a teljes szerződést egy teljesen integrált rendszerként teszteljük, hogy megnézzük, az igényeinknek megfelelően teljesít-e. Ez a felhasználó szemszögéből történik, és a legjobb módja annak, hogy telepítse a testnetekre.

2.1.2. Statikus elemzés

A statikus analízis a program futtatása nélkül is elvégezhető. Ez magában foglalja az intelligens szerződés forráskódjának vagy bájtkódjának elemzését a végrehajtás előtt. Így a statikus elemzés a nevének megadásával néhány gyakori sérülékenység felderítését eredményezheti.

2.1.3. Dinamikus elemzés

A statikus elemzéstől eltérően a dinamikus elemzés az intelligens szerződések futási ideje alatt történik a kódbeli problémák azonosítása érdekében. A dinamikus kódelemzők megfigyelik a szerződés futási állapotát, és részletes jelentést készítenek a sebezhetőségekről és a tulajdonjog megsértéseiről. A fuzzing a Dinamikus elemzés alá tartozik. A fuzzing helytelen vagy rosszindulatú bevitel táplálása, amely nem kívánt kódfuttatást okoz.

2.2 kézikönyv

Ahogy a neve is sugallja, az intelligens szerződések tesztelésének ez a módszere rendszeres interakciót foglal magában egy emberi fejlesztővel. A kódellenőrzések, amelyek során a fejlesztők kódsorokon mennek keresztül, az intelligens szerződések tesztelésének kézi üzemmódjába tartoznak.

A kézi üzemmód jelentős időt, szakértelmet, pénzt és erőfeszítést igényel. Ennek ellenére az eredmény gyakran megéri, mert ezzel azonosítjuk azokat a sebezhetőségeket, amelyek az automatikus tesztelés során észrevétlenek maradhatnak. A kézi tesztelésnek két alapvető típusa van:

2.2.1 Kódellenőrzések:- 

A legjobb módszer annak tesztelésére, hogy a biztonsági intézkedés megfelelően működik-e, ha megpróbálja megszegni. Például, ha ellenőrizni szeretné, hogy az autózár megfelelően működik-e, próbálja meg feltörni. Most megkérdezheti, hogy egy ügyes autótolvaj könnyen betörhet az autómba. Lehet, hogy nem, szóval a megoldás az, hogy felvesz valakit, aki jártas a betörésben, hogy ő irányíthasson!

 Igen, a QuillAuditsról beszélek. Szakképzett auditorokból álló csapat vagyunk, akik útmutatást nyújtanak Önnek. A kódellenőrzésekhez támadói gondolkodásmód szükséges, hogy megtalálja a forráskód összes lehetséges sebezhetőségét. A kódellenőrzés az intelligens szerződés kódjának részletes kiértékelése a lehetséges sebezhetőségek és hibák feltárása érdekében.

2.2.2 Bug Bounty:-

Ha úgy gondolja, hogy biztonsági hibák lehetnek a forráskódjában (amelyek többnyire vannak), és nem találja őket, akkor ezt a munkát szabadúszókra bízhatja egy jutalmazási rendszer létrehozásával. Ez inkább olyan, mintha jutalmat hirdetne ki mindenkinek, aki feltörheti az intelligens szerződését. Ezzel megismerheti az intelligens szerződésben található sebezhetőséget, így jobban megvédheti azt, és megóvhatja a felhasználókat a veszteségtől.

3. Intelligens szerződések formális ellenőrzése

A formális ellenőrzés az a folyamat, amelynek során formális előírások alapján értékelik a szerződés helyességét. Ez azt jelenti, hogy a formális ellenőrzés felméri, hogy a kód megfelel-e a szándéknak. A formális ellenőrzés formális módszereket használ a programok meghatározására, tervezésére és ellenőrzésére.

3.1 Mi a formális specifikáció?

Az intelligens szerződésekkel összefüggésben a formális specifikációk azokra a tulajdonságokra vonatkoznak, amelyeknek minden lehetséges körülmény között változatlannak kell maradniuk. Ezek „invariáns” tulajdonságok, mivel nem változtathatnak és nem képviselhetnek logikai állításokat a szerződés végrehajtásáról.

A formális specifikáció formális nyelven írt állítások gyűjteménye. A specifikációk különböző tulajdonságokra vonatkoznak, és leírják, hogy a szerződés tulajdonságainak hogyan kell viselkedniük más körülmények között. A formális specifikációk kritikusak, mert ha a szerződések nem tartalmaznak invariáns változókat vagy a tulajdonságok nem változnak meg a végrehajtás során, az ingatlanok esetleges kihasználásához vezethet, ami hatalmas veszteséghez vezethet.

Segítségével megállapíthatjuk, hogy egy intelligens szerződés megfelel-e az előírásoknak, vagy van-e váratlan viselkedése. A formális ellenőrzésnek három összetevője van: egy specifikáció, egy modell és egy ellenőrző motor.

3.1.1 Specifikáció

A specifikáció világos, egyértelmű és teljes leírása az intelligens szerződés követelményeinek. Le kell írnia, hogy a szerződésnek mit kell tennie, és mit nem. Íme egy példa specifikáció egy egyszerű, intelligens szerződéshez, amely két számot ad hozzá:

// Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
// Implementation details are not relevant to the specification
// …
}

3.1.2 modell

A modell formálisan reprezentálja az intelligens szerződést, amely felhasználható a viselkedésére vonatkozó érvelésre. Az intelligens szerződések egyik népszerű modellje a Solidity programozási nyelv. Íme egy példamodell a fent leírt add funkcióhoz:

// Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
return a + b;
}

3.1.3 Ellenőrző motor

Az ellenőrző motor egy olyan eszköz, amely képes elemezni egy modellt és ellenőrizni annak helyességét egy adott specifikációra vonatkozóan. Számos ellenőrző motor áll rendelkezésre az intelligens szerződésekhez, többek között:

Mythrill: nyílt forráskódú szimbolikus végrehajtó eszköz, amely képes észlelni a Solidity intelligens szerződéseinek biztonsági réseinek széles körét.

Remix IDE: integrált fejlesztői környezet, amely tartalmaz egy formális ellenőrző eszközt, amely képes ellenőrizni az intelligens szerződések helyességét.

Certora Prover: egy kereskedelmi eszköz, amely automatizált matematikai érveléssel tudja ellenőrizni az intelligens szerződések helyességét. Íme egy példa arra, hogyan használható formális ellenőrzés egy intelligens szerződés helyességének ellenőrzésére a Certora Prover segítségével:

pragma solidity 0.7.6; // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint)
function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function test_add(uint a, uint b) public pure returns (bool) {
uint expected = a + b;
uint actual = add(a, b);
return expected == actual;
} // Verification: Verify the correctness of the add function contract TestAdd {
function test_add(uint a, uint b) public view returns (bool) {
return CertoraProver.verify(test_add, a, b);
}
}

A fenti példában egy Solidity intelligens szerződést definiálunk, amely tartalmazza az add funkció modelljét, a funkció specifikációját és egy ellenőrző motort (Certora Prover), amely képes ellenőrizni a funkció helyességét. Definiálunk egy tesztfüggvényt is (test_add), amellyel ellenőrizhetjük a függvény helyességét.

3.2 A VS formális ellenőrzés tesztelése

Amint azt már megbeszéltük, a tesztelés a várt eredményt adja néhány olyan bemeneti adatbot esetében, amely hiányzik, mivel nem tudjuk megmondani, hogy milyen adatokon nem tesztelték. Gyakorlatilag lehetetlen minden lehetséges bemeneten ellenőrizni. Így nem vagyunk biztosak a „funkcionális helyességében”. Itt jön be a formális ellenőrzés. A formális ellenőrzési módszerek szigorú matematikai technikákat használnak a szoftverek vagy intelligens szerződések meghatározására és ellenőrzésére.

3.3 A formális ellenőrzés technikái

A formális ellenőrzésnek számos technikája van a javításra intelligens szerződésbiztonság. A blog ezen részében néhányat külön-külön megvizsgálunk.

3.3.1 Modellellenőrzés

Miközben megvitattuk, mi a formális specifikáció, ellenőrizzük az intelligens szerződést ennek a formális ellenőrzési technikának a specifikációihoz képest. Ezeket az intelligens szerződéseket állapotátmeneti rendszerekként ábrázolják, és a tulajdonságokat időbeli logika segítségével határozzák meg. 

Ezt a technikát elsősorban az intelligens szerződések időbeli viselkedését bemutató időbeli tulajdonságok értékelésére használják. Hozzáférés-vezérlés tulajdonság (adminisztrátori hívás önpusztító) formális logikaként írható le. Ezután a modellellenőrző algoritmus ellenőrizni tudja, hogy a szerződés teljesíti-e ezt a formális ellenőrzést.

A modellellenőrzés a State Space exploration nevű technikát alkalmazza, amely lényegében az okosszerződésünk összes lehetséges állapotát kipróbálja, majd ellenőrzi, hogy valamelyik nem eredményez-e tulajdonsértést. Ez azonban végtelenül sok állapothoz vezethet; ezért a modellellenőrzők absztrakciós technikákra támaszkodnak, hogy lehetővé tegyék az intelligens szerződések hatékony elemzését.

3.3.2 Tételbizonyítás

A tételbizonyítás a programok helyességére vonatkozó matematikai érvelésről szól. A szerződés rendszerének és specifikációjának logikai benyomásának kialakításával, valamint a nyilatkozatok közötti „logikai egyenértékűség” ellenőrzésével foglalkozik. A logikai ekvivalencia olyan matematikai összefüggés, amely szerint az A állítás akkor és csak akkor igaz, ha a B állítás igaz.

Amint azt a modellellenőrzési technikánál megtanultuk, a szerződéseket véges állapotú átmeneti rendszerként modellezzük. A tételbizonyítás képes végtelen állapotú rendszerek elemzésére. Az automatizált tételbizonyító azonban nem mindig tudhatja, hogy egy logikai probléma eldönthető-e; így gyakran emberi segítségre van szükség ahhoz, hogy a tételbizonyítót vezesse a helyességbizonyítások levezetésében.

4. Következtetés

A tesztelés és a formális ellenőrzés egyaránt az intelligens szerződésfejlesztés szerves részét képezi. Ezekkel a módszerekkel teszik biztonságossá az intelligens szerződéseket, és segítik a szerződések bevezetésre kész állapotát. De mint tudod, a biztonság sosem elég. Sok intelligens szerződést csak azért törtek fel, mert nem volt megfelelő tesztelés. A web3 közösségnek most minden eddiginél nagyobb szüksége van biztonságosabb protokollokra. 

Mi, a QuillAudits küldetése, hogy segítsünk protokolljai védelmében. Ügyes és tapasztalt csapatunkkal gondoskodunk arról, hogy egyetlen sebezhetőség se maradjon észrevétlen. Látogassa meg weboldalunkat, és biztosítsa Web3 projektjét!

28 Nézetek

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. Hozzáférés itt.
• Forrás: https://blog.quillhash.com/2023/02/16/testing-and-formal-verification/