64프레임 거래안, 헤고타 포함 검토 단계 유지

이더리움(ETH)의 계정 추상화 제안 EIP-8141이 헤고타(Hegotá) 업그레이드 후보로 남아 있다. 공개 공식 문서와 추적 페이지는 29일 한국시간 기준 이 제안을 포함 확정이 아닌 포함 검토 단계로 표시한다.

EIP-8141은 이더리움 거래를 여러 프레임으로 나눠 처리하는 ‘프레임 트랜잭션’ 제안이다. 검증, 승인, 실행, 가스 지불을 분리해 지갑이 여러 작업을 한 번에 처리하거나 다른 주체가 수수료를 부담하는 구조를 프로토콜 안에서 다루도록 설계됐다.

이더리움 개선제안 문서에는 새 거래 유형 ‘0x06’, 최대 64개 프레임, ‘APPROVE’ 명령이 명시돼 있다. 지갑 서명 방식 변경, 배치 거래, 가스 스폰서, 계정 추상화 확장에 활용될 수 있는 구조다.

계정 추상화는 이용자가 지갑과 거래를 다루는 방식을 바꾸는 기술 개념이다. 지금까지 일반 계정은 개인키와 주소의 결합에 크게 묶여 있었지만, 계정 추상화가 구현되면 서명 방식, 키 관리, 가스 지불, 여러 작업의 묶음 처리를 더 유연하게 설계할 수 있다.

이더리움재단(Ethereum Foundation)은 2월 18일 공개한 2026년 프로토콜 우선순위 문서에서 EIP-8141을 사용자경험 개선 축의 주요 후보로 다뤘다. 이 문서는 네이티브 계정 추상화가 스마트 계정 로직을 프로토콜에 넣는 방향과 맞닿아 있고, 기존 ECDSA 기반 인증에서 포스트퀀텀 보안 체계로 옮겨가는 경로와도 연결된다고 설명했다.

쟁점은 일정과 지위다. 이더리움재단은 4월 10일 체크포인트에서 헤고타의 합의층 주요 기능으로 FOCIL(EIP-7805)을 제시했고, EIP-8141은 비주요 기능 후보인 ‘Considered for Inclusion’ 상태로 옮겨졌다고 밝혔다.

공개 헤고타 추적 페이지도 같은 구도를 보인다. FOCIL만 ‘Scheduled for Inclusion’으로 표시하고, EIP-8141은 ‘Considered for Inclusion’으로 남겨뒀다.

본지는 앞서 이더랩스가 EIP-7805 FOCIL, EIP-8198 Quick Slots, EIP-8141 Frame Transactions 등을 헤고타 주요 항목으로 제시했다고 보도했다. 당시 논의의 중심도 검열 저항성과 빠른 블록 생성, 네이티브 계정 추상화였다.

크립토브리핑(Crypto Briefing)은 27일 올코어데브스 실행층 회의 뒤 EIP-8141이 헤고타의 ‘Scheduled’ 상태로 이동했다고 보도했다. 다만 공개 추적 페이지와 이더리움재단 문서만 놓고 보면, 현재 단계에서는 계정 추상화가 헤고타 범위 안에서 강하게 검토되는 흐름으로 보는 편이 정확하다.

코인데스크(CoinDesk)는 8월 17일 헤고타에 66개 제안이 올라와 있으며, EIP-8141은 헤고타 후보로 검토되고 있다고 전했다. 같은 보도는 헤고타에서 지금까지 승인된 변경은 검열 저항성과 관련된 FOCIL 하나라고 설명했다.

신규 제안 접수는 8월 6일 마감됐다. 남은 절차는 핵심 개발자 회의에서 구현과 테스트가 가능한 항목을 추려 실제 업그레이드 범위를 좁히는 과정이다.

클라이언트 구현 작업은 이어지고 있다. 이더리움 실행 스펙 저장소에는 EIP-8141 구현 추적과 frames-devnet 테스트 릴리스 추적 이슈가 열려 있고, Nethermind 저장소에도 프레임 트랜잭션 관련 이슈가 등록돼 있다.

이는 제안이 실제 클라이언트 구현 단계에서 검토되고 있다는 뜻이다. 그러나 구현 이슈가 열려 있다는 사실만으로 메인넷 반영이나 헤고타 포함이 끝났다고 보기는 어렵다.

업계 논의도 단일한 방향으로만 흐르지는 않는다. 이더리움 매지션스(Ethereum Magicians) 토론에서는 프레임 트랜잭션보다 다른 구조가 더 단순하고 저렴한 포스트퀀텀 전환 경로라는 주장과, 프로토콜 복잡도·멤풀 서비스거부 공격·새 명령 도입 부담을 우려하는 의견이 함께 나왔다.

헤고타 일정도 아직 고정되지 않았다. 이더리움재단의 2월 문서는 헤고타를 Glamsterdam 이후 단계로 설명했지만, 공개 추적 페이지는 헤고타를 2027년 업그레이드로 표시한다. EIP-8141의 구체적인 거래 유형과 구현 방식은 핵심 개발자 회의와 클라이언트 테스트를 거쳐 다시 정리될 예정이다.