Storage Reliability on Filecoin #843
Replies: 2 comments 2 replies
-
It's been 6 months since the CEL charts were published. Does it need to update it to reflect the current situation? A lot has changed since then (on the macro level). Has there been a continue increase of sectors termination? |
Beta Was this translation helpful? Give feedback.
-
I found the simulation results slightly surprising, in a good way. My opinion on the topic changed during the initial discussion but, based on the data, it seems that the current policy strikes a reasonable balance between competing priorities and there's no pressing need to change it. Re data stored, I'm somewhat in favour of the principle of providing a baseline level of guarantee (to this point in particular, I note that despite the never-ending debate, there's little robust evidence for negative impact of reasonable minimum wage laws), but I'm unconvinced that this is a real problem or that it warrants action and increased complexity. |
Beta Was this translation helpful? Give feedback.
-
Storage Reliability on Filecoin
Watch the talk from FIL Dev Summit Singapore here.
Background
CEL observed a sharp increase in the number of sectors being terminated between July-2022 to March-2023. Therefore, we started a GitHub discussion #691 to track the issue, and hypothesize reasons for the sharp increase.
We further spent some time analyzing the termination fee structure in more detail and presented our report to the public. The TL:DR from our report was that:
weighting_factor
in the termination fees calculation, which is currently set to1/2
, and, (2) scale theTERMINATION_LIFETIME_CAP
with sector duration commitment according to a functionHowever, on tracking the conversations that took place in our initial GitHub discussion, presenting our findings on the core devs meeting, and dicussing our work individually with different members of the community, it was evident that there were divergent views on changing the termination fee. There were roughly two schools of thought on this issue:
There were a lot of hypotheses that were put forth on what would happen to key performance metrics such as network QAP, daily power termination, daily power being onboarded, etc., if there is a change to the termination fee structure, but what was lacking was a quantitative approach to testing these hypotheses.
Agent Based Modelling
We decided to take an agent-based-modelling approach in order to understand the implication of different termination fee policies on key network KPIs such as - daily network QAP, daily power onboarded, daily power renewed and daily power terminated. This would fill in the gap that existed in the discussions by providing a way to concretely understand the potential implications of different termination fee policies on the network.
The policies that we tested were:
Agent based models are composed of an environment that implements the cryptoeconomic mechanisms of Filecoin (such as locking, vesting, minting, and the interaction between these aspects of token supply), and agents that interact with the environment and model SP behaviour. More details of ABMs can be found in this article.
Note: We are not making predictions of the network KPIs under different policies. Instead, we test different policies in our simulated environment to find the optimal one, and argue that it will also perform well on mainnet. Simulated network KPIs can differ from what is observed in reality.
We built agents that model three types of SPs in the Filecoin network:
More details on the SP specification such as how the ROI from the different pathways are computed, and how the agents decide when to onboard and renew power can be found here. The code that implements the mechanisms and behaviour of these agents can be found [here](will add once PR is merged) and here.
Results
Given below are the results when we ran the simulation of a network with an equal distribution of agents that believed that the future FIL price would be $0.1, $1, $10, and $100.
Fig 1. A) Line plots that describe the total network power (QAP, RBP) in EiB, total QAP onboarded, total QAP renewed, and total QAP terminated during the course of the simulations under each of the three different policies. B) The summary statistics of the same metrics under the same there policies.
Proposal
In order to navigate the tradeoffs between storage reliability and QAP growth we would like to propose the idea of implementing a different policy for different types of SPs, namely CC SPs and FIL+ SPs.
Beta Was this translation helpful? Give feedback.
All reactions