# Qualitative Analysis, FIP 17/FIP 19

###### tags: `Meso-Research`

:::info
Up to date by September 2021
:::

Note: FIP 17 "Lightweight Sector Updates" was closed August 24, 2021 and superceded by FIP 19 "Snap Deals"

FIP 17:
- https://github.com/filecoin-project/FIPs/issues/131
- https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0017.md

FIP 19:
- https://github.com/filecoin-project/FIPs/issues/145
- [fip-0019.md](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0017.md) TBD as of Aug 27

## What it does

FIP 17:

> 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.

FIP 19:

>Replaces FIP-0017
>
>Unlocking currently available CC sectors (8EiB) for deals by allowing CC to be updated to contain deals in a lightweight and fast process.
>
>Differences from FIP-0017
>
>- Update is now one message process with no waiting for randomness involved. Time to complete the upgrade reduced from 3h to less than 30min.
>- Encoding function changed slightly with a minimal compute cost increase (computing 512 Posseidon hashes).
>- Proof creation cost is slightly increased (10%) to enable cheap verification.
>- Proof verification cost is radically reduced by performing challenge generation in the circuit.

## Analysis (FIP 17)

On practical terms, that FIP allows a CC sector to be upgraded to a RD / VD sector within the following conditions:

- Miner can afford the initial pledge related to the new deals
- Miner can afford the `SectorUpdateDeposit` amount
- Miner doesn't have debt
- Miner has non-expired deals on the sector to be upgraded (eg: **the sector to be updated must consist entirely of committed capacity**)
- Miner has enough balance to offset the gas fees
- Miner executes an message flow that consists of `DeclareUpdate` -> `PreCommitReplicaUpdate` -> `ProveCommitReplicaUpdate`

Notice that failure in completing the update protocol by a `SectorUpdateExpiry` duration imply losing the new deals initial pledge + `SectorUpdateDeposit` amounts.

Another complicator is that the upgrade is not immediate, but rather dependant

### Free Parameters

Parameter | Comments
| - | -
`SectorUpdateDeposit` | Goal: cover both PreCommit and ProveCommit messages. It is given back after the process.
`SectorUpdateExpiry` | Goal: ???
`PreCommitReplicaUpdateRandDelay` | Goal: avoid miner to adaptively choose deals
`ProveCommitReplicaUpdateChallengeDelay` | Goal: avoid miner to be able to do long forks to grind better challenges
`SectorUpdateProveChallenges` | Goal: ???

### Potential Crypto-economic effects

- Right now, any additional demand of storage must be covered by sectors being sealed at given point of time, which requires a flux of collaterals.
- FIP 17 allows sectors which consists entirely of committed capacity to include a given number of deals, and they do not need to fill the entire sector.
- In terms of economic rationality provided that the risk-adjusted gas costs and opportunity costs related to the upgrade deposits are lower than the costs minus the marginal rewards associated with onboarding a new sector, then it's rational to upgrade an old sector rather than creating a new one.
- Economic Rationality of Upgrading: (Gas Costs + Upgrade Opportunity Costs) < (Onboarding New Sector Opportunity + New Sector Operational Costs - Expected New Sector Rewards)
- If the upgrade is relatively cheap, we can expect that the main determinants of whanever to upgrade will be the trade-off between new CC rewards and the new sector operational / opportunity costs.
- Notice that the value of the deal itself is not important, **unless there's a time advantage in onboarding a new sector vs upgrading a new sector**
- From a operational perspective, and **assuming that the upgrade cost is marginal compared to onboarding a new sector**
- It is possible that this upgrade will disproportionaly benefit capital-scarce / risk-averse miners, as they will put a heavier weight on the risk-adjusted opportunity / operational costs
- From an Macrodynamics perspective, the upgrade will increase the relative fraction of FIL being locked, although the exact weight will depend on the VD dominance.
- The heavier the share of VDs on the qa-NP, the less will make a difference.
- The order of magnitude probably will be one or two orders below 1% * (rb-NP / qa-NP) * (rb-NP associated with deals / total rb-NP).
- if rb-NP / qa-NP = 0.8, and rb-NP with deals / total rb-NP = 0.1, then **we should expect a essentially negligible relative increase in collaterals.**
-

### Possible Research Directions

- Specifying a economic rationality formalism and using it to inform regions parameters related to upgrade deposits and upgrade delays. This will mostly likely to be a separate series of experiments decoupled from the Digital Twin development
- Value: inform parameter selection under a strict set of assumptions
- Performing a more in-depth analysis / CLD of the economic incentivizations of the FIP, and how they relate to different stakeholder profiles
- Value: detect unexpected trajectories and risk points, especially regarding specific groups
- Investigate KPIs associated with the FIP, like an Upgrade Incentive Index
- Value: improved decision-making for the target audience
- Perform simulations to quantify the amount of additional collaterals due to the FIP under a range of circumstances
- Value: validation of the Digital Twin extrapolation workings

### Termination Fee implications

Word problem: "We just want to review Termination Fee calculation to make sure we dont miss any edge cases or create some attack surface. The concern is with potential strategies that a miner can employ to upgrade and then terminate to incur a lower termination fee."

Definitions:
tau: activation epoch
t: upgrade epoch

Before the upgrade:

Fee(t) = max(SectorStoragePledge(t), SectorStoragePledge(tau)) + B(tau; 1d) * cappedSectorAge(t) + replacedDayReward(?) * relevantReplacedAge(t)

After the the upgrade:

tau = t
t = t + dt
Fee(t) = ExpectedStoragePledge() + B(tau; 1d) * cappedSectorAge(t) + ExpectedDayReward(?) * (upgradeEpoch - Activation)

## Update given August 24th new termination fee policy

> `NewTF(t) = max(SP(t), max(BR(CC_StartEpoch, 20), BR(Upgrade_StartEpoch, 20)) + max(BR(CC_StartEpoch, 1d), BR(Upgrade_StartEpoch, 1d)) * (1 / 2) * min(sectorAgeFromCCStartInDays, 140))`
>
> - and then we remove `ReplacedDayReward` and `ReplacedSectorAge` from the sector info.
> - There is also no change to `ActivationEpoch` at the time of the upgrade.
> - `max(BR(CC_StartEpoch, 20), BR(Upgrade_StartEpoch, 20))` will be stored.
> - `max(BR(CC_StartEpoch, 1d), BR(Upgrade_StartEpoch, 1d))` will be stored.

### Edge cases

Terminology:

| Name | Description |
| -------- | -------- |
| **Original Sector** | Sector containing only committed capacity |
| **Upgraded Sector** | Sector that previously contained only committed capacity but that is upgraded-in-place with deals |
| **New Sector** | Sector that is onboarded containing deals and replaces an expired original sector with committed capacity |

Notation:

| Name | Notation |
| -------- | -------- |
| $IP_o$ | Initial pledge for original sector |
| $IP_u$ | Initial pledge for upgraded sector |
| $IP_n$ | Initial pledge for new sector |
| $TF_o(t, \tau_o)$ | Termination fee for original sector with activation epoch $\tau_o$ and termination epoch $t$ |
| $TF_u(t, \tau_o, \tau_u)$ | Termination fee for upgraded sector with original sector activation epoch $\tau_o$, upgraded sector activation epoch $\tau_u$, and termination epoch $t$ |
| $TF_n(t, \tau_n)$ | Termination fee for new sector with activation epoch $\tau_n$ and termination epoch $t$ |
|$C_n(t, \Delta t_n)$ | Cost of onboarding a new sector over a period $\Delta t_n$, starting from epoch $t$ |
|$C_u(t)$ | Cost of upgrading a sector at epoch $t$ (includes gas cost $\gamma_u(t)$ defined below) |
| $\gamma_u(t)$ | Gas cost of upgrading an original sector to an upgraded sector at upgrade time $t$ |

Edge cases:

1. _An original sector is upgraded with data to provide a lower initial pledge._
This edge case is eliminated by setting the initial pledge of the upgraded sector to be the maximum of its original initial pledge (as committed capacity) and the initial pledge that obtains from containing deals following the upgrade.
Let $\Delta IP_{u,o}$ denote the **_locked pledge difference_**, i.e. the difference in the initial pledge locked between the upgraded and the original sector:
$$
\Delta IP_{u,o} := IP_u - IP_o.
$$
Then the $\max$ operation on the initial pledge ensures that $\Delta IP_{u,o} \geq 0$ always, i.e. that there is no saved initial pledge from upgrading the sector.
Note: this is a sufficient condition to prevent upgrading to save pledge. A weaker sufficient condition is that the cost $C_u(t)$ of upgrading exceeds any possible savings in pledge, i.e.
$$
C_u(t) \geq - \Delta IP_{u,o}.
$$
The $\max$ operation, although more restrictive, is significantly easier to implement than the above weaker condition.

2. _An original sector is upgraded with data to provide a lower termination fee._
This edge case is eliminated using the new termination fee functional form of August 24th, which sets the termination fee to be the maximum possible fee, across both 20-day and daily block rewards, between the original and upgraded sectors.
Let $\Delta TF_{u,o}$, the **_upgrade termination fee difference_**, be the difference in the termination fee between the upgraded and the original sector:
$$
\Delta TF_{u,o} := TF_u(t, \tau_o, \tau_u) - TF_o(t, \tau_o).
$$
Then from the definition of the new termination fee function,
$$
\Delta TF_{u,o} = NewTF(t, \tau_o, \tau_u) - TF_o(t, \tau_o) \geq 0,
$$
since $TF_u(t, \tau_o, \tau_u) = NewTF(t, \tau_o, \tau_u)$ with $\tau_o =$ `CC_StartEpoch`, $\tau_u =$ `Upgrade_StartEpoch`, and $t - \tau_o =$ `sectorAgeFromCCStartInDays` $\times$ `builtin.EpochsInDay`.
3. _An original sector is allowed to expire rather than be upgraded, and a new sector is created with data, to provide a lower termination fee._
This edge case may not be eliminated if the net cost after termination of a new sector created with data is less than the net cost of terminating an upgraded sector. This could happen when both **a** and **b** below hold:
**a.** The **_new termination fee difference_** (the difference between the termination fee of the upgraded sector and the termination fee of the new sector) is positive--this can happen if e.g. the age of the new sector is short enough that the daily block reward termination penalty in the fee for the new sector is smaller than that for the upgraded sector upon termination.
Let the new termination fee difference $\Delta TF_{u,n}(t, \tau_u, \tau_o, \tau_n)$ be defined as
$$
\Delta TF_{u,n}(t, \tau_u, \tau_o, \tau_n) := NewTF(t, \tau_o, \tau_u) - NewTF(t, \tau_n, \tau_n).
$$

**b.** The **_transition cost difference_** (i.e. the difference between 1) the cost of expiring an original sector and onboarding a new sector, and 2) the cost of upgrading an original sector) is less than the new termination fee difference. In this case, the termination fee savings from onboarding a new sector covers the total cost of allowing the original sector to expire and of onboarding a new sector, because the termination fee of an upgraded sector is at least as high as the termination fee of the original sector (cf. August 24th termination fee functional form).
Let the transition cost difference $\Delta C_{n,u}(t, \Delta t_n)$ be defined as
$$
\Delta C_{n,u}(t, \Delta t_n) := C_n(t, \Delta t_n) - C_u(t).
$$
Then allowing a sector to expire and creating a new sector will be preferred to upgrading a sector if:
$$
\Delta TF_{u,n} \geq \Delta C_{n,u}.
$$
In other words, this edge case can be eliminated provided
$$
\Delta C_{n,u} > \Delta TF_{u,n}.
$$
4. _A sector is allowed to expire rather than be upgraded, and a new sector is created with data, to provide a lower initial pledge._
[NB: this edge case is mitigated from the confirmation that gas usage for a sector upgrade, $\gamma_u$, is lower than that used for onboarding a new sector (ProveCommit).]
This edge case can occur if the initial pledge computed for the new sector is significantly lower than the initial pledge locked of the original sector. In this situation the intial pledge computed for a new sector is _equal_ to that computed for an upgraded sector, since they both contain the same data, and assuming that they are activated at (around) the same epoch. But the actual pledge _locked_ is different for the two types of sectors. The upgrade process requires the continued outlay of the original sector's pledge, because the initial pledge locked for the upgraded sector is at least this amount, from the $\max$ operation. By contrast, onboarding the new sector will use the initial pledge computation because there is no $\max$ operation performed in that case, i.e. a _lower_ pledge will be locked.
If the **_new pledge difference_** (i.e. the difference between the initial pledge _locked_ of the original sector and the initial pledge _computed_ of the new sector) is positive and outweighs the transition cost difference, then onboarding a new sector instead of upgrading an existing sector will be preferred.
Let the new pledge difference $\Delta IP_{o,n}$ be defined as:
$$
\Delta IP_{o,n} := IP_o - IP_n \geq 0.
$$
Then the edge case described is eliminated if
$$
\Delta C_{n,u} \geq \Delta IP_{o,n}.
$$

Putting (3) and (4) above together, the edge case of allowing a sector to expire rather than upgrade, in order to onboard a new sector to save on pledge and/or termination fee, can be eliminated provided
$$
\Delta C_{n,u} \geq \Delta IP_{o,n} + \Delta TF_{u,n}.
$$