Block Chain & Crypto-Currencies (CY-702 (B)) - Unit 1 Short Notes

UNIT 1 - FOUNDATIONS OF BLOCKCHAIN & CRYPTOGRAPHY

(Based on Standard Syllabus Patterns for Introductory Blockchain Courses)

1.0 Introduction & Core Concepts

1.1 Definition of Blockchain

A Blockchain is a type of Distributed Ledger Technology (DLT). It is a decentralized, immutable, and cryptographically secure digital ledger of transactions or data, duplicated and distributed across a network of computers.

1.2 Key Characteristics

1.3 Evolution

• Blockchain 1.0: Bitcoin - Primarily for peer-to-peer digital cash.

• Blockchain 2.0: Ethereum - Introduced smart contracts (self-executing contracts with terms written in code), enabling decentralized applications (dApps).

• Blockchain 3.0: Focus on scalability, interoperability, and sustainability (e.g., Cardano, Polkadot, Solana).

1.4 Types of Blockchains

1.5 Use Cases Beyond Cryptocurrency

• Supply Chain: Track provenance of goods (food, pharmaceuticals).

• Voting: Create tamper-proof and transparent electoral systems.

• Digital Identity: Self-sovereign identity management.

• Finance (DeFi): Lending, borrowing, trading without intermediaries.

[!TIP] Exam Focus: Be prepared to define blockchain and list its four core characteristics. Know the difference between public and private blockchains with examples.

2.0 Cryptographic Primitives (The Bedrock)

2.1 Hash Functions (e.g., SHA-256, Keccak)

A cryptographic hash function takes an input (any size) and produces a fixed-size, unique string of characters (the hash or digest).

Essential Properties:

1. Deterministic: Same input always produces same hash.

2. Pre-image Resistant: Given a hash h, it is computationally infeasible to find any input m such that hash(m) = h.

3. Collision Resistant: It is infeasible to find two distinct inputs m1 and m2 such that hash(m1) = hash(m2).

4. Avalanche Effect: A tiny change in input causes a drastic, unpredictable change in the output hash.

5. Fast Computation: Hash can be computed quickly for any input.

Role in Blockchain:

• Block & Transaction Hashing: Each block header contains the hash of its own transactions (Merkle Root) and the hash of the previous block.

• Merkle Trees: Efficiently summarize and verify large sets of data.

2.2 Public Key Cryptography (Asymmetric Cryptography)

Uses a mathematically linked key pair:

• Private Key: A secret, randomly generated number. Must be kept secure. Used to sign transactions.

• Public Key: Derived from the private key. Can be shared openly. Used to verify signatures.

• Wallet Address: Typically a hashed version of the public key.

Digital Signatures (ECDSA - Elliptic Curve Digital Signature Algorithm):

1. Signing: The sender uses their private key to generate a signature for a transaction message.

2. Verification: Anyone on the network can use the sender's public key to verify that:

   • The signature was created by the corresponding private key (Authenticity).

   • The transaction message has not been altered since it was signed (Integrity).

   • The sender cannot later deny having signed the transaction (Non-repudiation).

\boxed{\text{Digital Signature = Sign(PrivateKey, Message)} \quad \text{Verification = Verify(PublicKey, Message, Signature)}}

2.3 Cryptographic Hash Functions vs. Encryption

2.4 HIGH PRIORITY: Digital Signatures for Non-Repudiation & Integrity

• Integrity: Any change to the signed transaction data will cause signature verification to fail, as the hash of the altered message will not match the one used in the signature.

• Non-Repudiation: Because only the owner of the private key could have generated a valid signature, they cannot later deny authorizing the transaction. The public key provides cryptographic proof of origin.

[!TIP] Common Pitfall: Do not confuse hashing (creating a digest) with encryption (hiding data). Blockchain uses hashing extensively for integrity; it does not use encryption for transaction privacy.

3.0 Blockchain Architecture & Data Structure

3.1 The Block Structure

3.2 The Chain: Linking Blocks

• Each block header contains the hash of the previous block's header.

• This creates a cryptographic link forming a chronological chain.

• Immutability Mechanism: To alter a past transaction, an attacker must recalculate the Proof-of-Work for that block and all subsequent blocks, which is computationally infeasible in a large, active network.

3.3 HIGH PRIORITY: Merkle Trees

• Purpose: Efficiently verify that a specific transaction is included in a block without needing the entire block. Enables Simplified Payment Verification (SPV).

• Construction:

  1. List all transaction hashes in a block (leaf nodes).

  2. Pair and hash them together to create a new level of nodes.

  3. Repeat until a single hash remains: the Merkle Root, stored in the block header.

• Merkle Proof: To prove transaction T is in a block, a node provides T's hash and the hashes of its "sibling" nodes at each level up to the root. The verifier can recompute the Merkle Root and compare it to the one in the block header.

\boxed{\text{Merkle Root} = \text{Hash}( \text{Hash}(\text{Tx}_1 | \text{Tx}_2) | \text{Hash}(\text{Tx}_3 | \text{Tx}_4) ) \quad \text{(for 4 transactions)}

[!TIP] Exam Question: "Explain Merkle Trees and their role in SPV." Answer Structure: 1) Define & show construction. 2) Explain purpose (efficiency, light clients). 3) Describe a Merkle Proof process.

4.0 Distributed Consensus Mechanisms

4.1 The Byzantine Generals' Problem

A classic problem in distributed computing: How to achieve agreement among a group of unreliable nodes (some may be malicious/faulty) about a single truth, when messages may be delayed or lost. Blockchain consensus solves this for decentralized trust.

4.2 HIGH PRIORITY: Proof-of-Work (PoW)

• Mechanism (Mining):

  1. Miners collect pending transactions into a candidate block.

  2. They repeatedly change the Nonce value in the block header and compute the block's hash.

  3. The goal: Find a hash that is less than the network's current Difficulty Target (i.e., has a certain number of leading zeros).

  4. This is a brute-force, probabilistic search requiring massive computational power (work).

  5. The first miner to find a valid hash broadcasts the block. Others verify the PoW and transactions easily.

• Block Reward: Incentive for miners (newly minted coins + transaction fees).

• Difficulty Adjustment: Network automatically adjusts the target every N blocks (e.g., 2016 blocks in Bitcoin) to maintain an average block time (e.g., 10 minutes).

Advantages: High security (51% attack is extremely costly), proven track record (Bitcoin). Disadvantages: Extremely high energy consumption, potential centralization of mining pools.

4.3 Proof-of-Stake (PoS) & Variants

• Mechanism:

  1. Validators are chosen to propose/attest to new blocks based on the amount of cryptocurrency they stake (lock up as collateral) and often other factors (randomness, coin age).

  2. No energy-intensive computation. The "stake" acts as economic security.

  3. If a validator acts maliciously (e.g., approves invalid transaction), their stake can be slashed (forfeited).

• Ethereum 2.0 (The Merge): Transitioned from PoW to PoS (Consensus Layer).

Advantages: Extremely energy efficient, potentially higher throughput. Disadvantages: "Nothing at Stake" problem (theoretical), potential for "rich get richer" (wealth concentration), different security model.

4.4 Other Consensus Algorithms (Brief)

• Proof-of-Authority (PoA): Validators are pre-approved, trusted entities (identity at stake). Used in private chains.

• Delegated Proof-of-Stake (DPoS): Token holders vote for a small number of delegates to validate blocks. Faster, more centralized.

• Practical Byzantine Fault Tolerance (PBFT): Used in permissioned chains. Nodes communicate in rounds to agree on a block. Communication overhead is high.

4.5 Compare & Contrast: PoW vs. PoS

[!TIP] Exam Focus: You WILL be asked to explain PoW and compare PoW vs. PoS. Know the steps of mining, difficulty adjustment, and the core trade-offs (security vs. energy).

5.0 Transactions & Wallets

5.1 Transaction Structure (Bitcoin UTXO Model)

A transaction has:

• Inputs: References to previous UTXOs (Unspent Transaction Outputs) being spent. Each input requires a digital signature from the owner of the UTXO.

• Outputs: New UTXOs created, specifying an amount and a locking script (cryptographic puzzle: "To spend this, provide signature matching PubKey X").

• Amount: Value being transferred.

• Script: Contains spending conditions (e.g., Pay-to-PubKeyHash).

5.2 UTXO Model vs. Account-Based Model

5.3 Transaction Lifecycle

1. Creation: Sender's wallet constructs transaction (inputs, outputs).

2. Signing: Sender signs transaction with private key.

3. Broadcasting: Transaction sent to P2P network.

4. Verification: Nodes verify: valid signatures, UTXOs exist and are unspent, no double-spend, scripts are valid.

5. Pooling: Valid transactions enter the mempool (waiting room).

6. Inclusion: A miner includes it in a candidate block and successfully mines that block.

7. Confirmation: Once the block is added to the chain, the transaction gets its first confirmation. Subsequent blocks add more confirmations.

5.4 Wallets

5.5 HIGH PRIORITY: Transaction Validation by Nodes

A full node validates a new transaction by checking:

1. Syntax & Structure: Is it correctly formatted?

2. Digital Signatures: Are all inputs signed correctly with the private keys corresponding to the UTXO owners?

3. UTXO Set: Do all referenced UTXOs exist in the current UTXO set (database of all unspent outputs) and are they unspent? (Prevents double-spend).

4. Script Execution: Does the locking script of each input UTXO unlock correctly with the provided unlocking script (signature)?

5. Value: Are output values ≤ input values? (The difference is the transaction fee).

6. No Inflation: Are the newly created coins (if any) equal to the allowed block subsidy?

\boxed{\text{Valid Transaction: } \sum \text{Inputs} \geq \sum \text{Outputs} + \text{Fee}}

[!TIP] Common Exam Trap: Transaction validation is not just checking signatures. The UTXO set check is critical for double-spend prevention. Always mention it.

6.0 Nodes, Networks & P2P Communication

6.1 Node Types

6.2 Peer-to-Peer (P2P) Network

• Gossip Protocol: When a node receives a new transaction/block, it forwards it to all its peers, who then forward it to theirs, ensuring rapid propagation.

• Discovery: Nodes find peers via DNS seeds or hardcoded addresses.

• No Central Server: The network is resilient as there is no single point of failure.

6.3 Network Security: Sybil Attack Resistance

• A Sybil Attack is when an attacker creates many fake node identities to gain disproportionate influence.

• Resistance via Consensus: In PoW, creating a fake identity doesn't give you more hash power. In PoS, it doesn't give you more stake. The consensus mechanism's resource requirement (work or stake) makes Sybil attacks economically impractical.

7.0 Introduction to Bitcoin (Primary Case Study)

7.1 Bitcoin Network Overview

• Decentralized P2P network of full and light nodes.

• Uses PoW consensus (SHA-256d hash function).

• Native cryptocurrency: BTC.

• Block time: ~10 minutes. Max supply: 21 million BTC.

7.2 Mining Process in Detail

1. Transaction Collection: Miners select transactions from the mempool (prioritizing higher fees).

2. Block Assembly: Build a candidate block with a coinbase transaction (reward to themselves) and selected transactions.

3. PoW Search: Iterate the Nonce (and extra nonce) to find a block hash H such that H < Target.

4. Block Propagation: Upon finding a valid hash, broadcast the block.

5. Chain Selection: Nodes adopt the longest valid chain (most cumulative PoW).

Block Reward & Halving:

• Block Reward: New BTC created and awarded to the miner. Initially 50 BTC.

• Halving: Every 210,000 blocks (~4 years), the block reward is cut in half. This creates a predictable, disinflationary supply schedule.

• Current Reward (as of 2024): 3.125 BTC per block.

• Final Halving: Expected around 2140, after which miners will rely solely on transaction fees.

7.3 Bitcoin Scripting Language

• Purpose: Defines the spending conditions for an output (locking script) and how to satisfy them (unlocking script).

• Characteristics:

  • Simple, stack-based, non-Turing complete. (No loops, limited operations). This prevents infinite loops and keeps validation predictable.

  • Not for general computation. Designed solely for transaction validation.

• Common Script Types:

  • P2PKH (Pay-to-PubKeyHash): Standard "send to address" script.

  • P2SH (Pay-to-ScriptHash): Allows complex spending conditions (e.g., multisig) to be represented by a simple hash.

  • P2WPKH / P2WSH (SegWit): More efficient, fixes transaction malleability.

• Use Cases: Multisignature (multisig) wallets (e.g., 2-of-3 signatures required), timelocks (e.g., CheckLockTimeVerify for escrow or vesting).

[!TIP] Key Distinction: Bitcoin Script is not a smart contract language like Solidity. It is a limited, security-focused scripting system for conditional payments. Ethereum (Unit 2) introduced Turing-complete smart contracts.