Artela, Unleashing the Power of Parallel EVM

Forward the Original Title:Technical Analysis Artela: Why is “Parallel EVM” related to the battle for the survival of the Ethereum EVM ecosystem?

Paradigm’s recent lead investment of a whopping $225 million in Monad’s funding round has sent shockwaves through the market, igniting a surge of interest in “parallel EVM”. But what exactly does “parallel EVM” address? What are the bottlenecks and key challenges in developing parallel EVM? I believe that “parallel EVM” represents the EVM chain’s last stand against high-performance layer 1 chains, a battle that will determine the survival of the Ethereum EVM ecosystem. Why? Let’s delve into my understanding:

The Ethereum EVM virtual machine’s inherent “serial” transaction processing capability has imposed significant performance constraints on both EVM-compatible layer 1 chains and EMV-compatible layer 2 chains. This stems from the fact that they all fundamentally rely on the same framework to process state and transaction finality.

In contrast, high-performance layer 1 chains like Solana, Sui, and Aptos possess inherent parallel processing advantages. Against this backdrop, EVM-based chains must address their inherent lack of parallel capabilities to effectively compete with these high-performance layer 1 public chains. Let’s explore the different approaches to implementing parallel EVM, using the example of Artela Network, a rising star in the parallel EVM space:

1）Represented by chains like Monad, Artela, and SEI, these chains significantly enhance TPS while enabling parallel transaction capabilities within a quasi-EVM environment. These independent parallel EVM layer 1 chains possess unique consensus mechanisms and technical characteristics, but they still maintain the goal of compatibility and expansion within the EVM ecosystem. Essentially, they reconstruct EVM chains by “changing their bloodline” to better serve the EVM ecosystem.

2） Exemplified by chains like Eclipse and MegaETH, these chains leverage the independent consensus and transaction “pre-processing” capabilities of layer 2 chains to filter and process transaction states before batching them to the mainnet. They can also select the execution layer of any other chain to finalize transaction states. This approach essentially abstracts EVM into a pluggable execution module, enabling the selection of the best “execution layer” based on need, thereby achieving parallel capabilities. However, while these solutions can serve EVM, they operate outside the EVM framework.

3）Represented by chains like Polygon and BSC, these chains have achieved a certain degree of parallel EVM processing capability. However, their optimizations are limited to the algorithm layer, without delving deeper into the consensus and storage layers. Consequently, their parallel capabilities are more akin to a specific feature rather than a comprehensive solution to EVM’s parallelization challenges.

4）Exemplified by chains like Aptos, Sui, and Fuel, these chains are not strictly EVM chains. Instead, they capitalize on their inherent high concurrency execution capabilities and employ middleware or code parsing techniques to achieve compatibility with the EVM environment. This is evident in the case of Starknet, an Ethereum layer 2 solution. Starknet’s compatibility with EVM requires a special conduit due to its Cario language and account abstraction features. This compatibility challenge is a common issue with non-EVM chains attempting to bridge with EVM chains.

The four approaches mentioned above each have their own emphasis. For example, Layer 2 with parallel capabilities focuses on the flexibility of modular combinations of “execution layer” chains, while EVM-Compatible chains highlight the customized features of specific functions. As for other non-EVM chains with EVM compatibility features, they aim more at tapping into Ethereum’s liquidity. The real goal is to thoroughly consolidate the EVM ecosystem, leaving only one reinforced EVM layer 1 track for enhancing parallel capabilities.

So, what are the key factors in strengthening a parallel EVM layer 1 public chain? How can we reconstruct an EVM chain while still serving the EVM ecosystem? There are two key points:

1. The ability to access state I/O disk reading and output information. Since reading and writing data takes time, simply sorting and scheduling transactions cannot fundamentally improve parallel processing capabilities. It also requires the introduction of caching, data slicing, and even distributed storage technologies 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 reinforcement, and various component optimizations of consensus mechanism layer such as separating computation and I/O tasks, which require comprehensive optimization and enhancement from various aspects including bottom-layer component architecture and collaborative processes. This ultimately leads to the ability to execute parallel transactions quickly, with controllable computation consumption and high accuracy.

Regarding the specific project of the parallel EVM layer 1 chain itself, what technological innovations and framework optimizations are needed to achieve “parallel EVM”?

To thoroughly achieve the resource coordination and optimization capabilities of “parallel EVM” from the bottom-layer architecture, Artela introduces Elastic Computing and Elastic Block Space. How to understand them? Elastic computing allows the network to dynamically allocate and adjust computing resources according to demand and load, while elastic block space adjusts block size dynamically based on the number of transactions and data size in the network. The entire elastic design principle works similar to escalators in shopping malls that automatically sense pedestrian flow, which makes perfect sense.

As mentioned earlier, the performance of state I/O disk reading is crucial for parallel EVM. EVM-Compatible chains like Polygon and BSC achieve efficiency improvements of 2-4 times through algorithmic parallelism, but this is only optimization at the algorithmic level. The consensus layer and storage layer have not undergone deep optimization. What would true deep optimization look like?

In response to this, Artela draws on database technology solutions, improving both state reading and writing. For writing states, it introduces Write-Ahead Logging (WAL) technology, which records changes before writing them to the disk. This asynchronous operation avoids immediate disk writing when the state changes, reducing disk I/O operations. For state reading, it essentially adopts asynchronous operations by preloading strategies to improve reading efficiency. By predicting which states will be needed based on contract execution history and preloading them into memory, it enhances disk I/O request efficiency.

In short, this is an algorithm that trades execution time for memory space, fundamentally improving the parallel processing capabilities of the EVM virtual machine and optimizing the state conflict issue from the ground up.

In addition, Artela introduces Aspect modular programming capabilities to better manage complexity and improve development efficiency. By introducing WASM coding parsing to enhance programming flexibility and providing low-level API access permissions, it achieves secure isolation of the execution layer. This enables developers to efficiently develop, debug, and deploy smart contracts within Artela’s environment, activating the customization and extension capabilities of the developer community. In particular, developers will be encouraged to optimize their smart contract code for parallelism, as reducing the probability of state conflicts is crucial for each smart contract’s invocation logic and algorithm.

That’s all.

It’s not hard for everyone to see that the concept of “Parallel EVM” is essentially optimizing the execution process of transaction status. @monad_xyz claims to be able to achieve 10,000 transactions per second, and its technical core is nothing more than achieving parallel processing of large-scale transactions through specialized databases, developer friendliness, delayed execution consensus, and superscalar pipeline technology, etc. This is not much different from the elastic computing and I/O asynchronous operations of Artela.

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 capabilities. It indeed adopts the essence of “technical handling” under high load from time to time in the mature application market of web2.

If you look at the distant future of mass adoption, “Parallel EVM” is indeed the basic infrastructure for the EVM ecosystem to face a wider market of web2, and it is reasonable for the capital market to be so Bullish.

statement:

1. This article is reproduced from [View on the chain], the copyright belongs to the original author [Hao Tian], if you have any objections to the reprint, please contact the Gate Learn team, and the team will handle it as soon as possible according to relevant procedures.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team and are not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.