How to clear storage and get incentivized by Ethereum Blockchain ?

Do you know EVM has the functionality of rewarding users with a gas refund for clearing the on-chain storage occupied by the contract data?

Let’s learn more about this. There have been some changes after the London fork. But to understand it better we will look at the scenario before London Upgrade and then we will see the changes proposed in the London upgrade.

But before starting with refunds we should get a bit of understanding about storage gas consumption, this will make the gas calculations easy to understand for you.

I have copied some gas amounts directly from the Ethereum Yellow paper, let’s see what are they.
1. Gcoldsload — 2100 Cost of cold storage access.
2. Gsset — 20000 Paid for an SSTORE operation when the storage value is set to non-zero from zero.
3. Gsreset — 2900 Paid for an SSTORE operation when the storage value’s zeroness remains unchanged or is set to zero.
4. Rsclear — 15000 Refund given (added into refund counter) when the storage value is set to zero from non-zero.

Let’s quickly understand this.
1. Gcoldsload — you have to pay every time you access any storage variable for the first time in a function, the second or consecutive times it costs 100 gas.
2. Gsset — Pay every time you set any variable from zero value to non-zero(false to true in case of bools). In simple words, you are changing the default value and the nodes now have to keep track of that slot.
3. Gsreset — Pay every time you set a non-zero value to a non-zero or zero value.
4. Rsclear — Whenever you set any value to its default value you get the refund.

Remember these points before we start

• Whenever we set any value from non-zero to non-zero or non-zero to zero, we collectively say the gas consumed to be 5000, adding Gcoldsload and Gsreset.
• Every transaction will consume all the related gas while executed and the refund is calculated at the very end of the transaction.
• There is an initial gas attached to every transaction which is 21000. This gas is consumed by the validator to make sure the transaction is valid or not. 21000 is added to every transaction and it is not in our control, so every transaction consumes 21000 + whatever gas the function data needs.
• The gas calculations below will implicitly include 21000 gas.

The refunds work whenever you set something to its default value, for uint it is zero for a boolean it’s false, etc. For ease of understanding, I’ll be taking examples of uint.

Before London Fork

The EVM refunds gas to the user in two cases. First, if you are calling selfdestructfunction, 24000 gas is refunded from the total consumed gas. This was simple and there’s nothing to talk about it as the gas refund functionality for selfdestruct was removed in EIP-3529 and recently the selfdestruct method is also deprecated. So, there is no reason to talk about it.
Second, if you set any variable to its default value, you get a refund of 15000. Why does it happen? Setting the value to default value means you are clearing the storage because the nodes don’t need to track that particular slot of storage you just cleared.

This is a screenshot of the Ethereum Yellow paper stating the refund amount.

But there is a proper way of calculating the gas to refund.

Here is the reference from the Ethereum Yellow paper.

Mechanism: The refund is given at the end of any transaction and capped at a maximum number. That maximum number is half of the total used gas.
let’s understand it with the example of uint. What happens when we set any non-zero uint value to zero?

Suppose you are setting a single uint variable to zero in a transaction so the total applicable refund will be 15000, but the total gas consumed in this transaction is 24000, half of which is 12000, now 12000 becomes the maximum amount of gas that can be refunded which means the transaction will now cost you
24000 — MAXIMUM_GAS_REFUNDABLE = 24000–12000 = 12000 gas.

Although we were expecting to get 15000 gas back, the limit got capped at 12000, hence reducing the amount to 12000. What if our transaction is consuming 40000 gas? In this case, half of 40000 is 20000 which is greater than 15000 so we will get the refund of 15000 gas.

This was the case when you are setting only one uint variable to zero, what will happen if we are setting multiple uint variables to zero? For example

contract { 

      uint256 count = 1;  
      uint256 count2 = 2;    
      uint256 count3 = 3;  
      uint256 count4 = 3;  
      uint256 count5 = 3;  
      uint256 count6 = 5;  
      uint256 count7 = 6;   
      uint256 count8 = 6;   
      
  function setTOzero() external {  
     count = 0;     
     count2 = 0;    
     count3 = 0;    
     count4 = 0;    
     count5 = 0;    
     count6 = 0;     
     count7 = 0;      
     count8 = 0;    
 }
 
}
//Transaction cost will be 21000+ execution cost//execution cost = 8 * (Gcoldsload +Gsreset) = 8 * 5000 = 40000// Transaction cost = 21000 + 40000 = 61000

Whatever your transaction cost is the EXECUTION_COST+ 21000. Now the refund is calculated based on how many variables you are setting to default. In this case, we are setting 8 uint variables to zero so the refundable amount counts to be 15000 * 8 = 1,20,000.

Wait, if this is the refund amount then how much gas our transaction is consuming? When you will calculate the gas to be consumed you will get the amount of approx 61000. Now, what will happen if 1,20,000 gas is refunded on a transaction of 61000? The miner will end up paying for the transaction, this is why the capping mechanism was introduced.

According to the formula, the maximum gas to be refunded will be 61000/2 = 30500. So the gas consumed will be 61000–30500 =30500 instead of 61000 – 1,20,000. Now I think this is pretty clear to you, but this method is no more valid now after London upgrade. If you want to test this then you can switch to the Berlin version of VM in Remix IDE and watch everything working.

Now let’s see what has changed in the London upgrade.

Post London Upgrade

These numbers have changed after the introduction of EIP-3529 in the London upgrade. Let’s see what has changed. The refund gas amount is now reduced to 4800 and the maximum amount that can be refunded now is one-fifth of the gas consumed. Let’s understand with the same approach as before.

In the first case, if we are setting only one variable to zero, the transaction is consuming 26000. when we notice the maximum gas rule in EIP-3529, it says TOTAL_GAS_CONSUMED divided by 5, which is in our case 26000/5 equals 5200, that means we were eligible for a maximum refund of 5200 in this transaction but as mentioned in the EIP-3529 the refund amount is 4800. This time 4800 is refunded to us and the transaction costs 21400 gas(some additional gas).

Let’s take the second case where we were setting 8 variables to zero. The gas consumed is still 61000. Talking about the refund, we expect a total refund of 4800 * 8 =38400, meaning the consumption we expect is
61000–38400 = 22600. But when you will execute this transaction, you will notice that the gas consumed is 49000, now you get the point that the gas to be refunded is capped to a maximum of 61000/5 = 12200 which means the transaction will consume a total of 61000–12200 ~ 49000.

You might be thinking what caused the gas refunds to get lower in the London upgrade. Look at the reasons I have copied from the official EIP website:

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, the benefits of this technique have proven to be far lower than anticipated, and gas refunds have had multiple unexpected 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.

The concept of gas refund must be clear to you now. The more you play with this on remix the more you will understand the calculations. Why not try executing some real-world functions? As the ones I wrote above are just examples. You can try to see the gas consumption in real contracts like the transfer function ERC20 when the balance is about to get zero. Let me know what you find by these experiments:)

Have any questions about this topic? Ask me anytime, on Twitter, LinkedIn, or telegram.