The core of parallelism is to improve the execution efficiency of the execution layer through multi-path execution. To achieve multi-path execution, the chain needs to implement a series of mechanisms such as conflict detection and rollback to ensure that they can execute in parallel without affecting the final state consistency, and to make certain improvements to the database.

Written by: Tia, Techub News

Blockchain sacrifices efficiency due to its decentralized design, making the enhancement of execution speed one of the urgent issues to be solved. The "execution layer" of the blockchain is a key part that processes each transaction and adds it to the chain. To accelerate processing capabilities, enhancing the execution layer has become one of the core strategies, and parallel execution is an important breakthrough in this regard.

Traditional blockchains typically process transactions serially, which greatly limits transaction speed, especially in transaction-intensive networks where congestion can occur. However, through parallel execution, multiple transactions can be processed simultaneously, significantly improving execution efficiency and alleviating on-chain pressure.

To better understand what parallel execution is, we will first introduce execution and use Ethereum under the PBS model after the Merge as an example to explain what execution is, while also demonstrating the position of execution in the entire transaction lifecycle.

Specific Steps of Transaction Execution

1. Transactions enter the mempool and are filtered and sorted: This is the preprocessing stage after a transaction is submitted, involving the interaction of Mempool, Searcher, and Builder to complete the filtering and sorting of transactions.
2. Builder constructs the block (but does not execute): The Builder arranges profitable transactions into a block to complete the packaging and sorting of transactions.
3. Proposer verifies and submits the block: After the block is constructed, the Builder sends the block proposal to the Proposer. The Proposer verifies the structure of the block and the transaction content, then formally submits the block to the network to begin execution.
4. Execute transactions: After the block is submitted, nodes execute the transactions in the block one by one. This is a critical phase for state updates, where each transaction triggers smart contract calls, account balance changes, or state changes.
5. Witnessing by validators: Validators witness the execution results and state root of the block and confirm them as final. This ensures the authenticity and validity of the block at the execution layer and prevents inconsistencies.
6. State synchronization: Each node synchronizes the execution results of the block (such as account balances, contract state updates, etc.) to its local state. After executing each transaction, the node calculates and stores a new state root to serve as the initial state in the next block.

Of course, this is just the state synchronization of transactions on a block basis. To maintain the latest on-chain state, nodes typically synchronize data block by block and continuously validate blocks and states. However, to achieve finality under the POS mechanism, aggregators need to aggregate the signatures of witnesses in each Slot into a complete signature and pass it to the proposer of the next Slot. Validators need to confirm the state of all blocks within that Epoch based on the number of votes after one Epoch, forming a temporary consensus state checkpoint. Only when two consecutive Epochs receive the support of the majority of validators will the blocks and transactions achieve finality.

From the perspective of the entire transaction lifecycle, execution occurs after the Proposer verifies the structure and transaction content of the block sent by the Builder. The actual execution process requires processing transactions one by one and updating the corresponding account or contract state. After all transactions are executed, the Proposer calculates a new state root (Merkle root), which summarizes the execution results of all transactions in the current block and the final global state. In simple terms, the complete block execution process includes a series of calculations needed to transition Ethereum from the previous state to the next state, from the execution of each transaction to the calculation of the Merkle root.

Sequential Execution

In contrast to parallel execution, sequential execution is the more common execution method in current blockchains. Typically, transactions are executed step by step in order. When a transaction completes execution, Ethereum updates the account state and related information (such as balance, contract storage data) in the account state tree, generating a new account state hash. Once all account state trees are updated, a root node hash known as the state Merkle root is formed. After completing the state Merkle root, transaction Merkle root, and receipt Merkle root, the block header undergoes hash calculation to generate the block hash.

In this process, the order of transaction execution is crucial. Since the Merkle tree is a binary tree of hash values, different orders will yield different Merkle root values.

Parallel Execution

In a parallel execution environment, nodes attempt to process transactions in the block in parallel. Instead of executing transactions one by one in order, transactions are assigned to different "execution paths" so that they can execute simultaneously. Through parallel execution, the system can process transactions in the block more efficiently, increasing throughput.

Once all transactions are executed, nodes will summarize the execution results (i.e., the state updates affected by the transactions) to form a new block state. This state will be added to the blockchain, representing the latest global state on the chain.

State Conflicts

Since parallel execution processes transactions simultaneously on different paths, one major challenge of parallelism is state conflicts. This means that multiple transactions may attempt to read or write to the same part of the data (state) on the blockchain at the same time. If not handled properly, this can lead to uncertain execution results. Because the order of state updates differs, the final computation results may also differ. For example,

Suppose there are two transactions, Transaction A and Transaction B, both trying to update the balance of the same account:

• Transaction A: Increase account balance by 10.
• Transaction B: Increase account balance by 20.

The initial balance of the account is 100.

If we execute them serially, the results of the execution order are determined:

1. Execute Transaction A first, then Transaction B:

• The account balance increases by 10 first, becoming 110.
• Then it increases by 20, ultimately becoming 130.

1. Execute Transaction B first, then Transaction A:

• The account balance increases by 20 first, becoming 120.
• Then it increases by 10, ultimately becoming 130.

In both of these orders, the final balance is 130 because the system ensures the consistency of the transaction execution order.

However, in a parallel execution environment, Transactions A and B may read the initial balance of 100 and perform their calculations simultaneously:

1. Transaction A reads the balance as 100, calculates, and updates the balance to 110.
2. Transaction B also reads the balance as 100, calculates, and updates the balance to 120.

In this case, because the transactions execute simultaneously, the final balance is only updated to 120 instead of 130, as the operations of Transactions A and B "overwrote" each other's results, resulting in a state conflict.

Such state conflict issues are often referred to as "data overwriting," meaning that when transactions attempt to modify the same data simultaneously, they may overwrite each other's computation results, leading to an incorrect final state. Another type of state conflict may lead to the inability to guarantee execution order. Since multiple transactions complete operations at different times, this can result in different execution orders. Different orders may lead to different computation results, making the results uncertain.

To avoid this uncertainty, blockchain parallel execution systems typically introduce some conflict detection and rollback mechanisms or conduct dependency analysis on transactions in advance to ensure they can execute in parallel without affecting final state consistency.

Optimistic Parallelism vs. Deterministic Parallelism

There are two approaches to dealing with potential state conflict issues: deterministic parallelism and optimistic parallelism. These two modes have trade-offs in terms of efficiency and design complexity.

Deterministic parallelism requires declaring state access in advance. Validators or sequencers check the declared state access when sorting transactions. If multiple transactions attempt to write to the same state, these transactions are marked as conflicts to avoid simultaneous execution. Different chains implement the declaration of state access in various ways, but generally include the following methods:

• Through contract specifications: Developers directly specify the scope of state access in smart contracts. For example, an ERC-20 token transfer requires access to the balance fields of the sender and receiver.
• Through structured data declaration in transactions: Adding specific fields in transactions to indicate state access.
• Through compiler analysis: Compilers for high-level languages can statically analyze contract code to automatically generate a set of state accesses.
• Through framework-enforced declarations: Some frameworks require developers to explicitly specify the state to be accessed when calling functions.

Optimistic parallelism, on the other hand, processes transactions optimistically first and re-executes the affected transactions in order when conflicts occur. To minimize the occurrence of conflicts, the core of optimistic parallelism design is to quickly predict and hypothesize states through historical data, static analysis, etc. This means that the system assumes certain operations or state updates are valid without complete verification, aiming to avoid waiting for all verification processes to improve performance and throughput.

Although optimistic parallelism can avoid conflicts as much as possible through quick predictions and hypotheses about states, there are still some unavoidable challenges, especially involving contract execution or cross-chain transactions. If conflicts occur frequently, re-execution may significantly slow down system performance and increase computational resource consumption.

Deterministic parallelism avoids the potential conflicts that may arise from optimistic parallelism by performing state dependency checks before transactions, but this requires developers to accurately declare state dependencies before transaction submission, thus increasing implementation complexity.

EVM Parallelism Dilemma

Dealing with state conflicts is not only a matter of determinism versus optimism; in the specific process of implementing parallelism, it also needs to be considered from the perspective of the chain database architecture. The issue of state conflicts in parallelism is particularly challenging in the EVM under the Merkle tree architecture. The Merkle tree is a hierarchical hash structure, and each time a transaction modifies a piece of state data, the root hash of the Merkle tree also needs to be updated. This update process is recursive, calculating from the leaf nodes up to the root node. Since hashes are irreversible, the upper layers can only be calculated after the lower layers have completed their data changes, making it difficult to update in parallel.

If two transactions execute in parallel and access the same state (such as account balance), it will cause conflicts in the Merkle tree nodes. Resolving such conflicts typically requires additional transaction management mechanisms to ensure that a consistent root hash value can be obtained across multiple branches. This is not easy to implement for the EVM, as it requires a trade-off between parallelization and state consistency.

Non-EVM Parallel Solutions

Solana

Unlike Ethereum's global state tree, Solana adopts an account model. Each account is an independent storage space stored in the ledger, thus avoiding path conflict issues.

Solana is deterministic parallelism. In Solana, each transaction must explicitly declare the accounts it will access and the required access permissions (read-only or read-write) at the time of submission. This design allows blockchain nodes to analyze the resources each transaction needs to access before executing the transaction. Since all account dependencies are clearly defined before execution begins, nodes can determine which transactions will access the same accounts and which transactions can be safely executed in parallel, thus achieving intelligent scheduling and avoiding conflicts, laying the foundation for parallel scheduling.

Since each transaction has declared the accounts and permissions it needs to access before execution, Solana can check for account dependencies between transactions (Sealevel model). If there are no shared read/write accounts between transactions, the system can assign them to different processors for parallel execution.

Aptos

Aptos's design for parallel execution is significantly different from Ethereum, making some key innovations in architecture and mechanisms, primarily reflected in its account model and state storage.

Ethereum frequently updates a global state tree (MPT) when executing transactions. All account and contract states are stored in a shared state tree, and any transaction needs to access and update a part of this state tree. In contrast, Aptos divides accounts into independent state units, where each object is an independent key-value pair. Objects can exist independently of each other and are only associated when there is a clear reference relationship. There are no common tree paths between objects, eliminating lock contention and allowing for complete parallelism.

Aptos's underlying data structure is the Jellyfish Merkle Tree. The state of each object is ultimately stored in the JMT as independent key-value pairs. Unlike Ethereum's MPT, the Jellyfish Merkle Tree is structured as a complete binary tree, simplifying the storage and query paths of nodes and significantly reducing verification time. Additionally, each account's position in the tree is fixed, and the nodes in the tree are stored independently, allowing for parallel updates and lookups of multiple accounts.

Aptos employs optimistic parallelism, which does not require pre-declaring all account dependencies. To achieve this, Aptos uses Block-STM, which estimates dependencies based on a preset transaction order to reduce the number of rollbacks.

Parallel EVM

Compared to non-EVM parallelism, parallel EVM faces greater technical challenges in handling state dependencies, conflict detection, gas management, and rollback mechanisms. To better understand this, we can refer to how some parallel EVM projects (such as Sui, Monad, Canto) address these issues.

Sui

Like Aptos, Sui also uses an object model to handle state, treating each object (such as account or smart contract state) as an independent resource, distinguished by unique object identifiers. When transactions involve different objects, these transactions can be processed in parallel because they operate on different states without direct conflicts.

Although Sui uses an object model to manage state, it bridges the object model and EVM's account model through an additional adaptation layer or abstraction mechanism to ensure compatibility.

In Sui, transaction scheduling employs an optimistic parallel strategy, assuming there are no conflicts between transactions. If a conflict occurs, the system uses a rollback mechanism to restore the state.

Sui utilizes an object model and state isolation techniques to effectively avoid state dependency issues. Each object acts as an independent resource, allowing different transactions to execute in parallel, thereby increasing throughput and efficiency. However, the trade-off of this approach is the complexity of the object model and the overhead of the rollback mechanism. If conflicts occur between transactions, requiring a rollback of some states, this increases the system's burden and may impact the efficiency of parallel processing. Compared to non-EVM parallel systems (like Solana), Sui requires more computational and storage resources to maintain efficient parallelism.

Monad

Like Sui, Monad also adopts optimistic parallelism. However, Monad's optimistic parallelism predicts some transactions with dependencies before executing them. This prediction is primarily accomplished through Monad's static code analyzer. The prediction requires access to the state, and the way Ethereum's database stores states makes accessing the state very difficult. To enhance the efficiency of parallelism during the state reading process, Monad has also restructured the database.

Monad's state tree is partitioned, with each partition maintaining its own state subtree. During updates, only the relevant shards need to be modified, eliminating the need to rebuild the entire state tree. A state index table quickly locates states within partitions, reducing interactions between partitions.

Summary

The core of parallelism is to improve the execution efficiency of the execution layer through multi-path execution. To achieve multi-path execution, the chain needs to implement a series of mechanisms such as conflict detection and rollback to ensure they can execute in parallel without affecting final state consistency, along with making certain improvements to the database.

Of course, improving the efficiency of the execution layer is not limited to parallelism; optimization of the execution process can also be achieved by reducing the read and write operations required by a transaction on the database. The overall speed enhancement of the chain involves a broader scope, including improvements in consensus layer efficiency.

Every technology has its specific limitations. Parallelism is just one way to enhance efficiency, and the final decision on whether to use this technology also needs to consider whether it is developer-friendly and whether it can be achieved without sacrificing decentralization, among other factors. The stacking of technologies is not necessarily better; at least for Ethereum, parallelism is not as attractive. From the perspective of improving efficiency alone, adding parallelism is not the optimal solution for Ethereum, whether considering simplicity or Ethereum's current Rollup-centered roadmap.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。