ERC-4337 переносит проверку пользовательской операции из жёстких правил EOA в программируемый smart account, не меняя консенсус Ethereum. Кошелёк формирует объект UserOperation, bundler проверяет его и включает в обычную onchain-транзакцию, а общий контракт EntryPoint вызывает аккаунт. Paymaster при необходимости оплачивает gas по собственным условиям, а factory создаёт аккаунт при первом использовании.
Это не бесплатные транзакции и не новый базовый блокчейн. Bundler всё равно платит нативной монетой сети, EntryPoint возмещает расход из депозита аккаунта или paymaster, а безопасность зависит от кода smart account и всей инфраструктуры вокруг него.
Зачем понадобился ERC-4337
Обычный EOA разрешает транзакцию одной подписью ECDSA от приватного ключа. Правила фиксированы протоколом: аккаунт не может сам потребовать две подписи, passkey, лимит расходов или временный session key. Смарт-контракт умеет реализовать такие проверки, но сам по себе не способен начать обычную Ethereum-транзакцию и оплатить gas как EOA.
ERC-4337 добавляет верхний слой доставки. Пользователь подписывает не обычную транзакцию, а UserOperation. Специализированный bundler превращает одну или несколько операций в обычную транзакцию к EntryPoint. Контрактный аккаунт проверяет подпись собственной логикой, после чего EntryPoint исполняет запрос.
Стандарт опубликован как application-layer account abstraction. Он работает поверх существующих правил Ethereum и совместимых EVM-сетей. Для его запуска не нужен hard fork каждой цепочки, но нужны развёрнутые контракты, bundlers, RPC-методы и кошельки, согласные с конкретной версией EntryPoint.
Основные участники
- Smart account. Контракт, который хранит активы, проверяет UserOperation и исполняет вызовы.
- UserOperation. Подписанный объект с sender, nonce, calldata, gas-параметрами и дополнительными данными.
- Bundler. Оператор, который принимает UserOperations, симулирует их и отправляет bundle в EntryPoint.
- EntryPoint. Общий контракт в центре проверки, учёта gas и исполнения.
- Factory. Контракт, создающий smart account по детерминированному адресу, если его ещё нет.
- Paymaster. Контракт, который соглашается оплатить операцию и держит депозит в EntryPoint.
- Aggregator. Необязательный контракт для объединённой проверки определённых схем подписей.
Приложение может скрыть эти роли за одной кнопкой. Пользователь видит «отправить», но кошелёк обращается к bundler RPC, получает данные paymaster, подписывает UserOperation и ждёт транзакцию EntryPoint. Для аудита полезно развернуть этот путь обратно и понять, кто способен отказать или изменить условия.
Что находится в UserOperation
UserOperation описывает намерение smart account. Поле sender задаёт адрес аккаунта, nonce защищает от повторного исполнения, callData кодирует действие, gas-поля ограничивают расходы, а signature передаёт доказательство авторизации. В актуальном onchain-вызове EntryPoint используется упакованная структура PackedUserOperation.
Если аккаунт ещё не создан, операция содержит данные factory. Они позволяют EntryPoint получить код аккаунта по ожидаемому адресу. Если используется paymaster, отдельный блок данных содержит его адрес, лимиты проверки и postOp, а также политику или подпись спонсора.
UserOperation не является обычной транзакцией в mempool Ethereum. У неё нет собственного консенсусного типа блока. До включения это offchain-объект в отдельной инфраструктуре, а onchain она становится частью вызова handleOps, который bundler отправляет в EntryPoint.
Как формируется подпись
Кошелёк вычисляет hash UserOperation с учётом сети и адреса EntryPoint. Привязка к chain ID и EntryPoint защищает от простого воспроизведения той же подписи в другой сети или через несовместимую версию центрального контракта. После этого smart account решает, как проверить поле signature.
Один аккаунт может принимать обычную ECDSA-подпись владельца, другой – M-of-N, passkey, guardian approval или session key. ERC-4337 задаёт транспорт и общий интерфейс, но не навязывает одну схему владения. Поэтому слова «кошелёк поддерживает 4337» недостаточно для вывода о восстановлении и безопасности.
Правила recovery, лимиты и обновления находятся в коде конкретного аккаунта или его модулей. Если implementation обновляемый, нужно проверить admin и задержку. Если подпись проверяет внешний сервис, account abstraction не делает его автоматически децентрализованным.
Отдельный mempool и bundler
Кошелёк отправляет UserOperation через специальные JSON-RPC методы bundler. Оператор выполняет базовые проверки, оценивает gas и симулирует validation. Невалидная подпись, недостаточный депозит, запрещённый доступ к состоянию или истекающий срок заставят bundler отклонить операцию до отправки onchain.
Прошедшие проверку операции собираются в bundle. Bundler вызывает handleOps EntryPoint и платит gas обычной транзакцией. После исполнения контракт возмещает расход и переводит собранные комиссии адресу beneficiary bundler. Экономически bundler похож на relayer, но следует общим правилам ERC-4337 и работает с отдельным пулом операций.
Один bundler может быть недоступен, цензурировать запрос или применять собственные минимальные fee. Стандарт стремится к общему mempool, однако кошельки часто используют конкретного провайдера. Возможность заменить endpoint важна для устойчивости, но альтернативный bundler должен поддерживать ту же сеть, EntryPoint, account implementation и paymaster.
Зачем нужна симуляция
Bundler рискует собственным gas: если bundle откатится, никто автоматически не возместит ему весь расход. До включения он симулирует validation аккаунта, factory и paymaster. Правила ограничивают доступ к storage и опасным операциям, чтобы один участник не мог дешёво заставлять bundlers многократно выполнять дорогую или непредсказуемую проверку.
Симуляция validation отвечает на вопрос, может ли операция быть принята сейчас и кто за неё заплатит. Она не гарантирует успешный результат бизнес-вызова. Между симуляцией и блоком состояние DEX, nonce, balance, deadline или oracle может измениться. Основной call способен revert, хотя validation прошла.
Поэтому интерфейс не должен называть успешную preflight-проверку гарантией. Bundler повторяет bundle simulation перед отправкой и исключает проблемную UserOperation, но полностью устранить изменение onchain-состояния между проверкой и включением невозможно.
Что делает EntryPoint
EntryPoint – общий контракт, через который проходит пакет операций. В validation loop он проверяет создание sender через factory, вызывает validateUserOp аккаунта, при необходимости вызывает проверку paymaster и резервирует средства на gas. Затем execution loop передаёт каждому аккаунту его callData.
После выполнения EntryPoint рассчитывает фактический расход, возвращает неиспользованную часть предварительно зарезервированных средств и компенсирует bundler. Если платит аккаунт, средства берутся из его депозита или переводятся в процессе validation. Если платит paymaster, используется депозит paymaster.
EntryPoint не знает, какая подпись «правильная» для всех кошельков. Он вызывает контракт sender, а тот применяет собственные правила. Центральность точки входа не означает единого владельца всех аккаунтов: код EntryPoint общий, но контроль активов определяется account implementation.
Новые версии EntryPoint разворачиваются отдельными контрактами. Старый аккаунт и новая инфраструктура могут оказаться несовместимыми, если кошелёк не поддерживает миграцию. Адрес EntryPoint должен входить в подпись, поэтому подмена версии меняет UserOperation hash.
Factory и контрфактический адрес
Smart account может получить известный адрес до развёртывания. Factory вычисляет его детерминированно по implementation, owner и salt. На такой адрес можно заранее получить активы, а первая UserOperation одновременно создаст контракт и выполнит действие.
В актуальной структуре данные создания передаются вместе с операцией. EntryPoint вызывает factory и проверяет, что появился ожидаемый sender. Если код уже развёрнут, данные factory не должны повторно создавать аккаунт.
Контрфактический адрес улучшает onboarding, но требует точной привязки к сети и factory. Одинаковые параметры не гарантируют одинаковый код на разных сетях. До перевода крупной суммы нужно проверить адрес factory, implementation, salt и возможность развернуть аккаунт при отказе исходного сервиса.
Как работает paymaster
Paymaster позволяет приложению, работодателю, DAO или другому спонсору оплачивать gas пользователя. Контракт хранит нативную монету на депозите EntryPoint и для каждой UserOperation решает, готов ли принять расход. Условия могут учитывать подпись backend, разрешённый метод, лимит, срок, токен или статус пользователя.
После основного вызова EntryPoint может вызвать postOp, чтобы paymaster учёл фактическую стоимость или выполнил расчёт по своей политике. Если приложение предлагает оплату gas ERC-20, обычно paymaster сначала платит bundler нативной монетой, а затем списывает или получает токен по отдельной логике.
«Gasless» означает, что пользователь не платит нативной монетой напрямую. Вычисления остаются платными. Расход покрывает спонсор, подписка, комиссия приложения или обмен другого токена. Подробнее экономику разбирает статья кто оплачивает gas в смарт-кошельке.
Paymaster может отказать из-за лимита, географии, истёкшей подписи, недостаточного депозита или изменения политики. Такой отказ не обязательно блокирует аккаунт: кошелёк может повторить операцию без paymaster, если имеет нативную монету и поддерживает другой маршрут.
Nonce в ERC-4337
Nonce предотвращает повторное исполнение UserOperation, но его модель гибче обычного счётчика EOA. EntryPoint может разделять значение на key и sequence. Разные nonce keys позволяют вести параллельные очереди, например для владельца и session key, не заставляя все операции ждать один глобальный номер.
Конкретный smart account способен добавлять собственные ограничения поверх EntryPoint. Ошибка кошелька при выборе key или sequence приведёт к отклонению операции. Pending UserOperation также живёт не в обычном txpool, поэтому стандартная кнопка ускорения Ethereum-транзакции может не работать.
Сравнение с обычным порядком отправки дано в материале что такое nonce в Ethereum. В обоих случаях nonce защищает от replay, но ERC-4337 допускает несколько логических последовательностей.
Когда операция считается завершённой
Кошелёк сначала получает UserOperation hash от bundler. Это ещё не transaction hash. После включения bundle появляется обычная транзакция bundler к EntryPoint, а результат конкретной операции фиксируется событиями EntryPoint. Один transaction hash может содержать несколько UserOperations.
Нужно различать четыре стадии: bundler принял объект, validation simulation прошла, bundle отправлен, событие исполнения подтверждено в блоке. Первые две стадии не означают onchain-результат. Даже внутри успешной bundle-транзакции отдельная операция может завершить пользовательский call ошибкой и оплатить израсходованный gas.
Окончательная финальность зависит от сети. Быстрое событие в L2 и расчётная финальность в Ethereum могут наступать в разное время. ERC-4337 не меняет базовые правила подтверждений выбранной цепочки.
Связь ERC-4337 с EIP-7702
ERC-4337 изначально работал со smart accounts, которые являются отдельными контрактными адресами. EIP-7702 позволяет обычному EOA установить указатель на account code и участвовать в 4337-потоке, сохранив прежний адрес. Authorization передаётся рядом с UserOperation и обрабатывается транзакцией соответствующего типа.
Эти стандарты дополняют, но не заменяют друг друга. EIP-7702 меняет code EOA на уровне протокола, а ERC-4337 доставляет и исполняет UserOperation через bundler и EntryPoint. Аккаунт может использовать 7702 без общего 4337 mempool, а контрактный smart account может использовать 4337 без 7702.
Владелец EOA сохраняет силу исходного приватного ключа, поэтому делегирование не создаёт абсолютное onchain-отзывание ключа. Риски и очистка разобраны отдельно в статье про EIP-7702.
Какие возможности получает кошелёк
- Пакетные действия. Approve и swap, несколько переводов или настройка аккаунта выполняются одной UserOperation.
- Гибкие подписи. Контракт может принимать multisig, passkey, guardian или session key.
- Спонсирование gas. Paymaster оплачивает нативную монету по заданной политике.
- Оплата другим токеном. Paymaster или модуль проводит обмен, но курс и комиссия определяются продуктом.
- Recovery. Владение можно восстановить по правилам контракта, если они были настроены заранее.
- Ограничения. Лимиты суммы, адресов, времени и методов могут проверяться onchain.
Пример зрелого программируемого аккаунта – Safe, который поддерживает ERC-4337 через отдельные модули. Но стандарт не делает любой модуль безопасным. Каждое расширение добавляет новый путь исполнения и должно проверяться вместе с базовым контрактом.
Основные риски
- Ошибка account implementation. Неверная проверка подписи или upgrade открывает прямой доступ к активам.
- Опасный модуль. Session key, recovery plugin или validator module способен обходить ожидаемые ограничения.
- Зависимость от bundler. Один провайдер может цензурировать, задерживать или неправильно оценивать gas.
- Зависимость от paymaster. Спонсор меняет политику, теряет депозит или блокирует определённые операции.
- Factory risk. Ошибка детерминированного развёртывания создаёт другой код по ожидаемому адресу.
- Несовместимость EntryPoint. Версии контрактов, SDK и bundler должны совпадать.
- Simulation gap. Состояние меняется между проверкой и включением, поэтому execution может revert.
- Непрозрачная комиссия. Пользователь может платить ERC-20, подписку или наценку, хотя интерфейс называет транзакцию бесплатной.
- Централизованное recovery. Удобное восстановление иногда даёт backend или guardians широкие права.
- Cross-chain divergence. Один адрес может иметь разные deployments, owners и nonce в разных сетях.
Что проверять пользователю
- Точный адрес smart account и сеть.
- Account implementation, proxy admin и включённые модули.
- Правила подписи, recovery, session keys и лимиты.
- Адрес EntryPoint и поддерживаемую версию.
- Bundler endpoint и возможность заменить провайдера.
- Кто является paymaster, что он оплачивает и может ли операция уйти без него.
- Разницу между UserOperation hash и transaction hash.
- Событие фактического исполнения и финальность сети.
Итог
ERC-4337 строит программируемый путь над обычными EVM-транзакциями. Smart account проверяет собственную авторизацию, UserOperation описывает действие, bundler доставляет пакет, EntryPoint координирует проверку и расчёт gas, factory создаёт аккаунт, а paymaster при желании становится плательщиком.
Удобство появляется за счёт новых компонентов. Чтобы оценить кошелёк, недостаточно увидеть поддержку account abstraction. Нужно знать код аккаунта, правила recovery, версию EntryPoint, доступность bundlers, политику paymaster и способ окончательной проверки onchain-результата.
