Ethereum and Solana: sequential and parallel execution

Solana's runtime, Sealevel, takes the opposite approach. The documentation describes it as a runtime that can process contracts in parallel using the validator's available cores, and the mechanism that makes that possible is a declaration requirement: every instruction in a transaction must list the accounts it will read and the accounts it will write. With that list in hand, the scheduler can identify instructions whose account sets do not overlap and run them concurrently, and it can serialise only the ones that contend for the same account.

The declaration requirement is the whole design. It is what turns an otherwise unknowable dependency graph into one the scheduler can read before execution begins, and it is why Solana's programming model asks the developer to be explicit about account access in a way Ethereum's does not. The cost is that the declaration must be correct: an instruction that touches an account it did not declare is not merely inefficient, it is invalid, because the runtime's safety argument depends on the declaration being complete.

Solana's documentation pairs Sealevel with the rest of the architecture that keeps the pipeline fed: Proof of History as a verifiable ordering of events, Turbine for propagating blocks through a tree of validators, and Gulf Stream for forwarding transactions ahead of the current block. Each component addresses a different bottleneck, and the whitepaper's performance analysis is explicit that the result depends on stated network and hardware assumptions rather than being a property of the protocol alone.

On Ethereum, a developer writes a contract and calls it. The execution environment resolves the call, reads whatever storage the code reaches, and charges gas for the work. Nothing about the contract's storage access has to be declared, and a contract can call another contract whose address it computes at runtime. That flexibility is what makes Ethereum's composability possible, and it is also what makes the execution order load-bearing.

On Solana, a developer writes a program and a client that builds transactions against it, and the transaction has to name the accounts involved. The documentation's account model makes this concrete: an account holds data and a lamport balance, programs are stateless and read their inputs from the accounts passed to them, and the runtime's parallelism follows from the account sets. A developer therefore designs the account layout as part of the program's interface, not as an afterthought, and the layout decides how much of the work can run concurrently.

The two models also differ in what a failed execution costs. On Ethereum, a transaction that reverts still consumes the gas it used up to the revert, and the sender pays for it. On Solana, the documentation describes a fee structure in which a transaction pays a base fee per signature and an optional priority fee, and the compute budget is expressed in compute units. The accounting is different in kind, and a developer moving between the two has to re-learn what a failed call costs and who bears it.

Parallel execution is not free throughput. It converts a scheduling problem into a declaration problem, and the throughput a network actually achieves depends on how much contention real workloads produce: two transactions that write the same popular account cannot run at once no matter how good the scheduler is. The documentation describes the mechanism; it does not promise that every workload benefits from it, and this page does not either.

The comparison is also silent on the cost of running a node, which is where the two designs diverge most sharply in practice. Solana's whitepaper is explicit that its performance analysis assumes stated hardware, and a design that uses a validator's cores to execute in parallel implies a validator with cores to spare. Ethereum's sequential model is cheaper to replay, which is a different kind of scalability: the ability for many independent participants to verify rather than the ability for one machine to process. The design-intent comparison takes that question up directly.

Finally, both platforms are moving. Ethereum's roadmap includes changes to execution and to how state is organised, and Solana's runtime and fee market have changed since the whitepaper. This page describes the models as their documentation describes them at the review date and does not treat a roadmap item as a deployed feature.