EVM vs SVM

On Ethereum, transactions become public before consensus picks them up. When a wallet signs a transaction and hands it to an RPC node, that node drops it into its mempool and forwards it to other nodes right away. From that moment, the transaction is visible to anyone watching the network.

Visible means MEV searchers can see it too. They look for ways to slip ahead of a user (frontrun), follow right behind (backrun), or sandwich both sides of a trade. Even after winning the fee auction, a user cannot decide what other transactions execute next to theirs. That is why services like Flashbots Protect appeared.

Block production itself is also split. A builder collects transactions from both the public mempool and private flows, assembles a candidate block, then sends only the block's header and a bid to that slot's proposer through a relay called MEV-Boost. The proposer signs whichever bid is highest without ever inspecting the body. Most modern Ethereum mainnet blocks are built off-chain by builders, with the proposer effectively rubber-stamping the auction winner.

Once signed, the block propagates back across the network. Ethereum runs on 12-second slots, and 32 slots make up one epoch. The committee assigned to each slot attests to the head, and those attestations decide which fork the network treats as canonical. But attesting alone is not finality. Two consecutive epochs must be backed by at least two-thirds of weighted attestations before the chain reaches finality, which lands at roughly 13 minutes. Until that point, short reorgs can still happen.

The shape of this pipeline is intentional separation: order flow public, block construction private, finality slow but explicit. Ethereum accepts the exposure window and the longer wait in exchange for client diversity, slashing-based accountability, and a clean economic finality boundary that does not unwind.

Solana has no public queue. When a wallet signs a transaction it embeds a recent blockhash, and the transaction stays valid for only about 60 seconds. Anything older is dropped on sight. That short shelf life is itself the first replay defense, working without a mempool at all.

The RPC node runs preflight the moment a transaction arrives, returning the result to the user immediately. If preflight passes, the RPC ships the packet directly to the current leader and the validators about to take over, through a route called Gulf Stream. There is no detour through gossip or a public buffer. The transaction lands on the actual processing node.

That leader feeds the transaction into the TPU. Packets are collected, signatures are verified in batches, and transactions whose writable accounts do not collide are scheduled across worker threads to run in parallel. As they execute, PoH stamps the result with a verifiable time. On Solana, time is decided before consensus catches up to it.

Blocks do not ship as one envelope. The instant transactions execute, the output is split into small pieces called shreds and fanned out concurrently through Turbine. Other validators do not wait for a complete block — they replay shreds the moment they arrive and verify locally. Propagation, execution, and verification overlap in time instead of running back to back.

Once a validator finishes verifying, it attaches a Tower BFT vote to the result. Solana describes confirmation in three tiers. First processed. Once a supermajority of stake votes the same way, it becomes confirmed, typically within 400ms to 2 seconds. After about 31 layers of lockout pile up on the same fork, it reaches finalized at around 12 to 13 seconds. There is no slashing, but the cost to reverse a finalized state grows so quickly with lockout depth that the result is effectively irreversible.

An Ethereum validator is not one program but two, running side by side on the same machine. This was not always so — before the Merge in 2022, a single client did everything. The split was deliberate, and it shapes how the whole network fails and recovers.

The execution client runs the EVM and holds the state — it is the part that actually executes what you send. The consensus client runs the beacon chain and decides which blocks count. The two talk over the Engine API, a narrow interface between them.

The reason for the seam is resilience through diversity. Because several independent implementations exist on each side, a consensus-breaking bug in one client only takes down the validators running that client — not the chain. No single codebase is a point of failure the whole network depends on.

The cost is coordination overhead. An operator runs two programs, keeps two databases, and updates both; the API between them adds a layer that a single integrated process would not need. The design is not built for tight real-time performance — it is built to survive its own bugs.

That is the tradeoff Ethereum accepts. It prioritizes fault isolation and a decentralized set of implementations over acting as one fast unit. The validator is modular and hard to kill, but heavier to run and slower to move as a whole.

Solana goes the other way entirely: one program, the validator, holding every subsystem together in real time. Where Ethereum draws a seam, Solana removes them.

Inside that single process live TPU, TVU, PoH, AccountsDB, Blockstore, and Gossip. They share memory and pass work through channels — not across process boundaries, which would cost time.

The reason is the 400ms slot rhythm. Networking, execution, storage, and consensus all have to move together inside that window. A hard boundary and an API between subsystems, like Ethereum has, would add latency the schedule simply cannot spend.

The cost shows up as a high hardware bar and, for years, single-implementation risk. A validator needs serious CPU, RAM, fast NVMe, and bandwidth to hold the whole machine at that pace. And because one implementation (Agave) ran almost the entire network, a single bug in it could stall the chain — exactly the failure mode Ethereum spends coordination overhead to avoid.

That is why Firedancer matters so much. A second independent client brings the diversity Ethereum gets by design, and pushes throughput higher at the same time. The tradeoff is clear: one tightly integrated, fast machine, bought with heavy hardware requirements and — until Firedancer matured — thin client diversity.

On Ethereum, a wallet and a program are two different kinds of account, and the line between them is sharp. Your wallet is usually an EOA: it holds a balance and is driven by whoever holds the private key. Application logic lives in a separate contract account, driven by its own code.

That separation buys a clean boundary — people sign, contracts enforce rules — but it also means the wallet itself is deliberately dumb. Anything richer than sign-and-send has to be built on top. Smart wallets, paying someone else's gas, batching several actions into one approval — none of that was in the original default, because an EOA is just a keypair.

There is a second consequence that bites developers: on a contract account, the code and the state it touches sit at the same address, married together. You cannot swap the code without carrying the state along with it. So upgrades usually go through a proxy pattern: a permanent front address that forwards to a swappable logic contract. It works, but storage layout clashes, permission mistakes, and botched initialization are a well-known class of bug precisely because state and code are entangled.

The recent direction is to make the wallet programmable without discarding the split. ERC-4337 builds smart wallets at the contract layer; EIP-7702 lets an ordinary EOA delegate to contract code and act like a smart wallet.

The tradeoff, then, is clarity over flexibility. Ethereum keeps a firm user-versus-code boundary that is easy to reason about, and pays for it by bolting richer wallet behavior on top rather than having it built in.

Solana starts from one broad idea: nearly everything is an account. Wallets, program code, token balances, metadata — all of it is an account. On the surface that sounds simpler than Ethereum's two account types, but the simplicity is only skin deep: a developer still has to reason constantly about who owns each account, who is allowed to sign for it, whether it is writable, its rent, and when it gets created or closed.

The important split on Solana is not user-versus-code but code-versus-data. A program's code lives in an executable program account that the program itself cannot modify; the data it works on lives in separate accounts that the program owns. Because one program can own many data accounts, patterns like SPL Token or protocol-owned vaults fall out naturally — one piece of code governing thousands of state accounts.

The primitive that makes this feel native is the PDA: an address with no private key that a program can nonetheless sign for, under rules fixed at derivation time. Vaults, escrows, and program-controlled authorities are just PDAs the program acts through.

Because the holder of a program's upgrade authority can swap its bytecode while the data accounts it owns stay exactly where they are, upgrades do not need Ethereum's proxy dance — the code and the state were never married in the first place.

The tradeoff is design burden, pushed squarely onto the developer. You must decide up front which accounts exist, who creates and owns them, and which instruction may read or write each one. Solana hands you a more flexible account system, and in return asks you to do far more of the state design yourself.

The EVM was designed for expressiveness first. A contract is free to decide, as it runs, what state to read, which other contracts to call, and how to compose behavior on the fly. That openness is why such a wide range of applications could be built on it at all.

The freedom has a structural cost. The EVM is a 256-bit stack machine: it does arithmetic by pushing values onto a stack and popping them off, in unusually wide 256-bit words. That width is handy for cryptography and big-integer math, but it is far from how a real 64-bit CPU works, so every operation runs through an interpreter rather than directly on the hardware.

Execution is shaped by three things at once: opcodes on the stack, reads and writes to storage, and calls out to other contracts — and each of those is metered by gas. Storage in particular is expensive: an addition costs 3 gas, while a single SSTORE that writes to an empty slot costs over 20,000. The cost model is part of the programming model.

So building on the EVM is never just writing the contract logic. You are also designing storage layout, minimizing expensive calls, planning an upgrade path, and estimating what every interaction will cost on-chain before anyone runs it.

That is the tradeoff: the widest possible design space, paid for by pushing execution cost and complexity back onto the developer. The machine will let you express almost anything; making it cheap and safe is your problem.

The SVM was designed for throughput and schedulability first, not open-ended generality. The guiding concern is running many transactions quickly and safely inside one high-performance runtime, and the machine is shaped around that goal.

Structurally it is a register machine built on eBPF. Instead of pushing values on a stack, it keeps them in a fixed set of registers — much closer to how a real CPU already executes code, so programs can be JIT-compiled to machine code and run fast. Cost is metered in compute units, a budget that in practice is simpler to schedule against than Ethereum gas.

Parallelism does not come from the register design, though. The register model makes a single program run fast, and the compute budget lets the scheduler work out how much fits in a block. The remaining condition for running many programs side by side comes from account declarations, covered in the Parallel Execution section.

The price is that programs must fit the runtime more tightly. A program has to disclose the set of accounts it will touch before it runs, and keep its compute and resource use inside declared bounds. The freedom the EVM gives — discover state as you go — is exactly what the SVM takes away.

So the SVM is not really trying to be a faster VM in isolation. It is trading away runtime freedom for constraints that make it easy to schedule inside a parallel system — the mirror image of the EVM's bargain.

Ethereum's consensus is built to make finality a hard, punishable line rather than a probability. The system is Gasper, which pairs a fork-choice rule (which chain is the head right now) with a separate finality rule (which blocks can never be reverted). The two jobs are kept distinct on purpose.

The path to finality runs in rounds. Committees of validators attest to blocks slot by slot; when two-thirds of the stake has backed a checkpoint across two consecutive epochs, that checkpoint locks. In wall-clock terms that is about 13 minutes. It takes that long because every validator votes once per epoch, in turn.

What backs the guarantee is slashing: a validator that double-signs or makes contradictory attestations has part of its stake destroyed, on-chain, automatically. Reverting a finalized block would require at least one third of the total stake to misbehave and be slashed together, which makes reversal not just hard but economically ruinous.

The cost is patience. A user who needs true finality waits minutes, and applications that want faster confirmation have to reason about the weaker, pre-finality state in the meantime.

That is Ethereum's bargain: wait longer, in exchange for a clean, explicit finality line that is expensive to attack and does not unwind once crossed.

Solana's consensus is built to keep pace with the block stream instead of pausing it for rounds of voting. The system is Tower BFT, which runs on top of PoH time and folds each validator's vote into the stream itself rather than treating voting as a separate phase.

Because votes travel with the data, confirmation happens on a much tighter rhythm, and Solana names the stages explicitly. A block is first processed locally; once a supermajority of stake has voted the same way it becomes confirmed, usually within a second or two; and as votes pile up on the same fork it becomes finalized at roughly 12–13 seconds.

The deepening is enforced by lockout: every vote commits a validator more deeply to a fork, and the commitment doubles with each further vote. Abandoning a fork you have voted on again and again costs exponentially more each time, so a finalized fork becomes effectively irreversible through accumulated commitment rather than through a burn.

The difference from Ethereum is the enforcement mechanism. Solana has not yet implemented slashing that destroys stake for misbehavior; irreversibility comes from the growing cost of contradicting your own votes, not from a punishment fund.

So Solana's bargain is the inverse of Ethereum's: much faster commitment, with finality built from accumulating lockout rather than from a slow, explicit, slashing-backed checkpoint.

The EVM runs transactions one at a time, and the reason is not a missing optimization — it is that the machine cannot know what a transaction will touch until it runs it. A contract computes its storage targets while executing: it reads a mapping whose key was just derived, then calls another contract that reads state of its own. The full state footprint only exists after the fact.

Parallel execution needs the opposite. To run two transactions at the same time safely, the scheduler must know in advance that they will not touch the same slot. If they might, running them together risks two writes landing in the wrong order and a corrupted state. Without a guarantee up front, the safe default is a single lane.

Ethereum did add a way to hint at the footprint. Access lists let a transaction pre-declare the slots it expects to touch. But the declaration is optional and unenforced — a transaction can touch more than it listed — so the scheduler cannot treat it as a promise. It helps gas accounting, not trust.

Block-level access lists, part of the upcoming Glamsterdam upgrade, close the gap from the other side. The block producer records the footprint after executing, and validating nodes can use that list to re-execute transactions in parallel. The list only exists after execution, though, so building the block is still sequential.

So Ethereum accepts sequential execution at the base layer and moves parallelism up a level, into rollups. Execution happens off-chain across many rollups running side by side; L1 keeps only settlement and data availability. The base layer stays one lane, but many lanes run above it.

The tradeoff is deliberate. Sequential L1 is simple and safe by default — developers never have to declare what they touch. The price is a hard throughput ceiling on L1 itself, and the complexity of scaling gets pushed outward to the rollup layer rather than solved in place.

Solana asks for the one thing Ethereum cannot get: every transaction must declare, before it runs, the accounts it will read and write. The state footprint is handed over up front instead of discovered along the way. That single requirement is what makes everything else possible.

With the footprint known in advance, Sealevel can look at a batch of transactions and sort them by what they touch. The Banking Stage then hands non-conflicting transactions to different cores to run simultaneously. Four transfers between eight different people are four independent problems, so they run at once.

The cost lands on the developer. Every instruction has to list its accounts and mark each one read or write, and a transaction that forgets an account it needs simply fails. The freedom to discover state at runtime is traded away for the ability to be scheduled.

The real ceiling is not the scheduler — it is hot accounts. When a popular trading pool is written by thousands of transactions in the same block, they all conflict on that one account and collapse back into a single line. Parallelism disappears exactly where demand is highest, which is the honest limit of the model.

Solana softens that with local fee markets: the bidding war over a hot account raises fees only for transactions touching that account, not for everyone else. The tradeoff is plain — more scheduling machinery and a real declaration burden, bought in exchange for genuine parallel throughput whenever the footprints stay apart.

Every one of the differences above traces back to a single roadmap choice, and Ethereum's has stayed the same for years: take execution pressure off L1, and spend the base layer's budget on being the best possible settlement layer instead.

The near-term work is about making room for rollups. Blobs gave rollups a cheap place to post their data. PeerDAS, added in the Fusaka upgrade (2025), means each node no longer has to download every blob, which opens the way to much more blob space. Further along that path is Danksharding, which spreads data availability across the whole validator set for far more blob space. The base layer is being tuned to anchor many execution environments cheaply, not to execute much itself.

The longer-term work is about making the chain cheap to verify. Verkle trees were the leading candidate for shrinking state proofs so light clients can check the chain without holding it. Binary trees, which work better with zero-knowledge proofs, are now under consideration too. Separate research aims to bring the 13-minute finality down to a single slot. The theme is a base layer that is thinner, easier to verify, and better at being trusted.

Since 2025, scaling L1 itself has gained weight too. The block gas limit keeps rising, and the block-level access lists in Glamsterdam are meant to speed up L1 execution. The same upgrade brings ePBS, which pulls the MEV-Boost auction from the first section into the protocol. Glamsterdam activated on the Sepolia testnet in October 2026, with mainnet expected in Q4 2026. The overall direction has not changed: most throughput is expected from rollups, while L1 concentrates on data availability and settlement.

The direction is modular by design: Ethereum is deliberately becoming a foundation for other execution layers rather than the execution layer itself.

Solana's roadmap pushes the exact opposite: put more throughput, better software, and better hardware efficiency directly into L1, and refuse to export execution elsewhere.

That is why Firedancer matters so much. Rather than splitting work outward, Solana is rewriting the validator itself to run faster and, with a second independent client, to fail less. The bet is that one machine can be made fast enough that a second layer is unnecessary.

Consensus is being redesigned too. Alpenglow, approved by a validator vote in 2025, replaces Tower BFT and Turbine. Validators exchange votes directly instead of putting them into blocks as transactions, with the goal of cutting finality from today's 12–13 seconds to around 150ms. As of October 2026 Alpenglow is still running on testnet with no mainnet date set; its prerequisite, BLS key registration for vote accounts, went live on mainnet in July 2026.

The rest of the roadmap keeps the state on L1 but makes it cheaper to hold. State compression lets huge numbers of NFTs or records live on-chain at a fraction of the usual cost, and ongoing work trims how much a validator must keep in fast memory. The goal is more capacity in the same place, not capacity moved outside.

The cost of this direction is exactly the hardware and single-machine pressure the earlier sections described. Denser L1 means heavier validators, which is why client diversity and efficiency work sit at the center of the plan rather than at the edges.

So the two roadmaps are mirror images. Ethereum gets thinner and pushes execution up and out; Solana gets denser and pulls everything into one fast base layer. That single contrast is still the cleanest summary of the whole comparison.