A Hardcore Interpretation of Web3 Parallel Computing

Written by: 0xjacobzhao and ChatGPT 4o

The "Blockchain Trilemma" of blockchain—"Security," "Decentralization," and "Scalability"—reveals the essential trade-offs in blockchain system design, indicating that it is challenging 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 currently on the market can be categorized by paradigm, including:

• Execution-enhanced scaling: Improving execution capabilities on-site, such as parallelism, GPU, multi-core

• State-isolation scaling: Horizontally splitting state / Shard, such as sharding, UTXO, multi-subnet

• Off-chain outsourcing scaling: Executing off-chain, such as Rollup, Coprocessor, DA

• Structural decoupling scaling: 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 scaling solutions include: intra-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 scaling system of "multi-layer collaboration and modular combination." This article focuses on parallel computing as the mainstream scaling method.

Intra-chain parallel computing focuses on the parallel execution of transactions/instructions within a block. According to the parallel mechanism, its scaling methods can be divided into five categories, each representing different performance pursuits, development models, and architectural philosophies, with increasingly finer parallel granularity, higher parallel intensity, and greater scheduling complexity, as well as increasing programming complexity and implementation difficulty.

• Account-level parallelism: Represented by the project Solana

• Object-level parallelism: Represented by the project Sui

• Transaction-level parallelism: Represented by the projects Monad, Aptos

• Call-level / Micro VM parallelism: Represented by the project MegaETH

• Instruction-level parallelism: Represented by the project GatlingX

The off-chain asynchronous concurrent model, represented by the Actor system (Agent / Actor Model), belongs to another parallel computing paradigm, serving as a cross-chain/asynchronous messaging system (non-block synchronization model), where each Agent operates as an independent "agent process," using asynchronous messaging, event-driven, and requiring no synchronized scheduling. Representative projects include AO, ICP, Cartesi, etc.

The well-known Rollup or sharding scaling solutions belong to system-level concurrent mechanisms and do not fall under intra-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.

II. EVM Series Parallel Enhanced Chains: Breaking Performance Boundaries within Compatibility

Ethereum's serial processing architecture has undergone multiple rounds of scaling attempts, including sharding, Rollup, and modular architecture, but the throughput bottleneck of the execution layer has not yet been fundamentally broken. Meanwhile, EVM and Solidity remain the most developer-friendly and ecologically potent smart contract platforms today. Therefore, EVM series parallel enhanced chains, which balance ecological compatibility and execution performance improvement, are becoming an important direction for the next round of scaling evolution. Monad and MegaETH are the most representative projects in this direction, building EVM parallel processing architectures aimed at high concurrency and high throughput scenarios, respectively, 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, Monad introduces a high-performance BFT protocol (MonadBFT) and a dedicated database system (MonadDB) at the consensus and storage layers, achieving end-to-end optimization.

Pipelining: Multi-stage Pipeline Parallel Execution Mechanism

Pipelining is the fundamental concept of Monad's parallel execution, where the core idea is to split the execution process of the blockchain into multiple independent stages and parallelize these stages, 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: Decoupling Consensus and Execution

In traditional chains, transaction consensus and execution are usually synchronous processes, and this serial model severely limits performance scalability. Monad achieves asynchronous consensus, execution, and storage through "asynchronous execution." This significantly reduces block time and confirmation latency, making the system more resilient, with more granular processing flows and higher resource utilization.

Core design:

• The consensus process (consensus layer) is only responsible for ordering transactions, not executing contract logic.

• The execution process (execution layer) is triggered asynchronously after consensus is completed.

• After consensus is completed, it immediately enters the next block consensus process without waiting for execution to finish.

Optimistic Parallel Execution: 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 increasing transaction processing speed.

Execution mechanism:

• Monad optimistically executes all transactions in parallel, assuming that most transactions do not have state conflicts.

• Simultaneously runs a "Conflict Detector" to monitor whether transactions access the same state (e.g., read/write conflicts).

• If a conflict is detected, conflicting transactions are serialized and re-executed to ensure state correctness.

Monad chooses a compatibility path: making minimal changes to EVM rules, achieving parallelism during execution by delaying state writes and dynamically detecting conflicts, resembling a performance-enhanced Ethereum. Its maturity facilitates easy migration of the EVM ecosystem, acting as a parallel accelerator in the EVM world.

Analysis of MegaETH's Parallel Computing Mechanism

Unlike Monad's L1 positioning, 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 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 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 "intra-chain threading."

Micro-VM Architecture: Accounts as Threads

MegaETH introduces an execution model where "each account is a micro virtual machine (Micro-VM)," threading the execution environment and providing the minimal isolation unit for parallel scheduling. These VMs communicate through asynchronous messaging rather than synchronous calls, allowing many VMs to execute and store independently, naturally achieving parallelism.

State Dependency DAG: Dependency Graph-Driven Scheduling Mechanism

MegaETH builds a DAG scheduling system based on account state access relationships, maintaining a global dependency graph in real-time. Each transaction modifies which accounts and reads from which accounts, all modeled as dependency relationships. Non-conflicting transactions can be executed in parallel, while dependent transactions will be scheduled in serial or delayed according to topological order. The dependency graph ensures state consistency and non-redundant writing during the parallel execution process.

Asynchronous Execution and Callback Mechanism

MegaETH is built on the asynchronous programming paradigm, similar to the Actor Model's asynchronous message passing, solving the traditional EVM serial call problem. Contract calls are asynchronous (non-recursive execution); when calling contract A -> B -> C, each call is asynchronous, requiring no blocking wait; the call stack is expanded into an asynchronous call graph; transaction processing = traversing the asynchronous graph + dependency resolution + parallel scheduling.

In summary, MegaETH breaks the traditional EVM single-threaded state machine model, encapsulating accounts as micro virtual machines, scheduling transactions through the state dependency graph, and replacing synchronous call stacks with asynchronous messaging mechanisms. It is a parallel computing platform redesigned across "account structure → scheduling architecture → execution process," providing a paradigm-level new idea for building the next generation of high-performance on-chain systems.

MegaETH chooses a reconstruction path: thoroughly abstracting accounts and contracts into independent VMs, releasing extreme parallel potential through asynchronous execution scheduling. Theoretically, MegaETH has a higher parallel ceiling but is also more challenging to control complexity, resembling a super distributed operating system under the Ethereum concept.

The design philosophies of Monad and MegaETH differ significantly from sharding: sharding horizontally divides the blockchain into multiple independent sub-chains (shards), with each sub-chain responsible for a portion of transactions and states, breaking the single-chain limitation for network layer scalability. In contrast, both Monad and MegaETH maintain the integrity of a single chain, only horizontally scaling at the execution layer, optimizing for extreme parallel execution within a single chain to break performance barriers. The two represent vertical reinforcement and horizontal expansion in the blockchain scaling path.

Projects like Monad and MegaETH focus primarily on throughput optimization, aiming to enhance on-chain TPS as the core goal, achieving 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 known as "Rollup Mesh." This architecture supports multi-virtual machine environments (EVM and Wasm) through the collaboration of the mainnet and Special Processing Networks (SPNs), integrating 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 transactions (such as consensus, execution, storage) and adopts asynchronous processing, allowing each stage to operate 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 based on their needs. This dual VM architecture not only enhances system flexibility but also improves transaction processing capabilities through parallel execution.

3. Special Processing Networks (SPNs): SPNs are key components of the Pharos architecture, similar to modular sub-networks, specifically designed to handle certain types of tasks or applications. Through SPNs, Pharos can achieve dynamic resource allocation and parallel task processing, further enhancing the system's scalability and performance.

4. Modular Consensus & Restaking: Pharos introduces a flexible consensus mechanism that supports various consensus models (such as PBFT, PoS, PoA) and achieves secure sharing and resource integration between the mainnet and SPNs through a restaking protocol.

Additionally, Pharos reconstructs the execution model from the storage engine's bottom layer using multi-version Merkle trees, delta encoding, versioned addressing, and ADS pushdown technology, launching a native blockchain high-performance storage engine, Pharos Store, to achieve high throughput, low latency, and strong verifiable on-chain processing capabilities.

In summary, Pharos's Rollup Mesh architecture achieves high-performance parallel computing capabilities through modular design and asynchronous processing mechanisms. Pharos acts as a scheduling coordinator for cross-Rollup parallelism, not merely an execution optimizer for "intra-chain parallelism," but rather as a carrier of heterogeneous custom execution tasks through SPNs.

In addition to the parallel execution architectures of Monad, MegaETH, and Pharos, we also observe some projects exploring the application of GPU acceleration in EVM parallel computing, serving as important supplements and frontier experiments for the EVM parallel ecosystem. Among them, Reddio and GatlingX are two representative directions:

• Reddio is a high-performance platform that combines zkRollup with a GPU parallel execution architecture. Its core lies in reconstructing the EVM execution process through multi-threaded scheduling, asynchronous state storage, and GPU-accelerated execution of transaction batches, achieving native parallelization at the execution layer. It belongs to transaction-level + operation-level (multi-threaded execution of opcodes) parallel granularity. Its design introduces multi-threaded batch execution, asynchronous state loading, and GPU parallel processing of transaction logic (CUDA-Compatible Parallel EVM). Like Monad and MegaETH, Reddio also focuses on parallel processing at the execution layer, but differs by reconstructing the execution engine through a GPU parallel architecture, specifically designed for high throughput and compute-intensive scenarios (such as AI inference). It has launched an SDK that provides an integrable execution module.

• GatlingX claims to be "GPU-EVM," proposing a more radical architecture that attempts to migrate the traditional EVM virtual machine's "instruction-level serial execution" model to a GPU-native parallel runtime environment. Its core mechanism dynamically compiles EVM bytecode into CUDA parallel tasks, executing instruction streams through GPU multi-core execution, thereby breaking the sequential bottleneck of the EVM at the lowest level. It belongs to instruction-level (Instruction-Level Parallelism, ILP) parallel granularity. Compared to the "transaction-level / account-level" parallel granularity of Monad and MegaETH, GatlingX's parallel mechanism is closer to instruction-level optimization paths, more akin to the underlying reconstruction of the virtual machine engine. It is currently in the conceptual stage, having released a white paper and architectural sketches, but lacks an SDK or mainnet.

Artela proposes a differentiated parallel design philosophy. By introducing the EVM++ architecture WebAssembly (WASM) virtual machine, it allows developers to maintain EVM compatibility while using the Aspect programming model to dynamically add and execute extensions on-chain. Its minimum parallel unit is the contract call granularity (Function / Extension), supporting the injection of Extension modules (similar to "pluggable middleware") into EVM contracts at runtime, achieving logical decoupling, asynchronous calls, and module-level parallel execution. It focuses more on the composability and modular architecture of the execution layer, providing new ideas for future complex multi-module applications.

### 3. Native Parallel Architecture Chains: Reconstructing the Execution Ontology of the VM

The EVM execution model of Ethereum has adopted a "total ordering of transactions + serial execution" single-threaded architecture since its design inception, aiming to ensure the determinism and consistency of state changes across all nodes in the network. However, this architecture has inherent performance bottlenecks that limit system throughput and scalability. In contrast, native parallel computing architecture chains like Solana (SVM), MoveVM (Sui, Aptos), and Sei v2 built on the Cosmos SDK are designed from the ground up for parallel execution, offering the following advantages:

• Naturally Separated State Models: Solana employs an account lock declaration mechanism, MoveVM introduces an object ownership model, and Sei v2 categorizes based on transaction types to achieve static conflict determination, supporting transaction-level concurrent scheduling.

• VM 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 parallel VM modules.

Of course, these native parallel chains also face challenges in ecological compatibility. Non-EVM architectures typically require entirely new development languages (such as Move, Rust) and toolchains, presenting a certain migration cost for developers; additionally, developers must grasp a series of new concepts such as state access models, concurrency limitations, and object lifecycles, raising the understanding threshold and imposing higher demands on development paradigms.

3.1 Principles of Solana and SVM's Sealevel Parallel Engine

Solana's Sealevel execution model is an account parallel scheduling mechanism, serving as the core engine for Solana to achieve on-chain parallel transaction execution. It implements high-performance concurrency at the smart contract level through "account declaration + static scheduling + multi-threaded execution." 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 Layer 1 parallel design.

Core mechanisms:

1. Explicit Account Access Declarations: Each transaction must declare the accounts it involves (read/write) upon submission, allowing the system to determine whether there are state conflicts between transactions.

2. Conflict Detection and Multi-threaded Scheduling:

• If the sets of accounts accessed by two transactions have no intersection → they can be executed in parallel;
• If there is a conflict → they are executed serially according to dependency order;
• The scheduler allocates transactions to different threads based on the dependency graph.

1. Independent Execution Contexts: Each contract call runs in an isolated context, with no shared stack, avoiding cross-call interference.

Sealevel is Solana's parallel execution scheduling engine, while SVM is the smart contract execution environment built on 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 the Solana VM onto modular chains (such as Ethereum L2 or Celestia), utilizing Solana's parallel execution engine as the Rollup execution layer. Eclipse is one of the first projects to propose detaching the Solana execution layer (Sealevel + SVM) from the Solana mainnet and migrating it to a modular architecture, modularizing Solana's "super strong concurrent execution model" as Execution Layer-as-a-Service, thus Eclipse also belongs to the category of parallel computing.

Neon takes a different route, introducing EVM to run in the SVM/Sealevel environment. It builds a compatible EVM runtime layer, allowing developers to use Solidity to develop contracts and run them in the SVM environment, but the scheduling execution uses SVM + Sealevel. Neon leans more towards the modular blockchain category and does not emphasize innovations in parallel computing.

In summary, Solana and SVM rely on the Sealevel execution engine, with Solana's operating system-like scheduling philosophy resembling a kernel scheduler, executing quickly but with relatively low flexibility. 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. Its core language, Move, was originally developed by Meta (formerly Facebook) for the Libra project, emphasizing the concept of "resources as objects," where all on-chain states exist as objects with clear ownership and lifecycles. This allows MoveVM to analyze whether there are state conflicts between transactions at compile time, enabling object-level static parallel scheduling, widely applied in native parallel blockchains like Sui and Aptos.

Sui's Object Ownership Model

Sui's parallel computing capability stems from its unique state modeling approach and language-level static analysis mechanism. Unlike traditional blockchains that use a global state tree, Sui constructs an object-centric state model, combined with MoveVM's linear type system, making parallel scheduling a deterministic process that can be completed at compile time.

• Object Model: The foundation of Sui's parallel architecture. Sui abstracts all on-chain states as independent objects, each with a unique ID, clear owner (account or contract), and type definition. These objects do not share state, providing natural isolation. Contracts must explicitly declare the set of objects involved when calling, avoiding the state coupling issues of traditional "global state trees." This design segments on-chain states into several independent units, making concurrent execution structurally feasible for scheduling.

• Static Ownership Analysis: This is a compile-time analysis mechanism enabled by the linear type system of the Move language. It allows the system to deduce which transactions will not produce state conflicts based on object ownership before execution, thus scheduling them for parallel execution. Compared to traditional runtime conflict detection and rollback, Sui's static analysis mechanism significantly enhances execution efficiency while greatly reducing scheduling complexity, which is key to achieving high throughput and deterministic parallel processing capabilities.

Sui divides the state space by objects and combines compile-time ownership analysis to achieve low-cost, rollback-free object-level parallel execution. Compared to the serial execution or runtime detection of traditional chains, Sui has made significant improvements in execution efficiency, system determinism, and resource utilization.

Aptos's Block-STM Execution Mechanism

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

Block-STM divides the execution of a block's transactions into three phases:

• Optimistic Concurrent Execution: All transactions are assumed to have no conflicts before execution, and the system parallelly schedules transactions to multiple threads for concurrent execution while recording the accessed account states (read set / write set).

• Conflict Detection and Validation: The system verifies the execution results: if two transactions have read-write conflicts (e.g., Tx1 reads a state written by Tx2), one of them is rolled back.

• Conflicted Transaction Rollback and Retry: Conflicted transactions are rescheduled for execution until their dependencies are resolved, ultimately forming a valid and deterministic state submission sequence for all transactions.

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, serving as the core of Aptos's high versatility and high throughput public chain.

Solana is more of an engineering scheduling faction, resembling an "operating system kernel," suitable for clearly defined state boundaries and controllable high-frequency trading, embodying a hardware engineer style that aims for hardware-grade parallel execution; Aptos is more of a system fault-tolerant faction, akin to a "database concurrency engine," suitable for contract systems with strong state coupling and complex call chains; Sui is more of a compile-safe faction, resembling a "resource-oriented smart language platform," suitable for asset separation and clearly defined combinations in on-chain applications. Aptos and Sui aim to operate chains as software engineers, ensuring software-grade resource security. The three represent different philosophical paths for the technical implementation of Web3 parallel computing.

3.3 Cosmos SDK Parallel Expansion Type

Sei V2 is a high-performance transaction-oriented public chain built on the Cosmos SDK, with its parallel capabilities primarily reflected in two aspects: a multi-threaded matching engine and parallel execution optimization at the virtual machine layer, aimed at serving high-frequency, low-latency on-chain trading scenarios, such as order book DEXs and on-chain exchange infrastructure.

Core parallel mechanisms:

1. Parallel Matching Engine: Sei V2 introduces multi-threaded execution paths in its order matching logic, splitting the order book and matching logic at the thread level, allowing matching tasks between multiple markets (trading pairs) to be processed in parallel, avoiding single-thread bottlenecks.

2. Virtual Machine-Level Concurrency Optimization: Sei V2 constructs a CosmWasm runtime environment with concurrent execution capabilities, allowing some contract calls to run in parallel under the condition of no state conflicts, combined with a transaction type classification mechanism to achieve higher throughput control.

3. Parallel Consensus with Execution Layer Scheduling: The introduction of the so-called "Twin-Turbo" consensus mechanism strengthens the decoupling of throughput between the consensus layer and the execution layer, enhancing overall block processing efficiency.

3.4 UTXO Model Reconstructor Fuel

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

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

The Actor Model is a parallel execution paradigm based on agent processes (Agent or Process) as units, differing from traditional synchronous computation of global states on-chain (such as Solana/Sui/Monad in "on-chain parallel computing" scenarios). It emphasizes that each agent has independent states and behaviors, communicating and scheduling through asynchronous messages. In this architecture, on-chain systems can run concurrently with a large number of decoupled processes, possessing 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 execution engines to "on-chain operating systems," providing native infrastructure for AI agents, multi-task interactions, and complex logic orchestration.

Although the design of the Actor Model shares certain surface characteristics (such as parallelism, state isolation, and asynchronous processing) with sharding, they fundamentally represent completely different technical paths and system philosophies. The Actor Model emphasizes "multi-process asynchronous computation," where each agent (Actor) runs independently and maintains its state, interacting through message-driven methods; whereas sharding is a mechanism of "horizontal division of state and consensus," dividing the entire blockchain into multiple independent subsystems (shards) that process transactions. The Actor Model resembles a "distributed agent operating system" in the Web3 world, while sharding is a structural expansion solution for on-chain transaction processing capabilities. Both achieve parallelism, but their starting points, goals, and execution architectures differ.

4.1 AO (Arweave), A Super Parallel Computer Above the Storage Layer

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

Core architectural features:

• Process Architecture: Each agent is referred to as a Process, possessing independent states, independent schedulers, and execution logic.

• No Blockchain Structure: AO is not a chain but is based on Arweave's decentralized storage layer + multi-agent message-driven execution engine.

• Asynchronous Message Scheduling System: Processes communicate through messages, adopting a lock-free asynchronous running model that naturally supports 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, automated task orchestrators, etc.), enabling the construction of "on-chain AI Coprocessors."

AO follows an extreme "agent-native + storage-driven + no-chain architecture" route, emphasizing flexibility and modular decoupling, serving as an "on-chain microkernel framework built on the storage layer," with intentionally narrowed system boundaries, emphasizing lightweight computation and composable control structures.

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, aiming to extend on-chain computing capabilities to a Web2-like experience while supporting complete service hosting, domain binding, and serverless architecture.

Core architectural features:

• Canister Architecture (Canister as Agent): Each Canister is an agent running on the Wasm VM, possessing independent state, code, and asynchronous scheduling capabilities;

• Subnet Distributed Consensus System: The entire network consists of multiple Subnets, each maintaining a set of Canisters and reaching consensus through the BLS signature mechanism;

• Asynchronous Call Model: Canisters communicate with each other through asynchronous messages, supporting non-blocking execution and possessing natural parallelism;

• On-chain Web Hosting: Supports smart contracts to directly host front-end pages, with native DNS mapping, making it the first blockchain platform to support direct browser access to dApps;

• Fully Functional System: Equipped with on-chain hot upgrades, identity authentication, distributed randomness, timers, and other system APIs, suitable for complex on-chain service deployments.

ICP adopts an operating system paradigm of platform re-architecture, integrated packaging, and strong platform control, featuring an integrated "blockchain operating system" for consensus, execution, storage, and access, emphasizing complete service hosting capabilities, expanding the system boundary into a full-stack Web3 hosting platform.

Additionally, other parallel computing projects based on the Actor Model paradigm can refer to the table below:

### 5. Summary and Outlook

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

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

• Monad: Achieves an optimistic parallel execution model compatible with EVM through delayed writes and runtime conflict detection, constructing a dependency graph and multi-threaded scheduling after consensus completion.

• MegaETH: Abstracts each account/contract as an independent micro virtual machine (Micro-VM), achieving highly decoupled account-level parallel scheduling based on asynchronous messaging and state dependency graphs.

• Pharos: Constructs a Rollup Mesh architecture, achieving system-level parallel processing across processes through asynchronous pipelines and SPN modules.

• Reddio: Adopts a zkRollup + GPU architecture, focusing on accelerating the off-chain verification process of zkEVM through batch SNARK generation, enhancing verification throughput.

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

• Solana (SVM Series): Based on account access declarations and static conflict graph scheduling, representing an account-level parallel execution model;

• Sui / Aptos (MoveVM Series): Based on a resource object model and type system, supporting compile-time static analysis to achieve object-level parallelism;

• Sei V2 (Cosmos SDK Route): Introduces a multi-threaded matching engine and virtual machine concurrency optimization within the Cosmos architecture, suitable for transaction-oriented high-frequency applications;

• Fuel (UTXO + Sway Architecture): Achieves transaction-level parallelism through static analysis of UTXO input sets, combined with a modular execution layer and a customized smart contract language, Sway.

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

• AO (Arweave AO): Constructs an on-chain asynchronous microkernel system based on a permanent storage-driven agent runtime;

• ICP (Internet Computer): Uses containerized agents (Canisters) as the smallest unit, achieving asynchronous high-scalability execution through subnet coordination;

• Cartesi: Introduces the Linux operating system as an off-chain computing environment, providing a verification path for trusted computing results on-chain, suitable for complex or resource-intensive application scenarios.

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

From a broader perspective on scalability, sharding and rollups (L2) focus on achieving horizontal system expansion through state partitioning 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 at the chain or system level. The former enhances on-chain throughput through multi-threaded virtual machines, object models, transaction conflict analysis, etc.; the latter uses processes/agents as basic units, employing message-driven and asynchronous execution methods to achieve concurrent operation of multiple agents. In contrast, sharding and rollups resemble "distributing the load across multiple chains" or "outsourcing to off-chain," while parallel chains and Actor models release performance potential from the execution engine itself, reflecting a more thorough architectural evolution direction.

Comparison of Parallel Computing vs. Sharding Architecture vs. Rollup Scalability vs. Actor Oriented Expansion Paths

It is important to note that most native parallel architecture chains have entered the mainnet launch stage. Although the overall developer ecosystem is still difficult to compare with the EVM-based Solidity system, projects represented by Solana and Sui, with their high-performance execution architecture and gradually flourishing ecological applications, have become core public chains of high market attention.

In contrast, although the Ethereum rollup (L2) ecosystem has entered a stage of "thousands of chains launching" or even "overcapacity," the current mainstream EVM-based parallel enhancement chains generally remain in the testnet stage, yet to undergo actual verification in the mainnet environment, and their scalability and system stability still require further testing. Whether these projects can significantly enhance EVM performance without sacrificing compatibility, promote ecological leaps, or instead exacerbate the further differentiation of Ethereum's liquidity and development resources remains to be seen over time.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。