A simple and principled way to compute rent fees

Sharding
41

Yes, but if people don’t use it, maybe it’s because a refund of half the gas used is not enough? Or maybe the cost of storage is too low in the first place? Both?

I haven’t seen this written down in detail, but gas refunds don’t solve the problems, because they still don’t charge for time value of storage. This is a fundamental problem which means that even with gas refunds, there is no upper bound on the ethereum state size. There are other smaller problems: you have to design the gas refund mechanism so that miners are still willing to mine transactions that refund gas, and if we get too close to validator-dilemma type bounds I think this might be impossible. The way that gas refund is designed today means that users are incentivized to place junk in the state when prices are low, to get a refund when prices are high (see: gastoken.io)

42

Bear in mind that 500 GB in 20 years will be peanuts. A time based deflation factor reflecting storage and bandwidth costs should be considered.

43

A question… Who would pay for what?

There is talk of reactivation and similar things… Now what came to my mind is a non-fungible token economy, with immense storage usage. Say, cryptokitties. It goes out of fashion, gets pruned from the state as people don’t pay the rent, and then a collector with a million-dollar genesis kitty wants to sell it. Will they have to pay the rent for the WHOLE STORAGE, as in every single cryptokitty ever? Clearly yes, as Ethereum contracts to date are self-contained, and assets belong to the contract, not to the client account.

You can’t re-awaken just part of a contract.

Now this means something even more problematic than demurrage of contract-held Ether. It means that crypto assets on Ethereum are no longer self-sovereign. I cannot own a cryptokitty unless every other member of the community also pays. Assets stop being assets, and become, well, virtual goods managed by DAOs as opposed to corporations (but let’s be honest, most of it will still be corporations).

Individuals lose any power or self-sovereignty they had to begin with. Most tokens become essentially worthless, and tokens can and will go to zero (if the value of a token goes below the breakeven of me reactivating the contract by myself).

Also, who will manage the recurring payments? I don’t see how most contracts could handle this automatically. Sure an EXTREMELY liquid token could seize assets from non-rentpaying holders to liquidate, but… hey… first of all, this sounds like contract bloat - it might be too big and complex to be written in a single file (Vyper), too big and complex to even fit into a single block gas limit, and too big and complex to be audited -, and then second, liquidate WHERE? It would need to know an exchange to do that. Which exchange? What if the exchange dies, is hacked, moves, etc.? What if nobody is buying?

And this is only the narrowest class of assets, highly liquid fungible ones. Any others would need a human corporation - administrators, fee collectors, people who do the liquidating, etc.

I don’t see how this wouldn’t irreversibly DESTROY Ethereum as an ecosystem.

ps. To me, the biggest promise of Ethereum was the independent programmed entity. A program providing an economic service that is entirely beyond the reach of regulators, because nobody has ANY power over it. And that includes me, the creator. I don’t need all kinds of licenses and papers, because I won’t be providing financial services - I just created something that will, independently of me. This is revolutionary and immense.
This is also dead the moment pay-to-stay gets introduced. “Unstoppable” is no more.

6 Likes
44

I predict a lot of contract programming will switch from “big monolithic contract” to “one contract per object of interest” (eg. domain name, cryptokitty, etc). Practically speaking, this is a good thing anyway for other reasons.

Now this means something even more problematic than demurrage of contract-held Ether. It means that crypto assets on Ethereum are no longer self-sovereign. I cannot own a cryptokitty unless every other member of the community also pays. Assets stop being assets, and become, well, virtual goods managed by DAOs as opposed to corporations (but let’s be honest, most of it will still be corporations).

I think this is a bit extreme. As was mentioned in a separate thread, you will be able to resurrect contracts that have not paid enough rent by paying a fee and supplying the Merkle branches to prove its state. Also, if cryptokitties switches to the “one contract per object of interest” model, then cryptokitties absolutely will still have the property that “if you maintain yours, everything will continue to be fine”. ENS already works in this way, so ENS domains will be exactly as “self-sovereign” as they work before.

2 Likes
45

@vbuterin, did you try to do any estimations for an “average” user having X ETH and participating in Casper for one of the shards, simultaneously having 20 tokens (each token is roughly equal to 5 storage slots)? Such user should ideally cover all his rent expenses by his profit from PoS bidding.

46

@vbuterin how would a fungible token work in this one contract per point of interest approach? To me it seems we’ll need to retire the entire ERC-20 concept, and go for something that looks more like UTXOs…

But then, what about token authenticity? Similarly to Bitcoin UTXO structure, the only way to validate a “coin” contract is to track it back to the issuer. Now if the contracts in its provenance chain are no longer in the state trie, you’d need an archival node to differentiate between 10000 fake Raiden tokens, and 10000 real Raiden tokens. (And even so, it would be impossible from within the EVM!)

This goes for non-fungible assets too… I could totally “make” myself a cryptokitty. Copy or reverse-engineer the contract code, put in the identifiers… Without a central registry, the only difference between that and one that got created as part of the cryptokitty ecosystem is provenance… and central registries will be impossible to maintain in the new fee model.

ENS uses a central registry to keep track of individual resolver contracts. Who would be paying for that, and most importantly how? The only thing that gives an ENS resolver contract value is that it’s in the registry. The individual name contract by itself is worthless.

And I really wonder how much that would cost, or it would even be possible, if the state size of that contract is measured in megabytes or even gigabytes. (For central registries, this could totally happen, either by spamming, or by legitimate use.)

And contract state spamming as a DoS attack shouldn’t be discounted. Especially government entities, or even corporations could use this to “murder” contracts they don’t like. Just bloat the state until the community is unable to keep paying the fees, and nobody will be able to afford a reactivation.

nb. I’m not trying to detract the idea of storage rent, it’s something we probably really need, as otherwise there is no check on state growth. However, this would fundamentally shift the way Ethereum operates, and the way we need to program for it. There might need to be changes to client software and the EVM itself as well, to accomodate for these new ways.

Reactivation for example, in my opinion, should be possible by simply “asking” an archival node for a certain convenience fee. Eg. light or “fast” node submits reactivation request, archival node snaps it up, gets paid, extracts proofs and last known state from the chain archive, and reactivates the contract. (This would also, finally, provide a real incentive for running an archival node.)

I’m quite eager to see how we can make Ethereum work in this new paradigm.

2 Likes
47

This is off-topic, but it’s easy to prove that a contract was created by a particular contract, since its address is deterministically generated based on the contract that created it. So if you have a single stateless manager contract that is responsible for creating all new contracts for that asset type (i.e. issuing a token, breeding a cryptokitty) you can verify that a given contract has valid provenance by checking that it was created by that manager contract. (The manager contract is stateless, but it doesn’t even have to be in the current state for you to do this check, as long as you know its address.)

You could also use a manager contract to merge and split contracts representing bags of fungible tokens.

48

Trying to be open about this idea but just can’t get into it as it feels like Ethereum’s initial promise is broken. Personally, I highly doubt so many devs would join on board if rent was part of it from beginning (I wouldn’t for sure). It’s not an all-inclusive world computer anymore. Moreover, it seems Ethereum is hitting a wall because initial design is not appropriate and I’d rather see solutions trying to incorporate other building blocks of Ethereum, like Swarm (which for me is one of the most promising tech outside). Why not rather incentivise storage on Swarm, extensive use of payment channels (which Swarm also offers) and reduce the state in this way - blockchain should be used only for final settlements and conflict resolution. Swap, swear and swindle framework is directly addressing blockchain scalability but it is being ignored by core eth devs which I find rather sad - @vbuterin I don’t recall a single tweet and mention of Swarm for quite some time while I remember listening to Ethereum’s roadmap in 2015 where Swarm and Whisper were an important part of the roadmap.

49

Why not rather incentivise storage on Swarm

Swarm never promised to let you store data for an infinite amount of time for a finite cost; “rent” was always assumed to be part of any significant usage of Swarm.

Also, I suppose I need to continue reiterating that with the proposed scheme, contracts that don’t pay rent don’t just disappear; they can be reawaken by providing Merkle proofs for their data. So you can absolutely keep using Ethereum in a similar way to how you do now, you’ll just have to pay a bit more (realistically it will on net be less than today post-sharding) to keep providing Merkle branches.

1 Like
50

Contract code could be written in such a way that if you increase its state size, you have to pay additional ETH to maintain its TTL for the new state size. Additionally, the protocol-level witness architecture, and the “one contract per object” architecture, would both make involuntarily bloating contract state impossible. I expect such architectures to become popular. ERC20 tokens, for instances, can absolutely be designed in such a way; the main token contract would create a child contract for every user to store their token balance.

52

Swarm never promised to let you store data for an infinite amount of time for a finite cost; “rent” was always assumed to be part of any significant usage of Swarm.

What about upload and disappear, how does that work if you need to pay rent? SWARM Guide — Python documentation

Also, I suppose I need to continue reiterating that with the proposed scheme, contracts that don’t pay rent don’t just disappear; they can be reawakened by providing Merkle proofs for their data. So you can absolutely keep using Ethereum in a similar way to how you do now, you’ll just have to pay a bit more (realistically it will on net be less than today post-sharding) to keep providing Merkle branches.

Can you estimate the cost of awakening a contract? Is the awakening price dependent on the amount of state storage used by the contract? Could the gasLimit prevent a contract too big from being restored? How would that work with closing channels (like if you want to close a channel after a microtransaction, wouldn’t the cost be prohibitive if you also need to awake the contract)? or a channel inside a plasma chain?

Contract code could be written in such a way that if you increase its state size, you have to pay additional ETH to maintain its TTL for the new state size. Additionally, the protocol-level witness architecture, and the “one contract per object” architecture, would both make involuntarily bloating contract state impossible. I expect such architectures to become popular. ERC20 tokens, for instances, can absolutely be designed in such a way; the main token contract would create a child contract for every user to store their token balance.

The key wording here is “Contract code could be written” but what about all the existing contracts? Do you seriously expect every ERC20 token to deploy a new contract and migrate everyone?
What about every others type of contracts that were not written to take into account that kind of change?
The most likely scenario of introducing that kind of change is a contentious hard fork in my opinion.

While I agree the growing state might be a problem, I don’t think this is the solution, and it’s not the only problem either.
The growing size of the full blockchain is even a bigger concern, in my opinion, the synching take an unreasonable amount of time.
And since we are talking “rent” the other big problem is that nobody is paying non-mining full node for data storage/bandwidth anyway, while Casper will help with that, nodes still won’t be paid the same amount for storing the same things.

53

@vbuterin any kind of address mapping would mean that ttl fees grow proportionately with the number of users. I see two reasons why making each user pay for ttl of a single common contract is impossible:

  • Iterating through a registry in the evm is impossible. Even in case of a (highly suboptimal) array registry, gas costs make iterating over all users (eg. to verify “tax” payments or seize assets from nonpayers) untenable.

  • Contracts are passive. An administrator is always needed to kick off any “tax collection” logic. (Per each user, separately!)

Now because of this, paying tax is entirely voluntary, or needs an offchain tax authority. This pretty much means that registry contracts always need an organizational (usually corporate) background.

Even if “registering” requires the payment of a year’s ttl on one’s own state, after a year, “register and forget” users will invariably drag the community down.

As for ERC20 contracts spinning off balances into “coins”, I don’t see how that could maintain the ERC20 interface. balanceOf(addr) would need a way to calculate coin contract addresses, or a mapping. And if we have a mapping, we’re back at square one.

About the reactivation… What if the state is larger than the block gas limit?

@danrobinson if I’m correct you’d need to try all past nonces of the address and hash them each to get all possible child contract addresses, until you find the address, or run out of nonces. Especially with a highly active parent contract, this sounds pretty expensive for an everyday (or, more, “every millisecond”) operation. Changing the contract address calculation scheme to be bidirectional, or adding parent address as a system field would probably help.

Otherwise, I like your proposals. I guess we could take this to another thread, even though making sure that this change to Ethereum won’t favor corporations using it as a database, over spontaneous, self-sovereign individual cooperation is probably too important to be strictly offtopic.

54

If the price of rent increases, the number and volume of contracts will decrease - this will lead to an outflow of users. If the cost of the contract is low, the number of miners will be reduced. Any fixed price will not be perfect. I suggest a crazy sketch:
rent = alpha * number_of_contracts_kb - beta * number_of_mainers
Coefficients alpha and beta will be searched like this: Let’s train 3 models of linear regression on ether data and other currencies. Models will predict the number of miners, the number of users and the price of the ether. If the number of predicted users is greater than the current one, the coefficient alpha should be reduced, since the reason is expensive rent. All this is very difficult (If you look at it in detail). But if you approve the concept, I can think about it in more detail. (The concept is to train model co-factors to maximize the number of users and cost)

55

Not true. Tax is collected at two points:

  • Whenever the state of an account changes, the account’s balance decreases by (block.number - last_accessed_block) * storage_size * fee, and last_accessed_block and storage_size are updated.
  • If a contract has less than N blocks of ETH left (eg. N = 1000, so balance < (block.number - last_accessed_block + 1000) * storage_size * fee), then anyone can “poke” the contract, hibernating it and taking that minimum balance for themselves as a reward.
56

I created a thread for this contract economy discussion, as it’s indeed offtopic here:
Contract economy challenges on a pay-to-stay Ethereum

What I meant was taxing individual stakeholders in a shared registry contract, not the TTL balance of the contract itself… The TTL balance needs to be filled regularly by someone.

Normally that could happen as an additional expense on calling operations on the contract (who uses it pays, similar to highway tolls), but that becomes potentially untenable if the state is inflated by register-and-forget users, especially if the contract has far more read than write operations.

Say, the ENS registry is mostly used for offchain lookups, so users don’t pay anything at all. Name owners pay when registering their name, and can forget it after.

New registrants will have to pay more and more in fees, in effect subsidizing the storage rent of previous registrants!

Registrants could only be incentivized to pay their part of the rent regularly, if their registrations could be ejected if they don’t. However, this would either require iterating over all registrants with a “tax paid check”, an operation that’s potentially unrunnable on chain due to gas limits, or an off-chain registry and a “tax authority” to manage this (ie. a corporate owner of ENS).

2 Likes
57

One possibility is to have contracts by default have a mechanism where if they have less than 1 year of TTL left, any call to them must pay up to bring the TTL back to 1 year. This would just look like an extra transaction fee, and would have the property that a contract only hibernates if it is literally left unused for an entire year.

3 Likes
60

If we assume that storage costs decline exponentially, as it appears they do, then you could say it declines at a rate of 1/k^p, p > 1, and if true, then the total cost to store a unit of storage would converge to a finite value over time. If this is the case, then it would seem like it would be much more simple to model that into gas costs for storage operations. Just a thought, and the assumption may not be true.

61

True. However, I’m considering that we could use the metaphor that Swarm is HDD and the state is RAM in terms of storage cost (not persistence) which should make storage on Swarm cheaper and separates concerns of storage. What about other scaling solutions Swarm is proposing?

62

The size of the blockchain is a legitimate issue, but at the current point, it’s not an emergency issue.

A simple fix (that could last 10 years or more), would be to add an option letting nodes choosing the quantity of data they accept to store.

I’m sure there will be a lot of nodes willing to store the whole blockchain for free. So it’s not a big problem currently.

Presently, the major issue is the protocol : designing a decentralized consensus able to validate a transaction for a fraction of a penny and within 10 - 20 seconds. The scalability level should be a few hundreds of transactions per second.

My preference is a network of POS masternodes (ETH validators).

I think most available resources should be patiently and continuously focused on this main objective, even if it is difficult, if there is a lot of pressure, and many other things to think about.

The first step is Casper, and the Casper testnet does not have enough support and resources currently : only 7 nodes at this time : http://34.203.42.208:3000/

I tried to install a Casper testnet node on Linux a few weeks ago, but the install process is not detailed enough even for people who are used to install crypto softwares on Linux.

There should also be bounties for people testing. At the current point, 7 nodes are not enough to validate the protocol.

The most useful and legitimate thing to do would be to push Casper in priority, and then to deliver a full POS consensus run by masternodes.

Other issues just like sharding (which I doubt), plasma (side chains), fees, rent, … are debatable but should not be a priority and consume too many resources at this point.

1 Like
63

I don’t think we can overlook the fundamental issue of state trie size.

(nb. even though you’re talking about “the whole blockchain”, the blockchain and the state trie are totally different things…)