All nodes maintain a transaction pool to store pending transactions before processing.
Options and methods for configuring and monitoring the transaction pool include:
txpool_besuTransactionsAPI method to list transactions in the transaction pool.
--tx-pooloption to specify the type of transaction pool to use.
--tx-pool-layer-max-capacityoption to specify the maximum memory capacity of the transaction pool.
--tx-pool-price-bumpoption to specify the price bump percentage to replace an existing transaction.
--tx-pool-priority-sendersoption to specify sender addresses to prioritize in the transaction pool.
droppedPendingTransactionsRPC subscriptions to notify you of transactions added to and dropped from the transaction pool.
Layered transaction pool
The layered transaction pool is the default transaction pool implementation. This implementation separates the pool into layers according to value and executability of the transactions. That is, the first layer keeps only transactions with the highest value and that could feasibly go into the next produced block. The two other layers ensure that Besu always has a backlog of transactions to fill blocks, gaining the maximum amount of fees.
With the layered transaction pool, Besu produces more profitable blocks more quickly, with more denial-of-service protection, and using less CPU than with the legacy transaction pool.
If you previously configured transaction pool behavior, upgrade to the layered transaction pool by:
- Removing the
--tx-pool-retention-hoursoption, which is not applicable because old transactions will expire when the memory cache is full.
- Replacing the
--tx-pool-max-future-by-senderto limit the number of sequential transactions, instead of percentage of transactions, from a single sender kept in the pool.
- Removing the
--tx-pool-max-sizeoption, which is not applicable because the layered pool is limited by memory size instead of the number of transactions. To configure the maximum memory capacity, use
You can opt out of the layered transaction pool implementation by setting the
--tx-pool option to
legacy, but the legacy
implementation will be deprecated soon, so we recommend using the layered pool.
Dropping transactions when the transaction pool is full
When the transaction pool is full, it accepts and retains local transactions in preference to remote transactions. If the transaction pool is full of local transactions, Besu drops the oldest local transactions first. That is, a full transaction pool continues to accept new local transactions by first dropping remote transactions and then by dropping the oldest local transactions.
Replacing transactions with the same sender and nonce
In networks with a base fee and priced gas
You can replace a pending transaction with a transaction that has the same sender and nonce but a higher gas price.
If sending an
EIP1559 transaction, the old transaction is replaced if one of the following is true:
The new transaction's effective gas price is higher than the existing gas price by the percentage specified by
--tx-pool-price-bumpAND the new effective priority fee is greater than or equal to the existing priority fee.
The new transaction's effective gas price is the equal to the existing gas price AND the new effective priority fee is higher than the existing priority fee by the percentage specified by
The default value for
--tx-pool-price-bump is 10%.
In networks with zero base base or free gas
To enable replacing transactions in the transaction pool for zero base fee networks, or free gas networks:
- If you set
truein the genesis file, the transaction pool price bump is set to
0. Specifying a value for transaction pool price bump using
--tx-pool-price-bumpwill cause an error.
- If the minimum gas price is zero, the transaction pool price bump is set to
0, unless you specify a different value using