Mempool

In Cardano, for blocks to have useful data, they have to contain transactions, which are codifications of operations on the Ledger state that only some authorized actors can enact. Notice that such transactions are what makes up the contents of the block. In one way, one could see the ledger as being able to validate transactions, and by implication full blocks as those are mainly collections of transactions.

The Mempool is the abstract component of the node that stores transactions which are valid on top of the latest known Ledger State (the one at the tip of the chain selected by Chain Selection in the Consensus layer). The validity of transactions is defined by the Ledger layer. Notice a change in the selected chain should trigger a prompt revalidation of the pending transactions to discard those that became invalid on the new selection. Such collection of valid transactions will be requested by the Consensus layer to forge new blocks.

Once a transaction has been included in some block, it cannot be a pending transaction anymore, in fact from that point onwards it will be an invalid transaction, as in Cardano every transaction consumes at least one UTxO, in this case consumed by the instance of the transaction that was included in a block.

While only nodes that forge new blocks will use these transactions to create blocks, non-block-producing nodes are still expected to diffuse transactions to their peers. All participating nodes must be able to receive, validate, and distribute transactions.

The TxSubmission2 miniprotocol is the one used to diffuse the pending transactions through the network.

To be able to diffuse transactions through TxSubmission2 and to fulfill the requirements of the Consensus layer, any mempool implementation has the following requirements:

• Acquiring a snapshot of valid transactions for a newly forged block should be as fast as possible, as it will delay all other steps in the diffusion of such a block. This is required by the Consensus layer for forging blocks.
• Cursor-like access to pending transactions. This is required by the TxSubmission2 protocol.
• Re-validation on a new selected chain: it is useless to keep transactions that are no longer valid in the mempool. This is an inherent requirement of the mempool itself.

Notice that what a transaction actually is defined by the Ledger layer and it depends on the current era at the tip of the chain. The Ledger layer provides mechanisms to translate transactions from older eras to more recent ones. Once a transaction is translated to a more recent era, it is such translation the one that is distributed to the network afterwards.

Fairness