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

UNIT 1: FOUNDATIONS AND CORE ARCHITECTURE OF BLOCKCHAIN

1.0 Introduction to Blockchain Technology

1.1 Definition and Core Concept

A blockchain is a distributed, immutable, cryptographically-secured ledger or chain of blocks, where each block contains a set of transactions and is linked to its predecessor via a cryptographic hash. It operates on a peer-to-peer (P2P) network without a central authority.

1.2 Essential Characteristics

1.3 Evolution: Traditional DBs vs. Distributed Ledgers

1.4 Types of Blockchains

[!TIP] Exam Focus: Be prepared to differentiate public vs. private/consortium blockchains based on access control, consensus mechanism, and use-case. Private/consortium are often called "permissioned."

2.0 Cryptographic Foundations

2.1 Cryptographic Hash Functions

A deterministic function that maps input data of any size to a fixed-size output string (hash/digest). Key Properties:

1. Deterministic: Same input → same hash.

2. Pre-image Resistance: Given hash h, it's computationally infeasible to find any input m such that hash(m) = h.

3. Second Pre-image Resistance: Given input m1, it's infeasible to find a different m2 where hash(m1) = hash(m2).

4. Collision Resistance: Infeasible to find any two distinct inputs m1 and m2 such that hash(m1) = hash(m2).

5. Avalanche Effect: A tiny change in input causes a drastic, unpredictable change in output.

6. Puzzle-friendly: Hard to solve, but easy to verify.

Common Algorithms: SHA-256 (Bitcoin), SHA-3, Keccak-256 (Ethereum).

2.2 Role in Blockchain

• Block Linking: Each block header contains the hash of the previous block. This creates an immutable chain. Altering any block breaks the chain.

• Data Integrity: Transaction data in a block is hashed (via Merkle Root). Any change in a single transaction changes the Merkle Root, which changes the block hash, breaking the chain.

• Proof-of-Work (PoW): Miners repeatedly hash the block header with different nonces to find a hash below a target difficulty.

2.3 Public Key Cryptography (Asymmetric)

Uses a key pair: a private key (kept secret) and a public key (shared).

• Key Generation: Mathematically linked pair.

• Encryption: Data encrypted with a public key can only be decrypted by the corresponding private key.

• Digital Signatures: Private key is used to sign a message. Anyone with the corresponding public key can verify the signature. This provides authentication and non-repudiation.

2.4 Digital Signatures in Blockchain

• Creation: Signature = Sign(Private_Key, Transaction_Data)

• Verification: Verify(Public_Key, Transaction_Data, Signature) → Returns True/False.

• Purpose:

  1. Authentication: Proves the owner of the private key (the sender) authorized the transaction.

  2. Non-repudiation: The sender cannot later deny having sent the transaction.

  3. Integrity: Any change to the signed transaction data invalidates the signature.

[!TIP] Common Pitfall: Do not confuse hashing (one-way, no keys) with encryption (two-way, uses keys). Blockchain uses hashing for integrity/linking and digital signatures (a form of asymmetric encryption) for authentication.

3.0 Blockchain Data Structures

3.1 Structure of a Block

+---------------------+

|     Block Header    |

+---------------------+

|      Block Body     |  (List of Transactions)

+---------------------+

Block Header Fields:

3.2 Merkle Trees (Binary Hash Trees)

• Structure: A binary tree where every leaf node is a hash of a transaction data, and every non-leaf node is a hash of its two child nodes.

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

• Importance:

  1. Efficient Verification (Merkle Proof): A user can verify a specific transaction is in a block without downloading all transactions. They only need the transaction hash and a few sibling hashes (the "Merkle Path") to recompute the Merkle Root and compare it to the one in the block header.

  2. Data Integrity: Any change to any transaction changes the Merkle Root.

  3. Scalability: Enables Simplified Payment Verification (SPV) in Bitcoin, allowing lightweight clients to verify transactions without full blockchain storage.

DiagramCANVAS: Draw a binary tree. Leaf nodes: Tx1_hash, Tx2_hash, Tx3_hash, Tx4_hash. Level 1: hash(hash(Tx1)+hash(Tx2)), hash(hash(Tx3)+hash(Tx4)). Root: Merkle Root = hash(Level1_left + Level1_right).

3.3 Transaction Structure (Bitcoin Example)

+-------------------+

| Transaction Input |

+-------------------+

| Transaction Output|

+-------------------+

• Input: Reference to previous transaction output(s) being spent. Contains a pointer (txid & vout) and an unlocking script (digital signature + public key).

• Output: Amount of BTC sent + a locking script (spending condition, e.g., OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG).

• Other Fields: Version, Locktime.

4.0 Consensus Mechanisms

4.1 The Consensus Problem & Byzantine Generals' Problem

In a distributed system, nodes must agree on a single state (the ledger) despite potential failures (crash faults) or malicious behavior (Byzantine faults). The Byzantine Generals' Problem illustrates the challenge: several generals must agree to attack or retreat, but some may be traitors sending conflicting messages. A system is Byzantine Fault Tolerant (BFT) if it can reach consensus despite up to f faulty/malicious nodes in a network of 3f + 1 total nodes.

4.2 Permissionless (Public) Consensus

4.2.1 Proof of Work (PoW)

• Mechanism: Miners compete to solve a computationally difficult but easily verifiable puzzle: find a nonce such that Hash(Block_Header) < Target.

• Mining Process:

  1. Collect pending transactions into a candidate block.

  2. Compute the block header (including a starting nonce).

  3. Repeatedly hash the header with different nonces.

  4. If a hash below the target is found, broadcast the new block.

  5. Other nodes verify the PoW (easy) and the block's transactions.

• Attacks:

  • 51% Attack: If a miner/group controls >50% of the network's hash power, they can:

    • Double-spend their own coins (by creating a longer private fork).

    • Censor transactions.

    • Note: Extremely expensive on major chains like Bitcoin.

  • Monopoly Problem: Mining power centralizes in large pools due to economies of scale, contradicting decentralization.

• HashCash vs. Bitcoin PoW: HashCash (1997) was an anti-spam PoW for email. Bitcoin adapted it by making the puzzle target dynamic (difficulty adjustment) and tying it to a blockchain data structure.

4.2.2 Proof of Elapsed Time (PoET)

• Mechanism: Uses a trusted execution environment (TEE) like Intel SGX. Each validator requests a random wait time from the enclave. The validator with the shortest wait time wins the block and gets to propose it.

• Advantages: Low energy consumption vs. PoW, fast finality.

• Limitations: Requires trusted hardware (Intel SGX), potential SGX vulnerabilities, perceived centralization risk.

4.3 Permissioned (Private/Consortium) Consensus

4.3.1 Raft Algorithm

• Goal: Leader-based consensus for crash fault tolerance (not Byzantine).

• Mechanism:

  1. Leader Election: Nodes start as followers. If no leader heartbeat, they become candidates, request votes. First to get majority becomes leader.

  2. Log Replication: Leader receives client commands, appends to its log, and replicates to followers. Once replicated on majority, command is committed.

• Properties: Safety (no two leaders with same term), Liveness (eventual leader election if majority are correct).

• Use Case: Hyperledger Fabric's ordering service (in non-BFT mode), etcd, Consul.

4.3.2 Practical Byzantine Fault Tolerance (PBFT)

• Goal: State machine replication tolerant to f Byzantine nodes in a 3f+1 system.

• Phases for each request (view):

  1. Pre-prepare: Leader assigns a sequence number and broadcasts (request, sequence number, view) to all replicas.

  2. Prepare: Each replica broadcasts a prepare message for that request/seq/view if valid. Upon receiving 2f+1 matching prepares (including its own), it enters prepared state.

  3. Commit: Replica broadcasts commit message. Upon receiving 2f+1 matching commits, it executes the request and enters committed state.

• Complexity: O(n²) message overhead. Used in Hyperledger Fabric (BFT ordering), some early blockchains.

4.3.3 Other Permissioned Protocols

• IBFT (Istanbul BFT): PBFT variant with improved performance, used in Quorum.

• Raft-based variants: SBFT (Scalable BFT), Tendermint (BFT-SMaRt).

• Selection: Depends on required fault tolerance (Byzantine vs. crash), throughput, and latency needs.

4.4 Consensus in Bitcoin (Detailed)

• Longest Chain Rule: Nodes always consider the longest valid chain (most cumulative PoW) as the canonical truth. Miners mine on the tip of this chain.

• Block Propagation: New block is broadcast via gossip protocol. Nodes validate and, if valid, add it to their chain and start mining the next block on the new tip.

• Fork Resolution: Temporary forks occur when two miners find a valid block near-simultaneously. Nodes build on the chain they receive first. The fork is resolved when one chain becomes longer (receives the next block). Transactions in the orphaned block return to the mempool.

• Difficulty Adjustment: Every 2016 blocks (~2 weeks), the network recalibrates the target to aim for 10 minutes per block. New_Target = Old_Target * (Actual_Time_of_Last_2016_Blocks / (2016 * 10 mins)). Clamped between min/max.

[!TIP] Exam Focus: Know the steps of PBFT (Pre-prepare, Prepare, Commit) and the difference between Raft (crash fault-tolerant) and PBFT (Byzantine fault-tolerant). Understand how Bitcoin's longest chain rule and difficulty adjustment work together.

5.0 Bitcoin: A Case Study of Permissionless Blockchain

5.1 Network Architecture

• P2P Network: Decentralized, unstructured mesh. Nodes (peers) connect to a few random neighbors.

• Node Types:

  • Full Node: Stores entire blockchain, validates all transactions/blocks, enforces consensus rules. (~10,000+ globally).

  • Lightweight/SPV Node: Stores only block headers, verifies transactions via Merkle Proofs. Relies on full nodes for data.

• Message Propagation: inv (inventory), getdata, tx (transaction), block messages. Uses a flood/gossip protocol.

5.2 Transaction Lifecycle

1. Creation: Sender creates transaction (inputs, outputs, digital signature).

2. Broadcasting: Sender's wallet broadcasts tx message to connected peers.

3. Validation: Each receiving full node validates: syntax, inputs unspent (UTXO check), signatures, sufficient fees. Invalid tx is dropped.

4. Mempool: Valid transactions enter the node's memory pool (mempool).

5. Inclusion: Miners select transactions from their mempool (usually by fee-per-byte) to include in the next candidate block.

5.3 Block Mining Process

1. Miner collects transactions from mempool.

2. Builds candidate block (header + transaction list). Calculates Merkle Root.

3. Initializes nonce = 0.

4. Hashing Loop: hash_value = SHA256(SHA256(Block_Header)). Check if hash_value < Target.

5. If not, increment nonce and repeat.

6. If valid hash found, broadcast block to network.

7. Other nodes verify the PoW and all transactions. If valid, add block to their chain.

8. Difficulty Adjustment: Every 2016 blocks.

5.4 Types of Mining

• Solo Mining: Individual miner. Probability of finding a block is proportional to their hash rate share. High variance in rewards.

• Pool Mining: Miners contribute hash power to a pool. Pool operator aggregates work, finds blocks, and distributes rewards (minus fee) to participants based on contributed work. Reduces variance.

5.5 Bitcoin Script

• Stack-based, Non-Turing Complete: Simple, no loops. Prevents infinite loops/DoS.

• Script Types:

  • Pay-to-PubKey (P2PK): <signature> <pubKey> OP_CHECKSIG. Directly locks to a public key.

  • Pay-to-PubKey-Hash (P2PKH): Most common. OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. Locks to a Bitcoin address (hash of pubkey).

  • Pay-to-Script-Hash (P2SH): OP_HASH160 <ScriptHash> OP_EQUAL. Allows complex spending conditions (multisig) while hiding complexity from sender.

• Limitations as Smart Contract Language: No state, no loops, limited opcodes, no Turing completeness → cannot express complex logic like Ethereum.

5.6 Double-Spending Problem & Prevention

• Problem: An attacker spends the same UTXO in two different transactions sent to different parties.

• Prevention in Bitcoin:

  1. Network Propagation: First transaction to reach majority of nodes gets into the mempool.

  2. Miner Selection: Miners typically include the first-seen valid transaction in a block.

  3. Confirmation: Once the first transaction is included in a block and that block is buried under subsequent blocks (e.g., 6 confirmations), the probability of a successful double-spend via a longer chain becomes negligible (exponentially small). The longest chain rule ensures only one transaction is ultimately accepted.

6.0 Smart Contracts

6.1 Definition & Core Characteristics

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

• Self-executing: Runs automatically without an intermediary.

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

• Deterministic: Same input (state + transaction) → same output on all nodes.

• Decentralized: Executed by the network, not a single server.

• Trustless: Parties don't need to trust each other; they trust the code.

6.2 Development Steps

1. Logic Design: Define rules, conditions, and state transitions.

2. Coding: Write in a supported language (Solidity, Go, Java, etc.).

3. Testing & Simulation: Test logic thoroughly on local/private networks.

4. Deployment: Compile bytecode, pay deployment fee (gas), and broadcast transaction. Contract gets an address.

5. Execution: Users interact by sending transactions to the contract's address, triggering functions.

6. Event Handling: Contracts emit events (logs) that external applications can listen to for notifications.

6.3 Smart Contract Languages

• Bitcoin Script: (See 5.5) Limited, non-Turing, for simple locking/unlocking.

• Ethereum (Solidity/Vyper):

  • Turing Complete: Can express any computation (with gas limit).

  • Gas Model: Every operation costs gas (paid in ETH). Prevents infinite loops/DoS. Gas Used * Gas Price = Transaction Fee.

  • Solidity: Statically-typed, high-level, influenced by C++, JavaScript. Most popular.

  • Vyper: Focus on security, readability, auditability. Simpler, no complex features (inheritance, modifiers).

• Hyperledger Fabric (Chaincode):

  • Written in Go, Java, or JavaScript.

  • Not Turing complete by default (no loops in endorsement logic), but can be.

  • Lifecycle: Install → Approve for org → Commit to channel.

  • Execution Model: Execute-Order-Validate. Endorsing peers execute chaincode (simulate) and sign results. Ordering service orders transactions. Committing peers validate based on endorsement policy before committing.

6.4 Writing Smart Contracts using Hyperledger Fabric

1. Define Chaincode Interface: Init(stub), Invoke(stub) functions.

2. Implement Business Logic: In Invoke, use stub.GetState(key), stub.PutState(key, value) to interact with the world state. Use stub.GetCreator() for identity.

3. Define Endorsement Policy: (e.g., AND('Org1.peer', 'Org2.peer')) in the chaincode metadata or via CLI.

4. Package & Install: Use peer chaincode package, peer chaincode install.

5. Approve & Commit: Org admins approve definition, then commit to channel.

6. Invoke: Client application sends proposal to endorsing peers, collects endorsements, sends transaction to ordering service, then receives committed block.

7.0 Hyperledger Fabric: A Case Study of Permissioned Blockchain

7.1 Introduction Hyperledger is an open-source collaborative effort under the Linux Foundation for enterprise blockchain frameworks. Hyperledger Fabric is a modular, permissioned blockchain platform with a unique execute-order-validate architecture, designed for use cases requiring privacy, scalability, and pluggable components.

7.2 Fabric Architecture Components

7.3 Key Components

• Ledger: Comprises the blockchain (immutable chain of blocks) and the World State (current state of assets as key-value pairs, e.g., CouchDB/LevelDB).

• Chaincode (Smart Contract): Business logic. Runs in Docker containers on peers.

• Endorsement Policy: Defines which peers must endorse (simulate) a transaction for it to be considered valid. (e.g., OR('Org1.member', 'Org2.member')).

• Validation Policy: System-level rule (typically AND of all required endorsements) checked by all committing peers.

7.4 Identities & Policies (MSP)

• MSP: Abstract interface for identity management. Converts a user's certificate into a role (admin, member, peer, client, orderer).

• Certificate Authority (CA): Issues X.509 certificates to users/peers. Fabric CA is the default.

• Role-Based Access Control: Policies (channel creation, chaincode install/commit, peer addition) are defined using MSP principals (e.g., admin:Org1, member:Org2).

7.5 Transaction Flow (Execute-Order-Validate)

1. Proposal (Execute): Client sends Invoke/Init proposal to endorsing peers (as per policy). Peers simulate transaction against their copy of world state, produce endorsement (signature + read/write set), return to client.

2. Transaction Assembly: Client collects sufficient endorsements. Creates a transaction envelope (proposal + responses).

3. Ordering: Client submits envelope to ordering service. Orderer orders transactions chronologically into blocks (by channel) and broadcasts blocks to all peers on that channel.

4. Validation & Commitment (Validate): Each committing peer:

   • Checks transaction syntax.

   • Validates endorsement policy (are required signatures present?).

   • Read-Write Set Consistency Check: Do the versions of keys read (rset) match the current world state? (MVCC check).

   • If valid, updates world state (wset) and appends block to their copy of the blockchain.

   • Invalid transactions are marked as such but still in the block.

7.6 Industry Use Cases for Fabric

• Supply Chain Finance: Track provenance of goods, automate payments upon delivery (smart contracts), reduce fraud.

• Trade Finance: Digitize letters of credit, bills of lading. Reduce paperwork, speed up settlements.

• Healthcare: Secure, permissioned sharing of patient records across hospitals/insurers.

• Insurance: Automate claims processing for parametric insurance (e.g., flight delay).

• Identity & Credential Verification: Verifiable digital identities for KYC/AML.

8.0 Other Enterprise Blockchain Platforms

8.1 Ripple (XRP Ledger)

• Consensus Protocol: RPCA (Ripple Protocol Consensus Algorithm). A variant of PBFT. Validators (chosen by admin) continuously vote on the next ledger version. Requires >80% agreement.

• Use Case: Cross-border payments & remittances. Targets banks and payment providers. Enables near-instant, low-cost settlement using XRP as a bridge currency. Focus on liquidity management, not public cryptocurrency.

8.2 Corda

• Core Philosophy: "Not a blockchain." A distributed ledger for regulated institutions. No global broadcast of all data.

• Key Concepts:

  • States: Immutable facts (e.g., Cash, IOU, Loan). Represent current data.

  • Contracts: Define the rules (constraints) for state evolution. Written in Kotlin/Java.

  • Flows: The "business process" to agree on a state update between parties (e.g., IssueCashFlow, SettleFlow). Runs in separate JVM threads.

  • Notary: Provides uniqueness consensus for a state (prevents double-spend). Can be a single node or a cluster (BFT or non-BFT). Notary pools provide service.

  • Privacy Model: Transaction privacy. Only parties to a transaction (and the notary) see its details. Data is shared on a need-to-know basis, not globally. Uses point-to-point messaging.

• Use Cases: Trade finance, syndicated loans, insurance, interbank payments, supply chain.

9.0 Blockchain Applications and Use Cases

9.1 Blockchain in Supply Chain Finance

• Traditional Issues: Lack of transparency, manual paperwork, fraud (fake invoices), slow payments.

• Blockchain Improvements:

  • Transparency & Traceability: All parties (supplier, buyer, bank, logistics) see the same immutable record of goods movement and document status.

  • Reduction of Fraud: Digitized, verifiable purchase orders, invoices, and bills of lading. Impossible to duplicate or alter secretly.

  • Improving Efficiency: Smart contracts automate payment upon verified delivery (IoT sensor data or document upload). Reduces reconciliation, accelerates cash flow.

  • Financing: Suppliers can get early payment on verified invoices (receivables financing) with lower risk for financiers.

9.2 Blockchain in Mortgage Process

• Traditional Process: Title search (manual, slow), multiple intermediaries (lenders, title companies, attorneys), paper-based, prone to errors/fraud.

• Blockchain-Enabled Process:

  1. Digitized Title & Deeds: Property titles as digital tokens/NFTs on a permissioned chain (e.g., county recorder, lenders, title companies as nodes).

  2. Smart Contract for Escrow: Funds are held in escrow smart contract. Release automatically upon fulfillment of conditions (e.g., title transfer recorded, appraisal complete).

  3. Streamlined Closing: All parties (buyer, seller, lender, agent) access the same immutable data. KYC/AML checks can be streamlined with verifiable credentials.

  4. Tokenization: Real-world asset (property) represented as a digital token. Enables fractional ownership, easier transfer.

  5. Benefit: Reduces time from weeks to days, cuts costs, increases security and auditability.

9.3 Blockchain in Cross-Border Payments

• Traditional Challenges: Multiple correspondent banks, high fees (3-7%), slow (2-5 days), lack of transparency on fees/timing, currency conversion costs.

• Blockchain Solutions (Ripple, Corda):

  • RippleNet (xCurrent/xRapid): Uses XRP as a bridge currency. Banks hold XRP to fund payments instantly, converting to local currency at the destination. Benefits: ~3-5 seconds, ~$0.0001 cost per transaction, end-to-end tracking.

  • Corda: Enables direct bilateral/multilateral settlement between financial institutions using smart contracts and a shared ledger. Reduces need for intermediaries.

• General Benefits: Speed (near real-time), Cost reduction (fewer intermediaries), Transparency (track payment status), 24/7 operation.

9.4 Blockchain Identity Management System (Self-Sovereign Identity - SSI)

• Traditional Model: Centralized identity providers (Google, Facebook, governments). Users cede control; data siloed; privacy risks.

• SSI Model on Blockchain:

  • Decentralized Identifiers (DIDs): Unique identifiers (e.g., did:example:123456) controlled by the user, not stored on-chain (only the DID document hash/pointer).

  • Verifiable Credentials (VCs): Digitally signed claims from an issuer (e.g., university degree, driver's license). Stored in user's digital wallet.

  • How it Works:

    1. User generates DID & key pair.

    2. Issuer signs a VC (e.g., "Jane Doe, age > 21") and gives it to user.

    3. User presents VC + proof of control over DID to a verifier (e.g., bar).

    4. Verifier checks issuer's DID (on-chain or via resolver) and signature cryptographically. No need to contact issuer.

• Advantages: User control & consent, privacy (zero-knowledge proofs possible), reduced fraud, interoperability.

[!TIP] Exam Focus: For use-case questions, structure your answer as: Problem in Traditional System → Blockchain Solution (key tech used) → Benefits. Be specific about the platform (e.g., "Ripple for cross-border," "Fabric for supply chain finance").