가스리스는 두 개의 인프라 서비스다

목적: 번들러는 가스를 선지불하고 페이마스터는 실행이 실패해도 책임을 지므로, 둘 다 자체 리스크 통제를 적용합니다. 애플리케이션은 모든 거절을 "트랜잭션 실패"로 뭉뚱그리지 말고 그 서비스들의 결정을 드러내야 합니다. ERC-4337 스마트 계정은 일반 트랜잭션을 보내지 않습니다. 번들러가 UserOperation 을 시뮬레이션하고 제출하며, 페이마스터가 가스비 후원 여부를 결정할 수 있습니다. EntryPoint 컨트랙트가 받아들일 동작도 이 두 서비스가 거절할 수 있습니다.

동작 방식: 같은 UserOperation 을 두 번들러와 두 스폰서십 정책으로 보내고, 시뮬레이션·정책·할당량·예치금·포함·실행 실패를 분류하며, 사용자 자금 fallback 을 정의합니다. ### PoC 같은 UserOperation 을 두 번들러에 보내고 두 가지 페이마스터 정책을 적용합니다. RPC 호환성, 시뮬레이션, 평판 정책, 할당량, 만료된 스폰서십, 부족한 페이마스터 예치금, 포함 타임아웃, 실행 revert 를 서로 다른 실패로 기록합니다. 그다음 후원 없이 사용자 자금으로 재시도합니다. ### 무엇을 증명하나 "가스리스"는 두 오프체인 서비스와 하나의 온체인 컨트랙트로 조립된 애플리케이션 약속입니다. 이식성은 엔드포인트만 바꾸는 것이 아닙니다: 오류 분류, EntryPoint 버전, 스폰서십 데이터, 대체 자금 경로까지 함께 동작해야 합니다. 참고: [ERC-4337 bundlers](https://docs.erc4337.io/bundlers/index.html), [paymaster security](https://docs.erc4337.io/paymasters/security-and-griefing).

검토 후 보완: ### 유효성은 가용성이 아니다 이 스택에서 유일하게 신뢰가 필요 없는 당사자는 EntryPoint 컨트랙트입니다 — 잘 만든 UserOperation 을 주면 받아들입니다. 하지만 사용자와 EntryPoint 사이에 **자기 돈을 먼저 쓰는** 두 서비스가 있습니다. **번들러**는 번들을 올리려 가스를 선지불하고, **페이마스터**는 호출이 revert 돼도 책임을 집니다. 확신 전에 지불하므로 로컬 리스크 통제를 걸고, 둘 중 누구든 체인이 받아줬을 op 를 거부할 수 있습니다. 그래서 "가스리스"는 지갑의 속성이 아니라 **가용성·정책** 주장입니다 — `rpc-view-not-consensus`(RPC 응답은 노드 하나의 관점), `receipt-is-not-settlement`(성공 응답이 곧 송금은 아님)과 같은 계열, 그 **계정 추상화 버전**입니다. 해피 패스가 서비스 결정을 숨깁니다. ### 돈을 따라가라 — 왜 각 서비스가 거부하나 모든 실패 유형은 두 서비스가 자본을 지키는 행위, 또는 컨트랙트 자체로 매핑됩니다: | 실패 | 누가 일으키나 | 무엇을 지키나 | | --- | --- | --- | | RPC 호환 | 번들러 | 당신 EntryPoint 버전을 말하기는 하나 | | 시뮬레이션 | 번들러 | 검증은 금지 opcode·타 계정 스토리지 금지(그리핑 방지) | | 평판/스로틀링 | 번들러 | ERC-7562: 시뮬 낭비하는 계정/페이마스터는 스로틀·밴 | | 포함 타임아웃 | 번들러 | 시뮬은 통과, 안 올라감 | | 정책 | 페이마스터 | 이 호출자/행위를 후원할까 | | 할당량 | 페이마스터 | 한도 소진 | | 만료된 후원 | 페이마스터 | 서명된 후원 데이터 시간 초과 | | 예치금 부족 | 페이마스터 | EntryPoint 예치·스테이크 부족 | | 실행 revert | EntryPoint | 검증 통과, 실제 호출 실패 | 레퍼런스의 그리핑 규칙이 *이유의 이유*입니다 — 평판·시뮬레이션은 악성 계정이 번들러에게 헛가스를 태우게 만들 수 있어서 존재합니다. 분류표는 요식이 아니라 그 적대적 설계의 표면입니다. ### 진짜 산출물은 분류표다 — 유형마다 대응이 정반대이기 때문 여덟 원인이 지금은 쓸모없는 "transaction failed" 하나로 뭉개지지만, 올바른 반응은 유형마다 다르고 때로는 정반대입니다: | 실패 | 올바른 대응 | | --- | --- | | 할당량/예치금 소진 | **사용자 자금** 폴백 | | 만료된 후원 | 서명 재요청 후 **후원** 재시도 | | 평판 밴 | **번들러 교체** | | 포함 타임아웃 | 재제출, 필요 시 다른 번들러 | | 실행 revert | **중단** — 재시도는 무의미, 비후원이면 사용자 실제 가스만 태움 | `x402-settlement-retry` 의 재시도 분류 규율과 같고, 이때 필요한 폴백 상태기계 — 생존, 올바른 방식의 재시도, 대기, 가시성 유지 — 가 바로 `temporal-durable-execution` 이 다루는 것입니다. ### 이식성이 날카로운 사업 포인트 — 그리고 EntryPoint 버전이 함정 "같은 UserOperation 을 두 번들러로"는 엔드포인트 교체처럼 들리지만 아닙니다. **EntryPoint v0.6 대 v0.7/0.8 은 UserOp 구조와 `paymasterAndData` 레이아웃이 달라**, "같은" op 가 스택 간 바이트 동일이 아닙니다. 후원 데이터 포맷·에러 코드·폴백 자금 경로도 제공자마다 다릅니다. 그래서 멀티 번들러 복원력은 진짜 엔지니어링이고, 열화나 제공자 전환을 못 하는 가스리스 제품은 광고하지 않는 단일 장애점을 안고 있습니다. ### 폴백은 UX 의 고백 "비후원으로 사용자 자금 재시도"는 가스리스가 **최선노력(best-effort)**임을 조용히 인정합니다. 정직한 설계지만 — 계정이 열화 경로용 가스 자산을 실제로 *보유*해야 하고, 앱은 새 동의 없이 사용자 돈을 언제 쓸지 정해야 합니다. 후원→사용자 지불로의 무단 전환은 사용자가 거부(veto)하고 싶을 정책 결정입니다 — 이 카드가 `embedded-wallet-policy` 와 `agentic-intent-veto` 에 닿는 지점입니다.