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

I. Parallel Computing: The Key Path to Blockchain Scalability

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 "ultimate security, universal participation, and high-speed processing". Regarding the eternal topic of "scalability", the mainstream blockchain scaling solutions currently available in the market can be categorized according to paradigms, including:

• Execute enhanced scalability: Improve execution capabilities on the spot, such as parallelism, GPU, and multi-core.
• State-isolated scaling: horizontal splitting of state/Shard, such as sharding, UTXO, multi-subnet
• Off-chain outsourcing scalability: executing outside the chain, such as Rollup, Coprocessor, DA
• Decoupled architecture for scalability: modular architecture, collaborative operation, such as modular chains, shared sorters, 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 architecture, Actor systems, zk-proof compression, Stateless architecture, etc., covering multiple levels of execution, state, data, and structure, forming a "multi-layered collaboration and modular combination" complete scalability system. This article focuses on introducing 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, its scalability can be divided into five major categories, each representing different performance pursuits, development models, and architectural philosophies. The parallel granularity becomes finer, the parallel intensity increases, the scheduling complexity also rises, and the programming complexity and implementation difficulty grow higher.

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

The off-chain asynchronous concurrent model, represented by the Actor agent system )Agent / Actor Model(, belongs to another parallel computing paradigm, functioning as a cross-chain/asynchronous messaging system ) non-block synchronous model(. Each Agent operates as an independently running "agent process" that asynchronously handles messages in a parallel manner, driven by events and requiring no synchronous scheduling. Representative projects include AO, ICP, Cartesi, etc.

The well-known Rollup or sharding expansion solutions belong to system-level concurrency mechanisms and do not fall under on-chain parallel computation. They achieve scaling by "parallel running multiple chains/execution domains" 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 Overview: The Best Solution for Native Expansion?])https://img-cdn.gateio.im/webp-social/moments-2340d8a61251ba55c370d74178eec53e.webp(

2. EVM System Parallel Enhanced Chain: Breaking Performance Boundaries in Compatibility

Ethereum's serial processing architecture has evolved through multiple rounds of scaling attempts, including sharding, Rollup, and modular architectures, but the throughput bottleneck at the execution layer has yet to be fundamentally broken through. Meanwhile, EVM and Solidity remain the most developer-friendly and ecologically potent smart contract platforms today. Therefore, EVM-based parallel enhancement chains are becoming a key path that balances ecological compatibility and improved execution performance, emerging as an important direction for the next round of scaling evolution. Monad and MegaETH are the most representative projects in this direction, each constructing 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 (Pipelining), asynchronously executing at the consensus layer (Asynchronous Execution) and optimistically parallel executing at the execution layer ###Optimistic Parallel Execution(. 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 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 cross-block concurrent processing, ultimately enhancing throughput and reducing latency. These stages include: transaction proposal ) Propose ( consensus achievement ) Consensus ( transaction execution ) Execution ( and block submission ) 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." It significantly reduces block time ) block time ( and confirmation delays, making the system more resilient, with more granular processing flows and higher resource utilization.

Core Design:

• Consensus process ) Consensus layer ( is responsible only for ordering transactions and does not execute contract logic.
• Execution process ) execution layer ( is asynchronously triggered after consensus is completed.
• After the consensus is reached, immediately enter the consensus process for the next block 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 improving transaction processing rates.

Execution mechanism:

• Monad will optimistically execute all transactions in parallel, assuming that there are no state conflicts between most transactions.
• Run a "Conflict Detector)" simultaneously to monitor whether transactions access the same state(, such as read/write conflicts).
• If a conflict is detected, conflicting transactions will be serialized and re-executed to ensure state correctness.

Monad chose 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 the migration of the EVM ecosystem, serving as a parallel accelerator in the EVM world.

( 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 both as an independent L1 public chain and as an execution enhancement layer on Ethereum )Execution Layer( or as 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 on-chain. The key innovations proposed by MegaETH include: Micro-VM architecture + State Dependency DAG) Directed Acyclic Graph of State Dependencies( and modular synchronization mechanisms, collectively constructing a parallel execution system aimed at "on-chain threading."

Micro-VM) Micro Virtual Machine ( Architecture: Account as Thread

MegaETH introduces the execution model of "one micro virtual machine per account )Micro-VM###", which "threadizes" the execution environment, providing the smallest isolation unit for parallel scheduling. These VMs communicate with each other through asynchronous messaging (Asynchronous Messaging), rather than synchronous calls, allowing a large number of VMs to execute independently and store independently, naturally 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 (Dependency Graph) in real-time, modeling all account modifications and reads during each transaction as dependency relationships. Non-conflicting transactions can be executed in parallel directly, while transactions with dependencies will be scheduled in serial order or delayed according to topological order. The dependency graph ensures state consistency and non-repetitive writes during parallel execution.

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 a state dependency graph, and replacing synchronous call stacks with an asynchronous messaging mechanism. It is a parallel computing platform redesigned from the full dimension of "account structure → scheduling architecture → execution process," providing a paradigm-level new approach for constructing the next generation of high-performance on-chain systems.

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

The design concepts of Monad and MegaETH are significantly different from ( Sharding ): Sharding horizontally splits the blockchain into multiple independent sub-chains ( Shards ), with each sub-chain responsible for part of the transactions and state, breaking the limitations of a single chain for network-layer scalability; whereas Monad and MegaETH maintain the integrity of a single chain and only horizontally scale 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 scalability path: vertical enhancement and horizontal expansion.

Projects like Monad and MegaETH focus primarily on throughput optimization paths, with the core goal of enhancing 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 its core parallel computing mechanism known as "Rollup Mesh." This architecture supports a multi-virtual machine environment, including EVM and Wasm, through the collaborative work of the main network 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 various stages of a transaction ) such as consensus, execution, and storage (, and uses 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 capability through parallel execution.
3. Special Handling Network ( SPNs ): SPNs are key components in the Pharos architecture, similar to modular sub-networks, specifically designed for handling specific 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 & 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 reconstructed the execution model from the bottom of the storage engine through 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, low latency, and strong verifiable on-chain processing capabilities.

![