EIP-7938 Exponential gas limit increase
No call decision · Scaling & data · EIP status Stagnant · created 2025-04-27
A proposal to change client default settings so the gas limit rises exponentially each epoch, growing about 100 times over four years (from 50 million to 5 billion). It does not change the protocol consensus rules.
Why it is needed
The gas limit, the cap on how much work a single Ethereum block can process, is currently set by a vote among the operators who build blocks. The source document points out that this approach is flexible but lacks coordination and predictability, so the limit can stay flat or rise only with excessive caution. It therefore proposes changing the client (node software) default so that, without any other configuration, clients vote automatically along a predefined exponential growth schedule. The aim is a transparent and sustainable gas limit growth path that tracks improvements in hardware and protocol efficiency.
What changes
Today
- The gas limit is set by operator votes, and it is hard to predict when and by how much it will rise
- Without coordination, the limit can stagnate or rise only conservatively
- Each node operator judges the limit value individually
After EIP-7938
- Clients automatically vote for a value computed by a formula every epoch
- It rises 10x about every 2 years, up to 100x (5 billion gas) after 4 years, and then stops
- If an operator sets a manual configuration, that value takes precedence over the default
- After 4 years, a new growth schedule must be decided and committed to
Who is affected
- Node operators and validators: Without any other configuration, the client automatically votes for a higher limit. If the limit rises quickly, it can put a burden on less optimized nodes, so hardware and settings need to be checked.
- Client teams: Clients must implement logic that recomputes the default vote value every epoch and gives precedence to manual settings. This is not a consensus rule change, so no hard fork is needed.
- Users and app developers: You can plan on the assumption that per-block processing capacity grows at a predictable rate.
In depth
Exponential growth schedule
The gas limit at the activation epoch is G0 = 50,000,000, and the activation time t0 is beacon chain epoch 369017 (about June 1, 2025). T = 164,250 is the number of epochs for a 10x increase (about 2 years). The limit at epoch t is the previous default if t < t0, round(G0 * 10^((t-t0)/T)) if t0 ≤ t ≤ t0 + 2*T, and 100 * G0 if t > t0 + 2*T. round rounds to the nearest integer. As a result, the limit rises up to 100x over 4 years and then stops. The Abstract of the source document states that an updated growth schedule must be decided and committed to at that point.
Client behavior and activation
At the start of every beacon chain epoch, the client recomputes the default gas limit vote value with the formula above and votes automatically for that value, using the existing gas voting mechanism as is. Users can override this default by specifying a manual gas limit policy in the client configuration. Activation is at beacon chain epoch 369017.
A default change, not a consensus rule
This EIP is of the Informational type. It does not change the protocol consensus rules. It keeps the current gas voting mechanism and layers a predictable, community-coordinated trajectory on top of it. The design spreads responsibility across individual clients rather than consensus rules, which preserves flexibility while encouraging scaling. The change is non-consensus and backward compatible. Clients that do not implement this EIP behave as before, only the default behavior changes, and manual configuration remains supported.
Security considerations
A fast rise in the gas limit can burden less optimized nodes and may lengthen block propagation time. The source document responds that the exponential schedule has a very small increase per epoch, so node operators and developers have enough time to adapt and optimize.
Current status and call history
The source status is Stagnant. The activation target, epoch 369017 (about June 1, 2025), has passed, and the proposal cannot be considered in progress even now. In the core developer call records, it was discussed at the 08.29 AMA #14 and no decision was made. There is also no decision to include it in a fork.