Blockchain Basics Module
State & Data Models
Transaction history → current state snapshot
Core path (coming soon): Coming soon
Core path articles are coming soon. Use the stage sections below for now.
What this module covers
Blockchains are not only a history of events. They also maintain a current snapshot of data: balances, contract storage, and protocol-defined fields.
This module explains how ownership is represented and how transactions deterministically update state.
It also explains how nodes verify and synchronize the latest snapshot.
This module is for
- Wallet users who want to understand balances, storage, and “what I actually own”
- Developers who need a clear read/write mental model for blockchain state
- Anyone confused by state roots, receipts, and sync modes
This module is not
- Consensus incentives, fees, and scaling (covered in later modules)
- Deep protocol design proofs or formal verification
- Chain-specific low-level storage quirks
Stage 0
Orientation: State as a Snapshot
What does “state” mean in a blockchain system?
See the blockchain as both a log of events and a current snapshot that everyone tries to keep consistent.
Core
What Is Blockchain State?
Supporting (intuition)
Optional intuition and mental models.
Why “History” Alone Is Not Enough
State vs Blocks: Snapshot vs Log
Reference (how to observe the system)
Optional verification via explorers, clients, wallets, and documentation.
How Explorers Show Balances and Contract Storage
You can move on when:
- You can define state as the current snapshot (balances, storage, protocol fields).
- You can explain why “history alone” is not enough for fast queries like balances.
- You can distinguish blocks (log) from state (snapshot).
Stage 1
Ownership Representation
How does a ledger represent “who owns what”?
Learn the two fundamental ownership models without arguing which is “better”.
Core
Account Model
UTXO Model
Supporting (intuition)
Optional intuition and mental models.
Accounts vs UTXOs: Trade-offs
Reference (how to observe the system)
Optional verification via explorers, clients, wallets, and documentation.
How Balances vs UTXOs Appear in Explorers
You can move on when:
- You can describe ownership as balances (account model).
- You can describe ownership as unspent outputs (UTXO model).
- You can name at least one trade-off each model creates.
Stage 2
State & Execution
How do transactions actually change state?
Internalize execution as: read state → apply rules → write new state.
Core
State and Execution
State Transitions
Supporting (intuition)
Optional intuition and mental models.
Why Execution Depends on State Structure
Reference (how to observe the system)
Optional verification via explorers, clients, wallets, and documentation.
Transaction Receipts as State Transition Evidence
You can move on when:
- You can describe execution as a deterministic state transition.
- You can explain why two nodes with the same inputs must produce the same outputs.
- You can connect receipts/logs to “evidence” of a state transition.
Stage 3
Storage & Structure
How is state laid out so it can be verified and queried?
Understand that state data structures and commitments are part of the protocol, not just an implementation detail.
Core
Storage Layout and Data Structures
Merkle Trees and State Commitments
Supporting (intuition)
Optional intuition and mental models.
Storage Slots, Keys, and Indexing
Reference (how to observe the system)
Optional verification via explorers, clients, wallets, and documentation.
How Proofs and State Roots Appear in Blocks
You can move on when:
- You can explain why protocols need commitments (hash roots) to summarize state.
- You can describe a Merkle tree at a high level and what a proof does.
- You can relate state roots to verification and querying.
Stage 4
Snapshots & State Sync
How do nodes catch up to the current state?
Understand that syncing is not only blocks; it also includes state and its proofs.
Core
State Sync Explained
Snapshots and Checkpoints
Supporting (intuition)
Optional intuition and mental models.
Full Sync vs Fast Sync
Light Clients and Data Serving
Reference (how to observe the system)
Optional verification via explorers, clients, wallets, and documentation.
Node Sync Modes in Practice
You can move on when:
- You can explain why downloading blocks is not the whole sync story.
- You can describe what a snapshot/checkpoint is for at a high level.
- You can name the difference between full sync and fast sync.
Stage 5
Practical Implications
Why do data models shape fees, composability, and tooling?
Connect the abstract state model to real system effects developers and users feel.
Core
Composability and Shared State
Supporting (intuition)
Optional intuition and mental models.
Fees and State Growth
Tooling: RPC, Indexers, and State Queries
Reference (how to observe the system)
Optional verification via explorers, clients, wallets, and documentation.
Why Wallets and Apps Don’t Run Full Nodes
You can move on when:
- You can explain why shared state enables composability but causes contention.
- You can connect state growth to costs and operational burden.
- You can name the roles of RPC, indexers, and state queries.
Stage 6
Boundaries & Next Module
What does this model enable — and what problems does it create next?
Lock in the boundaries: stop before incentives, consensus, and scaling, and transition to the networking layer.
You now have the “state lens”: ownership → execution → commitments → sync. Next, zoom out to the node and network layer.
Hard stop (covered later)
- Consensus & finality (agreement over state)
- Fees & incentives (pricing state access)
- Scaling & Layer 2 (reducing shared state pressure)
Next: Nodes & Networking
- How do nodes propagate blocks and transactions?
- How does the network view of state stay synchronized?
- What does “being a node” mean operationally?
Completion checklist
If you can answer these, you have the module’s mental model.
- What is blockchain state (as a snapshot), and why is history alone not enough?
- How do account and UTXO models represent ownership differently?
- What is a state transition, and why must it be deterministic?
- What do Merkle commitments (state roots) enable for verification?
- Why does state sync differ from just downloading blocks?
- How do shared state and data models shape composability and tooling?
FAQ
Back to Blockchain Basics
Blockchain Basics hub
Next module
Nodes & Networking
See how the network keeps blocks and state synchronized in practice.