Open bstr156 opened 1 year ago
I believe this came about because prior to regolith the system tx was unmetered, but now it is metered and so affects the gas limit for a regular tx.
In regolith the max gas is 1m for the system tx and it is metered so correct fix is to offset the blockGasLimit by 1m (in DoEstimateGas) to ensure the system tx and a max gas tx would be included
Thank you for the detailed report, we'll look into improving the gas estimation to account for this max-gas case better, and evict this type of transaction that cannot fit into a block.
Is this still an issue? cc @protolambda
@protolambda ok to close this one?
Describe the bug When L2geth checks a transaction against the block gas limit, it fails to account for the system transaction in the block.
typical Optimism system TX gas used = 46,913 (but varies)
In other words, in DoEstimateGas, only the raw block gas limit is used (25,000,000) instead of the appropriate (25,000,000 - 46,913) = 24,953,087
If a contract call is submitted which consumes between 24,953,087 and 25,000,000 gas, it is accepted into the mempool but never settles in a block as there will never be a block with sufficient gas available for it due to the offset from the Optimism system tx in every block.
To Reproduce This can be reproduced by calling a gas guzzler contract, e.g. one which accepts and stores an arbitrary array of numbers. Adjust your call's array length in order to hit the gas "sweet spot".
Expected behavior What should happen is the call results in error "gas required exceeds allowance" instead of reaching the mempool.
Notes/Suggestions Since it is challenging to know the exact gas expense of a systemTx ahead of time, maybe the best way to solve this is to add a buffer to the block gas limit for the limit check. (blockGasLimit - 10%) or something similar. A single execution consuming all the gas would be an oddity anyway, so this should solve it well.