Bundler и UserOperation: как работают транзакции ERC-4337

UserOperation — это подписанный объект намерения, определённый стандартом ERC-4337: он описывает, что смарт-контрактный аккаунт хочет сделать и как это действие должно быть проверено и оплачено. В отличие от обычной транзакции Ethereum это не объект уровня протокола, подписанный управляемым извне аккаунтом: его подпись проверяет сам контракт аккаунта, и он не обязан оплачивать собственный нативный газ. Bundler — это офчейн-участник, который собирает UserOperation из выделенного альтернативного мемпула, симулирует каждую из них, упаковывает действительные в одну обычную транзакцию Ethereum и вызывает канонический контракт EntryPoint, а тот проверяет каждую операцию пакета прежде, чем выполнить хотя бы одну. Bundler авансирует реальный газ со своего собственного EOA и получает возмещение ончейн от аккаунта-отправителя или от paymaster'а этого аккаунта. Необязательный контракт paymaster может согласиться покрыть операцию на этом шаге проверки — именно здесь комиссии становятся спонсируемыми или оплачиваемыми в токене ERC-20 вместо нативного газового токена сети.

Краткое напоминание об ERC-4337

ERC-4337 — это стандарт Ethereum для абстракции аккаунтов — способ дать смарт-контрактным аккаунтам ту же первоклассную способность инициировать и оплачивать действия, которая всегда была у управляемых извне аккаунтов (EOA), без каких-либо изменений базового протокола. Вместо изменения уровня консенсуса ERC-4337 вводит параллельную систему объектов более высокого уровня и офчейн-инфраструктуры, которая в итоге рассчитывается через обычные транзакции Ethereum. Если сначала вам нужна версия с нуля, объяснение что такое абстракция аккаунтов охватывает мотивацию, что такое ERC-4337 описывает весь стандарт, а смарт-аккаунты против EOA напрямую сравнивает два типа аккаунтов. Эта статья приближается к механике: объектам, которые движутся через систему, и участникам, которые их обрабатывают. Обратите внимание, что ERC-4337 — это стандарт EVM: он применяется к Ethereum и EVM-совместимым сетям, но не к сетям вне EVM, таким как Solana или TON.

Что такое UserOperation на самом деле

Центральный объект в ERC-4337 — UserOperation. Внешне он похож на транзакцию, но его лучше понимать как подписанное заявление о намерении: «вот что мой аккаунт хочет сделать, и вот параметры для проверки и оплаты этого». Это структура, передаваемая контракту в виде calldata, а не нативный объект протокола — базовый уровень о нём никогда не слышал.

По сути UserOperation несёт в себе:

• sender — смарт-контрактный аккаунт, от имени которого действует операция.
• nonce — защита от повтора, которую EntryPoint отслеживает как значение из двух частей (ключ плюс последовательность), так что аккаунт может вести несколько независимых дорожек nonce вместо одной строгой очереди.
• callData — то, что аккаунт должен выполнить, часто пакет из нескольких вызовов в одной операции.
• данные развёртывания аккаунта — необязательные; разворачивают контракт аккаунта на самой первой его операции, и именно так смарт-аккаунт можно пополнить по известному, детерминированно выведенному адресу ещё до того, как он появится ончейн.
• лимиты газа — отдельные бюджеты на проверку и на выполнение, плюс величина preVerificationGas, которая компенсирует bundler'у calldata и накладные расходы, не поддающиеся измерению самим EntryPoint.
• параметры комиссии — максимальная комиссия и максимальная приоритетная комиссия, по образцу EIP-1559.
• данные paymaster'а — необязательные; какой контракт будет спонсировать операцию и какой контекст ему для этого нужен.
• подпись — проверяется собственной функцией валидации аккаунта, а не протоколом.

Точная кодировка менялась от версии к версии EntryPoint — v0.7 разносит блобы развёртывания и paymaster'а по явным полям и упаковывает несколько значений газа вместе, тогда как v0.6 использовала единые байтовые строки initCode и paymasterAndData — но по смыслу содержимое одно и то же. Если вы делаете интеграцию, уточните, на какую версию EntryPoint нацелен ваш bundler.

Ключевое отличие от обычной транзакции — в том, кто и что её подписывает. Обычная транзакция Ethereum должна быть подписана приватным ключом EOA по фиксированной схеме ECDSA, и этот же аккаунт платит газ. UserOperation проверяется собственной логикой смарт-контрактного аккаунта отправителя — которая может реализовывать любую схему подписи, правило нескольких ключей, сессионный ключ или политику авторизации, определённую аккаунтом, — и она вовсе не обязана платить за себя нативным газом. В этой гибкости и весь смысл: аккаунт, а не протокол, решает, как выглядит допустимое действие.

Альтернативный мемпул, где они живут

UserOperation не попадают в обычный мемпул транзакций Ethereum, потому что они ещё не транзакции. Вместо этого они транслируются в отдельный альтернативный мемпул (часто называемый alt-мемпул) — одноранговую сеть, посвящённую объектам ERC-4337. На практике кошелёк или dApp отправляет такую операцию, вызывая eth_sendUserOperation на RPC-эндпоинте bundler'а; тот может разослать её в общий alt-мемпул или оставить в собственном приватном пуле. Так или иначе, инфраструктура, которая потребляет эти объекты, слушает именно здесь, а не мемпул базового уровня. Такое разделение держит трафик абстракции аккаунтов вне критичного для консенсуса пути до того момента, пока он не будет упакован в настоящую транзакцию.

Роль bundler'а

Bundler — это офчейн-участник, превращающий намерения в ончейн-реальность. Его работа состоит из четырёх частей. Во-первых, он собирает UserOperation из альтернативного мемпула. Во-вторых, он симулирует и проверяет каждую из них — запуская логику проверки аккаунта в симулированном контексте, чтобы подтвердить, что подпись действительна, nonce верен, а аккаунт или его paymaster может покрыть стоимость. В-третьих, он упаковывает одну или несколько действительных UserOperation в одну обычную транзакцию Ethereum. В-четвёртых, он отправляет эту транзакцию в сеть со своего собственного EOA, авансируя газ базового уровня и рассчитывая на возмещение ончейн.

Одной симуляции для защиты мало, потому что состояние может измениться между симуляцией и включением в блок. Поэтому ERC-4337 ещё и ограничивает то, что разрешено делать коду проверки: во время фазы проверки аккаунт или paymaster не может читать метки времени блоков и другие значения окружения, которые позволили бы ему вести себя ончейн иначе, чем в симуляции, а его доступ к хранилищу по большей части ограничен слотами, связанными с его собственным аккаунтом. От контрактов, действующих от имени многих пользователей — особенно от фабрик и paymaster'ов — ожидается внесение стейка, чтобы один недобросовестный контракт не мог дёшево обесценить сразу большую часть мемпула. Эти правила существуют ради одного: сделать симуляцию bundler'а надёжным предсказанием того, что произойдёт ончейн.

Поскольку bundler авансирует газ и зарабатывает комиссии за включение, он ведёт себя во многом как специализированный сборщик блоков для трафика абстракции аккаунтов. Его защищает именно шаг симуляции и проверки: он не станет включать в пакет операцию, которая не смогла бы ему возместить затраты.

Контракт EntryPoint

Всё сходится в едином каноническом смарт-контракте под названием EntryPoint. Это синглтон, развёрнутый для каждой версии по одному и тому же адресу во всех EVM-сетях, и именно он хранит депозиты, из которых оплачиваются операции. Транзакция bundler'а — это вызов EntryPoint с массивом UserOperation, после чего EntryPoint выполняет строгий двухфазный цикл.

В фазе проверки для каждой операции он вызывает функцию проверки аккаунта-отправителя (и paymaster'а, если он указан), чтобы перепроверить подпись, nonce и договорённость об оплате ончейн, и резервирует максимально возможную стоимость с того, кто платит. Только после того как все операции в пакете проверены, он переходит к фазе выполнения, где направляет calldata каждой операции её аккаунту, чтобы фактически выполнить перевод, своп или другое действие, а затем рассчитывает реальную стоимость и возвращает неиспользованный резерв.

Это разделение важно: проверка и выполнение разделены так, чтобы гарантии оплаты пакета устанавливались до запуска любой работы, изменяющей состояние, и чтобы EntryPoint мог точно учитывать газ сразу по многим операциям. Оно же означает, что сбой одной операции во время выполнения не отравляет остальные операции пакета.

Где место paymaster'а

Paymaster — это необязательный контракт, который соглашается оплатить UserOperation от имени аккаунта. Когда UserOperation включает данные paymaster'а, EntryPoint во время фазы проверки спрашивает этот paymaster, будет ли он спонсировать операцию и на каких условиях; paymaster возвращает решение и блоб контекста. После выполнения EntryPoint вызывает paymaster ещё раз, в постоперационном шаге, передавая фактически израсходованный газ, — и именно тут paymaster, берущий плату в токене, рассчитывает точную сумму. Paymaster может согласиться безусловно (настоящее спонсирование без газа, когда стоимость берёт на себя приложение) или согласиться в обмен на ценность — что наиболее полезно, списывая с пользователя оплату в токене ERC-20 вместо нативного газа. Для более подробного разбора этого компонента см. что такое paymaster. Paymaster — это точка в процессе, которая отделяет «чем платит пользователь» от «в чём получает оплату сеть».

Как обрабатываются газ и сбои

Газ в ERC-4337 многослоен. Bundler платит реальный ETH за внешнюю транзакцию; EntryPoint измеряет газ проверки и выполнения каждой UserOperation относительно объявленных ею лимитов; а тот, кто отвечает по счёту — аккаунт или его paymaster — должен был внести в EntryPoint достаточно, чтобы покрыть счёт, который рассчитывается в конце пакета. Следствие, которое стоит знать: операция ERC-4337 обходится в несколько больший газ, чем эквивалентная обычная транзакция, потому что поверх самого действия вы оплачиваете проверку на уровне контракта и бухгалтерию EntryPoint.

Сбои сдерживаются благодаря дизайну «сначала проверка». Если операция даёт сбой во время ончейн-проверки, откатился бы весь пакет, поэтому bundler отбрасывает её и пересобирает пакет, вместо того чтобы допустить такое, — именно для этого и нужна его офчейн-симуляция. Если операция проходит проверку, но её выполнение откатывается, эффекты выполнения откатываются, тогда как уже потраченный газ всё равно учитывается и оплачивается, так что bundler не остаётся без вознаграждения за честную работу. Именно из-за этой асимметрии bundler'ы так тщательно симулируют: их защита от грифинга — это отказ включать что-либо, что не возместит им затрат.

Жизненный цикл по шагам

1. Ваш кошелёк собирает UserOperation: sender, nonce, calldata, лимиты газа, параметры комиссии, необязательные данные paymaster'а.
2. Paymaster, если он используется, согласует условия спонсирования до того, как операция будет разослана.
3. Логика подписи вашего аккаунта подписывает её — и это не обязательно один ключ ECDSA.
4. Кошелёк отправляет её на RPC bundler'а, и она попадает в альтернативный мемпул.
5. Bundler симулирует и проверяет её по правилам стандарта об ограниченных опкодах и доступе к хранилищу.
6. Bundler упаковывает её вместе с другими операциями в одну транзакцию Ethereum, вызывающую handleOps у EntryPoint, и платит газ базового уровня.
7. EntryPoint проверяет каждую операцию, выполняет calldata каждой из них, списывает стоимость с депозитов, возвращает излишек и возмещает затраты bundler'у.

Что это даёт владельцу кошелька

Механика замысловатая, но её смысл прост и полезен: объединение нескольких действий в одно подтверждение (например, approve и своп вместе), спонсируемые комиссии или комиссии, оплаченные токеном, схемы подписи помимо единственного ключа secp256k1, политики трат и сессионные ключи, а также социальное восстановление или восстановление по устройству. Стоит отметить, что EIP-7702 позволяет обычному EOA временно исполняться с кодом смарт-аккаунта, что сокращает разрыв по части некоторых из этих возможностей, не заменяя описанную выше инфраструктуру ERC-4337.

Как это использует WATS

В EVM-сетях WATS опирается ровно на один элемент этого процесса: на слот paymaster'а. Когда вы делаете перевод, своп или стейкинг в WATS Hot Wallet, UserOperation, которую собирает ваш кошелёк, указывает paymaster, и именно он позволяет списывать комиссию в ATS, а не в нативном газовом токене сети, — так что вам не приходится держать в каждой сети остаток ETH, BNB или POL просто ради возможности что-то отправить. От вас не требуется запускать bundler, выбирать версию EntryPoint или заводить RPC-ключ bundler'а: это инфраструктура, а задача кошелька — собрать корректную UserOperation и отправить её.

Два уточнения, чтобы всё было честно. Первое: оплата в ATS — это не скидка. Сеть по-прежнему берёт свою обычную комиссию, а paymaster её оплачивает, так что меняется лишь то, какой токен уходит с вашего баланса, а не сама стоимость. Второе: ERC-4337 существует только в EVM, поэтому в Solana и TON роль paymaster'а играет эквивалентная схема плательщика комиссии, а не описанный здесь процесс с EntryPoint. ATS — это OFT на LayerZero, и именно это позволяет одному балансу ATS покрывать комиссии в Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana и TON; собранный ATS сжигается, снижая предложение со 100 000 000 до нижней границы в 30 000 000. WATS полностью некастодиален на всём протяжении: ключи держите вы, а WATS не держит ни одного.

Если вы хотите увидеть этот процесс как работающую систему, а не как спецификацию, конкретный шаг такой: попробуйте сделать перевод в WATS Hot Wallet в сети, где у вас нет нативного газового токена. UserOperation, bundler и EntryPoint делают своё дело за кадром, а комиссия уходит с вашего баланса ATS. Как работает модель комиссии ATS разбирает механику от начала до конца.