Public, Private and Consortium Networks

Introduction

Blockchain networks are not a single technological category. They differ in who may join, who may submit transactions, who may validate them, who may read recorded data, and who controls protocol changes. These differences determine whether a network is suitable for public digital money, inter-organisational supply chains, regulated finance, internal record keeping, or community governance.

A useful starting distinction is between permissionless and permissioned networks. In a permissionless network, participation is generally open: a user can create an address, submit transactions, and often help validate blocks without approval from a central authority. In a permissioned network, participation is governed by an admission process. Known organisations or individuals receive identities and defined rights before they can transact, validate, or access information.

The distinction is architectural rather than merely commercial. A network may use distributed consensus in both cases, but the assumptions about identity, trust, confidentiality, governance, and performance are different. Ethereum illustrates a widely used public network. Hyperledger Fabric illustrates a modular permissioned platform. Corda illustrates a permissioned, participant-focused distributed ledger whose design differs significantly from conventional blockchains.

Learning Objectives

After completing this chapter, a learner should be able to:

1. Distinguish public, private, consortium, permissionless, and permissioned networks.
2. Explain identity models, admission procedures, and access-control mechanisms.
3. Compare consensus and data-sharing approaches in Ethereum, Hyperledger Fabric, and Corda.
4. Select an appropriate network architecture for a practical business or public-service problem.
5. Evaluate governance, privacy, regulatory, ethical, and operational implications.

1. Network Classification

Public and private networks

A public network is open to broad participation and normally allows anyone to inspect at least the ledger’s publicly exposed data. Bitcoin and Ethereum are prominent examples. Public networks maximise openness and resistance to control by a single organisation, but they may expose transaction metadata and face scalability, privacy, and governance challenges.

A private network is operated by one organisation or by a tightly controlled administrative domain. Participation is restricted, and the operator normally determines membership, software configuration, and governance. Private networks may provide high performance and confidentiality, but they do not automatically provide the same decentralised trust properties as public networks. If one organisation can rewrite history or exclude participants unilaterally, users must trust that organisation.

A consortium network, also called a federated network, is governed by several organisations. Banks, logistics companies, hospitals, universities, or government agencies may jointly operate nodes. A consortium distributes operational authority across members while retaining controlled membership. Its decentralisation is therefore organisational and contractual as well as technical.

Permissionless and permissioned participation

The terms describe access rights rather than ownership alone. A permissionless network normally permits:

• open registration of user-controlled cryptographic accounts;
• broad ability to submit transactions;
• validation based on protocol rules rather than an organisational invitation; and
• public or pseudonymous participation.

A permissioned network normally requires:

• an approved digital identity;
• a membership authority or certificate issuer;
• role-based rights for transactions and data;
• identified validator organisations; and
• formal procedures for suspension, revocation, dispute resolution, and software upgrades.

These categories exist on a spectrum. For example, a consortium may allow all approved members to read shared records but restrict validation to a smaller group. A public network may use permissioned applications or private execution layers even though its settlement layer is open.

A comparison framework

No category is universally superior. The appropriate choice depends on the required level of openness, the sensitivity of data, the number and independence of participants, legal duties, expected transaction volume, and the consequences of validator failure.

2. Identity and Access Models

Addresses are not complete identities

In a public network, a cryptographic address usually represents control of a private key. It proves the ability to authorise a transaction, but it may not reveal the legal identity of the controller. This is more accurately described as pseudonymity than anonymity: activity can often be linked through transaction analysis, exchange records, network data, or voluntary disclosure.

Permissioned networks normally bind a participant to a recognised identity. A membership service may issue a digital certificate containing an organisation, role, or public key. The corresponding private key signs transactions. Certificate revocation lists, hardware security modules, multi-signature controls, and identity audits can reduce the risk of unauthorised use.

Identity management introduces responsibilities absent or less visible in open networks. An administrator must determine who qualifies for membership, how credentials are issued, how compromised keys are replaced, and how former employees or organisations are removed. Poor key governance can undermine an otherwise well-designed ledger.

Authentication, authorisation, and accountability

These concepts should be separated:

• Authentication asks, “Who or what is presenting a credential?”
• Authorisation asks, “What is this identity allowed to do?”
• Accountability links an action to a responsible identity and preserves evidence for review.
• Confidentiality restricts information to authorised parties.
• Integrity protects information from unauthorised alteration.

A digital signature supports authentication of a transaction request and integrity of its contents. It does not by itself prove that the signer is legally entitled to act. That requires an identity system, organisational policy, and often legal agreements.

Access-control models

Common models include:

1. Role-based access control (RBAC): permissions are assigned to roles such as auditor, supplier, regulator, or validator.
2. Attribute-based access control (ABAC): decisions depend on attributes such as jurisdiction, transaction value, time, product type, or regulatory status.
3. Channel or subnet access: a group receives a logically separated transaction and data space.
4. Private data collections: selected members share data while the broader network stores evidence that a transaction or data hash exists.
5. Application-level controls: smart contracts enforce conditions such as approval thresholds, segregation of duties, or permitted counterparties.

Access controls should be designed according to least privilege: each participant receives only the capabilities required for its role. Administrative access must also be controlled; otherwise, the system simply relocates excessive power from database administrators to blockchain administrators.

3. Consensus, Finality, and Governance

Consensus is the process by which distributed participants agree on transaction ordering and ledger state. Its security assumptions differ by network type.

Public networks must assume that many participants are unknown and that some may act maliciously. They therefore use mechanisms such as proof of work or proof of stake, together with economic incentives and public verification. Finality may be probabilistic or economically assured, depending on the protocol.

Permissioned networks know validator identities and can use voting-based Byzantine fault-tolerant protocols, crash-fault-tolerant ordering, or other tailored methods. If a protocol tolerates up to f Byzantine validator faults, a common Byzantine fault-tolerant design requires at least 3f + 1 validators under its stated assumptions. This relationship is not a universal rule for every consensus protocol; it applies to standard asynchronous or partially synchronous Byzantine settings where the protocol’s safety and liveness assumptions require that quorum structure. For example, with f = 1, at least 4 validators are commonly required. A deployment must still consider network timing, collusion, identity compromise, and governance.

A permissioned network may achieve faster confirmation because it does not need to defend against unlimited anonymous participants. However, speed is not equivalent to trustlessness. Members may collude, fail to operate nodes, or use contractual power to change rules.

Governance includes:

• admission and removal of members;
• validator selection;
• protocol upgrades;
• dispute and transaction-reversal procedures;
• data retention and deletion policies;
• incident response;
• liability allocation; and
• audit and regulatory reporting.

Public networks often govern through open-source development, public discussion, social consensus, and economic coordination. Consortium networks require explicit governance documents because technical control is shared among identifiable legal entities.

4. Ethereum as a Public Permissionless Platform

Ethereum is a public blockchain platform supporting accounts, transactions, smart contracts, and decentralised applications. Users generally interact through cryptographic accounts. Smart contracts execute on the Ethereum Virtual Machine (EVM), subject to protocol rules and transaction fees commonly called gas.

Ethereum’s openness enables anyone to deploy a contract, build a wallet, or operate infrastructure subject to the network’s rules. This supports innovation and composability: one application can interact with another without a bilateral integration agreement. The same openness also creates risks. Contracts may contain exploitable defects, users may interact pseudonymously, and transaction data is broadly observable.

Ethereum uses proof of stake. Validators lock or otherwise commit stake under protocol rules and participate in proposing and attesting to blocks. Misconduct can lead to penalties, while honest participation supports chain security. The exact economic and finality mechanisms are protocol-specific and can change through network upgrades; learners should therefore consult current technical documentation when implementing systems.

Ethereum is appropriate when:

• open participation is a central requirement;
• public verifiability and composability are valuable;
• tokenised assets or public settlement are needed; and
• the application can manage public-data and key-management risks.

It is less appropriate when commercial confidentiality requires that transaction details be hidden from nearly all network participants, or when a regulator requires a clearly accountable validator group.

5. Hyperledger Fabric as a Permissioned Platform

Hyperledger Fabric is an enterprise distributed-ledger framework designed for networks of known organisations. It uses a modular architecture rather than requiring every peer to execute every transaction in the same way.

Important Fabric concepts include:

• Membership Service Provider (MSP): defines how identities are recognised and associated with organisations.
• Peers: maintain ledgers and may endorse transactions or execute chaincode.
• Ordering service: establishes transaction order and creates blocks; it does not necessarily execute business logic.
• Channels: separate communication and ledger contexts for defined member groups.
• Chaincode: business logic that runs according to the network’s endorsement and validation rules.
• Endorsement policies: specify which organisations must approve a transaction proposal.
• Private data collections: allow selected members to hold sensitive data while other participants receive related ledger evidence or hashes.

A typical transaction flow is proposal, simulation and endorsement, ordering, block distribution, and validation/commitment. Separating execution from ordering can improve modularity and make organisational policies explicit. It also means that application designers must understand endorsement policies, identity configuration, lifecycle management, and the difference between an endorsed proposal and a committed transaction.

Fabric is suitable for supply chains, trade documentation, healthcare collaboration, and financial workflows where organisations are known and data must be selectively shared. Its confidentiality is not automatic: poorly designed channels, endorsement policies, peer configurations, or application logs can still disclose sensitive information.

6. Corda and Participant-Focused Distributed Ledgers

Corda is a permissioned distributed-ledger platform designed particularly for agreements and transactions between identifiable parties. It differs from the conventional model in which every node receives every transaction. Corda generally shares transaction data only with parties that need it, while a notary provides uniqueness or finality services according to the configured notary design.

Corda records states representing facts or contractual positions, such as ownership of an asset. Transactions consume input states and create output states. Contract code specifies validity rules, while flows coordinate communication and signatures among participants. A notary checks that an input state has not already been consumed, helping prevent double spending.

This model can provide strong privacy because unrelated participants do not need to receive all business transactions. It also requires careful attention to identity, legal agreements, notary trust, contract upgrades, and the distinction between transaction validity and legal enforceability.

Corda is particularly relevant to regulated financial services, insurance, syndicated lending, and other bilateral or multilateral agreements. It is not best understood simply as a smaller public blockchain. Its data-distribution model, transaction lifecycle, and trust assumptions are different.

7. Platform Comparison

The comparison should not be reduced to performance claims. Throughput depends on transaction size, workload, hardware, network conditions, state contention, consensus configuration, and application design. A benchmark from one deployment cannot establish a universal ranking.

8. Selecting an Architecture

A structured decision process is more reliable than choosing a platform by popularity.

Step 1: Identify participants

Are participants unknown and open-ended, or can a trusted membership list be maintained? If participants are known, permissioned architecture becomes feasible, but the reason for using a shared ledger must still be demonstrated.

Step 2: Classify information

Separate public, partner-confidential, personal, commercially sensitive, and legally restricted data. Do not place personal data on an immutable ledger merely because the technology permits it. Store sensitive content off-chain where appropriate and record only a verifiable reference, while recognising that hashes and metadata may still be personal or confidential information.

Step 3: Define trust and failure assumptions

Ask which parties may be dishonest, unavailable, compromised, or colluding. Identify who can validate, who can halt the network, and who can approve software changes.

Step 4: Determine governance and legal control

Establish membership rules, liability, audit rights, dispute handling, data retention, jurisdiction, and regulatory reporting before deployment.

Step 5: Match the transaction model

A public asset marketplace may benefit from Ethereum’s open settlement. A multi-organisation workflow with selective visibility may fit Fabric. A bilateral financial obligation requiring private exchange may fit Corda. A conventional replicated database may be better if one organisation is already trusted and no independent parties require a shared source of truth.

A practical decision matrix

9. Applied Case: Consortium Pharmaceutical Traceability

The following is an illustrative case, not a report of a specific company.

Background

A pharmaceutical supply chain includes manufacturers, wholesalers, pharmacies, logistics providers, and a regulator. Participants need to verify product provenance and detect falsified or diverted medicines. However, invoices, negotiated prices, patient-related information, and commercial volumes must not be visible to every participant.

Problem

A central database operated by one participant creates concerns about control and data alteration. Independent databases create reconciliation delays. A fully public blockchain would expose commercially sensitive transaction patterns and might conflict with privacy obligations.

Analysis

The participants are identifiable organisations with contractual relationships. They require shared evidence, but not universal visibility. The regulator needs audit access, while manufacturers and distributors need different permissions. The network therefore requires identity certificates, role-based access, selective data sharing, endorsement rules, and procedures for suspending compromised organisations.

Approach

A consortium permissioned design based on Fabric could be used. Each major organisation operates one or more peers. An MSP issues certificates. Chaincode validates product identifiers, authorised transfers, expiry dates, and recall status. Endorsement policies require appropriate organisations to approve a transfer. Channels or private data collections separate sensitive commercial records from information needed for provenance. A regulator receives defined read and audit rights.

The design should not store unnecessary patient data on-chain. A product event can contain a time, product identifier, event type, and references to controlled off-chain documents. Cryptographic hashes can help detect alteration of those documents, but access controls and retention policies remain necessary.

Outcome

The consortium obtains a shared, tamper-evident event history and reduces reconciliation between members. It does not eliminate disputes: members still need procedures for correcting erroneous entries, handling a compromised key, resolving a physical shipment discrepancy, and deciding which organisation bears liability.

Learning points

1. Permissioned membership is valuable when legal identity and accountability matter.
2. Privacy requires data-minimisation and selective distribution, not merely a private label.
3. Endorsement policies express organisational responsibility but do not replace contracts.
4. The best design may combine on-chain evidence, off-chain records, identity services, and conventional databases.
5. Governance and operational procedures are as important as ledger software.

10. Challenges, Ethics, and Regulation

Privacy and immutability

An immutable record can conflict with correction, deletion, confidentiality, or data-minimisation obligations. Encryption does not guarantee permanent privacy: keys may be lost or future techniques may weaken current protection. Designers should minimise personal data, use appropriate retention controls, document access, and obtain legal advice for the relevant jurisdiction.

Centralisation disguised as decentralisation

A consortium may have ten nodes but only two meaningful decision makers. A private network may use distributed databases while retaining unilateral administrative control. Architecture diagrams should therefore identify actual control over membership, keys, validators, upgrades, and data.

Key loss and insider abuse

A lost private key can prevent legitimate action; a stolen key can authorise fraudulent action. Use secure key storage, multi-person approval for high-risk operations, rotation and revocation procedures, incident drills, and separation of duties. Administrator accounts require especially strong controls.

Smart-contract and operational risk

Code may enforce rules exactly as written but still implement the wrong business interpretation. Independent review, testing, formal specifications where justified, staged deployment, monitoring, and emergency procedures are essential. An upgrade mechanism also creates governance risk because whoever controls upgrades may change economic or legal outcomes.

Legal and regulatory questions

Important questions include whether a digital asset is regulated, who is the data controller, where records are legally located, whether electronic signatures are recognised, how anti-money-laundering duties are fulfilled, and which entity is responsible for outages or erroneous transactions. Technical finality does not necessarily equal legal finality.

11. Best Practices for Design and Deployment

1. Begin with a documented inter-organisational problem, not with a preferred platform.
2. Compare blockchain with a shared database, replicated database, or API-based solution.
3. Define identities, roles, revocation, and key recovery before writing smart contracts.
4. Apply least privilege and separate transaction submission, endorsement, administration, and audit roles.
5. Minimise on-chain personal and confidential data.
6. Make governance explicit: membership, upgrades, incident response, disputes, and costs.
7. Test failure, collusion, network partition, key compromise, and unavailable validators.
8. Measure end-to-end performance rather than relying on vendor throughput claims.
9. Maintain independent audit logs and monitor unusual transactions.
10. Plan interoperability, migration, archival, and eventual retirement from the beginning.

Contemporary Developments

Current enterprise designs increasingly combine public and permissioned components. A permissioned network may periodically anchor a cryptographic commitment to a public chain to obtain an externally verifiable timestamp, while keeping business data private. Zero-knowledge techniques may allow a party to prove a condition without revealing all underlying data, although implementation and governance remain complex. Decentralised identity standards, confidential-computing approaches, tokenised assets, and cross-network interoperability are also developing.

These developments do not remove fundamental trade-offs. A privacy technique may increase computational cost; interoperability may expand the attack surface; tokenisation may create regulatory obligations; and a public anchor proves that a commitment existed, not that the underlying business event was truthful. Sound engineering continues to require clear trust assumptions and accountable governance.

Chapter Summary

Public, private, and consortium networks differ chiefly in membership, identity, validation, data visibility, governance, and trust assumptions. Permissionless networks such as Ethereum support open participation, public verification, and composable applications, but provide limited confidentiality by default and expose users to public-network and smart-contract risks. Permissioned networks restrict participation through recognised identities and organisational policies.

Hyperledger Fabric provides modular permissioned components including membership services, peers, ordering, channels, chaincode, endorsement policies, and private data collections. Corda uses a participant-focused model in which relevant parties share transaction information and notaries provide uniqueness or finality services. These platforms should be compared by trust model and transaction requirements rather than by simplistic performance claims.

Effective selection begins with participants, data sensitivity, failure assumptions, governance, legal requirements, and the possibility that a conventional database may be more appropriate. Strong identity management, least-privilege access, data minimisation, key protection, testing, and explicit consortium governance are essential for professional deployment.

Key Terms

Permissionless network: A network in which participation is generally open and does not require organisational admission.

Permissioned network: A network in which membership and actions are controlled by an identity and governance system.

Public blockchain: A broadly accessible ledger with open or widely distributed participation.

Private blockchain: A ledger controlled primarily by one organisation.

Consortium network: A permissioned network governed by several organisations.

Pseudonymity: Use of identifiers that do not directly reveal legal identity but may be linkable to a person or organisation.

Membership Service Provider: A system that defines and validates organisational identities in a permissioned network.

Authentication: Verification of the identity associated with a request.

Authorisation: Determination of which actions an authenticated identity may perform.

Accountability: Ability to associate actions with responsible actors and evidence.

Role-based access control: Access control based on assigned organisational roles.

Endorsement policy: A rule specifying which parties must approve a proposed transaction.

Channel: A logically separated communication and ledger context in Fabric.

Private data collection: A mechanism for sharing data with selected network members.

Chaincode: Business logic executed in a Fabric network.

Notary: A Corda service that helps confirm transaction uniqueness or finality.

Smart contract: Programmed logic that validates or executes agreed transaction rules.

Finality: The point at which a transaction is considered settled under a network’s rules.

Governance: Processes for membership, decisions, upgrades, disputes, and accountability.

Least privilege: Security principle of granting only the access necessary for a task.

Review Questions

Short Answer Questions

1. What is the principal difference between a permissionless and a permissioned network?
2. Why is a public blockchain address usually described as pseudonymous rather than anonymous?
3. What functions does a Membership Service Provider perform in Hyperledger Fabric?
4. What is the purpose of a Corda notary?
5. State two reasons why a consortium might prefer selective data sharing.

Long Answer Questions

1. Compare public, private, and consortium networks in terms of membership, trust, governance, privacy, and validation.
2. Explain the relationship between authentication, authorisation, accountability, and least privilege in a permissioned network.
3. Describe a typical Hyperledger Fabric transaction flow and explain the role of endorsement policies.
4. Compare Ethereum, Hyperledger Fabric, and Corda for enterprise use, including their data-sharing and governance models.
5. Discuss the legal, ethical, and operational risks of storing personal information on an immutable ledger.

Analytical / Application Questions

1. A group of competing banks needs to share settlement evidence while keeping transaction details visible only to relevant parties. Recommend an architecture and justify your choice against Ethereum, Fabric, and Corda.
2. A government agency proposes a private blockchain for an internal database that it alone controls. Analyse whether blockchain is justified and identify questions that should be answered before implementation.
3. Design a high-level identity, access-control, and governance model for a consortium pharmaceutical traceability network. Explain how it would handle membership, endorsement, privacy, key compromise, and disputes.

Multiple Choice Questions with Answers

Question 1

Which characteristic most clearly distinguishes a permissioned network from a permissionless network?

A. It uses cryptography.

B. It requires approved identities for participation.

C. It stores data on multiple computers.

D. It supports digital signatures.

Correct Answer: B. It requires approved identities for participation.

Question 2

Why is a typical Ethereum address described as pseudonymous?

A. It cannot be used to sign transactions.

B. It directly contains a verified legal identity.

C. It identifies a cryptographic account without necessarily revealing its controller.

D. It is visible only to network administrators.

Correct Answer: C. It identifies a cryptographic account without necessarily revealing its controller.

Question 3

Which Hyperledger Fabric component defines how identities are recognised and associated with organisations?

A. Membership Service Provider

B. Virtual machine

C. Mining pool

D. Notary

Correct Answer: A. Membership Service Provider

Question 4

What is a central purpose of an endorsement policy in Hyperledger Fabric?

A. To determine which organisations must approve a transaction proposal

B. To encrypt every public blockchain transaction

C. To assign cryptocurrency prices

D. To replace all identity certificates

Correct Answer: A. To determine which organisations must approve a transaction proposal

Question 5

In Corda, what is the principal role of a notary?

A. To publish every transaction to every node

B. To issue all employee credentials

C. To confirm transaction uniqueness or finality according to the notary design

D. To execute Ethereum smart contracts

Correct Answer: C. To confirm transaction uniqueness or finality according to the notary design

Question 6

Which architecture is generally most suitable when participation is open and public verification is a primary requirement?

A. A public permissionless network

B. A single-organisation private database

C. A closed private network with no external access

D. An offline document archive

Correct Answer: A. A public permissionless network

Question 7

Which statement about permissioned networks is correct?

A. They automatically eliminate the need for governance.

B. They make all data public by definition.

C. They can use known identities and role-based permissions.

D. They cannot support multiple organisations.

Correct Answer: C. They can use known identities and role-based permissions.

Question 8

A consortium has four validators and wants to tolerate one Byzantine validator under a standard 3f + 1 design assumption. What is the minimum number of validators required?

A. 2

B. 3

C. 4

D. 5

Correct Answer: C. 4

Question 9

Which practice best reflects the principle of least privilege?

A. Giving every participant administrator access

B. Giving each participant only the permissions required for its role

C. Allowing anonymous users to approve all transactions

D. Disabling identity revocation

Correct Answer: B. Giving each participant only the permissions required for its role

Question 10

Why might a pharmaceutical consortium choose selective data sharing rather than a fully public blockchain?

A. To avoid using cryptography

B. To prevent any organisation from having an identity

C. To protect commercially sensitive and personal information

D. To eliminate the need for governance

Correct Answer: C. To protect commercially sensitive and personal information