Blockchain Technology (IT-803 (A)) - Unit 2 Short Notes

UNIT 2: BLOCKCHAIN TECHNOLOGY - SHORT NOTES

1.0 FOUNDATIONAL CONCEPTS & DATA STRUCTURES

1.1 Cryptographic Hash Functions

A cryptographic hash function is a one-way mathematical function that maps input data of any size to a fixed-size output (hash/digest).

Core Properties:

Role in Blockchain:

• Linking Blocks: Previous Block Hash in header uses hash of prior block's header, creating an immutable chain.

• Data Integrity: Any change in block body (transactions) changes its Merkle root and thus the block hash.

• Digital Signatures: Hashes of messages are signed, not the entire message, for efficiency.

[!TIP] Exam Focus: Be ready to define each property and give a blockchain-specific example (e.g., "Collision resistance prevents an attacker from creating a different block with the same hash as a valid one").

1.2 Merkle Trees (Hash Trees)

A Merkle Tree is a binary tree where every non-leaf node is the hash of its two child nodes.

Structure & Construction:

1. Leaf Nodes: Hashes of individual transactions (or data chunks).

2. Parent Nodes: Concatenate & hash child pairs: Hash(Hash(Tx1) + Hash(Tx2)).

3. Root Hash (Merkle Root): Single hash at the top, stored in the block header. Represents all transactions in the block.

        Root = H(H(A)+H(B))

           /        \

      H(H(A)+H(B))  H(H(C)+H(D))

       /     \      /     \

     H(A)   H(B)  H(C)   H(D)

     /       /    /       /

    TxA    TxB  TxC    TxD  (Leaf Nodes)

Importance in Blockchain:

• Efficient Verification (Merkle Proofs): A light client (SPV) can verify a transaction is in a block by receiving only the transaction hash and a few sibling hashes (~log₂N), not the entire block.

• Data Integrity: Any change to a single transaction changes its leaf hash, propagating up to alter the root hash. Root in header would not match.

• Scalability: Enables lightweight clients and simplifies block propagation (only need to send new transactions, not entire block history).

[!TIP] Common Pitfall: Merkle Trees are for efficient verification, not for storing the full transaction list. The block body still stores all transactions.

1.3 Block Structure

A block is a container for a set of transactions, cryptographically linked to its predecessor.

Components:

Purpose: The header components collectively ensure immutability (via hashing), consensus (via PoW fields), and integrity (via Merkle root).

[!DIAGRAM: CANVAS] Draw this: A box labeled "Block". Inside, a top section "Block Header" with 6 labeled fields (Version, Prev Hash, Merkle Root, Timestamp, Bits/Difficulty, Nonce). Below, a section "Block Body" with "Tx Count" and a list of "Transaction 1, Transaction 2,...".

2.0 CONSENSUS MECHANISMS

2.1 Introduction to Consensus

Consensus is the mechanism by which all nodes in a distributed network agree on a single, consistent version of the ledger (the "truth").

Critical Need: Solves the Byzantine Generals' Problem—how to achieve agreement in a trustless, decentralized system with potentially faulty/malicious nodes.

Primary Goals:

1. Agreement: All honest nodes agree on the same block sequence.

2. Liveness: The network continues to produce new blocks (transactions get confirmed).

3. Safety: Once a block is confirmed, it cannot be reversed (finality).

2.2 Proof-of-Work (PoW)

Mechanism: Miners compete to find a nonce such that the block header hash is below a difficulty target.

$$H(\text{Version} \parallel \text{PrevHash} \parallel \text{MerkleRoot} \parallel \text{Timestamp} \parallel \text{Bits} \parallel \text{Nonce}) < \text{Target}$$

• Cryptographic Puzzle: Brute-force search for a valid nonce.

• Hashing Difficulty: Target is adjusted periodically (e.g., every 2016 blocks in Bitcoin) to maintain average block time (~10 mins).

• Winner: First miner to find a valid nonce broadcasts the block. Others verify the PoW and the transactions.

Bitcoin's Implementation:

• Block Reward: New BTC + transaction fees. This incentivizes mining.

• Transaction Selection: Miners pick transactions from mempool, prioritizing those with higher fees.

• Difficulty Adjustment: Every 2016 blocks, recalculate target based on actual time taken vs. expected (2 weeks).

Attacks & Challenges:

Historical Context: HashCash (Adam Back, 1997) was an early PoW system to combat email spam. Bitcoin adapted it for consensus.

[!TIP] Exam Focus: Be prepared to write the PoW equation and explain the difficulty adjustment formula conceptually.

2.3 Alternative Consensus for Public/Permissionless: Proof-of-Elapsed-Time (PoET)

• Mechanism: Uses Intel SGX (Software Guard Extensions) trusted execution environment.

• Process:

  1. Each validator randomly waits for a randomly chosen time (like a lottery timer) within an SGX enclave.

  2. The validator whose timer expires first is the leader and proposes the next block.

  3. Others verify the wait time was legitimately generated within SGX.

• Advantages: Low energy consumption (no hashing race), fair leader selection.

• Disadvantages: Requires trusted hardware (Intel SGX), potential SGX vulnerability exploits.

• Use Case: Hyperledger Sawtooth.

2.4 Consensus for Permissioned Blockchains

Byzantine Fault Tolerance (BFT) & PBFT

• Goal: Tolerate up to f Byzantine (malicious/faulty) nodes in a network of 3f+1 total nodes.

• Lamport-Shostak-Pease (BFT) Algorithm: The foundational theoretical algorithm. PBFT is its practical implementation.

• PBFT Operation Phases (for a single consensus instance):

  1. Pre-prepare: Leader assigns a sequence number to client request and broadcasts <<PRE-PREPARE, view, seq-no, digest>>.

  2. Prepare: Each node broadcasts <<PREPARE, view, seq-no, digest, node-id>> if request is valid. A node collects 2f matching PREPARE messages.

  3. Commit: Node broadcasts <<COMMIT, view, seq-no, digest, node-id>>. Collects 2f+1 matching COMMIT messages → committed.

  4. Reply: Execute request and send reply to client. Client needs f+1 matching replies.

• Use Case: Original Hyperledger Fabric (pre-1.0).

Raft Consensus Algorithm

• Type: Crash Fault Tolerant (CFT), not BFT. Assumes nodes only fail/crash, not act maliciously.

• Mechanism: Leader-based log replication.

• Key Roles & Terms:

  • Leader: Handles all client requests, appends to log, replicates to followers.

  • Follower: Passive, receives log entries from leader.

  • Candidate: Used during elections.

  • Term: Arbitrary increasing index for leader elections (like "epoch").

  • Log: Ordered list of commands/transactions.

  • Commit Index: Highest log index known to be committed.

• Process:

  1. Election: If follower doesn't hear from leader (election timeout), becomes candidate, votes for self, requests votes. Wins if gets majority → becomes leader.

  2. Log Replication: Leader appends new entry to its log, sends AppendEntries RPC to followers. Once replicated on majority, entry is committed.

• Comparison with PBFT:

  | Feature | PBFT (BFT) | Raft (CFT) | | :--- | :--- | :--- | | Fault Model | Byzantine (malicious) | Crash-only | | Complexity | High (O(n²) messages) | Low (O(n) messages) | | Performance | Lower throughput, higher latency | Higher throughput, lower latency | | Use Case | High-security consortiums | General permissioned enterprise |

[!TIP] Exam Focus: Know the 3f+1 rule for BFT. Be able to contrast Raft's leader-based simplicity with PBFT's multi-phase voting.

2.5 Bitcoin-Specific Consensus & Networking

Bitcoin P2P Network Architecture:

• Node Discovery: Uses DNS seeds, hardcoded addresses, and addr message propagation.

• Message Propagation: Key messages: inv (inventory), getdata (request data), tx (transaction), block (block).

• Flooding Protocol: Nodes advertise new txs/blocks via inv, peers request with getdata.

Transaction & Block Propagation Workflow:

1. User creates/signs transaction → broadcasts to connected peers (tx message).

2. Peers validate (scripts, fees, no double-spend) → add to mempool → forward to other peers (after inv/getdata).

3. Miner assembles block from mempool → solves PoW → broadcasts new block (block message).

4. Nodes validate block (PoW, txs, prev hash) → add to chain → forward to peers.

Block Mining Process:

1. Transaction Selection: Pick txs from mempool, prioritize high-fee.

2. Fee Calculation: Sum of (input value - output value) for all txs.

3. Block Assembly: Create coinbase tx (block reward), build Merkle root, fill header.

4. PoW Computation: Iterate nonce (and extra nonce in coinbase) to find header hash < target.

5. Block Propagation: Broadcast winning block to network.

Types of Mining:

• Solo Mining: Individual miner. Very low probability of finding block; high variance in rewards.

• Pool Mining: Miners contribute hash power to a pool. Pool operator finds block, rewards split proportionally. Reduces variance.

[!TIP] Common Pitfall: Miners don't "verify transactions" in the sense of executing scripts—they include valid transactions from their mempool. Full nodes do the full validation upon block receipt.

3.0 SMART CONTRACTS

3.1 Definition & Essential Characteristics

A smart contract is self-executing code stored on a blockchain that automatically enforces the terms of an agreement when predefined conditions are met.

Essential Characteristics:

1. Self-executing: Runs automatically without intermediary upon trigger (e.g., tx receipt).

2. Immutable: Once deployed, code cannot be changed (unless upgrade mechanism built-in).

3. Deterministic: Same input (state + tx) → same output, on any node.

4. Trigger-based: Executed in response to transactions or events.

5. Stateful: Can store and modify state on the blockchain.

Development Lifecycle:

1. Writing: Code in high-level language (Solidity, Go).

2. Deployment: Compiled to bytecode, deployed via a special transaction (creates contract address).

3. Execution: Users interact by sending transactions to the contract's address with function call data.

4. Termination: Contract can be "killed" only if code includes a selfdestruct function (Ethereum) or is upgraded (Fabric).

3.2 Bitcoin Script (Stack-based, Non-Turing Complete)

• Purpose: Simple locking/unlocking script mechanism for transaction validation. Not for general computation.

• Stack-based: Operates on a LIFO stack. Opcodes push/pop values.

• Non-Turing Complete: No loops, bounded execution (max 201 opcodes), stateless. Prevents infinite loops/DOS.

• Script Types:

  • Pay-to-Public-Key-Hash (P2PKH): Standard. scriptSig (signature+pubkey) must satisfy scriptPubKey (hash of pubkey).

  • Pay-to-Script-Hash (P2SH): Allows complex scripts. scriptPubKey contains hash of redeem script. scriptSig provides redeem script + data.

  • Multi-signature (Multisig): Requires M signatures from N public keys (e.g., 2-of-3).

• Limitations: No state between txs, no loops, limited opcodes → cannot express complex logic.

3.3 Ethereum Smart Contracts (Turing Complete)

• High-level Languages: Solidity (JS-like), Vyper (Python-like, security-focused).

• Ethereum Virtual Machine (EVM):

  • Execution Environment: Sandboxed, deterministic runtime on every node.

  • Gas Model: Each EVM operation costs gas. Prevents infinite loops/DOS. User pays gas fee (gasUsed * gasPrice).

  • State Transitions: Contract execution changes global state (account balances, storage).

• Process:

  1. Write Solidity code.

  2. Compile to EVM bytecode (and ABI).

  3. Deploy: Send transaction with bytecode as data → creates contract address.

  4. Interact: Send transaction to contract address with function selector + args. EVM executes on all nodes.

3.4 Hyperledger Fabric Smart Contracts (Chaincode)

• Writing Chaincode:

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

  • Endorsement Policies: Define which peers must execute/endorse a tx for it to be valid (e.g., "Org1's peer AND Org2's peer").

  • Access Control: Uses Fabric identities (MSP) to control who can invoke which functions.

• Deployment & Lifecycle:

  1. Install: Chaincode package installed on endorsing peers.

  2. Instantiate/Upgrade: On a channel, define initial policy, endorsement policy, and init args. (Fabric v2.x uses "commit" after approval).

• Invocation Flow:

  Client App → Endorsing Peers (execute, simulate) → Ordering Service (order txs) → Committing Peers (validate, commit)

[!TIP] Key Difference: Ethereum contracts run on all nodes. Fabric chaincode runs only on endorsing peers for simulation; all peers commit the result. This enables privacy (data stays on endorsing peers).

4.0 BLOCKCHAIN TAXONOMY & PLATFORMS

4.1 Public vs. Private vs. Permissioned Blockchains

4.2 Enterprise Blockchain Platforms

Hyperledger Fabric

• Architecture:

  • Peers: Host ledgers & chaincode. Endorsing peers execute chaincode.

  • Ordering Service: Consensus on tx order (Raft, Kafka, Solo). Does not execute chaincode.

  • Channels: Private subnets. Ledger data isolated per channel.

  • Membership Service Provider (MSP): Manages identities (X.509 certs) for orgs/users.

• Key Concepts:

  • Ledger: Comprises World State (current DB of assets) & Blockchain (immutable log of all txs).

  • Chaincode: Smart contract. Runs in Docker container.

  • Endorsement Policy: Which peers must endorse a tx (e.g., AND('Org1.peer', 'Org2.peer')).

  • Private Data Collections: Sensitive data shared only among specific orgs, not on all peers.

• Use Cases: Supply chain traceability (food, diamonds), trade finance, healthcare records.

R3 Corda

• Design Philosophy: Not a blockchain. A distributed ledger with privacy-by-design. No global broadcast of all data.

• Key Concepts:

  • States: Immutable facts (e.g., CashState, IOUState). Represent current data.

  • Contracts: Define legal rules for state evolution. Code + legal prose.

  • Notaries: Provide uniqueness consensus (prevent double-spend). Can be validating (see all data) or non-validating.

  • Flows: Encapsulate business logic for node communication (e.g., InitiatorFlow, ResponderFlow).

  • Corda Network: Network of nodes (legal entities) with point-to-point communication.

• Use Cases: Inter-bank settlements, trade finance, syndicated loans.

Ripple (XRP Ledger)

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

  • Unique Node List (UNL): Each node has a list of trusted validators it listens to.

  • Process: Validators propose candidate sets, iterate until 80%+ agreement on a ledger version.

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

• Focus: Cross-border payments & digital assets. Gateways issue IOUs (BTC, USD, etc.). XRP used as bridge currency for liquidity.

• Native Crypto: XRP (used for anti-spam transaction fee, destroyed on each tx).

5.0 APPLICATIONS & USE CASES

5.1 Financial Services

Cross-Border Payments

• Traditional: SWIFT, correspondent banking → slow (3-5 days), expensive (high fees), opaque.

• Blockchain (Ripple):

  • Disintermediation: Direct transfer between institutions via RippleNet.

  • Speed: Settlements in seconds.

  • Cost: Lower fees (using XRP as bridge asset reduces nostro accounts).

  • Transparency: Real-time tracking.

Supply Chain Finance

• Traditional: Manual invoices, delays in payments, fraud risk (duplicate financing).

• Blockchain Improvement:

  • Single Source of Truth: Immutable record of goods movement (IoT + blockchain).

  • Automated Payments: Smart contracts trigger payment upon verified delivery (via IoT sensor data or document hash).

  • Invoice Financing: Banks can verify invoice authenticity on-chain → faster credit, lower risk.

  • Reduced Fraud: Prevents duplicate invoice submission.

Mortgages

• Traditional Process: Paper-heavy, multiple intermediaries (lenders, title companies, escrow), slow (30-60 days), fraud risk.

• Blockchain Mortgage:

  • Digital Identity & KYC: Reusable, verifiable credentials.

  • Smart Contract Escrow: Automatically release funds to seller upon title transfer.

  • Automated Title Transfer: Title as a digital asset on-chain; transfer is atomic with payment.

  • Reduced Fraud: Immutable history of ownership, liens.

  • Faster Closing: Automated workflows reduce manual verification.

5.2 Identity Management

• Self-Sovereign Identity (SSI): User owns and controls their identity data, not a central authority.

• Blockchain Role:

  • Decentralized Identifiers (DIDs): Unique IDs anchored on-chain, pointing to off-chain data.

  • Verifiable Credentials (VCs): Issuer signs credential (e.g., "Degree from University X"). User presents VC; verifier checks signature + issuer's DID on-chain.

  • Immutable Audit Trail: All credential issuances/revocations logged.

• Benefits: Privacy (minimal disclosure), Security (no central DB hack), User control, Reduced identity theft.

5.3 Industry-Specific Implementations (Hyperledger Fabric)

• Healthcare: Secure, permissioned sharing of patient records among hospitals, insurers, labs. Patient controls access.

• Diamond Tracking: Track diamond from mine to retailer (e.g., Everledger). Record characteristics, ownership history to prevent conflict diamonds.

• Food Safety: Trace produce from farm to store (e.g., IBM Food Trust). Rapid source identification during contamination outbreaks.

[!TIP] Exam Focus: For use cases, structure answer as: Problem in Traditional System → Blockchain Solution (which feature?) → Benefits. E.g., "Cross-border: Problem is slow/expensive intermediaries → Solution: Ripple's direct settlement with XRP bridge → Benefits: Speed, cost reduction."

END OF UNIT 2 NOTES