Session keys a spending limits

Session kľúče a spending limity: pohodlie bez hazardu

Session kľúče a spending limity sú kľúčové nástroje, ktoré prenášajú pohodlie web2 do sveta web3 bez toho, aby zničili bezpečnostné záruky vlastného kľúča. Cieľom je umožniť opakovateľné podpisovanie a míňanie v presne ohraničenom rámci – bez nutnosti odomknúť primárny kľúč pri každej interakcii. V článku rozoberieme architektúry (smart kontrakt peňaženky, account abstraction), dizajn oprávnení, kryptografické a operačné detaily, a „edge cases“ typické pre DeFi a on-chain hry.

Problém: frikcia vs. bezpečnosť

• Každé kliknutie „Sign/Confirm“ zvyšuje frikciu a riziko chýb používateľa (slepé podpisovanie, phishing).
• Trvalé unlimited approvals (neobmedzené povolenia) sú pohodlné, no pri kompromitácii dApp/approve kontraktu vedú k katastrofám.
• Cieľ: medzi manuálne podpisovať všetko a nechať otvorené dvere nájsť bezpečný stred – časovo a rozsahom obmedzené oprávnenia.

Čo je session kľúč

Session kľúč je dočasný kryptografický kľúč (alebo pár kľúčov), ktorému primárny vlastník deleguje presne ohraničené práva na podpisovanie transakcií v mene účtu/peňaženky. Typicky je viazaný na:

• Čas (expirácia, TTL),
• Rozsah (konkrétne kontrakty, funkcie, kolekcie tokenov),
• Limity (denné/mimoriadne, per-tx stropy),
• Prostredie (chain ID, dApp domain, relayer/pátracia logika).

Po expirácii alebo odvolaní je session kľúč bezcenný, čím sa minimalizuje „blast radius“ úniku.

Kde sa session kľúče používajú

• On-chain hry a sociálne dApps: plynulé podpísanie desiatok úkonov bez odomykania hlavného kľúča.
• DeFi exekúcia: sériové swapy, rebalansy, DCA/TWAP stratégiá s limitmi bez interakcie používateľa.
• Podnikové prostredia: oddelenie operátorských práv od trezorového kľúča (treasury/ops model).

Architektúry: EOAs vs. smart kontrakt peňaženky

• EOA-simulácia: delegácia pomocou podpisu meta-transakcií alebo „permit“ štandardov; právomoci sa uplatnia v cieľovom kontrakte.
• Smart kontrakt peňaženky: pravidlá autorizácie sú on-chain (modulárne politiky, guardi). To umožňuje jemné ACL, spending limity, odvolanie a audit trail.
• Account Abstraction: transakcie sú user operations s verifikátorom (validator), ktorý kontroluje session pravidlá a limity pred vykonaním.

Spending limity: dizajn a dimenzie

Spending limit je formálny rozpočet nad objemom, frekvenciou a adresátmi. Pre bezpečné nastavenie odporúčame kombinovať:

• Objem: max. suma v natívnej mene, max. notional v stable (napr. 500 USDC/deň), max. počet NFT transferov.
• Frekvencia: per-tx limit, per-block cap, per-časové okno (minúta/hodina/deň), „cool-down“ na vyčerpanie.
• Adresy a funkcie: allowlist kontraktov, selektívne ABI funkcie (napr. swapExactTokensForTokens), zákaz „call arbitrary“.
• Smery: iba pull (permit) alebo push (priame prevody); často oboje s inými limitmi.
• Oracly: notional kalkulovaný z on-chain/bezpečného oracle, nie zo subjektívneho „spotu“ dApp.

Politiky overovania: pred transakciou vs. po transakcii

• Pre-check: pravidlá sa uplatnia v peňaženke/verifikátore pred vykonaním (preferované; žiadny „rollback“ hazard).
• Post-check: monitor a spätné zrušenie práv po detekcii anomálie (fallback; vyžaduje pausable/guard háky).

Dizajnové vzory oprávnení

• Session ako modul: peňaženka načíta „policy modul“ s mapou sessionKey → ACL/limity/expirácia.
• Permit-driven exekúcia: podpis „voucheru“ (permit) s doménou, funkciou, parametrami, deadlinom a nonce; dApp/relayer ho vykoná až po kontrole limitu.
• Rollback-resistant approvals: schválenia (allowance) sú viazané na spender kontrakt s vlastnou politikou, nie na „neobmedzené“ ERC-20 allowances.

Prevádzkové aspekty: generovanie, uloženie a rotácia

• Generovanie: session kľúč vytvára klient lokálne (WebCrypto/SE), podpíše ho primárny kľúč ako delegation.
• Uloženie: v zabezpečenom úložisku (Secure Enclave, Android Keystore) alebo v HSM; nikdy nie v plain localStorage.
• Rotácia: expirácia tvorená TTL + „idle timeout“; revokácia on-chain (záznam o zrušení) a off-chain (zabudnutie v klientoch/relayeroch).

Threat model: na čo si dať pozor

• Phishing UI: session vytvorená pre iný kontrakt/doménu. Riešenie: doménové viazanie (EIP-712 domain separator), „origin pinning“.
• Parameter smuggling: benigné funkcie s nečakanými calldata. Riešenie: striktne validovať selector, rozsah parametrov a príjemcov.
• Reentrancy cez modul: volanie tretích strán v rámci policy hooku. Riešenie: checks-effects-interactions, guardi a reentrancy lock.
• Oracle drift: notional kontrolovaný slabým oracle. Riešenie: viacnásobné feedy, percentuálne odchýlky a havarijné limity.
• Relayer kompromitácia: vynútenie podpisu/odhalenie metadát. Riešenie: šifrované kanály, podpisovanie „intentu“ a schválenie on-chain policy.

Spending limity pre tokeny: praktické vzory

• Per-asset cap: napr. 200 USDC/deň, 0,05 ETH/deň; reset v pevnom okne (UTC) alebo klzavé okno (rolling).
• Per-protocol cap: celkový notional cez konkrétny router (DEX) – bráni „approval driftu“ na iné smery.
• Per-destination cap: silná ochrana proti odlivu – only-to-vault/allowlist; užitočné pre treasuries.
• Percentuálne limity: max. X % zostatku alebo TVL účtu; dynamické prispôsobenie pri volatilite.

Funkčné limity: granularita na úrovni ABI

Okrem tokenových stropov zavádzajte funkčné politiky:

• povoliť iba konkrétne function selectors,
• overovať range parametrov (minOut, deadline <= N minút),
• zakázať delegatecall, create a volania bez cieleného príjemcu (call to EOA).

Bezpečné UX pre session kľúče

• Čitateľná karta oprávnení: „Kto → Čo → Koľko → Kedy“ v jednej obrazovke; nezahlcujte ABI detailmi.
• Výstrahy a precap: ak sú požadované „unlimited“ práva, núťte používateľa manuálne zmeniť limit.
• Živý meter: vizualizujte vyčerpanie denného stropu (napr. 120/500 USDC).
• Rýchla revokácia: tlačidlo „Zrušiť všetky sessions“ + granularna revokácia per kľúč.

Observabilita a audit

• Eventy: SessionCreated, SessionRevoked, Spend s metadátami (chain, kontrakt, suma, policyID).
• On-chain metriky: percento zamietnutých volaní (policy reject rate), využitie capu, počet aktívnych session kľúčov.
• Off-chain logy: mapovanie domén, relayer ID, odtlačky klienta (device fingerprint) pri zmene správania.

Incident response a „kill-switch“

• Globálne pauzovanie peňaženky alebo konkrétnej policy.
• Cap-cut: okamžité zníženie limitov na nulu pre rizikový protokol.
• Time-lock odvolania opačne (pre treasury): veľké zmeny vyžadujú oneskorenie a viaceré podpisy.

Integrácia s multi-sig a MPC

• Multi-sig & sessions: multi-sig schvaľuje zriadenie policy, nie každé volanie – vysoké pohodlie, zachovaná kolektívna kontrola.
• MPC primárny kľúč + lokálne session kľúče: minimalizuje frekvenciu interakcií s MPC a chráni pred single-device rizikom.

Implementačné zásady pre vývojárov

• Deterministické policy ID (hash parametrov) pre audit a reprodukovateľnosť.
• Jednoznačný domain separator (chainID, name, version) proti „sign-in another app“ útokom.
• Nonce a replay ochrana: monotónna nonce per session/funkciu; v kombinácii s deadlinom.
• Fail-closed logika: ak oracle/relayer zlyhá, transakcia sa zamietne.
• Gas policy: cap na gasPrice/priorityFee a fallback na sponzorovanie cez paymaster s limitom.

Testovanie: scenáre a metriky

• Pozitívne cesty: sériové volania v limite, prekročenie limitu → očakávaný „revert“ s dôvodom.
• Mutácie parametrov: extrémne hodnoty (max uint, nulové adresy), substitúcia príjemcu, zmena chainID.
• Výkonnostné: latencia validácie policy vs. baseline; overhead na gas a na relayer infra.
• Bezpečnostné: reentrancy, storage-collision v moduloch, zneužitie delegatecall.

Tabuľka: porovnanie prístupov k pohodliu a riziku

Checklist pre používateľov

• Session karta zobrazuje konkrétne kontrakty, limity, expiráciu a doménu dApp?
• Je dostupné rýchle zrušenie a prehľad aktívnych sessions?
• Sú limity denné a per-tx, nie iba „mesačný strop“?
• Je pre výpočty notionalu použitý spoľahlivý oracle s odchýlkovými poistkami?

Checklist pre integrátorov

• Implementovali ste policy modul s allowlistou funkcií a adresátov?
• Sú eventy a monitoring nastavené na detekciu prekročenia limitu a anomálií?
• Testujete phishing scenáre (zlá doména, iný chainID) v CI?
• Máte kill-switch a cap-cut pre incidenty?

Pohodlie bez hazardu je inžinierska disciplína

Session kľúče a spending limity umožňujú web3 aplikáciám nasadiť plynulé UX bez toho, aby obetovali bezpečnosť. Kľúčom je presná špecifikácia oprávnení, exaktné limity, auditovateľnosť a okamžitá revokácia. Dizajnujte politiky ako kód, merajte ich vplyv na riziko a udržiavajte minimálne nutné oprávnenia. Takto dosiahnete, že pohodlie nebude hazard, ale kontrolované riziko – presne tak, ako to v profesionálnom krypto a trading stacku má byť.