EIP-7935 Final

Set default gas limit to 60M

Authors: , , , , , , , , , ,

Canonical data: /latest/eips/7935.json

Recommend a new gas limit value for Fusaka and update execution layer client default configs

Timeline

Fusaka

Included

EIP Created Apr 22, 2025

Key Benefits

● Directly increases mainnet throughput
● Enables more complex smart contracts
● Reduces transaction queuing during high demand
● Improves confirmation times

Trade-offs & Considerations

No trade-offs documented yet.

Stakeholder Impact

End Users

Benefits from higher throughput and faster transaction processing, but potential risks if inadequately tested or if RPC infrastructure can't keep up.

Application Developers

Can build more sophisticated applications without hitting gas limits, but need to be aware that the specific limit value is still TBD.

Wallet Developers

Better user experience with faster confirmations, but RPC node performance impacts could affect wallet reliability.

Tooling / Infrastructure

RPC providers, indexers, and monitoring tools need significant updates to handle larger blocks and higher computational loads.

Layer 2s

More block space available for settlement transactions, but coordination needed with EIP-7825's 30M transaction cap.

Stakers & Node Operators

Need significantly more computational power to process larger blocks. Validator hardware requirements may increase substantially.

CL Client Developers

Must handle larger execution payloads and ensure consensus layer can propagate larger blocks within gossip limits.

EL Client Developers

Major testing and bug-fixing effort required to handle larger blocks safely. Must update default gas limit configurations and ensure stability at higher computational loads.

North Star Goal Alignment

● Scale L1: Directly increases overall network throughput by allowing more computation per block, the most straightforward way to scale L1 execution capacity.

Abstract

The gas limit on mainnet is currently 36M. This should be significantly increased to 60M by the time Fusaka is released by execution layer clients updating their default configurations.

Motivation

There is currently great interest in scaling L1 execution. This can likely be done to some extent without implementing any new features. However, it requires guidance from EL devs as we expect to find bugs in clients at higher gas limits than currently used on mainnet. This will require time from client developers both to test and to fix any bugs that arise, therefore it makes sense to include as an EIP in a hard fork to commit to this.

Specification

Execution layer clients have different configuration formats. They should all update the gas limit value generated in their default configurations to 60M.

Rationale

In the past there has been some difficulty coordinating EL clients to update gas limit values in their default configurations. Therefore we suggest tying a new value to a hard fork release.

Backwards Compatibility

A higher gas limit should not break any existing contracts. It is possible that with a higher limit new transactions could exceed the proposed 30M transaction gas limit, so the scheduling of these two EIPs should be coordinated.

Security Considerations

Devnets will be stood up with nodes running all combinations of EL and CL clients in order to test if a gas limit of 60M is safe. Synthetic transactions will be created until blocks are full, and network and node health monitored. If bugs are discovered, client teams will patch them and then start the process again. If everything looks good, the gas limit will be increased incrementally.

Adversarial block constructions that would increase the worst-case size have already been researched and should not be a factor below 150M gas because this is close to where the current worst-case block size of 1.79 MiB would reach the current 10MiB CL gossip limit.