2024 will be the "year of Parallel EVM".
Author: David, Deep Tide TechFlow
The narrative of the crypto market always follows a cause-and-effect cycle.
In recent months, with the continuous outbreak of transactions in the Bitcoin ecosystem, capital overflow and Fomo sentiment have also caused transactions to blossom on other chains, but the result has also brought negative effects:
Due to the excessive number and variety of transactions, multiple blockchain networks including Arbitrum, Avalanche, Cronos, zkSync, and The Open Network have all experienced performance overload.
As a result of the transaction frenzy, the market has begun to re-examine the performance issues of the EVM.
At the same time, a new narrative related to optimizing EVM performance has emerged - Parallel EVM.
JD, former co-founder of Polygon, recently stated on social media that he has a hunch that in 2024, every L2 will rebrand itself and label itself as "Parallel EVM";
Georgios, CTO of Paradigm, also believes that 2024 will be the "year of Parallel EVM", and also stated that Paradigm is internally exploring and designing related technologies.
Why is everyone so optimistic about Parallel EVM?
In addition to the exacerbation of EVM chain performance burden by transactions, optimizing EVM is a continuous theme in the crypto world - new public chains, OP-based L2, ZK-based L2, etc., are all narratives and projects derived from optimizing EVM, and the market will also value them more.
However, these narratives are relatively mature, and related projects no longer have much hype space. Therefore, the new method of optimizing EVM performance, Parallel EVM, is easily attracting market attention during the bull market.
Returning to the concept itself, what exactly is Parallel EVM? What are the specific implementation methods? And which related projects are worth paying attention to in advance?
In this issue, we attempt to answer the above questions.
Parallel, More Efficient
So, what is Parallel EVM?
Parallel EVM (Ethereum Virtual Machine) is a concept aimed at improving the performance and efficiency of the existing EVM.
As we all know, the EVM is the core of Ethereum, responsible for running smart contracts and processing transactions.
The current EVM has a very important feature in its design to maintain network consistency and security:
Transactions are executed in sequence.
Sequential execution ensures that transactions and smart contracts can be executed in a deterministic order, making it easier to manage and predict the state of the blockchain. This design choice prioritizes security and reduces potential complexity and vulnerabilities associated with parallel execution.
However, in the face of high loads, this may lead to network congestion and delays.
Imagine the original design of the EVM as vehicles on a single-lane road moving one after another, with each vehicle having to travel at the speed of the preceding vehicle. Once there is congestion with a vehicle (transaction), the subsequent vehicles will be completely stuck on the road;
Parallel EVM, on the other hand, is like expanding this single lane into a multi-lane highway, allowing multiple vehicles to travel simultaneously.
From a technical perspective, Parallel EVM allows different independent transactions or smart contracts to proceed simultaneously, greatly improving the processing speed and system throughput of the EVM.
So, what are the ways to implement Parallel EVM?
We do not intend to provide a particularly in-depth technical interpretation here, but we can first give a general method of parallel EVM processing:
- Partitioning or Sharding: Partition or group transactions so that they can be executed in parallel. This means that different transactions can be executed simultaneously on different processing units, rather than one by one. In addition, Solana's SVM also adopts a similar processing logic.
Optimization Algorithms: Develop new scheduling algorithms and optimization techniques to effectively manage and execute parallel tasks while maintaining the correctness and order of transactions.
Security and Consistency Assurance: Implement complex synchronization mechanisms and consistency models to ensure the security and data consistency of the entire system even in parallel processing situations.
In short, by processing transactions in parallel, the EVM can handle more transactions at the same time, significantly increasing TPS, alleviating network congestion, and improving scalability.
There are already some projects in the market that have begun to explore the design of Parallel EVM, each with its own characteristics. Next, we will provide specific introductions and inventories of related projects.
Independent Faction: Building L1 independently, designed as Parallel EVM
Since Ethereum's EVM currently executes transactions sequentially, the first approach to implementing Parallel EVM is very direct:
Abandon Ethereum, start afresh, and create an independent Layer1 to run Parallel EVM.
Representative projects: Monad and Sei.
Monad: L1 with built-in Parallel EVM
Monad is a blockchain project dedicated to solving the scalability issues of traditional EVM. It adopts a parallel execution strategy, is compatible with Ethereum, and aims to optimize blockchain performance by increasing transaction processing speed and system efficiency.
By implementing parallel execution, Monad aims to significantly increase transaction throughput, solve the congestion issues of the existing EVM chain under high loads, and ultimately aims to achieve 400,000 TPS, the physical bandwidth limit.
It is worth mentioning that if you search directly on Twitter with "Parallel EVM" as a keyword, the first project that comes out in the popular category is Monad, which also reflects the project's marketing actions in line with the narrative of Parallel EVM.
So how does Monad specifically implement parallel transaction processing?
The core of Monad's parallel execution strategy lies in its ability to identify and execute transactions without common dependencies in parallel. Although both Monad and Ethereum's blocks are linearly ordered transaction sets, Monad allows transactions to proceed in parallel without affecting the final result through optimized execution strategies. This parallel execution strategy includes several key technologies:
Optimistic Execution: Start executing subsequent transactions before the previous one is completed. This method may lead to transaction dependency errors, but by tracking input-output comparisons, once data inconsistencies are detected, the system will re-execute the transaction to ensure the correct execution result.
Scheduling and Dependencies: In order to reduce unnecessary duplicate executions, Monad predicts transaction dependencies through a static code analyzer and intelligently schedules transaction execution to optimize parallel execution efficiency.
State Merging: Despite transactions being executed in parallel, the state updated by each transaction needs to be merged in order to ensure the consistency of the entire block's state.
In terms of funding, Monad has also performed well. In February of this year, its official announcement revealed a $19 million seed round led by Dragonfly, with individual investors including well-known figures in the industry such as Cobie and Hasu.
Additionally, the project's founder is Keone Hon, former head of research at Jump Trading. Since the project has not yet issued tokens, considering Jump Trading's experience in trading and market making, the token's performance may be worth looking forward to.
(Related Reading: Interview with Monad Labs CEO: Exploring the Role of Public Chains in On-Chain Finance by the Former Jump Trading Team)
In September of this year, Monad Labs released the project's technical documentation, which revealed that the native token of the project is called MON. However, the introduction of MON in the document was later deleted, suggesting that the token may be named differently.
With substantial funding, a market maker background, a new public chain, and Parallel EVM, these elements together ensure that Monad will receive widespread attention and anticipation.
However, the performance of its Parallel EVM still needs to be verified with testnet data and mainnet operation.
SEI: V2 Version Puts Parallel EVM on the Agenda
Sei is an open-source Layer 1 blockchain designed specifically for transaction optimization, aiming to provide advanced infrastructure for various transaction applications, including DeFi, NFT markets, and game DEX.
As we all know, Sei is not a new project. Its mainnet was ready in August of this year, and the previous V1 version had already implemented features specifically optimized for transactions, such as mechanisms to prevent front-running transactions and support for order batch processing, aiming to improve transaction security and efficiency.
(Related Reading: Sei Network: A Layer 1 Blockchain Breaking DEX Scalability)
In the latest V2 version (expected to be implemented in the first half of 2024), Sei puts Parallel EVM on the agenda.
Optimistic Parallelization: Sei also adopts an optimistic parallelization strategy, allowing the chain to execute all transactions in parallel. When transactions touch the same state, the system tracks the storage parts touched by each transaction, and conflicting transactions are re-executed in sequence until all conflicts are resolved.
Geth Compatibility: As part of the core Sei binary, Sei nodes will automatically import Geth, the Go implementation of the Ethereum Virtual Machine, to process Ethereum transactions, and update any results through the special interface created by Sei for EVM.
SeiDB Storage Optimization: Sei has redesigned the storage interface, using more efficient data structures and databases to optimize read and write performance while reducing state bloat.
These technologies together form the core of Sei v2, making it not only a fully parallelized EVM, but also highly performant and compatible; at the same time, Sei provides a diverse execution environment by allowing seamless interaction between Cosmwasm smart contracts and EVM smart contracts, further expanding its applicability and appeal.
Based on the test data provided in the documentation, Sei achieved a peak TPS of around 28,300 in parallel transaction processing. From a theoretical testing perspective, the efficiency of Parallel EVM is significantly stronger than various L1s currently. We also look forward to the actual implementation not discounting too much.
(Related Reading: In-Depth Technical Design of Sei v2)
In terms of tokens, SEI has seen an 80% increase in the past month, and considering the project's high market value, such an increase is already very impressive. With the continuation of the Parallel EVM narrative, the token may see further gains, but it is more of a beta return.
Middle Ground Faction: Becoming L2, Combining the Capabilities of Other Chains with EVM
Unlike the L1 self-reliant approach mentioned above, there are also some L2 projects with a different solution for Parallel EVM:
Leveraging the performance of other chains or virtual machines to assist in the execution of Ethereum transactions.
Representative projects: Neon, Eclipse, Lumio.
Neon: Introducing EVM into the Solana Ecosystem as L2
Neon EVM is the first parallelized Ethereum Virtual Machine built on the Solana blockchain, aiming to improve blockchain efficiency and scalability through parallel transaction processing.
The project's biggest feature is its cross-ecosystem operation: allowing developers to use Solana's parallel execution architecture to extend Ethereum dApps, optimize network efficiency through parallel execution, increase transaction speed, reduce costs, while maintaining compatibility with the EVM environment.
In its specific implementation, Neon converts Ethereum transactions into Solana transactions, which are then submitted to Solana validators. These validators execute and update the state of the Neon program on Solana. The specific process can be understood as follows:
User-signed transactions are sent to an agent. The agent is an account on Solana, running an EVM simulator, and responsible for executing Neon-txn.
The agent requests the blockchain state from Solana and tests the initiation of Neon-Txn on the Solana state.
Based on the received data, the agent forms a new txn (transaction) according to Solana rules and sends it along with the packaged data to Solana for data processing.
Finally, according to eth rules, the transaction is sent back to Neon for signature verification, and once verified, it is executed in parallel on Solana.
In terms of token performance, NEON has tripled in the past month, but its total market value is significantly lower than SEI. Considering the recovery of the Solana ecosystem and the related token frenzy, NEON, as the only parallel EVM in the Solana ecosystem, still deserves attention for its future market performance.
Eclipse: Introducing SVM into the Ethereum Ecosystem as L2
Faced with the performance issues caused by the sequential execution of EVM, Neon's approach is to introduce EVM into Solana; but conversely, introducing SVM into Ethereum is also a different but converging choice.
Eclipse Mainnet is such a general L2 solution that introduces SVM into Ethereum, combining Ethereum settlement, Solana Virtual Machine (SVM) execution, Celestia data availability, and RISC Zero zero-knowledge proofs, among other technologies.
The project aims to provide a massively parallel execution environment, allowing multiple operations to proceed simultaneously, thereby increasing network throughput and efficiency, while reducing congestion and transaction costs. With this structure, Eclipse aims to improve the scalability and user experience of dApps.
In terms of implementation, Eclipse achieves parallel EVM through the Solana Virtual Machine (SVM) and its Sealevel runtime.
SVM allows different transactions to be executed in parallel, especially when these transactions do not affect overlapping states. In this way, SVM can directly scale performance with an increase in the number of hardware cores, achieving optimized parallel execution. This design enables Eclipse to significantly increase processing speed and network throughput, while reducing congestion and transaction costs.
(Related Reading: Podcast Notes | Conversation with Eclipse Co-founder: How Solana SVM Becomes Ethereum's L2?)
In simple terms, Eclipse's design logic is that transaction execution occurs in Solana's SVM, while transaction settlement still occurs on Ethereum.
In terms of project background, Eclipse completed a $15 million funding round in 2022, with investors including Polychain, Polygon Ventures, Tribe Capital, Infinity Ventures Crypto, CoinList, and others.
Eclipse's co-founder & CEO Neel Somani has previous experience at companies such as Airbnb, Two Sigma, and Oasis Labs, while Chief Business Officer Vijay was previously the former business development manager at Uniswap and dYdX teams.
On December 13th, Eclipse's testnet has already gone live, and the first 1000 developers to deploy contracts on this testnet will receive commemorative NFT rewards. As the project has not yet released tokens, considering its substantial funding background, actively engaging and closely following the project's social media updates to seize airdrop opportunities would be a good choice.
Lumio: Introducing Move and Aptos to Process Transactions as L2
The recently released Lumio is also an L2, with a certain integration with parallel EVM in its product design.
Lumio aims to use Aptos as an Ethereum L2, based on an OP Rollup. In terms of product features, it processes transactions using Aptos and settles them on Ethereum.
Compared to other L2s, Lumio's official materials provide performance comparisons:
Gas costs are 3-4 orders of magnitude lower than existing L2s ($0.1 vs $0.0006);
TPS is 1-2 orders of magnitude higher than existing L2s (1K vs 30K);
High-performance and secure execution layer suitable for enterprise-level applications, a good choice for transitioning Web2 traditional applications to Web3;
Move and EVM cross-virtual machine calls.
In terms of funding background, in 2021, the organization behind the project, Pontem, received a $4.5 million funding round led by Mechanism Capital and Kenetic Capital, and also attracted participation from institutions such as Animoca and Bixin. The new Lumio L2, it is said, will have new funding developments announced in the near future.
In addition, Pontem focuses on building Move and EVM-compatible products, and has been using Move for application development since the Libra era within Facebook, making it one of the earliest projects in the Aptos ecosystem.
With the resurgence of other public chains, if Aptos can benefit from capital overflow, Lumio, which is related to the parallel EVM narrative, may also receive attention. At the same time, Pontem and Lumio currently do not have tokens; with the launch of the Lumio testnet, active engagement may lead to airdrop opportunities.
Polygon Miden: Old L2, New Virtual Machine
Polygon Miden is a zero-knowledge (zk) Rollup under development, running on the Miden VM. This virtual machine is designed with a focus on zero-knowledge friendliness, prioritizing these aspects over direct EVM compatibility. As a zk Rollup, it aims to enhance transaction privacy and scalability for the Polygon network.
Based on Polygon Miden's Github page, it mentions parallel transaction execution, meaning it can process causally independent transactions in parallel.
How is this achieved?
Specifically, Miden achieves verifiability by changing the transparency requirements of traditional blockchains, using zero-knowledge proofs to allow users to execute smart contracts locally and create proofs, which the network can then quickly verify.
This approach reduces computational burden and naturally allows transactions to be parallelized, improving overall processing efficiency and speed.
At the same time, the project's Twitter account shows that Miden is still in the development stage, with limited information disclosed. However, from the overall design of this L2 on Polygon, it has various technical solutions such as sidechains, zk-STARK, and SDK, and parallel EVM is not its most important focus.
Considering that Polygon has already been recognized as a successful L2, the author believes that Miden's design can only be tangentially related to the narrative of parallel EVM in terms of technology. However, Polygon itself has not actively capitalized on this narrative momentum, and since the Matic token can no longer generate Alpha returns, Matic may not be completely associated with the narrative of parallel EVM in terms of token performance.
Finally, we can also use a table to compare all the projects involved in the narrative of parallel EVM, providing readers with a reference.
As mentioned at the beginning of the article, narratives are always in flux.
The narrative of parallel EVM is showing signs of resurgence, but whether it can continue to be hot depends on the real breakthroughs in technology by different L1 and L2 projects on one hand, and on the other hand, it also requires close attention to the movements of the projects. With the upcoming Cancun upgrade in the first quarter of next year to optimize Ethereum, the narrative of parallel EVM, which optimizes its performance, may yet see another climax.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
