EIP-3978

Gas refunds on reverts

Reprice reverted SSTORE/CREATE/SELFDESTRUCT/LOGX operations gas via gas refund mechanism

StagnantStandards Track: Core

Created: 2021-09-16

Anton Bukov (@k06a), Mikhail Melnik (@ZumZoom)

1 min read

EIP-3978, titled "Gas refunds on reverts," proposes that for reverted state modification operations, the access cost should be kept, but the modification cost should be refunded. The motivation behind this proposal is that reverting a transaction, or any of its sub-calls, drops any state modifications that happened inside. However, users are currently charged for the dropped modifications as if they persisted. The proposal specifies that for each call frame, a revert_gas_refund should be tracked, initially set to 0. The set of operations that modify revert_gas_refund include SSTORE, LOG0-LOG4, CALL, CREATE, CREATE2, and SELFDESTRUCT. These operations increase revert_gas_refund as follows: call.revert_gas_refund += operation.gas - WARM_STORAGE_READ_COST. In case of a revert, this value is used instead of just erasing gas_refund. The rationale behind this proposal is that gas should reflect the cost of use. The revert cost reflects the cost of access during execution, but not the cost of modification. The document mentions that there are no known backward compatibility issues associated with this proposal. The test cases, reference implementation, and security considerations are yet to be determined.

Video

Anyone may contribute to propose contents.

Go propose

Original

Abstract

For reverted state modification operations, keep access cost, but refund modification cost.

Motivation

Reverting a transaction, or any of its sub-calls, drops any state modifications that happened inside. But now, users are being charged for the dropped modifications as if they persisted.

Since EIP-3298, the gas refund mechanism works for storage restores only inside the same transaction. But on revert, the gas refund is not increased; it is completely erased. It can even be cheaper to transfer tokens back at the end of a transaction instead of reverting, to keep the existing gas refund. This should be changed.

Reverted SSTORE deserves to be repriced to SLOAD gas (100 gas)
Reverted LOG0, LOG1, LOG2, LOG3 and LOG4 deserve to be repriced to 100 gas
Reverted CALL with value (positive_value_cost = 9,000 gas) deserves to be repriced to 100 gas
Reverted CALL with value and account creation (value_to_empty_account_cost = 25,000 gas) deserves to be repriced to 100 gas
Reverted CREATE and CREATE2 (32,000 gas) deserve to be repriced to 100 gas
Reverted SELFDESTRUCT (5,000 or 25,000 gas) deserves to be repriced to 100 gas

Moreover, it seems fair to charge CREATE and CREATE2 operations 32,000 fix price conditionally only if returned bytecode is not empty.

Specification

For each callframe, track revert_gas_refund, initially 0.

The set of operations that modify revert_gas_refund are:

SSTORE
LOG0, LOG1, LOG2, LOG3, LOG4
CALL
CREATE, CREATE2
SELFDESTRUCT

They increase revert_gas_refund as follows:

call.revert_gas_refund += operation.gas - WARM_STORAGE_READ_COST

And in case of revert let's use this value instead of just erasing gas_refund:

if (call.reverted) {
    // existing behavior
    tx.gas_refund -= call.gas_refund;
    
    // New behavior added to existing according to the EIP-3978
    tx.gas_refund += call.revert_gas_refund;
}

Rationale

Gas should reflect the cost of use. The revert cost reflects the cost of access during execution, but not the cost of modification.

Backwards Compatibility

No known backward incompatibilities.

Test Cases

TBD

Reference Implementation

TBD

Security Considerations

TBD

Copyright

Adopted by projects