Technical Analysis: Why is "Parallel EVM" Related to the Survival of the Ethereum EVM Ecosystem?

Original author: @tmel0211

Original source: X

Note: The original article is from @tmel0211 release long tweet.

Recently, Paradigm led a huge $225 million funding round from Monad, which sparked strong interest in "parallel EVM". So, what exactly does "parallel EVM" solve, and what are the bottlenecks and keys to the development of parallel EVM? In my opinion, "parallel EVM" is the last game for EVM chains to meet high-performance layer1 chains, and it is related to the survival of the Ethereum EVM ecosystem. Next, let's talk about my understanding:

Since the Ethereum EVM virtual machine can only "serially" transactions, both the EVM-compatible layer1 chain and the EVM-compatible layer2 chain are also subject to corresponding performance constraints, because everyone essentially processes the state and transaction finality based on the same set of frameworks.

However, layer1s with high performance such as Solana, Sui, and Aptos have the inherent advantage of being parallel. In this context, if the EVM gene chain wants to face the impact of the high-performance layer1 public chain, it is bound to make up for the inherent lack of "parallelism" ability. Involving the technical principles and details, I will take the parallel EVM cutting-edge chain @Artela_Network as an example to illustrate:

1) Enhanced EVM layer1 chains represented by Monad, Artela, SEI, etc., which will greatly improve TPS on the basis of being highly compatible with EVM and can give transactions parallelism in a quasi-EVM environment.

2) Scalable layer2 EVM-compatible chains represented by Eclipse, MegaETH, etc., which use the independent consensus and transaction "preprocessing" capabilities of the layer2 chain to screen and process the transaction status before a large number of transactions are batched to the mainnet, and can select the execution layer of any other chain at the same time to finalize the transaction status. It is equivalent to abstracting the EVM into a pluggable execution module, and the best "execution layer" can be selected according to the need, thus achieving parallelism, but such solutions can serve the EVM, but they are beyond the scope of the EVM framework;

3) Equivalent Alt-layer1 chains represented by Polygon and BSC, which realize the parallel processing capability of EVM to a certain extent, but only optimize the algorithm layer, and do not optimize the consensus layer and storage layer at a deep level, so this kind of parallel capability can be regarded as more of a specific Feature, and does not completely solve the parallel problem of EVM.

4) Differential non-EVM parallel chains represented by Aptos, Sui, Fuel, etc., to some extent, they do not realize not EVM chains, but are in contact with their innate high concurrency execution capabilities, and then achieve compatibility with the EVM environment through some middleware or coding and parsing methods. We see this as the case of Starknet, which is the layer 2 of Ethereum, because Starknet has the Cario language and account abstraction, so it also has parallelism, but its compatibility with EVM requires a special pipeline. The parallelism of these non-EVM chains is basically related to the EVM chain.

For example, layer2 with parallel capability focuses on the flexibility of the modular combination of "execution layer" chains, while EVM-Compatible chains highlight the customization features of specific functions, and the EVM-compatible features of other non-EVM chains are more about the liquidity of Ethereum.

So, what is the key to making an enhanced parallel EVM layer1 public chain, and how can we reconstruct the EVM chain and serve the EVM ecosystem?

1. The ability to access state I/O disk reading and output information, because the reading and writing of data consumes time, just simple transaction sorting and scheduling can not fundamentally improve the parallel processing ability, and it is also necessary to introduce cache, data slicing and even distributed storage technology, etc., to balance the read speed and the possibility of state conflict from the fundamental state storage and read process;

2) Efficient network communication, data synchronization, algorithm optimization, virtual machine enhancement, and optimization of various components of the consensus mechanism layer such as separating computing and IO tasks, etc., need to be comprehensively optimized and improved from the underlying component architecture, collaboration process and other aspects, and finally promote the ability of parallel transactions with fast response speed, controllable computing consumption and high accuracy;

As for the parallel EVM layer1 chain project itself, what technological innovations and framework optimizations should be made to achieve "parallel EVM"?

In order to fully realize the "parallel EVM" capability of resource coordination and optimization from the underlying architecture layer, Artela has introduced Elastic Computing and Elastic Block Space. Elastic computing, the network can dynamically allocate and adjust computing resources according to demand and load, elastic block space, can dynamically adjust the block size according to the number of transactions and data size in the network, and the working principle of the whole elastic design is just like the escalator that automatically senses the flow of people in a shopping mall, which is very Make Sense.

As mentioned above, the read performance of State I/O disks is critical to parallel EVM, and the "parallelism" capability of EVM-Compatible chains such as Polygon and BSC can also achieve 2-4 times efficiency improvement through algorithms, but it is only the optimization of the algorithm layer, and the consensus layer and storage layer are not deeply optimized.

In view of this, Artela borrowed from the database technology solution, and made improvements in both state read and write, among which the write state went to the pre-write log (WAL) technology, when the state change is to be written, the change record is written into the log and submitted to the memory, which can be considered to have completed the "write" operation, which actually realizes the asynchronous operation, avoiding the disk write operation immediately when writing when the state changes, so the I/O operation on the disk is reduced. In terms of state reading, it is also an asynchronous operation in nature, which improves the reading efficiency through the preload strategy, predicts which states will be used for the next specific contract call based on the historical execution records of the contract, and pre-loads them into memory, thereby improving the efficiency of disk I/O requests.

In short, this is an algorithm that exchanges memory space for execution time, so as to fundamentally improve the parallel processing capacity of the EVM virtual machine, which can be regarded as a fundamental optimization of the state conflict problem.

In addition, Artela has introduced Aspect modular programming capabilities to better manage complexity and improve development efficiency: by introducing WASM code parsing to enhance programming flexibility, and at the same time, it has low-level API access to achieve secure isolation at the execution layer. This allows developers to efficiently develop, debug, and deploy smart contracts in Artela's environment, thereby activating the customization and extensibility capabilities of the developer community. In particular, developers will also be incentivized to optimize the code in the direction of parallelism at the smart contract code layer, after all, the invocation logic and algorithm of each smart contract are particularly critical to reduce the probability of state conflicts.

more than

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

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

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

Note: I would prefer to bring Mass Option to layer 2, and now it seems that I can only jump to a more technical hardcore "parallel EVM" track to continue to roll infra. For a quick overview of more industry analysis, subscribe to my personal Substack column on the Profile page, thank you.