Attestation Slashing

A validator is slashed for submitting two different attestations (votes) for the same target epoch. This is the primary, most direct form of attestation slashing. The protocol treats this as a provable attempt to undermine consensus, as it signals support for conflicting chain histories.

• Example: Attesting that both block A and block B are the canonical head of the chain for epoch 100,000.

A more complex slashable offense occurs when a validator's attestations surround a previous one. This happens when a validator votes for a newer source checkpoint and an older target checkpoint, effectively attempting to rewrite history they had previously agreed to finalize.

• Mechanism: Attestation (source: 10, target: 20) is later surrounded by attestation (source: 5, target: 25). This violates the fork choice rule by creating ambiguity about finalized checkpoints.

Attestation slashing is enforced automatically by the consensus client software. Any other validator can submit a slashing proof containing the contradictory attestations to the network. Penalties are severe and progressive:

• Initial Slash: An immediate penalty of up to 1 ETH (or the validator's effective balance).
• Ejection: The validator is forcibly exited from the active set.
• Correlation Penalty: If many validators are slashed simultaneously (e.g., in a coordinated attack), an additional penalty proportional to the total ETH slashed in that period is applied.

It is crucial to distinguish attestation slashing from block proposer slashing. While both are slashing conditions, they penalize different validator roles:

• Attestation Slashing: Punishes faulty voting on chain history by an attesting validator.
• Proposer Slashing: Punishes a block proposer for signing two different beacon blocks for the same slot.

Both mechanisms work in tandem to secure the LMD-GHOST and Casper FFG components of Ethereum's consensus.

Modern validator clients (e.g., Prysm, Lighthouse, Teku) are designed with multiple safeguards to prevent accidental slashing, which is almost always caused by operator error like running the same keys on two machines.

• Slashing Protection Database: A local record of all signed messages prevents the client from signing contradictory attestations.
• Doppelgänger Protection: Detects if another instance of the validator is already active on the network.
• Best Practice: Use a single, reliable client per validator key and maintain secure backups of the slashing protection DB.

A surround vote occurs when a validator's attestation has an older source checkpoint and a newer target checkpoint that entirely surrounds another validator's attestation. This is a slashable offense because it attempts to rewrite history and could enable double-finality attacks.

• Mechanism: Attestation A (source=10, target=20) surrounds Attestation B (source=11, target=19).
• Penalty: The surrounding validator is slashed and forcibly exited from the validator set.

A double vote (or equivocation) is the most straightforward slashable offense, where a validator signs two different attestations for the same target epoch. This creates a safety fault by voting for conflicting versions of the chain.

• Detection: The protocol compares all attestations for a given epoch and validator index.
• Consequence: This is cryptographically provable malice, resulting in immediate slashing of the validator's stake.

This violation involves a validator signing an attestation with a target checkpoint that is not a descendant of its declared source checkpoint. It violates the fork choice rule (LMD-GHOST) by attempting to justify a checkpoint on an incompatible chain branch.

• Example: Attestation with source=100 (on chain A) and target=105 (on chain B, not descended from A).
• Impact: Undermines consensus stability and is treated as a slashable fault.

While not directly slashable by the protocol, excessive inclusion delay is a severe negligence penalty. Validators must publish attestations within a specific slot window (32 slots on Ethereum). Failure to do so results in missed rewards, but correlated failure by many validators can indicate a censorship attack or network partitioning, which may be investigated for slashing via social consensus.

Attestation slashing is triggered when a validator is provably caught signing two conflicting attestations for the same target epoch or block height, known as a surround vote or double vote. This is cryptographic proof of dishonest behavior. The penalty typically involves:

• Slashing a significant portion (e.g., 1 ETH or 1-5% in early Ethereum) of the validator's staked balance.
• Ejection of the validator from the active set.
• A correlation penalty that can increase based on how many other validators are slashed simultaneously.

The two primary slashing conditions are defined by attestation data structures:

• Double Vote: Signing two different attestations with the same target.epoch. This is a direct equivocation.
• Surround Vote: Signing an attestation where one's source and target epochs surround those of a previous attestation. For example, attesting with a new source that is older and a new target that is newer than a previous vote. Both attacks undermine the consensus safety and finality of the chain by attempting to create conflicting histories.

While often accidental due to faulty validator client setups or misconfigured cloud deployments, slashing can be a deliberate attack vector:

• Availability Attack: An attacker with multiple validator keys could be slashed to trigger a correlation penalty, disproportionately harming honest validators in the same withdrawal queue.
• Denial-of-Service: Targeting a specific validator or pool by compromising its keys to get it slashed and ejected.
• Protocol Griefing: In rare cases, a suicide attack where an attacker sacrifices their own stake to create network turbulence or exploit other system vulnerabilities during the slashing event.

Validator operators mitigate slashing risks through operational best practices:

• Single Validator Client: Running only one validator client per set of keys to prevent double-signing.
• Secure Signer Setup: Using remote signers (e.g., Web3Signer) or hardware security modules (HSMs) to isolate signing keys from the beacon node.
• Monitoring & Alerts: Deploying tools that monitor attestation performance and can alert to missed duties or potential double-signing scenarios.
• Infrastructure Redundancy: Ensuring high availability without allowing the same validator to run concurrently in two locations.

Slashing has significant economic and protocol consequences:

• Direct Penalty: The slashed validator loses a minimum of 1 ETH (Ethereum) plus up to their entire effective balance if they are slashed during a mass slashing event.
• Correlation Penalty: The penalty scales with the total proportion of stake slashed in a ~36-day window, designed to disincentivize coordinated attacks.
• Ejection & Withdrawal Delay: Slashed validators are forcibly exited and must wait through a penalty period before withdrawing remaining funds, during which they continue to incur inactivity leaks if the network is not finalizing.

Attestation slashing is one part of a broader cryptoeconomic security model:

• Proposer Slashing: Penalty for proposing two different blocks for the same slot.
• Inactivity Leak: A separate penalty that slowly drains stake from validators that are offline during periods when the chain cannot finalize.
• Proof-of-Stake (PoS): The consensus mechanism where slashing is a key deterrent.
• Casper FFG: The 'friendly finality gadget' which defines the attestation and finality rules that slashing enforces.
• Validator Lifecycle: The process from deposit, activation, active duty, exit, and withdrawal, where slashing is a punitive exit.

Blockchains built with the Cosmos SDK, such as Cosmos Hub (ATOM), Osmosis (OSMO), and others, implement a double-sign slashing penalty. This is triggered when a validator's private key is used to sign two different blocks at the same height. Consequences are severe:

• A significant portion (e.g., 5%) of the validator's and its delegators' bonded tokens are slashed.
• The validator is jailed, immediately removed from the active set.
• A lengthy unbonding period is enforced before the remaining funds can be withdrawn.

In the Polkadot and Kusama relay chain and parachain ecosystem, equivocation slashing penalizes validators and collators for producing multiple conflicting blocks or backing invalid parachain blocks (e.g., through Approval Voting). The slashing model is unique:

• Penalties are non-linear and increase with the number of validators slashed in a single incident, discouraging coordinated attacks.
• It employs accountability by slashing not just the offending validator, but also those who voted for the invalid candidate block.

Solana's Proof-of-History consensus includes slashing conditions for validators (called leaders) that act maliciously. While historically less emphasized than in other networks, the protocol defines slashable behavior:

• Double Signing: Producing two different blocks for the same slot.
• Vote Fraud: Voting on a fork that is not a descendant of a previously voted-on block. Penalties involve the loss of a portion of the validator's stake and potential ejection from the network to maintain ledger integrity.

On Avalanche's Platform Chain (P-Chain), which manages staking and validator sets, slashing occurs for double-signing. Validators who sign conflicting transactions are penalized. Key mechanics include:

• A portion of the staked AVAX is slashed.
• The validator is removed from the current and future validator sets for a mandatory lock-up period. This mechanism secures the core staking and subnet creation logic of the Avalanche ecosystem.

While the core goal of deterring Byzantine behavior is consistent, implementations vary significantly across ecosystems:

• Trigger Conditions: Ranges from strict double-signing (Cosmos) to complex surround vote logic (Ethereum).
• Penalty Severity: Can be a fixed percentage (Cosmos) or a variable, escalating function (Polkadot).
• Ancillary Punishments: Often includes jailing (temporary removal) or forced exit (permanent ejection) in addition to stake loss.
• Recovery: Some networks allow for unbonding after a delay, while others require manual intervention.