본문으로 건너뛰기

글램스테르담 (Glamsterdam) 지연 : ePBS 도입 연기로 엔지니어링 현실에 부딪힌 이더리움 MEV 개혁

· 약 11 분
Dora Noda
Dora Noda
Software Engineer

이더리움의 가속화된 2026-2027 포크 주기에서 처음으로 로드맵에 차질이 생겼습니다. 2026년 4월 중순, 핵심 개발자들은 클라이언트 팀들이 몇 주 동안 속삭여 온 사실을 공개적으로 인정했습니다. 글램스테르담 (Glamsterdam) 하드 포크에서 가장 야심 찬 부분인 프로포저-빌더 분리 내재화 (Enshrined Proposer-Builder Separation, ePBS)가 "예상보다 까다롭다"는 것이며, 원래 계획했던 5~6월 메인넷 일정은 거의 확실히 달성 불가능해졌습니다. 이 지연으로 인해 글램스테르담은 2026년 3분기 또는 4분기로 밀려나게 되었고, 이미 예정된 헤고타 (Hegota) 포크와의 간격이 좁아졌습니다. 이로 인해 이더리움이 이미 해결했다고 생각했던 질문이 다시 제기되었습니다. 5개의 클라이언트를 가진 베이스 레이어가 과연 포스트 펙트라 (post-Pectra) L2 경제가 요구하는 속도에 맞춰 업그레이드할 수 있을까요?

이 질문에 대한 답변은 이더리움 자체의 생태계를 훨씬 넘어서는 중요성을 가집니다. ePBS가 데브넷 (devnet)에 머무는 매주, 현재의 플래시봇 릴레이 (Flashbots-relay) 과점 체제는 연간 수백억 달러에 달하는 MEV 흐름을 계속 중개하게 됩니다. 또한 L2는 포크를 통해 완화될 예정이었던 공급 곡선에 맞춰 블롭 (blobs) 가격을 계속 책정하게 되며, 2025년 9월 알펜글로우 (Alpenglow) 합의 개편에 대해 98.27%의 검증인 승인을 확보한 솔라나 (Solana)는 눈에 띄게 빠른 모놀리식 (monolithic) 업그레이드 속도로 격차를 더 벌리게 됩니다. 글램스테르담은 단순한 하드 포크가 아니었습니다. 그것은 "빠른 L1 (Fast L1)" 이론에 대한 이더리움의 답변이었습니다. 그리고 그 답변은 이제 늦어지고 있습니다.

글램스테르담을 정의하는 두 가지 EIP​

글램스테르담 (Glamsterdam) — 합의 레이어 코드명인 글로아스 (Gloas)와 실행 레이어 코드명인 암스테르담 (Amsterdam, Devcon 개최 도시 전통에 따름)의 합성어 — 은 이더리움의 블록 생성 방식을 재구성하는 두 가지 핵심 EIP를 중심으로 합니다.

EIP-7732 (ePBS) 는 프로토콜 수준에서 합의 블록과 실행 블록을 분리합니다. 현재 MEV-Boost를 실행하는 검증인들은 중앙 집중식 릴레이를 통해 프로토콜 외부의 빌더 시장에 블록 구성을 위임합니다. 플래시봇이 2024년 12월에 모든 빌더와 주문 흐름을 빌더넷 (BuilderNet)으로 마이그레이션한 것 자체가 릴레이 아키텍처가 집중화 위험을 초래한다는 점을 인정한 것이었습니다. ePBS는 이 분리를 내재화합니다. 즉, 제안자 (proposer)와 빌더 (builder)가 릴레이 없이 직접 상호작용하는 일급 프로토콜 참여자가 됩니다.

EIP-7928 (블록 수준 액세스 리스트) 는 블록이 읽고 쓰는 계정 및 스토리지 슬롯 등 '발자국'을 미리 선언하도록 합니다. 이를 통해 클라이언트는 실행과 검증을 병렬화할 수 있어 블록이 전파되는 데 걸리는 시간을 단축할 수 있습니다. ePBS와 결합하여, 이 두 가지는 실질적인 블록 지연 시간을 약 50% 줄이는 것을 목표로 합니다.

이론적으로 이들은 서로를 깔끔하게 보완합니다. 하지만 구현 과정에서 이들은 펙트라 (Pectra)에서 이미 배포된 EIP-7251 MaxEB 검증인 통합을 포함하여 포스트 펙트라 스택의 다른 모든 요소와 상호작용하고 있으며, 이는 원래 사양에서 충분히 예상하지 못한 방식으로 나타나고 있습니다.

실제로 지연된 부분​

2026년 4월 16일 전체 핵심 개발자 합의 회의 (ACDC #177)는 엔지니어링의 현실을 분명히 보여주었습니다. 이번 달까지 테스트는 두 개의 개별 네트워크로 나뉘어 진행되었습니다. 프로포저-빌더 분리를 위한 epbs-devnet과 액세스 리스트를 위한 bals-devnet입니다. 이들을 병합한 "일반화된 데브넷 (generalized devnet)" — 모든 글램스테르담 구성 요소가 공존하는 첫 번째 환경 — 은 4월 상호 운용성 기간 동안 라이트하우스 (Lighthouse)와 몇몇 다른 합의 클라이언트가 안정적인 빌드를 생성한 후에야 승인되었습니다.

"ePBS Devnet Zero는 성능보다는 상호 운용성에 관한 것입니다"라고 한 클라이언트 엔지니어는 회의 요약에서 언급했습니다. 이는 5개의 합의 클라이언트와 5개의 실행 클라이언트가 각각 독립적으로 사양을 해석할 때 무엇이 망가지는지 여전히 파악 중이라는 뜻입니다. 초기 테스트에서는 대부분 빈 블록이 생성되고 있는데, 이는 구조적 결함이라기보다는 정상적인 경로 (happy path)가 아직 다듬어지는 중이며 공격적인 시나리오 (adversarial path)는 고려조차 못 하고 있다는 신호입니다.

일정 지연의 결과는 연쇄적으로 작용합니다.

  • Devnet Zero는 합의 측의 Lighthouse, Prysm, Teku, Nimbus, Lodestar와 실행 측의 Geth, Nethermind, Besu, Erigon, Reth 전체에서 안정화되어야 합니다.
  • Devnet One 및 Two에서는 ePBS, BAL, 가스 가격 재책정, 그리고 검토 중인 25개 이상의 비핵심 EIP 간의 상호작용 버그를 찾아내야 합니다.
  • 공개 테스트넷 (Holesky 후속, Sepolia)은 메인넷 목표 날짜를 신뢰성 있게 설정하기 전에 최소 6 ~ 8주의 섀도우 포크 (shadow-fork) 활동이 필요합니다.
  • 클라이언트 릴리스는 메인넷의 포크 선택 이슈가 활성성 (liveness) 사고로 번지지 않도록 충분한 여유 시간을 두고 스테이커들에게 배포 및 감사되어야 합니다.

각 단계는 며칠이 아니라 몇 주 단위로 측정됩니다. 5 ~ 6월 출시를 위해서는 Devnet Zero가 2월에 안정화되었어야 했지만 그러지 못했습니다. 6 ~ 7월 출시를 위해서는 3월에 안정화되었어야 했지만 그러지 못했습니다. 4월 시점에서 산술적으로 일정은 맞지 않으며, 이에 따라 핵심 포크가 2026년 하반기로 밀려나고 있다는 사실을 조용히 인정하게 된 것입니다.

클라이언트 다양성의 역설​

이더리움의 5개 클라이언트 실행 다양성은 아마도 네트워크에서 가장 가치 있고 신뢰할 수 있는 중립적 속성일 것입니다. 단일 클라이언트의 버그가 네트워크 전체를 중단시킬 수 없기 때문입니다. 하지만 그 다양성이 바로 글램스테르담이 어려운 이유이기도 합니다.

모든 구현 팀은 ePBS를 독립적으로 구축, 테스트 및 안정화해야 합니다. 각 팀은 서로 다른 예외 상황 (edge case)을 발견합니다. 4월 ACDC 회의록에는 여러 클라이언트에 걸친 "보류 중인 풀 리퀘스트 (pull requests)"가 설명되어 있으며, 합의 사양 (consensus-specs) 변경 사항이 해결될 때까지 ePBS Devnet Two가 완전히 차단될 수 있다고 언급되어 있습니다. 이것이 바로 단일 구현 체인에서는 지불하지 않는 조율 비용 (coordination tax)입니다.

솔라나의 행보와 비교해 보십시오. 100 ~ 150ms의 결정적 최종성 (deterministic finality)을 목표로 하는 솔라나의 합의 대체안인 알펜글로우 (Alpenglow)는 2025년 9월 네트워크 역사상 가장 강력한 지지 중 하나인 98.27%의 검증인 찬성으로 투표를 통과했습니다. 출시 계획은 간단합니다. 안자 (Anza)의 아가베 (Agave) 클라이언트가 2026년 3분기에 업그레이드를 출시하고, 점프 크립토 (Jump Crypto)의 두 번째 구현체인 파이어댄서 (Firedancer)가 그 뒤를 잇습니다. 솔라나는 올해 초 파이어댄서가 메인넷 스테이크의 20%를 넘기기 전까지 사실상 하나의 프로덕션 클라이언트만 있었기 때문에, 조율 범위가 이더리움의 극히 일부에 불과합니다.

이것은 중립적인 관찰이 아닙니다. 모놀리식 체인은 더 빨리 배포합니다. 멀티 클라이언트 체인은 더 안전하게 배포합니다. 글램스테르담의 지연은 이더리움의 아키텍처 선택에 따른 대가이며, 머지 (Merge) 이후 처음으로 시장은 그 대가가 여전히 지불할 가치가 있는지 가늠하고 있습니다.

지연이 L2와 MEV에 의미하는 바​

2025년 펙트라(Pectra) 포크가 예정대로 배포되었습니다. 푸사카(Fusaka)는 그 직후 PeerDAS를 추가하고 블롭(blob) 용량을 확장했습니다. L2 팀들은 2분기에 출시될 글램스테르담(Glamsterdam)을 중심으로 2026년 용량 계획을 세웠으며, 급증하는 롤업 수요를 충족하기 위해 추가적인 블롭 확장과 MEV 재분배가 이루어질 것으로 기대했습니다.

이제 그 계획들은 수정되어야 합니다.

블롭 가격 책정. 글램스테르담은 블록당 블롭 수를 잠재적으로 72개 이상으로 늘려 옵티미스틱 및 ZK 롤업에 훨씬 더 저렴한 데이터 가용성을 제공할 것으로 예상되었습니다. 34분기로의 일정 지연은 24개월 동안 블롭 공급이 타이트해짐을 의미하며, 이는 이미 수수료 레인이 포화 상태인 롤업들에게 가장 큰 영향을 미칩니다.

MEV 재분배. 오늘날의 MEV-부스트(MEV-boost) 아키텍처는 대형 빌더들에게 불균형적인 보상을 제공합니다. 주문 흐름 애그리게이션(orderflow aggregation)에 대한 초선형적 수익은 빌더가 일단 선두를 점하면 경제 논리가 독점으로 치닫게 함을 의미합니다. ePBS가 MEV를 완전히 제거하지는 않지만, 조율의 병목 지점인 릴레이를 제거하여 이론적으로 현재 추출되는 수익의 일부를 제안자에게, 나아가 스테이커에게 재분배해야 합니다. 지연되는 매달은 기존의 MEV 역학이 지속되는 한 달이 됩니다.

L2 경쟁. 베이스(Base)는 이미 2초의 블록 시간을 달성했습니다. 아비트럼(Arbitrum)과 옵티미즘(Optimism)은 독립적인 속도로 자체 시퀀서 및 DA 개선 사항을 배포하고 있습니다. L1 병목 현상이 길어질수록 L2 로드맵은 통합된 L1 업그레이드에서 더 멀어지며, '롤업 중심 로드맵'은 우연히 동일한 베이스 레이어에서 정산되는 N개의 개별 롤업 로드맵으로 변모하게 됩니다.

FOCIL 문제와 헤고타 스퀴즈 (Hegota Squeeze)​

지난 4월 ACDC(합의 개발자 회의)의 가장 중대한 결정 중 하나는 포크 선택 포함 리스트(FOCIL)를 글램스테르담에서 제외하여 2026년 하반기 합의 레이어의 핵심 기능인 헤고타(Hegota)로 옮긴 것이었습니다.

FOCIL은 이더리움의 검열 저항성에 대한 해답으로, 제안자 위원회가 집합적으로 트랜잭션 포함을 강제할 수 있게 하여 단일 빌더가 페이로드(예: OFAC 제재 주소)를 체계적으로 배제할 수 없도록 하는 메커니즘입니다. 베이스(Base) 엔지니어링 팀은 FOCIL을 ePBS와 함께 묶을 경우 글램스테르담 출시가 2026년을 완전히 넘길 수 있다고 공개적으로 경고한 바 있습니다. 이를 분리함으로써 글램스테르담의 일정 부담은 덜었지만, 글램스테르담의 메인넷 활성화와 헤고타 활성화 사이의 간격이 압축되는 결과를 초래했습니다.

글램스테르담이 2026년 4분기에 출시되고 헤고타가 4분기 후반을 목표로 한다면, 그 간격은 6~8주에 불과할 수 있습니다. 이는 검증자, 블록 빌더, 스테이킹 제공자 및 L2 팀이 다음 프로토콜 변경이 오기 전까지 하나의 변경 사항을 흡수하기에는 매우 짧은 시간입니다. 헤고타(Hegota) 로드맵에는 상당한 상태 팽창(state-bloat) 작업도 포함되어 있습니다. 초기 논의는 노드 하드웨어 요구 사양을 낮추지만 광범위한 테스트가 필요한 버클 트리(Verkle Trees)에 집중되었습니다.

이더리움이 현재 조용히 준비하고 있는 시나리오는 다음과 같습니다. 솔라나(Solana)가 단일 조정 릴리스로 배포하는 수준의 테스트 매트릭스를 요구하는 두 개의 대규모 포크가 한 분기 내에 연달아 출시되는 상황입니다.

이것이 아직 위기가 아닌 이유​

글램스테르담의 지연을 실존적 위기로 해석하는 것은 실수입니다. 이더리움의 포크 프로세스는 설계된 대로 정확하게 작동하고 있습니다. ePBS가 지연되는 이유는 조율이 실패했기 때문이 아니라, 메인넷에 도달하기 전에 사양의 모호성과 구현상의 엣지 케이스를 발견했기 때문입니다. 일정을 맞추기 위해 배포했다가 4,000억 달러 이상의 자산이 걸린 상황에서 실시간 포크 선택 버그를 해결해야 하는 상황보다는 훨씬 낫습니다.

더 깊은 질문은 포크당 복잡성이 증가함에 따라 이더리움의 현재 케이던스(cadence)가 지속 가능한가 하는 점입니다. 글램스테르담은 단순히 두 개의 EIP가 아닙니다. 두 개의 핵심 기능과 25개 이상의 세부 변경 사항이 포함되어 있으며, 각각은 이미 MaxEB 통합, PeerDAS 기반 블롭, 성숙한 L2 생태계를 갖춘 펙트라 이후의 검증자 세트와 상호작용합니다. 새로운 포크가 추가될 때마다 테스트 매트릭스는 더욱 넓어집니다.

글램스테르담 자체를 분할하여 3분기에 BALs를 출시하고 2027년 1분기에 ePBS를 출시하자는 제안도 나왔으나 지금까지는 거부되었습니다. 이에 대한 반대 논거는 설득력이 있습니다. ePBS 없는 BALs는 병렬 실행 이득이 현재의 빌더 아키텍처에 의해 병목 현상을 겪기 때문에 가치가 미미하다는 것입니다. 이 기능들은 진정으로 상호 보완적이며, 이를 분리하는 것은 업그레이드의 일관성을 희생하여 일정을 앞당기는 것에 불과합니다.

향후 90일 동안 지켜봐야 할 것​

개발자, 스테이커, 그리고 2026년 하반기 L2 블록 공간 가격을 책정하는 모든 이들에게 다음 세 가지 신호가 중요합니다:

  1. 데브넷 제로(Devnet Zero) 안정성. 6월 초까지 일반화된 데브넷이 중대한 사고 없이 30일 이상 운영된다면 2026년 3분기 목표가 신뢰를 얻을 것입니다. 그렇지 않다면 4분기가 마지노선이 될 것입니다.
  2. 공개 테스트넷 활성화. 홀스키(Holesky)의 후계자와 세폴리아(Sepolia)는 메인넷보다 최소 8주 전에 포크되어야 합니다. 테스트넷 포크 날짜가 정해지지 않았다는 것은 메인넷 포크 날짜도 정해지지 않았음을 의미합니다.
  3. 헤고타 EIP 선정. 2026년 2월 헤고타의 합의 레이어 핵심 기능은 FOCIL로 정해졌지만, 실행 레이어의 핵심 기능은 여전히 논의 중입니다. 무엇이 선택되든 두 포크가 얼마나 긴밀하게 순차적으로 진행될 수 있는지를 더욱 제약하게 될 것입니다.

이더리움의 2026~2027년 로드맵은 언제나 야심 찼습니다. 글램스테르담의 지연은 야심 찬 계획이 곧 정시 출시를 의미하지 않는다는 첫 번째 구체적인 신호입니다. 어려운 일을 신중하게 수행하는 것에 신뢰를 두는 네트워크에 있어, 측정된 지연은 실패가 아닙니다. 그것은 이더리움의 특징(Feature)입니다.

BlockEden.xyz는 펙트라, 푸사카 및 글램스테르담 포크 규칙을 스테이징하는 모든 테스트넷에서 엔터프라이즈급 이더리움 인프라를 운영합니다. 변화하는 업그레이드 목표에 맞춰 개발 중이며 메인넷, 테스트넷, 데브넷을 병렬로 추적하는 노드가 필요하다면 당사의 이더리움 API 서비스 살펴보기를 확인하세요. 사양 변경의 잘못된 지점에서 포크된 상태를 감당할 수 없는 팀들을 위해 설계된 인프라입니다.

출처​

Share on Twitter