1. Blockchain as a Distributed Ledger

A blockchain can be viewed as an append-only, tamper-evident ledger replicated across a set of nodes. Each node maintains a local copy of the ledger and participates in validation and consensus. Unlike a centralised database, there is no single owner; instead, nodes collectively agree on the canonical history.

Core characteristics include:

• Immutability: once data is finalised, modification requires prohibitive computational or economic effort.
• Transparency: the ledger is auditable by any participant.
• Replicated state: every full node stores the same logical state.
• Deterministic state transitions: given an initial state and ordered transactions, all honest nodes converge to the same result.

2. Block Structure: Header, Body and Metadata

A block is a container for a batch of transactions plus metadata required for validation and consensus. Abstractly, we can decompose a block into:

• Header: compact summary of the block contents and consensus-critical fields.
• Body: ordered list of transactions and, in some systems, additional data (e.g., receipts, logs).
• Ancillary fields: signatures, proofs, or justifications depending on the consensus algorithm.

2.1 Header Fields (PoW-style systems)

A canonical PoW-style block header typically contains:

• Parent hash: reference to the previous block, forming a chain.
• Merkle root: commitment to the transactions in the block body.
• Timestamp: approximate block creation time.
• Difficulty target or stake-related metadata.
• Nonce / proof data: proof-of-work or proof-of-stake fields.

2.2 Transaction List

The block body contains an ordered list of transactions. The order matters, because state transitions are sequential. Different mempool ordering policies (e.g., gas price, MEV strategies) can produce different candidate blocks, even with the same transaction set.

3. Transactions and State Transitions

A transaction is a state transition request signed by an externally owned account (EOA) or, in account abstraction models, by a more general authorisation scheme. Transactions specify:

• Source and destination addresses.
• Value transfers (e.g., native token amount).
• Payload data (e.g., smart contract function calls and parameters).
• Fees and gas limits.
• Cryptographic signatures.

The execution environment (e.g., EVM) interprets each transaction, applies the associated state transition rules, and either commits the resulting state (if successful) or reverts (if constraints are violated).

4. Merkle Trees and Cryptographic Commitments

Because blocks may contain thousands of transactions, we need a compact way to authenticate their contents without transmitting every transaction in every context. Merkle trees provide a logarithmic-size proof mechanism.

4.1 Merkle Tree Basics

A Merkle tree is a binary hash tree. Leaves correspond to transaction hashes; internal nodes are hashes of their children. The root hash (Merkle root) commits to the entire set.

• Merkle proofs allow a node to verify inclusion of a transaction using a path of hashes.
• Proof size grows as O(log n) with number of transactions.
• Light clients use these proofs to verify data without storing full blocks.

4.2 Extended Commitment Structures

Modern systems generalise Merkle structures:

• Merkle–Patricia tries for key–value maps (e.g., Ethereum state).
• Verkle trees using vector commitments for smaller proof sizes.
• Sparse Merkle trees for large address spaces.

5. State Models: Account-Based vs UTXO

Blockchains instantiate two major paradigms for representing value ownership and state: the UTXO model and the account-based model.

5.1 UTXO Model

In UTXO systems:

• State consists of unspent transaction outputs (UTXOs).
• Transactions consume existing UTXOs and create new ones.
• Each UTXO is a discrete coin with a locking script.

Properties:

• Natural parallelism: independent UTXOs can be spent concurrently.
• Non-trivial expressiveness for complex smart contracts.
• Good for privacy with appropriate address hygiene.

5.2 Account-Based Model

In account-based systems:

• Each address has a balance and associated state.
• Transactions modify balances and persistent storage directly.
• Smart contracts are accounts with code and storage.

Properties:

• Easy to reason about for smart contracts.
• More complex concurrency semantics.
• State bloat is a central concern.

6. Networking Layer and Node Roles

The networking layer is responsible for transaction and block propagation across the peer-to-peer (P2P) network. Design choices here affect latency, bandwidth, and resilience.

6.1 Node Types

• Full nodes: validate all blocks and maintain full state.
• Archival nodes: store full historical state.
• Light clients: only store headers and use proofs.
• Validator / miner nodes: participate directly in consensus.

6.2 Gossip Protocols

Most blockchain networks use gossip-style propagation:

• Nodes maintain peer lists and forward new messages.
• Redundant propagation enhances robustness but costs bandwidth.
• Flooding mitigations (e.g., inventory messages, relay policies) are needed.

7. Data Availability, Pruning and State Growth

A blockchain must ensure that all data required to validate the chain remains accessible. However, unlimited data growth is unsustainable.

7.1 Data Availability

Nodes require access to transaction data to verify correctness. Data availability failures can lead to:

• Inability to reconstruct state.
• Hidden invalid transitions.
• Denial-of-service scenarios.

7.2 Pruning and Snapshots

To mitigate storage growth:

• Old state can be pruned once newer checkpoints are trusted.
• State snapshots allow fast sync from recent state without replaying the entire history.
• Archival nodes preserve full history for audit and research.

8. Execution Environments and Virtual Machines

Smart-contract capable blockchains embed an execution engine such as the Ethereum Virtual Machine (EVM) or WASM-based runtimes. The VM defines:

• Instruction set.
• Gas cost schedule.
• Call semantics and error handling.
• Deterministic behaviour constraints.

Execution environments are tightly coupled to consensus: every validating node must replay contract execution to verify blocks.

9. End-to-End Block Validation Workflow

From a systems viewpoint, validating a new block involves:

1. Checking header fields (parent linkage, difficulty, timestamps, consensus proof).
2. Verifying the Merkle root against the received transaction list.
3. Sequentially executing transactions and updating state.
4. Ensuring all invariants (e.g., no negative balances, no double spending) hold.
5. Persisting the new state and appending the block to the local chain.

This end-to-end process is the foundation upon which consensus and scalability mechanisms operate, and it must remain correct and efficient even as system throughput increases.

10. Module Summary

In this module, we decomposed blockchain systems into their structural components: blocks, transactions, state models, Merkle commitments, node roles, and execution environments. A sound grasp of these architectural primitives is essential before analysing consensus protocols and scalability strategies.

In Module 2, we will focus on consensus mechanisms, particularly Nakamoto-style consensus and proof-of-work/ proof-of-stake designs, and study how these systems achieve agreement in adversarial networks.