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

I. Introduction: The "Impossible Triangle" of Blockchain and Scaling Solutions

The "impossible triangle" of blockchain, which includes "security," "decentralization," and "scalability," reveals the essential trade-offs in the design of blockchain systems. 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 on the market are categorized according to paradigms, including:

• Execute enhanced scaling: Improve execution capabilities on-site, such as parallel processing, GPU, and multi-core.
• State Isolation Scaling: Horizontal Sharding of State/Shards, such as Sharding, UTXO, Multi-Subnet
• Off-chain outsourcing expansion: executing outside the chain, such as Rollup, Coprocessor, DA
• Decoupled Structure Expansion: Modular architecture, collaborative operation, such as modular chains, shared sequencers, Rollup Mesh
• Asynchronous concurrent scaling: 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 structures, Actor systems, zk-proof compression, Stateless architecture, etc., covering multiple levels of execution, state, data, and structure, forming a complete scalability system that is "multi-layer collaborative and modular combination". This article focuses on the mainstream scalability method based on parallel computing.

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

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

The out-of-chain asynchronous concurrent model, represented by the Actor agent system (Agent / Actor Model), belongs to another parallel computing paradigm. As a cross-chain/asynchronous messaging system (non-block synchronization model), each Agent operates as an independent "agent process" that utilizes asynchronous messaging in a parallel manner, event-driven, and does not require synchronized scheduling. Notable projects include AO, ICP, Cartesi, etc.

The well-known Rollup or sharding scaling 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. 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 Expansion?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

2. EVM-based Parallel Enhanced Chain: Breaking Performance Boundaries within Compatibility

The development of Ethereum's serial processing architecture has gone through multiple rounds of scalability attempts, including sharding, Rollup, and modular architecture, but the throughput bottleneck at the execution layer has still not achieved a fundamental breakthrough. Meanwhile, EVM and Solidity remain the most developer-friendly and ecologically potent smart contract platforms today. Therefore, EVM-based parallel enhancement chains, which balance ecological compatibility and improved execution performance, are becoming an important direction for the next round of scalability 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, 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, in 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 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, 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 delay, 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 reached.
• Immediately enter the consensus process for the next block after consensus is reached, without waiting for execution to complete.

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 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 by delaying state writes and dynamically detecting conflicts during execution, resembling a performance version of Ethereum. Its maturity facilitates the easy migration of the EVM ecosystem, making it a parallel accelerator in the EVM world.

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

) Analysis of MegaETH's Parallel Computing Mechanism

Differentiating from 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 on Ethereum (Execution Layer) or a modular component. Its core design goal is to 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: Micro-VM architecture + State Dependency DAG (Directed Acyclic Graph of State Dependencies) and modular synchronization mechanisms, collectively building a parallel execution system oriented towards "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 through Asynchronous Messaging, rather than synchronous calls, allowing numerous VMs to execute and store independently, naturally in 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 in real time, modeling which accounts are modified and which are read during each transaction as a dependency relationship. Non-conflicting transactions can be executed in parallel, while transactions with dependencies will be scheduled and sorted in topological order either serially or deferred. The dependency graph ensures state consistency and non-duplicate writes 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 on an account basis, scheduling transactions through a state dependency graph, and replacing synchronous call stacks with an asynchronous messaging mechanism. It is a parallel computing platform 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 restructured path: completely 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 difficult 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 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 a portion of transactions and state, breaking the single-chain limitations for network layer scalability; whereas Monad and MegaETH maintain the integrity of a single chain, only horizontally scaling at the execution layer, optimizing performance through extreme parallel execution within the single chain. The two represent two directions in the blockchain expansion path: vertical reinforcement and horizontal expansion.

Projects like Monad and MegaETH that focus on parallel computing mainly concentrate on optimizing throughput paths, aiming to enhance on-chain TPS as a core goal. 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 a core parallel computing mechanism called "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, storage) and adopts an asynchronous processing method, allowing each stage to proceed 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 capabilities 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 processing of tasks, further enhancing the scalability and performance of the system.
4. Modular Consensus & Restaking: Pharos introduces a flexible consensus mechanism that supports multiple consensus models (such as PBFT, PoS, PoA) and achieves secure sharing and resource integration between the mainnet and SPNs through the Restaking protocol.

In addition, Pharos has restructured its execution model from the underlying storage engine using multi-version Merkle trees, Delta Encoding, Versioned Addressing, and ADS Pushdown technology, launching the native blockchain high-performance storage engine Pharos Store, achieving high throughput and low latency.