Test og formel verifikation til Web3 Smart Contract Security

Genudgivet af Platon

Abonnenter: 0

Testing and Formal Verification for Web3 Smart Contract Security PlatoBlockchain Data Intelligence. Vertical Search. Ai.

Læsetid: 9 minutter

Forestil dig at tage på faldskærmsudspring. Før du hopper af flyet, vil du tjekke efter din faldskærm hundrede gange, ikke? Kontrol og test er en integreret del af sikkerheden; tænke over enhver sikkerhedsrelateret ting. Der ville sandsynligvis være en mekanisme til at teste efterfølgende, uanset om det er installation af CCTV eller kontrol af blækket i pennen før en skriftlig eksamen i skolen, vi følger alle sikkerhedsforanstaltninger. Jo højere risikoen er, jo mere tester vi tingene. Og når vi taler om smarte kontrakter, er risikoen STOR. Du kan ikke være skødesløs, når det kommer til smart kontraktsikkerhed.

1. Sikkerhed er altid nødvendig.

Du kan helt sikkert låse døren to eller tre gange betyder ikke noget. Kan du være sikker på, at dit hus ikke kan blive bestjålet, mens du er væk? Det kan du ikke, fordi du ikke ved, hvad røveren kan gøre for at bryde ind i huset – det samme gælder for alle sikkerhedsforanstaltninger, vi træffer. Der er ingen helt sikker metode, som garanterer sikkerheden. Alligevel øger den handling, vi tager, hurtigt vores chancer for at være sikker, hvilket er, hvad spillet er. Vi ønsker at øge chancerne for at være sikker ved at anvende forskellige foranstaltninger.

Web3s verden er ikke anderledes. Der er ingen sikker metode til at redde dig selv, men at have erfarne revisorer fra QuillAudits kan øge chancerne for, at din protokol bliver sikret enormt og vil sikre din opdaterede sikkerhed. I web3 er der to vigtige mekanismer, som hjælper dig med at forstå, hvor sikker du er ved at udføre nogle test på din protokol:

Smart kontrakttestning
Formel verifikation af smarte kontrakter

Lad os forstå dem i detaljer og lære, hvordan de hjælper os med at kende vores kontrakters svage punkter eller sårbarheder.

2. Smart kontrakttestning

En erfaren udvikler kan forklare arbejdet til en maskine med kode. Alligevel viser maskinen nogle gange ikke den nøjagtige mekanisme, som udvikleren havde i tankerne på grund af en fejl eller en logisk fejl i koden. Test er den proces, der hjælper med at identificere, hvor vores kode fejler, og hvad der kan gøres for at få den til at svare til den handling, vi skal udføre.

Smart kontrakttest er en fase i udviklingscyklussen, hvor vi udfører en detaljeret analyse af vores kontrakter og forsøger at finde ud af, hvor og hvorfor vores kode fejler. Næsten alle smarte kontrakter gennemgår denne fase. Der er to måder, smart kontrakttestning udføres på. Lad os udforske dem.

2.1 Automatiseret

Som navnet antyder, bruges denne metode til test af smarte kontrakter til at udføre scripted test. Det involverer automatiseret software, som udfører gentagne tests for at finde eventuelle sårbarheder og defekter i smarte kontrakter. Disse automatiserede testværktøjer kan konfigureres med testdata og forventede resultater. Derefter sammenlignes det faktiske resultat med de forventede for at kontrollere, om kontrakten fungerer korrekt. Automatiseret test kan yderligere klassificeres i tre kategorier.

2.1.1. Funktionel testning

Antag, at du skriver et program for at tage to tal, a og b og derefter returnere tilføjelsen af begge tal. Så for at tjekke det program, giver du 2 og 8 og fodrer det forventede resultat til at være 10. Når programmet nu kører, skulle det også returnere 10. Hvis det gør, så fungerer det fint, og vores kode er korrekt, men hvis det gør det ikke, så er der en fejl med vores kode.

Funktionstest kræver forståelse for, hvordan din kontrakt skal opføre sig under visse forhold. Vi kan teste det ved at køre en beregning med udvalgte værdier og sammenligne det returnerede output. Funktionel test har tre klasser: -

Enhedstest:- Dette omhandler test af individuelle komponenter i den smarte kontrakt for korrekthed. Det er assertivt eller kræver udsagn om variable.

Integration prøveng: – Disse omhandler test af flere individuelle komponenter sammen. Integrationstest er et niveau højere i hierarkiet end enhedstest. Det hjælper os med at bestemme fejl, der opstår fra samspillet mellem forskellige funktioner, som kan være en del af andre smarte kontrakter.

Systemkrav prøveng: – Dette er det højeste i hierarkiet. I dette tester vi hele kontrakten som ét fuldt integreret system for at se, om det fungerer efter vores behov. Det gøres fra brugerens synspunkt, og den bedste måde at gøre det på er at implementere det på testnet.

2.1.2. Statisk Analyse

Statisk analyse kan udføres uden selv at køre programmet. Det involverer analyse af kildekoden eller bytekoden for den smarte kontrakt før udførelse. Ved at give sit navn kan statisk analyse resultere i påvisning af nogle almindelige sårbarheder.

2.1.3. Dynamisk analyse

I modsætning til statisk analyse udføres dynamisk analyse i løbet af de smarte kontrakter for at identificere problemer i kode. De dynamiske kodeanalysatorer observerer kontraktens driftstilstand og genererer en detaljeret rapport om sårbarheder og ejendomsovertrædelser. Fuzzing kommer under dynamisk analyse. Fuzzing leverer forkert eller ondsindet input for at forårsage utilsigtet kodekørsel.

2.2 Manual

Som navnet antyder, involverer denne metode til smart kontrakttestning regelmæssig interaktion med en menneskelig udvikler. Kodeaudit, hvor udviklere gennemgår linjer med koder, kommer under den manuelle tilstand for smart kontrakttestning.

Manuel tilstand kræver betydelig tid, dygtighed, penge og kræfter. Alligevel er resultatet ofte det værd, fordi vi med dette identificerer sårbarheder, der kan blive ubemærket i den automatiske test. Der er to væsentlige typer af manuel test: -

2.2.1 Koderevisioner:-

Den bedste måde at teste, om din sikkerhedsforanstaltning fungerer korrekt, er at prøve at bryde den. For eksempel, hvis du vil tjekke, om din billås fungerer korrekt, så prøv at bryde den. Nu kan du spørge, at en dygtig biltyv sagtens kan bryde ind i min bil. Det kan jeg ikke, så løsningen er at ansætte en, der er dygtig til at bryde ind, så han kan guide dig!

Ja, jeg taler om QuillAudits. Vi er et team af dygtige revisorer, der kan vejlede dig. Kodeaudit kræver en hackertankegang for at finde alle mulige sårbarheder i kildekoden. En kodeaudit er en detaljeret evaluering af en smart kontrakts kode for at afdække potentielle sårbarheder og mangler.

2.2.2 Bug Bounty:-

Hvis du tror, der kan være nogle sikkerhedsfejl i din kildekode (som for det meste er), og du ikke kan finde dem, kan du outsource dette arbejde til freelancere ved at oprette et belønningssystem. Det er mere som at annoncere en belønning til alle, der kan hacke din smarte kontrakt. Ved at gøre dette lærer du om sårbarheden i din smarte kontrakt, så du kan beskytte den bedre og redde dine brugere fra tab.

3. Formel verifikation af smarte kontrakter

Formel verifikation er processen med at evaluere rigtigheden af en kontrakt baseret på formelle specifikationer. Det betyder, at formel verifikation vurderer, om koden gør det tilsigtede. Formel verifikation bruger formelle metoder til at specificere, designe og verificere programmer.

3.1 Hvad er den formelle specifikation?

I forbindelse med intelligente kontrakter henviser formelle specifikationer til de egenskaber, som skal forblive de samme under alle mulige omstændigheder. Disse er "invariante" egenskaber, fordi de ikke kan ændre sig og repræsenterer logiske påstande om kontraktens udførelse.

Formel specifikation er en samling af erklæringer skrevet i formelt sprog. Specifikationer dækker over forskellige egenskaber og beskriver, hvordan kontraktens egenskaber skal opføre sig under andre omstændigheder. Formelle specifikationer er kritiske, fordi hvis kontrakter ikke har invariante variabler eller egenskaber ændres under udførelsen, kan det føre til mulig ejendomsudnyttelse, hvilket kan føre til et stort tab.

Det kan hjælpe os med at afgøre, om en smart kontrakt opfylder specifikationerne eller har uventet adfærd. Formel verifikation har tre komponenter: en specifikation, en model og en verifikationsmotor.

3.1.1 Specifikation

En specifikation er en klar, entydig og fuldstændig beskrivelse af kravene til en smart kontrakt. Den skal beskrive, hvad kontrakten skal gøre, og hvad den ikke skal. Her er et eksempel på specifikation for en simpel, smart kontrakt, der tilføjer to tal:

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

En model repræsenterer formelt den smarte kontrakt, der kan bruges til at ræsonnere om dens adfærd. En populær model for smarte kontrakter er programmeringssproget Solidity. Her er en eksempelmodel for tilføjelsesfunktionen 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 Verifikationsmotor

En verifikationsmotor er et værktøj, der kan analysere en model og verificere dens rigtighed i forhold til en given specifikation. Der er flere tilgængelige verifikationsmotorer til smarte kontrakter, herunder:

Mythril: et open source symbolsk eksekveringsværktøj, der kan opdage en lang række sikkerhedssårbarheder i Solidity smarte kontrakter.

Remix IDE: et integreret udviklingsmiljø, der inkluderer et formelt verifikationsværktøj, der kan verificere rigtigheden af smarte kontrakter.

Certora Prover: et kommercielt værktøj, der kan verificere rigtigheden af smarte kontrakter ved hjælp af automatiseret matematisk ræsonnement. Her er et eksempel på, hvordan formel verifikation kan bruges til at verificere rigtigheden af en smart kontrakt ved hjælp af 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 ovenstående eksempel definerer vi en Solidity smart kontrakt, der inkluderer en model af tilføjelsesfunktionen, en specifikation for funktionen og en verifikationsmotor (Certora Prover), der kan verificere rigtigheden af funktionen. Vi definerer også en testfunktion (test_add), som kan bruges til at verificere funktionens rigtighed.

3.2 Test vs formel verifikation

Som vi diskuterede, returnerer test det forventede resultat for nogle inputdatabot, som den mangler, fordi vi ikke kan sige noget om de data, den ikke er blevet testet på. Det er praktisk talt umuligt at kontrollere det på alle mulige input. Derfor er vi ikke sikre på dens "funktionelle korrekthed". Det er her, formel verifikation kommer ind i billedet. Formelle verifikationsmetoder bruger strenge matematiske teknikker til at specificere og verificere software eller smarte kontrakter.

3.3 Teknikker til formel verifikation

Formel verifikation har en bred vifte af teknikker til forbedring smart kontrakt sikkerhed. I denne del af bloggen vil vi udforske et par stykker individuelt.

3.3.1 Modelkontrol

Da vi diskuterede, hvad en formel specifikation er, tjekker vi den smarte kontrakt mod dens specifikation i denne formelle verifikationsteknik. Disse smarte kontrakter er repræsenteret som tilstandsovergangssystemer, og egenskaber defineres ved hjælp af tidsmæssig logik.

Denne teknik bruges primært til at evaluere tidsmæssige egenskaber, der skildrer adfærden af smarte kontrakter over tid. Adgangskontrolegenskab (admin kalder selvdestruere) kan skrives ned som formel logik. Derefter kan modelkontrolalgoritmen verificere, om kontrakten opfylder denne formelle verifikation.

Modelkontrol bruger en teknik kaldet State Space exploration, som dybest set er at prøve alle de mulige tilstande, vores smarte kontrakt kan være i, og derefter kontrollere, om noget af det resulterer i en ejendomskrænkelse. Dette kan dog føre til uendeligt mange tilstande; Derfor stoler modelcheckere på abstraktionsteknikker for at muliggøre en effektiv analyse af smarte kontrakter.

3.3.2 Teorembevis

Teorembevis handler om matematiske ræsonnementer om korrektheden af programmer. Det handler om at skabe et logisk indtryk af kontraktens system og specifikation og verificere den ”logiske ækvivalens” mellem udsagn. Logisk ækvivalens er et matematisk forhold, der siger, at udsagn A er sand, hvis og kun hvis udsagn B er sand.

Som vi lærte i modelkontrolteknikken, modellerer vi kontrakter som overgangssystemer med endelige tilstande. Sætningsbevis kan håndtere analyse af uendelige tilstandssystemer. En automatiseret teorembeviser kan dog ikke altid vide, om et logisk problem kan afgøres; derfor kræves der ofte menneskelig assistance for at vejlede sætningsbeviseren i at udlede korrekthedsbeviser.

4. konklusion

Test og formel verifikation er begge integrerede dele af intelligent kontraktudvikling. Det er de metoder, der bruges til at gøre smarte kontrakter sikre og hjælpe med at gøre kontrakterne klar til implementering. Men sikkerhed er som bekendt aldrig nok. Mange smarte kontrakter blev hacket, bare fordi der ikke var nogen ordentlig test. Nu har web3-fællesskabet mere end nogensinde brug for mere sikre protokoller.

Vi hos QuillAudits er på en mission for at hjælpe med at beskytte dine protokoller. Med vores dygtige og erfarne team sørger vi for, at ikke en eneste sårbarhed bliver ubemærket. Besøg vores hjemmeside og få dit Web3-projekt sikret!

28 Views