rpc: make eth_estimategas precision parametrized

[karalabe]

Geth at least has a down-to-1-wei precise gas estimator. Since wallet providers will just bump this up, we could save a bunch of compute by not doing it. E.g. we could by default only estimate until we reach 1% precision, or less (5%?).

Since it still seems very very useful to estimate with full precision + it seems like an arbitrary ad hoc decision which may or may not work for everyone, my proposal is to estend eth_estimateGas with an optional parameter that specifies what precision the estimator should stop at. Then providers could roll this out slower and they could decide how precise they want to be without us influencing them.

[karalabe]

An interesting proposal along this optimsation line is #28589, which uses the gas used and gas refund of the max-limit call to attempt to do a greedy minimum call of used+refund to see if that works, and if it does, consider that the estimate.

I'm unsure that that is enough, but it's an idea worth considering.

[s1na]

I want to add to this proposal. We have the RPC global gas cap which we use right now for checking the gasLimit of the call once. I think all of the iterations should be accounted for towards the gas cap. I.e. it shouldn't be possible to execute more EVM code than the cap allows.

[karalabe]

Nah, the gas cap is meant as a way to provide an upper limit, it's not a throttling parameter.

[karalabe]

One catch-22 with a parameter here is that the estimation caller nowadays is not the node operator. Even if we added a parameter, callers would just ask for max precision, because why not. So it might make the optimization moot. We might need to forcefully pick one that cannot be changed by the callers.

[s1na]

Nah, the gas cap is meant as a way to provide an upper limit, it's not a throttling parameter.

I'd like for us to have a parameter "the maximum amount of evm processing that is allowed during a method call" and the gas cap is the closest thing we have to it. It is used in that sense now in the eth_multicall implementation. I was thinking of applying it more widely also to eth_createAccessList and tracing API. So that an API exposed publicly can set one parameter to mitigate DoS.

[karalabe]

Such a feature seems a bit overly optimistic to me. Who specifies it? The caller? In that case I will just set it to infinity? The node operator? Well, they need to still be able to estimate huge transactions which take many orders more gas to estimate than small ones.

[s1na]

Can we close this issue in light of the comments in #28618?