Technical Analysis by Artela: Why is “Parallel EVM” a battle for the survival of the Ethereum EVM ecosystem?
Written by: Haotian
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 the development of 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, the EVM-Compatible layer1 chain and the EVM-compatible layer2 chain are also subject to corresponding performance constraints, because they are essentially based on the same framework to handle status and transaction finality.
However, high-performance layer1 chains such as Solana, Sui, and Aptos have the inherent 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? In terms of technical principles and details, I will take the parallel EVM new chain @Artela_Network as an example to explain:
1) Enhanced EVM layer1 chains represented by Monad, Artela, SEI, etc., 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 they still aim to be compatible with and expand the EVM ecosystem. This is equivalent to reconstructing the EVM chain in a "bloodline-changing" way and serving the EVM ecosystem.
2) Scalable layer2 EVM-compatible chains represented by Eclipse and MegaETH use the independent consensus and transaction "pre-processing" capabilities of the layer2 chain to screen and process transaction status before large-scale transactions are batched to the main network, and can simultaneously select the execution layer of any other chain to finalize the transaction status. This is equivalent to abstracting the EVM into a pluggable execution module, which can select the best "execution layer" as needed, thereby achieving parallel capabilities; however, this type of solution can serve the EVM, but it is beyond the scope of the EVM framework;
3) Equivalent Alt-layer1 chains represented by Polygon and BSC have achieved the parallel processing capabilities of EVM to a certain extent, but they have only optimized the algorithm layer, and have not optimized 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., to some extent, are not EVM chains, but they are inherently highly concurrent execution capable, and then through some middleware or coding parsing methods, they achieve compatibility with the EVM environment. This is the case with Starknet, which is Ethereum layer 2. Because Starknet has Cario language and account abstraction, it also has parallel capabilities, but its compatibility with EVM requires a special pipeline. These Non-EVM chains basically have this problem when connecting their parallel capabilities to EVM chains.
The above four solutions have different focuses. For example, the layer2 with parallel capabilities focuses on the flexibility of modular combination of "execution layer" chains; 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 completely consolidate the EVM ecosystem and change the parallel capabilities from the bottom up, leaving only the enhanced EVM layer1 track.
So, what is the key to building an enhanced parallel EVM layer1 public chain? How can we reconstruct the EVM chain and serve the EVM ecosystem? There are two key points:
1. The ability to access state I/O disks 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 technologies to balance the reading speed and the possibility of state conflicts from the fundamental state storage and reading process.
2) Efficient network communication, data synchronization, algorithm optimization, virtual machine enhancement, and optimization of various components at the consensus mechanism layer such as separation of computing and IO tasks, etc. require comprehensive optimization and improvement of the underlying component architecture, collaboration process, and other aspects, ultimately achieving 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 need to be made to realize "parallel EVM"?
In order to fully realize the "parallel EVM" capability of resource coordination and optimization from the underlying architecture layer, 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, State I/O disk reading performance is critical to parallel EVM. The "parallel" capabilities achieved by EVM-Compatible chains such as Polygon and BSC through algorithms can also achieve a 2-4 times efficiency improvement, but it is only an optimization at the algorithm layer. Its consensus layer and storage layer have not been deeply optimized. What will the real deep optimization be like?
To address this, Artela has borrowed from database technology solutions and made improvements in both state reading and writing. In terms of writing state, it has adopted the write-before-log (WAL) technology. When the state changes and needs to be written, the change record is first written to the log and submitted to the memory. It can be considered that the "write" operation is 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.contractHistorical execution records to predict the next specificcontractThe states that will be used in the call are pre-loaded into memory, thereby improving the efficiency of disk I/O requests.
In short, this is an algorithm that exchanges memory space for execution time, thereby fundamentally improving the parallel processing capabilities 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 low-level API access rights to achieve execution layerSafety隔离。这使得开发者可以在 Artela 的环境下高效地开发，调试和部署智能合约，以此激活开发者群体的定制扩展能力。特别是，开发者也会被激励在智能合约代码层就往可并行的方向进行代码优化，毕竟要减少状态冲突概率，每一个智能合约的Xiaobai NavigationCalling logic and algorithms are particularly critical.
above
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. This 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 strengths, and it does adopt the essence of "technical processing" under high traffic loads from time to time in the mature web2 application market.
If we look to the distant future of Mass Adoption, "Parallel EVM" is indeed the basic infra for the EVM ecosystem to face the broader web2 market in the next step, and it is reasonable that it is so bullish in the capital market.
The article comes from the Internet:Technical Analysis by Artela: Why is “Parallel EVM” a battle for the survival of the Ethereum EVM ecosystem?
The halving will push up the price of Bitcoin in the medium term; however, the price action before and after is likely to be negative. Written by: Arthur Hayes, Founder of BitMEX Translated by: Deng Tong, Golden Finance Ping, Ping, Ping, this is the sound of my phone reminding me of the nighttime snowfall at various ski resorts in Hokkaido that I monitor. Although this sound is not heard in January and February…
相关文章
