1. '롤업 중심 이더리움' 두번째 단계의 시작

Dencun 업그레이드의 EIP-4844(Proto-Danksharding) 도입 이후 레이어2 트랜잭션 수수료는 큰 폭으로 낮아졌다. 현재 이더리움의 관심사는 L2가 제출하는 데이터 용량의 한계(Data Availability)를 넓히고, 레이어1 실행 엔진(EVM)의 연산, I/O 병목을 해결하며, 프로토콜 차원의 검열 저항성과 계정 UX를 정비해야 하는 시점을 지나고 있다.

이더리움은 Fusaka를 시작으로 Glamsterdam, Hegota로 이어지는 하드포크 로드맵을 통해 L1 코어와 L2 확장성의 구조적 개편을 추진하고 있다. 각 하드포크에 포함되는 주요 EIP 및 핵심 메커니즘의 진행 상태는 다음과 같이 정리할 수 있다.

이더리움 핵심 EIP 진행 현황

업그레이드	주요 EIP 및 메커니즘	역할 및 개요	진행 상태
Fusaka - 2025.12.3 완료	EIP-7594 (PeerDAS)	p2p 서브넷 기반 데이터 가용성 확장	포함
	EIP-7892 (BPO)	BPO 기반 노드 Execution 및 I/O 최적화 규격	포함
	EIP-7825	트랜잭션당 가스 소비 한도 제한	포함
Glamsterdam - 2026 4Q 예정	EIP-7732 (ePBS)	프로토콜 내장형 Proposer-Builder 분리 및 Relay 제거	논의 중
	EIP-7928 (BALs)	EVM 병렬 처리 및 스토리지 프리페칭용 Access List	논의 중
	EIP-8037	State Creation 수수료 세분화 및 다차원 가스 모델	논의 중
Hegota - 2027 예정	EIP-7805 (FOCIL)	다수 검증자 위원회 기반 포크 초이스 연동 Inclusion List	논의 중
	EIP-8141 (Frame Tx)	검증·실행 프레임 분리 기반 네이티브 계정 추상화	논의 중

2. Fusaka

"L2 롤업 체인들을 위한 Blob 용량 확장과 L1 연산 안전성 확보"

① PeerDAS: p2p 서브넷 기반의 Blob 확장

EIP-4844 체제에서는 모든 검증 노드가 blob 데이터 전체를 직접 다운로드해야 하므로, 네트워크 대역폭 한계로 인해 blob 생성량을 무제한 늘리기 어려웠다.

PeerDAS(Peer Data Availability Sampling) 적용 이후로는 노드가 전체 데이터 대신 p2p 서브넷을 통해 '분할된 조각'만 분담 수신하고, 무작위 샘플링을 통해 전체 데이터의 가용성을 확인한다. 이를 통해 개별 노드의 대역폭 부담을 늘리지 않고도 Blob 수용량을 확장할 수 있다.

1D 리드-솔로몬(Reed-Solomon) 지우기 기법: Details
p2p 서브넷 활용
- p2p 서브넷은 2020년 이더리움 2.0(지분증명) 출범 때부터 핵심 인프라로 존재하던 기술이다. 이더리움의 모든 검증자 노드가 전 세계의 모든 메시지를 다 받아보면 네트워크 전파 병목이 발생하기 때문에, 이를 방지하기 위해 데이터를 관심사별로 분할 전파한다.
- PeerDAS에서는 이 구조를 업데이트하여 blob 데이터 전파 대역폭을 분산한다. 한 노드가 모든 Blob의 전체 조각을 직접 다운로드할 필요 없이, 자신이 속한 p2p 서브넷 채널의 데이터 조각(Column)만 다운로드 및 검증한다. 노드가 받지 않은 다른 조각은 다른 서브넷에 속한 노드에게 아주 적은 양의 샘플을 요청해 검증한다.

EIP-7594: PeerDAS - Peer Data Availability Sampling

② BPO (Block Parameter Only)

L2 데이터 가용성에 대한 수요가 빠르게 증가하면서 Blob 용량이 지속적으로 한계에 다다르고 있다. EIP-7892에서는 클라이언트 소프트웨어 코드를 수정하지 않고도 Blob 관련 프로토콜 파라미터 설정값만을 조정하는 별도의 업그레이드가 진행되었다.

Blob Target (target): block 당 목표 blob 개수 (평균적으로 유지하려는 사용량. target보다 많이 사용하는 경우 수수료를 더 받아서 수요를 억제)
Blob Limit (max): block 당 최대 blob 개수 제한
Blob Base Fee Update Fraction (baseFeeUpdateFraction): 블록당 blob 가스 가격이 어떻게 조정되는지 결정

max를 올리는 것은 순간 처리 용량을 늘리는 것, target을 올리는 것은 수수료가 상승하기 시작하는 사용량 기준을 높여 더 많은 평균 사용을 수용하는 것을 의미한다.

EIP-7892: Blob Parameter Only Hardforks

③ Transaction Gas Limit Cap

단일 트랜잭션이 소비할 수 있는 최대 가스 한도를 약 16,777,216 (2^24) gas로 제한한다.
하나의 트랜잭션이 블록 전체 연산 리소스를 독점해 발생하는 DoS 공격을 방지하고, 블록 내 트랜잭션 간 형평성 있게 가스를 할당하며, 극단적으로 긴 블록 검증 시간을 방지하여 노드 간 동기화를 원활하게 하기 위함이다.

가스 상한에서 특히 주의할 점은 실제로 소비한 가스가 아니라 거래에 지정한 gasLimit도 제한한다는 것이다. 예를 들어 실제 실행은 1,000,000 gas만 필요하더라도, 여유 있게 gasLimit = 20,000,000을 지정하면 거래 자체가 거부된다.

EIP-7825: Transaction Gas Limit Cap

3. Glamsterdam

외부 미들웨어에 의존하던 블록 생성 체계를 L1 프로토콜로 내재화하며, EVM 연산 구조를 병렬 처리에 맞춰 개편

① ePBS (Enshrined Proposer-Builder Seperation)

기존의 PBS(Proposer-Builder Seperation) 구조는 Validator의 역할을 Proposer와 Builder로 분리하여 프로토콜을 운영하는 매커니즘을 MEV-Boost라는 오프체인 미들웨어에 의존해왔다.

MEV-Boost 미들웨어
- 먼저 PBS 및 ePBS에서의 블록 사이클을 단순화하면 아래와 같다.
  Builder는 블록을 생성하고 입찰 -> 블록 유효성 검증 (검증 주체는 PBS, ePBS에 따라 다름) -> Proposer는 가장 높은 금액을 제시한 블록 선택
- Builder가 유효하지 않은 블록을 보내거나, Proposer가 완성된 블록 내용을 미리 보고 탈취하는 등 여러 우려들이 배경에 있었다.
- Proposer와 Builder 사이에 제3자 'Relay'라는 중개자를 두고 신뢰하는 방식이다.
- Relay는 블록의 유효성을 검사하고, Proposer에게는 블록의 헤더와 입찰가만 보여주어 탈취를 방지한다. Proposer가 선택한 블록을 네트워크로 전파하는 역할까지 담당한다.

Relay는 프로토콜 외부의 중앙화된 서버 형태로 운영되었기 때문에, 중앙화되거나 장애가 발생할 경우 블록 생성이 차단될 수 있는 리스크가 있다.

EIP-7732 ePBS(Enshrined PBS)는 Relay의 존재를 없애고, Proposer와 Builder의 역할 분리를 이더리움 합의 레이어 내부 코드로 '내장(Enshrine)'한다. Relay 없이도 Trustless 환경에서 Proposer와 Builder 사이에 블록 헤더와 payload를 교환할 수 있으며, 2단계 payload 검증 방식을 통해 Builder의 블록 제출과 Proposer의 수수료 수령을 프로토콜 차원에서 보장한다.

EIP-7732: Enshrined Proposer-Builder Separation

② BALs: EVM 병렬 처리의 기반

기존 EVM은 트랜잭션을 하나씩 순차적으로 실행해서 상태 변화를 적용했다. 트랜잭션을 실행하기 전에는 어떤 스토리지 슬롯에 접근해서 변경이 생길지 알 수 없었기 때문에, 노드의 CPU 코어가 여러 개여도 하나의 블록을 처리할 때는 멀티코어를 활용한 병렬 처리가 불가능했다.

BALs(Block Access Lists / EIP-7928)는 블록 빌더가 블록을 조립할 때, 블록 단위로 접근 대상(계정, 스토리지 슬롯 등)을 요약 정리하여 블록 헤더, 바디에 포함시키는 방식이다. 검증 노드는 블록을 전달받았을 때 BALs를 참조하여 상호 간에 스토리지 충돌이 없는 트랜잭션 그룹을 판별하고, 이를 CPU의 여러 코어에 분배하여 병렬로 실행할 수 있다.

            [ BALs (블록 액세스 리스트) 분석 ]
                           │

   ┌───────────────────────┼───────────────────────┐
   ▼                       ▼                       ▼

  [ Group A ]             [ Group B ]             [ Group C ]
  Tx 1, Tx 3 (A계정 접근)    Tx 2 (B계정 접근)       Tx 4, Tx 5 (C계정 접근)
  │                       │                       │
  Core 1 실행             Core 2 실행             Core 3 실행
  └───────────────────────┼───────────────────────┘
                          ▼
                    [ 상태 최종 적용 ]

EIP-7928: Block Access Lists

③ Gas 모델 개편: 실행/상태 리소스 분리

Glamsterdam에서는 가스 수수료 메커니즘도 개편된다. Fusaka의 EIP-7825가 단일 트랜잭션의 Execution 연산 상한을 제한하는 유지를 맡는다면, Glamsterdam의 EIP-8037은 EVM 실행 연산과 상태 생성 비용을 다차원적으로 분리한다.

신규 계정 생성이나 스토리지 슬롯 할당처럼 노드의 디스크 용량을 영구적으로 차지하는 작업에 상대적으로 높은 가스 비용을 부과하여 State Bloat(상태 용량 팽창)을 억제하고, 단순 연산 작업과의 수수료 구조를 분리한다.

EIP-8037: State Creation Gas Restructuring

4. Hegota

ePBS 도입 이후 강화된 Builder의 권력을 견제하고, 트랜잭션 승인 체계를 개선

① FOCIL (Fork-choice enforced Inclusion Lists)

ePBS 체제에서는 고성능 Builder가 특정 트랜잭션을 의도적으로 배제하거나 검열할 가능성이 존재한다. 이를 방지하기 위해 FOCIL이라는 정책이 도입된다.

FOCIL은 단일 Proposer가 아닌 무작위로 선출된 여러 검증자 committee가 각자 메모리풀을 관찰하여 **반드시 포함되어야 할 트랜잭션 목록(Inclusion List)**을 작성한다.

FOCIL에서 블록의 유효성 검증은 Attester(증명자)의 투표 동작과 연동된다. Attester 노드는 자신이 확보한 Inclusion List를 기준으로 빌더가 제안한 블록이 요구 조건을 충족했는지 검증한다. 만약 빌더가 해당 리스트의 트랜잭션을 정당한 사유 없이 배제했다면, Attester는 해당 블록에 증명 투표를 하지 않는다. 투표를 받지 못한 블록은 포크 초이스 규칙에 의해 자연스럽게 체인의 canonical block으로 선택되지 못하고 탈락하는 구조다.

EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL)

② Frame Transactions: 가스 지불 승인을 포함한 네이티브 계정 추상화

이더리움의 계정 추상화(AA)는 ERC-4337(스마트 컨트랙트 지갑 기반 오프체인 인프라)을 거쳐, Pectra 업그레이드의 EIP-7702(EOA에 일시적으로 컨트랙트 코드를 부여하는 규격)로 발전해 왔다. Hegota의 Frame Transactions는 이 흐름을 L1 네이티브 트랜잭션 프레임워크 수준으로 통합하는 규격이다.

EIP-8141은 트랜잭션 구조를 Validation Frame(검증 프레임)과 Execution Frame(실행 프레임)으로 분리한다.


[ Frame Transaction (EIP-8141) 구조 ]
┌────────────────────────────────────────────────────────┐
│  1. Validation Frame                                   │
│     - 서명 검증 (P-256 / 패스키 등 커스텀 로직)               │
│     - 가스 지불 승인 (Paymaster 로직 또는 대체 토큰 결제)       │
├────────────────────────────────────────────────────────┤
│  2. Execution Frame                                    │
│     - 실제 DApp 호출 및 상태 변경 연산                       │
└────────────────────────────────────────────────────────┘

Validation Frame
- 트랜잭션이 블록에 들어가기 전, 해당 계정에 정의된 커스텀 로직(ex. "P-256 패스키 서명이 올바른가?", "하루 이체 한도를 초과하지 않았는가?")을 먼저 실행한다.
- 이 검증 프레임이 True를 반환해야만 가스비가 결제되고 다음 단계로 넘어간다.
Execution Frame
- 승인이 완료되면 실제로 토큰을 송금하거나 스마트 컨트랙트를 호출하는 로직이 실행된다.

Validation Frame 단계에서 계정이 정의한 자체 승인 로직(예시: Fusaka에서 최적화된 P-256 패스키 서명 검증)을 실행할 뿐만 아니라, 가스비 지불 승인 처리까지 수행할 수 있다. 이에 따라 별도의 ERC-4337 번들러 네트워크를 거치지 않고도, 원하는 암호화 알고리즘 서명과 제3자 가스비 대납(Paymaster) 로직을 L1 네이티브 트랜잭션 파이프라인 안에서 처리할 수 있게 된다.

EIP-8141: Frame Transactions

5. 확장 후에도 남는 과제

Fusaka, Glamsterdam, Hegota로 이어지는 개편이 진행되더라도 이더리움 생태계에는 지속적으로 평가해야 할 과제들이 남아있다.

빌더 레이어의 집중화 문제: ePBS를 통해 블록 제안 과정의 릴레이 의존성을 줄이더라도, 고성능 MEV 알고리즘과 대규모 자본을 가진 일부 전문 빌더로 블록 생성 시장이 집중되는 현상은 여전히 존재한다.
노드 운영 리소스 부담: PeerDAS, BALs, BPO 기술을 통해 노드 요구 사양의 상승폭을 억제하고 있으나, 데이터 처리량 증대와 병렬 처리를 지원하기 위한 멀티코어/RAM 메모리 사양 부담은 소규모 검증 노드의 운영 유지에 상시적인 요인으로 작용한다.
L2 자체의 보안 및 탈중앙화 문제: L1의 데이터 가용성과 실행 성능이 향상되는 것과 별개로, 각 L2 체인이 사용하는 Sequencer의 탈중앙화 수준, Fraud/Validity Proof 시스템의 완성도는 L2 생태계 내부에서 별도로 검증하고 평가해야 하는 영역이다.

7. 정리

Fusaka: PeerDAS와 BPO(EIP-7892)를 통해 L2용 데이터 가용성 공간을 확장하고, EIP-7825로 L1 연산 안전선을 설정한다.
Glamsterdam: ePBS(EIP-7732)로 블록 빌딩을 L1 프로토콜 내부로 흡수하고, BALs(EIP-7928) 및 가스 개편(EIP-8037)을 통해 EVM 병렬 실행 기반을 정비한다.
Hegota: FOCIL(EIP-7805)로 검열 저항성 규칙을 보완하고, Frame Transactions(EIP-8141)를 통해 가스비 승인을 포함한 네이티브 계정 추상화 체계를 정립한다.