The Ethereum MEV Supply Chain: Understanding Builders and Relays

In the early years of decentralized networks, the process of assembling a block was a monolithic task handled by a single entity. Miners in proof of work systems were responsible for both selecting transactions from the mempool and ordering them to maximize their own rewards. This dual responsibility created a significant barrier to entry for smaller participants who lacked the specialized hardware and sophisticated algorithms required to compete effectively.

As decentralized finance protocols grew in complexity, the opportunities for extracting value through transaction ordering became a multi million dollar market. This phenomenon, known as Maximal Extractable Value, led to high gas wars and network congestion as bots competed for the same profitable opportunities. The resulting instability made it clear that the network needed a more structured way to handle transaction sequencing without compromising decentralization.

The introduction of Proposer-Builder Separation was designed to solve this problem by decoupling the role of the validator from the role of the block constructor. By creating a competitive marketplace for block building, the network ensures that even small home stakers can access the same rewards as institutional operators. This architectural shift protects the consensus layer from the centralizing pressures of high performance optimization.

The primary goal of Proposer-Builder Separation is to maintain a decentralized validator set by outsourcing the computationally expensive task of block optimization to a specialized marketplace.

A block builder operates as a high performance optimization engine that must process thousands of transactions per second. Unlike a standard execution client, the builder does not just follow a simple first in first out logic for transaction ordering. Instead, it runs complex simulations to determine the cumulative impact of different transaction sequences on the final state of the blockchain.

The builder must maintain a private transaction pool where searchers can submit their bundles without the risk of being front run by others. This private channel is essential for maintaining the incentives of searchers who spend significant resources identifying MEV opportunities. If these opportunities were public, they would quickly be exploited by others before they could be included in a block.

Once the builder has identified a profitable sequence, it constructs an execution payload that includes a special transaction paying the validator for the slot. This payment is the builder bid, and it represents the portion of the extracted value that the builder is willing to share to win the right to propose the block. The builder must balance their bid amount carefully to remain competitive while still maintaining a profit margin for their operations.

1func (b *Builder) BuildOptimalBlock(mempool []Transaction, bundles []Bundle) *ExecutionPayload {
2    // Initialize the block template with current state
3    template := NewBlockTemplate(b.currentHead)
4    
5    // First, process high-value private bundles from searchers
6    for _, bundle := range bundles {
7        if err := template.SimulateAndApply(bundle); err == nil {
8            template.AddBundle(bundle)
9        }
10    }
11    
12    // Fill remaining space with profitable public transactions
13    publicTxs := SortByEffectiveGasPrice(mempool)
14    for _, tx := range publicTxs {
15        if template.HasSpace(tx.GasLimit) {
16            template.ApplyTransaction(tx)
17        }
18    }
19
20    // Construct the final payload for the relay
21    return template.ToPayload()
22}

The relay serves as the critical bridge between the competitive builder market and the decentralized validator set. Its primary function is to facilitate an honest exchange where neither the builder nor the proposer can cheat the other. Without a relay, a proposer could see the contents of a builder block and steal the MEV strategy by rebuilding the block themselves.

Relays act as an escrow by receiving the full block from the builder but only sharing the block header and the bid value with the proposer. This blind bidding process ensures that the proposer must commit to a specific block before they are allowed to see the actual transactions inside it. Once the proposer signs the header, the relay releases the full payload to the network for inclusion.

Because the relay is a trusted party, it must perform rigorous validation on every block it receives from builders. It checks for consensus rule violations, ensures all transactions are valid, and verifies that the payment to the proposer matches the builder bid. If a relay fails to perform these checks, it could cause the validator to propose an invalid block and lose their staking rewards.

MEV-Boost is a sidecar service that runs alongside a consensus client to manage the interaction with various relays. It provides a standardized API for validators to register their interest in receiving blocks from the builder market. By using this middleware, validators do not need to modify their core consensus software to participate in the MEV ecosystem.

The communication flow between the consensus client and the relay is defined by the Builder API. This specification ensures that different client implementations can all communicate with the same relays using a unified interface. The efficiency of this protocol is vital for ensuring that blocks are propagated through the network as quickly as possible.

Validators can configure MEV-Boost with specific thresholds to determine when they should accept an external block versus building one locally. For example, a validator might set a minimum bid value of zero point zero five ETH to ensure that they only take the extra risk of an external block if the reward is significant. This level of control allows node operators to balance their profit goals with their preference for network neutrality.

1const registerValidator = async (validatorData) => {
2  // Prepare the registration payload with signing credentials
3  const payload = {
4    message: {
5      pubkey: validatorData.pubkey,
6      fee_recipient: validatorData.feeRecipient,
7      timestamp: Math.floor(Date.now() / 1000),
8      gas_limit: 30000000
9    },
10    signature: await signMessage(validatorData.privateKey)
11  };
12
13  // Submit to the MEV-Boost relay endpoint
14  const response = await fetch('https://relay.example.com/eth/v1/builder/validators', {
15    method: 'POST',
16    body: JSON.stringify([payload]),
17    headers: { 'Content-Type': 'application/json' }
18  });
19
20  return response.ok;
21};

While the current relay based architecture has been successful in distributing MEV rewards, it still relies on centralized intermediaries. The Ethereum community is actively working on a long term solution called Enshrined Proposer-Builder Separation. This upgrade aims to move the auction mechanism and the safety guarantees directly into the core blockchain protocol.

In a protocol native PBS system, the need for trusted relays is eliminated by using cryptographic techniques like committee based validation and data availability proofs. This would allow the network to achieve the same separation of roles without requiring builders or proposers to trust a third party for escrow services. Moving these functions into the protocol layer will significantly improve the censorship resistance and robustness of the network.

For developers and node operators, the transition to enshrined PBS will simplify the software stack required to run a validator. Instead of managing a separate sidecar like MEV-Boost, the auction process will be handled by the same consensus rules that manage staking and attestation. This evolution represents the final step in creating a fully decentralized and permissionless market for block production.