When such hard fork is announced, it is likely that the hoarding of the state will begin (get it while it is cheap!). Blocks will probably fill up with the state expanding transactions, and the gas prices will shoot up again. This situation might persist until the hard fork. And then, when the high costs are introduced, those who hoarded the space, will need to return their “investment” and will try to form what I call a Dark Rent market . I have not figured out the mechanism, but I think it is technically possible. The difference between this and the State Rent that is being proposed so far, is that the beneficiaries of the Dark rent are the hoarders, and the beneficiaries of the “Light” Rent are all ETH holders collectively (because rent gets burnt).
It’s worth noting that there is a “keyhole solution” to this. For each storage key, store whether or not it has already been accessed after the fork. If the old new-storage-slot cost is STORAGE_SLOT_OLD and the new cost is STORAGE_SLOT_NEW (eg. 20000 and 60000), then if a storage slot is modified that has not yet been accessed after the fork, charge an additional STORAGE_SLOT_NEW - STORAGE_SLOT_OLD gas.
The flags also have a secondary function, which is that they can be used to calculate over time the number of nonempty storage slots in each contract, which is needed to properly charge rent to contracts if that ends up being implemented later.
Alternatively, if we decide that we have access to a “tell me how many storage slots this contract has now” method (this could be done safely for large contracts by storing values in the client’s database that start at zero or whatever the storage slot count is at fast-sync time, then updating them as blocks are processed), then we don’t need per-slot accounting; we can just store a variable “number of storage slots not updated”, and charge an additional STORAGE_SLOT_NEW - STORAGE_SLOT_OLD per write until this “debt” is paid off.
Thank you, this is a valuable insight! It looks like a good solution to hoarding and dark rent.
I think it might also reorder some of the things in the State Rent proposal to introduce accurate accounts of contract storage BEFORE introducing the rent on contracts.
I have a couple of concerns regarding increasing SSTORE cost to curb the increasing state size.
We will be required to increase block gas limit by the same factor so that any legacy contract is not rendered useless. If SSTORE cost goes from 20k to 60k, block gas limit will have to be increased from 8m to about 24m.
Assuming we increase the block gas limit, it raises a couple of concerns:
This might not solve the problem at all because people will still be able to store same amount of data per block. Yeah gas cost will be higher but gas price might drop due to large block size resulting in similar actual cost. Even if the cost of transaction goes up by 3x, will it matter? Were there significantly less transactions when eth price was going up, making transactions more expensive?
Uncle rates are down, network propagation is fast and we can increase the gas limit by a bit but can the network support a drastic increase of 3x?
Ps. I am in favour of renting over sstore cost increase. We need a solution for the rapidly increasing state size.
Thank you for the comments! I think what we might be doing is to increase the cost of SSTORE, CREATE, etc (anything that expands the state) times 3, while leaving the cost of most other opcodes the same, and recommending the raise in block size limit (if the uncle rate drops sufficiently over the next few weeks). Note that the same effect could have been achieved by just reducing the gas cost of all operations except the state expanding ones times 3, but it is not possible because some costs are already small number indivisible by 3 - so we would lose pricing precision.
Although this path would not lead to shrinking of the state, it will effective make non-expansive uses of Ethereum potentially cheaper. It is sort of removing the dependency of one improvement (faster block propagation) onto another (state rent), which currently looks like a more sensible roadmap to me.
We are not thinking to abandon State Rent research and implementation, but thinking about making it less of a bottleneck for the growth of Ethereum adoption.
This makes prefect sense. Thank you for clearing things up. I was under the impression that increasing sstore cost was being proposed as an alternative to rent for decreasing state size. Happy to learn that it’s not.
Well, I portrayed it in this post as an alternative, but then realised (after Vitalik’s and your responses) that it could be part of the plan!
EDIT: On the second thought, though, it might be that making expansive operations more expensive, but still pricing them in Gas, and giving that gas to miners to be recycled, potentially opens up another vulnerability - miners might start offering special state expansion services, because for them the expansion might actually be free. Also, the time non-uniformity of gas price is likely to be abused even more. I think it might be prudent to only do the cost increase after something like this: Fee market change for ETH 1.0 chain · Issue #1559 · ethereum/EIPs · GitHub. And, of course, any increase needs to get burnt (later on, it might get added to rentalnce instead). What do you think, @vbuterin ?
IMHO introducing rent for the main net is a totally wrong thing to do - it will kill what people love Ethereum for which is simplicity.
The problem which needs to be solved is how to pay people so they can run ethereum nodes not on crappy PCs but on powerful computer clusters. If you figure out how to pay each honest node $10000 a month, all storage and compute problems will go away. Storage is incredibly cheap and compute is incredibly cheap.
ETH can not grow if the direction is to force dapps to use less storage. What needs to be figured out, how to make more storage avalable to dapps.