Why is “Parallel EVM” a battle for the survival of the Ethereum EVM ecosystem?

Author: Haotian, independent researcher Source: X, @tmel0211

Recently, Paradigm made a big bet and led a huge round of financing of $225 million in Monad, which aroused strong market attention to "parallel EVM". So, what problem does "parallel EVM" solve? What are the bottlenecks and keys to developing parallel EVM? In my opinion, "parallel EVM" is the last gamble of the EVM chain to fight against the high-performance layer1 chain, which is related to the survival battle of the Ethereum EVM ecosystem. Why? Next, let's talk about my understanding:

Since the Ethereum EVM virtual machine can only "serialize" transactions, this makes the EVM-Compatible layer1 chain and the EVM-compatible layer2 chain also subject to corresponding performance constraints, because everyone is essentially based on the same framework to handle state and transaction finality.

However, high-performance layer1s such as Solana, Sui, and Aptos inherently have the advantage of being parallel. In this context, if chains with EVM genes want to face the impact of high-performance layer1 public chains head-on, they must make up for the inherent lack of "parallel" capabilities. How to do it? Regarding the technical principles and details, I will take the parallel EVM emerging chain @Artela_Network as an example to explain: 1) Enhanced EVM layer1 chains represented by Monad, Artela, SEI, etc., which will greatly improve TPS on the basis of high compatibility with EVM and enable transactions to run in parallel in a quasi-EVM environment. These independent parallel EVM layer1 chains have independent consensus mechanisms and technical characteristics, but will still aim to be compatible with and expand the EVM ecosystem, which is equivalent to reconstructing the EVM chain in a "bloodline change" manner and serving the EVM ecosystem; 2) Expansion-type layer2 EVM-compatible chains represented by Eclipse, MegaETH, etc., which use the independent consensus and transaction "pre-processing" capabilities of the layer2 chain to screen and process the transaction status before large quantities of transactions are batched to the main network, and can simultaneously select the execution layer of any other chain to finally determine the transaction status. It is equivalent to abstracting EVM into a pluggable execution module, which can select the best "execution layer" as needed, thereby realizing parallel capabilities; however, this type of solution can serve EVM, but it is beyond the scope of the EVM framework;

3) Equivalent Alt-layer1 chains represented by Polygon, BSC, etc., which have realized the parallel processing capabilities of EVM to a certain extent, but only optimized the algorithm layer, and did not optimize the deep consensus layer and storage layer. Therefore, this type of parallel capability can be regarded as a specific feature, and has not completely solved the parallel problem of EVM.

4) Differentiated Non-EVM parallel chains represented by Aptos, Sui, Fuel, etc., are not EVM chains to some extent, but are in contact with their inherent high concurrent execution capabilities, and then through some middleware or coding parsing methods, they have achieved compatibility with the EVM environment. This is the case with Starknet, which is Ethereum's layer 2. Since Starknet has Cario language and account abstraction, it also has parallel capabilities, but its compatibility with EVM requires a special pipeline. The parallel capabilities of these Non-EVM chains are basically connected to the EVM chain.

The above four solutions have different focuses. For example, the layer 2 with parallel capabilities focuses on the flexibility of modular combination of "execution layer" chains; while the EVM-Compatible chain highlights the customization of specific functions; as for the EVM compatibility of other non-EVM chains, they are more aimed at extracting Ethereum's liquidity; the real goal is to thoroughly consolidate the EVM ecosystem and change the parallel capabilities from the bottom. Only one enhanced EVM layer 1 track is left.

So, what is the key to making an enhanced parallel EVM layer 1 public chain? How can we reconstruct the EVM chain and serve the EVM ecosystem? There are two key points: 1. The ability to access the state I/O disk to read and output information. Since reading and writing data takes time, simply sorting and scheduling transactions cannot fundamentally improve parallel processing capabilities. It is also necessary to introduce cache, data slicing and even distributed storage technology, etc., to balance the reading speed and the possibility of state conflicts from the fundamental state storage and reading process; 2) Having efficient network communication, data synchronization, algorithm optimization, virtual machine enhancement, and various component optimizations of the consensus mechanism layer such as separation of computing and IO tasks, etc., requires comprehensive optimization and improvement of the underlying component architecture, collaborative processes and other aspects, and ultimately promotes the ability of parallel transactions with fast response speed, controllable computing consumption and high accuracy; Specifically for the parallel EVM layer1 chain project itself, what technical innovations and framework optimizations should be made to realize "parallel EVM"?

In order to completely realize the "parallel EVM" capability of resource coordination and optimization from the bottom layer of the architecture, Artela introduced elastic computing and elastic block space. How to understand it? Elastic computing, the network can dynamically allocate and adjust computing resources according to demand and load; elastic block space, the block size can be dynamically adjusted according to the number of transactions and data size in the network; the working principle of the entire elastic design is just like the escalator in the shopping mall that automatically senses the flow of people to work, which makes sense;

As mentioned earlier, the State I/O disk read performance is critical to parallel EVM. The "parallel" capability achieved by the algorithm of EVM-Compatible chains such as Polygon and BSC can also achieve 2-4 times efficiency improvement, but it is only the optimization of the algorithm layer, and its consensus layer and storage layer have not been deeply optimized. What will the real deep optimization be like?

In response to this, Artela borrowed from the database technology solution and made improvements in both state reading and writing. In terms of writing state, the write-before-log (WAL) technology was used. When the state changes to be written, the change record is first written to the log and submitted to the memory, and the "write" operation can be considered completed. This actually realizes the asynchronous operation and avoids the immediate disk write operation when the state changes, thereby reducing the I/O operation on the disk. In terms of state reading, it is essentially an asynchronous operation. The preloading strategy is used to improve the reading efficiency. According to the historical execution record of the contract, it predicts which states will be used in the next specific contract call and pre-loads them into the memory, thereby improving the disk I/O request efficiency.

In short, this is an algorithm that exchanges memory space for execution time, thereby fundamentally improving the parallel processing capability of the EVM virtual machine, and fundamentally optimizing the state conflict problem.

In addition, Artela introduces Aspect modular programming capabilities to better manage complexity and improve development efficiency: by introducing WASM encoding parsing to enhance programming flexibility; at the same time, it also has underlying API access rights to achieve secure isolation at the execution layer. This allows developers to efficiently develop, debug and deploy smart contracts in the Artela environment, thereby activating the customized expansion capabilities of the developer community. In particular, developers will also be motivated to optimize the code in the direction of parallelization at the smart contract code layer. After all, to reduce the probability of state conflicts, the calling logic and algorithm of each smart contract are particularly critical.

It is not difficult to see that the concept of "parallel EVM" is essentially to optimize the execution process of transaction status. @monad_xyz claims to be able to reach 10,000 transactions per second. Its technical core is nothing more than dedicated databases, developer friendliness, delayed execution consensus, superscalar pipeline technology, etc. to achieve parallel processing of large-scale transactions, which is not much different from the essential logic of Artela's elastic computing and I/O asynchronous operations.

But what I actually want to express is that this type of high-performance parallel EVM chain is actually the result of integrating web2 products and technical strength, and it does adopt the essence of "technical processing" under high traffic load from time to time in the mature web2 application market.

If we look at the distant future of Mass Adoption, "Parallel EVM" is indeed the basic infra for the next step of the EVM ecosystem to face the wider web2 market, and it is reasonable that it can be so bullish in the capital market.