Разработка Paymaster контракта (ERC-4337)

Разработка Paymaster контракта (ERC-4337)

ERC-4337 (Account Abstraction) решает одну из главных проблем onboarding'а в Web3: новый пользователь не может взаимодействовать с dApp, пока у него нет ETH на оплату газа. Paymaster — смарт-контракт, который берёт на себя оплату газа за пользователей. Это либо полное спонсирование («gasless transactions»), либо оплата газа в ERC-20 токенах вместо ETH.

Как Paymaster вписывается в стек ERC-4337

ERC-4337 не меняет протокол Ethereum — он работает поверх через отдельный уровень инфраструктуры. Ключевые компоненты:

• UserOperation — объект, описывающий действие пользователя (аналог транзакции)
• Bundler — нода, которая собирает UserOperations и отправляет их через EntryPoint контракт
• EntryPoint — единственный контракт, верифицированный ERC-4337 сообществом (одинаковый адрес на всех EVM-чейнах)
• Paymaster — опциональный контракт, который оплачивает газ вместо пользователя

Поток: пользователь подписывает UserOperation → bundler проверяет через симуляцию → EntryPoint вызывает validatePaymasterUserOp → если ok, выполняет операцию → вызывает postOp для итогового расчёта.

Два типа Paymaster и их реализация

Sponsoring Paymaster (газ бесплатно для пользователя)

Простейший случай: студия хочет, чтобы пользователи их dApp не платили газ. Paymaster депонирует ETH в EntryPoint (entryPoint.depositTo(paymasterAddress)) и одобряет UserOperations от нужных аккаунтов.

Критическая часть — функция validatePaymasterUserOp:

function validatePaymasterUserOp(
    UserOperation calldata userOp,
    bytes32 userOpHash,
    uint256 maxCost
) external returns (bytes memory context, uint256 validationData)

Здесь нужно решить: кого спонсировать? Без проверки любой может дренировать депозит Paymaster. Стандартные подходы:

Whitelist по адресу. Простейший — список разрешённых Smart Account адресов. Подходит для beta с ограниченным числом пользователей.

Off-chain подпись. Paymaster-сервер (backend) проверяет условия (KYC, подписку, баланс) и выдаёт подпись, которую пользователь включает в paymasterData поле UserOperation. Paymaster on-chain проверяет ECDSA-подпись от доверенного ключа. Это позволяет динамически управлять логикой спонсирования без изменения контракта. OpenZeppelin предоставляет VerifyingPaymaster как reference implementation.

Лимиты по времени и объёму. validAfter и validUntil в validationData позволяют ограничить окно валидности UserOperation — защита от replay в будущих блоках.

ERC-20 Paymaster (газ в токенах)

Пользователь платит газ в USDC или в native-токене проекта. Сложнее, потому что курс ETH/USDC нужно получать on-chain. Здесь необходим ценовой оракул — Chainlink Price Feed.

Поток расчёта:

1. validatePaymasterUserOp — читаем цену ETH/USDC из Chainlink, рассчитываем maxCost в токенах, делаем transferFrom с аккаунта пользователя
2. Операция выполняется
3. postOp — рассчитываем реальный gas cost (он известен точно только после выполнения), возвращаем излишек или доначисляем

Проблема postOp mode == PostOpMode.postOpReverted: если postOp ревертится, EntryPoint вызывает его ещё раз с mode = postOpReverted. Если контракт не обрабатывает этот кейс, он входит в бесконечный цикл ревертов. Нужно явно проверять mode и корректно обрабатывать оба состояния.

Безопасность: что может пойти не так

Gas griefing через злонамеренный postOp. Если пользовательский Smart Account может заставить postOp потреблять больше gas, чем ожидалось — Paymaster переплачивает. Защита: устанавливать postOpGasLimit с запасом, но не безлимитно.

Манипуляция ценой через Chainlink. При использовании spot-цены Chainlink без TWAP атакующий теоретически может провести flash-loan атаку для временного изменения цены оракула. В большинстве случаев для Paymaster достаточно Chainlink с проверкой staleness (цена не обновлялась более 1 часа — отклонять операцию).

Исчерпание депозита. Нужен мониторинг баланса EntryPoint. Если депозит опускается ниже порога — операции начинают отклоняться без понятного error message для пользователя. Автоматическое пополнение через Keeper или Gelato Automation.

Стек и инфраструктура

• Контракт: Solidity 0.8.x, OpenZeppelin BasePaymaster, EntryPoint v0.6 или v0.7
• Тестирование: Hardhat с @account-abstraction/sdk или Foundry с fork mainnet
• Bundler: Stackup, Alchemy AA SDK, Pimlico — для тестирования и продакшна
• SDK для фронтенда: permissionless (viem-based) или @alchemy/aa-sdk
• Мониторинг депозита: The Graph или кастомный indexer

Работаем с EntryPoint v0.7 (последняя версия на Ethereum mainnet). Если проект требует совместимости с v0.6 — нужна отдельная версия Paymaster, интерфейсы несовместимы.

Процесс разработки

Аналитика. Определяем тип Paymaster (спонсор vs. ERC-20), логику верификации, лимиты спонсирования.

Разработка. Наследуем от OpenZeppelin BasePaymaster, реализуем _validatePaymasterUserOp и _postOp. Отдельно деплоим backend-сервис для off-chain подписи если нужен.

Тестирование. Fork mainnet в Hardhat, деплой EntryPoint (он уже есть по стандартному адресу), тесты с реальным bundler flow через @account-abstraction/sdk.

Деплой и мониторинг. Деплой на целевые чейны, депозит ETH в EntryPoint, настройка алертов на баланс депозита.

Сроки

Sponsoring Paymaster с whitelist-верификацией — 3 рабочих дня. Paymaster с off-chain подписью и backend-сервисом — 4-5 дней. ERC-20 Paymaster с Chainlink интеграцией — 5-7 дней.

Стоимость рассчитывается индивидуально.