Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Polkadot Wiki Migration] Validator Payout #42

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

CrackTheCode016
Copy link
Collaborator

@dawnkelly09 dawnkelly09 requested a review from a team as a code owner October 3, 2024 19:41
@dawnkelly09
Copy link
Collaborator

All I did was merge master into this to resolve merge conflicts but it triggered a content team review I can't cancel. Sorry about that!

- Producing a referenced uncle block

!!!note
An uncle block is a Relay Chain block that is valid in every regard, but which failed to become canonical. This can happen when two or more validators are block producers in a single slot, and the block produced by one validator reaches the next block producer before the others. We call the lagging blocks uncle blocks.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
An uncle block is a Relay Chain block that is valid in every regard, but which failed to become canonical. This can happen when two or more validators are block producers in a single slot, and the block produced by one validator reaches the next block producer before the others. We call the lagging blocks uncle blocks.
An uncle block is a Relay Chain block that is valid in every regard but has failed to become canonical. This can happen when two or more validators are block producers in a single slot, and the block produced by one validator reaches the next block producer before the others. The lagging blocks are called uncle blocks.


Era points create a probabilistic component for staking rewards.

If the mean of staking rewards is the average rewards per era, then the variance is the variability from the average staking rewards. The exact DOT value of each era point is not known in advance since it depends on the total number of points earned by all validators in a given era. This is designed this way so that the total payout per era depends on Polkadot's [inflation model](), and not on the number of payable actions (for example, authoring a new block) executed. For more information, read this StackExchange post about [reward calculations](https://substrate.stackexchange.com/questions/5353/how-are-rewards-in-dot-calculated-from-the-era-points-earned-by-validators-in-po).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If the mean of staking rewards is the average rewards per era, then the variance is the variability from the average staking rewards. The exact DOT value of each era point is not known in advance since it depends on the total number of points earned by all validators in a given era. This is designed this way so that the total payout per era depends on Polkadot's [inflation model](), and not on the number of payable actions (for example, authoring a new block) executed. For more information, read this StackExchange post about [reward calculations](https://substrate.stackexchange.com/questions/5353/how-are-rewards-in-dot-calculated-from-the-era-points-earned-by-validators-in-po).
If the mean of staking rewards is the average rewards per era, then the variance is the variability from the average staking rewards. The exact DOT value of each era point is not known in advance since it depends on the total number of points earned by all validators in a given era. This is designed this way so that the total payout per era depends on Polkadot's [inflation model](), and not on the number of payable actions (for example, authoring a new block) executed. For more information, read the [How are rewards in dot calculated from the era point](https://substrate.stackexchange.com/questions/5353/how-are-rewards-in-dot-calculated-from-the-era-points-earned-by-validators-in-po) post.


If the mean of staking rewards is the average rewards per era, then the variance is the variability from the average staking rewards. The exact DOT value of each era point is not known in advance since it depends on the total number of points earned by all validators in a given era. This is designed this way so that the total payout per era depends on Polkadot's [inflation model](), and not on the number of payable actions (for example, authoring a new block) executed. For more information, read this StackExchange post about [reward calculations](https://substrate.stackexchange.com/questions/5353/how-are-rewards-in-dot-calculated-from-the-era-points-earned-by-validators-in-po).

With parachains now on Polkadot, a large percentage of era points will come from parachain validation, as a subset of validators are selected to para-validate for all parachains each epoch, and those para-validators can generate more era points as a result. Para-validators are rewarded 20 era points each for each parachain block that they validate.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably this was written when parachains went live. I'd paraphrase this a bit since they have been a reality for some time now

Comment on lines 56 to 59
Then, `v` ↑ if `w` ↑, as this reduces `p` : `w`, with respect to `e`.

Increased `v` is expected, and initially keeping `p` ↓ using the same para-validator set
for all parachains ensures [availability]() and [voting](../learn/learn-polkadot-opengov.md). In addition, despite `v` ↑ on an `e` to `e` basis, over time, the amount of rewards each validator receives will equal out based on the continuous selection of para-validators.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it would be better for readability to also explicitly write down these relationships, not just use arrows and icons. However, I do like the arrows, so I'd keep both since I believe they are easier to remember

Comment on lines 103 to 128
```
Validator Set Size (v): 4
Validator 1 Stake (v1): 18 DOT <- Your validator
Validator 2 Stake (v2): 9 DOT
Validator 3 Stake (v3): 8 DOT
Validator 4 Stake (v4): 7 DOT
Payout (p): 8 DOT

Your payout = (p / v) * 1 = (8 / 4) * 1 = 2
```

Running two validators, and splitting the stake equally, would result in the original validator `v4`
to be kicked out of the validator set, as only the top `v` validators (as measured by stake) are
selected to be in the validator set. More important, it would also double the reward that you get
from each era.

```
Validator Set Size (v): 4
Validator 1 Stake (v1): 9 DOT <- Your first validator
Validator 2 Stake (v2): 9 DOT <- Your second validator
Validator 3 Stake (v3): 9 DOT
Validator 4 Stake (v4): 8 DOT
Payout (p): 8 DOT

Your payout = (p / v) * 2 = (8 / 4) * 2 = 4
```
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be helpful to add a distinguishing factor for the second set of validators (v1, v2, v3, v4). I was thinking of using something like:

  • v1'
  • v2'
  • v3'
  • v4'

This way, users can better understand the changes from the original v1 to the new v1' and how they relate to v4 and v4'.

and 100% commission means that the validator operator gets all rewards and gives none to its
nominators.

In the following examples, we can see the results of several different validator payment schemes and
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you are using DOT in these examples, I'd add a small note or sentence that explains that these example are thought for polkadot relay chain that uses DOT as native token

having a low or non-existent validator payment may attract more stake from nominators, since they
know they will receive a larger reward.

```
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still unsure if this would look nicer in a table format...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants