Validation Screen

[bedeho]

Background

The validation subsystem is complex, and the health of that system depends on how easily we can surface key information about the state of the system and the attractiveness of getting involved (both as validator and nominator) to key stakeholders. Right now, it is way to hard, and it even involves consulting a increasingly stale Notion board, which holds verified social information on some validators.

I think we initially underestimated how information and skill intensive it would be for someone who had $JOY tokens to get involved and safely select a validator to nominate, while understanding rewards, risks, delays, etc. I frankly don't even know half the concepts involved in validator selection, rewards and punishment right now.

Proposal

Introduce a new validation screen in Pioneer which attempts to address this, here are some ideas:

1. surface some top line metrics around the health, status of the overall validation system: useful for nominators, voters and council
2. show list of would-be and current validators, with rich profiles they can submit themselves. This last step probably requires some sort of sign off by council on what profiles are authentic, i.e. "verified" vs not, meaning that the holder of the given validator profile/account is indeed who they say they are.
3. show rich state and history information relevant to the attractiveness of a validator: useful for nominators
4. allow nominators to perform nomination and manage their stake and rewards, and also subscribe to key health indicators around people they are nominating with. Help people to securely nominate offline so they don't need to put wealth online.

At any rate, this is a complex undertaking, so I suggest the following steps

1. Devise some key MVP user stories with domain experts, such as @bwhm , @traumschule and one of the active validatos, e.g. Polkadotters.
2. Identify required changes on runtime and QN: this may be substantial, consider revising scope.
3. A few rounds of low-fi sketches.
4. Design, primarily using existing components.
5. Implementation in Pioneer

Given the size of this, it may be wise to try to be very aggressive on restricting initial scope.

Resources

• Be aware that there is a similar effort started on the CLI side to generate some of this information: https://github.com/Joystream/joystream/issues/4510
• There is already a validator management tool in polkadotjs apps, although it is quite minimal.

[pmensik]

Hello, this is a great initiative and I am glad that Polkadotters can contribute to it! From my point of view, it's a well-thought proposal and sounds reasonable. Just two notes 1) I would definitely focus on the validator identity part in the first iteration - it's a real pain for nominators to be able to select just addresses without knowing who the validator is and what is his reputation (especially in a UX-unfriendly environment which Polkadot JS is). This process can be actually automated via registrars (at least for the email and social network accounts verification) - see W3F registrar on how its done (or I can explain later on). 2) It's a bit harder to correctly count the APY for a nominator because they are able to select more validators than one (which is actually recommended). So sometimes you are in the active set with one validator, sometimes with the other - and they could have a different amount of total stake and thus a different APY.

Anyways, we would be proud to help with creating the validator dashboard so feel free to contact me.

[dmtrjsg]

Suggested way to address the design issue:

• [ ] Conduct discovery interviews with target users of this feature: @traumschule, @kdembler, @freakstatic and @pmensik would be perfect for this imho, this does not have to take a lot of time and 20 minute chat may just suffice

  Verify the objective of the nominators and validators, what are they trying to achieve and how they are doing it right now, how often they use the interfaces of polkadot and for what use cases

• [ ] Perform competitor research

  and see how the user objectives are met/ problems addressed by competition

• [ ] Create low fi mockups

  Hand/ drawn are fine at this point, or low touch designs that only expose the information architecture on the page

• [ ] Validate the low-fi designs with the technical lead on feasibility of implementation

  @traumschule has expressed interest in this in the past, so would the perfect candidate for assessing the feasbility. All other guys from point 1 could also advise in async mode..

• [ ] Refine the low-fi designs, taking into consideration and present for the attention of the same users + JSG team
• [ ] Obtain confirmation and progress with the hi-fi designs relying on the components adopted in Pioneer already. In some cases feel free to suggest your own components if the design problem you are trying to solve is not currently covered with existing components.

[traumschule]

I was asked in private and will answer here:

what is their job? What are they doing? what's the utility of validators?

Quoting the handbook A validator is an actor which checks the validity of newly constructed blocks, proposes new blocks and participates in the consensus process for committing new blocks to the chain.

is it linked with the council?

The Council has no influence on the set of validators nor their rewards.

are does validators are linked with the concept of validators like in PoS for the chain?

From the handbook again: The Joystream platform state lives on a blockchain consensus system. This consensus system is a variant of classical BFT consensus combined with Proof-of-Stake to determine who gets to be a consensus participant, i.e. validator.

and so people need to delegate their tokens to validators? like for optimism for example?

This is also explained on a dedicated handbook page.

Additionally i gave a detailed response here and am open for more specific questions.

[dmtrjsg]

@ninja-fire please try to write up user stories here as a list, which can help to cross check with the designs you've put together in figma, and break it down for development once the designs are signed off 👍

[ninja-fire]

yes I'll do it when I'll have validated a more advanced version of the user stories. Right now it is too early and may just create confusion.

[ninja-fire]

here is the link for the current designs: https://www.figma.com/file/tjad3r2EZJXRMFOELcxxNR/Validators?node-id=5-1550

[dmtrjsg]

Development of this feature is tracked here:

• 4321