Original author: 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 developing parallel EVM? In my opinion, Parallel EVM is the last gamble of the EVM chain to fight against high-performance layer 1 chains, and it is related to the survival battle of the Ethereum EVM ecosystem. Why? Next, lets talk about my understanding:
Since the Ethereum EVM virtual machine can only perform transactions “serially”, the EVM-Compatible layer 1 chain and the EVM-compatible layer 2 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 layer 1 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 layer 1 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 layer 1 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 layer 1 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 layer 2 EVM-compatible chains represented by Eclipse and MegaETH use the independent consensus and transaction pre-processing capabilities of layer 2 chains to screen and process transaction status before large-volume 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-layer 1 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, 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 layer 2 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 features of other non-EVM chains, they are more aimed at extracting Ethereums 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 layer 1 track.
So, what is the key to building 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 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 to conduct parallel transactions with fast response speed, controllable computing consumption, and high accuracy;
Specifically for the parallel EVM layer 1 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 can dynamically adjust the block size 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 a 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?
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 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. According to the historical execution record of the contract, it predicts which states will be used in the next specific contract call and preloads them into the 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 underlying API access rights to achieve secure isolation of 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 parallelism 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.
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 Artelas 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 at 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.
