中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC022
Two honest blockchain nodes can report different latest blocks because they have received different information. A network partition interrupts communication between parts of the network; it does not automatically prove that either node is dishonest. To understand the disagreement, compare the network, rules, observation time, validated block identities and selection rule. A block height alone is insufficient.
This guide follows two fictional nodes through a short interruption and reconnection. You will calculate their local choices, separate missing information from invalid information, and write a defensible observation report. The exercise concerns how a node’s view changes. Its small weights are invented teaching values, not a real proof-of-work calculation or a secure consensus design.
Choose your reading route
In this guide
- 1. Begin with an observation card
- 2. A partition changes who can hear whom
- 3. State the toy rules before calculating
- 4. Follow the four snapshots
- 5. Why X cannot win with a large number
- 6. A header is not the same as a validated block
- 7. What changes for transaction T?
- 8. Reconnection is not a merge of every transaction
- 9. Diagnose two disagreeing API responses
- 10. Six diagnostic cases, with answers
- 11. A concise reporting checklist
- 12. Frequently asked questions
- Sources and next learning steps
If you are new to the subject, read the observation card and the complete West–East trace in order. If you work with dashboards or data reports, pay particular attention to the sections on headers, transaction T and conflicting API responses. For classroom discussion, complete the six diagnostic cases before looking at their answers.
The mathematical background to replicated logs and agreement is covered in Distributed Consensus, Quorums and Fault Tolerance. Database readers can also use Read Replicas, Replication Lag and Read-After-Write Consistency. Here we focus on a blockchain-specific question: what can two observers actually conclude from different local branches?
Back to contents · Next section
1. Begin with an observation card
“Node West is at block 202” is an incomplete report. It omits which network West follows, which block occupies that position, whether the block is fully validated, and when the measurement was taken. It also says nothing about another node’s knowledge.
For this lesson, record six fields for each observation:
- Network and rule set: the intended network and the validation rules assumed by the exercise.
- Observation time and source: when the reading was made and which node or service supplied it.
- Selected head: the identifier of the last block on the branch currently selected by that node.
- Available evidence: which headers, complete blocks and required ancestors the node has received and checked.
- Selection information: the relevant branch score or other protocol-specific decision inputs.
- Separate status fields: pending transactions and any finality evidence, if the protocol provides it.
This is an analytical worksheet, not a universal API schema. A real client may expose these facts through several interfaces, and a remote service may hide important detail. An absent field should become an explicit uncertainty rather than a value invented by the reader.
The card also prevents an easy language mistake. “Latest” might mean most recently received, highest reported number, current selected head, or latest finalized checkpoint. Write the intended meaning. Two reports can disagree simply because they answer different questions.
Back to contents · Next section
2. A partition changes who can hear whom
Imagine West and East initially exchanging messages and agreeing on a starting block Q. Communication then breaks between their two regions, while communication within each region continues. West receives one stream of descendants and East another. Neither node can select a branch it has not received enough information to evaluate.
This differs from a stopped process. A stopped node performs no new local work; a partitioned node may continue checking messages from reachable peers. It also differs from a slow application cache, which may display yesterday’s answer while the underlying node is current. Similar-looking screens do not establish the same underlying fault.
A partition need not divide a network neatly into two equal halves. The two-region picture is a classroom simplification. Real communication can be delayed, asymmetric or intermittent. A successful request in one direction does not establish that every relevant message has reached every participant.
The Bitcoin developer documentation separates peer-to-peer message exchange from the rules used to validate blocks. That separation is useful here: delivery gives a node information to examine; delivery itself does not make that information acceptable. See the P2P Network guide.
Back to contents · Next section
3. State the toy rules before calculating
Our exercise supplies a common starting reference Q with cumulative score 100. Q is assumed available to both nodes. We are not proving that Q is finalized, nor specifying how a new node would establish trust in it.
Each descendant has a parent, an invented positive weight and a validity result supplied by the worksheet. A valid branch’s cumulative score is the starting score plus its descendant weights. A node selects the greatest-scoring branch among those it has fully validated. There are no ties in the comparison that matters here.
The complete block set is:
- A1 follows Q, has weight 3 and is valid. Its cumulative score is 103.
- A2 follows A1, has weight 2 and is valid. Its cumulative score is 105.
- B1 follows Q, has weight 2 and is valid. Its cumulative score is 102.
- B2 follows B1, has weight 5 and is valid. Its cumulative score is 107.
- X claims to follow Q and advertises weight 99, but fails the exercise’s validity checks. It is ineligible.
These rules deliberately leave out production details such as weight verification, block creation, adversarial bounds, tie resolution, timing guarantees and finality. They are sufficient to reproduce the finite observation trace, not to deploy a blockchain. In particular, a participant cannot create legitimate weight merely by writing a large number in a message.
The valid-branch qualification matters outside the toy model too. The Bitcoin Block Chain guide describes competing valid branches and cumulative work, and explains why equal height does not uniquely identify a block. Our integers illustrate comparison only; they are not Bitcoin’s work formula.
Back to contents · Next section
4. Follow the four snapshots
At t0, both nodes know Q and select Q. Their cards agree on the starting reference and score 100. Nothing in that observation proves that they will always receive future messages at the same instant.
At t1, the partition is active. West receives and validates A1, so its best eligible branch is Q–A1 with score 103. East receives and validates B1, so its best eligible branch is Q–B1 with score 102. West has not compared A1 against B1 because B1 is not in West’s available set. East’s lower score is not evidence that East ignored a known stronger branch.
At t2, West validates A2 and selects Q–A1–A2, score 105. East validates B2 and selects Q–B1–B2, score 107. Both selected heads are two descendants beyond Q. Their heights match while their identifiers and histories differ.
At t3, communication is restored. For this snapshot we explicitly assume both nodes receive all four valid descendants, obtain all necessary data and finish validation. No additional blocks appear during the comparison. Each node now compares score 105 with score 107 and selects B2.
West changes its selected branch; East does not. That asymmetry is expected in this trace. Reconnection does not require both participants to discard their former choice, split the difference, or alternate between heads. The same deterministic comparison over the same eligible set produces the same answer here.
Remove the t3 assumptions and the conclusion becomes conditional. A network link becoming available does not mean all messages have arrived or all checks have completed. The trace demonstrates convergence after specified evidence becomes common; it does not prove a universal recovery time for every blockchain.
Back to contents · Next section
5. Why X cannot win with a large number
Suppose West receives X between t2 and t3. A careless dashboard might display its advertised weight and declare it superior. Our worksheet must reject that conclusion before ranking branches because X is invalid.
There are two distinct checks: whether the claimed input has been established under the rules, and how eligible candidates compare. Treating an unverified advertisement as an established score collapses them. An invalid block does not enter the contest with a penalty; it is excluded under this exercise’s rule.
Nor should the reader add X’s advertised 99 to Q and label the resulting number an accepted cumulative score. That arithmetic may describe the sender’s claim, but the observation card must preserve its unverified or rejected status. Precise labels stop a colourful number from becoming false evidence.
This is a general reporting habit rather than a claim that every protocol uses scores. In a vote-based system, an alleged certificate would also need its own specified checks. The current lesson does not substitute invented weights for signatures, authorized membership or protocol rules.
Back to contents · Next section
6. A header is not the same as a validated block
After reconnection, West might first learn that a block called B2 exists, then obtain its header, then fetch B1 and the full data needed for validation. Those stages should not all be reported as “West has accepted B2.” Knowing an identifier is weaker than possessing and checking the relevant material.
For a concrete example of separate status concepts, the getblockchaininfo reference distinguishes the active chain’s validated block height, validated header count and best block hash. The linked reference documents a particular API description; consult the client version in use before depending on its exact output. We use the fields to illustrate distinctions, not as a complete current operational checklist.
A node that has heard about more headers than it has fully processed blocks may have a data or validation backlog. The gap alone does not identify its cause. Likewise, a progress estimate is an estimate, not an independent proof that a node has every relevant message.
In the classroom card, write “B2 announced; full branch validation pending” until the exercise’s required checks are complete. This description is both more useful and more honest than forcing every intermediate observation into a binary synchronized/unsynchronized label.
Back to contents · Next section
7. What changes for transaction T?
Transaction T appears only in A2. At t2, West’s selected history includes T; East’s does not. At t3, West selects the B branch, so T is no longer included in West’s selected history. This follows from the given block contents, without claiming that T’s bytes have vanished from every storage device.
The distinction matters for an application index. If an exhibition catalogue displayed a fictional update derived from T, its selected-chain view would need to reflect the new branch. Keeping the old derived result while showing the new head mixes evidence from different histories.
Whether T becomes pending again, remains eligible for a later block, or conflicts with the selected branch depends on the relevant state and rules. The trace does not supply those details, so “T will automatically return and succeed” is unsupported. It also does not justify asking a user to resubmit a real transaction.
Keep three records separate in your report: the transaction data observed, its inclusion in a particular block, and its inclusion in the currently selected history. A fourth, finality, would require protocol-specific evidence that our model does not provide. This lesson therefore establishes a changed local selection, not a reversal of an explicitly finalized checkpoint.
Back to contents · Next section
8. Reconnection is not a merge of every transaction
An ordinary collaborative document may offer a merge operation. A blockchain branch change cannot be understood as copying every transaction from both branches into one larger accepted block. The ordering and state-transition rules still constrain what may coexist.
For an original teaching example, suppose one branch records the transfer of a single fictional catalogue-control token to Team A, while the other records an incompatible transfer of the same token to Team B. Under a rule permitting only one current controller, combining both results without an ordering decision produces an inconsistent application state. Network recovery alone does not resolve that application rule.
Our trace chooses a branch and then interprets its history. A real protocol defines its own mechanics for selecting, validating and updating state. The important reading habit is to ask which history the application result belongs to, rather than assuming communication repairs have combined all local outcomes.
This is also why “all data was replicated” is too broad a success statement. You may mean all required blocks were downloaded, all eligible branches were examined, or all application projections were updated. Record the specific completed stage and leave other stages open until their evidence exists.
Back to contents · Next section
9. Diagnose two disagreeing API responses
Suppose two dashboards both display height 202 but one reports A2 and the other B2. Start by checking whether they refer to the same network and comparable observation times. Then compare identifiers, validation status and which underlying node supplied each response. A shared height cannot settle the disagreement.
Next ask whether the services expose a live node view or cached application data. A front end may be delayed even after its node has changed heads. Multiple services may also depend on the same upstream provider, so several matching displays do not necessarily constitute independent observations.
Possible explanations include ordinary propagation delay, a genuine communication partition, an incomplete download, a stale cache, different rule sets, different networks or a software fault. The reports alone do not select one explanation. Avoid turning a list of possibilities into a diagnosis without evidence.
A useful incident sentence is: “At the recorded times, West reported validated head A2 and East reported validated head B2 on the stated exercise network; their known block sets differed.” A poor sentence is: “The blockchain was hacked.” The first preserves observable facts and scope; the second invents a cause.
This guide calls for read-only comparison and reasoning. It is not an instruction to alter peer settings, reset node data or disable validation in order to make two screens agree.
Back to contents · Next section
10. Six diagnostic cases, with answers
Try each case before reading its answer. Use only the worksheet assumptions, not facts you wish the exercise had supplied.
- At t2, which node has the greater selected score? East, at 107 rather than 105. West is still following its best locally available validated branch.
- Both heads are two blocks beyond Q. Are they the same block? No. A2 and B2 have different identifiers and ancestry despite equal relative height.
- West receives only B2’s announcement. Must it immediately select B2? No. The rule requires a fully validated eligible branch, including the necessary parent and block data.
- X advertises weight 99. Does it outrank B2? No. X is invalid and excluded before score comparison.
- After the complete t3 exchange, where is T included? In A2’s history, but not in the selected B branch. Pending status and future inclusion are unspecified.
- Both nodes select B2 at t3. Has the exercise proved finality? No. It proves the stated finite comparison result; no finality mechanism is modeled.
For an extension, change the supplied B2 weight from 5 to 3. The two valid tips now both have cumulative score 105. Our original specification lacks a tie rule, so it cannot uniquely determine the selected head in that modified case. Identifying a missing rule is the correct answer; inventing one is not.
Back to contents · Next section
11. A concise reporting checklist
Before writing that two blockchain nodes agree, ask whether you have matched the intended network, rules, observation times and selected head identifiers. Specify whether you compared headers, fully validated blocks or an application’s cached projection. State the relevant evidence source and any unavailable fields.
Before writing that they disagree, identify exactly which field differs. A difference in pending transactions is not automatically a difference in selected history. A difference in selected head is not automatically conflicting finality. A difference in API timestamps may simply mean the observations are not simultaneous.
Finally, separate the observed change from its explanation. The West–East worksheet shows a known partition because the exercise supplies it. An actual pair of screenshots does not supply that cause. Good technical reporting preserves the boundary between what was measured, what was assumed and what remains unknown.
Back to contents · Next section
12. Frequently asked questions
Does every partition make both sides produce blocks?
No. That is a supplied feature of this finite teaching example. A particular protocol and participant distribution may permit progress in one region, neither region, or different limited activities. Read its assumptions rather than transferring this trace universally.
Does a node with the higher block number always have the preferred chain?
No. Height is a position count, and the relevant selection rule is protocol-specific. Our example deliberately uses equal-height branches with different cumulative scores.
Can two honest nodes disagree temporarily?
Yes, when their available information differs under conditions such as those supplied here. Whether a particular disagreement is expected or violates a protocol guarantee requires that protocol’s rules and evidence.
Is selecting the same head enough for an application report?
It is useful evidence, but the application may also need consistent derived state, current indexing and a specified confidence or finality condition. State which question has actually been answered.
Back to contents · Next section
Sources and next learning steps
Primary technical references checked on 12 October 2026, Singapore time: Bitcoin Block Chain guide, Bitcoin P2P Network guide, and getblockchaininfo reference. The observation card, invented block weights, catalogue example and exercises are original teaching material. They do not claim a production implementation or an operational recovery guarantee.
After this guide, study safety and liveness with a sharper question: is a system failing to make a particular kind of progress, or producing results that its rules say must never coexist? The answer requires more than noticing that two screens look different.