Method of performing transactions in a blockchain system, blockchain system and node

Abstract

A method for executing transactions in a blockchain, a blockchain system and a node, the blockchain system comprising a master node and a slave node, the method comprising: the master node pre-executing a plurality of transactions to obtain a pre-execution read-write set of each transaction; grouping the plurality of transactions according to the pre-execution read-write sets of the plurality of transactions to obtain a plurality of transaction groups, and generating a pre-execution read-write set of each transaction group; sending the grouping result and the pre-execution read-write set of each transaction group to the slave node; the slave node verifying the grouping result according to the pre-execution read-write sets of the plurality of transaction groups; in the case of passing the verification, executing the plurality of transactions in parallel according to the grouping result to obtain an execution read-write set of the transactions included in each transaction group, and verifying the pre-execution read-write set of each transaction group based on the execution read-write set of the transactions included in the transaction group.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for executing transactions in a blockchain system, a blockchain system, and a node. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain has received increasing attention and application. When executing multiple transactions within a block, blockchain nodes can accelerate transaction execution by executing transactions in parallel. Summary of the Invention

[0003] The purpose of this invention is to provide a scheme for executing transactions in a blockchain that can effectively verify whether the master node is acting maliciously.

[0004] This specification provides, in a first aspect, a method for executing transactions in a blockchain, the blockchain including master nodes and slave nodes, the method comprising:

[0005] The master node pre-executes multiple transactions to obtain a pre-execution read-write set for each transaction; it then groups the multiple transactions according to their pre-execution read-write sets to obtain multiple transaction groups, generating a pre-execution read-write set for each transaction group; and finally sends the grouping results and the pre-execution read-write sets for each transaction group to the slave nodes.

[0006] The slave node verifies the grouping results based on the pre-execution read-write sets of the multiple transaction groups; if the verification is successful, the multiple transactions are executed in parallel according to the grouping results to obtain the execution read-write set of the transactions included in each transaction group, and the pre-execution read-write set of the transaction group is verified based on the execution read-write set of the transactions included in each transaction group.

[0007] A second aspect of this specification provides a method for executing transactions in a blockchain, the blockchain including master nodes and slave nodes, the method being executed by the slave nodes, including:

[0008] The master node receives the grouping results obtained by grouping multiple transactions and the pre-execution read / write set of each transaction group, wherein the pre-execution read / write set of each transaction group is generated based on the pre-execution read / write set of each transaction included in the transaction group;

[0009] The grouping results are verified based on the pre-execution read / write sets of the multiple transaction groups;

[0010] If the verification is successful, the multiple transactions are executed in parallel according to the grouping results to obtain the execution read and write set of the transactions included in each transaction group;

[0011] The pre-execution read / write set of each transaction group is verified based on the execution read / write set of the transactions included in each transaction group.

[0012] A third aspect of this specification provides a blockchain slave node, comprising:

[0013] The receiving unit is configured to receive from the master node of the blockchain the grouping result obtained by grouping multiple transactions and the pre-execution read-write set of each transaction group, wherein the pre-execution read-write set of the transaction group is generated based on the pre-execution read-write set of each transaction included in the transaction group;

[0014] The verification unit is used to verify the grouping results based on the pre-execution read-write set of the multiple transaction groups;

[0015] An execution unit is used to execute the multiple transactions in parallel according to the grouping results if the verification is successful, so as to obtain the execution read and write set of the transactions included in each transaction group;

[0016] The verification unit is further configured to verify the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group.

[0017] The fourth aspect of this specification provides a blockchain, including master nodes and slave nodes.

[0018] The master node is used to: pre-execute multiple transactions to obtain a pre-execution read-write set for each transaction; group the multiple transactions according to the pre-execution read-write sets to obtain multiple transaction groups, and generate a pre-execution read-write set for each transaction group; and send the grouping results and the pre-execution read-write sets for each transaction group to the slave nodes.

[0019] The slave node is used to: verify the grouping results based on the pre-execution read-write sets of the multiple transaction groups; if the verification is successful, execute the multiple transactions in parallel based on the grouping results to obtain the execution read-write set of the transactions included in each transaction group, and verify the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group.

[0020] The fifth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the second aspect.

[0021] A sixth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in the second aspect.

[0022] The solution provided in the embodiments of this specification allows slave nodes to quickly verify whether the master node is acting maliciously, optimize existing time-consuming steps as much as possible, and ensure that the correctness and consistency of blockchain data can still be maintained even if the master node acts maliciously. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a diagram of the blockchain architecture in the embodiments of this specification;

[0025] Figure 2 A blockchain structure diagram is shown in the embodiments of this specification;

[0026] Figure 3 This is a flowchart illustrating the method for executing transactions in the embodiments of this specification;

[0027] Figure 4 This is an architecture diagram of a blockchain slave node in one of the embodiments of this specification. Detailed Implementation

[0028] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0029] Figure 1 A diagram illustrating the blockchain architecture in an embodiment of this specification is shown. Figure 1In this blockchain, for example, there are six nodes: master node 1 and slave nodes 2 through 5. The connections between the nodes schematically represent P2P (Peer-to-Peer) connections. Each node stores the full ledger, containing the state of all blocks and all accounts. Each node in the blockchain generates the same state by executing the same transactions, and each node stores the same state database. The difference lies in that master node 1 is responsible for receiving transactions from clients and initiating consensus proposals to the slave nodes. These proposals include, for example, information such as multiple transactions in the block to be formed (e.g., block B1) and the submission order of these transactions. After the nodes in the blockchain successfully reach a consensus on the proposal, each node executes these transactions according to the submission order in the proposal, thereby generating block B1.

[0030] Understandable. Figure 1 The blockchain shown is merely exemplary, and the embodiments described in this specification are not limited to applications. Figure 1 The blockchain shown can also be applied to blockchain systems that include sharding.

[0031] in addition, Figure 1 Although the example shows a blockchain with 6 nodes, this specification's embodiments are not limited to this and may include other numbers of nodes. Specifically, the nodes in the blockchain can satisfy the Byzantine Fault Tolerance (BFT) requirement. The Byzantine Fault Tolerance requirement can be understood as the existence of Byzantine nodes within the blockchain, while the blockchain does not exhibit Byzantine behavior externally. Generally, some Byzantine Fault Tolerance algorithms require a number of nodes greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm.

[0032] In related technologies, to improve the transactions per second (TPS) metric in blockchains, it is necessary to accelerate transaction execution. To this end, blockchain nodes can accelerate transaction execution by executing transactions in parallel. In one implementation, a blockchain node can execute transactions in parallel through multiple processes on a single machine; in another, blockchain nodes can be deployed in a server cluster, with multiple servers executing transactions in parallel. Typically, for transfer transactions, blockchain nodes first divide multiple transactions into multiple transaction groups based on the accounts accessed by the transactions. These transaction groups do not access the same accounts, thus allowing for parallel execution of each transaction group. However, when a smart contract is invoked within a transaction, the variables accessed in that transaction cannot be predicted before execution, making it impossible to effectively group multiple transactions and thus hindering parallel transaction execution.

[0033] In one related technology, in a blockchain including a master node and multiple slave nodes, the master node can pre-execute multiple transactions to obtain pre-execution read-write sets for each transaction. Based on these pre-execution read-write sets, the transactions are then divided into multiple groups, allowing each slave node to execute multiple transactions in parallel according to these groups. However, in this scheme, there is a possibility that the master node might intentionally act maliciously, such as providing incorrect groupings to the slave nodes.

[0034] This specification provides an embodiment of... Figure 1 The scheme shown in the blockchain for parallel transaction execution allows slave nodes to effectively check whether the master node is acting maliciously, thereby improving the system efficiency of the blockchain.

[0035] Figure 2 This diagram illustrates the structure of a blockchain master node 1 and slave nodes (e.g., slave node 2) provided in an embodiment of this specification. Figure 2 As shown, master node 1 includes a pre-execution module 11, a conflict detection module 12, and a consensus module 13, while slave node 2 includes a consensus module 22 and a computation module 23. Master node 1 can connect to a client, for example, to receive multiple transactions from the client. After receiving each transaction, master node 1 pre-executes the transaction using pre-execution module 11, obtaining a pre-execution read / write set for that transaction. The pre-execution read / write set includes a pre-execution read set and a pre-execution write set. Specifically, the pre-execution read set can be key-value pairs of variables read during the pre-execution of the transaction, and the pre-execution write set can be key-value pairs of variables written during the pre-execution of the transaction. Master node 1 can maintain a pre-execution state set. When pre-executing a transaction, pre-execution module 11 can read the state values ​​of variables from the pre-execution state set or a state database. After pre-executing a transaction, pre-execution module 11 can update the pre-execution state set based on the transaction's pre-execution read / write set.

[0036] like Figure 2 As shown, the pre-execution module 11 may include multiple pre-execution sub-modules, such as pre-execution sub-module 111 and pre-execution sub-module 112, which can pre-execute transactions in parallel. The conflict detection module 12 includes a pre-execution state set and a pre-execution transaction set, wherein the master node 1 stores the pre-execution state set and the pre-execution transaction set in memory, for use by the conflict detection module 12. The conflict detection module 12 performs pre-execution conflict detection on each transaction serially. Specifically, the conflict detection module 12 detects whether there is a conflict between the pre-execution read set of the transaction and the write set of already pre-executed transactions. If the value of a variable in the pre-execution read set of the transaction is different from the value of the variable in the pre-execution state set, a conflict is determined to exist. If no conflict is determined, the conflict detection module 12 updates the state in the pre-execution write set of the transaction to the pre-execution state set and sequentially arranges the transaction into the pre-execution transaction set.

[0037] Consensus module 13 retrieves multiple transactions from the pre-execution transaction set, arranged in a pre-recorded order. Consensus module 13 includes a grouping submodule 131, which groups the multiple transactions according to their respective pre-execution read / write sets, resulting in multiple transaction groups. There are no conflicting transactions between the transaction groups. Conflicting transactions between two transaction groups typically include the following situations: a transaction in the first transaction group reads a first variable (i.e., the first transaction group reads the first variable), and the second transaction group writes to the first variable; the first transaction group writes to the first variable, and the second transaction group writes to the first variable; the first transaction group reads and writes to the first variable, and the second transaction group writes to the first variable; the first transaction group reads and writes to the first variable, and the second transaction group reads and writes to the first variable. If two transaction groups read the same variable, it can also be considered that there are no conflicting transactions. Typically, to simplify the scheme, grouping submodule 131 can group multiple transactions according to the requirement that each transaction group does not access the same variable.

[0038] In addition, consensus module 13 generates pre-execution read-write sets for each transaction group based on the pre-execution read-write sets of the multiple transactions. Then, master node 1 initiates a consensus proposal to the consensus modules (e.g., consensus module 22) of each slave node. This consensus proposal includes the multiple transactions, the order of the multiple transactions in the pre-execution transaction set, the grouping results of the multiple transactions, and the pre-execution read-write sets for each transaction group. It is understood that the master node may also broadcast the multiple transactions to the slave nodes, thus omitting the multiple transactions from the consensus proposal.

[0039] After multiple consensus nodes in the blockchain successfully reach consensus, the group verification submodule 221 in the consensus module 22 can verify whether there is a conflict between the groups based on the group read and write sets of each group, that is, verify whether the groups access the same variables or accounts.

[0040] If the verification by the group verification submodule 221 passes, the computation module 23 in the slave node can begin executing the multiple transactions in parallel according to the groups. The computation module 23 of slave node 2 includes multiple execution submodules (execution submodules 232, 233, and 234 are schematically shown in the figure). Each execution submodule can verify the correctness of the grouping based on the obtained execution read / write set of the transactions during the transaction execution process.

[0041] Through the process described above, master node 1 sends the pre-execution read-write sets of each transaction group to each slave node, which can effectively verify whether the master node is acting maliciously, thus improving system efficiency.

[0042] The following will refer to Figure 3The flowchart illustrating the method for executing a transaction details the above process. Figure 3 The diagram only shows the processes executed by master node 1 and slave node 2. It can be understood that other slave nodes in the blockchain execute the same processes as slave node 2.

[0043] refer to Figure 3 First, in step S301, master node 1 pre-executes multiple transactions to obtain a pre-execution read / write set for each transaction.

[0044] Master node 1 can pre-execute each transaction immediately after receiving it.

[0045] In one implementation, master node 1 can serially execute multiple received transactions. When master node 1 is about to execute a transaction, it receives... Figure 2 When reading the value of any variable from the pre-execution state set or state database, the key-value pair of the variable being read is recorded in the read cache of the transaction set in memory. When writing the value of any variable, the key-value pair of the variable being written is recorded in the write cache of the transaction. After the pre-execution ends, the pre-execution read-write set of the transaction can be obtained based on the read cache and write cache of the transaction.

[0046] Specifically, when master node 1 reads a variable (e.g., variable A) during the pre-execution of a transaction, it first determines whether the write cache of the transaction stores the value of variable A. If the value of variable A is stored, it can be read directly from the write cache. If the write cache does not store the value of variable A, it determines whether the read cache of the transaction stores the value of variable A. If the read cache does not store the value of variable A, it determines whether the pre-execution state set stores the value of variable A. If the pre-execution state set stores the value of variable A, it can be read from the state database. In other words, during the pre-execution of a transaction, the priority of master node 1 in reading variables is: transaction write cache > transaction read cache > pre-execution state set > state database. This ensures that the value of a variable read during pre-execution is the latest value of that variable.

[0047] After pre-executing each transaction as described above, master node 1 obtains a pre-execution read-write set for each transaction. In one embodiment, the pre-execution read-write set includes a read set and a write set, wherein the read set includes key-value pairs of variables read during the pre-execution of the transaction, and the write set includes key-value pairs of variables written during the pre-execution of the transaction. In another embodiment, the read set of the pre-execution read-write set may include version numbers of variables read during the pre-execution of the transaction, and the write set may include version numbers of variables written, wherein, for example, each written value of a variable and its corresponding version number are stored in a state database, so that the values ​​read and written by the transaction can be determined by including the version numbers of the variables in the read-write set.

[0048] In transactions involving contract calls, blockchain nodes may write different variables based on the values ​​read during the execution of the called contract. For example, when the read value of a variable is 1, 10 might be written to variable 'a'; when the read value is 2, 20 might be written to variable 'b', and so on. Therefore, for a transaction that calls a contract, the blockchain node must execute the transaction to determine the variables read and written, thus obtaining the transaction's read-write set. To this end, master node 1 obtains a pre-execution read-write set for each of multiple transactions by pre-executing each of them. This pre-execution process is essentially the same as the transaction execution process, except that the pre-execution of the transaction occurs before consensus is reached, while the execution of the transaction occurs after consensus is reached. Furthermore, the pre-execution results of the pre-execution transactions are only used to update the pre-execution state set, not to update the world state, while the execution results of the executed transactions are used to update the world state.

[0049] In one implementation, reference Figure 2 Master node 1 can pre-execute multiple transactions received simultaneously in parallel through multiple pre-execution sub-modules. To prevent conflicts caused by multiple pre-execution sub-modules updating the pre-execution state set in parallel, master node 1 performs pre-execution conflict detection on each transaction serially after pre-execution.

[0050] Specifically, when master node 1 performs pre-execution conflict detection on transaction Tx1 among the multiple transactions, it first determines whether the pre-execution state set includes variables (e.g., variable A) from the pre-execution read set of transaction Tx1. If not, it similarly determines whether the pre-execution state set includes other variables from the pre-execution read set of transaction Tx1. If the pre-execution state set does not include all variables from the pre-execution read set of transaction Tx1, meaning that the transaction that previously underwent pre-execution conflict detection has not yet read or written the variables accessed by this transaction, it can be determined that the pre-execution read set of transaction Tx1 does not conflict with the pre-execution state set, that is, it is determined that the pre-execution of transaction Tx1 does not conflict with the transactions that previously underwent pre-execution conflict detection.

[0051] If master node 1 determines that the pre-execution state set includes the value of variable A, it then checks whether the value of variable A in the pre-execution read set is consistent with the value of variable A in the pre-execution state set. If they are consistent, it means that the value of variable A read by the transaction is the latest state of variable A during the pre-execution process. Once master node 1 has determined that the value read for each variable in the pre-execution read set of transaction Tx1 is the latest state during the pre-execution process, it can be determined that there is no conflict between the pre-execution read set and the pre-execution state set of transaction Tx1.

[0052] If master node 1 determines that the value of variable A in the pre-execution read set of transaction Tx1 is inconsistent with the value of variable A in the pre-execution state set, it indicates that the value of variable A read by transaction Tx1 is not the latest state during the pre-execution process. Therefore, it can be determined that there is a conflict between the pre-execution read set and the pre-execution state set of transaction Tx1. In the case of a confirmed conflict, master node 1 can re-execute transaction Tx1.

[0053] If the master node 1 determines that there is no conflict between the pre-execution read set and the pre-execution state set of a transaction, it updates the pre-execution state set and the pre-execution transaction set based on the pre-execution read and write set of the transaction.

[0054] Specifically, for example, if master node 1 determines that there is no conflict between the pre-execution read set and the pre-execution state set of transaction Tx2 among the multiple transactions, master node 1 updates the values ​​of variables read or written from the pre-execution read / write set of transaction Tx2 to the pre-execution state set, thereby making the pre-execution state set record the latest state of each variable during the pre-execution process. Simultaneously, master node 1 records this transaction sequentially into the pre-execution transaction set, for example, recording it at the end of the pre-execution transaction set (i.e., the last position). That is, the order of transactions recorded in the pre-execution transaction set reflects the order of conflict detection for each transaction, and the recorded transactions do not conflict with previously recorded transactions. The pre-execution transaction set can be, for example, in the form of a sequential list or a queue.

[0055] In step S303, master node 1 groups multiple transactions according to the pre-execution read-write set of multiple transactions.

[0056] In master node 1, multiple transactions can be grouped using the grouping submodule 131 based on the keys of the variables read and written in the pre-execution read / write sets of each transaction. As mentioned above, this grouping ensures that transactions in different groups do not access the same variables, including both read and write operations. Under the condition that this grouping condition is met, there will be no conflicting transactions between transaction groups, and therefore, the transaction groups can be executed in parallel.

[0057] In step S305, master node 1 generates pre-execution read-write sets for each transaction group.

[0058] The grouping submodule 131 can also generate the pre-execution read-write set for each transaction group based on the pre-execution read-write set of each transaction included in each transaction group. Specifically, the grouping submodule 131 can generate the pre-execution read set for each transaction group based on the pre-execution read set of each transaction. This pre-execution read set includes the keys of all variables read by all transactions in the transaction group. For example, a transaction group includes transactions Tx1, Tx2, and Tx3. The pre-execution read set of transaction Tx1 includes key-value pairs of variables a and b, the pre-execution read set of transaction Tx2 includes key-value pairs of variables c and b, and the pre-execution read set of transaction Tx3 includes key-value pairs of variables a and c. Then the pre-execution read set of this transaction group is {a, b, c}.

[0059] Grouping submodule 131 can generate a pre-execution write set for a transaction group based on the pre-execution write set of each transaction. Similar to generating a pre-execution read set for a transaction group as described above, the pre-execution write set includes the keys of variables written by all transactions in the transaction group.

[0060] After master node 1 completes the pre-execution of multiple transactions, as described above, the consensus process ensures that the pre-execution read-write set and the execution read-write set of the transactions are consistent. Therefore, master node 1 can directly use the pre-execution results of the multiple transactions as the execution result of the transaction. It updates the state database based on the pre-execution read-write set of the multiple transactions and generates a block. This block includes a block header and a block body. The block body includes, for example, the transaction body and receipt data of each of the multiple transactions. The block header may include state root, receipt root, transaction root, and other data.

[0061] In step S307, master node 1 sends the grouping results of multiple transactions, the pre-execution read / write set of each transaction group, and the order of the multiple transactions in the pre-execution transaction set to the slave nodes (including slave node 2).

[0062] Specifically, master node 1 can generate a consensus proposal, which may include the grouping results of multiple transactions, the pre-execution read / write sets of each transaction group, and the order of the multiple transactions in the pre-execution transaction sets. This consensus proposal is then sent to each slave node, thereby reaching a consensus with them. That is, the multiple transactions are included as transactions in the upcoming block, and these transactions are executed based on their order in the pre-execution transaction sets. Slave nodes may receive these multiple transactions separately from the master node or a client, or the consensus proposal may include these multiple transactions.

[0063] In this way, master node 1 eliminates conflicts between transactions during pre-execution, and each node executes each transaction in the order of the pre-execution transaction set, so that the read-write set obtained by executing a transaction is necessarily consistent with the pre-execution read-write set of the transaction if the master node does not act maliciously.

[0064] In step S309, the slave node verifies the grouping results based on the pre-execution read-write set of each transaction group.

[0065] Specifically, slave node 2 can determine whether each group accesses the same variable based on the pre-execution read-write set of each transaction group. If at least two groups access the same variable, it means that the at least two groups should be assigned to the same transaction group. Therefore, it can be determined that the grouping result is incorrect, and thus it can be determined that the master node has engaged in malicious behavior, that is, provided incorrect grouping. Therefore, the verification fails, and slave node 2 can execute step S315, which executes multiple transactions serially in the order of the consensus proposal. That is, each slave node no longer trusts the grouping result of the master node, but achieves a consistent execution result by executing multiple transactions serially.

[0066] If the verification in step S309 passes, step S311 is executed from node 2. During the execution of each transaction, the pre-execution read-write set of the verification group is verified according to the execution read-write set of the transaction.

[0067] After node 2 verifies the grouping results, it can proceed via... Figure 2 The multiple execution submodules shown execute multiple transactions in parallel. For example, each execution submodule can receive one or more transaction groups from the consensus module 22 to execute multiple transactions in each transaction group serially. During the execution of each transaction, the execution submodule generates an execution read set and an execution write set for that transaction. The execution read set includes key-value pairs of variables read during the execution of the transaction, and the execution write set includes key-value pairs of variables written during the execution of the transaction.

[0068] During the execution of a transaction, i.e., before the transaction execution is complete, the execution submodule checks whether the pre-execution read set of the transaction group to which the transaction belongs includes the variable each time it reads a variable. This verifies the pre-execution read set of the transaction group. If the variable is not included in the pre-execution read set of the transaction group, it means that the master node provided an incorrect pre-execution read set. Therefore, the grouping result obtained based on this pre-execution read set is also incorrect. Consequently, the verification in step S311 fails, and slave node 2 can similarly execute step S315. Conversely, if all variables written during the execution of the transaction appear in the pre-execution write set of the transaction group, the execution of other transactions in that group can continue.

[0069] Similarly, during transaction execution, the execution submodule can also verify the pre-execution write set of the transaction group. It can verify whether the variables written during transaction execution appear in the pre-execution write set of the transaction group. If they do not appear, the verification in step S311 fails, and the slave node can execute step S315. Conversely, if all variables written during transaction execution appear in the pre-execution write set of the transaction group, the execution of other transactions in that group can continue.

[0070] If the verification in step S311 passes, the slave node can continue execution. Figure 3 Step S313 in the process.

[0071] In step S313, the slave node verifies the execution read-write set of the transaction group based on the execution read-write set of the transaction group.

[0072] After node 2 completes multiple transactions in parallel, it can generate the execution read-write set of each transaction group based on the execution read-write set of the transactions included in each group. This process can be referred to the description of generating the pre-execution read-write set of the transaction group above, and will not be repeated here.

[0073] Then, node 2 can verify whether the executed read / write set of each transaction group is consistent with the pre-executed read / write set of that transaction group. Specifically, it verifies whether the executed read set of each transaction group is consistent with the pre-executed read set of that transaction group, and it verifies whether the executed write set of each transaction group is consistent with the pre-executed write set of that transaction group. If they are consistent, the verification passes, and node 2 can update the world state based on the execution results of these multiple transactions and generate a block. If the executed read / write set of each transaction group is inconsistent with the pre-executed read / write set of that transaction group, then node 2 can execute step S315.

[0074] After each slave node completes step S315 if the verification fails, it can trigger a re-election of the master node, thereby preventing the current master node from acting maliciously again.

[0075] Figure 4 This is an architecture diagram of a blockchain slave node according to an embodiment of this specification, including:

[0076] The receiving unit 41 is used to receive from the master node of the blockchain the grouping result obtained by grouping multiple transactions and the pre-execution read-write set of each transaction group, wherein the pre-execution read-write set of the transaction group is generated based on the pre-execution read-write set of each transaction included in the transaction group;

[0077] Verification unit 42 is used to verify the grouping results based on the pre-execution read-write set of the multiple transaction groups;

[0078] Execution unit 43 is used to execute the multiple transactions in parallel according to the grouping results when the verification is passed, so as to obtain the execution read and write set of the transactions included in each transaction group;

[0079] The verification unit 42 is further configured to verify the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group.

[0080] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0081] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0082] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0083] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0084] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0085] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0086] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0087] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0088] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, a network interface, and memory. Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0089] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0090] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0091] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0092] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate different embodiments or examples and features described in this specification. The above descriptions are merely embodiments of one or more embodiments of this specification and are not intended to limit the scope of this specification. For those skilled in the art, various modifications and variations can be made to the one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A method for executing transactions in a blockchain system, the blockchain system comprising master nodes and slave nodes, the method comprising: The master node pre-executes multiple transactions to obtain a pre-execution read-write set for each transaction; it then groups the multiple transactions according to their pre-execution read-write sets to obtain multiple transaction groups, generating a pre-execution read-write set for each transaction group; and finally sends the grouping results and the pre-execution read-write sets for each transaction group to the slave nodes. Before executing the multiple transactions, the slave node verifies whether the transaction groups in the multiple transaction groups access the same variables based on the pre-execution read-write set of the multiple transaction groups. If not, the verification is confirmed to be successful. In the case where the verification fails, the multiple transactions are executed sequentially according to the order in the consensus proposal; in the case where the verification passes, the multiple transactions are executed in parallel according to the grouping results to obtain the execution read-write set of the transactions included in each transaction group, and the pre-execution read-write set of the transaction group is verified based on the execution read-write set of the transactions included in each transaction group.

2. The method according to claim 1, wherein verifying the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group comprises: During the execution of each transaction, the pre-execution read set of the transaction group to which the transaction belongs is verified using the execution read set of the transaction.

3. The method according to claim 1, wherein verifying the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group comprises: After the parallel execution of the multiple transactions is completed, an execution read-write set for each transaction group is generated based on the execution read-write set of the transactions included in each transaction group, and the pre-execution read-write set of each transaction group is verified based on the execution read-write set of each transaction group.

4. The method according to any one of claims 1-3, wherein the master node pre-executes multiple transactions comprising: The master node pre-executes the multiple transactions based on the pre-execution state set. The method further includes: after pre-executing each transaction, the master node sequentially processes each transaction as follows: determining whether the pre-execution read set of the transaction conflicts with the pre-execution state set; wherein, if it is determined that there is no conflict for the first pre-executed transaction, the pre-execution state set is updated based on the pre-execution read / write set of the first transaction, and the order of the first transaction is recorded in the pre-execution transaction set; wherein the order of transactions in each transaction group is determined based on the order of transactions in each transaction group in the pre-execution transaction set.

5. The method according to claim 4, further comprising: The master node sends the order of the multiple transactions in the pre-execution transaction set to the slave node. If the verification fails, the slave node executes the multiple transactions serially according to their order in the pre-execution transaction set.

6. The method according to claim 4, wherein, The master node pre-executes the multiple transactions based on the pre-execution state set, including: when the master node reads the first variable in the pre-execution of any transaction, it determines whether the value of the first variable is stored in the pre-execution state set; if it determines that the value of the first variable is not stored in the pre-execution state set, it reads the value of the first variable from the state database.

7. The method according to claim 4, wherein, Determining whether the pre-execution read set of the transaction conflicts with the pre-execution state set includes determining whether the pre-execution state set includes a second variable in the pre-execution read set of the transaction. If the pre-execution state set includes the second variable, determining whether the value of the second variable in the pre-execution state set is consistent with the value of the second variable in the pre-execution read set. If they are inconsistent, then it is determined that the pre-execution read set of the transaction conflicts with the pre-execution state set.

8. A method for executing transactions in a blockchain system, the blockchain system comprising a master node and slave nodes, the method being executed by the slave node, comprising: The master node receives the grouping results obtained by grouping multiple transactions and the pre-execution read / write set of each transaction group, wherein the pre-execution read / write set of each transaction group is generated based on the pre-execution read / write set of each transaction included in the transaction group; Before executing the multiple transactions, the pre-execution read-write set of the multiple transaction groups is used to verify whether the transaction groups in the multiple transaction groups access the same variables. If not, the verification is confirmed to be successful. In the event that the verification fails, the multiple transactions are executed sequentially in the order proposed in the consensus proposal; If the verification is successful, the multiple transactions are executed in parallel according to the grouping results to obtain the execution read and write set of the transactions included in each transaction group; The pre-execution read-write set of the transaction group is verified based on the execution read-write set of the transactions included in each transaction group.

9. The method according to claim 8, wherein verifying the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group comprises: During the execution of each transaction, the pre-execution read set of the transaction group to which the transaction belongs is verified using the execution read set of the transaction.

10. The method according to claim 9, wherein verifying the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group further comprises: After the parallel execution of the multiple transactions is completed, the execution write set of each transaction group is obtained based on the execution read and write sets of the transactions included in each transaction group, and the pre-execution write set of each transaction group is verified based on the execution write set of each transaction group.

11. A slave node device for a blockchain system, comprising: The receiving unit is configured to receive from the master node of the blockchain system the grouping result obtained by grouping multiple transactions and the pre-execution read-write set of each transaction group, wherein the pre-execution read-write set of the transaction group is generated based on the pre-execution read-write set of each transaction included in the transaction group; The verification unit is used to verify, before the slave node device executes the multiple transactions, whether the transaction groups in the multiple transaction groups access the same variable based on the pre-execution read-write set of the multiple transaction groups; if not, the verification is confirmed to be successful. An execution unit is configured to execute the multiple transactions sequentially in the order of the consensus proposal if the verification fails; and to execute the multiple transactions in parallel according to the grouping results if the verification passes, thereby obtaining the execution read / write set of the transactions included in each transaction group. The verification unit is further configured to verify the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group.

12. A blockchain system, comprising master nodes and slave nodes, The master node is used to: pre-execute multiple transactions to obtain a pre-execution read-write set for each transaction; group the multiple transactions according to the pre-execution read-write sets to obtain multiple transaction groups, and generate a pre-execution read-write set for each transaction group; and send the grouping results and the pre-execution read-write sets for each transaction group to the slave nodes. The slave node is used to: before executing the multiple transactions, verify whether the transaction groups in the multiple transaction groups access the same variables based on the pre-execution read-write set of the multiple transaction groups, and confirm that the verification is successful if not; if the verification fails, execute the multiple transactions serially according to the order in the consensus proposal; if the verification is successful, execute the multiple transactions in parallel according to the grouping result to obtain the execution read-write set of the transactions included in each transaction group, and verify the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group.

13. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 8-10.

14. A blockchain node device, comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 8-10.

Images