Concurrent Execution

Unlike sequential blockchains where transactions are processed one after another, concurrent execution allows the network to process multiple, non-conflicting transactions at the same time. This is achieved by analyzing the state access patterns of transactions. For example, a transfer between Alice and Bob can be processed in parallel with a transfer between Charlie and Dana, as they access different accounts.

The core mechanism enabling concurrency is tracking which parts of the blockchain's state (e.g., specific accounts, smart contract storage) a transaction will read from and write to. Systems use techniques like Software Transactional Memory (STM) or deterministic parallelism to identify and schedule non-overlapping transactions for parallel execution, while ensuring conflicting transactions are processed sequentially to maintain correctness.

The primary benefit is a massive increase in transactions per second (TPS) and reduced confirmation times. By utilizing multiple processor cores simultaneously, the network's computational capacity scales more efficiently with hardware. This directly addresses the scalability limitations of purely sequential models, enabling blockchain applications to support user bases and transaction volumes comparable to traditional web-scale systems.

Different blockchains implement concurrency in distinct ways:

• Solana: Uses a Sealevel parallel runtime that schedules transactions based on declared state dependencies.
• Aptos & Sui: Employ Block-STM, a parallel execution engine for the Move language that uses optimistic concurrency control.
• Monad: Combines parallel execution with MonadDB and pipelining for high-performance Ethereum Virtual Machine (EVM) compatibility.

A critical challenge is handling transactions that conflict by accessing the same state (e.g., two trades for the same liquidity pool). Systems must detect these conflicts and ensure deterministic final state. Methods include:

• Optimistic Execution: Execute in parallel first, then validate and re-execute conflicts.
• Pessimistic Locking: Acquire locks on state before execution. The goal is to maximize parallel work while guaranteeing the same outcome as a sequential process.

For developers, concurrent execution can be transparent or require active design. In some systems (e.g., using Block-STM), existing sequential smart contracts can run with automatic speedups. For maximum performance, developers may need to structure contracts and transactions to minimize state contention—designing data models that allow operations on independent data segments to avoid conflicts and unlock full parallel potential.

Concurrent execution allows a blockchain's state to be updated by multiple transactions at the same time, provided they do not access the same data. This is a fundamental departure from the sequential model used by networks like Ethereum's EVM. Key implementations include:

• Sealevel: Solana's runtime that schedules transactions across multiple cores.
• Block-STM: Aptos and Sui's software transactional memory system for optimistic parallelization.
• Modular DA Layers: Data availability layers like Celestia and EigenDA enable rollups to post and process data in parallel.

Applications requiring massive user interaction benefit directly from concurrency. This eliminates bottlenecks and failed transactions due to nonce conflicts or single-threaded congestion.

• DEXs & Perpetuals: Order matching and liquidations can be processed in parallel, enabling higher trade volume and lower latency.
• On-Chain Games & Social Apps: Player actions and social interactions can be executed simultaneously, creating a seamless, real-time user experience impossible on sequential chains.
• High-Frequency Operations: Automated strategies in DeFi (e.g., arbitrage, lending) execute more reliably without being blocked by unrelated network activity.

Achieving safe and effective concurrent execution requires specific architectural choices at the protocol and virtual machine level.

• State Access Declarations: Transactions must pre-declare which accounts or state objects they will read/write (e.g., Solana's read/write locks, Aptos' Move resources).
• Deterministic Scheduling: The runtime must have a deterministic way to schedule, execute, and validate parallel transactions to ensure consensus.
• Conflict Resolution: Mechanisms like Block-STM's re-execution or optimistic concurrency control are needed to handle transactions that conflict on shared state.

Concurrency changes how developers design and reason about smart contracts, introducing new patterns and potential pitfalls.

• Explicit State Dependencies: Developers must carefully manage and declare state access to maximize parallelizability and avoid deadlocks.
• New Abstraction Models: Frameworks like Sui's Object Model and Aptos' Move are built around owned objects that are inherently parallelizable, differing from the shared global state model of Ethereum.
• Testing Complexity: Ensuring correctness in a parallel environment requires rigorous testing for race conditions and non-deterministic outcomes that don't exist in sequential execution.

Understanding the trade-offs between concurrent and sequential execution models is key for application design.

• Throughput vs. Simplicity: Concurrent execution (e.g., Solana, Aptos) maximizes hardware utilization for throughput, while sequential execution (e.g., Ethereum EVM) offers a simpler, more deterministic programming model.
• Gas Estimation: Parallel systems often have more predictable gas/fee costs for independent operations, while sequential networks see volatile fees due to single-threaded contention.
• Composability: Sequential execution offers synchronous composability (calls within a block), while parallel execution often relies on asynchronous patterns, which can be more complex but enable greater scale.

Concurrent execution is rapidly evolving, with new standards and cross-chain interoperability efforts emerging.

• EVM Parallelization: Projects like Monad and Sei v2 are bringing parallel execution to the EVM environment, aiming to retain compatibility while boosting performance.
• Interoperability Protocols: Protocols like LayerZero and Wormhole must account for differing execution models when facilitating cross-chain messages and state proofs.
• Formal Verification: As systems become more parallel, the need for formal verification tools to prove the safety of concurrent smart contracts is increasing.

The core software environment that enables the simultaneous processing of transactions. Unlike a sequential EVM, a parallel VM can schedule and execute multiple independent transactions at the same time, dramatically increasing throughput. Key examples include:

• Aptos MoveVM and Sui MoveVM, which are designed with parallel execution as a first-class feature.
• Solana's Sealevel runtime, which schedules transactions based on declared state dependencies.
• Modified EVM implementations like those used by Monad and Sei v2.

A system for identifying which parts of the blockchain state (accounts, smart contract storage) a transaction will read from and write to. This is the fundamental requirement for determining which transactions can be run in parallel. There are two primary models:

• Explicit Declaration: Transactions must declare all state keys they will access upfront (e.g., Sui, Aptos).
• Dynamic Scheduling: The runtime dynamically analyzes and schedules transactions based on real-time access patterns, often using software transactional memory (STM) concepts.

The mechanism that identifies when two concurrent transactions attempt to modify the same state, creating a write-write conflict. Systems handle this differently:

• Optimistic Concurrency Control: Transactions execute in parallel optimistically, and a final validation step aborts and re-executes any that had conflicts.
• Pessimistic Concurrency Control: Transactions requiring the same state are serialized from the start, preventing conflicts but reducing potential parallelism.
• Deterministic Ordering: A leader (e.g., the block proposer) pre-orders transactions to minimize conflicts before parallel execution begins.

Using a Directed Acyclic Graph (DAG) to represent transaction dependencies and execution order, rather than a strictly linear block. This is a key enabler for advanced concurrency models.

• In a Block DAG, multiple blocks of transactions can be proposed concurrently, with edges representing dependencies.
• Execution Graphs explicitly map the flow of transactions, allowing independent branches to be processed in parallel. This structure is central to the design of networks like Aptos Block-STM and Narwhal (Sui's mempool).

Decoupling transaction execution from block consensus and finality. This allows validators to execute transactions as soon as they are seen, without waiting for a block to be finalized.

• Pipeline Architecture: Separates the stages of gossip, execution, consensus, and commitment into parallel pipelines (pioneered by Solana).
• Speculative Execution: Transactions are executed speculatively based on the most recent state, and results are only committed once the block containing them is finalized, enabling low-latency pre-confirmations.

The underlying physical compute resources required to realize the benefits of concurrent software architecture. Parallel execution shifts the bottleneck from software to hardware.

• Multi-core CPUs: Essential for distributing computational workloads across threads.
• High-Speed Memory & SSDs: Required for low-latency access to large, concurrent state databases.
• High-Bandwidth Networking: Necessary for validators to keep up with rapid block and transaction gossip in a high-throughput environment.

The traditional blockchain processing model where transactions in a block are executed one after another, in a strict order. This is the baseline against which concurrent execution is measured.

• Characteristic: Simple and deterministic but creates a fundamental bottleneck.
• Examples: Used by Ethereum's EVM (pre-EIP-6480) and Bitcoin. All transactions must wait for previous ones to fully complete.

Occur when two or more transactions attempt to read from or write to the same state (e.g., a wallet balance, an NFT owner) simultaneously. Managing these is the central challenge for concurrent execution.

• Conflict Resolution: Systems use optimistic concurrency control (re-execute conflicts) or require explicit dependency declaration.
• Impact: High conflict rates can force fallback to sequential execution, negating performance gains.

The requirement that a transaction, given the same initial state and inputs, will always produce the exact same result on every node in the network. Concurrent execution must preserve this property for consensus.

• Challenge: Parallel processing must be logically deterministic, even if the physical order of operations varies.
• Solution: Achieved through techniques like speculative execution with validation or strict dependency graphs.

Transactions Per Second (TPS) is the primary metric improved by effective concurrent execution. It measures the network's capacity to process transactions.

• Direct Correlation: Moving from sequential to concurrent execution is the main architectural shift enabling high TPS (thousands to hundreds of thousands).
• Note: TPS gains are only realized for workloads with low state conflict, such as payments across unrelated accounts.

The design of the blockchain's Virtual Machine is critical for enabling concurrency. It defines how transaction logic is isolated and how state access is managed.

• Sequential VMs: Like the EVM, were designed for single-threaded execution, requiring layer-2 solutions or major upgrades (EIP-6480) for concurrency.
• Parallel VMs: Newer VMs like Move VM (Aptos, Sui) and Solana's runtime are built from the ground up with state access models that expose concurrency.