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

UNIT 4: Blockchain & Distributed Ledger Technologies

A. FOUNDATIONS OF BLOCKCHAIN

Core Concept: The Public/Decentralized Ledger

• Definition: A public ledger is a decentralized, immutable digital record of transactions or data entries, maintained collectively by a network of nodes without a central authority.

• Function in Financial Transactions:

  • Transparency: All transactions are visible to network participants.

  • Immutability: Once recorded, data cannot be altered retroactively.

  • Disintermediation: Removes need for trusted third parties (e.g., banks).

• Contrast with Centralized Ledgers:

  | Feature | Centralized Ledger | Decentralized/Public Ledger | | :--- | :--- | :--- | | Control | Single entity | Distributed network | | Single Point of Failure | Yes | No | | Trust Model | Trust in central authority | Trust in protocol/cryptography | | Transparency | Private to entity | Public/Permissioned |

[!TIP] Exam often asks to contrast. Focus on control, trust, and failure points.

Block Structure & Chain Formation

• Anatomy of a Block:

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

  • Transaction Counter/List: The actual data/transactions.

  • Nonce: A number changed by miners to satisfy the Proof-of-Work requirement.

• "Block within a Block" Concept: Refers to the previous block hash field in the header. Each block contains the cryptographic hash of the entire header of the preceding block, creating an immutable, chronological chain.

  Key Formula: Hash(Block Header_{n}) is stored in previous_hash field of Block Header_{n+1}.

• How Chaining Ensures Integrity: Altering any transaction in a historic block changes its header hash. This breaks the previous_hash link for all subsequent blocks, requiring re-mining all following blocks—computationally infeasible in a healthy network.

[!TIP] "Block within a block" is a literal description of the linking mechanism. Emphasize the hash pointer.

Cryptographic Hash Functions

• Role: Creates a unique, fixed-size digital fingerprint (hash) for any input data. Used for:

  1. Block identifiers (block hash from header).

  2. Linking blocks (previous_hash).

  3. Building Merkle trees.

• Essential Properties:

  • Deterministic: Same input → same output.

  • Pre-image resistant: Given hash h, infeasible to find input m such that hash(m) = h.

  • Second pre-image resistant: Given m1, infeasible to find m2 ≠ m1 with hash(m1) = hash(m2).

  • Collision resistant: Infeasible to find any two distinct inputs m1, m2 with hash(m1) = hash(m2).

  • Avalanche effect: A tiny change in input drastically changes the output.

[!TIP] Distinguish pre-image resistance from collision resistance. Both are crucial for blockchain security.

Merkle Trees (Hash Trees)

• Structure:

  DiagramCANVAS: A binary tree diagram. Leaf nodes are transaction hashes (Tx1, Tx2, Tx3, Tx4). Parent nodes are hashes of concatenated child hashes (Hash(Tx1+Tx2), Hash(Tx3+Tx4)). The root node is the Merkle Root, stored in the block header.

• Construction: Transactions are hashed to form leaf nodes. Pairs of hashes are concatenated and hashed to form parent nodes, repeating until a single Merkle Root is obtained.

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

  • Allows a lightweight (SPV) client to verify a transaction's inclusion in a block without downloading the entire block.

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

  • By recursively hashing the transaction hash with the provided proof hashes, the client can compute the root and compare it to the one in the block header.

• Significance: Enables scalability and trust-minimized verification. Tampering with a single transaction changes its leaf hash, altering all ancestor hashes up to the root, which would be detected.

[!TIP] Merkle Proof = Authentication Path. Know how an SPV client uses it. The Merkle Root is the "summary" of all transactions.

B. NETWORKING & CONSENSUS MECHANISMS

Peer-to-Peer (P2P) Networks (Bitcoin Model)

• Architecture: Decentralized network of nodes (full nodes, miners, SPV clients). No central server.

• Gossip Protocol: The primary message dissemination method.

  1. A node receives a new transaction/block.

  2. It verifies it locally.

  3. It forwards the valid item to all its connected peers.

  4. Peers repeat the process, causing exponential spread ("flooding").

• Function:

  • Transaction Propagation: Users broadcast signed transactions to the network.

  • Block Dissemination: Miners broadcast newly mined blocks. Nodes validate and adopt the longest valid chain.

[!TIP] Gossip is asynchronous and probabilistic. It's not guaranteed instant delivery but ensures high probability of network-wide propagation.

Proof-of-Work (PoW) & HashCash

• Mechanism: Miners compete to find a nonce such that:

$$ \text{Hash}(\text{Block Header}) < \text{Target} $$

Where the Target is a dynamically adjusted difficulty value.

*   The hash function (double SHA-256 in Bitcoin) makes this a **brute-force search**.

*   Finding a valid nonce is **easy to verify** but **computationally hard to find**.

• How PoW Secures the Network:

  1. Sybil Resistance: Creating network identity is cheap, but mining requires real-world resources (electricity, hardware).

  2. Cost of Attack: To rewrite history, an attacker must outpace the honest network's cumulative PoW, requiring >51% of the global hash power—prohibitively expensive.

  3. Leader Election: The miner who first finds a valid nonce gets to propose the next block (winning the "lottery").

• HashCash: The foundational PoW concept by Adam Back. A system where a sender must compute a PoW to send an email, proving they expended CPU cycles, thus deterring spam. Bitcoin adapted this for block creation.

[!TIP] PoW ties security to physical resources. The "work" is wasted computation (from a utility perspective) but is the security budget of the network.

The Byzantine Generals' Problem & Byzantine Fault Tolerance (BFT)

• Problem Definition: 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 to disrupt consensus. The challenge is to achieve reliable consensus despite arbitrary/malicious faults.

• Relation to Blockchain: Nodes in a distributed network are the "generals." Some may be malicious (Byzantine). The consensus algorithm must ensure all loyal nodes agree on the same transaction history, even with up to f faulty/malicious nodes.

• BFT Threshold Rule: For a system with n total nodes, it can tolerate up to:

$$ f < \frac{n}{3} $$

That is, the number of faulty nodes (`f`) must be **less than one-third** of the total nodes (`n`) for consensus to be possible.

[!TIP] The f < n/3 rule is fundamental. For n=3f+1 nodes, the system is BFT-safe.

Byzantine Fault Tolerance Algorithms

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

  • Approach: A recursive, message-passing algorithm for the oral messages model (messages can be forged by traitors).

  • Idea: The commander (proposer) sends an order to each lieutenant. Lieutenants exchange the orders they received. After m rounds of recursion (where m is the number of traitors the system can tolerate), a lieutenant uses a majority function over all received values (after recursive resolution).

  • Drawback: Message complexity is exponential: O(n^m). Impractical for large n or m.

• Practical BFT (PBFT):

  • State Machine Replication: All nodes (replicas) maintain the same state machine. Clients send requests; replicas execute them in the same order to maintain consistency.

  • Phases for a Single Consensus Instance:

    1. Pre-Prepare: Primary (leader) assigns a sequence number n to client request m and broadcasts <PRE-PREPARE, n, m>.

    2. Prepare: Each replica broadcasts <PREPARE, n, m, i> (where i is its ID) if it accepts the pre-prepare. A replica enters prepared state after receiving 2f matching prepare messages (including its own).

    3. Commit: Replicas broadcast <COMMIT, n, m, i>. A replica enters committed state after receiving 2f+1 matching commit messages (including its own). It can then execute the request and reply to the client.

  • View Change: If the primary is faulty, replicas trigger a view change to elect a new primary after timeout.

  • Complexity: Message complexity is O(n^2) per consensus instance—a massive improvement over Lamport's algorithm.

[!TIP] PBFT is state machine replication. Remember the three phases: Pre-Prepare → Prepare → Commit. The thresholds are 2f for prepare and 2f+1 for commit.

Paxos Algorithm

• Role: Achieves consensus in non-Byzantine (crash-fault-only) environments. It's the foundation for many permissioned systems (e.g., Raft, which is simpler).

• Key Roles:

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

  • Acceptor: Votes on proposed values. A quorum of acceptors must agree.

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

• Basic Flow (Simplified):

  1. Prepare Phase: Proposer picks a proposal number n and asks acceptors: "Promise not to accept proposals numbered < n?" (<PREPARE, n>).

  2. Promise: Acceptors respond with a promise, and if they've already accepted a proposal, they include that accepted value (<PROMISE, n, (n_a, v_a)>).

  3. Accept Phase: If proposer receives promises from a quorum (majority), it sends an accept request: <ACCEPT, n, v> (where v is the highest-numbered accepted value from promises, or its own value if none).

  4. Accepted: Acceptors that haven't promised a higher number reply <ACCEPTED, n, v>.

  5. Learn: Once a proposer sees ACCEPTED from a quorum, the value v is chosen. Learners are informed.

• Safety & Liveness: Paxos guarantees safety (only one value is chosen) under asynchrony with crash faults. Liveness (progress) requires some synchrony (a stable leader).

[!TIP] Paxos is crash-fault tolerant (CFT), not BFT. It assumes nodes fail-stop (crash), not malicious. The quorum size is majority (n/2 + 1).

Consensus in Permissioned vs. Permissionless Blockchains

[!TIP] Permissioned = known nodes → can use efficient BFT/CFT algorithms. Permissionless = unknown nodes → need Sybil resistance (PoW/PoS).

C. PLATFORM-SPECIFIC ARCHITECTURES & IMPLEMENTATIONS

Bitcoin: The First Implementation

• Miner's Role & Routines:

  1. Transaction Selection: Gather unconfirmed transactions from mempool, prioritize by fee.

  2. Block Creation: Assemble transactions into a candidate block (with coinbase transaction for reward).

  3. PoW Computation: Repeatedly modify the nonce (and extra nonce in coinbase) in the block header, double-SHA256 hashing it, until Hash(Header) < Target.

  4. Block Propagation: Upon finding a valid nonce, broadcast the new block to the P2P network.

  5. Reward Collection: Receive block subsidy (newly minted BTC, halves every 210,000 blocks) + transaction fees from all transactions in the block.

• Transaction Model: UTXO (Unspent Transaction Output)

  • Concept: The ledger does not track account balances. It tracks discrete, unspent outputs from previous transactions.

  • Transaction Structure: Consumes one or more UTXOs as inputs (proven by digital signature) and creates one or more new UTXOs as outputs.

  • Analogy: Like physical cash. You spend a whole "bill" (UTXO) and get change (new UTXOs) back. The set of all UTXOs is the UTXO set, representing all spendable BTC.

  • Advantage: Prevents double-spending by design—an output can only be spent once.

[!TIP] UTXO is the state in Bitcoin. Miners validate that transaction inputs are unspent UTXOs and properly signed.

Hyperledger Fabric (Permissioned Enterprise Framework)

• Modular Architecture:

  DiagramCANVAS: A three-layer diagram. 1. APPLICATION LAYER: Clients/SDKs submit transactions to Endorsing Peers. 2. CONSENSUS/ORDERING LAYER: Ordering Service (Raft/Kafka) receives endorsed transactions, orders them into blocks, delivers to Committing Peers. 3. LEDGER & SMART CONTRACT LAYER: Peers (Endorsing & Committing) maintain ledger (World State + Blockchain) and run Chaincode (Smart Contracts). Membership Service Provider (MSP) sits underneath, managing identities.

  • Separation of Concerns:

    • Consensus (Ordering Service): Orders transactions into blocks (Raft for crash fault tolerance, BFT-SMaRt for Byzantine). Does not execute chaincode.

    • Execution (Peers & Chaincode): Endorsing peers simulate transactions to produce read-write sets (endorsement). Committing peers validate and commit blocks.

    • Membership (MSP): Manages X.509 certificates for all entities, providing identity-based access control.

• Scalability & Performance:

  • Channels: Private subnets of communication between specific organizations. Ledger data is isolated per channel, providing privacy and reducing the load on non-participants.

  • Execute-Order-Validate Paradigm:

    1. Execute: Client sends transaction proposal to endorsing peers. They execute chaincode speculatively (without updating ledger) to produce a read-write set.

    2. Order: Endorsed transaction (with RW-set) sent to ordering service, which orders all transactions and creates blocks.

    3. Validate: Committing peers receive blocks, validate RW-sets against current world state (checking endorsement policy, read-set consistency), then commit updates.

    • Contrast with Order-Execute (e.g., Ethereum): Fabric's model allows parallel execution of non-conflicting transactions and separates consensus from execution, improving scalability.

• Chaincode (Smart Contracts):

  • Languages: Go, Java, JavaScript (Node.js).

  • Lifecycle: Install on peers → Approve for organization → Commit to channel (defines endorsement policy).

  • Endorsement Policy: Specifies which set of peers (by org/MSP) must endorse a transaction for it to be valid (e.g., "Org1 AND Org2" or "1 of Org1, Org2, Org3").

[!TIP] Fabric's key innovation is execute-order-validate. Channels are its privacy mechanism. Endorsement policy is the smart contract's "quorum" rule.

Ripple & Corda (Alternative DLTs)

• Ripple (XRP Ledger):

  • Consensus Protocol: RPCA (Ripple Protocol Consensus Algorithm).

  • Mechanism: A unique node list (UNL) is maintained by each server. Consensus rounds: servers propose candidate transaction sets; each server merges proposals from its UNL; voting occurs until >80% agreement on a ledger update.

  • Focus: Real-time gross settlement system, currency exchange, and remittance. Native cryptocurrency is XRP used as a bridge currency.

  • Gateways: Trusted entities that hold and manage deposits/withdrawals of traditional currencies, issuing digital IOUs on the ledger.

  • No Mining: All 100 billion XRP were pre-mined. Validators are known entities (banks, payment providers).

• Corda:

  • Philosophy: "Not a blockchain." It's a distributed ledger with no global broadcast of data.

  • Architecture:

    • Point-to-Point Communication: Transactions are shared only with necessary counterparties (not all nodes).

    • Notary Clusters: Provide consensus on transaction uniqueness (prevent double-spend). A notary is a single node or a cluster using BFT/CFT consensus. It stamps transactions as valid/consumed.

    • States & Contracts: Data is represented as states (agreed facts). Contracts (code in Kotlin/Java) define the rules for state evolution (consuming input states, creating output states).

    • Flow Framework: Allows parties to coordinate a transaction step-by-step (e.g., "I propose, you agree, we sign, we notarize").

  • Focus: Legal agreements, trade finance, supply chain. Privacy and regulatory compliance are paramount.

[!TIP] Ripple = fast consensus for payments, uses UNL. Corda = point-to-point, legal agreement focus, notary for uniqueness.

D. ADVANCED FEATURES & SMART CONTRACTS

Smart Contracts

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

• Potential Applications:

  • Finance: Automated loans, derivatives, insurance claims.

  • Supply Chain: Automated payments upon delivery verification (IoT sensor data).

  • Real Estate: Automated title transfer upon payment.

  • IoT: Machine-to-machine transactions and data marketplaces.

• Platforms:

  • Ethereum: General-purpose Turing-complete blockchain. Smart contracts are deployed to the EVM, have their own addresses, and can hold value (ETH). Focus on decentralization and censorship resistance.

  • Hyperledger Fabric/Corda: Business logic focused. Contracts (chaincode) enforce business policies and access control within a permissioned, privacy-aware consortium. Not necessarily public or holding native cryptocurrency.

[!TIP] Ethereum smart contracts are public and global. Fabric/Corda contracts are private and permissioned. This is the core difference.

Cryptocurrency & Tokenomics (Bitcoin Context)

• Role of Mining:

  • Currency Issuance: Block subsidy introduces new BTC into circulation according to a fixed, disinflationary schedule (halving every ~4 years, capped at 21 million).

  • Security: PoW secures the network by making block creation costly.

• Halving Events: Every 210,000 blocks (~4 years), the block subsidy is cut in half. This reduces the inflation rate, creating digital scarcity. Past halvings: 2012 (50→25), 2016 (25→12.5), 2020 (12.5→6.25), next ~2024 (6.25→3.125).

• Transaction Fees: Users attach fees to incentivize miners to include their transactions. Fees become the primary miner reward once block subsidy approaches zero (~2140). Fee market determines priority.

[!TIP] Tokenomics = token supply schedule (halving) + incentive structure (fees vs. subsidy).

E. APPLICATIONS, CHALLENGES & REGULATORY ASPECTS

Supply Chain Management

• Impact on International Trade:

  • Provenance & Traceability: Immutable record of an asset's journey from origin to consumer. Combats counterfeiting (e.g., pharmaceuticals, luxury goods).

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

  • Automation: Smart contracts trigger actions (payments, notifications) upon predefined conditions (e.g., "temperature stayed below 5°C," "goods received at port").

• Supply Chain Financing (e.g., Invoice Factoring):

  • Problem: SMEs face cash flow gaps due to long payment terms. Factoring (selling invoices at a discount) is slow, paper-heavy, and risky.

  • Blockchain Solution:

    1. Invoice is tokenized on a permissioned blockchain (e.g., between supplier, buyer, and financier).

    2. Buyer's commitment to pay is cryptographically verified and immutable.

    3. Financier can instantly verify invoice authenticity and buyer credit, reducing risk and cost.

    4. Smart contract automates payment to financier when buyer pays, closing the loop.

  • Result: Faster access to capital, lower financing costs, reduced fraud.

[!TIP] Link traceability (provenance) to automation (smart contracts) to financing (verified assets = lower risk).

Know Your Customer (KYC) & Identity

• Key Components of KYC:

  1. Customer Identification: Collecting documents (passport, ID).

  2. Identity Proofing: Verifying documents are genuine and belong to the customer.

  3. Ongoing Monitoring: Screening against PEPs, sanctions lists; monitoring transactions for suspicious activity.

• How Blockchain Streamlines KYC:

  • Reusable Digital Identity: A customer undergoes KYC once with a trusted entity (e.g., a bank). The verified attestation (not raw documents) is stored on a blockchain (or hash of it).

  • Verifiable Credentials: Other institutions can request and verify the KYC attestation directly from the customer via the blockchain, with customer consent. No need to re-submit documents.

  • Benefits: Reduces redundancy, lowers compliance costs, improves customer experience, enhances data integrity.

[!TIP] Blockchain doesn't store PII. It stores verifiable attestations/hashes. The customer controls consent for sharing.

Design Considerations for Enterprise Blockchains

• Permissioned vs. Permissionless: Permissioned is almost always chosen for enterprise use (known participants, regulatory compliance, performance).

• Privacy:

  • Channels (Fabric): Isolate data subsets.

  • Zero-Knowledge Proofs (ZKPs): Prove a statement is true without revealing underlying data (e.g., prove you have sufficient balance without revealing amount).

  • Private Data Collections (Fabric): Store sensitive data off-ledger, only hashes on-chain.

• Scalability, Throughput, Latency: Define requirements (TPS, confirmation time). Permissioned BFT algorithms (PBFT) offer finality but scale poorly with n. Raft scales better but is CFT.

• Governance: Who decides protocol upgrades? How are disputes resolved? Clear governance model is critical for consortiums.

• Legal Enforceability: Are smart contracts legally binding? Must align with existing contract law. "Code is law" is a nuanced principle; off-chain legal agreements often still govern.

[!TIP] Enterprise design is a trade-off triangle: Decentralization vs. Scalability vs. Privacy. You can usually optimize for two.