A Deep Dive into Layer 1 Parallel Execution: How Aptos, Sui, Linera, and Fuel Make It Happen
TechFlow Selected TechFlow Selected
A Deep Dive into Layer 1 Parallel Execution: How Aptos, Sui, Linera, and Fuel Make It Happen
As we reexamine the evolution of blockchain technology, a strong trend emerges: new L1s are focusing on parallel execution.
Navigating Web3 tides with focused insights
Author: Mohamed Fouda
Translation: TechFlow
As we revisit the evolution of blockchain technology, a strong trend is emerging: new Layer 1 blockchains are increasingly focusing on parallel execution.
This is not a novel technique—Solana already employs it within its Sealevel execution environment.
However, the impressive performance of DeFi and NFTs during the last bull market has highlighted the urgent need for technological improvements.
In the next market cycle, several prominent projects adopting the concept of parallel execution are set to emerge: Aptos, Sui, Linera, and Fuel.
This article will explore their similarities and differences, as well as the challenges they face.
The Problem
Smart contract platforms enable a wide range of decentralized applications. To execute these applications, a shared computational engine is required. Every node in the network runs this engine, executing applications and user interactions with them. When nodes achieve identical results from execution, consensus is reached and the chain progresses.
The Ethereum Virtual Machine (EVM) is the dominant smart contract (SC) execution engine, with around 20 different implementations.
Since its invention, the EVM has achieved critical mass in developer adoption.
Beyond Ethereum and its Layer 2 solutions, several other chains—including Polygon, BNB Smart Chain, and Avalanche C-Chain—adopt the EVM as their execution engine, focusing instead on modifying consensus mechanisms to improve network throughput.
A major limiting feature of the EVM is the sequential execution of transactions. The EVM essentially executes one transaction at a time, holding all others until execution completes and the blockchain state is updated. Even if two transactions are independent—such as a payment from Alice to Bob and another from Carol to Dave—the EVM cannot execute them in parallel. While this execution model enables interesting use cases like flash loans, it is neither efficient nor scalable.
This sequential transaction execution is one of the primary bottlenecks for network throughput:
- First, it leads to longer transaction execution times within blocks, constraining block intervals;
- Additionally, it limits the number of transactions that can be included in a block, so that nodes can execute them and confirm the block.
Ethereum’s average throughput is about 17 tx/sec. This low throughput means that during periods of high activity—such as an NFT mint—network miners/validators cannot process all transactions, leading to fee bidding wars to secure priority execution and driving up transaction costs. At times, Ethereum’s average fees have exceeded 0.2 ETH (around $800), deterring many users from using the network.
The second issue with sequential execution is inefficient use of network nodes. Sequential instruction execution cannot benefit from multiple processor cores, resulting in low hardware utilization and inefficiency. This hampers scalability and causes unnecessary energy consumption.
Can Parallel Execution Solve This?
The limitations of the EVM architecture have opened the door for a new wave of Layer 1 blockchains focused on parallel execution (PE). Parallel execution allows transaction processing to be distributed across multiple processor cores, improving hardware utilization and enabling better scalability. On high-throughput chains, increasing hardware resources directly correlates with the number of executable transactions.
During periods of high activity, validator nodes can delegate more cores to handle additional transaction load. Dynamic scaling of computing resources allows the network to achieve higher throughput during peak demand, significantly improving user experience.
Another advantage of this approach is improved transaction confirmation latency. Dynamic resource allocation makes low-latency confirmation possible under all potential network loads.
Transactions no longer need to wait tens or hundreds of blocks, nor incur excessive fees for priority confirmation. Improved confirmation times enhance transaction finality and open the door to low-latency blockchains. Guaranteed low-latency execution enables several previously impossible use cases.
Changing the chain's execution model to allow PE is not a new idea; several projects have explored it. One approach is replacing the EVM’s account-based accounting model with an Unspent Transaction Output (UTXO) model. The UTXO execution model, used by Bitcoin, allows parallel transaction processing, making it ideal for payments.
However, due to UXTO’s limited functionality, extensions are needed to support the complex interactions required by smart contracts. For example, Cardano uses an extended UTXO model for this purpose, while Findora employs a hybrid UTXO model that supports both accounting models and allows users to switch asset types between them.
Another approach to PE does not change the account model but focuses on improving the architecture and modification of chain state. For instance, Solana’s Sealevel framework.
How Does Parallel Execution Work?
Parallel execution works by identifying independent transactions and executing them simultaneously. Two transactions are considered dependent if the execution of one affects the other. For example, AMM transactions within the same pool are dependent and must be executed sequentially.
While the concept of parallel processing sounds simple, the difficulty lies in the details—the main challenge being how to efficiently identify "independent" transactions. Classifying independent transactions requires understanding how each transaction alters blockchain memory or state. Transactions interacting with the same smart contract (e.g., an AMM pool) can simultaneously modify contract state and therefore cannot be executed in parallel.
Given the current level of composability among applications, identifying dependencies is a challenging task. Consider an AMM trade swapping UNI for USDC, where the AMM determines the most efficient route as UNI → ETH → DAI → AAVE → USDC. All pools involved in this trade cannot process any other transactions until the entire trade is executed and the state of all participating pools is updated.
Identifying Independent Transactions
This section compares methods used by different parallel execution engines, focusing on approaches to controlling access to state (memory). Blockchain state can be thought of as RAM memory, where each on-chain account or smart contract owns a set of modifiable memory locations. Dependent transactions are those attempting to modify the same memory location within a block. Different chains use varying memory architectures and mechanisms to identify such transactions.
Several chains in this category are built upon technologies developed by Facebook’s now-defunct blockchain project Diem. The Diem team created the Move smart contract language, specifically designed to improve SC execution. Aptos, Sui, and Linera are three high-profile projects belonging to this group. Aside from this group, Fuel is another notable project focused on PE, using its own SC language.
Aptos
Built on Diem’s Move language and MoveVM, Aptos creates a high-throughput chain that implements parallel execution.
Aptos’ approach detects dependencies transparently to users and developers, meaning transactions are not required to explicitly declare which part of the state (memory locations) they use.
Aptos uses a modified version of Software Transactional Memory (STM) called Block-STM.
In Block-STM, transactions are pre-ordered within a block and divided among processor threads for execution.
During execution, transactions are assumed to be independent. Memory locations modified by transactions are recorded, and after execution, all transaction results are validated. During validation, if a transaction is found to have accessed a memory location modified by a prior transaction, it is aborted. The transaction’s result is discarded and re-executed.
This process repeats until all transactions in the block are successfully executed.
When using multiple processor cores, Block-STM accelerates execution—the degree of speedup depends on the level of transaction interdependence.
Results from the Aptos team show that using 32 cores can improve performance by 8x for highly dependent workloads and by 16x for low-dependency workloads. If all transactions in a block are interdependent, Block-STM incurs a slight performance penalty compared to sequential execution. Aptos claims this method can achieve a throughput of 160,000 TPS.
Sui
Another PE approach requires transactions to explicitly declare which parts of the chain state they modify—a method currently used by Solana and Sui.
Solana refers to memory units as accounts, and transactions must specify which accounts they modify. Sui uses a similar approach.
Sui also builds on Diem’s technology using MoveVM. However, Sui uses a different version of the Move language.
Sui’s implementation of Move alters Diem’s core storage model and asset permissions, marking a significant departure from Aptos, which uses the core Diem Move language.
Sui Move defines a state storage model that facilitates easier identification of independent transactions.
In Sui, state storage is defined as Objects. Objects typically represent assets and can be shared, meaning multiple users can modify the same object.Each Object in Sui has a unique ID and contains internal pointers to owner addresses. Using these concepts, dependencies can be easily identified by checking whether transactions use the same Objects.
By shifting the burden of declaring dependencies to developers, the execution engine becomes simpler to implement, potentially enabling better performance and scalability. However, this comes at the cost of a less ideal developer experience.
Sui has not yet launched and recently rolled out its testnet.
Sui’s founders claim that the implementation of parallel execution, combined with the Narwhal and Tusk consensus mechanisms, enables throughput exceeding 100,000 tx/sec. If true, this would represent a significant improvement over Solana’s current throughput of approximately 2,400 tx/sec and surpass Visa and Mastercard’s transaction volumes.
Linera
Linera is the newest entrant in the parallel processing space, having recently announced its first funding round led by a16z. Few details are available about its implementation. However, according to their funding announcement post, it is based on the FastPay protocol, also developed at Facebook.
FastPay is built on a technique called Byzantine Consistent Broadcast, which focuses on accelerating independent payments—such as those occurring in point-of-sale networks. It allows a group of validators to ensure payment integrity as long as more than two-thirds are honest. FastPay is a variant of Real-Time Gross Settlement (RTGS) systems used in networks between banks and financial institutions.
Building on FastPay, Linera plans to create a blockchain that emphasizes fast settlement and low latency by parallelizing payment transactions. Notably, Sui also uses Byzantine Consistent Broadcast for simple payments. For other transaction types, Sui relies on its own Narwhal and Tusk consensus mechanisms to efficiently handle more complex, interdependent transactions such as DeFi trades.
Fuel
Fuel focuses on serving as the execution layer in modular blockchains, meaning it does not implement consensus or store blockchain data on the Fuel chain itself. For full functionality, Fuel interacts with other chains for consensus and data availability—such as Ethereum or Celestia.
Fuel uses UTXO to create strict access lists—essentially controlling access to the same state via a list. This model is built on the concept of canonical transaction ordering. In this scheme, the ordering of transactions within a block significantly simplifies the detection of dependencies between transactions. To realize this architecture, Fuel developed a new virtual machine called FuelVM and a new programming language called Sway.
FuelVM is a simplified, EVM-compatible design that enables developers to seamlessly join the Fuel ecosystem.
Moreover, because Fuel focuses on modular blockchains, Fuel smart contract execution can be settled on the Ethereum mainnet. This approach aligns with Ethereum’s post-merge vision of becoming a rollup-centric settlement and data availability layer. In this architecture, Fuel can achieve high-throughput execution with batching and settlement on Ethereum.
To validate the concept, the Fuel team has created an AMM called SwaySwap, similar to Uniswap, running on a testnet. The goal is to demonstrate superior performance of FuelVM compared to the EVM.
Challenges of Parallel Execution Approaches
While parallel execution appears logical and straightforward, several challenges remain. First is estimating the actual proportion of transactions that can be accelerated using this method. Second is maintaining decentralization—if validators can easily scale compute power to increase throughput, how can full nodes keep up to ensure chain correctness?
Percentage of Parallelizable Transactions
Accurately estimating the percentage of on-chain transactions that can be executed in parallel on any chain is challenging. Additionally, this percentage can vary significantly between blocks depending on the type of network activity.
For example, an NFT mint could trigger a burst of highly interdependent transactions. Nevertheless, we can use assumptions to obtain a rough estimate of the average percentage of parallelizable transactions.
For instance, we can assume most ETH and ERC20 transfers are independent—initiated from different addresses and sent to different recipients. Thus, we might estimate that about 25% of ETH and ERC20 transfers are interdependent—such as deposits to smart contracts or aggregating exchange hot wallet assets into cold wallets.
On the other hand, all AMM transactions within the same pool are interdependent. Given that most AMMs are typically dominated by a few pools and AMM transactions are highly composable—interacting with multiple pools—we can safely assume at least 50% of AMM transactions are interdependent.
Analyzing Ethereum’s transaction categories, we find that out of approximately 1.2 million daily transactions, 20–30% are ETH transfers, 10–20% are stablecoin transfers, 10–15% are DEX trades, 4–6% are NFT transactions, 8–10% are ERC20 approvals, and 12–15% are other ERC20 transfers.
Using these figures and assumptions, we can estimate that PE can accelerate roughly 70–80% of transactions on a smart contract platform.
This implies that sequential execution of dependent transactions accounts for 20–30% of all transactions. In other words, PE could potentially deliver a 3x to 5x throughput increase under the same gas limit.
Some experimental implementations of parallel-execution EVMs show similar estimates, achieving consistent 3–5x throughput improvements.
In practice, high-throughput chains use higher gas limits and shorter block times to achieve throughput increases of over 100x compared to Ethereum. This increased throughput demands powerful validator nodes to process these blocks, leading to the second challenge: network centralization.
Network Centralization
In high-throughput networks, the network can process tens of thousands of transactions per second.
Validators are incentivized by fees and network rewards to process these transactions and invest in dedicated servers or scalable cloud infrastructure. However, companies or individuals who use the chain and need to run full nodes for interaction cannot afford such complex servers to handle massive transaction loads. This pushes users to rely on specialized RPC node providers like Infura, increasing centralization.
Without the option to run full nodes on consumer-grade hardware, high-throughput chains risk becoming closed systems where a small number of entities hold absolute control. In such cases, these entities could collude to censor transactions, users, or even applications—like Tornado Cash—turning these chains into permissioned systems indistinguishable from Web 2.
Currently, operating a full node on the Sui testnet requires fewer resources than on the Aptos testnet. However, we expect these requirements to change significantly once mainnets launch and applications begin deploying on-chain.
Decentralization advocates are proposing solutions to address these anticipated issues, including using lightweight nodes and verifying block correctness via ZK validity proofs or fraud proofs.
The Fuel team is particularly active in this area, aligning with the Ethereum community’s ethos on the importance of decentralization. It remains unclear whether the Aptos and Sui teams prioritize implementing such methods or other decentralization-promoting measures. The Linera team briefly discussed these concerns in their introductory post, but protocol implementation has yet to confirm this commitment.
Conclusion
Parallel execution engines are a promising solution for increasing throughput on smart contract platforms.
Combined with innovations in consensus mechanisms, parallel transaction execution can push chain throughput close to or beyond 100,000 TPS—performance comparable to Visa and Mastercard—enabling several of today’s most demanding use cases, such as fully on-chain gaming and decentralized micropayments.
These impressive throughput improvements come with challenges, particularly regarding ensuring decentralization. We look forward to founders committed to solving these issues.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@MohamedFFouda
