Maximal Extractable Value (MEV)
Scaling Fairness: Enshrined PBS and the Evolution of MEV
Investigate protocol-level innovations like Enshrined PBS and encrypted mempools designed to decentralize block building and redistribute value.
In this article
The Structural Evolution of Transaction Ordering
Maximal Extractable Value represents the total profit that can be extracted from block production through transaction ordering. In the early days of decentralized finance, this was often limited to simple arbitrage and liquidations. However, as the ecosystem matured, these strategies evolved into sophisticated operations involving frontrunning and sandwich attacks.
The current landscape relies heavily on external middleware like MEV-Boost to manage this extraction. While this solution successfully democratized access to MEV for smaller validators, it introduced new dependencies on trusted relays. These relays act as intermediaries, which creates a point of centralization that contradicts the core principles of blockchain architecture.
Software engineers must understand that the problem is not just about profit, but about network stability and fairness. High MEV rewards can lead to consensus instability if validators have a financial incentive to reorganize the chain to steal rewards. This creates a systemic risk where the economic layer interferes with the security of the ledger itself.
The goal of protocol-level MEV design is not to eliminate extraction, but to manage it in a way that preserves decentralization and ensures the health of the network.
Addressing these issues requires moving from external, trust-based systems to native, protocol-enforced mechanisms. By integrating the separation of roles directly into the consensus engine, we can remove the middleman and create a more robust incentive structure. This transition is known as Enshrined Proposer-Builder Separation, or ePBS.
The Architecture of Out-of-Protocol Relay Systems
In the current MEV-Boost model, the proposer communicates with a relay to receive the most profitable block header. The proposer signs this header without seeing the actual transactions within the block. This blind commitment prevents the proposer from stealing the builder's strategy before it is included in the chain.
If the builder fails to provide the full block body after the proposer signs the header, the slot is effectively lost. This creates a liveness risk that the protocol cannot natively handle. Because the relay is a third party, the blockchain consensus rules have no authority over its actions or failures.
1package main
2
3import "context"
4
5// RelayInterface defines the communication between the validator and the relay
6type RelayInterface interface {
7 GetBestBlockHeader(slot uint64) (Header, error)
8 SubmitSignedHeader(header SignedHeader) (BlockBody, error)
9}
10
11func proposerWorkflow(ctx context.Context, relay RelayInterface, currentSlot uint64) {
12 // Proposer requests the highest bid from the relay network
13 header, err := relay.GetBestBlockHeader(currentSlot)
14 if err != nil {
15 return
16 }
17
18 // Proposer signs the header, committing to this block blindly
19 signedHeader := signHeader(header)
20
21 // Proposer expects the relay to release the full transaction set
22 body, err := relay.SubmitSignedHeader(signedHeader)
23 if err != nil {
24 // If the relay fails here, the proposer cannot produce a block
25 panic("Relay failure: liveness at risk")
26 }
27
28 broadcastBlock(header, body)
29}Enshrined Proposer-Builder Separation
Enshrining Proposer-Builder Separation means integrating the bid-and-commitment logic directly into the Ethereum consensus layer. This removes the need for trusted relays by making the interaction part of the block validation process. The protocol itself ensures that builders are paid and proposers receive valid blocks.
One of the primary challenges in ePBS is the timing of block delivery. Since there is no longer a central relay to guarantee delivery, the protocol must define what happens if a builder fails to reveal their payload. This requires a two-step consensus process where the network first agrees on the winning bid and then on the block content.
This architectural shift significantly changes how developers interact with the consensus layer. Instead of a single block proposal, we move toward a system of conditional commitments. This ensures that the proposer is not punished for builder failures, provided they followed the protocol rules correctly.
Furthermore, ePBS allows for the implementation of sophisticated payout mechanisms. In current systems, payouts are often handled via a standard transaction at the end of a block. Within an enshrined system, the protocol can handle these transfers as internal state changes, reducing overhead and improving security.
Handling Builder Default and Payload Timeliness
When a builder wins an auction but fails to publish the block body, the slot must be handled gracefully. The protocol can detect this failure if the data does not appear on the peer-to-peer network within a specific timeframe. In such cases, the proposer is protected from being slashed for missing their slot.
This mechanism relies on a concept called the payload-timeliness committee. A subset of validators is tasked with observing whether the builder released the block data on time. Their attestations determine if the proposer should be credited with a successful slot or if the slot should be marked as empty.
- The builder submits a bid and a header to the proposer through the P2P network.
- The proposer chooses the winning header and broadcasts it as their proposal.
- The builder must reveal the full block body within a strict time window after seeing the proposal.
- The timeliness committee votes on whether the body was available in time.
- If the committee votes yes, the block is added to the chain; if no, the proposer is not penalized.
Solving Frontrunning with Encrypted Mempools
While ePBS solves the centralization of block building, it does not inherently prevent builders from frontrunning users. As long as transactions are visible in the mempool, sophisticated actors can simulate outcomes and insert their own transactions. Encrypted mempools aim to solve this by keeping transaction details hidden until they are finalized.
In an encrypted mempool architecture, users encrypt their transactions using a public key associated with the network. The transaction is included in a block while still in its encrypted state. Only after the block is committed do the validators reveal the decryption key to execute the code.
This approach fundamentally changes the game theory of MEV. Builders can no longer see the content of transactions to reorder them for profit. They are forced to order transactions based on metadata or arrival time, which drastically reduces the surface area for toxic MEV like sandwich attacks.
Implementing this at scale requires highly efficient cryptographic techniques. We must balance the need for privacy with the need for network performance. If the decryption process is too slow, it increases block times and reduces the overall throughput of the blockchain.
Threshold Cryptography and Distributed Key Generation
Threshold cryptography is a leading candidate for implementing encrypted mempools. In this system, the decryption key is split into multiple shares distributed among the validator set. No single validator can decrypt a transaction on their own.
Decryption only occurs when a threshold of validators, such as two-thirds of the total set, provide their partial decryptions. This ensures that the transaction content remains private until it is too late for a builder to maliciously reorder it. The distributed nature of the key ensures that there is no single point of failure or corruption.
1// This pseudo-code represents the lifecycle of an encrypted transaction
2async function processEncryptedTx(tx, validators) {
3 // Transaction is received in encrypted form
4 console.log("Received encrypted payload: ", tx.data);
5
6 // Wait for the block to be included in the chain at a specific height
7 await waitForInclusion(tx.hash);
8
9 // Collect decryption shares from the validator committee
10 const shares = await Promise.all(validators.map(v => v.getDecryptionShare(tx.hash)));
11
12 // Aggregate shares to recover the original transaction content
13 const cleartextTx = thresholdLib.combineShares(shares, tx.data);
14
15 // Execute the now-visible transaction logic
16 return executeTransaction(cleartextTx);
17}TEE-Based Mempool Privacy
An alternative to threshold cryptography is the use of Trusted Execution Environments like Intel SGX. In this model, the transaction is decrypted and processed inside a secure hardware enclave. The builder can see that a transaction exists but cannot inspect the memory inside the enclave to see what it does.
TEEs offer lower latency compared to threshold cryptography because they do not require a round of network communication for share collection. However, they introduce a hardware dependency and rely on the security of the chip manufacturer. Developers must weigh the performance gains against the risk of hardware-level vulnerabilities.
MEV Burn and Economic Equilibrium
Even with encrypted mempools and ePBS, some forms of MEV like arbitrage between decentralized and centralized exchanges will persist. To further stabilize the network, researchers have proposed MEV Burn. This mechanism captures a portion of the MEV bid and destroys the currency rather than giving it all to the validator.
The logic behind MEV Burn is similar to the base fee burn in transaction pricing. By burning the value, we ensure that the benefits of MEV are distributed across all token holders through deflation. This also reduces the incentive for validators to engage in complex strategies to capture the highest possible MEV, as the marginal gains are reduced.
Implementing MEV Burn requires a reliable way to determine the fair market value of a block's MEV. This is usually done through the auction mechanism in ePBS. The protocol can set a floor price for the bid based on historical data or competing bids, ensuring that the burned amount reflects the actual value being extracted.
Critics of MEV Burn argue that it might lead to off-chain side payments between builders and proposers. If the protocol burns too much of the bid, builders might try to pay proposers directly to circumvent the burn. Designing the burn mechanism requires careful calibration of these economic incentives to prevent the emergence of a shadow economy.
The Impact on Validator Yields
MEV Burn significantly changes the yield profile for validators. Currently, validator income is a combination of issuance and MEV tips, which can be highly volatile. A burn mechanism smoothens this by removing the extreme peaks of MEV income that occur during periods of market volatility.
For institutional stakers, this predictability is often preferred despite the lower total potential income. It makes financial modeling more reliable and reduces the pressure to run complex MEV optimization software. This shift supports the goal of keeping validator hardware and software requirements accessible to a wider range of participants.