이더리움 트랜잭션 자유를 얻다. 프레임 트랜잭션

Key Takeaways

• Hegota 하드포크에 포함이 고려중인 EIP-8141, 일명 "프레임 트랜잭션(Frame Transaction)"은 기존 이더리움 트랜잭션의 인증/지불/실행을 분리해서 각각을 프로그래밍 가능하게 만든다. 이를 통해 이더리움 트랜잭션은 서명 알고리즘(패스키, 양자 저항 서명 등)을 자유롭게 선택할수 있게 되며, 가스 수수료 대납, 여러 호출을 하나의 트랜잭션으로 묶는 배치 실행과 같은 기능을 프로토콜 레벨에서 처리할수 있게 된다.

• 프레임 트랜잭션은 단순한 UX 개선이 아니라, 양자 저항/검열 저항/프라이버시와 같은 이더리움의 방향성에 대한 기반이 되며 AI 에이전트 권한 위임과 같은 시대의 흐름까지 관통하는 인프라 업그레이드다. 비탈릭은 프레임 트랜잭션을 "AA 커뮤니티가 지난 2년간 논의해온 모든 남은 문제를 해결하는 종합 패치(omnibus)이자 약 10년에 가까운 연구의 정점"이라고 표현했다.

• 프레임 트랜잭션은 이더리움이 하드포크 없이 스스로 진화할 수 있는 토대를 만든다. EVM이 스마트 컨트랙트를 통해 실행 레이어를 프로그래밍 가능하게 만들어 이더리움 위에 다양한 프로그램들이 하드포크 없이 추가될수 있는 것처럼, 프레임 트랜잭션은 검증 레이어를 프로그래밍 가능하게 만들어 현재와 미래의 다양한 인증 혁신이 프로토콜 수정 없이 일어날 수 있게 한다. 이더리움 재단이 지향하는 "walkaway test", 재단 없이도 지속 가능한 프로토콜이라는 비전과 직결된다.

0. 들어가며

이더리움이 탄생한 2015년부터 지금까지, 네트워크 위의 모든 트랜잭션은 하나의 고정된 틀 안에 갇혀 있었다. 인증은 반드시 ECDSA 서명으로 해야 하고, 가스비는 반드시 서명자 본인이 ETH로 지불해야 하며, 하나의 트랜잭션은 반드시 하나의 호출만 실행할 수 있다.

이 세 가지가 프로토콜에 고정되어 있어서, 서명 방식을 바꾸는 것도, 제3자가 가스비를 대납하는 것도, 여러 동작을 하나의 트랜잭션으로 묶는 것도 불가능하다. 수천만 개의 스마트 계정이 온체인에서 동작하고, AI 에이전트가 사용자를 대신해 트랜잭션을 실행하며, 양자 컴퓨팅이 기존 암호체계를 위협하는 시대에, 이 고정된 트랜잭션 구조가 이더리움의 한계가 되고 있다. 이더리움 트랜잭션은 이 속박에서 자유로워질 수 있을까?

Source: forkcast

2026년 3월 26일, 이더리움 프로토콜 변경 사항을 논의하는 코어 개발자 회의인 All Core Devs Execution(ACDE) 콜에서 EIP-8141, 일명 "프레임 트랜잭션(Frame Transaction)"이 헤고타(Hegota) 하드포크에 CFI(Considered for Inclusion)로 추가되었다. 하드포크의 진행 여부를 결정하는 헤드라이너 지위는 아니지만, 이더리움 프로토콜 레벨에서의 네이티브 계정 추상화(Native Account Abstraction)가 공식적인 검토 궤도에 올라섰다는 점에서 의미가 크다.

EIP-8141은 비탈릭 부테린(Vitalik Buterin)등이 2026년 1월 29일에 초안을 작성한 제안으로, 이더리움 트랜잭션의 유효성 검증(validation) 단계를 프로그래밍 가능하게 만드는 것이 핵심이다. 지금까지 이더리움의 모든 트랜잭션은 ECDSA 서명이라는 단일 인증 체계에 묶여 있었다. 프레임 트랜잭션은 이 고정된 구조를 해체하고, 검증 로직 자체를 EVM 위에서 자유롭게 프로그래밍할 수 있도록 한다. 비탈릭은 2월 28일 이더리움 매지션즈(Ethereum Magicians) 포럼에서 이 제안을 “AA 커뮤니티가 지난 2년간 논의해온 모든 남은 문제를 해결하는 종합 패치(omnibus)이자 약 10년에 가까운 연구의 정점”이라고 표현했다.

그동안 ERC-4337이나 EIP-7702 같은 제안들이 이더리움 프로토콜에 대한 변경 없이 계정 추상화를 우회적으로 구현해왔지만, EIP-8141은 AA(Account Abstraction)를 프로토콜 자체에 내장(enshrine)하려는 시도다. 이것이 계정 추상화, 양자 저항, 검열 저항, 프라이버시라는 이더리움의 핵심 방향성, 그리고 AI에이전트로 대표되는 시대의 변화에 어떻게 맞물리는지 살펴보자.

1. 프레임 트랜잭션의 기술적 구조

핵심 아이디어는 하나의 트랜잭션을 여러 단계로 나누는 것이다.

기존 이더리움 트랜잭션의 구조를 먼저 떠올려 보자. 하나의 트랜잭션에는 "ECDSA 서명으로 본인 인증", "하나의 대상 호출", "sender가 ETH로 가스비 지불"이라는 세 가지가 한 덩어리로 묶여 있다. 이 세 가지 중 하나라도 바꾸고 싶으면 프로토콜 자체를 수정해야 한다. 트랜잭션마다 서명 방식을 ECDSA 대신 다른 것으로 쓸 수 없고, 가스비를 제3자가 대납할 수 없고, 여러 호출을 한 트랜잭션으로 묶을 수도 없다.

프레임 트랜잭션은 이 고정된 덩어리를 "프레임(frame)"이라는 독립적인 단위들의 시퀀스로 풀어낸다. 한 트랜잭션 안에 프레임이 여러 개 들어가고, 각 프레임이 "본인 확인", "가스비 지불 결정", "실제 동작 수행" 같은 역할을 하나씩 맡는다. 인증과 실행과 지불이 분리되면, 각각을 독립적으로 프로그래밍할 수 있다. ECDSA 대신 Face ID로 인증할 수 있는 패스키를 쓰든, 가스비를 USDC로 내든, 한 트랜잭션 안에서 5개 컨트랙트를 순차 호출하든 프레임을 조합하기만 하면 된다.

1.1 트랜잭션 포맷

먼저 현재 이더리움에서 가장 보편적으로 쓰이는 EIP-1559 트랜잭션(타입 0x02)의 페이로드 구조를 살펴보자.

여기서 끝에 붙은 v, r, s가 ECDSA 서명값이다. 이더리움 노드는 이 서명값에 ecrecover를 수행해서 sender 주소를 역산한다. 즉, 송신자 정보가 트랜잭션에 명시되어 있는 게 아니라 서명에서 추출되는 구조다. 하나의 트랜잭션의 호출 대상은 to 하나뿐이고, 가스비는 반드시 sender의 ETH 잔고에서 차감된다.

이번에는 EIP-8141에서 도입되는 프레임 트랜잭션(타입 0x06)의 페이로드를 보자.

두 구조를 비교해서 살펴보면 차이를 확실하게 알 수 있다. 우선, ECDSA 서명값인 v, r, s가 사라졌다. ECDSA 서명에 대한 의존이 프로토콜 레벨에서 제거된 것이다. 다음으로는 서명에서 역산하던 sender가 명시적인 필드로 올라왔다. "이 sender가 진짜 주인인가?"라는 질문에 대한 답은 서명값이 아닌 frames 안의 검증 코드가 내린다. 마지막으로, 단일 호출 대상이었던 to와 value가 사라지고 frames 배열이 그 자리를 대신한다. 하나의 고정된 호출 대신, 여러 프레임의 시퀀스가 트랜잭션의 동작을 정의하는 것이다.

서명 방식이 프로토콜에 하드코딩되지 않으므로, 각 계정이 자신의 VERIFY 프레임에서 어떤 서명 체계를 사용할지 자유롭게 선택할 수 있다. 기존처럼 ECDSA를 그대로 써도 되고, 양자 저항이 필요한 계정은 CRYSTALS-Dilithium 같은 PQ 서명으로 전환할 수 있고, 일반 사용자 온보딩을 위해 패스키(P256 곡선 기반 WebAuthn)를 쓸 수도 있다. 패스키를 쓴다는 것은 Face ID, 지문 인식, 하드웨어 보안 키 같은 디바이스 네이티브 인증을 트랜잭션 서명에 직접 연결할 수 있다는 뜻이다. 이 모든 것이 프로토콜 변경 없이, VERIFY 프레임의 코드만으로 결정된다.

각 프레임은 [mode, target, gas_limit, data]로 구성된다. mode는 이 프레임이 검증용인지, 실행용인지, 배포용인지를 결정한다. target은 호출 대상 주소, gas_limit은 이 프레임에 할당된 가스 예산이다. 프레임별로 가스가 독립적이어서, 남은 가스가 다음 프레임으로 넘어가지 않는다.

1.2 세 가지 프레임 모드

바로 앞에서 이야기한 것처럼 프레임에는 mode 필드가 있고, 이것이 해당 프레임의 역할을 결정한다. 모드는 VERIFY(검증), SENDER(실행), DEPLOY(배포) 세가지가 존재한다.

1.2.1 VERIFY(검증)

"이 트랜잭션을 정말 이 사람이 보낸 것인가?"를 판단하는 프레임이다. 기존에는 프로토콜이 ECDSA 서명을 ecrecover하는 로직을 하드코딩하고 있었지만, VERIFY 프레임 안에서는 어떤 검증 코드든 자유롭게 실행할 수 있다.

프로토콜이 VERIFY 프레임에 요구하는 것은 딱 하나다. 검증이 통과하면 새로운 OPCODE인 APPROVE(0xaa)를 호출할 것이다. APPROVE가 호출되지 않으면 트랜잭션 전체가 무효 처리된다. APPROVE에는 scope 파라미터가 있어서 승인 범위를 세분화할 수 있다. 0x0은 실행 권한만, 0x1은 가스 지불 권한만, 0x2는 둘 다를 승인한다. 실행 권한과 지불 권한이 분리된다는 것이 핵심인데, 이 분리 덕분에 "사용자가 실행을 승인하고, 제3자가 가스비 지불을 승인하는" 스폰서드 트랜잭션(sponsored transaction)구현이 프로토콜 레벨에서 가능해진다.

안전성을 위해 VERIFY 프레임은 STATICCALL처럼 읽기 전용으로 동작한다. 읽기 전용이라 온체인 상태를 변경할 수 없으므로, 검증 과정에서 의도치 않은 부작용이 발생하는 것을 방지한다.

1.2.2 SENDER(실행)

SENDER는 사용자가 실제로 하고 싶은 일을 수행하는 프레임이다. ETH 전송, 컨트랙트 호출 등이 여기서 이루어진다. VERIFY에서 APPROVE가 호출된 후에만 실행되며, 호출받는 컨트랙트 입장에서는 sender가 직접 호출한 것과 동일하게 인식된다. 여러 SENDER 프레임을 연속 배치하면 하나의 트랜잭션 안에서 여러 호출을 묶을 수 있고, atomic batch 플래그를 쓰면 그중 하나라도 실패할 때 묶음 전체가 롤백된다.

1.2.3 DEPLOY(배포)

새 스마트 계정을 처음 만들 때 사용하는 프레임이다. 계정 코드 배포, 검증, 실행을 하나의 트랜잭션으로 원자적으로 처리할 수 있다.

1.3 기존 계정(EOA) 사용자들은?

프레임 트랜잭션이 도입되고 나면 수많은 기존 이더리움 계정(EOA, Externally Owned Accounts) 사용자는 스마트 계정으로 마이그레이션해야 할까? 결론부터 이야기 하자면 그렇지는 않다.

VERIFY 프레임의 target 값이 코드가 없는 주소, 즉 일반 EOA를 가리키면, EVM은 프로토콜에 내장된 기본 검증 코드(default code)를 자동으로 실행한다. 이 기본 검증 코드는 frame.data에서 승인 범위와 서명 알고리즘 종류를 읽어서 검증을 수행하며, 기본값으로 ECDSA(secp256k1)와 P256(패스키용 곡선)을 지원한다.

즉, 기존 EOA 사용자는 아무것도 하지 않아도 프레임 트랜잭션의 혜택을 받는다. 원래 사용하던 주소가 바뀌지 않고, 따로 마이그레이션을 하지 않아도 된다. 블록 탐색기에서 볼 때 VERIFY 프레임이 기본 검증 코드로 ECDSA 서명을 검증하고 APPROVE를 호출하는 것이 보일 뿐이다.

이전의 AA 제안들은 모두 "사용자가 스마트 계정으로 먼저 전환해야 한다"는 전제를 깔고 있었다. 하지만 EIP-8141은 그 전제를 뒤집어 업그레이드는 프로토콜 차원에서 이루어지고, 사용자는 자연스럽게 알게 되는 것이다.

2. 이더리움의 방향성과 프레임 트랜잭션

2.1 네이티브 계정 추상화

프레임 트랜잭션이 가져오는 가장 근본적인 변화는 "트랜잭션의 유효성(validity)"을 정의하는 권한이 프로토콜의 고정된 규칙에서 애플리케이션 레이어로 내려온다는 것이다. 비탈릭은 이를 EVM 자체의 범용 프로그래밍 가능성에 비유했다. EVM이 이더리움을 강력한 플랫폼으로 만든 것은 실행(execution) 단계를 사용자가 직접 프로그래밍할 수 있게 했기 때문이다. 프레임 트랜잭션은 같은 범용성을 검증(verification) 단계에도 부여해 검증 로직을 직접 프로그래밍할수 있게 만들어준다.

이전까지 검증 단계는 하드코딩된 ECDSA뿐이었다. EIP-8141 이후에는 멀티시그, 패스키, 소셜 리커버리, 세션 키, 지출 한도 등 어떤 검증 로직이든 계정 코드에서 자유롭게 정의할 수 있다. 개발자 입장에서는 "원하는 로직을 작성하고, 마지막에 APPROVE OPCODE를 호출하면 된다"는 것이 전부다.

2.2 양자 저항: ECDSA로부터의 탈출 경로

프레임 트랜잭션의 VERIFY 프레임은 이더리움 트랜잭션의 인증을 ECDSA 서명 체계로부터 분리(decouple)한다. 이는 곧 양자 컴퓨팅에 취약한 ECDSA를 대체할 양자 저항 서명 알고리즘(CRYSTALS-Dilithium 등)으로 계정을 업그레이드할 수 있는 네이티브 경로를 제공한다는 뜻이다. 사용자는 지갑 주소를 바꾸지 않고도 트랜잭션 실행을 위한 서명 체계만 교체할 수 있게 된다.

양자 컴퓨팅 연구가 가속화되면서, 실행 레이어(EL)에서의 양자 저항은 합의 레이어(CL) 만큼이나 중요한 과제가 되었다. 이더리움 재단의 리서처들은 합의 레이어에서의 PQ(Post-Quantum) 보안을 중시한다면 실행 레이어에서도 마찬가지로 신경 써야 한다 주장하고 있다.

양자 저항에 대한 부분은 단순한 미래 대비가 아니라, 이미 현실적인 요구사항이 되어가고 있다. 블록체인의 기관 채택이 현실화 되어가는 지금, 트랜잭션에 대한 하이브리드 인증 체계와 양자 저항 서명을 활용한 기관급 보안 등은 점점 더 실질적인 요구로 부상하고 있다.

2.3 검열 저항: FOCIL과의 시너지

헤고타의 헤드라이너 제안인 FOCIL(Fork-Choice Enforced Inclusion List, EIP-7805)은, 매 슬롯마다 17명의 무작위 선출된 참여자가 트랜잭션 포함(inclusion)을 강제할 수 있는 메커니즘이다. 블록 제안자 한 명이 트랜잭션을 의도적으로 배제하더라도, 다른 includer들을 통해 1-2슬롯 내에 포함될 수 있다. 심지어 PBS를 통해 100%의 슬롯이 적대적 빌더에게 팔리더라도 포함이 가능하다. 이는 이더리움의 검열 저항에서 가장 중요한 업그레이드다.

EIP-8141과 FOCIL의 조합이 중요한 이유는, 프레임 트랜잭션 덕분에 스마트 계정과 프라이버시 프로토콜의 트랜잭션이 래퍼(wrapper) 없이 퍼블릭 멤풀에 직접 제출될 수 있기 때문이다. 지금까지 스마트 계정 트랜잭션은 번들러라는 중개자를 거쳐야 했고, 이 과정에서 검열 가능한 지점이 존재했다. 프레임 트랜잭션이 스마트 계정 트랜잭션을 프로토콜 레벨의 일급 시민(first-class citizen)으로 격상시키면, FOCIL이 이를 직접 수신하고 온체인에 포함시킬 수 있다. 중개자가 필요 없어지기에 이더리움 프로토콜 레벨의 검열 저항성을 갖추게 되는 것이다.

2.4 프라이버시: 프로토콜 레벨의 지원

비탈릭은 2026년 3월 23일 X 포스트에서 EIP-8141이 "프라이버시 프로토콜을 훨씬 더 일급(first-class)으로 만든다"고 강조했다. 지금의 이더리움 프라이버시 프로토콜들은 표준 트랜잭션 포맷에 맞추기 위해 래퍼 트랜잭션이나 릴레이어를 사용해야 하는데, 이 중개 레이어 자체가 프라이버시의 구멍이 된다.

프레임 트랜잭션은 검증 로직의 자유도를 높여서, 프라이버시 프로토콜이 자체적인 영지식 증명(ZKP) 기반 검증을 VERIFY 프레임에서 직접 수행할 수 있게 한다. 래퍼 없이 퍼블릭 멤풀에 제출하고, FOCIL을 통해 검열 없이 포함될 수 있다. 프라이버시를 위한 별도의 인프라 스택이 필요 없어지는 것이다. 프레임 트랜잭션을 통해 이더리움 역시 선택적 프라이버시를 프로토콜 레벨에서 구현 가능하게 되는 것이다.

비탈릭이 프레임 트랜잭션을 "강력한 옴니버스"라고 부른 이유도 여기에 있다. EVM이 실행 단계에 범용 프로그래밍 가능성을 부여해서 강력한 옴니버스가 된 것처럼, 프레임 트랜잭션을 같은 범용성을 검증 단계에도 부여한다. 이전까지 검증 단계는 하드코딩된 ECDSA뿐이었기 때문이다.

2.5 AI 에이전트: 프로그래밍 가능한 권한 위임

프레임 트랜잭션의 프로그래밍 가능한 검증 로직은 AI 에이전트 시대의 인프라로서도 의미가 있다. AI 에이전트가 온체인에서 사용자를 대신해 행동하려면, "이 에이전트에게 어디까지 허용할 것인가"를 정밀하게 제어할 수 있어야 한다. 현재 구조에서는 AI에게 개인키를 통째로 넘기거나, 별도의 스마트 컨트랙트 계층을 추가하는 것 외에 선택지가 없다.

프레임 트랜잭션의 VERIFY 프레임은 이 문제에 대한 프로토콜 차원에서 해결책을 제공해준다. 인증 과정을 프로그래밍 할 수 있다는 것이 중요한 지점이다. 예를 들면 세션 키 방식으로 에이전트에게 제한된 권한을 부여하고, "24시간 동안 Uniswap에서 1,000 USDC 이내의 스왑만 허용" 같은 조건부 위임 로직을 VERIFY 프레임의 검증 코드에서 직접 구현할 수 있는 것이다. AI 에이전트 키가 이 범위를 벗어나는 트랜잭션을 시도하면 APPROVE가 호출되지 않고, 트랜잭션은 무효 처리된다. 지출 한도, 허용 컨트랙트 목록, 유효 시간 같은 조건을 검증 레이어에서 강제할 수 있는 것이다.

프레임 트랜잭션으로 가스 대납이 가능해지는 것도 AI 에이전트 흐름에 자연스럽게 맞물린다. 에이전트 계정이 직접 ETH를 보유할 필요 없이, 서비스 제공자나 에이전트를 소유한 사용자의 계정이 가스비를 대납하는 구조를 APPROVE의 scope 분리로 처리할 수 있다. 여러 디파이(DeFi) 프로토콜을 순차적으로 호출하는 복잡한 에이전트 워크플로도 SENDER 프레임의 atomic batch로 하나의 트랜잭션에 묶을 수 있고, 중간 단계에서 실패하면 전체가 롤백되어 안전하게 에이전트에게 온체인 금융 활동을 위임할 수 있게 된다.

3. 마치며

프레임 트랜잭션이 지향하는 바를 한마디로 설명하자면, EVM이 실행 레이어에 부여한 프로그래밍 가능성을 검증 레이어에까지 확장하는 것이다.

이더리움과 비트코인의 가장 큰 차이는, EVM이 실행 레이어에서 범용 프로그래밍을 가능하게 했다는 점이다. 이로 인해 지금의 디파이, NFT, DAO 와 같은 온체인 혁신이 등장할수 있었다. 프레임 트랜잭션은 검증 레이어에서 같은 것을 가능하게 한다. 이는 단순한 UX 개선이 아니라, 트랜잭션의 "유효성"이라는 가장 기본적인 개념 자체를 재정의하는 작업이다.

더 장기적인 관점에서 보면, 이 변화는 이더리움의 자기 지속성 비전과 맞닿아 있다. 2026년 3월 13일, 이더리움 재단은 38페이지 분량의 EF Mandate를 공개하며 "우리는 이더리움의 첫 번째 수호자였다. 이제 우리는 여럿 중 하나이며, 우리가 사라진 후에도 이 원칙들이 계속되기를 바란다"고 선언했다. 비탈릭이 "walkaway test"라고도 부르는 이 철학적 방향은 재단과 현재의 개발자들이 내일 당장 사라져도 이더리움이 완벽하게 동작해야 한다는 것이다.

하지만 양자 컴퓨팅과 같은 기술 발전에 따른 보안 위협은 언제나 새롭게 등장한다. 새로운 서명 알고리즘이 필요할 때마다, 새로운 계정 기능이 요구될 때마다 하드포크를 해야 한다면, 프로토콜은 항상 중앙화된 거버넌스 조율에 의존하게 된다. EIP-8141이 검증 로직까지 프로그래밍 가능하게 만들면, 양자 저항 서명이든, 아직 발명되지 않은 인증 방식이든 프로토콜을 수정하지 않고 계정 코드 레벨에서 도입할 수 있다. EVM 덕분에 새로운 디파이가 등장할 때마다 이더리움을 하드포크할 필요가 없는 것처럼, 프레임 트랜잭션은 미래의 인증 혁신이 하드포크 없이 일어날 수 있는 토대를 만든다. 재단이 스스로 사라진 후에도 프로토콜이 지속 가능하려면, 프로토콜은 스스로 진화할 수 있어야 한다.

헤고타 하드포크에 EIP-8141이 도입된다면 FOCIL으로 검열 저항을, 프레임 트랜잭션으로 L1레벨의 프라이버시와 네이티브 AA, 양자 저항을 달성하기 위한 토대가 마련된다. 이는 헤고타를 이더리움 역사에서 가장 사이퍼펑크적인 업그레이드로 만들어줄 것이다.