Yes, I meant PAYRENT. In the case of a EOA creating a contract*, the constructor/initcode would try to execute PAYRENT. If it failed – e.g due to no value having been provided in the call, there would be no deployment.
*nitpick: not by sending to address zero, which would just burn the money; but by sending without a recipient
I don’t see how SLOAD creates dark rent.
The numbers I wondered about on AllCoreDevs remain critical to whether the blockchain can survive. We know that the blockchain is currently growing about twice as fast as storage is getting cheaper. Assuming this continues, how much income do we need–from rent, store and load fees–to make up the difference?
The idea of rent (at least in my understanding) is not to provide income, but to restrict state growth. The limitation of growth becomes tied to the supply of ETH. As the state size approaches the desired maximum, the rent starts climbing sharply, pushing out more and more stuff out of the state. It would be very difficult to resist this process for a long time, because, since rent ETH gets burnt (removed from the supply), and therefore make resistance to rent more and more expensive. We are not targeting any specific income, but rather a certain state size.
EDIT: In other words, current proposal for State Rent, does not require figuring out how expensive the state access should be. It will adaptively become more expensive, as we approach the bounds
And could not the same idea be applied to storing and loading?
@AlexeyAkhunov
The idea of rent (at least in my understanding) is not to provide income, but to restrict state growth… We are not targeting any specific income, but rather a certain state size.
Other than the desire to fit current RAM and SSD sizes, why limit state size?
Or (I’ve lost track) is evicted state available for seamless resurrection, so that it amounts to hierarchical storage?
EDIT: inserted another answer here
Adaptive pricing of storing and loading? Interesting, let me think about that
To keep sync time reasonable for the new nodes joining the network.
Seemless resurrection is only possible if we keep a “hash stump” in the place of evicted contracts. In some ways, yes, it is hierarchical storage.
Scheme based on “hash stump” is obviously prone to some a form of abuse - create lots of contract and leave their hashes in the state.
Therefore, from my point view (and this is Step 6 in the proposal), we might also need true eviction, which does not leave any stumps. To brings such contracts back, one would either need proofs of exclusion (pointers in the proposal), or graveyard tree, which is equivalent to moving the contract into the stateless realm.
This is a key area of discussion I think.
Are there any estimates about how much expansion of network use would create the scenario of reaching maximum state size / escalating rent?
If it does not allow a great amount of additional use, the goals of improving mainnet scalability will again be in contention with state size. Instead of targeting a maximum, is there a way to find a more reasonable economic equilibrium between storage needs and user needs?
State rent climbing sharply, or even the expectation that a limit could be reached, may cause problems for the dapp ecosystem and users who depend on the network daily.
As @cdetrio described in the half-baked 1.x roadmap:
The plan for 1.x encompasses three primary goals:
(1) mainnet scalability boost by increasing the tx/s throughput, achieved with client optimizations that will enable raising the block gas limit substantially;
(2) ensure that operating a full node will be sustainable by reducing and capping the disk space requirements with “storage rent”;
(3) improved developer experience with VM upgrades including EVM 1.5 and Ewasm.
No. And the reason is that Ethereum is not simply a monetary protocol. A lot of network uses (like transferring Ether or token to the existing accounts/holders), does not change the state size, and therefore, does not escalate the rent. Only expansive uses will cause the escalation. But there is a whole spectrum of possible uses from non-expansive to very expansive. And even more so, the prevalent uses do and will keep changing. How they have been changing so far needs to be researched and illustrated.
Not necessarily. As I pointed out above, only expansive uses will be in contention with the state size. Also, the old unused state will be removed quicker the higher is the rent. Theoretically, the system is self-healing. And, we cannot cater for all user needs, because some of these needs require too much altruism from the maintainers of the network. One example of such a “need” is profiting from non-uniform gas prices (e.g. Gas Token). Other examples are spam-voting, or year-long ICOs.
Some contract developers make incorrect design choices, because the rent-free model encourages it. Examples - massive DEX contracts, using contract storage to record all trades and withdrawals that ever happened, in the ACTIVE state, MiniMe tokens, storing the entire history of token holding, in the ACTIVE state. Users will need to change their “needs”, I am afraid. They will need to optimise, because we are already optimising quite a lot.
See my comment above. We (and I) are doing a lot of work currently to assess the impact of the State rent on the ecosystem, but it is unreasonable to expect that protocol developers will come along and save Ethereum, without dapp ecosystem needing to change their ways. It is everybody’s problem.
A lot of this is being driven by our state growing faster than storage is getting cheaper. But is not the case for most anything else. If we do settle down to a rate that is less that the cost rate these problems become much easier to deal with.
Thank you for clarifying @AlexeyAkhunov.
If I am interpreting this correctly in a very broad sense: the introduction of costs will alter the way dapps make use of the network, while culling older state. It is not so much that there is a limit driven by sync times and node operator costs to worry about, but that this limit is avoided as the introduction of costs incentivizes changes in contract design and usage behavior.
What concerns me is not that the network participants have to pay a cost, but that the new capacity to operate dapps created by 1.x will again get used up. Your pointing to “only expansive uses” as leading to this condition is reassuring!
Do you think that finding the right pricing of rent to maintain parity with the technical capacity to sync will be challenging?
Cost-based incentives targeting dapp developers (and by extension their users) is not the only lever available; node operators are available to do work.
Is it worth exploring a possible market mechanism between node operators and contract maintainers? @tjayrush and the Data Ring have discussed node operator incentives before.
Or is it expected that an appropriate pricing scheme can be estimated / adjusted by the larger 1.x team.
And yes, absolutely, each of us has to do the difficult work and make sacrifices in order to “save Ethereum”! Well, more like save it from being a shared smart phone from the late 1990s 
Yes, I think it will be. But I also think that we do not have to get it right from the first attempt. Firstly, the actual rent pricing is not introduced until Step 5 in the proposal (or Step 4 in the next revision). Secondly, it will be easy enough to tweak for pricing formulae once other mechanisms are in place. I am pretty sure we will not get it right on the first attempt, and we will have to observe how the first formulae behaves, and see where its defects are. And then we will do a hard-fork to correct it. That hard fork would be easy to prepare.
Not at the moment. We do not have node operators modelled in any way in the protocol, like for example, miners (via Coinbase field in the blocks), or ETH holders (by their accounts and ether supply). One of my ideas is to launch a Plasma-like network for accounting between the node operators (not necessarily in Ether, but in some other token, and perhaps even allowing negative balances, so that new node operators do not need to have those tokens to start with). If we figure out how to distinguish a genuine accounting network like that from fake ones, we can use it to drive the pricing mechanism. But I do not know how to do that at the moment.
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:
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.