Author: Haotian, independent researcher Source: X, @tmel0211
A new narrative of "parallel EVM" has appeared in the market, which is very interesting in layer 2. It can realize a new "refined" Rollup paradigm. To exaggerate, Solana can become the new layer 2 of Ethereum. Magical modification effect.
In my opinion, parallel EVM is just a highly "modular" manifestation of Rollup. It is the fall of the VM execution layer again after DA was invaded by a third party. In the future, layer2 will be redefined. Why? Next, let’s analyze it from a popular science perspective:
To understand this topic, we must first clarify the single-threaded execution model of "EVM".
This model stipulates that transactions must be processed and confirmed one after another in order, which directly affects the transaction processing speed, block generation time, and transaction throughput Etc., are the main reasons for the high gas and congestion of the Ethereum main network. Moreover, the reason why it is designed to be single-threaded has certain historical limitations.
Since transactions on Ethereum are verified and executed by distributed independent nodes, it is necessary to ensure that the data of all addresses, such as balances, smart contract codes, etc., remain different The status between nodes must be consistent, and at the same time, it must be ensured that there is no possibility of double spending of the same asset.
This causes transactions to be queued in order. If parallel transactions occur, it may lead to errors in data synchronization between nodes. The key is that serious double-spending transactions may occur.
One, the advantage is that every operation of the bank's account system will be accurately recorded, but the customer queue time will be longer;
If the bank opens multiple service windows, Customers can choose windows to handle different businesses, and there will be two windows trying to deduct money from one account at the same time. If the account system reconciliation between windows is not timely, it will lead to double spending. Obviously, this significantly improves efficiency, but it is complicated. Accounting logic can put pressure on the accounting system.
In the layer1 independent chain scenario, if the bottom layer of the chain supports parallel processing, the problem will be easily solved. Since Solana’s computing and storage states are separated, its VM will not receive the user’s After multiple transactions, the node will sort these transactions, and then call the independent storage system status data to detect whether there is a status conflict in these transactions. If there is no conflict, the transaction will be packaged into a block. If there is a conflict, the conflicting transaction will be excluded from this block.
In contrast, Ethereum’s storage status is calculated in real time. Each transaction must wait for the previous transaction to complete before updating the status, so it cannot Performing transaction screening before waiting for packaging limits the possibility of parallel processing.
In the layer2 Rollup chain scenario, to achieve parallel processing, the distance is similar. You can think of Solana's transaction calculation and storage status detection waiting for the POH timestamp as the process of the Rollup chain processing transactions in the Sequener and then batching them to the main network.
Now before layer2 batches transactions, the Sequener will first arrange nonces for the transactions in chronological order, and then batch them to the mainnet in order. How can we achieve multi-threading?
1) Based on the AA account abstract model, multiple transactions can be initiated at the same time from the account status. For example, if two Transfers are executed at the same time, AA intelligent The contract will give it a nonce, which needs to be executed in order. If one is Transfer and the other is Approve, it can be processed in parallel more flexibly without the restriction of nonce. In the AA account model, each account can customize transaction processing logic, and then cooperate with nonce to achieve high concurrency.
2) "Refined" processing of transactions in Sequencer can be performed. For example, when layer2 transactions are submitted to Sequencer, Sequencer can quickly detect These transaction logics are subject to refined sorting and screening. For example, if the same account initiates two Transfers, the latter one must be excluded and wait for the next Batch. If the same account initiates two operations of different nature, then Can be Batched into a block at the same time.
Sounds simple? But this is definitely not the case. Taking the DeFi scenario as an example, Sequencer has two major challenges in achieving refined management of transactions:
1) Real-time analysis Transaction data, understand the smart contract calling method and parameters of the incoming data, take the common Staking in DeFi as an example, a Staking operation involves token transfer, status update, pledge period, and potential reward calculation, etc. If a large number of users input some pledge transactions at the same time, if there are also transactions involving pledge and then transfer, coupled with complex Oralce price factors, etc., if Sequener cannot parse and process it properly, an error in one step may lead to serious accidents.
2) Sequencer must ensure decentralization. Under the premise that the current layer2 Sequener is only a Batch transaction, the rights are too great. If the Sequencer decentralization problem is solved No, doing "refined" Rollup is equivalent to giving the Sequencer more permissions. If Sequencer makes fake transactions, blatantly engages in MEV traps, or even maliciously manipulates Oracle liquidation, etc., it will breed.
Recently, Metis has become popular. On the surface, it only realizes decentralization of Sequencer. On a deeper level, it builds a basic foundation for refined rollup of Sequencer in the future. consensus premise.
Of course, relying on Sequencer to achieve highly refined Rollup transaction aggregation and processing is still just an idea. Fortunately, AA account abstraction, blockchain The overall modular combination and open thinking provide prerequisites for the implementation of this idea.
Above.
Furthermore, as mentioned above, layer2 is becoming increasingly modular as a whole. ZK technology is embedded in the OP Stack framework to achieve privacy expansion; the original Ethereum DA Transform it into a third-party DA such as Celestia to reduce costs; gradually change the tradition of ETH as a gas fee, giving layer2 tokens greater practicality; even layer2 can batch batch transactions and submit them to different VM execution environment, transactions are processed on Solana and Ethereum, etc.
At that time, a new paradigm will emerge. The current layer 2 is no longer just the layer 2 of Ethereum. Solana can also be the layer 2 of Ethereum, and even The definition of layer2 will also be modified.
Bold imagination, now layer2 has become an entry-level "layer1" integrating high concurrent transaction processing capabilities, and the former layer1 of Ethereum and Solana have become A new "layer2" for asset settlement and security protection.
Layer2 has never been a rigid concept. Layer2 platforms have always had the mission of solving large-scale concurrent processing of transactions and attracting incremental user market groups.
If the mission is achieved, under the modular idea, not only the legitimacy of Ethereum layer 1 will be broken, but also the DA data availability of the entire chain, the VM execution layer and even Interoperability communication and interaction will become the infra for layer2 to implement Mass Adoption.
By then, layer2 will no longer be just a supplement to layer1, but will become a powerful comprehensive transaction aggregation and distribution processing platform. Who is whose layer2? ?