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

UNIT 1: FOUNDATIONAL BLOCKCHAIN CONCEPTS & ARCHITECTURES

(Based on RGPV "A BLOCKCHAIN TECHNOLOGIES - MAY 2024" Past Paper Analysis)

1.0 Foundational Concepts & Data Structures

1.1 Public Ledger

• Definition: A decentralized, immutable, and transparent digital record of all transactions across a network. It is the core database of a blockchain.

• Function in Financial Transactions:

  • Transparency: All participants can view the history of asset ownership (e.g., Bitcoin transactions).

  • Immutability: Once recorded, data cannot be altered retroactively without network consensus, preventing fraud.

  • Decentralization: No single entity controls the ledger; it is maintained by a distributed network of nodes (peers), eliminating single points of failure and central authority.

• Mechanism: Transactions are grouped into blocks, which are cryptographically linked (via hashes) to form a chain. This chain is replicated across all network nodes.

[!TIP] Exam Focus: Be prepared to contrast a public ledger with a traditional centralized ledger (like a bank's database). Emphasize the "trustless" environment it creates.

1.2 Block Structure & "Block Within a Block"

• Standard Block Anatomy:

  • Block Header: Contains metadata: Version, Previous Block Hash (link to chain), Merkle Root (hash of all transactions), Timestamp, Difficulty Target, Nonce.

  • Transaction Counter/List: The actual data (e.g., financial transactions, smart contract calls).

• "Block Within a Block" (Nested/Recursive Blocks):

  • Concept: A design where a block can contain another complete block as part of its transaction data. This creates a hierarchical or tree-like structure of blocks.

  • Purpose & Contribution:

    1. Scalability & Parallelization: Allows different sub-chains or sidechains to be created and validated within the main chain, enabling parallel transaction processing.

    2. Flexible Governance: Different "sub-ledgers" (blocks-within-blocks) can have different rules or participants while being anchored to the main chain for security.

    3. Enhanced Privacy: Specific transactions can be grouped into a nested block, revealing details only to authorized parties within that sub-chain.

1.3 Merkle Trees

• Construction:

  1. List all transactions in a block.

  2. Hash each transaction (using SHA-256 in Bitcoin) to get leaf nodes.

  3. Pair and hash adjacent nodes recursively until a single hash remains: the Merkle Root.

  
  Level 0 (Leaves): H(Tx1), H(Tx2), H(Tx3), H(Tx4)
  
  Level 1:        H(H(Tx1)||H(Tx2)), H(H(Tx3)||H(Tx4))
  
  Root:           H(Level1_Left || Level1_Right)
  
  

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

  • Efficiency: A light client (e.g., mobile wallet) does not need to download the entire block (all transactions). To verify a specific transaction (Tx3) is in a block, it only needs:

    • The block header (contains Merkle Root).

    • The transaction itself (Tx3).

    • A small set of "sibling" hashes from the tree (e.g., H(Tx4), H(H(Tx1)||H(Tx2)), and the hash from the other branch at Level 1).

  • Security: By repeatedly hashing up the tree using the provided sibling hashes, the light client can independently compute the Merkle Root. If it matches the root in the block header (which is secured by Proof-of-Work), the transaction is cryptographically proven to be part of that block. Any alteration to Tx3 would change the root, causing mismatch.

• Impact: Drastically reduces storage and bandwidth requirements for participants, enabling broader network participation without full nodes.

[!TIP] Common Pitfall: Merkle Trees provide inclusion proofs (Tx is in block), not ordering proofs (Tx was before another). Ordering is provided by the block's transaction list position.

2.0 Cryptography & Consensus Mechanisms

2.1 HashCash Proof of Work (PoW)

• Mechanism: A computational puzzle requiring significant but verifiable work to find a solution (nonce).

  • Miners repeatedly hash the block header (with a changing nonce).

  • Goal: Find a hash output that is less than a network target value (i.e., has a certain number of leading zeros).

  • Hash(Block Header + Nonce) < Target

  • Finding this nonce is brute-force (guess-and-check). Verifying the solution is a single hash computation.

• Contribution to Security:

  1. Sybil Attack Resistance: Creating network identity (mining power) requires real-world resources (electricity, ASIC hardware), making it costly to spawn many fake identities.

  2. Currency Issuance: The difficulty adjustment ensures new blocks (and thus new bitcoins) are found approximately every 10 minutes, controlling monetary supply.

  3. Chain Security: An attacker wanting to rewrite history must redo the PoW for the target block and all subsequent blocks, requiring >51% of the total network hash power—prohibitively expensive.

2.2 Distributed Consensus Fundamentals

• Byzantine General Problem (BGP):

  • Definition: A classic problem in distributed computing where traitorous generals (faulty/malicious nodes) must agree on a common plan of action (attack/retreat) despite some generals sending conflicting messages. The core challenge is achieving agreement in a system with faulty components.

  • Implication for Blockchains: Nodes in a peer-to-peer network can fail or act maliciously (Byzantine faults). A consensus algorithm must ensure all honest nodes agree on the same ledger state despite these faults.

• Paxos Algorithm:

  • Roles:

    • Proposer: Suggests a value (e.g., a new block).

    • Acceptor: Votes to accept or reject proposals.

    • Learner: Learns the final chosen value.

  • Phases (Simplified):

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

    2. Promise: Acceptors respond with their highest accepted proposal (if any).

    3. Accept: If proposer gets majority promises, it sends an Accept request with a value (either its own or the highest from promises).

    4. Accepted: Acceptors record the value and notify learners.

  • Achieves Consensus: Guarantees that if a value is chosen, all future proposals will see that value. Requires a majority (quorum) of acceptors to be honest.

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

  • Oral Messages Model: Messages can be forged by traitors.

  • Recursive Strategy (BFT(n, f)): To reach consensus with n generals where up to f are traitors, the algorithm recursively solves smaller sub-problems.

    • Base Case (n=1): The commander's order is the decision.

    • Recursive Step: The lieutenant acts as commander for n-1 lieutenants, using the majority of the n-1 returned orders as its final order.

  • Fault Tolerance Limit: The algorithm only works if n > 3f. With n=3f+1 or more generals, the loyal lieutenants can overcome the traitors' misinformation and reach the same consistent order.

  • Key Insight: Requires 3f+1 nodes to tolerate f Byzantine faults.

[!TIP] Exam Distinction: Paxos is for crash faults (nodes fail/stop), while BFT algorithms (like Lamport's) handle Byzantine faults (nodes lie/act arbitrarily). Bitcoin's PoW is a probabilistic BFT solution.

3.0 Network Architecture & Mining

3.1 Bitcoin Peer-to-Peer (P2P) Network

• Decentralized Topology: A mesh network where every full node is a peer. There is no central server.

• Transaction & Block Propagation:

  1. A user broadcasts a signed transaction to its connected peers.

  2. Peers validate the transaction (script, double-spend check) and forward it to their peers (flooding/gossip protocol).

  3. Miners collect valid transactions into a candidate block and begin PoW.

  4. Once a miner finds a valid nonce, it broadcasts the new block.

  5. Nodes validate the block (PoW, transactions, Merkle root) and, if valid, add it to their local copy of the blockchain and forward it.

• Facilitating Trustless Transfers: The P2P network, combined with consensus (PoW) and cryptography, allows two parties to transact directly without trusting an intermediary. The network's collective validation replaces the need for a central trust authority.

3.2 Life & Operations of a Bitcoin Miner

• Daily Routines:

  1. Transaction Selection: Listen to the mempool (pending transactions). Prioritize transactions with higher fees (fee-per-byte) to maximize revenue.

  2. Block Template Creation: Assemble selected transactions into a candidate block. Calculate the Merkle Root. Set the previous block hash to the latest chain tip.

  3. Proof-of-Work Computation: Iterate the nonce (and eventually other fields like extraNonce in the coinbase) and hash the block header until a hash below the target is found.

• Hardware & Economics:

  • Hardware: ASICs (Application-Specific Integrated Circuits) dominate. They are thousands of times more efficient at SHA-256 hashing than CPUs/GPUs.

  • Energy Consumption: Massive. The "work" in PoW is real-world electrical energy. Profitability depends on electricity cost vs. block reward + fees.

  • Revenue Sources: Block Reward (newly minted bitcoins, halves ~every 4 years) + Transaction Fees.

  • Mining Pools: Miners combine hash power to reduce variance in income. The pool operator finds a block and distributes reward proportionally.

• Contribution to Network:

  • Security: Provides the hash power that secures the chain against 51% attacks.

  • Transaction Finality: Miners order transactions into blocks, providing a definitive, irreversible (after ~6 confirmations) record.

  • Currency Issuance: Controls the release schedule of new bitcoins.

4.0 Blockchain Types & Design

4.1 Permissioned vs. Permissionless Blockchains

4.2 Design Considerations for Permissioned Blockchains

• Identity Management & Membership Service: A Membership Service Provider (MSP) or Certificate Authority (CA) is crucial to issue, revoke, and manage cryptographic identities (X.509 certificates) for all participants (nodes, users, admins).

• Consensus Algorithm Selection: Non-PoW. Choices include:

  • Practical BFT (PBFT): State machine replication. Requires n > 3f. Good for small, known networks.

  • Raft: Crash-fault tolerant leader-based consensus. Simpler, faster, but not BFT.

  • Proof-of-Authority (PoA): Validators are pre-approved, staking their reputation.

• Performance & Scalability: Design for high Throughput (TPS) and low Latency. Achieved via efficient BFT consensus, parallel transaction execution, and sharding if needed.

• Privacy & Confidentiality: Critical for enterprises. Achieved via:

  • Channels (Fabric): Subsets of participants share private data.

  • Private Transactions (Corda): Point-to-point, not broadcast to all.

• Governance & Administration: Clear rules for:

  • Member onboarding/offboarding.

  • Smart contract (chaincode) deployment and upgrade policies.

  • Dispute resolution and protocol parameter changes.

5.0 Enterprise & Platform-Specific Architectures

5.1 Hyperledger Fabric

• Modular Architecture: Separates the execution of transactions from the ordering (consensus) of transactions.

  • Execution (Peers & Chaincode):

    • Peers: Host the ledger and chaincode (smart contracts). Endorsing Peers simulate transactions and check policies. Committing Peers only record results.

    • Chaincode: Business logic, runs in Docker containers.

  • Ordering (Ordering Service):

    • A standalone service (cluster of nodes) that orders transactions into blocks without executing them.

    • Implements consensus (e.g., Raft, Kafka, BFT-SMaRt).

• Key Components & How Modularity Achieves Goals:

  • Channels: Private subnets. Ledger data is partitioned. Only members of a channel see its transactions. Enables privacy and scalability (parallel channels).

  • World State: Current value of assets (key-value store). Cached for fast queries, separate from immutable transaction log.

  • How Modularity Helps:

    1. Scalability: Ordering service can scale independently. Multiple channels process transactions in parallel.

    2. Flexibility: Different chaincode can run on different peers. Ordering service can be swapped (Raft vs. BFT).

    3. Privacy: Channels ensure data is only shared with relevant parties. Peers not on a channel cannot see its ledger.

5.2 Ripple and Corda (Comparative Note)

6.0 Applications & Industry Impact

6.1 Smart Contracts

• Definition: Self-executing contracts with the terms of the agreement directly written into lines of code. They exist on a decentralized blockchain network and execute automatically when predefined conditions are met.

• Key Properties:

  • Autonomy: Remove the need for intermediaries.

  • Immutability: Once deployed, code cannot be changed (unless upgrade logic is built-in).

  • Verifiability: Code and execution are publicly auditable (on public chains).

  • Trustless Execution: Execution is guaranteed by the network's consensus.

• Potential Applications:

  • Finance: Automated loans, insurance payouts (flight delay), decentralized exchanges (DEXs).

  • Supply Chain: Automatic payment upon delivery confirmation (IoT sensor data).

  • Real Estate: Automated title transfer upon payment.

  • IoT: Machine-to-machine micropayments and service agreements.

6.2 Supply Chain Financing

• Traditional Challenges: Opacity (hard to track goods), delays in documentation/payment, high counterparty risk (especially for SMEs), reliance on manual processes and trusted intermediaries (banks, factors).

• Blockchain Enablement:

  1. Transparency & Traceability: All parties (supplier, manufacturer, shipper, buyer, bank) see the same immutable record of goods movement and document status (PO, invoice, bill of lading).

  2. Automated Payments (via Smart Contracts): A smart contract can be triggered by an IoT sensor confirming goods receipt or by a digital bill of lading, automatically releasing payment from the buyer's bank to the supplier. This is Supply Chain Finance (SCF) or dynamic discounting.

  3. Reduced Counterparty Risk: Banks can finance invoices with greater confidence, seeing the underlying trade history and buyer's commitment on an immutable ledger. SMEs get faster access to capital.

  4. Reduced Fraud: Single, shared version of documents prevents duplicate financing.

6.3 Impact on International Trade & Global Supply Chains

• End-to-End Traceability & Provenance: Track a product from raw material to consumer. Combats counterfeit goods and ensures ethical sourcing (e.g., conflict-free minerals).

• Reduction in Paperwork & Fraud: Replaces bills of lading, letters of credit, and invoices with digital, cryptographically signed assets. Eliminates document forgery and reconciliation errors.

• Streamlined Customs & Logistics: Customs authorities can access pre-verified, immutable data, speeding up clearance. Real-time visibility of shipment location and status.

• Enhanced Trust: Creates a "single source of truth" among international partners who may not inherently trust each other, reducing disputes and delays.

6.4 KYC (Know Your Customer) Process

• Traditional KYC Challenges:

  • Repetition: Each institution (bank, broker, exchange) independently performs KYC on the same customer.

  • High Cost: Labor-intensive verification (ID, proof of address, source of funds).

  • Siloed Data: Customer's verified identity is trapped in each institution's database. No secure sharing.

  • Poor User Experience: Customers submit same documents repeatedly.

• Blockchain's Role:

  1. Self-Sovereign Identity (SSI): Customer owns their verified identity data (stored as a verifiable credential on their device or a secure wallet).

  2. Secure, Shared Verification: A trusted entity (e.g., a bank) performs KYC and issues a signed, encrypted credential (e.g., "This person is AML-compliant as of Date X").

  3. Customer-Controlled Sharing: The customer can then grant permission to any other financial institution to view this specific credential without revealing underlying raw documents. The institution can cryptographically verify the credential's authenticity and issuer.

• Importance for Financial Institutions:

  • AML Compliance: Streamlines ongoing monitoring and customer due diligence.

  • Fraud Prevention: Reduces identity theft and synthetic fraud by relying on verified, immutable credentials.

  • Cost Reduction: Eliminates redundant KYC checks for existing customers moving between institutions.

  • Improved Onboarding: Dramatically faster customer onboarding (minutes vs. days/weeks).

[!TIP] Exam Application: When asked about impact, structure your answer: Problem -> Blockchain Solution -> Result/Benefit. E.g., KYC: Problem = Repetition/Cost. Solution = SSI + Verifiable Credentials. Result = Faster onboarding, lower cost, better compliance.