EIP-8141 PoC 공개

EIP-8141 PoC 공개 이더리움의 차세대 네이티브 계정 추상화 제안, EIP-8141의 PoC를 공개합니다. 누구든 수정된 geth를 띄우고 솔리디티로 EIP-8141 계정을 짜서 테스팅해볼 수 있습니다. EIP-8141이란? EIP-8141은 하나의 트랜잭션을 '프레임'이라는 작은 호출 단위들로 쪼개는 새 트랜잭션 타입입니다. 프레임은 세 종류가 있습니다: DEFAULT: 범용 프레임. 훅 실행, 컨트랙트 배포 등에 사용 VERIFY: 검증 전용 프레임. 읽기 전용(STATICCALL)이라 상태 변경 불가. 반드시 APPROVE를 호출해서 트랜잭션을 승인해야 함 SENDER: 사용자 계정 명의로 실행되는 프레임. VERIFY에서 먼저 승인받아야 사용 가능 핵심은, VERIFY 프레임으로 기존 ECDSA 서명 검증을 대체할 수 있다는 것입니다. 컨트랙트가 정의한 어떤 서명 검증 로직이든 쓸 수 있게 되죠. 양자 내성 서명도 가능합니다. 또한 TXPARAM이라는 명령어로 프레임 간 정보를 읽을 수 있어서, 검증 프레임이 아직 실행되지 않은 다른 프레임의 내용을 미리 확인하는 것도 가능합니다. ERC-4337과의 차이 ERC-4337에서는 검증 단계에서 제한적으로 상태 변경이 가능했지만, EIP-8141의 VERIFY 프레임은 완전한 읽기 전용입니다. 더 보수적이지만, 프로토콜 레벨에서 더 단순하고 안전합니다. PoC에서 한 것 geth와 Solidity 컴파일러를 모두 수정했고, ERC-7562 기반 멤풀 트레이서도 구현했습니다. 트레이서는 VERIFY 프레임에서 block.timestamp 같은 '시간/상태에 따라 바뀔 수 있는' 명령어를 감지해서, DoS 공격에 쓰일 수 있는 트랜잭션을 멤풀 단계에서 거부합니다. 케이스 스터디 1: ERC20 Paymaster 사용자가 ETH 대신 ERC-20 토큰으로 가스비를 내는 구조입니다: Frame 0: VERIFY → 계정이 서명 검증 후 실행 승인 Frame 1: VERIFY → 페이마스터가 토큰 전송 조건 검증 후 가스 납부 승인 Frame 2: SENDER → 토큰을 페이마스터에게 전송 Frame 3: SENDER → 사용자의 실제 호출 실행 Frame 4: DEFAULT → 토큰 전송 성공 여부 확인 핵심은 Frame 1입니다. 페이마스터가 TXPARAMLOAD로 아직 실행 안 된 Frame 2의 콜데이터를 미리 읽어서, 올바른 토큰이 충분한 양만큼 자기한테 보내지는지 확인합니다. 상태 변경 없이 미래 프레임을 검증하는 거죠. 케이스 2: Kernel V3 (모듈러 스마트 계정) 제로데브의 Kernel v3 포팅인데, 프레임 모델의 제약이 가장 크게 영향을 미친 케이스입니다. ERC-4337에서는 validateUserOp 안에서 모듈 오케스트레이션(밸리데이터 결정, 훅 저장 등)을 다 했는데, EIP-8141에서는 VERIFY가 읽기 전용이라 이게 불가능한 것이 문제이죠. 해결책은 오케스트레이션을 온체인에서 오프체인으로 옮기는 것이었습니다. 클라이언트(SDK)가 계정 설정을 읽고 프레임 시퀀스를 직접 구성하는 방식입니다. 훅이 필요하면 DEFAULT 프레임을 앞에 추가하고, 모듈 설치가 필요하면 별도 DEFAULT 프레임으로 분리하는 식이죠. 복잡성이 컨트랙트에서 SDK로 이동하지만, 훅이 독립 프레임으로 실행되고 트랜잭션 구조에서 투명하게 보인다는 장점이 있습니다. 가스 벤치마크 (vs ERC-4337) EIP-8141 트랜잭션의 가스는 ERC-4337과 비교했을 때 30%에서 최대 43%까지 줄어드는 양상을 보였습니다. Simple Account: 101,319 → 58,017 (43% ↓) LightAccount: 100,910 → 64,612 (36% ↓) Kernel: 106,460 → 74,911 (30% ↓) EntryPoint의 고정 오버헤드가 제거된 덕분입니다. 남은 과제 1. 페이마스터 가스 과다 청구: 실제 가스 사용량을 알 수 없어 사용자에게 항상 최대 비용을 청구해야 하는 이슈가 존재합니다. 표준을 수정하여 TXPARAM을 확장하는 방식으로 해결 가능하긴 하나, 표준에 반영될 수 있을지는 의문입니다. 2. 포스트-퀀텀 스마트 계정: PQ 서명 프리컴파일을 통합하면, 저렴한 가격에 EIP-8141 트랜잭션을 보내볼 수 있습니다. EIP-8141 제안의 가장 큰 목적 중 하나이기도 하죠. 3. 멤풀 검증 성능: EVM 시뮬레이션 기반 검증의 처리량 벤치마킹이 필요합니다. 노드들이 멤풀에서 복잡한 검증을 처리해야 블록 빌딩에 영향이 없기 때문에 필수적이라고 볼 수 있는데, 이 로드가 크다면 탈중앙화에 영향이 있을 수도 있습니다. 자세한 내용은 PoC 리포지토리와 HackMD 문서를 참고 바랍니다!