이더리움 스마트 계정과 계정 추상화: UserOperation, 번들러, 가스 후원

일반적인 EOA 거래는 개인 키 서명으로 발신자를 증명하고, 계정의 거래 순번인 논스가 실행 순서를 제한합니다. 이 모델은 단순하지만 보통 같은 서명 키가 모든 동작을 승인합니다. EOA 거래 하나에는 최상위 동작이 하나 있지만, 대상 계약이 내부에서 다른 계약을 다시 호출할 수 있습니다.

이 설명은 기존 이더리움 대기 거래와 논스 안내에서 다룬 EOA 거래 풀과 혼동하지 않도록 출발점을 구분합니다. 스마트 계정은 자산을 보유하고 호출을 실행하는 계약입니다.

계약의 검증 코드는 단일 서명, 여러 서명의 임계값, 정해진 기간만 유효한 권한 등 계정별 규칙을 구현할 수 있습니다. ERC-4337은 이 로직을 실제 계정에 넣어 주는 지갑 제품이나 복구 정책을 하나로 정하지 않고, 계약 계정이 승인된 작업을 표현하고 실행할 인터페이스를 마련합니다.

Ethereum.org의 계정 추상화 설명은 백업 키, 제한된 권한, 가스 대납 등 가능한 사용 사례를 소개하지만, 모든 지갑이 이 기능을 지원한다는 뜻은 아닙니다.

따라서 “스마트 지갑”이라는 이름만으로 계정의 보안이나 보관 구조를 판단할 수 없습니다. 어떤 계약이 실제 자산을 보유하는지, 계정이 어떤 코드와 EntryPoint를 신뢰하는지, 어떤 서명자가 호출을 승인할 수 있는지 따로 살펴봐야 합니다. 계정 로직이 업그레이드 가능한 경우 관리자 권한과 변경 절차도 자산 통제의 일부입니다.

ERC-4337의 UserOperation은 스마트 계정이 하려는 작업을 묶어 표현하는 요청 객체입니다. 발신 스마트 계정 주소, 그 계정이 이해하는 논스, 호출 데이터, 서명, 가스 한도와 수수료 조건이 들어가며, 새 계정을 만드는 팩토리 정보나 paymaster 정보가 추가될 수도 있습니다. 실제 필드 구성은 EntryPoint 버전에 따라 달라질 수 있습니다.

지갑은 이 객체를 일반 거래용 eth_sendTransaction으로 곧장 체인에 보내는 대신, eth_sendUserOperation 같은 ERC-4337 RPC를 제공하는 번들러나 릴레이에 제출합니다. 이는 보통 거래가 모이는 EOA 거래 풀과 구분되는 UserOperation용 대기 공간을 거칩니다. UserOperation 해시는 요청을 추적하는 식별자이고, 번들러가 체인에 제출하는 실제 거래에는 별도의 이더리움 거래 해시와 영수증이 생깁니다.

ERC-7769 RPC 규격은 제출, 해시 조회와 UserOperation 영수증 조회 API를 정의합니다. UserOperation을 제출했다는 응답은 요청이 해당 번들러의 검증과 대기 풀에 받아들여졌다는 의미일 수 있지만, 블록 포함이나 앱 동작의 성공을 보장하지 않습니다. 수신한 번들러가 다른 번들러에 작업을 퍼뜨리는 방식도 인프라와 정책에 달려 있습니다. 한 제공자의 응답과 체인에서 실행된 결과를 구분해야 합니다.

번들러는 UserOperation을 받고, 지원하는 EntryPoint 버전에 맞는지 확인한 뒤 계정과 paymaster의 검증 로직을 미리 시뮬레이션합니다. 서명이 유효한지, 계정이 해당 EntryPoint를 신뢰하는지, nonce와 가스 조건이 맞는지, 후원 요청이 승인되는지를 살펴봅니다. 규칙에 맞지 않거나 실행 경로에서 예상 밖의 접근이 발생하면 요청을 거절할 수 있습니다.

ERC-4337 번들러 문서는 이 시뮬레이션과 묶음 제출의 역할을 설명합니다. 조건을 통과한 하나 이상의 UserOperation을 고른 뒤, 번들러는 일반 이더리움 거래 하나를 만들어 EntryPoint의 handleOps 함수를 호출합니다. 이 트랜잭션을 실제 블록에 포함할지는 블록 생산자의 선택과 네트워크 상태에 달려 있습니다. 번들러가 요청 해시를 돌려줬다는 사실은 작업이 정식 체인에 실행되었다는 증거가 아닙니다.

UserOperation 대기 풀은 EOA 거래 풀과 별도이며, 모든 제공자가 같은 요청을 공유한다고 가정할 수 없습니다. 따라서 한 번들러가 거절하거나 오래 기다리게 하는 경우가 생길 수 있고, 운영자나 지갑마다 지원하는 체인·EntryPoint 버전·정책이 다를 수 있습니다. 전송 상태를 확인할 때는 지갑의 UserOperation 상태, UserOperation 영수증, 그리고 번들 트랜잭션의 체인 영수증을 함께 구분해 보세요.

EntryPoint는 bundler의 handleOps 요청을 받아 계정의 검증 함수를 호출합니다. 계정은 신뢰하는 EntryPoint에서 온 호출인지, 서명과 자체 권한 규칙이 유효한지 확인합니다. ERC-4337 논스는 192비트 key와 64비트 sequence로 나뉩니다. EntryPoint가 계정과 key별 sequence를 검증하고 증가시키며, 계정은 key에 별도 의미를 부여하거나 추가 규칙을 둘 수 있습니다.

선택적으로 지정된 paymaster도 작업을 후원할지 검증합니다. 검증 단계가 허용되면 EntryPoint는 계정의 실행 함수를 호출해 callData가 나타내는 동작을 수행하고, 비용을 정산합니다. EntryPoint는 중심 계약이지만 지갑 개발자가 따로 프로토콜을 변경하지 않고도 계약 계정 흐름을 만들 수 있게 한 경유지입니다.

ERC-4337 EntryPoint 안내에서 이 검증·정산 역할을 확인할 수 있습니다. EntryPoint 주소와 버전, 지원 체인 여부는 지갑이 사용하는 실제 배포 정보로 확인해야 합니다. 시뮬레이션은 실행을 미리 보려는 유용한 점검이지 포함 약속은 아닙니다. 대기 시간 중 체인 상태, 수수료, 만료 조건이나 외부 계약 상태가 바뀌면 실제 검증이 달라질 수 있습니다.

검증은 통과했더라도 앱 호출이 실패하거나 되돌려질 수 있으며, 작업이 블록에 포함되었다는 사실만으로 의도한 토큰 이동이나 계약 동작이 성공했다고 판단해서는 안 됩니다.

UserOperation에 paymaster 정보를 넣으면 EntryPoint는 이 계약에 작업을 후원할 의사가 있는지 묻습니다. Paymaster는 앱이 수수료를 대신 부담하도록 하거나, 계정이 ETH를 따로 보유하지 않아도 작업을 시작하게 만들 수 있습니다. 일부 설계는 토큰 결제나 다른 사용자 조건을 붙일 수도 있지만, 이런 조건은 지갑과 paymaster 구현에 따라 다릅니다. 후원은 아무 조건 없이 가스가 사라진다는 뜻이 아닙니다.

Paymaster는 후원 대상 앱·사용자·횟수·금액을 제한하거나 작업 내용을 확인한 뒤 거절할 수 있습니다. EntryPoint에 넣은 예치금은 작업 비용을 지급하는 재원입니다. 별도의 stake가 요구되는 경우, 이는 오용 방지를 위한 담보 성격이며 예치금과 같은 돈이라고 볼 수 없습니다.

ERC-4337 paymaster 문서와 EIP-4337은 이 확인과 정산 흐름을 설명합니다. 앱 화면에 수수료가 0으로 표시되어도 비용이 발생하지 않은 것은 아닙니다.

후원자가 먼저 비용을 내고 나중에 구독료·토큰 결제·서비스 조건으로 사용자에게 일부 비용을 받을 수 있습니다. 약관상 부담자가 누구인지, 후원이 한도나 일회성 조건을 갖는지, 거래 실패 시에도 수수료가 청구될 수 있는지 확인하세요.

예를 들어 지갑이 지원한다면 사용자는 한 UserOperation 안에 앱 승인과 스왑 호출을 함께 넣을 수 있습니다. 두 동작은 한 작업으로 제출되어 EntryPoint를 거칩니다. 이것은 EOA에서 서명한 일반 거래 하나와 다른 흐름이며, 여러 UserOperation을 번들러가 하나의 체인 거래로 묶는 일과도 구분됩니다. 어느 구조가 사용됐는지 지갑의 미리보기에서 확인하세요. 가상의 수수료 예를 들면, 후원 정책이 승인한 작업의 최종 가스 비용이 0.0012 ETH라고 가정할 수 있습니다.

사용자의 계정 잔고가 아니라 paymaster의 EntryPoint 예치금에서 이 비용이 정산될 수 있습니다. 0.0012 ETH는 설명용 숫자이지 현재 시세나 실제 견적이 아닙니다. 실제 금액은 실행된 가스량, 수수료 조건과 네트워크에 따라 달라집니다. 묶음이나 여러 호출이 항상 더 싸거나 더 안전한 것은 아닙니다. 여러 동작의 원자성은 스마트 계정이 실패를 다루는 방식에 달려 있습니다. 하나가 실패했을 때 전체 호출을 되돌리는지, 일부 동작이 남을 수 있는지, 수수료가 누가 낼지 확인해야 합니다.

가스 한도 추정이 빗나가거나 지원 앱이 중단되면 작업은 거절되거나 실패할 수 있습니다. 일반 가스 필드의 관계는 이더리움 가스비 안내에서 확인할 수 있습니다.

스마트 계정은 여러 서명자를 두거나, 신뢰하는 복구자들이 정족수를 채우면 키를 교체하도록 구현될 수 있습니다. 일정 대기 시간을 두고 기존 키가 이의를 제기할 수 있게 만드는 설계도 가능합니다. 반대로 특정 단일 서명이 필수라면 그 키를 잃었을 때 접근을 회복할 경로가 없을 수 있습니다. ERC-4337은 계정이 자체 규칙에 따라 UserOperation을 검증하도록 하지만, 모든 계정에 백업 키나 사회적 복구 기능을 기본 제공하지 않습니다. 복구자가 너무 적거나 키 교체 규칙이 약하면 복구 계정이 공격 경로가 될 수 있습니다.

복구자가 지나치게 많거나 요건이 까다로우면 정당한 소유자도 복구가 늦어질 수 있습니다. 임계값, 대기 시간, 취소 권한, 복구 키의 보관 방법을 함께 살펴보세요. 보안 규칙은 복구 가능성뿐 아니라 누가 호출을 막거나 승인할 수 있는지도 바꿉니다. 계약 지갑이라는 이유만으로 비수탁 또는 수탁이라고 단정할 수 없습니다. 실제 통제권은 서명 키를 누가 쥐었는지, 계정의 관리자·업그레이드 권한이 있는지, hosted signer나 복구 서비스가 무엇을 승인할 수 있는지에 달려 있습니다.

자산을 보관하는 계약과 이를 제어하는 키·서비스를 나누어 확인하세요. 일반 시드 문구 백업과 복구의 범위는 지갑 시드 문구 복구 안내에서 별도로 다룹니다.

지갑의 미리보기에서 네트워크, 계정 주소, 대상 계약, 호출 내용, 토큰 승인 범위와 한 번에 포함된 호출 수를 살펴보세요. 서명은 화면에 표시된 하나의 동작뿐 아니라 여러 동작을 승인할 수 있습니다. 정확히 이해되지 않는 데이터에 서명하라는 요청이면 해당 앱과 지갑의 공식 도움말에서 의미를 확인하세요. 수수료를 누가 내는지 확인할 때는 paymaster의 이름만 보지 말고 적용 조건, 사용량 제한, 결제 대체 조건, 실패 시 비용 부담을 읽습니다.

후원이 유효하다는 표시는 앱이 무조건 무료라는 뜻이 아니며, paymaster가 선택한 작업을 언제든 거절할 수도 있습니다. 체인 혼잡이나 블록 포함 지연은 별도로 남아 있습니다. UserOperation이 오래 대기 중이라면 EOA 거래의 “speed up/cancel” 절차를 그대로 적용하지 마세요. 먼저 작업 해시와 해당 UserOperation 영수증을 확인하고, 번들 트랜잭션 해시가 있으면 블록 영수증과 실행 성공 여부도 봅니다.

RPC가 반환하는 영수증은 한 작업의 실제 비용·성공 여부와 묶음 거래 전체의 영수증을 구분할 수 있습니다. 이 구분은 EOA의 동일 논스 대체·취소와 다릅니다.