Focil과 ePBS가 다시 쓰는 이더리움의 블록 생산 파이프라인
핵심 요약 3가지
- MEV 구조가 Builder와 Relay에 권한을 집중시키며 블록 생산 파이프라인이 사실상 중앙화된 형태로 고착되고 있다.
- 검증자는 Relay가 제공하는 Payload에 의존해야 하므로 투명성이 낮아지고, 특정 트랜잭션이 배제될 수 있는 검열 위험이 증가한다.
- 이더리움은 Focil과 ePBS를 통해 중앙화·검열·병목 문제를 근본적으로 해결하기 위해 블록 생산 파이프라인을 재설계하고 있다.
Focil과 ePBS가 어떻게 이더리움의 블록 생산 파이프라인을 근본적으로 재설계하는지 한눈에 이해하기.
50초 쇼츠 영상
50초 영상으로 전체 흐름을 먼저 이해한 뒤, 아래 본문에서 더 깊이 있게 살펴보세요.
1. 왜 이더리움은 지금 파이프라인을 재설계하는가
MEV(Maximal Extractable Value)는 블록 생산자가 트랜잭션의 순서를 재배치하거나 포함·제외함으로써 얻을 수 있는 경제적 이익을 의미한다.
문제는 이 MEV 수익이 점점 소수의 Builder에게 집중되고, 블록 전달과 검증을 중개하는 Relay 역시 소수 사업자가 운영하면서 블록 생산 과정이 사실상 중앙화된 파이프라인처럼 굳어지고 있다는 점이다. 즉, 현재 구조에서는 Builder가 경제적 권한을, Relay가 정보·전달 권한을 과도하게 보유하게 된다.
검증자는 블록의 내용을 직접 확인하기 어렵고, Relay가 제공하는 Payload에 의존해야 한다. 이 때문에 투명성이 떨어지고 특정 트랜잭션이 의도적으로 제외되는 검열 위험도 커진다.
이더리움이 파이프라인을 재설계하려는 이유는 바로 이 MEV 추출 과정에서 발생하는 중앙화·검열·병목 문제를 근본적으로 해결하기 위해서다.
MEV 구조가 Builder 중앙화를 가속
Execution Payload 검증이 병목을 유발
Proposer가 블록 내용을 충분히 통제하지 못함
검열 저항성 약화 가능성
슬롯 시간 단축이 어려운 구조적 한계
이러한 문제들이 실제로 어떻게 나타나는지는 트랜잭션이 처리되는 전체 흐름을 보면 더 분명해진다. 이제 이더리움 트랜잭션 라이프사이클을 단계별로 살펴보자.
2. 이더리움 트랜잭션 라이프사이클
이더리움의 트랜잭션은 실행 레이어(EVM)와 합의 레이어(Beacon Chain)가 협력해 처리된다. 아래는 각 단계에서 어떤 일이 일어나고, Focil과 ePBS가 어떤 문제를 해결하는지 정리한 것이다.
① 사용자가 트랜잭션 전송 — Execution Client 기본 검증
트랜잭션은 지갑에서 노드로 전달되며, Execution Client가 서명, nonce, 가스 한도 등 기본 유효성 검증을 수행한다.
검증된 트랜잭션은 mempool에 저장되고, 수수료 기준으로 정렬되며 네트워크 전체로 전파된다. 이 단계에서는 Focil·ePBS가 개입하지 않는다.
② 실행 레이어(EVM) 사전 검증 — 트랜잭션 유효성 판단
EVM은 수수료 계산과 상태 시뮬레이션을 통해 트랜잭션이 블록에 포함될 수 있는지 판단한다.
하지만 현재 구조에서는 Builder가 특정 트랜잭션을 선택·배제할 수 있어 검열 저항성 문제가 발생한다. 즉, Builder의 선택이 네트워크 공정성을 왜곡할 수 있다.
Focil 개입
- Inclusion List(IL)로 반드시 포함해야 하는 트랜잭션을 지정
- Builder의 임의 배제를 사전에 차단
ePBS 개입
- Proposer–Builder 분리로 Proposer의 MEV 추출 유인을 제거
- 트랜잭션 배제 유인을 구조적으로 감소
해결되는 문제
- 검열 저항성 강화
- MEV 기반 선택 왜곡 완화
트랜잭션이 유효하다고 판단되면, 이제 블록을 제안할 주체를 선정하는 단계로 넘어간다.
③ 블록 제안자(Proposer) 선정 — Consensus Layer
각 Slot마다 블록을 제안할 검증자가 선택된다. 기존 구조에서는 Builder가 블록 구성과 제출을 모두 독점했다.
ePBS는 이 권한을 분리해 Builder는 Payload만 만들고, Proposer는 여러 Builder가 제출한 Payload 중 하나를 선택한다.
해결되는 문제
- Builder 중앙화 해소
- 검열 저항성 강화
Proposer가 정해졌다면, 이제 어떤 트랜잭션을 담은 Payload가 만들어지는지가 중요해진다.
④ Execution Payload 생성 — Builder가 트랜잭션 선택
Builder는 mempool에서 트랜잭션을 선택해 Payload를 구성한다. 이 단계가 MEV·검열·중앙화 문제가 가장 크게 발생하는 지점이다.
Focil 개입
- Inclusion List 강제 적용
- Payload 구성 권한을 단일 Builder에서 다자 구조로 이동
ePBS 개입
- Builder 권한 제한
- 최종 선택권을 Proposer에게 부여
해결되는 문제
- 블록 내용 탈중앙화
- 검열 저항성 강화
- Builder 중앙화 해소
이렇게 구성된 Payload는 이제 Beacon Block에 포함될 차례다. 이 단계에서 기존 구조와 ePBS 구조의 차이가 극명하게 드러난다.
⑤ Beacon Block 생성 및 포함 — Consensus Layer
A. 기존 구조 — Builder가 사실상 블록 내용을 결정
Builder가 만든 Payload는 사실상 자동으로 블록에 포함된다. Proposer는 형식적으로 서명만 할 뿐 실질적 선택권이 없다.
결과적으로 Builder가 블록 내용을 사실상 결정하며, Builder 독점이 강화된다.
B. ePBS 구조 — Proposer가 최종 선택권 행사
Proposer는 여러 Builder가 제출한 Payload 중 하나를 선택해 블록에 포함한다. Builder는 Payload를 ‘제안’만 할 뿐, 포함 여부는 Proposer가 결정한다.
Focil 개입
- Payload 검증 부담 감소
- 노드 운영 복잡성 감소
ePBS 개입
- Builder 영향력 구조적 제한
- 중앙화 완화
이제 블록이 제안되었다면, 네트워크는 이 블록이 정당한지 확인하는 절차를 거친다.
⑥ Attestation(투표) — 검증자 확인 단계
검증자들은 무작위로 구성된 위원회에서 블록의 정당성에 투표한다. 2/3 이상이 동일한 블록에 투표하면 해당 블록은 정당성을 인정받는다.
Focil 개입
- 검증 부담 감소
- Attestation 지연 감소
ePBS 개입
- 없음 (합의 레이어의 순수 기능)
해결되는 문제
- 슬롯 시간 단축 기반 마련
- 노드 운영 복잡성 감소
마지막으로 블록은 최종성(Finality)을 획득하며 되돌릴 수 없는 상태가 된다.
⑦ 최종성(Finality) — 절대적 확정 단계
Epoch 단위로 블록이 최종성을 획득한다. 한 번 최종성을 얻은 블록은 사실상 되돌릴 수 없다.
Focil 개입
- Inclusion List 유지
- 검열 저항성과 탈중앙화 동시 보장
ePBS 개입
- 없음
해결되는 문제
- 노드 운영 복잡성 감소
- 블록 내용 탈중앙화 유지
3. 전체 요약: 단계별 목표 매핑
| 트랜잭션 단계 | 해결되는 목표 |
|---|---|
| 사용자 전송 | — |
| EVM 사전 검증 | 검열 저항성 강화 |
| Proposer 선정 | Builder 중앙화 해소, 검열 저항성 강화 |
| Payload 생성 | 탈중앙화, 검열 저항성 강화, 중앙화 해소 |
| Beacon Block 포함 | 슬롯 시간 단축 기반, 운영 복잡성 감소 |
| Attestation | 슬롯 시간 단축 기반, 운영 복잡성 감소 |
| 최종성 | 운영 복잡성 감소, 탈중앙화 유지 |
4. 결론: 이더리움은 ‘더 빠르고 더 탈중앙화된’ 미래로 간다
Focil과 ePBS는 단순한 성능 개선이 아니라, 이더리움의 블록 생산 파이프라인을 근본적으로 재설계하는 업그레이드다.
이 두 기술은 Builder 중앙화 해소, 블록 내용 탈중앙화, 검열 저항성 강화, 슬롯 시간 단축 기반 마련, 노드 운영 복잡성 감소라는 다섯 가지 목표를 동시에 달성한다.
이더리움은 지금 더 빠르고, 더 안전하며, 더 탈중앙화된 네트워크로 진화하고 있다.
정윤찬 (Younchan Jung)
AI, 블록체인, 온체인 경제의 구조적 변화를 탐구하는 리서처.
영문으로 읽기를 원하시면 아래 버튼을 클릭하세요.
댓글
댓글 쓰기