Reforge Research: Only parallel EVM can save Ethereum, and there is a bright future ahead

Source: Reforge Research

Compiled by: Odaily Planet Daily Wenser

Editor's note: Ethereum's high gas fees and security risks have long been criticized. In addition, the recent discussion of parallel EVM has attracted great attention from the industry. Reforge Research has conducted in-depth exchanges with many senior industry insiders such as EVM L1 ecological network, AMM industry and cross-chain protocol to understand the different views of different ecosystems on this topic. Odaily Planet Daily has compiled this article for your reference.

introduce

In today’s computer systems, getting tasks processed faster and more efficiently often means doing it in parallel rather than sequentially. This phenomenon, enabled by the multi-core processor architecture of modern computers, is known as “parallelization,” as the name implies. Tasks that were traditionally handled in steps can now often be handled simultaneously, maximizing processor performance. Similarly, in blockchain networks, this principle of performing multiple operations simultaneously also applies to transaction operations, although rather than utilizing multiple processors for the operation, it leverages the collective verification capabilities of many nodes in the network. Some early examples include:

• In 2015, Nano (XNO) adopted a block grid structure, allowing each account to have its own blockchain to enable parallel processing and remove the need for network-wide transaction confirmation.
• In 2018, the Block-STM (Software Transaction Memory) parallel execution engine paper of the blockchain network was officially published, Polkdot achieved parallelization through a multi-chain architecture, and EOS launched their multi-threaded processing engine.
• In 2020, Avalanche introduced a parallel processing mechanism for its consensus layer (rather than the serialized EVM c-chain), and Solana incorporated similar innovations in Sealevel.

For EVM, transactions and smart contract execution have been processed sequentially since its inception. This single-threaded execution design limits the throughput and scalability of the entire system, which is particularly evident when the network is overloaded. As network nodes face increasing workloads, the blockchain network will inevitably slow down, and users will also face higher costs. In order to prioritize transactions in a crowded network environment, they have to bid higher.

The Ethereum community has been exploring parallel processing as a solution since Vitalik's EIP proposal in 2017. The original intention was to achieve parallelization through traditional sharded blockchains, or sharding. However, the rapid development and adoption of L2 Rollup, which provides simpler and more direct scalability benefits, has shifted the focus of Ethereum's development from sharding to what is now called "danksharding". With danksharding, shards are primarily used as a data availability layer rather than for parallel execution of transactions. However, since danksharding has not yet been fully implemented, people's attention has turned to several key alternative parallelized L1 networks with EVM compatibility (especially Monad, Neon EVM, and Sei).

Given the legacy of software systems engineering and the success of other network scalability efforts, the parallelization of the EVM is inevitable. We anticipate this shift with conviction, and the direction of the future, while unclear, is promising. This will have a huge impact on the world’s largest smart contract developer ecosystem (currently with over $80 billion in TVL). What happens when gas fees are reduced to just a fraction of a penny through optimized state access? How vast is the design space for application layer developers? Here is our take on the possibilities in a post-parallel EVM world.

Parallelization is a means, not an end

Scaling blockchains is a multi-dimensional problem, and parallel execution paves the way for the development of more critical infrastructure, such as blockchain state storage.

The main challenge facing projects running on the parallel EVM is not only to enable computation to be performed simultaneously, but also to ensure optimized state access and modification in a parallelized environment. The key to the problem lies in two main issues:

1. Ethereum clients and Ethereum itself use different storage data structures (B-tree/LSM tree and Merkle tree), resulting in poor performance when embedding one data structure into another.
2. In parallel execution, the ability to asynchronously input/output (asynchronous I/O) for transaction reads and updates is critical; operations are stalled by waiting for each other to respond, wasting all speed gains.

Adding additional computational tasks such as adding a large number of additional SHA-3 hashes or calculations is secondary to the cost of retrieving or setting stored values. To reduce transaction processing time and gas fees, the infrastructure of the database itself must be improved. This is not just a matter of adopting traditional database architectures as an alternative to raw key-value storage (such as SQL databases). Implementing the EVM state using a relational model adds unnecessary complexity and overhead, resulting in higher costs for "load" and "store" operations compared to using basic key-value storage. EVM state does not require features like sorting, range scanning, or interactive semantics because it only performs point reads and point writes, and writes occur at the end of each block. In turn, the need for these improvements should focus on addressing major considerations such as scalability, low-latency reads and writes, efficient concurrency control, state pruning and archiving, and seamless integration with the EVM. For example, Monad is building a custom state database called MonadDB from scratch. It will take advantage of the latest kernel support for asynchronous operations while implementing Merkle tree data structures natively on disk and in memory.

We expect to see further improvements to the underlying key-value databases as well as significant improvements in the third-party infrastructure that supports the majority of blockchain storage capabilities.

Make pCLOBs Great Again

As DeFi moves to a higher fidelity state, CLOBs (central limit order books) will become the primary design approach for transactions.

Since their debut in 2017, automated market makers (AMMs) have become a cornerstone of DeFi by providing simplicity and the unique ability to bootstrap liquidity. By leveraging liquidity pools and pricing algorithms, AMMs have revolutionized DeFi and become the best alternative to traditional trading systems such as order books. Despite being a fundamental building block of traditional finance, when central limit order books (CLOBs) were introduced to Ethereum, they were limited by the scalability of the blockchain. They require a large number of transactions, as each order submission, execution, cancellation, or modification requires a new on-chain transaction. Due to the immaturity of Ethereum's scalability efforts, the cost of this requirement made CLOBs unsuitable in the early stages of DeFi, leading to the failure of early attempts such as EtherDelta. However, even as AMMs gained popularity, they faced inherent limitations. These shortcomings became more apparent as DeFi matured and attracted more sophisticated traders and established institutions.

Recognizing the superiority of CLOBs, attempts to incorporate CLOB-based exchanges into DeFi have become increasingly common on alternative, more scalable blockchain networks. Protocols such as Kujira, Serum (RIP, the project has been offline), Demex, dYdX, Dexalot, and more recently Aori and Hyperliquid aim to provide a better on-chain trading experience than competitors such as AMMs. However, with the exception of projects targeting specific market segments (such as dYdX and Hyperliquid for perpetual contracts), CLOBs on these alternative networks face a range of challenges beyond scalability:

• Liquidity fragmentation: The network effect achieved by the highly composable and seamlessly integrated DeFi protocols on Ethereum makes it difficult for CLOBs on other chains to attract sufficient liquidity and trading volume, thus affecting their further adoption and usability.
• Memecoins: Bootstrapping liquidity in on-chain CLOBs requires setting limit orders, which is a more challenging chicken and egg problem given that new assets like Memecoins are relatively unknown.

CLOBs with blobs

Dencun Mainnet Announcement

How does L2 perform?

Compared to the Ethereum mainnet, the existing Ethereum L2 has significant improvements in transaction throughput and gas fees, especially after the recent Dencun hard fork (Cancun upgrade). Gas fees have been significantly reduced by replacing gas-intensive call data with lightweight binary large objects (blobs).

According to growthepie, as of April 1, gas fees for Arbitrum and OP Network were $0.028 and $0.064 respectively, with Mantle Network being the cheapest at just $0.015. This is a far cry from gas fees before the Cancun upgrade, where call data fees accounted for 70%-90% of gas costs. Unfortunately, this is still not cheap enough, and the launch/cancel fee of about $0.01 is still a bit high.

For example, institutional traders and market makers place large orders relative to the number of trades actually executed, and thus typically have a high order-to-trade ratio. Even with today’s L2 fee pricing, paying order submission fees and subsequently modifying or canceling those orders on the order book can have a significant impact on the profitability and strategic decisions of institutional participants. Imagine the following example:

Company A: 10,000 order submissions, 1,000 trades, and 9,000 cancellations or modifications per hour is a relatively standard benchmark. If the company operates on 100 order books throughout the day, even if the transaction fee is less than $0.01, the total operation fees will easily exceed $150,000.

New Solution: The pCLOB

With the advent of the parallel EVM, we expect to see a surge in DeFi activity thanks to the feasibility of CLOBs leading on-chain. But it’s not just CLOBs – it’s programmable central limit order books (pCLOBs for short). Given the composable nature of DeFi, we can interact with countless protocols (limited only by gas) to create a large number of trading pairs. Leveraging this principle, pCLOBs can enable embedded custom logic in the order submission process. This logic can be called before or after an order is submitted. For example, a pCLOB smart contract can include custom logic to implement:

• Validate order parameters (e.g., price and quantity) based on predefined rules or market conditions

• Perform real-time risk checks (e.g. ensuring sufficient margin or collateral for leveraged trades)

• Apply dynamic fee calculations based on any parameters (e.g. order type, volume, market volatility, etc.)

• Execute conditional orders based on specified trigger conditions

…and still be a better deal than existing deal designs.

The concept of Just-in-Time (JIT) illustrates this point well. Liquidity does not sit idle on any single exchange, but instead generates yield elsewhere until the moment an order is matched and liquidity is extracted from the underlying platform. Who wouldn’t want to earn that last bit of yield on MakerDAO before extracting trading liquidity? The innovative “Quotes as Code” approach pioneered by Mangrove Exchange hints at the potential of this mechanism. When a quote in an order book is matched, the portion of code embedded in it is executed, whose sole task is to find the liquidity requested by the order taker. Nonetheless, challenges related to L2 scalability and cost remain.

The parallel EVM also radically enhances pCLOBs’ matching engine. Now, pCLOBs can implement a parallel matching engine that utilizes multiple “channels” to simultaneously process incoming orders and perform matching calculations. Each channel can handle a subset of the order book, so price-time priority is not restricted and orders are only executed when a match is found. Reduced latency between order submission, execution, and modification makes order book updates more efficient.

“Due to their ability to consistently make markets in the face of illiquidity, AMMs are likely to continue to be widely used for long-tail assets; however, for ‘blue chip’ assets, pCLOBs will dominate.”

——Keone, co-founder and CEO of Monad

In a discussion with us, Monad co-founder and CEO Keone expressed his belief that we can expect multiple pCLOBs to emerge in different high-throughput ecosystems. Keone stressed that these pCLOBs will have a significant impact on the larger DeFi ecosystem due to lower operational fees.

Even with just a handful of these improvements, we expect pCLOBs to have a significant impact in terms of improving capital efficiency and unlocking new categories in DeFi.

Got it, we need more apps, but first...

Existing and new applications need to be architected in a way that takes full advantage of underlying parallelism.

With the exception of pCLOBs, current decentralized applications are not parallel — their interactions with the blockchain are inherently sequential. However, history shows that technology and applications naturally take advantage of new advances to drive their own development, even if they were not originally designed with these factors in mind.

“When the first iPhone came out, the apps designed for it looked a lot like bad computer apps. Same thing here. Just like we’re adding multi-core to blockchain, that will lead to better apps.”

**—— Steven Landers, blockchain architect of Sei Ecosystem said so. **

The evolution of e-commerce from being presented on the internet as a magazine catalog to the existence of a strong two-sided marketplace is a classic example. As parallel EVM becomes a reality, we will witness a similar transformation of decentralized applications. This highlights a key limitation: Applications that were not designed with parallelism in mind will not benefit from the efficiency gains of a parallel EVM. Therefore, it is not enough to have parallelism at the infrastructure layer without redesigning the application layer, they must be architecturally consistent.

State contention

Without making any changes to the applications themselves, we still expect 2-4x performance improvements, but why stop there when it can go even higher? This shift presents a key challenge: applications need to be fundamentally redesigned to accommodate the nuances of parallel processing.

“If you want to take advantage of throughput, you need to limit contention between transactions.”

**——Steven Landers, blockchain architect of Sei Ecosystem said. **

More specifically, when multiple transactions of a decentralized application try to modify the same state at the same time, conflicts arise between them. Resolving transaction conflicts requires processing them sequentially, which offsets the benefits of parallelization.

There are many ways to resolve this conflict, which we will not discuss in detail at this time, but the number of potential conflicts encountered during execution is largely up to the application developer. Looking at decentralized applications, even the most popular protocols such as Uniswap were not designed and implemented with this limitation in mind. 0xTaker, co-founder of Aori (a high-frequency off-chain order book system for market makers), talked to us in depth about the major state disputes that will occur in a parallelized world. For AMMs, due to the peer-to-pool model they set up, many traders may trade against a single pool at the same time. From a few transactions to hundreds of transactions, these operations will compete for transaction priority, so AMM designers will have to carefully consider how liquidity is allocated and managed to maximize the benefits of the liquidity pool.

Steven, a core developer of the parallel EVM L1 network Sei ecosystem, emphasized the importance of considering state contention in multi-threaded development, and pointed out that Sei is actively researching what parallelization means and how to ensure that resources are fully utilized.

Performance Predictability

Yilong, co-founder and CEO of MegaETH, also stressed to us the importance of decentralized applications seeking performance predictability.

Performance predictability means that decentralized applications will always be able to execute transactions within a certain time, regardless of network congestion or other factors. One way to achieve this is through application-specific chains, however, while application-specific chains provide predictable performance, they sacrifice composability.

“Parallelization provides a way to experiment with local fee markets to minimize state contention.”

Said 0xTaker, co-founder of Aori.

Additionally, advanced parallelism and multi-dimensional charging mechanisms can enable a single blockchain to provide more deterministic performance for each application while maintaining overall composability.

Solana has a nice localized fee market system, so if multiple users access the same state, they are charged a higher fee (surge pricing) instead of bidding against each other in a global fee market. This approach is particularly beneficial for loosely connected protocols that need performance predictability and composability.

To understand the concept, think of it as a highway system with multiple lanes and dynamic tolling. During rush hour, the highway can allocate dedicated express lanes for vehicles willing to pay higher tolls. These express lanes ensure predictable and faster travel times for those who prioritize speed and are willing to pay the extra toll. At the same time, the regular lanes are open to all vehicles, maintaining the overall connectivity of the highway system.

Diverse Imaginations of Possibilities

While the need to re-architect protocols to align with underlying parallelism may seem extremely challenging, the possible design space for DeFi and other verticals will expand significantly. We can expect to see a new generation of more complex and efficient applications focused on solving use cases that were previously impractical due to performance limitations.

"Back in 1995, the only internet option was paying $0.10 per 1MB of data downloaded - you were very selective about which sites you went to. Imagine the change from that time to infinity, and notice how people would handle it and what would be possible."

Said Keone Hon, co-founder and CEO of Monad.

We could potentially return to a scenario similar to the early days of centralized exchanges - a war for user acquisition in which DeFi applications, especially decentralized exchanges, offer referral programs (e.g. points, airdrops) and superior user experience as weapons. We could see a world of on-chain gaming where any reasonable interactivity would exist, which would be very different. Hybrid order book-AMMs already exist, but instead of having the CLOB sequencer as a standalone node off-chain and then decentralized through governance, we can move it on-chain, making it more decentralized, less latency-intensive, and more composable. Social interactions that are fully on-chain are now possible as well. Frankly, any scenario with a large number of participants or agents operating simultaneously can now be made public and discussed.

It is likely that intelligent agents, other than humans, will dominate on-chain transaction flow even more than they do today. AIs that have been in the game for a long time in the form of arbitrage bots and autonomous trade execution capabilities have already existed, however, their participation will grow exponentially in the future. Our view is that any form of on-chain participation will be augmented by AI to some degree. Latency requirements for proxy trading will become even more important than we imagine today.

At the end of the day, technological advancement is just the basic enabler. Ultimately, the winner will be determined by who can attract users and drive trading volume/liquidity better than their competitors. The difference is that now developers need to do more.

Crypto App UX Sucks…Now It’s Going to Get Better

User Experience Consistency (UXU) is not only possible, it’s necessary — and the industry is certainly moving towards achieving it.

Thank you, GPT Man

Today’s blockchain user experience is fragmented and cumbersome - users need to jump between multiple blockchains, wallets, and protocols, waiting for transactions to complete while facing the risk of security vulnerabilities or hackers. The ideal future is one where users can seamlessly interact with their assets securely without having to worry about the underlying blockchain infrastructure. This transition from the current fragmented user experience to a unified, simplified experience is what we call User Experience Unification (UXU).

Essentially, improving blockchain performance, especially through lower latency and lower fees, can significantly solve user experience issues. Historically, advances in performance have tended to positively impact every aspect of our digital user experience. For example, faster internet speeds not only enable seamless online interactions, but also create demand for richer and more immersive digital content. The advent of broadband and fiber optic technologies has enabled low-latency streaming of high-definition video and real-time online gaming, raising user expectations for digital platforms. This growing need for depth and quality drives many companies to continue innovating in the development of the next big, engaging thing—from advanced interactive web content to sophisticated cloud-based services to virtual/augmented Realistic experience. Increased network speeds not only improve the online experience itself, but also further expand the scope of user needs.

Similarly, the improvement of blockchain performance will not only directly enhance the user experience by reducing latency, but will also indirectly promote the rise of protocols that unify and improve the overall user experience. Performance is a key factor in their existence. Especially for networks like parallel EVM, better performance and lower gas fees, for users, this means smoother on-chain operations, which can attract more developers to build the ecosystem. In our conversation with Sergey, co-founder of the cross-chain interoperability network Axelar, he envisioned a world that is not only interoperable but also symbiotic.

“If you have complex logic that needs to be implemented on a high-throughput chain (i.e. parallel EVM), and the chain itself is high-performance and can “absorb” that logic and throughput requirements, then you can use interoperability solutions to export that functionality to other chains in an efficient manner.”

**——Sergey Gorbunov, co-founder of Axelar. **

As scalability issues are resolved and interoperability between different ecosystems increases, we will witness the emergence of protocols that bring Web3 user experience on par with Web2. Examples include v2 of intent-based protocols, advanced RPC infrastructure, chain abstraction support, and open computing infrastructure enhanced by AI.

“As the throughput network increases, our nodes will be able to orchestrate state much faster because the solvers can understand our intent very quickly.”

——Felix Madutsa, co-founder of Orb Labs

A rising star who may thrive

As performance demands increase, the oracle market will become extremely prosperous.

Parallel EVM means increased performance demand for oracles, which has been an extremely underdeveloped vertical over the past few years. Strong demand from the application layer will revitalize this untapped market filled with poorly performing and secure products, which is critical to improving the composability of DeFi. For example, market depth and trading volume are strong indicators to examine many DeFi pioneers. We expect that big players like Chainlink and Pyth will quickly adapt when new players challenge their market share. After a conversation with a senior member of Chainlink, our thoughts are consistent: "The consensus (within Chainlink) is that if parallel EVM takes dominance, we may want to redesign our smart contracts to capture value from it (e.g., reduce dependencies between contracts so that transactions/calls do not unnecessarily rely on execution and thus be attacked by MEV) but since parallel EVM is designed to improve transparency and throughput of applications already running on EVM, it should not affect network stability."

This shows that Chainlink understands the impact of parallel execution on their product, and as mentioned before, in order to take advantage of parallelization, they will have to redesign their smart contracts.

It’s not just L1’s party, parallel EVM L2 also wants to participate

From a technical perspective, creating a high-performance parallel EVM L2 solution is easier than developing L1. This is because, in an L2 network, the sequencer setup is much simpler than the consensus-based mechanisms used in traditional L1 systems such as Tendermint and its variants. This simplicity stems from the fact that the sequencer in a parallel EVM L2 setup only needs to maintain the order of transactions, rather than requiring many nodes to agree on the order of transactions as in a consensus-based L1 system.

More specifically, we expect that in the short term, parallel EVM L2 based on OP networks will dominate compared to ZK-based ones. Ultimately, we highly expect that the transition from OP-based Rollups to ZK-Rollups will be achieved through the transition of a general ZK framework like RISC0, rather than the traditional methods used in other ZK-Rollups. It is just a matter of time.

Are the advantages of Rust language still there?

The choice of programming language will play an important role in the development of these systems. We prefer Reth, the Rust implementation of Ethereum, over other alternatives. This preference is not random, as Rust has many advantages over other languages, including memory safety without garbage collection, zero-cost abstractions, and a rich type system.

Rust Yes！

As you and I can see, the competition between Rust and C++ is becoming an important competition in the new generation of blockchain development languages. Although this competition is often overlooked, it should not be ignored. The choice of development language is crucial because it affects the efficiency, security, and flexibility of developers to build systems.

Developers are the implementers of these systems, and their preferences and expertise are critical to the direction of the industry. We firmly believe that Rust will eventually come out on top. However, porting one completed application to another is far from easy. It requires a lot of resources, time, and expertise, which further highlights the importance of choosing the right development language from the beginning.

In the context of parallel execution, we cannot fail to mention the Move language.

While Rust and C++ are often the focus of discussion, the Move language has some characteristics that make it equally suitable in this context.

• Move introduces the concept of "resources" that can only be created, moved, or destroyed but not copied. This ensures that resources are always uniquely owned, preventing common problems that can arise in parallel execution, such as race conditions and data races.
• Formal verification and static typing: Move is a statically typed language with a strong focus on safety. It includes features such as type inference, ownership tracking, and overflow checking that help prevent common programming errors and vulnerabilities. These safety features are particularly important in the context of parallel execution, where errors can be more difficult to detect and reproduce. The language's semantics and type system are based on linear logic, similar to Rust and Haskell, which makes it easier to reason about the correctness of Move programs, so formal verification can help ensure that parallel execution is safe and correct.
• Move advocates a modular design approach, where smart contracts are composed of smaller, reusable modules. This modular structure makes it easier to reason about the behavior of individual components and can facilitate parallel execution by allowing different modules to execute simultaneously.

Future considerations: EVM should be cured of its insecurity

While we paint an incredibly optimistic picture of the on-chain universe after the parallel EVM, it will all be meaningless if we don’t address the shortcomings of the EVM and smart contract security.

Different from the network economy and consensus security, hackers exploited the smart contract security vulnerabilities of Ethereum DeFi protocol and stole more than $1.3 billion in 2023 alone. As a result, users prefer to use CEXs (centralized exchanges) like walled gardens or "decentralized" protocols with mixed centralized nodes - sacrificing decentralization for an improved on-chain experience, choosing a centralized experience that is considered more secure (and better performing).

**The question is, do average users care about decentralization? **

The lack of inherent security features in the EVM design is the root cause of these vulnerabilities.

Similar to the aerospace industry, strict safety standards make air travel very safe, but the blockchain world's approach to security is in stark contrast. Just as people value their lives above all else, the safety of their financial assets is equally important. Key practices such as exhaustive testing, redundancy, fault tolerance, and strict development standards support the aviation safety record, but these key features are currently missing in the EVM, and in most cases, other virtual machine systems.

One potential solution is to adopt a dual VM setup, where a separate VM (e.g. CosmWasm) is used to monitor the real-time execution of EVM smart contracts, just like antivirus software functions in an operating system. This structure supports advanced inspections, such as call stack inspections, specifically designed to reduce hacking incidents. However, this approach will require a major upgrade of existing blockchain systems. We expect newer and better solutions, like Arbitrum Stylus and Artela, to implement this architecture from the beginning.

Existing security mechanisms in the market tend to be performed reactively, responding to imminent or attempted threats by checking the memory pool or smart contract code audits/reviews. While these mechanisms help, they fail to address underlying vulnerabilities in the virtual machine design, so a more productive and proactive approach must be taken to improve and enhance the security of blockchain networks and their application layers.

We advocate for a fundamental overhaul of blockchain VM architecture to embed real-time protection and other critical safety features, perhaps through a dual VM setup as has been successfully proven in industries such as aerospace. Going forward, we strongly support infrastructure improvements that emphasize a preventative approach to ensure that advances in security match industry progress in performance (i.e., parallel EVMs).

in conclusion

The advent of Parallel EVM is a major turning point in the evolution of blockchain technology. By enabling simultaneous execution of transactions and optimizing state access, Parallel EVM opens a new era of possibilities for decentralized applications. From the resurgence of programmable CLOBs to the emergence of more complex and performant applications, Parallel EVM lays the foundation for a unified and user-friendly blockchain ecosystem.

As the industry embraces this paradigm shift, we can expect a wave of innovation that will push the boundaries of decentralized technology. Ultimately, the success of this shift will depend on the ability of developers, infrastructure providers, and the broader community to adapt and follow the principles of parallel execution, leading to a new future where technology is seamlessly integrated into our daily lives.

The advent of the Parallel EVM has the potential to reshape the landscape of decentralized applications and user experiences. By addressing the scalability and performance limitations that have long hindered growth in key verticals such as DeFi, the Parallel EVM opens the door to a future where complex, high-throughput applications can develop without sacrificing the “trilemma”.

To achieve this vision, it will take more than just infrastructure advances. Developers will have to fundamentally rethink the architecture of their applications to align with the principles of parallel processing, minimize state contention, and maximize performance predictability. Even so, despite the bright prospects ahead, we must emphasize that security must be prioritized as much as scalability.