Part 2: Technical Overview

Rewards

Introduction

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.

1. 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.
2. Proposing beacon chain blocks.
3. 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.

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.

Eligibility for rewards

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.

Rewards scale with effective balance

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.

If a validator has $n$ increments (that is, an effective balance of $n \times$ EFFECTIVE_BALANCE_INCREMENT, or $n$ ETH in other words) then its expected¹ income per epoch is $nb$, where $b$ is the base reward per increment.

For the regular attestations that occur every epoch, this is achieved explicitly by multiplying the base reward by the number of increments in get_base_reward().

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 $\frac{n}{T}$, where $T$ 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 compute_proposer_index() and get_next_sync_committee_indices() for the details.

Attestation rewards

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.

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 $\frac{W_s + W_t + W_h}{W_{\Sigma}}nb$, or $0.84375nb$.

The full matrix of possible weights for an attestation reward is as follows. In each case we need to multiply by $\frac{nb}{W_{\Sigma}}$ to get the actual reward.

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, $T$ is the total number of increments of active validators (the sum of their effective balances in ETH terms).

Correctness

"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.

Timeliness

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 $\frac{1}{d}$, where $d$ 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 $\lfloor \sqrt{\tt SLOTS\_PER\_EPOCH} \rfloor = \lfloor \sqrt{32} \rfloor = 5$, 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.²

Remarks

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, yet 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.

Proposer rewards for attestations

If the attestations in a block are worth a total of $R$ 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 $I_A$ 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.

Sync committee rewards

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 500,000 validators, the expected interval between being chosen for sync committee duty is around 37 months. However, during the 27-hour period of participation the rewards are relatively very large.

Sync committee participants receive a reward for 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 $T$ 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 in respect of their sync contributions is then

Proposer rewards for sync committees

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 proposers for including sync committee contributions is

Remarks on proposer rewards

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 $R$ is the validator reward for a duty, then the proposer reward is $\frac{W_p}{W_{\Sigma} - W_p}R$. 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 $\frac{8}{56} = \frac{1}{7}$ which means that $\frac{7}{8}$ of rewards go to validators performing duties and $\frac{1}{8}$ 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.

This equivalence ensures that the interests of attesters and proposers are aligned.

Total issuance

To check that the calculations above are consistent with our claim that the maximum issuance by the beacon chain per epoch is $Tb$ 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

as expected.

Rewards in numbers

The following calculations are based on 500 thousand active validators, all performing perfectly and all with 32 ETH of effective balance.

• Base reward per increment
  • $b = \frac{1{,}000{,}000{,}000 \times 64}{\sqrt{32{,}000{,}000{,}000 \times 500{,}000}} = 505$ Gwei
• Value of a single attestation
  • $R_A = \frac{14 + 26 + 14}{64}32b = 13{,}635$ Gwei
• Value of a single sync committee contribution
  • $R_Y = \frac{2}{32 \times 512 \times 64}500{,}000 \times 32b = 15{,}411$ Gwei
• Value of a block proposal due to attestations
  • $R_{A_P} = \frac{500{,}000}{32}\frac{8}{64-8}R_A = 30{,}435{,}267$ Gwei
  • 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
  • $R_{Y_P} = 512\frac{8}{64-8}R_Y = 1{,}127{,}204$ Gwei

Putting it all together, the total available reward per epoch across all validators is $500{,}000R_A + 32(512R_Y + R_{A_P} + R_{Y_P}) = 8{,}080{,}000{,}000$ Gwei (to 5 significant figures)

Finally, as a check-sum, $Tb = 500{,}000 \times 32b = 8{,}080{,}000{,}000 \text{ Gwei} = 8.080 \text{ ETH}$ issued per epoch.

Individual validator rewards vary

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 $nb$ per epoch.

The following chart shows the expected distribution of annual rewards for 500,000 validators, all participating perfectly, each with 32 ETH of effective balance. The mean reward is 1.3302 ETH/year (the 4.16% number from earlier), and the median 1.3123 ETH/year, but there is a large standard deviation of 0.1037 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.2175 ETH in rewards over the year, and 10% more than 1.4704 ETH, due solely to randomness in assigning duties.

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 additionally receive the transaction priority fees from execution payloads, and potentially MEV-related income as well. These can 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.

Rewards scale with participation

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 $0.75 \times \frac{W_h}{W_{\Sigma}}nb$ 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 $p$, the reward for a fully correct attestation is $0.844nbp$, and the penalty for a missed attestation is $0.625Tb$. This gives us a net issuance of $p^2(0.844Tb) - (1-p)(0.625Tb)$. The positive root of this is $p = 56.7\%$. 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.

Discouragement attacks

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 encourage 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.

See also

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 are analysed in a paper by Vitalik.