Validator list

[csillag]

mockups: https://www.figma.com/file/8dwSyYOOm3vlgbvxPGT29p/Block-Explorer-(Post-Launch)?type=design&node-id=6092-212988&mode=design&t=y5RJp5Wyw0HndnoP-0

current UI: https://explorer.dev.oasis.io/mainnet/consensus/validators

API endpoint: http://nexus.oasis.io/v1/consensus/validators

• we need rank prop, we need to track it in http://nexus.oasis.io/v1/consensus/validators/{entity_id / address} as well
• Do we need to sort by rank by default or we are fine with current sorting. It is escrow, right?
  • [@Andrew7234 ] added rank (sorted by active escrow balance) in Andrew7234/validator api #686(wip)
• Provide data to media prop. Currently we do not have data for props like logotype etc. Sometimes name is missing too. Oasis Scan sample https://api.oasisscan.com/mainnet/validator/list?pageSize=500
• add uptime prop. Our mockups require detailed historical uptime data for validators, but it seems like overkill. Maybe we can simplify it to Oasis Scan style - badge with "100%" label. Their API has uptime:t "100%" prop. If we can have historical data that is ofc a better option.
  • [@mitjat] In product syncs we discussed (and IMO Jernej supported too) a "24h uptime" stat. The % uptime wrt full history is not very informative.
  • TODO: How is uptime/liveness of a node defined? @Jan Berčič to explore.
  • [@Andrew7234 ] Block signers (wip in consensus: save block metadata #646) should be a good proxy for this, but open to suggestions. Either way, this requires an additional PR)
• filtering by status active/inactive. (In mockups I can see waiting as well, not sure what it is). Imo we should push back as we do not support list filtering anywhere.
• add delegators (number) prop
  • [@Andrew7234 ] wip in Andrew7234/validator api #686
• add escrowChange24 (string ) prop
  • Related to Track per-epoch staking rewards #813
  • Probably best to track each validator's total shares and staked tokens for every epoch (= at the starting block of an epoch?) (Unknown: Are rewards disbursed in the first or last block of an epoch?)
  • Might be a good project for Jan
  • It's not easy to know whether a given block is first/last in an epoch. But we don't need to, probably: Update the epoch's stats on every block, but only if the current block is the max height block that we've seen so far for this epoch.
    • Yikes but to update the table, we need to query the balances of 120+ validators, in 120+ node calls.
    • So this is best done as a separate analyzer. Then we'll also know which heights are first/last in an epoch because the analyzer can look it up in existing tables.
      • Get list of epochs that need to be processed (from chain.epochs , ignoring epoch with end_height == max height seen so far)
      • For each epoch:
        • Find validators in the DB (only the ones active in this epoch? all validators seen so far?)
        • Query the node
        • Record historical staking balances+shares of validators in a new table in the DB
  • [@Andrew7234 ] The required data will be indexed in Andrew7234/validator staking history #703. Note that it only tracks active/debonding escrow balances (since we don't need to track voting power). A follow-up PR may be needed for the api work
• add voting prop. Let's use the same convention/notation for voting and current_rate props. I don't remember how we deal with percentage values in other places in API
  • [@Andrew7234 ] wip in 686, Implementation note: we return the voting power of the entity (int64) and the total voting power (int64) and let the explorer calculate the percentage.
• how we want to handle cumulative voting
  • [@Andrew7234 ] wip in 686, since we return the raw voting power of each validator the frontend can calculate this.
• view also has "stats section". Oasis scan adds additional props to list endpoint. We can add them to other endpoint too I don't care. We would need props like active_validators , waiting_validators, inactive_validators , delegators , bond_rate . However, I think we should push back that idea and kill stats section in the list view.
• we also need to render chart with "Active/Inactive/Waiting" how current props map to these three states?
  • [@Andrew7234 ] need more research into this, but will likely be added as part of Andrew7234/validator api #686

Subtasks:

• Add %24hr escrow change for validators - Andrew7234/validator staking api #732

[csillag]

Copying old comment from @Andrew7234:

See also the #861 . The big chunk of remaining work is to support uptime/participation rate. I think the block signers/proposer data can be used as a proxy for this. Warren has a #646 which tracks this data, but we will need a follow-up PR to expose this data in the validators api.

[ptrus]

The remaining part is tracked in #860. I will close this to avoid duplicated tasks.