Agents by network power

[yiannisbot]

It was suggested by @momack2 to add a plot on network power per agent for the Filecoin network, in order to have more clearly defined the dependency on each implementation. This is indeed an interesting idea, although our tooling does not gather that information from the network. We would have to pull this information from tools like Lilly, which is not impossible, but we're not clear of the effort needed at this point.

This is a tracking issue to identify what's possible and what's needed in order to make this happen.

[kasteph]

miner_actor_dumps is not available on the public BigQuery Lily dataset, which means that we cannot get the network power by agent version over time.

The only available table from which we could get this information is the power_actor_claims table. However, this has two caveats:

1. A claim is an assertion made by a storage provider. It is not actually verified until later, during WindowPoSt.
2. A row is added to this table only when a storage provider changes its claim. In other words, each entry represents the most recent update for a specific height, and the power value from this table should be treated as the latest state instead of a historical snapshot at that height.

We can create a time series line graph that illustrates the latest power values from the power_actor_claims table for each agent version over time. While this graph won't account for every claim made by storage providers, it will effectively show the trend of network power as it evolves. Another potential approach is to create a bar graph that displays the latest power values for each agent version at specific time intervals (1d, 1w, 1m).

[yiannisbot]

The "Agents by Power" (both quality adjusted power (QAP) and raw bytes power (RBP)) is finally live at: https://probelab.io/filecoin/dht/2025-19/#powers_by_agent_plot-plot - screenshot below. The data comes from the Starboard API and the BigQuery dataset, as well as ProbeLab's crawler data.

At first sight, the fact that the vast majority of power resides with an "unknown" agent version seemed weird, but given that lotus-miner nodes:

1. do not have to report their agent version, multiaddress or anything else (for privacy reasons),
2. do not have to participate in the DHT,
3. do not have to participate in the Gossipsub mesh (or do they have to?), so they can't be seen in the Gossipsub Peer Exchange messages,

showing up as "unknown" is most likely expected behaviour for SPs that do not participate in retrievals (through boost).

cc: @momack2 and @masih to confirm the Gossipsub/networking particulars.

[masih]

Re unknown category - I am curious if the list of libp2p protocols exposed by nodes could be used for classification. The concrete classification name would be ideal but simply knowing the number of classifications would also be very valuable.

[masih]

to confirm the Gossipsub/networking particulars

I would be interested to understand the agent power distribution relative to F3 participation. We should be able to use the list of libp2p protocols exposed by the agents to infer this, i.e. /f3/*.

[dennis-tra]

Re unknown category - I am curious if the list of libp2p protocols exposed by nodes could be used for classification. The concrete classification name would be ideal but simply knowing the number of classifications would also be very valuable.

The list of supported protocols are transferred via the identify protocol which we also use to source the agent version information. Hence, if we don't have agent information we also don't have protocol information :/

---

The recent extension of Nebula to also crawl via GossipSub peer exchange yielded ~50% more peers (~330) than before. However, around 140 (~50%) of the new peers only advertise private IP addresses (at least that's what we learned through GossipSub - why's there no filter to not share such peers?) and almost all connection attempts to the other half time out.

I would be interested to understand the agent power distribution relative to F3 participation. We should be able to use the list of libp2p protocols exposed by the agents to infer this, i.e. /f3/*.

We might be able to get more data from our Filecoin Hermes deployment which we haven't analysed yet.

[yiannisbot]

@BigLep @jennijuju we're looking to close the loop here and the question still remains from my comment further up (#170 (comment)):

At first sight, the fact that the vast majority of power resides with an "unknown" agent version seemed weird, but given that lotus-miner nodes:

1. do not have to report their agent version, multiaddress or anything else (for privacy reasons),
2. do not have to participate in the DHT,
3. do not have to participate in the Gossipsub mesh (or do they have to?), so they can't be seen in the Gossipsub Peer Exchange messages,
   showing up as "unknown" is most likely expected behaviour for SPs

Can you confirm the above statement and also that the "Power by Agent" plot that we're publishing weekly (e.g., https://probelab.io/filecoin/dht/2025-27/#powers_by_agent_plot-plot for the latest one) is according to your expectations, despite the large percentage of "unknown" agent version?

Thanks!

[yiannisbot]

Through a combination of on-chain and off-chain data we're now capturing the "Power by Agent" distribution much more accurately: https://probelab.io/filecoin/dht/2025-40/#powers_by_agent_plot-plot

Closing this issue, feel free to re-open in case something still needs clarification.

[BigLep]

Thanks @yiannisbot for this. I apologize for the radio silence. Notifications for this repo were going to a personal email address I wasn't checking as frequently. I have fixed that now.

Given my lack of engagement, we shouldn't hold this up and it's fine if you all just need to move on, but I think it would be useful to have it documented how the connection from Agent to Power is established (unless it's what's already in the issue).

I'm partly asking about this because during FDS-7 I want to have a discussion with interested attendees on how we can know in advance of a network upgrade how much "power" has updated to support the new network version of "buillt-in actors". This will ultimately involve some degree of mapping minerId X is running software version Y. When I have bandwidth to actually take that on, I'll create an issue for it, but I'm bringing it up as to why I personally would find it useful for understanding the methology of this graph.

I'll reopen the issue to make sure this comment got seen, but it's also 100% fine to close again saying you don't have bandwidth to engage more right now. Thanks!

• Actually I can't reopen. I'll just coment.

[yiannisbot]

Understood @BigLep - re-opening the issue to give a more detailed explanation on the methodology, when we get a moment. We're happy to participate in the discussion at FDS-7 (ProbeLab team will be there). We could also discuss the idea of monitoring the network during transitions/upgrades - see similar study we've done for Ethereum: https://www.probelab.network/blog/ethereums-pectra-upgrade during the Pectra upgrade (and the Dencun one earlier on: https://probelab.io/blog/deep-dive-dencun/).