中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC023
A blockchain can keep producing blocks while its finality stops advancing. It can finalize new history while one person’s transaction remains absent. It can also show two different recent heads without having finalized contradictory histories. These observations describe different problems, so a single “network healthy” light is not enough to explain them.
This guide teaches you to classify evidence before naming a failure. You will build a three-part progress report, examine a fictional archive network, and distinguish an observed delay from a demonstrated violation of a stated rule. The cases are diagnostic teaching exercises, not reports about a real network or instructions for operating a financial service.
Choose your reading route
In this guide
- 1. Ask three different progress questions
- 2. Safety names a prohibited outcome
- 3. Liveness must say what eventually happens
- 4. The archive network’s incident card
- 5. Read the trace without adding promises
- 6. Why growing blocks and stalled finality can coexist
- 7. A missing transaction needs its own investigation
- 8. When conflicting checkpoints become safety evidence
- 9. Why waiting and forcing agreement are not equivalent remedies
- 10. Six case cards and answer explanations
- 11. Write an incident note someone else can check
- 12. Frequently asked questions
- Sources and next learning steps
Start with the three questions and the archive incident if the terms safety and liveness are new. Readers who prepare technical reports can move next to the conflicting-checkpoint evidence test and the reporting template. Teachers can use the six case cards as a discussion exercise with answers.
For the underlying mathematics, read Distributed Consensus, Quorums and Fault Tolerance and Proving Software Correct Before It Runs. This lesson applies the distinction to blockchain observations rather than repeating a general replicated-log or majority-intersection proof.
Back to contents · Next section
1. Ask three different progress questions
The first question is about the selected chain: are new valid blocks being added to the history the observer currently follows? A changing head can answer part of this question, provided you also know the block identifiers and their ancestry. A number that rises on a dashboard is weaker evidence than a verified sequence of valid descendants.
The second question is about finality: has the protocol’s finality status advanced? In systems with an explicit finality mechanism, the latest selected head and latest finalized checkpoint need not be the same block. Track both. In systems using a different confidence model, name that model instead of inventing an equivalent certificate.
The third question is about a particular request: has transaction T been included and processed in the relevant history? Even if both chain growth and finality advance, that does not answer whether T was received, eligible, selected or successfully executed.
Write the three answers separately. “Blocks advanced; finality unchanged; T absent” is a coherent result. So is “Finality advanced; T included; intended application update failed.” A compressed green/red indicator loses the distinctions needed to investigate either case.
Back to contents · Next section
2. Safety names a prohibited outcome
A safety property specifies something the system must never do under its stated model. For our fictional archive network, one such property is: two incompatible checkpoints must not both be accepted as finalized by correct participants following the same rules and trust assumptions.
“Incompatible” matters. A checkpoint and a later descendant can both be finalized without conflict. Two reports with different checkpoint numbers are not automatically contradictory. You need their identities and ancestor relationship, together with the relevant protocol’s meaning of acceptance and finality.
Validity is another possible safety concern. If a system promises that accepted state transitions obey a particular authorization rule, an accepted unauthorized transition would violate that rule. This differs from a correctly authorized transaction carrying a false description of a physical object: the latter may be an input-truth problem outside what the protocol checks.
Leslie Lamport’s 1977 paper Proving the Correctness of Multiprocess Programs distinguishes properties excluding unwanted events from properties requiring progress. We use that conceptual distinction, with explicitly stated blockchain examples. “Safety” here does not mean that every application, key holder, legal claim or real-world input is safe.
Back to contents · Next section
3. Liveness must say what eventually happens
A liveness claim requires some specified progress, subject to assumptions. “The blockchain is live” is incomplete unless we know the event being promised. Is it another valid block, another finalized checkpoint, or eventual inclusion of an eligible transaction delivered under defined conditions?
The assumptions may concern message delivery, participant availability, scheduling, software behavior or adversarial limits. A promise depending on eventual network recovery is different from one promising completion within a fixed time while communication remains disrupted. You cannot test them against the same deadline without qualification.
There is also an important observation limit. A finite period with no new finalized checkpoint establishes that finality did not advance during that period. By itself it does not prove that an unbounded “eventually” promise is false forever. It can still be an operational incident demanding attention.
If an explicit bounded guarantee applies, the analysis changes. Suppose a fictional service promises an answer within five observation rounds whenever conditions C hold. Evidence that C held throughout and no answer arrived by the deadline is evidence against that bounded guarantee. It is not automatically evidence against every broader liveness theorem about the underlying protocol.
Back to contents · Next section
4. The archive network’s incident card
Consider an invented archive network whose selected blocks are labeled H100, H101 and so on. The labels indicate increasing height on one supplied valid branch. Its latest finalized checkpoint is identified separately. We assume the classroom observer receives authentic, fresh status records; we are not designing the mechanism that produces them.
At observation round r0, the selected head is H100 and the finalized checkpoint is F90. Transaction T has been received by the observation node but is not included in the selected history.
At r1, the head is H104 and finality remains at F90. At r2, the head is H108 and finality still remains at F90. T is absent in both observations. The exercise explicitly supplies valid descendant relationships for the heads; it is not relying on height alone.
At r3, the head is H112 and the finalized checkpoint advances to F100, a checkpoint identifying H100 on the same branch. T is still absent. At r4, the head is H116 and finality remains F100. T is now included in H114, but the checkpoint supplied at r4 does not cover H114.
These are observation rounds, not seconds, slots or epochs of a real protocol. The trace gives no promised maximum delay and no diagnosis of the cause. Its job is to make the three progress questions independently answerable.
Back to contents · Next section
5. Read the trace without adding promises
Between r0 and r2, head height increases from 100 to 108, an increase of eight. Finality stays at the same identified checkpoint. The correct summary is that the supplied selected branch grew while observed finality stalled. It is incorrect to say the entire system did nothing.
At r3, finality advances from F90 to F100. This is evidence of renewed finality progress in the trace, not proof that all causes of the earlier interruption have been permanently removed. The record still says nothing about a guaranteed future rate.
T’s absence through r3 does not contradict the observed chain and finality progress. Those facts describe collective history; T is one request. At r4, T becomes included in H114 but is not covered by the supplied finalized checkpoint F100. That is a new inclusion observation, not yet the finality condition for T.
Nor have we been told whether T’s application execution succeeded. A block can contain a transaction whose execution outcome does not deliver the user’s intended change, depending on the system’s transaction semantics. Keep the receipt or execution result separate from the fact of inclusion.
The trace therefore supports a sequence of precise statements. It does not support “everything failed,” “everything is fixed,” “T was censored,” or “T’s requested catalogue change succeeded.” Each of those requires facts the worksheet has not supplied.
Back to contents · Next section
6. Why growing blocks and stalled finality can coexist
A protocol can have related but distinct mechanisms for selecting a head and finalizing checkpoints. Ethereum’s Gasper overview describes the combination of LMD-GHOST fork choice and Casper-FFG finality. Its attestations documentation distinguishes information about the head from source and target checkpoints.
That provides a concrete reason to avoid treating “new block seen” as “new finality established.” It does not mean our archive trace is an Ethereum simulation. We have not supplied its validator set, balances, timing rules, fork-choice inputs or finalization conditions.
A diagnostic report should ask what evidence is missing for the progress condition in question. Are relevant messages unavailable to the observer? Has required participation been established? Is the observer’s finality field stale? Has validation completed? These are questions to investigate, not causes established by a flat line on a chart.
Avoid inserting a remembered universal threshold or timeout into the report. Thresholds have denominators, membership contexts and rules for counting evidence. Timing claims have environmental assumptions. A generic statement such as “enough nodes are online” does not establish that the protocol’s necessary actions occurred.
Back to contents · Next section
7. A missing transaction needs its own investigation
Suppose T is absent even while many other transactions are included. Start with its path through the system. Was it only created locally, accepted by an application server, received by one node, or made available to the relevant block-building process? These are different observations.
Next consider eligibility in the relevant state. A request may depend on an earlier action, conflict with another included request, or fail a protocol rule. “Valid when first prepared” does not establish eligibility after the surrounding state changes. The exact tests depend on the network, so this guide does not prescribe a universal resubmission procedure.
Finally, distinguish eligibility from selection. Finite block capacity, ordering policies, competing requests and deliberate exclusion can all be relevant possibilities. One transaction’s absence is insufficient to prove which explanation applies. An allegation of censorship requires evidence beyond a single unsuccessful attempt.
A per-request inclusion guarantee also needs a precise quantifier. “Some eligible transactions continue to be included” is weaker than “every eligible transaction delivered under conditions C is eventually included.” Observing the former does not prove the latter. This is the key difference between global progress and an individual user’s progress.
For transaction stages and execution context, consult the Ethereum transactions documentation. It is a named-system reference; use the target system’s own rules when applying the questions elsewhere.
Back to contents · Next section
8. When conflicting checkpoints become safety evidence
Now consider a different case, separate from the archive trace. Two reports label checkpoints P and R as finalized. Both refer to the same network and relevant rule context. P and R lie on incompatible branches: neither is an ancestor of the other.
Before calling this a demonstrated protocol safety failure, establish what the reports actually contain. A screenshot, an unverified service label, a stale cache or an invalid certificate does not automatically demonstrate that correct participants accepted incompatible finalized histories under the model.
A careful evidence packet identifies the network and rule version, checkpoint hashes and ancestry, the relevant acceptance evidence, its validation result, the participants or observations involved, and the trust assumptions used. If those checks establish the prohibited outcome for the stated property, the incident is more serious than an ordinary finality delay.
The scope of the claim still matters. An honest client accepting malformed evidence could reveal an implementation failure rather than a flaw in a mathematical protocol theorem. A model assumption being exceeded is not the same as a proof being false within its assumptions. Both may matter operationally, but they are different explanations.
This section supplies a classification test, not an attribution of blame. Do not name a responsible operator, attacker or software component without supporting evidence. Preserve the distinction between an apparent conflict, a validated conflict and its cause.
Back to contents · Next section
9. Why waiting and forcing agreement are not equivalent remedies
A stalled system can sometimes preserve a safety boundary by refusing to claim progress without sufficient evidence. That does not make every stall desirable or prove that every stopped system is safe. It means the absence of an answer and the presence of a prohibited answer must be evaluated separately.
Imagine an archive display that changes “finalized” to true whenever a waiting timer expires. This improves the appearance of progress but provides no missing finality evidence. It changes a label, not the protocol result. A user-facing deadline cannot manufacture an authorized certificate.
Similarly, two observers agreeing to display the same head does not prove that the underlying validation and finality conditions hold. A reporting shortcut may conceal a disagreement instead of resolving it. This is why a diagnostic lesson should not casually recommend disabling checks, resetting history or lowering thresholds.
The responsible classroom response is to state the unmet condition and retain uncertainty. In a real deployment, recovery actions require the applicable protocol procedures, authorized operators and an understanding of consequences. This article provides conceptual diagnosis rather than an operational recovery plan.
Back to contents · Next section
10. Six case cards and answer explanations
- The selected head advances through verified valid descendants for six observations, but the finalized checkpoint stays unchanged. Classify this as observed chain growth with stalled finality over that interval. It does not by itself demonstrate conflicting finality or permanent liveness failure.
- Finalized checkpoints advance along one compatible history, while T never appears in the observed interval. Global finality progress is visible; T’s inclusion is not. Investigate its delivery, eligibility and selection evidence before assigning a cause.
- Two current heads differ, but both descend from the same finalized checkpoint. This is not by itself conflicting finalized history. More context is needed to assess whether the head divergence is expected under the protocol’s conditions.
- Two incompatible checkpoints are accepted as finalized by correct participants, with the same relevant rules and the assumed trust context established. This matches the stated safety prohibition. Investigate whether an assumption, implementation or protocol claim failed; the classification alone does not choose the cause.
- A service explicitly promises a result within five rounds under condition C. C is independently established, and six rounds pass without the result. The bounded service promise was missed. Do not silently replace that promise with an unbounded theorem or vice versa.
- T is included in a block covered by the relevant finality condition, but its execution result reports failure. Inclusion and finality do not establish successful completion of the requested application change. Read the execution evidence and the application’s semantics.
For a classroom extension, ask which case can be decided from one head-height chart alone. None has enough evidence in that chart: even the first requires ancestry and finality observations. This reveals why better measurements often matter more than stronger adjectives.
Back to contents · Next section
11. Write an incident note someone else can check
Use five short parts: the property being examined; the observation interval and sources; the relevant assumptions; the actual evidence; and the conclusion with its limits. This structure makes disagreement about an incident easier to resolve because readers can point to a missing fact or an overbroad inference.
For the archive trace, a defensible note is: “Across r0–r2, supplied valid descendant heads advanced from H100 to H108 while finalized checkpoint F90 remained unchanged. T was absent from the selected history. No bounded finality guarantee or cause was supplied, so this establishes observed stalled finality during the interval, not a demonstrated permanent liveness violation.”
A later update can add: “At r3, finality advanced to F100. At r4, T appeared in H114, beyond the supplied finalized checkpoint.” Neither update requires rewriting the earlier observations or pretending they never mattered.
Avoid using “safe” as a blanket verdict after finding no conflict in a small sample. The sample may contain no observed violation, while many executions and failure conditions remain untested. Likewise, a healthy interval does not prove future progress under every environment.
Back to contents · Next section
12. Frequently asked questions
Is liveness the same as speed?
No. A claim about eventual progress differs from a latency target. A useful report can include both, but it should identify the event, deadline if any, and assumptions for each.
Does a halted network automatically have a safety failure?
No. Halting and accepting a forbidden outcome are different observations. A halt may also hide missing evidence, so it is not a proof of safety either.
Does finality guarantee the truth of a museum description?
No. Finality concerns the protocol’s treatment of history. Whether a recorded description matches a physical object requires evidence beyond the consensus mechanism.
Can a transaction be included without doing what its sender wanted?
Yes, depending on execution semantics. Separate inclusion, execution outcome and application intent. They answer different questions even when shown on one screen.
Back to contents · Next section
Sources and next learning steps
Primary references checked on 12 October 2026, Singapore time: Lamport’s 1977 correctness paper, Ethereum’s Gasper overview, attestations guide and transactions guide. Only the stated conceptual distinctions are used here; no universal participation threshold, recovery deadline or penalty schedule is inferred.
The archive trace, five-round promise and case cards are original synthetic examples. Next, study how a protocol decides who may influence consensus. Counting visible identities is not the same as measuring independent participants or valid voting weight, and that distinction affects how its safety and progress assumptions should be read.