Mempool interface design

[Quantumplation]

I'm starting a discussion to capture previous and ongoing discussion related to the mempool interface, as @KtorZ likes Github discussions and I want him to tell me he's proud of me.

A block producing node checks every slot (i.e. once per second) whether it is allowed to produce a block; to maximize the likelihood that its block gets adopted, it's important for this block to be produced on top of the latest tip, consist of valid transactions, and be produced and propagated as quickly as possible.

To this end, most blockchain nodes have a component called the mempool, which is, abstractly, a collection of transactions that have been seen, validated (for some definition of validation), and are ready to be either propagated or forged into a block.

For a relay node, this mempool's purpose is to propagate transactions across the network so they reach the next block producing node;

For a data node, this mempool's purpose is to expose upcoming transactions to the dApps reading from the data node, so that they can perhaps build speculative transactions chained on top of this one.

For a block producing node, this mempool's purpose is to enable the forging module to select transactions for a block being forged.

Some other priorities that at least impact the design of the mempool:

• denial of service attacks, where mempool is flooded with invalid or "useless" transactions
• the mempool component may be useful on it's own, or as a reusable module, such as within a Sundae scooper
• some use cases might want real time control over the transactions; for example, node level MEV, etc; We need to decide whether we want to lean in to and enable this kind of customization, or whether we want to make it difficult and defend against it.
• Some use cases may want to assign priority to transactions, such as settling collateral updates before liquidations (or vice versa)
• Some use cases may involve transactions that are secret, and don't propagate: the SPO wants to definitely be the one to mint the block with that tx, even if it takes a bit longer. see Ethereum is a Dark Forest
• the design might be impacted by Tiered pricing, Leios and Validation zones
• Should the mempool be persistent and survive a reboot?
• What kinds of metrics / analytics / health / etc. should the mempool expose? Or should that be the responsibility of another component?

There are some interesting performance / modularity tradeoffs to consider:

• How concerned with validity / ledger state should the mempool be? i.e. are transactions validated at the time they are added, or is that the responsibility of whoever is draining transactions for whatever use case?
• Should the mempool be multi-tip aware, to handle switching between forks repeatedly? the haskell node currently discards transactions that are invalid on the new fork, even if we end up switching back to the original fork
• Should the mempool expose a simple, 1 at a time interface? or should we let the consumer ask for a "batch" of transactions of some size, like execution units, etc?
• How much effort should the mempool put into "bin packing"? perfect bin-packing is probably too hard, but the haskell node currently stops when one dimension is full, and could likely do slightly better

Given all the above, we discussed some basic capabilities that a mempool module/trait might need:

• Observe a new transaction, adding it to the mempool, such as from a peer or from the local client
• Observe a new ledger state, which may change the internals, such as invalidating some transactions
• Request a batch of transactions to fill some capacity

Additionally, we called these out as potentially useful, but not part of the core trait responsibilities:

• Remove one or more transactions manually
• Inspect / iterate over the current set of transactions

[Quantumplation]

@AndrewWestberg I know you're focused on other things right now, but if there's anything I've forgotten, feel free to chime in!

[AndrewWestberg]

In my design, I didn't require transactions in the mempool to be valid. This is a departure from the haskell node. For example, the mempool might keep around transactions after they are on chain in the event of a rollback so they can be re-applied. They might also only be valid once some new future state arrives.

Certain interfaces could be designed to provide exactly what the client needs though. For example, a block producing node should be able to request only valid transactions for a particular ledger state it wants to build on top of.