Parallel EVM Explained: Monad, Sei V2 & Neon

Why Sequential EVM Is a Bottleneck

Ethereum's EVM processes transactions sequentially because the protocol cannot safely parallelize execution without knowing which state slots each transaction will access. Transaction A might read account balance X and write to X, while transaction B also depends on X. If both execute simultaneously, results could diverge from sequential ordering.

This sequential design limits Ethereum to approximately 12-15 TPS and creates gas price volatility during network congestion. L2s like Arbitrum and Optimism achieve higher throughput through different mechanisms (fraud/validity proofs), but L1 parallelization directly attacks the root constraint.

The State Dependency Problem

Each smart contract interaction reads and writes specific state slots. Consider a DEX swap: transaction reads oracle price, reads user balance, decrements user balance, increments recipient balance. If two swap transactions execute concurrently without ordering guarantees, one might read a stale oracle price, leading to inconsistent results.

Monad: MonadBFT & 10,000 TPS

Monad is a new Layer 1 blockchain designed from scratch for parallel EVM execution. Its consensus mechanism, MonadBFT, orders transactions but allows execution parallelism. MonadBFT achieves 10,000 TPS, a 600x improvement over Ethereum's current throughput.

How MonadBFT Works

MonadBFT separates consensus (transaction ordering) from execution (state updates). Validators reach consensus on a transaction order but execute transactions in parallel across multiple threads. If transaction B depends on transaction A's output, MonadBFT detects this dependency, ensures A executes first, and then executes B.

The key innovation: instead of pessimistically locking state before execution, Monad optimistically executes transactions in parallel. After execution, if state conflicts are detected (two transactions wrote to the same slot), the offending transaction rolls back and re-executes in correct order.

Monad's EVM Compatibility

Monad maintains full EVM compatibility. Solidity smart contracts deploy without modification. This is critical: developers can migrate from Ethereum with zero code changes, reducing friction and enabling rapid adoption. Monad's consensus and parallelism are transparent to the application layer.

Optimistic Parallelism Explained

Optimistic parallelism is the core technique behind parallel EVM. The strategy: execute many transactions concurrently assuming they do not conflict. Check for conflicts afterward. If conflicts occur, re-execute the conflicting transaction in correct order.

Pessimistic vs. Optimistic Approach

Pessimistic locking requires analyzing transaction inputs before execution to identify which state they access. This is expensive (requires re-implementing parts of the EVM) and limits parallelism benefit. Optimistic parallelism avoids this overhead: execute first, conflict-check later.

Most transactions never conflict. In a typical DeFi application, if user Alice swaps on DEX A and user Bob swaps on DEX B, both transactions touch entirely different state and can execute in parallel. The optimistic approach scales to these non-conflicting scenarios with zero overhead.

Conflict Detection & Re-execution

After parallel execution completes, the chain checks for state conflicts by comparing write sets. If transactions A and B both wrote to the same state slot, a conflict occurred. The canonical order (determined by consensus) is enforced: A's writes take effect, B is rolled back, and B is re-executed against A's modified state.

Sei V2: Parallelized EVM on Cosmos

Sei V2 launched in Q1 2024 as the first parallelized EVM environment integrated into the Cosmos SDK. Unlike Monad (which is a standalone L1), Sei is a Cosmos-based chain benefiting from Tendermint consensus and the broader IBC ecosystem.

Sei V2 Architecture

Sei V2 groups transactions by their access patterns. Transactions that read/write to different contract accounts are batched and executed in parallel. Sei's parallelism is more structured than Monad's general-purpose approach: it leverages Cosmos's state organization (each account is a key) to pre-identify non-conflicting transactions.

Sei V2 achieves 2,000+ TPS with full EVM compatibility. It maintains support for existing ERC-20, ERC-721, and complex DeFi protocols. The chain also features MEV mitigation through encrypted mempools and frequent batching.

Sei's Cosmos Integration

As a Cosmos chain, Sei benefits from IBC (Inter-Blockchain Communication). Developers can build apps that interact with other Cosmos chains (Osmosis, Atom) without wrapping. This is distinct from Monad, which is isolated, and Neon, which depends on Solana's ecosystem.

Neon EVM: Solana-Native Parallel Execution

Neon EVM is not an independent L1 but a Program deployed on Solana that executes EVM bytecode. It leverages Solana's Sealevel runtime, which is inherently parallel. Sealevel processes transactions that touch different accounts in parallel, and Neon EVM maps Ethereum accounts to Solana accounts to enable parallelism.

Solana Sealevel Runtime

Solana's Sealevel is the world's first parallel transaction runtime built into a blockchain. Each Solana transaction specifies which accounts it will read/write. Validator nodes execute transactions with different account sets in parallel. Sealevel is deterministic: all validators reach identical state through deterministic parallelism.

Neon EVM wraps Ethereum smart contracts in Solana Accounts and uses Sealevel's parallelism transparently. This gives Neon the ability to execute EVM contracts at Solana's throughput (theoretical 50,000+ TPS).

Neon's Limitations

Neon depends on Solana's infrastructure and is subject to Solana's congestion. Solana validators must run Neon's EVM interpreter, adding computational load. Additionally, Neon's compatibility is not 100% EVM—certain contracts (those with complex storage layouts) may require adjustments.

Comparison: Chain Architecture & Performance

The following table compares Monad, Sei V2, and Neon EVM across key dimensions:

State Conflict Resolution Strategies

Different parallel EVM chains employ different conflict detection and resolution strategies:

Monad's Re-execution Model

Monad executes transactions speculatively in parallel and detects conflicts via write-set analysis. If transaction B's read set intersects with transaction A's write set, and A executed before B but they ran in parallel, B is rolled back and re-executed. This guarantees consistency with minimal re-execution overhead in typical cases.

Sei's Account-Level Isolation

Sei V2 partitions transactions into groups based on account access. Transactions in group A touch accounts (Alice, Bob) while group B touches accounts (Charlie, Dave). Since groups access disjoint accounts, they execute in parallel without any conflict possibility. This avoids re-execution but requires stricter partitioning.

Neon's Deterministic Specification

Neon users must declare account access upfront (inherited from Solana's model). Sealevel groups transactions by declared accounts and executes non-conflicting groups in parallel. This eliminates runtime conflict detection but requires explicit account specification in every transaction.

FAQ