Note: The original text comes from @tmel0211 who posted a long tweet.
A new narrative of "parallel EVM" has emerged in the market, which is very interesting for layer2. It can realize a new paradigm of "refined" Rollup. To exaggerate a little, it can achieve the magical effect of Solana becoming the new layer2 of Ethereum.
In my opinion, parallel EVM is just a highly "modularized" Rollup. It is the fall of the VM execution layer after DA was attacked by a third party. In the future, layer2 will be redefined. Why? Next, 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 by one in order, which directly affects the transaction processing speed, block time, and transaction throughput, and is the main reason for the high gas and congestion of the Ethereum main network. In addition, the design of single thread 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 consistent between different nodes. At the same time, it is also necessary to ensure that there is no possibility of double payment of the same asset.
This means that transactions have to be queued and processed in order. If parallel transactions occur, data synchronization errors between nodes may occur, and more importantly, serious double-spending transactions may occur.
Popular explanation: The bank has only one service window, and customers have to queue up in order to withdraw money. Whether it is a deposit, withdrawal, or loan, one customer can start the next one after completing the business. The advantage is that every operation of the bank's account system will be accurately recorded, but the customer's waiting time will be longer;
If a bank opens multiple service windows, customers can choose windows to handle different businesses. There will be two windows trying to deduct money from the same account at the same time. If the account system between the windows is not reconciled in time, double spending will occur. Obviously, this significantly improves efficiency, but the complex accounting logic will bring pressure to the accounting system.
In the layer 1 independent chain scenario, if the underlying chain supports parallel processing, the problem will be solved. Since Solana separates computing and storage status, after its VM receives multiple transactions from users, the node will sort these transactions and then call the independent storage system status data to detect whether there are status conflicts in these transactions. If there is no conflict, the transactions will be packaged into a block. If there is a conflict, the conflicting transactions will be excluded from this block.
In contrast, Ethereum's storage status is calculated in real time, and each transaction must wait for the previous transaction to be completed before updating the status. Therefore, it is impossible to screen transactions before waiting for packaging, which limits the possibility of parallel processing.
In the layer2 Rollup chain scenario, parallel processing is also similar. You can think of Solana's transaction calculation and storage status detection while waiting for the POH timestamp as the process of the Rollup chain processing transactions in Sequener and then batching to the main network.
Now before batching transactions, layer2's Sequener will first sort the transactions by nonce in chronological order, and then batch them to the main network in order. How can multi-threading be achieved?
1) Based on the AA account abstract model, multiple transactions can be initiated simultaneously from the account status. For example, if two transfers are executed at the same time, the AA smart contract will assign nonce to them and they need to be executed in sequence. If one is a transfer and the other is an approval, they can be processed in parallel more flexibly without being restricted by nonce. In the AA account model, each account can customize the transaction processing logic, and then cooperate with nonce to achieve high concurrency.
2) The transactions in the Sequencer can be processed in a "refined" manner. For example, when layer2 transactions are submitted to the Sequencer, the Sequencer can quickly detect the transaction logic and perform 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 natures, they can be batched into one block at the same time.
Sounds simple? But it is not. Taking DeFi as an example, there are two major challenges for Sequencer to achieve refined transaction management:
1) To parse transaction data in real time and understand the smart contract calling method and parameters of the incoming data, take DeFi's common Staking as an example. A Staking operation involves token transfer, status update, pledge period, and potential reward calculation. If a large number of users pass in some pledge transactions at the same time, if there are also transactions that are transferred after being postponed, plus complex Oracle 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. The current layer 2 Sequener only has Batch transactions, and its power is already too great. If the Sequencer decentralization problem cannot be solved, then making a "fine" Rollup is equivalent to giving the Sequencer more authority. If the Sequencer does evil in the middle, inserts fake transactions, blatantly engages in MEV clamps, or even maliciously manipulates Oracle liquidation, etc., it will breed.
Recently, Metis has been popular. On the surface, it only realizes the decentralization of Sequencer, but in depth, it has built a basic consensus premise for future Sequencer to make refined Rollups.
Of course, relying on Sequencer to achieve highly refined Rollup transaction aggregation and processing is still just a concept. Fortunately, AA account abstraction and the overall modular combination and open thinking of the blockchain provide the prerequisites for the implementation of this concept.
that's all.
Moreover, as mentioned earlier, layer2 is becoming more and more modular as a whole. ZK technology is embedded in the OP Stack framework to achieve privacy expansion; the original Ethereum DA is converted into a third-party DA such as Celestia to reduce costs; the tradition of ETH as a gas fee is gradually changed, giving layer2 tokens greater practicality; even, layer2 can batch transactions and submit them to different VM execution environments, and divide transactions into Solana and Ethereum for processing, etc.
By then, a completely new paradigm will emerge. The current layer2 is no longer just Ethereum’s layer2. Solana can also be Ethereum’s layer2, and even the definition of layer2 will be changed.
A bold assumption is that layer2 has now become an entry-level "layer1" that integrates high-concurrency transaction processing capabilities, while Ethereum, Solana and other former layer1s have become new "layer2s" for asset settlement and security assurance.
Layer2 has never been a rigid concept. The mission of layer2 platforms to solve large-scale concurrent transaction processing and attract incremental user market groups has always existed.
If the mission is achieved, under the modular idea, not only will the legitimacy of Ethereum layer 1 be broken, but the DA data availability, VM execution layer and even interoperability communication interaction of the entire chain will become the infra for layer 2 to achieve 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. So, who is whose layer2?