The last video is ready: understand the development paradigm of BTC L2 in one breath ~ https://www.bilibili.com/video/BV1dw411575M/?vd_source=e88bbc11f1ecd88d1c5847538efee51c
The competition in Alt L1 has become fierce. Near has launched a DA solution and Sui’s TVL has been rising. Only Ethereum is still unhurriedly upgrading its main network. Two major competition points have emerged in L2: parallel EVM and decentralized sequencer.
At present and in the future, a basic fact is that Ethereum's position is difficult to shake, and the concept of modularity will be generalized. If Vitalik's suppression of Celestia is unsuccessful, the market will choose the best one. Combination and modularity not only occur in the same system. Market principles will prompt project parties to freely assemble various elements, such as the availability of combinations between public chains, L2 and Bitcoin. The popularity of BTC L2 is a clear proof of this.
If Near can do the job of DA, then high-performance public chains such as Aptos, Solana and Sui can also be "L2-ized" and eventually compatible with and absorbed by Ethereum.
Parallel EVM can be understood as a parallelized EVM-compatible chain/L2. Starting from the blockchain speed, there are only two ways to solve the slow blockchain operation in theory:
Add hardware and continuously optimize it. For example, Solana's hardware configuration is uniquely high, and the management and configuration of the "computer room" allows Solana to enjoy ultra-high network speed and improve throughput;
Multi-core parallelism and multi-thread concurrency. With hardware upgrades, multi-cores can truly achieve multi-tasking. In addition, continuously dividing and subdividing tasks can also improve efficiency, which is also a common practice in computers.
Assuming that hardware utilization has reached its limit, parallel EVM can be classified and understood from the following three levels:
Parallelism is a common practice in the computer field, and any public chain and L2 can use it. For example, Alt L1 such as Aptos, Sui and Solana, or Sei, which claims to be the first EVM-compatible L1, as well as Ethereum L2 projects such as Scroll (2024 roadmap), Lumio, Eclipse, and Neon EVM, which belongs to the Solana ecosystem and also claims to be the first EVM-compatible solution.
In a narrow sense, parallel EVM refers to L1/L2 that is compatible with EVM. In theory, Ethereum itself can also implement parallel transformation, which is the most consistent with the definition of parallel EVM, but the action is too big to be possible.
Parallel EVM can be expanded in a broad sense. Any parallel computing chain, regardless of whether it is compatible with EVM, can be included as long as it can establish a link with EVM, such as using Aptos as an "accelerator" of Ethereum.
It is also of special significance to examine the non-EVM-compatible Alt L1, which can be connected to the EVM ecosystem. In addition, the Block-STM solution pioneered by Aptos has also become the de facto template and source of ideas for many emerging parallel EVM solutions, which will be described in detail below.
Prerequisites: A simple explanation of threads, processes, parallelism and concurrency, and EVM
I categorized them according to the idea of parallel EVM disassembly, but the explanation of the concept of parallelism is still incomplete. If I directly talk about the logic of project implementation, people will be confused, which is simply making people dizzy with its own obviousness.
Similarly, explanations such as "process is the smallest unit of resource allocation, and thread is the smallest unit of CPU scheduling" are professional but not very friendly to most people. I would like to use buying melons as an example to illustrate this process.
Let's lay the groundwork first. The bottom layer of our computer is physical hardware, and above that are the operating system and various applications. When the computer processes a task, it allocates software and hardware resources according to priority. Let's use Huaqiang buying melons to illustrate this process:
The relationship between threads, processes, parallelism and concurrency
Huaqiang rides his bike to buy a watermelon. This is a single behavior and the smallest unit, a thread. A watermelon is the physical hardware resource that can be called at this time. There are no more.
Two Huaqiangs want to buy a watermelon together. This is a compound behavior because two Huaqiangs want to eat the watermelon. However, please note that there is still only one watermelon at this time, and there is no more. And the two Huaqiangs agreed to cut the watermelon together. Whoever does not go is not a brother. At this time, the two Huaqiangs buying watermelons is a process, and each Huaqiang eating watermelons is still a thread, so one process includes two threads.
At this time, the situation where there is only one watermelon but multiple people want to eat it is concurrency. The key here is that everyone eats the watermelon together to ensure that everyone can at least have a bite, because no matter how many people are eating the watermelon, how they divide their seats and the order of eating, it will not affect the final result of multiple people eating one watermelon.
You, as a smart person, must have spotted the problem. Why do so many people have to eat watermelon together? The owner of a watermelon stall is essentially a fruit shop owner. You can also eat bananas. You are right. This is why supply-side reform is needed. Now the boss has announced that bananas are also on the market. Then the physical resources (fruits) have increased. Huaqiang can be divided into two columns to eat different fruits respectively. This is parallelism. Two rows are in parallel, and everyone eats what he likes.
(Disclaimer: The above explanation is relatively popular but not professional. If there is any dispute, the programmer’s understanding shall prevail. I am a half-baked person.)
The next step is to combine them with the EVM to assemble what a parallel EVM really means.
Although EVM is often mentioned, its real meaning is unclear, especially the virtual machine (VM), which always gives people a feeling of being detached from reality and moving towards virtuality. In fact, to be frank, a virtual machine is a specialized operating system. Programmers do not need to develop for physical entities, but only need to adapt at the software level.
To simplify, the role of EVM is trading. Users submit instructions, and then EVM will execute them one by one according to the user's needs, such as transfer, SWAP, pledge, or other behaviors that require interaction with smart contracts. The focus here is on instructions and one-to-one execution. EVM can understand the user's needs, but the execution needs to be queued and the order cannot be changed at will.
Therefore, the essence of parallel EVM is to change the execution order, allowing multiple smart contracts (instructions) to run at the same time, which is equivalent to a stall owner hiring workers. He sells watermelons and his younger brother sells bananas. In the end, the profit still belongs to the boss.
EVM Description
The most typical example is the BTC L2 mentioned in my previous article. The current BTC L2 basically wants to connect Bitcoin to the EVM ecosystem. In fact, they themselves are virtual machines on Bitcoin. When developers develop for them, they do not need to consider the limitations of Bitcoin’s own architecture and programming language, and can use the familiar EVM development process in one step.
The same is true for EVM. To put it more extremely, if you are a front-end developer, you can even develop documents without any understanding of hardware, operating system principles, or Ethereum principles. You only need to understand the description of EVM development tools and interfaces, such as writing the front-end interface of a DEX (only theoretical explanation, it is actually very complicated).
In a nutshell, a virtual machine (VM) is a processing workshop without hardware and principles. For example, if Huaqiang buys melons to make watermelon juice, then the virtual machine is the juicer. A glass of watermelon juice only requires three steps: open the lid, put in the watermelon, and squeeze the juice. That's it.
Similarly, EVM is the juicer of Ethereum, and compatible EVM is the L1/L2 juicer. Although it has some flaws, it can still be used, and parallel EVM is multiple juicers working together.
It’s not that you can’t afford manual work, but that a juicer is more cost-effective.
Finally, the concept of parallel EVM has re-emerged. In essence, Ethereum can only process single transactions in sequence due to speed limitations. Its main network TPS can only be stabilized at around 10, and more centralized EVM-compatible chains such as BNB Chain (BSC) can only be increased to around 200. In the absence of revolutionary breakthroughs in physical hardware and Ethereum itself cannot be transformed into a parallel mechanism, the parallel EVM track will be hot for a long time. After all, no one will complain about speed.
Current situation: Optimistic verification has become a consensus, and the Move system is gradually showing signs of being saved
The concepts of parallelism and VM have existed for a long time, but their introduction into blockchain, especially the concept of parallel EVM, actually started in 2022. Aptos published the paper "Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing", and then the Polygon PoS chain tried to add this function at the end of that year. Not only that, many of the solutions and ideas proposed by Aptos in this paper have also become the common choice of the industry and need to be introduced.
Parallel EVM related projects and categories
The starting point of the dream: Block-STM
It can be said that Aptos is the epitome of blockchain parallelization. Although Solana and Near have already explored this, Aptos uses STM (Software Transactional Memory) in the blockchain to reorder transactions. The core idea is to first assume that the sorted transactions are correct. If errors are found after parallel execution, they are solved separately. According to the 80/20 rule, most transactions can be accelerated. This so-called optimistic verification mechanism is basically the same as the optimistic verification mechanism in Rollup.
Block-STM
Specifically, Block-STM divides the execution process of blockchain into two stages: the sorting stage and the execution stage.
In the sorting phase, Block-STM uses STM to sort transactions to ensure the order of transactions;
During the execution phase, Block-STM uses the sorting results to execute transactions in parallel, thereby improving execution efficiency.
Parallel EVMs since then are basically similar to this, except that there are implementation differences in ordering and execution, as well as the need to increase compatibility with EVM. For example, Neon EVM and Polygon PoS belong to this category.
Sui transformation: everything is an object
Sui and Aptos come from the same school and are highly similar, but the biggest difference is that Sui is centered on objects. For example, in the process of transferring money from Alice to Bob, it works as follows:
Aptos: Alice's account is deducted by 1 USDT, and Bob's account is added by 1 USDT, which involves the accounting information and balance changes of the two accounts;
Sui: 1 USDT remains unchanged, only its ownership attributes are changed, changing the ownership from Alice to Bob, which only involves the change of information of 1 USDT;
As you can see, Sui’s starting point is not to examine the accounts of the two parties to the transaction, but to involve changes in the attributes of the object. By extension, it can be not only token transfers, but also assets such as NFTs.
To extend this further, if an asset only involves attribute changes between peers, it is not actually necessary to synchronize the entire node. As long as both parties approve the transaction, such transactions can be processed in parallel.
Of course, the specific implementation of the two is much more complicated, and parallelism will also bring many problems, but it is enough to understand this.
Solana and Neon EVM: Backdoor Listings
Solana's own parallel processing is implemented through the Sea Level mechanism, which is similar to Block-STM (in fact, it should be reversed, Sea Level was proposed in 2019 and Block-STM was proposed in 2022). Both require transactions to be sorted and then executed.
Solana's "innovation" lies in the special optimization of hardware resources. In theory, not only can all instructions be sorted, but the optimized multi-threading can also bring out the full performance of the processor to achieve high concurrency. The theoretical TPS value is 50,000, and the actual peak value can reach about 5,000.
So how does this relate to Neon EVM?
Neon EVM Fees
All Neon has to do is synchronize EVM's transaction information and then use Solana for calculations. This way, it can take advantage of the richness and security of the dApps in the EVM ecosystem, and also use Solana to increase speed and reduce fees. Compared with the expensive and slow Ethereum mainnet, Neon's authorization, transfer, deposit and borrowing are basically below 0.1 or even 0.01 US dollars.
It is not quite appropriate to say that Neon has turned Solana into an alternative L2 of Ethereum. By analogy, L1/L2 EVM can not only achieve parallelism by itself, but can also act as an intermediary, which is only responsible for compatibility with EVM or only doing L1/L2, and outsourcing the rest.
This is also what I said at the beginning, the true meaning of generalized modularity. L1/L2 parallel EVM can be a combination of three projects, or even a cross-chain combination. In this way, the gameplay is diverse.
Sei V2 and Monad: Happy Together, Byte Compatible
From the perspective of technical implementation, Sei V2 and Monad are very similar. Both are byte-level compatible with Ethereum’s EVM. In fact, in terms of parallel thinking, they both chose the familiar optimistic verification, first sorting, executing what can be executed, and then solving the dependencies separately if there are errors.
Sei V2 Parallel Solution Description
Of course, everyone can use mature products and ideas, but it should be noted that, like BTC L2, there are not many real technological innovations, and it is still mainly based on "combination". Solana is the only L1 that practices parallelism on a large scale and uses a combination of software and hardware to achieve high concurrency effects. Others are more of a "EVM-compatible + parallel" package.
Everyone can definitely think that since Solana can be used as an accelerator, then Aptos and others can also be used. In fact, Lumio also thinks so. As long as it acts as an intermediary, is compatible with EVM on one hand and achieves parallelism on the other hand, it can be called a parallel EVM. Therefore, there is no need to explain Lumio in detail.
Conclusion: The Parallel EVM Dilemma
In this article, I emphasize that the core of parallel EVM is the allocation of hardware resources and the ordered execution of tasks. Both are indispensable. The upper limit of software optimization is the parameter limitation of physical hardware. After all, Bolt cannot exceed the speed of light. However, parallel EVM is currently mainly a modification and imitation of Aptos' Block-STM, which is also a basic fact.
In addition, there is currently no need to over-explore parallel practices on Ethereum L2. They need to solve the centralization problem of the sorter, and the efficiency is already high enough.
Parallel EVM is not mysterious. I have omitted the technical details of the read and write mechanism design, TPS comparison, data recording and state synchronization of each project in the text. Ordinary people don’t need to understand these things at all. Just remember that you are currently in the process of optimistic verification. Optimistic verification is the idea of executing first and then debugging. If there is any update, I will supplement it for you in time.