První otázka: proč sdílený registr
Blockchain není univerzální náhrada databáze. Je užitečný, když na výsledku záleží více stranám, které nemají důvod svěřit správu společného záznamu jediné z nich. Pokud všechny zápisy i čtení provádí jedna organizace, bývá běžná databáze levnější, rychlejší a snáze opravitelná. Uvažovanou hodnotu proto formulujte jako konkrétní změnu důvěry: kdo může ověřit vlastnictví, pořadí kroků nebo vykonání pravidla a co by bez sdíleného stavu nemohl zjistit.
Příkladem může být proces s více účastníky, v němž se dnes informace porovnávají ručně a spor vzniká kvůli odlišným verzím záznamu. Není však samozřejmé, že zveřejnění transakcí tento spor vyřeší. Pořád je třeba určit identitu účastníků, význam událostí, opravu vstupní chyby a pravidla pro údaje, které na veřejný řetězec vůbec nepatří. První etapou by měla být mapa aktérů a jejich pobídek, nikoli volba tokenu.
Rozdělení odpovědnosti mezi řetězec a aplikaci
Architektura rozlišuje pravidla, která mají být společně ověřitelná, od části, kterou musí umět změnit provozovatel. Na řetězec patří jen data a operace, u nichž má veřejná či sdílená kontrola skutečnou hodnotu. Osobní údaje, rozsáhlé dokumenty a často se měnící obchodní text obvykle potřebují jiné úložiště a jasný režim přístupu. Odkaz nebo hash může prokázat vztah k dokumentu, ale sám neříká, že dokument byl správný ani kdo měl právo jej vytvořit.
Uživatelské rozhraní, vyhledávání, notifikace a analytika běží typicky mimo řetězec. Proto je třeba mít plán, jak se off-chain zobrazení synchronizuje se skutečným stavem a co uživateli ukáže při zpoždění. Převod mezi oběma světy je integrační hranice se stejnými otázkami jako jiné systémy: identifikátory, opakované doručení, změny schématu a oprava selhání. Návrh nemá skrývat tyto náklady pod slovem decentralizace.
Životní cyklus transakce a očekávání uživatele
Odeslání požadavku neznamená jeho konečné provedení. Transakce může čekat, selhat, být nahrazena nebo získat různou úroveň potvrzení podle sítě a použitého procesu. Rozhraní musí rozlišit stav vytvořeno, odesláno, potvrzeno a nezdařilo se. Člověk potřebuje vědět, kdy může bezpečně navázat další krok a kdy má počkat. Ethereum dokumentace popisuje transakce a související náklady na gas; konkrétní poplatky jsou proměnlivé a nelze je slibovat předem.
Při návrhu testujte slabé spojení, zamítnutí podpisu, nedostatek prostředků na poplatek i opakovaný pokus uživatele. Stejná obchodní operace nesmí vzniknout dvakrát jen proto, že první odpověď přišla pozdě. U kritického procesu stanovte, která událost je zdrojem pravdy a kdy se případ přesune k ručnímu vyřízení. Indexer nebo cache mohou zlepšit odezvu, ale nesmějí se vydávat za konečný stav, pokud jsou pozadu.
Peněženky, klíče a oprávnění
Největší provozní rozhodnutí často není volba sítě, nýbrž správa oprávnění. Kdo podepisuje transakce, kdo může měnit nastavení a co se stane při ztrátě klíče? Klíč poskytuje schopnost vykonat akci; jeho ochrana se proto musí řešit společně s rolí člověka, schvalováním a obnovou. U firemního procesu může být vhodné více podpisů nebo oddělení přípravy a schválení, ale konkrétní model vychází z hodnoty a rizika transakcí.
Uživatelská peněženka přináší jinou zkušenost než účet spravovaný službou. První dává přímou kontrolu držiteli, ale vyžaduje porozumění podpisu a obnově. Druhá může zjednodušit používání, současně však přesouvá odpovědnost za klíče na provozovatele. Obě varianty mají dopady na podporu, bezpečnost a případné regulatorní posouzení. Produkt nesmí nazývat řešení samoobslužným, pokud ve skutečnosti existuje správce schopný prostředky přesunout.
Smart kontrakty a hranice neměnnosti
Pravidlo vykonávané na řetězci má být malé, srozumitelné a testovatelné. Než vznikne kód, popište stavy, povolené přechody, role a invarianty: co nesmí platit nikdy, ani při chybném či nepřátelském volání. Veřejné funkce může zkoušet volat kdokoli, pokud síť umožňuje přístup. Bezpečnostní doporučení Ethereum proto zdůrazňují kontrolu oprávnění, validaci vstupu a pozorovatelnost kritických událostí. Kontrakt nevytváří pravdivost externího údaje; pro takový údaj je nutné řešit zdroj a důvěru v něj.
Nasazený kontrakt může být obtížné nebo nemožné jednoduše opravit. Pokud návrh připouští upgrade či nouzové pozastavení, je nutné otevřeně popsat, kdo tyto pravomoci drží a jak je kontroluje. Možnost změny může snížit riziko chyby, ale zároveň vytváří nové místo důvěry. Nezávislé odborné bezpečnostní posouzení je zvlášť důležité pro kód, který může držet významnou hodnotu; tato stránka však netvrdí, že EXCOIN takový audit samo provádí nebo má konkrétní certifikaci.
Napojení na běžné systémy
Blockchainová aplikace málokdy stojí sama. Potřebuje identitu, účetnictví, obchodní systém, správu dokumentů nebo zákaznickou podporu. Pro každé propojení určete, zda čte potvrzený stav, spouští novou operaci nebo pouze informuje uživatele. Pokud se některá část opozdí, musí být možné rozdíl dohledat a srovnat. Stav na řetězci nelze bez vysvětlení přepsat jen proto, aby odpovídal interní tabulce.
Při příjmu událostí plánujte opakování, změnu pořadí a dočasnou nedostupnost poskytovatele uzlu. Integrace má ukládat číslo bloku či jiný vhodný referenční údaj, verzi parseru a způsob přepočtu po opravě. Monitoring sleduje zpoždění a nesoulad, nikoli pouze dostupnost HTTP endpointu. Užitečný prototyp vyzkouší i obnovu po výpadku indexeru.
Bezpečnost, náklady a právní kontext
Riziko se netýká jen smart kontraktu. Zranitelná peněženka, podvržené rozhraní, špatná správa přístupů nebo chybný off-chain proces mohou obejít správně napsané pravidlo. Před spuštěním je nutné modelovat hrozby, testovat kritické cesty, oddělit oprávnění a připravit reakci na incident. Výsledek kontroly musí být dohledatelný; automatický skener není náhradou za posouzení logiky produktu. Pro obecný přehled rizik slouží veřejné bezpečnostní materiály Ethereum.
Celkové náklady zahrnují vývoj, provoz uzlů nebo poskytovatele, transakční poplatky, monitoring, podporu a budoucí změny. U veřejné sítě záleží i na přístupu uživatelů k peněžence a předvídatelnosti transakčních nákladů. Regulatorní otázky se posuzují podle skutečného produktu, dat, jurisdikce a rolí účastníků; technický návrh právní posouzení nenahrazuje. Pokud projekt pracuje s hodnotou nebo finančním instrumentem, je třeba tuto oblast otevřít už v discovery.
Dodávka a rozhodnutí, zda pokračovat
První etapa má odpovědět, zda blockchain přináší prokazatelnou výhodu proti jednodušší variantě. Výstupem může být mapa důvěry, tok transakce, hranice dat, srovnání provozních nákladů a malý experiment na testovací síti. Akceptace by měla zahrnovat chybné vstupy, zpoždění i obnovu, nikoli jen úspěšnou demonstraci. Pokud hypotéza nevydrží, je správným výsledkem doporučení použít jinou architekturu.
Teprve potom se rozhoduje o plném produktu. Potřebuje vlastníka pravidel, bezpečnostní plán, pravidla aktualizací, podporu uživatelů a srozumitelný postup při incidentu. V nabídce mají být jasně odděleny implementace aplikace, vývoj kontraktu, externí audit a případné právní služby. Bez ověřených podkladů neslibujeme konkrétní síť, rychlost, integraci ani dosažený výsledek klientského projektu.
Častou otázkou je, zda je možné projekt nejprve provozovat bez řetězce a sdílený zápis přidat později. Je to možné, pokud datový model už nyní zaznamenává vlastníka, čas, důvod změny a jednoznačné identifikátory. Jinak by pozdější migrace přenášela i nejasnosti, které současná aplikace neumí vysvětlit. Druhou otázkou je volba veřejné a uzavřené sítě. Rozhoduje počet nezávislých ověřovatelů, požadovaná otevřenost, správa oprávnění a náklady na provoz, nikoli samotné označení technologie.