Standard scale for transaction priority

[gavofyork]

Right now the transaction priority is a u64 with no inherent scale. While one is implied through the ChargeTransactionPayment::get_priority function impl, it's rather opaque and arbitrary. This makes it harder to compose different SignedExtensions and presents a notable pain point when attempting to use EVM prioritisation mechanics.

The calculation there and elsewhere should be altered so it fits into a standard mechanic which can be assumed throughout the Substrate ecosystem.

The proposed scale would be rooted in two concepts local to the blockchain, one economic and the other resource-based. The economic concept would be one unit of the chain's native currency. The unit of resource would be the limit of one single block of the chain.

To allow a fine priority scale, a prioritisation of 10**9 would be designated as the priority gained by spending 1 unit of native currency over and above the minimum requirement (if there is one) for a transaction which would exhaust the chain's resources for a whole block.

Thus, on Polkadot, the prioritisation scale would therefore be in nanoDOTs spent per block: a priority of 1 would, for example, be a tip of 1 nanoDOT for a transaction which required an entire block's worth of resources. More realistically, if a transactor placed a tip of 0.01 DOT (10,000,000 nanoDOT) for a transaction which took only 1/10th of a block's maximum resources (weight or size, whichever is greater), then this would equate to a priority of 10,000,000 / (1/10) = 100,000,000.

[bkchr]

More realistically, if a transactor placed a tip of 0.01 DOT (10,000,000 nanoDOT) for a transaction which took only 1/10th of a block's maximum resources (weight or size, whichever is greater), then this would equate to a priority of 10,000,000 / (1/10) = 100,000,000.

When the transaction would consume 4/10th of the block. The priority would be 25,000,000. So, less than in your example. The block producer would get paid more for this transaction (in fees), but it would favor the one that uses less resources?

And the current implementation of ChargeTransactionPayment::get_priority prioritizes operational transactions, to ensure that they are more likely be included. Would we drop this prioritization of operational transactions?

[gavofyork]

The block producer would get paid more for this transaction (in fees)
...
Would we drop this prioritization of operational transactions?

No.

This is only about defining a meaningful scale for the TransactionPriority type in order that different systems for prioritisation can be composed. Ordering would be preserved as it is now, so it would make no difference to the tip payment, fees or operational transactions.