eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

Reading Blockchain Consensus Claims: Validity, Fork Choice and Finality

—

by

eduKate Asia
Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

中文版 · Blockchain learning guide · Previous article

Blockchain learning · Article BC021

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.
Study photograph for illustration; it does not establish that the pictured students are studying blockchain.

A blockchain consensus claim should tell you more than whether the system uses proof of work, proof of stake, or a voting committee. A reader needs to separate at least four questions: which blocks are valid, how participation gains weight, which valid history a node currently selects, and what evidence supports treating part of that history as settled under the protocol.

Those questions interact, but their answers are not interchangeable. A large amount of work cannot make an invalid transaction valid. A selected head is not automatically a finalized checkpoint. A protocol that keeps producing blocks does not necessarily guarantee timely inclusion for every user.

This guide teaches a reading method: convert a consensus description into an assumption card, mark what is specified, and leave unsupported claims unresolved. Two fictional descriptions provide practice. They are deliberately incomplete and must not be treated as functioning consensus protocols.

Choose your reading route

In this guide

If you are reading a protocol introduction, start with the four questions and the assumption card. If you are comparing claims, use the two fictional descriptions and the stress questions. If you need the mathematics of replicated logs and quorum intersection, use the existing Distributed Consensus, Quorums and Fault Tolerance guide first.

This article does not repeat that guide’s Raft walkthrough. It applies a different task to blockchain descriptions: identifying the boundaries among validity, participant weight, history selection, finality and timing assumptions.

Back to contents · Next section

1. Four questions hiding inside one word

The word consensus is often used as shorthand for an entire system. That is convenient until a claim needs to be checked. Begin by asking:

  • Validity: what makes a block and its proposed state transition acceptable under the rules?
  • Participation and weight: who can propose or influence agreement, and what determines their effective weight?
  • History selection: among the valid alternatives a node knows, which branch or head does it select?
  • Settlement or finality: what additional condition supports the protocol’s particular stability claim?

Add a fifth question about progress: under which conditions should the system make the promised kind of progress? The promise might concern producing blocks, finalizing checkpoints or including a particular class of transactions. Those are different outcomes.

Our reading method keeps these fields separate even when one implementation combines them tightly. The goal is not to force every chain into one architecture. It is to prevent a label from silently answering questions that its definition does not cover.

A protocol description that fills only the participation field is incomplete as an explanation of consensus. “Anyone can join” does not tell you what they can make the system accept.

Back to contents · Next section

2. Validity comes before comparing eligible histories

Imagine a fictional catalogue transaction with a missing authorization signature. A proposed block includes it as an accepted state update. If that violates the system’s validation rules, popularity or voting weight does not repair the defect. Honest validating nodes should apply the applicable validity rules rather than count support for arbitrary bytes.

The exact boundary is protocol-specific. Some systems reject a block containing an invalid transaction; others record ordered transactions and mark particular transactions invalid so that they do not change application state. A reader must learn which model the named system uses.

Hyperledger Fabric’s ordering-service documentation distinguishes transaction ordering from peer validation. It explains that invalidated transactions can remain in a block while being marked invalid and not updating the ledger state. Thus “included in an ordered block” is not the same statement as “successfully changed the application’s state.”

For any chain, ask which component performs each check and what an acceptance status means. A block-header check, a transaction-signature check and full state-transition validation do not supply identical evidence. Do not let a user interface’s single accepted label erase those differences.

Back to contents · Next section

3. Weight must have a unit and an admission rule

A description might say that a majority supports a history. Majority of what? Network connections, registered identities, computational work, stake weight, or a configured set of organizations? These units lead to different assumptions.

Creating many node identities does not automatically mean controlling the same number of independent decision-makers. A protocol needs some account of how participation is admitted or weighted and what it assumes about adversarial influence. The detailed study of Sybil attacks follows later in this module.

For now, write down the denominator. If the claim uses voting weight, identify which set and which snapshot of weights it refers to. If it uses cumulative work, ask how work is calculated and which blocks are eligible. If it uses authenticated membership, ask how membership and changes to it are established.

Avoid transferring a percentage from one protocol to another. A percentage without its unit, fault model and target property is not a usable security statement. “Tolerates one-third failures,” for example, needs to distinguish unavailable participants from arbitrary adversarial behavior and explain whether the claim concerns safety, progress, or both.

Back to contents · Next section

4. Fork choice is a rule for a node’s current view

A node may learn about multiple valid branches. A fork-choice rule helps it select a head or history based on its available information and the protocol’s rules. Nodes that receive information at different times may temporarily have different views.

Bitcoin’s developer guide describes selection among valid branches using accumulated proof of work. The relevant measure is not simply the number of blocks. The validity qualification is essential: greater work does not grant permission to violate the node’s consensus rules.

For a reading exercise, distinguish three statements: a node received a block; the node found it valid under the checks it performed; the node selected a branch containing it. None should be silently substituted for the next.

A selected head is also relative to a view at a time. A later message can change the information available to the node. Whether and how that affects settled history depends on the protocol’s finality or settlement model, which must be read separately.

A screenshot of one node’s head is useful observational evidence. It is not, by itself, a universal statement that all honest nodes have already seen or selected exactly the same head.

Back to contents · Next section

5. Finality needs a definition and assumptions

Some systems describe settlement confidence in terms of the difficulty or probability of replacing a history under a model. Others have explicit protocol conditions that mark checkpoints or blocks finalized. Those are not interchangeable promises.

Ethereum’s Gasper documentation provides a concrete example of separating a fork-choice component, LMD-GHOST, from Casper-FFG finality. The names identify roles in that design; they are not universal ingredients required by every proof-of-stake chain.

When reading a finality claim, ask what evidence is checked, which participants or weights matter, and which assumptions would have to fail for incompatible finalized outcomes. If the claim is probabilistic, ask which model and parameters support its confidence statement. A confirmation count without that context is not a universal guarantee.

Also distinguish protocol finality from legal settlement, application completion and physical-world delivery. The protocol may establish a property of recorded history while a document shipment, legal transfer or external service remains unfinished.

This lesson only identifies the questions. Later articles trace confirmation and finality timelines and examine the detailed certificates or rules used by particular designs.

Back to contents · Next section

6. Timing and faults qualify different promises

A network assumption might bound message delays, assume that communication eventually becomes well behaved, or adopt another precisely defined model. A fault assumption might limit crashed participants, adversarial voting weight, compromised keys, or other behavior.

The reader should connect each assumption to the property it supports. A system may aim to preserve a safety property during delays while requiring improved communication for progress. That does not mean every delay proves an attack or every stalled system has violated agreement.

A timeout is an observation that something did not arrive before a deadline. It does not, by itself, identify whether the cause was a crash, a partition, overload, censorship or a scheduling delay. The protocol’s response to that observation is part of its specification.

Implementation assumptions matter too. Honest software must interpret the same inputs under compatible rules, preserve required state, and verify authentication correctly. An abstract bound on adversarial participants does not automatically cover a common software bug affecting everyone.

For rigorous background on the difference between a claimed invariant and its implementation, see the existing guide to proving software correct. Here the practical task is to mark which assumptions a blockchain claim actually states.

Back to contents · Next section

7. Fictional description A: an open work-weighted chain

A fictional brochure for “River Chain” says: “Anyone may propose blocks by supplying the required work. Nodes choose the valid branch with greatest cumulative work. Additional accepted blocks increase our confidence in earlier history. Blocks appear quickly.”

This description supplies some information but leaves important gaps. The participation mechanism is work-based, and history selection explicitly considers valid branches. The stability claim is confidence-based rather than a stated finality certificate. However, the brochure has not supplied its precise validation rules, work formula, adversarial resource assumptions, network model or confidence calculation.

“Blocks appear quickly” is particularly incomplete. Is that an average production interval, a measured propagation delay, a target parameter or a user-visible inclusion estimate? What distribution and workload were observed? Does the claim apply during a network disruption?

The correct reading is neither “safe” nor “unsafe” on this evidence alone. It is a partially completed assumption card. The reviewer requests the missing specification and measurements before evaluating the relevant guarantee.

River Chain is invented and is not a disguised specification of Bitcoin. Its short description is an exercise in identifying what a claim does and does not provide.

Back to contents · Next section

8. Fictional description B: an authenticated voting chain

A second brochure, for “Cedar Ledger,” says: “A configured validator set proposes and votes on blocks. A specified certificate rule finalizes a block. Under our bounded-adversary model, conflicting finalized histories should not occur. Progress requires sufficient honest voting weight and suitable communication.”

This brochure distinguishes finality from proposal, and it mentions both adversarial and communication assumptions. Yet it still omits the actual certificate rule, weight snapshot, round-transition conditions, signing restrictions, membership-change mechanism and application-validation rules.

A reader must not fill those gaps by borrowing a familiar threshold from another protocol. Certificate arithmetic alone is not a safety proof. The behavior of participants across rounds and conflicting proposals matters, as do the assumptions under which their signatures and state remain reliable.

The progress claim is also incomplete until it defines progress. Does it mean another block proposal, a finalized block, or eventual inclusion of any valid submitted transaction? What additional admission or scheduling policy governs individual requests?

Like River Chain, Cedar Ledger is a diagnostic description rather than a working algorithm. Its more formal vocabulary does not justify assuming that its implementation satisfies the proposed guarantees.

Back to contents · Next section

9. Compare the cards without inventing a winner

The two descriptions emphasize different evidence and tradeoffs. River’s stated selection rule depends on accumulated work among valid branches. Cedar’s finality claim depends on a specified certificate and participant model. Neither card, as written, provides enough information to rank overall security or performance.

A fair comparison aligns the task. If the application needs a particular kind of settled-history evidence, compare that property under each design’s assumptions. If it needs service during a partition, specify what service and which side of the partition. If it needs low latency, define the event at the start and end of the measurement.

Do not compare River’s average block-production interval with Cedar’s finalized-application-response latency and call the smaller number faster. They measure different events. Similarly, throughput of submitted requests is not necessarily throughput of valid, settled application updates.

Resource costs and governance also differ. Participant admission, operation, recovery, upgrades and verification may depend on different actors. These are legitimate comparison dimensions, but they must be supported by evidence rather than inferred from the labels permissionless or permissioned.

The useful output is a list of matched questions and missing evidence, not a score produced by combining incompatible marketing numbers.

Back to contents · Next section

10. Six stress questions for a consensus claim

Question A. A branch has greater advertised weight, but a full validation check finds a rule violation. Must the node accept it?

Answer. No. Selection rules apply within the protocol’s eligible histories. Weight does not automatically override validity.

Question B. Two nodes show different recent heads. Does that alone prove a safety violation?

Answer. No. Examine the protocol’s allowed temporary divergence and settlement rules. Different local heads are not automatically incompatible finalized outcomes.

Question C. Cedar receives no finality certificate during a disruption. Does that prove it finalized contradictory blocks?

Answer. No. Missing progress and conflicting decisions are different observations. Investigate the promised property and whether its assumptions held.

Question D. River produced blocks throughout the test, but one submitted request never appeared. Is per-user inclusion established?

Answer. No. Chain progress does not by itself prove that every request met inclusion conditions or received fair scheduling.

Question E. A proposal says “two-thirds agree” without defining the participant set or weights. Can the security claim be evaluated?

Answer. Not adequately. The denominator, authentication, fault model, vote rules and target property remain unspecified.

Question F. Fabric includes a transaction in an ordered block but a peer marks it invalid. Did the intended state update necessarily occur?

Answer. No. Ordered inclusion and successful state update are distinct in this workflow. Read the validity result rather than infer success from block membership.

Back to contents · Next section

11. Build an assumption card that remains useful

For a named protocol and version, record eight fields:

  1. The exact validity checks and the component responsible for them.
  2. Participation admission and the unit of influence or voting weight.
  3. The history-selection rule and the information a node needs to apply it.
  4. The finality or settlement claim and its evidence.
  5. The fault model, bound and relevant population or resource denominator.
  6. The timing and communication assumptions for each progress claim.
  7. Membership, upgrade and recovery assumptions that affect the above rules.
  8. The application-visible event the claim actually supports.

Attach a source to each filled field and leave missing fields visibly unresolved. A blank is more honest than an inherited assumption from a different chain. Record the protocol version because rule changes may alter the meaning of an old summary.

Then write one calibrated conclusion. For example: “The description specifies valid-branch selection, but has not supplied the network and adversarial assumptions needed to evaluate its settlement-confidence claim.” That statement moves the review forward without pretending to know more than the evidence supports.

An assumption card is not a formal proof or a production audit. It is a disciplined reading aid that tells you what further evidence is needed and which claims must not be conflated.

Back to contents · Next section

Frequently asked questions

Is proof of stake a complete consensus specification?

No. A system still needs precise validity, participation, voting, history-selection and settlement rules, together with their assumptions.

Does a vote make invalid data valid?

Not under a protocol that requires the violated validity rule. Agreement about bytes and satisfaction of application rules must be distinguished.

Does no fork mean every transaction succeeded?

No. The meaning of fork freedom and transaction validity depends on the system. An ordered record can have a different status from an applied state update.

Can a consensus protocol guarantee every user instant inclusion?

Do not infer that from a general progress claim. Admission, network conditions, capacity, scheduling and censorship assumptions need separate examination.

Back to contents · Next section

Sources and next reading

Sources checked on 12 October 2026, Singapore time. River Chain and Cedar Ledger are original, deliberately incomplete diagnostic examples. They do not specify deployable protocols or claim proved security.

Next, follow two nodes through delayed messages and a network partition. The aim will be to record what each node knows, which head it selects, and what can change when communication returns.

Back to contents