Proposer Slashing

A validator submits two different block proposals for the same slot. This is a direct attack on consensus and is automatically detectable by the network. The slashing penalty is severe, resulting in the validator's effective balance being slashed and the validator being ejected from the active set.

• Mechanism: The protocol compares the signed block headers for the same slot height.
• Example: A validator with 32 ETH could lose 1-4 ETH and be forcibly exited.

A validator signs a slashing vote (an attestation) that 'surrounds' a previous vote they made, attempting to rewrite history. This violates the Casper FFG finality rules.

• Detection: The protocol checks the source and target epoch numbers of signed attestations.
• Consequence: A surround vote is considered a serious equivocation attack on finality, triggering a slashing penalty proportional to the validator's stake and the total amount slashed in a given period.

Nodes on the network (clients) continuously monitor for slashable offenses. A validator can submit a slashing proof—a bundle of signed messages proving the violation—to a block proposer, who includes it in a block.

• Incentive: The reporter receives a whistleblower reward (a portion of the slashed funds).
• Process: This creates a robust, decentralized policing mechanism where validators are incentivized to keep each other honest.

During the Medalla testnet in 2020, a client bug caused a large number of validators to unintentionally publish slashable attestations. This led to a mass slashing event.

• Impact: Over 2,000 validators were slashed, demonstrating the protocol's automated enforcement.
• Lesson: It highlighted the critical importance of client diversity and stable software, as slashing is a protocol-level response, not a judgment of intent.

The penalty is not fixed. It scales based on the total amount of ETH slashed in a recent period (≈36 days), using a correlation penalty. This design discourages coordinated attacks.

• Formula: Penalty = Base Penalty + (Validator Balance * Proportional Slashing Multiplier).
• Effect: If many validators are slashed simultaneously (suggesting an attack), the multiplier increases, making the penalty more severe for all offenders.

After being slashed, a validator is not immediately removed. It enters a short penalty period and is then forcibly exited from the validator set.

• Timeline: The exit process takes a minimum of 36 days, during which further penalties may apply.
• Withdrawal: The remaining stake (after penalties) becomes withdrawable after the exit is complete, but the validator can no longer participate in consensus.

A proposer slashing event occurs when a validator is proven to have signed and broadcast two different BeaconBlock headers for the same slot. This is a direct attack on the consensus protocol and is detectable by other validators. The conflicting signatures provide cryptographic proof of misbehavior, triggering an automatic slashing penalty.

The penalty for proposer slashing is severe and involves multiple components:

• Initial Penalty: A base slashing penalty (up to 1 ETH or more, depending on network conditions).
• Correlation Penalty: An additional penalty that increases if many validators are slashed simultaneously, discouraging coordinated attacks.
• Ejection: The validator is forcibly exited from the active validator set and cannot propose blocks or attest until a withdrawal period is complete.

Proposer slashing is detected by other validators who see the two conflicting signed block proposals. Any validator can submit a SlashingProof transaction to the network, which contains the two conflicting signed headers. The proof is verified on-chain, and if valid, the slashing penalty is applied. The reporter may receive a small reward from the slashed funds.

It is crucial to distinguish proposer slashing from attester slashing.

• Proposer Slashing: Punishes a single validator for proposing two blocks.
• Attester Slashing: Punishes a set of validators for making contradictory attestations (e.g., voting for two different blocks or surrounds/ double votes). Both are integrity violations but target different validator duties.

While often malicious, slashing can sometimes result from operational faults:

• Malicious Actor: A validator intentionally trying to create a fork or disrupt consensus.
• Faulty Client Software: A bug causing the validator client to sign and broadcast two different blocks.
• Compromised Signing Key: An attacker gaining control of a validator's private keys.
• Configuration Error: Running multiple validator clients with the same keys on different machines.

Validators must implement robust operational security to avoid accidental slashing:

• Use highly reliable, updated client software.
• Ensure signing keys are stored securely (HSMs, remote signers).
• Avoid duplicate validator instances (same keys on multiple machines).
• Monitor validator performance with alerting tools to detect anomalies quickly.

The protocol-enforced penalty for a validator's provable malicious behavior, resulting in the loss of a portion of their staked funds and ejection from the validator set. It is distinct from smaller penalties for being offline. Key slashable offenses include:

• Proposer Slashing: Proposing two conflicting blocks for the same slot.
• Attestation Slashing: Casting contradictory attestations (votes) that could be used to finalize conflicting chains. The primary goal is to disincentivize attacks on network consensus and liveness.

A vote cast by a validator in a Proof of Stake system to confirm the validity of a block. Validators are periodically assigned to committees to attest to specific blocks. An attestation contains:

• A vote for a block at a particular slot.
• The validator's signature.
• A link to the checkpoint block they consider to be the chain's head. Casting two attestations that contradict each other (e.g., voting for two different blocks as the head of the chain for the same epoch) is a slashable offense known as an attestation slash.

A protocol mechanism that gradually reduces the stake of validators who are persistently offline during periods when the chain cannot achieve finality. Unlike slashing, it is not a penalty for malice but a safety measure to ensure liveness.

• Purpose: If too many validators go offline, the chain cannot reach the 2/3 supermajority needed to finalize blocks. The inactivity leak reduces the stake of offline validators until the participating validators control >2/3 of the remaining stake, allowing finality to resume.