<aside> 📌 See the this in the FIP repo: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0059.md

</aside>

Simple Summary

This proposal presents a new PoRep protocol (Synthetic PoRep) that reduces the size of the temporary data stored between PreCommit and ProveCommit (150 epochs) from ~400GiB to ~25GiB, with no impact on security.

Abstract

Synthetic PoRep achieves reduction in used up space by reducing the set of challenges that might be chosen during the interactive Commit step from all possible challenges to some predetermined number that is feasible to precompute.

• A Storage Provider can complete the challenge generation and vanilla proof computation before performing PreCommit on-chain thus removing layers data before the sector is pre-committed on-chain;
• The GPU cost for SNARK generation during Commit is not significantly increased.

Motivation

The current interactive PoRep protocol (PreCommit + ProveCommit) requires to seal and keep a buffer of 12 layers (11 SDR layers + 1 data layer) between PreCommit and ProveCommit. This is the cost that we are targeting to reduce with this FIP.

Specification

Protocol Overview

Differences between currently deployed PoRep and Synthetic PoRep are limited to challenge generation and additional capabilities for the Storage Provider.

1. Starting point
   1. We assume there is a sector S for which the Storage Provider completed PreCommit1 and PreCommit2 computations.
   2. This sector is not listed on-chain.
   3. The Storage Provider possesses knowledge or CommR and CommD of that sector (acquired in PreCommit2 step) and the layers needed to generate CommR
2. Storage Provider generates “Synthetic” challenges from CommR
   1. Based on the CommR, the Storage Provider generates a list of N_synchallenges
   2. The Storage Provider computes responses for all the N_syn challenges, which take the form of N_syn vanilla proofs and saves them for future use.
3. Storage Provider can remove layers data
   1. As the Storage Provider knows responses to all possible challenges that will be asked in the interactive step, he can remove the layers data which is needed to respond to challenges.
4. Storage Provider publishes “PreCommitsSector”
   1. Using the same flow as today Storage Provider submits the sector for PreCommit.
   2. This establishes when in the future the randomness for interactive response will be known (PreCommitChallengeDelay)
5. Storage Provider generates and publishes ProveCommitSectors proof
   1. Storage Provider waits PreCommitChallengeDelay (150 epochs).
   2. The randomness revealed at PreCommitEpoch+PreCommitChallengeDelay selects N_verified challenges to be verified on-chain from the N_syn challenges generate in step 2.
   3. Storage Provider takes the N_verified vanilla proofs which were generated earlier corresponding to selected challenges and computes SNARK proofs of these challenges.
   4. Storage Provider publishes the ProveCommit either in individual or aggregated form.