https://eips.ethereum.org/EIPS/eip-4337
Custodial Wallet? Non-Custodial Wallet?
web3 서비스를 이용하다보면 커스터디 월렛, 논-커스터디 월렛이라는 용어를 사용합니다.
Custodial Wallet
서비스 제공자가 사용자의 private key를 대신 보관하고 관리하는 지갑
특징
- 사용자는 private key를 직접 관리하지 않음
- 로그인 기반 (이메일, OAuth 등)으로 접근 가능
- UX가 Web2 서비스처럼 간단함
- 서비스가 계정을 복구하거나 접근을 제한할 수 있음
장점
- 사용하기 쉬움 (초보자 친화적)
- 사용자의 키 분실 리스크 없음
- 빠른 온보딩
단점
- 서비스가 자산을 통제할 수 있음
- 해킹 또는 내부 사고 시 리스크 큼(SPOF)
- “Not your key, not your coin”
Non-Custodial Wallet
Non-Custodial Wallet은 사용자가 자신의 private key를 직접 관리하는 지갑
특징
- private key를 사용자 본인이 보관
- 모든 트랜잭션은 사용자가 직접 서명
- !!누구도!! 계정을 임의로 통제할 수 없음
장점
- 완전한 자산 소유권
- 검열 저항성
- 탈중앙성 유지
단점
- 키 분실 시 복구 불가능
- UX가 어렵고 진입장벽 높음
- gas fee, 네트워크 이해 필요
Account Abstraction : 계정 추상화
AA 는 왜 등장했는가
기존 EOA의 문제점
- 모든 tx는 EOA private key 서명이 필요
- gas fee는 반드시 ETH로만 지불 가능
- ETH Funding이 꼭 필요함
- nonce 관리 강제
- 하나의 private key가 곧 계정 자체
- 서명 정책 커스터마이징 불가능
- recovery / session key / multi-sig 등을 구현하려면 별도 구조 필요
EOA vs Account Abstraction 비교
| 항목 | EOA | AA |
|---|---|---|
| 서명 주체 | Private Key만 가능 | 원하는 검증 로직 적용 가능 |
| Gas 지불 | ETH만 가능 | Paymaster를 통해 확장 가능(대납 등) |
| 복구 | 불가능 | 가능 |
| 멀티시그 | 외부 구현 필요 | 내장 가능 |
Definitions : 구성 항목
-
UserOperation : 유저 행동을 정의하는 정보를 갖고 있는 데이터 구조체. 흔히 사용하는 transaction과 비슷한 개념이지만 같은 것은 아니기 때문에
UserOperation이라는 용어 사용 -
Sender : 추상화된 하나의 계정.
UserOperation을 보내는 계정이며, 일반적으로 스마트 컨트랙트 계정(Account Contract)을 의미함 -
Owner : 추상화된 계정의 주인 계정. Sender에 대한 통제권과 소유권을 갖고있음을 증명할 수 있는 계정이며 일반적으로 Private Key를 사용하는 EOA 계정
-
EntryPoint :
UserOperation을 검증하고 실행하는 중심 컨트랙트. Bundler는 여러UserOperation을 모아EntryPoint.handleOps()를 호출하고, EntryPoint는 각 Account의 검증 로직과 실행 로직을 호출함 -
Bundler : UserOperation mempool에서
UserOperation들을 수집하고, 이를 하나의 일반 Ethereum transaction으로 묶어 EntryPoint에 제출하는 주체 -
Paymaster : 사용자의 gas 비용을 대신 지불하거나, ETH가 아닌 다른 방식으로 gas 비용을 처리할 수 있게 해주는 선택적 컨트랙트. 예를 들어 서비스가 gas를 sponsor하거나, 사용자가 토큰으로 gas 비용을 지불하는 구조를 만들 수 있음
-
AccountFactory : Account Contract를 생성하는 컨트랙트. 사용자의 Account가 아직 배포되지 않은 경우,
UserOperation의initCode를 통해 Factory가 Account를 생성할 수 있음 -
UserOperation mempool : ERC-4337 표준 검증 규칙을 따르는 공개 UserOperation mempool. Bundler들이 공통 규칙에 따라 UserOperation을 수집하고 검증할 수 있도록 설계된 기본 mempool 개념
-
Deposit : EntryPoint에 예치된 ETH 잔액. Account 또는 Paymaster가 gas 비용 정산을 위해 EntryPoint에 미리 예치해두는 자금
AA 동작방식
- userOperation을 생성합니다.
{
"sender" : "",
"nonce" : "",
"factory" : "",
"factoryData" : "",
"callData" : "",
"callGasLimit" : "",
"verificationGasLimit" : "",
"preVerificationGas" : "",
"maxFeePerGas" : "",
"maxPriorityFeePerGas" : "",
"paymaster" : "",
"paymasterVerificationGasLimit" : "",
"paymasterPostOpGasLimit" : "",
"paymasterData" : "",
"signature" : "",
}-
생성된 userOperation의 실행 주체는 sender입니다. sender가 생성한 userOp 이 맞다는 서명을 owner 계정을 통해 생성합니다.
-
생성된 userOperation 과 signature를 alt_mempool 에 제출합니다.
-
bundler는 alt_mempool에 등록된 userOperation 정보(signature 포함)를 가지고 entryPoint의 handleOps() 함수를 호출합니다.
-
handleOps() 함수는 내부적으로 account contract의 validateUserOp을 통해 userOperation을 검증합니다.
-
paymaster가 지정되었다면 validatePaymasterUserOp을 통해 paymaster도 검증합니다.
-
bundler가 handleOps()를 네트워크에 전송할 때 가스토큰을 지불합니다.
-
userOperation이 실행이 끝나면 사용한 gas 만큼 bundler가 user/paymaster로부터 돌려받습니다.
-
user/paymaster의 deposit에서 돌려받게 되며, atomic하게 정산됩니다.
validateUserOp의 의미
기존 Ethereum 에서는
이 트랜잭션이 유효한, 즉 트랜잭션을 전송하는 사람이 계정의 주인이 맞는지
를 검증하기 위하여 ECDSA 서명 검증 로직이 protocol 내부에 고정되어있습니다.
: transaction data 를 생성 -> 계정 소유자가 private key로 서명 -> 프로토콜 레벨에서 ECDSA 서명검증 -> 검증 성공 시 tx 실행
하지만 AA 에서는 이 검증 과정을 원하는 방식으로 직접 구현할 수 있으며 그로 인해 다음 기능들을 구현할 수 있습니다.
- owner signature 검증
- multiSig 검증
- 특정 시간대만 사용 가능
- 특정 dApp만 허용
- 등
기존 Ethereum에서는 “유효한 서명”의 기준이 protocol에 고정되어 있었다면,
ERC-4337에서는 그 검증 기준 자체를 Account Contract가 직접 정의할 수 있게 됩니다.
paymaster 예시
gas sponsor
- 사용자는 ETH 없음
- 서비스는 Paymaster 운영
- 사용자는 단순 서명만 수행
- Paymaster가 gas sponsor
- 사용자는 Web2처럼 서비스 이용
ERC20 gas payment
사용자는 USDC만 보유
→ Paymaster가 ETH gas를 대신 지불
→ 이후 User의 USDC를 차감
AA로 가능한 것들
계정 추상화는 계정들로 하여금 다음을 가능하게 합니다.
- 가스비 대납
- 일반 ERC-20 토큰으로 가스비 지불
- 트랜잭션 배치 실행
- 계정사용정책 적용
- 계정 signer 로테이션
- 등등
마무리
ERC-4337은 단순히 “가스비를 대신 내주는 기술”이 아닙니다.
기존 Ethereum의 EOA는 강력하고 단순했지만, 계정 자체의 동작 방식을 프로그래밍할 수는 없었습니다.
하지만 Account Abstraction에서는 계정(Account)이 하나의 Smart Contract가 되며,
“어떤 요청을 유효하다고 판단할 것인가” 자체를 개발자가 정의할 수 있게 됩니다.
즉, 계정이 단순한 private key의 소유 개념을 넘어:
- 정책을 가질 수 있고
- 복구 기능을 가질 수 있으며
- 여러 서명 방식을 사용할 수 있고
- 서비스 목적에 맞는 UX를 직접 구현할 수 있는
하나의 programmable entity가 됩니다.
그리고 ERC-4337은 이러한 구조를 consensus layer 변경 없이 Ethereum 위에서 구현하기 위한 현실적인 접근입니다.
결국 Account Abstraction은 단순한 기능 추가가 아니라,
“Ethereum 계정 모델 자체를 소프트웨어적으로 확장 가능하게 만든 변화”
라고 볼 수 있겠습니다.
