What's the point of parallelizing EVM? Or is it the endgame under EVM hegemony?

Author: Zhixiong Pan, source: author's blog

TL;DR

< ol class=" list-paddingleft-2">

The Parallel EVM concept is being used by several leading VCs Bets: Paradigm, Jump, Dragonfly and more.

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

Parallel EVM although the literal meaning only represents " "Parallelization", but in fact it is also a special optimization of the performance of each component of the EVM, so its efforts are likely to represent the performance limit under the EVM standard.

Difficulty: In addition to reassessing the entire technology stack In addition to the structure, 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 , how to find a balance between decentralization and performance.

Both consensus algorithm, DA (data layer), zero After knowledge proof technology has been extensively researched 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 unicorn-level start-ups have been born.

The community is beginning to pay attention to Parallel EVM (EVM parallelization) Origin Georgios Konstantopoulos (CTO of Paradigm) and Haseeb Qureshi of Dragonfly 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. Why combine these two words? Is being together 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 allow 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 "Fortune"< a href="https://fortune.com/crypto/2024/03/11/monad-paradigm-venture-capital-crypto-jump-bitcoin/" style="font-size: 18px; text-align: justify; ">ReportsParadigm is planning to lead Monad’s latest round of investment, 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 announced it in 2021Mentions 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 type of functional programming language Design patterns help programmers deal with real-world complexities with near-mathematical purity, making code more modular, easier to understand, and easier to maintain.

Another interesting thing is that Monad and Nomad are "anagrams" of each other (Anagram), nomad means nomad, and digital nomad means digital nomad/digital herder.

In addition to Monad, Georgios Sei and Polygon were also mentioned when discussingthis 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 accused by members of the Erigon team of plagiarizing its Akula open source code. This also resulted in the Akula project being halted due to lack of funds. 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. (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; an investor in Sei There is 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 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 Theoretically can reach 1000 TPS, which is usually only a few Ten to hundreds.

BSC Archive NodeRequires at least 16-core CPU and 128G memory, Ethereum nodeJust need at least 4-core CPU and 16G memory.

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 when things are processed frequently Read and write status...". 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 the majority of blocks Essential skills for chain 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 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. However, Ipsilon maintains an independent implementation of EVM developed in C++, and other Ethereum clients This library can be called directly to execute as an 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 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 evmone  can also be implemented in other ways. 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, there are Sei, MegaETH, Polygon, Neon EVM, BSC etc. And Paradigm's Reth client also wants to implement parallelization functionality.

From a positioning perspective, Monad, Sei, Polygon, and BSC are all Layer 1 blockchains, while MegaETH may be Layer 2 and Neon EVM. It is based on the Solana network. 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 up. 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, in case 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. If conflicts are encountered Just re-execute. Of course, if you can predict and screen for possible conflicting transactions in advance, you can also increase the parallel efficiency of the entire virtual machine.

In addition to the engineering implementation differences 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 accordingly , 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 it is not allowed to fork into commercial projects). 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.