Blockchain Architectures and Platforms

Introduction

A blockchain is not a single technology or a single type of network. It is a family of distributed systems that combine replicated data storage, cryptographic integrity, consensus, networking, and rules for validating transactions. The appropriate architecture depends on who may participate, what assets are recorded, how much governance is required, and what performance, privacy, and regulatory obligations apply.

Bitcoin illustrates a public, permissionless blockchain designed primarily for peer-to-peer digital money. Ethereum extends the public-blockchain model with a general-purpose execution environment for smart contracts. Enterprise frameworks such as Hyperledger Fabric and Hyperledger Besu support organisations that require controlled membership, privacy, identity management, and configurable governance. Understanding these differences is essential when selecting or designing a blockchain solution.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish public, private, consortium, permissioned, and permissionless networks;
• explain how architecture affects identity, governance, consensus, privacy, scalability, and finality;
• compare Bitcoin, Ethereum, and enterprise blockchain frameworks;
• select a suitable platform for a practical organisational problem;
• evaluate blockchain proposals critically rather than assuming that decentralisation is always desirable.

1. Architectural Dimensions of a Blockchain

A blockchain architecture can be analysed through several related dimensions.

Membership asks who may join the network and obtain an identity. In an open network, participation is generally unrestricted. In a controlled network, an administrator or membership service provider approves participants.

Read, write, and validate rights are separate permissions. A network may allow many users to read records while limiting transaction submission or block validation to approved organisations. Therefore, “permissioned” should not be treated as a single binary property.

Governance concerns who changes protocol rules, admits members, resolves disputes, upgrades software, and manages emergencies. Governance may be informal and community-driven, or contractual and administered by a consortium.

Consensus is the process by which nodes agree on the order and validity of transactions. Public systems may use economic incentives and open participation; enterprise systems commonly use authenticated validators and voting or leader-based protocols.

Execution describes whether the chain merely transfers a native asset or also runs programmable transactions and smart contracts. Programmability increases flexibility but also introduces software risk.

Data visibility ranges from globally replicated public data to confidential records shared only among selected parties. Encryption may protect content, but metadata such as transaction timing, addresses, and frequency can remain visible.

Performance and finality include throughput, latency, and whether a confirmed transaction can later be reversed. These are system properties, not just marketing claims. Throughput depends on transaction size, block or ordering parameters, validation cost, network conditions, and workload.

A useful high-level relationship is that increasing openness and decentralisation often creates additional coordination and performance costs. This is not an absolute law: engineering improvements can change trade-offs, but they cannot remove the need to make them explicit.

Figure: Principal dimensions used to compare blockchain architectures.

2. Network Classifications

2.1 Public and private networks

A public blockchain is open to broad participation. Its ledger is usually readable by anyone, and new nodes can often join without approval. Public networks aim to reduce dependence on a single organisation. They are suitable where participants do not already trust one another, such as open digital-asset markets. Their challenges include variable fees, public data exposure, governance disputes, regulatory complexity, and lower performance than a centrally controlled database for many workloads.

A private blockchain is operated by one organisation or by a clearly designated controlling entity. Participation, validation, and access are restricted. Private systems can provide predictable performance and confidentiality, but they may offer little advantage over a conventional database if one party already controls all records and participants. Their value may arise when multiple internal departments need shared auditability, tamper evidence, or standardised workflows.

2.2 Consortium networks

A consortium blockchain, also called a federated blockchain, is governed by several organisations. Membership is controlled, but no single participant necessarily owns the whole network. A consortium agreement should specify admission criteria, validator responsibilities, software upgrades, data access, liability, dispute resolution, and recovery procedures.

For example, banks may jointly operate a trade-finance network. Each bank can validate transactions, but customers may have more limited rights. Consortium structures can improve inter-organisational coordination while retaining legal accountability. However, they require institutional trust and careful governance; technology cannot substitute for an enforceable agreement.

2.3 Permissioned and permissionless networks

A permissionless network allows participants to perform one or more activities—such as reading, submitting transactions, or validating blocks—without prior authorisation. Bitcoin and the public Ethereum network are examples. Permissionless systems commonly use pseudonymous cryptographic identities and mechanisms intended to resist Sybil attacks, in which one actor creates many identities.

A permissioned network requires authorisation for specified activities. Identity is generally linked to an organisation or individual through certificates, registrations, or other credentials. Permissioned networks can apply access controls, legal accountability, and privacy policies. They may use Byzantine fault-tolerant consensus, proof of authority, or other mechanisms rather than open mining or staking.

These categories overlap. A network can be public but permissioned for validation, or private but permit public reading. The most precise description therefore states the permission associated with each activity.

3. Consensus, Finality, and Trust Models

Consensus does not make false real-world information true. It establishes agreement on whether a transaction satisfies protocol rules and on its position in the ledger. If an oracle reports an incorrect temperature or delivery status, consensus can faithfully record the incorrect report.

In Bitcoin, proof of work (PoW) makes block production computationally expensive. Miners compete to find a valid hash under a difficulty target and receive rewards according to protocol rules. The model supports open participation but consumes substantial energy and normally provides probabilistic finality: confidence increases as additional blocks build on a transaction.

Proof of stake (PoS) selects or assigns validators according to staked economic value and applies penalties or loss of stake for certain dishonest behaviour. Ethereum uses PoS. Its security model depends on validator incentives, protocol rules, client diversity, and assumptions about the distribution of stake.

Enterprise networks may use authenticated validators and Byzantine fault-tolerant protocols. In a simplified crash-and-Byzantine model, a protocol may tolerate fewer than one-third of validators behaving arbitrarily, often expressed as f < n/3, where n is the number of validators and f is the maximum number of Byzantine validators. This condition is protocol-dependent and should not be presented as a universal rule. It assumes the relevant network model, communication assumptions, and correct implementation.

Probabilistic finality means that reversal becomes increasingly unlikely but is not immediately impossible under the protocol’s threat model. Deterministic or economic finality means that protocol rules provide a defined finality point, subject to stated assumptions. Organisations must distinguish technical finality from legal finality: a court, regulator, or contractual process may still reverse or compensate a transaction.

4. Platform Categories and Major Examples

4.1 Bitcoin: a settlement-oriented public blockchain

Bitcoin is a public, permissionless network designed around a scarce native asset and peer-to-peer transfer. Users control funds through private keys; transactions reference unspent transaction outputs (UTXOs), which are consumed and replaced by new outputs. Bitcoin Script is intentionally constrained compared with general-purpose programming languages, reducing some classes of execution complexity but limiting application flexibility.

Bitcoin’s strengths include a clear monetary purpose, extensive independent verification, strong censorship resistance, and a mature security culture. Its limitations include energy use associated with proof of work, limited on-chain transaction capacity, public transaction history, fee variability, and the irreversibility of confirmed transactions in ordinary operation. Scaling approaches may use additional layers or off-chain channels, but these introduce their own liquidity, routing, custody, or trust considerations.

4.2 Ethereum: a programmable public blockchain

Ethereum is a public blockchain with a general-purpose smart-contract execution environment, the Ethereum Virtual Machine (EVM). Accounts may be externally controlled by private keys or controlled by smart contracts. Developers deploy programs that manage assets, permissions, exchanges, voting, and other processes.

Ethereum’s programmability enables decentralised applications and token standards, but it creates risks. Smart contracts may contain exploitable logic, incorrect assumptions, access-control errors, or economic vulnerabilities. A deployed contract can be difficult to change, and upgrade mechanisms may create administrative powers that users must understand. Transaction execution consumes gas, a metering mechanism that prevents unbounded computation and allocates scarce block space.

Ethereum uses proof of stake and has a broader application ecosystem than Bitcoin. Nevertheless, its public execution environment exposes transaction data, and users face fees, congestion, wallet-security risks, and dependencies on interfaces, bridges, oracles, and off-chain services. “Decentralised application” therefore describes only part of a system; the complete trust model includes every operational dependency.

4.3 Enterprise frameworks

Enterprise blockchain frameworks generally provide permissioned membership, identity services, configurable endorsement or ordering, private data mechanisms, and integration interfaces.

Hyperledger Fabric uses a modular architecture. Organisations join channels or other controlled data arrangements, peers maintain ledgers and execute chaincode, and an ordering service establishes transaction order. Endorsement policies can require specified organisations to approve a transaction. This allows a business process to express rules such as “two of three institutions must endorse.” Fabric is well suited to multiparty workflows where all participants are identified and not every participant should see every record.

Hyperledger Besu is an Ethereum client that can operate on public Ethereum or private, permissioned networks. Its EVM compatibility can help organisations use Ethereum tooling while configuring enterprise-oriented networks and consensus options. Compatibility does not remove the need to evaluate privacy, governance, key management, and operational resilience.

Other enterprise approaches include Quorum-derived systems and Corda. Corda is often described as a distributed ledger platform rather than a conventional globally replicated blockchain: data is shared selectively among parties involved in a transaction, and not every node necessarily stores every transaction. The distinction matters when analysing privacy and replication.

5. Selecting an Architecture

A disciplined selection process begins with the business problem, not the label “blockchain.” Ask the following questions:

1. Is a shared ledger necessary? If one trusted organisation can maintain the authoritative database and no independent auditability requirement exists, a conventional database may be cheaper and simpler.
2. Who are the participants? Unknown participants suggest a public model; known regulated organisations may favour a consortium.
3. What must be private? Classify transaction content, identities, metadata, and business logic separately. Encryption alone does not guarantee metadata privacy.
4. Who governs membership and upgrades? Name the decision rights and emergency procedures before deployment.
5. What finality is needed? A payment, securities transfer, or manufacturing event may have different operational and legal requirements.
6. What performance is required? Measure realistic workload, peak bursts, latency, storage growth, and failure recovery rather than relying on a nominal transactions-per-second figure.
7. What is the key-management model? Lost keys, compromised administrator credentials, insider abuse, and inadequate recovery can defeat a technically sound design.
8. How will the system integrate? APIs, identity providers, ERP systems, IoT devices, oracles, and reporting systems may become the true points of failure.

A useful evaluation matrix assigns weighted scores to criteria such as privacy, decentralisation, governance fit, operational cost, ecosystem maturity, interoperability, and regulatory suitability. Scores should be justified by evidence and sensitivity-tested; a high score is not meaningful if the weights merely encode an unexamined preference.

6. Applied Case: A Consortium for Pharmaceutical Traceability

Background. This illustrative case concerns manufacturers, distributors, hospitals, and a regulator seeking to trace batches of temperature-sensitive medicines. Counterfeit products and delayed recalls create safety and financial risks. No single participant is trusted to operate the complete record for all others.

Problem. Participants need a common history of batch creation, custody transfer, and recall status. Commercial prices and patient information must not be visible to every member. The regulator requires audit access, while hospitals need rapid verification at receipt.

Analysis. A public permissionless chain would expose commercially sensitive events and create unnecessary transaction-fee and identity problems. A single private database would leave other organisations dependent on the operator and could weaken shared governance. A consortium permissioned network is more appropriate because participants are known organisations with contractual relationships.

Approach. Each organisation receives a managed digital identity. The network records batch identifiers, timestamps, custody events, and references to inspection documents. Sensitive documents remain in controlled off-chain repositories; the ledger stores suitable hashes and access-controlled references. Endorsement rules require, for example, the sender and receiver to approve a custody transfer. The consortium agreement defines validator admission, audit rights, key recovery, incident response, data retention, and dispute procedures.

Outcome. The design improves shared auditability and recall coordination without requiring every participant to disclose all commercial data. It does not prove that a physical package is genuine merely because a valid digital record exists. Therefore, tamper-evident seals, inspections, secure scanning, and reliable data-entry procedures remain necessary.

Learning points. Architecture follows trust relationships and information requirements. Off-chain components must be included in the threat model. Governance, identity, and physical controls are as important as consensus.

7. Limitations, Risks, and Governance

Blockchain records are only as reliable as the processes that create them. The “garbage in, garbage out” problem is especially important for IoT feeds and human-entered events. Privacy laws may conflict with immutable replication, particularly where individuals have rights to correction or erasure. Designers should minimise personal data on-chain, use appropriate retention and access controls, and obtain legal advice for the relevant jurisdiction.

Smart contracts create software and governance risks. Code review, testing, formal analysis where justified, least-privilege administration, independent audits, pause or recovery procedures, and transparent upgrade policies reduce—but do not eliminate—risk. An audit is evidence about examined code, not a guarantee of safety.

Operational resilience requires monitoring, backups where compatible with the trust model, disaster recovery, client and node diversity, patch management, incident exercises, and documented key ceremonies. Concentration in a small number of cloud providers, validators, custodians, or developers can create centralisation even when the protocol is decentralised.

Environmental evaluation should consider the complete system and energy source, not only a consensus label. Regulatory classification may include money transmission, securities, payments, consumer protection, competition, privacy, sanctions, and recordkeeping obligations. AI can assist with anomaly detection, transaction classification, code analysis, or operational monitoring, but AI outputs require validation and should not be granted unilateral authority over irreversible transactions.

8. Contemporary Developments and Best Practices

Current development trends include layer-2 scaling, rollups, modular architectures, zero-knowledge proofs, interoperable messaging, tokenised real-world assets, and improved wallet abstraction. These technologies may improve scalability or privacy, but they also add bridge, sequencer, prover, oracle, and upgrade dependencies. A system should be evaluated as a complete architecture rather than by its most innovative component.

Best practice includes:

• define the trust and threat model before selecting a platform;
• separate read, submit, and validate permissions;
• minimise sensitive and personal data on-chain;
• document governance and legal accountability;
• use test networks and staged deployment;
• conduct threat modelling, code review, and penetration testing;
• design key recovery and incident response in advance;
• measure real workloads and total cost of ownership;
• monitor decentralisation and operational concentration over time;
• maintain an exit or migration plan.

Chapter Summary

Blockchain architectures differ chiefly in membership, authority, visibility, consensus, execution, governance, and finality. Public permissionless networks such as Bitcoin and Ethereum support open participation and resistance to unilateral control, but introduce public-data, performance, fee, governance, and operational challenges. Bitcoin is primarily settlement-oriented and uses a constrained scripting model; Ethereum provides a general-purpose smart-contract environment with additional software and economic risks.

Private and consortium permissioned networks provide known identities, configurable privacy, and institutional governance. Frameworks such as Hyperledger Fabric, Hyperledger Besu, and Corda support different approaches to endorsement, ordering, EVM compatibility, and selective data sharing. A sound selection process first determines whether a blockchain is necessary, then evaluates participants, privacy, finality, performance, governance, integration, key management, and regulation. Consensus secures agreement about recorded transactions, but it cannot guarantee the truth of external data. Effective blockchain solutions therefore combine technical controls with legal agreements, operational procedures, physical safeguards, and responsible governance.

Key Terms

Blockchain: A replicated, cryptographically linked ledger maintained by a distributed network.

Public blockchain: A network broadly open to reading or participation.

Private blockchain: A network controlled by one organisation.

Consortium blockchain: A network governed by multiple approved organisations.

Permissionless: Allowing specified network activities without prior authorisation.

Permissioned: Requiring authorisation for specified network activities.

Consensus: A protocol process for agreeing on valid transaction order and state.

Proof of work: A consensus mechanism using computational effort to make block production costly.

Proof of stake: A consensus mechanism using staked value and validator rules.

Finality: The point or probability at which a transaction is considered irreversible under stated assumptions.

Smart contract: Program code that executes agreed rules on a blockchain platform.

EVM: Ethereum Virtual Machine, the execution environment for Ethereum-compatible contracts.

Gas: A measure used to meter computation and allocate execution resources on Ethereum.

UTXO: An unspent transaction output used in Bitcoin’s transaction model.

Validator: A node or participant that helps verify or order transactions.

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

Oracle: A service that supplies external information to a blockchain.

Sybil attack: An attack using many identities to gain disproportionate influence.

Governance: Processes for changing rules, managing membership, and resolving disputes.

Review Questions

Short Answer Questions

1. What is the difference between a public blockchain and a permissionless blockchain?
2. Why might a consortium choose a permissioned network?
3. What does finality mean, and how can it be probabilistic?
4. How does Ethereum differ from Bitcoin in programmability?
5. Why does consensus not guarantee the truth of an oracle’s data?

Long Answer Questions

1. Compare public, private, and consortium blockchains in terms of membership, governance, privacy, and performance.
2. Explain the principal strengths and limitations of Bitcoin as a settlement platform.
3. Discuss how smart contracts create both opportunities and risks in Ethereum-based systems.
4. Describe the roles of identity, endorsement, ordering, and governance in an enterprise blockchain.
5. Explain why a conventional database may be preferable to a blockchain for some business problems.

Analytical / Application Questions

1. A group of competing banks wants to share trade-finance records while keeping customer details confidential. Recommend an architecture and justify the consensus, identity, privacy, and governance choices.
2. A proposed blockchain claims 100,000 transactions per second but provides no workload, latency, or finality information. Design an evaluation plan to test the claim.
3. Analyse the pharmaceutical traceability case. Identify two technical risks, two governance risks, and two controls that should be implemented before production deployment.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a consortium blockchain?

A. It is controlled by one individual user.

B. It is governed by multiple approved organisations.

C. It allows no transaction validation.

D. It must use proof of work.

Correct Answer: B. It is governed by multiple approved organisations.

Question 2

Which platform is primarily associated with a UTXO transaction model?

A. Bitcoin

B. Ethereum

C. Hyperledger Fabric

D. Corda

Correct Answer: A. Bitcoin

Question 3

What is a principal characteristic of a permissionless network?

A. All validators must belong to one company.

B. Participation in specified activities does not require prior authorisation.

C. Every transaction is legally reversible.

D. Private data is automatically hidden from all observers.

Correct Answer: B. Participation in specified activities does not require prior authorisation.

Question 4

What does Ethereum gas primarily measure?

A. The market price of ether

B. The physical energy used by a validator

C. Computational execution resources

D. The number of wallet addresses

Correct Answer: C. Computational execution resources

Question 5

Which statement about consensus is correct?

A. It guarantees that external data supplied by an oracle is true.

B. It establishes agreement about valid transactions under protocol rules.

C. It removes the need for identity and governance.

D. It makes all blockchain data confidential.

Correct Answer: B. It establishes agreement about valid transactions under protocol rules.

Question 6

Which feature is especially associated with Hyperledger Fabric?

A. Mining based on proof of work

B. Mandatory public visibility of every transaction

C. Configurable endorsement policies among organisations

D. A requirement that all nodes be anonymous

Correct Answer: C. Configurable endorsement policies among organisations

Question 7

A company alone controls all participants and needs only an internal database. What should be evaluated first?

A. Whether a conventional database is simpler and more suitable

B. How to maximise anonymous mining

C. How to expose all records publicly

D. How to eliminate all governance procedures

Correct Answer: A. Whether a conventional database is simpler and more suitable

Question 8

In the simplified Byzantine fault-tolerance condition f < n/3, what does n represent?

A. The number of transactions in a block

B. The number of validators

C. The number of private keys per user

D. The number of smart contracts

Correct Answer: B. The number of validators

Question 9

Why may encryption alone fail to provide complete privacy on a public blockchain?

A. Encryption prevents transaction validation.

B. Metadata such as timing and addresses may remain observable.

C. Encrypted data cannot ever be stored.

D. Encryption automatically reveals private keys.

Correct Answer: B. Metadata such as timing and addresses may remain observable.

Question 10

Which is an appropriate best practice for sensitive personal information?

A. Store all personal records permanently on every node.

B. Ignore retention and correction requirements.

C. Minimise on-chain personal data and apply suitable access controls.

D. Replace governance with an AI model.

Correct Answer: C. Minimise on-chain personal data and apply suitable access controls.