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

Unit 2: Blockchain Fundamentals, Architecture, Consensus & Applications

(Based on "A BLOCKCHAIN TECHNOLOGIES - MAY 2024" Exam Questions)

1.0 Blockchain Core Structure & Cryptography

1.1 Public Ledger

• Definition: A decentralized, immutable digital record of all transactions shared across network participants.

• Function in Financial Transactions:

  • Eliminates need for central authority (e.g., banks).

  • Provides transparency (all transactions visible) and auditability.

  • Ensures immutability once validated via consensus.

• Transparency vs. Privacy:

  • Public blockchains (e.g., Bitcoin) offer full transparency but pseudonymity (addresses not directly linked to identities).

  • Privacy challenges addressed via techniques like zero-knowledge proofs (e.g., Zcash) or permissioned blockchains with access control.

[!TIP]

Exam Focus: Distinguish between transparency (data visibility) and privacy (identity concealment). Public ledgers prevent double-spending without trusted intermediaries.

1.2 Block Structure & Chain Formation

• Block Header (80 bytes in Bitcoin):

  • Contains: Previous block hash, Merkle root, timestamp, nonce, difficulty target.

• Block Body:

  • List of transactions (e.g., Bitcoin: up to 1 MB).

• "Block within a Block" Concept:

  • Refers to chaining mechanism: Each block header includes the hash of the previous block’s header.

  • Forms a cryptographic link; altering any block requires re-mining all subsequent blocks.

  • Ensures tamper-evidence and chronological order.

[!TIP]

Common Pitfall: "Block within a block" is not about nested blocks but the hash pointer linking blocks. This is the backbone of blockchain immutability.

1.3 Merkle Trees

• Construction:

  • Binary hash tree: Transactions hashed pairwise → hashes hashed recursively until single Merkle root.

  • Example: 4 transactions → 2 hashes → 1 root.

• Role in Efficient Data Verification:

  • Merkle Proof (Proof of Inclusion): A lightweight client can verify a transaction’s inclusion without downloading entire block.

  • Requires O(log n) hashes vs. O(n) for full block.

  • Enables Simplified Payment Verification (SPV) in Bitcoin.

• Security: Any change in a transaction alters the Merkle root, breaking the chain.

[!DIAGRAM: SEARCH: "Merkle tree blockchain structure with transaction hashes"]

Key Formula: For n transactions, Merkle proof size ≈ \(\log_2 n\) hashes.

1.4 Cryptographic Hash Functions

• Properties:

  • Deterministic: Same input → same output.

  • Pre-image resistance: Given hash h, infeasible to find input x such that \(H(x) = h\).

  • Collision resistance: Infeasible to find two inputs x ≠ y with \(H(x) = H(y)\).

  • Avalanche effect: Small input change drastically changes output.

• Role in Blockchain:

  • Block hashing (SHA-256 in Bitcoin) links blocks.

  • Transaction IDs (txids) are hashes of transaction data.

  • Mining: Finding nonce such that block hash < target.

[!TIP]

Exam Alert: Hash functions are one-way; they secure blockchain but do not encrypt data. Use cases: integrity, digital signatures (with asymmetric crypto).

2.0 Bitcoin Network & Mining

2.1 Bitcoin Peer-to-Peer (P2P) Network

• Decentralized Architecture:

  • Nodes (peers) communicate directly without central server.

  • New nodes bootstrap via DNS seeds or hardcoded addresses.

• Node Types:

  • Full nodes: Store entire blockchain, validate all transactions/blocks.

  • Lightweight/SPV nodes: Store only block headers, rely on full nodes for transaction data.

• Transaction/Block Propagation:

  • Gossip protocol: Node forwards new transactions/blocks to all peers (flooding).

  • Prevents double-spends by rapid dissemination.

[!TIP]

Key Insight: P2P network’s resilience comes from redundancy—no single point of failure. Attackers need >50% hash power to censor transactions.

2.2 HashCash Proof-of-Work (PoW)

• Concept:

  • Computational puzzle: Find nonce such that \(H(\text{block header}) < \text{target}\).

  • Target adjusts every 2016 blocks (~2 weeks) to maintain ~10 min block time.

• Security Contribution:

  • Sybil attack resistance: Creating identities is cheap, but mining requires real resources (electricity, hardware).

  • Longest chain rule: Honest nodes adopt chain with most cumulative PoW.

  • 51% attack: Attacker needs majority hash power to rewrite history (extremely costly).

[!DIAGRAM: SEARCH: "Bitcoin PoW mining difficulty adjustment"]

Formula:

\[ > \text{New Target} = \text{Old Target} \times \frac{\text{Actual Time}}{\text{Target Time (2016 blocks × 10 min)}} > \]

2.3 Daily Life of a Bitcoin Miner

• Routines:

  1. Transaction selection: Pick high-fee transactions from mempool.

  2. Block assembly: Create block header + coinbase transaction.

  3. PoW computation: Iterate nonce/extra nonce to find valid hash.

  4. Block propagation: Broadcast winning block to network.

  5. Orphan handling: Be prepared for chain reorganizations.

• Challenges:

  • Hardware costs: ASICs expensive, become obsolete quickly.

  • Electricity: Major operational cost; miners locate near cheap power.

  • Pool mining: Individual miners join pools to reduce variance; rewards split proportionally.

  • Regulatory risks: Bans in some countries, environmental concerns.

[!TIP]

Numerical Example: If block reward is 6.25 BTC + fees ≈ 1 BTC, daily revenue ≈ 900 BTC (144 blocks/day). At $30k/BTC → $27M/day shared globally → intense competition.

3.0 Distributed Consensus Mechanisms

3.1 Byzantine General Problem

• Definition: Problem of achieving consensus among distributed nodes where some may be faulty/malicious (Byzantine faults).

• Fault Types:

  • Crash faults: Node stops responding.

  • Byzantine faults: Node sends conflicting/arbitrary messages.

• Need for Consensus: In decentralized systems (no central coordinator), nodes must agree on transaction order despite faults.

[!TIP]

Key Threshold: For n nodes, can tolerate up to \(f < n/3\) Byzantine faults (in synchronous systems with digital signatures).

3.2 Lamport-Shostak-Pease (Oral Messages) Algorithm

• Core Principle: Uses recursive messaging to reach consensus in synchronous networks with digital signatures.

• Phases:

  1. Oral messages: Commander sends order to lieutenants.

  2. Recursive forwarding: Each lieutenant forwards received order to others.

  3. Majority voting: Each lieutenant decides based on majority of received orders.

• Fault Tolerance: Works if \(n > 3f\) (traitorous generals).

[!TIP]

Limitation: Assumes synchronous network (bounded delay). Not practical for large n due to \(O(n^f)\) message complexity.

3.3 Practical Byzantine Fault Tolerance (PBFT)

• Phases (for each request):

  1. Pre-prepare: Primary node assigns sequence number, broadcasts request.

  2. Prepare: Replicas broadcast "prepare" messages if request valid.

  3. Commit: After 2*f+1 prepare messages, replicas broadcast "commit" and execute.

• Fault Tolerance: \(f < n/3\) Byzantine nodes tolerated.

• Efficiency: \(O(n^2)\) messages per request; used in permissioned blockchains (e.g., Hyperledger Fabric).

3.4 Paxos Algorithm

• Roles:

  • Proposer: Suggests value.

  • Acceptor: Votes on value.

  • Learner: Learns chosen value.

• Phases:

  1. Prepare/Promise: Proposer gets promises from majority of acceptors not to accept lower-numbered proposals.

  2. Accept/Accepted: Proposer sends proposed value; acceptors accept if no higher-numbered prepare seen.

• Use Case: Crash-fault tolerant consensus (e.g., Google Chubby). Less tolerant to Byzantine faults than PBFT.

[!TIP]

Comparison:

• PBFT: Tolerates Byzantine faults, higher message overhead, used in permissioned chains.

• Paxos: Tolerates crash faults, simpler, used in distributed databases.

4.0 Blockchain Types & Enterprise Architectures

4.1 Permissioned vs. Permissionless Blockchains

4.2 Design Considerations for Permissioned Blockchains

• Identity Management: Membership Service Provider (MSP) issues certificates (X.509).

• Consensus Choice: PBFT for BFT, Raft for crash-fault tolerance; trade-off between speed and fault tolerance.

• Privacy/Confidentiality:

  • Channels (Fabric): Private subnets for specific organizations.

  • Private Data Collections: Data shared only among subset.

• Governance: Who can add/remove nodes? Smart contract upgrade policies.

• Scalability: Sharding, sidechains, or modular design (execution vs. ordering separation).

4.3 Hyperledger Fabric Architecture

• Modularity:

  • Pluggable consensus: Ordering service (Raft, Kafka) separate from peers.

  • Pluggable MSP: Supports various certificate authorities.

• Chaincode (Smart Contracts):

  • Written in Go/Java/JavaScript; executes on peers in Docker containers.

  • Execute-Order-Validate paradigm:

    1. Execute (endorsing peers simulate transaction).

    2. Order (ordering service sequences transactions).

    3. Validate (committing peers check endorsement policy, update ledger).

• Channels: Enable multi-lateral privacy; each channel has separate ledger.

• Ledger Structure:

  • World State (current state, LevelDB/CouchDB).

  • Blockchain (immutable log of transactions).

• Scalability: Throughput increases with more endorsing peers; ordering service can be scaled independently.

[!DIAGRAM: SEARCH: "Hyperledger Fabric architecture execute-order-validate"]

Key Advantage: Separation of concerns allows parallel transaction execution and efficient ordering.

5.0 Smart Contracts & Applications

5.1 Smart Contracts

• Definition: Self-executing code stored on blockchain that enforces agreements when predefined conditions are met.

• Properties:

  • Deterministic: Same input → same output across all nodes.

  • Immutable: Once deployed, cannot be altered (unless upgrade mechanism built-in).

  • Trustless: Execute without intermediary.

• Execution Environments:

  • EVM (Ethereum): Stack-based, gas-metered.

  • Chaincode (Fabric): Docker containers, no gas model.

• Applications:

  • DeFi: Lending, borrowing, automated market makers.

  • Supply Chain: Automated payments upon delivery verification.

  • Real Estate: Tokenization, automated title transfer.

  • Legal: Escrow, royalty distribution.

[!TIP]

Security Risk: Bugs in smart contracts are irreversible (e.g., DAO hack). Formal verification and audits essential.

5.2 Impact on International Trade & Supply Chains

• Transparency: All parties (manufacturer, shipper, customs, retailer) share single source of truth.

• Traceability: Immutable record of product journey (origin, temperature, handling).

• Automated Payments: Smart contracts trigger payments upon IoT sensor confirmation (e.g., temperature within range).

• Reduced Fraud: Counterfeit goods detected via unique digital IDs.

• Paperwork Reduction: Digitize letters of credit, bills of lading; faster clearance.

5.3 Supply Chain Financing

• How Blockchain Enables:

  • Invoice Factoring: Invoice tokenized on blockchain; financiers can verify authenticity and purchase instantly.

  • Dynamic Discounting: Smart contracts allow early payment discounts based on time.

  • Inventory Financing: Real-time inventory data on blockchain reduces risk for lenders.

• Benefits:

  • Speed: Financing reduced from days to hours.

  • Lower Costs: Reduced due diligence, no intermediaries.

  • Trust: Immutable audit trail reduces disputes.

[!TIP]

Example: A supplier ships goods; IoT data + bill of lading on blockchain triggers automatic payment from buyer’s bank via smart contract.

6.0 Platforms, Compliance & Integration

6.1 Ripple vs. Corda

[!TIP]

Key Difference: Ripple is a public ledger for payments; Corda is a private ledger for business agreements with no global data store.

6.2 KYC (Know Your Customer) Process

• Key Components:

  1. Identity Verification: Government ID, passport, biometrics.

  2. Document Checks: Proof of address (utility bill), incorporation documents (for corporates).

  3. PEP/Sanctions Screening: Check against politically exposed persons lists, OFAC sanctions.

  4. Ongoing Monitoring: Transaction monitoring for suspicious activity; periodic re-verification.

• Importance for Financial Institutions:

  • AML Compliance: Prevent money laundering, terrorist financing.

  • Fraud Prevention: Stop identity theft, account takeover.

  • Regulatory Risk: Avoid fines (e.g., under Bank Secrecy Act, GDPR).

  • Reputation: Protect from association with illicit activities.

[!TIP]

Blockchain Impact: KYC on blockchain can reduce duplication (once verified, reusable across institutions) but raises privacy concerns (who controls data?).

6.3 Integration Challenges

• Scalability Trilemma:

  • Decentralization vs. Security vs. Scalability (throughput).

  • Bitcoin/Ethereum: High decentralization/security, low scalability.

  • Permissioned chains: Higher scalability, lower decentralization.

• Interoperability:

  • Different blockchains cannot natively communicate.

  • Solutions: Cross-chain bridges (e.g., Polkadot, Cosmos), atomic swaps, oracles.

• Regulatory Landscape:

  • Unclear jurisdiction; varying stances (ban, regulate, embrace).

  • Compliance costs high for global operations.

• Energy Consumption:

  • PoW blockchains (Bitcoin) use massive electricity (~100 TWh/year).

  • Shift to PoS (Ethereum 2.0) or permissioned chains reduces footprint.

[!TIP]

Exam Approach: For "integration challenges," always mention trilemma first, then interoperability, regulation, energy. Use real examples (e.g., Bitcoin energy use, SEC vs. Ripple lawsuit).

\boxed{\text{These notes cover all topics from the May 2024 Blockchain exam. For Quantum Computing Unit 2, refer to actual syllabus/past papers.}}