For years, almost every public chain and modular project has used the word “scaling,” rarely for the same layer. Rollup teams usually mean moving execution off Ethereum mainnet. Data-availability teams mean publishing and sampling more data cheaply. Parallel-execution L1s mean feeding a single chain’s execution engine across many cores. One word; different security assumptions, ceilings, and failure modes.
This article breaks scaling into non-overlapping layers, marks where L2s, Ethereum’s sharding roadmap, standalone DA, and L1 parallelism each sit, and answers a practical question: what does parallel EVM actually target on this map — substitute for rollups, or complement?
Four jobs first: consensus, DA, execution, settlement
A chain that offers a trusted ledger must do at least four things.
First, consensus: agree on transaction order and block contents, and commit — under stated security assumptions — that the record is not casually rewritten. Second, data availability (DA): publish the data needed to verify state transitions somewhere public enough that anyone can download and recheck. Third, execution: actually run transaction logic and compute the new world state. Fourth, settlement: anchor final state or proofs as a fact external systems can rely on — bridges, cross-chain messages, and fiat on/off-ramps often latch here.
Ethereum in 2015 bundled all four in one node stack — later called a monolithic architecture. The upside is a unified security story and a simple mental model; the downside is that a bottleneck in any layer slows the whole chain. Execution was the first widely felt wall: mainnet throughput long sat in single digits to low teens of TPS, and fees spiked whenever an application got hot. Ethereum’s core roadmap then turned “rollup-centric”: mainnet focuses more on DA and settlement refereeing, leaving bulk execution to L2s. That pivot is the starting point for every branch that follows.
L2 rollups: move execution out, keep security anchored to mainnet
A rollup’s core move is to run transactions in a separate execution environment and send data plus proofs (or challengeable commitments) back to Ethereum. ZK rollups rely on validity proofs; optimistic rollups rely on fraud-proof windows. Mainnet need not replay every transaction — only verify proofs or handle disputes. Execution compute shifts to sequencers and proving systems; settlement security still aims to anchor to Ethereum’s validator set.
This path solves “you can add more execution instances horizontally”: many rollups serve many apps in parallel. It does not automatically solve “is each instance still single-threaded inside.” Many optimistic rollups stay close to classic serial EVM semantics; throughput gains come from dedicated hardware, shorter blocks, and moving congestion from the L1 fee market into the L2’s own market — not necessarily from intra-block parallelism.
Rollups also inherit two constraints. Data must still be published somewhere — calldata, blobs, or external DA — and DA cost returns in user fees. Users also pick up an L2→L1 trust and latency hop (withdrawal challenge periods, bridge risk, sequencer availability). A rollup is never standalone; it sits on DA that is cheap and credible enough.
Public dashboards’ L2 TVL and throughput figures move quickly; cite them as snapshots. Structure matters more: where capital concentrates often reflects preferences about proof cost, challenge design, and operational maturity — not a claim that one theoretical route is forever superior.
Sharding: from execution-sharding talk to data sharding
“Sharding” changed meaning in Ethereum’s history. Early roadmaps stressed execution sharding: split state, execute per shard, then wrestle with cross-shard messaging. Complexity was high; cross-shard composability was hard. As rollups matured, mainnet narrative shifted toward doing less execution and more data capacity — the Danksharding direction, with Proto-Danksharding (EIP-4844) already live.
EIP-4844 introduced blobs: short-lived data space that does not permanently bloat execution-layer state, cutting the cost for L2s to post data to mainnet. Full Danksharding envisions data-availability sampling so nodes need not download everything to gain probabilistic confidence that data is available. The key correction: in today’s Ethereum vocabulary, “sharding” mostly expands DA capacity — it does not reintroduce a multi-threaded EVM on mainnet. Conflating it with Solana, Sui, or parallel-EVM L1 “execution parallelism” scrambles the map.
Standalone DA: modularity’s third leg
Not every rollup wants DA locked to Ethereum’s blob market. Celestia, EigenDA, Avail, and similar projects supply another lane: specialize in publish-and-sample, leave execution and settlement to others. Modular combinations become concrete — execution on a rollup, DA on a dedicated layer, settlement still optionally anchored to Ethereum or another L1.
Standalone DA addresses data-publish bandwidth and cost. It does not directly raise intra-block parallelism on any one chain. It may indirectly make more rollup transactions cheap and lift ecosystem-wide throughput; on “can a single execution engine run in parallel,” the DA layer is mostly silent. When evaluating a project, ask whether it sells execution, settlement, or a data pipe.
L1 parallel execution: widen execution in place
Opposite “move execution out” is another path: keep execution and settlement on L1, but change the engine so conflict-free transactions run in parallel. Solana’s account-declaration scheduling, Aptos-style Block-STM optimistic parallelism, Sui’s object model, and multiple parallel-EVM attempts sit in this cell.
L1 parallelism targets the single-threaded execution ceiling discussed previously. It usually means building your own validator set and consensus — you cannot simply “inherit” Ethereum security — in exchange for liquidity and composability in one settlement domain and one fewer default bridge hop. The cost: performance numbers must be read under the chain’s own security assumptions, and state growth, hardware floors, and decentralization tension land on local governance.
Parallel EVM is a subclass: keep bytecode and tooling compatibility while introducing runtime parallelism. It shares the “execution-layer scaling” coordinate with L1s that change the VM and account model, but not the same developer-migration cost curve. Details of the three parallel paths belong in the next article; here the placement is enough: parallel EVM sells execution width — not DA sampling, and not “spin up more rollups.”
A comparison table
| Path | Bottleneck it mainly hits | Typical move | Common misread |
|---|---|---|---|
| L2 rollup | Mainnet execution capacity | Externalize execution; prove/challenge back | “Intra-block parallelism is solved” |
| Ethereum data sharding / blobs | L2 data-posting cost | Expand DA capacity | “Ethereum shipped execution sharding” |
| Standalone DA | Modular data bandwidth | Specialized publish and sample | “This alone is a full chain UX” |
| L1 parallel execution | Single-instance serial execution | Multi-core scheduling / OCC / object parallelism | “Same metric as a rollup bake-off” |
Complement more than mutual exclusion
Two axes beat slogans. One axis is where execution lives: many off-chain instances, or one on-chain instance made wider. The other is who provides DA: Ethereum blobs, standalone DA, or an L1’s own publication. Real combinations are richer than either/or — a rollup can post to Celestia; a parallel L1 can later coordinate large-object or history strategies with external storage.
Calling parallel EVM simply “anti-Ethereum” or “a sharding replacement” is imprecise. It patches execution width: when a single environment gets dense and contracts get complex, the serial model fails first. Rollups increase the number of execution environments; they do not automatically optimize scheduling inside each one. The two can serve different products and still connect on asset paths.
When reading later technical pieces, ask which layer a number measures. Comparing testnet single-chain parallel throughput to a rollup’s user-perceived TPS under a particular DA cost — without stating premises — is a comparison without information content.
Further reading
- Previous: "Why a Single-Threaded EVM Caps TPS: Congestion History and the Execution Model"
- Next: "Three Paths to Parallel Execution: Deterministic Scheduling, Optimistic OCC, and Object Models"
- Related: "Positioning Bitroot: Boundaries of an Optimistic Parallel EVM Layer 1", "The Tension Between Decentralization and Performance: Validator Requirements, Hardware, and Geographic Distribution"