You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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?)
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)?
No trusted setup: Are there practical constructions for PoSt that do not require trusted setup?
No arithmetic circuits: Are there Proof-of-Spacetime implementations (that use Proof-of-Replication) that do not require using general-purpose verifiable computation?
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)
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:
O(t)?
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
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
Useful Readings
The text was updated successfully, but these errors were encountered: