Sei vs Monad: Everything You Need to Know About Parallel EVM
A look under the hood at Sei v2 and Monad
Blockcrunch VIP is a premium research newsletter on the most important crypto projects and trends, prepared by top crypto analysts twice a month. Subscribe to Blockcrunch VIP to receive in-depth project analysis from our research team - all for the price of a coffee ☕ a day.
In an industry where technological advancements and narratives evolve at an increasingly rapid pace, parallelized Ethereum Virtual Machines (EVMs) have emerged into the spotlight, claiming to offer crucial solutions to scalability and efficiency challenges currently faced by the EVM.
Two contenders have emerged as frontrunners — Sei Network and Monad. Both are at the forefront of parallel execution, introducing innovative approaches for processing transactions and smart contract executions more effectively and efficiently. Notably, while Sei Network has already introduced its token (SEI), Monad remains in the development phase.
The rise of the 'Parallelized EVM Narrative' has seen SEI's performance soar, with the token value increasing by over 500% in the last three months, significantly outperforming ETH's 50% rise in the same timeframe.
This report aims to provide a high level analysis of parallel EVM implementations and potential impacts of Sei Network and Monad. The report will thoroughly examine the distinctive features, potential challenges, and opportunities that SEI and Monad bring to the forefront of blockchain technology.
Disclosure: The author holds a position in SEI.
Parallel Execution: What is it?
All this talk about parallelization, but what are we parallelizing, and what does it actually mean?
‘Parallel execution’ simply means processing multiple transactions or operations at the same time, instead of handling them one after the other. In the context of transactions on a blockchain, it's like having several lines at the checkout of your local grocery store instead of just one, allowing more traffic to flow simultaneously.
Traditionally, blockchain networks process transactions sequentially (one by one), which can lead to bottlenecks, especially during high-traffic periods — like a single-file line at the grocer where each shopper waits their turn.
Parallel execution breaks away from this linear model by enabling the network to handle multiple transactions concurrently, significantly increasing the network's capacity and efficiency. This approach is particularly beneficial for complex smart contract executions, which can be resource-intensive. By parallelizing these operations, transaction processing times are reduced, the overall throughput of the network is improved, and transaction costs are lowered due to increased efficiency.
In essence, parallel execution transforms the blockchain from a one-lane road into a multi-lane superhighway, allowing for faster and more efficient processing of a larger volume of transactions. This is a key step in scaling blockchain technology to meet the demands of a growing user base and increasingly complex applications.
Today, parallel execution is achieved via two primary methodologies: state access control and optimistic execution.
The state access approach involves a preemptive analysis of transactions to determine their impact on different segments of the blockchain's state. This facilitates the identification of independent transactions, streamlining the process of parallel execution. Solana, Sei v1, and Sui are successful examples of blockchains using state access approach to parallelize execution.
In contrast, the optimistic model operates on the initial assumption of transaction independence. It subsequently verifies this assumption, making necessary adjustments to correct any dependencies identified post-execution. Examples of chains using the optimistic approach are Aptos, Monad, and Sei v2.
However, parallel execution alone is not enough to scale a blockchain effectively, as there are multiple bottlenecks beyond just transaction processing and execution. These include challenges like state management, network latency, and data storage efficiency — we will not dive too deep into these concepts, but will explore these briefly in the context of Sei and Monad’s implementations of parallel execution.
Author’s Note: The following will mostly cover the architecture behind Sei and Monad that facilitate parallel execution on the EVM — I’ve tried to keep it as high level as possible, with analogies here and there to aid understanding.
Sei Network
Background & Architecture
Sei is a Layer 1 blockchain built on the Cosmos SDK and CosmWasm smart contract platform. Cosmos SDK chains can be architecturally divided into three conceptual layers:
Application Layer: This is where the blockchain processes and updates its status based on a group of transactions. Think of it as the layer where the application logic and transaction processing happens. On Sei, this layer is connected to the Consensus and Networking layers via ABCI++.
Consensus Layer: Allows all the nodes (or participants) in the blockchain network to reach an agreement on the current state of the system, ensuring everyone is on the same page. On Sei, this layer is handled by a fork of Tendermint. Tendermint is a consensus mechanism based on the Byzantine-Fault-Tolerant (BFT) model, which is a unique solution to the Byzantine General’s Problem — also known as the consensus issue in distributed computing where parties must agree on a single strategy to avoid failure, despite some participants being unreliable or malicious. More on this later.
Networking Layer: This layer is key for spreading transactions throughout the blockchain and for circulating messages that are essential for achieving consensus — this layer is also part of the Tendermint Core.
Sei is also connected to the rest of Cosmos via the Inter-Blockchain Communication Protocol (IBC).
While Sei is a Cosmos chain, it is ‘not like the others’ — Sei leverages the modularity and customizability of the Cosmos stack to introduce enhancements over the standard Cosmos SDK chain:
Twin-Turbo Consensus
Parallelization
Native Order Matching Engine
Twin-Turbo Consensus
At its core, Twin-Turbo Consensus is defined by two key elements: Intelligent Block Propagation and Optimistic Block Processing. These features work in tandem to streamline the way transactions are handled and blocks are confirmed, representing a significant leap from traditional methods.
Intelligent Block Propagation is a sophisticated way of disseminating (gossiping) transactions across the network. Instead of a linear, time-consuming process, it allows for a more dynamic and efficient transaction spread among nodes, ensuring that validators receive transaction data quickly and accurately.
Imagine a scenario where Alice and Bob each have their own extensive libraries of books. Previously, when Alice wanted to discuss a book with Bob, she would send the book to him to read. However, since Bob usually already had the same book in his library, this process was time-consuming and redundant.
Similarly, block proposers send blocks containing each transaction in full detail. However, since validators routinely exchange transaction data among themselves at the time of transaction submission, the majority of them already possess all the necessary transactions in their local mempool — up to 99.99% of transactions! This meant that validators waste a lot of time waiting to receive transactions that they already had in their mempool.
Now, imagine if Alice sends Bob only the title of the book she's been reading. Bob, upon receiving this, checks his own library and, finding the same book, can refer to the book. Only if he doesn't have the book does he let Alice know to send the full copy.
Likewise, using intelligent block propagation, block proposers now transmit a proposal containing only a hash for each transaction included in the block. When this proposal reaches the validators, they can swiftly reconstruct the block using transactions from their own mempool. In instances where validators lack some transactions in their local mempool, they can default to waiting for the full block contents to be delivered. This implementation of intelligent block propagation has led to a significant enhancement in efficiency, with an observed increase in overall throughput of approximately 40%.
The second element, Optimistic Block Processing, is a proactive (optimistic) approach to block confirmation.
The Tendermint BFT protocol reaches consensus in two phases (rounds of communication between nodes) — prevote and precommit — after a block is proposed. During the propose phase, a block is proposed and shared with other validators. Subsequently, validators exchange prevote and precommit messages to reach a consensus on committing that specific block. Following the dispatch of a precommit message, validators methodically process each transaction in the block, applying necessary state changes. This procedure can become notably sluggish, especially when dealing with a substantial volume of data.
Sei recognized that validators already have all the transactions from the block by the prevote phase, and that there's an opportunity to begin optimistically processing the state changes, applying them to a provisional candidate state instead of waiting for the full commitment cycle to complete.
This method allows validators to 'optimistically' process transactions as soon as they receive a block proposal. This optimistic processing significantly reduces latency, as validators can act swiftly, either committing the transaction data if the block is accepted or discarding it if not.
Parallelization v1
At its core, Sei uses the Cosmos SDK, which is like the operating system for its blockchain network. When validators receive a block of transactions, they follow a three-part procedure: BeginBlock, DeliverTx, and EndBlock.
Each part is customizable, and Sei has tailored the last two for parallel processing:
DeliverTx Transaction Parallelization: Traditionally, transactions would be processed one after the other during DeliverTx. Sei changes this by allowing multiple transactions to be processed at the same time, in parallel, leading to faster performance.
To avoid race conditions and nondeterminism — scenarios where the outcome of processes is unpredictable or undesirable due to their simultaneous execution — Sei carefully manages which transactions can run in parallel and which need to go in order, based on the type of transaction and the data they handle. In addition to these measures, smart contract developers specify the resources their contracts use and define any dependencies, in order to facilitate the safe parallel execution of transactions.
EndBlock and the Matching Engine: In the EndBlock stage, Sei processes orders related to its native matching engine, which pairs buy and sell orders. Instead of processing these orders one by one, Sei handles independent orders in parallel at the end of the block. Orders are considered independent if they don't impact the same market within the same block, speeding up the overall process.
Parallelization v2
Sei recently announced its v2, which introduces the addition of the following:
EVM Support
Optimistic Parallelization
SeiDB.
EVM Support
Sei's support for the Ethereum Virtual Machine (EVM) hinges on two pivotal concepts: Backwards Compatibility and Interoperability.
Backwards Compatibility allows for the deployment of existing Solidity smart contracts on Sei without any code alterations. This is achieved via an import of go-ethereum (Geth) into the core Sei binary, which is essentially incorporating Ethereum's standard software framework for running and managing blockchain applications.
EVM transactions are wrapped as Sei transactions for the network’s nodes to process. Here's how it works:
Transaction Initiation: Say Alice initiates a transaction from MetaMask to send tokens to her address on Sei. MetaMask creates and signs the transaction with Alice’s key.
Transaction Handling by Sei: The Sei RPC server receives this signed transaction from Alice and wraps it in a Sei transaction before passing it to a Sei node. Notably, the transaction isn’t signed again at this stage.
Signature Verification: The Sei node verifies the transaction’s signature using the Ante handler logic specific to the EVM module. This module, containing Geth, then processes Ethereum transactions, handling state updates or contract calls through a specialized interface that connects Sei and the EVM.
Address Translation: Both EVM and Sei addresses are generated and mapped through the Address Translator, facilitating the integration of Ethereum transactions within the Sei ecosystem.
Interoperability, on the other hand, ensures seamless interaction among various transaction types, such as Bank, EVM, Wasm, and Staking. Sei’s Geth incorporates a special function known as a precompile, which is essentially a built-in operation allowing for the execution of complex tasks. This particular precompile enables the calling of Cosmwasm contracts.
Moreover, Sei's wasmd module is designed to communicate with the EVM. This setup allows EVM contracts to interact with Cosmwasm contracts, and vice versa, creating a bridge for seamless operation between these two types of smart contracts.
Optimistic Parallelization
As we covered earlier, in Sei v1, developers had to manually define dependencies to prevent race conditions — a process that could be quite cumbersome. In Sei v2, the chain takes a significant leap forward by autonomously and optimistically managing parallelization. This approach will work for all kinds of transactions on Sei, whether they are Sei's own native transactions, Cosmwasm transactions, or EVM transactions.
When Sei encounters conflicting transactions touching the same parts of storage in parallel, it follows a straightforward process:
Identifying Conflicts: The system first identifies which parts of its storage (like a digital filing cabinet) each transaction is trying to access or change.
Parallel or Sequential Processing: If the transactions are working on different parts of the storage, they are processed at the same time (in parallel). However, if they are trying to change the same data, they are processed one after the other (sequentially).
Recursive Resolution: This step-by-step approach repeats itself until all conflicts are resolved, ensuring that each transaction is handled correctly without any data clashes.
SeiDB
We won’t go too deep into this, but SeiDB is an upgrade of the existing database from a complex IAVL tree structure to a more efficient system. This new system divides the database into two parts: a state store for quick access to data, improving query response times, and a state commitment layer using an optimized in-memory structure to speed up consensus among validators. This results in a number of performance improvements as below:
Additionally, Sei is switching to PebbleDB from GoLevelDB, known for superior read/write speeds, particularly in multi-threaded tasks, significantly enhancing overall database performance.
For the technically inclined, more information about the SeIDB implementation can be found here and here.
Monad
Background & Architecture
Monad is a performance focused Ethereum-compatible L1 chain, with four major optimizations that set it apart from other EVM chains:
MonadBFT
Deferred Execution
Parallel Execution
MonadDB
One thing to note is that Monad has written its own Ethereum client from the ground up using C++ and Rust. The most popular Ethereum client is Geth — Sei v2 uses a modified version of Geth (which uses Go).
MonadBFT
MonadBFT is a pipelined two-phased BFT algorithm based on the Hotstuff BFT protocol.
I know…Let’s unpack this:
Pipelining is a method for achieving parallelism by breaking down tasks into smaller, sequential parts that can be completed concurrently.
A practical example of how pipelining works: Consider the task of doing four loads of laundry. A basic approach would be to wash, dry, fold, and put away the first load before beginning the next load. However, with pipelining, as soon as the first load is in the dryer, you start washing the second load, and repeat this for each step of the task. This way, pipelining maximizes efficiency by engaging multiple resources at the same time. Note that in the laundry example, no resource (storage) is used (accessed) by more than one load (transaction) at any given time.
The term “two-phased” refers to how many phases it takes for a BFT protocol to achieve consensus and each phase represents one round of message exchange between nodes. Like Tendermint, MonadBFT needs only two phases to reach consensus, and is an improved version of the original three-phased Hotstuff protocol.
For the technically inclined, refer to this paper for an overview of the different BFT protocols.
Deferred Execution
Unlike Ethereum and most other blockchains, execution on Monad is NOT a prerequisite to consensus.
What does that mean?
Consensus involves nodes agreeing on the sequence of transactions, whereas execution pertains to carrying out these transactions and updating the system state.
In Monad's approach, nodes reach a consensus on transaction order without executing said transactions yet. This means that both the leader (chosen validator for that block) proposing the block and the validating nodes approve the transaction order without needing to know if the transactions were executed or not. This fundamental design is a key contributor to Monad’s speed and scalability.
In essence, once transactions are officially ordered, the resulting state is not a matter of chance but a predetermined certainty.
To ensure integrity, Monad includes a delayed merkle root in block proposals. Once consensus is achieved on block N, it confirms the state at block N-D rooted in a specific merkle root. Any discrepancies in execution lead to a node falling out of consensus and triggering a rollback and re-execution process.
To recap, Monad modifies the strict enforcement of execution-before-consensus seen on Ethereum and most blockchains today, gaining substantial throughput at the cost of slightly relaxed strictness. This strategic design choice underpins Monad's ability to efficiently scale and manage a high volume of transactions.
Parallel Execution
Parallel execution on Monad is achieved through optimistic execution, where transactions with no common dependencies within a block are executed in parallel, even before preceding transactions are completed. This approach is similar to Sei’s 'optimistic parallelization' concept that we explored above.
What does this mean?
Consider two transactions in the same block, where both read and update the balance of the same account, creating a potential race condition. If these transactions run in parallel, and the second transaction starts before the first one finishes, it might read an outdated account balance, resulting in incorrect execution.
Thus, only transactions that do not share dependencies can be executed in parallel on different cores. On the other hand, transactions with shared dependencies are executed sequentially as per usual. This method of consecutive scheduling not only maintains operational integrity but also significantly reduces I/O overhead, which is a major factor contributing to latency in the current EVM implementation that teams like Monad and Sei are trying to solve.
MonadDB
Unlike SeiDB, which is a re-architected IAVL tree data structure that uses PebbleDB for key-value storage, MonadDb is a custom-built database specifically designed for blockchain state management, efficiently implementing the Merkle Patricia Trie (MPT) structure used by Ethereum. It enhances performance by directly integrating the data structure it requires, both for on-disk and in-memory storage.
This is significant because most Ethereum clients traditionally rely on different types of data structures, such as LSM-Trees, typically found in key-value databases. Key-value databases store data as a collection of key-value pairs, where each unique key is linked to a specific piece of data or value. However, these conventional databases embed the MPT within these differing structures, leading to inefficiencies.* By natively implementing the MPT structure, both in memory and on disk, MonadDb aligns more closely with Ethereum's state management needs, offering a more optimized and direct approach to data storage and retrieval for blockchain applications.
Another key advantage of MonadDb is its use of asynchronous input/output (async i/o), allowing the system to process multiple transactions simultaneously without waiting for disk operations to complete. This is a significant upgrade over traditional key-value databases used in Ethereum, which often lack efficient async i/o support.
*Worth noting that in Sei's case, Sei only stores key-value pairs in the database, so storing an IAVL/MPT in the database isn't a concern.
Technical Comparison
Impacts & Challenges
The parallel execution in blockchain systems, and more specifically the EVM — like Sei and Monad — represents a significant leap forward in enhancing the scalability and efficiency of EVM transactions. However, these advancements come with their own set of impacts and challenges that are essential to consider.
Impacts
Increased Transaction Throughput: By executing transactions in parallel, blockchain networks can process more transactions simultaneously, significantly increasing throughput. This is crucial for blockchain scalability, as it allows networks to handle larger volumes of transactions, catering to a growing user base.
Optimization of Resources: Parallel EVMs make better use of computational resources. By distributing transaction processing across multiple cores, they ensure that the computational capacity of the network is utilized more effectively.
Enhanced User Experience: Faster transaction processing and cheaper gas costs directly impacts the user experience positively. This is increases accessibility to users in third-world countries and is particularly important for decentralized applications that require real-time interactions.
Enhanced Developer Experience: Parallel EVMs offer a wider array of design and development possibilities, facilitating innovation and creation of new applications.
Challenges
State Management Complexity: Parallel processing of transactions increases the complexity of state management. Transactions that depend on the same state need careful handling to avoid conflicts, known as race conditions, which can lead to inconsistent states if not managed correctly.
Optimistic Execution Overheads: While optimistic execution allows for parallel processing, it also requires mechanisms to detect and correct incorrect executions. This adds an additional layer of complexity and can potentially lead to increased processing time for some transactions.
Scheduling and Dependency Analysis: Efficiently scheduling transactions for parallel execution requires advanced algorithms to analyze dependencies. Incorrect scheduling can lead to frequent re-executions, undermining the benefits of parallel processing.
Database and I/O Optimizations: Implementing custom databases like SeiDB and MonadDB to support asynchronous I/O is crucial for the success of parallel EVMs. Due to its nascent nature and relatively unproven state, can be challenging to maintain and update.
Balance between Decentralization and Performance: The need for more computational resources for nodes running parallel EVMs may raise concerns about the decentralization aspect. Ensuring that nodes can operate on standard hardware and service providers without compromising on performance is a delicate balance to strike. Not doing so could result in an over dependence on specialized RPC node providers, non consumer-grade hardware, etc. — high throughput chains like Solana and Sei have come under criticism for this exact reason.
Sei in particular faces questions regarding the collocation of its validator set — the concentration of nodes and stake weight in a single geographic region (ie. Europe).
This is perhaps a valid question to ask — a check of other blockchains however, shows that stake weight is generally concentrated in a particular region (continent), as shown in the table below:
From the table above, we can observe a notable pattern: blockchains with a stake weight concentration exceeding 80% in a particular continent predominantly feature central limit order book (CLOB) decentralized exchanges (DEXs) as their primary application. This geographic collocation may contribute to reduced latency, which is crucial for CLOB DEXs' performance. For a more nuanced analysis, examining stake weight distribution across various cloud service providers, countries, or client types could be insightful. This would offer a deeper perspective on network decentralization, a subject often marked by complex discussions. However, this report will not explore the broader philosophical and practical debates surrounding decentralization.
Conclusion
The transition towards parallel EVMs heralds significant potential for enhancing blockchain scalability and efficiency. This shift, however, requires meticulous management of the complexities associated with optimizing the processing of transactions and state management in blockchain systems. As these technical hurdles are progressively overcome, parallel execution could become a cornerstone in the ongoing evolution of not just the EVM, but all blockchains.
References
Sei v2: Will Sei Claim the Title of the First Parallelized EVM Blockchain?
What is the difference between PBFT, Tendermint, HotStuff, and HotStuff-2?
Disclaimer
The Blockcrunch Podcast (“Blockcrunch”) is an educational resource intended for informational purposes only. Blockcrunch produces a weekly podcast and newsletter that routinely covers projects in Web 3 and may discuss assets that the host or its guests have financial exposure to.
Some Blockcrunch VIP posts are written by contractors to Blockcrunch and posts reflect the contractors’ independent views, not Blockcrunch’s official stance. Blockcrunch requires contractors to disclose their financial exposure to projects they write about but is not able to fully guarantee no such conflicts of interest exist. Blockcrunch itself will not buy or sell assets it covers 72 hours prior to and subsequent to the publication of a piece; however, its directors, employees, contractors and affiliates may buy or sell assets prior to or subsequent to publication of any content and will make disclosures on a best effort basis.
Views held by Blockcrunch’s guests are their own. None of Blockcrunch, its registered entity or any of its affiliated personnel are licensed to provide any type of financial advice, and nothing on Blockcrunch’s podcast, newsletter, website and social media should be construed as financial advice. Blockcrunch also receives compensation from its sponsor; sponsorship messages do not constitute financial advice or endorsement.
For more detailed disclaimers, visit https://blockcrunch.substack.com/about