Testing og formell verifisering for Web3 Smart Contract Security

Testing og formell verifisering for Web3 Smart Contract Security

Tidsstempel: 16. februar 2023 4:10
Testing og formell verifisering for Web3 Smart Contract Security PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Lesetid: 9 minutter

Tenk deg å gå fallskjermhopping. Før du hopper av flyet, vil du se etter fallskjermen hundre ganger, ikke sant? Kontroll og testing er en integrert del av sikkerheten; tenke på alle sikkerhetsrelaterte ting. Det vil sannsynligvis være en mekanisme for testing etterpå, enten det er installasjon av CCTV eller sjekk av blekket i pennen før en skriftlig eksamen på skolen, vi følger alle sikkerhetstiltak. Jo høyere risiko det er, jo mer tester vi ting. Og når vi snakker om smarte kontrakter, er risikoen STOR. Du kan ikke være uforsiktig når det kommer til smart kontraktssikkerhet.

1. Sikkerhet er alltid nødvendig.

Du kan sikkert låse døren to eller tre ganger spiller ingen rolle. Kan du være sikker på at huset ditt ikke kan bli ranet mens du er borte? Du kan ikke fordi du ikke vet hva raneren kan gjøre for å bryte seg inn i huset – det samme gjelder for alle sikkerhetstiltak vi tar. Det er ingen helt sikker metode som garanterer sikkerhet. Likevel øker handlingen vi tar raskt sjansene våre for å være trygge, og det er det spillet er. Vi ønsker å øke sjansene for å være trygge ved å ta i bruk ulike tiltak.

Web3-verdenen er ikke annerledes. Det er ingen sikker metode for å redde deg selv, men å ha erfarne revisorer fra QuillAudits kan øke sjansene for at protokollen din blir sikret enormt og vil sikre din oppdaterte sikkerhet. I web3 er det to viktige mekanismer som hjelper deg å forstå hvor sikker du er ved å gjøre noen tester på protokollen din:-

  1. Smart kontraktstesting
  2. Formell verifisering av smarte kontrakter

La oss forstå dem i detalj og lære hvordan de hjelper oss å kjenne kontraktenes svakheter eller sårbarheter.

2. Smart kontraktstesting

En erfaren utvikler kan forklare arbeidet til en maskin med kode. Likevel, noen ganger viser ikke maskinen den nøyaktige mekanismen utvikleren hadde i tankene på grunn av en feil eller en logisk feil i koden. Testing er prosessen som hjelper til med å identifisere hvor koden vår feiler og hva som kan gjøres for å få den til å samsvare med handlingen vi trenger den for å utføre.

Smart kontraktstesting er en fase i utviklingssyklusen der vi utfører en detaljert analyse av våre kontrakter og prøver å finne ut hvor og hvorfor koden vår svikter. Nesten alle smarte kontrakter gjennomgår denne fasen. Det er to måter smart kontrakttesting utføres på. La oss utforske dem.

2.1 Automatisert

Som navnet antyder, brukes denne metoden for testing av smarte kontrakter til å utføre skripttesting. Det involverer automatisert programvare som utfører gjentatte tester for å finne eventuelle sårbarheter og mangler i smarte kontrakter. Disse automatiserte testverktøyene kan konfigureres med testdata og forventede resultater. Deretter sammenlignes det faktiske resultatet med de forventede for å sjekke om kontrakten fungerer som den skal. Automatisert testing kan videre klassifiseres i tre kategorier.

2.1.1. Funksjonstesting

Anta at du skriver et program for å ta to tall, a og b, og deretter returnere addisjonen av begge tallene. Så for å sjekke det programmet, gir du 2 og 8 og mater det forventede resultatet til å være 10. Nå når programmet kjører, skal det også returnere 10. Hvis det gjør det, så fungerer det fint, og koden vår er riktig, men hvis den ikke, så er det en feil med koden vår. 

Funksjonstesting krever forståelse for hvordan kontrakten din skal oppføre seg under visse forhold. Vi kan teste det ved å kjøre en beregning med utvalgte verdier og sammenligne den returnerte utgangen. Funksjonell testing har tre klasser: -

  1. Enhetstesting:- Dette omhandler testing av individuelle komponenter i den smarte kontrakten for korrekthet. Det er selvsikkert eller krever utsagn om variabler.
  1. Integrasjon testng: – Disse omhandler testing av flere enkeltkomponenter sammen. Integrasjonstesting er et nivå høyere i hierarkiet enn enhetstesting. Det hjelper oss å finne feil som oppstår fra samspillet mellom forskjellige funksjoner, som kan være en del av andre smarte kontrakter.
  1. System teksterng: – Dette er det høyeste i hierarkiet. I dette tester vi hele kontrakten som ett fullt integrert system for å se om det fungerer i henhold til våre behov. Det gjøres fra brukerens synspunkt, og den beste måten å gjøre det på er å distribuere det på testnett.

2.1.2. Statisk analyse

Statisk analyse kan gjøres uten engang å kjøre programmet. Det innebærer analyse av kildekoden eller bytekoden til den smarte kontrakten før utførelse. Med navnet sitt kan statisk analyse resultere i oppdagelse av noen vanlige sårbarheter.

2.1.3. Dynamisk analyse

I motsetning til statisk analyse, utføres dynamisk analyse i løpet av kjøretiden til de smarte kontraktene for å identifisere problemer i kode. De dynamiske kodeanalysatorene observerer kontraktens driftstilstand og genererer en detaljert rapport om sårbarheter og brudd på eiendom. Fuzzing kommer under dynamisk analyse. Fuzzing mater feil eller ondsinnet inndata for å forårsake utilsiktet kodekjøring.

2.2 Manuell

Som navnet antyder, innebærer denne metoden for smart kontraktstesting regelmessig interaksjon med en menneskelig utvikler. Koderevisjoner, der utviklere går gjennom linjer med koder, kommer under den manuelle modusen for smart kontraktstesting.

Manuell modus krever betydelig tid, dyktighet, penger og krefter. Likevel er resultatet ofte verdt det fordi vi med dette identifiserer sårbarheter som kan bli ubemerket i den automatiske testingen. Det er to viktige typer manuell testing:

2.2.1 Kode revisjoner:- 

Den beste måten å teste om sikkerhetstiltaket fungerer som det skal, er å prøve å bryte det. Hvis du for eksempel vil sjekke om billåsen din fungerer som den skal, prøv å bryte den. Nå kan du spørre om at en dyktig biltyv lett kan bryte seg inn i bilen min. Det kan hende jeg ikke, så løsningen er å ansette en som er flink til å bryte inn slik at han kan veilede deg!

 Ja, jeg snakker om QuillAudits. Vi er et team av dyktige revisorer som kan veilede deg. Koderevisjoner krever en angripertankegang for å finne alle mulige sårbarheter i kildekoden. En koderevisjon er en detaljert evaluering av en smart kontrakts kode for å avdekke potensielle sårbarheter og feil.

2.2.2 Bug Bounty:-

Hvis du tror det kan være noen sikkerhetsfeil i kildekoden din (som stort sett er det) og du ikke finner dem, kan du sette ut dette arbeidet til frilansere ved å opprette et belønningssystem. Det er mer som å kunngjøre en belønning for alle som kan hacke den smarte kontrakten din. Ved å gjøre dette lærer du om sårbarheten i smartkontrakten din, slik at du kan beskytte den bedre og redde brukerne dine fra tap.

3. Formell verifisering av smarte kontrakter

Formell verifisering er prosessen med å evaluere riktigheten av en kontrakt basert på formelle spesifikasjoner. Dette betyr at formell verifisering vurderer om koden gjør det som er tiltenkt. Formell verifisering bruker formelle metoder for å spesifisere, designe og verifisere programmer.

3.1 Hva er den formelle spesifikasjonen?

I sammenheng med smarte kontrakter refererer formelle spesifikasjoner til egenskapene som må forbli de samme under alle mulige omstendigheter. Dette er "invariante" egenskaper fordi de ikke kan endres og representerer logiske påstander om kontraktens utførelse.

Formell spesifikasjon er en samling av utsagn skrevet på formelt språk. Spesifikasjoner dekker ulike egenskaper og beskriver hvordan kontraktens egenskaper skal oppføre seg under andre forhold. Formelle spesifikasjoner er kritiske fordi hvis kontrakter ikke har invariante variabler eller egenskaper endres under utførelse, kan det føre til mulig eiendomsutnyttelse, noe som kan føre til et stort tap.

Det kan hjelpe oss å avgjøre om en smart kontrakt oppfyller spesifikasjonene eller har uventet oppførsel. Formell verifisering har tre komponenter: en spesifikasjon, en modell og en verifiseringsmotor.

3.1.1 Spesifikasjon

En spesifikasjon er en klar, entydig og fullstendig beskrivelse av kravene til en smart kontrakt. Den skal beskrive hva kontrakten skal gjøre og hva den ikke skal gjøre. Her er et eksempelspesifikasjon for en enkel, smart kontrakt som legger til to tall:

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

En modell representerer formelt den smarte kontrakten som kan brukes til å resonnere om dens oppførsel. En populær modell for smarte kontrakter er programmeringsspråket Solidity. Her er en eksempelmodell for add-funksjonen beskrevet ovenfor:

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

En verifikasjonsmotor er et verktøy som kan analysere en modell og verifisere riktigheten i forhold til en gitt spesifikasjon. Det er flere verifiseringsmotorer tilgjengelig for smarte kontrakter, inkludert:

Mythril: et symbolsk utførelsesverktøy med åpen kildekode som kan oppdage et bredt spekter av sikkerhetssårbarheter i Solidity smarte kontrakter.

Remix IDE: et integrert utviklingsmiljø som inkluderer et formelt verifiseringsverktøy som kan verifisere riktigheten av smarte kontrakter.

Certora Prover: et kommersielt verktøy som kan verifisere riktigheten av smarte kontrakter ved hjelp av automatiserte matematiske resonnementer. Her er et eksempel på hvordan formell verifisering kan brukes til å verifisere riktigheten av en smart kontrakt ved å bruke Certora Prover:

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

I eksemplet ovenfor definerer vi en Solidity smart kontrakt som inkluderer en modell av add-funksjonen, en spesifikasjon for funksjonen og en verifikasjonsmotor (Certora Prover) som kan verifisere riktigheten av funksjonen. Vi definerer også en testfunksjon (test_add) som kan brukes til å verifisere funksjonens korrekthet.

3.2 Testing VS formell verifisering

Som vi diskuterte, returnerer testing det forventede resultatet for noen inndataroboter den mangler fordi vi ikke kan si noe om dataene den ikke har blitt testet på. Det er praktisk talt umulig å sjekke det på alle mulige input. Derfor er vi ikke sikre på dens "funksjonelle korrekthet". Det er her formell verifisering kommer inn. Formelle verifiseringsmetoder bruker strenge matematiske teknikker for å spesifisere og verifisere programvare eller smarte kontrakter.

3.3 Teknikker for formell verifisering

Formell verifisering har et bredt spekter av teknikker for å forbedre smart kontraktsikkerhet. I denne delen av bloggen skal vi utforske noen enkeltvis.

3.3.1 Modellkontroll

Mens vi diskuterte hva en formell spesifikasjon er, sjekker vi den smarte kontrakten mot spesifikasjonen i denne formelle verifiseringsteknikken. Disse smarte kontraktene er representert som tilstandsovergangssystemer, og egenskaper er definert ved hjelp av tidslogikk. 

Denne teknikken brukes først og fremst til å evaluere tidsmessige egenskaper som viser oppførselen til smarte kontrakter over tid. Tilgangskontrollegenskap (admin kaller selvdestruksjon) kan skrives ned som formell logikk. Deretter kan modellsjekkingsalgoritmen verifisere om kontrakten tilfredsstiller denne formelle verifiseringen.

Modellsjekking bruker en teknikk som kalles State Space Exploration, som i utgangspunktet prøver ut alle mulige tilstander vår smarte kontrakt kan være i og deretter sjekke om noe av det resulterer i et eiendomsbrudd. Dette kan imidlertid føre til uendelig mange tilstander; Derfor er modellsjekkere avhengige av abstraksjonsteknikker for å gjøre en effektiv analyse av smarte kontrakter mulig.

3.3.2 Teorembevis

Teorembevising handler om matematisk resonnement om riktigheten av programmer. Den omhandler å skape et logisk inntrykk av kontraktens system og spesifikasjon og verifisere den «logiske ekvivalensen» mellom utsagnene. Logisk ekvivalens er et matematisk forhold som sier at påstand A er sant hvis og bare hvis påstand B er sant.

Som vi lærte i modellsjekkingsteknikken, modellerer vi kontrakter som overgangssystemer med endelige tilstander. Teorembevising kan håndtere analyse av uendelig-tilstandssystemer. En automatisert teorembeviser kan imidlertid ikke alltid vite om et logisk problem kan avgjøres; derfor kreves det ofte menneskelig assistanse for å veilede teorembeviset i å utlede korrekthetsbevis.

4. konklusjon

Testing og formell verifisering er begge integrerte deler av smart kontraktsutvikling. Dette er metodene som brukes for å sikre smarte kontrakter og bidra til å gjøre kontraktene klare for utplassering. Men som du vet, er sikkerhet aldri nok. Mange smarte kontrakter ble hacket bare fordi det ikke var noen skikkelig testing. Nå trenger web3-fellesskapet mer enn noen gang sikrere protokoller. 

Vi i QuillAudits er på et oppdrag for å hjelpe til med å beskytte protokollene dine. Med vårt dyktige og erfarne team sørger vi for at ikke en eneste sårbarhet blir ubemerket. Besøk nettsiden vår og få Web3-prosjektet ditt sikret!

28 Visninger

Tidstempel:

Mer fra Quillhash