Ethereum co-founder and researcher Dankrad Feist introduced a bold new proposal on April 27, 2025, that could fundamentally reshape the network’s transaction capacity over the next four years. The proposal, designated EIP-7938, outlines an exponential gas limit increase that would gradually scale Ethereum’s throughput from its current constraints to roughly 100 times today’s levels — potentially unlocking thousands of transactions per second without relying on off-chain solutions.
TL;DR
- EIP-7938 proposes an exponential gas limit increase, targeting a 100x improvement over four years
- The schedule starts at 50 million gas per block and reaches 5 billion through automatic client voting
- Activation is targeted for Ethereum beacon chain epoch 369017, approximately June 1, 2025
- The proposal is non-consensus, backward compatible, and can be overridden by individual node operators
- If successful, Ethereum could process up to 2,000 transactions per second on the base layer
The Mechanics Behind EIP-7938
Unlike traditional hard forks that require network-wide consensus changes, EIP-7938 takes a more elegant approach. It leverages Ethereum’s existing gas limit voting mechanism — the same process miners and validators already use — but introduces a predictable, coordinated default schedule that client software would follow automatically.
The formula is straightforward: starting from an initial gas limit of 50 million (G0), the limit grows exponentially, achieving a 10x increase approximately every 164,250 beacon chain epochs, which translates to roughly two years. After four years, the gas limit would plateau at 100 times its starting value — around 5 billion gas units per block.
This gradual, predictable growth stands in stark contrast to the ad-hoc gas limit adjustments that have characterized Ethereum’s history. Since the network’s genesis, gas limit increases have been inconsistent, driven primarily by individual miner preferences and lacking a unified long-term strategy.
Why a 100x Increase Matters
Ethereum currently processes roughly 15-30 transactions per second on its base layer, with the gas limit hovering around 36 million units. Even a modest increase would be significant, but a 100x improvement would transform the network’s capabilities entirely.
At 5 billion gas per block, Ethereum could theoretically handle up to 2,000 transactions per second — a figure that places it in direct competition with traditional payment processors like Visa, which averages around 4,000 TPS in normal operations. This level of throughput would dramatically reduce the need for Layer 2 rollups for many use cases, though scaling solutions like Arbitrum, Optimism, and Base would still play crucial roles for high-frequency applications.
The timing is particularly relevant given that the Ethereum Pectra upgrade is scheduled for May 7, 2025, just weeks away. Pectra already includes improvements to staking mechanics and transaction flexibility through EIP-7702, and adding a clear gas limit roadmap to the mix could significantly boost developer and institutional confidence in Ethereum’s long-term scalability.
Technical Considerations and Risks
The proposal is not without its critics. A rapid gas limit increase, even one spread across four years, places significant demands on node hardware. Larger blocks mean more data to propagate across the network, potentially increasing block times and putting stress on less-optimized validators, particularly those running on modest hardware in home setups.
Feist addresses this concern by emphasizing the gradual nature of the increase. Each epoch brings only a tiny incremental adjustment — far smaller than the dramatic gas limit bumps Ethereum has weathered in the past. The exponential curve is designed to match expected improvements in consumer hardware and network infrastructure over the four-year period.
Importantly, the proposal preserves operator autonomy. Any validator or node operator can override the default voting behavior through manual configuration, ensuring that no one is forced into accepting gas limits their hardware cannot handle. This opt-out mechanism is critical for maintaining Ethereum’s decentralization ethos.
Broader Implications for the Blockchain Ecosystem
EIP-7938 arrives at a moment when blockchain scalability is arguably the most pressing technical challenge in the industry. While competitors like Solana have pursued high-throughput architectures from the ground up, Ethereum’s approach has been more measured — prioritizing decentralization and security while building layered scaling solutions.
A 100x base layer improvement would fundamentally alter the competitive landscape. It would validate Ethereum’s philosophy that careful, incremental scaling can coexist with robust decentralization, while also reducing the urgency for users to migrate to alternative chains for performance reasons.
The proposal also intersects with the growing AI-blockchain convergence trend. On the same day, academic research published in precision agriculture journals demonstrated how AI-driven blockchain frameworks are enabling new use cases in supply chain management and IoT integration — applications that demand exactly the kind of high-throughput infrastructure EIP-7938 aims to deliver.
Why This Matters
EIP-7938 represents one of the most ambitious scalability proposals in Ethereum’s decade-long history. Rather than relying solely on Layer 2 solutions, it charts a path toward dramatically increasing the base layer’s capacity through a mechanism that respects the network’s governance traditions and operator freedoms. If adopted, it could redefine what’s possible on Ethereum — making thousands of transactions per second a reality without sacrificing the decentralization that makes the network unique. As the blockchain industry races toward mainstream adoption, proposals like this one could determine which platforms are ready for the demands of a globally scaled decentralized economy.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Cryptocurrency markets are highly volatile, and readers should conduct their own research before making any investment decisions.
50M to 5B gas over 4 years through automatic client voting. No hard fork needed. Dankrad’s proposal is elegant but state growth concerns are real.
gas_guzzler_ state growth is the real concern. 5B gas per block means validators need enterprise hardware to keep up. this benefits centralized validators
gas_wars_ 5B gas per block means validators need enterprise SSDs and bandwidth. solo stakers get priced out and we end up with AWS-hosted validation
block_state_ this isnt about SSDs its about state growth. 5B gas means the state bloats 10x faster and pruning becomes impossible on consumer hardware. the AWS concern is real
solo_node_ state growth at 5B gas per block means pruning becomes a research problem. consumer hardware wont keep up and we all know what that means for decentralization
state_bloat_ pruning at 5B gas per block becomes a distributed systems research problem not an engineering one. nobody has solved stateless clients yet and this proposal assumes they will
block_state_ this isnt about SSDs its about state growth. 5B gas means the state bloats 10x faster and pruning becomes impossible on consumer hardware. the AWS concern is real
non-consensus change through client voting is elegant. validators who disagree can simply override. no chain split drama
2000 TPS on the base layer would make a lot of L2s obsolete. Validators will have strong opinions about the hardware requirements though.
Sofia Petrov making L2s obsolete is a feature not a bug. why pay for an L2 when the base layer can handle the throughput natively
10x every 164K epochs roughly 2 years. non-consensus change so node operators can override. technically clever but politically this will be a battle
Dankrad proposing this through client voting instead of a hard fork is smart politics. but if it actually works the L2 stack loses its reason to exist and those are billion dollar ecosystems
Activation targeted for June 1, 2025. If this works even partially, ETH gas fees could drop dramatically. Bullish for DeFi adoption.
Dankrad proposing 50M to 5B gas per block via client voting is clever. bypasses the governance circus entirely. node operators just vote with their client
100x gas increase sounds insane until you check hardware trends. validator hardware in 2029 will handle this easily. storage is the real bottleneck not compute
2000 TPS on L1 is great until you calculate the state growth. at that rate youre adding terabytes per month. who runs the archival nodes?
5 billion gas per block sounds insane until you realize most nodes will just crash trying to validate that. hardware requirements would skyrocket
Dankrad proposing automatic client voting is clever. sidesteps the governance nightmare of getting everyone to agree on each bump
Dankrad proposing 100x gas increase through non-consensus client voting is the most elegant solution to the scaling debate. no hard fork drama, just gradual adoption
Pavel D. elegant until a coalition of large validators pushes it through against community wishes. non-consensus voting is only democratic when voting power is distributed
Felix A. non-consensus voting sounds democratic until you realize 3 validator pools control over 50 percent of stake. coalition push through is the realistic outcome not community consensus
epoch_drift_ completely agree on the validator concentration issue. 100x gas means 100x state growth and only massive ops can afford the hardware. decentralization goes out the window
Pavel D. elegant until a coalition of large validators pushes it through against community wishes. non-consensus voting is only democratic when voting power is distributed
2000 TPS on base layer would cannibalize half the L2 ecosystem. optimistic rollups would lose their entire value prop overnight
Pia R. making L2s obsolete is a feature not a bug. paying 3 bridges and a sequencer fee to move your own money was never sustainable. base layer throughput fixes that
Mats L. calling L2s obsolete is bold. even at 2000 TPS base layer you still need them for settlement guarantees and app-specific throughput. they dont disappear they just specialize