Research Collection about Parallel, Concurrent, and High-Performance Blockchain/Blockchain VMs
39
15 commits
updated Jan 30, 2024
Faster, robust, and high-performanced blockchain systems are the cornerstone of tomorrow.
Contributions from the community are welcome; make sure the material you add is worth reading, at least you have read it yourself.Parallelism and concurrency are two sharp swords that could improve the transaction execution performance of Blockchain and Blockchain-related VMs(i.e., EVM and SVM).
This knowledge base collects information about state-of-the-art research and engineering works about parallel and concurrent blockchain, blockchain VM, and other related systems, with some relevant examples for better understanding.
Parallelism and concurrency are two easily confused terms; although they are both used to improve the efficiency of the execution of the system, they differ in meaning and in the scenarios in which they are used.
Parallelism, typically refers to multiple processes or threads working on different tasks at the same time. For example, ten threads are executing ten different transactions simultaneously. Or think of ten dogs eating from ten food bowls.
Concurrency, typically refers to a thread simultaneously working multiple tasks to increase efficiency. For instance, certain operations, like reading data from disk(i.e., sLoad in EVM), might need to wait for a while in order to be completed. In such a case, the main thread could move ahead and do other duties, like computation. Then, It returns to continuing execution after the disk's data has been read in complete. Again, think about using a bowl to feed ten dogs, and being in the middle of a meal the dog is chewing on a bone, when you could start by letting him out of the bowl for a while and letting the other dogs eat first.
For further reading: Difference between Concurrency and Parallelism
In general, the core challenge of adopting a parallel or concurrent method is the data race problem, read-write conflict, or data hazard problem. All these terms describe the same issue: different threads or operations are trying to read and modify the same data at the same time.
Consider a transfer scenario on Ethereum where Alice and Bob both want to transfer 10 ETH to Carl at the same time. Suppose Carl's initial balance is 100 ETH. After these two transactions are completed, Carl's balance should be 120 ETH. Let's consider a fully concurrent scenario where Alice's and Bob's transactions start executing at the same time. The initial balance of Carl that their transactions read would be 100 ETH (see the error?). Eventually, they will update Carl's balance as 110 ETH.
To resolve a data race issue, there are usually three ways:
So how do we implement these solutions in the blockchain world? Let's dig in!
In the current EVM architecture, the most fine-grained read and write operators are sload and sstore, which read and write data from the state trie, respectively. So the easiest entry point is how to make sure that different threads don't conflict on these two operators. In fact, there is a special kind of transaction in Ethereum that includes a special structure named Access list, which allows transactions carrying storage addresses that it will read and modify. Therefore, this is a good entry point for implementing scheduling-based concurrent methods.
In terms of system implementations, there are three general forms of Parallel/Concurrent EVM.
So, what makes Parallism/concurrency on blockchain different than in the database system?
What do we need?
In the context of database management systems (DBMS), parallelism refers to the capability that a single query can be executed by utilizing multiple CPU and IO resources. The typical technical challenges of parallel query execution include parallel operator implementation, parallel query optimization, load balancing, etc.
On the other hand, concurrency in DBMS refers to the process that executes multiple transactions simultaneously without conflicting with each other.
Research Collection about Parallel, Concurrent, and High-Performance Blockchain/Blockchain VMs
39
15 commits
updated Jan 30, 2024
Faster, robust, and high-performanced blockchain systems are the cornerstone of tomorrow.
Contributions from the community are welcome; make sure the material you add is worth reading, at least you have read it yourself.Parallelism and concurrency are two sharp swords that could improve the transaction execution performance of Blockchain and Blockchain-related VMs(i.e., EVM and SVM).
This knowledge base collects information about state-of-the-art research and engineering works about parallel and concurrent blockchain, blockchain VM, and other related systems, with some relevant examples for better understanding.
Parallelism and concurrency are two easily confused terms; although they are both used to improve the efficiency of the execution of the system, they differ in meaning and in the scenarios in which they are used.
Parallelism, typically refers to multiple processes or threads working on different tasks at the same time. For example, ten threads are executing ten different transactions simultaneously. Or think of ten dogs eating from ten food bowls.
Concurrency, typically refers to a thread simultaneously working multiple tasks to increase efficiency. For instance, certain operations, like reading data from disk(i.e., sLoad in EVM), might need to wait for a while in order to be completed. In such a case, the main thread could move ahead and do other duties, like computation. Then, It returns to continuing execution after the disk's data has been read in complete. Again, think about using a bowl to feed ten dogs, and being in the middle of a meal the dog is chewing on a bone, when you could start by letting him out of the bowl for a while and letting the other dogs eat first.
For further reading: Difference between Concurrency and Parallelism
In general, the core challenge of adopting a parallel or concurrent method is the data race problem, read-write conflict, or data hazard problem. All these terms describe the same issue: different threads or operations are trying to read and modify the same data at the same time.
Consider a transfer scenario on Ethereum where Alice and Bob both want to transfer 10 ETH to Carl at the same time. Suppose Carl's initial balance is 100 ETH. After these two transactions are completed, Carl's balance should be 120 ETH. Let's consider a fully concurrent scenario where Alice's and Bob's transactions start executing at the same time. The initial balance of Carl that their transactions read would be 100 ETH (see the error?). Eventually, they will update Carl's balance as 110 ETH.
To resolve a data race issue, there are usually three ways:
So how do we implement these solutions in the blockchain world? Let's dig in!
In the current EVM architecture, the most fine-grained read and write operators are sload and sstore, which read and write data from the state trie, respectively. So the easiest entry point is how to make sure that different threads don't conflict on these two operators. In fact, there is a special kind of transaction in Ethereum that includes a special structure named Access list, which allows transactions carrying storage addresses that it will read and modify. Therefore, this is a good entry point for implementing scheduling-based concurrent methods.
In terms of system implementations, there are three general forms of Parallel/Concurrent EVM.
So, what makes Parallism/concurrency on blockchain different than in the database system?
What do we need?
In the context of database management systems (DBMS), parallelism refers to the capability that a single query can be executed by utilizing multiple CPU and IO resources. The typical technical challenges of parallel query execution include parallel operator implementation, parallel query optimization, load balancing, etc.
On the other hand, concurrency in DBMS refers to the process that executes multiple transactions simultaneously without conflicting with each other.