Exploring the Impact of MEV Relays

---

Introduction

The process of generating blocks on the Ethereum network is well-known, however a number of its features changed on 15th September 2022 when the Ethereum consensus and execution chains merged. In particular, the merge came with support for outsourcing block building. The theory behind outsourcing block building is that external parties may have requirements such as inclusion of specific transactions for which they are willing to pay a premium, but these transactions are sensitive in that if they were made available publicly their value to the external party would be significantly less. As such, validators are encouraged to sign blocks without knowing their transactions in return for the higher rewards. To obtain these outsourced blocks requires interaction with middlemen that on the one hand deal with those generating the transactions and the other on those signing the blocks: the middlemen are called "MEV relays", and they provide blocks at the cost of additional complexity in the building process. This article examines the changes in the block building process, the additional time using MEV relays requires, and the impact of this process on Ethereum as a whole.

---

Block inclusion time

The block inclusion time (hereafter just "block time") is the time from the beginning of a block's slot to the time at which the block has been incorporated into a local node's chain. It includes the time to generate the block, propagate it around the network until the node receives it, verify the block for correctness, and update the local node's state with the information in the block.

Higher block times on the network can have detrimental effects on the stability of the chain, as explored below.

---

Why does the merge affect block times?

Block generation prior to the merge was a relatively simple affair¹ consisting of interaction between a validator client (that managed the validator) and consensus node (that managed the consensus chain):

Figure 1: Block generation process (pre-merge)

The steps in the process were:

1. The validator client requests a block from the consensus node
2. The validator client signs the block
3. The validator client sends the signed block to the consensus node
4. The consensus node broadcasts the signed block to the network

With the introduction of the merge the block was expanded to include information required by the execution node², and this increased the complexity of the block generation process by including an additional step:

Figure 2: Block generation process (post-merge)

The new process is:

1. The validator client requests a block from the consensus node
2. The consensus node requests an execution payload from the execution node and incorporates it into the block
3. The validator client signs the block
4. The validator client sends the signed block to the consensus node
5. The consensus node broadcasts the signed block to the network

In addition to the lengthier process, the resultant block is also significantly larger. A larger block takes longer to broadcast to the network, and longer to verify when it is received. These factors slow down the propagation of the block through the network, with each node having to do more work before it can pass it on to its peers.

---

Why does MEV affect block times?

Concurrent with the merge itself came the advent of MEV relays. There are two critical differences with MEV relays compared to the building process pre-merge. First, the relays are not controlled by the validator and are situated on physically remote servers. Second, the relays release information to the consensus node in stages, requiring additional back-and-forth before the block can be broadcast.

Figure 3: Block generation process (post-merge with MEV)

The process is now:

1. The validator client requests a block without transactions, known as a "blinded block", from the consensus node
2. The consensus node queries multiple MEV relays for their best bid (a bid being a promise to provide transactions worth a certain amount of Ether)
3. The consensus node selects the best bid and incorporates it into the returned blinded block
4. The validator client signs the blinded block
5. The validator clients requests the consensus node to unblind and broadcast the signed block (unblinding being the process of including the transactions in the block)
6. The consensus node requests the winning MEV relay to unblind the signed block
7. The consensus node broadcasts the signed unblinded block to the network

Note that this is the block generation process assuming that it succeeds at each stage. Because the MEV relay is remote and not under the control of the validator it is possible for it to fail unexpectedly at any stage, in which case the validator client may or may not be able to abandon the process and restart with the prior process (albeit having lost time going through it to the point of failure).

The additional complexity and steps involved with block generation after the merge, both with and without MEV relays, should be visible in the blockchain statistics. To test this, data was gathered.

---

Data gathering

A number of mainnet beacon nodes, running different client software and distributed geographically, were monitored by probed. The monitor obtained, for each beacon node, the time at which each block was incorporated into the local chain. This time was recorded as the "block time".

Data was gathered for 7,200 slots from 4,654,799 to 4,661,998, which were all of the slots on 9th September 2022 (UTC). This date was approximately one week prior to the merge. 7,116 of the slots contained blocks. For each block the median block time across all nodes was recorded, and from this a distribution of block times could be made, as shown below.

An alternative way of looking at the data above is to consider the percentage of blocks that arrived within a given time frame:

Block time	Percentage of blocks
≤ 1 second	80.97
≤ 2 seconds	97.99
≤ 3 seconds	99.42
≤ 4 seconds	99.87

This data gathering was repeated for 7,200 slots from 4,755,599 to 4,762,798, which were all of the slots on 23rd September 2022 (UTC). This date was approximately one week after the merge, and the same day of the week (Friday) as the previous data set. 7,167 of the slots contained blocks. Again, the block time was recorded and a distribution charted:

Block time	Percentage of blocks
≤ 1 second	26.89
≤ 2 seconds	84.85
≤ 3 seconds	97.96
≤ 4 seconds	99.36

---

Analysis

It is clear that block times are significantly different between the pre-merge and post-merge results, with post-merge blocks taking longer to produce. However, as we know there are two separate factors that may contribute to this additional time: the additional work due to the merge, and the additional work due to MEV relays. To attempt to understand the relevance that each factor plays it is required to break out the post-merge blocks to those that involved MEV relays and those that did not.

Of the 7,167 blocks proposed on 23rd September, 2,413 were confirmed to use MEV relays to propose the block with the remaining 4,754 assumed to be locally built. The distribution for the blocks not using the MEV relays is below:

Block time	Percentage of blocks
≤ 1 second	40.16
≤ 2 seconds	93.08
≤ 3 seconds	98.78
≤ 4 seconds	99.52

The information here can be compared directly with that presented in figure 4 to see how the merge has impacted block times. It is clear that block times have increased, with the average block time increasing significantly from 0.78s to 1.21s.

Block time	Percentage of blocks
≤ 1 second	0.75
≤ 2 seconds	68.63
≤ 3 seconds	96.35
≤ 4 seconds	99.05

Comparing this information with that presented in figure 6 it is clear that there is a further increase in the time taken to produce blocks, with the average block time increasing even further to 1.88s.

---

The impact of MEV relays

The longer it takes for a block to be built, propagated around the network, and incorporated into all of the beacon nodes' chains, the less time there is for validators to attest to that block and, in turn, have their attestations propagated and ready to be part of the next block. Given that we have seen above that blocks are arriving later when using MEV relays than without, is there any noticeable impact?

Firstly, looking at the number of attestations for blocks with and without MEV there is a noticeable decrease in the average of number of votes for blocks provided by MEV relays compared those built locally. Within the post-merge blocks there were an average of 13,534 votes per block without MEV compared to an average of 13,304 votes per block with, which is an approximate 2% decrease.

Secondly, looking at the contents of the validator's vote within the attestation provides a further issue. Validators vote for what they consider to be the head of the chain i.e. the latest valid block on the chain. If a block is delivered late then it results in the validator voting for the "wrong" block, because its view of the chain at the time it voted was not yet up-to-date. The average percentage of votes with incorrect votes for blocks supplied by MEV relays was slightly over 2%, compared to slightly under 1% for those built locally.

The combination of the two items above gives an impact of around 3% in terms of the number of correct attestations that make it on-chain for blocks supplied by MEV relays versus locally built blocks. This is a significant decrease in the overall performance of the chain now, and as of the data gathering period only around one third of validators were using the MEV relays, with the rest building locally. Given the potential gains from using MEV relays, they are likely to increase in popularity and result in a higher percentage of missing or incorrect attestations. The impact is also likely to increase as more validators are added to the network, due to the work to obtain and verify the additional votes resulting in blocks taking longer to verify.

What can be done about this? It is inevitable that the introduction of block relays increases the time taken to build blocks, however there are areas that could be improved upon to reduce their impact. One area that needs continual improvement is storage and retrieval of bids, to ensure that MEV relays are as responsive as possible. Another is to move from JSON (a text format that is easy to read but verbose) to SSZ (a binary format that is unreadable to humans but much more compact) as the primary format for data moving between consensus nodes and MEV relays, reducing both size and encoding/decoding time.

The most important improvement, however, should be within the Ethereum protocol to handle the situation where blocks are delivered late to consensus nodes. In this situation the late block should be considered invalid by the local node unless and until enough other validators have voted for it. This would ensure that the potential benefits of fetching blocks with additional rewards from remote MEV relays have to be balanced against the potential losses if the block is not included on-chain, allowing for a more nuanced approach to block selection than is required today.

Footnotes

1. In this and future diagrams some elements of the block building process are elided or combined, however the diagrams capture the important parts of the process. ↩

2. See this article for more details of the merged block structure. ↩