Web3 nutika lepingu turvalisuse testimine ja ametlik kinnitamine

Lugemise aeg: 9 protokoll

Kujutage ette langevarjuhüpet. Enne lennukist alla hüppamist kontrollite oma langevarju sada korda, eks? Kontrollimine ja testimine on turvalisuse lahutamatu osa; mõtle mis tahes turvalisusega seotud asjadele. Tõenäoliselt järgneb hiljem testimismehhanism, olgu see siis CCTV paigaldamine või pliiatsi tindi kontrollimine enne koolis kirjalikku eksamit, me kõik järgime ohutusmeetmeid. Mida suurem on sellega seotud risk, seda rohkem me asju testime. Ja kui me räägime nutikatest lepingutest, on risk SUUR. Nutika lepingu turvalisuse osas ei saa te olla hooletu.

1. Turvalisust on alati vaja.

Kindlasti saate ukse kaks või kolm korda lukustada, see pole oluline. Kas saate olla kindel, et teie maja ei saa röövida, kui olete ära? Te ei saa seda teha, sest te ei tea, mida röövel majja sissemurdmiseks teha võib – sama kehtib kõigi meie rakendatavate turvameetmete kohta. Pole olemas täiesti ohutut meetodit, mis ohutuse tagaks. Sellegipoolest suurendab meie kiiresti tehtav tegevus meie võimalusi olla ohutu, mida see mäng endast kujutab. Soovime erinevate meetmete abil suurendada tõenäosust olla ohutu.

Web3 maailm pole erinev. Enda päästmiseks pole turvalist meetodit, kuid QuillAuditsi kogenud audiitorite olemasolu võib teie protokolli turvalisuse tõenäosust tohutult suurendada ja tagada teie ajakohase turvalisuse. Web3-s on kaks olulist mehhanismi, mis aitavad teil mõista, kui turvaline olete, tehes oma protokolli mõned testid: -

1. Nutikas lepingute testimine
2. Nutikate lepingute ametlik kontrollimine

Mõistame neid üksikasjalikult ja uurime, kuidas need aitavad meil teada saada meie lepingute nõrku kohti või haavatavust.

2. Nutikate lepingute testimine

Kogenud arendaja oskab koodi abil masinale töö lahti seletada. Siiski ei kujuta masin mõnikord koodi vea või loogikavea tõttu täpset mehhanismi, mida arendaja silmas pidas. Testimine on protsess, mis aitab tuvastada, kus meie kood ebaõnnestub ja mida saab teha, et see vastaks toimingule, mida me vajame.

Nutikas lepingu testimine on arendustsükli etapp, mille käigus analüüsime üksikasjalikult oma lepinguid ja püüame välja selgitada, kus ja miks meie kood ebaõnnestub. Peaaegu kõik nutikad lepingud läbivad selle etapi. Nutika lepingu testimiseks on kaks võimalust. Uurime neid.

2.1 Automatiseeritud

Nagu nimigi ütleb, kasutatakse seda nutikate lepingute testimise meetodit skriptitud testimise läbiviimiseks. See hõlmab automatiseeritud tarkvara, mis viib läbi korduvaid teste, et leida nutikate lepingute haavatavused ja defektid. Neid automatiseeritud testimistööriistu saab konfigureerida testiandmete ja oodatavate tulemustega. Seejärel võrreldakse tegelikku tulemust oodatud tulemustega, et kontrollida, kas leping töötab korralikult. Automaattestimise võib jagada kolme kategooriasse.

2.1.1. Funktsionaalne testimine

Oletame, et kirjutate programmi, mis võtab kaks numbrit a ja b ning tagastate seejärel mõlema arvu liitmise. Selle programmi kontrollimiseks annate 2 ja 8 ning sisestate oodatavaks tulemuseks 10. Nüüd, kui programm töötab, peaks see tagastama ka 10. Kui see töötab, siis see töötab hästi ja meie kood on õige, aga kui see on õige. ei, siis on meie koodis viga. 

Funktsionaalne testimine eeldab mõistmist, kuidas teie leping peaks teatud tingimustes käituma. Saame seda testida, käivitades valitud väärtustega arvutuse ja võrreldes tagastatud väljundit. Funktsionaalsel testimisel on kolm klassi:

1. Ühiku testimine:- See käsitleb nutika lepingu üksikute komponentide õigsuse testimist. See on enesekindel või nõuab avaldusi muutujate kohta.

2. Integratsioon Testing: – Need käsitlevad mitme üksiku komponendi koos testimist. Integratsioonitestimine on hierarhias kõrgemal tasemel kui ühiktestimine. See aitab meil tuvastada erinevate funktsioonide koostoimest tulenevaid vigu, mis võivad olla osa teistest nutikatest lepingutest.

3. süsteem testng: – See on hierarhias kõrgeim. Selle käigus testime kogu lepingut ühe täielikult integreeritud süsteemina, et näha, kas see toimib meie vajaduste kohaselt. Seda tehakse kasutaja vaatenurgast ja parim viis seda teha on juurutada see testvõrkudesse.

2.1.2. Staatiline analüüs

Staatilist analüüsi saab teha isegi programmi käivitamata. See hõlmab nutika lepingu lähtekoodi või baitkoodi analüüsi enne täitmist. Seega võib staatilise analüüsi tulemusel oma nime anda avastada mõningaid levinud turvaauke.

2.1.3. Dünaamiline analüüs

Erinevalt staatilisest analüüsist tehakse dünaamiline analüüs nutikate lepingute tööajal, et tuvastada koodis olevad probleemid. Dünaamilised koodianalüsaatorid jälgivad lepingu tööolekut ja loovad üksikasjaliku aruande haavatavuste ja vara rikkumiste kohta. Fuzzing kuulub dünaamilise analüüsi alla. Hägustamine on vale või pahatahtliku sisendi söötmine, mis põhjustab soovimatut koodikäivitust.

2.2i kasutusjuhend

Nagu nimigi ütleb, hõlmab see nutika lepingu testimise meetod regulaarset suhtlemist inimarendajaga. Koodiauditid, kus arendajad läbivad koodiridu, kuuluvad nutika lepingu testimise käsitsi režiimi alla.

Käsirežiim nõuab märkimisväärset aega, oskusi, raha ja vaeva. Siiski on tulemus sageli seda väärt, sest selle abil tuvastame haavatavused, mis võivad automaatse testimise käigus märkamatuks jääda. Käsitsi testimisel on kaks peamist tüüpi:

2.2.1 Koodikontrollid: 

Parim viis kontrollida, kas teie ohutusmeede töötab korralikult, on proovida seda murda. Näiteks kui soovite kontrollida, kas teie auto lukk töötab korralikult, proovige see lõhkuda. Nüüd võite küsida, et osav autovaras võib kergesti minu autosse sisse murda. Ma ei pruugi, nii et lahendus on palgata keegi, kes on vilunud sissemurdmises, et ta saaks teid juhendada!

 Jah, ma räägin QuillAuditsist. Oleme kvalifitseeritud audiitorite meeskond, kes saab teid juhendada. Koodiauditid nõuavad ründaja mõtteviisi, et leida lähtekoodis kõik võimalikud haavatavused. Koodiaudit on nutika lepingu koodi üksikasjalik hindamine, et avastada võimalikud haavatavused ja vead.

2.2.2 Bug Bounty:-

Kui arvate, et teie lähtekoodis võib olla turvavigu (mis enamasti on) ja te ei leia neid, saate selle töö tellida vabakutselistelt, luues preemiasüsteemi. See on pigem nagu preemia väljakuulutamine kõigile, kes saavad teie nutika lepingu häkkida. Seda tehes saate teada oma nutikas lepingus olevast haavatavusest, et saaksite seda paremini kaitsta ja säästa kasutajaid kadumise eest.

3. Nutikate lepingute ametlik kontrollimine

Ametlik kontrollimine on lepingu õigsuse hindamise protsess, mis põhineb formaalsetel spetsifikatsioonidel. See tähendab, et ametlik kontrollimine hindab, kas kood teeb seda, mis on ette nähtud. Ametlik kontrollimine kasutab programmide täpsustamiseks, kavandamiseks ja kontrollimiseks formaalseid meetodeid.

3.1 Mis on ametlik spetsifikatsioon?

Nutikate lepingute kontekstis viitavad formaalsed spetsifikatsioonid omadustele, mis peavad jääma igal võimalikul juhul samaks. Need on "invariantide" omadused, kuna need ei saa muuta ega esindada loogilisi väiteid lepingu täitmise kohta.

Formaalne spetsifikatsioon on formaalses keeles kirjutatud väidete kogum. Spetsifikatsioonid hõlmavad erinevaid omadusi ja kirjeldavad, kuidas lepingu omadused peaksid teistes tingimustes käituma. Formaalsed spetsifikatsioonid on kriitilise tähtsusega, sest kui lepingutes ei ole muutumatuid muutujaid või omadused ei muutu täitmise ajal, võib see kaasa tuua võimaliku vara ärakasutamise, mis võib kaasa tuua tohutu kahju.

See võib aidata meil kindlaks teha, kas nutikas leping vastab spetsifikatsioonidele või käitub ootamatult. Ametlikul kontrollimisel on kolm komponenti: spetsifikatsioon, mudel ja kinnitusmootor.

3.1.1 Spetsifikatsioon

Spetsifikatsioon on nutika lepingu nõuete selge, üheselt mõistetav ja täielik kirjeldus. See peaks kirjeldama, mida leping peaks tegema ja mida mitte. Siin on näide lihtsa nutika lepingu spetsifikatsioonist, mis lisab kaks numbrit:

// 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 mudel

Mudel esindab formaalselt nutikat lepingut, mida saab kasutada selle käitumise arutlemiseks. Üks populaarne nutikate lepingute mudel on Solidity programmeerimiskeel. Siin on ülalkirjeldatud lisamisfunktsiooni näide:

// 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 Taatlusmootor

Verifitseerimismootor on tööriist, mis suudab analüüsida mudelit ja kontrollida selle õigsust antud spetsifikatsiooni suhtes. Nutikate lepingute jaoks on saadaval mitu kinnitusmootorit, sealhulgas:

Müüt: avatud lähtekoodiga sümboolne täitmistööriist, mis suudab tuvastada laias valikus Solidity nutikate lepingute turvaauke.

Remix IDE: integreeritud arenduskeskkond, mis sisaldab ametlikku kontrollitööriista, millega saab kontrollida nutikate lepingute õigsust.

Certora Prover: kaubanduslik tööriist, mis suudab automatiseeritud matemaatilise arutluskäigu abil kontrollida nutikate lepingute õigsust. Siin on näide, kuidas ametlikku kinnitamist saab kasutada nutika lepingu õigsuse kontrollimiseks Certora Proveri abil:

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);
}
}

Ülaltoodud näites määratleme Solidity nutika lepingu, mis sisaldab lisamisfunktsiooni mudelit, funktsiooni spetsifikatsiooni ja kinnitusmootorit (Certora Prover), mis suudab funktsiooni õigsust kontrollida. Samuti määratleme testfunktsiooni (test_add), mida saab kasutada funktsiooni õigsuse kontrollimiseks.

3.2 VS formaalse kontrolli testimine

Nagu arutasime, tagastab testimine oodatud tulemuse mõne sisendandmete roboti puhul, mis sellel puudub, kuna me ei saa öelda andmete kohta, mille puhul seda pole testitud. Seda on praktiliselt võimatu igal võimalikul sisendil kontrollida. Seega pole me kindlad selle "funktsionaalses õigsuses". Siin tulebki sisse formaalne kontrollimine. Ametlikud kontrollimeetodid kasutavad tarkvara või nutikate lepingute täpsustamiseks ja kontrollimiseks rangeid matemaatilisi meetodeid.

3.3 Ametliku kontrolli tehnikad

Ametlikul kontrollimisel on tõhustamiseks lai valik tehnikaid tark lepingu turvalisus. Selles ajaveebi osas uurime mõnda üksikut.

3.3.1 Mudeli kontroll

Kui arutasime, mis on ametlik spetsifikatsioon, kontrollime nutikat lepingut selle ametliku kontrollitehnika spetsifikatsiooniga. Need nutikad lepingud on kujutatud olekute üleminekusüsteemidena ja omadused on määratletud ajalise loogika abil. 

Seda tehnikat kasutatakse peamiselt ajaliste omaduste hindamiseks, mis kujutavad arukate lepingute käitumist aja jooksul. Juurdepääsu kontrolli atribuut (administraatori helistamine enesehäving) saab kirja panna kui formaalset loogikat. Seejärel saab mudelikontrolli algoritm kontrollida, kas leping vastab sellele ametlikule kontrollile.

Mudeli kontrollimisel kasutatakse tehnikat nimega State Space exploration, mis põhimõtteliselt katsetab kõiki võimalikke olekuid, milles meie nutikas leping võib olla, ja seejärel kontrollib, kas mõni neist toob kaasa vara rikkumise. See võib aga viia lõputult paljude olekuteni; seega tuginevad mudelite kontrollijad arukate lepingute tõhusa analüüsi tegemiseks abstraktsioonitehnikatele.

3.3.2 Teoreemi tõestamine

Teoreemide tõestamine puudutab matemaatilist arutlust programmide õigsuse kohta. See käsitleb lepingu süsteemist ja spetsifikatsioonist loogilise mulje loomist ning väidete vahelise “loogilise samaväärsuse” kontrollimist. Loogiline ekvivalentsus on matemaatiline seos, mis ütleb, et väide A on tõene siis ja ainult siis, kui väide B on tõene.

Nagu mudeli kontrollimise tehnikas õppisime, modelleerime lepinguid lõplike olekutega üleminekusüsteemidena. Teoreemide tõestamine saab hakkama lõpmatu olekuga süsteemide analüüsiga. Kuid automaatne teoreemi tõestaja ei saa alati teada, kas loogikaülesanne on otsustatav; seega on sageli vaja inimese abi, et teoreemi tõestajat õigsusetõestuste tuletamisel suunata.

4. järeldus

Testimine ja ametlik kontrollimine on mõlemad arukate lepingute arendamise lahutamatud osad. Neid meetodeid kasutatakse nutikate lepingute turvaliseks muutmiseks ja lepingute kasutuselevõtuks ettevalmistamiseks. Kuid nagu teate, ei piisa turvalisusest kunagi. Paljusid nutikaid lepinguid häkiti lihtsalt seetõttu, et puudus korralik testimine. Nüüd vajab web3 kogukond rohkem kui kunagi varem turvalisemaid protokolle. 

Meie, QuillAudits, missioon on aidata kaitsta teie protokolle. Oma osava ja kogenud meeskonnaga hoolitseme selle eest, et ükski haavatavus ei jääks märkamatuks. Külastage meie veebisaiti ja kindlustage oma Web3 projekt!

28 views

• SEO-põhise sisu ja PR-levi. Võimenduge juba täna.
• Platoblockchain. Web3 metaversiooni intelligentsus. Täiustatud teadmised. Juurdepääs siia.
• Allikas: https://blog.quillhash.com/2023/02/16/testing-and-formal-verification/