Part 2: Technical Overview

The Incentive Layer

Penalties

  • Validators that do not fulfil their assigned duties are penalised by losing small amounts of stake.
  • Receiving a penalty is not the same as being slashed!
  • Break-even uptime for a validator is around 43%.

Introduction

Incentivisation of validators on the beacon chain is a combination of carrot and stick. Validators are rewarded for contributing to the chain's security, and penalised for failing to contribute. As we shall see, penalties are quite mild. Nonetheless they provide good motivation for stakers to ensure that their validator deployments are running well.

It's common to hear of the penalties for being offline being referred to as "getting slashed". This is incorrect. Being slashed is a severe punishment for very specific misbehaviours, and results in the validator being ejected from the protocol in addition to some or all of its stake being removed.

Penalties are subtracted from validators' balances on the beacon chain and effectively burned, so they reduce the net issuance of the beacon chain.

Attestation penalties

Attestations are penalised for being missing, late, or incorrect. We'll lump these together as "missed" for conciseness.

Attesters are penalised for missed CASPER FFG votes, that is, missed source or target votes. But there is no penalty for a missed head vote. If a source vote is incorrect, then the target vote is missed; if the source or target vote is incorrect then the head vote is missed.

Let's update our rewards matrix to give the full picture of penalties and rewards for attestations. Recall that this shows the weights; we need to multiply by nbWΣ\frac{nb}{W_{\Sigma}} to get the actual reward.

Timeliness 1 slot <= 5 slots <= 32 slots > 32 Slots (missing)
Wrong source WsWt-W_s-W_t WsWt-W_s-W_t WsWt-W_s-W_t WsWt-W_s-W_t
Correct source only WsWtW_s-W_t WsWtW_s-W_t WsWt-W_s-W_t WsWt-W_s-W_t
Correct source and target only Ws+WtW_s+W_t Ws+WtW_s+W_t Ws+Wt-W_s+W_t WsWt-W_s-W_t
Correct source, target and head Ws+Wt+WhW_s+W_t+W_h Ws+WtW_s+W_t Ws+Wt-W_s+W_t WsWt-W_s-W_t

For more intuition, we can put in the numbers, Ws=14W_s = 14, Wt=26W_t = 26, Wh=14W_h = 14, and normalise with WΣ=64W_{\Sigma} = 64:

Timeliness 1 slot <= 5 slots <= 32 slots > 32 Slots (missing)
Wrong source 0.625-0.625 0.625-0.625 0.625-0.625 0.625-0.625
Correct source only 0.188-0.188 0.188-0.188 0.625-0.625 0.625-0.625
Correct source and target only +0.625+0.625 +0.625+0.625 +0.188+0.188 0.625-0.625
Correct source, target and head +0.844+0.844 +0.625+0.625 +0.188+0.188 0.625-0.625
Break-even uptime

Stakers sometimes worry that downtime will be very expensive. To examine this, we can estimate the break-even uptime. We'll ignore sync committee participation since that is so rare, so only attestations are relevant for the calculation.

We'll assume that, when online, the validator's performance is perfect, and that the rest of the validators are performing well (both of which are pretty good approximations to the beacon chain's actual performance over its first year).

If pp is the proportion of time the validator is online, then its net income is, 0.844p0.625(1p)=1.469p0.6250.844p - 0.625(1-p) = 1.469p - 0.625. This is positive for p>42.5%p > 42.5\%. So, if your validator is online more than 42.5% of the time, you will be earning a positive return.

A useful rule of thumb is that it takes about a day of uptime to recover from a day of downtime.

Sync committee penalties

The small group of validators currently on sync committee duty receive a reward in each slot that they sign off on the correct head block (correct from the proposer's point of view).

Validators that don't participate (sign the wrong head block or don't show up at all) receive a penalty exactly equal to the reward they would have earned for being correct. And the block proposer receives nothing for the missing contribution.

Historical note: Since sync committee participation is rare for any given validator, and since rewards are significant, there were concerns with earlier designs that the resulting variance in rewards for validators would be quite unfair. Small stakers might prefer to join staking pools rather than solo stake in order to smooth out the variance, similarly to how proof of work mining pools have sprung up.

One suggested approach to reducing the variance was not to reward sync committee participation at all, but rather to raise overall reward levels for everyone and to penalise the sync committee validators if they did not participate. Ultimately the approach adopted was to reduce the length of sync committees (meaning lower rewards, but more often), reduce the proportion of total reward for participation, and introduce a penalty for non-participation – kind of half-way to the other proposal.

The main reasons1 for not adopting the former proposal, although it is elegant, seem to be around the psychology of being explicitly penalised but never explicitly rewarded. The penalty for not participating in a sync committee would be substantially bigger than the attestation reward over an epoch. In addition, participation is not entirely in the validator's own hands: it depends on the next block proposer being on the right fork. There were also concerns about changing the clean relationship between proposer rewards and the value of the duties they include in blocks.

Remarks on penalties

There are no explicit penalties related to block proposers.

In particular, there is no explicit penalty for failing to include deposits from the Eth1 chain, nor any direct incentive for including them. However, if a block proposer does not include deposits that the rest of the network knows about, then its block is invalid. This provides a powerful incentive to include outstanding deposits.

Also note that penalties are not scaled with participation as rewards are.

See also

The detailed penalty calculations are defined in the spec in these functions:


  1. The quite interesting discussion remains on the Ethereum R&D Discord.

Created by Ben Edgington. Licensed under CC BY-SA 4.0. Published 2022-05-12 12:26 UTC. Commit 0cc9f0b.