Потеряли приватный ключ — потеряли все средства. В стандартных EOA-кошельках нет восстановления, сессионных ключей или оплаты газа в токенах. ERC-4337 (Account Abstraction) меняет правила: каждый кошелёк — это смарт-контракт с произвольной логикой авторизации, без изменения консенсуса Ethereum. Мы внедрили этот стандарт в 20+ проектах (от DeFi до NFT-маркетплейсов) и знаем все подводные камни.
EIP-4337: Account Abstraction Using Alt Mempool
Архитектурный трюк: вместо обычных транзакций пользователи создают UserOperation объекты, которые агрегируются в отдельном mempool. Специализированные ноды-bundler собирают UserOps и отправляют их через EntryPoint контракт — singleton, задеплоенный по одному адресу во всех EVM-совместимых сетях. За 5 лет на рынке мы накопили опыт в 20+ интеграциях AA, что позволило сократить сроки внедрения на 30% по сравнению с типовыми проектами.
Как работает UserOperation?
UserOperation — это не транзакция в классическом смысле. Это структура данных, которую пользователь подписывает и отправляет в alt mempool:
struct UserOperation {
address sender; // адрес смарт-контракт кошелька
uint256 nonce;
bytes initCode; // если кошелёк ещё не задеплоен
bytes callData; // что исполнить
uint256 callGasLimit;
uint256 verificationGasLimit;
uint256 preVerificationGas;
uint256 maxFeePerGas;
uint256 maxPriorityFeePerGas;
bytes paymasterAndData; // кто платит газ (опционально)
bytes signature;
}
initCode — ключевой момент для UX. Пользователь может получить адрес кошелька (через CREATE2) до его деплоя и использовать этот адрес для получения активов. Кошелёк деплоится автоматически при первой UserOperation — пользователь не видит отдельного шага «создать кошелёк». Bundler вызывает EntryPoint.handleOps(), передавая batch UserOps. EntryPoint делает два прохода: validation loop (проверяет подписи и балансы) и execution loop (исполняет callData). Разделение критично — validation изолирована, чтобы bundler мог проверить рентабельность без side effects.
Пошаговая интеграция ERC-4337
-
Выбор EntryPoint и Bundler. Определите сеть (Ethereum mainnet, Arbitrum, Optimism, Base) и managed-провайдера (Stackup, Alchemy, Pimlico). EntryPoint v0.6 уже задеплоен по адресу
0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789. -
Разработка Account контракта. Наследуйтесь от
BaseAccount(изeth-infinitism/account-abstraction) и добавьте кастомную валидацию: ECDSA, WebAuthn, multisig. - Настройка Paymaster. Реализуйте Verifying Paymaster для freemium или ERC-20 Paymaster с Chainlink oracle для приёма USDC.
- Интеграция SDK. Подключите
permissionless.js(viem) или готовый SDK от Biconomy / ZeroDev. Настройте создание и подпись UserOperation. - Тестирование и аудит. Используйте Foundry, Slither, Mythril, Echidna (fuzzing) для контрактов. Обязателен внешний аудит перед деплоем.
Что нужно реализовать в Account-контракте?
Минимальный Account контракт должен реализовывать IAccount интерфейс с одним методом:
function validateUserOp(
UserOperation calldata userOp,
bytes32 userOpHash,
uint256 missingAccountFunds
) external returns (uint256 validationData);
validationData — packed uint256, содержащий: результат валидации (0 = успех, 1 = провал), validAfter и validUntil временные ограничения. Это позволяет реализовать временные сессионные ключи прямо в логике валидации.
Реальная Account имплементация обычно наследуется от BaseAccount и добавляет кастомную логику:
contract MultiSigAccount is BaseAccount {
mapping(address => bool) public owners;
uint256 public threshold;
function _validateSignature(
UserOperation calldata userOp,
bytes32 userOpHash
) internal override returns (uint256 validationData) {
// decode multiple signatures from userOp.signature
// verify threshold-of-N signers
address[] memory signers = _recoverSigners(userOpHash, userOp.signature);
uint256 validCount = 0;
for (uint i = 0; i < signers.length; i++) {
if (owners[signers[i]]) validCount++;
}
return validCount >= threshold ? 0 : SIG_VALIDATION_FAILED;
}
}
Как работает Paymaster?
Paymaster — смарт-контракт, который спонсирует газ за пользователя. Два основных паттерна:
Verifying Paymaster — принимает off-chain подпись от backend-а, проверяет её on-chain. Используется для freemium моделей: dApp платит газ за пользователей. Backend подписывает разрешение, кошелёк включает его в paymasterAndData.
ERC-20 Paymaster — пользователь платит газ в ERC-20 токене (например, USDC). Paymaster конвертирует курс через Chainlink oracle, берёт чуть больше ERC-20 у пользователя и оплачивает ETH газ сам. Пользователю вообще не нужен ETH.
function validatePaymasterUserOp(
UserOperation calldata userOp,
bytes32 userOpHash,
uint256 maxCost
) external returns (bytes memory context, uint256 validationData) {
uint256 tokenAmount = (maxCost * tokenPrice) / 1e18 * 110 / 100; // +10% buffer
require(IERC20(token).allowance(userOp.sender, address(this)) >= tokenAmount);
return (abi.encode(userOp.sender, tokenAmount), 0);
}
Как работает Social Recovery?
Одна из главных фич Account Abstraction — социальное восстановление. Пользователь назначает guardians (доверенные адреса или хэши адресов), которые могут сменить owner через timelock:
function initiateRecovery(address newOwner) external onlyGuardian {
recoveryRequests[newOwner] = block.timestamp + RECOVERY_DELAY;
}
function finalizeRecovery(address newOwner) external {
require(block.timestamp >= recoveryRequests[newOwner], "Timelock active");
owner = newOwner;
delete recoveryRequests[newOwner];
}
RECOVERY_DELAY (обычно 48-72 часа) даёт пользователю время отменить recovery, если guardian скомпрометирован.
Что такое Session Keys?
Session keys — временные ключи с ограниченными правами. Dapp просит подписать политику: «этот ключ может тратить до 10 USDC в день только в контракте 0x...». Пользователь подписывает один раз, дальше dApp подписывает UserOps session key-ом — без popup каждый раз. Реализуется через SessionKeyValidator module или через кастомную логику в validateUserOp.
Kernel от ZeroDev и Safe{Wallet} реализуют это через модульную архитектуру: Account — execution layer, а validators/executors — подключаемые модули. Выбор базового SDK зависит от требований: Kernel — максимальная гибкость, Biconomy SDK — готовая инфраструктура bundler+paymaster.
Стек и инфраструктура
Смарт-контракты: Solidity 0.8.x, eth-infinitism/account-abstraction v0.6 или v0.7, Foundry для тестов. Критично тестировать через simulateValidation — EntryPoint имеет storage access rules для validation фазы, нарушение которых bundler отклонит UserOp.
Bundler: Stackup, Alchemy, Pimlico — managed bundlers для production. Для собственного — eth-infinitism/bundler (TypeScript) или Silius (Rust). Bundler должен соответствовать ERC-4337 mempool спецификации.
SDK для frontend: permissionless.js (viem-based), Biconomy SDK, ZeroDev SDK. permissionless.js — наиболее low-level, полный контроль над UserOperation construction.
| Компонент | Технология | Примечание |
|---|---|---|
| Account контракт | Solidity + eth-infinitism | Аудит обязателен |
| Paymaster | Solidity + Chainlink | Для ERC-20 gas |
| Bundler | Stackup/Pimlico API | Managed для старта |
| Frontend SDK | permissionless.js + viem | Viem-based, активно развивается |
| Session keys | ZeroDev Kernel / Biconomy | Готовые реализации |
| Тип Paymaster | Механизм | Когда применять |
|---|---|---|
| Verifying Paymaster | Off-chain подпись backend-а | Freemium, кешбэк газ |
| ERC-20 Paymaster | Конвертация токенов через oracle | Пользователь без ETH |
Gas overhead и L2
На Ethereum mainnet каждая UserOperation стоит дороже обычной EOA транзакции на ~42 000 gas (overhead EntryPoint). На L2 это почти незаметно: на Arbitrum/Optimism gas в разы дешевле, и Account Abstraction становится практичным для массового использования. Экономия на газе при переходе на L2 достигает 40–80%, что делает AA доступной для retail-пользователей.
Для Polygon, Base, Optimism, Arbitrum — EntryPoint уже задеплоен по стандартному адресу 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 (v0.6). Одна имплементация работает во всех сетях.
Чек-лист перед деплоем
- [ ] Account контракт проходит тесты Foundry (unit + integration)
- [ ] Paymaster протестирован на edge-case: превышение лимитов, подделка подписи
- [ ] Bundler корректно принимает UserOp (проверено на local node)
- [ ] Аудит внешней командой (минимум один round)
- [ ] Формальная верификация
validateUserOp(опционально)
Сроки и что входит в работу
Базовая интеграция (Account + Paymaster + bundler подключение, без кастомной логики): 3-4 недели. Включает: смарт-контракт Account с ECDSA или WebAuthn валидацией, Verifying Paymaster, интеграция с managed bundler, frontend SDK.
Полная реализация с social recovery, session keys, ERC-20 paymaster, кастомными модулями, аудитом: 8-12 недель.
Аудит Account и Paymaster контрактов — отдельный этап, обязателен перед production деплоем. Ошибки в validateUserOp могут позволить drain кошелька. Свяжитесь с нами для детальной консультации. Закажите интеграцию ERC-4337 — мы реализуем проект под ключ.