Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Novel constructions for Proof-of-Spacetime #5

Closed
nicola opened this issue Mar 29, 2018 · 1 comment
Closed

Novel constructions for Proof-of-Spacetime #5

nicola opened this issue Mar 29, 2018 · 1 comment

Comments

@nicola
Copy link

nicola commented Mar 29, 2018

Work in Progress: This is a work in progress. For comments and suggestions contact us at research@protocol.ai

We as Protocol Labs actively support these areas of research with grants, bounties and direct collaborations. We plan to fund research related to these open problems. Reach out if you want to work on or are working on these problems.


Proof-of-Spacetime

In Filecoin, storage providers must generate valid Proofs-of-Storage with specific properties (see Proof-of-Replication) to get rewarded for storing data.

Each Proof-of-Replication shows that a replica was stored around the time of a challenge. This means that proving that a file was stored for a duration of time requires multiple rounds of interaction. Instead, we proposed a new proof scheme, Proof-of-Spacetime, where the storage provider can generate a set of Proofs-of-Storage non-interactively and only post a final proof which guarantees that the file was stored all along.

Problem Definition

A Proof-of-Spacetime (PoSt) is a protocol between a storage provider and a verifier, where the storage provider must convince the verifier that they have stored a specific file for a specific amount of time.

Intuition

A client wants to make sure that the storage provider has been storing a file D throughout some time t. Using classic Proof-of-Retrievability/Proof-of-Data-Possession schemes, a client would have to check that a file has been stored throughout time by issuing challenges throughout t. Naively, a client can choose a security parameter λ and issue a challenges λ for each unit of time, making the number of interactions (the number of challenges issued) O(t), and the total communication complexity (the size of all the data received by the verifier) O(pt), where p is the size of a single Proof-of-Storage.

The requirements solved by a practical Proof-of-Spacetime are:

  • Question 1: How do we construct a scheme where the number of interactions is less than
    O(t)?
  • Question 2: How do we construct a scheme where the total communication complexity is less than O(pt)?

Candidate constructions

Naive construction: On receiving a challenge, the provider generates a Proof-of-Storage and uses the output of the proof (assuming Random Oracle) as the challenge to the next Proof-of-Storage. The provider will repeat this step t times. The concatenation of all the proofs will be the proof sent to the verifier, which can verify: (1) the correctness of the individual proofs and (2) the correctness of the concatenation. This scheme has O(1) interactions, however, total communication complexity is O(pt).

Incrementally Verifiable Computation: On receiving a challenge, the provider runs the naive construction, but at the completion of every Proof-of-Storage, it uses incrementally verifiable computation to prove that the proof was generated correctly and it used the output of a previous proof. This scheme has interactions O(1) and total communication complexity O(1) (depending on the scheme). A problem of these schemes is that achieving incrementally verifiable computation using schemes such as SNARKs, add a substantial overhead to the generation of the proof.

Batching Verifiable Computation: On receiving a challenge, the provider runs the naive construction; once completed, it runs the verifier algorithm (verifying correctness of individual proofs and correctness of the concatenation). This scheme has interactions and total communication complexity. This scheme has interactions O(1) and total communication complexity O(1) (depending on the scheme, this may involve SNARKs).

Desirable properties

  • Transparency: There is no such extra information (or trapdoor) that a prover can use to generate valid PoSt proofs without storing data through time.
  • Short Verification Time: The verification time is short if it is constant in the security parameter O(λ), for a small constant, or sublinear in the size of the data. (Note: For a reasonable data size, e.g. 10GB, a constant verification might concretely take longer than a sublinear verification)
  • Short Proofs: The proofs are short if they are constant in the security parameter O(λ), for a small constant, or sublinear in the size of the data (Note: For a reasonable data size, e.g. 10GB, a constant proof size might be concretely larger than a sublinear proof size)
  • Concrete Practical Proving Overhead: The overhead memory and computation time to generate a proof should be practical (e.g. can be executed for large files on commodity hardware) without compromising security.
  • Sequential Proof Generation: The duration for generating a Proof-of-Spacetime is dominated by the sequential (non-parallelizable) composition of the underlying Proof-of-Storage.

Open Problems

While there are some candidate constructions of the Proof-of-Spacetime, there are still improvements for making such constructions more practical (faster proving time) or with weaker cryptographic assumptions. An ideal PoSt construction should have as many of the following properties as possible.

Concrete Open Problems

  1. New Proof-of-Spacetime constructions: Are there constructions of a transparent PoSt with fast verification time, small proving computation/memory overhead, and short proofs? (Alternatively, are there radically different constructions that achieve the same goals?)
  2. Optimization for repeated computation: The Proof-of-Spacetime requires proving knowledge of a sequence of Proofs-of-Storage. Are there ways to exploit repetition to achieve more practical constructions (e.g. Hyrax)?
  3. No trusted setup: Are there practical constructions for PoSt that do not require trusted setup?
  4. No arithmetic circuits: Are there Proof-of-Spacetime implementations (that use Proof-of-Replication) that do not require using general-purpose verifiable computation?
  5. Optimized arithmetic circuits: Are there optimizations (e.g. more SNARK-friendly primitives) for Proof-of-Spacetime circuits that use Proof-of-Replication? (see current Proof-of-Replication construction or contact us for more information)

Useful Readings

  • Filecoin Whitepaper (paper)
  • Proof of Replication (paper)
  • Filecoin Proof of Replication motivation (video)
  • Proof of Replication Construction (video, slides)
@nicola nicola changed the title Improved Proof-of-Spacetime Novel constructions for Proof-of-Spacetime Mar 29, 2018
@miyazono miyazono added the open RFP see https://github.com/protocol/research-rfps label May 22, 2018
@miyazono miyazono removed the open RFP see https://github.com/protocol/research-rfps label Jul 9, 2018
@jpeg07
Copy link
Contributor

jpeg07 commented Jan 28, 2022

Closing issue. Current discussions better routed to https://github.com/protocol/cryptonetlab

@jpeg07 jpeg07 closed this as completed Jan 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants