What is the significance of EVM parallelization? Or is it the end of EVM hegemony?

avatar
ChainFeeds
5 months ago
This article is approximately 2561 words,and reading the entire article takes about 4 minutes
Can Parallel EVM enable existing decentralized applications to achieve Internet-level performance?

TL;DR

  • The Parallel EVM concept is being bet on by several leading VCs: Paradigm, Jump, Dragonfly, etc.

  • The representative project is Monad, as well as Sei, MegaETH, Polygon, Neon EVM, BSC, etc. Some are L1, 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 are likely to 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 efficiency of re-execution after conflicts.

  • Challenge: How to build differentiation in the open source ecosystem and how to find a balance between decentralization and performance.

After the consensus algorithm, DA (data layer), and zero-knowledge proof technology have been widely studied and iterated, the next hard-core technology to attract attention is Parallel EVM. The capital market has also invested hundreds of millions of dollars in this narrative, and many unique technologies have been born. A beast-level startup.

The community began to pay attention to Parallel EVM (EVM parallelization)originGeorgios Konstantopoulos (CTO of Paradigm) and Dragonflys Haseeb Qureshi coincidentally mentioned the same keyword when looking forward to 2024 trends at the end of 2023. However, there are not many details on this topic, and many people believe that this is not a new concept. EVM and parallel computing are relatively mature concepts respectively. Why is it an important trend to combine these two words? Woolen cloth?

What is the significance of EVM parallelization? Or is it the end of EVM hegemony?

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 has made a big bet

According to Fortunereport, Paradigm is planning to lead Monad’s latest round, raising $200 million at a $3 billion valuation. Although this is the first Parallel EVM concept team that Paradigm plans to invest in, they have actually been paying attention to this technology for many years. Georgios Konstantopoulos (Paradigm’s CTO) once discussed it in 2021mentiongot this word.

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 refers to nomad, and digital nomad refers to digital nomad/digital herder.

Besides Monad, GeorgiosdiscussSei and Polygon were also mentioned on 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 RD engineering, it may be a better choice to invest in other teams to promote Parallel EVM. According to Monads 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. (https://thedefiant.io/paradigm-accused-copying-code)

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 execution layer’s turn

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. PolygontheoryIt can reach 1,000 TPS, but usually only dozens to hundreds.

BSC archive nodeRequires at least 16-core CPU and 128 G memory,Ethereum nodeRequires 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 NodeRealcooperative developmentParallel 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 CPUs

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 Honexpress, ...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 Monads larger mission is to focus on EVM and make it as efficient as possible.

Therefore, although Parallel EVM literally means parallelization, it is actually a special optimization of the performance of each component of EVM, so its efforts are likely to 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 translation, so there will also be some overhead (extra overhead). For engineers with experience in low-level coding, they can write program logic directly using opcodes in Solidity. This can achieve the highest performance, which means that users can save Gas when making transactions. For example, the Seaport protocol launched by Opensea uses inline assembly extensively in smart contracts to reduce gas expenses for users as much as possible.

Therefore, if Parallel EVM can be finally implemented, it will not only bring parallelization capabilities, but also optimize the performance of the entire EVM stack. Ordinary application developers do 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, and standard does not equal engineering practice

The virtual machine can also be called the execution layer. It is the engine in which smart contracts are finally calculated and processed after they are compiled into opcodes. The bytecode defined by the Ethereum Virtual Machine (EVM) has now become an industry standard. Whether it is a second-layer network based on Ethereum or other independent public chains, they are more willing to be directly and fully compatible with the EVM standard before developing Authors can write smart contracts once and deploy them 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. But the Ethereum Foundation’s executive research team IpsilonmaintainAn independent implementation of EVM developed in C++ has been developed. 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 isevmoneimplementation, 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 Paradigms Reth client also wants to implement 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 various teams are still in the development and testing stages of Parallel EVM technology, they have not yet chosen to open source all engineering details. This is one of the current moats. However, after entering the test network and main network, these project documents 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.

Original article, author:ChainFeeds。Reprint/Content Collaboration/For Reporting, Please Contact report@odaily.email;Illegal reprinting must be punished by law.

ODAILY reminds readers to establish correct monetary and investment concepts, rationally view blockchain, and effectively improve risk awareness; We can actively report and report any illegal or criminal clues discovered to relevant departments.

Recommended Reading
Editor’s Picks