FIP-0090: Non Interactive PoRep #891
Conversation
lucaniz
requested review from
momack2,
arajasek,
jennijuju,
kaitlin-beegle,
anorth,
raulk and
jsoares
as code owners
Co-authored-by: Jiaying Wang <[email protected]>
FIPS/fip-xxxx-ni-porep.md
Outdated
| A first step to mitigate the downsides of the waiting time was the introduction of Synthetic PoRep (See [FIP-0059](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0059.md)), which reduces the size of the temporary data stored between PreCommit and ProveCommit. | ||
| NI-PoRep is a further step forward, completely foregoing on-chain interaction (ie, the waiting time) and the need of PCD by allowing SP to locally generate challenges instead of using on-chain randomness. | ||
|
|
||
| NI-PoRep has little downside with respect to the status quo: it removes PreCommit at the cost of augmenting C2 (ie SNARK generation) costs, which would result in a limited cost increase looking at onboarding costs as a whole). Indeed, NI-PoRep requires 12.8x more PoRep Challenges, which translates into an 12.8x SNARK proving overhead. We analyzed how this SNARK computation overhead affects overall costs. The conclusion is that considering PC1+PC2+C1+C2 and storage costs (i.e. not considering maintenance costs), a NI-PoRep sector with 128 bits of security is 5% more expensive than an Interactive PoRep sector when sector duration is 3y. See full analysis [here](../resources/fip-xxx-niporep/NIPoRep_CostAnalysis.pdf). |
There was a problem hiding this comment.
Peer(can move to discussion, doesn't block draft): Why is the worst-case scenario for security modeled using sector duration 1.5 yr - which is the minimal sector duration atm?
There was a problem hiding this comment.
Actually, we are not analysing security here, but the cost overhead due to the new security params (ie, 12.8 x challenges).
But you are right that the cost difference between NI-PoRep and Interactive PoRep is maximum when sector duration is minimum.
I think it make sense con consider 3y as that is the most common duration we see in the network.
There was a problem hiding this comment.
is there a reason why you think 3yr can be considered as the most common duration we see in the network?
Most SP set sector duration according to deal durations and not majority of the data clients are making 3yr deals (data from early Feb)
There was a problem hiding this comment.
what's on the x axis here?
are you saying majority of deals have 25000 epochs (~9 days)? @jennijuju
For the analysis we need to consider the avarage lifetime of the sector (ie, initial commitment + all the extensions).
FIPS/fip-xxxx-ni-porep.md
Outdated
| NI-PoRep has little downside with respect to the status quo: it removes PreCommit at the cost of augmenting C2 (ie SNARK generation) costs, which would result in a limited cost increase looking at onboarding costs as a whole). Indeed, NI-PoRep requires 12.8x more PoRep Challenges, which translates into an 12.8x SNARK proving overhead. We analyzed how this SNARK computation overhead affects overall costs. The conclusion is that considering PC1+PC2+C1+C2 and storage costs (i.e. not considering maintenance costs), a NI-PoRep sector with 128 bits of security is 5% more expensive than an Interactive PoRep sector when sector duration is 3y. See full analysis [here](../resources/fip-xxx-niporep/NIPoRep_CostAnalysis.pdf). | ||
|
|
||
| The new onboarding method `ProveCommitSectorsNI` is restricted to CC-sectors. We decided for this design for the following reasons: | ||
| 1. We believe that the main users of NI-PoRep will be SaaS Providers, which will use NI-PoRep for CC sectors anyway. In the SaaS scenario, the flow where the SP ships the data over to an SaaS Provider and then gets back the sealed data (replica) seems more complex (and therefore more expensive in practice) than the flow where the SaaS Provider distributes CC sectors and then the SP can snap the data later. This should be especially true after [FIP0082](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0082.md) (SuperSnap) will be deployed in the network. |
There was a problem hiding this comment.
| 1. We believe that the main users of NI-PoRep will be SaaS Providers, which will use NI-PoRep for CC sectors anyway. In the SaaS scenario, the flow where the SP ships the data over to an SaaS Provider and then gets back the sealed data (replica) seems more complex (and therefore more expensive in practice) than the flow where the SaaS Provider distributes CC sectors and then the SP can snap the data later. This should be especially true after [FIP0082](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0082.md) (SuperSnap) will be deployed in the network. | |
| 1. We believe that the main users of NI-PoRep will be SaaS Providers, which will use NI-PoRep for CC sectors anyway. In the SaaS scenario, the flow where (1) the SP ships the data over to an SaaS Provider and then gets back the sealed data (replica) seems more complex (and therefore more expensive in practice) than the flow where the SaaS Provider distributes CC sectors and then the SP can snap the data later; (2) Data client can technically transfer the data directly to SaaS, however, requiring clients needs to find both trustworthy SaaS and SP adds on undesired overhead. This should be especially true after [FIP0082](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0082.md) (SuperSnap) will be deployed in the network. |
There was a problem hiding this comment.
an add-on based on my understanding - feel free to accept / modify / or reject
There was a problem hiding this comment.
is "data client" a common term?
I don't want to lead to confusion using it
Co-authored-by: Jiaying Wang <[email protected]>
|
Thank you @irenegia for addressing the feedbacks! This LGTM as the first Draft! Please update the fip doc with the fip number and add it to the readme before merging! |
done! |
|
|
||
| NI-PoRep will implement the batch balancer currently in place. See [FIP-0013](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0013.md) for details. | ||
|
|
||
|
|
There was a problem hiding this comment.
I think a new parameter value for this will need to be calculated, otherwise aggregated NI-PoRep proofs could end up too much more expensive than non-aggregated ones. Measuring this can be a TODO before last call.
|
Please add to README in this PR before merging. |
done |
This proposal presents a new PoRep protocol (Non-Interactive PoRep) that removes
PreCommitwhen onboarding CC sectors. As a result, we have:Discussion: #854
(PR description edited by @anorth)