From b537e7b96efadb7865dfb02ee6843208f1be1d0c Mon Sep 17 00:00:00 2001 From: goooooproject Date: Sat, 17 Jun 2023 15:44:37 +0300 Subject: [PATCH 01/35] add new page --- .DS_Store | Bin 0 -> 6148 bytes validator_revard.md | 191 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 191 insertions(+) create mode 100644 .DS_Store create mode 100644 validator_revard.md diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..6dd7e65f841dd0101cc31e7d450dfe1d309b9503 GIT binary patch literal 6148 zcmeHK%TB^T6g{KF@JI|B6XU8&H<u2~;et>_Y=gv$> zDRpa%-rL+c)9IW$b5GNm4gk~KMz=s6K$$LBs4cG`F1Zb;&+>1gY5SkW6mqamhBC!SRY{dFpo#Wc|0UbmW+G)^`|w~fGa#( z#u5>xSaL0BV8QiZfg#Jp#!1*?!uo)%H}ohM^F0^y95cpR?YSdHTJtL4nr@C;K^JY@ zp@j~yi1CqQ)EIe8J+_?Tl$q~}ST^ssOx{)W@W?Sb9IK0dAxHAca?Uu?j=m9n4mGfO zWcyY)pEWg|QMda&@dMi(CUmH!DxeA+Dsbv<>$3m1zd!#UlJrg$PzC;!0;bgJwVF)H z@2yA4$zB`KpXg%JFLh`sEc|wCE3y?|(yj4XAQfWhF?Glmn*In_8MIIZepG=kTC literal 0 HcmV?d00001 diff --git a/validator_revard.md b/validator_revard.md new file mode 100644 index 0000000..b9762e6 --- /dev/null +++ b/validator_revard.md @@ -0,0 +1,191 @@ +Validator Payout Overview + +Reward Calculation +Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. + +Total reward is split among validators and their nominators depending on the number of points they received during the era. Points are added to a validator using reward_by_ids or reward_by_indices. + +Module implements pallet_authorship::EventHandler to add reward points to block producer and block producer of referenced uncles. + +The validator and its nominator split their reward as following: + +The validator can declare an amount, named commission, that does not get shared with the nominators at each reward payout through its ValidatorPrefs. This value gets deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among the validator and all of the nominators that nominated the validator, proportional to the value staked behind this validator (i.e. dividing the own or others by total in Exposure). + +All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: + +Controller account, (obviously) not increasing the staked value. +Stash account, not increasing the staked value. +Stash account, also increasing the staked value. + + +How to calculate individual Nominator and Validator Rewards: + +Shared Validator Set Rewards - THIS ONE DONE BY CHAIN IN THE END OF EACH ERA +In each era, a function of +− totalIssuance.at(lastBlockOfEra) +− erasTotalStake(era) + +erasRewardPoints(era).total += validatorSetRewardInEra +Individual Rewards for each Validator, before split between (vals + noms) +In each era, equal to: +(validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / +erasRewardPoints(era).total) + +slashedInEra(era,stashOfVal) += totalValidatorRewardInEra +Individual Rewards for each Validators (vals + noms) +In each era, equal to: + +valCommission = totalValidatorRewardInEra(era) × commission% / 100 +sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 += totalValidatorRewardInEra(era) × (1 00 − commission%) + +valReward(era) = valCommission + sharedReward × valOwnStake(era) / totalValStake(era) + +nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) + +Era Points + + +For every era (a period of time approximately 6 hours), validators are paid proportionally to the amount of era points they have collected. Era points are reward points earned for payable actions like: + +producing a non-uncle block in the Relay Chain. +producing a reference to a previously unreferenced uncle block. +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. + + +Payments occur at the end of every era. + + +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 joys 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 joystream's inflation model, and not on the number of payable actions (f.e., authoring a new block) executed. + +Payout Scheme +No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on era points, as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras. + +Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. + +Validators will receive staking rewards in the form of the native token of that chain (joystream). + +For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. + +Validator Set Size (v): 4 +Validator 1 Stake (v1): 18 tokens +Validator 2 Stake (v2): 9 tokens +Validator 3 Stake (v3): 8 tokens +Validator 4 Stake (v4): 7 tokens +Payout (p): 8 joys + +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 tokens + +siemma—Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. + + +Running Multiple Validators +It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. + +For the following example, assume you have 18 joys to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 joys in this era. + +Validator Set Size (v): 4 +Validator 1 Stake (v1): 18 joys <- Your validator +Validator 2 Stake (v2): 9 joys +Validator 3 Stake (v3): 8 joys +Validator 4 Stake (v4): 7 joys +Payout (p): 8 joys + +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 joys <- Your first validator +Validator 2 Stake (v2): 9 joys <- Your second validator +Validator 3 Stake (v3): 9 joys +Validator 4 Stake (v4): 8 joys +Payout (p): 8 joys + +Your payout = (p / v) * 2 = (8 / 4) * 2 = 4 + +With enough stake, you could run more than two validators. However, each validator must have enough stake behind it to be in the validator set. + +The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather than static, equilibrium. Potential validators will run different numbers of validators and apply different amounts of stake to them as time goes on, and in response to the actions of other validators on the network. + + +Slashing +Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough joys to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more joys for a validator with 18 joys staked than one with 9 joys staked. + +Running multiple validators does not absolve you of the consequences of misbehavior. Joystream punishes attacks that appear coordinated more severely than individual attacks. You should not, for example, run multiple validators hosted on the same infrastructure. A proper multi-validator configuration would ensure that they do not fail simultaneously. + +Nominators have the incentive to nominate the lowest-staked validator, as this will result in the lowest risk and highest reward. This is due to the fact that while their vulnerability to slashing remains the same (since it is percentage-based), their rewards are higher since they will be a higher proportion of the total stake allocated to that validator. + +To clarify this, let us imagine two validators, v1 and v2. Assume both are in the active set, have commission set to 0%, and are well-behaved. The only difference is that v1 has 90 joys nominating it and v2 only has 10. If you nominate v1, it now has 90 + 10 = 100 joys and you will get 10% of the staking rewards for the next era. If you nominate v2, it now has 10 + 10 = 20 joys nominating it, and you will get 50% of the staking rewards for the next era. In actuality, it would be quite rare to see such a large difference between the stake of validators, but the same principle holds even for smaller differences. If there is a 10% slash of either validator, then you will lose 1 joys in each case. + +CAUTION +If a validator is oversubscribed in an era, staking rewards are distributed only to the the top 512 nominators and the rest of the nominators do not receive any rewards. This is not the case for slashing! Every active nominator of the validator committing slashable offence will be slashed. + + +Nominators and Validator Payments +Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without running a validator node yourself. Validators can choose to keep a percentage of the rewards due to their validator to "reimburse" themselves for the cost of running a validator node. Other than that, all rewards are shared based on the stake behind each validator. This includes the stake of the validator itself, plus any stake bonded by nominators. + +INFO +Validators set their preference as a percentage of the block reward, not an absolute number of joys. joystream's block reward is based on the total amount at stake, with the reward peaking when the amount staked is at 50% of the total supply. The commission is set as the amount taken by the validator; that is, 0% commission means that the validator does not receive any proportion of the rewards besides that owed to it from self-stake, 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 split between nominator and validator stake. We will assume a single nominator for each validator. However, there can be numerous nominators for each validator. Rewards are still distributed proportionally - for example, if the total rewards to be given to nominators is 2 joys, and there are four nominators with equal stake bonded, each will receive 0.5 joys. Note also that a single nominator may stake different validators. + +Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in joys) is listed in brackets ([]) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. + +Validator Set Size (v): 4 +Validator 1 Stake (v1) [20% commission]: 18 joys (9 validator, 9 nominator) +Validator 2 Stake (v2) [40% commission]: 9 joys (3 validator, 6 nominator) +Validator 3 Stake (v3) [10% commission]: 8 joys (4 validator, 4 nominator) +Validator 4 Stake (v4) [ 0% commission]: 6 joys (1 validator, 5 nominator) +Payout (p): 8 joys + +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 joys + +v1: +(0.2 * 2) = 0.4 joys -> validator payment +(2 - 0.4) = 1.6 -> shared between all stake +(9 / 18) * 1.6 = 0.8 -> validator stake share +(9 / 18) * 1.6 = 0.8 -> nominator stake share +v1 validator total reward: 0.4 + 0.8 = 1.2 joys +v1 nominator reward: 0.8 joys + +v2: +(0.4 * 2) = 0.8 joys -> validator payment +(2 - 0.8) = 1.2 -> shared between all stake +(3 / 9) * 1.2 = 0.4 -> validator stake share +(6 / 9) * 1.2 = 0.8 -> nominator stake share +v2 validator total reward: 0.8 + 0.4 = 1.2 joys +v2 nominator reward: 0.8 joys + +v3: +(0.1 * 2) = 0.2 DOT -> validator payment +(2 - 0.2) = 1.8 -> shared between all stake +(4 / 8) * 1.8 = 0.9 -> validator stake share +(4 / 8) * 1.8 = 0.9 -> nominator stake share +v3 validator total reward: 0.2 + 0.9 joys = 1.1 joys +v3 nominator reward: 0.9 joys + +v4: +(0 * 2) = 0 joys -> validator payment +(2 - 0) = 2.0 -> shared between all stake +(1 / 6) * 2 = 0.33 -> validator stake share +(5 / 6) * 2 = 1.67 -> nominator stake share +v4 validator total reward: 0 + 0.33 joys = 0.33 joys +v4 nominator reward: 1.67 joys + + + + +mokhtar, lezek, bedeho, martin from JSG +tomato, 0x2bc, freakstatic, l1.media, siemma from community From dc26a21635a0b25d42d734acafb2584e723bd577 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Mon, 19 Jun 2023 14:36:03 +0300 Subject: [PATCH 02/35] Update validator_revard.md --- validator_revard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/validator_revard.md b/validator_revard.md index b9762e6..15e9df7 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -1,4 +1,4 @@ -Validator Payout Overview +#Validator Payout Overview Reward Calculation Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. From fa116be8bb6dc165c8509fba6a5be37c3529b602 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Mon, 19 Jun 2023 14:39:51 +0300 Subject: [PATCH 03/35] Update validator_revard.md --- validator_revard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/validator_revard.md b/validator_revard.md index 15e9df7..edfb876 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -1,4 +1,4 @@ -#Validator Payout Overview +# Validator Payout Overview Reward Calculation Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. From e16c0dba5bc1fc5ee7e918188983e81c1771b628 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Mon, 19 Jun 2023 14:42:34 +0300 Subject: [PATCH 04/35] Update validator_revard.md --- validator_revard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/validator_revard.md b/validator_revard.md index edfb876..afb12e3 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -1,6 +1,6 @@ # Validator Payout Overview -Reward Calculation +## Reward Calculation Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. Total reward is split among validators and their nominators depending on the number of points they received during the era. Points are added to a validator using reward_by_ids or reward_by_indices. From d176d14ac81d8eae769a9de55dc5cddb496f0b11 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Mon, 19 Jun 2023 14:44:28 +0300 Subject: [PATCH 05/35] Update validator_revard.md --- validator_revard.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index afb12e3..bb5e521 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -7,18 +7,18 @@ Total reward is split among validators and their nominators depending on the num Module implements pallet_authorship::EventHandler to add reward points to block producer and block producer of referenced uncles. -The validator and its nominator split their reward as following: +## The validator and its nominator split their reward as following: The validator can declare an amount, named commission, that does not get shared with the nominators at each reward payout through its ValidatorPrefs. This value gets deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among the validator and all of the nominators that nominated the validator, proportional to the value staked behind this validator (i.e. dividing the own or others by total in Exposure). -All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: +## All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: Controller account, (obviously) not increasing the staked value. Stash account, not increasing the staked value. Stash account, also increasing the staked value. -How to calculate individual Nominator and Validator Rewards: +## How to calculate individual Nominator and Validator Rewards: Shared Validator Set Rewards - THIS ONE DONE BY CHAIN IN THE END OF EACH ERA In each era, a function of From f98c30a523f7332ca8064d260937e8444c9d5e42 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Mon, 19 Jun 2023 14:45:03 +0300 Subject: [PATCH 06/35] Update validator_revard.md --- validator_revard.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index bb5e521..fc9264e 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -11,14 +11,14 @@ Module implements pallet_authorship::EventHandler to add reward points to block The validator can declare an amount, named commission, that does not get shared with the nominators at each reward payout through its ValidatorPrefs. This value gets deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among the validator and all of the nominators that nominated the validator, proportional to the value staked behind this validator (i.e. dividing the own or others by total in Exposure). -## All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: +All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: Controller account, (obviously) not increasing the staked value. Stash account, not increasing the staked value. Stash account, also increasing the staked value. -## How to calculate individual Nominator and Validator Rewards: +How to calculate individual Nominator and Validator Rewards: Shared Validator Set Rewards - THIS ONE DONE BY CHAIN IN THE END OF EACH ERA In each era, a function of From 57afa1aafbac1f452350d49369005d72e2f2c07d Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Tue, 20 Jun 2023 11:09:02 +0300 Subject: [PATCH 07/35] Update validator_revard.md --- validator_revard.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index fc9264e..f1358ab 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -66,7 +66,7 @@ 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 joys 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 joystream's inflation model, and not on the number of payable actions (f.e., authoring a new block) executed. -Payout Scheme +## Payout Scheme No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on era points, as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras. Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. @@ -88,7 +88,7 @@ p / v = 8 / 4 = 2 tokens siemma—Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. -Running Multiple Validators +## Running Multiple Validators It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. For the following example, assume you have 18 joys to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 joys in this era. @@ -118,7 +118,7 @@ With enough stake, you could run more than two validators. However, each validat The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather than static, equilibrium. Potential validators will run different numbers of validators and apply different amounts of stake to them as time goes on, and in response to the actions of other validators on the network. -Slashing +## Slashing Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough joys to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more joys for a validator with 18 joys staked than one with 9 joys staked. Running multiple validators does not absolve you of the consequences of misbehavior. Joystream punishes attacks that appear coordinated more severely than individual attacks. You should not, for example, run multiple validators hosted on the same infrastructure. A proper multi-validator configuration would ensure that they do not fail simultaneously. @@ -131,7 +131,7 @@ CAUTION If a validator is oversubscribed in an era, staking rewards are distributed only to the the top 512 nominators and the rest of the nominators do not receive any rewards. This is not the case for slashing! Every active nominator of the validator committing slashable offence will be slashed. -Nominators and Validator Payments +# Nominators and Validator Payments Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without running a validator node yourself. Validators can choose to keep a percentage of the rewards due to their validator to "reimburse" themselves for the cost of running a validator node. Other than that, all rewards are shared based on the stake behind each validator. This includes the stake of the validator itself, plus any stake bonded by nominators. INFO From 50825c26b858fd2e8c7f98e25b9f2843e3226be1 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Tue, 20 Jun 2023 13:47:55 +0300 Subject: [PATCH 08/35] Update validator_revard.md --- validator_revard.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index f1358ab..f7cc92c 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -1,9 +1,7 @@ # Validator Payout Overview ## Reward Calculation -Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. - -Total reward is split among validators and their nominators depending on the number of points they received during the era. Points are added to a validator using reward_by_ids or reward_by_indices. +Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. Total reward is split among validators and their nominators depending on the number of points they received during the era. Points are added to a validator using reward_by_ids or reward_by_indices. Module implements pallet_authorship::EventHandler to add reward points to block producer and block producer of referenced uncles. From 3710cde14206f6e9c7e2aedf08466a3f995b5498 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Tue, 20 Jun 2023 13:49:47 +0300 Subject: [PATCH 09/35] Update validator_revard.md --- validator_revard.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index f7cc92c..b6f1f26 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -3,8 +3,6 @@ ## Reward Calculation Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. Total reward is split among validators and their nominators depending on the number of points they received during the era. Points are added to a validator using reward_by_ids or reward_by_indices. -Module implements pallet_authorship::EventHandler to add reward points to block producer and block producer of referenced uncles. - ## The validator and its nominator split their reward as following: The validator can declare an amount, named commission, that does not get shared with the nominators at each reward payout through its ValidatorPrefs. This value gets deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among the validator and all of the nominators that nominated the validator, proportional to the value staked behind this validator (i.e. dividing the own or others by total in Exposure). From ee8bba7f1fc23f5e52a689485c172ba7280a8fc9 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Wed, 21 Jun 2023 12:01:40 +0300 Subject: [PATCH 10/35] Update validator_revard.md Document formatting --- validator_revard.md | 27 ++++++--------------------- 1 file changed, 6 insertions(+), 21 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index b6f1f26..267bfdf 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -7,14 +7,13 @@ Validators and nominators are rewarded at the end of each era. The total reward The validator can declare an amount, named commission, that does not get shared with the nominators at each reward payout through its ValidatorPrefs. This value gets deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among the validator and all of the nominators that nominated the validator, proportional to the value staked behind this validator (i.e. dividing the own or others by total in Exposure). -All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: +## All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: Controller account, (obviously) not increasing the staked value. Stash account, not increasing the staked value. Stash account, also increasing the staked value. - -How to calculate individual Nominator and Validator Rewards: +## How to calculate individual Nominator and Validator Rewards: Shared Validator Set Rewards - THIS ONE DONE BY CHAIN IN THE END OF EACH ERA In each era, a function of @@ -43,21 +42,17 @@ nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) Era Points - For every era (a period of time approximately 6 hours), validators are paid proportionally to the amount of era points they have collected. Era points are reward points earned for payable actions like: producing a non-uncle block in the Relay Chain. producing a reference to a previously unreferenced uncle block. producing a referenced uncle block. - -NOTE +### 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. - Payments occur at the end of every era. - 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 joys 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 joystream's inflation model, and not on the number of payable actions (f.e., authoring a new block) executed. @@ -81,8 +76,7 @@ Payout (p): 8 joys Payout for each validator (v1 - v4): p / v = 8 / 4 = 2 tokens -siemma—Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. - +Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. ## Running Multiple Validators It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. @@ -113,7 +107,6 @@ With enough stake, you could run more than two validators. However, each validat The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather than static, equilibrium. Potential validators will run different numbers of validators and apply different amounts of stake to them as time goes on, and in response to the actions of other validators on the network. - ## Slashing Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough joys to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more joys for a validator with 18 joys staked than one with 9 joys staked. @@ -123,17 +116,15 @@ Nominators have the incentive to nominate the lowest-staked validator, as this w To clarify this, let us imagine two validators, v1 and v2. Assume both are in the active set, have commission set to 0%, and are well-behaved. The only difference is that v1 has 90 joys nominating it and v2 only has 10. If you nominate v1, it now has 90 + 10 = 100 joys and you will get 10% of the staking rewards for the next era. If you nominate v2, it now has 10 + 10 = 20 joys nominating it, and you will get 50% of the staking rewards for the next era. In actuality, it would be quite rare to see such a large difference between the stake of validators, but the same principle holds even for smaller differences. If there is a 10% slash of either validator, then you will lose 1 joys in each case. -CAUTION +### CAUTION If a validator is oversubscribed in an era, staking rewards are distributed only to the the top 512 nominators and the rest of the nominators do not receive any rewards. This is not the case for slashing! Every active nominator of the validator committing slashable offence will be slashed. - # Nominators and Validator Payments Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without running a validator node yourself. Validators can choose to keep a percentage of the rewards due to their validator to "reimburse" themselves for the cost of running a validator node. Other than that, all rewards are shared based on the stake behind each validator. This includes the stake of the validator itself, plus any stake bonded by nominators. -INFO +### INFO Validators set their preference as a percentage of the block reward, not an absolute number of joys. joystream's block reward is based on the total amount at stake, with the reward peaking when the amount staked is at 50% of the total supply. The commission is set as the amount taken by the validator; that is, 0% commission means that the validator does not receive any proportion of the rewards besides that owed to it from self-stake, 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 split between nominator and validator stake. We will assume a single nominator for each validator. However, there can be numerous nominators for each validator. Rewards are still distributed proportionally - for example, if the total rewards to be given to nominators is 2 joys, and there are four nominators with equal stake bonded, each will receive 0.5 joys. Note also that a single nominator may stake different validators. Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in joys) is listed in brackets ([]) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. @@ -179,9 +170,3 @@ v4: (5 / 6) * 2 = 1.67 -> nominator stake share v4 validator total reward: 0 + 0.33 joys = 0.33 joys v4 nominator reward: 1.67 joys - - - - -mokhtar, lezek, bedeho, martin from JSG -tomato, 0x2bc, freakstatic, l1.media, siemma from community From 78f596ebefa20cf17816ec305c7b5efdab7f2c2c Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Wed, 21 Jun 2023 18:11:12 +0300 Subject: [PATCH 11/35] Update validator_revard.md text formatting --- validator_revard.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/validator_revard.md b/validator_revard.md index 267bfdf..ab8f80c 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -67,16 +67,22 @@ Validators will receive staking rewards in the form of the native token of that For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. Validator Set Size (v): 4 + Validator 1 Stake (v1): 18 tokens + Validator 2 Stake (v2): 9 tokens + Validator 3 Stake (v3): 8 tokens + Validator 4 Stake (v4): 7 tokens + Payout (p): 8 joys Payout for each validator (v1 - v4): + p / v = 8 / 4 = 2 tokens -Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. +### Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. ## Running Multiple Validators It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. From 1a7e6bf41a02d22e2b0c79b52febcd874f8ef107 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Wed, 21 Jun 2023 18:18:35 +0300 Subject: [PATCH 12/35] Update validator_revard.md text formatting --- validator_revard.md | 44 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 41 insertions(+), 3 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index ab8f80c..fbb3d64 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -90,26 +90,36 @@ It is possible for a single entity to run multiple validators. Running multiple For the following example, assume you have 18 joys to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 joys in this era. Validator Set Size (v): 4 + Validator 1 Stake (v1): 18 joys <- Your validator + Validator 2 Stake (v2): 9 joys + Validator 3 Stake (v3): 8 joys + Validator 4 Stake (v4): 7 joys + Payout (p): 8 joys -Your payout = (p / v) * 1 = (8 / 4) * 1 = 2— +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. +**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 joys <- Your first validator + Validator 2 Stake (v2): 9 joys <- Your second validator + Validator 3 Stake (v3): 9 joys + Validator 4 Stake (v4): 8 joys + Payout (p): 8 joys Your payout = (p / v) * 2 = (8 / 4) * 2 = 4 -With enough stake, you could run more than two validators. However, each validator must have enough stake behind it to be in the validator set. + ### With enough stake, you could run more than two validators. However, each validator must have enough stake behind it to be in the validator set. The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather than static, equilibrium. Potential validators will run different numbers of validators and apply different amounts of stake to them as time goes on, and in response to the actions of other validators on the network. @@ -136,43 +146,71 @@ In the following examples, we can see the results of several different validator Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in joys) is listed in brackets ([]) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. Validator Set Size (v): 4 + Validator 1 Stake (v1) [20% commission]: 18 joys (9 validator, 9 nominator) + Validator 2 Stake (v2) [40% commission]: 9 joys (3 validator, 6 nominator) + Validator 3 Stake (v3) [10% commission]: 8 joys (4 validator, 4 nominator) + Validator 4 Stake (v4) [ 0% commission]: 6 joys (1 validator, 5 nominator) + Payout (p): 8 joys + Payout for each validator (v1 - v4): + p / v = 8 / 4 = 2 joys + v1: (0.2 * 2) = 0.4 joys -> validator payment + (2 - 0.4) = 1.6 -> shared between all stake + (9 / 18) * 1.6 = 0.8 -> validator stake share (9 / 18) * 1.6 = 0.8 -> nominator stake share + v1 validator total reward: 0.4 + 0.8 = 1.2 joys + v1 nominator reward: 0.8 joys + v2: (0.4 * 2) = 0.8 joys -> validator payment + (2 - 0.8) = 1.2 -> shared between all stake + (3 / 9) * 1.2 = 0.4 -> validator stake share + (6 / 9) * 1.2 = 0.8 -> nominator stake share + v2 validator total reward: 0.8 + 0.4 = 1.2 joys + v2 nominator reward: 0.8 joys v3: (0.1 * 2) = 0.2 DOT -> validator payment + (2 - 0.2) = 1.8 -> shared between all stake (4 / 8) * 1.8 = 0.9 -> validator stake share + (4 / 8) * 1.8 = 0.9 -> nominator stake share + v3 validator total reward: 0.2 + 0.9 joys = 1.1 joys + v3 nominator reward: 0.9 joys + v4: (0 * 2) = 0 joys -> validator payment + (2 - 0) = 2.0 -> shared between all stake + (1 / 6) * 2 = 0.33 -> validator stake share + (5 / 6) * 2 = 1.67 -> nominator stake share + v4 validator total reward: 0 + 0.33 joys = 0.33 joys + v4 nominator reward: 1.67 joys From a0b0f8b261e6601d9f2b3163089692cfd395cf25 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Wed, 21 Jun 2023 18:34:23 +0300 Subject: [PATCH 13/35] Update validator_revard.md text formatting --- validator_revard.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index fbb3d64..390ed7e 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -66,7 +66,7 @@ Validators will receive staking rewards in the form of the native token of that For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. -Validator Set Size (v): 4 +**Validator Set Size (v): 4** Validator 1 Stake (v1): 18 tokens @@ -89,7 +89,7 @@ It is possible for a single entity to run multiple validators. Running multiple For the following example, assume you have 18 joys to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 joys in this era. -Validator Set Size (v): 4 +**Validator Set Size (v): 4** Validator 1 Stake (v1): 18 joys <- Your validator @@ -105,7 +105,7 @@ 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 Set Size (v): 4** Validator 1 Stake (v1): 9 joys <- Your first validator @@ -145,7 +145,7 @@ In the following examples, we can see the results of several different validator Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in joys) is listed in brackets ([]) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. -Validator Set Size (v): 4 +**Validator Set Size (v): 4** Validator 1 Stake (v1) [20% commission]: 18 joys (9 validator, 9 nominator) @@ -157,26 +157,26 @@ Validator 4 Stake (v4) [ 0% commission]: 6 joys (1 validator, 5 nominator) Payout (p): 8 joys - Payout for each validator (v1 - v4): p / v = 8 / 4 = 2 joys +**v1:** -v1: (0.2 * 2) = 0.4 joys -> validator payment (2 - 0.4) = 1.6 -> shared between all stake (9 / 18) * 1.6 = 0.8 -> validator stake share + (9 / 18) * 1.6 = 0.8 -> nominator stake share v1 validator total reward: 0.4 + 0.8 = 1.2 joys v1 nominator reward: 0.8 joys +**v2:** -v2: (0.4 * 2) = 0.8 joys -> validator payment (2 - 0.8) = 1.2 -> shared between all stake @@ -189,10 +189,12 @@ v2 validator total reward: 0.8 + 0.4 = 1.2 joys v2 nominator reward: 0.8 joys -v3: +**v3:** + (0.1 * 2) = 0.2 DOT -> validator payment (2 - 0.2) = 1.8 -> shared between all stake + (4 / 8) * 1.8 = 0.9 -> validator stake share (4 / 8) * 1.8 = 0.9 -> nominator stake share @@ -201,8 +203,8 @@ v3 validator total reward: 0.2 + 0.9 joys = 1.1 joys v3 nominator reward: 0.9 joys +**v4:** -v4: (0 * 2) = 0 joys -> validator payment (2 - 0) = 2.0 -> shared between all stake From 5311332a6db0ad6b989548de44090334af59e939 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Wed, 21 Jun 2023 18:47:02 +0300 Subject: [PATCH 14/35] Update validator_revard.md text formatting --- validator_revard.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index 390ed7e..53fa191 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -15,25 +15,37 @@ Stash account, also increasing the staked value. ## How to calculate individual Nominator and Validator Rewards: -Shared Validator Set Rewards - THIS ONE DONE BY CHAIN IN THE END OF EACH ERA -In each era, a function of +Shared Validator Set Rewards - **THIS ONE DONE BY CHAIN IN THE END OF EACH ERA** In each era, a function of + − totalIssuance.at(lastBlockOfEra) + − erasTotalStake(era) erasRewardPoints(era).total + = validatorSetRewardInEra + Individual Rewards for each Validator, before split between (vals + noms) + In each era, equal to: + (validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / + erasRewardPoints(era).total) + slashedInEra(era,stashOfVal) + = totalValidatorRewardInEra + Individual Rewards for each Validators (vals + noms) + In each era, equal to: valCommission = totalValidatorRewardInEra(era) × commission% / 100 + sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 + = totalValidatorRewardInEra(era) × (1 00 − commission%) valReward(era) = valCommission + sharedReward × valOwnStake(era) / totalValStake(era) From f3049a15c7132aaccd30d4f7e6e7f5bebd6f8fc6 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Wed, 21 Jun 2023 18:51:40 +0300 Subject: [PATCH 15/35] Update validator_revard.md text formatting --- validator_revard.md | 109 ++++++++++++++++---------------------------- 1 file changed, 39 insertions(+), 70 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index 53fa191..a89068a 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -157,74 +157,43 @@ In the following examples, we can see the results of several different validator Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in joys) is listed in brackets ([]) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. -**Validator Set Size (v): 4** - -Validator 1 Stake (v1) [20% commission]: 18 joys (9 validator, 9 nominator) - -Validator 2 Stake (v2) [40% commission]: 9 joys (3 validator, 6 nominator) - -Validator 3 Stake (v3) [10% commission]: 8 joys (4 validator, 4 nominator) - -Validator 4 Stake (v4) [ 0% commission]: 6 joys (1 validator, 5 nominator) - -Payout (p): 8 joys - -Payout for each validator (v1 - v4): - -p / v = 8 / 4 = 2 joys - -**v1:** - -(0.2 * 2) = 0.4 joys -> validator payment - -(2 - 0.4) = 1.6 -> shared between all stake - -(9 / 18) * 1.6 = 0.8 -> validator stake share - -(9 / 18) * 1.6 = 0.8 -> nominator stake share - -v1 validator total reward: 0.4 + 0.8 = 1.2 joys - -v1 nominator reward: 0.8 joys - -**v2:** - -(0.4 * 2) = 0.8 joys -> validator payment - -(2 - 0.8) = 1.2 -> shared between all stake - -(3 / 9) * 1.2 = 0.4 -> validator stake share - -(6 / 9) * 1.2 = 0.8 -> nominator stake share - -v2 validator total reward: 0.8 + 0.4 = 1.2 joys - -v2 nominator reward: 0.8 joys - -**v3:** - -(0.1 * 2) = 0.2 DOT -> validator payment - -(2 - 0.2) = 1.8 -> shared between all stake - -(4 / 8) * 1.8 = 0.9 -> validator stake share - -(4 / 8) * 1.8 = 0.9 -> nominator stake share - -v3 validator total reward: 0.2 + 0.9 joys = 1.1 joys - -v3 nominator reward: 0.9 joys - -**v4:** - -(0 * 2) = 0 joys -> validator payment - -(2 - 0) = 2.0 -> shared between all stake - -(1 / 6) * 2 = 0.33 -> validator stake share - -(5 / 6) * 2 = 1.67 -> nominator stake share - -v4 validator total reward: 0 + 0.33 joys = 0.33 joys - +**Validator Set Size (v): 4** +Validator 1 Stake (v1) [20% commission]: 18 joys (9 validator, 9 nominator) +Validator 2 Stake (v2) [40% commission]: 9 joys (3 validator, 6 nominator) +Validator 3 Stake (v3) [10% commission]: 8 joys (4 validator, 4 nominator) +Validator 4 Stake (v4) [ 0% commission]: 6 joys (1 validator, 5 nominator) +Payout (p): 8 joys +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 joys + +**v1:** +(0.2 * 2) = 0.4 joys -> validator payment +(2 - 0.4) = 1.6 -> shared between all stake +(9 / 18) * 1.6 = 0.8 -> validator stake share +(9 / 18) * 1.6 = 0.8 -> nominator stake share +v1 validator total reward: 0.4 + 0.8 = 1.2 joys +v1 nominator reward: 0.8 joys + +**v2:** +(0.4 * 2) = 0.8 joys -> validator payment +(2 - 0.8) = 1.2 -> shared between all stake +(3 / 9) * 1.2 = 0.4 -> validator stake share +(6 / 9) * 1.2 = 0.8 -> nominator stake share +v2 validator total reward: 0.8 + 0.4 = 1.2 joys +v2 nominator reward: 0.8 joys + +**v3:** +(0.1 * 2) = 0.2 DOT -> validator payment +(2 - 0.2) = 1.8 -> shared between all stake +(4 / 8) * 1.8 = 0.9 -> validator stake share +(4 / 8) * 1.8 = 0.9 -> nominator stake share +v3 validator total reward: 0.2 + 0.9 joys = 1.1 joys +v3 nominator reward: 0.9 joys + +**v4:** +(0 * 2) = 0 joys -> validator payment +(2 - 0) = 2.0 -> shared between all stake +(1 / 6) * 2 = 0.33 -> validator stake share +(5 / 6) * 2 = 1.67 -> nominator stake share +v4 validator total reward: 0 + 0.33 joys = 0.33 joys v4 nominator reward: 1.67 joys From 52cd6e77465d553cb08b7afe182954c64c5e1455 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Wed, 21 Jun 2023 18:55:12 +0300 Subject: [PATCH 16/35] Update validator_revard.md text formatting --- validator_revard.md | 107 +++++++++++++++----------------------------- 1 file changed, 37 insertions(+), 70 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index a89068a..f7493d8 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -13,44 +13,26 @@ Controller account, (obviously) not increasing the staked value. Stash account, not increasing the staked value. Stash account, also increasing the staked value. -## How to calculate individual Nominator and Validator Rewards: - -Shared Validator Set Rewards - **THIS ONE DONE BY CHAIN IN THE END OF EACH ERA** In each era, a function of - -− totalIssuance.at(lastBlockOfEra) - -− erasTotalStake(era) - -erasRewardPoints(era).total - -= validatorSetRewardInEra - -Individual Rewards for each Validator, before split between (vals + noms) - -In each era, equal to: - -(validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / - -erasRewardPoints(era).total) - - -slashedInEra(era,stashOfVal) - -= totalValidatorRewardInEra - -Individual Rewards for each Validators (vals + noms) - -In each era, equal to: - -valCommission = totalValidatorRewardInEra(era) × commission% / 100 - -sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 - -= totalValidatorRewardInEra(era) × (1 00 − commission%) - -valReward(era) = valCommission + sharedReward × valOwnStake(era) / totalValStake(era) - -nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) +## How to calculate individual Nominator and Validator Rewards: +Shared Validator Set Rewards - **THIS ONE DONE BY CHAIN IN THE END OF EACH ERA** In each era, a function of +− totalIssuance.at(lastBlockOfEra) +− erasTotalStake(era) +erasRewardPoints(era).total += validatorSetRewardInEra +Individual Rewards for each Validator, before split between (vals + noms) +In each era, equal to: +(validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / +erasRewardPoints(era).total) + +slashedInEra(era,stashOfVal) += totalValidatorRewardInEra +Individual Rewards for each Validators (vals + noms) +In each era, equal to: +valCommission = totalValidatorRewardInEra(era) × commission% / 100 +sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 += totalValidatorRewardInEra(era) × (1 00 − commission%) +valReward(era) = valCommission + sharedReward × valOwnStake(era) / totalValStake(era) +nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) Era Points @@ -78,17 +60,12 @@ Validators will receive staking rewards in the form of the native token of that For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. -**Validator Set Size (v): 4** - -Validator 1 Stake (v1): 18 tokens - -Validator 2 Stake (v2): 9 tokens - -Validator 3 Stake (v3): 8 tokens - -Validator 4 Stake (v4): 7 tokens - -Payout (p): 8 joys +**Validator Set Size (v): 4** +Validator 1 Stake (v1): 18 tokens +Validator 2 Stake (v2): 9 tokens +Validator 3 Stake (v3): 8 tokens +Validator 4 Stake (v4): 7 tokens +Payout (p): 8 joys Payout for each validator (v1 - v4): @@ -101,33 +78,23 @@ It is possible for a single entity to run multiple validators. Running multiple For the following example, assume you have 18 joys to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 joys in this era. -**Validator Set Size (v): 4** - -Validator 1 Stake (v1): 18 joys <- Your validator - -Validator 2 Stake (v2): 9 joys - -Validator 3 Stake (v3): 8 joys - -Validator 4 Stake (v4): 7 joys - +**Validator Set Size (v): 4** +Validator 1 Stake (v1): 18 joys <- Your validator +Validator 2 Stake (v2): 9 joys +Validator 3 Stake (v3): 8 joys +Validator 4 Stake (v4): 7 joys Payout (p): 8 joys 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 joys <- Your first validator - -Validator 2 Stake (v2): 9 joys <- Your second validator - -Validator 3 Stake (v3): 9 joys - -Validator 4 Stake (v4): 8 joys - -Payout (p): 8 joys +**Validator Set Size (v): 4** +Validator 1 Stake (v1): 9 joys <- Your first validator +Validator 2 Stake (v2): 9 joys <- Your second validator +Validator 3 Stake (v3): 9 joys +Validator 4 Stake (v4): 8 joys +Payout (p): 8 joys Your payout = (p / v) * 2 = (8 / 4) * 2 = 4 From dd5632183f0194edddc50c23a3a336d6a1cd1b66 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Wed, 21 Jun 2023 18:59:10 +0300 Subject: [PATCH 17/35] Update validator_revard.md text formatting --- validator_revard.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index f7493d8..af61180 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -13,21 +13,26 @@ Controller account, (obviously) not increasing the staked value. Stash account, not increasing the staked value. Stash account, also increasing the staked value. -## How to calculate individual Nominator and Validator Rewards: +## How to calculate individual Nominator and Validator Rewards: + Shared Validator Set Rewards - **THIS ONE DONE BY CHAIN IN THE END OF EACH ERA** In each era, a function of − totalIssuance.at(lastBlockOfEra) -− erasTotalStake(era) +− erasTotalStake(era) + erasRewardPoints(era).total -= validatorSetRewardInEra += validatorSetRewardInEra + Individual Rewards for each Validator, before split between (vals + noms) In each era, equal to: (validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / erasRewardPoints(era).total) slashedInEra(era,stashOfVal) -= totalValidatorRewardInEra += totalValidatorRewardInEra + Individual Rewards for each Validators (vals + noms) -In each era, equal to: +In each era, equal to: + valCommission = totalValidatorRewardInEra(era) × commission% / 100 sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 = totalValidatorRewardInEra(era) × (1 00 − commission%) From 9bcb4ff0ead47cb684552313b5a7fa1c20767ea5 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Thu, 22 Jun 2023 10:15:34 +0300 Subject: [PATCH 18/35] Update validator_revard.md text formatting --- validator_revard.md | 49 +++++++++++++++++++-------------------------- 1 file changed, 21 insertions(+), 28 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index af61180..faedd0e 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -15,32 +15,34 @@ Stash account, also increasing the staked value. ## How to calculate individual Nominator and Validator Rewards: -Shared Validator Set Rewards - **THIS ONE DONE BY CHAIN IN THE END OF EACH ERA** In each era, a function of +Shared Validator Set Rewards - **THIS ONE DONE BY CHAIN IN THE END OF EACH ERA** In each era, a function of + − totalIssuance.at(lastBlockOfEra) − erasTotalStake(era) -erasRewardPoints(era).total + **erasRewardPoints(era).total** = validatorSetRewardInEra -Individual Rewards for each Validator, before split between (vals + noms) -In each era, equal to: -(validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / -erasRewardPoints(era).total) +Individual Rewards for each Validator, before split between (vals + noms) +In each era, equal to: +(validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / +erasRewardPoints(era).total) -slashedInEra(era,stashOfVal) + **slashedInEra(era,stashOfVal)** = totalValidatorRewardInEra Individual Rewards for each Validators (vals + noms) -In each era, equal to: +In each era, equal to: -valCommission = totalValidatorRewardInEra(era) × commission% / 100 -sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 -= totalValidatorRewardInEra(era) × (1 00 − commission%) -valReward(era) = valCommission + sharedReward × valOwnStake(era) / totalValStake(era) -nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) +valCommission = totalValidatorRewardInEra(era) × commission% / 100 +sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 += totalValidatorRewardInEra(era) × (1 00 − commission%) -Era Points +valReward(era) = valCommission + sharedReward × valOwnStake(era) / totalValStake(era) +nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) + +### Era Points For every era (a period of time approximately 6 hours), validators are paid proportionally to the amount of era points they have collected. Era points are reward points earned for payable actions like: producing a non-uncle block in the Relay Chain. @@ -48,21 +50,14 @@ producing a reference to a previously unreferenced uncle block. 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. - -Payments occur at the end of every era. - -Era points create a probabilistic component for staking rewards. - +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. 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 joys 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 joystream's inflation model, and not on the number of payable actions (f.e., authoring a new block) executed. ## Payout Scheme No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on era points, as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras. -Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. - -Validators will receive staking rewards in the form of the native token of that chain (joystream). - +Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. +Validators will receive staking rewards in the form of the native token of that chain (joystream). For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. **Validator Set Size (v): 4** @@ -72,15 +67,13 @@ Validator 3 Stake (v3): 8 tokens Validator 4 Stake (v4): 7 tokens Payout (p): 8 joys -Payout for each validator (v1 - v4): - +Payout for each validator (v1 - v4): p / v = 8 / 4 = 2 tokens ### Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. ## Running Multiple Validators -It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. - +It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. For the following example, assume you have 18 joys to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 joys in this era. **Validator Set Size (v): 4** From 1133f287a0a78f8bc67dc84c50b54387038d7f8b Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Thu, 22 Jun 2023 13:47:28 +0300 Subject: [PATCH 19/35] Update validator_revard.md text formatting --- validator_revard.md | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index faedd0e..2036109 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -9,9 +9,9 @@ The validator can declare an amount, named commission, that does not get shared ## All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: -Controller account, (obviously) not increasing the staked value. -Stash account, not increasing the staked value. -Stash account, also increasing the staked value. +Controller account, (obviously) not increasing the staked value. +Stash account, not increasing the staked value. +Stash account, also increasing the staked value. ## How to calculate individual Nominator and Validator Rewards: @@ -45,9 +45,9 @@ nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) ### Era Points For every era (a period of time approximately 6 hours), validators are paid proportionally to the amount of era points they have collected. Era points are reward points earned for payable actions like: -producing a non-uncle block in the Relay Chain. -producing a reference to a previously unreferenced uncle block. -producing a referenced uncle block. +producing a non-uncle block in the Relay Chain. +producing a reference to a previously unreferenced uncle block. +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. Era points create a probabilistic component for staking rewards. @@ -66,7 +66,6 @@ Validator 2 Stake (v2): 9 tokens Validator 3 Stake (v3): 8 tokens Validator 4 Stake (v4): 7 tokens Payout (p): 8 joys - Payout for each validator (v1 - v4): p / v = 8 / 4 = 2 tokens @@ -82,7 +81,6 @@ Validator 2 Stake (v2): 9 joys Validator 3 Stake (v3): 8 joys Validator 4 Stake (v4): 7 joys Payout (p): 8 joys - 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.** @@ -93,7 +91,6 @@ Validator 2 Stake (v2): 9 joys <- Your second validator Validator 3 Stake (v3): 9 joys Validator 4 Stake (v4): 8 joys Payout (p): 8 joys - Your payout = (p / v) * 2 = (8 / 4) * 2 = 4 ### With enough stake, you could run more than two validators. However, each validator must have enough stake behind it to be in the validator set. From abfdc0c76b059be299d5121ba1fcee6a2344caba Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Thu, 22 Jun 2023 19:47:45 +0300 Subject: [PATCH 20/35] Update validator_revard.md text formatting --- validator_revard.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/validator_revard.md b/validator_revard.md index 2036109..4f0953b 100644 --- a/validator_revard.md +++ b/validator_revard.md @@ -56,9 +56,9 @@ If the mean of staking rewards is the average rewards per era, then the variance ## Payout Scheme No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on era points, as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras. -Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. -Validators will receive staking rewards in the form of the native token of that chain (joystream). -For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. +Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. +Validators will receive staking rewards in the form of the native token of that chain (joystream). +For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. **Validator Set Size (v): 4** Validator 1 Stake (v1): 18 tokens From bccc60db8bed949c041be522116b2c80f1d0730b Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Thu, 29 Jun 2023 20:47:43 +0300 Subject: [PATCH 21/35] Create read.me --- system/validator_revard/read.me | 1 + 1 file changed, 1 insertion(+) create mode 100644 system/validator_revard/read.me diff --git a/system/validator_revard/read.me b/system/validator_revard/read.me new file mode 100644 index 0000000..5e37295 --- /dev/null +++ b/system/validator_revard/read.me @@ -0,0 +1 @@ +Hellow world From e1a6ec5a2a9e6db7e557cf66a07cacb2093ca622 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Thu, 29 Jun 2023 21:29:27 +0300 Subject: [PATCH 22/35] Add files via upload --- system/validator_revard/validator_revard.md | 161 ++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 system/validator_revard/validator_revard.md diff --git a/system/validator_revard/validator_revard.md b/system/validator_revard/validator_revard.md new file mode 100644 index 0000000..4f0953b --- /dev/null +++ b/system/validator_revard/validator_revard.md @@ -0,0 +1,161 @@ +# Validator Payout Overview + +## Reward Calculation +Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. Total reward is split among validators and their nominators depending on the number of points they received during the era. Points are added to a validator using reward_by_ids or reward_by_indices. + +## The validator and its nominator split their reward as following: + +The validator can declare an amount, named commission, that does not get shared with the nominators at each reward payout through its ValidatorPrefs. This value gets deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among the validator and all of the nominators that nominated the validator, proportional to the value staked behind this validator (i.e. dividing the own or others by total in Exposure). + +## All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: + +Controller account, (obviously) not increasing the staked value. +Stash account, not increasing the staked value. +Stash account, also increasing the staked value. + +## How to calculate individual Nominator and Validator Rewards: + +Shared Validator Set Rewards - **THIS ONE DONE BY CHAIN IN THE END OF EACH ERA** In each era, a function of + +− totalIssuance.at(lastBlockOfEra) +− erasTotalStake(era) + + **erasRewardPoints(era).total** += validatorSetRewardInEra + +Individual Rewards for each Validator, before split between (vals + noms) +In each era, equal to: +(validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / +erasRewardPoints(era).total) + + **slashedInEra(era,stashOfVal)** += totalValidatorRewardInEra + +Individual Rewards for each Validators (vals + noms) +In each era, equal to: + +valCommission = totalValidatorRewardInEra(era) × commission% / 100 +sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 += totalValidatorRewardInEra(era) × (1 00 − commission%) + +valReward(era) = valCommission + sharedReward × valOwnStake(era) / totalValStake(era) + +nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) + +### Era Points +For every era (a period of time approximately 6 hours), validators are paid proportionally to the amount of era points they have collected. Era points are reward points earned for payable actions like: + +producing a non-uncle block in the Relay Chain. +producing a reference to a previously unreferenced uncle block. +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. 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 joys 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 joystream's inflation model, and not on the number of payable actions (f.e., authoring a new block) executed. + +## Payout Scheme +No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on era points, as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras. + +Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. +Validators will receive staking rewards in the form of the native token of that chain (joystream). +For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. + +**Validator Set Size (v): 4** +Validator 1 Stake (v1): 18 tokens +Validator 2 Stake (v2): 9 tokens +Validator 3 Stake (v3): 8 tokens +Validator 4 Stake (v4): 7 tokens +Payout (p): 8 joys +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 tokens + +### Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. + +## Running Multiple Validators +It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. +For the following example, assume you have 18 joys to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 joys in this era. + +**Validator Set Size (v): 4** +Validator 1 Stake (v1): 18 joys <- Your validator +Validator 2 Stake (v2): 9 joys +Validator 3 Stake (v3): 8 joys +Validator 4 Stake (v4): 7 joys +Payout (p): 8 joys +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 joys <- Your first validator +Validator 2 Stake (v2): 9 joys <- Your second validator +Validator 3 Stake (v3): 9 joys +Validator 4 Stake (v4): 8 joys +Payout (p): 8 joys +Your payout = (p / v) * 2 = (8 / 4) * 2 = 4 + + ### With enough stake, you could run more than two validators. However, each validator must have enough stake behind it to be in the validator set. + +The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather than static, equilibrium. Potential validators will run different numbers of validators and apply different amounts of stake to them as time goes on, and in response to the actions of other validators on the network. + +## Slashing +Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough joys to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more joys for a validator with 18 joys staked than one with 9 joys staked. + +Running multiple validators does not absolve you of the consequences of misbehavior. Joystream punishes attacks that appear coordinated more severely than individual attacks. You should not, for example, run multiple validators hosted on the same infrastructure. A proper multi-validator configuration would ensure that they do not fail simultaneously. + +Nominators have the incentive to nominate the lowest-staked validator, as this will result in the lowest risk and highest reward. This is due to the fact that while their vulnerability to slashing remains the same (since it is percentage-based), their rewards are higher since they will be a higher proportion of the total stake allocated to that validator. + +To clarify this, let us imagine two validators, v1 and v2. Assume both are in the active set, have commission set to 0%, and are well-behaved. The only difference is that v1 has 90 joys nominating it and v2 only has 10. If you nominate v1, it now has 90 + 10 = 100 joys and you will get 10% of the staking rewards for the next era. If you nominate v2, it now has 10 + 10 = 20 joys nominating it, and you will get 50% of the staking rewards for the next era. In actuality, it would be quite rare to see such a large difference between the stake of validators, but the same principle holds even for smaller differences. If there is a 10% slash of either validator, then you will lose 1 joys in each case. + +### CAUTION +If a validator is oversubscribed in an era, staking rewards are distributed only to the the top 512 nominators and the rest of the nominators do not receive any rewards. This is not the case for slashing! Every active nominator of the validator committing slashable offence will be slashed. + +# Nominators and Validator Payments +Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without running a validator node yourself. Validators can choose to keep a percentage of the rewards due to their validator to "reimburse" themselves for the cost of running a validator node. Other than that, all rewards are shared based on the stake behind each validator. This includes the stake of the validator itself, plus any stake bonded by nominators. + +### INFO +Validators set their preference as a percentage of the block reward, not an absolute number of joys. joystream's block reward is based on the total amount at stake, with the reward peaking when the amount staked is at 50% of the total supply. The commission is set as the amount taken by the validator; that is, 0% commission means that the validator does not receive any proportion of the rewards besides that owed to it from self-stake, 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 split between nominator and validator stake. We will assume a single nominator for each validator. However, there can be numerous nominators for each validator. Rewards are still distributed proportionally - for example, if the total rewards to be given to nominators is 2 joys, and there are four nominators with equal stake bonded, each will receive 0.5 joys. Note also that a single nominator may stake different validators. + +Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in joys) is listed in brackets ([]) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. + +**Validator Set Size (v): 4** +Validator 1 Stake (v1) [20% commission]: 18 joys (9 validator, 9 nominator) +Validator 2 Stake (v2) [40% commission]: 9 joys (3 validator, 6 nominator) +Validator 3 Stake (v3) [10% commission]: 8 joys (4 validator, 4 nominator) +Validator 4 Stake (v4) [ 0% commission]: 6 joys (1 validator, 5 nominator) +Payout (p): 8 joys +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 joys + +**v1:** +(0.2 * 2) = 0.4 joys -> validator payment +(2 - 0.4) = 1.6 -> shared between all stake +(9 / 18) * 1.6 = 0.8 -> validator stake share +(9 / 18) * 1.6 = 0.8 -> nominator stake share +v1 validator total reward: 0.4 + 0.8 = 1.2 joys +v1 nominator reward: 0.8 joys + +**v2:** +(0.4 * 2) = 0.8 joys -> validator payment +(2 - 0.8) = 1.2 -> shared between all stake +(3 / 9) * 1.2 = 0.4 -> validator stake share +(6 / 9) * 1.2 = 0.8 -> nominator stake share +v2 validator total reward: 0.8 + 0.4 = 1.2 joys +v2 nominator reward: 0.8 joys + +**v3:** +(0.1 * 2) = 0.2 DOT -> validator payment +(2 - 0.2) = 1.8 -> shared between all stake +(4 / 8) * 1.8 = 0.9 -> validator stake share +(4 / 8) * 1.8 = 0.9 -> nominator stake share +v3 validator total reward: 0.2 + 0.9 joys = 1.1 joys +v3 nominator reward: 0.9 joys + +**v4:** +(0 * 2) = 0 joys -> validator payment +(2 - 0) = 2.0 -> shared between all stake +(1 / 6) * 2 = 0.33 -> validator stake share +(5 / 6) * 2 = 1.67 -> nominator stake share +v4 validator total reward: 0 + 0.33 joys = 0.33 joys +v4 nominator reward: 1.67 joys From 08ade9b8c7956b5c0c3029710c406d6d00d1e24f Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Thu, 29 Jun 2023 21:33:04 +0300 Subject: [PATCH 23/35] Delete validator_revard.md --- validator_revard.md | 161 -------------------------------------------- 1 file changed, 161 deletions(-) delete mode 100644 validator_revard.md diff --git a/validator_revard.md b/validator_revard.md deleted file mode 100644 index 4f0953b..0000000 --- a/validator_revard.md +++ /dev/null @@ -1,161 +0,0 @@ -# Validator Payout Overview - -## Reward Calculation -Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. Total reward is split among validators and their nominators depending on the number of points they received during the era. Points are added to a validator using reward_by_ids or reward_by_indices. - -## The validator and its nominator split their reward as following: - -The validator can declare an amount, named commission, that does not get shared with the nominators at each reward payout through its ValidatorPrefs. This value gets deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among the validator and all of the nominators that nominated the validator, proportional to the value staked behind this validator (i.e. dividing the own or others by total in Exposure). - -## All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: - -Controller account, (obviously) not increasing the staked value. -Stash account, not increasing the staked value. -Stash account, also increasing the staked value. - -## How to calculate individual Nominator and Validator Rewards: - -Shared Validator Set Rewards - **THIS ONE DONE BY CHAIN IN THE END OF EACH ERA** In each era, a function of - -− totalIssuance.at(lastBlockOfEra) -− erasTotalStake(era) - - **erasRewardPoints(era).total** -= validatorSetRewardInEra - -Individual Rewards for each Validator, before split between (vals + noms) -In each era, equal to: -(validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / -erasRewardPoints(era).total) - - **slashedInEra(era,stashOfVal)** -= totalValidatorRewardInEra - -Individual Rewards for each Validators (vals + noms) -In each era, equal to: - -valCommission = totalValidatorRewardInEra(era) × commission% / 100 -sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 -= totalValidatorRewardInEra(era) × (1 00 − commission%) - -valReward(era) = valCommission + sharedReward × valOwnStake(era) / totalValStake(era) - -nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) - -### Era Points -For every era (a period of time approximately 6 hours), validators are paid proportionally to the amount of era points they have collected. Era points are reward points earned for payable actions like: - -producing a non-uncle block in the Relay Chain. -producing a reference to a previously unreferenced uncle block. -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. 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 joys 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 joystream's inflation model, and not on the number of payable actions (f.e., authoring a new block) executed. - -## Payout Scheme -No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on era points, as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras. - -Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. -Validators will receive staking rewards in the form of the native token of that chain (joystream). -For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. - -**Validator Set Size (v): 4** -Validator 1 Stake (v1): 18 tokens -Validator 2 Stake (v2): 9 tokens -Validator 3 Stake (v3): 8 tokens -Validator 4 Stake (v4): 7 tokens -Payout (p): 8 joys -Payout for each validator (v1 - v4): -p / v = 8 / 4 = 2 tokens - -### Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. - -## Running Multiple Validators -It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. -For the following example, assume you have 18 joys to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 joys in this era. - -**Validator Set Size (v): 4** -Validator 1 Stake (v1): 18 joys <- Your validator -Validator 2 Stake (v2): 9 joys -Validator 3 Stake (v3): 8 joys -Validator 4 Stake (v4): 7 joys -Payout (p): 8 joys -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 joys <- Your first validator -Validator 2 Stake (v2): 9 joys <- Your second validator -Validator 3 Stake (v3): 9 joys -Validator 4 Stake (v4): 8 joys -Payout (p): 8 joys -Your payout = (p / v) * 2 = (8 / 4) * 2 = 4 - - ### With enough stake, you could run more than two validators. However, each validator must have enough stake behind it to be in the validator set. - -The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather than static, equilibrium. Potential validators will run different numbers of validators and apply different amounts of stake to them as time goes on, and in response to the actions of other validators on the network. - -## Slashing -Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough joys to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more joys for a validator with 18 joys staked than one with 9 joys staked. - -Running multiple validators does not absolve you of the consequences of misbehavior. Joystream punishes attacks that appear coordinated more severely than individual attacks. You should not, for example, run multiple validators hosted on the same infrastructure. A proper multi-validator configuration would ensure that they do not fail simultaneously. - -Nominators have the incentive to nominate the lowest-staked validator, as this will result in the lowest risk and highest reward. This is due to the fact that while their vulnerability to slashing remains the same (since it is percentage-based), their rewards are higher since they will be a higher proportion of the total stake allocated to that validator. - -To clarify this, let us imagine two validators, v1 and v2. Assume both are in the active set, have commission set to 0%, and are well-behaved. The only difference is that v1 has 90 joys nominating it and v2 only has 10. If you nominate v1, it now has 90 + 10 = 100 joys and you will get 10% of the staking rewards for the next era. If you nominate v2, it now has 10 + 10 = 20 joys nominating it, and you will get 50% of the staking rewards for the next era. In actuality, it would be quite rare to see such a large difference between the stake of validators, but the same principle holds even for smaller differences. If there is a 10% slash of either validator, then you will lose 1 joys in each case. - -### CAUTION -If a validator is oversubscribed in an era, staking rewards are distributed only to the the top 512 nominators and the rest of the nominators do not receive any rewards. This is not the case for slashing! Every active nominator of the validator committing slashable offence will be slashed. - -# Nominators and Validator Payments -Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without running a validator node yourself. Validators can choose to keep a percentage of the rewards due to their validator to "reimburse" themselves for the cost of running a validator node. Other than that, all rewards are shared based on the stake behind each validator. This includes the stake of the validator itself, plus any stake bonded by nominators. - -### INFO -Validators set their preference as a percentage of the block reward, not an absolute number of joys. joystream's block reward is based on the total amount at stake, with the reward peaking when the amount staked is at 50% of the total supply. The commission is set as the amount taken by the validator; that is, 0% commission means that the validator does not receive any proportion of the rewards besides that owed to it from self-stake, 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 split between nominator and validator stake. We will assume a single nominator for each validator. However, there can be numerous nominators for each validator. Rewards are still distributed proportionally - for example, if the total rewards to be given to nominators is 2 joys, and there are four nominators with equal stake bonded, each will receive 0.5 joys. Note also that a single nominator may stake different validators. - -Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in joys) is listed in brackets ([]) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. - -**Validator Set Size (v): 4** -Validator 1 Stake (v1) [20% commission]: 18 joys (9 validator, 9 nominator) -Validator 2 Stake (v2) [40% commission]: 9 joys (3 validator, 6 nominator) -Validator 3 Stake (v3) [10% commission]: 8 joys (4 validator, 4 nominator) -Validator 4 Stake (v4) [ 0% commission]: 6 joys (1 validator, 5 nominator) -Payout (p): 8 joys -Payout for each validator (v1 - v4): -p / v = 8 / 4 = 2 joys - -**v1:** -(0.2 * 2) = 0.4 joys -> validator payment -(2 - 0.4) = 1.6 -> shared between all stake -(9 / 18) * 1.6 = 0.8 -> validator stake share -(9 / 18) * 1.6 = 0.8 -> nominator stake share -v1 validator total reward: 0.4 + 0.8 = 1.2 joys -v1 nominator reward: 0.8 joys - -**v2:** -(0.4 * 2) = 0.8 joys -> validator payment -(2 - 0.8) = 1.2 -> shared between all stake -(3 / 9) * 1.2 = 0.4 -> validator stake share -(6 / 9) * 1.2 = 0.8 -> nominator stake share -v2 validator total reward: 0.8 + 0.4 = 1.2 joys -v2 nominator reward: 0.8 joys - -**v3:** -(0.1 * 2) = 0.2 DOT -> validator payment -(2 - 0.2) = 1.8 -> shared between all stake -(4 / 8) * 1.8 = 0.9 -> validator stake share -(4 / 8) * 1.8 = 0.9 -> nominator stake share -v3 validator total reward: 0.2 + 0.9 joys = 1.1 joys -v3 nominator reward: 0.9 joys - -**v4:** -(0 * 2) = 0 joys -> validator payment -(2 - 0) = 2.0 -> shared between all stake -(1 / 6) * 2 = 0.33 -> validator stake share -(5 / 6) * 2 = 1.67 -> nominator stake share -v4 validator total reward: 0 + 0.33 joys = 0.33 joys -v4 nominator reward: 1.67 joys From 48fa05d98a62e6b7d091b5979c13e75179d1fc8b Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Fri, 30 Jun 2023 10:44:04 +0300 Subject: [PATCH 24/35] Add files via upload --- system/validator_revard/README.md | 161 ++++++++++++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 system/validator_revard/README.md diff --git a/system/validator_revard/README.md b/system/validator_revard/README.md new file mode 100644 index 0000000..4f0953b --- /dev/null +++ b/system/validator_revard/README.md @@ -0,0 +1,161 @@ +# Validator Payout Overview + +## Reward Calculation +Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. Total reward is split among validators and their nominators depending on the number of points they received during the era. Points are added to a validator using reward_by_ids or reward_by_indices. + +## The validator and its nominator split their reward as following: + +The validator can declare an amount, named commission, that does not get shared with the nominators at each reward payout through its ValidatorPrefs. This value gets deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among the validator and all of the nominators that nominated the validator, proportional to the value staked behind this validator (i.e. dividing the own or others by total in Exposure). + +## All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: + +Controller account, (obviously) not increasing the staked value. +Stash account, not increasing the staked value. +Stash account, also increasing the staked value. + +## How to calculate individual Nominator and Validator Rewards: + +Shared Validator Set Rewards - **THIS ONE DONE BY CHAIN IN THE END OF EACH ERA** In each era, a function of + +− totalIssuance.at(lastBlockOfEra) +− erasTotalStake(era) + + **erasRewardPoints(era).total** += validatorSetRewardInEra + +Individual Rewards for each Validator, before split between (vals + noms) +In each era, equal to: +(validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / +erasRewardPoints(era).total) + + **slashedInEra(era,stashOfVal)** += totalValidatorRewardInEra + +Individual Rewards for each Validators (vals + noms) +In each era, equal to: + +valCommission = totalValidatorRewardInEra(era) × commission% / 100 +sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 += totalValidatorRewardInEra(era) × (1 00 − commission%) + +valReward(era) = valCommission + sharedReward × valOwnStake(era) / totalValStake(era) + +nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) + +### Era Points +For every era (a period of time approximately 6 hours), validators are paid proportionally to the amount of era points they have collected. Era points are reward points earned for payable actions like: + +producing a non-uncle block in the Relay Chain. +producing a reference to a previously unreferenced uncle block. +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. 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 joys 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 joystream's inflation model, and not on the number of payable actions (f.e., authoring a new block) executed. + +## Payout Scheme +No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on era points, as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras. + +Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. +Validators will receive staking rewards in the form of the native token of that chain (joystream). +For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. + +**Validator Set Size (v): 4** +Validator 1 Stake (v1): 18 tokens +Validator 2 Stake (v2): 9 tokens +Validator 3 Stake (v3): 8 tokens +Validator 4 Stake (v4): 7 tokens +Payout (p): 8 joys +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 tokens + +### Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. + +## Running Multiple Validators +It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. +For the following example, assume you have 18 joys to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 joys in this era. + +**Validator Set Size (v): 4** +Validator 1 Stake (v1): 18 joys <- Your validator +Validator 2 Stake (v2): 9 joys +Validator 3 Stake (v3): 8 joys +Validator 4 Stake (v4): 7 joys +Payout (p): 8 joys +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 joys <- Your first validator +Validator 2 Stake (v2): 9 joys <- Your second validator +Validator 3 Stake (v3): 9 joys +Validator 4 Stake (v4): 8 joys +Payout (p): 8 joys +Your payout = (p / v) * 2 = (8 / 4) * 2 = 4 + + ### With enough stake, you could run more than two validators. However, each validator must have enough stake behind it to be in the validator set. + +The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather than static, equilibrium. Potential validators will run different numbers of validators and apply different amounts of stake to them as time goes on, and in response to the actions of other validators on the network. + +## Slashing +Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough joys to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more joys for a validator with 18 joys staked than one with 9 joys staked. + +Running multiple validators does not absolve you of the consequences of misbehavior. Joystream punishes attacks that appear coordinated more severely than individual attacks. You should not, for example, run multiple validators hosted on the same infrastructure. A proper multi-validator configuration would ensure that they do not fail simultaneously. + +Nominators have the incentive to nominate the lowest-staked validator, as this will result in the lowest risk and highest reward. This is due to the fact that while their vulnerability to slashing remains the same (since it is percentage-based), their rewards are higher since they will be a higher proportion of the total stake allocated to that validator. + +To clarify this, let us imagine two validators, v1 and v2. Assume both are in the active set, have commission set to 0%, and are well-behaved. The only difference is that v1 has 90 joys nominating it and v2 only has 10. If you nominate v1, it now has 90 + 10 = 100 joys and you will get 10% of the staking rewards for the next era. If you nominate v2, it now has 10 + 10 = 20 joys nominating it, and you will get 50% of the staking rewards for the next era. In actuality, it would be quite rare to see such a large difference between the stake of validators, but the same principle holds even for smaller differences. If there is a 10% slash of either validator, then you will lose 1 joys in each case. + +### CAUTION +If a validator is oversubscribed in an era, staking rewards are distributed only to the the top 512 nominators and the rest of the nominators do not receive any rewards. This is not the case for slashing! Every active nominator of the validator committing slashable offence will be slashed. + +# Nominators and Validator Payments +Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without running a validator node yourself. Validators can choose to keep a percentage of the rewards due to their validator to "reimburse" themselves for the cost of running a validator node. Other than that, all rewards are shared based on the stake behind each validator. This includes the stake of the validator itself, plus any stake bonded by nominators. + +### INFO +Validators set their preference as a percentage of the block reward, not an absolute number of joys. joystream's block reward is based on the total amount at stake, with the reward peaking when the amount staked is at 50% of the total supply. The commission is set as the amount taken by the validator; that is, 0% commission means that the validator does not receive any proportion of the rewards besides that owed to it from self-stake, 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 split between nominator and validator stake. We will assume a single nominator for each validator. However, there can be numerous nominators for each validator. Rewards are still distributed proportionally - for example, if the total rewards to be given to nominators is 2 joys, and there are four nominators with equal stake bonded, each will receive 0.5 joys. Note also that a single nominator may stake different validators. + +Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in joys) is listed in brackets ([]) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. + +**Validator Set Size (v): 4** +Validator 1 Stake (v1) [20% commission]: 18 joys (9 validator, 9 nominator) +Validator 2 Stake (v2) [40% commission]: 9 joys (3 validator, 6 nominator) +Validator 3 Stake (v3) [10% commission]: 8 joys (4 validator, 4 nominator) +Validator 4 Stake (v4) [ 0% commission]: 6 joys (1 validator, 5 nominator) +Payout (p): 8 joys +Payout for each validator (v1 - v4): +p / v = 8 / 4 = 2 joys + +**v1:** +(0.2 * 2) = 0.4 joys -> validator payment +(2 - 0.4) = 1.6 -> shared between all stake +(9 / 18) * 1.6 = 0.8 -> validator stake share +(9 / 18) * 1.6 = 0.8 -> nominator stake share +v1 validator total reward: 0.4 + 0.8 = 1.2 joys +v1 nominator reward: 0.8 joys + +**v2:** +(0.4 * 2) = 0.8 joys -> validator payment +(2 - 0.8) = 1.2 -> shared between all stake +(3 / 9) * 1.2 = 0.4 -> validator stake share +(6 / 9) * 1.2 = 0.8 -> nominator stake share +v2 validator total reward: 0.8 + 0.4 = 1.2 joys +v2 nominator reward: 0.8 joys + +**v3:** +(0.1 * 2) = 0.2 DOT -> validator payment +(2 - 0.2) = 1.8 -> shared between all stake +(4 / 8) * 1.8 = 0.9 -> validator stake share +(4 / 8) * 1.8 = 0.9 -> nominator stake share +v3 validator total reward: 0.2 + 0.9 joys = 1.1 joys +v3 nominator reward: 0.9 joys + +**v4:** +(0 * 2) = 0 joys -> validator payment +(2 - 0) = 2.0 -> shared between all stake +(1 / 6) * 2 = 0.33 -> validator stake share +(5 / 6) * 2 = 1.67 -> nominator stake share +v4 validator total reward: 0 + 0.33 joys = 0.33 joys +v4 nominator reward: 1.67 joys From 98691497fe4e8f67848c1164b5396a6753ae89ff Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Fri, 30 Jun 2023 10:51:56 +0300 Subject: [PATCH 25/35] Add files via upload --- system/validator_revard/validation.md | 275 ++++++++++++++++++++++++++ 1 file changed, 275 insertions(+) create mode 100644 system/validator_revard/validation.md diff --git a/system/validator_revard/validation.md b/system/validator_revard/validation.md new file mode 100644 index 0000000..5528ccb --- /dev/null +++ b/system/validator_revard/validation.md @@ -0,0 +1,275 @@ +--- +description: Maintaining agreement over the growing history of the system. +--- + +# 🏭 Validation + +## Validator + +### Responsibilities + +* Run and maintain screening nodes that are always available and performant +* Help enforce the consensus rules of the network + +### Requirements + +* Experienced with how to setup and maintain high performance IT infrastructure +* Access to highly performant and reliable IT infrastructure, with high storage, (up & down) bandwidth and processing capacity +* Able to securely store keys +* Hold sufficient amount of the native platform token to put at stake + * currently **at least** JOY 41.667k in a single account, which is the minimum to sign up – actually getting a validator slot likely requires more + +#### Hardware Requirements + +The Joystream blockchain, and therefore the `joystream-node` is built on the [substrate](https://substrate.io/) framework, developed for the [Polkadot](https://polkadot.network/) ecosystem. As Joystream is still in infancy on mainnet, we refer to the their expertise for the technical specification and [recommendations](https://wiki.polkadot.network/docs/maintain-guides-how-to-validate-polkadot#reference-hardware): + +* **CPU** + * x86-64 compatible; + * Intel Ice Lake, or newer (Xeon or Core series); AMD Zen3, or newer (EPYC or Ryzen); + * 4 physical cores @ 3.4GHz; + * Simultaneous multithreading disabled (Hyper-Threading on Intel, SMT on AMD); + * Prefer single-threaded performance over higher cores count. A comparison of single-threaded performance can be found [here](https://www.cpubenchmark.net/singleThread.html). +* **Storage** + * An NVMe SSD of 1 TB (As it should be reasonably sized to deal with blockchain growth). An estimation of current chain snapshot sizes can be found [here](https://paranodes.io/DBSize). In general, the latency is more important than the throughput. +* **Memory** + * 16GB DDR4 ECC. +* **System** + * Linux Kernel 5.16 or newer. +* **Network** + * The minimum symmetric networking speed is set to 500 Mbit/s (= 62.5 MB/s). This is required to support a large number of parachains and allow for proper congestion control in busy network situations. + +It should be obvious that given the life span and size – thus state and transaction activity – of Polkadot relative to Joystream at this stage, it is certainly fine to scale down on things like storage... + +## Guides + +The instructions below cover Linux binaries only. If you want to build from source, clone the [repo](https://github.com/Joystream/joystream) and follow the build steps there. + +### Install and Deploy + +* Every time something is written in ``, this means you have to replace this with your input, without the `<>`. +* When something is written in `"double_quotes"`, it means the number/data will vary depending on your node or the current state of the blockchain. +* For terminal commands: + * `$` means you must type what comes afterwards + * `#` means it's just a comment/explanation for the readers convenience + +``` +# This is just a comment, don't type or paste it in your terminal! +$ cd ~/ +# Only type/paste the "cd ~/, not the preceding $ ! +``` + +For the purposes of simplicity, we will assume: + +1. You are user `joystream`, with sudo priveliges. +2. You want to save everything in `/home/joystream/bin/` + +#### Download Node Binary + +Find the latest release [here](https://github.com/Joystream/joystream/releases/latest) or get the tag from the command line with: + +``` +$ curl -sL https://api.github.com/repos/Joystream/joystream/releases/latest | jq -r ".tag_name" +``` + +At the time of writing, the latest release is `v12.1001.0`, whereas the last node binary is from version `v12.1000.0` (mainnet) + +``` +# Create the directory, and go there +$ mkdir ~/bin && cd ~/bin + +# Assuming the latest version is still v12.1000.0 +# Download the binary: +$ wget https://github.com/Joystream/joystream/releases/download/v12.1000.0/joystream-node-8.0.0-1a0d1f677df-x86_64-linux-gnu.tar.gz + +# unzip it: +$ tar -vxf joystream-node-8.0.0-1a0d1f677df-x86_64-linux-gnu.tar.gz + +# Download the chain spec: +$ wget https://github.com/Joystream/joystream/releases/download/v12.1000.0/joy-mainnet.json + +# test that your node works: +$ ./joystream-node --chain-spec joy-mainnet.json --pruning archive +``` + +Assuming it starts syncing, you can stop it right away with `ctrl+c` + +#### Configuration + +The node lets you set a variety of option flags. You can display them all with `./joystream-node --help` Some basic `options` you should enable or consider: + +> \--chain \ +> +> Specify the chain specification. It can be one of the predefined ones (dev, local, or staging) or it can be a path to a file with the chainspec (such as one exported by the `build-spec` subcommand). + +* **Required** + * Without this flag, you will not connect the chain. + +> \--pruning \ +> +> Specify the state pruning mode, a number of blocks to keep or 'archive'. Default is to keep all block states if the node is running as a validator (i.e. 'archive'), otherwise state is only kept for the last 256 blocks. + +* **Required for validators** + * If you want to be a validator, the node must run with `--pruning archive` + * If you start syncing without that flag enabled, you will have to wipe your node and sync again if you change your mind. + +> \--validator +> +> Enable validator mode. The node will be started with the authority role and actively participate in any consensus task that it can (e.g. depending on availability of local keys). + +* **Required for validators** + * Unlike with `--pruning`, it only has to be set when you are actually in the validator set to have an effect, so you don't have to re-sync if you forget while syncing. + +> \--name +> +> The human-readable name for this node. The node name will be reported to the telemetry server, if enabled. + +* **Optional** + * May serve some benefits if you want someone to nominate you, but may make it easier to identity you. + +*** + +As a validator, you should (as a bare minimum) be very restrictive in terms of RPC access to your node. Go through the options, and double check that the defaults are in line with your preferences and risk tolerance. + +#### Run as a Service + +Running as a service means that the node will continue running as a daemon, and you can enable it to restart in case of crashes and on reboot. + +It requires sudo privileges. If you are not user `root`, add `sudo` before commands. + +Example file below, with essentials only: + +``` +[Unit] +Description=Joystream Node +After=network.target + +[Service] +Type=simple +User=joystream +WorkingDirectory=/home/joystream/bin/ +ExecStart=/home/joystream/bin/joystream-node \ + --chain /home/joystream/bin/joy-mainnet.json \ + --pruning archive \ + --validator +Restart=on-failure +RestartSec=3 +LimitNOFILE=10000 + +[Install] +WantedBy=multi-user.target +``` + +``` +# Create/open a file with your favorite editor (I use nano below) +$ sudo nano /etc/systemd/system/joystream-node.service + +# Paste in the example file above, and do "ctrl+x", then "y" and "return" to save + +# start it up: +$ sudo systemctl start joystream-node + +# check that it's working: +$ sudo systemctl status joystream-node +# For a brief status, OR +$ sudo journalctl -f -n 100 -u joystream-node +# To monitor the log + +# If you are happy, enable it so it will start automatically on boot: +$ sudo systemctl enable joystream-node +``` + +### Setup Keys and Validate + +With your validator node up and running, you are now ready to set up keys and announce your intentions on chain. + +#### Generate Session Keys + +In the terminal on your node (will only work if you are on running the chain on the same machine!): + +``` +$ curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933 + +# Which should return: +{"jsonrpc":"2.0","result":"0xabc...123","id":1} +``` + +Where `0xabc...123` (a much longer string in reality) is a concatenation of four public keys hex-encoded. The private keys should have been injected in your `base-path`. Make sure you copy this string over somewhere, as you need it later. + +Assuming you only did this once (while running this _this_ chain), and you didn't set a different `--base-path` flag: + +``` +# On the current network, replace with joy_testnet_7 +$ ls -a ~/.local/share/joystream-node/chains//keystore + +# Which should return 4 files, each a long string starting with a 6. + +# You can confirm more precisely by: + +$ curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_hasSessionKeys", "params":["0xabc...123"]}' http://localhost:9933 + +# Which, if you have the corresponding ready to sign, should return: +{"jsonrpc":"2.0","result":true,"id":1} +``` + +**Warning:** + +* It's both bad practice, and a possible slashing risk, to keep multiple set of session keys on one node. If you wanted to try the command, made a mistake, or for whatever reason want to switch them, delete them. If you have had set them on chain (see next steps), you can change them before you get into the validator set. +* Keeping the same set of keys, on multiple nodes, all running with the `--validator` enabled, will cause a slash. A good backup system could include backup nodes, but be careful. It's better to get "booted" for an era than to double sign blocks. It will be treated as an attack even if just by accident. + +#### Configure Validator on Chain + +For the time being, we will only show how to do this with [Polkadot{.js} apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.joystream.org#/explorer), a web based UI, and the [Polkadot{.js} extension](https://polkadot.js.org/extension/), a that works with both the aforementioned UI and Joystreams [own Pioneer](https://pioneerapp.xyz/#/profile). + +As the polkadot-js UI serves lots of projects in the substrate ecosystem, you have to make sure to set the correct endpoint, meaning which network (and node) you connect to. The link above does Joystream automatically, and sets it as default in local storage (until another is set). + +The network endpoint can also be set manually by clicking the top left corner, and selecting "Live Networks" -> "Joystream" (hosted by Jsgenesis) before clicking "Switch", from the meny that appears. + +This will display the logo, network name, node version and latest block height of the chain you are currently connected to as shown below. + +
+ +**With Polkadot-js** + +You need two keys for this, one to be the `controller` and one as the `stash`. The latter holds the stake and must sign at least once to "delegate" to the `controller` which is running the "day to day" operations. + +Assuming you are fully synched, your node is running, and you have + +**Steps:** + +1. Go to the "staking actions" tab - "Network" -> "Staking" -> "Accounts", and click the "+ Validator" button in the top right corner. +2. Select a `stash` and `controller` account from the dropdown, set the "value bonded" as the amount you want to stake, and choose a "payment destination", then hit "next". +3. Paste in the public session keys (`0xabc...123`), choose a "reward commission percentage" and whether you want to allow nominations or not, then click "Bond & Validate". + +If you are preparing this for later, click the "+ Stash" button instead. This allows you to wait for your session keys and/or synching your node. + +#### Being a Validator + +Assuming the transaction went through, you will now appear under the "waiting" tab [here](https://polkadot.js.org/apps/#/staking). That means you are in the queue for joining the validator set, but when (and whether) you actually join depends on the competition for getting a slot. + +At all times, there is a limit to how many can become validators. What that number is set by the council. The current value can be found in the [chain state](https://polkadot.js.org/apps/#/chainstate) -> "staking" -> "validatorCount". + +Suppose that number is `n`, and that there are `m` validators that, towards the end of each `era` were already validating or joined the queue: + +* If `n >= m`, all will be elected +* If `n "staking" -> "minValidatorBond". (In base value `HAPI`, meaning `1*10^-10 JOY`) + +Another reason the transaction can be rejected is if the maximum number of `bonded` accounts have declared as validators. That number can be found in the [chain state](https://polkadot.js.org/apps/#/chainstate) -> "staking" -> "maxValidatorsCount". How many there are currently can be found in the [chain state](https://polkadot.js.org/apps/#/chainstate) -> "staking" -> "counterForValidators". + +There are of course a limitless amount of other reasons the transaction could be rejected if you constructed it yourself in the cli. + +### Advanced Setup + +`TODO` + +## From 7a162a5bb428cf680fafc0531e71a29846eca8f1 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Fri, 30 Jun 2023 11:16:01 +0300 Subject: [PATCH 26/35] Delete read.me --- system/validator_revard/read.me | 1 - 1 file changed, 1 deletion(-) delete mode 100644 system/validator_revard/read.me diff --git a/system/validator_revard/read.me b/system/validator_revard/read.me deleted file mode 100644 index 5e37295..0000000 --- a/system/validator_revard/read.me +++ /dev/null @@ -1 +0,0 @@ -Hellow world From e93d0ade2f477b58370b7d3e1daa22c38c6dbe9c Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Sat, 1 Jul 2023 12:05:54 +0300 Subject: [PATCH 27/35] Delete README.md --- system/validator_revard/README.md | 161 ------------------------------ 1 file changed, 161 deletions(-) delete mode 100644 system/validator_revard/README.md diff --git a/system/validator_revard/README.md b/system/validator_revard/README.md deleted file mode 100644 index 4f0953b..0000000 --- a/system/validator_revard/README.md +++ /dev/null @@ -1,161 +0,0 @@ -# Validator Payout Overview - -## Reward Calculation -Validators and nominators are rewarded at the end of each era. The total reward of an era is calculated using the era duration and the staking rate (the total amount of tokens staked by nominators and validators, divided by the total token supply). It aims to incentivize toward a defined staking rate. Total reward is split among validators and their nominators depending on the number of points they received during the era. Points are added to a validator using reward_by_ids or reward_by_indices. - -## The validator and its nominator split their reward as following: - -The validator can declare an amount, named commission, that does not get shared with the nominators at each reward payout through its ValidatorPrefs. This value gets deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among the validator and all of the nominators that nominated the validator, proportional to the value staked behind this validator (i.e. dividing the own or others by total in Exposure). - -## All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: - -Controller account, (obviously) not increasing the staked value. -Stash account, not increasing the staked value. -Stash account, also increasing the staked value. - -## How to calculate individual Nominator and Validator Rewards: - -Shared Validator Set Rewards - **THIS ONE DONE BY CHAIN IN THE END OF EACH ERA** In each era, a function of - -− totalIssuance.at(lastBlockOfEra) -− erasTotalStake(era) - - **erasRewardPoints(era).total** -= validatorSetRewardInEra - -Individual Rewards for each Validator, before split between (vals + noms) -In each era, equal to: -(validatorSetRewardInEra × erasRewardPoints(era).stashOfVal / -erasRewardPoints(era).total) - - **slashedInEra(era,stashOfVal)** -= totalValidatorRewardInEra - -Individual Rewards for each Validators (vals + noms) -In each era, equal to: - -valCommission = totalValidatorRewardInEra(era) × commission% / 100 -sharedReward = totalValidatorRewardInEra(era) − totalValidatorRewardInEra(era) × commission% / 100 -= totalValidatorRewardInEra(era) × (1 00 − commission%) - -valReward(era) = valCommission + sharedReward × valOwnStake(era) / totalValStake(era) - -nomReward_i(era) = sharedReward × nomStake_i(era) / totalValStake(era) - -### Era Points -For every era (a period of time approximately 6 hours), validators are paid proportionally to the amount of era points they have collected. Era points are reward points earned for payable actions like: - -producing a non-uncle block in the Relay Chain. -producing a reference to a previously unreferenced uncle block. -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. 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 joys 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 joystream's inflation model, and not on the number of payable actions (f.e., authoring a new block) executed. - -## Payout Scheme -No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on era points, as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras. - -Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly. -Validators will receive staking rewards in the form of the native token of that chain (joystream). -For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips. - -**Validator Set Size (v): 4** -Validator 1 Stake (v1): 18 tokens -Validator 2 Stake (v2): 9 tokens -Validator 3 Stake (v3): 8 tokens -Validator 4 Stake (v4): 7 tokens -Payout (p): 8 joys -Payout for each validator (v1 - v4): -p / v = 8 / 4 = 2 tokens - -### Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. - -## Running Multiple Validators -It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. -For the following example, assume you have 18 joys to stake. For simplicity's sake, we will ignore nominators. Running a single validator, as in the example above, would net you 2 joys in this era. - -**Validator Set Size (v): 4** -Validator 1 Stake (v1): 18 joys <- Your validator -Validator 2 Stake (v2): 9 joys -Validator 3 Stake (v3): 8 joys -Validator 4 Stake (v4): 7 joys -Payout (p): 8 joys -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 joys <- Your first validator -Validator 2 Stake (v2): 9 joys <- Your second validator -Validator 3 Stake (v3): 9 joys -Validator 4 Stake (v4): 8 joys -Payout (p): 8 joys -Your payout = (p / v) * 2 = (8 / 4) * 2 = 4 - - ### With enough stake, you could run more than two validators. However, each validator must have enough stake behind it to be in the validator set. - -The incentives of the system favor equally-staked validators. This works out to be a dynamic, rather than static, equilibrium. Potential validators will run different numbers of validators and apply different amounts of stake to them as time goes on, and in response to the actions of other validators on the network. - -## Slashing -Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough joys to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more joys for a validator with 18 joys staked than one with 9 joys staked. - -Running multiple validators does not absolve you of the consequences of misbehavior. Joystream punishes attacks that appear coordinated more severely than individual attacks. You should not, for example, run multiple validators hosted on the same infrastructure. A proper multi-validator configuration would ensure that they do not fail simultaneously. - -Nominators have the incentive to nominate the lowest-staked validator, as this will result in the lowest risk and highest reward. This is due to the fact that while their vulnerability to slashing remains the same (since it is percentage-based), their rewards are higher since they will be a higher proportion of the total stake allocated to that validator. - -To clarify this, let us imagine two validators, v1 and v2. Assume both are in the active set, have commission set to 0%, and are well-behaved. The only difference is that v1 has 90 joys nominating it and v2 only has 10. If you nominate v1, it now has 90 + 10 = 100 joys and you will get 10% of the staking rewards for the next era. If you nominate v2, it now has 10 + 10 = 20 joys nominating it, and you will get 50% of the staking rewards for the next era. In actuality, it would be quite rare to see such a large difference between the stake of validators, but the same principle holds even for smaller differences. If there is a 10% slash of either validator, then you will lose 1 joys in each case. - -### CAUTION -If a validator is oversubscribed in an era, staking rewards are distributed only to the the top 512 nominators and the rest of the nominators do not receive any rewards. This is not the case for slashing! Every active nominator of the validator committing slashable offence will be slashed. - -# Nominators and Validator Payments -Nominated stake allows you to "vote" for validators and share in the rewards (and slashing) without running a validator node yourself. Validators can choose to keep a percentage of the rewards due to their validator to "reimburse" themselves for the cost of running a validator node. Other than that, all rewards are shared based on the stake behind each validator. This includes the stake of the validator itself, plus any stake bonded by nominators. - -### INFO -Validators set their preference as a percentage of the block reward, not an absolute number of joys. joystream's block reward is based on the total amount at stake, with the reward peaking when the amount staked is at 50% of the total supply. The commission is set as the amount taken by the validator; that is, 0% commission means that the validator does not receive any proportion of the rewards besides that owed to it from self-stake, 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 split between nominator and validator stake. We will assume a single nominator for each validator. However, there can be numerous nominators for each validator. Rewards are still distributed proportionally - for example, if the total rewards to be given to nominators is 2 joys, and there are four nominators with equal stake bonded, each will receive 0.5 joys. Note also that a single nominator may stake different validators. - -Each validator in the example has selected a different validator payment (that is, a percentage of the reward set aside directly for the validator before sharing with all bonded stake). The validator's payment percentage (in joys) is listed in brackets ([]) next to each validator. Note that since the validator payment is public knowledge, having a low or non-existent validator payment may attract more stake from nominators, since they know they will receive a larger reward. - -**Validator Set Size (v): 4** -Validator 1 Stake (v1) [20% commission]: 18 joys (9 validator, 9 nominator) -Validator 2 Stake (v2) [40% commission]: 9 joys (3 validator, 6 nominator) -Validator 3 Stake (v3) [10% commission]: 8 joys (4 validator, 4 nominator) -Validator 4 Stake (v4) [ 0% commission]: 6 joys (1 validator, 5 nominator) -Payout (p): 8 joys -Payout for each validator (v1 - v4): -p / v = 8 / 4 = 2 joys - -**v1:** -(0.2 * 2) = 0.4 joys -> validator payment -(2 - 0.4) = 1.6 -> shared between all stake -(9 / 18) * 1.6 = 0.8 -> validator stake share -(9 / 18) * 1.6 = 0.8 -> nominator stake share -v1 validator total reward: 0.4 + 0.8 = 1.2 joys -v1 nominator reward: 0.8 joys - -**v2:** -(0.4 * 2) = 0.8 joys -> validator payment -(2 - 0.8) = 1.2 -> shared between all stake -(3 / 9) * 1.2 = 0.4 -> validator stake share -(6 / 9) * 1.2 = 0.8 -> nominator stake share -v2 validator total reward: 0.8 + 0.4 = 1.2 joys -v2 nominator reward: 0.8 joys - -**v3:** -(0.1 * 2) = 0.2 DOT -> validator payment -(2 - 0.2) = 1.8 -> shared between all stake -(4 / 8) * 1.8 = 0.9 -> validator stake share -(4 / 8) * 1.8 = 0.9 -> nominator stake share -v3 validator total reward: 0.2 + 0.9 joys = 1.1 joys -v3 nominator reward: 0.9 joys - -**v4:** -(0 * 2) = 0 joys -> validator payment -(2 - 0) = 2.0 -> shared between all stake -(1 / 6) * 2 = 0.33 -> validator stake share -(5 / 6) * 2 = 1.67 -> nominator stake share -v4 validator total reward: 0 + 0.33 joys = 0.33 joys -v4 nominator reward: 1.67 joys From 1f7a20807ae68bc0b7662bb26b6f19e684816117 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Sat, 1 Jul 2023 12:07:30 +0300 Subject: [PATCH 28/35] Rename validator_revard.md to Reward-calculation.md --- .../{validator_revard.md => Reward-calculation.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename system/validator_revard/{validator_revard.md => Reward-calculation.md} (100%) diff --git a/system/validator_revard/validator_revard.md b/system/validator_revard/Reward-calculation.md similarity index 100% rename from system/validator_revard/validator_revard.md rename to system/validator_revard/Reward-calculation.md From 3f42f85da7eec4a8d4ccb94853012aac054a8762 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Wed, 5 Jul 2023 11:49:05 +0300 Subject: [PATCH 29/35] Add files via upload --- system/validator_revard/README.md | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 system/validator_revard/README.md diff --git a/system/validator_revard/README.md b/system/validator_revard/README.md new file mode 100644 index 0000000..a31f6bb --- /dev/null +++ b/system/validator_revard/README.md @@ -0,0 +1,5 @@ +The purpose of the supplement. It was found that the guide is missing information about validator awards. +The information was taken from the joystream documents on this topic and from the polkadot handbook. +The document was checked by several authoritative joistream members and changes were made according to joistream blockchain. +It is possible that errors may be found in the future, which will need to be corrected. +Target audience validators. From 0a7c52d92b08a1770abb58d9f55226c1326cc6fa Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Wed, 5 Jul 2023 11:50:33 +0300 Subject: [PATCH 30/35] Update README.md --- system/validator_revard/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system/validator_revard/README.md b/system/validator_revard/README.md index a31f6bb..87efcae 100644 --- a/system/validator_revard/README.md +++ b/system/validator_revard/README.md @@ -2,4 +2,4 @@ The purpose of the supplement. It was found that the guide is missing informatio The information was taken from the joystream documents on this topic and from the polkadot handbook. The document was checked by several authoritative joistream members and changes were made according to joistream blockchain. It is possible that errors may be found in the future, which will need to be corrected. -Target audience validators. +The target audience is validators. From 94ae2fc224ea2f2606cf8e112f96a5e5c1263e36 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Fri, 7 Jul 2023 17:37:53 +0300 Subject: [PATCH 31/35] Rename README.md to README1.md --- system/validator_revard/{README.md => README1.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename system/validator_revard/{README.md => README1.md} (100%) diff --git a/system/validator_revard/README.md b/system/validator_revard/README1.md similarity index 100% rename from system/validator_revard/README.md rename to system/validator_revard/README1.md From adf343f6607b33e5561a79286a9161ace1eb58aa Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Fri, 7 Jul 2023 17:40:42 +0300 Subject: [PATCH 32/35] Rename validation.md to README.md Changed the file name from validator.md to README.md --- system/validator_revard/{validation.md => README.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename system/validator_revard/{validation.md => README.md} (100%) diff --git a/system/validator_revard/validation.md b/system/validator_revard/README.md similarity index 100% rename from system/validator_revard/validation.md rename to system/validator_revard/README.md From 2b6f3511f4a5bc5ad389081ef7059b5a47863c7c Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Fri, 7 Jul 2023 20:13:15 +0300 Subject: [PATCH 33/35] Update Reward-calculation.md removed the highlighting --- system/validator_revard/Reward-calculation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system/validator_revard/Reward-calculation.md b/system/validator_revard/Reward-calculation.md index 4f0953b..a5ea521 100644 --- a/system/validator_revard/Reward-calculation.md +++ b/system/validator_revard/Reward-calculation.md @@ -7,7 +7,7 @@ Validators and nominators are rewarded at the end of each era. The total reward The validator can declare an amount, named commission, that does not get shared with the nominators at each reward payout through its ValidatorPrefs. This value gets deducted from the total reward that is paid to the validator and its nominators. The remaining portion is split among the validator and all of the nominators that nominated the validator, proportional to the value staked behind this validator (i.e. dividing the own or others by total in Exposure). -## All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: +All entities who receive a reward have the option to choose their reward destination through the Payee storage item (see set_payee), to be one of the following: Controller account, (obviously) not increasing the staked value. Stash account, not increasing the staked value. From 0ac36d592377225160f0d996d8226543f4401f8c Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Fri, 7 Jul 2023 20:15:11 +0300 Subject: [PATCH 34/35] Update Reward-calculation.md removed the highlighting --- system/validator_revard/Reward-calculation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system/validator_revard/Reward-calculation.md b/system/validator_revard/Reward-calculation.md index a5ea521..a3bfeba 100644 --- a/system/validator_revard/Reward-calculation.md +++ b/system/validator_revard/Reward-calculation.md @@ -69,7 +69,7 @@ Payout (p): 8 joys Payout for each validator (v1 - v4): p / v = 8 / 4 = 2 tokens -### Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. +Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked. ## Running Multiple Validators It is possible for a single entity to run multiple validators. Running multiple validators may provide a better risk/reward ratio. Assuming you have enough joys, or enough stake nominates your validator, to ensure that your validators remain in the validator set, running multiple validators will result in a higher return than running a single validator. From 66a9fc1e5d01ff8a75b7b01c0741ed4b277f9d05 Mon Sep 17 00:00:00 2001 From: goooooproject <36838076+goooooproject@users.noreply.github.com> Date: Sat, 8 Jul 2023 07:59:30 +0300 Subject: [PATCH 35/35] Rename README1.md to CHANGELOG.md --- system/validator_revard/{README1.md => CHANGELOG.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename system/validator_revard/{README1.md => CHANGELOG.md} (100%) diff --git a/system/validator_revard/README1.md b/system/validator_revard/CHANGELOG.md similarity index 100% rename from system/validator_revard/README1.md rename to system/validator_revard/CHANGELOG.md