ERC-7579 모듈형 스마트계정
도입
ERC-7579는 smart account와 module이 최소한의 공통 인터페이스로 상호운용되도록 하려는 ERC다. account abstraction 제품에서 session key, spending limit, recovery, hook, executor를 wallet별로 다르게 붙이면 앱은 통합하기 어렵고 사용자는 어떤 module이 어떤 권한을 갖는지 이해하기 어렵다.
Agent payment에서는 module boundary가 곧 지출 권한 boundary다. validator가 서명을 검증하고, hook이 정책을 검사하고, executor가 결제를 실행한다. 이 역할이 섞이면 악성 module이 "검증만 하는 척"하면서 자금을 움직이는 위험이 생긴다.
학습 목표
- 모듈형 smart account의 validator, executor, hook 개념을 설명한다.
- 모듈 설치와 권한 확장 위험을 체크한다.
개념 설명
핵심 개념
- 모듈형 smart account의 validator, executor, hook 개념을 설명한다.
- 모듈 설치와 권한 확장 위험을 체크한다.
검증 지점
- 서명 권한과 지출 한도가 분리되는가
- paymaster 정책이 설명 가능한가
- 모듈 권한 경계를 설명했다.
실습 산출물
- ERC-7579 모듈형 스마트계정 이해 점검
- ERC-7579 모듈형 스마트계정 적용 과제
- 세션키 오남용이 차단되는가
ERC-7579는 module type을 구분한다.
| Module type | 역할 | payment 제품 예시 | 주요 위험 |
|---|---|---|---|
| Validator | UserOperation 또는 signature 유효성 판단 | session key, passkey, policy signer | 너무 넓은 signer 인정 |
| Executor | account behalf로 실행 | recurring payment, batch payout | 자금 이동 권한 오남용 |
| Fallback Handler | fallback 기능 확장 | custom signature route, receiver behavior | 예상 밖 selector 처리 |
| Hook | 실행 전후 custom check | merchant allowlist, daily limit, KYT gate | 특정 execution mode에서 우회 |
설치와 제거는 event로 추적해야 한다. ModuleInstalled와 ModuleUninstalled를 indexer가 놓치면 dashboard는 사용자의 실제 권한 상태를 잘못 보여준다.
코드로 확인하기
modular account는 validator, executor, hook을 조합하는 방식이다. 편리하지만 설치된 module이 account 권한을 확장하므로, 코드에서는 install과 execute 경계를 분리해서 읽어야 한다.
컨트랙트module 설치 전 allowlist 검증
enum ModuleType { Validator, Executor, Hook}function installModule(ModuleType moduleType, address module, bytes calldata initData) external onlyOwner { if (!moduleRegistry.isAllowed(moduleType, module)) { revert ModuleNotAllowed(moduleType, module); } installedModules[moduleType][module] = true; IModule(module).onInstall(initData); emit ModuleInstalled(moduleType, module);}module 설치는 단순 설정 변경이 아니다. validator module은 서명 규칙을, executor module은 실행 경로를, hook은 사전·사후 정책을 바꿀 수 있다.
백엔드account별 module manifest 검수
type ModuleManifest = { address: string; type: "validator" | "executor" | "hook"; permissions: string[]; version: string;};function rejectDangerousModule(manifest: ModuleManifest) { const dangerous = manifest.permissions.includes("execute_any_call"); const unknownVersion = !/^1\.\d+\.\d+$/.test(manifest.version); if (dangerous) return "permission_too_broad"; if (unknownVersion) return "unreviewed_version"; return "ok";}LMS 실습에서는 module을 설치했다는 사실보다, 설치한 module의 권한 표면을 어떻게 설명하고 회수할지까지 확인해야 한다.
인덱서module install 상태 재구성
select account, module_type, module_address, max(block_number) as last_seen_blockfrom smart_account_module_eventswhere event_name in ('ModuleInstalled', 'ModuleUninstalled')group by account, module_type, module_address;module 상태는 UI 설정값이 아니라 event stream에서 복원해야 한다. indexer가 uninstall event를 놓치면 사용자는 제거된 module을 아직 설치된 것으로 보거나, 반대로 위험한 module을 보지 못한다.
운영emergency uninstall runbook
module_incident_response: detect: - unreviewed_module_installed - executor_without_hook contain: - disable_agent_payments - require_owner_reconfirmation recover: - uninstall_module - rotate_session_keys - rebuild_module_inventoryERC-7579는 module 조합의 장점이 크지만, incident response도 module 단위로 준비해야 한다. "스마트 계정이 위험하다"가 아니라 어떤 validator, executor, hook이 문제인지 좁혀야 한다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| module type | validator, executor, fallback, hook이 분리되어 있는가 | module inventory |
| execution mode | single, batch, delegatecall 같은 mode를 어디까지 허용하는가 | supported mode table |
| install 권한 | 누가 어떤 module을 설치/제거할 수 있는가 | install approval checklist |
| hook coverage | 모든 payment execution path에 hook이 적용되는가 | hook coverage test |
| emergency removal | 악성 module을 어떻게 disable하는가 | uninstall runbook |
실무 예시
x402 agent payment를 smart account module로 설계한다면 최소 세 module이 필요하다.
| module | 책임 | risk gate |
|---|---|---|
| Session key validator | agent session key signature 검증 | key expiry, revoked state, signer allowlist |
| Spending policy hook | token, merchant, amount, daily cap 확인 | all execution modes에 적용 |
| Payment executor | x402 또는 invoice payment 실행 | only approved target, receipt required |
이 구조에서는 executor가 직접 policy를 생략할 수 없어야 한다. batch execution, delegatecall, fallback route에서도 hook이 빠지지 않는지 테스트한다.
흔한 오해와 실패 시나리오
| 오해 | 실제로 확인할 것 |
|---|---|
| module 설치는 플러그인 UX 문제라고 본다. | module은 account 권한을 확장하므로 install approval과 registry 검증이 필요하다. |
| validator만 안전하면 된다고 본다. | executor와 hook도 자금 이동과 정책 우회에 직접 영향을 준다. |
| hook이 있으면 모든 경로가 보호된다고 본다. | single call, batch call, executor call, fallback, delegatecall별 적용 범위를 테스트해야 한다. |
| fallback handler는 호환성 기능이라고만 본다. | fallback은 예상 밖 selector를 받아 core account logic을 우회할 수 있다. |
| uninstall은 나중에 처리해도 된다고 본다. | 악성 module 대응에는 즉시 제거와 event monitoring이 필요하다. |
실습 과제
- ERC-7579 모듈형 스마트계정 이해 점검: checkout account에 설치된 validator, executor, hook, fallback module inventory를 만든다.
- 설치 검수표 작성: module source, version, code hash, module type, allowed execution mode, install authority, uninstall path를 표로 정리한다.
- hook coverage test 설계: merchant allowlist hook이 single, batch, executor, fallback 경로에서 모두 적용되는지 테스트 케이스를 작성한다.
- 비상 제거 절차 작성: 악성 module 발견 시 disable, user notification, receipt audit, replacement module install 순서를 만든다.
완료 기준
- 모듈 권한 경계를 설명했다.
- 설치 검수표를 만들었다.
- 비상 제거 절차를 작성했다.
근거 자료
- ERC7579 모듈형 스마트계정: 05-계정추상화-에이전트결제/06-ERC7579-모듈형-스마트계정.md
- ERC-7579: Minimal Modular Smart Accounts: https://eips.ethereum.org/EIPS/eip-7579