Интеграция с ERC-4337 (Account Abstraction)
ERC-4337 — стандарт, который появился в Ethereum mainnet в марте 2023 и принципиально меняет то, как работают кошельки. До него каждый аккаунт в сети — либо EOA (externally owned account), управляемый приватным ключом, либо смарт-контракт. EOA прост, но жёстко ограничен: одна подпись, один ключ, потерял — потерял всё. ERC-4337 позволяет каждому пользователю иметь смарт-контракт-кошелёк с произвольной логикой авторизации — без изменения консенсуса Ethereum.
Суть архитектурного трюка: вместо обычных транзакций пользователи создают UserOperation объекты, которые агрегируются в отдельном mempool. Специализированные ноды-bundler-ы собирают UserOps и отправляют их через EntryPoint контракт — singleton, задеплоенный по одному адресу во всех EVM-совместимых сетях. Вся логика проверки и исполнения — внутри Account контракта пользователя.
Как устроен 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.
Смарт-контракт 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 (из eth-infinitism/account-abstraction репозитория) и добавляет кастомную логику:
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: газ без ETH
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 | Готовые реализации |
Gas overhead и L2
На Ethereum mainnet каждая UserOperation стоит дороже обычной EOA транзакции на ~42 000 gas (overhead EntryPoint). На L2 это почти незаметно: на Arbitrum/Optimism gas в разы дешевле, и Account Abstraction становится практичным для массового использования.
Для 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 кошелька.







