nicola
commented
6 years ago - Direction 0: Mitigations
- Proposal 0: Change hard-coded VDF every month
- Proposal 1: VDFs that we use are memory-hard
- according to Ben they are difficult, require SNARKs and might be really expensive to prove. An idea would be to avoid using SNARKs (see PIE paper)
- Direction 1: Changing protocol (or security guarantees)
- Proposal 0: Make PoSt interactive (post on chain every proof)
- Proposal 1: No Storage based consensus
- if not -> no need for PoRep, no need for PoSt
- Proposal 2: Separating consensus from storage market (mild)
- PoSt is not needed for consensus but for storage market
- we can have different types of PoSt (interactive, sampling a set of users that do interactions, trusted hardware)
- consensus runs on Proof of Replication (as a Proof of Space), very similar to Spacemint
- Direction 2: Change trust assumptions
- Proposal 0: Challenge/Response happens without SNARKs with different trust assumption
- Instead of using SNARKs, let's use things like Refereed Multiprover, sampling a set of people running BA on whether or not a node replied correctly to the challenge -> what about economics?
- Proposal 1: sample a set users that run in an MPC a replica for the prover, with assumption that the prover will not be able to ask them to do that again
- prover sends file to oblivious network
- encoders receive the file (possible not knowing from who)
- encoders encode the file
- encoders run a MPC protocol for other encoders
- encoders for this file should only send the final output to the oblivious network (otherwie the prover can just re-simulate the steps and get a replica again!!)
- prover receives the encoded data
- why oblivious network? you could have the prover and the encoders colluding (unless assume the encoders are honest and never collude, good luck!)
bvohaska