Hackathony v krypto/web3: jak připravit odpovědný projekt bez zkratkovitosti
Hackathon je tlaková zkouška, ve které se ukáže technický talent, rozhodování pod stresem i schopnost týmu dodat minimum viable výsledek. V prostředí krypto, tradingu a web3 to však nestačí: odpově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 také před reálným světem.
Definice problému a přístup „impact first“
- Problémová věta: jednou–dvěma větami přesně definujte, kterou bolest řešíte (například 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í: regulatorní (sankce, licence), technická (finalita, poplatky), tržní (likvidita, oracles), etická (soukromí, zneužití).
Rozsah, milníky a „MVP bez podvádění“
- Definice MVP: ne „figma + video“, ale e2e tok na testnetu/mainnetu s reálnou transakcí/událostí a ověřitelným důkazem.
- Milníky: M1 – kostra kontraktu + unit testy; M2 – první volání přes UI/CLI; M3 – observabilita (logy, eventy); M4 – dokumentace a demo skript.
- Co záměrně vynechat: pokročilé optimalizace a „nice-to-have“ UI. Raději dodat bezpečné minimum pokryté testy.
Týmové role a odpovědnosti
- Tech lead: architektura, průřezová rozhodnutí, „no-go“ veto v otázkách bezpečnosti.
- Smart contract engineer: model stavu, kontrola oprávnění, testy a formální vlastnosti.
- Frontend/UX: stavové chyby, flow podepisování, vysvětlení rizik, „undo“ a revokace.
- DevOps/infra: 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, oracles). Usnadní to testování a omezí „blast radius“ chyb.
- Minimální oprávnění: princip least privilege na úrovni kontraktů, proxy a podpisů (session klíče, limity výdajů).
- 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ány rate-limitů, lokální cache a backoff strategie.
Hrozebný model: co se může pokazit
- Kontrakty: reentrancy, nedostatečná validace vstupů, nesprávné výpočty poplatků, overflow/underflow v custom matematice.
- Schvalování a přístup: neomezené approvals, chybějící limity, slabé role/guardy, neoprávněný delegatecall.
- Ekonomika: manipulace oracle, MEV (sandwich, backrun), likvidační smyčky, cenové disparity.
- 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“ u výplat.
- 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, připravte migraci a deprecation.
- Bezpečné matematické operace a saturace limitů; explicitní jednotky (decimály, bps, wei).
Testování: od unit po property-based
- Unit testy: pokrývají běžné scénáře, chybové stavy, parametrové hranice.
- Property-based: invariance (např. zachování hodnoty), monotónnost, limity.
- Fork testy: simulace reálných dat (pooly, oracles, 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.
- Výchozí limity: nikdy „unlimited“; denní/per-transakční stropy, doménové vázání (EIP-712).
- Revokace jedním klikem: pro session i approvals, s uživatelským návodem.
- Chybové stavy: předvídatelné, s návrhem řešení (navýšit limit, obnovit oracle, zkusit jinou cestu).
Data, soukromí a minimalismus
- Neveřejné informace neukládejte 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 s rate-limity a klíči.
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í aktiva/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 odpovědnost
- Možnosti zneužití: identifikujte potenciální zneužití (wash trading, obcházení sankcí, phishing) a navrhněte mitigace (limity, allowlist, monitoring).
- Inkluze a přístupnost: jednoduché texty, kontrasty, ovládání klávesnicí; vícejazyčná oznámení rizik.
- Udržitelnost: odhad nákladů (gas, infra), aby produkt nebyl neudržitelný mimo hackathon.
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) e2e ukázka, (3) bezpečnostní pojistky. Žádné „magické“ prokliká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 zkratkovitosti
- 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 odchylce parity wrapped aktiv.
- Bezpečné UX: varování při přechodu sítí, přesné popisy rizik a čas 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ů; předcházejte „sybil“ útokům a toxickým strategickým chováním.
- Rizikový fond: pokud je vhodné, naznačte pojišťovací mechanismus (treasury, slashing, cap na expozici).
Checklist před odevzdáním projektu
- Má MVP reálný on-chain tok s prokazatelným výsledkem?
- Jsou kritické funkce pod role/guardem a pokryty testy (včetně chybových stavů)?
- Existuje „kill-switch“, limity a revokace pro případ incidentu?
- Je dokumentace dostatečná na spuštění cizím člověkem do 10 minut?
- Máte metriky, chybové hlášení 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é milestone a priorita drobných oprav („papercuts“).
Odpovědnost je konkurenční výhoda
Odpovědný hackathonový projekt není nejdelší pitch ani nejbarevnější UI. Je to funkční, auditovatelný, reprodukovatelný a bezpečný kus softwaru s jasnou hodnotou a vědomým respektem k vlastním limitům. Když postavíte MVP na pevných zásadách – 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.
