Module consensus_transaction_pool 

Pull-based submission of transactions to consensus, enabled by NodeConfig::consensus_transaction_pool. Instead of the admission-queue drain task pushing transactions through ConsensusAdapter into consensus, the consensus proposer pulls them from a ConsensusTransactionPool at block proposal time via the consensus_core::TransactionPool trait.

Producers feed the pool from three directions: the validator gRPC service inserts user transactions (TransactionPoolContext::try_insert), the ConsensusAdapter submits system transactions and pings through TransactionPoolClient, and each submission is resolved when the proposer includes it in a block (or with an error on eviction or epoch end).

A pool instance is bound to a single epoch: ConsensusManager creates one at consensus start, publishes it through the process-lifetime TransactionPoolContext, and closes it before stopping consensus.

Structs

ConsensusTransactionPool

A single epoch’s transaction pool, drained by the consensus proposer through the consensus_core::TransactionPool impl below. take() drains pings (zero block space), then the system lane FIFO, then the user lane in gas-price order — user transactions never delay system ones.

TransactionPoolClient

The ConsensusClient installed in pull mode in place of LazyMysticetiClient, so the unchanged ConsensusAdapter (system transactions, pings, GC retries) submits into the pool. Wraps the context rather than one pool, resolving the right epoch’s pool per submission.

TransactionPoolContext

Process-lifetime handle connecting submitters to the current epoch’s pool. The watch channel is the single authoritative state, always updated with send_replace so an installation is never lost while no receiver is subscribed.

Type Aliases

PositionReceiver

Resolves with the submission’s final consensus positions once the proposer includes it in a block, or with an error on eviction or epoch end.