fix eth_estimateGas: remove ErrorRatio

[wjmelements]

Fixes #29726 by removing ErrorRatio from the gas estimator.

I prefer this fix to #29727 because eth_estimateGas has defined behavior that is important for users such as myself. This defined behavior is found in several places, listed below. The "estimate" meaning pertains to how the execution can change if the contingent state changes, and does not excuse inaccuracy. False results are very bad in my line of work, and can cause huge losses.

Defined in geth codebase:

DoEstimateGas returns the lowest possible gas limit that allows the transaction to run

EstimateGas returns the lowest possible gas limit that allows the transaction to run

Defined in ethjsonrpc

Generates and returns an estimate of how much gas is necessary to allow the transaction to complete.

[karalabe]

Could you detail a bit why it's important for you to have a 100% accurate estimate?

Reasons against it:

• Allowing 1.5% error rate gives us a 50% runtime performance gain.
• The transaction only pays for used gas, so anything above that is not relevant from a fee percpective.
• An exact number is only correct if the context stays the same during inclusion time. If the dependent state changes, an exact estimate could result in a failed transaction vs. an overestimate.

To top it off, wallets usually add 25+% on top, making out 1.5% a drop in the bucket.

[wjmelements]

Bundle submission systems have weak guarantees against revert. Under such a system you do not want to overestimate gas because you can cap gasUsed with the gas. If you set a higher gas, the transaction will succeed under unexpected conditions and cost more than expected. Because tipping with gasPrice saves a lot of gas, even a 1% difference in gasUsed can mean the difference between profit and loss.

…

On Wed, May 8, 2024 at 2:12 AM Péter Szilágyi ***@***.***> wrote: Could you detail a bit *why* it's important for you to have a 100% accurate estimate? Reasons against it: - Allowing 1.5% error rate gives us a 50% runtime performance gain. - The transaction only pays for used gas, so anything above that is not relevant from a fee percpective. - An exact number is only correct if the context stays the same during inclusion time. If the dependent state changes, an exact estimate could result in a failed transaction vs. an overestimate. To top it off, wallets usually add 25+% on top, making out 1.5% a drop in the bucket. — Reply to this email directly, view it on GitHub <#29729 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGDGVLKLH7IAAJ7SRHPZFTZBHF67AVCNFSM6AAAAABHMAMFT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJZHA4TQNJQG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[karalabe]

Please see my comment at #29726 (comment)