EIP-7825 Final

Transaction Gas Limit Cap

Authors: ,

Canonical data: /latest/eips/7825.json

Introduce a protocol-level cap on the maximum gas used by a transaction to 16,777,216 (2^24).

Timeline

Fusaka

Included

EIP Created Nov 23, 2024

Key Benefits

● Prevents single transactions from hogging block space
● Ensures fairer access for all users
● Reduces network instability risks
● Enables safer block capacity increases

Trade-offs & Considerations

No trade-offs documented yet.

Stakeholder Impact

End Users

Most users unaffected as typical transactions use far less than 16.8M gas. Edge cases with very complex operations may need to restructure.

Application Developers

Applications with very large transactions (complex DeFi, large contract deployments) may need to split operations or redesign architecture to stay under the cap.

Wallet Developers

Need to enforce the gas cap in transaction creation, but most wallet operations are well below the limit.

Tooling / Infrastructure

Gas estimation tools, transaction builders, and deployment scripts need updates to enforce the 16.8M gas cap.

Layer 2s

Could impact future L2 bundling strategies and settlement transaction designs. May conflict with efficient batch processing approaches.

Stakers & Node Operators

More predictable block processing times and reduced risk of validation bottlenecks from extremely large transactions.

CL Client Developers

No direct impact on consensus layer operations as this affects execution layer transaction validation.

EL Client Developers

Need to implement transaction pool validation to reject transactions exceeding the gas cap and block validation to reject blocks containing invalid transactions.

North Star Goal Alignment

● Scale L1: Improves network stability and resilience against DoS attacks by preventing individual transactions from consuming excessive block space, enabling more predictable block validation times.
● Improve UX: More predictable transaction inclusion and fairer access to block space, though may require some large applications to restructure their operations.

Abstract

This proposal introduces a protocol-level cap on the maximum gas usage per transaction to 16,777,216 (2^24) gas. By implementing this limit, Ethereum can enhance its resilience against certain DoS vectors, improve network stability, and provide more predictability to transaction processing costs, especially in the context of increasing the gas limit.

Motivation

Currently, transactions can theoretically consume up to the entire block gas limit, which poses several risks:

DoS Attacks: A single transaction consuming most or all of the block gas can result in uneven load distribution and impact network stability.
State Bloat Risks: High-gas transactions often result in larger state changes, increasing the burden on nodes and exacerbating the Ethereum state growth problem.
Validation Overhead: High-gas transactions can lead to longer block verification times, negatively impacting user experience and network decentralization.

By limiting individual transactions to a maximum of 16,777,216 gas, we aim to:

Reduce the risks of single-transaction DoS attacks.
Promote fairer gas allocation across transactions within a block.
Ensure better synchronization among nodes by mitigating extreme block validation times.

Specification

Gas Cap

Enforce a protocol-level maximum of 16,777,216 gas (2^24) for any single transaction.
This cap applies regardless of the block gas limit set by miners or validators.
Transactions specifying gas limits higher than 16,777,216 gas will be rejected with an appropriate error code (e.g., MAX_GAS_LIMIT_EXCEEDED).

Changes to EVM Behavior

Txpool Validation: During transaction validation, if the gasLimit specified by the sender exceeds 16,777,216, the transaction is invalidated (not included in the txpool).
Block Validation: As part of block validation before processing, any block having a transaction with gasLimit > 16,777,216 is deemed invalid and rejected.

Protocol Adjustment

The GAS_LIMIT parameter for transactions will be capped in client implementations at 16,777,216.
This cap is independent of the block gas limit, which exceeds this value.

Rationale

Why 16,777,216 (2^24)?

The proposed cap of 16,777,216 gas (2^24) provides a clean power-of-two boundary that simplifies implementation while still being large enough to accommodate most complex transactions, including contract deployments and advanced DeFi interactions. This value represents approximately half of typical block sizes (30-40 million gas), ensuring multiple transactions can fit within each block.

Compatibility with Current Gas Dynamics

Backward Compatibility: Transactions with gas usage below 16,777,216 remain unaffected. Existing tooling and dApps need only minor updates to enforce the new cap.
Impact on Validators: Validators can continue to process blocks with a gas limit exceeding 16,777,216, provided individual transactions adhere to the cap.

Backwards Compatibility

This change is not backward-compatible with transactions that specify gas limits exceeding 16,777,216. Transactions with such high limits will need to be split into smaller operations. This adjustment is expected to impact a minimal number of users and dApps, as most transactions today fall well below the proposed cap.

An empirical analysis has been conducted to assess the potential impact of this change.

Security Considerations

DoS Mitigation: A fixed cap reduces the risk of DoS attacks caused by excessively high-gas transactions.
Block Verification Stability: By capping individual transactions, the validation of blocks becomes more predictable and uniform.
Edge Cases: Certain highly complex transactions, such as large contract deployments, may require re-architecting to fit within the 16,777,216 gas cap.