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

UNIT 4: Blockchain Technology - Short Notes

I. Cryptographic Foundations & Data Structures

A. 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).

Essential Properties:

1. Deterministic: Same input → same hash, always.

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

3. Second Pre-image Resistance: Given input x1, it is infeasible to find a different input x2 such that hash(x1) = hash(x2).

4. Collision Resistance: It is infeasible to find any two distinct inputs x1 and x2 such that hash(x1) = hash(x2).

5. Avalanche Effect: A tiny change in input (e.g., 1 bit) causes a drastic, unpredictable change in the output hash (~50% of bits flip on average).

Role in Blockchain:

• Block Linking: Each block header contains the hash of the previous block. This creates an immutable chain; altering any past block changes its hash, breaking all subsequent links.

• Transaction Hashing: Each transaction is hashed to create its unique TXID. These hashes are used to build the Merkle Tree.

• Data Integrity: Any tampering with block data is immediately detectable by recalculating and comparing hashes.

[!TIP] Exam Focus: Be prepared to explain why each property (especially collision resistance) is critical for blockchain security. A collision could allow an attacker to substitute a malicious transaction with a valid hash.

B. Public Key Cryptography (PKC)

PKC uses a key pair: a private key (kept secret) and a public key (shared openly).

• Digital Signatures (e.g., ECDSA in Bitcoin):

  • Signing: Signature = Sign(private_key, message_hash). Proves ownership and message integrity.

  • Verification: Verify(public_key, message_hash, signature). Anyone can verify the signature without knowing the private key.

• Address Generation: A blockchain address (e.g., Bitcoin address) is a hashed representation of the public key, often with a version byte and checksum. Example flow:

  Private Key → Public Key (via EC multiplication) → Public Key Hash (SHA-256 + RIPEMD-160) → Address (Base58Check encoding)

• Encryption/Decryption: Less common in public blockchains (used in private/enterprise chains for data privacy). Public key encrypts, private key decrypts.

C. Merkle Trees

A Merkle Tree (or hash tree) is a binary tree where:

• Leaf Nodes: Hashes of individual transactions.

• Non-Leaf Nodes: Hashes of the concatenation of their two child nodes.

• Root Node (Merkle Root): Single hash stored in the block header. It is a cryptographic commitment to all transactions in the block.

Importance:

1. Efficient Verification (SPV): A Simple Payment Verification (SPV) node can prove a transaction is in a block without downloading the entire block. It only needs the transaction hash, the Merkle root (from block header), and the "Merkle proof" (hashes of sibling nodes along the path to the root).

2. Data Integrity & Tamper Detection: Any change to a single transaction changes its leaf hash, which propagates up, altering the Merkle root. A valid root proves the entire set of transactions is intact.

3. Scalability: Enables lightweight clients.

[!DIAGRAM: SEARCH: "Merkle Tree blockchain structure diagram"]

Search for diagrams showing leaf nodes, parent node hashing, and the Merkle root in a block header.

D. Block Structure

A block consists of a Block Header and a Transaction List.

Block Header Fields (80 bytes in Bitcoin):

Transaction List: Variable-length list of all transactions included in the block. The first is usually the coinbase transaction (miner's reward).

Block Size Limit: A protocol-defined maximum (e.g., 1-4 MB in Bitcoin) to control propagation times and prevent spam.

II. Blockchain Types & Design Paradigms

A. Public vs Private Blockchains

B. Permissioned vs Permissionless Blockchains

• Permissionless: Synonym for Public. Open participation.

• Permissioned: Synonym for Private. Focus on design issues:

  1. Identity Management: Robust Membership Service Provider (MSP) is crucial. Every participant has a known, verifiable digital identity (X.509 certificates).

  2. Scalability: Easier to achieve with a limited, known set of validators.

  3. Privacy & Confidentiality: Can be implemented via channels (Fabric) or transaction privacy (Corda), as counterparties are known.

  4. Regulatory Compliance: Easier to enforce KYC/AML, data privacy laws (GDPR) within a controlled consortium.

C. Hybrid Blockchain Models

A hybrid blockchain combines elements of public and private/consortium chains.

• Typical Structure: A private/permissioned chain for internal, high-speed transaction processing, with periodic anchoring (hashing) of its state or block headers onto a public chain (like Bitcoin or Ethereum).

• Purpose: Leverages the immutability and security of a public chain as a tamper-proof notary, while maintaining the speed and privacy of a private chain for daily operations.

III. Consensus Mechanisms

A. Proof-of-Work (PoW)

Mechanism: Miners compete to solve a cryptographic puzzle: find a nonce such that:

$$Hash(Block\_Header) < Target$$

Where Target is a difficulty-adjusted value. This requires massive computational power (hashing).

Bitcoin PoW vs HashCash:

• HashCash (1997): Original anti-spam proposal. Puzzle: Hash(header + nonce) has k leading zeros. No block propagation or chain concept.

• Bitcoin PoW (2008): Integrates HashCash puzzle into a distributed ledger. Solves the double-spend problem via the longest valid chain rule and economic incentives (block reward).

Major Attacks:

1. 51% Attack: An entity controlling >50% of network hash power can:

   • Double Spend: Reverse own transactions by building a longer private chain that orphans the public chain.

   • Censor Transactions: Refuse to include specific transactions in blocks.

   • Feasibility: Economically prohibitive for major chains like Bitcoin, but possible for smaller chains.

2. Selfish Mining: A miner with >33% hash power withholds found blocks, creating a private lead. They release blocks strategically to increase the probability of their chain becoming the longest, reducing honest miners' revenue.

3. Block Withholding: A mining pool participant finds a valid block but discards it, harming the pool's revenue (often an act of sabotage or competitive attack).

4. Monopoly Problem: See Advanced Topics VIII.A.

B. Proof-of-Elapsed Time (PoET)

Mechanism: Proposed by Intel. Relies on Trusted Execution Environments (TEEs) like Intel SGX.

1. Each validator requests a random wait time from the SGX enclave.

2. The enclave (trusted) generates a random wait time and signs it.

3. The validator with the shortest wait time wins the block and broadcasts it.

4. Others verify the winner's SGX signature and their wait time was sufficiently long.

Advantages:

• Energy Efficient: No computational race; minimal power consumption.

• Secure: Randomness from a trusted source; lottery-based, not resource-based.

• Deterministic: Fair leader selection.

Limitations:

• Hardware Dependency: Requires specific Intel SGX hardware, creating centralization risk.

• TEE Security: Relies on the security of the SGX enclave. Vulnerabilities (like SGX Spectre) compromise the system.

• Not Decentralized: Validators must be known and use approved hardware.

C. Byzantine Fault Tolerance (BFT) - PBFT

Lamport-Shostak-Pease (Practical BFT - PBFT) is a consensus algorithm for replicated state machines tolerating Byzantine faults (arbitrary/malicious behavior).

Phases for a single consensus instance (on a request):

1. Pre-Prepare: Primary (leader) assigns a sequence number n to request m, broadcasts <<PRE-PREPARE, n, d, m>> to all replicas (d is request digest).

2. Prepare: Each replica i broadcasts <<PREPARE, n, d, m, i>> if it accepts the pre-prepare. A replica prepares a request if it receives 2f+1 matching prepare messages (including its own) for the same (n, d, m) from different nodes.

3. Commit: After preparing, each replica broadcasts <<COMMIT, n, d, m, i>>. A replica commits when it receives 2f+1 matching commit messages. The request is now committed and can be executed.

Fault Tolerance Limit: The system can tolerate up to f Byzantine nodes in a network of 3f+1 total nodes.

\boxed{n > 3f}

Where n = total nodes, f = max faulty nodes.

D. RAFT Consensus

RAFT is a Crash Fault Tolerant (CFT) consensus algorithm designed for understandability. It elects a leader that handles all client requests.

Key Mechanisms:

1. Leader Election:

   • Nodes start as followers.

   • If a follower doesn't hear from a leader within an election timeout, it becomes a candidate, increments its term, and votes for itself.

   • Candidate wins election if it receives votes from a majority of nodes.

   • Leader sends periodic heartbeats to maintain authority.

2. Log Replication:

   • Leader receives client command → appends to its log → sends AppendEntries RPC to followers.

   • If follower's log is inconsistent, leader finds the latest point of agreement and overwrites follower's log from that point.

   • Command is committed once replicated on a majority of nodes.

3. Safety & Liveness:

   • Safety: Only a leader with a fully committed log can become leader (via election restrictions).

   • Liveness: As long as a majority of nodes are operational and can communicate, a leader will be elected and logs will progress.

Use Case: Default consensus in Hyperledger Fabric (v1.4+) for ordering service (orderers).

E. Consensus in Permissioned Blockchains

F. Bitcoin Consensus (The "Nakamoto Consensus")

1. Longest Chain Rule (GHOST): Nodes always consider the longest valid chain as the truth. If two chains compete (a fork), miners mine on the chain they received first, but switch to the longer one when they see it.

2. Block Propagation: Blocks are gossiped through the P2P network. Miners receive new blocks, validate them, and start mining the next block on the updated chain.

3. Difficulty Retargeting: Every 2016 blocks (~2 weeks), the network adjusts the Target to maintain an average block time of 10 minutes.

$$\text{New Target} = \text{Old Target} \times \frac{\text{Actual Time of last 2016 blocks}}{2016 \times 10 \text{ minutes}}$$

4. Incentive Alignment:

   • Block Subsidy: New bitcoins created and awarded to the miner of a block (currently 3.125 BTC, halves every 210,000 blocks).

   • Transaction Fees: Sum of fees from all transactions in the block.

   • Economic Rationality: Honest mining (following consensus rules) is more profitable than attacking (due to high hardware/energy cost and risk of devaluing BTC).

IV. Bitcoin Network & Operations

A. Bitcoin P2P Network

• Node Types:

  • Full Nodes: Store entire blockchain (~500+ GB), validate all transactions/blocks, enforce consensus rules. Backbone of security.

  • Lightweight/SPV Clients: Store only block headers (~5 GB). Request proofs from full nodes.

  • Mining Nodes: Full nodes that also perform PoW.

• Network Topology: Unstructured gossip network. Nodes connect to ~8 random peers.

• Message Propagation: Transactions and blocks are flooded through the network. Nodes validate before relaying (prevent spam).

B. Transaction Processing (UTXO Model)

• Structure:

  • Inputs: Reference to previous transaction outputs (UTXOs) being spent. Contains a scriptSig (unlocking script).

  • Outputs: New UTXOs created. Contains a scriptPubKey (locking script, e.g., OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG for P2PKH).

• Validation Rules:

  1. All referenced UTXOs must exist and be unspent.

  2. Sum of input values ≥ sum of output values (difference = transaction fee).

  3. Script execution: scriptSig (from input) + scriptPubKey (from referenced output) must execute successfully on the stack-based, non-Turing complete Bitcoin Script.

• UTXO Set: The set of all unspent transaction outputs. This is the critical state that all nodes agree on, not account balances.

C. Double Spending Problem

Problem: Spending the same digital currency unit (UTXO) more than once. Prevention in Bitcoin:

1. Consensus & Confirmations: A transaction is only final when included in a block that becomes part of the longest valid chain. Each subsequent block is a "confirmation." The probability of reversing a transaction drops exponentially with confirmations (6+ is considered secure).

2. Race Attack: Attacker sends payment to merchant and a conflicting double-spend transaction to a miner they control. If the double-spend gets confirmed first, merchant loses funds. Prevention: Wait for confirmations.

3. Finney Attack: Attacker pre-mines a block containing a double-spend transaction (paying themselves), but doesn't release it. They then make a payment to a merchant. Once the merchant accepts the 0-confirmation transaction, the attacker releases the pre-mined block, reversing the payment. Prevention: Wait for at least 1 confirmation.

4. 51% Attack: As described in III.A.

D. Block Mining

Process:

1. Transaction Selection: Miner selects transactions from mempool, prioritizing high-fee transactions.

2. Block Assembly: Creates a block with:

   • Block header (version, prev hash, Merkle root of selected txs, timestamp, difficulty target).

   • Coinbase transaction (creates new BTC + collects fees).

   • List of selected transactions.

3. PoW Solving: Iterates the nonce (and extra nonce in coinbase) to find a hash of the block header below the Target.

4. Block Propagation: Upon finding a valid nonce, miner broadcasts the block to the network.

Types of Mining:

• Solo Mining: Individual miner. Extremely low probability of finding a block; high variance.

• Pool Mining: Miners combine hash power in a mining pool. Pool operator finds blocks and distributes rewards proportionally to contributed work (via shares). Reduces variance.

• Cloud Mining: Renting hash power from a remote facility. Often associated with scams.

Rewards & Halving:

• Block Reward = Block Subsidy + Transaction Fees.

• Halving: The block subsidy halves every 210,000 blocks (~4 years). Current (2024) subsidy: 3.125 BTC. Next halving (~2028): 1.5625 BTC. Total supply capped at 21 million BTC.

V. Smart Contracts

A. Smart Contract Fundamentals

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 an intermediary upon trigger (e.g., transaction receipt).

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

3. Deterministic: Given the same input and blockchain state, it always produces the same output across all nodes.

4. Decentralized: Stored and executed across multiple nodes in the network.

5. Trustless: Parties do not need to trust each other; they trust the code and the consensus mechanism.

6. Transparent: Code is typically public and auditable (on public chains).

B. Bitcoin Script

• Stack-based, Forth-like, non-Turing complete language. No loops, limited conditional logic (OP_IF/OP_ELSE/OP_ENDIF).

• Opcodes: ~200 instructions for stack manipulation, arithmetic, cryptography (OP_CHECKSIG, OP_CHECKMULTISIG), and flow control.

• Script Types:

  • P2PK (Pay-to-PubKey): pubKey + OP_CHECKSIG. Simple but exposes public key.

  • P2PKH (Pay-to-PubKey-Hash): Most common. OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. Hides public key until spent.

  • P2SH (Pay-to-Script-Hash): OP_HASH160 <scriptHash> OP_EQUAL. Allows complex spending conditions (multisig, timelocks) to be hashed, simplifying sender's job.

  • Multisig (P2MS): OP_m <pubKey1> ... <pubKeym> OP_n OP_CHECKMULTISIG. Requires m signatures from n keys.

  • Timelocks: OP_CHECKLOCKTIMEVERIFY (absolute) / OP_CHECKSEQUENCEVERIFY (relative). Restrict spending until a certain block/time.

• Limitations: Non-Turing complete (no unbounded loops), limited data access (can't read arbitrary blockchain state), low expressiveness. Designed for security, not complex logic.

C. Ethereum Smart Contracts

• Solidity: Statically-typed, JavaScript-like language. Compiles to Ethereum Virtual Machine (EVM) bytecode.

• EVM: A quasi-Turing complete, sandboxed, stack-based VM. Each node executes contract code. Gas is the execution fee.

• Gas Model: Every EVM operation has a gas cost. Gas Limit (set by transaction sender) = max gas they'll pay. Gas Price (Gwei) = price per gas unit. Transaction Fee = Gas Used × Gas Price. Prevents infinite loops and DoS.

• Lifecycle:

  1. Deployment: Send a transaction with empty to field and contract bytecode. Returns a contract address.

  2. Execution: Call contract functions via transactions (state-changing) or calls (read-only, no gas cost for caller).

  3. Destruction: selfdestruct(opcode) removes code, sends remaining Ether to a target.

• Contract Interactions: Contracts can call other contracts. Events (emit) log data for off-chain listeners.

• Modifiers: Reusable code that runs before/after function execution (e.g., onlyOwner).

D. Hyperledger Fabric Smart Contracts (Chaincode)

• Chaincode: The smart contract logic in Fabric, written in Go, Java, or JavaScript (Node.js).

• Endorsement Policies: Define which peers (organizations) must execute a transaction and validate its result for it to be considered valid. E.g., AND('Org1.peer', 'Org2.peer'). This is the consensus at the application/contract level.

• Lifecycle:

  1. Package: Chaincode source is packaged.

  2. Install: Package is installed on endorsing peers.

  3. Instantiate/Approve: On a channel, the chaincode is instantiated with initial policy and arguments. (In newer Fabric, this is split into Approve and Commit).

  4. Invoke: Clients send transaction proposals to endorsing peers. Endorsers simulate, sign responses (read-write set). Client collects enough endorsements, submits to ordering service.

  5. Upgrade: New chaincode version is packaged, installed, and approved/committed on the channel.

• Invocation: Via peer chaincode invoke or SDK. Transaction is sent to ordering service (RAFT/PBFT) for sequencing, then delivered to all peers for validation and commit.

• Private Data Collections: Allows subsets of organizations to store data privately (on their peers only), sharing only the hash with the rest of the channel. Chaincode can access this private data.

VI. Enterprise Blockchain Platforms

A. Hyperledger Fabric

Architecture (Modular & Permissioned):

• Peers: Host chaincode (endorsing peers) and the ledger (committing peers). Belong to Organizations.

• Ordering Service (Orderers): Consensus component. Sequences transactions into blocks. Does not execute chaincode. Decoupled from peers. Implements RAFT (CFT) or BFT-SMaRt (BFT).

• Channels: Private subnets of communication. Ledger data is isolated per channel. An organization can be on multiple channels.

• Membership Service Provider (MSP): Manages identities (X.509 certificates) for all entities (peers, orderers, users, admins). Defines root of trust for each organization.

• Membership Services: Handles user enrollment, certificate revocation, and authentication.

Identities and Policies:

• MSP Structure: Defines Root Certs, Intermediate Certs, Admins, and Organizational Units (OUs). Each org has its own MSP.

• Policies (ACLs): Access Control Lists define who can do what. Key policies:

  • Readers: Who can read ledger data.

  • Writers: Who can submit transactions.

  • Admins: Who can manage channel config.

  • Endorsement Policy: (See V.D) Which peers must endorse a transaction.

  • Channel Creation Policy: Who can create a channel.

• Attribute-Based Access Control (ABAC): Can use certificate attributes (like hf.Type=client) in policies.

Use Cases:

• Supply Chain Traceability: Track provenance of goods (food, pharmaceuticals) across multiple orgs with privacy (competitors on same channel don't see all data).

• Trade Finance: Digitize Letters of Credit, automate payments upon shipment verification.

• Healthcare Data Sharing: Securely share patient records between hospitals, insurers, labs with patient consent.

B. Ripple (XRP Ledger)

• Consensus Protocol (RPCA): A Byzantine Fault Tolerant agreement protocol among known, trusted validator nodes. Not PoW/PoS.

  • Process: Validators propose candidate transaction sets. Through multiple rounds of voting ("consensus rounds"), they agree on a single set. A new ledger is closed.

  • Uniqueness: No mining. Finality in ~3-5 seconds.

• Validator Nodes: Run by Ripple (initial validators) and third parties (banks, exchanges). UNL (Unique Node List): Each validator configures a list of other validors it trusts to not collude. Consensus requires agreement across the overlap of UNLs.

• XRP Ledger: The native cryptocurrency is XRP. Used as a bridge currency and to pay transaction fees (destroyed, not given to validators).

• Use in Cross-Border Payments:

  • Speed & Cost: Settles in seconds vs days (SWIFT), costs fractions of a cent.

  • Gateway Model: Entities (banks, payment providers) act as gateways to issue IOUs (e.g., USD.gateway, EUR.gateway). XRP is used as a bridge to convert between these IOUs instantly.

  • ILP Integration: Built on Interledger Protocol (ILP) for interoperability with other ledgers/banks.

C. Corda

• Notary Service: A notary is a single node or cluster that prevents double-spends. It receives a transaction, checks its input states haven't been consumed, and timestamps/notarizes it. Provides uniqueness consensus.

• Flows: The transaction building and execution process is defined as a Flow. A flow is a sequence of steps (sub-flows) that two or more parties execute together to reach agreement on a state update (e.g., InitiatorFlow and ResponderFlow).

• States and Contracts:

  • State: A piece of data representing an agreed-upon fact at a point in time (e.g., Cash.State, IOU.State). States are consumed and created by transactions.

  • Contract: Java/Kotlin code attached to a state type. Contains verify() function that enforces business rules (constraints) on any proposed transaction consuming/creating that state.

• Privacy Model:

  • Transaction Privacy: Only parties to a transaction (and the notary) see its contents. Data is shared point-to-point, not broadcast to all.

  • Counterparty Awareness: Parties know exactly who they are transacting with (required for signature).

  • Confidential Identities: Optional feature to use different public keys per transaction for enhanced privacy.

• Corda Network: A global network of Corda nodes run by different organizations. Uses TLS for network security and AMQP for messaging. Has a Network Map Service that lists all active nodes.

D. Platform Comparison

VII. Blockchain Applications & Use Cases

A. Financial Services

1. Cross-Border Payments (Ripple Use Case):

   • Traditional: SWIFT-based, 2-5 days, high fees ($25-50), multiple intermediaries, lack of transparency.

   • Blockchain (RippleNet): Uses XRP as a bridge currency. Speed: 3-5 seconds. Cost: Fractions of a cent. Transparency: Real-time tracking. Settlement: Final, atomic settlement (payment + delivery).

2. Supply Chain Finance:

   • Traditional: Paper-based invoices, slow approval, high fraud risk, limited access for SMEs.

   • Blockchain Improvement:

     • Transparency: All parties (supplier, buyer, bank) see the same immutable record of goods and invoices.

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

     • Reduced Fraud: Tamper-proof documents (Bill of Lading, invoices).

     • Early Payment: Financiers can trust the underlying trade data, offering dynamic discounting.

3. Mortgage Process:

   • Traditional: Manual, paper-heavy (10+ parties: buyer, seller, agents, lenders, title co, county). Takes 30-60 days. High risk of errors/fraud.

   • Blockchain Mortgage:

     • Digitized Assets: Property title as a digital token (NFT-like).

     • Shared Ledger: All parties (lender, title company, county recorder) access the same immutable record of title history, liens, appraisal.

     • Smart Contract Automation: Automates escrow, funds release upon title transfer and recording, payment of fees.

     • Benefits: Reduces time to days, cuts costs, increases trust, prevents title fraud.

4. Trade Finance (Blockchain-Enabled Trade):

   • Traditional: Letters of Credit (LCs) are paper-based, slow (5-10 days), require manual verification by multiple banks.

   • Blockchain Trade: Digitized LCs as smart contracts. All parties (importer/exporter banks, shipping co) share a single, immutable view. Automated Compliance: Smart contract checks shipping documents against LC terms. Automated Payment: Payment released automatically upon proof of shipment. Reduces processing from days to hours, cuts costs, reduces fraud.

B. Identity Management

• Self-Sovereign Identity (SSI): Individuals own and control their digital identity, not a central authority (like a government or Facebook).

• Decentralized Identifiers (DIDs): Unique, persistent identifiers that are controller-independent. Stored on-chain or off-chain with on-chain pointers. Format: did:method:identifier.

• Verifiable Credentials (VCs): Digitally signed, tamper-proof credentials (e.g., "Degree from University X", "Driver's License"). Issuer signs VC → holder stores it → verifier checks issuer's signature and VC status.

• Blockchain-Based System:

  1. Issuance: University (Issuer) signs a VC (degree) and gives it to student (Holder). Hash of VC may be anchored on-chain.

  2. Storage: Holder stores VC in a digital wallet (off-chain).

  3. Verification: Employer (Verifier) requests proof. Holder presents VC + proof of control over DID. Verifier checks issuer's DID on-chain and VC signature.

• Benefits: Tamper-proof records, user control (minimal disclosure), interoperability, reduced identity theft.

C. Other Industry Applications

• Healthcare: Secure, patient-controlled medical records. Different hospitals can access shared history with patient consent. Drug supply chain traceability.

• Government: Voting: Transparent, auditable, immutable votes. Land Registry: Clear title, reduced fraud, faster transfers (e.g., Georgia, Sweden pilots).

• Logistics/Track-and-Trace: Real-time, immutable tracking of goods from source to consumer (food safety, luxury goods anti-counterfeit).

VIII. Advanced Topics & Critical Analysis

A. Monopoly Problem in PoW

The tendency of PoW systems to become centralized due to economic scaling.

1. Mining Pool Centralization: Individual miners join pools to reduce variance of rewards. A few large pools (e.g., Foundry USA, Antpool) control >50% of hash power. Pool operators gain significant influence.

2. Geographic Concentration: Mining is attracted to regions with cheap electricity (e.g., China historically, now US, Kazakhstan). Creates regulatory and geopolitical single points of failure.

3. ASIC Manufacturing Centralization: Design and fabrication of specialized mining hardware (ASICs) is concentrated in a few companies (e.g., Bitmain, MicroBT). Creates barriers to entry.

4. Economic Implications: Undermines the "decentralized" premise. Large pools/miners have more power to censor transactions or launch 51% attacks. Increases rent-seeking behavior.

B. Attacks on PoW (Detailed)

1. 51% Attack: (See III.A). Requires >50% hash power. Can double-spend and censor. Costly to maintain, devalues the coin.

2. Selfish Mining: (See III.A). Miner withholds blocks to create forks. More profitable than honest mining with >33% hash power. Requires coordination or large pool.

3. Block Withholding: (See III.A). A pool participant finds a valid block but discards it. Harms pool revenue. Can be used by competitors or disgruntled employees.

4. Network-Level Attacks:

   • Eclipse Attack: Attacker controls all of a victim node's incoming/outgoing connections. Can feed it false blockchain view, enabling double-spends against the victim.

   • DNS Seed Poisoning / BGP Hijacking: Attacker manipulates network routing or DNS to isolate nodes or redirect traffic, partitioning the network.

5. Finney Attack: (See IV.C). Pre-mined block attack on 0-confirmation transactions.

C. Distributed Consensus in Closed Environment (Permissioned)

Characteristics:

• Known Participants: Identities are known and vetted. Sybil attacks are impossible.

• High Performance: Can use efficient CFT/BFT algorithms (RAFT, PBFT) because the set of validators is small and stable (e.g., 4-20 nodes). Achieves 1000s TPS, sub-second latency.

• Fault Model: Primarily deals with crash faults (CFT) or limited Byzantine faults (BFT). Assumes most nodes are honest.

• Governance: Consensus rules and membership changes are decided by the consortium (off-chain governance).

Trade-offs:

• Performance vs. Openness: Gains massive performance but sacrifices open, permissionless decentralization.

• Trust Shift: Trust moves from "trust in math/code" to "trust in the consortium members and their governance."

• Censorship Resistance: Lower. Consortium can collectively censor transactions or nodes.

• Use Case Fit: Ideal for enterprise consortia where participants are known businesses (banks, supply chain partners) and performance/privacy are critical.

D. Scalability and Performance Challenges

1. Throughput: Number of transactions per second (TPS). Bitcoin ~7, Ethereum ~15-30, Fabric ~1000s.

2. Latency: Time from transaction submission to finality. Bitcoin ~60 min (6 confirmations), Ethereum ~12 min, Fabric ~1-2 sec.

3. Block Size Debate: Larger blocks increase throughput but increase propagation delay, leading to more orphaned blocks and centralization (larger miners propagate faster).

4. Layer-2 Solutions (Off-Chain):

   • State Channels (e.g., Bitcoin Lightning, Ethereum Raiden): Two parties lock funds on-chain, then conduct unlimited off-chain transactions via signed updates. Only final state is settled on-chain. Enables instant, cheap, private payments.

   • Payment Channels: A type of state channel for payments.

   • Sidechains: Separate blockchains with their own consensus, pegged to the mainchain via two-way peg. Assets move between chains.

5. Sharding (Ethereum 2.0+): Partitioning the network into multiple shards. Each shard processes its own transactions/blocks in parallel. Increases throughput linearly with number of shards. Requires complex cross-shard communication.

[!TIP] Exam Focus: Be ready to contrast on-chain scaling (bigger blocks, sharding) vs off-chain scaling (state channels, sidechains). Know the core trade-off: security/decentralization vs throughput.