This is a mirror from my hackmd page. It may be a stupid idea, but just some thoughts that hopefully inspire more open discussion around this topic
based MEV-Share
If you have “smart searchers” they could read the different Mempools and match orders. Then match the orders, bundle them and send them to a builder. So basically MEV-Share for all rollup mempools. In this way you would not need a sequencer for ordering, though a local fallback is always helpful.
This idea on the surface appears similar to the idea put forth by a couple of Jedis here. Perhaps this lends some credence to the technical feasibality of the following discussion.
Disc-V5 supports topics and is used on both CL and EL, so we could create separate p2p channels at any granularity we want (e.g. shared_sequenced_chain1_chain2_slot5 , see e.g. how EIP-4844 blobs are each on separate topics. ~ @gakonst
I would caution the reader that the following proposal is reductionist and may be technically infeasible and/or too left curve. Feel free to correct any misconceptions or comment.
4337, Private Mempools & Match-Making
MEV-Share inserts an intermediate role between searchers and Builders. The Match maker plays a similar role to that of a solver in the Anoma framework. Can you match make userOperations for all rollups?
Since all transactions are 4337 compliant they need aggregation anyway. So rather than send rollup transactions to a sequencer you send to a private mempool and communicate with the Bundler who is the MEV-Matchmaker. They then bundle all transactions and send to the builder who aggregates the block. The rollup reads the state from the L1 after the block is produced and derives current state of the chain. One issue with this approach is it would kill rollup soft confirmations which is why you would need them on L1.
I think this could be super valuable for economic security as MEV flows to the base layer. One downside is then the rollup captures less value and so funding public goods with MEV becomes less feasible. I think this can be implemented in stages. For example maybe at first you only get this level of cross composability with rollups sharing Liquidity in dAMM contract. Then other stuff, like aggregation across yield farming, borrow/lend operations, NFT mints, attestations, payments, etc. It could be possible for the Match-Maker to take all un-matched AMM orders and send them through an L1 aggregator, similar to Cowswap.
In this scheme rollups could still have a sequencer. As a user you would be alble to opt-in to an MEV auction similar to how you use private mempools today. The other alternative would be the based rollup critical path, outlined by Justin Drake.
Censorship resistant
The design is more censorship resistant If the matchmaker can be trust minmized. But maybe its less bad if the user has multiple mempools to choose from. The Match-Maker itself could potentially have multiple instances asigned to different rollups should the need exist. Smart Wallets could come with built in logic that suggests to the user which mempool to use. However, I personally think this is unlikely and we will see only a handful of winning rollups in a winner take most competition. But as you can see there is clearly a path to open and permissionless Match-Making.
This is all well and good but there are many unanswered questions, like how would this new matching framework comply with 4844?
Also, the logic required to run a multi-rollup match maker may be costly initially and take time to mature. In this case you could start with one rollup and then add additional rollups as the stack matures and demand arises. Reth is around the corner as well which will make simulation faster.
The Match-Maker role could be more decentralized than the builder role as it would not require the composition of entire blocks, only bundles that match userOperations . The Builder in this scenario could order bundles based on fees or FIFO if desired. The Builder could also reserve space at the top of the block for this 4337 Auction and then leave space for L1 public mempool transactions. Many such combinations and scenarios.
Builder pre-confirmations
One extra builder service that would be desirable here is pre-confirmations. The concept is well understood so i won’t outline the specifics, but to recap the builder could guarantee inclusion of transactions pay a specified gas fee. In this way the builder would collect these pre-confirmed chunks and aggregate them and then send to the relay. This may also help builders reason better about how much to pay for an MEV opportunity.
Also, if pre-confirmations are ~ 1s then you can get lower latency with respect to price updates on DEXes, as they would not remain ‘stale’ until the next oracle update. So the notion of “stale pries” goes away mostly. The pre-confirmation would need to be globally visible for searchers and users to reason about the current source of truth. Lower latency would allow for better price discovery and perhaps less adverse selection for LPs. There are better researchers who can make this argument wrt Latency and price discovery. Don’t take my word for it.
Its also unclear if a Matchmaker would be able to provide pre-confirmations and if a cross rollup mempool order flow auction introduces too much latency.
Conclusion
The combination of 4337 with MEV-Share, builder pre-confirmations, and based rollups could lead to cros-rollup + L1 composability while filling in the ordering function for rollup sequencers who seperate ordering from inclusion.