TL;DR
The concept of Parallel EVM is being backed by several top VCs: Paradigm, Jump, Dragonfly, etc.
Representative projects include Monad, as well as Sei, MegaETH, Polygon, Neon EVM, BSC, etc. Some are L1, some are L2. There is currently no complete public information on the specific differences between the teams.
Although the literal meaning of Parallel EVM only represents "parallelization," it is also a specialized optimization of the performance of various components of EVM. Therefore, its efforts are likely to represent the performance limit under the EVM standard.
Challenges: In addition to the need to refactor the entire technology stack, there is also the issue of how to predict in advance whether parallel transactions will conflict, as well as the efficiency of re-execution when conflicts occur.
Challenges: How to build differences in the open-source ecosystem, and how to find a balance between decentralization and performance.
After consensus algorithms, data layers, and zero-knowledge proof technologies have been widely researched and iterated, the next hardcore technology that is being focused on is Parallel EVM. The capital market has already invested hundreds of millions of dollars in this narrative, giving rise to several unicorn-level startups.
The community has begun to pay attention to Parallel EVM (EVM parallelization) originating from Georgios Konstantopoulos (CTO of Paradigm) and Haseeb Qureshi of Dragonfly, who independently mentioned this same keyword at the end of 2023 when looking ahead to the trends of 2024. However, there are not many details discussed about this topic, and many people also believe that this is not a new concept, as both EVM and parallel computing are relatively mature concepts. Why is it an important trend to combine these two words together?
[
](https://substackcdn.com/image/fetch/fauto,qauto:good,flprogressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fdf09e012-c00f-4664-83b2-55be476a6aa61158x436.png)
However, this is still a very niche topic, to the extent that if you look through the annual summaries and trend forecasts of many research institutions, Parallel EVM is not mentioned. So, this is still a new concept that has not formed a large-scale consensus. Moreover, similar to consensus algorithms, DA, and other topics, this concept is purely technical, so the audience paying attention to it is even smaller.
The most direct advantage of Parallel EVM is to enable existing decentralized applications to achieve Internet-level performance. It can even be said that Parallel EVM is the only new technology that can both utilize (a large number of mature) existing smart contracts and achieve high-performance, parallel public chain throughput.
Paradigm's Long-Awaited Entry, Heavy Investment by Jump
According to "Fortune" report, Paradigm is planning to lead the latest round of investment in Monad, raising $200 million at a valuation of $30 billion. Although this is the first team with a Parallel EVM concept that Paradigm plans to invest in, they have actually been paying attention to this technology for many years. Georgios Konstantopoulos (CTO of Paradigm) mentioned this term as early as 2021 here.
The origin of the word "Monad" is also interesting. In the philosopher Leibniz's philosophical system, Monad is the basic element that constitutes the universe. They are indivisible, entities not subject to physical influence, and each Monad reflects the entire universe. In Chinese, it has been translated as "单子" (monad).
In computer science, Monad is a design pattern in functional programming languages that helps programmers deal with the complexity of the real world in a nearly mathematical purity, making the code more modular, easy to understand, and maintain.
Another interesting point is that Monad and Nomad are "anagrams" of each other. Nomad refers to a nomad, and digital nomad refers to a digital nomad.
In addition to Monad, Georgios also mentioned Sei and Polygon when discussing this topic. However, another important reason why he is so optimistic about Parallel EVM is that they have developed an Ethereum client called Reth. Its positioning is a high-performance Ethereum execution layer client implemented in the Rust language. Reth is being developed at a very fast pace and has just entered the Beta stage. Perhaps they will consider implementing Parallel EVM directly on Reth, but considering the amount of engineering involved, it may be a better choice to promote Parallel EVM through investment in other teams. According to Monad's documentation, they mainly use C++ and Rust in their engineering.
When Reth was first launched, it was accused by members of the Erigon team of plagiarizing their open-source code, which also led to a lack of funding for the Akula project, causing it to stop development. Georgios responded that Reth is not a fork of any other client, and the code does not come from any other client, but it is indeed influenced and inspired by Geth, Erigon, and Akula. (https://thedefiant.io/paradigm-accused-copying-code)
Another core participant is Jump Trading and Jump Capital, with the founder of Monad coming from Jump Trading, having extensive experience in high-frequency trading. Sei's investors include Jump Capital, and Jump has been deeply involved in the Solana ecosystem, including infrastructure and projects.
Early investors in Monad, Dragonfly, have also been paying attention to related tracks, having invested in NEAR, which focuses on sharding technology, as well as Aptos, Avalanche, Nervos, and other public chains.
Upgrading Consensus Algorithms Is Not Enough, It's Finally the Turn of the Execution Layer
In the past few public chain battles, the execution layer has always been overlooked, with discussions almost exclusively focused on the innovation of consensus algorithms, whether it's Solana, Avalanche, or EOS, etc. Although they have a lot of innovation in the execution layer, the community still remembers more about the consensus algorithms they use, and the entire community also tends to think that these high-performance public chains can achieve this performance solely from the innovation of consensus algorithms.
However, this is not the case. In order to achieve a high-performance public chain, both the consensus algorithm and the execution layer need to be complementary, which also aligns with the concept of the "weakest link" in a system. For public chains based on EVM that only improve the consensus algorithm, increasing performance requires stronger nodes. For example, BSC limits the block gas processing to a level of 2000 TPS, requiring machine configurations several times greater than those of Ethereum full nodes. Polygon theoretically can achieve 1000 TPS, but usually only reaches tens to hundreds.
BSC archive nodes require at least 16-core CPUs and 128GB of memory, while Ethereum nodes only require at least 4-core CPUs and 16GB of memory.
The BSC team has long been aware of these issues and is collaborating with NodeReal to develop Parallel EVM technology. Only in this way can the number of transactions processed per block be further increased, allowing more transactions to be executed in parallel and increasing the TPS limit.
Parallel: Upgrading from Single-Core to Multi-Core CPUs
In most blockchain systems, transactions are executed in strict sequence, similar to a single-core CPU where the next calculation can only occur after the current one is completed. While this method is slow, its advantage lies in its simplicity and low system complexity.
However, if future blockchain systems need to accommodate Internet-scale user bases, a single-core CPU will not suffice. Therefore, upgrading to a multi-core CPU parallelized virtual machine can process multiple transactions simultaneously, increasing throughput. However, there are many engineering challenges in implementing this, such as how to handle two transactions being processed simultaneously that write data to the same smart contract. This requires the design of a new mechanism to resolve such conflicts. For parallel execution of completely unrelated smart contracts, throughput can be increased according to the number of parallel processing threads.
Furthermore, Parallel EVM not only enhances parallel capabilities but also optimizes the efficiency of single-thread execution. Monad CEO Keone Hon stated, "…(the EVM's) real bottleneck lies in frequent state reads and writes during transaction processing…" He also mentioned that parallel execution is just part of the roadmap, and Monad's larger mission is to make the EVM as efficient as possible.
Therefore, although the literal meaning of Parallel EVM only represents "parallelization," it is actually a specialized optimization of the performance of various components of EVM. Therefore, its efforts are likely to represent the performance limit under the EVM standard.
EVM Does Not Equal Solidity
Writing smart contracts is a necessary skill for most blockchain developers. Engineers can write the corresponding logic implementation in Solidity or other high-level smart contract languages based on business requirements. However, the EVM cannot directly understand the logic of Solidity. It needs to undergo some "translation" to be compiled into a low-level language that the machine can understand (opcode/bytecode) before it can be executed by the virtual machine. Solidity developers do not need to understand this translation process because mature tools have already implemented it.
Since it is a "translation," there is some overhead involved. For engineers with experience in low-level code, they can directly write program logic in opcode within Solidity, achieving the highest efficiency and saving gas for user transactions. For example, Opensea's Seaport protocol extensively uses inline assembly in smart contracts to minimize gas expenditure for users.
Therefore, if Parallel EVM can be implemented, it will not only bring parallel capabilities but also optimize the performance of the entire EVM stack. Ordinary application developers will not need to expend significant effort to optimize for gas savings, as the underlying virtual machine will be powerful enough to bridge these differences.
Different EVM Performances, "Standard" Does Not Equal "Engineering Practice"
A "virtual machine" can also be referred to as an "execution layer," which is the engine where smart contracts are compiled into opcodes and ultimately calculated and processed. The "bytecode" defined by the Ethereum Virtual Machine (EVM) has become an industry standard, and whether it is a second-layer network based on Ethereum or other independent public chains, they are more willing to directly and fully comply with the EVM standard. Developers can write a smart contract once and deploy it to multiple networks, making it highly cost-effective.
Therefore, as long as it fully complies with the "bytecode" standard compatible with EVM, it can be called EVM, but the implementation methods can vary greatly. For example, the Ethereum client Geth has implemented the EVM standard using the Go language. However, the Ethereum Foundation's execution layer research team, Ipsilon, maintains an independent implementation of the EVM developed in C++, which other Ethereum clients can directly call to serve as the EVM execution.
For example, many industrially produced products have corresponding international standards. For instance, a product must meet a specific limit for bacterial count before it can be sold. This is the "standard." However, how to meet this standard when the product is manufactured can be chosen from dozens of different sterilization methods by each factory, and some factories can find a more cost-effective way to meet this requirement. This is the "practice."
Since there is an evmone implementation, other implementations can also be made. Therefore, in this example of the EVM, the standard of the EVM defines some basic operation methods "bytecode" (such as supporting basic arithmetic operations like addition, subtraction, multiplication), and each bytecode has a specific input, resulting in a specific output. While meeting this standard, the implementation (practice) methods can vary greatly, providing a lot of room for customization and engineering optimization possibilities.
Similarities and Differences of Parallel EVM
In the Parallel EVM track, apart from the highly popular Monad, there are also Sei, MegaETH, Polygon, Neon EVM, BSC, and Paradigm's Reth client also aims to implement parallelization.
In terms of positioning, Monad, Sei, Polygon, and BSC are all Layer 1 blockchains, while MegaETH may be Layer 2, and Neon EVM is based on the Solana network. Additionally, Reth is an open-source client, and MegaETH will also continue development based on Reth's engineering.
Of course, there is competition among these teams, and not all technical details and engineering documents have been fully disclosed, so more comparisons will have to wait for their gradual public release. Perhaps this is like an arms race, similar to BTC Layer 2, Restaking, and Ethereum Layer 2, where despite subtle differences in technology (and being open-source), the more important aspect is how to build the uniqueness of the ecosystem.
Technical Challenges of Parallel EVM
For sequentially executed transactions, the bottleneck lies in the CPU and the process of reading and writing states. However, the benefit of this method is that it is simple and error-free, and all transactions can be executed in an orderly manner. For parallel execution virtual machines, there may be state conflicts, so additional checks are needed before or after execution.
A simple example is that if the virtual machine supports the parallel execution of four threads, and each thread can process a transaction simultaneously, if all four transactions are related to the same transaction pool on Uniswap, they cannot be computed in parallel because each transaction will affect the transaction price of the pool. However, if the four threads are processing four completely unrelated tasks simultaneously, then there is no problem.
This will involve the design and engineering implementation of different teams, but at the very least, after parallel execution, a module is needed to detect conflicts and re-execute if a conflict occurs. Of course, if potential conflicting transactions can be predicted and screened in advance, it can also increase the overall parallel efficiency of the virtual machine.
In addition to the engineering implementation differences of the Parallel EVM virtual machine, teams generally also redesign and enhance the read and write performance of the state database, and design a consensus algorithm to complement it, such as Monad's design of MonadDb and MonadBFT.
Challenges
For Parallel EVM, there are two potential challenges: whether the long-term engineering value will be captured by Ethereum, and node centralization.
Since various teams are still in the development and testing stages of Parallel EVM technology, none have chosen to open source all engineering details, which is one of the current moats. However, once they enter the test network and main network, these engineering files will be made public and may be absorbed by Ethereum or other public chains. Therefore, at that time, it will be necessary to accelerate ecosystem development and build more ecosystem-level moats.
However, this issue is not so severe. On the one hand, for crypto developers, there are now more open source licenses to choose from (such as Uniswap's license that allows code to be made public but does not allow forking for commercial projects). On the other hand, Monad's positioning is different from Ethereum's. Even if Ethereum can achieve single-slot finality (SSF) in the future, the finality of transactions is still at least 12 seconds, which is far from sufficient for higher frequency use cases.
Another challenge, common to all high-performance public chains, is how to deploy more nodes to meet the basic requirements of permissionless and trustless for users: decentralization. Perhaps some metrics can be quantified, such as "TPS divided by hardware requirements per node," so that variables can be controlled to compare which public chain/client has a higher TPS under specific hardware requirements. After all, the lower the hardware requirements for nodes, the more nodes there may be.
Next, we will continue to track the progress of various projects related to Parallel EVM and discuss their technologies and differences in detail.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
