ePBS란 무엇인가

EIP-7732: enshrined Proposer-Builder Separation

Intro: Glamsterdam

이더리움의 다음 업그레이드인 Fusaka의 스코프가 모두 결정되고, 구현 및 테스팅이 활발히 이뤄지고 있는 동시에, 2026년 진행될 Glamsterdam 업그레이드에 어떤 피처가 들어갈지에 대한 논의가 평행하게 진행되고 있습니다. 그 중, 이더리움 커뮤니티에서 가장 활발히 논의된 것은 EIP-7732: enshrined Proposer-Builder Separation(ePBS)입니다. 해당 EIP의 저자들부터, 이더리움 재단 리서치, Flashbot 그리고 L2들까지 이 EIP를 두고 CT와 Ethereum Magicians에서 다양한 논의를 진행하고 있습니다.

이 글은 ePBS가 무엇인지 잘 모르고, 이에 대해 자세히 알아보고 싶은 사람들을 위해 ePBS의 배경과 디테일, 그리고 이를 둘러싼 논의 전반에 대해 설명합니다.

Why ePBS?

EIP-7732는 MEV-Boost의 고질적인 신뢰 문제 해결과 확장성 개선을 위해, 슬롯 구조를 변경하고 MEV-Boost 자체를 프로토콜에 내장하자는 제안입니다. 이는 일반적으로 ePBS라고 불립니다.

이에 대해 이해하기 위해, 우선 MEV-Boost가 무엇인지부터 알아봅시다. MEV-Boost는 블록을 제안하는 프로포저가 MEV에 전문성을 가진 블록 빌더에게 블록을 팔아, 대신 빌딩하게끔 하는 구조입니다. 이러한 구조가 없다면 이더리움 네트워크 전체는 더 중앙화될 수 있습니다. MEV 기회는 아무나 찾을 수 있는 것이 아니기 때문에, 이러한 능력을 가진 일부 밸리데이터들이 더 높은 수익을 달성하고, 이렇게 더 높은 수익률을 기반으로 일반 사용자들의 ETH까지를 위임받아 네트워크 전체가 더 중앙화되는 구조입니다. 즉, MEV-Boost는 전문성을 가진 객체에 모두가 블록 빌딩을 위임할 수 있게 하여, MEV 수익을 공정하게 분배하고 네트워크의 중앙화를 막기 위해 제안된 구조입니다.

그러나, 프로포저가 블록 빌더에게 빌딩 권한을 위임하는 형태는 생각보다 구현이 쉽지 않습니다. 나이브하게 디자인된다면, 빌더가 프로포저에게 약속한 비용을 주지 않는다거나, 프로포저가 bid는 받아놓고 빌더에게 받은 블록을 제안하지 않는 등 서로가 서로를 기만할 수 있는 상황이 발생할 수 있습니다. MEV-Boost에서는 ‘릴레이’라는 객체의 도입을 통해 이러한 문제를 해결하려고 합니다. 이를 구체적으로 살펴보면 다음과 같은 구조를 가지고 있습니다.

1. 차익거래 기회를 찾는 서처들은, 기회를 찾으면 이를 번들 형태로 블록 빌더에게 보냅니다.
2. 블록 빌더는 서처들에게 받은 번들과, 기타 여러 트랜잭션들을 포함해서 가장 수익성 있는 블록을 구성합니다.
3. 빌더는 이 블록에 bid를 붙인 다음, 릴레이에게 전달합니다.
4. 릴레이는 빌더의 블록을 가리고 블록 헤더 정보와 bid만을 담아, 현재 블록의 프로포저에게 보냅니다.
5. 프로포저는 가장 높은 bid를 받은 블록을 선택하고, 해당 블록 헤더에 서명을 하여 릴레이에게 보냅니다.
6. 릴레이는 프로포저의 서명을 확인하고, 선택된 블록 정보(실행 페이로드)를 프로포저에게 모두 전달합니다.

여기서 알 수 있는 점은, 현재의 오프체인 PBS는 블록 빌더와 프로포저 모두 릴레이에 대한 신뢰를 기반으로 하고 있다는 점입니다. 만약 릴레이가 특정 빌더를 검열하거나, 빌더가 준 블록을 프로포저에게 보여주지 않는다면 빌더와 프로포저 모두 손해를 볼 수 있게 되죠.

물론 릴레이를 하나만 써야 하는 이유는 없고 누구나 릴레이를 운영할 수 있기는 하지만, 이러한 신뢰 기반 구조는 없애는 것이 바람직합니다. ePBS는 기본적으로 이러한 아키텍처를 프로토콜 안에 내장해 릴레이에 대한 신뢰가 최소화될 수 있도록 합니다.

그러나 현재 Glamsterdam 업그레이드에서 ePBS가 주목받는 이유는, 이러한 장점 때문이라고 볼 수만은 없습니다. ePBS는 슬롯을 완전히 재구성해, 이더리움 L1과 L2의 확장성을 300% 가량 증가시킬 수 있다는 장점이 존재하며, 이것이 ePBS를 Glamsterdam에서 가장 주목받는 EIP로 만든 가장 큰 이유입니다. 이에 대해서도 글 후반부에 자세히 다뤄보겠습니다.

이더리움 슬롯 구조 및 Fork-choice Rule

ePBS에 대해 자세히 알아보기 전에, 먼저 현재 이더리움 슬롯의 구조와 합의 진행에 대해 알아보도록 하겠습니다. 현재 12초의 시간으로 구성된 이더리움 슬롯은 다음과 같이 구성되어 있습니다.

(Ethereum Slot Structure | 출처: Glamsterdam’s hidden gem — EIP-7732)

• 블록 전파(block propagation, 0초-4초): 프로포저가 블록을 밸리데이터들에게 전파합니다. 블록을 받은 비콘 위원회 내 밸리데이터들은 이를 블록 내의 실행 페이로드를 실행해보고 투표(attestation)를 생성합니다. 이더리움 합의 스펙 내에서는 이 기간이 종료되는 4초를 ‘attestation deadline’이라고 부릅니다.
• 투표 집계(attestation aggregation, 4초-8초): 밸리데이터들은 본인이 생성한 투표를 Aggregator에게 보냅니다. Aggregator는 BLS 서명 알고리즘에 따라, 동일한 블록에 대한 투표들을 한 개의 서명으로 집계하는 역할을 수행합니다.
• 집계 전파(aggregation propagation, 8초-12초): 집계된 서명이 네트워크에 전파됩니다.

여기서 프로포저가 전파한 블록들을 밸리데이터(attester)들이 투표하는 것은, 어떤 블록이 체인의 올바른 헤드인지를 결정하기 위함입니다. 이를 fork-choice rule이라고 합니다. Fork-choice 과정에서 각 밸리데이터들의 투표는 해당 밸리데이터가 가진 지분에 비례한 점수만큼 가중치가 매겨지며, 매 슬롯마다 가장 높은 가중치를 가진 블록이 체인의 올바른 헤드로 인정받게 됩니다(엄밀히는 에포크 완결이 되어야 하나, 단순화를 위해 이렇게 표현하였습니다).

여기서 Proposer Boost라는 개념이 존재합니다. 이는 블록 리오그를 줄이고 네트워크 안정성을 높이기 위해 도입된 개념으로, 현재 슬롯에 한해서 프로포저가 attestation deadline인 4초 안에 잘 블록을 제안한다면, 제안한 블록의 가중치를 40% 만큼 더해주는 것입니다. 즉, 프로포저가 블록을 빠르게 전파하면, 해당 블록의 fork-choice 가중치가 높아져 체인의 헤드가 될 가능성이 높아지고, 밸리데이터는 블록 보상을 예상한 대로 잘 받을 가능성이 높아지게 되는 것이죠.

(Proposer Boost | 출처: Ethereum Consesus Spec GitHub)

이렇게 이더리움의 합의는 밸리데이터 지분에 따른 투표 결과로 정해지며, 상황에 따라 네트워크 참여자들의 특정 행동을 유도하고 싶다면 Proposer Boost와 같은 가중치가 도입되기도 합니다.

ePBS는 무엇인가

그렇다면 이러한 배경지식 하에서, ePBS가 MEV-Boost를 개선하는지 알아보겠습니다. ePBS는, 릴레이를 통해 이뤄지던 블록 페이로드의 전달과 bid의 지불을 프로토콜 내의 로직으로 옮겨옵니다.

우선, ePBS는 이전까지 오프체인 객체이던 블록 빌더를 프로토콜 내로 들여옵니다. ePBS 이후 빌더는 일반 밸리데이터처럼 32 ETH 이상을 스테이킹해야 하죠. 이를 통해, 원래는 릴레이를 통해 이뤄지던 빌더와 프로포저 간 bid 지불을 프로토콜 로직으로 강제할 수 있게 됩니다. 이 지불은 비콘 블록이 제안될 때 이뤄집니다.

또한 ePBS는 이전에 릴레이를 통해 이뤄지던 실행 페이로드의 전달을 슬롯 구조 내에 포함시킵니다. 실행 페이로드는 이제 빌더가 직접 네트워크에 전파하게 되죠. 이를 구현하기 위해, ePBS는 블록의 구조에서 ‘실행 페이로드’를 ‘빌더가 서명한 블록 헤더값’으로 변경하고, 밸리데이터들끼리는 이 값에 대해 투표를 진행하도록 합니다. 즉, 트랜잭션이나 블롭 데이터 없이 일단 빌더가 제안할 블록의 헤더 값만을 가지고 합의를 진행하는 것이죠.

그러나 이 경우, 이미 실행 페이로드만 뺀 블록에 대해 합의가 이뤄진 상황에서 빌더가 실행 페이로드를 전파하지 않아버릴 수도 있습니다. 이러한 상황이 긴 블록 리오그를 일으켜 네트워크의 안정성에 큰 영향을 주는 것을 방지하기 위해, ePBS에서는 블록 페이로드의 전달을 감시하기 위한 새로운 위원회인 Payload Timeliness Committee (PTC) 를 도입합니다. PTC는 매 슬롯마다 선출되는 512개의 밸리데이터로 구성되며, 약속한 블록이 빌더로부터 프로포저에게 정해진 시간 내에 잘 전달해줬는지 감시합니다. PTC는 기존 비콘 체인 투표와 별도로 적용되는 Payload Timeliness (PT) 투표를 진행하게 됩니다. 이 투표는 빌더가 만든 실행 페이로드가 제대로 전파되었는지 여부를 확인하는 방식으로 이뤄지며, 이 투표의 결과에 따라 fork-choice 가중치가 조정됩니다.

PTC의 도입을 위해, ePBS는 슬롯 구조와 fork-choice rule 모두에 여러 가지 변경 사항을 적용합니다. 우선, ePBS에서의 이더리움 슬롯은 다음과 같이 변경됩니다 (후술되는 각 단계의 시간은 임의로 설정되었으며, 실제 ePBS 적용 시의 값과 다를 수 있습니다).

(Slot structure of ePBS | 출처: ethresearch)

블록 전파(0초-2초): 프로포저는 비콘 블록을 제안하여, 네트워크에 전파합니다. 전파되는 블록에는 실행 페이로드 대신, 빌더가 서명한 블록 헤더값인 SignedExecutionPayloadEnvelope 이 들어가 있습니다. 실행 페이로드는 일반적으로 비콘 블록의 대부분을 차지했기에, 여기서 전파되는 비콘 블록은 크기가 상대적으로 매우 작고, 기존 attestation deadline이었던 4초보다 더 작은 시간 안에 전파 및 투표가 이뤄질 수 있습니다.

• 투표 집계(2초-6초): 밸리데이터들은 본인이 생성한 투표를 Aggregator에게 보냅니다. Aggregator는 BLS 서명 알고리즘에 따라, 동일한 블록에 대한 투표들을 한 개의 서명으로 집계하는 역할을 수행합니다.
• 집계 및 페이로드 전파(6초-10초): 집계된 서명을 네트워크에 전파합니다. 이 단계에서는 빌더가 네트워크에 실행 페이로드(일반 L1 트랜잭션 + 블롭)를 전파하는 작업도 포합됩니다. PTC는 전파되는 실행 페이로드를 확인하고, 잘 전파되었으면 PAYLOAD_PRESENT에, 빌더가 전파를 거부했으면 PAYLOAD_WITHHELD에, 아예 전파되지 않았다면 PAYLOAD_ABSENT에 PT 투표를 진행합니다.
• PT 투표 결과 전파(10초-12초): PT 투표의 결과가 네트워크에 전파되고, 이에 따라 다음 슬롯에서 해당 슬롯의 fork-choice 가중치가 결정됩니다. 이 가중치 결정을 Payload Boost라고도 부릅니다.

PT 투표 결과에 따라 fork-choice 가중치가 결정되는 것은 다음과 같이 여러 가지 경우에 따라 이뤄집니다.

1. 프로포저와 빌더 모두 정직하게 행동하는 경우

프로포저가 적시에 비콘 블록을 전파하고, 이를 확인한 빌더가 실행 페이로드를 잘 전파했다고 해봅시다. 만약 PTC의 절반(256명) 이상이 실행 페이로드의 정상적인 전파를 확인해 PAYLOAD_PRESENT 에 투표했다면, 해당 블록은 다음 슬롯에서 40%의 fork-choice 가중치를 얻게 됩니다. 이 가중치를 Reveal Boost라고 부릅니다. Reveal Boost는 빌더가 올바르게 실행 페이로드를 전파했을 때, 해당 블록이 리오그나는 상황을 최대한 방지하기 위한 조치입니다.

2. 프로포저가 악의적인 경우

(Proposer-initiated splitting | 출처: ethresearch)

특정 상황에서, 프로포저는 빌더의 실행 페이로드를 훔쳐, 본인이 MEV 수익을 가로채는 공격을 수행할 수 있습니다. 원래 MEV-Boost에서는 릴레이가 정직하게 행동한다는 가정 하에 이러한 공격이 불가능했으나, ePBS에서는 페이로드 공개 및 전파를 빌더가 직접 하기 때문에, 문제가 될 수 있죠.

예를 들어, 연속되는 두 슬롯 N과 N+1에 대해, 해당 슬롯들의 프로포저와 attester들이 공모하였다고 가정해보겠습니다. 슬롯 N에서 비콘 블록 P가 제안되면, 슬롯 N의 프로포저는 attester들로 하여금 ‘지금 제안된 블록 말고, 이전 슬롯인 N-1에 투표해’라고 명령하여, P의 가중치를 의도적으로 낮춥니다.

이후 순진한 빌더는 블록 P에 대한 실행 페이로드를 네트워크에 공개하고 프로포저에게 bid를 지불합니다. 네트워크는 다음 슬롯인 N+1의 투표를 진행합니다. 이때 공모한 프로포저와 attester들은 블록 P와 연결되는 블록에 투표하는 것이 아니라, 그 이전 슬롯인 N-1에 연결되는 새로운 블록 Q를 만들어 이에 투표합니다. 만약 블록 Q에 대한 투표가 높다면 블록 P는 체인의 일부가 아닌 것으로 판정되어 네트워크에서 제외될 것이고, 빌더는 네트워크에 페이로드를 정상적으로 공개했음에도 페이로드가 네트워크에 포함되지 못할 것입니다.

ePBS에서는 이러한 상황을 방지하기 위해, 파라미터를 조정함과 동시에 빌더에게 ‘페이로드를 공개하지 않는 옵션’을 부여합니다. 우선, ePBS에서는 악의적인 프로포저에 의해 빌더 페이로드가 제외되는 상황을 최대한 막기 위해 Proposer Boost의 가중치를 40%에서 20%로 내려, 올바른 체인 헤드 결정에 미치는 프로포저의 영향력을 줄입니다.

또한, 빌더는 페이로드 대신 ‘페이로드 전파를 거부하겠다’라는 메세지를 네트워크에 전파할 수 있습니다. 빌더는 이제 네트워크 참여자로 동작하며, 실시간으로 본인이 빌딩한 블록의 실시간 투표율을 확인할 수 있기 때문에, 악의적인 프로포저가 attester와 공모하는 등 투표율을 조작하여 빌더의 페이로드를 가로채는 행위를 감지할 수 있습니다. 이 경우 빌더는 페이로드 전파 거부 메세지를 네트워크에 전파하며, PTC에 포함된 밸리데이터는 이 거부 메세지를 보면 PAYLOAD_WITHHELD 에 투표해야 합니다. 만약 절반 이상의 PTC가 PAYLOAD_WITHHELD 에 투표했으면 현재 슬롯에 제안된 블록의 반대쪽에 40%의 fork-choice 가중치가 부여됩니다. 이 가중치는 빌더가 현재 비콘 블록에 대한 투표율을 확인하여 악의적인 프로포저가 있다는 것을 감지하고 전파 거부(withhold) 메세지를 보냈음에도 불구하고, 해당 블록이 완결되어 빌더가 프로포저에게 bid를 지불해야 하는 것을 최대한 막기 위한 조치입니다.

Potuz의 리서치에 따르면, 연속된 블록에서 공모한 프로포저 및 attester의 지분율이 전체의 20%를 넘지 않는다면, 빌더가 페이로드를 빼앗기거나 억울하게 bid를 지불하는 일은 발생하지 않습니다.

3. 빌더가 페이로드 제출을 하지 않은 경우

이 경우 PTC는 PAYLOAD_ABSENT 에 PT 투표를 진행할 것이며, 해당 블록은 다음 슬롯에서 별도의 가중치를 얻지 못합니다. 이러한 상황에도 프로포저가 정상적으로 비콘 블록을 전파했다면 빌더는 프로포저에게 bid를 주어야 하기 때문에, 프로포저는 빌더의 악의적인 페이로드 미제출에도 돈을 받아낼 수 있습니다.

즉, ePBS는 빌더를 프로토콜 내 객체로 끌어오고, PTC를 도입한 후 여러 가지 공격 상황들을 고려해 fork-choice rule을 수정함으로써, 릴레이의 신뢰 이슈를 제거한 버전의 PBS를 구현합니다.

ePBS를 통한 확장성 증가

그러나, Glamsterdam에서 ePBS가 주목받는 이유는 이러한 장점 때문만이 아닙니다. ePBS의 가장 큰 장점은, 슬롯 재구조화 덕분에 이더리움 네트워크 전반의 확장성이 크게 증가할 수 있다는 점입니다.

위에서 설명한 ePBS의 슬롯 구조로 다시 돌아가보겠습니다.

(Slot structure of ePBS | 출처: ethresearch)

ePBS는 맨 처음 블록 전파 시 실행 페이로드를 넣지 않습니다. 즉, 실행 페이로드는 나중에 잘 전파될 것이라고 생각하고 나머지 것들에 대해 먼저 합의하는 것이죠. 이후 실행 페이로드의 전파는 3단계인 집계 / 페이로드 전파 단계에서 일어납니다.

그런데, 여기서 두 번째 단계인 투표 집계를 자세히 들여다보면, 이 단계에서 밸리데이터들은 투표를 전파하는 것 외에 다른 일을 하지 않기 때문에 상대적으로 리소스가 많이 남습니다. 즉, 이 단계에서부터 실행 페이로드의 전파를 시작해버릴 수도 있는 것이죠.

이렇게 되면, 위의 타임라인을 기반으로 슬롯 시작 후 2초부터 10초까지 8초 동안의 시간을 페이로드 전파에 온전히 쓸 수 있습니다. 기존 이더리움의 슬롯 구조에서는 실행 페이로드 전파가 attestation deadline인 4초 전까지 이뤄져야 했고, 실행 및 투표 등의 여러 가지 부가적인 것들을 고려한다면 실질적으로 실행 페이로드 전파에 할당된 시간은 약 2초 정도밖에 없었습니다. 즉, ePBS는 실행 페이로드의 전파 시간을 약 4배 늘릴 수 있는 것이죠.

실행 페이로드 전파 시간이 넉넉해지면 ‘실행 계산 능력’이 아니라 ‘데이터 전파’가 확장성의 병목이었던 오늘날 이더리움의 한계를 직접적으로 완화할 수 있습니다. 홈 스테이커와 같이 네트워크 환경이 열악한 노드는 블록에 더 많은 트랜잭션과 블롭이 들어갈 경우, 블록을 제 시간에 전파하지 못하거나 전파받지 못하여 네트워크에 참여할 수 없습니다. 그러나 ePBS가 도입된다면 데이터 전파를 더 오랜 시간 할 수 있게 되기 때문에, 현재 네트워크 요구 사항 내에서도 한 블록 내에 들어가는 데이터의 크기를 늘릴 수 있는 것입니다.*

* 다만 빌더가 현재 블록의 투표율을 보며 페이로드 전파 여부를 결정할 것이기 때문에, 확장성의 증가는 실제로 4배보다는 낮을 것입니다.

** 블롭은 일반적으로 MEV와 큰 상관이 없기 때문에, 빌더는 투표가 전파되기 전에 블롭 사이드카를 통해 블롭을 미리 전파할 수도 있습니다.

*** 활발히 논의되고 있는 솔루션 중 Dual-deadline PTC vote에서는 일반적인 실행 페이로드 전파와 블롭에 대한 전파를 나누고 PTC가 각각의 전파에 대해 두 번 투표하게 만들자는 제안을 하기도 했습니다. 이는 블롭보다 전파가 빠른 실행 페이로드를 빠르게 전파하게끔 하여, 데이터 전파에 대한 시간을 최대화하고 확장성을 더욱 끌어올리자는 제안입니다.

기존 구조에서 이러한 개선이 불가능했던 이유는, 실행 페이로드가 모두 전파된 이후에 투표를 해야만 했던 구조 때문이었습니다. ePBS에서는 비콘 블록과 실행 페이로드를 구분하여, 먼저 비콘 블록에 대한 합의를 진행하고 이에 대한 실행 페이로드는 따로 전파하는 구조로 실행 페이로드 전파에 필요한 시간을 최대한 확보할 수 있게 되는 것이죠.

실제로 Nethermind에서 테스트해본 결과, 현재 버전의 이더리움 클라이언트와 ePBS가 적용된 버전의 확장성 차이는 생각보다 컸습니다. 1기가가스 수준의 로드(4초마다 2억 가스의 블록)에서, 기존 클라이언트는 스트레스를 버티지 못하고 많은 리오그를 일으킨 반면, ePBS가 적용된 클라이언트는 한 번의 리오그도 없이 정상적으로 네트워크를 유지하는 것을 확인하였습니다.

[embed]

이러한 장점은 현재 이더리움의 단기 목표인 Scale L1 및 Scale L2와 매우 잘 맞물리기도 하며, 많은 클라이언트 및 커뮤니티의 지지를 받고 있습니다.

ePBS의 부작용: free-option problem

free-option 문제 — 빌더의 무위험 수익 전략

그러나 ePBS가 모든 문제를 해결하는 완벽한 솔루션인 것은 아닙니다. ePBS가 화두에 오르면서 지적받은 가장 큰 문제점은, 플래시봇에서 지적한 free-option 문제입니다.

이는 빌더가 악의적인 프로포저에 저항할 수 있도록, 빌더에게 ‘페이로드 전파 거부권’을 주었기 때문에 발생할 수 있는 문제입니다.

기존 MEV-Boost에서 빌더는 PBS 옥션이 종료되면 제안한 페이로드를 취소하기 매우 어려웠습니다. 슬롯 N에 대한 MEV-Boost 옥션과 프로포저에게 페이로드가 전달되는 시점은 모두 슬롯 N 시작 전이며, 빌더가 페이로드를 취소할 수 있는 시점은 다음과 같습니다.

MEV 옥션이 끝나 릴레이가 프로포저에게 MEV 옥션에서 이긴 bid 및 헤더를 전달하고, 밸리데이터가 이에 서명하여 릴레이에게 반환하는 동안의 시간

이 기간은 길어야 200ms 정도 되는 짧은 시간입니다. 그러나, ePBS에서는 슬롯 시작 후 일정 시간까지 빌더가 페이로드 전파 여부를 결정할 수 있으므로, 빌더는 여유 있게 (약 8초 간) 시장 상황을 지켜보며 페이로드를 전파할지 취소할지를 결정할 수 있습니다.

이게 왜 문제가 될 수 있을까요? 플래시봇의 원글에 나온 비유를 인용하면, ‘바이낸스처럼 유동성이 높은 시장에서 BTC나 ETH(현물 및 선물)를 거래하고 있는데, 누군가 8초 후 시장 상황이 마음에 들지 않으면 모든 거래를 취소할 수 있는 옵션을 제공하는 것과 같다’고 볼 수 있습니다. 즉, 빌더는 8초 전 본인이 구성한 블록과 지금 시장 상황을 보고, 외부 시장의 흐름이 본인이 만든 블록에 불리하게 굴러가면 페이로드 전파를 거부하는 것입니다.

이를 통해 빌더가 얻을 수 있는 이득 중 가장 단순한 예시는, CEX-DEX 아비트라지를 통해 무위험 수익을 챙겨가는 것입니다. 예를 들어, 빌더가 블록 맨 위에 ETH를 DEX에서 대규모로 구매하는 트랜잭션을 넣어 페이로드를 구성했다고 해 봅시다. 만약 8초 후 시장에서 ETH의 가격이 급락했다면, 빌더는 해당 페이로드에 대한 전파를 거부(withhold)하여 해당 슬롯에는 빈 블록이 들어가게끔 만들고, 본인은 손해를 보지 않게 할 수 있습니다. 반대로 ETH의 가격이 8초 후에 급상승했다면, 빌더는 페이로드를 그대로 공개해 CEX-DEX 차익거래를 진행할 수 있죠. 심지어 시장 상황이 초 단위로 급격하게 변한다면, withhold 옵션이 아니라 아예 실행 페이로드 혹은 블롭 일부를 전파하지 않는 방식으로, 해당 블록에 대한 bid만큼의 손해를 보더라도 페이로드를 취소할 수도 있죠. 플래시봇의 원 글에 따르면, 1M의 유동성으로 이러한 작업을 계속했을때 빌더가 하루 동안 얻을 수 있는 수익은 $1.3M에 달합니다.

빌더가 이러한 전략을 계속해서 택한다면, 빌더가 시장의 방향성을 맞추지 못할 때마다 이더리움에는 빈 슬롯이 생길 것이며, 사용자들은 더 큰 레이턴시를 겪게 될 것입니다.

다만 이는 ePBS만이 가진 문제는 아닙니다. 현재 MEV-Boost에서도 빌더는 릴레이와 공모한다면 200ms보다 더 긴 시간 동안 페이로드를 취소할 수 있는 권한을 가질 수 있으며, Delayed Execution이나 APS 등 스케일링을 위해 실행 페이로드와 블롭 전파의 데드라인을 서로 다르게 설정하는 모든 제안에서도 유사한 문제가 발생할 수 있습니다.

또한, 빌더가 이러한 전략을 계속 택할 가능성도 적습니다. 정직한 프로포저들 입장에서 이러한 전략을 택하는 빌더를 만나게 되면 본인이 제안한 블록이 지속적으로 리오그될 것이기 때문에, 해당 빌더가 제안한 블록을 택하지 않는 방향으로 움직일 것이기 때문입니다. 서처들도 이러한 전략을 택하는 빌더들에게 트랜잭션을 보내지 않을 것입니다. ‘이더리움에 빈 블록을 만드는 주범이다’라는 비판이 따라오는 등 사회적인 압력도 존재할 것이구요.

free-option 문제의 해결책

그럼에도 free-option이 현실적으로 문제가 될 수 있다면, 여러 가지 해결책을 고려해볼 수 있습니다. 구현 및 테스팅에 시간이 많다면 가장 명확한 해결책 중 하나는, EIP-7782를 적용해 슬롯 타임을 12초에서 6초로 줄이는 것으로 보입니다. 그렇게 되면 빌더가 free-option 전략을 취할 때까지 기다릴 수 있는 시간이 8초에서 4초로 줄어들며, 이 경우 free-option의 기댓값도 크게 줄어들 수 있습니다. 다만 ePBS가 6초 슬롯과 동시에 Glamsterdam에서 구현될 수 있는지는 지켜보아야 하는 문제입니다.

블록 옥션을 도입하여, 빌더가 페이로드 전파 직전까지 페이로드를 변경할 수 있도록 하는 것도 문제를 완화할 수 있다는 이야기도 있습니다. 블록 옥션이 적용된 상황에서 빌더는 위와 같은 free-option 식 베팅을 하는 것이 아니라, 전파 직전에 가장 수익성이 높은 실행 페이로드를 구성하는 것이 항상 유리하기 때문에, 위와 같은 free-option 행사의 빈도가 줄어든다는 것입니다. 다만 블롭 전파 시간을 극대화하여 확장성 증가 효과를 늘리는 Dual-deadline PTC vote와 같은 구조에서, 빌더는 여전히 블롭 전파를 덜 해버리는 방식으로 여전히 free-option 베팅을 진행할 수 있기 때문에, 블록 옥션은 문제를 완전히 해결하지는 못할 것으로 보입니다.

결국 이 free-option 문제를 L1 / L2 확장에 따른 어쩔 수 없는 부작용으로 볼 것인지, 아니면 무조건 해결하고 넘어가야 하는 P0 버그로 볼 것인지는 아직까지도 미지수입니다.

커뮤니티의 반응

Forkcast의 공개와 Ethereum Magicians의 쓰레드, 그리고 다양한 클라이언트의 블로그에서 ePBS와 관련된 이야기가 나오고 있습니다. 현재 ePBS와 함께 Glamsterdam에 들어갈 유력 후보들로 고려되고 있는 EIP는 EIP-7805: Fork-Choice enforced Inclusion List (FOCIL), EIP-7886: Delayed Execution, EIP-7928: Block-level Access List (BAL), EIP-7782: Reduce Block Latency 등이 있으며, 이러한 제안들 사이에서 ePBS에 대해 의견을 표출한 회사 및 리서처들은 다음과 같습니다.

• Lighthouse: 합의 레이어 단에서 ePBS를 우선시해야 함. 그러나 ePBS의 원래 목적인 MEV-Boost 중앙화 문제 해결은 시급하게 조치되어야 하는 것이 아니며, 필요하다면 일부만 떼어서 확장성 이점만 가져갈 수도 있음.
• Prysm: ePBS의 확장성 증가, MEV 레이어에서의 신뢰 제거, UX 증진 등의 장점을 생각했을 때 ePBS는 Glamsterdam의 헤드라이너가 되어야 함.
• Lodestar: MEV-Boost 파이프라인에서 기존에 발생한 문제들과, ePBS가 가져다주는 확장성 이점을 고려했을 때 ePBS를 Glamsterdam에 포함해야 함.
• Base: L2에도 적용할 수 있고 빠른 preconfirmation이 가능하다는 점에서 Delayed Execution을 가장 선호하나, ePBS도 블롭 측면의 확장성을 크게 증가시켜준다는 점에서 지지함.
• Flashbot: ePBS가 구현되었을 때 발생하는 free-option 문제는 블록 리오그의 빈도를 늘릴 수 있으며, 이에 대해 더 많은 논의가 이뤄져야 함.
• Gattaca (Titan): ePBS는 빌더를 프로토콜 내로 끌고와 더 자본 집약적으로 만들어 빌더 시장의 진입 장벽을 높일 수 있고, 블록 경매가 이전의 공개된 형태에서 비공개 형태로 이뤄지는 등 경매 다이나믹이 변경될 가능성이 존재함.
• Mike Neuder: free-option 문제는 ePBS에서 심각한 P0 버그로 봐야 함.

이외에 Commit-Boost & Fabric과 L2Beat, Nethermind 등의 엔티티는 ePBS 대신 검열 저항 제안인 FOCIL을 Glamsterdam의 헤드라이너로 넣어야 한다고 주장하기도 합니다.

ePBS를 포함한 전반적인 Glamsterdam 헤드라이너에 대한 논의들은 차주 8/7 Ethereum All Core Devs Call에서 자세히 이뤄질 예정입니다.