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

Fix eth_feeHistory rewards when bounded by configuration #7750

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

fab-10
Copy link
Contributor

@fab-10 fab-10 commented Oct 9, 2024

PR description

The issue is that, when bounding rewards returned by eth_feeHistory by configuration, the minPriorityFeePerGas runtime value is used, but it could not be great enough to return acceptable values in order to estimate which priorityFeePerGas to use in a tx to ensure it is paying enough to be mineable.
To fix that a a mineable lower bound for the priority fee is calculated and used in place of minPriorityFeePerGas conf value, when it is greater that the latter, so we are reasonably sure that we are returning value that can be used to estimate the priority fee when submitting new txs.

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

  • Checked out our contribution guidelines?
  • Considered documentation and added the doc-change-required label to this PR if updates are required.
  • Considered the changelog and included an update if required.
  • For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

  • unit tests: ./gradlew build
  • acceptance tests: ./gradlew acceptanceTest
  • integration tests: ./gradlew integrationTest
  • reference tests: ./gradlew ethereum:referenceTests:referenceTests

@fab-10 fab-10 marked this pull request as ready for review October 9, 2024 15:26
List<Wei> rewards = ethFeeHistory.computeRewards(rewardPercentiles, block, Wei.of(8));

// Define the expected bounded rewards for each percentile
List<Wei> expectedBoundedRewards = Stream.of(4, 4, 4, 4, 5, 6, 6, 6, 6).map(Wei::of).toList();
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't get this test. If lower bound is set to 10 Wei, why are we getting values lower than that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

in this case minGasPrice is 10wei, and since baseFee is 8wei, the calculated min priority fee (necessary to get the tx minable) is 2wei that is greater than the configured minPriorityFeePerGas=0 so the former is used.

Then the rewards (effective priority fees) are bounded by 200 and 300 coefficients, so the rewards must be in the interval 4wei and 6wei

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, I'm following it now, thanks!

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

Successfully merging this pull request may close these issues.

2 participants