Part 2: Technical Overview

Slashing

Introduction

Slashing occurs when validators make attestations or block proposals that break very specific protocol rules. It applies to behaviour that could potentially be part of an attack on the chain. Getting slashed means losing a 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.

The behaviours that lead to slashing are as follows.

1. Related to Casper FFG consensus,
   • making two differing attestations for the same target checkpoint, or
   • making an attestation whose source and target votes "surround" those in another attestation from the same validator.
2. Related to LMD GHOST consensus,
   • proposing more than one distinct block at the same height, or
   • attesting to different head blocks, with the same source and target checkpoints¹.

All of these slashable behaviours relate to "equivocation", which is when a validator contradicts something it previously advertised to the network.²

The slashing conditions related to Casper FFG underpin Ethereum 2.0's economic finality guarantee. They effectively impose a well-determined price on reverting finality.

The slashing conditions related to LMD GHOST are less robustly supported by consensus theory, and are not directly related to economic finality. Nonetheless, they punish bad behaviour that could lead to serious issues such as the balancing attack. Since we already had the slashing mechanism available for use with Casper FFG, it was simple enough to extend it to LMD GHOST.

As with penalties, any amount removed from validators' beacon chain accounts due to slashing is 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 $\frac{1}{32}$ (MIN_SLASHING_PENALTY_QUOTIENT_BELLATRIX) of its effective balance deducted from its actual balance. This is a maximum of 1 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 the initial penalty was $\frac{1}{128}$ of the offender's effective balance, and during Altair, $\frac{1}{64}$. It was raised to its full value of $\frac{1}{32}$ of the slashed validator's effective balance, a maximum of 1 ETH, in the pre-Merge Bellatrix upgrade.

The correlation penalty

At the halfway 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_BELLATRIX, 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 Bellatrix is set to 3. With $S$ being the sum of increments in the list of slashed validators over the last 36 days, $B$ my effective balance, and $T$ the total increments, the calculation looks as follows.

Interestingly, due to the way the integer arithmetic is constructed in the implementation the result of this calculation will be zero if $3SB < 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 proportional slashing multiplier was increased gradually through the early deployment of the beacon chain. At Genesis, it was set to one (PROPORTIONAL_SLASHING_MULTIPLIER), at Altair it was increased to two (PROPORTIONAL_SLASHING_MULTIPLIER_ALTAIR), and at Bellatrix set to its final value of three (PROPORTIONAL_SLASHING_MULTIPLIER_BELLATRIX). This was intended to punish slashed validators less harshly while we were becoming accustomed to running the beacon chain. As it happened, no correlated slashings occurred that incurred a penalty greater than zero under this mechanism.

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

So, in addition to the initial slashing penalty and the correlation penalty, there is a further penalty of up to $8192\frac{14 + 26}{64}32b = 82{,}739{,}200 \text{ Gwei} = 0.0827 \text{ ETH}$, based on 500k validators, where $b$ is the base reward per increment. This assumes that the chain is not in an inactivity leak; the penalties will be much higher 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. The odds of this happening, though, in the absence of 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 / 512$ if $B$ 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 very 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 $\frac{7}{8}$ of the above reward and the proposer $\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.