jacobzhao
The well-known Blockchain Trilemma—Security, Decentralization, and Scalability—reveals a fundamental tradeoff in blockchain system design: it's extremely difficult for a blockchain to simultaneously achieve maximum security, full decentralization, and high-throughput processing.
To address the ever-relevant challenge of scalability, today’s blockchain ecosystem presents a diverse set of scaling solutions. These can be categorized into several distinct paradigms:
Execution-enhancement scaling: Directly improving execution performance (e.g., through parallelism, GPU acceleration, multi-threading).
State-isolation scaling: Horizontally splitting state (e.g., sharding, UTXO models, multi-subnet systems).
Off-chain delegation scaling: Outsourcing execution off-chain (e.g., Rollups, coprocessors, data availability layers).
Structural-decoupling scaling: Modularizing architecture and enabling cooperative execution (e.g., modular blockchains, shared sequencers, Rollup Mesh networks).
Asynchronous concurrency scaling: Leveraging the Actor model with process isolation and message-driven execution (e.g., smart agents, multi-threaded async blockchains).
Blockchain scalability solutions encompass a wide range of techniques—intra-chain parallelism, Rollups, sharding, data availability modules (DA), modular architectures, Actor-based systems, zk-proof compression, and stateless architectures. These approaches span multiple layers, including execution, state, data, and structural layers, forming a multi-layered, modular, and composable scalability system. This report focuses specifically on intra-chain parallel computation as the core scalability paradigm.
Intra-chain parallelism targets the concurrent execution of transactions or instructions within a single block. Based on the underlying mechanism, intra-chain scalability can be categorized into five main models, each representing distinct tradeoffs in terms of performance, developer experience, architectural philosophy, and scheduling complexity. As the granularity of parallelism increases, so do performance potential, implementation difficulty, and programming model complexity:
Account-level Parallelism – e.g., Solana
Object-level Parallelism – e.g., Sui
Transaction-level Parallelism – e.g., Monad, Aptos
Call-level / Micro-VM Parallelism – e.g., MegaETH
Instruction-level Parallelism – e.g., GatlingX
In contrast, actor-based models such as AO, ICP, and Cartesi represent a fundamentally different form of parallel computation. These systems operate as asynchronous, event-driven agent networks, where each Agent (Process) is an independent execution unit. Rather than synchronous block-based computation, these agents communicate through asynchronous message passing—removing the need for global consensus or synchronized scheduling. This model forms the basis for cross-chain and decentralized AI architectures, not traditional block-by-block execution.
While well-known solutions like Rollups and Sharding also enable scalability, they belong to the category of system-level concurrency, not intra-chain parallelism. These models achieve scalability by running multiple independent execution environments (chains or rollups) in parallel, rather than increasing the execution concurrency within a single block or VM. As such, they are not the focus of this report, though we will refer to them in architectural comparisons to highlight design contrasts.
🔍 Types of Parallelism in Web3 Execution
Ethereum's serial processing architecture has undergone several waves of scalability efforts, including sharding, rollups, and modular architectures. However, the throughput bottleneck at the execution layer remains unresolved. At the same time, EVM and Solidity continue to dominate as the most widely adopted smart contract platforms. As a result, EVM-compatible parallel execution chains—which aim to improve performance without sacrificing ecosystem compatibility—have emerged as a promising direction in the evolution of blockchain scalability. Among them, Monad and MegaETH are two of the most representative projects, tackling high-throughput execution through deferred execution and state decomposition respectively.
Monad is a high-performance Layer 1 blockchain designed to be EVM-compatible, reimagined with a core focus on pipelined parallel execution. It introduces asynchronous execution at the consensus layer and optimistic parallel execution at the execution layer. Additionally, it implements MonadBFT (a high-performance BFT consensus protocol) and MonadDB (a purpose-built database), enabling end-to-end system optimization.
Pipelining: Monad decomposes the transaction lifecycle into multiple pipeline stages (Propose → Consensus → Execute → Commit), allowing each stage to be processed independently and concurrently in different threads or cores. This multilayered pipeline boosts throughput and reduces latency.
Asynchronous Execution: In traditional blockchains, consensus and execution are tightly coupled. Monad decouples them:
The consensus layer is responsible only for transaction ordering.
Execution is triggered asynchronously after consensus.
The system can begin processing the next block’s consensus phase without waiting for prior execution to complete.
This approach improves elasticity, reduces block time and confirmation latency, and increases resource utilization.
Optimistic Parallel Execution: Monad assumes most transactions do not conflict and runs them in parallel optimistically:
A Conflict Detector monitors for state access conflicts (e.g., overlapping reads/writes).
Conflicting transactions are re-executed serially to maintain state correctness.
Monad follows a “minimal disruption” design—preserving EVM semantics while enabling high-performance execution. It's best viewed as a "parallel accelerator" for Ethereum, with high compatibility and ease of ecosystem migration.
Unlike Monad’s L1 positioning, MegaETH is designed as a modular, high-performance parallel execution layer that is EVM-compatible. It can operate as an independent Layer 1 or as a plug-in execution layer for Ethereum. Its core design goal is to deconstruct account logic, execution environments, and state into minimal, independently schedulable units—allowing high concurrency and low latency.
Micro-VM Architecture:
MegaETH adopts a “one account = one Micro-VM” model. Each account runs in an isolated execution thread with its own storage and logic. These Micro-VMs communicate through asynchronous messaging rather than synchronous function calls. This design enables inherent parallelism and modular scheduling.
State Dependency DAG:
MegaETH maintains a real-time Directed Acyclic Graph (DAG) of account state dependencies:
Each transaction’s reads/writes are modeled into the DAG.
Non-conflicting transactions can execute in parallel.
Dependent transactions are serialized or rescheduled according to the DAG topology.
This ensures deterministic execution and prevents duplicate state writes in concurrent processing.
Asynchronous Execution Model:
MegaETH employs a programming paradigm similar to the Actor Model, using asynchronous message passing to replace traditional call stacks. When contract A calls B, which then calls C, these calls are converted into an asynchronous call graph. Transaction execution becomes: Traverse Call Graph → Resolve Dependencies → Parallel Execution.
MegaETH breaks away from Ethereum’s single-threaded state machine by encapsulating accounts into Micro-VMs, scheduling via a dependency graph, and communicating via async messages. It’s a fully rearchitected parallel execution platform, optimized for the next generation of high-performance blockchain systems.
Where Monad takes a compatibility-first, EVM-optimized path, MegaETH opts for a deep architectural redesign, turning the Ethereum execution model into a highly concurrent, thread-like runtime. Its theoretical upper limit for parallelism is higher—but so is its complexity. MegaETH resembles a distributed operating system built on Ethereum principles.
While both Monad and MegaETH target high-throughput parallel execution, their approaches differ fundamentally from sharding.
Sharding expands horizontally at the network level by splitting the blockchain into multiple independent shards, each responsible for part of the state and transaction load. This breaks the single-chain limitation by running many sub-chains in parallel.
Monad and MegaETH, in contrast, preserve the integrity of a single chain and scale horizontally within the execution layer, aiming to maximize parallel execution inside the same chain rather than splitting it.
Thus, they represent two complementary directions in blockchain scalability:
Sharding = Horizontal Network Partitioning
Monad/MegaETH = Vertical Execution Optimization
Monad and MegaETH, as representatives of parallel execution projects, primarily focus on throughput optimization—aiming to maximize on-chain TPS. They achieve this by enabling transaction-level or account-level parallelism through mechanisms such as Deferred Execution and Micro-VM architectures.
In contrast, Pharos Network is a modular, full-stack parallel Layer 1 blockchain, whose core parallel computation architecture is called the Rollup Mesh. This architecture coordinates between the mainnet and Specialized Processing Networks (SPNs) to support multi-VM environments (EVM and WASM) and integrates advanced technologies like zero-knowledge proofs (ZK) and Trusted Execution Environments (TEE).
Full Lifecycle Asynchronous Pipelining:
Pharos decouples the transaction lifecycle (e.g., consensus, execution, storage) into separate stages that are processed asynchronously and in parallel, significantly boosting overall throughput.
Dual VM Parallel Execution:
Pharos supports both EVM and WASM environments, allowing developers to choose their preferred execution layer. This dual-VM architecture enhances system flexibility while enabling parallel contract execution.
Specialized Processing Networks (SPNs):
SPNs are modular sub-networks designed to handle specialized tasks or application domains. By distributing workload across SPNs, Pharos achieves dynamic resource allocation and workload parallelization, enhancing both scalability and system performance.
Modular Consensus & Restaking:
Pharos supports multiple consensus mechanisms (PBFT, PoS, PoA) and introduces a restaking protocol to securely bridge and coordinate between the mainnet and SPNs, ensuring unified security and economic alignment.
In addition, Pharos has rebuilt the execution model from the storage engine layer by integrating multi-version Merkle trees, delta encoding, versioned addressing, and ADS pushdown, launching Pharos Store—a high-performance, blockchain-native storage engine that delivers high throughput, low latency, and strong verifiability for on-chain computation.
In summary, Pharos' Rollup Mesh achieves high-performance parallel computing through modular design and asynchronous task processing. Rather than being an intra-chain execution optimizer like Monad or MegaETH, Pharos acts as a cross-Rollup scheduler and orchestrator, with SPNs serving as custom, parallelized execution environments.
In addition to the execution-layer parallelism represented by Monad, MegaETH, and Pharos, the ecosystem is also exploring GPU-accelerated EVM execution as a frontier for performance breakthroughs. Two notable projects in this category are Reddio and GatlingX.
Reddio is a high-performance platform that combines zkRollup with a GPU-based parallel execution architecture. Its core innovation lies in reengineering the EVM execution process by leveraging multi-threaded scheduling, asynchronous state storage, and GPU-accelerated batch transaction execution to achieve native parallelism at the execution layer. It operates at both the transaction-level and operation-level (multi-threaded opcode execution) granularity. The design introduces multi-threaded batch execution, asynchronous state loading, and GPU-parallelized transaction logic (CUDA-Compatible Parallel EVM).
Like Monad and MegaETH, Reddio also focuses on parallel execution at the execution layer. However, it differentiates itself by reconstructing the execution engine through a GPU-parallel architecture, purpose-built for high-throughput and compute-intensive scenarios such as AI inference. An SDK is already available, offering an integratable execution module.
GatlingX, which brands itself as a “GPU-EVM,” proposes a more radical architecture aimed at migrating the traditional EVM model of sequential, instruction-level execution to a GPU-native parallel environment. Its core mechanism dynamically compiles EVM bytecode into CUDA-parallelized tasks, enabling instruction stream execution across GPU cores—breaking the sequential bottleneck of EVM at the most fundamental layer. Compared with the transaction-level or account-level parallelism of Monad and MegaETH, GatlingX takes an instruction-level optimization route, more akin to a low-level virtual machine engine overhaul. It is currently at the conceptual stage, with a whitepaper and architectural sketch published, but no SDK or mainnet available yet.
The Ethereum Virtual Machine (EVM) was designed with a single-threaded architecture based on total transaction ordering + sequential execution, aimed at ensuring deterministic and consistent state transitions across all network nodes. However, this design presents inherent performance bottlenecks, limiting throughput and scalability.
In contrast, a new wave of natively parallel chains—such as Solana (SVM), MoveVM-based chains like Sui and Aptos, and Sei v2 (built on Cosmos SDK)—have been designed from the ground up for parallel execution, offering several key advantages:
Naturally separated state models:
Solana uses account-level access declaration, MoveVM introduces object ownership models, and Sei v2 leverages transaction-type classification to enable static conflict detection and transaction-level concurrency.
VMs optimized for concurrency:
Solana’s Sealevel engine supports native multi-threaded execution; MoveVM performs static concurrency graph analysis; and Sei v2 integrates multi-threaded matching engines and parallel VM modules.
That said, native parallel chains also face ecosystem compatibility challenges. Non-EVM architects often require entirely new languages (e.g., Move or Rust) and toolchains, introducing migration costs. Developers also need to understand new concepts such as state access models, concurrency constraints, and object lifecycles—raising both cognitive and development complexity.
Solana’s Sealevel execution model is a transaction scheduler built for account-level parallelism. It powers Solana’s high-performance on-chain concurrency through a mechanism of account declaration + static scheduling + multi-threaded execution. Sealevel was the first execution engine in production to achieve intra-block parallelism and has influenced many later parallel VM designs.
Explicit Account Access Lists:
Every transaction must declare its read/write accounts. The runtime uses this to detect conflicts.
Conflict Detection & Multithreaded Scheduling:
If two transactions access disjoint account sets → execute in parallel.
If there's a conflict → execute serially based on dependency ordering.
The scheduler assigns transactions to different threads using a dependency graph.
Isolated Program Invocation Contexts:
Each contract call runs in its own isolated context, avoiding shared stacks or cross-call interference.
Sealevel is the parallel execution engine, while the Solana Virtual Machine (SVM)—which uses the BPF virtual machine—sits on top. Together, they form the technical backbone of Solana’s parallel runtime.
Eclipse is a project that ports the Solana VM to modular blockchains (e.g., Ethereum L2 or Celestia), using Sealevel as the Rollup execution layer. As the first to modularize Solana’s execution stack, Eclipse represents a new model: Execution Layer-as-a-Service, falling under the broader parallel execution category.
Neon takes a different path by bringing the EVM into Solana’s Sealevel environment. It allows developers to write Solidity contracts and run them in the SVM + Sealevel stack. Neon leans more toward modular blockchain design than parallel computing innovation.
In short, Solana and its SVM rely on Sealevel’s parallel scheduling engine. Solana’s kernel-style scheduling philosophy delivers blazing-fast execution with lower flexibility—representing a high-performance, native parallel Layer 1 chain.
MoveVM is a smart contract virtual machine designed for resource safety and parallelism. Its core language, Move, was developed by Meta (formerly Facebook) for the Libra project. It introduces the principle of “resources as objects”—each piece of on-chain state exists as an owned object with a defined lifecycle.
This object-centric model enables compile-time analysis of transaction conflicts, allowing for deterministic, object-level parallel scheduling. It powers native parallel chains like Sui and Aptos.
Sui’s parallel execution stems from its unique state model and language-level static analysis.
Unlike traditional blockchains that use a global state tree, Sui structures its state as discrete “Objects”, each with:
A unique ID
A clearly defined owner (user or contract)
A strict type definition
Objects are naturally isolated from one another. Smart contracts must explicitly declare which objects they touch, eliminating global state coupling and enabling structural separation of state—an essential precondition for safe concurrency.
Static Ownership Analysis:
Move’s linear type system allows the compiler to determine transaction conflicts before execution by analyzing object ownership.
This enables conflict-free transactions to be scheduled in parallel without needing runtime rollback or reordering—unlike optimistic execution models.
By partitioning state into objects and analyzing dependencies statically, Sui enables parallelism with low overhead and high determinism, improving performance, system predictability, and resource efficiency.
Aptos, another Move-based high-performance Layer 1, implements Block-STM (Block-level Software Transactional Memory) for parallelism. Unlike Sui’s compile-time static scheduling, Block-STM follows a runtime optimistic concurrency + conflict rollback strategy, ideal for complex interdependent transactions.
Speculative Execution:
All transactions are optimistically assumed conflict-free and executed in parallel across threads, with read/write sets recorded.
Validation Phase:
The system checks for conflicts—e.g., if Tx1 reads a value written by Tx2—then invalidates one of them.
Retry Phase:
Conflicting transactions are rescheduled until dependencies are resolved. The final output is a valid, deterministically ordered state transition.
Block-STM is a dynamic execution model based on “optimistic parallelism + rollback”. It is well-suited for batch processing of state-heavy, logic-complex transaction sets, forming the parallel computation backbone of Aptos' scalable architecture.
Solana represents the engineering-driven scheduling philosophy—more akin to an operating system kernel. It's best suited for high-frequency, tightly scoped transactions where state boundaries are well-defined and controllable. Solana embodies a hardware-engineer mindset, aiming to run the chain like hardware: hardware-grade parallel execution.
Aptos, by contrast, follows a fault-tolerant systems approach, resembling a concurrent database engine. It’s ideal for complex smart contract systems with deeply intertwined states and long dependency chains.
Sui embodies the compile-time safety paradigm, resembling a resource-oriented smart language platform. It excels in applications with clear asset separation and composability.
Together, Aptos and Sui represent the software-engineer mindset—striving for software-grade resource safety and correctness in smart contract execution.
These three projects—Solana, Aptos, and Sui—represent divergent philosophies and engineering approaches to Web3 parallel computing, each offering a distinct path toward scalable execution.
Sei V2 is a high-performance, trading-focused blockchain built on the Cosmos SDK. Its parallel execution capabilities are centered around two core innovations: a multi-threaded matching engine and parallel execution optimizations at the virtual machine layer. Sei is designed to serve high-frequency, low-latency on-chain trading use cases such as orderbook-based DEXs and on-chain trading infrastructure.
Parallel Matching Engine:
Sei V2 introduces multithreaded execution into the order matching logic by splitting the order book and matching algorithm across threads. This allows independent matching tasks (e.g., across trading pairs) to be processed concurrently, avoiding single-thread bottlenecks.
Virtual Machine-Level Concurrency:
Sei V2 enhances the CosmWasm VM with parallel execution capabilities, allowing non-conflicting contract calls to run concurrently. Combined with transaction-type classification, this improves throughput and system responsiveness.
Consensus-Execution Decoupling (Twin-Turbo):
Sei V2 introduces a “Twin-Turbo” consensus mechanism that decouples consensus throughput from execution scheduling, enabling higher overall block processing efficiency.
Fuel is a high-performance execution layer built with Ethereum modularity in mind. Its parallelism is rooted in a rearchitected UTXO (Unspent Transaction Output) model. Unlike Ethereum’s account-based model, Fuel leverages UTXOs to represent assets and state, offering natural state isolation, which simplifies conflict detection and enables safe parallel execution of transactions.
Fuel also introduces:
Sway, a Rust-inspired smart contract language;
Static analysis tooling, which pre-detects potential input conflicts before execution.
This design allows Fuel to achieve efficient, secure, transaction-level parallelism, making it a compelling modular EVM-compatible execution layer that balances performance with flexibility.
The Actor Model is a parallel execution paradigm centered on autonomous computational units—Agents or Processes. Unlike traditional on-chain systems that rely on synchronized global state (as in Solana, Sui, Monad, etc.), the Actor Model emphasizes independent state and behavior per agent, with asynchronous messaging as the basis for communication and coordination.
This architecture enables a blockchain system to support massively parallel, decoupled processes, offering exceptional scalability and asynchronous fault tolerance. Representative projects include AO (Arweave AO), ICP (Internet Computer), and Cartesi, which are advancing the evolution of blockchain systems from execution engines to "on-chain operating systems"—providing foundational infrastructure for AI agents, multi-task workflows, and complex logic orchestration.
Although the Actor Model shares some surface-level traits with sharding—such as parallelism, state isolation, and async execution—it is fundamentally distinct in both technical design and system philosophy.
Actor Model emphasizes asynchronous multi-process computation, where each Actor maintains its own state and interacts through message passing.
Sharding, by contrast, is a form of horizontal partitioning of state and consensus, splitting the blockchain into multiple subsystems (shards), each processing part of the network's transactions.
In essence, the Actor Model acts as a "distributed agent operating system" for the Web3 world, while sharding remains a structural scaling solution for intra-chain transaction throughput. Both achieve parallelism—but with different starting points, goals, and architectural strategies.
AO is a decentralized computation platform built on Arweave's permanent storage layer, with the core ambition of creating an on-chain operating system for massively asynchronous agent execution.
Process-Based Architecture: Each agent is a Process with its own state, scheduler, and execution logic.
No Blockchain Structure: AO is not a blockchain; it operates on top of Arweave using decentralized storage + a multi-agent, message-driven execution engine.
Asynchronous Messaging System: Communication between processes is fully async and lock-free, enabling scalable concurrency.
Permanent State Storage: All process state, messages, and instructions are immutably stored on Arweave, ensuring auditability and decentralization.
Agent-Native Design: Tailored for complex, multi-step workflows—such as AI agents, DePIN controllers, or automated orchestration systems—AO functions as an on-chain AI coprocessor framework.
AO follows a radical "agent-native + storage-driven + non-chain architecture" model. It focuses on flexibility and modular decomposition, functioning as a lightweight on-chain microkernel, purposefully minimizing system boundaries in favor of composable control and lean execution.
ICP, developed by DFINITY, is a Web3-native full-stack on-chain application platform. Its goal is to provide blockchain-level compute with Web2-grade usability, including full-service hosting, domain binding, and a serverless architecture.
Canister Architecture (Container-as-Agent):
Each Canister is an agent running in a Wasm VM, with independent state, code, and an async scheduler.
Subnet-Based Distributed Consensus:
The network is composed of multiple Subnets, each managing a set of Canisters and reaching consensus via BLS threshold signatures.
Asynchronous Call Model:
Canisters communicate via async messages, enabling non-blocking, parallel execution across the network.
On-Chain Web Hosting:
ICP supports direct hosting of frontend code on-chain, with native DNS integration. It was the first blockchain to enable browser-accessible dApps.
Comprehensive System APIs:
Includes built-in capabilities like hot upgrades, identity verification, distributed randomness, timers, and more—ideal for complex on-chain services.
ICP adopts a "heavyweight platform" model, embracing monolithic integration and full-stack control. With execution, consensus, storage, and access all tightly coupled, ICP functions as a true blockchain operating system, extending its boundaries into a full Web3 hosting stack.
Other Actor Model-based parallel computing projects are summarized in the table below:
Based on differences in virtual machine architecture and programming models, blockchain parallel computing solutions can be broadly categorized into two types: EVM-compatible parallel-enhanced chains and natively parallel architecture chains (non-EVM).
These chains retain full compatibility with the EVM/Solidity ecosystem, while implementing deep execution-layer optimizations to achieve higher throughput and parallelism. They are ideal for projects that want to leverage the Ethereum developer ecosystem while breaking through performance limits. Representative projects include:
Monad: Implements an optimistic parallel execution model compatible with EVM using deferred writes and runtime conflict detection, constructing a dependency graph post-consensus to enable multithreaded execution.
MegaETH: Treats each account/contract as an independent Micro-VM, using asynchronous message passing and a state dependency DAG to enable decoupled account-level parallel scheduling.
Pharos: Builds a Rollup Mesh architecture with asynchronous pipelining and SPN (Specialized Processing Network) modules, enabling system-level parallel coordination across execution stages.
Reddio: Uses a zkRollup + GPU-based architecture, focusing on accelerating off-chain zkEVM proof generation via batch SNARK processing to enhance verification throughput.
These architectures abandon Ethereum compatibility entirely, redesigning execution from the ground up—VMs, state models, and scheduling—to achieve native, high-performance parallelism. Key subtypes include:
Solana (SVM-based): Uses account access declarations and static conflict graphs to enable account-level parallelism at the transaction scheduler level.
Sui / Aptos (MoveVM-based): Built on a resource-object model and type system, enabling compile-time static analysis and object-level parallel execution.
Sei V2 (Cosmos SDK-based): Integrates multi-threaded matching engines and VM-level parallelism into the Cosmos stack, suited for high-frequency trading applications.
Fuel (UTXO + Sway): Uses a static UTXO input analysis model to enable transaction-level concurrency, along with a modular execution layer and a custom smart contract language, Sway.
The Actor Model, as a broader paradigm of concurrency, builds a new on-chain execution framework based on asynchronous process scheduling via Wasm or custom VMs. It emphasizes agent-level autonomy and message-driven coordination, enabling massive scalability and asynchronous composition. Representative projects include:
AO (Arweave AO): An agent runtime built on permanent storage (Arweave), forming an asynchronous on-chain microkernel system.
ICP (Internet Computer): Uses Canisters as containerized agents, coordinated via Subnets to achieve scalable, asynchronous execution across the network.
Cartesi: Introduces a Linux-based off-chain execution layer, where complex or compute-intensive logic is verified on-chain via provable results.
Based on these frameworks, we can summarize and classify the current landscape of mainstream parallel execution blockchain platforms using the following taxonomy diagram:
From a broader scalability perspective, sharding and Rollups (L2) focus on horizontal system expansion through state partitioning or off-chain execution. In contrast, parallel execution chains (e.g., Monad, Sui, Solana) and Actor-Oriented systems (e.g., AO, ICP) fundamentally rebuild the execution model, enabling native parallelism either within the chain or at the system level.
The former improves on-chain throughput through techniques like multi-threaded virtual machines, object-based state models, and transaction conflict analysis. The latter treats each process or agent as an independent unit, using message-driven and asynchronous execution to enable massive concurrency across agents.
In comparison, sharding and Rollups are more akin to “distributing load across multiple chains” or “outsourcing execution off-chain,” whereas parallel chains and actor-based systems aim to "unlock performance from within the execution engine itself"—representing a more fundamental architectural evolution.
🔍 Parallel Execution vs. Sharding vs. Rollup vs. Actor-Oriented: A Scalability Path Comparison
It is worth highlighting that most natively parallel architecture chains have already launched on mainnet. Although their overall developer ecosystems still fall short compared to the Solidity-based EVM stack, projects like Solana and Sui have emerged as high-profile Layer 1s—thanks to their high-performance execution architectures and the gradual growth of vibrant on-chain ecosystems.
In contrast, while the Ethereum Rollup (L2) ecosystem has entered a phase of “mass proliferation”—even facing concerns of overcapacity—the majority of EVM-compatible parallel-enhanced chains remain in the testnet stage, yet to be validated under real mainnet conditions. Their true scalability and system stability are still subject to further verification.
Whether these chains can significantly improve EVM performance without sacrificing compatibility, thus catalyzing a new wave of ecosystem evolution—or instead further fragment Ethereum’s liquidity and developer resources—remains to be seen.
