Many computers can still share one software mistake. Use a fictional record-checking club to understand independent clients, common specifications, correlated failures and the limits of counting nodes.
Part of How Blockchain Works — the beginner series. Read for understanding technology, not for cryptocurrency investment advice.
The people, workshops and numerical examples in this guide are fictional teaching examples. Platform-specific behaviour is identified rather than assumed to apply to every blockchain.
Technical companion: continue into the structured learning guide.
Choose your reading route
This guide has 18 short chapters. Read straight through or begin with the question you need.
- 1. Count the right thing
- 2. Understand independent implementations
- 3. Map common dependencies
- 4. Read diversity evidence
- 5. Practise a failure map
Chapter index · Check your understanding · Blockchain learning hub
Chapter index
Count the right thing · Chapters 1–3
Understand independent implementations · Chapters 4–7
Map common dependencies · Chapters 8–11
Read diversity evidence · Chapters 12–15
Practise a failure map · Chapters 16–18
A fictional club runs ten copies of its notebook checker. Every copy contains the same bug: it accepts a second loan that the rulebook forbids.
All ten agree on the wrong answer.
The number of computers gives the club several running copies, but it does not give ten independent implementations of the rule.
This introduces client diversity. A client is software that implements relevant network behaviour. Different clients can be developed independently while following a shared specification.
Our club is fictional and its bug is a paper example, not a report about any named software.
The beginner question is what is actually diverse. Machines, software implementations, operators and infrastructure are different things.
A clear explanation identifies the category being counted before claiming that a large number means a particular kind of resilience.
A node is a running participant in the network’s architecture. A client is software that provides the relevant implementation.
Several nodes can run the same client. One operator can run several nodes.
These relationships mean that node count, client count and operator count need not match.
Our paper model draws ten devices and writes one software name beneath each. A second line names the people or organisations operating them.
The picture can change without changing every count. Ten devices might use two clients but one operator, or one client but several operators.
Neither arrangement is fully described by saying there are ten participants.
This is why the nodes-and-shared-copies guide is only the starting point. Once the copies are visible, the next question is which dependencies and decision-makers sit behind them.
The fictional club has a written rulebook defining valid notebook behaviour. Two teams can build different programs intended to implement that rulebook.
The rulebook and the programs are related but not identical.
A protocol specification defines expected behaviour. A client implementation is real software that attempts to realise the relevant rules.
This distinction supports the idea of independent implementations. Different codebases can aim at the same accepted behaviour.
It also explains why popularity alone cannot establish correctness. A widely deployed program can contain a defect relative to the specification.
Our paper exercise gives each team the same written requirement and test cases. A disagreement prompts investigation into the rule, implementation or context.
The useful beginner habit is to ask which claim concerns the shared specification and which concerns a particular program’s actual behaviour.
One fictional team writes a checker using one programming language, and another team uses a different language and internal structure.
For the same defined input, state and rules, both should produce the specified relevant result.
They need not execute the same machine instructions internally. Their implementations can organise storage, scheduling and computation differently.
This is the connection to the virtual-machine guide. Agreement concerns the specified behaviour, not identical source text.
Independent design can reduce some chances that one implementation-specific mistake appears everywhere.
It does not guarantee there are no shared mistakes or that every differing program is correct.
Our paper example deliberately separates implementation from result. Two routes through the calculation can be acceptable when they satisfy the same specification.
The goal is compatible independent checking, not variation merely for its own sake.
The fictional lending checker mishandles one unusual request. Every node running that affected version may respond incorrectly when it encounters the same trigger.
A defect shared across many copies is a correlated risk: the failures are linked by a common cause.
Adding more copies of the same version does not automatically remove that cause.
This does not mean replication has no value. It can still help with other problems, such as one device failing.
Different resilience measures address different failure modes.
Our paper map draws one bug box connected to every affected client instance. The picture makes the shared cause visible.
A useful explanation says which failure the extra copies are expected to tolerate. “There are backups” is incomplete when the concern is not one lost machine but one repeated software behaviour.
The fictional club has two client names, but both use the same library for an important check. A defect in that shared dependency could affect both.
Different branding or code repositories does not prove complete independence.
Implementation diversity can exist alongside common components, assumptions and tooling.
The right question is which dependencies matter for the failure being considered.
Our paper map adds a shared-library box below two programs. It does not claim that every shared library is a problem. Reuse can be practical and well reviewed.
The lesson is to avoid an overstatement. Independent development reduces certain correlations; it does not erase every common cause.
A careful discussion names what is known about the implementation relationship and leaves unexamined dependencies as uncertainties rather than treating the number of logos as a complete security analysis.
The fictional rulebook says a loan limit resets “at the end of the period” without defining the boundary precisely.
Two independent teams interpret the phrase differently.
The resulting disagreement is not necessarily caused by one team copying the other’s bug. The specification itself may be ambiguous.
Client diversity can help expose such disagreements through comparison, but it does not magically resolve the intended meaning.
The club needs a legitimate clarification process and appropriate testing of the agreed interpretation.
This connects diversity to governance and upgrades.
Our paper exercise changes a vague phrase into a precise condition, then asks both teams to implement and test it.
The beginner takeaway is that resilience depends on more than separate teams. Clear specifications, careful implementation and a way to investigate differences all contribute to a coherent multi-client system.
Ethereum’s node architecture distinguishes execution-client and consensus-client responsibilities. A statement about client diversity should identify which layer it concerns.
The execution side handles relevant transaction and state-transition work. The consensus side handles its defined agreement responsibilities.
The architecture has additional roles and details, but this distinction is enough to prevent one common confusion.
Our fictional club uses a rule-calculation program and a notebook-agreement program as separate teaching boxes. Counting varieties of one does not establish diversity in the other.
The technical companion explains the boundary in more detail.
A beginner should therefore ask whether a chart concerns execution software, consensus software or some other participant role. A single unlabeled percentage can hide the category.
Diversity is meaningful only after the object being measured has been defined.
The fictional club runs two different clients, but one organisation controls every deployment and all configuration decisions.
There is software variety without corresponding independence of operation.
Another arrangement could have many independent operators all using one client. That spreads operational control while retaining a common software dependency.
Neither description is complete by itself.
This is why decentralisation should not be compressed into a single count.
Our paper table uses separate columns for client and operator. A third column will later show infrastructure.
A useful claim says which distribution it describes and why that distribution matters to a stated failure or authority question.
The lesson is not that one perfect mixture can be selected from a beginner diagram. It is that the diagram should not silently substitute software names for independent decision-makers or vice versa.
The fictional club’s independently operated devices all depend on one power connection. A power failure can stop them together despite their different clients.
Real deployments can share infrastructure dependencies such as providers, network paths or physical locations.
The specific dependency matters. This guide does not assert current concentration figures or rank providers.
Its purpose is to add another layer to the failure map.
A software-diverse system can still have operational correlations, just as a geographically spread system can still share one faulty client.
Draw the relevant common causes instead of assuming a list of addresses represents every independence property.
This connects the guide to network partitions and incident recovery. A system’s response depends on what actually fails together. Counts are useful when they match that question; they mislead when they conceal the shared structure behind the count.
CHAPTER 11 OF 18
11. A minority implementation does not guarantee unaffected progress
The fictional club has several unaffected checkers after one client encounters a bug. That is valuable, but whether the whole record process continues depends on the protocol and distribution of relevant authority.
The mere existence of an alternative program does not automatically supply every quorum or progress condition.
In proof-of-stake contexts, the relevant consensus weight is not simply a count of software downloads.
This guide deliberately avoids numerical threshold claims about a current network.
The important question is how the failure affects the protocol stage being examined. Does execution checking disagree? Does block production continue? Does finality advance?
The network-delays guide separates safety and liveness. Client diversity should be discussed with the same precision.
A resilience claim needs both a failure scenario and a protocol context, not only a statement that at least two client names exist.
Suppose eight fictional checkers accept an invalid request and two correctly reject it under the agreed rulebook.
The count does not make the request valid.
Protocol correctness and the observed distribution of software behaviour are different questions.
A disagreement can have serious network consequences, but it still needs investigation against the applicable specification and evidence.
Our paper model asks readers to inspect the rule that was violated instead of voting for the larger pile of result cards.
This is a useful counterweight to the idea that consensus means truth is whatever most screens say.
The actual network’s decision mechanisms must be explained on their own terms. A client-diversity diagram is a map of implementation use, not a replacement for block validity rules or an independent proof that the most popular implementation is always right.
The fictional club labels two deployments Checker A, but one runs an older release with a known difference in behaviour.
A client-family count can hide version variation.
Version diversity is not automatically the same as useful independent implementation diversity. An old version can also be incompatible or unsuitable for the required rules.
The point is not to recommend a particular release policy. It is to describe the deployed system accurately.
A technical report should identify the scope of its measurement: families, versions, active participants or another defined category.
Our paper map writes both client family and version beside each instance.
That small addition explains why a broad software-name label may be insufficient for diagnosing an incident. The relevant question is which actual implementation behaviour was present, not merely which brand appeared on a diagram.
A fictional survey reports that Client A has half the network. Half of what?
It could mean half the reachable nodes observed by the survey, half the listed operators or half the relevant validator weight under a defined method.
These quantities can differ.
A useful measurement names its population, observation time, identification method and uncertainty.
Some participants may be difficult to identify or missing from the sample. A chart’s clean slices do not remove those limitations.
This guide offers no current client-share figures because the learning goal is how to interpret the evidence.
The beginner can still ask the right questions. Which layer was measured? What was counted? How were clients recognised? What was not observed?
A proportion becomes informative when its denominator and method are visible, rather than when its colours look precise.
Two fictional clients compute different results for the same claimed case. The club records the discrepancy.
It still needs to check that the code version, input, state and execution context really match. A different starting condition can explain a different output without an implementation defect.
The virtual-machine guide introduced this replay boundary.
If the conditions match, the specification and implementation behaviours need examination. The discrepancy alone does not identify the correct answer or the exact cause.
Our paper exercise labels observed difference separately from established bug.
This is a general evidence habit. Diversity can make a problem visible, but visibility is only the beginning of diagnosis.
A useful incident account explains what was compared, which mismatch was reproduced and how the finding relates to the rulebook. It does not stop at a dramatic screenshot of two different numbers.
The fictional club develops common cases for its separate client teams. Ordinary, boundary and invalid inputs help compare behaviour under the same defined conditions.
Agreement on selected tests adds evidence. It does not prove that every future case is correct.
The testing guide explains why case selection and properties matter.
A multi-client design needs both compatibility and independence: implementations should conform to the same rules without every component merely copying one unexamined code path.
Those aims can require careful engineering and review.
Our classroom version does not build real clients. It gives two readers different instruction sheets intended to implement one policy, then compares their answers on carefully chosen cases.
The lesson is to understand what testing contributes. A shared test result is scoped evidence about examined behaviour, not a complete certificate that all failure modes have become independent.
Draw six fictional nodes. Give four Client A and two Client B. Assign three operators and two infrastructure providers independently of those software labels.
Now draw a bug affecting only Client A, an operator outage and a shared-provider outage as three separate scenarios.
For each, mark the affected nodes. Do not assume that the same count answers every scenario.
Then add a shared library used by both clients and discuss how it changes one part of the map.
Finally label what your map does not establish, such as real consensus progress under an unspecified protocol.
No current network data or live deployments are involved.
The exercise succeeds when a reader can explain why many nodes, many clients, many operators and many providers describe different dimensions of resilience.
Client diversity concerns independently developed software implementing shared network rules. It can reduce particular common software risks, but it does not eliminate every dependency or settle every decentralisation question.
The complete picture includes implementation families, versions, operators, infrastructure and protocol consequences.
Carry three questions into the technical companion: diverse in what, measured how and resilient against which failure?
Our fictional club shows why ten copies can repeat one bug, why two client names can share a dependency and why a popular result is not automatically a valid one.
The aim is not to select software from a beginner article. It is to make a resilience claim intelligible.
A precise dependency map gives readers a stronger understanding than a reassuring count because it shows both the independence that exists and the common causes that remain.
Worked situations
| Situation | What it means | What to check next |
|---|---|---|
| Ten nodes run one affected version | Replication can repeat a software defect | Identify the common implementation |
| Two clients share a critical library | Some independence exists, but a dependency remains | Map the shared component |
| A chart shows fifty percent | The denominator is not yet known | Check population, layer and method |
| Two clients disagree | A discrepancy is observed | Match context before diagnosing the cause |
Check your understanding
- Are nodes and clients identical?
- Do different names prove complete independence?
- Does a popular answer override validity rules?
- Why distinguish operator and client diversity?
- What should a diversity measurement name?
Answer guide: No: one is a running role and the other software. No. No. Operational control and software failure dependencies are different. It should name the layer, population, observation time, method and uncertainty.
Continue learning
- Simplest Explanation
- A Record’s Journey
- Digital Fingerprints
- Keys and Digital Signatures
- Nodes and Shared Copies
- Consensus and Agreement
- Smart Contracts and Rules
- Oracles and the Outside World
- Public, Private and Consortium Networks
- Confirmations and Finality
- Wallets and Custody
- Tokens and What They Represent
- Supply Chains and Handovers
- Certificates and Credentials
- Databases and When Blockchain Helps
- Scaling and Layers
- Bridges Between Networks
- Fees and Computing Resources
- Governance and Upgrades
- Privacy and What Records Reveal
- Zero-Knowledge Proofs
- Block Explorers and Reading a Record
- Testing Rules and Finding Mistakes
- Merkle Trees and Small Proofs
- Data Availability and Missing Pieces
- Forks and Changing Histories
- Digital Identity and Proving Who You Are
- Light Clients and Checkpoints
- Multisignature and Shared Control
- Network Delays and Partitions
- Incident Response and Recovery
- Transaction Order and Fairness
- Token Approvals and Remaining Permission
- NFTs, Metadata and Linked Files
- Logs, Events and Application Memory
- UTXOs and Change Outputs
- Proof of Work and Targets
- Proof of Stake and Validator Duties
- Post-Quantum Cryptography and Migration
Technical companion · English–Chinese Blockchain hub
References and scope
Sources checked 15 October 2026. Specifications and implementations differ and can change. This is a conceptual beginner guide, not operational, security or investment advice.
Return to chapter index · Begin with the simplest explanation
How Blockchain Works · beginner reading sequence: 1. Simplest Explanation · 2. A Record’s Journey · 3. Digital Fingerprints · 4. Keys and Digital Signatures · 5. Nodes and Shared Copies · 6. Consensus and Agreement · 7. Smart Contracts and Rules · 8. Oracles and the Outside World · 9. Public, Private and Consortium Networks · 10. Confirmations and Finality · 11. Wallets and Custody · 12. Tokens and What They Represent · 13. Supply Chains and Handovers · 14. Certificates and Credentials · 15. Databases and When Blockchain Helps · 16. Scaling and Layers · 17. Bridges Between Networks · 18. Fees and Computing Resources · 19. Governance and Upgrades · 20. Privacy and What Records Reveal · 21. Zero-Knowledge Proofs · 22. Block Explorers and Reading a Record · 23. Testing Rules and Finding Mistakes · 24. Merkle Trees and Small Proofs · 25. Data Availability and Missing Pieces · 26. Forks and Changing Histories · 27. Digital Identity and Proving Who You Are · 28. Light Clients and Checkpoints · 29. Multisignature and Shared Control · 30. Network Delays and Partitions · 31. Incident Response and Recovery · 32. Transaction Order and Fairness · 33. Token Approvals and Remaining Permission · 34. NFTs, Metadata and Linked Files · 35. Logs, Events and Application Memory · 36. UTXOs and Change Outputs · 37. Proof of Work and Targets · 38. Proof of Stake and Validator Duties · 39. Post-Quantum Cryptography and Migration · 40. Virtual Machines and Replaying Rules · 41. All-or-Nothing Execution and Its Boundaries · 42. Client Diversity and Software Independence · 43. Benchmarks, Throughput and Finality · 44. Encoding and Serialisation · 45. RPC Requests and Access Points · 46. State Snapshots, Pruning and Archives · 47. Timestamps and Clock Limits