Smart Contract Execution Is Not Parallel

Smart contract execution is sequential. Ethereum, Solana, and most L1s process transactions one at a time within a block, creating a deterministic but slow global state machine.

Parallelism is the proven scaling path. Modern computing uses multi-core CPUs and GPUs; blockchains like Aptos and Sui implement this with parallel virtual machines (MoveVM) and conflict-free execution.

The bottleneck is state access. A transaction modifying a popular NFT contract (e.g., Bored Ape Yacht Club) blocks all others needing that state, unlike independent Uniswap swaps which could run in parallel.

Evidence: Solana's Sealevel runtime demonstrates the potential, claiming 50k-65k TPS for simple payments by executing non-conflicting transactions simultaneously.

Sequential execution guarantees determinism. Parallel execution introduces non-determinism from race conditions and scheduling, breaking the core guarantee that a transaction's outcome is identical for every node. This is why Sui and Aptos require complex Byzantine Fault Tolerant consensus to manage parallel execution's inherent unpredictability.

Composability requires shared state. The Ethereum Virtual Machine (EVM)'s global, linearized state is what allows DeFi protocols like Uniswap and Aave to atomically compose. Parallel execution fragments this state, forcing developers to reason about concurrency control and data dependencies, which adds complexity and risk.

The bottleneck is state access, not CPU. Most blockchain workloads are I/O-bound, waiting for Merkle proof verification and storage reads. Parallelizing execution without solving state access, as seen in early Solana congestion, just creates different bottlenecks. The real scaling path is via EIP-2930 access lists and state expiry.

Evidence: Ethereum's L2 rollups, like Arbitrum and Optimism, preserve sequential execution within their virtual machines. They scale by moving computation off-chain and posting compressed proofs to L1, proving that sequencing is the security primitive, not the performance limit.

Sequential execution is the bottleneck. A blockchain's consensus mechanism can finalize blocks in milliseconds, but a single-threaded EVM must process transactions one after another. This creates a hard physical limit on throughput, regardless of network speed.

Parallel execution is the proven solution. Modern processors use multiple cores; blockchains like Solana (Sealevel) and Sui (Move) do the same. They analyze transaction dependencies to execute non-conflicting operations simultaneously, achieving order-of-magnitude gains.

The EVM is the legacy system. Its global state and sequential design are incompatible with parallelization. Layer 2s like Arbitrum Stylus and Monad are building new VMs to bypass this, treating the EVM as a compatibility layer, not a performance engine.

Evidence: Solana's architecture targets 100k+ TPS by default, while a saturated Ethereum L1 executes ~15 TPS. The gap is not consensus; it's the execution model.

Smart contract execution is serial. The EVM processes transactions sequentially to guarantee deterministic state transitions, creating a hard throughput ceiling.

Rollups inherit this bottleneck. Arbitrum and Optimism scale data posting, but their execution layers remain single-threaded, capping their TPS gains.

Parallel execution requires new VMs. Solana's Sealevel and Aptos' Block-STM demonstrate the performance gains, but Ethereum's path is through new execution layers like Monad.

Danksharding solves data, not execution. Proto-danksharding (EIP-4844) provides cheap blob space for rollups but does not make the EVM itself faster.

The endgame is modular separation. A dedicated execution layer, like EigenLayer's EigenDA for data and a parallelized EVM for compute, is the logical conclusion.

Sequential execution is non-negotiable. Ethereum's state is a single, globally ordered list of changes. This guarantees determinism and composability but creates a hard throughput ceiling. Parallel virtual machines like Solana's Sealevel or Sui's Move bypass this by assuming transaction independence, which breaks Ethereum's atomic composability model.

The future is specialized execution layers. The ecosystem will fragment into purpose-built L2s and L3s. A rollup for a high-frequency DEX like dYdX will optimize for order matching, while a social app's rollup will prioritize cheap, simple state transitions. This is the only viable path to scale without altering Ethereum's core security guarantees.

Shared sequencers create coordination points. Projects like Astria and Espresso are building decentralized sequencer sets that multiple rollups can use. This creates a new coordination layer—a 'multi-threaded' ecosystem of execution environments that batch transactions to a single, sequential L1, preserving atomic cross-rollup composability where it matters most.

Evidence: The L2 landscape is already diverging. Arbitrum Nitro, Optimism Bedrock, and zkSync Era have fundamentally different VM architectures, proving systems, and data compression strategies. This specialization is the direct, necessary consequence of working around a sequential base layer.