A Comprehensive Overview of the Web3 Parallel Computing Track: The Best Solution for Native Scalability?

1. Introduction: The Eternal Topic of Blockchain Scalability

The "Blockchain Trilemma" of security, decentralization, and scalability reveals the essential trade-offs in the design of blockchain systems, meaning that blockchain projects find it difficult to achieve "ultimate security, universal participation, and high-speed processing" simultaneously. Regarding the eternal topic of "scalability," the mainstream blockchain expansion solutions currently on the market can be categorized according to different paradigms, including:

• Execute enhanced scalability: improve execution capabilities on-site, such as parallel processing, GPU, multi-core.
• State-isolated scaling: horizontal partitioning of state/Shard, such as sharding, UTXO, multi-subnet
• Off-chain outsourcing type scaling: execute off-chain, for example Rollup, Coprocessor, DA
• Decoupled structure expansion: modular architecture, collaborative operation, such as module chains, shared sequencers, Rollup Mesh
• Asynchronous Concurrent Scaling: Actor model, process isolation, message-driven, such as agents, multithreaded asynchronous chain

Blockchain scaling 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, forming a "multi-layer collaboration and modular combination" complete scaling system. 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 parallelism mechanism, its expansion methods can be divided into five major categories, each representing different performance pursuits, development models, and architectural philosophies, with increasingly finer parallel granularity, higher parallel intensity, greater scheduling complexity, and increasing programming complexity and implementation difficulty.

• Account-level parallelism: represents the Solana project
• Object-level parallelism: represents the Sui project
• Transaction-level: Represents 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 agent system (Agent / Actor Model), belongs to another parallel computing paradigm, serving as a cross-chain/asynchronous messaging system (non-block synchronization model). Each Agent operates as an independent "agent process," utilizing asynchronous messaging and event-driven methods in parallel without synchronous scheduling. Representative projects include AO, ICP, Cartesi, and others.

The well-known Rollup or sharding scaling solutions are system-level concurrency mechanisms and do not fall under on-chain parallel computation. They achieve scalability by "running multiple chains/execution domains in parallel" rather than increasing the parallelism within a single block/virtual machine. These types of 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 Overview: The Best Solution for Native Scalability?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

2. EVM System Parallel Enhanced 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 in the execution layer has still not achieved a fundamental breakthrough. Meanwhile, 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 improvements in execution performance, are becoming 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, with asynchronous execution at the consensus layer and optimistic parallel execution at the execution layer. Additionally, 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 basic concept of parallel execution in Monads. Its core idea is to split the execution process of the blockchain into multiple independent stages and process these stages in parallel, forming a three-dimensional pipeline architecture. Each stage runs on independent threads or cores to achieve concurrent processing across blocks, ultimately enhancing throughput and reducing latency. These stages include: Transaction Proposal (Propose), Consensus Achievement (Consensus), Transaction Execution (Execution), and Block Commitment (Commit).

Asynchronous Execution: Consensus - Execution 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 layer, asynchronous execution layer, 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, not executing contract logic.
• The execution process (execution layer) is triggered asynchronously after consensus is reached.
• Immediately enter the consensus process for the next block after consensus is reached, 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 employs an "optimistic parallel execution" strategy, significantly increasing transaction processing speed.

Implementation mechanism:

• Monad will optimistically execute all transactions in parallel, assuming that there are no state conflicts between most transactions.
• Run a "Conflict Detector (Conflict Detector###)" to monitor whether transactions access the same state (e.g., 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: minimizing changes to EVM rules, achieving parallelism during execution by delaying state writes and dynamically detecting conflicts, resembling a performance-enhanced Ethereum. It has a good level of maturity, making it easier to realize EVM ecosystem migration, serving as a parallel accelerator in the EVM world.

![Web3 Parallel Computing Track Panorama: The Best Solution for Native Expansion?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.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 compatible with EVM, which can serve as an independent L1 public chain or as an execution enhancement layer or modular component on Ethereum. Its core design goal is to isolate and deconstruct account logic, execution environment, and state into independently schedulable minimum units to achieve high concurrency execution and low latency response capability within the chain. The key innovations proposed by MegaETH are: Micro-VM architecture + State Dependency DAG (Directed Acyclic Graph of State Dependencies) and a modular synchronization mechanism, together constructing a parallel execution system oriented towards "in-chain threading."

Micro-VM Architecture: Account as Thread

MegaETH introduces an execution model of "one micro virtual machine (Micro-VM) per account," which "threads" the execution environment, providing the minimum isolation unit for parallel scheduling. These VMs communicate via asynchronous messaging, rather than synchronous calls, allowing a large number of VMs to execute and store independently, inherently parallel.

State Dependency DAG: Dependency Graph Driven Scheduling Mechanism

MegaETH has built a DAG scheduling system based on account state access relationships, which maintains a global dependency graph in real-time. Each transaction modifies certain accounts and reads from others, all modeled as dependency relationships. Non-conflicting transactions can be executed in parallel, while transactions with dependencies will be scheduled in serial or deferred according to topological order. The dependency graph ensures state consistency and non-repeated writing during the parallel execution process.

Asynchronous Execution and Callback Mechanism

B

In summary, MegaETH breaks the traditional EVM single-threaded 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-shifting new approach for building the next generation of high-performance on-chain systems.

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

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

The design philosophies 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 a portion of transactions and states, breaking the limitations of a single chain for network layer scalability; while both Monad and MegaETH maintain the integrity of a single chain, they horizontally scale only at the execution layer, achieving performance breakthroughs through extreme parallel execution within the single chain. The two represent vertical reinforcement and horizontal expansion in the blockchain scalability path.

Projects like Monad and MegaETH focus primarily on throughput optimization paths, aiming to enhance on-chain TPS. They achieve transaction-level or account-level parallel processing through Deferred Execution and Micro-VM architecture. Pharos Network, as a modular and full-stack parallel L1 blockchain network, has a core parallel computing mechanism called "Rollup Mesh." This architecture supports multiple 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, and storage) and employs 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 system's flexibility but also improves transaction processing capacity through parallel execution.
3. Special Processing Networks (SPNs): SPNs are key components in the Pharos architecture, similar to modular sub-networks, specifically designed for handling 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 & Restaking: Pharos introduces a flexible consensus mechanism that supports various consensus models (such as PBFT, PoS, PoA) and achieves secure sharing and resource integration between the mainnet and SPNs through the Restaking protocol.

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

In addition, Pharos uses multi-version Merkle trees, Delta Encoding, and versions