本說明書實施例旨在提供一種更有效的並行執行交易的方案，以解決現有技術中的不足。
為實現上述目的，本說明書一個方面提供一種在區塊鏈中並行執行交易的方法，所述方法在區塊鏈中的第一節點執行，所述第一節點中目前透過預設的預定數目的執行體並行執行交易，其中包括第一執行體，所述第一執行體目前在處理第一交易，所述方法由所述第一執行體執行，包括：
在處理第一交易的過程中進行預定操作之後，在共享記憶體中記錄與第一交易對應的第一待處理任務、以及與該第一待處理任務對應的執行信息，以相對於所述第一交易進入等待過程；
對於所述共享記憶體中已經記錄的多個待處理任務，確定其中是否存在等待過程結束的待處理任務，所述多個待處理任務由所述預定數目的執行體記錄；以及
在確定第二待處理任務對應的等待過程結束的情況中，基於與所述第二待處理任務對應的執行信息，繼續執行該第二待處理任務，其中，所述多個待處理任務中包括所述第二待處理任務。
在一個實施例中，所述方法還包括，在確定所述多個待處理任務各自的等待過程都未結束的情況中，從共享記憶體中的第一緩衝區獲取待處理的第二交易，並開始執行所述第二交易。
在一個實施例中，所述共享記憶體中包括第二緩衝區，其中，在處理第一交易的過程中進行預定操作之後，在共享記憶體中記錄與第一交易對應的第一待處理任務、以及與該第一待處理任務對應的執行信息包括，在處理完成第一交易之後，在確定第二交易未提交的情況中，在所述第二緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第二交易根據預定提交順序為所述第一交易的前一個交易。
在一個實施例中，對於所述共享記憶體中已經記錄的多個待處理任務，確定其中是否存在等待過程結束的待處理任務包括，基於共享記憶體中記錄的目前應提交的交易，確定所述第二緩衝區中對應於最小交易編號的待處理任務的等待過程是否結束，以確定所述第二緩衝區中是否存在等待過程結束的待處理任務，其中，所述交易編號對應於交易的提交順序。
在一個實施例中，在確定第二待處理任務對應的等待過程結束的情況中，基於與所述第二待處理任務對應的執行信息，繼續執行該第二待處理任務包括，在確定所述第二緩衝區中的第二待處理任務的等待過程結束的情況中，基於與所述第二待處理任務對應的執行信息，繼續執行對第三交易的提交，其中所述第二待處理任務與所述第三交易相對應。
在一個實施例中，所述共享記憶體中包括第三緩衝區，所述第一交易中包括對第一變數的讀取操作，其中，在處理第一交易的過程中進行預定操作之後，在共享記憶體中記錄與第一交易對應的第一待處理任務、以及與該第一待處理任務對應的執行信息包括，在請求對所述第一變數的讀取之後，在所述第三緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第一待處理任務中包括對所述第一變數的記錄。
在一個實施例中，所述第三緩衝區中包括所述第二待處理任務，所述第二待處理任務與第二交易中對第二變數的讀取操作相對應，對於所述共享記憶體中已經記錄的多個待處理任務，確定其中是否存在等待過程結束的待處理任包括，確定所述第二變數的變數值是否被返回，在確定所述第二變數的變數值被返回的情況中，確定該第二待處理任務的等待過程結束。
在一個實施例中，對於所述共享記憶體中已經記錄的多個待處理任務，確定其中是否存在等待過程結束的待處理任務包括，對於所述第三緩衝區中已經記錄的多個待處理任務，基於各個待處理任務對應的交易編號從小至大的順序，依次確定各個待處理任務的等待過程是否結束，其中，所述第二待處理任務為首次確定的等待過程結束的待處理任務，其中，所述交易編號對應於交易的預定提交順序。
在一個實施例中，確定所述第二變數的變數值是否被返回包括，基於在共享記憶體中的預定位址是否儲存有第二變數的變數值，確定所述第二變數的變數值是否被返回，其中，所述預定位址與所述第二交易相對應。
在一個實施例中，在確定第二待處理任務對應的等待過程結束的情況中，基於與所述第二待處理任務對應的執行信息，繼續執行該第二待處理任務包括，在確定所述第三緩衝區中存在等待過程結束的第二待處理任務的情況中，基於與所述第二待處理任務對應的執行信息和所述第二變數的變數值，繼續執行所述第二交易。
在一個實施例中，所述共享記憶體中包括第四緩衝區，所述第一交易中包括對第一變數的讀取操作，其中，在處理第一交易的過程中進行預定操作之後，在共享記憶體中記錄與第一交易對應的第一待處理任務、以及與該第一待處理任務對應的執行信息包括，在執行到所述讀取操作的碼之後，確定提交順序在第一交易之前、且未提交的各個交易是否為已執行了對第一變數的寫入操作的衝突交易，所述各個交易中包括第二交易，在確定所述第二交易為距離第一交易最近的衝突交易的情況中，在第四緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第一待處理任務中包括對第二交易的記錄。
在一個實施例中，對於所述共享記憶體中已經記錄的多個待處理任務，確定其中是否存在等待過程結束的待處理任務包括，基於共享記憶體中記錄的目前應提交的交易，確定在所述第四緩衝區中記錄的多個待處理任務中是否存在等待過程結束的待處理任務。
在一個實施例中，所述共享記憶體中包括第五緩衝區，所述第一交易中包括對第一變數的讀取操作，其中，在處理第一交易的過程中進行預定操作之後，在共享記憶體中記錄與第一交易對應的第一待處理任務、以及與該第一待處理任務對應的執行信息包括，在執行到所述讀取操作的碼之後，推斷提交順序在第一交易之前、且未提交的各個交易是否為將要對第一變數進行寫入操作的衝突交易，所述各個交易中包括第二交易，在推斷所述第二交易為距離第一交易最近的衝突交易的情況中，在所述第五緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第一待處理任務中包括對第二交易的記錄。
在一個實施例中，所述共享記憶體中包括至少一個緩衝區，所述至少一個緩衝區與至少一種待處理任務分別對應，其中，對於所述共享記憶體中已經記錄的多個待處理任務，確定其中是否存在等待過程結束的待處理任務包括，基於所述至少一個緩衝區的預定順序，確定各個緩衝區中是否存在等待過程結束的待處理任務。
本說明書另一方面提供一種在區塊鏈中並行執行交易的裝置，所述裝置部署在區塊鏈中的第一節點中的第一執行體中，所述第一節點中目前透過預設的預定數目的執行體並行執行交易，其中包括第一執行體，所述第一執行體目前在處理所述第一交易，所述裝置，包括：
記錄單元，配置為，在處理第一交易的過程中進行預定操作之後，在共享記憶體中記錄與第一交易對應的第一待處理任務、以及與該第一待處理任務對應的執行信息，以相對於所述第一交易進入等待過程；
確定單元，配置為，對於所述共享記憶體中已經記錄的多個待處理任務，確定其中是否存在等待過程結束的待處理任務，所述多個待處理任務由所述預定數目的執行體記錄；以及
繼續執行單元，配置為，在確定第二待處理任務對應的等待過程結束的情況中，基於與所述第二待處理任務對應的執行信息，繼續執行該第二待處理任務，其中，所述多個待處理任務中包括所述第二待處理任務。
在一個實施例中，所述裝置還包括，交易執行單元，配置為，在確定所述多個待處理任務各自的等待過程都未結束的情況中，從共享記憶體中的第一緩衝區獲取待處理的第二交易，並開始執行所述第二交易。
在一個實施例中，所述共享記憶體中包括第二緩衝區，其中，所述記錄單元還配置為，在處理完成第一交易之後，在確定第二交易未提交的情況中，在所述第二緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第二交易根據預定提交順序為所述第一交易的前一個交易。
在一個實施例中，所述確定單元還配置為，基於共享記憶體中記錄的目前應提交的交易，確定所述第二緩衝區中對應於最小交易編號的待處理任務的等待過程是否結束，以確定所述第二緩衝區中是否存在等待過程結束的待處理任務，其中，所述交易編號對應於交易的提交順序。
在一個實施例中，所述繼續執行單元還配置為，在確定所述第二緩衝區中的第二待處理任務的等待過程結束的情況中，基於與所述第二待處理任務對應的執行信息，繼續執行對第三交易的提交，其中所述第二待處理任務與所述第三交易相對應。
在一個實施例中，所述共享記憶體中包括第三緩衝區，所述第一交易中包括對第一變數的讀取操作，其中，所述記錄單元還配置為，在請求對所述第一變數的讀取之後，在所述第三緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第一待處理任務中包括對所述第一變數的記錄。
在一個實施例中，所述第三緩衝區中包括所述第二待處理任務，所述第二待處理任務與第二交易中對第二變數的讀取操作相對應，所述確定單元還配置為，確定所述第二變數的變數值是否被返回，在確定所述第二變數的變數值被返回的情況中，確定該第二待處理任務的等待過程結束。
在一個實施例中，所述確定單元還配置為，對於所述第三緩衝區中已經記錄的多個待處理任務，基於各個待處理任務對應的交易編號從小至大的順序，依次確定各個待處理任務的等待過程是否結束，其中，所述第二待處理任務為首次確定的等待過程結束的待處理任務，其中，所述交易編號對應於交易的預定提交順序。
在一個實施例中，所述確定單元還配置為，基於在共享記憶體中的預定位址是否儲存有第二變數的變數值，確定所述第二變數的變數值是否被返回，其中，所述預定位址與所述第二交易相對應。
在一個實施例中，所述繼續執行單元還配置為，在確定所述第三緩衝區中存在等待過程結束的第二待處理任務的情況中，基於與所述第二待處理任務對應的執行信息和所述第二變數的變數值，繼續執行所述第二交易。
在一個實施例中，所述共享記憶體中包括第四緩衝區，其中，所述記錄單元還配置為，在執行到所述讀取操作的碼之後，確定提交順序在第一交易之前、且未提交的各個交易是否為已執行了對第一變數的寫入操作的衝突交易，所述各個交易中包括第二交易，在確定所述第二交易為距離第一交易最近的衝突交易的情況中，在第四緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第一待處理任務中包括對第二交易的記錄。
在一個實施例中，所述確定單元還配置為，基於共享記憶體中記錄的目前應提交的交易，確定在所述第四緩衝區中記錄的多個待處理任務中是否存在等待過程結束的待處理任務。
在一個實施例中，所述共享記憶體中包括第五緩衝區，所述第一交易中包括對第一變數的讀取操作，其中，所述記錄單元還配置為，在執行到所述讀取操作的碼之後，推斷提交順序在第一交易之前、且未提交的各個交易是否為將要對第一變數進行寫入操作的衝突交易，所述各個交易中包括第二交易，在推斷所述第二交易為距離第一交易最近的衝突交易的情況中，在所述第五緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第一待處理任務中包括對第二交易的記錄。
在一個實施例中，所述共享記憶體中包括至少一個緩衝區，所述至少一個緩衝區與至少一種待處理任務分別對應，其中，所述確定單元還配置為，基於所述至少一個緩衝區的預定順序，確定各個緩衝區中是否存在等待過程結束的待處理任務。
本說明書另一方面提供一種電腦可讀儲存媒體，其上儲存有電腦程式，當所述電腦程式在電腦中執行時，令電腦執上述任一項方法。
本說明書另一方面提供一種計算設備，包括記憶體和處理器，其特徵在於，所述記憶體中儲存有可執行碼，所述處理器執行所述可執行碼時，實現上述任一項方法。
透過根據本說明書實施例的並行執行交易的方案，在執行體執行交易過程中需要等待時記錄對該交易的處理信息，並從共享記憶體中獲取其它待處理任務或其它待處理交易進行處理，從而減少了執行體的等待時間，加快了交易並行執行的總體速度。The embodiments of this specification aim to provide a more effective solution for executing transactions in parallel to solve the deficiencies in the prior art.
In order to achieve the above objective, one aspect of this specification provides a method for executing transactions in parallel in the blockchain. The method is executed on the first node in the blockchain. The execution body executes transactions in parallel, including a first execution body, and the first execution body is currently processing a first transaction. The method is executed by the first execution body and includes:
After a predetermined operation is performed in the process of processing the first transaction, the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task are recorded in the shared memory so as to be relative to the first to-be-processed task. A transaction enters the waiting process;
For the multiple pending tasks that have been recorded in the shared memory, determine whether there are pending tasks waiting for the end of the process, and the multiple pending tasks are recorded by the predetermined number of executives; and
In the case where it is determined that the waiting process corresponding to the second to-be-processed task ends, the second to-be-processed task is continued to be executed based on the execution information corresponding to the second to-be-processed task, wherein the multiple to-be-processed tasks include The second task to be processed.
In an embodiment, the method further includes, in a case where it is determined that the waiting processes of the multiple to-be-processed tasks are not finished, obtaining the second transaction to be processed from the first buffer in the shared memory, And start to execute the second transaction.
In one embodiment, the shared memory includes a second buffer area, wherein, after a predetermined operation is performed in the process of processing the first transaction, the first to-be-processed task corresponding to the first transaction is recorded in the shared memory , And the execution information corresponding to the first to-be-processed task includes, after processing the first transaction, in the case where it is determined that the second transaction has not been submitted, recording the first transaction corresponding to the first transaction in the second buffer A pending task, wherein the second transaction is the previous transaction of the first transaction according to a predetermined submission order.
In one embodiment, for the multiple pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process includes: determining all pending tasks recorded in the shared memory based on the current transaction that should be submitted Whether the waiting process of the task to be processed corresponding to the smallest transaction number in the second buffer is over, to determine whether there is a task waiting for the end of the process in the second buffer, where the transaction number corresponds to the transaction number The order of submission.
In one embodiment, in a case where it is determined that the waiting process corresponding to the second to-be-processed task is over, based on the execution information corresponding to the second to-be-processed task, continuing to execute the second to-be-processed task includes: In the case where the waiting process of the second to-be-processed task in the second buffer is over, continue to perform the submission of the third transaction based on the execution information corresponding to the second to-be-processed task, wherein the second to-be-processed task Corresponds to the third transaction.
In one embodiment, the shared memory includes a third buffer, the first transaction includes a read operation of the first variable, wherein, after a predetermined operation is performed in the process of processing the first transaction, Recording in the shared memory the first task to be processed corresponding to the first transaction and the execution information corresponding to the first task to be processed includes, after requesting to read the first variable, in the third buffer A first task to be processed corresponding to the first transaction is recorded in the area, where the first task to be processed includes a record of the first variable.
In one embodiment, the third buffer includes the second to-be-processed task, and the second to-be-processed task corresponds to the read operation of the second variable in the second transaction, and the shared memory For multiple pending tasks that have been recorded in the body, determining whether there are any pending tasks waiting for the end of the process includes determining whether the variable value of the second variable is returned, and determining whether the variable value of the second variable is returned In this case, it is determined that the waiting process of the second task to be processed ends.
In one embodiment, for the multiple pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process includes: for the multiple pending tasks that have been recorded in the third buffer Task, based on the order of the transaction number corresponding to each to-be-processed task from small to large, determine in turn whether the waiting process of each to-be-processed task is over, wherein the second to-be-processed task is the first-determined to-be-processed task whose waiting process is over Wherein, the transaction number corresponds to the predetermined submission sequence of the transaction.
In one embodiment, determining whether the variable value of the second variable is returned includes determining whether the variable value of the second variable is stored based on whether the variable value of the second variable is stored at a predetermined address in the shared memory Is returned, wherein the predetermined address corresponds to the second transaction.
In one embodiment, in a case where it is determined that the waiting process corresponding to the second to-be-processed task is over, based on the execution information corresponding to the second to-be-processed task, continuing to execute the second to-be-processed task includes: In the case that there is a second pending task waiting for the process to end in the third buffer, the second transaction is continued to be executed based on the execution information corresponding to the second pending task and the variable value of the second variable.
In one embodiment, the shared memory includes a fourth buffer, and the first transaction includes a read operation of the first variable, wherein, after a predetermined operation is performed in the process of processing the first transaction, the Recording in the shared memory the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task includes, after the code of the read operation is executed, determining that the order of submission is in the first transaction Whether each of the previous and uncommitted transactions is a conflict transaction that has performed the write operation to the first variable, the each transaction includes a second transaction, and it is determined that the second transaction is the closest conflict to the first transaction In the case of a transaction, the first to-be-processed task corresponding to the first transaction is recorded in the fourth buffer zone, wherein the first to-be-processed task includes a record of the second transaction.
In one embodiment, for the plurality of pending tasks that have been recorded in the shared memory, determining whether there are pending tasks waiting for the end of the process includes: determining the current transaction that should be submitted based on the transaction recorded in the shared memory Whether there is a to-be-processed task that waits for the end of the process among the multiple to-be-processed tasks recorded in the fourth buffer.
In one embodiment, the shared memory includes a fifth buffer, and the first transaction includes a read operation of the first variable, wherein, after a predetermined operation is performed in the process of processing the first transaction, the The first task to be processed corresponding to the first transaction and the execution information corresponding to the first task to be processed in the shared memory include: after the code of the read operation is executed, it is inferred that the order of submission is in the first transaction Whether each of the previous and uncommitted transactions is a conflicting transaction that will write the first variable, the each transaction includes a second transaction, and it is inferred that the second transaction is the conflicting transaction closest to the first transaction In this case, the first to-be-processed task corresponding to the first transaction is recorded in the fifth buffer, wherein the first to-be-processed task includes a record of the second transaction.
In an embodiment, the shared memory includes at least one buffer, and the at least one buffer corresponds to at least one task to be processed, wherein, for multiple tasks to be processed that have been recorded in the shared memory , Determining whether there is a pending task waiting for the end of the process includes determining whether there is a pending task waiting for the end of the process in each buffer based on a predetermined sequence of the at least one buffer.
Another aspect of this specification provides a device for executing transactions in parallel in a blockchain. The device is deployed in a first executable in a first node in the blockchain. The first node currently uses a preset A predetermined number of executive bodies execute transactions in parallel, including a first executive body, which is currently processing the first transaction, and the device includes:
The recording unit is configured to record the first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in the shared memory after performing a predetermined operation in the process of processing the first transaction, To enter the waiting process relative to the first transaction;
The determining unit is configured to, for the multiple pending tasks that have been recorded in the shared memory, determine whether there are pending tasks waiting for the end of the process, and the multiple pending tasks are recorded by the predetermined number of executives ;as well as
The continuing execution unit is configured to continue to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task in a case where it is determined that the waiting process corresponding to the second to-be-processed task is over, wherein the The multiple to-be-processed tasks include the second to-be-processed task.
In an embodiment, the device further includes a transaction execution unit configured to obtain from the first buffer in the shared memory when it is determined that the waiting processes of the multiple pending tasks are not finished. The second transaction to be processed, and the execution of the second transaction is started.
In one embodiment, the shared memory includes a second buffer area, wherein the recording unit is further configured to, after processing the first transaction, in a case where it is determined that the second transaction has not been submitted, in the The first to-be-processed task corresponding to the first transaction is recorded in the second buffer zone, wherein the second transaction is the previous transaction of the first transaction according to a predetermined submission order.
In an embodiment, the determining unit is further configured to determine whether the waiting process of the task to be processed corresponding to the smallest transaction number in the second buffer is over based on the transaction that should be submitted currently recorded in the shared memory, To determine whether there is a pending task waiting for the end of the process in the second buffer zone, wherein the transaction number corresponds to the submission sequence of the transaction.
In an embodiment, the continuing execution unit is further configured to, in a case where it is determined that the waiting process of the second to-be-processed task in the second buffer is ended, based on the execution corresponding to the second to-be-processed task Information, continue to perform the submission of the third transaction, wherein the second pending task corresponds to the third transaction.
In an embodiment, the shared memory includes a third buffer, and the first transaction includes a read operation of the first variable, wherein the recording unit is further configured to, upon request, to the first variable After a variable is read, the first to-be-processed task corresponding to the first transaction is recorded in the third buffer, where the first to-be-processed task includes a record of the first variable.
In an embodiment, the third buffer includes the second to-be-processed task, the second to-be-processed task corresponds to a read operation of the second variable in the second transaction, and the determining unit further It is configured to determine whether the variable value of the second variable is returned, and in a case where it is determined that the variable value of the second variable is returned, it is determined that the waiting process of the second to-be-processed task ends.
In one embodiment, the determining unit is further configured to, for a plurality of pending tasks that have been recorded in the third buffer, determine each pending task in sequence based on the order of the transaction number corresponding to each pending task from small to large. Whether the waiting process of the processing task ends, wherein the second task to be processed is the first determined task to be processed after the waiting process ends, and the transaction number corresponds to the predetermined submission sequence of the transaction.
In one embodiment, the determining unit is further configured to determine whether the variable value of the second variable is returned based on whether the variable value of the second variable is stored at a predetermined address in the shared memory, wherein The predetermined address corresponds to the second transaction.
In an embodiment, the continuing execution unit is further configured to, in a case where it is determined that there is a second to-be-processed task waiting for the end of the process in the third buffer, based on the execution corresponding to the second to-be-processed task Information and the variable value of the second variable, continue to execute the second transaction.
In one embodiment, the shared memory includes a fourth buffer, wherein the recording unit is further configured to, after executing the code of the read operation, determine that the submission sequence is before the first transaction, and Whether each transaction that has not been submitted is a conflict transaction in which a write operation to the first variable has been performed, and each transaction includes a second transaction, in the case of determining that the second transaction is the closest conflict transaction to the first transaction In the fourth buffer, the first task to be processed corresponding to the first transaction is recorded, wherein the first task to be processed includes the record of the second transaction.
In an embodiment, the determining unit is further configured to determine whether there is a waiting process to be completed among the multiple pending tasks recorded in the fourth buffer based on the transaction that should be submitted currently recorded in the shared memory. Pending tasks.
In one embodiment, the shared memory includes a fifth buffer, and the first transaction includes a read operation of the first variable, wherein the recording unit is further configured to: After fetching the code of the operation, it is inferred whether each transaction whose submission sequence is before the first transaction and is not submitted is a conflict transaction that will write the first variable, and each transaction includes the second transaction. In the case that the second transaction is the closest conflict transaction to the first transaction, the first pending task corresponding to the first transaction is recorded in the fifth buffer, wherein the first pending task includes the 2. Records of transactions.
In an embodiment, the shared memory includes at least one buffer, and the at least one buffer corresponds to at least one task to be processed, wherein the determining unit is further configured to, based on the at least one buffer To determine whether there are pending tasks waiting for the end of the process in each buffer.
Another aspect of this specification provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is made to perform any of the above methods.
Another aspect of this specification provides a computing device, including a memory and a processor, characterized in that executable code is stored in the memory, and when the processor executes the executable code, any one of the above methods is implemented .
Through the parallel execution transaction scheme according to the embodiment of this specification, the processing information of the transaction is recorded when the execution body needs to wait during the execution of the transaction, and other pending tasks or other pending transactions are obtained from the shared memory for processing, This reduces the waiting time of the execution body and speeds up the overall speed of parallel execution of transactions.
下面將結合附圖描述本說明書實施例。
圖1示出根據本說明書實施例的區塊鏈系統示意圖。如圖1所示，所述系統中包括構成區塊鏈的多個節點(圖中示意示出6個節點)，這些節點兩兩相連，其中例如包括節點11、節點12和節點13。如本領域技術人員所知，在區塊鏈中，一些節點會收集區塊鏈中的多個交易放入交易池中並競爭記帳權。例如圖中的節點11透過獲取記帳權而成為記帳節點。節點11在成為記帳節點之後會執行其交易池中的多個交易，並將該多個交易打包成區塊發送給其它節點，例如發送給節點12。節點12將會對該區塊進行驗證，並同樣地執行該區塊中的多個交易。在預定數目個節點對該區塊進行驗證之後，也即對該區塊達到了共識，區塊鏈中的其它節點(例如節點13)將不需要繼續對該區塊進行驗證，而是直接對該區塊中的交易進行執行，以更新本地的相關資料。
圖2示出在區塊鏈中各個節點透過多個執行緒並行執行交易的示意圖。可以理解，所述執行緒也可以替換為處理、共常式等執行體。如圖2中所示，在每個節點中，通常，CPU的數目是有限的，預設的執行緒的數目也是固定的，例如，假設該節點的CPU數為4個，執行緒池中預設的執行緒數目為6個，從而6個執行緒競爭搶占CPU，並且只有在搶占到CPU之後，才能開始執行任務池中的任務。
在多個執行緒並行執行多個交易的過程中，所述多個交易中可能涉及到對多個變數的計算，在兩個交易中不涉及相同的變數的情況中，其執行順序並不會影響最終的計算結果，而在兩個交易中涉及相同的變數的情況中，其執行順序將會影響最終的計算結果。在本說明書實施例中，為了保證各個節點對多個交易的執行結果是相同的，在並行執行多個交易的同時，考慮交易之間對存取變數的衝突，從而使得平行執行的執行緒中的一些執行緒需要經過等待過程。或者在等待返回存取儲存時需要進行等待。
如圖2中所示，該圖中包括第一節點的共享記憶體，該共享記憶體中例如包括用於指示待處理交易的緩衝區1，該共享記憶體是相對於全部執行緒可讀寫的。例如，第一緩衝區中目前記錄了10個待處理的交易1、2、…10，其中，圖中數字1、2、…、10對應的位元框中初始應都為1，表示，其都是待處理的交易，其中，交易1～10的編號對應於各個交易的提交順序。在開始並行執行交易之後，例如，執行緒1～4分別搶占到CPU1～4，從而，執行緒1～4可分別從第一緩衝區中獲取一個任務進行處理，例如，執行緒1～4分別開始處理交易1～4，執行緒1～4在開始處理交易1～4之後，分別將第一緩衝區中交易1～4對應的位元分別修改為0，以表示這些交易已經開始執行。可以理解，雖然圖中示意示出，執行緒1搶占到CPU1，並執行交易1，執行緒2搶占到CPU2，並執行交易2等等，可以理解，圖中所示內容僅是為了示意說明，執行緒的編號、CPU的編號和交易的編號並不是相互對應的，例如，執行緒1有可能搶占到CPU2，執行交易3等等。
圖2中還示出了用於記錄待處理任務的多個緩衝區，緩衝區2～5，其中，每個緩衝區與一種等待過程相對應。例如，緩衝區2與執行完交易等待提交的等待過程相對應，緩衝區3與請求讀取以等待返回變數值的等待過程相對應，緩衝區4與在讀取前基於變數寫入記錄等待在前交易提交的等待過程相對應，緩衝區5與在讀取前基於交易衝突機率等待在前交易提交或寫入的等待過程相對應。在本說明書實施例中，為了並行執行交易，執行交易的過程包括處理交易的過程和提交交易的過程，其中，所述處理交易的過程是將處理交易的結果儲存到與該交易對應的緩衝區中，所述提交交易的過程是將最終的處理結果儲存到各個交易共用的共享記憶體中。例如，當執行緒3處理完交易3之後，為了保證執行各個交易的最終結果一致，需要保證各個交易按照其編號順序先後提交，因此，交易3需要等待前面的交易2提交之後再提交。在該情況中，執行緒3在緩衝區2中與交易3對應的位置進行記錄，例如將初始的0改為1，然後，執行緒3到緩衝區中去獲取新的任務。例如，執行緒3可首先檢查緩衝區2中有沒有等待過程結束的任務。圖2中的共享記憶體中還記錄了目前交易窗口，該目前交易窗口例如可由提交完交易的執行緒進行維護。例如，執行緒1在提交了交易1之後，可將該交易窗口中的首交易修改為2。從而交易窗口在待提交的多個交易中向後移動一位，當執行緒根據窗口首位而開始執行一個新交易(例如交易7)時，可將交易窗口中的末交易由6更新為7。在此時，例如，執行緒3在檢查緩衝區2之後，可首先基於所述窗口確定交易2是否為目前應提交的交易。在緩衝區2中沒有等待過程結束的任務的情況中，可以檢查緩衝區3中有沒有等待過程結束的任務，等等。在緩衝區2～5中都沒有等待過程結束的任務的情況中，則可以從緩衝區1中獲取待處理的交易，例如交易6。執行緒3當在執行交易6的過程中也遇到等待過程時，也將到緩衝區2～5中的相應的一個中記錄下相應的待處理任務，例如，如圖中右側虛線箭頭所示，執行緒3在緩衝區4中記錄與交易6對應的待處理任務。然後，類似地，執行緒3首先在緩衝區2～5確定有沒有等待過程結束的待處理任務。
可以理解，上文對圖2的描述只是示意性地，而不是用於限制本說明書實施例的範圍。例如，所述緩衝區1～5的具體形式不一定為圖中所示形式，只要其能記錄下相應的信息即可。下文將詳細描述根據本說明書實施例的並行執行交易的過程。
圖3示出根據本說明書一個實施例的一種在區塊鏈中並行執行交易的方法流程圖，所述方法在區塊鏈中的第一節點執行，所述第一節點中預設有第一執行體，所述第一執行體目前在處理第一交易，所述方法由所述第一執行體執行，包括：
步驟S302，在處理第一交易的過程中進行預定操作之後，在共享記憶體中記錄與第一交易對應的第一待處理任務、以及與該第一待處理任務對應的執行信息，以相對於所述第一交易進入等待過程；
步驟S304，對於所述共享記憶體中已經記錄的多個待處理任務，確定其中是否存在等待過程結束的待處理任務；以及
步驟S306，在確定第二待處理任務對應的等待過程結束的情況中，基於與所述第二待處理任務對應的執行信息，繼續執行該第二待處理任務，其中，所述多個待處理任務中包括所述第二待處理任務。
首先，在步驟S302，在處理第一交易的過程中進行預定操作之後，在共享記憶體中記錄與第一交易對應的第一待處理任務、以及與該第一待處理任務對應的執行信息，以相對於所述第一交易進入等待過程。
如上文中參考圖2所述，所述第一執行體例如可以為執行緒、處理、共常式等執行主體，所述共享記憶體相對於用於並行執行交易的多個執行體是共享的。下文中將以執行緒為例進行說明。
在節點中並行執行交易的過程中，對於其中一個正在執行的交易，可能會包括多個等待過程，所述等待過程可能是由於不同的原因引起的。
在一個實施例中，如上文中參考圖2中所述，所述多個並行執行的交易已經預設了預定的提交順序，例如圖2中的交易1～10必須按照其編號的從小到大的順序進行先後提交，以保證各個節點對該多個交易的執行結果是相同的。這裡，在節點中，執行緒在執行交易時，將處理結果先保存到僅與該交易對應的緩衝區中，而在提交之後，才將該執行結果保存到各個交易共用的共享記憶體中。例如，在處理第一交易的過程中，需要對第一變數進行寫入操作，則在僅與第一交易對應的緩衝區中先保存該寫入操作之後的第一變數的值，該值僅在處理該第一交易時可以使用，在處理其它交易時並不會對該值進行讀寫。而在提交第一交易之後，第一交易的值被存到共享記憶體中，其它交易也可以讀取到該值，或者透過提交對該值進行修改。
由於各個交易具有預定的提交順序，因此，如圖2中所示，例如所述第一交易為圖2中的交易6，則第一執行體為圖中的執行緒3。如果執行緒3在處理完交易6之後，交易6之前的交易還未提交，此時，執行緒3需要等待交易5提交完成之後才能進行對交易6的提交。這裡，執行緒3可基於共享記憶體中預設的交易窗口參數確定交易5是否提交。透過該交易窗口控制可同時並行執行的交易的最大總數，該交易窗口的兩邊分別是目前並行執行的編號最小的交易和編號最大的交易，例如圖2中的1和6表示目前並行執行的交易為交易1～6。從而，透過確定交易5是否為交易窗口中的最小交易，從而確定交易5目前是否應提交。在該情況中，執行緒3可如圖2中所示，將緩衝區2中的與交易6對應的位修改為1，以添加一個與交易6對應的待處理任務，該待處理任務只有等到交易5提交之後才可以繼續執行，同時，可將與該待處理任務對應的執行信息，也即交易6的目前處理信息儲存到該共享記憶體中的例如與各個交易分別對應的執行信息緩衝區中。
在一個實施例中，交易6中包括對變數k1的讀取操作，執行緒3在開始執行該讀取操作的碼之後，向用於讀取變數的硬體或執行緒發出對變數k1的讀取請求，之後在圖2中所示的緩衝區3中的與交易6對應的位元組中記錄“k1”，以添加一個與交易6對應的待處理任務，該待處理任務在等到變數k1的值返回之後才繼續執行。
在一個實施例中，交易6中包括對變數k1的讀取操作，執行緒3在開始執行該讀取操作的碼之後，查詢共享記憶體中的寫入緩衝區，該寫入緩衝區中記錄了目前對各個交易的處理過程中對各個變數(包括變數k1)的寫入情況。例如，寫入緩衝區中僅記錄了交易4對變數k1進行了寫入，未記錄交易5對變數k1的寫入。由於，基於該記錄，交易4在提交之後將改變共享記憶體中的變數表中的k1的值，因此，交易6需要在等待交易4提交之後再讀取該變數k1的值，否則將讀取錯誤的k1的值。執行緒3在進行該對寫入緩衝區的檢查之後，在圖2中的緩衝區3中的與交易6對應的位元組中記錄“4”，以添加一個與交易6對應的待處理任務，所述“4”與交易4相對應，表示該待處理任務在等到交易4提交之後才可以繼續執行。
在一個實施例中，交易6中包括對變數k1的讀取操作。執行緒3在開始執行該讀取操作的碼之後，推斷正在並行執行的多個交易中提交順序在交易6之前的各個交易(例如圖2中的交易1～5)是否將要對變數k1進行寫入操作。在一種方法中，可預先基於該節點中的交易執行歷史，確定各個變數的交易衝突機率，當變數k1的交易衝突機率大於預定臨限值時，則可推斷交易1～5都將要對變數k1進行寫入操作，從而，需要等交易5提交之後，再進行交易6中的讀取操作，如果交易5在處理過程中將對k1的寫入值寫入共享記憶體中與交易5對應的緩衝區(該緩衝區不是與各個交易對應的變數表)中，則可等交易5執行完對k1的寫入後，進行對k1的讀取。在一種方法中，執行緒3可基於交易6前面各個交易的交易資料，確定交易6與前面各個交易的衝突機率，並基於該衝突機率，推斷所述各個交易是否將要對k1進行寫入操作，從而確定是否等待該交易的提交或寫入。例如，在確定交易4對k1的寫入機率大於等於預定臨限值、且交易5對k1的寫入機率小於預定臨限值的情況中，執行緒3在圖2中的緩衝區5中與交易6對應的位元組中記錄“4”，以記錄一個與交易6對應的待執行任務，該待執行任務只有等到交易4提交或寫入之後才可以繼續執行。
上文雖然列舉了四種等待情況，然而，本說明書實施例中的等待情況不限於上述四種情況，而是可以為任意由預定操作觸發的等待情況。
在步驟S304，對於所述共享記憶體中已經記錄的多個待處理任務，確定其中是否存在等待過程結束的待處理任務。
如上文中所述，所述共享記憶體中包括緩衝區2～5，其中分別記錄了不同類型的待處理任務。例如，執行緒3在透過上述步驟S302在共享記憶體中存入與交易6對應的第一待處理任務之後，執行緒3以預定順序檢查共享記憶體中的緩衝區2～5，以用於獲取其中的等待過程結束的待處理任務。可以理解，在圖2中，所述緩衝區2～5中的待處理任務可以是由執行緒1～4中任一執行緒記錄的待處理任務。
例如，首先，執行緒3可首先檢查緩衝區2。如上文所述，緩衝區2中記錄的各個待處理任務與處理完成等待提交的交易相對應。例如，如圖2所示，在緩衝區2中，可確定對應位為1的最小交易為交易2，執行緒3可基於共享記憶體中的交易窗口確定目前應提交的交易是否為交易2，如果目前應提交的交易為交易2，則表示與交易2對應的該待處理任務等待過程結束，執行緒3可從共享記憶體中的用於儲存交易執行信息的緩衝區中獲取與交易2對應的執行信息，並基於該執行信息繼續執行交易2，即進行對交易2的提交。
在執行緒3在緩衝區2中沒有發現等待過程結束的待處理任務的情況中，執行緒3例如可檢查緩衝區3。如上文所述，緩衝區3中記錄的各個待處理任務都在等待相應變數值的返回。例如，緩衝區3中的與交易2對應的位元組中記錄有“k2”，則表示交易2在等待變數k2的值的返回。執行緒3可從與交易2對應的共享記憶體中的預定位址中確定是否已寫入k2的值，在k2的值被寫入的情況中，則表示與交易2對應的該待處理任務的等待過程結束，其中，所述預定位址與所述交易2相對應。其中，該k2的值可由執行讀取操作的其它執行緒在該位址寫入。在確定k2的值未被寫入的情況中，可對交易2之後的待處理任務確定等待過程是否結束。例如，交易3對應的位元組中記錄了“k1”，則可在與交易3對應的預定位址確定是否已寫入k1的值。
在執行緒3在緩衝區2和3中都沒有發現等待過程結束的待處理任務的情況中，執行緒3例如可檢查緩衝區4。如上文所述，緩衝區4中記錄的待處理任務對應於基於寫入情況等待其它交易提交以進行讀取操作的交易。與檢查緩衝區2類似地，執行緒3可基於共享記憶體中的交易窗口，確定例如交易2等待的交易1是否提交，在確定交易1提交的情況中，則與交易2對應的待處理任務的等待過程結束。在確定交易1未提交的情況中，執行緒3可以確定對應於交易2之後的交易的待處理任務的等待過程是否結束，例如可確定交易3對應的等待過程是否結束。
在執行緒3在緩衝區2～4都沒有發現等待過程結束的待處理任務的情況中，執行緒3例如可檢查緩衝區5。如上文所述，緩衝區5中記錄的待處理任務對應於基於衝突機率等待其它交易提交或寫入以進行讀取操作的交易。執行緒3可類似地確定交易2等待的交易1是否提交，或者可基於交易1在處理過程中在共享記憶體中寫入的變數值，確定與交易2對應的待處理任務的等待過程是否結束。
可以理解，上述共享記憶體中包括的緩衝區2～5僅僅是示意性地，而不是限制性的，上述檢查緩衝區的順序僅是示意性地，而不是限制性，在具體實施中，可根據場景的需要設置緩衝區、以及檢查緩衝區的順序。
在一個實施例中，在緩衝區2～5中都未檢查到等待過程結束的待處理任務的情況中，執行緒3可檢查圖2中所示的共享記憶體中的緩衝區1，該緩衝區1中記錄了待處理的交易，從而，執行緒3可以從該緩衝區1中獲取編號最小的待處理交易(例如交易6)，並開始執行該交易。
在步驟S306，在確定所述共享記憶體中存在等待過程結束的第二待處理任務的情況中，基於與所述第二待處理任務對應的執行信息，繼續執行該第二待處理任務。
在一個實施例中，執行緒3在緩衝區2中獲取等待過程結束的第二待處理任務，則執行緒3基於對應的執行信息，繼續執行對該第二待處理任務對應的交易的提交。執行緒3在確定該第二待處理任務的等待過程結束之後，將緩衝區中相應的第二待處理任務去除，例如將緩衝區2中的第二待處理任務對應的“1”修改為0。
在一個實施例中，執行緒3在緩衝區3中獲取第二待處理任務，則執行緒3基於相應的執行信息和相應的變數的值，繼續執行相應的交易中讀取操作後面的操作。
在一個實施例中，執行緒3在緩衝區4中獲取第二待處理任務，則執行緒3基於相應的執行信息，繼續執行相應的交易中的相應讀取操作。
在一個實施例中，執行緒3在緩衝區5中獲取第二待處理任務，則執行緒3基於相應的執行信息，繼續執行相應的交易中的相應讀取操作。
圖4示出根據本說明書一個實施例的本說明書另一方面提供一種在區塊鏈中並行執行交易的裝置400，所述裝置部署在區塊鏈中的第一節點中的第一執行體中，所述第一節點中目前透過預設的預定數目的執行體並行執行交易，其中包括第一執行體，所述第一執行體目前在處理第一交易，所述裝置，包括：
記錄單元41，配置為，在處理第一交易的過程中進行預定操作之後，在共享記憶體中記錄與第一交易對應的第一待處理任務、以及與該第一待處理任務對應的執行信息，以相對於所述第一交易進入等待過程；
確定單元42，配置為，對於所述共享記憶體中已經記錄的多個待處理任務，確定其中是否存在等待過程結束的待處理任務，所述多個待處理任務由所述預定數目的執行體記錄；以及
繼續執行單元43，配置為，在確定第二待處理任務對應的等待過程結束的情況中，基於與所述第二待處理任務對應的執行信息，繼續執行該第二待處理任務，其中，所述多個待處理任務中包括所述第二待處理任務。
在一個實施例中，所述裝置還包括，交易執行單元44，配置為，在確定所述多個待處理任務各自的等待過程都未結束的情況中，從共享記憶體中的第一緩衝區獲取待處理的第二交易，並開始執行所述第二交易。
在一個實施例中，所述共享記憶體中包括第二緩衝區，其中，所述記錄單元41還配置為，在處理完成第一交易之後，在確定第二交易未提交的情況中，在所述第二緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第二交易根據預定提交順序為所述第一交易的前一個交易。
在一個實施例中，所述確定單元42還配置為，基於共享記憶體中記錄的目前應提交的交易，確定所述第二緩衝區中對應於最小交易編號的待處理任務的等待過程是否結束，以確定所述第二緩衝區中是否存在等待過程結束的待處理任務，其中，所述交易編號對應於交易的提交順序。
在一個實施例中，所述繼續執行單元43還配置為，在確定所述第二緩衝區中的第二待處理任務的等待過程結束的情況中，基於與所述第二待處理任務對應的執行信息，繼續執行對第三交易的提交，其中所述第二待處理任務與所述第三交易相對應。
在一個實施例中，所述共享記憶體中包括第三緩衝區，所述第一交易中包括對第一變數的讀取操作，其中，所述記錄單元41還配置為，在請求對所述第一變數的讀取之後，在所述第三緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第一待處理任務中包括對所述第一變數的記錄。
在一個實施例中，所述第三緩衝區中包括所述第二待處理任務，所述第二待處理任務與第二交易中對第二變數的讀取操作相對應，所述確定單元42還配置為，確定所述第二變數的變數值是否被返回，在確定所述第二變數的變數值被返回的情況中，確定該第二待處理任務的等待過程結束。
在一個實施例中，所述確定單元42還配置為，對於所述第三緩衝區中已經記錄的多個待處理任務，基於各個待處理任務對應的交易編號從小至大的順序，依次確定各個待處理任務的等待過程是否結束，其中，所述第二待處理任務為首次確定的等待過程結束的待處理任務，其中，所述交易編號對應於交易的預定提交順序。
在一個實施例中，所述確定單元42還配置為，基於在共享記憶體中的預定位址是否儲存有第二變數的變數值，確定所述第二變數的變數值是否被返回，其中，所述預定位址與所述第二交易相對應。
在一個實施例中，所述繼續執行單元43還配置為，在確定所述第三緩衝區中存在等待過程結束的第二待處理任務的情況中，基於與所述第二待處理任務對應的執行信息和所述第二變數的變數值，繼續執行所述第二交易。
在一個實施例中，所述共享記憶體中包括第四緩衝區，所述第一交易中包括對第一變數的讀取操作，其中，所述記錄單元41還配置為，在執行到所述讀取操作的碼之後，確定提交順序在第一交易之前、且未提交的各個交易是否為已執行了對第一變數的寫入操作的衝突交易，所述各個交易中包括第二交易，在確定所述第二交易為距離第一交易最近的衝突交易的情況中，在第四緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第一待處理任務中包括對第二交易的記錄。
在一個實施例中，所述確定單元42還配置為，基於共享記憶體中記錄的目前應提交的交易，確定在所述第四緩衝區中記錄的多個待處理任務中是否存在等待過程結束的待處理任務。
在一個實施例中，所述共享記憶體中包括第五緩衝區，所述第一交易中包括對第一變數的讀取操作，其中，所述記錄單元41還配置為，在執行到所述讀取操作的碼之後，推斷提交順序在第一交易之前、且未提交的各個交易是否為將要對第一變數進行寫入操作的衝突交易，所述各個交易中包括第二交易，在推斷所述第二交易為距離第一交易最近的衝突交易的情況中，在所述第五緩衝區中記錄與第一交易對應的第一待處理任務，其中，所述第一待處理任務中包括對第二交易的記錄。
在一個實施例中，所述共享記憶體中包括至少一個緩衝區，所述至少一個緩衝區與至少一種待處理任務分別對應，其中，所述確定單元42還配置為，基於所述至少一個緩衝區的預定順序，確定各個緩衝區中是否存在等待過程結束的待處理任務。
本說明書另一方面提供一種電腦可讀儲存媒體，其上儲存有電腦程式，當所述電腦程式在電腦中執行時，令電腦執上述任一項方法。
本說明書另一方面提供一種計算設備，包括記憶體和處理器，其特徵在於，所述記憶體中儲存有可執行碼，所述處理器執行所述可執行碼時，實現上述任一項方法。
透過根據本說明書實施例的並行執行交易的方案，在執行體執行交易過程中需要等待時記錄對該交易的處理信息，並從共享記憶體中獲取其它待處理任務或其它待處理交易進行處理，從而減少了執行體的等待時間，加快了交易並行執行的總體速度。
需要理解，本文中的“第一”，“第二”等描述，僅僅為了描述的簡單而對相似概念進行區分，並不具有其他限定作用。
本說明書中的各個實施例均採用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於系統實施例而言，由於其基本相似於方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在附圖中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多任務處理和並行處理也是可以的或者可能是有利的。
本領域普通技術人員應該還可以進一步意識到，結合本文中所公開的實施例描述的各示例的單元及演算法步驟，能夠以電子硬體、電腦軟體或者二者的結合來實現，為了清楚地說明硬體和軟體的可互換性，在上述說明中已經按照功能一般性地描述了各示例的組成及步驟。這些功能究竟以硬體還是軟體方式來執行，取決於技術方案的特定應用和設計約束條件。本領域普通技術人員可以對每個特定的應用來使用不同方法來實現所描述的功能，但是這種實現不應認為超出本申請的範圍。
結合本文中所公開的實施例描述的方法或演算法的步驟可以用硬體、處理器執行的軟體模組，或者二者的結合來實施。軟體模組可以置於隨機記憶體(RAM)、內部記憶體、唯讀記憶體(ROM)、電可編程ROM、電可抹除可編程ROM、暫存器、硬碟、可移動磁碟、CD-ROM、或技術領域內所公知的任意其它形式的儲存媒體中。
以上所述的具體實施方式，對本發明的目的、技術方案和有益效果進行了進一步詳細說明，所應理解的是，以上所述僅為本發明的具體實施方式而已，並不用於限定本發明的保護範圍，凡在本發明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。The embodiments of this specification will be described below in conjunction with the drawings.
Fig. 1 shows a schematic diagram of a blockchain system according to an embodiment of the present specification. As shown in FIG. 1, the system includes multiple nodes (six nodes are schematically shown in the figure) constituting a blockchain, and these nodes are connected in pairs, including node 11, node 12, and node 13, for example. As those skilled in the art know, in the blockchain, some nodes collect multiple transactions in the blockchain and put them into the transaction pool and compete for the right to keep accounts. For example, the node 11 in the figure becomes a billing node by acquiring billing rights. After node 11 becomes a billing node, it will execute multiple transactions in its transaction pool, package the multiple transactions into blocks and send them to other nodes, for example, to node 12. The node 12 will verify the block and execute multiple transactions in the block in the same way. After a predetermined number of nodes have verified the block, that is, the block has reached a consensus, other nodes in the block chain (such as node 13) will not need to continue to verify the block, but directly The transaction in this block is executed to update the local relevant information.
Figure 2 shows a schematic diagram of each node in the blockchain executing transactions in parallel through multiple threads. It can be understood that the execution threads can also be replaced with execution bodies such as processing and common routines. As shown in Figure 2, in each node, usually, the number of CPUs is limited, and the number of preset threads is also fixed. For example, assuming that the number of CPUs on the node is 4, the number of CPUs in the thread pool is pre-defined. Suppose the number of threads is 6, so that 6 threads compete to preempt the CPU, and only after preempting the CPU, can the tasks in the task pool begin to be executed.
In the process of executing multiple transactions in parallel by multiple threads, the calculation of multiple variables may be involved in the multiple transactions. In the case that the same variables are not involved in the two transactions, the order of execution will not Affect the final calculation result, and in the case of two transactions involving the same variables, the order of execution will affect the final calculation result. In the embodiments of this specification, in order to ensure that the execution results of multiple transactions by each node are the same, while multiple transactions are executed in parallel, the conflicts between the access variables between the transactions are considered, so that the parallel execution threads are Some of the threads need to go through a waiting process. Or you need to wait while waiting to return to access storage.
As shown in Figure 2, the figure includes the shared memory of the first node. The shared memory includes, for example, a buffer 1 for indicating transactions to be processed. The shared memory is readable and writable with respect to all threads. of. For example, there are currently 10 pending transactions 1, 2,...10 recorded in the first buffer zone. The bit boxes corresponding to the numbers 1, 2,..., 10 in the figure should all initially be 1, indicating that They are all pending transactions, where the serial numbers of transactions 1-10 correspond to the order of submission of each transaction. After starting to execute transactions in parallel, for example, threads 1 to 4 are preempted to CPUs 1 to 4, respectively, so that threads 1 to 4 can obtain a task from the first buffer for processing, for example, threads 1 to 4 respectively Start to process transactions 1 to 4. After the threads 1 to 4 start to process transactions 1 to 4, they respectively modify the bits corresponding to transactions 1 to 4 in the first buffer to 0 to indicate that these transactions have been executed. It can be understood that although the figure schematically shows that thread 1 preempts CPU1 and executes transaction 1, thread 2 preempts CPU2 and executes transaction 2, etc., it can be understood that the content shown in the figure is only for illustrative purposes. The thread number, CPU number, and transaction number do not correspond to each other. For example, thread 1 may preempt CPU2, execute transaction 3, and so on.
Figure 2 also shows multiple buffers for recording tasks to be processed, buffers 2 to 5, where each buffer corresponds to a waiting process. For example, buffer 2 corresponds to the waiting process of waiting for submission after the transaction is executed, buffer 3 corresponds to the waiting process of requesting a read to wait for the return of the variable value, and buffer 4 corresponds to the waiting process of writing a record based on the variable before reading. The waiting process of the previous transaction submission corresponds to the buffer 5 corresponding to the waiting process of waiting for the previous transaction submission or writing based on the transaction conflict probability before reading. In the embodiment of this specification, in order to execute the transaction in parallel, the process of executing the transaction includes the process of processing the transaction and the process of submitting the transaction, wherein the process of processing the transaction is to store the result of the transaction in the buffer corresponding to the transaction. In the process of submitting a transaction, the final processing result is stored in a shared memory shared by each transaction. For example, after thread 3 processes transaction 3, in order to ensure that the final results of each transaction are consistent, it is necessary to ensure that each transaction is submitted in the order of its number. Therefore, transaction 3 needs to wait for the previous transaction 2 to submit before submitting. In this case, the thread 3 records the position corresponding to the transaction 3 in the buffer 2, for example, the initial 0 is changed to 1, and then the thread 3 goes to the buffer to obtain a new task. For example, the thread 3 can first check whether there is a task in the buffer 2 waiting for the end of the process. The shared memory in FIG. 2 also records the current transaction window, and the current transaction window can be maintained by, for example, the thread that submits the transaction. For example, after thread 1 submits transaction 1, the first transaction in the transaction window can be modified to 2. Therefore, the transaction window moves one position backward among the multiple transactions to be submitted. When the thread starts to execute a new transaction (for example, transaction 7) according to the top position of the window, the last transaction in the transaction window can be updated from 6 to 7. At this time, for example, after the thread 3 checks the buffer 2, it can first determine whether the transaction 2 is a transaction that should be submitted currently based on the window. In the case that there is no task waiting for the end of the process in the buffer 2, it can be checked whether there is a task waiting for the end of the process in the buffer 3, and so on. In the case that there is no task waiting for the end of the process in buffers 2 to 5, the transaction to be processed can be obtained from buffer 1, for example, transaction 6. Thread 3 will also record the corresponding pending task in the corresponding one of the buffers 2 to 5 when it encounters a waiting process during the execution of transaction 6, for example, as shown by the dotted arrow on the right side of the figure , The thread 3 records the pending tasks corresponding to the transaction 6 in the buffer 4. Then, similarly, the thread 3 first determines in the buffer 2 to 5 whether there is a pending task waiting for the end of the process.
It can be understood that the above description of FIG. 2 is only schematic, and is not used to limit the scope of the embodiments of the present specification. For example, the specific forms of the buffers 1 to 5 are not necessarily the forms shown in the figure, as long as they can record corresponding information. Hereinafter, the process of executing transactions in parallel according to the embodiment of the present specification will be described in detail.
Fig. 3 shows a flow chart of a method for executing transactions in parallel in a blockchain according to an embodiment of the present specification. The method is executed on a first node in the blockchain, and the first node is preset with a first node. Execution body, the first execution body is currently processing a first transaction, and the method executed by the first execution body includes:
Step S302, after a predetermined operation is performed in the process of processing the first transaction, the first task to be processed corresponding to the first transaction and the execution information corresponding to the first task to be processed are recorded in the shared memory to compare The first transaction enters the waiting process;
Step S304, for the multiple pending tasks that have been recorded in the shared memory, it is determined whether there are pending tasks waiting for the end of the process; and
Step S306: In a case where it is determined that the waiting process corresponding to the second to-be-processed task is over, continue to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task, wherein the plurality of to-be-processed tasks The tasks include the second to-be-processed task.
First, in step S302, after a predetermined operation is performed in the process of processing the first transaction, the first to-be-processed task corresponding to the first transaction and the execution information corresponding to the first to-be-processed task are recorded in the shared memory. In order to enter the waiting process with respect to the first transaction.
As described above with reference to FIG. 2, the first executive body may be, for example, an executive body such as a thread, a process, a common routine, etc., and the shared memory is shared with respect to multiple executive bodies used to execute transactions in parallel. The following will take the thread as an example for description.
In the process of parallel execution of transactions in the nodes, for one of the transactions being executed, multiple waiting processes may be included, and the waiting processes may be caused by different reasons.
In one embodiment, as described above with reference to FIG. 2, the multiple transactions executed in parallel have been preset with a predetermined submission order. For example, transactions 1 to 10 in FIG. 2 must be numbered from small to large. Submit in order to ensure that the execution results of multiple transactions by each node are the same. Here, in the node, when the thread executes the transaction, the processing result is first saved in the buffer corresponding to the transaction, and after submission, the execution result is saved in the shared memory shared by each transaction. For example, in the process of processing the first transaction, the first variable needs to be written, and the value of the first variable after the write operation is first saved in the buffer corresponding to only the first transaction. The value is only It can be used when processing the first transaction, and the value will not be read or written when processing other transactions. After the first transaction is submitted, the value of the first transaction is stored in the shared memory, and other transactions can also read the value, or modify the value by submitting it.
Since each transaction has a predetermined submission sequence, as shown in FIG. 2, for example, the first transaction is transaction 6 in FIG. 2, and the first executive body is thread 3 in the figure. If the thread 3 finishes processing the transaction 6 and the transaction before the transaction 6 has not been submitted, at this time, the thread 3 needs to wait for the completion of the transaction 5 submission before submitting the transaction 6. Here, the thread 3 can determine whether the transaction 5 is submitted based on the preset transaction window parameters in the shared memory. The maximum total number of transactions that can be executed in parallel is controlled through the transaction window. The two sides of the transaction window are the transaction with the smallest number and the transaction with the largest number that are currently executed in parallel. For example, 1 and 6 in Figure 2 represent the transactions that are currently executed in parallel. For transactions 1～6. Therefore, by determining whether transaction 5 is the smallest transaction in the transaction window, it is determined whether transaction 5 should be submitted at present. In this case, thread 3 can modify the bit corresponding to transaction 6 in buffer 2 to 1, as shown in Figure 2, to add a pending task corresponding to transaction 6, which can only wait until Transaction 5 can only be executed after submission. At the same time, the execution information corresponding to the task to be processed, that is, the current processing information of transaction 6, can be stored in the shared memory, for example, the execution information buffer corresponding to each transaction. in.
In one embodiment, transaction 6 includes a read operation for variable k1, and after the execution of the code for the read operation, thread 3 sends a read for variable k1 to the hardware or thread used to read the variable. Fetch the request, and then record "k1" in the byte corresponding to transaction 6 in the buffer 3 shown in Figure 2 to add a pending task corresponding to transaction 6, and the pending task is waiting until the variable k1 The execution continues after the value of is returned.
In one embodiment, transaction 6 includes a read operation on the variable k1, and after the execution thread 3 starts to execute the code of the read operation, it queries the write buffer in the shared memory, and the write buffer records The current situation of writing various variables (including variable k1) in the processing of various transactions. For example, the write buffer only records that transaction 4 writes to variable k1, and transaction 5 writes to variable k1 is not recorded. Because, based on this record, transaction 4 will change the value of k1 in the variable table in the shared memory after submission. Therefore, transaction 6 needs to wait for transaction 4 to submit before reading the value of the variable k1, otherwise it will read Wrong value of k1. Thread 3, after checking the write buffer, records "4" in the byte corresponding to transaction 6 in buffer 3 in Figure 2 to add a pending task corresponding to transaction 6 , The "4" corresponds to transaction 4, which means that the pending task can only be executed after transaction 4 is submitted.
In one embodiment, transaction 6 includes a read operation on the variable k1. After the execution thread 3 starts to execute the code of the read operation, it infers whether each transaction (for example, transactions 1 to 5 in Figure 2) in the multiple transactions that are being executed in parallel will be written to the variable k1. Into operation. In one method, the transaction conflict probability of each variable can be determined in advance based on the transaction execution history in the node. When the transaction conflict probability of variable k1 is greater than a predetermined threshold, it can be inferred that transactions 1 to 5 will be affected by variable k1. Perform a write operation. Therefore, you need to wait for transaction 5 to be submitted before performing the read operation in transaction 6. If transaction 5 writes the value written to k1 into the buffer corresponding to transaction 5 in the shared memory during processing In the area (the buffer is not a variable table corresponding to each transaction), you can wait for transaction 5 to finish writing to k1 before reading k1. In one method, thread 3 can determine the conflict probability between transaction 6 and the previous transactions based on the transaction data of each transaction before transaction 6, and based on the conflict probability, infer whether each transaction will write to k1, In order to determine whether to wait for the transaction to be submitted or written. For example, in the case where it is determined that the write probability of transaction 4 to k1 is greater than or equal to the predetermined threshold, and the write probability of transaction 5 to k1 is less than the predetermined threshold, the thread 3 is in the buffer 5 in FIG. "4" is recorded in the byte corresponding to transaction 6 to record a task to be executed corresponding to transaction 6. The task to be executed can only be executed after transaction 4 is submitted or written.
Although four waiting conditions are listed above, the waiting conditions in the embodiments of this specification are not limited to the above four conditions, but may be any waiting conditions triggered by a predetermined operation.
In step S304, for the multiple pending tasks that have been recorded in the shared memory, it is determined whether there are pending tasks waiting for the end of the process.
As mentioned above, the shared memory includes buffers 2 to 5, in which different types of pending tasks are recorded respectively. For example, after the thread 3 stores the first task to be processed corresponding to transaction 6 in the shared memory through the above step S302, the thread 3 checks the buffers 2 to 5 in the shared memory in a predetermined order for use Obtain the pending tasks in which the waiting process ends. It can be understood that, in FIG. 2, the tasks to be processed in the buffers 2 to 5 may be tasks to be processed recorded by any of the threads 1 to 4.
For example, first, thread 3 can check buffer 2 first. As described above, each pending task recorded in the buffer 2 corresponds to a transaction that has been processed and is waiting to be submitted. For example, as shown in Figure 2, in buffer 2, the smallest transaction with a corresponding bit of 1 can be determined as transaction 2, and thread 3 can determine whether the transaction that should be submitted currently is transaction 2 based on the transaction window in the shared memory. If the transaction that should be submitted currently is transaction 2, it means that the waiting process of the pending task corresponding to transaction 2 is over, and the thread 3 can obtain the corresponding transaction 2 from the buffer for storing transaction execution information in the shared memory And continue to execute transaction 2 based on the execution information, that is, submit transaction 2.
In the case that the thread 3 does not find a pending task waiting for the end of the process in the buffer 2, the thread 3 can check the buffer 3, for example. As mentioned above, each pending task recorded in the buffer 3 is waiting for the return of the corresponding variable value. For example, if "k2" is recorded in the byte corresponding to transaction 2 in buffer 3, it means that transaction 2 is waiting for the return of the value of variable k2. Thread 3 can determine whether the value of k2 has been written from the predetermined address in the shared memory corresponding to transaction 2. When the value of k2 is written, it indicates the pending task corresponding to transaction 2 The waiting process ends, wherein the predetermined address corresponds to the transaction 2. Among them, the value of k2 can be written at the address by other threads performing read operations. In the case where it is determined that the value of k2 has not been written, it can be determined whether the waiting process is over for the tasks to be processed after transaction 2. For example, if "k1" is recorded in the byte corresponding to transaction 3, it can be determined whether the value of k1 has been written in the predetermined address corresponding to transaction 3.
In the case that the thread 3 does not find any pending tasks waiting for the end of the process in the buffers 2 and 3, the thread 3 can check the buffer 4, for example. As described above, the pending tasks recorded in the buffer 4 correspond to transactions that wait for other transactions to be submitted for read operations based on write conditions. Similar to checking buffer 2, thread 3 can determine whether transaction 1 waiting for transaction 2 is submitted based on the transaction window in shared memory. In the case of confirming transaction 1 submission, the pending task corresponding to transaction 2 The waiting process is over. In the case where it is determined that the transaction 1 has not been submitted, the thread 3 can determine whether the waiting process of the pending task corresponding to the transaction after the transaction 2 is over, for example, it can determine whether the waiting process corresponding to the transaction 3 is over.
In the case that the thread 3 does not find any pending tasks waiting for the end of the process in the buffers 2 to 4, the thread 3 can check the buffer 5, for example. As described above, the pending tasks recorded in the buffer 5 correspond to transactions that wait for other transactions to be submitted or written for read operations based on the probability of conflict. Thread 3 can similarly determine whether transaction 1 waiting for transaction 2 is submitted, or it can determine whether the waiting process of the pending task corresponding to transaction 2 is over based on the variable value written in the shared memory during the processing of transaction 1 .
It can be understood that the buffers 2 to 5 included in the aforementioned shared memory are only illustrative and not restrictive, and the sequence of checking the buffers is only illustrative and not restrictive. In specific implementations, Set up buffers and check the order of buffers according to the needs of the scene.
In one embodiment, in the case that the pending tasks waiting for the end of the waiting process are not checked in the buffers 2 to 5, the thread 3 can check the buffer 1 in the shared memory shown in FIG. The transaction to be processed is recorded in the area 1, so that the thread 3 can obtain the transaction to be processed with the smallest number (for example, transaction 6) from the buffer 1, and start to execute the transaction.
In step S306, in a case where it is determined that there is a second to-be-processed task waiting for the end of the process in the shared memory, the second to-be-processed task is continued to be executed based on the execution information corresponding to the second to-be-processed task.
In one embodiment, the thread 3 obtains the second to-be-processed task waiting for the end of the process in the buffer 2, and then the thread 3 continues to execute the submission of the transaction corresponding to the second to-be-processed task based on the corresponding execution information. After the thread 3 determines that the waiting process of the second to-be-processed task ends, it removes the corresponding second to-be-processed task in the buffer, for example, changes the "1" corresponding to the second to-be-processed task in the buffer 2 to 0 .
In one embodiment, the thread 3 obtains the second task to be processed in the buffer 3, and then the thread 3 continues to perform the operations following the read operation in the corresponding transaction based on the corresponding execution information and the value of the corresponding variable.
In one embodiment, the thread 3 obtains the second task to be processed in the buffer 4, and the thread 3 continues to execute the corresponding read operation in the corresponding transaction based on the corresponding execution information.
In one embodiment, the thread 3 obtains the second task to be processed in the buffer 5, and the thread 3 continues to execute the corresponding read operation in the corresponding transaction based on the corresponding execution information.
Fig. 4 shows another aspect of this specification according to an embodiment of this specification provides a device 400 for executing transactions in parallel in a blockchain, the device being deployed in the first execution body in the first node in the blockchain , The first node currently executes transactions in parallel through a preset predetermined number of executive bodies, including a first executive body, the first executive body is currently processing the first transaction, and the device includes:
The recording unit 41 is configured to record the first task to be processed corresponding to the first transaction and execution information corresponding to the first task to be processed in the shared memory after performing a predetermined operation in the process of processing the first transaction , To enter the waiting process with respect to the first transaction;
The determining unit 42 is configured to determine whether there is a pending task waiting for the end of the process among the multiple pending tasks that have been recorded in the shared memory, and the multiple pending tasks are determined by the predetermined number of execution entities. Record; and
The continuing execution unit 43 is configured to continue to execute the second to-be-processed task based on the execution information corresponding to the second to-be-processed task in a case where it is determined that the waiting process corresponding to the second to-be-processed task is over, wherein The multiple to-be-processed tasks include the second to-be-processed task.
In one embodiment, the device further includes a transaction execution unit 44 configured to, in the case where it is determined that the waiting processes of the multiple pending tasks have not ended, from the first buffer in the shared memory Acquire the second transaction to be processed, and start to execute the second transaction.
In one embodiment, the shared memory includes a second buffer area, wherein the recording unit 41 is further configured to, after processing the first transaction, in the case where it is determined that the second transaction has not been submitted, The first to-be-processed task corresponding to the first transaction is recorded in the second buffer zone, wherein the second transaction is the previous transaction of the first transaction according to a predetermined submission order.
In one embodiment, the determining unit 42 is further configured to determine whether the waiting process of the task to be processed corresponding to the smallest transaction number in the second buffer is over based on the transaction that should be submitted currently recorded in the shared memory To determine whether there is a pending task waiting for the end of the process in the second buffer zone, wherein the transaction number corresponds to the order of transaction submission.
In one embodiment, the continued execution unit 43 is further configured to, in a case where it is determined that the waiting process of the second to-be-processed task in the second buffer is over, based on the data corresponding to the second to-be-processed task Executing the information, continue to execute the submission of the third transaction, wherein the second pending task corresponds to the third transaction.
In one embodiment, the shared memory includes a third buffer, and the first transaction includes a read operation of the first variable, wherein the recording unit 41 is further configured to request the After the first variable is read, the first to-be-processed task corresponding to the first transaction is recorded in the third buffer, where the first to-be-processed task includes a record of the first variable.
In one embodiment, the third buffer includes the second to-be-processed task, and the second to-be-processed task corresponds to a read operation of the second variable in the second transaction, and the determining unit 42 It is also configured to determine whether the variable value of the second variable is returned, and in a case where it is determined that the variable value of the second variable is returned, it is determined that the waiting process of the second to-be-processed task ends.
In one embodiment, the determining unit 42 is further configured to, for the multiple pending tasks that have been recorded in the third buffer, determine each of the pending tasks based on the descending order of the transaction number corresponding to each pending task. Whether the waiting process of the task to be processed is finished, wherein the second task to be processed is the first determined task to be processed after the waiting process is completed, and the transaction number corresponds to the predetermined submission sequence of the transaction.
In one embodiment, the determining unit 42 is further configured to determine whether the variable value of the second variable is returned based on whether the variable value of the second variable is stored in the predetermined address in the shared memory, wherein, The predetermined address corresponds to the second transaction.
In one embodiment, the continued execution unit 43 is further configured to, in a case where it is determined that there is a second to-be-processed task waiting for the end of the process in the third buffer, based on the data corresponding to the second to-be-processed task The execution information and the variable value of the second variable continue to execute the second transaction.
In one embodiment, the shared memory includes a fourth buffer, and the first transaction includes a read operation of the first variable, wherein the recording unit 41 is further configured to: After reading the code of the operation, it is determined whether each transaction whose submission sequence is before the first transaction and is not submitted is a conflict transaction that has performed the write operation to the first variable, and each transaction includes the second transaction. In the case where it is determined that the second transaction is the closest conflict transaction to the first transaction, the first pending task corresponding to the first transaction is recorded in the fourth buffer, wherein the first pending task includes The record of the second transaction.
In one embodiment, the determining unit 42 is further configured to determine whether there is a waiting process to end among the multiple pending tasks recorded in the fourth buffer based on the transaction that should be submitted currently recorded in the shared memory. Pending tasks.
In one embodiment, the shared memory includes a fifth buffer, and the first transaction includes a read operation of the first variable, wherein the recording unit 41 is further configured to: After reading the code of the operation, it is inferred whether each transaction whose submission order is before the first transaction and is not submitted is a conflicting transaction that will write the first variable. The each transaction includes the second transaction. In the case where the second transaction is the closest conflict transaction to the first transaction, the first pending task corresponding to the first transaction is recorded in the fifth buffer, wherein the first pending task includes The record of the second transaction.
In an embodiment, the shared memory includes at least one buffer, and the at least one buffer corresponds to at least one task to be processed, wherein the determining unit 42 is further configured to, based on the at least one buffer The predetermined sequence of the zones determines whether there are pending tasks waiting for the end of the process in each buffer.
Another aspect of this specification provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is made to perform any of the above methods.
Another aspect of this specification provides a computing device, including a memory and a processor, characterized in that executable code is stored in the memory, and when the processor executes the executable code, any one of the above methods is implemented .
Through the parallel execution transaction plan according to the embodiment of this specification, the transaction processing information is recorded when the execution body needs to wait while executing the transaction, and other pending tasks or other pending transactions are obtained from the shared memory for processing, This reduces the waiting time of the execution body and speeds up the overall speed of parallel execution of transactions.
It needs to be understood that the descriptions of "first", "second", etc. in this article are only used to distinguish similar concepts for the sake of simplicity of description, and do not have other limiting effects.
The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment.
The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the attached patent application. In some cases, the actions or steps described in the scope of the patent application may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
Those of ordinary skill in the art should be further aware that the units and algorithm steps of the examples described in the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two, for clarity To illustrate the interchangeability of hardware and software, the composition and steps of each example have been described generally in terms of function in the above description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. A person of ordinary skill in the art may use different methods for each specific application to implement the described functions, but such implementation should not be considered beyond the scope of the present application.
The steps of the method or algorithm described in combination with the embodiments disclosed herein can be implemented by hardware, a software module executed by a processor, or a combination of the two. The software module can be placed in random memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the technical field.
The specific embodiments described above further describe the purpose, technical solutions and beneficial effects of the present invention in further detail. It should be understood that the above descriptions are only specific embodiments of the present invention and are not intended to limit the scope of the present invention. The scope of protection, any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the scope of protection of the present invention.
