API/RSS

Social

What is the significance of EVM parallelization, or is it the end of EVM hegemony?

24-03-28 14:00

Read this article in 25 Minutes

AI summary

View the summary

Original source: Chainfeeds

TL;DR

1. Parallel EVM concept is developing Bet on by several leading VCs: Paradigm, Jump, Dragonfly, etc.

2. The representative project is Monad, and there are also 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.

3. 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 Represents the performance limit under the EVM standard.

4. Difficulty: In addition to reconstructing the entire technology stack, there is also how to predict in advance whether parallel transactions will conflict, and how to deal with conflicts when they occur. re-execution efficiency.

5. 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 extensively studied and iterated, the next hard-core technology to be focused on is Parallel EVM, the capital market has also invested hundreds of millions of dollars in this narrative, and many unicorn-level startups have been born.

The community began to pay attention to Parallel EVM (EVM parallelization) which originated from Georgios Konstantopoulos (CTO of Paradigm) and Haseeb Qureshi of Dragonfly coincidentally looking forward to the end of 2023 The same keyword was mentioned when talking about 2024 trends. 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?

But this is still a very niche topic, so if you look at Parallel EVM is not mentioned in the annual summaries and trend forecasts of many research institutions. 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 the Jump system has made a big bet

According to "Fortune" Report, Paradigm is planning to lead Monad’s latest round, raising $200 million at a $3 billion valuation. Although this is the first team Paradigm plans to invest in the Parallel EVM concept, 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 real world with almost mathematical purity. complexity, 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 herdsman.

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 Beta. Perhaps they will consider implementing Parallel EVM directly on Reth, but considering the amount of R&D engineering, it may be a better option 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 led to the Akula project's lack of funds to 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, Erigan, 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 also 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 times In the public chain war, the execution layer has always been ignored. 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 TheoryIt can reach 1000 TPS, usually only tens to hundreds.

BSC archive node requires at least 16-core CPU and 128G memory, Ethereum node only requires at least a 4-core CPU and 16G of memory.

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

Parallel: not only upgrade from single-core to multi-core CPU

In most blocks In the chain system, 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 parallel 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 state while processing things..." He also said that parallel execution is only part of the roadmap, and Monad's larger mission is around EVM to make it as efficient as possible.

So, although Parallel EVM literally means "parallelization", it is actually a special optimization of the performance of each component of EVM, so its The effort likely represents the performance limit under the EVM standard.

EVM is not equal to Solidity

Writing smart contracts is a necessary 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/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 during 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.

So, 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"

" "Virtual machine" can also be called the "execution layer", which is the engine that ultimately calculates and processes smart contracts 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.

So 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 layer research team Ipsilon maintains a C++ The developed EVM is implemented independently, and other Ethereum clients can directly call this library to execute as EVM.

For example, many industrially produced products have their 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 "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, except for the most popular Monad In addition, Sei, MegaETH, Polygon, Neon EVM, BSC, etc., as well as Paradigm's Reth client also want to implement parallelization functions.

From a positioning perspective, 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. of. In addition, Reth is an open source client, and MegaETH will continue to be developed partly 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 for them to follow. It can only unfold gradually when it becomes public. 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 status. 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 four threads for parallel execution, and each thread can process a transaction at the same time, if these four The transactions are all transactions in the same trading pool on Uniswap, so they cannot be calculated in parallel, because each transaction will affect the transaction price of this trading 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.

Challenges

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

Since each team is still in the development and testing stage of Parallel EVM technology, they have not yet chosen to open source all the 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 so serious. On the one hand, for Crypto developers, there are now more open source licenses to choose from (such as Uniswap’s) The code can be made public, but forking is not allowed to be a commercial project license). On the other hand, the positioning of Monad is inherently different from 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 the same for all high-performance public chains is how to deploy more nodes to satisfy users’ permissionless and trustless needs. ) basic requirement: 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.