mev-boost

mev-boost copied to clipboard

On the mev-boost workshop it came up that it would be great to include the proof of payment in the getHeader response, with which the builder proves to the proposer/mev-boost that the payment has actually happened.

This could go into the initial v0.2.x (and would probably be good to have, even if we don't automatically verify it).

How would this proof work exactly?

It depends on how much information we expect the verifier to have. I see two main possibilities here:

1. The verifier has no state beyond the GetHeader response. In this case, there needs to be two proofs. One proof against the parent root in the payload of the feeRecipient's balance. The second proof against the stateRoot in the paylaod of the feeRecipient's balance. This authenticates the balance before and after. The delta can be verified against the claimed value.
2. The verifier has the previous block's state. Here, only the later proof in 1) would be needed because the balance of the feeRecipient before the payload is executed can be ascertained by just looking in up in the state.

Closing for now, until proof of payment comes up again for the next discussions.

Reopening this issue to discuss question raised in https://github.com/ethereum/builder-specs/issues/16

My current position on payment proofs is that it is a necessary component of the three pronged security model of mev-boost: https://hackmd.io/bTmbknkGRM6RdVCCIrRblg

Here are two approaches to implementing payment proofs:

1. inclusion proof on transaction trie

This approach requires the builder to set their own account as the feeRecipient address in the payloadHeader. The builder then includes a transaction at the end of the block which transfers ETH to the feeRecipient defined by the validator. Finally, the builder publishes this transaction along with the payload header and an inclusion proof.

2. account proof on post execution state trie

Any address can be set as the feeRecipient. Builder provides an account proof on the post execution state trie (see below).

What are desirable properties of payment proofs?

• provide transparency to the identity of builders
• defense in depth, even if fraud proofs protect against invalid payments, payment proofs can be verified pre-execution thus providing stronger protection
• makes accounting easier, can monitor the value of the payload bids without needing to simulate blocks

What are potential concerns?

• potential overhead of 21k gas in every block

---

AccountProof

Refer to EIP-1186.

• 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.