The Ethereum Virtual Machine (EVM) faces significant performance limitations due to its single-threaded architecture. This sequential transaction processing model severely restricts network throughput, resulting in processing speeds that fall far short of growing user demands. By analyzing the EVM's execution flow, we can identify two primary software challenges for implementing parallel execution: state identification and data architecture with IOPS consumption. Various projects propose different solutions, each involving trade-offs around EVM compatibility, optimistic versus pessimistic parallelism, database design, memory versus storage efficiency, developer experience, hardware requirements, and modular versus monolithic chain architecture.
It's important to recognize that while parallel execution offers exponential scalability potential, inherent bottlenecks in distributed systems—such as P2P networking and database throughput—remain. Achieving traditional computing performance levels in blockchain systems is a long-term endeavor. Current parallel execution approaches also face challenges including increasing hardware requirements, node centralization risks, potential downtime from memory or cluster dependencies, and cross-chain communication between parallelized chains. These areas require continued exploration and innovation.
The Single-Threaded Limitations of Ethereum
Ethereum's performance constraints primarily stem from its architectural design, particularly the lack of parallel processing capability. Implementing transaction parallelism would effectively transform a single-lane road into a multi-lane highway, dramatically increasing network capacity.
Understanding Ethereum's Transaction Flow
In Ethereum's current execution/consensus separation model, all EVM transaction processing occurs sequentially:
- Execution nodes translate transaction instructions into EVM-opcode
- Gas requirements are determined based on hardcoded opcode values
- Transactions access the database to retrieve and update state information
- Transactions are executed in strict numerical order within each block
- The Merkle Patricia Tree (MPT) stores state data, producing state roots, transaction roots, and receipt roots after block execution
- Consensus layer validates the state root for transaction verification
- Validated blocks are added to the blockchain and broadcast network-wide
This sequential execution prevents state conflicts but creates severe performance limitations, contributing to Ethereum's limited transactions per second (TPS). While Ethereum has adopted a Layer2-centric roadmap, fundamental EVM issues including MPT structure and LevelDB database inefficiencies remain unaddressed.
Current optimization efforts focus primarily on two areas: transaction state separation for parallel processing and database optimization for high-concurrency state access.
The Database IOPS Challenge
While state separation concepts are relatively straightforward, database IOPS (Input/Output Operations Per Second) requirements present complex challenges that receive less public discussion.
Ethereum uses a key-value database organized through MPT structures. The MPT system enables efficient data verification through cryptographic hashing but introduces significant performance overhead:
- Performance issues: MPT's hierarchical structure requires traversing multiple nodes for updates, involving substantial hash computations and frequent database access
- State bloat: Growing blockchain state data increases storage requirements and node synchronization challenges
- Inefficient partial updates: Any leaf node modification requires recomputing hashes along the entire path to the root
For perspective: updating a single key-value pair in a binary MPT with 16 billion keys requires approximately 68 read operations and 34 write operations. Processing 10,000 simple transfers per second would necessitate 2.04 million IOPS operations—far beyond consumer SSD capabilities (typically 10,000-100,000 IOPS).
Ethereum's proposed Verkle Tree implementation offers some improvement through reduced tree depth and smaller proofs via KZG commitments, but these represent incremental rather than transformative changes for parallel execution and high IOPS requirements.
Parallel Execution as Standard in New Networks
Most new Layer1 networks now incorporate parallel execution as a standard feature. Implementation approaches vary primarily by virtual machine (EVM-compatible versus non-EVM) and state separation methodology (optimistic execution versus explicit declaration).
Different solutions involve various trade-offs between compatibility, performance, and development complexity.
Comparative Approaches to Parallel Execution
MegaETH operates as a high-performance heterogeneous blockchain leveraging Ethereum's security through EigenDA for consensus and data availability. Its performance optimization strategy includes:
- Transaction prioritization for streamed block construction
- New database structures addressing MPT limitations
- Specialized hardware through centralized sequencers
MegaETH currently focuses on maximizing single-node performance before implementing parallel execution.
Monad implements a native parallel execution EVM through:
- Optimistic parallel execution using Block-STM inspired technology
- Database restructuring with async I/O support
- Decoupled consensus and execution layers
The project maintains EVM compatibility while significantly improving throughput capabilities.
Aptos developed the Block-STM parallel execution engine that has become widely adopted. Its approach features:
- Optimistic execution with conflict detection and re-execution
- Multi-version data structures for state conflict management
- Parallelized transaction propagation, ordering, and execution
The system reduces developer burden but increases hardware requirements.
Sui implements pessimistic parallelization with:
- Developer-declared state dependencies
- Object-based architecture instead of account models
- Locking mechanisms to prevent execution conflicts
This approach increases developer responsibility but reduces system complexity.
Solana employs deterministic parallelism requiring:
- Explicit state declarations in transaction construction
- Custom account database (Cloudbreak) with sharded architecture
- Memory-mapped storage for improved IO performance
The FireDancer client implementation further pushes hardware efficiency limits.
Sei transitioned from pessimistic to optimistic parallelization in its V2 upgrade, incorporating:
- Block-STM inspired execution
- SeiDB database separating active and historical data
- Memory-based state management with periodic snapshots
This balance aims to provide both performance and developer convenience.
Node Requirements and Implementation Trade-offs
Hardware requirements vary significantly across implementations:
- FireDancer: Highest requirements (performance-optimized)
- Sei: High memory requirements
- Monad: Moderate requirements (32GB RAM)
- Sui/Aptos: Moderate requirements
- MegaETH: Low requirements (except sequencer nodes)
- Ethereum: Lowest requirements
Implementation approaches diverge primarily on three optimization fronts: database IOPS consumption, state identification methodology, and asynchronous pipelining.
The optimistic execution approach (adopted by Aptos, Monad, and Sei V2) assumes transaction independence and handles conflicts through re-execution. The declaration-based approach (used by Sui, Solana, and Sei V1) requires explicit developer declarations but provides more deterministic execution.
Database optimization strategies differ between horizontal scaling (adding parallel I/O channels) and vertical optimization (reducing I/O consumption through memory mapping). These choices directly impact hardware requirements and cost structures.
EVM-compatible chains face additional constraints maintaining Merkle Trie compatibility, while non-EVM chains can implement more radical architectural changes like Sui's Objects model or Solana's separated code and data accounts.
👉 Explore advanced scaling solutions
Future Outlook and Challenges
While parallel execution components have relatively clear optimization targets, fundamental distributed system limitations remain. Blockchain systems still face inherent bottlenecks in P2P networking, database operations, and hardware constraints.
Current challenges include:
- Increasing hardware requirements leading to node centralization
- Potential downtime risks from memory or cluster dependencies
- Cross-chain communication complexities between parallelized chains
- Security and verification challenges in optimized architectures
The ecosystem continues to explore optimal engineering approaches through both modular (MegaETH) and monolithic (Monad) designs. These implementations demonstrate blockchain technology increasingly incorporating traditional computer optimization techniques, particularly in data storage, hardware utilization, and processing pipelining.
Despite these advances, significant bottlenecks and challenges remain, creating substantial opportunities for continued innovation and improvement.
Frequently Asked Questions
What is parallel execution in blockchain context?
Parallel execution allows multiple transactions to be processed simultaneously rather than sequentially. This requires identifying independent transactions that don't conflict over shared state, enabling substantial throughput improvements compared to single-threaded processing models.
How does optimistic parallel execution work?
Optimistic execution assumes transactions are independent and processes them concurrently. If conflicts are detected (multiple transactions accessing the same state), affected transactions are re-executed sequentially. This approach reduces developer burden but requires sophisticated conflict detection mechanisms.
What are the trade-offs between EVM compatibility and performance?
EVM compatibility ensures easier migration of existing contracts and developers but constrains architectural innovation. Non-EVM chains can implement more radical optimizations but face ecosystem development challenges. The choice involves balancing developer convenience against performance potential.
Why does database design matter for blockchain performance?
Blockchains frequently access and update state information. inefficient database structures create significant IOPS requirements that limit transaction throughput. Optimized database designs reduce unnecessary operations and enable higher concurrency.
How do hardware requirements affect decentralization?
Higher hardware requirements increase node operation costs, potentially leading to greater centralization as fewer participants can afford to run nodes. Projects must balance performance improvements against decentralization preservation.
What future developments might improve parallel execution?
Potential improvements include better state conflict prediction, more efficient database structures, hardware acceleration, cross-shard communication protocols, and improved developer tools for writing parallel-friendly smart contracts.