On-Chain Storage

The state trie is the primary data structure for storing the global state of an account-based blockchain like Ethereum. It is a modified Merkle Patricia Trie that maps account addresses to their state (balance, nonce, storage root, code hash).

• Cryptographic Commitment: The root hash of this trie is included in each block header, providing a cryptographic commitment to the entire network state.
• Efficient Verification: Light clients can verify the existence and state of an account by requesting a Merkle proof (a path through the trie) without downloading the entire chain.
• Persistent Storage: The trie is stored across the network's full nodes, with each node responsible for maintaining its local copy of the state database.

Each smart contract account on Ethereum has its own storage trie, a separate Merkle Patricia Trie that stores the contract's persistent variables.

• Key-Value Mapping: It maps 256-bit keys (storage slots) to 256-bit values, as defined by the contract's Solidity or Vyper code.
• Root Hash Reference: The root hash of a contract's storage trie is stored in the account's storageRoot field within the main state trie.
• Gas Costs: Writing to and reading from storage are among the most expensive operations in terms of gas, incentivizing efficient data structure design within contracts.

Each block contains separate tries for its transactions and transaction receipts, enabling efficient and verifiable queries.

• Transaction Trie: Contains all transactions included in the block, indexed by their order within it. The root is stored in the block header as transactionsRoot.
• Receipt Trie: Contains transaction receipts, which are records of the outcome of each transaction (status, gas used, logs emitted). The root is stored as receiptsRoot.
• Logs Bloom: A Bloom filter derived from the logs in the receipts is also included in the header, allowing light clients to efficiently filter for events of interest.

Ensuring data is available and managing the growth of on-chain state are critical scaling challenges.

• Full Nodes vs. Archive Nodes: Full nodes store the current state and recent blocks. Archive nodes store the entire historical state, enabling queries of any account's state at any past block.
• State Pruning: Nodes can prune old state trie nodes that are no longer referenced by the current state, significantly reducing disk usage while maintaining full validation capability.
• Witness Data: Protocols like Ethereum's Verkle Trees (planned) aim to replace Merkle proofs with more efficient vector commitments, reducing proof sizes for light clients.

The Unspent Transaction Output (UTXO) model, used by Bitcoin, takes a different approach to on-chain storage than the account model.

• Chainstate Database: Nodes maintain a UTXO set, a database of all transaction outputs that have not yet been spent. This represents the network's current state.
• Implicit Balance: A user's balance is not stored directly but is the sum of all UTXOs they can cryptographically claim with their private keys.
• Stateless Validation: Proposals like UTXO commitments involve placing the hash of the UTXO set in the block header, allowing for more efficient stateless validation where nodes wouldn't need to store the full UTXO set.

Storing data on-chain is intentionally expensive to align economic incentives with network security and scalability.

• Gas Fees for Storage: Writing data to persistent contract storage consumes gas, paid by the transaction sender. This compensates nodes for the permanent cost of storing that data.
• Storage Refunds: Some blockchains (e.g., Ethereum pre-London, EIP-3529) offered partial gas refunds for clearing storage slots, incentivizing state cleanup.
• Block Space as a Resource: Block space is the ultimate scarce resource. The cost of on-chain storage is fundamentally the opportunity cost of the block space it occupies forever.

The primary form of on-chain storage, where data is stored within a smart contract's state variables. This data is permanently recorded on every node in the network, making it immutable and verifiable by anyone. Key characteristics include:

• High Cost: Storage is the most expensive blockchain operation, priced in gas.
• Persistence: Data survives contract upgrades if stored correctly.
• Examples: Token balances in an ERC-20 contract, DAO proposal data, or NFT metadata for fully on-chain collections.

A critical distinction in Ethereum Virtual Machine (EVM) chains between temporary and permanent data locations.

• Calldata: A read-only, temporary data area containing function arguments. It is cheaper for external function calls but cannot be modified.
• Storage: The persistent key-value store that defines a contract's state. Writing to storage is expensive but permanent. Optimizing gas costs often involves storing data in calldata when possible and using storage only for essential, long-term state.

The fundamental trade-off between decentralization/security and cost/scalability.

• On-Chain: Data is immutable, trustless, and consensus-backed. Ideal for high-value settlement data (final balances, ownership).
• Off-Chain (IPFS, Arweave, Centralized Servers): Data is referenced by a hash (like a CID). Cheaper and scalable, but introduces a liveness assumption—someone must host the data. Used for NFT media, large documents, or historical logs.

Ethereum's Proto-Danksharding upgrade introduced blob-carrying transactions as a dedicated data channel for rollups. Blobs are large data packets (~128 KB each) that are attached to blocks but are not accessible to the EVM and are deleted after ~18 days. This provides rollups with orders-of-magnitude cheaper temporary data availability than using calldata, significantly reducing Layer 2 transaction fees.

Determining what belongs on-chain is a core design decision. Store On-Chain:

• Financial settlement finality
• Governance votes and proposals
• Core protocol parameters Reference Off-Chain:
• High-resolution digital art
• Application logs and analytics
• Lengthy legal documents

The guiding principle: Store only the minimum viable state on-chain to achieve the required security and trust guarantees.

The state is the complete, current representation of all data stored on-chain, including account balances, smart contract code, and variable values. It is the cumulative result of all validated transactions. The state is stored in a Merkle Patricia Trie, allowing for efficient cryptographic verification of any piece of data without needing the entire dataset.

Calldata is a special, read-only data location in Ethereum that contains the arguments passed into a function call. It is the cheapest form of on-chain storage for data that only needs to be temporarily available for transaction execution and does not need to persist in the contract's state. Its primary use is for passing information to functions and for emitting event logs.

Event logs are a cost-efficient method for storing historical data on-chain. While they are emitted by smart contracts and written to the blockchain, they are not accessible to contracts during execution (they are not part of the state). Their primary purposes are:

• Providing a gas-efficient historical record for off-chain applications.
• Emitting data for decentralized application front-ends and indexers.
• Serving as cryptographic proof that a specific event occurred.

Data availability refers to the guarantee that the data for a block is published to the network and is accessible for nodes to download. It is a critical security property for layer-2 rollups, which typically post transaction data to a layer-1 chain (like Ethereum) to ensure anyone can reconstruct the rollup's state and verify its integrity, enabling secure fraud or validity proofs.

Gas cost is the primary constraint and economic mechanism governing on-chain storage. Writing data to persistent storage (SSTORE) is one of the most expensive operations on networks like Ethereum. The cost scales with the amount of data and incentivizes developers to minimize state bloat, use efficient data structures, and leverage cheaper alternatives like calldata and event logs where possible.