월간 EIP - 2026년 6월 (ft. 다극화의 전환기에 선 이더리움)

Key Takeaways

• 6월의 EIP 흐름은 규제 대응과 프라이버시 풀 간 자산 이동, 특정 시점의 토큰 보유 현황을 새 토큰에 반영하는 방식 등 ERC가 다루는 범위가 넓어지는 한편, 코어 레이어에서도 스테이킹 프라이버시와 블롭의 사전 전파, 공유 상태를 활용하는 계정 검증처럼 특수한 요구에 대응할 별도 경로를 탐색하는 논의가 진행되었다.
• 또한 이더리움 재단(EF)의 인력 및 예산 축소와 조직 개편, Ethlabs의 출범이 맞물리면서 EF는 이더리움의 중립성과 자기주권적 속성에 집중하고, 외부 조직은 기관 도입과 ETH의 활용 범위를 넓히는 역할을 맡는 구조가 본격적으로 모습을 드러냈다.
• 한편, 이더리움 생태계 내 EF 중심 체제에서 다극화된 개발 생태계로의 전환은 여러 조직이 후원자의 이해관계와 연구의 독립성 사이에서 균형을 잡으며, 하나의 중심 없이 공동의 방향과 책임을 유지할 수 있는지를 시험하는 새로운 탈중앙화 실험으로 이어질 것으로 보인다.

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

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

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

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

6월의 EIP 흐름에서 가장 두드러지는 특징은, 지난 3개월간에 비해 코어(Core) EIP의 채택이 소폭 감소하는 한편, 특히 토큰 표준과 관련하여 ERC 신규 제안이 등장했다는 점이다. 특히 동결과 추적과 같이 규제에 대응하기 위한 기능이나 기존의 ERC-20 기능을 확장해 과거의 보유 구조를 새로운 토큰으로 이전하는 방식, 서로 다른 프라이버시 풀 사이에서 비공개 자산 상태를 전달하는 구조 등 자산 표준이 다루는 범위를 넓히려는 시도가 두드러졌다. 코어 레이어에서도 프라이버시가 필요한 예치와 출금, 데이터를 미리 확정할 수 있는 블롭 전송, 그리고 프레임 트랜잭션 컨텍스트에서 공유 상태를 참조해야 하는 계정 검증처럼 특수한 상황에서 활용할 수 있는 별도의 경로를 마련하려는 제안이 이어졌다.

또한 기존 EIP의 진전에서도 규제 환경에 맞춘 자산 통제(ERC-1450), 트랜잭션 실행 조건의 명시(ERC-7796), 그리고 AI 에이전트의 검증과 권한 관리(ERC-8196)처럼 최근 애플리케이션 수요를 반영한 표준들이 두드러졌다. 이와 함께 ERC-4337을 비롯한 계정 추상화 및 다양한 ERC 계열 표준들도 꾸준히 상태가 격상된 반면, ERC-2770과 EIP-7701, ERC-7766은 ‘Withdrawn’ 상태로 변경됐다.

이는 6월이 새로운 설계의 등장뿐 아니라, 규제형 자산과 조건부 실행, 에이전트 기반 애플리케이션을 뒷받침하는 기존 표준들이 실제 채택 가능성을 높여간 달이었음을 보여준다.

한편, 5월에 두드러졌던 시니어 기여자들의 연쇄 이탈은 6월 들어 이더리움 생태계의 연구와 실행 주체가 재편되는 흐름으로 구체화되었다. 6월 18일 Hsiao-Wei Wang이 안식년을 마친 뒤 이더리움 재단(EF)의 공동 전무이사와 이사회에서 물러나겠다고 발표했고, 닷새 뒤 EF는 수개월간 진행한 조직 개편을 마무리하며 전체 인력의 약 20%에 해당하는 54명과 결별한다고 밝혔다. 비탈릭 부테린 역시 올해 EF의 예산을 약 40% 줄이겠다고 밝혔으며, 새 조직은 프로토콜(Protocol), 접근(Access), 사용(User), 커뮤니티(Community), 기관(Institution)이라는 다섯 개의 레이어별 클러스터와 운영 및 경영 조직으로 재편되었다. 이는 5월에 제시된 ‘이더리움의 중심이 아닌, 정해진 목적을 가진 하나의 노드’라는 방향이 실제 인력과 예산, 조직 구조에 반영되기 시작한 것으로 볼 수 있다.

Source: X(@ethlabs_org)

주목할 점은 EF의 축소가 곧 이더리움 연구 역량의 단순한 감소로만 이어지지는 않았다는 것이다. 조직 개편 하루 전인 6월 22일, Ansgar Dietrichs와 Barnabé Monnot, Caspar Schwarz-Schilling, Josh Rudolf, Julian Ma 등 전직 EF 시니어 연구자 5명은 독립 비영리 연구 조직인 Ethlabs를 출범시켰다. Ethlabs는 BitMine과 SharpLink, Joe Lubin, Anchorage, Octant, SNZ 등의 지원을 바탕으로 결제 완결성, 메인넷 확장, 데이터 가용성, 상호운용성과 ETH의 경제적 속성처럼 기관의 온체인 진입에 필요한 연구를 별도의 트랙에서 추진하겠다고 밝혔다. EF가 검열 및 장악 저항성과 프라이버시, 보안 등 자기주권적 속성을 지키는 프로토콜 관리자로 역할을 좁히는 동안, 기관 채택이나 ETH의 경제적 가치와 보다 직접적으로 연결된 연구는 외부의 전문 조직이 맡는 분업 구조가 형성되기 시작한 셈이다.

이러한 변화는 EF의 영향력이 단순히 약화됐다기보다, 그동안 한 조직 안에 함께 놓여 있던 프로토콜 중립성, 생태계 성장, 기관 채택과 ETH 옹호의 역할이 서로 다른 조직으로 분화되는 과정으로 읽을 수 있다. 다만 EF 내부에도 기관 레이어가 신설된 만큼, 기관 관련 활동을 외부에 완전히 넘긴 것은 아니다. EF는 기관이 이더리움을 도입하더라도 프라이버시와 데이터 이동성, 검증 가능성, 탈출 가능성을 유지하도록 표준과 참조 구조를 만드는 데 초점을 두는 반면, Ethlabs와 Etherealize 같은 외부 조직은 처리 성능과 실제 도입, 자본 및 산업 수요를 보다 직접적으로 연결하는 역할을 맡을 가능성이 높다. 결국 6월의 조직 개편은 ‘EF가 무엇을 포기했는가’보다, 이더리움 생태계에서 누가 어떤 목표를 책임질 것인지가 한층 명시적으로 나뉘기 시작했다는 점에서 의미가 있다.

2. 새로이 제안된 EIP들

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

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

2.1 코어 / 네트워킹 레이어

2.1.1 EIP-8222: Lean Staking

이더리움에서 스테이킹은 온체인 상에서 신원과 자금이 가장 오랫동안 공개적으로 묶이는 활동이다. 이에, 기관의 이더리움 스테이킹 수요가 점점 높아지면서 이처럼 예치 주소와 밸리데이터의 키가 장기간 연결되는 구조는 프라이버시 측면에서 점점 수면위로 떠오르게 되었다. 공개된 예치 내역만으로도 기관의 포지션 규모와 운용 패턴을 분석할 수 있고, 특정 운영자를 오프체인 신원과 연결할 여지도 커지기 때문이다. 지금까지는 믹서나 별도의 프라이버시 컨트랙트로 이를 우회해야 했지만, 이용자가 컨트랙트별로 제한되는 만큼 충분히 큰 익명성 집합을 만들기 어려웠다. 더욱이, 토네이도 캐시(Tornado Cash) 제재가 보여줬듯, 외부 믹서에 의존하는 방식은 기술적인 불편함을 넘어 법률적 & 정치적인 부담까지 수반하게 되었다.

그 사이 EIP-6110이 입금 검증 절차를 실행 계층으로 이전하면서, 스테이킹 컨트랙트 내부에서 예치와 밸리데이터 등록 사이의 공개된 연결을 분리할 수 있는 기반이 마련됐다. EIP-8222는 이를 활용해 자금이 예치되는 시점과 특정 밸리데이터가 등록되는 시점을 분리함으로써, 두 행위 사이의 온체인 연결 고리를 끊으려는 제안이다.

예치자는 밸리데이터 공개키와 출금 정보를 바로 제출하는 대신, 최소 1 ETH와 hash(nullifier_preimage | validator_key | withdrawal_cred | amount) 형태의 커밋먼트를 Pending Deposit Tree에 넣는다. 이때 예치 사실과 금액은 공개되지만, 해당 자금이 어떤 밸리데이터로 이어질지는 드러나지 않는다. 이후 릴레이어나 AA 번들러가 트리 안에 유효한 커밋먼트가 있다는 영지식 증명을 제출하면, 그제야 예치금이 밸리데이터 진입 대기열로 넘어간다. 컨트랙트는 사용된 nullifier를 기록해 같은 예치금이 다시 청구되는 것을 막고, 밸리데이터 키와 금액도 증명에 묶어 청구 내용을 가로채는 공격을 차단한다.

제안은 같은 구조를 출금 단계까지 확장한다. 새로운 0x03 출금 자격 증명을 사용하면 밸리데이터의 자금은 특정 주소로 바로 전송되지 않고 Pending Withdrawal Tree에 들어가며, 수령자는 별도의 증명을 제출해 이를 찾아간다. 이렇게 되면 예치 주소와 밸리데이터 키뿐 아니라 밸리데이터와 최종 출금 주소 사이의 연결도 약해진다. 기관과 스테이킹 사업자 입장에서는 재무 지갑, 운영 중인 밸리데이터, 자금 회수 주소가 하나의 공개된 자금 흐름으로 묶이는 문제를 줄일 수 있다는 점에서 의미가 있다.

다만 EIP-8222가 밸리데이터를 완전히 익명화하는 것은 아니다. 눈에 띄는 예치 금액이나 입금과 청구 사이의 시간 차이와 같은 요소는 여전히 추적의 단서가 될 수 있고, 밸리데이터의 IP와 네트워크 활동도 별도의 보호가 필요하다. 영지식 증명 생성, 비밀값 보관, 릴레이 운영이 새롭게 필요해지는 만큼 복잡성이 사라진다기보다 다른 영역으로 이동한다는 점도 고려해야 한다. 그럼에도 EIP-8222는 외부 믹서에 맡겨졌던 스테이킹 프라이버시를 이더리움의 기본 예치 및 출금 흐름 안으로 가져오려는 첫 구체적인 설계로 볼 수 있다.

2.1.2 EIP-8256: Blob Streaming

이더리움의 블롭 확장 논의는 그동안 각 노드가 얼마나 많은 데이터를 감당하고 검증할 수 있는지에 초점을 맞춰왔다; EIP-4844가 블롭이라는 별도의 데이터 공간을 만들고 PeerDAS가 노드별 다운로드 부담을 낮추었다. 하지만 데이터는 여전히 블록이 제안되는 짧은 시간에 맞춰 네트워크에 도착해야 한다. 이 상태에서 처리량을 높이려면 같은 시간 안에 더 많은 데이터를 전파하거나 블록 전파에 허용되는 시간을 늘려야 하는데, 후자는 빌더가 시장 상황을 지켜본 뒤 블록 공개 여부를 결정할 수 있는 여지를 키운다. 이에, EIP-8256은 전송 용량을 미리 예약하고 데이터를 슬롯 이전부터 퍼뜨려, 블록 생성 시점에 몰린 전파 부담을 시간적으로 분산하여 결과적으로 더욱 안정적인 전파를 가능케하려는 제안이다.

핵심은 블롭을 Ahead-Of-Time(AOT, 사전 전송)과 Just-In-Time(JIT, 적시 전송)이라는 두 경로로 나누는 데 있다. AOT 사용자는 시스템 컨트랙트에서 티켓을 구매해 미래 슬롯의 전송 용량을 확보하고, 실제 블롭 데이터를 합의 레이어의 전용 서브넷을 통해 미리 전파한다. 반면 배치 내용을 블록 직전까지 확정해야 하는 롤업 시퀀서는 기존처럼 블록 생성 시점에 데이터를 보내는 JIT 경로를 이용할 수 있다. 현재 명세에서는 max_fee_per_blob_gas == 0인 트랜잭션을 AOT로, 현재 blob_base_fee 이상을 제시한 트랜잭션을 JIT로 구분하며, 두 경로의 수요는 하나의 블롭 기본 수수료에 함께 반영된다.

여기서 티켓은 특정 미래 슬롯에 블롭 데이터를 미리 전파할 수 있는 네트워크 용량 예약권이다. 사용자는 (blob_count, bls_pubkey)를 등록하고 비용을 선납하며, 구매 시점에서 TICKET_LOOKAHEAD만큼 지난 슬롯이 실제 사용 시점으로 정해진다. 이후 등록한 BLS 키로 데이터에 서명하면, 노드들은 티켓의 유효성뿐 아니라 서명과 KZG 증명까지 확인한 뒤 해당 데이터를 받아 전파한다. 티켓은 환불되지 않기 때문에 데이터를 보내지 않고 용량만 선점하려는 참여자도 정상 사용자와 같은 비용을 부담하며, 네트워크는 슬롯마다 전파를 허용할 데이터의 총량을 사전에 제한할 수 있다.

요컨대, EIP-8256이 바꾸는 것은 블록 생성 이전의 데이터 전달 방식이다. 기존에도 블록에 포함된 블롭은 합의 레이어의 BlobSidecar, PeerDAS 이후에는 DataColumnSidecar를 통해 전파됐지만, 포함 전 단계에서는 실행 레이어의 blobpool도 트랜잭션 본문과 함께 블롭과 KZG 검증 자료를 전달했다. EIP-8256은 blobpool에서 블롭 원문을 제거하고, AOT 데이터는 합의 레이어의 전용 서브넷을 통해 슬롯 이전부터 퍼뜨리도록 한다. 이를 위해 합의 레이어와 실행 레이어는 activeTickets와 availableAotBlobCommitments를 주고받으며, 예약된 용량과 실제로 도착한 데이터, 블록에 포함될 트랜잭션을 서로 맞춰본다.

Source: EIP-8256

EIP-8256의 실용적 의미는 블롭 처리량을 높이기 위해 블록 전파 시간을 무작정 늘리는 대신, 슬롯 이전의 시간을 데이터 전송에 활용한다는 데 있다. 롤업은 배치를 일찍 확정할 수 있다면 AOT로 용량을 확보하고, 막판까지 데이터가 바뀌는 경우에는 JIT를 선택하는 식으로 전파 전략을 나눌 수 있다. 다만 티켓은 데이터 전파 권한일 뿐 블록 포함을 보장하지 않으며, 티켓 구매가 미래 수요를 미리 드러내기 때문에 프런트러닝 가능성과 빌더 의존성도 남는다. 또한, 주요 blob 상수가 아직 TBD이고 실행 및 합의 레이어, 그리고 Engine API 전반의 변경이 필요한 만큼, 이 제안은 완성된 확장 해법이라기보다 PeerDAS의 검증 효율을 실제 처리량 증가로 연결하기 위한 새로운 전파 구조로 보는 편이 적절하다.

2.1.3 기타

• EIP-8279: Block Access List Byte Floor

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

2.2.1 EIP-8272: Recent Roots for Frame Transactions

계정 추상화에서는 트랜잭션의 유효성을 판단하는 규칙도 각 계정의 컨트랙트 코드가 직접 정할 수 있다. 문제는 이 검증 과정이 여러 사용자가 공유하는 외부 컨트랙트의 최신 상태에 의존할 때 생긴다. 특정 상태를 변경하는 거래가 먼저 블록에 포함되면, 이전 상태를 기준으로 멤풀에 들어와 있던 수많은 트랜잭션이 한꺼번에 유효하지 않게 될 수 있기 때문이다. 노드가 이 거래들을 다시 검증하고 정리해야 하는 부담을 막기 위해 프레임 트랜잭션(Frame Transactions, EIP-8141)은 검증 단계에서 다른 계정의 변경 가능한 상태를 직접 참조하는 것을 강하게 제한한다.

이러한 제한은 공개 멤풀을 보호하는 데는 효과적이지만, 계정이 활용할 수 있는 기능까지 함께 좁힌다. 예를 들어 프라이버시 애플리케이션은 여러 사용자의 커밋먼트를 하나의 트리에 모아 관리하고, 지갑 서비스는 여러 계정이 공유하는 승인 키나 보안 정책을 운영할 수 있다. 이런 구조에서는 각 계정의 내부 상태만으로는 최신 권한이나 증명의 유효성을 확인하기 어렵다. 결국 계정 추상화에 필요한 유연성을 넓힐수록 멤풀의 안정성이 약해지고, 멤풀을 안전하게 유지할수록 공유 상태를 활용하기 어려워지는 문제가 남는다.

이를 위한 절충안으로, EIP-8272는 외부 상태를 자유롭게 읽도록 허용하는 대신, 애플리케이션이 특정 시점의 상태를 압축한 32바이트 루트를 미리 기록하도록 한다. 사용자는 트랜잭션을 제출할 때 자신이 어떤 슬롯에 기록된 루트를 기준으로 검증받을 것인지 함께 명시하고, 노드는 그 루트가 실제로 게시된 최근 값인지 먼저 확인한다. 검증 코드는 계속 바뀌는 외부 컨트랙트의 현재 상태를 직접 읽지 않고, 트랜잭션에 고정된 상태의 스냅샷만 사용한다. 이후 새로운 루트가 올라오더라도 기존 트랜잭션은 자신이 지정한 루트가 만료되거나 체인 재구성으로 사라지기 전까지 같은 조건으로 검증될 수 있다.

이러한 구조는 프라이버시 트리, 공동 권한 목록, 공유 보안 정책처럼 여러 계정이 함께 사용하는 상태를 공개 멤풀에서도 제한적으로 활용할 수 있도록 한다. 즉, 계정 추상화의 검증 자유도를 무작정 확대한다기보다는 노드가 의존 관계와 유효기간을 미리 파악할 수 있는 형태로 공유 상태를 들여오는 것이다. 다만 애플리케이션은 루트를 제때 게시하고, 증명이 특정 애플리케이션과 슬롯, 루트에 정확히 연결되도록 설계해야 하며, 노드도 만료와 체인 재구성을 추적해야 한다. 요컨대, EIP-8272는 EIP-8141을 보완하여 계정 추상화의 표현력과 공개 멤풀의 안정성 사이에 통제 가능한 중간 지대를 만들려는 제안으로 볼 수 있다.

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

2.3.1 ERC-8047: Forensic Token (Forest)

동결과 추적 기능이 필요한 온체인 자산(e.g., 스테이블코인, 토큰화 예금 및 증권 등)에서 중요한 문제는 거래를 사전에 막을 수 있느냐보다, 사고 이후 문제 자금과 정상 자금을 얼마나 정확히 분리할 수 있느냐에 있다. ERC-20이나 ERC-3643처럼 계정(account)별로 잔액을 관리하는 구조에서는 서로 다른 경로로 들어온 자금도 하나의 잔액으로 합쳐지기 때문에, 특정 거래에서 유입된 부분만을 떼어내기가 어렵다. 결국 의심 자금을 통제하려면 주소 전체나 일정 금액을 동결해야 하고, 해당 주소가 보유한 정상 자산까지 함께 묶일 수 있다. ERC-8047은 이러한 사후 대응의 단위를 계정 단위에서 DAG 방식의 개별 토큰의 이동 계보로 낮추려는 제안이다.

이를 위해 ERC-8047은 화폐를 하나의 합산된 잔액이 아니라, root, parent, value, level, owner를 가진 개별 Token 노드의 집합으로 표현한다. 처음 발행된 토큰은 자신의 ID를 root로 삼고, 이후 전송이 일어나면 기존 토큰의 value를 줄이거나 0으로 만든 뒤 수취인에게 새로운 자식 ID를 발행한다. 부분 전송에서도 부모 토큰에는 남은 금액이 유지되고, 전송된 금액만큼의 새 토큰이 다음 level에 생성된다. 따라서 전송은 기존 잔액의 소유자를 바꾸는 행위가 아니라, 기존 노드를 지출하고 그 계보를 잇는 새로운 노드를 만드는 과정에 가깝다.

이러한 계보는 곧 규제 조치 등에 적용하는 인덱스로 쓰일 수 있다. 같은 발행 단위에서 갈라진 토큰은 동일한 root를 공유하고, level은 해당 토큰이 최초 발행 이후 몇 단계의 전송을 거쳤는지를 나타내므로 특정 ID뿐 아니라 하나의 계보 전체, 특정 단계 이전이나 이후의 토큰을 함께 격리할 수 있다. 참조 구현인 TPEn(Token Policy Enforcement)은 bucket := shr(8, level)과 bitIndex := and(level, 0xFF)로 256개 레벨의 동결 상태를 하나의 비트맵에 묶고, 전송 시 해당 비트만 조회한다. 명세가 말하는 O(1)은 모든 후손 토큰을 순회하지 않고도 정책을 설정하고 검사할 수 있다는 뜻이지, 전체 거래 계보의 탐색이나 사용 가능 잔액 계산까지 항상 상수 시간에 끝난다는 의미는 아니다.

이러한 표준이 도입된다 하였을 때, 실질적인 변화는 지갑과 인덱서에서 크게 나타난다. 하나의 주소가 같은 자산에 속하지만 서로 다른 root와 동결 상태를 가진 여러 ID를 보유할 수 있으므로, 지갑은 단순한 잔액 차감 대신 어떤 토큰부터 사용할지 정하는 코인 선택 로직과 배치 전송을 지원해야 한다. ERC-8047 역시 실제 사용 가능 잔액은 TokenCreated, TokenSpent, TokenMerged 등의 이벤트를 구독하는 오프체인 서비스에서 계산하는 방식을 제시한다. ERC-1155 및 ERC-5615를 상속해 기존 인터페이스와 이벤트 도구를 활용할 수는 있지만, 동일한 명목 자산이 일련번호를 가진 여러 조각으로 나뉜다는 점에서 일반적인 토큰과는 운영 방식이 크게 달라진다.

그 대가도 분명하다. 사용이 끝난 토큰도 계보 보존을 위해 삭제하지 않는 구조라 거래가 반복될수록 상태가 계속 쌓이며, 높은 소수점 정밀도와 잦은 소액 결제는 ID 파편화와 배치 전송 비용을 키울 수 있다. 부모와 자식 간 관계가 공개되기 때문에 자금 흐름의 프라이버시는 약해지고, 정상 토큰과 제재 대상 토큰을 한 번에 묶어 사용하면 두 자산의 위험 평가가 뒤섞일 가능성도 있다. 무엇보다 ERC-8047은 추적 가능한 데이터 구조를 정의할 뿐, 누가 동결 권한을 갖고 오판과 해제를 어떤 절차로 다룰지는 개별 구현에 남겨두므로, 범용 화폐 표준보다는 정밀한 사후 집행을 위해 프라이버시, 상태 효율, 그리고 단순한 대체가능성을 일부 포기한 규제형 화폐 아키텍처로 보는 편이 적절하다.

2.3.2 ERC-8054: Forkable ERC-20 Token

ERC-20은 현재의 잔액을 기록하는 데는 충분했지만, 특정 시점의 보유 구조를 새로운 토큰으로 옮기는 방법까지 정해두지는 않았다. 따라서 프로토콜이 기존 토큰을 새 컨트랙트로 마이그레이션하거나, 특정 시점의 보유자에게 거버넌스 토큰이나 보상 토큰을 배분하려면 별도의 스냅샷과 머클 트리, 그리고 청구 컨트랙트를 만들어야 했다. 온체인에 이미 존재하는 소유 기록을 다시 외부 데이터로 가공한 뒤, 배포 비용과 증명 생성 부담을 감수하고 사용자가 직접 토큰을 청구하도록 한 셈이다. ERC-8054는 ERC-20에 체크포인트 기반의 잔액 이력을 추가하고, 새로운 ERC-20이 특정 체크포인트의 보유 구조를 그대로 이어받을 수 있게 해 이러한 배분과 마이그레이션을 온체인 표준으로 만들려는 제안이다.

기존의 ERC20Snapshot도 특정 시점의 잔액을 조회할 수 있지만, 스냅샷을 언제 생성할지는 컨트랙트 운영자가 결정하며 그 결과로 새 토큰을 만드는 방식까지 표준화하지는 않는다. 반면 ERC-8054의 소스 토큰은 전송이나 발행, 혹은 소각이 일어날 때마다 잔액과 총공급량의 체크포인트를 남겨, 이러한 외부의 스냅샷 생성 절차 없이 연속적인 이력을 제공할 수 있다. 체크포인트는 블록 번호나 타임스탬프 대신 논스(nonce)로 식별되기 때문에, 포크 시점이 특정 블록 안의 거래 순서에 따라 모호해지는 문제도 줄인다.

소스 토큰은 totalSupplyAt(checkpoint), balanceOfAt(account, checkpoint), 그리고 checkpointNonce()를 포함한 IERC20Checkpointed 인터페이스를 구현한다. 전송과 발행, 소각이 발생할 때마다 새로운 체크포인트를 기록하며, 아직 존재하지 않는 미래의 체크포인트를 조회하면 ERC20FutureCheckpoint 오류를 반환해야 한다. 따라서 포크를 생성하는 쪽은 임의로 작성한 보유자 명단이나 머클 루트를 제출하는 대신, 소스 컨트랙트가 직접 증명하는 특정 시점의 잔액을 참조할 수 있다. 다만 이러한 이력을 유지하려면 소스 토큰의 상태 변경마다 추가 저장 연산이 필요하므로, 미래의 포크 가능성을 확보하는 비용은 평상시 전송을 수행하는 사용자들이 나누어 부담하게 된다.

포크된 토큰은 배포 시 checkpointedToken과 checkpointedNonce를 지정하고, 해당 지점의 totalSupplyAt()과 각 계정의 balanceOfAt()을 초기 공급량과 잔액으로 이어받는다. 그렇다고 모든 보유자의 잔액을 새 컨트랙트에 한꺼번에 복사하는 것은 아니며, 계정에 첫 상태 변화가 생기기 전까지는 소스 토큰의 과거 잔액을 조회하는 지연 로딩 방식을 쓴다. 이후 그 계정이 토큰을 전송하거나 받으면 포크 토큰 내부의 잔액으로 전환되고, 그때부터는 소스 토큰과 독립적으로 움직인다. 따라서 ‘가스 없는 배분’은 토큰 생성 자체가 무료라는 뜻이 아니라, 보유자 수만큼 전송하거나 사용자가 별도의 청구 트랜잭션을 보낼 필요가 없다는 의미에 가깝다.

이 구조는 토큰 마이그레이션이나 보상 배분뿐 아니라, 기존 보유 관계를 유지한 채 별도의 거버넌스 권리나 위험 및 수익 구조를 분리하는 데에도 활용될 수 있다. 포크된 토큰도 일반 ERC-20으로 동작하므로 기존 지갑과 애플리케이션의 변경 부담은 크지 않지만, allowance와 permit nonce는 승계되지 않으므로 사용자는 새로운 토큰에 다시 승인해야 한다. 또한 리베이싱(rebasing)이나 fee-on-transfer처럼 잔액 변화가 표준 ERC-20 전송 규칙에만 담기지 않는 토큰은 체크포인트와 실제 경제적 권리가 어긋날 수 있다.

요컨대, ERC-8054는 프로토콜 전체를 복제하는 범용적인 ‘포크’라기보다, 특정 시점의 소유 구조를 온체인에서 검증 가능한 방식으로 재사용하는 표준이며, 그 편의성을 위해 지속적인 저장 비용을 감수할 가치가 있는 토큰에 더 적합하다.

2.3.3 기타

• ERC-8100: Representable Contract State
• ERC-8273: Attestation-Gated Agentic Actions

2.4 애플리케이션

2.4.1 ERC-8290: Shielded Note Teleportation

프라이버시 프로토콜의 한계는 개별 풀 안에서 거래를 얼마나 잘 숨기느냐보다, 서로 다른 풀 사이를 이동하는 순간 더 뚜렷해진다. 한 풀에서 공개적으로 출금한 뒤 다른 풀에 다시 예치하면 금액과 시점, 자산 종류, 출발지와 목적지를 조합해 두 거래를 연결할 수 있기 때문이다. 결국 각 프로토콜이 충분한 익명성 집합을 구축하더라도, 사용자는 프로토콜을 바꿀 때마다 해당 프로토콜 밖으로 나와야 한다. ERC-8290은 이러한 이동을 공개된 자산 흐름이 아니라, 이전 프라이버시 풀에 유효한 자산이 존재했다는 증명의 전달로 바꾸려는 제안이다.

아이디어의 출발점은 자산을 특정한 소유자가 없는 주소에 보내고, 이후 영지식증명으로 그 소각 사실을 증명하는 EIP-7503의 ‘ZK Wormhole’이다. 다만 EIP-7503이 이더리움의 ETH를 비공개로 소각하고 다시 발행하는 코어 프로토콜 변경을 다룬다면, ERC-8290은 이를 애플리케이션 레이어의 UTXO형 프라이버시 프로토콜 간 상호운용 표준으로 확장한다. 기존 풀도 노트 커밋먼트와 루트 포함 관계를 어댑터로 표현할 수 있다면 자체 포맷을 바꾸지 않고 출발지로 활용될 수 있다. 하지만 출발지 풀에 잠긴 자산을 목적지에서 어떻게 뒷받침할지는 별도의 문제이므로, 이 제안이 곧바로 브리지나 유동성 구조를 대체하는 것은 아니다.

burnAddress = H(chainId, dstPoolAddress, receiver, burnSecret, "ZKTELEPORT")

사용자는 먼저 목적지 체인과 풀, 수령인, 비밀값인 burnSecret을 묶어 burnAddress를 만들고, 이를 기존 소유자 주소 대신 출발지 풀의 노트에 넣는다. 이 주소는 특정 목적지를 위해 만들어지기 때문에 같은 노트를 다른 체인이나 컨트랙트에서 다시 사용할 수 없다. 이후 teleport proof는 해당 노트가 출발지 풀에 실제로 존재하고, 그 풀의 루트가 목적지에서 신뢰하는 canonicalRoot에 포함돼 있으며, 토큰과 금액 같은 자산 정보도 그대로 이어진다는 사실을 증명한다. 노트 구조나 해시 함수가 다른 프로토콜도 어댑터를 통해 각자의 검증 방식을 이러한 흐름에 연결할 수 있다.

목적지 컨트랙트는 먼저 출발지 풀의 루트가 신뢰할 수 있는지 확인한 뒤 증명을 검증하고, nullifier를 기록해 같은 노트가 두 번 사용되는 것을 막는다. 다만 영지식증명은 소스 풀에 유효한 자산이 있었다는 사실만 증명할 뿐, 목적지에서 실제 자산을 지급할 수 있는지까지 보장하지 않으므로 에스크로, 신규 발행, 프로토콜 보유 자산, 브리지 정산 등의 담보 구조는 별도로 필요하다.

이러한 구조가 자리 잡으면 서로 다른 프라이버시 프로토콜이 하나의 포맷으로 통합되지 않고도 익명성 집합을 연결할 수 있고, 규모가 작은 풀도 기존 대형 풀의 프라이버시를 일부 이어받을 수 있다. 반면 어댑터나 루트 레지스트리를 잘못 구현하면 이중 사용이나 자산 인플레이션으로 이어질 수 있고 이동 시점이 노출될 가능성도 남아 있다. 요컨대, ERC-8290은 프라이버시 풀을 하나로 합치기보다 서로 다른 정책을 유지한 채 비공개 자산 상태를 옮길 수 있는 공통 인터페이스를 마련하려는 제안에 가깝다.

2.4.2 기타

• ERC-8217: Agent NFT Identity Bindings

3. 기존 EIP들의 진전

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

격상된 표준들 중 특히 주목할만한 것들은 - 토큰 보유자가 직접 transfer 및 approve하는 것은 차단하고 SEC 등록 이전대리인(RTA)만이 발행 & 소각 & 이전을 집행하도록하여 Reg CF/D/A 규제를 충족하는 증권 토큰을 정의하는 표준인 ERC-1450, 트랜잭션을 보낼 때 특정 계정의 사전 조건을 함께 명시할 수 있는 eth_sendRawTransactionConditional RPC를 정의해, 빌더가 시뮬레이션 없이 포함 여부를 판별하고 트랜잭션 간 교차 의존을 저비용으로 처리할 수 있게 하는 표준인 ERC-7796, 그리고 AI 에이전트가 온체인에서 할 수 있는 액션을 정책으로 제한하고 모든 실행에 감사 가능한 서명 로그를 남기게 하여 소유자가 개인키를 넘기지 않고도 자율 에이전트를 통제할 수 있게 하는 지갑 표준인 ERC-8196 등이 있다.

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

3.1 코어 / 네트워킹 레이어

• EIP-8133: Network Upgrade Naming

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

• 이외 없음

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

• ERC-4337: Account Abstraction Using Alt Mempool
• ERC-5516: Soulbound Multi-owner Tokens
• ERC-7813: Store, Table-Based Introspectable Storage

3.4 애플리케이션

• ERC-8126: AI Agent Verification
• ERC-8161: Transferable Tokenized Vault Requests

4. 다극화의 전환기에 선 이더리움

Source: Twitter(@trent_vanepps)

지난 6월에는, 이더리움 코어 개발 자금이 향후 3~9개월 안에 부족해질 수 있다는 Trent Van Epps의 경고가 화제가 된 바가 있었다. 다만 실제로 개발이 중단될 가능성보다 더 눈여겨볼 부분은, 이 문제를 해결하는 과정에서 앞으로 누가 이더리움을 이끌게 될 것인가이다. 지금까지는 EF가 축적해온 자산과 인재, 생태계의 신뢰를 바탕으로 장기 연구와 코어 개발을 지원해왔다. 결국 개발 자금 부족에 관한 논의는 EF가 줄여온 역할을 앞으로 어떤 조직과 이해관계자가 나눠 맡을 것인지에 관한 논의이기도 하다.

EF 중심 체제의 가장 큰 장점은 당장 수익으로 이어지지 않더라도 프로토콜에 필요한 일을 꾸준히 지원할 수 있었다는 점이다. 특정 기업의 실적이나 토큰 가격, 시장의 관심과 무관하게 클라이언트 개발과 보안 연구, 업그레이드 조율 같은 공공재에 장기적으로 자금을 투입할 수 있었다. 반면 주요 자금과 인재가 한 조직에 모이면서 EF의 판단이 이더리움 전체의 우선순위로 받아들여지고, 공식적인 권한 이상으로 큰 영향력을 행사한다는 비판도 끊이지 않았다. EF가 스스로 역할을 줄여온 것은 이러한 의존을 낮추려는 선택이었지만, 그 빈자리를 건강한 시장과 새로운 조직들이 자연스럽게 채워주는 것은 아니다.

앞으로는 Protocol Guild처럼 생태계의 후원을 모으는 조직과 Ethlabs 같은 독립 연구기관, 클라이언트 팀과 애플리케이션 사업자들이 각자의 방식으로 프로토콜 개발을 지원할 가능성이 높다. 하나의 조직이 모든 연구 의제와 예산을 정하는 구조보다 다양한 실험과 경쟁이 가능해진다는 점은 분명한 장점이다. 하지만 자금원이 흩어질수록 어떤 개발을 누가 책임지고, 무엇을 우선하며, 실패했을 때 누가 책임질 것인지는 오히려 모호해질 수 있다. 이더리움의 다극화는 EF의 영향력을 여러 조직에 나누는 데서 끝나는 것이 아니라, 서로 다른 이해관계와 정당성을 지닌 조직들이 하나의 프로토콜을 함께 발전시킬 새로운 조율 방식을 만드는 과정에 가깝다.

특히 코어 개발 자금을 어떤 방식으로 마련하느냐는 그 자체로 새로운 거버넌스 레이어가 될 수 있다. 거래소와 L2, 스테이블코인, 스테이킹 사업자처럼 이더리움 위에서 큰 가치를 축적한 기업들이 개발비를 부담한다면 공공재의 무임승차 문제는 줄어들 수 있다. 반면에, 자금을 많이 제공하는 조직의 사업적 필요가 연구와 개발의 우선순위에 반영될 가능성도 커진다. 그렇다고 후원자의 영향력을 지나치게 차단하면 Protocol Guild와 같은 자발적 기부에 의존해야 하고, 시장이 어려워질 때마다 장기 연구와 개발 조직의 기반이 흔들릴 수 있다. 결국 중요한 것은 자금의 규모보다, 후원자의 이해관계와 연구 의사결정 사이에 얼마나 분명한 거리를 둘 수 있느냐이다.

EF 이후의 이더리움은 하나의 후계 조직이 등장하기보다, 각 분야에서 전문성과 신뢰를 쌓은 여러 조직이 느슨하게 협력하는 모습에 가까울 것이다. 이러한 구조는 특정 조직이나 리더십의 실패가 생태계 전체로 번지는 위험을 낮추는 대신, 조율 속도를 늦추고 의견 충돌을 일상적인 조건으로 만들 우려도 있다. 그렇기 때문에 새로운 조직들은 자금과 인력을 확보하는 데 그치지 않고, 자신들이 무엇을 위해 존재하며 어떤 이해관계로부터 독립적인지를 지속적으로 증명해야 한다. 이더리움의 다음 탈중앙화 실험은 노드나 밸리데이터의 숫자나 다양성 따위보다, 프로토콜을 만드는 여러 조직이 하나의 중심 없이도 공동의 방향을 유지할 수 있는지에 달려 있지 않을까.