Parallel Execution

What Is Parallel Execution?

Parallel execution is a blockchain design approach where multiple transactions are processed simultaneously across different CPU threads, rather than being handled one after another in a single thread. In traditional sequential execution (the model used by Ethereum's EVM), each transaction must fully complete and update the global state before the next one begins. This creates a bottleneck: no matter how powerful the hardware, only one transaction runs at any given moment.

Parallel execution removes that bottleneck by identifying transactions that touch independent pieces of state and running them concurrently. Two users transferring tokens between entirely different accounts, for example, have no reason to wait for each other. A parallel execution engine recognizes this independence and processes both at the same time, reducing the time needed to execute a full block.

Research by the Sei team analyzing over 2.4 million Ethereum transactions found that roughly 65% of transactions on Ethereum are parallelizable: they touch independent state and could execute concurrently. The remaining 35% involve conflicts (such as multiple transactions modifying the same contract storage slot) and must be serialized. This ratio illustrates both the opportunity and the challenge of parallel execution.

How It Works

The fundamental problem that parallel execution engines solve is determining which transactions are independent. Two transactions conflict when one writes to a state location that the other reads or writes. When conflicts exist, the execution order matters: processing them in a different sequence could produce different results. The consensus mechanism defines a canonical transaction order within each block, and the parallel execution engine must produce results identical to executing that order sequentially.

Blockchains have adopted two primary strategies to achieve this: pessimistic concurrency control and optimistic concurrency control.

Pessimistic Concurrency Control

In the pessimistic approach, transactions declare which state they will read and write before execution begins. The execution engine builds a dependency graph from these declarations, identifies non-conflicting transactions, and schedules them across threads. Transactions that access the same state are serialized automatically.

Solana's Sealevel runtime pioneered this approach. Every Solana transaction must specify the accounts it will access and whether each access is a read or a write. The runtime applies account-level locking: multiple transactions can read the same account concurrently, but any transaction that writes to an account obtains an exclusive lock. Solana uses a Prio-Graph scheduling algorithm with a look-ahead window to optimize execution order under high contention.

Sui takes a related but distinct approach using an object-centric data model. Every asset (coin, NFT, contract resource) is an independent object with a unique ID. Transactions touching only "owned" objects (belonging to a single user) bypass consensus entirely and finalize via Byzantine Consistent Broadcast. Transactions touching "shared" objects go through the Mysticeti consensus engine, a DAG-based BFT protocol that achieves finality in roughly 0.5 seconds.

The pessimistic approach avoids wasted work: no transaction executes speculatively. However, it requires developers to declare state access upfront, which adds complexity and breaks compatibility with the EVM programming model, where contracts can dynamically access arbitrary storage slots during execution.

Optimistic Concurrency Control

The optimistic approach executes all transactions speculatively in parallel, assuming they will not conflict. Each transaction records its read-set and write-set during execution. After completion, a validation pass checks whether any values a transaction read were modified by a concurrent transaction. If a conflict is detected, the affected transaction is rolled back and re-executed with the correct data.

Aptos uses Block-STM (Software Transactional Memory), the most well-characterized optimistic parallel execution algorithm in production. Block-STM uses multi-version concurrency control (MVCC) to store every write with version information. When validation detects a conflict, it marks the affected storage locations as "ESTIMATION," causing subsequent transactions that depend on those locations to wait rather than execute with stale data. This reduces the number of wasted re-execution cycles.

Monad applies a similar optimistic strategy while maintaining full bytecode-level EVM compatibility: Solidity contracts deploy without modification, and standard tools like Hardhat and Foundry work unchanged. Monad adds static code analysis to predict dependencies before execution, reducing conflict rates. Its architecture also decouples consensus from execution (deferred execution), allowing block ordering and transaction processing to happen in parallel.

The optimistic approach preserves developer ergonomics and EVM compatibility, but wastes computational work when conflicts occur. Performance degrades under high contention as more transactions require re-execution.

The Conflict Detection Pipeline

Regardless of approach, every parallel execution engine follows a similar pipeline:

1. Transaction scheduling: assign transactions to threads based on declared dependencies (pessimistic) or arbitrarily (optimistic)
2. Parallel execution: each thread processes its assigned transactions, recording all state reads and writes
3. Conflict detection: compare read-sets and write-sets across transactions to identify dependencies
4. Resolution: re-execute conflicting transactions in the correct order, or serialize them (pessimistic systems handle this at scheduling time)
5. Commitment: once all conflicts are resolved, commit the final state atomically

// Simplified optimistic parallel execution pseudocode
function executeBlock(transactions) {
  // Phase 1: speculative parallel execution
  results = parallelMap(transactions, tx => {
    readSet = {}
    writeSet = {}
    result = execute(tx, { onRead: (k,v) => readSet[k] = v,
                           onWrite: (k,v) => writeSet[k] = v })
    return { result, readSet, writeSet }
  })

  // Phase 2: conflict detection and re-execution
  for (i = 0; i < results.length; i++) {
    for (j = 0; j < i; j++) {
      if (overlaps(results[j].writeSet, results[i].readSet)) {
        // Conflict: re-execute transaction i with updated state
        results[i] = reExecute(transactions[i], committedState)
      }
    }
  }

  // Phase 3: atomic commit
  commitAll(results)
}

Major Implementations

Solana (Sealevel)

Solana's Sealevel runtime was the first widely deployed parallel smart contract engine. Programs on Solana are stateless: they contain only code and cannot hold mutable state. All mutable state lives in accounts, which programs can modify only if they own that account. This separation enables the runtime to analyze dependencies at the account level.

Solana's current implementation uses multiple threads (typically four for non-vote transactions and two for vote transactions). The Firedancer validator client, now running on roughly 26% of mainnet validators, demonstrated over one million TPS in controlled testing. Real-world mainnet throughput runs at 2,000 to 6,000 non-vote TPS, with block times of approximately 400 milliseconds.

Aptos (Block-STM)

Aptos achieves over 160,000 non-trivial Move transactions per second using Block-STM. The algorithm delivers a 16x speedup over sequential execution at low contention and an 8x speedup even at high contention (measured with 32 threads and 10,000 transactions per block). Block finality is roughly 0.9 seconds.

A key insight of Block-STM is that the predetermined block order (set by consensus) is a performance advantage, not a constraint. Conflict resolution has a clear ordering, eliminating the expensive negotiation required in general-purpose concurrent systems.

Monad (Parallel EVM)

Monad launched its mainnet in November 2025 as the first production parallel EVM Layer 1. Its architecture combines five components: MonadBFT consensus (blocks every 500 milliseconds, single-slot finality), deferred execution, optimistic parallel processing, a custom storage layer (MonadDB) optimized for asynchronous I/O, and RaptorCast for block propagation. Devnet testing reached 10,000 TPS.

Sei (Optimistic Parallel EVM)

Sei transitioned from pessimistic to optimistic parallelization with its v2 upgrade, applying conflict detection and re-execution across all transaction types. The network achieves 12,500 TPS with 390-millisecond finality. Sei's upcoming Giga upgrade introduces Autobahn, a multi-proposer consensus protocol, along with ML-based conflict prediction and a four-stage execution pipeline targeting 5 gigagas throughput.

Throughput Comparison

Use Cases

Parallel execution unlocks application categories that sequential blockchains struggle to support:

• High-frequency decentralized exchanges: order book DEXes require processing thousands of order placements, cancellations, and matches per second. Sequential execution creates latency that market makers cannot tolerate, pushing activity to centralized venues. Parallel execution reduces block-level latency enough to make on-chain order books viable.
• Real-time payments: payment networks need to handle large bursts of independent transfers without congestion. Since most payments involve different sender-receiver pairs, they are naturally parallelizable. Higher throughput from parallel execution keeps gas fees low even during demand spikes.
• Gaming and social applications: these generate high volumes of small, independent state changes (player movements, social interactions, in-game transactions) that benefit from concurrent processing.
• DeFi composability: complex transactions that interact with multiple smart contracts (flash loan arbitrage, multi-hop swaps) can execute alongside unrelated transactions without blocking them.

Why It Matters

Parallel execution directly addresses one side of the blockchain trilemma: scalability. By using available hardware more efficiently, parallel execution increases throughput without requiring larger blocks (which increase storage and bandwidth requirements) or sacrificing decentralization.

For payment infrastructure, throughput is a practical constraint. A payment network that processes 15 transactions per second (Ethereum's base layer) cannot compete with traditional rails that handle thousands per second. Parallel execution brings on-chain throughput into the range needed for real-world payment volumes, complementing Layer 2 scaling solutions that move transactions off the base chain entirely.

Bitcoin's base layer processes transactions sequentially, which is one reason Layer 2 solutions like Spark and the Lightning Network exist: they handle high-frequency payments off-chain while settling to the secure base layer. The parallel execution trend on other chains represents an alternative approach to the same scalability challenge, trading the simplicity of sequential processing for raw throughput.

Risks and Considerations

State Contention

Parallel execution delivers its best performance when transactions touch independent state. Popular smart contracts that many users interact with simultaneously (such as a DEX liquidity pool or a lending protocol) create contention hotspots. When many transactions compete for the same storage slots, optimistic engines waste work on re-execution, and pessimistic engines serialize those transactions anyway. The theoretical throughput advantage shrinks under high contention.

Determinism Guarantees

A parallel execution engine must produce results identical to sequential execution in the canonical order. Any bug in conflict detection, scheduling, or re-execution could cause nodes to disagree on state, breaking consensus. These engines are significantly more complex than sequential processors, expanding the attack surface for implementation bugs.

Developer Complexity

Pessimistic systems like Solana require developers to declare all state access upfront, which adds friction and makes certain dynamic access patterns (such as contracts that conditionally call other contracts) difficult or impossible. Optimistic systems preserve developer ergonomics but make performance harder to reason about: a contract that works well at low usage may degrade unpredictably when contention increases.

Hardware Requirements

Parallel execution benefits scale with available CPU cores and memory bandwidth. This can raise validator hardware requirements, potentially reducing the number of entities that can run full nodes and impacting decentralization. MegaETH, for example, requires its sequencer node to have 100 cores, up to 4 TB of RAM, and a 10 Gbps network connection.

Modular Alternatives

Modular blockchain architectures take a different approach to scaling: instead of parallelizing execution within a single chain, they separate execution, data availability, and consensus into specialized layers. Rollups, for instance, execute transactions off the base chain and post compressed results back for verification. Both approaches can coexist: some rollups (like MegaETH) use parallel execution within their execution layer while relying on Ethereum for data availability and settlement.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.