Paymaster와 가스 정책

도입

Paymaster는 "사용자에게 gas를 무료로 보이게 하는 기능"이 아니라 sponsor risk를 떠안는 contract다. ERC-4337에서 UserOperation이 paymaster 정보를 포함하면 EntryPoint는 validation 단계에서 Paymaster를 호출하고, 실행 후 postOp으로 실제 비용과 회계 처리를 마무리할 수 있다.

Stablecoin checkout에서는 Paymaster가 강력한 UX 개선을 만든다. 사용자는 ETH 없이 USDC로 결제하고, merchant나 앱이 gas를 sponsor할 수 있다. 하지만 실패한 operation도 sponsor 비용을 태울 수 있으므로 policy, deposit, stake, monitoring이 함께 설계되어야 한다.

학습 목표

• gas sponsorship의 정책과 abuse risk를 설계한다.
• paymaster 예산과 사용자 한도를 운영 지표로 만든다.

개념 설명

Paymaster 흐름은 validation과 post-operation accounting으로 나뉜다.

Paymaster policy는 아래 축으로 쪼개야 한다.

코드로 확인하기

paymaster는 무료 gas 버튼이 아니다. 어떤 operation을 대신 지불할지 결정하는 risk engine이다. 정책은 contract와 backend 양쪽에 나뉘어 구현된다.

컨트랙트paymaster 검증에서 허용 selector 제한

01function validatePaymasterUserOp(02    PackedUserOperation calldata userOp,03    bytes32 userOpHash,04    uint256 maxCost05) external returns (bytes memory context, uint256 validationData) {06    if (msg.sender != entryPoint) revert OnlyEntryPoint();0708    bytes4 selector = bytes4(userOp.callData[0:4]);09    if (!sponsoredSelectors[selector]) revert SelectorNotSponsored(selector);10    if (maxCost > maxSponsoredGasCost) revert GasCostTooHigh(maxCost);1112    address account = userOp.sender;13    _consumeDailyQuota(account, maxCost);14    return (abi.encode(account, maxCost, userOpHash), 0);15}

이 코드에서 중요한 것은 paymaster가 모든 호출을 지원하지 않는다는 점이다. checkout, claim, refund처럼 제품이 설명 가능한 action만 sponsor해야 한다.

백엔드sponsorship 사전 판단

01type SponsorshipPolicy = {02  allowedSelectors: Set<string>;03  dailyGasLimit: bigint;04  usedToday: bigint;05  riskScore: number;06};0708function decideSponsorship(selector: string, estimatedCost: bigint, policy: SponsorshipPolicy) {09  if (!policy.allowedSelectors.has(selector)) return { allow: false, reason: "selector_blocked" };10  if (policy.usedToday + estimatedCost > policy.dailyGasLimit) return { allow: false, reason: "quota_exceeded" };11  if (policy.riskScore >= 80) return { allow: false, reason: "risk_score_high" };12  return { allow: true, reason: "sponsored" };13}

backend는 사용자가 서명하기 전에 sponsorship 가능성을 알려준다. 이 단계가 없으면 사용자는 "gasless"라고 믿고 서명했는데 bundler 단계에서 거절되는 경험을 하게 된다.

인덱서sponsor budget과 거절 사유 집계

01select02  date_trunc('hour', created_at) as bucket,03  rejection_reason,04  count(*) as rejected_ops,05  sum(estimated_gas_cost) as blocked_gas_cost06from paymaster_decisions07where allowed = false08group by bucket, rejection_reason09order by bucket desc;

paymaster 정책은 배포 후에도 계속 조정된다. selector_blocked가 많으면 UX 설명이 부족할 수 있고, quota_exceeded가 늘면 merchant sponsor budget을 재설계해야 한다.

강의 포인트

실무 예시

merchant sponsored checkout을 생각해보자. merchant는 구매 전환율을 높이기 위해 gas를 sponsor하지만, 아무 UserOperation이나 받아주면 sponsor deposit이 공격자에게 소모될 수 있다.

흔한 오해와 실패 시나리오

실습 과제

1. Paymaster와 가스 정책 이해 점검: token, merchant, method, value, risk, gas, budget 기준으로 policy table을 작성한다.
2. abuse 시나리오 작성: replay abuse, gas griefing, whitelist bypass, stake draining, postOp accounting failure를 각각 방어 조건과 연결한다.
3. 대시보드 지표 정의: sponsor spend, rejection rate, gas per successful payment, postOp failure, remaining deposit, cap usage를 정의한다.
4. checkout 연결: stablecoin 결제 금액과 gas sponsor 비용을 하나의 reconciliation ledger로 연결하는 필드를 설계한다.

완료 기준

1. paymaster 정책 축을 정의했다.
2. abuse 방어 조건을 작성했다.
3. 대시보드 지표를 정했다.

근거 자료

• Paymaster 가스 정책: 05-계정추상화-에이전트결제/03-Paymaster-가스-정책.md
• ERC-4337: Account Abstraction: https://eips.ethereum.org/EIPS/eip-4337
• ERC-4337 Documentation: Paymasters: https://docs.erc4337.io/paymasters/