中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC026
A proof-of-stake validator can miss a duty without having signed conflicting messages. It can also sign two messages that meet a protocol’s slashing conditions even if a human operator says the mistake was accidental. Those situations need different evidence and have different consequences.
This guide uses Ethereum as a named technical example to explain proposals, attestations and the distinction between ordinary participation failures and slashable behavior. Its core exercise compares fictional message records. It does not ask you to stake funds, operate a validator, change signing software or submit a slashing report.
Choose your reading route
In this guide
- 1. Stake is part of a participation rule
- 2. Proposals and attestations do different jobs
- 3. Missing participation is not a signed contradiction
- 4. What the message worksheet includes and omits
- 5. Case A: different data with the same target epoch
- 6. Case B: one vote surrounds another
- 7. Three look-alikes that need different conclusions
- 8. Proposer evidence has its own comparison
- 9. Intention and protocol evidence are different questions
- 10. Why signing history matters alongside keys
- 11. Penalties, exit and recovery are separate states
- 12. Six questions with worked answers
- 13. Frequently asked questions
- Sources and next learning steps
Begin with the role map if you are new to proof of stake. Then follow the message worksheet, especially the difference between two distinct messages for the same target epoch and a pair of votes where one surrounds the other. The later sections explain why a key backup alone is not a complete account of a validator’s signing history.
The goal is to read evidence precisely. We do not estimate returns, prescribe deposits, quote penalty amounts or generalize Ethereum’s rules to every proof-of-stake network. Rules and implementation details evolve, so an actual assessment must identify the applicable network and fork.
Back to contents · Next section
1. Stake is part of a participation rule
Proof of stake is a family of designs in which protocol-recognized stake is involved in assigning participation or influence. It is not simply a poll where every visible node has one equal vote. The active participant set, effective weight and eligible actions are defined by the particular protocol.
Ethereum’s proof-of-stake documentation provides the setting for this lesson. A validator identity is associated with protocol duties and signing capability. One operator can manage more than one validator, so validator count does not automatically measure independent control.
The protocol also needs more than a weight rule. It must define what blocks are valid, how participants choose a head, how finality is established, which messages are acceptable and how state changes are processed. “Stake-weighted” alone does not answer those questions.
For this guide, keep an evidence card with the network, applicable rules, validator identity, message type, relevant slot or epoch, signed data and verification status. A statement such as “validator V voted twice” is incomplete until those fields tell us what was actually signed.
Back to contents · Next section
2. Proposals and attestations do different jobs
A block proposal presents a candidate block for other participants to check. Being the selected proposer does not give a validator permission to bypass execution or consensus rules. Other nodes still need to validate the candidate.
An attestation is a validator’s signed consensus message. In the Ethereum example, its data includes a view of the head and source and target checkpoint information. Those components relate to fork choice and finality, but an individual attestation is not by itself a certificate that the entire network has finalized a block.
The block proposal guide and attestations guide describe these roles. We use only the role distinction here, not an assumed permanent duty schedule or every implementation detail on those pages.
A proposal, an attestation and a normal application transaction are therefore different objects. A signature valid for one message type and context is not automatically valid authorization for another. The verification context is part of the claim, not decorative metadata.
Back to contents · Next section
3. Missing participation is not a signed contradiction
Suppose a fictional monitoring record says validator V produced no observed attestation for one duty. This is evidence about the monitor’s observation. To determine whether the protocol counted participation, one would need the relevant accepted messages and state, not just the monitor’s missing log line.
If participation was genuinely missed, consequences may include missed rewards or ordinary penalties under the applicable rules. Missing a proposal and missing particular attestation components need not have identical treatment. Do not use one generic “offline fine” for every event.
Slashing concerns specified provable message behavior. It is not simply another word for losing any amount of stake. Ethereum’s rewards and penalties documentation separates ordinary participation consequences from slashing and discusses forced exit and associated loss for slashable behavior.
That distinction does not make downtime harmless. A prolonged participation problem can affect the validator and network in important ways. It means that an absence and a pair of conflicting signed statements answer different evidential questions.
Back to contents · Next section
4. What the message worksheet includes and omits
Our classroom records identify one fictional validator V and pairs of attestation data. Each pair lists a source epoch and target epoch. The small integers are teaching labels, not records taken from a real chain.
For the exercises, assume the messages are associated with the same intended network and signing context, and that stated differences in the data are real. We will first classify the shape of the data. We do not create signatures or prove that these are valid on-chain evidence objects.
An actual slashing assessment additionally checks the relevant signatures, participant identities or intersections, state eligibility and applicable processing rules. The public specification contains those checks beyond the simple data predicate. A diagram of epochs is not a substitute for them.
The distinction is deliberate: the worksheet can show that a pair matches a prohibited data pattern while still withholding the conclusion that a real validator has been successfully slashed. Data shape, admissible evidence and processed consequence are separate stages.
Back to contents · Next section
5. Case A: different data with the same target epoch
Record A says that V signed attestation data with source epoch 2 and target epoch 6. Record B says that the same V signed different attestation data with source epoch 3 and target epoch 6. The target epoch is the same, and the data differs.
The Ethereum consensus specification’s attestation-data predicate includes this double-vote shape. The important comparison is the target epoch and distinct data, not the vague claim that someone “voted twice for the same block.”
Our pair satisfies that shape. It does not need the two source epochs to be equal. Conversely, repeating exactly the same attestation data is not the distinct-data condition in this predicate.
In a report, write “the supplied pair matches the double-vote data condition for one validator, subject to the remaining evidence checks.” That is more precise than treating every repeated network packet as a punishable new vote.
The lesson also explains why time labels must be interpreted correctly. A slot and an epoch are different protocol concepts. Replacing a target-epoch comparison with an arbitrary wall-clock timestamp comparison would test a different condition.
Back to contents · Next section
6. Case B: one vote surrounds another
Now compare source 2, target 6 with source 3, target 5 for the same validator V. The first source is earlier than the second source, while the second target is earlier than the first target. Written as inequalities, 2 is less than 3 and 5 is less than 6.
The first source-to-target interval strictly surrounds the second. This matches the surround-vote shape in the same specification predicate. Both inequalities are strict: merely sharing an endpoint does not satisfy this particular surrounding test.
The phrase “surround” describes the relationship between source and target epochs. It does not mean that the voter was physically surrounded, that a message arrived late, or that the latest head changed. Those are different facts.
A reader should check both possible orderings of an unordered pair when looking for one interval surrounding the other. Reversing the names of the two records does not remove the underlying relationship. An actual evidence object still has to satisfy its protocol’s processing requirements.
This example is intentionally small enough to check by hand. It teaches a data relation, not a method for creating real slashable messages or a recommendation to experiment with a live signing key.
Back to contents · Next section
7. Three look-alikes that need different conclusions
First, compare source 2, target 4 with source 4, target 6. The targets differ, and neither interval strictly surrounds the other. These two simplified records do not match either data pattern above. That limited result does not prove every other aspect of the messages is valid.
Second, suppose the same source 2, target 6 attestation data appears twice, with the worksheet explicitly stating that the entire data object is identical. There is no distinct-data double vote in that pair, and no strict surrounding relation. Duplicate delivery should not be mistaken for two incompatible statements.
Third, suppose one message belongs to V and the other to a different validator W. Even if their source and target numbers have a conflicting shape, the pair does not establish that a single validator signed both. Actual aggregate-attestation evidence must identify the relevant participants rather than treating all signatures as one anonymous pool.
These cases are useful because they force a narrow conclusion. “This pair does not establish the specified offense” is different from “the validator can never be slashed” or “the network is safe.” A local test should not become a universal verdict.
Back to contents · Next section
8. Proposer evidence has its own comparison
For a fictional proposer example, consider two different signed block headers attributed to the same validator for the same slot. This is a different message category from our attestation pairs.
The specification’s proposer-slashing processing checks matching slots and proposer identity, different headers, validator eligibility and signatures in the relevant signing domain. We cite it to show that several checks combine; the phrase “two blocks appeared” is insufficient.
Two different validators’ proposals do not automatically establish one validator’s double proposal. Nor does receiving the same signed header twice establish two different headers. The exact objects and signer context matter.
The processing rules are part of a versioned specification. The linked base section should be read with applicable fork changes for a real deployment. This lesson does not claim that every numeric parameter or data structure on a base-specification page is the current full network configuration.
Back to contents · Next section
9. Intention and protocol evidence are different questions
A validator operator may accidentally run conflicting signing paths, restore stale information or misunderstand a duty. The protocol’s message checks do not establish the operator’s mental state. Conversely, a statement that “it was an accident” does not make two conflicting authenticated messages disappear.
For reporting, distinguish the behavior demonstrated by evidence from the cause being investigated. A software fault, operational mistake and deliberate action can require different remedies, even if a particular signed-data condition is the same.
Avoid attributing malicious intent merely because a penalty occurred. Also avoid promising that an accidental event will be exempt from protocol consequences. Neither conclusion follows from the message worksheet.
This is one reason to teach slashing as an evidence rule rather than a moral label. The relevant question is which signed acts can be established under which rules. Human accountability, service obligations and legal interpretations are separate matters outside this technical exercise.
Back to contents · Next section
10. Why signing history matters alongside keys
A key backup preserves signing capability. It does not necessarily preserve knowledge of what that key has already signed. A second signer with the same capability but incomplete history can make a new decision without knowing it conflicts with an earlier message.
EIP-3076, Slashing Protection Interchange Format, addresses transferring signing-history information between clients. The page was marked Last Call when checked; its creation date is 27 October 2020. It should not be casually described as a finalized standard merely because it has an EIP number.
The conceptual lesson is that validator continuity includes relevant prior signing constraints, not only secret-key availability. A history record also needs the correct chain context. Information from one network cannot be assumed interchangeable with another.
This is not a migration checklist. Importing a file, seeing a success message or possessing a backup does not by itself prove a transition is safe. Actual operational work depends on the supported client procedure, complete relevant information and authorized handling of sensitive keys.
For our paper exercise, imagine two assistants maintaining separate copies of V’s message record. One copy contains the earlier 2-to-6 entry and the other does not. Their decisions may differ because their knowledge differs, even though they represent the same signing capability. The example explains the risk without asking anyone to duplicate a real key.
Back to contents · Next section
11. Penalties, exit and recovery are separate states
“Slashed,” “exiting,” “withdrawable” and “offline” are not interchangeable status labels. A protocol can impose consequences and schedule state changes over time; an application interface may expose only part of that process.
Do not infer immediate withdrawal or complete recovery from the observation that a validator has stopped signing. Nor should a general educational article promise a universal exit duration or a fixed loss. Such details depend on the named protocol, applicable rules, state and sometimes broader participation conditions.
The same caution applies to a network recovering finality after participation problems. A mechanism designed to help recovery is not proof that every possible disruption resolves within a specific time. A careful reader separates the mechanism’s purpose from a guarantee under established assumptions.
This article therefore uses no financial estimates or recommended actions. Its practical outcome is a clearer evidence vocabulary: missing duty, candidate slashable message pattern, validated evidence, processed consequence and subsequent lifecycle state.
Back to contents · Next section
12. Six questions with worked answers
- V is not seen attesting by one monitor. Is that already a slashing proof? No. It is a missing observation, and even established missed participation is different from conflicting signed-message evidence.
- V signs different data targeting epoch 6 twice, once from source 2 and once from source 3. Which shape is present? The double-vote data shape, subject to the remaining protocol evidence checks.
- V signs 2-to-6 and 3-to-5. Which shape is present? The first strictly surrounds the second because 2<3 and 5<6.
- The complete same 2-to-6 data object is delivered twice. Does that pair show a distinct-data double vote? No. The problem explicitly says the data is identical.
- V signs one record and W signs another. Can the pair alone prove that V signed both? No. Signer identity and, where relevant, participant intersection must be established.
- A restored signer has the key but no record of earlier signing. Does key possession establish safe continuity? No. Relevant signing history and context are separate requirements; this observation does not authorize a real recovery action.
For an extension, compare 2-to-6 with 2-to-5. The targets differ and the equal sources do not satisfy a strict surrounding inequality. These two simplified records therefore do not match the two taught predicates, although that is not a complete validity assessment.
Back to contents · Next section
13. Frequently asked questions
Do all proof-of-stake systems use these slashing rules?
No. The detailed examples are tied to named Ethereum documentation. Other systems can have different duties, evidence requirements, consequences or no equivalent mechanism.
Is every loss of rewards slashing?
No. Missed rewards, ordinary penalties and slashing are distinct categories. The applicable protocol determines which consequence follows from which event.
Does a valid signature make an attestation correct?
A valid signature is only one part of the evidence. Message context, participant eligibility, data relationships and protocol rules also matter.
Does slashing prove that the operator intended harm?
No. Protocol evidence concerns signed behavior and state conditions. Intention and root cause require separate investigation.
Back to contents · Next section
Sources and next learning steps
Primary references checked on 12 October 2026, Singapore time: Ethereum’s proof-of-stake overview, proposal guide, attestation guide, rewards and penalties guide, the base consensus specification and EIP-3076. The message pairs are original synthetic exercises, not real signatures or accusations.
Next, examine Byzantine vote certificates: how several authenticated votes combine, why participant overlap matters, and why counting a quorum without the surrounding protocol rules is not a complete safety proof.