Tool request: validator keys tracking

[ordian]

This is something I planned on implementing myself, but I think it'd be a good fit for polkadot-introspector collection of tools.

The idea is to have a way to quickly find all information we have on-chain and off-chain about validator by providing some input. That input could be (session_index, validator_index) or AccountId or even PeerId.

The information we store could be:

• AccountId as a unique identification of a validator (session_info->account_keys might be useful)
• ss58 format of accountid based on the network
• session keys for the past N sessions
• information about when they were paravalidators in the past N sessions
• PeerIds
• IP addresses
• ISP and geolocation based on IP

[vstakhov]

The only thing that is not so clear to me is how to find an IP address based on AccountID. Do you have any glue about it?

[ordian]

You can use discovery_keys from SessionInfo (same ValidatorIndex as in AccountKeys) and authority discovery service to map AuthorityDiscoveryId -> Vec<Multiaddr> by using get_addresses_by_authority_id.
And then extract PeerId and IP from that.

Note, that it takes some time for authority discovery worker to populate its cache from DHT.

[ordian]

The hardest part is probably figuring out how to instantiate authority discovery service w/o bringing most of the substrate dependencies.

[vstakhov]

What about moving this tracking logic to the node then? It already has this discovery information, so it might probably store it and provide access via some utility pallet call.

[sandreim]

We could use the imonline pallet, but afaiu this is not really reliable

[sandreim]

Second option is to use the telemetry websocket feed if the telemetry backend has the —expose-node-ips flag

[ordian]

provide access via some utility pallet call

This multiaddr data is offchain and arguably should remain offchain. Maybe we could introduce an RPC call for it, but I think it shouldn't be too hard to implement with authority discovery worker either.