§ 1.5Module 1

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)

The three types

TypeWho controls itWho can joinRead accessWho may submitWho may validate/order
PublicNo single operator; governance is distributed across participantsAnyoneUsually openUsually anyone may submit a valid transactionParticipants selected by the protocol (e.g. PoW/PoS); not every reader is a validator
PrivateA single organizationInvitation onlyOften restrictedAuthorized usersCentral administrator or selected nodes
ConsortiumA group of organizationsVetted membersOften restrictedAuthorized member usersSelected 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:

  1. Who may read the ledger?
  2. Who may submit a transaction?
  3. Who may validate or order transactions?
  4. 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:

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:

  1. A charity wants a fully transparent, globally auditable donation ledger anyone can verify.
  2. Three competing hospitals must share patient-consent records without any one hospital controlling the system.
  3. 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:

Common traps:

Rapid revision

Key takeaways

Sources

Footnotes

  1. Blockchain Technology, S. Chandramouli, Asha A. George, Abhillash K. A., Meena Karthikeyan. Universities Press. E-edition first published 2020; copyright 2021.

  2. Bashir, I. (2019). Mastering Blockchain, 3rd Ed. Packt — Ch. 1 classifies public/private/consortium and their trade-offs. 2

  3. Antonopoulos, A. M., & Wood, G. Mastering Ethereum. O’Reilly — contrasts public mainnet with permissioned/consortium deployments. 2

  4. Hyperledger Fabric documentation, “What is ordering?” https://hyperledger-fabric.readthedocs.io/en/latest/orderer/ordering_service.html — permissioned identity, ordering, validation, and finality.