The Future of Expansion: A Panorama of the Web3 Parallel Computing Track

Written by: 0xjacobzhao and ChatGPT 4o

The "Blockchain Trilemma" of blockchain, which includes "Security," "Decentralization," and "Scalability," reveals the essential trade-offs in the design of blockchain systems, meaning that it is challenging for blockchain projects to achieve "extreme security, universal participation, and high-speed processing" simultaneously. 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 concurrency scaling: Actor model, process isolation, message-driven, such as agents, multi-threaded asynchronous chains

Blockchain scaling solutions include: on-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 the mainstream scaling method based on parallel computing.

On-chain parallel computing (intra-chain parallelism) 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 increasing scheduling complexity, 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 concurrency model, represented by the Actor agent 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 concurrency mechanisms and do not fall under on-chain parallel computing. They achieve scaling by "running multiple chains / execution domains in parallel" rather than enhancing the parallelism within a single block / virtual machine. Although these scaling solutions are not the focus of this article, we will still use them for comparative analysis of architectural concepts.

## II. EVM-based 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 still not been fundamentally broken. Meanwhile, EVM and Solidity remain the most developer-friendly and ecologically potent smart contract platforms today. Therefore, EVM-based 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 from the perspectives of delayed execution and state decomposition.

Analysis of Monad's Parallel Computing Mechanism

Monad is a high-performance Layer 1 blockchain redesigned for the Ethereum Virtual Machine (EVM), based on the fundamental parallel concept of pipelining, with asynchronous execution at the consensus layer and optimistic parallel execution at the execution layer. Additionally, 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 process these stages in parallel, forming a three-dimensional pipeline architecture. Each stage runs on independent threads or cores, achieving cross-block concurrent processing, ultimately improving throughput and reducing latency. These stages include: transaction proposal (Propose), consensus achievement (Consensus), transaction execution (Execution), and block submission (Commit).

Asynchronous Execution: Decoupling Consensus and Execution

In traditional chains, transaction consensus and execution are usually synchronous processes, and this serial model severely limits performance scaling. Monad achieves asynchronous consensus, asynchronous execution, and asynchronous 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 completion.
• After consensus completion, 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. Monad adopts an "optimistic parallel execution" strategy, significantly increasing transaction processing rates.

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 has chosen a compatibility path: changing EVM rules as little as possible, achieving parallelism during execution by delaying state writes and dynamically detecting conflicts, making it more like a performance version of Ethereum, with good maturity and ease of EVM ecological migration, serving as a parallel accelerator in the EVM world.

Analysis of MegaETH's Parallel Computing Mechanism

Unlike Monad's Layer 1 positioning, MegaETH is positioned as a modular high-performance parallel execution layer compatible with EVM, which can serve as an independent Layer 1 public chain or as an execution enhancement layer (Execution 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 "in-chain threading."

Micro-VM Architecture: Each Account as a Thread

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 parallel.

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, modeling which accounts are modified and read by each transaction 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-repetitive 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's serial call issues. Contract calls are asynchronous (non-recursive execution), and when calling contract A -> B -> C, each call is made asynchronously without blocking; the call stack is expanded into an asynchronous call graph (Call Graph); transaction processing = traversing the asynchronous graph + dependency resolution + parallel scheduling.

In summary, MegaETH breaks the traditional EVM single-thread state machine model, achieving micro virtual machine encapsulation at the account level, 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 has chosen a reconstruction path: thoroughly abstracting accounts and contracts into independent VMs, releasing extreme parallel potential through asynchronous execution scheduling. Theoretically, MegaETH's parallel ceiling is higher but also more challenging to control complexity, resembling a super distributed operating system under the Ethereum philosophy.

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

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 delayed execution and micro virtual machine architecture. Pharos Network, as a modular, full-stack parallel Layer 1 blockchain network, features a core parallel computing mechanism known as "Rollup Mesh." This architecture supports multi-virtual machine environments (EVM and Wasm) through the collaboration of the main network and special processing networks (SPNs), integrating advanced technologies such as zero-knowledge proofs (ZK) and trusted execution environments (TEE).

Rollup Mesh Parallel Computing Mechanism Analysis:

1. Full Lifecycle Asynchronous Pipelining: Pharos decouples various stages of transaction processing (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 processing of tasks, further enhancing the system's scalability and performance.
4. Modular Consensus and Restaking Mechanism: 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 main network and SPNs through a restaking protocol.

Additionally, Pharos reconstructs the execution model from the storage engine level using multi-version Merkle trees, delta encoding, versioned addressing, and ADS pushdown technologies, 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 serves as a scheduling coordinator for cross-Rollup parallelism, not merely as an "on-chain parallel" execution optimizer, but rather as a platform for 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 paths 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 GPU parallel execution architecture, focusing on 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 represents transaction-level + operation-level (multi-threaded execution of opcode) 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 / MegaETH, Reddio also focuses on parallel processing at the execution layer, with the difference being that it reconstructs 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, providing 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 execution environment. Its core mechanism dynamically compiles EVM bytecode into CUDA parallel tasks, executing instruction streams through GPU multi-core, thereby breaking the sequential bottleneck of EVM at the lowest level. It represents instruction-level (Instruction-Level Parallelism, ILP) parallel granularity. Compared to the "transaction-level / account-level" parallel granularity of Monad / MegaETH, GatlingX's parallel mechanism belongs to the instruction-level optimization path, closer to the underlying reconstruction of the virtual machine engine. It is currently in the conceptual stage, with a white paper and architectural sketch released, but no SDK or mainnet yet.

Artela proposes a differentiated parallel design philosophy. By introducing the EVM++ architecture WebAssembly (WASM) virtual machine, it allows developers to dynamically add and execute extensions on-chain while maintaining EVM compatibility, using the aspect programming model. Its minimum parallel unit is the contract call granularity (Function / Extension), supporting the injection of Extension modules (similar to "pluggable middleware") into the EVM contract 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.

## III. Native Parallel Architecture Chains: Reconstructing the Execution Ontology of VMs

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 determinacy and consistency of state changes across all nodes in the network. However, this architecture has inherent performance bottlenecks, 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 designed from the ground up for parallel execution, possessing the following advantages:

• State models are inherently separated: Solana adopts an account lock declaration mechanism, MoveVM introduces an object ownership model, and Sei v2 categorizes based on transaction types, achieving static conflict determination and supporting transaction-level concurrent scheduling.
• Virtual machines are optimized for concurrency: Solana's Sealevel engine natively supports multi-threaded execution; MoveVM can perform static concurrency graph analysis; Sei v2 integrates multi-threaded matching engines 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 limits, and object lifecycles, raising the understanding threshold and development paradigm requirements.

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, through "account declaration + static scheduling + multi-threaded execution" mechanisms, achieving high-performance concurrency at the smart contract level. 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 declaration (Account Access Lists): 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 account sets 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 context (Program Invocation Context): 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 on 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 also belonging 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 rather than emphasizing 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 initially 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, achieving object-level static parallel scheduling, widely applied in native parallel public chains 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 a state model based on "objects" (Object-centric 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 during calls, 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 as a scheduling prerequisite.
• Static Ownership Analysis: This is a compile-time analysis mechanism implemented with the support of Move's linear type system. It allows the system to infer which transactions will not produce state conflicts through 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 achieves significant improvements in execution efficiency, system determinacy, 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 tendency towards "compile-time static parallel" strategies, Block-STM employs a "runtime optimistic concurrency + conflict rollback" dynamic scheduling mechanism, suitable for handling transaction sets with complex dependencies.

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

• Optimistic Concurrent Execution: All transactions are assumed to be conflict-free before execution, and the system concurrently schedules transactions to multiple threads for execution attempts, recording the accessed account states (read set / write set).
• Conflict Detection and Validation Phase: The system verifies the execution results: if two transactions have read/write conflicts (e.g., Tx1 reads a state written by Tx2), one will be rolled back.
• Conflicting Transaction Rollback and Retry Phase: Conflicting transactions will be rescheduled for execution until their dependencies are resolved, ultimately forming a valid and deterministic state submission sequence for all transactions.

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

Solana is an engineering scheduling faction, more like an "operating system kernel," suitable for clear state boundaries and controllable high-frequency trading, embodying a hardware engineering style, aiming to run chains like hardware (Hardware-grade parallel execution); Aptos is a system fault-tolerant faction, resembling a "database concurrency engine," suitable for contract systems with strong state coupling and complex call chains; Sui is a compile-safe faction, more like a "resource-oriented smart language platform," suitable for on-chain applications with asset separation and clear combinations, with Aptos and Sui aiming to run chains safely like software (Software-grade resource security). The three represent different technical implementation paths for Web3 parallel computing under different philosophies.

3.3 Cosmos SDK Parallel Expansion Type

Sei V2 is a high-performance trading public chain built on the Cosmos SDK, with its parallel capabilities primarily reflected in two aspects: a multi-threaded matching engine (Parallel 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 DEX and on-chain exchange infrastructure.

Core parallel mechanisms:

1. Parallel Matching Engine: Sei V2 introduces multi-threaded execution paths in its order matching logic, performing thread-level separation of the order book and matching logic, 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 builds a CosmWasm runtime environment with concurrent execution capabilities, allowing some contract calls to run in parallel under the premise of no state conflicts, and implementing higher throughput control through transaction type classification mechanisms.
3. Parallel Consensus Combined with Execution Layer Scheduling: Introduces the so-called "Twin-Turbo" consensus mechanism, enhancing the throughput decoupling between the consensus layer and execution layer, improving 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 stemming 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 a self-developed smart contract language, Sway (similar to Rust), and combines static analysis tools to determine input conflicts before transaction execution, thus achieving efficient and safe transaction-level parallel scheduling. It is a performance-oriented and modular EVM alternative execution layer.

## IV. 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 "on-chain parallel computing" scenarios like Solana/Sui/Monad), emphasizing that each agent has independent states and behaviors, communicating and scheduling through asynchronous messages. In this architecture, on-chain systems can run concurrently with numerous decoupled processes, possessing strong scalability and asynchronous fault tolerance capabilities. 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, asynchronous processing) with sharding, they fundamentally represent entirely 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; while sharding is a mechanism for "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 the Arweave 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 called a Process, possessing independent states, independent schedulers, and execution logic;
• No blockchain structure: AO is not a chain but a decentralized storage layer based on Arweave + a multi-agent message-driven execution engine;
• Asynchronous message scheduling system: Processes communicate through messages, adopting a lock-free asynchronous running model, naturally supporting 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.), capable of building "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," intentionally shrinking system boundaries and emphasizing lightweight computation + 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 and support complete service hosting, domain binding, and serverless architecture.

Core architectural features:

• Canister architecture (containers as agents): Each Canister is an agent running on a Wasm VM, possessing independent states, code, and asynchronous scheduling capabilities;
• Subnet distributed consensus system: The entire network consists of multiple Subnets, each maintaining a group of Canisters and reaching consensus through BLS signature mechanisms;
• Asynchronous calling model: Canisters communicate with each other through asynchronous messages, supporting non-blocking execution and possessing natural parallelism;
• On-chain web hosting: Supports direct hosting of front-end pages by smart contracts, 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 strong platform control, one-piece encapsulation, and re-platforming, integrating consensus, execution, storage, and access into a "blockchain operating system," emphasizing complete service hosting capabilities and expanding system boundaries into a full-stack Web3 hosting platform.

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

## V. Conclusion and Outlook

Based on the differences in virtual machine architectures 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 ecological 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 a compatible EVM optimistic parallel execution model through delayed writing and runtime conflict detection, building a dependency graph and multi-threaded scheduling execution 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 limitations of Ethereum compatibility, redesigning execution paradigms from virtual machines, state models, and scheduling mechanisms to achieve native high-performance concurrency capabilities. Typical subclasses include:

• Solana (SVM series): Represents an account-level parallel execution model based on account access declarations and static conflict graph scheduling;
• Sui / Aptos (MoveVM series): Supports compile-time static analysis based on resource object models and type systems, achieving object-level parallelism;
• Sei V2 (Cosmos SDK route): Introduces multi-threaded matching engines and virtual machine concurrency optimizations in the Cosmos architecture, suitable for high-frequency trading applications;
• Fuel (UTXO + Sway architecture): Achieves transaction-level parallelism through static analysis of UTXO input sets, combining a modular execution layer with a customized smart contract language Sway;

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

• AO (Arweave AO): Builds an on-chain asynchronous microkernel system based on permanent storage-driven smart agent runtime;
• ICP (Internet Computer): Achieves asynchronous high-scalability execution through containerized agents (Canister) as the minimum unit, coordinated by subnets;
• Cartesi: Introduces the Linux operating system as an off-chain computing environment, providing on-chain verification paths for trusted computing results, 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 (Sharding) and Rollup (L2) focus on achieving horizontal system expansion through state division or off-chain execution, while parallel computing chains (such as Monad, Sui, Solana) and Actor Oriented systems (such as AO, ICP) directly reconstruct execution models, achieving 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 Rollup are more like "splitting the load across multiple chains" or "outsourcing to off-chain," while parallel chains and Actor models are about "releasing 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 particularly noteworthy 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 architectures and gradually flourishing ecological applications, have become core public chains of high market attention.

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