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

1. Introduction

The "Blockchain Trilemma" reveals the essential trade-offs in the design of blockchain systems, namely the difficulty for blockchain projects to achieve "ultimate security, universal participation, and high-speed processing" simultaneously. Regarding the eternal topic of "scalability," the mainstream blockchain scaling solutions available in the market are categorized according to paradigms, including:

• Execute enhanced scalability: Improve execution capabilities on-site, such as parallel processing, GPU, and multi-core.
• State-isolation scaling: horizontal partitioning of state / Shard, such as sharding, UTXO, multi-subnet
• Off-chain outsourcing scaling: executing outside the chain, such as Rollup, Coprocessor, DA
• Decoupled Architecture 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, multithreaded asynchronous chains.

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 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 scalability can be divided into five 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 project Solana
• Object-level parallelism: represents the Sui project
• 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 paradigm of parallel computing. As a cross-chain / asynchronous messaging system (non-block synchronization model), each Agent operates as an independent "intelligent agent process," using asynchronous messaging in a parallel manner, driven by events and requiring no synchronized scheduling. Representative projects include AO, ICP, Cartesi, etc.

The Rollup or sharding scalability solutions that we are familiar with belong to system-level concurrency mechanisms and do not fall under on-chain parallel computing. They achieve scalability by "running multiple chains/execution environments in parallel" rather than enhancing the parallelism within a single block/virtual machine. Such scalability solutions are not the focus of this discussion, 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 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 of the execution layer has still not been fundamentally broken. Meanwhile, EVM and Solidity remain the most developer-friendly and ecosystem-empowered smart contract platforms today. Therefore, EVM-based parallel enhancement chains, which balance ecosystem compatibility and execution performance improvement, are becoming an important direction for the new 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, starting from 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, at the consensus and storage layers, Monad introduces a high-performance BFT protocol (MonadBFT) and a specialized database system (MonadDB) to achieve end-to-end optimization.

Pipelining: Multi-stage pipeline parallel execution mechanism

Pipelining is the fundamental concept of Monad parallel execution. Its core idea is to split the execution process of the blockchain into multiple independent stages and to process these stages in parallel, forming a three-dimensional pipeline architecture. Each stage runs on independent threads or cores, achieving 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, asynchronous execution, and asynchronous storage through "asynchronous execution." This significantly reduces block time and confirmation delays, making the system more resilient, processing flows more granular, and resource utilization more efficient.

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 achieved.
• Immediately enter the consensus process for the next block after consensus is completed, without waiting for execution to finish.

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 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)" simultaneously 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 chooses a compatible path: minimizing changes to EVM rules, achieving parallelism by delaying state writes and dynamically detecting conflicts during execution, resembling a performance version of Ethereum. Its good maturity makes EVM ecological migration easier, serving as a parallel accelerator in the EVM world.

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

Analysis of the parallel computing mechanism of MegaETH (

Differentiating from the L1 positioning of Monad, MegaETH is positioned 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 on Ethereum (Execution Layer) or as a modular component. Its core design goal is to deconstruct the account logic, execution environment, and state into independently schedulable minimal units, in order to achieve high concurrent execution and low latency response capability within the chain. The key innovation proposed by MegaETH lies in: Micro-VM architecture + State Dependency DAG (Directed Acyclic Graph of State Dependencies) and a modular synchronization mechanism, collectively constructing a parallel execution system aimed at "in-chain threading".

Micro-VM Architecture: Account as Thread

MegaETH introduces an execution model of "one Micro-VM per account", which "threads" the execution environment, providing the smallest unit of isolation 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, 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 models which accounts are modified and which accounts are read as dependency relationships. Non-conflicting transactions can be executed in parallel directly, while transactions with dependencies will be scheduled and sorted in serial or delayed 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-threaded state machine model, encapsulating micro virtual machines at the account level, scheduling transactions through state dependency graphs, and replacing synchronous call stacks with an asynchronous messaging mechanism. It is a parallel computing platform redesigned from the "account structure → scheduling architecture → execution process" in all dimensions, providing paradigm-level new ideas for building the next generation of high-performance on-chain systems.

MegaETH has chosen a reconstruction path: completely 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-9c4a4c4309574e45f679b2585d42ea16.webp###

Monad and MegaETH have significantly different design philosophies compared to sharding: sharding horizontally divides the blockchain into multiple independent subchains (shards), with each subchain responsible for a portion of transactions and state, breaking the single-chain limitation for network-layer scalability; whereas Monad and MegaETH maintain single-chain integrity, only horizontally scaling at the execution layer, achieving performance breakthroughs through extreme parallel execution optimization within the single chain. The two represent the vertical reinforcement and horizontal expansion directions in the blockchain scalability paths.

Projects like Monad and MegaETH focus primarily on throughput optimization paths, aiming to enhance on-chain TPS as the core objective, achieving 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 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 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 adopts an asynchronous processing method, allowing each stage to be conducted 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 capability through parallel execution.
3. Special Processing Networks (SPNs): SPNs are key components in the Pharos architecture, akin to modular sub-networks 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 & Restaking: Pharos introduces a flexible consensus mechanism that supports multiple consensus models (such as PBFT, PoS, PoA), and through restaking.