A Panorama of the Web3 Parallel Computing Track: The Best Solution for Native Scaling?

1. Parallel Computing: A New Paradigm for Blockchain 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 simultaneously achieve "extreme security, universal participation, and high-speed processing". Regarding the eternal topic of "scalability", the mainstream blockchain scaling solutions in the current market are categorized by paradigm, including:

• Execute enhanced scalability: improve execution capability on-site, such as parallel processing, GPU, multi-core.
• State-Isolation Scaling: horizontal partitioning of state/Shard, such as sharding, UTXO, multiple subnets.
• Off-chain outsourcing scaling: execute outside the chain, such as Rollup, Coprocessor, DA
• Decoupled structure expansion: modular architecture, collaborative operation, such as module chains, shared sorters, Rollup Mesh
• Asynchronous concurrent expansion: Actor model, process isolation, message-driven, such as agents, multi-threaded asynchronous chains.

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

Intra-chain parallelism ), focusing 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 increasingly finer, the parallel intensity increases, the scheduling complexity also rises, and the programming complexity and implementation difficulty become greater.

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

The off-chain asynchronous concurrency model, represented by the Actor intelligent agent system )Agent / Actor Model (, belongs to another parallel computing paradigm, serving as a cross-chain / asynchronous messaging system ) non-block synchronous model (. Each Agent acts as an independently running "intelligent agent process," asynchronously messaging in parallel, event-driven, and without the need for synchronized scheduling. Representative projects include AO, ICP, Cartesi, etc.

The well-known Rollup or sharding scaling solutions belong to system-level concurrency mechanisms and do not pertain to on-chain parallel computing. They achieve scaling by "running multiple chains/execution domains in parallel" rather than enhancing the parallelism within a single block/virtual machine. Such scaling 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 Scalability?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

2. EVM System Parallel Enhancement Chain: Breaking Performance Boundaries through 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 overcome. Meanwhile, EVM and Solidity remain the most developer-friendly and ecosystem-empowered smart contract platforms. Therefore, EVM-based parallel enhancement chains are becoming a key path for balancing ecological compatibility and improving execution performance, and are emerging as an important direction for the next round of scaling evolution. Monad and MegaETH are the most representative projects in this direction, building EVM parallel processing architectures aimed at high concurrency and high throughput scenarios, respectively, from the perspectives of delayed execution and state decomposition.

Analysis of Monad's Parallel Computing Mechanism )

Monad is a high-performance Layer 1 blockchain redesigned for the Ethereum Virtual Machine (EVM), based on the fundamental parallel concept of pipelining (Pipelining), executing asynchronously at the consensus layer (Asynchronous Execution) and optimistically in parallel at the execution layer ###Optimistic Parallel Execution(. In addition, Monad introduces a high-performance BFT protocol )MonadBFT( and a dedicated database system )MonadDB( at the consensus and storage layers, 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 split the execution process of the blockchain into multiple independent stages and handle these stages in parallel, forming a three-dimensional pipeline architecture. Each stage runs on independent threads or cores, achieving concurrent processing across blocks, ultimately improving throughput and reducing latency. These stages include: transaction proposal ) Propose ( consensus reaching ) Consensus ( transaction execution ) Execution ( and block submission ) Commit (.

Asynchronous Execution: Consensus - Execute Asynchronously Decoupled

In traditional blockchains, transaction consensus and execution are typically synchronous processes, and this serial model severely limits performance scalability. Monad achieves asynchronous consensus layer, asynchronous execution layer, and asynchronous storage through "asynchronous execution." This significantly reduces block time ) block time ( and confirmation delays, making the system more resilient, with more streamlined processes and higher resource utilization.

Core Design:

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

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 improving transaction processing speed.

Execution mechanism:

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

Monad has chosen a compatible path: changing EVM rules as little as possible, achieving parallelism during execution by delaying state writes and dynamically detecting conflicts, resembling a performance version of Ethereum. Its maturity facilitates the migration of the EVM ecosystem 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-dc016502755a30d5a95a8134f7586162.webp(

Analysis of the parallel computing mechanism of MegaETH )

Unlike the L1 positioning of Monad, MegaETH positions itself as an EVM-compatible modular high-performance parallel execution layer, which can serve as an independent L1 public chain or as an execution enhancement layer ( Execution Layer ) or modular component on Ethereum. Its core design goal is to isolate and deconstruct account logic, execution environment, and state into independently schedulable minimal units, enabling high concurrent execution and low-latency response capabilities within the chain. The key innovation proposed by MegaETH lies in: Micro-VM architecture + State Dependency DAG ( directed acyclic state dependency graph ) and modular synchronization mechanism, collectively constructing a parallel execution system oriented towards "in-chain threading."

Micro-VM( architecture: account as thread

MegaETH introduces the execution model of "one micro virtual machine per account )Micro-VM###", which "threads" the execution environment and provides the minimal isolation unit for parallel scheduling. These VMs communicate through asynchronous messaging (Asynchronous Messaging), rather than synchronous calls, allowing a large number of VMs to execute independently and store independently, naturally parallel.

State Dependency DAG: Dependency graph-driven scheduling mechanism

MegaETH has built a DAG scheduling system based on account state access relationships. The system maintains a global dependency graph ( Dependency Graph ) in real-time, modeling all account modifications and reads during each transaction as dependencies. 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, encapsulating micro virtual machines at the account level, scheduling transactions through state dependency graphs, and replacing synchronous call stacks with asynchronous messaging mechanisms. It is a parallel computing platform that is redesigned from a "account structure → scheduling architecture → execution flow" full-dimensional perspective, providing a paradigm-level new approach 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 limit is higher, but it is also more difficult to control complexity, resembling a super distributed operating system under the Ethereum philosophy.

The design concepts of Monad and MegaETH are quite different from Sharding ( 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 expanding at the execution layer, achieving performance breakthroughs through extreme parallel execution optimization within a single chain. The two represent vertical strengthening and horizontal expansion in the path of blockchain scaling.

Parallel computing projects such as Monad and MegaETH mainly focus on throughput optimization paths, with the core goal of enhancing on-chain TPS. This is achieved through deferred execution ( Deferred Execution ) and micro-virtual machine ( Micro-VM ) architecture to enable transaction-level or account-level parallel processing. Pharos Network, as a modular, full-stack parallel L1 blockchain network, features a core parallel computing mechanism known as "Rollup Mesh." This architecture supports a multi-virtual machine environment ( 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 Rollup Mesh Parallel Computing Mechanism:

1. Full Lifecycle Asynchronous Pipelining (: Pharos decouples various stages of transactions ) such as consensus, execution, and 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 the flexibility of the system but also improves transaction processing capacity through parallel execution.
3. Special handling network ( SPNs ): SPNs are key components in the Pharos architecture, similar to modular subnetworks, specifically designed for handling specific types of tasks or applications. Through SPNs, Pharos can achieve dynamic resource allocation and parallel processing of tasks, further enhancing the system's scalability and performance.
4. Modular Consensus & Restaking(: Pharos introduces flexible