Public blockchains rely on decentralized, permissionless consensus like Proof of Work (PoW) or Proof of Stake (PoS) to achieve security through economic incentives. Private blockchains use efficient, permissioned protocols such as Practical Byzantine Fault Tolerance (PBFT) or Raft, where known validators achieve consensus faster but with reduced decentralization.

• Public Example: Ethereum uses PoS, requiring validators to stake 32 ETH.
• Private Example: Hyperledger Fabric uses a pluggable ordering service, often PBFT, for enterprise networks.

This defines who can read, write, and validate transactions. Public blockchains are permissionless; anyone can join the network, run a node, and participate. Private blockchains are permissioned, with a central authority controlling network access and user roles.

• Public: Bitcoin and Ethereum have no gatekeepers for participation.
• Private: A consortium blockchain for banks would restrict validator nodes to member institutions only.

Public blockchains offer full transparency; all transaction data is visible to anyone, enabling verifiable audit trails. Private blockchains provide controlled transparency, where data visibility is restricted to authorized participants, balancing privacy with internal accountability.

• Public: All Ethereum smart contract interactions are publicly auditable on Etherscan.
• Private: A supply chain blockchain may share shipment data only with the involved buyer, seller, and logistics provider.

Governance determines how protocol changes are decided. Public blockchains use decentralized, often slow, on-chain or social consensus (e.g., Ethereum Improvement Proposals). Private blockchains employ centralized, off-chain governance where a consortium or single entity makes swift decisions.

• Public: Bitcoin's BIP process requires broad community agreement.
• Private: A corporate blockchain's upgrade is decided by its IT governance committee.

Used by Bitcoin and early Ethereum. Miners compete to solve cryptographic puzzles to add blocks. This mechanism is decentralized and secure but extremely energy-intensive.

• Key for: Public, permissionless networks requiring maximum security.
• Throughput: Low (Bitcoin: ~7 TPS).
• Finality: Probabilistic (confirmation depth required).

Validators are chosen to propose blocks based on the amount of cryptocurrency they "stake" as collateral. This is the foundation for Ethereum 2.0, Cardano, and Solana.

• Key for: Public networks seeking energy efficiency and higher scalability.
• Throughput: Medium to High (Ethereum: ~15-45 TPS post-merge).
• Finality: Can be probabilistic or, with protocols like Casper FFG, finalized in epochs.

A classical consensus algorithm where a known set of validators vote on block ordering. Requires 2/3 + 1 of nodes to be honest. Used as the basis for Hyperledger Fabric's ordering service and early versions of Ripple.

• Key for: Private/consortium networks with known participants.
• Throughput: High (thousands of TPS).
• Finality: Instant and deterministic once a supermajority agrees.

Token holders vote for a small set of delegates (e.g., 21 for EOS, 27 for TRON) to validate transactions and produce blocks. This creates a more efficient but more centralized governance layer.

• Key for: Public networks prioritizing high transaction speed and governance clarity.
• Throughput: Very High (EOS can handle 4,000+ TPS).
• Finality: Near-instant (1-3 second block times).

Designed for systems where nodes may fail but are not malicious (non-Byzantine). A leader is elected to sequence transactions. Used in private Ethereum clients like Hyperledger Besu and Quorum for speed.

• Key for: Private, single-organization blockchains where all nodes are trusted.
• Throughput: Very High, limited only by network and hardware.
• Finality: Instant upon leader confirmation.

Blocks are validated by approved, identifiable accounts (validators). This sacrifices decentralization for high performance and is used in consortium chains and testnets (like Goerli, Sepolia).

• Key for: Private networks or public utility chains where identity and uptime are paramount.
• Throughput: High.
• Finality: Fast and deterministic. Validator identity provides accountability.

Anyone can join the network as a node, validator, or user without requiring approval. This model is defined by open participation and censorship resistance. Key characteristics include:

• Pseudonymous participation: Users interact via cryptographic addresses.
• Consensus via Proof-of-Work/Stake: Open competition to propose blocks.
• Transparent ledger: All transaction data is publicly auditable.

Examples: Bitcoin, Ethereum, Solana.

Network access is restricted to a predefined set of known entities. A central authority or consortium controls membership and validator rights. This model prioritizes privacy, compliance, and performance. Key characteristics include:

• Identity-based access: Participants are known and vetted.
• Consensus via Voting/PBFT: Faster, finality-driven mechanisms.
• Data confidentiality: Transaction visibility can be restricted.

Examples: Hyperledger Fabric, R3 Corda for enterprise consortia.

A hybrid model where a group of organizations, rather than a single entity, controls the network. It balances decentralization with the efficiency needs of business partnerships. Key characteristics include:

• Multi-party governance: A pre-selected group of nodes validates transactions.
• Enhanced trust: Reduces reliance on any single organization.
• Regulatory clarity: Known participants simplify compliance.

Use cases include interbank settlements (like Marco Polo Network) and supply chain tracking.

The access model dictates core development choices, from tooling to smart contract design.

• Public chains: Use wallets (MetaMask, Phantom), public RPCs, and gas tokens. Smart contracts are immutable and public.
• Private/Consortium chains: Use certificate-based authentication, private RPC endpoints, and may not require a native token for fees. Smart contracts can have upgradeable and private logic modules.

Frameworks like Hyperledger Besu allow deployment in both permissioned and permissionless environments.

The threat surface differs radically between models.

• Public: Security relies on cryptoeconomic incentives and the cost of attacking a decentralized validator set (51% attack). Transparency enables crowd-sourced auditing.
• Private/Consortium: Security is administrative and legal. Threats include insider attacks, collusion among members, and centralized points of failure in the permissioning service. Data privacy is a primary security goal.

The Ethereum Yellow Paper is the formal specification of Ethereum as a public, permissionless blockchain. It defines the execution model, gas accounting, state transitions, and consensus assumptions used by open networks.

Key topics relevant to public blockchains:

• Permissionless access where any node can validate and propagate blocks
• Gas-based resource pricing to mitigate spam and enforce fairness
• Global state machine replicated across thousands of nodes
• Security tradeoffs between decentralization and performance

This paper is essential for understanding why public blockchains prioritize censorship resistance and trust minimization over throughput and confidentiality.

Hyperledger Fabric is the most widely deployed permissioned blockchain framework in enterprise environments. Its architecture illustrates core differences between private blockchains and public networks.

Key architectural concepts:

• Membership Service Provider (MSP) for identity and access control
• Execute-order-validate transaction flow
• Private data collections for selective state visibility
• Modular consensus with pluggable ordering services

Fabric is commonly used in supply chain, trade finance, and internal settlement systems where participants are known and compliance requirements mandate data confidentiality.

The NIST Blockchain Technology Overview (NISTIR 8202) provides a neutral, standards-focused analysis of blockchain architectures used in both public and private systems.

Topics covered:

• Permission models and their security implications
• Differences between public, private, and consortium blockchains
• Consensus mechanisms and fault assumptions
• Governance, identity, and risk management considerations

This resource is frequently cited in regulated environments and is useful for comparing architectural tradeoffs from a security and compliance perspective rather than a crypto-economic one.

The Bitcoin whitepaper defines the original architecture of a public, permissionless blockchain secured by proof-of-work.

Relevant architectural principles:

• Open participation in block production and validation
• Probabilistic finality via longest-chain rule
• Economic incentives aligned through block rewards and fees
• Resistance to Sybil attacks without trusted identities

Despite its age, this paper remains foundational for understanding why public blockchains are designed to function without centralized governance or access controls.

The Enterprise Ethereum Alliance (EEA) specifications describe how Ethereum-based systems can be adapted for permissioned and consortium settings.

Key differences highlighted:

• Restricted validator sets compared to public Ethereum
• Support for private transactions and state segregation
• Alternative consensus mechanisms optimized for known participants

EEA documents are useful for understanding hybrid architectures that sit between fully public blockchains and fully private ledgers.