Základy auditu smart kontraktů pro neprogramátory

Proč se audit smart kontraktů týká i neprogramátorů

Smart kontrakty jsou automatizované dohody běžící na blockchainu. Nedopusťují chyby: po nasazení často není možné vzít zpět důsledky špatné logiky, slabého řízení oprávnění nebo neočekávaných interakcí. Manažeři, produktoví vlastníci, právníci, správci treasury či zakladatelé projektů proto musí rozumět, co audit je, co není, jaké má limity a jak z něj vytěžit maximum. Tento text je praktickým průvodcem 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 reziduálního rizika (residual risk).
• Audit není zárukou bezchybnosti ani pojištěním proti ztrátám. Je to snížení rizika – kvalita závisí na rozsahu, času, odbornosti a spolupráci týmu.
• Limity: omezený čas, neúplné specifikace, dynamické prostředí (oracle, 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 monitorováním po nasazení.

Jak si připravit projekt na úspěšný audit

1. Stabilizujte kód: zavést code freeze před začátkem auditu. Změny během auditu snižují kvalitu a zvyšují cenu.
2. 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.
3. Testovací sada: unit/integration testy, scénáře ekonomických útoků, invarianty (co musí vždy platit), pokrytí testů (coverage) a ukázková konfigurace nasazení.
4. Mapa závislostí: verze knihoven (např. OpenZeppelin), externí protokoly, oracle, mosty (bridges), L2 specifika. Uveďte přesné commit hash-e.
5. 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: oracle (manipulace cen), 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ě)

1. Kickoff & scoping: sladění cílů, rozsahu, termínů, prostředí a kontaktních osob.
2. Studium specifikace: pochopení, co má protokol dělat, a identifikace kritických invariantů.
3. Manuální čtení kódu: hledání logických chyb, nestandardních vzorů a nebezpečných závislostí.
4. Analýza nástroji: statická analýza, symbolická exekuce, fuzzing (náhodné generování vstupů), differential testing (porovnání s referenční implementací).
5. Modelování útoků: reentrancy, manipulace oracle, MEV/tx-ordering, front-running, únik oprávnění, zneužití admin funkcí, ekonomické vyprázdnění poolů.
6. Ověření oprávnění: princip nejmenších oprávnění, oddělení rolí, timelocky, přístupové kontrolní seznamy.
7. Kontrola nasazení: migrace, inicializace proxy, správné adresy, pauza/obnova, aktualizační postupy.
8. Zpráva nálezů: klasifikace (informational/low/medium/high/critical), dopady, pravděpodobnost, doporučení.
9. Re-test: verifikace oprav a aktualizace závěru – důležité pro stakeholdery a integrátory.

Nejčastější třídy zranitelností (vysvětlené „byznys“ jazykem)

• Reentrancy: kontrakt odesílá externí volání dříve, než uzamkne svůj stav. Útočník může „vybrat“ 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á nepřiměřenou výhodu.
• Práva admina: příliš silné klíče bez timelocku nebo multisigu. Riziko úmyslného/neúmyslného zásahu nebo kompromitace klíče.
• Delegatecall / proxy pasti: sdílení kontextu úložiště mezi kontrakty – jedna chyba v logice či inicializaci může „otevřít“ celý protokol.
• Arithmetic a hranové případy: overflow/underflow (moderní kompilače je většinou chytí), dělení nulou, nesprávné zaokrouhlování, přesnost výpočtů 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: podepsané autorizované převody (EIP-2612) bez správné ochrany proti opakovanému použití.
• Neúmyslné zmrazení prostředků: chybějící rescue funkce, nevratné stavy při chybných parametrech, nepokrytí edge casů.
• Chyby ve standardech: neúplné nebo nesprávně implementované 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, dopad, vektor útoku, příklady scénářů, návrhy oprav, posouzení reziduálního rizika.
• Stav po opravách: které nálezy jsou opravené, které akceptované s rizikem, které jsou sporné.
• Doporučení na provoz: monitorování, limity, postup při incidentu, 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řeložit ji do priorit:

1. Kritické: okamžitá akce před nasazením nebo aktivací funkcí. Pokud je protokol live, zvažte pause nebo limity.
2. Vysoké: opravit před rozšířením kapacity (TVL, počet uživatelů), často vyžadují změny logiky.
3. Střední: řešit v nejbližším releasu, mohou být mitigovány konfigurací.
4. 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 updaty, komplexní 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 rezervy 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 i hraničních vstupů, aby odhalil neočekávané stavy. Pro rozhodovatele: ptejte se, jaké invarianty byly ověřeny a jaké pokrytí fuzzing dosáhl (počet unikátních cest, zasažené 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 nasazování, správu treasury a bezpečnost.
• Havarijní plán: runbook pro incidenty, kontaktní kanály, nástroje ke zmírnění (limity, časová okna výběrů, vypnutí citlivých funkcí).

Ekonomická bezpečnost: když je kód správný, ale ekonomika nikoli

Mnohé ztráty nevznikly syntaktickou chybou, ale chybným ekonomickým designem. Při auditu proto požadujte:

• Analýzu incentiv: může účastník zneužít model poplatků nebo odměn?
• Simulace stresu: co se stane při extrémní volatilitě, vyschnutí likvidity nebo selhání oracle?
• Flash-loan scénáře: jednorázové velké přesuny kapitálu pro 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šíří počet očí a útočné modely. Klíčové je rychlé třídění nálezů a fér vyplácení – to zvýší důvěru komunity.

On-chain monitorování a detekce anomálií

• Upozornění na změny konfigurace, volání admin funkcí, velké přesuny, neobvyklé výběry, odchylky oracle.
• Omezení: denní limity, „circuit breakers“, postupné uvolňování kapacity (TVL caps).
• Telemetrie: metriky provozu ukládat off-chain, ale korelovat s on-chain událostmi (eventy).

Kontrolní seznam pro neprogramátora (před nasazením)

1. Máme alespoň jeden nezávislý audit a proběhly re-testy po opravách?
2. Jsou specifikace kompletní a sladěné s implementací?
3. Je definována a vynucena správa oprávnění (multisig, timelock, pause)?
4. Máme monitoring a incident response plán s jasnými rolemi?
5. Jsou externí závislosti (oracle, DEXy, mosty) identifikovány a mají fallbacky?
6. Je připraven bug bounty a proces pro rychlé nasazení oprav?
7. 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 třídění, ochota vysvětlovat netechnickému publiku.
• Konflikty zájmů: nezávislost od investičních či integračních vazeb na auditovaný projekt.

Příklady „červených vlajek“ v auditním procesu