Guide to getting a gas refund by deleting data
A guide on how to get a gas refund by deleting data
Table of Contents for Guide to getting a gas refund by deleting data
Did you know that if you delete data from storage, you can get a reduction in gas?
Just like it costs to store things in storage on the blockchain, the opposite is true and if you remove things in storage it reduces your gas.
How deleting data saves gas in EVM
By ‘deleting’ we mean setting a non zero slot to a zero value.
A slot is 256 bits.
You can get a gas refund of up to 15,000 for each state slot that is set to zero.
You have to take into account that originally it cost you (or someone) 20,000 gas to write that data in the first place (cost of changing from zero value to a non zero value). If you change a non zero value to another value then that costs 2,900 gas per slot.
These fees are calculated while the smart contract call is executing, however the refund is paid only after execution.
Because this can reduce your gas cost, one tactic is to store lots of data when gas is very cheap so that you can delete it later on (while gas is expensive) to make a saving. This can help if you are making smart contract calls that take up too much gas.
Read the specification related to gas refunds
For more info check out “Appendix G. Fee Schedule” in the Yellow Paper-EIP-150 for current fees.
Current gas fees related to gas refunds:
The current relevant fees:
Gsreset2,900 gas Paid for an
SSTOREoperation when the storage value’s zeroness remains unchanged or is set to zero
Gsset20,000 gas Paid for an
SSTOREoperation when the storage value is set from zero to non-zero
Rsclear15,000 gas Refund given (added into refund counter) when the storage value is set to zero from non-zero.
Proposal to remove the gas refund
There have been proposals to remove the refund or change how it works. Here are some of the more relevant/interesting ones:
EIP 3529 is another proposal, which aims to remove gas refunds for
SELFDESTRUCT and reduce the gas refund for deleting data. One of the reasons for introducing EIP 3529 is that the refund system encourages users to store data when gas is cheap only to delete it when it is more expensive.
Another issue was that people would sometimes instead of completely deleting data (setting a uint256 to
0 for example), they would keep it at the lowest non zero value (
1), as if they ever needed to set to a non zero value in the future its cheaper to change an already non-zero value to another non-zero value, than it is to go from a zero value to a non-zero value.
A criticism of earlier refund removal EIPs (EIP-3298 and EIP-3403) is that these EIPs fully remove the incentive to set a value to zero, encouraging users to not fully clear a storage slot if they expect even the smallest probability that they will want to use that storage slot again.
For example, if you have 1 unit of an ERC20 token and you are giving away or selling your entire balance, you could instead only give away 0.999999 units and leave the remainder behind. If you ever decide to re-acquire more of that token with the same account in the future, you would only have to pay 5000 gas (2100 for the read + 2900 for nonzero-to-nonzero set) for the
SSTOREinstead of 22100 (20000 for the zero-to-nonzero set). Today, this is counterbalanced by the 15000 refund for clearing, so you only have an incentive to do this if you are more than 15000 / 17100 = 87.7% sure that you will use the slot again; with EIP-3298 or EIP-3403 the counterbalancing incentive would not exist, so setting to nonzero is better if your chance of using the slot again is any value greater than 0%.
A refund of 4800 gas remains, so there is only be an incentive to keep a storage slot nonzero if you expect a probability of more than 4800 / 17100 = 28.1% that you will use that slot again. This is not perfect, but it is likely higher than the average person’s expectations of later re-acquiring a token with the same address if they clear their entire balance of it.
The capping of refunds to 1/5 of gas expended means that this refund can only be used to increase the amount of storage write operations needed to process a block by at most 25%, limiting the ability to use this mechanic for storage-write-focused denial-of-service attacks.
Other interesting EIPs worth reading:
- EIP-3529 Reduction in refunds (selfdestruct)
- EIP-3298 Removal of refunds (Stagnant)
- EIP-1087 Net gas metering for
- EIP 2200 also aims to replace the
SSTOREopcode gas cost calculation (which includes refunds) with new logic (Final)
Find more gas optimization tricks
I have a large article with lots of different gas optimization tricks that you can use in your Solidity code. Check it out if you want to see more Solidity gas saving tips.
Find out more about costs and tips for storage data
See my guide to storage data on the EVM
This post is incomplete and a work-in-progress
I'll update it soon and flesh it out with more info!
Spotted a typo or have a suggestion to make this crypto dev article better? Please let me know!
📙 Solidity Auditing online quiz
Learn how to audit smart contracts by looking at some example code and trying to find the bugs
⛽ Solidity Gas Optimizations Guide
How to optimize and reduce gas usage in your smart contracts in Solidity
🧪 Guide to testing with Foundry
Guide to adding testing for your Solidity contracts, using the Foundry and Forge tools
📌 Guide to UTXO
UTXO and the UTXO set (used by blockchains such as Bitcoin) explained
📐 Solidity Assembly Guide
Introduction guide to using assembly in your Solidity smart contracts
📦 Ethereum EOF format explained
Information explaining what the upcoming Ethereum EOF format is all about