FIP-00XX (NI-PoRep)

Authors

Irene

Luca

Creator

Luca

Created

Feb 8, 2023 11:28 AM

Project

Storage on-boarding

Stage

Still Valid

⚠️

Status: wip

Simple Summary

Non Interactive PoRep (NI-PoRep) protocol merges PreCommit and ProveCommit in a unique step simplyfying the PoRep pipeline, eliminating thew wait (150 epochs) between PreCommit and storage overhead. NI-PoRep has no impact on security, at the cost of ~ 8x proving overhead.

Abstract

NI-PoRep removes the need to submit PreCommit and allows to have a unique message for proving new sectors (eg, only a message similar to the current ProveCommit is needed). Challenge generation happens locally and thus there is no need of having PreCommit messages on chain. Notably, the removal of PreCommit would also remove the need for the PreCommitDeposit and for keeping around extra data for the time from PreCommit to ProveCommit.

Motivation

TODO Draft:

NI-PoRep would be highly beneficial in terms of improving porep pipeline, easing the birth of a Sealing as a Service market which could be decentralized without need of trust between Sealing as a Service Provider and Client (No need of a PreCommit step translates into no need of PreCommit deposit, which would ease CC sector sealing outsourcing).

Specification

High Level Protocol Flow - wip

The protocol can be summarized as follows:

Graph Labelling and commitments (similar to the current preCommit1 and preCommit2 computation)

Using CommD, the SP computes a the labels for all layers and the replica R;
The SP computes the column commitments, CommC , CommR and finally computes CommCR=Poseidon_2(CommC, CommR);

Storage Provider locally generates NI_ChallengesNumber challenges and vanilla proofs;

ch_i = H(commCR, tag, i);

TODO (@irene, @luca) : check if we need to include commD here

The SP computes responses for all the NI_ChallengesNumber challenges, which take the form of NI_ChallengesNumber vanilla proofs;

Storage Provider publishes the new NI_ProveCommitSector proof

The SP takes the NI_ChallengesNumber vanilla proofs and computes the corresponding SNARK proofs for these challenges.
The SP publishes the snark and commitment CommCR (either in individual or aggregated form).

Note in this step the SP will, by default, use the SnarkPack aggregation technique to prove even only one sector (see “product considerations” section for the motivation).

Chain verifies proof

Using CommCR as a seed, the chain generates NI_ChallengesNumber challenges and this are fed into proof verification.

Rationale

TODO

The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.

Backwards Compatibility

NI-PoRep would be a separate proof type with a different on-chain flow as current PoRep. It would not require a new trusted setup.

Test Cases

Will be included with implementation to be presented.

Security Considerations

NI-PoRep is based on the well-known Fiat-Shamir Heuristic, which allows for having a non interactive protocol starting from any 3-message interactive protocol. However, the heuristic requires the interactive protocol to have 80 bits of security (instead of the current 10). This means that for NI-PoRep we need 8x challenges compared to the current interactive PoRep protocol to ensure no loss in security with respect to the status quo. Therefore NI_ChallengesNumber= 1760.

Product Considerations

The increased number of challenges brings over an additional proving overhead, which we partially (on chain footprint and verification) mitigate using SnarkPack. From the SnarkPack paper, we can estimate that SnarkPack proof size amortization will kick in when sealing at least 2 sectors. While, in terms of the verification even one NI-PoRep already benefits from SnarkPack (note that the more sector you seal at a time, the better the amortization becomes). With respect to the status quo, the new costs will be:

Proving cost:

8x snark cost compared with today (80 groth16 snarks instead of 10)
SnarkPack aggregation cost: this cost is logarithmic, so log(80) ~ 6.7

⇒ Total proving overhead: 8.7x

Verification cost: it is the SnarkPack cost (counting each NI-PoRep sector as 8 sectors with the current proof system), comparable to aggregatedproveCommit today.
Proof size: comparable to today.

From the paper: breakeven at ~130 proofs (23Kb for SnarkPack proof Vs 24kb for 130 Groth 16 proofs). It follows that this approach starts being meaningful regarding proof size when sealing 2 sectors together (Single Groth 16 proof is ~0.2Kb)

Incentive Considerations

We think that this proposal does not affect the current incentive system of the Filecoin network.

Implementations