계정 추상화는 고정된 EOA 서명 규칙 대신 스마트 계약 코드가 계정의 검증·복구·일괄 실행 규칙을 정하게 하는 접근입니다. ERC-4337에서는 UserOperation을 번들러가 모아 EntryPoint 계약에 제출하며, paymaster가 수수료를 대신 낼 수도 있지만 각 구성요소의 실패와 권한을 따로 확인해야 합니다.
추상화하는 것은 계정 주소가 아니라 검증 규칙이다
전통적 EOA 거래는 프로토콜이 정한 개인키 서명과 nonce 규칙을 따른다. 계정 추상화는 계정 계약이 다중 서명, 패스키, 세션 키, 복구자, 지출 한도 같은 검증 로직을 표현할 수 있게 한다. 사용자가 키를 잃었을 때의 복구도 애플리케이션 규칙으로 만들 수 있다.
ERC-4337은 합의 계층을 바꾸지 않고 별도 UserOperation 흐름과 EntryPoint 계약을 사용한다. 추상화는 인증이 사라지는 것이 아니라 인증 판단 위치가 고정 프로토콜 규칙에서 계정 코드로 이동한다.
기능이 많아질수록 설정 권한의 의미가 커진다. 복구자 추가, 모듈 설치, 세션 키 발급은 한 번의 전송보다 오래 영향을 미칠 수 있다. 지갑 화면은 단순 성공 여부 외에 어떤 장기 권한이 바뀌는지 보여 줘야 한다.
| 구성요소 | 역할 | 점검 위험 |
|---|---|---|
| Smart Account | 검증·실행 규칙 보유 | 소유자·모듈·업그레이드 |
| UserOperation | 사용자 의도와 수수료 조건 표현 | 서명 범위·nonce·체인 |
| Bundler | 여러 작업을 거래로 묶어 제출 | 검열·가용성·시뮬레이션 |
| EntryPoint | 검증과 실행의 공통 관문 | 공식 주소·버전 |
| Paymaster | 가스비 대납 조건 검증 | 후원 조건·데이터 수집·중단 |
UserOperation은 아직 온체인 거래가 아니다
사용자는 sender, nonce, callData, 가스 한도, signature 등이 담긴 UserOperation을 별도 메모풀이나 서비스에 보낸다. 번들러는 유효성을 시뮬레이션하고 여러 작업을 handleOps 호출 하나로 묶어 L1 또는 L2 거래로 제출한다.
따라서 지갑에서 UserOperation 해시가 생성됐다는 사실과 블록에 포함됐다는 사실을 구분해야 한다. 번들러 접수, 시뮬레이션 통과, 번들 거래 제출, EntryPoint 실행, 최종 계정 호출이라는 단계가 있으며 각 단계의 오류 코드를 따로 본다.
검증과 실행을 나누는 이유
번들러가 비용을 내고 거래를 제출하려면 포함 후 보상받을 수 있다는 확신이 필요하다. 악성 작업이 비싼 연산 끝에 실패하도록 허용하면 메모풀과 번들러를 소진시킬 수 있다. ERC-4337은 검증 단계의 접근과 연산에 규칙을 두고 실행 전에 시뮬레이션한다.
시뮬레이션 성공은 실제 블록 실행 성공을 보장하지 않는다. 그 사이 상태가 변하거나 같은 번들의 다른 작업과 충돌할 수 있다. 사용자 인터페이스는 접수와 확정을 구분하고, 재시도 때 같은 의도가 중복 실행되지 않도록 nonce와 상태를 확인해야 한다.
가스 대납은 무료 거래와 같은 말이 아니다
paymaster는 정책에 맞는 UserOperation의 비용을 대신 부담한다. 앱이 신규 사용자의 수수료를 후원하거나 토큰 결제를 중개할 수 있다. 그러나 후원 한도, 허용 함수, 만료 시간, 오프체인 승인 서버 같은 조건이 붙을 수 있다.
paymaster가 멈춰도 사용자가 직접 가스를 내는 대체 경로가 있는지 확인한다. 특정 서버가 서명한 paymasterData가 필수라면 그 서버가 새로운 가용성·검열 지점이다. ‘가스리스’라는 UI 문구보다 누가 언제 어떤 통화로 최종 비용을 부담하는지 본다.
- EntryPoint 주소와 버전 확인
- UserOperation의 sender·nonce·callData 확인
- 서명에 chainId와 EntryPoint가 포함되는지 확인
- paymaster 후원 조건과 대체 결제 경로 확인
- 번들러 실패 시 다른 제출 경로 확인
복구와 세션 키는 권한 확대이기도 하다
소셜 복구는 분실 대응을 개선하지만 복구자 담합이나 계정 탈취 경로가 될 수 있다. 세션 키는 제한된 기간 특정 게임이나 앱 동작을 자동 승인할 수 있지만 대상 계약, 함수, 금액, 만료가 넓으면 사실상 주 키와 비슷한 권한을 갖는다.
설정 화면에서 현재 소유자, 임계값, 활성 모듈, 세션 키, 만료를 조회할 수 있어야 한다. 모듈을 제거하는 거래와 복구 지연도 확인한다. 스마트 계정 코드가 프록시라면 구현 업그레이드 권한이 검증 규칙 전체를 바꿀 수 있다.
편리한 계정은 권한이 줄어든 계정이 아니라 권한을 더 세밀하게 표현한 계정이다.
JOBCOIN 해설
탐색기에서 스마트 계정 작업 확인하기
일반 거래 해시를 열어 to가 EntryPoint인지 확인하고 이벤트 로그에서 UserOperationEvent를 찾는다. userOpHash와 sender, nonce, success 값을 본 뒤 내부 호출 추적으로 스마트 계정이 실제 어떤 대상에 어떤 데이터를 보냈는지 확인한다.
실패했다면 번들 거래 자체 성공과 개별 UserOperation 성공을 구분한다. 한 번들 안에서 일부 작업이 실패해도 거래 로그는 남을 수 있다. 가스 사용량도 번들 전체와 사용자 작업 배분이 다르므로 지갑 영수증의 계산 기준을 확인한다.
계정 구현 주소와 소스 검증, 소유자·모듈 조회 함수, 업그레이드 이벤트를 기록한다. 공식 배포 주소 목록과 탐색기 주소가 다르면 이름이 같아도 다른 EntryPoint나 포크일 수 있으므로 서명하지 않는다.
자주 묻는 질문
계정 추상화를 쓰면 시드 문구가 필요 없나요?
패스키·복구자 등 다른 인증을 쓸 수 있지만 구현에 따라 시드가 남을 수도 있습니다. 실제 소유자와 복구 규칙을 확인하세요.
번들러가 자산을 가져갈 수 있나요?
번들러는 제출자지만 계정의 검증을 통과해야 합니다. 다만 검열·지연과 잘못된 지갑 구현 위험은 별도로 남습니다.
가스리스 거래는 정말 비용이 0인가요?
사용자에게 직접 청구되지 않을 수 있지만 paymaster나 앱이 비용을 냅니다. 후원 정책 종료나 토큰 후불 정산 여부를 확인해야 합니다.
