Simulace transakcí před podpisem: Základní strategie řízení finančních rizik

Proč simulovat transakce před podpisem

Simulace transakcí před podpisem je proces, při kterém se navrhovaná transakce provede „nanečisto“ vůči aktuálnímu stavu sítě, aniž by byla publikována na blockchainu. Cílem je předvídat výsledek (zůstatky, přesuny tokenů, změny ve stavu smluv, spotřebu plynu, chybové kódy) a tím snížit riziko ztráty prostředků, podvodu nebo neočekávaných nákladů. V prostředí Krypto, trading & Web3 se jedná o klíčový bezpečnostní i UX prvek, který dokáže odhalit skryté schémata odčerpání prostředků, zásadní selhání (revert), neviditelná approvals či manipulaci s cenou přes MEV.

Co přesně je simulace a co není

Simulace není pouze odhad poplatku za plyn. Jedná se o deterministické provedení tranzitivních volání, která by v reálu nastala při provedení transakce – včetně vnořených volání, převodů ETH a tokenů, emitovaných událostí, vytváření nových smluv a změn v storage. Simulace nic nepublikuje do mempoolu, proto nevyvolává MEV reakce ani finalizaci. Zároveň však není věštěním budoucnosti: nedokáže garantovat identický výsledek v prostředí měnícího se stavu, konkurenčních transakcí či externích dat (např. oracly).

Jak simulace funguje na úrovni EVM

• Lokální provedení volání: Peněženka nebo backendový uzel vytvoří volání se stejnými parametry from, to, value, data, gas a max fee a spustí jej v režimu, který nezachovává změny.
• Call trace a state diff: Výstupem je sled vnořených volání (call tree), návratové kódy, logy událostí, dočasné změny v storage a delta zůstatků účtů a tokenů.
• Fork hlavní sítě: Pokročilejší nástroje spouští simulaci na „forknutém“ stavu sítě se stejným blokem, čímž maximalizují shodu se skutečnou sítí bez zápisu.
• Detekce chyb: Zachycují se důvody revert, nedostatek plynu, neplatné podpisy, chybné calldata, konflikt nonce či insufficient liquidity.

Nejčastější rizika, která simulace odhalí

• Skryté přesuny a odčerpání prostředků: Smlouva volá další smlouvy, které přesouvají aktiva na nečekané adresy, případně využívají delegatecall ke zneužití oprávnění volajícího.
• Nevýhodná approvals a permit mechanismy: Simulace odhalí, že podpisem udělujete neomezená oprávnění (allowance = uint256 max) u ERC-20 nebo setApprovalForAll u NFT kolekcí.
• Reentrancy a logika poplatků: Ačkoliv simulace sama nemusí odhalit všechny reentrancy scénáře, call trace často identifikuje podezřelé sekvence „transfer → externí volání → další transfer“.
• DEX obchod za nevýhodných podmínek: Výpočet výsledného množství, price impact, skluzu a minimální přijatelné hodnoty po poplatcích a router hops.
• Nedostatek likvidity nebo nevhodná cesta: Simulace upozorní na neexistující pool, zmrazené tokeny či blokované metody transfer (např. fee-on-transfer tokeny).
• Nástrahy u mintování NFT: Falešné mintovací stránky využívající podpis permit nebo „sepolia/holesky“ switch; simulace ukáže, že nic skutečného se nemintuje nebo že hodnota jde útočníkovi.

Limity simulace a kdy si dát pozor

• Časový posun stavu: Mezi simulací a skutečným zařazením do bloku se stav může změnit – přijdou jiné transakce, změní se cena v poolech nebo u oraclů.
• MEV a front-running: Simulace nepredpoví, že vaši transakci někdo předběhne a změní podmínky (např. vyprázdnění poolu, posun oracle).
• Externí zdroje dat: Off-chain oracly a VRF generátory mohou mít výsledky v okamžiku zařazení jiné než v momentě simulace.
• Rozdíly v RPC: Ne všechny uzly implementují stejně rozšiřené RPC metody pro tracing; výsledky se mohou lišit v detailech.

Architektury simulace: kde ji implementovat

• V peněžence (client-side): Rychlá odezva, soukromí uživatele, ale omezené zdroje a náročnost udržování lokálního stavu.
• Backend s forknetem: Přesnější výsledky, snadnější agregace heuristik, ale vyžaduje infrastrukturu (uzly, fork síť, cache bloků a stavů).
• Hybrid: Lehká předsimulace v peněžence a potvrzení v backendu před podpisem nebo odesláním do bundleru.

Simulace u účtů s abstrakcí (Account Abstraction)

V kontextu ERC-4337 a smart peněženek se nesimuluje pouze transakce, ale i UserOperation tok: validace, pravidla paymastera, factory deploy přes CREATE2, hooky, session keys a levné „batched“ akce. Správná simulace musí prověřit, jak se userOp chová v bundleru, jaké poplatky zaplatí, zda nedojde k revertu v validateUserOp nebo v execution, a jestli paymaster neukončí operaci stop-loss pravidly.

Simulace při DEX a DeFi operacích

• AMM výpočet výsledku: Na základě rezerv poolu, poplatků a cesty přes více poolů odhadněte amountOut a price impact.
• Limit a TWAP příkazy: Zkontrolujte, zda transakce splní limitní podmínky při aktuálním stavu a zda neporuší ochranné hranice minOut.
• Leveraged a lending protokoly: Simulujte otevření/uzavření pozice, LTV, health factor a riziko likvidace po změně ceny.
• Výnosové strategie: Ověřte kompatibilitu vkládaných tokenů (např. deposit token vs. wrapped varianta) a zda odměny nejsou blokovány vestingem.

Detekční heuristiky nad call trace

• Neobvyklí příjemci: Adresy mimo whitelist protokolu nebo nově vytvořené peněženky.
• Neomezená oprávnění: approve s maximální hodnotou, setApprovalForAll na neznámé trhy, podezřelé permit podpisy.
• Privilegovaná volání: owner-only funkce volané přes delegatecall nebo proxy struktury bez správné verifikace.
• Rozdíl mezi očekávaným a simulovaným zůstatkem: Záporné diference aktiv, které uživatel neočekává (např. úbytek všech NFT).

Praktické metriky, které by měla peněženka zobrazovat

• Před/po zůstatky: ETH a všechny dotčené tokeny s přesností na desetinná místa a s tickerem.
• Příjemci a částky: Seznam adresátů s přiřazenými částkami a důvodem (swap, poplatek, dar, mint).
• Spotřeba plynu a poplatky: Odhad gasUsed, base fee, priority fee, celkový náklad v ETH i v ekvivalentu fiat měny.
• Riziková varování: Výrazná bannerová upozornění na approvals, NFT setApprovalForAll, podezřelé delegatecall či neznámý bytecode.
• Srozumitelný popis akce: Dekódování calldata do „lidského“ jazyka: co se má stát a proč.

Implementační postup pro vývojáře

1. Získejte přesný stav: Použijte head blok, snapshot a případně forknete síť pro konzistenci.
2. Spusťte trace: Využijte callTracer a stateDiff pro plná vnořená volání a změny v storage.
3. Normalizujte tokeny: Detekujte ERC-20/721/1155, zvláštnosti fee-on-transfer a rebasing mechaniky.
4. Heuristiky a pravidla: Přidejte detektory pro approvals, neznámé implementace proxy, nové adresy a známé škodlivé vzory.
5. Renderování výsledku: Zobrazte před/po stavy, příjemce, varování a rozpis poplatků.
6. Bezpečnostní sandboxy: Blokujte podpis, pokud heuristiky překročí rizikový práh, nebo vyžadujte výslovné „pokračovat i tak“.

Simulace na různých sítích a L2

Na rollupech a L2 je důležité zohlednit čas finality, mechaniky sekvenzerů, poplatky za data a specifika mostů. Při cross-chain akcích simulujte obě strany – odesílající i přijímající – a upozorněte uživatele na latenci a rizika nedoručení zpráv.

Propojení se snižováním MEV rizik

Simulace sama o sobě MEV neeliminuje, ale spolu s ochrannými kanály odesílání (soukromé mempooly, objednávkové relaye) a nastavením skluzu snižuje pravděpodobnost front-runningu či sandwich útoků. Zobrazujte výstrahu, pokud je transakce citlivá na skluz a prochází volatilními pooly.

Doporučené zásady pro uživatele

• Nikdy nepodepisujte „naslepo“: Pokud peněženka nezobrazuje simulaci, buďte zvlášť opatrní u approvals a neznámých kontraktů.
• Kontrolujte příjemce: Ujistěte se, že v simulaci figuruje pouze známé adresy protokolu, nikoli nově vytvořené peněženky.
• Omezujte oprávnění: Preferujte omezené allowance a pravidelné revoke před neomezenými schváleními.
• Dávejte pozor na varování: Pokud simulace hlásí pokles zůstatku tokenu, který „neměl odejít“, transakci nepodepisujte.
• Opatrně u sign-in a permit podpisů: Ne každý podpis odesílá transakci, ale některé podpisy mohou udělovat přístup k aktivům.

Doporučené zásady pro vývojáře peněženek a protokolů

• Simulace vždy zapnutá: Žádný podpis bez přehledu dopadu na zůstatky a stavy.
• Jasná vizualizace: Kontrastní varování, barevné zvýraznění diffů a podrobný rozpis transferů.
• Přirozený jazyk: Místo hexa čitelné věty s názvy funkcí a parametrů.
• Nezávislé RPC a redundance: Ověření proti více uzlům, aby se minimalizovaly falešné pozitivy/negativy.
• Bezpečnostní politiky: Blokování známých škodlivých podpisů, denylist adres, rate-limit podpisů s vysokým rizikem.

Příklady situací, kde simulace zachrání kapitál

• Phishing dApp: Transakce vypadá jako „claim airdrop“, ale simulace odhalí transferFrom všech vašich NFT na útočníka.
• „Lepší“ swap: Router slibuje výhodnější kurz, ale simulace ukáže vysoký poplatek a horší amountOut po dvou hopích.
• Nákladná interakce: Interakce s kontraktem bez optimalizace plynu, simulace odhalí extrémní gasUsed a doporučí změnu parametrů.
• Chybný podpis u AA: UserOperation by prošel validací, ale fallback hook způsobí revert v exekuci – simulace to zachytí.

Metodika hodnocení rizika

• Skóre kontraktu: Věk, audit, počet interakcí, známé incidenty.
• Skóre transakce: Počet a typy transferů, nové approvals, proxy/delegatecall, netypické tokeny.
• Kontext sítě: Volatilita base fee, aktivita MEV, hloubka likvidity na trase.

UX a komunikace výsledků

Simulaci je třeba přeložit do srozumitelného jazyka: „Po podpisu ztratíte 125,3 USDC a získáte 0,0382 ETH. Udělujete neomezené oprávnění kontraktu X utrácet váš USDC. Doporučujeme oprávnění snížit nebo transakci zrušit.“ Takový popis je hodnotnější než surové logy, protože vede ke správnému rozhodnutí.

Best practices při integraci do trading nástrojů

• Před každým odesláním příkazu: Povinná