Kdy má pravidlo běžet na řetězci
Smart kontrakt má smysl pro pravidlo, jehož provedení potřebují nezávislí účastníci sami ověřit. Může řídit převod, přístup nebo stav společného procesu. Pokud jediný provozovatel může měnit všechny vstupy a výstupy, samotné nasazení kontraktu důvěru významně nezmění. Nejdříve proto určete účastníky, jejich práva, obchodní události a informaci, kterou musí být možné zpětně prokázat. Zvažte také běžnou aplikaci s auditní stopou jako srovnávací variantu.
Ne každé pravidlo patří do neměnného prostředí. Často upravované sazby, texty či výjimky mohou potřebovat správu mimo kontrakt, s jasným postupem schválení. Data z vnějšího světa vyžadují důvěryhodný zdroj; kontrakt je neumí nezávisle ověřit jen proto, že je zapíše. V dobrém návrhu je proto hranice mezi řetězcem a aplikací co nejužší, pochopitelná a podložená konkrétním důvodem.
Specifikace před kódem
Prvním výstupem je model stavu: jaká operace může následovat, kdo ji smí vyvolat a co se musí stát při odmítnutí. U převodu hodnoty je třeba popsat zůstatky, rezervace, storno, časové podmínky a případ, kdy protistrana nespolupracuje. U rolí zaznamenejte, kdo je přiděluje a kdo může pravomoc odebrat. Slovní popis doplňte tabulkou přechodů a příklady chybných volání. Tím se ukáže, zda navržené rozhraní vyjadřuje skutečný obchodní proces.
Invarianty jsou pravidla, která musí platit po každé operaci: například že celkové množství evidované hodnoty odpovídá definovaným tokům nebo že neautorizovaná role nikdy nepřevezme správu. Jejich formulace pomáhá testování i případnému formálnějšímu ověření. Pokud tým nedokáže invariant srozumitelně vysvětlit vlastníkovi produktu, nemá se jeho implementace schovat do technických detailů.
Oprávnění, správa a nouzové kroky
Veřejné funkce mohou být volány libovolným účastníkem s přístupem k síti. Každá změna stavu proto potřebuje explicitní kontrolu oprávnění, validaci vstupu a reakci na nečekané pořadí volání. Privilegované operace, například změna parametrů, upgrade nebo zastavení, vyžadují zvláštní správu. Rozhodněte, zda se použije více podpisů, časový odklad nebo oddělené role. Vyšší počet podpisů sám o sobě není řešením, pokud podpisy ovládá jedna osoba nebo neexistuje postup při ztrátě klíče.
Nouzová pauza může omezit dopad chyby, ale současně dává jejím správcům významnou moc. Uživatel musí rozumět, co lze zastavit, co zůstane dostupné a jak se služba obnoví. Zvažte i postup, když se k oprávněné správě nelze dostat: kdo rozhodne o nápravě a jak bude komunikovat. Správa kontraktu je součást produktu a její pravidla mají být viditelná dříve než nasazení.
Interakce a typické bezpečnostní chyby
Nebezpečí vzniká zejména na hranicích: kontrakt volá jiný kontrakt, přebírá cenu z vnějšího zdroje nebo umožňuje nečekanou kombinaci funkcí. Důležité jsou pořadí aktualizace stavu a externího volání, aritmetika, kontrola návratových hodnot a obchodní logika, kterou automatický skener nezná. Veřejný přehled OWASP pomáhá strukturovat rozhovor o slabinách, ale nenahrazuje analýzu konkrétního toku peněz a oprávnění.
Pro každý tok nakreslete útočníka, jeho schopnosti a motivaci. Může ovlivnit pořadí transakcí, dodat zpožděný údaj, rozdělit operaci do více kroků nebo zneužít administrátorský klíč? Testování má zahrnout i předpoklady o integracích a uživatelském rozhraní. Správný kontrakt nezachrání aplikaci, která požádá o podpis jiné akce, než jakou uživateli ukazuje.
Testy podle vlastností, ne pouze scénářů
Základní testy potvrzují běžný průchod, odmítnutý vstup a hranice částek. Větší hodnotu ale přinesou vlastnostní testy, které zkoušejí mnoho pořadí operací, krajní hodnoty a kombinace rolí. U změn pravidel je důležitá regresní sada navázaná na invarianty. Testovací síť pomůže vyzkoušet skutečný tok podpisů a nasazení, ale neposkytuje stejné ekonomické pobídky ani provozní podmínky jako produkce.
U vysoce rizikového kontraktu lze zvážit formálnější metody pro konkrétní vlastnosti. Ethereum dokumentace popisuje formální verifikaci jako způsob dokazování požadovaného chování vůči definované specifikaci. Důkaz je však tak užitečný, jak správné jsou jeho předpoklady. Čas na nezávislou kontrolu, opravu nálezů a opakované ověření musí být součástí plánu před nasazením. EXCOIN netvrdí, že samo poskytuje nezávislý audit.
Upgrade a migrace
Možnost měnit logiku po nasazení je technická i organizační volba. Neměnný kontrakt omezuje pravomoc správce, ale chybu lze obtížně opravit. Upgrade mechanismus usnadní změnu, zato vytváří nové privilegium a riziko chybného přechodu stavu. U každé varianty popište, kdo změnu navrhuje, schvaluje a ověřuje a co se stane s již vydanými závazky. Uživatelé mají vědět, zda pravidla, která dnes přijímají, může někdo později změnit.
Migrační plán musí pokrýt kompatibilitu dat, staré adresy, otevřené operace, dostupnost historie a způsob návratu při selhání. Simulujte migraci s reprezentativním stavem před ostrým krokem. Vnější systémy, které sledují události, musí umět změnu verze rozpoznat. Dokumentace upgrade není administrativní příloha; chrání návazné aplikace i uživatele před tichou změnou významu.
Nasazení, monitoring a reakce
Před nasazením se kontroluje přesný zdrojový kód, konfigurace, síť, adresy správců a postup podpisu. Výsledná adresa a ověřený kód se zaznamenají tak, aby bylo možné později zjistit, co skutečně běží. Kritické události se sledují i mimo řetězec: změny rolí, mimořádné objemy, pozastavení a selhání integračního indexeru. Monitoring není jen upozornění; musí mít člověka, který ví, co na ně navazuje.
Incidentový plán určí, kdo může pozastavit funkci, jak se informují uživatelé, co lze bezpečně obnovit a kdy se zapojuje externí expert. Po vydání je nutné sledovat také nové poznatky o použitých knihovnách a závislostech. Jestliže je pro provoz potřeba pravidelný zásah, zohledněte ho v rozpočtu a odpovědnostech. Není správné popsat kontrakt jako bezúdržbový jen proto, že jeho bytecode zůstává na řetězci.
Co má obsahovat poptávka a výstup
Pro první posouzení popište účastníky, hodnotu nebo právo, s nímž má kontrakt pracovat, zdroj vnějších údajů, očekávaný objem a nejhorší přijatelnou chybu. Přidejte otázku, zda mají být pravidla měnitelná a kdo má tuto změnu řídit. Nemusíte předepisovat knihovny či řetězec. Dodavatel by měl nejprve ověřit, zda část procesu nemůže bezpečněji zůstat mimo řetězec.
Srozumitelný výstup obsahuje specifikaci stavů a rolí, zdrojový kód, testy, postup nasazení, seznam předpokladů, provozní příručku a záznam otevřených rizik. Externí audit, pokud je požadován, má jasně určeného nezávislého autora a rozsah; nelze ho nahradit slovem „bezpečné“. Před převzetím je třeba určit, kdo drží klíče, kdo sleduje provoz a kdo může v mimořádné situaci rozhodnout.
Jak poznat, že je kontrakt připraven k nasazení? Nestačí, že prošly automatické testy. Vlastník pravidel musí rozumět tomu, co bude nevratné, jaké výjimky budou řešeny mimo řetězec a kdo drží správní pravomoci. Technický tým má doložit výsledky testů, nálezy kontrol, opravy a přesnou verzi kódu. Provozní tým musí umět reagovat na upozornění a nacvičit postup při ztrátě přístupu. Pokud některá z těchto odpovědí chybí, je lepší posunout nasazení než přenést nejasnost do systému, v němž může chyba poškodit skutečné uživatele.
Častý omyl je předpoklad, že zveřejnění zdrojového kódu samo zaručí důvěru. Veřejný kód umožní kontrolu, ale uživatelé potřebují také vědět, že odpovídá nasazené verzi, že rozumí správním rolím a že aplikace ukazuje skutečnou operaci před podpisem. Tato kontrola propojuje technické, produktové i provozní rozhodnutí.