Abstract
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
- Note: Since receipts store the post-refund
gas_used value, validating block gas limits using receipts requires tracking refunds during transaction execution and adding them back to each transaction's gas_used when computing cumulative block gas usage
-
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.