中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC029
A node does not choose a trustworthy history by selecting the largest number a peer advertises. It must establish which candidates are valid, which are compatible with its required starting information, and how the protocol ranks the remaining possibilities. A recovering node also needs to know why its starting point should be trusted.
This guide separates candidate validation, fork choice, checkpoints and bootstrap assumptions. You will inspect a fictional recovery packet, filter four branches and distinguish verifying a downloaded file from establishing that the file represents the intended network state. The exercises are read-only reasoning tasks, not instructions to reset a live node or replace a trusted checkpoint.
Choose your reading route
In this guide
- 1. Separate validation, eligibility and selection
- 2. The supplied checkpoint in our worksheet
- 3. What the arithmetic did not prove
- 4. A checkpoint is more than a height number
- 5. Finalized checkpoints and supplied bootstrap anchors play different roles
- 6. Why old signing history can complicate a new node’s view
- 7. A snapshot hash answers only the question it binds
- 8. Ordinary synchronization and exceptional recovery are different
- 9. Read a recovery packet in layers
- 10. Six candidate and provenance decisions
- 11. Keep fork-choice explanations versioned
- 12. Common misconceptions
- 13. Frequently asked questions
- Sources and next learning steps
Start with the three decision layers and the four-branch worksheet. Then read the distinction between a finalized checkpoint, an externally supplied starting reference and a data snapshot. The later sections focus on a node that has been offline and the information missing from an unexplained recovery file.
For the mathematics of distributed snapshots and consistent cuts, see Distributed Snapshots, Channel State and Recovery. This lesson concerns blockchain history selection and starting-state trust, rather than repeating that general snapshot algorithm.
Back to contents · Next section
1. Separate validation, eligibility and selection
First, validation asks whether a candidate block and its state transitions obey the relevant rules. The answer depends on the required data, parent context and applicable protocol version. An impressive score cannot compensate for a failed validity check.
Second, eligibility asks whether a candidate belongs to the set the node is permitted to consider under its current protocol state and starting constraints. A branch might contain otherwise valid blocks but conflict with a required checkpoint. Such a branch can be excluded from this node’s selection set.
Third, fork choice ranks eligible possibilities according to the protocol’s rules and the node’s available information. The rule may depend on work, authenticated votes or other specified state. It is not a universal instruction to select the most blocks, most peers or latest timestamp.
Real implementations may organize these checks differently, but the conceptual separation is useful. A recovery report should identify whether a candidate failed validation, conflicted with a required anchor, or simply lost the comparison among eligible branches.
Back to contents · Next section
2. The supplied checkpoint in our worksheet
Our fictional node starts with a checkpoint reference C. The exercise assumes that C is the required anchor and that the relevant history must descend from it. We do not yet establish where C came from or why its source is trustworthy.
Four candidate branches are supplied. P descends from C, is fully validated and has synthetic score 7. Q descends from C, is fully validated and has score 9. R otherwise satisfies the supplied local validity checks but does not descend from C, so it is ineligible under the C-anchor rule; it advertises score 100. S descends from C and advertises score 200, but its full validity has not been established.
The classroom selection rule is to retain fully validated descendants of C, then choose the greatest synthetic score among them. There is no tie in the supplied case. These scores are invented for the worksheet and are neither real proof-of-work values nor Ethereum vote weights.
The result is Q. P and Q qualify, and 9 exceeds 7. R is excluded by the anchor constraint. S is not admitted as a fully validated candidate merely because its advertisement is large.
This exercise does not declare S permanently invalid. Its status is unvalidated, which is different from a known failed check. The evidence supplied is insufficient to select it under the classroom rule.
Back to contents · Next section
3. What the arithmetic did not prove
Selecting Q establishes the result conditional on C and the supplied validity facts. It does not prove that C belongs to the intended network’s accepted history. If the starting reference is wrong, correct comparison after that point does not magically correct its origin.
A checksum matching a file, several peers repeating a value, or a large number printed next to a branch cannot by itself replace the missing provenance argument. Each can provide particular evidence, but the conclusion depends on what the source is trusted to establish.
For example, a copied checkpoint and a copied screenshot might both originate from the same unverified website. Their agreement would not create two independent confirmations. The observer needs to understand the dependence between sources, not merely count matching displays.
The worksheet therefore produces two separate report lines: “Q is selected under the supplied C constraint,” and “C’s provenance is assumed for this calculation.” Keeping the second line visible is an essential part of the result.
Back to contents · Next section
4. A checkpoint is more than a height number
A height identifies a position, not necessarily one unique block across competing branches. A checkpoint reference needs the relevant identifier and context specified by the protocol. Depending on the system, that may involve a block root, epoch, state reference or another defined object.
For the Ethereum-specific example, the base weak-subjectivity guide describes a checkpoint using a block root and epoch in its synchronization procedure. That page identifies itself as a Phase 0 guide and work in progress. It is not a promise that every present-day client’s complete setup procedure is identical to the page.
The useful conceptual point is that the reference must name the intended object, not merely say “start around this date” or “use the block at height 500.” An incorrect network identifier or mismatched root can make an apparently plausible starting point unsuitable.
A checkpoint constraint also does not erase the need to check later data. It narrows the histories considered under a trust assumption; it does not authorize arbitrary descendants or make every downloaded block valid.
Back to contents · Next section
5. Finalized checkpoints and supplied bootstrap anchors play different roles
A finalized checkpoint is a protocol status established according to the relevant consensus rules and assumptions. An externally supplied bootstrap reference is information a node uses to establish a starting context. The two may refer to related objects, but the way the recovering node obtains and trusts them matters.
Ethereum’s weak-subjectivity overview explains the role of a sufficiently recent trusted checkpoint for joining or long-offline nodes. We use this named-system idea without transferring it to every proof-of-stake design or claiming that all trust disappears afterward.
A node already following a chain has accumulated state and observations. A new node presented with an entire history does not automatically possess the same background knowledge. The fact that the history contains old signatures does not answer every question about which history the intended network recognizes now.
This is why “the file contains finalized labels” is not a complete bootstrap argument. The recipient of the file needs the protocol-specific basis for trusting the starting context and for checking subsequent information.
Back to contents · Next section
6. Why old signing history can complicate a new node’s view
A proof-of-stake history reflects changing participants and weights. Keys associated with earlier participation can still produce signatures later if their holders retain signing capability. A signature’s mathematical validity is not itself a statement that its signer currently holds the same protocol role or economic exposure.
This helps explain the long-range-history problem discussed in Ethereum’s weak-subjectivity material. A node that has been offline for a long period may need additional trusted recent context to distinguish the intended history from an alternative presented with historical-looking evidence.
The lesson is not that every offline node is attacked or that any arbitrary old signature defeats the protocol. It is that the bootstrap assumptions differ from the assumptions of a continuously participating observer. The exact protection and relevant period come from the named protocol and state.
We do not quote a universal number of days. A fixed duration copied from an old guide can conceal dependencies on validator changes, balances or updated rules. A careful reader asks which version and state determine the requirement instead of treating recency as a timeless constant.
Back to contents · Next section
7. A snapshot hash answers only the question it binds
Suppose our fictional archive receives a compressed state snapshot and a digest. Recomputing the digest can establish that the received bytes match the supplied digest, under the hash assumptions. It does not establish who selected those bytes or why they represent the intended canonical state.
If the same untrusted sender supplies both file and digest, the match may detect transfer corruption while doing nothing to establish the sender’s authority. Integrity relative to a claimed reference and authenticity of the reference are different questions.
A protocol-specific state root may bind a defined state representation rather than the raw bytes of a compressed download. Comparing the wrong kind of digest can therefore fail even as an integrity test. The format, serialization and commitment scheme must match the claim being checked.
Our worksheet does not ask you to download or import an actual snapshot. It asks which evidence would connect a supplied file to the trusted starting reference, and which checks the relevant client performs before relying on it. “The download completed” is not an answer to either question.
Back to contents · Next section
8. Ordinary synchronization and exceptional recovery are different
An ordinary synchronization process obtains missing data and validates it within established rules and starting assumptions. A node that was temporarily behind may be able to catch up without changing its trust reference, depending on the protocol and the state it retained.
An exceptional consensus failure can raise a different question: which history should participants recognize when normal assumptions no longer supply an automatic answer? Human coordination, governance or a software change may become relevant. That process is not simply another invocation of the ordinary fork-choice function.
Do not describe an exceptional social decision as if a local numeric score had proved it inevitable. Conversely, do not assume that every routine fork choice requires a human vote. The two processes operate at different levels.
For this guide, the practical boundary is clear: identifying missing evidence does not authorize replacing a checkpoint, deleting local history or changing security-sensitive settings. Real recovery requires the applicable procedures, responsible operators and explicit authority for the action.
Back to contents · Next section
9. Read a recovery packet in layers
A useful fictional recovery packet identifies the intended network, relevant client and protocol version, starting reference, source and observation date, state representation, integrity checks, and conditions under which the reference remains suitable.
Then it describes what happens after the starting point: which data must be obtained, which checks establish validity, how candidates are filtered and which fork-choice inputs select among the survivors. These are separate claims that a reader can examine individually.
Finally, it states failure behavior. What does the procedure do if the downloaded state does not match the reference, if a branch conflicts with the checkpoint, or if the reference’s suitability cannot be established? A document that says only “continue with the largest branch” has not answered those questions.
This is a review structure, not an implementation specification. It helps an archive team recognize when a recovery proposal has omitted trust assumptions or conflated a data transfer with a verified state transition.
Back to contents · Next section
10. Six candidate and provenance decisions
- P and Q are fully validated descendants of C, with scores 7 and 9. Which wins under the worksheet rule? Q, because it has the larger score within the eligible set.
- R advertises 100 but conflicts with C. Can its score override the required anchor? No. It is excluded before the comparison under this rule.
- S advertises 200 and descends from C, but is not fully validated. Is it automatically the winner? No. Unverified weight and missing validity cannot be treated as established eligibility.
- The file’s digest matches a digest supplied by the same unknown sender. Does that establish the intended canonical state? No. It establishes a relation between supplied bytes and supplied digest, not trustworthy provenance.
- Two sources agree on C, but both copy the same upstream service. Have we established two independent sources? No. Independence requires more than two different display addresses.
- A recovery document provides only a height and says nothing about network, block identifier or source. Is that a complete checkpoint reference? Not under the concepts taught here. The missing context prevents the intended claim from being checked.
For an extension, change P’s score to 10 while keeping all supplied eligibility facts unchanged. P then wins. Now instead remove the trusted-C assumption: the arithmetic can still describe a conditional choice, but it cannot establish the legitimacy of the starting reference. These are different kinds of change to the problem.
Back to contents · Next section
11. Keep fork-choice explanations versioned
A named protocol’s fork-choice rules can depend on more than a simple total. Ethereum’s base fork-choice specification is a concrete example of a structured rule set with stored state and checkpoint-related constraints. Applicable fork modifications must also be considered for a real deployment.
Our score-7-versus-9 worksheet intentionally does not implement that algorithm. It isolates filtering from ranking so a reader can see why the biggest advertisement is not enough. Substituting our classroom score for real vote processing would remove important protocol conditions.
When reading a tutorial, distinguish a conceptual model from a client command, a formal specification and a claim about the currently deployed network. Each needs different evidence. A precise version label is a useful boundary, not needless detail.
Back to contents · Next section
12. Common misconceptions
“Valid signatures mean the starting history is unquestionably current” overlooks membership changes and bootstrap context. “A matching hash proves the sender is trustworthy” confuses content integrity with source authority. “The branch with the biggest number must win” skips eligibility.
“Checkpoint synchronization means no further validation” overstates what the anchor supplies. “All recovery is social” ignores ordinary rule-based synchronization. “All recovery is automatic” ignores cases where the model’s assumptions no longer resolve the problem.
A good explanation repairs each statement by naming the missing layer. The goal is not to make readers distrust every source indiscriminately, but to make the actual trust dependencies visible and checkable.
Back to contents · Next section
13. Frequently asked questions
Is a checkpoint always a finalized block?
The term is used differently across systems and procedures. Identify the exact object and its role: protocol status, bootstrap reference, stored snapshot marker or something else.
Does a supplied checkpoint make its descendants valid?
No. It constrains the starting context or eligible histories. Later blocks and state transitions still need the checks required by the protocol.
Is the largest peer-reported score sufficient to recover a node?
No. The score’s meaning, validity, ancestry constraints and starting assumptions must be established. A peer’s advertisement is only a claim until checked.
Can a general lesson give a safe universal recovery command?
No. Client versions, networks, retained state and authorization differ. This article teaches how to review the evidence rather than directing changes to a live system.
Back to contents · Next section
Sources and next learning steps
Primary references checked on 12 October 2026, Singapore time: Ethereum’s weak-subjectivity overview, the Phase 0 weak-subjectivity guide and base fork-choice specification. The Phase 0 guide identifies itself as work in progress; none of these links is presented as a universal recovery procedure or a fixed current timing guarantee.
The four candidates and recovery-packet questions are original synthetic teaching material. Next, broaden the analysis from a single node’s starting assumptions to network control: operators, voting weight, software clients, hosting, RPC services and governance can each create different concentrations and dependencies.