Parallel EVM has heated up fast over the past couple of years, but it means something completely different depending on who's reading about it. A Solidity developer who sees the words "parallel execution" usually thinks first about whether their own contracts might break. A protocol engineer cares about how the scheduler and conflict detection need to be built to saturate every core. A researcher wants to know whether the so-called "optimistic parallelism" actually comes with a rigorous correctness proof, or whether it's marketing dressed up in database-theory language. All three concerns are legitimate, but lumping them together tends to produce a discussion vague enough that nobody walks away with a clear answer.
That's why, before launching into a hundred-part series on parallel EVM, it's worth splitting the readership first. Not to create an artificial barrier, but because parallel execution is inherently a topic that spans the application layer, the systems layer, and the theory layer — any single article trying to satisfy all three audiences at once will likely fail to do justice to any of them.
Contract developers: will your code have to change
The population of contract developers in the Ethereum ecosystem is far larger than most outsiders assume. According to Electric Capital's annual developer report, Ethereum currently has 31,869 total active developers — nearly double Solana's 17,708, the second-largest ecosystem. In just the first nine months of 2025 alone, Ethereum added 16,181 new developers, the fastest growth rate of any public chain. Another network-effect data point tells a similar story: 74% of engineers doing cross-chain development end up touching an EVM-compatible chain, which means any new chain claiming "EVM compatibility" is plugging directly into the largest developer pool by an order of magnitude, and in theory the cheapest one to migrate from.
But compatibility doesn't mean the change is invisible. For contract developers, parallel execution doesn't change Solidity syntax — it changes the behavioral semantics at execution time. Under a single-threaded EVM, a transfer's execution order and final state are fully deterministic. Under an optimistic parallel environment, transactions within the same batch may be speculatively pre-executed concurrently, with a validation phase later deciding whose results get accepted and whose get rolled back and re-run. For most low-frequency contracts, this process is completely transparent. But for contracts like AMMs, lending protocols, and NFT mints — which read and write the same storage slots at high frequency — conflict rates rise noticeably, which in turn affects gas metering, the user-perceived latency after a failed retry, and even some contract logic that implicitly assumes an ordering between transactions. These details get broken down piece by piece in Series B (read/write sets and conflict detection) and Series C (multi-engine execution architecture) — in particular, articles 25 and 26, which compare hot contracts against low-conflict workloads, and article 96, a migration guide for developers, will directly answer the question "does my code need to change."
Client and protocol engineers: how do you actually build the scheduler, the locks, the state tree
If contract developers care about "will the outcome change," protocol engineers care about "how do you build the mechanism that makes this work." This is a highly engineering-driven problem space: how the transaction dependency graph gets constructed, how batches get split, whether fine-grained locks sit at the account level or the storage-slot level, how deadlocks get detected, and how core pinning under a NUMA architecture avoids letting cross-socket communication drag down overall throughput.
How much this matters to the protocol engineering community is easy to gauge from public channels. On Ethereum Magicians, the Ethereum research community forum, proposals around execution-layer parallelization keep surfacing — for example, a proposal centered on "Frame Transactions" (EIP-8141) explicitly argues that dependencies can be processed in parallel: when the state a transaction accesses is statically declared, the mempool layer can infer state-related dependencies, while purely computational dependencies are handled once, uniformly, at the mempool layer. Earlier still, Vitalik Buterin raised a multi-stage proposal on the same forum exploring whether RISC-V could replace the EVM to simplify the execution layer and improve proving efficiency. That discussion was motivated by zero-knowledge proving rather than parallel execution, but it points to the same broader trend: the execution layer's architecture is being reconsidered from the ground up. None of this is an isolated position taken by one emerging project — it reflects a direction the entire Ethereum engineering community is taking seriously.
For this audience, Series C (multi-engine execution architecture, articles 29 through 48) is the main battleground, covering execution pipeline layering, engine-pool auto-scaling, shared-state lock ordering, memory models and cache coherence, NUMA core pinning, and other concrete engineering decisions. Series D (state, storage, and sharding, articles 49 through 64) goes further, digging into concurrent writes to the state tree, sharding-model selection, and cross-shard messaging — deeper storage and networking problems. Both series lean heavily on concrete data-structure choices and trade-off analysis, rather than stopping at the level of "we built parallelism."
Researchers: where are the boundaries of the model
The third audience's question is more abstract, but it's also the one most likely to puncture holes in marketing claims: a system that calls itself "optimistically parallel" — which correctness definition does it actually satisfy, conflict-serializability or view-serializability? Is its proof formal, or does it amount to "it ran without crashing, so it counts"?
The academic output in this area is becoming dense. Aptos's paper on Block-STM was published at ACM SIGPLAN PPoPP 2023, showing the engine reaching roughly 110,000 TPS on the Diem benchmark and roughly 170,000 TPS on the Aptos benchmark — about 20x and 17x improvements, respectively, over a serial baseline on 32 threads. Its core innovation is using a multi-version data structure to avoid write-write conflicts, and critically, the validation process isn't independent across transactions — it must proceed in a predetermined logical order, so that when one transaction fails validation, every transaction ordered after it can only be committed once it passes re-validation. This is exactly the kind of detail researchers actually care about: not the throughput number itself, but whether the scheduling algorithm behind that number can be proven equivalent in correctness to some form of serial execution.
That pace has only picked up over the past two years. The 2025 AFT (Advances in Financial Technologies) conference accepted research on efficient parallel execution of blockchain transactions; the same year saw new proposals like NEMO, optimized for high-contention workloads, along with ParallelEVM, research focused on operation-level concurrency published at EuroSys 2025. This shows that "is optimistic parallel EVM correct, how correct, and where are its boundaries" has become an academic subfield with a steady stream of published papers, rather than a promotional battlefield where a handful of chains talk past each other. Articles 22 and 23 in Series B, covering serializability equivalence and sketches of correctness proofs, along with Series G's security audit checklist, are the entry points prepared for this audience.
Three paths, one map
The three audiences ask different questions, but they share the same underlying mechanism — which is exactly why it's worth stringing them together into one series rather than splitting them into three unrelated documents. The table below is a rough guide for jumping to what you need:
| Reader profile | Primary concern | Series entry point |
|---|---|---|
| Contract developers | Will my contract's behavior change, and does my code need to change | Series B (12–28), articles 96–98 |
| Client/protocol engineers | How to implement scheduling, locking, and the state tree; where the performance bottlenecks are | Series C (29–48), Series D (49–64) |
| Researchers | Where the correctness boundaries lie, and how this compares to models like Block-STM | Articles 22–23 in Series B, Series G (89–94) |
If you just want a quick overview, Series A itself (articles 1 through 10) already covers the problem definition, the full landscape of scaling approaches, the trade-offs between the three parallel execution routes, and a unified way of measuring performance metrics — reading those ten articles should be enough to figure out which series to dive into next. Series E (consensus and execution coordination) and Series F (side-by-side comparisons and benchmarks) are shared knowledge that all three audiences will draw on: the former is about how parallel execution and the consensus layer coordinate without dragging each other down, and the latter provides the methodology for judging whether any given "TPS number" is credible.
Parallel EVM isn't a technology with a single answer — it's a design space that requires trading off developer experience, engineering complexity, and theoretical correctness against each other. The articles that follow will unfold along these three paths one at a time, not aiming for every piece to cover everything, but aiming for every piece to land with the right audience.