Unit 1: Blockchain Concepts and Architectures

1. Foundations and Core Governing Principles

A blockchain is an append-only, cryptographically secured, distributed ledger replicated across an autonomous peer-to-peer (P2P) network. Transactions submitted by participants are bundled into discrete structures called blocks. Each block is mathematically bound to its immediate predecessor through a cryptographic hash pointer, forming an immutable sequence that extends back to the initial or genesis block.

The concept of chaining timestamped cryptographic records originated in seminal research by Stuart Haber and W. Scott Stornetta (1991) to prevent the backdating of digital documents. This foundational model was integrated with distributed consensus mechanisms by Satoshi Nakamoto in 2008 to create Bitcoin, solving the long-standing Double-Spending Problem in decentralized digital cash systems without requiring a centralized clearinghouse.

1.1 Fundamental Properties of Blockchain

Blockchain systems derive their utility and resilience from several interrelated pillars:

• Cryptographic Chaining (prevHash): Each block header contains the hash of the preceding block header:
  $\text{Block}[n].\text{prevHash} = H(\text{Block}[n-1].\text{header})$
  Any retroactive modification of transaction data in block $n-1$ changes its header hash, breaking the link to block $n$ and all subsequent blocks. To forge a past transaction, an attacker must recompute the proof of work or stake for the target block and every succeeding block faster than the rest of the network combined.
• Data Integrity via Cryptographic Primitives: Blockchains employ collision-resistant cryptographic hash functions (such as SHA-256 in Bitcoin or Keccak-256 in Ethereum) and asymmetric digital signature schemes (such as ECDSA using the secp256k1 elliptic curve or Ed25519). Public keys serve as the foundation for user addresses, while private keys produce non-repudiable digital signatures that authorize state transitions.
• Decentralization and Distributed State: Rather than maintaining state in a central relational database, full nodes maintain duplicate copies of the ledger. State updates occur through deterministic state transition rules accepted across the network.
• Consensus Without Central Authority: Decentralized participants reach agreement on the singular valid history of transactions through consensus protocols (e.g., Nakamoto Proof-of-Work, Proof-of-Stake, PBFT), eliminating single points of failure.
• Immutability and Finality: As new blocks accumulate atop a confirmed block, the mathematical cost to overturn that block grows exponentially. Once sufficient confirmations occur, the transaction reaches probabilistic or deterministic finality.
• Transparency and Pseudonymity: On public blockchains, every transaction, balance, and smart contract execution is visible on an open ledger. User identities remain pseudonymous, represented by cryptographic address strings derived from public key hashes.
• Trustless Execution: Participants interact without placing counterparty trust in each other or intermediaries. Trust is shifted to mathematically verifiable protocols, open-source code, and economic game theory.

2. Practical Application Paradigms: The Escrow Mechanism

To understand how distributed ledgers replace traditional financial intermediaries, consider the classic commercial escrow problem.

2.1 The Traditional vs. On-Chain Escrow Model

In traditional commerce, when a buyer purchases goods from an unknown remote seller, a trust dilemma arises:

• If the buyer pays upfront, the seller might abscond without delivering the goods.
• If the seller ships upfront, the buyer might refuse payment upon receipt.

Traditional markets resolve this by employing a trusted third-party escrow agent (e.g., a bank or title company). The buyer deposits funds with the agent, the seller ships the merchandise, and once the buyer confirms delivery, the agent releases the funds. However, centralized escrow introduces significant friction: high percentage fees (2% to 5%), geographic restrictions, processing delays, counterparty risk, and single points of data compromise.

2.2 On-Chain Multi-Signature and Smart Contract Escrow

Blockchain replaces the human intermediary with programmable cryptographic logic:

The 2-of-3 Multi-Signature Model

On UTXO-based networks like Bitcoin, escrow is implemented using multi-signature (multisig) scripts (P2SH - Pay to Script Hash):

1. Setup: A multisig address is created requiring $M = 2$ signatures out of $N = 3$ authorized public keys: the Buyer, the Seller, and an independent Arbiter.
2. Deposit: The buyer funds the 2-of-3 multisig address. The funds cannot be moved by any single party.
3. Happy Path (Cooperative Release): The seller ships the goods. Upon arrival, the buyer signs a transaction sending the funds to the seller. The seller counter-signs. With 2 of 3 signatures present, the transaction is valid and broadcast to the network. The arbiter never participates, incurring zero arbiter fees.
4. Dispute Resolution: If goods do not arrive or are defective, a dispute arises. The arbiter investigates external evidence (e.g., carrier tracking). If the arbiter rules in favor of the buyer, the arbiter and buyer sign a transaction refunding the deposit. If the arbiter rules in favor of the seller, the arbiter and seller sign to release payment.

Programmable Smart Contract State Machine

On account-based platforms like Ethereum, an escrow contract acts as an autonomous state machine governed by explicit state transitions:

• AWAITING_PAYMENT $ightarrow$ AWAITING_DELIVERY $ightarrow$ COMPLETE (or REFUNDED / DISPUTED).
• Timelocks (such as block.timestamp or Bitcoin CheckLockTimeVerify - CLTV) can be enforced to automatically refund the buyer if the seller fails to deliver within a specified block window.

3. The Layered Blockchain Technology Stack

Modern blockchain architectures are structured into distinct functional layers, often conceptualized as a multi-tier protocol stack.

3.1 The Data Layer and Merkle Trees

The data layer defines how state and transactions are packaged and stored:

• Block Architecture: A block comprises a Header (metadata including version, previous block hash, Merkle root, timestamp, difficulty target/bits, and nonce) and a Body (serialized list of transactions).
• The Merkle Tree (Binary Hash Tree):
  Transactions are paired and hashed recursively from the bottom up until a single cryptographic hash remains: the Merkle Root.
  $\text{Hash}_{AB} = H(\text{Hash}_A \parallel \text{Hash}_B)$
  $\text{Merkle Root} = H(\text{Hash}_{AB} \parallel \text{Hash}_{CD})$
• Forensic & Operational Utility of Merkle Trees:
  • Tamper Detection: Altering even a single bit in any transaction changes its leaf hash, propagating changes up the branches and altering the Merkle root in the header.
  • Simplified Payment Verification (SPV): Thin client wallets do not need to download gigabytes of raw transaction history. To verify that a transaction is included in a block, a light node only requests an SPV proof (or Merkle audit trail) of size $O(\log_2 N)$, consisting of the transaction and adjacent branch hashes leading to the Merkle root.

3.2 Layer 1 vs. Layer 2 Architectures

• Layer 1 (L1 - The Base Settlement Layer): The foundational blockchain protocol (e.g., Bitcoin, Ethereum, Solana). L1 guarantees global consensus, security, and final settlement, but suffers from throughput constraints due to the physical limits of decentralized block propagation.
• Layer 2 (L2 - Off-Chain Scaling Execution Layer): Protocols built on top of Layer 1 that execute hundreds or thousands of transactions off-chain while anchoring final state proofs back to L1 for dispute resolution and security guarantees.
  • State Channels (e.g., Lightning Network): Participants exchange cryptographically signed balance states peer-to-peer off-chain, opening and closing channels on L1 via multisig funding transactions.
  • Rollups (Optimistic & Zero-Knowledge): Execute transactions in off-chain virtual machines and bundle hundreds of transactions into a single compressed batch submitted to L1. Optimistic Rollups rely on fraud proofs during a challenge period; ZK-Rollups (Validity Rollups) provide cryptographic zero-knowledge proofs (SNARKs/STARKs) verifying state validity instantly.

4. Evolution from Web 2.0 to the Decentralized Web (Web 3.0)

The evolution of the internet reflects continuous architectural shifts in data ownership, identity, and trust paradigms.

4.1 Drivers for the Decentralized Web

• Data Sovereignty and Privacy: In Web 2.0, users trade privacy for free platform services; centralized providers harvest, monetize, and can leak user behavioral data. Web 3.0 utilizes Self-Sovereign Identity (SSI) and cryptographic keypairs, granting individuals unilateral control over their credentials.
• Censorship Resistance and Platform De-platforming: Centralized platforms possess arbitrary authority to alter algorithms, demonetize creators, or deactivate user accounts. Decentralized applications (DApps) execute deterministically on decentralized runtimes without single administrative choke points.
• Composability: In Web 3.0, smart contracts act as open, interoperable "money legos" or functional modules that can be combined without permission from underlying protocol developers.

5. Domain-Specific Blockchain Applications and Deployment Models

Blockchains are not a universal panacea; their adoption depends strictly on organizational requirements for trust, latency, and governance.

5.1 Permissionless vs. Permissioned Blockchain Architectures

1. Permissionless (Public) Blockchains:
   • Open to anyone globally: any participant can read the ledger, broadcast transactions, or spin up a node to join consensus.
   • Employ economic Sybil-resistance mechanisms (PoW, PoS) with native cryptocurrency incentives.
   • Highly censorship-resistant and decentralized, but possess lower transaction throughput (15–60 TPS on legacy L1s) and high confirmation latency.
   • Examples: Bitcoin, Ethereum, Monero.
2. Permissioned (Private and Consortium) Blockchains:
   • Access is restricted: identities of all participating nodes are known and authenticated through a Public Key Infrastructure (PKI) and Certificate Authority (CA).
   • Employ crash fault tolerant (CFT like Raft) or Byzantine fault tolerant (BFT like PBFT or Istanbul BFT) consensus algorithms that do not require wasteful PoW mining or native speculative tokens.
   • High throughput (thousands of TPS), sub-second deterministic finality, and strict privacy controls, but sacrifice trustless decentralization.
   • Examples: Hyperledger Fabric, R3 Corda, Quorum.

5.2 Applicability Framework: When is a Blockchain Required?

Following the methodology of Wüst and Gervais (2018), engineers evaluate whether a blockchain is justified using a structured decision process:

1. Is there a need to store state? If No $ightarrow$ Do not use a blockchain.
2. Are there multiple writers? If No $ightarrow$ Use a standard encrypted database.
3. Can an always-online, fully trusted third party (TTP) be used? If Yes $ightarrow$ Use a centralized database with TLS and access control lists.
4. Are the writers trusted or have aligned incentives? If Yes $ightarrow$ Use a distributed database with replication (e.g., Cassandra, CockroachDB).
5. If writers are untrusted, is public verifiability required?
   • If Yes $ightarrow$ Deploy a Permissionless Blockchain.
   • If No $ightarrow$ Deploy a Permissioned / Consortium Blockchain.

5.3 High-Impact Enterprise Domains

• Supply Chain Traceability: Real-time provenance tracking for pharmaceutical drugs, luxury goods, and food supply chains (e.g., cold chain temperature compliance via IoT oracle integration). Eliminates counterfeit goods by ensuring each transfer of custody is digitally signed and immutable.
• Healthcare Data Interoperability: Decentralized patient-controlled electronic health records (EHR). Hash pointers of medical records stored in off-chain encrypted repositories (IPFS) are referenced on-chain, enabling granular, auditable patient consent for hospital access.
• Decentralized Finance (DeFi): Non-custodial lending protocols, automated market makers (AMMs), and collateralized stablecoins executing 24/7 without banking intermediaries.
• Cross-Border Remittances and Real-Time Settlement: Replacing multi-day correspondent banking hops (SWIFT) with near-instant cryptographic asset transfer, slashing settlement times from days to seconds.

6. Systemic Benefits, Trade-Offs, and Open Challenges

Deploying decentralized architectures requires navigating severe engineering trade-offs.

6.1 The Blockchain Trilemma

Formulated by Ethereum co-founder Vitalik Buterin, the Blockchain Trilemma posits that a decentralized ledger can achieve at most two out of three properties simultaneously:

1. Decentralization: The network can be run by ordinary consumer hardware across a vast number of geographically distributed nodes.
2. Security: The network can withstand Byzantine attacks from well-capitalized adversaries (e.g., 51% hash rate or 33% stake attacks).
3. Scalability: The network can process thousands of transactions per second (matching enterprise clearinghouses like Visa).

Traditional architectures sacrifice decentralization to achieve scale (e.g., EOS or centralized cloud databases). Bitcoin and Ethereum L1 prioritize decentralization and security, relying on Layer 2 modular rollups to solve the scalability vector.

6.2 Key Operational and Technical Challenges

• Storage and State Bloat: Full nodes must store the entire history of transactions and the growing global state tree. Over time, storage requirements expand to terabytes, increasing hardware costs and threatening node decentralization.
• The Oracle Problem: Smart contracts are deterministic state machines isolated inside their execution runtimes; they cannot natively fetch real-world data (such as commodity prices, weather, or shipping delivery receipts). They must rely on Oracles (e.g., Chainlink), re-introducing trust vulnerabilities if the oracle data source is manipulated.
• User Experience and Key Management: Blockchain transactions are irreversible; there is no "password reset" or customer support line. Losing a private key results in total, permanent loss of assets.
• Regulatory and Legal Friction: The immutability of public blockchains directly conflicts with data protection mandates such as the European Union's GDPR Right to be Forgotten (Article 17). Once personal data or identifiers are committed to a public block, they cannot be pruned without hard-forking the network.