Goal
The following projects are focused on improving storage operations (ie, onboarding CC sectors and storage deals, and sector maintenance). We want to assign priorities based on Storage Providers needs and pain points (ie, reduce costs).
First Group
- Synthetic PoRep
- NI-PoRep (with snarkpack)
- Note: Synthetic PoReP and NI-PoRep are “in competition” here (like choose one or the other to be shipped in 2023), indeed:
- If we ship NI-PoRep, then Synthetic PoRep will not make sense anymore;
- We can ship first Synthetic PoRep and later on change the protocol again to have NI-PoRep, but we believe this is not the best use of resources.
- Support Sealing as a Service (”CC sectors market”)
Second Group
- 1 WindowPoSt a day (”DailyPoSt”)
- CheapSnap (via mtree translation)
- ReSnap
🌐 Synthetic PoRep
Synthetic PoRep represents a way to lower down SP operational costs by avoiding the need of keeping a buffer of 12x sector size of layers data between PreCommit and ProveCommit phase.
Details in
❇️ Pros
- Solution “ready to be deployed” (99% research phase is done);
- SP stores much less (we expect ~ 6% of current buffer storage) between PreCommit and ProveCommit;
⚠️ Cons
- [minor] If at any point in the future, we are able to ship Non-Interactive PoRep, then this is not needed anymore and protocol will be reverted to current challenge sampling;
↔️ Dependencies
- None identified so far
🌐 Non Interactive PoRep (NI-PoRep)
Making PoRep fully non interactive. At high level, this means:
- No PreCommit method and message, only ProveCommit will stay (only one method and one message needed to add sectors the the network);
- No PCD (PreCommit Deposit)
- In general, no ad-hoc deposit will be required for the PoRep step (InitialPledge will remain);
- Increase by 8x the number of challenges (and therefore the SNARKs circuit size)
- Apply SnarkPack (to maintain the same on-chain footprint)
See overview in
❇️ Pros
- No major research needed;
- Merge PreCommit and ProveCommit in a unique step
- Simplifying the protocol
- Less operational cost for SPs (eg, no waiting time for the machines)
- Removing the cost of keeping a buffer of 12x sector size of layers for ~1.25h, or few hours if aggregation is used);
- Remove PreCommit Deposit;
- De-risking “sealing as a service”
- Note that this implies that it will be easier to allow for longer max sector duration. Today the max sector duration is bounded by the value used at PreCommit time.
⚠️ Cons
- SNARK circuit is 8x larger:
- That is larger proving cost (8.7x compared to today, before Supranational improvements)
- Same footprint (proof size)
- Slightely larger verification time, see more details here
- ❓ Does the cost of buffer storage compensate the additional proving cost?
↔️ Dependencies
- SnarkPack (already implemented and ready to use, no new trusted set is needed)
- [MAYBE] Testudo
- If the higher snark cost is not acceptable, future SNARK tools like Testudo can be used to bring the miner cost for generating the SNARKs down to ~2x current values. However currently (Jan 2023) Testudo shipping timeline is not clear.
🌐 Support “Sealing as a Service”
Sealing as a Service is the scenario where “Sealers” creates CC sectors and sell them to Storage Providers. The goal of this project is to make the necessary protocol changes to Filecoin to make this scenario
- Effective: for example both sealing steps (PreCommit and ProveCommit) are run by sealer;
- Low-risk/Low-trust: for example the sealer does not need to put down collateral that will be re-paid by buyers or buyer does not need to pre-pay this amount.
See
❇️ Pros
- New Functionalities/Opportunities for the Network;
⚠️ Cons
- [minor] protocol design/research phase still need to be complete (but confident that solutions exist);
↔️ Dependencies
- none identified so far;
Second Group
🌐 One WindowPost a day
Merging all the different WindowPost a SP has to provide throughout the day in a unique one, maybe using SnarkPack. See for example
❇️ Pros
- Unique “per SP” proof
- Easier schedule/Possible efficiency improvements on the SP side (to be better checked)
⚠️ Cons
- [minor] protocol design/research phase still need to be complete (but confident that solutions exist);
- Possibly additional proving cost (SnarkPack cost)
↔️ Dependencies
none (SnarkPack is already implemented)
🌐 CheapSnap
Currently SnapDeal protocol has a cost which is comparable with sealing a new sector. We think this is one of the main blockers towards massive adoption. The main reason is due to dealing w/ commD built with SHA (see and )
One way to address this issue is via Merkle Tree Translation proofs (see ‣ and
❇️ Pros
- SnapDeals would gain a significant advantage wrt sealing a new sector and could be used at full potential
- CC sectors could be filled with real data efficiently
- Data inside CC-born sectors can be changed efficiently
⚠️ Cons
- Unclear if the network is really willing to use SnapDeals massively
- We think so, given that the potential of efficient SnapDeals is underestimated (for instance, having efficient SnapDeals would allow for sector with FIL+ data to profit by the 10x multiplier for their entire lifecycle, and not only for the deal duration time window)
↔️ Dependencies
- none
❓ Open Points
- Overall agreement on SnapDeals willing to be the default option for having sectors with deals
- More research needed, at the current stage we only have an idea with no fully fledged details
- Full analysis of current idea needed
- Other possible protocol to explore to get the same result
- Assuming Testudo ships and gives us a significant improvement in proving cost, does this effort become lose impact?
- In our opinion no. The real metric here is the cost comparison with sealing a new sector and NOT the absolute cost. We work under the assumption that Snapdeal a CC sector putting inside data should be preferred to sealing a new sector
- Is the assumption above something we all agree on?
🌐 ReSnap
At the current stage, SnapDeal has been implemented only for filling a CC sector with data but not to allow for changing data in a SnapDealed sector (basically going back to CC and re-fill with new data). This would be the missing piece to give SnapDeal protocl the full functionality that was originally proposed
❇️ Pros
- It would bridge the gap between the original SnapDeal proposal and what got implemented
- It would give full flexibility in terms of data replacement into sectors
⚠️ Cons
↔️ Dependencies
- CheapSnap seems to be fundamental in order to have ReSnap to have considerable impact
❓ Open Points
- Before committing we should review the SnapDeals protocol and its costs in order to evaluate if ReSnap is actually a convenient option wrt sealing a new sector when willing to change the data inside a sector after deal expiration/termination (proof costs etc)
- Is ReSnap something that the Network would really benefit from/is actively waiting for?