![[2023Q2] CC Sector Upgrade: Guidelines and Modeling](https://images.spr.so/cdn-cgi/imagedelivery/j42No7y-dcokJuNgXeA0ig/921ad9ba-42ae-4205-8aa3-5f8db1ebe5c5/porte-garage/w=3840,quality=80)
@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.
🥁 Context
- 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.
🚀 Outcomes
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).
📐 Modeling
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.
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).
Definitions
Pipelines
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
Parameters
Cost_M(t, t’) | 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_S | 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 |
Cost_B | Bandwidth cost for 32 GiB transfer | — | Currently non considered in the model |
Cost_L(lendingR) | 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 |
Cost_dgas | Gas cost for a sector with deals ( PublishStorageDeals message) | Note that deal activation gas costs for deal native sectors are currently subsidized by cron. This may change soon. | |
Cost_dataLat | 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 |
lendingR | Lending interest rate | — | In the model, we allow for tunable lending interest rate. |
Name | Description | Source | Comment |
BR(t) | Expected share of the block reward that a 32GiB sector with no deal gives in a day (computed at time t) | ||
d | Sector lifetime in days | — | |
d0 | Waiting time (in days) for FIL+ deals to be available | — | |
IP_cc(t) | Initial Pledge for CC sectors at time t | ||
IP_filplus(t) | Initial Pledge for sectors with Verified Deals at time t | ||
Cost_ccseal | 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_ccproving | 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 |
Cost_ccgas | Gas cost for sealing CC sectors | ||
Cost_dseal | 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_dproving
| 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 |
Cost_dataOp
| 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 |
Cost_dealGas | Gas cost for deal publishing ( PublicStorageDeals message) | This cost refers to the PublicStorageDeals message and the absolute cost is the same for:
- Deal Sector
- Full CC Sector Upgrade
- Existing CC Sector Upgrade
Nevertheless, the amortized costs depends on the number of deals published together in each scenario. | |
Cost_snapembed | Cost of embedding data when snapping | — | Currently not considered in the model. We expect this cost to be minimal. |
Cost_snapproving | Proving cost of the SnapDeal protocol (~ cost of C2 with the current SnapDeal protocol) | 0.1$ per snap | |
Cost_snapgas | 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 ProofReplicaUpdates message.
This discrepancy may change soon. | |
Cost_snapextra | Cost of storing the old CC replica for 900 epochs before deletion after Snap is completed | — | Note that this cost is really minimal. |
Formulas
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+