- Miért nem elég, ha egy protokoll „auditált”?
- Mit vizsgál egy smart contract audit valójában?
- A három nagy sérülékenységtípus
- Folyamatos monitoring — az audit utáni világ
- A bug bounty programok szerepe
- Likviditási kockázat: a kevésbé emlegetett veszély
- TVL mint félrevezető mutató
- Governance-kockázat: a backdoor, amit sokan nem látnak
- Mire figyelj governance szempontból?
- Hogyan értékeld egy protokoll biztonsági szintjét?
- A biztosítás mint utolsó védelmi vonal
- Összefoglalás
Miért nem elég, ha egy protokoll „auditált”?
Az auditált jelző mára szinte marketingeszközzé vált a DeFi-szektorban. Szinte minden protokoll büszkén hirdeti a weboldalán, hogy „audited by” — és ez sokakban hamis biztonságérzetet kelt. A valóság ennél jóval árnyaltabb: egy audit pillanatfelvétel, nem folyamatos védőháló.
A legnagyobb DeFi-hackek döntő többsége auditált protokollokat érintett. A Ronin Bridge esetén 625 millió dollár tűnt el 2022-ben — a kód átment az ellenőrzésen, a probléma mégis ott lapult. Az Euler Finance 197 milliós vesztesége 2023 márciusában szintén ezt a mintát követte.
Mit vizsgál egy smart contract audit valójában?
Az audit lényegében egy kódellenőrzési folyamat, amelynek során független biztonsági kutatók végigmennek a protokoll okosszerződésein. Keresik a logikai hibákat, a reentrancy-sérülékenységeket, az integer overflow problémákat, és az üzleti logika rétegében megbúvó anomáliákat.
A folyamat azonban korántsem egységes. Más minőséget képvisel egy Trail of Bits vagy OpenZeppelin elvégzett vizsgálat, mint egy kisebb, kevésbé ismert cég néhány hetes munkája. Az iparágban nincs kötelező akkreditáció, nincs egységes minősítési rendszer — ami azt jelenti, hogy az „auditált” jelző önmagában semmit nem garantál.
A három nagy sérülékenységtípus
- Reentrancy támadás: A támadó egy tranzakció lezárulta előtt ismételten meghívja a szerződés funkcióját, így a rendszer többször fizet ki egyetlen egyenleget. Ez döntötte el a DAO-hackot 2016-ban is.
- Flash loan exploit: Fedezetlen, egyetlen tranzakcióban visszafizetendő hitelekkel manipulálják az árakon és árfolyamokon alapuló protokolllogikát. A Beanstalk Farms 182 millió dolláros vesztesége 2022-ben flash loan segítségével valósult meg.
- Oracle manipuláció: Ha egy protokoll egyetlen árfolyamforrásra támaszkodik, azt könnyebb befolyásolni. A decentralizált orákulum-hálózatok csökkentik, de nem szüntetik meg ezt a kockázatot.
Folyamatos monitoring — az audit utáni világ
A statikus audit önmagában nem elég, mert a protokollok fejlődnek. Frissítések, új funkciók, governance-változások — mind-mind új kockázati felületet nyitnak meg. Ezért kezdett el teret nyerni a folyamatos, valós idejű biztonsági monitoring gondolata.
Olyan platformok, mint a Forta Network vagy az OpenZeppelin Defender, automatizált riasztási rendszereket kínálnak. Ezek figyelik a szokatlan tranzakciómintákat, a nagy értékű mozgásokat és a potenciálisan rosszindulatú interakciókat — lehetőséget adva arra, hogy egy támadást még a teljes kifosztás előtt észleljenek.
A Euler Finance-hackben a csapatnak mindössze néhány óra állt rendelkezésére a reagálásra. Ahol jobb volt a monitoring rendszer, ott sikerült részleges veszteségmérséklés — ahol nem, ott szinte semmi sem maradt.
A bug bounty programok szerepe
Az élő protokollok másik védelmi vonala a bug bounty program: fehérkalapos hackerek jutalom ellenében jelzik a talált sérülékenységeket. Az Immunefi platform 2024 elejéig összesen több mint 90 millió dollár jutalmat fizetett ki etikus hackereknek — ami jól mutatja, mennyi hibát találnak a formális auditokon túl is.
A legkomolyabb DeFi-protokollok ma már egymillió dolláros nagyságrendű maximális jutalmakat kínálnak kritikus hibákért. Ez nem olcsó megoldás, de az alternatíva — egy sikeres exploit — exponenciálisan többe kerülhet.
Likviditási kockázat: a kevésbé emlegetett veszély
A biztonsági auditok elsősorban a technikai sérülékenységekre fókuszálnak, de a DeFi-protokollok egy teljesen más típusú kockázatot is hordoznak: a likviditási kockázatot. Ez különösen a kisebb, kevésbé likvid protokolloknál jelent komoly problémát.
Amikor egy nagyobb szereplő kiveszi a likviditását egy poolból, a maradék felhasználók drámaian megnövekedett slippage-gel és rontott árfolyamokkal szembesülnek. Extrém esetben ez bank run-szerű spirált indíthat el: mindenki menekül, és a menekülés maga okozza a teljes összeomlást.
TVL mint félrevezető mutató
A Total Value Locked, azaz a protokollban lekötött összes érték az egyik legtöbbet emlegetett DeFi-mutató. Csakhogy önmagában megtévesztő lehet. Egy magas TVL nem jelent sem biztonságot, sem egészséges likviditást — csupán azt mutatja, mennyi tőke „ül” ott éppen.
A valódi likviditásmélységet inkább a piaci mélység (market depth) és a koncentrációs mutató vizsgálata mutatja meg: mennyi a likviditás a legfontosabb árszinteken, és mennyire függ mindez néhány nagytulajdonostól? Ha az összes likviditás 80%-a öt tárca kezében van, az komoly koncentrációs kockázatot jelent.
Governance-kockázat: a backdoor, amit sokan nem látnak
Az egyik legtöbbet alábecsült kockázati forrás a governance-struktúra. Számos protokoll rendelkezik admin kulcsokkal vagy governance-joggal, amelyek segítségével a csapat — vagy egy rosszindulatú szereplő — megváltoztathatja a szerződés paramétereit.
A Tornado Cash governance-hack 2023 májusában szemléletes példa volt erre: a támadó rosszindulatú governance-javaslatot fogadtatott el, majd ezzel átvette az irányítást a protokoll fölött. A decentralizált döntéshozatal papíron jól hangzik — de ha a szavazati jogok koncentráltak, a rendszer éppoly sebezhető, mint egy centralizált megoldás.
Mire figyelj governance szempontból?
- Van-e timelock? Egy javaslat elfogadása és végrehajtása között telik-e el elegendő idő arra, hogy a felhasználók reagálhassanak?
- Mennyire koncentrált a szavazati hatalom? Néhány bálna képes-e egyedül átnyomni egy javaslatot?
- Vannak-e multisig-megoldások a kritikus admin funkciókhoz, vagy egyetlen kulcs elegendő a változtatáshoz?
- Nyilvános-e a fejlesztőcsapat kiléte, vagy teljesen anonim?
Hogyan értékeld egy protokoll biztonsági szintjét?
Nincs tökéletes módszer, de néhány alapvető szempontot érdemes végigvenni, mielőtt bárki tőkét helyez el egy DeFi-protokollban.
- Audit előzmények: Ki végezte az auditot, mikor, és a megtalált hibákat javították-e? Az audit report nyilvánosan elérhető?
- Protokoll életkora: Az idő nem garancia, de egy régebben futó protokoll több stresszt élt túl. Az első hat hónap különösen kockázatos időszak.
- Nyílt forráskód és verifikáció: A kód elérhető és verifikált-e nyilvánosan, például az Etherscan-en?
- Bug bounty program: Létezik-e aktív jutalomazási program, és mekkora a maximális jutalom?
- Biztosítási lefedettség: Elérhető-e a protokollra vonatkozó DeFi-biztosítás, például a Nexus Mutual-on keresztül, és milyen áron?
A biztosítás mint utolsó védelmi vonal
A DeFi-biztosítási piac még gyerekcipőben jár, de lassan érik. A Nexus Mutual és az InsurAce típusú platformok lehetővé teszik, hogy a felhasználók smart contract hibák ellen biztosítsák pozícióikat. Az éves prémium általában a biztosított tőke 2–5%-a között mozog, attól függően, mekkora kockázatúnak tartja a piac az adott protokollt.
Ez az ár önmagában is egyfajta piaci kockázatbecslés: ahol a prémium magas, ott a piac is szkeptikusabb. Nem mindegy tehát, hogy egy protokoll biztosítása elérhető-e egyáltalán — és ha igen, mennyibe kerül.
Összefoglalás
A DeFi-protokollok biztonsági értékelése összetett feladat, amelyet sem egyetlen audit, sem egyetlen mutató nem old meg. A kockázatok több rétegben jelentkeznek: a technikai sérülékenységektől a likviditási koncentráción át a governance-struktúrák hiányosságaiig.
A legfontosabb tanulság talán ez: az „auditált” jelző szükséges, de nem elégséges feltétel. A folyamatos monitoring, a bug bounty programok, az átlátható governance és az egészséges likviditási struktúra együttesen adnak valamiféle képet arról, mennyire megbízható egy protokoll.
Aki tőkét helyez el DeFi-ben, annak érdemes azzal számolni, hogy a szektor a mai napig kísérletezési fázisban van. A hozamok mögött valós, mérhető kockázatok állnak — és ezeket nem a protokoll neve, hanem a konkrét biztonsági infrastruktúra alapján érdemes megítélni.
