Validator’s Note 17 — 이더리움 PBS 로드맵

Disclaimer: 이 글은 정보 전달을 위한 목적으로 작성되었으며, 특정 프로젝트에 대한 투자 권고, 법률적 자문 등 목적으로 하지 않습니다. 모든 투자의 책임은 개인에게 있으며, 이로 발생한 결과에 대해 어떤 부분에서도 DSRV는 책임을 지지 않습니다. 본문이 포괄하는 내용은 특정 자산에 대한 투자를 추천하는 것이 아니며, 언제나 본문의 내용만을 통한 의사결정은 지양하시길 바랍니다.

MEV(Maximal Extracted Value)란 트랜잭션을 포함, 제외, 순서를 조정하여 얻을 수 있는 이득을 뜻합니다. 밸리데이터는 블록을 생성하는 권리를 가지고 트랜잭션을 자신에게 유리하게 구성하여 차익 거래(Arbitrage trading), 청산(Liquidation), 선형 매매(Front-running) 등의 기회로 컨센서스 레이어의 블록 보상에 더하여 추가적인 MEV 수익을 얻을 수 있습니다.

하지만 밸리데이터의 MEV 수익에도 규모의 경제가 적용됩니다. 더 큰 규모의 밸리데이터 운영자 혹은 스테이킹 풀 일수록 더 좋은 하드웨어, 고도화된 MEV 전략을 적용할 수 있는 리소스가 있으며, 더 높은 확률로 블록을 생성할 수 있는 기회를 얻을 수 있습니다. 큰 밸리데이터들은 기회를 독점하고, 솔로 스테이커들은 MEV에 참여하기 어려워집니다. 이처럼 MEV는 밸리데이터를 중앙화하는 압력을 만들고 검열의 위험을 높히기 때문에, 이를 완화하기 위하여 도입된 것이 바로 이더리움의 로드맵 중 하나인 PBS(Proposer Builder Seperation) 디자인입니다.

PBS가 무엇인가요?

Proposer Builder Seperation(PBS)는 밸리데이터의 역할을 블록을 네트워크에 제안하는 프로포저(Proposer) 역할과 블록에 포함될 트랜잭션을 구성하는 빌더(Builder)역할로 분리합니다. 이를 통해 밸리데이터는 빌더에게 더욱 수익성 있는 블록을 구성하는 일을 아웃소싱 하여, 스스로 MEV를 탐색하는 대신 빌더가 만든 블록을 선택하여 제안할 수 있습니다.

이처럼 PBS는 블록 생성을 위한 시장을 생성하여 모든 밸리데이터의 MEV에 대한 접근성을 향상시킵니다. 고 가치의 MEV 블록을 만드는 경쟁은 빌더를 통해 이루어지기 때문에, 밸리데이터는 큰 밸리데이터 운영자나 솔로 스테이커의 구분 없이 항상 가능한 가장 많은 양의 MEV를 가진 블록을 생성할 수 있고 밸리데이터간 MEV 수익이 평준화됩니다.

프로포저와 빌더 두 역할을 모두 보호하기 위하여 PBS는 크게 다음과 같은 속성을 만족하도록 디자인됩니다. 빌더는 경쟁에서 이겼을 때 블록을 생성할 기회를 얻어야 하며, 블록 내용이 공개되었을 때 이가 정식 체인이 될 것임을 확신할 수 있어야 합니다. equivocation attack, 즉 같은 슬롯에서 프로포저가 빌더의 블록을 보고 MEV 기회를 탈취하기 위해 두 개 이상의 상충되는 블록을 제안하는 공격 시도로부터 보호되어야 합니다. 프로포저는 정직하게 블록을 게시하였다면 빌더로 부터 약속한 대가를 지불받을 수 있어야 합니다.

PBS Roadmap

PBS를 구현하는 것에는 크게 In-protocol 과 Out-of-protocol 두 가지 접근 방식이 있습니다. In-protocol PBS는 PBS를 이더리움 프로토콜의 컨센서스 레이어 자체에 통합하는 것을 말하며 현재 이더리움 로드맵이 추구하는 방향이기도 합니다. (In-protocol PBS, IP-PBS , Enshrined PBS, ePBS 모두 같은 의미입니다.) 아래 그림에서 Two-slot PBS, PTC, PEPC가 이에 포함된다고 볼 수 있습니다. Out-of-protocol PBS는 이더리움 프로토콜의 변경없이 PBS가 이더리움 외부에서 작동하도록 하는 것이며, mev-boost, 및 낙관적 릴레이(Optimistic Relay)가 이에 포함됩니다.

현재 이더리움에서는 어떠한 방식으로 PBS를 구현할 것인지를 결정하기 위하여 다양한 디자인들이 논의되고 있습니다. 따라서 본 글은 PBS.day에서 Mike Neuder가 소개한 아래의 Diagram을 바탕으로, 현재 진행 중인 PBS 디자인들과 각 디자인들의 연관 관계 그리고 장단점을 비교해 소개해보려 합니다.

본 글에서 염두해야 할 것은 현재 실행중인 mev-boost 및 낙관적 릴레이 v1을 제외하고는 모두 논의중인 디자인에 불과하며 어떻게 변화할지, 무엇이 채택될지는 알 수 없다는 점입니다. 그럼 이제 각각의 디자인을 한번 살펴보겠습니다.

💡 아래의 내용은 이더리움의 합의 알고리즘에 대한 내용을 포함하고 있습니다. slot, attestation, committee, forkchoice rule 등이 생소하신 분들이라면 DSRV에서 발간한 이더리움 합의 알고리즘 시리즈를 참고하시는 것을 추천 드립니다.

Out-of-protocol PBS

MEV-Boost

mev-boost는 이더리움 프로토콜 변경없이 외부에서 PBS를 구현하기 위해 개발된 오픈소스 소프트웨어입니다. [1] mev-boost를 실행하는 밸리데이터들이 블록 생성 시장에 접근하고 빌더들이 만든 블록을 받을 수 있게 합니다. 이는 ePBS 도입 이전의 일종의 임시 솔루션으로 개발되었지만, 이더리움의 블록의 약 95%가 mev-boost를 통해서 생성되고 있을 만큼 널리 도입되어 있습니다. [2]

mev-boost 디자인에는 크게 세가지 역할이 있습니다. mev-boost를 실행하는 이더리움 밸리데이터인 프로포저(proposer), MEV를 극대화한 블록을 만드는 빌더(builder), 그리고 이 둘 사이에 존재하며 블록 경매를 중개하는 릴레이(relay)입니다. 프로포저는 mev-boost를 통해 릴레이와 상호작용할 수 있습니다. 이들이 블록을 생성하는 과정은 다음과 같습니다.

1. 먼저 빌더가 다양한 주체로 부터 트랜잭션을 받아 블록을 구성하여 릴레이에게 제출합니다. 이 때 빌더는 프로포저가 다른 빌더의 블록이 아닌 자신의 블록을 선택하게 하기 위해, 프로포저에게 얼마를 지불할 것인지를 블록에 포함합니다.
2. 릴레이어는 빌더들로 부터 받은 블록이 유효한지를 확인하고, 빌더들이 프로포저에게 지불할 금액을 계산하여 프로포저에게 전달합니다. 이때 릴레이는 프로포저가 빌더의 블록 내용을 미리 확인하고 MEV 기회를 가로챌 수 없도록, 블록 내용(body 혹은 payload)을 제외한 블록 헤더(header)만을 프로포저에게 전달합니다.
3. 프로포저가 빌더들의 입찰 중 가장 높은 금액을 선택하여 헤더에 사인을 하고 릴레이어에게 다시 전달하면 릴레이는 사인된 헤더와 블록 내용을 합친 완전한 블록을 네트워크에 전파합니다. 블록이 정식 체인으로 실행되면 그 보상이 빌더 및 프로포저에 분배됩니다.

하지만 mev-boost의 매커니즘이 동작하기 위해 빌더와 프로포저는 릴레이를 믿어야 합니다. 빌더는 자신이 만든 블록을 먼저 확인할 수 있는 릴레이가 해당 MEV 기회를 훔치지 않을 것이라는 것을 믿어야 하고, 프로포저는 릴레이가 자신에게 유효한 블록의 헤더를 전달하고, 자신이 사인한 헤더에 대한 블록을 제 시간에 네트워크에 전파할 것이라는 것을 신뢰하여야 합니다.

뿐만 아니라 릴레이는 각 슬롯마다 빌더로부터 제출되는 수백 개의 입찰을 모두 수신하고, 블록 내용을 먼저 검증하고, 블록 내용에 대한 데이터 가용성 레이어 역할을 해야하며, 프로포저가 헤더에 서명한 후 적시에 블록을 네트워크에 전파하여야 합니다. 이 모든 역할을 수행하는 릴레이를 운영하는 것은 많은 비용이 들지만 현재는 릴레이를 위한 별도의 인센티브가 존재하지 않아 공공재로만 운영되고 있습니다.

현재 mev-boost 디자인에서는 릴레이어에 대한 신뢰가 필수적일 뿐만 아니라, 릴레이를 운영하기 위한 진입 장벽이 높아 중앙화 및 검열에 대한 우려가 있습니다. 뿐만 아니라 그리고 릴레이어의 버그로 인해 프로포저가 자금을 탈취하는 사례가 발생하기도 하여 릴레이 및 mev-boost 의 클라이언트 다양성 문제도 대두되고 있습니다.

Optimistic Relay

위와 같은 문제에 따라 제안된 낙관적 릴레이(Optimistic Relay)는 릴레이의 책임과 역할을 점차 축소 시키며 보다 지속가능한 운영을 통해 ePBS(Enshrined PBS)에 점진적으로 도달하는 것을 목표로 하는 디자인입니다. [3] Ultra Sound Money는 기존부터 운영하던 릴레이를 3월부터 낙관적 릴레이로 운영하고 있습니다.

Ultra Sound Money가 현재 운영하고 있는 그 첫 번째 버전은 일단 단순히 기존 mev-boost 과정에서 릴레이의 블록 검증 단계를 제거하는 것으로 시작합니다. 릴레이는 빌더가 유효한 블록을 제출했을 것이라고 ‘낙관적’으로 가정하고, 검증을 생략한 채 블록 헤더를 프로포저에게 전달합니다. 따라서 빌더의 입찰은 기존 릴레이의 검증으로 발생했던 지연시간 없이 바로 낙찰받을 수 있는 상태가 됩니다. 릴레이 또한 모든 입찰된 블록을 다운로드 하고 검증해야 하는 부담이 크게 감소합니다. 하지만 빌더가 유효하지 않은 블록을 제출할 수 있으므로, 현재 Ultra Sound Money의 낙관적 릴레이는 1ETH의 담보를 제출한 빌더의 블록만 검증을 생략하고 있습니다. [4]

낙관적 릴레이는 담보를 통해 검증 단계를 제거하는 것에서 시작하여, 점차 블록을 전파하는 역할에서도 벗어나는 것을 목표로 합니다. 낙관적 릴레이의 마지막 단계는 오라클처럼 기능하는 것으로, 빌더의 블록을 중개하지 않고 그 과정을 지켜보는 역할을 하는 것입니다. 이 단계에서 빌더는 P2P로 프로포저에게 직접 입찰을 제출하고, 릴레이는 프로포저가 낙찰된 헤더에 올바르게 서명했는지 그리고 빌더가 이후 블록 내용을 적시에 게시 했는지 그 유효성을 확인합니다.

이처럼 낙관적 릴레이는 점진적으로 릴레이에 대한 의존도를 축소시키고 최종적으로 릴레이의 유효성 확인 역할을 이더리움 프로토콜 내부의 committee등으로 대체하여 ePBS에 도달하고자 하는 디자인 입니다. 하지만 최근에는 기존에 ePBS가 구현되기 전 임시적으로만 존재할 것으로 간주되던 릴레이가 ePBS 이후에도 계속해서 존재할 수 있다는 의견도 제시되었습니다. 프로토콜 내에서 지원할 수 없는 입찰 취소나 무조건적인 지불 매커니즘에 대한 이점으로 릴레이가 계속해서 역할을 수행할 가능성이 발견되고 있습니다. [5]

In-protocol PBS

Two-slot PBS

21년 7월 비탈릭 부테린이 제안한 Two-slot PBS는 두 슬롯마다 하나의 실행 블록을(exec block) 결정하는 방식이며 ePBS 디자인의 시작이라고 볼 수 있습니다. [6] 이 방식에서는 비콘 블록(Beacon Block)에 더하여 중간 블록(Intermidiate Block)이라는 또 다른 종류의 블록이 생성되며, 기존에 하나의 슬롯에 할당된 attestation committee들도 분할되어 역할에 따라 비콘 블록 혹은 중간 블록에 대한 attestation을 생성하게 됩니다.

위 그림을 통해 그 과정을 살펴보겠습니다.

1. 우선 빌더들이 첫 번째 슬롯이 시작하기 전 프로포저에게 실행 블록의 헤더(header)와 입찰가를 포함한 입찰을 제시합니다. 입찰을 받은 프로포저는 첫 번째 슬롯에서 하나의 입찰을 선택하여, 해당 실행 블록 헤더만을를 포함하여 비콘 블록을 생성하고, 전체 attestation committee중 하나의 committee가 이 헤더를 검증하여 비콘 블록의 attestation을 생성합니다.
2. 비콘 블록에 낙찰된 빌더는 실행 블록의 내용과 최대한 많은 비콘 블록 attestation을 집계(aggregate)하여 중간 블록을 생성합니다. 비콘 블록을 검증한 committee를 제외한 나머지 committee들은 중간 블록을 검증하여 비콘 블록에서 낙찰된 빌더의 블록을 식별하고 attestaion을 생성하여 가중치를 부여합니다. 집계된 중간 블록의 attestation 은 다음 비콘 블록에 포함되며 같은 과정이 반복됩니다.

Two-slot PBS는 빌더가 만든 실행 블록의 MEV 기회가 탈취당하지 않도록 블록 내용을 미리 공개하지 않고 프로토콜 자체에서 이를 검증합니다. 하지만, 기존의 블록 생성 과정이 둘로 나뉘어 블록 타임을 증가시키고, 두 블록에 대해 각각의 포크 선택 가중치가 부여되어 re-org(블록의 실행이 무효화 되는 것)가 발생하기 쉬워져 컨센서스 레이어의 보안성을 약화시킨다는 위험이 있습니다.

Payload Timeliness Commitee(PTC)

Payload Timeliness Commitee(PTC) 디자인은 23년 7월 비교적 최근 제안된 디자인입니다. [7] 이 디자인은 Two-slot PBS와 일부 유사하지만 중간 블록이 아닌, 각 슬롯의 attestation committe의 하위 집합인 새로운 committee, 즉 PTC를 통한 새로운 투표 단계를 도입합니다.

위 그림을 통해 그 과정을 살펴보겠습니다.

1. 빌더들은 슬롯 시작 전 프로포저에게 실행 블록의 헤더와 입찰가를 포함한 입찰을 보내고, 프로포저는 슬롯이 시작되면 낙찰된 빌더의 입찰을 포함한 비콘 블록을 만들어 전파합니다.
2. t1까지 해당 슬롯의 모든 attestation committee가 포크 초이스룰에 따라 비콘 블록에 대한 attestation을 생성합니다.
3. t2에 attestaion이 집계되면, 빌더는 attestation의 유효성을 보고 자신이 만든 실행 블록의 내용을 공개할지 안할지를 판단합니다. 빌더가 내용을 공개한 블록을 full-block, 공개하지 않은 블록을 empty-block 이라고 합니다.
4. t3에서 전체 attestation commitee에서 선정된 일부 밸리데이터로 이루어진 PTC가 해당 내용이 제 시간에 공개 되었는지(full 혹은 empty) PT(Payload Timeliness) 투표를 합니다.
5. t4에 다음 슬롯의 밸리데이터는 이 attestation과 PT 투표에 기반하여, 다음 블록을 어디에 연결하여 생성할 것인지를 결정하게 되고, 이 결정에 따라 낙찰된 빌더의 블록이 실행됩니다.

PTC는 PT 투표의 효과가 단일 슬롯에만 영향을 미치며 별도의 포크를 생성할 수 없고 re-org에 대한 위험이 줄어듭니다. 하지만 빌더가 직접 중간 블록(intermidiate block)을 생성하여 포크 선택 시 proposer boost를 받았던 Two-slot PBS와 달리, 빌더에게 별도의 포크 선택 가중치를 부여하지 않습니다. 따라서 PTC에서는 빌더의 권한을 줄여 빌더가 다음 슬롯의 프로포저의 선택에 따라 자신의 블록 내용을 공개하였는데 실행되지 못하여 손해를 입는 상황을 겪을 수 있습니다. 결국 Two-slot PBS와 PTC는 이더리움의 보안성(re-org resilience)와 빌더의 블록을 보장하는 정도에서 차이가 발생한다고 볼 수 있습니다.

Protocol-Enforced Proposer Commitments(PEPC)

Protocol-Enforced Proposer Commitments(PEPC)는 22년 8월 Unbundling PBS라는 글에서 처음 제안된 디자인입니다. [8] PEPC는 프로포저와 빌더 사이에 프로그래밍 가능한 계약을 체결할 수 있다는 가능성을 통해, ePBS 같이 전체 블록(full-block)에 대한 경매 하나로 블록을 만드는 방식을 고정하는 것이 아닌 전체 블록, 부분 블록(partial-block), 미래 슬롯에 대한 경매나 crList등 다양한 방식으로 블록을 만드는 보다 일반화된 PBS를 목표로 합니다.

PEPC는 더 많은 가능성을 열기 위하여 EigenLayer같은 프로토콜을 기반으로 프로포저와 빌더가 이더리움 외부에서 Proposer Commitment(PC)라고 하는 약속을 할 수 있게 합니다. 이 PC는 ’x슬롯에 y빌더의 블록을 생성한다’ 와 같은 내용이나, 혹은 더 다양한 조건이 달린 내용이 포함 될 수 있습니다. PC를 통해 이루어지는 PEPC의 블록 생성 과정은 Two-slot PBS와 유사하게 commit phase와 reveal phase로 나누어 집니다.

💡 간단히 소개하자면, Eigenlayer는 스테이킹된 ETH를 재스테이킹(Re-staking)하여 다른 서비스의 밸리데이터로도 참여하여 이더리움 스테이킹 보상 뿐만 아니라 다른 서비스들의 추가 보상까지 얻을 수 있게하는 프로토콜입니다. 이더리움 네트워크의 보안을 활용하는 Oracle, Bridge, DA layer, 그리고 PEPC처럼 PC를 위한 레이어 등 다양한 사용 사례로 활용할 수 있습니다.

1. 먼저 commit phase에서 프로포저와 빌더는 이더리움 외부에서 스마트 컨트랙트를 통해 PC를 채결하게 됩니다. 빌더는 블록 내용의 가용성을 증명할 수 있는 특정 해시와 입찰가를 프로포저에게 보내고, 프로포저는 자신의 슬롯에 해당 해시가 증명하는 블록을 만들겠다는 약속, 즉 PC를 포함한 커밋 블록(commit-block)을 만듭니다. 커밋 블록에는 비콘 블록과 유사하게 이전 블록의 attestation과 같은 컨센서스 레이어의 정보가 담길 뿐만 아니라 PC와 payload template라고 하는 낙찰된 빌더의 블록 내용이 들어갈 수 있는 자리가 포합됩니다.
2. reveal phase에서 커밋 블록에 포함된 PC의 유효성을 확인한 빌더는 커밋 블록의 payload template을 채웁니다. 이후 프로포저가 완전한 커밋 블록을 전파하면 attastation committee가 해당 블록의 유효성을 판단하여 투표하고, 포크 초이스룰에 따라 정식 체인이 됩니다.

중요한것은 약속이 잘 체결되었는지 그리고 올바르게 이행 되었는지 블록의 유효성(validity)을 체크하고 어떻게 약속을 지키도록 강제할 것인가 일 것입니다. 프로포저가 체결한 PC를 어기는 상황에는 두 가지 방식으로 접근할 수 있습니다. 첫번째는 낙관적(optimistic) 접근으로 프로포저가 약속을 지키지 않을 경우 추후에 슬래싱을 하는 방식입니다. attestation committee는 프로토콜 외적으로 커밋 블록의 유효성을 판단하여 투표하고, 옳지 않은 블록 생성에 동조한 밸리데이터는 Eigenlayer 매커니즘에 따라 슬래싱됩니다. 하지만 약속 위반으로 인한 슬래싱 보다 이익이 더 큰 경우나, 매우 복잡한 약속을 입력하여 유효성 검증을 어렵게 하는 공격의 가능성이 있습니다.

💡 최초 게시물에서는 Eigenlayer에서 슬래싱된 밸리데이터의 잔액을 이더리움 컨센서스 레이어에서 파악하기 어렵다는 문제점 때문에 Eigenlayer의 매커니즘을 프로토콜 내부의 컨트랙트로 포함시키는 방안(aka IP-Eigenlayer)이 제안되었습니다. 하지만 최근 PEPC FAQ 게시물에서는 이가 스마트 컨트랙트가 컨센서스 레이어 업데이트를 수행할 수 있도록 하는 EIP-7002를 통해 해결될 수 있다고 말했습니다.[9]

따라서 PEPC는 프로토콜 자체에서 약속을 충족하지 않는 블록을 유효하지 않은 블록으로 간주하도록 하는 비관적(pessimistic) 접근 방식을 추구합니다. 이를 위해서는 PC가 EVM에서 실행 가능한 코드로 표현되어 attestation committee가 이더리움 프로토콜에 내장된 방식으로 유효성을 확인하여 투표할 수 있어야 합니다. zk proof를 사용하는 방식 등도 언급되었으나 결정된 바는 없습니다.

어떤 디자인이 선택 될까?

mev-boost 및 낙관적 릴레이는 릴레이 역할로 인한 중앙화 및 검열의 가능성이 존재하며, mev-burn이나 crList와 같은 ePBS를 기반으로 하는 매커니즘과는 호환될 수 없습니다. 하지만 이들은 현재 실행되고 있는 매커니즘이며, mev-boost 릴레이의 변형인 낙관적 릴레이 같이 프로토콜 내부의 변경보다는 상대적으로 더 가볍고 빠르게 새로운 시도를 할 수 있다는 장점이 있습니다.

Two slot PBS 나 PTC는 릴레이 역할을 제거하여 릴레이로 인한 다양한 문제를 수반하지 않습니다. mev-burn이나 inclusion list와 같은 ePBS를 기반으로 하는 매커니즘, 즉 이더리움 로드맵과도 호환됩니다. 하지만 이더리움 컨센서스 수준의 변경이 필요하여 보다 신중해야 하고 구현에 시간이 듭니다. 따라서 디자인이 한번 구현되고 나면 변경도 어려울 뿐만 아니라 하나의 방식이 프로토콜에 의해 강제되기 때문에 유연성이 낮습니다.

PEPC는 일반적인 ePBS와는 조금 다르게 외부 레이어를 활용하지만, 블록 유효성 확인에 프로토콜 변경이 필요할 수 있다는 점에서 ePBS 완전히 분리해서 바라보기는 어렵습니다. 하지만 PEPC는 다른 디자인들에 비해 아직 밝혀지지 않은 가능성이 너무나 많은 디자인 입니다. 오늘 소개한 PEPC 외에도, out-of-protocol 디자인으로 mev-boost Relay를 통해 이루어지는 PEPC-boost나 DVT를 사용하여 프로토콜 외부에서 유효성을 검증하는 PEPC-DVT등 최근 PC를 사용하는 여러가지 PEPC의 버전들이 등장하기도 하였습니다.

오늘은 현재 이더리움에 있는 다양한 종류의 PBS 디자인들을 소개해 보았습니다. 각각의 디자인이 추구하는 바와 장단점이 다르기 때문에 쉽사리 어느 것이 선택 될지 예측하기는 무척 어렵습니다. 뿐만 아니라 새로운 디자인, 개선안들도 제안되고 다양한 가능성 아래 논의가 이루어 지고 있기 때문에 계속해서 지켜봐야할 주제인 것 같습니다. 이더리움의 MEV 생태계의 미래에 관심이 있으신 분들께 도움이 되었길 바라며 읽어주셔서 감사합니다.

Written by
Youngbin Park, Research Engineer, DSRV Validator Team (Twitter @bin0_0bin)

Reference

[1] https://github.com/flashbots/mev-boost
[2] https://mevboost.pics/
[3] https://github.com/ultrasoundmoney/mev-boost-relay/blob/prod-optimistic-relaying/docs/optimistic/an-optimistic-weekend.md
[4] https://github.com/ultrasoundmoney/mev-boost-relay/blob/prod-optimistic-relaying/docs/optimistic/event-log.md
[5] https://ethresear.ch/t/relays-in-a-post-epbs-world/16278
[6] https://ethresear.ch/t/two-slot-proposer-builder-separation/10980
[7] https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054
[8] https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879/4
[9] https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4