This article aims to illustrate the principles of parallel execution techniques, the similarities, differences, and challenges between these projects through Aptos, Sui, Linera, and Fuel.
When looking at the development of blockchain technology, we can see a strong trend that the new L1 focuses on parallel execution. This idea is not new, as parallel execution is currently used in Solana’s Sealevel execution environment. However, the impressive performance of DeFi and NFTs in the last bull market shows the urgent need for improvement. Some well-known projects currently adopting the concept of parallel execution are Aptos, Sui, Linera and Fuel.
This article discusses the similarities and differences between these projects, as well as the challenges they face.
problem lies in
Smart contract platforms enable the creation of a wide range of decentralized applications. In order to execute these applications, a shared computing engine is required. Every node in the network runs this computing engine and executes the application and user interaction with the application. When nodes get the same result from execution, they reach consensus and move the chain forward.
The Ethereum Virtual Machine is the dominant Smart Contract (SC) execution engine, with about 20 different implementations. Since its invention, EVM has been widely adopted by developers. In addition to Ethereum and Ethereum’s L2, several other chains such as Polygon, BNB Smart Chain, and Avalanche c Chain have adopted EVM as their execution engine and are working on changing the consensus mechanism to increase network throughput.
A major limiting feature of EVM is sequential sequential execution. The EVM essentially puts all other transactions into a paused state each time a transaction is executed, until the transaction execution is complete and the blockchain state is updated. Even if two transactions are independent, for example, a payment from Alice to Bob and another payment from Carol to Dave, the EVM cannot execute these transactions in parallel. While this execution model allows for interesting use cases like flash loans, it is neither efficient nor scalable.
This sequential execution of transactions is one of the major bottlenecks in network throughput. First, it causes transactions in blocks to take longer to execute, thereby limiting block times. Additionally, it limits the number of transactions that can be added to a block. The average throughput of Ethereum is about 17 tx/sec. This low throughput means that during periods of high activity, network miners/validators cannot process all transactions, and can lead to fee bidding wars that ensure transaction priority execution and drive up transaction fees. The average fee on Ethereum exceeds 0.2 ETH (~$800) at some points, putting many users off. The second problem with sequential execution is the inefficiency of network nodes. The execution of sequential instructions does not benefit from multi-core processors, which leads to low hardware utilization and inefficiency. This hinders scalability and leads to unnecessary energy consumption.
Can parallel execution solve this problem?
The fundamental limitations of the EVM structure set the stage for a new area of L1 focused on parallel execution (PE). Parallelism allows transaction processing to be divided among multiple processor cores, increasing hardware utilization and enabling better scalability. In a high-throughput chain, the increase in hardware resources is directly related to the number of transactions that can be executed. During periods of high activity, validator nodes can delegate more cores to handle additional transaction load. Dynamic scaling of computing resources allows the network to achieve higher throughput during periods of high demand, significantly improving the user experience.
Another advantage of this approach is improved transaction confirmation latency. The dynamic scaling of node resources enables low-latency confirmation transactions. Transactions do not need to wait for tens or hundreds of blocks or pay excessive fees to be prioritized. Improvements in confirmation times increase transaction finality, opening the door to low-latency blockchains. Guaranteed low latency for executing transactions enables several use cases that were not possible before.
Changing the execution mode of the chain to allow PE is not a new idea, and some projects have already explored it. One approach is to replace the accounting model used by the EVM from an account model to an unspent transaction output (UTXO) model. Bitcoin uses the UTXO execution model, which allows transactions to be processed in parallel, making it ideal for payments. Due to the limited functionality of UXTOs, extensions are required to implement the complex interactions required by smart contracts. As an example, Cardano uses an extended UTXO model for this, and Findora uses a hybrid UTXO model that implements two accounting models and allows users to change asset types in between.
Another approach to PE does not change the account model, but instead focuses on improving the architecture of the chain state. An example of this approach is Solana’s Sealevel framework, and this article focuses on the latter approach.
How parallel execution works
Parallel execution works by identifying independent transactions and executing them simultaneously. Two transactions are interdependent if the execution of one transaction affects the execution of another transaction. For example, AMM transactions in the same pool are interdependent and must be executed sequentially.
While the concept of parallel processing is simple, the problem is in the details. The main challenge is to effectively identify “independent” transactions. Sorting independent transactions requires understanding how each transaction changes the blockchain memory or chain state. Transactions that interact with the same smart contract can change the contract state at the same time and therefore cannot be executed at the same time. With the current degree of composability between applications, identifying dependencies is a challenging task.
Identify arm’s length transactions
In this section, the methods used by different parallel execution engines will be compared. The discussion focuses on ways to control state (memory) access. Blockchain state can be thought of as RAM storage. Each on-chain account or smart contract has a modifiable set of storage locations. Interdependent transactions are those that attempt to change the same memory location in the same block. Different chains use different memory architectures and different mechanisms to identify dependent transactions.
Several chains in this category are built on technology developed by Diem, the blockchain project Facebook has axed. The Diem team created the smart contract language Move to specifically improve the execution of SC. Aptos, Sui and Linera are three high-profile projects that fall into this category. In addition to them, Fuel is another well-known project focused on PE, which uses its own SC language.
Aptos builds on Diem’s Move language and MoveVM to create high-throughput chains that enable parallel execution. Aptos’ approach is to detect dependencies while being transparent to the user/developer, which means that transactions are not required to explicitly state which part of the state (memory location) they are using. Aptos uses a modification of Software Transaction Memory (STM) called Block-STM. In Block-STM, transactions are pre-ordered in blocks and divided among processor threads during execution for optimistic execution. In execution, the execution of a transaction is assumed to have no dependencies. The memory locations modified by the transaction are recorded. All transaction results will be verified after execution. During verification, if a transaction is found to have accessed a memory location modified by a previous transaction, the transaction is declared invalid. The transaction result will be refreshed and the transaction will be re-executed. This process repeats until all transactions in the block have been executed. Block-STM can improve execution speed when using multiple processor cores. The speed depends on how interdependent the transactions are. The Aptos team’s results show that using 32 cores can increase the speed by 8 times with high interdependence and 16 times with low interdependence. If all transactions in a block are interdependent, then Block-STM will have a smaller performance penalty compared to sequential execution. Aptos claims that this approach can achieve a throughput of 160,000 TPS.
Another PE approach is to require transactions to explicitly state which parts of the chain state they have modified. Solana and Sui currently use this approach. Solana refers to memory cells as accounts, and a transaction must state which accounts it modifies. Sui also uses a similar approach.
Sui also builds on Diem’s technology with MoveVM. However, Sui uses a different version of the Move language. The implementation of Sui Move changes Diem’s core storage model and asset permissions. This represents its main difference from Aptos using the core Diem Move. (We have analyzed the difference between Sui and Aptos before. If you are interested, please go to Allrecord to refactor.) Sui Move defines a state storage model to make it easier to identify independent transactions. In Sui, state stores are defined as objects. Objects usually represent assets and can be shared, which means that multiple users can modify an object. Each object has a unique ID in the Sui execution environment and has an internal pointer to the owner’s address. Using these concepts, it is easy to identify dependencies by checking whether transactions use the same objects.
By offloading the work of declaring dependencies to the developer, the implementation of the execution engine becomes easier, which means it can theoretically have better performance and scalability. However, this comes at the cost of a less than ideal developer experience.
Sui is not live yet, the project just recently went live on their testnet. The founders of Sui claim that the implementation of parallel execution and the use of the Narwhal & Tusk consensus mechanism can lead to throughputs exceeding 100,000 tx/sec. If true, Sui would be a huge improvement over Solana’s current throughput of ~2400 tx/sec, and would surpass Visa and Mastercard’s throughput.
Linera is the latest addition to the parallel processing space, and they recently announced their first round of funding led by a16z. There are not many details about the implementation of the project. However, based on their funding announcement, we know it’s based on the FastPay protocol also developed at Facebook. Fastpay is based on a technology called Byzantine Consistent Broadcast. The technology focuses on accelerating independent payments, such as those that take place in a point-of-sale network. It allows a group of validators to ensure the integrity of payments as long as more than two-thirds of them are honest. Fastpay is a variant of the Real Time Gross Settlement (RTGS) system used in networks of banks and financial institutions.
Linera plans to build a blockchain based on FastPay, focusing on fast settlement and low latency by executing payment transactions in parallel. It is worth noting that Sui also uses the Byzantine Consistent Broadcast method for simple payments. For other transactions, Sui uses its own consensus mechanisms, Narwhal and Tusk, to efficiently handle more complex and dependent transactions such as DeFi transactions.
Fuel aims to be the execution layer in a modular blockchain stack. This means that Fuel does not implement consensus and does not store blockchain data on the Fuel Chain. For a functional blockchain, Fuel interacts with other chains (like Ethereum or Celestia) for consensus and data availability.
Fuel uses UTXOs to create strict access lists, using a list to control access to the same piece of state. The model builds on the concept of classical transaction ordering. In this scheme, the ordering of transactions in blocks greatly simplifies the detection of dependencies between transactions. To implement this architecture, Fuel built a new virtual machine called FuelVM and a new language called Sway. FuelVM is a compatible and simplified implementation of EVM that effectively guides developers into the Fuel ecosystem. Additionally, due to Fuel’s focus on modular blockchain stacks, the execution of Fuel SC can take place on the Ethereum mainnet. This approach aligns with Ethereum’s vision as a rollup-centric settlement and data availability layer after the merger.
As a proof-of-concept, the Fuel team created a Uniswap-style AMM called SwaySwap, which is currently running on a testnet to demonstrate the improved performance of FuelVM compared to EVM.
Challenges of executing methods in parallel
Executing methods in parallel seems logical and straightforward. However, there are still some challenges to discuss. The first is to estimate the actual proportion of transactions that can be accelerated using this parallel execution. The second challenge is the decentralization of the network, that is, if validators can easily scale their computing power to increase throughput, how can full nodes, often using commodity hardware, keep up to ensure chain correctness?
Percentage of parallel transactions
Accurately estimating the percentage of on-chain transactions that can be executed in parallel is a challenge. Also, depending on the type of network activity, this percentage can vary widely from block to block. For example, an NFT minting activity may lead to a surge in dependent transactions. That said, we can use some assumptions to get a rough estimate of the average percentage of parallelizable transactions. For example, we can assume that most ETH and ERC20 transfers are independent. Therefore, we can assume that about 25% of simple ETH and ERC20 transfers are interdependent. On the other hand, all AMM transactions in the same pool are interdependent. Considering that most AMMs are typically dominated by a few pools, and that AMM transactions are highly composable and interact with multiple pools, we can safely assume that at least 50% of AMM transactions are interdependent.
By doing some analysis of Ethereum’s transaction categories, we can find that out of about 1.2 million daily transactions in Ethereum, 20-30% are ETH transfers, 10-20% are stablecoin transfers, and 10-15% are DEXs For transfers, 4-6% are NFT transactions, 8-10% are ERC20 approvals, and 12-15% are other ERC20 transfers. Using these numbers and assumptions, we can estimate that PE can accelerate about 70-80% of transactions on the SC platform. This means that the sequential execution of dependent transactions may account for 20-30% of all transactions. In other words, PE throughput might be 3 – 5 times higher if the same gas limit is used. Some experiments on building parallel execution EVMs also show similar estimates. In practice, high-throughput chains will achieve at least 100x higher throughput than Ethereum by using higher gas per block limits and shorter block times. The increased throughput requires powerful validator nodes to process these blocks. This requirement leads to the problem of network centralization.
Another common criticism of parallel processing is that it greatly drives the centralization of the network. In a high-throughput network, the network can process tens of thousands of transactions per second. Validator nodes are incentivized by fees and network rewards to process these transactions, and invest in dedicated servers or scalable cloud architectures to process these transactions. The situation is different for companies or individuals who use the chain and need to run full nodes to interact with the chain. These entities cannot afford complex servers to handle such a massive transaction load. This will push on-chain users to rely on specialized RPC node providers like Infura, leading to more centralization.
Without the option of running an entire node with consumer-grade hardware, a high-throughput chain could become a closed system in which a small group of entities have absolute power over the network. In this case, these entities can coordinate to review transactions, entities, and even applications, turning these chains into permissioned systems indistinguishable from Web 2.
Currently, the requirements to run a full node on the Sui testnet are lower than those on the Aptos testnet node. However, we expect these requirements to change significantly when the mainnet launches and applications start appearing on-chain. Decentralization advocates have been proposing solutions to these anticipated problems. Among the solutions are the use of lightweight nodes to verify the correctness of blocks through zk validity proofs or fraud proofs. The Fuel team has been very active in this regard and aligned with the Ethereum community on the importance of decentralization. The Aptos and Sui teams have not yet clearly articulated priorities for implementing these methods or other ways to promote decentralization. The Linera team briefly discusses these issues in their introductory article, but the implementation of the protocol has yet to confirm this promise.
Parallel execution engines are expected to improve the throughput of smart contract platforms. By incorporating innovations in consensus mechanisms, the parallel execution of transactions can enable chain throughputs approaching or exceeding 100k TPS. Such performance is comparable to Visa and Mastercard, enabling several currently challenging use cases such as full on-chain gaming and decentralized micropayments. These impressive improvements face the challenge of ensuring decentralization. We look forward to founders working on solving these problems.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/what-is-parallel-execution-take-aptos-sui-linera-and-fuel-as-examples-to-explain-to-you/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.