Menu
Menu
On Ethereum, slashing refers to the process of penalising a validator for behaving improperly.
In a Proof-of-Stake (PoS) blockchain like Ethereum, validators are responsible for verifying transactions and adding them to the blockchain. If a validator is found to be behaving in a malicious or dishonest way, it may be slashed. This means that a portion of its stake (the amount of ETH it has staked as collateral) is destroyed by the network as a punishment.
Slashing incentivises validators to act in the best interests of the network. It can occur based on 4 “slashable offences”:
Source: https://eth2book.info/bellatrix/part2/incentives/slashing/
Slashing penalties are the same for all slashable offences, and are listed below:
There is an initial penalty of 1/32 of the effective balance (normally 1 ETH). This penalty is applied immediately once the offence has been identified.
The validator is removed from the validation set and is placed in the exit queue, for ~36 days.
Until the validator leaves the exit queue:
Finally, a special penalty is applied: the severity of this penalty depends on the number of validators who committed a slashable offence a few days before and thereafter. The more validators are slashed, the worse the penalty per validator.
In extreme cases, this special penalty could wipe all of an account’s staked Ether.
🔢 This public spreadsheet from Kiln can help you model the slashing penalties under different scenarios. (Tab: Correlated Slashing Penalties)
The Ethereum network is able to detect slashable offences but does not know why such an offense appears on the network. This offence might be intentional or not.
The main reason for a validator to commit unintentional slashable offence is when two different validators clients (connected to two different beacon nodes) validate for the same validator key.
This kind of setup typically happens when two main validation infrastructures, one active and online and another used as a backup and normally offline, comes online unintentionally at the same time.
In this blog post, we propose to define multiple layers of anti-slashing protection. Each layer is not perfect alone and can let some slashable events through. By stacking all layers, we hope all slashable offences will be caught by at least one layer.
Anti slashing strategies as a Swiss cheese model. By stacking multiple kinds of layers, we intend to avoid the case where an arrow is able to go through all layers without being stopped by at least one of them.
In this post, we will present 4 anti-slashing layers:
GitOps promotes a Git repository as the single source of truth for declarative infrastructure and applications. Using a GitOps workflow, the desired state of the validation system (including the relationship between validator keys and validator clients) is stored in Git.
One validator client is represented by one GitOps file. All public keys the validator client has to validate for are written in the validator client GitOps file. Before being merged into the main branch, continuous integration checks if the same validator public key is present more than once in the whole system. If this is the case, it means that more than one validator client would start to validate for a given validator public key, which could lead to a slashable offence. The merge into the main branch is therefore blocked.
In this case, no public key is common between the two validator clients.
⇒ The check passes.
In this case, the second and the third keys are common between the two validator clients.
⇒ The check fails.
Known holes for this layer:
Validator clients manage a local anti-slashing database. This database records every block and attestation signed by validators. The validator client uses this information to avoid attesting or proposing two different attestations or blocks for the same slot.
Without a local anti-slashing database, the following pattern could lead to a slashable offence:
The validator has now signed two slots at the same height on conflicting forks, which is a slashable offense.
With the local anti-slashing database, after the reboot, the validator client will see by reading into the database that it already voted for the current slot. Unfortunately it won’t receive the reward corresponding to the head vote since it probably voted for the wrong head, but at least the validator won’t be slashed.
Known holes for this layer:
An external signing authority is a tool which provides slashing protection to prevent validators from signing blocks and attestations based on what it knows has already been signed. This tool manages a (global) slashing protection database which records each block and attestation signed by a validator. Ideally, all validator clients would be connected to the same external signing authority.
When using external signing, validator clients do not sign attestations and block proposals themselves, but rather request that the external signing authority to do so. While signing, the authority records in its database that a given validator key signed for a given slot. If, eventually, another validator client asks to sign for the same validator key / slot, then the global external signing authority will refuse to sign it again, avoiding any slashable offence.
Because the global anti-slashing database is now a critical part of the validation system, it’s recommended to have a (strongly consistent) replication of this database on multiple zones / regions.
For now, the primary external signing authority tool used is Consensys Web3Signer.
There is no known hole for this layer, however there is two downsides:
In such a case, an attestation can be delayed, and its inclusion distance can be sub-optimal, incurring some rewards losses.
Doppelgänger detection is a tool to detect if, somewhere on the Ethereum network, a second instance of validation for a given validator key occurs. The implementation can differ between validator clients, but the principle stays the same. The following part describes the Prysm validator client behaviour:
At the start the validator client checks, for a given validator key, if it validated for it less than two epochs ago.
If not, the validator client checks on the beacon chain (via the beacon node) whether or not the given validator key was live during the last two epochs. If the validator client detects liveness for the validator key, then another validator client, somewhere, must currently be validating for the validator key. The validator therefore won’t start.
In the converse scenario, if no liveness is detected for a key, it is likely no other validator client is currently validating for the key.
Upon startup, if the validator client detects it was validating for a given validator key during the last two epochs, then it chooses to skip the doppelgänger check, since it is unable to know if the on-chain liveness comes from itself (before a restart, for example), or from another validator client somewhere on the network.
Other validator client implementations (like Lighthouse) choose, at validator client start, to remain silent on the network for 2-3 epochs before starting to sign slashable messages (resulting in minor penalties for not participating to the network during these 2-3 epochs).
Source: Lighthouse documentation
Known holes for this layer:
Doppelgänger detection should be considered a last-line-of-defence that mightsave a validator from being slashed due to operator errors (i.e. running two instances of the same validator). Users should never rely upon Doppelgänger and should practise the same caution with regards to duplicating validators as if it did not exist.
Source: Lighthouse documentation
Thanks to Emmanuel Nalepa for writing this article, as well as the Ethereum Foundation for their support.
Kiln is the leading enterprise-grade staking platform, enabling institutional customers to stake assets, and to whitelabel staking functionality into their offering. Our platform is API-first and enables fully automated validator, rewards, and commission management.
Want to work with us? We're hiring.
