월간 EIP - 2026년 8월 (ft. 로빈후드 체인이 보여준 L2의 성공과 이더리움의 딜레마)

Key Takeaways

• 8월에는 신규 EIP가 줄어든 대신 기존 Core EIP의 진전이 활발했으며, Core 레이어에서는 상태 보존, 블록 생산, 데이터 전파, 실행 검증에 드는 비용과 부담을 분산하려는 논의가 구체화됐다. ERC에서는 모듈 구성과 자금 활용, 정책 검증처럼 애플리케이션마다 따로 구현하던 기능을 공통 규격으로 정리하려는 제안들이 두드러졌다.
• 또한 EF는 글램스테르담(Glamsterdam)의 주요 변경 사항을 공개 테스트넷과 과거 메인넷 데이터로 검증하고 기존 애플리케이션의 전환을 지원하는 한편, 프런트엔드 보안과 AI를 활용한 포스트퀀텀 연구까지 지원 범위를 넓히며 주요 의제를 실제 시험과 배포 준비 단계로 옮기기 시작했다.
• 한편, 로빈후드 체인의 성공은 대형 금융회사가 이더리움 기술을 활용해 기존 자산과 사용자를 온체인으로 끌어들일 수 있음을 보여주는 동시에, 거래와 수익이 기업형 L2에 머무를 경우 L2의 성장이 곧 이더리움의 성장으로 이어지지는 않는다는 점을 드러내며 이더리움만이 제공할 수 있는 가치를 어떻게 강화할 것인지라는 과제를 남겼다.

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

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

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

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

8월의 EIP 흐름에서 가장 두드러지는 특징은, 신규 제안 수가 지지난달과 비슷한 수준으로 돌아온 반면 기존 EIP의 진전은 Core EIP를 중심으로 활발하게 이뤄졌다는 점이다. 신규 EIP는 총 10개로 전월보다 14개 줄었지만, 25개의 기존 EIP가 다음 단계로 올라갔으며 철회된(withdraw) 제안은 없었다.

새로 제안된 Core EIP 중 EIP-8321은 RANDAO를 BLS 서명에서 해시 체인으로 분리했고, EIP-8347은 기존 MPT 상태를 오프라인에서 PBT로 옮긴 뒤 정해진 하드포크에서 전환하는 방식을 제시했다. 또한 EIP-8371은 블롭 복구 작업을 네트워크 전반에 분산하고, EIP-8390은 향후 라이트 클라이언트 운영 등의 활용사례를 위해 싱크 위원회를 영지식 기반의 파이널리티 증명으로 대체하는 등 특정 암호 체계와 고사양 노드, 소규모 검증자 집단에 대한 의존을 줄이려는 시도가 이어졌다.

애플리케이션 레이어를 위한 ERC에서는 복잡한 실행 과정을 여러 컨트랙트와 서비스가 함께 사용할 수 있는 인터페이스로 정리하려는 흐름이 나타났다. ERC-8349는 함수 셀렉터 대신 1바이트 인덱스로 실행할 패싯을 지정해 모듈 단위의 배포와 업그레이드를 단순화하고, ERC-8187은 사용자가 허용한 한도 안에서 볼트나 대출 프로토콜에 예치된 자산까지 결제에 활용할 수 있는 Token Puller 인터페이스를 제시했다. 한편 ERC-8354는 AI 에이전트의 행동이 비공개 정책을 충족했는지를 영지식증명으로 확인한 뒤 실행 여부를 결정할 수 있도록 했다. 전반적으로 모듈 구성과 자금 조달, 정책 검증처럼 애플리케이션이 개별적으로 구현하던 과정을 공통된 실행 규격으로 만들려는 제안들이 두드러졌다.

기존 EIP의 진전에서는 오랫동안 논의돼 온 프로토콜 개편안들이 대거 다음 단계로 이동했다. 오래된 블록과 영수증 데이터를 프루닝할 수 있도록 하는 EIP-4444, 블록 제안자와 빌더를 프로토콜 수준에서 분리하는 EIP-7732, 실행 증명을 활용한 선택적 무상태 검증을 제안하는 EIP-8025가 대표적이다. 이 밖에도 상태 생성 비용을 별도의 state gas로 계량하는 EIP-8037, 블롭 보관과 전파 부담을 분산하는 EIP-8070, BAL을 활용해 상태 동기화를 개선하는 EIP-8189가 진전됐다.

요컨대, 8월은 신규 제안의 양보다, 상태 보존과 블록 생산, 데이터 전파, 실행 검증 등 이더리움의 장기적인 비용 구조와 역할 분담을 손보는 Core EIP들이 본격적으로 성숙했다는 점에 더 큰 의미가 있다.

Source: blog.ethereum.org

한편, 7월까지 새 조직 아래에서 주요 의제를 구체화한 이더리움 재단(EF)은 8월 들어 이를 실제 테스트와 배포 준비 단계로 옮기기 시작했다. 8월 17일 EF Protocol DevOps 팀은 Glamsterdam의 주요 변경 사항을 공개적으로 시험할 수 있는 Platåberget 테스트넷을 발표했다. 이 테스트넷에는 ePBS와 Block-Level Access List, 가스 재가격화 등이 적용됐으며, 솔로 스테이커와 DVT 프로젝트, 대형 운영자도 직접 밸리데이터와 빌더를 등록해 새로운 블록 생산 흐름을 시험할 수 있도록 설계됐다. 이는 Glamsterdam 준비가 클라이언트 팀 중심의 단기 devnet을 넘어, 실제 영향을 받는 운영자와 애플리케이션 개발자가 참여하는 공개 검증 단계로 넘어갔음을 보여준다.

새로운 확장 구조가 기존 애플리케이션에 미칠 영향을 사전에 확인하려는 작업도 병행됐다. 8월 24일 EF Protocol Research와 EthPandaOps, Specifications 팀은 EIP-8037과 EIP-8038의 가스 재가격화를 과거 메인넷 트랜잭션에 적용한 분석을 공개했다. 대다수 컨트랙트는 영향을 받지 않았지만 일부는 기존 가스 한도에 대한 가정 때문에 실행이 실패하거나 성능이 저하될 수 있었고, EF는 영향 확인 도구를 제공하는 한편 관련 빌더들에게 직접 연락하기 시작했다. 향후 가스 한도를 높이기 위해 상태 생성과 접근 비용을 조정하면서도, 기존 애플리케이션이 갑작스럽게 깨지지 않도록 프로토콜 변경과 마이그레이션 지원을 함께 추진한 셈이다.

보안 분야에서는 보호 범위와 연구 참여 방식을 동시에 넓히려는 움직임이 나타났다. 8월 5일 EF Access 클러스터는 웹사이트가 제공하는 코드가 개발자가 공개한 버전과 일치하는지 확인하는 WEBCAT에 대한 지원을 발표해, 보안의 범위를 합의와 스마트 컨트랙트에서 지갑과 디앱의 프런트엔드까지 확장했다. 이어 8월 20일 Formal Verification 팀은 누구나 자신의 AI 에이전트를 활용해 포스트퀀텀 SNARK의 보안 수준을 개선하고, 결과를 Lean으로 검증받을 수 있는 better.codes 공개 연구 챌린지를 시작했다.

2. 새로이 제안된 EIP들

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

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

2.1 코어 / 네트워킹 레이어

2.1.1 EIP-8321: Hash-Chain RANDAO

이더리움은 블록을 만들 밸리데이터를 무작위로 배정한다. 이때 사용하는 무작위 값은 RANDAO가 여러 블록 제안자의 기여값을 계속 섞어 만든다; RANDAO 기여값 = BLS 서명(밸리데이터 비밀키, 에포크 번호)

현재 기여값으로는 에포크 번호에 대한 BLS 서명을 사용하는데, 같은 밸리데이터가 같은 내용에 서명하면 결과가 항상 하나로 정해진다. 따라서 여러 서명을 만들어 각각의 배정 결과를 비교한 뒤, 자신에게 유리한 서명만 제출하는 것은 불가능하다.

문제는 BLS가 양자컴퓨터의 공격을 견디도록 설계된 서명 방식이 아니라는 점이다. 공격자가 밸리데이터의 비밀키를 알아내면 앞으로 제출될 기여값을 미리 계산하고, 향후 블록 제안자 배정까지 예측할 수 있다. BLS를 포스트퀀텀 서명으로 바꾸는 것만으로도 해결되지 않는데, 일부 포스트퀀텀 서명(e.g., XMSS)은 같은 메시지에서도 서로 다른 서명을 여러 개 만들 수 있기 때문이다. 이 경우 밸리데이터는 각 서명이 RANDAO에 들어갔을 때 누가 블록 제안자로 배정되는지 비교하고, 자신에게 가장 유리한 결과를 골라낼 수 있다.

EIP-8321은 RANDAO에 넣는 값을 서명이 아니라 미리 만들어둔 ‘해시 체인’에서 하나씩 꺼내도록 바꾼다. 밸리데이터는 임의의 비밀값 c_0에 BLAKE3 해시를 반복 적용해 긴 값의 사슬을 만들고, 그 마지막 값 c_n만 온체인에 먼저 등록한다. 이후 블록을 제안할 때마다 체인을 거꾸로 한 칸씩 공개하며, 프로토콜은 새로 공개된 값을 한 번 해시했을 때 앞서 저장된 값이 나오는지 확인한다. 공개할 값이 등록 시점에 이미 정해지므로, 밸리데이터는 자신의 블록 제안 순서를 본 뒤 유리한 값을 새로 만들거나 고를 수 없다.

새로 공개된 값은 mix = blake3(mix + reveal) 방식으로 기존 RANDAO 값에 더해진다. 같은 값을 다시 넣더라도 이전 기여가 지워지는 대신 전혀 다른 결과가 나오기 때문에, 다른 밸리데이터의 값을 복사해 서로의 기여를 상쇄하는 공격도 어렵다. 밸리데이터가 처음 등록한 해시 체인은 3에포크가 지난 뒤 활성화되며, 아직 전환하지 않은 밸리데이터는 기존 BLS 방식을 계속 사용할 수 있다. PREVRANDAO를 비롯해 애플리케이션이 받아보는 값의 형식도 그대로 유지되므로, 실행 레이어와 스마트 컨트랙트는 생성 방식이 달라져도 별도로 수정할 필요가 없다.

다만 이 제안만으로 이더리움의 합의 과정 전체가 양자컴퓨터에 안전해지는 것은 아니다. 해시 체인을 처음 등록할 때와 블록에 서명할 때는 여전히 BLS를 사용하며, 밸리데이터가 값을 공개하지 않고 블록 보상을 포기하는 방식으로 RANDAO에 제한적인 영향을 주는 것도 여전히 가능하다. 또한 운영자가 해시 체인의 비밀값을 잃거나 잘못된 값을 등록하면 이를 중간에 교체할 수 없어, 해당 밸리데이터를 종료하고 새로 등록해야 한다. 요컨대, EIP-8321의 의의는 RANDAO를 BLS의 특성에서 미리 분리해 향후 서명 방식을 교체하기 쉽게 만드는 데 있다.

2.1.2 EIP-8347: Offline State Migration to the PBT

Source: EIP-8297

이더리움은 모든 계정의 잔액과 컨트랙트 데이터를 MPT(Merkle Patricia Trie)라는 구조에 기록한다. 하지만 MPT는 상태가 올바른지 증명할 때 많은 데이터를 요구하고, 영지식증명으로 처리하기에도 복잡해 장기적인 확장에 적합하지 않다는 지적을 받아왔다. EIP-8297은 이를 더 단순하고 증명하기 쉬운 PBT(Partitioned Binary Tree)라는 새로운 구조로 바꾸려는 제안이다. 하지만, 새로운 트리를 설계하는것만큼이나, 기존 네트워크에 쌓여있는 상태를 안전하게 옮기는 것도 매우 중요하다. EIP-8347은 기존 MPT에 쌓인 방대한 데이터를 PBT로 안전하게 옮기는 방법을 다룬다.

데이터를 옮기는, 가장 직관적인 방법은 블록이 생성될 때마다 일부 데이터를 조금씩 옮기는 것이다. 하지만 이러한 방식을 택하면 어느 데이터까지 변환됐는지 모든 노드가 계속 확인해야 하고, 데이터 구조의 전환 기간에는 기존 구조와 새로운 구조를 함께 다뤄야 한다. 상태 증명을 확인하는 브리지(bridge)나 라이트 클라이언트(light client)도 두 구조가 섞인 별도의 검증 방식을 구현해야 한다. EIP-8347은 이런 복잡성을 피하기 위해 변환 작업을 미리 진행하고, 정해진 하드포크에서 한 번에 PBT로 전환한다.

먼저 이미 확정돼 되돌아갈 가능성이 없는 블록을 ANCHOR_BLOCK으로 지정하고, 그 시점의 전체 상태를 PBT 형식의 스냅샷으로 만든다. 여기서 스냅샷은 특정 시점의 모든 계정과 컨트랙트 데이터를 새로운 저장 방식에 맞춰 정리한 파일이라고 보면 된다.

검증은 새 구조와 기존 구조를 각각 기준으로 한 번씩 진행된다. 먼저 스냅샷으로 PBT를 다시 만들어 제시된 루트와 일치하는지 확인하고, 같은 데이터를 기존 MPT 방식으로 계산해 ANCHOR_BLOCK에 기록된 stateRoot도 재현되는지 확인한다. 이후 앵커 블록 다음에 발생한 잔액과 스토리지 등의 변경 사항은 EIP-7928의 Block-Level Access List(BAL)를 통해 반영한다. 이는 앵커 이후의 모든 트랜잭션을 다시 실행하지 않고, 각 블록에서 실제로 바뀐 값만 새 장부에 옮겨 적는 방식이다.

전환 전에는 검증자들이 매 블록의 PBT 루트를 별도로 계산해 ‘섀도 루트(shadow root)’로 공개하고, 서로 다른 클라이언트가 같은 결과에 도달하는지 충분히 확인한다. 이후 PBT_ACTIVATION_FORK가 실행되면 블록 헤더의 stateRoot가 MPT 대신 PBT를 기준으로 계산되기 시작하며, 문제가 생겼을 때 되돌릴 수 있도록 포크가 확정될 때까지 두 구조를 함께 보관한다.

이 방식은 장기간 두 트리가 합의 규칙 안에서 공존하는 상황을 피하고, 상태 트리 교체를 하나의 명확한 전환 시점으로 단순화한다. 하지만 변환에 참여하는 노드는 전환 기간 동안 메인넷 기준 약 300GB의 추가 저장공간을 확보해야 하고, 대용량 스냅샷과 프리이미지를 안정적으로 배포할 인프라도 필요하다. 브리지와 라이트 클라이언트, eth_getProof 기반 서비스처럼 상태 증명을 직접 확인하는 시스템은 새로운 PBT 증명 형식에 맞춰 별도로 업그레이드해야 한다.

2.1.3 EIP-8371: RowDAS - Distributed Blob Reconstruction

PeerDAS는 블롭(blob) 데이터를 여러 열(column)로 나눠 노드마다 일부만 보관하게 함으로써, 모든 노드가 전체 데이터를 내려받아야 했던 구조를 개선한다. 다만 데이터 일부가 제때 퍼지지 않았을 때는 128개 열 가운데 절반 이상을 보유한 노드가 소실된 부분을 복원해야 하며, 특히 모든 열을 구독하는 슈퍼노드들이 같은 블롭을 각자 복구하는 경우가 많다. 이 때, 블롭 수가 늘어날수록 이들의 CPU와 대역폭 부담도 함께 커지기 때문에, 처리량을 높일수록 데이터 복구가 고사양 노드에 의존하는 역설이 생긴다. EIP-8371은 복구 대상을 네트워크 전체에 나눠 맡기는 RowDAS를 통해 이러한 병목을 완화하려는 제안이다.

PeerDAS에서 하나의 블롭은 행(row)에 해당하고, 각 노드는 여러 블롭에서 자신에게 배정된 열의 조각(cell)만 보유한다. RowDAS는 기존 열 서브넷에 data_row_{subnet_id}라는 128개의 행 서브넷을 추가하고, 각 블롭을 슬롯마다 다른 행 서브넷에 배정한다. 노드 역시 자신의 ID를 기준으로 하나의 행 서브넷에 배정되며, 같은 서브넷에 모인 노드들은 각자 보유한 조각을 공유한다. 개별 노드가 충분한 데이터를 갖고 있지 않더라도, 서브넷 전체에서 한 행의 128개 조각 가운데 64개 이상을 모으면 나머지를 복구할 수 있는 구조다.

블롭과 서브넷의 연결은 compute_shuffled_index를 이용해 슬롯마다 의사무작위로 바뀌기 때문에, 특정 서브넷에 작업이 장기간 몰리지 않는다. 반면 노드가 담당하는 행 서브넷은 블롭 수와 무관하게 고정되어 있어, 블롭 한도가 바뀌더라도 네트워크 연결을 다시 구성할 필요가 없다. 각 노드는 자신이 확보한 조각의 위치를 비트맵으로 알리고, 다른 노드가 이미 복구를 마쳤다면 예정된 작업을 취소한다. 행 서브넷에서 받은 모든 조각은 전달하거나 복구에 사용하기 전에 해당 블롭의 KZG 커밋먼트와 대조해 검증한다.

복구는 세 단계로 진행된다. 먼저 64개 이상의 열을 구독하는 ‘행 복구 노드’가 자신에게 배정된 행을 복구하고, 일정 시간이 지나도 비어 있는 행은 슈퍼노드가 보완하며, 마지막에는 일반 노드도 같은 행 서브넷에서 64개 이상의 조각을 모았다면 복구에 참여할 수 있다. 일반 노드의 작업은 앞선 단계가 실패했을 때만 발생하므로 평상시 CPU 부담은 제한하면서도, 슈퍼노드 없이 데이터를 되살릴 수 있는 예비 성격의 경로를 만든다. 제안서의 추산대로 약 1만 2,000개 노드가 128개 행 서브넷에 고르게 참여한다면, 서브넷마다 약 94개 노드가 데이터를 함께 모으는 셈이다.

다만 RowDAS가 PeerDAS의 한계를 모두 해결하는 것은 아니다. 데이터 샘플링에 필요한 대역폭은 여전히 블롭 수에 비례하며, L2 노드가 자신에게 필요한 특정 블롭만 곧바로 받아오는 기능도 이번 제안에는 포함되지 않는다. 또한 새로운 행 서브넷과 비트맵 메시지를 운영해야 하는 만큼 클라이언트와 피어(peer) 관리가 복잡해지고, 복구 단계별 대기 시간처럼 아직 확정되지 않은 변수도 남아 있다. 그럼에도 데이터 가용성 판단은 기존 열 서브넷을 그대로 기준으로 삼으면서 복구 작업만 분산한다는 점에서, RowDAS는 PeerDAS의 보안 가정을 크게 바꾸지 않고 향후 블롭 확장에 필요한 운영 비용과 슈퍼노드 의존도를 낮추는 현실적인 보완책으로 볼 수 있다.

2.1.4 EIP-8390: Remove the Sync Committee

이더리움 라이트 클라이언트는 블록체인의 모든 데이터를 내려받지 않고도 최신 블록이 유효한지 확인할 수 있도록 만든 가벼운 클라이언트다. 하지만 수십만 명에 달하는 검증자의 서명을 매번 확인하기는 부담스럽기에, 현재는 전체 검증자 가운데 512명을 무작위로 샘플링하여 뽑은 ‘싱크 위원회(Sync Committee)’가 이를 대신한다. 2021년에는 이러한 방식이 현실적인 절충안이었지만, 라이트 클라이언트의 보안이 이더리움 전체가 아닌 512명의 작은 집단에 달려 있다는 한계도 함께 남겼다.

싱크 위원회는 전체 검증자 가운데 뽑힌 512명으로 구성되며, 약 27시간마다 교체된다. 라이트 클라이언트는 전체 검증자의 합의를 직접 확인하는 대신, 이 가운데 3분의 2 이상이 서명한 블록 헤더를 유효한 것으로 받아들인다. 문제는 위원회 다수가 가짜 헤더에 서명해도 해당 서명만을 이유로 예치금을 삭감하는 규칙이 없다는 점이다. EIP-7657은 이를 처벌하는 슬래싱 방안을 제시하지만, 라이트 클라이언트가 전체 검증자가 아닌 512명의 판단에 의존한다는 구조적 한계는 그대로 남는다.

EIP-8390이 제시하는 대안은 전체 활성 검증자가 특정 체크포인트를 확정했다는 사실을 영지식증명으로 압축하는 방식이다. 외부 증명 생성자가 많은 검증자의 BLS 서명과 지분을 확인해 짧은 증명을 만들면, 라이트 클라이언트는 이를 수 밀리초 안에 검증할 수 있다. 쉽게 말해 512명의 대리인에게 다시 묻는 대신, 전체 검증자의 합의 결과가 맞다는 ‘압축된 영수증’을 확인하는 셈이다. 이에 따라 라이트 클라이언트도 파이널리티를 뒤집으려면 최소 3분의 1 지분이 슬래싱 위험을 감수해야 하는 이더리움 본래의 경제적 보안을 이어받을 수 있다.

이를 위해 EIP-8390은 합의 레이어에서 sync_aggregate, current_sync_committee, next_sync_committee를 삭제하고, 블록 처리 과정의 process_sync_aggregate와 위원회 교체 로직도 제거한다. 관련 네트워크 메시지와 Beacon API, 검증자의 싱크 위원회 서명 및 집계 업무도 함께 사라지며 실행 레이어에는 별도 변경이 없다. 하드포크 이후에는 sync_aggregate가 포함된 블록이 유효하지 않은 것으로 처리되고, 과거 서명이 다른 용도로 재사용되지 않도록 관련 서명 도메인도 폐기된다.

싱크 위원회에 배정됐던 SYNC_REWARD_WEIGHT = 2/64는 다른 보상으로 돌리지 않기 때문에 합의 레이어의 전체 발행량과 스테이킹 보상의 해당 부분은 약 3.125% 감소한다. 반면 기존 Altair 라이트 클라이언트와 관련 API는 더 이상 작동하지 않아 클라이언트와 인프라의 전환이 필요하다. 무엇보다 EIP-8390은 영지식증명을 누가 지속적으로 생성 및 배포를 진행하고, 그 비용을 어떻게 보상할지까지 규정하지 않는다. 따라서 이 제안은 싱크 위원회를 바로 없애자는 완결된 계획이라기보다는, 신뢰할 수 있는 공개 증명 인프라가 마련됐을 때 라이트 클라이언트의 보안을 작은 표본에서 전체 검증자 합의로 옮기기 위한 설계 방향으로 보는 편이 적절하다.

2.1.5 기타

• EIP-8363: Tapered Issuance Burn*
• EIP-8368: CPSB Recalibration for New Gas Limit
• EIP-8372: Normalized state gas limit

*EIP-8363에 대한 개요와 논의는 포필러스의 아래 두 이전 아티클을 참조하길 바란다:

1. 월간 EIP - 2026년 7월 (ft. 발행량 논쟁이 드러낸 이더리움 거버넌스의 한계)
2. 이더리움은 당장 발행량을 줄여야 하는가

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

이외 없음

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

2.3.1 ERC-8349: Index-Based Multi-Facet Proxy

Source: ERC-2535

디파이처럼 기능이 계속 추가되는 프로토콜은 모든 실행 로직을 하나의 스마트 컨트랙트에 담기 어렵다. ERC-2535의 Diamond 구조는 외부에서는 하나의 주소와 상태를 사용하는 컨트랙트처럼 보이게 하면서, 내부 로직은 토큰, 거래, 관리 등 여러 패싯(facet)으로 나눌 수 있도록 설계됐다; 각 패싯은 여러 함수로 구성되며, 라우터는 함수마다 부여된 4바이트 식별값인 ‘셀렉터’를 보고 해당 함수가 들어 있는 패싯을 찾는다.

다만 개발과 감사, 업그레이드는 패싯 단위로 이뤄지는 반면 라우팅 정보는 함수별로 관리되기 때문에, 기능이 늘어날수록 등록해야 할 셀렉터가 많아지고 패싯을 교체하는 작업도 복잡해진다.

ERC-8349가 제안하는 ‘Cento’ 구조에서는 호출 데이터 끝에 붙는 1바이트 인덱스가 실행할 패싯을 지정한다. 패싯 인덱스가 실행할 모듈을 고르고, 셀렉터는 그 모듈 안에서 실행할 함수를 고르는 식이다. 즉, ERC-2535에서는 패싯 하나에 함수가 20개라면 20개의 selector → facet 관계를 등록해야 하지만, Cento에서는 index → facet 관계 하나만 관리하면 되는 것이다. 인덱스는 uint8 값으로 정의돼 하나의 라우터에 최대 256개 패싯을 연결할 수 있다.

일반적인 호출 데이터는 function(args) + index 형태로 구성된다. 라우터는 마지막 바이트에서 인덱스를 읽어 등록된 패싯을 찾고, 인덱스를 제거한 나머지 데이터를 DELEGATECALL로 전달한다. 패싯은 기존 컨트랙트 호출과 동일한 function(args)를 받아 셀렉터에 해당하는 함수를 실행하므로, 기존 Solidity 코드와 ABI 인코딩 방식을 그대로 활용할 수 있다. ERC-165나 ERC-173처럼 지갑과 익스플로러가 기존 셀렉터 방식으로 호출하는 표준 인터페이스는 별도의 호환성 경로를 통해 처리된다.

업그레이드도 함수가 아닌 패싯 단위로 이뤄진다. atomicUpdate()는 여러 패싯의 설치, 교체, 제거와 지원 인터페이스 변경, 저장 데이터 마이그레이션을 한 트랜잭션에서 처리하며, 하나라도 실패하면 모든 변경을 되돌린다. 변경 내용은 AtomicUpdate 이벤트로 기록되고, getFacetEntries()나 getFacetAt(index) 같은 함수로 현재 어떤 패싯이 설치돼 있는지도 확인할 수 있다. 이에 따라 개발자는 수많은 셀렉터를 일일이 갱신할 필요가 줄어들고, 거버넌스와 감사 도구도 프로토콜의 변화를 패싯 단위로 추적할 수 있다.

다만 ERC-8349는 현재 Draft 단계이며, 패싯들이 저장 공간을 어떻게 나눠 사용할지, 누가 업그레이드를 승인할지, 어떤 거버넌스 절차를 적용할지까지 정하지는 않는다. 모든 패싯이 라우터의 저장 공간에서 실행되기 때문에 잘못된 패싯이 데이터를 훼손하거나 자금을 탈취할 수 있고, 패싯 간 저장 공간 충돌도 별도로 방지해야 한다. 특히 외부 권한으로 실행 코드를 변경할 수 있는 EIP-7702 위임 계정을 패싯으로 등록하면 라우팅 테이블을 건드리지 않고도 프로토콜 로직이 달라질 수 있어, 명세는 이를 설치 단계에서 거부하도록 권고한다.

2.3.2 기타

• 이외 없음

2.4 애플리케이션

2.4.1 ERC-8187: Token Puller

스테이블코인 결제나 구독 서비스는 대체로 사용자의 지갑에 결제 가능한 토큰이 이미 들어 있다는 전제에서 출발한다. 자산이 대출 프로토콜이나 볼트에 예치돼 있다면 사용자는 먼저 이를 인출해야 하고, 결제 서비스가 직접 처리하려면 자산이 놓인 프로토콜마다 별도의 연동 로직이 필요하다. 결국 사용자는 수익을 포기한 채 결제용 자금을 지갑에 따로 남겨두거나, 서비스마다 필요한 자금을 여러 계정에 나눠 보관해야 한다. ERC-8187은 결제 서비스가 자산이 어디에 예치돼 있는지 알 필요 없이, 사용자가 허용한 한도 내에서 필요한 금액을 바로 가져갈 수 있도록하는 공통된 방식을 제시한다.

기존 ERC-20의 approve와 transferFrom은 지갑에 직접 보관된 토큰만 가져올 수 있으며, ERC-2612의 Permit도 승인 과정을 서명으로 바꿀 뿐 자금 조달 방식까지 추상화하지는 않는다. ERC-8187은 그 사이에 IPuller 컨트랙트를 두고, 결제 사업자나 애플리케이션이 자산의 보관 위치를 알지 못해도 필요한 토큰과 금액만 요청할 수 있도록 한다. Puller는 볼트 지분을 상환하거나 대출 프로토콜에서 자산을 인출하고, 필요하다면 스왑하는 등 구현체마다 정해진 방식으로 토큰을 마련한 뒤 목적지로 전송한다. 즉 새로운 토큰 규격을 만드는 것이 아니라, 서로 다른 자산 운용 전략 위에 공통된 출금 & 결제 인터페이스를 씌우는 ERC인 것이다.

사용자는 approvePull(token, spender, limit)을 호출해 특정 지출 주체가 해당 토큰을 가져갈 수 있는 한도를 설정한다. 이후 지출 주체가 pullFrom(token, owner, to, amount)을 호출하면 Puller는 잔여 한도를 확인하고, 자금을 조달한 뒤 to 주소에 정확히 amount만큼 전송하며, 어느 단계에서든 실패하면 전체 실행을 되돌린다. maxPullable(token, owner, upTo)은 현재 전략에서 실제로 꺼낼 수 있는 금액을 조회하되 upTo에 도달하면 계산을 멈출 수 있어, 여러 자금원을 차례로 확인하는 구현의 비용을 줄인다. 이때 Puller 한도는 기존 ERC-20 allowance와 별도로 관리되므로, 사용자는 일반적인 토큰 사용 권한과 특정 자금 조달 전략을 통한 결제 권한을 구분할 수 있다.

승인은 온체인 트랜잭션뿐 아니라 token, spender, limit, nonce, deadline을 포함한 EIP-712 서명으로도 설정할 수 있으며, pullFromWithPermit은 승인과 출금을 한 트랜잭션에서 처리한다. 누군가 서명을 먼저 제출해 nonce를 소진하더라도 이미 설정된 한도로 출금을 계속 시도할 수 있게 설계해, permit 선점에 의한 서비스 거부 가능성도 줄였다. 또한 transferPullAllowance를 통해 지출 주체가 자신의 한도 일부를 다른 주소에 넘기거나 address(0)으로 보내 포기할 수 있어, 가디언이 전체 예산을 보유하고 결제 서비스별 한도를 보충하는 구조를 만들 수 있다. 스마트 계정이 IPuller를 직접 구현하면 별도의 중개 컨트랙트 없이 계정 자체의 자산 운용과 지출 제한 로직에 이를 결합할 수도 있다.

실무적으로는 사용자가 자산을 결제 직전까지 운용하면서도 구독료나 반복 결제를 자동화하고, 결제 사업자는 볼트와 대출 프로토콜을 각각 연동하지 않아도 된다는 점이 가장 크다. 다만 ERC-8187은 자금 조달 전략의 안전성을 표준화하지 않으며, 외부 프로토콜 호출 과정에서 재진입, 오라클 조작, 슬리피지, 출금 실패가 발생할 수 있고 무제한 한도나 양도 가능한 권한은 지출 주체가 탈취됐을 때 피해를 키울 수 있다. 특히 Puller를 스마트 계정에 직접 넣으면 구현 오류가 계정 전체에 영향을 미칠 수 있으므로, 모듈 격리와 엄격한 한도 설정이 중요하다. 현재 제안은 참조 구현도 감사를 받지 않았으며 ERC-1271 및 ERC-6492의 검증이 아직 완성되지 않았다는 점에서, 완성된 결제 인프라라기보다 ‘운용 중인 자산을 필요할 때 꺼내 쓴다’는 흐름을 여러 애플리케이션이 공유하기 위한 초기 표준으로 보는 편이 적절하다.

2.4.2 기타

• ERC-8354: Confidential Agent Policy Verdicts

3. 기존 EIP들의 진전

한편, 8월 한달간은 10개의 새로이 채택된 EIP들을 제외하고, 25개의 기존 EIP의 상태가 변화하였다. 해당 EIP 중, 모든 EIP들이 최종적으로 채택되기위한 다음 단계(i.e., ‘Final’, ‘Last Call’, ‘Review’, ‘Draft’ 등의 단계)로 격상되었고, ‘Withdrawn’ 상태로 격하된 EIP는 없었다.

격상된 ERC들 중 특히 주목할만한 것들은 - 하나의 양도 불가능한 소울바운드 토큰(Soulbound Token)을 여러 계정에 공동 발급하고 재활용할 수 있게 하는 표준인 ERC-5516, 잔액과 전송 금액을 숨긴 상태에서도 전송(transfer) 및 승인(approval)을 지원하는 기밀 펀저블 토큰(confidential fungible token) 인터페이스 표준인 ERC-7945, 그리고 Diamond facet이 자신의 function selector를 직접 공개하도록 해 배포와 업그레이드 관리를 단순화하는 표준인 ERC-8153 등이 있다.

ERC를 제외한 EIP들 중 특히 주목할만한 것들은 - 실행 클라이언트가 1년보다 오래된 블록 & receipt 데이터를 P2P로 제공하지 않고 로컬에서 프루닝(pruning)할 수 있게 하는 EIP-4444, 블록 제안자와 실행 페이로드(payload) 빌더를 프로토콜 수준에서 분리하는 EPBS(Enshrined Proposer-Builder Separation)를 도입하는 EIP-7732, 실행 페이로드를 재실행하지 않고 실행 증명(execution proof)을 통해 선택적으로 무상태 검증(stateless validation)을 할 수 있도록 하는 EIP-8025, 새 계정 & 스토리지 & 코드 등 상태 생성 비용을 바이트 단위로 재가격화하고 별도의 상태 가스(state gas)로 계량하는 EIP-8037, 노드가 자신이 맡은 블롭(blob) 데이터만 선택적으로 보관하고 전파하도록 “sparse blobpool”을 도입해 대역폭 부담을 줄이는 EIP-8070, 그리고 snap sync의 트리 노드(trie-node) healing을 Block-Level Access List 기반 상태 복구 방식으로 대체하는 EIP-8189 등이 있다.

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

3.1 코어 / 네트워킹 레이어

• EIP-2780: Resource-based intrinsic transaction gas
• EIP-3298: Remove storage-clear refund and refund cap
• EIP-5920: PAY opcode
• EIP-7666: EVM-ify the identity precompile
• EIP-7709: Read BLOCKHASH from Storage and Update Cost
• EIP-7773: Hardfork Meta - Glamsterdam
• EIP-7843: SLOTNUM opcode
• EIP-7975: eth/70 - partial block receipt lists
• EIP-8038: State-access gas cost update
• EIP-8045: Exclude slashed validators from proposing
• EIP-8061: Increase exit and consolidation churn
• EIP-8066: Upgrade Mascots
• EIP-8159: eth/71 - Block Access List Exchange
• EIP-8261: Gas Limit Schedule
• EIP-8282: Builder Execution Requests

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

• EIP-8136: Cell-Level Deltas for Data Column Broadcast

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

• 이외 없음

3.4 애플리케이션

• 이외 없음

4. 로빈후드 체인이 보여준 L2의 성공과 이더리움의 딜레마

Source: Robinhood

로빈후드 체인(Robinhood Chain)은 L2의 성공 기준이 달라지고 있음을 보여준다. 로빈후드는 기존 고객과 금융상품을 자체 체인으로 옮기고, 토큰화 주식을 디파이와 연결하는 동시에 시퀀서 수익까지 확보했다. 출시 직후부터 대규모 자산과 거래를 끌어들였다는 점에서 로빈후드 체인은 분명 성공적이다. 하지만 그 성공이 로빈후드와 아비트럼(Arbitrum), 그리고 이더리움에 같은 비율로 돌아가는지는 별개의 문제다.

로빈후드가 자체 L2를 선택한 이유는 비교적 명확하다. 아비트럼과 이더리움의 기술을 활용하면서도 전용 블록스페이스를 확보하고, 거래 처리와 수수료 구조, 규제 대응 방식을 자체적으로 설계할 수 있기 때문이다. 거래 데이터는 이더리움의 블롭에 게시하고 ETH를 가스 자산으로 사용하므로, 자체 L1을 처음부터 구축하는 것보다 적은 비용과 운영 부담으로 이더리움의 데이터 가용성과 완결성(finality)을 활용할 수 있다. 기업의 입장에서 L2는 탈중앙화를 위한 목적지가 아니라, 필요한 기능과 통제권을 선택해 구축할 수 있는 온체인 인프라에 가까워지고 있다.

Source: L2BEAT

따라서 로빈후드 체인을 이더리움 L2라고 부르는 것 자체가 기술적으로 틀렸다고 보기는 어렵다. 다만 L2라는 분류와 이더리움 수준의 보안을 물려받는다는 주장은 구분해야 한다. Stage는 L2 여부를 판정하는 등급이라기보다, 운영자에 대한 신뢰를 얼마나 코드와 사용자 권리로 대체했는지를 보여주는 성숙도 기준이다. 현재 L2BEAT는 외부에서 상태를 검증하고 이의를 제기할 수 있는 주체가 충분하지 않다는 이유로 로빈후드 체인을 Stage 0~2의 롤업이 아닌 ‘Other’로 분류하고 있다.

실제로 로빈후드 체인에서는 잘못된 상태에 이의를 제기할 수 있는 검증자가 오프체인랩스(Offchain Labs)와 알케미(Alchemy) 두 곳으로 제한돼 있다. 중앙화된 시퀀서는 특정 거래가 이더리움을 통해 강제로 포함되더라도 이를 무효화할 수 있으며, 8인 보안위원회는 긴급 상황에서 7명의 서명만으로 대기시간 없이 시스템을 변경할 수 있다. 이더리움은 로빈후드 체인이 게시한 데이터를 공개하고 거래 이력을 재구성할 수 있게 해주지만, 운영자의 검열이나 악의적인 업그레이드까지 반드시 막아주지는 않는다. 로빈후드 체인은 이더리움에 데이터를 맡기고 있지만, 최종적인 통제권까지 넘긴 것은 아니다.

이 구조에서 ‘자기수탁(Self-custody)’ 역시 제한적으로 이해할 필요가 있다. 사용자는 개인키를 직접 보유하지만, 운영자의 도움 없이 언제나 거래하고 자산을 인출할 수 있다는 강한 의미의 자기주권까지 보장받지는 않는다. 하지만 금융회사는 법원 명령과 제재, 해킹 사고에 대응해 거래나 자산을 동결할 수 있어야 하므로, 이러한 통제권은 로빈후드에 없애야 할 결함이 아니라 책임을 이행하기 위한 안전장치일 수 있다. 즉, 기업형 L2가 Stage 2로 나아가지 않는 이유는 기술이 부족해서라기보다, 신뢰 최소화와 규제 대상 금융회사의 운영 방식이 구조적으로 충돌하기 때문일 가능성이 크다.

Source: L2BEAT

경제적 관계에서도 같은 간극이 나타난다. 로빈후드 체인은 4월 말 이후 6억 건이 넘는 거래를 처리했지만, 같은 기간 이더리움에 지불한 온체인 비용은 약 4만 9,000달러, 하루 평균 약 370달러였다. 별도의 온체인 분석에 따르면 9월 3일에는 로빈후드 체인이 약 450만 달러의 수수료를 거두면서 이더리움에는 약 400달러를 지불했다. 블롭을 저렴하게 공급하는 것은 이더리움의 확장 로드맵이 의도한 결과이지만, L2의 거래량과 수익을 그대로 이더리움의 가치로 계산하기 어려운 이유도 여기에 있다.

최근의 가스비 급등은 전용 L2가 가진 명암을 더욱 선명하게 보여준다. 소수의 트레이딩 주소가 추가 수요의 대부분을 만들자 로빈후드 체인의 가스 가격은 11일 만에 약 25배 상승했고, 우선 수수료가 없는 구조 때문에 일반 사용자도 함께 높아진 기본 수수료를 부담했다. 기업은 전용 체인을 통해 처리 용량과 수수료 정책을 직접 조정할 수 있지만, 그 결정권과 수익 역시 운영자에게 집중된다. 결국 L2는 이더리움의 혼잡을 해소하는 동시에, 각 운영자가 소유한 새로운 병목과 수수료 시장을 만들어낸다.

로빈후드 체인은 앞으로의 L2 시장이 하나의 방향으로 수렴하지 않을 것임을 시사한다. 일부 롤업은 무허가 검증과 강제 출금, 제한된 업그레이드 권한을 갖춘 신뢰 최소화 네트워크를 지향하겠지만, 더 많은 기업형 L2는 규제 준수와 성능, 수익 확보를 우선하는 온체인 서비스 플랫폼으로 남을 가능성이 크다. 롤업 스택이 표준화되면서 체인 출시는 연구개발의 결과라기보다 클라우드 인프라를 도입하는 것과 비슷한 사업적 선택이 되고 있다. 이 과정에서 서로 다른 보안 모델이 모두 ‘Ethereum L2’라는 이름으로 묶인다면, 사용자는 기업형 체인의 통제 가능성을 이더리움이 보장하는 보안으로 오인할 수 있다.

더 큰 문제는 이러한 흐름이 계속될 경우 이더리움의 역할이 값싼 데이터 공급자로 축소될 수 있다는 점이다. 사용자는 기업형 L2에, 수수료는 운영사에, 기술 수익은 롤업 스택에 남고 이더리움에는 소액의 블롭 수수료만 돌아오는 구조라면, 생태계의 외연이 넓어져도 이더리움의 경제적 가치는 희석될 수 있다. ETH가 가스와 담보로 사용되고 기업들이 이더리움의 브랜드를 선택한다는 간접 효과도 있지만, 이는 운영자가 다른 DA 레이어나 가스 토큰으로 전환하면 약해질 수 있다. 이더리움이 L2의 성장을 자신의 성장으로 연결하려면, 단순한 데이터 게시보다 강한 구조적 의존 관계가 필요하다.

그렇다고 모든 활동을 다시 L1으로 가져오거나 기업형 L2에 Stage 2를 강요하는 것도 현실적인 해법은 아니다. 이더리움이 집중해야 할 것은 서로 신뢰하지 않는 기업과 프로토콜, 사용자가 공동으로 자산을 발행하고 거래를 마무리할 수 있는 중립적인 시장이 되는 것이다. 이를 위해 L1 처리 용량과 계정 UX를 개선하는 동시에, L2 간 자산과 유동성이 이더리움을 중심으로 연결되고 사용자의 출금 권리와 최종 정산이 운영자의 재량에서 분리되도록 해야 한다. 검열 저항성과 프라이버시, 무허가 검증도 추상적인 가치에 머무르지 않고 실제 사용자가 체감하는 제품상의 이점으로 만들어야 한다.

결국 로빈후드 체인의 성공은 이더리움에 기회인 동시에 경고다. 대형 금융회사가 이더리움 기술을 활용해 기존 자산과 사용자를 온체인으로 끌어들였다는 점에서는 분명 의미가 있지만, 거래와 수익이 기업형 L2 안에 머물고 이더리움과의 연결이 선택 사항에 그친다면 그 성장은 이더리움의 가치로 축적되지 않는다. 앞으로 중요한 것은 L2의 숫자를 늘리는 일이 아니라, 어느 한 기업도 신뢰하고 싶지 않은 사용자와 서로를 신뢰할 수 없는 기업들이 이더리움을 공동의 기반으로 선택할 이유를 만드는 것이다. 이더리움은 누구나 떠날 수 있는 네트워크여야 하지만, 동시에 떠날수록 포기해야 하는 가치가 분명한 네트워크여야 한다.