Home / News / technologie

Parallel EVM Execution: Architecture and Real-World Throughput

NOUTITA NEWSROOM·15 OCT. 2026 À 20:01 (UTC+1)·6 MIN READ

PARALLEL EVM & ZK

TECHNOLOGIE

noutita.com#TECHNOLOGIE

In Brief (TL;DR)

An in-depth guide to parallelizing Ethereum's EVM: theoretical foundations, architectural patterns, and practical steps to explore real-world throughput. We weigh competing viewpoints, examine data availability via EIP-4844 blob infrastructure, and propose a hands-on tutorial for building and evaluating a parallel execution workflow using current research and open-source prototypes.

# Parallel EVM Execution: Architecture and Real-World Throughput

In a web3 era where throughput and data availability are the gating factors for scalable rollups, Parallel EVM Execution is increasingly invoked as a design point for unlocking higher transaction throughput without sacrificing on-chain security. This guide pairs theory with practice, anchored in the latest research and active open-source work, to help engineers reason about architecture, limits, and real-world outcomes. We cite primary sources from arXiv papers, GitHub implementations, and Ethereum community documentation to present a nuanced view rather than a single promotional narrative.

Note on current state: Proto-Danksharding (EIP-4844) introduces blob data for cheaper Rollup data posting, a critical enabler for throughput growth. The blob data has a finite lifetime in blocks and is subject to a blob market mechanism that prices data availability. See EIP-4844 and Ethereum data-availability primers for foundational details.

In brief terms, parallel EVM aims to execute more transactions in a block by exploiting independent state accesses and delaying or reordering conflicting operations. Realistic gain depends on workload characteristics, storage architecture, and how aggressively a system can detect and resolve conflicts without breaking determinism. The literature ranges from optimistic, near-linear throughputs on synthetic traces to more modest, workload-bound gains on real-chain workloads.

Sources anchor the discussion to three layers: (i) protocol/data-layer foundations (blob transactions, data availability, and pricing), (ii) execution-layer research (conflict-aware parallelism, scheduling, and Block-STM-inspired approaches), and (iii) real-world prototypes and benchmarks. See EIP-4844 blob transactions and data availability discussions, architecture papers on parallel EVM execution, and several open-source experiments.

Core concept: data availability blobs post L2 transaction data cheaply to L1 so that rollups can rely on Ethereum’s security while reducing data posting costs. This is the architectural beef behind Proto-Danksharding (EIP-4844) and its related discussions. (eips.ethereum.org)

Throughput thesis: parallel execution can yield substantial improvements under the right workload, but real-world throughput depends on state access patterns, I/O bottlenecks, and scheduling. EuroSys 2025 Parallel-EVM studies report speedups (e.g., ~8.8x under certain traces), illustrating both the potential and the limits of practical parallelization. (yajin.org)

Prototypes and R&D: active experiments range from Ethpar and Concerto-style models to modern peer-reviewed proposals (PEVM, Block-STM-inspired scheduling, and multi-version memory approaches). These works provide blueprints and testbeds for evaluating parallelism outside of a pure simulator. (ethpar.ai)

In this guide you’ll find a structured breakdown that starts with the theory, then moves to a practical, tutorial-style path that emphasizes security, reproducibility, and measurement. The emphasis is on critical thinking and editorial balance: conflicting viewpoints are presented with references, so readers can compare claims about feasibility, scalability, and complexity.

1. Theoretical Foundations & Invariants

Key objective: enable higher throughput by executing independent transactions in parallel while guaranteeing deterministic, correct block results. This requires precise definitions of independence, conflicts, and commit/abort behavior. The literature distinguishes between purely speculative concurrency and robust, conflict-aware scheduling that can deliver real throughput gains on real workloads. See parallel-EVM research and conflict-specification work for concrete models. (arxiv.org)

Data-layer context: blob data is posted to L1 as a cheaper data channel for Rollups, and its availability is verified via data sampling (DAS). Blob data has a limited lifetime in blocks, and blob pricing markets influence Rollup data-posting strategies. This data-layer design is central to the throughput story because it decouples data availability from data replication costs. (eips.ethereum.org)

Execution-layer architecture: multiple design approaches exist to achieve parallelism. Some proposals emphasize scheduling and transaction-level conflict management (Block-STM-inspired strategies), while others explore per-transaction or per-operation concurrency with speculative retries. The state transition and Merkle-tree interactions create subtle dependencies that complicate naive parallelization. See discussions on Parallel-EVM scheduling and Conflict Specifications, as well as Block-STM-inspired architectures. (arxiv.org)

Conflict semantics and invariants: the fundamental bottlenecks in parallelizing an EVM are read/write dependencies on account storage, code, and storage slots. A comprehensive study of conflicts and pre-execution hints shows how negotiation around shared state can yield speedups, but also how contention can throttle throughput. The consensus is not “parallel at all costs” but “parallel where safe, with abort/retry where needed.” (yajin.org)

Realism vs idealism: there is a spectrum of claims—from optimistic models of near-linear speedups to empirical measurements showing significant bottlenecks at I/O and storage layers. For readers, the takeaway is that throughput gains are workload-dependent and hardware-friendly but must be tested under realistic traces. See EuroSys results and related analyses for a balanced view. (yajin.org)

The following subtopics anchor the discussion with concrete sources.

Blob economics and data availability dynamics. Proto-Danksharding (EIP-4844) creates blob data with dedicated pricing and a defined lifetime, designed to scale data posting for Rollups while preserving Ethereum security semantics. The EIP page and Ethereum documentation describe the purpose and mechanics of blob data, including the data-availability sampling model and blob gas pricing. (eips.ethereum.org)

Throughput research with parallelization. Parallel-EVM studies show that substantial speedups are possible, but results vary by workload. A notable EuroSys 2025 paper reports a speedup close to 9x on certain synthetic traces, illustrating the potential and the boundaries of current approaches. (yajin.org)

Practical prototypes and architectures. A range of practical experiments exists, including Ethpar-style parallelism demonstrations, Concerto-style parallel EVM proposals, and GitHub-provided engines aiming to batch and schedule non-conflicting transactions. These sources provide real-world scaffolding for learning-by-doing. (ethpar.ai)

For readers who want a deeper dive into concrete architectures, there are several executable lines of inquiry:

Block-STM-inspired scheduling for EVM execution with multi-version memory. See AERE Network’s whitepaper for a detailed look at scheduling and parallel commit semantics, including the practical challenges of proving block correctness against a sequential baseline. (aere.network)

Per-operation conflict resolution and parallel transaction batching. Papers on operation-level concurrency and conflict specifications illustrate how parallel EVM ideas can be formalized and benchmarked against traditional sequential execution. (yajin.org)

Two credible, opposing perspectives surface in the literature:

Perspective A (feasible and scalable under workloads with low inter-transaction dependencies): empirical results show meaningful speedups when conflicts are minimized and scheduling can exploit independent state accesses. Examples include Parallel-EVM work with reported speedups on designed workloads. (yajin.org)

Perspective B (bottlenecks remain formidable in real networks due to storage I/O and cross-contract dependencies): some analyses emphasize that the EVM’s call/return semantics and storage model impose non-trivial constraints, capping achievable throughput without architectural changes to the state model or data layout. See conflict-specification and general parallel-EVM discussions as evidence of nuanced, not universal, gains. (arxiv.org)

Real-world context and related literature also point to adjacent approaches—some of which aim to complement parallel EVM with other advancements (e.g., ZK-based verifications, different EVM implementations, or alternative scheduling mechanisms). The landscape is broad and the conclusions are not monolithic. (github.com)

2. Step-by-Step Tutorial (Practice)

A. Prerequisites & Security

Prerequisites (conceptual):

A solid understanding of the EVM execution model, gas accounting, and the state trie (Merkle-Patricia Trie). The Ethereum Yellow Paper and the Ethereum Foundation’s EVM documentation provide baseline definitions of execution semantics and state transitions. (ethereum.org)

A working knowledge of concurrency concepts, especially conflict detection, optimistic/concurrent execution, and retry semantics. Contemporary papers on Parallel-EVM scheduling and conflict specification illustrate the kinds of invariants you’ll need to formalize. (arxiv.org)

Familiarity with data availability concepts, blob transactions, and blob gas markets as described in EIP-4844 and accompanying Ethereum docs. (eips.ethereum.org)

Security considerations (non-negotiable):

Determinism must be preserved: while you may execute in parallel, the final block commitment must be equivalent to some sequential order of the same transactions (for each non-conflicting batch). If a conflict is detected, you must abort/retry in a well-defined way. This is a central tenet in Block-STM and related scheduling models. (aere.network)

Correctness of the post-execution state is essential. Work with a testing harness that replays transactions against a reference sequential executor to spot divergence. See parallel-EVM benchmarking work and practice guidelines for how to structure these comparisons. (yajin.org)

Data availability handling must respect the blob lifecycle and the DAS verification model. This is critical to maintain Rollup security in blob-based data posting. (ethereum.org)

Tooling and references (starter kit):

GitHub prototypes and academic work provide concrete implementations to study. For example, Othentic-Labs’ Parallel-EVM project shows a practical approach to batching transactions based on independent state accesses, which is a good starting point for learning the patterns. (github.com)

Risechain’s PEVM repository describes a parallel execution engine; reviewing their architecture helps in understanding how batches are formed and how state is shared across workers. (github.com)

Ethpar/Concerto-style explorations and related papers provide additional perspectives on parallel transaction execution in EVM-compatible environments. (ethpar.ai)

B. Executing the Steps

Step 1: Establish the baseline sequential executor

Start with a trusted sequential EVM client and a set of test blocks (e.g., from a public testnet or a synthetic workload). The goal is to measure baseline execution time, gas usage, and correctness metrics. This is essential to quantify any parallelism gains later. Use standard EVM tooling and tracing to capture per-transaction state reads/writes. See general EVM docs for your starting point. (ethereum.org)

Step 2: Implement a conflict model and a batcher

Define the conflict graph: for each pending transaction, record the accounts/storage slots it reads and writes. Transactions with disjoint read/write sets can potentially be executed in parallel. If there is an overlap, you must mark a potential conflict and place these transactions into separate batches or force sequential execution. This approach is at the core of operation-level concurrency work and conflict-specification studies. (arxiv.org)

Build a batcher that groups non-conflicting transactions into execution baskets. Real-world prototypes (e.g., Othentic-Labs’ work) illustrate how to derive batches from mempool analyses and state access patterns. Start with a conservative 2–4 batch parallelism and scale up gradually while monitoring correctness. (github.com)

Step 3: Design the worker pool and memory model

The execution engine will run in parallel workers that fetch a batch, perform EVM execution, and produce a per-batch post-state. A Block-STM-inspired approach uses a multi-version memory model to tolerate concurrent reads/writes, with careful commit/abort semantics if conflicts are detected later. See AERE’s whitepaper for concrete architecture implications of Block-STM-style scheduling. (aere.network)

Step 4: Integrate storage and I/O with parallel I/O optimizations

One of the biggest bottlenecks in practice is state access and I/O rather than pure CPU compute. Research on parallel I/O, prefetching BAL-like data, and asynchronous storage can dramatically improve throughput when combined with parallel EVM execution. Recent analyses show substantial throughput gains when I/O is decoupled from execution and prefetching is effectively utilized. (ethresear.ch)

Step 5: Validate correctness with reference traces

Re-execute the same transactions in the original sequential order and compare the final state, receipts, and Bloom filters to ensure bit-identical results. This mirrors how research papers evaluate parallel EVM proposals against sequential baselines. (yajin.org)

Step 6: Measure performance under realistic traces

Use publicly reported traces or synthetic workloads to measure throughput, latency, and abort/retry rates across varying batch sizes and worker counts. A key takeaway from EuroSys 2025 is that speedups are highly workload-dependent; some traces exhibit significant gains, while others expose bottlenecks that require architectural refinement. (yajin.org)

Step 7: Compare with blob-data-enabled scaling paths

While parallel execution focuses on the execution engine, blob data (Proto-Danksharding) handles data availability economics for L2 data posted to L1. Consider how blob markets influence Rollup posting rates and cost, and how your architecture would interact with blob-based postings in practice. (eips.ethereum.org)

Step 8: Document learnings and next steps

Publish measured results, including both the best-case throughput and the worst-case scenarios, and discuss how further optimizations (e.g., enhanced conflict detection, smarter batching, or alternative EVM implementations) could push throughput further. The literature consistently emphasizes that parallel EVM is not a silver bullet and must be tuned to workloads and data access patterns. (arxiv.org)

Block quotes from the literature help crystallize the debate:

“Parallel transaction execution in the EVM can yield significant throughput improvements, but the benefits strongly depend on the independence of state accesses and the effectiveness of conflict resolution.” — summarizing the tension in parallel-EVM research and experiments. (yajin.org)

“Blob data economics and a dedicated data availability channel are essential for scalable rollup data posting, and the blob lifecycle interacts with throughput through pricing and data availability proofs.” — from EIP-4844 and related documentation. (eips.ethereum.org)

Practical notes and exemplars you can study as you implement:

Ethpar/Concerto-style parallel EVM prototypes and working papers provide concrete design ideas for partitioning work and managing state dependencies. They’re useful for sketches, not final production. (ethpar.ai)

Othentic-Labs’ Parallel-EVM project demonstrates an operational batcher that tries to maximize parallelizable execution by inspecting mempool state accesses. This is a good reference point for a first implementation. (github.com)

Risechain’s PEVM and related discussions (GitHub) show additional architectural patterns and tradeoffs in parallel EVM engines. (github.com)

AERE Network’s whitepaper provides an architecture-level view of how Block-STM-like scheduling can be integrated with an EVM, including the notion of near-linear throughput with appropriate workers and scheduling proofs. (aere.network)

Real-world throughput reality check (without assumptions):

A key empirical result from the EuroSys 2025 ParallelEVM line of work reports an average speedup around 8.8x on certain workloads, illustrating the potential magnitude of gains but also implying that gains are not universal. This is a crucial data point for practitioners to avoid over-optimistic expectations. (yajin.org)

Related work shows a spectrum of outcomes from 1.75x to ~1.33x speedups with certain conflict-resolution approaches, highlighting how small architectural choices can dramatically shift results. These findings complement the more optimistic throughput narratives and remind readers that practical deployment must be data-driven. (arxiv.org)

What this means for developers and researchers

If you’re building a new EVM-compatible chain or a rollup-friendly client, parallel EVM concepts offer a path to scaling, but you must implement robust conflict detection and abort/retry semantics to preserve determinism. The literature consistently emphasizes the need for careful scheduling and verification against a known sequential baseline. (yajin.org)

If you’re evaluating Ethereum layer-2s and blob data posting, you should consider how blob markets and DAS verification influence your data availability strategy and fee modeling. The blob market design is a critical input to throughput economics for Layer 2 data. (eips.ethereum.org)

If you’re a researcher, you may explore hybrid designs that combine data-layer blob availability with execution-layer parallelism, or you may test alternative EVM implementations (including high-performance engines) to assess their respective throughput curves under realistic traces. There are multiple active pathways and many credible viewpoints in the literature. (github.com)

Sourcing notes and navigating the literature

Blob data and Proto-Danksharding: EIP-4844 pages, Ethereum.org data-availability docs, and partner analyses. These sources provide the canonical description of blob transactions, data availability proofs, and the blob lifecycle. (eips.ethereum.org)

Parallel-EVM architecture and benchmarks: EuroSys 2025 ParallelEVM papers, conflict-specification literature, and Block-STM-oriented discussions. These give both the construction of the parallel engine and empirical results. (yajin.org)

Prototypes and open-source experiments: Ethpar/Concerto, PEVM repos, and other GitHub projects offer practical starting points for experimentation and benchmarking. (ethpar.ai)

Related data and community benchmarks: L2Beat’s Parallel project page and Blob Explorer guides offer contextual, widely-used vantage points for understanding how parallel EVM ideas fit into the broader Layer 2 landscape. (l2beat.com)

Meta notes on the date and state of the field

Proto-Danksharding and blob data became a meaningful design point around 2023–2024, with Ethereum’s mainnet and community documents noting the blob data mechanism and its economics. The literature captures this transition and its ongoing evolution into 2025–2026. For instance, research papers discussing EIP-4844 economics and blob markets reference events in 2024, including the March 2024 implementation window for EIP-4844 data availability dynamics. (arxiv.org)

As with any rapidly evolving area, experiments and results are workload-sensitive and device- and dataset-dependent. Readers should treat throughput claims as conditional on workload type and system design, and should rely on published benchmarks (like EuroSys) to ground expectations. (yajin.org)

Bottom line: Parallel EVM is a fertile area with credible progress and credible caveats. It has moved from a theoretical idea to a set of playable architectures and experimental platforms. The data-layer (blob transactions) and the execution-layer (conflict-aware parallelism) are both essential to realize any practical, scalable throughput uplift, and the interplay between these layers remains a central research and engineering frontier. The cited papers, GitHub projects, and Ethereum docs provide a well-lit path for practitioners who want to explore, measure, and contribute to this ongoing evolution.

Citations and reference notes (selected):

EIP-4844: Proto-Danksharding and blob transactions; data availability and blob gas markets. (eips.ethereum.org)

Ethereum data-availability overview and DAS verification. (ethereum.org)

Danksharding roadmap and blob data benefits for rollups. (ethereum.org)

Blob data lifetime in blocks (~18 days) and related data availability notes. (ethereum.org)

Parallel-EVM architecture, scheduling, and empirical benchmarks (EuroSys 2025). (yajin.org)

Conflict-specification and Block-STM-like scheduling in EVM. (arxiv.org)

AERE Network whitepaper: Block-STM-style parallel execution. (aere.network)

Othentic-Labs/Parallel-EVM (GitHub). (github.com)

Risechain/PEVM (GitHub). (github.com)

Ethpar/Concerto-style parallel EVM concepts and demonstrations. (ethpar.ai)

L2Beat Parallel project overview. (l2beat.com)

General EVM theory and execution model (Yellow Paper and Ethereum docs). (ethereum.org)

Related data and media exploring blob-based data explorers and blob data economics (Blob Explorer guides and related analyses). (ethexplorer.org)

Meta: This piece is written for a US market audience for NOUTITA NEWSROOM, with careful attention to current literature, open-source experiments, and the practical realities of throughput in parallel EVM contexts. It aims to present a balanced view, acknowledging both the potential gains and the substantial engineering challenges that remain. For readers seeking deeper dives, the cited sources provide a helpful starting point for further reading and experimental replication.