Hey @Tariz, thanks for sharing this proposal!
We are seeing increasing innovation in schemes that divide the building of an individual block over multiple parties and this one is an interesting addition. I have some loose questions/observations and would encourage others to add their own.
I think the most interesting fundamental question here is how the two ordering approaches should be combined. I.e. should searcher txns go at the top or the bottom of the block? Which yields better overall outcomes?
In your proposal, you are putting searcher txns at the bottom in order to capture backrun revenue for the protocol. I would argue that it would be better to put the searcher txns at the top, and this is purely additive to your goals but removes some undesirable properties.
First, while you can run an auction for bottom-of-the-block MEV in your scheme, top-of-the-block MEV is generally (much) more important on empirical grounds.
Second, if you don’t run an explicit auction for top-of-the-block MEV, it will generally form in other ways. In your case, I assume the sequencer orders encrypted txns by arrival time, so the result would be a latency auction that encourages spam and latency optimization to the sequencer. For the negative externalities incurred by that, you can look today at the Arbitrum (latency optimization) and Polygon + Solana (spam) ecosystems.
Third, users are generally in a privileged position to capture their own backrun revenues, and your scheme stands a little in the way of that. For example, look at the mev-share protocol. Here, users reveal information about their transactions to searchers, who compete to backrun them. One difference is that the profit goes straight to the user or wallet (which is preferable to these parties). Another is that mev-share is much more extensible toward searchers filling arbitrary intents for users. For example, searchers can route user transactions towards best execution, they can pay gas fees on their behalf, and more. But all of these advantages require collaboration between user and searcher before the exact user transaction is committed to the ordering.
For an alternative design that would be fully compliant with PVDE, I would encourage you to check out @sxysun’s FCFS-FBA proposal to the Arbitrum research forum. In his proposal, there is a searcher auction at the top of the block, followed by FCFS ordering at the bottom of the block, which you can additionally encrypt.
I understand that you want to use encryption but another alternative would be to not put in-flight encryption of transactions into the protocol at all. It’s very hard to do encryption in a way that maximizes revenue for the protocol and best execution for the user, and minimizes negative externalities/centralizing forces because such a scheme would have to consider the MEV supply chain in a holistic way. In the medium term, it can work. In the long term, I hope we can provide a better alternative with SUAVE as an encrypted mempool for blockchains that also satisfies the goal of revenue generation as well as user protection and expressivity.
Cheers!