Modded Layer 2: Is the Endgame of Modularity a New "Layer 1" Gateway?
TechFlow Selected TechFlow Selected
Modded Layer 2: Is the Endgame of Modularity a New "Layer 1" Gateway?
Layer 2 is no longer just Ethereum's Layer 2.
Navigating Web3 tides with focused insightsAuthor: Haotian
A new narrative of "parallel EVM" has emerged in the market, which is particularly interesting for Layer2, enabling a refined Rollup paradigm—so to speak, it could even lead to a wild scenario where Solana becomes a new Layer2 of Ethereum.
In my view, parallel EVM is merely the visible manifestation of Rollup's high degree of modularity—an indication that after DA has been taken over by third parties, the VM execution layer is now being compromised as well. The concept of Layer2 will be redefined in the future. Why? Let’s analyze this from an educational perspective:
To understand this topic, we must first clarify the single-threaded execution model of the "EVM".
This model dictates that transactions must be processed and confirmed sequentially, one after another, directly affecting transaction processing speed, block production time, and throughput. It's also the main reason why Ethereum's mainnet suffers from high gas fees and network congestion. Moreover, the design of a single-threaded system stems partly from historical limitations.
Since transactions on Ethereum are validated and executed by distributed independent nodes, all nodes must maintain consistent state data—such as balances and smart contract code—while ensuring no double-spending of the same asset occurs.
This necessitates sequential transaction processing. If transactions were handled in parallel, it could result in data synchronization errors between nodes and, more critically, severe double-spending issues.
Put simply: imagine a bank with only one service window. Customers must queue in order to withdraw money—whether depositing, withdrawing, or applying for loans. Only after one customer finishes can the next begin. The advantage is that every operation in the bank's account system is precisely recorded, but customers face long wait times.
If the bank opens multiple service windows allowing customers to conduct different operations simultaneously, two windows might attempt to deduct funds from the same account at once. If inter-window account reconciliation isn't timely, double-spending could occur. Clearly, this increases efficiency, but complex accounting logic puts pressure on the financial system.
In a Layer1 standalone chain scenario, supporting parallel processing at the base layer resolves these issues. For example, Solana separates computation from state storage. When its VM receives multiple user transactions, nodes sort them and use an independent storage system to check for state conflicts. Transactions without conflicts are grouped into a single block; conflicting ones are excluded from that batch.
By contrast, Ethereum computes its state storage in real-time—each transaction must wait for the previous one to complete before updating the state. Thus, Ethereum cannot perform transaction filtering prior to batching, limiting its ability to process transactions in parallel.
In the context of Layer2 Rollup chains, achieving parallel processing follows a similar principle. You can think of Solana’s transaction computation and state conflict detection during POH timestamp waiting as analogous to how a Rollup chain processes transactions via a Sequencer before batching them to the mainnet.
Currently, before batching, Layer2 Sequencers assign nonces to transactions in chronological order and then submit them sequentially to the mainnet. So how can multi-threading be achieved?
1) By leveraging the Account Abstraction (AA) model, multiple transactions can be initiated simultaneously from an account state perspective. For instance, if two Transfer operations are executed concurrently, the AA smart contract assigns nonces requiring sequential execution. However, if one is a Transfer and the other an Approve, they can bypass nonce constraints and be processed flexibly in parallel. In the AA model, each account can customize transaction handling logic, enabling high concurrency when combined with nonce management.
2) Transactions within the Sequencer can undergo “fine-grained” processing. When Layer2 transactions are submitted to the Sequencer, it can quickly analyze their logic and perform precise sorting and screening. For example, if a single account initiates two Transfers, the second should be excluded and queued for the next batch. But if the account initiates two different types of operations, both can be batched into the same block.
Sounds simple? In reality, it’s far from it. Take DeFi scenarios as an example—there are two major challenges for Sequencers aiming to achieve fine-grained transaction management:
1) Real-time parsing of transaction data is required—to understand the invoked smart contract methods and parameters. Take Staking, a common DeFi operation: it involves token transfers, state updates, staking duration, and potential reward calculations. If many users simultaneously submit staking transactions—including those followed by Transfer actions—and factor in complex Oracle price feeds, any failure by the Sequencer to correctly parse and handle these could trigger serious incidents.
2) The Sequencer must remain decentralized. Even under current conditions—where the Sequencer merely batches transactions—it already holds excessive power. Without solving the decentralization issue, introducing "fine-grained" Rollups would grant the Sequencer even greater authority. Malicious actors could inject fake transactions, openly engage in MEV sandwich attacks, or manipulate Oracle-based liquidations.
Recently, Metis gained popularity—not just because its Sequencer achieved decentralization, but more importantly, because it laid the foundational consensus groundwork for future fine-grained Rollup implementations.
Of course, achieving highly refined Rollup transaction aggregation and processing through the Sequencer remains theoretical—for now. Fortunately, Account Abstraction and the broader modular composability philosophy in blockchain provide the prerequisites needed to make this vision a reality.
Above.
Moreover, as previously mentioned, Layer2 is increasingly becoming modular: embedding ZK technology into the OP Stack framework for privacy scaling; replacing Ethereum’s native DA with third-party solutions like Celestia to reduce costs; moving beyond ETH as the sole gas token, thereby enhancing the utility of Layer2-native tokens; and even allowing Layer2s to batch transactions and submit them to different VM execution environments—processing some transactions on Solana and others on Ethereum, for example.
Eventually, a completely new paradigm will emerge—current Layer2s won’t just be Ethereum’s Layer2s anymore. Solana could become Ethereum’s Layer2, and the very definition of Layer2 will be radically transformed.
Imagine boldly: today’s Layer2 evolves into a gateway-level "Layer1" with high-concurrency transaction processing capabilities, while former Layer1s like Ethereum and Solana become new "Layer2s" focused on asset settlement and security assurance.
Layer2 has never been a rigid concept. Layer2 platforms continue to carry the mission of solving large-scale concurrent transaction processing and attracting new user markets.
Should this mission succeed, under the modular paradigm, not only will Ethereum’s Layer1 primacy be challenged, but entire-chain data availability (DA), VM execution layers, and even interoperability communication infrastructures will become foundational components enabling Mass Adoption across Layer2 ecosystems.
At that point, Layer2 will no longer merely supplement Layer1—it will become a powerful, comprehensive platform for transaction aggregation and distribution. Then again, who exactly will be whose Layer2?
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Haotian | CryptoInsight
