Storage costs are high in the EVM model. We’re wondering if the developer community is interested in a rentable storage facility. The idea is that you could allocate some kind of storage area that would cost less but would evaporate unless regular “rent” was paid to keep it alive.
This could be much cheaper for data with a limited lifetime, because the system could avoid the usual Ethereum requirement that storage needs to be available forever.
An obvious way to implement this is with a precompile.
Is this valuable to developers?
40 Likes
Here’s one approach to rentable storage:
Add a precompile that lets a caller create a “storage bin” that it owns. The owner can use a precompile write a block of data to the bin. Anyone can use a precompile to read the current value from the bin.
Many bins can exist. Any account can own as many bins as it likes, as long as it pays for them.
The cost of a bin is linear in its size.
A bin will evaporate after a fixed interval (say 14 days) unless a fee is paid to renew it. Anyone can pay to renew a bin, for as long a period as they like.
The fees create create and renew bins should be lower than creating storage, because create/renew is paying for a limited time period, but storage allocation must pay to store the data forever.
21 Likes
There was an approach for Ethereum called EIP-103.
The idea was straight forward. It created two new columns in the database:
- Last accessed
- Total bytes
An opcode was devised such that, a user can update both items in the row to say “I want to pay for another 500 blocks of storage”.
If no one paid for the storage, then a block proposer could ping the data slot and delete it. I guess they’d get a bounty for this.
The issues that came up:
- Someone needs to pay for autonomous smart contracts, otherwise they get deleted. (Imagine a liquidity pool Uniswap disappearing because of it).
- Some transacting overhead to deal with updating the storage slots.
- UX was annoying
Vitalik has a nice tweet:
i.e., that is beautiful in theory, but horrid in practice.
In general, the community started to favour two different approaches:
-
State expiry. A list of “old databases that can be deleted” and a current database. If you want to recover old data, just so an inclusion proof of the last database it was in. So basically, you end up with recent data in the current database and if you play with the gas limit, can estimate its likely size.
-
Statelessness. Transactions carry inclusion proofs and the node can use this to process the transaction. Nodes don’t need to keep around the database, but can validate that the transaction is still correct.
So generally, trying to guage the maximise size of the database and then push the database away from the core network protocol. Someone like Infura could provide the service for users.
16 Likes
The big difference with what we’re proposing here is that it is opt-in for the contract author. Anyone worried about the state disappearance that you described has the option of not using it.
The best long-term approach is for Ethereum to adopt EIPs like the ones you described, that change the model to reduce storage load. But that isn’t going to happen for some time, and we might want to offer other options in the meantime.
12 Likes
Agreed with you @edfelten and I would like to say on this
YES! 
11 Likes
+1, I have a dapp use case for rentable storage.
Currently only L1->L2 retryable tickets enjoy the benefits of rentable storage.
Can this be opened up to any contract which wishes to opt-in to rentable storage?
What’s the status of this feature?
My sense is that this is not likely to be implemented soon on the DAO-governed chains, but that could change, if this is a high priority upgrade for the DAO (compared to other available improvements).