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

Author: 0xjacobzhao and ChatGPT The

"Blockchain Trilemma" of the 4o blockchain "security", "decentralization", and "scalability" reveal the essential trade-offs in the design of blockchain systems, that is, it is difficult for blockchain projects to achieve "ultimate security, everyone-in-waiting, and high-speed processing" at the same time. In response to the eternal topic of "scalability", the mainstream blockchain scaling solutions on the market are currently divided according to paradigms, including:

• Execution-enhanced scaling: improving execution capabilities in situ, such as parallel, GPU, and multi-core
State
• isolated scaling: horizontally splitting state/shard, such as sharding, UTXO, and multi-subnet
• Off-chain outsourcing scaling: putting execution off-chain, such as rollup, Coprocessor, DA
• structure decoupling scaling: architecture modularity and collaborative operation, such as module chains, shared sequencers, Rollup Mesh
• Asynchronous concurrent scaling: Actor model, process isolation, message-driven, such as agents, multi-threaded asynchronous chains

The blockchain expansion solution includes: intra-chain parallel computing, Rollup, sharding, DA modules, modular structures, actor systems, zk proof compression, stateless architecture, etc., covering multiple layers of execution, state, data, and structure, and is a complete expansion system with "multi-layer collaboration and module combination". This article focuses on the expansion method with parallel computing as the mainstream.

Intra-chain parallelism, which focuses on the parallel execution of transactions/instructions within blocks. According to the parallel mechanism, its expansion methods can be divided into five categories, each representing different performance pursuits, development models and architecture philosophies, and the parallel granularity is getting finer and finer, the parallel intensity is getting higher and higher, the scheduling complexity is getting higher and higher, and the programming complexity and implementation difficulty are getting higher and higher.

• Account-level: Represents the project Solana
• Object-level:
• Transaction-level: Represents the project Monad, Aptos
• call-level / MicroVM : Represents the project MegaETH
• Instruction-level: Represents the project GatlingX

Off-chain asynchronous concurrency models, represented by the Actor Agent System (Agent/Actor Model), they belong to another parallel computing paradigm, as a cross-chain/asynchronous message system (non-block synchronous model), each agent acts as an independent "agent process", parallel asynchronous messages, event-driven, no synchronous scheduling, representing projects such as AO, ICP, Cartesi, etc.

The rollup or shard scaling scheme we are familiar with is a system-level concurrency mechanism and does not belong to intra-chain parallel computing. They scale by "running multiple chains/execution domains in parallel" rather than increasing the parallelism within a single block/virtual machine. This scaling scheme is not the focus of this article, but we will still use it to compare the similarities and differences between architectural concepts.

2. EVM parallel enhancement chain: breaking the performance boundary in compatibility

Ethereum's serial processing architecture has undergone multiple rounds of expansion attempts such as sharding, rollup, and modular architecture, but the throughput bottleneck of the execution layer has not yet been fundamentally broken. However, at the same time, EVM and Solidity are still the smart contract platforms with the most developer base and ecological potential. Therefore, EVM-based parallel enhancement chains, as a key path that takes into account ecological compatibility and execution performance improvement, are becoming an important direction for a new round of expansion and evolution. Monad and MegaETH are the most representative projects in this direction, starting from delayed execution and state decomposition, respectively, to build an EVM parallel processing architecture for high-concurrency and high-throughput scenarios.

Monad's Parallel Computing Analysis

Monad is a high-performance Layer1 blockchain redesigned for the Ethereum Virtual Machine (EVM), based on the basic parallel concept of pipelining, with Asynchronous Execution at the consensus layer and Optimistic at the execution layer Parallel Execution） 。 In addition, at the consensus and storage layers, Monad introduces the high-performance BFT protocol (MonadBFT) and the dedicated database system (MonadDB) to achieve end-to-end optimization.

Pipelining: Multi-stage pipeline parallel execution mechanism

Pipelining is the basic concept of Monad parallel execution, the core idea is to split the execution process of the blockchain into multiple independent stages, and process these stages in parallel to form a three-dimensional pipeline architecture, each stage runs on independent threads or cores to achieve cross-block concurrent processing. The result is to increase throughput and reduce latency. These stages include: Propose, Consensus, Execution, and Commit.

Asynchronous Execution: Consensus - Execution Asynchronous Decoupling

On traditional chains, transaction consensus and execution are typically synchronous processes, and this serial model severely limits performance scaling. Monad implements consensus layer asynchronous, execution layer asynchronous, and storage asynchronous through "asynchronous execution". Significantly reduce block time and confirmation delay, making the system more resilient, more granular processing, 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 consensus is completed.
• Once the consensus is completed, it immediately enters the next block consensus process without waiting for the execution to complete.

Optimistic Parallel Execution: Traditional

Ethereum employs a strict serial model for transaction execution to avoid state conflicts. Monad, on the other hand, adopts an "optimistic parallel execution" strategy to significantly increase transaction processing speed.

Execution Mechanism:

• Monad optimistically executes all transactions in parallel, assuming that most transactions are stateless and conflict-free.
• A "Conflict Detector" is also run to monitor whether the same state is accessed between transactions (e.g., read/write conflicts).
• If a conflict is detected, the conflicting transaction is serialized and reexecuted to ensure state correctness.

Monad has chosen the compatibility path: it uses as few EVM rules as possible, and achieves parallelism by delaying write state and dynamically detecting conflicts during execution, more like a performance version of Ethereum, which is easy to achieve EVM ecological migration with maturity, and is a parallel accelerator in the EVM world.

MegaETH's parallel computational resolution

is different from Monad's L1 positioning, which is positioned as an EVM-compatible modular, high-performance parallel execution layer, which can be used as a standalone L1 public chain, or as an execution layer or modular component on Ethereum. Its core design goal is to deconstruct account logic, execution environment, and state isolation into the smallest unit that can be independently scheduled to achieve high concurrency execution and low latency responsiveness within the chain. The key innovations proposed by MegaETH are: Micro-VM architecture + State Dependency DAG (Directed Acyclic State Dependency Graph) and modular synchronization mechanism, jointly building a parallel execution system for "intra-chain threading".

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

MegaETH introduces the execution model of "one micro-virtual machine (Micro-VM) per account", which "threads" the execution environment and provides minimal isolation units for parallel scheduling. These VMs communicate with each other through asynchronous messaging rather than synchronous calls, and a large number of VMs can be executed independently, stored independently, and naturally parallel.

State Dependency DAG: A 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, and models which accounts are modified and read for each transaction, all of which are modeled into dependencies. Conflict-free transactions can be executed directly in parallel, and transactions with dependencies will be scheduled and ordered in topological order serial or delayed. Dependency graphs ensure state consistency and unique writes during parallel execution.

Asynchronous Execution and Callback Mechanism

MegaETH is built on the asynchronous programming paradigm, similar to the asynchronous messaging of the Actor Model, solving the problem of traditional EVM serial calls. Contract calls are asynchronous (non-recursive execution), and when contracts A -> B -> C are called, each call is asynchronous without blocking waiting. The call stack is expanded into an asynchronous call graph; Transaction processing = traversal asynchronous graph + dependency resolution + parallel scheduling.

In summary, MegaETH breaks the traditional EVM single-threaded state machine model, implements micro-virtual machine encapsulation on an account-by-account basis, conducts transaction scheduling through state dependency graphs, and replaces the synchronous call stack with an asynchronous messaging mechanism. It is a parallel computing platform that has been redesigned from the full dimension of "account structure→ scheduling architecture, → execution process", providing a paradigm-level new idea for building the next generation of high-performance on-chain systems.

MegaETH has chosen a refactoring path: completely abstracting accounts and contracts into independent VMs, unleashing the ultimate parallel potential through asynchronous scheduling. In theory, MegaETH has a higher parallel cap, but it is also more difficult to control complexity, more like a super-distributed operating system under the Ethereum concept.

Monad and MegaETH both have design concepts that are quite different from sharding: sharding horizontally splits the blockchain into multiple independent sub-chains (shards), each of which is responsible for a portion of the transaction and state, breaking the limitations of a single chain and expanding at the network layer. Both Monad and MegaETH maintain single-chain integrity, only scaling horizontally at the execution layer, and executing in parallel within the single chain to optimize breakthrough performance. The two represent two directions of vertical strengthening and horizontal expansion in the blockchain expansion path.

Parallel computing projects such as Monad and MegaETH mainly focus on the throughput optimization path, with the core goal of improving in-chain TPS, and achieving transaction-level or account-level parallel processing through deferred execution and micro-VM architectures. As a modular, full-stack parallel L1 blockchain network, Pharos Network's core parallel computing system is called "Rollup Mesh". This architecture works in tandem with special processing networks (SPNs) through mainnets, supports multi-virtual machine environments (EVM and Wasm), and integrates advanced technologies such as zero-knowledge proofs (ZK) and trusted execution environments (TEEs).

Rollup Mesh Parallel Computing Analysis:

1. Full Lifecycle Asynchronous Pipelining: Pharos decouples the various stages of the 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 both EVM and WASM virtual machine environments, allowing developers to choose the appropriate execution environment according to their needs. This dual-VM architecture not only enhances the flexibility of the system but also enhances transaction processing capabilities through parallel execution.
3. Special Processing Networks (SPNs): SPNs are key components in the Pharos architecture, similar to modular subnetworks designed to handle specific types of tasks or applications. Through SPNs, Pharos enables 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 (e.g., PBFT, PoS, PoA) and enables secure sharing and resource integration between the mainnet and SPNs through re-staking protocols (Restaking).

In addition, Pharos has launched Pharos Store, a native blockchain high-performance storage engine, to achieve high throughput, low latency, and strong verifiable on-chain processing capabilities by reconstructing the execution model from the bottom layer of the storage engine through multi-version Merkle trees, delta encoding, versioned addressing, and ADS Pushdown technologies.

In general, Pharos' Rollup Mesh architecture achieves high-performance parallel computing capabilities through modular design and asynchronous processing mechanisms, and Pharos, as a scheduling coordinator for cross-rollup parallelism, is not an execution optimizer for "intra-chain parallelism" but rather carries heterogeneous customized execution tasks through SPNs.

In addition to the parallel execution architectures of Monad, MegaETH, and Pharos, we have also observed that there are some projects in the market exploring the application path of GPU acceleration in EVM parallel computing as an important supplement to the EVM parallel ecosystem and cutting-edge experiments. Among them, Reddio and GatlingX are two representative directions:

• Reddio is a high-performance platform that combines zkRollup and GPU parallel execution architecture, and its core is to reconstruct the EVM execution process, through multi-threaded scheduling, asynchronous state storage, and GPU-accelerated execution of transaction batches, and realize the native parallelization of the execution layer. It belongs to the parallel granularity of transactional level + operation level (multi-threaded execution opcode). Its design introduces multi-threaded batch execution, asynchronous state loading, and GPU-Parallel Transaction Logic (CUDA-Compatible Parallel EVM). Like Monad / MegaETH, Reddio also focuses on parallel processing at the execution layer, with the difference that it refactors the execution engine through a GPU parallel architecture, designed for high-throughput and computationally intensive scenarios such as AI inference.
• GatlingX, which calls itself "GPU-EVM" and proposes a more radical architecture to migrate the "instruction-level serial execution" model of traditional EVM virtual machines to GPU-native parallel running environments. Its core mechanism is to dynamically compile EVM bytecode into CUDA parallel tasks, executing instruction flow through GPU multi-cores, thereby breaking the EVM's sequential bottleneck at the very bottom. Parallel granularity belongs to the Instruction-Level Parallelism (ILP). Compared with Monad/MegaETH's "transaction-level/account-level" parallel granularity, GatlingX's parallelism mechanism belongs to the instruction-level optimization path, which is closer to the underlying refactoring of the virtual machine engine. Currently in the concept stage, a white paper and architecture sketch have been published, and there is no SDK or mainnet yet.

Artela proposed a differentiated parallel design concept. By introducing the EVM++ architecture WebAssembly (WASM) virtual machine, developers can dynamically add and execute extensions on-chain using the Aspect programming model while maintaining EVM compatibility. It uses contract call granularity (Function/Extension) as the minimum parallel unit, and supports injecting Extension modules (similar to "pluggable middleware") when EVM contracts are running, enabling logical decoupling, asynchronous calls, and module-level parallel execution. Pay more attention to the composability and modular architecture of the execution layer. Its concept provides new ideas for future complex multi-module applications.

3. Native parallel architecture chain: reconstructing the execution ontology of the VM

Ethereum's EVM execution model has adopted a single-threaded architecture of "transaction sequence + serial execution" since its design, aiming to ensure the certainty and consistency of state changes among all nodes in the network. However, this architecture has inherent bottlenecks in performance, limiting system throughput and scalability. In contrast, native parallel computing architecture chains such as Solana (SVM), MoveVM (Sui, Aptos), and Sei v2 built on the Cosmos SDK are tailored for parallel execution from the underlying design, with the following advantages:

• Natural separation of state models: Solana adopts an account lock claim mechanism, MoveVM introduces an object ownership model, and Sei v2 is based on transaction type classification. Static conflict determination is realized, and transaction-level concurrent scheduling is supported.
• Virtual machines optimized for concurrency: Solana's Sealevel engine natively supports multi-threaded execution; MoveVM can perform static concurrency graph analysis; Sei v2 integrates a multi-threaded matching engine and a parallel VM module.

Of course, this type of native parallel chain also faces the challenge of ecological compatibility. Non-EVM architectures usually require new development languages (such as Move, Rust) and toolchains, which have certain migration costs for developers. In addition, developers need to master a series of new concepts such as state access models, concurrency limits, and object lifecycles, which put forward higher requirements for understanding thresholds and development paradigms.

3.1 Principle of Sealevel parallel engine of Solana and SVM systems

Solana's Sealevel execution model is an account parallel scheduling mechanism, which is the core engine used by Solana to implement parallel transaction execution within the chain, achieving high-performance concurrency at the smart contract level through the "account declaration + static scheduling + multi-threaded execution" mechanism. Sealevel is the first execution model in the blockchain field to successfully implement on-chain concurrent scheduling in a production environment, and its architectural ideas have influenced many subsequent parallel computing projects, serving as a reference paradigm for high-performance Layer1 parallel design.

Core mechanism:

1. Explicit Account Access Lists: Each transaction must declare the accounts involved (read/write) when submitted, and the system determines whether there is a state conflict between transactions.

2. Conflict detection and multi-threaded scheduling

• If the account collection accessed by two transactions does not intersect→ it can be executed in parallel.
• There is a conflict → Serial execution in the order of dependencies;
• The scheduler assigns transactions to different threads based on a dependency graph.

3. Program Invocation Context: Each contract call runs in an isolated context without a shared stack to avoid cross-call interference.

SealevelSealevel is Solana's parallel execution scheduling engine, while SVM is a smart contract execution environment built on top of Sealevel (using the BPF virtual machine). Together, they form the technical foundation of Solana's high-performance parallel execution system.

Eclipse is a project that deploys Solana VMs onto modular chains like Ethereum L2 or Celestia, leveraging Solana's parallel execution engine as a rollup execution layer. Eclipse was one of the first projects to propose to migrate the Solana execution layer (Sealevel + SVM) from the Solana mainnet to a modular architecture, modularizing Solana's "super concurrent execution model" as an Execution Layer-as-a-Service, so Eclipse also belongs to the parallel computing category.

Neon takes a different route by bringing the EVM to the SVM / Sealevel environment to operate. Build an EVM-compatible runtime layer where developers can use Solidity to develop contracts and run them in the SVM environment, but use SVM + Sealeve for scheduling execution. Neon leans more towards modular blockchain and less emphasis on parallel computing innovation.

In summary, Solana and SVM rely on the Sealevel execution engine, and the Solana operating system-based scheduling philosophy is similar to the kernel scheduler, which executes quickly but is relatively less flexible. It is a native high-performance, parallel computing public chain.

3.2 MoveVM Architecture: Resource and Object-Driven

MoveVM is a smart contract virtual machine designed for on-chain resource security and parallel execution, and its core language Move was originally developed by Meta (formerly Facebook) for the Libra project, emphasizing the concept of "resource is object", where all on-chain state exists as an object, with clear ownership and lifecycle. This allows MoveVM to analyze whether there are state conflicts between transactions during compile time, implement object-level static parallel scheduling, and is widely used in native parallel public chains such as Sui and Aptos.

Sui's object ownership model

Sui's parallel computing power stems from its unique state modeling approach and language-level static analysis mechanism. Unlike traditional blockchains that use global state trees, Sui has built an "object-centric model" based on MoveVM's linear typing system, making parallel scheduling a deterministic process that can be completed at compile time.

• The Object Model is the foundation of Sui's parallel architecture. Sui abstracts all state on the chain into independent objects (Objects), each with a unique ID, a clear owner (account or contract), and a type definition. These objects do not share state with each other and are naturally isolated. The contract must explicitly declare the set of objects involved when called, avoiding the state coupling problem of the traditional on-chain "global state tree". This design cuts the on-chain state into several independent units, making concurrent execution a structurally feasible scheduling prerequisite.
• Static Ownership Analysis is a compile-time analysis mechanism implemented with the support of the linear typing system of the Move language. It allows the system to deduce which transactions do not cause state conflicts through object ownership before they are executed, and thus arrange them to be executed in parallel. Compared with traditional runtime conflict detection and rollback, Sui's static analysis mechanism improves execution efficiency while greatly reducing scheduling complexity, which is the key to achieving high throughput and deterministic parallel processing capabilities.

Sui divides the state space on an object-by-object basis, combined with compile-time ownership analysis, to achieve low-cost, non-rollback-free object-level parallel execution. Compared with the serial execution or runtime detection of traditional chains, Sui has achieved significant improvements in execution efficiency, system certainty, and resource utilization.

Aptos' Block-STM Execution Mechanism

Aptos is a high-performance Layer1 blockchain based on the Move language, and its parallel execution capabilities mainly stem from the self-developed Block-STM (Block-level Software Transactional Memory) framework. Unlike Sui's strategy of "static parallelism at compile time", Block-STM is a dynamic scheduling mechanism of "optimistic concurrency at runtime + collision rollback", suitable for handling transaction sets with complex dependencies.

Block-STM divides the transaction execution of a block into three stages:

• Speculative Execution: All transactions are conflict-free by default before execution, and the system schedules transactions to multiple threads to attempt execution in parallel, and records the status of the accounts they access (read/write).
• Validation Phase: The system verifies the execution results: If there is a read/write conflict between two transactions (e.g., Tx1 reads the state written by Tx2), one of them will be rolled back.
• Conflicting transaction rollback retry phase: Conflicting transactions will be rescheduled for execution until their dependencies are resolved, and eventually all transactions form a valid, definite state commit sequence.

Block-STM is a dynamic execution model of "optimistic parallelism + rollback retry", suitable for state-intensive and logically complex on-chain transaction batch processing scenarios, and is the parallel computing core for Aptos to build a highly versatile and high-throughput public chain.

Solana is an engineering scheduling school, more like an "operating system kernel", suitable for clear state boundaries, controllable high-frequency trading, and is a hardware engineer style, running the chain like hardware (Hardware-grade parallel execution); Aptos is a system fault tolerant and more like a "database concurrency engine", suitable for contract systems with strong state coupling and complex call chains. Aptos and Sui should act like programming language engineers and software-grade resource security.

3.3 Cosmos SDK Parallel Scalability

Sei V2 is a high-performance transactional public chain built on the Cosmos SDK, and its parallel capabilities are mainly reflected in two aspects: the parallel matching engine (Parallel Matching Engine) and the virtual machine layer are optimized for parallel execution, aiming to serve high-frequency, low-latency on-chain transaction scenarios, such as order book DEXs, on-chain exchange infrastructure, etc.

Core Parallel Mechanism:

1. Parallel Matching Engine: Sei V2 introduces a multi-threaded execution path in the order matching logic, splitting the pending order book from the matching logic at the thread level, so that matching tasks between multiple markets (trading pairs) can be processed in parallel, avoiding single-threaded bottlenecks.
2. Virtual Machine-Level Concurrency Optimization: Sei V2 builds a CosmWasm runtime environment with concurrent execution capabilities, allowing some contract calls to run in parallel without state conflicts, and cooperates with transaction type classification mechanisms to achieve higher throughput control.
3. Parallel Consensus with Execution Layer Scheduling: The so-called "Twin-Turbo" consensus mechanism is introduced to strengthen the decoupling of throughput between the consensus layer and the execution layer, improving the overall block processing efficiency.

3.4 UTXO Model Restructuror Fuel

Fuel is a high-performance execution layer designed based on Ethereum's modular architecture, and its core parallelism mechanism is derived from the improved UTXO model (Unspent Transaction Output). Unlike Ethereum's account model, Fuel uses a UTXO structure to represent assets and state, which is inherently state-isolated, making it easy to determine which transactions can be executed safely in parallel. Additionally, Fuel introduces Sway, a self-developed smart contract language (similar to Rust), and combines it with static analysis tools to identify input conflicts before transaction execution, enabling efficient and secure transaction-level parallel scheduling. It is an EVM alternative execution layer that balances performance and modularity.

4. Actor Model: A New Paradigm for Concurrent Execution of Agents

Actor Model is a parallel execution paradigm based on agent processes (Agents or Processes), which is different from the traditional synchronous computation of global state on the chain ("on-chain parallel computing" scenarios such as Solana/Sui/Monad), which emphasizes that each agent has independent states and behaviors, communicating and scheduling through asynchronous messages. Under this architecture, on-chain systems can run concurrently with a large number of processes that are decoupled from each other, with strong scalability and asynchronous fault tolerance. Representative projects include AO (Arweave AO), ICP (Internet Computer), and Cartesi, which are driving the evolution of blockchain from an execution engine to an "on-chain operating system", providing native infrastructure for AI agents, multitasking interactions, and complex logic orchestration.

Although the design of the Actor Model has some similarities with sharding in terms of surface features (e.g., parallelism, state isolation, asynchronous processing), they essentially represent completely different technical paths and system philosophies. The Actor Model emphasizes "multi-process asynchronous computing", where each agent (Actor) operates independently, maintains its state independently, and interacts through message-driven interactions; Sharding, on the other hand, is a "horizontal slicing of state and consensus" mechanism, dividing the entire blockchain into multiple subsystems (shards) that process transactions independently. Actor Model is more like a "distributed agent operating system" in the Web3 world, while sharding is a structural scaling solution for on-chain transaction processing capabilities. Both achieve parallelism, but have different starting points, goals, and execution architectures.

4.1 AO (Arweave), a super-parallel computer on top of the storage layer

AO is a decentralized computing platform running on the Arweave permanent storage layer, with the core goal of building an on-chain operating system that supports the operation of large-scale asynchronous agents.

Core Architecture Features:

• Process architecture: Each agent is called a Process, with independent state, independent scheduler, and execution logic.
• No blockchain structure: AO is not a chain, but a decentralized storage layer + multi-agent message-driven execution engine based on Arweave.
• Asynchronous message scheduling system: Processes communicate through messages, adopt a lockless asynchronous operation model, and naturally support concurrent expansion.
• Permanent state storage: All agent states, message records, and instructions are permanently recorded on Arweave, ensuring complete auditability and decentralized transparency.
• Agent-native: Suitable for deploying complex multi-step tasks (such as AI agents, DePIN protocol controllers, automatic task orchestrators, etc.), and can build "on-chain AI coprocessors".

AO takes the ultimate "agent-native + storage-driven + chainless architecture" route, emphasizing flexibility and module decoupling, and is an "on-chain microkernel framework built on top of the storage layer", with deliberately shrinking system boundaries and emphasizing lightweight computing + composable control structure.

4.2 ICP (Internet Computer), a full-stack Web3 hosting platform

ICP is a Web3 native full-stack on-chain application platform launched by DFINITY, with the goal of extending on-chain computing power to Web2-like experiences, and supporting complete service hosting, domain binding, and serverless architecture.

Core Architecture Features:

• Canister architecture (container i.e. agent): Each Canister is an agent running on a Wasm VM, with independent state, code, and asynchronous scheduling capabilities.
• Subnet Distributed Consensus System (Subnet): The entire network consists of multiple subnets, each maintaining a set of Canisters to reach consensus through the BLS signature mechanism.
• Asynchronous call model: Canister communicates with Canister through asynchronous messages, supports non-blocking execution, and has natural parallelism.
• On-chain web hosting: It supports smart contracts to directly host front-end pages, native DNS mapping, and is the first blockchain platform to support direct access to dApps by browsers.
• Complete system functions: It has system APIs such as on-chain hot upgrades, authenticated identity, distributed randomness, and timers, making it suitable for complex on-chain service deployments.

ICP chooses an operating system paradigm that emphasizes platform, integrated packaging, and strong platform control, with a "blockchain operating system" integrating consensus, execution, storage, and access, emphasizing complete service hosting capabilities, and expanding the system boundary to a full-stack Web3 hosting platform.

In addition, the parallel computing projects of other Actor Model paradigms can be referred to the following table:

5. Summary and Prospect

Based on the differences between virtual machine architecture and language systems, blockchain parallel computing solutions can be roughly divided into two categories: EVM-based parallel enhanced chains and native parallel architecture chains (non-EVM).

The former retains the compatibility of the EVM / Solidity ecosystem and achieves higher throughput and parallel processing capabilities through deep optimization of the execution layer, making it suitable for scenarios that want to inherit Ethereum assets and development tools while achieving performance breakthroughs. Representative projects include:

• Monad: Implements an optimistic parallel execution model compatible with EVM through delayed write and runtime conflict detection, builds a dependency graph and schedules execution in multiple threads after consensus is completed.
• MegaETH: Abstracts each account/contract into an independent micro-virtual machine (Micro-VM), based on asynchronous messaging and state dependency graphs, to achieve highly decoupled account-level parallel scheduling.
• Pharos: Build a Rollup Mesh architecture that collaborates with SPN modules through asynchronous pipelines to achieve system-level parallel processing across processes.
• Reddio: Adopts zkRollup + GPU architecture, focusing on accelerating the off-chain verification process of zkEVM through batch SNARK generation to improve verification throughput.

The latter completely removes the limitations of Ethereum compatibility and redesigns the execution paradigm from virtual machines, state models, and scheduling mechanisms to achieve native high-performance concurrency capabilities. Typical subclasses include:

• Solana (SVM system): based on account access claims and static conflict graph scheduling, representing an account-level parallel execution model;
• Sui / Aptos (MoveVM series): Based on the resource object model and type system, it supports static analysis at compile time and realizes object-level parallelism.
• Sei V2 (Cosmos SDK route): Introduces a multi-threaded matching engine and virtual machine concurrency optimization in the Cosmos architecture, suitable for transactional high-frequency applications.
• Fuel (UTXO + Sway Architecture): Enables transaction-level parallelism through static analysis of UTXO input sets, combining a modular execution layer with a customized smart contract language Sway.

In addition, Actor Model, as a broader parallel system, builds an on-chain execution paradigm of "multi-agent independent operation + message-driven collaboration" through an asynchronous process scheduling mechanism based on Wasm or custom VMs. Representative projects include:

• AO (Arweave AO): Build an on-chain asynchronous microkernel system based on a persistent storage-driven agent runtime;
• ICP (Internet Computer): with the containerized agent (Canister) as the smallest unit, asynchronous and highly scalable execution is achieved through subnet coordination;
• Cartesi: Introduces the Linux operating system as an off-chain computing environment, providing an on-chain verification path for trusted computational results, suitable for complex or resource-intensive application scenarios.

Based on the above logic, we can summarize the current mainstream parallel computing public chain scheme into the classification structure shown in the following chart:

From a broader perspective of scaling, sharding and rollup (L2) focus on system horizontal scaling through state segmentation or off-chain execution, while parallel computing chains (such as Monad, Sui, Solana) and actor-oriented systems (such as AO, ICP) directly reconstruct the execution model to achieve native parallelism within the chain or at the system layer. The former improves in-chain throughput through multi-threaded virtual machines, object models, transaction conflict analysis, etc.; the latter takes the process/agent as the basic unit and adopts message-driven and asynchronous execution to realize the concurrent operation of multiple agents. In contrast, sharding and rollups are more like "breaking the load down to multiple chains" or "outsourcing it to off-chain", while the parallel chain and actor model "unlocks performance potential from the execution engine itself", reflecting a more thorough architectural evolution.

Parallel Compute vs Sharding Architecture vs Rollup Scaling vs Actor Oriented Scaling Path Comparison

Although the overall developer ecosystem is still difficult to compare with the EVM-based Solidity system, projects represented by Solana and Sui have become the core public chains that the market is highly concerned about with their high-performance execution architectures and the gradual prosperity of ecological applications.

In contrast, although the Ethereum Rollup (L2) ecosystem has entered the stage of "ten thousand chains simultaneously" or even "overcapacity", the current mainstream EVM-based parallel enhancement chains are still generally stuck in the testnet stage and have not yet been actually verified by the mainnet environment, and their scalability and system stability still need to be further tested. Whether these projects can significantly improve EVM performance and promote ecological transitions without sacrificing compatibility, or whether they will further differentiate Ethereum's liquidity and development resources, remains to be tested.