Bundler와 UserOperation: ERC-4337 트랜잭션은 어떻게 작동하는가

UserOperation은 ERC-4337이 정의하는 서명된 의도 객체입니다. 스마트 컨트랙트 계정이 무엇을 하고자 하는지, 그리고 그 동작을 어떻게 검증하고 무엇으로 지불할지를 명시합니다. 일반적인 이더리움 트랜잭션과 달리 외부 소유 계정이 서명하는 프로토콜 수준의 객체가 아닙니다. 그 서명은 계정 컨트랙트 자신이 검사하며, 자신의 네이티브 가스를 스스로 지불할 필요도 없습니다. bundler는 전용 대체 멤풀에서 UserOperation을 수집하고, 각각을 시뮬레이션한 뒤, 유효한 것들을 단일 일반 이더리움 트랜잭션에 담아 정본 EntryPoint 컨트랙트를 호출하는 오프체인 주체입니다. EntryPoint는 배치 안의 어떤 동작이든 실행하기 전에 모든 동작을 먼저 검증합니다. bundler는 자신의 EOA에서 실제 가스를 선지급하고, 발신 계정 또는 그 계정의 paymaster로부터 온체인에서 상환받습니다. 선택적인 paymaster 컨트랙트는 바로 그 검증 단계에서 어떤 동작의 비용을 대신 부담하기로 합의할 수 있으며, 수수료가 후원되거나 체인의 네이티브 가스 토큰 대신 ERC-20 토큰으로 지불 가능해지는 지점이 여기입니다.

ERC-4337 빠른 요약

ERC-4337은 계정 추상화를 위한 이더리움 표준입니다. 즉, 기반 프로토콜을 전혀 변경하지 않고도, 외부 소유 계정(EOA)이 늘 가져왔던 것과 동일한, 동작을 개시하고 그 비용을 지불하는 일급(first-class) 능력을 스마트 컨트랙트 계정에 부여하는 방법입니다. ERC-4337은 합의 계층을 수정하는 대신, 궁극적으로 일반적인 이더리움 트랜잭션을 통해 정산되는 상위 수준 객체와 오프체인 인프라의 병렬 시스템을 도입합니다. 기초부터 알고 싶다면 계정 추상화란 무엇인가 설명이 그 동기를 다루고, ERC-4337이란 무엇인가가 전체 표준을 정리하며, 스마트 계정과 EOA 비교가 두 계정 유형을 직접 견줍니다. 이 글은 메커니즘을 확대해서 봅니다. 시스템을 통과하는 객체들과 그것을 처리하는 주체들입니다. ERC-4337은 EVM 표준이라는 점에 유의하세요. 이는 이더리움과 EVM 호환 체인에 적용되며, Solana나 TON 같은 비EVM 체인에는 적용되지 않습니다.

UserOperation이란 실제로 무엇인가

ERC-4337의 핵심 객체는 UserOperation입니다. 표면적으로는 트랜잭션처럼 보이지만, 서명된 의도 선언으로 이해하는 편이 낫습니다. "내 계정이 하고자 하는 일은 이것이고, 이를 검증하고 지불하기 위한 매개변수는 이러하다." UserOperation은 컨트랙트에 calldata로 전달되는 구조체이지 네이티브 프로토콜 객체가 아닙니다. 기반 계층은 그런 것이 있다는 사실조차 알지 못합니다.

UserOperation이 실질적으로 담고 있는 것은 다음과 같습니다.

• sender — 해당 동작이 대신 수행하는 스마트 컨트랙트 계정.
• nonce — 재전송 방지 값. EntryPoint가 키와 시퀀스로 이루어진 두 부분 값으로 추적하므로, 계정은 하나의 엄격한 대기열이 아니라 서로 독립적인 여러 nonce 레인을 운용할 수 있습니다.
• callData — 계정이 실행해야 할 내용. 한 동작 안에 여러 호출을 묶은 배치인 경우가 많습니다.
• 계정 배포 데이터 — 선택 사항. 맨 처음 동작에서 계정 컨트랙트를 배포합니다. 덕분에 스마트 계정은 온체인에 존재하기도 전에, 결정론적으로 도출된 알려진 주소로 자금을 받을 수 있습니다.
• 가스 한도 — 검증용과 실행용으로 나뉜 예산, 그리고 EntryPoint가 스스로 계측할 수 없는 calldata와 부대 비용을 bundler에게 보상하는 preVerificationGas 값.
• 수수료 매개변수 — EIP-1559을 그대로 따르는 최대 수수료와 최대 우선 수수료.
• paymaster 데이터 — 선택 사항. 어떤 컨트랙트가 해당 동작을 후원할지, 그리고 그것이 필요로 하는 컨텍스트.
• 서명 — 프로토콜이 아니라 계정 자신의 검증 함수가 검사합니다.

정확한 인코딩은 EntryPoint 버전에 따라 달라져 왔습니다. v0.6이 단일 initCode와 paymasterAndData 바이트 문자열을 쓴 반면, v0.7은 배포 데이터와 paymaster 데이터를 명시적인 필드로 분리하고 여러 가스 값을 함께 묶습니다. 다만 개념적인 내용물은 동일합니다. 직접 연동한다면 사용하는 bundler가 어떤 EntryPoint 버전을 대상으로 하는지 확인하세요.

일반 트랜잭션과의 핵심 차이는 누가 그리고 무엇이 서명하느냐입니다. 통상적인 이더리움 트랜잭션은 고정된 ECDSA 방식을 사용하는 EOA의 개인키로 서명되어야 하며, 바로 그 계정이 가스를 지불합니다. UserOperation은 발신자 자신의 스마트 컨트랙트 계정 로직에 의해 검증되며—이는 계정이 정의하는 어떤 서명 방식, 다중 키 규칙, 세션 키, 승인 정책이든 구현할 수 있습니다—네이티브 가스로 스스로 비용을 지불할 필요가 전혀 없습니다. 바로 그 유연함이 핵심입니다. 프로토콜이 아니라 계정이 유효한 동작이 무엇인지 결정합니다.

이들이 거주하는 대체 멤풀

UserOperation은 아직 트랜잭션이 아니기 때문에 일반적인 이더리움 트랜잭션 멤풀에 들어가지 않습니다. 대신 별도의 대체 멤풀(흔히 alt-mempool이라 부릅니다)로 브로드캐스트됩니다. 이는 ERC-4337 객체 전용의 P2P 네트워크입니다. 실제로는 지갑이나 dApp이 bundler의 RPC 엔드포인트에 eth_sendUserOperation을 호출해 하나를 제출하며, 그 bundler는 이를 공용 alt-mempool로 전파할 수도 있고 자체 프라이빗 풀에 담아둘 수도 있습니다. 어느 쪽이든, 이 객체들을 소비하는 인프라는 기반 계층 멤풀이 아니라 여기를 청취합니다. 이 분리는 계정 추상화 트래픽을, 실제 트랜잭션으로 패키징되는 순간까지 합의에 중요한 경로에서 떼어놓습니다.

bundler의 역할

bundler는 의도를 온체인 현실로 바꾸는 오프체인 주체입니다. 그 일은 네 부분으로 나뉩니다. 첫째, 대체 멤풀에서 UserOperation을 수집합니다. 둘째, 각각을 시뮬레이션하고 검증합니다. 즉, 시뮬레이션된 컨텍스트에서 계정의 검증 로직을 실행하여 서명이 유효한지, nonce가 올바른지, 계정 또는 그 paymaster가 비용을 감당할 수 있는지 확인합니다. 셋째, 하나 이상의 유효한 UserOperation을 단일 일반 이더리움 트랜잭션에 담습니다. 넷째, 자신의 EOA에서 그 트랜잭션을 네트워크에 제출하며, 기반 계층 가스를 선지급하고 온체인에서 상환받기를 기대합니다.

시뮬레이션만으로는 충분한 보호가 되지 않습니다. 시뮬레이션과 포함 사이에 상태가 바뀔 수 있기 때문입니다. 그래서 ERC-4337은 검증 코드가 할 수 있는 일도 제약합니다. 검증 단계 동안 계정이나 paymaster는 블록 타임스탬프를 비롯해, 시뮬레이션할 때와 온체인에서 다르게 동작하게 만들 수 있는 환경 값을 읽을 수 없고, 스토리지 접근도 대체로 자기 계정에 연관된 슬롯으로 제한됩니다. 또한 다수의 사용자를 대신해 동작하는 컨트랙트, 특히 팩토리와 paymaster는 스테이크를 예치할 것이 요구됩니다. 잘못 행동하는 컨트랙트 하나가 멤풀의 상당 부분을 값싸게 한꺼번에 무효화하지 못하도록 하기 위해서입니다. 이 규칙들이 존재하는 이유는 단 하나, bundler의 시뮬레이션이 온체인에서 벌어질 일에 대한 믿을 만한 예측이 되게 하기 위해서입니다.

bundler는 가스를 선지급하고 포함에 대한 수수료를 벌어들이므로, 계정 추상화 트래픽을 위한 특화된 블록 빌더처럼 행동합니다. 그것을 보호하는 것은 시뮬레이션-및-검증 단계입니다. bundler는 자신에게 상환하지 못할 동작은 묶지 않습니다.

EntryPoint 컨트랙트

모든 것은 EntryPoint라는 단일한 정본 스마트 컨트랙트로 수렴합니다. 이는 싱글턴으로, 버전별로 EVM 체인 전반에서 동일한 주소에 배포되며, 동작 비용을 지불하는 예치금을 보관합니다. bundler의 트랜잭션은 UserOperation 배열과 함께 EntryPoint를 호출하는 것이고, 그러면 EntryPoint는 엄격한 2단계 루프를 실행합니다.

검증 단계에서는 각 동작에 대해 발신 계정의 검증 함수를(그리고 지정된 경우 paymaster의 검증 함수를) 호출하여 서명, nonce, 지불 약정을 온체인에서 재확인하고, 지불하는 쪽으로부터 가능한 최대 비용을 예약합니다. 배치 내 모든 동작이 검증된 후에야 실행 단계로 넘어가, 각 동작의 calldata를 해당 계정으로 디스패치하여 실제로 전송, 스왑, 또는 기타 동작을 수행하고, 이어서 실제 비용을 정산하고 쓰지 않은 예약분을 환급합니다.

이 분리는 중요합니다. 상태를 변경하는 작업이 실행되기 전에 배치의 지불 보증이 확립되도록, 그리고 EntryPoint가 한 번에 여러 동작에 걸쳐 가스를 정확하게 계측할 수 있도록 검증과 실행이 분리됩니다. 또한 한 동작이 실행 중 실패해도 배치 안의 다른 동작들을 오염시킬 수 없다는 뜻이기도 합니다.

paymaster가 자리하는 곳

paymaster는 계정을 대신해 UserOperation의 비용을 지불하기로 합의하는 선택적 컨트랙트입니다. UserOperation이 paymaster 데이터를 포함하면, EntryPoint는 검증 단계 동안 그 paymaster에게 해당 동작을 후원할 것인지 그리고 어떤 조건으로 할 것인지 묻고, paymaster는 그 결정과 컨텍스트 데이터를 돌려줍니다. 실행 후에는 EntryPoint가 실제로 사용된 가스와 함께 사후 처리 단계에서 paymaster를 다시 호출하며, 토큰으로 청구하는 paymaster가 정확한 금액을 정산하는 곳이 바로 여기입니다. paymaster는 무조건 수락(앱이 비용을 흡수하는 진정한 가스리스 후원)할 수도 있고, 대가를 받고 수락할 수도 있습니다. 가장 유용하게는, 네이티브 가스 대신 ERC-20 토큰으로 사용자에게 청구하는 것입니다. 이 구성 요소에 대한 더 깊은 설명은 paymaster란 무엇인가를 참고하세요. paymaster는 흐름 속에서 "사용자가 무엇으로 지불하는가"를 "네트워크가 무엇으로 지급받는가"로부터 분리하는 고리입니다.

가스와 실패는 어떻게 처리되는가

ERC-4337에서 가스는 계층적입니다. bundler는 외부 트랜잭션에 대해 실제 ETH를 지불하고, EntryPoint는 각 UserOperation의 검증 및 실행 가스를 선언된 한도에 대비해 계측하며, 책임이 있는 쪽—계정 또는 그 paymaster—은 청구액을 감당할 만큼 EntryPoint에 예치해 두어야 하고, 이는 배치 마지막에 정산됩니다. 알아둘 만한 귀결이 하나 있습니다. ERC-4337 동작은 동등한 평범한 트랜잭션보다 가스를 다소 더 씁니다. 동작 자체에 더해 컨트랙트 수준의 검증과 EntryPoint의 장부 처리 비용까지 지불하기 때문입니다.

실패는 검증 우선 설계로 봉쇄됩니다. 어떤 동작이 온체인 검증 중 실패하면 배치 전체가 되돌려지므로, bundler는 그런 일이 벌어지게 두는 대신 그 동작을 빼고 배치를 다시 구성합니다. 오프체인 시뮬레이션이 존재하는 이유가 바로 이것입니다. 동작이 검증을 통과했으나 실행이 되돌려지면(revert), 실행의 효과는 롤백되는 한편 이미 소비된 가스는 여전히 회계 처리되어 지불됩니다. 그래서 bundler는 정직한 작업에 대해 보상받지 못하는 일이 없습니다. 이 비대칭성이 바로 bundler가 그토록 신중하게 시뮬레이션하는 이유입니다. 그리핑에 대한 그들의 보호책은 자신에게 상환하지 못할 것은 무엇도 포함하지 않는 것입니다.

생애 주기를 순서대로

1. 지갑이 UserOperation을 조립합니다. sender, nonce, calldata, 가스 한도, 수수료 매개변수, 그리고 선택적인 paymaster 데이터.
2. paymaster를 쓴다면, 동작이 브로드캐스트되기 전에 후원 조건에 서명해 승인합니다.
3. 계정의 서명 로직이 그것에 서명합니다. 반드시 단일 ECDSA 키일 필요는 없습니다.
4. 지갑이 그것을 bundler의 RPC로 제출하고, 대체 멤풀에 들어갑니다.
5. bundler가 표준의 제한된 옵코드 및 스토리지 규칙 아래에서 그것을 시뮬레이션하고 검증합니다.
6. bundler가 그것을 다른 동작들과 함께 EntryPoint의 handleOps를 호출하는 하나의 이더리움 트랜잭션에 담고, 기반 계층 가스를 지불합니다.
7. EntryPoint가 모든 동작을 검증하고, 각각의 calldata를 실행하고, 예치금에 대비해 비용을 정산하고, 초과분을 환급하고, bundler에게 상환합니다.

이것이 지갑 사용자에게 주는 것

기계 장치는 정교하지만, 그 목적은 소박하고 쓸모 있습니다. 여러 동작을 한 번의 승인으로 묶기(예컨대 approve와 스왑을 함께), 후원되거나 토큰으로 지불되는 수수료, 단일 secp256k1 키가 아닌 서명 방식, 지출 정책과 세션 키, 그리고 소셜 또는 기기 기반 복구입니다. 참고로 EIP-7702는 평범한 EOA가 일시적으로 스마트 계정 코드로 실행되도록 해주며, 위에서 설명한 ERC-4337 인프라를 대체하지 않으면서 이 기능들 가운데 일부의 격차를 좁힙니다.

WATS는 이를 어떻게 활용하는가

EVM 체인에서 WATS는 이 흐름 중 정확히 한 조각에 의존합니다. 바로 paymaster 자리입니다. WATS Hot Wallet에서 전송, 스왑, 또는 스테이킹을 하면, 지갑이 조립하는 UserOperation이 paymaster를 지정하고, 그 paymaster가 당신의 수수료를 체인의 네이티브 가스 토큰이 아니라 ATS로 청구되게 해줍니다. 그래서 자산을 움직일 수 있게 하려고 모든 네트워크마다 ETH, BNB, POL 잔돈을 남겨둘 필요가 없습니다. 당신에게 bundler를 운영하거나, EntryPoint 버전을 고르거나, bundler RPC 키를 보유하라고 요구하지 않습니다. 그것은 인프라이고, 지갑의 일은 유효한 UserOperation을 조립해 제출하는 것입니다.

정직을 위해 두 가지를 분명히 해둡니다. 첫째, ATS로 지불하는 것은 할인이 아닙니다. 네트워크는 여전히 통상적인 수수료를 청구하고 paymaster가 그것을 정산하므로, 바뀌는 것은 당신의 잔액에서 빠져나가는 토큰이지 그 밑에 깔린 비용이 아닙니다. 둘째, ERC-4337은 EVM 전용이므로 Solana와 TON에서는 여기서 설명한 EntryPoint 흐름 대신 동등한 fee-payer 방식이 paymaster의 역할을 합니다. ATS는 LayerZero OFT이며, 그 덕분에 단일 ATS 잔액이 Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana, TON 전반의 수수료를 감당합니다. 그리고 징수된 ATS는 소각되어 공급량을 100,000,000개에서 30,000,000개 하한선까지 낮춥니다. WATS는 그 전 과정에서 완전히 논커스터디얼입니다. 키는 당신이 보유하며, WATS는 결코 키를 보유하지 않습니다.

이 흐름을 명세서가 아니라 작동하는 시스템으로 보고 싶다면, 구체적인 단계는 네이티브 가스 토큰을 하나도 보유하지 않은 체인에서 WATS Hot Wallet으로 전송을 시도해 보는 것입니다. UserOperation과 bundler와 EntryPoint는 보이지 않는 곳에서 제 일을 하고, 수수료는 당신의 ATS 잔액에서 빠져나갑니다. ATS 수수료 모델이 어떻게 작동하는지가 그 메커니즘을 처음부터 끝까지 다룹니다.