Blockchain-biztonság: Hogyan lehet megérteni a blokklánc-auditokat, hogy biztonságban maradhasson a DeFi-ben

Az elmúlt év meglehetősen sötét időszak volt a kriptográfia terén. Nemcsak a Luna katasztrofális összeomlását, a 3 Arrows Capital elfajulását, a fizetésképtelenségi és csődgondokat a BlockFi-vel, a Celsius-szal, a Voyager-rel, a VAULD-dal és még sok mással láttuk, makrogazdasági körülményeket, amelyek a kriptotél mélyére sodortak bennünket, hanem Monumentálisan katasztrofális év volt a blokklánc és a DeFi feltörése és kihasználása terén is, ami azt eredményezte, hogy az emberek gyorsabban menekültek el a DeFi elől, mint az úszók a cápákkal fertőzött vizekből.

Most valószínűleg azt gondolod magadban, „Wow, köszönöm a lehangoló bevezetőt. A kripto úgy hangzik, mint egy aknamező!”

És ebben nem tévedsz, a kriptográfia minden bizonnyal megvan a maga része a kockázatoknak. De mielőtt hagyná, hogy ez a végzet és borongás arra késztessen, hogy örökre elhagyja a kriptográfiai eszközöket, és bebújjon az ágya alá, ne féljen, mert ez a cikk segít megtanítani Önnek, hogyan navigáljon a DeFi vizein a lehető legbiztonságosabb módon, és megmutatja, mit akar. tudnia kell a blokklánc biztonsági auditokról.

Bár ez nem segít megvédeni a kriptoval kapcsolatos minden kockázat ellen, nem véd meg valakit, aki úgy dönt, hogy a megmentett összegét a következő memecoinba „YOLO” adja, az ebben a cikkben található információk legalább segítenek felszerelni még egy nyíllal a tegezben. amelyeket bevetve nagymértékben javíthatja a DeFi tér általános biztonságos navigációját.

A félelmek korai eloszlatása érdekében ne aggódjon amiatt, hogy ez a cikk túl technikai jellegű. Ez a hasznos útmutató olyan könnyen érthető lesz, hogy még az apám is meg fogja érteni, aki az egész kriptoipart „az a bitcoin-cucc”-ként emlegeti.

És mivel nagyjából olyan jártas vagyok a blokklánc fejlesztésében, mint a kő a hajvágásban, úgy döntöttem, hogy szakmai segítséget és bennfentes tanácsot kérek ehhez a cikkhez. Megkerestem a barátainkat a címen Ackee Blockchain hogy segítsek megtanulni magam és az átlagos Joe, hogy mi a fenéről szólnak ezek a blokklánc auditok.

Szeretnék megköszönni az Ackee csapatának, hogy időt szakítottak arra, hogy segítsenek nekünk és közösségünknek azáltal, hogy megtanítottak nekünk a blokklánc auditálás alapjait, és hogy együttműködtek velünk ezen a cikken. A blokklánc és a DeFi audit jelentései a kriptográfia kritikus fontosságú aspektusai, és nagyon kevesen értjük igazán.

Amikor kellő gondossággal határozzuk meg a DApp vagy a DeFi protokollok biztonságát, sokan keresünk valamit, ami azt mondja, hogy a platformot ellenőrizték, és azt gondolhatja, hogy „oké, elég jó”. Tudom, hogy a múltban bűnös voltam ebben, de mit jelent valójában az, hogy auditáltak? Hogyan tudjuk ezt ellenőrizni? És ahogy ebből a cikkből megtudhatja, csak azért, mert valamit auditáltak, ez nem jelenti azt, hogy automatikusan zöld utat kell kapnia.

Kezdésként nézzük meg, mit csinálnak valójában a blokklánc-auditáló cégek.

Mit csinálnak a blokklánc-auditáló cégek?

Amikor meghalljuk az „ellenőrzés” kifejezést, sokan automatikusan elképzelünk egy, a kormánynak dolgozó, öltönyös, tömött öreg csávót, aki kopogtat, és finom fogú fésűvel végignézi az összes pénzügyi és bankszámlakivonatunkat. A hagyományos pénzügyi ágazatban igaza van, de a blokklánc-auditorok nem állhatnának távolabb ettől.

A blokklánc-auditorok képzeletüket tekintve nem könyvelők, a kódolás és a fejlesztői készségek szakértői, akik hibákat, hibákat és rosszindulatú kódokat keresnek egy blokklánc projekt, intelligens szerződés vagy kriptotoken forráskódjában.

A különböző könyvvizsgáló cégek is különböző területekre szakosodhatnak, ezért mindig jó látni egy olyan platformot, amelyet több cég is auditált. Minden elvégzett audit csökkenti a kockázatot, és az egyik vállalat észrevesz valamit, amit a másik cég elmulasztott.

1inch remek példa erre. Az 1inch egy DEX aggregátor, amelyet több különböző cég is auditált, ami növeli a felhasználók platform iránti bizalmát, és rávilágít arra, hogy az 1 hüvelykes csapat határozottan elkötelezett közössége biztonsága mellett.

A blokklánc könyvvizsgáló cégeknek van egy mérnökcsapata, amely olyan feladatokat tud végezni, mint:

• Security Audit
• Eszközelemzés
• Kézi kód áttekintése
• Futtasson és írjon automatikus teszteket
• Vigyázz Bug Bounty Versenyekre

Míg más könyvvizsgáló cégek, mint például az Ackee Blockchain, több „teljes körű szolgáltatási” követelménynek is megfelelhetnek, és további területeken is segítséget nyújthatnak, például:

• Biztonságos intelligens szerződések létrehozása szilárdságra vagy rozsdára vonatkozóan
• Segítség a teljes ökoszisztéma felépítésében, az UX kezelésében, a tervezésben, a frontendekben, a háttérben és a DevOps-ban

Az Ackee Blockchain a blokklánc-ipar egészéhez is hozzájárul, amit nagyszerű látni. Nyílt forráskódú biztonsági eszközöket fejlesztettek ki, amelyeket bárki használhat, és szenvedélyesen oktatják és lehetőséget biztosítanak a blokklánc-fejlesztőknek. Korábban online kurzusokat tartottak azoknak a fejlesztőknek, akik blokkláncban szeretnének dolgozni, és még a Solana Alapítványtól is támogatást kaptak nyári iskola Solana számára.

A csapat online nyári iskolákat kínál, ahol a Solidity-t tanítják, 2022 őszén pedig Josef Gattermayer, az Ackee Blockchain vezérigazgatója és társalapítója, Ph.D. blokklánc fejlesztéssel kapcsolatos témákat tanít majd a Cseh Műszaki Egyetem, Prága. Mindenképpen érdemes az Ackee csapatához fordulni, regisztráció a tanfolyamokra az oldalukon, és kövesse őket, ha érdekli a blokklánc fejlesztés és biztonság jövője.

Amint látja, a blokklánc-audit többről is szólhat, mint egy sötét szobában való bóklászás és a kód átvizsgálása, hanem egy egész ökoszisztéma van a résen belül.

Miért fontos a blokklánc auditálás?

Ha az emberek tökéletesek lennének, nem lenne szükség blokklánc-auditáló cégekre, mivel minden kódsor hibátlanul és teljesen áthatolhatatlan lenne a kizsákmányolásokkal, hibákkal és támadásokkal szemben.

Ami még annál is rosszabb, mint amikor az emberek hibáznak, az az, hogy az emberek korruptak és rosszindulatúak lehetnek. Meglehetősen gyakori jelenség, hogy a rossz szereplők szándékosan rosszindulatú kódot írnak be a protokolljukba, amely lehetővé teszi számukra, hogy kihasználják az általuk létrehozott platformot a felhasználók pénzének ellopása érdekében.

Az emberi hiba és a rosszindulatú szándékok között az intelligens szerződések és a blokklánc-alkalmazások/DApp-ok a következő kockázatoknak vannak kitéve:

• Szolgáltatásmegtagadási támadások, amelyek használhatatlanná teszik a protokollt.
• Szőnyeghúzás/hátsó ajtólopás, ahol az alapítók rosszindulatú kódot írnak be, amely lehetővé teszi számukra, hogy kivegyék az intelligens szerződésben elhelyezett pénzeszközöket.
• A kód olyan módon történő kihasználása, amely a hacker számára előnyös és a felhasználóknak kárt okoz, például új tokenek verése a tervezett módszereken kívül, vagy az ügyfelek pénzének elszívása az intelligens szerződésekből.
• Egyes hackerek egyszerűen csak „nézni akarják, ahogy ég a világ”, és minden talált hibát kihasználva kárt tesz egy platformon.

Sok DeFi-felhasználó szerint az egyik legfontosabb dolog, amit a DeFi platformon keresni kell, az, hogy a kód nyílt forráskódú-e vagy sem. Ez egy nagyszerű első lépés, mivel sok projekt közzéteszi a kódot egy nyilvános webhelyen, például a Githubon, ahol bárki bemehet és saját maga ellenőrizheti/ellenőrizheti a kódot.

Amikor egy projekt GitHub oldalát nézzük, gyakran ez az egyik dolog, amit a DApp használatát fontolgató felhasználók keresik, példaként ismét az 1 hüvelykes méretre:

Ez egy jó kezdeti megközelítés a protokoll hitelességének ellenőrzéséhez, mivel itt a közösség tagjai vagy bárki bemehet és ellenőrizheti, hogy nincs-e benne rosszindulatú kód.

Az is hasznos tudni, hogy bárki bármit közzétehet a GitHubon. A GitHubban közzétett kód nem erősíti meg automatikusan, hogy ez ugyanaz a kód, amely az intelligens szerződést futtatja. Szerencsére a felhasználók ezt úgy ellenőrizhetik, hogy belépnek egy blokkböngészőbe, például az Etherscanbe, és ellenőrzik, hogy a GitHubban lévő kód valóban telepítve van-e és használatban van-e. Itt van 1 hüvelykes token Etherscanben, például. Hajlamos vagyok egyetérteni azzal az érzéssel, hogy a nyílt forráskódú közzététel a GitHubon jó jel, de számomra, amikor rákattintok a GitHubra, hogy megnézzem, csak a következőket látom:

Tehát ahelyett, hogy az agyam tojásként sülne a forró járdán, hogy kitaláljam ezt, szeretem látni, hogy egy blokklánc-auditáló cég szakemberei átkutatták mindezt, és felfelé mutatták a hüvelykujját.

Fontos tisztázni egy dolgot, mégpedig azt, hogy pusztán azért, mert egy protokollt auditáltak, az nem jelenti azt, hogy 100%-ban biztonságos. Egyetlen kód sem tekinthető teljesen áthatolhatatlannak a feltörési kísérletekkel szemben, mivel a hackerek eszközei és képességei egyre kifinomultabbak. Ahogy a fehér kalapos (jó) hackerek és a blokklánc-fejlesztők egyre jobbak és fejlődnek, úgy a rosszfiúk is.

Úgy képzelheted el, mint egy macska-egér játékot, a kódírás lényegében olyan, mint egy kreatív rejtvény felépítése és problémamegoldás, és a hackerek egyre okosabb és kifinomultabb módszerekkel keresik a rejtvény megoldásának vagy megtámadásának módjait. mindig kockázati elem marad.

Miért volt 2022 különösen rossz a kriptográfiai kihasználások számára?

Amikor ilyen címeket látunk:

Elég szívszorító tud lenni. A kriptoipar komoly fekete szemet kapott, mivel úgy tűnik, hogy minden héten egy újabb hatalmas feltörés vagy kizsákmányolás történik, ami milliós pénzeszközök elvesztését eredményezi.

Ez nem csak azért szomorú, mert átlagos emberek veszítik el a pénzüket, hanem aggasztó is, mivel ezek a támadások az egész kriptoipart egyre keményebb kritikáknak vetik alá, lelassítják az elfogadást, távol tartják a befektetőket, és olyan kifogásokkal látják el a kormányokat, amelyekre szükségük van tekintélyük növelésére. ellenőrzést a befektetők „védelmére”, gyakran drákói intézkedéseket hozva, amelyeket sokan a kriptográfia felé fordultak, hogy elkerüljék.

Ennek elsődleges oka a hanyag fejlesztői tervezés.

Amikor leültem Joseffel Ackee-ből, megkérdeztem a véleményét arról, hogy miért történt rekordszámú visszaélés, magyarázata logikus volt.

Erősen átfogalmazva Josef tovább magyarázta nekem, hogy a kriptoipar gyorsan növekszik, és heves verseny folyik a csapatokért termékeik piacra dobásáért. Hiányoznak a képzett és tapasztalt blokklánc-fejlesztők, akik képesek kielégíteni a keresletet, ezért sok projektben kezdő fejlesztőket vesznek fel, és „elég jó” hozzáállással indítják el a DApp-okat a megfelelő ellenőrzések és auditok elvégzése nélkül.

Josef azt is kifejtette, hogy a blokklánc auditálási szolgáltatások iránti igény az egekbe szökik, és nincs elég blokklánc auditáló cég a projektek keresletének kielégítésére. Ez azt eredményezte, hogy a projektcsapatok nem akartak megvárni, amíg egy auditáló csapat elérhetővé válik, ezért továbblépnek, és elindítanak vagy kiadnak egy frissítést, akár audit nélkül, akár egy elavult auditra hagyatkozva, amely nem terjed ki egy platform új verziója vagy iterációja.

Ez a téma különösen a 2021-es bikafuttatás során volt jelen, de a dolgok sokkal lazábbak most, hogy egy medvepiacon vagyunk. A projektek nem kapnak nagy rohanást az indulással, és kevesebb projekt van az ellenőrzési szűk keresztmetszetben. Való igaz, hogy a medvepiacon az építkezés ideje van, és a csapatok hajlamosak szorgalmasabb megközelítést alkalmazni a lassabb piaci időkben.

Áttekintettünk két konkrét sikeres támadást, hogy kivizsgáljuk, mi is történt pontosan, hogy mindezt perspektívába helyezzük.

A 2016-os Ethereum DAO Hack

Lényegében, ami itt történt, az újrabelépési hibaként ismert. Egyszerűen fogalmazva, a kód két utasítást hajt végre:

1. Kifizetés
2. Frissítse az egyenleget

Ha időrendben hajtjuk végre, úgy működik, ahogy kell. De mivel az Ethereum egy elosztott rendszer (ellentétben a web2-es programokkal), a szerződés egy másik szerződésből is lehívható, amely lehetőséget kínál egy egyéni visszahívási funkció megvalósítására, amelyet a visszavonási utasításból hívnak meg.

És ez a hacker által megvalósított visszahívási funkció többször is lehívja a szerződést, mielőtt az egyenlegfrissítési utasítás végre végrehajtódik. Ez lehetővé teszi a támadó számára, hogy többször visszavonuljon.

Ez egy gyakori hiba, amelyet a kezdő web3 fejlesztők követnek el. Még 5 évvel a támadás után is felmerül a probléma, hogy a fejlesztők nem fordítanak időt arra, hogy tanuljanak ebből az esetből. A megoldás ebben az esetben meglehetősen egyszerű, és ez az, hogy ezt a két kódsort az ellenkező sorrendbe helyezzük. Először frissítés, majd visszavonás.

Az auditorok az ehhez hasonló ismert problémákat keresik a protokollok auditálásakor.

Solana Wormhole Attack 2022

A 2022-es év nem indult jól, február elején az első jelentős támadás Solana ellen történt. A támadó megkerülte az aláírás-ellenőrzést egy Rust programban, így úgy tűnt, hogy a gyámok aláírtak egy 120 XNUMX ETH letétet a solanai Wormhole-ba, pedig nem tették meg. A támadó ezután verte 120 ezer értékű becsomagolt ETH a Solanán.

A féreglyuk támadás előtt sokan a kriptográfiai közösségben azt feltételezték, hogy a Solana és a Rust fejlesztését túl nehéz megtanulni, hogy vonzzák az amatőr fejlesztőket. Ez arra a meggyőződésre vezetett, hogy csak a legjobb fejlesztők dolgoztak a Solanán, ami azt jelenti, hogy nincs olyan nagy szükség az auditokra. A támadás után Josef megemlítette, hogy ő és csapata jelentős növekedést tapasztalt a Solana DApps és protokollok ellenőrzési kérelmeiben.

Mindezek után arra gondolhat, hogy ha az emberek a hibák és a káros szándékok forrásai, nem lenne értelme egyszerűen csak számítógépeket és mesterséges intelligencia gépeket írni, amelyek valószínűleg nem követnek el hibákat, és nem képesek rosszindulatú szándékra. nekünk?

Ez egy nagyszerű kérdés, és a fentihez hasonló cikkek miatt ez is megfordult a fejemben. A következő részben ezzel foglalkozunk.

A blokklánc biztonság jövője

Nyilvánvaló, hogy egy olyan jövő felé haladunk, ahol sok munkánkat olyan számítógépekre és mesterséges intelligencia programokra bízzák, amelyek sokkal jobban képesek ellátni az emberek munkáját, mint mi.

Ezt már látjuk az automatizált pénztárosoknál és az autógyártó gyárakban, amelyekben több robot van, mint ember. A számítógépek még az olyan speciális munkákat is átveszik, mint az orvosok és a gyógyszerészek, mivel egy robot pontosabb lehet egy szikével, egy számítógépes program pedig át tudja vizsgálni a teljes gyógyszeradatbázist, és másodperceken belül jelentéseket készít arról, hogy milyen gyógyszerek keverhetők és melyek nem keverhetők más vegyi anyagokkal. gyógyszerek, egy ember számára lehetetlen feladat.

Biztos voltam benne, hogy a programozás és fejlesztés lesz az egyik első olyan munka, amelyet a számítógépek váltanak fel. Ha a képernyőn minden betű és szám úgy van megszerkesztve, hogy bizonyos feladatokat elvégezzen, akkor egy számítógép biztosan jobban meg tudná csinálni, mint egy ember, kevesebb hibával, igaz?

Azt hittem, hogy a blokklánc-auditáló cégek a Dodo-madár (kihalt) útját járják majd, mivel amint a számítógépek önállóan kezdenek fejlődni, nem fognak hibát találni. Ez rávilágított arra, hogy milyen keveset tudtam a fejlesztésről, mivel az Ackee csapata elmagyarázott néhány olyan koncepciót, amelyeket nem értékeltem.

A blokklánc fejlesztésének nagy része a problémamegoldás és a probléma 360 fokos nézetének vizsgálata. Nagy mennyiségű kreativitásra és „dobozon kívüli” gondolkodásra van szükség, amire a számítógépek nem képesek. Ez nem olyan egyszerű, mint „amikor az „X” megtörténik, hajtsa végre az „Y”-t.

Azt is figyelembe kell vennünk, hogy sok ilyen DApp és alkalmazás megpróbálja megoldani az „emberi” problémákat, és azt, hogy miként kommunikálunk rendszerekkel, protokollokkal és eljárásokkal. Bocsánat a kis Butter Bot, de nem vagy hajlandó megérteni az emberi problémákat és emberi megoldásokat kínálni.

Nemcsak a blokklánc-fejlesztéssel és a biztonsággal kapcsolatos állások szaporodnak, de úgy tűnik, hogy ezekre a szerepekre még évekig szükség lesz.

Ez azonban nem jelenti azt, hogy a web3 fejlesztési térben nem történik automatizálás. Rengeteg ingyenes eszköz áll rendelkezésre a fejlesztők számára, amelyek biztonsági visszajelzést adnak számukra, és segítenek a munka egy részének tehermentesítésében, hogy a fejlesztők más feladatokra összpontosíthassanak.

Például az Ethereumon van egy jó nevű statikus kódelemző Csúszik ami nagyon népszerű, és az Ackee Blockchain saját, nyílt forráskódú statikus elemzőjén dolgozik Felébredt, amely másként érzékeli a dolgokat, mint a Slither, csökkentve a kód manuális elemzésének terhét.

Az Ackee csapata egy trendet is feltárt Solana-n a tesztekkel kapcsolatos probléma kapcsán. A fejlesztők nem írtak eleget belőlük, mivel meglehetősen munkaigényes, és sok feldolgozási kódot kell írni. Tehát Ackee Blockchain egy projekt élén állt, ahol megírtak egy nyílt forráskódú tesztelési keretrendszert Solana számára. Trdelnik így a fejlesztők könnyebben írhatnak teszteket. A csapat megtisztelő elismerésben részesült és Marinade díjat nyert a hackathon Prágában Trdelnikért.

Mindez azt mutatja, hogy valószínűleg az automatizálás és a számítógépek egyre fontosabb szerepet fognak játszani a blokklánc-fejlesztők és biztonsági auditorok segítésében, de nem valószínű, hogy egyhamar felváltják őket.

A blokklánc-fejlesztők körében az az általános vélemény, hogy sok ilyen feltörés és kihasználás annak a következménye, hogy ez még mindig fiatal és tapasztalatlan iparág. Ahogy a blokklánc-ipar folyamatosan fejlődik és érik, egyre kevesebb kizsákmányolásra van szükség, aminek eredményeként a teljes kriptográfiai terület biztonságosabbá és felhasználóbarátabbá válik.

Rendben, most térjünk rá a jó dolgokra, a cikk főbb részletére.

Hogyan ellenőrizhető, hogy a platformot auditálták

A legelső lépés az, hogy ténylegesen megbizonyosodjon arról, hogy van-e ellenőrzés. Ezek megtalálhatók a projekt GitHub adattárában, és minden elvégzett auditot egyértelműen meg kell említeni a projekt dokumentumaiban vagy magán a platform webhelyén. Ha nem talál említést egy auditról, akkor távol maradok.

A nyilvánosan elérhető audit valószínűleg azt jelenti, hogy:

• Ellenőrzés nem történt
• Volt egy sikertelen audit, amelyről a projektet nem akarják tudni
• Az ellenőrzés olyan problémákat tárt fel, amelyekre a csoport nem tért ki
• A kód rosszindulatú backdoor útvonalakat tartalmaz, amelyek lopáshoz vezethetnek

Ahogy korábban említettük, azt is jó látni, hogy a kód nyílt forráskódú, mivel a GitHubon „nyilvános” címkével látták el. Ez nem követelmény, de még mindig bónusz. Ennek ellenére vannak okai annak, hogy ne használjunk nyílt forráskódot, így ez nem mindig akadályozza meg az üzletet. A nyílt forráskódú kód elutasításának okai a következők lehetnek:

• Versenyelőnyt megőrizni kívánó cégek. Amint egy vállalat megnyitja a kódját, bárki létrehozhatja ugyanazt a protokollt, és versenyezhet. Ez az oka annak, hogy a Coca-Cola titokban tartja a receptjét, a KFC-nek pedig híres a „11 szigorúan titkos gyógynövénye és fűszere”.
• Amint egy kód nyilvános, a hackerek felhasználhatják az információt kihasználások keresésére. Bár a jó gyakorlat ennek az ellenkezőjét teszi, ha egy projekt biztos a kódjában, közzéteszik azt.
• Előfordulhat, hogy a korai projektek nem akarják azonnal megnyitni a kódjukat, amíg nem építettek fel egy nagy közösséget és elegendő felhasználót, ami akadályt jelent a potenciális versenytársak számára.

Nemrég találkoztam egy projektcsapattal, akik azonnal megbánták, hogy nyílt forrásból vásárolták fel a platformjukat, mivel egy versengő cég egyszerűen lemásolta a kódjukat és az üzleti modelljüket, és több pénze volt az influencereknek és a követőknek való fizetésre. Ez azt a látszatot keltette, hogy a konkurens cég volt a jobb platform az indulástól kezdve, mivel több felhasználó és nagyobb követő benyomását keltette. A konkurens vállalat most jelentősen megelőzi az eredeti alapító csapatot, amely az organikusabb és etikusabb növekedést választotta.

Íme egy nagyszerű kép innen Bridge Global amely összefoglal néhány általános különbséget a nyílt forráskódú és a zárt forráskódú szoftverek között:

A nyílt és a zárt forráskód két érdekes megközelítése megtalálható a népszerű hardvertárcák összehasonlításával Trezor és a Főkönyv. A Trezor úgy döntött, hogy forráskódjának 100%-át nyilvánosságra hozza, hogy bárki ellenőrizhesse, míg a Ledger úgy döntött, hogy közelebb játssza ki a kártyáit, és nyílt forráskódú kódot, de a firmware zárt forráskódját megtartja.

Ez oda vezetett, hogy sok blokklánc-elitista a Trezort választotta a Ledger helyett, mivel úgy érezte, hogy a Ledgernek meg kellene nyitnia a kódját, vajon mit akarnak elrejteni. Én személy szerint nem tartom aggodalomra ad okot, mivel a Ledger bebizonyította múltját és elkötelezettségét a tér iránt, és a világ egyik legnagyobb hardvertárca-szolgáltatójává nőtte ki magát, létrehozva a legmagasabb szintű biztonságos kriptotárolók egyikét. eszközöket.

Az ellenőrzés lefolytatása és helye, mindaddig, amíg azt nyilvánosságra hozták, bárki megnyithatja a dokumentumot, és megtekintheti az ellenőrzés eredményeit. A teljes ellenőrzési dokumentum átgörgetése helyett, egyszerű célunk érdekében, csak a „Vezetői összefoglaló” oldalt kell keresnünk, amely gyakran valahogy így néz ki:

Ez az oldal a jelentés legelején vagy végén található. Ez egy olyan oldal, amely egyszerű, az átlagember számára is érthető formátumban mutatja be az audit eredményeit. Nézzük meg, milyen információkat mutat ez nekünk.

Friss volt az ellenőrzés? Az auditálásnak folyamatos szolgáltatásnak kell lennie, és mindenképpen MINDEN frissítésre, verzióra vagy új funkcióra/funkcióra vonatkozóan új auditot kell végezni. Ha új funkciót vagy verziót indítottak el, a korábbi ellenőrzési eredmények már nem érvényesek, mivel a kódbázis valószínűleg megváltozott.

Ezt a projekt verziójának megtekintésével és/vagy a hash véglegesítésével ellenőrizheti. A verzió olyan, mint amikor látod Cserélje le „V2” (2-es verzió), és a véglegesítési hash egy változatot azonosít a forráskód-tárházban. Ha megnézi az auditban látható verziót vagy véglegesítési hash-t, amely a fenti képen látható a táblázatban a „tárhely” címmel, a felhasználók ellenőrizhetik, hogy az egybeesik-e a GitHubon látható verzióval vagy véglegesítési hash-sel.

Ez valahogy így fog kinézni:

Íme egy másik pillantás az egyik Ackee Blockchain Auditból:

Bár ha a commit hash nem egyezik, az nem feltétlenül jelenti azt, hogy van piros zászló. A véglegesítési hash a projekt GitHubon minden új módosítás vagy iteráció alkalmával megváltozik. Minden módosítás megváltoztatja a véglegesítési hash-t, és nem lehet aggodalomra okot adó, ha csak kisebb módosítás történt.

Ha nem látja a véglegesítési hash-t az auditból a GitHub főoldalán, lépjen be a „Commit History”-ba, és keresse meg a véglegesítési kivonatot, és saját szemével nézze meg, mennyit változott az audit elvégzése óta.

Ezt ide kattintva teheti meg:

Akkor keress itt:

Mivel minden változtatáshoz új véglegesítési hash kerül feltöltésre, mindegyik dátummal és időbélyegzővel, ha jelentős számú új véglegesítés történt az audit lefolytatása és a projekt jelenleg futó véglegesítési kivonat között, megfontolandó, hogy megvárja az újabb audit elvégzését, mielőtt belevágna.

Ha van analitikus szemed, és szeretnél mélyebbre merülni, kattints minden új véglegesítési hash-re, és összehasonlíthatod a pirossal jelölt régi kódot a zöld színnel jelzett új kóddal, és ellenőrizheted, hogy pontosan mi változott:

Ha olyan új véglegesítési hash-t észlel, amely eltér az audit lefolytatásának időpontjától, és valami ehhez hasonlót lát:

Ez egyike azoknak a jelentéktelen változtatásoknak, amelyeket említettem, és bár új véglegesítési hash-t töltött be, nem kell aggódni, mivel ez egy fájl egyszerű átnevezése volt. A fenti GitHub-kép 0 hozzáadást és 0 törlést mutat.

Most pedig térjünk rá a következő dologra, amit a Vezetői összefoglalóban érdemes keresni:

Problémák - A vezetői összefoglalóban az ellenőrzés során feltárt összes probléma látható, és ami még fontosabb, hogy a csapat megoldotta-e a problémákat. Ez a szakasz az alján látható, ahol az „Összes problémák” látható, majd a súlyosság szerint bontja le őket, és azt, hogy megoldották-e vagy sem. Az auditáló cég először azonosítja a problémákat, megjelöli azokat a fejlesztői csapatnak, majd ismét ellenőrzi a kódot, amint a fejlesztők megoldják a problémákat, mielőtt az auditáló csapat „megoldottként” jelölné meg a problémát.

Nyilvánvaló, hogy minden olyan problémát, amely „kritikus” vagy „nagy kockázatú” megjelöléssel van ellátva, meg kell oldani. Még ha a jelentés azt mutatja is, hogy az összes kritikus vagy nagy kockázatot jelentő problémát megoldották, ezt akkor is szkepticizmussal kell tudomásul venni a projekttel kapcsolatban. Ha az auditáló csapat kezdetben sok kritikus problémát talált, az rávilágíthat arra, hogy a projekt mögött álló fejlesztői csapat meglehetősen kezdő lehet, ami további és további problémákhoz vezethet az úton.

A közepes vagy alacsony kockázatú problémák gyakoriak, és általában nem adnak okot aggodalomra. Az auditáló csoport akár alacsony kockázatú problémaként is megjelölhet valamit, ha egyszerűen alternatívát javasol, vagy véleménykülönbségük van azzal kapcsolatban, hogy hogyan kell megközelíteni valamit.

Íme egy összefoglaló az egyes kategóriák jelentéséről:

Kritikai – Bármi, ami kritikusnak van megjelölve, azt jelenti, hogy valami jelenleg kihasználható.

Az Ackee Blockchain csapata elmesélt egy történetet egy általuk végzett auditról, ahol kritikus hibát találtak egy már elindított protokollon. Hajnali 5 órakor felébresztették a projekt fejlesztői csapatát „minden kéz a fedélzeten” vészhelyzetben, hogy mielőbb megjavítsák a kódot. Szerencsére időben észlelték a problémát, mielőtt a hackerek azonosítani tudták volna a sebezhetőséget.

Nagy súlyosságú – Olyan problémák, amelyek jelenleg nem kihasználhatók, de bizonyos szekvenciák teljesülése esetén igen.

Közepestől alacsonyig – Ezek gyakran kisebb módosítások vagy ajánlások, amelyek nem feltétlenül biztonsági fenyegetések.

A különböző könyvvizsgáló cégek különböző formátumban is készítenek vezetői összefoglalókat. A fenti összefoglalót könyvvizsgáló cég készítette Quantstamp. Az Ackee Blockchain biztosítja a PDF-fájlt az audittal és egy internetes összefoglalóval, amely egyesíti a kezdeti és a nyomon követési eredményeket egy sokkal könnyebben olvasható esszéformátumban. Példát találhat náluk Ellenőrzési összefoglaló.

További keresendő dolgok:

• Egynél több cégnél végzett könyvvizsgálat? Minél több szem keresi a problémákat, annál kisebb az esélye annak, hogy a kódban hiba található.
• A blokklánc könyvvizsgáló cég professzionális és elismert a közösségben? Ha még soha nem hallott a könyvvizsgáló cégről, tekintse meg weboldalukat, és keressen más projekteket, amelyeken dolgoztak. Az általuk auditált platformok valamelyike ​​jó hírű? Ellenőrizze, hogy valamelyik platformot kihasználták-e, miután a vállalat auditot végzett, mert ez rávilágíthat a gyenge auditálási készségekre. Keressen olyan dolgokat, mint a megnyert hackathonok és az 1. réteg hálózati alapjaitól származó támogatás/támogatás.

Jó példa erre az Ackee Blockchain, amelyhez négy kulcsfontosságú alapítvány kapott hivatalos fejlesztési/közösségi támogatást: a Coinbase Giving, az Ethereum Alapítvány, a Solana Alapítvány és a Tezos Alapítvány.

Ha Ön érthetően bizalmatlanná vált ebben a félretájékoztatási korszakban, ha olyan állítást lát, mint amilyen a fenti kép az Ackee Blockchain webhelyéről készült, akkor ahelyett, hogy szót fogadna, mindig az alapítványok weboldalaira navigálhat. megemlítette, és ellenőrizze saját maga az állításokat.

Azért mondom ezt, mert az én több éves értékelésem során elsöprő azoknak a webhelyeknek a száma, amelyek azt állítják, hogy „Kiemelt a Forbes-ban vagy a Yahoo Finance-ben”, amikor még soha nem voltak. Bárcsak létezne valamiféle internetes rendőrség, amely internetes börtönbe hurcolná a cégeket az ehhez hasonló hazug és félrevezető kijelentések miatt. Ezért van a kripto-ban egy mondás: "ne bízz, ellenőrizd." Ne aggódj, Ackee kijelentkezik, és a fenti alapítványok valóban megbíznak benne, megnéztem 😉

Záró gondolatok

Nos, megvan. Néhány információ a blokklánc biztonságáról, amelyeket remélem hasznosnak találtál. Remélem, ez a cikk segít abban, hogy magabiztosabban merészkedjen a kriptográfia világába egy újabb páncélréteggel, és biztonságosabban tudjon navigálni a kriptovizeken, mint korábban. Tudom, hogy szorgalmasan ellenőrizni fogom ezeket az információkat, amikor legközelebb kiválasztom, hogy mely DApp-eket és protokollokat bízom meg kriptoeszközeimnél.

Ahogy a mondás tartja: „a kriptográfia területén nem az a lényeg, hogy mennyit keresel, hanem az, hogy mennyit tartasz meg”, mivel sajnos sokan közülünk, régi kérges kripto-veteránok többet veszítettek, mint amennyit méltányos részenket Satoshis-ból szereztünk, számtalan feltörés során. csalások, szőnyeglehúzások, csődök stb. Minél több tudással rendelkezünk, annál jobban meg tudjuk védeni magunkat a kriptotechnológiának ebben az új és bimbózó szokatlan világában fennálló számos kemény kockázat ellen.

Jogi nyilatkozat: Ezek az író véleményei, és nem tekinthetők befektetési tanácsnak. Az olvasóknak maguknak kell kutatniuk.