이더리움 개발자 및 리서처들이 올해 글램스터담 업그레이드를 열심히 준비 중인 가운데, 그 다음 업그레이드인 헤고타(Hegota)를 대표할 헤드라

sm-stack · 2026.02.05 · Short

이더리움 개발자 및 리서처들이 올해 글램스터담 업그레이드를 열심히 준비 중인 가운데, 그 다음 업그레이드인 헤고타(Hegota)를 대표할 헤드라이너 EIP에 대한 논의가 막 시작되었습니다. 현재 이번주까지 헤드라이너가 될 EIP에 대한 제안을 받는 중이죠. 그 중 개인적으로 가장 인상깊게 봤던 것은 EIP-8141, Frame Transaction입니다.

이더리움 개발자 및 리서처들이 올해 글램스터담 업그레이드를 열심히 준비 중인 가운데, 그 다음 업그레이드인 헤고타(Hegota)를 대표할 헤드라이너 EIP에 대한 논의가 막 시작되었습니다. 현재 이번주까지 헤드라이너가 될 EIP에 대한 제안을 받는 중이죠. 그 중 개인적으로 가장 인상깊게 봤던 것은 EIP-8141, Frame Transaction입니다. EIP-8141은 비탈릭 부테린, Geth 팀, 그리고 EF 계정 추상화 팀이 같이 만든 네이티브 계정 추상화(Native AA) 제안입니다. 이는 ERC-4337과 유사한 형태의 스마트 계정을 프로토콜 기본으로 만드는 것을 목표로 합니다. 이를 통해 유저들은 - EOA 서명이 아닌, 패스키 등 UX 친화적 서명 알고리즘 - 양자 저항 서명 알고리즘 - 가스비 대납 - 트랜잭션 배칭 등 ERC-4337에서 지원되던 대부분의 기능들을, 훨씬 더 저렴하게 누릴 수 있게 됩니다. 구체적인 스펙은 다음과 같습니다. EIP-8141은 트랜잭션을 여러 프레임으로 구분하고, 각 프레임을 트랜잭션 전송자가 자유롭게 구성할 수 있도록 합니다. 프레임에는 일반적인 스마트 컨트랙트 호출 뿐만 아니라, ‘커스텀 서명 검증 단계’도 넣을 수 있습니다. 해당 단계에서는 기존 ECDSA 서명 뿐만 아니라, 패스키 / 멀티시그 / 양자 저항 키 등등 다양한 검증 로직을 구현할 수 있으며, 이 단계를 통해 트랜잭션의 유효성이 판단될 뿐만 아니라, 가스를 누가 내는지도 결정할 수 있게 되죠. 이 검증 단계를 명시하기 위해, EIP-8141은 APPROVE라는 새로운 명령어(opcode)를 도입합니다. 이 명령어는 컨트랙트가 이더리움 노드에게 ‘이 트랜잭션이 유효한지, 그리고 가스는 누가 낼지’를 전달하는 역할을 수행하죠. 즉, 컨트랙트 계정은 이제 검증 로직을 알아서 구현하고, 끝에다가 APPROVE 명령어를 갖다가 붙이면 됩니다. 프레임은 매우 자유로워서, 기존 EOA 트랜잭션 형태도 지원하는 반면, 트랜잭션 배칭 / 가스비 대납 등 유용한 유즈케이스까지 완벽히 지원될 수 있습니다. 또한, 계정 추상화 지갑이나 서비스를 구현하는 빌더들은 종종 고민에 빠지게 될 때가 있습니다. 커스텀한 검증과 실행을 지원하는 월렛들의 특성 상, 사용처에 따라 검증 스텝에서 쓴 정보를 실행 과정에서 필요로 할때도 있는 등, EVM에서 기본 제공하는 맥락 외 추가 정보가 필요할 때가 많습니다. 이를 위해, EIP-8141은 TXPARAM 명령어를 지원합니다. 이 명령어는 트랜잭션 내 다양한 필드들의 정보를 네이티브한 명령어로 쉽게 불러올 수 있도록 하여, 컨트랙트 함수 실행에 필요한 맥락을 제공하기 위해 이상한 필드에 추가 정보를 억지로 끼워 넣는 등의 행위를 안 해도 되게 만듭니다. ERC-4337에서 조금 더 빌더 친화적으로 진화했다고 볼 수 있겠네요. 템포나 셀로 등의 계정 추상화 구현들과의 가장 큰 차이점은, 매우 자유로운 구현이 가능하다는 점입니다. 타 체인의 계정 추상화는 일반적으로 구현자들의 의도에 맞는 서명 알고리즘을 써야만 한다거나 하는 제약들이 있는데, EIP-8141은 완전히 월렛 구현자의 마음대로 구현이 가능합니다. 그렇기에 양자 저항 서명도 어떤 알고리즘이든 자유롭게 지원이 가능하죠. 사실, 기존에 네이티브 계정 추상화 제안은 EIP-7701의 형태로 원래 존재했었습니다. 여기서 장점만 골라서 EIP-8141를 만든 형태인데요, 구체적인 차이점은 다음과 같습니다. - EIP-7701은 트랜잭션의 검증과 실행을 위해 프로토콜이 고정된 형태의 함수를 부르도록 하여, 월렛 개발자들이 지정된 함수를 컨트랙트 월렛 내에 구현해야만 했습니다. 반면, EIP-8141은 이를 명령어 형태로 정형화하여 훨씬 자유롭게 만들었습니다. 이제 빌더들은 컨트랙트 단의 제약이 크게 없이, 훨씬 자유롭게 코드를 작성할 수 있습니다. - 이에 따라 노드 단에서 ABI 인코딩 등을 하지 않아도 되니 노드 단에서 코드도 더욱 단순해집니다. - 또한, 위에서 이야기 하였듯, TXPARAM 명령어 덕분에 EIP-8141에서는 월렛 개발자가 쓸데없는 맥락 정보를 이상한 필드에 끼워넣는 행위를 하지 않아도 됩니다. 참고로, ERC-4337 월렛들을 보면 전혀 상관없는 데이터를 UserOperation 내 논스나 서명 필드에 끼워넣는 구현들이 있는데, EIP-8141에서는 이런 요상한 짓들을 하지 않아도 된다는 의미입니다. - 다만 기존 이더리움 트랜잭션 형태를 크게 고치지 않으려는 형태다 보니, EIP-8141에서는 ERC-4337 / EIP-7701이 제공하던 일부 기능(e.g. 2D 논스)을 제공하지 않습니다. 전반적으로 개발자 경험과 구현 단순성에 초점을 맞춘 네이티브 계정 추상화라고 볼 수 있겠습니다. 앱 개발자들이 통합하려면 SDK 레벨의 추상화가 좀 잘 이뤄져야 할 것 같다는 생각은 있지만, 기존 ERC-4337에서 컨트랙트 개발자들이 겪었던 어려움을 해소하는 긍정적인 방향의 제안이라고 볼 수 있겠네요. 한 가지 짚고 넘어가야 할 부분은, 트랜잭션 유효성이 이제 컨트랙트 코드에 의존하기 때문에, ‘유효하지 않은 트랜잭션’이 블록에 포함될 여지가 있습니다. 이를 위해 노드들은 멤풀에서 EIP-8141 트랜잭션을 매우 잘 디버깅해봐야 하며, 이 때문에 멤풀이 무거워질 여지는 존재합니다. 어찌 되었든 이 제안이 헤고타 업그레이드 내 실행 레이어의 헤드라이너가 된다면, 이더리움은 UX 측면에서 큰 발전을 이룰 수 있을 것이라고 기대됩니다!

← Contents