Transaction Queue - Wiki Parity Ethereum Documentation

Parity client is listening to the network for transactions in order to include them in a block (if mining/validating) or to broadcast them. These transactions emitted locally or externally are verified and ordered in a transaction queue. This document aims at describing the process of selection and rejection of these transactions.

Queue logic

Terminology

Accepting conditions

As a transaction is received from the network, a verification is performed before adding it to the queue. The following criteria are checked:

Note that a transaction would be included in the queue if it fulfills the above-mentioned criteria and:

Dropping conditions

Once a transaction has been added to the queue, it might get dropped if:

Note that the last 3 conditions require additionally that another transaction with a higher overall score (i.e. gas price), potentially from a different sender, fulfills the requirement to enter the pool while it’s full.

Note also that local transactions will never get dropped to ease debugging.

Dropping logic

Given the following transactions in a queue from a same sender:

[TX(nonce=1)| TX(nonce=2) | Tx(nonce=3) | Tx(nonce=4)]

Where nonce=1 is in the past, nonce=2 is current, nonce=3 and nonce=4 are in the future. nonce=1 can be dropped without discussion. The transaction with nonce=5 would be the “lowest rated” transaction for this sender as it is far in the future. The system would then compare this transaction with the other transactions in the queue from the other senders. The decision to drop a transaction is taken based on the transaction queue strategy (--tx-queue-strategy), which is gas_price per default. If the transaction nonce=5 has the lowest gas price among the “lowest rated” transactions from the queue, it will be dropped.

RPC APIs

The RPC API will only show the external transactions that are in the queue. They will never return rejected transactions.