A new proof type which removes on-chain interaction simplifying the whole sealing pipeline and allowing for a real separation between storage and proving, without compromising security.
Quick Links
📊 Motivation
PoRep is currently interactive and it is composed by two steps: PreCommit and ProveCommit.
At PreCommit SP put down a collateral and wait 150 epochs in order to receive a challenge seed from the chain which enables the ProveCommit step. This means that
- Mining pipeline is not flexible. In order to add a sector to the network, that sector needs to be first precommited and
ProveCommitneeds to happen within a time window lastingMaxSectorDurationepochs. - Given
PreCommitneeds a collateral, there is no real possible trustless separation between the entity which stores the sector and the entity which actually proves it. This means that if anyone wants to outsource the task of proving a sector, then the entity which proves and the entity which outsource the task need to agree on who puts down the collateral (trusting the other part).
A first step to mitigate PoRep bottlenecks was the introduction of Synthetic PoRep. Nevertheless, if we really want to remove the aforementioned limitations, NI-PoRep is the way to go: indeed,
non interactive PoRep would remove the PreCommit step, without compromising security, allowing for a simplified pipeline which can reduce costs and enable a full separation between storage and proving. Note that this is particularly relevant now that we have SaaS and SN sealing software (see below).
🗺️ How to get there
There are two ways we can get NI-PoRep
🟢 Pros:
- No new trusted setup needed ⇒ Fastest way to ship NI-PoRep
⚠️ Cons:
- We have a linear blowup in public inputs which could result in 8x on-chain footprint
- A way to de-risk input blowup effects is needed
🟢 Pros:
- We can try to use recursion to prevent input blowup effects
⚠️ Cons:
- New trusted setup needed
- More engineering work to build and audit the new circuits
as a result, this approach would require much more time to ship
In this doc, we assume to re-use existing circuits.
🚀 Impact on Filecoin
Why NI-PoRep in Filecoin?
Improvements of NI-PoRep vs status quo
- Removing interaction translates into a simplified pipeline
- No
PreCommitmethod and message, onlyProveCommitwill stay (only one method and one message needed to add sectors to the network); - No
PCD(PreCommit Deposit) - In general, no ad-hoc deposit will be required for the PoRep step (
InitialPledgewill remain); - No waiting time between
PreCommitandProveCommit - Removing interaction translates into much more flexible pipeline
- Sectors can se sealed and proved in a flexible way
- SP can prove how many sector they want, whenever they are ready to do so
- No fixed schedule to add sectors to the network
- SP can follow their own sealing schedule according to their setup and prove sectors on-chain when ready
⇒ SN Improvements at full potential
- Simplification of the pipeline and more flexible
ProveCommitStep (i.e. “prove when you are ready”) would allow for maximizing sealing throughput
- Removal of
PCDallows for Proving and Storing to be now decoupled - SaaS would be possible in a trustless manner (low risk-low trust: sealer does not need to put down collateral that will need to be re-paid by buyers or buyer does not need to pre-pay this amount)
- SaaS providers can delegate proving tasks. In particular, proving can be split into specialized subtasks which get outsourced to specialized entities (labeling the graph, Snarks, …)
- Enabling HDD wholesale: it would be possible to receive brand new drives with Sector-Keys pre-generated in your name
- Chain cryptographic security gets increased: NI-PoRep would make misbehaving cryptographically infeasible rather than irrational
- We can get more flexible/longer sector extensions. Nevertheless, we need to determine a good trade off.
- It is true that as long as cryptographic assumption holds, PoRep is cryptographically secure, so in principle we could extend sectors lifetime for very long time window
- On the other hand, it would not be a safe move to have sectors with a too long lifetime (like 10y) since technology advancement could make assumption which are currently solid to get weaken in such a long time window
- Current PoRep is interactive and needs to get randomness form the chain. Moreover, in order to be secure, 150 epochs are needed between
PreCommitandProveCommit. This is due to the fact that some Consensus attacks need to be infeasible (as putting those attacks in place would allow for faking storage). In NI-PoRep, since randomness is derived locally, there is no link anymore between PoRep and consensus attacks. This mean that - Consensus attacks are not a concern anymore for PoRep security
- PoRep can now work “agnostically” with any consensus mechanism
- L2 Filecoin protocol can use NI-PoRep independently from consensus
- Can we enable other protocol to check in with Filecoin now?000
- NI-PoRep would be a separate proof type with a different on-chain flow as current PoRep
- No need for a new trusted setup
🔥 Current Risks
- Per sector resulting gas costs are likely to be higher than today (more inputs, more challenges, more snarks needed).
- We know what worst case is (8.7x, resulting in 1/9 of the sectors proven per block compared with today)
- We need to understand what are the real costs and eventually optimize for those
- In order to preserve security NI-PoRep needs 8x challenges and a massive usage of Snarkpack. This translates to a ~8.7x proving overhead compared to today. Verification cost and proof size would be comparable to today.
Possible mitigations
- SN improvements on
C2seem to get a 10x cost savings wrt today.If this is the case, we’d have NI-PoRep to have a similar cost cost as current PoRep (it would actually be a bit cheaper) - We know there is a market of Ethereum miners providing snark computation at competitive price (some entities in the community are already profiting by this fact).
- If
BatchBalancerapplies to the proof aggregation within the same sector (as we’d to with NI-PoRep), then NI-PoRep gas cost per sector would be 10x the current one - We need to be sure batch balancer only depends on the total number of different sectors and not on the number of aggregated proofs
- Current PoRep comes with a set of parameters which with NI-Porep would become
- Unnecessary, like
MaxSectorDuration - Difficult to validate, like
SectorRandomness, which anchors the sector with consensus - We can guarantee the same functionalities we have today
- We make the adjustment which are needed in order for NI-PoRep to work properly
Given those parameters are used and checked in the protocol, we need to be sure that
🥜 NI PoRep Protocol in a nutshell
NI-PoRep protocol can be summarized as follows:
Graph Labelling and commitments (similar to the current PC1 and PC2 computation)
- Using
ReplicaID(which containsCommD), SP computes the labels for all layers and the replica R; - SP compute the column commitments
CommC,CommRLastand finally computesCommR=Poseidon_2(CommC, CommRLast);
Storage Provider locally generates NI_ChallengesNumber challenges and vanilla proofs;
- Each challenge is of the form
ch_i = H(prefix, commR, tag, i); - SP computes responses for all the
NI_ChallengesNumberchallenges, which result inNI_ChallengesNumbervanilla proofs;
Storage Provider publishes the new NI_ProveCommitSector proof
- SP takes the
NI_ChallengesNumbervanilla proofs and computes the corresponding SNARK proofs for these challenges. - SP publishes the snark and commitment
CommR(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
CommRas a seed, the chain generatesNI_ChallengesNumberchallenges and this are fed into proof verification
🛑 NI-PoRep 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 at least 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 = 1408.
🔀 Which Proof System for NI-PoRep? Groth16 Vs Nova
Dealing with NI-PoRep Challenges using Groth16
Using Groth16 to prove NI-PoRep’s 1408 challenges requires generating 79 Groth16 PoRep proofs; each proof having 18 public inputs dedicated to challenges (resulting in a 1422 total challenge public inputs per NI-PoRep). Using SnarkPack, these 79 proofs can be aggregated into a single proof (see a more detailed analysis in
Dealing with NI-PoRep Challenges using Nova
Using Nova to prove NI-PoRep would produce a single Nova proof per NI-PoRep (this proof may or may not be smaller than 79 Groth16 proofs, but not smaller than a single SnarkPack proof) and would require the generation of slightly fewer challenge public inputs (1408, versus Groth16’s 1422) by the verifier. Because Nova does not require a trusted setup, the PoRep circuit can be augmented to include in-circuit challenge generation, thus reducing the out-of-circuit challenge generation work performed by the verifier.
If challenges are computed in-circuit using a circuit-friendly hash function (e.g. Poseidon), the increase in Nova’s proving/verifying time would be marginal (according to FilCrypto Intuition) and would remove almost all challenge public inputs (the tag and challenge_index used in NI-PoRep challenge generation may each require a public input, thus reducing the number of challenge public inputs from 1408 to 2).
Nova Pros and Cons
Nova proving is faster than the current (i.e. non-SupraSeal) Groth16, whereas its verification time is slower than both Groth16 and SnarkPack (however verifying a single Nova proof may be on-par with, or faster than, verifying 79 Groth16 proofs). Nova’s proving time versus SupraSeal has yet to be benchmarked.
A drawback to Nova is that it uses different curve groups and fields than Groth16, thus any sector sealed using Nova NI-PoRep would require also using Nova for PoSt.
🎯 Workplan (TBD)
📈 Progress so far
👥 People
- Research:
- Luca
- TBD
- Engineering:
- FilCrypto
- PM
- Jennifer (?)