Even if the block builder ends up paying 0.5 of the proposer fee, an attack may still be profitable. Suppose we have proposer1 and proposer2, but proposer2 also runs a malicious builder1 and a colluding builder2. Builder1 sends proposer1 blocks, paying 0.5 fee and never publishes the body. Proposer1 is unable to complete any block and always gets just 0.5 (paid by builder1). Proposer2 always gets 1 fee, and its colluding builder2 earns block builder profit. The colluders (proposer2+builder1+builder2) always earn 0.5+profit (0.55 in the example above), while proposer1 always gets 0.5. It makes collusion more profitable than the default behavior, which might lead to centralization.
Would it work better if we make the 0.5 fee case asymmetric? If the body is not published, the proposer gets 0.5 fee but the builder pays 1 fee - half of which is burned. This would shift the scales and hopefully makes collusion unprofitable. Proposer1 gets 0.5 but the colluders lose 1 so they end up with 0+profit (0.05 in the example above). As long as profit < 0.5 fee, collusion seems unprofitable.
In reality this attack seems unlikely because the colluders make 0.55 (and the attacked proposer 0.5) but a honest pair (proposer3,builder3) make 1.05. However, the possibility of this attack means that proposers will prefer to work with trusted builders (be a part of a honest pair) to avoid getting into the 0.5 situation, and that violates Untrusted builder friendliness.
Another concern around the symmetric 0.5-fee is that it makes stalling the chain cheaper than advancing it. A malicious block builder can always bids the highest fee, knowing that it will never publish the body so it will end up paying 0.5 of its bid while triggering the default “zero-proposal” for the slot.
Honest block builders attempting to advance the chain must outbid the malicious one, and they end up paying the full fee.
Hence, advancing the chain costs twice as much as stalling it.
Making the 0.5 fee asymmetric as I suggested above (builder pays 1 fee, proposer gets 0.5, and 0.5 fee gets burned) seems to even the costs.
Doesn’t has the same drawback because a proposer is not limited to a single block header.
However, it gives the proposer more power to choose between blocks after they’re already known. I don’t see a DoS/griefing opportunity but a proposer colluding with a group of builders could always select the block that makes most sense based on off-chain events. E.g. an oracle is going to publish a piece of real world information in the next block, not known when the current block is built, but known by the time it is proposed. Two builders send conflicting blocks before the information is known, one assuming that the oracle will return 0 and the other assumes 1, and then their colluding proposer chooses the “winning” one 2 seconds later.
A proposer could have done the same by itself before this proposal - proposing only when the oracle information is known, but now that we separate builders from proposers, we don’t want collusion to be profitable. Collusion between builders and proposers becomes the winning strategy due to new information becoming available during the period between building and proposing.
It seems like a corner case that won’t happen too often, but it still makes collusion the more profitable strategy, leading to potential centralization.
It doesn’t mitigate the collusion above, because the fee is paid from the builder to the proposer, which are actually the same entity. That is, unless the fee is burned like in EIP 1559. If the fee is burned then it should mitigate this collusion, just as long as the profit from the collusion around the oracle result is lower than the burned fee.
N-slots exclusion penalty could work better since the combined entity actually takes a loss. Obviously, if the gains from choosing the winning block and not publishing the losing one (based on oracle information) is sufficiently high, no mitigation would work. We could add some sort of slashing for not publishing the body, but that may be too harsh because unreliable connectivity could also lead to that. N-slots exclusion seems to strike the balance.
If we go with the N-slots exclusion, the block builder deposit needs a withdrawal delay, i.e. the deposit must remain locked for at least N slots after submitting a block. Otherwise it wouldn’t be Sybil resistance and will just lead to high churn rate of block builders.
This condition seems necessary if we add such a fee. Otherwise a fee reduces the incentive to run a builder (separately from the proposer- if fee is not burned, or at all - if fee is burned). If the submission fee becomes too high it could increase centralization by reducing the number of builders or encouraging them to collude with a proposer.
The combined approach, with fee based delay and not propagating lower-fee bodies after a high fee body was propagated, seems to solve most problems.
On a more general note, both issues I highlighted are centered around the profitability of collusion between builders and proposers.
Would it make sense to add a sixth desired property, “Collusion doesn’t increase profitability”? The 5th rule (Consensus-layer simplicity and safety) implicitly includes it, since the consensus layer already has that property, but there’s a subtle difference because we’re adding another component and want to prevent collusion with it as well, so it might make sense to make it explicit.