What is the significance of EVM parallelization? Or the endgame under EVM hegemony?
TechFlow Selected TechFlow Selected
What is the significance of EVM parallelization? Or the endgame under EVM hegemony?
Can Parallel EVM enable existing decentralized applications to achieve internet-scale performance?
Navigating Web3 tides with focused insightsAuthor: ZHIXIONG PAN
TL;DR
-
The concept of Parallel EVM is being backed by several top-tier VCs: Paradigm, Jump, Dragonfly, and others.
-
Representative projects include Monad, as well as Sei, MegaETH, Polygon, Neon EVM, BSC, among others. Some are L1s, some are L2s. Detailed technical differences between teams remain largely undisclosed.
-
Although "Parallel EVM" literally refers only to parallelization, it also involves targeted optimizations across various components of the EVM—making these efforts likely represent the performance ceiling under the EVM standard.
-
Challenges: Beyond reconstructing the entire tech stack, key hurdles include predicting whether transactions will conflict before execution and efficiently re-executing after conflicts occur.
-
Key challenges: Building differentiation within an open-source ecosystem and balancing decentralization with high performance.
After widespread research and iteration on consensus algorithms, DA (data availability), and zero-knowledge proof technologies, the next hardcore technical frontier gaining attention is Parallel EVM. The capital markets have already poured hundreds of millions into this narrative, spawning multiple unicorn-level startups.
Community interest in Parallel EVM (EVM parallelization) originated when Georgios Konstantopoulos (CTO of Paradigm) and Haseeb Qureshi from Dragonfly independently highlighted the same keyword while forecasting 2024 trends at the end of 2023. However, detailed discussions remain sparse, and many argue that this isn't a novel concept—after all, both EVM and parallel computing are relatively mature fields individually. So why does combining them constitute a significant trend?
Yet this remains a niche topic—so much so that most industry research reports and annual forecasts don’t mention Parallel EVM at all. It’s still far from achieving broad consensus. Like consensus algorithms or data availability, it's deeply technical, which further limits its audience.
The most direct benefit of Parallel EVM is enabling existing decentralized applications to achieve internet-scale performance. In fact, Parallel EVM may be the only new technology capable of both leveraging vast amounts of mature smart contracts and delivering high-performance, parallelized blockchain throughput.
Paradigm has long awaited entry, Jump doubles down
According to Fortune reporting, Paradigm plans to lead Monad’s latest funding round, raising $200 million at a $3 billion valuation. While this would mark Paradigm’s first investment in a Parallel EVM project, they’ve been tracking the space for years—Georgios Konstantopoulos (Paradigm CTO) previously mentioned the term back in 2021.
The name “Monad” itself is interesting. In philosopher Leibniz’s metaphysical system, monads are indivisible, non-physical entities that each reflect the entire universe—previously translated into Chinese as “单子” (“monad”).
In computer science, a monad is a design pattern used in functional programming languages, helping developers manage real-world complexity with mathematical purity, resulting in more modular, understandable, and maintainable code.
Interestingly, “Monad” is an anagram of “Nomad”—referring to nomadic people, or digital nomads in modern contexts.
Beyond Monad, Georgios referenced Sei and Polygon when discussing this topic. His strong belief in Parallel EVM is also influenced by their development of Reth—an Ethereum client built in Rust, positioned as a high-performance execution-layer client. Reth is rapidly evolving and has just entered beta. While Paradigm might consider implementing Parallel EVM directly in Reth, given the engineering scale, investing in specialized teams like Monad could be a more strategic move. According to Monad’s documentation, they primarily use C++ and Rust in their engineering stack.
At launch, Reth faced accusations from Erigon team members claiming it copied Akula’s open-source code, leading to Akula’s discontinuation due to lack of funding. Georgios responded that Reth is not a fork of any other client and did not copy code from any source, though it was inspired by Geth, Erigon, and Akula. (https://thedefiant.io/paradigm-accused-copying-code)
Another major player is Jump Trading and Jump Capital. Monad’s founder comes from Jump Trading, bringing extensive experience in high-frequency trading. Sei counts Jump Capital among its investors, and Jump has long been deeply involved in Solana’s ecosystem, including infrastructure and projects.
Dragonfly, an early investor in Monad, has consistently tracked this space, having invested in NEAR (focused on sharding), Aptos, Avalanche, Nervos, and other public chains.
Upgrading consensus wasn’t enough—it’s time for the execution layer
In past blockchain wars, the execution layer was often overlooked. Discussions focused almost exclusively on innovations in consensus algorithms—whether for Solana, Avalanche, or EOS. While these chains introduced many execution-layer improvements, the community mostly remembers their consensus mechanisms, assuming that high performance stems solely from consensus innovation.
But that’s misleading. Achieving high performance requires synergy between consensus and execution layers—consistent with the短板 effect (bottleneck principle). For EVM-based blockchains that only improve consensus, scaling performance demands increasingly powerful nodes. For example, BSC maintains around 2,000 TPS by capping block gas limits, requiring node hardware multiple times more powerful than standard Ethereum full nodes. Polygon theoretically supports up to 1,000 TPS but typically operates at dozens to hundreds.
BSC archive nodes require at least 16-core CPUs and 128GB RAM, whereas Ethereum nodes need only 4-core CPUs and 16GB RAM.
Recognizing these limitations, BSC has partnered with NodeReal to develop Parallel EVM technology. Only through such upgrades can they increase per-block transaction capacity, enable parallel transaction execution, and push TPS higher.
Parallelization: More than upgrading from single-core to multi-core CPU
In most blockchain systems, transactions execute strictly sequentially—one after another—like a single-core CPU where each computation must finish before the next begins. This approach is slow but simple and low-complexity.
However, if blockchains aim to serve internet-scale user bases, single-core processing won’t suffice. Transitioning to a multi-core, parallelized virtual machine allows simultaneous transaction processing and increased throughput. But this introduces engineering challenges: what happens when two concurrent transactions attempt to write data to the same smart contract? A new mechanism must resolve such conflicts. Meanwhile, fully independent contract executions can scale linearly with available threads.
Moreover, Parallel EVM doesn’t just enhance parallel capabilities—it also optimizes single-threaded execution. Monad CEO Keone Hon noted: "...the real bottleneck lies in frequent state reads and writes during transaction processing..." He added that parallel execution is just one part of the roadmap—Monad’s broader mission is maximizing EVM efficiency.
Thus, while 'Parallel EVM' literally denotes 'parallelization,' it also encompasses targeted optimizations across all EVM components—potentially representing the ultimate performance limit under the EVM standard.
EVM ≠ Solidity
Writing smart contracts is a fundamental skill for blockchain developers. Engineers implement business logic using high-level languages like Solidity. However, the EVM cannot directly interpret Solidity—it must be compiled into low-level machine-readable instructions (opcodes / bytecode) first. This compilation process is abstracted away by mature tooling, so developers rarely need to understand it.
As a translation step, this incurs overhead. Developers familiar with low-level coding can write opcodes directly in Solidity (via inline assembly), achieving maximum efficiency and minimizing gas costs. For instance, OpenSea’s Seaport protocol extensively uses inline assembly to reduce user gas fees.
Therefore, successful implementation of Parallel EVM wouldn’t merely enable parallel execution—it would optimize the entire EVM stack. Ordinary developers wouldn’t need to obsess over minor gas optimizations because the underlying VM would be powerful enough to eliminate such inefficiencies.
EVM performance varies—“standard” ≠ “engineering practice”
A “virtual machine” can also be called an “execution layer”—the engine that processes compiled opcodes. Ethereum Virtual Machine (EVM) bytecode has become an industry standard. Whether building Ethereum Layer 2s or independent L1s, most prefer full EVM compatibility so developers can deploy once and run anywhere—highly cost-effective.
Any system that fully complies with EVM bytecode standards can call itself an EVM—but implementations vary widely. For example, Geth implements EVM in Go. Meanwhile, the Ethereum Foundation’s Ipsilon team maintains Evmone—a standalone EVM implementation in C++, usable by any Ethereum client as a library.
Take industrial products: many follow international standards—for example, a product must meet bacterial count thresholds before sale. That’s the “standard.” But manufacturers may choose from dozens of sterilization methods to meet it—some finding cheaper, more efficient approaches. That’s the “practice.”
Since evmone exists, alternative implementations are possible. In the case of EVM, the standard defines basic operations (bytecode)—like arithmetic functions—with deterministic inputs and outputs. But how those operations are implemented leaves vast room for customization and engineering optimization.
Similarities and differences among Parallel EVM projects
Beyond the hottest project, Monad, the Parallel EVM landscape includes Sei, MegaETH, Polygon, Neon EVM, BSC, and even Paradigm’s Reth client aiming for parallel functionality.
In terms of positioning, Monad, Sei, Polygon, and BSC are Layer 1 blockchains, while MegaETH may operate as a Layer 2, and Neon EVM runs atop Solana. Reth is an open-source client, and MegaETH may build partially on Reth’s engineering foundation.
These teams also compete, and none have fully disclosed technical details or engineering documents yet. Deeper comparisons will emerge as they gradually open up. Perhaps this mirrors an arms race—as seen in BTC Layer 2s, restaking, or Ethereum Layer 2s—where despite minor technical differences (and open-source nature), the real differentiator lies in building unique ecosystems.
Technical challenges of Parallel EVM
For sequential transaction execution, bottlenecks lie in CPU speed and state read/write latency. The upside? Simplicity and reliability—all transactions proceed without error. In contrast, parallel execution risks state conflicts, requiring additional checks either before or after execution.
For example, if a VM supports four parallel threads, each handling one transaction, problems arise if all four interact with the same Uniswap pool—each trade alters the price, making true parallelism impossible. But if the four transactions involve unrelated contracts, no issue occurs.
Different teams employ varying designs and engineering solutions, but all must include a module to detect conflicts post-execution and re-execute when necessary. Ideally, preemptively identifying potentially conflicting transactions could further boost overall parallel efficiency.
Beyond VM architecture, teams usually redesign and accelerate state database read/write performance and co-design consensus algorithms—such as Monad’s MonadDb and MonadBFT.
Challenges
Two potential challenges face Parallel EVM: long-term value capture by Ethereum, and node centralization.
Since teams are still developing and testing Parallel EVM tech, they haven’t open-sourced everything—this secrecy forms part of their current moat. But once testnets and mainnets launch, engineering details become public and could be adopted by Ethereum or other chains. At that point, faster ecosystem growth becomes essential to build deeper, non-technical moats.
Still, this risk isn’t fatal. First, crypto developers now have more licensing options (e.g., Uniswap-style licenses that allow code sharing but prohibit commercial forking). Second, Monad’s vision differs fundamentally from Ethereum. Even if Ethereum achieves Single Slot Finality (SSF), finality would still take at least 12 seconds—far too slow for ultra-high-frequency applications.
The second challenge—common to all high-performance blockchains—is increasing node distribution to uphold core principles of permissionless and trustless access: decentralization. Metrics like “TPS divided by node hardware requirements” could help normalize comparisons—measuring which chain/client delivers higher throughput under identical hardware constraints. After all, lower hardware requirements generally enable more nodes.
Going forward, we’ll continue tracking progress across Parallel EVM projects and dive deeper into their technical distinctions.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@ChainFeedsxyz
