Impossible to cheat: Assuming "ongoing storage costs", on every payment cycle, rotate the blocks somewhere else (non-predictably). The hashes are probably stored on blockchain, so the receiver can verify them. So to cheat, you need to produce a collision or miss out on your payment.
Practically that's impossible, since the network would need to swap the whole datastore once every payment cycle.
Say each block is stored on three nodes, then these nodes could each generate a nonce, compute a hash of the stored block (using all nonces as IV) and then vote on whether they still have the original file or not. This is much more feasible, as only nonces and hashes are transferred (a few dozen bytes instead of e.g. 64MB blocks).
In that case they can store nothing and instead cooperate to generate spoofed hashes, so you probably want some auditor nodes.
I am not sure why any of these would strictly need blockchain to solve the problem of safely storing data in a pool of untrusted, unreliable nodes.
Yeah, I wonder how their pricing compares to e.g. S3. The Filecoin website claims "hypercompetitive pricing" but does not actuall dress that to numbers: https://filecoin.io/store/#decentralize
It sure is a neat hack if they have changed to PoW to Proof-of-Storage, but whether is it actually usable for real-world applications of storing data at scale?
I think the point of a lot of blockchain tech is not to actually solve a real-world problem. For most of these problems you don't need blockchain or there is little extra value to be derived from blockchain.
Most of the time, the real-world problem solved by selling "something something blockchain" is that the person selling it needs to earn money somehow.
Honestly, if you pay me money for, I'd sell you "something something blockchain" if that's what you want me to do. Though shutting up about telling you my opinion ("fuck blockchain") will cost extra.
Practically that's impossible, since the network would need to swap the whole datastore once every payment cycle.
Say each block is stored on three nodes, then these nodes could each generate a nonce, compute a hash of the stored block (using all nonces as IV) and then vote on whether they still have the original file or not. This is much more feasible, as only nonces and hashes are transferred (a few dozen bytes instead of e.g. 64MB blocks). In that case they can store nothing and instead cooperate to generate spoofed hashes, so you probably want some auditor nodes.
I am not sure why any of these would strictly need blockchain to solve the problem of safely storing data in a pool of untrusted, unreliable nodes.