Skip to content
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

Open
gavofyork opened this issue May 12, 2022 · 2 comments
Open

Standard scale for transaction priority #277

gavofyork opened this issue May 12, 2022 · 2 comments
Labels
I5-enhancement An additional feature request. T1-FRAME This PR/Issue is related to core FRAME, the framework.

Comments

@gavofyork
Copy link
Member

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
Copy link
Member

bkchr commented May 12, 2022

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
Copy link
Member Author

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.

@juangirini juangirini transferred this issue from paritytech/substrate Aug 24, 2023
@the-right-joyce the-right-joyce added I5-enhancement An additional feature request. T1-FRAME This PR/Issue is related to core FRAME, the framework. and removed J0-enhancement labels Aug 25, 2023
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 8, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 9, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 10, 2024
serban300 pushed a commit to serban300/polkadot-sdk that referenced this issue Apr 10, 2024
jonathanudd pushed a commit to jonathanudd/polkadot-sdk that referenced this issue Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I5-enhancement An additional feature request. T1-FRAME This PR/Issue is related to core FRAME, the framework.
Projects
Status: Backlog
Development

No branches or pull requests

4 participants