This post outlines some changes to how MEV-Boost works that both allows for improvement in the security and efficiency and the system and would serve as a kind out-of-protocol test for ePBS.
tl;dr: proposer gets a list of optimistic builders ahead of time and queries the directly. This improves efficiency, reduces relay role and moves towards ePBS.
Motivation
In the current design, all block bids must flow through relays before they can reach validators. This introduces additional latency (thus lower revenue) and places additional trust in relays to pass on correct bid information to validators.
However, due to the uptake of optimistic relaying, the relays often hardly provide any meaningful service that justifies these costs as blocks are not being validated before being passed on to validators. The primary role relays in the optimistic setting are playing is slashing misbehaving builders and protecting validator IP information.
Several block builders have discussed deploying their own relays and some already have. Ideally, we avoid a process in which block building becomes a competition to sit in zoom calls to motivate proprietary relays being adopted. This proposal hopefully does avoid that.
MEV-Boost Direct:
- removes the ability for relays to skim value from block bids and more broadly reduces the significance of a role whose existence we would to eliminate.
- removes unnecessary latency, increasing revenue
- implements direct bidding from builder to validator which more closely resembles ePBS
- provides a path to further decentralising the relay
This isn’t anything particularly new since the original optimistic relaying idea was intended to involve into something relay-less.
MEV-Boost Direct
- Just like with optimistic relaying, builders can opt-in to staking their funds in a contract the relay controls. This only needs to happen once, not every slot. A small change here is that builders must also register an endpoint which the validator will later query.
- Just like before, validators choose which relays they trust
For every slot,
-
MEV-Boost queries relays with a unauthenticated
getEndPointscall. Relays respond to this call with a list of(stake, endpoint)for all the staked builders. Alternatively, MEV-Boost could be configured to check contracts on chain for this information. -
The
getHeaderis made to all trusted relays and all builder endpoints received in step 3. Relays behave as normal, responding with their best known headers. Builders also respond with their best headers, however proposers ignore any bids that exceed the builder’s stake. -
As normal, the proposer selects and signs the most valuable header. If the header comes from a builder directly and not via the relay, MEV-Boost sends the signed header to the relay where that builder is staked to protect its IP and for the relay to tell whether the header was signed in time.
-
In the happy case, the block is delivered to the network and the promised payment is made. In the unhappy case, the block is not delivered, not valid or doesn’t make the promised payment. Just like with optimistic relaying, the relay slashes
open route to decentralising the relay
The economics are the same as optimistic relaying so there is no change there. Builders who can’t put down enough capital to do a direct bid can go through the relay that simulates and can vouch for correctness and DA.
There is room to decentralise the relay into a committee, however I left that out of this discussion because it boils down to a latency/security tradeoff that applies to the status quo as well.
Finally, this does require builders to implement some relay functionality, but this doesn’t seem to be qualitatively different from managing their current open bundle submission endpoints.
EDIT:
- the biggest unsolved problem is how to protect against validator IP leakage on the getHeader call.