Let’s agree that decentralization of Ethereum is one of the most important properties for its success. The purpose of Ethereum is not ensuring highly profitable rent for permanently centralized, trusted intermediaries.
Your argument rests on two premises:
- Simulation costs are inherently high and removing MEV monetization makes block building economically unsustainable.
- Without profit incentives, transaction flow will fragment into private lanes, increasing centralization.
Both premises appear to mischaracterize the actual cost structure and market dynamics.
Cost Structure
The computational burden isn’t inherent to block building – it’s an artifact of current market structure. Block construction resembles a knapsack problem, but the complexity stems from volume (n) rather than algorithmic difficulty.
Current MEV infrastructure processes millions of redundant transactions because searchers must defensively submit to avoid missing opportunities. This creates artificial load:
- Multiple searchers target identical opportunities (arbitrage, liquidations)
- Each submits defensively, assuming others will too
- Builders process orders of magnitude more transactions than ultimately execute
- The actual computational work per transaction remains trivial
With protocol-enforced revert protection, the submission pattern changes fundamentally. Searchers can submit with confidence that failed transactions won’t cost them, with observation of others’ bids. While some may elect to use private pools (i.e. the existing infrastructure of relayers), a sufficient amount of searchers will optimize for maximum propagation over bid privacy. Further, propagation based flow control naturally reduces spam by creating constraint on transaction volume. Flow naturally reduces to actual opportunities rather than probabilistic spam.
The notion that block building requires datacenter-scale infrastructure misunderstands where value accrues. Current MEV providers don’t provide computational power – they provide reputational guarantees about transaction inclusion. The technical requirements for transaction simulation and ordering are modest; what’s expensive is maintaining trust relationships and network effects. The trust relationships have been required since any leakage of bids/transactions will cause costly revert.
The margin for MEV intermediaries largely goes to bribing validators, it doesn’t go into servers for builders. The server cost for builders’ simulation is an infinitesimal rounding error.
Private Lanes
The private lane concern inverts the current reality. Today’s MEV infrastructure already operates through private channels – builders/relayers and similar services are, by definition, private transaction pools separated from public mempools.
Searchers use these private channels for one reason: without revert protection, public submission risks paying for failed transactions. Ostensibly some claim the desire to hide strategies, but strategies at this point are well known and obvious (since you can look at on-chain history), unique strategies are definitionally rare and irrelevant. When multiple searchers target the same opportunity, only one succeeds while others pay for reverts. This economic reality forces rational actors into private pools.
EIP-7640 addresses this at the protocol level. With consensus-enforced revert protection:
- Searchers can safely broadcast to public networks (using existing p2p infrastructure, no new tokens or validator sets required)
- Competition occurs through transparent gas pricing
- Failed transactions don’t incur costs
- The economic rationale for private pools disappears
This doesn’t eliminate sophisticated block building – builders can still optimize transaction ordering if validators don’t want to do it themselves. But it removes the gatekeeping function where intermediaries control access based on trust relationships. The distinction is critical: optimization services can compete on merit, while trust-based gatekeeping creates monopolistic bottlenecks. Relayers and builders do not need to be a trusted, centralized, priestly class.
Implementation Mechanics
Consider a concrete scenario: five searchers identify an arbitrage opportunity. Currently:
- All five submit to builders (often through relay services) to avoid revert costs
- Builder selects the highest value transaction and constructs an optimal block
- Builder includes winning transaction, excludes the four others, sends complete block to relay
- Relay sends only block header to validator, withholding full block data
- Validator blindly commits to the block header without seeing contents, trusting the relay to reveal valid block data after commitment
- Builder captures MEV value, pays most (~90%) to validator through proposer payment, relay provides trust infrastructure
There are a few notable security risks with this form of centralization. Specifically, the relayer/builder can withhold the block data, they can construct bad block data (reverted txes when they promised not to do so, or coercive censorship), and they are in a privileged position to front-run searcher transactions (getting flash trading data and selectively frontrunning searchers). Secure Enclaves/TEEs merely delay the relayer/builder frontrunning problem, as TEEs are highly vulnerable as they are on-premises to the attacking relayer/builder (stealing millions/billions over time is too lucrative to assume security of TEEs held at the potential attacker’s data center).
With EIP-7640:
- All five submit to public alt-mempools with revert protection flags, flow is gated by address stake-weight
- Validators naturally select the highest gas bid, or use public builders which help construct blocks
- One transaction executes, four get dropped/ignored without cost
- No closed intermediary captures value for trust provision
While existing builders may still exist, you can move traffic into public lanes to compete, and even the existing relayer/builder infrastructure can be more open (reduced trust between builders and relayer, with the possibility of removing most of the trusted roles of the relayer entirely).
This architectural change has downstream effects on builder infrastructure. Currently, builders require relay partnerships because transaction gossip risks revert costs for searchers. Remove that risk at the protocol level, and builders can share transactions without trust requirements.
The result is a more competitive builder ecosystem. New builders can enter without establishing relay relationships. Existing builders compete on optimization quality rather than trust networks. The entire MEV supply chain becomes more permissionless and competitive.
Note that this doesn’t eliminate the need for block construction – optimal ordering still provides value. But it transforms block building from a trust-gated activity to an open competition based on technical merit. The economic rent currently extracted for trust provision gets competed away, benefiting users and the wider ecosystem instead of trusted intermediaries.
This tiny change enables the Ethereum ecosystem to build tooling which reduces dependence upon permanently entrenched participants responsible for truthfully and correctly relaying transactions/blocks.