[txmgr] Call estimate gas twice

[mdehoog]

Description
This PR adds an additional call to estimateGas in the txmgr transaction creation, and uses the minimum value returned. This is to ensure we use a correct gas limit for proposer transactions. This will cause slight overhead on tx submission, as well as increased load on the L1 node.

Tests
No tests added, this is a simple logic change.

Additional context
We believe Geth has a race condition bug where, if a contract call switches from reverting to passing during the estimateGas call, the gas calculation binary search can return very high values (see this PR for more details).

As an example, given an L1 block limit of 30,000,000, and the following binary search code: https://github.com/ethereum/go-ethereum/blob/46ec972c9c56a4e0d97d812f2eaf9e3657c66276/internal/ethapi/api.go#L1202-L1218

The binary search variables might look like:

lo = 15010500, hi = 30000000 # contract call reverts, thus gas is increased
lo = 22505250, hi = 30000000
lo = 26252625, hi = 30000000
lo = 28126312, hi = 30000000
lo = 29063156, hi = 30000000
lo = 29531578, hi = 30000000
lo = 29765789, hi = 30000000
lo = 29882894, hi = 30000000 # contract call starts working here due to internal state transition
lo = 29882894, hi = 29941447
lo = 29882894, hi = 29912170
lo = 29882894, hi = 29897532
lo = 29882894, hi = 29890213
lo = 29882894, hi = 29886553
lo = 29882894, hi = 29884723
lo = 29882894, hi = 29883808
lo = 29882894, hi = 29883351
lo = 29882894, hi = 29883122
lo = 29882894, hi = 29883008
lo = 29882894, hi = 29882951
lo = 29882894, hi = 29882922
lo = 29882894, hi = 29882908
lo = 29882894, hi = 29882901
lo = 29882894, hi = 29882897
lo = 29882894, hi = 29882895

Thus the tx is submitted with a gas limit of 29882895. This is rejected by the network because of how high the limit is. We are experiencing a stuck proposer because of this bug, using values like this.

[changeset-bot]

⚠️ No Changeset found

Latest commit: a14d260

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[netlify]

✅ Deploy Preview for opstack-docs canceled.

Name	Link
🔨 Latest commit	a14d260
🔍 Latest deploy log	https://app.netlify.com/sites/opstack-docs/deploys/648f9e52eba9d300084b828d

[tynes]

It looks like the fix has been merged into upstream geth and will be released in 1.12.1 - ethereum/go-ethereum#27505

We have no guarantee this will run in prod until the next hardfork. I don't love calling estimate gas twice, would the correct solution just be to have a sanity cap and not allow the gas limit to be higher than that value?

[mdehoog]

Agree I don't love this either. We do have the ability to hard code the gas, but we're not using it yet:

optimism/op-proposer/proposer/l2_output_submitter.go

Line 331 in e1571d7

GasLimit: 0,

Maybe a good fix would be to simply expose this as a command line flag. We can consider this if we continue to see issues.

Closing this for now.