Author: Ali Sheikh, crypto analyst; Translation: Golden Finance xiaozou
This article will outline the parallel design architecture of blockchain, borrowing three relevant examples: Solana, Sei and Monad. This article highlights the difference between optimistic and deterministic parallelism, and understands the nuances of state and memory access on these chains.
In 1837, computer scientist and mathematician Charles Babbage designed "Analytical Engine" lays the theoretical foundation for parallel computing. Parallelization is a key theme in the crypto world these days, and blockchains are trying to push the boundaries of processing, efficiency, and throughput.
Parallel computing enables many calculations or processes to be performed simultaneously, rather than having to perform calculations sequentially or one after the other. Parallel computing refers to the decomposition of a larger problem into smaller independent parts that can be executed by multiple processors communicating through shared memory. Parallel systems offer many advantages, such as increased efficiency and speed, scalability, improved reliability and fault tolerance, optimized resource utilization, and the ability to handle extremely large data sets.
However, it is critical to realize that the effectiveness of parallelization depends on the details of the underlying architecture and implementation. The two core bottlenecks of blockchain are cryptographic functions (hash functions, signatures, elliptic curves, etc.) and memory/state access. For blockchain, one of the key components in designing efficient parallel systems lies in the nuances of state access. State access refers to the ability of transactions to read and write blockchain state, including storage, smart contracts, and account balances. In order for parallel blockchains to be effective and performant, state access must be optimized.
There are currently two schools of thought on optimizing state access for parallelized blockchains: deterministic parallelism and optimistic parallelism. Deterministic parallelism requires the code to explicitly declare in advance which parts of the blockchain state will be accessed and modified. This allows the system to determine in advance which transactions can be processed in parallel without conflicts. Deterministic parallelism supports predictability and efficiency (especially in the case of mostly independent transactions). However, it does introduce more complexity for developers.
Optimistic parallelism does not require code to declare its state accesses in advance so that transactions can be processed in parallel as if conflicts would not occur. If a conflict occurs, Optimistic Parallelism will rerun, reprocess, or run the conflicting transactions serially. While optimistic parallelization provides developers with greater flexibility, conflicts require re-execution, so this approach is most efficient when transactions do not conflict. There is no right answer as to which method is better. They are just two different possible ways to achieve parallelization.
Let’s first explore some basic knowledge related to non-cryptographic parallel systems, and then look at the design space of blockchain parallel execution. We will focus on three core areas: overview of cryptographic parallel systems, memory and State access methods and parallel design opportunities.
Through what we have just learned about the functions of parallel computing and the advantages of parallel systems , it is now easy to understand why the adoption of parallel computing has become popular in recent years. And over the past few decades, parallel computing has become increasingly popular and has achieved many breakthroughs.
Medical Imaging: Parallel processing fundamentally changed medical imaging, bringing significant improvements in speed and resolution of various imaging modalities (such as MRI, CT, X-ray and optical tomography). NVIDIA is at the forefront of these advances, providing radiologists with more powerful artificial intelligence capabilities through its parallel processing toolkit, allowing imaging systems to handle more data and computational loads more efficiently.
Astronomy: Some new astronomical phenomena, such as the understanding of black holes, can only be achieved using parallel supercomputers.
UnityGame Engine:The Unity engine uses GPU power (built for large-scale graphics workloads) to help improve Performance and speed. The engine is equipped with multi-threading and parallel processing capabilities for a seamless gaming experience and the ability to create complex and realistic gaming environments.
Let’s look at three blockchains that have deployed parallel execution environments. First, we look at Solana, then two EVM-based chains - Monad and Sei.
From a high-level perspective, Solan’s design philosophy is that blockchain innovation should develop with hardware advancements. As hardware continues to improve over time in line with Moore's Law, Solana's design will benefit from increased performance and scalability. Solana co-founder Anatoly Yakovenko designed Solana’s original parallel architecture more than five years ago, and today, parallelism is rapidly spreading as a blockchain design principle.
Solana uses a deterministic parallelism approach, which comes from Anatoly's past experience with embedded systems, where all states are usually declared in advance. This enables the CPU to know all dependencies, allowing it to preload the necessary portions of memory. The result is optimized system execution, but again, it requires developers to do extra work up front. On Solana, all memory dependencies of a program are required and declared in the constructed transaction (i.e., access list), allowing the runtime to efficiently schedule and execute multiple transactions in parallel.
The next major component of Solana’s architecture is Sealevel VM, Solana’s parallel smart contract runtime. Sealevel natively supports parallel processing of multiple contracts and transactions based on the number of cores of the validator. Validators in a blockchain are network participants responsible for validating transactions, proposing new blocks, and maintaining the integrity and security of the blockchain. Because transactions declare in advance which accounts require read-write locks, the Solana scheduler is able to determine which transactions can be executed in parallel. Because of this, when it comes to validation, a “block producer” or leader is able to sequence thousands of pending transactions and schedule non-overlapping transactions in parallel.
The final design element of Solana is "pipelining". Pipelining is triggered when data needs to be processed in a series of steps, with each step being handled by different hardware. The key idea here is to take the data that needs to be run serially and use pipelining to parallelize it. These pipelines can run in parallel, and each pipeline stage can handle different transaction packages.
These optimizations allow Sealevel to organize and execute independent transactions simultaneously, leveraging the capabilities of the hardware to process multiple data points with one program at a time. Sealevel sorts instructions by programID and executes the same instructions in parallel on all related accounts.
Through these innovations, we can see that Solana is intentionally designed to support parallelization.
Sei is a general-purpose, open-source L1 blockchain dedicated to digital asset transactions. Sei V2 adopts an optimistic parallelism approach and therefore, it is more developer friendly. In optimistic parallelism mode, smart contracts can execute in parallel more seamlessly, without requiring developers to declare their resources in advance. This means that the chain optimistically runs all transactions in parallel. Nonetheless, when conflicts occur (i.e., multiple transactions access the same state), the blockchain will keep track of the specific storage components affected by each conflicting transaction.
Sei Blockchain uses the "Optimistic Concurrency Control (OCC)" mechanism to execute transactions. Concurrent transaction processing occurs when there are multiple transactions active in the system at the same time. This method of trading has two phases: execution and verification.
During the execution phase, transactions are processed optimistically, with all reads/writes temporarily stored in transaction-specific storage. Thereafter, each transaction will enter the verification phase, where the information in the temporary storage operation is checked against the state changes made by previous transactions. If transactions are independent, transactions will run in parallel. If data read by one transaction has been modified by another transaction, a conflict will occur. Sei's parallel system will identify each conflict by comparing the transaction's read data set with the latest state changes in the multi-version store, which are indexed in transaction order. Sei will re-execute and re-validate the instance where the conflict occurs. This is an iterative process that involves executing, validating, and re-running to fix conflicts. The diagram below illustrates how Sei handles transactions when conflicts arise.
The implementation of Sei is EVM developers provide lower gas fees and wider design space. Historically, EVM environments have been limited to less than 50 TPS, forcing developers to create applications that follow anti-patterns. Sei V2 gives developers access to areas that typically require high performance and low fees, such as DeFi, DePIN, and gaming.
Monad is building a parallel EVM L1 with full bytecode compatibility. What makes Monad unique is not only its parallel engine, but also the optimization engine they built under the hood. Monad adopts a unique holistic design approach that combines several key features such as pipelining, asynchronous I/O, consensus execution separation, and MonadDB.
A key innovation in the Monad design is pipelining with slight offset. Offsets allow parallelizing more processes by running multiple instances simultaneously. Therefore, pipelining is used to optimize many functions such as state access pipelining, transaction execution pipelining, consensus and execution internal pipelining, and pipelining within the consensus mechanism itself.
Next, we will look at the parallelization part of Monad in detail. In Monads, transactions are ordered linearly within blocks, but the goal is to reach the final state faster by leveraging parallel execution. Monad's execution engine is designed using an optimistic parallel algorithm. Monad’s engine processes transactions simultaneously and then performs analysis to ensure that the same results would be achieved if the transactions were executed one after the other. If there are any conflicts, you will need to re-execute. The parallel execution here is a relatively simple algorithm, but combining it with Monad’s other key innovations makes this approach novel. One thing to note here is that even if a re-execution occurs, it's usually cheap because the inputs required for the invalid transaction are almost always kept in the cache, so it will be a simple cache lookup. The re-execution is guaranteed to succeed because you have already executed the previous transaction in the block.
Monad also improves performance by decoupling execution and consensus (similar to Solana and Sei) and delaying execution. The idea is that if you relax the execution conditions so that execution completes before consensus is reached, you can run execution and consensus in parallel, adding extra time to both. Of course, Monad handles this situation using a deterministic algorithm to ensure that one of them doesn't get too far and lose control.
As I mentioned at the beginning of this article, state access is the One of the typical performance bottlenecks of blockchain. Design choices for state access and memory can ultimately determine whether a particular implementation of a parallel system will improve performance in practice. Let’s take a closer look at and compare the different methods used by Solana, Sei, and Monad.
Solana leverages horizontal scaling to Distribute and manage state data across multiple SSD devices. Today, many blockchains use general-purpose databases (i.e. LevelDB), which have limitations in handling large amounts of concurrent reads and writes of state data. To avoid this, Solana leveraged Cloudbreak to build its own custom account database.
Cloudbreak is designed for parallel access across I/O operations, rather than relying solely on RAM, which is inherently fast. I/O operations (input/output) are operations that read data from or write data to an external source such as a disk, network, or peripheral device. Initially, Cloudbreak used a RAM internal index to map public keys to accounts holding balances and data. However, as of this writing, the V1.9 index has been moved from RAM to SSD. This shift allows Cloudbreak to handle 32 (I/O) operations simultaneously in its queue, enhancing throughput across multiple SSDs. Therefore, blockchain data such as accounts and transactions can be accessed efficiently just like in RAM using memory mapped files. The following figure shows the memory structure. Although RAM is faster, it has smaller capacity than SSD and is generally more expensive:
By scaling out and distributing state data across multiple devices, Cloudbreak reduces latency and increases the efficiency, decentralization and network resiliency of the Solana ecosystem.
Sei redesigned its storage -- SeiDB -- to address several issues: write amplification (how much metadata is needed to maintain the data structure, the smaller the better), state bloat, slow operations, and performance degradation over time. The new redesign is now divided into two components: state storage and state commitments. Logging and validating any changes to the data is handled by the state promise, while the database recording all the data at any time is handled by the state store (SS).
In Sei V2, state commitment uses the memory-mapped IAVL tree architecture (MemIAVL). Memory mapped IAVL trees store less metadata, which reduces state storage and state synchronization time and makes running full nodes easier. A memory-mapped IAVL tree is represented as three files on disk (kv file, branch file, and leaf file); therefore, there is less metadata to keep track of, which helps reduce state storage by more than 50%. The new MemIAVL structure helps reduce the write amplification factor because it reduces the metadata required to maintain the data structure.
The updated SeiDB allows flexible database backend support for the state storage layer. Sei believes that different node operators have different needs and storage requirements. Therefore, SS is designed to adapt to different backend needs and provide operators with freedom and flexibility, such as PebbleDB, RocksDB, SQLite, etc.
Monad’s state access has some important of nuances. First, most Ethereum clients utilize two types of databases: B-Tree databases (i.e. LMDB) or log-structured merge tree (LSM) databases (i.e. RocksDB, LevelDB). Both of these are general-purpose data structures and are not specifically designed for blockchain. Furthermore, these databases do not take advantage of the latest advances in Linux technology, especially in asynchronous operations and I/O optimization. Finally, Ethereum itself manages state using MPT trees, which are dedicated to encryption, verification, and proof. The main problem is that the client has to integrate this specific MPT tree into a more general database (i.e. B-Tree/LSM), which brings serious performance drawbacks such as excessive disk accesses.
All of this helped lay the foundation for Monad’s decision to create a custom MonadDB database designed to handle blockchain data and state access more efficiently. Some of the key features of MonadDB include parallel access to the database, custom database optimized for Merkle Trie data, efficient state access over standard RAM usage, decentralization and scalability.
MonadDB is designed specifically for blockchain, making it more performant than using a general-purpose database. Customized MonadDB is designed to efficiently manage Merkle Trie type data and supports parallel access to multiple Trie nodes at the same time. Although the cost per read of MonadDB is the same as some of the general databases mentioned above, the key feature of MonadDB is that it can run multiple reads in parallel, resulting in huge speedups.
MonadDB supports synchronized state access to the database in parallel. Because Monad built this database from the ground up, it is able to leverage the latest Linux kernel technology and the full power of SSDs for asynchronous I/O. With asynchronous I/O, if a transaction requires reading state from disk, this should not cause any friction in the pending operation. Instead, it should start reading immediately while continuing to process other transactions. This is how asynchronous I/O significantly speeds up MonadDB processing. Monad can achieve better hardware performance by optimizing SSD usage and reducing reliance on excess RAM. This has the added benefit of aligning with decentralization and scalability.
In short, exploring the development of parallelism in blockchain through the perspectives of Solana, Sei and Monad can provide a comprehensive understanding of how different architectures and methods improve performance and scalability. Solana's deterministic parallelism focus on pre-declared state access provides predictability and efficiency, making it a strong choice for applications with high throughput requirements. Sei's optimistic parallelism approach, on the other hand, prioritizes developer flexibility and is ideal for environments where transaction conflicts are infrequent. With its unique approach to optimistic parallelism and custom MonadDB, Monad provides an innovative solution that leverages the latest technological advancements to optimize state access and performance.
Each blockchain offers a unique approach to solving parallelization challenges and has its own set of trade-offs. Solana is designed to maximize hardware utilization and throughput, while Sei focuses on streamlining the development process, and Monad focuses on providing tailored database solutions for blockchain data. These differences highlight the diversity of the blockchain ecosystem and the importance of choosing the right platform based on the specific needs of your application.
As the blockchain field continues to develop, the advancements in parallelization technology demonstrated by Solana, Monad, and Sei will undoubtedly inspire further innovation. The journey towards a more efficient, scalable and developer-friendly blockchain is ongoing, and the lessons learned from these platforms will play a vital role in shaping the future of blockchain technology.
Staking rewards are typically small relative to token price volatility, which should be considered the primary risk and potential source of reward for most crypto asset investments.
JinseFinanceEVM++ uses AI models to accurately predict transaction dependencies to reduce parallel execution conflicts, and maintains stable dApp performance through elastic block space.
JinseFinanceThis paper systematically explores how the block space allocation mechanism affects MEV.
JinseFinanceSolana is 46 times faster than Ethereum and more than 5 times faster than Polygon, the Ethereum scaling solution with the highest TPS.
JinseFinanceSocial media personality and former professional kickboxer Andrew Tate has recently endorsed a blockchain he believes will be “huge.”
FinboldOnce your transaction fees drop significantly below $0.01, the chain and its infrastructure become vulnerable to spam, DDoS, and tiny MEV attacks.
JinseFinanceRecently, AltLayer, the leading project in the Rollup as a service (RaaS) track, has launched the largest airdrop in 2024. The total value of the airdrop exceeds US$100 million, which has become a hotly discussed event in the Web3 community.
JinseFinanceThe last decade of cryptocurrencies has been a boom in “blockspace” commodities, and this boom is likely to continue for the next 5-10 years.
JinseFinanceThe storage system will use BNB as its native token and will become the third blockchain in the BNB ecosystem that already comprises of BNB Beacon Chain and BNB Smart Chain.
CryptoSlateAva Labs CEO Emin Gün Sirer said that this will simplify the experiences of Avalanche developers and users.
Cointelegraph