![[2023Q2] CC Sector Upgrade: Guidelines and Modeling](/_next/image?url=https%3A%2F%2Fassets.super.so%2F70d25217-3b12-48f5-b837-e5a3cb5a4d4a%2Fimages%2F921ad9ba-42ae-4205-8aa3-5f8db1ebe5c5%2Fporte-garage.jpg&w=3840&q=80)
@Luca @Irene @Nicola May 2023
Upgrading existing CC sectors is the most profitable option for Filecoin SPs.
If data cap and existing CC sectors are available, SPs should upgrade those sectors rather than sealing new ones.
- 🥁 Context
- 🚀 Outcomes
- Profits overview
- Further Observation on Datacap Availability
- 📡 Future scenarios
- Possible future changes on the CC-Sector Upgrade pipeline
- 📐 Modeling
- Assumptions
- Definitions
- Pipelines
- Parameters
- Formulas
🥁 Context
- The different storage pipelines which are available in the Filecoin Network today
- The outcomes of the modeling the profit of the different pipelines and our recommendations for SPs
- An overview of the model
In the Filecoin network, a Storage Provider (SP, for short) can seal two different type of sectors
- CC sectors: data set by default to zero
- Deal sectors: data collated previously (off chain) from clients.
Thanks to FIP0019 (”SnapDeal”) and the introduction of the ReplicaUpdate method, it is possible to inject data into CC sectors. This means that SPs who want to store client data currently have two different options:
- Sealing a deal sector
- Upgrade a CC-sector via SnapDeal to inject client data. This can be done on any CC-sector, at any point of its life (modulo the fact that there's enough life remaining to cover for the deal duration). We differentiate between
- Upgrading an existing CC sector
- Seal a new CC sector and upgrade it afterwards (CC sector upgrade pipeline)
Our model aims to compare all the different strategies at SPs’ disposal to store client data.
🚀 Outcomes
Profits overview
Best strategy
Our model estimates the profit of this upgrading an existing CC sector pipeline to be ~25/30% higher that the profit of a new deal sector added to the network, if no lending is required.
CC Upgrade Pipeline Vs Deal Sectors
➡️ If datacap is not available, starting with a CC sector and upgrade later on is fine.
Indeed the difference between the CC sector upgrade pipeline and the deal native sector pipeline is NOT remarkable. In the current modeling, without considering fixed costs (electricity, bandwidth, labor costs,…) the difference between CC sector upgrade ROI and deal sectors ROI is ~25%. We expect real difference to be considerably closer, given that overall total cost difference will be minimal when introducing fixed costs.
Further Observation on Datacap Availability
🔍 If datacap is available but there are no existing CC sectors available, the preferred strategy for SP should be to seal new sectors with verified deals. If you have datacap, upgrade the existing CC sector.
🔍 If datacap is not available, then adding a CC sector to be upgraded afterwards has in general a lower profit than adding a new sector with deals. Nevertheless, in the model the difference is not remarkable and we expect the difference to be lower when fixed costs are considered. An upper bound on the current estimation of this difference is ~20%.
📡 Future scenarios
Possible future changes on the CC-Sector Upgrade pipeline
💰Cheaper CC sector acquisition
This modeling is considering sealing of a CC sector and of a deal sector to have the same cost. If we assume that acquiring CC sector is cheaper than sealing a new deal sector then the CC sector pipeline would be closer (o even better) than the deal sector one. What can make CC sector acquisition cheaper than sealing a new deal sector can 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 profit comparison between CC Sector Upgrade and Deal Sector is due to gas fees accounting in the two different pipelines. In particular
- 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 bug which prevents the two pipelines to be fairly compared.
There are two different paths to re-balance gas accounting for deal activation
- Option 1: make sectors in the deal pipeline to pay gas costs associated with activation
- Option 2: discount the activation gas fees for the CC sector upgrade pipeline (subsidizing those costs w/ cron or other alternatives)
We expect the CC sector upgrade and the deal sector pipelines to be closer after fixing the mismatch. See
✌️Lowering down Snapdeal costs
Another option to improve on CC Sector upgrade pipeline is lowering down proving costs of the SnapDeal protocol. A few attempts went in this direction (see
📐 Modeling
We model all the different strategies (i.e. pipelines) available for storing data in the Filecoin network. The model computes the costs and the rewards of each pipeline having as inputs basic SP resources 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.
Definitions
Pipelines
The different pipelines any SP can opt for in the Filecoin Network are described below (in brackets the corresponding categorization in our Observable model).
🛑 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_B | Bandwidth cost for 32 GiB transfer | TBD | |
Cost_S | Cost of 32GiB storage at time t | We assume storage costs are stable for a time window of 2 years | |
lendingR | Lending interest rate | In the model we allow for tunable lending interest rate. after talking with different stakeholders in the community we assume a realistic value to be around 20% | |
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_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) | For WindowPoSt related gas costs
• Filfox
• Starboard
For WindowPoSt related proving costs
• Pre-Supranational upgrade
• Post-Supranational upgrade
| |
Cost_dgas | Gas cost for a sector with deals deal publishing at time t ( PublishStorageDeals message) | Note that deal activation gas costs for deal native sectors are currently subsidized by cron.
This will change soon. See Separating proof validation from sector activation | |
Cost_dataLat | Latency costs (includes idle time) related to data acquisition | TBD | This cost is the same for
- Deal Sector
- Full CC Sector Upgrade
- Existing CC Sector Upgrade |
Name | Description | Source | Comment |
BR(t) | Expected share of the block reward that a 32GiB sectors with no deal gives in a day (computed at time t) | ||
d | Sector lifetime in days | — | Set to maximum (540 days today, 5y in the future) |
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) | Spreadsheets from Supranational
• Pre-Supranational upgrade
• Post-Supranational upgrade | 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) | Spreadsheets from Supranational
• Pre-Supranational upgrade
• Post-Supranational upgrade | 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) | Spreadsheets from Supranational
• Pre-Supranational upgrade
• Post-Supranational upgrade | 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) | Spreadsheets from Supranational
• Pre-Supranational upgrade
• Post-Supranational upgrade | 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 | TBD | 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 | TBD (should be minimal, could be skipped) | |
Cost_snapproving | Proving cost of the SnapDeal protocol (~C2 with the current SpanDeal protocol) | Supranational Spreadsheets
• Pre-Supranational upgrade
• Post-Supranational upgrade | |
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 will change soon. See Separating proof validation from sector activation | |
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. To see the full model, check the model page in Observable
- Reward: 0
- Costs: 0
- Profit: 0
- Reward_ccpure: BR*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+