The current博弈 between Ethereum's consensus and MEV dates back to the day it transitioned from PoW to PoS...
TechFlow Selected TechFlow Selected
The current博弈 between Ethereum's consensus and MEV dates back to the day it transitioned from PoW to PoS...
Not only is it necessary to design a market mechanism for redistributing MEV, but it is also essential to consider how to further decentralize validators and enhance censorship resistance.
Navigating Web3 tides with focused insightsBy Tia, Techub News
The process of solving MEV is essentially about redefining how block space is allocated. Most people are likely already familiar with MEV, but understanding specific Ethereum MEV governance proposals may still require some background knowledge. This article reviews a series of post-Ethereum PoS transition proposals—such as PBS, ePBS, and PEPC—to provide context on the ongoing efforts to govern MEV.
PBS (Proposer-Builder Separation)
Before the Ethereum Merge, MEV was addressed using Flashbots' MEV-Geth, a modified version of the go-ethereum client. The core idea was to let miners focus solely on mining rather than competing for MEV, thereby avoiding potential chain reorganizations. MEV-Geth introduced a simple market-based solution: miners could select transaction bundles submitted by searchers based on profitability. This elegant market mechanism allowed participants to benefit while also creating mutual constraints. Although searchers had to share part of their profits with miners, they gained security against theft by miners. As searchers became the primary source of profit, miners were incentivized to adopt MEV-Geth and abide by its rules. MEV-Geth maintained a whitelist of trusted miners who could receive bundles; miners caught stealing searcher profits would be removed from this list, thus enforcing reputational accountability.
However, after the Merge, proposers are randomly selected validators rather than miners, making reputation-based enforcement ineffective.
A possible solution is to make block contents invisible to proposers. This concept evolved into Proposer-Builder Separation (PBS), which further decomposes the validator’s role: instead of building blocks themselves, proposers outsource the complex task of block construction—which involves competing for MEV—to specialized entities called builders. Thus, the proposer's job becomes simple: just choose among builder-submitted blocks based on offered payments and propose one.
Initially, Ethereum intended to integrate PBS directly into the protocol at the time of the Merge, but due to complexity concerns, it was postponed—opening the door for MEV-Boost to serve as an interim implementation. Currently, PBS is realized via Flashbots’ MEV-Boost. Besides builders and proposers, another key player exists: the relay. Builders do not send blocks directly to proposers but through a third-party relay.
Additional issues must be resolved—for example, ensuring that builders actually pay proposers and disclose full block content so proposers aren’t penalized for proposing empty blocks, or guaranteeing that proposed blocks are included in the beacon chain. These protections for both builders and proposers are primarily managed by relays.
Builders submit blocks to relays, which rank them by profitability and forward only the header of the highest-paying block to the proposer—ensuring proposers remain blind to block contents. Only after the proposer signs commitment to that header does the relay reveal the full block. Payments from builders to proposers are also secured through the relay. Although payment transactions are embedded within the proposed block, since proposers can't see the content, the relay must pre-validate these commitments.
In-Protocol vs. Out-of-Protocol
To participate in the MEV-Boost market, validators must run not only the standard consensus and execution clients but also a third-party MEV-Boost service external to Ethereum’s core protocol. This is the peculiar reality of today’s PBS: an out-of-protocol entity plays a central role in shaping Ethereum’s consensus formation. From an ownership perspective, this arrangement seems absurd.
This raises questions about the credibility of protocol mechanisms—how trust is established and potentially undermined. MEV-Boost exemplifies this risk: external systems may alter core dynamics when the protocol lags behind market demands. While such external innovations often respond to real needs, their reliability, robustness, and long-term compatibility with the protocol remain uncertain—and they might even compromise it.
Centralized Relays
The most criticized aspect of MEV-Boost is its centralized relay market, which introduces trust assumptions. Builders must trust that relays won’t steal their MEV opportunities. Proposers must trust that the block headers they receive and sign from relays are valid. Yet despite their critical function, relays lack direct economic incentives and incur significant operational costs. Last year, 11 relays supported Ethereum; now only nine remain active.
Notably, relays are not permissionless. For instance, Eden only forwards blocks from its own builder. Others like bloXroute claim to filter frontrunning and sandwich attacks. In effect, relays wield a degree of rule-making power.
Data from Rated Network
From a liveness standpoint, the relay introduces non-atomicity between builders and proposers. If a proposer signs a commitment to a block header and the builder provides the payload, but the relay fails—whether maliciously or accidentally—to deliver it on time, both parties suffer losses.
ePBS: Integrating PBS Into Ethereum
Whether to resolve relay centralization or bring external components on-chain, integrating PBS natively into Ethereum via ePBS appears inevitable. ePBS is no longer just a proposal—it has been assigned EIP-7732 by the Ethereum EIP editors.
ePBS provides a trustless infrastructure enabling proposers and builders to outsource block construction. The previously off-chain builder role is now formalized within the protocol: a subset of validators act as builders and must stake ETH like all other validators. Since ePBS splits the original proposer duties in the consensus layer, modifying the consensus layer is required. Specifically, builders create the execution payload (the final list of transactions to be executed), while proposers are responsible for proposing beacon blocks. The workflow is as follows:
-
After being selected as a Proposer, generate and broadcast an Inclusion List (IL)—transactions that must be included in the slot.
-
Builders send a SignedExecutionPayloadHeader containing the block hash of their proposed execution payload (which satisfies the IL) and their promised payment to the proposer.
-
The proposer selects one SignedExecutionPayloadHeader (typically the highest bidder) and broadcasts the signed beacon block (SignedBeaconBlock).
-
Attesters perform their attestation duties.
-
Aggregators submit attestation aggregates; simultaneously, the winning builder broadcasts the full execution payload.
-
PTC (Payload Timeliness Committee)—a group of 512 randomly selected validators per slot—verifies whether the builder timely revealed the payload and broadcasts the result.
ePBS underwent extensive discussion before receiving its EIP number. Initially proposed by Vitalik in June 2021, the Two-slot design was refined four months later. Three months after that, Single-slot PBS emerged. It wasn’t until July 2023 that the PTC concept was formally introduced.
PEPC (Protocol-Enforced Proposer Commitments)
Of course, not everyone supports ePBS. Alternatives like PEPC offer different visions. While ePBS embeds a fixed set of rules into the protocol, PEPC allows proposers to sell programmable block-building rights.
Proposed by barnabe in October 2022, PEPC argues that if PBS-like mechanisms are to be integrated on-chain, Ethereum should implement a general-purpose mechanism for trustworthy signaling—not one tied to specific promises (e.g., “I’ll return X ETH if you let me build”).
As the name suggests, Protocol-Enforced Proposer Commitments rely on commitments made by proposers within the protocol—commitments that are verifiable on-chain, enabled primarily through the BEACONROOT opcode. This is a more flexible framework: commitments can involve outsourcing the entire block, part of it, or any customizable condition. In essence, proposers sell programmable block space.
Summary
The above covers a brief overview of PBS, ePBS, and PEPC. From a protocol design perspective, creating a new MEV allocation market isn't enough—designers must also consider validator decentralization and anti-censorship properties. Moreover, trade-offs abound. Take ePBS, which now has an EIP number: while it solves the problem of centralized relays, were those external relays purely detrimental? Consider payment mechanisms: relays may actually outperform ePBS here. Under ePBS’s pre-payment model, a builder who creates an exceptionally profitable block cannot offer higher compensation to the proposer beyond what was prepaid—a limitation that doesn’t exist in the current relay-based system.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@News_Techub
