A simple and principled way to compute rent fees

Does this mechanism address your concern: Improving the UX of rent with a sleeping+waking mechanism? A contract that misses a rent payment doesn’t get shut down; anyone can still use it. It’s just that when you use it, you have to pay a little extra and provide a little extra data to remind everybody what was in it.

I think it’s helpful to come at this from the opposite direction. Imagine Ethereum had started out with fully stateless validation. Every transaction has to prove the current state of every contract it touches (with Merkle proofs from previous state headers).

This would be very efficient for validators—no need to track almost any state except the block headers! And IMO it would still fulfill the promise of unstoppable applications. But it would be pretty inefficient for contracts that are accessed very frequently, and leads to complicated race conditions when the proof that comes with a transaction is from an outdated Merkle root.

So we could ameliorate those problems by requiring that validators cache the state of each contract for some amount of time after such a proof is provided. And for convenience, if a contract wants to avoid being dropped from the cache, it can burn some ETH to bump its TTL. If you don’t pay rent, your contract gets dropped from the cache, but it’s still part of the Ethereum state, and can still be accessed by anyone just by providing the necessary proofs.

2 Likes

I might be wrong, but wouldn’t this break backward compatibility with a bunch of frontends/interactions between existing contract, that require the use of pure/view functions to work?

What happens if A is removed from the state?

contract A {
  function a() public pure returns (uint){
    return 1;
  }
}
contract B {
  A a;
  function b() public view returns (uint) {
    return a.a()+1;
  }
}
1 Like

You’re always free to keep more state than is strictly required for block validation. Infura could maintain every contract’s state (and even provide your client with a proof of that state, so you don’t have to trust them). And your local Mist could maintain the state of contracts you’ve viewed, or that it knows you are interested in.

But yes, interfaces will probably have to consider the possibility of failure. It’s definitely a tradeoff (link rot is a real problem on the web) but maybe one worth making to prevent the validator state from growing without bound.

2 Likes

As long as SELFDESTRUCT is a thing you will always need to reason about the probability of or lack of probability of failure. Having more explicit reasoning about the liveness of dependencies isn’t a huge burden, IMO.

In your example, B would throw until someone paid to resurrect A (the trickier example is if someone used the unchecked .call() construct, then they could potentially get an unexpected “return 0”, but such unchecked sends are not recommended anyway).

The alternatives are unsustainable state size growth, or stateless-clients-only, which have the same dev UX limitations surrounding state storage.

2 Likes

Yes - I think a rent mechanism for state is the right thing to do. Will state rent be burned so will this be a deflationary factor? Also, I guess ether balances will have a special role and not require rent, correct?

The answer is that calling B.b() will also fail (calls to empty code would throw by default in this proposal), and if you want to call it then you would have to wake A.

I Love the way that you think in terms of ensuring accessible technologies for all. If we can maintain this stance across all emerging tech, the ethical barriers we’re facing will be dissolved. Great thread. I’m learning a lot. Thank You to all contributors.

1 Like

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)

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.

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

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

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

@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

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.

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.

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

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.

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? http://swarm-guide.readthedocs.io/en/latest/introduction.html#basics

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.

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

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)