Skip to content

Latest commit

 

History

History
73 lines (50 loc) · 4.31 KB

sector-health-rate.md

File metadata and controls

73 lines (50 loc) · 4.31 KB

Sector Health Rate

Meta

Document Purpose

This document is intended to become the canonical resource that is referenced in the Storage Providers Market Dashboard wherever the “(TBD) Sector Health” graphs are shown. A reader of those graphs should be able to read this document and understand the "Sector Health SLO”. The goal of this document is to explain fully and clearly “the rules of the game”. With the “game rules”, we seek to empower market participants - onramps, aggregators and Storage Providers (SPs) - to “decide how they want to play the game”.

Versions / Status

SLI Version Status Comment
v1.0.0 wip 2024-11-04: this was started as a placeholder to start moving the exploration work from davidgasquez/filecoin-data-portal#79 over and to seed this repo with more than one metric definition. It needs more review, and particularly SP feedback on the caveats of this metric. It is not decided that "Sector Health Rate" is the right name or that this should be under "durability". Agains, this current iteration was done to move fast so there is more skeleton in this repo before FDS 5.

Support, Questions, and Feedback

If you see errors in this document, please open a PR. If you have a question that isn't answered by the document, then ... If you want to discuss ideas for improving this proposoal, then ...

TL;DR

Filecoin has a robust mechanism already for proving spacetime on chain for each sector. The proportion of successful proofs over time gives indication of the "durability" of data stored on these sectors.

Metric Definition

On a daily basis and for each SP compute:

  • Number of Active Sectors
  • Number of Faulted Sectors

An SP's daily sector health rate is then

$$\frac{\text{Number of Active Sectors - Number of Faulted Sectors}}{\text{Number of Active Sectors}}$$

Implementation Details

There are multiple ways to compute this metric. Multiple options are outlined as they differ in self-service local reproducibility vs. scale.

Option 1: Lotus RPC Calls

Below explains the way to compute this method when using Lotus RPC:

  • This metric is computed based on a single sampling per SP per day. This works because:
    1. A sector that is faulted stays in the fault state for a duration that is a multiple of 24 hours given a sector's state transitions in and out of faulted state happens during the providing dealine for the sector.
    2. New sectors in a given day may get missed until the next day, but sectors aren't a highly transient resource flipping into and out of existence. Since sectors tend to have a lifespan of months or years, not counting them on their first day isn't a significant impact on the metric over time.
  • Number of Active Sectors is computed by getting the SP's Raw Power (StateMinerPower) divided by the SP's sector size (StateMinerInfo)).
  • Number of Faulted Sectors is computed by daily querying for the StateMinerFaults for each SP with sectors.

Option 2: Lily Events

Below explains hoe an Filecoin blockchain event indexer like Lily can be used.

TODO: fill this in or link to the corresponding Lily query in FDP?

Appendix

Callouts/Concerns with this SLI

For full transparency, a list of potential issues or concerns about this SLI are presented below.

  1. TODO: add items here

Related Items