Is there a practical way for Ethereum networks to handle considerably large volumes of data used by heavy contracts?

Question

It's not a secret that a single contract could potentially store quite a large volume of data (1, 2). Of course, it takes some gas, but it doesn't seem to cap strictly the overall volume of data to be stored in the entire network. There are also recommended ways to avoid that (like IPFS / Swarm), but again they're not restrictive. Even being inefficient, these data consuming contracts can be created and filled with data and kept in the depth of the network for times.

Now, assuming that blockchain is distributed, how are we going to handle e.g. a few TB heavy contracts? Does it mean, the network would need to distribute these terabytes across all the node to function properly? Maybe there's some sort of retention for such "lost stones"?

Or am I missing a point?

Answer 1

An SSTORE of a non-zero value costs 20,000 gas. Each SSTORE can store 32 bytes of information.

Double check my math:

1TB / 32 bytes = 31,250,000,000

31,250,000,000 * 20,000 gas * 1 gwei/gas = 625,000 ether * $750/ether = $468,750,000

So yes, a contract could store a terabyte of data and require all nodes to replicate it. But it would cost hundreds of millions of dollars to do so.

The data stored by contracts isn't actually part of the main blockchain structure, since it can be computed by rerunning all the transactions. So it's conceivable that nodes could simply not store that data until it's needed (at which point it would be expensive computationally to reconstruct). That said, depending on how the data was created in the first place, the transactions themselves may be just as heavy. (Note that gas must also be paid for the payload of a transaction.)

I don't know the details of the sharding work that's planned, but I imagine it includes not needing every node to store all the data. This might also alleviate the per-node cost of storage.