status-im/research
2
0
Fork 0
mirror of https://github.com/status-im/research.git synced 2025-01-12 08:04:12 +00:00
Code Issues Projects Releases Wiki Activity

Added a paragraph about rent

Browse Source
This commit is contained in:
Vitalik Buterin 2018-08-09 12:12:59 -04:00
parent 33700a752b
commit 815f083430
2 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
papers/pricing/ethpricing.pdf
View File

Binary file not shown.

2
papers/pricing/ethpricing.tex
View File

@ -411,6 +411,8 @@ Second, the developer and user experience considerably improves if developers an
For a simple cryptocurrency, the harm from one particular UTXO or account being deleted because its balance was completely drained paying storage maintenance fees is very simple to understand, and there are no complex interaction effects between different accounts or UTXOs that could result. For a more complex smart contract blockchain, rent does introduce more complexities, as there will be contracts that are very valuable for reasons other than the ETH (or other protocol-level base currency) contained in them, such as their function as software libraries, user-defined assets (ERC20, ERC721, etc) that they hold, active relationships with other smart contracts, etc. Hence, there is larger risk of an application suddenly becoming unusable because someone forgot to pay a maintenance fee.
One possible mitigation is to introduce two ways of paying for storage, one requiring a time-based fee and the other requiring a relatively very large one-time fee that ensures that the account can last forever. However, this is also vulnerable to arbitrage issues: an account that lasts forever can rent its storage out, and thereby earn interest by filling up storage slots, leading to complexities arising from competition between base-layer storage with maintenance fees and the second-layer storage market. If a permanent option is strongly desired, then the approach based on the time-based pricing/refund function $F(t)$ described above is likely optimal.
Such situations can generally be detected far ahead of time, but if this happens, then there is a second backstop that can be added to mitigate the effect of deletions arising from negligent failure to pay maintenance fees: a \emph{hibernation/waking scheme}. Accounts that run out of funds to pay their maintenance fees do get removed from the state, but they are not \emph{deleted}; rather, they are \emph{hibernated}. For any hibernated contract, anyone can submit Merkle proofs that prove two claims:
\begin{enumerate}