Author: 0xjacobzhao and ChatGPT 4o

The "impossible triangle" of blockchain (security), "decentralization", and "scalability) reveals the essential trade-offs in blockchain system design, that is, it is difficult for blockchain projects to achieve "extreme security, everyone can participate, and high-speed processing" at the same time. Regarding the eternal topic of "scalability", the mainstream blockchain expansion solutions on the market are divided into paradigms, including:

• Execution-enhanced expansion: Improve execution capabilities in situ, such as parallelization, GPU, and multi-core
• State isolation expansion: horizontal split state/Shard, such as sharding, UTXO, multiple subnets
• Off-chain outsourcing expansion: putting execution outside the chain, such as Rollup, Coprocessor, DA
• Structural decoupling expansion: modular architecture and collaborative operation, such as module chain, shared sequencer, Rollup Mesh
• Asynchronous concurrent expansion: Actor model, process isolation, message-driven, such as intelligent agents, multi-threaded asynchronous chains

Blockchain expansion solutions include: in-chain parallel computing, Rollup, sharding, DA module, modular structure, Actor system, zk proof compression, Stateless architecture, etc., covering multiple levels of execution, state, data, and structure. It is a complete expansion system of "multi-layer collaboration and module combination". This article focuses on the expansion method with parallel computing as the mainstream.

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

• Account-level parallelism: Representative project Solana
• Object-level parallelism: Representative project Sui
• Transaction-level parallelism: Representative projects include Monad and Aptos
• Call-level / MicroVM parallelism: Representative project MegaETH
• Instruction-level parallelism: Representative project GatlingX

The off-chain asynchronous concurrent model is represented by the Actor / Actor Model. They belong to another parallel computing paradigm. As a cross-chain / asynchronous messaging system (non-block synchronization model), each Agent is an independently running "agent process" with asynchronous messaging and event-driven parallel methods, and no synchronous scheduling is required. Representative projects include AO, ICP, Cartesi, etc.

The Rollup or sharding expansion solutions that we are familiar with are system-level concurrency mechanisms, not intra-chain parallel computing. They achieve expansion by "running multiple chains/execution domains in parallel" rather than improving the parallelism within a single block/virtual machine. This type of expansion solution is not the focus of this article, but we will still use it to compare the similarities and differences in architectural concepts.

2. EVM-based parallel enhancement chain: breaking through performance boundaries in compatibility

Ethereum's serial processing architecture has been developed to date, and has undergone multiple rounds of expansion attempts such as sharding, Rollup, and modular architecture, but the throughput bottleneck of the execution layer has not been fundamentally broken through. But at the same time, EVM and Solidity are still the smart contract platforms with the most developer base and ecological potential. Therefore, the EVM-based parallel enhanced chain, as a key path to balance ecological compatibility and execution performance improvement, is becoming an important direction for the new round of expansion evolution. Monad and MegaETH are the most representative projects in this direction. Starting from delayed execution and state decomposition, respectively, they build EVM parallel processing architectures for high concurrency and high throughput scenarios.

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 basic parallel concept of pipeline processing, it uses 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 to achieve end-to-end optimization.

Pipelining: Multi-stage pipeline parallel execution mechanism

Pipelining is the basic concept of Monad parallel execution. Its core idea is to split the execution process of the blockchain into multiple independent stages, and process these stages in parallel to form a three-dimensional pipeline architecture. Each stage runs on an independent thread or core to achieve cross-block concurrent processing, ultimately achieving the effect of improving throughput and reducing latency. These stages include: transaction proposal (Propose), consensus (Consensus), transaction execution (Execution) and block submission (Commit).

Asynchronous Execution: Consensus - asynchronous execution decoupling

In traditional chains, transaction consensus and execution are usually synchronous processes. This serial model severely limits performance expansion. Monad achieves consensus layer asynchrony, execution layer asynchrony, and storage asynchrony through "asynchronous execution". It significantly reduces block time and confirmation delay, making the system more flexible, the processing flow more segmented, and resource utilization more efficient.

Core design:

• The consensus process (consensus layer) is only responsible for sorting transactions and does not execute contract logic.
• The execution process (execution layer) is triggered asynchronously after consensus is reached.
• After the consensus is completed, the next block consensus process will be entered immediately without waiting for the execution to be completed.

Optimistic Parallel Execution: Optimistic Parallel Execution

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

Execution mechanism:

• The monad will optimistically execute all transactions in parallel, assuming that most transactions do not conflict with each other.
• A "Conflict Detector" is also run to monitor whether transactions access the same state (such as read/write conflicts).
• If a conflict is detected, the conflicting transactions will be serialized and re-executed to ensure state correctness.

Monad has chosen a compatible path: it changes EVM rules as little as possible, and achieves parallelism by postponing writing status and dynamically detecting conflicts during execution. It is more like a high-performance version of Ethereum. Its maturity makes it easy to achieve EVM ecosystem migration, and it is a parallel accelerator in the EVM world.

Analysis of MegaETH’s parallel computing mechanism

Different from Monad's L1 positioning, MegaETH is positioned as an EVM-compatible modular high-performance parallel execution layer, which can be used as an independent L1 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 isolation into the smallest unit that can be independently scheduled to achieve high concurrency execution and low-latency response capabilities within the chain. The key innovation proposed by MegaETH is: Micro-VM architecture + State Dependency DAG (directed acyclic state dependency graph) and modular synchronization mechanism, which jointly build a parallel execution system for "threading within the chain".

Micro-VM architecture: Accounts as threads

MegaETH introduces an execution model of "one micro-VM per account", which "threads" the execution environment and provides the smallest isolation unit for parallel scheduling. These VMs communicate with each other through asynchronous messaging instead of synchronous calls, so a large number of VMs can be executed and stored independently, which is naturally parallel.

State Dependency DAG: Dependency graph driven scheduling mechanism

MegaETH has built a DAG scheduling system based on account status access relationships. The system maintains a global dependency graph in real time. Each transaction modifies which accounts and reads which accounts, all of which are modeled as dependencies. Non-conflicting transactions can be directly executed in parallel, and transactions with dependencies will be scheduled and sorted in topological order or delayed. The dependency graph ensures state consistency and non-duplicate writes during parallel execution.

Asynchronous execution and callback mechanism

MegaETH is built on an asynchronous programming paradigm, similar to the asynchronous message passing of the Actor Model, to solve the serial call problem of traditional EVM. Contract calls are asynchronous (non-recursive execution). When calling contracts A -> B -> C, each call is asynchronous without blocking and waiting; 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, implements micro-virtual machine encapsulation based on accounts, schedules transactions through state dependency graphs, and replaces synchronous call stacks with asynchronous message mechanisms. It is a parallel computing platform that has been redesigned from all dimensions from "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: completely abstracting accounts and contracts into independent VMs, and releasing the ultimate parallel potential through asynchronous execution scheduling. In theory, MegaETH has a higher parallel upper limit, but it is also more difficult to control complexity, and is more like a super distributed operating system under the Ethereum concept.

The design concepts of Monad and MegaETH are quite different from Sharding: Sharding divides the blockchain horizontally into multiple independent sub-chains (Shards), each of which is responsible for part of the transactions and status, breaking the limitation of single chain expansion at the network layer; while Monad and MegaETH both maintain the integrity of the single chain, only expand horizontally at the execution layer, and optimize the performance of extreme parallel execution within the single chain. Both represent the two directions of vertical strengthening and horizontal expansion in the blockchain expansion path.

Parallel computing projects such as Monad and MegaETH mainly focus on throughput optimization paths, with the core goal of improving the TPS within the chain, and achieve transaction-level or account-level parallel processing through Deferred Execution and Micro-VM architecture. As a modular, full-stack parallel L1 blockchain network, Pharos Network's core parallel computing mechanism is called "Rollup Mesh". This architecture supports multiple virtual machine environments (EVM and Wasm) through the collaboration of the main network and special processing networks (SPNs), and integrates advanced technologies such as zero-knowledge proof (ZK) and trusted execution environment (TEE).

Analysis of Rollup Mesh parallel computing mechanism:

1. Full Lifecycle Asynchronous Pipelining: Pharos decouples the various stages of a transaction (such as consensus, execution, and storage) and uses asynchronous processing so that each stage can be performed independently and in parallel, thereby improving overall processing efficiency.
2. Dual VM Parallel Execution: Pharos supports both EVM and WASM virtual machine environments, allowing developers to choose the appropriate execution environment according to their needs. This dual VM architecture not only improves the flexibility of the system, but also improves transaction processing capabilities through parallel execution.
3. Special Processing Networks (SPNs): SPNs are key components in the Pharos architecture, similar to modular sub-networks, dedicated to processing specific types of tasks or applications. Through SPNs, Pharos can achieve dynamic resource allocation and parallel processing of tasks, further enhancing the scalability and performance of the system.
4. Modular Consensus & Restaking: Pharos introduces a flexible consensus mechanism that supports multiple consensus models (such as PBFT, PoS, PoA), and achieves secure sharing and resource integration between the mainnet and SPNs through the restaking protocol (Restaking).

In addition, Pharos reconstructs the execution model from the bottom of the storage engine through multi-version Merkle trees, Delta Encoding, Versioned Addressing, and ADS Pushdown technologies, and launches the native blockchain high-performance storage engine Pharos Store, achieving high-throughput, low-latency, and highly verifiable on-chain processing capabilities.

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

In addition to the parallel execution architectures of Monad, MegaETH, and Pharos, we have also observed that there are some projects in the market that explore the application path of GPU acceleration in EVM parallel computing, as an important supplement 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 with GPU parallel execution architecture. Its core is to reconstruct the EVM execution process and realize native parallelization of the execution layer through multi-threaded scheduling, asynchronous state storage and GPU accelerated execution of transaction batches. The parallel granularity belongs to the transaction level + operation level (multi-threaded execution of opcode). 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. The difference lies in the reconstruction of the execution engine through the GPU parallel architecture, which is designed for high-throughput and compute-intensive scenarios (such as AI reasoning). The SDK is now online and provides integrable execution modules
• GatlingX calls itself "GPU-EVM" and proposes a more radical architecture, attempting to migrate the traditional EVM virtual machine's "instruction-level serial execution" model to the GPU's native parallel operating environment. Its core mechanism is to dynamically compile EVM bytecode into CUDA parallel tasks, and execute instruction streams through GPU multi-cores, thereby breaking the sequential bottleneck of EVM at the bottom level. It belongs to the parallel granularity of instruction-level parallelism (ILP). Compared with the "transaction-level/account-level" parallel granularity of Monad/MegaETH, GatlingX's parallel mechanism belongs to the instruction-level optimization path, which is closer to the underlying reconstruction of the virtual machine engine. It is currently in the conceptual stage, and has released white papers and architecture sketches, but no SDK or mainnet yet.

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

3. Native parallel architecture chain: Reconstructing the execution entity of VM

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

• Natural separation of state models: Solana adopts an account lock declaration mechanism, MoveVM introduces an object ownership model, and Sei v2 is based on transaction type classification to achieve static conflict determination and support 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 a multi-threaded matching engine and a parallel VM module.

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

3.1 Solana and SVM-based Sealevel parallel engine principle

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

Core Mechanics:

1. Explicit Account Access Lists: Each transaction must declare the accounts (read/write) involved when it is submitted, and the system uses this to determine whether there is a status conflict between transactions.

2. Conflict detection and multi-threaded scheduling

• If the account sets accessed by the two transactions have no intersection → they can be executed in parallel;
• If there is a conflict, execute serially in the order of dependency;
• 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, without a shared stack, to avoid cross-call interference.

SealevelSealevel is Solana's parallel execution scheduling engine, and SVM is a 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 Solana VM to modular chains (such as Ethereum L2 or Celestia), using Solana's parallel execution engine as the Rollup execution layer. Eclipse is one of the first projects to propose to move Solana's execution layer (Sealevel + SVM) away from the Solana mainnet and migrate it to a modular architecture, modularizing Solana's "super concurrent execution model" as an Execution Layer-as-a-Service, so Eclipse also belongs to the category of parallel computing.

Neon takes a different approach, introducing EVM to run in the SVM/Sealevel environment. By building an EVM-compatible runtime layer, developers can use Solidity to develop contracts and run them in the SVM environment, but the scheduling execution uses SVM + Sealevel. Neon is more inclined to the category of modular blockchain and does not emphasize parallel computing innovation.

In summary, Solana and SVM rely on the Sealevel execution engine. Solana's operating system scheduling philosophy is similar to the kernel scheduler, which is fast in execution but relatively inflexible. It is a native high-performance, parallel computing public chain.

3.2 MoveVM Architecture: Resource and Object Driver

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

Sui's object ownership model

Sui's parallel computing capabilities stem from its unique state modeling method and language-level static analysis mechanism. Unlike traditional blockchains that use a global state tree, Sui has built an object-centric model based on "objects" and combined it with MoveVM's linear type system to make parallel scheduling a deterministic process that can be completed at compile time.

• The Object Model is the foundation of Sui's parallel architecture. Sui abstracts all states on the chain into independent objects, each of which has a unique ID, a clear owner (account or contract), and a type definition. These objects do not share states with each other and are naturally isolated. When calling a contract, the contract must explicitly declare the set of objects involved, avoiding the state coupling problem of the "global state tree" on the traditional chain. This design divides the on-chain state into several independent units, making concurrent execution a structurally feasible scheduling prerequisite.
• Static Ownership Analysis is a compile-time analysis mechanism implemented with the support of the linear 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, so as to arrange them for parallel execution. Compared with the conflict detection and rollback in the traditional runtime, Sui's static analysis mechanism greatly reduces the scheduling complexity while improving the execution efficiency, which is the key to its high-throughput and deterministic parallel processing capabilities.

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

Aptos' Block-STM Implementation Mechanism

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

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

• Optimistic concurrent execution (Speculative Execution): All transactions are conflict-free by default before execution. The system schedules transactions in parallel to multiple threads for concurrent execution and records the account status (read set/write set) accessed.
• Conflict Detection and Verification (Validation Phase): The system verifies the execution results: If there is a read-write conflict between two transactions (such as Tx1 reads the state written by Tx2), one of them will be rolled back.
• Conflicting transactions are rolled back and retried (Retry Phase): Conflicting transactions will be rescheduled for execution until their dependencies are resolved, and eventually all transactions form a valid and deterministic state submission sequence.

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

Solana is an engineering scheduling school, more like an "operating system kernel", suitable for clear state boundaries, controllable high-frequency transactions, and has the style of a hardware engineer, running the chain like hardware (Hardware-grade parallel execution); Aptos is a system fault tolerance school, more like a "database concurrency engine", suitable for contract systems with strong state coupling and complex call chains; Sui is a compilation security school, more like a "resource-based intelligent language platform", suitable for on-chain applications with clear asset separation and combination. Aptos and Sui should be like programming language engineers and run the chain as safely as software (Software-grade resource security). The three represent the technical implementation paths of Web3 parallel computing under different philosophies.

3.3 Cosmos SDK Parallel Expansion

Sei V2 is a high-performance transaction-based public chain built on the Cosmos SDK. Its parallel capabilities are mainly reflected in two aspects: the parallel execution optimization of the multi-threaded matching engine (Parallel Matching Engine) and the virtual machine layer, which aims to serve high-frequency, low-latency on-chain transaction scenarios, such as order book DEX, on-chain exchange infrastructure, etc.

Core parallel mechanism:

1. Parallel matching engine: Sei V2 introduces a multi-threaded execution path in the order matching logic, splitting the order book and matching logic at the thread level, so that the matching tasks between multiple markets (trading pairs) can be processed in parallel to avoid 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 without state conflicts, and cooperates with the transaction type classification mechanism to achieve higher throughput control.
3. Parallel consensus 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, and improve the overall block processing efficiency.

3.4 UTXO Model Reconstructor Fuel

Fuel is a high-performance execution layer designed based on the modular architecture of Ethereum. Its core parallel mechanism is derived from the improved UTXO model (Unspent Transaction Output). Unlike Ethereum's account model, Fuel uses the UTXO structure to represent assets and states. This model naturally has state isolation, making it easier to determine which transactions can be safely executed in parallel. In addition, Fuel introduces the self-developed smart contract language Sway (similar to Rust), and combines it with static analysis tools to determine input conflicts before transaction execution, thereby achieving efficient and secure transaction-level parallel scheduling. It is an EVM alternative execution layer that takes into account both performance and modularity.

IV. Actor Model: A new paradigm for concurrent execution of intelligent agents

The Actor Model is a parallel execution paradigm based on agent processes (Agent or Process). Different from the traditional synchronous calculation of global states on the chain (Solana/Sui/Monad and other "on-chain parallel computing" scenarios), it emphasizes that each agent has independent state and behavior, and communicates and schedules through asynchronous messages. Under this architecture, the on-chain system can be run concurrently by a large number of decoupled processes, with strong scalability and asynchronous fault tolerance. Representative projects include AO (Arweave AO), ICP (Internet Computer) and Cartesi, which are driving the evolution of blockchain from 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 has some similarities with Sharding in terms of surface features (such as parallelism, state isolation, and asynchronous processing), in essence, the two represent completely different technical paths and system philosophies. The Actor Model emphasizes "multi-process asynchronous computing", and each agent (Actor) runs independently, maintains its state independently, and interacts in a message-driven manner; while sharding is a "horizontal segmentation of state and consensus" mechanism that divides the entire blockchain into multiple subsystems (Shards) that independently process transactions. The Actor Model is more like a "distributed agent operating system" in the Web3 world, while sharding is a structural expansion solution for the transaction processing capabilities within the chain. Both achieve parallelism, but with different starting points, goals, and execution architectures.

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

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

Core architectural features:

• Process architecture: Each agent is called a process, which has 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 with each other through messages, using a lock-free asynchronous operation model, and naturally supporting concurrent expansion;
• Permanent state storage: All agent states, message records, and instructions are permanently recorded on Arweave, ensuring full auditability and decentralized transparency;
• Agent-native: Suitable for deploying complex multi-step tasks (such as AI agents, DePIN protocol controllers, automatic task schedulers, etc.), and can build an "on-chain AI Coprocessor".

AO takes the ultimate "intelligent native + storage-driven + chainless architecture" route, emphasizing flexibility and module decoupling. It is an "on-chain microkernel framework built on the storage layer". The system boundaries are deliberately shrunk, emphasizing lightweight computing + composable control structure.

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

ICP is a Web3 native full-stack on-chain application platform launched by DFINITY. Its goal is to expand on-chain computing capabilities to a Web2-like experience and support complete service hosting, domain name binding and serverless architecture.

Core architectural features:

• Canister architecture (container as agent): Each Canister is an agent running on Wasm VM, with independent state, code and asynchronous scheduling capabilities;
• Subnet Distributed Consensus System (Subnet): The entire network consists of multiple Subnets, each of which maintains a set of Canisters and reaches consensus through the BLS signature mechanism;
• Asynchronous call model: Canisters communicate with each other through asynchronous messages, supporting non-blocking execution and natural parallelism;
• On-chain web hosting: supports smart contracts to directly host front-end pages, native DNS mapping, and is the first blockchain platform that supports browsers to directly access dApps;
• The system is fully functional: it has system APIs such as on-chain hot upgrades, authentication identity, distributed randomness, timers, etc., and is suitable for complex on-chain service deployment.

ICP chooses an operating system paradigm that emphasizes platform, integrated packaging, and strong platform control. It has a "blockchain operating system" that integrates consensus, execution, storage, and access. It emphasizes complete service hosting capabilities, and the system boundaries are expanded to a full-stack Web3 hosting platform.

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

V. Summary and Outlook

Based on the differences in virtual machine architecture and language system, 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, while retaining the compatibility of the EVM/Solidity ecosystem, achieves higher throughput and parallel processing capabilities by deeply optimizing the execution layer. It is suitable for scenarios that want to inherit Ethereum assets and development tools while achieving performance breakthroughs. Representative projects include:

• Monad: Implement an optimistic parallel execution model compatible with EVM through delayed writing and runtime conflict detection. After consensus is completed, a dependency graph is built and multi-threaded scheduling is performed.
• MegaETH: Abstract each account/contract into an independent micro-virtual machine (Micro-VM), and achieve highly decoupled account-level parallel scheduling based on asynchronous message passing and state dependency graph.
• Pharos: Builds a Rollup Mesh architecture and achieves system-level parallel processing across processes through asynchronous pipelines and collaboration with SPN modules.
• Reddio: Adopts zkRollup + GPU architecture, focusing on accelerating the off-chain verification process of zkEVM through batch SNARK generation and improving verification throughput.

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

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

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

• AO (Arweave AO): Building an on-chain asynchronous microkernel system based on a persistent storage-driven intelligent runtime;
• ICP (Internet Computer): uses containerized intelligent entities (Canister) as the smallest unit and achieves asynchronous and highly scalable execution through subnet coordination;
• 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 summarize the current mainstream parallel computing public chain solutions into the classification structure shown in the following chart:

From a broader perspective of capacity expansion, Sharding and Rollup (L2) focus on achieving system-level expansion through state segmentation or off-chain execution, while parallel computing chains (such as Monad, Sui, Solana) and Actor Oriented systems (such as AO, ICP) directly reconstruct the execution model to achieve native parallelism within the chain or at the system level. The former improves intra-chain throughput through multi-threaded virtual machines, object models, transaction conflict analysis, etc.; the latter uses processes/agents as basic units, and adopts message-driven and asynchronous execution methods to achieve multi-agent concurrent operation. In comparison, Sharding and Rollup are more like "splitting the load to multiple chains" or "outsourcing to the chain", while parallel chains and Actor models "release performance potential from the execution engine itself", reflecting a more thorough direction of architectural evolution.

Comparison of Parallel Computing vs Sharding Architecture vs Rollup Scaling vs Actor Oriented Scaling Paths

It should be pointed out 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 have become core public chains that have attracted much attention from the market due to their high-performance execution architecture and the gradual prosperity of ecological applications.

In contrast, although the Ethereum Rollup (L2) ecosystem has entered the stage of "all chains launched simultaneously" or even "overcapacity", the current mainstream EVM-based parallel enhanced chains are still generally in the testnet stage and have not been actually verified in the mainnet environment. Their expansion capabilities and system stability still need further testing. As for whether these projects can significantly improve EVM performance without sacrificing compatibility and promote ecological transition, or instead aggravate the further differentiation of Ethereum liquidity and development resources, it remains to be tested by time.