Removal of refunds

[vbuterin]

Remove gas refunds for SSTORE and SELFDESTRUCT.

[The-3D]

I'm curious to know if any study has being made on what will be the impact of removing refunding after cleaning up the state. Is the state bloat due to gastoken minting really worth removing a gas saving feature and an incentive to keep the state in check for smart contract developers?
I went through hell sometimes in the past trying to clean up the state, pretty damn sure i won't do the same if no refunds are being made. Let's see if it's actually worth removing state management incentives or not.

[lightclient]

@The-3D please see the motivation in the EIP, it says this EIP is more motivated by reducing the variability of the block size.

[vorot93]

@The-3D

"GasTokens" are not a gas saving "feature" - it's an exploit in the gas calculation for the more cunning, at the expense of everyone else and the nodes.

State should not be naively "cleaned up", as it makes client implementations a lot more complex. We should explore alternative solutions like reGenesis.

[The-3D]

@The-3D please see the motivation in the EIP, it says this EIP is more motivated by reducing the variability of the block size.

It says both, and to be honest far more relevance is given to state bloat due to the gasToken (it even mentions block size variance as undesiderable, but not fatal). I can understand the block size variability of course, what i'm asking is if there is any research/simulation on estimated impact on the network should this EIP go through.

I also don't agree with this
However, they are not widely used for this, and poor state hygiene continues to be the norm.

This might be true for many contracts (maybe the majority) but for sure it's not true for the most used ones (the ones that actually generate the majority of the activity on the network). Most of the best protocols out there that i checked, including top Defi protocols, have excellent state management.

[The-3D]

@The-3D

"GasTokens" are not a gas saving "feature" - it's an exploit in the gas calculation for the more cunning, at the expense of everyone else and the nodes.

State should not be naively "cleaned up", as it makes client implementations a lot more complex. We should explore alternative solutions like reGenesis.

I never said anything against this. In fact, i agree with both. I'm all for finding an alternative way for state management, manual garbage collection is painful and error prone.

[0xSachinK]

LGTM!!

[greenlucid]

Isn't this a bit drastic?

[vbuterin]

Isn't this a bit drastic?

See this doc for my more generalized case in favor of doing drastic things between now and the merge: https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/evm_feature_removing

Most of the best protocols out there that i checked, including top Defi protocols, have excellent state management.

I think the most important category that even the best state management practices can't avoid is users forgetting about some application. Has anyone who stopped using MakerDAO self-destructed their CDP? Do orders on an on-chain order book that just never get filled because the price moves in one direction soon after they're made ever get deleted? Do airdrop tokens worth $0.001 ever go away? There's this large unavoidable category of state growth that comes from users ceasing to interact with some application (or ethereum entirely) and not bothering to clean up their state, and only some form of statelessness or state expiry (including regenesis) can fix that.

[k06a]

Maybe to keep this refunds for storage dirtied in the same tx? Else this would explode gas costs for thing like approve+transferFrom :(

[vbuterin]

Increasing remaining gas by 15000 when storage goes from (orig=zero, current=nonzero) to (orig=zero, current=zero) seems reasonable, and additionally ensures that total in-block gas usage cannot exceed the gaslimit, though it would violate an invariant in that a child call with N gas would be able to execute more than N gas [but I'm not sure anyone actually uses that invariant; it would be certainly dangerous from a security perspective to do so]. Seems worth discussing.

[GNSPS]

Seeing this purely from an attack surface mitigation position I fully support this EIP.
The rationale of rolling back a decision that did not add to a better state utilization is also sound.

Fully backing this up as I hope ConsenSys Diligence will. 👍

[jomarip]

Honestly, I did not know I could self-destruct contracts and assets. What is the process for doing this so I can clean up while I wait for this to pass

[Dadybayo]

It is important to think about the security of the Ethereum blockchain rather than the benefits of the protocols. Yes, Gas token hacked the rules of the Ethereum game, but it did not bring anything developing to the market

Now it is important to focus on Layer 2 solutions and only together we can build a new world!

[greenlucid]

Isn't this a bit drastic?

See this doc for my more generalized case in favor of doing drastic things between now and the merge: https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/evm_feature_removing

Thanks, I know understand the rationale behind this.
A bit related and drastic: should gas costs of EVM opcodes stay static? Should they be voted, like miners vote for gas limit? Wondering about possible perverse incentives that allowing for fluid costs of EVM opcodes could make. The advantage I see is that maybe processing-related opcodes could be agreed by miners to stay cheaper, and memory-related opcodes could be considered more expensive by miners.
SUM, a very cheap computation instruction costs 3 gas, meanwhile a permanent store opcode SSTORE costs 20k. Computers can compute millions of SUM operations in a second, but a SSTORE will make the state increasingly heavier for whoever comes next. This is just my perception on why I think gas costs look a bit rigid and arbitrary to me.

[wjmelements]

Please defer discussion here

[jochem-brouwer]

Another side-effect worth mentioning is that eth_estimateGas returns the amount of gas paid for. However, due to refunds, the gasLimit one should use could be higher (up to 2x the reported estimated gas).

[wjmelements]

No, eth_estimateGas reflects the required gas limit.

…

On Fri, Feb 26, 2021 at 2:54 PM Jochem Brouwer ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In EIPS/eip-3297.md <#3298 (comment)>: > +created: 2021-02-26 +--- + +## 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 ***@***.***/state_size_management), 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](https://gastoken.io/). 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 ***@***.***/eip_1559_spikes), but is still undesirable, especially given that refunds can be used to maintain 2x usage spikes for far longer than EIP 1559 can. + Another side-effect worth mentioning is that eth_estimateGas returns the amount of gas paid for. However, due to refunds, the gasLimit one should use could be higher (up to 2x the reported estimated gas). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3298 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGDGVJVGGF4EC7CD4IIGCTTBARD3ANCNFSM4YIPWMHA> .

[jochem-brouwer]

It should be noted that currently we can create blocks which execute almost 2x the gas limit of the block in gas (if each transaction gets the max 50% refund). So this EIP effectively halves the maximum gas executed in the worst case. This will definitely impact how much transactions fit in a block, since now any transaction which used a refund, is now more expensive.

[jochem-brouwer]

I just moved these points to magicians.

@wjmelements if you have a very simple transaction, where a storage slot of a contract has a nonzero value, and the code only SSTOREs 0 to that slot, then estimateGas will (IIRC) report that you need something like 13000 gas for the entire transaction (since this is what you are charged), but is obviously incorrect. So it does not reflect the right gas limit (unless I'm missing something here).

[seaofstars2020]

If no refund, will SSTORE be cheaper?