Розробка Account Abstraction Paymaster
ERC-4337 Account Abstraction усуває головний бар'єр — залежність від нативного токена для газових комісій. Paymaster — це контракт, який бере оплату газу на себе, дозволяючи користувачам взаємодіяти з dApp без необхідності мати ETH. Перехід на gasless UX збільшує конверсію на 40% і знижує відтік користувачів на 30%. Наша команда з досвідом у блокчейн-розробці створює Paymaster-рішення під ключ, гарантуючи оптимальну газову ефективність та захист від атак. Ми використовуємо перевірені патерни та забезпечуємо безшовний UX для ігор, DeFi та соціальних додатків. Отримайте консультацію щодо вашого проєкту — пишіть, оцінимо безкоштовно.
Чому Paymaster критичний для gasless UX?
Без Paymaster користувачі зобов'язані купувати та тримати ETH для кожної транзакції. Це знижує конверсію в 2-3 рази порівняно з gasless досвідом. Paymaster вирішує проблему: він спонсорує газ або приймає оплату в будь-якому ERC-20 токені. Економія на газі для користувачів досягає 100%, а для бізнесу — зниження відтоку на 40%.
Як Paymaster вписується в ERC-4337
У стандартній транзакції: користувач → підписує транзакцію → платить gas в ETH. В ERC-4337 flow: користувач підписує UserOperation (не транзакцію) → Bundler збирає UserOps в батч → EntryPoint контракт викликає validatePaymasterUserOp → якщо Paymaster схвалює — платить gas → postOp викликається після виконання.
UserOperation {
sender, // smart account користувача
callData, // що виконати
paymasterAndData, // адреса Paymaster + його дані
signature, // підпис користувача
...gasFields
}
paymasterAndData — це address(paymaster) + bytes(paymasterSpecificData). Paymaster декодує свої дані з цього поля.
Типи Paymaster та їх архітектура
Verifying Paymaster (sponsored gas)
Найпоширеніший патерн: off-chain сервіс вирішує, чи спонсорувати конкретну UserOperation, і підписує дозвіл. Paymaster контракт верифікує цей підпис. EIP-4337 описує сигнатуру _validatePaymasterUserOp.
function _validatePaymasterUserOp(
UserOperation calldata userOp,
bytes32 userOpHash,
uint256 maxCost
) internal override returns (bytes memory context, uint256 validationData) {
// Декодуємо дані: підпис backend-а + термін дії
(uint48 validUntil, uint48 validAfter, bytes calldata signature) =
abi.decode(userOp.paymasterAndData[20:], (uint48, uint48, bytes));
// Хеш для верифікації = хеш UserOp + validUntil + validAfter
bytes32 hash = ECDSA.toEthSignedMessageHash(
keccak256(abi.encode(userOpHash, validUntil, validAfter))
);
// Якщо підпис від verifyingSigner — спонсоруємо
if (ECDSA.recover(hash, signature) != verifyingSigner) {
return ("", _packValidationData(true, validUntil, validAfter));
}
return ("", _packValidationData(false, validUntil, validAfter));
}
Backend отримує UserOp від frontend, перевіряє умови (користувач в whitelist? чи досяг ліміту безкоштовних транзакцій? чи тип операції дозволений?), підписує та повертає paymasterAndData. Frontend підставляє в UserOp і відправляє Bundler-у.
ERC-20 Paymaster (gas в токенах)
Користувач платить gas в USDC/USDT замість ETH. Paymaster приймає ERC-20 і поповнює свій ETH депозит в EntryPoint з власних коштів.
function _validatePaymasterUserOp(...)
internal override returns (bytes memory context, uint256 validationData) {
(address token, uint256 exchangeRate) =
abi.decode(userOp.paymasterAndData[20:], (address, uint256));
uint256 tokenCost = (maxCost * exchangeRate) / 1e18;
// Перевіряємо allowance користувача
require(
IERC20(token).allowance(userOp.sender, address(this)) >= tokenCost,
"Insufficient allowance"
);
// context передаємо в postOp для реального списання
return (abi.encode(userOp.sender, token, tokenCost), 0);
}
function _postOp(PostOpMode mode, bytes calldata context, uint256 actualGasCost)
internal override {
(address sender, address token, uint256 maxTokenCost) =
abi.decode(context, (address, address, uint256));
// Реальна вартість може бути менше maxCost
uint256 actualTokenCost = (actualGasCost * exchangeRate) / 1e18;
IERC20(token).transferFrom(sender, address(this), actualTokenCost);
}
Ключова складність ERC-20 Paymaster — exchange rate. Потрібен актуальний курс ETH/token на момент транзакції. Варіанти: Chainlink oracle, TWAP з Uniswap V3, або централізований price feed від backend.
Порівняння Verifying та ERC-20 Paymaster
| Критерій | Verifying Paymaster | ERC-20 Paymaster |
|---|---|---|
| Газові комісії | Безкоштовно для користувача | Оплата в токенах (низька комісія) |
| Складність реалізації | Середня (back-end signer) | Висока (оракул, ліквідність) |
| Ризик abuse | Високий, потрібен rate limiting | Низький (користувач платить) |
| UX | Максимально гладкий | Потрібен approve токена |
| Підтримка активів | Тільки ETH депозит | Будь-які ERC-20 |
Verifying Paymaster за продуктивністю в 2 рази швидше в інтеграції, але потребує жорстких лімітів. ERC-20 Paymaster дає гнучкість, але дорожчий у розробці. Вибір залежить від бізнес-моделі.
Як налаштувати rate limiting для Paymaster?
Без обмежень один користувач може дренувати весь бюджет через спам. Стратегії:
- Per-user spending limit. Off-chain в Verifying Paymaster backend: кожен адреса має місячний ліміт в USD. Backend відмовляє у підписі при перевищенні.
- Cooldown період. Не більше N транзакцій на годину на адресу. Зберігається в Redis з TTL.
- Transaction type whitelist. Backend перевіряє callData userOp: спонсоруються лише виклики конкретних контрактів.
- Reputation system. Нові акаунти отримують мінімальний ліміт, який зростає після верифікації (Worldcoin, Sign In With Ethereum + email).
Для per-user limit використовуємо Redis з ключем user:{address}:spent та TTL місяць. Cooldown реалізуємо через Redis з лічильником за годину. Whitelist зберігаємо в базі PostgreSQL. Backend підписує тільки якщо всі перевірки пройдені.
Депозит та управління балансом
Paymaster повинен тримати ETH депозит в EntryPoint контракті. EntryPoint списує gas з цього депозиту після кожної спонсорованої UserOperation.
// Поповнення депозиту
entryPoint.depositTo{value: 1 ether}(address(paymaster));
// Перегляд балансу
uint256 balance = entryPoint.balanceOf(address(paymaster));
// Виведення (unstake period для staked Paymaster)
entryPoint.withdrawTo(payable(owner), amount);
Для production потрібен моніторинг балансу та автоматичне поповнення. Якщо депозит вичерпається — всі UserOp через цей Paymaster почнуть ревертитися. Рекомендуємо: alert при балансі нижче порогу + auto-topup з treasury через Chainlink Automation або кастомний keeper.
Стек та інфраструктура
| Компонент | Технології |
|---|---|
| Paymaster контракт | Solidity + eth-infinitism/account-abstraction |
| Backend signer | Node.js + viem + власний signer wallet |
| Bundler | Stackup / Alchemy Bundler / власний (go-bundler) |
| Rate limiting | Redis + BullMQ |
| Моніторинг депозиту | Chainlink Automation / кастомний keeper |
| SDK для frontend | permissionless.js / ZeroDev SDK / Biconomy SDK |
| Тестування | Foundry + hardhat-deploy для fork-тестів |
Вибір Bundler провайдера
Bundler — сервіс, що приймає UserOperations та включає їх в блок. Варіанти:
- Alchemy — найпростіший старт, хороша документація, платний при масштабі
- Stackup — open-source bundler, можна self-host
- Pimlico — спеціалізується на AA, зручний Paymaster API
- Self-hosted (go-bundler) — повний контроль, потрібна інфраструктура
Що входить в роботу?
- Аудит архітектури та вибір типу Paymaster
- Розробка смарт-контракту з тестами (Foundry)
- Backend signer сервіс з API та rate limiting
- Інтеграція з frontend (SDK)
- Моніторинг балансу та автоматичне поповнення
- Документація та навчання команди
- Гарантія 6 місяців на контракти
Процес розробки
Аналітика (2-3 дні). Тип Paymaster (sponsored vs ERC-20), цільові мережі, ліміти та політики спонсорування, вибір Bundler провайдера.
Розробка контракту (1-2 тижні). Verifying або ERC-20 Paymaster, тести на EntryPoint v0.6/v0.7, deposit management.
Backend signer сервіс (1 тиждень). API для підпису UserOp, rate limiting, rate oracle (для ERC-20).
Інтеграція з frontend (3-5 днів). SDK підключення, UserOperation побудова, моніторинг статусу.
Моніторинг та операції (3-5 днів). Алерти на баланс, auto-topup, dashboard витрат.
Базовий Verifying Paymaster з rate limiting — 3-4 тижні. ERC-20 Paymaster з oracle та full моніторингом — 5-7 тижнів.
Замовте розробку Paymaster під ключ: залиште заявку, ми розрахуємо вартість та терміни протягом робочого дня. Зв'яжіться з нами для безкоштовної консультації щодо вашого проєкту.