First of all, let me summarise what happened in the State Rent working group since first revision of the state rent proposal was published.
- After considering Vitalik’s post on the common classes of contracts, it is very likely that Linear Cross-Contract Storage (LCCS) will be removed from the next revision, in favour of contractions based on CREATE2. An example of such construction for ERC20 tokens can be found here: https://github.com/ledgerwatch/eth_state/tree/master/erc20
- ERC20 tokens have been identified as an important class of contracts, and now this has been quantified. Contracts that have ERC20 interface occupy around 53% of all contract storage. Their balances (how much each holder owns) occupy around third of all contract storage
- Following the research of ERC20, the next most important (by footprint in the state) class of contracts will be identified and researched (so far the hunch is that is could either either on-chain order books or non-fungible token contracts). Solutions similar to ERC20 contract above will need to be researched.
- It has been observed, that because evicted contracts would be recoverable, no eviction notification might be needed (it is present in the first revision of the proposal). For example, if an ERC20 token holder contract gets evicted, the token contract should not reduce the
totalSupply, because the evicted holder can be reinstated, so technically, the tokens still exist.
- Observation mentioned in the previous item weakens the case for the Eviction Priority Queue, described in the Step 2 of the first revision of the proposal. It is likely that the Eviction Priority Queue will be removed from the next revision, and eviction will instead happen when an account is “touched”. The regular updates to the rent balance will still only happen when an account is modified.
- Adrian S. from PegaSys team is helping by creating Proof Of Concept implementation based on Pantheon.
- First interesting observation made during the Proof Of Concept implementation, is that some kind of grace period is required to maintain a better user experience. Meaning that when you create a contract without an “endowment”, it should not get evicted at the same block. Current idea is to redirect part of the cost of contract or account creation (and potentially part of SSTORE charge) into the account’s rent balance.
- Interesting consequence and complication of the point above is that because rent is charged in wei, but account creation and SSTORE is charged in gas, there might be conversation back from gas into wei. Also, if something gets created with a higher gas price, it will have a longer grace period.
Now, to the Dark Rent markets!
There were some counter-proposals to rent based on raising the cost of SSTORE a lot, so that it curbs further growth of the state. Some variants include putting up a deposit during any allocation in the state, which gets returned when the allocated space is reclaimed. That could also be viewed as an increased capital cost of allocation.
My argument, that I would like to share and discuss is this. Let’s say we drastically increase the cost of allocation, and this change in cost only applies to the allocations happening AFTER the hard fork (where the change is introduced). 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).