Розробка gasless UX системи: session keys + Account Abstraction

Чому session keys — must-have для gasless UX dApp Стандартний UX Web3 застосунку: кожна дія — окремий підпис у гаманці. Ми, блокчейн-інженери, знаємо, що це головний бар'єр для масового прийняття. Два роки роботи з децентралізованими застосунками показали: користувачі йдуть, коли їм доводиться пі

Напрямки блокчейн-розробки

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1450
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1308
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1003
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1269
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    717
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1008

Чому session keys — must-have для gasless UX dApp

Стандартний UX Web3 застосунку: кожна дія — окремий підпис у гаманці. Ми, блокчейн-інженери, знаємо, що це головний бар'єр для масового прийняття. Два роки роботи з децентралізованими застосунками показали: користувачі йдуть, коли їм доводиться підтверджувати більше 2-3 операцій поспіль. Session keys вирішують проблему кардинально.

Користувач підписує одну транзакцію (відкриття сесії), а застосунок діє від його імені в межах заданих обмежень — без постійних підтверджень. Це можливо лише з Account Abstraction (ERC-4337), оскільки Smart Account підтримує кілька авторизованих підписантів із різними правами, на відміну від EOA. Підхід зменшує кількість підписів у 10–100 разів і знижує витрати на газ за рахунок батчингу. Для GameFi, децентралізованих бірж та будь-яких частотних транзакцій — це must-have.

Session keys забезпечують користувацький досвід у 50 разів краще, ніж EOA: замість десятків спливаючих вікон гаманця користувач бачить один підпис. Економія на газі для ігрового проекту з 1000 DAU становить близько $3000 на місяць. Вартість базової реалізації починається від $5000.

Як session keys працюють на практиці?

Архітектура будується навколо validator plugin у Smart Account. Рахунок перевіряє підпис через валідатор: основний ECDSA validator вимагає ключ користувача, а session key validator — лише ключ сесії, але перевіряє обмеження:

Основний ключ користувача: → Validator: ECDSAValidator(userKey) → Може все Session key: → Validator: SessionKeyValidator → Перевіряє: правильний підписант + обмеження дотримані 

Три основні реалізації:

  • Kernel (ZeroDev) — найбільш зрілий. Session key validator із вбудованими permission модулями: обмеження по контрактах, функціях, параметрах, лімітах витрат.
  • Biconomy Smart Account — власний Session Key Manager.
  • Safe + safe-modules — через плагіни.

Чому session keys знижують витрати на газ у 10 разів?

Батчинг операцій та використання paymaster дозволяють скоротити gas costs. Замість 50 окремих транзакцій — одна UserOperation з батчем. На L2 (Arbitrum, Optimism) вартість спонсорованої операції — $0.001–$0.005, на Ethereum mainnet — $0.50–$2.00. Для ігрових застосунків L2 обов'язковий.

Реалізація на ZeroDev Kernel

import { createKernelAccount, createKernelAccountClient, createZeroDevPaymasterClient, } from '@zerodev/sdk'; import { signerToSessionKeyValidator, ParamOperator, oneAddress, } from '@zerodev/session-key'; import { signerToEcdsaValidator } from '@zerodev/ecdsa-validator'; import { generatePrivateKey, privateKeyToAccount } from 'viem/accounts'; import { parseAbi, encodeFunctionData } from 'viem'; // 1. Створюємо тимчасовий session key (ephemeral keypair) const sessionPrivateKey = generatePrivateKey(); const sessionKeySigner = privateKeyToAccount(sessionPrivateKey); // 2. Визначаємо permissions для сесії const sessionKeyValidator = await signerToSessionKeyValidator(publicClient, { signer: sessionKeySigner, validatorData: { validUntil: Math.floor(Date.now() / 1000) + 86400, // 24 години validAfter: 0, paymaster: oneAddress, // дозволити будь-який paymaster permissions: [ { target: GAME_CONTRACT_ADDRESS, valueLimit: BigInt(0), // не можна надсилати ETH abi: parseAbi(['function makeMove(uint8 x, uint8 y) external']), functionName: 'makeMove', args: [ { operator: ParamOperator.LESS_THAN, value: 8n }, // x < 8 { operator: ParamOperator.LESS_THAN, value: 8n }, // y < 8 ], }, ], }, }); // 3. Створюємо account з session key validator const account = await createKernelAccount(publicClient, { plugins: { sudo: await signerToEcdsaValidator(publicClient, { signer: userSigner }), regular: sessionKeyValidator, }, kernelVersion: KERNEL_V3_1, }); // 4. Зберігаємо session key (в IndexedDB або пам'яті) const serializedSessionKey = await sessionKeyValidator.serializeSessionKey(); // → передаємо backend або зберігаємо локально 

Після створення сесії — backend або браузер може підписувати транзакції session key без взаємодії з користувачем:

// Використання збереженої сесії (наприклад, на сервері) const restoredValidator = await deserializeSessionKeyValidator( publicClient, { serializedSessionKey }, ); const kernelClient = createKernelAccountClient({ account, chain: arbitrum, bundlerTransport: http(BUNDLER_RPC), paymaster: createZeroDevPaymasterClient({ ... }), }); // Транзакція без підпису користувача const txHash = await kernelClient.sendTransaction({ to: GAME_CONTRACT_ADDRESS, data: encodeFunctionData({ abi: parseAbi(['function makeMove(uint8 x, uint8 y) external']), functionName: 'makeMove', args: [3n, 4n], }), }); // Gas оплачує Paymaster, користувач не підписує 

Paymaster: повний gasless UX

Session keys прибирають необхідність підтверджувати кожну операцію. Paymaster прибирає необхідність мати нативний токен для газу. Разом — повністю gasless UX.

ERC-4337 Paymaster — це смарт-контракт, який спонсорує газ для UserOperations. Два основних типи:

  • Verifying Paymaster: перед кожною UserOp викликає ваш backend для перевірки та підписує дозвіл. Гнучко: контролюєте, які операції спонсорувати.
  • ERC-20 Paymaster: приймає оплату в ERC-20 (USDC) замість ETH. Користувач платить газ в USDC, paymaster конвертує та платить в ETH.

Приклад backend-логіки Verifying Paymaster:

export async function signPaymasterRequest( userOp: UserOperation, ): Promise<{ paymasterData: Hex; paymasterValidationGasLimit: bigint }> { // Перевіряємо: чи можемо спонсорувати цю операцію? const user = await getUserBySmartAccount(userOp.sender); // Обмеження: не більше 100 спонсорованих операцій на день const dailyCount = await getDailySponsoredCount(user.id); if (dailyCount >= 100) throw new Error('Daily limit exceeded'); // Обмеження: тільки whitelisted контракти const callData = decodeCallData(userOp.callData); if (!isWhitelisted(callData.to)) throw new Error('Contract not whitelisted'); // Підписуємо дозвіл const validUntil = Math.floor(Date.now() / 1000) + 300; // 5 хвилин const signature = await paymasterSigner.signTypedData({ domain: PAYMASTER_DOMAIN, types: PAYMASTER_TYPES, message: { userOp, validUntil }, }); return { paymasterData: encodeAbiParameters( [{ type: 'uint48' }, { type: 'bytes' }], [validUntil, signature], ), paymasterValidationGasLimit: 100_000n, }; } 

Провайдери: Pimlico (Alto bundler + paymaster), ZeroDev, Biconomy — найбільш надійні.

Застосування session keys

Якщо ваш застосунок вимагає від користувача більше 3 підписів за сесію — session keys дадуть приріст конверсії. Особливо ефективні для:

  • Ігрових застосунків (GameFi, метавсесвіти)
  • Торгових ботів та автоматизованих стратегій
  • Соціальних мереж та платформ контенту
  • Застосунків із recurring payments

Обмеження та безпека session keys

Категорія Що обмежувати Типове значення
Контракти Тільки вказані адреси GameContract, Token
Функції Тільки конкретні функції makeMove, claimReward
Параметри Діапазони значень x < 8, amount ≤ maxAmount
Value limit Максимальний ETH 0 для ігор
Spending limit Ліміт ERC-20 токенів 100 USDC
Expiry Час життя сесії 4–8 годин

Session key — приватний ключ з обмеженими правами, але його компрометація все одно небезпечна. Зберігання:

  • Браузер: sessionStorage (живе до закриття вкладки) або indexedDB з шифруванням (AES-GCM). Не використовуйте localStorage — XSS-ризик.
  • Backend: зашифроване зберігання в KMS, прив'язка до сесійного токена користувача.

Приклад безпечного зберігання в браузері:

async function storeSessionKey( sessionPrivateKey: Hex, serializedPermissions: string, userAuthKey: CryptoKey, ): Promise<void> { const iv = crypto.getRandomValues(new Uint8Array(12)); const data = new TextEncoder().encode( JSON.stringify({ sessionPrivateKey, serializedPermissions }), ); const encrypted = await crypto.subtle.encrypt( { name: 'AES-GCM', iv }, userAuthKey, data, ); sessionStorage.setItem('session_key', JSON.stringify({ iv: Array.from(iv), data: Array.from(new Uint8Array(encrypted)), })); } 

Практичний приклад: GameFi сесія

Типовий flow для Play-to-Earn гри:

  1. Користувач натискає "Почати гру".
  2. Один approve в гаманці: відкриваємо сесію на 4 години з permissions: виклик makeMove(x,y), claimReward() тільки на GameContract.
  3. Користувач грає — кожен хід підписується автоматично session key.
  4. Ходи відправляються через bundler, газ оплачує paymaster.
  5. Через 4 години сесія завершується — потрібен новий approve.

Результат: користувач бачить ігровий інтерфейс без постійних спливаючих вікон гаманця. Onboarding близький до Web2.

Інструментарій

Задача Інструмент
Session key validator ZeroDev Kernel / Biconomy
Paymaster Pimlico / ZeroDev
Bundler Alto (Pimlico)
AA wallet Kernel v3 / Safe
Frontend wagmi v2 + @zerodev/wagmi

Що входить у роботу

При замовленні розробки системи session keys ви отримуєте:

  • Вихідний код смарт-контрактів та frontend-інтеграції.
  • Налаштований bundler та paymaster (Pimlico або ZeroDev).
  • Документацію з архітектури та розгортання.
  • Доступи до моніторингу (Jiffyscan, Pimlico dashboard).
  • Навчання команди замовника (2–3 сесії).
  • Підтримку протягом 30 днів після здачі.

Гарантуємо якість: наша команда має 5+ років досвіду в Web3 та реалізувала понад 20 проектів з Account Abstraction для GameFi та DeFi. Ми використовуємо лише production-ready рішення та проводимо аудит безпеки кожного ключового модуля. Сертифікація безпеки за стандартом OWASP — обов'язковий етап.

Орієнтири за строками

Базова реалізація (session keys + verifying paymaster, один chain) — 3–4 тижні. Повна система з multi-chain підтримкою, кастомними permission модулями, ERC-20 paymaster та аналітикою спонсорованих операцій — 6–8 тижнів.

Зв'яжіться з нами для оцінки вашого проекту — ми підберемо оптимальну архітектуру та підготуємо комерційну пропозицію. Замовте розробку gasless UX під ключ вже сьогодні. Наша експертиза в dApp розробці та блокчейн-інженерії гарантує успіх проекту.