-
Notifications
You must be signed in to change notification settings - Fork 1
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
base: master
Are you sure you want to change the base?
Conversation
CrackTheCode016
commented
Sep 18, 2024
…dot-docs into bd-infra-payout
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
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
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. |
There was a problem hiding this comment.
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
``` | ||
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 | ||
``` |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. | ||
|
||
``` |
There was a problem hiding this comment.
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...