Filecoin
Mecanismo de Proof-of-Spacetime
Context
Figure 3 appears in Section 3.4.4 (Practical PoSt construction) as an illustration of the internal mechanism of the PoSt.Prove algorithm. It directly precedes Section 3.5 (Usage in Filecoin) and provides a visual explanation of how sequential proof composition achieves time-based storage verification. The caption reads 'Illustration of the underlying mechanism of PoSt.Prove showing the iterative proof to demonstrate storage over time.'
What This Figure Shows
The figure depicts a loop that iterates t times, representing the time parameter in PoSt.Prove. At each iteration, the prover starts from a Merkle Tree root (rt) of the stored replica, generates a new challenge by hashing the previous PoSt output concatenated with the current challenge and loop counter, runs PoRep.Prove to produce a Proof-of-Storage, then uses SCIP.Prove to recursively compose this into a new PoSt proof. The SEAL key is shown as a parameter influencing the Merkle Tree construction. The output is a final compressed PoSt proof that encodes the entire chain of sequential PoRep executions. Data flows from the Merkle Tree through hash functions into each iteration's proof generation.
Significance
This figure explains the core technical mechanism that prevents storage providers from retroactively generating fake proofs: because each iteration's challenge depends on the output of the previous proof, the sequence cannot be parallelized or precomputed. The sequential nature of PoSt.Prove is what ties proof generation to actual elapsed time, enabling the network to verify continuous data storage without requiring constant real-time interaction.
