The Future of Scaling: A Panoramic View of the Web3 Parallel Computing Landscape
TechFlow Selected TechFlow Selected
The Future of Scaling: A Panoramic View of the Web3 Parallel Computing Landscape
A hardcore interpretation of Web3 parallel computing.
Navigating Web3 tides with focused insightsAuthor: 0xjacobzhao and ChatGPT 4o
The blockchain "impossible triangle" (Blockchain Trilemma) — security, decentralization, and scalability — reveals the inherent trade-offs in blockchain system design: it is extremely difficult for a blockchain project to simultaneously achieve "maximum security, universal participation, and high-speed processing." Regarding scalability, an evergreen topic, current mainstream blockchain scaling solutions can be categorized by paradigm into:
-
Execution-enhanced scaling: enhancing execution capabilities in-place, such as parallelism, GPU acceleration, and multi-core processing
-
State-isolated scaling: horizontally partitioning state/shards, such as sharding, UTXO, and multi-subnet architectures
-
Off-chain outsourcing scaling: moving execution off-chain, such as Rollup, Coprocessor, and DA
-
Structural decoupling scaling: modular architecture with coordinated operation, such as modular chains, shared sequencers, and Rollup Mesh
-
Asynchronous concurrent scaling: Actor model, process isolation, message-driven, such as agents and multi-threaded asynchronous chains
Blockchain scaling solutions include intra-chain parallel computing, Rollup, sharding, DA modules, modular structures, Actor systems, zk-proof compression, and Stateless architecture. Covering multiple layers including execution, state, data, and structure, they form a complete scaling system based on "multi-layer coordination and modular composition." This article focuses primarily on scaling approaches centered on parallel computing.
Intra-chain parallelism refers to the parallel execution of transactions/instructions within a block. Classified by parallel mechanisms, these scaling methods fall into five categories, each representing different performance goals, development models, and architectural philosophies. The granularity becomes progressively finer, parallel intensity increases, scheduling complexity grows, and so does programming and implementation difficulty.
-
Account-level parallelism: represented by Solana
-
Object-level parallelism: represented by Sui
-
Transaction-level parallelism: represented by Monad, Aptos
-
Call-level / MicroVM parallelism: represented by MegaETH
-
Instruction-level parallelism: represented by GatlingX
Off-chain asynchronous concurrency models, exemplified by Agent/Actor Model systems, represent another paradigm of parallel computing. As cross-chain/asynchronous messaging systems (non-block-synchronized models), each Agent operates as an independent "agent process," communicating via asynchronous messages and event-driven interactions without requiring synchronized scheduling. Representative projects include AO, ICP, and Cartesi.
Familiar solutions like Rollup or sharding belong to system-level concurrency mechanisms and are not considered intra-chain parallel computing. They scale by "running multiple chains/executing domains in parallel," rather than increasing the internal parallelism of a single block/virtual machine. While not the focus of this article, we will still compare their architectural similarities and differences.
II. EVM-based Parallel-Enhanced Chains: Breaking Performance Boundaries While Maintaining Compatibility
Ethereum's serial processing architecture has undergone multiple rounds of scaling attempts, including sharding, Rollups, and modular architectures, yet the throughput bottleneck at the execution layer remains fundamentally unresolved. Meanwhile, EVM and Solidity continue to serve as the most widely adopted smart contract platform with the largest developer base and ecosystem momentum. Thus, EVM-based parallel-enhanced chains—balancing ecosystem compatibility with enhanced execution performance—are emerging as a key direction in the next wave of scaling evolution. Monad and MegaETH stand out as representative projects in this space, building high-concurrency, high-throughput EVM architectures through delayed execution and state decomposition, respectively.
Monad's Parallel Computing Mechanism Explained
Monad is a high-performance Layer1 blockchain redesigned for the Ethereum Virtual Machine (EVM). Based on pipelining—a fundamental parallel concept—it enables 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 foundational principle behind Monad’s parallel execution. The core idea involves decomposing the blockchain execution process into multiple independent stages and processing them in parallel, forming a three-dimensional pipeline architecture. Each stage runs on separate threads or cores, enabling cross-block concurrent processing to ultimately increase throughput and reduce latency. These stages include transaction proposal (Propose), consensus formation (Consensus), execution (Execution), and block commitment (Commit).
Asynchronous Execution: Decoupling Consensus from Execution
In traditional blockchains, transaction consensus and execution follow a synchronous flow, severely limiting performance scalability. Monad achieves asynchronous execution across consensus, execution, and storage layers, significantly reducing block time and confirmation latency, making the system more elastic, processing workflows more granular, and resource utilization more efficient.
Core Design:
-
The consensus process (consensus layer) only handles transaction ordering, not contract logic execution.
-
The execution process (execution layer) is triggered asynchronously after consensus completion.
-
Immediately after consensus, the system proceeds to the next block’s consensus process without waiting for execution to finish.
Optimistic Parallel Execution: Optimistic Concurrency
Traditional Ethereum uses a strict serial model for transaction execution to avoid state conflicts. In contrast, Monad adopts an "optimistic parallel execution" strategy to dramatically improve transaction processing speed.
Execution Mechanism:
-
Monad optimistically executes all transactions in parallel, assuming most transactions do not have state conflicts.
-
A "Conflict Detector" runs concurrently to monitor whether transactions access the same states (e.g., read/write conflicts).
-
If a conflict is detected, conflicting transactions are re-executed serially to ensure state correctness.
Monad chooses a compatibility-focused path: minimizing changes to EVM rules and achieving parallelism through deferred state writes and dynamic conflict detection. It functions like a high-performance version of Ethereum, offering high maturity and smooth migration for EVM ecosystems—an EVM-world parallel accelerator.
MegaETH's Parallel Computing Mechanism Explained
Unlike Monad’s L1 positioning, MegaETH positions itself as a high-performance, EVM-compatible modular parallel execution layer. It can function either as an independent L1 chain or as an execution-enhancement layer (Execution Layer) or modular component on Ethereum. Its core design goal is to deconstruct account logic, execution environments, and state into independently schedulable minimal units, enabling high intra-chain concurrency and low-latency response. MegaETH's key innovations include: Micro-VM Architecture + State Dependency DAG (Directed Acyclic Graph of State Dependencies) and modular synchronization mechanisms—collectively forming a "threaded-intra-chain" parallel execution framework.
Micro-VM (Micro Virtual Machine) Architecture: Account-as-Thread
MegaETH introduces an execution model where "each account is a micro virtual machine (Micro-VM)," threading the execution environment to provide the smallest isolation unit for parallel scheduling. These VMs communicate via asynchronous messaging instead of synchronous calls, allowing many VMs to execute and store data independently—enabling natural parallelism.
State Dependency DAG: Dependency Graph-Driven Scheduling
MegaETH builds a DAG-based scheduling system grounded in account state access relationships. The system maintains a real-time global dependency graph, modeling every transaction’s modifications and reads into dependency relations. Transactions without conflicts are executed in parallel; those with dependencies are scheduled in topological order or postponed. The dependency graph ensures state consistency and prevents duplicate writes during parallel execution.
Asynchronous Execution and Callback Mechanism
Built on an asynchronous programming paradigm similar to the Actor Model’s message-passing mechanism, MegaETH resolves the issue of traditional EVM’s serial calls. Contract invocations are asynchronous (non-recursive), so calling A → B → C breaks down each call into non-blocking operations. The call stack unfolds into an asynchronous call graph. Transaction processing becomes traversing this asynchronous graph, resolving dependencies, and parallel scheduling.
In summary, MegaETH breaks away from the traditional EVM single-threaded state machine model by encapsulating accounts and contracts into micro VMs, using a state dependency graph for transaction scheduling, and replacing the synchronous call stack with asynchronous messaging. It represents a fully reimagined parallel computing platform—from "account structure → scheduling architecture → execution flow"—offering a paradigm-shifting approach for next-generation high-performance on-chain systems.
MegaETH chooses a reconstruction path: completely abstracting accounts and contracts into independent VMs and unlocking maximum parallel potential through asynchronous scheduling. Theoretically, MegaETH offers higher parallel limits but greater complexity control challenges—it resembles a super distributed operating system under the Ethereum philosophy.
Both Monad and MegaETH differ significantly from sharding: sharding horizontally divides the blockchain into multiple independent sub-chains (shards), each handling partial transactions and state, breaking single-chain limitations through network-layer expansion. In contrast, Monad and MegaETH maintain single-chain integrity, expanding only at the execution layer and pushing intra-chain parallel execution to its limits. They represent two distinct blockchain scaling directions: vertical enhancement versus horizontal scaling.
Projects like Monad and MegaETH primarily focus on throughput optimization, aiming to boost intra-chain TPS through delayed execution and Micro-VM architectures to achieve transaction-level or account-level parallel processing. Pharos Network, however, is a modular, full-stack parallel L1 blockchain network whose core parallel mechanism is called "Rollup Mesh." This architecture supports multi-virtual machine environments (EVM and Wasm) through collaboration between the mainnet and Special Processing Networks (SPNs), integrating advanced technologies such as zero-knowledge proofs (ZK) and Trusted Execution Environments (TEE).
Rollup Mesh Parallel Computing Mechanism Explained:
-
Full Lifecycle Asynchronous Pipelining: Pharos decouples transaction phases (e.g., consensus, execution, storage) and applies asynchronous processing, enabling each phase to proceed independently and in parallel, improving overall efficiency.
-
Dual VM Parallel Execution: Pharos supports both EVM and WASM virtual machines, allowing developers to choose the appropriate execution environment. This dual-VM architecture enhances flexibility and boosts transaction throughput via parallel execution.
-
Special Processing Networks (SPNs): SPNs are key components in the Pharos architecture, functioning as modular subnetworks specialized for specific tasks or applications. Through SPNs, Pharos achieves dynamic resource allocation and parallel task processing, further enhancing scalability and performance.
-
Modular Consensus & Restaking: Pharos introduces flexible consensus mechanisms supporting various models (e.g., PBFT, PoS, PoA) and enables security sharing and resource integration between the mainnet and SPNs via restaking protocols.
Additionally, Pharos reconstructs the execution model at the storage engine level using multi-version Merkle trees, delta encoding, versioned addressing, and ADS pushdown techniques, launching Pharos Store—a native high-performance blockchain storage engine enabling high-throughput, low-latency, and strongly verifiable on-chain processing.
Overall, Pharos’ Rollup Mesh architecture achieves high-performance parallel computing through modular design and asynchronous processing. As a coordinator for cross-Rollup parallelism, Pharos is not an "intra-chain parallel" execution optimizer but leverages SPNs to host heterogeneous, customized execution tasks.
Besides Monad, MegaETH, and Pharos, we observe market explorations into GPU-accelerated EVM parallel computing as important supplements and frontier experiments in the EVM parallel ecosystem. Reddio and GatlingX represent two notable directions:
-
Reddio is a high-performance platform combining zkRollup with GPU-parallel execution architecture. Its core innovation lies in reengineering the EVM execution flow through multithreaded scheduling, asynchronous state storage, and GPU-accelerated batch transaction execution, achieving native parallelism at the execution layer. It operates at transaction-level plus operation-level (multithreaded opcode execution) granularity. By introducing multithreaded batch execution, asynchronous state loading, and GPU-parallelized transaction logic (CUDA-Compatible Parallel EVM), Reddio focuses on execution-layer parallelism like Monad/MegaETH—but differs by rebuilding the execution engine around GPU parallelism, specifically designed for high-throughput and computation-intensive scenarios (e.g., AI inference). An SDK is already available, offering integrable execution modules.
-
GatlingX brands itself as a "GPU-EVM," proposing a more radical architecture aiming to migrate the traditional EVM’s "instruction-level serial execution" model into a GPU-native parallel environment. Its core mechanism dynamically compiles EVM bytecode into CUDA parallel tasks, leveraging GPU multi-core processing of instruction streams to break EVM’s sequential bottleneck at the lowest level. Operating at instruction-level (Instruction-Level Parallelism, ILP) granularity, GatlingX takes an instruction-level optimization path—deeper than Monad/MegaETH’s "transaction/account-level" parallelism—approaching bottom-up VM engine reconstruction. Currently conceptual, with whitepaper and architecture sketches published, but no SDK or mainnet yet.
Artela proposes a differentiated parallel design philosophy. By introducing EVM++ and WebAssembly (WASM) virtual machines, it allows developers to dynamically add and execute extensions on-chain using the Aspect programming model while maintaining EVM compatibility. Using contract call granularity (Function/Extension) as the smallest parallel unit, it supports injecting Extension modules ("pluggable middleware") during EVM contract runtime, enabling logical decoupling, asynchronous calls, and module-level parallel execution. Artela emphasizes composability and modular architecture at the execution layer, offering new ideas for future complex multi-module applications.
III. Native Parallel Architecture Chains: Reconstructing the Execution Core of the VM
Ethereum’s EVM execution model was originally designed with a "total transaction order + serial execution" single-threaded architecture to ensure deterministic and consistent state changes across all nodes. However, this design inherently limits 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 purpose-built from the ground up for parallel execution, offering the following advantages:
-
Naturally separated state models: Solana uses account lock declarations, MoveVM employs object ownership models, and Sei v2 relies on transaction-type classification to enable static conflict determination and support concurrent transaction scheduling;
-
VMs optimized for concurrency: Solana’s Sealevel engine natively supports multi-threaded execution; MoveVM performs static concurrency graph analysis; Sei v2 integrates a multi-threaded matching engine and parallel VM modules.
However, these native parallel chains face ecosystem compatibility challenges. Non-EVM architectures typically require entirely new development languages (e.g., Move, Rust) and toolchains, posing migration costs for developers. Moreover, developers must master new concepts such as state access models, concurrency constraints, and object lifecycles, raising learning curves and demanding shifts in development paradigms.
3.1 Solana and SVM’s Sealevel Parallel Engine Principles
Solana’s Sealevel execution model is an account-parallel scheduling mechanism and serves as the core engine for intra-chain parallel transaction execution. Through "explicit account access declaration + static scheduling + multi-threaded execution," it achieves high-performance concurrency at the smart contract level. Sealevel is the first execution model in the blockchain field to successfully implement intra-chain concurrent scheduling in production environments. Its architectural ideas have influenced numerous subsequent parallel computing projects and serve as a reference paradigm for high-performance Layer1 parallel design.
Core Mechanisms:
1. Explicit Account Access Declaration (Account Access Lists): Each transaction must declare the accounts it accesses (read/write) upon submission, enabling the system to determine potential state conflicts between transactions.
2. Conflict Detection and Multi-threaded Scheduling
-
If two transactions access disjoint account sets → they can be executed in parallel;
-
If conflicts exist → they are executed sequentially according to dependency order;
-
The scheduler assigns transactions to different threads based on the dependency graph.
3. Independent Execution Context (Program Invocation Context): Each contract call runs in an isolated context with no shared stack, preventing interference across calls.
Sealevel is Solana’s parallel execution scheduling engine, while SVM is the smart contract execution environment built atop Sealevel (using the BPF virtual machine). Together, they form the technical foundation of Solana’s high-performance parallel execution system.
Eclipse is a project that deploys Solana VM onto modular chains (e.g., Ethereum L2 or Celestia), leveraging Solana’s parallel execution engine as a Rollup execution layer. Eclipse was among the first to propose extracting Solana’s execution layer (Sealevel + SVM) from the Solana mainnet and deploying it within modular architectures, modularizing Solana’s "ultra-high concurrency execution model" as Execution Layer-as-a-Service. Hence, Eclipse also belongs to the broader category of parallel computing.
Neon takes a different route by bringing EVM into the SVM/Sealevel environment. It constructs an EVM-compatible runtime layer, allowing developers to write contracts in Solidity and run them under SVM, while relying on SVM + Sealevel for scheduling and execution. Neon leans more toward modular blockchain (Modular Blockchain) and does not emphasize parallel computing innovation.
In summary, Solana and SVM rely on the Sealevel execution engine. Solana’s OS-like scheduling philosophy resembles a kernel scheduler—fast execution but relatively lower 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." All on-chain states exist as objects with clear ownership and lifecycles. This allows MoveVM to analyze potential state conflicts between transactions at compile time, enabling object-level static parallel scheduling. It is widely used in native parallel public chains such as Sui and Aptos.
Sui’s Object Ownership Model
Sui’s parallel computing capability stems from its unique state modeling and language-level static analysis mechanisms. Unlike traditional blockchains using a global state tree, Sui builds an "object-centric" state model supported by MoveVM’s linear type system, making parallel scheduling a deterministic process achievable at compile time.
-
The Object Model forms the foundation of Sui’s parallel architecture. Sui abstracts all on-chain states into 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 invocation, avoiding the state coupling issues associated with traditional "global state trees." This design fragments on-chain state into independent units, making concurrent execution structurally feasible.
-
Static Ownership Analysis is a compile-time analysis mechanism enabled by Move’s linear type system. It allows the system to deduce which transactions will not produce state conflicts before execution, thereby scheduling them for parallel execution. Compared to traditional runtime conflict detection and rollback, Sui’s static analysis significantly improves execution efficiency and reduces scheduling complexity—the key to its high throughput and deterministic parallel processing.
Sui partitions state space by object and combines compile-time ownership analysis to achieve low-cost, rollback-free object-level parallel execution. Compared to traditional serial execution or runtime detection, Sui achieves significant improvements in execution efficiency, system determinism, and resource utilization.
Aptos’ Block-STM Execution Mechanism
Aptos is a high-performance Layer1 blockchain based on the Move language. Its parallel execution capability primarily comes from its proprietary Block-STM (Block-level Software Transactional Memory) framework. Unlike Sui’s preference for "compile-time static parallelism," Block-STM adopts 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:
-
Optimistic Concurrent Execution (Speculative Execution): All transactions are assumed conflict-free by default. The system schedules transactions across multiple threads for concurrent speculative execution, recording their accessed account states (read-set/write-set).
-
Conflict Detection and Validation: The system validates execution results: if two transactions have read-write conflicts (e.g., Tx1 reads a state written by Tx2), one of them is rolled back.
-
Conflict Retry Phase: Conflicting transactions are rescheduled until their dependencies are resolved, ultimately forming a valid, deterministic sequence of state commits.
Block-STM is a "optimistic parallel + rollback retry" dynamic execution model, ideal for state-intensive, logic-complex on-chain transaction batching. It serves as the core parallel computing engine for Aptos to build a highly general-purpose, high-throughput public chain.
Solana represents the engineering-scheduling school—akin to an "operating system kernel"—suited for clear state boundaries and predictable high-frequency transactions, embodying a hardware engineer’s mindset aiming to run chains like hardware (Hardware-grade parallel execution). Aptos represents the system fault-tolerance school—like a "database concurrency engine"—ideal for tightly coupled states and complex call-chain contract systems. Sui represents the compilation-security school—resembling a "resource-oriented smart language platform"—best suited for asset-segregated, clearly composable on-chain applications. Aptos and Sui reflect a software engineer’s mindset—running chains securely like software (Software-grade resource security). Together, they represent divergent technical implementations of Web3 parallel computing under different philosophies.
3.3 Cosmos SDK Parallel Expansion
Sei V2 is a high-performance transactional public chain built on the Cosmos SDK. Its parallel capabilities manifest in two aspects: a multi-threaded matching engine and VM-level parallel execution optimization, targeting high-frequency, low-latency on-chain trading scenarios such as order-book DEXs and on-chain exchange infrastructure.
Core Parallel Mechanisms:
-
Parallel Matching Engine: Sei V2 introduces multi-threaded execution paths into order-matching logic, splitting order books and matching logic at the thread level, enabling parallel processing across multiple markets (trading pairs) to avoid single-thread bottlenecks.
-
VM-level Concurrency Optimization: Sei V2 builds a CosmWasm runtime environment capable of concurrent execution, allowing certain contract calls to run in parallel when no state conflicts exist, combined with transaction-type classification for improved throughput control.
-
Parallel Consensus Coordinated with Execution Scheduling: Introduces the so-called "Twin-Turbo" consensus mechanism to strengthen throughput decoupling between consensus and execution layers, improving overall block processing efficiency.
3.4 UTXO Model Innovator: Fuel
Fuel is a high-performance execution layer designed on Ethereum’s modular architecture. Its core parallel mechanism stems from an enhanced UTXO (Unspent Transaction Output) model. Unlike Ethereum’s account model, Fuel uses UTXO structures to represent assets and states, a model that naturally provides state isolation, facilitating safe identification of transactions eligible for parallel execution. Additionally, Fuel introduces its own smart contract language Sway (Rust-like) and combines static analysis tools to determine input conflicts before execution, enabling efficient, secure transaction-level parallel scheduling. It serves as a modular, high-performance alternative execution layer to EVM.
IV. Actor Model: A New Paradigm for Agent-Based Concurrent Execution
The Actor Model is a parallel execution paradigm based on agent processes (Agents or Processes). Unlike traditional chains relying on global state synchronous computing (e.g., Solana/Sui/Monad’s "on-chain parallel computing"), it emphasizes that each agent possesses independent state and behavior, interacting via asynchronous messaging and scheduling. Under this architecture, on-chain systems can run vast numbers of loosely coupled processes concurrently, offering exceptional scalability and asynchronous fault tolerance. Representative projects include AO (Arweave AO), ICP (Internet Computer), and Cartesi. These projects are transforming blockchains from mere execution engines into "on-chain operating systems," providing native infrastructure for AI Agents, multi-task interaction, and complex logic orchestration.
Although the Actor Model shares surface-level characteristics (e.g., parallelism, state isolation, asynchronous processing) with sharding, they represent fundamentally different technical paths and system philosophies. The Actor Model emphasizes "multi-process asynchronous computing," where each agent (Actor) runs independently with its own state, interacting via message-driven mechanisms. Sharding, in contrast, is a "horizontal partitioning of state and consensus," dividing the entire blockchain into multiple independent subsystems (Shards) handling transactions. The Actor Model resembles a "distributed agent operating system" in the Web3 world, whereas sharding is a structural scaling solution for intra-chain transaction processing. Both achieve parallelism but differ in origin, objectives, and execution architecture.
4.1 AO (Arweave): A Super-Parallel Computer on Top of Storage Layer
AO is a decentralized computing platform running atop Arweave’s permanent storage layer, aiming to build an on-chain operating system supporting large-scale asynchronous agent execution.
Core Architectural Features:
-
Process Architecture: Each agent is a Process with independent state, scheduler, and execution logic;
-
No Blockchain Structure: AO is not a chain but a decentralized storage layer (on Arweave) combined with a multi-agent message-driven execution engine;
-
Asynchronous Message Scheduling System: Processes communicate via Messages using a lock-free asynchronous model, naturally supporting concurrent scaling;
-
Permanent State Storage: All agent states, message logs, and instructions are permanently recorded on Arweave, ensuring full auditability and decentralized transparency;
-
Agent-Native: Ideal for deploying complex multi-step tasks (e.g., AI agents, DePIN protocol controllers, automated task orchestrators), enabling construction of "on-chain AI coprocessors."
AO follows an extreme "agent-native + storage-driven + chainless architecture" path, emphasizing flexibility and modular decoupling. It is a "microkernel framework built atop the storage layer," intentionally narrowing system boundaries to emphasize lightweight computation and composable control structures.
4.2 ICP (Internet Computer): Full-Stack Web3 Hosting Platform
ICP is a native Web3 full-stack on-chain application platform launched by DFINITY, aiming to extend on-chain computing experiences to Web2-equivalent levels and support full-service hosting, domain binding, and serverless architecture.
Core Architectural Features:
-
Canister Architecture (Container-as-Agent): Each Canister is an agent running on a Wasm VM, possessing independent state, code, and asynchronous scheduling capabilities;
-
Distributed Subnet Consensus System: The entire network consists of multiple Subnets, each maintaining a group of Canisters and reaching consensus via BLS signatures;
-
Asynchronous Call Model: Canisters communicate via asynchronous messages, supporting non-blocking execution and possessing inherent parallelism;
-
On-chain Web Hosting: Supports direct front-end page hosting via smart contracts with native DNS mapping, making it the first blockchain platform allowing browsers to directly access dApps;
-
Comprehensive System Features: Offers on-chain hot upgrades, authenticated identities, distributed randomness, timers, and other system APIs, suitable for deploying complex on-chain services.
ICP chooses a heavy-platform, integrated, centrally controlled operating system paradigm—a "blockchain operating system" unifying consensus, execution, storage, and access. It emphasizes complete service hosting capabilities, extending system boundaries into a full-stack Web3 hosting platform.
Other Actor Model-based parallel computing projects are summarized in the table below:
V. Summary and Outlook
Based on differences in virtual machine architecture and language systems, blockchain parallel computing solutions can be broadly divided into two categories: EVM-based parallel-enhanced chains and native parallel architecture chains (non-EVM).
The former retains EVM/Solidity ecosystem compatibility while deeply optimizing the execution layer to achieve higher throughput and parallel processing, suitable for scenarios seeking Ethereum asset and tool inheritance with performance breakthroughs. Representative projects include:
-
Monad: Achieves compatible EVM optimistic parallel execution through deferred writes and runtime conflict detection, constructing dependency graphs post-consensus and scheduling multi-threaded execution.
-
MegaETH: Abstracts each account/contract into an independent micro-VM (Micro-VM), enabling highly decoupled account-level parallel scheduling based on asynchronous message passing and state dependency graphs.
-
Pharos: Builds a Rollup Mesh architecture, achieving system-level parallel processing across workflows via asynchronous pipelines and SPN module coordination.
-
Reddio: Employs zkRollup + GPU architecture, focusing on accelerating zkEVM’s off-chain verification through batch SNARK generation to improve verification throughput.
The latter completely abandons Ethereum compatibility constraints, redesigning the execution paradigm from scratch—including VM, state model, and scheduling mechanisms—to achieve native high-performance concurrency. Typical subcategories include:
-
Solana (SVM family): Based on account access declarations and static conflict graph scheduling, representing account-level parallel execution models;
-
Sui / Aptos (MoveVM family): Built on resource-object models and type systems, supporting compile-time static analysis for object-level parallelism;
-
Sei V2 (Cosmos SDK path): Introduces multi-threaded matching engines and VM concurrency optimizations into the Cosmos architecture, ideal for high-frequency transactional applications;
-
Fuel (UTXO + Sway architecture): Achieves transaction-level parallelism via static analysis of UTXO input sets, combined with modular execution layers and custom smart contract language Sway;
Furthermore, the Actor Model, as a broader parallel system, constructs an "on-chain execution paradigm of multiple independent agents collaborating via message-driven mechanisms" through asynchronous process scheduling on Wasm or custom VMs. Representative projects include:
-
AO (Arweave AO): An agent runtime driven by permanent storage, building an asynchronous microkernel system on-chain;
-
ICP (Internet Computer): Uses containerized agents (Canisters) as the smallest unit, achieving asynchronous high scalability via subnet coordination;
-
Cartesi: Introduces the Linux operating system as an off-chain computation environment, providing an on-chain verification path for trusted computation results, suitable for complex or resource-intensive applications.
Based on the above logic, current mainstream parallel computing public chain solutions can be categorized into the following structural chart:
From a broader scaling perspective, sharding and Rollup (L2) focus on horizontal system expansion through state partitioning or off-chain execution. In contrast, parallel computing chains (e.g., Monad, Sui, Solana) and Actor-Oriented systems (e.g., AO, ICP) directly reconstruct the execution model, achieving native parallelism within the chain or at the system level. The former improves intra-chain throughput via multi-threaded VMs, object models, and transaction conflict analysis; the latter treats processes/agents as basic units, using message-driven and asynchronous execution for concurrent agent operation. In comparison, sharding and Rollup resemble "splitting load across multiple chains" or "outsourcing to off-chain," while parallel chains and Actor Models represent "unlocking performance potential from the execution engine itself," reflecting a more thorough architectural evolution.
Comparison of Parallel Computing vs. Sharding Architecture vs. Rollup Scaling vs. Actor-Oriented Expansion Paths
It should be particularly noted that most native parallel architecture chains have now entered mainnet launch stages. Although their overall developer ecosystems still lag behind the EVM/Solidity universe, projects like Solana and Sui—with their high-performance execution architectures and gradually flourishing ecosystems—have become core public chains attracting significant market attention.
In contrast, although the Ethereum Rollup (L2) ecosystem has entered a stage of "thousands of chains launching" or even "overcapacity," most mainstream EVM-based parallel-enhanced chains remain largely in testnet phases, lacking real-world validation under mainnet conditions. Their scaling capabilities and system stability require further testing. Whether these projects can significantly enhance EVM performance without sacrificing compatibility, drive ecosystem leaps, or instead exacerbate fragmentation of Ethereum liquidity and developer resources, remains to be seen over time.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
