Skip to main content

Local Mempool

Summary​

Most blockchains use a global mempool with peer-to-peer gossipping for transaction propagation. This approach is not suitable for high-performance distributed consensus for a few reasons:

  1. It is slow because it may involve many hops for a transaction to reach a leader, increasing time to inclusion.
  2. It is wasteful on bandwidth because the gossip protocol involves many retransmissions.
  3. It ignores the leader schedule which is typically known well in advance.

In Monad, there is no global mempool; instead, each validator maintains a local mempool, and RPC nodes forward transactions to the next few leaders for inclusion in their local mempool. This is much more efficient on bandwidth usage and allows transactions to be included more quickly.

Background​

A mempool is a collection of pending transactions. Many blockchain networks use a global mempool design, using peer-to-peer gossip protocols to keep roughly the same mempool state across all nodes in the network. A primary motivation of a global mempool design is that no matter who is leader, they will have access to the same set of pending transactions to include in the next block.

A global mempool is effective for low-throughput networks, where network bandwidth is typically not a bottleneck. However, at thousands of transactions per second, the gossip protocols (and especially the required retransmission at each node) can easily consume the entire network bandwidth budget. Moreover, a global mempool is wasteful since the leader schedule is typically known well in advance.

Transaction Lifecycle in Monad​

There is no global mempool in Monad. Validators maintain local mempools; RPC nodes forward transactions to upcoming leaders to ensure that those transactions are available for inclusion.

More precisely, transaction flow is as follows:

  1. A transaction is submitted to the RPC process of a node (typically a full non-validator node).
  2. The RPC process performs some static checks on the transaction.
  3. The RPC process passes the transaction to the consensus process.
  4. The consensus process performs static checks and dynamic checks against local state in MonadDb, such as checking the sender's account balance and nonce.
  5. If the transaction is valid, the consensus process forwards the transaction to N upcoming leader validator nodes.1 Currently, N is set to 3.
  6. Each of those N validators performs the same checks before inserting valid transactions into their local mempools.
  7. When it is a leader's turn to create a proposal, it selects transactions from its local mempool.
Transaction path to leader
Transaction path from RPC to leader (through the local mempool).

Local mempool eviction​

Transactions are evicted from a validator's local mempool for the following reasons:

  1. Whenever a validator finalizes a block, any replicas of transactions in that block are pruned from the local mempool.
  2. Validators periodically check the validity of each transaction in the mempool and evict invalid transactions (e.g. nonces are too low, account balances are insufficient).
  3. If the local mempool's size reaches a soft limit, older transactions will be evicted.

Footnotes​

  1. In testnet, a transaction that fails to land is re-forwarded once to a new set of N upcoming leaders. ↩