You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The dashboard today is minerId (SP instance in Filecoin protocol) focused. In reality, we know that SP operations (whether individuals, entities, etc.) are often composed of multiple minerIds. Ideally in the data model we'd have this relationship so it would be possible to bring up the performance an "SP entity/operation", looking at an aggregate view across multiple related minerIds.
I (@BigLep) don't know the way to accomplish this. There is no mapping on chain of minerId to peerId. Maybe we can look at the origin address of WindowPoSt messages and aggregate that way? (I assume that is still an approximation, but likely gets decently close.). I also assume other thought has been given to this in the past.
This is an interesting question @BigLep! In the past, I've used some manually curated lists mapping provider_ids to "Entities" but that doesn't scale. Also, some entities want to remain private.
There have been many approaches to this problem, not sure if your idea has been explored though! The approach I'm using is to rely on the Filecoin's scores provided by Nova Energy (API). That only covers a handful of providers for some Entities since they have to apply and get reviewed.
What
The dashboard today is minerId (SP instance in Filecoin protocol) focused. In reality, we know that SP operations (whether individuals, entities, etc.) are often composed of multiple minerIds. Ideally in the data model we'd have this relationship so it would be possible to bring up the performance an "SP entity/operation", looking at an aggregate view across multiple related minerIds.
Why
This came up in https://protocollabs.notion.site/2024-12-03-Client-Success-Meeting-150837df73d4801eb9cae595e2ea1d7c?pvs=4 . It's relevant from a market perspective given onramps/aggregators care about making deals with an actual "SP entity/operation" rather than a specific minerId.
How
I (@BigLep) don't know the way to accomplish this. There is no mapping on chain of
minerId
topeerId
. Maybe we can look at the origin address of WindowPoSt messages and aggregate that way? (I assume that is still an approximation, but likely gets decently close.). I also assume other thought has been given to this in the past.Other Notes
The text was updated successfully, but these errors were encountered: