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

[sim] Correctly handle PVG and gas limits during simulation/estimation calls #783

Open
dancoombs opened this issue Sep 5, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@dancoombs
Copy link
Collaborator

Describe the feature
On Arbitrum Nitro networks the gas limit value of a transaction includes both L2 execution gas AND the L1 calldata gas components. Before a transaction is applied to the VM (i.e. during a send, call, gas estimation, etc) the L1 calldata component is subtracted from the gas limit and the remaining gas is applied. If the gas limit isn't high enough it can fail here with "intrinsic gas too low."

The L1 calldata gas component can be unboundedly high, especially on testnets. During calls that are made during both gas estimation and UO simulation, we need to ensure that the gas limit applied to the call contains the L1 component. We still want to use certain settings to limit the amount of EXECUTION gas that gets applied to these calls. Settings like max_verificaiton_gas and max_simulate_handle_ops_gas should still be applied, but we need to add the L1 component on top.

We should also audit anywhere that we compare PVG to these settings to ensure that we don't reject UOs with a high L1 component. For example, this line is incorrect

@dancoombs dancoombs added the enhancement New feature or request label Sep 5, 2024
@dancoombs dancoombs added this to the v0.4 milestone Sep 5, 2024
@dancoombs dancoombs self-assigned this Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant