Parallel EVM and Decentralized Sequencers

• Forward the Original Title：Parallel Solutions Beyond EVM – High-Performance L1 (Sui) Battles Ethereum L2?

Video of the last episode is ready: Get a Quick Overview of the Development Paradigm of BTC L2

https://www.bilibili.com/video/BV1dw411575M/?vd_source=e88bbc11f1ecd88d1c5847538efee51c

Competition in the Alt L1 space is heating up, with Near introducing a DA solution and Sui’s TVL steadily rising. While Ethereum takes its time with mainnet upgrades, L2 introduces two major competitive points: parallel EVM and decentralized sequencers.

In the present and future, a fundamental fact is that Ethereum’s position is challenging to shake. The concept of modularity will generalize, and if Vitalik’s attempts to suppress Celestia are unsuccessful, the market will selectively choose. The combination and modularization will not be confined to the same system, as market principles will drive project teams to freely assemble various components. This includes combinations of different public chains, Layer 2 solutions, and Bitcoin, as evident in the popularity of BTC Layer 2.

If Near can provide Data Availability (DA), high-performance public chains like Aptos, Solana, and Sui could transition to L2, ultimately becoming compatible with and merge into Ethereum.

Parallel EVM can be understood as the parallelization of EVM-compatible chains/L2. The solution starts by addressing blockchain speed, with theoretically two ways to overcome the issue of slow blockchain operations:

• Invest in hardware and continuously optimize. For instance, Solana boasts unique and high-end hardware configurations, with efficient data center management and configuration allowing Solana to enjoy ultra-fast internet speeds and increased throughput.
• Utilize multi-core parallelism and multi-thread concurrency. After hardware is improved, multiple cores can genuinely achieve multitasking. Furthermore, continuously breaking down tasks into finer components can enhance efficiency – a common practice of computers.

Assuming hardware utilization has reached its peak, parallel EVM can be classified and understood at three levels:

1. Parallelism is a common practice in the computer field and can be employed by any public chain or L2. Examples include Alt L1s like Aptos, Sui, and Solana, or Sei claiming to be the first EVM-compatible L1, as well as Ethereum L2 projects like Scroll (2024 roadmap), Lumio, Eclipse, and other EVM-compatible solutions on heterogeneous chains such as Neon EVM (belonging to the Solana ecosystem and claiming to be the first EVM-compatible).
2. Parallel EVM, narrowly defined, refers to L1/L2 that can be compatible with EVM. Theoretically, Ethereum itself can undergo parallelization transformation, which is the most fitting definition of parallel EVM but is nearly impossible due to its extensive scope of actions.
3. Parallel EVM, broadly defined, can be extended to any parallel computing chain, regardless of whether it is inherently EVM-compatible. As long as it can establish a connection with and link to EVM, it can be included. For instance, considering Aptos as an “accelerator” for Ethereum.

Examining non-EVM-compatible Alt L1s holds special significance as they can be integrated into the EVM ecosystem. Additionally, Aptos’ groundbreaking Block-STM solution has become a de facto template and source of inspiration for numerous emerging parallel EVM solutions, as elaborated in the following sections.

Preface: A Layman’s Introduction to Threads, Processes, Parallelism and Concurrency, and the EVM

I’ve categorized the concept of parallel EVM following a breakdown approach, but the explanation of the parallelism concept is still incomplete. If we proceed directly to explain the project’s implementation logic, it might be confusing for readers.

Similarly, explanations like “a process is the smallest unit of resource allocation, and a thread is the smallest unit of CPU scheduling” are professional but not very user-friendly for most people. I’d like to use buying watermelons as an example to illustrate this process.

First, let’s set the stage. The lowest level of our computer is physical hardware, with the operating system and various applications layered on top. When a computer processes tasks, it allocates software and hardware resources based on priority. Let’s use Bob buying watermelons to explain this process:

Relationship between Threads, Processes, Parallelism, and Concurrency

1. Bob is riding a bike to buy a watermelon, which is a single action and the smallest unit - a thread. The watermelon at this point represents the available physical hardware resources, and there’s no more ones.
2. If two Bobs want to buy a watermelon, this is a compound action. Despite there being two Bobs wanting to eat watermelon, it’s crucial to note that there’s still only one watermelon. Both Bob agree to go and buy the watermelon together, making it a process. Each Bob eating watermelon remains a thread. Therefore, one process includes two threads.

Now, if there’s only one watermelon but multiple people to eat it, this is concurrency. The key here is that everyone eats the watermelon together, ensuring each person can at least take a bite. Regardless of how people are seated or the order in which they eat, it doesn’t affect the ultimate outcome of sharing one watermelon.

You might have noticed a problem – why do so many people need to eat one watermelon together? The boss running the watermelon stand is essentially a fruit shop owner, and you can also eat bananas. Exactly! This is the reason for the supply-side reform. The boss now announces that bananas are also available. In this case, physical resources (fruits) have increased, and two Bob can each eat different fruits. This is parallelism – two rows side by side, each enjoying his preferred fruit.

(Disclaimer: The explanation above is simplified and not professional. In case of disputes, rely on the programmer’s understanding.)

Next, we’ll combine these concepts with EVM and unveil the true meaning of parallel EVM.

Although EVM is frequently mentioned, its true meaning is often unclear, especially since the virtual machine (VM) gives a sense of moving from the real to the virtual. In reality, to put it simply, a virtual machine is a specialized operating system. Programmers don’t need to develop for physical entities; they just need to adapt at the software level.

Simplifying the role of EVM, it’s essentially about transactions. Users submit instructions, and EVM, based on user demands like transfers, swaps, staking, or other interactions with smart contracts, executes them one by one. The key here is the instructions and sequential execution. EVM can understand user needs, but execution needs to be queued; the order cannot be changed at will.

So, parallel EVM fundamentally changes the execution order, allowing multiple smart contracts (instructions) to proceed simultaneously. It’s akin to the stand owner hiring workers – he sells watermelons, and the employees sell bananas, but ultimately, the boss takes the earnings.

Explanation of EVM

One of the most typical examples is the BTC Layer 2 solutions mentioned in my previous article. Current BTC Layer 2 solutions are essentially looking to integrate Bitcoin into the EVM ecosystem. In essence, they serve as a virtual machine on Bitcoin, and developers can develop against them without considering Bitcoin’s own architecture and programming language limitations, using the familiar EVM development process to get the job done.

Similarly, EVM is comparable. In an extreme case, if you are a frontend developer, you can even develop without understanding the hardware, operating system principles, or Ethereum principles. You just need to understand the documentation for EVM development tools and interfaces. For instance, you can create the frontend interface for a DEX – theoretical explanation only, as it is quite complex in practice.

In short, a virtual machine is a workshop that processes without considering hardware and principles. For example, if Bob wants to make watermelon juice, the virtual machine is the juicer. Making a glass of watermelon juice only requires three steps: open the lid, place the watermelon, and juice it – done.

Similarly, EVM is Ethereum’s juicer. Being EVM-compatible is like buying a discounted juicer for L1/L2, despite some flaws, it works. Parallel EVM is like multiple juicers working together.

It’s not that manual labor is ineffective; it’s just that the juicer offers better value for money.

Finally, the concept of parallel EVM resurfaces. Essentially, Ethereum can only process transactions one by one due to speed limitations, resulting in a mainnet TPS stable at around 10. Even relatively centralized EVM-compatible chains like BNB Chain can only increase to around 200. In the absence of revolutionary breakthroughs in physical hardware and Ethereum’s inability to transform into a parallel mechanism, the parallel EVM track will remain hot for the long term. After all, no one complains about speed.

Current Status: Optimistic Verification Becomes Consensus, the Move ecosystem May Become a Solution

The concepts of parallelism and VM have long existed, but their introduction to blockchain, especially the concept of parallel EVM, can be traced back to 2022. Aptos released the paper “Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing” as a starting point. Later, Polygon PoS chain attempted to integrate this functionality by the end of the year. Not only that, many solutions and ideas proposed by Aptos in this paper have become industry common choices and deserve introduction.

Parallel EVM-Related Projects and Classifications

Block-STM: The Initial Parallel EVM Project

It can be said that Aptos is the leader of parallelization in blockchain. While Solana and Near have explored this area, Aptos, applying STM (Software Transactional Memory) to reorder transactions in blockchain, assumes initially that the reordered transactions are correct. It then executes them in parallel and identifies any discrepancies afterward. Individual discrepancies are resolved separately. Following the Pareto principle, this approach accelerates the execution of the majority of transactions. This is referred to as the optimistic verification mechanism, and the core idea is similar to the optimistic verification mechanism in Rollup.

Block-STM

Specifically, Block-STM divides the blockchain execution process into two stages: the sequencing stage and the execution stage.

• In the sequencing phase, Block-STM uses STM to sequence transactions to ensure the order of transactions;
• In the execution phase, Block-STM uses the sequencing results to execute transactions in parallel, thereby improving execution efficiency.

Since then, most parallel EVM implementations follow a similar approach. The differences lie in the implementation of sequencing and execution, as well as the need to enhance compatibility with EVM. Projects like Neon EVM and Polygon PoS fall into this category.

Sui Transformation: Everything is an Object

Sui and Aptos share a common origin, and while they are highly similar, the key difference lies in Sui’s focus on objects. For example, in the process of Alice transferring 1 USDT to Bob:

• Aptos: Alice’s account decreases by 1 USDT, and Bob’s account increases by 1 USDT, involving the accounting information and balance changes of two accounts.
• Sui: 1 USDT remains unchanged; only its ownership attribute changes from Alice to Bob. This involves only the information change of 1 USDT.

As you can see, Sui’s starting point is not to examine the accounts of both parties in the transaction but rather to involve changes in the properties of objects. This can be extended beyond token transfers to assets such as NFTs.

Furthermore, if an asset involves only changes in attributes between two parties, there is no need to synchronize the full node. As long as both parties acknowledge the transaction, such transactions can be processed in parallel.

Of course, the specific implementations of the two are much more complex, and parallelism brings about many challenges. However, understanding this much is sufficient.

Solana and Neon EVM: Going Live through Existing Mechanism

Solana achieves parallel processing through the Sea Level mechanism, similar to Block-STM (though Sea Level was introduced in 2019, predating Block-STM in 2022). Both require sequencing transactions before execution.

Solana’s “innovation” lies in specialized optimization of hardware resources. In theory, it can sequence all instructions, and the optimized multi-threading can utilize the full power of processors, achieving high concurrency. The theoretical TPS value is 50,000, with actual testing reaching around 5,000 at peak.

So, what is the relationship with Neon EVM?

Neon EVM Expenses

Neon’s task is to synchronize transaction information from EVM and then perform computations on Solana. This approach allows leveraging the richness and security of the EVM ecosystem for dApps while utilizing Solana to enhance speed and reduce costs. Compared to the expensive and slow Ethereum mainnet, Neon’s authorizations, transfers, and interactions generally cost around $0.1 or even below $0.01.

In a somewhat loose analogy, Neon turns Solana into an alternative L2 for Ethereum. By extension, L1/L2 EVM can not only implement parallelism but also serve as intermediaries. They can focus on EVM compatibility or act solely as L1/L2, outsourcing the remaining components.

This aligns with the broader concept of modularization and generalization mentioned at the beginning, where L1/L2 parallel EVM could be a combined product of three projects or even involve cross-chain combinations, offering a diverse range of possibilities.

Sei V2 and Monad: Byte Compatibility

From a technical standpoint, Sei V2 and Monad share significant similarities. Both projects focus on byte-level compatibility with EVM on Ethereum. In terms of parallelization, they independently opt for familiar optimistic validation. They sequence transactions first, execute those that can proceed, and address dependencies separately in case of errors.

Sei V2 Parallelization Scheme Explanation

Certainly, mature products and approaches are widely applicable. However, it’s crucial to note that, much like BTC L2, genuine technological innovations are limited, and the emphasis remains on “combination.” Solana stands out as the sole large-scale implementation of parallelism, achieving high concurrency through a combination of software and hardware. Others predominantly offer a package deal of “EVM compatibility + parallelism.”

As one might expect, if Solana can serve as an accelerator, then Aptos and others can too. Lumio, for instance, follows a similar approach—acting as an intermediary, simultaneously ensuring EVM compatibility and implementing parallelism. Hence, any project adopting this dual strategy can be referred to as parallel EVM. Consequently, I won’t delve further into Lumio in this context.

Conclusion: The Dilemma of Parallel EVM

In this article, I’ve emphasized that the core of parallel EVM lies in the allocation of hardware resources and the sequence and execution of tasks—both essential components. Hardware constraints impose an upper limit on software optimization, considering that even Usain Bolt can’t surpass the speed of light. Currently, most parallel EVM initiatives are either transformations or imitations of Aptos’ Block-STM, and this is a fundamental reality.

Furthermore, there’s no need for extensive exploration of parallel practices on Ethereum L2 at the moment. These solutions primarily need to address the centralization issues related to sequencers, as their efficiency is already sufficiently high.

Parallel EVM isn’t mysterious. In the article, I’ve omitted technical details such as read-write mechanism design, TPS comparisons, data recording, and state synchronization. These intricacies aren’t necessary for the average person to understand. Simply remember that we are currently in the era of optimistic validation, where execution precedes error checking. If there are updates, I will promptly provide additional information.

Disclaimer：

1. This article is reprinted from [佐爷歪脖山], Forward the Original Title‘Parallel Solutions Beyond EVM – High-Performance L1 (Sui) Battles Ethereum L2?’,All copyrights belong to the original author [佐爷]. 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.