Running a validator node on the Tangle Network allows you to connect to the network, sync with a bootnode, obtain local access to RPC endpoints, and also author blocks. The network rewards successful validators (users running validator nodes and actively producing blocks) by paying a set amount of network tokens as rewards. Validators are chosen using an algorithm AURA (opens in a new tab) that works to give every validator in the active set, a chance at authoring a block.
For every era (a period of time approximately 6 hours in length in Tangle), 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 Chain.
- producing a reference to a previously unreferenced uncle block.
- producing a referenced uncle block.
An uncle block is a 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 TNT 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 Tangle's inflation model, and not on the number of payable actions (f.e., authoring a new block) executed.
In this case, analyzing the expected value of staking rewards will paint a better picture as the weight of era points of validators and para-validators in the reward average are taken into consideration.
This should only serve as a high-level overview of the probabilistic nature for staking rewards.
pe= para-validator era points,
ne= non-para-validator era points,
EV= expected value of staking rewards,
EV(pe) has more influence on the
EV(pe) has a more weighted probability on the
EV, the increase in variance against the
EV becomes apparent between the different validator pools (aka. validators in the active set and
the ones chosen to para-validate).
v= the variance of staking rewards,
p= number of para-validators,
w= number validators in the active set,
v ↑ if
w ↑, as this reduces
w, with respect to
v is expected, and initially keeping
p ↓ using the same para-validator set for
all parachains ensures availability and approval voting. In addition, despite
v ↑ on an
basis, over time, the amount of rewards each validator receives will equal out based on the
continuous selection of para-validators.
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.
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 TNT 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.
v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as
who had only 7 tokens staked.
Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough TNT to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more TNT for a validator with 18 TNT staked than one with 9 TNT staked.
Running multiple validators does not absolve you of the consequences of misbehavior. Polkadot 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,
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 TNT
nominating it and
v2 only has 10. If you nominate
v1, it now has
90 + 10 = 100 TNT, and you
will get 10% of the staking rewards for the next era. If you nominate
v2, it now has
10 + 10 = 20 TNT 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 TNT in each case.