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

UNIT 2: BLOCKCHAIN TECHNOLOGY FOUNDATIONS & CONSENSUS

MAIN THEME 1: FOUNDATIONS OF BLOCKCHAIN TECHNOLOGY

1.1 Core Structural Concepts

Public Ledger

• Definition: A decentralized, immutable, and transparent digital record of all transactions shared across a network of participants (nodes). No single entity controls it.

• Function in Financial Transactions:

  • Immutability: Once a transaction is recorded in a block and added to the chain, altering it requires changing all subsequent blocks and gaining majority network control—computationally infeasible.

  • Transparency: All participants can independently verify the history of transactions (though identities may be pseudonymous).

  • Trust Minimization: Eliminates the need for a central trusted intermediary (e.g., a bank) for verification.

[!TIP] Exam Focus: Always link immutability to cryptographic hashing and consensus. Transparency does not mean anonymity—it means verifiability of the ledger's state.

Block Structure & "Block within a Block"

• A block is a container for data. Its typical structure includes:

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

  2. Transaction List: The actual data (e.g., financial transactions, contract states).

• "Block within a block" Concept: This typically refers to:

  • Merkle Tree Structure: The transaction list is summarized into a single Merkle Root hash stored in the header. This creates a hierarchical "tree" of hashes within the block header.

  • Contribution to Integrity: The previous block's hash is included in the current block's header. This cryptographically chains blocks together. Any change in a transaction would change its leaf hash, propagate up to alter the Merkle root, and finally break the chain because the next block's "previous hash" would no longer match.

Merkle Trees

• Construction: A binary tree where:

  1. Leaf nodes are hashes of individual transaction data (e.g., H(Tx1)).

  2. Parent nodes are hashes of concatenated child hashes (e.g., H(H(Tx1) + H(Tx2))).

  3. The top node is the Merkle Root.

• Role in Efficient & Secure Verification:

  • Space Efficiency: A node only needs the Merkle Root (in the block header) and a small subset of hashes (Merkle Proof) to verify a specific transaction's inclusion without storing the entire block.

  • Data Integrity: Any alteration to a transaction changes its hash, which changes all parent hashes up to the root. Verifying a Merkle Proof against the stored root instantly detects tampering.

  • Scalability: Enables Simplified Payment Verification (SPV) in Bitcoin, allowing light clients to verify transactions without downloading the full blockchain.

[!TIP] Common Pitfall: A Merkle Tree proves inclusion, not exclusion. It cannot prove a transaction is not in the block.

1.2 Smart Contracts

• Definition: Self-executing contracts with the terms of the agreement directly written into lines of code. The code is stored on the blockchain and automatically executes when predefined conditions are met.

• Key Properties:

  • Self-Executing & Autonomous: No third-party enforcement needed.

  • Tamper-Proof: Once deployed, the code cannot be altered.

  • Deterministic: Given the same input and state, it always produces the same output across all nodes.

  • Transparent: Code is publicly auditable (on public blockchains).

• Potential Applications:

  • Finance: Automated loans, insurance payouts, stablecoins.

  • Supply Chain: Automatic release of payment upon verified delivery (via IoT sensor data).

  • Real Estate: Automated title transfer upon escrow fulfillment.

  • Legal: Escrow services, royalty distribution.

  • IoT: Machine-to-machine microtransactions and automated service agreements.

MAIN THEME 2: CONSENSUS MECHANISMS & FAULT TOLERANCE

2.1 Proof-of-Work (PoW) & Mining

HashCash Proof of Work

• Mechanism: A cryptographic puzzle requiring significant computational effort (hashing) to solve but easy to verify. Miners repeatedly hash the block header with a changing nonce until the resulting hash is below a network difficulty target (i.e., has a certain number of leading zeros).

• Contribution to Security:

  1. Sybil Attack Resistance: Creating multiple fake identities is cheap, but mining (solving PoW) is expensive. It ties voting power (block creation) to computational power.

  2. Chain Selection Rule: The longest valid chain (most cumulative PoW) is the canonical truth. An attacker must re-mine all blocks after a targeted transaction plus catch up to honest nodes—prohibitively expensive.

  3. Decentralized Leader Election: PoW randomly (via computation) selects the next block proposer.

Bitcoin Miner's Role & Routine

1. Transaction Validation: Collect unconfirmed transactions from the mempool, verify signatures, check for double-spends.

2. Block Creation: Assemble valid transactions into a candidate block. Construct the block header (including Merkle root of transactions and previous block hash).

3. Nonce Searching: Iterate the nonce value, compute SHA256(SHA256(block_header)) repeatedly until a hash below the target is found.

4. Block Propagation: Broadcast the solved block to the P2P network.

5. Reward: Receive block subsidy (newly minted BTC) + transaction fees. This incentivizes honest mining.

6. Hardware/Energy: Uses specialized ASICs. Energy cost is the primary security guarantee ("digital gold" analogy).

[!TIP] Exam Detail: Be prepared to list the exact steps in a miner's routine and link each to network security (e.g., validation prevents invalid blocks, PoW makes chain rewriting costly).

2.2 Distributed Consensus Algorithms

Byzantine General Problem (BGP)

• Definition: A classic problem illustrating the challenge of achieving consensus in a distributed system where some components may fail or act maliciously (Byzantine faults—arbitrary behavior, not just crashes).

• Implication: For a system to reach agreement despite traitors, the number of loyal (honest) generals must be more than 2/3 of the total. If n is total nodes, t is max faulty nodes, then n > 3t is required.

  \boxed{n > 3t}

Lamport-Shostak-Pease (Byzantine Generals') Algorithm - Oral Messages (OM)

• Goal: Achieve consensus in a synchronous network with digital signatures (oral messages).

• Mechanism (Recursive):

  1. The commanding general sends an order to all lieutenants.

  2. Each lieutenant forwards the order they received to all other lieutenants.

  3. Each lieutenant uses a recursive majority function on the n-1 values they receive (including their own direct one) to decide on the final order.

• Key Requirement: Works only if n > 3t. Message complexity is high: O(n^t).

• Handles Byzantine Faults: By relying on recursive message passing and majority, it can filter out contradictory orders from traitors.

Paxos Algorithm

• Goal: Achieve consensus in a permissioned, asynchronous network tolerant of crash faults (nodes may stop, but don't act maliciously). The classic algorithm for replicated state machines.

• Roles:

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

  • Acceptor: Votes to accept a value. A majority (quorum) of acceptors must agree.

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

• Phases:

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

  2. Propose/Accept: If proposer receives promises from a quorum, it sends its value. Acceptors accept if they haven't promised a higher-numbered proposal.

• Guarantees:

  • Safety (Consistency): Only one value is ever chosen.

  • Liveness: A value will eventually be chosen if a majority of acceptors are operational.

• Note: Classic Paxos is complex. Multi-Paxos (with a stable leader) is used in practice (e.g., Google Chubby).

[!TIP] Key Distinction: BGP/Lamport-Shostak-Pease solves for malicious (Byzantine) faults but requires n>3t. Paxos solves for crash faults with simpler majority (n>2t) but assumes non-malicious nodes.

2.3 Design for Permissioned Systems

• Identity Management: All participants are known and vetted. Uses Membership Service Provider (MSP) to issue and manage cryptographic identities (X.509 certificates).

• Consensus Mechanism: Typically non-PoW. Uses efficient, deterministic algorithms like:

  • PBFT (Practical BFT): Tolerates f Byzantine faults with 3f+1 nodes. High message complexity but fast finality.

  • Raft: Crash-fault tolerant, leader-based, simpler than PBFT.

• Privacy/Confidentiality: Achieved via:

  • Channels (Hyperledger Fabric): Private sub-networks where only channel members see transactions.

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

• Performance vs. Decentralization Trade-off: Fewer, known nodes → higher throughput (TPS) and lower latency. Sacrifices the open, permissionless decentralization of Bitcoin.

• Governance: Clear, on-chain or off-chain governance models for protocol changes, as participants are known entities.

MAIN THEME 3: NETWORKS, IDENTITY, AND APPLICATIONS

3.1 Bitcoin Peer-to-Peer (P2P) Network

• Architecture: Decentralized network of nodes (computers running Bitcoin Core). No central server.

  • Full Nodes: Store the entire blockchain, validate all blocks and transactions.

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

• Facilitating Bitcoin Transfer:

  1. Transaction Creation & Signing: User A creates a transaction sending BTC to User B, signs with private key.

  2. Broadcast: User A's wallet broadcasts the raw transaction to its connected full nodes.

  3. Propagation & Validation: Nodes validate the transaction (signature, UTXO set, fees). Valid transactions enter the mempool and are propagated to peers.

  4. Mining: Miners select transactions from mempools, assemble a candidate block, and perform PoW.

  5. Block Propagation: Solved block is broadcast. Nodes validate the block (PoW, transactions) and, if valid, add it to their local chain, updating the UTXO set.

  6. Confirmation: Once the block containing User A's transaction is buried under k subsequent blocks, the transfer is considered final.

3.2 Identity & Compliance (KYC)

Key Components of KYC Process:

1. Customer Identification Program (CIP): Collecting and verifying identity documents (ID, passport, proof of address).

2. Customer Due Diligence (CDD): Understanding the nature and purpose of the customer relationship to develop a risk profile.

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

4. Ongoing Monitoring: Tracking transactions for suspicious activity, updating customer information periodically.

Importance for Financial Institutions:

• AML (Anti-Money Laundering): Prevents criminals from using financial systems to launder proceeds of crime.

• Fraud Prevention: Detects identity theft and account takeover attempts.

• Regulatory Compliance: Mandatory under laws like the Bank Secrecy Act (USA), PMLA (India), GDPR (for data). Heavy fines for non-compliance.

• Risk Management: Protects institution's reputation and financial stability by avoiding association with illicit activities.

3.3 Industry Impact & Use Cases

Impact on International Trade & Global Supply Chains:

• Transparency & Provenance: All participants (manufacturer, shipper, customs, buyer) see the same immutable record of a product's journey, reducing fraud and disputes.

• Automation: Smart contracts automate payments, letters of credit, and compliance checks upon fulfillment of conditions (e.g., IoT sensor confirms temperature-controlled cargo arrival).

• Reduced Paperwork & Fraud: Digitizes bills of lading, certificates of origin, etc., eliminating document forgery and delays.

• Efficiency: Real-time visibility reduces inventory costs, accelerates financing, and streamlines customs clearance.

Supply Chain Financing

• Definition: Financial services (e.g., invoice discounting, dynamic discounting, purchase order financing) that optimize cash flow across a supply chain.

• Traditional Challenges: Lack of trust between SMEs and large buyers, slow manual processes, difficulty verifying invoice authenticity, high risk of double financing.

• Blockchain Enablement:

  • Trusted Data: Immutable record of purchase orders, invoices, and deliveries.

  • Smart Contracts: Automate financing triggers (e.g., upon verified invoice approval, funds are released to the supplier at a discount).

  • Reduced Risk: Financiers can verify the underlying trade transaction's legitimacy on the shared ledger, enabling faster, cheaper financing for SMEs.

MAIN THEME 4: ENTERPRISE & ALTERNATIVE PLATFORMS

4.1 Hyperledger Fabric

Architecture for Modularity & Scalability:

• Pluggable Consensus: The ordering service (e.g., Raft, Kafka) is separate from the peer execution. This decoupling allows different consensus algorithms for different network needs.

• Execute-Order-Validate Paradigm:

  1. Execute: Endorsing peers (smart contract "chaincode" executors) simulate transactions before ordering to check policies and produce read-write sets.

  2. Order: Ordering service sequences transactions into blocks without executing them.

  3. Validate: All peers validate the block's transactions against the endorsement policy and read-write sets before committing. This avoids all peers redundantly executing all transactions.

• Chaincode Isolation: Smart contracts (chaincode) run in separate Docker containers from the peer process, enhancing security and stability.

• Private Channels: Allow subsets of network members to transact privately. Ledger data is partitioned; only channel members see transactions.

• Membership Service Provider (MSP): Manages identities and certificates for all entities (peers, orderers, users), enabling a permissioned environment.

4.2 Comparative Study of Platforms

[!TIP] Exam Short Note Structure: For "Ripple and Corda," structure as: 1) Core Purpose, 2) Ledger/Privacy Model, 3) Consensus, 4) Token, 5) Key Differentiator. Contrast them directly.