Parallel Execution

The core mechanism that enables parallelism. Before execution, transactions are analyzed to identify dependencies. Key methods include:

• Read/Write Sets: Tracking which accounts or storage slots a transaction accesses.
• Software Transactional Memory (STM): Optimistically executing transactions and rolling back those with conflicts.
• Deterministic Scheduling: Using pre-defined rules to order transactions that touch shared state.

How a blockchain manages shared data dictates its parallelization strategy.

• Shared State (e.g., Solana): All programs share a global state; the runtime must dynamically detect conflicts during execution.
• Partitioned State (e.g., Monad, Sui): State is sharded or owned by specific accounts, allowing transactions on independent partitions to run in parallel without conflict checks. This is often more efficient.

Different implementations of the parallel execution concept.

• Optimistic Parallelism: Execute all transactions in parallel, then validate and re-execute only those with conflicts (used by Aptos, Sui).
• Deterministic Parallelism: Use static analysis or programmer annotations to schedule non-conflicting transactions in advance (a goal of Monad and Fuel).
• Multi-threaded EVMs: Layer 2 solutions like Polygon zkEVM or clients like Reth that parallelize execution within a single block.

The theoretical speedup is bounded by Amdahl's Law. Maximum throughput depends on:

• Conflict Rate: The percentage of transactions that contend for the same state. Low conflict = high parallelism.
• Scheduler Efficiency: Overhead of the conflict detection and scheduling algorithm.
• Hardware: Leveraging multi-core processors and high-speed memory (RAM). Real-world gains can be 10-100x over sequential execution for suitable workloads.

Parallel execution changes how developers design smart contracts.

• Explicit Ownership: In systems like Sui, defining clear object ownership minimizes conflicts.
• Contention Awareness: Hot contracts (e.g., popular NFT mints, DEX pools) can become bottlenecks, limiting parallel gains.
• New Abstraction: May require new tools and languages to help developers reason about and optimize for parallelism.

Parallel execution interacts with other scaling solutions.

• Modular Blockchains: Separates execution from consensus and data availability; parallel execution is an execution layer optimization.
• Sharding: A data availability and consensus layer technique that partitions the network; can be combined with parallel execution for compound scaling.
• Asynchronous Execution: Transactions in one block do not wait for the previous block to finalize, further increasing throughput.

Parallel execution strategies are defined by how they handle state access and dependency detection:

• Optimistic (e.g., Solana, Aptos): Execute all in parallel, detect conflicts, re-execute failures.
• Deterministic (e.g., Sui, Fuel): Use a data model (objects/UTXOs) to pre-determine non-conflicting transactions.
• Sharded (e.g., Ethereum via rollups): Parallelism across independent sub-chains or rollups, not within a single state machine.

A state access conflict occurs when two transactions attempt to read from or write to the same storage location (e.g., an account balance) concurrently. This is the core challenge of parallel execution. Protocols handle this via:

• Optimistic Concurrency Control: Execute transactions in parallel first, then abort and re-execute conflicting ones in sequence (e.g., Solana, Aptos).
• Static Analysis: Require transactions to declare all state they will access upfront, enabling the scheduler to group non-conflicting transactions (e.g., Sui's Move).
• Sharding: Partition the state so transactions in different shards cannot conflict, allowing parallel execution across shards.

Blockchain consensus requires deterministic execution—the same inputs must always produce the same final state. Parallel execution complicates this because the final state must be independent of the order in which non-conflicting transactions were processed. Systems must ensure:

• Commitment Guarantees: The final, canonical state is identical across all validators.
• Sequential Equivalence: The parallel execution's outcome must be equivalent to some valid sequential ordering of the transactions.
• Front-running Mitigation: The chosen parallelization strategy can influence the effective transaction ordering, impacting MEV and fairness.

Parallel execution opens new denial-of-service (DoS) attack vectors that target system resources.

• Compute Saturation: An attacker can flood the network with many simple, non-conflicting transactions to saturate all parallel execution threads.
• Memory Bloat: Transactions that declare large, unnecessary state access sets can waste memory in schedulers using static analysis.
• Abort Attacks: In optimistic systems, malicious actors can craft transactions designed to cause frequent conflicts, forcing expensive re-execution and slowing the network. Robust gas metering and resource pricing for computation, memory, and bandwidth are critical defenses.

Developers must write contracts with parallelism in mind to maximize throughput and avoid pitfalls.

• Minimize Global State Contention: Design contracts to avoid frequent writes to widely shared state variables (e.g., a global counter).
• Use Object-Centric Models: Frameworks like Sui's Move encourage owning objects, which have clear ownership and fewer conflicts.
• Explicit Dependency Declaration: On chains like Aptos, properly declaring dependencies in Move allows the runtime to safely parallelize.
• Idempotency: Designing operations to be idempotent (safe to re-execute) is beneficial for optimistic systems that may abort and retry.

The performance benefits of parallel execution are heavily dependent on high-end, multi-core server hardware. This creates potential centralization pressures:

• Hardware Requirements: Validators need powerful CPUs with many cores and large, fast memory to achieve claimed throughput, raising entry costs.
• Optimization Advantage: Entities that can optimize software for specific hardware (e.g., custom schedulers, SIMD instructions) gain a competitive edge.
• Network Fragmentation: If hardware tiers diverge significantly, the network may effectively split into tiers with different performance characteristics, undermining decentralization guarantees.

Verifying the correctness of parallel execution is more complex than for sequential blocks.

• Proof Generation: Creating succinct validity proofs (e.g., zk-proofs) for a block of parallel transactions is computationally intensive, as the proof must account for all possible execution paths and conflicts.
• State Witness Size: Light clients or bridges needing to verify a specific transaction may have to download a larger Merkle proof (state witness) covering all potentially accessed state, not just a single path.
• Fraud Proof Complexity: In optimistic rollups or blockchains, constructing and verifying a fraud proof for an incorrect parallel execution is a more complex challenge than for a linear transaction history.

The traditional model where transactions are processed one at a time in a strict, linear order. This is the baseline against which parallel execution is measured.

• Deterministic Ordering: The state of the blockchain is updated serially, ensuring a single, unambiguous final state.
• Bottleneck: This model creates a fundamental throughput limit, as the network can only process as many transactions per second as a single CPU core can handle sequentially.
• Examples: Bitcoin and the Ethereum Virtual Machine (EVM) in its standard execution mode operate sequentially.

The specific way a transaction reads from and writes to the blockchain's shared state. This is the critical data dependency that determines if transactions can be parallelized.

• Conflict Detection: Parallel execution engines analyze these patterns to identify non-overlapping transactions that can be processed simultaneously.
• Read-Write Sets: Transactions often declare their intended access sets upfront, allowing the scheduler to group independent transactions.
• Hot Accounts: High-frequency accounts (e.g., major DEX pools or NFT marketplaces) become contention points that can limit parallelization gains.

A data structure used to model dependencies between transactions for parallel scheduling.

• Nodes as Transactions: Each transaction is a node in the graph.
• Edges as Dependencies: A directed edge from Transaction A to Transaction B indicates that B depends on the output of A (e.g., B reads a state that A writes).
• Scheduling: Transactions with no dependencies (no incoming edges) can be executed in parallel. This structure is fundamental to schedulers in Aptos' Block-STM and Sui's execution model.

A concurrency control mechanism that allows multiple threads to operate on shared memory simultaneously, providing the theoretical foundation for optimistic parallel execution.

• Optimistic Concurrency: Transactions execute in parallel without initial locks, assuming no conflicts.
• Validation & Abort: After execution, the system validates that no other transaction modified the shared data it accessed. If a conflict is detected, the transaction is aborted and re-executed.
• Implementation: Block-STM, used by Aptos and Sui, is a specialized STM optimized for blockchain workloads, where the entire block of transactions is known in advance.

A horizontal scaling technique that partitions the blockchain's state and transaction load across multiple, independent subsets called shards. It is a complementary scaling approach to parallel execution.

• Different Layer: Sharding scales at the consensus and data availability layer, creating multiple parallel chains.
• Combined Approach: A network can use both: parallel execution within a single shard and sharding across multiple chains. Ethereum's roadmap combines Ethereum L1 sharding with Layer 2 rollups that may use parallel execution (e.g., via EIP-648).
• Cross-Shard Communication: Introduces complexity that intra-shard parallel execution does not have.

The property that ensures a parallel execution engine always produces the same final state as a sequential execution of the same transactions in the canonical order. This is non-negotiable for blockchain consensus.

• Core Requirement: The system must be deterministic despite non-deterministic scheduling of parallel threads.
• Achieved Through: A combination of dependency tracking, conflict resolution (like abort/re-execute in STM), and a final sequential commitment phase that applies writes in the global order.
• Guarantee: This ensures all network validators reach identical results, maintaining the blockchain's single source of truth.