Lesson Objective

Understand Blockchain Architecture Selection

In the previous lesson, you followed the technical lifecycle of a blockchain transaction[cite: 8]. This lesson now asks a deeper architectural question: should the blockchain be public, private or shared between selected organisations?[cite: 8] By the end of this lesson, you will be able to compare blockchain types using permission models, validator control, transparency, governance, privacy and performance requirements[cite: 8].

Audio Lesson

Listen to This Lesson

The audio version provides a comprehensive architectural comparison, exploring the trade-offs between permissionless public networks, controlled private enterprise frameworks, and multi-party consortium governance agreements[cite: 8].

0:00 / 0:00

Architecture Overview

The Type of Blockchain Changes the System

A blockchain is not automatically public, private, decentralised or suitable for every use case[cite: 8]. The architecture depends on who can join the network, who can validate transactions, who can read data, who controls upgrades and how quickly the system needs to process activity[cite: 8]. Public blockchains move trust towards open protocols and decentralised validators[cite: 8]. Private blockchains move control towards an organisation[cite: 8]. Consortium blockchains distribute control between a selected group of trusted organisations[cite: 8].

Selection Algorithm

Public vs Private Blockchain Selection

Algorithm 3: Blockchain Architecture Selection[cite: 8]
Step Process Technical Selection Meaning
Step 1 Understand public blockchains Assess whether the system requires permissionless access, open validators and public auditability[cite: 8].
Step 2 Understand private blockchains Assess whether the system requires permissioned identities, known validators and organisational control[cite: 8].
Step 3 Understand consortium blockchains Assess whether several trusted organisations need shared validation and joint governance[cite: 8].
Step 4 Compare transparency Decide whether ledger data should be public, restricted, encrypted or visible only to approved members[cite: 8].
Step 5 Compare governance Identify who controls validators, permissions, protocol rules, upgrades and dispute resolution[cite: 8].
Step 6 Compare privacy Decide whether data should be stored publicly, encrypted, permissioned or kept off-chain with hashes on-chain[cite: 8].
Step 7 Compare performance Evaluate throughput, validator count, latency, cost, scalability and consensus overhead[cite: 8].
Step 8 Choose the correct blockchain type Select the architecture that matches the technical and organisational requirements[cite: 8].

Step 1

Understand Public Blockchains

A public blockchain is permissionless[cite: 8]. This means anyone can create a wallet, submit transactions, inspect ledger activity and, depending on the protocol, participate in validation[cite: 8]. Trust is not placed in one company or central administrator[cite: 8]. Instead, trust is distributed across the network through cryptography, consensus rules and economic incentives[cite: 8]. Public chains are useful when openness, independent verification and censorship resistance are more important than privacy or centralised performance control[cite: 8].

Public

Permissionless Ledger[cite: 8]

Wallet User

Open key creation bounds[cite: 8].

Network Node

Hosting unindexed data copies[cite: 8].

Open Access

Anyone can transact safely[cite: 8].

Validator

Distributed consensus voting rules[cite: 8].

Technical Point

Public blockchains use permissionless access, open validation and transparent ledger inspection to reduce reliance on central authorities[cite: 8].

Step 2

Understand Private Blockchains

A private blockchain is permissioned[cite: 8]. Users, applications and validator nodes must be approved before they can interact with the network[cite: 8]. This architecture is common in enterprise settings where identity, compliance, confidentiality and administrative control matter[cite: 8]. A private blockchain may still use blocks, hashes, signatures and validation rules, but the validator set is usually smaller and known[cite: 8]. This can reduce consensus overhead and improve speed, but it also makes the system less decentralised than a public blockchain[cite: 8].

User Identity

Approved access verified via whitelist registers[cite: 8].

Private Chain

Permissioned network topology tracking known validators and centralised rules protocols[cite: 8].

Admin Policy

Enforcing strict rules and role-based permissions profiles[cite: 8].

Technical Point

Private blockchains combine blockchain-style records with controlled identity, known validators and organisational governance[cite: 8].

Step 3

Understand Consortium Blockchains

A consortium blockchain is governed by several approved organisations rather than one owner or a fully open public network[cite: 8]. Each member may operate a validator node, participate in governance decisions and share responsibility for maintaining the ledger[cite: 8]. This model is useful for banking networks, supply chains, logistics, healthcare partnerships, government systems and industry groups where multiple organisations need shared verification without exposing everything to the public[cite: 8].

Consortium

Shared Validator Node Sets[cite: 8]

Organisation A

Validator node framework[cite: 8].

Organisation B

Validator node framework[cite: 8].

Organisation C

Member validation tracks[cite: 8].

Organisation D

Member validation tracks[cite: 8].

Technical Point

Consortium blockchains are permissioned networks where governance and validation are distributed across selected organisations[cite: 8].

Step 4

Compare Transparency

Transparency determines who can inspect the ledger[cite: 8]. In a public blockchain, transaction metadata and ledger history are usually visible to everyone, even if wallet identities are pseudonymous[cite: 8]. In a private blockchain, visibility can be restricted to internal users, departments or authorised applications[cite: 8]. In a consortium blockchain, approved members may share ledger visibility while hiding sensitive commercial details from external parties[cite: 8].

Public Openness

Fully open ledger history and public audit trails globally[cite: 8].

Private Limits

Restricted access layers locked to internal organizational tracking systems[cite: 8].

Consortium Shared

Member ledger views providing a mutual verification data pool[cite: 8].

Technical Point

Transparency controls who can read, inspect and verify blockchain activity[cite: 8].

Step 5

Compare Governance

Governance defines who controls the blockchain over time[cite: 8]. This includes who can approve validators, change protocol rules, modify access permissions, upgrade smart contracts, resolve disputes and respond to security incidents[cite: 8]. Public chains usually depend on community governance, protocol developers and validator incentives[cite: 8]. Private chains centralise governance in one organisation[cite: 8]. Consortium chains use shared governance agreements between approved members[cite: 8].

Public

Open Protocol Community Rule[cite: 8]

Private

Single Entity Administrative Node[cite: 8]

Consortium

Multi-Party Shared Agreements[cite: 8]

Technical Point

Governance controls the human and organisational rules behind the technical blockchain protocol[cite: 8].

Step 6

Compare Privacy

Privacy is one of the strongest reasons to choose a private or consortium blockchain[cite: 8]. Public chains expose transaction metadata by design, even when users are represented by wallet addresses rather than real names[cite: 8]. Enterprise systems may need encrypted payloads, role-based access, permissioned reads or off-chain storage where only a hash is placed on-chain[cite: 8]. This allows the blockchain to verify integrity without exposing the full sensitive record[cite: 8].

Public

Fully open transaction metadata traces[cite: 8].

Private

Role-based structural user visibility locks[cite: 8].

Consortium

Explicit member clearance verification parameters[cite: 8].

Technical Point

Privacy design decides whether sensitive data is public, encrypted, permissioned or represented by verification hashes[cite: 8].

Step 7

Compare Performance

Performance is not only about speed[cite: 8]. It includes transaction throughput, latency, validator count, consensus complexity, storage cost and network overhead[cite: 8]. Public blockchains may have lower throughput because many independent nodes must agree under open network conditions[cite: 8]. Private and consortium blockchains can often process transactions faster because they use known validators, controlled membership and lighter permissioned consensus[cite: 8].

Public

• Validator count: High[cite: 8]

• Consensus overhead: High[cite: 8]

• Throughput scale: Lower[cite: 8]

• Trust model: Open protocol[cite: 8]

Private

• Validator count: Low[cite: 8]

• Consensus overhead: Lower[cite: 8]

• Throughput scale: Higher[cite: 8]

• Trust model: Controlled[cite: 8]

Consortium

• Validator count: Medium[cite: 8]

• Consensus overhead: Medium[cite: 8]

• Throughput scale: Higher[cite: 8]

• Trust model: Shared system[cite: 8]

Technical Point

Performance depends on validator count, consensus overhead, network openness and how much decentralisation the system requires[cite: 8].

Step 8

Choose the Correct Blockchain Type

Blockchain selection should be based on requirements, not hype[cite: 8]. A public blockchain is appropriate when the system needs open participation, decentralised trust and public auditability[cite: 8]. A private blockchain is appropriate when one organisation needs controlled access, known validators and data confidentiality[cite: 8]. A consortium blockchain is appropriate when several organisations need to share verification, governance and trust without making the system fully public[cite: 8].

Architecture Selection

What does your core system require?[cite: 8]

Choose Public

Open access and public verification lines[cite: 8].

Choose Private

Organisational control and restricted data sets[cite: 8].

Choose Consortium

Shared multi-party governance with approved members[cite: 8].

Technical Point

Good blockchain design begins with requirements: openness, control, shared governance, privacy and performance[cite: 8].

Key Takeaways

What You Should Remember

🌍

Public Blockchain

Permissionless, transparent and decentralised, but usually slower and less private[cite: 8].

🔒

Private Blockchain

Permissioned, controlled and privacy-focused, but less decentralised[cite: 8].

🤝

Consortium Blockchain

Shared between approved organisations with joint validation and governance[cite: 8].

⚙️

Architecture Selection

The correct choice depends on access, validator control, transparency, privacy and performance[cite: 8].

Knowledge Check

Quick Public vs Private Blockchain Quiz

Test your understanding. The questions can change when you refresh them[cite: 8].

Lesson Summary

Public, Private and Consortium Blockchains

Public blockchains are open, permissionless systems designed for public auditability and decentralised trust[cite: 8]. Private blockchains are permissioned systems designed for organisational control, known validators and stronger privacy[cite: 8]. Consortium blockchains sit between these models by allowing several approved organisations to share validation and governance[cite: 8]. The best architecture depends on the system’s requirements, including access, transparency, governance, privacy, validator control and performance[cite: 8].