Ethereum anti-slashing strategies
Slashing on the Ethereum Beacon chain
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”:
- By being a proposer and proposing more than one distinct block at the same height
- By being an attester and making two differing attestations for the same target checkpoint
- By being an attester and attesting to different head blocks, with the same source and target checkpoints
- By being an attester and making an attestation whose source and target votes “surround” those in another attestation from the same validator.
Source: https://eth2book.info/bellatrix/part2/incentives/slashing/
Slashing penalties
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:
- The validator is made inactive and any remaining balance is retained on the account without any withdrawal possibility.
- Please note that before the Shanghai update (which should occur in March 2023), staked balances won't be withdrawable at all, even after leaving the exit queue.
- At each epoch, the validator loses about the amount it would have normally earned if it had been active.
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)
Being slashed while behaving perfectly honestly
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.
Anti-slashing strategy layers
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:
- Layer 1: GitOps validator public keys duplication check
- Layer 2: Validator client local anti-slashing database
- Layer 3: External signing authority (global anti-slashing database)
- Layer 4: Doppelgänger detection
Layer 1: GitOps validator public keys duplicate check
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.
- OK - No validator client has common validator public keys
In this case, no public key is common between the two validator clients.
⇒ The check passes.
- NOT OK - One key is the same for two validator clients
In this case, the second and the third keys are common between the two validator clients.
⇒ The check fails.
Known holes for this layer:
- The key duplicate checker may contain some bugs.
- In some circumstances, it’s possible for a developer to push directly in the main branch and bypass continuous integration checks.
Layer 2: Validator client local anti-slashing database
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:
- For a given validator key, the validator client signals the beacon node for its view of the blockchain.
- The validator signs a attestation for slot 3.
- Because of bad network conditions, the beacon node re-orgs to another head that is on a conflicting fork of the chain.
- For whatever reason, the validator client reboots.
- After the reboot, the validator client signals the beacon node for its view of the blockchain.
- The validator client now sends an attestation for the same slot on the conflicting fork.
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:
- The validator client local anti-slashing database, as stated in its name, is dedicated to a given instance of a validator client. If the same validator key is managed by two different instances of a validator client (possibly connected to two different beacon nodes), then the local anti-slashing database won’t be able to avoid the slashable offence.
- If a given validator key is moved between two different validator clients (possibly connected to two different beacon nodes), then the target validator client may vote for the same slot as the source validator, but for a different block. This is a slashable offence.
Layer 3: External signing authority (global anti-slashing database)
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:
- Because using external signing authority adds two additional software pieces (the signer itself and the global database), in some circumstances this system can add additional delay to the validation process, especially if validators / external signer / global database are not colocated (example: in different cloud provider regions).
- External signing authoring adds centralisation. If the signing client and/or database gets down for any reason, including potential bug in the signer, then the whole validation process is down too.
In such a case, an attestation can be delayed, and its inclusion distance can be sub-optimal, incurring some rewards losses.
Layer 4: Doppelgänger detection
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:
- An attestation or block could take multiple slots to be fully broadcasted to the whole network. A validator key could appear inactive for a beacon node, while the corresponding attestation / block coming from this validator key could actually just be “in transit”. Doppelgänger detection may cause a false-negative (validator key which appears not live while it is actually live).
Doppelgänger detection should be considered a last-line-of-defence that might save 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.
About Kiln
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.
.png)
