How to prevent MEV stealing by Proposer?

Relays
1

Regarding the FAQ on preventing MEV by Proposers, I’m having trouble fully understanding the concept and would like to confirm my understanding.

What prevents block proposers from stealing MEV from submitted builders’ blocks?

If my understanding correct, the following steps are taken to prevent MEV stealing by Proposers.

① The Proposer retrieves the blindBlock using getHeader.
getHeader(/eth/v1/builder/header/{slot}/{parent_hash}/{pubkey}): Builder-API

② When the Proposer receives that block, they sign the header.

③ The signed data is sent to the ExecutionClient or Consensus Client.

④ Based on the signed data, the full block is retrieved using submitBlindedBlock.
submitBlindedBlock(/eth/v1/builder/blinded_blocks): Builder-API

⑤ The full block is submitted. If the header differs from the one in ③, they are slashed.

Is my understanding of ③ correct?
Also, if it is, could someone explain which specific API is used and what it does?

I would greatly appreciate any insights.

2

These docs should clarify:

sequence diagram
sequence diagram686×1019 54.5 KB

The API for (3) is getPayload, where the proposer sends the signed blinded beacon block to the relay, at which point the block will be proposed by the relay.

2 Likes
4

@metachris Thank you!

  1. The builder running the Builder API is expected to respond with the full execution payload upon seeing the blinded block proposal. This allows the validator to create a “signed” Beacon block, which they propagate throughout the network.
  2. A validator using the Builder API is still expected to build a block locally in case the block builder fails to respond promptly, so they don’t miss out on block proposal rewards. However, validator cannot create another block using either the now-revealed transactions or another set, as it would amount to equivocation (signing two blocks within the same slot), which is a slashable offense.

I initially thought that the “sign” by the proposer simply involved signing the header with a private key and then sending that signed data to the builder.

However, after looking at ethereum.org, I’ve come to understand that the signed block header is created within the consensus client, and that data is then transmitted.

1 Like