EIP-7825 Transaction Gas Limit Cap
Final · Fees & gas · EIP status Final · created 2024-11-23
Limits the gas a single transaction can use to 16,777,216 (2^24) at the protocol level. This cap applies regardless of the block gas limit.
Why it is needed
Today a single transaction can in theory use the entire block gas limit by itself. Such very large transactions carry three risks. First, one transaction can monopolize the block processing load and become a channel for denial-of-service (DoS) attacks that shake the network. Second, transactions that use a lot of gas usually cause large state changes, which quickly inflates the data nodes must store. Third, block validation takes longer, which hurts user experience and network decentralization. These risks grow as the block gas limit rises. Capping the gas a single transaction can use reduces the single-transaction DoS risk, distributes gas more evenly within a block, and prevents extreme block validation times, which stabilizes synchronization between nodes.
What changes
Today
- A single transaction can in theory use the entire block gas limit
- A very large transaction can extend block validation time dramatically
- Gas distribution within a block can be concentrated in one transaction
After EIP-7825
- A single transaction can use at most 16,777,216 (2^24) gas
- A transaction above the cap is rejected in both the transaction pool and block validation
- Block validation time becomes more even and predictable
Who is affected
- Users: Most transactions today use far less gas than the cap, so they continue to work as they are.
- Wallet & app developers: Tools and dapps need a small update to reflect the new cap. Operations that exceed the cap, such as large contract deployments, must be split across multiple transactions.
- Client teams: Adds the cap check to transaction pool validation and block validation, and caps the transaction's GAS_LIMIT parameter at 16,777,216.
- Validators: The block gas limit can stay higher than the cap. As long as each individual transaction in a block respects the cap, the block is processed as usual.
In depth
Cap Value and Scope
No transaction may specify a gas limit above 16,777,216 (2^24) gas. This cap applies independently of the block gas limit set by miners or validators, and even if the block gas limit is higher than this value, the cap still applies to each individual transaction. A transaction that specifies a gasLimit above the cap is rejected with an appropriate error code such as MAX_GAS_LIMIT_EXCEEDED. In client implementations, the transaction's GAS_LIMIT parameter is capped at 16,777,216.
Two-Stage Validation: Transaction Pool and Block
Enforcement happens at two points. First, at transaction validation, if the gasLimit specified by the sender exceeds 16,777,216, the transaction is treated as invalid and is not included in the transaction pool. Second, at block validation, as part of pre-processing checks, a block that contains even one transaction whose gasLimit exceeds 16,777,216 is judged invalid as a whole and rejected. This structure also closes the path of bypassing the transaction pool and placing such a transaction directly in a block.
Why 16,777,216 (2^24)
Because it is a power-of-two boundary, the value keeps implementation simple while still being large enough to accommodate most complex transactions, including contract deployments and complex DeFi interactions. It is about half of a typical block size (30 to 40 million gas), so it guarantees that several transactions can fit in one block.
Backwards compatibility and scope of impact
This is not backward compatible with transactions that specify a gas limit above 16,777,216. Such transactions must be split into several smaller operations. However, most transactions today sit far below the proposed cap, so very few users and dapps are expected to be affected. Transactions whose gas usage is under the cap are unaffected, and existing tooling and dapps only need a small update to reflect the new cap. An empirical analysis to assess the potential impact has also been carried out.
Security benefits and remaining challenges
A fixed cap reduces the risk of DoS attacks caused by transactions that consume excessive gas. When a cap applies to each individual transaction, block validation becomes more predictable and uniform. Extreme cases remain an open problem. Some very complex transactions, such as large contract deployments, may need to be redesigned to fit within the 16,777,216 gas cap.