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

I. Overview of Parallel Computing Track

The "impossible triangle" of blockchain - "security," "decentralization," and "scalability" - reveals the essential trade-offs in the design of blockchain systems, meaning that it is difficult 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 currently on the market are classified according to paradigms, including:

• Execute enhanced scalability: Improve execution capabilities on the spot, such as parallel processing, GPU, and multi-core.
• State-isolated scaling: horizontal partitioning of state, such as sharding, UTXO, multi-subnet
• Off-chain outsourcing type expansion: executing off-chain, such as Rollup, Coprocessor, DA
• Decoupled structure expansion: modular architecture, collaborative operation, such as module chains, shared sequencers, 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. These cover multiple levels of execution, state, data, and structure, forming a complete scalability system that is "multi-layered collaboration and modular combination." This article focuses on the mainstream scalability method based on parallel computing.

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

• 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 concurrent 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 parallel asynchronous messaging, event-driven, without the need for synchronized scheduling. Notable projects include AO, ICP, Cartesi, etc.

The well-known Rollup or sharding scalability solutions belong to system-level concurrency mechanisms, rather than on-chain parallel computation. They achieve scalability by "running multiple chains/execution domains in parallel" instead of enhancing the parallelism within a single block/virtual machine. This type of scalability solution is not the focus of this article, but we will still use it for comparative analysis of architectural concepts.

![Web3 Parallel Computing Track Overview: The Best Solution for Native Scaling?])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, Rollups, and modular architecture. However, the throughput bottleneck at the execution layer has still not been fundamentally overcome. At the same time, EVM and Solidity remain the most developer-friendly and ecologically potent smart contract platforms today. Therefore, EVM-based parallel-enhanced chains are becoming a key path that balances ecological compatibility with improved execution performance, and they are emerging as an important direction for the next round of scaling evolution. Monad and MegaETH are the most representative projects in this direction, each building an EVM parallel processing architecture aimed at high concurrency and high throughput scenarios, from the perspectives of delayed execution and state decomposition, respectively.

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, enabling 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 decompose 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 cross-block concurrent processing, ultimately enhancing throughput and reducing latency. These stages include: transaction proposal (Propose), consensus reaching (Consensus), transaction execution (Execution), and block submission (Commit).

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 layer, asynchronous execution layer, and asynchronous storage through "asynchronous execution." This significantly reduces block time and confirmation latency, making the system more resilient, with more granular processing flows and higher resource utilization.

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 the consensus is completed.
• 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 adopts an "optimistic parallel execution" strategy, significantly enhancing 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 are accessing the same state (such as 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 delaying state writes and dynamically detecting conflicts, resembling a performance version of Ethereum. Its maturity makes it easy to implement EVM ecosystem migration, acting 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 is positioned as a high-performance parallel execution layer that is EVM-compatible and can serve both as an independent L1 public chain and 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 minimal units, achieving high concurrency execution and low latency response capability within the chain. The key innovations proposed by MegaETH include: Micro-VM architecture + State Dependency DAG (Directed Acyclic Graph of State Dependencies) and a modular synchronization mechanism, collectively building 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 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 and store independently, thus achieving natural parallelism.

State Dependency DAG: A scheduling mechanism driven by dependency graphs

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 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-threaded state machine model by implementing micro virtual machine encapsulation on an account basis. It utilizes a state dependency graph for transaction scheduling and replaces the synchronous call stack 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 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 upper limit 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 Panorama: The Best Solution for Native Expansion?])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 sub-chains (shards), with each sub-chain responsible for a portion of transactions and states, breaking the single-chain limitations for network layer scalability; whereas Monad and MegaETH maintain the integrity of the single chain, only horizontally scaling at the execution layer, optimizing for extreme parallel execution within the single chain to break through performance limits. The two represent two directions in the blockchain scaling path: vertical enhancement and horizontal expansion.

Parallel computing projects such as Monad and MegaETH primarily focus on throughput optimization paths, aiming to enhance on-chain TPS as the core objective. 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 multiple virtual machine environments (EVM and Wasm) through the collaborative operation of the mainnet and Special Processing Networks (SPNs), integrating 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 employs an asynchronous processing approach, 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 capability through parallel execution.
3. Special Processing Networks (SPNs): SPNs are key components in the Pharos architecture, similar to modular sub-networks specifically designed to handle particular 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 achieves the connection between the mainnet and SPN through the restaking protocol.