Parallel EVMs and Improved State Layers

An overview of parallel design architectures for blockchains, using two relevant examples: Monad and Sei. It highlights the differences between optimistic and deterministic parallelization and examines the nuances of state and memory access across these chains.

Parallel EVMs and Improved State Layers


Parallelization will continue to become a pivotal theme as the on-chain world continues to tackle the blockchain trilemma.  The blockchain trilemma refers to the trade-off between 3 critical aspects of the blockchain technology surrounding security, scalability and decentralization.  Dominant blockchains today, such as Bitcoin and Ethereum, prioritize decentralization and security but failed to address the challenges of scalability.  Despite the introduction of Layer-2 (L2) scaling solutions to use off-chain techniques, it comes at the cost of compromising the security and decentralization of the underlying blockchain.  Fragmented liquidity and poor user experience have also become a major barrier to overcome for L2’s.  Parallel execution has proven to be a promising blockchain scaling solution needed for widespread adoption without sacrificing user experience and fragmented liquidity as seen with Solana.  Solana has shown that its unique architecture supporting parallel processing can achieve scalability as multiple transactions can be confirmed simultaneously. Applying such approach to the dominant Ethereum Virtual Machine (EVM) has proven to be much more complicated.  However, there are some promising projects that are trying to offer developers the possibility to create their applications in a familiar EVM environment with the performance of Solana.  In this article, we look at a few promising projects that are working on parallelized EVM solutions and we’ll delve into how these networks are designed.

Parallelized blockchains and optimizing state access

Parallel computation, a key facet of modern computing, allows for the simultaneous execution of numerous calculations or processes, in stark contrast to the traditional method of sequential execution. This approach involves breaking down complex problems into smaller, independent parts that can be processed by multiple processors while communicating through shared memory. The advantages of implementing parallel computing are substantial, including enhanced efficiency and speed, scalability, improved reliability, fault tolerance, optimal resource utilization, and the capacity to handle exceptionally large data sets. However, it is imperative to grasp that the effectiveness of parallelization is contingent on the specific characteristics of the underlying architecture and its implementation.


In the context of blockchain technology, a notable challenge arises from two core bottlenecks: cryptographic functions (such as hash functions, signatures, and elliptical curves) and memory or state access. Significant consideration must be given to designing an efficient parallel system with regards to accessing the state, which encompasses a transaction's ability to read from and write to various elements of a blockchain's state, including storage, smart contracts, and account balances. For a parallelized blockchain to function optimally and deliver high performance, the optimization of state access is of paramount importance.

Presently, there exist two prevailing schools of thought with respect to optimizing state access for parallelized blockchains: deterministic parallelization and optimistic parallelization. The deterministic approach entails explicit declaration within the code of which parts of the blockchain state will be accessed and modified prior to execution. This affords the system the ability to ascertain, in advance, which transactions can be processed concurrently without conflicts. Deterministic parallelization offers predictability and efficiency, especially when transactions are primarily independent. However, this approach introduces a higher degree of complexity for developers.

On the other hand, optimistic parallelization does not necessitate upfront declaration of state access within the code and processes transactions concurrently under the assumption of no conflicts. In the event of a conflict, optimistic parallelization may necessitate rerunning or reprocessing the conflicting transactions, or processing them sequentially. While optimistic parallelization provides greater flexibility for developers, the need for re-execution in the case of conflicts results in this method being most effective when transactions are not in conflict. It is important to note that there is no definitive answer as to which of these approaches is superior. They represent two distinct and viable methodologies for achieving parallelization. 

Why parallelize EVMs?

Ethereum is currently where the vast majority of blockchain development takes place. A recent report from Electric Capital found that 71% of smart contract code was initially deployed on Ethereum.  Although Ethereum is the birthplace for the majority of blockchain code, developers also frequently opt to deploy their projects on alternative blockchains that boast higher speeds and reduced transaction fees.  Blockchains like Solana or Cardano have had a hard time attracting Ethereum developers because they use software that is incompatible with Ethereum’s. Solana uses its own custom-made solution, while Cardano uses a UTXO model. This has created an opportunity for Sei and similar projects looking to court Ethereum devs.

Source: Electric Capital

The Ethereum blockchain, renowned for its smart contract capabilities and robust community, is actively addressing scalability concerns. However, the shift from sharding to roll-ups presents a challenge in achieving sufficient scalability at the base layer. While roll-up centric solutions have the potential to enhance scalability, they are not without drawbacks. Fragmented liquidity and diminished user experience, stemming from interactions with multiple blockchains, represent significant barriers. 

MONAD: Parallel Design Overview (Technical)

Monad is developing a parallel EVM Layer 1 with full compatibility for Ethereum bytecode, which sets it apart from other platforms. Its unique features include pipelining, asynchronous I/O, separating consensus and execution, and MonadDB, reflecting its innovative design approach. A notable innovation is the use of pipelining with a slight offset, which allows for multiple processes to be run in parallel, optimizing various functions. In terms of parallelization, transactions are ordered linearly within a block, but the goal is to expedite this process through parallel execution.

Monad uses an optimistic parallelization algorithm, processing transactions simultaneously and verifying the consistency of the outcomes. In case of conflicts, transactions are re-executed, a process that remains inexpensive due to cached inputs. By separating execution and consensus, Monad strives to enhance performance, while also enabling parallel execution of transactions within a block. The system starts executions before previous ones are completed and monitors inputs/outputs to rectify incorrect results, leading to increased throughput and reduced transaction failures.

Asynchronous I/O is a key component of Monad's approach, allowing for parallel transaction execution without waiting for I/O results, thus boosting processing efficiency. MonadDB, built for efficient blockchain data and state access, optimizes parallel access to multiple nodes, offering significant speed improvements. Compared to generic databases, MonadDB's capability to execute numerous reads in parallel results in substantial performance gains.

Monad's custom-built database leverages the latest Linux kernel technologies and SSDs for asynchronous I/O, enhancing processing speed while reducing reliance on excessive RAM. These technologies not only optimize performance but also align with the platform's commitment to decentralization and scalability. 

Sei v2: Parallel Design Overview (Technical)

Sei, a general purpose, open source Layer 1 blockchain, is designed specifically for the secure exchange of digital assets. With the release of Sei v2, the platform introduces optimistic parallelization, a enhancement that significantly enhances its appeal to developers compared to its deterministic predecessor. By embracing optimistic parallelization, Sei v2 offers a more developer-friendly environment where smart contracts can be executed concurrently without the need for upfront resource declarations.

Optimistic parallelization, a key feature of Sei v2, allows for the seamless execution of smart contracts in a parallel manner on the blockchain. This approach eliminates the requirement for developers to specify resource dependencies beforehand, enabling the chain to run transactions optimistically in parallel. However, in scenarios where conflicts arise due to multiple transactions accessing the same state, Sei's system efficiently handles these conflicts by tracking the specific storage components impacted by each conflicting transaction.

By employing Optimistic Concurrency Control (OCC), Sei's blockchain processes transactions concurrently, thereby enhancing efficiency and throughput within the network. The transaction processing in Sei's system comprises two distinct phases: execution and validation. During the execution phase, transactions are processed optimistically, with all read/write operations temporarily stored in a transaction-specific store. Subsequently, in the validation phase, the system verifies these temporary store operations against any state changes resulting from previous transactions. Transactions that are deemed independent can run in parallel, while conflicts arising from data dependencies trigger a re-validation process.

In the event of conflicts, Sei's parallel system identifies each conflict by comparing the read sets of transactions with the latest state changes stored in a multi-versioned store, indexed by transaction order. To resolve conflicts, Sei iteratively executes, validates, and reruns transactions until all conflicts are successfully resolved. This iterative process ensures the integrity and consistency of the blockchain by systematically addressing conflicts as they arise.

A significant aspect of Sei v2's upgrade is the introduction of SeiDB, a dual-component data structure designed to streamline storage functions and prevent blockchain bloat. By segregating state storage and state commitment, SeiDB departs from the conventional single IAVL tree design, improving latency, disk usage, and read/write performance under multithreaded operations. The redesigned SeiDB effectively tackles several key issues faced in blockchain storage, including write amplification, state bloat, sluggish operations, and long-term performance degradation.


The revamped storage architecture of SeiDB is divided into two main components: state store and state commit. While the state commitment component is responsible for recording and validating data changes, the state storage component functions as a comprehensive database maintaining all data records at any given point in time. Within Sei v2, the State Commitment mechanism leverages a memory-mapped IAVL tree architecture (MemIAVL) to reduce metadata overhead, resulting in decreased state storage requirements and sync times. The MemIAVL structure, represented by three disk files (kv, branch, leaves), significantly minimizes metadata tracking, leading to a more efficient state storage process with over 50% reduction in storage requirements compared to conventional methods.

Sei recognizes the diverse needs and preferences of node operators with regards to storage solutions. Consequently, Sei's flexible approach in designing the state storage layer, known as SS, allows for seamless integration with various backend support systems, including PebbleDB, RocksDB, SQLite, and others. This versatility provides node operators with the freedom to choose storage backends that align with their specific requirements, thereby enhancing operational flexibility and efficiency within the network.

In conclusion, the enhancements introduced in Sei v2 underscore its commitment to fostering a developer-friendly, efficient, and scalable blockchain ecosystem. By leveraging optimistic parallelization, optimizing storage solutions through SeiDB, and offering flexible backend support for state storage, Sei v2 sets a new standard for blockchain platforms seeking to address the evolving needs of developers and node operators in the digital asset exchange landscape.


The Web3 landscape is characterized by fierce competition, as numerous layer 1 and layer 2 solutions vie for prominence. However, success in this domain transcends mere technological advancement. Compelling narratives, robust community building, and the launch of exciting new applications on the network are equally pivotal. Therefore, blockchains that excel in these areas often find themselves in advantageous positions. Specifically, in the context of parallel EVM (Ethereum Virtual Machine) narrative, Monad has strategically positioned itself for success. Although its performance may marginally lag behind Sei, Monad is currently generating the most excitement and attention, thus positioning itself as a prime contender among the projects discussed in this discourse. Nevertheless, it is essential to recognize that trends in the crypto space are transient, and consequently, Monad must leverage its short-term hype to bootstrap its ecosystem effectively.

Moreover, apart from competing with each other, these platforms must also vie with established entities such as Ethereum, its layer 2 solutions, and second-generation blockchains like Solana, Avalanche, and Polygon, all of which have had substantially more time to cultivate their communities and ecosystems. The allure of these new, innovative technologies and their impressive performance is likely to garner attention upon their launch. However, long-term success hinges on their ability to capitalize on this attention and retain users and developers to foster thriving ecosystems and communities of their own.

In summary, a comprehensive exploration of parallelization in blockchains, as viewed through the lens of Sei and Monad, provides a thorough understanding of how different architectures and approaches can enhance performance and scalability. Solana's deterministic parallelization, emphasizing upfront declaration of state access, offers predictability and efficiency, rendering it a compelling choice for high-throughput applications. On the other hand, Sei's optimistic parallelization approach prioritizes developer flexibility and is well-suited for environments with infrequent transaction conflicts. Meanwhile, Monad presents an innovative solution with its unique blend of optimistic parallelization and the custom-built MonadDB, leveraging the latest technological advancements to optimize state access and performance.

Conclusively, each blockchain presents a distinct approach to addressing the challenges of parallelization, entailing its own set of trade-offs. Solana's design focuses on maximizing hardware utilization and throughput, while Sei prioritizes easing the development process, and Monad emphasizes a tailor-made database solution for blockchain data. These variances underscore the diversity within the blockchain ecosystem and underline the significance of selecting the most suitable platform based on an application's specific requirements.

As the blockchain space continues to evolve, the strides in parallelization techniques demonstrated by Solana, Monad, and Sei are bound to inspire further innovation. The ongoing journey towards more efficient, scalable, and developer-friendly blockchains is expected to draw invaluable insights from these platforms, playing a seminal role in shaping the future of blockchain technology.