Ethereum State rent for Eth 1.x pre-EIP document

[AlexeyAkhunov]

@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

[hershy]

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.

[AlexeyAkhunov]

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.

[veox]

@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.

[AlexeyAkhunov]

@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.

[veox]

@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”.

[AlexeyAkhunov]

@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

[veox]

@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.

[holiman]

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.

[AlexeyAkhunov]

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

[Infernaltoast]

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.’

[AlexeyAkhunov]

@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.

[Infernaltoast]

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.

[AlexeyAkhunov]

@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

[alberreman]

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

[AlexeyAkhunov]

@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.

[alberreman]

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.

[boris]

This is really well said.

[boris]

@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.