Začněte tím, co kontrakt slibuje
Smart kontrakt může nakládat s hodnotou a po nasazení se jeho chyby často napravují obtížně. Revize proto nezačíná hledáním známých vzorů v kódu, ale stručným modelem očekávaného chování. Sepište aktéry, jejich oprávnění, tok aktiv, pravidla výpočtu a stavy, v nichž se může systém nacházet. U každého veřejného volání určete vstupy, výstupy, účinky a situace, kdy má transakce selhat. Bez specifikace se dá potvrdit, že kód funguje podle sebe sama, ale ne zda dělá to, co potřebuje produkt.
Vymezte přesný rozsah: verzi zdrojů, compileru, závislosti, síť a adresy externích kontraktů. Zahrňte i skripty pro nasazení, počáteční nastavení a webovou či serverovou část, která volání připravuje. Chyba v adrese, desetinných místech tokenu nebo roli správce může mít stejný dopad jako chyba ve funkci převodu. Před revizí zmrazte commit a seznam výjimek. Nález na jiném commitu se nevztahuje na skutečně vydaný bytecode.
Sepište invarianty a hranice důvěry
Invariant je vlastnost, která musí platit napříč posloupnostmi transakcí. Příklady: součet závazků nepřevýší krytí, běžný uživatel nemůže změnit příjemce poplatků, vyplacená částka nelze vyplatit znovu a nouzové zastavení neumožní převod cizích prostředků. Přeložte tyto věty do testů, které zkoušejí mnoho pořadí akcí, nejen jednotlivé šťastné cesty. Ethereum v bezpečnostních doporučeních zdůrazňuje kombinaci jednotkových a vlastnostních testů. Ani dobré pokrytí řádků neříká, zda byly zvoleny správné vlastnosti.
Nakreslete hranice důvěry k oracle, mostům, jiným kontraktům a operátorům. Zeptejte se, co se stane při chybných nebo starých datech, selhání externího volání či změně pravidel protistrany. Útočník může ovládat pořadí transakcí a vytvořit stav, který se v ručním testu nevyskytl. Každý předpoklad o spolehlivosti třetí strany má být explicitní. Pokud bez ní nelze produkt bezpečně provozovat, je to obchodní rozhodnutí, které se nesmí skrývat v kódu.
Zkontrolujte role a správu klíčů
Vytvořte tabulku všech privilegovaných funkcí: kdo může měnit parametry, zastavit provoz, upgradovat implementaci, vybírat poplatky nebo obnovovat službu. Ověřte výchozí přidělení rolí, jejich převod a odebrání. Nezapomeňte na možnost, že oprávněný klíč bude ztracen nebo zneužit. Technicky bezpečný kontrakt s jediným nechráněným administrátorským klíčem má stále zásadní provozní riziko. U kritických změn zvažte více podpisů, časový odklad a oddělení návrhu od schválení.
Přezkoumejte i proces mimo řetězec: kdo drží klíče, jak se zálohují, kdo má přístup k prostředí pro nasazení a jak se ověřuje adresa před podpisem. Přidejte postup pro mimořádnou výměnu správce, který byl vyzkoušen na testovací síti. Pozor na dočasná oprávnění přidělená při nasazení a nikdy neodebraná. Log událostí musí pomoci odlišit běžnou změnu parametrů od incidentu, ale událost nenahrazuje kontrolu samotné autorizace.
Externí volání a opětovný vstup
Solidity v bezpečnostních doporučeních uvádí vzor kontroly, změna stavu, interakce. Když kontrakt odešle hodnotu nebo zavolá jiný kontrakt před dokončením vlastního stavu, může protistrana znovu vstoupit do funkce. Prověřte všechny cesty externího volání, včetně volání přes knihovny, tokenových hooků a zdánlivě známých adres. Ochranný zámek může pomoci, ale nenahrazuje správnou logiku zůstatků a přechodů. Testujte scénáře s protistranou, která volání vrací, odmítá nebo se pokusí znovu vstoupit.
Uvažujte i limity gasu, návratové hodnoty, chyby převodů a práce s nestandardními tokeny. Předpoklad, že každý token vrátí očekávaný boolean nebo má stejné desetinné místo, bývá nebezpečný. Hromadné operace mohou překročit gas limit a zablokovat zpracování celé skupiny. V testech kombinujte malé, hraniční i extrémní hodnoty a prověřte zaokrouhlování. Zvláštní pozornost si zaslouží časová závislost a manipulace pořadím transakcí tam, kde z něj plyne finanční výhoda.
Upgrade není jen změna souboru
Pokud kontrakt používá proxy, revize musí zahrnout inicializaci implementace, oprávnění k upgradu a kompatibilitu úložiště. OpenZeppelin upozorňuje, že proxy pracuje s jinými pravidly inicializace než běžný konstruktor a že změna layoutu úložiště může zničit význam stávajících hodnot. Ověřte každou plánovanou novou verzi automatickou kontrolou layoutu i testem migrace se skutečným stavem. Není-li upgrade povolen, musí produkt mít plán, co dělat při nalezené chybě v neměnné logice.
Před vydáním upgradované verze sepíšte rozdíly v chování a dopad na aktiva uživatelů. Připravte schvalovací krok, časové okno, monitor a případný návrat, pokud je technicky možný. Rollback není automaticky bezpečný: nová implementace mohla už zapsat stav, který stará neumí číst. U každé změny proto nejprve simulujte celý sled v izolovaném prostředí. Uživatelské rozhraní musí být sladěno s aktuální verzí kontraktu, jinak mohou lidé podepisovat akce s jiným významem, než ukazuje obrazovka.
Kombinujte různé druhy testů
Jednotkové testy ověřují konkrétní pravidla, vlastnostní testy procházejí kombinace vstupů a stavů, integrační testy spojují kontrakty, oracly a uživatelské volání. Statická analýza může odhalit podezřelé vzory, ale každý nález potřebuje kontext; čistý výstup nástroje není důkaz bezpečnosti. Testy nasazení musí ověřit počáteční role, konfiguraci a zveřejněný bytecode. Důležité jsou negativní případy: nepovolené volání, opakované vypořádání, přerušená transakce a neplatné údaje z oracle.
Pokud je hodnota nebo složitost vysoká, zajistěte nezávislou odbornou revizi s dostatečným časem na opravy a nové ověření. Ethereum připomíná, že audit nemůže zachytit každou chybu; je další vrstvou kontroly. Výstup musí jasně uvádět rozsah, commit, závažnost nálezů, stav oprav a zbylá rizika. „Auditováno“ bez těchto údajů je marketingové tvrzení, nikoli technický podklad. Po opravě musí reviewer potvrdit konkrétní změněný kód; nová funkce mimo původní rozsah vyžaduje nové posouzení.
Připravte provoz po nasazení
Bezpečnost nekončí publikací. Sledujte události změny rolí, upgrady, neobvyklé objemy převodů, odchylky oracle a pokusy o selhávající volání. Nastavte reakci: kdo vyhodnocuje alarm, kdo smí zastavit část systému a jak se komunikuje s uživateli. Nouzový mechanismus otestujte, včetně přístupu klíčů a skutečného času potřebného k zásahu. Plán má počítat i s kompromitací externí služby nebo chybou v uživatelském rozhraní.
Při incidentu uchovejte záznam relevantních transakcí, verzí a rozhodnutí. Neprovádějte improvizovaný upgrade bez kontroly důsledků pro stav a uživatele. Po vyřešení doplňte test, který zachytí příčinu, a aktualizujte model hrozeb. EXCOIN může pomoci se specifikací, testy, integrací a provozním plánem; konkrétní audit a tvrzení o bezpečnosti musí vždy odpovídat skutečnému kódu, rozsahu a nezávislému ověření. Praktickým cílem revize je sada důkazů a jasně přiznaných rizik před každým podpisem nasazovací transakce.
Nálezy proměňte v rozhodnutí o vydání
Každý nález zapište s reprodukčním postupem, dotčenou verzí, předpoklady útoku a odhadem dopadu. Rozlište chybu, která umožňuje ztrátu prostředků, od doporučení zlepšujícího čitelnost. Priorita má vycházet z možného dopadu a dosažitelnosti, ne z názvu analytického nástroje. U opravy uveďte commit, test potvrzující původní problém a test nového chování. Reviewer musí ověřit, že oprava nezměnila jinou bezpečnostní vlastnost. Pokud se nález přijme jako zbylé riziko, zaznamenejte vlastníka rozhodnutí, důvod a opatření, která omezují dopad. Neuzavírejte jej pouhým označením za nízkou prioritu.
Vydání má mít krátký, ale konkrétní seznam podmínek: souhlasná verze specifikace a kódu, úspěšné testy invariantů, potvrzené role a adresy, vyřešené kritické nálezy, naplánované sledování a schopnost zásahu. Někdo jiný než autor nasazovacího skriptu by měl před podpisem přečíst cílovou síť, adresu implementace a inicializační data. Po transakci porovnejte zveřejněný bytecode a konfiguraci s očekávaným stavem. Pokud se něco liší, zastavte další kroky a zjistěte proč. Tento poslední kontrolní bod je levnější než napravování chybné inicializace v produkci.
Uživatelům a partnerům sdělujte přesný rozsah provedené revize. Veřejně dostupná zpráva může pomoci důvěře, ale jen když nevytváří dojem garance. Uveďte datum, verzi a otevřené výjimky. Při změně kódu po revizi starý závěr automaticky nepřenášejte. Bezpečnost je průběžná odpovědnost vlastníka produktu, ne jednorázová položka v harmonogramu ani náhrada za dohled nad provozem.