Did you know that EVM has the functionality of rewarding users with a gas refund for clearing the on-chain storage occupied by 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 gas calculations easy to understand. I have copied some gas amounts directly from the Ethereum Yellow paper, let’s see what are they: 1. Gcoldsload — 2,100 Cost of a cold storage access. 2. Gsset — 20,000 Paid for an SSTORE operation when the storage value is set to non-zero from zero. 3. Gsreset — 2,900 Paid for an SSTORE operation when the storage value’s zeroness remains unchanged or is set to zero. 4. Rsclear — 15,000 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 5,000, 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 21,000. This gas is consumed by the validator to determine whether the transaction is valid or not. 21,000 is added to every transaction and it is not in our control, so every transaction consumes 21,000 + whatever gas the function data needs. The gas calculations below will implicitly include 21,000 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 the London Fork The EVM refunds gas to the user in two cases. First, if you are calling the function, gas is refunded from the total consumed gas. This was simple and there’s nothing to talk about as the gas refund functionality for was removed in EIP-3529 and recently the method is also deprecated. selfdestruct 24,000 selfdestruct selfdestruct Second, if you set any variable to its default value, you get a refund of 15,000. 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. 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. Mechanism: 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 , but the total gas consumed in this transaction is , half of which is , now becomes the maximum amount of gas that can be refunded which means the transaction will now cost you gas. 15,000 24,000 12,000 12,000 24,000 — MAXIMUM_GAS_REFUNDABLE = 24000–12000 = 12000 Although we were expecting to get gas back, the limit got capped at , hence reducing the amount to . What if our transaction is consuming gas? In this case, half of is which is greater than so we will get a refund of gas. 15,000 12,000 12,000 40,000 40,000 20,000 15,000 15,000 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 . 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 . EXECUTION_COST+ 21,000 15,000 * 8 = 120,000 Wait, if this is the refund amount then how much gas is our transaction consuming? When you calculate the gas to be consumed you will get the amount of approx . Now, what will happen if gas is refunded on a transaction of ? The miner will end up paying for the transaction, this is why the capping mechanism was introduced. 61,000 120,000 61,000 According to the formula, the maximum gas to be refunded will be . So the gas consumed will be instead of . Now I think this is pretty clear to you, but this method is no more valid after the London upgrade. 61000/2 = 30500 61000–30500 = 30500 61000 – 1,20,000 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. The refund gas amount is now reduced to 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. 4,800 In the first case, if we are setting only one variable to zero, the transaction is consuming . when we notice the maximum gas rule in EIP-3529, it says TOTAL_GAS_CONSUMED divided by 5, which is in our case equals , which means we were eligible for a maximum refund of in this transaction but as mentioned in the EIP-3529 the refund amount is . This time is refunded to us and the transaction costs (some additional gas). 26,000 26,000/5 5,200 5,200 4,800 4,800 2,1400 gas Let’s take the second case where we were setting 8 variables to zero. The gas consumed is still . Talking about the refund, we expect a total refund of , meaning the consumption we expect is . 61,000 4,800 * 8 =38,400 61000–38400 = 22600 But when you execute this transaction, you will notice that the gas consumed is . Now you understand that the gas to be refunded is capped to a maximum of which means the transaction will consume a total of . 49,000 61,000/5 = 12,200 61,000–12,200 ~ 49,000 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 , or . Twitter LinkedIn, telegram Also published . here

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch

Fungible Tokens: Tracing the Evolution of Digital Assets 

How the Ethereum Blockchain Incentivizes Users to Clear Storage

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

An Update to Solidity’s ‘Assert()’ Statement You Might’ve Missed

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

An Update to Solidity’s ‘Assert()’ Statement You Might’ve Missed

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps