MEV-Boost를 프로토콜 안으로 넣으면 무엇이 달라질까: EIP-7732 ePBS로 보는 블록 생산 신뢰 경계

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: Ethereum이 proposer와 builder의 역할 분리를 프로토콜에 “enshrine”하면, 개발자는 MEV·릴레이·블록 전파 리스크를 어떻게 다시 봐야 할까?
• 핵심 출처:
  • Glamsterdam | ethereum.org - 최종 업데이트 2026-06-06, 확인일 2026-06-21
  • EIP-7732: Enshrined Proposer-Builder Separation - 생성일 2024-06-28, 확인일 2026-06-21
  • epbs-devnet-1 spec | EthPandaOps - devnet 목표 2026-03-31, 확인일 2026-06-21
  • ethereum/consensus-specs v1.7.0-alpha.4 - 게시일 2026-03-27, 확인일 2026-06-21
  • ethereum/beacon-APIs PR #552: Standardized Epbs Beacon Api - 병합일 2026-02-12, 확인일 2026-06-21

1. 왜 지금 봐야 하나

Ethereum의 다음 큰 흐름 중 하나는 “더 많은 트랜잭션을 넣자”가 아니라 블록을 만드는 일과 블록을 검증하는 일을 언제, 누가, 어떤 보증으로 나눌 것인가다. ethereum.org의 Glamsterdam 로드맵은 H2 2026 계획으로 EIP-7732, 즉 enshrined proposer-builder separation(ePBS)을 핵심 후보로 설명한다. 같은 페이지는 ePBS가 현재 MEV-Boost·릴레이 같은 off-protocol middleware에 있는 신뢰 가정을 줄이고, consensus block과 execution payload를 별도로 다루어 데이터 전파 창을 넓힌다고 정리한다.

블록체인 앱 개발자에게 이건 단순한 validator 내부 사정이 아니다. 오늘날 많은 Ethereum 블록은 proposer가 직접 모든 트랜잭션을 조립하기보다 builder가 만든 payload를 받아들이는 PBS 흐름을 탄다. 이 구조는 MEV를 공개 경매처럼 만들고 proposer 수익을 높이는 데 도움을 줬지만, 핵심 교환은 프로토콜 밖의 relay와 middleware에 기대고 있다. relay가 payload 공개를 중계하고, proposer는 blinded block을 서명하고, builder는 payload를 제때 공개해야 한다.

EIP-7732의 질문은 간단하다. “이 교환을 Ethereum 합의 규칙 안으로 넣으면 어떤 실패 모드를 줄이고, 어떤 새 운영 표면이 생길까?”

2. 핵심 개념

먼저 용어를 정리하자.

• proposer: 특정 slot에 beacon block을 제안하는 validator다. 합의 관점에서 “이 블록을 체인에 올리자”고 말하는 역할이다.
• builder: mempool, private orderflow, MEV 전략 등을 이용해 execution payload를 조립하는 주체다.
• relay / MEV-Boost: 현재 proposer와 builder 사이의 교환을 도와주는 off-protocol 인프라다. Ethereum 합의 규칙 자체는 이 relayed exchange를 완전히 책임지지 않는다.
• ePBS: proposer-builder separation을 프로토콜에 내장해 builder commitment, payload reveal, proposer payment, timeliness attestation을 합의 객체로 다루려는 설계다.

EIP-7732의 핵심 변화는 BeaconBlockBody가 더 이상 전체 ExecutionPayload를 직접 들고 있지 않게 만드는 것이다. 대신 builder가 서명한 SignedExecutionPayloadBid가 consensus block 안에 들어가고, builder는 나중에 실제 execution payload를 SignedExecutionPayloadEnvelope 형태로 공개한다. 즉, consensus block은 “어떤 execution block을 나중에 공개하겠다는 약속”을 담고, 실행 검증은 한 박자 늦춰진다.

여기서 새로 중요한 역할이 **Payload Timeliness Committee(PTC)**다. PTC는 validator subset으로, builder가 약속한 payload를 제때 공개했는지, blockhash가 맞는지, blob data가 자기 관점에서 available했는지에 대해 attestation을 낸다. ethereum.org는 이를 dual-deadline logic이라고 표현한다. 합의 블록에 대한 attestation과 execution payload의 timeliness attestation을 분리해, 모든 노드가 같은 2초 안에 consensus validation·execution validation·blob availability 확인을 한꺼번에 끝내야 하는 병목을 줄이려는 것이다.

3. 최신 이슈와 연결

이번 글에서 확인한 최신 신호는 세 가지다.

첫째, ethereum.org Glamsterdam 페이지는 2026년 6월 6일 업데이트 기준으로 ePBS를 Glamsterdam의 대표 proposal로 설명한다. 특히 현재 hot path에서는 transaction broadcasting과 execution이 짧은 시간 창 안에 몰리고, ePBS는 proposer와 builder 역할을 프로토콜 수준으로 분리해 전파 시간을 늘린다고 설명한다.

둘째, EIP-7732 명세는 아직 Draft이지만 구체적인 합의 객체를 제안한다. SignedExecutionPayloadBid, SignedExecutionPayloadEnvelope, builder의 in-protocol stake, proposer에게 지급되는 payment, PTC attestation이 모두 명세 안에 들어간다. 중요한 점은 builder가 일반 validator와 같은 역할이 아니라, payload를 commit/reveal하고 payment를 보증하는 별도 staked entity로 다뤄진다는 것이다.

셋째, 구현 신호도 있다. EthPandaOps의 epbs-devnet-1 문서는 2026년 3월 말 목표 devnet에서 EIP-7732를 테스트 대상으로 두고, Prysm·Lodestar 등 클라이언트 조합과 engine_forkchoiceUpdatedV3, engine_newPayloadV5, engine_getPayloadV5 같은 Engine API 버전을 명시한다. consensus-specs v1.7.0-alpha.4 릴리스도 Gloas 항목에서 PTC window cache, payload attestation message 처리, missing payload envelope request 같은 변경을 포함한다. beacon-APIs PR #552는 ePBS용 Beacon API를 표준화하며 execution_payload_bid, ptc duties, payload_attestation_data, payload attestation pool endpoint를 추가했다.

즉, ePBS는 “언젠가 좋은 아이디어” 수준을 넘어, 명세·API·devnet·client 실험으로 내려온 상태다. 다만 Draft와 devnet 단계이므로 앱 개발자가 지금 해야 할 일은 하드코딩된 결론을 내리는 것이 아니라, 자신의 시스템이 어떤 블록 생산 가정을 은근히 전제하는지 찾아내는 것이다.

4. 개발자 관점 해석

4-1. 블록 생산은 더 이상 단일 actor의 함수처럼 보이면 안 된다

간단한 dApp은 transaction -> block -> finality만 생각해도 된다. 하지만 MEV, oracle, liquidation, bridge, rollup batcher, intent solver를 다룬다면 블록은 하나의 actor가 만든 결과물이 아니다. proposer는 consensus block을 고르고, builder는 execution payload를 조립하고, PTC는 payload timeliness와 blob availability 관측을 남긴다.

따라서 “트랜잭션이 inclusion되었다”는 상태도 더 세분화해 봐야 한다.

사용자 전송
→ mempool / private orderflow 진입
→ builder payload에 포함
→ proposer가 bid 선택
→ consensus block에 commitment 포함
→ payload reveal
→ PTC가 timely/available로 관측
→ execution validation
→ finality

이 흐름을 모르면, 앱의 상태 머신은 “블록에 보이는가?” 하나만 보고 위험한 결정을 내릴 수 있다.

4-2. relay 신뢰가 사라지는 것이 아니라 형태가 바뀐다

ePBS의 목표 중 하나는 off-protocol relay 신뢰를 줄이는 것이다. 하지만 이것이 모든 block-production risk가 사라진다는 뜻은 아니다. 신뢰 경계가 middleware에서 protocol object와 client implementation으로 이동한다.

예를 들어 개발자는 다음 질문을 봐야 한다.

• 내 MEV-aware 서비스는 특정 relay API 응답을 canonical truth처럼 쓰고 있나?
• builder bid, payload envelope, payload attestation event를 분리해 관측할 준비가 되어 있나?
• ePBS 이후에도 private orderflow·preconfirmation·intent market 같은 off-protocol 시장을 별도로 신뢰하고 있나?
• validator나 staking pool을 운영한다면 builder selection과 PTC duty failure를 모니터링할 수 있나?

프로토콜이 교환을 내장하면 UX는 좋아질 수 있지만, 관측 포인트는 오히려 더 많아질 수 있다.

4-3. 롤업과 blob 앱은 “더 긴 전파 창”을 비용 절감으로만 읽으면 안 된다

ePBS가 blob 전파와 execution validation의 hot path를 완화하면, 장기적으로 L1 gas limit과 blob capacity 확대의 기반이 될 수 있다. 하지만 앱 입장에서는 “싸진다”보다 “지연·관측·reorg 모델이 달라진다”가 먼저다.

특히 rollup batcher, bridge watcher, oracle relayer는 payload reveal과 blob data availability 관측 시점을 따로 생각해야 한다. 블록 commitment는 보였지만 payload나 blob 관측이 늦거나 실패하는 edge case에서 무엇을 할지 정해야 한다. EIP-7732가 바로 그런 edge case를 합의 객체로 끌어올리는 설계이기 때문이다.

5. 내 프로젝트에 적용할 체크포인트

• 블록 상태를 한 단계로 저장하지 말기: seen_in_block 하나보다 bid_seen, payload_revealed, payload_timely, executed, finalized처럼 내부 상태를 나눌 수 있는지 검토한다.
• MEV/relay 의존성 목록 만들기: relay API, private tx endpoint, bundle submission, builder-specific endpoint를 어디에서 쓰는지 검색한다.
• oracle·bridge confirmation policy 재점검: “N block confirmations” 규칙이 payload reveal delay, blob availability delay, builder failure를 설명하지 못할 수 있다.
• validator/staking 운영자는 새 duty를 모니터링하기: PTC duty, payload attestation miss, builder payment, builder index 오류를 별도 알림으로 설계한다.
• 로그 스키마에 block-production metadata 넣기: block number만 남기지 말고 proposer, builder/bid 식별자, relay 또는 payload source, blob 관련 관측값을 남길 수 있게 한다.
• Draft 상태를 명시하기: EIP-7732는 Draft이며 세부 endpoint와 client 동작은 바뀔 수 있다. 제품 문서에는 “Glamsterdam/ePBS 대비”와 “현재 mainnet behavior”를 분리한다.

6. 오늘 10분 액션

1. 코드베이스에서 mev, relay, builder, flashbots, bundle, private tx, confirmation 키워드를 검색한다.
2. 트랜잭션 상태 enum이 있다면 pending / confirmed / finalized / failed 네 단계뿐인지 확인한다.
3. oracle, bridge, liquidation bot 중 하나를 골라 “payload가 약속됐지만 아직 실행 검증 전”이라는 중간 상태가 생기면 어떤 오판을 할지 한 문장으로 적는다.
4. 운영 대시보드에 block number 외에 slot, proposer, payload source, blob availability 관련 메타데이터를 붙일 수 있는지 확인한다.
5. EIP-7732 명세에서 SignedExecutionPayloadBid와 PayloadAttestationMessage 이름만 찾아보고, 이 두 객체가 내 시스템의 어느 로그와 연결될지 상상해본다.

7. 더 볼 자료

• Glamsterdam | ethereum.org
• EIP-7732: Enshrined Proposer-Builder Separation
• epbs-devnet-1 spec | EthPandaOps
• ethereum/consensus-specs v1.7.0-alpha.4
• ethereum/beacon-APIs PR #552

중복 회피 메모

최근 blockchain_dev 글은 PeerDAS/data availability, EIP-7918 blob fee reserve, EIP-7928 block-level access list, FOCIL inclusion list, Solana Alpenglow finality, OP Stack interop, Chainlink CCIP TokenPool upgrade, Uniswap v4 hook, ProxyAdmin 권한 사고를 다뤘다. 이번 글은 DA 샘플링·blob 가격·병렬 실행·검열 저항이 아니라 MEV-Boost/relay에 있던 proposer-builder 교환을 EIP-7732 ePBS가 합의 객체로 바꾸는 원리와 그에 따른 블록 생산 관측 경계에 집중해 중복을 피했다.