Thread by @lightclients

Smart contract developers:

How much does the storage refund need to decrease before you start using a different value to represent 0?

The London hard fork in July will almost certainly modify the behavior of refunds. There have been several iterations, but the latest is EIP-3529: Reduction in refunds.

I recommend reading the EIP as it is very thorough and explains the past proposals, however the main case we care about for this thread is setting a nonzero storage element to zero and the refund that incurs.

eips.ethereum.org/EIPS/eip-3529

EIP-3529 reduces the storage clearing refund from 15,000 to 4,800. The reasoning is that for gas tokens to work, the refund needs to be greater than the cost of zeroing out the storage element.

Since clearing a storage element costs 4,800 and it refunds 4,800, therefore there is no net-gain to clearing storage, and it can’t be used as a battery for locking up gas during periods of inactivity and deployed during congestion.

Aside - this thread isn’t about gas tokens or the importance of reducing the elasticity of blocks. I recommend reading the EIP, reviewing the last few ACDs, and directing discussions on these topics to ethereum magicians forum.

Before Berlin, it cost 20,000 to initialize a new storage element and 5,000 to modify and existing one. Therefore, it never made *not* to zero out storage elements when zeros occurred naturally, since you’d be refunded 15,000.

After Berlin, it costs 22,100 to initialize a new storage element and it costs 5,000 to modify an existing one. The difference of 17,100 can be considered the refund inflection point at which you’d always clear storage.

With the current refund of 15,000, you would need to be 15,000/17,100 = 87.7% sure that you’ll reuse that slot before you should consider using a nonzero value to represent zero.

After EIP-3529, the refund would be 4,800, so you need to be 4,800/17,100 = 28.1% sure that you will not reuse that slot at a later point. If you think there is a decent chance of reusing the slot, you’re better off using a nonzero value to represent zero.

This then yields the question for developers - would this reduction cause you to change the way you write your contract?

I would guess the answer would be “yes” for many if this was to be the expected behavior long term. So, it’s important to mention though that in the next 1.5-3 years there will be modifications to state trie that will completely remove the concept of cross-tx refunds.

The state trie considers zero and nil as the same thing. When a element is zeroed out, it is dropped from the trie. In the future, there will be a distinction between the two. The reasons and mechanisms are for another thread, but for those curious - check out “regenesis”.

Once zero and nil are each unique values, there will be no advantage to representing zero with a nonzero value. In fact, it will most likely be technical debt confusing users and developers alike.

So to reframe the above question, would the refund reduction cause you to change the way you write contracts, *even if* the advantage will only last for 1.5-3 years?

cc: @AndreCronjeTech @bantg @samczsun @_prestwich @nicksdjohnson @wolflo0 @PhABCD @NoahZinsmeister