Middleware is classically defined as a software layer that sits between the operating system and applications, providing common services so that developers do not need to reimplement them for every project. As Tanenbaum and van Steen put it, middleware abstracts away OS heterogeneity, enables interoperability, and reduces development cost by reusing high-quality solutions for hard problems.
Middleware is developed once for many applications. It lets us afford better designers and provides reusable services — authentication, security, distributed access to shared resources, and consensus.
A critical question arises: should we write consensus algorithms from scratch for every distributed application that needs them? Or should consensus be provided as part of a new middleware layer? Distributed Ledger Technology (DLT) answers this question by offering consensus, immutability, and synchronisation as a service — middleware for trust.
The ITU Focus Group on DLT defines it as "the processes and related technologies that enable nodes in a network to securely propose, validate, and record state changes (or updates) to a synchronised ledger that is distributed across the network's nodes". Notice the key point: the ledger is synchronised, while the nodes and network are not required to be synchronous. DLT thus acts as a synchronising layer — exactly what middleware does in a distributed system.
The middleware perspective explains why DLT is not just about cryptocurrencies. It provides horizontal communication (application-to-application, middleware-to-middleware) with strong guarantees about ordering, finality, and immutability — the kind of infrastructure that enterprise integration has always needed.
ISO/TC 307 provides precise vocabulary: a ledger is an information store that keeps records of transactions intended to be final, definitive, and immutable. A distributed ledger is shared across a set of DLT nodes and synchronised between them using a consensus mechanism. Distributed ledger technology is the technology enabling the operation and use of distributed ledgers.
DLT is not the same as Blockchain Technology (BCT). BCT is one way to implement a distributed ledger — but not all distributed ledgers use blockchains. Examples: IOTA (DAG-based Tangle), Hedera Hashgraph, and R3 Corda. In general, DLT ⊃ BCT.
| Body | Focus | Key Output |
|---|---|---|
| ITU FG DLT | UN agency for ICT; focus on DLT applications | Reference architecture, terms, use cases (2017–2019) |
| ISO/TC 307 | Blockchain and DLT standardisation | ISO 22739 vocabulary (2020, rev. 2024) |
The ITU FG DLT defines a layered architecture: a resource and infrastructure layer (network, storage, computation) below a ledger layer (consensus, data model, smart contracts) above an application layer (APIs, user interfaces). This layered design is itself middleware-like — abstracting the complexity of consensus and replication from application developers.
As a General Purpose Technology (GPT), DLT brings gains across multiple sectors: finance (letters of credit, insurance), pharma (vaccine supply chains), medicine (organ donation registries, health records), ICT (number portability), and energy (P2P trading).
Why is DLT considered middleware? Because it provides a synchronising layer for processes that would otherwise need to implement consensus from scratch. It sits between the OS/network layer and the application layer, offering interoperability, conceptual integrity, and reusable infrastructure — the defining characteristics of middleware.
Blockchains rest on three cryptographic primitives:
A hash function H maps an input of arbitrary size to a fixed-size digest. Key properties: preimage resistance (given y, infeasible to find x such that H(x)=y), collision resistance (infeasible to find x≠y with H(x)=H(y)), and the avalanche effect (a small change in input produces a completely different digest).
hash("Alice->Bob: 1 $"): "b35f8926bc17290dc4f4febb98bd1..."
hash("Allce->Bob: 1 $"): "ff65fc2d9d8cf76917d47b0c7a0a7..." (typo → completely different)
hash("Alice->bob: 2 $"): "7042a70cc7ec19c5cc17bf89390d1..."Each user holds a key pair: a public key (shared openly) and a private key (kept secret). Encrypting with one key can only be decrypted with the other. Deriving the private key from the public key is computationally infeasible. This enables confidentiality, authenticity, and non-repudiation.
A sender creates a signature by encrypting the hash of a message with their private key: Signature = Encrypt_Priv(H(Message)). Anyone can verify it using the sender's public key, proving that the alleged sender is the actual sender (authenticity) and that the message was not tampered with (integrity).
In blockchain, user identifiers are derived from public keys via a one-way hash function (e.g., Address = H(K_pub)). This provides pseudonymity: a user can own multiple addresses with no visible link between them.
Hash functions can be used to build hash chains. Each event is stored within a block b_i. Each block b_{i+1} records the hash of the previous block H(b_i). This creates an immutable sequence: altering any past block would change its hash, breaking the chain link and revealing the tampering.
graph LR B0["Block 0 (Genesis) H(b0)=0x3f2a..."] -->|"H(b0)"| B1["Block 1 H(b1)=0x7e1b..."] B1 -->|"H(b1)"| B2["Block 2 H(b2)=0x9c4d..."] B2 -->|"H(b2)"| B3["Block 3 H(b3)=0xa1e8..."]
By including timestamps in hash chains, we get a timestamping service. Blocks are appended periodically (parameter Δt), recording what happened and when.
Making the timestamping service only accept correctly-signed events yields a notary service. It tracks who did what and when, providing non-repudiation. Applications include supply-chain tracking, voting systems, property registries, employee punching systems, and — of course — cryptocurrencies.
What is the single point of trust in a centralised notary service? The party running the server may be corrupted and arbitrarily alter the ordering/timing of events or exclude participants. Replication across multiple independent parties is the solution — and this leads directly to State Machine Replication.
State Machine Replication (SMR) is the theoretical backbone of blockchain. The core idea: execute the same deterministic state machine over multiple independent processors, in parallel, to achieve fault tolerance, availability, and data untamperability.
A computation is stateful when its output depends on both input and current state. A computation is deterministic if its state depends only on the initial state and the sequence of inputs. For SMR to work, the state machine must be both stateful and deterministic:
SMR faces several challenges: messages may be lost/reordered (solved by TCP + hash functions), lack of global time (NTP/UTC), network partitions (CAP theorem), and Byzantine faults (BFT consensus algorithms).
In a distributed system with shared data, you cannot simultaneously guarantee all three of:
The theorem states: at most two out of three can be satisfied at any time. Blockchain chooses P + A (partition tolerance and availability) and provides eventual consistency — sooner or later, with high probability, replicas converge on the same state.
In permissionless blockchains, consistency is governed by probabilistic rules (e.g., wait for n confirmations). The probability that a block will be overturned decreases exponentially with the number of subsequent blocks mined on top of it.
The Byzantine Generals Problem (Lamport et al., 1982) captures the challenge of reaching agreement when nodes may be arbitrarily faulty — lying, colluding, or sending conflicting messages. In a blockchain, Byzantine faults are particularly dangerous because bad actors have economic incentives to cheat.
A BFT consensus algorithm ensures eventual consistency despite f faulty replicas, provided that the total number of replicas N satisfies N ≥ 3f + 1. This is why we need at least 4 replicas to tolerate 1 Byzantine fault.
FLP theorem (Fischer, Lynch, Paterson, 1985): distributed consensus is impossible in an asynchronous system with even a single faulty process. This is why all practical consensus protocols proceed through periodic rounds with timeouts, effectively imposing synchrony assumptions.
Users are identified by a function of their public key, typically a hash: Address = H(K_pub). In permissionless systems, users can create many pseudonymous addresses (pseudonymity, decentralisation, but vulnerable to Sybil attacks). In permissioned systems, a Certificate Authority (CA) certifies each identity.
The system state is a set of assets: ⟨SystemState⟩ ::= ⟨UserID⟩, ⟨AssetState⟩. The asset state can be a balance (cryptocurrency), custom data, or a smart contract's storage. Three common implementations: account-based (Ethereum), UTXO (Bitcoin), and versioned key-value store (Hyperledger Fabric).
A transaction is a proposed state change: ⟨TX⟩ ::= ⟨UserID⟩, ⟨Operation⟩, ⟨Arguments⟩, ⟨Signature⟩. A transaction is valid if: (i) it is well-formed, (ii) the signature matches the issuer, and (iii) the signature certifies integrity. A valid transaction tx applied to state s via function γ(s, tx) = s' produces a new state.
A block is a timestamped, hash-linked list of transactions with their resulting states:
⟨Block⟩ ::= ⟨PrevHash⟩, ⟨Height⟩, ⟨Time⟩, ⟨Metadata⟩, ⟨TxList⟩
b_i = (ph_i, h_i, ts_i, m_i, (tx1_i, r1_i, ..., txn_i, rn_i))Each block b_i is locally valid if ph_i = H(b_{i-1}), the height increments by 1, and the timestamp falls within the expected interval [Δt - ε; Δt + ε].
Transactions must be validated before being included in a block. Let us see how validation works.
Alice → Bob: 5 ETHBob → Carol: 3 ETHEve → Alice: 100 ETHAlice → (mint): 10 ETHBalances before validation: Alice: 20 ETH, Bob: 5 ETH, Carol: 2 ETH, Eve: 0.5 ETH
Consensus is the heart of any blockchain. Two major families exist:
PBFT (Practical Byzantine Fault Tolerance, Castro & Liskov 2002) is used in permissioned blockchains. It assumes N ≥ 3f + 1 replicas with known identities and proceeds through rounds:
2f+1 commits, the request is executedPros: high throughput (~1000 TX/s), exact consistency, no energy waste.
Cons: limited to ~100–1000 nodes, requires identity management.
Proof-of-Work (PoW, Back 2002) is used in permissionless blockchains like Bitcoin and Ethereum. It combines a computational puzzle with a branch resolution strategy.
The puzzle: Miners compete to find a nonce such that H(block) < target (i.e., the hash starts with a required number of zero bits). The difficulty adjusts to keep E[Δt] constant (~10 min for Bitcoin).
Branch resolution: When two miners solve the puzzle simultaneously, a temporary fork (branch) occurs. The longest chain rule (Bitcoin) or GHOST (Ethereum) resolves it: honest miners always extend the longest/heaviest chain. Eventually, one branch becomes longer and the orphan is abandoned.
Pros: open participation, Sybil-resistant (cost of attack scales with computing power).
Cons: low throughput (~10 TX/s), probabilistic consistency, energy-intensive.
Use this interactive simulator to experience how Proof-of-Work mining plays out. Four miners race to solve a computational puzzle (find a nonce). The difficulty target is a hash starting with 0. The first to succeed mines the next block!
The Sybil attack (Douceur, 2002) occurs when an attacker subverts a P2P system by creating a large number of pseudonymous identities and using them to gain disproportionate influence. In voting-based systems, this undermines majority decisions.
Blockchains defend against Sybil attacks differently depending on permission model:
| Model | Defence | Trade-off |
|---|---|---|
| Permissioned | Certificate Authority (CA) certifies identities | Single point of trust / failure |
| Permissionless (PoW) | Voting power = computing power; 51% attack cost is prohibitive | Energy consumption; probabilistic security |
| Permissionless (PoS) | Voting power = stake; attacking requires majority of economic stake | Nothing-at-stake problem; wealth concentration |
In Bitcoin, the probability that an adversary with fraction r of total computing power can overtake the honest chain after n confirmations follows a Poisson distribution:
P(n | r) = 1 - sum_{k=0}^{n} ( (nr)^k * e^{-nr} / k! ) * (1 - r^{n-k}) [Nakamoto, 2008]With n = 6 confirmations (~1 hour) and adversary power < 13%, confidence exceeds 99.999%.
PoW links security to economic cost. Miners behave honestly because it is profitable to do so. An attack requires acquiring >50% of the network's computing power — which is extremely costly and would also devalue the cryptocurrency the attacker seeks to exploit. This incentive alignment is the genius of Nakamoto's design.
Melanie Swan's popular classification identifies three blockchain generations:
Bitcoin (Nakamoto, 2008) pioneered this generation: a decentralised digital currency using PoW mining, UTXO-based state model, and a limited scripting language. The blockchain is used solely as a ledger of monetary transactions. The model presented in this lesson covers generations 1 and 2 essentially.
Ethereum (Wood, 2014) and Hyperledger Fabric (Androulaki et al., 2018) expanded the model to support custom digital assets beyond currency — tokens, property registries, medical records, voting systems. The world state can track arbitrary data through user-defined assets.
Smart contracts turn the blockchain from a passive ledger into an active computational platform. Users can deploy and invoke programs (smart contracts) that run deterministically on all replicas. This is the topic of the next section.
Generations 1-2 are covered by the "Blockchain Main Elements" model (user identifiers + world state + transactions + blocks + consensus). Generation 3 requires the enhanced model with smart contracts as a new entity type.
Smart contracts (Szabo, 1997) are stateful, user-defined, reactive, immutable, deterministic processes executing replicated computations on the blockchain. They are:
Two operations are provided to clients:
With smart contracts, entities can be either users or contracts:
⟨EntityID⟩ ::= ⟨UserID⟩ | ⟨SmartContractID⟩
⟨Asset⟩ ::= ⟨UserID⟩, ⟨Data⟩ | ⟨SmartContractID⟩, ⟨SmartContractState⟩
⟨SmartContractState⟩ ::= ⟨Storage⟩, ⟨Code⟩
⟨Operation⟩ ::= deploy, ⟨Code⟩ | invoke, ⟨Arguments⟩, ⟨SCID⟩ | transfer, ⟨EntityID⟩, ⟨Value⟩A Turing-complete language on a replicated system raises a critical problem: what if a deployed SC never terminates? Ethereum solves this with Gas:
gasLimit and gasPricegasUsed > gasLimit, execution halts and all side effects are revertedΔETH = gasPrice × gasUsed, compensating the minerThis makes Ethereum smart contracts quasi-Turing-complete: any computable function can be expressed, but infinite loops are prevented by economics.
Why are smart contracts said to be "quasi-Turing-complete" rather than fully Turing-complete? Because the Gas mechanism makes unbounded computation infeasible — any loop will exhaust gas and be reverted. In theory, if you had infinite money for gas, you could simulate a Turing machine, but in practice the Gas bound makes infinite computation impossible.
Solidity is an object-oriented, high-level language for Ethereum smart contracts. Here is a simple Counter contract:
contract Counter {
event Increased(uint oldValue, address cause);
address owner;
uint value;
function Counter() public {
owner = msg.sender; // constructor: sets the deployer as owner
}
function inc(uint times) public { // any user can call this
for (uint i = 0; i < times; i++) {
emit Increased(value++, msg.sender);
}
}
}When deployed, this contract creates a counter that anyone can increment. Each increment fires an Increased event. The contract's state (owner, value) is stored on-chain and replicated across all nodes. All invocations cost gas proportional to times.
Smart contracts act as trustable intermediaries — automated agents that manage assets according to transparent, immutable code. They reduce the need for arbitration and eliminate dependence on human operators for trust-critical decisions.
Smart contract technology is still immature. Several important issues remain:
No privacy or secrets. Everything on the blockchain is visible to everyone. Private state of a smart contract is not secret. Pseudo-anonymity can be broken with statistical analysis or machine learning. This makes secret voting practically impossible.
Poor randomness. True randomness cannot be exploited because replicas would diverge. Most on-chain data (timestamps, heights, hashes) is manipulable by miners. Finding a non-manipulable random seed is an open problem — which makes lotteries and gambling contracts tricky.
Re-entrancy. SCs communicate via synchronous method calls. A calling contract waits for the callee — which may call back into the caller before the first invocation completes. Non-reentrant code can fail or be exploited (the famous 2016 DAO hack).
No way to fix bugs. Immutability is a double-edged sword: buggy or fraudulent contracts cannot be updated, replaced, or undeployed. They remain forever, wasting resources. This makes formal verification paramount — yet verifying Turing-complete code is intrinsically hard.
Lack of pro-activeness. SCs are purely reactive: they always need a user transaction to trigger execution. They are time-aware but not time-reactive — they cannot schedule or postpone computations. No periodic payments without external infrastructure.
Disembodiment and lack of concurrency. Computation is logically located everywhere yet executed strictly sequentially. Independent computations cannot run concurrently. Computations that make sense only locally are replicated globally. Smart contracts cannot parallelise work.
Is instruction-level gas costing the best granularity? In publish-subscribe patterns, the publisher pays the higher price even though the subscriber benefits. This suggests that more sophisticated economic models may be needed for next-generation platforms.
DLT functions as middleware because it provides a synchronising layer for distributed processes — nodes in a DLT network can be asynchronous, but the ledger stays synchronised through consensus. Middleware traditionally provides interoperability, reusable services, and abstraction from OS/network heterogeneity. DLT offers the same: it abstracts consensus and immutable storage, provides shared services (authentication, validation, ordering) to applications, and works across heterogeneous networks — all without requiring applications to implement Byzantine fault-tolerant consensus from scratch.
DLT ⊃ BCT: blockchain is one way to implement a distributed ledger, but not all DLTs use blockchains. Non-blockchain DLTs include: IOTA (uses a Directed Acyclic Graph called the Tangle), Hedera Hashgraph (uses gossip-about-gossip + virtual voting), and R3 Corda (uses notary services with UTXO model, not blocks in the traditional sense).
For a system to tolerate f Byzantine faults, we need enough replicas so that honest replicas can reach agreement despite f liars. Consider: each honest replica needs to hear from 2f+1 replicas (including itself) to have a quorum, because among any set of 2f+1 replicas, at most f are faulty, guaranteeing a honest majority. The total number N must satisfy N ≥ (2f+1) + f = 3f+1, because the f faulty replicas might not respond. For f=1, N ≥ 4 — we need at least 4 replicas to tolerate 1 Byzantine fault.
FLP (Fischer, Lynch, Paterson, 1985) proves that in an asynchronous distributed system (no bounds on message delay), no deterministic consensus protocol can guarantee termination in the presence of even one faulty process. The intuition: you can never distinguish between a slow process and a crashed one, so you cannot safely decide. Practical blockchains circumvent this through periodic rounds with timeouts — effectively assuming partial synchrony (the network becomes synchronous after some unknown time). PoW adds a probabilistic element: the longest-chain rule ensures eventual consensus with high probability, but theoretical determinism is sacrificed.
In PoW, voting power equals computing power, not number of identities. Creating many Sybil identities does not increase an attacker's probability of mining the next block — only acquiring more computing hardware does. The 51% attack requires >50% of total network hash power, which is extremely costly. Security is reinforced by economic incentives: miners are rewarded with newly minted coins and transaction fees for honestly extending the chain. Attacking the network (e.g., by mining an alternate branch) is enormously expensive and would likely devalue the cryptocurrency, making the attack self-defeating. The probability that an adversary with <13% hash power can overturn 6 confirmations is less than 0.001%.
The longest chain rule states that honest miners always extend the longest valid chain they have heard of. When two miners solve a block at nearly the same time, a temporary fork (branch) occurs. Some miners see one block first, others see the other. Because computational puzzles are solved at different rates (the two branches do not grow at the same speed), one branch will eventually become longer than the other. Honest miners then abandon the shorter branch (which becomes an orphan block) and extend the longer one. This achieves eventual consistency: all honest nodes converge on the same chain after some time, with probability approaching 1 as more blocks are mined.
Gas is a metering mechanism: each EVM bytecode instruction consumes a known amount of gas, and transactions specify a gasLimit (maximum gas the caller is willing to pay). If execution exceeds the limit, it is reverted. This prevents infinite loops and denial-of-service attacks. It makes contracts quasi-Turing-complete because while the EVM can theoretically express any computable function, the Gas bound makes unbounded computation impossible in practice — infinite loops will exhaust gas and revert. Without Gas, a malicious user could deploy a contract with an infinite loop, and every replica would be stuck executing it forever.
Identity: PBFT requires known, CA-certified identities; PoW allows pseudonymous participation. Throughput: PBFT achieves ~1000 TX/s; PoW achieves ~10 TX/s. Consistency: PBFT provides exact (deterministic) consistency; PoW provides probabilistic consistency (eventual with high probability). Scalability: PBFT is limited to ~100–1000 nodes due to O(n²) message complexity; PoW scales to thousands of nodes. Sybil defence: PBFT relies on CAs (single point of trust); PoW uses computational cost (no single point of trust but energy-intensive).
Gen 1 — Cryptocurrencies: Simple digital cash, limited scripting. Example: Bitcoin (UTXO model, PoW). Gen 2 — Custom Assets: Blockchain tracks arbitrary state beyond currency — tokens, property, medical records. Example: Ethereum (account-based, before smart contracts) or Hyperledger Fabric (versioned key-value store). Gen 3 — Smart Contracts: Replicated interpreters running user-deployed programs. Example: Ethereum with Solidity, or Hyperledger Fabric with chaincode.
Major limitations include: (1) No privacy — every transaction and state is public, preventing many business applications. (2) Poor randomness — lack of trustworthy entropy makes gambling and games difficult. (3) Re-entrancy vulnerabilities — synchronous calls can lead to exploits (DAO hack). (4) Immutability — bugs cannot be patched. (5) No pro-activeness — contracts cannot initiate actions, only react. (6) No concurrency — all computation is sequential. Each matters because they limit the applicability of smart contracts in real-world scenarios where privacy, reliability, or autonomy are required.