How can validators be slashed?
Contents:
Aim of this article
Why does slashing occur
Categories of offences
Reasons for offences
How does slashing occur
Phases of penalisation
Cumulative cost to a validator
Avoiding accidental slashing
Client diversity
Multiple simultaneous clients
Migrating devices
Final notes
Aim of this article
To maintain the reliability and security of Ethereum there is a reliance on over two-thirds of all active validators to be honest. Motivating such honesty is the responsibility of carefully devised rewards and risks for validators. While participating in the network would typically return profitable yields, malicious actions, including double spend attacks, require consequences. This concept is referred to as slashing and involves losing access to a significant portion of a validator’s initial stake (32 ETH that one must invest to be allowed to participate in the network). Throughout this article explanation will be given to what exactly constitutes a slashable offence and the precise effect of being slashed. Importantly it will also be explained how slashing can inadvertently punish validators not intending to act maliciously and how these circumstances can be avoided.
Why does slashing occur
Categories of offences
There are three primary categories of slashable offences to understand. Each category is treated equally (i.e. there is none which would be considered more or less severe) and can be reported by other validators if witnessed.
Reasons for offences
By stipulating such offences the aim is to target behaviours which, accidentally or deliberately, can target weaknesses of Ethereum’s consensus. Specific mention was made earlier to double spend attacks which serve as one of the most obvious (and profitable) examples of attacks which could occur. It also serves as one of the most obvious examples of the principles of slashing in practice. For such an attack to occur in Ethereum requires at least two branches of the chain to exist where a branch is created from each additional block proposed for the same slot. Typically these conflicting branches are ignored as only the block, and hence branch, with the most attestations is considered “canonical” and eventually finalised within 2 epochs (within 64 slots or 6.4 minutes).
If at a later date though a majority of signatures instead attested to another block for the same slot this conflicting branch will be considered “canonical” replacing the original branch entirely. Therefore by preventing the act of proposing or attesting to two blocks for the same slot it wouldn’t be feasible to create the branches necessary to perform a double spend attack. In extension the third category (surrounding attestation) prevents a block being published which ignores a previously finalised block in an attempt to ignore a portion of the “canonical” branch. Discovering these offences and enforcing relevant punishments are what ensures that attacks are infeasible.
How does slashing occur
Phases of penalisation
When a validator witnesses a slashable offence they can report this and have their proof published in a block. Once published the proposer of the block (not necessarily the witness) is able to claim a reward - though they will otherwise be punished if the proof is found to be fraudulent. If genuine the validator who committed the slashable offence enters the first of three phases.
Cumulative cost to a validator
While validators are free to rejoin the network given all other conditions (such as a 32 ETH stake) are met, the accrual of penalties and the extended period of being incapable of earning reward ensures that being slashed is a punishing act. When multiplied by the number of validators that would be required to make an attack technically feasible (expected to be a minimum of 33% of all active validators) and the increasing size of the correlation penalty, an attack becomes financially infeasible. With respect to the current number of active validators and conversion rates at the time of writing this article such penalties may cost the malicious validators up to a cumulative $10B USD.
Avoiding accidental slashing
Client diversity
Not all acts of slashable offences are deliberate though and some validators have been inadvertently punished through the use of over-engineered consensus clients or those that contain bugs. It is important to emphasise that trusted and reviewed clients such as Lighthouse, Prysm or Teku should be used to avoid a majority of possible bugs. Within this same emphasis though it is important to note that using clients such as Teku, Lodestar or Nimbus that are trusted but used by a smaller proportion of validators should be done where possible. This concept is known as client diversity; if Lighthouse or Prysm encounters a bug which causes slashing (improbable but not impossible), the cumulative penalty will be severe due to the greater magnitude of validators being slashed simultaneously.
Multiple simultaneous clients
Besides the use of clients that behave incorrectly the most common mistake to result in accidental slashing is the use of multiple consensus clients for a single validator. Due to operating in multiple independent locations each individual client can make separate decisions about block proposals or attestations. If one instance of a client proposes or attests to one block and another instance proposes or attests to another then this would be an automatic case of double proposal or double attestation respectively. Therefore no two consensus clients should ever be operating with the same keys. Most commonly validators run into trouble with this when attempting to run backup devices if their main device goes offline. Always remember that the penalty for inactivity is significantly less severe than for being slashed.
Migrating devices
Likewise, when migrating devices it is essential that documentation for one’s consensus client is consulted to ensure that keys are successfully removed from the old device and that the new device does not accidentally propose or attest for slots that the old device has already performed. The latter is also worth noting if the device being used has a storage failure. Each consensus client typically stores a database which notes all slots that proposals or attestations have already been performed for by that validator. Backups should always be maintained to prevent any accidental offences that would occur from performing an action for a slot that has already been accounted for. Assuming though that data loss does occur it is possible that the client being used is connected to a global database which can be relied upon to download to the device (once again consulting documentation for the client being used is necessary here).
Final notes
Ensuring that Ethereum is always reliable and safe for business and consumer needs requires mechanisms such as slashing. Without this mechanism, there would be no financial penalty for committing attacks. However, even as an honest user it is important to understand what slashing is and what offences are punishable - much like understanding the laws of a nation. The risks of inadvertent slashing are improbable as long as some of the basic precautions cited above are integrated into one’s setup. If there are any doubts about performing these precautions there are online services available to assist.
