• Student author: @leesper6
• Supervising teacher: @CryptoScott_ETH
• First release date: April 5, 2024

1. Parallel EVM is a new narrative that emerged after the development of on-chain transaction volume to a certain extent. Parallel EVM is mainly divided into monolithic blockchain and modular blockchain. Monolithic blockchain is further divided into L1 and L2. Parallel L1 public chains are divided into two major camps: EVM and non-EVM. Currently, the narrative of parallel EVM is in the early stage of development.
2. The technical implementation path of parallel EVM mainly includes two aspects: virtual machine and parallel execution mechanism. In the context of blockchain, a virtual machine refers to a virtual process virtual machine for executing contracts on a distributed state machine.
3. Parallel execution refers to leveraging the advantages of multi-core processors to execute multiple transactions at the same time as much as possible, while ensuring that the final state is consistent with the result of serial execution.
4. The parallel execution mechanism is divided into three major categories: message passing, shared memory, and strict state access list. Shared memory is further divided into memory lock model and optimistic parallelization. Both mechanisms increase the complexity of the technology.
5. The narrative of parallel EVM has both inherent driving factors for industry growth and requires practitioners to pay close attention to potential security issues.
6. Each target project of parallel EVM has provided parallel execution ideas in different ways, with both technical commonalities and their own unique contributions.

Performance has become a bottleneck for further industry development. Blockchain networks have created a new decentralized trust foundation for individuals and businesses to conduct transactions.

The first-generation blockchain network represented by Bitcoin pioneered a new mode of decentralized electronic currency transactions through distributed accounting. The second-generation blockchain network represented by Ethereum fully leveraged imagination and proposed decentralized applications (dApps) through a distributed state machine.

Since then, the blockchain network has embarked on its own rapid development history for more than a decade, giving birth to numerous innovations in technology or business models, from Web3 infrastructure to various tracks represented by DeFi, NFT, social networks, and GameFi. The vigorous development of the industry requires continuous attraction of new users to participate in the ecological construction of decentralized applications, which in turn imposes higher requirements on product experience.

As a "unprecedented" new product form, Web3 not only needs to innovate in meeting user needs (functional requirements) but also needs to consider how to achieve a balance between security and performance (non-functional requirements). Since its inception, various solutions have been proposed to address performance issues.

These solutions can be roughly divided into two categories: on-chain scaling solutions, such as sharding and directed acyclic graph (DAG); and off-chain scaling solutions, such as Plasma, Lightning Network, sidechains, and Rollups. However, these still cannot keep up with the rapid growth of on-chain transactions.

Especially after experiencing the DeFi Summer in 2020 and the continuous outbreak of inscriptions in the Bitcoin ecosystem at the end of 2023, the industry urgently needs new performance improvement solutions to meet the requirements of "high performance, low fees". Parallel blockchains were born in such a background.

The narrative of parallel EVM marks the formation of a competitive situation between two strong forces in the field of parallel blockchains. Ethereum processes transactions in a serial manner, where transactions are executed one after another in sequence, resulting in low resource utilization. Transforming the serial processing method into parallel processing would bring about a huge performance improvement.

Ethereum's competitors such as Solana, Aptos, and Sui all have inherent parallel processing capabilities and have also developed their ecosystems well, with token market capitalizations reaching 45 billion, 3.3 billion, and 1.9 billion US dollars, respectively, forming the parallel non-EVM camp. Faced with the challenge, the Ethereum ecosystem is also unwilling to show weakness, and has come forward to empower EVM, forming the parallel EVM camp.

Sei has boldly claimed in its v2 upgrade proposal to become the "first parallel EVM blockchain", with a current market capitalization of 21 billion US dollars and even greater potential for development. The currently highly marketed parallel EVM new public chain, Monad, is favored by capital and its potential should not be underestimated. The L1 public chain Canto, with a market capitalization of 170 million US dollars and its own free public infrastructure, has also announced its parallel EVM upgrade proposal.

In addition, a number of early-stage L2 projects are also providing cross-ecosystem performance improvements by integrating the capabilities of multiple L1 chains. Apart from Neon, which has a circulating market capitalization of 69 million US dollars, other projects lack relevant data. It is believed that more L1 and L2 projects will join the parallel blockchain battlefield in the future.

Not only does the narrative of parallel EVM have great market growth potential, but the parallel blockchain sector to which the narrative of parallel EVM belongs also has great market growth potential, thus having broad market prospects.

Currently, the overall circulating market capitalization of L1 and L2 is 752.123 billion US dollars, and the circulating market capitalization of parallel blockchains is 52.539 billion US dollars, accounting for only about 7%. Among them, the circulating market capitalization of projects related to the narrative of parallel EVM is 2.339 billion US dollars, accounting for only 4% of the circulating market capitalization of parallel blockchains.

The industry generally divides blockchain networks into 4 layers:

1. Layer 0 (Network): The underlying network of the blockchain, handling basic network communication protocols.
2. Layer 1 (Infrastructure): Decentralized networks that rely on various consensus mechanisms to verify transactions.
3. Layer 2 (Expansion): Various second-layer protocols that rely on Layer 1, aiming to address various limitations of Layer 1, especially scalability.
4. Layer 3 (Applications): Built on Layer 2 or Layer 1, used to construct various decentralized applications (dApps).

The narrative of parallel EVM projects is 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 there is still a lot of room for development in the parallel EVM L1 public chain ecosystem compared to the Ethereum ecosystem.

The DeFi track has a demand for "high speed and low fees," and the gaming track has a demand for "strong real-time interaction," both of which have certain requirements for execution speed. Parallel EVM will inevitably bring better user experience to these projects and drive the industry into a new stage of development.

L1 is a new public chain with inherent parallel execution capability and is a high-performance infrastructure. In this camp, projects represented by Sei v2, Monad, and Canto have independently designed parallel EVM, compatible with the Ethereum ecosystem, and provide high throughput transaction processing capabilities.

L2 provides cross-ecosystem collaboration and scaling capabilities by integrating the capabilities of other L1 chains, which is the essence of rollups. In this camp, Neon is an EVM simulator on the Solana network, and Eclipse uses Solana to execute transactions but settles on the EVM. Lumio is similar to Eclipse, but it replaces the execution layer with Aptos.

In addition to the above monolithic blockchain solutions, Fuel has proposed its own modular blockchain approach. In its second version, it will position itself as an Ethereum rollup operating system, providing more flexible and thorough modular execution capabilities.

Fuel focuses on executing transactions and outsources the rest to one or more independent layers of blockchains, enabling more flexible combinations: it can be an L2, an L1, or even a sidechain or state channel. Currently, the Fuel ecosystem has 17 projects, mainly focused on DeFi, NFT, and infrastructure.

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

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

• Execution: Executing and verifying transactions
• Data availability: Distributing new blocks to all nodes in the blockchain network
• Consensus mechanism: Verifying blocks and reaching consensus
• Settlement: Settling and recording the final state of transactions

Parallel EVM mainly focuses on performance optimization at the execution layer. This is further 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 as much as possible within the virtual machine. L2 solutions essentially utilize the already parallelized L1 virtual machine to achieve some degree of "off-chain execution + on-chain settlement."

Therefore, to understand the technical principles of parallel EVM, it needs to be broken down: first, understand what a virtual machine is, and then understand what parallel execution is.

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

Virtual machines are divided into two types: system virtual machines, which can virtualize one physical machine into multiple machines, running multiple operating systems to improve resource utilization; and process virtual machines, which provide abstractions for certain high-level programming languages, allowing programs written in these languages to run in a platform-independent manner on different platforms.

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

A blockchain virtual machine is a type of process virtual machine. In the context of blockchain, a virtual machine refers to the virtual execution of a distributed state machine, used to execute contracts and run dApps in a distributed manner. Similar to JVM, EVM is a process virtual machine designed for the Solidity language, where smart contracts are first compiled into opcode bytecode, and then executed by the EVM.

Emerging public chains outside of Ethereum tend to use virtual machines based on WASM or eBPF bytecode when implementing their own virtual machines. WASM is a compact, fast-loading, portable, and sandbox-secure bytecode format, allowing developers to write smart contracts in various programming languages (C, C++, Rust, Go, Python, Java, and even TypeScript), compile them into WASM bytecode, and execute them. The smart contracts executed on the Sei public chain use this bytecode format.

eBPF, originally known as BPF (Berkeley Packet Filter), was initially used for efficient filtering of network packets, and later evolved into eBPF, providing a richer instruction set.

It is a revolutionary technology that allows dynamic intervention in and modification of the behavior of the operating system kernel without changing the source code. This technology later emerged from the kernel and developed into user-space eBPF runtimes, which are high-performance, secure, and portable. Smart contracts executed on Solana are compiled into eBPF bytecode and run on its blockchain network.

In other L1 public chains, Aptos and Sui use the Move smart contract programming language, compiling into proprietary bytecode to execute on the Move virtual machine. Monad has independently designed a virtual machine compatible with EVM opcode bytecode (Shanghai fork).

Parallel execution is a technology that:

1. Harnesses the advantages of multi-core processors to handle multiple tasks simultaneously, increasing system throughput.
2. Ensures that the results obtained are exactly the same as when transactions are executed in sequence in a serial manner.

TPS (transactions per second) is a commonly used technical indicator to measure processing speed in blockchain networks. The mechanism of parallel execution is quite complex and also tests the technical level of developers, making it not easy to explain clearly. Starting from an example of a "bank," the concept of parallel execution will be explained.

First, what is serial execution?

Scenario 1: If we consider the system as a bank and the CPU processing tasks as counters, then serial execution of tasks is like having only one counter at the bank to handle transactions. In this case, customers (tasks) coming to the bank can only queue up in a long line and have their transactions processed one by one. For each customer, the counter staff must repeat the same actions (execute instructions) to process the transaction. While waiting for their turn, customers can only wait, resulting in extended transaction times.

So, what is parallel execution?

Scenario 2: In this case, the bank sees that it's overcrowded and opens several more counters to handle transactions. With 4 staff members processing transactions at the counters simultaneously, the speed is about 4 times faster than before, reducing the waiting time for customers to about 1/4 of the original time, thus increasing the speed of transaction processing at the bank.

What happens if there is no protection and two people transfer money to another person at the same time?

Scenario 3: A, B, and C each 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 where transactions are executed serially, there would be no problem (the left arrow "=" indicates reading from the ledger, and the right arrow "=>" indicates writing to the ledger):

However, parallel execution is not as simple as it seems. There are many subtle details, and a slight oversight can lead to very serious errors. If A and B's transactions to C are executed in parallel, depending on the order of execution of each step, inconsistent results may occur:

Parallel Task 1 executes A's transfer to C, and Parallel Task 2 executes B's transfer to C. The steps marked with an asterisk in the table are problematic: due to the parallel execution of tasks, the balance calculation made by Parallel Task 1 in step 2 has not been written to the ledger yet, and in step 3, Parallel Task 2 reads C's account balance (which is still 0 at this point) and makes an incorrect balance calculation based on the balance of 0 in step 5. Then, in step 6 of the ledger update operation, the balance updated in step 4 is incorrectly updated again to 0.5. As a result, even though A and B both transferred 0.5 ETH to C at the same time, after the transactions are completed, C's account balance is only 0.5 ETH, and the other 0.5 ETH has disappeared.

If there is no protection, two tasks that are not dependent on each other can be executed in parallel without errors

Scenario 4: Parallel Task 1 executes A (balance 2 ETH) transferring 0.5 ETH to C (balance 0 ETH), and Parallel Task 2 executes B (balance 1 ETH) transferring 0.5 ETH to D (balance 0 ETH). It can be seen that there is no dependency between the two transfer tasks. Therefore, no matter how the steps of the two tasks are interleaved, there will be no issues as shown above:

From the comparison of these two scenarios, it can be analyzed that as long as there is a dependency between tasks, errors may occur during parallel execution of tasks, whereas there will be no errors if there is no dependency. If either of the following two conditions is met, it is considered that there is a dependency between tasks (transactions):

• One task writes to an output address that another task reads from as an input address.
• Two tasks output to the same address.

This is not unique to decentralization. Any scenario involving parallel execution may experience data inconsistency due to unprotected access to shared resources (such as the "ledger" in the bank example or shared memory in a computer system), known as data race issues.

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

Scenario 5: Suppose the bank has 4 counters simultaneously handling transactions, and each counter staff member is given a dedicated ledger, which only they can modify. This ledger records the account balances of the customers they serve.

Each counter staff member, when handling transactions for a customer, checks their own ledger. If the customer's information is not found in their ledger, they inform the other counter staff members about the transaction, and the other staff members then handle it.

This is the principle of the message passing model. The Actor model is a type of message passing model, where each executor responsible for processing transactions is an actor (counter staff member), and they have access to their own private data (dedicated ledger). If they need to access someone else's private data, they can only do so by sending a message.

Scenario 6: Suppose the bank has only one large ledger that records the account balances of all customers. There is only one pen next to the ledger that can be used to modify it.

In this scenario, the 4 counter staff members compete to see who can get the pen first (lock) to start processing transactions and modify the ledger. The other 3 staff members have to wait. Once the staff member finishes using the pen (unlock), the other 3 staff members then compete for the right to use the pen again, and this cycle continues. This is the memory lock model.

A memory lock is used to lock the access to shared resources when tasks are executed in parallel, allowing only one task to access the shared resource after locking it, and other tasks must wait for it to finish modifying the resource before they can lock it again and access it.

The handling of read-write locks allows for a more refined approach, where shared resources can be locked for reading (read lock) or writing (write lock). The difference is that multiple parallel tasks can acquire multiple read locks and read shared resource data, but are not allowed to modify it at that time. On the other hand, only one write lock can be acquired, and once acquired, it allows exclusive access by the lock holder.

Solana, Sui, and Sei v1 adopt a shared memory model based on memory locks. This mechanism may seem simple, but its implementation is quite complex and tests the developers' ability to handle multi-threaded programming. A slight oversight can lead to various bugs:

1. Scenario 1: Task locks the shared resource but crashes and exits due to an error during execution, leaving the shared resource locked and inaccessible.
2. Scenario 2: Task has already acquired a lock, but due to nested business logic, it attempts to acquire the lock again, resulting in self-waiting.

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

When multiple parallel tasks compete for multiple shared resources, each task occupies a portion and waits for the others to release resources, leading to deadlock issues. Parallel tasks detect that other parallel tasks are active, so they voluntarily release the shared resources they hold, resulting in a situation where resources are constantly being passed back and forth, leading to livelock. High-priority parallel tasks always have access to shared resources, while lower-priority tasks wait for a long time, leading to "starvation."

Scenario 7: Each of the 4 bank staff members can independently access and modify the ledger while handling transactions, regardless of whether other staff members are using the ledger. When using the ledger, each staff member attaches a personal label to the content they have accessed and modified. After completing a transaction, they review the ledger again. If they find a label that is not their own, it means that another staff member has modified the record, and the transaction needs to be invalidated and reprocessed.

This is the basic principle of optimistic parallelization. The core idea of optimistic parallelization is to assume that all tasks are independent of each other. Tasks are executed in parallel, and then each task is validated. If validation fails, the task is re-executed until all tasks are completed. For example, if 8 parallel tasks are executed optimistically, and conflicts arise during the process, the conflicting tasks will be repeatedly executed until all tasks are completed.

The optimistic parallelization model uses a multi-version in-memory data structure to record each written value and its version information (similar to the bank staff attaching labels). The execution of each parallel task is divided into two stages: execution and validation. The execution stage records all read and write behaviors to form read sets and write sets. The validation stage compares the read and write sets with the multi-version data structure. If the comparison reveals that it is not the latest version, validation fails.

The optimistic parallelization model originated from Software Transaction Memory (STM), which is a mechanism for lock-free programming in the database field. Due to the natural order of transaction processing in blockchain networks, this concept has been introduced and evolved into the Block-STM mechanism. Aptos and Monad adopt Block-STM as their parallel execution mechanism.

It is worth mentioning that the Sei public chain has abandoned the original memory lock model in the upcoming v2 version and adopted the optimistic parallelization model. Block-STM achieves extremely fast transaction execution speeds, with Aptos achieving an astonishing 160k tps in experimental environments, 18 times faster than sequential transaction execution.

Block-STM delegates the complex task execution and validation to the core team responsible for implementing the underlying mechanism, allowing developers to effortlessly write smart contracts just like writing sequentially executed programs.

The message passing and shared memory mechanisms are implemented based on the account/balance data model, which records the balance information of each on-chain account. It is similar to the bank's ledger recording that customer A has a balance of 1000 yuan, and customer B has a balance of 600 yuan. Each transaction only requires a modification of the account balance status.

Alternatively, in each transaction, only the specific content of the transaction is recorded to form a transaction record, and the user's account balance can be calculated based on the transaction records. For example, the following transaction records:

1. Customer A opens an account and deposits 1000 yuan.
2. Customer B opens an account (0 yuan).
3. Customer A transfers 100 yuan to Customer B.

By reading the transaction records and performing calculations, it can be determined that the current account balance for Customer A is 900 yuan, and for Customer B is 100 yuan.

UTXO (unspent tx output) is a data model similar to this transaction record, and it is a way of representing digital currency used in the first-generation blockchain Bitcoin. Each transaction has inputs (how it was obtained) and outputs (how it is spent), and UTXO can be understood as the unspent receipts.

For example, if Customer A has 6 BTC and transfers 5.2 BTC to Customer B, leaving 0.8 BTC, from the perspective of UTXO: A's 6 UTXOs worth 1 BTC each are destroyed, B receives a new UTXO worth 5.2 BTC, and a new UTXO worth 0.8 BTC is given as change to A. In this case, 6 UTXOs are destroyed, and 2 new UTXOs are created.

The inputs and outputs of transactions are linked together and ownership information is recorded using digital signatures, forming the UTXO model. Blockchain using this data model needs to sum up all UTXOs for a specific account address to determine the current account balance. The strict state access list mechanism is implemented based on the UTXO model to achieve parallel execution. It calculates the account addresses that each transaction needs to access in advance, forming an access list.

The access list serves two purposes:

1. Judging Transaction Security: If an address that is not in the access list is accessed during transaction execution, the execution will fail.
2. Parallel Execution of Transactions: Based on the access list, multiple sets of transactions are formed, and there is no intersection (no dependency) between each set of transactions in the access list, allowing multiple sets of transactions to be executed in parallel.

From an intrinsic perspective, the development of anything goes through the process of "from non-existent to existent" to "from existent to excellent," and humanity's pursuit of faster speed is eternal. Various on-chain and off-chain solutions have emerged to address the issue of blockchain network execution speed. Off-chain solutions represented by rollups have been fully explored, while the narrative of parallel EVM still has a lot of room for exploration.

From a historical perspective, with events such as the SEC approving a spot Bitcoin ETF, the upcoming Bitcoin halving, and the potential interest rate cut by the Federal Reserve, the cryptocurrency industry is expected to enter a major bull market. The flourishing development of the industry requires blockchain network infrastructure with greater throughput as a solid foundation.

From a resource management perspective, traditional blockchain networks process transactions in a serial manner, which, while simple, also represents a waste of processor resources. In contrast, parallel blockchains make efficient use of computing resources, fully utilizing the performance of multi-core processors and improving the overall efficiency of blockchain networks.

In terms of industry development, although there is a constant stream of innovations in various technologies and business models, the growth potential of Web3 is still waiting to be tapped. Centralized networks can handle over 50,000 messages per second, send 3.4 million emails, complete 100,000 Google searches, and have thousands of players online simultaneously, a feat that decentralized networks cannot currently achieve. Decentralization must compete with centralization, secure its own territory, continuously optimize parallel execution mechanisms, and increase transaction throughput, which is a necessary path for development.

In the development of decentralized applications, attracting more users requires a focus on user experience. Performance optimization is one of the directions to improve user experience. For DeFi users, there is a need to meet the demand for high transaction speeds and low fees. For GameFi users, there is a need to meet the demand for real-time interaction. All of these require support from parallel execution.

Decentralization, security, and scalability can only satisfy two out of the three, forming the "impossible triangle" of blockchain. Since "decentralization" is an unshakable pole, an increase in "scalability" means a decrease in "security." Code is written by humans, and human-written code is prone to errors. The technical complexity brought about by parallel computing provides a breeding ground for security vulnerabilities.

Multi-threaded programming is prone to problems due to improper handling of complex concurrent control operations, as well as crashes caused by accessing invalid memory addresses, and even buffer overflow vulnerabilities that can be exploited by attackers.

At least three aspects can be used to evaluate the security of a project. Firstly, the team background. A team with experience in system programming has rich experience in multi-threaded programming and can handle 80% of difficult problems. System programming generally involves the following areas:

• Operating systems
• Various device drivers
• File systems
• Databases
• Embedded devices
• Cryptography
• Multimedia encoding and decoding
• Memory management
• Networking
• Virtualization
• Gaming
• High-level programming languages

Secondly, code maintainability. Writing maintainable code follows a set of principles, such as clear architectural design, reasonable use of design patterns to achieve code reusability, writing a sufficient amount of unit test code using test-driven development techniques, and eliminating duplicate code through reasonable refactoring.

Thirdly, the programming language used. Some cutting-edge programming languages emphasize memory safety and high concurrency in their design. The compiler checks the code, and if it detects concurrency issues or potential access to invalid memory addresses, it will fail to compile, forcing developers to write robust code.

Rust is an outstanding example of such a language, which is why we see that the majority of parallel blockchain projects are developed using Rust. Some projects have even borrowed from the design of the Rust language to implement their own smart contract languages, such as Fuel's Sway language, and so on.

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

Sei has received a total of 3 rounds of funding, including a $5 million seed round, a $30 million first-round strategic financing, and an undisclosed amount for the second-round strategic financing. Sei Network has also raised a total of $100 million in funds to support its ecosystem development.

In August 2023, Sei went live on the mainnet, claiming to be the fastest L1 public chain, capable of executing 12,500 transactions per second, with a final determinism requiring only 380 ms. The current circulating market value is nearly $2.2 billion.

Currently, the Sei ecosystem consists of 118 projects, mainly focused on DeFi, infrastructure, NFT, gaming, and wallets. The community currently has 650,000, 600,000, and 40,000 members on Twitter, Discord, and Telegram, respectively.

At the end of November 2023, Sei announced on its official blog that it would launch the largest version upgrade after the mainnet goes live in the first half of 2024: Sei v2. Sei v2 is touted as the first parallel EVM blockchain, and this version upgrade will bring the following new features:

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

The original parallel execution of transactions on the Sei network was implemented based on the memory lock model. Before execution, the dependency relationships between all pending transactions are resolved and a DAG is generated, and then the execution order of transactions is precisely arranged based on the DAG. This approach adds to the mental burden of contract developers, as they have to write the logic into the code when developing contracts.

As mentioned in the technical principles section above, the new version adopts optimistic parallelization, allowing developers to develop smart contracts just like writing sequentially executed programs. A series of complex mechanisms such as transaction scheduling, execution, and validation are handled by the underlying modules. The core team has also introduced a proposal to further enhance parallel execution capabilities through pre-filling dependency relationships.

Specifically, it introduces a dynamic dependency generator to analyze the write operations of transactions before execution and pre-fill them into a multi-version memory data structure, optimizing potential data contention. The core team has concluded that while this optimization mechanism may not be beneficial for transaction processing in the best-case scenario, it will significantly improve execution efficiency in the worst-case scenario.

If you missed the development of the aforementioned public chains, then Monad is definitely one you cannot miss. It is hailed 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 round investment in February 2023, and in March 2024, Paradigm led negotiations for a round of over $200 million in financing for Monad, which, if successful, will be the largest cryptocurrency financing since the beginning of the year.

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

Monad is highly favored by capital for two prominent reasons: strong technical background and effective marketing hype. The core team of Monad Labs consists of 30 members, all of whom have been deeply involved in high-frequency trading, kernel drivers, and financial technology for decades, with rich development experience in distributed systems.

The project's daily operations are also very "down-to-earth": it continuously engages with its 200,000 followers on Twitter and 150,000 members on Discord through "magical marketing." For example, it holds meme contests every week, collecting various bizarre purple animal emojis or videos from the community for "spiritual dissemination."

The vision of Monad is to become a developer-oriented smart contract platform, bringing ultimate performance improvements to the Ethereum ecosystem. Monad has introduced two mechanisms for the Ethereum Virtual Machine (EVM): superscalar pipeline technology and improved optimistic parallel mechanism.

Superscalar pipeline technology parallelizes the execution phase of transactions. The official documentation provides a vivid example. Doing laundry is like processing transactions on the blockchain, requiring multiple stages to complete. The traditional approach is to wash, dry, fold, and store each pile of dirty laundry before moving on to the next pile.

The superscalar pipeline starts washing the second pile of laundry while the first pile is drying, and the second and third piles are being dried and washed respectively while the first pile is being folded. Therefore, each stage of processing is never idle.

The optimistic parallel mechanism parallelizes the execution of transactions. Monad uses optimistic parallelization to achieve parallel execution. It has also implemented its own static code analyzer to predict the dependency relationships between transactions, scheduling subsequent transaction execution only after the dependent transactions have been executed, greatly reducing the repetition of transactions due to verification failures.

Currently, the performance has reached 10,000 TPS and can produce blocks in 1 second. As the project progresses, the core team will continue to explore more optimization mechanisms.

Founded in 2022, Canto is a highly decentralized L1 project based on the Cosmos SDK, with no official foundation, no presale, no affiliation with any organization, no fundraising, completely community-driven, and even the core team works anonymously in a loose organizational manner.

Although it is a general-purpose blockchain compatible with EVM, Canto's primary vision is to become an accessible, transparent, decentralized, and free DeFi value platform. Through long-term research on the track, it has been found that any healthy DeFi ecosystem project includes three basic elements:

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

However, past DeFi ecosystems have all ended up with the same fate: issuing governance protocol tokens, where the value of the token depends on how much usage fees the ecosystem can extract from its future users. The more it can extract, the greater the value. This is like each DeFi protocol being a pay-per-hour private parking lot, with the more users, the higher the valuation.

Canto has taken a different approach: building free public infrastructure for DeFi, creating itself as a free parking lot for its ecosystem projects to use for free.

The infrastructure consists of three protocols: the decentralized exchange Canto DEX, the pool-based lending platform Canto Lending Market (CLM) forked from Compound v2, and the stablecoin NOTE that can be borrowed from CLM by collateralizing assets.

Canto DEX operates perpetually with an unupgradable, ungoverned protocol that neither issues tokens nor charges additional fees. This avoids various rent-seeking behaviors within the DeFi applications in the ecosystem, leading to a zero-sum game of survival of the fittest.

The governance of the lending platform CLM is controlled by pledgers, who fully enjoy the benefits brought by the ecosystem's development, in turn creating the best environment for developers and DeFi users, incentivizing them to continuously contribute. The interest generated by borrowers lending out NOTE is paid to the borrowers, and the protocol does not take a single penny.

For developers, Canto has also introduced the Contract Secured Revenue (CSR) model, allowing a certain percentage of the fees generated by user interactions with contracts on the chain to be distributed to developers. This series of business model innovations has achieved a "three-pronged" effect, creating a constructive foundation for ecological prosperity by providing open, free financial infrastructure.

By giving back to developers and users in various ways, it incentivizes them to join and enrich the ecosystem continuously. By firmly holding the "coinage right," it has created the possibility of cross-application liquidity for various decentralized applications. The more prosperous the ecosystem, the more valuable the token. When the CSR proposal was approved by the community vote on January 26, 2024, the token $CANTO experienced a wave of growth.

After completing this series of business model innovations, on March 18, 2024, Canto announced its new round of technical iteration plans on its official blog.

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

Canto's use of the Cosmos SDK divides transaction processing into three stages: Proposal, Voting, and Finalization. The ProcessProposal sub-process in Voting is responsible for the parallel execution of transactions. The parallel execution engine is responsible for executing transactions, while the conflict detection engine verifies transaction validity.

If invalid, it is rolled back to the execution engine for re-execution; if valid, the transaction is submitted to the subsequent processing flow. It is believed that after this round of technical upgrades, Canto's token will have even more remarkable performance.

Fuel consists of the virtual machine FuelVM, the Rust-inspired contract development language Sway, and related toolchains. It is a custom 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 3 years of development. The project is finally set to launch its mainnet in the third quarter of 2024.

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

Executing transactions one by one on-chain requires paying gas fees, competing for valuable block space, and is slow. Therefore, various scaling solutions naturally come to mind, such as batch processing transactions for execution and then settling them together on-chain to speed up execution.

Rollup is a scaling solution that operates outside of L1, batch-executing transactions off-chain, and then sending transaction data or execution proofs to L1, ensuring security through the data availability layer and settling transactions. There are two main types of rollup: optimistic and zero-knowledge proof (ZK).

Optimistic rollup assumes transactions are valid, and if malicious or erroneous transactions are discovered, fraud proofs are generated and submitted to L1 for rollback. ZK rollup generates transaction validity proofs through complex calculations without exposing transaction details, proving that rollup has correctly executed transactions. Therefore, rollup is a blockchain execution layer technology.

Although rollup speeds up transaction execution, most existing implementations are designed for monolithic blockchains. Developers have to make various compromises, limiting the full potential of rollup. There is also a lack of adapted rollup solutions for the new trend of modular blockchains. Fuel was born to fill this gap.

Fuel uses UTXO as a data model, which has the advantage of having only two states for transaction outputs: spent, permanently recorded in the block's transaction history, or unspent, available for future transactions. This minimizes the storage of state data for each node on-chain. Based on this, Fuel checks the account information accessed by each transaction, identifies dependencies before executing transactions, and schedules independent transactions for parallel execution, increasing transaction processing throughput.

L2 solutions have a commonality: they combine the capabilities of two virtual machines to improve transaction execution speed. Specifically, they use parallel L1 to execute transactions while remaining compatible with other chains (supporting dual virtual machines). The difference lies in the compatibility mechanisms adopted by different projects. Neon, Eclipse, and Lumio are quite representative in this regard.

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 fast L2 protocol compatible with EVM in the Solana ecosystem, built with a modular architecture. Among these three projects, only Neon has issued its own token, with a circulating market value of over $780 million.

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

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

All three projects have not formed a large-scale application ecosystem, but they have tens of thousands to hundreds of thousands of followers or members on major social media platforms, as shown in the table below.

In terms of implementation mechanisms, Neon is an EVM simulator on the Solana network, running in the form of smart contracts. Developers can use languages like Solidity and Vyper to write dApp applications and can use Ethereum tools and compatible Ethereum RPC APIs, accounts, signatures, and token standards such as MetaMask, Hardhat, Remix, etc. At the same time, they can enjoy the low fees, high transaction execution speed, and parallel execution capabilities of Solana.

Ethereum transactions sent from the frontend of dApps are converted by a proxy into Solana transactions, which are then executed in the simulator, modifying the on-chain state. Similar to using a game emulator on a PC to play exclusive games from platforms like Switch and PS, Neon allows Ethereum developers to run Ethereum applications on the Solana network.

Eclipse has adopted another implementation approach: executing transactions through SVM and settling transactions through EVM. Eclipse adopts a modular blockchain architecture, where it is only responsible for transaction execution and "outsources" other responsibilities through modular combinations to form a unified solution.

For example, it uses Celestia to manage data availability and Ethereum for transaction settlement. Eclipse uses SVM to ensure execution speed and Ethereum for verification and settlement to ensure security.

Lumio adopts a design approach independent of the execution and settlement layers, supporting various virtual machines and compatible L1/L2 networks such as Ethereum, Aptos, Optimism, Avalanche, zkSync, and others. It executes transactions through Move VM and settles transactions through EVM, connecting the Ethereum and Aptos ecosystems.

However, Lumio's ambition does not stop there. Its vision is to provide cross-virtual machine calls to achieve multi-chain liquidity interconnection at the fastest speed and lowest cost.

The above are the main projects related to parallel EVM narrative at present, as shown in the following figure.

People love to compare Bitcoin to a "distributed ledger" and Ethereum to a "distributed state machine." If all nodes running the blockchain network are seen as a computer, then parallel blockchain is essentially about maximizing the processor resources of this "computer" to achieve maximum execution speed.

This is the historical inevitability of the continuous development of computing technology, just like processors evolving from single-core to multi-core, and operating systems evolving from single-user single-thread to multi-user multi-thread. This has extraordinary significance for driving the continuous development of the industry.

The technical principles of parallel EVM can be broken down into two components: virtual machine and parallel execution mechanism. In the context of blockchain, the virtual machine integrates a set of instructions for distributed contract execution and dApp operation. The parallel execution mechanism mainly studies how to maximize transaction execution speed while ensuring the correctness of transaction results.

On the one hand, parallel EVM has commonalities in technical principles. Firstly, the optimistic parallelization model is the consensus of L1 public chains. However, this does not mean that the memory lock model is useless. Because there is no distinction between high and low technology, only differences in the level of developers.

Secondly, projects represented by Fuel firmly believe that off-chain scaling mechanisms can only achieve maximum performance after modularization. Finally, a group of L2 projects integrate parallel L1 public chains to increase transaction throughput and achieve cross-ecosystem scaling capabilities.

On the other hand, parallel blockchain has its own unique technical achievements. Even if the same parallel execution model is adopted, different teams have used different architectural design patterns, data models, or preprocessing mechanisms. The exploration of technology is endless, and different projects will develop different technologies based on different visions to drive continuous advancement to higher levels.

Looking ahead, there will be more L1 and L2 projects joining the competition of parallel EVM. The L1 track will form a pattern of comprehensive competition for processor resources, storage resources, network resources, file system resources, and device resources between the parallel EVM and parallel non-EVM camps, and more new narratives related to performance improvement will emerge. The L2 track will evolve towards blockchain virtual machine simulators or modular blockchains.

In the future, optimized infrastructure will bring faster speed, lower costs, and higher efficiency. Web3 entrepreneurs can boldly innovate business models to create better decentralized product user experiences for the world, further flourishing the industry ecosystem. For Web3 investors, focusing solely on technology is far from enough.

When choosing investment targets, investors should not only consider the narrative but also look at market value and liquidity. They should choose projects with "good narratives," "low market value," and "high liquidity," and then study their business, team background, economic model, marketing, and ecosystem projects in all aspects to discover potential projects and find suitable investment paths.

Parallel EVM is in the early stages of development, and Neon, Monad, Canto, Eclipse, Fuel, and Lumio are still in the stage where their value has not been fully realized. Especially Monad, Canto, and Fuel.

From the marketing style of Monad, not only is it worth paying attention to itself, but the meme projects in its ecosystem are also worth noting in the future, and may create myths of wealth due to hype. Canto already meets the conditions of "good narrative" and "low market value," but whether it is a good investment target requires in-depth research into its various indicators. Fuel represents the hot development direction of modular blockchains and may also create new investment opportunities, all of which are directions worth our attention.

References

[1]https://www.theblockbeats.info/news/49248

[2]https://www.binance.com/en/research/analysis/technical-deep-dive-parallel-execution

[3]https://en.wikipedia.org/wiki/Virtual_machine

[4]https://medium.com/@yunwei356/userspace-ebpf-runtimes-overview-and-applications-d19e3c84c7a7

[5]https://news.marsbit.co/20240119153041358158.html

[6]https://medium.com/@NervosCN/%E5%8C%BA%E5%9D%97%E9%93%BE%E4%B8%8D%E5%8F%AF%E8%83%BD%E4%B8%89%E8%A7%92-%E7%BB%88%E6%9E%81%E6%8C%87%E5%8D%97-85c069f21adc

[7]https://news.marsbit.co/20240112161732277166.html

[8]https://blog.ambire.com/blockchain-layers-differences-explained/

[9]https://medium.com/solana-labs/sealevel-parallel-processing-thousands-of-smart-contracts-d814b378192

[10]https://aptosfoundation.org/whitepaper/aptos-whitepaper_en.pdf

[11]https://blog.sui.io/parallelization-explained/

[12]https://blog.sei.io/sei-v2-the-first-parallelized-evm/

[13]https://docs.monad.xyz/technical-discussion/execution/parallel-execution

[14]https://canto.mirror.xyz/5q8V3Z9CHjM7fjgUTE0hMYcD-UuVemPybo0QWaNzzzE

[15]https://docs.neonevm.org/docs/about/why_neon

[16]https://www.eclipse.xyz/

[17]https://docs.lumio.io/xlumio-virtual-machines#execution

[18]https://fuel.mirror.xyz/uYMT39LiB538Q61Mgf4bRrsAwApJSeNiG_afDHhOhGs

[19]https://fuel.network/

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。