Testning och formell verifiering för Web3 Smart Contract Security

Lästid: 9 minuter

Tänk dig att gå fallskärmshoppning. Innan du hoppar av planet kommer du att kolla efter din fallskärm hundra gånger, eller hur? Kontroll och testning är en integrerad del av säkerheten; tänk på alla säkerhetsrelaterade saker. Det skulle sannolikt finnas en mekanism för att testa efteråt, oavsett om det är installation av CCTV eller kontroll av bläcket i pennan innan en skriftlig tentamen i skolan, vi följer alla säkerhetsåtgärder. Ju högre risk det är, desto mer testar vi saker. Och när vi pratar om smarta kontrakt är risken STOR. Du kan inte slarva när det kommer till smart avtalssäkerhet.

1. Säkerhet behövs alltid.

Du kan säkert låsa dörren två eller tre gånger spelar ingen roll. Kan du vara säker på att ditt hus inte kan rånas medan du är borta? Du kan inte eftersom du inte vet vad rånaren kan göra för att bryta sig in i huset – detsamma gäller för alla säkerhetsåtgärder vi vidtar. Det finns ingen helt säker metod som garanterar säkerheten. Ändå ökar de åtgärder vi vidtar snabbt våra chanser att vara säkra, vilket är vad spelet är. Vi vill öka chanserna att vara säkra genom att använda olika åtgärder.

Web3-världen är inte annorlunda. Det finns ingen säker metod för att rädda dig själv, men att ha erfarna revisorer från QuillAudits kan öka oddsen för att ditt protokoll ska säkras enormt och kommer att säkerställa din uppdaterade säkerhet. I web3 finns det två viktiga mekanismer som hjälper dig att förstå hur säker du är genom att göra några tester på ditt protokoll:-

1. Smart kontraktstestning
2. Formell verifiering av smarta kontrakt

Låt oss förstå dem i detalj och lära oss hur de hjälper oss att känna till våra kontrakts svagheter eller sårbarheter.

2. Smart kontraktstestning

En erfaren utvecklare kan förklara arbetet för en maskin med kod. Men ibland visar inte maskinen exakt den mekanism utvecklaren hade i åtanke på grund av ett fel eller ett logiskt fel i koden. Testning är den process som hjälper till att identifiera var vår kod misslyckas och vad som kan göras för att få den att stämma överens med den åtgärd vi behöver den ska utföra.

Smart kontraktstestning är en fas i utvecklingscykeln där vi utför en detaljerad analys av våra kontrakt och försöker ta reda på var och varför vår kod misslyckas. Nästan alla smarta kontrakt genomgår denna fas. Det finns två sätt att testa smarta kontrakt. Låt oss utforska dem.

2.1 Automatiserad

Som namnet antyder används denna metod för att testa smarta kontrakt för att utföra skripttestning. Det handlar om automatiserad programvara som utför upprepade tester för att hitta eventuella sårbarheter och defekter i smarta kontrakt. Dessa automatiserade testverktyg kan konfigureras med testdata och förväntade resultat. Sedan jämförs det faktiska resultatet med de förväntade för att kontrollera om kontraktet fungerar som det ska. Automatiserad testning kan ytterligare klassificeras i tre kategorier.

2.1.1. Funktionell testning

Anta att du skriver ett program för att ta två siffror, a och b och sedan returnera additionen av båda talen. Så för att kontrollera det programmet ger du 2 och 8 och matar det förväntade resultatet till 10. Nu när programmet körs ska det också returnera 10. Om det gör det så fungerar det bra, och vår kod är korrekt, men om den inte, då finns det något fel med vår kod. 

Funktionstestning kräver att du förstår hur ditt kontrakt ska bete sig under vissa förhållanden. Vi kan testa det genom att köra en beräkning med valda värden och jämföra den returnerade utdata. Funktionstestning har tre klasser:-

1. Enhetstestning:- Detta handlar om att testa enskilda komponenter i det smarta kontraktet för korrekthet. Det är assertivt eller kräver uttalanden om variabler.

2. Integration texterng: – Dessa handlar om att testa flera enskilda komponenter tillsammans. Integrationstestning är en nivå högre i hierarkin än enhetstestning. Det hjälper oss att fastställa fel som uppstår från samverkan mellan olika funktioner, som kan vara en del av andra smarta kontrakt.

3. Systemkrav testetng: – Detta är den högsta i hierarkin. I detta testar vi hela kontraktet som ett helt integrerat system för att se om det fungerar enligt våra behov. Det görs från användarens synvinkel, och det bästa sättet att göra det är att distribuera det på testnät.

2.1.2. Statisk analys

Statisk analys kan göras utan att ens köra programmet. Det involverar analys av källkoden eller bytekoden för det smarta kontraktet innan exekvering. Genom att ge sitt namn kan statisk analys resultera i upptäckten av några vanliga sårbarheter.

2.1.3. Dynamisk analys

Till skillnad från statisk analys utförs dynamisk analys under körtiden för de smarta kontrakten för att identifiera problem i koden. De dynamiska kodanalysatorerna observerar kontraktets drifttillstånd och genererar en detaljerad rapport om sårbarheter och egendomsöverträdelser. Fuzzing kommer under dynamisk analys. Fuzzing matar in felaktig eller skadlig inmatning för att orsaka oavsiktlig kodexekvering.

2.2 Manuell

Som namnet antyder innebär denna metod för smart kontraktstestning regelbunden interaktion med en mänsklig utvecklare. Kodrevisioner, där utvecklare går igenom rader med koder, faller under det manuella läget för smart kontraktstestning.

Manuellt läge kräver avsevärd tid, skicklighet, pengar och ansträngning. Ändå är resultatet ofta värt det eftersom vi med detta identifierar sårbarheter som kan bli obemärkta i den automatiska testningen. Det finns två viktiga typer av manuell testning:

2.2.1 Kodrevisioner:- 

Det bästa sättet att testa om din säkerhetsåtgärd fungerar korrekt är att försöka bryta den. Om du till exempel vill kontrollera om ditt billås fungerar korrekt, försök att bryta det. Nu kan ni fråga att en skicklig biltjuv lätt kan bryta sig in i min bil. Jag kanske inte, så lösningen är att anlita någon som är skicklig på att bryta in så att han kan vägleda dig!

 Ja, jag pratar om QuillAudits. Vi är ett team av duktiga revisorer som kan vägleda dig. Kodrevisioner kräver ett angripartänkande för att hitta alla möjliga sårbarheter i källkoden. En kodrevision är en detaljerad utvärdering av ett smart kontrakts kod för att avslöja potentiella sårbarheter och brister.

2.2.2 Bug Bounty:-

Om du tror att det kan finnas några säkerhetsbrister i din källkod (som oftast är det) och du inte kan hitta dem, kan du lägga ut detta arbete på frilansare genom att skapa ett belöningssystem. Det är mer som att tillkännage en belöning för alla som kan hacka ditt smarta kontrakt. Genom att göra detta lär du dig om sårbarheten som finns i ditt smarta kontrakt så att du kan skydda det bättre och rädda dina användare från förlust.

3. Formell verifiering av smarta kontrakt

Formell verifiering är processen för att utvärdera riktigheten av ett kontrakt baserat på formella specifikationer. Detta innebär att formell verifiering bedömer om koden gör det som är avsett. Formell verifiering använder formella metoder för att specificera, utforma och verifiera program.

3.1 Vad är den formella specifikationen?

I samband med smarta kontrakt avser formella specifikationer de egenskaper som måste förbli desamma under alla möjliga omständigheter. Dessa är "invarianter" egenskaper eftersom de inte kan ändras och representerar logiska påståenden om kontraktets utförande.

Formell specifikation är en samling uttalanden skrivna på formellt språk. Specifikationer omfattar olika egenskaper och beskriver hur kontraktets egenskaper ska förhålla sig under andra omständigheter. Formella specifikationer är kritiska eftersom om kontrakt inte har oföränderliga variabler eller egenskaper förändras under utförande, kan det leda till möjlig egendomsexploatering, vilket kan leda till en enorm förlust.

Det kan hjälpa oss att avgöra om ett smart kontrakt uppfyller specifikationerna eller har oväntade beteenden. Formell verifiering har tre komponenter: en specifikation, en modell och en verifieringsmotor.

3.1.1 Specifikation

En specifikation är en tydlig, entydig och fullständig beskrivning av kraven för ett smart kontrakt. Den ska beskriva vad kontraktet ska göra och vad det inte ska göra. Här är en exempelspecifikation för ett enkelt, smart kontrakt som lägger till två siffror:

// 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 representerar formellt det smarta kontraktet som kan användas för att resonera kring dess beteende. En populär modell för smarta kontrakt är programmeringsspråket Solidity. Här är en exempelmodell för add-funktionen som beskrivs ovan:

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

En verifieringsmotor är ett verktyg som kan analysera en modell och verifiera dess riktighet avseende en given specifikation. Det finns flera verifieringsmotorer tillgängliga för smarta kontrakt, inklusive:

Mythril: ett symboliskt exekveringsverktyg med öppen källkod som kan upptäcka ett brett utbud av säkerhetsbrister i Solidity smarta kontrakt.

Remix IDE: en integrerad utvecklingsmiljö som inkluderar ett formellt verifieringsverktyg som kan verifiera riktigheten av smarta kontrakt.

Certora Prover: ett kommersiellt verktyg som kan verifiera riktigheten av smarta kontrakt med hjälp av automatiserade matematiska resonemang. Här är ett exempel på hur formell verifiering kan användas för att verifiera riktigheten av ett smart kontrakt med hjälp av 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 exemplet ovan definierar vi ett Solidity smart kontrakt som inkluderar en modell av add-funktionen, en specifikation för funktionen och en verifieringsmotor (Certora Prover) som kan verifiera funktionens korrekthet. Vi definierar även en testfunktion (test_add) som kan användas för att verifiera funktionens korrekthet.

3.2 Testning VS formell verifiering

Som vi diskuterade returnerar testning det förväntade resultatet för en viss indatabot som den saknar eftersom vi inte kan säga något om vilken data den inte har testats på. Det är praktiskt taget omöjligt att kontrollera det på alla möjliga ingångar. Därför är vi inte säkra på dess "funktionella korrekthet". Det är där formell verifiering kommer in. Formella verifieringsmetoder använder rigorösa matematiska tekniker för att specificera och verifiera programvara eller smarta kontrakt.

3.3 Tekniker för formell verifiering

Formell verifiering har ett brett spektrum av tekniker för att förbättra smart kontraktssäkerhet. I den här delen av bloggen kommer vi att utforska några individuellt.

3.3.1 Modellkontroll

När vi diskuterade vad en formell specifikation är, kontrollerar vi det smarta kontraktet mot dess specifikation i denna formella verifieringsteknik. Dessa smarta kontrakt representeras som tillståndsövergångssystem och egenskaper definieras med hjälp av tidslogik. 

Denna teknik används främst för att utvärdera tidsmässiga egenskaper som skildrar beteendet hos smarta kontrakt över tid. Åtkomstkontrollegenskap (admin anrop självförstörelse) kan skrivas ner som formell logik. Sedan kan modellkontrollalgoritmen verifiera om kontraktet uppfyller denna formella verifiering.

Modellkontroll använder en teknik som kallas State Space Exploration, som i princip är att pröva alla möjliga tillstånd som vårt smarta kontrakt kan vara i och sedan kontrollera om något av det resulterar i en egendomskränkning. Detta kan dock leda till oändligt många tillstånd; Därför förlitar sig modellcheckare på abstraktionstekniker för att göra en effektiv analys av smarta kontrakt möjlig.

3.3.2 Satsbevisande

Satsbevisande handlar om matematiska resonemang om programs riktighet. Det handlar om att skapa ett logiskt intryck av kontraktets system och specifikation och att verifiera den ”logiska likvärdigheten” mellan påståendena. Logisk ekvivalens är ett matematiskt samband som säger att påstående A är sant om och endast om påstående B är sant.

Som vi lärde oss i modellkontrolltekniken, modellerar vi kontrakt som övergångssystem med finita tillstånd. Satsbevisande kan hantera analys av oändliga tillståndssystem. En automatiserad teorembevisare kan dock inte alltid veta om ett logiskt problem är avgörbart; sålunda krävs ofta mänsklig hjälp för att vägleda satsbevisaren för att härleda korrekthetsbevis.

4. Slutsats

Testning och formell verifiering är båda integrerade delar av smart kontraktsutveckling. Det här är metoderna som används för att göra smarta kontrakt säkra och hjälpa till att göra kontrakten redo för driftsättning. Men säkerheten räcker som bekant aldrig till. Många smarta kontrakt blev hackade bara för att det inte fanns någon ordentlig testning. Nu mer än någonsin behöver web3-communityt säkrare protokoll. 

Vi på QuillAudits har ett uppdrag att hjälpa till att skydda dina protokoll. Med vårt skickliga och erfarna team ser vi till att inte ens en enda sårbarhet blir obemärkt. Besök vår hemsida och få ditt Web3-projekt säkrat!

28 Visningar

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. Tillgång här.
• Källa: https://blog.quillhash.com/2023/02/16/testing-and-formal-verification/