The Impact of Parallelizing the EVM: Endgame of Its Dominance？

TL;DR

1. 1. Several top VCs, including Paradigm, Jump, and Dragonfly, are investing in the concept of Parallel EVM.
2. 1. Representative projects in this domain include Monad, Sei, MegaETH, Polygon, Neon EVM, and BSC, operating on both Layer 1 (L1) and Layer 2 (L2) solutions.
3. 1. However, there’s limited public information available regarding the specific differences between the teams.
4. 1. While “parallelization” is the literal meaning of Parallel EVM, it denotes a specialized optimization aimed at enhancing various aspects of EVM’s performance, potentially pushing the boundaries of EVM’s capabilities.
5. 1. Challenges include the need to refactor the entire technology stack and address issues such as predicting conflicts among parallel transactions and efficiently handling conflicts if they arise.
6. 1. Another challenge is establishing differentiation in the open-source ecosystem while balancing decentralization with performance.

After extensive research and iteration on consensus algorithms, data layers (DA), and zero-knowledge proof technology, attention has shifted towards the next frontier in hardcore technology: Parallel EVM. This trend has already attracted significant investment from the capital market, with hundreds of millions of dollars being poured into the development of several unicorn-level startups.

The spotlight on Parallel EVM, also known as EVM parallelization, intensified when Georgios Konstantopoulos, CTO of Paradigm, and Haseeb Qureshi of Dragonfly coincidentally highlighted this concept at the close of 2023 while discussing future trends for 2024. Despite this attention, detailed discussions on the topic have been sparse, leading many to dismiss it as anything particularly novel. Given that both the Ethereum Virtual Machine (EVM) and parallel computing are well-established concepts, what elevates the fusion of these two terms to the status of an important emerging trend remains unclear.

However, Parallel EVM remains a highly specialized subject. It is notable that in the annual summaries and trend forecasts of numerous research institutions, Parallel EVM does not garner mention. Consequently, it remains a nascent concept lacking widespread consensus. Furthermore, akin to concepts such as consensus algorithms and decentralized applications (DA), Parallel EVM is inherently technical, thus limiting its audience to an even narrower scope.

The primary benefit of Parallel EVM lies in its ability to empower existing decentralized applications to attain performance levels akin to those of the Internet. In fact, it could be argued that Parallel EVM stands alone as a novel technology capable of leveraging a vast array of established smart contracts while achieving high-performance and parallel throughput on public chains.

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

“Fortune” reports that Paradigm intends to spearhead the latest funding round for Monad, aiming to raise $200 million with a valuation of $3 billion. While this marks Paradigm’s initial venture into backing a team with a Parallel EVM concept, they have been closely monitoring this technology for several years. Georgios Konstantopoulos, Paradigm’s CTO, first referenced this term in 2021.

The etymology of “Monad” adds another layer of intrigue. In philosopher Leibniz’s system, Monad signifies the fundamental element constituting the universe. These indivisible entities remain impervious to physical influences, with each reflecting the entirety of the universe, known as “单子” in Chinese.

In the realm of computer science, Monad serves as a design pattern within functional programming languages, aiding programmers in navigating real-world complexities with near-mathematical precision. This approach fosters code modularity, comprehension, and maintenance.

A noteworthy tidbit is the linguistic symmetry between Monad and Nomad, the latter denoting a wanderer, and “digital nomad” referencing a wanderer in the digital sphere.

Georgios, in his discourse on the topic, also referenced Sei and Polygon. However, his optimism towards Parallel EVM is bolstered by the development of Reth, an Ethereum client engineered by Paradigm. Positioned as a high-performance Ethereum execution layer client built in Rust, Reth is rapidly advancing and has recently transitioned to the Beta stage. While the prospect of integrating Parallel EVM directly into Reth is considered, the considerable engineering effort involved suggests that supporting Parallel EVM through investments in other teams might be a more viable option. Monad’s documentation reveals their predominant use of C++ and Rust in their engineering endeavors.

Upon Reth’s inception, accusations surfaced from members of the Erigon team, alleging plagiarism of their open-source code, Akula, leading to diminished funding for the Akula project. Georgios refuted these claims, asserting that Reth is neither a derivative nor a fork of any other client, although it draws inspiration from Geth, Erigon, and Akula.

Another pivotal player is Jump Trading and Jump Capital, with Monad’s founder originating from Jump Trading, boasting extensive experience in high-frequency trading. Sei counts Jump Capital among its investors, with Jump’s involvement extending deeply into the Solana ecosystem, spanning infrastructure and projects.

Dragonfly, an early investor in Monad, has also kept a keen eye on related developments, with investments in NEAR, focusing on sharding technology, alongside Aptos, Avalanche, Nervos, and other public chains.

Upgrading consensus algorithms is not enough, it’s finally the turn of the execution layer

In recent battles among public chains, the spotlight has consistently bypassed the execution layer, instead fixating almost exclusively on innovative consensus algorithms, whether it be Solana, Avalanche, or EOS, among others. Despite significant innovations in the execution layer by these chains, the community tends to primarily recall their employed consensus algorithms. Moreover, there’s a prevailing notion within the community that the superior performance of these high-throughput public chains stems solely from their groundbreaking consensus algorithms.

However, achieving a high-performance public chain necessitates a symbiotic relationship between both the consensus algorithm and the execution layer, echoing the principle of a chain being only as strong as its weakest link. Public chains reliant on the Ethereum Virtual Machine (EVM), and solely focusing on enhancing their consensus algorithm, encounter performance bottlenecks that demand increasingly robust nodes. Take, for instance, Binance Smart Chain (BSC), which caps block Gas processing at 2000 transactions per second (TPS). To support this, node configurations must exceed those of an Ethereum full node by several multiples. While Polygon theoretically boasts a 1000 TPS capacity, it typically achieves only tens to hundreds.

BSC archive nodes necessitate a minimum of 16-core CPUs and 128GB of memory, compared to Ethereum nodes, which require at least 4-core CPUs and 16GB of memory.

Recognizing these challenges, the BSC team has entered into collaboration with NodeReal to develop Parallel EVM technology. This innovation aims to further enhance transaction throughput per block by enabling parallel transaction execution, consequently raising the upper limit of TPS.

Parallel: Upgrading from a single-core to a multi-core CPU

In most blockchain systems, transactions follow a strict sequential order, akin to a single-core CPU where each calculation must wait for the preceding one to finish. Despite its simplicity and low system complexity, this approach is relatively slow.

However, as future blockchain systems aim to accommodate Internet-scale user bases, relying solely on a single-core CPU becomes inadequate. Therefore, transitioning to a multi-core CPU with parallelized virtual machines enables the simultaneous processing of multiple transactions, thereby boosting throughput. Yet, engineering this upgrade presents numerous challenges, such as managing conflicts when two concurrently processed transactions attempt to modify the same smart contract. Addressing this necessitates the development of novel mechanisms.

For unrelated smart contracts executed in parallel, throughput can be further increased by scaling according to the number of concurrent processing threads. Additionally, Parallel EVM not only augments parallel capabilities but also enhances the efficiency of single-thread execution. Keone Hon, CEO of Monad, highlighted that the primary bottleneck of EVM lies in the frequent reads and writes of states. He emphasized that while parallel execution is a pivotal aspect of the roadmap, Monad’s overarching goal is to optimize EVM’s efficiency to its fullest potential.

Thus, while Parallel EVM inherently entails “parallelization,” it primarily serves as a specialized optimization of various EVM components’ performance. Consequently, its endeavors likely delineate the performance boundaries within the EVM standard.

EVM is not equal to Solidity

Writing smart contracts is a vital skill for blockchain developers, necessitating the ability to implement logic based on business requirements using Solidity or other high-level languages. However, the Ethereum Virtual Machine (EVM) doesn’t directly comprehend Solidity logic; it requires translation into low-level bytecode for execution. Solidity developers typically rely on existing tools to handle this translation process.

This translation incurs overhead, but engineers familiar with low-level code can bypass it by directly coding logic using opcodes in Solidity, resulting in optimal efficiency and gas savings for user transactions. For instance, Opensea’s Seaport protocol leverages inline assembly extensively in smart contracts to minimize gas costs for users.

The potential implementation of Parallel EVM holds promise not only for introducing parallel capabilities but also for optimizing the overall performance of the EVM stack. This advancement would alleviate the need for application developers to dedicate significant efforts to gas optimization, as the underlying virtual machine would already efficiently manage such differences.

Differences in EVM Performance, “Standard” Does Not Equal “Engineering Practice”

The engine where smart contracts are compiled into opcodes and processed is often referred to as the “execution layer” or “virtual machine.” The bytecode established by the Ethereum Virtual Machine (EVM) has emerged as an industry norm. Whether on Ethereum’s layer 2 networks or other independent public chains, compatibility with the EVM standard is highly favored. Developers benefit from the ability to write a smart contract once and deploy it across multiple networks, resulting in considerable cost savings.

Although adherence to the EVM bytecode standard qualifies a system as EVM-compatible, the methods of implementation can vary significantly. For instance, the Ethereum client Geth employs the Go language to implement the EVM standard, while the Ethereum Foundation’s research team Ipsilon maintains an independent EVM implementation developed in C++. Other Ethereum clients can directly utilize this implementation as the EVM execution engine.

Analogously, various industries adhere to international standards for their products. For instance, a product must meet a specified bacterial count threshold before it can be sold, representing the “standard.” However, individual factories may employ diverse sterilization methods to meet this requirement, with some opting for more cost-effective approaches, exemplifying the “practice.”

The existence of implementations such as evmone indicates the feasibility of alternative approaches. Consequently, within the context of EVM, the standard delineates fundamental bytecode operations (e.g., basic arithmetic functions like addition, subtraction, multiplication), each bytecode yielding specific outputs based on defined inputs. While compliance with this standard is essential, the methodologies employed in practice can vary widely, presenting ample room for customization and engineering optimizations.

Similarities and Differences of Parallel EVM

In the Parallel EVM track, besides the widely known Monad, other prominent contenders include Sei, MegaETH, Polygon, Neon EVM, BSC, and Paradigm’s Reth client, which also strives to integrate parallelization.

In terms of their positioning, Monad, Sei, Polygon, and BSC are categorized as Layer 1 blockchains, whereas MegaETH could potentially function as a Layer 2 solution, and Neon EVM operates within the Solana network framework. Furthermore, Reth stands out as an open-source client, with MegaETH poised to continue its development utilizing certain aspects of Reth’s engineering.

Naturally, there exists competition among these teams, and comprehensive technical specifications and engineering documentation have not yet been fully disclosed. Further comparisons will need to await gradual revelations in the future. This dynamic may resemble an arms race akin to developments seen in BTC Layer 2, Restaking, and Ethereum Layer 2. Despite nuanced technical distinctions and the open-source nature of these projects, the crucial factor lies in establishing the distinctiveness of each ecosystem.

Technical Challenges of Parallel EVM

The bottleneck in sequentially executed transactions stems from CPU operations and the process of reading and writing states. However, this method offers simplicity, accuracy, and the ability to execute transactions step by step. Conversely, virtual machines executing in parallel may encounter state conflicts, necessitating additional checks before or after execution.

Consider a scenario where a virtual machine supports four threads for parallel execution, with each thread capable of processing a transaction simultaneously. If all four transactions involve the same transaction pool on Uniswap, parallel computation is unfeasible due to the potential impact on the pool’s transaction price. Yet, if these threads handle entirely unrelated tasks, parallel execution poses no issue.

Addressing potential conflicts post-parallel execution requires a dedicated module for conflict detection and re-execution if conflicts arise. Moreover, preemptive screening of potentially conflicting transactions can bolster the overall parallel efficiency of the virtual machine.

Aside from the engineering implementations specific to Parallel EVM, teams typically focus on redesigning and optimizing the read/write performance of the state database. Additionally, they devise consensus algorithms such as Monad’s MonadDb and MonadBFT.

Challenges

For Parallel EVM, two potential challenges emerge: the capture of long-term engineering value by Ethereum and node centralization.

Currently, various teams are in the developmental and testing phases of Parallel EVM technology, with none opting to open-source all engineering details yet, constituting a current obstacle. However, upon their integration into testnet and mainnet, these engineering specifications will become public and could potentially be integrated by Ethereum or other public chains. Consequently, there arises a need to expedite ecosystem development and establish additional barriers at the ecosystem level.

Nevertheless, this issue does not pose an insurmountable hurdle. On one hand, crypto developers now have a wider array of open-source licenses to choose from (such as Uniswap’s licensing model, permitting code disclosure but restricting forking into commercial projects). On the other hand, Monad’s positioning differs from Ethereum’s. Even if Ethereum achieves single-slot finality (SSF) in the future, the transaction finality remains at least 12 seconds, inadequate for high-frequency use cases.

Another shared challenge among high-performance public chains is the deployment of additional nodes to satisfy the fundamental prerequisites of user permissionlessness and trustlessness: decentralization. It may be possible to quantify certain metrics, such as “TPS divided by node hardware requirements,” enabling comparative analysis to determine which public chain/client offers higher TPS under specific hardware prerequisites. Ultimately, lower hardware requirements for nodes facilitate greater node deployment.

Moving forward, we will continue to monitor the progress of various projects associated with Parallel EVM and delve into their technologies and discrepancies in detail.

Disclaimer：

1. This article is reprinted from [ChainFeeds Research], All copyrights belong to the original author [ZHIXIONG PAN]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.