# MEV-Boost workshop 09/12/2021

Recording:
{%youtube ivcI_plFu1o %}

## architecture


### design goals

| | MEV-Geth | MEV-Boost | PBS |
| ------------------------- |:--------:|:---------:|:---:|
| Blockspace auction | ✅ | ✅ | ✅ |
| Full block bids | ❌ | ✅ | ✅ |
| Solo staker participation | ❌ | ✅ | ✅ |
| Client diversity | ❌ | ✅ | ✅ |
| Complete privacy | ❌ | ⚠️* | ✅ |
| Trustless | ❌ | ⚠️* | ✅ |

* complete privacy and trustlessness is partially improved by mev-boost because trusted counterparties is changed from relay + miner to only relay

### network topology

The system is designed to have multiple redundant parties play each role.


### validator setup

Dashed components are new components introduced by mev-boost.


### sequence diagram

participant network
participant consensus
participant mev_boost
participant execution
participant relays
Title: MEV-Boost Block Proposal
network->consensus: votes, attestations & new blocks
consensus->mev_boost: `engine_forkchoiceUpdatedV1`
mev_boost->execution: `engine_forkchoiceUpdatedV1`
mev_boost->relays: `engine_forkchoiceUpdatedV1`
Note over consensus: wait for allocated slot
consensus->mev_boost: `builder_getPayloadHeaderV1`
mev_boost->execution: `engine_getPayloadV1`
mev_boost->relays: `builder_getPayloadHeaderV1`
Note over mev_boost: select most valuable payload
mev_boost-->consensus: `builder_getPayloadHeaderV1` response
Note over consensus: sign the block
consensus->mev_boost: `builder_proposeBlindedBlockV1`
Note over mev_boost: identify payload source
mev_boost->relays: `builder_proposeBlindedBlockV1`
Note over relays: validate signature
relays-->mev_boost: `builder_proposeBlindedBlockV1` response
mev_boost-->consensus: `builder_proposeBlindedBlockV1` response
consensus->network: propose block

## milestones

See [mev-boost repository](https://github.com/flashbots/mev-boost).

1. **kintsugi compatibility (mid december 2021)**
simple middleware logic with minimal consensus client changes, simple networking, no authentication, and manual safety mechanism
3. **security, authentication & reputation (end of january 2021)**
cleanup consensus client and add security fallbacks
5. **privacy (optional / tbd)**
add p2p comms mechanisms for validator IP obfuscation
7. **configurations (optional / tbd)**
add optional configurations

| Milestone | 1 | 2 | 3 | 4 |
| ---------- |:---:|:---:|:---:|:---:|
| mev-boost | ✅ | | | |
| mergemock | ✅ | | | |
| lighthouse | ✅ | | | |
| prysm | | | | |
| teku | | | | |
| nimbus | | | | |
| lodestar | | | | |
| grandine | | | | |

## open questions

### Validator IP obfuscation

**Problem:** Authenticated communication between mev-boost and relays would leak the IP address of the validators.

**Option 1:** Mess with p2p

A proposal was discussed which would move the validator --> relay messages to a p2p topic and rely on anonymity set for relay --> validator messages. The proposal is described [here](https://hackmd.io/@paulhauner/H1XifIQ_t#Change-3-New-Gossipsub-Topics).

The benefit of this is it makes information distribution symmetric. Anyone listening for this topic on the p2p network will obtain information about the `feeRecipient` and the relay payload proposal which can be used to validate the block proposal.

The downside is the complexity of implementation and incentive for it to be bypassed.

**Option 2:** Let the validator deal with it

The second option is to let the validator deal with it. If a validator is concerned about targetted DOS, they can insert a reverse proxy in between the mev-boost and relay communication (like what miners do today).

Many client teams and validators have indicated a strong preference for this option because of simplicity + performance.

### feeRecipient authentication

**Problem:** The validator must communicate to the network the `feeRecipient` it plans to use. This information must be available to all block builders and relays.

**Proposal:** MEV-Boost should be able to request from the beacon client a list of `feeRecipient` addresses signed by the corresponding validator. This authenticated list can then be made visible to the network by the relays. This proposal requires introducing a new signing domain to the validator client and an API to the beacon node to aggregate these messages.

### Execution client block value

**Problem:** MEV-Boost must know the value of the payload produced by the local execution client in order to perform profit switching against the payloads from the relays.

**Proposal:** Add a return value to the `engine_getPayloadV1` method which surfaces the change in balance of the `feeRecipient` from the execution of this payload. Note: this requires a modification to the engine API.

### Relay fraud proof message

**Problem:** MEV-Boost must be made aware when a relay has delivered an invalid payload to a different validator.

**Proposal:** A new fraud proof message which can be delivered to mev-boost by a relay which proves that one of the recently produced blocks proposed by a relay was invalid.

### Splitting away executePayload call

**Problem:** Consensus clients should not rely on mev-boost for validating the chain.

**Proposal:** Introduce a call splitter to the beacon nodes which routes `engine_executePayloadV1` calls directly to the local execution client instead of to mev-boost.

## resources
- [mev-boost architecture](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177)
- [mev-boost repository](https://github.com/flashbots/mev-boost)
- lighthouse notes
- [architecture notes](https://hackmd.io/@paulhauner/BJHb-76It)
- [summary of client modifications](https://hackmd.io/@paulhauner/H1XifIQ_t)
- [suggestions for increased security](https://hackmd.io/@paulhauner/SJQvD6cKK)