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

Transaction priority should take into account the inclusion fee #257

Open
IkerAlus opened this issue Sep 2, 2022 · 5 comments · May be fixed by paritytech/substrate#14717
Open

Transaction priority should take into account the inclusion fee #257

IkerAlus opened this issue Sep 2, 2022 · 5 comments · May be fixed by paritytech/substrate#14717
Assignees
Labels
I5-enhancement An additional feature request. T1-FRAME This PR/Issue is related to core FRAME, the framework.

Comments

@IkerAlus
Copy link

IkerAlus commented Sep 2, 2022

The concept of transaction priority is used to prioritize transactions in the transaction pool for block inclusion. At the moment, this concept of priority is defined in the get_priority function here.

If we look at this function, the transaction priority for "normal" class extrinsics is a function of the tip added by extrinsic author together with the weight and the length of the extrinsic. But it is not function of the inclusion fee of the extrinsic. As a practical example, this implies that extrinsics with a small and simple call (f.e., Remark call) paying a very small tip are prioritized over complex and big extrinsics (f.e., batchAll) paying no tip.

If we assume that transaction priority tries to maximize the profit for block producers, and knowing that block producers get 20% of the inclusion fee of every extrinsic, I believe that get_priority function should take into account the inclusion fee in its definition of transaction priority for "normal" class extrinsics. Something like :

priority = m * inclusion_fee + tip / bounded_{weight|length}.

where m is a multiplier to be defined depending on how much weight we would like to give to the inclusion fee in the priority computation.

@kianenigma
Copy link
Contributor

I agree with this. Should be final_fee / weight|length where final fee is inclusion_fee + tip

@kianenigma
Copy link
Contributor

Two further comments:

  • @Ank4n given that you recently worked on a similar ground of code, this could be a nice side-task for you.
  • For the case of Polkadot, this is something that needs to be discussed with w3f-research and then implemented in a generic way in Substrate, where we allow other chains to diverge from what Polkadot choses to do.

@kianenigma
Copy link
Contributor

Possibly a more up to date approach toward next-gen priority is #277

@Ank4n Ank4n self-assigned this Jun 22, 2023
@Ank4n Ank4n removed their assignment Aug 3, 2023
@Ank4n
Copy link
Contributor

Ank4n commented Aug 3, 2023

Unassigning this from myself since I won't be able to pick this up for next few weeks at minimum. I will keep an eye and pick it later if no one else has and when I have more bandwidth.

@MrishoLukamba
Copy link

Unassigning this from myself since I won't be able to pick this up for next few weeks at minimum. I will keep an eye and pick it later if no one else has and when I have more bandwidth.

Assign it to me @Ank4n

@MrishoLukamba MrishoLukamba linked a pull request Aug 4, 2023 that will close this issue
@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
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: To Do
Development

Successfully merging a pull request may close this issue.

6 participants