Optimistic Relays and the MEV-Boost Latency War
Introduction
Aestus is an MEV-boost relay committed to principles of neutrality and offered as a not-for-profit public good to the Ethereum ecosystem. After nearly 4 months of operation, we’ve seen over a quarter of the validator set connect to our relay.
This post analyses the current shift to an optimistic mode of operation for MEV-Boost relays, and offers some general commentary on the state and direction of the post-merge MEV-Boost ecosystem. It’s intended to educate and provoke discussion in the wider staking community.
MEV-Boost Architecture in Brief
There are four principle actors in the MEV-Boost ecosystem, as summarised in the diagram below. Central to this architecture is the relay, which serves to coordinate communication between builders submitting bids for blocks, and a connected validator which is next in line to propose. In order to protect the builder from having valuable MEV stolen, a proposing validator signs the header of a block “blind” — without first seeing the transactions it contains. However, this means a proposer is vulnerable to signing an invalid or malicious block, resulting in loss of rewards for that slot. A current core function of a relay is to simulate each block received by a builder on behalf of a proposer, forwarding only those that are valid and dropping the rest. This consolidates trust in the relay, removing the need for builders and proposers to trust each other directly. Failure to properly validate blocks opens relays to attacks like the one on the Manifold relay in October 2022, which resulted in the loss of ~7.47 ETH of value for proposers.
The introduction of this multi stage MEV-Boost architecture introduces latency both in the communication between the parties in this network over the wire, and in the various execution steps along this journey. Transactions must be bundled into a block, forwarded to a relay, simulated (validated), and sent to the validator in time for a proposal. Transactions submitted to the mempool near the end of a 12-second slot are unlikely to complete this process in time for inclusion. This latency is therefore clearly sub-optimal from both an economic perspective as it leaves MEV opportunities on the table, but it also has impact on the Ethereum network — slightly reducing the average time-to-inclusion of transactions.
We would naturally expect to see builders aggressively pursuing strategies to minimise this latency path at every possible step. For example, Aestus is already observing builders co-locate within our hosting data-centre in order to gain a competitive advantage. More extreme is the vertical integration of searchers, builders and relays, often being run by the same entity in the same data-centre — perhaps on the same machine — with reduced simulation requirements.
Optimistic relaying, as per this PR on the mev-boost github and this proposal is another attempt to reduce latency. It provides a mechanism for a relay to skip the simulation step for specific builders, by instead holding a security deposit on behalf of the builder and establishing a set of rules with penalties for bad behaviour. In the event that a builder takes advantage of this system to force a validator to sign an invalid or malicious block, the relay compensates the proposer from the builder’s deposit. With this optimisation, block validation is no longer along the latency-critical path and blocks can be sent to proposers earlier. But, there are complex dynamics at play which need to be understood by all parties involved in PoS consensus on Ethereum.
Benefits of Optimistic Relaying
Large relays receive hundreds of blocks from competing builders over a ~12 second slot which are generally clustered in a very narrow time window — the pivotal second or two near the end of a slot when blocks are most valuable. Simulating this queue of blocks efficiently requires a relay to have significant burstable CPU resources, and sophisticated queue and firewall policies to manage traffic and prevent spam. In an optimistic setup, blocks may be simulated asynchronously over the course of the slot at leisure. In theory, removing this performance requirement will minimize the incentive for relays to compete on reducing validation latency, making relay infrastructure significantly less expensive to operate.
We have been privately informed that some entities have already optimised this pathway and removed the need to simulate slots on a relay, either for their own builders — or for a price. Alternatively, the ultra sound relay has deployed an open optimistic setup, in which all builders can bypass the need to simulate before proposing. Independent relays and builders therefore become more competitive, which should improve the overall distribution of MEV across the network.
If the small edge this optimisation provides translates into a consistent average improvement in competitiveness for builders, then we should expect to see a steady increase in optimistically built blocks. Relays and builders that do not adapt to this new paradigm will lose market share and relevance. Since these optimisations are inevitable in the pursuit of profit, we are therefore glad to see this developed transparently and released in the open.
Considerations for Optimistic Relaying
These improvements do not come for free, and in the remainder of this article we will examine some of the implications of the optimistic relay design.
Bonded Relay-Builder Relationships
In the optimistic paradigm, relays are no longer only cloud infrastructure projects, but become financial entities in their own right: establishing economic relationships with builders, taking custody of assets and the responsibility for reimbursing validators in the event of an invalid or malicious optimistic block. Beyond the financial, this also has significant operational, support, security, and legal dimensions which Aestus has yet to fully explore. In particular, we are concerned that these cooperative financial arrangements could force relays to re-examine the legal risks around compliance with OFAC and KYC regulations. These legal and compliance concerns could force relays and builders to establish formal business arrangements and enmesh a set of sticky and complex relationships.
Some of these concerns may be mitigated by having third-party escrow or by encoding builder collateral and payment systems in a smart contract. However, these ideas are still nascent and will take time to be developed and deployed.
Managing this new set of responsibilities competently requires an expanded in-house skill set and for independent relays without established revenue streams, resourcing these requirements will be challenging without pursuing additional funding.
Capital Requirements for Builders
Builders must provide a security deposit, or bond, with each relay they work with. Blocks they submit with a value higher than that deposit will not be optimistically validated. For honest builders, this collateral is never used, and ties up capital that could otherwise be used to extract higher MEV or otherwise earn yield. Smaller builders may find the collateral requirements to be a barrier to initial entry.
If builders could submit arbitrary amounts of collateral, wealthier builders could afford to deposit more, creating block value thresholds above which the wealthy builders have access to optimistic relaying while smaller builders are forced to take the slower full-simulation path — a centralization vector. At the current stage of the rollout of optimistic relaying on the ultra sound relay, builders are limited to 1 ETH in collateral, creating a single, even transition point from optimistic to simulated submissions, addressing this issue. The vast majority of blocks have a value less than 1 ETH and will be processed optimistically. However, the exceptionally valuable “lottery blocks” make up a disproportionate amount of profit, so competition for them is critical. It remains to be seen if relays will in practise be able to scale back their latency-optimized block validation infrastructure, which is unnecessary for optimistic relaying of <1 ETH blocks, but will continue to be important for the valuable >1 ETH blocks.
At present, many builders simultaneously broadcast their blocks to several relays. Recent changes to the MEV-Boost client also allows a validator to query a block from multiple relays once they receive a bid. This provides some resilience for the ecosystem and can prevent a bug with an individual relay from causing a validator to miss a slot. In the optimistic paradigm we would expect to see this burgeoning resilience diminish. Limited capital and limited operational capacity will presumably push builders towards being very selective in who they work with, optimising for a high deposit at a minimal set of trusted relays, rather than for redundancy.
In general, this new dynamic between relays and builders may effectively establish a walled garden, in which it becomes very difficult for new builders to compete without significant capital and existing relationships, and for new relays to establish themselves when builders have a high marginal cost of establishing an additional relationship.
One additional concern is that inevitable builder pressure to increase collateral limits on any individual relay creates a race to the bottom. Others relays would presumably feel obliged to follow suit in order to remain competitive, effectively leading to the removal of collateral limits altogether. This would clearly provide an enormous advantage to the most well capitalised builders.
Invalid Block Submissions, and Compensation for End Users
MEV-Boost currently allows builders to win a bid for a slot with which they could choose to create an empty block (only including the payment to the proposer), though the rationale for doing so seems fairly limited and this has rarely been seen so far in practice. In the optimistic paradigm, builders could also choose to submit invalid blocks.
In both situations, the builder ends up paying a winning bid for the entire blockspace and delays all other transactions by one slot. We assume that if a builder were to act maliciously, they would generally prefer the former approach, to the latter — so as to avoid demotion from optimistic submission.
But the accidental submission of invalid blocks appears inevitable. Operating as a builder is a never ending race against competitors, requiring an eternal evolution of code to find and win MEV.
Distorting the mempool maliciously by delaying transaction execution using either approach may provide complex economic opportunities that we have yet to imagine. But, whatever the cause — the end result is a disruption to the normal processing of transactions on Ethereum and could impact end users relying on transaction timing. Note that these users have no recourse to compensation. Missed slots are a regular occurrence — the Ethereum protocol and on-chain applications should be robust to them — but if optimistic relaying provides means by which builders can intentionally trigger a missed slot and proposers have no incentive to prevent it, the implications should be thoroughly researched before widespread adoption occurs.
Relays now have a particularly severe obligation to manage this challenge by swiftly identifying offending builders and disabling optimistic privileges. A failure in this mechanism on any relay could be exploited to create a significant disruption to on-chain activity.
Conclusion (TL;DR)
Optimistic relaying has clear advantages in minimising relay infrastructure costs and slightly improving inclusion timing. And beyond the efficiency advantages, managing the simulation queue is in any case a major pain point for relays. The engineering work from the ultra sound team to advance this proposal is impressive, and we’re glad to see it open sourced given that private implementations are spreading and likely to be providing those builders that pay for it with a significant advantage.
Steps to minimise all sources of latency in the MEV-Boost pathway are to be expected, and clearly this is being aggressively pursued by builders. This latency game is ultimately a strong centralising force on the MEV-Boost ecosystem, and the somewhat artificial separation between searcher, builder and relay is already threatened. Optimistic relaying may reduce the need for relays to compete in the latency game, and as a longer plan develops, relays may play less of role.
The potential downsides of the optimistic relaying paradigm are not technical. The concern is that by undermining the original role of a relay as a trusted oracle of block integrity, and instead repurposing it merely as an escrow agent we introduce an additional set of complex trade-offs.
If, in general, this optimisation increases competition amongst builders so as to increase the proportion of MEV that is captured by validators, then perhaps from a network perspective it is desirable. However, it is quite unclear that it will do so. Open optimistic relaying will likely improve competitiveness for already well-established independent builders. But the danger is that instead we accidentally cooperate in building what increasingly looks like a permissioned walled garden where the effective cost of entry for builders with limited capital and operational capacity becomes exorbitant, and the increased costs of running a relay in the absence of incentives only entrenches vertical integration. Instead of a rich network of independently operated relays and builders operating trustlessly — our vision of a healthy space — we may instead provoke a scenario where a limited cast of builders and relays must tightly cooperate off-chain and out of protocol: creating business arrangements, specifying SLAs, undertaking AML/KYC arrangements, and signing legal agreements.
But if this optimisation is indeed inevitable, then what can be done to foster builder competition and encourage the genesis of more independent relays, while minimising the role of trust and reputation in the MEV-Boost ecosystem? Funding relays to provide them with viable economic independence is one crucial component in pushing back against these centralising forces. Public goods funding for this may alone be sufficient, but the option of rewarding relays within the MEV-Boost protocol should at least be examined as this would on first glance, appear to directly incentive a relay to improve competition amongst builders.
While we have concerns about the potential impact of optimistic relaying and the general direction of the MEV-Boost ecosystem, one hopes that this only a transitionary stage as we look towards proper in protocol proposer builder separation. For Aestus to remain relevant, we need to be competitive. As such, we are making plans to adopt the optimistic relaying paradigm so we can continue to serve as a neutral and independent relay.
