Original title: "The Case for Parallel Processing Chains》
Original compilation:
Original compilation:Deep Tide TechFlow
Deep Tide TechFlow
As we revisit the evolution of blockchain technology, we can see a strong trend emerging, namely the new L1 focus on parallel execution.
This is nothing new, Solana is currently used in Sealevel's execution environment.
However, the impressive performance of DeFi and NFT in the past bull market has also brought awareness to the fact that the technology is in dire need of improvement.
This article will discuss the similarities and differences of these projects, as well as the challenges they face.
question
questionSmart contract platforms can create 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, as well as executes the application and the user's 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 primary Smart Contract (SC) execution engine, with about 20 different implementations.
Since the EVM was invented, it has built a critical mass of developer adoption.
In addition to Ethereum and Ethereum's L2, several other chains including Polygon, BNB Smart Chain, and Avalanche C Chain all adopt EVM as the execution engine and focus on changing the consensus mechanism to improve network throughput.A major limiting feature of the EVM is the sequential execution of transactions.
The EVM basically executes transactions one at a time, putting all other transactions on hold until the transaction is executed 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 mode of execution allows for interesting use cases such as flash loans, it is neither efficient nor scalable.
This sequential execution of transactions is one of the main bottlenecks in network throughput:
First, it causes transactions in blocks to take longer to execute, limiting block times;
Additionally, it limits the number of transactions that can be added to a block to enable nodes to execute transactions and confirm blocks.
The average throughput of Ethereum is about 17 tx/s. This low throughput means that during periods of high activity, such as NFT Mint, network miners/validators cannot process all transactions, and fee bidding wars ensue to ensure priority execution, driving transaction fees up. The average fee on Ethereum exceeded 0.2 ETH (~$800) at some point, which discouraged many users from using Ethereum.The second problem with sequential execution is the inefficiency of network nodes.
Sequential instruction execution cannot benefit from multiple processor cores, which leads to low hardware utilization and inefficiency. This hinders scalability and leads to unnecessary energy consumption.
Can parallel execution solve this problem?The constraints of the EVM architecture allow for a new L1 realm of parallel execution (PE).
Parallelism allows transaction processing to be divided among multiple processor cores, increasing hardware utilization and thus enabling better scalability. In high-throughput chains, increasing 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 user experience.
Another advantage of this method is that the latency of transaction confirmation is improved, and the dynamic expansion of node resources makes it possible to confirm all possible network loads with low-latency transactions.Transactions do not need to wait for tens or hundreds of blocks, nor do they need to incur excessive fees for priority confirmation.
Improved confirmation times increase transaction finality, opening the door to low-latency blockchains. Guaranteed low latency for executing transactions enables several previously impossible use cases.
Changing the chained execution model to allow PE is not a new idea, and several projects have explored it. One approach is to replace the accounting model used by the EVM from the Accounts model to the Unspent Transaction Output (UTXO) model. The UTXO execution model used in Bitcoin allows transactions to be processed in parallel, which makes it ideal for payments.However, due to the limited functionality of UXTO, it needs to be extended to enable the complex interactions required by smart contracts.
For example, Cardano uses an extended UTXO model for this purpose, while Findora uses a hybrid UTXO model, which implements two accounting models and allows users to change asset types between the two models.Another approach to PE does not change the account model, but instead focuses on improving the architecture and modification of the chain state.
For example Solana's Sealevel framework.
How does parallel execution work?Parallel execution works by identifying independent transactions and executing them concurrently.
Two transactions are associated if the execution of one transaction affects the execution of another transaction. For example, AMM transactions in the same pool are linked and must be executed sequentially."Although the concept of parallel processing sounds simple, the difficulty lies in the details. The main challenge is how to effectively identify"independent
trade. Classification of independent transactions requires an understanding of how each transaction changes the blockchain memory or chain state. Transactions that interact with the same smart contract (such as an AMM pool) 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 whether they are related to each other is a challenging task. Imagine an AMM transaction exchanging UNI for USDC, and the AMM finds that the most efficient route to execute it is UNI -> ETH -> DAI -> AAVE -> USDC. All pools participating in the transaction cannot process any other transactions until the transaction is fully executed, then the state of all participating pools can be updated.
Identify independent transactions
Several chains in this category are built on technology developed by Facebook's defunct blockchain project Diem. The Diem team created the smart contract language Move specifically to improve SC execution. Aptos, Sui, and Linera are three high-profile projects that fall into this group. Besides this group, Fuel is another well-known project focused on PE, using its own SC language.
Aptos
secondary title
Aptos builds on Diem's Move language and MoveVM to create a high-throughput chain that enables parallel execution.Aptos' approach is to detect associations while being transparent to users/developers
, that is, transactions are not required to explicitly state which part of the state (memory location) they use.
Aptos uses a modified version of Software Transactional Memory (STM), called Block-STM.
In Block-STM, transactions are pre-ordered within blocks and divided among processor threads in order to be executed.
In the process, the execution of the transaction is assumed to be unrelated. The memory locations modified by transactions are recorded, and after execution, the results of all transactions are verified. During verification, if a transaction is found to access a memory location that was modified by a previous transaction, the transaction will be annulled. The results of the transaction are flushed and re-executed.
This process is repeated until all transactions in the block have been executed.
When multiple processor cores are used, Block-STM speeds up execution, depending on how interconnected the transactions are.The Aptos team's results showed that,If all transactions in a block are interdependent, then Block-STM can cause a slight penalty in performance compared to sequential execution. Aptos claims that this approach can achieve a throughput of 160,000 TPS.
Sui
secondary title
Another PE approach is to require transactions to explicitly state which parts of the chain state they modify, an approach currently used by Solana and Sui.
Solana refers to units of memory as accounts, and a transaction must state which accounts it modifies. Sui also used a similar approach.Sui also builds on Diem's technology by using 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, which represents a significant difference from Aptos using core Diem Move.
Sui Move defines a state storage model that allows for easier identification of independent transactions.
In Sui, state storage is defined as Objects. Objects typically represent assets and can be shared, meaning multiple users can modify the object. Each Object has a unique ID in the Sui execution environment, and has an internal pointer pointing to the address of the owner. By using these concepts, it is easy to identify associations by checking whether transactions use the same Objects.
By shifting the work of declaring relationships to the developer, the implementation of the execution engine is made easier, which means that it can theoretically have better performance and scalability. However, this comes at the cost of a less-than-ideal developer experience.
The founders of Sui claim that the implementation of parallel execution and the use of Narwhal and Tusk consensus mechanisms resulted in a throughput of over 100,000 tx/sec. This throughput, if true, could be a big boost over Solana's current throughput of about 2400 tx/sec, and would exceed the throughput of Visa and Mastercard.
Linera
secondary titleLinera is the newest entrant in the parallel processing space and recently announced their first round of funding, led by a16z.
There are few details about the implementation of the project. However, based on their funding announcement post, we know it's based on the FastPay protocol, also developed at Facebook.
Based on FastPay, Linera is planning to build a blockchain that focuses 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's own consensus mechanism Narwhal and Tusk are used to efficiently handle more complex and relational transactions such as DeFi transactions.
Fuel
secondary titleFuel is focused on being the execution layer in a modular blockchain, meaning that Fuel does not enforce consensus or store the blockchain's data on the Fuel chain.
For functional blockchains, Fuel interacts with other chains for consensus and data availability, such as Ethereum or Celestia.
Fuel uses UTXO to create a strict access list, that is, a list to control access to the same piece of state. This model builds on the concept of canonical transaction ordering. In this scheme, the ordering of transactions in blocks leads to a significant simplification in detecting associations between transactions. To implement this architecture, Fuel created a new virtual machine called FuelVM and a new language called Sway.
FuelVM is a compatible and simplified representation of EVM, which can effectively allow developers to join the Fuel ecosystem.
To prove the concept, the Fuel team has created an AMM called SwaySwap, similar to Uniswap, and running it on a testnet. The purpose is to demonstrate the higher performance of FuelVM compared to EVM.
first level title
The approach of parallel execution seems logical and straightforward, however, currently we still face several challenges. The first is to estimate the actual proportion of transactions that can be accelerated using this type of parallel execution. The second challenge is the decentralization of the network, that is, if validators can easily scale computing power to increase throughput, how can full nodes keep up to ensure the correctness of the chain?
first level title
Percentage of transactions that can be parallelizedAccurately estimating the percentage of on-chain transactions that can be executed in parallel on any chain is challenging.
Also, this percentage can vary greatly from block to block, depending on the type of network activity.
For example, an NFT Mint could cause an explosion with a high percentage of related transactions. That said, we can use some assumptions to get a rough estimate of the average percentage of transactions that can be parallelized.
For example, we can assume that most ETH and ERC20 transfers are independent, i.e. originated from and received from different addresses. So we can assume that about 25% of ETH and ERC20 transfers are interrelated, namely deposits to SC and aggregation of assets from exchange hot wallets to cold wallets.
On the other hand, all AMM transactions in the same pool are correlated. Given that most AMMs are typically dominated by a small number of 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 interconnected.
By analyzing the transaction categories of Ethereum, we can find that among the approximately 1.2 million transactions in Ethereum per day, 20-30% are ETH transfers, 10-20% are stable currency transfers, and 10-15% are DEX 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 approximately 70-80% of transactions in the SC platform.This means that the sequential execution of related transactions accounts for 20-30% of all transactions.
In other words, if the same gas limit is used, it is possible to achieve a 3-5 times increase in throughput through PE.
In practice, high-throughput chains use higher gas limits and shorter block times to achieve at least 100x throughput improvement over Ethereum. The increased throughput requires powerful validating nodes to process these blocks, a requirement that leads to the second challenge, centralization of the network.
first level title
Centralization of the network
In a high-throughput network, the network can handle tens of thousands of transactions per second.
Validators are incentivized by fees and network rewards to process these transactions, and invest in dedicated servers or scalable cloud architectures to process these transactions. This is not the case 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 massive transaction loads. This will drive on-chain users to rely on specialized RPC node providers, such as Infura, leading to more centralization.
Without the option to use consumer-grade hardware to run full nodes, a high-throughput chain can become a closed system, with a small group of entities having absolute power over the network. In this case, these entities can coordinate vetting transactions, entities and even applications, such as Tornado Cash, that can turn these chains into permissioned systems not unlike Web 2.Currently, the requirements to operate a full node on the Sui testnet are lower than the requirements for an Aptos testnet node.
However, we expect these needs to change significantly when mainnet launches and applications start appearing on-chain.
The Fuel team is active in this regard, in line with the spirit of the Ethereum community on the importance of decentralization. It is not clear whether the Aptos and Sui teams are prioritizing implementing these methods or otherwise promoting decentralization. The Linera team briefly discussed these issues in their introductory post, but the protocol implementation has yet to confirm this commitment.
Summarize
Summarize
Parallel execution engines are a promising solution to increase the throughput of smart contract platforms.
Original link
