A simple and principled way to compute rent fees

TB drive is extremely common for most of the young adults using PC, are you talking about SATA or normal ones. Either way we are heading towards the specialized computer/harddrive for mining anyway, so POS would be mostly hosted on specialized equipments (possibly made in China)

1 Like

so POS would be mostly hosted on specialized equipments (possibly made in China)

I would really like to avoid encouraging that further. I recognize that that’s likely an optimal setup especially for high-value stakers, but that’s not an excuse to risk adding even more dependence on specialized hardware.

Additionally, keeping initial fast sync time low is also important.

2 Likes

don’t think you have a choice as many have told me that they will design it as long as its “profitable”. a long term solution is to restrict that exploitation.

do you think async would be better? fast sync time requires firmware level optimization, which eth hasn’t done too much about (as it relies on VM, but plz correct me if I am wrong)

Ah, I was operating under the assumption that the rent was being paid to validators, rather than being burned. +1

Perhaps the rent could go to those running full nodes.

3 Likes

One key goal of rent, at least in my opinion, is that contracts that developers and users forget and stop caring about should disappear from the state by default

You’re making a very dangerous assumption.
Sorry for the comparison, but - it’s the same reasoning as that used by honest btc smallblockers: sacrifice user experience now for the sake of more sustainable future. The dangerous assumption is that users stay.

Imagine that you want to create a dapp and you can choose two platforms to develop on: one has explicit time rents and one doesn’t; everything else, including userbase, is equal, including vm.
The choice is obvious: you can launch your dapp on the platform without explicit rents faster, one less thing to think about.
If for some reason you choose to deploy on a more complex platform first, a potential competitor that started at the exact same time would be able to launch first on the simpler platform.

Userbases aren’t going to be equal for long.

In an abstract way: markets execute stochastic gradient descent. An optimum that’s not the closest local optimum almost surely isn’t going to happen.

1 Like

Here’s the writeup for the sleep/wake mechanism: Improving the UX of rent with a sleeping+waking mechanism

Essentially, this degrades to “if you want to do something with a contract that got accidentally deleted, you just need to send a bunch of extra Merkle proofs along with your transaction to bring it back, so it’s kind of like the stateless client model”. I actually think it could be designed to be pretty tolerable.

2 Likes

It is true that 500 GB is too low compared to the current state size.

Perhaps with stateless clients and storage rent then the storage will not grow above 500 GB, but that is a tenuous assumption if we assume that Ethereum 2.0 scales much more and it is necessary to store it in the state. However, much of it could be stored off-chain in secondary markets with archival nodes and fraud proofs.

That chart is extremely misleading. 500 GB is the data size of an archive node. The size of the state alone is 5 GB. For Ethereum 2.0, I am assuming a theoretical max size of 500 GB per shard, not in total; so the total storage would be ~50 TB (and perhaps we can eventually increase the shard count, say from 100 to 256 or even 1000).

You need the platform to be sustainable in the long run; you need to internalise costs. At the same time you deal with adverse side effects like a worse UX, such as second layer markets. One way or another, the platform will fail, be disrupted, or stagnate if the costs are not internalised.

1 Like

OK, that’s fair enough, I neglected to think of that.

That’s orthogonal, the complexity is inherent in demurrage itself. Things like wrapped eth become impossible; at best it reduces to ‘eth during creation’. Everything that uses eth as a currency - all decentralized exchanges, bet contracts, even cryptokitties - would have to change their logic for a decaying currency. Decaying collateral would mean that liquidation of a dai stablecoin contract becomes a certainty.
Indefinite payment channels are dead. A valid signed transfer of 1 eth today can stop being valid tomorrow.

Tokens would have none of these problems, so ether would become the worst unit of account, unit of exchange and store of value on the platform. A utility token used exclusively for fees.
Ironically, much lower price resulting from this would almost certainly result in more state stored than the simple locking model.

Psychologically it destroys the immutability and store of value meme. It’s fine to argue technical points about rents, but all a typical crypto holder is going to see is that he has less eth that he should and interpret that as theft.

The question is not about whether to internalize costs, but how.
Locking eth already internalizes cost, the only difference is that state isn’t automatically deleted:

unless hardfork/gas limit like/ increases are going to be substantially smaller than increases in the total supply, the explicit payment model makes no sense, as it adds complexity for no gain.
IF they are going to be, then all that additional complexity is there only to prevent a few percentage points of growth at most.

3 Likes

Not true. Storing tokens would also require paying rent, just like storing both tokens and ETH already requires transaction fees.

Everything that uses eth as a currency - all decentralized exchanges, bet contracts, even cryptokitties - would have to change their logic for a decaying currency. Decaying collateral would mean that liquidation of a dai stablecoin contract becomes a certainty.

If we want to, we could store TTL separately from ETH balances, and then users would always have the ability to just pay the minimum 1-week upkeep every time, and reawaken their contracts every time they need to; this would be equivalent to what they would have to do if we were in a stateless client model, they would just experience the upkeep as just another kind of gas fee they only have to pay when they use the system. It would be more expensive for them to do things this way, but still likely substantially cheaper than the current status quo without sharding.

2 Likes

If we want to, we could store TTL separately from ETH balances

That’s way better, as long as the basic account itself is free (balance + nonce) to prevent all problems from demurrage. The balance could theoretically function as a read-only store, but setting the minimum positive balance to eg. 100 gwei should prevent any actual abuse.

I agree that would work. Without demurrage and with the inevitable rent-paying markets that take people’s eth for staking and pay for chosen storage, this becomes economically equivalent to the direct eth locking model, although more complex and requiring maintenance. The maintenance aspect satisfies the behavioral incentive function you want.

1 Like

In the future, the storage capacity of devices will increase, and we will want to decrease the price. The initial version should include a governance mechanism to allow this. Tying it to the governance mechanism used to determine max block size seems reasonable, so that when better governance mechanisms are researched, they can both change at the same time. The current mechanism also throttles the rate at which this sort of constant can change, which will be nice for people to be able to create their contract and forget about the rent for a long time.

1 Like

In the future, the storage capacity of devices will increase, and we will want to decrease the price. The initial version should include a governance mechanism to allow this

Agree. I would also say that we should have the ability to decrease, but not increase the storage price. This way we get the kind of flexibility that will end up mattering more in practice, and also give the direction of price predictability that matters more in practice.

1 Like

In this computation is the rent burnt or paid to validators?

If it is paid to validators, it seems to me that the “long-run cap” actually increases by about 0.5% every year

Would address balances decay over time or would it be an initiated process?

If it’s a decaying model, you could just leave a balance of 1 ETH and have storage security for 41 years. I think that’s pretty low risk if you have millions in this address (>1 ETH).

It is burnt. Ultimately there’s no reason to make short-run validator income dependent on short-run fluctuations in state storage. In the long run, there are proposals to have a long-run cap (eg. 120 million) and then scale all rewards by a factor of (120 million - current total supply), which would mean that in the long run all burnt ETH is paid to validators, but that’s a different mechanic and doesn’t affect short-run incentives in the same way.

I think rent fees are an awful idea, to be honest.
It completely breaks the original promise made by the ethereum project: Build unstoppable applications.
You can’t call an application unstoppable if it gets shut down for not paying “rent”.

If you want to clean the state from contracts that are no longer used, you should instead incentivize self-destruction of contracts by refunding a partial amount of the gas used by that same contract for storing its data.

1 Like

Do you mean like the existing refunds for sstore and selfdestruct? https://gastoken.io/#how