Who Should Read About Parallel EVM: Three Paths for Contract Developers, Client Engineers, and Researchers

"Parallel EVM" means different questions to different readers. A Solidity developer worries first whether contract behavior will change silently. Client and protocol engineers care how schedulers, conflict detection, and state trees saturate cores. Researchers ask whether optimistic parallelism has checkable correctness bounds, or whether marketing is wearing database vocabulary. All three concerns are fair; mixing them usually produces a discussion too vague to satisfy anyone.

So it helps to split the audience — not to raise a gate, but to admit that parallel execution spans application, systems, and theory. One article that tries to please all three often deepens none of them. What EVM Compatibility Actually Means covered the engineering meaning of compatibility; this piece turns "what next" into three executable paths that link only to articles already published here, not to fictional future installments, and not to "Series Letter, article N" citations that cannot be opened.

Path 1: Contract developers — will behavior change, and must code change

For contract authors, parallelism does not change Solidity syntax; it changes conflict and retry experience at execution time. Under a single-threaded EVM, in-block transactions are interpreted in order and final state tracks that order. Under optimistic parallelism, a batch may speculate concurrently, then accept or roll back in validation. Low-frequency contracts with little shared state usually see a transparent process. AMMs, lending protocols, and NFT mints that repeatedly touch the same storage slots see higher conflict rates — slower confirmation, more failed retries, and greater fragility for logic that assumes implicit same-block ordering.

Suggested order:

1. What EVM Compatibility Actually Means — confirm which bytecode, precompile, JSON-RPC, and tooling alignments matter for migration.
2. Optimistic Concurrency Control (OCC) Primer — build the "execute, validate, retry on conflict" intuition, and why final state should still match a serial order.
3. Conflict Hotspots and Workloads — see why AMM / lending / mint traffic hurts throughput, and how storage layout drives conflict rates.
4. Optional depth: Bitroot Parallelised EVM Explained, Multi-Engine Parallel Execution Design — how production-oriented engines group work and detect conflicts, without requiring every systems detail up front.

Practical takeaway: audit hot slots and global counters first; split state by user or pool when possible; do not encode "someone else executed first in this block" as an implicit invariant. Most contracts need not rewrite business logic for parallelism, but high-conflict contracts almost always need storage and interaction designs that are conflict-tolerant. If your job is mainly moving an existing Solidity repo to a new chain, the four-layer compatibility checklist usually reduces launch risk more than reading execution-engine source.

Path 2: Client / protocol engineers — how scheduling, state, and consensus cohere

These readers already know node internals. Their questions are harder: how dependency graphs are built, whether read/write sets are account- or slot-grained, how engine pools scale, how conflict re-execution avoids livelock, and how consensus proposal and execution pipelines decouple without blocking each other. Historical context for the bottleneck is in The EVM Single-Thread Bottleneck; the design fork is in Three Approaches to Parallel Execution.

Suggested order:

1. The EVM Single-Thread Bottleneck — locate "slow" in serial interpretation, not only in consensus interval.
2. A Map of Blockchain Scaling — place parallel execution among rollups, sharding, and modular stacks so execution-layer wins are not mistaken for the whole scaling answer.
3. Three Approaches to Parallel Execution and OCC Primer — see where deterministic declaration, object models, and optimistic paths put complexity.
4. Pipeline BFT and Multi-Engine Synergy, Multi-Engine Parallel Execution Design — compare one concrete consensus–execution decoupling and multi-engine design to see tradeoffs land in code-shaped choices.
5. Before trusting numbers: Performance Metrics Glossary; when weighing hardware and set size: Decentralization vs Performance.
6. Calibrate expectations on real load: Conflict Hotspots and Workloads.

Practical takeaway: split "throughput" into scheduling efficiency, conflict re-execution cost, state read/write amplification, and consensus messaging cost, and measure each. Benchmarks that quote ideal-load peaks without conflict distribution and hardware disclosure have limited value for client optimization. In implementation, make conflict definitions, re-execution policy, and observability metrics configurable and exportable — otherwise production only shows "it got slower," not why.

Path 3: Researchers — correctness bounds, model comparison, falsifiable claims

Researchers rarely need another product brief. They need falsifiable questions: are committed results serializable with respect to block order? How do approximate read/write sets (account vs slot) affect safety and performance? Under which conflict graphs does speedup collapse toward 1? Against Block-STM-like schemes, deterministic parallelism, and object models, what are the respective assumptions?

Suggested order:

1. Three Approaches to Parallel Execution — fix the comparison frame before diving into one project's implementation.
2. OCC Primer — map blockchain execution back onto classic database concurrency vocabulary (read/write sets, validation, re-execution).
3. Conflict Hotspots and Workloads — build conflict-graph intuition from real contract shapes, not transfer-only benchmarks.
4. Performance Metrics Glossary — unify TPS / latency / finality / conflict-rate definitions so paper-style and marketing-style numbers are not mixed.
5. Decentralization vs Performance — put "faster" back into observable dimensions such as validator requirements, geography, and client diversity.
6. Optional system context: A Map of Blockchain Scaling, Positioning Bitroot, Pipeline BFT and Multi-Engine Synergy.

Practical takeaway: demand that any performance or correctness claim attach a workload description, a conflict definition, and a failure/re-execution policy. "Parallel EVM is faster" without those attachments has near-zero research value. Writing claims as reproducible experiment designs (hardware, client, transaction generator, conflict injection) gets closer to a shared language between research and engineering than arguing over adjectives.

Comparison table: jump by role

For a shared foundation, follow the site reading chain: positioning → compatibility → this guide → metrics glossary → decentralization tension → conflict hotspots. The three role paths are forks off that spine, not a second table of contents that cannot be opened. After the shared foundation, diving by the table above usually costs less time than trying to read every long technical post from the start.

Further reading

• Previous: What EVM Compatibility Actually Means: Bytecode, Precompiles, JSON-RPC, and Tooling
• Next: A Glossary of Performance Metrics: TPS, BPS, Confirmation Latency, Finality, and Conflict Rate