The risks of vertical integration in MEV-Boost

[guayabyte]

In the implementation of proposer/builder separation (PBS) with MEV-Boost there are still some roles that need to be trusted and there are still some risks of centralization.

The risks get riskier when a single organization plays multiple roles. We are calling this vertical integration.

Let’s make it clear which organizations are taking the most prominent roles, while we explore the system in production, learn from it, and keep building improvements. We have to make sure that trusted roles are minimized, that the organizations taking these roles are being responsible stewards contributing to the exploration towards full permission-less PBS, and alert when a single party is starting to get enough power to manipulate the blockchain.

These are the roles in the system:

• private orderflow source
• searcher
• builder
• relay
• relay monitor
• proposer

Currently, these are the most prominent organizations:
(to be updated as the system evolves and power shifts)

• Flashbots: runs an RPC endpoint to receive private orderflow from searchers, a builder, and a relay.
• Lido: runs a big decentralized network of proposer node operators.
• Coinbase: runs many proposer nodes.

What follows is copied from the initial exploration by @jolene. If you are concerned about a particular combination of roles, or about a particular organization, please share your thoughts.

[guayabyte]

Vertical integration refers to one party controlling multiple components in the block-building supply chain. Below, we lay out what we see as the three most likely (and riskiest) points of centralisation in the system.

We assume that builders will exhibit the characteristics of searchers throughout these scenarios. Of course, naive builders that only build blocks might exist, but it is more likely that they will be gradually out-competed by builders who are inserting their own transactions and providing execution guarantees in exchange for orderflow.

[guayabyte]

Scenario #1: Builder-Relay

The block builder and relay are run by the same party. In general, there is an information advantage here as long as other builders are sending their blocks to the relay.

If the party is acting maliciously, the biggest risk is that the relay communicates information about competing blocks and bundles back to the builder, which then uses this knowledge to front-run other builders.

Malicious Party

Case 1

Bundles are sent to a single builder that uses a single relay, both controlled by the same entity

Is it possible for the party to front-run other builders? Pre-PBS, this seems to be possible, as the Builder API allows validators to make a request to the relay when they are ready to receive a block for a particular slot. It’s possible that the malicious relay can accept blocks from other parties, and then make their own blocks that front-run these.

How likely is this to happen in practice? In this scenario, it would be easy to detect if the competing builders had some exclusive orderflow that the relay-builder shouldn’t know about. This would likely lead to the relay being blacklisted after a short time. If this is done with only public transactions, it is less clear how this could be mitigated.

Case 2

Bundles are sent to multiple builders, which then send blocks to multiple relays. Some of these builders and relays are controlled by one party.

The same malicious behaviour as in Case 1 is possible, however now it is much more difficult to detect and blacklist a malicious relay.

Honest Party

If the builder and relay are operated together by an honest party, there are still some advantages and issues here that do not require them to behave badly.

If the builder and relay are operated by the same party, they could be co-located, so that this builder’s blocks consistently reach its own relay faster than blocks from other builders.

Running both of these components may also draw regulatory scrutiny.

This scenario is particularly important to pay attention to because it is the one that Flashbots is proposing to run.

[guayabyte]

Scenario #2: Builder-Proposer

The builder and proposer are run by the same party, relay is independent. Under PoS without PBS, it is a normal and expected scenario the block building and proposal functions will both be performed by the validator, as the validators are expected to build their own blocks and then propose them to the network. However, issues arise when the proposer is also running a mev-boost style block builder.

Case 1

Proposer owns the current slot and also owns a block builder

The proposer could bypass mev-boost, and just get blocks directly from their own builder. This may be economically sub-optimal, but may have other advantages such as allowing them to have private deals with others looking for inclusion guarantees, or promotional deals in order to gain customers.

Even if the proposer does not bypass mev-boost, the builder can game the auction by just bidding the maximum amount possible to the proposer so that their block is guaranteed to be picked. It doesn’t matter how much they bid as both are controlled by one party.

Case 2

Proposer does not own the current slot

If the proposer does not have the current slot, this should not be an issue. However, we are aware of players that have a lot of stake in the system, so that they propose blocks regularly. Is mev-boost economically the right choice for them, versus running their own builder?

[guayabyte]

Scenario #3: Relay-Proposer

In this scenario, the validator that has been chosen to propose a block and the relay are both run by the same party.

If the party is malicious, the relay could send full blocks to this proposer. The proposer is then able to see, censor, and steal transactions from other parties. Builders who submit their blocks to this relay could also be front-run.

[ywzx]

@guayabyte

Thank you for your post! It is really interesting.

When I checked relayscan, I noticed that bloXroute accounts for 30% of block relay, and bloXroute is also acting as a builder.

MEV-Boost Relay & Builder Stats | relayscan.io

This seems to be the Builder-Relay integration you were concerned about.

Do you know if there are any discussion to address this Builder-Relay integration within Flashbot community?

From my perspective, the lack of incentives for Relayers might be leading to a block relay monopoly by top Relayers.
I’m considering ideas to provide incentives for Relayers.

[Eru_Iluvatar]

There are many parties looking to build vertically integrated searchers-builders-relays-validators. The latency advantage given in the CEX/DEX arb is really huge as it allows to last bid + censor competitors’ txs/blocks.
This is 100% a current risk associated to the stx supply chain design.

[cankisagun]

Relay operations is a public goods model with no real funding mechanism. I guess one approach could be to allocation a percentage of MEV to relayers like Guild for Ethereum Core Devs. I think this should be programmable and enforceable on SUAVE via smart contracts.

Given the value associated with CEX/DEX arbitrage, I think the latency game and the risk of relayer-builder integration will always be relevant.

Also saw this interesting post recently called PROF. The idea is to run a relayer inside an SGX to add private order flow directly through the relayer. Obviously this will introduce some latency