State Rent proposal update and Dark Rent markets

[jpitts]

@AlexeyAkhunov

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.

@gcolvin

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?

@AlexeyAkhunov

To keep sync time reasonable for the new nodes joining the network.

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.