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.
rejected- means that transaction will not be added to the queue.
drop- means that transaction was added to the queue but got removed.
As a transaction is received from the network, a verification is performed before adding it to the queue. The following criteria are checked:
--min-gas-price) unless it is a zero gas price transactions aka service transaction allowed by an on-chain managed contract.
gas * gas price) on top of the
max_transaction_sizein the chain specification).
Note that a transaction would be included in the queue if it fulfills the above-mentioned criteria and:
current: equals to state nonce + number of already pending transactions. or
future: there is a nonce gap, meaning that the transaction seems to have been received out of order, parity will, therefore, keep it, anticipating that transactions with lower nonces will fill the gap (gap =
transaction nonce). A
futuretransactions will not be propagated nor will it get included in the pending block as it would be invalid.
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.
Given the following transactions in a queue from a same sender:
[TX(nonce=1)| TX(nonce=2) | Tx(nonce=3) | Tx(nonce=4)]
nonce=1 is in the past,
nonce=2 is current,
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.
The RPC API will only show the external transactions that are in the queue. They will never return rejected transactions.
parity_localTransactionswill show up to 25 local transactions, be they already mined, pending or dropped. This RPC method is used in the top section of the Parity UI TxQueueViewer Dapp.
parity_pendingTransactionswill show the transactions added to the queue that will be processed soon (and do not fulfill any of the droping conditions). This RPC method is used in the bottom section of the Parity UI TxQueueViewer Dapp.
parity_allTransactionswill show the transactions added to the queue that will be processed soon as well as the ones that might get dropped.
parity_futureTransactionsis deprecated in favor of
parity_allTransactions. It can be computed by subtracting