This article will describe a method for using “proof-of-storage” as the consensus mechanism for a public blockchain that hosts a cryptocurrency. We aim to construct a proof of storage consensus mechanism that can support a cryptocurrency for a number of reasons. Firstly, proof of storage saves an enormous amount of electricity compared to proof of work. Secondly, proof of storage does double duty: securing the blockchain and providing a useful service. Thirdly, proof of storage can work to “democratize” mining away from those with abundant capital.

An Outline of the Proposed Mechanism

Anybody can upload data at the cost of some of the cryptocurrency. This data is divided into small chunks and distributed among the network’s “miners”. As previous data storage cryptocurrencies have done, miners cannot choose what data they store and they must accept all of the assigned “work”. This is done so that miners cannot easily upload their own optimized data to get more rewards than they should. We will now consider the case when the price of storing data on the network is fixed with adjustments made at regular intervals according to supply and demand. This prevents undercutting other miners to get your own data. For example, one could have a system where there are five minute intervals where users can commit to supplying a certain amount of storage for the set price/commit to storing a file on the network at the price and then at the end of the five minute interval, buyers and sellers are matched up randomly and prices adjust for the next interval.

However, a number of attacks still exist against this system. If the fiat price of storage suddenly drops, many miners might leave the market, leaving potentially only a couple large miners left. If these miners comprise a large enough portion of the remaining supply of storage, they could upload their own optimized data and get it very reliably, and on top of that, get their storage fees back.

A (partial) solution to this problem is to simply not give the storage fees to the actual storage providers but actually just burn them. Then mining profits come from the block reward and transaction fees, as in Bitcoin. This creates a perfectly inelastic supply curve in the storage market.

But it may seem that this is still not enough. After all, when most of the supply of storage has been exhausted, we are in a similar solution again (ie. the remaining supply can upload their own files). However, if we limit the number of copies of a chunk that can be stored on the network to 3, as we will below, then even under optimal conditions (only one supplier on the market with three accounts uploading their own data to the network): the total block rewards in a month times 3 divided by b need only be less than the cost to store a gigabyte on the network for a month, where b is the total data stored on the network in gigabytes.

Note that the total block rewards in a month divided by b is simply your expected revenue per gigabyte per month of mining. This times 3 needs to be less than the cost to store a gigabyte on the network for a month. Amazon currently charges about $0.02/GB/month. So your expected revenue per gigabyte per month of mining must be less than $0.006666666. So an average person with a laptop hanging around with 500 GB spare can expect to earn up to $3.33 a month. Not spectacular but not terrible. An external hard drive costs about $30/terabyte. At that rate, they pay for themselves in at least 4.5 months, with an 8TB drive earning $50/month in profit after that initial period. So the supply side shouldn’t be a problem. The demand side is more of an open question but it seems likely to be able to be satisfied as well. So it is quite possible that it can be made impossible to attack the network in this way. Keep in mind that this is the extreme case; in practice, looser bounds may be used.

We must also note the existence of the so-called “sybil attack”. In this attack, one creates many accounts that all mine. The point is to get multiple accounts assigned copies of the same chunk so that the chunk only needs to be stored once. This is difficult to avoid so the only remedy we employ is that the data mining accounts have to publish to the blockchain (so it can be verified later that they were indeed storing that chunk) incurs the regular cost of publishing data on the blockchain. This prevents creating almost an unlimited number of accounts from becoming the optimal strategy. If the maximum number of copies of a chunk that can be stored is set at 3, the advantage to sybil attacking relative to acting naively is bounded by a factor of 1/(1-x) where x is the proportion of the network storage supply controlled by the miner, for x < 2/3. If we bound x to be less than 2/3 with regards to the previous attack as well, we obtain a factor of 2 instead of a factor of 3.

We now consider another attack against the network: “outsourcing attacks” where one uploads the data they were assigned to store to the network itself and retrieves it whenever necessary. In the extreme case where one is able to execute the sybil attack perfectly on all three copies with the freed-up space, this is weakly worse than the “generation attack” we first considered, so it implies the same bound.

The data you are assigned to store seems unlikely to be easily able to be generated (if others are acting rationally anyway). But we will consider anyway the possibility of pulling off all three of these attacks at once. However, it quickly becomes clear that this provides no extra benefit to the sybil+generation attack besides the fact that you don’t have to store that chunk to start with. If you upload a chunk and it gets assigned to you, you can pull off the sybil+generation attack. If you upload a chunk and it gets assigned to someone else, you don’t gain anything because you didn’t have to store that chunk to start with.

These are three major attacks against the system and how they might be avoided. To sum up, sybil attacks are difficult to solve and therefore, we just deal with the consequences but prevent infinite accounts by having a small fee that comes with starting to mine. Generation attacks can be solved by bounding the total block reward per month by the storage price for a gigabyte per month divided by three times the number of gigabytes stored in the network. Outsourcing attacks can be solved the same way as generation attacks.

Next, we will describe a few specifics of a possible implementation using the above ideas.

Mining works by choosing a point in the range of the hash function. This point is the hash of the previous chunk that was successful in mining. Over time, a symmetric interval opens around this point. If you hold a chunk which when combined with an assigned nonce and your own private variable hash to within that interval, you can create the next block. The hash of the hash of the chunk+nonce+private var is published beforehand in a merkle tree so that it can be verified. The nonce is different for each copy of a chunk so that different copies of the same chunk have different hashes.

To solve the nothing-at-stake problem, mining rewards are held for X blocks. If someone detects two blocks mined by the same account at the same height then they can publish that info destroying their reward and receiving some portion themselves.

To solve long-range attacks, we employ timestamps.

To prevent griefing via deletion of data, we require a deposit for mining that is destroyed if any data goes missing. To detect this, the network requires certain chunks to be published within a certain number of blocks every block. There is also a mechanism whereby people can challenge others to publish a chunk they were supposed to be storing on the blockchain.

A note: with all this chunk publishing, of course all the data stored on this network should be encrypted first.

Conclusion

I believe that this has laid out a possible way to implement proof of storage as a consensus mechanism. As mentioned at the beginning of this article, this would have many benefits for public blockchains hosting cryptocurrencies, though this mechanism is not without its flaws. If you have noticed another flaw in my mechanism or have any comments or questions, please feel free to leave a response below.