This EIP modifies the block gas accounting mechanism to prevent the circumvention of block gas limits. It proposes that gas refunds, particularly those from SSTORE operations setting storage slots to zero, should not reduce the gas counted toward the block gas limit, while still being applied to transaction gas costs for users.
Motivation
Currently, gas refunds from operations like clearing storage slots (setting to zero) reduce both the transaction gas cost for users and the gas counted toward the block gas limit. This creates a discrepancy between the computational work performed and the gas accounted for in the block.
Example: Block 20878522 shows a net usage of 28.5 MGas, but contains 4.01 MGas of refunds, bringing the gross usage to 32.51 MGas—exceeding the block gas limit by 2.51 MGas.
This mechanism can be exploited to perform more operations in a block than the gas limit intends to allow, potentially leading to:
Network instability due to oversized blocks
Denial-of-service vectors
Computational loads exceeding the intended block gas limit
Specification
Gas Accounting Changes
User Gas Costs (Unchanged):
Users continue to receive gas refunds for operations that qualify (e.g., setting storage to zero)
The transaction gas cost remains: tx.gas_used = gas_used - gas_refund
Block Gas Accounting (Modified):
When calculating gas for block gas limit enforcement, refunds are not subtracted
Block gas accounting becomes: block.gas_used += gas_used (without subtracting refunds)
Storage discounts that reflect actual reduced computational work (e.g., warm storage access, reverting to original values) remain applied to block gas accounting
Block Gas Limit Enforcement
The sum of unrefunded gas used by all transactions must not exceed the block gas limit
This ensures the block gas limit accurately reflects the computational and storage workload
Rationale
Aligning Gas Limits with Computational Work
The block gas limit is designed to constrain the computational load per block
Gas refunds were introduced to incentivize “cleaning up” the state, not to allow exceeding computational limits
By excluding refunds from block gas accounting, we ensure the block gas limit effectively constrains computational load
Preserving User Incentives
Users still receive gas refunds, maintaining incentives for efficient state management
Only the accounting for block-level constraints changes, not the economics for individual users
Backwards Compatibility
This change is not backwards compatible and requires a hard fork
User and developer experience for individual transactions remains unchanged
Only block producers need to adjust their transaction selection algorithms to account for the new gas accounting rules
Test Cases
SSTORE Operations:
Setting storage to zero: User receives refund, but block gas accounting uses full cost
Verify blocks containing many storage-clearing operations still adhere to gas limits
Block Gas Limit Edge Cases:
Construct blocks with varying amounts of refundable operations
Ensure blocks cannot exceed gas limits through refund mechanisms
Transaction Gas vs Block Gas:
Verify that transaction costs for users remain unchanged
Confirm block gas accounting properly excludes refunds
Security Considerations
Eliminates potential denial-of-service vectors that exploit gas refunds to exceed block computational limits
Improves predictability of block processing times by enforcing stricter limits on computational work
Prevents miners/validators from including transactions that collectively contain more computational work than intended
Copyright
Copyright and related rights waived via CC0 1.0 Universal.
Citation
Please cite this document as:
Ben Adams (@benaadams), Toni Wahrstätter (@nerolation), "EIP-7778: Block Gas Limit Accounting without Refunds [DRAFT]," Ethereum Improvement Proposals, no. 7778, October 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7778.