Add EIP: Add Controlled Gas Limit Increase Strategy

[Giulio2002]

Adds the possibility to have a gradual increase in gas target over time:

1. This EIP does not require an hard fork so in case of a DDOS vector, a fixed gas target can still be set
2. It gives time to analyze network behaviour and bandwidth usage as the gas target increases, instead of setting the increasing the gas target in a cliff-like manner.
3. It is less prone to cause issue when raising the gas target due to it being a gradual change

[eth-bot]

✅ All reviewers have approved.

[jochem-brouwer]

Some comments.

In general I am not in favor of this approach. Because we currently have the freedom to let miners change the gas limit, this means that without a hardfork we can decide as community to scale up the gas limit. In case that a problem is found (for instance, a new DoS vector on blocks, like the Shanghai attacks https://ethos.dev/shanghai-attacks ) we can signal to miners that the gas limit should be scaled down (which can be done without a fork).

However, this EIP will remove this flexibility. If a problem is found and we need to decrease the gas limit as fast as possible, this means we have to fork, which will take a substantial amount of time.

As a general suggestion for this EIP: I would suggest linear increase of the gas limit, instead of an exponential increase. The exponential variant could lead to some rounding errors when rounding down to the nearest integer, which could lead to consensus bugs. The linear increase (constant gas limit bump per block) is also slightly easier to code.

[paulmillr]

validators are already voicing their concern with increased bandwidth requirements. Increasing gas to 60M will make the situation worse.

Also, why would this be necessary with blob-based roadmap? Gas prices have been low since the last hardfork.

#8931 seems like a better solution.

[Giulio2002]

validators are already voicing their concern with increased bandwidth requirements. Increasing gas to 60M will make the situation worse.

Also, why would this be necessary with blob-based roadmap? Gas prices have been low since the last hardfork.

#8931 seems like a better solution.

#8931 does not do anything for bandwidth. there is an ongoing conversation about this. also this is a gradual increase so the gas limit is unlikely to reach 60mn - maybe 40-45mn.

[Giulio2002]

Some comments.

In general I am not in favor of this approach. Because we currently have the freedom to let miners change the gas limit, this means that without a hardfork we can decide as community to scale up the gas limit. In case that a problem is found (for instance, a new DoS vector on blocks, like the Shanghai attacks https://ethos.dev/shanghai-attacks ) we can signal to miners that the gas limit should be scaled down (which can be done without a fork).

However, this EIP will remove this flexibility. If a problem is found and we need to decrease the gas limit as fast as possible, this means we have to fork, which will take a substantial amount of time.

As a general suggestion for this EIP: I would suggest linear increase of the gas limit, instead of an exponential increase. The exponential variant could lead to some rounding errors when rounding down to the nearest integer, which could lead to consensus bugs. The linear increase (constant gas limit bump per block) is also slightly easier to code.

Can you re-comment on the updated version?

[Giulio2002]

Then I think you need to take into account what I mention about the cap and possible invalid blocks from honest nodes.

So actually - the CL only sends it to the builder API and not to the engine api so this does not affect the EIP

[Giulio2002]

one job got cancelled :(

[g11tech]

i think it requires an approval from @SamWilsn or @lightclient to merge

[jochem-brouwer]

Some comments and suggestions

[jochem-brouwer]

LGTM!

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...