Staking/validators page

[jessepinho]

In this PR

• Create Staking page with initial columns. NOTE: There's no "delegate"/"undelegate" button yet; that will come as part of User's delegations #541.
• Add StakingService to the service registry, create a proxy impl for it in service-worker.ts, and create a service client for it in webapp/src/clients/grpc.ts.
• Move the max-width that was shared by a number of pages to the main tag of the root <Layout /> component.
• Add a bunch of getters for validator info.
• Set up UI testing libraries inside webapp (@testing-library/react and @testing-library/jest-dom) along with test setup files and Vitest config.

Closes #540

[jessepinho]

Converting back to draft while I fix the commission

[jessepinho]

OK @grod220 / @turbocrime , this is ready for review again

[hdevalence]

As a general comment, this work is (or should be) entangled with #558: staking in Penumbra is token-based, and the staking UI should reflect that.

This UI shouldn't be centered around a list of validators, it should be centered around a list of tokens, since a user's staking state is represented via tokens. (That's why I opened up #558, to flag that as a problem to solve, but I could have been more explicit about the intent, sorry about that).

OK, but what does it mean for the UI to be centered around tokens?

First, we need to set out what tokens there are. There are three relevant classes of tokens:

1. The staking token UM itself, representing unbonded stake. This is the simplest, since it's just one token.
2. Delegation tokens, representing shares of a particular validator's delegation pool. These are not just one token but a family of tokens, parameterized by the validator identity. (The chain does staking rewards by adjusting the exchange rate between the staking token and each delegation token).
3. Unbonding tokens, representing stake that was delegated to a particular validator but is in the process of being undelegated. These have even more variety than delegation tokens: they're parameterized both by the validator identity and the epoch at which unbonding started. (In the happy path, unbonding tokens are 1:1 with the staking token, but the chain delays conversion to allow slashing if the validator were to misbehave during the unbonding period).

Rendering the user's staking state requires handling all of these tokens. However, because these tokens are how that state is recorded, it does not require any more than handling these three classes of tokens.

I'd suggest the following organization for the staking page. There should be several tabular blocks, showing each of these categories of tokens. Each row should have staking-specific rendering (ie additional contextual information) of the user's balance of a particular token.

The first block should be titled "Unstaked Tokens" and have one row, showing the user's balance of the UM token.

The second block should be titled "Staked Tokens" and have one row for each delegation token for which the user has a nonzero balance. If there are no rows, the block should be omitted. Each row should show the amount of delegation tokens, the equivalent amount of staking tokens and USD (this functionality being provided by the equivalent_values feature in the valueview, which the extension needs to but does not yet implement), information about the validator, and buttons for "Delegate" and "Undelegate".

The third block should be titled "Unbonding Tokens" and have one row for each unbonding token for which the user has a nonzero balance. If there are no rows, the block should be omitted. Each row should show the amount of unbonding tokens (initially we can ignore penalties and treat these as 1:1 for UM tokens), information about the validator, and a time-based estimate of when unbonding will finish. The row should have a button labeled "Claim" that does the UndelegateClaim, this should be disabled until unbonding is believed to be finished.

The fourth block should be labeled "Active Validators" and have one row for each active validator, excepting validators the user already has delegations to. Each row should be identical to the rows used for the "Staked Tokens" block, the only difference being that the rows are rendering a 0-balance of that validator's delegation token and so should have a disabled "Undelegate" button.

This UI shows a complete picture of the user's staking state, which is recorded by tokens, shows them the most relevant information (their balances and delegations) first, and provides convenient hooks for all staking-related actions.

[grod220]

I feel this comment is best placed in the very next task that is currently being worked on: #463

This UI shouldn't be centered around a list of validators, it should be centered around a list of tokens

In general, this feels like you are saying something was built incorrectly and something is wrong. But, really, this page is simply not complete. We have follow up issues specifically for the user's positions and taking actions. We really can't expect a user to be able to take an action without being able to pull a list of validators they can delegate to.

[hdevalence]

This UI shouldn't be centered around a list of validators, it should be centered around a list of tokens

In general, this feels like you are saying something was built incorrectly and something is wrong. But, really, this page is simply not complete.

Yes, I am trying to draw attention at an early stage to the fact that it is not just a matter of completeness but that we are starting out by building in the wrong direction, and need to change course.

Our goal is to show a list of tokens, not a list of validators.

We have follow up issues specifically for the user's positions and taking actions. We really can't expect a user to be able to take an action without being able to pull a list of validators they can delegate to.

Again, the problem is that we need to be rendering a list of tokens, not a list of validators. That's the conceptual change I am trying to explicitly highlight here. Having a list of validators doesn't directly help us, because what we need is rendering of delegation tokens.

We can of course use this code as a starting point for "what does a staking-specific rendering of a delegation token row look like", but it is important to get consensus that that is the problem to solve.

[jessepinho]

Thanks @grod220 / @hdevalence. It seems like I've built the "Active Validators" block except for its delegate buttons. My suggestion:

1. I'll add delegate buttons as part of User's delegations #541.
2. I'll create additional tickets for each of the remaining blocks described above.

[hdevalence]

Yep, that sounds great. In that refactoring it would be good to refactor into a component that takes BOTH:

• a ValueView of the delegation token
• additional validator data

and reconceptualize it as being a rendering of the delegation token amount. We should be planning to use the asset Metadata to render the delegation tokens for the reasons discussed in #558 — it's important that we have consistent rendering of delegation tokens.