ADR-111: #1585

Summary

The current mempool built into CometBFT implements a robust yet somewhat inefficient transaction gossip mechanism.
While the CometBFT team is currently working on more efficient general-purpose transaction gossiping mechanisms,
some users have expressed their desire to manage both the mempool and the transaction dissemination mechanism
outside CometBFT (typically at the application level). @sergio-mena

Solution

Introduce mempool.type config setting with flood and nop options.

flood would represent the existing CListMempool.

nop, short for no operation, would disable all mempool-related functionality in CometBFT. When nop is being used, the ABCI developers will need to design and implement the application side (or external) mempool and propose transactions via PrepareProposal.

When nop mempool is used:

• broadcast_* RPC endpoints will return an error
• no P2P reactor will be running (peers attempting to send mempool msgs will be stopped)
• The mempool ABCI connection will still be created (should we make it optional?)
• RequestPrepareProposal will contain 0 transactions
• create_empty_blocks=false will return an error upon startup