The disbanding of the Diem project (formerly known as Libra, or Facebook Coin) led to the emergence of several new blockchain initiatives developed by its former team members. In a recent analysis, Mohamed Fouda, a partner at venture capital firm Volt Capital, examined four prominent projects implementing parallel execution: Aptos, Sui, Linera, and Fuel.
This article provides a condensed overview of these innovative Layer 1 solutions. For those seeking more detailed technical insights, it is always advisable to consult the original sources directly.
The Limitations of Sequential Execution in EVM Blockchains
Understanding the EVM (Ethereum Virtual Machine)
Smart contract blockchains, like Ethereum, require a shared computational engine to run various decentralized applications (dApps). Network nodes operate this engine, execute the dApps, and interact with users. After nodes reach consensus on the execution results, the blockchain progresses.
The Ethereum Virtual Machine (EVM) is the primary execution engine for smart contracts and has been adopted by numerous other Layer 1 chains and Layer 2 scaling solutions.
The Core Issue: Execution Efficiency
A significant limitation of the EVM is its sequential nature; it processes transactions one at a time. While executing one transaction, all others are paused until it is complete and the blockchain's state is updated. This sequential execution creates a bottleneck, ultimately capping the network's overall transaction throughput (TPS).
The Opportunity of Parallel Execution
Several foundational Layer 1 (L1) blockchains are adopting a parallel execution (PE) approach. This method allows transactions to be processed simultaneously across different CPU cores, optimizing hardware usage to dramatically increase network throughput and improve transaction confirmation times.
Parallel execution is not a new concept. One idea involves changing the accounting model from the Accounts model (used by Ethereum) to the UTXO model (used by Bitcoin), which natively supports parallel processing for payments. However, because the basic UTXO model has limited functionality, it requires expansion to interact with complex smart contracts, as seen with Cardano's extended UTXO model.
Another approach to achieving PE is to enhance how the blockchain's state is structured and modified without changing the core accounting model. Solana's Sealevel is a prime example of this. The projects discussed here—Aptos, Sui, Linera, and Fuel—all follow this latter path. The central challenge lies in how the blockchain understands its state and, crucially, identifies independent transactions, separating them from dependent ones.
The RAM (Random-Access Memory) Analogy
A blockchain's state can be compared to a computer's RAM. Each blockchain account or smart contract controls a specific range of memory addresses that can be modified. Dependent transactions are those that need to modify the same memory location.
For example, a complex token swap on a decentralized exchange (DEX) might involve multiple interdependent steps (e.g., UNI -> ETH -> DAI -> USDC), which must be processed in sequence. Different blockchains employ various memory architectures and mechanisms to efficiently identify these dependent transactions. 👉 Explore more strategies for understanding blockchain scalability
Breaking Down the Parallel Execution Chains: Aptos, Sui, Linera, and Fuel
Aptos, Sui, and Linera utilize the Move programming language, originally developed by the Diem team, to enhance smart contract execution. Fuel, conversely, employs its own custom language and virtual machine designed for parallel processing.
Aptos
Aptos leverages the Move language and the Move Virtual Machine (MoveVM) to achieve high throughput via parallel execution. Its innovation is a modified Software Transactional Memory (STM) system called Block-STM.
In Block-STM, transactions within a block are pre-ordered and then processed optimistically by multiple processors. "Optimistic execution" means transactions are processed under the assumption that they have no dependencies. All memory locations touched by a transaction are recorded. After processing, the results are validated. If a transaction is found to have used a memory location modified by a prior transaction, it is invalidated and re-executed. This process repeats until all transactions in the block are successfully processed. Block-STM significantly accelerates processing with multiple cores, though its efficiency nears that of sequential processing if all transactions in a block are interdependent. Aptos claims a capacity of up to 160,000 TPS.
Sui
Sui takes a different PE approach by requiring transactions to explicitly declare which parts of the blockchain state they intend to modify. This method is similar to Solana's, which requires transactions to list the "accounts" they affect.
While Sui also uses a MoveVM, it implements a custom version of the Move language—Sui Move—which alters core storage modules and asset permissions. This defines a state storage model that makes identifying independent transactions more straightforward.
In Sui, state storage is organized around "objects," which represent assets. These objects can be shared and modified by multiple users. Each object has a unique ID and is linked to an owner's address. This structure makes tracing transaction dependencies simpler.
However, the task of declaring these dependencies falls on developers. While this makes the execution engine highly efficient and capable of immense throughput (Sui's testnet claims 100,000 TPS), it creates a less ideal developer experience.
Linera
Details on Linera are currently scarce. The project, which received funding from 16z (a16z), is based on the FastPay protocol developed at Facebook. FastPay utilizes a technique called Byzantine Consistent Broadcast, which is designed to facilitate extremely fast payment settlements. Its application to a broader smart contract platform remains to be fully detailed as the project develops.
Fuel
Fuel is distinct because it focuses solely on being a modular execution layer within a broader blockchain stack. It does not have its own consensus mechanism or data availability layer. Instead, Fuel offloads these functions to a base layer, like Ethereum, with which it interacts.
Fuel uses a UTXO model combined with a strict access list that identifies which entities have control over a specific state. This simplifies the process of identifying dependent transactions within a block. Fuel has its own FuelVM and Sway smart contract language. Its design allows for smart contract execution to be performed on Fuel and then securely settled on a base chain like Ethereum.
Key Challenges for Parallel Execution Blockchains
- Percentage of Parallelizable Transactions: The actual performance gain from PE depends heavily on the ratio of independent transactions (like simple transfers between addresses) to complex, interdependent ones (like multi-step DEX trades). Estimates suggest that PE could accelerate roughly 70-80% of transactions on a typical smart contract platform, potentially increasing throughput by 3 to 5 times.
- Network Centralization: High-throughput PE networks place significant demands on hardware. Consumer-grade equipment may struggle to run full nodes, potentially forcing users to rely on specialized node providers. This could lead to power being concentrated among a few entities, increasing the risk of censorship. While Sui's current testnet requirements are lower than Aptos's, this may change at mainnet launch. Fuel's alignment with Ethereum's decentralization ethos may mitigate this concern. The decentralization priorities of Aptos and Sui remain to be fully seen as their networks mature.
In conclusion, parallel execution is one of the most promising solutions for scaling smart contract platform throughput. Combined with innovations in consensus mechanisms, it has the potential to push TPS into the hundreds of thousands. However, maintaining a decentralized network structure while operating such high-performance infrastructure remains a significant challenge for the ecosystem.
Frequently Asked Questions
What is parallel execution in blockchain?
Parallel execution is a processing method where multiple transactions are handled simultaneously across different CPU cores, as opposed to one after another. This optimizes hardware usage and can dramatically increase a network's transaction throughput and speed.
How is Aptos's approach different from Sui's?
Both use the Move language but differ fundamentally. Aptos uses a "optimistic" model (Block-STM) that processes transactions without prior declaration of dependencies and re-executes them if conflicts are found. Sui requires developers to explicitly state which state objects a transaction will change, making dependency identification easier for the engine but placing more burden on developers.
Can parallel execution work with Ethereum?
Directly, the Ethereum Virtual Machine (EVM) processes transactions sequentially. However, projects like Fuel are designed as parallelized execution layers that settle their results on Ethereum, effectively bringing parallel execution benefits to the Ethereum ecosystem through a modular design.
What is the main trade-off with parallel execution?
A significant trade-off is the potential for increased network centralization. Running a node for a high-throughput PE chain often requires more powerful, expensive hardware, which could make it difficult for average users to participate, concentrating node operation among specialized providers.
Does parallel execution make transactions cheaper?
In theory, yes. By increasing the number of transactions the network can process per second (throughput), parallel execution should reduce competition for block space and lead to lower transaction fees for users, assuming demand remains constant.
Are these parallel execution chains live now?
As of this writing, Aptos and Sui have launched their mainnets, while Fuel and Linera are still in development or testing phases. It's important to check the latest status of each project as the ecosystem evolves rapidly.