Skip to content

Add eth_getMaxPriorityFeePerGas RPC method #4092

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

Merged
merged 7 commits into from
May 28, 2025

Conversation

holgerd77
Copy link
Member

No description provided.

Copy link

codecov bot commented May 27, 2025

Codecov Report

Attention: Patch coverage is 86.53846% with 7 lines in your changes missing coverage. Please review.

Project coverage is 79.41%. Comparing base (86d7b9b) to head (f6cd708).
Report is 1 commits behind head on master.

Additional details and impacted files

Impacted file tree graph

Flag Coverage Δ
block 84.33% <ø> (ø)
blockchain 89.32% <ø> (ø)
client 67.64% <86.53%> (+0.06%) ⬆️
common 97.49% <ø> (ø)
devp2p 86.78% <ø> (ø)
evm 73.13% <ø> (ø)
mpt 89.74% <ø> (-0.31%) ⬇️
statemanager 69.06% <ø> (ø)
static 99.11% <ø> (ø)
tx 89.89% <ø> (ø)
util 89.24% <ø> (ø)
vm 55.50% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@acolytec3
Copy link
Contributor

This adds an AI assisted draft of eth_getMaxPriorityFeePerGas. Going to approve and merge here to unblock kurtosis work but this could probably stand another eye on making more efficient at some point.

Copy link
Contributor

@acolytec3 acolytec3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good enough for now. LGTM

@acolytec3 acolytec3 merged commit 504212e into master May 28, 2025
40 checks passed
@holgerd77 holgerd77 deleted the client-add-eth-maxpriorityfeepergas-rpc-method branch May 28, 2025 16:50
return a * n + b // predict next (n-th) value
}
const nextMedianRegression = BigInt(Math.round(linearRegression(blockMedians)))
return bigIntToHex(nextMedianRegression)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this returns 0 in case there are no 1559 txs in the scanned blocks, right? Should we not default this to some other value, like 1 GWei? 1_000_000_000?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about this a bit, but then I was to lazy to put more thought in it. At the moment this is not practically relevant anyhow (guess this is not a problem on testnets, right?), and beyond I was also not sure if this is just not somewhat an arbitrary choice (so validators/block builders can actually also just include without a max prio fee, right?).

That said: totally "unopinioned" here, just open a quick PR with an update if you have a better choice and would want this in! 🙂

Dargon789 pushed a commit to Dargon789/ethereumjs-monorepo that referenced this pull request May 28, 2025
* Add initial eth_getMaxPriorityFeePerGas RPC method implementation

* Add a first simple test setup

* Add basic chain creation framing

* Add proper createBlock mocking

* Expand on test scenarios

* Expand on test cases

* Revise parameter name in tests

---------

Co-authored-by: acolytec3 <17355484+acolytec3@users.noreply.github.com>
@holgerd77
Copy link
Member Author

could probably stand another eye on making more efficient at some point

Could you expand on this where you see the non efficient points? Do you rather mean this performance wise? Or would you want to improve on the algortihm at some point?

Just to add here: I am also tend to think more and more in the realms of: we are not a production client, so we do not need to integrate super-fitting algorithms on these kind of things to "maximize out stuff for tx submitters".

(nevertheless: if possible to improve with limited ressource allocation, we can surely do)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants