High Performance computing (AL-802 (B)) Unit 5 Notes

UNIT 5: BLOCKCHAIN TECHNOLOGIES & DISTRIBUTED SYSTEMS

I. FOUNDATIONS OF BLOCKCHAIN ARCHITECTURE

A. The Public Ledger Concept

Definition: A public ledger is a decentralized, append-only digital record of all transactions shared across a network of nodes. It functions as the single source of truth.
In Financial Transactions: It replaces traditional centralized intermediaries (like banks) by allowing direct peer-to-peer value transfer. Every participant can independently verify the entire transaction history.
Key Principles:
- Immutability: Once data is written, it is extremely difficult to alter. Achieved via cryptographic hashing and chaining.
- Transparency: All transactions are visible to all network participants (in a public blockchain).
Decentralization vs. Centralization:

| Feature | Centralized Ledger | Decentralized (Blockchain) Ledger | | :--- | :--- | :--- | | Control | Single entity (e.g., bank) | Distributed across network nodes | | Single Point of Failure | Yes | No | | Trust Model | Trust in central authority | Trust in protocol/cryptography | | Transparency | Private/restricted | Public (typically) |

B. Block Structure & Chaining

Anatomy of a Block:
```
[Block Header] | [Transaction Counter] | [List of Transactions]
```
- Block Header: Contains metadata: Version, Previous Block Hash, Merkle Root, Timestamp, Difficulty Target, Nonce.
- Transactions: The actual data (e.g., financial transfers, smart contract calls).
- Nonce: A number miners change to solve the Proof-of-Work puzzle.
"Block Within a Block" (Chaining): Each block's header contains the cryptographic hash of the previous block's header. This creates a linked list where altering any block would require re-computing all subsequent hashes, ensuring immutability.

$$ \text{Hash}_i = \text{Hash}(\text{Header}_i) \quad \text{where} \quad \text{Header}_i \text{ contains } \text{Hash}_{i-1} $$

\boxed{\text{Chain Integrity: } H_n = f(H_{n-1}, \text{data}_n)}

Genesis Block: The first block in the chain (block #0). It has no previous hash and is hard-coded into the protocol.

C. Merkle Trees (Hash Trees)

Structure: A binary tree where:
- Leaf Nodes: Hashes of individual transactions.
- Parent Nodes: Hashes of concatenated child hashes.
- Root Hash (Merkle Root): A single hash stored in the block header, representing all transactions in the block.
```
      Root Hash (in Block Header)

      /           \

  Hash(A,B)     Hash(C,D)

  /      \      /      \

Hash(A)  Hash(B) Hash(C) Hash(D)
```
Role & Merkle Proofs:
- Efficient Verification: A lightweight client (e.g., mobile wallet) can verify a specific transaction is in a block without downloading the entire block. It only needs the transaction hash and a few sibling hashes (the Merkle Proof) to recompute the root.
- Data Integrity: Any change to a single transaction completely changes the root hash, making tampering evident.
- Application: Crucial for Simplified Payment Verification (SPV) in Bitcoin.

[!TIP] Exam Focus: Be ready to draw a simple Merkle Tree and explain how an SPV client uses a Merkle Proof to verify a transaction with minimal data.

II. CONSENSUS MECHANISMS & FAULT TOLERANCE

A. Proof-of-Work (PoW)

HashCash Mechanism: A computational puzzle where miners must find a nonce such that:

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

The target is a very small number, making the hash output start with many zeros. This requires massive trial-and-error (brute force).

Security Role:
- Sybil Attack Prevention: Creating network identity (computational power) is costly, deterring fake nodes.
- Chain Security: An attacker needs >51% of the network's total hash power to rewrite history, which is economically prohibitive in large networks like Bitcoin.
Mining Process:
1. Collect pending transactions.
2. Create a candidate block template.
3. Iterate the nonce, compute the double-SHA256 hash.
4. If hash < target, broadcast the new block.
5. Difficulty Adjustment: Every 2016 blocks (~2 weeks), the target is recalculated to maintain an average block time of 10 minutes.

B. The Byzantine Generals' Problem & Fault Tolerance

Problem Definition: How can a group of Byzantine Generals (distributed nodes) surrounding a city achieve agreement on a common plan of action (attack/retreat) when some generals may be traitors (malicious/faulty) who send conflicting messages?
Relation to Blockchain: It models the challenge of achieving distributed consensus in a permissionless network where nodes can be arbitrary, malicious, or offline.
Lamport-Shostak-Pease (Oral Messages) Algorithm (OM(m)):
- Goal: Achieve consensus if ≤ m traitors exist in a network of n nodes, where n > 3m.
- Process (Recursive): The commanding general sends an order to each lieutenant. Each lieutenant, upon receiving an order, acts as a new commander and forwards it to other lieutenants (recursively for m levels).
- Decision: After recursion, each lieutenant uses a deterministic majority function on all received orders (including the path of messages) to decide.
- Handling Faults: The recursive message-passing and majority rule allow honest nodes to "outvote" conflicting messages from traitors.
- Message Complexity: Exponential, O(n^m). Impractical for large m.

C. Practical Consensus Algorithms

Paxos Algorithm (for Permissioned Systems):
- Roles:
  - Proposer: Suggests a value (e.g., a block).
  - Acceptor: Votes on proposed values. A majority (Quorum) must accept.
  - 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: Proposer sends a proposal with a value. Acceptors accept if they haven't promised a higher-numbered proposal.
  3. Learn: Once a majority accepts, the value is chosen and learned by all.
- Guarantees: Safety (no two nodes decide different values) and Liveness (eventually a value is decided) in asynchronous networks with crash faults.
Comparison: PoW vs. Paxos

| Feature | Proof-of-Work (Bitcoin) | Paxos | | :--- | :--- | :--- | | Type | Probabilistic (finality is probabilistic) | Deterministic (finality is absolute) | | Network | Permissionless (anyone can join) | Permissioned (known, vetted participants) | | Fault Model | Byzantine (Sybil) | Crash faults (nodes fail-stop) | | Efficiency | Low TPS, high energy | High TPS, low energy | | Finality | Requires ~6 confirmations | Immediate upon quorum |

[!TIP] Common Pitfall: Do not confuse Byzantine fault tolerance (arbitrary/malicious faults) with crash fault tolerance (nodes just stop). Paxos assumes the latter; algorithms like PBFT handle the former.

III. NETWORK OPERATIONS & MINING ECOSYSTEM

A. Peer-to-Peer (P2P) Network Architecture (Bitcoin)

Structure: A decentralized, unstructured overlay network where nodes (peers) connect to a few random neighbors.
Gossip Protocol (Flooding): The primary propagation method.
1. A node receives a new transaction/block.
2. It validates it locally.
3. It forwards it to all its connected peers (except the sender).
4. Peers repeat the process. This ensures rapid, resilient dissemination.
Node Discovery: Initial connections via DNS seeds. New nodes ask peers for their peer lists.
Facilitating Transfer: This P2P gossip ensures all honest nodes eventually have the same ledger copy, enabling decentralized validation of ownership without a central server.

B. The Life & Role of a Bitcoin Miner

Daily Operational Routines:
1. Transaction Selection: Listen to the P2P network's mempool (pending transactions). Prioritize transactions with higher fees.
2. Block Template Creation: Build a candidate block: coinbase transaction (new BTC + fees), selected transactions, set header fields (prev hash, merkle root, timestamp).
3. Mining: Run the PoW algorithm (double-SHA256) on the block header, changing the nonce and extra nonce.
4. Block Propagation: Upon finding a valid nonce, immediately broadcast the new block to the network.
Hardware Evolution & Energy:
- CPU (2009-2010): General-purpose, inefficient.
- GPU (2010-2013): Parallel processing, ~10-100x faster.
- ASIC (2013-Present): Application-Specific Integrated Circuits. 100,000x+ more efficient than CPU. Major criticism: High energy consumption (global Bitcoin energy use comparable to a medium-sized country).
Economic Incentives:
- Block Reward: Newly minted bitcoins (currently 3.125 BTC, halves ~every 4 years). Primary incentive.
- Transaction Fees: Sum of fees from all transactions in the block. Becomes dominant incentive after ~2140 when block reward goes to zero.
Contribution: Miners are the security engine. They order transactions, prevent double-spends, and their computational power secures the chain. More hash power = more expensive to attack.

IV. PERMISSIONED vs. PERMISSIONLESS BLOCKCHAINS

A. Design Considerations for Permissioned Blockchains

Identity Management: All participants have known, verified identities (via Membership Service Provider - MSP). No anonymity.
Consensus Mechanism: Non-PoW. Uses deterministic, efficient protocols like:
- PBFT (Practical Byzantine Fault Tolerance): Tolerates <1/3 Byzantine nodes, high message complexity.
- Raft: Crash-fault tolerant, leader-based, simpler and faster.
Privacy & Confidentiality: Channels (private subnets) allow transaction privacy between specific subsets of participants. Data is not visible to all.
Governance: Clear, pre-agreed rules for membership, smart contract upgrades, and dispute resolution.
Scalability Trade-offs: Higher TPS (thousands/sec) and lower latency than permissionless chains, but at the cost of reduced decentralization and censorship resistance.

B. Enterprise Blockchain Frameworks: Hyperledger Fabric

Modular Architecture:
- Pluggable Consensus (Ordering Service): Separates transaction ordering from validation. Can use Raft, PBFT, etc.
- Pluggable Membership Service (MSP): Manages identities and access control.
Scalability via Channels: Private subnets where only relevant members see transactions and ledger data. This isolates the workload and enhances privacy.
Execute-Order-Validate Paradigm:
1. Execute: All peers in a channel execute smart contracts (Chaincode) to produce a read-write set (proposed ledger updates). No consensus here.
2. Order: Ordering service sequences all transactions into a block (no execution).
3. Validate: Peers validate the block's transactions against their read-write sets and endorsement policies. Only then are updates committed.
- Benefit: Parallel execution and validation increase throughput.
Components:
- Peers: Host ledgers and chaincode. Endorsing Peers simulate transactions.
- Ordering Nodes: Form the ordering service, create blocks.
- Chaincode: Smart contracts written in Go/Java/JavaScript.

[!TIP] Key Differentiator: Fabric's execute-order-validate vs. Ethereum's order-execute. Fabric's model allows for more scalability and privacy.

V. SMART CONTRACTS & APPLICATIONS

A. Smart Contract Fundamentals

Definition: Self-executing code stored on a blockchain that automatically enforces the terms of an agreement when predefined conditions are met.
Key Properties:
- Immutability: Once deployed, code cannot be changed (unless upgrade mechanisms are built-in).
- Determinism: Given the same input and state, it must produce the same output. Critical for network consensus.
- Trustlessness: Parties do not need to trust each other; they trust the code and the blockchain's execution.
Applications: Decentralized Finance (DeFi), automated supply chain payments, digital identity, royalty distribution, IoT device coordination.

B. Industry-Specific Applications

Supply Chain Financing:
- Problem: SMEs face cash flow gaps due to slow invoice payments. Traditional financing is paper-heavy and risky.
- Blockchain Solution: Digitize invoices and trade documents on a permissioned blockchain. All parties (supplier, buyer, financier) share a single, immutable view.
- Impact: Enables invoice financing where financiers can instantly verify invoice authenticity, reducing counterparty risk and speeding up funding.
Impact on International Trade & Global Supply Chains:
- Provenance Tracking: Immutable record of a product's journey from raw material to consumer. Combats counterfeit goods.
- Automation of Letters of Credit (LCs): Smart contracts can automate LC payments upon verified delivery (via IoT sensor data or document upload), reducing processing from days to hours.
- Reduction in: Paperwork, fraud, delays, and administrative costs. Increases transparency and trust among unknown trading partners.

VI. PLATFORM-SPECIFIC STUDIES & REGULATORY FRAMEWORKS

A. Ripple & Corda

Ripple (XRP Ledger):
- Focus: Cross-border payments and liquidity for financial institutions (banks, payment providers).
- Consensus Protocol (RPCA): A permissioned consensus algorithm using a Unique Node List (UNL). Validators (known entities) vote on transaction order. Fast (~3-5 sec finality), low cost.
- Institutional Use: Banks use RippleNet and On-Demand Liquidity (ODL) with XRP as a bridge currency to avoid pre-funded nostro accounts.
Corda:
- Design: Built exclusively for regulated institutions (banks, insurers, trade finance). Not a general-purpose blockchain.
- Point-to-Point Messaging: Transactions are shared only with necessary counterparties, not broadcast to the whole network. Privacy by design.
- Consensus Services: Uses a Notary service (single or cluster) for transaction uniqueness (prevents double-spend). The notary does not see transaction content.
- Key Difference: No global ledger. Each node maintains its own vault of relevant states.
Comparative Analysis:

| Feature | Ripple (XRP Ledger) | Corda | | :--- | :--- | :--- | | Primary Use Case | Cross-border payments | Regulated business networks (trade finance, insurance) | | Data Sharing Model | Global ledger (all validators see all transactions) | Point-to-point (only counterparties see transaction) | | Consensus | RPCA (permissioned validator voting) | Notary service for uniqueness; transaction validity is bilateral | | Cryptocurrency | Has native token (XRP) for security & liquidity | No native token |

B. Regulatory & Compliance Layer: KYC

KYC Process Components:
1. Identity Verification: Government-issued ID (passport, driver's license), proof of address.
2. Document Screening: Sanctions lists (OFAC), PEPs (Politically Exposed Persons), adverse media.
3. Risk Assessment: Customer risk profile (low/medium/high) based on activity, jurisdiction, etc.
Importance for AML: KYC is the first line of defense against money laundering and terrorist financing. It establishes the true identity of the customer, enabling monitoring of suspicious activity.
Blockchain's Potential:
- Streamlining: A verified, reusable digital identity (self-sovereign identity) on a permissioned blockchain could let customers prove identity to multiple institutions once, reducing repetition and cost.
- Security: Immutable audit trail of identity checks and document submissions.
- Challenges: Privacy regulations (GDPR), interoperability between different institutional blockchains.

[!TIP] Exam Connection: Link KYC to permissioned blockchains. Permissioned chains with known identities are naturally suited for compliant financial applications where KYC is mandatory.

END OF UNIT 5 NOTES

Account

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