owned this note
owned this note
Published
Linked with GitHub
# CPR-SA: Consensus Pledge
###### tags: `filecoin-pl` `Protocol Review`
:::info
Updated by April 2023
:::
*Authors: Danilo Lessa Bernardineli (BlockScience), Jamsheed Shorish (BlockScience), Jakob Hackel (BlockScience)*
___
*Meta*
- Title: Consensus Pledge: Locking the Network Journey into Safety
## Intro
:::success
ok
:::
In this article, we'll dive deep into possibly the most interdisciplinary Cryptoeconomic Mechanism of the Filecoin ecosystem: the Consensus Pledge. It brings together the concepts of the Filecoin token (FIL) Circulating Supply, its Baseline Minting, the network's Quality Adjusted Power (QAP) and per-Sector dynamics, all within one requirement placed upon the provision of storage by a Filecoin Storage Provider.
As such, in order to have a good grasp of what the Consensus Pledge is and does, we need to first understand (much of) the underlying economics of the Filecoin ecosystem.
___
*The [Filecoin Consensus Pledge Educational Calculator](https://share.streamlit.io/blockscience/filecoin-consensus-pledge-demo/main/app/main.py) is an useful open-source tool for gaining intuition.*
![](https://hackmd.io/_uploads/rktyD2-Z2.gif)
### What does the Consensus Pledge do?
:::success
ok
:::
When a Storage Provider onboards a new sector, an amount of Filecoin must be locked pre-emptively. This serves two functions: one is about ensuring that faults and penalties should be covered for, and this is the rationale for the Storage Pledge, which is valued at 20 days of Estimated Sector Rewards. In the same vein, the fact that rewards are mostly Locked rather than immediatly released also takes an inspiration on this function.
**The second function is to enhance Security to the network by enforcing large capital costs to opportunistic attackers**. This is accomplished by the **Consensus Pledge**, and the exact amount that should be locked is given an below expression.
$SectorInitialPledge(t) = SectorStoragePledge(t) + SectorConsensusPledge(t)$
$SectorConsensusPledge(t) = TLS * CirculatingSupply(t) * \frac{SectorQAP}{max(Baseline(t), NetworkQAP(t))}$
Where TLS is the Target Locked Supply Parameter, which is set as of now to 30%. One general heuristic is that the Consensus Pledge tends to steer the network trajectory such that 30% of the Circulating Supply is locked as Consensus Pledge Collateral, although the exact number can vary significantly as we'll see on the next sections.
### A brief intro to Filecoin Token Distribution terminology
:::success
ok
:::
In order to understand Circulating Supply, it helps to first to know what are the Sources and Sinks of the Filecoin Token. It does have two Sources: Mining Issuance and Vested Filecoin, and it has a single Sink: Burnt Filecoin.
Between the Sources and Sinks there are multiple token flow pathways. We could argue that Filecoin Economics is all about the different ways of definning the Acummulation points and the circulation between them and the Sources / Sinks.
One possible terminology for the distinct acummulation points is the figure given below. Arrows indicates possible flow directions. From there, we can define some names:
- Miner Collaterals = All Storage Pledges + All Consensus Pledges + All Deal Collaterals + Any "surplus" Collateral
- Locked Filecoin = All Locked Rewards + All Miner Collaterals
- Meaning: All Filecoin that's locked because of Sectors.
- Available Filecoin = Everything that has been Mined + Everything that has been Vested - Everything that has been burnt
- Meaning: All Filecoin that has been released into the economy. Can be understood as being as the Total Supply right now
- Circulating Filecoin = Available Filecoin - Locked Filecoin
- Meaning: All Filecoin that's immediatly transferable. Can be understood as the Supply on which users can perform deal-making and actions on the Secondary market.
With clarity on those items, we're ready to perform a deep dive on what Consensus Pledge does.
___
*Illustration of the Filecoin Token Components. The blue ones makes the Locked Filecoin Supply, and the ones in yellow are the collateral components.*
![](https://hackmd.io/_uploads/SJB84khRj.png)
## Going Deep into the Consensus Pledge
### The Consensus Pledge is a Mechanism
:::success
ok
:::
From a requirements perspective, Consensus Pledge was designed with two properties in mind:
1. Reflect some measure of existing supply, so that the locked amount is not too large or too small; and
2. Reflect some measure of the relative size of the storage provided, as compared with the ecosystem's total storage, so that the locked amount enhances security.
The functional form of the Consensus Pledge was selected in service of these reflections---we break down the Pledge in what follows, describing the importance of its components and demonstrating their impact(s) in a series of stylized examples.
#### The Components of the Pledge
:::success
ok
:::
The components of the Pledge (and their notation in what follows) are:
1. `Target Locked Supply`, $TLS$,
2. `Circulating Supply` at time $t$, $\Omega_C(t)$,
3. `Sector Quality Adjusted Power`, $f_s$ (the storage provider is providing this),
4. `Network Baseline Power` at time $t$ $b(t)$, and
5. `Estimated Network Quality Adjusted Power` at time $t$, $\Pi(t)$.
Of the above components, `Target Locked Supply` is a tunable, governance-level parameter, set as of this writing to 0.30. This amount is intended to adjust the impact of the `Circulating Supply` upon the Pledge, e.g. the value of 0.30 implies that 30% of the `Circulating Supply` contributes to the Pledge. This contribution in turn controls the intensity of the Pledge.
The functional form, given the components above, of the Initial Consensus Pledge at time $t$, $p_c(t)$, may be expressed as:
$$
p_c(t) := TLS * \Omega_C(t) * \frac{f_s}{\max \{ b(t), \Pi(t) \}}.
$$
#### Target Locked Supply and Actual Locked Supply
:::success
ok
:::
The `Target Locked Supply` terminology can be somewhat confusing, as the actual fraction of supply that is locked accounts for not just the Consensus Pledge, but also the Storage Pledge and Locked (Block) Rewards. Thus, over time it may be that the "Actual Locked Supply Fraction" exceeds the fraction expected to be locked when relying upon the TLS parameter. This is more likely to occur if the Network QAP is higher than the Baseline Power, and if the marginal Circulating Supply per onboarded sector rewards is relatively constant.
By contrast, there are also situations where the Actual Locked Supply Fraction is _lower_ than that expected from the TLS parameter. This can occur in between updates of the Consensus Pledge, which only occurs when onboarding, upgrading or renewing a sector. For example, if Block Rewards were to be unlocked at a time without a Storage Pledge, then less supply would be locked than expected until such time as the Consensus Pledge was updated.
#### How the Pledge Components Interact
:::success
ok
:::
To gain intuition behind this functional form, we can express the same information in a slightly different way, by explicitly defining exploring how the relative amount of storage provided interacts with the fraction of circulating supply. We write:
$$
p_c = f_{s, \Pi} * \Omega_C * \tilde{f}_{TLS}.
$$
The first term, the Sector Power Fraction $f_{s, \Pi}$, is the Sector QAP $f_s$ divided by the Network QAP Estimate, $\Pi(t)$. The second term is, as before, the protocol's circulating supply $\Omega_C$. Finally, the last term $\tilde{f}_{TLS}$ is the *Effective Target Locked Supply* Fraction, which assesses the impact of the Target Locked Supply $TLS$ on the Pledge as a fraction of the baseline power or Network QAP, whichever proves larger. This is itself defined as:
$$
\tilde{f}_{TLS} := TLS * \min(1, n_\Pi(t)),
$$
___
*The Effective Target Locked Supply as dependent on the QAP Power proportion vs. Baseline. ([source](https://docs.google.com/spreadsheets/d/13iB2BPN-0QcxcghlxAVzI9l-nPvSFnbauaymnugYZS4/edit?usp=sharing))*
![](https://hackmd.io/_uploads/rkZLOcuW3.png)
___
where $n_{\Pi}(t)$ is defined as the _relative Network QAP advantage over baseline power_:
$$
n_\Pi := \frac{\Pi(t)}{b(t)}.
$$
As of 29 March 2023, the above numbers can be inferred through the [Starboard Filecoin Dashboard](https://dashboard.starboard.ventures/dashboard) and the Sentinel database as being:
|$\Omega_C$ (MFIL)| $b$ (EiB) | $\Pi$ (EiB) | $n_\Pi$ | $\tilde{f}_{TLS}$|
|-|-|-|-|-|
|454.92|15.10 [^baseline_sql]|13.02|0.86|0.26
The Effective Target Locked Supply Fraction $\tilde f_{TLS}$ rescales the TLS value by how much more the estimated Network QAP $\Pi(t)$ exceeds the Baseline Power $b(t)$. Intuitively, the stronger the network power, the more the Sector Power Fraction should simply reflect the size of the ecosystem---so the impact of the TLS (via the Effective Target Locked Supply) should be as large as possible when $n_\Pi > 1$.
\
By contrast, if the Network QAP falls below the Baseline Power, then the Sector Power Fraction needs to be adjusted downward accordingly to provide the security of the ecosystem at the Baseline Power reference level. Note that this reduces the Pledge and hence incentivizes onboarding of new storage. In that case, $n_\Pi < 1$ and the Effective Target Locked Supply is reduced
For example, when the Network QAP is 50% of the Baseline Power, then the Consensus Pledge will be half as much as it would be if the Network QAP is 100% or more of the Baseline Power - assuming that the sector share remains the same.
Practically speaking, given that sectors tend to have fixed sizes, the $\min$ operator in the definition of the **Effective Target Locked Supply Fraction works by providing a ceiling for how much the Consensus Pledge per Sector should be**, for a given amount of Circulating Supply $\Omega_C(t)$.
#### Example: Computing the Consensus Pledge
:::success
ok
:::
The table below demonstrates the computation of the Consensus Pledge value $p_c$ (the second column) as a function of the variables described above for an single 32 GB raw-bytes sector. We can observe that all things being equal, the only factor that can cause an increase on Consensus Pledge is additional Circulating Supply, while both increasing Network QAP or Baseline growing above Network QAP can both induce an reduction on Consensus Pledge.
___
Stylized Consensus Pledge calculations for an 32GB sector with no quality adjustment. ([source](https://docs.google.com/spreadsheets/d/13iB2BPN-0QcxcghlxAVzI9l-nPvSFnbauaymnugYZS4/edit?usp=sharing))
![](https://hackmd.io/_uploads/S1eKzi_W2.png)
___
### Why have the Consensus Pledge?
:::success
ok
:::
As desribed earlier, the importance of the Consensus Pledge lies in the fact that it provides a means for storage providers to signal their good faith when engaging within the ecosystem. As this mechanism leverages the usage of the ecosystem FIL token, the Consensus Pledge also becomes the **main economic lever** to remove circulating FIL, and hence lessen the supply of FIL on the secondary market.
This means that, to first order, the introduction of TLS into the Consensus Pledge
- Significantly increases the cost to onboard 33% of the Filecoin QAP---this is related to [protocol security](https://spec.filecoin.io/systems/filecoin_blockchain/storage_power_consensus/), so that a significant fraction of ecosystem storage is prohibitively expensive to accumulate;
- Provides additional economic protection for the network against faults, by allowing the protocol to slash Pledged amounts locked by a Storage Provider;
- Significantly increases the capital investment and FIL exposure required for onboarding new sectors, endowing storage providers with an incentive to contribute to the stability of the FIL token's value in the secondary market;
- Provides a means of restricting FIL liquidity as a function of storage provided, so that FIL is less readily available to convert to other stores of value (tokens, fiat, etc.) and hence lose value.
It is more difficult to assess the impact of the introduction of TLS into the Consensus Pledge to higher order, because the interactions can be more complex than the first order effects described above. Attempting to provide such an assessment is usually heavily dependent upon underlying assumptions about e.g. ecosystem participant behavior, and conclusions must consequently be drawn with caution. Some (non-exhaustive) potential second order cause-effect chains include:
- Impacting the valuation of the Filecoin ecosystem based upon fundamental metrics, such as Total Value Locked;
- Favouring Sector onboarding in the direction of token holders; and
- Inducing liquidity scarcity on the secondary markets as a function of ecosystem growth, impacting the use of FIL for other operations.
___
![](https://hackmd.io/_uploads/r1s82uzx2.gif)
*Animation: A simplified vision of Filecoin's Economy in terms of causal drivers and effects. Consensus Pledge sits right on the middle. ([Source](https://kumu.io/danlessa/filecoin-qap-cld)*)
___
As an example of the latter effect (and potentially other cause-effect chains not described here), the Consensus Pledge could potentially run counter to properties considered desirable for Deal Marketplace Stakeholders, as it means that the global share of FIL available for Deal Making is diminished.
Not surprisingly, the TLS parameter has always been the most challenging parameter to set, given its impact and the trade-offs involved as described above. Its importance in the ecosystem for explaining the movements of other factors, and hence upon the established Filecoin system goals, is illustrated in the following figure. This figure ranks the importance of various governance parameters of the ecosystem in decision tree analysis (cf. Analysis and Recommendations for Filecoin, p. 40[^filecoin_documentation]), indicating that TLS carries the highest importance when examining the impact of these parameters upon a measure combining all system goals.
The table following the figure also indicates the impact of TLS on the indivdiual system goals of the ecosystem, showing that only for the system goal "Reliability" is the impact of TLS expected to be minimal (cf. Analysis and Recommendations for Filecoin, p. 10 [^filecoin_documentation].
___
![](https://hackmd.io/_uploads/HycVu8_Si.png)
*Importance of the Parameters on the "Combined Goals" KPI. Target Locked Supply is the most important parameter. Analysis and Recommendations for Filecoin, p. 10[^filecoin_documentation]*
![](https://hackmd.io/_uploads/r1yqvLdHs.png)
*Effects of the Protocol Cryptoecon Parameters on Design Goals. Analysis and Recommendations for Filecoin, p. 10[^filecoin_documentation]*
### Challenges of Understanding the Consensus Pledge
:::success
ok
:::
Consensus Pledge is notable for the number of different concepts it brings together (and hence creates bridges between), making it challenging to understand its emerging dynamics from its constituent components. Specifically:
- Understanding the circulating supply $\Omega_C(t)$ _requires_ describing the historical and current token dynamics in terms of minting (which is linked to Baseline Minting and Baseline Power), SAFT vesting, FIL token burning (itself linked to gas dynamics & slashing dynamics) and locking (linked not only to the Consensus Pledge itself, but also to the associated Block Rewards from mining);
- The Sector QAP $f_s$ directly impacts sector onboarding, sector renewal and sector upgrade events;
- The reliance of the Pledge upon the relative magnitudes of the Baseline Power and the (Estimated) Network QAP, from the Effective Target Locked Supply Fraction $f_{TLS}$, means that locked FIL is direcly associated with the [Network Power Baseline Crossing](https://medium.com/block-science/a-cadcad-interactive-calculator-to-explore-minting-scenarios-in-filecoin-284009a2e941);
- The Estimated Network QAP, $\Pi(t)$, is determined from a forecasting tool based upon previous data (the [Alpha-Beta Filter](/aXjjtYsoQfmVkPRgt9sZLg)).
Collectively these interactions make analytical predictions, or intuitive 'stylized facts', difficult to achieve without a suitably complex model (which itself carries difficulties for e.g. simulation and scenario design). Nevertheless, such a 'comprehensive' model is a requirement in order for its evolution to be considered representative of the actual generated dynamics of the Filecoin ecosystem.
___
*A simplified vision of Filecoin's Economy. Consensus Pledge is near the center of it. ([Source](https://kumu.io/danlessa/filecoin-qap-cld)*)
![](https://hackmd.io/_uploads/r1s82uzx2.gif)
### Intuiting about Consensus Pledge through a cadCAD Educational Calculator
:::success
ok
:::
To give Filecoin ecosystem participants better insights and intuition about the effects of the Consensus Pledge, BlockScience built an [interactive simulation](https://share.streamlit.io/blockscience/filecoin-consensus-pledge-demo/main/app/main.py) that lets users consider the effects of varying scenarios under simplified assumptions.
The app gives users full control over various parameters to test how the network evolves under different conditions. Metrics which can be observed includes the Initial Pledge per RBP/QAP, the Cost to Onboard 33% of the QAP, FIL Locked, Collateral & Circulating Supply and among others.
___
[The Filecoin Consensus Pledge Educational Calculator.](https://share.streamlit.io/blockscience/filecoin-consensus-pledge-demo/main/app/main.py)
![](https://hackmd.io/_uploads/rJ7TisOZh.gif)
___
The sidebar on the left lets users set a total time for the simulation and then adjust the scenario for up to five distinct phases. Users can either adjust parameters in-app or via uploading parameters directly as .json files. Additionally, users can download the results as .csv files. Those features **allows the simulations input and outputs to be directly reproducible**.
As an **example** for a scenario to be tested, lets assume the following parameter values for the simulation. This scenario represents an story on which the Quality Adjustment and Storage Onboarding goes up suddenly 1 year after the simulation start, and then the network stays on a steady state in regards to onboarding for 1.75 years. After that, there's another explosion on onboarding. All while sector lifetime going up. This can be understood somewhat as an story on which there's an explosion of demand for Filecoin because of FIL+ and sector duration incentives.
Some of the effects which can be observed (and reproduced by doing more scenario simulations) are:
- The Critical Cost (Capital Costs to onboard 33% of the Network QAP) remains on the ~25M FIL magnitude most of the time. Sudden increases on onboarding will transiently make it go higher, but it does adjust itself fast (eg. in less than 6 months)
- Sudden jumps on Onboarding / Quality Factor tends to make the Filecoin Locked Supply increase significantly initially, although this effect is transient and tends to wash off with time.
- The Initial Pledge per QAP tends to only go down. However, there's an different story when we look to the Initial Pledge per RBP. It is possibly to have large jumps on it when there's an transition on the onboarding pattern, althoug it decays very fast (possibly in the order of days or weeks).
___
*Configuration for the Example Scenario*
| Phase | Phase Duration | Raw Bytes Onboarding Rate | Onboarding Quality Factor | Sector Lifetime in days | Monthly Renewal Rate |
| - | - | - | - | - | - |
| 1 | 1y | 25 PiB | 1.5 | 270 | 10% |
| 2 | 0.25y | 200 PiB | 10 | 800 | 0% |
| 3 | 1.75y | 30 PiB | 6.5 | 1000 | 5% |
| 4 | 0.25y | 1000 PiB | 6.5 | 1000 | 12% |
| 5 | 0.25y | 0 PiB | 7.5 | 360 | 3% |
___
*Metrics for the Example Scenario*
|![RBP](https://hackmd.io/_uploads/H1qephrl3.png)|![QAP](https://hackmd.io/_uploads/H114T3Bg3.png)|
|-|-|
|![](https://hackmd.io/_uploads/ryArT2Heh.png)|![](https://hackmd.io/_uploads/Hy4Ip3Bxh.png)|![](https://hackmd.io/_uploads/HyhDThBe2.png)|
|-|-|-|
|![CLS](https://hackmd.io/_uploads/SJnVT3Sen.png)|![TD-CL](https://hackmd.io/_uploads/SJzr62Slh.png)|![LTD-CL](https://hackmd.io/_uploads/rk_rpnHen.png)|
|-|-|-|
|![](https://hackmd.io/_uploads/rk6ITnBl3.png)|![](https://hackmd.io/_uploads/rJVwThrx2.png)|
|-|-|
___
*Notes Scenario Descriptions:*
The simulation starts with one year of activity seen previously in Filecoin history and then explores some shocks to the network:
1. 25PiB are onboarded daily, with an average Quality Factor of 1.5. Such a scenario corresponds roughly to October 2021 to June 2022. The aggregate sectors have a lifetime of 270 days, while 10% of the PiB are renewed monthly.
The overall PiB supply drops slightly in this period, since onboarding and renewal rates are not fully keeping up with sectors dropping. As the Baseline Function still increases, this results in Baseline Minting reserving part of the issuance, incentivizing additional PiB to be onboarded.
2. Following this initial phase we test a brief period where the proposal for Sector Duration Multiplier (SDM) is approved. With this incentive new storage supply is sharply increasing, resulting in the daily onboarding of 200PiB with an average QF of 10 (without SDM, the maximum multiplier would be 10x. As it is unrealistic that every PiB is onboarded through Verified Deals, a QF average of 10 is likely only achieved through additional multipliers, such as an additional 3.5x for SDM).
As the Baseline Function becomes saturated rewards are increasing, yet the high increase in PiB results in lower rewards per PiB. The increased PiB also needs to lock up collateral and reduces drastically the Circulating FIL. While sector lifetime also increases drastically, renewal rate drops to 0%.
3. As such a period decreases rewards per PiB, storage supply then drops to prior levels while demand stays reasonably high. Sectors still show high lifetimes and renewal rates are slowly increasing again.
4. Next, another brief period of highly increased supply hits the network. We assume that demand for this supply keeps up, so the average QF stays high at 6.5x.
5. Finally, an intense shock hits the system - newly onboarded PiB drops to 0 (QF is set to 7.5, but irrelevant - older sectors that get renewed are adjusted by their old QF). With this shock, renewal rates are dropping too as the reasons for onboarding new PiB are likely correlated with reasons to renew existing sectors.
## The Story behind the Consensus Pledge
:::success
ok
:::
The initial economic design of the Filecoin ecosystem didn't include Consensus Pledge as a means of ensuring 'good faith' behavior from storage providers. Miner collateral was instead structured to disincentivize storage providers from dropping sectors early, and so the Initial Pledge was largely derived from actual sector Block Rewards that were locked and released only over time (cf. the screenshot below describing the Initial Pledge per Sector).
___
![](https://hackmd.io/_uploads/ByaaWwdBj.png)
*Initial Requirements for the Sector Collateral. Slash The World, April 2020.*
___
The combined introduction of Quality Adjusted Power together with Verified Deals during the design of the network changed how Pledging took place in the ecosystem---this introduction meant that:
- If the system remained largely built upon Committed Capacity (i.e. storage committed to be available but currently unused) and Regular Deals, it would require an comparatively small share of the Raw Byte (RB) power to acquire an large amount of QAP. For example, if (say) 95% of the RB power is provided by Committed Capacity Storage, while only 5% is provided by Verified Deals, the latter storage providers would in reality hold just over 34% of the Network QAP.
- Onboarding deals could now be completed faster than onboarding storage, because the latter is constrained by the Sealing Capacity, which is expensive in terms of hardware (while predictable in terms of its rate of change).
In addition, most of the Filecoin cryptoeconomic mechanisms were being designed in 2019 and 2020, just before and during the so-called "DeFi Summer". The wave of capital inflows, and concurrent economic attacks, that occurred at this time introduced to the ecosystem a key design goal: _resilency to economic attack_. Taken together with the above effects, this design goal provided a strong rationale for introducing the Consensus Pledge mechanism as a way of strengthening both Security and Economic Attack Resiliency.
### Sector Lock-up Mechanism Adoption: Historical Challenges
:::success
ok
:::
Deciding upon the form and implementation of Sector Collateral was always one of the most difficult problems for Filecoin's cryptoeconomic mechanism design. Just after the Mainnet Launch (in October 2020) Sector Collateral was one of the main cost drivers for storage providers when onboarding new sectors. This was compounded by the lack of Circulating Supply of the FIL token just after launch, resulting in a liquidity crunch for providers.
When the Consensus Pledge was proposed in June 2020 (two months before Testnet), there was a lot of community discussion resulting in concerted 'pushback' against the idea of an additional sector collateral. These concerns were addressed through the following measures:
1. Testnet sectors were allowed to remain on Mainnet _without the need for collateral_. This generated further debate in April 2021, when a Filecoin Improvement Proposal (FIP) allowing sector renewal was approved (cf. [The Impact of V1 Sector Expirations on Filecoin Storage and Cryptoeconomics](/XGL9Ip6dR9KySTSsJe8b2g) for further information.)
2. Block Rewards were released sooner, by
- releasing 25% of Block Rewards immediately (cf. [FIP0004](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0004.md)), and
- removing the vesting cliff duration. Intially set at 2 months, the cliff duration was first reduced to 20 days and then removed entirely, when simulations indicated that there was ultimately no benefit in having a delay in Block Reward release.
During the design and development of the Consensus Pledge, the optimal value of TLS was found to depend heavily on the set of design goals, and in the maximization of Key Performance Indicators (KPIs) associated with those goals. This was complicated by the fact that (as described earlier) TLS has synergistic interactions with other governance parameters, particularly those related to the duration of FIL locking.
BlockScience implemented a simulation framework ("Digital Twin") that provided the means to assess the initial parameterization of the Consensus Pledge. Initially (before Testnet) BlockScience's recommendation was to set TLS to 0.2, (i.e. 20% of Circulating Supply) while keeping the vesting cliff duration to 3 months.
The pre-Testnet recommendation further evolved before Mainnet launch, when the liquidity crunch was taken into consideration to create an additional design goal, to recommend no vesting cliff duration and a reduced overall period of locked reward to 3 months instead of the initial 6 months (cf. the figure below).
![](https://hackmd.io/_uploads/r1qzPLOHs.png)
*Final Recommendations before Mainnet. Source: cadCAD Decision Support System - Analysis and Recommendations for Filecoin[^filecoin_documentation]*
The final value of 0.3 for TLS was arrived at from discussion and feedback between and among BlockScience, Protocol Labs and miner groups, providing a value that balanced stakeholder preferences with BlockScience's simulation-based recommendations.
*The adopted parameters for Mainnet*
|Vesting Cliff Duration|Vesting Linear Duration|Immediate Reward Factor|Target Locked Supply|Deal Collateral Fraction|Initial Pledge Factor|
|-|-|-|-|-|-|
|0 days|6 months|25%|30%|1.0%|20d
## The Future of the Consensus Pledge
:::success
ok
:::
The **Consensus Pledge was introduced to address the security concerns** of the Filecoin ecosystem at the time of its introduction. The evolution of the ecosystem over the past 3 years has changed both the supply side and the demand side of Filecoin’s services (and associated infrastructure), necessitating an adjustment of the associated governance parameters affecting e.g. minimum storage duration. It is natural, then, to view the Consensus Pledge as also requiring an evolution, so that it does not remain a solution to a problem that no longer exists, and a problem for a system seeking a new solution.
For instance, there may also be functional form changes of the Consensus Pledge, which are more difficult to capture. For example, if a Sector Duration Multiplier (SDM) or a Capped Duration Multiplier (CDM) solution changes the immediate or long-term supply of storage, the explicit comparison to the baseline may become less relevant—instead, there may be another metric, such as the relative proportion of committed capacity to verified deals, that provides the security that the Consensus Pledge is designed for.
Ultimately the Consensus Pledge should, as with the other mechanisms present within the Filecoin ecosystem, act in service to the goals held by stakeholders, such as providing safe, secure, retrievable data in a decentralized, economically favorable manner that is (at least) competitive with other data storage solutions. As the ecosystem begins to address the addition of data via Filecoin Plus, and the method by which storage providers are incentivized to extend the duration of a Sector, there is an active role to be played by an informed governance process that can adapt the Consensus Pledge to new conditions.
Although not (strictly speaking) required, a suggestive component of “informed” in this context is the ability to rely upon computer simulations of the Filecoin ecosystem that provide a means to experiment with different ‘what if?’ scenarios. Each scenario (e.g. [SDM vs. CDM](https://medium.com/block-science/reviewing-the-fip-0056-and-cdm-debate-on-filecoin-6a6af0ed4b78), short vs. long sector duration, Filecoin Plus vs. Committed Capacity onboarding, etc.) provides a ‘testbed’ for adjusting the parameters and underlying functional form(s) of the Consensus Pledge, by influencing KPIs and metrics that are used to assess whether system goals such as Security and Resiliency are maintained.
In this way, adjustments to e.g. TLS can be supported by more than informed opinion, or (better still) couple informed opinion with quantitative assessments that ensure the continuing evolution of a critical component of the Filecoin safety and incentive mechanism suite.
## Resources
:::success
ok
:::
- [Reviewing the Target Locked Supply](/90MrWid8QHejWGAju9EaDw)
## References
[^filecoin_documentation]: cadCAD Decision Support System - Analysis and Recommendations for Filecoin, October 2020. BlockScience
# Leftovers
| $\boldsymbol{p_c}$ | $\boldsymbol{b(t)}$ | $\boldsymbol{\Pi(t)}$ | $\boldsymbol{f_s}$ | $\boldsymbol{f_{s, \Pi}}$ | $\boldsymbol{\Omega_C}$ | $\boldsymbol{\tilde{f}_{TLS}}$ |
| - | - | - | - | - | - | - |
| 0.3 | 100 | 100 | 1 | 0.01 | 100 | 0.3 |
| - | - | - | - | - | - | - |
| 0.3 | 99 | 100 | 1 | 0.01 | 100 | 0.3 |
| 0.3 | 100 | 100 | 1 | 0.01 | 100 | 0.3 |
| 0.297 | 101 | 100 | 1 | 0.01 | 100 | 0.297 |
| - | - | - | - | - | - | - |
| 0.3 | 100 | 99 | 1 | 0.0101 | 100 | 0.297 |
| 0.297 | 100 | 101 | 1 | 0.0099 | 100 | 0.3 |
| - | - | - | - | - | - | - |
| 0.1493 | 100 | 201 | 1 | 0.00498 | 100 | 0.3 |
| 0.15 | 100 | 200 | 1 | 0.005 | 100 | 0.3 |
| - | - | - | - | - | - | - |
| 0.3 | 100 | 51 | 1 | 0.0196 | 100 | 0.153 |
| 0.3 | 100 | 50 | 1 | 0.02 | 100 | 0.15 |
There are five adjustments that can be made for each phase:
1. First, users can adjust the *duration of each phase*. This lets them test the evolution under various scenarios.
As an example, one might test a long period of consistent supply growth (RBP), with a brief and sudden demand shock after (Quality Factor), followed by a longer phase of recovery.
Then, users can adjust some assumptions about new sectors that are onboarding:
2. The *Raw-Byte Power* (in PiB) onboarded per day. Varying this allows testing of different growth scenarios on a Raw-Byte Basis. On a technical basis, each day adds 1 cumulative sector, serving as an aggregate of all sectors onboarded that day.
3. The *Quality Factor* of the newly onboarded or renewed RB Power. The Quality Factor will determine the additional QAP added by a sector, and affects the network QAP over time (which affects the share of Baseline Minting and the size of the Consensus Pledge).
The main factor for additional quality of Sector Storage are Verified Deals (10x multiplier). Other Quality Factor multipliers might be adopted through FIPs in the future and can be tested here. As a simplification, this simulation uses an average quality adjustment for newly onboarded aggregate sectors based on the Quality Factor of the respective phase.
4. The *Sector Lifetime*, measured in days. Users can set this from the minimum 6 month Sector Lifetime up to 40 months of Sector Lifetime, incremented in days. In this simulation, sectors are not terminating due to faults, only when their lifetime reaches 0.
5. The *monthly probability* that a sector will be renewed. Each day, sectors in Filecoin might be renewed to extend their lifetime. As a technical simplification for this simulation, this probability assesses the total share of RBP that is renewed each day. The renewed RBP is subtracted from the old sectors and added as a new aggregate sector, with updated collateral and lifetime. Remember that one simulation sector would consist of thousands of sectors in the actual Filecoin network. A monthly renewal probability of 15% would then be somewhat analogous to ~90% of the related RBP renewing over the course of a 180-day Sector Lifetime.
#### Metrics
The simulation shows users the effects on various metrics relating to:
* **Network Storage:**
Network RBP shows the evolution of raw storage in Filecoin. It is an important metric for supply-side considerations and block rewards, as Baseline Minting will slow down when the Baseline Target is above the Network RBP.
Network QAP lets users consider effects on Filecoin consensus, demand-side effects and feedback loops within Filecoin - such as a shrinking Network QAP reducing the required Consensus Pledge, given equal onboarding Sector QAP. This in turn increases Circulating Supply, which again increases the required Consensus Pledge.
* **Token Distribution:**
Users can evaluate the evolution of Circulating FIL and Locked FIL, both relative to Available FIL and as absolute amounts, as well as the distribution of Locked FIL as either collateral or locked block rewards. Token Distribution is once again an important factor to determine Collateral Requirements. However, the Circulating Supply depends on many factors - FIL being minted (depending on Network RBP through Baseline Minting), burned (through transaction fees), lockked up and then vested (unlocked Block Rewards).
* **Network Security:**
Critical Cost works as a proxy for network security. Requiring the Consensus Pledge collateral from onboarding Storage Miners drastically increases the stakes for an attacker needing 33% of QAP.
$$
Critical Cost = OnboardingPledgePerQAP * (1/3) * NetworkQAP
$$
Circulating Surplus shows how many units of FIL are circulating for each unit of FIL that an attacker would need to acquire. Comparing the amount of FIL that an attacker would need (to acquire) for an attack to the Circulating Supply gives good intuition about the increased cost for consensus attacks introduced by the Consensus Pledge at various stages of the network.
$$
Circulating Surplus = Circulating Supply / Critical Cost
$$
* **Onboarding Costs:**
The distribution of the onboarding costs per PiB (both for RBP and QAP) for the individual parts of the Initial Pledge further show the effects of the Consensus Pledge on security. While an increase in Consensus Pledge makes attacks more costly, it naturally also increases capital costs for honest Storage Providers and their daily operations.
* **Rewards:**
Finally, daily rewards are shown both on a total basis (seperated in share of simple minting and baseline minting) as well as expected rewards per PiB. Note that sectors with a higher QAP/PiB (as in: those with higher QF) also earn more rewards - their usefulness to the network, indicated through a higher QAP, awards them more shares of the rewards. Comparing these rewards directly to the costs mentioned above only tells one side of the picture though. Miner Rewards in Filecoin are partly Block Rewards, and partly Deal Revenue. The latter is a demand-side concern and outside of the scope of this educational calculator.
## Footnotes
[^baseline_sql]: We've used the following SQL on [Sentinel](https://lilium.sh/) to retrieve the Baseline Power
```sql
select
avg(new_baseline_power) / (2^60) as avg_baseline_in_eib /* RB EiB */
from chain_rewards cr
where cr.height > unix_to_height(extract(epoch from timestamp '2023-03-28 15:00')::int8)
and cr.height < unix_to_height(extract(epoch from timestamp '2023-03-28 17:00')::int8)
```