Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal to include EIP 3298 (removal of refunds) in London #255

Closed
vbuterin opened this issue Feb 26, 2021 · 6 comments
Closed

Proposal to include EIP 3298 (removal of refunds) in London #255

vbuterin opened this issue Feb 26, 2021 · 6 comments

Comments

@vbuterin
Copy link
Collaborator

EIP here: ethereum/EIPs#3298

Simple Summary

Remove gas refunds for SSTORE and SELFDESTRUCT.

Motivation

Gas refunds for SSTORE and SELFDESTRUCT were originally introduced to motivate application developers to write applications that practice "good state hygiene", clearing storage slots and contracts that are no longer needed. However, they are not widely used for this, and poor state hygiene continues to be the norm. It is now widely accepted that the only solution to state growth is some form of statelessness or state expiry, and if such a solution is implemented, then disused storage slots and contracts would start to be ignored automatically.

Gas refunds additionally have multiple harmful consequences:

  • Refunds give rise to GasToken. GasToken has benefits in moving gas space from low-fee periods to high-fee periods, but it also has downsides to the network, particularly in exacerbating state size (as state slots are effectively used as a "battery" to save up gas) and inefficiently clogging blockchain gas usage
  • Refunds increase block size variance. The theoretical maximum amount of actual gas consumed in a block is nearly twice the on-paper gas limit (as refunds add gas space for subsequent transactions in a block, though refunds are capped at 50% of a transaction's gas used). This is not fatal, but is still undesirable, especially given that refunds can be used to maintain 2x usage spikes for far longer than EIP 1559 can.
@timbeiko timbeiko changed the title Proposal to include EIP 3298 (removal of refunds) in Longon Proposal to include EIP 3298 (removal of refunds) in London Feb 27, 2021
@vbuterin
Copy link
Collaborator Author

vbuterin commented Mar 2, 2021

Some possible alternative options to try to address some people's concerns around breaking economics for within-transaction approvals and other situations.

Simpler solution

In the case where original = new = 0 != current, SSTORE only deducts SLOAD_GAS (cold read costs would continue to be applied on top, so ~2200 gas would be charged in total). This adds some incentive to set a storage value back to zero instead of nonzero.

More comprehensive solution

Replace the "refund" counter with two counters: (i) a new_storage_slots_filled counter that increments every time a storage slot goes from zero to nonzero, and (ii) a storage_slots_cleared counter that increments every time a storage slot goes from nonzero to zero. At the end of a transaction, refund 15000 * max(storage_slots_cleared - new_storage_slots_filled, 0) gas. So every 15000 gas refunded must be matched by 15000 gas storage-increase gas paid, and so the maximum amount of gas spent on execution would not be able to exceed the gas limit.

@Genysys
Copy link

Genysys commented Mar 8, 2021

I think an under appreciate benefit of removing this opcode is that it would make gas easier to estimate with most clients / wallets.

My intuition behind this is that most clients do not check for refunds, as that context isnt available to the RPC endpoint.

For reference , here is how Geth implements it

@saaqibz
Copy link

saaqibz commented Mar 8, 2021

@Genysys That is a definitely a benefit, but I wonder if you could get that in a different way. E.g., defi gas futures contracts. The downsides from the gas token exploit seems to outweigh this benefit.

@timbeiko
Copy link
Collaborator

timbeiko commented Mar 8, 2021

@Genysys I'm not sure I understand your comment. This EIP doesn't remove the entire opcode, just the refund that gets sent back at the end of execution. It is a step in that direction, though.

@saaqibz
Copy link

saaqibz commented Mar 11, 2021

I think @Genysys is talking about the economic incentive to remove opcode not the feature itself.

@timbeiko
Copy link
Collaborator

Closing this as 3403 was noted as the prefered EIP on ACD108.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants