What is the significance of parallelization of EVM? Or is it the endgame under EVM hegemony?

TL;DR

• The Parallel EVM concept is being bet on by several leading VCs: Paradigm, Jump, Dragonfly, etc.
• The representative project is Monad, and there are also Sei, MegaETH, Polygon, Neon EVM, BSC, etc. Some are L1, and some are L2. There is no complete public information on the specific differences between the teams.
• Although Parallel EVM literally means “parallelization”, it is actually a special optimization of the performance of each component of EVM, so its efforts may represent the performance limit under the EVM standard.
• Difficulty: In addition to reconstructing the entire technology stack, there is also how to predict in advance whether parallel transactions will conflict, and the re-execution efficiency after encountering conflicts.
• Challenge: How to build differentiation in the open source ecosystem and how to find a balance between decentralization and performance.

After consensus algorithms, DA (data layer), and zero-knowledge proof technologies have been widely researched and iterated, the next hard-core technology to receive attention is Parallel EVM. The capital market has invested hundreds of millions of dollars in this narrative, and several unicorn-level startups have been born.

The community began to pay attention to Parallel EVM (EVM parallelization) when Georgios Konstantopoulos (CTO of Paradigm) and Haseeb Qureshi of Dragonfly mentioned the same keyword when they looked forward to the trends in 2024 at the end of 2023. However, there are not many details on this topic, and many people think that this is not a new concept. EVM and parallel computing are relatively mature concepts. Why is combining these two words an important trend?

But this is still a very niche topic, so much so that if you look at 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 yet formed a large-scale consensus. Moreover, this concept is similar to topics such as consensus algorithm and DA. They are all purely technology-related, so there are even fewer people paying attention to it.

The most direct advantage of Paralle 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 not only utilize (a large number of mature) existing smart contracts, but also achieve high-performance, parallelized public chain throughput.

Paradigm has been looking forward to entering the game for a long time, and Jump is betting heavily.

According to Fortune, Paradigm is planning to lead Monad’s latest round of investment, raising $200 million at a $3 billion valuation. Although this is the first team 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 in 2021.

The origin of the word monad is also interesting. In the philosophical system of the philosopher Leibniz, Monads are the basic elements that constitute the universe. They are indivisible entities that are not affected by physics. Each Monad reflects the entire universe and was once translated as “monad” in Chinese. .

In computer science, Monad is a design pattern in functional programming languages that helps programmers deal with the complexity of the real world with almost mathematical purity, making the code more modular, easier to understand and maintain.

Another interesting thing is that Monad and Nomad are anagrams of each other. Nomad means nomad, while digital nomad means digital nomad/digital nomad.

In addition to Monads, 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, Reth. It is positioned as a high-performance Ethereum execution layer client, implemented in the Rust language. Reth is being developed at a rapid pace and has just entered the Beta stage. Maybe they will consider implementing Parallel EVM directly on Reth, but considering the amount of R&D engineering, 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 engineering.

When Reth was launched, it was also accused by Erigon team members of plagiarizing its Akula open source code, which also caused the Akula project to lack funds and stop development. Georgios responded that Reth is not a fork of any other client, nor does the code come from any other client, but it is indeed influenced and inspired by Geth, Erigon and Akula. ()

Another core participant is Jump Trading and Jump Capital. The founder of Monad comes from Jump Trading and has rich 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. .

Dragonfly, an early investor in Monad, has also been paying attention to related tracks. It has invested in NEAR, which focuses on sharding technology, as well as public chains such as Aptos, Avalanche, and Nervos.

Upgrading the consensus algorithm is not enough, it is finally the turn of the execution layer

In the past few public chain wars, the execution layer has been a neglected place. They almost only talk about the innovation of consensus algorithms, whether it is Solana, Avalanche or EOS. Although they have a lot of innovations in the execution layer, the community still remembers the consensus algorithm they used, and the entire community also thinks that the performance of these high-performance public chains comes from the innovation of the consensus algorithm.

But it is not the case. If you want to obtain a high-performance public chain, the consensus algorithm and execution layer need to be matched, which is also in line with the shortcomings of the wooden barrel. For those public chains that are based on EVM and only improve the consensus algorithm, stronger nodes are needed to improve performance. For example, BSC limits the gas that can be processed by a block to the level of 2000 TPS, which requires machine configuration several times the investment of an Ethereum full node. Polygon can theoretically reach 1000 TPS, but usually it is only tens to hundreds.

BSC archive nodes require at least 16-core CPU and 128 G memory, and Ethereum nodes only require at least 4-core CPU and 16 G memory.

The BSC team has long been aware of these problems, so it is also working with NodeReal to develop Parallel EVM technology. Only in this way can we further increase the number of transactions that each block can process, allow more transactions to be executed in parallel, and increase the TPS upper limit.

Parallelism: Not only upgrading from single-core to multi-core CPU

In most blockchain systems, transactions are executed completely in sequence. You can think of it as a single-core CPU. The next calculation can only be performed after the current calculation is completed. Although this method is slow, its advantages are simplicity and low system complexity.

But if the future blockchain system needs to access Internet-level user scale, a single-core CPU will definitely not be enough. Therefore, upgrading to a parallelized virtual machine with multi-core CPU can process multiple transactions at the same time and increase throughput. However, there are many challenges in engineering implementation. For example, what should I do if two transactions processed at the same time write data to the same smart contract? It is necessary to design a new mechanism to resolve this contradiction. For the parallel execution of other completely unrelated smart contracts, the throughput can be increased according to the number of parallel processing threads and scale.

In addition, Parallel EVM not only improves parallel capabilities, but also optimizes single-threaded execution efficiency. Monad CEO Keone Hon said, “…the real bottleneck (of EVM) is the frequent reading and writing of status when processing things…”. He also said that parallel execution is only part of the roadmap, and Monad’s larger mission is to focus on EVM and make it as efficient as possible.

Therefore, although the literal meaning of Parallel EVM only represents “parallelization”, it is actually a special optimization of the performance of each component of EVM, so its efforts may represent the performance limit under the EVM standard.

EVM is not equal to Solidity

Writing smart contracts is an essential skill for most blockchain developers. Engineers can use Solidity or other high-level smart contract languages to write corresponding logic implementations based on business needs. However, the EVM cannot actually directly understand the logic of Solidity. It needs to go through some “translation” and translate (compile) it into a low-level language that the machine can understand (opcode operation code / bytecode bytecode) before it can be read by the virtual machine. implement. Solidity developers do not need to understand this translation process, because there are already mature tools to implement it.

After all, it is a “translation”, so there will be some overhead. For engineers with low-level code experience, they can directly use opcodes to write program logic in Solidity, which can achieve the highest efficiency, that is, users can save Gas when trading. For example, the Seaport protocol launched by Opensea uses a lot of inline assembly in smart contracts to reduce Gas expenses for users as much as possible.

Therefore, if Parallel EVM can be finally realized, it will not only bring parallelization capabilities, but also optimize the performance of the entire EVM stack. Ordinary application developers will not need to spend a lot of energy on optimization just to save a little Gas, because the underlying virtual machine is powerful enough to smooth out these differences.

EVM performance varies, “standard” does not equal “engineering practice”

The “virtual machine” can also be called the “execution layer”. It is the engine that is ultimately calculated and processed after the smart contract is compiled into opcodes. The “bytecode” defined by the Ethereum Virtual Machine (EVM) has become the industry standard. Whether it is a second-layer network based on Ethereum or other independent public chains, they are more willing to directly and fully compatible with the EVM standard. Developers can write a smart contract once and deploy it to multiple networks, which is extremely cost-effective.

Therefore, as long as it is fully compatible with the “bytecode” standard of EVM, it can be called EVM, but the implementation methods can vary widely. For example, the Ethereum client Geth uses the Go language to implement the EVM standard. However, Ipsilon, the execution layer research team of the Ethereum Foundation, maintains an independent implementation of EVM developed in C++. Other Ethereum clients can directly call this library to execute as EVM.

For example, many industrially produced products have corresponding international standards. For example, when a product leaves the factory, the number of colonies must be less than a certain value before it can be sold. This is the “standard.” But how to meet this factory standard, each factory can choose from dozens of different sterilization methods, and some factories can find more cost-effective ways to meet this requirement. This is “practice”.

Since there is an implementation of evmone, other implementations can also be made. So in this example of EVM, the EVM standard defines some basic operation methods “bytecode” (such as supporting the most basic arithmetic such as addition, subtraction, multiplication, etc.). When each bytecode has a certain input, there is Definite output. When it comes to meeting this criterion, implementations (and practices) vary widely, with plenty of room for customization and possibilities for engineering optimization.

Similarities and Differences of Parallel EVM

In the Parallel EVM track, in addition to the hottest Monad, there are also Sei, MegaETH, Polygon, Neon EVM, BSC, etc., and Paradigm’s Reth client also wants to achieve parallelization functions.

From a positioning perspective, Monad, Sei, Polygon, and BSC are all Layer 1 blockchains, while MegaETH may be Layer 2. Neon EVM is based on the Solana network. In addition, Reth is an open source client, and MegaETH will continue to be developed partially based on Reth projects.

Of course, there is still competition between these teams, and all technical details and engineering documents have not been fully disclosed. More comparisons will have to wait until they are gradually disclosed. Perhaps this is like an arms race again, like BTC Layer 2, Restaking, and Ethereum Layer 2. Although there are subtle differences between the technologies (and open source), what is more important is how to build the uniqueness of the ecosystem.

Technical Difficulties of Parallel EVM

For sequentially executed transactions, the bottleneck is the CPU and the process of reading and writing state. But the advantage is that this method is simple enough, error-free, and all tasks can be completed step by step. For virtual machines that execute in parallel, there may be state conflicts, so this part of the judgment needs to be added before or after execution.

A simple example is that if the virtual machine supports parallel execution of four threads, and each thread can process a transaction at the same time, if these four transactions are all transactions with the same transaction pool on Uniswap, they cannot be executed in parallel. Calculation, because each transaction will affect the transaction price of this transaction pool. But if these four threads are working on four completely unrelated things at the same time, then there is no problem.

This will involve the design and engineering implementation of different teams, but at least what must be ensured is that after parallel execution, a module is needed to detect conflicts and re-execute if conflicts are encountered. Of course, if transactions that may conflict can be predicted and screened in advance, the parallel efficiency of the entire virtual machine can also be increased.

In addition to the differences in the engineering implementation of the Parallel EVM virtual machine, each team will generally redesign and enhance the read and write performance of the state database, and design a consensus algorithm, such as MonadDb and MonadBFT designed by Monad.

challenge

For Parallel EVM, there are two possible challenges: whether the long-term engineering value will be captured by Ethereum; and the centralization of nodes.

Since the teams are still in the development and testing stage of Parallel EVM technology, they have not yet chosen to open source all the engineering details, which is one of the current moats. However, after entering the test network and main network, these engineering files will be made public and may also be absorbed by Ethereum or other public chains. Therefore, at that point in time, it is necessary to promote ecological construction faster and build more ecological moats.

However, this problem is not that serious. On the one hand, for Crypto developers, there are now more open source licenses to choose from (such as Uniswap’s license that can make the code public but does not allow forking into commercial projects). On the other hand, the positioning of Monad is inherently different from that of Ethereum. Even if Ethereum can achieve single-socket finality (SSF) in the future, the finality of transactions will still be at least 12 seconds, which is far from enough for higher-frequency application scenarios.

Another challenge that is common to all high-performance public chains is how to deploy more nodes to meet users’ basic requirements of permissionless and trustless: decentralization. Perhaps some indicators can be quantified, such as “TPS divided by the hardware requirements of the node”, so that we can control variables and compare which public chain/client has a higher TPS based on specific hardware requirements. After all, the lower the hardware requirements of a node, the higher the number of nodes possible.

Next, we will continue to track the progress of each Parallel EVM project and discuss their technologies and differences in detail.