Proč se audit smart kontraktů týká i neprogramátorů
Smart kontrakty jsou automatizované dohody běžící na blockchainu. Neodpouštějí chyby: po nasazení často není možné zvrátit důsledky špatné logiky, slabého řízení oprávnění nebo nečekaných interakcí. Manažeři, produktoví vlastníci, právníci, správci treasury či zakladatelé projektů proto musí rozumět, co audit je a co není, jaké jsou jeho limity a jak z něj vytěžit maximum. Tento text je praktický průvodce auditem pro neprogramátory – s důrazem na rozhodnutí, rozpočty, termíny a rizika, nikoli na kód.
Co je audit a co není: definice a limity
- Audit je systematické hodnocení bezpečnosti smart kontraktů: architektury, logiky, interakcí a konfigurace. Výstupem je zpráva s nálezy, závažností (severity), doporučeními a posouzením rizika zbytku (residual risk).
- Audit není záruka bezchybnosti ani pojistka proti ztrátám. Je to snížení rizika – kvalita závisí na rozsahu, čase, odbornosti a spolupráci týmu.
- Limity: omezený čas, neúplné specifikace, dynamické prostředí (oracly, DEX likvidita, L2 mosty) a nemožnost pokrýt všechny kombinace stavů. Proto se audit kombinuje s testováním, formálními metodami, bounty programy a monitoringem po nasazení.
Jak si připravit projekt na úspěšný audit
- Stabilizujte kód: zaveďte code freeze před začátkem auditu. Změny během auditu snižují kvalitu a zvyšují cenu.
- Připravte specifikaci: funkční požadavky, ekonomický design (tokenomie, poplatky), bezpečnostní model (kdo co může), správa klíčů, upgrade politika, pauzovatelnost, limity, časové zámky.
- Testovací sada: unit/integration testy, scénáře ekonomických útoků, invariance (co musí vždy platit), pokrytí testů (coverage) a ukázková konfigurace nasazení.
- Mapa závislostí: verze knihoven (např. OpenZeppelin), externí protokoly, oracly, mosty (bridges), L2 specifika. Uveďte přesné commit hashe.
- Provozní procesy: multisig role, timelocky, emergency pause, incident response plán a komunikační protokol pro uživatele.
Rozsah auditu: co by měl zahrnovat
- Architektonický přehled: vztahy kontraktů, upgrade proxy, přístupové role, správa treasury.
- Kontrola správnosti logiky: ekonomická pravidla, účtování poplatků, výpočty podílů, rozdělování odměn.
- Bezpečnostní vzory: reentrancy guard, checks-effects-interactions, používání openzeppelin modulů, bezpečné volání (call vs. delegatecall).
- Interakce s externím světem: oracly (manipulace cenou), MEV a pořadí transakcí, flash-loan scénáře, závislost na DEX likviditě.
- Konfigurace nasazení: inicializační parametry, prahy, limity, whitelisty/blacklisty, oprávnění admin klíčů a jejich zabezpečení (multisig, HSM, MPC).
- Formální tvrzení: vybrané bezpečnostní vlastnosti, které budou verifikovány (např. „zůstatky nikdy nebudou negativní“, „celková nabídka nepřekročí limit“).
Typická metodika auditu (zjednodušeně)
- Kickoff & scoping: sladění cílů, rozsahu, termínů, prostředí a kontaktních osob.
- Studium specifikace: pochopení funkcionality protokolu a identifikace kritických invariantů.
- Manuální čtení kódu: hledání logických chyb, nestandardních vzorů a nebezpečných závislostí.
- Analýza nástroji: statická analýza, symbolická exekuce, fuzzing (náhodné generování vstupů), differential testing (porovnání s referenční implementací).
- Modelování útoků: reentrancy, manipulace oracly, MEV/tx-ordering, front-running, únik oprávnění, zneužití admin funkcí, ekonomické vyprázdnění poolů.
- Ověření oprávnění: princip nejmenších privilegií, oddělení rolí, timelocky, přístupové kontrolní seznamy.
- Kontrola nasazení: migrace, inicializace proxy, správné adresy, pauza/obnova, aktualizační postupy.
- Správa nálezů: klasifikace (informational/low/medium/high/critical), dopady, pravděpodobnost, doporučení.
- Re-test: ověření oprav a aktualizace závěrů – klíčové pro stakeholdery a integrátory.
Nejčastější třídy zranitelností (vysvětlené „byznys“ řečí)
- Reentrancy: kontrakt odešle externí volání dříve, než zamkne svůj vlastní stav. Útočník může „vytáhnout“ prostředky opakovanými návraty.
- Manipulace cenového zdroje: pokud protokol spoléhá na slabý oracle nebo takový, který lze ovlivnit malým objemem na DEXu, útočník zkreslí cenu a získá neúměrnou výhodu.
- Práva admina: příliš silné klíče, bez timelocku či multisigu. Riziko úmyslného/neopatrného zásahu nebo kompromitace klíče.
- Delegatecall / proxy pasti: sdílení kontextu úložiště mezi kontrakty – jedna chyba v logice nebo inicializaci může „otevřít“ celý protokol.
- Arithmetic a hraniční případy: overflow/underflow (moderní kompilátory je většinou zachytí), dělení nulou, nesprávné zaokrouhlování, přesnosti při výpočtech podílů.
- Front-running a MEV: útočník předběhne transakci s citlivými parametry (např. nastavení ceny/slippage) a změní výsledek pro uživatele.
- Permit/replay útoky: podepisované autorizované převody (EIP-2612) bez správné ochrany proti opakovanému použití.
- Neúmyslné zmražení prostředků: chybějící rescue funkce, nevratné stavy při chybných parametrech, nepokrytí edge případů.
- Chyby ve standardech: neúplná nebo nesprávná implementace ERC rozhraní (20/721/1155), které brání interoperabilitě.
Co má obsahovat dobrá auditní zpráva
- Executive summary: rychlý přehled rizik, počet a typ nálezů, celkové hodnocení a doporučené kroky.
- Scope & commit hash: přesná verze kódu, zahrnuté kontrakty, omezení a předpoklady.
- Metodika: jaké nástroje a přístupy byly použity (manuální review, fuzzing, formální tvrzení).
- Detail nálezů: popis problému, dopady, vektor útoku, příklady scénářů, návrhy oprav, posouzení rizika zbytku.
- Stav po opravách: které nálezy jsou opravené, které jsou akceptované s rizikem, které jsou sporné.
- Doporučení pro provoz: monitoring, limity, postup při incidentech, nastavení rolí a governance.
Jak číst „severity“ a prioritizovat opravy
Severity (závažnost) kombinuje dopad a pravděpodobnost. Pro neprogramátora je klíčové převést ji do priorit:
- Kritické: okamžitá akce před nasazením nebo aktivací funkcí. Pokud je protokol live, zvažte pause nebo limity.
- Vysoké: opravit před rozšířením kapacity (TVL, počet uživatelů), často vyžadují změny logiky.
- Střední: řešit v nejbližším release, mohou být mitigovány konfigurací.
- Nízké/informační: kvalita kódu, optimalizace gasu, dokumentace – důležité pro dlouhodobou udržitelnost.
Rozpočet, harmonogram a dodavatel: praktická rozhodnutí
- Rozsah & složitost určují cenu a čas. Kontrakty s upgrady, složitou ekonomikou a externími závislostmi jsou dražší.
- Nezávislost a reputace: zkuste kombinovat nezávislý tým (manuální review) a kolektivní hodnocení (soutěže, bounty) pro širší pokrytí.
- Kontrakt a SLA: definujte scope, hranice odpovědnosti, počet re-testů, formu výstupu, práva na zveřejnění a časová okna.
- Odhad času: zahrňte rezervu na opravy a re-test. Plánujte audit před token eventy a velkými integracemi.
Formální metody a fuzzing: co o nich potřebujete vědět
Formálně verifikovaná tvrzení dokazují, že vybrané vlastnosti platí pro všechny možné vstupy v rámci určitých předpokladů. Fuzzing simuluje obrovské množství náhodných a hraničních vstupů, aby odhalil neočekávané stavy. Pro rozhodovatele: ptejte se, jaké invariance byly ověřeny a jaké pokrytí dosáhl fuzzing (počet unikátních cest, zásahnuté větve).
Governance, klíče a provoz: bezpečnost není jen kód
- Správa oprávnění: multisig pro admin funkce, timelocky pro neurgentní změny, pause guardian pro incidenty.
- Upgrade politika: transparentní proces, on-chain hlasování, odklad (grace period), veřejná oznámení.
- Segregace povinností: oddělené role pro nasazení, správu treasury a bezpečnost.
- Havarijní plán: runbook pro incidenty, kontaktní kanály, nástroje pro zmírnění (limity, výběrová okna, vypnutí citlivých funkcí).
Ekonomická bezpečnost: když je kód správný, ale ekonomika ne
Mnohé ztráty nevznikly syntaktickou chybou, ale ekonomickým designem. Při auditu proto požadujte:
- Analýzu incentiv: může účastník zneužít poplatkový model nebo odměny?
- Simulace stresu: co se stane při extrémní volatilitě, vyschnutí likvidity nebo selhání oraclu?
- Flash-loan scénáře: jednorázové velké přesuny kapitálu k ovlivnění ceny či stavu.
Bug bounty a kolektivní audity
Po formálním auditu zaveďte bug bounty s jasnými pravidly odměn, rozsahu, důkazů a právních záruk pro výzkumníky. Veřejné soutěže (crowd-audit) rozšíří množství očí a útočných modelů. Klíčová je rychlá triage a spravedlivé vyplácení – to zvýší důvěru komunity.
On-chain monitorování a detekce anomálií
- Alerty na změny konfigurace, volání admin funkcí, velké přesuny, neobvyklé výběry, odchylky oraclů.
- Limitery: denní limity, „circuit breakers“, postupné uvolňování kapacity (TVL caps).
- Telemetrie: metriku provozu ukládat off-chain, ale korelovat s on-chain událostmi (eventy).
Kontrolní seznam pro neprogramátora (před nasazením)
- Máme alespoň jeden nezávislý audit a proběhly re-testy po opravách?
- Jsou specifikace úplné a sladěné s implementací?
- Je definována a vynucena správa oprávnění (multisig, timelock, pause)?
- Máme monitoring a incident response plán s jasnými rolemi?
- Jsou externí závislosti (oracly, DEXy, mosty) identifikovány a mají fallbacky?
- Je připraven bug bounty a proces pro rychlé nasazení oprav?
- Máme TVL limity a postupné škálování místo „all-in“?
Jak vybrat auditního partnera
- Track record: veřejné zprávy, schopnost přiznat nejasnosti, kvalita doporučení.
- Transparentnost metodiky: kombinace manuálu, nástrojů, fuzzingu a formálních tvrzení.
- Komunikace: dostupnost, rychlost triage, ochota vysvětlovat ne-technickému publiku.
- Konflikty zájmů: nezávislost na investičních či integračních vazbách na auditovaný projekt.
Příklady „červených vlajek“ v auditním procesu
- Auditor odmítá sdílet metodiku, uvádí pouze generické fráze a žádá zveřejnění loga bez reálného review.
- Audit probíhá během masivních změn kódu bez jasného code freeze a verzování.
- Zpráva neobsahuje commit hash, stav po opravách ani konkrétní doporučení.
- Projekt ignoruje doporučení pro governance a spoléhá na jediný admin klíč.
