The “Blockchain Trilemma” reveals the essential trade-offs in the design of blockchain systems, namely the difficulty of achieving “ultimate 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 according to paradigms, including:

• Execute enhanced scalability: Improve execution capabilities on the spot, such as parallelism, GPU, and multi-core.
• State-isolated expansion: horizontal partitioning of state / Shard, such as sharding, UTXO, multi-subnet
• Off-chain outsourcing scaling: executing outside the chain, such as Rollup, Coprocessor, DA
• Decoupled structure expansion: modular architecture, collaborative operation, such as module chains, shared sorters, Rollup Mesh.
• Asynchronous concurrent scaling: Actor model, process isolation, message-driven, such as agents, multithreaded 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 layers of execution, state, data, and structure, forming a “multi-layered collaboration and modular combination” complete scaling system. This article focuses on the mainstream scaling method based on parallel computing.

Intra-chain parallelism focuses on the parallel execution of transactions/instructions within the block. According to the parallel mechanism, its scaling methods can be divided into five categories, each representing different performance pursuits, development models, and architectural philosophies. The granularity of parallelism becomes finer, the intensity of parallelism increases, the complexity of scheduling rises, and the programming complexity and implementation difficulty also increase.

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

The off-chain asynchronous concurrent model, represented by the Actor system (Agent / Actor Model), belongs to another parallel computing paradigm. As a cross-chain / asynchronous messaging system (non-block synchronization model), each Agent operates as an independently running “agent process,” asynchronously messaging in a parallel manner, event-driven, and without the need for synchronized scheduling. Notable projects include AO, ICP, Cartesi, etc.

The well-known Rollup or sharding scalability solutions belong to system-level concurrency mechanisms and do not fall under on-chain parallel computation. They achieve scalability by “running multiple chains/execution domains in parallel” rather than enhancing the parallelism within a single block/virtual machine. Such scalability solutions are not the focus of this article, but we will still use them for a comparative analysis of architectural concepts.

2. EVM-based Parallel Enhanced Chain: Breaking Performance Boundaries through Compatibility

The serial processing architecture of Ethereum has developed through multiple rounds of expansion attempts, including sharding, Rollup, and modular architecture. However, the throughput bottleneck of the execution layer has still not been fundamentally broken through. Meanwhile, EVM and Solidity remain the most developer-friendly and ecologically potent smart contract platforms today. Therefore, EVM-based parallel-enhanced chains are becoming an important direction for the next round of scalability evolution, balancing ecological compatibility and execution performance improvement. Monad and MegaETH are the most representative projects in this direction, respectively building EVM parallel processing architectures aimed at high concurrency and high throughput scenarios, starting from delayed execution and state decomposition.

Analysis of Monad’s Parallel Computing Mechanism

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

Asynchronous Execution: Consensus - Asynchronous Decoupling
In traditional blockchains, transaction consensus and execution are typically synchronous processes, and this serial model severely limits performance scaling. Monad achieves asynchronous consensus layer, asynchronous execution layer, and asynchronous storage through “asynchronous execution.” This significantly reduces block time and confirmation delays, making the system more resilient, processing flows more granular, and resource utilization higher.

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 the consensus is completed.
• After the consensus is completed, immediately enter the consensus process for the next block without waiting for execution to finish.

Optimistic Parallel Execution
Traditional Ethereum uses a strict serial model for transaction execution to avoid state conflicts. In contrast, Monad employs an “optimistic parallel execution” strategy, significantly enhancing transaction processing speed.

Execution mechanism:

• Monad will optimistically execute all transactions in parallel, assuming that most transactions have no state conflicts.
• At the same time, run a “Conflict Detector” to monitor whether transactions are accessing the same state (such as read/write conflicts).
• If a conflict is detected, conflicting transactions will be serialized and re-executed to ensure state correctness.

Monad chooses a compatible path: making as few changes to the EVM rules as possible, achieving parallelism by deferring state writes and dynamically detecting conflicts during execution, resembling a performance version of Ethereum. Its maturity facilitates easy migration of the EVM ecosystem and serves as a parallel accelerator in the EVM world.

Analysis of MegaETH’s Parallel Computing Mechanism

Unlike the L1 positioning of Monad, MegaETH is positioned as a modular high-performance parallel execution layer compatible with EVM, which can serve as an independent L1 public chain or as an execution enhancement layer on Ethereum or as a modular component. Its core design goal is to isolate and deconstruct account logic, execution environment, and state into independently schedulable minimal units to achieve high concurrent execution and low-latency response capabilities on-chain. The key innovations proposed by MegaETH are: Micro-VM architecture + State Dependency DAG (Directed Acyclic Graph of State Dependencies) and modular synchronization mechanism, which together construct a parallel execution system oriented towards “on-chain threading.”

Micro-VM architecture: Account is a thread
MegaETH introduces the execution model of “one micro virtual machine (Micro-VM) per account”, which thread-izes the execution environment and provides the smallest isolation unit for parallel scheduling. These VMs communicate through asynchronous messaging instead of synchronous calls, allowing a large number of VMs to execute independently and store independently, enabling natural parallelism.

State Dependency DAG: A scheduling mechanism driven by dependency graphs
MegaETH has built a DAG scheduling system based on account state access relationships. The system maintains a global Dependency Graph in real-time, modeling which accounts are modified and which accounts are read during each transaction as dependencies. Non-conflicting transactions can be executed in parallel, while transactions with dependencies will be scheduled in order or deferred according to a topological sequence. 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, addressing the issues of traditional EVM serial calls. 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-threaded state machine model by implementing micro virtual machine encapsulation on an account basis, scheduling transactions through a state dependency graph, and using an asynchronous message mechanism instead of a synchronous call stack. It is a parallel computing platform that is redesigned in all dimensions from “account structure → scheduling architecture → execution flow,” providing a paradigm-level new approach for building the next generation of high-performance on-chain systems.

MegaETH has chosen a reconstruction path: completely abstracting accounts and contracts into an independent VM, and releasing extreme parallel potential through asynchronous execution scheduling. Theoretically, MegaETH’s parallel limit is higher, but it is also more difficult to control complexity, resembling a super distributed operating system under the Ethereum concept.

The design concepts of Monad and MegaETH are quite different from sharding: sharding horizontally splits the blockchain into multiple independent sub-chains (shards), with each sub-chain responsible for a portion of transactions and states, breaking the limitations of a single chain to achieve scalability at the network layer; whereas Monad and MegaETH maintain the integrity of a single chain and only achieve horizontal scalability at the execution layer, optimizing performance through extreme parallel execution within the single chain. The two represent two directions in the blockchain scalability path: vertical enhancement and horizontal expansion.

Projects like Monad and MegaETH focus on throughput optimization paths, with the core goal of enhancing on-chain TPS. They achieve transaction-level or account-level parallel processing through Deferred Execution and Micro-VM architectures. 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 collaborative work 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:

• Full Lifecycle Asynchronous Pipelining: Pharos decouples the various stages of a transaction (such as consensus, execution, storage) and adopts an asynchronous processing approach, allowing each stage to proceed independently and in parallel, thereby improving overall processing efficiency.
• Dual VM Parallel Execution: Pharos supports two virtual machine environments, EVM and WASM, allowing developers to choose the appropriate execution environment based on their needs. This dual VM architecture not only enhances the system’s flexibility but also improves transaction processing capabilities through parallel execution.
• Special Processing Networks (SPNs): SPNs are key components in the Pharos architecture, similar to modular subnetworks, specifically designed to handle specific types of tasks or applications. Through SPNs, Pharos can achieve dynamic resource allocation and parallel task processing, further enhancing the scalability and performance of the system.
• Modular Consensus & Restaking: Pharos introduces a flexible consensus mechanism that supports multiple consensus models (such as PBFT, PoS, PoA) and achieves secure sharing and resource integration between the mainnet and SPNs through the Restaking protocol.

In addition, Pharos has restructured the execution model from the underlying storage engine using multi-version Merkle trees, Delta Encoding, Versioned Addressing, and ADS Pushdown technologies, launching the native blockchain high-performance storage engine Pharos Store, achieving high throughput, low latency, and strong verifiable on-chain processing capabilities.

Overall, Pharos’s Rollup Mesh architecture achieves high-performance parallel computing capabilities through a modular design and asynchronous processing mechanism. Pharos acts as a scheduling coordinator for cross-Rollup parallelism, not as an execution optimizer for “on-chain parallelism,” but rather undertakes heterogeneous custom execution tasks through SPNs.

In addition to the parallel execution architecture of Monad, MegaETH, and Pharos, we also observe that there are some projects in the market exploring the application paths of GPU acceleration in EVM parallel computing, which serve as an important complement and cutting-edge experiment to the EVM parallel ecosystem. Among them, Reddio and GatlingX are two representative directions:

• Reddio is a high-performance platform that combines zkRollup and GPU parallel execution architecture. Its core lies in reconstructing the EVM execution process, achieving native parallelization at the execution layer through multi-thread scheduling, asynchronous state storage, and GPU-accelerated execution of transaction batches. It belongs to the transaction-level + operation-level (multi-thread execution of opcodes) parallel granularity. Its design introduces multi-thread 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 the reconstruction of the execution engine through GPU parallel architecture, specifically designed for high throughput and compute-intensive scenarios (such as AI inference). The SDK has been launched, providing an integrable execution module.
• GatlingX claims to be a “GPU-EVM” and proposes 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 involves dynamically compiling EVM bytecode into CUDA parallel tasks, executing instruction streams through GPU multi-core, 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 / MegaETH, GatlingX’s parallel mechanism is closer to instruction-level optimization paths, more akin to the underlying reconstruction of the virtual machine engine. Currently, it is in the conceptual stage, with a white paper and architectural sketches released, but no SDK or mainnet yet.

Artela proposes a differentiated parallel design concept. By introducing the EVM++ architecture with a WebAssembly (WASM) virtual machine, it allows developers to dynamically add and execute extensions on-chain while maintaining EVM compatibility, utilizing the Aspect programming model. It takes the granularity of contract calls (Function / Extension) as the minimum parallel unit, supporting the injection of Extension modules (similar to “pluggable middleware”) during 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. This concept offers new ideas for future complex multi-module applications.

3. Native Parallel Architecture Chain: Reconstructing the Execution Entity of the VM

The Ethereum EVM execution model has adopted a “transaction total order + serial execution” single-threaded architecture since its design, aimed at ensuring 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 such as Solana (SVM), MoveVM (Sui, Aptos), and Sei v2 built on Cosmos SDK are tailored for parallel execution from the ground up, offering the following advantages:

• State model naturally separates: Solana adopts an account lock declaration mechanism, MoveVM introduces an object ownership model, and Sei v2 classifies based on transaction types to achieve static conflict determination, supporting transaction-level concurrent scheduling.
• Virtual machine concurrency optimization: Solana’s Sealevel engine natively supports multithreaded execution; MoveVM can perform static concurrency graph analysis; Sei v2 integrates a multithreaded matching engine and parallel VM module.

Of course, this type of native parallel chain also faces challenges of ecological compatibility. Non-EVM architectures often require entirely new development languages (such as Move, Rust) and toolchains, which presents a certain migration cost for developers; in addition, developers must also master a series of new concepts such as state access models, concurrency limits, and object lifecycles, all of which raise the threshold for understanding and impose higher demands on development paradigms.

3.1 The Principle of Solana and SVM’s Sealevel Parallel Engine

The Sealevel execution model of Solana is an account-based parallel scheduling mechanism, which is the core engine used by Solana to achieve on-chain parallel transaction execution. Through the “account declaration + static scheduling + multi-threaded execution” mechanism, it realizes 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 Mechanism:

1. Explicit Account Access Declaration (Account Access Lists): Each transaction must declare the accounts involved (read/write) at the time of submission, allowing the system to determine whether there are state conflicts between transactions.

2. Conflict Detection and Multithreading Scheduling

• If the set of accounts accessed by the two transactions has no intersection → they can be executed in parallel;
• Conflict exists → Execute serially in dependency order;
• The scheduler allocates transactions to different threads based on the dependency graph.

3. Independent Execution Context (Program Invocation Context): Each contract call operates in an isolated context, with no shared stack, preventing cross-call interference.

Sealevel is the parallel execution scheduling engine of Solana, 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. Therefore, Eclipse also falls under the category of parallel computing.

Neon’s approach is different; it introduces the EVM to run in the SVM / Sealevel environment. It builds a runtime layer compatible with the EVM, allowing developers to use Solidity to develop contracts that run in the SVM environment, but the scheduling execution uses SVM + Sealevel. Neon is more inclined towards the category of Modular Blockchain rather than emphasizing innovations in parallel computing.

In summary, Solana and SVM rely on the Sealevel execution engine, and the scheduling philosophy of the Solana operating system is similar to that of 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 the security of on-chain resources and parallel execution. Its core language, Move, was originally developed by Meta (formerly Facebook) for the Libra project, emphasizing the concept of “resource as an object”. All on-chain states exist as objects with clear ownership and lifecycle. This allows MoveVM to analyze whether there are state conflicts between transactions at compile time, enabling object-level static parallel scheduling, and it is widely used in native parallel public chains such as Sui and Aptos.

Sui’s object ownership model
The parallel computing capability of Sui stems from its unique state modeling approach and language-level static analysis mechanism. Unlike traditional blockchains that use a global state tree, Sui has built a set of object-centric state models, combined with the linear type system of MoveVM, allowing parallel scheduling to be a deterministic process that can be completed at compile time.

• The Object Model is the foundation of Sui’s parallel architecture. Sui abstracts all on-chain states into independent objects, each with a unique ID, a clear owner (account or contract), and type definitions. These objects do not share states with each other, providing natural isolation. Contracts must explicitly declare the set of objects involved when invoked, avoiding the state coupling issues of the traditional “global state tree” on-chain. This design breaks down on-chain states into several independent units, making concurrent execution a structurally feasible scheduling premise.
• Static Ownership Analysis is a compile-time analysis mechanism implemented under the support of the linear type system of the Move language. It allows the system to infer which transactions will not cause state conflicts through object ownership before the transactions are executed, thus arranging 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 based on objects and combines compile-time ownership analysis to achieve low-cost, rollback-free object-level parallel execution. Compared to the serial execution or runtime checks of traditional chains, Sui has achieved 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, whose parallel execution capability mainly comes from the self-developed Block-STM (Block-level Software Transactional Memory) framework. Unlike Sui, which tends to adopt a “compile-time static parallelism” strategy, Block-STM belongs to 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 phases:

• Speculative Execution: All transactions are assumed to be conflict-free before execution, and the system schedules transactions to multiple threads for concurrent execution, recording the account states they access (read set / write set).
• Conflict Detection and Validation Phase: The system verifies the execution results: if two transactions have a read-write conflict (for example, Tx1 reads the state written by Tx2), one of them will be rolled back.
• Conflict Transaction Rollback Retry (Retry Phase): Conflict transactions will be rescheduled for execution until their dependencies are resolved, ultimately forming a valid and deterministic state commit sequence for all transactions.

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

Solana is the engineering scheduling faction, more like an “operating system kernel”. It is suitable for clear state boundaries and controllable high-frequency trading, embodying a hardware engineer style, and is designed to run the chain like hardware (Hardware-grade parallel execution). Aptos is the system fault tolerance faction, more like a “database concurrency engine”. It is suitable for contracts with strong state coupling and complex call chains. Sui is the compile-time safety faction, more like a “resource-oriented smart language platform”. It is suitable for on-chain applications with asset separation and clear combinations. Aptos and Sui are meant to operate the chain as program language engineers, ensuring software-grade resource security. The three represent different philosophical paths for the technical implementation of parallel computing in Web3.

3.3 Cosmos SDK Parallel Scaling Type

Sei V2 is a high-performance trading public chain built on the Cosmos SDK. Its parallel capabilities are mainly reflected in two aspects: the multi-threaded matching engine and the 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 Mechanism:

• Parallel Matching Engine: Sei V2 introduces a multi-threaded execution path in the order matching logic, separating the order book from the matching logic at the thread level, allowing matching tasks between multiple markets (trading pairs) to be processed in parallel, thereby avoiding single-thread bottlenecks.
• Virtual Machine-Level Concurrency Optimization: Sei V2 has built a CosmWasm runtime environment with concurrent execution capabilities, allowing certain contract calls to run in parallel under the condition that their states do not conflict, and achieving higher throughput control in conjunction with a transaction type classification mechanism.
• Parallel consensus combined with execution layer scheduling: Introducing the so-called “Twin-Turbo” consensus mechanism to strengthen the throughput decoupling between the consensus layer and the execution layer, enhancing the overall block processing efficiency.

3.4 UTXO Model Rebuilder 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 inherently 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 called Sway (similar to Rust), and combines it with static analysis tools to identify input conflicts before transaction execution, thereby achieving efficient and secure transaction-level parallel scheduling. It serves as an EVM alternative execution layer that balances performance and modularity.

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

The Actor Model is a parallel execution paradigm that uses agent processes (Agent or Process) as units, differing from traditional synchronous computation with a global state on-chain (scenarios like “on-chain parallel computing” such as Solana/Sui/Monad), as it emphasizes that each agent has its own independent state and behavior, communicating and scheduling through asynchronous messages. Under this architecture, on-chain systems can concurrently run a large number of decoupled processes, providing 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, multi-task interactions, and complex logic orchestration.

Although the design of the Actor Model has certain superficial similarities to Sharding (such as concurrency, state isolation, and asynchronous processing), they essentially represent completely different technical paths and system philosophies. The Actor Model emphasizes “multi-process asynchronous computing,” where each agent (Actor) runs independently and maintains its own state, interacting through a message-driven approach; whereas Sharding is a mechanism for “horizontal partitioning of state and consensus,” dividing the entire blockchain into multiple independent subsystems (Shards) that process transactions. The 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 concurrency, but their starting points, goals, and execution architectures are different.

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 the operation of large-scale asynchronous agents.

Core Architecture Features:

• Process architecture: Each agent is referred to as a Process, possessing independent state, independent scheduler, 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 operating model, which inherently supports concurrent scaling;
• 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.), can build an “on-chain AI Coprocessor.”

AO follows an extreme “native intelligent body + storage-driven + no-chain architecture” approach, emphasizing flexibility and modular decoupling. It is a “microkernel framework built on top of the storage layer,” with intentionally narrowed system boundaries, emphasizing lightweight computing + 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 supports complete service hosting, domain binding, and a serverless architecture.

Core architecture features:

• Canister architecture (containers as smart agents): Each Canister is a smart agent running on the Wasm VM, possessing independent state, code, and asynchronous scheduling capabilities;
• Subnet Distributed Consensus System: The entire network is composed of multiple Subnets, each of which maintains a group of Canisters and reaches consensus through the BLS signature mechanism.
• Asynchronous call model: Canisters communicate with each other through asynchronous messaging, supporting non-blocking execution and having inherent 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.
• Comprehensive system functions: Equipped with on-chain hot upgrades, identity authentication, distributed randomness, timers, and other system APIs, suitable for complex on-chain service deployment.

ICP selects a heavy platform, integrated encapsulation, and strong platform control operating system paradigm, featuring a “Blockchain Operating System” with integrated consensus, execution, storage, and access. It emphasizes complete service hosting capabilities, and the system boundary expands into a full-stack Web3 hosting platform.

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

V. 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 achieves higher throughput and parallel processing capabilities through deep optimization of the execution layer while maintaining compatibility with the EVM/Solidity ecosystem. It is suitable for scenarios where there is a desire to inherit Ethereum assets and development tools while also achieving performance breakthroughs. Representative projects include:

• Monad: Achieves an optimistic parallel execution model compatible with EVM through delayed writes and runtime conflict detection, building a dependency graph and scheduling execution with multithreading after consensus is reached.
• MegaETH: Abstracts each account/contract as an independent Micro-VM, achieving highly decoupled account-level parallel scheduling based on asynchronous messaging and state dependency graphs.
• Pharos: Building a Rollup Mesh architecture that collaborates with the SPN module through asynchronous pipelines to achieve system-level parallel processing across processes.
• Reddio: Adopts a zkRollup + GPU architecture, focusing on accelerating the off-chain verification process of zkEVM through bulk SNARK generation, enhancing verification throughput.

The latter completely breaks free from the limitations of Ethereum compatibility, redesigning the execution paradigm from the virtual machine, state model, and scheduling mechanism to achieve native high-performance concurrency capabilities. Typical subclasses include:

• Solana (SVM System): Based on account access declarations and static conflict graph scheduling, representing an account-level parallel execution model;
• Sui / Aptos (MoveVM System): Based on the resource object model and type system, it supports compile-time static analysis and achieves 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 high-frequency trading applications.
• Fuel (UTXO + Sway architecture): Achieving transaction-level parallelism through static analysis of UTXO input sets, combined with a modular execution layer and the customized smart contract language Sway.

In addition, the Actor Model, as a broader parallel system, constructs 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): An agent runtime driven by permanent storage, building an on-chain asynchronous microkernel system.
• ICP (Internet Computer): Achieves asynchronous high scalability execution through subnet coordination with the containerized agent (Canister) as the smallest unit.
• Cartesi: Introduces the Linux operating system as an off-chain computing environment, providing an on-chain verification path for trusted computing results, suitable for complex or resource-intensive application scenarios.

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

From a broader perspective of scaling, sharding and rollup (L2) focus on achieving horizontal scaling of the system 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 methods like multithreaded virtual machines, object models, and transaction conflict analysis; the latter uses processes/agents as basic units and adopts message-driven and asynchronous execution methods to enable concurrent operation of multiple agents. In comparison, sharding and rollup are more like ‘distributing the load across multiple chains’ or ‘outsourcing to off-chain’, while parallel chains and the actor model are about ‘liberating the performance potential from the execution engine itself’, reflecting a more thorough architectural evolution direction.

Parallel Computing vs Shard Architecture vs Rollup Scalability vs Actor Oriented Extension Path Comparison

It is worth noting that most native parallel architecture chains have now 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 the gradual prosperity of ecological applications, have become the core public chains that attract significant market attention.

In contrast, although the Ethereum Rollup (L2) ecosystem has entered the stage of “many chains rushing to launch” or even “overcapacity,” the currently mainstream EVM-compatible parallel enhancement chains are still generally in the testnet stage and have not yet undergone actual verification in the mainnet environment. Their scaling capabilities and system stability still require further examination. As for whether these projects can significantly improve EVM performance and promote ecological evolution without sacrificing compatibility, or whether they will instead exacerbate the further differentiation of liquidity and development resources on Ethereum, remains to be seen.

Statement:

1. This article is reproduced from [TechFlow] The copyright belongs to the original author [0xjacobzhao and ChatGPT 4o] If you have any objections to the reprint, please contact Gate Learn TeamThe team will process it as quickly as possible according to the relevant procedures.
2. Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Other language versions of the article are translated by the Gate Learn team, unless otherwise mentioned.GateUnder no circumstances shall translated articles be copied, disseminated, or plagiarized.