Sådan kontrolleres smart kontrakt: Du skal se på koderne!

Af Dr. Smartcontract om hovedstaden

Godt nytår!

Mit forrige indlæg handlede om DAO-vedhæftningen, der viser, hvordan smart kontraktfejl ville ske og påvirke blockchain-sikkerheden.

Kort fortalt kan en sådan fiasko ske, da "hullet" i smart kontrakt tillader et brud på den smarte kontrakters forudsætning.

Konsekvensen vil være ikke kun økonomiske tab, men også en revne i troen på blockchain-netværk, der resulterer i ”tvivl”.

Yess, DOUB T.

Så hvordan ville du være i stand til at holde den smarte kontrakt sikker?

Det er her du har brug for at bringe begrebet "revision" til din smarte kontrakt.

Revision er et koncept, der oftest ses i regnskab. Ja, penge.

Det er simpelthen en gennemgang af finansielle poster, der kontrollerer, om pengene gik ind og ud korrekt.

Finansiel revision sigter mod at finde svig ved brug af virksomhedsbudget.

Og det samme gælder den smarte kontrakt.

Smart kontraktrevision er en proces til gennemgang af smarte kontraktkoder.

Når den økonomiske revision søger efter de fejl, der er skjult i de monetære poster, ser den smarte kontraktrevision også dybt ind i de skriftlige koder for at opdage fejl.

En god bugjagt.

I computerprogrammering kaldes en sådan revisionsproces “kodeanalyse”.

Til højre er den smarte kontraktrevision baseret på en række kodeanalyser.

I tilfælde af at du ikke ved, hvad kildekoden er, er det det komplekse udvalg af alfabeter, som computer fyre altid sætter på deres skærm, især i sort baggrund.

Der er flere metoder til kodeanalyse, der er sikkerhedskopieret af forsøg på at finde fejl mere effektivt.

Men den helt grundlæggende ”kildekodeanalyse”, som du først har brug for.

Kildekodeanalyse er en automatiseret måde at teste kildekoder til et program for at registrere og korrigere eventuelle fejl, der findes i koderne.

Med andre ord er det ligesom et computerprogram til sundhedspleje at sikre sig, at de ikke har nogen sygdom.

Kildekodeanalyse har to måder at gøre. Den ene er Top Down-metoden, den anden er Bottom Up-metoden.

For det første analyserer Top Down-metoden koder ved at følge programmeringsprocessen helt fra begyndelsen. Det giver dig mulighed for let at forstå den samlede struktur i et program. Da det giver dig et overblik, kan det opdage fejl ikke kun i grundlæggende funktioner eller variabler, men også i programmeringslogik og algoritme.

Imidlertid har en sådan måde at analysere meget tid på at blive afsluttet, da den gennemgår alle koder inklusive en uden fejl.

Det er en tidskrævende sorgundersøgelse.

Top Down skurriserer hele programkoderne.

Fra bunden vælger derimod en bestemt rutine blandt et program og sporer den tilbage for at finde rutinens oprindelse - dvs. variabler og funktioner. Det kan starte analyse fra de tidligere kendte, mistænkelige koder. Det er snarere målorienterede, specifikke analysemetoder, der kræver mindre tid end Top Down-tilgang.

Ikke desto mindre, i modsætning til Top Down, kan den ikke fuldt ud forstå den overordnede struktur i et program og går derfor ofte glip af programmets mainstream-logik.

I bottom up-tilgang kan du vælge et sted, der er mistænkeligt, og klatre op for at finde ud af, hvad der gik galt.

Det kan godt siges som en "deduktiv kontra induktiv" tilgang.

Der er en anden type kodeanalyse, du har brug for at vide for at forstå, hvordan smart kontraktrevision fungerer.

Det kaldes ”bytecode-analyse”, der ofte bruges i smart kontraktrevision med kildekodeanalyse.

Bytecode består af binære tal (dvs. 0 og 1), og det er snarere et computercentreret sprog end andre maskinsprog.

I modsætning til kildekoden designet til at blive læst af mennesker, er bytecode mere specifik og opsummeret, at det er valgt at blive læst af computere.

Åh ja. Dette minder mig om Matrix-verdenen.

Nah, dette billede gør mine øjne elendige.

>

>

:(

>

>

Nu meget bedre.

Tilbage til emnet er grunden til, at smart kontraktrevision bruger bytecode-analyse, fordi det er en temmelig effektiv måde at gennemgå koder på.

Kildekodeanalyse er meget effektiv, da den giver hurtig feedback og giver udviklere mulighed for at afbøde risici på farten.

Kodeanalyse skal dog være præcis.

Det skal være i stand til at snyde fejlene! (Billedkilde: BTCmanager)

For hvis det tager uger og måneder at anlayse koder, der forsinker frigivelsen af ​​dit program, og der stadig er fejl, forbliver uopdaget, kan indsatsen, du lægger i revisionsprocessen, vise sig at være meningsløs.

Bytecode kører, selvom kildekoden kører direkte over computerens operativsystem, over et applikationsprogram. Med andre ord kører det i en virtuel tilstand og kræver mindre hardware-ressourcer.

Det lyder fedt, når du ved, at bytecode ser fri ud for hardwarespecifikationer. Bytecode-analyse har imidlertid en forudsætning for, at alle koder skal scannes, og sårbarheder skal prioriteres først, før afhjælpning.

På trods af al den indsats, som bytecode-analyse har brug for, viser den generelt et bedre resultat af analysen end kildekodeanalyse, der tilføjer præcision til hele revisionsprocessen.

Ved at kombinere kildekode og bytecode-analyse kan du gennemgå en dybere gennemgang af din smartkontrakts kode.

Faktisk har bytecode-analyse og kildekodeanalyse et komplementært forhold. Bytecode-analyse er ikke i stand til at spore tilbage fundne fejl i kildekoden. Alligevel kan det finde fejl, der stammer fra kompileringsprocessen, hvilket kildekodeanalyse ikke er i stand til at gøre.

I dag har jeg talt om de helt basale begreber inden for kodeanalyse som en introduktion til smarte kontraktrevisioner.

I det næste indlæg vil jeg skrive mere dybtgående om kildekodeanalyse, der er bedre kendt som "statisk analyse". Så vær venlig at holde øje med min blog!

Om mig…

Drevet af Scope, en high-tech blockchain smart kontraktrevisionsløsning, vil Dr. Smart kontrakt præsentere alt om blockchain smart kontrakt fra meget grundlæggende til aktuelle sikkerhedsspørgsmål.

Så vær opmærksom på min ydmyge blog!

Om rækkevidde