High Performance computing (AL-802 (B)) - Unit 3 Short Notes

UNIT 3: Blockchain Technology and Distributed Systems (High Performance Computing Context)

1. Blockchain Fundamentals

Public Ledger in Financial Transactions

• Definition: A decentralized, append-only database recording all transactions across a network.

• Immutable Nature: Once recorded, data cannot be altered retroactively. Achieved via cryptographic hashing and consensus.

• Transparency vs. Privacy:

  • Transparency: All participants can verify transactions (in public blockchains).

  • Privacy: Identity is pseudonymous; transaction details are visible but not directly linked to real-world identities. Permissioned blockchains offer stricter access controls.

[!TIP] Exam often asks to contrast transparency and privacy. Highlight that immutability is a complement to transparency, not a substitute for privacy.

Smart Contracts

• Concept: Self-executing contracts with terms written in code. Automatically enforce and execute when predefined conditions are met.

• Self-executing Nature: Triggered by events (e.g., time, transaction) without intermediaries.

• Applications:

  • Finance: Automated loans, insurance claims, derivatives settlement.

  • Logistics: Release payment upon delivery confirmation via IoT sensor data.

  • Real Estate: Automated title transfers upon payment clearance.

Block Structure

• "Block within a block" Concept: Refers to hierarchical data organization:

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

  2. Block Body: Contains transactions.

  3. Merkle Tree: A binary hash tree of all transactions; its root hash is stored in the header. Thus, the Merkle tree (a "block" of hashed data) is cryptographically embedded within the block header.

• Linkage via Hashes: Each block header includes the hash of the previous block's header, forming an immutable chain. Altering any transaction changes its Merkle root, breaking all subsequent block hashes.

Merkle Trees

• Construction:

  1. Hash each transaction (leaf nodes).

  2. Pair and hash adjacent hashes to form parent nodes.

  3. Repeat until a single root hash (Merkle root) remains.

• Binary Hash Tree Structure: Each non-leaf node is hash of its two children. Efficient for verifying inclusion of a single transaction without needing entire block.

• Role in Verification:

  • Merkle Proofs: Provide a path (sibling hashes) from a transaction to the root. A verifier can confirm a transaction's presence by hashing upward and comparing to a trusted root.

  • Efficiency: Reduces data transmission and storage (light clients verify without full blockchain).

[!TIP] Merkle proofs are critical for scalability. In exams, sketch a small Merkle tree (4 transactions) and show a proof path for one transaction.

2. Distributed Consensus Mechanisms

Byzantine General Problem

• Problem Statement: A group of generals must agree on a common plan of attack (attack/retreat). Some generals may be traitors who send conflicting messages. How to achieve consensus despite faulty/malicious nodes?

• Fault Tolerance Requirement: To reach agreement in an untrusted environment, the system must tolerate up to $f$ faulty nodes. The necessary condition is total nodes $$\displaystyle n > 3f $$.

• Relation to Distributed Consensus: Models real-world systems where nodes may fail arbitrarily (Byzantine faults: crash, arbitrary, malicious). Blockchain consensus must solve this to agree on ledger state without central authority.

Byzantine Fault Tolerance (BFT) Algorithms

• Lamport-Shostak-Pease (Byzantine Generals) Algorithm:

  • Oral Messages: Commander sends order to lieutenants. Each lieutenant forwards received orders to others. Final decision by majority of received orders.

  • Recursive: For $f$ traitors, requires $$\displaystyle n > 3f $$ and $f+1$ rounds of messaging.

• Message Complexity: $$\displaystyle O(n^{f+1}) $$ in worst case—exponential with fault count $f$, limiting scalability.

• Fault Tolerance Threshold: Can tolerate up to $$\displaystyle \left\lfloor \frac{n-1}{3} \right\rfloor $$ Byzantine nodes.

[!TIP] Distinguish between crash faults (node stops) and Byzantine faults (node behaves arbitrarily). BFT algorithms handle both.

Paxos Algorithm

• Roles:

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

  • Acceptor: Votes to accept/reject proposals.

  • Learner: Learns the chosen value (does not vote).

• Phases:

  1. Prepare Phase: Proposer sends prepare(n) to acceptors. Acceptors promise not to accept proposals with number $$\displaystyle < n $$.

  2. Accept Phase: If proposer receives majority promises, it sends accept(n, value). Acceptors accept if not promised higher $n$.

  3. Learn Phase: Learners collect acceptances; once majority on a value, it is chosen.

• Achieving Consensus: Guarantees safety (only one value chosen) and liveness (eventual choice) despite failures. Requires majority ($$\displaystyle > n/2 $$) of acceptors to be non-faulty.

Proof of Work (PoW) as Consensus

• HashCash Mechanism: Miners solve computational puzzle: find nonce such that:

$$H(\text{nonce} \parallel \text{block header}) < \text{target}$$

where $H$ is a cryptographic hash (SHA-256 in Bitcoin), target adjusts to maintain ~10-minute block time.

• Security through Resource Expenditure:

  • Sybil Resistance: Creating multiple identities is cheap, but solving puzzles requires real computational power (electricity, hardware). Attackers must outcompete honest network's hash power.

  • Longest Chain Rule: Honest nodes build on longest valid chain. An attacker must redo PoW for all blocks after a transaction to double-spend, becoming infeasible if honest majority holds >50% hash power.

[!TIP] PoW is probabilistic finality (wait for $k$ confirmations). BFT gives deterministic finality. Contrast in exams.

3. Bitcoin Network and Mining

Bitcoin Peer-to-Peer (P2P) Network

• Decentralized Topology: No central server. Nodes (peers) connect to a random subset of others (~8 outbound, many inbound).

• Node Roles:

  • Full Nodes: Validate all blocks/transactions, store entire blockchain.

  • Lightweight (SPV) Nodes: Store only block headers, rely on full nodes for transaction proofs.

  • Mining Nodes: Full nodes that also compete to solve PoW.

• Transaction/Block Propagation:

  1. Transaction broadcast via inv (inventory) messages.

  2. Receiving nodes verify (signatures, UTXO) and forward to peers (flooding/gossip protocol).

  3. Mined block broadcast similarly; nodes validate and adopt if valid (longest chain rule).

Mining Process and Economics

• Daily Routines:

  1. Transaction Validation: Check signatures, unspent outputs (UTXO set), fees.

  2. Block Assembly: Select transactions from mempool (usually highest fee-first), construct coinbase transaction (block reward + fees), build Merkle tree.

  3. Nonce Search: Iterate nonce (and extra nonce in coinbase) to find hash below target. Requires massive parallel computation (ASICs).

• Miner Incentives:

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

  • Transaction Fees: Sum of fees from included transactions. As block reward diminishes, fees become primary incentive.

• Economics: Revenue = block reward + fees. Costs = hardware + electricity. Mining is profitable only if revenue > costs, driving centralization to low-cost regions.

Security Contributions of Mining

• Double-Spending Prevention: To reverse a confirmed transaction, attacker must produce a longer chain excluding it, requiring >50% of network hash power.

• 51% Attack Scenario:

  • If attacker controls >50% hash power, they can:

    • Double-spend their own transactions.

    • Censor transactions (exclude from blocks).

    • Earn all block rewards (but honest miners still get fees from non-censored txs).

  • Security Assumption: Honest majority (hash power) is economically rational to follow protocol (block rewards > attack gains). Attack devalues Bitcoin, harming attacker's investment.

[!TIP] 51% attack does not allow stealing funds from arbitrary addresses (requires private keys). It only allows censoring and double-spending own transactions.

4. Enterprise and Permissioned Blockchains

Permissioned Blockchain Design Considerations

• Access Control: Identity known (PKI certificates). Nodes must be approved to join.

• Identity Management: Membership Service Provider (MSP) issues/revokes identities. Often integrates with existing enterprise directories (LDAP, Active Directory).

• Governance Models: Consortium (pre-approved organizations) or single-entity control. Rules for adding/removing members, protocol upgrades.

• Trade-offs:

  • Decentralization: Reduced (known entities) vs. public chains (anonymous).

  • Scalability: Higher throughput (no PoW, known nodes enable efficient consensus).

  • Privacy: Enhanced (transactions visible only to participants, channels/subnets).

Hyperledger Fabric Architecture

• Modular Design:

  • Consensus: Pluggable ordering service (Kafka, Raft, BFT-SMaRt).

  • Membership Services: MSP handles identities, certificates.

  • Smart Contracts (Chaincode): Written in Go/Java/JavaScript; executed in Docker containers.

• Scalability via Channels: Private subnets where only invited members see transactions. Each channel has its own ledger and chaincode.

• Execute-Order-Validate Paradigm:

  1. Execute: Clients send transaction proposals to endorsing peers. Peers simulate execution (read/write sets) without updating ledger.

  2. Order: Endorsed transactions sent to ordering service (e.g., Raft cluster). Orders transactions into blocks.

  3. Validate: All peers receive blocks, validate (endorsement policies, read-write conflicts), then commit to ledger.

  • Advantage: Parallel execution (different channels) and separation of concerns improve performance.

Ripple and Corda

• Ripple (XRP Ledger):

  • Consensus Protocol: RPCA (Ripple Protocol Consensus Algorithm). Nodes (validators) in Unique Node List (UNL) repeatedly poll each other; transactions with >80% agreement are validated.

  • Use Case: Inter-bank settlements, cross-border payments. Native cryptocurrency XRP as bridge currency.

  • No Mining: All 100 billion XRP pre-mined; validators are known institutions.

• Corda:

  • Notary-based Consensus: Transactions require notary service (single or cluster) to prevent double-spends. Notary validates uniqueness, not content.

  • Privacy by Design: Only parties to a transaction and required notaries see data. No global broadcast.

  • Legal Entity Focus: States (facts) are legally enforceable; contracts (CorDapps) encode business logic. Designed for regulated industries (finance, healthcare).

[!TIP] Fabric uses channels for privacy; Corda uses point-to-point transactions with notaries. Ripple is for payments; Corda is for general agreements.

5. Blockchain Applications in Finance and Supply Chain

Know Your Customer (KYC) Process

• Key Components:

  1. Identity Verification: Government IDs, biometrics.

  2. Document Authentication: Proof of address, financial statements.

  3. Risk Assessment: PEP (Politically Exposed Person) screening, transaction monitoring.

• Blockchain's Role:

  • Streamlining: Shared, permissioned ledger among banks/financial institutions. Once a customer's KYC is verified by one institution, others can rely on the attestation (with customer consent), reducing duplication.

  • Reduced Costs: Faster onboarding, lower operational overhead.

  • Audit Trail: Immutable record of all KYC checks and updates.

Supply Chain Financing

• Concepts:

  • Invoice Discounting: Supplier sells invoice to financier at discount for immediate cash.

  • Dynamic Discounting: Buyer offers early payment discounts based on invoice age.

  • Trade Finance: Letters of credit, bills of lading.

• Blockchain Enablement:

  • Transparency: All parties (supplier, buyer, financier, carrier) see immutable shipment/payment status.

  • Automated Payment: Smart contracts release funds upon verified delivery (IoT sensor data, document hash match).

  • Reduced Fraud: Tamper-proof documents (e.g., bill of lading) prevent duplicate financing.

Impact on International Trade and Global Supply Chains

• Enhanced Traceability: End-to-end tracking of goods (origin, temperature, handling) on blockchain. Critical for food safety, pharmaceuticals.

• Reduced Fraud: Single source of truth for documents (customs declarations, certificates of origin) prevents tampering.

• Automated Compliance: Smart contracts enforce trade agreements, tariffs, sanctions automatically.

• Challenges:

  • Interoperability: Different blockchains (Fabric, Corda, Ethereum) cannot natively communicate.

  • Standardization: Lack of universal data formats (GS1, etc.) and legal recognition of digital documents.

  • Regulatory Adoption: Governments slow to accept blockchain records as legal evidence; jurisdictional conflicts.

[!TIP] In supply chain, emphasize provenance (tracking origin) vs. tracking (location history). Blockchain excels at both but requires IoT integration for real-time data.

Final Exam Strategy:

• For 7-mark questions: Define term (1 mark), explain mechanism (3-4 marks), give example/application (1-2 marks), discuss pros/cons (1 mark).

• Always link back to High Performance Computing context: scalability (TPS), resource usage (PoW energy), fault tolerance (BFT thresholds), and modularity (Fabric).

• Use diagrams where possible: Merkle tree, Paxos phases, Fabric execute-order-validate flow. Describe them in text if no canvas.