中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC027
A bundle containing three signatures is not automatically a valid blockchain vote certificate. The signatures must authenticate the right statements, come from eligible participants, count only once each and satisfy the required threshold in the correct context. Even then, a same-round counting argument does not by itself explain safety across later rounds.
This guide teaches you to inspect a certificate-shaped evidence packet. We use four fictional validators, a small weighted example and several deliberately defective packets. The exercises are mathematical checks on supplied records, not a new deployable Byzantine fault-tolerant protocol.
Choose your reading route
In this guide
- 1. What Byzantine behavior adds to the problem
- 2. Read the statement before counting its signers
- 3. The four-validator model
- 4. Why two conflicting same-context certificates cannot both fit the model
- 5. Duplicate signatures do not create extra participants
- 6. Height, round and phase are not interchangeable labels
- 7. The across-round gap in the simple proof
- 8. Weighted certificates require the right denominator
- 9. Compact signatures still need participant evidence
- 10. A certificate does not answer every application question
- 11. Six packet decisions, with explanations
- 12. A short certificate-review report
- 13. Frequently asked questions
- Sources and next learning steps
Start with the packet checklist if you want to read consensus evidence more carefully. The four-validator example then explains why honest overlap matters. Continue to round locks to see the limit of that argument, and finish with the six packet decisions.
For general replicated-log and quorum mathematics, use Distributed Consensus, Quorums and Fault Tolerance. Here the task is narrower: determine what authenticated blockchain votes establish, and which missing protocol rules prevent a stronger conclusion.
Back to contents · Next section
1. What Byzantine behavior adds to the problem
A crashed participant stops performing some or all duties. A Byzantine participant may behave inconsistently, send different statements to different observers, withhold messages or violate the protocol in other ways. Which actions are possible depends on the fault model and cryptographic assumptions.
For our exercise, a faulty validator may sign conflicting statements using its own key, but cannot forge another validator’s signature. This is an explicit assumption. It separates one participant’s ability to contradict itself from an ability to impersonate everybody else.
Authentication therefore remains useful even when a participant is dishonest. It can identify which eligible key signed a statement. It does not make that statement truthful or ensure that the signer followed the protocol’s prior steps.
A certificate review must combine cryptographic checks with membership, context and protocol rules. “All signatures verify” is an important observation, but it is not the end of the analysis.
Back to contents · Next section
2. Read the statement before counting its signers
Our fictional vote statement has six fields: network identifier, block height, round, phase, block identifier and validator-set reference. The signature binds the relevant statement under the exercise’s authentication assumptions.
Height identifies the position being decided. Round distinguishes repeated attempts to decide at that height. Phase identifies the kind of vote within an attempt. A preparatory vote and a commitment-stage vote are not interchangeable merely because they mention the same block.
The block identifier identifies the particular candidate. A vote for X cannot be relabeled as support for Y. The validator-set reference tells the reviewer which membership and weights apply. A signature from an old member is not automatically a current vote.
A real protocol has an exact message format and signing procedure, which may bind these concepts differently. Our six-field card is an analytical aid, not a universal wire format. The important habit is to find the protocol’s actual equivalents before doing arithmetic.
For a named example, the CometBFT v0.38.x data-structure specification documents votes, commits, validator sets and their validation context. The version label matters; this article does not present that branch as the current configuration of every CometBFT-based chain.
Back to contents · Next section
3. The four-validator model
Assume a fixed set of four validators: A, B, C and D. Each has equal weight. At most one is Byzantine. Messages are authenticated, and the honest validators obey the following limited rule: for one network, height, round and phase, an honest validator does not sign two different block identifiers.
A candidate certificate in this exercise requires three distinct eligible validators supporting the same statement. We are not defining all proposal, locking, timeout, membership-change or commit rules. The model is enough for a same-context overlap argument, not a complete consensus implementation.
The possible three-validator groups are ABC, ABD, ACD and BCD. Any two different groups share two validators. For example, ABC and BCD share B and C.
Because at most one validator is Byzantine, a two-validator intersection contains at least one honest validator. That honest overlap is the useful result. The intersection is not merely a repeated name on paper; it connects the fault bound to the rule honest participants follow.
If the membership set changed between the two certificates, or the same names referred to different keys, the stated argument would no longer directly apply. Fixed membership and authenticated identity are premises, not optional decorations.
Back to contents · Next section
4. Why two conflicting same-context certificates cannot both fit the model
Suppose a packet for block X contains valid votes from A, B and C. Another packet for different block Y contains valid votes from B, C and D. Both packets claim the same network, height, round, phase and validator set.
B and C would each have signed both X and Y in that context. With at most one Byzantine validator, at least one of B or C is honest. That contradicts the supplied honest non-equivocation rule.
Therefore, under these assumptions, the two conflicting packets cannot both be genuine qualifying certificates. If evidence appears to show both, at least one premise or validation result needs examination. Perhaps a signature is invalid, the contexts differ, membership was misread, the fault bound was exceeded, or an implementation did not enforce the intended behavior.
The argument does not identify which explanation occurred in a real incident. It also does not establish the honest status of a particular signer simply because we named it B or C. The conclusion is conditional on the model’s bound and behavior rule.
This is stronger than saying “three is a majority,” but narrower than proving an entire blockchain safe. It establishes one prohibited coexistence result for one fixed voting context.
Back to contents · Next section
5. Duplicate signatures do not create extra participants
Consider a packet listing A, A and B for block X. It has three entries but only two distinct validators. Under the exercise’s threshold, it fails. Repeating A’s signature, wrapping it differently or displaying it twice does not add an independent vote.
Now consider A, B and an unknown identity E. Three different names are visible, but E is not in the supplied eligible set. Unless the relevant membership rules establish E’s eligibility, the packet still has only two countable participants.
A third packet contains A and B for X, plus C for Y. It has three eligible signers but not three supporting the same statement. The reader cannot combine incompatible votes into a certificate for X.
These are simple cases, but they show why counting belongs after validation. First establish what each authenticated entry means and whether it is eligible. Then deduplicate and apply the appropriate weight or threshold.
Back to contents · Next section
6. Height, round and phase are not interchangeable labels
Suppose A and B signed for X at height 50, round 2, phase P. C signed for X at height 50, round 1, phase P. Our candidate rule requires a common round, so C’s vote cannot complete that packet.
Similarly, a vote at height 49 does not automatically carry over to height 50. A vote from phase P cannot simply be counted as phase Q support. The matching block name does not erase the different signed context.
Some real protocols deliberately use evidence from earlier rounds in carefully defined ways. That is not permission to mix arbitrary messages. It means the specification must say which evidence can be carried forward, how it is validated and what conclusion it supports.
A reviewer should therefore write “does not satisfy this certificate’s required context,” rather than “old votes are always useless.” The first follows the exercise. The second would incorrectly generalize across protocols and message purposes.
The CometBFT v0.38.x consensus description explicitly distinguishes height, round and voting steps. It provides a real example of why those fields are more than labels for a user interface.
Back to contents · Next section
7. The across-round gap in the simple proof
Our honest rule prohibits conflicting votes within the same round and phase. It says nothing yet about signing X in round 2 and Y in round 3 at the same height. An honest participant could satisfy the stated rule in each round separately while contributing to incompatible packets across rounds.
This exposes a missing part of the model, not a failure of the intersection arithmetic. The same sets still overlap, but overlap only helps when the honest behavior rule connects the decisions being compared.
A complete round-based protocol uses additional state and rules to carry safety constraints forward. Locking and carefully justified unlocking are examples of mechanisms that govern which later proposals a participant may support. Their exact conditions affect both safety and the ability to make progress.
The versioned CometBFT consensus specification describes locking behavior and evidence used for changing locks. We cite it to demonstrate that real protocols supply these additional rules. We do not replace them with a homemade instruction such as “unlock whenever the timer expires.”
A timeout can trigger a new attempt without making every old commitment irrelevant. Whether a participant may change support requires the actual protocol rule and evidence. This is the essential reason a three-signature screenshot is not a complete proof about all future rounds.
Back to contents · Next section
8. Weighted certificates require the right denominator
Now use a separate synthetic model with fixed voting weights: A has 40, B has 30, C has 20 and D has 10. Total eligible weight is 100. The illustrative threshold is strictly greater than two thirds of that total.
A and B together have 70, so they pass this numerical threshold. B, C and D together have 60, so they fail it despite being three validators rather than two. Headcount and weight answer different questions.
The denominator is the complete relevant eligible set, not just the validators whose messages arrived. If only A and B are visible to an observer, the observer cannot quietly change the total from 100 to 70 and declare every received vote sufficient under a different ratio.
The strict inequality also matters. For a total of 90, a weight of exactly 60 is exactly two thirds and would not pass a strictly-greater rule. Small wording differences such as “at least” and “more than” can change the result.
This weighted example supplies only a counting rule. To make a safety argument, one would also need an appropriate faulty-weight bound and honest behavior assumptions. The earlier at-most-one-faulty-validator premise cannot be transferred automatically: a single validator in the new example may carry a large share of weight.
Back to contents · Next section
9. Compact signatures still need participant evidence
Some systems represent multiple contributions compactly. A compact cryptographic object does not excuse the verifier from establishing which participants and weights it represents under that scheme’s rules.
If a report presents only an aggregate signature with no usable way to establish the relevant signer set or verification context, the reviewer cannot infer an arbitrary headcount from its size or appearance. The evidence structure must support the intended claim.
Different signature constructions expose participant information differently. A threshold signature may prove that a configured signing process produced a valid signature without publicly listing exactly which participants contributed. That is not the same artifact as a consensus certificate whose verification requires particular validator weights.
For our exercise, we avoid these implementation details by supplying individually labeled authenticated votes. The simplification makes counting transparent, but it should not become a claim that every real certificate uses that encoding.
Back to contents · Next section
10. A certificate does not answer every application question
Even a qualifying certificate has a defined purpose. It may support a protocol decision about a block, but the reader must still know which validity checks and assumptions connect that decision to the intended conclusion.
A certificate does not by itself prove that a physical shipment arrived, that a document author had legal authority, or that an application query used the correct interpretation of recorded data. Those claims require different evidence.
Nor should a reviewer assume that every transaction inside a committed block produced the user’s desired result. Execution outcomes and application semantics remain separate. What the consensus certificate says must be distinguished from what the application wants it to say.
For a classroom archive, a certificate might establish the accepted ordering of a catalogue update under the model. It cannot establish that the described artifact is genuine. This boundary keeps the lesson connected to useful record-keeping without overstating what agreement achieves.
Back to contents · Next section
11. Six packet decisions, with explanations
- A, B and C sign the same X statement in the supplied fixed context, and all eligibility and signature checks pass. The packet meets the exercise’s three-distinct-validator threshold. The model still is not a full production protocol.
- The packet contains A, A and B for X. Reject it as insufficient distinct support: there are only two countable validators.
- A and B support X, while C supports Y. Reject the claimed certificate for X because only two supplied votes support it.
- A and B support X in round 2, while C supports X in round 1. It does not meet the exercise’s same-round certificate rule. Any permitted cross-round use would require additional specified rules.
- In the weighted model, B, C and D support X. Their total is 60 of 100, below the strictly-greater-than-two-thirds requirement. Three names are not enough under that weight rule.
- Two three-validator packets conflict across different rounds, while the only stated honest rule concerns one round at a time. The available model is insufficient to prove across-round safety. Ask for its locking, unlocking and evidence-carryover rules rather than pretending the arithmetic supplies them.
For an extension, list all four three-validator groups and compare each pair. Every pair of different groups shares exactly two validators. Then remove the honest non-equivocation assumption: the overlap remains mathematically true, but the prohibited-coexistence conclusion no longer follows from it alone.
Back to contents · Next section
12. A short certificate-review report
A useful report records the claimed decision, network and version context, membership reference, signed statement fields, verification results, deduplicated participant support and threshold calculation. It then states what the packet establishes and what remains outside the evidence.
For the first case, write: “The supplied authenticated votes from A, B and C match the same statement and fixed eligible set, so they satisfy the classroom three-of-four certificate rule.” Do not silently expand that to “the whole blockchain is secure forever.”
For the across-round case, write: “The same-round intersection argument is insufficient because no rule governing later-round support was supplied.” Recognizing an incomplete specification is a useful result. It is better than inventing a missing safety mechanism.
Back to contents · Next section
13. Frequently asked questions
Is three-of-four a universal blockchain quorum?
No. It belongs to this equal-weight, fixed-membership exercise with its stated fault bound. Other protocols have different thresholds, weights, phases and assumptions.
Does a Byzantine signer invalidate every packet it signs?
Not automatically. The point of fault tolerance is to reason about qualifying evidence despite a bounded amount of faulty behavior. The actual protocol determines the acceptance conditions.
Does a timeout prove that earlier votes can be ignored?
No. It may change the round or trigger another action, but the safety implications depend on the protocol’s state and evidence rules.
Is signature verification enough to establish a quorum?
No. Eligibility, statement matching, deduplication, weights, context and the threshold must also be checked.
Back to contents · Next section
Sources and next learning steps
Primary technical references checked on 12 October 2026, Singapore time: the CometBFT v0.38.x consensus specification and v0.38.x data-structure specification. They are version-specific examples of a real protocol, not documentation for our fictional worksheet. The four-validator and weighted packet calculations are original teaching exercises.
Next, examine transaction finality from a recipient’s point of view: how submitted, included, confirmed, reorganized and finalized observations differ, and what evidence an application should attach to each label.