Increase price of SSTORE from zero to non-zero to 40k gas
EIP-5022 proposes increasing the gas cost of the SSTORE opcode from 20,000 to 40,000 when the original slot is zero and the resultant slot is non-zero. The motivation behind this proposal is to address the issue of state growth, which is one of the main reasons for not increasing the gas limit. Currently, the cost of creating new storage slots has not increased, which means that all users of other opcodes are subsidizing the creation of state. By increasing the price of state growth, developers will be incentivized to reuse storage instead. The proposal also suggests that increasing the gas refund from setting non-zero to zero requires further discussion. While solutions like state rent or state expiry have been researched, they will not be ready in the short to medium term, so it is desirable to patch pricing for the short term. The specific amount of 40,000 gas was chosen because the current pricing was based on a naive approach of benchmarking opcodes on a laptop, and did not consider the long-term problem of having the same price for a resource that costs more over time. The proposal acknowledges that this change will severely impact the gas cost of many applications, but argues that the network should not subsidize state growth at the expense of more expensive regular transactions. The proposal includes a new gas schedule that applies for blocks where block.number >= FORK_BLOCK, and notes that contracts that depend on hardcoded gas costs will break if they create state.
Video
Original
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
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all