Core Technology

How Blockchain Technology Works

A comprehensive, objective overview of the technical building blocks behind distributed ledger systems. From hash functions to consensus algorithms, we explain the architecture layer by layer.

25 min read Last updated: 8 Mar 2026 Expert-reviewed

Distributed Ledger Fundamentals 📒

A distributed ledger is a database that is shared, replicated, and synchronised across multiple sites, institutions, or geographies. Unlike a traditional centralised database managed by a single administrator, a distributed ledger has no central data store or administration functionality.

Each participant, or "node," in the network maintains its own identical copy of the ledger. When a new transaction occurs, the update is propagated across all copies through a peer-to-peer protocol. This replication means there is no single point of failure, and the system can continue operating even if some nodes go offline.

Blockchain is one specific type of distributed ledger technology (DLT). It organises data into sequential, cryptographically linked blocks. However, not all distributed ledgers use a block-chain structure. Directed acyclic graphs (DAGs) and hashgraph are alternative DLT architectures that organise data differently.

The key properties of distributed ledger systems include transparency (participants can verify records), immutability (past records are extremely difficult to alter), and decentralisation (no single entity controls the entire system). These properties make DLT suitable for applications where trust between parties needs to be established without relying on a central authority.

Cryptography

Cryptographic Primitives 🔐

Blockchain systems rely on several well-established cryptographic techniques to ensure data integrity, authentication, and non-repudiation.

Hash Functions

A cryptographic hash function takes an input of any length and produces a fixed-length output (the "hash" or "digest"). SHA-256, used in many blockchain systems, always produces a 256-bit output regardless of whether the input is a single character or an entire novel.

Hash functions have three critical properties for blockchain: they are deterministic (same input always produces the same hash), they are one-way (you cannot reverse-engineer the input from the output), and any tiny change to the input produces a completely different hash. This last property, known as the avalanche effect, is what makes tampering with blockchain records detectable.

Public-Key Cryptography

Also called asymmetric cryptography, this system uses a pair of mathematically related keys: a public key (shared openly) and a private key (kept secret). A message encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. Blockchain uses this to verify ownership and authorise transactions without revealing sensitive credentials.

Digital Signatures

A digital signature is created by hashing a message and then encrypting that hash with the sender's private key. Anyone with access to the sender's public key can verify that the signature is authentic and that the message has not been altered. This is how blockchain nodes confirm that a transaction was genuinely authorised by the account holder.

Merkle Trees

A Merkle tree (or hash tree) is a data structure in which every leaf node is labelled with the hash of a data block, and every non-leaf node is labelled with the hash of its child nodes. This enables efficient and secure verification of large datasets, as any change to a single transaction alters the root hash, making inconsistencies immediately detectable.

Zero-Knowledge Proofs

A zero-knowledge proof allows one party to prove to another that a statement is true without revealing any information beyond the validity of the statement itself. Some blockchain protocols use zero-knowledge proofs to enhance privacy, allowing transaction verification without disclosing the transaction details.

Agreement

Consensus Mechanisms ⚖️

Since no single authority governs a blockchain, participants must agree on the state of the ledger through a consensus mechanism. These protocols define how nodes validate transactions and add new blocks.

Proof of Work (PoW)

Compute-intensive

In Proof of Work, network participants (often called "miners") compete to solve a computationally difficult mathematical puzzle. The first to find a valid solution earns the right to add the next block to the chain. The difficulty of the puzzle is calibrated so that new blocks are produced at a roughly consistent interval.

The energy expenditure required to solve the puzzle serves as a cost barrier that discourages dishonest behaviour. To alter a historical block, an attacker would need to redo the computational work for that block and every subsequent block, requiring an impractical amount of computing power.

Key consideration: PoW is criticised for its energy consumption. Some estimates suggest that large PoW networks consume as much electricity as medium-sized countries. This has prompted research into more energy-efficient alternatives.

Proof of Stake (PoS)

Energy-efficient

In Proof of Stake, validators are selected to create the next block based on the amount of tokens they have committed (or "staked") as collateral. Rather than competing with computational power, validators are chosen through an algorithm that typically factors in the stake size and, in some implementations, the age of the stake.

If a validator attempts to include fraudulent transactions, they risk losing their staked tokens through a process known as "slashing." This economic penalty serves as the primary deterrent against dishonest behaviour.

Key consideration: PoS significantly reduces energy requirements compared to PoW. However, critics note that it may favour participants who already hold large amounts of the network's tokens, potentially leading to concentration of influence.

Delegated Proof of Stake (DPoS)

Democratic

DPoS introduces a democratic element where token holders vote to elect a limited number of delegates who are responsible for validating transactions and producing blocks. This approach can increase transaction throughput since fewer nodes are involved in consensus. However, the trade-off is a degree of centralisation, as block production is concentrated among the elected delegates.

Byzantine Fault Tolerance (BFT)

Fault-tolerant

BFT-based consensus protocols are designed to function correctly even when some nodes in the network are behaving maliciously or have failed. Named after the "Byzantine Generals' Problem" from computer science literature, these algorithms typically require that at least two-thirds of participants behave honestly. Practical BFT (pBFT) and Tendermint are well-known implementations used in various permissioned and public blockchain networks.

Structure

Anatomy of a Block 🧱

Each block in a blockchain contains specific data components that together ensure the integrity and continuity of the chain.

Block Header

The header contains metadata about the block: a timestamp, the hash of the previous block (linking it to its predecessor), the Merkle root of all transactions in the block, a nonce value (in PoW systems), and the current difficulty target. The header is what gets hashed to produce the block's unique identifier.

Transaction Data

The body of the block contains a list of validated transactions. Each transaction typically includes the sender's public key, the recipient's address, the amount or data being transferred, and a digital signature. The number of transactions per block varies by protocol and is constrained by the block size limit.

Previous Block Hash

Every block stores the cryptographic hash of its predecessor. This backward reference is what creates the "chain" in blockchain. If an attacker were to modify a transaction in a historical block, the hash of that block would change, breaking the link with the next block and every block thereafter. The entire network would immediately recognise the inconsistency.

Merkle Root

The Merkle root is the single hash at the top of a Merkle tree that summarises all the transactions in the block. It allows any node to verify whether a specific transaction is included in the block without downloading the entire transaction list, a process known as Simplified Payment Verification (SPV). This is particularly important for lightweight clients running on devices with limited storage.

Simplified diagram of block components and their relationships within a blockchain.

Programmable Logic

Smart Contracts 📜

The term "smart contract" was coined by computer scientist Nick Szabo in 1994. In the blockchain context, a smart contract is a programme stored on the blockchain that executes automatically when predefined conditions are met. Think of it as a set of digital "if/then" statements that run without the need for a middleman.

Smart contracts are typically written in domain-specific programming languages. Solidity is the most widely used language for Ethereum-compatible networks, while other platforms use Rust, Move, or Vyper. Once deployed, the contract's code is visible on the blockchain and cannot be modified, which is why thorough auditing before deployment is a standard practice.

Common applications include escrow services, where funds are released automatically upon delivery confirmation; insurance protocols, where claims are processed based on verifiable data feeds; and supply chain tracking, where ownership records are updated as goods change hands.

Limitations to Consider

Smart contracts can only act on data available on the blockchain. To interact with external data (weather, stock prices, delivery status), they rely on "oracles," which are third-party services that feed off-chain data into the blockchain. The reliability of the oracle directly affects the reliability of the contract.

Networks

Types of Blockchain Networks 🌐

Blockchain networks are broadly categorised by who can participate and how access is managed. Each type has distinct trade-offs between decentralisation, performance, and control.

Public Blockchains

Open to anyone. No permission is required to join, read data, submit transactions, or participate in consensus. Bitcoin and Ethereum are prominent examples.

Fully decentralised and censorship-resistant
Transparent: all transactions are publicly auditable
Typically slower throughput due to consensus overhead

Private Blockchains

Operated by a single organisation that controls who can join. Access to read or write data is restricted. Hyperledger Fabric is a well-known framework for private blockchain deployments.

Higher performance and transaction speed
Granular access controls for sensitive data
More centralised, relies on a trusted operator

Consortium Blockchains

Governed by a group of organisations rather than a single entity. Multiple pre-selected nodes share consensus responsibilities. R3 Corda and the Energy Web Chain are examples.

Shared governance among known participants
Balances privacy with multi-party verification
Requires coordination and agreement among members

Web3

Web3 Protocols and the Decentralised Web 🕸️

Web3 refers to a vision of the internet in which services and platforms run on decentralised infrastructure rather than centralised servers controlled by a few large companies. The idea is that users maintain ownership of their own data and digital identities.

Decentralised applications (often abbreviated dApps) are programmes that run on peer-to-peer networks rather than a single server. They interact with blockchain networks through smart contracts, and their front-end interfaces can be hosted on decentralised storage systems like IPFS (InterPlanetary File System).

Key infrastructure layers of the Web3 stack include consensus protocols (discussed above), data storage solutions (Filecoin, Arweave), naming systems (ENS for human-readable addresses), and communication protocols for node-to-node messaging. Each layer aims to replace a centralised counterpart with a distributed alternative.

It is worth noting that Web3 remains an active area of development. Many proposed systems are still experimental, and technical challenges around user experience, scalability, and regulatory compliance continue to be discussed within the technology community.

Web3 Stack

Scalability

Scalability Challenges 📈

The "blockchain trilemma," a concept popularised by Ethereum co-founder Vitalik Buterin, suggests that blockchain systems can optimise for at most two out of three properties: decentralisation, security, and scalability.

The Trilemma

Decentralisation

No single point of control. Thousands of independent nodes validate transactions.

Security

Resistance to attacks and data manipulation through cryptographic guarantees.

Scalability

Ability to handle a growing number of transactions without degradation of speed.

Proposed Solutions

Layer 2 Solutions

Secondary protocols built on top of a main blockchain that process transactions off-chain and periodically settle them on the main chain. Examples include rollups (optimistic and zero-knowledge) and state channels. These can significantly increase throughput without altering the base protocol.

Sharding

Dividing the blockchain network into smaller partitions ("shards"), each capable of processing its own transactions and smart contracts in parallel. This distributes the computational load across the network rather than requiring every node to process every transaction.

Alternative Data Structures

Some projects have moved beyond the traditional linear blockchain to structures like directed acyclic graphs (DAGs), where multiple transactions can be confirmed simultaneously, enabling higher theoretical throughput.

Security

Security Considerations 🛡️

While blockchain is designed to be tamper-resistant, no technology is entirely without risk. Understanding potential vulnerabilities helps contextualise the technology's strengths and limitations.

51% Attacks

If a single entity gains control of more than half the network's computing power (in PoW) or staked tokens (in PoS), it could theoretically rewrite recent blocks. Larger, more established networks are less susceptible due to the prohibitive cost of accumulating such resources.

Smart Contract Vulnerabilities

Bugs in smart contract code can be exploited if not caught before deployment. Since deployed contracts are generally immutable, vulnerabilities cannot simply be "patched." This underscores the importance of rigorous testing, formal verification, and independent audits during development.

Key Management

Blockchain security depends on users safeguarding their private keys. If a private key is lost or stolen, access to associated assets and accounts is typically unrecoverable. This places a significant responsibility on individual users and has driven development of multi-signature schemes and hardware security modules.

Social Engineering

Many security breaches in the blockchain space target people rather than technology. Phishing attacks, impersonation, and fraudulent communications can trick users into revealing private keys or signing malicious transactions. Technology alone cannot protect against human error.

Bridge Vulnerabilities

Cross-chain bridges, which allow assets to move between different blockchain networks, have been targets of some of the largest security incidents in blockchain history. The complexity of locking assets on one chain and minting equivalent tokens on another introduces additional attack surfaces.

Quantum Computing

Theoretical advances in quantum computing could eventually pose a threat to the cryptographic algorithms currently used by blockchain systems. Researchers are already working on quantum-resistant cryptographic schemes (post-quantum cryptography) to prepare for this possibility.

Continue Learning