Abstract

Increase the price of the SSTORE opcode from 20_000 gas to 40_000 gas when the original slot is zero and the resultant slot is non-zero.

Motivation

The cost of creating a piece of new state increases as state is larger. However, the price for creating every new storage slot has not increased. All resources are merged into the same pricing mechanism. If the price for creating new storage slots is fixed, then it needs to be manually changed.

One of the main reasons for not increasing gas limit is the increase of state. In that regard, because the cost of creating storage is higher than its price, all the users of all the other opcodes are subsidizing the creation of state. If state creation was more precisely priced, raising gas limit would be more feasible, and would benefit the users.

Rationale

Why not also raise the cost of non-zero to non-zero?

Rewriting storage does not affect state growth, which is the main issue this EIP is addressing. Rewriting storage may also be underpriced. Increasing the price of state growth will, at least, incentivize developers to reuse storage instead.

Why not also increase the gas refund from setting non-zero to zero?

More discussion is needed on this.

Why not a better state solution?

Whereas solutions like state rent, or state expiry have been researched for a long time, they will not be ready on the short to medium term. So, it is desirable to patch pricing for the short term. Opcode repricing has been done before, so it should not impose a large development time investment for clients.

Why was that specific amount chosen?

The current pricing was made off a naive approach of benchmarking opcodes in a laptop. Not only it did not consider the long term problem of having the same price for a resource that costs more over time, the benchmark itself was wrong. This price is closer to what the naive original benchmark should have been. It could go higher, but that may be too disruptive.

Is this too distruptive?

This change will severely impact the gas cost of many applications. The network does not have to subsidize state growth at the expense of more expensive regular transactions, so even if it is too disruptive, it will increase the health of the network.

Specification

Constant	Value
FORK_BLOCK	TBD
NEW_STORAGE_PRICE	40_000

For blocks where block.number >= FORK_BLOCK, a new gas schedule applies. Make SSTORE_SET_GAS, the price when a slot is set from zero to non-zero, equal NEW_STORAGE_PRICE. All other costs remain the same.

Backwards compatibility

Contracts that depend on hardcoded gas costs will break if they create state.

It is a gas schedule change, so transactions from an epoch before FORK_BLOCK should be treated with previous gas costs.

Implementation

https://github.com/ethereum/go-ethereum/pull/24725

Security considerations

TODO