Základy auditu smart kontraktů pro neprogramátory: metodika bezpečnostního hodnocení

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ávcové treasury či zakladatelé projektů proto musí chápat, co audit je a 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 rizika zbytku (residual risk).
• Audit není záruka bezchybnosti ani pojištění proti ztrátám. Jde o 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, likvidita DEX, L2 mosty) a nemožnost pokrýt všechny možné 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: zaveďte 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, možnost pozastavení, limity, časové zámky.
3. Testovací sada: unit/integrace 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, oracly, mosty (bridges), specifika L2. Uveďte přesné commit hash-e.
5. Provozní procesy: multisig role, timelocky, emergency pause, plán reakce na incidenty 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ů, dělení odměn.
• Bezpečnostní vzory: reentrancy guard, checks-effects-interactions, využívání openzeppelin modulů, bezpečné volání (call vs. delegatecall).
• Interakce s externím světem: oracly (možnost manipulace cen), MEV a pořadí transakcí, flash-loan scénáře, závislost na likviditě DEXu.
• 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 podléhající verifikaci (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í funkcí protokolu 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, upgrade postupy.
8. Zpráva nálezů: klasifikace (informational/low/medium/high/critical), dopady, pravděpodobnost, doporučení.
9. Re-test: ověření oprav a aktualizace závěrů – důležité pro stakeholdery a integrátory.

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

• Reentrancy: kontrakt odešle externí volání dříve, než uzamkne svůj vlastní 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 či multisigu. Riziko úmyslného/neudbalé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 hranové případy: overflow/underflow (moderní překladače je většinou zachytí), dělení nulou, nesprávné zaokrouhlování, přesnost 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: podepsané autorizované převody (EIP-2612) bez správné ochrany proti opakovanému použití.
• Nezamýšlené zmrazení prostředků: chybějící rescue funkce, nevratné stavy při chybných parametrech, nepokrytí edge caseů.
• 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: použité nástroje a přístupy (manuální review, fuzzing, formální tvrzení).
• Detail nálezů: popis problému, dopad, vektor útoku, příklady scénářů, návrhy oprav, posouzení rizika zbytku.
• Stav po opravách: které nálezy jsou opravené, které akceptované s rizikem, které sporné.
• Doporučení k provozu: 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 živý, zvažte pozastavení 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žší verzi, lze mitigovat 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 upgradami, 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 rozsah, 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 retesty. 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í dokládají, že vybrané vlastnosti platí pro všechny možné vstupy v rámci stanovený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é 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, 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 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í oracle?
• 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čí i útočných modelů. Klíčová je rychlá triáž a férové vyplácení – zvýší to 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 oracle.
• Limitery: denní limity, „circuit breakers“, postupné uvolňování kapacity (TVL caps).
• Telemetrie: metriky provozu ukládat off-chain, ale korelovat je 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 vynucována 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 (oracly, DEXy, mosty) identifikovány a mají fallbacky?
6. Je připraven bug bounty a proces na 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 triáže, 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

• Auditor odmítá sdílet metodiku, uvádí pouze generické fráze a požaduje zveřejnění loga bez reálné revize.
• 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í k governance a spoléhá na jediný admin klíč.

Specifika různých sítí a standardů

<