Why does this give miners more power than they already have more than anyone else? If there is a reward, anyone can claim it, miners will just have a frontrunning advantage. We can even measure the reward in gas so that it doesn’t cause any inflation - miners would be able to collect more gas fees by participating, or non-miners would be able to get a discount on large transactions.
Well, this could be designed, though I wanted to avoid these front-running games at all. And it is not as trivial as it might seem. A new type of transaction needs to be created, because the actions it would perform have no associated opcodes to it, so it is intrinsic. To prevent DOSing, we need to make users pay for such transaction, and then fully refund that if the eviction is successful as well as create some reward out of thin air. I daresay it might introduce more complexity and non-determinism than what we would want to avoid with the priority queue. A proof of concept should uncover if the priority queue is really a challenge.
Thanks for this document; this is quite helpful for me as an application developer to see if my intended storage usage is within accepted norms and will be sustainable once rent is implemented.
To clarify, I assume “storage item” refers to 32-byte storage slots? How did you calculate the storage associated with a particular contract?
Yes, 1 storage item is 32-byte storage slot. I current use a very ad-hoc method which works on top of Turbo-Geth’s database, something like this: https://github.com/AlexeyAkhunov/go-ethereum/blob/00f5e6590b81c7a5b3142879b472c40df194eff6/cmd/state/state.go#L1059
Potentially, when this is more developed, and I managed to get someone to help me with this, it could be more exposed as an API or something.
Congrats @AlexeyAkhunov for your good work. Rent is an absolute necessity for the future of Ethereum.
I would personally focus only on Reactive maintenance for now as it is enought to have a solid proof of concept. Regarding Token dust griefing attack, I am not sure it is a huge problem to solve for two reasons:
-> issuer of an active token will be ready to pay for the storage as it is is own interest to have an active token
-> Any token holder with access to transfer function can increase storage rent but it means I will send some token out. It can be spam only if it is very very small amount. One way to reduce that the problem is to reduce the number of decimal of the token which seems healthy I think.
This thought, of course, crossed our minds too. What if there is no issuer, i.e. token is unmanned? Don’t want to have a system where each popular contract needs a wealthy donor. And don’t want to require that everything is a DAO.
I think what you describing is the “Alternative point of view” on the page 23 
I agree with you! We just need to go step by step
Well, the document I have attached has 6 steps
I want to understand the main position better in relation to contract storage:
- If currently existing contracts are NOT upgradeable, they will loose their storage and need to be redeployed (potentially at the same address). From this point on they can use either active or reactive maintenance approach.
- If currently existing contracts are upgradeable, they will be able to transition into maintenance without the extra step of redeployment.
In either case their code needs to change.
If so, here comes a proposal in relation with this statement:
If the notion of rent is introduced without a “safe place” to migrate to, the only recourse of current contracts would be to use reactive maintenance approach, in the form of stateless contracts, which might too big of a leap in terms of usability.
If contracts need be updated with new code, do they really need a “safe place”? They could be rewritten into state-minimized versions with slightly modified interfaces. Very simple steps could go a long way:
- increase storage op-code cost a lot.
- create op-code that manages account storage root directly at old sstore/sload price.
- provide a precompile that allows to cheaply verify patricia merkle proofs in solidity.
- extend the ERC20/721 interfaces with a param to pass proofs.
this would give you:
- reduced problem space to managing rent on account-level only.
- contracts are incentivized to be written so that they manage the storage root themselves with off-chain data.
- You have a fallback for all the lazy guys (old sstore/sload) that comes at cost.
- new market of trust-free data service providers that hook as proof-providers into web3.js.
Unfortunately, the way I see it, most contracts will need to be re-written, re-deployed, and re-filled with data. To me it is the choice - either contracts need to be changed, or platform has to die.
In my opinion, asking them to just keep data off-chain and use Merkle proofs is not going to be very attractive. On pages 52-55 I tried to illustrate two main issues with that - contention of proofs and necessity for a sub-protocol for new users to be able to join.
Yes, this has been suggested a lot in response to apparent complexity of the proposal. I would say (and perhaps I will add it to the next version of the document) - when you increase cost of storage op-codes to compensate for storing data forever, you would probably make it too expensive for anyone to use. This is because there will be no middle ground, which is keeping data for some period of time. Everyone will either have to have no data stored, or data stored forever. I did not do numbers on these, but it seems very inflexible to me.
1 Like
should have read the whole thing 
thx
@AlexeyAkhunov indeed amazing doc. thx for the writeup.
Agree, and yet there should be a choice/market if you want. Currently a state-minimized contract is more expensive to reading or writing storage directly, which gives the chain a monopoly on storage.
Whatever the new design for rent is, other approaches should be able to compete.
An ever increasing price schedule for the cost of the sload/sstore opcodes would discourage use or gastoken, while leaving time to migrate contracts.
I have the same intuition: if in question - try to remove rather than add. Also if contracts need to change in 1.x, why not prepare them to move to 2.0 already.
Precisely. The new design has to exist though, for it to compete
GasToken is not the major contributor to the state growth. Major contributor is the collective growth of many token contracts. Also, as State rent becomes likely, the use of GasToken will diminish, out of expectation that hoarded storage will need to be maintained or disappear.
Because the whole premise of Eth1.x is that Eth 2.0 might be too far in the future and too uncertain, and ecosystem needs to live on
Would the overhead be too large if the SSTORE cost was dynamically calculated for each msg.sendertx.origin? Something like 
where 
is the the current SSTORE operation cost for a given EOA i and N is the number of storage slot currently used for EOA i.
The cost doesn’t need to be linear. It seems to me like this creates an incentive for users to “clean” their storage or they pay a premium for every new operation. With this simple scheme, users could, however, just always create new accounts to reset the counter. This could perhaps be mitigated if the first SSTORE is much more expensive and if we use a logarithmic curve instead of a linear one when calculating SSTORE_i.
The advantages of a scheme like this would be that the UX would be identical as it is now and I believe it would be backward compatible with currently existing contracts.
That seems risky. That would mean that once a contract becomes big enough it’s unusable. Also, it is circumventable by creating child contracts that store storage keys and calling them to read/write to storage.
Sorry, I should’ve specified tx_origin, not msg.sender (basically track the EOA that calls the SSTORE). Hence it’s independent of contract size, but tracks how much each user fills storage slots in the contracts they use. I don’t think this could be avoided by using child contracts or some proxy contracts.
It does become a bit weird when thinking of Meta-tx and relayers/operators, but that could be solved by having them find a L2 fee structure that makes sense to cover the costs.
I have some doubts in understanding the proposal completely.
Regarding Step-1, In case of eviction, will state data along with the account information of the contract will be deleted. If that is the case, then when reviving the contract, a Merkle proof of the account information should be provided. So we will know the nonce information during revival. So can you please help me understand what am I missing as a new replay protection mechanism was described ?
In an eviction transaction, SYSTEM account makes a call to the <writer> contract with the call data containing the address of the <owner> contract, with a stipend proportional to the size of evicted storage.
How is an eviction transaction triggered, if a contract is untouched for a long time as it was mentioned that calculation of dues happen only when account is modified by EVM ?
On Step-2, only non-contracts are evicted, and they don’t have meaningful state data, apart from balance (which would be 0 at the time of eviction), and nonce (which will be changed at the revival).
At Step 4, when contracts are getting evicted, the recovery scheme is provided.
It is triggered by priority queue, which is described on pages 31-38
Out of 47.64m accounts in total, 40.01m are Externally Owned (non-contracts)
Does this mean that Ethereum has 7.64 million contracts deployed?
It probably has a bit more right now