Hacker News new | ask | show | jobs
by whyrusleeping 2683 days ago
The proof of replication provides assurance that for some given data D, a unique replica R is created for it. What you’re proving with the Proof of SpaceTime isn’t that you have some data, you’re proving that you have the replicas. Generating the replica is slow, so you can’t do it on the fly. I gave a talk recently that goes over some of this briefly: https://youtu.be/GZZ2G9bPXsM
2 comments

Thanks for linking your talk! Just started watching it now. Is that Dan Boneh in the front?
Yep! He gave the talk just before me
you talk for 15s about it on that video. I will try to read the secondary paper on this... but doesn't look like it can protect against someone just generating hashes for multiple accounts from the same stored data.

P and (the fake) P2 can both reply to V with perfectly normalized storage.

But regardless if the protection works against bad actors, it definitely "works" against good actors if you take into account storage prices. E.g. P1 and P2 are two distinct good actors. They both pay cloudProviderA for storage. P1 and P2 bid on the same filecoin storage contract. They store that independently of each other, but cloudProviderA normalize the storage (with their own backup and consistency solutions). But with this protection scheme, since the cloud provider can't normalize, the cost will eventually go up because their normalization margin got erased. Over time, the data storage cost for good actors will go up, while for bad actors (assuming they are possible) the profit will increase.

To generate a response to the verifier, you have to have your replica of the data in question. A replica (from proof of replication) is a unique encoding of the data that is quite slow to generate. If the prover isn't storing the replica, they will have to regenerate it before they can respond to the challenge, which takes a noticeable amount of time.
What scale is "noticeable"? Is it slower than "we're going to pretend the network is slow and send you 1KB/s until we generate the rest"?
I wouldn't be surprised if regenerating it a few times is more expensive than simply storing it once.
1kb is much larger than most hashes.
I'm not sure what you're trying to say by that.
I'm saying that strategies like that won't work when the data required fits into a single packet.
Take a read through Ben's PoRep paper: https://eprint.iacr.org/2018/702
Thanks, I'll take a look.