# Cryptoeconomic considerations for FIP-047

#### **Authors: Shyam, JP, Irene, Luca, Tom**

### Summary
[FIP-0047](https://github.com/filecoin-project/FIPs/pull/446/files) is a Filecoin Improvement Proposal that adds a `ProofExpiration` parameter to each sector, and describes a policy to be adopted in case a flaw is discovered in the theory or implementation of proof-of-replication (PoRep).

The two new parameters introduced by the policy are:

1. `MaxProofDuration`: The proposed value of which is 1.5 years due to security considerations.
2. `ProofRefreshWindow`: The duration of the window preceeding expiration during which a proof can refresh. The default value is 117 days, based being the maximum value that allows three refreshes in 5 years. Other values satsify three refreshes but have better incentive alignement.
3. And a third that already exists and is relevant to to PoRep reseal incentives is the `TerminationFee` penalty.

This analysis sets out how these three parameters affect incentives to reseal, and suggests values for implementation that maximize the incentive compatibility of this FIP.

**Key Recommendations**:

* A `ProofRefreshWindow` of approximately **30-60 days** is optimal for making resealing more economically viable than not resealing, considering both typical scenarios and across a wide range of possible scenarios.
* A **50-100 day block reward per sector** `termination fee` is sufficient to drive storage providers towards the intended behaviour of resealing their sector in the case of a PoRep bug. We suggest **no change** from the current termination fee right now. But note that in the near the future termination fee will likely need to be revised upwards: the current termination fees were set in the context of 6 month sectors, and revision soon after sector duration multiplier implementation (if accepted) is high priority.

### Step-by-step analysis

**Step 1:** Understanding what parameters we can finetune.

* `ProofRefreshWindow`
* `TerminationFee`

**Step 2**: Developing a function for a SP's utility in the case where they choose to reseal their sector and the case where they choose not to reseal their sector.

There are multiple driving forces that affect a storage provider's utility:
* Termination fees, pledge dynamics, future rewards dynamics, and the future time horizon over which they continue to maintain a sector.
* The time SPs have to reseal their sector, which depends on the time between when the `RefreshProofExpiration` is disallowed and the `ProofExpiration` epoch is reached, is also an important factor.
* A mathematical description of the model is given in the following [document](https://hackmd.io/@1dR0N2W7SQyZWg7DGB8Vfw/SyXsYkVvi).

**Step 3**: Understanding how the parameters we can tune affect the time a storage provider has to reseal their sectors.

The relationship between the `ProofRefreshWindow` and time within which a sector must be resealed is in general not straightforward. It depends on three variables:
1. The time when the bug is discovered. In the simulation this is uniformly distributed between the time the proof was last refreshed and the time the proof expires.
2. The time when the proof was last refreshed. This is modeled as beta(3,1) distributed to reflect a bias towards lazy refreshing.
3. The number of times the proof was previously refreshed. This is sampled from a distribution derived from historical data.

For small values of `ProofRefreshWindow` the distribution of reseal times is nearly uniformly distributed. As `ProofRefreshWindow` increases the distribution concentrates towards a central peak. This is shown in Figure 1. The derived distributions in this figure were generated by simulating the 3 random variables described above --- for details please see this [Jupyter notebook]((https://colab.research.google.com/drive/15G-VBQXOQ6505Q53w6miRhCC70hTP-1P?usp=sharing)).


Fig 1A: Empirical probability density function and cumulative density function for reseal time. This is shown for `ProofRefreshWindow` of 30, 60, 120, 175, 225 days. The distribubtions are generated from sampling 100,000 simulation rounds.


Fig 1B: Empirical cumulative density function and cumulative density function for reseal time. This is shown for `ProofRefreshWindow` of 30, 60, 120, 175, 225 days. The distribubtions are generated from sampling 100,000 simulation rounds.

**Principle to approach next steps:** Different `ProofRefreshWindow` values result in different distributions of reseal time. These distributions each have different relative utilities for reseal vs no reseal. The principle to select a value for `ProofRefreshWindow` is to select a distribution which maximises this relative utility making resealing most rational.

**Step 4**: Optimizing the relative utility of reseal over no reseal, as a function of reseal time ([link](https://colab.research.google.com/drive/1SsZQKDoVU_ReRy_g1E65mMxRm1qlhZ5H?usp=sharing)).

We first used to the Filecoin mechaical twin model to collect data on the circulating supply projections of Filecoin. Using this data and the the mathematical models we previously derived, we were able to visualize how this reseal utility changes with the time a SP has to reseal their sector.


Fig 2: Utility for each sector as a function of its reseal time and profit horizon. The black line represents the breakeven point. Values above this line are positive.


Fig 3: Values of reseal time that give maximum utility for specific values of profit horizon.


Fig 4: Utility for each sector as a function of its reseal time for specific values of profit horizon.

* As we see in fig 2, the relative utility is negative for small reseal times because of gas and machine constraints.
* From fig 3 and 4, we observe that the optimal number of days to reseal is, as we estimate, 107 days, conditional on our model assumptions,
* We arrive at this conclusion by looking at multiple profit horizon values since we do not know how long each SP would keep their sector active.
* For the ones that we expect to most commonly observe (180, 250, 540, 1095, 1825 days), we found that the value of reseal time that maximises the storage provider’s relative utility of reseal for each of these profit horizon values was 107 days.
* Relative utility decreases after this due to ‘no-reseal’ gaining utility if the time to reseal is very high (as it can continue to earn rewards for a long time with no reseal action), and because of the future initial pledge dynamics.

**Step 5**: Choosing the right parameter for the `ProofRefreshWindow`.

The principle is to select a `ProofRefreshWindow` that has a distribution of time-to-reseals that have the most positive utility.

If the `ProofRefreshWindow` is less than 30 days, too much of the distribution of reseal times is concentrated at small values, where resealing is not rational due to gas and machine constraints (see Fig 3).

Our approach to finding the optimal value of `ProofRefreshWindow` is as follows:

* The black line in Fig 3 represents the epresents the breakeven level set for relative utility (Reseal - Noreseal) — above this line resealing is rational, below it is not.
* Our objective is to find the distribution of reseal times that minimizes the expected value of the relative utility level set, in order to maximize resealing across the network.
* The `ProofRefreshWindow` that can give us such a distribution and minimize this metric would be the ideal value.


Fig 5A-B: Quantiles and expected value of the breakeven point as a function of the ProofRefreshWindow.

* From figure 5, we can conclude that a `ProofRefreshWindow` below 30 days would be sub-optimal, as the reseal time for some sector would be too low (since the minimum reseal time takes the value of the `ProofRefreshWindow` itself according to the distribution in figure 1).
* We can infact see in fig 5A that for `ProofRefreshWindow` values less than 30 days, the extreme values (Q99) for the breakeven point becomes alarmingly high. Thus we wish to stick to a minimum of 30 days.
* As we see from the above graph, the minimum value that the expected and median breakeven points takes is for a `ProofRefreshWindow` value of 30 days. A lower breakevenpoint decreases the number of sectors for which it is rational to opt for reseal over no reseal.
* A value of **30 days** would
* Keep the lowest possible value of reseal time to be $\ge$ 30 days.
* Allow for 3 refreshes before commitment expiry.
* Give us a lower value for the breakeven point than we would get if the `ProofRefreshWindow` was higher or lower.

**Step 6**: Assessing the effect of termination fee on the miner’s utility ([link](https://colab.research.google.com/drive/1f6ROH9f-pgw2l4dugod7NEnEcf8ydJjW?usp=sharing)).

So far in our analysis, we assumed that the termination penalty was set to a value of expected 90 day block rewards. We thus wished to asses how the relative utility of reseal is affected when we consider a wider range of values for the termination penalty.


Fig 6: Utility for each sector as a function of its reseal time, profit horizon and termination penalty.


Fig 7: Utility for each sector as a function of its reseal time and termination penalty for specific values of profit horizon.


Fig 8: Utility for each sector as a function of termination penalty for specific values of profit horizon and reseal times.

Termination fee summary
* If the intended sector duration is very low (e.g. 100 days), no level of termination fee will create a scenario in which sector reseal is rational.
* If the intended sector duration is very high (e.g. 1000 days), generally it's always rational to reseal
* If the intended sector duration is in the low to intermediate range (e.g 200 days - 500 days), it is rational to reseal for smaller values of termination fee for most reseal times.
* For example, for a profit horizon of 500 days, as long as the reseal time is less than around 490d - it is always rationale to reseal for even a termination penalty that is as low as the 50d expected rewards

In any case, a higher termination fee would always make resealing a more economically viable option

**Recommendation:**
* A termination fee of a 90 day expected reward still drives resealing to be the rational choice among SPs for most profit horizon and reseal time values
* In order to change the termination fee, we must do a deeper analysis to see how it would affect the circulating supply of Filecoin, and understand the tradeoffs in how changing the termination fee to optimise PoRep would affect the deterrence of faults and terminations otherwise.

**Tradeoffs to consider**

We can interpret our results in two ways:
* A higher termination fee drives resealing to be economically rationale for a wide range of reseal times.
* A shorter reseal time coupled together with smaller termination fee values allows resealing to be more economically viable.

We can either (i) tune the value of the termination fee to become larger while paying less attention to the reseal times or we can (ii) tune the `ProofRefreshWindow` to allow for a distribution of shorter reseal times for as many sectors as possible, while letting the termination penalty retain its current value.

We prefer option 2, since from the perspective of a storage provider a very high termination fee can be a deterring force for them to join the network. However, a more comprehensive analysis on the termination fee and its effects on the network is an exhaustive study which the CEL plans to do moving forward.

**Step 7**: Finding the optimal value of `ProofRefreshWindow` for a range of termination fees: ([link](https://colab.research.google.com/drive/1f6ROH9f-pgw2l4dugod7NEnEcf8ydJjW?usp=sharing))

Now that we have established that a higher termination penalty is better and that there is a potential of tuning it to reach higher values based on a more comprehensive analysis, the next question we ask ourselves is if a value of 30-60 days for the `ProofRefreshWindow` is still optimal.


Fig 9: Quantile values of the breakeven point for a distribution of 100,000 sectors as a function of the ProofRefreshWindow for different termination penalty values.

As we observe from the above graphs, even for higher values of the termination penalty, the optimal `ProofRefreshWindow` value continues to be in the range of **30-60 days.**

**Step 8**: Analyzing the utility pathways and finding the optimal value of `ProofRefreshWindow` after SDM scaling is introduced to the termination fee: ([link](https://colab.research.google.com/drive/1XhmaapwIAJwhY_sO8q13_MWGvL-E0-GB?usp=sharing))

The SDM FIP draft introduces a change to the termination fee cap such that it scales with the duration multiplier in order to ensure that the relative incentives regarding the ratio of termination fees to aggregate lifetime block rewards of a sector is maintained.

Our next step was to analyze the various utility pathways of resealing in a post SDM world.


Fig 10: Utility for each sector as a function of its reseal time and profit horizon after the SDM fee cap change is introduced. The black line represents the breakeven point. Values above this line are positive.

- From Fig 10 we see that the relative utility of reseal follows a similar trend to what we obsevered in the base case where the termination fee was not scaled with the duration multiplier
- In fact, we notice that this change further drives resealing to be the economically rational choice, with the breakeven point going as low as 0 for select reseal times

The natural next question we ask oursevles is whether a `ProofRefreshWindow` between 30-60 days continues to be optimal


Fig 11: Quantile values of the breakeven point for a distribution of 100,000 sectors as a function of the ProofRefreshWindow after the SDM fee cap change is introduced.

As we observe in Fig 11, the optimal `ProofRefreshWindow` value continues to be in the range of **30-60 days** even after the SDM fee cap change is introduced.