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

UNIT 4: Blockchain Technologies & Distributed Systems

I. Foundational Concepts of Blockchain

A. Public Ledger

• Definition: A public ledger is a decentralized, append-only database (the blockchain) that records all transactions across a network in a transparent and immutable manner.

• Core Function in Financial Transactions: It eliminates the need for a central trusted authority (like a bank) by allowing all participants to independently verify the ownership and history of assets (e.g., bitcoins).

• Key Properties:

  • Immutability: Once a block is confirmed and added, altering its data requires re-mining all subsequent blocks, which is computationally infeasible.

  • Transparency: All transaction data is publicly visible (though identities are pseudonymous), enabling full auditability.

[!TIP] Exam Focus: Be prepared to contrast a public ledger with a traditional private ledger. Emphasize how cryptographic hashing and distributed consensus create trust without a central entity.

B. Block Structure & "Block within a Block"

• Anatomy of a Block:

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

  • Transaction List: The bulk of the block, containing validated transactions.

  • Block Hash: The cryptographic hash (e.g., SHA-256) of the block header, serving as its unique identifier.

• "Block within a Block" (Coinbase Transaction):

  • The first transaction in a block, created by the miner as a reward.

  • Purpose: It has no inputs; it creates new coins (block subsidy) and collects transaction fees. It "lives inside" the block it helps to create.

  • Contribution to Structure: It anchors the block's economic incentive and is a critical part of the chain's data integrity and issuance model.

C. Merkle Trees

• Structure & Construction:

  1. Each transaction's hash is computed.

  2. Hashes are paired and hashed again. This process repeats recursively until a single hash remains: the Merkle Root.

  3. The Merkle Root is stored in the block header.

  
  DiagramCANVAS: A binary tree diagram showing leaf nodes (Tx1, Tx2, Tx3, Tx4 hashes), intermediate nodes (Hash12, Hash34), and the final Merkle Root at the top. Arrows show the pairing and hashing process.
  
  

• Role in Efficient & Secure Verification (Merkle Proofs):

  • Allows a lightweight client (e.g., SPV wallet) to verify a specific transaction is in a block without downloading the entire block.

  • The client only needs the transaction hash, the Merkle Root (from the block header), and the hashes of the "sibling" nodes along the path to the root.

• Applications:

  • Lightweight Clients (SPV): Enables verification with minimal data and bandwidth.

  • Block Summarization: The single Merkle Root succinctly commits to all transactions in the block, ensuring any change to a transaction changes the root, breaking the chain.

[!TIP] Common Pitfall: Merkle Trees provide data integrity (proof of inclusion), not data availability. A node verifying a Merkle Proof still needs to trust that the majority of the network has seen the full block.

II. Bitcoin Network & Mining

A. Bitcoin Peer-to-Peer (P2P) Network

• Network Topology & Node Roles:

  • Decentralized Mesh: Nodes connect to a random subset of peers (~8 outbound, many inbound).

  • Full Nodes: Validate all transactions and blocks against consensus rules, store the full blockchain. The backbone of security.

  • Miners: Special full nodes that compete to create new blocks.

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

• Transaction Propagation & Validation:

  1. User signs transaction → broadcasts to connected peers.

  2. Each node validates (signatures, no double-spend, fees) → relays to its peers if valid.

  3. Valid transactions enter the mempool (memory pool) awaiting inclusion in a block.

• Facilitates P2P Value Transfer: By having all full nodes independently validate every transaction and block, the network enforces rules without a central server. Consensus on the ledger state emerges from this shared validation.

B. Proof of Work (PoW) & HashCash

• HashCash Mechanism: A pioneering PoW system (by Adam Back) requiring senders to compute a partial hash inversion (puzzle) to prove computational work was done, deterring spam.

• Bitcoin's Computational Puzzle (Nonce Finding):

  • Miners repeatedly change the nonce (a 32-bit number) in the block header and hash the header.

  • Goal: Find a hash H such that H < Target, where Target is a dynamically adjusted difficulty value.

  • This is a brute-force search; success is probabilistic.

• How PoW Secures the Network:

  • Sybil Attack Resistance: Creating node identities is cheap, but mining is expensive. Attackers must control >50% of global hash power to consistently rewrite history (51% attack).

  • Cost of Attack: An attacker must invest in hardware and electricity to compete. The economic cost likely outweighs potential gains from fraud.

  • Chain Selection (Longest Chain Rule): Nodes always consider the valid chain with the most cumulative PoW as the canonical one. This resolves forks honestly.

[!TIP] Key Formula: The probability of a single miner finding a block is roughly proportional to their share of the total network hash rate. Difficulty adjusts every 2016 blocks (~2 weeks) to target a 10-minute block time.

C. The Miner's Role & Lifecycle

• Daily Operational Routines:

  1. Transaction Selection: Pulls high-fee transactions from mempool.

  2. Block Template Creation: Constructs a candidate block (header + transactions), including the coinbase.

  3. Mining: Runs the PoW algorithm (ASICs) to find a valid nonce.

  4. Block Propagation: Upon finding a valid block, broadcasts it immediately to the network.

• Hardware Evolution: CPU → GPU (parallel hashing) → ASIC (Application-Specific Integrated Circuit, optimized solely for SHA-256). This created mining centralization pressure.

• Economic Incentives:

  • Block Reward: Newly minted bitcoins (currently 3.125 BTC, halves every 210,000 blocks).

  • Transaction Fees: Sum of fees from all transactions in the block.

• Contribution: Provides security (PoW), ensures transaction finality (confirmations), and manages currency issuance (predictable, disinflationary supply).

III. Distributed Consensus Algorithms

A. The Byzantine General Problem

• Problem Statement: A group of Byzantine generals must agree on a common plan of attack (attack or retreat). Some generals may be traitors who send conflicting messages. How can loyal generals achieve consensus despite faults?

• Implications for Decentralized Systems: It models the challenge of achieving Byzantine Fault Tolerance (BFT)—reaching agreement in a system where nodes can fail arbitrarily (crash, send wrong/malicious messages). Any distributed ledger must solve this to be secure.

B. Byzantine Fault Tolerance (BFT) Solutions

• Lamport-Shostak-Pease (Oral Messages) Algorithm:

  • Recursive Message-Passing Strategy: The commanding general sends an order to lieutenants. Lieutenants exchange the orders they received. After m rounds of messaging, each lieutenant uses a majority function on all received values to decide.

  • Handling Traitors: The recursion ensures that even if some messengers are traitors, loyal generals can filter out inconsistent messages.

  • Fault Tolerance Threshold: Requires n > 3m, where n = total nodes, m = maximum number of faulty (Byzantine) nodes. This is a fundamental bound for asynchronous BFT.

• Practical BFT Variants (e.g., PBFT): Used in permissioned blockchains (Hyperledger Fabric). More efficient than the oral messages algorithm by using a primary/backup replica system and a three-phase commit (pre-prepare, prepare, commit).

C. Paxos Algorithm

• Goal: Achieve consensus in non-Byzantine (crash-fault) environments where nodes only fail by stopping (not by sending malicious data).

• Core Roles:

  • Proposer: Suggests a value.

  • Acceptor: Votes to accept values.

  • Learner: Learns the chosen value.

• Phases:

  1. Prepare/Promise: Proposer asks acceptors to promise not to accept lower-numbered proposals.

  2. Accept/Accepted: Proposer sends a proposed value. Acceptors promise to accept if no higher-numbered prepare arrived.

• Role: The de facto standard for consensus in permissioned/private distributed systems (e.g., Google Chubby, etcd, many databases). It is simpler and more efficient than BFT when only crash faults are a concern.

[!TIP] Critical Distinction: Paxos assumes crash faults only (nodes stop). BFT algorithms (like PBFT, Lamport's) assume arbitrary/Byzantine faults (nodes can act maliciously). BFT is more robust but has higher communication overhead (O(n²) messages).

IV. Permissioned vs. Permissionless Blockchains & Architecture

A. Design Considerations for Permissioned Blockchains

• Identity Management & Access Control: Known, vetted participants. Access is granted/revoked by a governing body or consortium.

• Consensus Mechanism Selection: Often non-PoW (BFT, Raft, Paxos) because known identities reduce Sybil attack risk, enabling faster, more efficient consensus.

• Privacy & Confidentiality: Can be designed for transaction privacy between specific subsets of participants (e.g., via channels or private data).

• Trade-offs:

  • Performance/Scalability: Higher throughput (100s-1000s TPS) and lower latency than permissionless (Bitcoin ~7 TPS).

  • Governance: Clear rules for membership, upgrades, and dispute resolution.

  • Trust Model: Trust is placed in a known set of entities, not in open competition.

B. Hyperledger Fabric Architecture

• Modularity (Separation of Concerns):

  • Consensus (Ordering Service): Independent component that orders transactions into blocks but does not execute them.

  • Execution (Peers/Chaincode): Smart contracts (chaincode) are executed on endorsing peers to produce read-write sets. Validation is done by committing peers.

• Key Components:

  • Peers: Host ledgers and chaincode. Endorsing peers simulate transactions; committing peers validate and commit.

  • Ordering Service: Consensus component (e.g., Raft, BFT-SMaRt) that sequences transactions.

  • Membership Service Provider (MSP): Manages identities and certificates for all entities.

• Channels: Private sub-networks for confidential transactions between specific organizations. Each channel has its own ledger.

• Achieves Scalability & Flexibility: By decoupling consensus from execution and enabling private channels, Fabric allows parallel transaction processing and tailored privacy, unlike a monolithic chain.

[!TIP] Exam Comparison: Contrast Fabric's execute-order-validate architecture with Ethereum's execute-order-validate (all nodes do all). Fabric's separation allows for optimizations and privacy.

V. Applications, Use Cases & Supporting Systems

A. Smart Contracts

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

• Execution Environment:

  • EVM (Ethereum Virtual Machine): Sandboxed runtime for Ethereum smart contracts (Solidity/Vyper).

  • Chaincode (Hyperledger Fabric): Written in Go/Java/Node.js, executed in Docker containers.

• Potential Applications: Decentralized Finance (DeFi), automated supply chain payments, digital identity, royalty distribution, IoT device coordination, prediction markets.

B. Know Your Customer (KYC) Process

• Key Components:

  1. Identity Verification: Proof of identity (passport, driver's license).

  2. Document Checks: Verification of documents' authenticity.

  3. Risk Assessment: Screening against sanctions lists, PEPs (Politically Exposed Persons), adverse media.

  4. Ongoing Monitoring: Continuous transaction screening.

• Importance for Financial Institutions: Mandatory for AML (Anti-Money Laundering) compliance. Prevents fraud, identity theft, terrorist financing, and regulatory penalties.

• Blockchain Transformation: Enables shared, verifiable digital credentials. A customer's verified KYC data (stored privately, e.g., via zero-knowledge proofs) can be securely shared with multiple institutions with consent, reducing redundancy, cost, and onboarding time.

C. Impact on Supply Chain & Trade Finance

• Enhancing Transparency & Traceability: Every step (origin, processing, shipping) is immutably recorded. All permissioned participants see the same data.

• Reducing Fraud & Counterfeiting: Provenance tracking makes it difficult to insert fake goods. Digital certificates of authenticity can be on-chain.

• Automating Processes with Smart Contracts:

  • Letters of Credit (LCs): Automatically release payment when IoT sensors confirm goods arrival at port.

  • Payments: Trigger automatic payments upon delivery confirmation.

• Supply Chain Financing (Short Note Focus):

  • Problem: SMEs often face cash flow gaps due to long payment terms (e.g., 90 days) from large buyers. Traditional financing is slow and paper-heavy.

  • Blockchain Solution: A trusted, shared ledger of verified invoices and purchase orders on a permissioned network (e.g., between buyer, seller, and bank).

  • Process: Seller can instantly tokenize an approved invoice as a digital asset and sell it to a financier (bank) at a discount for immediate cash.

  • Benefits: Faster financing (hours vs. weeks), lower costs, reduced fraud (invoice duplication), improved SME liquidity. Smart contracts automate repayment when buyer pays the invoice.

D. Enterprise Blockchain Platforms: Ripple & Corda

[!TIP] Exam Comparison: Remember: Ripple = Payments (XRP, fast consensus). Corda = Private contracts (point-to-point, no global ledger, legal focus).