Simulace transakcí v blockchainových sítích

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 se publikovala na blockchain. 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 nečekaných nákladů. V prostředí Krypto, trading & Web3 jde o klíčový bezpečnostní i UX prvek, který dokáže odhalit skryté schémata odčerpání prostředků, závažné selhání (revert), neviditelné approvals či manipulaci s cenou přes MEV.

Co přesně je simulace a co není

Simulace není jen odhad poplatku za plyn. Je to deterministické provedení tranzitivních volání, která by reálně nastala při vykonání transakce – včetně vnořených volání, přenosů ETH a tokenů, emitovaných událostí, vytváření nových smluv a změny storage. Simulace nic nepublikuje do mempoolu, proto nevyvolává MEV reakce ani finalizaci. Současně však nejde o věštění budoucnosti: nedokáže garantovat identický výsledek při měnícím se stavu, konkurenčních transakcích či externích datech (např. oracly).

Jak simulace funguje na úrovni EVM

Lokální provedení volání: Peněženka nebo backendový uzel vytvoří call se stejnými parametry from, to, value, data, gas a max fee a spustí jej v režimu, který neukládá 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 ve 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 sítí bez zápisu.
Detekce chyb: Zachytávají se důvody revert, nedostatek plynu, neplatné podpisy, chybné calldata, kolize 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 ukáže, že podpisem udělujete neomezená oprávnění (allowance = uint256 max) pro ERC-20 nebo setApprovalForAll pro NFT kolekce.
Reentrancy a logika poplatků: Ačkoli simulace sama o sobě neprokáže všechny reentrancy scénáře, call trace často odhalí 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ího přijatého množství po poplatcích a router hopích.
Nedostatek likvidity nebo špatná cesta: Simulace upozorní na neexistující pool, zmrazené tokeny či blokované metody transfer (např. fee-on-transfer token).
Nástrahy při mintování NFT: Falešné mint stránky využívající podpis permit nebo „sepolia/holesky“ přepínače; 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á odchylka stavu: Mezi simulací a reálný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 nepředpoví, že vaši transakci někdo předběhne a změní podmínky (např. vyprázdní pool, posune oracle).
Externí zdroje dat: Off-chain oracly a VRF generátory mohou mít výsledky v okamžiku zařazení transakce jiné než při simulaci.
Režijní rozdíly RPC: Ne všechny uzly implementují identicky rozšíř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 na 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ání, cache bloků a stavů).
Hybrid: Lehká předsimulace v peněžence a potvrzení na backendu před podpisem nebo odesláním do bundleru.

Simulace při účtech s abstrakcí (Account Abstraction)

V kontextu ERC-4337 a smart peněženek se nesimuluje pouze transakce, ale i UserOperation tok: validace, pravidla paymaster, deploy factory přes CREATE2, hooky, session keys a levné „batched“ akce. Správná simulace musí ověřit, jak se userOp chová v bundleru, jaké poplatky zaplatí, zda nedojde k revertu v validateUserOp nebo během execution a zda paymaster nekončí 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, zda vkládané tokeny jsou kompatibilní (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 čerstvě 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é rozdíly aktiv, které uživatel neočekává (např. úbytek všech NFT).

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

Předchozí/późdější 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řidruženými částkami a důvodem (swap, fee, donation, mint).
Spotřeba plynu a poplatky: Odhad gasUsed, base fee, priority fee, celkové náklady v ETH i ve fiat ekvivalentu.
Riziková varování: Výrazná bannerová upozornění na approvals, NFT setApprovalForAll, podezřelé delegatecall či neznámý bytecode.
Čitelný popis akce: Dekódování calldata do „lidského“ jazyka: co se má stát a proč.

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

Získejte přesný stav: Použijte head block, snapshot a případně forknete síť pro konzistenci.
Spusťte trace: Využijte callTracer a stateDiff pro kompletní vnořená volání a změny storage.
Normalizujte tokeny: Detekujte ERC-20/721/1155, zvláštnosti fee-on-transfer a rebasing mechaniky.
Heuristiky a pravidla: Přidejte detektory pro approvals, neznámé implementace proxy, čerstvé adresy a známé škodlivé vzory.
Zobrazení výsledku: Ukažte před/po stavy, příjemce, varování a položkový rozpis poplatků.
Bezpečnostní sandboxy: Blokujte podpis, pokud heuristiky překročí rizikový práh, nebo vyžadujte explicitní „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, mechanismy sekvenzerů, poplatky za data a specifika mostů. Při cross-chain operacích simulujte obě strany – odesílací 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, ordering relaye) a s nastavením skluzu snižuje pravděpodobnost front-runningu či sandwich útoků. Zobrazujte varování, 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í při approvals a u neznámých kontraktů.
Kontrolujte příjemce: Ujistěte se, že simulace obsahuje pouze známé adresy protokolu, nikoli čerstvé peněženky.
Omezujte oprávnění: Preferujte omezené allowance a pravidelně revoke než neomezené schválení.
Dávejte pozor na varování: Pokud simulace hlásí pokles tokenového zůstatku, který „neměl odejít“, transakci nepodepisujte.
Pozor na sign-in a permit podpisy: Ne každý podpis odesílá transakci, ale některé podpisy mohou udělit přístup k aktivům.

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

Výchozí zapnutí simulace: Žádný podpis bez přehledu dopadu na zůstatky a stavy.
Jasná vizualizace: Kontrastní varování, barevné zvýraznění rozdílů a položkové zobrazení transferů.
Přirozený jazyk: Místo hexadecimálních hodnot čitelné věty s názvy funkcí a parametrů.
Nezávislé RPC a redundance: Ověření proti více uzlům ke snížení falešných pozitiv či negativ.
Bezpečnostní politiky: Blokování známých škodlivých podpisů, denylist adres a limitace podpisů s vysokým rizikem.

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

Phishing dApp: Transakce vypadá jako „claim airdrop“, ale simulace odhalí transferFrom všech vašich NFT útočníkovi.
„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 při 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á schválení, proxy/delegatecall, netypické tokeny.
Kontekst 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 nakládat s vašimi 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í.