Blockchain Origins, Principles and Terminology

Introduction and context

Blockchain is best understood not as a single product but as a family of techniques for maintaining a shared, tamper-evident record among parties that may not fully trust one another. Its significance lies in combining several earlier ideas: cryptography, peer-to-peer networking, distributed systems, digital signatures, electronic money, and consensus protocols.

A conventional database normally assumes that an organisation controls the system, determines who may write data, and can correct or replace records under an established governance process. A blockchain distributes control across multiple participants and makes historical alteration difficult to conceal. This does not make every blockchain “trustless,” perfectly immutable, anonymous, or universally superior to a database. Rather, it changes where trust is placed: from a single administrator toward protocols, economic incentives, cryptographic verification, software rules, and a network of participants.

The subject is important because blockchain systems now support cryptocurrencies, tokenised assets, decentralised finance, supply-chain records, digital identity experiments, settlement systems, and programmable applications commonly associated with Web3. An informed professional must therefore understand both their capabilities and their limitations.

Learning objectives

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

1. Explain the historical development from digital cash and distributed computing to blockchain.
2. Define blocks, nodes, ledgers, transactions, tokens, wallets, protocols, decentralisation, immutability, trust, and Web3.
3. Describe how cryptographic hashes, digital signatures, peer-to-peer replication, and consensus work together.
4. Distinguish permissionless, permissioned, and consortium blockchains.
5. Compare blockchains with conventional databases using technical and governance criteria.
6. Evaluate an appropriate blockchain use case and identify its risks, limitations, and governance requirements.

From digital cash to blockchain

The problem of digital scarcity

Physical cash can be transferred because possession is observable: handing over a banknote generally removes it from the sender and gives it to the recipient. Digital information can be copied perfectly. A digital payment system must therefore prevent a user from spending the same digital representation more than once. This is the “double-spending problem.”

Traditional electronic payments solve this problem through trusted intermediaries. A bank or payment processor maintains authoritative account balances, authenticates users, validates transactions, and reverses or investigates errors. The model is efficient, but it concentrates authority and creates dependencies on institutions, legal systems, operating procedures, and cybersecurity controls.

Early digital-cash research

During the late twentieth century, researchers proposed cryptographic forms of electronic cash. David Chaum’s work on blind signatures demonstrated how payment instruments could be issued by a bank while reducing the bank’s ability to link a payment to the original withdrawal. Other systems explored proof-of-work, anonymous credentials, and distributed agreement.

These projects established important components but faced practical challenges, including reliance on issuers, limited infrastructure, legal uncertainty, key management, and difficulty achieving decentralised agreement at scale. They nevertheless contributed concepts later used in blockchain systems.

Distributed computing and fault tolerance

Distributed computing studies how independent computers communicate and coordinate when messages may be delayed, machines may fail, or participants may behave maliciously. A distributed ledger is therefore not simply a file copied to several computers. The participants must agree on:

• which transactions are valid;
• the order in which transactions are recorded;
• which version of the ledger is authoritative; and
• how the system responds to failures or conflicting messages.

The Byzantine Generals Problem is a conceptual model for agreement when some participants may be faulty or deceptive. Byzantine fault-tolerant protocols seek agreement despite such behaviour, subject to assumptions about network conditions and the proportion of honest participants. Classical results show that agreement becomes impossible in some asynchronous settings if too many participants are malicious; practical systems therefore use timing assumptions, membership rules, cryptographic identities, or economic incentives.

Bitcoin and the modern blockchain

In 2008, the Bitcoin white paper proposed a peer-to-peer electronic cash system using a chain of blocks, proof-of-work, public-key signatures, and economic incentives. The design allowed participants to agree on transaction history without a central clearing institution, provided that honest computational power outweighed the attacker’s ability to rewrite history under the model’s assumptions.

Bitcoin did not invent every underlying component. Its important contribution was the integration of existing ideas into a public, permissionless system with an incentive mechanism and a practical method for ordering transactions. Later platforms, especially Ethereum, extended the model by supporting general-purpose smart contracts and programmable tokens.

The core architecture

A blockchain system can be analysed through four interacting layers:

1. Data layer: transactions, blocks, hashes, timestamps, and state representations.
2. Network layer: peer-to-peer communication and propagation of transactions and blocks.
3. Consensus layer: rules by which participants select a valid common history.
4. Application and governance layer: wallets, exchanges, smart contracts, user interfaces, legal arrangements, and software upgrades.

A weakness in any layer can undermine the system. For example, strong cryptography cannot compensate for a fraudulent smart contract, and a technically sound protocol may still fail if users lose their private keys.

Figure: The principal layers of a blockchain system. The layers interact rather than operating independently.

Essential terminology and mechanisms

Ledger and state

A ledger is a record of transactions or ownership claims. In a blockchain, the ledger is replicated across participating nodes. Some systems use an account model, in which addresses have balances and contract storage. Others use an unspent transaction output (UTXO) model, in which transactions consume previous outputs and create new outputs. Both models can represent ownership, but their validation and programming patterns differ.

State means the current condition represented by the ledger: for example, balances, smart-contract storage, or ownership records. A transaction proposes a state transition. Nodes independently execute validation rules before accepting that transition.

Transactions

A transaction is a signed instruction or data record submitted to the network. It may transfer value, invoke a smart contract, create a token, or record information. A transaction generally includes a sender reference, recipient or contract reference, data, a nonce or input reference, and a fee or resource payment, although exact fields vary by protocol.

A transaction is not necessarily final when first broadcast. It may be pending, included in a block, confirmed by subsequent blocks, or regarded as final under the protocol’s finality rule.

Blocks and chains

A block is a container of transactions and metadata. Typical metadata includes a reference to the previous block, a time indication, a commitment to the transactions, and consensus-related information. The previous-block reference creates a chronological chain. If data in an earlier block changes, its cryptographic commitment changes and the inconsistency becomes detectable in later blocks.

A cryptographic hash maps input data to a fixed-length output. In simplified notation:

Here, m is the message, H is a specified hash function, and h is the digest. A secure cryptographic hash is designed to make it computationally infeasible to find a different message with the same digest or to recover the original message from the digest. Hashes provide integrity evidence, not proof that the underlying information is truthful.

Many blockchains use a Merkle tree to summarise a set of transactions. Transaction hashes are combined pairwise until one root hash remains. If a transaction changes, the root changes. A Merkle proof can demonstrate that a transaction belongs to a committed set without transmitting the entire block.

Nodes and network roles

A node is a computer running blockchain software and participating in the network. Roles differ by protocol:

• A full node independently validates blocks and transactions and stores sufficient data to enforce the rules.
• A validator or miner participates in proposing or confirming blocks, depending on the consensus mechanism.
• A light client verifies selected information while relying on fuller nodes for some data.
• An archival node retains historical state or data needed for specialised queries.

The word “node” should not be treated as synonymous with “validator.” A node may validate without proposing blocks, and a block producer may operate several nodes.

Keys, addresses, and wallets

Public-key cryptography uses a key pair. A private key is secret and authorises actions; a public key can be shared for verification. An address is usually a protocol-specific identifier derived from a public key or smart-contract information. A wallet is software or hardware that manages keys and prepares transactions. The wallet does not literally contain coins on the device; the ledger records the relevant state, while the wallet controls credentials capable of authorising changes.

Key loss can mean permanent loss of control. Key theft can enable unauthorised transfers that are technically valid. Good practice includes secure backups, hardware protection for high-value keys, separation of duties, multi-signature approval, and tested recovery procedures.

Tokens

A token is a digitally represented unit governed by a blockchain protocol or smart contract. Tokens may represent native network value, utility, voting rights, claims on assets, access rights, or financial instruments. A token’s technical existence does not automatically establish legal ownership of an off-chain asset. The connection between a token and a real-world claim requires reliable custody, governance, contractual rights, and applicable law.

Common categories include:

Protocols and smart contracts

A protocol is a set of rules governing data formats, validation, communication, consensus, and state transitions. A protocol may be implemented by several independent software clients. A smart contract is program code deployed on a blockchain that executes when valid transactions invoke it. Smart contracts can automate rules, but they cannot independently guarantee the truth of external facts. Oracles, which supply external data, create an additional trust and security boundary.

Code is not the same as law. A contract may be technically executable yet legally defective, economically exploitable, or inconsistent with consumer-protection requirements.

Consensus, decentralisation, and finality

Consensus mechanisms

Consensus is the process by which a network selects an accepted history and determines valid state transitions. Two major families illustrate different trade-offs.

Proof of Work (PoW) selects block producers through computational work. Participants expend energy to solve a difficult puzzle, and the chain with the greatest accumulated work is generally preferred under the protocol. Rewriting history requires repeating relevant work and competing with honest participants. PoW provides open participation but may consume substantial energy and can have probabilistic confirmation.

Proof of Stake (PoS) selects or weights validators according to staked assets, usually with penalties for certain dishonest or negligent behaviour. PoS can reduce direct energy expenditure, but introduces complexities involving stake concentration, validator selection, slashing, governance, and correlated failures.

Permissioned systems may use practical Byzantine fault-tolerant or crash-fault-tolerant protocols in which known organisations take part. Such systems can achieve rapid deterministic finality under stated assumptions, but they are not equivalent to open, censorship-resistant public networks.

Finality

Probabilistic finality means that confidence increases as additional blocks are added, but a sufficiently powerful reorganisation remains theoretically possible. Deterministic or economic finality means that protocol rules make reversal impossible or prohibitively costly after a defined event, subject to assumptions about honest validators, cryptographic security, and governance.

“Immutable” should therefore be used carefully. A blockchain is generally tamper-evident and resistant to unauthorised alteration. Records can still be affected by private-key compromise, protocol bugs, majority attacks, social coordination, software upgrades, legal orders, or incorrect input data.

Decentralisation

Decentralisation has several dimensions:

• Architectural: data and validation are distributed across machines.
• Political: control is distributed among people or organisations.
• Logical: the system behaves as one coherent system despite many components.
• Economic: no small group controls essential resources or validation power.

A network can be technically distributed but politically centralised if a few firms control validators, development, infrastructure, or access. Decentralisation is thus a matter of degree and must be assessed using measurable indicators such as validator concentration, client diversity, governance participation, infrastructure dependence, and barriers to entry.

Trust, transparency, privacy, and Web3

Blockchain does not eliminate trust; it redistributes and formalises it. Participants may trust cryptographic verification for signatures, consensus rules for ordering, software developers for implementation, validators for operation, or legal institutions for off-chain enforcement. The relevant question is not “Is it trustless?” but “Which parties and assumptions must be trusted, and what mechanisms constrain them?”

Public blockchains may provide transparent transaction histories while offering weak privacy. Addresses are often pseudonymous rather than anonymous. Transaction patterns, exchange records, network metadata, and external identity information can enable analysis. Privacy technologies may include zero-knowledge proofs, confidential transactions, mixers, secure computation, or privacy-preserving identity systems, each with technical, regulatory, and usability trade-offs.

Web3 is a broad, contested term describing an internet architecture in which users may control digital assets or identities through cryptographic keys and interact with decentralised protocols. Its proposed characteristics include user-owned assets, composable applications, programmable incentives, and reduced dependence on central platforms. In practice, many Web3 applications still rely on centralised exchanges, cloud hosting, front-end interfaces, oracle providers, bridge operators, and custodians. The term should therefore be analysed as an architectural aspiration, not treated as a guarantee.

Blockchain versus conventional databases

A blockchain and a database can both store records, support queries, and enforce constraints. The decisive differences concern governance, write authority, replication, and conflict resolution.

A blockchain is not justified merely because several departments need shared data. A conventional database with replicated backups may be better when one accountable organisation exists, high performance is essential, data must be deleted routinely, or confidentiality is dominant. Blockchain becomes more plausible when multiple parties need a shared record, no party should unilaterally control it, participants require independently verifiable history, and the benefits exceed consensus and governance costs.

A useful decision test is:

1. Are there multiple writers or organisations?
2. Do they lack a fully trusted common administrator?
3. Is a shared transaction history more valuable than editable records?
4. Can the required data be represented without violating privacy or deletion obligations?
5. Can governance, identity, recovery, and dispute resolution be specified?

If most answers are negative, a conventional database is often preferable.

Applied case: a permissioned pharmaceutical supply-chain ledger

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

Background

A pharmaceutical supply chain involves manufacturers, logistics providers, wholesalers, pharmacies, and regulators. Each organisation maintains its own records. Product identifiers may be duplicated, shipment events may be delayed, and participants may dispute where a package entered or left the chain.

Problem

The industry needs a shared history of custody events while protecting commercially sensitive information. A single manufacturer-controlled database would face resistance because competitors would not want one firm to control the authoritative record.

Analysis

The use case has multiple independent writers and a need for consistent provenance. However, not every fact can be verified by software. A sensor may report a temperature, but the sensor can be miscalibrated; a participant may enter a false shipment event; and legal responsibility remains an institutional question. The design therefore needs identity management, audit procedures, data standards, privacy controls, and dispute processes in addition to a ledger.

Approach and solution

A consortium could operate a permissioned blockchain. Approved organisations receive cryptographic identities. Each custody event contains a product identifier, event type, time, location category, and digital signature. Sensitive commercial details are stored off-chain, while the ledger stores hashes or permission-controlled references. Smart-contract rules reject malformed events and require appropriate authorisation. Regulators receive read access or validated reporting interfaces.

Consensus among approved members provides a shared record without requiring energy-intensive public mining. A governance agreement specifies validator admission, software upgrades, incident response, key recovery, data retention, and responsibility for erroneous input. Periodic audits compare physical inventory and ledger events.

Outcome

The proposed system improves traceability and reduces reconciliation between organisations. It does not prove that a product is genuine merely because an event is on-chain. Its value depends on accurate product identities, trustworthy participants, secure devices, usable interfaces, and effective governance.

Learning points

1. A blockchain addresses inter-organisational coordination, not every supply-chain problem.
2. Permissioned does not mean risk-free; members and administrators remain trust points.
3. On-chain integrity cannot correct false off-chain data.
4. Privacy, legal accountability, and recovery must be designed from the beginning.
5. A database may still be appropriate for internal operational records.

Limitations, risks, and governance

Technical limitations

Scalability is constrained by the need for nodes to communicate, validate, and sometimes replicate data. Increasing block capacity may reduce fees but raise hardware and centralisation pressures. Cross-chain bridges can create concentrated points of failure. Smart-contract vulnerabilities may cause irreversible losses. Software clients can disagree because of bugs or implementation differences.

Economic and operational risks

Token prices may be volatile. Fees can rise during congestion. Governance may be captured by wealthy stakeholders, large validators, or influential developers. Users may misunderstand custody arrangements or approve malicious transactions. Recovery from key loss is difficult unless explicit social, institutional, or technical recovery mechanisms exist.

Legal and ethical issues

Relevant issues include consumer protection, securities or financial-services regulation, anti-money-laundering obligations, sanctions compliance, taxation, data protection, intellectual property, and jurisdiction. Publicly recording personal data may conflict with minimisation or erasure requirements. The safer design is often to keep personal data off-chain and store only a carefully governed reference or cryptographic commitment.

Ethically, designers should evaluate accessibility, energy use, surveillance potential, unequal governance power, environmental impacts, and the consequences of irreversible mistakes. “Code is law” is an inadequate ethical framework because people remain affected by software and require legitimate processes for redress.

Best practices

• Define the problem and compare blockchain with a database before selecting technology.
• Specify threat models, trust assumptions, failure modes, and finality requirements.
• Keep sensitive or mutable personal data off-chain where appropriate.
• Use established cryptographic libraries and independent security audits.
• Apply least privilege, multi-signature controls, hardware-backed keys, and tested backups.
• Separate protocol governance, application governance, and legal accountability.
• Monitor validator concentration, client diversity, bridge exposure, and operational incidents.
• Design user interfaces that clearly distinguish addresses, fees, permissions, and irreversible actions.
• Document upgrade procedures, dispute resolution, emergency powers, and decommissioning.

Contemporary developments

Current blockchain engineering increasingly combines rollups and other layer-two systems, zero-knowledge proofs, tokenised real-world assets, decentralised identity, and interoperable messaging. These developments may improve scalability or privacy, but they also introduce new assumptions. A rollup may depend on operators or data availability; a tokenised asset depends on custodians and legal enforceability; an identity system may create surveillance risks; and interoperability can expand the attack surface.

Artificial intelligence is relevant mainly as an adjacent tool. AI can assist anomaly detection, contract review, transaction classification, and user support. It does not replace consensus, cryptographic key management, or legal governance. AI-generated code can contain vulnerabilities, and automated decisions require auditability, human oversight, and protection against biased or adversarial data.

Chapter Summary

Blockchain developed from research into digital cash, cryptography, peer-to-peer networking, and distributed agreement. Its distinctive contribution is a protocol-coordinated ledger that allows multiple participants to maintain a common history without relying entirely on one central administrator. Blocks connect transactions through cryptographic commitments; nodes validate and replicate data; wallets manage keys; tokens represent protocol-defined units; and consensus determines accepted history.

Decentralisation is multidimensional, immutability is a qualified property, and blockchain does not remove trust. Public, permissioned, and consortium systems make different trade-offs among openness, performance, privacy, governance, and finality. Compared with conventional databases, blockchains are most valuable where independent parties require a shared, independently verifiable history and no single party should control it. They are less appropriate where a trusted administrator exists, high performance and private editing are essential, or regulatory and recovery requirements cannot be met.

Professional blockchain practice therefore requires more than understanding tokens or wallets. It requires threat modelling, governance, privacy design, key security, legal analysis, and disciplined comparison with simpler technologies.

Key Terms

Blockchain: A protocol-governed, cryptographically linked record of transactions or state transitions.

Block: A validated container of transactions and metadata.

Node: A computer participating in blockchain communication, validation, storage, or block production.

Ledger: A record of ownership, transactions, or state.

Transaction: A signed instruction or record proposing a state change.

Hash: A fixed-length digest generated from input data by a cryptographic hash function.

Merkle tree: A hash structure that commits efficiently to a collection of data.

Consensus: The process for agreeing on valid state and transaction history.

Proof of Work: Consensus based on computational effort.

Proof of Stake: Consensus involving selected or weighted staked validators.

Finality: The point or confidence level at which a transaction is treated as irreversible.

Wallet: Software or hardware that manages cryptographic keys and prepares transactions.

Private key: Secret credential used to authorise cryptographic actions.

Token: A protocol-defined digital representation of value, rights, or access.

Smart contract: Blockchain-deployed code that executes according to protocol rules.

Protocol: Rules governing communication, validation, consensus, and state transitions.

Decentralisation: Distribution of technical, political, logical, or economic control.

Immutability: Resistance to unnoticed or unauthorised historical alteration, subject to assumptions.

Web3: A broad vision of user-controlled, asset-aware, and decentralised internet services.

Oracle: A mechanism that supplies external data to a blockchain application.

Review Questions

Short Answer Questions

1. What is the double-spending problem, and how do traditional payment systems address it?
2. Distinguish a blockchain node from a validator or miner.
3. Why does changing an earlier block make later inconsistencies detectable?
4. What is the difference between a private key and a wallet?
5. Why is blockchain immutability a qualified rather than absolute property?

Long Answer Questions

1. Explain the historical path from digital cash research and distributed computing to Bitcoin and programmable blockchains.
2. Compare Proof of Work and Proof of Stake in terms of participation, security assumptions, resource use, and governance.
3. Explain how cryptographic hashes, digital signatures, networking, and consensus interact in a blockchain system.
4. Compare a conventional database and a permissionless blockchain for a multi-organisation business process.
5. Discuss why blockchain does not eliminate trust, using examples from smart contracts, oracles, validators, and legal institutions.

Analytical / Application Questions

1. A university wants to store student records on a public blockchain. Analyse the privacy, governance, correction, and legal issues, and recommend an alternative architecture if appropriate.
2. Several competing logistics firms need a shared record of custody events but do not want one firm to control it. Design a high-level permissioned blockchain solution and identify at least five non-technical governance requirements.
3. A token claims to represent ownership of gold held by a custodian. Analyse which claims are guaranteed by blockchain code and which depend on off-chain custody, auditing, contracts, and regulation.

Multiple Choice Questions with Answers

Question 1

Which problem is central to digital cash systems?

A. Preventing all network delays

B. Preventing double spending

C. Eliminating the need for passwords

D. Increasing database edit permissions

Correct Answer: B. Preventing double spending

Question 2

What is the primary function of a cryptographic hash in a blockchain?

A. To prove that real-world data is truthful

B. To encrypt data so no one can read it

C. To provide a tamper-evident commitment to data

D. To assign legal ownership of an asset

Correct Answer: C. To provide a tamper-evident commitment to data

Question 3

What does a wallet primarily manage?

A. Physical coins stored on the device

B. Cryptographic keys and transaction creation

C. All copies of the blockchain worldwide

D. The legal identity of every network participant

Correct Answer: B. Cryptographic keys and transaction creation

Question 4

Which statement best describes a blockchain transaction?

A. It is always final immediately after broadcast

B. It is a signed instruction or record proposing a state change

C. It is necessarily a transfer of a government currency

D. It cannot invoke program code

Correct Answer: B. It is a signed instruction or record proposing a state change

Question 5

Which consensus mechanism selects block producers using computational work?

A. Proof of Work

B. Proof of Stake

C. Role-based access control

D. Database replication

Correct Answer: A. Proof of Work

Question 6

Why may a conventional database be preferable to a blockchain?

A. A database can never be replicated

B. A database is appropriate when one accountable administrator exists and efficient editing is required

C. A blockchain cannot store any transaction data

D. A database automatically provides public transparency

Correct Answer: B. A database is appropriate when one accountable administrator exists and efficient editing is required

Question 7

What does decentralisation refer to in blockchain analysis?

A. Only the physical size of data centres

B. The distribution of control across relevant technical, political, or economic dimensions

C. The removal of all governance

D. The use of a single central administrator

Correct Answer: B. The distribution of control across relevant technical, political, or economic dimensions

Question 8

Which statement about blockchain immutability is most accurate?

A. On-chain data can never be affected by any event

B. Immutability means resistance to unnoticed or unauthorised alteration under stated assumptions

C. Immutability guarantees that input data is accurate

D. Immutability makes private-key theft impossible

Correct Answer: B. Immutability means resistance to unnoticed or unauthorised alteration under stated assumptions

Question 9

In the pharmaceutical supply-chain case, why might sensitive details be stored off-chain?

A. Because hashes cannot be calculated for documents

B. To reduce privacy and commercial-confidentiality risks

C. Because permissioned blockchains cannot authenticate users

D. To prevent any participant from validating events

Correct Answer: B. To reduce privacy and commercial-confidentiality risks

Question 10

What is a major trust boundary when a smart contract uses an external price feed?

A. The oracle supplying the external data

B. The block’s font size

C. The wallet’s screen brightness

D. The number of transaction fields displayed to a user

Correct Answer: A. The oracle supplying the external data