A blockchain is a virtual machine, a software-based computing model that runs on a distributed network of physical computers that anyone can join but is extremely difficult to control by a single entity. The concept of blockchain was first proposed in Satoshi Nakamoto's 2008 Bitcoin white paper as the core infrastructure that supports cryptographically secure peer-to-peer payments in Bitcoin. For blockchain, transactions are like logs for social media and Internet companies; they serve as a record of activity on a specific network, with the key difference that transactions on the blockchain are immutable and generally publicly searchable.
What exactly is a transaction
A transaction on the blockchain involves the transfer of digital assets from one address to another on the distributed ledger, a process that is secured by public key cryptography. Transactions can be used not only for decentralized peer-to-peer transfers, but also for various authentication and verification processes.
How blockchain transactions work
When a transaction is initiated, such as Bob sending some tokens to Alice, Bob's transaction is broadcast to the underlying blockchain network. A group of specialized nodes in the network then go to work verifying and confirming the legitimacy of the transaction. Once enough nodes have verified the transaction, the transaction is added to a block and packaged with other user transactions. When a block is full, it is added to the blockchain, which is where the name "blockchain" comes from. At this point, Bob's transaction becomes part of a secure and transparent ledger that both he and Alice can verify.
In general, all blockchain transactions contain metadata, which helps the nodes that operate and protect the network identify and execute a given set of instructions and parameters. Each transaction has high-level data entered by the sender, such as the amount to be transferred, the destination address, and a digital signature used to confirm the transaction, as well as various low-level data that is automatically created and attached, although this data varies depending on the network and design.
However, the processes involved behind the scenes at the network level before a transaction is executed will vary depending on the design of the blockchain.
Memory Pool (Ethereum)
Memory pools, or mempools for short, are a common feature in blockchain design, and traditional blockchain networks such as Bitcoin and Ethereum have memory pools. Mempools are essentially buffers or "waiting rooms" for pending transactions that have not yet been added to a block for execution.
To better understand, we can outline the life cycle of a transaction on a blockchain that uses a mempool:
A user initiates and signs a transaction.
Specialized nodes participating in the blockchain network verify the legitimacy of the transaction content and ensure that it contains the appropriate parameters.
Once verified, the transaction is routed to the public mempool and waits to be packaged with other pending transactions.
Eventually, based on the gas fee paid by the user for the transaction relative to the gas fees of other transactions in the mempool, the user's pending transaction will be selected and formed into the next block on the blockchain along with other pending transactions. At this point, the transaction status will be displayed as "successful".
After a certain amount of time or block generation threshold, the block itself will be finalized and the transaction will become an unalterable log recorded on the blockchain, which is extremely difficult to achieve unless a 51% attack occurs.
No Memory Pool (Solana)
It is worth noting that some blockchains, such as Solana, do not use a mempool, but forward transactions directly to block producers to achieve high speed and high throughput through continuous block production.
Let's continue through the transaction life cycle on a non-mempool blockchain:
The user initiates and signs a transaction for the application he is using.
The application routes the transaction information to the remote procedure call (RPC) server.
The RPC provider sends the transaction to the currently designated block producer, as well as the next three producers; this is a precautionary step in case the current leader is unable to execute the transaction in a timely manner. Solana employs a slotted leader schedule, which helps RPC to route transactions more easily.
The block producers then send the signed transaction to the consensus nodes for verification.
The consensus nodes vote to verify the transaction contents, and once completed, the transaction status is routed back to the RPC > Application > User as either "Success" or "Failure".
Similar to mempool-based blockchains, the blocks themselves are finalized after a certain amount of time or block-based thresholds are passed.
Sequential Execution
Older blockchains, especially Bitcoin and Ethereum, use a sequential execution mechanism for transactions. Each transaction added to the blockchain triggers a change in the state of the network, and the virtual machine (VM) is designed to handle only one state change at a time for safety reasons.
This leads to a significant bottleneck in the throughput of the underlying network, because the number of transactions that can be added to a block is limited, resulting in longer waiting times, unprecedented surges in transaction costs, and sometimes even making the network unusable. In addition, the sequential execution model uses hardware components quite inefficiently and therefore cannot benefit from breakthrough advances in computing, such as multiple processor cores.
Parallel Execution
Parallel computing is a key component of computer architecture, with its origins dating back to the late 1950s, although its ideas and theories can be traced back to 1837. By definition, parallel computing refers to the use of multiple processing elements simultaneously to solve an operation, where a larger and more complex task is broken down into smaller tasks so that it can be completed more efficiently than in a serial manner.
Initially implemented only in high-performance computing systems, parallel computing has evolved into the dominant paradigm in today's computer architecture as the demand for computing has grown exponentially in the Internet era and the frequency scaling limitations have intensified over the past few decades.
This architectural standard also applies to blockchains, except that the primary task that the computer solves is processing and executing transactions, or the transfer of value from smart contract A to smart contract B, hence the term parallel execution.
Parallel execution means that instead of processing transactions sequentially, blockchains can process multiple non-conflicting transactions at the same time. This can greatly increase the throughput of a blockchain network, making it more scalable and more efficient at handling higher activity loads and block space requirements.
To simplify understanding, imagine the efficiency of a grocery store checkout: there are multiple lanes for customers to check out, as opposed to just one lane for everyone to use.
Why Parallel Execution Matters
Parallel execution in blockchain is designed to increase the speed and performance of the network, especially when the network sees higher traffic and resource demands. In the context of the crypto ecosystem, if Bob wants to mint the latest popular NFT series and Alice wants to buy her favorite meme coin, the network will serve both users simultaneously without compromising performance and user experience.
While this may seem like just an intuitive quality of life feature, the network performance gains enabled by parallel execution pave the way for the development of innovative use cases and applications that can take advantage of low latency and high capacity, which in itself lays the foundation for bringing the next large user base into the crypto ecosystem.
How Parallel Execution Works
While the concept of parallel execution is relatively straightforward, the details of the underlying blockchain design affect how the parallel execution process itself behaves. The most important feature of designing a blockchain with parallel execution is that transactions have access to the state of its underlying network, including account balances, storage, and smart contracts.
Parallel execution on a blockchain can be categorized as either deterministic or optimistic. Deterministic parallel execution, as adopted by Solana, essentially requires transactions to declare all memory dependencies in advance, i.e., which parts of the global state they want to access in advance. While this step creates additional overhead for developers, it allows the network to sort and identify non-conflicting transactions before execution, creating a predictable and efficient optimization system. In contrast, optimistic parallel execution is structured to process all transactions in parallel, based on the assumption that there are no conflicts. This enables the underlying blockchain to provide faster transaction execution, although it may require potential re-execution later if conflicts occur. If two conflicting transactions are found, i.e., transactions that attempt to access the same network state, the system can reprocess and re-execute them, either in parallel or sequentially.
To better understand the impact of these design details, it may be helpful to analyze parallel execution through the lens of the team pushing the forefront of parallel execution today.
The 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 past experience in the telecommunications industry. Solana aims to provide a development platform that runs as fast as possible, so the speed and efficiency of parallel computing is a simple and intuitive design choice.
Sealevel is the parallel smart contract runtime environment of the Solana network and is a key component that enables its fast speed and high throughput. Unlike EVM- and WASM-based environments, Sealevel uses a multi-threaded architecture, which means it can process multiple transactions simultaneously within the capacity of the validator cores.
The key to Solana’s parallel execution is that when a transaction is enabled, the network assigns that transaction a series of instructions to execute, specifically which accounts and states to access and which changes to make — this is key to determining which transactions do not conflict and can be executed simultaneously, while also allowing transactions attempting to access the same state to proceed simultaneously.
Think of the efficiencies provided by tags in airport checked baggage systems.
Solana also leverages Cloudbreak, its custom accountsDB, for storing and managing state data to support concurrent reads and writes of transactions. Cloudbreak is optimized for parallel execution and can scale horizontally to distribute and manage state data across multiple nodes.
Thanks to its parallel architecture, Solana is able to process a large number of transactions while still executing quickly, providing near-instant finality for transactions. Solana currently processes an average of 2,000 to 10,000 transactions per second (TPS). In addition, the use cases for the SVM are slowly but steadily expanding as teams like Eclipse launch Layer 2 infrastructure designed to leverage the SVM as an execution environment.
Parallel EVM
Parallel EVM describes a new blockchain execution environment that aims to combine the best of both Solana and Ethereum designs, namely the speed and performance of Solana with the security and liquidity of Ethereum. By processing transactions in parallel rather than sequentially, unlike traditional EVM designs, Parallel EVM enables developers to build applications on a high-performance network while being able to leverage connections to EVM liquidity and development tools.
Sei Network
Sei Network is an open-source, EVM-compatible Layer 1 blockchain that supports a wide range of decentralized applications built around high performance. Sei aims to provide fast speeds and low costs for users and developers, and parallel execution is a key component to achieving this performance and user experience. Currently, Sei provides 390 millisecond block confirmation times and has processed over 1.9 billion transactions on its Pacific mainnet.
Originally, Sei adopted a deterministic parallel execution model, where smart contracts declare their required state accesses in advance so that the system can run non-conflicting transactions simultaneously. With the advent of their V2 upgrade, Sei is transitioning to an optimistic parallel model, which means that all transactions will be processed in parallel when submitted to the network (execution phase), and then checked for conflicting information with previous transactions during the verification phase. If two or more conflicting transactions are found, that is, transactions that attempt to access the same network state, Sei will identify this conflict point and then re-run the transactions either in parallel or sequentially, depending on the nature of the conflict.
To store and maintain transaction data, Sei will also introduce SeiDB, a custom database designed to improve the shortcomings of the v1 version by optimizing parallel execution. The goal of SeiDB is to reduce the overhead of storing redundant data and maintain efficient disk usage to improve network performance. V2 reduces the amount of metadata required to track and store, and enables write-ahead logs to help recover data in the event of a crash.
Finally, Sei also recently announced the launch of its Parallel Stack, an open source framework for enabling Layer 2 scaling solutions (such as rollups) to leverage and benefit from parallel execution.
Monad
Monad is an upcoming parallel-EVM Layer 1 blockchain that provides full bytecode and RPC compatibility for Ethereum applications and infrastructure. Through some innovative technical implementations, Monad aims to provide a more interactive experience than existing blockchains by optimizing performance and portability while maintaining low transaction costs, with 1 second block time and finality of up to 10,000 TPS.
Monad implements parallel execution and superscalar pipelining technology to optimize the speed and throughput of transactions. Similar to Sei v2, Monad will adopt an optimistic execution model, which means that the network will start executing all incoming transactions simultaneously, then analyze and verify the transactions to find conflicts and re-execute accordingly, with the ultimate goal that the results will be the same if the transactions were executed in sequence.
It is important to note that while keeping in sync with Ethereum, Monad sorts the transactions in the block in linear order and updates each transaction sequentially.
In order to maintain and access blockchain data more efficiently than the state provided by current Ethereum clients, Monad created its own custom MonadDB, which is built natively for the blockchain. Monad DB uses advanced Linux kernel features to achieve efficient asynchronous disk operations, eliminating the limitations of synchronous input/output access. MonadDB provides asynchronous input/output (async I/O) access, which is a key feature to achieve parallel execution. The system can start processing the next transaction while waiting to read the state of the previous transaction.
A simple analogy is to think about cooking a multi-step meal (like spaghetti with meatballs). The steps involved are 1) preparing the sauce, 2) cooking the meatballs, and 3) boiling the noodles. Rather than completing the steps one at a time and completing each task before moving on to the next, an efficient chef would first boil the water for the noodles, then prepare the ingredients for the sauce, then cook the noodles in the now-boiling water, then cook the sauce, and finally cook the meatballs.
Move
Move is a programming language that was originally developed by a Facebook team in 2019 for the now-abandoned Diem project. Move is designed to handle smart contracts and transaction data in a secure manner, eliminating attack vectors inherent in other languages, such as reentrancy attacks.
MoveVM, which serves as the native execution environment for Move-based blockchains, leverages parallelization to provide faster transaction execution and greater overall efficiency.
Aptos
Aptos is a Move-based Layer 1 blockchain developed by former Diem project members that provides a high-performance environment to application developers through parallel execution. Aptos utilizes Block-STM, a modified implementation of the Software Transactional Memory (STM) concurrency control mechanism.
Block-STM is a multi-threaded parallel execution engine that allows optimistic parallel execution. Transactions are pre-ordered and strategically ordered within blocks, which is critical for efficient conflict resolution and re-execution of transactions. Aptos' research found that parallelization using Block-STM can theoretically support up to 160,000 TPS.
Sui
Similar to Aptos, Sui is a Layer 1 blockchain developed by former Diem project members, and it also uses the Move language. However, Sui uses a custom Move implementation that changes the storage model and asset permissions from the original Diem design. In particular, 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, allowing the system to easily identify non-conflicting transactions and process them in parallel.
Similar to Solana, Sui implements deterministic parallel execution, requiring transactions to declare in advance the accounts they need to access.
Movement Labs
Movement is building a suite of developer tools and blockchain infrastructure services to make it easy for developers to access the benefits of building on Move. As an AWS-like execution-as-a-service platform for Move developers, Movement uses parallelization as a core design feature to achieve higher throughput and greater overall network efficiency. The MoveVM is a modular execution environment that allows blockchain networks to scale and adapt their transaction processing capabilities as needed to support growing transaction volumes, enhancing their ability to process and execute transactions in parallel.
Movement will also launch M2, a ZK-rollup that will interoperate with the 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
There are some important questions and considerations to ponder regarding the development of parallel blockchains:
What tradeoffs does the network make to achieve better performance through parallel execution?
Having fewer validators securing the network allows for faster validation and execution, but does this compromise the security of the blockchain and make it more vulnerable to collusion among validators?
Is there a large number of validators co-located? This is a common strategy in both cryptographic and non-cryptographic systems to minimize latency, but what happens to the network if a specific data center is compromised?
For optimistic parallel systems, does the process of re-executing invalid transactions become a bottleneck as the network scales? How has this efficiency been tested and evaluated?
At a high level, parallel blockchains run the risk of ledger inconsistencies, i.e. double spending and changes in the order of transactions (which is indeed the main benefit of sequential execution). Deterministic parallelization solves this problem by creating an internal tagging system for transactions on the underlying blockchain. Blockchains that implement optimistic processing must ensure that the mechanisms they use to verify and re-execute transactions are safe and practical, and that the trade-offs made for performance are reasonable.
Future Outlook
The history of computing tells us that parallel systems tend to be more efficient and scalable over time than sequential systems. The rise of parallel blockchains in the wake of Solana highlights that this concept also applies to crypto infrastructure. Even Vitalik mentioned parallelization as one of the potential key solutions to improve the scalability of EVM rollups. Broadly speaking, the growth of crypto/blockchain adoption requires superior systems than what is available today, including parallel blockchains. Solana’s recent network challenges highlight that there is still a lot of room for improvement in parallel blockchain development. As more teams seek to push the boundaries of the on-chain frontier and usher in the next wave of large-scale user groups and adoption into blockchain-native applications and ecosystems, the parallel execution model provides an intuitive framework for building systems that can efficiently handle the volume of network activity and easily scale with Web2 companies.