-
Notifications
You must be signed in to change notification settings - Fork 817
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
Add eth_getMaxPriorityFeePerGas RPC method #4092
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
This adds an AI assisted draft of |
There was a problem hiding this 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
return a * n + b // predict next (n-th) value | ||
} | ||
const nextMedianRegression = BigInt(Math.round(linearRegression(blockMedians))) | ||
return bigIntToHex(nextMedianRegression) |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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! 🙂
* 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>
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) |
No description provided.