Уявіть: ваш користувач хоче відправити токени, але в нього немає ETH для газу. Або потрібно відновити доступ до гаманця без seed phrase, а seed phrase втрачена. Класичний EOA-гаманець не справляється з цими сценаріями. Рішення — смарт-контрактний гаманець з Account Abstraction (AA). Смарт-контрактний гаманець з Account Abstraction — це не просто зберігання, а програмований агент. Наші інженери з 10+ річним досвідом у блокчейні розробляють такі гаманці з моменту стандартизації EIP-4337. За 5 років на ринку ми реалізували понад 20 проєктів на Ethereum, Polygon, Arbitrum. Середня економія на газі при використанні Paymaster становить $0.5–2 на транзакцію. Account Abstraction дозволяє зменшити витрати на газ у 3–5 разів порівняно з традиційними EOA-транзакціями через використання Paymaster. Вартість зовнішнього аудиту — від $5 000 до $15 000 залежно від складності. Ми гарантуємо безпеку — кожен смарт-контракт проходить сертифікований аудит. Замовте розробку смарт-контрактного гаманця — отримайте консультацію інженера протягом 2 днів.
Як Account Abstraction змінює архітектуру смарт-контрактного гаманця?
Компоненти системи — розробка смарт-контрактного
Класична EOA-транзакція йде напряму в mempool і виконується нодою. В AA-системі ланцюжок інший:
- UserOperation — псевдотранзакція, підписана користувачем. Містить callData, sender (адреса смарт-гаманця), signature, ліміти gas та параметри Paymaster.
- Bundler — offchain агент, який збирає UserOperations з альтернативного mempool, упаковує їх в одну on-chain транзакцію і викликає EntryPoint. Існуючі реалізації: Stackup, Pimlico, Alchemy Rundler (написаний на Rust, на порядок швидший референсної реалізації).
- EntryPoint — singleton контракт (0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 на більшості EVM мереж), розгорнутий командою ERC-4337. Саме він верифікує та виконує пачку операцій. Не можна деплоїти свій EntryPoint — екосистема зав'язана на цю адресу.
- Account Contract — сам смарт-гаманець користувача. Повинен реалізовувати інтерфейс IAccount з методом validateUserOp. Сюди йде вся кастомна логіка.
- Paymaster — опціональний контракт, який платить gas за користувача або приймає оплату в ERC-20 токенах замість ETH.
Детальніше в специфікації EIP-4337.
Життєвий цикл UserOperation
User → sign UserOp → send to Bundler RPC
Bundler → simulate via eth_estimateUserOperationGas → validate signature + paymaster
Bundler → batch multiple UserOps → call EntryPoint.handleOps()
EntryPoint → validateUserOp() на кожному Account Contract
EntryPoint → Paymaster.validatePaymasterUserOp()
EntryPoint → execute callData
EntryPoint → postOp() на Paymaster (для обліку gas)
Важливий момент: simulation і execution розділені. Bundler симулює через eth_callStateOverride і реджектить операції, які можуть зафейлитись on-chain. Це захищає Bundler від втрати ETH на failed transactions.
Що таке Factory і counterfactual деплой?
Одна з ключових властивостей AA — гаманець існує як адреса ще до деплою. CREATE2 з детермінованим salt (зазвичай хеш від owner address) дає передбачувану адресу. Користувач отримує адресу гаманця до першої транзакції, може прийняти кошти — гаманець деплоїться автоматично при першому використанні.
contract WalletFactory {
function getAddress(address owner, uint256 salt) public view returns (address) {
return Create2.computeAddress(
bytes32(salt),
keccak256(abi.encodePacked(
type(ERC1967Proxy).creationCode,
abi.encode(address(implementation), initData(owner))
))
);
}
function createAccount(address owner, uint256 salt) external returns (SmartWallet) {
address addr = getAddress(owner, salt);
if (addr.code.length > 0) return SmartWallet(payable(addr)); // вже задеплоєно
return SmartWallet(payable(new ERC1967Proxy{salt: bytes32(salt)}(
address(implementation), initData(owner)
)));
}
}
Реалізація газлес‑транзакцій через Paymaster
Sponsoring Paymaster
contract SponsoringPaymaster is IPaymaster {
mapping(address => bool) public whitelistedContracts;
function validatePaymasterUserOp(
UserOperation calldata userOp,
bytes32,
uint256 maxCost
) external returns (bytes memory context, uint256 validationData) {
// Спонсоруємо тільки виклики whitelisted контрактів
address target = address(bytes20(userOp.callData[16:36]));
require(whitelistedContracts[target], "Not whitelisted");
require(deposit() >= maxCost, "Insufficient deposit");
return (abi.encode(userOp.sender), 0);
}
}
Paymaster повинен тримати депозит в EntryPoint. Механізм staking запобігає DoS: Paymaster без stake може спонсорувати максимум одну операцію за бандл.
ERC-20 Paymaster
Приймає будь-який ERC-20 як оплату gas. Оракул потрібен для конвертації: Chainlink price feed або пул Uniswap V3 TWAP. Схема роботи: до виконання блокуємо maxCost * exchangeRate токенів, після — списуємо фактичний cost через postOp.
Готові рішення: Pimlico ERC-20 Paymaster (open source), Stackup Paymaster SDK.
Реалізація Account Contract
Базова структура
За основу беремо SimpleAccount від eth-infinitism або SafeAccount від Safe (колишній Gnosis Safe). Для production — Safe v1.4.1 з 4337 модулем, тому що він battle-tested з $100B+ TVL.
Замість наведення повного коду, опишемо ключовий метод validateUserOp. Він перевіряє підпис, nonce та при необхідності оплачує газ. validationData кодує три параметри: результат валідації (0 — успіх, 1 — провал), validAfter і validUntil timestamps (time-bounded операції).
Патерни розширеної логіки
Session keys. Обмежений ключ (наприклад, згенерований браузером без seed phrase exposure), якому дозволені операції тільки в рамках конкретного контракту, ліміту суми та часового вікна. Структура зберігання:
struct SessionKey {
address key;
address allowedContract;
uint256 spendingLimit;
uint48 validUntil;
bool enabled;
}
mapping(address => SessionKey) public sessionKeys;
Це фундамент для "gasless gaming" — користувач один раз підписує сесію на ігровий контракт, далі гра робить транзакції від його імені.
Social recovery. Guardians — довірені адреси, які можуть змінити owner через timelock (зазвичай 72 години). Реалізація Argent — хороший референс: threshold з M-of-N guardians, cancellation протягом timelock window якщо owner онлайн.
Фронтенд інтеграція
Viem + permissionless.js — найбільш актуальний стек (постійно оновлюється). permissionless побудований на Viem і надає абстракції для роботи з Bundler та Paymaster RPC:
import { createSmartAccountClient } from "permissionless";
import { signerToSimpleSmartAccount } from "permissionless/accounts";
import { createPimlicoBundlerClient } from "permissionless/clients/pimlico";
const smartAccount = await signerToSimpleSmartAccount(publicClient, {
signer: walletClient,
factoryAddress: FACTORY_ADDRESS,
entryPoint: ENTRY_POINT_ADDRESS,
});
const smartAccountClient = createSmartAccountClient({
account: smartAccount,
chain: optimism,
bundlerTransport: http(BUNDLER_RPC_URL),
middleware: {
sponsorUserOperation: paymasterClient.sponsorUserOperation,
},
});
// Відправка транзакції — ідентично звичайному гаманцю для користувача
const txHash = await smartAccountClient.sendTransaction({
to: contractAddress,
data: encodeFunctionData({ abi, functionName: "doSomething" }),
});
ZeroDev SDK — альтернатива з вищим рівнем абстракції, вбудованими session keys та Kernel account (популярний Account Contract з plugin системою).
Альтернативи EIP-4337
| Рішення | Вимагає EntryPoint | Сумісність з EVM | Особливість |
|---|---|---|---|
| EIP-4337 | Так | Всі EVM мережі | Стандарт де‑факто |
| zkSync Native AA | Ні | zkSync Era | Вбудовано в L2, дешевше |
| EIP-7702 | Ні (тимчасова делегація) | Майбутній Ethereum | Простіше для EOA |
zkSync Native AA — на zkSync Era AA вбудована в протокол, не потрібен окремий EntryPoint. Кожен акаунт може бути смарт-контрактом з коробки. Більш ефективно по gas, але прив'язка до zkSync.
EIP-7702 (Prague/Electra) — майбутній хардфорк Ethereum. Дозволяє EOA тимчасово делегувати виконання смарт-контракту через спеціальний тип транзакції. Не замінює 4337 повністю, але закриває частину use cases простіше.
Етапи розробки та оцінки
| Компонент | Складність | Термін |
|---|---|---|
| Базовий Account Contract (single owner) | Середня | 1–2 тиж |
| Factory + counterfactual deploy | Низька | 3–5 днів |
| Sponsoring Paymaster | Середня | 1 тиж |
| ERC-20 Paymaster + оракул | Висока | 1–2 тиж |
| Session keys | Висока | 1–2 тиж |
| Social recovery | Висока | 1–2 тиж |
| Frontend SDK інтеграція | Середня | 1 тиж |
| Аудит + виправлення | — | 3–6 тиж |
Детальніше про процес аудиту
Аудит включає ручну перевірку коду статичними аналізаторами (Slither, Mythril) та fuzzing (Echidna). Особливу увагу приділяємо validateUserOp та Paymaster‑логіці. Результат — звіт з критичністю багів та часом на виправлення.
Мінімальний production-ready гаманець (single owner + sponsoring paymaster + фронтенд) — 4–6 тижнів розробки. Повнофункціональний продукт з social recovery, session keys та мультимережею — 3–5 місяців. Оцінимо ваш проєкт за 2 дні — просто надішліть опис задачі.
Що входить в роботу
- Аналіз вимог та проектування архітектури
- Розробка смарт-контрактів (Account Contract, Factory, Paymaster)
- Інтеграція з Bundler та Paymaster (Pimlico, Stackup, Alchemy)
- Фронтенд SDK на Viem + permissionless.js
- Тестування (unit, integration, fuzzing via Echidna)
- Аудит коду (внутрішній + зовнішній)
- Деплой в mainnet/testnet
- Документація та навчання команди
- Технічна підтримка 3 місяці
Ключовий момент при виборі підрядника: реалізація validateUserOp повинна бути аудійована. Помилка в цій функції — пряма втрата коштів користувачів. Економія на аудиті тут — свідомий ризик. Зв'яжіться з нами для попередньої оцінки — розповімо, як уникнути типових помилок. Отримайте консультацію інженера вже сьогодні!