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 Accounting (Unchanged):
Users continue to receive gas refunds for operations that qualify (e.g., setting storage to zero)
When calculating gas for block gas limit enforcement, refunds are not subtracted
Block gas accounting becomes: block.gas_used += max(tx_gas_used, calldata_floor_gas_cost) (incorporating the calldata floor from EIP-7623)
Storage discounts that reflect actual reduced computational work (e.g., warm storage access, reverting to original values) remain applied to block gas accounting
Receipt Changes:
cumulative_gas_used: Now uses gas before refunds, matching block gas accounting
New field gas_spent: Gas actually spent by the transaction after refunds (what the user pays)
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
Receipt structure changes: cumulative_gas_used semantics change and new gas_spent field is added
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
Receipt Fields:
Verify cumulative_gas_used reflects gas before refunds
Verify gas_spent reflects gas after refunds (user cost)
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
Ben Adams (@benaadams), Toni Wahrstätter (@nerolation), "EIP-7778: Block Gas Accounting without Refunds [DRAFT]," Ethereum Improvement Proposals, no. 7778, October 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7778.