3. Blockchain Architectures and Data Models

Introduction and Context

A blockchain is not a single technology but an arrangement of data structures, network participants, consensus rules, storage mechanisms, and governance procedures. The architecture selected for a blockchain system determines who may participate, how transactions are validated, how quickly they become irreversible, what information is visible, and how the system responds to failure or disagreement. Consequently, blockchain architecture is a strategic and security decision rather than merely an implementation detail.

The earliest widely deployed blockchain systems were designed as open, adversarial networks. Their objective was to allow mutually distrustful participants to maintain a shared ledger without a central administrator. Enterprise systems later adapted blockchain principles for environments in which participants are known, legal accountability is important, and confidentiality is required. Between these settings lie consortium and hybrid architectures, which combine elements of openness, institutional control, and selective disclosure.

Data modelling is equally important. A UTXO model records spendable transaction outputs, whereas an account model records balances and, in many systems, programmable state. The choice influences privacy, transaction validation, smart-contract design, scalability, wallet management, and auditability. This chapter examines these architectural alternatives and connects them to nodes, peer-to-peer communication, storage, finality, forks, and interoperability.

Learning Objectives

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

1. Distinguish public, private, consortium, permissioned, and hybrid blockchain networks.

2. Compare UTXO and account-based data models in terms of state, validation, privacy, and programmability.

3. Explain the roles of full nodes, validating nodes, light clients, archival nodes, and other network participants.

4. Analyse peer-to-peer communication, storage architecture, replication, and data availability.

5. Differentiate probabilistic, economic, and deterministic finality and explain the security implications of forks.

6. Assess interoperability requirements and select an architecture for an organizational use case.

7. Identify governance, privacy, regulatory, operational, and security risks in blockchain deployment.

Architecture as a Set of Design Decisions

A blockchain system can be understood through several related layers. The data layer defines transactions, blocks, state, hashes, and cryptographic proofs. The network layer distributes transactions and blocks among peers. The consensus layer determines which proposed history becomes authoritative. The execution layer interprets scripts or smart contracts. The application layer provides business functionality, while the governance layer defines who may change rules, admit participants, or resolve exceptional events.

These layers are conceptually distinct but operationally interdependent. For example, a permissioned network may use authenticated membership at the network layer, a Byzantine fault-tolerant protocol at the consensus layer, and an account-based state model at the execution layer. Changing the consensus protocol can alter finality and node requirements; changing the data model can affect transaction privacy and smart-contract semantics.

A useful architectural analysis therefore asks five questions. Who can read the ledger? Who can submit transactions? Who can validate transactions and propose blocks? Who can change the protocol or membership rules? Finally, what evidence is available to prove that a particular state was valid at a particular time? These questions are more informative than classifying a system by a single label.

Public, Private, Consortium, Permissioned, and Hybrid Networks

Public Networks

A public blockchain permits broad participation, usually without prior institutional approval. Anyone may obtain software, create keys, submit transactions, and often operate a node. Validation may be open to all eligible participants, although economic or hardware requirements can create practical barriers.

Public networks maximize openness and resistance to unilateral control. They are appropriate where participants do not share a trusted administrator, such as open digital-asset ecosystems, censorship-resistant payment systems, and publicly verifiable registries. Their costs include lower throughput, exposure of transaction metadata, governance disputes, and the possibility of congestion or volatile transaction fees.

Public systems must assume that some participants are malicious or anonymous. Their consensus mechanisms therefore typically incorporate economic incentives, resource expenditure, or broad validator selection. Identity-based accountability is limited, so cryptographic identity and protocol-level penalties become important.

Private Networks

A private blockchain is controlled by a single organization or a tightly controlled administrative domain. Participation, validation, and access to data are restricted by the owner. Such a system may improve confidentiality, performance, and operational control, but it does not automatically provide decentralization. If one organization can rewrite history or admit validators unilaterally, the system may resemble a replicated database with blockchain-inspired structures.

Private blockchains can nevertheless be useful when several internal departments require a common tamper-evident record, when legacy systems need a shared audit trail, or when an organization wants programmable workflows without exposing data publicly. Their security depends heavily on institutional governance, access control, key management, and independent auditing.

Consortium Networks

A consortium blockchain is governed by several organizations rather than one owner. Membership is usually restricted to identified institutions, and validator rights are allocated according to an agreed governance arrangement. Examples may include banks sharing settlement infrastructure, manufacturers coordinating provenance records, or universities managing credentials.

Consortium design introduces political and legal questions. Members must agree on admission, voting rights, software upgrades, liability, dispute resolution, data retention, and the treatment of a member that becomes insolvent or malicious. Technical decentralization is meaningful only when governance prevents one participant from exercising disproportionate control.

Permissioned Networks

Permission describes access policy rather than ownership. A permissioned network requires authorization for some or all activities: reading data, submitting transactions, validating blocks, or deploying contracts. A consortium network is usually permissioned, but a private network is not the only form of permissioned architecture. Permissioned systems may use public anchoring, selective disclosure, or open observation combined with restricted validation.

Identity services are central to permissioned environments. Certificates, membership services, hardware security modules, and revocation procedures establish whether a public key represents an authorized organization or user. Permissioning can support accountability and regulatory compliance, but it creates administrative dependencies and a target for identity compromise.

Hybrid Networks

A hybrid blockchain combines controlled and open characteristics. For example, confidential business transactions may be processed by an authorized consortium while cryptographic commitments are periodically published to a public chain. Alternatively, transaction submission may be restricted while selected proofs or final states are publicly verifiable.

Hybrid architectures are attractive when an organization needs privacy but also wants an independent timestamp or an externally verifiable integrity anchor. Their complexity lies in coordinating two trust domains. If the public anchor confirms only a hash, it proves that a commitment existed at a time; it does not prove that the underlying private data was accurate or that the private network followed correct procedures.

Comparative Decision Criteria

Architecture selection should consider trust relationships, confidentiality, required throughput, latency, legal accountability, fault assumptions, governance, operating cost, and interoperability. Public networks are strongest for open verification and censorship resistance. Private networks offer control and efficiency. Consortium networks distribute institutional trust. Permissioned networks support identity and policy enforcement. Hybrid networks seek a balance but require careful boundary design.

UTXO and Account Models

The UTXO Model

UTXO means unspent transaction output. In this model, a transaction consumes one or more existing outputs and creates new outputs. Each output specifies a value and a spending condition, commonly represented by a script or a public-key-based locking rule. An output is available for spending only once; after consumption it is removed from the set of unspent outputs.

A transaction can be represented conceptually as:

Inputs referencing previous outputs + authorization data → new outputs.

The ledger state is therefore the set of all currently unspent outputs. A validator checks that referenced outputs exist, have not already been spent, satisfy the spending condition, and obey transaction rules. A transaction normally cannot alter an output after it has been confirmed, which gives the model a clear and auditable state-transition structure.

UTXO systems can validate inputs independently, support transaction parallelism, and make certain forms of privacy easier through the use of fresh addresses and coin selection. They also present practical challenges. Users may hold many small outputs, creating fragmentation and higher fees. Wallets must select inputs, calculate change, and manage transaction composition. Complex contracts may require sophisticated script design.

The Account Model

An account model represents state as accounts with balances and, in some systems, associated code and storage. A transaction typically identifies a sender, recipient, amount, fee, and sequence or nonce. The validator checks the sender’s authorization, balance, and transaction ordering before updating account state.

Account models are often intuitive for payment applications and well suited to general-purpose smart contracts. A contract can maintain persistent variables in its storage, and transactions can invoke functions that transform that state. The model resembles conventional banking or application databases more closely than the UTXO model.

Its challenges include state contention, replay protection, nonce management, and more complex global-state dependencies. Two transactions involving the same account may not be safely processed independently. Privacy is also difficult because balances and account histories can be linked over time unless additional mechanisms are used.

Comparison

The UTXO model emphasizes independent spendable objects; the account model emphasizes current balances and mutable state. UTXO validation asks whether particular outputs can be consumed. Account validation asks whether a state transition is authorized and consistent with the current account state. Neither model is universally superior.

UTXO is attractive for transparent value transfer, parallel validation, and transaction-level reasoning. Account models are attractive for contract-heavy applications, asset registries, and users who need persistent identities or balances. Some systems combine both approaches, or use specialized models for different asset and contract types.

Data-model choice affects security. In an account system, incorrect nonce handling can permit replay or transaction replacement problems. In a UTXO system, poor coin selection can damage privacy by linking otherwise separate holdings. Smart-contract developers must understand the underlying model because apparently simple operations can create race conditions, unintended state dependencies, or authorization errors.

Nodes and Peer-to-Peer Networking

A node is a participant that runs blockchain software and performs one or more network functions. A full node independently verifies blocks and transactions according to protocol rules and maintains sufficient state to reject invalid history. A validating node or consensus participant has additional authority to vote, propose, or order blocks. A light client stores limited information and relies on proofs or trusted servers to obtain relevant data.

An archival node retains historical states or complete historical data, which is valuable for forensic analysis, research, explorers, and regulatory investigations. A pruned node removes data that is no longer needed for ordinary validation while retaining the information required to verify current state and recent history. Specialized nodes may provide indexing, privacy relays, bridge services, or application APIs.

Peer-to-peer networks distribute transactions and blocks without requiring every participant to communicate directly with every other participant. Nodes discover peers, establish authenticated or pseudonymous connections, propagate messages, and maintain local views of pending transactions and candidate blocks. Gossip protocols improve resilience but can produce duplicates, delays, inconsistent views, and opportunities for denial-of-service attacks.

Network security requires limits on connection counts, message sizes, bandwidth, and resource consumption. Sybil resistance is especially important in open networks, where an attacker may create many identities to influence peer selection or information flow. Permissioned networks can mitigate Sybil attacks through membership certificates, although compromised authorized identities remain dangerous.

Storage, State, and Data Availability

Blockchain storage has at least three dimensions: the historical chain, the current state, and application-specific indexes. Blocks contain transactions and metadata, while state databases enable efficient access to balances, contract storage, or unspent outputs. Merkle trees and related authenticated data structures allow a node to commit to many records using a compact root hash and to provide proofs of inclusion or exclusion.

Replication improves availability and auditability but increases storage costs. A node that stores every block and every historical state requires significant capacity and maintenance. Pruning reduces local requirements but may limit historical queries. Off-chain databases and decentralized storage systems can hold large documents, while the blockchain stores hashes, references, permissions, or settlement events.

The distinction between data integrity and data availability is essential. A hash can show that retrieved data matches a commitment, but it cannot help if no participant retains the data. Applications should therefore define retention responsibilities, backup arrangements, recovery procedures, and evidence requirements. Sensitive data should generally not be placed directly on an immutable ledger without considering deletion rights, confidentiality, and future cryptographic compromise.

Consensus, Finality, and Forks

Consensus is the process by which distributed participants agree on an accepted sequence or state. In a proof-of-work-style system, agreement is linked to accumulated computational work. In proof-of-stake systems, validators commit economic value and may be penalized for conflicting behavior. Permissioned systems may use crash fault-tolerant or Byzantine fault-tolerant protocols, often providing rapid agreement among identified validators.

Finality describes when a transaction is treated as irreversible under the protocol and its operating assumptions. Probabilistic finality means that confidence increases as additional blocks build on a transaction, but reversal remains theoretically possible. Deterministic finality means that once a protocol commits a block under specified conditions, an honest participant will not later accept a conflicting finalized block. Economic finality combines protocol rules with the cost or penalty associated with reversal.

A fork occurs when participants temporarily or permanently disagree about valid history or protocol rules. A temporary fork may result from two blocks being proposed close together; a selection rule eventually makes one branch canonical. A soft fork changes rules in a way intended to remain compatible with older validating software, whereas a hard fork introduces rules that older software may reject. Governance, upgrade coordination, and user communication are critical during protocol changes.

Applications should not assume that transaction broadcast equals settlement. They should define confirmation policies based on value, threat model, consensus type, and business urgency. A low-value retail action may tolerate probabilistic confirmation, while interbank settlement or asset transfer may require deterministic commitment and legal finality.

Interoperability Across Ledgers

Interoperability is the ability of distinct blockchain networks, conventional databases, wallets, and external services to exchange information or value with understandable security guarantees. It is not merely a matter of connecting APIs. The parties must agree on identity, message formats, asset semantics, timing, settlement, failure handling, and proof verification.

Common approaches include trusted custodial gateways, federated relays, light-client verification, hash-time-locked contracts, token representations, and decentralized bridges. These approaches differ in their trust assumptions. A custodian can be efficient but introduces counterparty risk. A multisignature federation distributes control but may still be collusive. A light-client bridge can verify another chain’s consensus evidence but may be computationally complex. A tokenized representation may not preserve the legal rights associated with the underlying asset.

A serious interoperability design specifies what happens when one chain halts, reorganizes, changes its rules, loses data, or becomes unavailable. It also addresses replay protection, message ordering, rate limits, oracle integrity, key rotation, and emergency suspension. Cross-chain systems have historically been attractive targets because they concentrate value at protocol boundaries.

Applied Case: A Consortium for Pharmaceutical Provenance

Background

Consider an illustrative case in which a pharmaceutical supply network includes manufacturers, contract packagers, distributors, hospitals, and regulators. Participants currently exchange records through separate enterprise systems. Product recalls are slow because organizations cannot quickly determine which batches passed through which facilities.

Situation and Problem

The participants require a shared history of custody events, but commercial confidentiality prevents them from publishing all shipment details on a public chain. No single company is trusted to operate the authoritative database. The system must support regulatory inspection, selective disclosure, high transaction volume, and correction of erroneous off-chain records without silently rewriting the audit history.

Analysis

A public blockchain would provide broad independent verification but would expose commercially sensitive metadata and impose unsuitable transaction costs. A single private blockchain would be efficient but would leave other organizations dependent on one operator. A consortium permissioned network is more appropriate because identified institutions can validate events under shared governance.

An account model may represent organizations, facilities, and product lots with controlled contract state. Alternatively, a UTXO-like event model could represent custody certificates that are consumed and reissued at each transfer. The choice depends on whether the dominant requirement is complex workflow state or independently verifiable transfer objects.

Approach and Solution

The consortium establishes a membership service with certificate issuance and revocation. Validators are distributed among manufacturers, distributors, and an independent regulatory body. A Byzantine fault-tolerant consensus protocol provides deterministic commitment once the required validator threshold agrees. The ledger stores event identifiers, timestamps, product references, and hashes of detailed documents. Full documents remain in controlled repositories, with access granted according to role and legal authority.

The network adopts a governance agreement covering validator admission, software upgrades, incident response, evidence retention, and dispute resolution. A public timestamping service periodically anchors a consortium state commitment, providing an external integrity reference without revealing business data. APIs connect warehouse systems to the ledger, while automated rules reject transfers involving revoked facilities or inconsistent batch states.

Outcome

The architecture improves shared visibility and reduces dependence on a single company. It does not, by itself, prove that a physical shipment was genuine or that a sensor was accurate. Those risks remain dependent on scanning procedures, hardware security, organizational controls, and audits. The system therefore combines blockchain evidence with conventional assurance mechanisms.

Learning Points

The case demonstrates that architecture follows trust and information requirements. Permissioning addresses identity but not truthfulness at the point of data entry. Off-chain storage can protect confidentiality, but retention and availability must be governed. External anchoring improves evidentiary independence without converting a private ledger into a public one. Finally, consortium governance is as important as consensus software.

Risks, Governance, and Professional Practice

Common mistakes include treating decentralization as an absolute quality, selecting a blockchain before defining the trust problem, placing sensitive personal data directly on an immutable ledger, confusing encryption with access control, and assuming that a hash proves the accuracy of source information. Organizations also underestimate node operations, key recovery, software upgrades, monitoring, and incident response.

Governance should specify participant rights, validator obligations, voting thresholds, emergency powers, audit access, liability, privacy responsibilities, and procedures for disputed transactions. In regulated sectors, immutable records can conflict with correction, deletion, localization, or confidentiality obligations. A design may need to store references rather than personal data, use encryption with carefully governed key destruction, or maintain legally authoritative records outside the chain.

Ethically, designers should consider whether transparency exposes vulnerable individuals, whether pseudonymous data can be re-identified, and whether automated rules produce unfair outcomes. Professional responsibility requires documenting assumptions, testing failure scenarios, conducting threat modelling, and communicating the limits of finality and immutability to stakeholders.

Contemporary Developments and Best Practices

Current development is moving toward modular architectures in which execution, consensus, settlement, and data availability may be separated. Rollups and other scaling approaches process activity away from a base layer while publishing proofs or commitments. Zero-knowledge techniques can support selective disclosure and validity proofs, although their operational complexity remains significant. Decentralized identity systems seek to give users control over verifiable credentials, while confidential-computing and privacy-preserving methods aim to reduce exposure of business data.

Interoperability is also becoming more standards-oriented, but bridges and cross-domain messaging remain high-risk components. Automated monitoring, formal verification, anomaly detection, and machine-assisted smart-contract analysis can improve assurance; they do not replace governance or human review.

Best practice is to begin with a threat model and a trust analysis. Define the required form of finality, data retention, privacy, and legal evidence before selecting a platform. Minimize on-chain data, separate identity from transaction records where appropriate, distribute validator authority, protect keys with strong operational controls, test upgrades and recovery, and document every external dependency. A conventional replicated database may be preferable when a trusted administrator exists and decentralized validation adds little value.

Chapter Summary

Blockchain architecture determines participation, authority, visibility, performance, and resistance to failure. Public networks provide open verification but operate in adversarial environments. Private, consortium, and permissioned systems provide stronger identity and policy control, while hybrid systems combine restricted processing with public anchoring or selective verification. The UTXO model represents state as unspent outputs and supports independent transaction reasoning; the account model represents balances and mutable contract state and is often convenient for programmable applications.

Nodes perform different roles, from full validation and consensus participation to light-client access, archival storage, indexing, and bridging. Peer-to-peer networking distributes information but introduces propagation, Sybil, and denial-of-service risks. Storage design must distinguish historical data, current state, indexes, integrity, and availability. Finality may be probabilistic, economic, or deterministic, and forks require both technical and governance responses. Interoperability must be evaluated through trust assumptions, proof mechanisms, failure handling, and asset semantics. Sound practice begins with requirements and threat modelling rather than with enthusiasm for a particular platform.

Key Terms

Blockchain architecture: The coordinated design of a blockchain’s data, network, consensus, execution, governance, and application layers.

Public blockchain: A network generally open to participation without prior institutional approval.

Private blockchain: A blockchain administered by one organization or administrative domain.

Consortium blockchain: A blockchain governed and operated by multiple organizations.

Permissioned network: A network that restricts reading, submission, validation, or other activities through authorization.

Hybrid blockchain: A system combining controlled and open characteristics or linking private processing with public verification.

UTXO: An unspent transaction output representing a currently spendable unit of ledger value.

Account model: A state model that records account balances and often contract code and storage.

Full node: A node that independently verifies protocol rules and maintains sufficient state for validation.

Light client: A client that stores limited data and uses proofs or other nodes to obtain information.

Archival node: A node retaining extensive historical blocks and states for research, audit, or investigation.

Merkle tree: A hash-based structure that efficiently commits to many records and supports inclusion proofs.

Consensus: The process by which distributed participants agree on an accepted ledger history or state.

Finality: The condition under which a transaction is treated as irreversible according to specified assumptions.

Fork: A divergence in accepted blockchain history or protocol rules.

Probabilistic finality: Finality in which reversal becomes increasingly unlikely but is not absolutely excluded.

Deterministic finality: Protocol-based finality in which a committed result cannot normally be replaced by a conflicting finalized result.

Interoperability: The capacity of separate systems to exchange data or value with defined security and semantic guarantees.

Sybil attack: An attack involving the creation of multiple false identities to influence a network.

Data availability: The continued ability of authorized parties to obtain data required to verify or use a blockchain record.

Review Questions

Short Answer Questions

1. What distinguishes a consortium blockchain from a private blockchain?

2. What is the current ledger state in a UTXO model?

3. Why are light clients useful in blockchain systems?

4. Differentiate probabilistic and deterministic finality.

5. Why does a cryptographic hash not prove the truthfulness of source data?

Long Answer Questions

1. Compare public, private, consortium, permissioned, and hybrid blockchain architectures using trust, governance, privacy, and performance as criteria.

2. Explain the UTXO and account models and analyse their consequences for validation, privacy, wallets, and smart contracts.

3. Describe the roles of different node types and explain how peer-to-peer propagation affects security and reliability.

4. Discuss blockchain storage, state databases, Merkle structures, pruning, archival requirements, and data availability.

5. Explain finality and forks, including their implications for application design, governance, and transaction settlement.

Analytical / Application Questions

1. A group of banks needs confidential settlement, independent validation by participating institutions, and rapid deterministic finality. Which architecture and consensus characteristics would you recommend, and why?

2. An organization wants to publish proof that its private audit records existed at a certain time without revealing the records. Design a hybrid approach and identify its limitations.

3. A cross-chain bridge transfers valuable assets but depends on a small federation of signing entities. Analyse its main trust and failure risks and propose safeguards.

22. Multiple Choice Questions with Answers

Question 1

Which architectural characteristic most clearly distinguishes a consortium blockchain from a single-organization private blockchain?

A. It uses no cryptography

B. It is governed by multiple participating organizations

C. It must permit anonymous validation

D. It cannot restrict membership

Correct Answer: B. It is governed by multiple participating organizations

Question 2

In a UTXO-based system, a validator primarily checks whether an input refers to an output that is

A. Stored in a user’s account database

B. Already included in two previous transactions

C. Unspent and satisfies its spending condition

D. Approved by every network user

Correct Answer: C. Unspent and satisfies its spending condition

Question 3

Which feature is generally associated more directly with an account model than with a basic UTXO model?

A. Persistent contract storage associated with an address

B. Consumption of discrete transaction outputs

C. Input and output coin selection

D. Independent validation of separate outputs

Correct Answer: A. Persistent contract storage associated with an address

Question 4

What is the principal function of a full node?

A. To issue legal identities to all users

B. To independently verify transactions and blocks under protocol rules

C. To store only its own wallet balance

D. To replace the consensus protocol with a database administrator

Correct Answer: B. To independently verify transactions and blocks under protocol rules

Question 5

Which statement best describes probabilistic finality?

A. A transaction is final before it is broadcast

B. Reversal becomes less likely as additional confirming blocks are added

C. A regulator can reverse any transaction automatically

D. All validators must be legally identified

Correct Answer: B. Reversal becomes less likely as additional confirming blocks are added

Question 6

A company stores confidential documents off-chain and records their hashes on a permissioned ledger. What does the hash primarily demonstrate?

A. That the documents are factually accurate

B. That the documents are legally admissible in every jurisdiction

C. That retrieved documents correspond to the committed data

D. That the documents will remain available forever

Correct Answer: C. That retrieved documents correspond to the committed data

Question 7

Why can a public blockchain be unsuitable for confidential supply-chain data?

A. Public blockchains cannot use digital signatures

B. Public visibility may reveal commercially sensitive metadata

C. Public blockchains cannot record timestamps

D. Public blockchains always provide deterministic finality

Correct Answer: B. Public visibility may reveal commercially sensitive metadata

Question 8

Which issue is especially important when designing a cross-chain bridge?

A. Whether the bridge’s trust and proof assumptions remain valid if one chain reorganizes

B. Whether all users use identical passwords

C. Whether blocks contain no hashes

D. Whether the bridge eliminates the need for key management

Correct Answer: A. Whether the bridge’s trust and proof assumptions remain valid if one chain reorganizes

Question 9

A permissioned network’s membership service is compromised. What capability could an attacker most directly obtain?

A. The ability to create or authorize identities improperly

B. Automatic control of every public blockchain

C. The ability to remove cryptography from all blocks

D. Guaranteed access to users’ private keys

Correct Answer: A. The ability to create or authorize identities improperly

Question 10

Which situation most strongly suggests that a conventional replicated database may be preferable to a blockchain?

A. Several mutually distrustful institutions require shared validation

B. An open network needs censorship resistance

C. One trusted administrator controls the data and no decentralized validation is required

D. Independent parties need externally verifiable settlement

Correct Answer: C. One trusted administrator controls the data and no decentralized validation is required