Розробка Account Abstraction Paymaster

Розроблення Account Abstraction Paymaster

ERC-4337 Account Abstraction прибирає один з головних барʼєрів входу в Web3: користувач більш не зобов'язаний тримати нативний токен (ETH, MATIC, BNB) для оплати газу. Paymaster — контракт у ERC-4337 стеку, який бере на себе оплату газу від імені користувача. Це ключовий компонент для застосунків, де gasless UX — конкурентна вимога: onboarding нових користувачів, gaming, соціальні застосунки.

Як Paymaster вписується у ERC-4337

У стандартній транзакції: користувач → підписує транзакцію → платить газ у ETH. У ERC-4337 флоу: користувач підписує UserOperation (не транзакцію) → Bundler збирає UserOps у батч → EntryPoint контракт викликає validatePaymasterUserOp → якщо Paymaster затвердить — платить газ → postOp викликається після виконання.

UserOperation {
    sender,           // смарт-рахунок користувача
    callData,         // що виконати
    paymasterAndData, // адреса Paymaster + його дані
    signature,        // підпис користувача
    ...gasFields
}

paymasterAndData — це address(paymaster) + bytes(paymasterSpecificData). Paymaster декодує свої дані з цього поля.

Типи Paymaster та їх архітектура

Verifying Paymaster (спонсорована газ)

Найбільш поширений паттерн: off-chain сервіс вирішує, спонсирувати лі конкретну UserOperation, та підписує дозвіл. Paymaster контракт верифікує цю підпис.

contract VerifyingPaymaster is BasePaymaster {
    address public verifyingSigner;

    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 (газ у токенах)

Користувач платить газ в 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.

Депозит та управління балансом

Paymaster повинен тримати ETH депозит в EntryPoint контракті. EntryPoint списує газ з цього депозиту після кожної спонсорованої UserOperation.

// Поповнення депозиту
entryPoint.depositTo{value: 1 ether}(address(paymaster));

// Перегляд балансу
uint256 balance = entryPoint.balanceOf(address(paymaster));

// Вивід (unstake період для staked Paymaster)
entryPoint.withdrawTo(payable(owner), amount);

Для production потрібен моніторинг балансу та автоматичне поповнення. Якщо депозит іссякне — всі UserOp через цей Paymaster почнуть ревертитися. Рекомендуємо: alert при балансі нижче порогу + auto-topup з treasury через Chainlink Automation або кастомний keeper.

Rate limiting та захист від abuse

Без обмежень один користувач може дренувати весь бюджет Paymaster через spam транзакцій. Стратегії захисту:

Per-user spending лімітом. Off-chain у Verifying Paymaster backend: кожна адреса має місячний ліміт у USD. Backend відмовляє у підписі при перевищенні.

Cooldown період. Не більше N транзакцій на годину на адресу. Зберігається у Redis з TTL.

Transaction type whitelist. Backend перевіряє UserOp callData: спонсируються тільки вызови конкретних контрактів (вашого застосунку), не довільні транзакції.

Reputation система. Нові рахунки отримують мінімальний ліміт, який растет з часом або після верифікації (Worldcoin Proof of Humanity, Sign In With Ethereum + email).

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

Вибір Bundler провайдера

Bundler — сервіс, що приймає UserOperations та включає їх у блок. Варіанти:

• Alchemy — найпростіший старт, хорошо документовано, платний при масштабі
• Stackup — open-source bundler, можна self-host
• Pimlico — спеціалізується на AA, зручний Paymaster API
• Self-hosted (go-bundler) — повний контроль, потрібна інфраструктура

Процес розроблення

Аналітика (2-3 дні). Тип Paymaster (sponsored vs ERC-20), цільові мережи, лімити та політики спонсирування, вибір Bundler провайдера.

Розроблення контракту (1-2 тижні). Verifying або ERC-20 Paymaster, тести на EntryPoint v0.6/v0.7, управління депозитом.

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 та повним мониторингом — 5-7 тижнів.