- Validators receive rewards for making attestations according to their view of the chain, proposing blocks, and participating in sync committees in varying proportions.
- Votes that make up attestations must be both correct and timely in order to be rewarded.
- The proposer's reward is a fixed proportion (1/7) of the total reward for all the duties it is including in its block.
- A validator's expected long-term reward is per epoch (number of increments times the base reward per increment), but there is significant variance around that due to the randomness of proposer and sync committee assignments.
- Rewards are scaled both with a validator's effective balance and with the total participation rate of the validator set.
- The need to defend against discouragement attacks has shaped various aspects of the protocol.
In this section we will consider only rewards. We'll cover penalties in the next section.
The beacon chain protocol incentivises each validator to behave well by providing rewards for three activities as follows.
- Attesting to its view of the chain as part of the consensus protocol:
- voting for a source checkpoint for Casper FFG;
- voting for a target checkpoint for Casper FFG; and
- voting for a chain head block for LMD-GHOST.
- Proposing beacon chain blocks.
- Signing off on blocks in the sync committees that support light clients.
The first of these, making attestations, happens regularly every epoch and accounts for the majority a validator's total expected reward.
However, validators are selected at random to propose blocks or participate in sync committees, so there is a natural variance to the latter two rewards. Over the long run, the expected proportion of rewards earned for each activity breaks down as per the following chart.
The proportion of a validator's total reward derived from each activity.
These proportions are set by the incentivisation weights in the spec. For convenience, I've assigned a symbol to each weight in the last column.
One further reward is available to block proposers for reporting violations of the slashing rules, but this ought to be very rare and we will ignore it in this section (see Slashing for more on this).
Rewards are newly created Ether that is simply added to validators' balances on the beacon chain.
There are three relevant milestones in a validator's lifecycle: its activation epoch, its exit epoch, and its withdrawable epoch. Eligibility for rewards, penalties and slashing vary based on these.
Validators may receive rewards only between their activation and exit epochs. Note that, after submitting a voluntary exit, there may be a delay while the validator moves through the exit queue until its exit epoch is passed. The validator is expected to participate as usual during this period.
Similarly, validators receive penalties only between their activation and exit epochs. The exception to this is slashed validators. As a special case, slashed validators continue to receive penalties until they reach their withdrawable epoch, which may be long after their exit epoch.
All unslashed validators that are between their activation epoch and their withdrawable epoch are liable to being slashed.
As described earlier, all rewards are scaled in proportion to a validator's effective balance. This reflects the fact that a validator's influence (weight) in the protocol is proportional to its effective balance.
For the regular attestations that occur every epoch, this is achieved explicitly by multiplying the base reward by the number of increments in
For the random elements – block proposals and sync committee participation – the scaling is achieved implicitly by modifying the probability that a validator is selected for duty to be proportional to , where is the total number of increments of the active validator set. So, if your effective balance is 24 ETH, then you are 25% less likely to be selected to propose a block or join a sync committee than a validator with 32 ETH. See
get_next_sync_committee_indices() for the details.
The largest part, 84.4%, of validators' rewards come from making attestations. Although committee and slot assignments for attesting are randomised, every active validator will be selected to make exactly one attestation each epoch.
Attestations receive rewards only if they are included in beacon chain blocks. An attestation contains three votes. Each vote is eligible for a reward subject to conditions.
|Correct source||Within 5 slots|
|Correct source and target||Within 32 slots|
|Correct source, target and head||Within 1 slot|
These are cumulative, so the maximum attestation reward per epoch (for getting all three votes correct and getting the attestation included the next block) is , or .
The full matrix of possible weights for an attestation reward is as follows. In each case we need to multiply by to get the actual reward.
|Timeliness||1 slot||<= 5 slots||<= 32 slots||> 32 Slots (missing)|
|Correct source and target||0|
|Correct source, target and head||0|
But this is not the whole picture: we will also need to account for penalties for incorrect or late attestations.
The maximum total issuance per epoch across all validators is
where, once again, is the total number of increments of active validators (the sum of their effective balances in ETH terms).
"Correct" in the above means that the attestation agrees with the view of the blockchain that the current block proposer has. If the attesting validator votes for different checkpoints or head blocks then it is on a different fork and that vote is not useful to us. For instance, if the source checkpoint vote is different from what we as proposer think it ought to be, then our view of the chain's history is fundamentally different from the attester's, and so we must ignore their attestation. The attestation will instead receive rewards in blocks on the other fork, and eventually one fork or the other fork will win. To disincentivise attacks it is important that only participants in the winning chain receive rewards.
One of the changes brought in with Altair was a tightening of the timeliness requirements for attestations. Previously, there were rewards for correctness and a separate reward for timely inclusion that declined as , where was the inclusion distance in slots, up to a maximum of 32 slots. This led to oddities, like it being worth waiting slightly longer to make sure to get the head vote correct since that was worth more than any loss due to lateness of inclusion, even though a late head vote is pretty much useless.
The new timeliness reward better reflect the relative importance of the votes. A head vote that is older than one slot is not useful, so it gets no reward, Target votes are always useful, but we only want to track attestations pertaining to the current and previous epochs, so we ignore them if they are older than 32 slots.
The choice of distance for including the source vote is interesting. It is chosen to be , which is the geometric mean of 1 and 32, the head and target values. It's a somewhat arbitrary choice, but is intended to put a fully correct attestation on an exponentially decreasing curve with respect to timeliness: each step down in (net) reward happens after an exponentially increasing number of slots.2
It is plausible that setting the inclusion distance for correct source to 5 gives a kind of exponential reduction in reward with time. This graph shows the net reward (reward + penalty) for a completely correct attestation as it gets older plotted against an exponential curve for comparison.
Note that the attester does not have full control over whether it receives rewards or not. An attester may behave perfectly, but if the next block is skipped because the proposer is offline, then it will not receive the correct head block reward. Or if the next proposer happens to be on a minority fork, the attester will again forgo rewards. Or if the next proposer's block is late and gets orphaned - subsequent proposers are supposed to pick up the orphaned attestations, but there can be considerable delays if block space is tight. There are countless failure modes outside the attester's control.
It often perplexes stakers when, to all intents and purposes, their validators seem to be working perfectly but they still miss out on rewards or receive penalties. But this is the nature of permissionless, global, peer-to-peer networks. It is a testament to the quality of the protocol and the various client implementations that missed rewards have been surprisingly rare on the beacon chain so far.
If the attestations in a block are worth a total of in rewards to the attesters, then the proposer that includes the attestations in a block receives a reward of
Thus, over an epoch, the maximum total issuance due to proposer rewards in respect of attestations is
with being the maximum issuance to attesters per epoch, as above.
Thus, a proposer is strongly incentivised to include high value attestations, which basically means including them quickly, and including well-packed, as correct as possible aggregates.
Once every 256 epochs (27.3 hours), 512 validators are selected to participate in the sync committee. For any given validator this will happen rarely; with 300,000 validators, the expected interval between being chosen for duty is around 22 months. However, during the 27 hour period of participation the rewards are relatively very large.
Sync committee participants receive a reward every slot that they correctly perform their duties. With 512 members in the committee, and 32 slots per epoch, the reward per validator per slot for correct participation is
The here is the total increments of the whole active validator set, so this is a large number. The per-epoch per-validator reward is 32 times this.
The maximum issuance per epoch to sync committee members is then
As with attestations, the block proposer that includes the sync committee's output receives a reward proportional to the reward of the whole committee:
So the maximum issuance per epoch to sync committee proposers is
You'll note that, for both attestations and sync committees, the proposer reward for including them in a block is a fixed fraction of the validator reward. If is the validator reward for a duty, then the proposer reward is . In Vitalik's words, "The proposer reward for a duty is the attester reward for that duty, multiplied by the proposer reward as a fraction of everything but the proposer reward" (emphasis his).
This factor works out to be which means that of rewards go to validators performing duties and to the proposers including the evidence in blocks.
In the following charts, I have separated out the validator rewards from the proposer rewards, and we can see that they have exactly the same division among the duties. The chart on the right should probably be one seventh of the size of the one on the left for true accuracy.
On the left, the breakdown of expected rewards for validators for performing duties. On the right, the breakdown of rewards for proposers for including evidence of those duties.
This equivalence ensures that the interests of attesters and proposers are aligned.
To check that the calculations above are consistent with our claim that the maximum issuance by the beacon chain per epoch is Gwei, let us sum up the issuance due to the four rewards: attester rewards, proposer rewards in respect of attestation inclusion, sync committee rewards, and proposer rewards in respect of sync committee inclusion. The total maximum issuance per epoch is
The following calculations are based on 300 thousand active validators, all performing perfectly and all with 32 ETH of effective balance.
- Base reward per increment
- Value of a single attestation
- Value of a single sync committee contribution
- Value of a block proposal due to attestations
- Note: this can actually be higher if the chain is not performing perfectly, as after a skip slot the proposer can include high value attestations from the missed slot.
- Value of a block proposal due to sync committee contributions
Putting it all together, the total available reward per epoch across all validators is Gwei (to 5 significant figures)
Finally, as a check-sum, .
Actual individual validator returns, even on an optimally running beacon chain, will vary above and below the expected amounts, since block proposals and sync committee duties are assigned randomly. This leads to variance in the rewards, with some validators earning more and some earning less. Nonetheless, an average validator over a long period can expect to earn a return in line with per epoch.
The following chart shows the expected distribution of rewards for 300,000 validators, all participating perfectly, each with 32 ETH of effective balance. The mean reward is 1.7177 ETH/year (the 5.37% number from earlier), and the median 1.7188 ETH/year, but there is a large standard deviation of 0.1025 due to the randomness of being selected to propose blocks or participate in sync committees. In fact, ten percent of validators will earn less than 1.596 ETH in rewards over the year, and 10% more than 1.866 ETH, due solely to randomness in assigning duties.
Distribution of rewards for 300,000 validators with 32 ETH staked.
A few remarks on this.
First, the Altair upgrade did not change the expected reward per validator, but it did change the variance considerably. This is due to an increase in the block reward of a factor of four and the introduction of sync committees, with a corresponding reduction in attestation rewards. Since block proposals and sync committee participation are randomly assigned, while attestation rewards are steady, Altair greatly increased the variance in actual rewards. For an analysis of the change, see Pintail's article.
Second, there are further sources of variation that the above analysis doesn't account for. For example, if my validator proposes a block right after a skipped slot, in which there was no block, then my block proposal could be worth up to 71.4% more than a normal block proposal. This is because I get to include attestations from the skipped slot as well as from my own slot, and benefit from the extra source and target votes (but not the extra head votes, which will be too late, or the extra sync committee inclusion).
Third (and most significantly), post-Merge, validators will additionally receive the transaction tips from execution blocks, and potentially MEV-related income as well. These will substantially increase the percentage earnings, and variance in earnings, for stakers, but will not affect overall issuance on the beacon chain since they come from recycled Ether rather than new issuance.
One surprising aspect of attestation rewards not so far mentioned is that they are scaled in proportion to participation. That is, for each duty (source, target, head vote) the attester's reward is scaled by the proportion of the total stake that made the same vote.
For example, if I made a correct head vote, and validators with 75% of the total effective balance increments made the same head vote, then I would receive reward for that vote.
A hand-wavy reason for this is that this scaling makes it to my advantage to help other validators get their attestations included. Several aspects of the protocol are not explicitly incentivised yet are somewhat expensive, such as forwarding gossip messages and attestation aggregation duty. This scaling provides me with an implicit reward for helping out other validators by providing these services: if they perform better, then I perform better.
For a more quantitative analysis, see on discouragement attacks below.
One interesting side-effect of this is that, if participation drops by 10% (due to 10% of validators being offline, say), then total issuance of rewards due to attestations will fall by 19%, in addition to a further reduction from penalties.
We can calculate the participation rate at which net issuance due to attestations turns negative. With a participation rate , the reward for a fully correct attestations is , and the penalty for a missed attestation is . This gives us a net issuance of . The positive root of this is . But since this is below the 2/3 participation rate for finalisation, the inactivity leak will kick-in before we reach this level and completely change the reward and penalty profile, so the calculation is of theoretical interest only.
Note that the proposer reward is not scaled like this – proposers are already well incentivised to include all relevant attestations – and neither are sync committee rewards. Penalties do not scale with participation, either.
Quoting from Vitalik's Discouragement Attacks paper,
A discouragement attack consists of an attacker acting maliciously inside a consensus mechanism in order to reduce other validators' revenue, even at some cost to themselves, in order to encourage the victims to drop out of the mechanism.
Attackers might do this to gain more rewards with fewer participants in the system. Or they might do it as preparation for an attack on the chain: by reducing the number of validators they decrease their own cost of attack.
The paper goes into some quantitative analysis of different kinds of discouragement attacks. I would _en_courage you to read it and think through these things. As per the conclusion:
In general, this is still an active area of research, and more research on counter-strategies is desired.
Some parts of the beacon chain design that have already been influenced by a desire to avoid discouragement attacks are:
- the inverse square root scaling of validator rewards;
- the scaling of rewards with participation;
- the zeroing of attestation rewards during an inactivity leak; and
- rate limiting of validator exits, which means that an attacker needs to sustain an attack for longer, at greater cost to achieve the same ends.
The detailed rewards calculations are defined in the spec in these functions:
- Validator rewards for attestations are calculated in
get_flag_index_deltas()as part of epoch processing.
- Proposer rewards for attestations are calculated in
process_attestation()as part of block processing.
- Both validator and proposer rewards for sync committee participation are calculated in
process_sync_aggregate()as part of block processing.
The discussion of the variance of rewards is based on Pintail's analysis of Altair. The code I used to generate the stats and the chart are based on the code in that article.
Discouragement Attacks attacks are analysed in a paper by Vitalik.
I'm using the word "expected" in its technical sense here. Due to randomness there is a chance that some validators earn less and a chance that some validators earn more. The averagely lucky validator can expect their rewards to average out to Gwei per epoch over the long term.↩
This is taken from a conversation on the Ethereum R&D Discord server:
The rationale for the number 5 is just that 5 is geometrically halfway in between 1 and 32
And so we get the closest that makes sense to a smooth curve in terms of rewarding earlier inclusion
ah I mean on an exponential curve, not quadratic
To me exponential feels more logical
What's a bigger improvement in quality, 4 slot delay vs 6 slot delay, or 20 slot delay vs 23 slot delay?