How to remove relays?

It has been almost two years since MEV-Boost was introduced to the Ethereum network. Since the network transitioned from PoW to PoS with The Merge upgrade, MEV-Boost has facilitated approximately 526,000 ETH worth of MEV (currently valued at $1.34 billion). In fact, around 90% of Ethereum blocks are now provided through MEV-Boost, making it an integral part of the network.

However, with every advantage comes a drawback. To enhance the efficiency of validators and block builders and prevent malicious behavior, Flashbots introduced a centralized entity called a relay into the MEV-Boost. While this improves trust and security, it also introduces new trust assumptions, sparking discussions within the Ethereum community about solving the centralization issue of relays. This article will explore ideas such as Optimistic Relays, MEV-Boost++, and the newly proposed TEE-Boost.

1. MEV-Boost Overview

1.1 Introduction

MEV-Boost is middleware developed by Flashbots to mitigate the negative externalities of MEV in the Ethereum PoS network. By using MEV-Boost, validators can outsource the block-building process to block builders, selecting the block with the highest bid. This provides two key benefits to the Ethereum network:

• Reducing network congestion: Previously, MEV competition occurred on-chain using the PGA method, causing unnecessary congestion. Now, it has shifted to a private mempool, easing the network load.

• Decentralizing MEV extraction: Even validators who lack expertise in complex MEV extraction algorithms can share in MEV profits by choosing blocks built by specialized builders.

For more detailed information on how MEV-Boost operates, refer to my previous article, “How SUAVE Can Address Builder Centralization.”

1.2 Why Need Relay?

Relays act as intermediaries between block builders and validators in MEV-Boost. They are trusted by both parties, and their roles include the following:

• Preventing MEV stealing: If block builders were to directly provide block payloads to validators, there’s a risk that validators could create identical blocks themselves and steal the MEV. Relays prevent this by ensuring that validators only receive the block header and bid, without revealing the payload.

• Verifying block validity: Relays verify the validity of blocks before validators sign the block header. If validators sign invalid blocks, it could lead to missed slots.

• Ensuring data availability: After validators sign the block header, relays ensure that the block payload is delivered. Without relays, malicious builders could withhold payloads.

• Multiplexing: Relays allow block builders and validators to connect with a large number of counterparties. Without relays, these connections would have to be established manually.

1.3 Why Replace Relay?

1.3.1 Centralization Concerns

Although the situation has improved since the early days, a small number of relays still dominate block mediation in MEV-Boost. Currently, five relays—Flashbots, Ultra Sound (max profit), Ultra Sound (regulated), Bloxroute, and Gnosis—mediate around 90% of Ethereum blocks.

While these relays are operating fairly, what happens if a relay malfunctions or acts maliciously? The first concern is censorship. Relays have the ability to reject certain block builders' payloads. This isn't necessarily malicious but is already happening, as seen with Bloxroute (regulated), which rejects blocks containing illegal transactions in accordance with OFAC regulations.

The second concern is builder-relay collusion. Since relays have censorship power, they could choose to mediate blocks from only specific builders, regardless of bid size. This could increase the influence of certain builders, accelerating builder centralization.

The third issue is MEV stealing. Because relays can view builders' payloads, they could create identical blocks and steal the MEV themselves.

The fourth problem is liveness issues. If relays fail to release the block after validators sign the header, either maliciously or due to malfunction, it could result in an empty slot.

1.3.2 Latency Issues

Even if relays are not acting maliciously, their mere presence introduces latency into the block auction process. Latency arises during two phases: when the relay receives the block from the builder and when it runs simulations to verify the block's validity.

• Delivery latency: This is the time it takes for the relay to download the block from the builder, typically between 10 and 100 milliseconds. The closer the builder is to the relay geographically, the lower the latency, encouraging builders to colocate with relays.

• Simulation latency: This is the time it takes for the relay to simulate the block, averaging between 100 and 200 milliseconds.

Low latency is critical because, within the 12-second block auction window, if delivery latency is too long, there may not be enough time left to run the simulation, excluding the block from the auction.

Additionally, the computational cost of operating relays is quite high. While relays are manageable in the short term, in the long run, if Ethereum is to evolve into a truly decentralized computing platform and optimize block building efficiency, it would be ideal to either decentralize relays further or eliminate the need for them altogether.

2. Proposed Solutions

The Ethereum community has proposed several intriguing ideas to reduce the negative impact of relays or even eliminate the need for them altogether.

2.1 Optimistic Relays

Optimistic Relays aim to retain the presence of relays while significantly reducing latency. Similar to how optimistic rollups assume off-chain transactions are valid and process them accordingly, Optimistic Relays assume that the block provided by the builder is valid and proceed with the block auction. Three different versions of Optimistic Relays have been proposed.

Notably, the Ultra Sound relay has implemented Optimistic Relay v1, leading to increased processing of bids and reduced latency, which has boosted its market share.

2.1.1 v1: Asynchronous Block Validation

In Optimistic Relay v1, the relay does not immediately validate the block received from the builder but does so asynchronously. This significantly reduces simulation latency during the block auction process, effectively lowering overall latency. Additionally, it reduces the operational costs for relays, as they don't need to validate the surge of blocks at the auction's conclusion. To protect against malicious behavior, block builders participating in Optimistic Relays are required to stake a certain amount of funds, ensuring accountability if they attempt to submit invalid blocks.

2.1.2 v2: Header-Only Parsing

In Optimistic Relay v2, the relay receives only the bid details from the builder, rather than the entire block. This reduces the time required to download the block and eliminates the relay's ability to censor transactions since it no longer sees the payload. Similar to v1, builders are required to stake funds to deter malicious actions.

2.1.3 v3: Relay as an Oracle

Optimistic Relay v3 minimizes the relay's role, enabling direct peer-to-peer communication between builders and validators. Validators and builders each listen over the p2p network for header-only bids from builders and for validators' signed headers corresponding to those bids. In this version, the relay acts more like an oracle, detecting missed slots and imposing penalties when necessary.

Moving beyond v3, relays could eventually be replaced by a committee of validators, with these processes enshrined in the Ethereum network. This would bring the Ethereum network closer to achieving the final goal of ePBS (enshrined Proposer-Builder Separation).

2.2 MEV-Boost++ with EigenLayer

Although not primarily focused on relays, EigenLayer has proposed an interesting concept called MEV-Boost++ to address the issues caused by centralized relays. Unlike Optimistic Relays, which have been partially implemented, MEV-Boost++ remains a theoretical idea that has yet to be integrated into the block auction process.

The key innovation of MEV-Boost++ is that it allows validators to support partial block building by re-staking ETH through EigenLayer, in contrast to the current MEV-Boost system, which only supports full-block building.

In the current MEV-Boost system, validators only deal with full blocks because viewing builders' payloads before completing the block could lead to MEV-stealing. However, with MEV-Boost++, validators re-stake ETH through EigenLayer, which introduces slashing penalties if MEV-stealing occurs. This allows validators to inspect the payloads and complete block building by adding their own chosen transactions to the partial block.

MEV-Boost++ could solve two key problems caused by centralized relays:

• Preventing MEV-stealing: Validators face the risk of having their ETH slashed, making it difficult for them to collude with relays for MEV-stealing.

• Censorship Resistance: Even if a censoring relay refuses to process blocks containing certain transactions, validators can add these transactions to the partial block, bypassing the relay's censorship.

3. Enter TEE-Boost

Recently, a fascinating proposal was shared by Shea Ketsdever on the Flashbots forum, suggesting that relays could be completely eliminated by leveraging TEE.

3.1 What is TEE?

TEE, or Trusted Execution Environment, is a secure area within hardware like a CPU, isolated from the rest of the system, where sensitive data can be safely processed. TEEs ensure that trusted code can run securely, even if the external environment is compromised. Notable implementations include ARM’s TrustZone and Intel SGX. An example from daily life is the processing of biometric data, such as fingerprints or facial recognition, on mobile devices within a TEE.

TEE is designed so that even the operating system or programs with administrator authority cannot access the secure area. To verify that the code running inside the TEE is trustworthy, an attestation is used. Through the attestation process, the TEE can be verified as being in a trustworthy state, free from tampering or attacks. In the Intel SGX attestation process, a hash value representing the code and data within the SGX is computed. Additionally, a private key is generated and managed by the hardware, making it easy to prove the integrity of the code.

3.2 TEE + MEV-Boost

Now, let’s explore how combining TEE and MEV-Boost could remove relays.

Builders participating in TEE-Boost would begin by submitting an attestation at the start of each epoch, which validators would then verify. This attestation confirms that the builders are using verified software capable of producing valid blocks.

Subsequently, when builders submit blocks, they only need to generate a much simpler proof. Since builders have already been verified through their participation in TEE-Boost as using valid block-producing software, they need only submit a proof signed with a private key associated with the TEE. Validators can then confirm the validity of the block without needing to fully re-validate the attestation.

Because the TEE proof guarantees the block’s validity, builders don’t need to reveal the block to anyone, including relays. This approach effectively replaces the relay’s roles of preventing MEV-stealing and ensuring block validation. However, TEE-Boost does not entirely replace all relay functions. It doesn’t handle multiplexing (efficiently connecting builders and validators) or prevent malicious builders from withholding blocks. To address these issues, the Flashbots team has suggested some solutions and is seeking feedback from the community.

4. Final Thoughts

MEV-Boost has had a significant impact on the Ethereum ecosystem, with around 90% of the network’s blocks now being generated through it. While MEV-Boost is crucial to the roadmap of Proposer-Builder Separation, the ultimate goal should be to eliminate centralized relays. Similar to how Ethereum scaling solutions include both optimistic and validity rollups, this article explored two approaches for verifying the validity of block builders' payloads: Optimistic Relays and TEE-Boost. Although TEE may not be a perfect solution in terms of integrity, it could serve as a viable interim measure on the path to achieving full PBS.