The Landscape of Web3 Parallel Computing: Seeking the Ideal Solution for Native Scalability

The “impossible triangle” of blockchain systems reveals the essential trade-offs between security, decentralization, and scalability. In view of the eternal challenge of scalability, the mainstream blockchain scaling solutions in the market can be divided into the following paradigms:

• Implement enhanced scaling: improve native execution capabilities, such as parallel computing, GPU optimization, and multi-core processing.
• State isolation scaling: horizontal partitioning of state, such as sharding, UTXO model, multi-subnet architecture
• Off-chain outsourcing type scaling: transferring execution off-chain, such as Rollup, co-processors, and data availability layers.
• Decoupled Structure Expansion: Modular architecture and collaborative operation, such as modular chains, shared sequencers, Rollup networks.
• Asynchronous concurrent scaling: Actor model, process isolation, and message-driven, such as agent systems and asynchronous chains.

This article focuses on the expansion method based on parallel computing. In-chain parallel computing focuses on the parallel execution of transactions and instructions within the block, which can be divided into five major categories based on granularity, with increasing parallel intensity and complexity.

• Account-level parallelism: represents the project Solana
• Object-level parallelism: Represents the Sui project
• Trading-level parallelism: represents projects Monad, Aptos
• Calling level/micro VM parallel: represents the project MegaETH
• Instruction-level parallelism: represents the project GatlingX

The Actor smart agent systems (such as AO, ICP, Cartesi) adopt another parallel paradigm, achieving concurrency through asynchronous messaging, event-driven processes, and independent processes, without relying on block synchronization scheduling.

EVM-based Parallel Enhanced Chain: Seeking Breakthroughs in Compatibility

Ethereum’s serial processing architecture has undergone multiple rounds of expansion attempts, but the bottleneck at the execution layer has not yet been completely resolved. At the same time, EVM and Solidity remain the most developer-friendly smart contract platforms. Therefore, EVM-based parallel enhancement chains have become a key path to balancing ecosystem compatibility and performance improvement. Monad and MegaETH are representative projects in this direction.

Monad’s parallel computing mechanism

Monad is a high-performance L1 blockchain re-designed for EVM, based on pipelined processing and optimistic concurrency execution. Its core includes:

Pipelining Mechanism: The blockchain execution process is divided into multiple independent stages (proposal, consensus, execution, submission), forming a three-dimensional pipeline architecture, with each stage running on independent threads to achieve cross-block concurrent processing.

Asynchronous Execution: Achieve asynchronous consensus layer, asynchronous execution layer, and asynchronous storage, where the consensus process is only responsible for ordering transactions without executing contract logic. The execution process is triggered asynchronously after the consensus is completed, significantly reducing block confirmation delays.

Optimistic Parallel Execution: Execute all transactions in parallel optimistically while running a conflict detector to monitor state access conflicts. In case of conflicts, the relevant transactions are serialized and re-executed to ensure state correctness.

Monad chooses a compatible path, trying to retain EVM rules, achieving parallelism through delayed state writing and dynamic conflict detection, more like an Ethereum performance accelerator, facilitating ecological migration.

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

MegaETH’s parallel computing mechanism

MegaETH is positioned as a modular high-performance execution layer compatible with EVM, which can serve as an independent L1 or as an enhancement layer for Ethereum. Its core innovation lies in:

Micro-VM Architecture: Realizes “account as thread”, each account has its own independent micro virtual machine, achieving natural parallelism through asynchronous message communication instead of synchronous calls.

State-dependent DAG Scheduling: Construct a directed acyclic graph based on account state access relationships, recording transaction dependencies in real-time, allowing for parallel execution of non-conflicting transactions, and scheduling dependent transactions in topological order.

Asynchronous Execution and Callback Mechanism: Using asynchronous message passing similar to the Actor model, the contract call is asynchronous, the call stack is expanded into an asynchronous call graph, and the transaction processing is completed through traversal of the asynchronous graph, dependency resolution and parallel scheduling.

MegaETH chooses to reconstruct the path by abstracting accounts and contracts into independent VMs, unleashing extreme parallel potential through asynchronous execution. The theoretical upper limit of parallelism is higher, but it also becomes more challenging to control complexity, similar to a distributed operating system under the Ethereum concept.

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

In addition, Pharos Network proposes the “Rollup Mesh” architecture, which works together with the (SPNs) of the main network and the special processing network to support multi-virtual machine environments, zero-knowledge proofs, trusted execution environments and other technologies. Its features include full-lifecycle asynchronous pipeline processing, dual-VM parallel execution, modular consensus, and re-staking mechanism.

There are also some projects in the market that explore the application path of GPU-accelerated EVM parallel computing, such as Reddio to achieve transaction-level + operation-level parallelism through multi-threaded scheduling, asynchronous state storage, and GPU parallel processing of transaction batches; GatlingX proposes a more radical “GPU-EVM” architecture, which dynamically compiles the EVM bytecode into CUDA parallel tasks to achieve instruction-level parallelism.

Artela proposes a differentiated EVM++ architecture that supports the injection of Extension modules during the execution of EVM contracts through the WASM virtual machine and Aspect programming model, achieving logic decoupling and module-level parallel execution.

Native Parallel Architecture Chain: Reconstructing the VM Execution Body

Unlike Ethereum’s “total order + serial execution” single-threaded architecture, blockchains built on Solana, MoveVM, and Cosmos SDK are designed from the ground up for parallel execution, offering the following advantages:

• Status model is inherently separated: Solana’s account lock declaration mechanism, MoveVM’s object ownership model, and Sei v2’s transaction type classification all support static conflict detection and concurrent scheduling.
• Virtual machine concurrency optimization: Solana’s Sealevel engine supports multithreaded execution, MoveVM can perform static concurrency graph analysis, Sei v2 integrates a multithreaded matching engine.

Of course, these native parallel chains also face ecological compatibility challenges, requiring entirely new programming languages and toolchains, which pose migration costs and learning barriers for developers.

Solana’s Sealevel parallel engine

Solana’s Sealevel is the first execution model in the blockchain field to successfully implement on-chain concurrent scheduling, and its core mechanisms include:

1. Explicit Account Access Declaration: When submitting a transaction, the involved account read and write permissions must be declared, and the system determines conflicts based on this.
2. Collision Detection and Multi-threaded Scheduling: Transactions of non-intersecting accounts are executed in parallel, and those with conflicts are executed serially in the order of dependencies
3. Independent Execution Context: Each contract runs in an isolated context to avoid cross-call interference.

The Eclipse and Neon projects modularize Solana’s execution engine for output to other architectures or introduce EVM into the SVM environment. Solana’s operating system-like scheduling philosophy is similar to a kernel scheduler, which offers fast execution but relatively low flexibility.

MoveVM Architecture: Resource and Object Driven

MoveVM emphasizes the concept of “resources as objects”, where all on-chain states exist in the form of objects, having clear ownership and lifecycle. This allows for the analysis of state conflicts at compile time and enables object-level parallel scheduling.

Sui’s Object Ownership Model constructs an “object”-based state model, where each object has a unique ID and a clear owner. When invoking contracts, the involved objects are explicitly declared. Combined with static ownership analysis, transaction conflicts can be determined at compile time, enabling low-cost object-level parallel execution.

Aptos’ Block-STM execution mechanism adopts a dynamic scheduling strategy of “runtime optimistic concurrency + conflict rollback”, executing in three phases: optimistic concurrent execution of all transactions and recording read-write sets, conflict detection and verification, and conflict transaction rollback and retry, suitable for state-intensive and logically complex scenarios.

Solana, Aptos, and Sui represent different philosophical paths of parallel computing in Web3: Solana is like an operating system kernel, suitable for high-frequency trading with clearly defined state boundaries; Aptos is like a database concurrency engine, suitable for complex contracts with strong state coupling; Sui is like a resource-oriented smart language platform, suitable for applications with asset separation and clear combinations.

Cosmos SDK parallel scaling

Sei V2 is built on the Cosmos SDK, with its parallel capabilities reflected in the multi-threaded matching engine and virtual machine layer optimization, serving high-frequency, low-latency trading scenarios:

1. Parallel Matching Engine: Thread-level separation of order books and matching logic, enabling parallel processing of matches across multiple markets.
2. VM-Level Concurrency Optimization: Supports state non-conflicting contract calls running in parallel
3. Parallel Consensus with Execution Layer Scheduling: The “Twin-Turbo” consensus mechanism strengthens the decoupling of the consensus layer and execution layer throughput.

UTXO Model Reconstructor Fuel

Fuel is designed based on the modular architecture of Ethereum, with its core parallel mechanism sourced from the improved UTXO model. By combining the self-developed smart contract language Sway and static analysis tools, it determines input conflicts before transaction execution, achieving efficient and secure transaction-level parallel scheduling, making it an EVM alternative execution layer that balances performance and modularity.

Actor Model: A New Paradigm for Concurrent Execution of Agents

The Actor Model constructs a parallel execution paradigm using agent processes, where each agent has independent states and behaviors, scheduled through asynchronous message communication. Unlike traditional on-chain parallel or sharding architectures, the Actor Model represents the concept of “multi-process asynchronous computation,” where the system runs a large number of decoupled processes concurrently, providing native infrastructure for AI Agents, multi-task interactions, and complex logic orchestration.

AO ( Arweave ): Super parallel computer above the storage layer

AO is built on the Arweave permanent storage layer, with core features including:

• Process Architecture: Each agent is an independent process, possessing its own state and execution logic.
• No Blockchain Structure: Based on a decentralized storage layer and a multi-agent message-driven execution engine
• Asynchronous Message Scheduling: Inter-process communication through message passing, lock-free asynchronous operation, naturally supports concurrency.
• Permanent Storage of Status: All status and message records are permanently saved, ensuring auditability and transparency.
• Native Agent: Suitable for complex multi-step tasks, such as AI agents, automated task orchestration, etc.

AO takes the extreme “native intelligent agent + storage-driven + chainless architecture” route, which is a microkernel framework of lightweight computing and composable control structures.

ICP ( Internet Computer ): Full-stack Web3 hosting platform

ICP aims to extend on-chain computing power to near Web2 experience, supporting full service hosting and serverless architecture:

• Canister Architecture: Each Canister is a smart contract container running on the Wasm VM, possessing independent state and scheduling capabilities.
• Subnet Distributed Consensus: The network consists of multiple Subnets, each maintaining a set of Canisters.
• Asynchronous Call Model: Canisters communicate with each other through asynchronous messaging, supporting non-blocking execution.
• On-chain Web Hosting: Supports direct hosting of front-end by smart contracts, native DNS mapping.
• Complete system functionality: Equipped with on-chain hot upgrades, identity verification, randomness, timer, and other system APIs.

ICP chooses a heavy platform and an integrated packaging route, which is a full-stack Web3 hosting platform.

! [Web3 Parallel Computing Track Panorama: The Best Solution for Native Scaling?] ](https://img.gateio.im/social/moments-94f9f15c52613e996efa66a0e5fa0542)

Summary and Outlook

Blockchain parallel computing solutions can be broadly divided into two categories: EVM-based enhanced parallel chains and native parallel architecture chains.

EVM-based Parallel Enhanced Chain optimizes the execution layer while maintaining ecological compatibility, with representative projects including:

• Monad: Achieving optimistic parallel execution through delayed writes and runtime conflict detection.
• MegaETH: Abstracts accounts into micro virtual machines, achieving account-level parallelism based on asynchronous messages and dependency graphs.
• Pharos: Building a Rollup Mesh architecture that achieves system-level parallelism through asynchronous pipelines.
• Reddio: Accelerates the verification process using zkRollup + GPU architecture.

Native Parallel Architecture Chain redesigns the execution paradigm from the ground up, representing subclasses including:

• Solana: Achieving account-level parallelism based on account access declarations and static scheduling.
• Sui/Aptos: Based on the resource object model, supports static analysis at compile time.
• Sei V2: Introduces multi-threaded matching engine and virtual machine concurrency optimization
• Fuel: Achieving transaction-level parallelism through UTXO input set analysis

Actor Model system builds agent execution paradigm through asynchronous processes and message-driven approach:

• AO: Asynchronous microkernel system based on permanent storage
• ICP: A Web3 hosting platform based on containerized intelligent agents.
• Cartesi: Introducing Linux as a trusted off-chain computing environment

From a broader perspective, sharding and rollup focus on horizontal scaling through state sharding or off-chain execution, while parallel computing chains and actor systems directly reconstruct the execution model to achieve native parallelism. The former is similar to “splitting the load to multiple chains” or “outsourcing to off-chain”, while the latter is “unlocking performance potential from the execution engine itself”.

At present, most native parallel architecture chains have entered the mainnet stage, and although the developer ecosystem is not yet as good as the EVM system, projects such as Solana and Sui have become the focus of market attention. In contrast, the mainstream EVM parallel enhancement chain is mostly in the testnet stage, and its scaling ability and stability still need to be further verified. It remains to be seen whether these projects can significantly improve EVM performance while maintaining compatibility, promote ecological transition, or exacerbate resource differentiation.