Hackathony v krypto/web3: jak připravit zodpovědný projekt bez zkratek
Hackathon je tlaková nádoba, ve které se ukáže technický talent, rozhodování pod stresem i schopnost týmu doručit minimum viable výsledek. V prostředí krypto, tradingu a web3 to však nestačí: zodpovědný projekt musí kromě funkční ukázky respektovat bezpečnost, soukromí, právní rámce, etiku a dlouhodobou udržitelnost. Tento text je praktický manuál, který vám pomůže připravit projekt tak, aby obstál nejen před porotou, ale i před reálným světem.
Definice problému a „impact first“ přístup
- Problémová věta: jednou až dvěma větami přesně definujte, jaký problém řešíte (např. bezpečné mikroplatby bez KYC pro hry, auditovatelné PoR pro malé custody, levný on-chain settlement pro RFQ trhy).
- Hypotéza hodnoty: proč je řešení lepší než stávající stav? Kvantifikujte úsporu nákladů, latenci, riziko, UX kroky.
- Omezení: regulační (sankce, licence), technické (finalita, poplatky), tržní (likvidita, oracly), etické (soukrví, zneužití).
Rozsah, milníky a „MVP bez podvádění“
- Definice MVP: ne „figma + video“, ale end-to-end tok na testnetu/mainnetu s reálnou transakcí/událostí a verifikovatelným důkazem.
- Milníky: M1 – základ kontraktu + unit testy; M2 – první volání přes UI/CLI; M3 – observabilita (logy, eventy); M4 – dokumentace a demo skript.
- Co vědomě vynechat: pokročilé optimalizace a „nice-to-have“ UI. Raději dodat bezpečné minimum s pokrytím testy.
Týmové role a odpovědnosti
- Tech lead: architektura, průřezová rozhodnutí, „no-go“ veto při bezpečnosti.
- Smart contract inženýr: model stavu, kontrola oprávnění, testy a formální vlastnosti.
- Frontend/UX: chybové stavy, podpisové flow, vysvětlení rizik, „undo“ a revokace.
- DevOps/infrastruktura: testnety, klíče, CI, monitoring, spolehlivost RPC.
- Risk & compliance: hrozby, limity, jurisdikce, licence, otevřené zdroje (licence kódu a dat).
Architektura: jednoduchá, auditovatelná, rozšiřitelná
- Modularita: jádro + plug-in moduly (policy, přístup, oracly). Usnadní testování a omezí „blast radius“ chyb.
- Minimální oprávnění: princip least privilege na úrovni kontraktů, proxy a podpisů (session klíče, spending limity).
- Deterministické nasazení: verzování, adresy, migrace; zachovejte reprodukovatelnost (commit hash, build).
Výběr stacku a infrastruktury
- Řetězec a L2: podle finality, poplatků, nástrojů a dostupnosti testnetu. Zvažte modularitu a dostupnost oraclů/mostů.
- Oracly a data: definujte zdroje, latenci a fallback politiku; počítejte s výpadky feedů.
- RPC a indexace: redundantní poskytovatelé, plánování rate-limitů, lokální cache a backoff strategie.
Model hrozeb: co se může pokazit
- Kontrakty: reentrancy, nedostatečná kontrola vstupů, nesprávné výpočty poplatků, overflow/underflow v custom math.
- Schvalování a přístup: neomezené approvaly, chybějící limity, slabé role/guardy, neoprávněné delegatecall.
- Ekonomika: manipulace oracle, MEV (sandwich, backrun), likvidační smyčky, cenové mezery.
- UX útoky: phishingové domény, slepé podepisování, matoucí oprávnění.
Bezpečnostní zásady pro smart kontrakty
- Checks-Effects-Interactions, reentrancy guard, „pull over push“ pro výplaty.
- Oprávnění: onlyOwner/onlyRole nahraďte moduly a časovými zámky; kritické funkce pod multisig + timelock.
- Upgrade pattern: pokud používáte proxy, definujte upgrade governance a „kill-switch“. Pokud ne, počítejte s migrací a deprecation.
- Bezpečné matematické operace a saturace limitů; explicitní jednotky (desetinné čárky, bps, wei).
Testování: od unit po property-based
- Unit testy: pokrývají běžné cesty, chybové stavy, hranice parametrů.
- Property-based: invariance (např. zachování hodnoty), monotónnost, limity.
- Fork testy: simulace na reálných datech (pooly, oracly, mempool scénáře).
- Fuzzing: náhodné vstupy, mutace calldata, nestandardní pořadí volání.
UX a bezpečné podepisování
- Transparentní karta oprávnění: srozumitelně „Kdo/Co/Kolik/Kdy“. Zvýrazněte expiraci a limity.
- Přednastavené limity: nikdy „unlimited“; denní/per transakce stropy, doménové vázání (EIP-712).
- Revokace jedním kliknutím: pro sessions i approvaly, s návodem pro uživatele.
- Chybové stavy: předvídatelné s návrhem řešení (zvýšit limit, obnovit oracle, zkusit jinou cestu).
Data, soukromí a minimalismus
- Neverejné informace nedávejte on-chain; používejte hashované závazky a odkazujte na off-chain úložiště (s expirací).
- Telemetrie: sbírejte pouze anonymizované metriky; vysvětlete, co a proč logujete.
- Přístup k údajům: jasná SLA, retence a mazání; otevřené API by mělo mít rate limit a klíče.
Licencování, IP a „open-core“ strategie
- Licence kódu: zvolte OSI-kompatibilní licenci (MIT/Apache-2.0) nebo recipročně omezující podle cíle. Uveďte ji v hlavičce souborů.
- Právní rizika: nepoužívejte cizí assety/data bez práv; respektujte ochranné známky a názvy tokenů.
- Open-core: jádro otevřené, provozní moduly a infrastruktura mohou být „source-available“ pro hackathon demo.
Etika a zodpovědnost
- Misuse-cases: identifikujte možná zneužití (wash trading, obcházení sankcí, phishing) a navrhněte mitigace (limity, allowlist, monitoring).
- Inkluze a přístupnost: jednoduché texty, kontrast, klávesnice; vícejazyčná oznámení rizik.
- Udržitelnost: odhad nákladů (gas, infrastruktura), aby byl produkt udržitelný i po hackathonu.
Observabilita, logy a metriky
- On-chain eventy: emitujte důležité události s identifikátory (policyId, requestId, verze).
- Off-chain logy: korelační ID napříč frontendem, backendem a relayerem.
- Metriky: úspěšnost transakcí, čas do finality, reject rate policy, využití limitů, incidenty MEV.
Demo, skript a „story“
- Demo skript: tři kroky – (1) problém, (2) end-to-end ukázka, (3) bezpečnostní pojistky. Žádné „magické“ překlíkávání.
- Fallbacky: ukažte, co se stane, když oracle/RPC vypadne (smysluplná hláška, pauza, retry).
- Měřitelný výsledek: čísla před/po (poplatky, latence, dopad) a odkazy na block explorer/testnet.
Dokumentace a reprodukovatelnost
- README: co projekt dělá, architektura, jak spustit (jeden příkaz), jak testovat (příklady), adresy kontraktů.
- Architektonický přehled: diagram, sekvenční kroky, rizika a rozhodnutí s alternativami.
- Bezpečnostní příloha: threat model, známá omezení, doporučení pro produkční nasazení.
Cross-chain a interoperabilita bez zkratek
- Model důvěry: jasně uveďte, zda používáte custodial wrapping, light klienta, optimistický důkaz nebo IBC-like kanál.
- Limity objemů: denní stropy přes mosty, alarmy při odchýlce parity wrapped aktiv.
- Bezpečné UX: varování při přechodu sítí, přesné popisy rizik a doby finality.
Ekonomika protokolu: poplatky, incentivy, riziko
- Model poplatků: vysvětlete, kdo platí (uživatel, dApp, sponzor) a proč je to udržitelné.
- Incentivy: odměňování relayerů/validatorů; zabraňte „sybil“ útokům a toxickým strategickým chováním.
- Risk fond: pokud je vhodné, naznačte pojistný mechanismus (treasury, slashing, limit expozice).
Checklist před odevzdáním projektu
- Má MVP reálný on-chain tok s prokazatelným výsledkem?
- Jsou kritické funkce pod rolemi/guardy a testy (včetně chyb)?
- Existuje „kill-switch“, limity a revokace pro případ incidentu?
- Je dokumentace dostatečná pro spuštění cizím člověkem do 10 minut?
- Máte metriky, chybové hlášky a odkazy na explorer/logy v README?
- Jsou jasně uvedeny licence a právní omezení použití?
Po hackathonu: cesta k produkci
- Audit-ready roadmap: refaktor, coverage > 90 %, odstranění zbytečných privilegovaných cest.
- Bezpečnostní politika: bug bounty, zveřejnění zranitelností, postup při incidentu.
- Komunitní zpětná vazba: RFC, issue tracker, otevřené milníky a priorita „papercuts“.
Zodpovědnost je konkurenční výhoda
Zodpovědný hackathon projekt není nejdelší pitch ani nejbarevnější UI. Je to funkční, auditovatelný, reprodukovatelný a bezpečný kus softwaru s jasnou hodnotou a znalostí vlastních limitů. Když postavíte MVP na pevných základech – minimální oprávnění, testy, transparentní architektura, etika a soukromí – vyhráváte dvakrát: u poroty dnes a u uživatelů zítra.
