Parallel EVM Concept Being Bet On by Top VCs: Paradigm, Jump, Dragonfly, etc. Represented projects include Monad, Sei, MegaETH, Polygon, Neon EVM, BSC, etc. Some are L1, some are L2. There is currently no complete publicly available information on the specific differences between the teams. This article is sourced from ChainFeeds Selection and compiled, translated, and written by Foresight News.
Summary:
From Ethereum EVM to “Modular Blockchain”: A New Dawn in the Crypto Era?
Background:
Exploring BTC Ecosystem during Chinese New Year: Three Major Bitcoin Layer 2 Interactive Tutorials – B2 Network, Merlin, and BEVM
Table of Contents:
Paradigm’s Long-Awaited Entry, Heavy Betting by Jump
Consensus Algorithm Upgrade is Not Enough, Execution Layer is Finally in Focus
Parallelism: Upgrading from Single-Core to Multi-Core CPU
EVM is Not Equal to Solidity
Different EVM Performances, “Standard” Does Not Equal “Engineering Practice”
Differences and Similarities of Parallel EVM
Technical Challenges of Parallel EVM
Challenges: How to Build Diversity in the Open Source Ecosystem, and How to Find a Balance Between Decentralization and Performance
After the extensive research and iteration of consensus algorithms, data layer (DA), and zero-knowledge proof technologies, the next hardcore technology being focused on is Parallel EVM. The capital market has already invested hundreds of millions of dollars in this narrative, giving birth to several unicorn-level startups.
The community began to pay attention to Parallel EVM (EVM parallelization) when Georgios Konstantopoulos (CTO of Paradigm) and Haseeb Qureshi from Dragonfly mentioned this keyword at the end of 2023 when looking forward to the trend in 2024. However, there are not many details discussed about this topic, and many people believe that it is not a new concept. Both EVM and parallel computing are relatively mature concepts, so why is combining these two terms considered an important trend?
But this is still a very niche topic. If you look through the annual summaries and trend forecasts of many research institutions, Parallel EVM is not mentioned. Therefore, it is still a new concept that has not formed a large-scale consensus. Moreover, this concept, similar to consensus algorithms and DA, is purely technical, so the number of people 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 utilize (a large number of mature) existing smart contracts while achieving high-performance and parallelized public chain throughput.
According to Fortune, Paradigm is planning to lead the latest round of funding for Monad, raising $200 million at a valuation of $3 billion. Although this is Paradigm’s first investment in a team with the concept of Parallel EVM, they have been paying attention to this technology for many years. Georgios Konstantopoulos (CTO of Paradigm) mentioned this term in 2021.
The origin of the term “Monad” is also interesting. In Leibniz’s philosophical system, Monad is the basic element that constitutes the universe. They are indivisible and unaffected entities that reflect the entire universe. In computer science, Monad is a design pattern in functional programming languages that helps programmers deal with the complexity of the real world using near-mathematical purity, making the code more modular, understandable, and maintainable.
Another interesting fact is that “Monad” and “Nomad” are anagrams of each other. Nomad refers to a nomadic person, and “digital nomad” refers to a digital nomad.
In addition to Monad, Georgios also mentioned Sei and Polygon when discussing this topic. However, the 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 development work, it may be a better choice to invest in other teams to promote Parallel EVM. According to Monad’s documentation, they mainly use C++ and Rust in their engineering.
At the beginning of Reth’s launch, it was accused by members of the Erigon team of plagiarizing the open-source code of Akula, which also led to the lack of funding for the Akula project. 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.
Another key participant is Jump Trading and Jump Capital, with the founders of Monad coming from Jump Trading and having rich experience in high-frequency trading. Jump Capital is an investor in Sei, and Jump has been deeply involved in the Solana ecosystem, including infrastructure and projects.
Dragonfly, an early investor in Monad, has also been paying attention to related tracks and has invested in NEAR, which focuses on sharding technology, as well as Aptos, Avalanche, Nervos, and other public chains.
In the previous public chain wars, the execution layer has been overlooked, with the focus mainly on the innovation of consensus algorithms, whether it is Solana, Avalanche, or EOS, etc. Although they have many innovations in the execution layer, the community still remembers the consensus algorithms they use, and the entire community will think that these high-performance public chains achieve their performance through the innovation of consensus algorithms.
But that’s not the case. If you want to achieve a high-performance public chain, both the consensus algorithm and execution layer need to be coordinated, which also aligns with the concept of the weakest link. For those public chains based on EVM and only improve the consensus algorithm, increasing performance requires stronger node hardware. For example, BSC limits the gas that blocks can process to the level of 2000 TPS, requiring several times the machine configuration investment of Ethereum full nodes. Polygon theoretically can achieve 1000 TPS but usually only achieves dozens to hundreds.
BSC archive nodes require at least a 16-core CPU and 128GB of memory, while Ethereum nodes require at least a 4-core CPU and 16GB of memory.
The BSC team has long been aware of these issues, so they are also 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.
In most blockchain systems, transactions are executed strictly in order. You can think of it as a single-core CPU, where the next computation can only be performed after the current one is completed. This method is slow but has the advantage of being simple and having low system complexity.
However, if future blockchain systems need to accommodate internet-scale user bases, a single-core CPU will definitely not be enough. Therefore, upgrading to a multi-core CPU with parallelized virtual machines can process multiple transactions simultaneously and increase throughput. However, there are many challenges in engineering implementation, such as how to handle two transactions being processed simultaneously that write data to the same smart contract. This requires designing a new mechanism to resolve this conflict. As for the parallel execution of unrelated smart contracts, the throughput can be increased according to the number of parallel processing threads.
In addition, Parallel EVM not only improves parallel capabilities but also optimizes execution efficiency when running on a single thread. Monad CEO Keone Hon”The true bottleneck of EVM lies in frequent read and write operations when processing transactions,” said the spokesperson. He also stated that parallel execution is only part of the roadmap, and Monad’s larger mission is to optimize EVM to be as efficient as possible.
Writing smart contracts is a necessary skill for most blockchain developers. Engineers can use Solidity or other high-level languages for smart contract logic implementation based on business requirements. However, EVM cannot directly understand the logic of Solidity and requires some “translation” to be compiled into a low-level language (opcode/bytecode) that can be executed by the virtual machine. Solidity developers do not need to understand this translation process as mature tools have already been implemented.
Since it is a “translation,” there will be some overhead involved. For engineers with low-level programming experience, they can directly write program logic using opcodes in Solidity, which achieves the highest efficiency and saves gas for user transactions. For example, the Seaport protocol launched by Opensea extensively uses inline assembly in smart contracts to reduce gas expenditure for users.
Therefore, if Parallel EVM can be implemented, it will not only bring parallelization capabilities but also optimize the performance of the entire EVM stack. Ordinary application developers will no longer need to spend significant efforts optimizing for gas savings because the underlying virtual machine will be powerful enough to level out these differences.
The “virtual machine” can also be referred to as the “execution layer,” which is the engine where smart contracts are compiled into opcodes and ultimately computed and processed. The “bytecode” defined by Ethereum Virtual Machine (EVM) has become an industry standard, and whether it is based on Ethereum Layer 2 networks 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, which is highly cost-effective.
As long as it fully complies with the “bytecode” standard, it can be called EVM, but the implementation methods can vary greatly. For example, the Ethereum client Geth implements the EVM standard using the Go language. However, the Ipsilon research team maintained an independent implementation of EVM developed in C++, which other Ethereum clients can directly call as an EVM execution.
For example, many industrially produced products have corresponding international standards. For instance, a product may need to have a bacterial count below a specific value before it can be sold, which is the “standard.” However, each factory can choose from dozens of different sterilization methods to meet this requirement, and some factories may find more cost-effective ways to meet this requirement, which is “practice.”
Since evmone has been implemented, other implementations can also be done. In this example of EVM, the standard of EVM defines some basic operation methods (“opcodes,” such as supporting basic arithmetic operations), and each opcode has a specific input and output. While meeting this standard, the implementation methods (practices) can vary greatly, providing a lot of customization space and engineering optimization possibilities.
In the Parallel EVM track, besides the highly anticipated Monad, there are also Sei, MegaETH, Polygon, Neon EVM, BSC, and Paradigm’s Reth client, which also aim to achieve parallelization.
From the perspective 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. In addition, Reth is an open-source client, and MegaETH will continue development partially based on Reth’s engineering.
Of course, there is competition among these teams, and not all technical details and engineering files have been fully disclosed. More comparisons will have to wait until they gradually become public. Perhaps this is like an arms race, similar to BTC Layer 2, Restaking, and Ethereum Layer 2. Although there are slight differences (and they are open-source) among the technologies, the uniqueness of building an ecosystem is more important.
For sequentially executed transactions, the bottleneck lies in the CPU and the process of reading and writing states. However, the advantage of this method is that it is simple and error-free, and all transactions can be executed step by step. For parallel execution virtual machines, there may be state conflicts, so additional checks need to be added before or after execution.
A simple example is if the virtual machine supports four threads for parallel execution and each thread can process a transaction simultaneously, if these four transactions all involve the same transaction pool on Uniswap, parallel computation cannot be achieved because each transaction affects the transaction price in the pool. However, if these four threads handle four completely unrelated tasks simultaneously, there is no problem.
This involves the design and engineering implementation of different teams, but it is necessary to ensure that after parallel execution, there is a module to detect conflicts and retry if conflicts occur. Of course, if possible conflicts in transactions can be anticipated and screened in advance, it can also increase the parallel efficiency of the entire virtual machine.
In addition to the engineering implementation differences of Parallel EVM, each team generally redesigns and enhances the read and write performance of the state database and designs a consensus algorithm. For example, Monad designs MonadDb and MonadBFT.
For Parallel EVM, there are two potential challenges: whether its long-term engineering value will be captured by Ethereum and the centralization of nodes.
Since various teams are still in the development and testing stages of Parallel EVM, they have not chosen to open source all engineering details, which is one of the current moats. However, once they enter the testnet and mainnet, 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 construction and build more ecosystem-level moats.
However, this problem 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 not forked for commercial projects). On the other hand, Monad’s positioning is different from Ethereum. Even if Ethereum achieves 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 that applies to all high-performance public chains is how to deploy more nodes to meet the basic requirements of users for permissionless and trustless interactions: decentralization. Perhaps some indicators can be quantified, such as “TPS divided by the hardware requirements of nodes.” This way, control variables can be implemented 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 can be deployed.
Next, we will continue to track the progress of various Parallel EVM projects and delve into their technologies and differences in detail.