FIP Discussion: Lightweight Sector Updates

[nicola]

Discussion issue for this FIP-0017

Since 90+% of sectors in the Filecoin Network are CC sectors, having a protocol that allows for updating CC sectors to store real data without incurring in a full re-sealing would massively improve our network in terms of the amount of real data stored through it.

1. It would allow decoupling sealing latency from deal-making speed - offering storage clients an improved experience for how quickly their data can land in on-chain deals
2. It would unlock the 8EiB of storage already committed to the Filecoin network to be quickly used for deals - enabling a 100PiB+ client to make deals for their entire dataset with a single miner like f0127595 which already has 120PiB of committed capacity.
3. It makes utilizing existing committed capacity much cheaper for miners (since they’ve already invested the sealing cost), increasing the chances they pay clients to add FIL+ data to these sectors.

[jennijuju]

FIP proposal see: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0017.md

[lucaniz]

Note on the current proposal
The current FIP proposal takes care of "native" CC sectors (i.e. sector which were created as CC ones).

Indeed, in order to perform an update we need SectorKey (that is, the last layer of the SDR graph).
In CC sectors, given SectorKey = Replica, we implicitly have SectorKey committed onchain (indeed Replica = SectorKey + Data, and Data =0 for CC sectors).

For sectors which are not natively CC (meaning, they were created with deals since the beginning) we do not have SectorKey committed onchain (since Replica is different from SectorKey here).

Feature Prioritization
Given the above note, we could have three different directions for sector updates

1. Make sector updates possible for natively CC sectors only (this was the original goal, allowing for the transition CC -> Sector with deals). Technically one could update non natively CC sector, but would need to have data of the first commit
2. Having an ad-hoc circuit for updating sectors which were not natively CC
3. Find a way to commit SecotrKey onchain as a intermediate step

Note that, unless there is a change of direction,

• point 1 is the current FIP
• points 2 and 3 should be considered as separate FIPs/future improvements on the current one

Timeline
Additionally, we should agree on a timeline for SectorUpdates to be shipped

cc @nicola

[ZenGround0]

The current plan is best. For the current state of the network feature (1) is by far the most useful. Data stored in deals is currently at ~22 PiB vs > 8 EiB of total data growing at > 40 PiB a day. In my opinion we should only work on (2) and (3) once network conditions have changed significantly.

[momack2]

Agreed - focusing this improvement on CCSectors only (not sectors with deals that have been added to the network already) is a reasonable simplification that brings 99% of the benefit of this change without creating more work. It makes the 8EiB of capacity already added to the network much more accessible for active deal-making, and the (relatively) small number of existing deal sectors will likely expire off the network in the next 6-12 months anyway (at which point they can be replaced with new updateable sector deals).

[ZenGround0]

Will the replica update proof take similar verification time to PoRep? From what we've learned over the past year we should enable batching wherever possible in miner proving methods. Unless proof verification is much less expensive I'm thinking it could be worth it to implement this with snark pack from the start.

[lucaniz]

We will need a circuit to check the replica update was done correctly. Verification should be the usual snark verification. I guess there is no reason for not using snarkpack (i guess you mean snarkpacking different replica update proofs together right?)

[TippyFlitsUK]

As a miner I am personally very excited about fip 0017 and think it will be a major improvement on the current CC upgrade pathway.

I am extremely motivated by the long term vision of the network and very much dislike sealing "junk" data in empty CC sectors. I know many MinerX fellows who feel the same way.

It is also very useful in managing sealing costs by creating CC sectors when the base fee is low and then using the upgrade feature exclusively to seal new deal sectors in the empty CC's. The new batching feature has also really helped with this in conjunction with the upgrade feature.

Whilst the current CC upgrade pathway works it is not particularly user friendly. The UX is confusing when it comes to displaying the correct upgrade status and the upgrades do not persist across miner restarts. As MinerX fellows we restart A LOT!! I currently use an Excel spreadsheet to manage my upgrades so the bulk of my planning is done outside of Lotus.

The new lightweight CC upgrades would hopefully eliminate most of the current issues whilst using some of the existing network capacity to store real data which is ultimately the goal of many of us here.

https://filecoinproject.slack.com/archives/C022ZR4JA1M/p1628265181186200

[TippyFlitsUK]

I would very much like to see non CC sectors that already contain deals included in this FIP.

The flow of deal proposals can be extremely sporadic and as a result there are many occasions when miners are forced to seal almost empty sectors due to time limiting factors such as deal start epoch and PC1 ticket expiry. We therefore end up with multiple 32GiB/64GiB that contain very small individual deals and a large quantity of wasted space. I personally have many sectors that only contain one single 256MiB deal.

I believe that the deal flow will continue to be sporadic going forward and that the time limiting factors will remain in place. I would therefore sincerely welcome this addition.

Many thanks!!

[lucaniz]

The reason for which we do not address sectors that are not natively CC is purely technical: as you can see, one need to have the last layer of the SDR graph in order to perform the data retireval (SectorKey in the FIP proposal).
Given the way CC sectors are created, we have that replica is essentally the same as SectorKey so it is possble to retrieve data easily, recomputing SectorKey on the spot when needed.
If you want to do the same with a sector that is not natively CC, here you have an issue: SectorKey and Replica are now different, and not only that: SectorKey is not committed onchain.
In order to retrieve data from a non-natively CC updated sector you need to have its SectorKey, which means that either you keep a copy of the old data around, or you keep the old replica around which of course is not ideal.

This was in essence the motivation to my first comment above.

In the future, we'll explore the possibility of updating non natively CC sectors as well.

[kaitlin-beegle]

This proposal (and associated FIP-0017 draft) will soon be deferred. The upcoming FIP-0019 will provide a better solution to the problem of CC re-sealing times.

For more information, or to contribute to this topic, please see #145