Hur formell verifiering kan minska buggar och sårbarheter i smarta kontrakt

Formell verifiering i smarta kontrakt

Den formella verifieringen av smarta kontrakt är en framväxande trend i kryptovalutautrymmet som fokuserar på att minska förekomsten av buggar och sårbarheter hos smarta kontrakt som har lett till många högprofilerade hack och endemiska säkerhetsproblem.

Formell verifiering har ett brett utbud av applikationer när det gäller hårdvara och mjukvarusystem. Det har blivit oerhört viktigt eftersom systemens komplexitet ökar, särskilt med hårdvara. I blockchain-nätverk har litania av sårbarheter och utnyttjande av smarta kontrakt lett till ett behov av förbättrad programmering och granskning av smarta kontrakt..

Formell verifiering i smarta kontrakt

Bakgrund om formell verifiering

Formella verifieringsanvändningar formella metoder för att kontrollera om en design av ett hårdvaru- eller mjukvarusystem uppfyller en specifik uppsättning egenskaper. Formella metoder är en speciell typ av matematisk teknik för specifikation, utveckling och verifiering av både hårdvaru- och mjukvarusystem. Att använda formella metoder för att bevisa eller motbevisa riktigheten hos avsedda algoritmer kallas formell verifiering.

Martin Davis krediteras med att utveckla det första datorgenererade matematiska beviset 1954. Konceptet började få dragkraft på 1960-talet för att verifiera datorprogrammens riktighet på tidiga språk som Pascal och Java. Efter några högprofilerade datorfelar, till exempel Pentium FDIV Bug 1994 började känslan att formell verifiering behövde vara allestädes närvarande snöboll.

Att testa ett programvara eller hårdvarusystem kan delas upp i två allmänna faser:

  1. Godkännande
  2. Verifiering

Valideringen avgör om produkten uppfyller användarens behov.

Verifiering testar om produkten överensstämmer med specifikationerna eller inte.

Verifiering består av att producera en abstrakt matematisk modell som korrelerar med produktens designspecifikationer (dvs. algoritm, hårdvarukrets) medan de formella metoderna som används för att generera modellen huvudsakligen härrör från teoretiska datavetenskapliga grunder.

Användningen av formell verifiering har blivit oerhört viktig i hårdvarusystem, där den används av nästan alla större hårdvarutillverkare för att säkerställa deras produkters robusthet. Användningen är emellertid inte alls lika vanlig i programvara som i hårdvara, vilket främst tillskrivs den kommersiella karaktären av hårdvarutillverkning.

Den dynamiken börjar dock förändras med tillkomsten av blockkedjor och kryptovalutor där betydande värdeöverföringar utförs autonomt över ett decentraliserat nätverk. Med mer värde på spel än traditionella system har riktigheten i smarta kontrakt blivit ett pressande problem.

A kortfattad bakgrund av smarta kontrakt utnyttjar är allt som krävs för att förstå konsekvenserna av enkla sårbarheter i avtalskoden.

Varför använda det för smarta kontrakt?

Enligt en nyligen studie utfördes på nästan 1 miljon Ethereum-smarta kontrakt, 34 200 av dem flaggades som sårbara på 10 sekunder per kontrakt. Det häpnadsväckande antalet uppnåddes genom att analysera spårningssårbarheter i smarta kontrakt inklusive:

  • Hitta kontrakt som låser pengar på obestämd tid
  • Kontrakt som läcker pengar slarvigt till godtyckliga användare
  • Kontrakt som kan dödas av vem som helst

Tillsammans med den allmänna logiska komplexiteten och nyheten i samband med programmering av smarta kontrakt för blockkedjor, gör deras oföränderliga natur – när de är engagerade i blockchain – sårbarheter potentiellt mycket mer skadliga.

Brian Marick och Daejun Park ger ett utmärkt analys av sårbarheter i smarta kontrakt och hur formell verifiering kan hjälpa till att mildra deras instanser. I huvudsak finns det vanligtvis två sätt som en utvecklare inte kan få vad de vill ha från ett smart kontrakt.

  1. Missförstådd avsikt
  2. Gör ett misstag när du implementerar den avsikten

Många av dessa standardfel kan leda till enorma summor av låsta medel som med Paritetsplånbok eller med Ethereum rekursiv skicka utnyttja i DAO-incident. Formell verifiering används som ett sätt att matematiskt bekräfta att specifika sårbarheter inte kommer att leda till skadliga exploateringsvektorer.

En formell specifikation används som den exakta utdata eller resultatet som ett smart kontrakt letar efter, som en dator kan kontrollera. Verifiering sker därefter när kontraktet sammanställs till bytkoden och den formella verifieringen visar att den sammanställda bytecoden implementerar specifikationen. Men manuell utförande av formella verifieringar är en svår process och ibland kommer med sina egna misstag. Även verifiering av formella bevisresultat kan komma med dess nyanser.

Verktyg som Coq Proof Assistant har utvecklats för att underlätta de mekaniserade bevisen för programmens egenskaper och används för närvarande av flera nya kryptovalutor med de språk de använder inbäddade i Coq.

Medan smart kontraktsgranskning ger ett mycket nödvändigt försäkringsskikt genom kodgranskningar, kan formell verifiering av smarta kontrakt bidra till att minska förekomster av sårbarheter genom matematisk analys ytterligare. När smarta kontrakt blir vanligare verkar det naturligt att tillämpningen av formell verifiering kommer att bli mer utbredd i branschen.

Aktuella tillämpningar av formell verifiering

Flera plattformar integrerar redan formell verifiering eller planerar att göra det snart. Att utvärdera säkerheten för smarta kontrakt som fungerar inom dessa plattformar kommer att vara avgörande för att mäta deras effektivitet för att motverka kritiska sårbarheter.

Zilliqa

Zilliqa är en hög genomströmningskedja som är utformad för att vara värd för skalbara och säkra decentraliserade applikationer (dapps). Flera av de tekniska utvecklarna bakom Zilliqa var författare till den tidigare studien som avslöjade de tusentals smarta svagheterna i kontraktet.

Zilliqa

Zilliqa använder ett nytt programmeringsspråk som heter Scilla, designat av medlemmar i Zilliqa-teamet och några andra medlemsförbund. Scilla är ett mellanliggande språk som är inbäddat i Coq Proof Assistant. Det är tänkt att vara ett översättningsmål för språk på högre nivå för analys och verifiering innan kontrakt sammanställs till bytkod.

Tezos

Tezos är skrivet i OCaml och dess smarta kontraktspråk är Michelson, baserat på OCaml. OCaml valdes på grund av dess funktionella programmeringserbjudanden för hastighet, entydig syntax och semantik och förmåga att implementera formella bevis. Tezos använder också Coq Proof Assistant för att underlätta formell verifiering av smarta kontrakt.

Tezos Guide

Arthur Breitman – Tezos medgrundare – Postad detaljer om verifiering av vissa Michelson kontrakt i Coq, inklusive ett multi-sig-kontrakt på deras testnät förra året. Tezos lanserades nyligen, så dess tillämpning av formell verifiering bör ge ett utmärkt mått på tillståndet för förbättrad säkerhet för smarta kontrakt med metoden. Huruvida exploateringar som har plågat soliditetskontrakt kommer att spelas ut i Tezos kommer att ta lite tid att utvecklas eller inte, men att utvärdera hur säkra smarta kontrakt blir på Tezos kan vara mycket tecken på en fortsatt utveckling.

Cardano

Cardano är skrivet i Haskell och dess smarta kontraktspråk är Plutus, som är baserat på Haskell.

Cardano Guide

Cardano är utformat med ett Cardano Computation Layer (CCL) som består av två lager:

  1. En formellt specificerad ram för virtuell maskin och språk
  2. Formellt angivna språk som underlättar verifiering av smart kontraktskod

Målet är att skapa en miljö som effektiviserar processen för att garantera att ett kontrakt fungerar som utformat utan katastrofala sårbarheter. Noterbart använder Cardano inte en begränsad stackdesign som Ethereums EVM, så att inte oroa sig för stackaritmetiska flöden gör det möjligt att formellt verifiera smarta kontrakt mycket lättare.

Ethereum

Ethereum har undersökt införlivandet av formell verifiering under ganska lång tid, med flera projekt som undersöker dess potential. En sådan publikation, ”Gör smarta kontrakt smartare,”Fokuserar på smarta kontraktsfel och föreslår sätt att mildra dem, inklusive förbättring av den operativa semantiken i Ethereum för att främja formell verifiering.

Ethereum Guide

Gasgränserna i Ethereum gör det utmanande för att genomföra formell verifiering. Vidare är det enda sättet att känna till innebörden av ett soliditetsprogram att kompilera det i bytekod. Kompilatorn ändras snabbt, så verifieringsverktyg skulle också behöva anpassa sig till förändringshastigheten. Med tanke på Ethereums etablerade nätverk och historia skulle formell verifiering av smarta kontrakt i Ethereum uppenbarligen ge den bästa mätaren för deras effektivitet för att mildra sårbarheter om formell verifiering skulle bli allmänt använd i nätverket.

Slutsats

Formell verifiering är en mycket komplex och svår uppgift. Trots detta har det blivit en universell standard i hårdvaruindustrin och kommer sannolikt att fortsätta få fart i programvaruutrymmet. Blockkedjor och kryptovalutanätverk – där högvärdeöverföringar är vanliga – kommer säkert att påskynda denna effekt. Att mäta den positiva effekten av formell verifiering av smarta kontrakt kommer sannolikt att ta flera år att utvecklas eftersom vi bara ser början på vad som borde bli en mycket bredare trend i branschen.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me