Just pointing you to.
I heard good notes from @arachnid @vbuterin and they have changed my mind on the topic, as well as many other people. So here is a more formal explanation if anybody in interested in the rent topic.
I really don’t think it’s a good idea to tie the cost of rent to a fixed value in ether. The cost of rent should depend on storage constraints, not on how much people are willing to pay for a unit of ether.
Have you seen the discussion here about including a sleeping/waking mechanism to go along with rental storage? Including the ability to wake up a contract after it has been evicted will make it so that people will not have to fear that the eviction process will cause them to lose everything.
I also think that it is a waste of storage space to keep track of the balance and the rent balance separately - Getting evicted while you still have an ether balance is going to be the dumbest possible waste of eth, and if we use a sleep/wake mechanism, the account can be put to sleep whenever you don’t want to keep spending eth to keep it in storage.
I also think that there needs to be a better argument for fixing the price then “we can peg one of the values and it will be okay.” It is reasonable to say that the fixed value will make storage time more predictable, but that argument needs to be fully fleshed out so that it can be compared with the alternatives - a floating value or a governed value.
Thank you @arachnid and @jvluso for these points.
It is not spelled out in the proposal, but as-is this is by default a governed system. The storage cost can be changed at any time, this would require a hard fork. We are currently using the same approach with Constantinople. Specifically, EIP-1234 governs how the fixed fee for PoW miners will change.
You are both considering a market based approach (“storage constraints”, “floating”). I am trying to understand more about what you mean so I can make an improved proposal. Would a proof-of-storage system be moving in the right direction of what you are thinking?
Putting a couple ideas here to illustrate, but I haven’t read any existing work on PoStorage yet.
- Assume the Ethereum mainnet storage tree is 1 TB.
- Update Ethash:
- Currently, there is a 16 MB seed which generates a 1 GB+ dataset (“seeded dataset”). You pick a nonce and hash a bunch of times across this dataset. Your proof can be tied back to the 16 MB seed.
- Proposed is to use the state tree as a second 1 TB dataset (“state dataset”).
- When performing Ethash, the miner chooses whether to use seeded dataset or state dataset.
- Update the difficulty calculation:
- Currently, blocks based on seeded dataset are valid if the hash is less than DIFFICULTY, this stays the same.
- Propose that blocks based on state dataset are also valid if the hash is less than FULLDIFFICULTY.
- Currently DIFFICULTY changes to target 15 seconds per block.
- Proposed is that DIFFICULTY and FULLDIFFICULTY change to target two constraints: 15 seconds per block and 50% of blocks use full dataset.
- Now we can price rent based on how expensive storage is.
- If FULLDIFFICULTY = DIFFICULTY then apparently it is very easy to run a consensus node, so rent is free.
- If FULLDIFFICULTY is a super-low threshold because nobody is running a full node then rent increases to cover the full block reward.
- Somehow it scales in between these two extremes.
This concept to set a price is fairly straightforward. But practically it becomes more difficult to implement. This is because changing the rent price is a O(N) operation across the state dataset with N ~ the number of accounts – I was hoping this would be necessary only once.
In other words, it’s easy to predict when a bunch of rockets will hit the ground… just calculate each touchdown at launch based on SV_GRAVITY, then recalculate any rocket on thrusts. But if SV_GRAVITY keeps changing then you have a lot more to worry about.
~~
Is this PoStorage more in line with what you are thinking?