The Whale Who Was Up $100 M: Why I’m Leaving HyperLiquid
Protocol Survived, Users Didn’t I just made a personal—and painful—decision: I will no longer trade on HyperLiquid. I’m not calling for a boycott; I’m simply following the drift of my own values. After clearing $95 M on HL—and crossing nine figures across venues—my P&L is still positive this year. But on 10 October I lost $62 M in a single liquidation cascade. That day showed me the industry has out-grown its “hope and prayer” risk architecture.What Actually Happened on 10·10Binance’s interna...
From Meta to Blockchain Rising Stars: The Rise of Sui and Aptos
In recent years, the cryptocurrency market has experienced explosive growth. The success of mainstream cryptocurrencies like Bitcoin and Ethereum has attracted widespread attention from global investors. Emerging projects continue to emerge, offering a variety of investment opportunities. Investors are attracted by their high potential for returns, while also being aware of the market's high volatility and risks. Sui and Aptos are two blockchain projects that have recently garnered significan...
When the “Infinite-Ammo” mNAV Flywheel Reverses: Hidden Sell-Side Risks in the Crypto-Treasury Narra…
Executive Summary Treasury-driven alt-coins have turbo-charged this bull run. Ethereum has risen from US$1 800 to US$4 700 (+160 %) as listed “mini-MSTRs” like SBET and BMNR relentlessly buy ETH. Solana, BNB and HYPE have spawned copy-cat treasuries of their own. But the same flywheel that lifts prices can spin backwards. WINT—once a BNB-treasury poster-child—was delisted by Nasdaq and fell 91 %. Lion Group just trimmed US$500 k of its own HYPE stack. If mNAV (market-to-NAV ratio) drops below...
<100 subscribers
Support NFT
A Panoramic View of the Web3 Parallel Computing Track: The Best Native Scaling Solution?
Support NFT
A Panoramic View of the Web3 Parallel Computing Track: The Best Native Scaling Solution?
The Whale Who Was Up $100 M: Why I’m Leaving HyperLiquid
Protocol Survived, Users Didn’t I just made a personal—and painful—decision: I will no longer trade on HyperLiquid. I’m not calling for a boycott; I’m simply following the drift of my own values. After clearing $95 M on HL—and crossing nine figures across venues—my P&L is still positive this year. But on 10 October I lost $62 M in a single liquidation cascade. That day showed me the industry has out-grown its “hope and prayer” risk architecture.What Actually Happened on 10·10Binance’s interna...
From Meta to Blockchain Rising Stars: The Rise of Sui and Aptos
In recent years, the cryptocurrency market has experienced explosive growth. The success of mainstream cryptocurrencies like Bitcoin and Ethereum has attracted widespread attention from global investors. Emerging projects continue to emerge, offering a variety of investment opportunities. Investors are attracted by their high potential for returns, while also being aware of the market's high volatility and risks. Sui and Aptos are two blockchain projects that have recently garnered significan...
When the “Infinite-Ammo” mNAV Flywheel Reverses: Hidden Sell-Side Risks in the Crypto-Treasury Narra…
Executive Summary Treasury-driven alt-coins have turbo-charged this bull run. Ethereum has risen from US$1 800 to US$4 700 (+160 %) as listed “mini-MSTRs” like SBET and BMNR relentlessly buy ETH. Solana, BNB and HYPE have spawned copy-cat treasuries of their own. But the same flywheel that lifts prices can spin backwards. WINT—once a BNB-treasury poster-child—was delisted by Nasdaq and fell 91 %. Lion Group just trimmed US$500 k of its own HYPE stack. If mNAV (market-to-NAV ratio) drops below...
Share Dialog
Share Dialog
A deep dive into Web3 parallel computing.
The "Blockchain Trilemma" of security, decentralization, and scalability reveals the fundamental trade-offs in blockchain system design: it is extremely difficult for blockchain projects to simultaneously achieve maximum security, universal participation, and high-speed processing. Focusing on the eternal topic of scalability, the mainstream blockchain scaling solutions in the market can be categorized into paradigms such as:
Execution-Enhanced Scaling: Enhancing execution capabilities in place, such as parallelism, GPU, and multi-core.
State Isolation Scaling: Horizontal state sharding, such as sharding, UTXO, and multi-subnets.
Off-Chain Outsourcing Scaling: Offloading execution to off-chain, such as Rollup, Coprocessor, and DA.
Structural Decoupling Scaling: Modular architecture and collaborative operation, such as modular chains, shared sequencers, and Rollup Mesh.
Asynchronous Parallel Scaling: Actor model, process isolation, and message-driven, such as agents and multi-threaded asynchronous chains.
A Panoramic View of the Web3 Parallel Computing Track: The Best Native Scaling Solution?
Blockchain scaling solutions include intra-chain parallel computing, Rollup, sharding, DA modules, modular structures, Actor systems, zk proof compression, Stateless architecture, and more. These cover multiple layers including execution, state, data, and structure, forming a complete scaling system of "multi-layer collaboration and modular combination." This article focuses on the mainstream scaling approach based on parallel computing.
Intra-Chain Parallel Computing (Intra-chain Parallelism) focuses on the parallel execution of transactions/instructions within a block. Based on the parallelism mechanism, the scaling methods can be divided into five major categories, each representing different performance pursuits, development models, and architectural philosophies. The granularity of parallelism becomes finer, the strength of parallelism increases, and the complexity of scheduling, programming, and implementation also rises.
Account-Level Parallelism: Representative project: Solana
Object-Level Parallelism: Representative project: Sui
Transaction-Level Parallelism: Representative projects: Monad, Aptos
Call-Level / MicroVM Parallelism: Representative project: MegaETH
Instruction-Level Parallelism: Representative project: GatlingX
Off-Chain Asynchronous Concurrency Models, represented by the Actor Agent Model, belong to another parallel computing paradigm. They function as cross-chain/asynchronous messaging systems (non-block synchronization models), with each Agent operating as an independent "agent process." The parallelism is message-driven and event-driven, without the need for synchronized scheduling. Representative projects include AO, ICP, and Cartesi.
The well-known Rollup and sharding scaling solutions are system-level concurrency mechanisms and do not fall under intra-chain parallel computing. They achieve scaling by "running multiple chains/execution domains in parallel" rather than enhancing the parallelism within a single block/virtual machine. Although these solutions are not the focus of this article, they will still be used for comparative analysis of architectural concepts.
II. EVM Parallel Enhancement Chains: Breaking Through Performance Boundaries with Compatibility
The Ethereum's serial processing architecture has undergone multiple scaling attempts, including sharding, Rollup, and modular architecture. However, the throughput bottleneck at the execution layer has not been fundamentally resolved. Meanwhile, EVM and Solidity remain the most developer-friendly and ecosystem-empowered smart contract platforms. Therefore, EVM parallel enhancement chains, which balance ecological compatibility and execution performance improvement, are becoming a key path and an important direction for the next round of scaling evolution. Monad and MegaETH are the most representative projects in this direction, focusing on high-concurrency and high-throughput scenarios by adopting deferred execution and state decomposition to build parallel processing architectures for EVM.
Monad's Parallel Computing Mechanism Analysis
Monad is a high-performance Layer 1 blockchain redesigned for the Ethereum Virtual Machine (EVM), based on the fundamental parallel concept of pipelining. It employs 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, respectively, to achieve end-to-end optimization.
Pipelining: Multi-stage pipelined parallel execution mechanism
Pipelining is the core concept of Monad's parallel execution, which involves breaking down the blockchain execution process into multiple independent stages and parallelizing these stages to form a three-dimensional pipeline architecture. Each stage runs on independent threads or cores, enabling cross-block concurrent processing and ultimately improving throughput and reducing latency. These stages include: transaction proposal (Propose), consensus achievement (Consensus), transaction execution (Execution), and block commitment (Commit).
Asynchronous Execution: Decoupling consensus and execution
In traditional chains, transaction consensus and execution are typically synchronous processes, severely limiting scalability. Monad achieves asynchronous execution by decoupling the consensus layer, execution layer, and storage. This significantly reduces block time and confirmation latency, making the system more resilient, more finely divided in processing, and more efficient in resource utilization.
Optimistic Parallel Execution: Optimistic parallel execution
Traditional Ethereum executes transactions in a strictly serial model to avoid state conflicts. Monad, however, adopts an "optimistic parallel execution" strategy to significantly increase transaction processing rates.
Execution Mechanism:
Monad optimistically executes all transactions in parallel, assuming that most transactions do not conflict in state.
It runs a "conflict detector" to monitor whether transactions access the same state (e.g., read/write conflicts).
If conflicts are detected, the conflicting transactions are re-executed in series to ensure state correctness.
Monad chose a compatibility path: it minimizes changes to EVM rules, achieving parallelism by deferring state writes and dynamically detecting conflicts during execution. It is more like a performance-enhanced Ethereum, mature and easy to migrate to the EVM ecosystem, acting as a parallel accelerator for the EVM world.
MegaETH's Parallel Computing Mechanism Analysis
Unlike Monad's L1 positioning, MegaETH is designed as an EVM-compatible, modular, high-performance parallel execution layer. It can function 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 decompose account logic, execution environment, and state into independently schedulable units to achieve high-concurrency execution and low-latency response within the chain. MegaETH's key innovations include: Micro-VM architecture + State Dependency DAG (Directed Acyclic Graph of State Dependencies) and modular synchronization mechanisms, collectively forming a parallel execution system oriented towards "in-chain threading."
Micro-VM (Micro-Virtual Machine) Architecture: Accounts as Threads
MegaETH introduces an execution model of "one Micro-VM per account," threading the execution environment to provide the smallest isolation unit for parallel scheduling. These VMs communicate asynchronously through asynchronous messaging rather than synchronous calls, allowing a large number of VMs to execute and store independently, achieving natural parallelism.
State Dependency DAG: Dependency Graph-driven Scheduling Mechanism
MegaETH constructs a DAG scheduling system based on account state access relationships. The system maintains a global dependency graph in real-time, modeling which accounts each transaction modifies and reads. Conflict-free transactions can be executed in parallel, while transactions with dependencies are scheduled serially or delayed according to topological order. The dependency graph ensures state consistency and non-redundant 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, solving the traditional EVM's serial call problem. Contract calls are asynchronous (non-recursive execution); for example, when calling contracts A -> B -> C, each call is asynchronous without blocking. The call stack is expanded into an asynchronous call graph. Transaction processing involves traversing the asynchronous graph, resolving dependencies, and parallel scheduling.
In summary, MegaETH breaks the traditional EVM single-threaded state machine model, encapsulating accounts into micro-VMs, scheduling transactions based on state dependency graphs, and replacing synchronous call stacks with asynchronous messaging mechanisms. It is a parallel computing platform redesigned from the "account structure -> scheduling architecture -> execution process" in all dimensions, providing a paradigm-level new approach for building next-generation high-performance on-chain systems.
MegaETH chose a reconstruction path: completely abstracting accounts and contracts into independent VMs and releasing extreme parallel potential through asynchronous execution scheduling. Theoretically, MegaETH has a higher parallel ceiling but is more challenging to manage complexity. It is more like a super-distributed operating system under the Ethereum philosophy.
A Panoramic View of the Web3 Parallel Computing Track: The Best Native Scaling Solution?
The design philosophies of Monad and MegaETH are significantly different from sharding: Sharding horizontally slices the blockchain into multiple independent sub-chains (shards), with each shard responsible for a portion of transactions and state, breaking the single-chain limit at the network layer for scalability. In contrast, Monad and MegaETH maintain the integrity of a single chain, expanding horizontally only at the execution layer, optimizing parallel execution within the single chain to break through performance limitations. They represent two directions in blockchain scalability: vertical reinforcement and horizontal expansion.
Monad and MegaETH, among other parallel computing projects, primarily focus on throughput optimization, aiming to enhance intra-chain TPS through deferred execution and Micro-VM architectures to achieve parallel processing at the transaction or account level. In contrast, Pharos Network is a modular, full-stack parallel L1 blockchain network whose core parallel computing mechanism is called "Rollup Mesh." This architecture collaborates between the mainnet and Special Processing Networks (SPNs), supports multiple virtual machine environments (EVM and Wasm), and integrates advanced technologies such as zero-knowledge proofs (ZK) and Trusted Execution Environments (TEE).
Rollup Mesh Parallel Computing Mechanism Analysis:
Full Lifecycle Asynchronous Pipelining: Pharos decouples the various stages of a transaction (such as consensus, execution, and storage) and processes them asynchronously, allowing each stage to operate independently and in parallel, thereby improving overall processing efficiency.
Dual VM Parallel Execution: Pharos supports both EVM and WASM virtual machine environments, allowing developers to choose the appropriate execution environment based on their needs. This dual VM architecture not only increases system flexibility but also enhances transaction processing capabilities through parallel execution.
Special Processing Networks (SPNs): SPNs are a key component of the Pharos architecture, functioning as modular sub-networks dedicated to handling specific types of tasks or applications. Through SPNs, Pharos can dynamically allocate resources and process tasks in parallel, further enhancing the system's scalability and performance.
Modular Consensus and Restaking Mechanisms: Pharos introduces a flexible consensus mechanism that supports various consensus models (such as PBFT, PoS, PoA) and implements security sharing and resource integration between the mainnet and SPNs through a restaking protocol.
Additionally, Pharos reconstructs the execution model from the underlying storage engine through multi-version Merkle trees, delta encoding, versioned addressing, and ADS pushdown technology. It introduces the native blockchain high-performance storage engine Pharos Store, achieving high throughput, low latency, and strongly verifiable on-chain processing capabilities.
In summary, Pharos' Rollup Mesh architecture achieves high-performance parallel computing capabilities through modular design and asynchronous processing mechanisms. As a cross-Rollup parallel scheduler and coordinator, Pharos is not an "in-chain parallel" execution optimizer but rather a platform that uses SPNs to handle heterogeneous custom execution tasks.
In addition to the parallel execution architectures of Monad, MegaETH, and Pharos, we have also observed projects exploring the application of GPU acceleration in EVM parallel computing as an important supplement and cutting-edge experiment for the EVM parallel ecosystem. Two representative directions are Reddio and GatlingX:
Reddio: Reddio is a high-performance platform combining zkRollup with a GPU parallel execution architecture. Its core lies in restructuring the EVM execution process through multi-threaded scheduling, asynchronous state storage, and GPU-accelerated transaction batches to achieve native parallelization at the execution layer. It belongs to the granularity of transaction-level + operation-level (multi-threaded execution of opcodes) parallelism. 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, but it differs in that it reconstructs the execution engine through a GPU parallel architecture, specifically designed for high-throughput and compute-intensive scenarios (such as AI inference). It has already launched an SDK, providing an integrable execution module.
GatlingX: Self-proclaimed as "GPU-EVM," GatlingX proposes a more radical architecture, attempting to migrate the traditional EVM virtual machine's "instruction-level serial execution" model to a GPU-native parallel runtime environment. Its core mechanism dynamically compiles EVM bytecode into CUDA parallel tasks, executing instruction streams through GPU multi-core processing to break the sequential bottleneck of EVM at the most fundamental level. It belongs to the granularity of instruction-level parallelism (Instruction-Level Parallelism, ILP). Compared to Monad/MegaETH's "transaction-level/account-level" parallel granularity, GatlingX's parallel mechanism is an instruction-level optimization path, closer to a bottom-up reconstruction of the virtual machine engine. It is currently in the conceptual stage, having released a white paper and architectural sketch, but no SDK or mainnet is available yet.
Artela proposes a differentiated parallel design philosophy. By introducing the EVM++ architecture and a WebAssembly (WASM) virtual machine, it allows developers to dynamically add and execute extension programs on-chain while maintaining EVM compatibility. Using the Aspect programming model, it enables logic decoupling, asynchronous calls, and module-level parallel execution by injecting Extension modules (similar to "pluggable middleware") into EVM contract runtime at the granularity of contract calls (Function/Extension). It focuses more on the composability and modular architecture of the execution layer, offering new ideas for future complex multi-module applications.
III. Native Parallel Architecture Chains: Reconstructing the VM Execution Entity
Ethereum's EVM execution model was initially designed with a "transaction total order + serial execution" single-threaded architecture to ensure determinism and consistency of state changes across all nodes in the network. However, this architecture has inherent performance limitations that restrict 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 have been designed from the ground up for parallel execution, offering the following advantages:
Natively Separated State Models: Solana uses account lock declaration mechanisms, MoveVM introduces object ownership models, and Sei v2 is based on transaction type classification to achieve static conflict detection, supporting transaction-level concurrent scheduling.
VMs Optimized for Concurrency: Solana's Sealevel engine natively supports multi-threaded execution, MoveVM can perform static concurrency graph analysis, and Sei v2 integrates a multi-threaded matching engine and parallel VM modules.
Of course, these native parallel chains also face challenges in ecological compatibility. Non-EVM architectures typically require new development languages (such as Move, Rust) and toolchains, which pose certain migration costs for developers. Additionally, developers need to grasp new concepts such as state access models, concurrency limitations, and object lifecycles, raising the understanding threshold and development paradigm requirements.
3.1 Solana and SVM's Sealevel Parallel Engine Principle
Solana's Sealevel execution model is an account-based parallel scheduling mechanism and the core engine for Solana's intra-chain parallel transaction execution. Through the "account declaration + static scheduling + multi-threaded execution" mechanism, 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 a production environment, influencing many subsequent parallel computing projects and serving as a reference paradigm for high-performance Layer 1 parallel design.
Explicit Account Access Declaration (Account Access Lists): Each transaction must declare the accounts (read/write) it involves upon submission, allowing the system to determine whether there are state conflicts between transactions.
Conflict Detection and Multi-threaded Scheduling:
If two transactions have no intersection in their account sets → they can be executed in parallel.
If there is a conflict → they are executed serially according to dependency order.
The scheduler assigns transactions to different threads based on the dependency graph.
Independent Execution Context (Program Invocation Context): Each contract call runs in an isolated context without a shared stack, avoiding interference across calls.
Sealevel is Solana's parallel execution scheduling engine, while SVM is the smart contract execution environment built on top of Sealevel (using the BPF virtual machine). Together, they form the technical foundation of Solana's high-performance parallel execution system.
Eclipse is a project that deploys the Solana VM to modular chains (such as Ethereum L2 or Celestia), utilizing Solana's parallel execution engine as a Rollup execution layer. Eclipse is one of the earliest projects to propose decoupling Solana's execution layer (Sealevel + SVM) from the Solana mainnet and migrating it to a modular architecture, modularizing Solana's "super-concurrent execution model" as Execution Layer-as-a-Service. Therefore, Eclipse also falls under the category of parallel computing.
Neon takes a different approach by introducing EVM into the SVM/Sealevel environment. It builds a runtime layer compatible with EVM, allowing developers to write contracts in Solidity and run them in the SVM environment, but the scheduling execution uses SVM + Sealevel. Neon is more inclined towards the category of modular blockchains (Modular Blockchain) rather than emphasizing parallel computing innovation.
In summary, Solana and SVM rely on the Sealevel execution engine. Solana's operating system-style scheduling philosophy is similar to a kernel scheduler, which is fast in execution but relatively low in flexibility. It is a natively 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 safety and parallel execution. Its core language, Move, initially developed by Meta (formerly Facebook) for the Libra project, emphasizes the concept of "resources as objects." All on-chain states exist as objects with clear ownership and lifecycle. This allows MoveVM to analyze whether there are state conflicts between transactions at compile time, achieving object-level static parallel scheduling, widely used in native parallel public chains such as Sui and Aptos.
A deep dive into Web3 parallel computing.
The "Blockchain Trilemma" of security, decentralization, and scalability reveals the fundamental trade-offs in blockchain system design: it is extremely difficult for blockchain projects to simultaneously achieve maximum security, universal participation, and high-speed processing. Focusing on the eternal topic of scalability, the mainstream blockchain scaling solutions in the market can be categorized into paradigms such as:
Execution-Enhanced Scaling: Enhancing execution capabilities in place, such as parallelism, GPU, and multi-core.
State Isolation Scaling: Horizontal state sharding, such as sharding, UTXO, and multi-subnets.
Off-Chain Outsourcing Scaling: Offloading execution to off-chain, such as Rollup, Coprocessor, and DA.
Structural Decoupling Scaling: Modular architecture and collaborative operation, such as modular chains, shared sequencers, and Rollup Mesh.
Asynchronous Parallel Scaling: Actor model, process isolation, and message-driven, such as agents and multi-threaded asynchronous chains.
A Panoramic View of the Web3 Parallel Computing Track: The Best Native Scaling Solution?
Blockchain scaling solutions include intra-chain parallel computing, Rollup, sharding, DA modules, modular structures, Actor systems, zk proof compression, Stateless architecture, and more. These cover multiple layers including execution, state, data, and structure, forming a complete scaling system of "multi-layer collaboration and modular combination." This article focuses on the mainstream scaling approach based on parallel computing.
Intra-Chain Parallel Computing (Intra-chain Parallelism) focuses on the parallel execution of transactions/instructions within a block. Based on the parallelism mechanism, the scaling methods can be divided into five major categories, each representing different performance pursuits, development models, and architectural philosophies. The granularity of parallelism becomes finer, the strength of parallelism increases, and the complexity of scheduling, programming, and implementation also rises.
Account-Level Parallelism: Representative project: Solana
Object-Level Parallelism: Representative project: Sui
Transaction-Level Parallelism: Representative projects: Monad, Aptos
Call-Level / MicroVM Parallelism: Representative project: MegaETH
Instruction-Level Parallelism: Representative project: GatlingX
Off-Chain Asynchronous Concurrency Models, represented by the Actor Agent Model, belong to another parallel computing paradigm. They function as cross-chain/asynchronous messaging systems (non-block synchronization models), with each Agent operating as an independent "agent process." The parallelism is message-driven and event-driven, without the need for synchronized scheduling. Representative projects include AO, ICP, and Cartesi.
The well-known Rollup and sharding scaling solutions are system-level concurrency mechanisms and do not fall under intra-chain parallel computing. They achieve scaling by "running multiple chains/execution domains in parallel" rather than enhancing the parallelism within a single block/virtual machine. Although these solutions are not the focus of this article, they will still be used for comparative analysis of architectural concepts.
II. EVM Parallel Enhancement Chains: Breaking Through Performance Boundaries with Compatibility
The Ethereum's serial processing architecture has undergone multiple scaling attempts, including sharding, Rollup, and modular architecture. However, the throughput bottleneck at the execution layer has not been fundamentally resolved. Meanwhile, EVM and Solidity remain the most developer-friendly and ecosystem-empowered smart contract platforms. Therefore, EVM parallel enhancement chains, which balance ecological compatibility and execution performance improvement, are becoming a key path and an important direction for the next round of scaling evolution. Monad and MegaETH are the most representative projects in this direction, focusing on high-concurrency and high-throughput scenarios by adopting deferred execution and state decomposition to build parallel processing architectures for EVM.
Monad's Parallel Computing Mechanism Analysis
Monad is a high-performance Layer 1 blockchain redesigned for the Ethereum Virtual Machine (EVM), based on the fundamental parallel concept of pipelining. It employs 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, respectively, to achieve end-to-end optimization.
Pipelining: Multi-stage pipelined parallel execution mechanism
Pipelining is the core concept of Monad's parallel execution, which involves breaking down the blockchain execution process into multiple independent stages and parallelizing these stages to form a three-dimensional pipeline architecture. Each stage runs on independent threads or cores, enabling cross-block concurrent processing and ultimately improving throughput and reducing latency. These stages include: transaction proposal (Propose), consensus achievement (Consensus), transaction execution (Execution), and block commitment (Commit).
Asynchronous Execution: Decoupling consensus and execution
In traditional chains, transaction consensus and execution are typically synchronous processes, severely limiting scalability. Monad achieves asynchronous execution by decoupling the consensus layer, execution layer, and storage. This significantly reduces block time and confirmation latency, making the system more resilient, more finely divided in processing, and more efficient in resource utilization.
Optimistic Parallel Execution: Optimistic parallel execution
Traditional Ethereum executes transactions in a strictly serial model to avoid state conflicts. Monad, however, adopts an "optimistic parallel execution" strategy to significantly increase transaction processing rates.
Execution Mechanism:
Monad optimistically executes all transactions in parallel, assuming that most transactions do not conflict in state.
It runs a "conflict detector" to monitor whether transactions access the same state (e.g., read/write conflicts).
If conflicts are detected, the conflicting transactions are re-executed in series to ensure state correctness.
Monad chose a compatibility path: it minimizes changes to EVM rules, achieving parallelism by deferring state writes and dynamically detecting conflicts during execution. It is more like a performance-enhanced Ethereum, mature and easy to migrate to the EVM ecosystem, acting as a parallel accelerator for the EVM world.
MegaETH's Parallel Computing Mechanism Analysis
Unlike Monad's L1 positioning, MegaETH is designed as an EVM-compatible, modular, high-performance parallel execution layer. It can function 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 decompose account logic, execution environment, and state into independently schedulable units to achieve high-concurrency execution and low-latency response within the chain. MegaETH's key innovations include: Micro-VM architecture + State Dependency DAG (Directed Acyclic Graph of State Dependencies) and modular synchronization mechanisms, collectively forming a parallel execution system oriented towards "in-chain threading."
Micro-VM (Micro-Virtual Machine) Architecture: Accounts as Threads
MegaETH introduces an execution model of "one Micro-VM per account," threading the execution environment to provide the smallest isolation unit for parallel scheduling. These VMs communicate asynchronously through asynchronous messaging rather than synchronous calls, allowing a large number of VMs to execute and store independently, achieving natural parallelism.
State Dependency DAG: Dependency Graph-driven Scheduling Mechanism
MegaETH constructs a DAG scheduling system based on account state access relationships. The system maintains a global dependency graph in real-time, modeling which accounts each transaction modifies and reads. Conflict-free transactions can be executed in parallel, while transactions with dependencies are scheduled serially or delayed according to topological order. The dependency graph ensures state consistency and non-redundant 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, solving the traditional EVM's serial call problem. Contract calls are asynchronous (non-recursive execution); for example, when calling contracts A -> B -> C, each call is asynchronous without blocking. The call stack is expanded into an asynchronous call graph. Transaction processing involves traversing the asynchronous graph, resolving dependencies, and parallel scheduling.
In summary, MegaETH breaks the traditional EVM single-threaded state machine model, encapsulating accounts into micro-VMs, scheduling transactions based on state dependency graphs, and replacing synchronous call stacks with asynchronous messaging mechanisms. It is a parallel computing platform redesigned from the "account structure -> scheduling architecture -> execution process" in all dimensions, providing a paradigm-level new approach for building next-generation high-performance on-chain systems.
MegaETH chose a reconstruction path: completely abstracting accounts and contracts into independent VMs and releasing extreme parallel potential through asynchronous execution scheduling. Theoretically, MegaETH has a higher parallel ceiling but is more challenging to manage complexity. It is more like a super-distributed operating system under the Ethereum philosophy.
A Panoramic View of the Web3 Parallel Computing Track: The Best Native Scaling Solution?
The design philosophies of Monad and MegaETH are significantly different from sharding: Sharding horizontally slices the blockchain into multiple independent sub-chains (shards), with each shard responsible for a portion of transactions and state, breaking the single-chain limit at the network layer for scalability. In contrast, Monad and MegaETH maintain the integrity of a single chain, expanding horizontally only at the execution layer, optimizing parallel execution within the single chain to break through performance limitations. They represent two directions in blockchain scalability: vertical reinforcement and horizontal expansion.
Monad and MegaETH, among other parallel computing projects, primarily focus on throughput optimization, aiming to enhance intra-chain TPS through deferred execution and Micro-VM architectures to achieve parallel processing at the transaction or account level. In contrast, Pharos Network is a modular, full-stack parallel L1 blockchain network whose core parallel computing mechanism is called "Rollup Mesh." This architecture collaborates between the mainnet and Special Processing Networks (SPNs), supports multiple virtual machine environments (EVM and Wasm), and integrates advanced technologies such as zero-knowledge proofs (ZK) and Trusted Execution Environments (TEE).
Rollup Mesh Parallel Computing Mechanism Analysis:
Full Lifecycle Asynchronous Pipelining: Pharos decouples the various stages of a transaction (such as consensus, execution, and storage) and processes them asynchronously, allowing each stage to operate independently and in parallel, thereby improving overall processing efficiency.
Dual VM Parallel Execution: Pharos supports both EVM and WASM virtual machine environments, allowing developers to choose the appropriate execution environment based on their needs. This dual VM architecture not only increases system flexibility but also enhances transaction processing capabilities through parallel execution.
Special Processing Networks (SPNs): SPNs are a key component of the Pharos architecture, functioning as modular sub-networks dedicated to handling specific types of tasks or applications. Through SPNs, Pharos can dynamically allocate resources and process tasks in parallel, further enhancing the system's scalability and performance.
Modular Consensus and Restaking Mechanisms: Pharos introduces a flexible consensus mechanism that supports various consensus models (such as PBFT, PoS, PoA) and implements security sharing and resource integration between the mainnet and SPNs through a restaking protocol.
Additionally, Pharos reconstructs the execution model from the underlying storage engine through multi-version Merkle trees, delta encoding, versioned addressing, and ADS pushdown technology. It introduces the native blockchain high-performance storage engine Pharos Store, achieving high throughput, low latency, and strongly verifiable on-chain processing capabilities.
In summary, Pharos' Rollup Mesh architecture achieves high-performance parallel computing capabilities through modular design and asynchronous processing mechanisms. As a cross-Rollup parallel scheduler and coordinator, Pharos is not an "in-chain parallel" execution optimizer but rather a platform that uses SPNs to handle heterogeneous custom execution tasks.
In addition to the parallel execution architectures of Monad, MegaETH, and Pharos, we have also observed projects exploring the application of GPU acceleration in EVM parallel computing as an important supplement and cutting-edge experiment for the EVM parallel ecosystem. Two representative directions are Reddio and GatlingX:
Reddio: Reddio is a high-performance platform combining zkRollup with a GPU parallel execution architecture. Its core lies in restructuring the EVM execution process through multi-threaded scheduling, asynchronous state storage, and GPU-accelerated transaction batches to achieve native parallelization at the execution layer. It belongs to the granularity of transaction-level + operation-level (multi-threaded execution of opcodes) parallelism. 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, but it differs in that it reconstructs the execution engine through a GPU parallel architecture, specifically designed for high-throughput and compute-intensive scenarios (such as AI inference). It has already launched an SDK, providing an integrable execution module.
GatlingX: Self-proclaimed as "GPU-EVM," GatlingX proposes a more radical architecture, attempting to migrate the traditional EVM virtual machine's "instruction-level serial execution" model to a GPU-native parallel runtime environment. Its core mechanism dynamically compiles EVM bytecode into CUDA parallel tasks, executing instruction streams through GPU multi-core processing to break the sequential bottleneck of EVM at the most fundamental level. It belongs to the granularity of instruction-level parallelism (Instruction-Level Parallelism, ILP). Compared to Monad/MegaETH's "transaction-level/account-level" parallel granularity, GatlingX's parallel mechanism is an instruction-level optimization path, closer to a bottom-up reconstruction of the virtual machine engine. It is currently in the conceptual stage, having released a white paper and architectural sketch, but no SDK or mainnet is available yet.
Artela proposes a differentiated parallel design philosophy. By introducing the EVM++ architecture and a WebAssembly (WASM) virtual machine, it allows developers to dynamically add and execute extension programs on-chain while maintaining EVM compatibility. Using the Aspect programming model, it enables logic decoupling, asynchronous calls, and module-level parallel execution by injecting Extension modules (similar to "pluggable middleware") into EVM contract runtime at the granularity of contract calls (Function/Extension). It focuses more on the composability and modular architecture of the execution layer, offering new ideas for future complex multi-module applications.
III. Native Parallel Architecture Chains: Reconstructing the VM Execution Entity
Ethereum's EVM execution model was initially designed with a "transaction total order + serial execution" single-threaded architecture to ensure determinism and consistency of state changes across all nodes in the network. However, this architecture has inherent performance limitations that restrict 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 have been designed from the ground up for parallel execution, offering the following advantages:
Natively Separated State Models: Solana uses account lock declaration mechanisms, MoveVM introduces object ownership models, and Sei v2 is based on transaction type classification to achieve static conflict detection, supporting transaction-level concurrent scheduling.
VMs Optimized for Concurrency: Solana's Sealevel engine natively supports multi-threaded execution, MoveVM can perform static concurrency graph analysis, and Sei v2 integrates a multi-threaded matching engine and parallel VM modules.
Of course, these native parallel chains also face challenges in ecological compatibility. Non-EVM architectures typically require new development languages (such as Move, Rust) and toolchains, which pose certain migration costs for developers. Additionally, developers need to grasp new concepts such as state access models, concurrency limitations, and object lifecycles, raising the understanding threshold and development paradigm requirements.
3.1 Solana and SVM's Sealevel Parallel Engine Principle
Solana's Sealevel execution model is an account-based parallel scheduling mechanism and the core engine for Solana's intra-chain parallel transaction execution. Through the "account declaration + static scheduling + multi-threaded execution" mechanism, 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 a production environment, influencing many subsequent parallel computing projects and serving as a reference paradigm for high-performance Layer 1 parallel design.
Explicit Account Access Declaration (Account Access Lists): Each transaction must declare the accounts (read/write) it involves upon submission, allowing the system to determine whether there are state conflicts between transactions.
Conflict Detection and Multi-threaded Scheduling:
If two transactions have no intersection in their account sets → they can be executed in parallel.
If there is a conflict → they are executed serially according to dependency order.
The scheduler assigns transactions to different threads based on the dependency graph.
Independent Execution Context (Program Invocation Context): Each contract call runs in an isolated context without a shared stack, avoiding interference across calls.
Sealevel is Solana's parallel execution scheduling engine, while SVM is the smart contract execution environment built on top of Sealevel (using the BPF virtual machine). Together, they form the technical foundation of Solana's high-performance parallel execution system.
Eclipse is a project that deploys the Solana VM to modular chains (such as Ethereum L2 or Celestia), utilizing Solana's parallel execution engine as a Rollup execution layer. Eclipse is one of the earliest projects to propose decoupling Solana's execution layer (Sealevel + SVM) from the Solana mainnet and migrating it to a modular architecture, modularizing Solana's "super-concurrent execution model" as Execution Layer-as-a-Service. Therefore, Eclipse also falls under the category of parallel computing.
Neon takes a different approach by introducing EVM into the SVM/Sealevel environment. It builds a runtime layer compatible with EVM, allowing developers to write contracts in Solidity and run them in the SVM environment, but the scheduling execution uses SVM + Sealevel. Neon is more inclined towards the category of modular blockchains (Modular Blockchain) rather than emphasizing parallel computing innovation.
In summary, Solana and SVM rely on the Sealevel execution engine. Solana's operating system-style scheduling philosophy is similar to a kernel scheduler, which is fast in execution but relatively low in flexibility. It is a natively 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 safety and parallel execution. Its core language, Move, initially developed by Meta (formerly Facebook) for the Libra project, emphasizes the concept of "resources as objects." All on-chain states exist as objects with clear ownership and lifecycle. This allows MoveVM to analyze whether there are state conflicts between transactions at compile time, achieving object-level static parallel scheduling, widely used in native parallel public chains such as Sui and Aptos.
No comments yet