New Proof of Space Construction Idea
Understanding how to use the overhead in Vector Commitments (VC)
(1) VC PoS:
New proposition for PoS based on pairing-based VC where the replica is the precomputed proofs of openings
Requirements:
- space: proofs of openings cannot be compressed - the storage required for them = storage of the full initial vector
- time/cost: proof of openings are costly to generate - a prover needs to process all vector to generate one proof
(2) DRG PoS:
Current construction:
- first Data is sealed into Replica
- then use a VC scheme (Merkle Tree) to commit and open in the online phase
Requirements:
- trade-offs: we need space/time tradeoffs for the prover in the online phase
- space: if we precompute and store proofs of openings - they should be compressible
- time/cost: if we compute proofs on the spot online: proof of openings should be efficient to generate
The two words, when based on same VC construction, are complementary: (1) VC PoS and (2) DRG PoS and realising one securely implies the other construction is inefficient:
No (1) implies (2)
No (2) implies (1)
- they are mutually exclusive, so if we show (1) is not possible, then this shows (2) is possible
- we need to understand in which one we are in order to use new VC for PoS
- analysing the proposition and finding ways to compress the replica or to efficiently compute the replica will lead us to an answer either showing (1) is feasible or (2) is possible for the design we have today
Other PoS exploration based on new VC for Replication
- Specific to PoRep optimisations and preprocessing:
- if we consider the replication protocol based on graphs as we use today, what kind of reorganisation (parents-children nodes wise) can we do to the graph
- consider pairing-based VC: how can we exploit the graph structure in order to open and check relations between nodes efficiently?