@Luca @Irene @Nicola May 2023
Upgrading existing CC sectors appears to be one of the best opportunities for Filecoin Storage Providers (SPs): If Verifiable Deals and existing CC sectors are available, SPs may consider upgrading those sectors rather than sealing new ones in order to minimise new costs.
More in general, the difference in cost between upgrading a CC sector and adding a new deal native sector is small and should not prevent SPs to consider the upgrading strategy.
Outcomes may vary by SP, so we invite you to do your own research.
- The different storage pipelines which are available in the Filecoin Network today
- Models of the cost expected when using snapping versus not
In the Filecoin network, a Storage Provider (SP, for short) can seal two different types of sectors
- CC sectors: data set by default to zero
- Deal sectors: data obtained from storage clients
Thanks to FIP0019 (”SnapDeal”) and the introduction of the
ReplicaUpdate method, it is possible to inject data into CC sectors. This means that Storage Providers who want to store client data currently have two different options:
- Sealing a deal sector (ie, sealing a new sector with data from clients)
- Upgrading a CC-sector via SnapDeal to inject data from clients. We differentiate between
- Upgrading an existing CC sector
- Sealing a new CC sector and then immediately upgrading it (CC sector upgrade pipeline)
Our model aims to compare all the different strategies at Storage Providers' disposal to store client data.
Upgrading an existing CC sector Vs Deal Sector
➡️ Per our model, upgrading existing CC sectors appears to be one of the best opportunities for Filecoin Storage Providers.
Our model estimates the cost of upgrading an existing CC sector to be equivalent or even less than the cost of adding a new deal sector to the network (assuming no FIL leasing cost and not accounting for the past cost of sealing for the existing CC sector). Today (7th July 2023) the difference in cost is of 0.05$ per 32GiB sector (1.6$ per TiB). Since this is based off of dynamic calculations (especially gas price), the mileage may vary. Moreover, future protocol changes (see below) may increase this difference in favour of the upgrading CC sector pipeline.
CC Upgrade Pipeline Vs Deal Sectors
➡️ If no access to verified deals, starting with a CC sector and upgrading later also works.
Indeed, the difference between the CC sector upgrade pipeline and the deal native sector pipeline is NOT remarkable. And moreover, in our current modeling, we do not considering misc. costs such as electricity, bandwidth, labor costs, … We expect the real difference to be considerably closer, given that overall total cost difference will be minimal when introducing misc. costs.
Further Observation on Verified Deals Availability
🔍 If verifiable deals are available but there are no existing CC sectors available, the Storage Provider should consider sealing new sectors with verified deals.
📡 Future scenarios
Possible future changes on the CC-Sector Upgrade pipeline
💰Cheaper CC sector acquisition
Our modeling is considering sealing a CC sector and a deal sector to have the same cost. If we assume that acquiring a CC sector is cheaper than sealing a new deal sector, then the CC sector pipeline profit would be closer to (or even higher than) the one for deal sector. Factors that could make CC sector acquisition cheaper than sealing a new deal sector could include:
- SaaS pipeline/improvement focused on CC sectors
- Pre-sealed sector market
⛽ Different gas accounting for deal and sector (re)activation
One of the differences highlighted in the comparison between CC Sector Upgrade and Deal Sector is due to gas fees accounting. In particular, as of today (7th June 2023):
- Single sectors with deals do not pay sector activation and deal activation gas costs (which is subsidized by Cron).
- Sectors sealed through the CC sector pipeline pay sector reactivation and deal activation gas costs.
This fact represents a protocol quirk which prevents the two pipelines from be fairly compared. In the future, there might be changes in order to re-balance the gas accounting for deal activation. See for example, this discussion. In this case, we expect the cost of the CC sector upgrade and the deal sector pipelines to be closer.
✌️ Reducing SnapDeal costs
Another option to improve on CC Sector upgrade pipeline is reducing proving costs of the SnapDeal protocol. There have been some attempts to address this issue (see FIP discussions 645).
In our modeling, we look at the various strategies (i.e. pipelines) available for storing data in the Filecoin network. This modeling computes the estimated costs and rewards of each pipeline using basic SP resources as model inputs and relying on a few realistic assumptions.
- 32GiB sectors
- Deals with same size as sectors (ie, 32GiB). Note that this is coherent with the status quo (average verified deals size is ~30GiB, see related statistics in Starboard here).
- Verified deals only, assuming deals duration matching the remaining sector lifetime when they are activated (ie, a sector can be extended if needed).
The different pipelines any Storage Provider (SP) can choose in the Filecoin Network are described below:
🛑 Not Mining: SP not mining. Sectors are not sealed nor upgraded 🟪 CC Sector Only (cc pure): SP sealing CC sector only (no deals) 🔵 Deal sector (deal sector): SP sealing sectors natively with deals 🔶 Full CC-sector Upgrade (cc fil+): SP sealing new CC sectors and upgrading them via SnapDeal 🟨 Existing CC-sector Upgrade (cc existing fil+): SP upgrading existing CC sectors via SnapDeal
Maintenance cost for a 32 GiB sector from time t to time t’. This parameter is the sum of - WindowPoSt costs (proving and gas costs) - Operational costs (TBD)
Cost of 32GiB storage
We considered HDD Manufacture Deal of 18$ per TB
We assume storage costs are stable for a time window of 2 years and a redundancy factor of 1.25 per sector
Bandwidth cost for 32 GiB transfer
Currently non considered in the model
Lending cost of 1 $ for one day
This parameter is used in order to estimate capital cost of tokens lent to seal a deal sector at time t
Gas cost for a sector with deals (
Note that deal activation gas costs for deal native sectors are currently subsidized by cron. This may change soon.
Latency costs (includes idle time) related to data acquisition
Currently not considered in the model. This cost is the same for: - Deal Sector - Full CC Sector Upgrade - Existing CC Sector Upgrade
Lending interest rate
In the model, we allow for tunable lending interest rate.
Expected share of the block reward that a 32GiB sector with no deal gives in a day (computed at time t)
Sector lifetime in days
Waiting time (in days) for FIL+ deals to be available
Initial Pledge for CC sectors at time t
Initial Pledge for sectors with Verified Deals at time t
Cost of sealing a CC sector (PC1, i.e. labeling only)
This cost is currently the same as Cost_dseal but we keep them separate for full flexibility of the model
Cost of proving a CC sector (PC2 + C2)
This cost is currently the same as Cost_dproving but we keep them separate for full flexibility of the model
Gas cost for sealing CC sectors
Cost of sealing a sector with deals (PC1, i.e. labeling only)
0.114$ per sector (considering two CPUs and some RAM as HW)
This cost is currently the same as Cost_ccseal but we keep them separate for full flexibility of the model
Cost of proving a sector with deals (PC2 + C2)
estimated $0.2 per sector
This cost is currently the same as Cost_ccproving but we keep them separate for full flexibility of the model
Operational costs related to data acquisition
Currently not considered in the model. This cost is the same for - Deal Sector - Full CC Sector Upgrade - Existing CC Sector Upgrade
Gas cost for deal publishing (
This cost refers to the
Cost of embedding data when snapping
Currently not considered in the model. We expect this cost to be minimal.
Proving cost of the SnapDeal protocol (~ cost of C2 with the current SnapDeal protocol)
0.1$ per snap
Gas cost for a snapped sector
Note that while deal activation gas costs for deal native sectors are currently subsidized by cron, in case of SnapDeal gas activation, costs are charged with the
Cost of storing the old CC replica for 900 epochs before deletion after Snap is completed
Note that this cost is really minimal.
Pipelines are modeled in terms of Reward, Costs and Profit:
- Reward: 0
- Costs: 0
- Profit: 0
- Reward_ccpure: BR(t)*d
- Costs_ccpure: Cost_ccseal + Cost_ccproving + Cost_ccgas + Cost_B(t) + Cost_S + IP_cc(t)*Cost_T(t)*d + Cost_M(t, t+d)
- Profit_ccpure = Reward_ccpure - Costs_ccpure
A sector is created natively with deals:
- Reward_dealsector = 10*BR*(d-d0)
- Cost_dealsector = Cost_dataOp + Cost_dataLat + Cost_dealOp + Cost_dealLat + Cost_dealGas + Cost_dseal + Cost_dproving + Cost_dgas + Cost_B(t) + Cost_S + IP_filplus(t)*Cost_T(t)*d + Cost_M(t, t+d)
- Profit_dealsector = Reward_dealsector - Cost_dealsector
A CC sector is created and after d0 days it is snapped with data:
- Reward_ccfil+ = 10*BR*(d-d0) + BR*d0
- Cost_ccfil+ = Cost_ccseal + Cost_ccproving + Cost_ccgas + Cost_dataOp + Cost_dataLat + Cost_dealOp + Cost_dealLat + Cost_dealGas + Cost_snapembed + Cost_snapproving + Cost_snapgas + Cost_snapextra + Cost_B(t) + Cost_S + IP_cc(t)*Cost_T(t)*d + IP_filplus(t)*Cost_T(t)*(d-d0) + Cost_M(t, t+d)
- Profit_ccfil+ = Reward_ccfil+ - Cost_ccfil+
An existing CC sector is snapped with data at time t + d0 days:
- Reward_ccexistingfil+ = 10*BR*(d - d0)+BR*d0
- Cost_ccexistingfil+ = Cost_dataOp + Cost_dataLat + Cost_dealOp + Cost_dealLat + Cost_dealGas + Cost_snapembed + Cost_snapproving + Cost_snapgas + Cost_snapextra + Cost_B(t) + Cost_S + IP_filplus(t)*Cost_T(t)*(d-d0) + Cost_M(t, t+d)
- Profit_ccexistingfil+ = Reward_ccexistingfil+ - Cost_ccexistingfil+