Ethereum Considers 45 Million Gas Limit for Fusaka Upgrade

As Ethereum advances toward the Fusaka upgrade, developers are actively evaluating a potential increase in the network’s gas limit to 45 million per block. This marks one of the most significant throughput changes since the post-Merge era and is being carefully benchmarked across client implementations to ensure stability, safety, and consistent validator performance.

Why the Gas Limit Matters?

The gas limit defines how much computation can be packed into a single block. Raising it increases the amount of data and smart contract activity that can be processed per slot, potentially improving network efficiency and L2 throughput.

However, higher limits also increase execution burden on clients, raising concerns around validator centralization and attack surfaces. Ethereum’s current default gas limit hovers around 30 million, but with the rise of data heavy operations, particularly in blob related workloads, the community is exploring a controlled increase to 45 million.

Client Positions on the 45M Proposal

During interop testing and benchmarking sessions, the following client teams reported their readiness:

• Geth: Requires a single fix merged to the master branch. Developers warn that pushing beyond 45M would demand repricing of heavy operations like modexp, which is already addressed in Fusaka via EIP-7883. Geth supports 45M as a safe upper limit—for now.
• Nethermind: Comfortable with signaling 45M support. A new release is planned but the current version is deemed stable enough for inclusion.
• Erigon: Fully ready for 45M and expects no issues under the proposed changes.

This growing alignment has led to a soft consensus that 45 million is achievable without immediate repricing of other EVM opcodes, provided all clients integrate performance branch fixes in upcoming releases.

Benchmarking Insights

Performance tests have identified several bottlenecks that could affect Ethereum’s scalability beyond the Fusaka upgrade.

ModExp (modular exponentiation) remains the most significant constraint, but it is scheduled for repricing under EIP-7823 and EIP-7883. These changes are expected to reduce its impact on block execution times.

Looking ahead, the alt_bn128 precompiles, specifically EC_ADD, EC_MUL, and EC_PAIRING are likely to become the next major bottlenecks. These cryptographic operations are widely used in zero knowledge applications. Developers are currently expanding test cases to understand how these high frequency routines affect client performance under load.

Another area of concern involves EVM logs and devp2p limits. When blocks emit large volumes of logs, it can overwhelm the devp2p protocol’s message size threshold, which is capped at 10MB. Developers are testing whether this behavior requires repricing or an update to the peer to peer messaging layer, particularly for blocks exceeding 65 million gas.

Lastly, cache flush latency in Geth has emerged as a performance issue. When blocks generate a high volume of storage writes, they can overflow the client’s 256MB state tree buffer. This triggers disk flushes that delay block execution by up to 2.5 seconds. To mitigate this, Geth developers have proposed an asynchronous flushing mechanism with double buffering. This solution will be validated in upcoming shadowfork and perfnet environments.

Next Steps for Gas Limit Scaling

Client teams will continue integrating fixes and performance improvements over the coming weeks. A primary objective is to converge on 45 million gas as the new safe default during Fusaka Devnet 2. This target, if validated across client implementations, could become the basis for a formal proposal to raise the mainnet gas ceiling.

The ultimate decision to raise the gas limit on mainnet will depend on broad client agreement and supporting benchmarks that demonstrate the network can safely handle the additional load without introducing execution regressions or incentivizing validator centralization.

Conclusion

The push toward a 45 million gas limit is a signal of Ethereum’s growing confidence in client optimization and protocol maturity. While not yet finalized, the Fusaka Devnet 2 will be the proving ground for whether Ethereum can safely scale computational capacity ahead of more aggressive targets such as 60M or 100M in future upgrades.

If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.

Related Articles

1. Ethereum Fusaka Devnet 0 Coming Soon
2. Will Fusaka Be Ready in Time? Vitalik's 2025 Vision
3. Glamsterdam: The Next Upgrade After Fusaka
4. Ethereum Developers are Rethinking Transaction Signatures & Authority
5. Censorship Resistance Vs Scalability