Представьте: ваш пользователь хочет отправить токены, но у него нет ETH для газа. Или нужно восстановить доступ к кошельку без seed phrase, а seed phrase потеряна. Классический EOA-кошелёк не справляется с этими сценариями. Решение — смарт-контрактный кошелёк с Account Abstraction (AA). Наши инженеры с 10+ летним опытом в блокчейне разрабатывают такие кошельки с момента стандартизации EIP-4337. Account Abstraction превращает кошелёк из пассивного хранилища ключей в программируемый агент. Вся логика живёт в смарт-контрактах, а специализированная мемпул-инфраструктура (Bundlers и Paymasters) обрабатывает UserOperation объекты вместо обычных транзакций. Мы реализовали 20+ проектов на Ethereum, Polygon, Arbitrum. Средняя экономия на газе при использовании Paymaster составляет $0.5–2 на транзакцию. Стоимость внешнего аудита обсуждается индивидуально. Закажите разработку смарт-контрактного кошелька — получите консультацию инженера в течение 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 | Проще для EOAs |
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 должна быть аудирована. Ошибка в этой функции — прямая потеря средств пользователей. Экономия на аудите здесь — сознательный риск. Свяжитесь с нами для предварительной оценки — расскажем, как избежать типовых ошибок. Получите консультацию инженера уже сегодня!