Bezpečnost smart kontraktů

Účel a kontext: proč řešit bezpečnost chytrých kontraktů

Chytré kontrakty představují programovatelnou vrstvu decentralizovaných systémů (DeFi, NFT, DAO, hry). Na rozdíl od tradičního softwaru je jejich nasazení často nevratné, kód je veřejně auditovatelný a aktiva spravovaná kontrakty jsou okamžitě likvidní. Každá chyba má bezprostřední finanční dopady. Cílem tohoto článku je systematicky shrnout klíčová bezpečnostní rizika, útočné vektory a ověřené protiopatření pro návrh, vývoj a provoz chytrých kontraktů zejména v ekosystémech EVM (Solidity/Vyper), ale s obecnou platností i pro jiné platformy.

Model hrozeb: aktéři, povrchy útoku a předpoklady

• Externí útočník: neprivilegovaný účastník s možností volat veřejné funkce, manipulovat mempoolem a využít MEV.
• Privilegovaný insider: držitel administrátorských klíčů, multisigu, správce upgrade proxy, operátor oraclu.
• Ekonomický útočník: využívá racionální chování protistran, neefektivní incentivy a tržní neefektivity (flash půjčky, manipulace cen).
• Povrchy útoku: veřejná rozhraní kontraktů, hooky (fallback/receive), externí volání (call, delegatecall), oracly, cross-chain mosty, L2 zprávy, front-running na úrovni mempoolu.
• Předpoklady: plná transparentnost kódu a stavu, determinismus vykonání v rámci bloku, nedeterministické pořadí transakcí z pohledu uživatele.

Reentrancy a interakční vzory

• Popis: zneužití externího volání k opětovnému vstupu do kontraktu před aktualizací jeho stavu, typicky při výplatách.
• Zasažené patterny: push platby, callbacky, ERC-777/ETH přijímače, onERC721Received.
• Mitigace: vzor checks-effects-interactions, ReentrancyGuard, pull platby (withdraw pattern), minimalizace externích volání, caps na výplaty, použití call s nulovým gas stipendem vědomě a bezpečně.

Matematické chyby: přetečení, podtečení a zaokrouhlování

• Popis: aritmetické chyby vedoucí k neúmyslným hodnotám. V Solidity 0.8+ je aritmetika defaultně checked, starší kód či inline assembly rizikové.
• Mitigace: používat moderní kompilátor, bezpečnostní knihovny pro mulDiv s přesností, vyhýbat se dělení před násobením, validovat invariants (např. x*y=k u AMM).

Autorizace a řízení přístupu

• Chyby: nezáměrně veřejné funkce, reliance na tx.origin, chybějící onlyOwner ekvivalent, špatné modifier pořadí.
• Mitigace: explicitní role (RBAC) přes knihovny typu AccessControl, rozdělení povinností (SoD), časové zámky (Timelock) pro administrativní akce, pause spínač (Pausable) pro incident response.

Frontrunning, MEV a manipulace pořadí

• Popis: útočník přeuspořádá, vsune (sandwich) nebo zkopíruje transakci před obětí.
• Mitigace: commit–reveal protokoly, off-chain podepisování a meta-transactions s relayerem, limity skluzu a deadline parametry, dávkové aukce, využití privátních transakčních kanálů (tam kde dává smysl).

Oracle rizika a manipulace s cenou

• Popis: zneužití slabých cenových zdrojů (jednoduché spot ceny z nízké likvidity) ke změně kolaterálních poměrů či likvidací.
• Mitigace: časově vážené průměry (TWAP), kombinované zdroje (medianizéry), oracly s ekonomickými zárukami, zpožděná finalizace, limity na jednorázové změny.

Flash půjčky a ekonomické útoky

• Popis: bleskově vypůjčená likvidita k manipulaci stavu, cen a invariants během jediného bloku.
• Mitigace: navrhovat invarianty odolné vůči atomickým změnám, používat oracly odolné vůči jednorázovým posunům, v kritických funkcích vyžadovat víc než jedno blokové potvrzení stavu (kde je to akceptovatelné).

Delegatecall a knihovní vzory

• Rizika: delegatecall spouští kód v kontextu volajícího – může měnit jeho úložiště. Chyby ve směrování nebo malformované knihovny vedou k převzetí stavu.
• Mitigace: striktní whitelist cílových implementací, kontrola implementation slotu dle EIP-1967, immutable adresy knihoven, audit inicializátorů.

Upgradovatelnost: proxy, inicializace a kolize úložiště

• Chyby: nezavolané initializer umožňující převzetí vlastnictví, kolize storage layout mezi verzemi, špatně zabezpečený upgradeTo flow.
• Mitigace: standardy (Transparent/UUPS proxy), initializer s initializer modifier, storage gaps, timelock + multisig na upgrade, formální kontrola rozložení úložiště a test migrací.

DoS a griefing: plyn, smyčky, nepředvídatelné externí závislosti

• Chyby: neomezené iterace přes uživatelské seznamy, tvrdá závislost na externích voláních, selfdestruct a blokace návratových cest.
• Mitigace: navrhovat operace jako per-uživatel (pull model), paging, capy, refund-friendly vzory, ochrana proti gas griefing.

Náhodnost, čas a zdroje entropie

• Chyby: používání block.timestamp, blockhash a dalších manipulovatelných zdrojů jako náhody.
• Mitigace: commit–reveal s více účastníky, VRF oracly, víceblokové odhalení, limitace závislosti logiky na čase a čísle bloku.

Podpisy, replay a EIP-712

• Rizika: podpisy bez domény a nonce umožňují přehrání, zaměnitelnost řetězců.
• Mitigace: strukturované podpisy EIP-712, per-uživatel nonce, expirace a chain-id kontrola, oddělení práv pro permit/schvalování.

Standardy tokenů a hooky

• ERC-20/721/1155: rozdíly implementací (vracené bool, revert vs. návratové kódy), bezpečné převody s hooky mohou spustit reentrancy.
• Mitigace: používat prověřené knihovny, safe funkce, nonReentrant ochrany, minimalizace logiky v hookech.

Cross-chain a mosty

• Rizika: neautentizované zprávy, slabé light-client ověřování, chybné relaye, rozdílné finality.
• Mitigace: kryptografická ověření (light clients), zk-based důkazy, rate limits, circuit breakers, víceoperátorové schvalování.

Specifika L2 a rollupů

• Rizika: časová okna pro výběry, sequencer liveness, odlišné limity plynu a prekompilace, odlišný mempool/MEV model.
• Mitigace: design kompatibilní s cílovým L2, zohlednit finalitu a challenge period, testy na daném L2.

Bezpečnostní best practices v návrhu

• Minimalistický povrch: veřejné jen nezbytné funkce, rozhraní stabilní, explicitní receive/fallback s omezeními.
• Invarianta-first design: definovat a testovat invarianty (např. conservation of value, nepřekročitelnost capů).
• Fail-safe: Pausable, CircuitBreaker, RateLimiter pro nouzové stavy.
• Separační vrstvy: moduly pro matematiku, přístup, oracly; minimalizovat inline assembly.

Bezpečný vývojový proces

• Statická analýza: Slither, Mythril; pravidla na CI.
• Fuzzing a invariantní testy: Echidna, Foundry fuzz, property-based testy s formálními vlastnostmi.
• Symbolická exekuce: Manticore/Harvey na kritické cesty.
• Formální verifikace: pro protokoly spravující vysokou hodnotu (např. specifikace v Scribble/Certora/Isabelle/HOL dle potřeby).
• Kolegové a externí audit: vícestupňový code review, nezávislý auditní tým, řešení připomínek před nasazením.

Provoz, monitoring a reakce na incident

• On-chain alerting: sledování událostí (Eventy), anomálií toků, neobvyklých volání admin funkcí, změn implementace proxy.
• Runbooky: přesné postupy pro pause, blokaci výběrů, upgrade s timelockem, komunikaci s komunitou.
• Bug bounty: program s jasným rozsahem, responsible disclosure, odměny odpovídající riziku.

Role klíčů, multisig a governance

• Správa klíčů: multisig (≥2 z 3, lépe 3 z 5), hardwarové peněženky, opatrná rotace, oddělení pravomocí (upgrade vs. parametry vs. pauza).
• Governance: on-chain návrhy, quorum, timelock, nouzové mechanizmy a programově vymahatelná pravidla.

Tabulka: typické zranitelnosti a mitigace

Testovací strategie a pokrytí

• Jednotkové testy: validace happy-path i edge-case parametrů, návratových hodnot, událostí.
• Integrační testy: interakce s oracly, tokeny, proxy a externími protokoly.
• Situační scénáře: flash úvěr + obchod + likvidace, manipulace mempoolu, reentrancy skrze hooky.
• Testnet a canary nasazení: postupné navýšení limitů, monitorované nasazení s omezenou správou prostředků.

Dokumentace a transparentnost

• Specifikace: formální popis rozhraní, stavových proměnných a invarantů.
• Audit reporty: zveřejněné závěry, reakce a verifikace oprav.
• Komunikace rizik: limity protokolu, admin oprávnění, procesy pro nouzové zásahy.

Checklist před nasazením

• Solidity/Vyper verze aktuální, optimalizační vlajky a via-IR dle doporučení.
• RBAC a timelocky na všechny privilegované funkce; Pausable na kritické cesty.
• Proxy inicializovány, initializer zamknut, storage layout zdokumentován.
• Oracly odolné vůči manipulaci; TWAP/median, limity na odchylky.
• Fuzzing a invariantní testy běží v CI; statika a symbolika bez kritických nálezů.
• Bug bounty spuštěný, runbook incidentů připraven, alerty nasazené.

Závěr

Bezpečnost chytrých kontraktů je multidisciplinární disciplína kombinující formální metody, secure coding, ekonomické modelování a provozní připravenost. Nejlepší obranou je minimalismus v návrhu, explicitní řízení přístupů, důsledné testování a monitorování, a procesy reagující na incidenty. Jelikož útoky často zneužívají ekonomické slabiny stejně jako technické chyby, musí být bezpečnost a ekonomika protokolu navrženy společně a ověřeny praxí i nezávislým auditem.