Paymaster (пеймастер): как спонсируются комиссии в Account Abstraction

Зачем нужен paymaster

В классической модели Ethereum:

• транзакцию всегда подписывает EOA;
• комиссию за газ платит сам отправитель;
• платить нужно именно в ETH (см. Комиссии в Ethereum (gas fee) и Газ в Ethereum).

Это неудобно:

• новичкам приходится сначала «купить немного ETH на газ»;
• приложениям сложно субсидировать комиссии или брать их в своих токенах;
• любая «магия UX» требует централизованных костылей.

В AA-модели:

• аккаунт пользователя — смарт-контракт;
• логика оплаты газа становится настраиваемой;
• paymaster выступает «плательщиком за газ» за определённые условия.

Итог: пользователю можно показать привычную схему «платишь в стейблкоине за операцию», а технические детали оплаты газа в ETH берёт на себя paymaster.

Как paymaster работает в ERC-4337

Упрощённый цикл для UserOperation:

• Кошелёк AA формирует UserOp:
  • заполняет callData (что сделать);
  • указывает ограничение по газу;
  • добавляет данные paymaster’а (paymasterAndData), если комиссия должна оплачиваться не напрямую из аккаунта.

• UserOperation попадает в мемпул UserOp, откуда её забирает бандлер.

• Бандлер вызывает EntryPoint-контракт, который:
  • дергает функцию проверки аккаунта (validateUserOp);
  • при наличии paymaster’а вызывает его validatePaymasterUserOp.

• Paymaster:
  • проверяет условия (баланс у пользователя, whitelist, подписи, лимиты);
  • принимает решение — готов ли он оплатить gas за эту UserOp;
  • резервирует средства (или просто берёт обязательство заплатить).

• Если всё ок, UserOp исполняется, а в конце:
  • EntryPoint списывает фактический gas fee с paymaster’а;
  • при необходимости paymaster списывает с пользователя оплату в своём токене или учитывает её во внутреннем учёте.

Важно: с точки зрения протокола Ethereum всё это — просто взаимодействие контрактов на L1; вся логика AA живёт «поверх» через EntryPoint и смарт-контракты.

Какие бывают схемы paymaster’ов

На практике встречается несколько основных моделей:

• Gasless / sponsored-транзакции.

Приложение или сервис полностью оплачивает газ за пользователя:

• промо-кампании, онбординг;
• UX в стиле Web2 («подписка на сервис, комиссии скрыты внутри тарифа»).

• Оплата газа токенами (ERC-20 и др.).

Пользователь платит комиссию в токене:

• стейблкоин (USDT/USDC/DAI и др.);
• токен DeFi-протокола;
• любая другая монета на EVM-сети.

Paymaster в этом случае:

• получает токены от пользователя;
• конвертирует часть в ETH или покрывает газ из собственного пула.

• Спонсируемый UX с условиями.

Газ оплачивается при соблюдении правил:

• пользователь прошёл KYC/регистрацию;
• использует определённый маршрут/продукт (например, конкретный DEX);
• выполняет действия в рамках кампании (квесты, кэшбэк и т.п.).

• B2B-модели.

Paymaster выступает как инфраструктурный сервис:

• dApp платит фиксированную ставку за «пакет транзакций» пользователей;
• paymaster агрегирует риски и оптимизирует расходы на газ.

Риски и векторы атак вокруг paymaster’ов

Появление paymaster-уровня добавляет новые риски:

• Фрод и злоупотребления пользователями.

Если paymaster неаккуратно контролирует лимиты, атакующий может:

• посылать бессмысленные UserOp и сжигать газ за счёт paymaster’а;
• пытаться обойти лимиты и получать «бесплатный» gas.

• DoS на paymaster.

Массовый спам UserOp в его сторону может:

• перегрузить логику validatePaymasterUserOp;
• привести к расходу средств paymaster’а или блокировке его работы.

• Централизация и доверие.

Пользователь, полагаясь на paymaster, часто:

• доверяет ему условия (KYC, лимиты, списания токенов);
• может столкнуться с выборочной цензурой (paymaster отказывается обслуживать часть адресов).

• Ошибки в логике конверсии и биллинга.

Если paymaster конвертирует токены в ETH или ведёт сложный учёт:

• баги в расчётах могут приводить к убыткам;
• важны лимиты и защитные механизмы (кап на курс, временные окна, sanity-checkи).

С точки зрения безопасности AA-протоколов аудит paymaster’ов становится столь же критичен, как аудит core-контрактов (Аудит смарт-контрактов).

Paymaster, L2 и мультичейн-экосистема

Модель paymaster’ов особенно интересна в контексте L2-роллапов:

• комиссии там ниже, чем в L1, поэтому субсидировать газ проще;
• можно строить paymaster’ы, работающие сразу в нескольких сетях:
  • один и тот же UX кошелька AA;
  • единые правила лимитов и биллинга;
  • разные источники gas/ETH для каждой сети.

При этом для каждой L2-сети нужно учитывать:

• собственную модель газа и комиссий;
• возможные отличия в реализации ERC-4337-инфраструктуры;
• мосты и риски при переводе токенов между сетями (см. Мосты между блокчейнами и Риски мостов (Bridge Risks)).

На что смотреть пользователю и разработчику

Если вы:

• пользователь AA-кошелька:
  • кто именно выступает paymaster’ом (приложение, инфраструктурный сервис, биржа);
  • в каких токенах вы фактически платите комиссию;
  • какие данные вы передаёте (KYC, привязка телефона/почты и т.п.).

• разработчик dApp или кошелька:
  • как реализованы лимиты и защита от спама;
  • что будет, если paymaster внезапно перестанет обслуживать операции;
  • предусмотрен ли fallback-сценарий — оплата газа напрямую из аккаунта-контракта пользователя.

Грамотный дизайн paymaster-слоя позволяет получить «магический» UX без скрытых сюрпризов по рискам и централизации.

См. также

• Account Abstraction (AA)
• UserOperation (UserOp)
• Транзакция
• Газ в Ethereum
• Комиссии в Ethereum (gas fee)
• Стандарт токенов ERC-20
• Аудит смарт-контрактов