WalletUnCon

How does a public p2p mempool prevent UserOp collisions?

While it is relatively straightforward to prevent UserOp collisions in private mempools, the introduction of a shared public p2p mempool for AA complicates how competing bundlers grab and bundle UserOps for inclusion in a block. Duplicates may lead to frequent rejections of bundles.

The article Why Must ERC-4337 Bundlers Work with Block Builders talks about nonce collision in bundlers:
- After the public mempool is introduced, the most UserOperations are from this pool.
- There must be a mechanism to prevent multiple Bundlers from bundling the same UserOperation in the mempool.
- EtherSpot is developing this p2p network where once bundled and processed on-chain, UserOps will be marked and delisted. They say: "it is meaningless to send duplicate UserOperations to the mempool because it can be easily detected by the p2p network."
- At this point, multiple Bundlers will access the same set of unprocessed UserOperations.
- They recommend that "One cannot and should not run a bundler in the p2p mempool without a service like mevboost on a public mempool on Ethereum."
- This will ensure the elimination of duplicate submissions and reduce online rejections.

There seem to be additional hidden assumptions in how the mevboost block builder market work with bundlers to prevent duplicates and rejection of bundles.

This workshop aims to explore what these assumptions are, and also discuss alternative strategies for chains that do not have mevboost-style block builder markets like Filecoin, to support AA and maintain future compatibility with ERC-4337.