Types of Blockchain — Public, Private, and Consortium
1.5 — Types: Public, Private, and Consortium
Recall first. From §1.1, a blockchain replaces a trusted intermediary with a decentralized network + consensus. Who gets to join that network and write blocks is a separate decision. List two extremes (anyone vs. one company) before reading.
Reference-book anchor
Primary reference: Blockchain Technology, Chapter 2, §2.3 — converted Markdown lines 1304–1404.1
The book’s anchor separates accessibility (public/private) from permissions (permissionless/permissioned). The comparison below keeps those axes distinct and extends the book’s categories with a retrieval-friendly read/submit/validate/govern matrix.
The real axis: permissioned vs. permissionless
“Types of blockchain” is really about who is allowed to participate. The syllabus names three: Public, Private, Consortium. Map them onto one axis:
Permissionless ◄────────────────────────────────────► Permissioned
Public Consortium Private
(open to all) (group of orgs) (single org controls)
- Permissionless = membership is generally open under protocol rules; read, submit, and validation rights are often open, but those rights are not identical by definition.
- Permissioned = membership and roles are controlled; participants may be known and admitted, with read, submit, validate/order, and governance rights assigned separately.
The three types
| Type | Who controls it | Who can join | Read access | Who may submit | Who may validate/order |
|---|---|---|---|---|---|
| Public | No single operator; governance is distributed across participants | Anyone | Usually open | Usually anyone may submit a valid transaction | Participants selected by the protocol (e.g. PoW/PoS); not every reader is a validator |
| Private | A single organization | Invitation only | Often restricted | Authorized users | Central administrator or selected nodes |
| Consortium | A group of organizations | Vetted members | Often restricted | Authorized member users | Selected member organizations under the consortium policy |
Public
Fully open. Trust comes mainly from the consensus protocol and economic incentives, not from knowing every validator. Public chains usually offer broad verifiability and participation, but often have lower throughput or higher latency than a permissioned deployment because they must operate with open membership and adversarial conditions.2
Private
Run by one entity (a company, a government dept). The org decides who participates and can, in principle, revert or censor transactions. You trade decentralization for speed, privacy, and control. The “blockchain” here is mostly an internal audit/tamper-evidence tool, not a trustless one.3
Consortium (a.k.a. federated / permissioned)
A middle ground: a set of known organizations jointly operate the network. A member cannot unilaterally rewrite history provided the governance and consensus policy require agreement from the other members. Membership is vetted, which suits industries where competitors must share a record but trust no single one of them (e.g. banks clearing payments, supply-chain partners). Hyperledger Fabric (Module V) is the canonical study object.23
In Fabric, for example, an ordering service places endorsed transactions into blocks and peers validate and commit them; the permissioned identity model and ordering policy are part of the trust design, not optional decorations.4
Control is more than one question
When classifying a network, ask four separate questions:
- Who may read the ledger?
- Who may submit a transaction?
- Who may validate or order transactions?
- Who may change the rules or membership?
“Public,” “private,” and “consortium” are useful shorthand, not a complete permission matrix. A real system can mix these permissions: for example, a consortium may allow public proof of selected records while restricting transaction details to its members, or allow submission to more participants than it allows to validate or govern.
How the type changes the consensus choice
This is the bridge to §1.6. The type constrains which consensus protocol is sensible, but does not uniquely determine it:
- Public → often permissionless protocols such as Proof-of-Work or Proof-of-Stake (Sybil resistance via cost or stake).
- Private / Consortium → often permissioned protocols such as PBFT, Raft, or IBFT, where known validators replace open mining; other designs are possible.
A single company’s private chain generally has no reason to run energy-hungry PoW; its known membership permits other consensus choices. That mismatch is exactly why Module V covers PBFT/Raft while Module II covers PoW/PoS.
Beginner reframe. “Public/permissionless” answers “who do we trust?” with “nobody — the math.” “Private/permissioned” answers it with “these known, vetted parties.” Same data structure, different trust model.
Worked example — pick the type
Match each scenario to Public / Private / Consortium:
- A charity wants a fully transparent, globally auditable donation ledger anyone can verify.
- Three competing hospitals must share patient-consent records without any one hospital controlling the system.
- A factory tracks its own machinery maintenance log internally.
Answer: (1) Public — openness and verifiability are the point. (2) Consortium — multiple mutually-distrusting orgs, none to dominate. (3) Private — one organization, internal use, wants control + speed.
Exercise
A startup says: “We’ll put our app’s user data on a blockchain so it’s secure.” They plan a private chain they operate. What property that people associate with “blockchain” (from §1.1) does this not actually give them, and why?
Answer
It does not give trustlessness / resistance to a single authority. Because they operate the private chain, they can, in principle, alter or censor records. The cryptographic tamper-evidence remains, but the “no trusted intermediary” guarantee is lost — they are the intermediary. The security benefit is mostly internal auditability, not decentralized trust.
Exam lens
Comparison answer: compare the three types under control, membership, read access, validation, trust assumption, performance, and a suitable use case. Always state that permissionless/permissioned is the underlying axis.
Decision rule:
- Use public when open participation and public verifiability matter more than throughput and confidentiality.
- Use private when one organization is the legitimate authority and wants controlled, auditable coordination.
- Use consortium when several organizations need a shared record but do not want one organization to control it.
Common traps:
- Permissioned does not automatically mean secure, decentralized, or private.
- Public does not mean every piece of application data must be exposed in plaintext.
- A consortium still needs governance: membership, voting/quorum, upgrades, dispute handling, and access policy.
Rapid revision
- Can I separate read, submit, validate, and govern permissions?
- Can I map public/private/consortium to permissionless/permissioned?
- Can I justify a network choice from a scenario rather than memorizing examples?
- Can I explain exactly what trust is removed and what trust remains?
Key takeaways
- The spectrum is permissionless ↔ permissioned.
- Public = open, decentralized, transparent (Bitcoin/Ethereum).
- Private = one org, fast, controllable, not trustless.
- Consortium = multiple organizations share control under an agreed governance and quorum policy (Hyperledger Fabric is one example).
- Type strongly suggests a consensus family: public networks often use PoW/PoS; private/consortium networks can use PBFT/Raft or other permissioned protocols.
Sources
Footnotes
-
Blockchain Technology, S. Chandramouli, Asha A. George, Abhillash K. A., Meena Karthikeyan. Universities Press. E-edition first published 2020; copyright 2021. ↩
-
Bashir, I. (2019). Mastering Blockchain, 3rd Ed. Packt — Ch. 1 classifies public/private/consortium and their trade-offs. ↩ ↩2
-
Antonopoulos, A. M., & Wood, G. Mastering Ethereum. O’Reilly — contrasts public mainnet with permissioned/consortium deployments. ↩ ↩2
-
Hyperledger Fabric documentation, “What is ordering?” https://hyperledger-fabric.readthedocs.io/en/latest/orderer/ordering_service.html — permissioned identity, ordering, validation, and finality. ↩