# mev-boost milestone 2 security features

This document aims to provide a high level design for the payment proof and fraud proof system used by mev-boost to secure itself against malicious relays. The malicious relay problem is discussed [here](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177#malicious-relay-6).

## Payment proofs for "inaccurate value"

Payment proofs solve the "inaccurate value" attack vector where a relay could incorrectly report the value of the payment made to the block proposer.

When requested, a relay provides an [`MEVPayloadHeader`](https://github.com/flashbots/mev-boost/blob/thegostep/docs/docs/milestone-1.md#mevpayloadheader) which includes a `feeRecipientBalance` field representing the ending balance of the fee recipient address of the validator proposing the given block. Since mev-boost selects the payload with the highest ending balance for inclusion, it must verify that the ending balance is accurate.

To do this, we propose adding a merkle proof of the ending balance of the fee recipient to the `MEVPayloadHeader` object. mev-boost would verify the payment proof of all incoming payloads. Using the structure defined by [EIP-1186](https://eips.ethereum.org/EIPS/eip-1186) the merkle proof could conform to the following format:

- `balance`: `QUANTITY` - the balance of the account.
- `nonce`: `QUANTITY`, - nonce of the account.
- `storageHash`: `DATA`, 32 Bytes - SHA3 of the StorageRoot.
- `codeHash`: `DATA`, 32 Bytes - hash of the code of the account. For a simple Account without code it will return "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"
- `accountProof`: `ARRAY` - Array of rlp-serialized MerkleTree-Nodes, starting with the stateRoot-Node, following the path of the SHA3 (address) as key.

### Questions:
- is this the correct proof format to use?
- do the clients have standard methods for creating / verifying these proofs?

## Fraud proofs for "invalid payload"

Fraud proofs solve the "invalid payload" attack vector where a relay could propose a block that violates consensus rules.

In order to avoid outages and liveness failures, mev-boost must be notified if a relay in the network has proposed an invalid payload and automatically respond by rejecting payload proposals from this relay until trust has been re-established.

To do this, we propose adding the concept of a fraud proof which allows mev-boost to be notified of which relay proposed a payload which lead to an invalid block proposal in the beacon chain history. This fraud proof would include the following information:

- `payloadHeader`: [`SignedMEVPayloadHeader`](https://github.com/flashbots/mev-boost/blob/thegostep/docs/docs/milestone-1.md#signedmevpayloadheader) - the invalid payload header signed by the offending relay.
- `payload`: [`ExecutionPayloadV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayload) - the invalid payload revealed to the network.
- `block`: [`SignedBlindedBeaconBlock`](https://github.com/flashbots/mev-boost/blob/thegostep/docs/docs/milestone-1.md#signedblindedbeaconblock) - the invalid beacon block signed and proposed by the validator.

Upon receiving a fraud proof from a relay, mev-boost must extract the identity of the offending relay from the signature on the `SignedMEVPayloadHeader` and call `engine_executePayloadV1` against a local execution client using the corresponding `ExecutionPayloadV1` to verify that the payload validity. If the payload is invalid, mev-boost disables the offending relay.

### Questions:
- how much time does mev-boost have to validate a fraud proof? that is, how far back in the chain history do the execution clients allow calling `engine_executePayloadV1`?
- what does `engine_executePayloadV1` return if it does not have the state of the requested parentHash? for example, in the event of a soft fork, does this fraud proof still work?
- are there other edge cases which need to be considered?
- can a bad relay DOS mev-boost by providing too many inconclusive fraud proofs?

## Manual review for "missing data"

Manual review is necessary for mitigating the "missing data" attack vector where a relay could delay revealing the transaction list of a payload until after the block proposal deadline has passed.

We've not found a mechanism for automatically identifying this liveness error as it could occur under normal operating conditions given network latency. As such, we propose using a manual review process where the validator is responsible for assessing a relay's performance over time and make a decision on continuing to receive payloads from this provider.

We want to provide a way for a node operator to outsource the decision of which relay to support to a third party curated list in order to minimize burden on solo validators.