The Panorama of Web3 Parallel Computing Track: The Best Solution for Native Scalability?

The "impossible triangle" of blockchain—"security," "decentralization," and "scalability"—reveals the essential trade-offs in the design of blockchain systems, meaning that it is challenging for blockchain projects to achieve "ultimate security, universal participation, and high-speed processing" simultaneously. Regarding the eternal topic of "scalability," current mainstream blockchain scaling solutions on the market are categorized according to paradigms, including:

• Execute enhanced scaling: Improve execution capabilities on the spot, such as parallel processing, GPU, and multi-core.
• State-isolated scaling: horizontal partitioning of state / Shard, such as sharding, UTXO, multi-subnet
• Off-chain outsourcing expansion: execute outside the chain, for example Rollup, Coprocessor, DA
• Decoupled architecture expansion: modular architecture, collaborative operation, such as module chain, shared sequencer, Rollup Mesh
• Asynchronous concurrent scaling: Actor model, process isolation, message-driven, such as agents, multithreaded asynchronous chains

Blockchain scaling solutions include: on-chain parallel computing, Rollup, sharding, DA modules, modular structures, Actor systems, zk-proof compression, Stateless architecture, etc., covering multiple levels of execution, state, data, and structure, forming a complete scaling system of "multi-layer collaboration and modular combination." This article focuses on the mainstream scaling method based on parallel computing.

Intra-chain parallelism (, focuses on the parallel execution of transactions/instructions within the block. According to the parallel mechanism, its scaling methods can be divided into five major categories, each representing different performance pursuits, development models, and architectural philosophies. The parallel granularity becomes finer, the parallel intensity increases, the scheduling complexity also rises, and the programming complexity and implementation difficulty become higher.

• Account-level parallelism: Represents the project Solana
• Object-level parallelism: Represents the project Sui
• Transaction-level: Represents the projects Monad, Aptos
• Call-level / MicroVM parallelism: Represents the project MegaETH
• Instruction-level parallelism: Represents the project GatlingX

The off-chain asynchronous concurrency model, represented by the Actor system (Agent / Actor Model), belongs to another paradigm of parallel computing. As a cross-chain / asynchronous messaging system (non-block synchronization model), each Agent operates as an independently running "intelligent agent process," utilizing asynchronous messaging in a parallel manner, event-driven, and without the need for synchronized scheduling. Representative projects include AO, ICP, Cartesi, and others.

The familiar Rollup or sharding scalability solutions belong to system-level concurrency mechanisms and do not fall under on-chain parallel computing. They achieve scalability by "running multiple chains/execution domains in parallel" rather than enhancing the parallelism within a single block/virtual machine. These scalability solutions are not the focus of this article, but we will still use them for comparative analysis of architectural concepts.

![Web3 Parallel Computing Track Panorama: The Best Solution for Native Scaling?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

) 2. EVM System Parallel Enhancement Chain: Breaking Performance Boundaries in Compatibility

The development of Ethereum's serial processing architecture has gone through multiple rounds of scaling attempts, including sharding, Rollup, and modular architecture, but the throughput bottleneck at the execution layer has still not been fundamentally broken through. At the same time, EVM and Solidity remain the smart contract platforms with the strongest developer base and ecological potential. Therefore, EVM-based parallel enhancement chains, which balance ecological compatibility and the improvement of execution performance, are becoming an important direction for the new round of scaling evolution. Monad and MegaETH are the most representative projects in this direction, building an EVM parallel processing architecture aimed at high concurrency and high throughput scenarios, respectively, from the perspectives of delayed execution and state decomposition.

Analyzing the Parallel Computing Mechanism of Monad

Monad is a high-performance Layer 1 blockchain redesigned for the Ethereum Virtual Machine (EVM), based on the fundamental parallel concept of pipelining, with asynchronous execution at the consensus layer and optimistic parallel execution at the execution layer. Additionally, at the consensus and storage layers, Monad introduces a high-performance BFT protocol (MonadBFT) and a dedicated database system (MonadDB), achieving end-to-end optimization.

Pipelining: Multi-stage Pipeline Parallel Execution Mechanism

Pipelining is the fundamental concept of parallel execution in Monads. Its core idea is to break down the execution flow of the blockchain into multiple independent stages and process these stages in parallel, forming a multi-dimensional pipeline architecture. Each stage runs on independent threads or cores, enabling concurrent processing across blocks, ultimately achieving improved throughput and reduced latency. These stages include: transaction proposal (Propose), consensus reaching (Consensus), transaction execution (Execution), and block submission (Commit).

![Web3 Parallel Computing Track Overview: The Best Solution for Native Scaling?]###https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(

Asynchronous Execution: Consensus - Asynchronous Decoupling

In traditional blockchains, transaction consensus and execution are usually synchronous processes, and this serial model severely limits performance scalability. Monad achieves asynchronous consensus, asynchronous execution, and asynchronous storage through "asynchronous execution." This significantly reduces block time and confirmation delay, making the system more resilient, processing flows more granular, and resource utilization higher.

Core Design:

• The consensus process (consensus layer) is only responsible for ordering transactions and does not execute contract logic.
• The execution process (execution layer) is triggered asynchronously after consensus is reached.
• After the consensus is reached, immediately enter the consensus process for the next block without waiting for execution to complete.

Optimistic Parallel Execution: Optimistic Parallel Execution

Traditional Ethereum uses a strict serial model for transaction execution to avoid state conflicts. In contrast, Monad adopts an "optimistic parallel execution" strategy, significantly enhancing transaction processing speed.

Implementation mechanism:

• Monad will optimistically execute all transactions in parallel, assuming there are no state conflicts among most transactions.
• Run a "Conflict Detector (Conflict Detector))" simultaneously to monitor whether transactions access the same state (e.g., read/write conflicts).
• If a conflict is detected, the conflicting transactions will be serialized and re-executed to ensure state correctness.

Monad has chosen a compatible path: minimizing changes to EVM rules, achieving parallelism during execution by deferring state writes and dynamically detecting conflicts, making it more like a performance version of Ethereum. With good maturity, it is easy to implement EVM ecosystem migration and serves as a parallel accelerator in the EVM world.

![Web3 Parallel Computing Track Panorama: The Best Solution for Native Scaling?])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(

)# Analysis of MegaETH's Parallel Computing Mechanism

Unlike the L1 positioning of Monad, MegaETH is positioned as a modular high-performance parallel execution layer that is EVM compatible. It can function both as an independent L1 public chain and as an execution enhancement layer on Ethereum or as a modular component. Its core design goal is to isolate and deconstruct account logic, execution environment, and state into independently schedulable minimal units to achieve high concurrent execution and low latency response capabilities within the chain. The key innovation proposed by MegaETH lies in the Micro-VM architecture + State Dependency DAG (Directed Acyclic Graph of State Dependencies) and a modular synchronization mechanism, which together construct a parallel execution system aimed at "in-chain threading".

Micro-VM Architecture: Account is Thread

MegaETH introduces an execution model of "one micro virtual machine (Micro-VM) per account", threading the execution environment, providing the smallest isolation unit for parallel scheduling. These VMs communicate with each other through asynchronous messaging, rather than synchronous calls, allowing a large number of VMs to execute independently and store independently, naturally parallel.

State Dependency DAG: A Scheduling Mechanism Driven by Dependency Graphs

MegaETH has built a DAG scheduling system based on account state access relationships. The system maintains a global Dependency Graph in real-time, modeling all transactions that modify or read which accounts into dependency relationships. Non-conflicting transactions can be executed in parallel, while transactions with dependencies will be scheduled in a serial or delayed manner according to topological order. The dependency graph ensures state consistency and non-repetitive writing during the parallel execution process.

Asynchronous Execution and Callback Mechanism

B

In summary, MegaETH breaks the traditional EVM single-thread state machine model by implementing micro virtual machine encapsulation at the account level, scheduling transactions through a state dependency graph, and replacing synchronous call stacks with an asynchronous messaging mechanism. It is a parallel computing platform that is redesigned in all dimensions from "account structure → scheduling architecture → execution process," providing a paradigm-level new idea for building the next generation of high-performance on-chain systems.

MegaETH has chosen a reconstruction path: thoroughly abstracting accounts and contracts into independent VMs, releasing extreme parallel potential through asynchronous execution scheduling. Theoretically, MegaETH's parallel ceiling is higher, but it is also more challenging to control complexity, resembling a super distributed operating system under the Ethereum philosophy.

![Web3 Parallel Computing Track Overview: The Best Solution for Native Scaling?]###https://img-cdn.gateio.im/webp-social/moments-562daa8ae6acba834ef937bf88a742f0.webp(

The design concepts of Monad and MegaETH are quite different from sharding: sharding horizontally divides the blockchain into multiple independent sub-chains (shards), with each sub-chain responsible for part of the transactions and state, breaking the limitations of a single chain for network layer expansion; whereas both Monad and MegaETH maintain the integrity of a single chain, only horizontally scaling at the execution layer, achieving performance breakthroughs through extreme parallel execution optimization within a single chain. The two represent two directions in the blockchain expansion path: vertical enhancement and horizontal scaling.

Parallel computing projects such as Monad and MegaETH mainly focus on throughput optimization paths, with the core goal of enhancing on-chain TPS. They achieve transaction-level or account-level parallel processing through Deferred Execution and Micro-VM architecture. Pharos Network, as a modular, full-stack parallel L1 blockchain network, has its core parallel computing mechanism known as "Rollup Mesh." This architecture supports multi-virtual machine environments (EVM and Wasm) through the collaborative work of the mainnet and Special Processing Networks (SPNs), and integrates advanced technologies such as Zero-Knowledge Proofs (ZK) and Trusted Execution Environments (TEE).

Analysis of the Rollup Mesh Parallel Computing Mechanism:

1. Full Lifecycle Asynchronous Pipelining: Pharos decouples the various stages of a transaction (such as consensus, execution, storage) and adopts an asynchronous processing method, allowing each stage to operate independently and in parallel, thereby improving overall processing efficiency.
2. Dual VM Parallel Execution: Pharos supports two virtual machine environments, EVM and WASM, allowing developers to choose the appropriate execution environment based on their needs. This dual VM architecture not only enhances system flexibility but also improves transaction processing capability through parallel execution.
3. Special Processing Networks (SPNs): SPNs are key components in the Pharos architecture, similar to modular subnetworks, specifically designed to handle certain types of tasks or applications. Through SPNs, Pharos can achieve dynamic resource allocation and parallel task processing, further enhancing the system's scalability and performance.
4. Modular Consensus and Re-staking Mechanism (Mo