Yeah sorry, I wasn’t being clear. We need to absolutely assume that “the relayer can unbundle the block and fill in the requirement list itself without having to go through the builder.” if we don’t want builders to MEV the sh*t out of the preconfs, lol.
So to answer you more extensively:
The relayer sends the requirement list to the builder.
This is only needed depending on the merging policy. For instance, for a ‘BOB, low priority’ kind of preconf there is very little we need to do. Basically the only thing builder has to know is what the merging policy is. For instance, to make everything simpler for builders XGA uses things such as:
If builder submits a tx which also appears as a preconf tx in BOB, strip it out of BOB.
This means that for builders nothing really changes, they have priority over preconfed txs. In theory a competitive builder may fear that a competitor could use preconf to backrun their block, but given that preconfs have to be ready before the auction starts, I think this is a minimal concern. In general, we’re talking about two very different markets here.
As I said in the main post, the more deranged the merging policy is, the more complicated and terrible the mechanism becomes. Luckily for us the market is often very swift in punishing this kind of inefficiencies, and a very deranged policy would probably fall out of fashion rather quickly!
The builder sends the block to the relayer.
Nothing new under the sun! Again, builders may need to do extra work if the merging policy requires it, which is why they have to be picked wisely.
The relayer verifies the block (not necessary if it’s an optimistic relayer).
This is the pain point I was talking about before. Verifying the block is basically necessary, as the relayer is the party doing the merging. So it cannot blindly trust the builder. For instance, as hinted above, if the same tx (the literal same tx, same nonce, same everything) is submitted both by builder and as a preconf, the relayer will have to actively avoid that the tx shows up as duplicated in the block. This extra computational work is the main source of added latency. The more the merging policy is complicated, the worse it gets.
The relayer responds with the header back to the proposer.
Nothing new under the sun here. The main difference is that the relayer signs it, accruing the chain of evidence that can be used to implement slashing.