Part 2: Technical Overview

The Incentive Layer

Slashing

  • Validators are slashed for breaking very specific protocol rules that could be part of an attack on the chain.
  • Slashed validators are exited from the beacon chain and receive three types of penalty.
  • Correlated penalties mean that punishment is light for isolated incidents, but severe when many validators are slashed in a short time period.
  • Block proposers receive rewards for reporting evidence of slashable offences.

Introduction

Slashing occurs when validators break very specific protocol rules when submitting attestations or block proposals which could constitute attacks on the chain. Getting slashed means losing a potentially significant amount of stake and being ejected from the protocol. It is more "punishment" than "penalty". The good news is that stakers can take simple precautions to protect against ever being slashed.

Validators' stakes can be slashed for two distinct behaviours:

  1. as attesters, for breaking the Casper commandments, the two rules on voting for source and target checkpoints; and
  2. as proposers, for proposing two different blocks at the same height (equivocation).

The slashing of misbehaving attesters is what underpins Ethereum 2.0's economic finality guarantee by enforcing the Casper FFG protocol rules.

Proposer slashing, however, is not part of the Casper FFG protocol, and is not directly related to economic finality. It punishes a proposer that spams the block tree with multiple blocks that could partition the network, for example in a balancing attack.

As with penalties, the amounts removed from validators' beacon chain accounts due to slashing are effectively burned, reducing the overall net issuance of the beacon chain.

The cost of being slashed

When it comes to the punishment for being slashed it does not matter which rule was broken. All slashings are dealt with in the same way.

The initial penalty

Slashing is triggered by the evidence of the offence being included in a beacon chain block. Once the evidence is confirmed by the network, the offending validator (or validators) is slashed.

The offender immediately has one sixty-fourth (MIN_SLASHING_PENALTY_QUOTIENT_ALTAIR) of its effective balance deducted from its actual balance. This is a maximum of 0.5 ETH due to the cap on effective balance.

This initial penalty was introduced to make it somewhat costly for validators to self-slash for any reason.

Along with the initial penalty, the validator is queued for exit, and has its withdrawability epoch set to around 36 days (EPOCHS_PER_SLASHINGS_VECTOR, which is 8192 epochs) in the future.

During Phase 0, this initial penalty was 1128\frac{1}{128} of the offender's effective balance. It is expected to be raised to its full value of 132\frac{1}{32} of the effective balance, a maximum of 1 ETH, as part of The Merge.

The correlation penalty

At the half way point of its withdrawability period (18 days after being slashed) the slashed validator is due to receive a second penalty.

This second penalty is based on the total amount of stake slashed during the 18 days before and after our validator was slashed. The idea is to scale the punishment so that a one-off event posing little threat to the chain is only lightly punished, while a mass slashing event that might be the result of an attempt to finalise conflicting blocks is punished to the maximum extent possible.

To be able to calculate this, the beacon chain maintains a record of the effective balances of all validators that were slashed during the most recent 8192 epochs (about 36 days).

The correlated penalty is calculated as follows.

  1. Compute the sum of the effective balances (as they were when the validators were slashed) of all validators that were slashed in the previous 36 days. That is, for the 18 days preceding and the 18 days following our validator's slashing.
  2. Multiply this sum by PROPORTIONAL_SLASHING_MULTIPLIER_ALTAIR, but cap the result at total_balance, the total active balance of all validators.
  3. Multiply the slashed validator's effective balance by the result of #2 and then divide by the total_balance. This results in an amount between zero and the full effective balance of the slashed validator. That amount is subtracted from its actual balance as the penalty. Note that the effective balance could exceed the actual balance in odd corner cases, but decrease_balance() ensures the balance does not go negative.

The slashing multiplier in Altair is set to 2. With SS being the sum of increments in the list of slashed validators over the last 36 days, BB my effective balance, and TT the total increments, the calculation looks as follows.

Correlation penalty=min(B,2SBT)\text{Correlation penalty} = \min(B, \frac{2SB}{T})

Interestingly, due to the way the integer arithmetic is constructed in the implementation the result of this calculation will be zero if 2SB<T2SB < T. Effectively, the penalty is rounded down to the nearest whole amount of Ether. As a consequence, when there are few slashings there is no extra correlated slashing penalty at all, which is probably a good thing.

The intention is to raise the proportional slashing multiplier from 2 to 3 around The Merge, three being its "correct" cryptoeconomic value. To successfully finalise conflicting blocks at least one third of validators need to break attestation slashing rules. With the multiplier set to 3, that third would lose their entire stakes through this mechanism, which is optimal for security.

Other penalties

Validators that exit normally (by sending a voluntary exit message) are expected to participate only until their exit epoch, which is normally only a couple of epochs later.

A validator that is slashed continues to receive attestation penalties until its withdrawable epoch, which is set to 8192 epochs (36 days) after the slashing, and they are unable to receive any attestation rewards during this time. They are also subject for this entire period to any inactivity leak that might be in operation. Whatever the slashed validator does, it is penalised exactly as if it is failing to participate.1

So, in addition to the initial slashing penalty and the correlation penalty, there is a further penalty of up to 819214+266432b=106,987,520 Gwei=0.107 ETH8192\frac{14 + 26}{64}32b = 106{,}987{,}520 \text{ Gwei} = 0.107 \text{ ETH}, based on 300k validators, assuming that the chain is not in an inactivity leak. And (much) more if it is.

Slashed validators are eligible to be selected to propose blocks until they reach their exit epoch, but those blocks will be considered invalid, so there is no proposer reward available to them. This is in preference to immediately recomputing the duties assignments which would break the lookahead guarantees they have. (The proposer selection algorithm could easily be modified to skip slashed validators, but that is not how it is implemented currently.)

In an interesting edge case, however, slashed validators are eligible to be selected for sync committee duty until they reach their exit epoch and to receive the rewards for sync committee participation. Though the odds of this happening, absent a mass slashing event, are pretty tiny.

The value of reporting a slashing

In order for the beacon chain to verify slashings and take action against the offender, the evidence needs to be included in a beacon block. To incentivise validators to make the effort there is a specific reward for the proposer of a block that includes slashings.

The proposer reward

At the point of the initial slashing report being included in a block, the proposer of the block receives a reward of validator.effective_balance / WHISTLEBLOWER_REWARD_QUOTIENT, which is B/512B / 512 if BB is the effective balance of the validator being slashed.

A report of a proposer slashing violation can slash only one validator, but a report of an attestation slashing violation can simultaneously slash up to an entire committee, which might be hundreds of validators. This could be extremely lucrative for the proposer including the reports. A single block can contain up to 16 proposer slashing reports and up to 2 attester slashing reports.

Note that no new issuance is required to pay for this reward. The proposer reward is much less than the initial slashing applied to the validator, so the net issuance due to a slashing event is always negative.

The whistleblower reward

In the code implementing the reward for reporting slashing evidence there is provision for a "whistleblower reward", with the whistleblower receiving 78\frac{7}{8} of the above reward and the proposer 18\frac{1}{8}.

The idea is to incentivise nodes that search for and discover evidence of slashable behaviour, which can be an intensive process.

However, this functionality is not currently used on the beacon chain, and the proposer receives both the whistleblower reward and the proposer reward, as above. The challenge is that it is too easy for a proposer just to steal a slashing report, so there's no point incentivising them separately. It's not an ideal situation, but so far there seem to be sufficient altruistic slashing detectors running on the beacon chain for slashings to be reported swiftly. There only needs to be one in practice.

This functionality may become useful in future upgrades.

See also

From the spec:

  • The initial slashing penalty and proposer reward are applied in slash_validator() during block processing.
  • The correlation slashing penalty is applied in process_slashings() during epoch processing.

In the Serenity Design Rationale Vitalik gives some further background on why Ethereum 2.0 includes proposer slashing. It is specifically intended to discourage stakers from simultaneously running primary and backup nodes.


  1. It's not clear to me why we have such a large hang-over from being slashed during which validators continue to receive penalties. It seems like kicking a man when he's down, especially since slashed validators are locked in for twice as long as needed to calculate the correlation penalty. Vitalik says that this measure "is included to prevent self-slashing from being a way to escape inactivity leaks." But validators don't need to self-slash to avoid this; they could just make a normal voluntary exit.

Created by Ben Edgington. Licensed under CC BY-SA 4.0. Published 2023-07-01 13:17 UTC. Commit 8fa708b.