월간 EIP - 2026년 5월 (ft. 스테이킹 발행 정책 논쟁과 대형 인프라의 책임에 대하여)

Key Takeaways

• 5월의 EIP 흐름은 트랜잭션 & 자산 & 승인 모델의 기존 가정을 재정의하려는 코어 및 ERC 표준이 동시다발적으로 등장하며, 이더리움의 디자인 스페이스 자체를 확장 및 재구성하는 방향으로 진화하고 있음을 보여주었다.
• 2026년 5월, 핵심 인력 이탈과 외부 조직화 움직임이 맞물리는 가운데, 비탈릭은 EF를 이더리움의 중심이 아닌 목적 지향적 노드로 바라봐야 한다는 관점을 제시하며, 장기 지속성과 핵심 가치에 집중하는 역할 재정의의 필요성을 드러냈다.
• 한편, 기관 자금 유입으로 촉발된 스테이킹 발행 정책 논쟁은 결국 이더리움이 대형 스테이킹 인프라의 영향력 확대를 어떤 자발적 규율과 자기강제를 통해 통제하며 신뢰할 수 있는 중립성을 유지할 것인가에 대한 질문으로 귀결된다.

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

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

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

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

5월의 EIP 흐름에서 가장 두드러지는 특징은, 3월과 4월에 이어 코어(Core) EIP가 지속적으로 누적되고 있고 또 ERC 측에서도 신규 제안이 많이 등장하기 시작했다는 점이다. 특히 트랜잭션 본문의 구성 요소를 분해하거나, 프라이버시 & 만료(expiry)와 같이 그동안 프로토콜 바깥에서 우회적으로 다뤄지던 시맨틱을 표준 수준으로 끌어올리려는 시도가 동시에 등장하면서, 개별 변경의 폭보다 디자인 스페이스 자체를 재구성하려는 흐름이 짙어지고 있다.

보다 구체적으로는 트랜잭션의 서명 알고리즘과 본문을 분리하는 cryptographically agile 모델, 단일 sender 아래 다수 주체가 병렬로 트랜잭션을 발행할 수 있게 하는 keyed nonce 구조, 그리고 자산 표준 수준에서 투명성과 익명성을 양립시키는 듀얼 모드 토큰 등, 트랜잭션 & 자산 & 승인 영역에서의 기존 문법(서명 스킴 고정, 무기한 승인, 단일 논스 등)을 명시적으로 다시 정의하려는 움직임이 한 달 간 관측되었다.

업계 트렌드를 반영한다고도 볼 수 있는, 애플리케이션 단에서 구현되는 ERC 표준들 또한 유의미한 진전을 보였다. 후의 섹션에서 살펴보겠지만, 검증된 신원을 양도 불가능한 토큰으로 유통시키는 표준(ERC-7574), ERC-20 승인의 무기한 시맨틱을 시간 기반으로 재정의하는 표준(ERC-8255), 그리고 규제된 실물자산 위에서 AI 에이전트의 권한 위임을 정의하는 표준(ERC-8226) 등 서로 다른 도메인의 표준이 동시에 채택되었다. 또한 5월에 상태 변경이 있었던 기존 EIP 6개가 모두 채택을 향한 다음 단계로 격상되었다는 점은 특히 주목할 만한데, 이는 신규 제안과 별도로 파이프라인 후반부의 표준들 역시 안정적인 진전 사이클을 유지하고 있음을 시사한다.

한편, 이러한 기술적 흐름과는 별개로 5월 한 달간 이더리움 재단(EF, Ethereum Foundation)을 둘러싼 조직적 흐름 또한 빠르게 움직였다. 2026년 들어 EF를 떠나거나 이탈을 예고한 시니어 기여자는 최소 9명에 이르며, 그중 5명의 발표가 5월에 몰렸다. 특히 Protocol Cluster의 세 co-lead인 Barnabé Monnot, Tim Beiko, Trent Van Epps가 모두 5월에 자리에서 물러나면서 코어 프로토콜 연구 조직의 기존 리드 라인이 사실상 비었고, 5월 18일에는 7년 차 Carl Beek와 4년 차 Julian Ma가 잇따라 이탈을 알렸다. 며칠 뒤인 5월 21일에는 2025년 EF를 나와 템포(Tempo)로 합류한 전 EF 연구원 Dankrad Feist가 ETH를 자산으로서 보다 적극적으로 옹호할 별도 조직을 위해 10억 달러 규모의 자금 조성을 제안하면서, EF 바깥에서의 대안적 조직화 움직임도 수면 위로 떠올랐다.

Source: X (@VitalikButerin)

이러한 흐름 속에서 5월 24일, 비탈릭 부테린은 이사회의 공식 입장과는 별개로 자신의 개인 견해임을 분명히 한 장문의 글을 X에 공개했다. 글의 골자는 EF를 더 이상 "이더리움의 중심(center of Ethereum)"이 아니라 "정해진 목적을 가진 하나의 노드(one node, with a defined purpose)"로 다루겠다는 것이며, 폭(breadth)보다 장기 지속성(longevity)을 택해 ETH 매도 규모를 줄이고 검열 저항, 개방성, 프라이버시, 보안(CROPS)에 직결되는 영역, 즉 AI 기반 형식 검증(formal verification)을 통한 증명 가능한 무결성, 비동기 환경에서도 작동하는 가용 합의(available chain consensus), 그리고 FOCIL & EIP-8141 & Kohaku로 이어지는 중간자 최소화(intermediary minimization)에 자원을 집중하겠다는 방향이다. EF의 활동 반경이 좁혀지면서 생기는 공백은 외부 조직(그중 일부는 EF보다 많은 ETH를 보유한다)이 나누어 채우는 분업 구조 역시 글에 명시적으로 담겼는데, 이는 직전 Dankrad Feist의 제안처럼 EF 밖에서 자생하는 움직임이 별도 트랙으로 자리 잡는 흐름에 대한 시기적 응답으로도 읽힌다. EF가 어떤 형태로 안착할지는 앞으로 몇 달의 흐름을 통해 보다 분명해질 것으로 보인다.

2. 새로이 제안된 EIP들

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

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

2.1 코어 / 네트워킹 레이어

2.1.1 EIP-8268: Storage Roots in Block Access Lists

이더리움의 풀 노드는 전체 상태(full state)를 들고 있어야 한다는 한계점에 오랫동안 직면해있었다. 단일 계정의 잔액 한 줄을 검증하려고 해도 상태 트리(state trie) 전체가 로컬에 재현되어 있어야 가능했고, 이는 노드 운영 비용과 동기화 시간 측면에서 모두 비효율적으로 작용해왔다. 무상태 클라이언트(stateless client), 상태 만료(state expiry), 부분 상태(partial state) 등의 이니셔티브들은 이런 부담을 덜기 위한 접근이었지만, 정작 검증과 실행 사이에서 노드들이 무엇을 주고받을지의 데이터 포맷 자체는 본격적으로 다뤄진 적이 없었다. 이러한 배경 속에서 등장한 EIP-7928 (BAL, Block-Level Access Lists)은 블록 실행 중 어떤 계정과 슬롯이 어떻게 건드려졌는지를 블록과 함께 묶어 전달함으로써 병렬 실행이나 사전 검증과 같은 작업들을 같은 데이터 위에서 처리할 수 있게 했다.

하지만 문제는 BAL이 담는 정보의 범위에 있다. BAL에는 변경된 슬롯의 후값(post-value), 잔액, 논스(nonce), 코드까지는 포함되지만, 정작 변경된 계정의 post-block 스토리지 트리 루트(storage trie root)는 빠져 있다. 상태 트리 리프(state trie leaf)는 balance | nonce | code_hash | storage_root 네 필드의 조합으로 구성되기 때문에, 스토리지 루트 하나가 빠지면 리프 자체가 미완성으로 남고 post-block 상태 루트의 검증으로 연결되지 않는다. 즉, 부분 상태유지(partial stateful)의 노드 입장에서 BAL은 실행은 도와주지만 검증은 끝까지 책임지지 못하는 도구인 셈이었다.

EIP-8268의 골자는 BAL에 바로 이 빠진 필드 하나를 더하는 것이다. AccountChanges 엔트리 중 상태 변경이 하나라도 발생한 경우에 한해 후행 필드로 storage_root를 더하여, 해당 계정의 post-block 스토리지 트리 루트를 직접 커밋한다. 잔액, 논스, 그리고 코드는 이미 BAL diff에서 복원 가능하므로, 이 필드 하나가 추가되는 것만으로 상태 트리 리프의 네 필드가 모두 채워지고, 자기 상태 파티션과 무관하게 누구나 변경된 계정의 리프를 조립할 수 있다. 변경되지 않은 엔트리는 EIP-7928의 6-필드 형태를 그대로 둔다.

한 필드를 더했을 뿐이지만, BAL이 다루는 정보의 성격 자체가 달라진다. 기존 BAL은 어디까지나 병렬 실행을 위한 메타데이터, 즉 어디를 어떻게 건드렸는지를 미리 알려주는 정도에 머물렀다. 하지만 storage_root가 들어오는 순간 BAL은 부분 상태 노드가 자기 파티션 바깥 계정에 대해서까지 리프를 직접 조립하고 post-block 상태 루트를 검증할 수 있는 검증용 데이터 구조로도 쓰이게 된다. 동기화 시나리오에도 영향이 있어, 약한 주관성 주기(weak subjectivity period) 안에서 다시 들어오는 노드는 BAL 시퀀스를 재생하는 것만으로 자기 파티션의 정합성을 직접 확인할 수 있다. 이러한 점에서 EIP-8268은 단순히 BAL 포맷에 32바이트 한 필드를 추가하는 변경을 넘어, 무상태 & 부분 상태 로드맵 위에서 검증과 보유 사이의 비대칭을 좁히는 시도로 평가될 수 있다.

2.1.2 기타

• EIP-8246: Remove SELFDESTRUCT Burn
• EIP-8252: Execution-Layer Reorg State Retention Window
• EIP-8254: Cap Deposit Requests Per Block
• EIP-8261: Gas Limit Schedule

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

2.2.1 EIP-8197: Cryptographically Agile Transactions

이더리움의 트랜잭션 구조는 지난 십 여년 간 ECDSA-secp256k1을 단일 서명 스킴으로 고정되어왔다. EIP-2718이 typed envelope을 도입하면서 트랜잭션 형식을 확장할 여지는 생겼지만, 새 서명 알고리즘을 받아들이려면 매번 트랜잭션 타입 자체를 새로 정의해야 한다는 점은 계속해서 부담으로 작용해오고 있다. 양자내성 암호(Post-Quantum Cryptography) 전환, 페이마스터(paymaster)나 프레임 트랜잭션(EIP-8141, frame transaction)과 같은 다중 서명 페이로드, 그리고 ZK 서명 집약(aggregation)등의 논의가 동시에 진행되는 지금 시점에서, 이처럼 알고리즘마다 새 트랜잭션 타입을 찍어내는 방식은 점차 확장성에 있어 한계에 다다르고 있기 때문이다.

계정 추상화와 트랜잭션 모델을 확장하려는 시도들은 이러한 문제를 부분적으로 우회해 왔다. ERC-4337은 스마트 컨트랙트 계정 내부에서 임의의 서명 검증 로직을 구성할 수 있게 했다. 하지만 프로토콜 레벨의 트랜잭션은 여전히 ECDSA로 서명되어야 했다. EIP-7702가 EOA에 코드 위임을 허용한 이후에도 외부 서명 자체는 그대로였고, 양자 내성 암호 알고리즘 도입을 다루는 EIP-7932 같은 시도 역시, 서명 타입 레지스트리는 정의하되 트랜잭션 형식의 기본 구조까지 손대지는 않았다.

이에, EIP-8197의 CATX(Cryptographically Agile Transactions)는 트랜잭션 본문과 서명을 같은 컨테이너에 묶지 않고 flat 구조로 분리하는 모델을 제안한다. 인코딩은 CA_TX_TYPE || rlp([payload_type, payload_body, (sig_type, sig_body)+]) 형태로, payload_type이 트랜잭션의 동작(EIP-1559, EIP-4844, EIP-7702 등)을 결정하고 그 뒤에 sig_type과 sig_body 쌍이 1개 이상이 후행적으로 붙는 구조이다. 이러한 구조에서는 트랜잭션의 동작 부문(semantic)과 서명 알고리즘이 서로 독립적으로 다뤄지기 때문에, 서명 스킴을 교체하거나 다중 서명을 요구하는 경우에 더 이상 새 트랜잭션 타입을 정의하지 않아도 된다.

또한, 다중 서명을 위한 연결된 서명 해시(chained signature hash)는 각 서명자가 페이로드뿐 아니라 자기보다 앞서 서명한 모든 (sig_type, sig_body)까지 자신의 해시 입력에 함께 묶도록 강제하기 때문에, 일부 서명만 교체해 승인 구조(authorization semantics)를 바꾸려는 key substitution 공격이 구조적으로 봉쇄된다. ECDSA 외 서명 타입은 주소 도출 시 sig_type을 해시 입력에 포함시켜(keccak256(sig_type || public_key)[12:32]) 서로 다른 알고리즘이 같은 주소를 만들어내지 못하도록 분리한다.

CATX의 의의는 알고리즘 전환을 트랜잭션 모델 변경 없이 수행할 수 있는 경로를 표준화한다는 점에 있다. 빌더 입장에서는 PQC 알고리즘이 sig_type 레지스트리에 추가되기만 하면 멤풀 & 검증 로직을 다시 짤 필요 없이 새 서명 스킴을 받아들일 수 있고, 페이마스터나 프레임 트랜잭션처럼 송신자(sender)와 스폰서(sponsor)가 서로 다른 목적으로 같은 본문에 서명하는 시나리오에서는 연결된 해시 덕분에 스폰서가 의도한 송금자 외 다른 주체로 서명이 대체될 가능성이 사라진다. 또한 trailing signature 구조는 서명만 떼어내 별도로 집약 처리할 수 있는 인터페이스를 제공하므로, 향후 ZK 기반 서명 집계나 배치 검증(batch verification) 인프라가 표준화된 형태의 진입점을 갖게 된다.

2.2.2 EIP-8250: Keyed Nonces for Frame Transactions

이더리움의 sender 주소는 오랫동안 한 명의 사용자, 혹은 하나의 EOA에 묶인 단일 행위자를 가리키는 정체성으로 다뤄져 왔다. 하지만 프라이버시 믹서의 shared withdrawal contract나 스마트 지갑의 세션 키를 위탁받은 릴레이 계정, 혹은 페이마스터 스타일의 스폰서처럼 하나의 주소가 다수의 독립적인 사용자나 사용 맥락을 대표하도록 설계된 구조가 점차 늘어나게 되었다. 이러한 디자인에서 sender의 논스는 더 이상 한 사용자의 트랜잭션 순서를 표현하기보다는, 서로 무관한 주체들의 트랜잭션이 경합하는 공통적인 자원이 되므로 때로는 서로의 트랜잭션에 병목을 걸어버리는 현상까지 초래하게 되었다. EIP-8141이 도입한 프레임 트랜잭션 역시 검증 & 결제 & 실행을 프레임 시퀀스로 분해해 트랜잭션 추상화의 폭을 넓혔지만, 이처럼 sender가 실질적인 주체에 무관하게 선형적인 단일 논스 구조를 그대로 유지하는 구조이기에 같은 한계가 발생할 수 있었다.

이를 해결하기 위해, EIP-8250은 프레임 트랜잭션의 단일 선형 논스 구조를 (nonce_key, nonce_seq) 쌍으로 교체한다. nonce_key == 0은 sender의 레거시 계정 논스를 그대로 가리키는 alias로 두어 기존 replay 행동을 보존하고, 그 외의 키는 NONCE_MANAGER라 명명된 시스템 컨트랙트의 스토리지에 프로토콜이 직접 관리하는 독립 시퀀스를 부여한다. 즉, 서로 다른 non-zero 키 위의 트랜잭션은 논스 측면에서 독립적이므로, 동일 sender를 공유하는 주체들이 더 이상 단일 시퀀스를 공유하지 않게 된다. 결정적으로, 논스 소비 시점이 EIP-8141의 payment-approval transition에 묶이도록 재배치되어, 키 하나가 한 번만 사용될 수 있다는 atomic spent-once 보장이 프로토콜 레이어 단에서 직접 제공된다.

이 표준을 통해 프라이버시 프로토콜의 shared withdrawal contract는 서로 다른 nullifier로부터 유도한 32-byte 키를 그대로 논스 도메인으로 사용해, 한 출금이 다른 출금을 무효화(invalidate)시키지 않는 처리 모델을 프로토콜 레이어로부터 직접 제공받을 수 있다. 스마트 지갑 세션 키, 페이마스터 스타일의 스폰서, 그리고 릴레이어 계정 역시 동일한 sender 주소 아래에서 서로 간섭하지 않는 동시 트랜잭션 흐름을 표현할 수 있고, 키 소비가 payment-approval에 묶여 있기 때문에 single-use-key 애플리케이션은 별도의 컨트랙트 nullifier 테이블 없이도 이중 지불 문제 방지를 아토믹하게 보장받을 수 있다.

요컨대, EIP-8250은 단순히 프레임 트랜잭션의 논스 모델을 확장하는 데 그치지 않고, ERC-4337이 애플리케이션 단에서 정형화했던 “keyed nonce 패턴”을 프로토콜 레이어로 승격시키며 프라이버시 / 세션 / 스폰서 도메인 전반에 걸친 새로운 동시성 디자인 스페이스를 여는 작업으로 평가될 수 있다.

2.2.3 EIP-8266: Expiring Nonces for Frame Transactions

앞서 살펴본 EIP-8250이 프레임 트랜잭션이 답습한 기존의 논스 구조를 키 도메인으로 분해해 하나의 sender 아래 여러 주체가 병렬로 트랜잭션을 발행할 수 있게 했다면, EIP-8266은 논스 구조의 또 다른 한계점이라 할 수 있는 ”모든 트랜잭션이 순서대로 줄을 서야 하고, 한 번 쓴 기록은 체인에 영구히 남는다는 점” 을 시간 축에서 풀어낸다.

아토믹 인텐트(atomic intent)나 time-boxed 스폰서십처럼 짧은 시간 제한이 있는 트랜잭션은 짧은 윈도우 안에서 재전송(repay) 위험을 제거해야한다. 보통 트랜잭션은 sender당 카운터 하나가 +1 되는 것만으로 재전송이 차단되지만, 논스를 비우는 expiring 모드에서는 "이 트랜잭션을 본 적 있음"이라는 기록을 어딘가에 따로 남겨두어야 한다. 가장 단순한 대안은 트랜잭션의 서명 해시(sig-hash)와 마감을 스토리지에 영구히 기록해 두는 방식이라, expiring 트랜잭션이 늘어날수록 상태가 무한히 누적되고 빈 슬롯에 처음 값을 쓸 때 부과되는 SSTORE 비용까지 더해지면서 짧은 송신이 일반 트랜잭션보다 비싸지는 역설이 생긴다. 결국 논스 없이 재전송 방지를 설계하려는 시도는 영구 상태 누적과 가스 비용 폭증을 동시에 떠안아야 했다.

EIP-8266은 트랜잭션의 외부 페이로드 구조를 그대로 두고 기존 nonce 필드에 특수 값 EXPIRING_NONCE_SENTINEL = 2**64 - 1을 넣는 것만으로 expiring-nonce 모드로 전환한다. 이 모드에서는 sender의 계정 논스를 더 이상 읽거나 갱신하지 않는 대신, EIP-8141이 이미 정의한 expiry_verify 프레임의 마감 검사에 재전송 유효성을 위임하고, 트랜잭션의 서명 해시는 시스템 컨트랙트 NONCE_RING 안의 ring buffer에 기록된다. 핵심 로직은 ring에 새 해시를 기록할 때 같은 자리에 들어있던 이전 항목이 아직 만료되지 않았는지부터 점검한다.

이전 항목의 마감이 아직 지나지 않은 경우(oldDeadline >= now) 아직 유효한 항목을 덮어쓰지 않기 위해 BufferFull로 트랜잭션 자체를 실패시키고, 이미 만료된 상태라면 해당 슬롯을 비운 뒤 새 항목을 기록한다. MAX_EXPIRY_SECS = 60초와 RING_CAPACITY = 2**18의 조합은 약 4,369 TPS의 지속적인 처리량까지 아직 살아있는 항목이 밀려나는 일 없이 동작하도록 사이징되어 있고, EXPIRING_NONCE_GAS = 13000은 영구 상태 증가가 없는 만큼 새 슬롯을 까는 데 따르는 SSTORE_SET 추가 비용 없이 ring의 읽기 & 쓰기 비용만 부과한다.

이러한 구조 변화는 우선 멤풀(mempool) 계층에서 가장 직접적으로 나타난다. EIP-8141이 권고하던 sender당 1개의 대기하는(pending) 프레임 트랜잭션 제약이 expiring-nonce 모드에서는 풀려, 한 EOA가 다수의 아토믹 인텐트나 time-boxed 스폰서십 트랜잭션을 동시에 띄울 수 있게 되고, 트랜잭션의 순서 또한 논스가 아닌 마감과 포함 시점으로 결정되므로 인텐트 솔버나 페이마스터가 사용자의 다른 활동과 병행해 트랜잭션을 발행할 공간이 열린다. 영구적으로 점유하는 상태는 트랜잭션 수와 무관하게 2 × RING_CAPACITY 슬롯으로 묶이며, 앞서 다룬 EIP-8250과는 nonce_key == 2**256 - 1이라는 예약된 키(reserved key) 위에서 자연스럽게 합류하도록 설계되어 키 도메인 분해와 시간 축 분해가 한 모델 위에서 결합될 가능성도 함께 열어둔다. 요컨대, EIP-8266은 짧은 트랜잭션의 재전송 보호 매커니즘을 정리할 뿐 아니라, 논스 추상화의 확장 비용을 영구 상태 증가가 아닌 capacity 사이징 문제로 재배치하는 작업으로 평가될 수 있다.

2.2.4 기타

• EIP-8253: Bump nonce of zero-nonce storage accounts

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

2.3.1 ERC-7574: Authentication SBT using Credential

디지털 공간은 물리적 제약에서 자유롭지만 상호작용의 범위와 깊이는 현실 세계에 못 미친다. 개인의 데이터가 특정 플랫폼에 독점적으로 묶이고 그 통제권마저 플랫폼에 넘어가는 구조이기 때문이다. 데이터의 주체인 개인은 민감 정보가 신뢰할 수 있는 방식으로 보존되리라 확신하기 어려워 꼭 필요한 경우가 아니면 내어주기를 꺼리고, 한번 제공한 데이터도 플랫폼 간에 재구성해 쓰지 못한다. 탈중앙 신원(Decentralized Identity, DID)은 플랫폼이 아닌 사용자가 직접 소유 및 제어를 하는 식별자를 통해, 발급받은 자격 증명(credential)을 사용자가 직접 보관하고 제시하게 하는 표준으로 등장했다. 하지만 자격 증명을 온체인에 그대로 올리면 그 내용이 노출되어 프라이버시가 깨지고, 자격 증명에 대한 검증 방식도 서비스마다 제각각이라 DID는 온체인에서 온전히 자리잡지 못했다.

ERC-7574는 자격 증명을 온체인에 직접 올리는 대신, 검증에 성공했다는 사실만을 양도 불가능한 SBT(Soul Bound Token)로 남기는 방식을 제안한다. 영지식 증명으로 자격 증명 소유 여부를 확인하고, 컨트랙트는 그 결과만 토큰으로 발급한다. 이 표준은 증명 시스템을 특정하지 않는 대신, 결과의 형식을 통일한다. 덕분에 서비스 개발자는 발급자마다 다른 자격 증명 형식과 증명 체계를 직접 다룰 필요 없이, ERC-721 인터페이스로 SBT 보유 여부만 확인하면 검증된 사용자를 가려낼 수 있다.

인터페이스는 세 함수로 정리된다. verify(bytes verificationData)가 자격 증명 소유 증명을 검증하고, 성공하면 issueSBT(address to, string tokenURI)가 SBT를 발급하며, updateTokenURI(uint256 tokenId, string tokenURI)가 토큰 상태 변경을 반영한다. 주목할 점은, 해당 표준의 명세가 발급된 토큰이 ERC-5192(Locked SBT)를 반드시 구현하도록 MUST 수준으로 강제한다는 것이다. 메타데이터에는 Issuer와 credentialNumber 필드만 추가되어 사용자 정보 없이 검증 맥락만 참조하며, 문제 발생 시 발급자에게 credentialNumber로 조회를 요청해 추적하되 토큰 자체에는 식별 가능한 데이터를 담지 않는다. revocation 역시 토큰을 소각하지 않고 메타데이터만 갱신해 처리하는데, 토큰의 존재를 유지하면서 상태만 바꿔 "한 번도 검증되지 않음"과 "검증됐으나 이후 취소됨"을 구분하기 위해서다.

이러한 설계가 바꾸는 것은 서비스 개발자의 작업 방식이다. 자체 자격 증명 검증 로직을 구현하지 않고도, 익숙한 ERC-721 계열 토큰 인터페이스로 "검증된 사용자만 참여 가능한" 게이팅을 구현할 수 있다. 즉 게이티드 디파이 참여, 검증된 메타버스 아바타, 평판 시스템처럼 인증된 사용자를 전제로 하는 애플리케이션이 토큰 보유 여부 하나로 접근 제어를 처리하고, 사용자는 한 번 획득한 인증 상태를 여러 플랫폼에 재사용될 수 있는 것이다. 이러한 점에서 ERC-7574는 단순히 KYC 절차를 온체인으로 옮기는 데 그치지 않고, 검증된 신원을 프라이버시를 해치지 않으면서 토큰으로 유통시키는 프리미티브로 평가될 수 있다.

2.3.2 ERC-8086: Privacy Token

이더리움에서 프라이버시 자산을 다루는 방식은 지난 수년간 일관된 파편화의 양상을 보여왔다. 토네이도 캐시(Tornado Cash) 이후 등장한 아즈텍(Aztec), 레일건(Railgun) 등 각 프로토콜은 commitment, nullifier, 머클 트리(Merkle tree), 암호화된 노트(encrypted note)라는 사실상 동일한 프리미티브 위에서 작동했지만, 써킷(circuit) 설계와 증명 시스템(proof system), 노트 암호화 방식은 모두 제각각이었다. 그 결과 같은 zk 기반 프라이버시 토큰임에도 지갑은 매번 프로토콜별 맞춤형 통합을 거쳐야 했고, 새로운 빌더들은 매번 동일한 암호학적(cryptographic) 기반을 처음부터 다시 구현해야 했다.

그 사이 ERC-4337이나 EIP-7702 같은 계정 추상화 표준의 등장이 트랜잭션 레벨에서의 유연성을 확보했고, ERC-4626은 이자 창출형(yield-bearing) 볼트(vault)를 표준화하면서 디파이의 통합을 단순화했다. 하지만 이러한 표준화의 흐름이 프라이버시 자산에는 닿지 않았다. 개별 프라이버시 프로젝트는 래퍼(wrapper) 모델 (DAI → zDAI → DAI) 또는 듀얼 모드 모델 (한 토큰이 transparent ↔ private 두 상태를 가짐) 중 하나를 택했지만, 두 모델 모두 하부에 동일한 commitment-nullifier 프리미티브가 깔린다는 사실이 인터페이스 수준에서 드러나지 않았다. 보안 감사도 매번 동일한 영역을 다시 검증해야 했고, 지갑 단의 사용자 경험은 프로토콜 단위로 분기됐다.

ERC-8086은 이러한 공통 프리미티브를 IZRC20이라는 인터페이스로 구축하고, 구현 디테일은 오프체인Privacy Configuration File로 분리하는 접근을 택한다. 인터페이스 자체는 commitment의 머클 트리 추가, nullifier 소비, 암호화된 노트 발행이라는 동작만을 노출하고 어떤 증명 시스템을 쓰는지, 어떤 곡선과 해시 함수를 쓰는지, 그리고 노트 암호화 알고리즘이 무엇인지는 외부 JSON 파일이 명세한다. 이는 ERC-8004의 에Agent Registration File 패턴을 차용한 구조로, 온체인 인터페이스의 안정성과 구현 다양성 수용을 동시에 노린다. 그 결과 Groth16, PLONK, STARK 어느 쪽을 쓰든, 단일 트리든 듀얼 레이어 트리든, 같은 IZRC20을 구현했다면 동일한 클라이언트가 다룰 수 있게 된다.

코어 인터페이스는 두 개의 함수로 중심으로 구성되는데, proofType은 구현체가 여러 verifier를 동시에 등록하고 라우팅할 수 있게 하는 디스패처 역할을 한다. 예를 들어 듀얼 레이어 트리 구현은 active subtree용 증명과 finalized root tree용 증명을 서로 다른 proofType으로 분리할 수 있고, 향후 새로운 증명 시스템이 추가되어도 인터페이스 변경 없이 새 타입을 더하기만 하면 된다. 트랜잭션이 발생하면 Transaction(...) 이벤트가 emit되며, 여기서 viewTag는 수신자 클라이언트가 모든 트랜잭션을 trial-decryption하지 않고도 자기 노트를 빠르게 사전 필터링할 수 있게 하는 1바이트 식별자다.

이러한 구조는 프라이버시 자산을 다루는 개발자들의 작업 범위를 바꿀 수 있다. 지갑 벤더는 단일 통합으로 IZRC20을 구현한 모든 토큰을 다룰 수 있고, 각 토큰의 privacyConfigURI()에서 써킷 아티팩트와 공개 신호 스키마를 받아 동적으로 증명 생성 환경을 구성하면 된다. 래퍼 르로토콜 빌더는 프라이버시 프리미티브를 재발명하지 않고 자기 자산의 입출금 로직과 거버넌스에 집중할 수 있으며, 듀얼 모드 토큰을 설계하는 측은 ERC-20과 IZRC20 두 인터페이스를 한 컨트랙트에 동시 구현하여 transparent(일반적인, 공개적인 토큰 표준) 디파이 경로와 프라이버시 경로를 한 자산 안에 공존시킬 수 있다. 요컨대, ERC-8086은 새로운 프라이버시 프로토콜을 하나 더 추가하는 EIP가 라기보다는, 기존 프라이버시 프로토콜들이 지갑과 디파이 생태계와 통합되는 지점을 인터페이스 수준에서 표준화하는 시도로 평가될 수 있다.

2.3.3 ERC-8085: Dual-Mode Fungible Tokens

이더리움 위에서 프라이버시는 줄곧 베이스 자산 바깥에 덧붙는 “후행 레이어”로 존재해왔다. 토네이도 캐시가 ERC-20 위에 믹서 컨트랙트를 얹었고, 프라이버시 풀(Privacy Pools)을 비롯한 다른 후속적인 시도들 역시 기존 자산을 래퍼(wrapper)에 예치한 뒤 새로운 익명의 표현으로 꺼내는 구조에서 벗어나지 않았다. ERC-20 호환성이 워낙 만연하고 견고했기 때문에 프라이버시는 그 표준을 손대지 않는 선에서만 부가적으로 추가될 수 있었고, 발행 단계에서부터 두 모드를 함께 설계하는 “듀얼 모드” 선택지는 사실상 존재하지 않았다.

이에 대한 가장 보편적인 우회로는 프라이버시 풀의 방식처럼 기존 토큰을 래퍼에 넣어 익명 잔액으로 변환하는 방식이었다. 이 방식은 기존 ERC-20을 손대지 않고 어디에든 붙일 수 있다는 장점이 있었지만, 같은 토큰에 대해 공개 버전과 랩드(wrapped) 버전이라는 두 개의 컨트랙트 주소를 만들어내는 부작용을 낳았다. 그 결과 동일한 자산임에도 DEX 유동성은 두 풀로 쪼개졌고, 시장 가격도 미세하게 어긋났다. 익명 상태의 잔액으로는 디파이와 직접 상호작용할 수 없었기 때문에, 사용자가 거래나 담보로 쓰려면 매번 랩드 토큰을 다시 풀어야 하는 불편함이 따라붙었다.

ERC-8085는 이 전제를 뒤집어 "프라이버시는 별도의 토큰이 아니라 동일 토큰의 또 다른 모드"라는 명제로 시작한다. 단일 컨트랙트가 ERC-20과 IZRC20(앞 문단에서 설명한 ERC-8086에서 정의된 zk-SNARK 기반 프라이버시 인터페이스)을 동시에 상속하고, 두 모드 사이를 오가는 변환 함수를 노출하는 구조다. 공개 모드의 잔액은 종전 그대로 balanceOf()로 조회되며 DEX & 렌딩 프로토콜과 어떤 추가 통합도 없이 그대로 동작한다. 익명 모드는 commitment와 nullifier로 구성된 별도의 상태 트리에 보관되지만, 같은 컨트랙트 주소가 두 상태를 모두 소유한다는 점에서 토큰 이코노믹스와 유동성은 처음부터 통합되어 있다.

인터페이스의 핵심은 두 모드 사이의 변환을 정의하는 함수 한 쌍과 공급량 불변식이다:

toPrivate는 호출자의 ERC-20 잔액을 소각하면서 zk-SNARK 증명으로 같은 값의 commitment를 익명 트리에 추가하고, toPublic은 익명 노트를 nullify하면서 지정된 주소로 공개 잔액을 발행한다. 두 변환 모두 Transfer(account, address(0), amount) 형태의 표준 ERC-20 이벤트를 함께 emit하기 때문에, 기존 인덱서와 회계 도구의 시야에는 일반적인 소각 & 민트와 동일한 모양으로 잡힌다. 컨트랙트는 모든 호출에서 totalSupply() == sum(balanceOf) + totalPrivacySupply() 불변식을 강제하며, 익명 모드의 총합은 트리에서 계산하지 않고 변환 시점에 가감으로만 추적된다. 특히 toPublic 경로에서는 변환으로 빠져나간 값이 익명 트리에 남지 못하도록 출력 노트 하나를 사용 불가능한 BURN_ADDRESS로 강제 라우팅해 모드 간 이중 지불을 차단한다.

이러한 구조는 새 토큰을 발행하는 주체가 프라이버시를 사후에 덧붙이는 후속 작업이 아니라 발행 설계의 일부로 다룰 수 있게 만든다. DAO는 트레저리와 그랜트 분배는 공개 모드에서 감사 가능한 상태로 두면서, 투표권 위임이나 개인 보유 포지션은 익명 모드에 두어 전략 노출을 줄일 수 있다. 비즈니스 발행자는 투자자 보고와 거래소 상장은 공개 모드에서 처리하고, 급여 지급이나 공급사 결제처럼 경쟁상 민감한 정보가 담기는 트랜잭션은 같은 토큰의 익명 모드로 분리해 운용할 수 있게 된다. 프로토콜 토큰 역시 스테이킹 & 유동성 공급 같은 디파이 통합은 공개 모드에서, 장기 보유나 OTC처럼 가격 영향이 큰 행위는 익명 모드에서 나누어 운용할 수 있다. 결과적으로, ERC-8085는 이더리움 토큰 표준 자체가 투명성과 익명성을 양립시키는 단위로 자체 유틸리티를 진화시키는 새로운 표준으로 평가될 수 있다.

2.3.4 ERC-8255: Expiring Token Approvals

표면적으로 ERC-20의 approve는 단순한 권한 부여 함수이다. 하지만 한 번 발급된 allowance가 명시적으로 변경되기 전까지 무기한 유효하다는 시맨틱은, 사용자가 한참 전에 승인을 하고서 잊어버린 애플리케이션이나 로직이 바뀐 업그레이드 컨트랙트, 혹은 운영이 중단된 프론트엔드까지도 자산에 대한 allowance 권한을 그대로 유지하게 만든다. 보고된 approval 기반 자산 유출 누적 피해는 수년에 걸쳐 수억 달러 규모에 이르며, Revoke.cash 같은 별도 approval 정리 도구가 사실상 일상적인 지갑 관리의 일부로 자리잡은 현재 상황은 이러한 위험이 웹3 생태계 전반에 얼마나 만연한지 가장 직접적으로 드러낸다. ERC-2612의 permit과 ERC-4337 기반의 번들 트랜잭션, 혹은 송금하기(spend) 직전의 safeApprove로 allowance를 재설정하는 애플리케이션 측의 패턴은 모두 이러한 문제를 우회하려는 시도이긴 하지만, approval의 수명을 토큰이 아닌 호출자 측 규율에 의존한다는 구조적인 한계는 그대로 남는다.

ERC-8255가 제안하는 바는 ERC-20 approve의 ABI는 건드리지 않고 그 시맨틱만 재정의하는 것이다. 즉, 기존의 approve(spender, amount) 호출은 토큰 컨트랙트가 정의한 상수 maxApprovalDuration() 만큼만 유효하도록 자동으로 만료되도록 하며, 더 짧은 겍시 기간(window)가 필요하면 새로 도입된 approveForDuration(spender, amount, duration)으로 명시적으로 지정한다. 현재 잔여 권한과 만료 시점은 allowanceAndExpiration(owner, spender)이 한 번에 반환하므로 spender 컨트랙트는 두 번의 view 호출을 할 필요가 없으며, 스토리지는 만료를 uint256(expiration) << 192) | allowance 한 슬롯으로 표현할 수 있다. ERC-2612 permit은 서명 포맷과 논스(nonce) 동작을 그대로 유지한 채 동일한 default duration 규칙을 상속받으며, permit의 deadline 파라미터는 서명 제출 만료 시점일 뿐 approval 만료가 아니라는 점을 그대로 보존한다.

이러한 변경은 지갑과 애플리케이션 단의 approval UX를 근본부터 다시 재정의할 여지를 만든다. 사용자가 무제한 승인(unlimited approval)을 명시적으로 부여하더라도 그 권한이 시간 안에 자동 만료되므로, Revoke.cash 같은 사후 정리 도구가 담당하던 책임이 토큰 컨트랙트 자체로 이동한다. 애플리케이션 측에서는 트랜잭션을 완료하기 직전에 짧은 duration approval을 발급하고 사용 후 자연 만료되도록 두는 패턴이 표준 흐름으로 자리잡을 수 있다. 또한 EIP는 토큰 어드민 또는 spender 자신이 명시적으로 등록한 legacy-compatible spender에 한해 기존 무기한 시맨틱을 옵트인(opt-in) 방식으로 보존할 수 있게 함으로써, 영속적인 approval을 전제로 짠 이전의 통합을 깨지 않으면서 점진적으로 전환할 수 있는 경로를 열어둔다.

2.3.5 기타

• ERC-8040: ESG Tokenization Protocol
• ERC-8084: Zero-knowledge proof metadata
• ERC-8179: Blob Space Segments
• ERC-8180: Blob Authenticated Messaging

2.4 애플리케이션

2.4.1 ERC-8226: Regulated Agent Mandate

토큰화된 실물자산(RWA) 시장은 ERC-3643, ERC-7943 같은 투자자 적격성 표준을 거치며 발행 단계의 컴플라이언스 인프라를 어느 정도 확보해왔다. 한편, 자율적으로 거래를 집행하는 AI 에이전트의 정체성과 신뢰 수준을 다루는 ERC-8004 같은 표준 역시 별도의 트랙에서 정착되어 가는 중이다. 하지만 정작 그 사이를 잇는 표준, 즉 검증된 법인이 어떤 에이전트에게 어떤 권한을 어디까지 위임했는지를 온체인에서 표현할 수단은 부재하다. ERC-8226은 이 위임 관계 자체를 독립된 컨트랙트 계층으로 정의한다.

ERC-8226은 principal(권한을 위임하는 주체)의 자격을 검증하는 IComplianceProvider와, 위임의 발급 & 연장 & 취소 & 집행을 관리하는 IAgentMandate(RAMS 레지스트리)를 별도 컨트랙트로 분리한다. 위임 범위는 IPFS의 JSON 스코프 문서와 그중 온체인에서 강제되는 서브셋인 MandateScopeParams로 이원화되어, 사람이 읽는 합의문과 체인이 강제하는 한도가 동일한 scopeHash 아래 묶인다.

규제 토큰은 기존 pre-transfer hook(예: ERC-7943의 canTransfer) 안에서 에이전트 지갑으로부터 getActivePrincipal(agentId)로 principal을 역참조한 뒤, principal 적격성과 isActiveForAmount(agentId, principal, amount)를 이중으로 검증하고 recordExecution으로 누적 사용액을 갱신한다. 동결 권한은 EnforcerTier로 PLATFORM과 REGULATORY를 명시적으로 구분하며, 글로벌 동결은 규제 티어에만 허용된다.

이러한 구조가 갖는 의의는 기관용 RWA 플랫폼이 AI 에이전트 기반 포트폴리오 운용을 법적으로 방어 가능한 형태로 풀어낼 수 있다는 데 있다. agentId 하나당 활성 mandate 하나라는 제약은 전통 금융에서 운용역이 고객별로 계좌를 분리해 감사 추적을 보장하는 관행을 그대로 온체인에 옮긴 것이며, 운용사는 principal별로 별도 에이전트 지갑을 CREATE2로 배포해 이 요건을 충족한다.

가치 한도를 토큰 base unit으로 고정해 FX 오라클 의존성을 제거하고 cumulativeUsed가 extendMandate 시에도 리셋되지 않도록 설계한 것 역시 위임 계약 단위의 무결성을 우선한 선택이다. 발행자의 적격성 판단(누가 보유 가능한가)과 principal의 권한 부여(누구에게 무엇을 시킬 수 있는가)가 별개 레이어로 분리되면서, 토큰 발행자의 주권을 침범하지 않고도 에이전트 운용의 표준화가 가능해진 셈이다. 이러한 점에서 ERC-8226은 단순히 자율 에이전트의 거래 권한을 코드화한 표준을 넘어, 규제된 디지털 자산 위에서 자율 에이전트 경제가 작동하기 위한 법적 & 기술적 인터페이스의 첫 윤곽으로 평가될 수 있다.

2.4.2 기타

• ERC-8257: Agent Tool Registry

3. 기존 EIP들의 진전

한편, 5월 한달간은 19개의 새로이 채택된 EIP들을 제외하고, 6개의 기존 EIP의 상태가 변화하였다. 특이한 점은, 이번 6개의 EIP들 모두 최종적으로 채택되기위한 다음 단계(i.e., ‘Final’, ‘Last Call’, ‘Review’, ‘Draft’ 등의 단계)로 격상되었다는 점이다.

ERC들 중 특히 주목할만한 것들은 - 합의 레이어 변경 없이 별도 멤풀과 UserOperation & 번들러 & EntryPoint 구조로, 사용자가 EOA 대신 자체 검증 로직을 가진 스마트 컨트랙트 계정을 주 계정으로 쓸 수 있게 하는 계정 추상화 표준인 ERC-4337, 기존 토큰 표준 위에 전송 자격 검사 & 동결 & 강제 이전 같은 최소한의 컴플라이언스 기능을 얹어 실물자산(RWA) 토큰을 규제 친화적으로 표준화하는 인터페이스 표준인 ERC-7943, ERC-8004에 등록된 AI 에이전트의 신뢰도를 검증하기 위한 검증 및 리스크 스코어링 표준인 ERC-8126, 그리고 ERC-20 토큰의 잔액을 “멤버십 수준”으로 해석하여 온체인에서 그룹 구성원과 권한을 표현할 수 있도록 하는 표준인 ERC-8063 등이 있다.

ERC를 제외한 EIP들 중 주목할만한 것들은 - 다른 EVM 체인이 새 명령어를 실험할 수 있도록 이더리움 L1에서는 사용하지 않을 옵코드(opcode) 자리(0xae) 하나를 비워두는 표준인 EIP-8163 등이 있다*.

*이에 대해서는 이전 아티클에서 다루었다.

3.1 코어 / 네트워킹 레이어

• EIP-8013: Static relative jumps and calls for the EVM

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

• ERC-8152: Content-Addressable Logic Modules (CALM)

4. 스테이킹 발행 정책 논쟁과 대형 인프라의 책임에 대하여

이더리움의 스테이킹 수요가 사상 유례없는 속도로 가속되고 있다. 2026년 5월 기준 스테이킹 비율은 사상 최초로 33%에 근접하며 ATH를 기록했고, staking queue에는 약 280만 ETH가 48일치로 쌓여있다. 이러한 흐름의 주된 동력은 리테일 솔로 스테이커의 신규 유입이라기보다는 ETF & DAT(Digital Asset Treasury), 그리고 기관향 스테이킹 상품을 매개로 한 기관 자금이다. ETH를 보유한 기관이 이를 그냥 들고 있는 대신 스테이킹 이율(yield)까지 수취하는 구조로 자산 운용 방식을 빠르게 전환하면서, ETH가 스테이킹 레이어로 유입되는 속도가 더 빨라지는 국면이 본격화된 셈이다.

하지만 이러한 흐름은 이더리움 재단 리서처들이 오래전부터 우려해온 시나리오를 다시 정책 논의의 전면으로 끌어올렸다. 이더리움의 스테이킹 보상 곡선은 스테이킹된 ETH 총량이 늘어날수록 밸리데이터 당 이율(yield)이 그 제곱근에 반비례하여 줄어들도록 설계되어 있지만, 스테이킹이 일정 수준을 넘어가면 네트워크 보안을 위한 적정선보다 더 많은 ETH가 보상으로 발행되며 ETH 보유자들을 희석시키고, 동시에 stETH 같은 LST가 ETH 자체의 화폐성을 위협할 수 있다는 것이 핵심 우려였다.

Ansgar Dietrichs와 Caspar Schwarz-Schilling이 endgame staking economics 논의로 staking ratio targeting 프레임을 제시했고, Mike Neuder 등이 이를 바탕으로 펙트라(당시 일렉트라(Electra)) 업그레이드에 적용할 reward curve 조정안을 정식 제안했다. 같은 해 4월에는 Anders Elowsson이 tempered issuance reward curve를 EIP 리서치 포스트로 정리했고, 하반기에는 이를 확장한 endgame reward curve를 후속 제안했다. 당시에는 스테이킹 업계의 반발과 재단 영향력 논란이 겹치며 묻혔지만, 기관 스테이킹 가속이 가시화된 2026년에 들어 같은 논의가 다시 재부상하게 되었다.

정책 논의는 표면적으로는 "ETH 보유자들의 희석 문제를 어떻게 다룰 것인가, 아니면 현 발행 정책을 유지하며 다른 가치를 지킬 것인가"라는 통화정책 차원의 트레이드 오프이다. 찬성 측은 특정 임계점 이상의 스테이킹은 보안에 대한 한계 기여보다 보유자의 ETH 희석과 LST 화폐성 침식이라는 비용이 더 커지는 구간에 진입한다고 보며, Justin Drake가 제시한 "유통 ETH의 약 1/4 수준이 최적의 보안 예산"이라는 추정도 동일한 선상 위에 있다.

반면 반대 측은 이더리움이 아직 글로벌 정산 레이어로서의 시총 규모에 한참 못 미치는 단계라 "충분한 보안"을 지금 시점에 단정하는 것이 시기상조이며, 발행된 ETH 역시 단순히 비용 측면에서 바라볼 것이 아니라 더 넓은 밸리데이터 베이스를 형성하기 위한 재투자에 가깝다고 본다. 또한 라이도(Lido)의 듀얼 거버넌스(Dual Governance) 도입 이후 LST 도미넌스 우려가 거버넌스 차원에서 점진적으로 완화되고 있는 만큼, 특정 시장 구조를 겨냥한 통화정책 변경이 오히려 이더리움의 장기 로드맵을 단기 우려에 종속시킬 수 있다는 입장이다. 양쪽 모두 일관되게 논리를 주장하고 있으며, 어느 한 쪽이 명백히 옳다고 단정하기 어려운 상태가 현재 정책 논의가 수년째 평행선을 그리는 이유이기도 하다.

다만 어느 방향으로 결론이 나든, 밸리데이터 경제 관점에서 보면 대형 스테이킹 인프라의 상대적 위상이 강화된다는 점은 비교적 분명해보인다. 첫 번째 시나리오인 발행량 유지 케이스에서는 현재의 스테이킹 수요 누적 추세가 그대로 이어진다. ETF & DAT 자금이 LST와 기관향 스테이킹 상품을 통해 스테이킹된 ETH 레이어로 유입되는 흐름이 유지된다면, 라이도를 포함한 대형 LST와 기관향 스테이킹 제공자의 AUM은 스테이킹 비율 상승에 맞춰 자연스럽게 확장된다. 수수료 매출이 AUM과 이율의 곱으로 결정되는 만큼 절대 수익도 함께 증가하는 구조다. 특히 stETH처럼 디파이 전반에서 담보 및 조합성 네트워크 효과를 이미 확보한 LST는 후발주자와의 격차가 시간이 갈수록 벌어지며, 결과적으로 대형 스테이킹 인프라가 스테이킹 레이어의 기본 옵션(default option)으로 자리잡을 것으로 보인다.

역설적으로 두 번째 시나리오인 발행량 축소 케이스에서도 대형 스테이킹 인프라의 상대적 우위는 강화된다. 솔로 스테이커는 운영비 구조의 상당 부분이 줄일 수 없는 항목들로 구성되어 있어 이율의 감소가 곧바로 마진 잠식으로 이어지지만, 대형 운영자는 위임자에게 부과하는 수수료율을 조정해 그 충격을 위임자 쪽으로 흘려보낼 수 있다. 결국 이율이 낮아질수록 솔로 스테이커가 먼저 손익분기점 아래로 밀려나고, 그 공백을 가격 협상력을 가진 대형 CEX & LST & 기관향 스테이킹 상품이 흡수하게 되며, 사용자 입장에서도 직접 밸리데이터를 운영하는 것보다 편의성과 유동성을 함께 제공하는 위임형 옵션을 더 선호하게 된다.

두 시나리오 모두에서 대형 스테이킹 인프라의 비중이 구조적으로 확대된다는 사실은, 이들의 거버넌스 의사결정과 운영자 선정, 슬래싱 리스크 관리, 그리고 ETH 거버넌스에 미치는 영향력이 곧 이더리움 보안 모델의 핵심 변수로 자리잡는다는 의미다. 외부 규제나 프로토콜 차원의 강제만으로는 이러한 자연스러운 영향력을 견제하기 어렵기 때문에, 대형 스테이킹 인프라가 자체적으로 시장 점유율 상한, 밸리데이터 셋 다변화, 거버넌스 권한 위임 같은 자기강제적(self-imposed)인 기준을 확립하는 것이 이더리움의 신뢰할 수 있는 중립성(credible neutrality)을 지키는 가장 현실적인 장치가 된다.

이는 단순히 이윤을 극대화하려는 차원을 넘어, 대형 사업자가 자기 점유율의 크기 자체를 시스템적인 리스크로 인식하고 운영 원칙에 반영해야 한다는 보다 무거운 책임의 영역에 해당한다. 라이도가 초기에 압도적인 도미넌스를 가졌음에도 불구하고 듀얼 거버넌스를 도입해 stETH 보유자에게 위험한 프로토콜 의사결정에 대한 거부권과 ETH 환원 경로를 부여한 것, stVaults를 통해 기관향 참여자에게 독립적으로 운영되는 밸리데이터 집단과 맞춤형 운영 옵션을 제공한 것, DVT 기반 분산 밸리데이터 채택과 다양한 모듈을 통한 운영자 집단의 확대를 지속해온 것은 모두 같은 맥락 위에 있다.

결국 이해관계자가 다양해질수록 프로토콜의 변화는 느려지고, 의견 충돌은 더욱 빈번해질 수밖에 없다. 그럴수록 이더리움의 주요 참여자들은 오랜 시간 공유되어 온 이더리움의 방향성과 원칙을 끊임없이 되새겨야 한다. 그리고 그것을 강제가 아닌 자발적 규율을 통해 지켜낼 수 있는 장치들을 고민해야 하지 않을까.