Muxing in mev-boost to handle diverse relay sets

Research
1

Hello everyone, and thanks for the space to share some thoughts.
This is Paco from Stakely, a staking infrastructure provider running around 9,000 validators on Ethereum mainnet for different protocols and customers.

Right now, each protocol or customer defines its own authorized relay list. This already increases costs, since validators from different protocols cannot always be served properly by a single CL/EL server. This forces us to deploy a new CL/EL setups for each combination of relays and validators we need to support. It also prevents any reuse of CL/EL servers in case of failures and increases the risk of human error during maintenance.

In the future, with the evolution of preconfirmations, it is expected that each protocol will also define how preconfirmations must be negotiated and with which parties. These sets will not necessarily overlap. This will affect both large operators and home stakers participating in protocols such as Lido CSM, Stader, Rocket Pool, and others.

Because of this, I think it would be extremely useful to implement relay muxing in mev-boost, so that a single mev-boost instance can apply logic depending on which validator is making the request. This way, sets of validators could be associated with sets of relays and preconfirmation providers.

It would be great for Ethereum to see mev-boost evolve in this direction.

1 Like
2

Hello,

+1 to this feature, we (Kiln) operate around 60K validators and having a way to have sets of keys target different sets of relayers is important at scale, this is the reason why we pushed for this feature in commit-boost (and why we use commit-boost in production).

We did an initial attempt a few years ago in mev-boost in this PR but it didn’t make it. To give more light on what it solves there is some explanation here as well in the commit-boost community call.

At a high level, the mev-boost’s config could look like defining policies:

policies:
    - name: "lido-policy"
      relayers:
      - name: relayer-1
        url: ...
        http-header: ...
      - name: relayer-2
        url: ...
        http-header: ...

And later using them:

mappings:
    - name: "default"
      policy: "all-relayers"
      filters:
          public_keys: ["0x..", "0x...", ...]   
    - name: "lido-keys"
      policy: "lido-policy"
      filters:
          public_keys: ["0x..", "0x...", ...]

Commit-boost supports multiple filters like, lido_node_operator_id, (will fetch all lido keys for the operator so you don’t have to specify the full list of keys), ssv_operator_ids, you can imagine other types of filters as well.

I’m unsure how this will play out with ePBS as it’s unclear what’s coming up at this stage.

1 Like