@Kubuxu @Luca @ @Nicola

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:

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

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:

Since the challenge generation procedure is done locally, a malicious miner could cheat trying different seeds (and so grinding on different sets of challenges) until he finds a set of challenges he can answer.

Having 10 bits of security means that, on expectation, a cheating  adversary could misbehave during PoRep generation (for example by introducing more incorrect labels than he is allowed to) and find such a set of challenges in $2^{10}$  (~1000) attempts.

Note that this is particularly bad in our case since

The theoretical recommendation for using Fiat-Shamir heuristic is at least 80 bits of security (or even 128), which translates to 8x the number of challenges we have today per PoRep (1408 per layer instead of the current 176), resulting in 8x the number of snarks per PoRep. These numbers are impractical at the moment given the current snarks due to proving overhead.

One way to possibly overcome the need of 80 bits of security could be to rely on rationality: we could find a tradeoff between minimal cost of the number of attempts the adversary is required to perform in order to cheat with probability 1 (on expectation) and the reward they are earning during the sector lifetime. Ideally, is the two amounts are close (or equal) not cheating would not be a rational strategy for the miner.

On this front, the good thing is that we already use a rational model for WindowPoSt. Moreover, properly modeling such an idea for the FIat Shamir Heuristic could potentially be an interesting research result (in the framework of the so-called rational proofs).

On the other hand, this analysis would require significant effort, and there are uncertainties (for instance, costs are in $ while rewards are in FIL, which make the comparison not straightforward without making any price prediction/setting some lower bound on the value of FIL).

For all these reasons, at the moment this is not the main option

We could stick to the theoretical requirements for Fiat- Shamir Heuristic and heavily use SnarkPack in order to aggregate proofs. This would give us a reduced onchain footprint with a logarithmic overhead for the verification, which is acceptable. Nevertheless, proving overhead would be still considerable (8x what we have today)

Synthetic PoRep aims mitigate the need of keeping around a whole graph between PreCommit and ProveCommit by relying on a first non interactive step of challenge generation combined with an interactive step of partial challenge check.

Even if this approach is keeping some interaction, it improves the current state of things under multiple points of view:

The biggest benefit of NI PoRep comes from non-interactive challenge generation, its biggest drawback comes from how numerous these challenges have to be to perform non-interactive verification.

Proposed below protocol reintroduces interactivity to the PoRep protocol but keeps challenge generation non-interactive.

This allows us to keep the benefit of miners being able to discard layers data (12x sector size) before interacting with the chain, while at the same time not increasing the GPU cost of sealing, which is significantly increased in NI Fiat Shamir PoRep. The drawback in comparison to fully NI PoRep is that the interactive step still exists on chain but it is not worse in comparison to today.

The protocol works as follows:

The number of verified challenges, V, can be much lower than the overall number of challenges, N, as the miner has to cheat C challenges, which ends up being the majority of N challenges, such that when selecting V challenges at random, only cheated challenges are selected.

The details of the Synthetic PoRep Protocol Description can be found in here. Moreover, a discussion can be found on Github here