A blockchain network’s useful description starts with its permissions: who may read, submit, validate and change the rules. Public, private and consortium are broad labels; the actual control arrangement determines what participants can do.
Continue from How Blockchain Works | Simplest Explanation, or begin here if this is your current question. The guide develops the idea through 18 chapters, concrete situations and a paper activity. Its scenarios are fictional teaching models; a real service follows its specified network and application rules.
The Master Blockchain technical companion provides the deeper route after the everyday explanation here.
Choose your reading route
- Describe the shared job · Chapters 1–3
- Map the permissions · Chapters 4–7
- Compare control arrangements · Chapters 8–11
- Examine operation and change · Chapters 12–15
- Choose and practise · Chapters 16–18
Full chapter index · Worked situations · Answer check · Master Blockchain hub
Full chapter index
Describe the shared job · Chapters 1–3
Map the permissions · Chapters 4–7
Compare control arrangements · Chapters 8–11
Examine operation and change · Chapters 12–15
Choose and practise · Chapters 16–18
CHAPTER 1 OF 18 · Describe the shared job
1. Start with the people sharing the record
Three fictional community workshops lend tools between their members. They want a common record of which workshop has a drill and when it is due back.
Before choosing a technology, they must decide who participates and what each participant may do.
Should every visitor see the complete loan history? Can members propose entries? Which organisations operate the record? Who changes the borrowing rules?
Those questions make the network easier to understand.
The workshops are a teaching example, not an assertion that tool lending needs blockchain. An ordinary database operated by a trusted organisation may serve them well.
We will compare several possible arrangements without declaring one universally superior.
A label such as “public” describes part of a design. It does not supply all the permissions, governance or privacy details.
Begin with the job and the parties. The control map can then show whether the proposed network fits what they actually need.
CHAPTER 2 OF 18 · Describe the shared job
2. Reading and writing are different permissions
A visitor can read the workshop’s public opening hours. That does not grant permission to change a drill’s borrower.
A member may submit a loan request without being allowed to approve it.
These are ordinary distinctions, and a shared digital record needs them too.
For our toy system, separate reading records from submitting proposed changes and from approving particular business actions.
The permissions may differ by data field, role and organisation.
A network can allow broad visibility while restricting particular changes. It can also limit visibility while allowing several organisations to participate.
Therefore, do not infer the whole access policy from a single word.
In the classroom, give a visitor a reader card and a member a request card. Let both examine the same loan page, then ask who may perform each action.
The exercise makes one point clear: access to information is not the same as authority over it.
A useful service states both.
The workshop member submits a properly authorised request. Which participants check that it meets the relevant network and application rules?
That is a separate question from who may use the website.
A participant can read records or submit requests while relying on other participants for particular protocol duties.
The actual division depends on the network.
Our workshop model distinguishes ordinary borrowers, organisational representatives and computers performing specified checking or agreement roles.
These categories are not necessarily identical.
A diagram containing one box for “users” and another for “blockchain” hides important authority.
Replace it with named jobs.
The learner should ask who checks permissions, who establishes the accepted sequence and who presents the resulting answer.
When a service advertises openness, identify which job is open to whom.
Broad access for readers does not automatically mean unrestricted participation in every decision.
The permission map provides a clearer account than a slogan about everyone being part of the network.
The workshops want to change the maximum loan period.
A person allowed to borrow a drill should not automatically be able to rewrite that rule for everyone.
Network configuration, programme upgrades, membership decisions and ordinary loan entries can involve different powers.
Our model names a governance process for those changes. The process is fictional and must be evaluated against the organisations’ requirements if anyone builds a real service.
The important lesson is to include rule-changing authority in the control map.
A network may spread day-to-day checking across several participants while retaining concentrated power over upgrades.
That combination may be intentional, but it should be visible.
For the classroom, give separate cards for borrower and rule editor. Ask whether a valid borrowing request can alter the editor’s powers.
The answer should follow the written arrangement.
Understanding blockchain includes who can modify its operation, not only how its current records are checked.
A network described as public may allow outsiders to inspect significant parts of its history.
That does not tell us every detail about application permissions, data interpretation or administrative control.
Public records can also contain encoded information, references or identifiers whose meaning requires additional sources.
For our workshops, one proposal publishes tool availability while keeping individual contact information elsewhere.
Another publishes the full loan record. These are different information choices, even if both involve a publicly accessible ledger.
Readers should ask which data is visible, through which interfaces and with what ability to check it independently.
Visibility can support scrutiny. It can also create information exposure and interpretation challenges.
The useful comparison therefore includes the actual fields and audience.
The word “public” is not a guarantee that every record is easy to understand, that every participant is independent or that every real-world claim is correct.
Describe the visible record before drawing conclusions from the label.
Permissionless participation concerns admission to specified network roles under the protocol’s conditions.
It does not mean every proposed change is automatically accepted.
A network still defines valid instructions, accepted histories and relevant participation mechanisms.
Nor does one newly created username necessarily equal one equal unit of decision power.
Consensus and Agreement explains why participation rules need more precision.
For the workshop comparison, imagine an arrangement that permits broad protocol participation while the loan programme still restricts borrowing to approved workshop members.
These boundaries can coexist.
The learner should separately inspect network participation and application authority.
A child-friendly analogy is a public playing field with a defined game. Being able to enter the field does not make every possible move valid.
The analogy is limited; a real network’s admission and consensus conditions need their own specification.
The practical question remains: which role can anyone attempt to perform, under which checks and costs?
A private arrangement often restricts participation and may place important powers under one organisation’s control.
But the label alone does not identify all the operators, visibility settings or governance powers.
Our workshop network might be administered by the community association. Members use the service, while the association appoints operators and changes configuration.
That arrangement has identifiable responsibilities.
It also requires the workshops to trust the association’s relevant decisions and operation.
Adding hash links or several machines does not remove that dependency.
For learners, draw the association at the centre of the authority map and distinguish its machines from independent organisational control.
The arrangement may still be useful. The question is whether its guarantees improve the actual workflow compared with simpler options.
A private network is not inherently secure merely because outsiders lack access.
Its risks and benefits depend on permission enforcement, operators, software, recovery and the actions its administrator can take.
CHAPTER 8 OF 18 · Compare control arrangements
8. A consortium shares governance among organisations
In a consortium arrangement, several organisations participate in an agreed control and governance structure.
For our workshops, the three organisations might jointly decide membership and appoint relevant operators.
That makes the shared-control question explicit: what can one workshop do alone, and what requires support from others?
It does not mean every decision must be unanimous.
The actual agreement could define different approval rules for admitting a member, changing a borrowing programme or resolving a disputed tool record.
The organisations also need responsibilities for costs, incidents and departures.
For a classroom, give each workshop a governance card. Write which proposals need one, two or three approvals under the toy rules.
Then test a unilateral rule change.
The activity shows why “shared” must be described through particular powers.
A consortium can reduce some dependence on one organisation while creating coordination work among several.
Assess the complete arrangement rather than assuming that several logos automatically create balanced control.
CHAPTER 9 OF 18 · Compare control arrangements
9. Permissioned networks still require trust analysis
Known organisations can make responsibilities easier to identify.
They can still make mistakes, lose credentials, disagree or become unavailable.
A permissioned design therefore needs rules for faults and improper actions, just as other designs do.
The question is which assumptions the service makes about members and how it responds when those assumptions fail.
Our workshops know each other, but they may disagree about a damaged drill. Their identity records do not settle the damage claim.
They may also rely on a common hosting provider or one administrator.
These dependencies belong in the explanation.
For learners, replace “we know them, so it is fine” with a map of which action each party can perform and what evidence would reveal a misuse.
Trust becomes more manageable when it is specific.
A design can limit certain powers, preserve evidence and provide recovery procedures without pretending that organisational identity removes every risk.
The label begins the analysis; it does not complete it.
CHAPTER 10 OF 18 · Compare control arrangements
10. Privacy is a design, not a synonym for private
A network can restrict membership while still sharing sensitive data widely among its admitted participants.
Conversely, an application on a publicly accessible system can keep some information outside the shared record under controlled access.
These arrangements require careful explanation.
Our workshops do not need to publish every member’s phone number to coordinate a drill loan.
Their design should identify which fields serve the shared job and which remain in appropriate private records.
Even identifiers can reveal patterns when combined with other information.
Hashing a field does not automatically make it confidential.
The classroom uses fictional workshop names, toy equipment numbers and no personal data.
For real services, privacy requirements must be matched with the actual distribution, retention and access arrangements.
Ask who receives each field and what they can infer from it.
A reassuring network label should not replace that account.
Understanding information flow is part of understanding the network’s real control boundary.
CHAPTER 11 OF 18 · Compare control arrangements
11. Three machines can still belong to one operator
The association places a computer at each workshop. One administrator controls all three.
The network now has three locations. It does not necessarily have three independent authorities.
Distribution of machines and distribution of decision rights are different properties.
Several providers can also share infrastructure or credentials, creating common failure points.
Our learner should count the relevant actors separately from the computers.
Ask who can stop the service, change its configuration, replace operators and approve records.
Then ask which powers can be exercised independently.
A classroom can show this by giving one player all three operator cards. The visible machines are spread out, but the control is concentrated.
Next, distribute the cards among independently governed workshop teams and compare the consequences.
Neither arrangement is automatically the best choice.
The point is to identify what the proposed distribution actually achieves.
A good explanation names the unilateral action or failure that shared control is intended to constrain.
CHAPTER 12 OF 18 · Examine operation and change
12. A member’s departure needs a plan
One workshop leaves the consortium. It still holds equipment and copies of relevant records.
What happens to its active permissions, outstanding loans and ability to inspect earlier history?
Those questions should be considered before the departure.
Removing a network role does not automatically retrieve a physical drill or erase every distributed copy.
Our toy agreement specifies who handles the outstanding loan, how authority changes and which records remain available for reconciliation.
A real service would need its own operational and information requirements.
For learners, remove one workshop’s governance card while leaving an active loan on the board.
Ask which actions are still authorised and who can complete the handover.
If the written rules cannot answer, the gap is visible.
A shared network operates across changing organisational relationships.
Its value depends partly on handling those changes without leaving people or records stranded.
The departure plan is therefore part of the network explanation, not an afterthought.
CHAPTER 13 OF 18 · Examine operation and change
13. Recovery and disputes cross the digital boundary
The loan record says Workshop B returned the drill. Workshop A says the returned drill was damaged.
The network may establish an accepted history of acknowledgements. It does not automatically decide the physical dispute.
The organisations need an evidence and resolution procedure.
They also need a response when credentials are lost, software fails or records require correction under authorised rules.
Those procedures can differ across public, private and consortium arrangements.
For our comparison, ask who receives the complaint, which evidence is examined, who may intervene and what the intervention changes.
A recovery power can be useful while also introducing an authority dependency.
Both sides of that tradeoff should be visible.
For the classroom, add a disputed-damage card after a digitally completed return. Do not erase the earlier acknowledgement. Follow the separate resolution rule.
The activity explains why a reliable history and a satisfactory business outcome are related but distinct.
The network does not replace every human responsibility around the tool.
CHAPTER 14 OF 18 · Examine operation and change
14. The whole operating cost matters
A proposed network needs software, infrastructure, administration, monitoring and people capable of handling changes.
The workshops should compare these responsibilities with the benefits they expect.
A design that avoids one coordination problem may create another: maintaining membership, supporting several implementations or reconciling separate interfaces.
Transaction fees, if relevant, are only one part of the total cost.
Our guide does not quote prices or recommend a service.
Its purpose is to give the beginner a complete enough question: what ongoing work makes the promised record useful?
If the workshops already accept one trusted operator, a conventional database with appropriate permissions and an audit trail may be simpler.
If they need to limit unilateral control, a shared arrangement may deserve further examination.
Neither conclusion follows from a fashionable label.
The comparison should identify the specific requirement, the proposed guarantee and the total operational burden.
Technology earns its place by improving the actual job at an acceptable cost.
CHAPTER 15 OF 18 · Examine operation and change
15. Build a permission map before choosing the label
Make four columns: read, submit, validate and change the rules.
List visitors, borrowers, workshop representatives, network operators and governance participants down the side.
Fill each cell with the actual permission or condition.
Now add information access and recovery powers where they differ from the basic roles.
This produces a more useful description than selecting “public” or “private” first and trying to infer everything else.
For the fictional workshops, a visitor may read availability; a borrower may request a loan; designated parties may approve a handover; separate authorities may govern membership.
The map should also show who can change the map.
A classroom can compare two proposed networks using the same participants and workflow.
The different control arrangements become visible at once.
The labels are then summaries of the design rather than substitutes for it.
That order makes the choice easier to justify and the service easier for the next person to understand.
Give three workshop teams a shared toy loan record and different permission cards.
Process one valid borrowing request. Then ask a visitor to change a borrower, one workshop to admit a fourth member and an operator to modify the borrowing rule.
Apply the written map to every case.
Next, let a workshop leave while holding a drill. Use the departure process to handle permissions and the physical loan.
Finally, introduce a disputed damage claim.
The activity should show which questions the network rules answer and which need external evidence or organisational resolution.
The paper model is not a secure blockchain.
It teaches the authority map and its missing cases.
Ask each team to explain what it can do alone, what it requires from others and who can change its powers.
Those answers provide a concrete account of control.
They also show why an arrangement can be distributed in one sense and concentrated in another.
CHAPTER 17 OF 18 · Choose and practise
17. Read network claims through the actual powers
A service describes itself as decentralised, private or consortium-based.
Ask which participants may read the relevant data, submit changes, validate the record and alter the rules.
Then inspect common operators, membership changes, recovery powers and the evidence needed for outside-world disputes.
The answer may reveal useful shared control. It may also reveal dependencies the label did not explain.
This is not a reason to reject every network.
It is a way to determine whether the design meets the requirements people actually have.
Hyperledger Fabric provides a primary example of a configurable permissioned platform. Its particular architecture should not be treated as the definition of every permissioned design.
Our workshop comparison keeps the focus on roles.
Once the permissions are explicit, public, private and consortium become clearer descriptions.
The beginner can judge the claim through observable powers rather than relying on a word that sounds either reassuring or impressive.
The workshops need a record people can use, check and recover as their relationships change.
A public, private or consortium network might meet particular requirements. A conventional shared service might meet them more simply.
The choice should follow the permission map, evidence needs and operating plan.
A child-friendly explanation is that different networks let different people do different jobs. We should ask who can see, add, check and change things.
An adult explanation adds admission, governance, privacy, independence and recovery.
Return to Nodes and Shared Copies for the running participants. Consensus and Agreement explains accepted history. Oracles and the Outside World explains evidence entering the record.
The technical Master Blockchain lesson offers a deeper comparison of network types.
The closing question is practical: which arrangement gives these participants the necessary powers and limits, while keeping the service intelligible?
That question leads to a useful design even when the final answer is a simpler database.
Worked situations: locate the next check
| Situation | What it establishes | Next check |
|---|---|---|
| Public availability page, restricted borrowing | Reading and writing permissions differ. | Map each role instead of inferring from visibility. |
| Three nodes controlled by one administrator | Machine distribution does not prove independent authority. | Identify who can act unilaterally. |
| Consortium member leaves with equipment | Revoking network access does not complete a physical return. | Use the departure and reconciliation procedure. |
| Private ledger distributes personal details to all members | Restricted admission alone does not establish suitable privacy. | Trace each field and recipient. |
Check your understanding
Five questions: Does public visibility grant permission to change every record? Does permissionless mean ruleless? Do three machines necessarily mean three independent operators? Can known participants still disagree? Can a conventional database be the better fit?
Answer check: No; no; no; yes; yes. Identify the actual power or requirement behind each answer.
Continue through the beginner collection
- Simplest Explanation
- A Record’s Journey
- Digital Fingerprints
- Keys and Digital Signatures
- Nodes and Shared Copies
- Consensus and Agreement
- Smart Contracts and Rules
Technical companion · Structured technical learning guide
Primary references and scope
Reference pages checked 13 October 2026. The classroom models explain roles and evidence; they do not implement a secure network, define a universal waiting period or prescribe a production custody or measurement system.
- Hyperledger Fabric: Introduction — a primary, platform-specific reference. The actual system’s documentation defines its guarantees, roles and implementation.
- NIST IR 8202: Blockchain Technology Overview — published October 2018; broader shared-ledger terminology and mechanisms.
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. Start with the Simplest Explanation, then follow the guides in order or choose the topic you need. Continue into the technical learning guide for deeper study.