Meso-Research
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:
FIP 19:
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.
On practical terms, that FIP allows a CC sector to be upgraded to a RD / VD sector within the following conditions:
SectorUpdateDeposit
amountDeclareUpdate
-> 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
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: ??? |
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)
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
andReplacedSectorAge
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.
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:
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.
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
.
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}.
\]
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}.
\]