Title: Ethereum_State_rent_for_Eth_1_x_pre_EIP_document
Category: Working_Groups

Author: AlexeyAkhunov
Date: 2018-11-26T08:30:58.920Z

Here is the document about state rent: https://github.com/ledgerwatch/eth_state/blob/master/State_rent.pdf
Because I wrote most of it, it most probably reflects lots of my opinions, but I tried to incorporate alternative points of view to the extent it would still make description tractable.

Author: Cygnusfear
Date: 2018-11-26T13:41:20.022Z

Thank you for these slides. An idea that comes to mind reading this and https://ethresear.ch/t/ethereum-2-0-data-model-actors-and-assets/4117 is the following:
Account/wallet contracts implement a permissioned storage interface standard (using a sort of ACL).
Instead of ledger-within-ledger token contracts, the user of the wallet grants the token contract permission to write to the user’s own storage. Token balances, NFTs etc are now stored on the user’s account, thus the users are charged rent for their own assets. To decrease rent fees users can remove unwanted assets.
This could be a solution to the dust griefing attack mentioned in the slides.
Users can ‘deny’ tokens from storing data in their contract, reducing the viability of spam tokens. Airdrops can still be performed using a withdraw() scheme.
Token contracts will pay significantly less storage rent. Users are incentivised to pay their ‘account cost’ and be custodians of their own data usage.
(I’m uncertain if I’m reformulating the Step 3 - Linear cross-contract storage here, so please let me know if I whooshed there)

Author: AlexeyAkhunov
Date: 2018-11-26T14:00:37.632Z

Cygnusfear:

(I’m uncertain if I’m reformulating the Step 3 - Linear cross-contract storage here, so please let me know if I whooshed there)


Yes, what you are describing is in sprit the linear cross-contract storage from Step 3

Author: boris
Date: 2018-11-26T14:32:57.682Z

Useful thread from Vlad:


twitter.com



Vlad Zamfir (@VladZamfir) on X
@VladZamfir

I know blockchain rent doesn't have a great user experience, but we need to (eventually) bound the size of the EVM state trie or the system will 🔥

Author: hershy
Date: 2018-11-26T18:27:27.233Z

Thank you @AlexeyAkhunov . I appreciate that you had some concerns around the blowback that certain teams high up on the ‘Contracts by Storage’ list will/may receive from folks acting in bad faith. And I appreciate those concerns comes from a good and empathetic place. However, this research is excellent and concisely presented and should not have to accomodate the actions of a 'lowest common denominator.

Author: AlexeyAkhunov
Date: 2018-11-26T20:52:13.402Z

hershy:

I appreciate that you had some concerns around the blowback that certain teams high up on the ‘Contracts by Storage’ list will/may receive from folks acting in bad faith


Thank you for the kind words, and I think now that my concerns might be unfounded

Author: cheeselord1
Date: 2018-11-27T01:01:13.219Z

This is really great! I’m wondering if we can split up the rent problem for contracts into two groups:


How can we get active contracts that are using lots of storage to pay a rent that more accurately represents the cost of storing that data permanently on-chain over a period of time. As you pointed out, for many contracts (Token contracts) this suffers from the free rider problem. I think the Actor/Asset model (or Linear cross-contract storage as you call it) could be an interesting solution here.


How can we clear the state of abandoned contracts that are not being used anymore?  As calling SELFDESTRUCT is not free, most people don’t clear their old contracts when abandoning them (I am guilty of this too).  For this case, maybe we can store an expiration_time for each contract and refresh it to now+12 months on every call to that contract.  Though there may be some types of contracts that are still in-use but called very infrequently (libraries, multi-sig wallets)


#1 would offload a lot of state from large, central contracts to the actual users of the contract where rent could be applied more fairly.  And #2 would help purge any state remaining on the contract itself once abandoned

Author: AlexeyAkhunov
Date: 2018-11-27T08:02:52.525Z

cheeselord1:

How can we clear the state of abandoned contracts that are not being used anymore?


I did not include this into the deck, but as it stands at the moment, abandoned contracts (those not used for the last 12 months) represent only 6% of the state. That is why measures specifically designed to go after them were not in the proposal. And they are also quite easy to neutralise if someone wishes to.

Author: Cygnusfear
Date: 2018-11-27T13:28:29.593Z

Hey Alexey, I would like to second the sentiment shared by @hershy and I’m very happy to be able to ask stupid questions here as well 
Currently I understand that once a contract is evicted, it’s cross-contract storage is cleared, including the storage (on the owner’s side) that holds for example the tokens of a user. How does this influence actual ownership of assets, something that is specifically the goal of the NFT community and one of the promises of ‘gaming on Ethereum’ (once the servers go down, you still own the assets).
From a user perspective, I’m probably not aware this contract has run out of rent; my point of discovering this is when I’ve lost my assets. Additionally the community would have to rework current token standards to have actual ownership of items.
The rent model is a very elegant solution (not a UX nightmare at all); having an ‘open account’ means you pay a small fee for keeping the account open. If you store your own data, then you can do your own ‘cost’ housekeeping. The above scenario where you can lose your data is scary for a user with regards to ownership. Could you elaborate on why it is necessary to clear the user’s storage to help me understand the reasoning here?

Author: AlexeyAkhunov
Date: 2018-11-27T14:07:36.130Z

Cygnusfear:

Currently I understand that once a contract is evicted, it’s cross-contract storage is cleared, including the storage (on the owner’s side) that holds for example the tokens of a user


No, when contract is evicted, only the storage it owns gets evicted, but not the storage it writes. That means, if an NFT contract suddenly goes away, users will be able to bring it back using resurrection, and all their assets will be intact, as long as they keep paying for them. And, if NFT contract is very lean and popular, it might be able to effectively immortalise itself (because it will accumulate huge rent balance) by using call-fee (page 48).



 Cygnusfear:

Could you elaborate on why it is necessary to clear the user’s storage to help me understand the reasoning here?


Data owners should not be allowed to modify storage written by other contracts. But they should be able to withdraw that write permission, to stop paying for the store. For example, if you sold your tokens, you do not want to pay for number “0” kept in your storage

Author: Cygnusfear
Date: 2018-11-27T14:44:06.100Z

Thanks for clearing this up for me. It makes complete sense that you shouldn’t be able to write to the storage other contracts have grown, but should be capable of cleaning it. I was mistakenly assuming it would wipe all storage written to by the <writer> when reading the eviction slide (including the user’s). Very grateful for the help.
Probably the last stupid question   : It seems this is not very far removed from the actor/asset model if there is a ‘safe’ way to move that storage to another address? And if an asset could be isolated, as currently there would be an issue with the storage being a blob. As a hack for this, I can deploy a contract that won’t pay for its rent but writes to a user’s storage (so the storage is isolated) after deployment? Would an xmove and partitioned storage make this actor/asset model possible?
(I like the idea of not needing the original contract for moving my assets, doing an exchange. I don’t need to pay any extra fees to resurrect the inevitable transfer function that is built into every contract. I’m having a hunch that the above isn’t as obvious as it seems and isolating the data storage per asset encapsulates a lot more than that. And this doesn’t work for fungible tokens.)

Author: AlexeyAkhunov
Date: 2018-11-27T14:55:59.503Z

Cygnusfear:

It seems this is not very far removed from the actor/asset model if there is a ‘safe’ way to move that storage to another address?


I am afraid I did not study actor/asset model. Will look into it shortly.



 Cygnusfear:

As a hack for this, I can deploy a contract that won’t pay for its rent but writes to a user’s storage (so the storage is isolated) after deployment? Would an  xmove  and partitioned storage make this actor/asset model possible?


I don’t quite understand, sorry  Under this proposal, in the end, everything which is deployed, will pay rent, otherwise it will create abuse of primitives.



 Cygnusfear:

I like the idea of not needing the original contract for moving my assets, doing an exchange


It might get quite complicated if you want to start delegating writing rights to other contracts. We are trying to propose something that will be able to curb state growth, but that won’t destroy the ecosystem. Other extensions are possible, but only if they can be added without increasing complexity.

Author: Cygnusfear
Date: 2018-11-27T15:31:46.445Z

AlexeyAkhunov:

I don’t quite understand, sorry  Under this proposal, in the end, everything which is deployed, will pay rent, otherwise it will create abuse of primitives.


Sorry, that was a hamfisted way of explaining what I intended to . I’m intrigued by the fact that the rent proposal almost makes it possible for contracts/users (actors) to move/transfer/own their assets (items in storage) without any further interaction with the creating contract. This would allow ‘assets’ to be treated as first class-citizens similarly to a users’ ether balance.
However, I’m admittedly not very proficient in the base layer/evm/assembly level. As I understand it, this comes with a lot of increase in complexity. Moving around storage/memory is more complicated than I make it out to be in the above example.
The described proposal in your state rent document is very elegant without doing so and I really appreciate your patience in answering these questions and helping me understand these things a bit more.

Author: AlexeyAkhunov
Date: 2018-11-27T15:49:27.895Z

Cygnusfear:

The described proposal in your state rent document is very elegant without doing so and I really appreciate your patience in answering these questions and helping me understand these things a bit more. 


Thank you very much

Author: fubuloubu
Date: 2018-11-27T16:08:49.451Z

One other random thought: how we actually pay the rent (specifically using the actor/asset model)
The naive way would be to have whatever ether balance an address has be the rent payment. This makes it easier to collect rent for “large, central contracts” – just send ether to that address and it gets deducted at a rate of storage costs. If it runs out, the storage gets archived, then removed after some period (only the root remains).
However, let’s say you want to hibernate your holdings (meaning you will accept the burden of storing the state tree entry matching the root that remains). Your holdings include some significant amount of ether that you don’t want drained as you go into hibernation. A way to do that in my mind might be to make use of “semi-fungible tokens” (related to ERC 1410) where Ether holdings can be split into 2 holding groups: rent payment balance and free (non-rent) holdings. This would help contracts who are programmed to deal with escrow of Ether not to get their balances mixed with the rent payment balance.

Author: cheeselord1
Date: 2018-11-27T17:27:17.910Z

I’ve noticed some focus on “mitigating GasToken” on other forums like ethresear.ch. Why is that? The point of GasToken is to save state and later clear it to get refunds when gas prices are high, so it’s unlikely to continue growing unbounded compared to other contract types.

I did not include this into the deck, but as it stands at the moment, abandoned contracts (those not used for the last 12 months) represent only 6% of the state.

Super interesting!  From just eyeballing charts 1 and 2, it looks like total state was ~30% of current size 12 months ago.  Is this right?  So if 6% of current state is abandoned, that means 20% of the total state as of 12 months ago is now abandoned?  That may suggest the 6% number will start growing dramatically in the coming months

Data owners should not be allowed to modify storage written by other contracts. But they should be able to withdraw that write permission, to stop paying for the store.

I’m guessing we would make a contract’s write permission all-or-nothing? E.g. assume a contract stores user balances and debts. If the user could withdraw permission for the debt-storage field, that would enable them to drain the contract.
But then is there also a token-dusting attack vector if a contract’s write permission is all-or-nothing?  E.g. someone can send me dust from millions of tokens on EtherDelta which would make the rent prohibitively high. Unless we require authorization for each storage field used which seems like really complicated UX

Author: AlexeyAkhunov
Date: 2018-11-27T18:40:10.647Z

Adding another response here



 cheeselord1:

That may suggest the 6% number will start growing dramatically in the coming months


Main reason not to go specifically after abandoned contract is the fact that a spiteful adversary can easily neutralise such measures, and it will wasted work.



 cheeselord1:

debt-storage field


Debt is not an assert of the debtor, but of the creditor. The creditor is the one who should keep it and pay for it. That way, debtor cannot clear away the debt.



 cheeselord1:

But then is there also a token-dusting attack vector if a contract’s write permission is all-or-nothing?


It is not all-or-nothing. On the page 40, there is opcode XGROW, which owner can use to expand the cell writeable by a particular writer. Owner cannot shrink the cell though, only complete remove it

Author: AlexeyAkhunov
Date: 2018-11-27T18:42:21.740Z

fubuloubu:

deal with escrow of Ether not to get their balances mixed with the rent payment balance


Interesting line of thought. It might be possible to quite easily achieve that with a wrapped ETH token contract, which under the new model will have a constance storage size and can easily sustain itself by eating into the wrapped ETH it contains, or utilising callfee (page 48).

Author: fubuloubu
Date: 2018-11-27T20:01:15.857Z

AlexeyAkhunov:

wrapped ETH token contract


In other words, “RentToken” lol

Author: jvluso
Date: 2018-11-27T20:50:40.712Z

CallFee and Linear cross-contract storage both seem like powerful abstractions. Are these things that you want to add to the base layer or do you think they can be implemented in the scripting language?

Author: AlexeyAkhunov
Date: 2018-11-27T21:51:02.238Z

jvluso:

CallFee and Linear cross-contract storage both seem like powerful abstractions. Are these things that you want to add to the base layer or do you think they can be implemented in the scripting language?


To the base layer, as they require new opcodes and new consensus structures

Author: hershy
Date: 2018-11-27T23:52:50.160Z

The issue with this is that you would have to know ahead of time how long you want to (to borrow your term) ‘hibernate’ said holdings, in order to ensure you purchase enough of the NFT’s to cover rent.
The obvious answer to this is to say that if the balance of the Rent NFT dwindles to zero, then there is a default to rent begining draw off the primary holdings. However, if this is, ultimately, where we default to, it may as well be where we start from as well.

Author: AlexeyAkhunov
Date: 2018-11-28T14:11:23.490Z

Comment from Reddit and my replies


Yes we need rent for sure! But: “Owners consent to be given tokens by executing XGROW […]”.
So users need to do something to  receive  tokens? That doesn’t sound like a good solution at all. You shouldn’t have to be online/execute some function to receive a token!


Yes, users will need to do something to receive tokens. Because at the end of the day, they will pay maintenance for the space these tokens take. It would be wrong to allow anyone to burden you with such maintenance without your consent. On the other hand, it makes the fat finger problem less likely. Useless airdrops will not be possible. Tokens organised in such way will have better legal standing (this is my speculation)
EDIT: on the legal standing - in real world, you normally have an option to refuse unwanted gifts. And sometimes, it protects you from liability


That’s where I disagree. I think the token contract creator should pay for maintaining all token balances of his contract… If it’s a valuable token people will come together and crowdfund the maintainance of the token contract. To prevent extreme splitting/dust attacks… well… give the token less decimals or just implement a min-value you have to send.
What I see in this document is a clear case of over-engeneering IMO. Keep it simple/clean.


Thanks for the comment! I shall explore this more in the next version of the document. It actually mentions what you are suggesting, on the page 23 under “alternative point of view”. Obviously, the greater is the min-value, the smaller is griefing factor. But the greater is the min-value, the smaller is number of owners who can potentially hold the token. Will try to put some numbers behind this - to make is more visible why I think it is a genuine problem and cannot be waived away by saying “less decimal points and min-value”.
Regarding the crowd-sourcing the rent, this is another unknown. As I described in the document, the problem here is free riding. The smaller holder won’t contribute, because they will hope that the larger holders would. And larger holders might find it expensive, unless they hold supermajority of tokens.
Non-Fungible tokens and similar assets also need special treatment - though they are taken care of in the document by the cross-contract storage. Therefore, I disagree about the over-engineering - it solves lots of problems with one new primitive. I would say - make it as simple as possible, but not simpler.
ADDING MORE FROM THE SAME THREAD


How about the following dynamic (all solvable on contract level [best practices will emerge]):
Token contracts can migrate to new contracts with more digits or smaller min values once they become popular and increase in value. More users & more value means more interest from more parties in keeping the token contract alive. So the contract can afford a higher rent. Before seeing their tokens value disappear a substancial amount of token whales will always either vote the min-values up or pay for the rent from their own money (better lose some than all). I think it’s ok for small holders to free-ride a bit here.
Also a best practice that could emerge is that using these tokens will force holders to pay a certain fee (either by inflation or a portion of their holdings “melts away”). This fee is used in an auction contract to buy ETH on the market which gets automatically sent to pay for the token contracts rent.
There are many scenarios possible… My argument would be that it should be handled on the contract/application level.


That is great! If someone is prepared to work this out - it would be great. At the moment my position is that these scenarios only work in limited circumstances, and the EVM architecture is lacking primitives to write efficient contract under the rent conditions. I alone cannot explore all the scenarios one can think of, so I invite other people to contribute by making alternative proposals.

Author: veox
Date: 2018-11-29T11:28:00.535Z

AlexeyAkhunov:

I tried to incorporate alternative points of view to the extent it would still make description tractable.


Discussion-derailing comment on slide 23:

Token dust griefing attack. Any token holder with access to transfer function can increase storage rent for the contract forever, paying only once for the attack.

This is an over-complication, as things stand.
I’ve described at etheresear.ch earlier this year (and demonstrated using graffiti.lll) how anyone with an ether balance can perform an “allowance griefing attack” to increase storage.
The solution to “allowance griefing” is simple, and is in fact a philosophical correction to ERC-20: namely, make allowances have a validity (time-out) period, with an overriding global period. (This not already being the case is an oversight of ERC-20 standard developers: who, in their right mind, would allow withdrawals forever?..) Outdated allowances become free-for-all gas tokens.


Tokens could require a signed ACK (consent for the receipt of tokens) from recipients.

Nit-picking about nomenclature: it makes sense to call this an ACK when assuming current prevalent use as spam air-drops. Considering that other regular use case, it’d probably be called a REQuest, or similar.
Anyway, this won’t work. The cause for this use of tokens in spam air-drops is marketing. Marketing departments will not cripple themselves into complicated opt-in schemes.
With the introduction of rent, it makes sense then for marketing departments to extend the above-described “time-out” scheme to balances also. An unREQuested, unACKnowledged spam air-drop transfer could be reclaimed by the sender…
I hope you see a pattern here. The proposed REQ/ACK scheme is a mirror image of the existing allowance-transferral scheme. There is no little sense to have both, - unless, as things stand now, one is displayed to the user in-wallet, and the other is not. (Replace “wallet” with “blockchain explorer” if needed, - for what is a wallet, if not a personalised explorer?..)
EDIT: Actually, there is sense to have both - see two comments deeper.
In other words: the underlying problem - that brought us where we are - is as much wallet software design as contract design.

Author: AlexeyAkhunov
Date: 2018-11-29T13:13:47.856Z

veox:

I hope you see a pattern here. The proposed REQ/ACK scheme is a mirror image of the existing allowance-transferral scheme. There is no sense to have both, - unless, as things stand now, one is displayed to the user in-wallet, and the other is not. (Replace “wallet” with “blockchain explorer” if needed, - for what is a wallet, if not a personalised explorer?..)


First of all, thanks for reading and commenting! And thank you for pointing out the allowance griefing attack.
Sorry, I did not understand, is this critique about “Alternative point view” (which suggests using signed ACKs for token transfers)? Or is this critique of cross-contract storage?
My main position is that token contracts will have change, and I do not agree with the “Alternative point of view” that one can fix things up on the application level. without changing the storage model. I have not yet explored whether ERC-20 would still be viable under the conditions of state rent.
Regarding the similarities between REQ/ACK and current allowance scheme in ERC-20, I need to think about it more.

Author: veox
Date: 2018-11-29T16:25:34.208Z

AlexeyAkhunov:

Sorry, I did not understand, is this critique about “Alternative point view” (which suggests using signed ACKs for token transfers)?


Not really; I’m highlighting that requiring signed ACKs for token transfers brings it very close to the existing allowance model.
A comparison (might work better in table format?..):

in your (proposed) REQ/ACK transfer scheme:

the sender needs to first obtain a REQ/ACK from the receiver, and then
perform the transfer themselves;
they can’t transfer more than their balance;
displaying balances is supported by wallet software;


in the (existing) allowance scheme:

the sender first sets an allowance, and then
waits for a receiver-initiated ACK;
can set allowances in excess of their balance, although no more than the balance can actually be claimed by the receivers;
displaying allowances - from self or to self - is not supported by any wallet software I know of.



There are subtle differences between the two, and I find both schemes useful.
If anything, so far, this is not (yet) a critique, but a note of agreement and support. 




 AlexeyAkhunov:

My main position is that token contracts will have change, and I do not agree with the “Alternative point of view” that one can fix things up on the application level.


Sorry if that’s the impression my reply gave.
My actual critique is that, as long as there are protocol- and contract-level features (such as allowances or rent) of which wallet-level software is unaware of (and leaves the user unaware of), we will remain in this ditch of trying to solve application-level (both wallet- and game-) problems with protocol-level tools only. Or on the application-level only.
Note that:

I’m not referring to the particular balance- or allowance-grieving attacks, which become such with the introduction of rent. Both of these

can be solved partially (on the contract-level) with the introduction of time-outs for transfers/allowances, as I’ve mentioned in previous reply; and
can probably be solved completely (on the protocol-level) by use of cross-contract storage, as you describe in the slides. (Although, must I say, the images there lack legends, so aren’t very approachable. I’ll go read the comments here and on Reddit before asking for clarifications.)


By “game-level problems”, I mean not zombie-cat-warrior toys, but application-level design choices that are mainly game-theoretic; the kind in the saying “if you don’t understand the game, then you’re it”.


My main critique is on the disconnect between actors at various levels in the ecosystem, not your slides. Which why I called my first comment “discussion-derailing”. 
[rant snipped as hindsight]
There are ways to mitigate state growth in the interim, while rent is being developed; but the mitigation would have to come from actors - wallet and game developers - that are indifferent, because they are not being penalised yet. “Oh well”.

Author: AlexeyAkhunov
Date: 2018-11-29T16:52:48.544Z

veox:

can probably be solved completely (on the protocol-level) by use of cross-contract storage, as you describe in the slides. (Although, must I say, the images there lack legends, so aren’t very approachable. I’ll go read the comments here and on Reddit before asking for clarifications.)


I don’t think anyone has discussed cross-contract storage specifically, there was mostly discussions about “why we should not do it this way”  or “why we should not do this at all” 
I am probably not very good with images, because I don’t understand what legends mean in this context 



 veox:

My main critique is on the disconnect between actors at various levels in the ecosystem


It was my feeling too. That is why we started this process not by writing EIPs and trying to see if they will get through, but with understanding who will be most affected by the changes on the timeline these changes are likely to be important (next few years, until Ethereum 2.0 or World War III, whichever comes first). And the design of cross-contract storage grew as a solution to grieving and free-riding problems, which I personally think is very hard (or impossible) to solve purely on the application level

Author: veox
Date: 2018-11-29T17:05:24.524Z

AlexeyAkhunov:

I am probably not very good with images, because I don’t understand what legends mean in this context


I wrote that part while looking at slide 39, before really understanding what slides 39–44 (“Step 3 - Linear cross-contract storage - opcodes”) are about. It does make sense after following the rest of the slides.

EDIT: FTR, I don’t claim to fully understand the cross-contract storage proposal (yet); but it does look good on the surface: it’s less different from the current mode of contracts’ operation than, say, stateless/witness-based. AFAIU, it doesn’t prevent the use of the latter by those who want to; and doesn’t force those who don’t.

Author: holiman
Date: 2018-11-30T08:52:29.247Z

Adding myself to the thread here.
I’m a sceptic of linear cross-contract storage (let’s call it LCCS ok?). Here is my main ‘beef’ with it:
The proposal ‘looks and feels’ like a proposal which shifts the problem of state data ownership
over to individual token owners. However, I think it still leaves the actual problem unsolved :


Problem: lots of data that the network has to take care of,


Implicit solution: delete data that nobody pays for


What the proposal does, is only shifting the ‘blame’ on the individual token owners. So after
we implement that, we can say ‘tokens lost? well, it’s your fault’ instead of saying ‘tokens lost? well, tragedy of the commons’.
And hence, I would much rather try to solve the problem root problem


Problem: lots of data that the network has to take care of,


Solution: Let the token-owner take care of the data.


And to reach that kind of solution, token contracts would need to be stateless, or at least not O(N) state, at best O(1) but realistically maybe O(log N) or O(sqrt N). So I believe that we should focus on what low-level functionality we can provide to contracts to make stateless-ness easier to implement.
So my ideal route forward would involve these steps


Temporal replay protection


Dust clearing


Tooling for stateless contracts


State rent (fjl’s gist)


Regardless if we use LCCS or not, as I see it, all existing tokens will need to be replaced. So if regular state rent is introduced, then

Replace token X with an implementation which has

Pays for it’s own rent by rewarding rentpayers with tokens
Has built-in dust-thresholds, and mechanisms to clean dust
Potentially has some form of statelessness



If lccs is implemented, then

Replace token X with an implementation which has

Storage on user’s accounts
Nothing. SFYL when tokens go missing



With the ‘old’ scheme, funds (tokens in cold wallets) will not disappear in a way that they cannot be resurrected. With LCCS, they will disappear forever.

Author: AlexeyAkhunov
Date: 2018-11-30T09:31:34.066Z

Thanks for comments!



 holiman:

What the proposal does, is only shifting the ‘blame’ on the individual token owners. So after
we implement that, we can say ‘tokens lost? well, it’s your fault’ instead of saying ‘tokens lost? well, tragedy of the commons’.


Yes, the introduction of rent itself shift the burden of state maintenance from the protocol to the contracts. And the presented proposal says: “It is not always fair”, so it ALLOWS to shift it further to the token holders, or whoever is beneficiary of that data being stored (if such beneficiary can be identified). It does not force contract developers to do that, but gives them an extra tool, because my belief is that a lot of them will need it



 holiman:

And to reach that kind of solution, token contracts would need to be stateless, or at least not O(N) state, at best O(1) but realistically maybe O(log N) or O(sqrt N). So I believe that we should focus on what low-level functionality we can provide to contracts to make stateless-ness easier to implement.


I started to explore stateless contracts on the pages 52-55, and so far identified that the main issues to solve would be “proof contention” (which could be made less bad, but not completely solved, by bucketing the state. complete solution would involve miners updating the proofs, which is a lot of changes in consensus), and a sub-protocol to deliver off-chain data for the new users.



 holiman:

If lccs is implemented, then

Nothing. SFYL when tokens go missing

With LCCS, they will disappear forever.


Sorry, it was the case in the earlier version of the proposal, where I forgot to mention that recovery mechanism on the Step 4 will also apply to the LCCS. Have not figured all the details yet, but started on the page 58

Author: Infernaltoast
Date: 2018-12-03T21:26:13.409Z

Hello, what if normal eth nodes were only required to store merkle root hashes and we outsourced storage to other archival nodes who were paid for the storage by those who wish to conduct transactions?  Like part of the TX fee or another tx fee.  Those who want to perform TX need to pay the archive nodes for the merkle proofs to submit their tx.
These ‘state provider nodes’ would be responsible for maintaining and storing the Ethereum storage data and would be compensated via micropayments whenever a TX is done.
This way, one tx gas fee is used to pay miners and another tx gas fee is used to pay the archival nodes who are helping the user to submit the Merkle Proofs to the mining nodes.  Obviously an eth user needs the merkle proof of, for example , their token balances in order to spend their tokens.
This would mean that the Ethereum state could scale infinitely and we could even separate the data into separate segments such as by perhaps 10,000 block Segments such that there would be multiple Storage Provider nodes for each Segment.  It’s easier to do this when we abstract the ‘job’ out to a different class of provider.
The way I imagine it is we have traditional light nodes which mine and hold just merkle roots and process new tx and are compensated, and then we also have these new archival nodes which hold the merkle proofs (all the chain data) for those roots and they are paid whenever someone needs their data.
I mostly suggest this because I think putting the burden on transaction fees is 1000% the way to go here.   Forcing smart contracts to pay is NOT right because smart contracts are not people!! Most are non-owned… Take SafeMath for example.  How can SafeMath pay it’s bills?    Or wEth.  Or thousands of other critical contracts who have no central entity to pay their bills!   I think we need to just add an additional Tax to transaction fees and make it go towards archival nodes basically.  And we do this by having the archival nodes sell the TX submitters the Merkle proofs!!! The data that they need to use to prove to the miners that their new tx is valid 
This would be like a second fee market. ‘Merkle Proofing fees.’

Author: AlexeyAkhunov
Date: 2018-12-03T22:40:38.269Z

Infernaltoast:

I mostly suggest this because I think putting the burden on transaction fees is 1000% the way to go here. Forcing smart contracts to pay is NOT right because smart contracts are not people!!


I think we need both on-chain storage (as stated on the page 21), which is limited, and off-chain storage, aka Stateless Contracts - I tried to explore them a bit on pages 52-55. What is not in the document, but will be in the next version - the full solution to the “proof contention” problem requires miners (or validators) to adjust the proofs, and this is perhaps what will start happening in Ethereum 2.0, or in Ethereum 1.0 with a large change to consensus also.
And if we do not introduce state rent, what will motivate people to switch to the outsourced storage? If there is no consequences for keeping data in the state, then people will keep doing until the platform stops working. It is similar to exploitation of biosphere by humankind - we all know we do it, but we don’t stop until everything dies.

Author: Infernaltoast
Date: 2018-12-03T22:49:21.234Z

Correct me if I’m wrong but in my proposal, essentially all contracts become stateless and the storage outsourced because normal Ethereum nodes would not need to store any state, just a little merkle tree like a light client.  We are probably talking about the same thing but with different wording/perspective.
Since every contract is stateless, to do a tx a user must provide a merkle proof (basically the definition of a stateless contract no? ) .
Then the archival/storage nodes could store different parts of the chain ( like shards) and could even be quizzed by the miners to make sure they are storing all the data and not just certain parts.   If they fail a quiz, they could be punished and if they pass, they keep getting the fees as rewards.

Author: AlexeyAkhunov
Date: 2018-12-04T09:22:42.058Z

Infernaltoast:

essentially all contracts become stateless


Yes, I understand you. Though my currentl thinking is that it will probably not be Ethereum anymore, because everything (perhaps apart from EVM) will be different

Author: alberreman
Date: 2018-12-11T22:24:49.901Z

Hey! I’m writing an article about state rent and would appreciate some feedback/commentary. I’ve seen a lot of back and forth on Twitter about who should ultimately make decisions about how/if to impose state rent. The developers who are the ones programming the fix? Account holders? Someone else? If you want to remain anonymous you can always email me at aberreman@ethnews.com

Author: AlexeyAkhunov
Date: 2018-12-11T22:52:15.040Z

alberreman:

I’ve seen a lot of back and forth on Twitter about who should ultimately make decisions about how/if to impose state rent. The developers who are the ones programming the fix? Account holders? Someone else?


Definitely not people on Twitter 
As state rent is a non-trivial proposal affecting lots of things in Ethereum, I would even say most of the things, it needs to be of a very high-quality and will probably need to go through more than one iteration of high-level descriptions, proof of concept, specification, dapp developer guides, testnet. The decision to adopt it or not is with the users of the network who maintain Ethereum nodes. The decision to create (code up) such option to adopt this change is with the implementers of various Ethereum clients. By the time the implementation starts it should be more less clear what effect the state rent would have on dapp developers and account holders. At the moment it is too early to worry about these decisions though, because the proposal needs much more work. But if I had to guess, the dapp developers are the most important category of people to hear from with regards to this - because they would need to do work to modify their contracts to work under the state rent regime. ETH holders would also be affected, but in much less significant way.

Author: alberreman
Date: 2018-12-11T23:21:09.374Z

Thanks. I hear you with the claim that it’s too early to worry about these decisions, but I also think it’s significant that I’ve seen people with a big audience, like vlad and vitalik, and magicians too, about the need for decisions requiring significant trade offs to be made by people other than the core developers coding the fixes. I think it’s especially important to include governance discussions like this as I write about “controversies” or big decisions facing the network, because without acknowledging those conversations, there’s a kind of implication that “there’s this thing that core developers are deciding on behalf of users that will probably piss a lot of people off,” when in fact there’s an ongoing discussion about how to make decisions in the most fair and transparent way possible.

Author: boris
Date: 2018-12-12T00:24:52.300Z

This is really well said.

Author: boris
Date: 2018-12-12T00:27:31.872Z

alberreman:

there’s an ongoing discussion about how to make decisions in the most fair and transparent way possible.


I think that’s the right way to say it. It’s super early. There isn’t anything to “worry” about – other than there is active discussion.
BTW, any Etherem (EVM) based chain will have this exact same issue and might make different decisions on how to evolve. Ethereum main, since it actually gets wide usage, is just the first one to face this.