Blockchain-säkerhet: Hur man förstår Blockchain-revisioner för att vara säker i DeFi

Det senaste året har varit en ganska mörk tid inom krypto. Vi har inte bara sett Lunas katastrofala kollaps, 3 Arrows Capitals degeneration, insolvens och konkursproblem med BlockFi, Celsius, Voyager, VAULD med flera, makroekonomiska förhållanden som har störtat oss i djupet av en kryptovinter, men det har också varit ett monumentalt katastrofalt år för blockchain- och DeFi-hack och utnyttjande, vilket har resulterat i att människor flyr från DeFi snabbare än simmare som flyr haj-angripna vatten.

Nu tänker du förmodligen för dig själv, "wow, tack för det deprimerande introt. Krypto låter som ett minfält!"

Och du har inte fel där, krypto har verkligen sin beskärda del av riskerna. Men innan du låter all denna undergång och dysterhet få dig att vilja lämna krypton för alltid och gå och gömma dig under din säng, frukta inte, för den här artikeln kommer att hjälpa dig att lära dig hur du navigerar i DeFi-vattnet på säkrast möjliga sätt och visar dig vad du behöver veta om blockchain-säkerhetsrevisioner.

Även om detta inte kommer att hjälpa till att skydda mot alla risker i krypto, finns det inget skydd för någon som bestämmer sig för att "YOLO" sina livsbesparingar till nästa memecoin, informationen i den här artikeln kommer åtminstone att hjälpa dig att utrusta dig med ytterligare en pil i ditt koger som du kan använda för att avsevärt förbättra din övergripande säkra navigering av DeFi-utrymmet.

Bara för att dämpa vissa farhågor tidigt, oroa dig inte för att den här artikeln är för teknisk. Den här hjälpsamma guiden kommer att vara så lätt att förstå att även min pappa som hänvisar till hela kryptoindustrin som "That Bitcoin Stuff" kommer att kunna förstå det.

Och eftersom jag är ungefär lika väl insatt i färdigheterna att utveckla blockchain som en sten är på att klippa hår, bestämde jag mig för att få lite professionell hjälp och insiderråd för den här artikeln. Jag kontaktade våra vänner kl Ackee Blockchain att hjälpa mig att lära mig själv, och den genomsnittlige Joe, precis vad fan dessa blockkedjerevisioner handlar om.

Jag vill ge en stor hyllning till Ackee-teamet för att de tog sig tid att hjälpa oss och vårt samhälle genom att lära oss grunderna för blockchain-revisioner och för att de samarbetade med oss ​​i den här artikeln. Blockchain och DeFi revisionsrapporter är en så kritiskt viktig aspekt av krypto och är något som väldigt få av oss verkligen förstår.

När vi gör vår due diligence för att fastställa säkerheten och säkerheten för ett DApp- eller DeFi-protokoll, kommer många av oss att leta efter något som säger att plattformen har granskats och kanske tänker "okej, bra nog." Jag vet att jag har gjort mig skyldig till det tidigare, men vad innebär det egentligen att ha blivit granskad? Hur kan vi verifiera detta? Och som du kommer att lära dig i den här artikeln, bara för att något har granskats, betyder det inte att det automatiskt ska få grönt ljus.

Till att börja med, låt oss titta på vad blockchain-revisionsföretag faktiskt gör.

Vad gör Blockchain-revisionsföretag?

När vi hör termen "revision" föreställer många av oss automatiskt en kvav gammal snubbe i kostym som fungerar för regeringen som kommer att knacka och gå igenom alla våra ekonomi- och kontoutdrag med en fintandad kam. I den traditionella finansbranschen skulle du ha rätt, men blockchain-revisorer kunde inte vara längre ifrån det.

Blockchain-revisorer är inte revisorer på något sätt, de är experter på kodning och utvecklarfärdigheter som letar efter buggar, fel och skadlig kod i källkoden för ett blockchain-projekt, smart kontrakt eller kryptotoken.

Olika revisionsbolag kan specialisera sig inom olika områden också, varför det alltid är bra att se en plattform som har granskats av mer än ett företag. Varje revision som görs minskar risken och ett företag kan ta tag i något som det andra företaget missat.

1inch är ett bra exempel på detta. 1inch är en DEX-aggregator som har granskats av flera olika företag, vilket ökar användarnas förtroende för plattformen och framhäver att 1inch-teamet har ett starkt engagemang för att säkerställa säkerheten i sitt samhälle.

Blockchain-revisionsföretag kommer att ha ett team av ingenjörer som kan utföra uppgifter som:

• Säkerhetsanalys
• Verktygsanalys
• Manuell kodgranskning
• Kör och skriv automatiska tester
• Genomför Bug Bounty-tävlingar

Medan andra revisionsföretag som Ackee Blockchain också kan uppfylla fler "fullservice"-krav och hjälpa till på ytterligare områden som:

• Skapa säkra smarta kontrakt på soliditet eller rost
• Hjälp till att bygga ett komplett ekosystem, hantera UX, design, frontends, backends och DevOps

Ackee Blockchain bidrar också till blockkedjebranschen som helhet, vilket är fantastiskt att se. De har utvecklat säkerhetsverktyg med öppen källkod som alla kan använda och brinner för att lära ut och ge möjligheter för blivande blockkedjeutvecklare. Tidigare har de varit värd för onlinekurser för utvecklare som vill arbeta i blockchain och till och med fått ett bidrag från Solana Foundation för att driva en sommarskola för Solana.

Teamet erbjuder sommarskolor online där de undervisar i Solidity, och hösten 2022, Ackee Blockchain VD och medgrundare Josef Gattermayer, Ph.D. kommer att undervisa i ämnen kring blockchain-utveckling på Tjeckiska tekniska universitetet i Prag. Det är definitivt värt att nå ut till Ackee-teamet, anmäla sig till kurserna på deras sida, och följ dem om du är intresserad av en framtid inom blockkedjeutveckling och säkerhet.

Som du kan se kan blockchain-revision handla om mer än att bara nörda i ett mörkt rum och skura igenom kod, det finns ett helt ekosystem inkapslat i nischen.

Varför är Blockchain-revision viktig?

Om människor var perfekta skulle det inte finnas något behov av blockchain-revisionsföretag eftersom varje rad kod skulle skrivas felfritt och helt ogenomtränglig för utnyttjande, fel och attacker.

Vad som är ännu värre än att människor gör misstag, är att människor kan vara korrupta och illvilliga. En ganska ofta förekommande händelse är att dåliga aktörer avsiktligt kommer att mata in skadlig kod i sitt protokoll som gör att de kan utnyttja en plattform som de skapat för att stjäla användarnas pengar.

Mellan mänskliga fel och uppsåt, är smarta kontrakt och blockchain-applikationer/DApps mottagliga för följande risker:

• Denial of service-attacker som gör protokollet oanvändbart.
• Rug pulls/back door stöld där grundarna anger skadlig kod som tillåter dem att ta ut pengar som placerats i ett smart kontrakt.
• Att utnyttja koden på ett sätt som gynnar hackaren och skadar användarna, som att slå nya tokens utanför de avsedda metoderna eller tappa kundmedel från smarta kontrakt.
• Vissa hackare vill helt enkelt "se världen brinna" och kommer att utnyttja alla fel de kan hitta för att skada en plattform.

Många DeFi-användare anser att en av de viktigaste sakerna att leta efter i en DeFi-plattform är om koden är öppen källkod eller inte. Detta är ett bra första steg eftersom många projekt kommer att publicera koden på en offentlig webbplats som Github, där vem som helst kan gå in och kontrollera/verifiera koden själv.

När man tittar på ett projekts GitHub-sida är detta ofta en av sakerna som användare som funderar på att använda en DApp letar efter, med 1inch igen som ett exempel:

Detta är ett bra första tillvägagångssätt att ta när man verifierar äktheten av ett protokoll eftersom det är här communitymedlemmar eller vem som helst kan gå in och verifiera att det inte finns någon skadlig kod gömd där.

Det är också bra att veta att vem som helst kan lägga upp vad som helst på GitHub. Koden som publiceras i GitHub bekräftar inte automatiskt att det är samma kod som kör det smarta kontraktet. Lyckligtvis kan användare verifiera detta genom att gå in i en blockutforskare som Etherscan och kontrollera att koden i GitHub faktiskt distribueras och används. Här är 1 tums token i Etherscan, till exempel. Jag tenderar att hålla med om att öppen källkodspublicering till GitHub är ett gott tecken, men för mig, när jag klickar in på GitHub för att ta en titt, är allt jag ser:

Så istället för att min hjärna steker som ett ägg på en varm trottoar och försöker komma på det här, gillar jag att se att ett team av proffs från ett blockchain-revisionsföretag har letat igenom allt detta och gett tummen upp.

Det är viktigt att klargöra en sak, och det är att bara för att ett protokoll har granskats betyder det inte att det är 100% säkert. Ingen kod kan någonsin anses vara helt ogenomtränglig för hackförsök eftersom hackares verktyg och färdigheter blir mer sofistikerade hela tiden. Precis som white-hat (bra) hackare och blockchain-utvecklare blir bättre och utvecklas hela tiden, så blir de onda.

Du kan tänka på det ungefär som ett spel med katt och råtta, att skriva kod är i grunden som att bygga ett kreativt pussel och lösa problem, och hackare letar efter sätt att lösa eller attackera pusslet på allt smartare och sofistikerade sätt, så det kommer förblir alltid ett riskmoment.

Varför 2022 har varit särskilt dåligt för kryptoexploateringar

När vi ser rubriker så här:

Det kan vara ganska hjärtskärande. Kryptoindustrin har fått ett allvarligt öga eftersom det varje vecka verkar ske ytterligare ett massivt hack eller utnyttjande som resulterar i miljoner i förlorade pengar.

Detta är inte bara tråkigt eftersom dessa är genomsnittliga människor som förlorar sina pengar, utan också oroande eftersom dessa attacker utsätter hela kryptoindustrin för allt hårdare kritik, saktar ner adoptionen, håller investerare borta och ger regeringar de ursäkter de behöver för att öka sin auktoritativa kontroll för att "skydda" investerare, ofta införa drakoniska åtgärder som många av oss vände sig till krypto för att undkomma.

Den främsta anledningen till detta beror på slarvig utvecklarteknik.

När jag satte mig ner med Josef från Ackee bad jag om hans syn på varför det har varit rekordmånga bedrifter, hans förklaring var vettig.

Tungt parafraserande fortsatte Josef med att förklara för mig att kryptoindustrin växer snabbt och att det pågår ett hårt lopp för team att lansera sina produkter. Det finns en brist på skickliga och erfarna blockchain-utvecklare som kan möta efterfrågan, vilket resulterar i att många projekt anställer nybörjare och har en "tillräckligt bra" attityd, och lanserar DApps utan att ordentliga kontroller och revisioner görs.

Josef fortsatte också med att förklara att behovet av blockchain-revisionstjänster skjuter i höjden, och det finns inte tillräckligt med blockchain-revisionsföretag för att möta efterfrågan från projekt. Detta har resulterat i att projektteam inte vill vänta på att ett revisionsteam ska bli tillgängligt, så de går vidare och lanserar eller släpper en uppgradering, antingen utan en revision eller förlitar sig på en inaktuell revision som inte täcker den nya versionen eller iterationen av en plattform.

Detta tema var särskilt närvarande under 2021 års bull run, men saker och ting är mycket mer avslappnade nu när vi är på en björnmarknad. Projekten har inte så stor brådska att starta och det finns färre projekt i revisionsflaskhalsen. Det är sant att björnmarknader är tiden för att bygga, och team tenderar att ta ett mer noggrant tillvägagångssätt under långsammare marknadstider.

Vi gick igenom två specifika framgångsrika attacker som hände för att undersöka exakt vad som gick ner, för att hjälpa till att sätta allt detta i perspektiv.

Ethereum DAO Hack 2016

I huvudsak var det som hände här något som kallas en återinträdesbugg. För att uttrycka det enkelt, koden kör två instruktioner:

1. Dra
2. Uppdatera saldo

Om den utförs kronologiskt fungerar den som den ska. Men eftersom Ethereum är ett distribuerat system (till skillnad från web2-program), kan kontraktet anropas från ett annat kontrakt som ger en möjlighet att implementera en anpassad återuppringningsfunktion som anropas från återkallningsinstruktionen.

Och denna återuppringningsfunktion implementerad av hackaren anropar kontraktet igen och sedan igen flera gånger innan uppdateringsbalansinstruktionen slutligen exekveras. Detta gör att angriparen kan dra sig tillbaka flera gånger.

Detta är ett vanligt misstag som görs av nybörjare av webb3-utvecklare. Även 5 år efter denna attack uppstår problemet fortfarande från att utvecklare inte tar sig tid att lära av det här fallet. Lösningen är ganska enkel i det här fallet, och det är att bara lägga de två kodraderna i motsatt ordning. Först uppdatering, sedan uttag.

Revisorer letar efter kända problem som detta när de granskar ett protokoll.

Solana Wormhole Attack 2022

2022 fick inte en bra start med den första stora attacken mot Solana i början av februari. Angriparen gick förbi en signaturverifiering i ett Rust-program så det såg ut som att vårdnadshavarna hade skrivit på en 120k ETH insättning i Wormhole på Solana, även om de inte hade gjort det. Angriparen slog sedan till 120 XNUMX insvept ETH på Solana.

Innan denna maskhålsattack antog många i kryptogemenskapen att utvecklingen av Solana och Rust var för svår att lära sig för att locka amatörutvecklare. Detta ledde till tron ​​att bara de bästa utvecklarna arbetade på Solana, vilket innebar att det inte fanns ett lika stort behov av revisioner. Efter denna attack nämnde Josef att han och hans team såg en betydande ökning av revisionsbegäranden för Solana DApps och protokoll.

Efter allt detta kanske du tänker att om människor är källan till fel och skadliga avsikter, skulle det inte vara vettigt att bara ha datorer och maskiner med artificiell intelligens som är osannolikt att göra misstag och som inte är kapabla till skadliga avsikter, bara skriva all denna kod för oss?

Det är en bra fråga, och på grund av artiklar som den ovan, är detta något som jag också har tänkt på. Vi kommer att ta upp det i nästa avsnitt.

Framtiden för Blockchain Security

Det är uppenbart att vi går mot en framtid där många av våra jobb kommer att läggas ut på datorer och AI-program som kan göra människors jobb mycket bättre än vi kan.

Vi ser redan detta med automatiserade kassörskor och biltillverkningsfabriker som har fler robotar än människor. Datorer tar till och med över högt specialiserade jobb som läkare och farmaceuter, eftersom en robot kan vara mer exakt med en skalpell och ett datorprogram kan söka igenom hela databasen med medicin och inom några sekunder fylla i rapporter om vilka läkemedel som kan och inte kan blandas med andra kemikalier och mediciner, en uppgift omöjlig för en människa.

Jag trodde säkert att programmering och utveckling skulle vara ett av de första jobben som ersattes av datorer. Om det är alla bokstäver och siffror på en skärm som är konstruerade på ett sätt för att slutföra vissa uppgifter, då skulle väl en dator kunna göra det bättre än en människa, med färre fel eller hur?

Jag trodde att blockchain-revisionsföretag skulle gå Dodo-fågelns väg (utdöd), eftersom när datorer väl börjar utvecklas autonomt kommer det inte att finnas några fel att hitta. Detta belyste hur lite jag visste om att utveckla eftersom Ackee-teamet förklarade några koncept som jag inte hade uppskattat.

En stor del av blockchain-utvecklingen är problemlösning och att titta på en 360-graders bild av en fråga. Det krävs en stor mängd kreativitet och "utanför boxen"-tänkande som datorer inte kan göra. Det är inte bara så enkelt som "när 'X' händer, kör 'Y'."

Vi måste också tänka på att många av dessa DApps och applikationer försöker lösa "mänskliga" problem och hur vi interagerar med system, protokoll och procedurer. Förlåt lilla Butter Bot, men du är inte kapad att förstå mänskliga problem och tillhandahålla mänskliga lösningar.

Inte bara jobben inom blockkedjeutveckling och säkerhet skjuter i höjden, utan det ser ut som att det kommer att finnas ett behov av dessa roller under många år framöver.

Därmed inte sagt att det inte sker någon automatisering i web3-utvecklingsutrymmet. Det finns massor av gratisverktyg för utvecklare som ger dem viss säkerhetsfeedback och hjälper till att ladda ner en del av arbetet så att utvecklare kan fokusera på andra uppgifter.

Till exempel på Ethereum finns det en bra statisk kodanalysator som heter Slither det är väldigt populärt och Ackee Blockchain arbetar på sin egen statiska analysator med öppen källkod som heter vaknade, som upptäcker saker annorlunda än Slither, vilket minskar bördan av att behöva manuellt analysera koden.

Ackee-teamet upptäckte också en trend på Solana angående ett problem med tester. Utvecklare skrev inte tillräckligt mycket av dem eftersom det är ganska arbetsintensivt, med behovet av att skriva mycket kod. Så Ackee Blockchain ledde ett projekt där de skrev ett testramverk med öppen källkod för Solana som heter Trdelnik som gör det lättare för utvecklare att skriva tester. Laget fick ett hedersomnämnande och vann ett Marinadpris under a hackathon i Prag för Trdelnik.

Allt detta visar oss att det är troligt att automation och datorer kommer att spela en allt viktigare roll för att hjälpa blockchain-utvecklare och säkerhetsrevisorer, men det är osannolikt att de kommer att ersätta dem någon gång snart.

Den allmänna känslan bland blockchain-utvecklare är att många av dessa hacks och utnyttjar är ett resultat av att detta fortfarande är en ung och oerfaren bransch. När blockchain-industrin fortsätter att utvecklas och mogna borde det bli färre och färre utnyttjande, vilket resulterar i att det övergripande kryptoutrymmet blir säkrare och användarvänligare.

Okej, låt oss nu gå in på det som är bra, det viktigaste med den här artikeln.

Hur man verifierar att en plattform har granskats

Det allra första steget är att faktiskt se till att det finns en revision att hitta. Dessa kan hittas i projektets GitHub-förråd, och eventuella utförda revisioner bör tydligt nämnas i projektets dokument eller på själva plattformens webbplats. Om du inte kan hitta något omnämnande av en revision, skulle jag hålla mig borta.

Ingen offentligt tillgänglig revision betyder sannolikt att:

• Det har inte gjorts någon revision
• Det har skett en misslyckad revision som projektet inte vill bli känt
• Revisionen upptäckte problem som teamet inte tog upp
• Koden innehåller skadliga bakdörrsrutter som kan leda till stöld

Som nämnts tidigare är det också trevligt att se att koden är öppen källkod genom att den är märkt "public" på GitHub. Detta är inget krav, men det är ändå en bonus. Det finns dock skäl att inte använda öppen källkod, så det är inte alltid en deal breaker. Anledningar till att inte använda öppen källkod kan vara saker som:

• Företag som vill behålla en konkurrensfördel. Så fort ett företag öppnar sin kod kan vem som helst skapa samma protokoll och tävla. Det är därför Coca-Cola håller sitt recept hemligt och KFC har sina "Top Secret 11 örter och kryddor."
• När en kod är offentlig kan hackare använda informationen för att leta efter utnyttjande. Även om god praxis gör motsatsen, kommer de att publicera den om ett projekt är övertygat om sin kod.
• Tidiga projekt kanske inte vill öppna sin kod direkt förrän de har byggt upp en stor community och tillräckligt många användare, vilket skapar ett hinder för potentiella konkurrenter.

Jag träffade nyligen ett projektteam som ångrade att de öppnade sin plattform direkt, eftersom ett konkurrerande företag helt enkelt kopierade sin kod och affärsmodell och hade mer finansiering för att betala influencers och betala för följare. Detta gjorde att det visade sig att det konkurrerande företaget var den bättre plattformen redan från lanseringen eftersom det gav intryck av fler användare och ett större antal följare. Det konkurrerande företaget ligger nu betydligt före det ursprungliga grundarteamet som valde att växa mer organiskt och etiskt.

Här är en fantastisk bild från Bridge Global som sammanfattar några av de generella skillnaderna mellan programvara med öppen källkod och stängd källkod:

Två intressanta metoder för öppen vs stängd källkod kan hittas genom att jämföra populära hårdvaruplånböcker värde och Ledger. Trezor valde att publicera 100 % av sin källkod till allmänheten för vem som helst att verifiera, medan Ledger valde att spela sina kort närmare bröstet och öppnade lite kod, men behålla sin firmware stängd källkod.

Detta ledde till att många blockchain-elitister valde Trezor framför Ledger eftersom de ansåg att Ledger borde öppna källkod för sin kod och undrade vad de försöker dölja. Jag personligen ser inte detta som en anledning till oro eftersom Ledger har bevisat sin meritlista och hängivenhet till utrymmet, och har vuxit till att bli en av de största hårdvaruplånboksleverantörerna i världen, vilket skapar några av de högsta säkra kryptolagringarna. enheter.

När en revision väl har genomförts och lokaliserats, så länge den har offentliggjorts, kan vem som helst öppna dokumentet och hitta resultatet av revisionen. Istället för att bläddra igenom hela revisionsdokumentet, för vårt enkla syfte, är allt vi behöver leta efter sidan "Executive Summary", som ofta ser ut ungefär så här:

Den här sidan kommer antingen att finnas i början eller slutet av rapporten. Det är en sida som visar resultatet av granskningen i ett enkelt format som en vanlig människa kan förstå. Låt oss dyka in i vilken information det här visar oss.

Är granskningen nyligen? Revisioner bör vara en kontinuerlig tjänst och det bör definitivt göras en ny revision för VARJE uppdatering, version eller ny funktion/funktion som introduceras. Om det har lanserats en ny funktion eller version är de tidigare granskningsresultaten inte längre giltiga eftersom kodbasen troligen har ändrats.

Detta kan verifieras genom att titta på projektversionen och/eller commit hash. Versionen är ungefär som när du ser Ta bort "V2" (version 2), och commit-hash identifierar en revision i källkodsförrådet. När man tittar på versionen eller commit-hashen som visas i granskningen, som kan ses i bilden ovan i tabellen med rubriken "repository", kan användare kontrollera att den sammanfaller med versionen eller commit-hashen som visas i GitHub.

Det kommer att se ut ungefär så här:

Här är en annan titt från en av Ackee Blockchain Audits:

Men om commit-hash inte stämmer, betyder det inte nödvändigtvis att det finns en röd flagga. Bekräftelsehashen på projektets GitHub kommer att ändras varje gång en ny justering eller iteration görs. Varje justering kommer att ändra commit-hash och borde inte vara en anledning till oro om det bara var en mindre justering.

Om du inte ser commit-hash från revisionen på GitHub-huvudsidan, kan du gå in i "Commit History" och söka efter commit-hash och se själv hur mycket som har förändrats sedan revisionen genomfördes.

Det kan göras genom att klicka här:

Gör sedan en sökning här:

Eftersom en ny commit-hash fylls i för varje ändring, var och en med en datum- och tidsstämpel, om det har förekommit ett betydande antal nya commits mellan det att revisionen genomfördes och den commit-hash som projektet för närvarande pågår, kan du vill överväga att vänta tills ytterligare en revision har genomförts innan du engagerar dig.

Om du har ett analytiskt öga och vill dyka in djupare kan du klicka dig in i varje ny commit-hash och jämföra den gamla koden som visas i rött med den nya koden som visas i grönt och verifiera själv vad som har förändrats:

Om du märker en ny commit-hash som skiljer sig från när revisionen genomfördes och ser något i stil med detta:

Det är en av de obetydliga ändringarna jag nämnde, och även om den fyllde i en ny commit-hash är det inget att oroa sig för eftersom det här var ett enkelt byte av en fil. GitHub-bilden ovan visar 0 tillägg och 0 raderingar.

Nu till nästa sak att leta efter i sammanfattningen:

Problem – Sammanfattningen visar alla problem som upptäcktes under revisionen, och ännu viktigare, om teamet löste problemen. Det här avsnittet kan ses nära botten där det visar "Totala problem", sedan går till att dela upp dem i allvarlighetsgrad och om de löstes eller inte. Revisionsföretaget identifierar först problem, flaggar dem till utvecklarteamet och kontrollerar sedan koden igen när utvecklarna tar itu med problemen innan revisionsteamet kommer att markera problemet som "löst".

Det är klart att alla problem som är markerade som "Kritiska" eller "Högrisk" bör lösas. Även om rapporten visar att alla kritiska eller högriskproblem har lösts, bör detta ändå noteras med viss skepsis mot projektet. Om revisionsteamet hittade ett stort antal kritiska problem till att börja med, kan det markera att utvecklarteamet bakom projektet kan vara ganska nybörjare, vilket leder till ytterligare och ytterligare problem på vägen.

Medel- eller lågriskproblem är vanliga och normalt inte en anledning till oro. Revisionsteamet kan till och med markera något som ett lågriskproblem om de bara föreslår ett alternativ eller har en meningsskiljaktighet om hur man ska närma sig något.

Här är en sammanfattning av vad var och en av kategorierna betyder:

Kritisk – Allt som markeras som kritiskt betyder att något är exploateringsbart just nu.

Teamet på Ackee Blockchain berättade för mig en historia om en revision de genomförde där de hittade ett kritiskt problem på ett protokoll som redan hade lanserats. De väckte projektets Dev-team klockan 5 på morgonen i en nödsituation "alla händer på däck" för att reparera koden ASAP. Lyckligtvis fångade de problemet i tid innan hackare kunde identifiera sårbarheten.

Hög svårighetsgrad – Problem som inte går att exploatera nu, men som kan vara om vissa specifika sekvenser uppfylls.

Medium till Låg – Dessa är ofta mindre justeringar som behövs eller rekommendationer och inte nödvändigtvis säkerhetshot.

Olika revisionsföretag kommer också att skriva sammanfattningar i olika format. Sammanfattningen ovan har gjorts av revisionsbyrå Quantstamp. Ackee Blockchain tillhandahåller PDF:en med granskningen och en webbsammanfattning som kombinerar initiala och uppföljande resultat i mer av ett uppsatsformat som är lättare att läsa. Du kan hitta ett exempel på det i deras Revisionssammanfattning.

Ytterligare saker att leta efter:

• Har en revision genomförts av mer än ett företag? Ju fler ögon som letar efter problem, desto mindre är chansen att det finns ett fel i koden.
• Är blockchain-revisionsföretaget professionellt och respekterat i samhället? Om du aldrig har hört talas om revisionsföretaget tidigare, ta en titt på deras hemsida och leta efter andra projekt som de har arbetat med. Är någon av plattformarna de har granskat ansedda? Kontrollera om någon av plattformarna har utnyttjats efter att företaget utfört en revision, detta kan visa på en meritlista med dåliga revisionsfärdigheter. Leta efter saker som vunna hackathons och support/bidrag från lager 1-nätverksstiftelser.

Ett bra exempel på detta är Ackee Blockchain, som har tilldelats officiella utvecklings-/gemenskapsbidrag av fyra nyckelstiftelser: Coinbase Giving, Ethereum Foundation, Solana Foundation och Tezos Foundation.

Om du är någon som har blivit förståeligt otillförlitlig i denna tidsålder av desinformation, om du ser ett påstående som bilden ovan hämtad från Ackee Blockchain-webbplatsen, istället för att ta deras ord för det, kan du alltid navigera till stiftelsernas webbplatser nämnt och verifiera påståendena själv.

Anledningen till att jag säger detta är för att, under mina år av att skriva recensioner, antalet webbplatser som hävdar "Featured in Forbes eller Yahoo Finance", när de aldrig var, är överväldigande. Jag önskar att det fanns någon form av internetpolis som kunde dra företag till internetfängelse för att ljuga och vilseledande uttalanden som det. Det är därför det i krypto finns ett talesätt, "lita inte på, verifiera." Oroa dig inte, Ackee checkar ut och är faktiskt betrodd av ovanstående stiftelser, jag kollade 😉

Utgående Tankar

Tja, där har du det. Lite information om blockchain-säkerhet som jag hoppas att du tyckte var användbar. Jag hoppas att den här artikeln hjälper dig att känna dig mer säker på att ge dig ut i kryptovärlden med ytterligare ett lager rustning och att kunna navigera i kryptovattnen säkrare än tidigare. Jag vet att jag kommer att vara noggrann med att verifiera denna information nästa gång jag väljer vilka DApps och protokoll jag väljer att lita på med mina kryptotillgångar.

Som ordspråket säger, "inom krypto handlar det inte om hur mycket du tjänar, det handlar om hur mycket du behåller", eftersom många av oss gamla knapriga kryptoveteraner tyvärr har förlorat mer än vår beskärda del av Satoshis i en myriad av hacks, bedrägerier, ruggningar, konkurser etc. Ju mer kunskap vi har, desto bättre kan vi skydda oss från många av de svåra risker som finns i denna nya och spirande galna kryptovärld.

Ansvarsfriskrivning: Detta är författarens åsikter och bör inte betraktas som investeringsråd. Läsarna bör göra sin egen forskning.