비탈릭 부테린(Vitalik Buterin) 이더리움 공동창업자가 이더리움(ETH) 거래 형식을 검증과 실행으로 나누는 설계 논의를 다시 꺼냈다. 거래가 실제로 무엇을 하는지와 실행 전에 무엇을 검증해야 하는지를 분리해 확장성과 프라이버시 문제를 함께 다루려는 구상이다.
부테린은 최근 X 글에서 2015년식 모델에서는 실행과 상태를 한 덩어리로 볼 수 있었지만, 지금의 확장 전략에서는 동적으로 유연한 부분과 정적으로 분석 가능한 부분을 나눠야 한다고 설명했다. 그는 이더리움 활동량의 90% 이상은 동적 유연성이 필요하지 않다고 보고, 상태와 엮이지 않은 순수 의존성은 메모리풀 단계에서 한 번 처리한 뒤 스타크(STARK) 증명으로 대체할 수 있다고 했다.
핵심은 EIP-8141 '프레임 트랜잭션(Frame Transaction)' 초안이다. 이더리움 개선 제안 문서는 EIP-8141이 거래를 여러 프레임으로 나누고 각 프레임에서 검증, 수수료 지불, 사용자 작업 실행을 분리하는 구조라고 설명한다.
EIP-8141은 2026년 1월 29일 작성된 드래프트 문서다. 부테린은 공저자 중 한 명으로 이름을 올렸다. 문서는 프레임 거래가 계정 추상화의 원래 목표를 프로토콜 차원에서 구현하려는 설계라고 적었다.
계정 추상화는 이용자 계정이 특정 서명 방식에만 묶이지 않고 코드가 있는 주소처럼 동작하도록 만드는 개념이다. 통상 지갑 복구, 다중 서명, 수수료 대납, 새 서명 방식 도입 같은 기능을 더 유연하게 구현하기 위한 기반으로 다뤄진다.
기존 거래에서는 실행과 검증이 한 덩어리로 취급되는 경우가 많았다. 새 설계는 거래를 프레임 단위로 쪼갠다. 프레임은 검증용 VERIFY, 실행용 SENDER, 기본 실행 흐름 등으로 나뉜다.
각 프레임에는 실행 가스와 상태 가스 한도가 따로 붙는다. 이는 거래가 계산 자원을 얼마나 쓰는지와 상태 변경에 얼마를 쓰는지를 더 분명하게 나누려는 접근이다. 메모리풀 단계에서 검증 가능한 요소를 미리 가려내면 실행 부담을 줄일 여지도 생긴다.
이 논의는 단일 기능 제안에 그치지 않는다. EIP-8250 '키드 논스(Keyed Nonces)'는 프레임 거래에 독립 논스 영역을 넣는 방식을 제안한다. 하나의 선형 논스만 쓰면 같은 송신자 주소에서 여러 사용자의 거래가 서로 막힐 수 있다는 문제의식에서다.
키드 논스는 프라이버시 애플리케이션이나 공유 지갑 구조에서 서로 겹치지 않는 논스 영역을 쓰도록 하는 방안이다. 거래 순서 관리가 하나의 줄로 묶이지 않으면 병렬 처리와 공동 사용 구조를 설계하기 쉬워진다는 설명이다.
이더리움 매지션스의 헤고타(Hegota) 네트워크 업그레이드 메타 스레드도 프레임 거래, 키드 논스, 리센트 루츠(Recent Roots), 포실(FOCIL)을 보안·프라이버시·사용자경험 축으로 묶었다. 거래 형식 재설계가 별도 실험이 아니라 차기 업그레이드 논의의 한 부분으로 다뤄지고 있다는 뜻이다.
실행 클라이언트 진영에서는 테스트넷 실험도 이어지고 있다. 공개된 업계 공지에는 이더렉스(ethrex)가 프레임, 키드 논스, 리센트 루츠, 포실 계열 EIP를 묶은 공개 테스트넷을 운영하고 있다는 내용이 담겼다. 문서 논의가 개발망과 테스트넷 단계로 내려오기 시작한 셈이다.
개발자 커뮤니티의 반응은 방향성과 구현 부담으로 갈렸다. EIP-8141 토론 스레드에는 "This looks great!"라는 호응이 나왔지만, 곧바로 여러 VERIFY 프레임이 있을 때의 처리, 원자적 멀티콜 가능성, 새 명령어와 프로토콜 차원 내성 검사의 복잡도를 묻는 질문이 이어졌다.
찬성론은 네이티브 계정 추상화가 양자 내성 서명 전환과 릴레이어 축소에 도움이 될 수 있다고 본다. 반면 신중론은 새 명령어와 프로토콜 차원의 내부 검사가 늘어나는 만큼 복잡도가 커질 수 있다고 지적한다. 같은 설계를 두고도 유연성 확대와 프로토콜 비대화가 함께 거론되는 구조다.
이번 논의는 이더리움이 양자 내성과 프라이버시를 장기 로드맵의 핵심 과제로 끌어올렸다는 본지 보도와도 맞닿아 있다. 부테린은 앞서 장기 로드맵에서 양자 안전, 강한 프라이버시, 재귀 스타크, 형식검증을 더 높은 우선순위로 다뤘다.
다만 EIP-8141과 EIP-8250은 모두 드래프트 상태다. 메인넷 적용 일정은 제시되지 않았다. 현재 확인되는 변화는 확정된 업그레이드가 아니라 거래 형식을 어떻게 쪼개고 검증할지에 대한 프로토콜 설계 논의다.
<저작권자 ⓒ TokenPost, 무단전재 및 재배포 금지>
많이 본 기사