[Feature]: Consumer chain validator queries

[MSalopek]

Summary

With the advent of permissionless ICS it would be useful to have API methods returning data about the consumer chain validators that includes data coming from both the x/staking and provider modules.

Having rich validator data simplifies client-side data fetching and makes interacting with delegation work flows much easier because a single source of on-chain data can be queries.

Problem Definition

At the moment of writing, clients must use the following data flow to obtain a filtered list of all consumer chain validators:

1. query staking validators

• returns a list of validator metadata (moniker, website, commision rate on provider) and valoper address used for delegations

2. query opted_in_validators for a consumer chainID

• /interchain_security/ccv/provider/opted_in_validators/{chain_id}
• returns a list of valcons addresses of validators that have opted in to validate the consumer chain
• this list does not contain the definitive list of validators that are actually required to run the consumer chain binaries and vote during consensus rounds

3. query consumer_validators for a consumer chainID

• /interchain_security/ccv/provider/consumer_validators/{chain_id}
• returns a list of {valcons,power,consumerKey} for validators that are required to validate the consumer chain in the current epoch

4. query validator commission for the chainID

• /interchain_security/ccv/provider/consumer_commission_rate/{chain_id}/{provider_address}
• returns a commission rate for a particular valcons on a particular chain

Proposed Feature

The flow described above is quite cumbersome to get around and can be reduced to a single query on the provider module that would return all the relevant data.

Implement a query that returns enriched data for opted-in validators:

• refactor /interchain_security/ccv/provider/consumer_validators/{chain_id}
• or use /interchain_security/ccv/provider/consumer_validators_extended/{chain_id}

The endpoint should always return opted-in validators and clearly specify if the opted-in is required to validate the current epoch. This should work for all chains regardless of the spawnTime param.

Proposed return type (as json)

// RichConsumerValidatorData or ExtendedConsumerValidatorData
{
  "operator_address": "cosmosvaloper...",
  "consensus_address": "cosmosvalcons...",
  "consensus_pubkey": {
    "type": "tendermint/PubKeyEd25519",
    "value": "<base64data>"
  },
  "description": {
    "moniker": "ConsuVal",
    "identity": "123lsadpsld",
    "website": "https://consu.val"
  },
  "provider_commission_rate": "0.10",
  "consumer_commission_rate": "0.25",
  "provider_tokens": "4999500",
  "provider_power": "4999500",
  "consumer_power": "50000",
  "status": "BOND_STATUS_UNBONDED", // on provider -> includes inactive valset
  "validates_current_epoch": true
}

Possible states:

Opted-in, does not validate epoch

e.g relevant for chains with validator caps -> number of opted-in validators can be larger than the cap; anyone outside the cap is not validating

• validator outside the provider active set has opted-in to validate a chain with valset_cap = 20

// validator is outside `valset_cap` -> validator number 30 in the list
{
   ...
  "status": "BOND_STATUS_UNBONDED", // on provider
  "validates_current_epoch": false  // not validating but opted-in
}

• validator outside provider active set, opted-in, inside the valset_cap = 20

// validator is outside `valset_cap` -> validator number 30 in the list
{
   ...
  "status": "BOND_STATUS_UNBONDED", // on provider
  "validates_current_epoch": true  // opted-in and validating
}

• validators in provider active set, opted-in, inside the valset_cap = 20

// validator is outside `valset_cap` -> validator number 30 in the list
{
   ...
  "status": "BOND_STATUS_BONDED", // on provider
  "validates_current_epoch": true  // opted-in and validating
}

• validators in provider active set, opted-in, outside the valset_cap = 20

// validator is outside `valset_cap` -> validator number 30 in the list
{
   ...
  "status": "BOND_STATUS_BONDED", // on provider
  "validates_current_epoch": false  // opted-in and not validating
}

This should be implemented for both opt-in chains and top-N chains. There should be no distinction between chain types when querying.

Chains that have not reached spawn time

If possible, for chains that have not reached their spawn time and generated the consumer genesis make it so that the validators that would fall inside the valset_cap would have validates_current_epoch set to false.

Do this because no validator is actually validating because the chain is not running as an ICS chain.

Tasks

Preview Give feedback

1. Introduce a query to return the consumer valset before spawn time #2159
   scope: UI scope: provider +2
   
2. Add fields to consumer_validators query feat: add fields to consumer validators query #2167