Fraud proof communication

[realbigsean]

What is the current direction this is headed? I'm not sure how bad payloads are supposed to be communicated between mev-boost nodes and I think this is important in order to know ahead of time which relays to avoid using.

The options I can think of are:

1. consensus layer p2p - seems like the best solution but not feasible pre-merge
2. mev-boost implements p2p - also seems unlikely pre-merge, but maybe with re-use of Prysm's libraries this wouldn't actually be too bad
3. relays are used to also relay fraud proofs, and this would rely on relays policing each other. Their incentive for doing this is to increase their own flow of payloads by notifying mev-boost nodes that other relays are misbehaving. This one seems least appealing but maybe the easiest to actually implement pre-merge. Relevant comment: Simplify spec, update based on recent discussions #82 (comment)

[thegostep]

The design I initially proposed was 3) where mev-boost can call relay_getRelayStatusV1 on the relays to obtain fraud proofs for the last 64 blocks. Main reason for selecting this approach is to avoid needing to solve spam prevention on p2p.

Why I think 3) can work:

• relays have incentive to report against on each other because they can take down a different relay
• it allows all validators to obtain a fraud proof and disconnect from a relay simultaneously
• if a relay provides an invalid fraud proof or spam, they can be punished by mev-boost

The fraud proof does assume that the execution client provides an RPC for simulating a block on top of the state of any of the past 64 blocks. Initially, the plan was to use engine_executePayloadV1 for this, but as I understand it was removed from the engine API and must be replaced.

---

Validation

sequenceDiagram
    Title: Fraud Proof
    participant mev_boost
    participant relays
    mev_boost->>relays: relay_getRelayStatusV1
    Note over mev_boost: blacklist bad relay

Loading

1. if a relay identifies a payload which violates consensus rules and was subsequently proposed to the network, they must craft a FraudProof which contains the necessary information to verify the missbehavior.
2. mev-boost requests recent fraud proofs by calling relay_getRelayStatusV1 on connected relays.
3. If a fraud proof is returned, mev-boost extracts the identity of the offending relay from the payload signature and verifies that the signature matches the payload header.
4. mev-boost calls engine_executePayloadV1 against the local execution client using the payload data provided in the fraud proof. If the response is "INVALID", mev-boost immediately blacklists the relay that generated this payload.
5. the operator must manually remove the offending relay from the blacklist in order to resume receiving payloads.

relay_getRelayStatusV1

Request

• method: relay_getRelayStatusV1

Response

• result: RelayStatus
• error: code and message set in case an exception happens while performing the request.

RelayStatus

• currentState: ForkchoiceStateV1 - current state of the chain seen by the relay.
• nextPayload: PayloadAttributesV1 - attributes of the upcoming payload.
• fraudProofs: Array of FraudProof - any fraud proof produced in the last 64 blocks.

FraudProof

• payloadHeader: SignedMEVPayloadHeader - the invalid payload header signed by the offending relay.
• payload: ExecutionPayloadV1 - the invalid payload revealed to the network.
• block: SignedBlindedBeaconBlock - the invalid beacon block signed and proposed by the validator.