Ethereum Data Structures Explained

Ethereum's architecture is built upon a sophisticated foundation of data structures and encoding mechanisms that ensure efficiency, security, and scalability. Understanding these components is essential for developers, researchers, and blockchain enthusiasts aiming to grasp how Ethereum maintains state integrity and enables decentralized execution. This article provides a comprehensive yet accessible overview of Ethereum’s core data structures—focusing on Merkle Patricia Trie, RLP encoding, SSZ serialization, and their role in organizing blocks, transactions, and state.

Core Data Structures in Ethereum

At the heart of Ethereum lies a set of optimized data structures designed to balance performance with cryptographic verifiability. The primary ones include:

• Patricia Trie: Enables efficient path compression for fast key-value lookups.
• Merkle Tree: Provides tamper-proof hashing for data consistency across distributed nodes.
• Merkle Patricia Trie (MPT): Combines both concepts to form Ethereum’s main state organization mechanism.
• Recursive Length Prefix (RLP): A compact binary serialization format used across Ethereum 1.0.
• Simple Serialize (SSZ): A newer, Merkle-friendly serialization method introduced in Ethereum 2.0.

These elements work together to support Ethereum’s role as a decentralized world computer.

👉 Discover how modern blockchain systems use advanced data encoding for secure state management.

Understanding Trie Structures

What Is a Patricia Trie?

A Trie (short for retrieval tree) organizes keys based on shared prefixes, enabling fast lookups by traversing character-by-character from the root. However, standard tries can become inefficient when dealing with long common prefixes, leading to deep, unbalanced trees.

The Patricia Trie (Practical Algorithm to Retrieve Information Coded in Alphanumeric) optimizes this by compressing consecutive single-child nodes into one. Instead of storing each character in a separate node, it stores entire path segments, reducing depth and improving access speed.

For example, keys like 1111A, 1111B, and 1111F share the prefix 1111. In a regular trie, this would require four levels of nodes; in a Patricia Trie, those four characters are compressed into a single extension node.

This optimization drastically reduces memory usage and lookup time—critical for blockchain environments where performance matters.

Merkle Trees: Ensuring Data Integrity

A Merkle Tree is a binary tree where each non-leaf node contains the hash of its children. This structure allows lightweight verification of large datasets without transferring all data.

In Ethereum, Merkle Trees are used to:

• Verify transaction inclusion
• Confirm receipt authenticity
• Prove account state

Because any change in a leaf propagates up to the root hash, even minor alterations are immediately detectable. This makes Merkle Trees ideal for trustless consensus.

Ethereum extends this concept by embedding actual data within the tree nodes—going beyond pure hash references found in traditional implementations.

Merkle Patricia Trie (MPT): Ethereum’s State Engine

The Merkle Patricia Trie (MPT) is Ethereum’s fundamental data structure for managing global state. It merges the efficiency of Patricia Tries with the cryptographic security of Merkle Trees.

Each node in an MPT is hashed, and parent nodes reference child nodes via their hashes. This creates a verifiable chain of integrity—from individual accounts to the overall state root stored in every block header.

Node Types in MPT

There are three types of nodes:

• Branch Node: Contains 17 elements — 16 for hex characters (0–F), plus one for value storage. Used when multiple paths diverge.
• Extension Node: Stores a shared path segment and points to the next node. Reduces redundancy in long common prefixes.
• Leaf Node: Marks the end of a path, containing the final part of the key and associated value.

All keys are in hexadecimal format, allowing up to 16 branching possibilities per node.

Path Compression and Hashed References

Unlike classic tries, MPT uses hex prefix encoding (HP) to compress keys and distinguish between leaf and extension nodes. When referencing child nodes, only their Keccak-256 hash is stored—not the raw data—enabling secure, decentralized verification.

This design supports Ethereum’s requirement for persistent, tamper-evident state storage while minimizing overhead.

👉 Explore how next-gen blockchains optimize state trees for scalability and security.

Encoding: From Structure to Bytes

To store structured data in a database or compute hashes, Ethereum must convert complex objects into byte arrays. This is achieved through two main encoding schemes: RLP and SSZ.

Recursive Length Prefix (RLP) Encoding

RLP is used extensively in Ethereum’s execution layer for serializing nested arrays and values. It prioritizes simplicity and space efficiency over self-description.

Key rules:

• Values ≤ 127 bytes: encoded directly.
• Short strings (≤ 55 bytes): prefixed with 0x80 + length.
• Longer strings/arrays: prefixed with length descriptor and byte count.
• Nested structures are recursively encoded.

Example: "ABCD" becomes [0x84, 'A', 'B', 'C', 'D'].

RLP enables consistent hashing across nodes and underpins MPT operations by providing deterministic byte representations.

Hex Prefix (HP) Encoding

Used specifically for MPT node keys, HP encoding compresses nibble sequences (4-bit values) and adds metadata:

• Bit 4 indicates node type: 0 = extension, 1 = leaf.
• Bit 0 indicates path length parity: 0 = even, 1 = odd.

This allows efficient reconstruction during traversal while minimizing storage footprint.

Simple Serialize (SSZ): The Future of Encoding

Introduced with Ethereum 2.0, SSZ replaces RLP in the consensus layer due to its advantages:

• Fixed offsets enable partial deserialization.
• Designed for Merkleization—every field has a predictable position.
• Supports unique canonical forms (critical for consensus).

SSZ uses containers, lists, vectors, and unions to define strict schemas. Unlike RLP, it’s not self-describing—type information must be known ahead of time.

For example, a validator record in the beacon chain is serialized using SSZ so clients can quickly verify signatures or extract status without decoding everything.

This efficiency is vital for light clients and network scalability.

Block and Transaction Architecture

Ethereum operates as a distributed state machine where each block represents a state transition triggered by transactions.

Post-Merge Block Structure

After The Merge, Ethereum transitioned from Proof-of-Work to Proof-of-Stake. The new block structure includes:

type BeaconBlock struct {
    Slot               uint64
    ProposerIndex      uint64
    ParentRoot         [32]byte
    StateRoot          [32]byte
    Body               BeaconBlockBody
}

The ExecutionPayload inside the body contains all legacy transaction data:

• transactions: List of signed transactions
• withdrawals: Validator withdrawals (post-Shanghai)
• blob_gas_used: Blob gas consumed (post-Cancun/EIP-4844)

Fields like difficulty and nonce are now set to zero or constants since they’re no longer relevant under PoS.

Transaction Types Evolution

Ethereum supports several transaction types:

• Legacy Transactions: Original format with fixed gas price.
• Access List Transactions (EIP-2930): Pre-declare accessed addresses to reduce gas costs.
• Dynamic Fee Transactions (EIP-1559): Introduce base fee + priority fee model; improves UX and fee predictability.
• Blob Transactions (EIP-4844): Carry temporary large data blobs for L2 rollups at lower cost.

Each reflects a step toward scalability, user experience, and economic efficiency.

Data Representation in Practice

Ethereum uses four main MPTs:

1. World State Trie: Maps addresses to account states.
2. Transaction Trie: Stores all transactions in a block.
3. Receipts Trie: Contains execution results (logs, status).
4. Storage Trie: Holds contract variable data per account.

Account Model

Two account types exist:

• Externally Owned Accounts (EOA): Controlled by private keys; hold ETH.
• Contract Accounts: Store code and data; activated by transactions.

Account state includes:

• nonce: Transaction count (EOA) or contract creation count.
• balance: Current ETH balance.
• codeHash: Hash of EVM bytecode (empty for EOAs).
• storageRoot: Root of the account’s storage trie.

All updates go through state transitions validated by the EVM.

Storage Layout

Smart contract variables are stored in slots (32-byte units). The Solidity compiler determines slot assignment:

• Small variables may be packed into one slot.
• Mappings and dynamic arrays use keccak(slot_index + key) to derive sub-keys.
• Strings < 32 bytes store length in the last byte.

This deterministic layout enables predictable access but limits flexibility—once deployed, storage cannot be reorganized safely.

Frequently Asked Questions

Q: Why does Ethereum use Merkle Patricia Tries instead of regular Merkle Trees?
A: MPTs combine efficient key lookup (via path compression) with cryptographic verification (via hashing), making them ideal for dynamic state management.

Q: What is the difference between RLP and SSZ?
A: RLP is recursive and flexible but slow to decode partially; SSZ is schema-based, faster for consensus needs, and optimized for Merkle proofs.

Q: How are contract storage variables addressed?
A: Each variable gets a slot index; mappings and arrays use keccak(slot + key) to compute actual storage keys.

Q: What replaced mining after The Merge?
A: Proof-of-Stake replaced mining; validators propose blocks based on staked ETH rather than computational work.

Q: Why is HP encoding needed in MPTs?
A: It compresses paths efficiently while encoding node type and path length parity—critical for correct traversal and decoding.

Q: Can old contracts use blob transactions?
A: No—blob transactions are a new type usable only by EOAs or contracts explicitly designed to handle them post-EIP-4844.

Conclusion

Ethereum’s data architecture reflects years of innovation aimed at balancing decentralization, security, and performance. From the foundational Merkle Patricia Trie to modern SSZ serialization, every component serves a purpose in enabling reliable state transitions across a global network.

As Ethereum evolves with upgrades like Proto-Danksharding and Verkle Trees on the horizon, understanding today’s data structures remains crucial for building robust dApps, analyzing chain data, or contributing to protocol development.

👉 Stay ahead in blockchain development by mastering core cryptographic data structures.