Unit 1: Blockchain concepts

I. Foundations and Governing Principles

A blockchain (concept dating to Haber & Stornetta 1991, realised in Bitcoin 2008 by Satoshi Nakamoto) is an append-only, replicated ledger in which transactions are grouped into blocks, each cryptographically chained to its predecessor, and agreed upon by a distributed network without a central authority. Every later section depends on these defining properties.

• Block linkage: each block stores the hash of the previous block header, so block[n].prevHash = H(block[n-1].header); altering any past block changes all later hashes.
• Cryptographic integrity: transactions are secured by hash functions (SHA-256) and digital signatures (ECDSA), proving authorship and non-tampering.
• Decentralisation: the ledger is replicated across many nodes; no single party owns or edits the canonical state.
• Consensus: nodes agree on one valid chain via protocols such as Proof-of-Work or Proof-of-Stake.
• Immutability: once confirmed and buried under further blocks, a record is practically unchangeable.
• Transparency with pseudonymity: all participants see the same ledger, while identities are addresses (public-key hashes), not legal names.
• Trustless execution: trust shifts from an intermediary to verifiable code and math.

II. Blockchain Application Example — Escrow

Replacing the trusted middleman with code.

A. The escrow problem and its on-chain solution

Escrow holds a buyer's funds until agreed conditions are met, protecting both sides of a trade.

• Traditional escrow: a bank, lawyer or platform (e.g. a marketplace) holds money, charges a fee, and can be slow, biased, or a single point of failure.
• Blockchain escrow: a smart contract locks funds and releases them automatically when conditions are satisfied, removing the paid intermediary.
• Release logic: funds move only when the required signatures or oracle data confirm delivery.

B. Multi-signature and smart-contract mechanics

The escrow is enforced by consensus rules rather than a person's judgement.

• 2-of-3 multisig: buyer, seller, and arbiter each hold a key; any two must sign to release or refund, so no single party controls the funds.
• Dispute path: in normal trade buyer + seller sign; if they disagree the arbiter signs with the honest party.
• Smart-contract version (pseudocode):

function release() public {
    require(msg.sender == buyer || arbiter);
    require(delivered == true);
    payable(seller).transfer(amount);
}

• Symbols: buyer, seller, arbiter are stored addresses; amount is the locked value in wei; delivered is a boolean set by confirmation or an oracle.

C. Benefits and limitations of on-chain escrow

• Benefits: lower fees (no custodial cut), speed (instant programmatic release), and auditability (every step on-ledger).
• Limitations: an oracle problem — the contract cannot itself verify that physical goods arrived, so it still depends on an off-chain data feed or human arbiter.

III. The Blockchain Stack

The layered architecture from hardware to user.

A. Layered model

A blockchain system is best understood as a stack where each layer builds a service for the one above.

• Hardware / infrastructure layer: physical nodes, networking, and virtualised compute that run the clients.
• Data layer: the block and transaction structures — Merkle trees, hashes, timestamps — that define how state is stored.
• Network (P2P) layer: gossip protocol by which nodes propagate transactions and blocks; no central server.
• Consensus layer: the rule set (PoW, PoS, PBFT) deciding which block is appended next.
• Execution / contract layer: the virtual machine (e.g. the Ethereum Virtual Machine) that runs smart contracts deterministically on every node.
• Application layer: dApps, wallets, and user interfaces that call the layers below.

B. The Merkle tree in the data layer

The data layer uses a Merkle tree so a block can commit to many transactions with one hash.

• Construction: hash each transaction, then hash pairs upward until a single Merkle root remains, stored in the block header.
• Formula: root = H( H(tx1)+H(tx2) ... ) combined pairwise.
• Benefit: a light client can verify one transaction is in a block using only a short branch (log₂ n hashes), not the whole block.

C. On-chain vs off-chain layers

• 1. On-chain (Layer 1): the base ledger (Bitcoin, Ethereum) — maximally secure but limited in throughput.
• 2. Off-chain (Layer 2): protocols built atop L1 (payment channels, rollups) that batch activity off the main chain and settle periodically, trading some directness for scale.

IV. From Web 2.0 to the Decentralized Web

Shifting control of data and value from platforms to users.

A. Characteristics of Web 2.0

Web 2.0 (roughly 2004 onward) made the web interactive but centralised control.

• Platform ownership: data lives on corporate servers (social networks, cloud providers), who control access and monetise it.
• Centralised trust: users must trust the provider for identity, payments, and content persistence.
• Business model: free services funded by harvesting and selling user data.

B. Characteristics of the decentralized web (Web 3.0)

The decentralized web returns ownership of identity, data, and value to the user.

• User-held keys: identity is a cryptographic key pair; the user, not a platform, controls their account.
• Decentralised storage: content addressed by its hash on networks like IPFS, not by a server URL.
• Token-based value: native tokens let value move peer-to-peer without a bank.
• Open protocols: logic runs as public smart contracts anyone can audit or build on.

C. Web 2.0 versus the decentralized web

• 1. Web 2.0: fast, polished UX, but the user is the product; data is siloed and censorable.
• 2. Decentralized web: user-sovereign and censorship-resistant, but slower, more complex, and shifting responsibility (key loss = permanent loss) onto the user.
• Transition reality: most systems are hybrid — a dApp front-end (centralised hosting) talking to on-chain contracts.

V. Domain-Specific Blockchain Applications

Where decentralisation adds concrete value.

A. Principle for applicability

Blockchain fits domains needing a shared, tamper-evident record among parties who do not fully trust each other.

• Finance (DeFi): lending, stablecoins, and exchanges run as contracts; e.g. automated market makers price trades via x * y = k.
• Supply chain: each handover is logged, giving end-to-end provenance of goods (e.g. tracing food from farm to shelf).
• Healthcare: patient records shared across providers with the patient controlling access, while preserving an audit trail.
• Identity: self-sovereign identity lets users prove credentials without a central registry.
• Voting: tamper-evident, auditable ballots recorded on-ledger.
• Real estate / land registry: immutable title records reduce fraud and simplify transfer.
• NFTs and digital assets: unique on-chain tokens proving ownership of art, media, or in-game items.

B. Permissioned vs permissionless deployments

• 1. Permissionless (public): open to all (Bitcoin, Ethereum); maximal transparency, suited to open finance.
• 2. Permissioned (private/consortium): restricted members (Hyperledger Fabric); faster and private, suited to enterprise supply chains where participants are known but must share one ledger.

VI. Benefits and Challenges

Weighing what blockchain gains against what it costs.

A. Benefits

Blockchain's structural properties translate into practical advantages.

• Decentralisation: removes single points of failure and gatekeepers.
• Immutability and auditability: a permanent, verifiable history — valuable for compliance and provenance.
• Transparency: all participants verify the same state, reducing reconciliation effort.
• Security: cryptographic signatures and consensus make tampering economically and computationally infeasible.
• Disintermediation: cuts cost and delay by removing middlemen (as the escrow example shows).
• Programmability: smart contracts automate agreements without manual enforcement.

B. Challenges

The same design choices create real limits.

• Scalability: low throughput — Bitcoin ≈ 7 tx/s, Ethereum ≈ 15–30 tx/s — versus thousands for centralised systems.
• The blockchain trilemma: a chain struggles to maximise decentralisation, security, and scalability simultaneously; improving one usually sacrifices another.
• Energy cost: Proof-of-Work consumes large amounts of electricity (motivating the shift to Proof-of-Stake).
• Storage growth: every full node stores the entire chain, which only grows.
• Latency / finality: confirmations take time (e.g. several blocks) to be considered irreversible.
• Regulatory uncertainty: unclear legal status of tokens, contracts, and liability.
• Key management: losing a private key means irrecoverable loss of funds or identity.
• Oracle problem: contracts cannot natively access or trust real-world data without external feeds.
• Immutability as a drawback: bugs or mistaken transactions cannot simply be reversed, as a smart-contract exploit permanently drains funds.