Testen en formele verificatie voor Web3 Smart Contract Security

Leestijd: 9 minuten

Stel je voor dat je gaat parachutespringen. Voordat je uit het vliegtuig springt, moet je wel honderd keer naar je parachute kijken, toch? Controleren en testen zijn een integraal onderdeel van beveiliging; denk aan alles wat met beveiliging te maken heeft. Er volgt waarschijnlijk een testmechanisme achteraf, of het nu gaat om de installatie van cameratoezicht of het controleren van de inkt in de pen voor een schriftelijk examen op school, we volgen allemaal veiligheidsmaatregelen. Hoe hoger het risico, hoe meer we dingen testen. En als we het hebben over slimme contracten, is het risico ENORM. U kunt niet onzorgvuldig zijn als het gaat om slimme contractbeveiliging.

1. Beveiliging is altijd nodig.

Je kunt de deur zeker twee of drie keer op slot doen, het maakt niet uit. Weet u zeker dat uw huis niet kan worden beroofd terwijl u weg bent? Dat kan niet omdat je niet weet wat de overvaller zou kunnen doen om in te breken in het huis - hetzelfde geldt voor elke veiligheidsmaatregel die we nemen. Er is geen volledig veilige methode die veiligheid garandeert. Toch vergroot de actie die we snel ondernemen onze kansen om veilig te zijn, en dat is wat het spel is. Met verschillende maatregelen willen we de kans op veiligheid vergroten.

De wereld van Web3 is niet anders. Er is geen veilige methode om uzelf te redden, maar ervaren auditors van QuillAudits kunnen de kans dat uw protocol wordt beveiligd enorm vergroten en zorgen voor een up-to-date beveiliging. In web3 zijn er twee belangrijke mechanismen die u helpen begrijpen hoe veilig u bent door enkele tests op uw protocol uit te voeren:

1. Slimme contracttesten
2. Formele verificatie van slimme contracten

Laten we ze in detail begrijpen en leren hoe ze ons helpen de zwakke punten of kwetsbaarheden van onze contracten te kennen.

2. Slimme contracttesten

Een ervaren ontwikkelaar kan met code het werk uitleggen aan een machine. Toch geeft de machine soms niet het exacte mechanisme weer dat de ontwikkelaar in gedachten had vanwege een fout of een logische fout in de code. Testen is het proces dat helpt te identificeren waar onze code faalt en wat er kan worden gedaan om ervoor te zorgen dat deze overeenkomt met de actie die we nodig hebben om deze uit te voeren.

Slimme contracttesten is een fase in de ontwikkelingscyclus waarin we een gedetailleerde analyse van onze contracten uitvoeren en proberen te achterhalen waar en waarom onze code faalt. Vrijwel alle smart contracts ondergaan deze fase. Er zijn twee manieren waarop smart contract-testen worden uitgevoerd. Laten we ze verkennen.

2.1 Geautomatiseerd

Zoals de naam al doet vermoeden, wordt deze methode voor het testen van slimme contracten gebruikt om scripttests uit te voeren. Het gaat om geautomatiseerde software die herhaalde tests uitvoert om eventuele kwetsbaarheden en defecten in slimme contracten te vinden. Deze geautomatiseerde testtools kunnen worden geconfigureerd met testgegevens en verwachte resultaten. Vervolgens wordt het daadwerkelijke resultaat vergeleken met het verwachte resultaat om te controleren of het contract goed werkt. Geautomatiseerd testen kan verder worden ingedeeld in drie categorieën.

2.1.1. Functioneel testen

Stel dat u een programma schrijft om twee getallen, a en b, te nemen en vervolgens de optelling van beide getallen terug te geven. Dus om dat programma te controleren, geef je 2 en 8 en voer je het verwachte resultaat in als 10. Als het programma nu draait, zou het ook 10 moeten retourneren. Als dat zo is, dan werkt het prima, en onze code is correct, maar als het niet, dan is er een fout in onze code. 

Functioneel testen vereist inzicht in hoe uw contract zich onder bepaalde omstandigheden zou moeten gedragen. We kunnen het testen door een berekening uit te voeren met geselecteerde waarden en de geretourneerde uitvoer te vergelijken. Functioneel testen heeft drie klassen: -

1. Testen van een eenheid: - Dit gaat over het testen van individuele componenten van het slimme contract op juistheid. Het is assertief of vereist uitspraken over variabelen.

2. Integratie testing: – Deze gaat over het samen testen van verschillende afzonderlijke componenten. Integratietesten is een niveau hoger in de hiërarchie dan unittesten. Het helpt ons fouten vast te stellen die voortkomen uit de interactie van verschillende functies, die deel kunnen uitmaken van andere slimme contracten.

3. Systeem Tekstenng: – Dit is de hoogste in de hiërarchie. Hierin testen we het hele contract als één volledig geïntegreerd systeem om te zien of het presteert volgens onze behoeften. Het wordt gedaan vanuit het oogpunt van de gebruiker, en de beste manier om dit te doen is door het op testnetten in te zetten.

2.1.2. Statische analyse

Statische analyse kan worden uitgevoerd zonder het programma zelfs maar uit te voeren. Het omvat de analyse van de broncode of bytecode van het slimme contract vóór uitvoering. Door zijn naam te geven, kan statische analyse resulteren in de detectie van enkele veelvoorkomende kwetsbaarheden.

2.1.3. Dynamische analyse

In tegenstelling tot statische analyse, wordt dynamische analyse uitgevoerd tijdens de looptijd van de slimme contracten om problemen in de code te identificeren. De dynamische code-analyzers observeren de lopende status van het contract en genereren een gedetailleerd rapport van kwetsbaarheden en eigendomsschendingen. Fuzzing valt onder dynamische analyse. Fuzzing is het invoeren van onjuiste of schadelijke invoer om onbedoelde uitvoering van code te veroorzaken.

2.2 Manual

Zoals de naam al doet vermoeden, omvat deze methode van slimme contracttesten regelmatige interactie met een menselijke ontwikkelaar. Code-audits, waarbij ontwikkelaars coderegels doorlopen, vallen onder de handmatige modus van slimme contracttesten.

Handmatige modus vereist veel tijd, vaardigheid, geld en inspanning. Toch is het resultaat vaak de moeite waard, omdat we hiermee kwetsbaarheden identificeren die mogelijk onopgemerkt blijven bij het automatisch testen. Er zijn twee essentiële soorten handmatig testen: -

2.2.1 Code-audits:- 

De beste manier om te testen of uw veiligheidsmaatregel goed werkt, is door te proberen deze te doorbreken. Als je bijvoorbeeld wilt controleren of je autoslot goed werkt, probeer het dan te verbreken. Nu vraag je je misschien af ​​of een bekwame autodief gemakkelijk in mijn auto kan inbreken. Ik misschien niet, dus de oplossing is om iemand in te huren die bedreven is in inbreken, zodat hij je kan begeleiden!

 Ja, ik heb het over QuillAudits. Wij zijn een team van bekwame auditoren die u kunnen begeleiden. Code-audits vereisen een mentaliteit van een aanvaller om alle mogelijke kwetsbaarheden in de broncode te vinden. Een code-audit is een gedetailleerde evaluatie van de code van een slim contract om potentiële kwetsbaarheden en gebreken aan het licht te brengen.

2.2.2 Bugpremie:-

Als u denkt dat er beveiligingsfouten in uw broncode zitten (wat meestal het geval is) en u kunt ze niet vinden, dan kunt u dit werk uitbesteden aan freelancers door een beloningssysteem te creëren. Het lijkt meer op het aankondigen van een beloning voor iedereen die je slimme contract kan hacken. Door dit te doen, leert u over de kwetsbaarheid in uw slimme contract, zodat u deze beter kunt beschermen en uw gebruikers kunt behoeden voor verlies.

3. Formele verificatie van slimme contracten

Formele verificatie is het proces waarbij de juistheid van een contract wordt beoordeeld op basis van formele specificaties. Dit betekent dat formele verificatie beoordeelt of de code doet wat bedoeld is. Formele verificatie maakt gebruik van formele methoden voor het specificeren, ontwerpen en verifiëren van programma's.

3.1 Wat is de formele specificatie?

In de context van slimme contracten verwijzen formele specificaties naar de eigenschappen die onder alle mogelijke omstandigheden hetzelfde moeten blijven. Dit zijn "invariante" eigenschappen omdat ze niet kunnen veranderen en logische beweringen over de uitvoering van het contract vertegenwoordigen.

Formele specificatie is een verzameling uitspraken die in formele taal zijn geschreven. Specificaties hebben betrekking op verschillende eigenschappen en beschrijven hoe de eigenschappen van het contract zich in andere omstandigheden zouden moeten gedragen. Formele specificaties zijn van cruciaal belang, want als contracten geen onveranderlijke variabelen hebben of eigenschappen veranderen tijdens de uitvoering, kan dit leiden tot mogelijke exploitatie van eigendommen, wat tot een enorm verlies kan leiden.

Het kan ons helpen bepalen of een slim contract aan de specificaties voldoet of onverwacht gedrag vertoont. Formele verificatie bestaat uit drie componenten: een specificatie, een model en een verificatie-engine.

3.1.1 Specificatie

Een specificatie is een duidelijke, ondubbelzinnige en volledige beschrijving van de vereisten voor een slim contract. Het moet beschrijven wat het contract geacht wordt te doen en wat het niet behoort te doen. Hier is een voorbeeldspecificatie voor een eenvoudig, slim contract dat twee getallen optelt:

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

Een model vertegenwoordigt formeel het slimme contract dat kan worden gebruikt om over zijn gedrag te redeneren. Een populair model voor slimme contracten is de programmeertaal Solidity. Hier is een voorbeeldmodel voor de hierboven beschreven optelfunctie:

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

Een verificatie-engine is een hulpmiddel dat een model kan analyseren en de juistheid ervan met betrekking tot een bepaalde specificatie kan verifiëren. Er zijn verschillende verificatie-engines beschikbaar voor slimme contracten, waaronder:

mythril: een open-source symbolische uitvoeringstool die een breed scala aan beveiligingsproblemen in slimme contracten van Solidity kan detecteren.

Remix-IDE: een geïntegreerde ontwikkelomgeving met een formele verificatietool die de juistheid van slimme contracten kan verifiëren.

Certora Bewijs: een commerciële tool die de juistheid van slimme contracten kan verifiëren met behulp van geautomatiseerd wiskundig redeneren. Hier is een voorbeeld van hoe formele verificatie kan worden gebruikt om de juistheid van een slim contract te verifiëren met behulp van de 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);
}
}

In het bovenstaande voorbeeld definiëren we een Solidity smart contract dat een model van de toevoegfunctie, een specificatie voor de functie en een verificatie-engine (Certora Prover) bevat die de juistheid van de functie kan verifiëren. We definiëren ook een testfunctie (test_add) die kan worden gebruikt om de juistheid van de functie te verifiëren.

3.2 Testen versus formele verificatie

Zoals we hebben besproken, levert testen het verwachte resultaat op voor een bot met invoergegevens die het mist, omdat we niets kunnen zeggen over de gegevens waarop het niet is getest. Het is praktisch onmogelijk om het op elke mogelijke ingang te controleren. We zijn dus niet zeker van de "functionele correctheid". Dat is waar formele verificatie om de hoek komt kijken. Formele verificatiemethoden gebruiken rigoureuze wiskundige technieken voor het specificeren en verifiëren van software of slimme contracten.

3.3 Technieken voor formele verificatie

Formele verificatie heeft een breed scala aan technieken om te verbeteren slimme contractbeveiliging. In dit deel van de blog zullen we er een paar afzonderlijk onderzoeken.

3.3.1 Modelcontrole

Terwijl we bespraken wat een formele specificatie is, controleren we het slimme contract aan de hand van zijn specificatie in deze formele verificatietechniek. Deze slimme contracten worden weergegeven als toestandsovergangssystemen en eigenschappen worden gedefinieerd met behulp van temporele logica. 

Deze techniek wordt voornamelijk gebruikt om tijdelijke eigenschappen te evalueren die het gedrag van slimme contracten in de loop van de tijd weergeven. Toegangscontrole-eigenschap (admin calling zelfvernietiging) kan worden opgeschreven als formele logica. Vervolgens kan het algoritme voor modelcontrole controleren of het contract aan deze formele verificatie voldoet.

Modelcontrole maakt gebruik van een techniek genaamd State Space-verkenning, die in feite alle mogelijke staten uitprobeert waarin ons slimme contract zich kan bevinden en vervolgens controleert of een ervan resulteert in een eigendomsovertreding. Dit kan echter leiden tot oneindig veel toestanden; vandaar dat modelcheckers vertrouwen op abstractietechnieken om een ​​efficiënte analyse van slimme contracten mogelijk te maken.

3.3.2 Stelling bewijzen

Stelling bewijzen gaat over wiskundig redeneren over de juistheid van programma's. Het gaat om het creëren van een logische indruk van het systeem en de specificatie van het contract en het verifiëren van de "logische gelijkwaardigheid" tussen de verklaringen. Logische equivalentie is een wiskundige relatie die zegt dat bewering A waar is als en slechts als bewering B waar is.

Zoals we hebben geleerd in de modelchecktechniek, modelleren we contracten als overgangssystemen met eindige toestanden. Het bewijzen van stellingen kan de analyse van systemen met oneindige toestanden aan. Een geautomatiseerde stellingbewijzer kan echter niet altijd weten of een logisch probleem beslisbaar is; dus is vaak menselijke hulp nodig om de stellingbewijzer te begeleiden bij het afleiden van correctheidsbewijzen.

4. Conclusie

Testen en formele verificatie zijn beide integrale onderdelen van de ontwikkeling van slimme contracten. Dit zijn de methoden die worden gebruikt om slimme contracten te beveiligen en om de contracten gereed te maken voor implementatie. Maar zoals u weet, is veiligheid nooit genoeg. Veel slimme contracten werden gehackt alleen omdat er niet goed werd getest. Meer dan ooit heeft de web3-gemeenschap behoefte aan veiligere protocollen. 

Wij bij QuillAudits zijn op een missie om uw protocollen te helpen beschermen. Met ons vakkundige en ervaren team zorgen we ervoor dat geen enkele kwetsbaarheid onopgemerkt blijft. Bezoek onze website en beveilig uw Web3-project!

28 keer bekeken

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://blog.quillhash.com/2023/02/16/testing-and-formal-verification/