Parallel Execution: The Next Generation of Blockchains
Exploring the design philosophies of parallelized blockchains and which teams are pushing the frontier today.
Prelude
1.0 Blockchain Transactions
Blockchains are virtual machines, a software-based computing model which runs on top of a distributed network of physical computers which anyone can join but is extremely difficult for any single entity to control. The concept of a blockchain was first put into writing in Satoshi Nakomoto’s infamous Bitcoin whitepaper in 2008, as the core infrastructure enabling cryptographically secured peer-to-peer payments in Bitcoin. Transactions are to blockchains what logs are to social media and internet companies; they serve as records of activity for that particular network, the key difference being that transactions on a blockchain are immutable and often publicly observable.
But what exactly is a transaction?
Transactions on blockchains involve the transfer of digital assets from one address on the distributed ledger to another, secured by the use of public key cryptography. Transactions can be used for decentralized peer to peer transfers, or for various authentication and verification processes as well.
1.1 How Blockchain Transactions Work
When a transaction is initiated, i.e. Bob sends some tokens to Alice, Bob’s transaction is broadcast to the underlying blockchain network. Subsequently, clusters of specialized nodes on the network get to work verifying and validating the transaction as legitimate. Once enough of these nodes have verified the contents of the transaction, the transaction gets added to a block along with other user transactions. Once a block is full, it then gets added to the chain, hence the name ‘blockchain'. Bob’s transaction is now part of a secure and transparent ledger, and he and Alice can both verify the contents.
Broadly speaking, all blockchain transactions contain metadata that helps the nodes operating and securing the network identify and execute a given set of instructions and parameters. Every transaction will have high-level data input by the original sender, such as the amount to be transferred, the destination address, and the digital signature to confirm the transaction, as well as various low-level data that is created and attached automatically, though this data varies by network and design.
Ultimately, however, the processes involved behind the scenes at the networking layer prior to transaction execution vary by the design of the blockchain.
1.1.1 Mempool
A memory pool, or mempool, is a common feat of blockchain designs, implemented by traditional blockchain networks such as Bitcoin and Ethereum. Mempools are simply buffer zones, or ‘waiting rooms’, for pending transactions which are yet to be added to a block and executed.
To better understand, we can lay out the lifecycle of a transaction on a blockchain which uses a mempool;
The user initiates and signs a transaction.
Specialized nodes participating in the blockchain network verify the contents of the transaction to be legitimate and contain appropriate parameters.
Once verified, the transaction is routed to the public mempool alongside other pending transactions.
Eventually, depending on the gas fee paid for the transaction relative to other transactions in the mempool, our user’s pending transaction is selected with a cluster of other pending transactions to form the next block on the blockchain. At this stage, our transaction status will read “Successful”.
After a certain time or block-based threshold has passed, the block itself is finalized and the transaction becomes an immutable log recorded on the blockchain, which could only be compromised in the event of a 51% attack, an extremely difficult task to perform otherwise.
1.1.2. No Mempool (Solana)
It’s important to note that some blockchains, such as Solana, do not employ a mempool, and may instead forward transactions directly to the block producer as a means of enabling high speed and throughput through continuous block production.
Let’s walk through the lifecycle of a transaction on a non-mempool blockchain:
User initiates and signs a transaction for an application they are using.
The application routes the transaction info to the Remote Procedure Call (RPC) server.
The RPC provider sends the transaction to the current designated block producer, and the next three producers; this is a precautionary step in the event that the current leader cannot execute the transaction in time. Solana employs a slot leader schedule which helps RPCs route the transactions easier.
The block producer then sends the signed transaction to consensus nodes for verification.
Consensus nodes vote to verify the contents of the transaction, and once completed, the transaction status is then routed back to RPC > application > user as either ‘success’ or ‘failed’.
Similar to mempool-based blockchains, the block itself is finalized after a certain time or block-based threshold has passed.
1.2 Sequential Execution
Older blockchains, namely Bitcoin and Ethereum, utilize a sequential execution mechanism for transactions. Every transaction added to the blockchain invokes a change in the network’s state, and the VM is structured to only process one state change at a time for security purposes.
This has led to significant bottlenecks for the throughput of the underlying network, as the number of transactions that can be added to the block gets limited, leading to longer wait times and unprecedented spikes in transaction costs which can render the network unusable at times. Furthermore, sequential execution models utilize hardware components rather inefficiently, and thus do not benefit from breakthroughs in computing, i.e. multiple processor cores.
Parallel Execution
2.0 What is Parallel Execution?
Parallel computing is a key component of computer architecture whose origins can be traced back as far back as the late 1950s, though its ideation and theory has even been traced back to 1837. By definition, parallel computing refers to the act of utilizing multiple processing elements simultaneously to solve an operation, wherein a larger and more complex task is divided into smaller ones to be completed more efficiently than in a serial manner.
Originally only implemented in high performance computing systems, parallel computing has evolved to become the dominant paradigm in computer architecture today, as demand for compute has exponentially increased in the internet era, exacerbated by the limitations of frequency scaling in prior decades.
This architectural standard applies to blockchains in much the same way, only that the primary task which computers solve is the processing and execution of 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 serially, a blockchain can process multiple non-conflicting transactions simultaneously. This can greatly increase the throughput of a blockchain network, making it more scalable and efficient to handle higher loads of activity and demand for blockspace.
For a simpler analogy. consider the efficiency of a grocery store with multiple lanes for shoppers to check out. vs just one for everyone.
Why is Parallel Execution important?
Parallel execution in blockchains is designed to unlock efficiencies in the speed and performance of a network, especially as the network sees higher traffic and resource demand. In the context of crypto ecosystems, parallel execution means that if Bob wants to mint the latest popular NFT collection, and Alice wants to buy her favorite memecoin, the network will serve both users without compromising any quality in performance and thus user experience.
While this may come across as simply an intuitive quality-of-life feature, the unlocks in network performance enabled by parallel execution gives way to the development of new and innovative use cases and applications which can leverage low-latency and high volumes, which in itself lays the groundwork for onboarding the next mass cohort of users to crypto ecosystems.
How Does Parallel Execution Work?
Although the premise of parallel execution is relatively straightforward, nuances in the designs of the underlying blockchains affect how the process of parallel execution itself plays out. The most relevant feature to designing blockchains with parallel execution is the transactions’ ability to access the state of its underlying network, including account balances, storage, and smart contracts.
Parallel execution on blockchains can be categorized as either deterministic or optimistic. Deterministic parallel execution, employed by blockchains like Solana, inherently requires transactions to declare all memory dependencies upfront, i.e. which parts of the global state they wish to access upfront. While this step creates additional overhead for developers, more broadly it allows the network to sort and identify non-conflicting transactions prior to execution, creating an optimized system that is predictable and efficient. Conversely, optimistic parallel execution is structured to process all transactions in parallel, operating under the inherent assumption there are no conflicts. This enables the underlying blockchain to deliver faster transaction execution, though at the cost of potential re-execution afterward in the event of a conflict. If two conflicting transactions are found to be submitted, the system can then re-process and re-execute them either in parallel or sequentially.
In order to better understand the implications of these design intricacies, it can be helpful to analyze parallel execution through the lens of teams pushing the frontier of parallel execution today.
State of Parallel Execution Today
In order to better understand the implications of these design intricacies, it can be helpful to analyze parallel execution through the lens of teams pushing the frontier of parallel execution today.
3.1 Solana Virtual Machine (SVM)
Solana was the first blockchain network to be designed around parallel execution, inspired by founder Anatoly Yakovenko’s previous experience in the telecommunications industry. Solana aims to provide a developer platform which runs as fast as physics allows, therefore the speed and efficiency unlocked by parallel computing was a simple and intuitive design choice.
A critical component to enabling Solana’s fast speeds and high throughput is Sealevel, the network’s parallel smart contracts runtime environment. Unlike EVM and WASM-based environments, Sealevel employs a multi-threaded architecture, meaning it can process multiple transactions simultaneously to the extent of the validator core’s capacity.
The key to enabling Solana’s parallel execution is that when a transaction is enabled, the network will assign a list of instructions for that transaction to be executed, specifically which accounts and state to access and what changes to make - this is key to determining which transactions are non-conflicting and can execute simultaneously, as well as enabling transactions which are attempting to access the same state to do so concurrently.
Consider the efficiency that labels provide to checked baggage systems at airports.
Solana also utilizes Cloudbreak, its own custom accountsDB, for storing and managing state data to enable concurrent reads and writes of transactions. Cloudbreak, optimized for parallel execution, scales horizontally to distribute and manage state data across multiple nodes.
Thanks to its parallel architecture, Solana can handle a large number of transactions and still execute quickly, giving transactions near-instant finality. Solana handles between 2,000 and 10,000 transactions per second (TPS) on average today. Furthermore, use cases for the SVM are slowly but surely expanding, as teams like Eclipse are rolling out Layer 2 infrastructure which aims to take advantage of the SVM as an execution environment.
3.2 Parallel EVM
The Parallel EVM describes a new execution environment for blockchains which aims to bring the “best of both worlds” from Solana and Ethereum’s designs, with the speed and performance of Solana, and the security and liquidity of Ethereum. By processing transactions in parallel rather than sequentially as per the traditional EVM design, parallel EVMs enable developers to build applications on a highly performant network while being able to leverage connections to EVM liquidity and developer tooling.
3.2.1 Sei Network
Sei Network is an EVM-compatible, open source Layer 1 blockchain which hosts a variety of decentralized applications built around high performance. Sei was built around delivering fast speeds at low costs for users and developers, and parallel execution is a key component of enabling this performance and UX. Currently, Sei delivers 390ms block confirmation times and has processed over 1.9B transactions on its pacific mainnet.
Originally, Sei employed a deterministic parallel execution model, wherein smart contacts declare their required state access ahead of time in order for the system to run non-conflicting transactions simultaneously. With the onset of their V2 upgrade, Sei is transitioning to an optimistic parallel model instead, meaning all transactions will be processed in parallel upon being submitted to the network (the execution stage), and then will be reviewed for conflicting information with previous transactions (the validation stage). In the event of two or more conflicting transactions, i.e. transactions attempting to access the same network state, Sei identifies this point of conflict and then re-runs the transactions either in parallel or sequentially depending on the nature of the conflict.
In order to store and maintain transaction data, Sei will also introduce SeiDB, a custom database which aims to improve upon shortcomings in v1 by optimizing for parallel execution. SeiDB aims to bring down the overhead of storing redundant data and maintaining efficient disk usage for better network performance. V2 reduces the amount of metadata needed for tracking and storage purposes, and enables a write-ahead log to aid with data recovery in the event of a crash.
Lastly, Sei has also recently announced the launch of its Parallel Stack, an open-source framework for enabling Layer 2 scaling solutions, i.e. rollups, to utilize and benefit from parallel execution.
3.2.2 Monad
Monad is an upcoming parallel-EVM Layer 1 blockchain bringing full bytecode and RPC compatibility for Ethereum applications and infrastructure. Through a number of innovative technical implementations, Monad aims to deliver more interactive experiences than existing blockchains while maintaining lower transaction costs by optimizing for performance and portability, with 1 second block times and finality with up to 10,000 TPS.
Monad implements parallel execution and superscalar pipelining to optimize the speed and throughput of transactions. Similar to Sei v2, Monad will employ an optimistic execution model, meaning the network starts executing all incoming transactions simultaneously, and then analyzes and validates the transactions to look for conflicts and re-execute accordingly, with the end goal being that the outcome would be identical had the transactions been executed sequentially.
It’s important to note that in maintaining synchronicity with Ethereum, Monad orders transactions in a block in linear order, with each transaction updated sequentially.
In order to maintain and access blockchain data more efficiently than the current state of Ethereum clients offers, Monad created its own custom MonadDB, built natively for blockchains. Monad DB leverages advanced Linux kernel features for efficient asynchronous disk operations, eliminating the constraints of synchronous input/output access. MonadDB offers asynchronous input/output (async I/O) access, a key feature in enabling parallel execution, wherein the system can start processing the next transaction while waiting to read state for a prior transaction.
For a simple analogy, consider cooking a multi-faceted meal (spaghetti with meatballs). The steps involved are 1) preparing a sauce, 2) cooking the meatballs, and c) cooking the pasta. An efficient chef would start by boiling water for the pasta, then preparing ingredients for the sauce, then tossing the pasta in the now-boiling water, then cooking the sauce, and finally the meatballs, as opposed to doing each step one at a time, completing one task in its entirety before moving on.
3.3 Move
Move is a programming language originally developed by the Facebook team in 2019 for its now-defunct Diem project. Move was designed to handle smart contract and transaction data in a secure manner, eliminating attack vectors native to other languages such as reentrancy attacks.
The MoveVM serves as the native execution environment for Move-based blockchains, taking advantage of parallelization to deliver faster transaction execution speeds and greater overall efficiency.
3.3.1 Aptos
Aptos is a Move-based Layer 1 blockchain developed by members of the former Diem project, which implements parallel execution to deliver a high performance environment for application developers. 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 which enables for optimistic parallel execution. Transactions are pre-ordered and strategically sequenced inside of blocks, which is key to efficiently resolving conflicts and re-executing those transactions. Research conducted by Aptos has found that up to 160K TPS can be theoretically supported using Block-STM’s parallelization.
3.3.2 Sui
Similar to Aptos, Sui is a layer 1 blockchain developed by former members of the Diem project, which utilizes the Move language. However, Sui utilizes a custom implementation of Move which changes the storage model and asset permissions from the original Diem design. In particular, this allows Sui to utilize a state storage model to represent independent transactions as objects. Each object has a unique ID within Sui’s execution environment, and in doing so, this allows the system to easily identify non-conflicting transactions and process them in parallel.
Similar to Solana, Sui implements deterministic parallel execution, which requires transactions to state which accounts they need to access ahead of time.
3.3.3 Movement Labs
What is Movement?
Movement is building a suite of developer tooling and blockchain infrastructure services for enabling developers to easily access the benefits of building on Move. Operating as an AWS-like execution-as-a-service provider for Move developers, Movement implements parallelization as a core design feature for enabling higher throughput and greater overall network efficiency. The MoveVM is a modular execution environment which enables blockchain networks to expand and adjust their transaction processing capabilities as needed to be able to support an increasing volume of transactions, bolstering their abilities to process and execute transactions in parallel.
Movement will also be launching M2, a ZK-rollup which will be interoperable with EVM and Move clients alike. M2 will inherit the Block-STM parallelization engine, and is expected to deliver tens of thousands of TPS as a result.
Closing Thoughts
4.1 Challenges For Parallel Systems Today
Some important questions and considerations to be pondered upon regarding the development of parallel blockchains;
What tradeoffs is the network making to enable better performance through parallel execution?
Less validators securing the network enables faster verification and execution speeds, but does this compromise the security of the blockchain in that it becomes easier for validators to collude against the network?
Is there a significant number of validators colocated? This is a common strategy for minimizing latency in both crypto and non-crypto systems alike, but what happens to the network in the event of that particular data center being compromised?
For optimistic parallel systems, does the process of re-executing invalid transactions create a bottleneck as the network scales? How is this efficiency being tested and evaluated?
At a high level, parallel blockchains face the risk of ledger inconsistencies, i.e. double spending and changes in the order of transactions (indeed, this is the key benefit of sequential execution). Deterministic parallelization addresses this by creating an internal labeling system for transactions on the underlying blockchain. Blockchains implementing optimistic processing must ensure the mechanisms they use to validate and re-execute transactions is secure and functional, and the tradeoffs made for performance can be reasonably implemented.
4.2 Future Outlook / Opportunities
The history of computers has taught us that parallel systems tend to be more efficient and scalable over time than sequential systems. The rise of post-Solana parallel blockchains emphasizes that this notion applies to crypto infrastructure as well. Even Vitalik has alluded to parallelization as a one of the potential key solutions for improving the scalability of EVM rollups recently. Broadly speaking, crypto/blockchain adoption growth calls for systems that are more optimal than what is available today, including parallel blockchains. Solana’s recent network struggles have highlighted that there is plenty of room for improvement in the development of parallel blockchains. As more teams seek to push the boundaries of the onchain frontier and onboard the next mass cohort of users and adoption to blockchain-native applications and ecosystems, parallel execution models provide an intuitive framework for building systems that can efficiently handle magnitudes of network activity at a scale which matches that of Web2 companies with ease.
Works Cited
Dixon, C. (2024). Read write own: Building the next era of the internet. Random House.
AllianceDAO. (2023, April 12). The case for parallel processing chains. Medium. https://medium.com/alliancedao/the-case-for-parallel-processing-chains-90bac38a6ba4
Solana Labs. (2020, December 3). Sealevel: Parallel processing thousands of smart contracts. Medium. https://medium.com/solana-labs/sealevel-parallel-processing-thousands-of-smart-contracts-d814b378192
Etherscan. (n.d.). Ethereum average gas price chart. https://etherscan.io/chart/gasprice
Sei Labs. (2023, February 10). Sei V2: The first parallelized EVM. Sei Blog. https://blog.sei.io/sei-v2-the-first-parallelized-evm/
Sei Labs. (n.d.). Overview. Sei Documentation. https://www.docs.sei.io/overview
Sei Labs. (2023, January 18). SEIDB: Improving long-term storage. Sei Forum. https://forum.sei.io/t/seidb-improving-long-term-storage/22?ref=blog.sei.io
Sei Labs. (2023, March 5). The parallel stack. Sei Blog. https://blog.sei.io/the-parallel-stack/
Monad Labs. (n.d.). Monad documentation.
https://docs.monad.xyz/
CoinMarketCap. (2022, August 1). What is Aptos? The ultimate guide to the Aptos ecosystem. CoinMarketCap Academy. https://coinmarketcap.com/academy/article/what-is-aptos-the-ultimate-guide-to-the-aptos-ecosystem
Wang, J., Zhang, L., & Huang, Y. (2022). Efficient algorithms for parallel computing. arXiv. https://arxiv.org/pdf/2203.06871.pdf
Movement Labs. (2023, May 10). The MoveVM: A new era of blockchain precision and safety. Medium. https://medium.com/movementlabsxyz/the-movevm-a-new-era-of-blockchain-precision-and-safety-a1b5bd4a65ea
Buterin, V. (2024, March 28). Blobs: A new data structure for efficient blockchain storage. Vitalik’s Blog. https://vitalik.eth.limo/general/2024/03/28/blobs.html
Not financial or tax advice. The purpose of this newsletter is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.
Disclosures. All posts are the authors own, not the views of their employer. This post has been sponsored by the Aster Foundation. While Shoal Research has received funding for this initiative, sponsors do not influence the analytical content. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.
 | A guest post by
|
Great article. I found the explanations about parallel and sequential execution in blockchains really helpful. Thanks for sharing