Quantum Computing (AL-802 (D)) - Unit 5 Short Notes

UNIT 5: BLOCKCHAIN TECHNOLOGIES

I. FOUNDATIONAL CONCEPTS & CORE ARCHITECTURE

Public Ledger & Transaction Functioning

• Definition: A public ledger is a decentralized, immutable, and append-only digital record of all transactions shared across a network of nodes.

• Functioning:

  1. A transaction is broadcast to the network.

  2. Nodes validate it against consensus rules (e.g., sufficient funds, valid signature).

  3. Valid transactions are grouped into a candidate block.

  4. After consensus (e.g., PoW), the block is added to the chain, cryptographically linking it to the previous block.

• Transparency vs. Pseudonymity: All transactions are publicly visible and verifiable, but participants are identified by cryptographic addresses (public keys), not real-world identities, providing pseudonymity.

Block Structure & Data Organization

• Anatomy of a Block:

  • Block Header: Contains metadata (version, previous block hash, Merkle root, timestamp, difficulty target, nonce).

  • Transaction Counter: Number of transactions.

  • Transactions: The list of validated transactions.

• "Block within a block" (Chain Linkage): Refers to the block height (ordinal position) and the critical previous_block_hash field in the header. Each block contains the hash of its predecessor, forming an immutable chain. Tampering with any block changes its hash, breaking all subsequent links.

  Exam Tip: The "block within a block" concept is the core of blockchain's integrity—it's the cryptographic linkage.

Merkle Trees (Hash Trees)

• Structure: A binary tree where:

  • Leaves are hashes of individual transactions.

  • Non-leaf nodes are hashes of their two child hashes.

  • The root is the Merkle Root, stored in the block header.

• Role & Efficiency:

  • Efficient Verification (Merkle Proofs): A node can prove a transaction is in a block without downloading all transactions. It only needs the transaction hash and the sibling hashes along the path to the root (~log₂(N) hashes).

  • Data Integrity: Any change to a transaction changes its leaf hash, altering all ancestor hashes up to the root, which would not match the header.

  • Storage/Bandwidth: Enables Simplified Payment Verification (SPV)—lightweight nodes verify transactions using only block headers and Merkle proofs.

II. BITCOIN NETWORK & CRYPTOCURRENCY MECHANICS

Bitcoin Peer-to-Peer (P2P) Network

• Topology: Decentralized, unstructured mesh. Nodes (full nodes, miners) connect to a random subset of peers (~8).

• Node Roles:

  • Full Nodes: Validate all transactions/blocks, enforce rules, relay valid data.

  • Miners: Special full nodes that create blocks.

  • SPV Clients: Lightweight nodes that rely on full nodes for proof.

• Transaction/Block Propagation: Uses a flooding protocol. A node broadcasts new transactions/blocks to its peers, who validate and rebroadcast if valid. This gossip protocol ensures rapid, decentralized dissemination.

Proof-of-Work (PoW) & HashCash

• HashCash Mechanism: A Sybil attack deterrent. To send a message (or create a block), a sender/miner must find a nonce such that:

$$H(\text{block header}) \leq \text{target}$$

where `H` is a cryptographic hash function (SHA-256 in Bitcoin). This requires brute-force computation.

• Difficulty Adjustment: The target is adjusted every 2016 blocks (~2 weeks) to maintain an average block time of 10 minutes, regardless of network hash power.

• Security Contributions:

  1. Immutability: To rewrite history, an attacker must redo the PoW for the target block and all subsequent blocks, requiring >50% of the network's hash power (51% attack).

  2. Consensus: The longest valid chain (most cumulative PoW) is accepted as truth.

  3. Sybil Resistance: Creating multiple identities is costly due to computational resource requirement.

Bitcoin Mining: Process & Miner's Role

• Daily Operational Routine:

  1. Transaction Selection: Miners pick unconfirmed transactions from the mempool, prioritizing those with higher fees.

  2. Block Template Creation: Build a candidate block with a coinbase transaction (reward to themselves), selected transactions, and set the previous_block_hash.

  3. Mining: Iterate the nonce (and extra nonce in coinbase) to find a header hash below the target.

  4. Block Propagation: Upon finding a valid nonce, broadcast the block immediately.

• Hardware & Economics:

  • Hardware: Specialized ASICs (Application-Specific Integrated Circuits) are used for efficiency. Energy consumption is massive (global Bitcoin network ~100-150 TWh/year).

  • Rewards: Block Subsidy (newly minted BTC, halves ~every 4 years) + Transaction Fees. This is the economic incentive.

• Network Contribution: Miners secure the network by expending real-world resources (electricity, hardware). They finalize transactions and prevent double-spending by including them in the canonical chain.

III. DISTRIBUTED CONSENSUS & FAULT TOLERANCE

The Byzantine General Problem (BGP)

• Definition: A classic problem in distributed computing. Several Byzantine generals must agree on a common plan of attack (attack or retreat). Some generals may be traitors who send conflicting messages. The challenge is to achieve reliable consensus despite potential malicious (Byzantine) faults.

• Analogy to Blockchain: Nodes are generals. Messages are network communications. The system must agree on the next block even if some nodes are malicious or offline.

• Core Requirement: To tolerate m Byzantine faults, the system needs n > 3m total nodes. This is the fundamental limit for Byzantine Fault Tolerant (BFT) consensus.

Paxos Algorithm

• Goal: Achieve consensus in a network with crash faults only (nodes may fail but do not behave maliciously).

• Key Roles:

  • Proposer: Suggests a value.

  • Acceptor: Votes to accept values.

  • Learner: Learns the chosen value.

• Phases:

  1. Prepare/Promise Phase: Proposer sends Prepare(n) to acceptors. Acceptors promise not to accept proposals numbered less than n.

  2. Accept/Accepted Phase: If proposer receives promises from a majority, it sends AcceptRequest(n, value). Acceptors accept if they haven't promised a higher-numbered proposal.

• Limitations: Complex to implement, assumes synchronous network for safety, primarily handles crash faults, not full Byzantine behavior.

Lamport-Shostak-Pease (Byzantine Fault Tolerance - BFT) Algorithm

• Solution to BGP (Oral Messages): A recursive, message-passing algorithm denoted OM(m), where m is the maximum number of traitors (Byzantine nodes) the system can tolerate.

• Algorithmic Approach:

  1. The commander (source) sends its value to all lieutenants.

  2. Each lieutenant acts as the commander in a subproblem of depth m, recursively forwarding the value it received to other lieutenants.

  3. After recursion, each lieutenant uses a majority function over all received values to decide.

• Requirement: n > 3m (for m traitors, need at least 3m+1 loyal nodes). This ensures the recursive majority function converges to the commander's value if loyal.

• Contrast with Practical BFT: The OM(m) algorithm is theoretical and inefficient (O(n^m) messages). Practical BFT algorithms like PBFT (Practical BFT) use optimizations (e.g., three-phase commit: pre-prepare, prepare, commit) to achieve BFT with O(n²) message complexity.

IV. ENTERPRISE & PERMISSIONED BLOCKCHAIN ARCHITECTURES

Design Considerations for Permissioned Blockchains

• Key Differences from Public Chains:

  • Access Control: Known, identifiable participants (membership via MSP - Membership Service Provider).

  • Consensus: Non-PoW (BFT, Raft, etc.)—high throughput, low latency, deterministic finality.

  • Privacy/Confidentiality: Transactions and data can be private to a subset of participants (channels, private data collections).

  • Governance: Defined rules for membership, smart contract upgrades, dispute resolution.

  • Regulatory Compliance: Easier to meet KYC/AML requirements due to known identities.

Hyperledger Fabric

• Modular Architecture: Separates key functions into distinct components:

  1. Consensus (Ordering Service): Determines transaction order (e.g., Raft, Kafka). Does not validate transactions.

  2. Execution (Peers & Chaincode): Peers host ledgers and execute smart contracts (Chaincode). Validation occurs here.

  3. Validation & Commit: Endorsing peers simulate transactions and produce read-write sets. Ordering service orders them. All peers validate the ordered transactions against policies and commit to their ledger.

• Execute-Order-Validate Paradigm: Contrasts with Bitcoin's Order-Execute. This allows parallel execution of non-conflicting transactions before ordering, improving scalability.

• Privacy via Channels: Sub-networks where only members of a channel can see its transactions and ledger. Enables multi-lateral business networks on a single Fabric network.

• Scalability/Flexibility: Pluggable consensus, chaincode in multiple languages (Go, Java, JS), and private data collections provide high flexibility.

Platform-Specific Notes: Ripple & Corda

V. APPLICATIONS, SMART CONTRACTS & INDUSTRIAL IMPACT

Smart Contracts

• Definition: Self-executing contracts where the terms of the agreement between buyer and seller are written directly into lines of code. The code controls the execution, and transactions are trackable and irreversible.

• Key Properties:

  • Autonomy: Self-executing, no intermediary needed.

  • Trustlessness: Parties don't need to trust each other, only the code.

  • Immutability: Once deployed, the contract logic cannot be changed (unless programmed with upgradeability).

  • Transparency: Code is public and verifiable.

• Potential Applications:

  • Finance (DeFi): Lending, borrowing, automated market makers, stablecoins.

  • Insurance: Parametric insurance (automatic payout on flight delay).

  • Real Estate: Automated property transfer upon payment.

  • Supply Chain: Automated payments upon delivery verification.

  • Legal: Escrow services, royalty distribution.

• Challenges:

  • Security Vulnerabilities: Bugs like reentrancy (e.g., DAO hack), overflow/underflow.

  • Oracle Problem: Smart contracts cannot access off-chain data natively; require trusted external data feeds (oracles), which are a central point of failure.

  • Code Bugs: "Code is law" means errors are permanent and exploitable.

  • Legal Recognition: Unclear status in many jurisdictions.

Blockchain in Supply Chain & Trade Finance

• Impact on International Trade & Global Supply Chains:

  • Provenance & Traceability: Immutable record of a product's journey from raw material to consumer. Combats counterfeiting.

  • Transparency & Trust: All authorized participants (manufacturer, shipper, customs, retailer) share a single source of truth.

  • Reduced Fraud & Errors: Tamper-proof documents (bills of lading, certificates of origin).

  • Automated Compliance: Smart contracts can trigger actions based on predefined conditions (e.g., payment upon IoT sensor confirming temperature).

• Supply Chain Financing (SCF):

  • Problem: SMEs face cash flow gaps due to long payment terms. Traditional financing is slow and paper-heavy.

  • Blockchain Solution: Immutable, verifiable records of invoices and receivables on a shared ledger.

    • Invoice Financing: A factor can instantly verify an invoice's authenticity and advance funds.

    • Dynamic Discounting: Buyer can offer early payment discounts; terms are automated via smart contracts.

    • Receivables Financing: Multiple financiers can trade verified receivables on a secondary market.

  • Key Benefit: Reduces risk, paperwork, and settlement time from weeks to hours/minutes.

Know Your Customer (KYC) Process

• Key Components:

  1. Customer Identification (CIP): Collecting and verifying identity documents (passport, PAN).

  2. Customer Due Diligence (CDD): Understanding the nature of the customer's activities to assess risk profile.

  3. Enhanced Due Diligence (EDD): For high-risk customers (PEPs, high-risk jurisdictions), involves deeper investigation and ongoing monitoring.

  4. Ongoing Monitoring: Tracking transactions for suspicious activity.

• Importance for Financial Institutions:

  • Regulatory Compliance: Mandatory under AML/CFT (Anti-Money Laundering/Combating Financing of Terrorism) laws globally.

  • Fraud Prevention: Detects identity theft and synthetic fraud.

  • Risk Management: Prevents reputational and financial loss from facilitating illicit finance.

• Blockchain Streamlining Potential:

  • Shared, Verifiable Digital Identity: A customer's KYC attestation, once verified by a trusted institution, can be cryptographically shared (with consent) to other institutions, eliminating redundant checks.

  • Reduced Onboarding Time/Cost: From days/weeks to near real-time.

  • Improved Accuracy: Immutable audit trail of KYC documents and checks.

  Exam Tip: Focus on the redundancy problem in traditional KYC and how blockchain's shared ledger with privacy controls (e.g., zero-knowledge proofs) can solve it while maintaining compliance.