EIP Proposal: Increase cost of SSTORE from 20k to X when creating new storage

(please change tags if they are improper)
I’m making a draft for a EIP to raise the cost of creating new storage.
I’ve been told EIPs require to be highly technical, but I don’t have that technical knowledge. I also want to have a discussion on if this is feasible or desirable. I will be pasting the unfinished .md I wrote.
Originally, the proposal had NEW_STORAGE_PRICE = 30_000, but I want to see if someone more knowledgeable proposes a different amount. Why not 40_000 instead, what would the consequences be?
It’s implied in the EIP, but the cost of modifying existing storage remains the same.

Abstract

Increase the cost of the SSTORE opcode from 20_000 gas to NEW_STORAGE_PRICE 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 as state became larger.
All resources are merged into the same pricing mechanism. As the price for creating new storage slots is fixed, it has to be changed manually to reflect costs more accurately.

Until a solution to state growth like state expiry is built, a way to slow down the creation of new storage slots will buy additional time.

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 creating state was more precisely priced, raising gas limit would be more feasible, and would benefit the users.

Specification

Constant Value
FORK_BLOCK TBD
NEW_STORAGE_PRICE TBD

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

Rationale

Unsure of what this means, TODO.

Backwards Compatibility

Some contracts that depend on hardcoded gas costs may have to be redeployed.

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

Implementation

TODO

Security Considerations

Less state growth may encourage miners to increase gas limit per block. This could lead to a return to previous level of state growth, and some new problems such as increased latency, increase in uncle blocks.

Copyright

Copyright and related rights waived via CC0.

1 Like

Could you please provide an analysis and measurement that supports the following statement from the EIP?

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.

I would also understand better what exactly this means

The cost of creating a piece of new state increases as state is larger.

Are you referring to disk space or space in memory while processing? If it’s the former then I guess one should also increase pricing of tx payload as that also gets stored?