Transaction Queue: update normalized order

Fix #3043.

The order of same-cost transactions in the queue was updated in [rippled 1.8.2](https://github.com/XRPLF/rippled/releases/tag/1.8.2), released in 2021, to address issues with high fees and full transaction queues on the network at the time.
This commit is contained in:
Rome Reginelli
2025-07-07 13:45:58 -07:00
committed by GitHub
parent 2a3abedace
commit 259a5ac32b

View File

@@ -60,7 +60,7 @@ If none of the above occur, transactions can stay in the queue for a theoretical
## Order Within the Queue
Within the transaction queue, transactions are ranked so that transactions paying a higher transaction cost come first. This ranking is not by the transactions' _absolute_ XRP cost, but by costs _relative to the [minimum cost for that type of transaction](transaction-cost.md#special-transaction-costs)_. Transactions that pay the same transaction cost are ranked in the order the server received them. Other factors may also affect the order of transactions in the queue; for example, transactions from the same sender are sorted by their `Sequence` numbers so that they are submitted in order.
Transactions that were previous proposed in the consensus process but did not achieve the threshold to be validated are the first ones to be added to the next open ledger. After that, transactions are pulled from the queue to be proposed in a normalized order so that, during periods of high traffic, different servers propose similar sets of transactions. Within the transaction queue, transactions are ranked so that transactions paying a higher transaction cost come first. This ranking is not by the transactions' _absolute_ XRP cost, but by costs _relative to the [minimum cost for that type of transaction](transaction-cost.md#special-transaction-costs)_. Transactions that pay the same transaction cost are ranked in ascending order by hash. Other factors may also affect the order of transactions in the queue; for example, transactions from the same sender are sorted by their `Sequence` numbers so that they are submitted in order.
The precise order of transactions in the queue decides which transactions get added to the next in-progress ledger version in cases where there are more transactions in the queue than the expected size of the next ledger version. The order of the transactions **does not affect the order the transactions are executed within a validated ledger**. In each validated ledger version, the transaction set for that version executes in [canonical order](../consensus-protocol/consensus-structure.md#calculate-and-share-validations).