What Does the Parallelization of EVM Mean? Is It the Endgame Under EVM Domination?
Can Parallel EVM Enable Existing Decentralized Applications to Achieve Internet-Level Performance?
TL;DR
The concept of Parallel EVM is being bet on by several leading VCs: Paradigm, Jump, Dragonfly, etc.
Representative projects include Monad, as well as Sei, MegaETH, Polygon, Neon EVM, BSC, etc. Some are L1, some are L2. Detailed differences between the teams are not yet fully disclosed.
Although Parallel EVM literally means "parallelization," it also represents specialized optimization for the performance of various EVM components. Thus, its efforts likely signify the performance limit under the EVM standard.
Challenges include reconstructing the entire tech stack, predicting potential transaction conflicts in advance, and the efficiency of re-execution upon conflicts.
Another challenge is how to build differentiation within the open-source ecosystem and find a balance between decentralization and performance.
Following widespread research and iterations on consensus algorithms, DA (Data Availability), and zero-knowledge proofs, the next hardcore technology to gain attention is Parallel EVM. The capital market has already invested hundreds of millions of dollars into this narrative, spawning several unicorn-level startups.
The community's interest in Parallel EVM originated from Georgios Konstantopoulos (CTO of Paradigm) and Haseeb Qureshi of Dragonfly independently mentioning this key term while forecasting trends for 2024 at the end of 2023. However, detailed discussions on this topic are scarce, and many believe it's not a new concept since both EVM and parallel computing are relatively mature concepts. Why then is combining these two terms considered an important trend?
Yet, it remains a niche topic, so much so that many research institutions' annual summaries and trend predictions do not mention Parallel EVM. Thus, it's still a new concept without widespread consensus. Like topics such as consensus algorithms and DA, it's purely technical, attracting even fewer followers.
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 amount of existing smart contracts while achieving high performance and parallel Layer1 throughput.
Paradigm Eager to Enter, Heavy Bets by the Jump
According to Fortune, Paradigm plans to lead the latest round of investment in Monad, aiming to raise $200 million at a valuation of $3 billion. Although this is the first Parallel EVM concept team Paradigm plans to invest in, they have been focusing on this technology for years. Georgios Konstantopoulos (CTO of Paradigm) mentioned this term back in 2021.
The origin of the term "Monad" is interesting. In the philosophical system of Leibniz, a Monad is a fundamental element of the universe, indivisible, not subject to physical influence entities, each reflecting the entire universe.
In computer science, a Monad is a design pattern in functional programming languages, helping programmers handle the complexity of the real world with near-mathematical purity, making the code more modular, understandable, and maintainable.
Interestingly, "Monad" and "Nomad" are anagrams.
Besides Monad, Georgios also mentioned Sei and Polygon when discussing this topic. However, another important reason he is optimistic about Parallel EVM is that they developed an Ethereum client called Reth. Its positioning is a high-performance Ethereum execution layer client implemented in Rust. Reth is developing rapidly, having just entered the Beta stage. Perhaps they will consider implementing Parallel EVM directly on Reth, but given the engineering volume, promoting Parallel EVM through investment in other teams might be a better choice. According to Monad's documentation, their engineering mainly uses C++ and Rust.
Reth was initially accused by the Erigon team of plagiarizing its open-source code for Akula, leading to the suspension of Akula's development due to lack of funds. Georgios responded that Reth is not a fork of any other client, and its code does not 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. Monad's founders come from Jump Trading, with extensive 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.
Early investor Dragonfly in Monad has also been focusing on related tracks, investing in NEAR, which focuses on sharding technology, as well as Layer1 like Aptos, Avalanche, and Nervos.
It's Finally the Execution Layer's Turn
In the past few Layer1 battles, the execution layer has always been overlooked, with discussions almost solely on innovations in consensus algorithms, whether it's Solana, Avalanche, or EOS, etc. Although they have many innovations at the execution layer, the community remembers more about their consensus algorithms, and the entire community also tends to think that these high-performance Layer1 achieve their performance through innovations in consensus algorithms.
But actually, that's not the case. If you want a high-performance Layer1, both the consensus algorithm and the execution layer need to be complementary, also in line with the theory of the weakest link. For those Layer1 based on EVM and only improving the consensus algorithm, enhancing performance requires stronger nodes. For example, BSC has set the block gas limit at 2000 TPS, requiring hardware configurations several times higher than Ethereum full nodes. Polygon theoretically can reach 1000 TPS, but usually only dozens to hundreds.
BSC archive nodes require at least a 16-core CPU and 128GB of memory, while Ethereum nodes only need at least a 4-core CPU and 16GB of memory.
The BSC team also realized these issues early on, so they are also developing Parallel EVM technology in collaboration with NodeReal. Only in this way can the number of transactions each block can handle be further increased, allowing more transactions to be executed in parallel, and raising the TPS limit.
Parallelization: Not Just Upgrading from Single-Core to Multi-Core CPUs
In most Layer1s, transactions are executed entirely in sequence, which can be thought of as a single-core CPU, where the current computation must be completed before the next one can begin. Although this method is slow, its advantage is simplicity and low system complexity.
However, if future Layer1s need to accommodate internet-scale user volumes, a single-core CPU will definitely not suffice. Therefore, upgrading to a multi-core CPU parallel virtual machine can process multiple transactions simultaneously, increasing throughput. However, this presents many engineering challenges, such as what to do when two simultaneously processed transactions write data to the same smart contract? A new mechanism must be designed to resolve this contradiction. For parallel execution of completely unrelated smart contracts, throughput can be scaled according to the number of parallel processing threads.
Moreover, Parallel EVM not only enhances parallel capabilities but also optimizes single-thread execution efficiency. Monad CEO Keone Hon stated, "...the real bottleneck of (EVM) lies in the frequent reading and writing of states during transaction processing..." He also mentioned that parallel execution is only part of the roadmap, and Monad's greater mission revolves around making EVM as efficient as possible.
Therefore, although Parallel EVM literally means "parallelization," it also represents specialized optimization for the performance of various EVM components. Thus, its efforts likely signify the performance limit under the EVM standard.
EVM Does Not Equal Solidity
Writing smart contracts is an essential skill for most Dapp developers. Engineers can implement corresponding logic based on business needs using Solidity or other high-level smart contract languages. However, EVM cannot directly understand the logic of Solidity; it needs to be "translated" (compiled) into a low-level language (opcode/bytecode) that the virtual machine can execute. Solidity developers do not need to understand this translation process, as mature tools have already implemented it.
Since it's a "translation," some overhead (additional costs) is generated. For engineers with low-level code experience, programming logic can be directly written in opcodes within Solidity, achieving the highest efficiency, i.e., saving Gas during user transactions. For example, the Seaport protocol launched by Opensea extensively uses inline assembly in smart contracts to minimize Gas expenses for users as much as possible.
Therefore, if Parallel EVM can ultimately be realized, it will not only bring parallelization capabilities but also optimize the entire EVM stack's performance. Ordinary application developers will not need to spend a lot of effort optimizing to save a bit of Gas, as the underlying virtual machine will be 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," the engine where smart contracts are compiled into opcodes and finally computed and processed. The "bytecode" defined by the Ethereum Virtual Machine (EVM) has become the industry standard, whether it's Ethereum's layer-2 networks or other independent Layer1. They prefer to be directly and fully compatible with the EVM standard, allowing developers to write a smart contract once and deploy it across multiple networks, offering high cost-effectiveness.
As long as it is fully compatible with the EVM's "bytecode" standard, it can be called an EVM, but the implementation methods can vary greatly. For example, the Ethereum client Geth implements the EVM standard in Go language. However, the Ethereum Foundation's execution layer research team, Ipsilon, maintains an independent EVM implementation developed in C++, which other Ethereum clients can directly call as an EVM execution.
Another example, many industrial products have corresponding international standards, such as a product needing to meet a specific bacterial count before it can be sold, which 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, which is "practice."
Since there is an implementation like evmone, other implementations can also be made. So, in the example of EVM, the EVM standard defines some basic operations "bytecode" (such as supporting basic arithmetic operations like addition, subtraction, multiplication, etc.), where each opcode has a definite input and output. Meeting this standard, the implementation (practice) methods can vary greatly, with a lot of room for customization and engineering optimization possibilities.
Differences and Similarities in Parallel EVM
In the Parallel EVM track, besides the hottest Monad, there are also Sei, MegaETH, Polygon, Neon EVM, BSC, etc., and Paradigm's Reth client also aims to implement parallelization features.
From a positioning perspective, Monad, Sei, Polygon, BSC are all Layer 1, while MegaETH might be Layer 2, and Neon EVM is based on the Solana network. Additionally, Reth is an open-source client, and MegaETH will also partially continue development based on Reth's engineering.
Of course, there are competitive relationships between these teams, and not all technical details and engineering files have been fully disclosed. More comparisons will have to wait until they gradually disclose more information. Perhaps this is like an arms race, similar to BTC Layer 2, Restaking, Ethereum Layer 2, etc. Although there are subtle differences between technologies (and they are open-source), what's more important is how to build the uniqueness of the ecosystem.
Technical Challenges of Parallel EVM
For sequentially executed transactions, the bottleneck lies in the CPU and the process of reading and writing states. But the advantage is that this method is simple enough and error-free, with all transactions executed in an orderly manner. However, for a parallel-executing virtual machine, state conflicts are possible, so judgment on this part is needed 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, what if these four transactions all involve trading with the same pool on Uniswap? Then parallel computation cannot be performed, as each transaction will affect the trading price of that pool. But if these four threads simultaneously handle four completely unrelated matters, then there's no problem.
This involves different teams' designs and engineering implementations, but at least it's necessary to ensure that after parallel execution, a module is needed to detect conflicts. If conflicts are encountered, re-execution is required. Of course, if potential conflicts can be predicted and screened in advance, the overall parallel efficiency of the virtual machine can be increased.
Besides the engineering implementation differences of the Parallel EVM virtual machine, each team generally redesigns and enhances the read-write performance of the state database and designs a consensus algorithm to match, such as Monad's MonadDb and MonadBFT.
Other Challenges
For Parallel EVM, there are at least another two potential 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 with Parallel EVM technology, they have not yet chosen to open-source all engineering details, which is currently one of their moats. But once they enter the testnet and mainnet, these engineering files will be public and may be absorbed by Ethereum or other Layer1. So at that point, it's necessary to accelerate ecosystem construction and build more ecological moats.
However, this issue 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, which allows code to be public but does not allow forking for commercial projects). On the other hand, Monad's positioning is different from Ethereum's. 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 application scenarios.
Another challenge, common to all high-performance Layer1, is how to deploy more nodes to meet the basic requirements of being permissionless and trustless: decentralization. Perhaps some indicators can be quantified, such as "TPS divided by the hardware requirements of nodes," allowing for controlled variable comparisons to see which Layer1/client has higher TPS under specific hardware requirements. After all, the lower the hardware requirements for nodes, the more likely there are to be more nodes.
Next, we will continue to track the progress of various Parallel EVM projects and discuss their technologies and differences in detail.