Session klíče a limity výdajů

Session klíče a spending limity: pohodlí bez hazardu

Session klíče a spending limity jsou klíčové nástroje, které přenášejí pohodlí web2 do světa web3, aniž by narušily bezpečnostní záruky vlastního klíče. Cílem je umožnit opakované podepisování a utrácení v přesně vymezeném rámci – bez nutnosti odemykat primární klíč při každé interakci. V článku rozebíráme architektury (smart kontrakt peněženka, account abstraction), návrh oprávnění, kryptografické a operační detaily a „edge cases“ typické pro DeFi a on-chain hry.

Problém: frikce vs. bezpečnost

• Každé kliknutí „Sign/Confirm“ zvyšuje frikci a riziko uživatelských chyb (slepé podepisování, phishing).
• Trvalá unlimited approvals (neomezená povolení) jsou pohodlná, ale při kompromitaci dApp/approve kontraktu vedou ke katastrofám.
• Cíl: mezi ručně podepisovat vše a nechat otevřenou bránu najít bezpečný střed – časově a rozsahově omezená oprávnění.

Co je session klíč

Session klíč je dočasný kryptografický klíč (nebo pár klíčů), kterému primární vlastník deleguje přesně vymezená práva k podepisování transakcí jménem účtu/peněženky. Typicky je vázán na:

• Čas (expirace, TTL),
• Rozsah (konkrétní kontrakty, funkce, kolekce tokenů),
• Limity (denní/mimořádné, per-tx stropy),
• Prostředí (chain ID, dApp doména, relayer/vyhledávací logika).

Po expiraci nebo odvolání je session klíč bezcenný, čímž se minimalizuje „blast radius“ úniku.

Kde se session klíče používají

• On-chain hry a sociální dApps: plynulé podepisování desítek úkonů bez odemykání hlavního klíče.
• DeFi exekuce: sériové swapy, rebalancing, DCA/TWAP strategie s limity bez uživatelské interakce.
• Podnikové prostředí: oddělení operátorských práv od trezorového klíče (treasury/ops model).

Architektury: EOAs vs. smart kontrakt peněženka

• EOA simulace: delegace pomocí podpisu meta-transakcí nebo „permit“ standardů; pravomoci se uplatní v cílovém kontraktu.
• Smart kontrakt peněženka: pravidla autorizace jsou on-chain (modulární politiky, guardi). To umožňuje jemné ACL, spending limity, odvolání a auditní stopu.
• Account Abstraction: transakce jsou user operations s validátorem, který kontroluje session pravidla a limity před vykonáním.

Spending limity: návrh a dimenze

Spending limit je formální rozpočet nad objemem, frekvencí a adresáty. Pro bezpečné nastavení doporučujeme kombinovat:

• Objem: max. částka v nativní měně, max. notional ve stable coinech (např. 500 USDC/den), max. počet NFT transferů.
• Frekvence: limit na transakci, limit na blok, limit na časové okno (minuta/hodina/den), „cool-down“ po vyčerpání.
• Adresy a funkce: allowlist kontraktů, selektivní ABI funkce (např. swapExactTokensForTokens), zákaz „call arbitrary“.
• Směry: pouze pull (permit) nebo push (přímé převody); často oboje s rozdílnými limity.
• Oracly: notional kalkulovaný z on-chain/bezpečného oracle, ne z subjektivního „spotu“ dApp.

Politiky ověřování: před transakcí vs. po transakci

• Pre-check: pravidla se uplatní v peněžence/validátoru před vykonáním (doporučeno; žádný „rollback“ hazard).
• Post-check: monitorování a zpětné zrušení práv po detekci anomálie (fallback; vyžaduje pausable/guard hooky).

Návrhové vzory oprávnění

• Session jako modul: peněženka načte „policy modul“ s mapou sessionKey → ACL/limity/expirace.
• Permit-driven exekuce: podpis „voucheru“ (permit) s doménou, funkcí, parametry, deadlinem a nonce; dApp/relayer ho vykoná až po kontrole limitu.
• Rollback-resistant approvals: schválení (allowance) jsou vázána na spender kontrakt s vlastní politikou, ne na „neomezené“ ERC-20 allowances.

Provozní aspekty: generování, uložení a rotace

• Generování: session klíč vytváří klient lokálně (WebCrypto/SE), podepíše ho primární klíč jako delegaci.
• Uložení: v zabezpečeném úložišti (Secure Enclave, Android Keystore) nebo v HSM; nikdy ne v plain localStorage.
• Rotace: expirace tvořená TTL + „idle timeout“; revokace on-chain (záznam o zrušení) a off-chain (zapomenutí v klientech/relayerech).

Threat model: na co si dát pozor

• Phishing UI: session vytvořená pro jiný kontrakt/doménu. Řešení: doménové vázání (EIP-712 domain separator), „origin pinning“.
• Parameter smuggling: benigní funkce s nečekanými calldata. Řešení: striktní validace selectoru, rozsahu parametrů a příjemců.
• Reentrancy přes modul: volání třetích stran v rámci policy hooku. Řešení: checks-effects-interactions, guardi a reentrancy lock.
• Oracle drift: notional kontrolovaný slabým oracle. Řešení: více feedů, procentuální odchylky a havarijní limity.
• Relayer kompromitace: vynucení podpisu/odhalení metadat. Řešení: šifrované kanály, podepisování „intentu“ a schválení on-chain policy.

Spending limity pro tokeny: praktické vzory

• Per-asset cap: např. 200 USDC/den, 0,05 ETH/den; reset v pevném okně (UTC) nebo klouzavé okno (rolling).
• Per-protocol cap: celkový notional přes konkrétní router (DEX) – zabraňuje „approval driftu“ na jiné směry.
• Per-destination cap: silná ochrana proti odlivu – only-to-vault/allowlist; užitečné pro treasuries.
• Procentuální limity: max. X % zůstatku nebo TVL účtu; dynamické přizpůsobení při volatilitě.

Funkční limity: granularita na úrovni ABI

Kromě tokenových stropů zavádějte funkční politiky:

• povolit pouze konkrétní function selectors,
• ověřovat range parametrů (minOut, deadline <= N minut),
• zakázat delegatecall, create a volání bez cílového příjemce (call to EOA).

Bezpečné UX pro session klíče

• Čitelná karta oprávnění: „Kdo → Co → Kolik → Kdy“ v jedné obrazovce; nezahlcujte ABI detaily.
• Varování a precap: pokud jsou požadována „unlimited“ práva, nutte uživatele manuálně změnit limit.
• Živý meter: vizualizujte vyčerpání denního stropu (např. 120/500 USDC).
• Rychlá revokace: tlačítko „Zrušit všechny sessions“ + granulární revokace per klíč.

Observabilita a audit

• Eventy: SessionCreated, SessionRevoked, Spend s metadata (chain, kontrakt, částka, policyID).
• On-chain metriky: procento zamítnutých volání (policy reject rate), využití capu, počet aktivních session klíčů.
• Off-chain logy: mapování domén, relayer ID, otisky klienta (device fingerprint) při změně chování.

Incident response a „kill-switch“

• Globální pauzování peněženky nebo konkrétní policy.
• Cap-cut: okamžité snížení limitů na nulu pro rizikový protokol.
• Time-lock odvolání opačně (pro treasury): velké změny vyžadují prodlevu a více podpisů.

Integrace s multi-sig a MPC

• Multi-sig & sessions: multi-sig schvaluje zřízení policy, ne každé volání – vysoké pohodlí, zachovaná kolektivní kontrola.
• MPC primární klíč + lokální session klíče: minimalizuje frekvenci interakcí s MPC a chrání proti riziku single-device.

Implementační zásady pro vývojáře

• Deterministické policy ID (hash parametrů) pro audit a reprodukovatelnost.
• Jednoznačný domain separator (chainID, name, version) proti „sign-in another app“ útokům.
• Nonce a replay ochrana: monotónní nonce per session/funkci; v kombinaci s deadlinem.
• Fail-closed logika: pokud oracle/relayer selže, transakce se zamítne.
• Gas policy: cap na gasPrice/priorityFee a fallback na sponzorování přes paymaster s limitem.

Testování: scénáře a metriky

• Pozitivní cesty: sériová volání v limitu, překročení limitu → očekávaný „revert“ s důvodem.
• Mutace parametrů: extrémní hodnoty (max uint, nulové adresy), substituce příjemce, změna chainID.
• Výkonnostní: latence validace policy vs. baseline; overhead na gas a relayer infrastrukturu.
• Bezpečnostní: reentrancy, storage collision v modulech, zneužití delegatecall.

Tabulka: porovnání přístupů k pohodlí a riziku

Checklist pro uživatele

• Session karta zobrazuje konkrétní kontrakty, limity, expiraci a doménu dApp?
• Je dostupné rychlé zrušení a přehled aktivních sessions?
• Jsou limity denní a per-tx, ne pouze „měsíční strop“?
• Je pro výpočty notionalu použit spolehlivý oracle s odchylkovými pojistkami?

Checklist pro integrátory

• Implementovali jste policy modul s allowlistou funkcí a adresátů?
• Jsou eventy a monitoring nastaveny na detekci překročení limitu a anomálií?
• Testujete phishing scénáře (špatná doména, jiný chainID) v CI?
• Máte kill-switch a cap-cut pro incidenty?

Pohodlí bez hazardu je inženýrská disciplína

Session klíče a spending limity umožňují web3 aplikacím nasadit plynulé UX, aniž by obětovaly bezpečnost. Klíčem je přesná specifikace oprávnění, exaktní limity, auditovatelnost a okamžitá revokace. Navrhujte politiky jako kód, měřte jejich dopad na riziko a udržujte minimální nezbytná oprávnění. Tak dosáhnete, že pohodlí nebude hazard, ale kontrolované riziko – přesně tak, jak to v profesionálním krypto a trading stacku má být.