Brainstorming a bit with research folks and here is an early idea for how inclusion lists could apply to mev-boost:
- Proposer can send a list of transactions to mev-boost relays that specifies which transactions must be included in a block for that to be considered valid by mev-boost. This likely needs to be done with a new API call that’s signed by the proposer.
- Then when the proposer asks relays for a block header the relay responds with a header along with merkle proofs proving that the transactions from the proposer’s inclusion list are present in the block.
- For each block header that is returned mev-boost validates the proofs to ensure each transaction from the proposer’s list was included. If a block header did not include the necessary transactions then it is discarded.
In effect this would make mev-boost temporarily filter out, just for that block, relays which are not able to include their desired transactions.
We had thought about allowing the proposer to specify their inclusion list in the getHeader() call when they got a block. However, this doesn’t work because that call isn’t authenticated, so the relay can’t know that it was actually the proposer who is asking for transactions to be included. A new API call also avoids having the inclusion list come “just in time” and the proposer can register their inclusion list ahead of their slot.
One additional thing that could be done is have the beacon node validate the merkle proofs of the final block header and switch to a block built locally if the block doesn’t meet their requirements. I’m not sure if this is necessary (as mev-boost does the validation too), so others would need to weigh in here.
Perhaps there is a way to disable the merkle proof checks if the relay is offering a block that is filled up to the full gas limit. I’ll think about that a bit more. Right now the above doesn’t offer that functionality.
Lastly, I’ve described how this works primarily with a proposer <> relay interaction in mind, but the system should work the same if a proposer is interfacing directly with a builder. I think it would also translate to in-protocol PBS well some day.