Blockchain-sikkerhed: Sådan forstår du Blockchain-revisioner for at forblive sikker i DeFi

Det sidste år har været en temmelig mørk tid inden for krypto. Ikke alene har vi set Lunas katastrofale sammenbrud, degenerationen af ​​3 Arrows Capital, insolvens og konkursproblemer med BlockFi, Celsius, Voyager, VAULD og flere, makroøkonomiske forhold, der har kastet os ned i dybet af en kryptovinter, men det har også været et monumentalt katastrofalt år for hacks og udnyttelser af blockchain og DeFi, hvilket har resulteret i, at folk løber væk fra DeFi hurtigere end svømmere, der flygter fra haj-befængt farvand.

Nu tænker du sikkert ved dig selv, “wow, tak for den deprimerende intro. Krypto lyder som et minefelt!"

Og du tager ikke fejl der, krypto har bestemt sin rimelige andel af risici. Men før du lader al denne undergang og dysterhed give dig lyst til at droppe krypto for evigt og gemme dig under din seng, så frygt ikke, for denne artikel vil hjælpe dig med at lære dig, hvordan du navigerer i DeFi-vandene på den sikrest mulige måde og viser dig, hvad du har brug for at vide om blockchain-sikkerhedsrevisioner.

Selvom dette ikke hjælper med at beskytte mod enhver risiko i krypto, er der ingen beskyttelse af nogen, der beslutter sig for at "YOLO" deres livsopsparing til den næste memecoin, informationen i denne artikel vil i det mindste hjælpe med at udstyre dig med endnu en pil i dit kogger som du kan implementere for i høj grad at forbedre din overordnede sikre navigation af DeFi-rummet.

Bare for at dæmpe nogle frygt tidligt, skal du ikke bekymre dig om, at denne artikel er for teknisk. Denne hjælpsomme guide vil være så let at forstå, at selv min far, der omtaler hele kryptoindustrien som "That Bitcoin Stuff", vil være i stand til at forstå det.

Og fordi jeg er omtrent lige så velbevandret i blockchain-udvikling, som en sten er til at klippe hår, besluttede jeg at få professionel hjælp og insiderråd til denne artikel. Jeg nåede ud til vores venner over kl Ackee Blockchain at hjælpe med at lære mig selv og den gennemsnitlige Joe, hvad pokker disse blockchain-revisioner går ud på.

Jeg vil gerne give en stor ros til Ackee-teamet for at have taget sig tid til at hjælpe os og vores samfund ved at lære os det grundlæggende i blockchain-revisioner og for at samarbejde med os om denne artikel. Blockchain og DeFi revisionsrapporter er et så kritisk vigtigt aspekt af krypto og er noget, som meget få af os virkelig forstår.

Når vi udfører vores due diligence med at bestemme sikkerheden og sikkerheden for en DApp- eller DeFi-protokol, vil mange af os lede efter noget, der siger, at platformen er blevet revideret og måske tænker "okay, godt nok." Jeg ved, at jeg har gjort mig skyldig i det tidligere, men hvad vil det egentlig sige at være blevet revideret? Hvordan kan vi verificere dette? Og som du vil lære i denne artikel, bare fordi noget er blevet revideret, betyder det ikke, at det automatisk skal få grønt lys.

For at starte, lad os se på, hvad blockchain-revisionsvirksomheder faktisk gør.

Hvad gør Blockchain-revisionsfirmaer?

Når vi hører udtrykket "revision", forestiller mange af os automatisk en indelukket gammel fyr i et jakkesæt, der fungerer for regeringen, som kommer til at banke på og gennemgå alle vores regnskaber og kontoudtog med en fintandet kam. I den traditionelle finansielle industri ville du have ret, men det kunne blockchain-revisorer ikke være længere fra.

Blockchain-revisorer er ikke bogholdere på nogen måde, de er eksperter i kodning og udviklerfærdigheder, som leder efter fejl, fejl og ondsindet kode i kildekoden til et blockchain-projekt, smart kontrakt eller kryptotoken.

Forskellige revisionsvirksomheder kan også specialisere sig inden for forskellige områder, hvorfor det altid er godt at se en platform, der er blevet revideret af mere end én virksomhed. Hver revision, der udføres, reducerer risikoen, og en virksomhed kan opfange noget, som den anden virksomhed gik glip af.

1inch er et godt eksempel på dette. 1inch er en DEX-aggregator, der er blevet revideret af flere forskellige virksomheder, hvilket øger brugernes tillid til platformen og fremhæver, at 1inch-teamet har en stærk forpligtelse til at sikre sikkerheden i deres samfund.

Blockchain revisionsfirmaer vil have et team af ingeniører, der kan udføre opgaver som:

• Security Audit
• Værktøjsanalyse
• Manuel kodegennemgang
• Kør og skriv automatiske tests
• Gennemfør Bug Bounty-konkurrencer

Mens andre revisionsfirmaer som Ackee Blockchain også kan opfylde flere "full-service" krav og hjælpe på yderligere områder som:

• Oprettelse af sikre smarte kontrakter om soliditet eller rust
• Assistere med at opbygge et komplet økosystem, håndtere UX, design, frontends, backends og DevOps

Ackee Blockchain bidrager også til blockchain-industrien som helhed, hvilket er fantastisk at se. De har udviklet open source sikkerhedsværktøjer, som alle kan bruge og brænder for at undervise og give muligheder for håbefulde blockchain-udviklere. Tidligere har de været værter for onlinekurser for udviklere, der ønsker at arbejde i blockchain og endda modtaget et tilskud fra Solana Foundation til at drive en sommerskole for Solana.

Holdet tilbyder sommerskoler online, hvor de underviser i Solidity, og i efteråret 2022, Ackee Blockchain CEO og medstifter Josef Gattermayer, Ph.D. vil undervise i emner omkring blockchain-udvikling på Tjekkiske tekniske universitet i Prag. Det er bestemt værd at kontakte Ackee-teamet, tilmelding til kurserne på deres side, og følg dem, hvis du er interesseret i en fremtid inden for blockchain udvikling og sikkerhed.

Som du kan se, kan blockchain-auditering handle om mere end blot at nørde ud i et mørkt rum og gennemsøge kode, der er et helt økosystem indkapslet i nichen.

Hvorfor er Blockchain-revision vigtig?

Hvis mennesker var perfekte, ville der ikke være behov for blockchain-revisionsfirmaer, da hver linje kode ville være skrevet fejlfrit og fuldstændig uigennemtrængelig for udnyttelser, fejl og angreb.

Hvad der er endnu værre, end at mennesker laver fejl, er, at folk kan være korrupte og ondsindede. En ret hyppig hændelse er, at dårlige aktører med vilje vil indtaste ondsindet kode i deres protokol, som vil give dem mulighed for at udnytte en platform, som de har oprettet for at stjæle brugernes penge.

Mellem menneskelige fejl og ondsindede hensigter er smarte kontrakter og blockchain-applikationer/DApps modtagelige for følgende risici:

• Denial of service-angreb, der gør protokollen ubrugelig.
• Tæppetræk/bagdørstyveri, hvor grundlæggerne indtaster ondsindet kode, der giver dem mulighed for at hæve penge, der er placeret i en smart kontrakt.
• Udnyttelse af koden på måder, der gavner hackeren og skader brugere, såsom at præge nye tokens uden for de tilsigtede metoder eller dræne kundemidler fra smarte kontrakter.
• Nogle hackere ønsker simpelthen at "se verden brænde" og vil udnytte enhver fejl, de kan finde, til at beskadige en platform.

Mange DeFi-brugere mener, at en af ​​de vigtigste ting at kigge efter i en DeFi-platform er, om koden er open source eller ej. Dette er et godt første skridt, da mange projekter vil offentliggøre koden på et offentligt websted som Github, hvor alle kan gå ind og tjekke/bekræfte koden selv.

Når man ser på et projekts GitHub-side, er dette ofte en af ​​de ting, som brugere, der overvejer at bruge en DApp, kigger efter ved at bruge 1inch igen som eksempel:

Dette er en god indledende tilgang at tage, når du verificerer ægtheden af ​​en protokol, da det er her fællesskabsmedlemmer eller nogen som helst kan gå ind og kontrollere, at der ikke er nogen ondsindet kode gemt derinde.

Det er også nyttigt at vide, at alle kan poste hvad som helst på GitHub. Koden, der er postet i GitHub, bekræfter ikke automatisk, at det er den samme kode, der kører den smarte kontrakt. Heldigvis kan brugere bekræfte dette ved at gå ind i en blokudforsker som Etherscan og kontrollere, at koden i GitHub faktisk er implementeret og brugt. Her er 1 tommer token i Etherscan, for eksempel. Jeg er tilbøjelig til at være enig i holdningen om, at open source-publicering til GitHub er et godt tegn, men for mig, når jeg klikker ind på GitHub for at se, er alt, hvad jeg ser:

Så i stedet for at min hjerne steger som et æg på et varmt fortov i forsøget på at finde ud af dette, kan jeg godt lide at se, at et team af fagfolk fra et blockchain-revisionsfirma har gennemgået alt dette og har givet det tommelfingeren op.

Det er vigtigt at opklare én ting, og det er, at bare fordi en protokol er blevet auditeret, betyder det ikke, at den er 100 % sikker. Ingen kode kan nogensinde anses for at være fuldstændig uigennemtrængelig for hackforsøg, da hackernes værktøjer og færdigheder hele tiden bliver mere sofistikerede. Ligesom white-hat (gode) hackere og blockchain-udviklere bliver bedre og udvikler sig hele tiden, så er de onde.

Du kan tænke på det lidt som et spil kat og mus, at skrive kode er i bund og grund som at bygge et kreativt puslespil og løse problemer, og hackere leder efter måder at løse eller angribe puslespillet på på stadig mere smarte og sofistikerede måder, så der vil forbliver altid et risikoelement.

Hvorfor 2022 har været særligt dårligt til krypto-udnyttelse

Når vi ser overskrifter som denne:

Det kan være ret hjerteskærende. Kryptoindustrien har fået et seriøst sort øje, da der hver uge ser ud til at være endnu et massivt hack eller udnyttelse, der resulterer i millioner i tabte midler.

Dette er ikke kun trist, da disse er gennemsnitlige mennesker, der mister deres penge, men også bekymrende, da disse angreb udsætter hele kryptoindustrien for stadig mere hård kritik, bremser adoptionen, holder investorer væk og giver regeringer de undskyldninger, de har brug for for at øge deres autoritative kontrol for at "beskytte" investorer, som ofte påtvinger drakoniske foranstaltninger, som mange af os vendte til krypto for at undslippe.

Den primære årsag til dette kommer ned til sjusket udviklerteknik.

Da jeg satte mig ned med Josef fra Ackee, spurgte jeg om hans bud på, hvorfor der har været rekordmange bedrifter, hans forklaring gav mening.

Stærkt parafraserende fortsatte Josef med at forklare mig, at kryptoindustrien vokser hurtigt, og der er et voldsomt kapløb for teams om at lancere deres produkter. Der er mangel på dygtige og erfarne blockchain-udviklere, der er i stand til at imødekomme efterspørgslen, hvilket resulterer i, at mange projekter ansætter nybegyndere og har en "god nok"-attitude, og lancerer DApps uden at de korrekte kontroller og revisioner bliver udført.

Josef fortsatte også med at forklare, at behovet for blockchain-revisionstjenester skyder i vejret, og at der ikke er nok blockchain-revisionsfirmaer til at imødekomme efterspørgslen fra projekter. Dette har resulteret i, at projektteams ikke har ønsket at vente på, at et revisionsteam bliver tilgængeligt, så de går videre og lancerer eller frigiver en opgradering, enten uden en revision eller stoler på en forældet revision, der ikke dækker den nye version eller iteration af en platform.

Dette tema var især til stede under tyreløbet i 2021, men tingene er meget mere afslappede nu, hvor vi er på et bjørnemarked. Projekter har ikke det store travlt med at lancere, og der er færre projekter i revisionsflaskehalsen. Det er rigtigt, at bjørnemarkeder er tiden til at bygge, og hold har en tendens til at tage en mere flittig tilgang i langsommere markedstider.

Vi gennemgik to specifikke vellykkede angreb, der skete for at undersøge præcis, hvad der gik ned, for at hjælpe med at sætte alt dette i perspektiv.

Ethereum DAO Hack fra 2016

I det væsentlige var det, der skete her, noget kendt som en genindtræden-fejl. For at sige det enkelt, udfører koden to instruktioner:

1. Træk
2. Opdater saldo

Hvis det udføres kronologisk, fungerer det som det skal. Men da Ethereum er et distribueret system (i modsætning til web2-programmer), kan kontrakten kaldes fra en anden kontrakt, som giver mulighed for at implementere en tilpasset tilbagekaldsfunktion, der kaldes fra tilbagetrækningsinstruktionen.

Og denne tilbagekaldsfunktion implementeret af hackeren kalder kontrakten igen og derefter igen flere gange, før opdateringsbalanceinstruktionen endelig udføres. Dette giver angriberen mulighed for at trække sig tilbage flere gange.

Dette er en hyppig fejl begået af uerfarne web3-udviklere. Selv 5 år efter dette angreb opstår problemet stadig fra udviklere, der ikke tager sig tid til at lære af denne sag. Løsningen er ret simpel i dette tilfælde, og det er bare at sætte de to linjer kode i modsat rækkefølge. Først opdatering, derefter tilbagetrækning.

Auditorer leder efter kendte problemer som dette, når de reviderer en protokol.

Solana Wormhole Attack 2022

2022 kom ikke godt fra start med det første store angreb på Solana i begyndelsen af ​​februar. Angriberen omgik en signaturbekræftelse i et Rust-program, så det så ud som om, at vogterne havde underskrevet en 120 ETH-indbetaling i Wormhole på Solana, selvom de ikke havde gjort det. Angriberen slog derefter til 120 indpakket ETH på Solana.

Før dette ormehulsangreb antog mange i kryptosamfundet, at Solana og Rust-udvikling var for svær at lære at tiltrække amatørudviklere. Dette førte til den tro, at kun de bedste udviklere arbejdede på Solana, hvilket betyder, at der ikke var et så stort behov for revisioner. Efter dette angreb nævnte Josef, at han og hans team så en betydelig stigning i revisionsanmodninger for Solana DApps og protokoller.

Efter alt dette tænker du måske, at hvis mennesker er kilden til fejl og skadelige hensigter, ville det så ikke give mening bare at have computere og kunstig intelligens-maskiner, som sandsynligvis ikke begår fejl og ikke er i stand til ondsindede hensigter, så skriv bare al denne kode for os?

Det er et godt spørgsmål, og på grund af artikler som den ovenfor, er dette også noget, der har strejfet mig. Det vil vi dække i næste afsnit.

Fremtiden for Blockchain-sikkerhed

Det er tydeligt, at vi bevæger os mod en fremtid, hvor mange af vores job vil blive outsourcet til computere og AI-programmer, der kan udføre menneskers job langt bedre, end vi kan.

Det ser vi allerede med automatiserede kasserere og bilfabrikker, der har flere robotter end mennesker. Computere overtager endda højt specialiserede job som læger og farmaceuter, da en robot kan være mere præcis med en skalpel, og et computerprogram kan gennemsøge hele databasen af ​​medicin og inden for få sekunder udfylde rapporter om, hvad medicin kan og ikke kan blandes med andre kemikalier og medicin, en opgave umulig for et menneske.

Jeg troede med sikkerhed, at programmering og udvikling ville være et af de første job, der blev erstattet af computere. Hvis det er alle bogstaver og tal på en skærm, der er konstrueret på en måde til at udføre visse opgaver, så kunne en computer sikkert gøre det bedre end et menneske, med færre fejl ikke?

Jeg troede, at blockchain-revisionsfirmaer ville gå Dodo-fuglens vej (uddød), da når computere begynder at udvikle sig autonomt, vil der ikke være nogen fejl at finde. Dette fremhævede, hvor lidt jeg vidste om udvikling, da Ackee-teamet forklarede nogle koncepter, som jeg ikke havde værdsat.

En stor del af blockchain-udvikling er problemløsning og at se på et 360-graders billede af et problem. Det kræver en stor mængde kreativitet og "uden for boksen" at tænke, som computere ikke er i stand til. Det er ikke bare så simpelt som "når 'X' sker, udfør 'Y'."

Vi skal også overveje, at mange af disse DApps og applikationer forsøger at løse "menneskelige" problemer, og hvordan vi interagerer med systemer, protokoller og procedurer. Undskyld lille Butter Bot, men du er ikke skåret ud til at forstå menneskelige problemer og give menneskelige løsninger.

Ikke alene skyder jobs inden for blockchain-udvikling og sikkerhed i vejret, men det ser ud til, at der vil være behov for disse roller i de kommende år.

Det betyder dog ikke, at der ikke sker nogen automatisering i web3-udviklingsområdet. Der er masser af gratis værktøjer til udviklere, der giver dem noget sikkerhedsfeedback og hjælper med at aflaste noget af arbejdet, så udviklere kan fokusere på andre opgaver.

For eksempel på Ethereum er der en god statisk kodeanalysator ved navn Slither det er meget populært, og Ackee Blockchain arbejder på deres egen open source statiske analysator kaldet vågnede, som registrerer ting anderledes end Slither, hvilket reducerer byrden ved at skulle manuelt analysere koden.

Ackee-teamet afslørede også en tendens på Solana vedrørende et problem med tests. Udviklere skrev ikke nok af dem, da det er ret arbejdskrævende, med behovet for at skrive en masse boilerplate-kode. Så Ackee Blockchain stod i spidsen for et projekt, hvor de skrev en open source-testramme for Solana kaldet Trdelnik som vil give udviklere mulighed for at skrive test nemmere. Holdet fik en hæderlig omtale og vandt en Marinade-pris under en hackathon i Prag for Trdelnik.

Alt dette viser os, at det er sandsynligt, at automatisering og computere vil spille en stadig vigtigere rolle i at hjælpe blockchain-udviklere og sikkerhedsrevisorer, men det er usandsynligt, at de vil erstatte dem på et tidspunkt snart.

Den generelle stemning blandt blockchain-udviklere er, at mange af disse hacks og udnyttelser er et resultat af, at dette stadig er en ung og uerfaren industri. Efterhånden som blockchain-industrien fortsætter med at udvikle sig og modnes, burde der være færre og færre udnyttelser, hvilket resulterer i, at det samlede kryptorum bliver mere sikkert og brugervenligt.

Okay, lad os nu komme ind på de gode ting, den vigtigste takeaway fra denne artikel.

Sådan bekræfter du, at en platform er blevet revideret

Det allerførste skridt er faktisk at sikre, at der er en revision at finde. Disse kan findes i projektets GitHub-lager, og eventuelle udførte revisioner bør tydeligt nævnes i projektets dokumenter eller på selve platformens hjemmeside. Hvis du ikke kan finde nogen omtale af en revision, ville jeg holde mig væk.

Ingen offentlig tilgængelig revision betyder sandsynligvis, at:

• Der er ikke foretaget revision
• Der har været en mislykket revision, som projektet ikke ønsker at blive kendt
• Revisionen opdagede problemer, som holdet ikke behandlede
• Koden indeholder ondsindede bagdørsruter, der kan føre til tyveri

Som tidligere nævnt er det også rart at se, at koden er open source ved at være mærket "offentlig" på GitHub. Dette er ikke et krav, men det er stadig en bonus. Der er dog grunde til ikke at åbne kildekode, så det er ikke altid en deal breaker. Årsager til ikke at åbne kildekode kan være ting som:

• Virksomheder, der ønsker at bevare en konkurrencefordel. Så snart en virksomhed åbner deres kode, kan enhver oprette den samme protokol og konkurrere. Det er derfor, Coca-Cola holder deres opskrift hemmelig, og KFC har berømt deres "Tophemmelige 11 urter og krydderier."
• Når først en kode er offentlig, kan hackere bruge oplysningerne til at lede efter udnyttelser. Selvom god praksis gør det modsatte, udgiver de det, hvis et projekt har tillid til sin kode.
• Tidlige projekter vil måske ikke åbne deres kode med det samme, før de har opbygget et stort fællesskab og nok brugere, hvilket skaber en hindring for potentielle konkurrenter.

Jeg mødtes for nylig med et projekthold, der fortrød at åbne deres platform med det samme, da en konkurrerende virksomhed simpelthen kopierede deres kode og forretningsmodel og havde flere midler til at betale influencers og betale for følgere. Dette fik det til at se ud til, at det konkurrerende firma var den bedre platform lige fra lanceringen, da det gav indtryk af flere brugere og en større tilhængerskare. Den konkurrerende virksomhed er nu markant foran det oprindelige stifterteam, som valgte at vokse mere organisk og etisk.

Her er et flot billede fra Bridge Global der opsummerer nogle af de generaliserede forskelle mellem open source og closed source software:

To interessante tilgange til åben vs lukket kildekode kan findes ved at sammenligne populære hardware tegnebøger Sikker indbetaling , Ledger. Trezor valgte at udgive 100 % af sin kildekode til offentligheden, så alle kunne verificere dem, mens Ledger valgte at spille sine kort tættere på brystet og åbnede noget kode, men beholde sin firmware lukket kilde.

Dette førte til, at mange blockchain-elitister valgte Trezor frem for Ledger, da de mente, at Ledger burde open source deres kode, og undrede sig over, hvad de forsøger at skjule. Jeg ser personligt ikke dette som en grund til bekymring, da Ledger har bevist deres track record og dedikation til rummet, og er vokset til at blive en af ​​de største hardware wallet udbydere i verden, hvilket skaber noget af den højeste kvalitet sikker kryptolagring enheder.

Når en revision er blevet gennemført og lokaliseret, så længe den er blevet offentliggjort, kan enhver åbne dokumentet og finde resultaterne af revisionen. I stedet for at rulle gennem hele revisionsdokumentet, for vores enkle formål, er alt, hvad vi behøver at kigge efter, siden "Resursoversigt", som ofte ser sådan ud:

Denne side vil enten være placeret i begyndelsen eller slutningen af ​​rapporten. Det er en side, der viser resultaterne af revisionen i et simpelt format, som den gennemsnitlige person kan forstå. Lad os dykke ned i, hvilke oplysninger dette viser os.

Er revisionen nylig? Revisioner bør være en kontinuerlig service, og der bør absolut være en ny revision, der bliver lavet for HVER opdatering, version eller ny feature/funktion, der introduceres. Hvis der er blevet lanceret en ny funktion eller version, er de tidligere revisionsresultater ikke længere gyldige, da kodebasen sandsynligvis har ændret sig.

Dette kan verificeres ved at se på projektversionen og/eller begå hash. Udgaven er noget som når du ser Uniswap "V2" (version 2), og commit-hash identificerer en revision i kildekodelageret. Når man ser på den version eller commit-hash, der er vist i revisionen, som kan ses på billedet ovenfor i tabellen med overskriften "repository", kan brugere kontrollere, at den falder sammen med versionen eller commit-hash vist i GitHub.

Det kommer til at se sådan ud:

Her er et andet look fra en af ​​Ackee Blockchain Audits:

Selvom commit-hashen ikke stemmer overens, betyder det ikke nødvendigvis, at der er et rødt flag. Commit-hashen på projektets GitHub ændres hver gang en ny justering eller iteration foretages. Hver justering vil ændre commit-hashen og burde ikke give anledning til bekymring, hvis der kun var en mindre justering.

Hvis du ikke kan se commit-hashen fra revisionen på GitHub-hovedsiden, kan du gå ind i "Commit History" og søge efter commit-hashen og selv se, hvor meget der har ændret sig siden revisionen blev udført.

Det kan gøres ved at klikke her:

Så søg her:

Da en ny commit-hash er udfyldt for hver ændring, hver med et dato- og tidsstempel, hvis der har været et betydeligt antal nye commits mellem det tidspunkt, hvor revisionen blev udført, og den commit-hash, som projektet er i øjeblikket på, kan du evt. ønsker at overveje at vente til endnu en revision er gennemført, før man involverer sig.

Hvis du har et analytisk øje og ønsker at dykke dybere ned, kan du klikke ind i hver ny commit-hash og sammenligne den gamle kode vist i rødt med den nye kode vist i grønt og selv kontrollere, hvad der præcist er ændret:

Hvis du bemærker en ny commit-hash, der er anderledes end da revisionen blev udført, og ser noget som dette:

Det er en af ​​de ubetydelige ændringer, jeg nævnte, og selvom det udfyldte en ny commit-hash, er det ikke noget at bekymre sig om, da dette var en simpel omdøbning af en fil. GitHub-billedet ovenfor viser 0 tilføjelser og 0 sletninger.

Nu til den næste ting at kigge efter i resuméet:

Problemer - Resuméet viser alle de problemer, der blev afsløret under revisionen, og endnu vigtigere, hvis teamet løste problemerne. Denne sektion kan ses nær bunden, hvor den viser "Samlede problemer", og derefter går til at opdele dem i sværhedsgrad og om de blev løst eller ej. Revisionsfirmaet identificerer først problemer, markerer dem til udviklerteamet og tjekker derefter koden igen, når udviklerne har behandlet problemerne, før revisionsteamet vil markere problemet som "løst".

Det er klart, at alle problemer, der er markeret som "Kritisk" eller "Høj risiko", skal løses. Selvom rapporten viser, at alle de kritiske eller højrisikoproblemer er blevet løst, skal dette stadig noteres med en vis skepsis over for projektet. Hvis revisionsteamet fandt et stort antal kritiske problemer til at begynde med, kan det fremhæve, at udviklerteamet bag projektet kan være ret nybegyndere, hvilket fører til yderligere og yderligere problemer hen ad vejen.

Medium eller lav risiko problemer er almindelige og normalt ikke en grund til bekymring. Revisionsteamet kan endda markere noget som et lavrisikoproblem, hvis de blot foreslår et alternativ eller har en meningsforskel om, hvordan man griber noget an.

Her er en oversigt over, hvad hver af kategorierne betyder:

Kritisk - Alt markeret som kritisk betyder, at noget kan udnyttes lige nu.

Teamet hos Ackee Blockchain fortalte mig en historie om en revision, de var i gang med, hvor de fandt et kritisk problem på en protokol, der allerede var lanceret. De vækkede projektets udviklerteam kl. 5 om morgenen i en nødsituation "alle hænder på dækket" for at reparere koden ASAP. Heldigvis fangede de problemet i tide, før hackere var i stand til at identificere sårbarheden.

Høj alvorlighed – Problemer, der ikke kan udnyttes nu, men kan være, hvis nogle specifikke sekvenser er opfyldt.

Mellem til lav – Disse er ofte mindre justeringer, der er nødvendige eller anbefalinger og ikke nødvendigvis sikkerhedstrusler.

Forskellige revisionsfirmaer vil også skrive resuméer i forskellige formater. Ovenstående resumé er lavet af revisionsfirmaet Quantstamp. Ackee Blockchain leverer PDF'en med revisionen og et webresumé, der kombinerer indledende og opfølgende resultater i mere et essayformat, der er lettere at læse. Det kan du finde et eksempel på i deres Revisionsoversigt.

Yderligere ting at kigge efter:

• Er der gennemført en revision af mere end én virksomhed? Jo flere øjne, der leder efter problemer, jo mindre chance er der for, at der findes en fejl i koden.
• Er blockchain-revisionsfirmaet professionelt og respekteret i samfundet? Hvis du aldrig har hørt om revisionsfirmaet før, så tag et kig på deres hjemmeside og se efter andre projekter, som de har arbejdet på. Er nogen af ​​de platforme, de har revideret, velrenommerede? Tjek for at se, om nogen af ​​platformene blev udnyttet, efter at virksomheden udførte en revision, dette kunne fremhæve en track record med dårlige revisionskompetencer. Se efter ting som vundne hackathons og støtte/tilskud fra lag 1 netværksfonde.

Et godt eksempel på dette er Ackee Blockchain, som er blevet tildelt officielle udviklings-/samfundsstipendier af fire nøglefonde: Coinbase Giving, Ethereum Foundation, Solana Foundation og Tezos Foundation.

Hvis du er en person, der forståeligt nok er blevet tillidsfuld i denne tidsalder af misinformation, hvis du ser en påstand som billedet ovenfor taget fra Ackee Blockchain-webstedet, i stedet for at tage deres ord for det, kan du altid navigere til fondenes hjemmesider nævnt og verificer påstandene selv.

Grunden til, at jeg siger dette, er, fordi i mine år med at skrive anmeldelser, er antallet af websteder, der hævder, "Featured in Forbes eller Yahoo Finance", overvældende, når de aldrig har været det. Jeg ville ønske, at der var en form for internetpoliti, der kunne hive virksomheder i internetfængsel for løgnagtige og vildledende udtalelser som den. Det er derfor, der i krypto er et ordsprog, "stol ikke på, verificer." Bare rolig, Ackee tjekker ud og er faktisk betroet af ovenstående fonde, jeg tjekkede 😉

Lukning Tanker

Nå, der har du det. Nogle oplysninger om blockchain-sikkerhed, som jeg håber, du fandt nyttige. Jeg håber, at denne artikel hjælper dig med at føle dig mere sikker på at begive dig ud i kryptoverdenen med endnu et lag rustning og være i stand til at navigere i kryptofarvandet mere sikkert end før. Jeg ved, at jeg vil være flittig med at verificere disse oplysninger, næste gang jeg vælger, hvilke DApps og protokoller jeg vælger at stole på med mine kryptoaktiver.

Som man siger, "i krypto handler det ikke om, hvor meget du tjener, det handler om, hvor meget du beholder," da mange af os gamle crusty krypto-veteraner desværre har mistet mere end vores rimelige andel af Satoshis i et utal af hacks, svindel, tæppetræk, konkurser osv. Jo mere viden vi har, jo bedre kan vi beskytte os mod mange af de barske risici, der findes i denne nye og spirende skøre kryptoverden.

Ansvarsfraskrivelse: Dette er skribentens meninger og bør ikke betragtes som investeringsrådgivning. Læsere bør lave deres egen research.