Интеграция с ERC-4337 (Account Abstraction)

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1 услугВсе 1306 услуг
Интеграция с ERC-4337 (Account Abstraction)
Сложная
~1-2 недели
Часто задаваемые вопросы
Направления блокчейн-разработки
Этапы блокчейн-разработки
Последние работы
  • image_website-b2b-advance_0.png
    Разработка сайта компании B2B ADVANCE
    1258
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1170
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    873
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1092
  • image_logo-advance_0.png
    Разработка логотипа компании B2B Advance
    563
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    830

Интеграция с 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 кошелька.