Draft: Validation Diagnostics

# Problem

The health of the validation ecosystem is very important. Things can keep working while things are deteriorating. Unless the cost of obtaining this information is very cheap and reliable, then people will not be able to act in time to reallocate stake or recover from impending failure modes. The failure modes we care about are lack of liveness or consistency, possibly as a result of actions by a byzantine adversary. Also having validator metadata identity metadata available on-chain would be very useful

# Solution

## Query Node

Add support to the QN for rich historical information associated with validators. When this information lives in the QN, it is easy to access for apps like Pioneer, CLI and also for alert-based services that different actors may want to run to detect bad scenarios with low latency. Information we are interested in would be

- History of pretty much all events associated with validation, rewards, staking, nomination, and most importantly: slashing
- Representation of validators, past and present, and with associations to events, and also some useful cumulative numbers, e.g for earning, number of events of various types.
- Representation of nominators, same.

Question: here we really need to think about what nominators want to know when picking validators

## CLI

Add support to the CLI for listing key information about the state of the chain and validation. This information should either be printable to screen, or dumpable to an output file as a structured format that can be easily programmatically parsed, so e.g. JSON.

The information that immediately comes to mind is:

**Chain**
- Most recent finalised block by block height, including key information like the congestion variable, time, size, hash, height, tx count, etc.
- Most recent unfinalized block, same information.
- Presence of chain splits, i.e. finalisation of blocks on either side of a fork.
**Validation**
- Number of validators in the validation set, with key information associated with each, like amount of stake backing, number of nominators, commission, when they last checked in, unpaid reward, impending slashes, and whatever else would be useful.
- Current overall rate of staking.
- Impending slashes.

Most of this information should be available in the state, but adding in some extra historical information, e.g. metadata

# Feedback

I am in particular looking for feedback on

- nailing down more specifically what information we need to collect or display that is important for the relevant user, in particular nominators and the council trying to ensure the overall health and vitality of the system.
- whether there is an alternative approach that would be better in terms of flexibility in how information can be used by other apps or services
- how to detect and report on splits