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

eth_estimateGas returns wrong gas, off by 1.5% #29726

Open
wjmelements opened this issue May 8, 2024 · 3 comments
Open

eth_estimateGas returns wrong gas, off by 1.5% #29726

wjmelements opened this issue May 8, 2024 · 3 comments
Labels

Comments

@wjmelements
Copy link
Contributor

Caused by #28618 which should be reverted IMO. Otherwise the current behavior does not comply with ethjsonrpc spec.

If imprecision is to be the default there MUST be a parameter to set ErrorRatio. I think that parameter should default to 0 but so-long as I am able to set it to 0 my use case will be satisfied.

@wjmelements
Copy link
Contributor Author

I have submitted two permissible solutions for this issue.

Which merges should depend upon what the maintainers consider to be correct behavior, and how much they care about standardization.

@karalabe
Copy link
Member

karalabe commented May 8, 2024

@karalabe
Copy link
Member

karalabe commented May 8, 2024

Neither PR is really a viable one.

  • remove ErrorRatio: this undoes the optimization that's useful for everyone but you.
  • add necessaryGas: this pollutes the namespace for a method that's not needed by anyone, but you.

Whilst I get your pain, we need a solution that's more flexible that both these extremes. My suggestion towards that would be adding an optional parameter to eth_estimateGas to control the error rate. I don't think any client would be against it, since it is an easy optimization for all to support error rates. The only catch is that we already have the block number as an optional parameter, meaning that anyone specifying the error rate will also need to explicitly specify the block to estimate on top (but latest does work). IMO that would support power users without polluting the namespaces as well as without undoing an optimization everyone - but you - cares about.

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