월간 EIP - 2026년 7월 (ft. 발행량 논쟁이 드러낸 이더리움 거버넌스의 한계)

Key Takeaways

• 7월에는 신규 EIP가 크게 늘어난 가운데, Core 레이어에서는 밸리데이터 수와 상태 규모의 증가에 대비해 어테스테이션 전파, 포스트퀀텀 검증, state tiering, 상태 트리 구조 등 합의 & 검증 & 저장 비용을 장기적으로 낮추기 위한 기반의 재설계가 두드러졌고, ERC에서는 규제 & RWA 정보를 표준화하고 새로운 스마트 계정 구조와 기존 모듈을 연결하려는 논의가 활발하게 전개되었다.
• 또한 6월 조직 개편 이후 EF는 정부 & 기관 대상 활동, 그리고 빠른 완결성 개선 논의를 본격화하는 한편, 보안, 프라이버시, 검열 저항성을 강조해온 인사를 이사회에 합류시키며 기관 도입 확대와 이더리움의 핵심 가치 수호를 함께 가져가려는 방향을 분명히 했다.
• 한편, EIP-8363을 계기로 다시 불붙은 발행량 논쟁은 스테이킹 보상 조정을 넘어, 충분한 검증 없이 통화정책이 제안될 수 있는 현재 거버넌스의 한계를 드러내며 다극화되어가는 이더리움에서 누가 어떤 절차로 합의를 만들어갈 것인지라는 또 다른 과제를 남겼다.

이더리움은 스마트 컨트랙트라는 개념을 기존의 분산 원장 구조에 접목하며 블록체인의 새로운 지평을 열었다. 이러한 설계 철학은 EIP(Ethereum Improvement Proposal)라는 형태를 통해 점진적으로 구체화되었고, 그 결과 블록체인은 단순한 가치 저장 수단을 넘어 실제 비즈니스와 다양한 유스케이스를 담아낼 수 있는 인프라로 진화하고 있다. 이러한 발전의 흐름 속에서, 각기 다른 시각과 문제의식을 지닌 오피니언 리더들이 EIP 논의에 더욱 폭넓게 참여한다면, 우리가 그려보는 디지털 네이티브한 미래 역시 한층 더 풍부해질 수 있을 것이다.

본 아티클은 매월 새롭게 ‘Draft’ 단계로 채택되는 제안들과, 그 과정에서 상태(status)가 변화하는 주요 제안들을 하이레벨에서 조망하며 EIP 트렌드를 정리한다. 이를 통해 빌더와 비즈니스 관계자들이 EIP의 흐름과 맥락을 보다 입체적으로 이해하고, 나아가 각자의 영역에서 새로운 가치를 제안하는 데 참고할 수 있는 출발점이 되기를 기대한다.

본 아티클과 관련된 EIP 데이터는 EIP, ERC, RIP 공식 깃허브 레포지토리를 각각 활용해 수집 & 분석되었다.

1. 이달의 이더리움 논의 요약

7월의 EIP 흐름에서 가장 두드러지는 특징은, 연초와 비견될 만큼 신규 제안 수가 크게 늘어난 가운데 특히 Core EIP를 중심으로 새로운 제안이 집중적으로 등장했다는 점이다. 합의 레이어에서는 여러 밸리데이터의 어테스테이션을 전파 단계에서 묶어 네트워크 부하를 줄이거나(EIP-8243), 포스트퀀텀 서명 체계에서 무거운 증명 생성을 별도의 aggregator 역할로 분리하는 방식(EIP-8292)이 제안됐다. 실행 레이어에서는 오래 사용되지 않은 상태에 별도의 쓰기 비용을 부과하는 state tiering(EIP-8295 & 8296), MPT를 증명과 상태 관리에 유리한 바이너리 트리로 재구성하는 EIP-8297 등 향후 더 큰 상태와 validity proof 환경을 염두에 둔 제안들이 이어졌다. 전반적으로 7월의 Core EIP는 당장의 기능 추가보다, 밸리데이터 수와 상태 규모가 계속 커지는 환경에서도 이더리움의 검증, 전파, 그리고 저장 비용을 감당할 수 있도록 기반 구조를 다시 다듬는 데 무게가 실렸다.

애플리케이션 레이어를 위한 ERC 단에서는 규제와 실물자산을 온체인에서 다루기 위한 표준화 논의가 두드러졌다. ERC-8262는 AML 및 위험 평가와 같은 컴플라이언스 결과를 원본 정보 대신 영지식증명으로 전달하는 공통 인터페이스를 제안했고, ERC-8325부터 ERC-8330까지 이어지는 일련의 표준들은 토큰화된 실물자산의 근거 문서, 이전 정책, 규제 이벤트, 임팩트 지표, NAV 등을 기능별 인터페이스로 나눠 기록하는 구조를 제시했다. 한편 ERC-8286은 EIP-8141의 새로운 프레임 트랜잭션(frame transaction) 구조에서도 기존 ERC-7579 스마트 계정 모듈을 재사용할 수 있는 검증 인터페이스를 마련했다. 즉 Core 레이어에서 장기적인 확장성과 검증 구조를 다시 설계하는 움직임이 강해진 동시에, ERC에서는 규제형 자산과 스마트 계정처럼 실제 애플리케이션이 요구하는 정보를 보다 일관된 방식으로 연결하려는 시도가 함께 나타났다.

기존 EIP의 진전에서도 이러한 흐름과 맞닿은 제안들이 다수 다음 단계로 올라갔다. 블록 단위의 상태 접근 정보를 명시해 병렬 실행과 상태 처리를 지원하는 EIP-7928, Access List의 데이터 크기까지 가스에 반영하는 EIP-7981을 비롯해 Core EIP들이 진전됐고, ERC에서는 증권형 토큰의 이전을 등록된 Transfer Agent가 통제하도록 하는 ERC-1450, 릴레이 기반 가스 대납 구조를 정의한 ERC-1613, AI 에이전트의 실행 권한을 정책 안에서 제한하는 ERC-8196 등이 격상됐다. 24개의 신규 EIP와 15개의 기존 EIP가 동시에 다음 단계로 진전됐다는 점에서, 7월은 특정한 하나의 애플리케이션 트렌드보다 향후 이더리움의 상태 & 합의 & 검증 구조를 손보는 Core 논의와 규제 & 자산 & 계정 영역의 표준화가 동시에 활발하게 전개된 달로 볼 수 있다.

Source: Ethereum

한편, 6월의 조직 개편이 이더리움 재단(EF)의 역할을 다시 정의하는 과정이었다면, 7월에는 새 구조 아래에서 어떤 의제를 실제로 전면에 내세울지가 조금씩 드러나기 시작했다. 가장 먼저 움직인 곳은 새롭게 기관 영역을 담당하는 조직이었다. 7월 1일 EF의 Global Policy Strategy 팀은 정부와 기관을 위한 가이드인 “Ethereum Basics for Governments and Institutions”를 공개하며, 이더리움을 특정 기업이나 국가가 통제하는 시스템이 아니라 여러 주체가 공동으로 사용할 수 있는 중립적인 디지털 인프라로 제시했다. 이는 6월 조직 개편에서 신설된 Institution 레이어가 단순한 조직도상의 구분을 넘어, 실제 정부 & 기관 대상 커뮤니케이션과 도입 지원으로 이어지기 시작했음을 보여준다.

프로토콜 측에서는 이더리움을 보다 빠른 결제 & 정산 레이어로 만들기 위한 완결성(finality) 개선 논의가 한층 구체화됐다. 7월 10일 EF Consensus 팀은 롤업과 브리지, 결제 서비스, 지갑, 솔버(solver), 오라클(oracle), 스테이킹 사업자와 기관 관련 팀 등을 대상으로 진행한 조사를 공개하며, 현재 약 13~19분이 걸리는 완결성을 줄이는 것이 어떤 실질적인 효과를 가져올 수 있는지 정리했다. 특히 빠른 완결성은 단순히 사용자가 거래를 빨리 확정받는 문제를 넘어, 브리지와 솔버가 부담하는 자본 비용과 애플리케이션의 리스크 관리, 그리고 체인이 공격에 노출되는 시간을 함께 줄이는 문제로 다뤄졌다. 동시에 기존 합의 구조를 한 번에 교체하기보다 포크 선택(fork choice)와 온결성을 분리한 뒤 단계적으로 완결성을 단축하는 방향이 제시되면서, 장기적인 컨센서스(consensus) 개편을 보다 현실적인 업그레이드 경로로 가져오려는 움직임도 나타났다.

한편 EF의 조직적인 정체성은 7월 말 이사회 변화에서도 확인됐다. 7월 29일 SEAL 911 공동 창립자이자 이더리움의 보안과 프라이버시, 검열 저항성을 꾸준히 강조해온 pcaversaccio가 EF 이사회에 합류하면서, 이사회는 Aya Miyaguchi, Vitalik Buterin, Patrick Storchenegger와 함께 네 명으로 구성됐다. EF는 이사회의 역할을 재단 경영진의 전략이 핵심 가치와 부합하는지를 감독하고 재단의 방향성을 지키는 일종의 security council로 설명하고 있다. 6월에 실행 조직과 예산을 줄이는 한편 EF가 프로토콜의 중립성과 자기주권적 속성에 집중하겠다고 밝힌 데 이어, 7월에는 기관 도입을 위한 대외 활동을 넓히면서도 보안, 프라이버시, 검열 저항이라는 재단의 기준점은 더욱 명시적으로 고정하는 모습이 나타난 셈이다.

2. 새로이 제안된 EIP들

7월 한달 간 새로이 채택된 EIP의 수는 총 24개로, 전월대비 14개가 증가하였다. 당월의 새로운 EIP는 네트워크 단의 개선을 요하는 코어(Core) EIP와 애플리케이션 단에서 구현되는 표준인 ERC가 주를 이루었다.

아래에서는 새로이 ‘Draft’로 채택된 EIP들을 더욱 세부적으로 분류해보고, 특별히 주요깊게 살펴볼만한 EIP들을 살펴본다.

2.1 코어 / 네트워킹 레이어

2.1.1 EIP-8243: Batching Attestations at Source

이더리움의 밸리데이터 수가 늘어날수록 합의에 참여하는 표의 수뿐 아니라, 그 표를 네트워크에 전달하는 비용도 함께 커진다. 현재 약 100만 개의 활성 밸리데이터가 모두 참여하면 매 슬롯 약 3만 1천 개의 개별 어테스테이션(attestation)이 발생하는데, 대형 스테이킹 사업자가 같은 노드에서 여러 밸리데이터를 운영하더라도 각 밸리데이터의 표는 별도의 메시지로 전파해야 한다. 특히 더 짧은 슬롯과 빠른 완결성(finality)를 논의하려면 검증 연산뿐 아니라 이처럼 반복되는 합의 메시지 자체를 줄일 필요가 있다. EIP-8243은 밸리데이터의 수를 줄이는 대신, 같은 위원회에 배정된 여러 밸리데이터의 어테스테이션을 출발점에서 하나로 묶어 보내는 방식을 제안한다.

여러 어테스테이션을 단순히 묶어 전파하는 기능이 지금까지 허용되지 않았던 데는 이유가 있다. 누구나 이미 공개된 서명을 모아 임의의 부분집합으로 재조합할 수 있다면, k개의 표만으로도 최대 O(2^k)개의 서로 다른 aggregate를 만들어 가십 네트워크를 공격할 수 있기 때문이다. EIP-7251의 밸리데이터 잔액 통합도 메시지 수를 줄일 수 있지만 자발적인 통합을 전제로 하는 반면, EIP-8243은 밸리데이터 구조를 그대로 둔 채 네트워크에서 전파되는 표현만 압축한다. 즉 기존 스테이킹 구성을 바꾸지 않고도 consolidation과 유사한 네트워크 효율을 얻으려는 접근이다.

이를 위해 기존 SingleAttestation과 새로운 BatchAttestation을 함께 담을 수 있는 WireAttestation = Union[SingleAttestation, BatchAttestation]을 도입하고, 각각 0x00과 0x01 selector로 구분한다. 배치에 포함될 밸리데이터는 (slot, committee_index, batcher)에 대한 batch_seal을 미리 서명해 특정 밸리데이터가 자신의 표를 묶어도 된다는 권한을 부여하고, 실제 batcher는 aggregation_bits까지 포함한 구성 자체에 다시 batcher_signature를 남긴다. 따라서 공개된 일반 어테스테이션 서명만 주워서는 다른 밸리데이터를 임의로 배치에 끼워 넣을 수 없으며, batcher 역시 사전에 허가받은 구성원만 묶을 수 있다. 한편 실제 attestation의 BLS 서명 형식은 그대로 유지되기 때문에 이 두 추가 서명은 가십 단계에서만 검증된 뒤 버려지고, 온체인 Attestation이나 process_attestation은 변경되지 않는다.

스팸을 막는 핵심은 메시지의 형태가 아니라 그 안에 담긴 ‘새로운 표’를 기준으로 중복을 제거하는 데 있다. 노드는 (slot, committee_index, data_root)마다 seen_attesters와 seen_batchers를 관리하고, BatchAttestation이 최소 한 명의 아직 보지 못한 attester를 포함할 때만 가십으로 전달한다. 덕분에 서로 겹치는 여러 배치가 들어오더라도 새로운 표를 하나도 추가하지 못하는 부분집합은 자연스럽게 버려져, 공격자가 만들 수 있는 메시지 증폭도 자신이 실제로 통제하는 밸리데이터 수에 묶인다. 또한 batcher가 장애를 일으키면 밸리데이터가 기존 SingleAttestation으로 돌아갈 수 있고, 운영자는 에포크(epoch) 초기에 primary와 fallback batcher에 대한 seal을 미리 만들어 critical path의 추가 서명 지연도 피할 수 있다.

EIP-8243의 의의는 밸리데이터 수를 직접 제한하지 않고도 현재 합의 네트워크에 남아 있는 중복 전파를 줄일 수 있다는 데 있다. 예컨대 같은 트래픽 예산에서 어테스테이션 당 정보 밀도가 네 배 높아진다면 향후 위원회나 서브넷(subnet) 수, 나아가 에포크 길이를 줄이는 설계까지 검토할 여지가 생기지만, 이러한 파라미터 변경은 이 EIP 자체가 규정하는 내용은 아니다. 반대로 같은 batch에 포함된 밸리데이터들이 하나의 운영 주체 아래 있다는 사실이 드러날 수 있고, DVT, LST 등 복수 주체가 키를 나눠 관리하는 구조와의 구체적인 통합 방식도 아직 추가 검증이 필요하다. 따라서 EIP-8243은 validator cap이나 합의 구조 개편을 대신하는 해법이라기보다, 기존 밸리데이터 집합을 유지하면서 어테스테이션 전파 비용부터 압축해 향후 더 빠른 합의를 위한 네트워크 여유를 확보하려는 제안으로 보는 편이 적절하다.

2.1.2 EIP-8295: State Tiering by Periods & EIP-8296: Fixed-Cutoff State Tiering

이더리움의 상태 문제는 단순히 데이터가 계속 쌓인다는 데서 끝나지 않는다. 수년간 한 번도 변경되지 않은 계정이나 스토리지 슬롯과 매 블록 반복적으로 갱신되는 상태가 같은 저장 경로에 섞여 있고, 다시 수정할 때도 현재 가스 체계에서는 그 차이가 거의 반영되지 않는다. 노드 입장에서는 오래 묵은 상태를 다시 꺼내 쓰는 작업과 최근 상태를 수정하는 작업의 비용 구조가 다른데, 프로토콜은 이를 동일한 상태 쓰기로 취급해온 셈이다. EIP-8295와 EIP-8296은 상태를 삭제하는 대신, 마지막으로 변경된 시점을 기준으로 Active와 Inactive로 나누고 오래 방치된 상태를 다시 쓸 때 더 높은 비용을 매기자는 두 가지 설계를 제시한다.

두 제안의 전제는 EIP-8188이 마련한다. EIP-8188은 계정과 스토리지 슬롯에 last_written_block을 추가해 해당 상태가 마지막으로 변경된 블록을 컨센서스 수준에서 기록하지만, 이 정보를 가스 가격에는 반영하지 않는다. EIP-8295와 EIP-8296은 이 값을 실제 가격 신호로 가져와, 오래 쓰이지 않은 상태를 다시 활성화하는 비용을 해당 트랜잭션에 부담시킨다. 따라서 EIP-2929의 warm/cold처럼 한 트랜잭션 안에서 처음 접근했는지를 따지는 개념과 달리, 여기서 Active/Inactive는 여러 블록에 걸친 쓰기 이력을 기준으로 한다.

EIP-8295는 이 구분을 시간에 따라 계속 갱신하는 방식이다. 블록 번호를 PERIOD_LENGTH 단위로 나눈 뒤 마지막 쓰기 이후 INACTIVE_MIN_AGE 이상의 주기(period)가 지나면 해당 계정이나 슬롯을 Inactive로 분류하고, 이후 수정할 때 INACTIVE_ACCOUNT_WRITE_SURCHARGE 또는 INACTIVE_STORAGE_WRITE_SURCHARGE를 추가로 부과한다. 한 번 쓰기가 일어나면 last_written_block이 현재 블록으로 갱신되면서 다시 Active가 되고, 충분한 기간 동안 변경되지 않으면 자연스럽게 Inactive로 돌아간다. 즉 사용자가 앞으로도 저렴하게 수정할 상태라면 일정 기간마다 이를 갱신하는 비용을 감수하게 만들어, Active set의 크기를 경제적으로 제한하려는 구조다.

EIP-8296은 같은 원리를 훨씬 단순하게 적용한다. 프로토콜이 CUTOFF_BLOCK 하나를 정하고 last_written_block < CUTOFF_BLOCK인 상태만 Inactive로 지정하기 때문에, 활성화 시점의 오래된 상태 집합이 사실상 한 번에 고정된다. 덕분에 클라이언트는 이 집합을 불변 파일로 따로 저장하고 state root에 대해 검증 가능한 공통 포맷으로 배포할 수 있으며, 명세는 이를 위한 shared file format까지 권고한다. 반면 cutoff 이후 한 번이라도 Active로 분류된 상태는 시간이 아무리 지나도 자동으로 Inactive가 되지 않기 때문에, 오래된 상태를 다시 걷어내려면 향후 네트워크 업그레이드에서 CUTOFF_BLOCK을 다시 앞으로 옮겨야 한다.

실제 가스 부과 방식은 두 제안이 거의 같다. 예를 들어 기존 Inactive 슬롯을 SSTORE로 변경하면 슬롯 자체뿐 아니라 storageRoot가 바뀌는 계정 leaf에도 각각 해당 surcharge가 붙을 수 있지만, 새 슬롯이나 새 계정처럼 새로 만들어지는 상태에는 이를 부과하지 않고 EIP-8037의 state-creation 비용을 적용한다. 추가 비용은 state-gas가 아니라 regular-gas로 처리되며, 실행이 이후 반려(revert)가 되더라도 이미 소비된 surcharge는 돌려받지 않는다. 따라서 지갑과 RPC 제공자는 eth_estimateGas 단계부터 쓰기 대상의 last_written_block을 확인해 Active/Inactive 여부를 반영해야 한다.

결국 두 EIP의 차이는 상태를 분류(tiering)할 것인가보다 그 경계를 프로토콜이 자동으로 움직일 것인가, 업그레이드 때마다 사람이 다시 정할 것인가에 있다. EIP-8295는 새로운 cold state까지 지속적으로 포착할 수 있지만, 저렴한 미래 쓰기를 위해 불필요한 리프레시 트랜잭션(refresh transaction)을 반복하는 유인을 만들 수 있고, EIP-8296은 이런 갱신(renewal gaming)을 피하면서 구현과 아카이빙을 단순화하는 대신 Active set이 다음 cutoff 조정까지 계속 커질 수 있다.

어느 쪽도 상태를 삭제하는 state expiry는 아니며, Inactive 상태 역시 state root 안에 남아 있기 때문에 클라이언트가 이를 실제로 느린 저장장치나 별도 파일로 옮길지는 구현 정책에 달려 있다. 특히 “오래 쓰이지 않았다”는 것이 “거의 읽히지 않는다”는 뜻은 아니므로, write-age만 보고 자주 조회되는 데이터를 느린 경로로 이동할 경우 오히려 읽기 성능이나 DoS 측면의 새로운 문제가 생길 수 있다는 점도 두 제안이 공통적으로 남겨둔 한계다.

2.1.3 EIP-8297: Partitioned Binary Tree

이더리움이 validity proof를 중심으로 검증 구조를 바꾸려면, 실행 자체뿐 아니라 실행 과정에서 읽고 쓴 상태를 얼마나 작고 효율적으로 증명할 수 있는지도 중요해진다. 문제는 현재의 Merkle Patricia Trie(MPT)가 16진 분기, RLP 인코딩, Keccak 해시, 계정 트리 안에 다시 스토리지 트리를 두는 구조까지 겹치면서 증명에 필요한 데이터와 계산량을 키운다는 점이다. 특히 컨트랙트 코드는 일부 바이트만 확인하더라도 전체 코드를 제시해야 하므로, 극단적인 경우 한 블록의 상태 증명 데이터가 매우 커질 수 있다. EIP-8297은 이 병목을 단순한 해시 함수 교체가 아니라, 이더리움의 상태를 배치하고 커밋하는 방식 자체를 다시 설계하는 문제로 접근한다.

핵심은 기존의 계정 및 스토리지 트리를 하나의 바이너리 트리로 합치면서도, 모든 데이터를 무작위로 섞지 않는 데 있다. 각 키의 첫 바이트를 zone identifier로 사용해 0x00은 계정 헤더, 0x01은 컨트랙트 코드, 0xFF는 스토리지로 구분하고, 나머지 영역은 향후 새로운 상태 유형을 위해 남겨둔다. 덕분에 모든 상태를 하나의 공통 트리에서 다루면서도 특정 계정의 스토리지나 코드처럼 함께 증명하거나 관리할 데이터는 명확한 키 영역으로 묶을 수 있다. 이는 이후 state expiry나 partial statelessness가 계정 또는 상태 유형별 영역을 독립적으로 다룰 수 있는 구조적인 기반이 된다.

트리 자체도 MPT보다 증명 친화적으로 단순화된다. 노드는 LeafNode와 BranchNode 두 종류만 사용하며, 각각 H(LEAF_TAG || key || value)와 H(BRANCH_TAG || prefix || left_hash || right_hash) 형태로 커밋된다. 바이너리 분기는 한 단계마다 필요한 sibling hash가 하나뿐이어서 동일한 상태 규모에서 witness 크기를 줄일 수 있고, 긴 공통 경로는 BranchNode.prefix 안에 압축해 불필요한 단일 자식 노드가 이어지는 것도 막는다. 여기에 RLP를 제거하고 증명 시스템에 더 적합한 해시를 사용할 수 있도록 했지만, 현재 reference implementation의 BLAKE3는 임시 선택일 뿐 최종 해시 함수는 아직 확정되지 않았다.

상태 배치에서도 실제 접근 패턴을 고려했다. nonce, balance, code size와 자주 접근할 가능성이 높은 첫 64개 스토리지 슬롯은 계정의 동일한 header stem 아래 모으는 반면, 나머지 스토리지는 0xFF || H(address) || H(address || tree_index) || sub_index 형태로 별도 storage zone에 배치한다. 컨트랙트 코드는 31바이트 단위로 쪼개 증명할 수 있게 하고, 주소가 아니라 code_hash를 기준으로 저장해 동일한 바이트코드를 사용하는 수많은 컨트랙트가 하나의 코드 데이터를 공유하도록 한다. 따라서 클라이언트 입장에서는 하나의 키-값 트리를 중심으로 캐싱, 동기화, witness 생성을 통일하면서도, 자주 함께 읽는 데이터의 branch opening과 반복된 코드 저장을 줄일 여지가 생긴다.

EIP-8297의 의의는 상태 크기를 곧바로 줄이거나 stateless Ethereum을 완성한다는 데 있기보다, 앞으로 상태를 증명, 동기화, 그리고 만료시키기 쉬운 형태로 다시 배치한다는 데 있다. EVM에서 사용하는 SLOAD, SSTORE나 Solidity의 스토리지 인터페이스는 그대로라 애플리케이션 코드를 바꿀 필요는 없지만, 상태 루트와 proof format이 달라지므로 MPT proof를 직접 검증하던 컨트랙트와 클라이언트 인프라는 새로운 구조를 지원해야 한다. 또한 기존 MPT 상태의 실제 이전은 별도의 EIP-8347이 담당하며, 해시 함수 역시 아직 열려 있어 EIP-8297만으로 전환 경로 전체가 확정된 것은 아니다. 그럼에도 이 제안은 validity proof, state expiry, partial statelessness처럼 앞으로의 상태 관리 논의를 각각의 별도 장치가 아니라 하나의 공통 state tree 위에서 전개할 수 있도록 토대를 다시 짜려는 시도로 볼 수 있다.

2.1.4 기타

• EIP-8219: Checked Arithmetic Opcodes
• EIP-8282: Builder Execution Requests
• EIP-8298: SETCODEFROM Code Reuse Instruction
• EIP-8310: Post-Quantum Keystore for Stateful Keys
• EIP-8311: Increase Calldata Floor Cost to 96
• EIP-8333: Align Checkpoint with Epoch Boundary Block
• EIP-8337: Validated EVM Code

2.2 데이터 / 메시징 / 트랜잭션

2.2.1 EIP-8292: Post-Quantum Attestation Aggregators

이더리움의 포스트퀀텀 전환에서 어려운 문제 중 하나는 새로운 서명 알고리즘을 고르는 것 뿐 아니라, 수십만 검증자의 투표를 지금처럼 작은 데이터로 압축해 블록에 싣는 방법을 다시 설계하는 데 있다. 현재 비콘체인의 BLS 서명은 여러 검증자의 서명을 하나의 96바이트 서명으로 합칠 수 있지만, EIP-8292가 전제로 하는 XMSS 계열의 해시 기반 서명에는 이런 성질이 없다. 개별 서명도 약 1.17KiB로 더 큰데 이를 그대로 쌓으면 참여 검증자 수에 비례해 데이터와 검증 부담이 늘어난다. 따라서 포스트퀀텀 합의로 넘어가려면 서명 방식뿐 아니라, 그동안 BLS의 집계 특성에 기대왔던 어테스테이션 처리 구조 자체를 바꿔야 한다.

EIP-8292가 제안하는 방법은 여러 서명을 직접 하나로 합치는 대신, 해당 서명들이 모두 유효하다는 사실을 하나의 succinct proof로 압축하는 것이다. 문제는 이 증명을 생성하는 작업이 기존 BLS aggregator가 수행하던 단순한 곡선 연산보다 훨씬 무겁다는 점으로, 이를 일반 검증자의 의무로 만들면 홈 스테이커까지 높은 사양의 하드웨어를 갖춰야 하거나 슬롯의 시간 제약을 맞추지 못할 수 있다. EIP-8292는 그래서 증명 생성을 블록 제안 및 일반 검증과 분리하고, 충분한 하드웨어를 가진 노드가 자발적으로 맡는 별도의 aggregator 역할을 새로 정의한다.

작동 방식은 검증자들이 SUBNET_COMMITTEES로 나뉜 가십 서브넷에서 서명된 어테스테이션을 전파하는 데서 시작한다. Aggregator는 하나 이상의 서브넷을 구독해 같은 어테스테이션 메시지(attestation message)에 붙은 서명을 모은 뒤, leanVM을 통해 이들을 하나의 증명으로 만드는 leaf aggregation을 수행하고, 필요하면 여러 부분적인 증명들(partial proof)을 다시 합치는 recursive aggregation까지 담당한다. 반면 서로 다른 어테스테이션 메시지들을 최종적으로 하나의 블록 검증(block proof)에 묶는 작업은 proposer에게 남겨지며, 현재 명세에서는 한 블록이 최대 MAX_ATTESTATIONS_DATA = 8개의 서로 다른 메시지를 포함하도록 경계를 둔다. 즉 EIP-8292는 “서명을 모으는 노드”를 추가한다기보다, 포스트퀀텀 환경에서 서명 → 증명 → 블록 단위 증명으로 이어지는 새로운 집계 파이프라인의 역할을 나누는 제안에 가깝다.

이 분리가 중요한 이유는 증명 크기보다 증명 생성 시간이 실제 운영상의 병목이 되기 때문이다. 현재 벤치마크에서 1,000개 서명을 집계한 증명은 약 227KiB 수준으로 투표 수가 늘어도 크기가 크게 증가하지 않지만, 생성 시간은 2코어 환경에서 약 11초, 16코어에서는 약 2.6초까지 차이가 난다. 이에 EIP-8292는 stake threshold를 통해 aggregator 자격을 제한하지 않고, 필요한 자원을 감당할 수 있는 노드라면 누구든 opt-in할 수 있도록 하면서도, 충분한 지분을 운영하는 노드에는 모든 서브넷을 담당하는 super-aggregator 역할을 권고한다. 일반 검증자와 proposer는 이렇게 생성된 succinct proof를 검증하면 되므로, 포스트퀀텀 전환의 무거운 연산 부담을 전체 validator set에 동일하게 전가하지 않는 구조다.

다만 이는 포스트퀀텀 전환의 비용을 없애기보다 특정 역할에 집중시키는 선택이기도 하다. Aggregator가 어테스테이션과 완결성(finality) 사이의 critical path에 들어가는 만큼, 소수의 고성능 사업자에게 proving이 집중되거나 이들이 장애, 검열을 일으킬 경우 liveness가 저하될 수 있으며, 현재 명세에는 높은 연산 비용을 보상할 별도의 프로토콜 인센티브도 정해져 있지 않다. 또한 leanVM proof의 soundness 자체가 새로운 합의 보안 가정으로 들어오고, 구체적인 하드웨어 기준과 일부 PQ 파라미터도 아직 확정되지 않았다. 그럼에도 EIP-8292는 양자내성 서명을 기존 합의 구조에 단순히 끼워 넣는 대신, 비싼 증명 생성과 저렴한 검증을 분리함으로써 일반 검증자의 참여 장벽을 낮게 유지하려는 역할 분담이라는 점에서 포스트퀀텀 이더리움의 인프라 구조가 어떻게 달라질지를 보여주는 제안으로 볼 수 있다.

2.2.2 기타

• EIP-8289: Multi-block Access List Warming
• EIP-8304: Trustless log and transaction index

2.3 계정 / 컨트랙트 / 토큰 표준 / 지갑

2.3.1 ERC-8286: Modular Accounts for Frame Transactions

스마트 계정은 서명 검증이나 거래 실행 같은 기능을 외부 모듈로 분리해, 계정마다 필요한 기능을 조합할 수 있다. 해서, ERC-7579는 이런 모듈들을 서로 다른 스마트 계정에서도 공통된 방식으로 설치하고 사용할 수 있도록 규격을 정리했다. 하지만 EIP-8141이 기존 ERC-4337과 달리 하나의 트랜잭션을 검증과 실행을 담당하는 여러 frame으로 나누는 새로운 계정 추상화 방식을 제안하면서, 기존의 검증자(validator)들을 연결하는 방법도 달라지게 됐다. ERC-8286은 EIP-8141 구조에서도, ERC-7579의 기존 모듈 구조를 그대로 이어갈 수 있도록 프레임 트랜잭션(frame transaction)에 맞는 새로운 검증 인터페이스를 추가하는 제안이다.

따라서 ERC-8286이 새로 만드는 것은 모듈 자체보다 EIP-8141에서 모듈을 이용해 거래를 검증하는 방법에 관한 것이다. 모듈의 설치와 제거, 계정이 어떤 모듈을 지원하는지 확인하는 방식은 ERC-7579를 그대로 사용하고, 기존 validateUserOp 대신 프레임 트랜잭션을 검사하는 validateFrame을 추가한다. ERC-7579에서는 기존 검증자를 모듈 타입 1로 구분하는데, ERC-8286은 새 프레임 검증자에 type 11을 배정하며 하나의 모듈이 두 방식을 모두 지원하는 것도 허용한다. 예를 들어 하나의 멀티시그나 패스키 검증자가 ERC-4337에서는 validateUserOp을, EIP-8141에서는 validateFrame을 구현해 같은 인증 로직을 두 환경에서 재사용할 수 있는 식이다.

validateFrame이 하는 일은 해당 거래가 유효한지만 판단하는 데서 끝나지 않고, 검증에 성공했다면 계정이 어디까지 권한을 내줄지도 결정하는 것이다. 반환값인 approvalMode는 0x1이면 이 거래의 가스비 지불만, 0x2이면 계정 명의의 실행만, 0x3이면 둘 다 허용한다는 뜻이며, 계정은 이 결과를 확인한 뒤 EIP-8141의 APPROVE 명령으로 실제 권한을 부여한다. 다만 검증자가 원하는 권한을 마음대로 줄 수 있는 것은 아니며, 각 VERIFY 프레임이 처음부터 허용한 범위를 넘어설 수 없고 최종적으로 APPROVE를 호출하는 주체도 검증자가 아니라 계정이다. 즉 검증자가 “이 거래는 실행해도 된다”고 판정하더라도, 실제로 어느 권한까지 열어줄지 결정하는 마지막 관문은 스마트 계정에 남겨둔 구조다.

이 구조에서 특히 중요한 것은 EIP-8141이 거래를 실행하는 두 가지 경로의 차이다. DEFAULT 프레임은 기존 스마트 계정처럼 계정 컨트랙트의 execute를 거치기 때문에, 계정이 실행 직전에 호출 대상이나 실행 방식 등을 다시 확인할 수 있다. 반면 SENDER 프레임은 프로토콜이 계정 주소를 발신자로 삼아 대상 컨트랙트를 직접 호출하므로, 한 번 실행 권한이 승인된 뒤에는 스마트 계정 코드가 각 호출 사이에 개입하지 않는다. 따라서 여러 호출을 묶었는지, 모두 성공해야 하는 거래인지, 어디에 얼마를 보내는지 같은 조건은 실행 순간이 아니라 앞선 검증 단계에서 FRAMEPARAM, FRAMEDATALOAD 등을 통해 미리 검사해야 한다.

ERC-8286의 실용적 의미는 EIP-8141이라는 새로운 계정 추상화 방식이 등장하더라도, 기존 스마트 계정 생태계가 쌓아온 모듈을 처음부터 다시 만들 필요성을 줄인다는 데 있다. 장기적으로는 ERC-7579가 특정 계정 추상화 구현에 묶이지 않는 공통 모듈 규격이 되고, ERC-4337이나 EIP-8141처럼 검증 방식이 다른 환경마다 필요한 연결 인터페이스만 추가하는 구조로 발전할 수 있다. 다만 EIP-8141의 SENDER 프레임은 APPROVE_EXECUTION을 한 번 받으면 이후 호출을 다시 검사하지 않기 때문에, 잘못 설계된 검증자는 허용하지 말아야 할 target이나 value, calldata까지 한꺼번에 승인할 수 있다는 위험이 있다.

요컨대, ERC-8286은 새로운 스마트 계정 기능을 추가하기보다, 계정 추상화의 기반이 바뀌더라도 그 위의 모듈 생태계는 계속 재사용할 수 있도록 둘 사이의 경계를 정리하는 제안으로 보는 편이 적절하다.

2.3.2 기타

• 이외 없음

2.4 애플리케이션

2.4.1 ERC-8262: Zero-Knowledge Compliance Oracle

프라이버시를 유지하면서 규제를 준수하려는 시도는 그간 둘 중 하나를 일부 포기하는 방식에 가까웠다. 거래 데이터를 숨기면 규제기관이나 금융기관이 AML이나 제재 심사 여부를 확인하기 어려워지고, 반대로 view key처럼 필요할 때 원본 데이터를 공개하는 방식은 결국 프라이버시를 사후 공개로 바꿀 뿐이다. 프라이버시 풀(Privacy Pools)처럼 제재 대상 자금과 연관되지 않았다는 사실을 증명하는 방식도 등장했지만, 이것만으로 각 국가가 요구하는 위험 평가나 거래 패턴 심사까지 충족할 수 있는 것은 아니다. ERC-8262는 여기서 규제 준수 여부를 원본 데이터가 아니라 영지식증명으로 전달하는 공통 인터페이스를 만들려는 제안이다.

핵심은 사용자가 거래 금액이나 상대방, 개별 스크리닝 결과를 제출하는 대신, 자신의 기기에서 “해당 규칙을 통과했다”는 증명을 생성하도록 만드는 데 있다. ERC-8262는 이를 하나의 범용 증명으로 뭉치지 않고 Compliance, Risk Score, Pattern, Credential Attestation, Membership, Non-membership과 provider-signed 변형을 포함한 아홉 종류의 회로(circuit)로 구분한다. 예를 들어 COMPLIANCE (0x01)은 최대 8개 제공자의 위험 신호와 가중치를 비공개 입력으로 받아 가중 위험 점수를 계산하고, 특정 관할권(jurisdiction)의 기준선 아래인지 여부만 meets_threshold로 공개한다. 반면 PATTERN (0x03)은 최대 16개 거래의 금액과 시점을 숨긴 채 structuring, velocity, round-amount 같은 거래 패턴 검사 결과만 증명한다.

증명이 만들어지면 IERC8262Verifier.verifyProof()가 증명 타입(proof type)에 맞는 회로 검증 컨트랙트로 이를 라우팅하고, 검증에 성공한 결과는 오라클(Oracle)에 ComplianceAttestation으로 기록된다. 이 attestation에는 대상 주소, 관할권, 증명 타입, 유효기간, 사용된 verifier와 providerSetHash 등이 남으며, 애플리케이션은 이후 checkCompliance(address, jurisdictionId)만 호출해 현재 유효한 준수 증명이 있는지 확인할 수 있다. 모든 증명은 공개 입력인 submitter가 msg.sender와 같아야 하며, proofHash = keccak256(abi.encodePacked(proof, proofType, block.chainid, address(this)))로 체인과 오라클까지 묶어 다른 배포 환경에서 같은 증명을 재사용하는 것도 막는다. 즉 애플리케이션이 사용자의 원본 컴플라이언스 데이터를 직접 다루지 않고도, 온체인에서 검증 가능한 결과를 공통된 형태로 소비할 수 있게 만드는 것이 이 구조의 핵심이다.

다만 영지식증명이 곧 스크리닝 데이터 자체의 신뢰성을 보장하는 것은 아니다. 특히 기본 COMPLIANCE (0x01)과 RISK_SCORE (0x02)에서는 signals[]가 사용자의 프라이빗한 목격자(private witness)이기 때문에, 회로는 “입력된 값으로 계산했을 때 기준을 통과한다”는 사실만 검증할 뿐 그 신호를 실제 AML 제공자가 생성했는지는 증명하지 않는다. 이를 보완하기 위해 COMPLIANCE_SIGNED (0x07)과 RISK_SCORE_SIGNED (0x08)은 등록된 공급자의 secp256k1 서명을 회로 안에서 검증하고, COMPLIANCE_MULTI_SIGNED (0x09)은 최대 다섯 공급자들 가운데 threshold_m개 이상의 독립 서명을 요구할 수 있게 한다. 따라서 ERC-8262의 보안 모델은 ZK 자체뿐 아니라 어떤 증명 타입을 허용하는지, 어떤 공급자와 역치값(threshold)을 신뢰하는지에 크게 좌우되며, 명세 역시 이를 self-attested, provider-attested, credential-attested라는 서로 다른 신뢰 단계로 명시하고 있다.

요컨대 ERC-8262의 의미는 “프라이버시를 규제에 맞게 만든다”기보다, 지금까지 서비스마다 제각각 구현하던 컴플라이언스 결과를 온체인에서 조합 가능한 증명으로 바꾸려는 데 있다. 증명은 기본 24시간의 TTL을 가지며 만료 후에도 getHistoricalProof()로 조회할 수 있어, 거래 당시에는 유효한 심사를 통과했다는 기록을 사후에 확인하는, proof-of-innocence에도 활용할 수 있다. 다만 공급자 담합이나 잘못된 입력, 관리자 권한 탈취, 증명 제출 자체가 멤풀에서 노출되는 문제는 남아 있고, 특정 규제기관이 이런 ZK 증명을 실제 컴플라이언스 증빙으로 인정할지 역시 기술 표준이 결정할 수 있는 영역이 아니다.

2.4.2 ERC-8325 & ERC-8326 & ERC-8327 & ERC-8328 & ERC-8329 & ERC-8330

실물자산이나 펀드 같은 오프체인 자산을 토큰화할 때 어려운 지점은 토큰을 발행하는 것 자체보다, 그 토큰을 둘러싼 정보를 여러 시스템이 같은 방식으로 읽고 검증하게 만드는 데 있다. 어떤 자산을 나타내는지, 근거 문서는 무엇인지, 어디로 이전할 수 있는지, 어떤 규제 조치가 있었는지, 성과 지표와 현재 가치는 얼마인지가 지금은 토큰별 컨트랙트와 별도 레지스트리, 오프체인 데이터베이스에 흩어져 있다. ERC-8325부터 ERC-8330까지는 이 문제를 하나의 거대한 토큰 표준으로 해결하기보다, 서로 독립적으로 조합할 수 있는 여섯 개의 인터페이스로 나누는 접근을 취한다. 즉 토큰의 동작 방식을 새로 정의하기보다, 오프체인 자산을 둘러싼 출처와 상태, 정책, 보고 데이터를 공통된 방식으로 조회할 수 있는 프레임을 만들려는 시도에 가깝다.

우선 ERC-8325와 ERC-8326은 각각 자산과 문서의 출처를 다룬다. ERC-8325는 legalHash와 evidenceHash로 anchorId = keccak256(abi.encode(legalHash, evidenceHash))를 만들고, 이를 특정 토큰 컨트랙트 또는 토큰 ID와 연결해 어느 레지스트리가 어떤 자산 주장을 어떤 토큰에 대응시켰는지 양쪽에서 확인할 수 있게 한다. ERC-8326은 여기서 한 단계 더 내려가 계약서, 인증서, 증빙자료처럼 여러 문서의 해시를 정해진 순서로 배열한 뒤 하나의 bundleHash로 묶고, (subjectId, role)별로 기존 번들을 새 번들이 대체한 이력까지 남긴다. 둘 다 문서가 진짜인지 또는 해당 토큰에 법적 권리가 실제로 존재하는지를 증명하지는 않지만, 적어도 어느 자료를 근거로 어떤 관계가 등록됐고 이후 어떻게 갱신됐는지를 구현체마다 다른 메타데이터 대신 공통 인터페이스로 추적할 수 있게 한다.

ERC-8327은 자산이 어디에서 어디로 이동할 수 있는가를 별도의 정책 계층으로 분리한다. 핵심 단위는 (sourceDomain, destinationDomain, assetClass)이며, 여기서 도메인(domain)은 특정 국가뿐 아니라 규제된 거래소, 기업 네트워크, DAO 등 애플리케이션이 정의하는 논리적인 영역이 될 수 있고, A에서 B로의 허용 여부와 B에서 A로의 허용 여부도 독립적으로 설정된다. 따라서 여러 토큰이 같은 자산군에 속한다면 각 토큰에 동일한 이동 규칙을 반복해서 넣는 대신 isRoutePermitted()를 공통으로 조회할 수 있고, 필요하면 즉시 철회하거나 유예기간을 둔 철회도 구현할 수 있다. 다만 레지스트리는 주소가 어느 도메인에 속하는지 판단하거나 실제 전송을 막아주지는 않기 때문에, 토큰이나 transfer controller가 도메인과 자산 클래스(asset class)를 먼저 판별한 뒤 이 결과를 실제 전송 경로에서 집행해야 한다.

ERC-8328은 규제나 운영 과정에서 발생한 일을 현재 상태 하나로 덮어쓰지 않고, 감사 가능한 이력으로 남기는 쪽에 초점을 맞춘다. 발행과 상환, 동결, KYC 상태 변경, 규제기관의 홀드(hold) 행위, 강제 이전 같은 행위를 subjectId별 append-only 이벤트로 저장하면서, 행위를 실제로 기록한 actor와 그 행위의 근거라고 주장하는 authority, 관련 당사자와 증빙 해시 등을 구분한다. 잘못된 기록도 삭제하거나 수정하지 않고 correctsIndex와 correctedByIndex로 새로운 정정 기록을 이어 붙이기 때문에, 현재 유효한 기록을 찾으면서도 과거에 어떤 내용이 보고됐는지 보존할 수 있다. 중요한 점은 이것이 컴플라이언스를 판정하는 엔진이 아니라는 것으로, 온체인에 남는 것은 어디까지나 권한을 가진 레코더(recorder)가 남긴 주장이며 그 조치의 적법성이나 실제 발생 여부까지 보증하지는 않는다.

ERC-8329와 ERC-8330은 같은 기록 구조를 정량 데이터로 확장하지만, 대상은 서로 다르다. ERC-8329는 탄소배출, 재생에너지 생산량, 고용 인원처럼 특정 기간의 임팩트(impact) 지표를 (subjectId, indicatorId, [periodStart, periodEnd))에 연결하고, value, decimals, unit, 측정 방법론과 정정 이력을 함께 기록해 단순한 최신 숫자가 아니라 시계열 보고 자료로 만든다. 반면 ERC-8330은 펀드, 사모대출, 부동산처럼 실시간 시장가격보다 주기적인 평가가 중요한 자산을 위해 (subjectId, currency)별 NAV 스트림을 만들고, 평가기준 시점인 valuationTimestamp와 실제 온체인 게시 시점인 publishedAt을 분리하며 오래된 데이터인지도 별도로 판별한다. 여러 공급자(provider)가 같은 시점의 NAV를 제출할 경우 lower-median으로 집계하는 선택적 인터페이스까지 정의하지만, 이 역시 NAV를 직접 계산하거나 그것이 실제 매매·상환 가능한 가격이라고 보증하는 오라클은 아니다.

이 여섯 ERC를 함께 보면 공통된 방향은 규제를 토큰 컨트랙트 하나에 집어넣는 것보다, 오프체인 자산을 운영하는 데 필요한 정보를 기능별로 분리하고 표준화하는 것에 있다. 발행자는 ERC-8325로 자산과 토큰의 관계를, ERC-8326으로 근거 문서를, ERC-8327로 이동 가능한 영역을 관리하고, 이후의 규제 이벤트와 비재무 지표, NAV는 각각 ERC-8328, 8329, 8330을 통해 별도의 이력으로 제공하는 식의 조합이 가능하다.

이는 지갑이나 커스터디, 거래소, 감사 시스템이 특정 발행자의 독자 API에 의존하지 않고 같은 인터페이스로 필요한 데이터를 조회할 수 있는 기반을 넓히지만, 신뢰 문제 자체를 없애지는 않는다. 어떤 레지스트리와 레코더, NAV 공급자를 믿을 것인지, 오프체인 문서와 측정 방법론이 실제로 타당한지, 여러 체인과 레지스트리 사이에서 중복된 주장을 어떻게 처리할지는 여전히 각 구현과 제도권 인프라의 몫이라는 점에서, 이 제안들은 RWA의 실체나 신뢰성을 온체인에서 직접 보장하려는 것이 아니라, 자산을 둘러싼 정보가 어떤 근거로 등록되고 이후 어떻게 변경됐는지를 일관된 방식으로 기록하려는 시도에 가깝다.

2.4.3 기타

• ERC-8143: Smart Credential Resolution Interface
• ERC-8320: Regulated Asset Claim

3. 기존 EIP들의 진전

한편, 7월 한달간은 24개의 새로이 채택된 EIP들을 제외하고, 16개의 기존 EIP의 상태가 변화하였다. 이 중 15개의 EIP들 모두 최종적으로 채택되기위한 다음 단계(i.e., ‘Final’, ‘Last Call’, ‘Review’, ‘Draft’ 등의 단계)로 격상되었고, 1개의 EIP(i.e., EIP-2542)가 ‘Withdrawn’ 상태로 격하되었다.

격상된 ERC들 중 특히 주목할만한 것들은 - 등록된 Transfer Agent가 증권형 토큰의 발행, 소각, 그리고 이전을 전담하도록 해 규제 준수를 강제하는 표준인 ERC-1450, 릴레이 노드가 가스비를 대신 지불하고 디앱(dApp)이 이를 정산할 수 있도록 하는 탈중앙화 Gas Station Network(GSN)를 제안하는 표준인 ERC-1613, ERC-7540 기반 토큰화 볼트의 대기 중인 예치, 상환 요청을 다른 계정으로 이전할 수 있게 하는 표준인 ERC-8161, 그리고 AI 에이전트가 자산 소유자가 정한 정책과 검증 조건 안에서만 트랜잭션을 실행하도록 하는 지갑 표준인 ERC-8196 등이 있다.

ERC를 제외한 EIP들 중 특히 주목할만한 것들은 - 모든 ETH 전송에 ERC-20 Transfer 이벤트와 호환되는 로그를 자동 생성해, ETH 이동을 일관된 방식으로 추적할 수 있게 하는 EIP-7708, 블록에서 접근한 계정과 스토리지 및 상태 변경을 Block-Level Access List로 명시해 병렬 실행과 상태 처리를 지원하는 EIP-7928, Access List의 데이터 크기에도 가스 비용을 부과해 calldata 최저 비용 규칙을 우회하지 못하도록 하는 EIP-7981, 그리고 여러 EVM 체인에서 동일한 주소에 컨트랙트를 배포할 수 있도록 공통 CREATE2 팩토리를 표준화하는 EIP-7997 등이 있다.

이 외 참고할만한 다른 EIP들은 아래와 같다.

3.1 코어 / 네트워킹 레이어

• EIP-7778: Block Gas Accounting without Refunds
• EIP-7904: Compute Gas Cost Analysis
• EIP-7954: Increase Maximum Contract Size
• EIP-7976: Increase Calldata Floor Cost
• EIP-8015: Remove `deposit` and `eth1data` fields

3.2 데이터 / 메시징 / 트랜잭션

• EIP-8182: Private ETH and ERC-20 Transfers

3.3 계정 / 컨트랙트 / 토큰 표준 / 지갑

• 이외 없음

3.4 애플리케이션

• ERC-5516: Soulbound Multi-owner Tokens

4. 발행량 논쟁이 드러낸 이더리움 거버넌스의 한계

Source: pintail.xyz

최근 제안된 EIP-8363: Tapered Issuance Burn(TIB)을 계기로 이더리움 생태계에서는 발행 정책을 둘러싼 논쟁이 다시 뜨거워졌다. EIP-8363은 빠르게 늘어나는 스테이킹에 대응해, 스테이킹 비율이 높아질수록 밸리데이터 보상의 일부를 소각하고 일정 수준에서는 순수익률을 0까지 낮추자는 제안이다.

현행 발행 곡선에 스테이킹 증가를 상단에서 제어할 장치가 없다는 문제의식 자체는 충분히 논의할 가치가 있다. 하지만 이더리움에 필요한 적정 보안 예산이나 미래 밸리데이터의 역할에 대한 합의가 없는 상태에서 구체적인 축소안이 먼저 제시됐고, 스테이커와 인프라 사업자, 디파이와 기관 등 직접적인 이해관계자와의 충분한 논의도 선행되지 않았다. 결국 이번 논쟁에서 더욱 생각해봐야 할 지점은 발행량을 줄여야 하는가 자체뿐 아니라, 누가 어떤 절차를 거쳐 이더리움의 통화정책을 바꿀 수 있는가에 있었다.

특히 발행 정책은 이제 프로토콜 내부의 경제 모델만으로 결정하기 어려운 영역이 됐다. 실제 스테이킹 수요는 보상률뿐 아니라 각국의 규제와 세금, 유동성, 커스터디 환경, 기관의 자산운용 방식에 따라 달라지며, 같은 보상 축소라도 솔로 스테이커와 대형 스테이킹 사업자에게 미치는 영향은 크게 다를 수 있다. 스테이킹 수익률 역시 디파이의 대출과 레버리지, 각종 금융상품에 폭넓게 연결돼 있어 정책 변화의 영향이 밸리데이터 시장에만 머무르지도 않는다. 연구자들의 모델과 추정은 중요한 출발점이지만, 생태계의 실제 이해관계와 외부 환경에 대한 검증 없이 곧바로 프로토콜 정책으로 이어지기는 어렵다.

더 큰 문제는 이더리움에 이러한 차이를 조율할 명확한 의사결정 구조가 없다는 점이다. 지금까지 이더리움은 공식적인 의결 기관이나 토큰 투표 대신 연구자와 EIP 제안자, 클라이언트 팀, 코어 개발자, 커뮤니티가 공개 논의를 거쳐 느슨한 합의를 만들어왔다. 특정 조직이나 자본에 결정권이 집중되지 않는다는 것은 중요한 장점이지만, 통화정책처럼 광범위한 이해관계가 얽힌 사안에서 누구의 의견을 어느 단계까지 듣고, 어느 정도의 합의를 거쳐야 다음 단계로 넘어갈 수 있는지는 분명하지 않다. TIB가 Hegotá의 PFI 논의를 불과 이틀 앞두고 제출되며 제안의 내용뿐 아니라 그 절차까지 논란이 된 것은 이러한 공백을 잘 보여준다.

지금까지의 흐름을 보면, 앞으로 이더리움의 거버넌스가 더욱 다극화될수록 중요한 것은 새로운 결정권자를 만드는 것보다 서로 다른 주체가 정책을 검증하는 과정에 참여할 수 있도록 만드는 일일 것이다. 연구자는 장기적인 보안과 경제 모델을 제시하고, 밸리데이터와 인프라 사업자, 애플리케이션과 기관은 실제 시장 구조와 규제 환경에서 나타날 영향을 검증하며, 코어 개발자는 구현 가능성과 함께 충분한 논의가 이뤄졌는지를 확인할 수 있다. 그렇다고 대형 사업자에게 더 많은 결정권을 부여할 필요는 없다. 오히려 각자의 전문성과 이해관계를 투명하게 드러낸 채 서로의 가정과 결론을 검증하는 과정이, 특정 집단의 이해가 곧바로 프로토콜 정책으로 이어지는 것을 막는 현실적인 방법에 가깝다.

물론 이런 과정은 이미 느린 이더리움의 의사결정을 한층 더디게 만들 수 있다. 하지만 EF의 역할이 줄고 연구 조직과 클라이언트 팀, 인프라 사업자, 애플리케이션과 기관이 각자의 목소리를 내는 다극화 시대에는 빠른 합의보다 그 합의가 어떻게 만들어졌는지가 더 중요해질 수 있다. 모든 이해관계자의 동의를 얻을 수는 없더라도, 적어도 어떤 가정을 토대로 정책이 제안됐고 누구의 의견과 어떤 현실적인 변수가 검토됐는지는 충분히 드러나야 한다. 이번 발행량 논쟁을 계기로 이더리움이 이러한 과정을 조금 더 명확하게 정립할 수 있다면, 지금의 거버넌스 공백은 오히려 다극화된 생태계에 맞는 새로운 합의 방식을 만들어가는 출발점이 될 수도 있지 않을까.