UNIT 5: BLOCKCHAIN TECHNOLOGY – SHORT NOTES

(Compiled from Past Examination Patterns for IT-803(C))

I. INTRODUCTION & CORE CONCEPTS

Definition & Fundamental Principles

A blockchain is a distributed, immutable, decentralized ledger that records transactions in blocks linked via cryptographic hashes. Core principles:

• Decentralization: No single controlling authority; consensus among nodes.

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

• Transparency: All transactions are visible to participants (in public chains).

• Security: Cryptography ensures data integrity and authentication.

Blockchain Taxonomy

[!TIP] Exam Focus: Distinguish based on access control and consensus mechanism. Private chains are not "owned" by one entity but by a consortium.

Cryptographic Foundations

1. Cryptographic Hash Function (e.g., SHA-256):

   • Properties: Deterministic, Fast computation, Pre-image resistant, Avalanche effect, Collision resistant.

   • Role in Blockchain: Generates block identifiers, ensures immutability (any change alters hash), links blocks.

2. Public Key Cryptography (PKI):

   • Key Pairs: Private key (secret, signs), Public key (shared, verifies).

   • Digital Signature: Signature = Sign(Private_Key, Transaction_Data). Provides authentication, non-repudiation, integrity.

   • Address Generation: Derived from public key (e.g., Bitcoin: RIPEMD160(SHA256(Public_Key))).

Critical Problems Addressed

• Double-Spending Problem: Spending the same digital asset twice.

  • Prevention: Consensus mechanism (first valid transaction in a block is accepted), global ledger replication, confirmation depth (wait for k blocks).

• Trustless Environment: Participants need not trust each other; trust is placed in the protocol and mathematics.

• Decentralization: Eliminates single point of failure/censorship.

II. BLOCKCHAIN STRUCTURE & DATA MANAGEMENT

Block Structure

A block consists of:

1. Block Header (80 bytes in Bitcoin):

   • Version: Protocol version.

   • Previous Block Hash: Hash of the previous block's header (creates the chain).

   • Merkle Root: Hash of the root of the Merkle tree of all transactions in the block.

   • Timestamp: Block creation time.

   • Difficulty Target: Current mining difficulty.

   • Nonce: Number miners vary to find a valid Proof-of-Work.

2. Block Body / Transaction List: The actual transactions (or smart contract calls).

[!TIP] Exam Focus: Be ready to draw and label a block diagram, emphasizing the header fields and their purpose.

Merkle Trees (Hash Trees)

• Construction: Transactions are hashed, paired, and hashed recursively until a single root hash (Merkle Root) is formed.

  
  Level 0: Tx1, Tx2, Tx3, Tx4
  
  Level 1: H12=H(Tx1||Tx2), H34=H(Tx3||Tx4)
  
  Level 2: Root = H(H12 || H34)
  
  

• Importance:

  • Efficiency: Allows Merkle Proofs. A light client can verify a transaction's inclusion by receiving only ~log₂(N) hashes, not the entire block.

  • Security: Any alteration to a single transaction changes its hash, propagating up to alter the Merkle Root, breaking the block's validity.

  • Data Integrity: Merkle Root in the block header commits to all transactions succinctly.

Bitcoin P2P Network Architecture

• Node Types: Full nodes (store entire blockchain), Lightweight/SPV nodes (store headers only), Mining nodes.

• Network Propagation: Flooding/gossip protocol. A node broadcasts a new transaction to its peers, who validate and rebroadcast.

• Transaction Processing Workflow:

  1. Broadcast: User signs transaction → broadcasts to network.

  2. Validation: Nodes validate (signature, UTXO existence, no double-spend).

  3. Mempool: Valid transactions enter the memory pool (mempool) waiting to be included in a block.

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

  5. Propagation: Mined block is broadcast; nodes validate and add to their chain.

III. CONSENSUS MECHANISMS

Role of Consensus

To achieve agreement on the state of the ledger among distributed, potentially faulty nodes in a Byzantine environment (where nodes may act maliciously or fail).

Proof-of-Work (PoW)

• Mechanism (HashCash/Bitcoin): Miners repeatedly hash the block header (varying the nonce) to find a value H(header) < Target. This is computationally hard to find but easy to verify.

• Difficulty Adjustment: Every 2016 blocks (~2 weeks), the network adjusts the Target so that the average time between blocks remains ~10 minutes.

• Monopoly Problem & Attacks:

  • 51% Attack: If an entity controls >50% of hash power, it can double-spend and censor transactions.

  • Selfish Mining: Miner withholds a found block to gain a strategic advantage, reducing network efficiency.

Proof-of-Elapsed-Time (PoET)

• Mechanism: Used in permissioned chains (e.g., Hyperledger Sawtooth).

  1. Each node waits a randomly chosen amount of time (enforced by Intel SGX trusted execution environment).

  2. The node that finishes waiting first becomes the leader and proposes the next block.

• Advantage: Low energy consumption compared to PoW. Random leader selection prevents monopoly.

Byzantine Fault Tolerance (BFT) - PBFT

• Lamport-Shostak-Pease (PBFT) Algorithm: Tolerates up to f faulty nodes in a system of 3f+1 nodes.

• Phases for a single request:

  1. Pre-Prepare: Leader assigns a sequence number and broadcasts to backups.

  2. Prepare: Each node broadcasts a "prepare" message for that sequence number.

  3. Commit: After receiving 2f+1 prepare messages, node broadcasts "commit".

  4. Reply: After 2f+1 commit messages, node executes request and replies to client.

• Finality: Transactions are final once committed; no forks.

RAFT Consensus

• Mechanism: Leader-based consensus for non-Byzantine (crash-fault only) environments.

  1. Leader Election: Nodes in follower state. If no heartbeat from leader within timeout, become candidate, request votes. Wins with majority.

  2. Log Replication: Leader receives client command, appends to its log, replicates to followers. Once replicated on majority, leader commits and notifies followers.

• Comparison with PBFT:

  | Feature | RAFT | PBFT | | :--- | :--- | :--- | | Fault Model | Crash faults only | Byzantine faults | | Complexity | Simpler, O(n) messages | More complex, O(n²) | | Throughput | High | Lower due to overhead | | Use Case | Permissioned, trusted nets | Permissioned, adversarial nets |

Consensus Protocols for Permissioned Blockchains

• RAFT: For simple, trusted consortia (e.g., Hyperledger Fabric v1.4+ ordering service).

• PBFT: For higher security against malicious nodes.

• Kafka/ZooKeeper: Often used as an ordering service in Fabric (not a BFT consensus itself, but provides total order).

Bitcoin-Specific Consensus (Detailed Workflow)

1. Transaction Pool: Miners collect valid, unconfirmed transactions from mempool.

2. Block Assembly: Create candidate block with:

   • Coinbase transaction (miner's reward).

   • Selected transactions (prioritized by fee).

   • Correct block header fields (prev hash, merkle root, timestamp, difficulty, nonce).

3. PoW Mining: Iterate nonce (and extra nonce in coinbase) to find H(header) < Target.

4. Block Propagation: Winning miner broadcasts block.

5. Validation by Nodes:

   • Verify PoW (hash < target).

   • Verify all transactions (signatures, UTXOs, no double-spend).

   • Verify Merkle Root matches transactions.

   • Check block height and previous hash.

6. Chain Selection: Nodes always adopt the longest valid chain (most cumulative PoW). Orphaned blocks become stale.

IV. SMART CONTRACTS

Definition & Essential Characteristics

A smart contract is self-executing, immutable, deterministic code stored on the blockchain that automates the execution of an agreement when predefined conditions are met.

• Self-Executing: Runs automatically without intermediary.

• Immutable: Once deployed, code cannot be changed (unless built with upgradeability pattern).

• Deterministic: Same input → same output on any node.

• Trustless: Execution enforced by network consensus.

Bitcoin Script

• Stack-based, non-Turing complete language (no loops, limited operations).

• Purpose: Simple transaction conditions (e.g., P2PKH: Pay-to-Public-Key-Hash).

• Use Cases: Multi-signature wallets, time-locked contracts (HTLCs for Lightning Network).

• Limitations: No complex logic, no state between transactions, limited expressiveness.

Ethereum Smart Contracts

• Solidity: Statically-typed, high-level language for writing contracts.

• Development Process:

  1. Write .sol file.

  2. Compile to EVM bytecode (using solc).

  3. Deploy bytecode via transaction (paying gas).

  4. Interact via contract address and ABI.

• Gas: Unit of computation. Each EVM operation has a gas cost. Prevents infinite loops and spam. Paid in ETH.

• EVM (Ethereum Virtual Machine): Runtime environment for smart contracts. Every node executes contract code to validate state transitions.

Hyperledger Fabric Smart Contracts (Chaincode)

• Writing Process:

  1. Chaincode is written in Go, Java, or Node.js.

  2. It implements a defined interface (Init, Invoke).

  3. Endorsement Policies define which peers must execute/endorse a transaction for it to be valid (e.g., "Org1 AND Org2").

  4. Execution Flow:

     • Client sends proposal to endorsing peers.

     • Peers simulate execution (no state update), generate read-write set, sign endorsement.

     • Client sends transaction + endorsements to Ordering Service.

     • Orderers sequence transactions into blocks, deliver to committing peers.

     • Committing peers validate endorsements & policies, then commit to ledger.

• Key Difference from Ethereum: Chaincode does not manage the ledger state directly. It proposes changes (read-write set), which the peers validate and commit. Separation of compute (chaincode) and ordering (orderers).

Comparative Analysis of Smart Contract Platforms

V. BLOCKCHAIN PLATFORMS & ARCHITECTURES

Bitcoin

• Architecture: UTXO (Unspent Transaction Output) model. Transactions consume UTXOs and create new ones.

• Mining Economics: Block reward (new BTC + transaction fees). Halving every 210,000 blocks (~4 years).

• Transaction Scripts: P2PK, P2PKH, P2SH, P2WPKH (SegWit).

Ethereum

• Account-Based Model: Balances stored in accounts (externally owned accounts - EOAs, contract accounts).

• Smart Contract Ecosystem: ERC-20 (tokens), ERC-721 (NFTs), DeFi protocols (Uniswap, Aave), DAOs.

• EVM: Global state machine. Gas limits per block prevent DoS.

Hyperledger Fabric

• Modular Architecture:

  • Peers: Committing peers (store ledger), Endorsing peers (simulate/endorse).

  • Ordering Service (Orderers): Consensus, total order of transactions (crash-fault tolerant).

  • Channels: Private subnets for confidential transactions between specific organizations.

• Identities & Policies:

  • MSP (Membership Service Provider): Defines how identities are validated (root CAs, intermediate CAs, OU).

  • ACLs (Access Control Lists): Define which identities can invoke which chaincode functions.

• Enterprise Use Cases: Supply chain traceability (food, pharma), trade finance, inter-bank settlements.

Ripple (XRP Ledger)

• Consensus Protocol (RPCA): Permissioned, BFT-like consensus among trusted validators (Unique Node List - UNL). No mining. Finality in ~3-5 seconds.

• Use in Cross-Border Payments: RippleNet (xCurrent for messaging, xRapid for liquidity using XRP). Targets banks for fast, low-cost settlement vs. SWIFT.

Corda

• Notary & Consensus Model: Notary service (single or cluster) provides uniqueness consensus (prevents double-spend). Transaction validation is done by required counterparties only (no global broadcast).

• Privacy via Confidential Identities: Transactions are only shared with necessary participants. No global ledger; each node stores only its relevant transactions.

• Use Case: Inter-organizational record keeping (finance, trade, healthcare) where privacy is paramount.

Platform Comparison: Ripple vs. Corda

VI. MINING & NETWORK OPERATIONS

Block Mining Process

1. Transaction Selection: Miner selects transactions from mempool, prioritizing by fee rate.

2. Block Assembly: Creates coinbase transaction + selected transactions. Computes Merkle Root. Fills block header.

3. Nonce Calculation: Iterates nonce (and extra nonce) to solve PoW puzzle: H(block_header) < target.

4. Block Propagation: Broadcasts valid block to network.

Types of Mining

• Hardware Evolution: CPU → GPU → FPGA → ASIC (Application-Specific Integrated Circuit - most efficient, Bitcoin-specific).

Mining Rewards & Incentives

• Block Subsidy: New coins created as reward (e.g., 6.25 BTC in 2023). Halving event every 210k blocks.

• Transaction Fees: Sum of fees from all transactions in the block. Becomes primary incentive after all coins are mined (~2140).

• Incentive Alignment: Miners are economically incentivized to act honestly (follow protocol) as it maximizes long-term reward from block subsidies and fees.

VII. APPLICATIONS & ENTERPRISE USE CASES

Supply Chain Finance

• Traditional: Manual, paper-heavy, lack of transparency, slow invoice financing.

• Blockchain Improvement:

  • Transparency & Traceability: Immutable record of product journey (origin → consumer). Reduces fraud.

  • Invoice Financing: Digitized invoices on chain (e.g., as NFTs) enable faster, lower-cost factoring by proving authenticity and ownership history.

  • Automated Payments: Smart contracts trigger payments upon delivery confirmation (IoT sensor data).

Mortgage & Real Estate

• Traditional Process: Lengthy (30-60 days), paper-based, multiple intermediaries (title companies, escrow, banks), high fees, fraud risk.

• Blockchain-Based Mortgage:

  1. Property Tokenization: Title represented as a digital token on blockchain.

  2. KYC/AML On-Chain: Verified identities stored once.

  3. Smart Contract Automation: Escrow managed by contract; funds released automatically upon fulfillment of conditions (inspection, appraisal).

  4. Title Transfer: Instant, immutable transfer of token upon payment.

  • Benefits: Reduced time (days), lower costs, reduced fraud, transparent audit trail.

Cross-Border Payments

• Traditional (SWIFT): Slow (2-5 days), expensive (multiple correspondent bank fees), opaque tracking.

• Blockchain (RippleNet):

  • xCurrent: Real-time messaging and settlement tracking for banks (uses blockchain-like consensus but not XRP).

  • xRapid: Uses XRP as a bridge currency for on-demand liquidity. Source currency → XRP → destination currency in seconds.

  • Benefits: Speed (3-5 sec), Cost (fraction of fees), Transparency (track payment end-to-end).

Digital Identity Management

• Traditional: Siloed, centralized databases (Facebook, Google login). Users lack control; prone to breaches.

• Blockchain (Self-Sovereign Identity - SSI):

  • Identity is a collection of verifiable credentials (VCs) stored in user's digital wallet.

  • Issuers (govt, university) sign credentials. Verifiers can cryptographically check authenticity without contacting issuer.

  • Privacy: Zero-knowledge proofs allow proving attributes (e.g., "age > 21") without revealing birthdate.

  • Benefit: User-controlled, portable, tamper-proof identity.

Trade Finance

• Traditional: Paper-based Letters of Credit (LCs), Bills of Lading. Slow, costly, fraud-prone.

• Blockchain Improvement:

  • Digitize documents as smart assets on a permissioned chain (e.g., we.trade, Marco Polo platforms).

  • All parties (importer, exporter, banks, carrier) share a single, immutable version.

  • Smart contracts auto-execute upon event (e.g., shipment arrival triggers payment).

  • Benefits: Reduced processing time (days → hours), lower costs, reduced counterparty risk.

Enterprise Blockchain Adoption Challenges

• Scalability: Throughput (TPS) limitations vs. Visa/Mastercard.

• Regulation: Unclear legal frameworks for smart contracts, token assets, cross-border data.

• Interoperability: Different blockchains cannot natively communicate (solved by cross-chain protocols, atomic swaps).

• Integration: Legacy system integration complexity.

• Governance: Decision-making in decentralized consortia.

VIII. ADVANCED TOPICS & CURRENT TRENDS

Scalability Solutions

• Lightning Network (Bitcoin): Off-chain payment channels. Users open a channel, transact instantly/cheaply off-chain, settle final state on-chain. Enables microtransactions.

• Sharding (Ethereum 2.0+): Partition network into n shards. Each shard processes its own transactions/state. Increases throughput linearly.

• Sidechains: Independent blockchains pegged to mainchain via two-way peg. Can have different rules/consensus (e.g., Polygon PoS chain).

Privacy-Enhancing Technologies

• Zero-Knowledge Proofs (ZKPs): Prove knowledge of a secret without revealing it.

  • ZK-SNARKs: zCash, zkEVM (Ethereum L2).

  • ZK-STARKs: No trusted setup, larger proof size.

• Ring Signatures (Monero): Signer is hidden within a group of signers. Provides sender anonymity.

Interoperability

• Cross-Chain Protocols: Bridges (lock assets on chain A, mint on chain B), relay chains (Polkadot), hubs (Cosmos IBC).

• Atomic Swaps: Peer-to-peer exchange of cryptocurrencies across different blockchains without trusted intermediary. Uses hashed timelock contracts (HTLCs).

Regulatory & Compliance

• Public Chains: Pseudonymous → challenging for KYC/AML. Travel rule compliance difficult.

• Permissioned Chains: Known identities → easier to enforce KYC/AML at network entry. ACLs and private channels enable data privacy for regulated data.

Future Directions

• Blockchain in IoT: Device identity, micro-payments, data integrity (e.g., IOTA).

• AI Integration: Decentralized AI marketplaces, training data provenance, model verification.

• CBDCs (Central Bank Digital Currencies): Government-issued digital currency on permissioned/controlled blockchain (e.g., digital Yuan, digital Euro). Focus on monetary policy, financial inclusion.

Final Exam Strategy: For 7-mark questions, structure answer as: 1-sentence definition → 3-4 key points with brief explanation → 1 real-world example (if applicable). Always link concepts to security, efficiency, or trust benefits. For diagrams (block structure, Merkle tree, consensus flow), practice drawing clean, labeled diagrams.