中文版 · Blockchain learning guide · Previous: Blocks, Transactions and State
Blockchain learning · Article BC009
Public, private and consortium are useful starting labels, but they do not fully describe a blockchain. To understand a system, separate who can read information, submit requests, validate or order updates, and change the rules.
A network can publish records widely while restricting who operates its decision-making components. A consortium can share control among institutions without revealing every document to every member. An application on a public chain can still have powerful administrators.
This guide turns those distinctions into a practical classification method. The goal is to describe actual permissions rather than assume that one label guarantees openness, privacy or decentralisation.
Choose your reading route
In this guide
- 1. Begin with four separate permission questions
- 2. What the broad labels usually mean
- 3. Public does not mean every action is unrestricted
- 4. Private does not automatically mean confidential
- 5. A consortium is an agreement about institutions, not just servers
- 6. Worked example: an environmental observation network
- 7. Compare three variants of the same project
- 8. Governance remains important in open networks
- 9. Fault tolerance is not determined by the category name
- 10. A practical classification card
- 11. Questions that expose misleading labels
- Classification exercise
- Frequently asked questions
- Sources and scope
- Learn the categories: start with the four permission questions and the three broad labels.
- Assess a consortium: focus on membership, governance and the environmental-record example.
- Understand privacy: read the difference between public verification and public disclosure.
- Test your understanding: classify the short scenarios before checking the answers.
Back to contents · Next section
1. Begin with four separate permission questions
Who can read?
A system may expose all records, selected fields, proofs about records or only a public summary. Reading through one website may also differ from obtaining the underlying data needed for independent verification.
Ask what the reader actually receives. “Public dashboard” is not necessarily equivalent to “publicly verifiable complete history.” The dashboard may omit details or depend on a service’s interpretation.
Who can submit?
Submitting a request is different from making an accepted change. A network may let anyone send a protocol-valid transaction while a particular application accepts actions only from approved accounts.
Identify both the network-level entry conditions and the application’s permissions. An open platform can host an application with restricted roles.
Who can validate or order?
These roles concern checking proposed changes and participating in how the accepted sequence is established. The network may use open protocol-based participation or a defined group of admitted organisations.
Do not assume that every reader is a validator, or that every person allowed to submit a form operates a consensus component.
Who can change the rules?
Look for software upgrades, membership changes, administrator keys, pause powers and recovery procedures. These permissions may sit outside the interface ordinary users see.
A system with widely readable records can still concentrate these powers. Conversely, several institutions can share important rule changes even if access to business data remains limited.
Back to contents · Next section
2. What the broad labels usually mean
Public blockchain commonly describes a network whose ledger or participation is broadly open. Because usage varies, follow the label with the specific reading, submission and consensus arrangements.
Private blockchain commonly describes a restricted network under the control of one organisation or a limited administrative setting. It may use multiple machines while keeping governance concentrated.
Consortium blockchain commonly describes a system governed or operated by a group of organisations. It usually involves permissioned participation in important roles, but the exact division of control must be checked.
Permissionless refers to participation without a central membership approval for the specified protocol role, subject to protocol conditions. Permissioned refers to roles granted through a membership or authorisation arrangement.
These terms overlap rather than forming one perfectly exclusive classification. A publicly readable permissioned ledger is possible. So is a consortium with private data shared only among selected members.
NIST’s Blockchain Technology Overview, published October 2018, is a useful foundation for permission models. The safest description still states concrete rights instead of relying only on a category name.
Back to contents · Next section
3. Public does not mean every action is unrestricted
Consider a hypothetical document registry deployed on an openly accessible chain. Anyone can inspect its public records, but only a recognised issuer can register a certificate.
The underlying network’s participation rules and the registry’s application permissions are different layers. A person may be able to submit a transaction that calls the application, yet the application can reject the requested action because the caller lacks the required role.
The same distinction applies to administration. A public contract may contain an upgrade mechanism controlled by a specified account or group. Public visibility makes that power potentially inspectable; it does not remove it.
A useful description would say: records are publicly visible, issuance is restricted to approved issuers, and upgrades require a named approval arrangement. “It is public, so nobody controls it” would hide the most important facts.
Also avoid treating permissionless as a legal conclusion. It is a statement about protocol membership, not a declaration that every activity is legally permitted in every jurisdiction.
Back to contents · Next section
4. Private does not automatically mean confidential
A restricted network can still reveal information to more participants than the application requires. If every admitted operator receives a full document, preventing outsiders from joining does not keep that document private from members.
Confidentiality needs its own design. Which fields are shared? Which organisations receive them? Can administrators or infrastructure providers access them? How are keys, backups and exports handled?
Encrypting data raises additional questions rather than ending the analysis. Who has the decryption keys? Can access be revoked effectively for future information? What metadata remains visible? A label cannot answer these details.
Hyperledger Fabric’s private-data documentation describes one way selected organisations can share private data while hashes are recorded for verification by other channel participants. The actual policies and data flows determine what is disclosed. Fabric private data.
The general lesson is to specify the audience of each piece of information. “Private chain” is too broad to serve as a complete privacy explanation.
Back to contents · Next section
5. A consortium is an agreement about institutions, not just servers
Imagine five organisations shown as five nodes on a diagram. If one vendor controls every administrator account and can replace all software without their approval, the picture may exaggerate shared authority.
A meaningful consortium arrangement should explain what each institution controls and which decisions require joint approval. Admission of a new organisation, removal of an existing member, application upgrades and emergency action may follow different policies.
The arrangement also needs continuity. What happens if one member leaves, stops paying for infrastructure or loses its signing authority? Can remaining members proceed under the agreed rules? Can the departing member retain the records it is entitled to keep?
Membership is therefore more than a list of names. It connects identity to roles and enforceable permissions. Fabric’s Membership Service Provider documentation illustrates that connection between recognised identities and authorised roles. Fabric membership.
An institution can be accountable in the real world and still make mistakes in software operation. Consortium design should address both organisational responsibility and the protocol’s technical fault model.
Back to contents · Next section
6. Worked example: an environmental observation network
Suppose three research institutes want to maintain a common record of river-monitoring observations. Each operates sensors, and the public should be able to inspect published measurements and later corrections. This is a hypothetical learning example, not a claim about an existing project.
The first requirement is public access to selected observations. The second is that only recognised institutes can submit official records. The third is that no single institute can silently change the admission policy. None of those requirements implies that every raw operational document must be public.
A possible permission map is: the public reads published observations; institute accounts submit measurements; admitted operators perform specified network roles; major membership changes require joint approval. The design must still specify the actual agreement mechanism and fault assumptions.
Notice what remains unsolved. A sensor can be miscalibrated. An institute can submit a misleading interpretation. A ledger can preserve the authorised submission without independently proving that the measurement reflects the river accurately.
The category might be described as a publicly readable consortium ledger. That phrase is more useful than choosing either “public” or “private” and pretending the other dimension does not exist.
What should stay separate?
Sensor maintenance records might contain operational details intended only for the institutes. A public summary may link to evidence of calibration without disclosing every internal document.
The policy should explain exactly which evidence is sufficient for public scrutiny. Hiding all supporting information behind a public number may weaken accountability. Publishing everything may disclose unnecessary information. The design must justify the boundary rather than assume maximum exposure is always best.
What happens when a measurement is corrected?
The system can record a correction and its reason while preserving the earlier published observation. The correction authority should be explicit: can the original institute act alone, or is review required?
This is a governance question as well as a data question. A well-designed record format cannot substitute for an agreed responsibility to investigate mistakes.
Back to contents · Next section
7. Compare three variants of the same project
Variant A: one institute runs the service. The other institutes submit signed observations, but the operator controls the official database and access interface. This can be a sensible arrangement if that authority is accepted. It should not be marketed as joint control merely because several organisations contribute data.
Variant B: the institutes share a permissioned ledger. Roles and changes are governed by agreed policies. This may reduce unilateral control over specified actions, but introduces membership, operator coordination and recovery responsibilities.
Variant C: selected commitments are placed on a public chain. The full observation service remains elsewhere. Public commitments can support particular integrity checks, but do not automatically make source data available or give the public control of the application.
These variants are not a ranking. The best fit depends on the required evidence, participation, privacy and operating burden. Each can also be implemented badly.
The exercise demonstrates why a system can combine public and restricted components. The useful analysis follows the record and its permissions rather than demanding one label for every layer.
Back to contents · Next section
8. Governance remains important in open networks
An open network still needs ways to develop software, discuss protocol changes and coordinate adoption. Openness does not mean the absence of governance.
Ethereum describes its protocol governance as an offchain process involving several stakeholder groups. That is different from assuming that every protocol decision is made by an onchain token vote. Application governance can follow still other arrangements. Ethereum governance.
For a reader, this means the governance question should be asked at the correct layer. Who changes the base protocol? Who upgrades the application? Who controls the interface? Who can alter membership in a specific service?
A claim about one layer cannot automatically be transferred to another. An application on an open network may have a single administrator. A jointly governed application may depend on one website for ordinary access.
Clear classification describes these combinations without declaring that one word settles every concentration of power.
Back to contents · Next section
9. Fault tolerance is not determined by the category name
A permissioned network can use different consensus and ordering designs. A public network can have different participation resources and finality rules. The labels alone do not specify how many failures can be tolerated or what happens during a partition.
For example, a design that tolerates stopped servers should not be assumed to tolerate arbitrary conflicting messages. A consortium’s known identities may support accountability, but they do not make dishonest or faulty behaviour technically impossible.
Similarly, broad participation does not ensure that every operator is independent or that a network has no concentrated infrastructure dependencies.
Ask for the actual failure model, decision rules and recovery procedure. When a performance claim is made, also ask what confirmation or finality condition the measurement uses.
This avoids comparing a fast acknowledgement in one system with a stronger settled outcome in another, or assuming that restricted membership automatically makes a system safer.
Back to contents · Next section
10. A practical classification card
For any proposed system, complete five sentences.
- Readers can obtain… Specify the data, proof or summary and any access restriction.
- Submitters may request… Identify recognised roles and application-level permissions.
- The accepted sequence is maintained by… Name the relevant operators or participation mechanism.
- Rules and membership can change when… Describe the real approval and execution powers.
- Information is withheld from… Identify the confidentiality boundary and the method supporting it.
For the river example: readers obtain published observations and corrections; institute accounts submit official measurements; admitted operators maintain the sequence; membership changes require the agreed joint process; internal maintenance details are shared only under a defined policy.
This description remains useful even if different people disagree about whether to call the system public, private or consortium. The permissions are explicit enough to evaluate.
Back to contents · Next section
11. Questions that expose misleading labels
If a vendor says “public,” ask whether that refers to a website, the underlying ledger, transaction submission or consensus participation.
If it says “private,” ask private from whom. Outsiders, other members, the vendor and administrators are different audiences.
If it says “consortium,” ask which decisions a single organisation cannot make alone and how that restriction is enforced.
If it says “permissionless,” ask which role does not require membership approval and what protocol conditions still apply.
If it says “decentralised,” ask about operations, software, governance, access and data sources separately.
A precise answer may reveal a sensible hybrid. It may also reveal a conventional managed service with blockchain terminology attached. Either way, clarification is more useful than arguing from labels alone.
Back to contents · Next section
Classification exercise
Scenario 1: Everyone can read the ledger, but only five admitted organisations can operate its ordering service. Is public visibility enough to call every role permissionless?
Answer: No. The system has public reading and permissioned ordering. Describe both dimensions.
Scenario 2: A contract runs on an open chain, but one administrator can upgrade its application logic. Does the open chain remove that administrator’s power?
Answer: No. Base-network participation and application control are different layers. Inspect the upgrade authority directly.
Scenario 3: A consortium allows every member to download every business document. Does the word private guarantee confidentiality between members?
Answer: No. Restricting outsiders does not restrict admitted members. Data-sharing rules need a separate design.
Scenario 4: One company operates twenty nodes. Does that alone establish a consortium?
Answer: No. A consortium concerns a group of organisations and their governance or operational arrangement, not simply a large node count.
Final task: Write a five-sentence classification card for a fictional school-library inventory network without using the words public, private or decentralised. Focus on roles and permissions; do not include real student information.
Back to contents · Next section
Frequently asked questions
Is a consortium always permissioned?
It commonly uses permissioned roles, but the term alone does not specify every layer. A consortium might operate an application that anchors information to an open network. Identify the actual permissions.
Can a public network carry confidential applications?
Applications can use techniques that limit disclosure, but confidentiality is not automatic. Analyse public inputs, metadata, keys and the exact mechanism rather than assuming the public-chain label answers the question.
Is a private chain always pointless?
No universal answer follows from the label. Ask what verification or coordination requirement it meets and compare it with a well-designed database or signed log. A claimed benefit needs a concrete explanation.
Does permissionless mean anyone can legally use any service?
No. It describes a protocol’s membership arrangement. Applicable rules and service availability are separate questions that depend on the activity and jurisdiction.
Back to contents · Next section
Sources and scope
The foundational reference was researched on 12 October 2026, Asia/Singapore. The following primary documentation supports the conceptual distinctions; living implementation guidance was checked during preparation. The environmental project and classification card are educational examples.
- NIST IR 8202: Blockchain Technology Overview, October 2018: foundational permission models and terminology.
- Hyperledger Fabric: Introduction: permissioned architecture.
- Hyperledger Fabric: Membership Service Provider: recognised identities and roles.
- Hyperledger Fabric: Private data: selective sharing within a permissioned setting.
- Ethereum governance: protocol governance distinct from application-level arrangements.
The best classification is the one that makes powers and boundaries visible. A label is the beginning of that explanation, not its conclusion.