Nodes, mining & validator operations

slashing protection

Slashing protection is the local safety mechanism that stops a validator from accidentally signing a message that would get its stake slashed. In proof-of-stake, certain actions are provably punishable: proposing two different blocks for the same slot, or casting two conflicting attestations (a double vote, or a vote that 'surrounds' an earlier one). These rules exist to make equivocation expensive — but an honest operator can trigger them by accident, for example after a crash, a misconfiguration, or running the same keys on two machines. Slashing protection is the guardrail that makes those accidents impossible.

It works as a strict local record: the validator client keeps a slashing-protection database listing every block slot it has ever signed and the source/target epochs of every attestation it has cast. Before signing anything new, the client checks this database and refuses to produce a message that would violate a slashing rule — it will not sign a second block for a slot it already proposed, and it will not sign an attestation that double-votes or surrounds a prior one. The protection is conservative by design: when in doubt, it declines to sign, accepting a small missed-duty penalty rather than risk a far larger slashing.

The protection is only as good as the integrity of that database, which makes key portability dangerous. The notorious failure is importing your validator keys onto a second machine for 'redundancy': each machine keeps its own slashing-protection database, neither knows what the other signed, and the moment both sign for the same slot you are slashed. This is why the cardinal rule of staking is that a validator key must be active in exactly one place at a time. To move keys between machines safely, operators export and import the standardized slashing-protection interchange file (EIP-3076) so the new instance inherits the full signing history.

It is important to understand what slashing protection does and does not do. It is purely a local, defensive tool that protects an honest validator from self-inflicted slashing; it does nothing to detect or punish others, and it cannot save a validator that is genuinely trying to attack the network. For higher assurance, operators pair it with remote signers and, increasingly, distributed validator technology, which splits one key across several nodes so the validator stays available without any single machine ever holding a complete, slashable key.

The cardinal rule it enforces: one validator key, active in exactly one place at a time. To migrate, export the EIP-3076 slashing-protection history with the keys — never just copy the keys and hope.