Two-slot proposer/builder separation

I’ve stated my position in favor of MEV auctions in my previous article, but I think @pmcgoohan has some very interesting arguments here that we should not dismiss.

First of all, I think we can all agree with @vbuterin that censorship is very expensive and not of much concern regarding transactions that are time-insensitive and can easily wait for several blocks. The users only have to pay once what the censor has to pay again and again every block, so the censor clearly loses.

Second, and that is going to be a lot more controversial, I think badly designed protocols are the ones to blame for most MEV. Just as you should not write an application that expects UDP datagrams to be received in order, a dapp should not rely on transaction ordering within blocks, and should not even rely on transactions never being censored for a few blocks. The only guarantee that blockchains provide in general is that transactions will eventually be included. So in my opinion almost no time-critical economic activity should happen on the blockchain settlement layer itself. Time-critical activities should be executed elsewhere (rollups, off-chain exchange relayers, etc) and then settled later with no time pressure at all. So I don’t see any need to protect badly designed protocols or their users from MEV; protocols should just do better and users should just go elsewhere.

However, if users do care about having their transactions being included very quickly (e.g. in the next block) for any reason, then it is not clear to me that a dominant centralized relayer for fast transactions will not emerge. This relayer will at most be able to delay transactions for a few blocks, but it seems possible to me for such a relayer may be able to obtain a near-monopoly on fast transactions.

I can imagine the following equilibrium.

  1. A single relayer builds a high proportion of blocks
  2. Out of the users who want their transactions to be included very quickly, a high percentage sends them to the private relayer only (and not to the mempool).
  3. If the relayer detects that someone wanted their transaction to be included quickly, but that it sent the transaction to the mempool instead, it loses some money to delay this transaction for a couple blocks.

I think we should not discuss whether such an equilibrium is likely to arise. Rather, we should discuss whether this equilibrium would be stable.

Unfortunately, I think it may be stable indeed. Because of the credible commitment of the relayer to behave as in (3), it is in the rational interest of users to send txs to the private relayer only in (2). Second, because of (2), the relayer has access to more transactions than others and so is able to propose the majority of blocks as in (1). Because it may auction off mempool MEV opportunities to sub-searchers, it may not even be the best searcher itself. Finally extra profits coming from (1) may allow it to maintain the behavior described in (3).

Maybe I am missing something and this is not actually profitable, but I feel I could come up with an explicit economic model in which this equilibrium can be proved to be stable.

To make it clear, I don’t think this scenario would be catastrophic for the network. The monopolist would be able to extract some rents, but no long-term censorship can happen. Moreover, a solution could be proposed in the future and implemented as a hard fork. But it may well be worth thinking about it now.