Ethereum processes 12-15 TPS sequentially—each transaction waits for the previous one to complete. Despite most validators running multi-core processors, these cores sit idle. Parallel EVMs like Monad target 10,000+ TPS by executing non-conflicting transactions simultaneously, finally utilizing modern hardware capabilities.
The Sequential Execution Problem
How Traditional Blockchains Process Transactions
Sequential processing executes transactions in the exact order received:
- Leader selection via consensus algorithm
- Fetch pending transactions from mempool
- Execute each transaction sequentially, reading and updating state
- Emit logs and generate hashes for verification
- Continue until block gas limit reached
- Broadcast block for peer validation
Why Sequential Creates Bottlenecks
- Underutilized hardware: Multi-core CPUs idle while transactions queue
- Network congestion: High activity creates backlog and extended wait times
- Fee competition: Users bid up gas for prioritization during congestion
- Scalability ceiling: Throughput limited regardless of hardware improvements
Blockchain State Models
UTXO Model (Bitcoin)
Unspent Transaction Outputs represent discrete "coins" that are consumed and created:
- Mechanism: Transactions consume existing UTXOs and produce new ones
- Privacy: New addresses with each UTXO make linking difficult
- Parallelism: Transactions spending different UTXOs naturally parallelize
- Complexity: Wallet must track all UTXOs to calculate balance
Account Model (Ethereum)
Single balances per address, similar to bank accounts:
- Mechanism: Transactions directly modify account balances
- Simplicity: Intuitive for developers and users
- State bloat: All historical data must be maintained
- Parallelism barrier: Any transaction can modify any state, creating dependencies
Object-Centric Model (Sui)
Assets exist as independent objects with defined ownership:
- Mechanism: Transactions modify specific objects, outputs are new/modified objects
- Natural parallelism: Independent objects process simultaneously
- Instant finality: Transactions on unrelated objects bypass consensus
- Developer paradigm: Requires thinking in objects rather than accounts
Parallelization Strategies
Deterministic vs Optimistic Parallelization
Two schools of thought dominate parallel execution design:
| Approach | Deterministic | Optimistic |
|---|---|---|
| State access | Declared upfront | Discovered during execution |
| Conflict handling | Prevented by design | Detected and re-executed |
| Developer burden | Must specify dependencies | No changes required |
| Predictability | Higher | Variable (depends on conflicts) |
| Examples | Solana, Sui | Monad, Sei v2, Aptos |
Solana: Sealevel (Deterministic)
How Sealevel Works
Solana's parallel runtime processes tens of thousands of contracts simultaneously using all available validator cores:
- State declaration: Transactions explicitly specify all accounts they'll read/write
- Dependency analysis: Banking Stage determines which transactions can run together
- Parallel rules:
- Different accounts → run in parallel
- Both reading same account → run in parallel (reads don't conflict)
- Both writing same account → run sequentially
- Account-level locking: Scheduler enforces rules via read/write locks
Sealevel sorts instructions by program ID and runs the same program over all accounts concurrently. This Single Instruction, Multiple Data approach allows a single piece of code to execute over multiple data streams simultaneously—uniquely efficient for Solana's design.
Solana Architecture Advantages
- Determinism: Runtime knows upfront which transactions conflict
- No re-execution: Conflicts prevented rather than detected
- Pipelining: Different stages run on different hardware simultaneously
- Turbine propagation: Erasure-coded block distribution optimizes bandwidth
AccountsDB & Cloudbreak
Solana's state storage addresses traditional database limitations:
- Horizontal scaling: State distributed across multiple SSD devices
- Parallel I/O: Cloudbreak handles 32 simultaneous I/O operations
- Memory-mapped files: SSD access mimics RAM speed
- Reduced RAM dependency: Index moved from RAM to SSDs in v1.9
Monad: Optimistic Parallel EVM
Performance Targets
| Metric | Ethereum | Monad |
|---|---|---|
| TPS | 12-15 | 10,000+ |
| Block time | 12 seconds | 500ms |
| Finality | ~13 minutes | 1 second |
| Hardware | 2 cores minimum | 16 cores, 32GB RAM, 2TB SSD |
Optimistic Execution Model
Unlike Solana's upfront declaration, Monad assumes transactions execute independently:
- Execute all transactions in parallel optimistically
- Track read/write sets during execution
- Validate assumptions during merge phase
- If inputs prove stale (earlier transaction modified accessed data), re-execute with correct state
- Re-execution is cheap: inputs cached from prior execution
Monad maintains full bytecode compatibility—anything running on Ethereum's Go implementation runs on Monad without modification. Developers don't need to rewrite contracts or specify state access, making migration frictionless.
Deferred Execution Architecture
Monad decouples consensus from execution—a critical innovation:
- Consensus layer: Validators agree on transaction ordering without executing them
- Execution layer: Nodes independently execute ordered transactions to update state
- Parallel operation: Consensus uses full block time for communication; execution uses full block time for computation
- Delayed merkle roots: Each block includes state root from N blocks ago, enabling later verification
MonadDB: Purpose-Built State Storage
Rather than generic databases (LevelDB, RocksDB), MonadDB is built specifically for blockchain:
- Native Patricia Tries: On-disk and in-memory, eliminating hash-based node references
- Direct path compression: Reduced computational overhead
- Asynchronous I/O: Parallel transactions access storage simultaneously without serialization
- Latest kernel features: Leverages modern Linux async operations
MonadBFT Consensus
- 2-round BFT: Derived from HotStuff, lower latency than 3-round alternatives
- Threshold signatures: Aggregated using pairing-based cryptography
- RaptorCast: Erasure-coded block propagation via two-tier relay network
- Local mempool: Transactions routed to scheduled leaders rather than global gossip
Sei v2: First Parallelized EVM
Performance Specs
| Metric | Sei v2 | Sei Giga (upcoming) |
|---|---|---|
| Throughput | 100 megagas/second | 5 gigagas/second |
| Block time | 400ms | 400ms |
| Finality | Instant | Under 400ms |
| TPS (batched) | 28,300 | ~200,000 |
Optimistic Concurrency Control (OCC)
Sei v2's parallelization strategy:
- Execution phase: All transactions processed optimistically in parallel
- Reads/writes: Temporarily stored in transaction-specific store
- Validation phase: Check temporary operations against state changes from previous transactions
- Conflict detection: Compare read sets against multi-version store indexed by transaction order
- Re-execution: Conflicts trigger iterative re-execution until resolved
Unlike deterministic parallelization, Sei v2 doesn't require developers to define dependencies upfront. Smart contracts deploy without modification—the chain optimistically processes everything and resolves conflicts automatically.
SeiDB Storage Architecture
Sei v2 redesigned storage into two components:
- State Store: Unencrypted key-values, efficient metadata history without redundancy
- State Commitment: MemIAVL tree (memory-mapped IAVL) for node consensus
Benefits:
- 50%+ reduction in state storage
- Faster state sync for new nodes
- Reduced write amplification
- Flexible database backend support (PebbleDB, RocksDB, SQLite)
Aptos: Block-STM
Software Transactional Memory Approach
Aptos's Block-STM achieves 160k+ TPS through Software Transactional Memory techniques:
- Transactions ordered within block (preset sequence)
- Execute all transactions in parallel optimistically
- Track memory locations accessed during execution
- Validate against concurrent modifications
- Re-execute on conflict; guaranteed to eventually succeed
Performance Results
| Benchmark | TPS | Improvement vs Sequential |
|---|---|---|
| Diem (low conflict) | 110k | 20x |
| Aptos (low conflict) | 170k | 17x |
| Diem (contended) | 50k | ~5x |
| Aptos (contended) | 80k | ~8x |
During the Tapos gaming surge (May 2024), Aptos handled 326 million transactions over three days without congestion or fee spikes—demonstrating Block-STM's production reliability.
Move Language Benefits
Aptos uses Move, originally developed for Diem:
- Resources: Digital assets that can't be copied or accidentally lost
- Ownership tracking: Prevents race conditions in parallel environments
- Static typing: Type inference and overflow checking enhance safety
- Formal verification: Mathematical proofs of contract correctness
Sui: Object-Centric Parallelism
How Sui Differs
Sui's object-centric model provides natural parallelism:
- Independent objects: Each has owner, permissions, and properties
- Ownership changes: Simple transfers only modify ownership attribute
- No contention: Transactions on different objects process simultaneously
- Consensus bypass: "Owned object transactions" skip consensus entirely
Dynamic Resource Allocation
Sui validators dynamically allocate computational resources:
- Additional processing power during high transaction loads
- Reduces need for high gas fees during congestion
- Faster confirmation for latency-sensitive applications
Comparing Parallel Architectures
| Feature | Solana | Monad | Sei v2 | Aptos | Sui |
|---|---|---|---|---|---|
| Parallelization | Deterministic | Optimistic | Optimistic (OCC) | Optimistic (STM) | Object-centric |
| State model | Account | Account (EVM) | Account (EVM) | Account (Move) | Object (Move) |
| EVM compatible | No (SVM) | Full bytecode | Full bytecode | No (Move) | No (Move) |
| Developer changes | Declare state | None | None | Use Move | Use Move |
| Finality | ~400ms | 1 second | Instant | ~250ms | ~500ms |
| Target TPS | 65k+ | 10k+ | 28k+ | 160k+ | 100k+ |
Challenges and Trade-offs
State Contention Problem
Parallelization benefits diminish when transactions conflict:
- AMM bottlenecks: Many users hitting single liquidity pool serializes transactions
- NFT mints: High-demand mints create single contract hotspot
- Popular dApps: Applications weren't designed to minimize conflicts
Decentralized applications like Uniswap weren't built with parallel processing in mind. Dozens or hundreds of transactions competing for the same pool creates significant bottlenecks. AMM designers must reconsider how liquidity is allocated to optimize for parallelization.
Hardware Requirements
High performance demands robust hardware:
- Monad: 16 cores, 32GB RAM, 2TB SSD, 100 Mbps
- Trade-off: Solo-staker accessibility sacrificed for throughput
- Centralization risk: Fewer validators can meet requirements
Re-execution Overhead
Optimistic systems must handle conflicts:
- Re-execution adds latency when conflicts occur
- High-conflict workloads approach sequential performance
- Caching mitigates but doesn't eliminate overhead
Investment Implications
What Parallelization Enables
- On-chain order books: CLOBs become viable at high throughput
- Real-time gaming: Latency-sensitive applications functional
- Complex DeFi: Sophisticated strategies without gas wars
- Institutional adoption: Predictable costs and performance
Evaluation Framework
- Contention resistance: How does performance degrade under high conflict?
- Developer experience: Code changes required for optimization?
- EVM compatibility: Existing ecosystem migration friction
- Decentralization: Hardware requirements vs validator accessibility
- Production track record: Real-world stress test performance
Parallelization is transitioning from competitive advantage to industry standard. Chains like Sei implemented Block-STM derivatives; Monad validated STM-based optimistic concurrency. The question isn't whether parallel execution wins—it's which implementations execute best when contention spikes and which ecosystems attract developer mindshare.