-
Notifications
You must be signed in to change notification settings - Fork 543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standard scale for transaction priority #277
Comments
When the transaction would consume And the current implementation of |
No. This is only about defining a meaningful scale for the |
Right now the transaction priority is a
u64
with no inherent scale. While one is implied through theChargeTransactionPayment::get_priority
function impl, it's rather opaque and arbitrary. This makes it harder to compose differentSignedExtensions
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.
The text was updated successfully, but these errors were encountered: