Интеграция ERC-4337 (Account Abstraction) — полный цикл внедрения

Потеряли приватный ключ — потеряли все средства. В стандартных 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

1. Выбор EntryPoint и Bundler. Определите сеть (Ethereum mainnet, Arbitrum, Optimism, Base) и managed-провайдера (Stackup, Alchemy, Pimlico). EntryPoint v0.6 уже задеплоен по адресу 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789.
2. Разработка Account контракта. Наследуйтесь от BaseAccount (из eth-infinitism/account-abstraction) и добавьте кастомную валидацию: ECDSA, WebAuthn, multisig.
3. Настройка Paymaster. Реализуйте Verifying Paymaster для freemium или ERC-20 Paymaster с Chainlink oracle для приёма USDC.
4. Интеграция SDK. Подключите permissionless.js (viem) или готовый SDK от Biconomy / ZeroDev. Настройте создание и подпись UserOperation.
5. Тестирование и аудит. Используйте 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.

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 + 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 — мы реализуем проект под ключ.