Audit smart kontraktov

Prečo sa audit smart kontraktov týka aj ne-programátorov

Smart kontrakty sú automatizované dohody bežiace na blockchaine. Neodpúšťajú chyby: po nasadení často nie je možné zvrátiť dôsledky zlej logiky, slabého riadenia oprávnení alebo nečakaných interakcií. Manažéri, produktoví vlastníci, právnici, treasury správcovia či zakladatelia projektov preto musia rozumieť, čo audit je, čo nie je, aké má limity a ako z neho vyťažiť maximum. Tento text je praktický sprievodca auditom pre ne-programátorov – s dôrazom na rozhodnutia, rozpočty, termíny a riziká, nie na kód.

Čo je audit a čo nie je: definícia a limity

• Audit je systematické hodnotenie bezpečnosti smart kontraktov: architektúry, logiky, interakcií a konfigurácie. Výstupom je správa s nálezmi, závažnosťou (severity), odporúčaniami a posúdením rizika zostatku (residual risk).
• Audit nie je záruka bezchybnosti ani poistenie proti stratám. Je to zníženie rizika – kvalita závisí od rozsahu, času, odbornosti a spolupráce tímu.
• Limity: obmedzený čas, neúplné špecifikácie, dynamické prostredie (oracly, DEX likvidita, L2 mosty) a nemožnosť obsiahnuť všetky kombinácie stavov. Preto sa audit kombinuje s testovaním, formálnymi metódami, bounty programami a monitorovaním po nasadení.

Ako si pripraviť projekt na úspešný audit

1. Stabilizujte kód: zaviesť code freeze pred začiatkom auditu. Zmeny počas auditu znižujú kvalitu a zvyšujú cenu.
2. Pripravte špecifikáciu: funkčné požiadavky, ekonomický dizajn (tokenómia, poplatky), bezpečnostný model (kto čo môže), správa kľúčov, upgrade politika, pauzovateľnosť, limity, časové zámky.
3. Testovacia sada: unit/integration testy, scenáre ekonomických útokov, invaranty (čo musí vždy platiť), pokrytie testov (coverage) a ukážková konfigurácia nasadenia.
4. Mapa závislostí: verzie knižníc (napr. OpenZeppelin), externé protokoly, oracly, mosty (bridges), L2 špecifiká. Uveďte presné commit hash-e.
5. Prevádzkové procesy: multisig role, timelocky, emergency pause, incident response plán a komunikačný protokol pre používateľov.

Rozsah auditu: čo by mal zahŕňať

• Architektonický prehľad: vzťahy kontraktov, upgradovacie proxy, prístupové roly, správa treasury.
• Kontrola správnosti logiky: ekonomické pravidlá, účtovanie poplatkov, výpočty podielov, rozdeľovanie odmien.
• Bezpečnostné vzory: reentrancy guard, checks-effects-interactions, používanie openzeppelin modulov, bezpečné volania (call vs. delegatecall).
• Interakcie s externým svetom: oracly (manipulácia ceny), MEV a poradie transakcií, flash-loan scenáre, závislosť od DEX likvidity.
• Konfigurácia nasadenia: inicializačné parametre, prahy, limity, whitelisty/blacklisty, oprávnenia admin kľúčov a ich zabezpečenie (multisig, HSM, MPC).
• Formálne tvrdenia: vybrané bezpečnostné vlastnosti, ktoré budú verifikované (napr. „zostatky nikdy nebudú negatívne“, „celková ponuka neprekročí limit“).

Typická metodika auditu (zjednodušene)

1. Kickoff & scoping: zosúladenie cieľov, rozsahu, termínov, prostredia a kontaktných osôb.
2. Štúdium špecifikácie: pochopenie toho, čo má protokol robiť, a identifikácia kritických invariantov.
3. Manuálne čítanie kódu: hľadanie logických chýb, neštandardných vzorov a nebezpečných závislostí.
4. Analýza nástrojmi: statická analýza, symbolická exekúcia, fuzzing (náhodné generovanie vstupov), differential testing (porovnanie proti referenčnej implementácii).
5. Modelovanie útokov: reentrancy, manipulácia oracle, MEV/tx-ordering, front-running, únik oprávnení, zneužitie admin funkcií, ekonomické vyprázdnenie poolov.
6. Overenie oprávnení: principle of least privilege, oddelenie rolí, timelocky, prístupové kontrolné zoznamy.
7. Kontrola nasadenia: migrácie, inicializácia proxy, správne adresy, pauza/obnova, aktualizačné postupy.
8. Správa nálezov: klasifikácia (informational/low/medium/high/critical), dopady, pravdepodobnosť, odporúčania.
9. Re-test: verifikácia opráv a aktualizácia záveru – dôležité pre stakeholderov a integrátorov.

Najčastejšie triedy zraniteľností (vysvetlené „biznis“ rečou)

• Reentrancy: kontrakt odošle externé volanie skôr, než uzamkne svoj vlastný stav. Útočník môže „vyťahať“ prostriedky opakovanými návratmi.
• Manipulácia cenového zdroja: ak protokol spolieha na slabý oracle alebo ten, ktorý možno ovplyvniť malým objemom na DEXe, útočník skreslí cenu a získa neprimeranú výhodu.
• Práva admina: príliš silné kľúče, bez timelocku či multisigu. Riziko úmyselného/neudbanlivého zásahu alebo kompromitácie kľúča.
• Delegatecall / proxy pasce: zdieľanie kontextu úložiska medzi kontraktmi – jedna chyba v logike alebo inicializácii môže „otvoriť“ celý protokol.
• Arithmetic a hranové prípady: overflow/underflow (moderné kompilátory ich väčšinou chytia), delenie nulou, nesprávne zaokrúhľovanie, presnosti pri výpočtoch podielov.
• Front-running a MEV: útočník predbehne transakciu s citlivými parametrami (napr. nastavenie ceny/slippage) a zmení výsledok pre používateľov.
• Permit/replay útoky: podpisom autorizované prevody (EIP-2612) bez správnej ochrany proti opakovanému použitiu.
• Nezámýšľané zmrazenie prostriedkov: chýbajúce rescue funkcie, nevratné stavy pri chybných parametroch, nepokrývanie edge caseov.
• Chyby v štandardoch: neúplné alebo nesprávne implementované ERC rozhrania (20/721/1155), ktoré bránia interoperabilite.

Čo má obsahovať dobrá auditná správa

• Executive summary: rýchly prehľad rizík, počet a typ nálezov, celkové hodnotenie a odporúčané kroky.
• Scope & commit hash: presná verzia kódu, zahrnuté kontrakty, obmedzenia a predpoklady.
• Metodika: aké nástroje a prístupy boli použité (manuálny review, fuzzing, formálne tvrdenia).
• Detail nálezov: popis problému, vplyv, vektor útoku, príklady scenárov, návrhy opráv, posúdenie rizika zostatku.
• Stav po opravách: ktoré nálezy sú fixnuté, ktoré akceptované s rizikom, ktoré sú sporné.
• Odporúčania na prevádzku: monitorovanie, limity, postup pri incidente, nastavenie rolí a governance.

Ako čítať „severity“ a prioritizovať opravy

Severity (závažnosť) kombinuje dopad a pravdepodobnosť. Pre ne-programátora je kľúčové preložiť ju do priorít:

1. Kritické: okamžitá akcia pred nasadením alebo aktiváciou funkcií. Ak je protokol live, zvážte pause alebo limity.
2. Vysoké: opraviť pred rozšírením kapacity (TVL, počet používateľov), často vyžadujú zmeny logiky.
3. Stredné: riešiť v najbližšom release, môžu byť mitigované konfiguráciou.
4. Nízke/informačné: kvalita kódu, gas optimalizácie, dokumentácia – dôležité pre dlhodobú udržateľnosť.

Rozpočet, harmonogram a dodávateľ: praktické rozhodnutia

• Rozsah & zložitosť určujú cenu a čas. Kontrakty s upgradami, komplexnou ekonomikou a externými závislosťami sú drahšie.
• Nezávislosť a reputácia: skúste kombinovať nezávislý tím (manuálny review) a kolektívne hodnotenie (súťaže, bounty) pre širšie pokrytie.
• Kontrakt a SLA: definujte scope, hranice zodpovednosti, počet re-testov, formu výstupu, práva na zverejnenie a časové okná.
• Odhad času: zahrňte rezervu na fixy a re-test. Plánujte audit pred token eventami a veľkými integráciami.

Formálne metódy a fuzzing: čo o nich potrebujete vedieť

Formálne verifikované tvrdenia preukazujú, že vybrané vlastnosti platia pre všetky možné vstupy v rámci určitých predpokladov. Fuzzing simuluje obrovské množstvo náhodných a hraničných vstupov, aby odhalil neočakávané stavy. Pre rozhodovateľov: pýtajte sa, aké invaranty boli overené a aké pokrytie dosiahol fuzzing (počet unikátnych cestách, zasiahnuté vetvy).

Governance, kľúče a prevádzka: bezpečnosť nie je len kód

• Správa oprávnení: multisig pre admin funkcie, timelocky pre neurgentné zmeny, pause guardian pre incidenty.
• Upgrade politika: transparentný proces, on-chain hlasovanie, odklad (grace period), verejné oznámenia.
• Segregácia povinností: oddelené roly pre nasadzovanie, správu treasury a bezpečnosť.
• Havarijný plán: runbook pre incidenty, kontaktné kanály, nástroje na zmiernenie (limity, okná výberov, vypnutie citlivých funkcií).

Ekonomická bezpečnosť: keď je kód správne, ale ekonomika nie

Mnohé straty nevznikli syntaktickou chybou, ale ekonomickým dizajnom. Pri audite preto žiadajte:

• Analýzu incentív: môže účastník zneužiť poplatkový model alebo odmeny?
• Simulácie stresu: čo sa stane pri extrémnej volatilite, vyschnutí likvidity alebo zlyhaní oraclu?
• Flash-loan scenáre: jednorazové veľké presuny kapitálu na ovplyvnenie ceny či stavu.

Bug bounty a kolektívne audity

Po formálnom audite zaveďte bug bounty s jasnými pravidlami odmien, rozsahu, dôkazov a právnych záruk pre výskumníkov. Verejné súťaže (crowd-audit) rozšíria množinu oči a útočných modelov. Kľúčové je rýchle triage a férové vyplácanie – zvýši to dôveru komunity.

On-chain monitorovanie a detekcia anomálií

• Alerty na zmeny konfigurácie, volanie admin funkcií, veľké presuny, nezvyčajné výbery, odchýlky oraclov.
• Limitery: denné stropy, „circuit breakers“, postupné uvoľňovanie kapacity (TVL caps).
• Telemetria: metriku prevádzky ukladať off-chain, ale korelovať s on-chain udalosťami (eventy).

Kontrolný zoznam pre ne-programátora (pred nasadením)

1. Máme aspoň jeden nezávislý audit a prebehli re-testy po opravách?
2. Sú špecifikácie úplné a zosúladené s implementáciou?
3. Je definovaná a vynútená správa oprávnení (multisig, timelock, pause)?
4. Máme monitoring a incident response plán s jasnými rolami?
5. Sú externé závislosti (oracly, DEXy, mosty) identifikované a majú fallbacky?
6. Je pripravený bug bounty a proces na rýchle nasadenie fixov?
7. Máme TVL limity a postupné škálovanie namiesto „all-in“?

Ako vybrať auditného partnera

• Track record: verejné správy, schopnosť priznať nejasnosti, kvalita odporúčaní.
• Transparentnosť metodiky: kombinácia manuálu, nástrojov, fuzzingu a formálnych tvrdení.
• Komunikácia: dostupnosť, rýchlosť triage, ochota vysvetľovať ne-technickému publiku.
• Konflikty záujmov: nezávislosť od investičných či integračných väzieb na auditovaný projekt.

Príklady „červených vlajok“ v auditnom procese

• Auditor odmieta zdieľať metodiku, uvádza iba generické frázy a žiada zverejnenie loga bez reálneho review.
• Audit prebieha počas masívnych zmien kódu bez jasného code freeze a verzovania.
• Správa neobsahuje commit hash, stav po opravách ani konkrétne odporúčania.
• Projekt ignoruje odporúčania na governance a spolieha sa na jediný admin kľúč.

Špecifiká rôznych sietí a štandardov

• Ethereum a EVM L2: pozor na odlišné gas limity, sequencer riziká, finalitu a odlišné časy potvrdenia.
• Ne-EVM siete: iné modely účtov, štandardy tokenov, prístupové mechanizmy; vyžadujú špecializovanú expertízu.
• Mosty (bridges): často najväčšie riziko – verifikácia správ, trust model, multi-sig validátori, ekonomické stimuly.

Komunikácia s komunitou a zverejňovanie

Zverejnite auditné správy, popíšte, čo bolo opravené a čo zostalo ako akceptované riziko (s dôvodmi). Pred major release oznámte zmeny s predstihom, používajte timelocky a dajte možnosť exitovať bez penalizácií.

Minimalistický plán od nápadu po bezpečný launch

1. Špecifikácia & threat model → spíšte invaranty, roly, limity, závislosti.
2. Vývoj & testy → unit/integration, fuzzing, scenáre ekonomických útokov.
3. Interný bezpečnostný pre-review → checklist a tool-based skeny.
4. Nezávislý audit → minimálne jeden, ideálne s re-testom.
5. Bug bounty & limity → pred otvorením plnej kapacity.
6. Monitorovanie & runbook → alerty, pause, komunikačný plán.
7. Post-launch hodnotenie → spätná väzba, metriky incidentov, roadmapa bezpečnostných zlepšení.

Zhrnutie pre rozhodovateľov

Audit smart kontraktov je proces riadenia rizika, nie „pečiatka“. Váš prínos ako ne-programátora je v jasných špecifikáciách, discipline procesu (code freeze, governance, incident plán), výbere partnerov a v komunikácii s komunitou. Kombinujte viac vrstiev obrany: kvalitný dizajn, nezávislý audit, bug bounty, limity, monitorovanie a transparentnosť. Tak maximalizujete šancu, že protokol obstojí v reálnom svete – aj vtedy, keď niečo zlyhá.