Motivations
Over the last few years, I’ve worked on almost every layer of the Ethereum stack: smart contracts, indexers, DeFi bots, execution clients, and distributed systems built around the EVM.
One of the most challenging projects my team worked on was building a high-performance L1 execution client with full P2P capabilities. Along the way, we redesigned large parts of the execution pipeline and implemented a custom BFT consensus protocol on top of the Engine API to push the architecture to its limits.
That experience highlighted an important lesson: while many bottlenecks can be optimized, the storage model remains one of the fundamental constraints shaping Ethereum’s scalability. The way state is stored, accessed, and verified has far-reaching consequences across the entire system.
This led me to study Solana’s architecture. Rather than asking why Solana is faster, I wanted to understand how a different storage model shifts complexity and which trade-offs it introduces.
In this article, I’ll compare the storage models of Ethereum and Solana, discussing how they influence scalability, developer experience, verification, and decentralization.
A framework for reasoning
Comparing blockchain architectures is ultimately about comparing trade-offs.
No design is universally better: every optimization comes at a cost. Throughout this article, I’ll use the blockchain trilemma as a simple mental model for reasoning about these trade-offs [1] [2].
The trilemma identifies three desirable properties of a blockchain:
- Scalability: Efficiently process increasing transaction demand.
- Security: Protect ledger integrity and enable independent state verification.
- Decentralization: Enable broad participation in network validation.
The goal isn’t to decide whether Ethereum or Solana is superior, but to understand how a different storage model shifts complexity and influences these three dimensions.
The Ethereum Storage Model
Ethereum models the blockchain state as a single global key-value store. The following diagram shows how state is organized and committed at the protocol level.
Each account is identified by an address and stores a small set of metadata. Smart contracts additionally own a private key-value storage, organized into 256-bit storage slots.
A fundamental property of this model is ownership: every storage slot belongs to exactly one contract. Contracts can freely access their own storage, while interaction with another contract’s state is only possible through function calls.
All accounts and their storage are committed into a single Merkle Patricia Trie [3], producing a state root for every block. This allows any node to independently verify the correctness of the blockchain state using Merkle proofs.
As we’ll see later, many of Ethereum’s strengths—and limitations—stem from this storage model.
The Solana Storage Model
Unlike Ethereum, Solana does not expose a single global state owned by smart contracts. Instead, application state is distributed across independent accounts. The following diagram illustrates how programs and accounts relate to each other.
Programs are stateless: they own executable code but do not own storage. Application state lives in separate accounts, each identified by an address and storing arbitrary data.
Programs can read and modify any account explicitly passed to them in a transaction, provided the required permissions are satisfied. Rather than discovering state during execution, every transaction declares upfront which accounts it intends to access.
This design makes state an explicit part of every transaction. As we’ll see later, this seemingly small difference has far-reaching implications for scalability, indexing, verification, and developer experience.
Key Differences
The different storage models have implications across multiple dimensions. Each of the topics below could easily deserve an article of its own; the goal here is not to provide an exhaustive treatment, but to highlight the key architectural differences and the trade-offs they introduce.
State Model
The first difference lies in ownership. In Ethereum, storage belongs to smart contracts and can only be accessed through their public functions, providing a strong encapsulation boundary. In Solana, state lives in independent accounts, while programs remain stateless.
This also changes how state is accessed. Ethereum contracts discover state dynamically during execution, whereas Solana programs receive all the accounts they will operate on upfront, much like a stored procedure receiving the records it should process. Making dependencies explicit is what enables safe parallel execution.
Finally, the account model makes application state naturally enumerable. Clients can discover and query accounts through RPC filters or deterministic addresses (PDAs), while equivalent views in Ethereum typically require processing events or maintaining dedicated indexes.
Execution Model
Ethereum transactions behave as black boxes: the storage they access is only known after execution, making dependencies impossible to determine in advance. In Solana, transactions explicitly declare the accounts they will read and write, allowing the runtime to acquire pessimistic locks and safely execute independent transactions in parallel. This is one of the key enablers of Solana’s throughput, whereas state-of-the-art parallel EVM implementations (e.g. Block-STM [4]) pursue parallelism through optimistic execution and conflict resolution.
The different execution model also influences the lifecycle of application state. In Ethereum, historical data can be pruned, but the current state remains part of the global state unless contracts explicitly delete it. In Solana, state lives in independent accounts that can be closed, reclaiming their reserved SOL and completely removing the associated data. This naturally encourages applications to treat storage as a managed resource rather than permanent state.
Developer Experience
Ethereum contracts expose a standardized ABI, allowing clients to interact by simply invoking public functions without knowing how state is organized internally. In Solana, clients must construct instructions and provide the required accounts explicitly, making integrations more tightly coupled to the program’s account model.
This also influences the surrounding tooling. Running an Ethereum node is relatively straightforward, and many applications can rely on a standard RPC endpoint. In Solana, full nodes are more demanding to operate, and applications more often depend on indexing infrastructure and account subscriptions to discover and track application state.
State verification
Ethereum commits the entire blockchain state into a state root—a cryptographic hash that uniquely represents the integrity of the global state—for every block. Using Merkle proofs, any participant can independently verify accounts and storage without trusting a third party. Solana does not maintain an authenticated global state equivalent to Ethereum’s state root. Verifying application state therefore relies more heavily on replaying the ledger or trusting external infrastructure, trading stronger state verification for higher execution throughput.
The Storage Trade-offs
Neither storage model is objectively better. They optimize for different goals by placing complexity in different parts of the system.
Viewed through the blockchain trilemma, the difference becomes clearer.
Ethereum keeps complexity inside the protocol. Authenticated state, storage ownership, encapsulation, and standardized interfaces provide strong verification guarantees, at the cost of execution throughput and long-term state growth.
Solana shifts part of this complexity outside the protocol. Explicit state access enables parallel execution and higher throughput, while clients and external infrastructure take on a greater role in state discovery, indexing, and integration.
Neither approach violates the trilemma. They simply make different engineering choices about where complexity should live.
Conclusions
The storage model is far more than an implementation detail: it shapes almost every aspect of a blockchain, from execution and state management to developer experience and verification.
Ethereum and Solana demonstrate two fundamentally different philosophies. Ethereum keeps complexity inside the protocol, favoring encapsulation, authenticated state, and minimal trust. Solana moves part of that complexity to clients and surrounding infrastructure, enabling a simpler execution model and significantly higher throughput.
Neither approach is objectively better. They simply optimize different points of the design space, reminding us that in distributed systems there are no free optimizations—only different places where complexity ultimately resides.
References
[1] Vitalik Buterin, Why sharding is great: demystifying the technical properties. https://vitalik.eth.limo/general/2021/04/07/sharding.html
[2] The Blockchain Trilemma: A Formal Proof of the Inherent Trade-Offs Among Decentralization, Security, and Scalability. https://www.mdpi.com/2076-3417/15/1/19
[3] Merkle Patricia Trie: https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/?utm_source=chatgpt.com
[4] Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing. https://arxiv.org/abs/2203.06871