Parallelization
Basics
"In many computing systems, operations are executed sequentially. This means that a second operation will only start after the first one is completed, and so on.
In blockchain transactions, this means processing each transaction in a block one after the other, known as sequential execution. Each transaction necessitates validation from the entire network, resulting in substantial energy consumption and a heightened workload for validators.
This sequential execution of transactions is one of the main bottlenecks to the Ethereum Virtual Machine (EVM) engine’s throughput. Sequential execution bloats the mempool resulting in high transaction costs, mooning gas fees, and a fractured user experience. It impedes the creation of scalable and cost-efficient dApps.
Parallel execution breaks from this sequential model enabling multiple operations to co-occur. It permits the simultaneous processing of multiple transactions allowing the network to achieve increased throughput — reducing the likelihood of congestion during periods of high demand. This enhances the network’s efficiency and scalability for blockchain dApps, significantly improving the user experience."
Approaches to parallel execution
"The two most prevalent methods for parallelizing transactions on a monolithic blockchain are a state access method or executing optimistically. The state access method proactively identifies transactions' access to specific parts of the blockchain's state, making it easy to declare independence and execute specific transactions in parallel. In contrast, the optimistic model assumes all transactions are independent initially, only to retrospectively verify this assumption and re-execute transactions that are not parallelizable.
Both methods are currently utilized in blockchains. Networks like Monad and Aptos implement optimistic parallelization, whereas Sui and Solana utilize state access methods. Optimistic methods are advantageous for their simplicity, requiring less effort from developers in defining transactions. However, executing optimistically introduces the potential for transaction conflicts and other inefficiencies during retrospective verification. State access methods, though requiring a bit more effort from developers, offer more predictable outcomes and avoid latency impacts from retroactive verification.
State access methods also enable more dynamic gas fee markets. Because dependencies are declared upfront, transactions involved in a highly congested part of the blockchain state can be treated differently than others. For instance, a highly popular NFT mint may generate massive amounts of transaction requests in a short timeframe. A network employing a state access method can identify blockchain state hotspots, such as the NFT minting contract, and rate-limit, and even charge more for transactions involving hotspots.
This allows standard transactions to proceed smoothly, while transactions related to the minting process are prioritized separately based on the the total gas associated with the transactions. On Sui, transactions are included into a checkpoint on a first-come-first-serve basis, but within the checkpoint are ordered based on gas provided. This creates a dynamic that allows for those interested in paying to have priority within a checkpoint without unfairy excluding transactions from a checkpoint that are not offering additional gas so long as they meet the minimum requirements. Achieving this level of granularity is not as easily feasible with optimistic parallel execution."
Blockchain Examples
The pioneer of parallelization was Solana, which got copycats like Aptos, Sei and Sui. This got followed up by EVM type protocols such as Solana based Neon and standalone L1 Monad. Aptos, Sei and Monad go for optimistic parallelization. Polygon PoS as well (3-1-2024).
