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

The "Blockchain Trilemma" - "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 everlasting topic of "scalability", current mainstream blockchain scaling solutions in the market are categorized by paradigms, including:

• Execute enhanced scalability: Improve execution capabilities on the spot, such as parallelism, GPU, and multi-core.
• State-isolated scaling: horizontal partitioning of state / Shard, such as sharding, UTXO, multi-subnet
• Off-chain outsourcing scaling: Execute outside the chain, such as Rollup, Coprocessor, DA
• Decoupled architecture scalability: 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 scaling solutions include: on-chain parallel computation, 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 "multi-layer collaboration, modular combination" complete scaling system. This article focuses on the mainstream scaling method based on parallel computation.

Intra-chain parallelism (, focuses on the parallel execution of transactions/instructions within the block. Based on the parallelism 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 finer, the intensity of parallelism increases, the scheduling complexity also rises, and the programming complexity and implementation difficulty become higher.

• 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 off-chain asynchronous concurrency model, represented by the Actor 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 process", with asynchronous messaging in a parallel manner, event-driven, and without the need for synchronous scheduling. Representative projects include AO, ICP, Cartesi, and others.

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 scaling by "running multiple chains/execution domains in parallel" rather than increasing 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 Parallel Enhanced Chain: Breaking Performance Boundaries in Compatibility

The serial processing architecture of Ethereum has developed to this day, undergoing multiple rounds of expansion attempts such as sharding, Rollup, and modular architecture, but the throughput bottleneck of the execution layer has still not been fundamentally broken. At the same time, EVM and Solidity remain the most developer-friendly and ecologically potent smart contract platforms today. Therefore, the EVM-based parallel enhancement chain, which balances ecological compatibility and improvements in execution performance, is becoming an important direction for the next round of expansion evolution. Monad and MegaETH are the most representative projects in this direction, building an EVM parallel processing architecture 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, at the consensus and storage layers, Monad introduces a high-performance BFT protocol (MonadBFT) and a dedicated database system (MonadDB) to achieve 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 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 improving throughput and reducing latency. These stages include: transaction proposal (Propose), consensus achievement (Consensus), transaction execution (Execution), and block submission (Commit).

Asynchronous Execution: Consensus - Execute Asynchronously Decoupled

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 segmented, 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 the consensus is completed.
• Once the consensus is completed, it immediately enters the consensus process for the next block without waiting for execution to finish.

Optimistic Parallel Execution: Optimistic Parallel Execution

Traditional Ethereum adopts a strict serial model for transaction execution to avoid state conflicts. In contrast, Monad employs 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, 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, making it more like a performance version of Ethereum. Its maturity facilitates easy migration of the EVM ecosystem, serving 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 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 the smallest independently schedulable units to achieve high concurrency execution and low latency response capabilities 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 virtual machine (Micro-VM) per account", which "threads" the execution environment, providing the smallest isolation unit for parallel scheduling. These VMs communicate asynchronously through asynchronous messaging instead of synchronous calls, allowing a large number of VMs to execute independently and store independently, enabling natural parallelism.

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 topological order either serially or deferred. The dependency graph ensures state consistency and non-redundant writes 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 from the "account structure → scheduling architecture → execution process" in all dimensions, 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 an independent VM, 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 concept.

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

The design concepts of Monad and MegaETH differ significantly from sharding: sharding horizontally splits the blockchain into multiple independent sub-chains (shards), with each sub-chain responsible for part of the transactions and states, breaking the limitations of a single chain for network layer scalability; whereas both Monad and MegaETH maintain the integrity of a single chain and only horizontally scale at the execution layer, optimizing performance through extreme parallel execution within the single chain. The two represent two directions in the blockchain scalability path: vertical reinforcement and horizontal expansion.

Projects like Monad and MegaETH focus on throughput optimization paths, with the core goal of enhancing on-chain TPS, achieving transaction-level or account-level parallel processing through Deferred Execution and Micro-VM architecture. Meanwhile, Pharos Network, as a modular, full-stack parallel L1 blockchain network, employs 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, 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 flexibility of the system 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 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 system's scalability and performance.
4. Modular Consensus and Re