A simple and principled way to compute rent fees

To make sure it’s not long-run possible for the state to exceed 500 GB, storing 500 GB should cost 500,000 ETH per year, so storing 1 byte should cost 0.000001 ETH per year,

Charging for storage naturally disincentivizes storage, but is there an economic/incentive/arbitration relation between 500GB and 500,000 Eth? Or is it just a presupposition that users will value storage on the ETH blockchain at 0.000001 ETH/byte? If I, and everyone else, value storage an order of magnitude more, then what actually stops the state from growing to 5TB? What happens when the state is full? The EVM throws errors on new state saving ops?

Only validators are paid to run full nodes, average user isn’t going to regardless. Validators and businesses that use ethereum can get larger drives.

People use light clients because the state is too big, not because they don’t want to run a full node. They don’t want to run a full node because it is inconvenient. Make running a full node convenient and they will.

1 Like

You still have to pay for the current EVM execution, I suppose, which has a one-time cost for allocating storage.

presumably when the state grows larger than 500 GB, the rent charge causes the ETH burn to go over the ETH minting rate which causes ETH to become deflationary. Over time given a constant market cap, this may cause the rent costs to become prohibitive, resulting in people taking their data off the chain to preserve capital. It seems like there will be a lot of fine tuning to find the correct charges for rent in order to find a steady state for ETH inflation while keeping the state size in mind.

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

If you want fee to be paid even from the non-staking perspective, then every not-locked eth could get small interest. Validators’ interest on top of it. It’s enough to keep a 32 bit block height per account with the last block that had a transaction to/from that account, and update balance on changes.

Locking eth is perfectly backwards compatible as it can be implemented in the existing gas mechanism:
txFee = performanceGas*gasPrice + ethForStorage
txGasLimit = \lceil{txFee/gasPrice}\rceil
with future refunds on deletion only for the lockedEth portion (no refunds at all for performanceGas).
(block gas limit ignores lockedEth ‘gas’)

How simple in comparison to time fees!

3 Likes

The other problem with locking as payment is that I think there is still a fundamental behavioral tradeoff that I think locking falls on the wrong side of, precisely because it seems so convenient. 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; forgetting about economics, achieving such a state of affairs is by itself enough to get the majority of the gains that we want to achieve from a rent scheme. On the other hand, if the majority of developers continue to by default use a scheme where contracts last forever, then there continues to be a tradeoff between either contracts being very expensive to create to begin with or the state size not really decreasing.

That said, there is a scheme based on pay-to-resurrect that I think could solve a large portion of the UX issues, that I’ll expand on in a separate post.

3 Likes

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