Parallel EVM: Breaking Through Blockchain Performance Bottlenecks

TL;DR

1. Parallel EVMs represent a new narrative that emerges as on-chain transaction volumes reach a certain level. They are mainly divided into monolithic blockchains and modular blockchains, with monolithic ones further categorized into L1 and L2. Parallel L1 public chains are split into two camps: EVM and non-EVM. Currently, the parallel EVM narrative is in its early stages of development.
2. The technical implementation path of parallel EVMs includes virtual machines and parallel execution mechanisms. In the context of blockchains, a virtual machine is a process virtual machine that virtualizes the distributed state machine to execute contracts.
3. Parallel execution refers to leveraging multicore processors to execute multiple transactions simultaneously as much as possible while ensuring that the final state is consistent with what would be achieved through serial execution.
4. Parallel execution mechanisms are divided into three categories: message passing, shared memory, and strict state access lists. Shared memory is further divided into the memory lock model and optimistic parallelization. Regardless of the mechanism, each increases the technical complexity.
5. The narrative of parallel EVMs not only has intrinsic drivers of industry growth but also requires practitioners to pay close attention to potential security issues.
6. Each parallel EVM project provides its unique approach to parallel execution, showing both technical commonalities and distinct innovations.

1.Industry overview

1.1 Historical evolution

Performance has become a bottleneck for further development in the industry. Blockchain networks create a new and decentralized basis of trust for transactions between individuals and enterprises.

The first-generation blockchain networks, represented by Bitcoin, pioneered a new mode of decentralized electronic currency transactions with distributed ledger technology, revolutionizing a new era. The second-generation, exemplified by Ethereum, fully utilized imagination to propose decentralized applications (dApps) through a distributed state machine approach.

Since then, blockchain networks have embarked on their own rapid development over more than a decade, from Web3 infrastructure to various tracks such as DeFi, NFTs, social networks, and GameFi, giving birth to numerous innovations in technology and business models. The thriving industry needs to continually attract new users to participate in the ecosystem of decentralized applications, which in turn raises higher requirements for product experience.

Web3, as a novel product form “unprecedented in history,” must innovate in meeting user needs (functional requirements) while balancing between security and performance (non-functional requirements). Since its inception, various solutions have been proposed to address performance issues.

These solutions can generally be categorized into two types: on-chain scaling solutions, such as sharding and Directed Acyclic Graphs (DAGs), and off-chain scaling solutions, such as Plasma, Lightning Networks, sidechains, and Rollups. However, these are still far from keeping up with the rapid growth of on-chain transactions.

Especially after the DeFi Summer of 2020 and the explosive growth of inscriptions in the Bitcoin ecosystem towards the end of 2023, the industry urgently needs new performance enhancement solutions to meet the demands for “high performance and low fees.” Parallel blockchains were born against this backdrop.

1.2 Market size

The narrative of parallel EVM signifies a competitive landscape where two major players dominate in the field of parallel blockchains. Ethereum processes transactions serially, executing them one after another, which results in low resource utilization. Switching from serial to parallel processing could significantly enhance performance.

Ethereum’s rivals such as Solana, Aptos, and Sui, all feature built-in parallel processing capabilities and have developed robust ecosystems. Their respective token market capitalizations have reached $45 billion, $3.3 billion, and $1.9 billion, forming a parallel non-EVM camp. In response to these challenges, the Ethereum ecosystem is not to be outdone, with various projects stepping forward to empower EVM, thus creating a parallel EVM camp.

Sei, in its version 2 upgrade proposal, has loudly declared that it will become the “first parallel EVM blockchain,” with a current market capitalization of $2.1 billion and potential for even greater growth. The new parallel EVM blockchain Monad, currently the hottest in marketing fervor, is highly favored by investors and has significant potential. Meanwhile, the L1 blockchain Canto, with a market cap of $170 million and its own free public infrastructure, has also announced its parallel EVM upgrade proposal.

Additionally, several early-stage L2 projects are enhancing cross-ecosystem performance by integrating multiple L1 chains’ capabilities. Aside from Neon, which has achieved a circulating market value of $69 million, other projects still lack relevant data. It is expected that more L1 and L2 projects will join the parallel blockchain battlefield in the future.

Not only is there significant market growth potential for the parallel EVM narrative, but the broader sector of parallel blockchains to which the parallel EVM belongs also holds substantial market growth potential, promising a wide-ranging market outlook.

Currently, the total market capitalization for Layer 1 and Layer 2 is $752.123 billion, with parallel blockchains having a market capitalization of $52.539 billion, accounting for approximately 7%. Within this, projects related to the parallel EVM narrative have a market capitalization of $2.339 billion, making up just 4% of the parallel blockchain market capitalization.

1.3 Industry Map

The industry generally divides blockchain networks into a four-layer structure:

Layer 0 (Network): This is the underlying blockchain network layer that handles basic network communication protocols.

Layer 1 (Infrastructure): This layer relies on various consensus mechanisms to validate transactions within a decentralized network.

Layer 2 (Expansion): Dependent on Layer 1, this involves various second-layer protocols aimed at addressing the limitations of Layer 1, especially in terms of scalability.

Layer 3 (Application): Dependent on Layer 2 or Layer 1, this layer is used to build various decentralized applications (dApps).

Parallel EVM (Ethereum Virtual Machine) narrative projects are mainly divided into monolithic blockchains and modular blockchains, with monolithic blockchains further divided into L1 and L2. From the total number of projects and the development of several major tracks, it can be seen that the parallel EVM L1 public chain ecosystems still have significant room for growth compared to the Ethereum ecosystem.

In the DeFi track, there is a demand for “high speed and low fees,” while the gaming track demands “strong real-time interaction”; both require a certain execution speed. Parallel EVMs will inevitably bring better user experiences to these projects, pushing the industry’s development into a new stage.

L1 represents new public chains with inherent parallel execution capabilities and serves as high-performance infrastructure. In this faction, projects such as Sei v2, Monad, and Canto have independently designed parallel EVMs, which are compatible with the Ethereum ecosystem and provide high transaction throughput capabilities.

L2, by integrating the capabilities of other L1 chains, offers expanded capacity for cross-ecosystem cooperation and is a prominent example of rollup technology. In this faction, Neon acts as an EVM emulator on the Solana network, while Eclipse executes transactions on Solana but settles on the EVM. Lumio is similar to Eclipse, except that the execution layer has been switched to Aptos.

Beyond the aforementioned standalone blockchain solutions, Fuel has introduced its own modular blockchain concept. In its second version, it aims to position itself as an Ethereum rollup operating system, offering more flexible and comprehensive modular execution capabilities.

Fuel focuses on executing transactions, while outsourcing other components to one or more independent layers of blockchain, thus allowing more flexible combinations: it can function as a Layer 2, a Layer 1, or even as a sidechain or a state channel. Currently, there are 17 projects within the Fuel ecosystem, primarily focusing on DeFi, NFTs, and infrastructure.

However, only the Orally cross-chain oracle has been put into practical use. The decentralized lending platform Swaylend and the perpetual contract trading platform SPARK have been launched on testnets, while other projects are still under development.

2.Technical Implementation Pathways

To achieve decentralized transaction execution, blockchain networks must fulfill four responsibilities:

• Execution: Executing and validating transactions.
• Data Availability: Distributing new blocks to all nodes in the blockchain network.
• Consensus Mechanism: Verifying blocks and achieving consensus.
• Settlement: Settling and recording the final state of transactions.

Parallel EVM primarily focuses on performance optimization of the execution layer. This is divided into Layer 1 (L1) solutions and Layer 2 (L2) solutions. L1 solutions introduce a mechanism for parallel transaction execution, allowing transactions to be executed in parallel within the virtual machine as much as possible. L2 solutions fundamentally leverage the already parallelized L1 virtual machine to achieve some level of “off-chain execution + on-chain settlement.”

Therefore, to understand the technical principles of parallel EVM, it is necessary to break it down: first, understand what a virtual machine (VM) is, and then understand what parallel execution entails.

2.1 Virtual machine

In computer science, a virtual machine refers to the virtualization or emulation of a computer system.

There are two types of virtual machines: system virtual machines, which can virtualize a single physical machine into multiple machines running different operating systems, thereby improving resource utilization; and process virtual machines, which provide an abstraction for certain high-level programming languages, allowing computer programs written in these languages to run in a platform-independent manner on different platforms.

The JVM is a process virtual machine designed for the Java programming language. Programs written in Java are first compiled into Java bytecode (an intermediate state of binary code), which is then interpreted by the JVM: the JVM sends the bytecode to an interpreter, which translates it into machine code for different machines, and then runs it on the machine.

Blockchain virtual machines are a type of process virtual machine. In the context of blockchain, a virtual machine refers to the virtualization of a distributed state machine used for distributed execution of contracts, running dApps. Analogous to the JVM, the EVM is a process virtual machine designed for the Solidity language, where smart contracts are first compiled into opcode bytecode, then interpreted by the EVM.

Emerging public chains beyond Ethereum often adopt virtual machines based on WASM or eBPF bytecode. WASM is a compact, fast-loading, portable bytecode format based on sandbox security mechanisms. Developers can write smart contracts in various programming languages (C, C++, Rust, Go, Python, Java, or even TypeScript), compile them into WASM bytecode, and execute them. Smart contracts executed on the Sei blockchain use this bytecode format.

eBPF originated from BPF (Berkeley Packet Filter), initially used for efficient filtering of network packets, and evolved into eBPF, offering a richer instruction set.

It is a revolutionary technology that allows dynamic intervention and modification of operating system kernel behavior without altering the source code. Later, this technology moved beyond the kernel, leading to the development of the user-space eBPF runtime, which is highly performant, secure, and portable. Smart contracts executed on Solana are compiled into eBPF bytecode and run on its blockchain network.

Other L1 public chains like Aptos and Sui use the Move smart contract programming language, compiling into proprietary bytecode executed on the Move virtual machine. Monad has designed its own virtual machine compatible with EVM opcode bytecode (Shanghai fork).

2.2 Parallel execution

Parallel execution is a technique that leverages the advantages of multi-core processors to handle multiple tasks simultaneously, thereby increasing the system’s throughput. It ensures that the results of transactions are identical to those obtained when transactions are executed serially.

In blockchain networks, TPS (Transactions Per Second) is commonly used as a technical indicator to measure processing speed. The mechanism of parallel execution is complex and poses a challenge to developers’ technical skills, making it difficult to explain. Here, we will use the example of a “bank” to explain what parallel execution is.

(1) First, what is serial execution?

Scenario 1: If we view the system as a bank and the task-processing CPU as a counter, then serial task execution is akin to this bank having only one counter available for service. In this case, customers (tasks) coming to the bank must form a long line and handle their business one by one. For each customer, the counter staff must repeat the same actions (execute instructions) to service the customer. Customers must wait their turn, which leads to extended transaction times.

(2) So, what is parallel execution?

Scenario 2: If the bank sees that it is overcrowded, it might open several counters to handle business, with four clerks working at the counters simultaneously. This increases the speed roughly four times compared to the original, and the time customers spend in line is also reduced to about one-fourth of the original. Thus, the speed of handling business at the bank is increased.

(3) What error occurs if no protections are in place and two people simultaneously transfer money to another person?

Scenario 3: Let’s consider A, B, and C, who have 2 ETH, 1 ETH, and 0 ETH in their accounts, respectively. Now, A and B each want to transfer 0.5 ETH to C. In a system that executes transactions serially, no issues would occur (the left arrow “<=” indicates reading from the ledger, and the right arrow “=>” indicates writing to the ledger, the same below):

However, parallel execution is not as simple as it seems. There are many subtle details that can lead to serious errors if not handled carefully. If the transactions of A and B transferring to C are executed in parallel, the sequence of steps can result in inconsistent outcomes:

Parallel Task 1 executes the transfer from A to C, and Parallel Task 2 executes the transfer from B to C. The steps marked with an asterisk are problematic: because the tasks are executed in parallel, in Step 2, the balance calculation made by Parallel Task 1 has not yet been written to the ledger. By Step 3, Parallel Task 2 reads C’s account balance (which is still 0) and performs an erroneous balance calculation based on this in Step 5. Then, in the ledger update operation in Step 6, it incorrectly updates the account balance, which was already updated to 0.5 in Step 4, back to 0.5 again. This results in C’s account balance being only 0.5 ETH, despite both A and B having transferred 0.5 ETH each, effectively causing the other 0.5 ETH to vanish.

(4) If no protections are in place, two tasks that do not depend on each other can execute in parallel without errors

Scenario 4: Parallel Task 1 executes a transfer of 0.5 ETH from A (balance 2 ETH) to C (balance 0 ETH), and Parallel Task 2 executes a transfer of 0.5 ETH from B (balance 1 ETH) to D (balance 0 ETH). It is evident that there is no dependency between these two transfer tasks. Regardless of how the steps of the two tasks are interlaced, they will not encounter the problems described above:

From the comparison of these scenarios, it can be analyzed that as long as there is a dependency between tasks, errors in state updates may occur during parallel execution; otherwise, no errors will occur. A task (transaction) is considered to have a dependency relationship if it meets one of the following two conditions:

1. A task writes to an output address that another task reads from as an input address;
2. Two tasks output to the same address.

This issue is not unique to decentralized systems. Any scenario involving parallel execution can suffer from data inconsistencies due to unprotected access to shared resources (like the “ledger” in the bank example or shared memory in computer systems) between multiple dependent tasks, known as data races.

The industry has proposed three mechanisms to resolve the data race issues in parallel execution: message-passing mechanisms, shared memory mechanisms, and strict state access list mechanisms.

2.3 Message Passing Mechanism

Scenario 5: Consider a bank with four service counters operating simultaneously for customers. Each teller at these counters is given a unique ledger, which only they can modify. This ledger records the account balances of the customers they serve.

Whenever a teller handles a transaction, if the customer’s information is available in their ledger, they proceed directly. If not, they call out to other tellers to inform them of the customer’s transaction needs, and the hearing teller takes over the task.

This exemplifies the principle of the message passing model. The Actor model is a type of message passing model, where each entity handling transactions is an actor (teller), each with access to their private data (the exclusive ledger). Accessing someone else’s private data can only be achieved through sending messages.

Advantages of the Actor Model:

Each actor has access only to their private data, thus avoiding race condition issues.

Disadvantages of the Actor Model:

Each actor can only execute tasks sequentially. In certain scenarios, this does not utilize the advantages of parallelism. For instance, if tellers No. 2, 3, and 4 simultaneously send messages to ask teller No. 1 about customer A’s account balance, teller No. 1 can only process these requests one at a time, even though these could be handled in parallel.

There is no global view of the current system status. If the system operations are complex, it becomes challenging to understand the overall situation, locate, and fix bugs.

2.4 Shared Memory Mechanism

2.4.1 Memory Lock Model

Scenario 6: Imagine a bank with only one large ledger that records the account balances of all its customers. Next to the ledger, there is only one pen available for making modifications to it.

In this scenario, the competition between four bank tellers becomes a race of speed: one teller grabs the pen first (locks it) and starts to modify the ledger, while the other three must wait. Once the teller is done and puts the pen down (unlocks it), the next three tellers rush to grab the pen. This cycle repeats, exemplifying the memory lock model.

A memory lock allows tasks running in parallel to lock a shared resource before accessing it. After the resource is locked, other tasks must wait until it has been modified and unlocked before they can lock and access it again.

The read-write lock model offers a more refined approach, allowing multiple parallel tasks to add read locks to a shared resource and access its data multiple times. During this, modifications are not allowed; however, a write lock can be applied by only one at a time, and once applied, it grants exclusive access to the resource holder.

Blockchain platforms like Solana, Sui, and Sei v1 use a shared memory model based on memory locks. This mechanism might seem simple, but it is complex to implement and requires developers to have sophisticated skills in multithreading programming. Carelessness can lead to various bugs:

Scenario 1: A task locks a shared resource but crashes during execution, leaving the resource inaccessible.

Scenario 2: A task locks a resource but ends up locking it again due to nested business logic, resulting in a deadlock where it waits on itself.

The memory lock model is prone to issues such as deadlocks, livelocks, and starvation:

1. Deadlock occurs when multiple parallel tasks vie for multiple shared resources, with each task holding a part of them and waiting for others to release their parts.
2. Livelock happens when parallel tasks detect that other tasks are active and voluntarily relinquish their hold on shared resources, leading to a continuous cycle of yielding.
3. Starvation occurs when high-priority tasks consistently gain access to shared resources, while lower-priority tasks endure prolonged waiting.

2.4.2 Optimistic Parallelism

Scenario 7

In a bank, four tellers each have the ability to independently access and modify the ledger during transactions, regardless of whether other tellers are using the ledger. When using the ledger, each teller applies a personal label to the entries they access or modify. After completing a transaction, they review the entries again; if they find a label that is not their own, it indicates that the entry has been modified by another teller, and the transaction must be voided and processed again.

This exemplifies the basic principle of optimistic parallelism. The core idea of optimistic parallelism is to initially assume that all tasks are independent. Tasks are executed in parallel, and then each task is validated. If a task fails validation, it is re-executed until all tasks are completed. Suppose there are eight parallel tasks performed in an optimistic parallelism manner, needing access to two shared resources, A and B.

During Phase 1, tasks 1, 2, and 3 are executed in parallel. However, tasks 2 and 3 access shared resource B simultaneously, causing a conflict, thus task 3 is rescheduled for the next phase. In Phase 2, tasks 3 and 4 both access resource B, resulting in task 4 being rescheduled, and so on, until all tasks are completed. As can be seen, tasks that encounter conflicts are repeatedly re-executed.

Optimistic Parallelism Model

The optimistic parallelism model employs a multi-version in-memory data structure to record each written value and its version information (similar to the labels used by bank tellers).

The execution of each parallel task is divided into two phases: execution and validation. During the execution phase, all data read and write actions are recorded, forming a read set and a write set. In the validation phase, the read set and write set are compared with the multi-version data structure. If the comparison reveals that the data is not the latest, the validation fails.

The optimistic parallelism model originated from Software Transaction Memory (STM), a lock-free programming mechanism in the database field. As blockchain networks inherently maintain a definite order of transactions, this concept has been introduced and evolved into the Block-STM mechanism. Blockchain platforms like Aptos and Monad have adopted Block-STM as their parallel execution mechanism.

It is worth mentioning that the Sei public chain, in its upcoming v2 version, has abandoned the original memory lock model in favor of the optimistic parallelism model. Block-STM executes transactions at an extremely fast pace; in a test environment, Aptos reached an impressive transaction execution speed of 160k transactions per second (tps), which is 18 times faster than sequential transaction processing.

Block-STM delegates the complex transaction execution and validation to the core development team, allowing developers to write smart contracts as easily as if they were programming in a sequential execution environment.

2.5 Strict State Access List

Message passing and shared memory mechanisms are based on the account/balance data model, which records the balance information of each account on the blockchain. It’s akin to how a bank’s ledger shows that Customer A has a balance of 1,000 units and Customer B has a balance of 600 units. Transactions are processed simply by updating the balance status of the accounts.

Alternatively, one could also record the details of each transaction at the time of the transaction, creating a transaction ledger. This ledger can be used to calculate the account balances. For example:

• Customer A opens an account and deposits 1,000 units;
• Customer B opens an account (0 units);
• Customer A transfers 100 units to Customer B.

By reading and calculating the ledger, it can be determined that Customer A has a balance of 900 units, and Customer B has a balance of 100 units.

UTXO (Unspent Transaction Output) is similar to this transaction ledger data model. It represents a method of denoting digital currency in Bitcoin, the first-generation blockchain. Each transaction has inputs (how the funds were received) and outputs (how the funds were spent), and UTXOs can be understood simply as the receipts of funds that have not yet been spent.

For example, if Customer A has 6 BTC and transfers 5.2 BTC to Customer B, leaving 0.8 BTC, from the UTXO perspective it looks like this: The 6 UTXOs valued at 1 BTC each are destroyed, and B receives a new UTXO worth 5.2 BTC, while A receives a new UTXO worth 0.8 BTC as change. Thus, 6 UTXOs are destroyed to create 2 new UTXOs.

The inputs and outputs of a transaction are linked together and use digital signatures to record ownership information, thus forming the UTXO model. Blockchains that adopt this data model need to sum all UTXOs for a particular account address to determine the current account balance. The Strict State Access List (SSAL) is based on the UTXO model and enables parallel execution. It pre-calculates the account addresses each transaction will access, forming an access list.

The access list serves two purposes:

1. Transaction Security Assessment: If a transaction accesses an address not on the access list, the execution fails.
2. Parallel Execution of Transactions: According to the access list, transactions are grouped into several sets. Since there are no dependencies (no intersections) between the sets on the access list, these transaction sets can be executed in parallel.

3. Industry Growth Drivers

From an intrinsic perspective, the development of anything typically progresses from inception to refinement, and humanity’s quest for speed is eternal. To address the execution speed issues in blockchain networks, a variety of solutions, both on-chain and off-chain, have emerged. Off-chain solutions, such as rollups, have been fully recognized for their value, while the narrative of parallel Ethereum Virtual Machines (EVM) still offers significant exploration opportunities.

Historically, with the SEC’s approval of a spot Bitcoin ETF and the upcoming Bitcoin halving event, coupled with potential interest rate cuts by the Federal Reserve, cryptocurrencies are expected to enter a significant bull market. The robust growth of the industry requires blockchain network infrastructures capable of handling higher throughput as a solid foundation.

In terms of resource management, traditional blockchain networks process transactions serially, a straightforward but inefficient method that wastes processor resources. In contrast, parallel blockchains make full use of computing resources, significantly extracting the performance potential of multicore processors, thus enhancing the overall efficiency of the blockchain networks.

Regarding industry development, although various technological and business model innovations are continuously emerging, the potential for growth in Web3 remains largely untapped. Centralized networks can handle over 50,000 messages per second, send 3.4 million emails, complete 100,000 Google searches, and support tens of thousands of players online simultaneously, feats not yet achievable by decentralized networks. For decentralized systems to compete and carve out their territory, continual optimization of parallel execution mechanisms and enhancement of transaction throughput are essential.

From the perspective of decentralized applications, attracting more users requires significant efforts in improving the user experience. Performance optimization is one key direction for enhancing user experience. For DeFi users, meeting the demands for high transaction speed and low fees is crucial. For GameFi users, real-time interaction is necessary. All these requirements are supported by the robustness of parallel execution.

4.Existing problems

The “blockchain trilemma” states that decentralization, security, and scalability can only satisfy two out of the three attributes simultaneously. Since “decentralization” is an immovable pillar, improving “scalability” implies a reduction in “security.” Since code is written by humans, it is prone to errors. The technical complexity introduced by parallel computing provides a breeding ground for potential security vulnerabilities.

Multithreaded programming is particularly challenging due to two main issues: first, it is prone to race conditions due to improper handling of various complex concurrent control operations; second, it can lead to crashes by accessing invalid memory addresses, which might even lead to buffer overflow vulnerabilities exploitable by attackers.

There are at least three perspectives from which to assess a project’s security:

1.Team Background: Teams with experience in systems programming are adept at multithreaded programming and can address 80% of complex issues. Systems programming generally involves the following areas:

• Operating systems
• Various device drivers
• File systems
• Databases
• Embedded systems
• Cryptography
• Multimedia codecs
• Memory management
• Networking
• Virtualization
• Gaming
• Advanced programming languages

2.Code Maintainability: Writing maintainable code follows a clear methodology, such as having a clear architectural design, utilizing design patterns to implement code reusability, employing test-driven development techniques to write ample unit tests, and eliminating redundant code through thoughtful refactoring.

3.Programming Language Used: Some cutting-edge programming languages are designed with a strong emphasis on memory safety and high concurrency. Compilers check the code for concurrent issues or potential access to invalid memory addresses, resulting in compilation failure if detected, thus forcing developers to write robust code.

The Rust language is exemplary in this regard, which is why we see that the majority of parallel blockchain projects are developed in Rust. Some projects even borrow from Rust’s design to implement their own smart contract languages, such as Fuel’s Sway language.

5. Target Arrangement

5.1 Based on optimistic parallelization model

5.1.1 From memory locks to optimistic parallelism

Sei is a general-purpose public blockchain based on open-source technology, established in 2022. The founders are alumni of the University of California, Berkeley, and other team members also have backgrounds from prestigious universities abroad.

Sei has received funding in three rounds: a seed round of $5 million, a first strategic financing round of $30 million, and a second strategic financing round where the amount was not disclosed. The Sei Network has also raised a total of $100 million in funds to support its ecosystem development.

In August 2023, Sei launched on its mainnet, claiming to be the fastest L1 public blockchain, capable of processing 12,500 transactions per second, with finality achieved in just 380 ms. Currently, it has a market capitalization of nearly $2.2 billion.

Presently, the Sei ecosystem comprises 118 projects, primarily focusing on DeFi, infrastructure, NFTs, gaming, and wallets. The community currently has 650,000 members on Twitter, 600,000 on Discord, and 40,000 on Telegram.

At the end of November 2023, Sei announced on its official blog that it would initiate the most significant version upgrade since the mainnet launch in the first half of 2024: Sei v2. Sei v2 is touted as the first parallel EVM blockchain. This version upgrade will introduce the following new features:

• Backward compatibility for EVM smart contracts: Developers can migrate and deploy EVM smart contracts without modifying the code.
• Reusability for common tools/applications such as Metamask.
• Optimistic parallelization: Sei v2 will abandon the shared access mechanism of memory locks in favor of optimistic parallelization.
• SeiDB: Optimization of the storage layer.
• Support for seamless interoperability between Ethereum and other chains.

Originally, Sei Network’s transaction parallel execution was based on a memory lock model. Before execution, all dependencies between pending transactions were resolved and a DAG was generated, then based on the DAG, the execution order of transactions was precisely arranged. This method increased the mental burden on contract developers because they had to incorporate the logic into the code during development.

As introduced in the technical principles section above, with the adoption of optimistic parallelization in the new version, developers can now write smart contracts as if they were writing sequentially executed programs. Complex mechanisms such as scheduling, execution, and verification of transactions are handled by the underlying modules. The core team’s optimization proposal design also introduced a further enhancement of parallel execution capabilities through pre-filling dependencies.

Specifically, this involves introducing a dynamic dependency generator that analyzes write operations of transactions before execution and pre-fills them into a multi-version memory data structure, optimizing potential data contention. After analysis, the core team concluded that while such an optimization mechanism is not advantageous in the best-case scenario for transaction processing, it significantly improves execution efficiency in the worst-case scenario.

5.1.2 Potential Disruptor in the L1 Track: Monad

If you missed the development of the public blockchains mentioned above, then you definitely shouldn’t miss out on Monad. It is touted as a potential disruptor in the L1 track.

Monad was founded by two senior engineers from Jump Crypto in 2022. The project completed a $19 million seed funding round in February 2023. In March 2024, Paradigm led negotiations for a funding round of over $200 million for Monad. If successful, this would be the largest cryptocurrency financing since the beginning of the year.

The project has already achieved the milestone of launching an internal testnet and is working towards the next step of opening a public testnet.

Monad is highly favored by capital for two prominent reasons: one is its solid technical background, and the other is its proficiency in marketing hype. The core team of Monad Labs consists of 30 members, all of whom have decades of deep experience in high-frequency trading, kernel drivers, and financial technology, and extensive development experience in distributed systems.

The project’s daily operations are also very “grounded”: continuously engaging in “magical marketing” with its 200,000 followers on Twitter and 150,000 members on Discord. For example, hosting weekly meme contests, collecting various quirky purple animal emojis or videos from the community, to perform “spiritual dissemination.”

Monad’s vision is to become a smart contract platform for developers, bringing extreme performance enhancements to the Ethereum ecosystem. Monad introduces two mechanisms to the Ethereum Virtual Machine: one is superscalar pipelining, and the other is an improved optimistic parallel mechanism.

Superscalar pipelining parallelizes the execution phase of transactions. An illustrative example given in the official documentation is washing clothes, which is similar to how blockchain processes transactions, also completed in several stages. The traditional method processes each pile of dirty clothes through washing, drying, folding, and storing before moving on to the next pile.

Superscalar pipelining, on the other hand, begins washing the second pile of clothes while the first pile is drying. As the first pile is being folded, the second and third piles are respectively drying and washing, thus keeping every stage active.

The optimistic parallel mechanism parallelizes the execution of transactions. Monad uses optimistic parallelism for parallel execution. It also developed its own static code analyzer to predict dependencies between transactions, scheduling subsequent transactions only after the prerequisite dependent transactions have been executed, thereby significantly reducing transaction re-execution due to failed validations.

Currently, its performance reaches 10,000 TPS and it can produce blocks within one second. As the project progresses, the core team will continue to explore more optimization mechanisms.

5.1.3 Highly Decentralized L1 Project: Canto

Established in 2022, Canto is a highly decentralized L1 project built on the Cosmos SDK. It operates without an official foundation, does not engage in pre-sales, is not affiliated with any organization, does not seek financing, and is entirely driven by the community. Even the core team remains anonymous, working in a loosely organized manner.

Though it is an EVM-compatible general blockchain, Canto’s primary vision is to become an accessible, transparent, decentralized, and free DeFi value platform. Through extensive research into the sector, it has been found that any healthy DeFi ecosystem comprises three fundamental elements:

1. Decentralized exchanges (DEX) like Uniswap and Sushiswap;
2. Lending platforms like Compound and Aave;
3. Decentralized tokens like DAI, USDC, or USDT.

However, traditional DeFi ecosystems ultimately share a common fate: they issue governance protocol tokens, whose value depends on how much usage fee the ecosystem can extract from its future users—the more extracted, the greater the value. This is akin to each DeFi protocol being a privately owned parking lot that charges by the hour—the more it’s used, the higher its valuation.

Canto takes another approach:Build free public infrastructure for DeFi (Free Public Infrastructure),Make yourself a free parking lot for its ecological projects.

The infrastructure consists of 3 protocols: the decentralized exchange Canto DEX, the pooled lending platform Canto Lending Market (CLM) forked from Compound v2, and the stable currency NOTE that can be loaned from CLM through collateral assets.

Canto has adopted a novel approach: building free public infrastructure targeted at DeFi, positioning itself as a free parking lot available for its ecosystem projects to use at no cost.

The infrastructure consists of three protocols: the decentralized exchange Canto DEX, the pooled lending platform Canto Lending Market (CLM) forked from Compound v2, and the stablecoin NOTE, which can be borrowed from CLM using collateralized assets.

Canto DEX operates perpetually as a non-upgradable, governance-free protocol. It neither issues its tokens nor charges additional fees. This design prevents various rent-seeking behaviors within the ecosystem’s DeFi applications, avoiding predatory zero-sum games.

The governance of the lending platform CLM is controlled by stakeholders, who fully benefit from the ecosystem’s growth and, in turn, create the best environment for developers and DeFi users, motivating them to continually contribute. The interest generated from loans issued in NOTE is paid to the borrowers, with the protocol not taking any cut.

For developers, Canto has introduced the Contract Secured Revenue model, which allocates a certain percentage of fees generated from on-chain interactions with contracts to the developers. This series of business model innovations by Canto, termed “killing three birds with one stone,” fosters a constructive and thriving ecosystem by providing open, free financial infrastructure.

By various means, Canto incentivizes ecosystem developers and users to join and continually enrich the ecosystem. By tightly controlling the “minting rights,” Canto creates possibilities for cross-application liquidity among various decentralized applications. As the ecosystem prospers, its tokens increase in value. After the CSR proposal was approved by community voting on January 26, 2024, the $CANTO token experienced a price surge.

Following these series of business model innovations, on March 18, 2024, Canto announced its latest round of technical iterations on its official blog.

In addition to adopting a new version of the Cosmos SDK and integrating new technologies to reduce storage access bottlenecks, Canto will also upgrade to parallel EVMs: introducing optimistic parallelization through the implementation of Cyclone EVM.

The Cosmos SDK used by Canto divides transaction processing into three stages: Proposal, Voting, and Finalization. The ProcessProposal sub-process during Voting is responsible for the parallel execution of transactions. The parallel execution engine handles the execution, while the conflict detection engine verifies the validity of transactions.

If a transaction is invalid, it is sent back to the execution engine for re-execution; if valid, it is committed to the subsequent processing flow. It is believed that this round of technological upgrades will make Canto’s tokens even more eye-catching.

5.2 Based on Strict State Access Lists: Fuel

Fuel, composed of the virtual machine FuelVM, the contract development language Sway inspired by Rust, and its associated toolchain, is a custom-built modular “Ethereum rollup operating system.” The Fuel project was established in 2019, and in December 2020, Fuel Labs launched the first optimistic rollup execution layer on Ethereum, Fuel v1. After more than three years of development, the project is finally set to launch its mainnet in the third quarter of 2024.

Fuel completed funding rounds of $1.5 million and $80 million in 2021 and 2022, respectively. The core team consists of over 60 engineers, with founder John Adler also being a co-founder of the data availability solution Celestia Labs and one of the earliest proponents of the optimistic rollup approach. In terms of operations, the project has 270,000 members on Twitter and 390,000 on Discord.

Executing transactions one by one on the blockchain incurs gas fees and competes for valuable block space, which is slow. Naturally, various scaling solutions come to mind, such as batch processing of transactions that are then packaged together and settled on the chain to speed up execution.

A rollup is a scaling solution that operates outside of L1, executing transactions in batches off-chain and then sending transaction data or execution proofs to L1. This ensures security through the DA layer and settles transactions. There are two main types of rollups: optimistic and zero-knowledge (ZK).

Optimistic rollups assume transactions are valid and produce a fraud proof to revert malicious or incorrect transactions on L1 when detected. ZK rollups generate proofs of transaction validity through complex calculations without exposing transaction details, and publish them to L1 to demonstrate that the rollup has executed the transactions correctly. Thus, rollups are a blockchain execution layer technology.

Although rollups speed up transaction execution, most existing implementations are designed for monolithic blockchains. Developers have to make various compromises technically, which limits the full performance of rollups. With the new trend towards modular blockchains, there has been no suitable rollup solution in the industry. Fuel was created to fill this gap.

Fuel uses the UTXO data model, which has the advantage that its transaction outputs have only two states: either spent, permanently recorded in the block’s transaction history, or unspent, available for future transactions. This minimizes the state data stored on each node in the chain. Based on this, Fuel checks the account information accessed by each transaction before execution, identifying dependencies, and schedules transactions with no dependencies to be executed in parallel, enhancing the throughput of transaction processing.

5.3 Cross-chain Integration of L1 Chains with L2 Solutions: Neno, Eclipse, and Lumio

L2 solutions share a common feature: they combine the capabilities of two types of virtual machines to enhance the speed of transaction execution. Specifically, this involves using parallel L1s to execute transactions while maintaining compatibility with other chains (dual virtual machine support). However, the compatibility mechanisms adopted by different projects vary. In this respect, Neon, Eclipse, and Lumio are particularly representative.

Neon claims to be the first parallel EVM project in the Solana ecosystem, allowing developers to seamlessly migrate Ethereum ecosystem projects to the Solana ecosystem. Eclipse is another protocol in the Solana ecosystem compatible with EVM, built with a modular architecture. Among these three projects, only Neon has issued its own token, achieving a circulation market value of over 78 million.

The other two projects are still in relatively early stages. Lumio combines Aptos and Ethereum to create an optimistic rollup L2 protocol, efficiently executing Ethereum applications at the speed of Move VM.

In terms of financing, Neon completed fundraising of $40 million in November 2021 and $5 million in June 2023, totaling $45 million. Eclipse completed fundraising of $6 million in August 2022, $9 million in September 2022, and $50 million in March 2024, totaling $65 million. Lumio has not yet raised funds.

None of the three projects have yet to form a large-scale application ecosystem, but they have tens to hundreds of thousands of followers or members on major social media platforms, indicating significant community activity.

From a mechanism perspective, Neon is an EVM emulator on the Solana network, running as a smart contract. Developers can use languages such as Solidity and Vyper to write dApp applications, and can use Ethereum toolchains and compatible Ethereum RPC APIs, accounts, signatures, and token standards, such as MetaMask, Hardhat, and Remix. Meanwhile, they enjoy the benefits of low fees, high transaction execution speed, and parallel processing capabilities brought by Solana.

Ethereum transactions sent from the Ethereum dApp frontend are converted by a proxy into Solana transactions, then executed in the emulator, modifying the chain state. It’s like the game emulators we often use on PCs, which allow us to play exclusive games from consoles like Switch and PlayStation on desktop computers. Neon enables Ethereum developers to run Ethereum applications on the Solana network.

Eclipse adopts a different implementation approach: executing transactions through SVM and settling transactions through EVM. Eclipse utilizes a modular blockchain architecture, where it only handles transaction execution and outsources other responsibilities, forming a unified solution through modular combinations.

For example, it uses Celestia to manage data availability and Ethereum to execute and settle transactions. Eclipse ensures execution speed through SVM and security through Ethereum’s validation and settlement.

Lumio employs a design philosophy independent of the execution and settlement layers, supporting various virtual machines and compatible with multiple L1/L2 networks: Ethereum, Aptos, Optimism, Avalanche, zkSync, and others. It executes transactions through Move VM and settles them through EVM, thereby connecting the Ethereum and Aptos ecosystems.

However, Lumio’s ambitions do not stop there. Its vision is to provide cross-virtual machine calls to achieve multi-blockchain liquidity connectivity at the highest speed and lowest rates.

The above are the main projects currently related to the parallel EVM narrative, as shown in the following diagram.

6. Conclusion and Outlook

People often liken Bitcoin to a “distributed ledger” and Ethereum to a “distributed state machine”. If we consider all nodes operating a blockchain network as one computer, then parallel blockchains fundamentally study how to maximize the utilization of this “computer’s” processing resources to achieve the fastest execution speeds.

This is an inevitable evolution in the history of computing technology, akin to the development from single-core to multi-core processors, and operating systems evolving from single-user single-thread to multi-user multi-threading. This has significant implications for the continuous development of the industry.

The technical principles of parallel EVM can be broken down into two components: the virtual machine and the parallel execution mechanism. In the context of blockchain, the virtual machine integrates a set of instructions for distributedly executing contracts and running dApps. The parallel execution mechanism primarily focuses on maximizing transaction execution speeds while ensuring the accuracy of transaction outcomes.

On one hand, parallel EVMs share common technical principles. Firstly, the optimistic parallelization model is a consensus for L1 public blockchains. However, this does not mean that the memory lock model is useless. Technological superiority does not exist; rather, it’s the skill level of developers that varies.

Secondly, projects like Fuel firmly believe that off-chain scaling mechanisms can only achieve their maximum performance after modularization. Finally, numerous L2 projects seek to enhance transaction throughput by integrating with parallel L1 public blockchains, thus achieving cross-ecosystem scaling capabilities.

On the other hand, parallel blockchains have their unique technical achievements. Even when adopting the same parallel execution model, different teams have implemented varying architectural design patterns, data models, or preprocessing mechanisms. Technological exploration is endless, and different projects develop distinct technologies based on different visions to push practice to higher levels.

Looking forward, more L1 and L2 projects will join the competition in parallel EVMs. The L1 track will see a comprehensive competition between parallel EVM and non-EVM camps in processor resources, storage resources, network resources, file system resources, and device resources. This competition will also give rise to new narratives related to performance enhancement. Meanwhile, the L2 track will evolve towards blockchain virtual machine simulators or modular blockchains.

In the future, infrastructure optimizations will bring faster speeds, lower costs, and higher efficiency. Web3 entrepreneurs can boldly innovate business models to create better decentralized product experiences worldwide, further flourishing the industry ecosystem. For Web3 investors, focusing solely on technology is insufficient.

When choosing investment targets, investors should consider narratives, market capitalization, and liquidity, selecting projects with “good narratives,” “low market capitalization,” and “high liquidity.” Then, they should delve into the business, team background, economic model, marketing, and ecological projects, thereby uncovering potential projects and finding suitable investment avenues.

Parallel EVMs are still in the early stages of development, with projects like Neon, Monad, Canto, Eclipse, Fuel, and Lumio in the phase where their value has not been fully realized. Particularly, Monad, Canto, and Fuel.

From Monad’s marketing style, not only is it noteworthy on its own, but the meme projects within its ecosystem are also worth paying attention to, which may lead to get-rich-quick stories driven by hype. Canto meets the conditions of “good narrative” and “low market valuation,” but whether it is a good investment target still requires thorough examination of its various indicators. Fuel represents a popular direction in the development of modular blockchains and may also give rise to new investment opportunities, all of which are directions worthy of our attention.

statement:

1. This article is reproduced from Gryphsis Academy), the original title is “Ten Thousand Words Interpretation of Parallel EVM: How to Break through the Blockchain Performance Bottleneck?”, the copyright belongs to the original author [@leesper6], if you have any objection to the reprint, please contact Gate Learn Team, the team will handle it as soon as possible according to relevant procedures.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team and are not mentioned inGate.ioThe translated article may not be reproduced, distributed or plagiarized.