Why parallelization will be the next-generation blockchain solution?
TechFlow Selected TechFlow Selected
Why parallelization will be the next-generation blockchain solution?
Computer history tells us that, over time, parallel systems tend to be more efficient and scalable than sequential systems.
Navigating Web3 tides with focused insightsAuthors: Paul Timofeev, Mike Jin, Gabe Tramble
Translation: Chris, Techub News
A blockchain is a virtual machine—a software-based computational model—running on a distributed network of physical computers that anyone can join but which is extremely difficult for any single entity to control. The concept of blockchain was first introduced in Satoshi Nakamoto’s 2008 Bitcoin whitepaper as the core infrastructure enabling cryptographically secure peer-to-peer payments. For blockchains, transactions are like logs for social media and internet companies; they serve as records of specific network activity. The key difference is that transactions on a blockchain are tamper-proof and typically publicly queryable.
What Exactly Is a Transaction?
A transaction on a blockchain involves transferring digital assets from one address to another on a distributed ledger, secured through public-key cryptography. Transactions can be used not only for decentralized peer-to-peer transfers but also for various authentication and verification processes.
Example of a transaction observable by anyone on blockchain explorers such as SeiTrace
How Blockchain Transactions Work
When Bob decides to send tokens to Alice, his action is immediately broadcast across the entire blockchain network. In this process, specific nodes in the network—validator nodes—become active and begin verifying the validity of the transaction. Once confirmed by a sufficient number of nodes, the transaction is recorded into a new block and bundled with other users’ transactions. When the block is full, it is permanently added to the blockchain, giving the technology its name. Thus, both Bob and Alice can check their transaction details on this persistent, public ledger.
Each transaction in a blockchain carries metadata that helps nodes in the network identify and execute specific instructions and parameters. A transaction typically includes high-level data such as transfer amount, recipient address, and digital signature for validation, along with automatically generated low-level data, the specifics of which vary based on network design.
Although these processes are generally applicable, the exact implementation details differ depending on the blockchain architecture used.
For example, in traditional blockchains like Ethereum, there is a mechanism called the mempool. The mempool is essentially a buffer or “waiting area” that holds transactions not yet included in a block.
Here is the typical lifecycle of a transaction in a mempool-based blockchain:
-
The user initiates and signs a transaction.
-
Validator nodes in the blockchain network verify the transaction's validity and ensure correct parameters.
-
Once validated, the transaction enters the public mempool, waiting alongside other pending transactions to be packaged.
-
Transactions are selected for inclusion in the next block based on their gas fees relative to others in the mempool. Once included, the transaction status becomes “successful.”
-
After a period of time or upon reaching a certain block confirmation threshold, the block is finalized, and the transaction is permanently recorded on the blockchain. Unless under extreme circumstances such as a 51% attack, the data cannot be altered.
No Mempool (Solana)
In contrast, some blockchain platforms like Solana do not use a mempool. Instead, transactions are sent directly to block producers, aiming to increase processing speed and throughput by continuously generating blocks.
Let’s now walk through the lifecycle of a transaction on a non-mempool blockchain:
-
The user initiates and signs a transaction during application usage.
-
The application routes the transaction data to a remote procedure call (RPC) server.
-
The RPC provider forwards the transaction to the current designated block producer, as well as the next three producers—an anti-failure measure in case the primary producer fails to execute promptly.
-
The block producer then sends the signed transaction to consensus nodes for validation.
-
Consensus nodes vote to validate the transaction content. Once complete, the transaction status is routed back via RPC → application → user as either “successful” or “failed.”
-
Similar to mempool-based blockchains, the block itself is finalized after a time delay or upon meeting a block threshold.
Sequential Execution
Older blockchains, particularly Bitcoin and Ethereum, use sequential execution for transactions. Each transaction added to the blockchain triggers a state change in the network, and for security reasons, the virtual machine processes only one state change at a time.
This creates significant bottlenecks in underlying network throughput, as the number of transactions that can be added to a block is limited, leading to longer wait times, surging transaction costs, and sometimes rendering the network unusable. Additionally, the sequential execution model uses hardware components inefficiently, thus failing to benefit from breakthroughs in computing such as multi-core processors.
Parallel Execution
Parallel computing is a key technique in computer architecture, with roots dating back to the late 1950s and theoretical foundations as early as 1837. This technology enables multiple processing units to work simultaneously on a single problem, breaking large, complex tasks into smaller chunks for more efficient completion than traditional serial processing.
Initially applied primarily in high-performance computing systems, parallel computing has become the dominant paradigm in modern computer architecture due to the rise of the internet era, exponential growth in computational demand, and the physical limits of processor speed improvements over recent decades.
In blockchain technology, this parallel processing approach is adopted to simultaneously handle and execute multiple transactions or value transfers between smart contracts—commonly referred to as “parallel execution.”
Parallel execution allows a blockchain to process multiple non-conflicting transactions simultaneously, significantly boosting network throughput and scalability, enabling the blockchain to efficiently manage higher activity levels and larger block demands.
This can be understood through a simple analogy: imagine a grocery store with multiple checkout lanes versus just one—the former is clearly far more efficient. Such parallel processing improves overall efficiency and customer satisfaction.
Why Parallel Execution Matters
In blockchain technology, the main goal of implementing parallel execution is to enhance network speed and overall performance, especially under high traffic and heavy resource demands. For instance, in the cryptocurrency ecosystem, when Bob wants to mint the latest popular NFT collection while Alice aims to buy her favorite meme coin, the blockchain network can respond to both actions simultaneously without sacrificing performance or user experience.
While this capability may seem like a mere user experience improvement, it fundamentally opens the door to innovative applications and use cases by increasing network efficiency. These applications leverage low latency and high processing power, providing a critical foundation for bringing broader user groups into the crypto ecosystem and signaling a shift toward wider adoption of cryptographic technologies.
How Parallel Execution Works
Although the premise of parallel execution is relatively straightforward, subtle differences in underlying blockchain design affect how the process itself performs. The most relevant feature for designing a blockchain with parallel execution is the ability of transactions to access underlying network states such as account balances, storage, and smart contracts.
Parallel execution in blockchains typically falls into two categories: deterministic and optimistic. Deterministic parallel execution, used by Solana, requires transactions to explicitly declare all memory dependencies—i.e., the specific parts of global state they need to access—before execution. While this increases developer burden, it allows the network to sort and identify non-conflicting transactions beforehand, creating a predictable and highly efficient system. In contrast, optimistic parallel execution assumes all transactions are conflict-free, accelerating processing speed, but requiring re-execution if conflicts arise. When two conflicting transactions—those attempting to access the same network state—are detected, the system may choose to reprocess them, either in parallel or sequentially.
To better understand the impact of these designs, it may help to analyze parallel execution from the perspective of teams currently pushing its boundaries.
Current Market Landscape of Parallel Execution
Solana Virtual Machine (SVM)
Solana is the first blockchain network designed around parallel execution, inspired by founder Anatoly Yakovenko’s prior experience in the telecommunications industry. Solana aims to provide a development platform operating at maximum possible speed, making parallel computing a natural and intuitive design choice.
The key component enabling Solana’s speed and high throughput is Sealevel, its parallel smart contract runtime environment. Unlike EVM- and WASM-based environments, Sealevel employs a multithreaded architecture, allowing it to process multiple transactions simultaneously within validator core capacity.
The cornerstone of Solana’s parallel execution is that when a transaction is enabled, the network allocates a set of instructions specifying which accounts and states to access and what changes to make—this is crucial for identifying non-conflicting transactions that can be executed simultaneously, while also permitting transactions accessing the same state to proceed in parallel.
Solana also leverages Cloudbreak, its custom accountsDB, to store and manage state data, supporting concurrent read/write operations for transactions. Optimized for parallel execution, Cloudbreak can horizontally scale across multiple nodes to distribute and manage state data.
Thanks to its parallel architecture, Solana can handle massive transaction volumes while maintaining fast execution and near-instant finality. Currently, Solana averages between 2,000 and 10,000 transactions per second (TPS). Moreover, SVM use cases are slowly but steadily expanding, driven by teams like Eclipse launching Layer 2 infrastructures utilizing SVM as an execution environment.
Parallel EVM
Parallel EVM describes a new blockchain execution environment designed to combine the best of Solana and Ethereum—offering Solana’s speed and performance with Ethereum’s security and liquidity. By processing transactions in parallel instead of sequentially as in traditional EVM design, Parallel EVM enables developers to build applications on high-performance networks while benefiting from compatibility with EVM liquidity and developer tools.
Sei Network
Sei Network is an open-source, EVM-compatible Layer 1 blockchain supporting various high-performance decentralized applications. Designed to deliver fast speeds and low costs for users and developers, parallel execution is central to achieving this performance and user experience. Currently, Sei offers a 390-millisecond block confirmation time and has processed over 1.9 billion transactions on its Pacific mainnet.
Initially, Sei adopted a deterministic parallel execution model, where smart contracts pre-declare required state access so the system can run non-conflicting transactions concurrently. With the upcoming V2 upgrade, Sei is transitioning to an optimistic parallel model, meaning all transactions will be processed in parallel upon submission (execution phase), then checked for conflicts with prior transactions during validation. If two or more conflicting transactions—those accessing the same network state—are found, Sei identifies the conflict point and re-runs the transactions either in parallel or sequentially based on the nature of the conflict.
To store and maintain transaction data, Sei will also introduce SeiDB, a custom database designed to improve upon v1 shortcomings by optimizing for parallel execution. SeiDB aims to reduce overhead from redundant data storage and maintain efficient disk usage to boost network performance. V2 reduces the volume of metadata tracked and stored and introduces write-ahead logging to aid data recovery in crash scenarios.
Finally, Sei recently announced the launch of its Parallel Stack, an open-source framework enabling Layer 2 scaling solutions (e.g., rollups) to leverage and benefit from parallel execution.
Monad
Monad is an upcoming parallel EVM Layer 1 blockchain offering full bytecode and RPC compatibility with Ethereum applications and infrastructure. Through innovative technical implementations, Monad aims to deliver a more interactive experience than existing blockchains—achieving 1-second block times and up to 10,000 TPS finality—while maintaining low transaction costs through optimized performance and portability.
Monad implements parallel execution and superscalar pipelining to optimize transaction speed and throughput. Similar to Sei v2, Monad adopts an optimistic execution model, meaning the network begins executing all incoming transactions in parallel, then analyzes and validates them for conflicts and re-executes as needed, with the ultimate goal of producing the same result as if executed sequentially.
It should be noted that while staying synchronized with Ethereum, Monad linearly orders transactions within each block and updates each transaction sequentially.
To maintain and access blockchain data more efficiently than current Ethereum clients, Monad developed its own custom MonadDB, built natively for blockchains. MonadDB leverages advanced Linux kernel features to enable efficient asynchronous disk operations, eliminating limitations of synchronous I/O access. Providing asynchronous I/O (async I/O) is a key enabler of parallel execution, allowing the system to begin processing the next transaction while waiting to read the state of a previous one.
A simple analogy is cooking a multi-step meal (like spaghetti and meatballs). The steps are 1) preparing the sauce, 2) cooking the meatballs, and 3) boiling the pasta. An efficient cook would start boiling water for the pasta, then prepare sauce ingredients, then cook the pasta in the now-boiling water, followed by the sauce, and finally the meatballs—rather than completing one step fully before moving to the next.
Move
Move is a programming language originally developed in 2019 by a Facebook team for the now-defunct Diem project. Move is designed to securely handle smart contracts and transaction data, eliminating inherent attack vectors found in other languages, such as reentrancy attacks.
MoveVM serves as the native execution environment for Move-based blockchains, leveraging parallelization for faster transaction execution and higher overall efficiency.
Aptos
Aptos is a Move-based Layer 1 blockchain developed by former Diem team members, providing a high-performance environment for application developers through parallel execution. Aptos leverages Block-STM, a modified implementation of a software transactional memory (STM) concurrency control mechanism.
Block-STM is a multithreaded parallel execution engine enabling optimistic parallel execution. Transactions are pre-sorted and strategically ordered within blocks, which is crucial for efficiently resolving conflicts and re-executing transactions. Aptos research suggests that Block-STM-based parallelization could theoretically support up to 160,000 TPS.
Sui
Like Aptos, Sui is a Layer 1 blockchain developed by former Diem team members using the Move language. However, Sui employs a custom Move implementation that modifies the storage model and asset permissions from the original Diem design. Notably, this allows Sui to represent independent transactions as objects using a state storage model. Each object has a unique ID in Sui’s execution environment, enabling the system to easily identify non-conflicting transactions and process them in parallel.
Like Solana, Sui implements deterministic parallel execution, requiring transactions to pre-declare the accounts they need to access.
Movement Labs
Movement is building a suite of developer tools and blockchain infrastructure services to make the benefits of building on Move easily accessible. As an AWS-like execution-as-a-service platform for Move developers, Movement treats parallelization as a core design principle to achieve higher throughput and greater overall network efficiency. MoveVM is a modular execution environment, allowing blockchain networks to scale and adjust their transaction processing capabilities as needed to support growing transaction volumes and enhance parallel transaction handling and execution.
Movement will also launch M2, a ZK-rollup interoperable with both EVM and Move clients. M2 will inherit the Block-STM parallelization engine and is expected to achieve tens of thousands of TPS as a result.
Challenges of Parallel Systems
Regarding the development of parallel blockchain technology, several key issues and trade-offs must be considered:
-
What trade-offs does the network make to achieve better performance through parallel execution?
-
Fewer validators protecting the network can accelerate validation and execution—but does this compromise blockchain security, making it more vulnerable to validator attacks?
-
Are many validators co-located? This is a common latency-minimizing strategy in both crypto and non-crypto systems—but what happens to the network if a specific data center is compromised?
-
For optimistic parallel systems, will the process of re-executing invalid transactions become a bottleneck as the network scales? How is this efficiency tested and evaluated?
At a high level, parallel blockchains face risks of ledger inconsistency—double spending and transaction order changes (in fact, this is the main advantage of sequential execution). Deterministic parallelization addresses this by creating an internal tagging system for transactions on the underlying blockchain. Blockchains using optimistic processing must ensure their mechanisms for validating and re-executing transactions are secure and effective, and that performance trade-offs are reasonably justified.
Outlook for the Future
History in computing shows that, over time, parallel systems tend to be more efficient and scalable than sequential ones. The rise of parallel blockchains following Solana underscores that this concept applies equally to crypto infrastructure. Even Vitalik has noted that parallelization could be a key solution for improving EVM rollup scalability. Broadly speaking, growing adoption of crypto/blockchain requires systems superior to those available today—including parallel blockchains. Solana’s recent network challenges highlight that significant room for improvement remains in parallel blockchain development. As more teams push the boundaries of on-chain innovation and bring the next wave of mass user adoption into blockchain-native applications and ecosystems, parallel execution models offer an intuitive framework for building systems capable of efficiently handling web-scale activity and seamlessly matching the scale of Web2 companies.
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
@Shoalresearch
