CN112887437A

CN112887437A - Block chain transaction processing method, block chain node and block chain

Info

Publication number: CN112887437A
Application number: CN202110465388.2A
Authority: CN
Inventors: 刘晓建
Original assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-04-28
Filing date: 2021-04-28
Publication date: 2021-06-01
Anticipated expiration: 2041-04-28
Also published as: CN112887437B

Abstract

The embodiment of the specification provides a blockchain transaction processing method, a blockchain node and a blockchain, wherein the blockchain node comprises a master control device and a plurality of computing devices, and the method comprises the following steps: the master control device sending the received transaction to one of the plurality of computing devices; the computing device generates an access variable record of the transaction after receiving the transaction from the master control device each time; the master control device determines a plurality of transactions in the consensus proposal from the received transactions, and sends the identifications of the plurality of transactions to each of the computing devices; after receiving the identifications of the multiple transactions, the computing device groups the transactions in the locally received consensus offers into multiple transaction groups based on the access variable records of the transactions, generates variable tables of the transaction groups, and sends the variable tables of the transaction groups to the main control device; the master control device determines a transaction execution scheme based on the variable table of each transaction group and instructs each computing device to execute the transaction.

Description

Block chain transaction processing method, block chain node and block chain

Technical Field

The embodiment of the present specification relates to the technical field of blockchain, and more particularly, to a blockchain transaction processing method, a blockchain node, and a blockchain.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. The block chain is a chain data structure formed by combining data blocks in a sequential connection mode according to a time sequence, and is a distributed account book which is guaranteed in a cryptographic mode and cannot be tampered and forged. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people.

In one blockchain example, a master node and slave nodes are included, the master node is used for proposing a consensus proposal, the consensus proposal comprises a plurality of transactions included in blocks to be blocked and execution sequences of the plurality of transactions, and the consensus proposal is sent to each slave node. The slave node, after receiving the consensus proposal from the master node, executes the plurality of transactions included in the consensus proposal in the order of execution of the transactions determined in the consensus proposal, thereby causing the master node and the slave node to store consistent data.

The master node and the slave nodes may be implemented as multiple devices including a master control device, multiple computing devices, multiple storage devices, and the like, where the devices may be physical computers or virtual devices in the physical computers for executing specific functions. In the master node, after determining a plurality of transactions of the consensus proposal, the master control device generally groups the plurality of transactions and issues a plurality of transaction groups obtained to each computing device, wherein the plurality of transaction groups have no common access variable with each other, so that the computing devices can execute the transactions in each transaction group in parallel. After receiving the multiple transactions and the execution sequences of the multiple transactions of the consensus proposal from the master node, the master control device of the slave node also groups the multiple transactions and sends a plurality of transaction groups obtained by grouping to each computing device.

Disclosure of Invention

Embodiments of the present disclosure aim to provide a more efficient blockchain transaction processing scheme, blockchain link points and blockchains. The scheme provided by the embodiment of the specification enables the calculation power of a plurality of calculation devices in the block chain node to be fully used for processing the transaction in parallel, shortens the time consumption of transaction processing, and improves the efficiency of the block chain.

To achieve the above object, a first aspect of the present specification provides a method for processing a blockchain transaction, the method being performed by a blockchain link point, the blockchain link point including a master control device and a plurality of computing devices, the method including:

the master device sending the received transaction to one of the plurality of computing devices after each receipt of the transaction;

the computing device generates an access variable record of the transaction after receiving the transaction from the master control device each time;

the master control device determines a plurality of transactions in the consensus proposal from the received transactions, and sends the identifications of the plurality of transactions to each of the computing devices;

after receiving the identifications of the multiple transactions, the computing device groups the transactions in the locally received consensus offers into multiple transaction groups based on access variable records of the transactions, generates variable tables of the transaction groups, and sends the variable tables of the transaction groups to the main control device, wherein the variable tables record the accessed variables of the multiple transactions in the transaction groups, and no common access variable exists among the transaction groups in the same computing device;

the main control device determines a transaction execution scheme based on the variable tables of the transaction groups after receiving the variable tables of the transaction groups from the computing devices, and instructs the computing devices to execute transactions based on the transaction execution scheme.

In one embodiment, determining the transaction execution plan based on the variable table for each transaction group includes determining whether different computing devices include multiple transaction groups accessing the same variable based on the variable table for each transaction group; determining a transaction execution plan based on the determination result.

In one embodiment, the method further includes, in the case that the master device determines that different computing devices include multiple transaction groups accessing the same variable, the master device instructing the respective computing devices to perform transaction migration to other computing devices such that the multiple transaction groups accessing the same variable are executed in a particular order on the same computing device.

In one embodiment, the method further includes receiving, by the first computing device, transaction migration information from the master device, the transaction migration information including an indication to migrate a first transaction group to a second computing device, and sending, by the first computing device, a local first transaction group and an access variable record for each transaction in the first transaction group to the second computing device.

In one embodiment, the method further comprises the second computing device, after receiving the migrated first transaction group from the first computing device, performing the first transaction group after ranking the first transaction group across a plurality of local transaction groups.

In one embodiment, ranking the first transaction group for execution after a plurality of local transaction groups includes ranking the first transaction group for execution after a local transaction group that conflicts with the first transaction group.

In one embodiment, the method further includes the second computing device, after receiving the first transaction group and the access variable records of the respective transactions in the first transaction group from the first computing device, performing variable value prefetching for the transactions in the first transaction group based on the access variable records of the respective transactions in the first transaction group.

In one embodiment, the master device sending the received transaction to one of the plurality of computing devices includes the master device sending the transaction to the corresponding computing device based on a pre-recorded sending account and/or a correspondence table of receiving accounts and computing devices of the transaction.

In one embodiment, the master control device sending the received transaction to one of the plurality of computing devices includes, in a case that a sending account and/or a receiving account of the transaction is not recorded in the correspondence table, the master control device allocating the transaction to one computing device according to a predetermined mapping function that maps a plurality of transactions to the respective computing devices evenly based on at least part of data of the respective transactions, and updating the correspondence table.

In one embodiment, the master control device sending the received transaction to one of the plurality of computing devices includes, in a case that a sending account and/or a receiving account of the transaction is not recorded in the correspondence table, the master control device allocating the transaction to one computing device according to the number of transactions received by each computing device and updating the correspondence table.

In one embodiment, the method further comprises the computing device prefetching variable values for the transaction after each receipt of the transaction from the master device and generation of an access variable record for the transaction.

In one embodiment, the method further comprises the master device generating a consensus offer based on the transaction execution plan after determining the transaction execution plan and sending the consensus offer to other blockchain nodes.

In a second aspect of the present specification, there is provided a block link point comprising a master control device and a plurality of computing devices,

the master control device is used for sending the received transaction to one of the plurality of computing devices after receiving the transaction each time;

the computing device is used for generating an access variable record of the transaction after receiving the transaction from the main control device each time;

the master control device is further used for determining a plurality of transactions in the consensus proposal from the received transactions and sending the identifications of the plurality of transactions to each of the computing devices;

the computing device is further used for grouping the transactions in the locally received consensus offers into a plurality of transaction groups based on access variable records of the transactions after the identifications of the transactions are received, generating variable tables of the transaction groups, and sending the variable tables of the transaction groups to the main control device, wherein the variable tables record the access variables of the transactions in the transaction groups, and the access variables are not common among the transaction groups in the same computing device;

the main control device is also used for determining a transaction execution scheme based on the variable tables of the transaction groups after receiving the variable tables of the transaction groups from the computing devices, and instructing the computing devices to execute transactions based on the transaction execution scheme.

In one embodiment, the master control device is configured to determine the transaction execution scheme based on the variable table of each transaction group, and the master control device is configured to determine whether different computing devices include multiple transaction groups accessing the same variable based on the variable table of each transaction group; determining a transaction execution plan based on the determination result.

In one embodiment, the master control device is further configured to, in a case where it is determined that different computing devices include multiple transaction groups accessing the same variable, instruct the corresponding computing device to perform transaction migration to other computing devices, so that the multiple transaction groups accessing the same variable are executed in a specific order on the same computing device.

In one embodiment, the plurality of computing devices includes a first computing device and a second computing device, the first computing device is configured to receive transaction migration information from the master control device, the transaction migration information includes an indication to migrate a first transaction group to the second computing device, and the first computing device is further configured to send the local first transaction group and an access variable record of each transaction in the first transaction group to the second computing device.

In one embodiment, the second computing device is further configured to, after receiving the migrated first transaction group from the first computing device, rank the first transaction group for execution after the local plurality of transaction groups.

In one embodiment, the master control device is used for sending the received transaction to one of the plurality of computing devices and comprises the master control device is used for sending the transaction to the corresponding computing device based on a pre-recorded sending account and/or a pre-recorded correspondence table of the receiving account and the computing device.

In one embodiment, the master control device is configured to send the received transaction to one of the plurality of computing devices, and in a case that the sending account and/or the receiving account of the transaction is not recorded in the correspondence table, the master control device is configured to allocate the transaction to one computing device according to a predetermined mapping function, and update the correspondence table, where the predetermined mapping function maps a plurality of transactions to each of the computing devices uniformly based on at least part of data of each transaction.

In one embodiment, the master control device is configured to send the received transaction to one of the plurality of computing devices, and in a case that a sending account and/or a receiving account of the transaction is not recorded in the correspondence table, the master control device is configured to allocate the transaction to one computing device according to the number of transactions received by each computing device, and update the correspondence table.

In one embodiment, the computing device is further configured to pre-fetch variable values for the transaction after each receipt of the transaction from the master device and generation of an access variable record for the transaction.

In one embodiment, the master control device is further configured to, after determining the transaction execution plan, generate a consensus offer based on the transaction execution plan and send the consensus offer to other blockchain nodes.

A third aspect of the present specification provides a blockchain comprising a master node and a slave node, each of the master node and the slave node comprising a master device and a plurality of computing devices,

the master control device of the master node is configured to send a received transaction to one of the plurality of computing devices of the master node after each receipt of a transaction;

the computing device of the master node is used for generating an access variable record of the transaction after receiving the transaction from the master control device each time;

the master control device of the master node is further used for determining a plurality of transactions in the consensus offer from the received transactions, and respectively sending the identifications of the plurality of transactions to the plurality of computing devices of the master node;

the computing device of the main node is further configured to group the transactions in the locally received consensus offers into a plurality of transaction groups based on access variable records of the transactions after receiving the identifiers of the transactions, generate variable tables of the transaction groups, and send the variable tables of the transaction groups to the main control device of the main node, where the variable tables record access variables of the transactions in the transaction groups, and there is no common access variable between the transaction groups in the same computing device;

the master control device of the master node is further used for determining a transaction execution scheme based on the variable tables of the transaction groups after receiving the variable tables of the transaction groups from the computing devices of the master node, instructing the computing devices of the master node to execute the transaction based on the transaction execution scheme, generating a consensus proposal based on the transaction execution scheme, and sending the consensus proposal to the master control device of the slave node;

the master control device of the slave node is used for instructing each computing device of the slave node to execute the transaction according to the consensus proposal after receiving the consensus proposal.

In one embodiment, the consensus proposal includes grouping information for a plurality of transactions, wherein the master control device of the slave node being configured to instruct respective computing devices of the slave node to perform transactions according to the consensus proposal includes the master control device of the slave node being configured to instruct respective computing devices of the slave node to perform transactions in respective sets of transactions according to the grouping information for the plurality of transactions.

In one embodiment, the computing device of the slave node is further configured to, after receiving an instruction to execute a transaction from the master control device of the slave node, generate a received variable table for each transaction group, and send the variable table for each transaction group to the master control device of the slave node; the master control means of the master node is further adapted to validate the consensus proposal after receiving the variable tables for the respective transaction groups.

A fourth aspect of the present specification provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform any of the methods described above.

A fifth aspect of the present specification provides a computing device comprising a memory having stored therein executable code, and a processor that, when executing the executable code, implements any of the methods described above.

Drawings

The embodiments of the present specification may be made more clear by describing the embodiments with reference to the attached drawings:

FIG. 1 shows an architectural diagram of a blockchain;

FIG. 2 shows a flow diagram of a transaction processing method according to an embodiment of the present description;

FIG. 3 shows a schematic diagram of variable tables for various transaction groups generated by the computing device;

FIG. 4 shows a flow diagram of a method of transaction migration in a master node;

FIG. 5 is a graph comparing the time consumption of a transaction processing scheme with another transaction processing scheme according to an embodiment of the present disclosure;

FIG. 6 is a graph comparing the time consumption of a transaction processing scheme with another transaction processing scheme in accordance with an embodiment of the present disclosure;

FIG. 7 illustrates a block link point in accordance with embodiments herein;

fig. 8 illustrates a blockchain in accordance with embodiments of the present description.

Detailed Description

The embodiments of the present specification will be described below with reference to the accompanying drawings.

Fig. 1 shows an architecture diagram of a blockchain. As shown in fig. 1, the blockchain includes a master node and a plurality of slave nodes, wherein the master node is configured to determine a plurality of transactions of the consensus offer and determine an execution order of the plurality of transactions, send the consensus offer to each of the slave nodes, and execute the plurality of transactions based on the execution order. The slave node is configured to receive a consensus offer from the master node and to perform a plurality of transactions based on the consensus offer. Both the master node and each slave node include a master device (schematically shown by the letter M in fig. 1) and a computing device (schematically shown by the letters C1-C3 in fig. 1). Each node may further comprise a storage device (not shown in fig. 1) for storing data such as block data, status data and the like of the block chain. The main control device, the computing device and the storage device may be separate entity computing devices, or may be a virtual device in the computing devices for implementing a specific function.

In one embodiment, the master M of the master node receives from the client a transaction sent by the blockchain user. After a predetermined number of transactions are accumulated in the transaction pool of the master node, the master control device M of the master node determines a plurality of transactions of a consensus proposal and an execution order of the plurality of transactions based on the transactions in the transaction pool, and transmits the consensus proposal to the master control device M of each slave node. Meanwhile, in order to execute the multiple transactions in parallel through the multiple computing devices C, the master control device M of the master node obtains a read-write set of each transaction, the read-write set includes variable identifiers of read-write of the transaction, and the multiple transactions are grouped based on the read-write sets of the transactions to obtain multiple transaction groups. The plurality of transaction groups do not access the same variables as each other, so that the respective transaction groups can be executed in parallel without affecting transaction execution results. Then, the master control device M of the master node sends each transaction group obtained by grouping to each computing device, so that each computing device can execute the transactions in the corresponding transaction group in parallel. After the execution of the transaction in the corresponding transaction group is started, each computing device may read the value of the variable accessed by the transaction from the storage device of the master node when a certain variable is accessed for the first time, thereby executing the transaction, and maintain the value of the variable in the memory, and after the execution of the transaction in the corresponding transaction group is completed, each computing device may store the updated variable value stored in the memory into the storage device, thereby updating the world state of the variable. Meanwhile, after receiving the consensus protocol, the master control device of each slave node still needs to group a plurality of transactions as the master control device of the master node and send each transaction group to each computing device to execute the transaction.

In this solution, only the master control device groups the plurality of transactions, and the stand-alone computing power is limited, which requires a long time. When the master control device calculates the transaction packet, each of the calculation devices cannot perform the previous data preparation work, and only after receiving the transaction packet from the master control device, the preparation work such as data pre-fetching can be performed according to the transaction packet, which affects the execution speed of the transaction. On the other hand, the slave node also needs to repeat the transaction grouping of multiple transactions in the consensus proposal, wasting the calculation power of the blockchain.

In the scheme, after the main control device of the main node receives the transaction, the main control device distributes the transaction to the computing device immediately, and after the computing device receives the transaction, the computing device can determine a read-write set of the transaction and can prefetch the value of the variable accessed in the transaction from the storage device. The master device, after determining a plurality of transactions of the consensus proposal, sends an identification of the plurality of transactions to each computing device so that each computing device can group the transactions in the locally obtained consensus proposal and send the variable table accessed by each transaction group to the master device. The master control device determines whether there is a conflict in the transaction groups of the respective computing devices based on the variable tables of the respective transaction groups transmitted by the respective computing devices, and instructs the respective computing devices to perform the execution of the transaction in the consensus proposal according to the determination result. Meanwhile, the master control apparatus of the master node transmits the transaction grouping information to the master control apparatus of each slave node including the consensus proposal, so that the master control apparatus of the slave node can distribute each grouping to each computing apparatus immediately after receiving the consensus proposal without performing grouping for a plurality of transactions.

In the solution of the embodiment of the present specification, after receiving a transaction, the master control device of the master node can immediately distribute the transaction to the computing device, so that the computing device can make data preparation work of the transaction before consensus and proposal, thereby saving transaction processing time; after the main node determines a plurality of transactions included in the consensus proposal, each computing device can perform grouping on the transactions in the locally received consensus proposal in parallel, and the main node determines a final transaction execution scheme based on the grouping result of each computing device, so that the main node does not need to perform grouping on the plurality of transactions independently, and the transaction processing time is shortened; in addition, after the slave node receives the consensus proposal, the slave node does not need to additionally group a plurality of transactions, and the transaction processing time of the slave node is shortened.

The transaction processing scheme provided by the embodiments of the present specification will be described in detail below.

Fig. 2 shows a flow diagram of a transaction processing method according to an embodiment of the present description. The method is performed by the master control device and the computing device of the master node and the master control device and the computing device of the slave node together, it is understood that only one slave node is shown in the figure as an illustration, only one computing device is shown in the master node and the slave node as an illustration, in an actual block chain, a plurality of slave nodes may be included, and a plurality of computing devices may be included in the master node and the slave nodes, which all perform the same process as that shown in the figure. For example, the master of the master node in fig. 2 is master M in the master node in fig. 1, the computing device in the master node in fig. 2 may be any one of computing devices C1-C3 in the master node in fig. 1, the slave node in fig. 2 may be any one of slave nodes in fig. 1, and the computing device in the slave node may be any one of computing devices C1-C3 in the slave node.

As shown in fig. 2, first, in step S201, the master device of the master node transmits a transaction to the computing device of the master node.

After receiving the transaction from the user client, the master control device of the master node numbers the transaction according to the receiving sequence of the transaction, and then distributes the transaction to the computing device for processing. The distribution may be performed according to a predetermined distribution rule such that at least one of the following is satisfied: (1) the transactions with the same modified variable are divided into the same computing device as much as possible, so that variable access conflicts of the transactions divided by different computing devices are avoided; (2) so that the respective computing devices are relatively equally loaded.

In one embodiment, the transactions in the blockchain are transfer transactions, and the variables accessed by the transactions include the balance of the sending account and the balance of the receiving account of the transaction. In this case, the master device maintains a correspondence table of accounts and computing devices locally. Before forwarding the transaction to the computing device, the master control device first acquires a sending account and a receiving account of the transaction, and queries the computing device corresponding to the sending account and/or the receiving account in the corresponding relation table.

If the sending account and/or the receiving account are not recorded in the corresponding relation table, it indicates that the main control device has not received the transaction including the sending account and/or the receiving account, therefore, the main control device can allocate the transaction to a computing device with a smaller transaction load amount, and record the corresponding relation between the sending account and the receiving account and the allocated computing device in the corresponding relation table. Specifically, a load table for each computing device may be maintained at the master control device that records the number of transactions currently received by each computing device. The master control device may set the computing device with the lower load as a default computing device based on the load table, and in a case where an account in a transaction is not recorded in the correspondence table, assign the transaction to the default computing device, and modify a transaction load of the default computing device. In the event that the transaction load of the default computing device reaches a threshold, another computing device with a lower load may be set as the default computing device. With such an arrangement, it is possible to allocate a plurality of transactions in succession to the same computing device, thereby facilitating data compression when transmitting the plurality of transactions.

In the case that the sending account and the receiving account of the transaction are included in the correspondence table, and the sending account and the receiving account correspond to the same computing device, the transaction may be allocated to the computing device corresponding to the two accounts. In the case where one of the sending account and the receiving account of the transaction is included in the correspondence table, the transaction may be assigned to the computing device corresponding to the account.

When the correspondence table includes the sending account and the receiving account of the transaction, but the sending account and the receiving account correspond to different computing devices, a policy of sending account priority or receiving account priority can be preset, so that the transaction is allocated to the computing device corresponding to the account with priority.

In one embodiment, the main control device forwards the transaction to the computing device through multiple threads, and in order to prevent the situation that multiple threads access the corresponding relation table at the same time, the corresponding relation table can be split into multiple sub-tables, and each sub-table comprises a part of corresponding relations in the corresponding relation table, so that the reading speed of multiple threads is increased.

In another embodiment, the slave node may also receive the transaction to be executed before receiving the consensus proposal from the master node, but the order in which the transactions are received by the slave node may be different from the order in which the transactions are received by the master node, and thus the master control device of the slave node may result in a different assignment result from the master node if the transactions are assigned to the computing device according to the above embodiments, such that the slave node needs to adjust the computing device executing the transaction when receiving the consensus proposal. To avoid this, in a case where an account included in a transaction is not recorded in the correspondence table, the master node and the slave node may uniformly distribute the transaction to one computing device according to a predetermined mapping function, and record the correspondence between the account included in the transaction and the computing device in the correspondence table. The predetermined mapping relationship is, for example, a hash function for mapping an account included in the transaction to the computing device, or a hash function for mapping a transaction body of the transaction to the computing device, or the like. In this case, the load situation of each computing device no longer needs to be maintained in the master device, and load balancing of the computing devices can also be achieved.

At step S202, the computing device of the master node generates an access variable record for the received transaction.

After receiving the transaction, the computing device reads the transaction body of the transaction, so as to analyze the read-write variable of the transaction and generate an access variable record of the transaction. For example, the computing device may record a read-write set of the transaction in a transaction information retrieval table as shown in table 1, the read-write set including an identification (or name) of a variable read and/or written by the transaction, thereby recording the variable accessed by the transaction.

TABLE 1

As shown in Table 1, the read-write sets for transaction 1, transaction 2, and transaction 5 are recorded in Table 1, while the read-write sets for transaction 3 and transaction 4 are empty sets, indicating that transaction 3 and transaction 4 have not been received.

In one embodiment, the transaction is a transfer transaction from account a to account B, then account a and account B are included in the read set of the transaction, and account a and account B are included in the write set of the transaction.

In another embodiment, the master device is not limited to recording the read-write set of the transaction after receiving the transaction, but may only record the variable names read and/or written in the transaction. For example, for the above-described transfer transaction, the master may record only account a and account B as variable names for transaction access.

After the main control device records the name of the variable accessed by the transaction, the main control device can also pre-fetch the value of the variable accessed by the transaction from the storage device or the memory, so that data preparation work is done for subsequent transaction execution.

At step S203, the master device of the master node transmits an identification of the plurality of transactions of the consensus proposal to the computing device of the master node.

The master control means of the master node may place a transaction in the transaction pool after each transaction is received and determine a consensus proposal for a block from the transactions included in the transaction pool at predetermined time intervals (or after the number in the transaction pool reaches a predetermined number). The master device, upon determining the plurality of transactions included in the consensus offer, may transmit an identification of the plurality of transactions (e.g., a transaction number or transaction number) to the computing device of the master node. It will be appreciated that the identification of the transaction is not limited to being a transaction number, for example, the identification of the transaction may also be a hash value of the transaction.

In step S204, the computing device of the master node, after receiving the identifications of the plurality of transactions of the consensus proposal, groups the transactions in the locally received consensus proposal and generates a variable table for each transaction group.

The computing means of the master node, after receiving the identification of the plurality of transactions of the consensus proposal, may determine the transactions comprised in the consensus proposal from the locally received transactions and may group the transactions according to their access variable records. The grouping is such that a plurality of transactions accessing the same variable are grouped into one transaction group, and the execution order of the plurality of transactions grouped into one transaction group is determined according to a predetermined rule, the plurality of transaction groups obtained by the grouping having no variable commonly accessed to each other. By grouping the transactions in this way, when the computing device executes the transactions in the plurality of transaction groups, the transactions in each transaction group can be processed in parallel without affecting the final execution result of each transaction, and meanwhile, because the transactions in one transaction group have access variable conflicts, the transactions in the same transaction group need to be executed in series.

The computing device, after dividing the transactions in the local consensus proposition into a plurality of transaction groups as described above, also generates a variable table for each transaction group. The variable table includes variables for the access of transactions in each transaction group.

Fig. 3 shows a schematic diagram of a variable table for each transaction group generated by a computing device, such as computing device C1 in the master node in fig. 1. As shown in fig. 3, G0, G1, and G2 in the figure are group numbers of transaction groups, a variable bitmap of each transaction group is recorded in the variable table, each bit of the variable bitmap corresponds to one variable, for example, each bit from the left of three variable bitmaps in fig. 3 corresponds to a variable a, a variable b, a variable c …, and the like in a one-to-one manner, and a value of a bit in the variable bitmap is 1 indicates that a transaction including access to a corresponding variable is included in the corresponding transaction group, and is 0 indicates that a transaction including access to the corresponding variable is not included in the transaction group. For example, as shown in FIG. 3, transactions in transaction group G0 include transactions that access variables a and b, and transactions in transaction group G1 include transactions that access variable c. By recording the transaction-accessed variables in the transaction groups in the form of a variable bitmap, a comparison of the accessed variables of the two transaction groups to determine whether there are commonly accessed variables for the two transaction groups may be facilitated. It is to be appreciated that embodiments of the present description are not limited to recording variables accessed by respective transaction groups in the form of variable bitmaps, e.g., names of variables accessed by respective transaction groups may be recorded directly.

In step S205, the calculation device of the master node transmits the variable table of each transaction group to the master device of the master node after generating the variable table of each transaction group.

Referring to fig. 1, the computing devices C1-C3 included in the master node group the transactions in the local consensus proposal, respectively, and transmit the variable tables of the respective transaction groups to the master M in the master node. For example, the computing device C1 of the master node transmits the variable tables of the transaction groups G0 to G2 obtained by grouping to the master device M of the master node, the computing device C2 of the master node transmits the variable tables of the transaction groups G3 to G5 obtained by grouping to the master device M of the master node, and the computing device C3 of the master node transmits the variable tables of the transaction groups G6 to G8 obtained by grouping to the master device M of the master node.

In step S206, the master device of the master node determines a transaction execution plan based on the variable table of each transaction group.

Specifically, the master control device of the master node first determines whether a plurality of transaction groups accessing the same variable are included in different computing devices based on the variable table of each transaction group. The master device may determine whether different transaction groups have access to the same variable based on the variable bitmap of each transaction group.

In the event that the master device determines that the different computing devices do not include multiple transaction groups accessing the same variable, the master device may determine that transactions for the respective local transaction groups are to be performed by the respective computing devices. And may determine a consensus offer based on the transaction execution plan, the consensus offer including at least the plurality of transactions, grouping information for the plurality of transactions.

In the case where the master device determines that multiple transaction groups accessing the same variable are included in different computing devices, the master device may determine that the multiple transaction groups are executed serially by one computing device and determine transaction grouping information in the consensus offer based on the determined transaction execution scheme.

In step S207, the master control device of the master node transmits a consensus proposal to the master control device of the slave node.

In one case, the master control device of the master node determines that there is no conflicting transaction group for the transaction group of the respective computing device, the master control device of the master node may put the transaction groups G0-G8 acquired by the computing devices C1-C3 into the consensus proposal as a final transaction grouping result for the plurality of transactions of the consensus proposal, and send the consensus proposal to the master control device of the respective slave node. The master control means of each slave node may process the plurality of transaction groups in parallel after receiving the consensus proposal. If each slave node does not receive each transaction before receiving the consensus proposal, the consensus proposal also needs to include the transaction body of each transaction, if each slave node can receive each transaction before receiving the consensus proposal, the consensus proposal only needs to include grouping information of the plurality of transactions, wherein each transaction group can include the hash value of the transaction as the identification of the transaction.

In another case, assume that the bit corresponding to the variable C in the variable bitmap of transaction group G4 generated by computing device C2 in the master node in fig. 1 is 1, i.e., indicating that access to the variable C is included in transaction group G4, and thus, both transaction group G4 and transaction group G1 have access to the variable C, which is the conflicting transaction group. Since the transaction group G4 conflicts with the transaction group G1, if executed in parallel by two computing devices, it cannot guarantee a consistent execution order of the nodes to the transaction group G4 and the transaction group G1, i.e., in one node, the transaction group G4 may be executed first, and in another node, the transaction group G1 may be executed first, which may lead to inconsistent execution results of the nodes for the multiple transactions suggested by the consensus, and therefore migration of the transaction groups needs to be performed so that the transaction group G4 and the transaction group G1 are executed by one computing device in a predetermined sequential order, thereby guaranteeing consistency of the execution results. For example, the master of the master node may determine that transaction group G4 was migrated by computing device C2 to computing device C1 for execution by computing device C1 of transaction group G4 after execution of transaction group G1. By executing transaction group G4 by computing device C1 after executing transaction group G1, computing device C1 need not wait for the migration of transaction group G4 first, and while computing device C1 is executing transaction group G1, if the migrated transaction group G4 has been received, it may also perform variable value pre-fetching and the like on the transactions in transaction group G4. Similarly, for example, the master may determine that, in the event that it determines that transaction group G1 conflicts with transaction group G6, that transaction group G6 was migrated to computing device C1 by computing device C3 for execution of transaction group G6 by computing device C1 after execution of transaction group G1. In this case, the transaction group information in the consensus proposal will include at least: each of the transaction groups G0-G3, G5, G7, G8 may be processed in parallel, transaction group G1 requiring serial processing with transaction group G4, and transaction group G4 may be executed after transaction group G1 is processed, transaction group G1 requiring serial processing with transaction group G6, transaction group G4 and transaction group G6 may be processed in parallel if transaction group G4 does not conflict with transaction group G6, and transaction group G1, transaction group G4 and transaction group G6 may all be processed in series if transaction group G4 also conflicts with transaction group G6.

In one implementation where each node includes the same number of computing devices (or virtual computing devices), the assignment of transaction groups to computing devices may be included in the consensus proposal as shown in table 2.

TABLE 2

The consensus proposal shown in table 2 shows that transaction groups G0/G1-G4-G6/G2 are processed by computing device C1, wherein transaction groups G0/G1/G2 may be processed in parallel, transaction group G4 may need to be processed after transaction group G1 is processed, transaction group G6 may need to be processed after transaction group G4 is processed (assuming that transaction group G6 conflicts with transaction group G4), transaction groups G3 and G5 are processed by computing device C2, which may be processed in parallel, and transaction groups G7 and G8 may be processed by computing device C3, which may be processed in parallel.

At step S208, the master device of the master node transmits the transaction execution information to the computing device of the master node while transmitting the consensus proposal to the slave node.

As described above, in one case, the master control device of the master node determines that there are no conflicting transaction groups for the transaction packets of the respective computing devices, the master control device of the master node may send transaction execution information to the respective computing devices of the master node to instruct the respective computing devices to execute transactions in local multiple transaction groups, wherein the multiple transaction groups in each computing device may be executed in parallel.

In another case, as described above, the master of the master node determines that transaction group G4, transaction group G6, and transaction group G1 are conflicting transaction groups, and determines that transaction group G4 is migrated to computing device C1 by computing device C2 of the master node and determines that transaction group G6 is migrated to computing device C1 by computing device C3. Fig. 4 shows a flow diagram of a method of transaction migration in a master node. As shown in fig. 4, in this case, the master device of the master node may transmit transaction execution information including migration information of the transaction group G4 to the computing device C1 to the computing device C2 of the master node at step S2082. Similarly, at step S2083, the master device of the master node may send transaction execution information to the computing device C3 of the master node, the transaction execution information including migration information for the transaction group G6 to the computing device C1. Meanwhile, in step S2081, the master device of the master node may transmit transaction execution information to the computing device C1 of the master node, the transaction execution information instructing the computing device C1 to receive the transaction groups G4 and G6 and to serially process the transaction groups G1, G4, and G6.

At step S2091, the computing device C1 starts executing the local transactions in the respective transaction groups (i.e., transaction groups G0, G1, and G2) immediately after receiving the transaction execution information of the master device. At step S2092, the computing device C2 sends the transaction body and access variable records (e.g., read-write set) of each transaction in the transaction group G4 to the computing device C1 based on the transaction execution information of the master device. Thereafter, computing device C2 may process the locally remaining transaction groups G5 and G6 in parallel, wherein each transaction in transaction group G5 or G6 is performed serially in a predetermined order while processing transaction group G5 or G6. During execution of the transactions in the transaction groups G5 and G6, the computing device C2 may read the state value of a variable from the state database in the storage device when the variable is first read, and then maintain the state value of the variable in memory when the variable is first written. After the execution of the transactions in the transaction groups G5 and G6 is complete, the computing device C2 may update the state values of the variables maintained in memory into a state database in the storage device. Wherein the storage means may be located in the same physical device as the computing means or in a different physical device.

In steps S2093 and S2096, the computing device C3 performs similar processing to the computing device C2, and the description thereof is omitted here.

At step S2095, the computing device C1, after receiving the related data of the transaction group G4 and the transaction group G6 from the computing devices C2 and C3, may perform variable value prefetching for each transaction according to the variable access records of each transaction in the transaction groups G4 and G6. The computing device C1 may determine whether the variable accessed by the transactions in the transaction groups G4 and G6 is the same as the accessed variable in the local transaction groups based on the local variable tables of the transaction groups, and if so, not prefetch the variable, and if not, prefetch the variable. Alternatively, the master may record a variable (e.g., variable C) commonly accessed by the conflicting transaction groups upon determining the conflicting transaction group and send the variable name in the transaction execution information to the corresponding computing device (e.g., computing device C1), such that computing device C1 may determine which variables in the migrated transaction groups G4 and G6 to prefetch based on the name of the conflicting variable recorded in the transaction execution information. At step S2097, the computing device C1 may begin executing the transactions in the transaction group G4 after determining that the transaction group G1 has been processed based on the transaction execution information received from the master device, and thus saving execution time for the transactions in the transaction group G4 because the computing device C2 has already pre-fetched variable values for the transactions in the transaction group G4 before beginning executing the transactions in the transaction group G4. At step S2098, the computing device C1 executes the transaction in the transaction group G6 after determining that the execution of the transaction in the transaction group G4 is complete. Similarly, computing device C1 may update the variable values maintained in memory into the state database of the storage device after executing transactions in the complete local transaction group and transactions migrated to the local transaction group.

It will be appreciated that the above-described process of processing transactions by a computing device is merely illustrative and is not intended to limit the scope of embodiments of the present description. For example, computing device C1, after receiving the transaction execution information from the master device, is not limited to performing the execution of the transactions in transaction group G4 immediately after determining that the transactions in transaction group G1 have been performed, e.g., computing device C1 may perform the execution of the transactions in transaction group G4 after performing the local individual transaction groups (i.e., G0, G1, G2). Additionally, computing device C1 may also migrate transaction groups to other computing devices, and computing devices C2 and C3 may also receive migrated transaction groups from other computing devices.

FIG. 5 is a graph comparing the time consumption of a transaction processing scheme with another transaction processing scheme according to embodiments of the present disclosure. As shown in fig. 5, the dotted line on the left side of the figure is a time when the master control device of the master node determines that a plurality of transactions in the consensus proposal are well known, the upper part of fig. 5 is a schematic time-consuming diagram of the transaction processing process in the master node of the transaction processing scheme of the embodiment of the present disclosure, and the lower part of fig. 5 is a schematic time-consuming diagram of the transaction processing process in the master node of another transaction processing scheme, wherein the horizontal length of each block represents the time-consuming duration of the corresponding operation, the diagonal frame represents that the execution subject of the operation is the master control device, the white frame represents that the execution subject of the operation is the computing device, and the overlapped white frames represent that the operation is executed by the computing devices in parallel.

Referring to the upper part of fig. 5, in the transaction processing scheme of the embodiment of the present specification, the master device transmits the transaction numbers of a plurality of transactions to the respective computing devices after determining the plurality of transactions which are commonly recognized. Each computing device receives the transaction from the consensus device and generates the read-write set of the transaction before the master device determines the multiple transactions which are in consensus, so that each computing device can determine local consensus transactions according to the consensus transaction numbers immediately after receiving the consensus transaction numbers and perform transaction grouping on the transactions. Here, it is assumed that the transaction grouping operation is performed in parallel by three computing devices, each of which basically groups only the transaction of 1/3 among the commonly recognized plurality of transactions. After the calculation device completes the transaction grouping, a variable table of each transaction group is generated and sent to the main control device. After receiving the transaction group variable table, the master control device may generate a transaction execution scheme for each computing device based on the transaction group variable table, and send the transaction execution scheme to each computing device. After receiving the transaction execution plan, each computing device first performs transaction migration based on the transaction execution plan, where the three computing devices perform migration of the transactions in the respective transaction group to other computing devices in parallel. After that, each computing device executes the transaction of each transaction group, and the computing device generates the read-write set of the transaction and performs variable value prefetching of the transaction immediately after receiving the transaction from the master control device, so that the transaction execution time can be shortened.

Referring to the lower part of fig. 5, in another transaction processing scheme, after determining a plurality of commonly recognized transactions, the master control device of the master node needs to locally complete the grouping of the transactions, and therefore, the master control device generates a read-write set of each transaction and groups the plurality of transactions based on the read-write set of each transaction. Here, since the master device is performing the grouping of multiple transactions on its own, it will take approximately three times as long as it would be to group 1/3 transactions in parallel by three computing devices. After the plurality of transactions are grouped, the master control device respectively sends the transactions of each transaction group to the corresponding computing devices, and the sending time is longer than the time for parallel transaction migration of the three computing devices in the upper part because the data volume of the transaction body of the transaction is large and the master control device singly sends the transactions to each computing device. In addition, in this technical solution, after each of the computing devices receives each of the transaction group transactions, it is also necessary to perform the variable value reading work for the transaction first in the process of executing the transaction, which is longer than the time for executing the transaction at the top.

As is apparent from the time consumption comparison diagram in fig. 5, each link of the transaction processing in the master node in the embodiment of the present description saves operation time compared with the corresponding link in the technical solution at the lower part in fig. 5, and the total time consumption of the solution in the embodiment of the present description is much shorter than that of another technical solution, thereby greatly saving the transaction processing time in the block chain and improving the transaction processing efficiency of the block chain.

Returning again to fig. 2, at step S210, the master of the slave node sends the transaction group information to the respective computing devices of the slave node after receiving the consensus proposal from the master of the master node.

As described above, if the master control device of the slave node does not receive each transaction in the consensus offer before receiving the consensus offer, the consensus offer includes the transaction body of each transaction and grouping information of the plurality of transactions that are agreed upon, such that the transaction body of the transaction in each transaction group is included in the transaction group information sent from the master control device of the slave node to each computing device. The master device of the slave node may transmit transaction groups (e.g., transaction groups G1-G4-G6 described above) that need to be executed serially to a computing device and instruct the computing device to execute the transaction groups G1-G4-G6 serially in a predetermined order, and the master device of the slave node may allocate other transaction groups that do not conflict with each other to the respective computing devices based on load balancing considerations.

If the master of the slave node receives each transaction in the consensus offer before receiving the consensus offer, the master of the slave node needs to send the received transaction to each computing device of the slave node in line with the master of the master node for the convenience of subsequently performing the transaction (e.g., assigning the transaction based on the hash value of the transaction). To this end, the same number of computing devices as in the master node need to be included in the slave nodes, e.g., computing devices C1-C3 are also included in the slave nodes as shown in FIG. 1. If the number of computing devices in the slave node is different from the number of computing devices in the master node, for example, two computing devices are included in the slave node, three virtual computing devices may be provided in the master control device of the slave node, and the mapping relationship between the virtual computing devices and the two computing devices may be set, so that the master control device of the slave node may perform distribution of transactions to the three virtual computing devices.

In the second case described above, the master control device of the slave node sends the transaction to the corresponding computing device immediately after receiving the transaction, and the respective computing device of the slave node also generates an access variable record (not shown in fig. 2) of the transaction immediately after receiving the transaction. The master control device of the slave node, upon receiving the consensus proposal from the master control device of the master node, sends to each computing device transaction group information in which only the identity (e.g., hash value) of the transactions in the transaction group and the transaction group migration information need to be included for each computing device. For example, for the slave node's computing device C2, the consensus proposal includes the identification of the transactions in transaction groups G3 and G5, and includes the identification of the transactions in transaction group G4 and the migration information of transaction group G4 to the slave node's computing device C1.

In step S211, a variable table for each transaction group to be executed is generated from the computing device of the node.

For the first case in step S210, i.e., the slave node does not receive the transaction before receiving the consensus proposal, the computing device of the slave node may generate a read-write set of each transaction based on the transactions in each transaction group and generate a variable table (e.g., the variable bitmap above) of each transaction group based on the read-write set of each transaction after receiving the transaction group information from the master device of the node. After generating the read-write sets of the respective transactions, the computing device of the slave node may also perform variable value prefetching operations on the respective transactions to speed up subsequent execution processes.

For the second case in step S210, i.e., the slave node has received the respective transactions before receiving the consensus proposal, the computing device of the slave node (e.g., computing device C2) sends the transaction and readwrite sets of transaction group C4 to computing device C2 after receiving the above-mentioned transaction group information, and generates the variable tables of transaction group C5 and transaction group C6 based on the previously generated readwrite sets of the respective transactions. The operation of computing device C3 can be referred to the operation of computing device C2, and will not be described herein. Computing device C1 first generates the variable tables for trading groups G0, G1, and G2 after receiving the trading group information, and generates the variable tables for trading groups G4 and G6 after receiving the relevant data for trading groups G4 and G6 from computing devices C2 and C3, respectively.

In step S212, the computing device of the slave node transmits the variable table of the transaction group to the master device of the slave node.

Each computing device of the slave node, after generating the variable tables for each transaction group to be executed, sends these variable tables to the master device of the slave node.

In step S213, the master device of the slave node confirms whether there is a conflict for each transaction group based on the variable table for each transaction group.

If it is confirmed that the variable tables of the respective transaction groups do not conflict, the consensus proposal of the master node can be verified to be correct. If it is confirmed that there is a conflict in the variable tables of the respective transaction groups, it can be verified that there is an error in the consensus proposal of the master node, in which case the master control device of the slave node will send a transaction group migration indication, a transaction rollback indication, a transaction execution indication, etc. according to the conflict to obtain a correct execution result. For example, assuming that the migration information from computing device C2 to computing device C1 of transaction group G4 is not included in the transaction group information transmitted from the master device of the master node, the master device of the slave node instructs computing device C2 to migrate transaction group G4 to computing device C1 and instructs computing device C2 to rollback the change of the variable value of execution transaction group G4 after determining that there is a conflict between the two according to the variable tables of transaction groups G1 and G4, and at the same time instructs computing device C1 to rollback the change of the variable value of execution transaction group G6 and, after executing the transactions in transaction group G4, re-execute the transactions in transaction group G6.

It is to be understood that the above steps S211-S213 are for verifying the consensus proposal of the master node, and in case it is confirmed that the master control device of the master node is a trusted device, the consensus proposal of the master node may not be verified, and thus the above steps S211-S213 are not necessary but optional.

In step S214, the respective computing devices of the slave nodes execute the transactions in the transaction group.

Each computing device of the slave node, upon receiving the transaction group information from the master device of the slave node, may perform transactions in each transaction group based on the transaction group information. In the execution process, the transaction execution time can be shortened because the calculation device performs variable value prefetching on the transaction in advance.

FIG. 6 is a graph comparing the time consumption of a transaction processing scheme with another transaction processing scheme according to embodiments of the present disclosure. As shown in fig. 6, the dotted line on the left side of the figure is the time when the master control device of the slave node receives the consensus proposal from the master control device of the master node, the upper part of fig. 6 is a schematic time consumption diagram of the transaction processing process in the slave node of the transaction processing scheme of the embodiment of the present specification, and the lower part of fig. 6 is a schematic time consumption diagram of the transaction processing process in the slave node of another transaction processing scheme, wherein, similarly to fig. 5, the horizontal length of each box represents the time consumption of the corresponding operation, the oblique line box represents that the execution main body of the operation is the master control device, the white line box represents that the execution main body of the operation is the computing device, and the overlapped multiple white line boxes represent that the operation is executed by multiple computing devices in parallel.

Referring to the upper part of fig. 6, since in the solution of the embodiment of the present specification, the consensus proposal received from the master control device of the slave node includes grouping information of multiple transactions in the consensus proposal, the master control device of the slave node can directly send each transaction group transaction to the computing device of the corresponding slave node without further grouping the multiple transactions. After receiving the transactions of each transaction group, each computing device of the slave node can execute the transactions of each transaction group, specifically including determining a transaction read-write set, performing variable value prefetching on transaction variables, and executing the transactions. After determining the read-write set of the transaction, the computing device of the slave node may generate a variable table of each transaction group based on the read-write set of the transaction, and send the variable table to the master control device of the slave node. After the master control device of the slave node receives the variable tables of each transaction group, whether each transaction group conflicts or not can be confirmed while each computing device executes the transaction, so that the consensus proposal of the master node is verified, the correctness of transaction execution is further increased, and the time consumption of transaction processing is not prolonged.

Referring to the lower part of fig. 6, in another transaction processing scheme, the consensus offers received from the master control device of the node include only the multiple transactions of the consensus offers without including grouping information of the multiple transactions, and therefore the master control device of the slave node needs to group the multiple transactions, and as described above, the process includes first determining the read-write sets of the respective transactions, and grouping the multiple transactions based on the read-write sets of the respective transactions, and similarly as described above with reference to fig. 5, since the grouping process is performed by the master control device alone, the transaction grouping process takes a long time. The master control device of the slave node, after determining that transactions for the plurality of transactions are grouped, sends each transaction group transaction to each computing device. After receiving the transaction groups, each computing device executes the transactions in each transaction group, and the transaction execution time is long because the transaction data preparation work is not carried out in advance, and the variable values of the transactions are read in the execution process.

As is apparent from the time consumption comparison diagram in fig. 6, the total time consumption of the transaction processing in the slave node in the embodiment of the present specification is much shorter than that of the slave node in another technical solution, which greatly saves the transaction processing time in the blockchain and improves the transaction processing efficiency of the blockchain.

Fig. 7 shows a block link point, according to an embodiment of the present disclosure, comprising a master control device 71 and a plurality of computing devices 72,

the master control device 71 is configured to send the received transaction to one of the plurality of computing devices after each received transaction;

the computing device 72 is used for generating an access variable record of the transaction after receiving the transaction from the master control device each time;

the master control device 71 is further configured to determine a plurality of transactions in the consensus offer from the received transactions, and send identifications of the plurality of transactions to the respective computing devices;

the computing device 72 is further configured to, after receiving the identifiers of the multiple transactions, group the transactions in the locally received consensus offers into multiple transaction groups based on access variable records of the respective transactions, generate variable tables of the respective transaction groups, and send the variable tables of the respective transaction groups to the master control device, where the variable tables record variables accessed by the multiple transactions in the transaction groups, and there is no common access variable between the transaction groups in the same computing device;

the master control device 71 is further configured to determine a transaction execution scheme based on the variable tables of each transaction group after receiving the variable tables of each transaction group from each computing device, and instruct each computing device to execute a transaction based on the transaction execution scheme.

In one embodiment, the master control device 71 is configured to determine the transaction execution scheme based on the variable table of each transaction group, including the master control device 71 is configured to determine whether different computing devices include multiple transaction groups accessing the same variable based on the variable table of each transaction group; determining a transaction execution plan based on the determination result.

In one embodiment, the master control device 71 is further configured to, in a case that it is determined that different computing devices include multiple transaction groups accessing the same variable, instruct the corresponding computing device to perform transaction migration to other computing devices, so that the multiple transaction groups accessing the same variable are executed in a specific order on the same computing device.

In one embodiment, the plurality of computing devices 72 includes a first computing device and a second computing device, the first computing device is configured to receive transaction migration information from the master device, the transaction migration information includes an indication to migrate a first transaction group to the second computing device, and the first computing device is further configured to send a local first transaction group and an access variable record of each transaction in the first transaction group to the second computing device.

In one embodiment, the master control device 71 being configured to send the received transaction to one of the plurality of computing devices includes the master control device 71 being configured to send the transaction to the corresponding computing device 72 based on a pre-recorded sending account and/or a table of correspondence between receiving accounts and computing devices of the transaction.

In one embodiment, the main control device 71 is configured to send the received transaction to one of the plurality of computing devices, and the main control device 71 is configured to assign the transaction to one of the computing devices according to a predetermined mapping function that maps the plurality of transactions to the respective computing devices uniformly based on at least part of data of the respective transactions, and update the correspondence table, in case that the sending account and/or the receiving account of the transaction is not recorded in the correspondence table.

In one embodiment, the main control device 71 is configured to send the received transaction to one of the plurality of computing devices, and in a case that the sending account and/or the receiving account of the transaction is not recorded in the correspondence table, the main control device 71 is configured to allocate the transaction to one computing device according to the transaction amount received by each computing device, and update the correspondence table.

In one embodiment, the computing device 72 is further configured to pre-fetch variable values for the transaction after each receipt of the transaction from the master device and generation of an access variable record for the transaction.

In one embodiment, the master control device 71 is further configured to, after determining the transaction execution scheme, generate a consensus offer based on the transaction execution scheme, and send the consensus offer to other blockchain nodes.

Fig. 8 shows a blockchain according to an embodiment of the present disclosure, which includes a master node 81 and a slave node 82, where the master node 81 includes a master control device 811 and a plurality of computing devices 812, the slave node 82 includes a master control device 821 and a plurality of computing devices 822,

the master control device 811 of the master node 81 is configured to send a received transaction to one of the plurality of computing devices of the master node after each received transaction;

the computing means 812 of the master node 81 is configured to generate an access variable record of a transaction after each receipt of a transaction from a master control device;

the master control means 811 of the master node 81 is further configured to determine a plurality of transactions in a consensus offer from the received transactions, and to send identifications of the plurality of transactions to the plurality of computing means of the master node, respectively;

the computing device 812 of the master node 81 is further configured to, after receiving the identifiers of the multiple transactions, group the transactions in the locally received consensus offers into multiple transaction groups based on access variable records of the respective transactions, generate variable tables of the respective transaction groups, and send the variable tables of the respective transaction groups to the master control device 811 of the master node 81, where the variable tables record the accessed variables of the multiple transactions in the transaction groups, and there is no access variable in common among the transaction groups in the same computing device;

the master control device 811 of the master node 81 is further configured to determine a transaction execution scheme based on the variable tables of the respective transaction groups after receiving the variable tables of the respective transaction groups from the respective computing devices 812 of the master node 81, instruct the respective computing devices 812 of the master node 81 to execute transactions based on the transaction execution scheme, generate consensus offers based on the transaction execution scheme, and transmit the consensus offers to the master control device 821 of the slave node 82;

the master device 821 of the slave node 82 is configured to instruct the respective computing device 822 of the slave node 82 to execute the transaction according to the consensus offer after receiving the consensus offer.

In one embodiment, the consensus proposal includes grouping information of a plurality of transactions, wherein the master device 821 of the slave node 82 for instructing the respective computing devices 822 of the slave node 82 to execute the transactions according to the consensus proposal includes the master device 821 of the slave node 82 for instructing the respective computing devices 822 of the slave node 82 to execute the transactions in the respective transaction groups according to the grouping information of the plurality of transactions.

In one embodiment, the computing device 822 of the slave node 82 is further configured to, after receiving the indication of executing the transaction from the master device 821 of the slave node 82, generate the received variable tables of the respective transaction groups, and send the variable tables of the respective transaction groups to the master device 821 of the slave node 82; the master control means 811 of the master node 81 is further arranged to validate the consensus proposal after receiving the variable tables for the respective transaction groups.

It is to be understood that the terms "first," "second," and the like, herein are used for descriptive purposes only and not for purposes of limitation, to distinguish between similar concepts.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

It will be further appreciated by those of ordinary skill in the art that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application. The software modules may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. A blockchain transaction processing method, the method performed by a blockchain link point, the blockchain link point including a master control device and a plurality of computing devices, the method comprising:

2. The method of claim 1, wherein determining a transaction execution scheme based on the variable table for each transaction group comprises determining whether different computing devices include multiple transaction groups accessing the same variable based on the variable table for each transaction group; a transaction execution plan is determined based on the determination result.

3. The method of claim 2, further comprising, in the event that the master device determines that different computing devices include multiple transaction groups accessing the same variable, the master device instructing the respective computing device to transact migration to other computing devices such that the multiple transaction groups accessing the same variable are executed in a particular order on the same computing device.

4. The method of claim 3, wherein the plurality of computing devices includes a first computing device and a second computing device, the method further comprising the first computing device receiving transaction migration information from the master device, the transaction migration information including an indication to migrate a first transaction group to the second computing device, the first computing device sending a local first transaction group and an access variable record for each transaction in the first transaction group to the second computing device.

5. The method of claim 4, further comprising the second computing device performing after ranking the first transaction group locally across multiple transaction groups after receiving the migrated first transaction group from the first computing device.

6. The method of claim 5, wherein ranking the first transaction group for execution after a plurality of local transaction groups comprises ranking the first transaction group for execution after a local transaction group that conflicts with the first transaction group.

7. The method of claim 4, further comprising the second computing device, after receiving from the first computing device a first transaction group and access variable records for each transaction in the first transaction group, performing variable value pre-fetching of transactions in the first transaction group based on the access variable records for each transaction in the first transaction group.

8. The method of any of claims 1-7, wherein the master device sending the received transaction to one of the plurality of computing devices comprises the master device sending the transaction to the corresponding computing device based on a pre-recorded table of correspondence between send accounts and/or receive accounts of transactions and computing devices.

9. The method of claim 8, wherein the master device sending the received transaction to one of the plurality of computing devices comprises, in the event that a send account and/or a receive account for the transaction is not recorded in the correspondence table, the master device assigning the transaction to one computing device according to a predetermined mapping function that maps a plurality of transactions evenly to each computing device based on at least a portion of data for each transaction, and updating the correspondence table.

10. The method of claim 8, wherein the master device sending the received transaction to one of the plurality of computing devices comprises, in the event that a send account and/or a receive account for the transaction is not recorded in the correspondence table, the master device allocating transactions to one computing device based on the number of transactions received by each computing device and updating the correspondence table.

11. The method of any of claims 1-7, further comprising the computing device pre-fetching variable values for a transaction after each receipt of the transaction from the master device and generation of an access variable record for the transaction.

12. The method of claim 1 or 2, further comprising, after determining a transaction execution plan, the master device generating a consensus offer based on the transaction execution plan and sending the consensus offer to other blockchain nodes.

13. A block link point comprises a main control device and a plurality of computing devices,

the computing device is further used for grouping the transactions in the locally received consensus offers into a plurality of transaction groups based on access variable records of the transactions after receiving the identifications of the transactions, generating variable tables of the transaction groups, and sending the variable tables of the transaction groups to the main control device, wherein the variable tables record the accessed variables of the transactions in the transaction groups, and no access variable is common among the transaction groups in the same computing device;

14. The blockchain node of claim 13, wherein the master device to determine the transaction execution scheme based on the variable table for each transaction group includes the master device to determine whether different computing devices include multiple transaction groups accessing a same variable based on the variable table for each transaction group; a transaction execution plan is determined based on the determination result.

15. The blockchain node of claim 14, the master device further to, in the event that a determination is made that different computing devices include multiple transaction groups accessing the same variable, instruct the respective computing device to perform transaction migration to other computing devices such that the multiple transaction groups accessing the same variable are executed in a particular order on the same computing device.

16. The block link point of claim 15, wherein the plurality of computing devices comprises a first computing device and a second computing device, the first computing device is configured to receive transaction migration information from the master control device, the transaction migration information comprises an indication to migrate a first transaction group to the second computing device, and the first computing device is further configured to send a local first transaction group and an access variable record for each transaction in the first transaction group to the second computing device.

17. The blockchain node of claim 16, the second computing device further to, after receiving the migrated first transaction group from the first computing device, rank the first transaction group for execution after the local plurality of transaction groups.

18. The blockchain node of any one of claims 13 to 17, wherein the master device being configured to send the received transaction to one of the plurality of computing devices includes the master device being configured to send the transaction to the corresponding computing device based on a pre-recorded table of correspondence between sending accounts and/or receiving accounts of the transaction and computing devices.

19. The blockchain node of claim 18, wherein the master device being configured to send the received transaction to one of the plurality of computing devices includes, in the event that a send account and/or a receive account for the transaction is not recorded in the correspondence table, the master device being configured to assign the transaction to one of the computing devices according to a predetermined mapping function that maps a plurality of transactions evenly to each of the computing devices based on at least a portion of data for each transaction and update the correspondence table.

20. The blockchain node of claim 18, wherein the master device being configured to send the received transaction to one of the plurality of computing devices includes, in the event that a send account and/or a receive account for the transaction is not recorded in the correspondence table, the master device being configured to assign the transaction to one computing device according to the number of transactions that each computing device has received and update the correspondence table.

21. The blockchain node of any one of claims 13 to 17, the computing means being further configured to pre-fetch variable values for a transaction after each receipt of the transaction from the master and generation of an access variable record for the transaction.

22. The blockchain node of claim 13 or 14, the master device further configured to, after determining a transaction execution scheme, generate a consensus offer based on the transaction execution scheme and send the consensus offer to other blockchain nodes.

23. A blockchain comprising a master node and slave nodes, each of the master node and the slave nodes comprising a master device and a plurality of computing devices,

24. The blockchain of claim 23, wherein the consensus proposal includes grouping information for a plurality of transactions, wherein the master control device of the slave node being configured to instruct respective computing devices of the slave node to perform transactions according to the consensus proposal includes the master control device of the slave node being configured to instruct respective computing devices of the slave node to perform transactions in respective sets of transactions according to the grouping information for the plurality of transactions.

25. The blockchain of claim 24, the computing device of the slave node further configured to, after receiving an indication from the master control device of the slave node to perform a transaction, generate a received variable table for each transaction group, and send the variable table for each transaction group to the master control device of the slave node; the master control means of the master node is further adapted to validate the consensus proposal after receiving the variable tables for the respective transaction groups.

26. A computer-readable storage medium, on which a computer program is stored which, when executed in a computer, causes the computer to carry out the method of any one of claims 1-12.

27. A computing device comprising a memory having stored therein executable code and a processor that, when executing the executable code, implements the method of any of claims 1-12.