@Kubuxu @Luca @Anonymous @Nicola

Problem space

Mining Experience: with the current interactive PoRep protocol (PreCommit + ProveCommit) SPs need to keep a buffer of 10 layers between PreCommit and ProveCommit. Here we aim to remove this need. We identify two different directions:

  1. Make PoRep non-interactive: this would remove the need to submit PreCommit and would allow to have a unique message for proving new sectors (only ProveCommit would be needed). Moreover, the removal of PreCommit would also remove the need for keeping around 11 layers for the window of time that starts at PreCommit and lasts until PreCommit.
  2. Make PoRep Synthetic: Non interactively generate challenges for 80 bits of security, commit to them, and later on, interactively, show a subset of them keeping around vanilla proofs only (aka: merkle tree paths), in order to get $2^{-10}$ soundness without need of keeping the whole graph.

Non Interactive PoRep: Merging PreCommit and ProveCommit in a unique step via Fiat Shamir Transformation

The aim of this line of work is to get rid of the need of both pre-commit and prove-commit merging the two steps into a unique one.

Having such an improvement is important (at least) under two different points of view

  1. Mining Experience: adding sectors to the network results in a lighter process
  2. Exponential Network Growth: having a non-interactive PoRep mechanism would be beneficial for network onboarding.

Why do we currently need interactive PoRep?

Currently, PoRep phase has 10 bits of security. This means that a malicious adversary can cheat a PoRep on a sector with probability lower or equal than $2^{-10}$.

This is due to the fact that proving PoRep in a Snark is expensive: achieving 10 bits of security translates in 10 snarks proofs per PoRep per sector, which at the moments needs go onchain. We could get around onchain footprint using SnarkPack but we would still have a considerable proving overhead.

In practice, 10 bits of security are not enough to use Fiat-Shamir heuristic and make PoRep non interactive. Indeed, roughly speaking a non interactive PoRep would work as follows:

  1. SP computes a Replica R
  2. SP uses CommR to locally generate a seed via an hash function
  3. SP uses the seed to compute challenges over which he has to produce a proof that is posted onchain