Methods for executing transactions, blockchain, master nodes and slave nodes

Abstract

A method for executing transactions in a blockchain, a blockchain, a master node, and a slave node. The method includes: the master node pre-executes a received first transaction to generate a pre-execution read-write set of the first transaction, wherein the pre-execution read-write set includes access to a first variable; the master node generates DAG data based on the pre-execution read-write set of the first transaction and the identifier of a second transaction that has been previously recorded and has most recently updated the first variable, wherein the second transaction is the most recent transaction before the pre-execution of the first transaction and updates the pre-execution state of the first variable after the pre-execution, and the DAG data indicates the time sequence of the first transaction and the second transaction accessing the first variable; the master node sends the DAG data to the slave node; and the slave node executes the first transaction and the second transaction based on the DAG data.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and more particularly to a method for executing transactions in a blockchain, a blockchain, a master node, and a slave node. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time order, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application. However, since the variables accessed by the transaction calling the smart contract cannot be predicted before execution, it is usually not executed in parallel. Summary of the invention

[0003] The object of the present invention is to provide a method for executing transactions in a blockchain, so that slave nodes in the blockchain can execute transactions in parallel according to the consensus proposal of the master node.

[0004] In a first aspect, the present specification provides a method for executing a transaction in a blockchain, wherein the blockchain includes a master node and a slave node, and the method includes:

[0005] The master node pre-executes the received first transaction to generate a pre-execution read-write set of the first transaction, wherein the pre-execution read-write set includes access to a first variable;

[0006] The master node generates DAG data according to the pre-execution read-write set of the first transaction and the identifier of the second transaction that has been previously recorded and has most recently updated the first variable, wherein the second transaction is the most recent transaction before pre-execution of the first transaction and updates the pre-execution state of the first variable after pre-execution, and the DAG data indicates a time sequence in which the first transaction and the second transaction access the first variable;

[0007] The master node sends the DAG data to the slave node;

[0008] The slave node executes the first transaction and the second transaction based on the DAG data.

[0009] A second aspect of the present specification provides a blockchain, wherein the blockchain includes a master node and a slave node.

[0010] The master node is used to: pre-execute a received first transaction to generate a pre-execution read-write set of the first transaction, wherein the pre-execution read-write set includes access to a first variable; generate DAG data according to the pre-execution read-write set of the first transaction and an identifier of a second transaction that has been previously recorded and has most recently updated the first variable, wherein the second transaction is a transaction that has most recently updated the pre-execution state of the first variable before the pre-execution of the first transaction, and the DAG data indicates a time sequence in which the first transaction and the second transaction access the first variable; and send the DAG data to the slave node;

[0011] The slave node is used to execute the first transaction and the second transaction based on the DAG data.

[0012] The third aspect of this specification provides a blockchain master node, including:

[0013] A pre-execution unit, configured to pre-execute a received first transaction and generate a pre-execution read-write set of the first transaction, wherein the pre-execution read-write set includes access to a first variable;

[0014] a generating unit, configured to generate DAG data according to a pre-execution read-write set of the first transaction and an identifier of a second transaction that is previously recorded and most recently updates the first variable, wherein the second transaction is a transaction that is most recently executed before the pre-execution of the first transaction and updates a pre-execution state of the first variable after the pre-execution, and the DAG data indicates a time sequence in which the first transaction and the second transaction access the first variable;

[0015] A sending unit is used to send the DAG data to a slave node of the blockchain.

[0016] A fourth aspect of this specification provides a blockchain slave node, including:

[0017] A receiving unit, configured to receive DAG data from a master node of the blockchain, wherein the DAG data indicates a time sequence in which a first transaction and a second transaction access a first variable;

[0018] An execution unit, configured to execute the first transaction and the second transaction based on the DAG data.

[0019] Through the solution for executing transactions in the blockchain provided by the embodiments of this specification, the slave nodes can execute non-conflicting transactions in parallel according to the DAG data generated by the master node, and the conflicting transactions can be executed sequentially according to the order in the DAG data, thereby improving the transaction execution efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use 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 ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

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

[0022] Figure 2 This is a flow chart of a method for executing transactions in a blockchain in an embodiment of this specification;

[0023] Figure 3 is a DAG graph in an embodiment of this specification;

[0024] Figure 4 This is an architecture diagram of a blockchain master node in an embodiment of this specification;

[0025] Figure 5 This is an architecture diagram of a blockchain slave node in one embodiment of this specification. DETAILED DESCRIPTION

[0026] In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0027] Figure 1 The following is a diagram showing the blockchain architecture used in the embodiments of this specification. Figure 1 In the example, the blockchain includes 6 nodes, namely, master node 1, slave node 2 to slave node 6. The lines between the nodes schematically represent P2P (Peer to Peer) connections. These nodes store the full amount of ledgers, that is, the status of all blocks and all accounts. Among them, each node in the blockchain generates the same state in the blockchain by executing the same transaction, and each node in the blockchain stores the same state database. The difference is that the master node 1 can be responsible for receiving transactions from the client and initiating a consensus proposal to each slave node. The consensus proposal includes, for example, multiple transactions in the block to be formed (such as block B1) and the submission order of each transaction. After the nodes in the blockchain successfully reach a consensus on the consensus proposal, each node can execute the multiple transactions according to the submission order in the consensus proposal, thereby generating block B1.

[0028] Understandably, Figure 1 The blockchain shown is only exemplary and the embodiments of this specification are not limited to application to Figure 1 The blockchain shown, for example, can also be applied to a blockchain system including shards.

[0029] in addition, Figure 1 Although it is shown that the blockchain includes 6 nodes, the embodiments of this specification are not limited to this, but may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet the Byzantine Fault Tolerance (BFT) requirements. The Byzantine Fault Tolerance requirement can be understood as Byzantine nodes can exist inside the blockchain, but the blockchain does not reflect Byzantine behavior to the outside. In general, some Byzantine fault tolerance algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes, such as the practical Byzantine fault tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).

[0030] Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. Transactions usually include a send field (From), a receive field (To), and a data field (Data). Among them, in the case where the transaction is a transfer transaction, the From field indicates the account address that initiates the transaction (i.e., initiates a transfer task to another account), the To field indicates the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount. In the case where the transaction calls a smart contract in the blockchain, the From field indicates the account address that initiates the transaction, the To field indicates the account address of the contract called by the exchange, and the Data field includes the function name in the calling contract, and the incoming parameters of the function, etc., which are used to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.

[0031] The blockchain can provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in Ethereum is to initiate a transaction pointing to the smart contract address, so that each node in the Ethereum network runs the smart contract code in a distributed manner. It should be noted that in addition to being able to create smart contracts by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a genesis contract. Generally, some blockchain data structures, parameters, properties and methods can be set in the genesis contract. In addition, accounts with system administrator privileges can create system-level contracts or modify system-level contracts (referred to as system contracts). Among them, the system contract can be used to add data structures of data for different businesses in the blockchain.

[0032] In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (i.e. deploying a contract) to Figure 1 In the blockchain shown, the data field of the transaction includes the code of the contract to be created (such as bytecode or machine code), and the to field of the transaction is empty to indicate that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93..." of the contract is determined, and each node adds a contract account corresponding to the contract address of the smart contract in the state database, allocates the state storage corresponding to the contract account, and saves the contract code in the state storage of the contract, so that the contract is successfully created.

[0033] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to Figure 1 In the blockchain shown, the from field of the transaction is the address of the account of the transaction initiator (i.e. Bob), the "0x6f8ae93..." in the to field represents the address of the smart contract being called, and the data field of the transaction includes the method and parameters for calling the smart contract. After the transaction is reached in the blockchain, each node in the blockchain can execute the transaction separately, thereby executing the contract separately, and updating the status database based on the execution of the contract.

[0034] In the related art, in order to improve the transaction execution per second (TPS) indicator in the blockchain, it is necessary to speed up the execution speed of transactions. To this end, the execution speed of transactions can be accelerated by executing transactions in parallel in the blockchain node. In one embodiment, the blockchain node can execute transactions in parallel through multiple processes in a single machine. In another embodiment, the blockchain node can be deployed in a server cluster and execute transactions in parallel through multiple servers. Usually, for transfer transactions, the blockchain node first divides multiple transactions into multiple transaction groups according to the accounts accessed by the transactions. The same accounts are not accessed between the transaction groups, so that each transaction group can be executed in parallel. However, when a smart contract is called in a transaction, the variables accessed in the transaction cannot be predicted before the transaction is executed, so that multiple transactions cannot be effectively grouped, and transactions cannot be executed in parallel.

[0035] In another related technology, the master node can execute transactions and send the execution results to the slave nodes for verification. In order to speed up the verification stage, the master node will only package non-conflicting transactions during execution and postpone the conflicting transactions to the next block, so that the slave nodes can achieve concurrent verification. However, in this method, when the conflict rate between transactions is high, these transactions will be placed in different blocks, which reduces system performance and increases storage costs.

[0036] Figure 2is a flow chart of a method for executing a transaction in a blockchain in an embodiment of this specification. The method may be performed by Figure 1 The master node and each slave node are executed as shown. Figure 2 The master node 1 and the slave node 2 are shown as examples. It can be understood that other slave nodes in the blockchain perform the same operations as the slave node 2.

[0037] like Figure 2 As shown, in step S201, the master node pre-executes the received transaction and generates a pre-execution read-write set of the transaction.

[0038] The pre-execution refers to the execution of transactions by the master node before making a consensus proposal. Before making a consensus proposal, the master node 1 has not set the submission order of each transaction, and the master node 1 can pre-execute transactions in any order. For example, the master node 1 can pre-execute each received transaction in the order in which each transaction is received, or the master node 1 can also pre-execute multiple transactions in parallel after receiving multiple transactions at the same time.

[0039] During the pre-execution of transactions, the master node 1 maintains the latest state set of variables (hereinafter referred to as the pre-execution state set) according to the read and write operations of each transaction on the variables, and pre-executes the transaction according to the pre-execution state set.

[0040] For example, transaction Txi includes a read operation on variable A and a write operation on variable B. When master node 1 pre-executes transaction Txi, when executing the read operation on variable A, it determines whether the pre-execution state set contains the value of variable A. If not, it reads the value of variable A from the state database, records the key-value pair of variable A in the pre-execution read set of transaction Txi, and stores the read value of variable A in the pre-execution state set. If the pre-execution state set contains the value of variable A, it directly reads the value of variable A from the pre-execution state set, and records the key-value pair of variable A in the pre-execution read set of transaction Txi. When master node 1 executes the write operation on variable B, it records the key-value pair of variable B in the pre-execution write set of transaction Txi. Thus, the pre-execution read-write set of transaction Txi is obtained.

[0041] After completing the pre-execution of transaction Txi, master node 1 determines whether the pre-execution read set of transaction Txi is consistent with the variable values ​​in the pre-execution status set. If they are inconsistent, it means that there is a conflict between transaction Txi and other previously pre-executed transactions, and transaction Txi is re-pre-executed. If they are consistent, the pre-execution status set is updated according to the pre-execution read-write set of transaction Txi, that is, the key-value pair of variable B in the pre-execution read-write set is updated to the pre-execution status set.

[0042] In step S203, the master node generates directed acyclic graph (DAG) data between transactions based on the pre-execution read-write set of the transaction and the identifier of the previously recorded transaction (hereinafter referred to as the most recent transaction) that most recently updated the transaction access variable (the pre-execution state) through pre-execution before the pre-execution of the transaction, indicating the time sequence of the transaction accessing the variable.

[0043] The DAG data is data used to indicate the DAG relationship between transactions, which can be in the form of a graph, a table, a data form, etc., and is not limited to this. For example, the DAG data includes the DAG table of each transaction, and the DAG table of transaction Txi includes the successor transaction and the in-degree of transaction Txi, wherein the successor transaction refers to the transaction that accesses the variable (the variable is also the variable accessed by transaction Txi) in the time sequence after transaction Txi through pre-execution, and is the transaction directly pointed to from transaction Txi in the DAG graph. The in-degree refers to the number of transactions pointing to transaction TXi in the DAG graph.

[0044] Specifically, after the master node 1 completes the pre-execution of transaction Txi, for variable A, the master node 1 can determine the transaction that most recently updated variable A before the pre-execution of transaction Txi based on the recent transaction index of variable A. Assuming that the recent transaction is transaction Txj, the master node 1 can record transaction Txi as a subsequent transaction in the DAG table of transaction Txj, and increase the in-degree of transaction Txi by 1 in the DAG table of transaction Txi. If the master node 1 determines that there is no transaction that updates variable A before the pre-execution of transaction Txi based on the recent transaction index of variable A, the master node 1 can bind the recent transaction index of variable A to an empty transaction, and record the transaction Txi in association with the empty transaction to record that transaction Txi has read variable A.

[0045] For variable B, master node 1 can determine the transaction that most recently updated variable B before the pre-execution of transaction Txi based on the most recent transaction index of variable B. Assuming that the most recent transaction is Txk, master node 1 can determine whether Txk has a subsequent transaction based on the DAG table of transaction Txk. If there is a subsequent transaction Txm, master node 1 can record transaction Txi as a subsequent transaction in the DAG table of transaction Txm, increase the in-degree of transaction Txi by 1 in the DAG table of transaction Txi, and bind the most recent transaction index of variable B to transaction Txi. If master node 1 determines that Txk has no subsequent transaction based on the DAG table of transaction Txk, master node 1 can record transaction Txi as a subsequent transaction in the DAG table of transaction Txk, increase the in-degree of transaction Txi by 1 in the DAG table of transaction Txi, and bind the most recent transaction index of variable B to transaction Txi.

[0046] In one example, master node 1 first pre-executes transaction Tx1, which includes a read operation on variable A. After pre-execution of transaction Tx1, master node 1 sets the most recent transaction of variable A to an empty transaction, and records transaction Tx1 as the empty transaction. It can be concluded that the in-degree of transaction Tx1 is 0, and the DAG table of transaction Tx1 is recorded as shown in Table 1:

[0047] trade Subsequent transactions In-degree Tx1 {} 0

[0048] Table 1

[0049] Among them, "{}" in Table 1 means that the successor transaction set of Tx1 is an empty set, that is, there is no successor transaction.

[0050] Afterwards, master node 1 pre-executes transaction Tx2, which includes a read operation on variable A and a write operation on variable B. After master node 1 pre-executes transaction Tx2, it can be concluded that the recent transactions of variables A and B are both empty transactions based on the recent transaction indexes of variables A and B. Based on this, it can be concluded that the in-degree of transaction Tx2 is 0, and transaction Tx2 is associated with the recent empty transaction of variable A, and transaction Tx2 is recorded as the recent transaction of variable B. The DAG table of the currently pre-executed transactions is recorded as shown in Table 2:

[0051] trade Subsequent transactions In-degree Tx1 {} 0 Tx2 {} 0

[0052] Table 2

[0053] Afterwards, master node 1 pre-executes transaction Tx3, which includes a read operation on variable A and a read operation on variable B. After master node 1 completes pre-execution of transaction Tx3, it can be concluded that the most recent transaction of variable B is transaction Tx2 based on the most recent transaction indexes of variables A and B. That is to say, during the pre-execution process, transaction Tx3 accesses variable B after transaction Tx2 writes variable B. Based on this, the DAG relationship of transaction Tx2 pointing to transaction Tx3 can be recorded, for example, it can be recorded through an arrow in the DAG graph, or transaction Tx3 can be recorded as a subsequent transaction in the DAG table of transaction Tx2, and the in-degree can be increased by 1 in the DAG table of transaction Tx3 to indicate the execution order of transaction Tx3 and transaction Tx2, that is, transaction Tx3 is executed after transaction Tx2. For example, master node 1 can record the DAG table of the currently pre-executed transaction as shown in Table 3:

[0054] trade Subsequent transactions In-degree Tx1 {} 0 Tx2 {Tx3} 0 Tx3 {} 1

[0055] Table 3

[0056] By recording the DAG relationship between transaction Tx2 and transaction Tx3 in this way, and executing transactions Tx2 and Tx3 in the execution order indicated by the DAG relationship when executing transactions, the state changes when executing transactions Tx2 and Tx3 are consistent with those during pre-execution, thereby maintaining the correctness of the DAG relationship between each transaction, and multiple transactions with zero in-degree can be executed in parallel according to the DAG relationship, thereby improving the execution efficiency of transactions.

[0057] At the same time, Master Node 1 also records the association between transaction Tx3 and the most recent empty transaction of the above variable A.

[0058] Afterwards, master node 1 pre-executes transaction Tx4, which includes a write operation on variable A and a read operation on variable B. After pre-executing transaction Tx4, master node 1 can deduce that the associated transactions of the most recent empty transaction of variable A include transactions Tx1, Tx2, and Tx3 based on the most recent transaction index of variable A. Therefore, transaction Tx4 is recorded as the successor transaction of each of Tx1, Tx2, and Tx3 to indicate that transaction Tx4 is executed after Tx1, Tx2, and Tx3 are executed, thereby avoiding the execution results of each transaction being different from the pre-execution results due to read-write conflicts. Master node 1 can deduce that the most recent transaction of variable B is transaction Tx2 based on the most recent transaction index of variable B, so transaction Tx4 is recorded as the successor transaction of transaction Tx2. Master node 1 can record the DAG table of the currently pre-executed transactions as shown in Table 4:

[0059] trade Subsequent transactions In-degree Tx1 {Tx4} 0 Tx2 {Tx3,Tx4} 0 Tx3 {Tx4} 1 Tx4 {} 3

[0060] Table 4

[0061] At the same time, master node 1 also binds the most recent transaction index of variable A to transaction Tx4.

[0062] Afterwards, master node 1 pre-executes transaction Tx5, and transaction Tx4 includes a write operation on variable B. After master node 1 pre-executes transaction Tx5, it can be concluded that the most recent transaction of variable B is Tx2 according to the most recent transaction index of variable A, so transaction Tx5 can be recorded as the successor transaction of transaction Tx2's successor transactions (transactions Tx3 and Tx4). Master node 1 can record the DAG table of the currently pre-executed transactions as shown in Table 5:

[0063] trade Subsequent transactions In-degree Tx1 {Tx4} 0 Tx2 {Tx3,Tx4} 0 Tx3 {Tx4, Tx5} 1 Tx4 {Tx5} 3 Tx5 {} 2

[0064] Table 5

[0065] At the same time, master node 1 also binds the most recent transaction index of variable B to transaction Tx5. Based on the DAG relationship between the currently pre-executed transactions, the following can be drawn: Figure 3 The DAG graph shown corresponds to the DAG data shown in Table 5.

[0066] In step S205, the master node 1 sends the DAG data of multiple transactions to each slave node.

[0067] The master node 1 may pre-execute multiple transactions as described above, generate DAG data between the multiple transactions, and send the DAG data of the multiple transactions as a consensus proposal to each slave node. The master node 1 may also send the received multiple transactions to each slave node. It is understood that each slave node may also receive multiple transactions from other slave nodes or clients. Each slave node may also receive the DAG data of the multiple transactions from other slave nodes.

[0068] In addition to sending the DAG data of multiple transactions to each slave node, the master node 1 can also generate an executable transaction set with an in-degree of 0 based on the DAG data, and send the transaction set together to each slave node. For example, the master node 1 sends the DAG data shown in Table 5 to each slave node, and the master node 1 can obtain an executable transaction set including transaction Tx1 and transaction Tx2 based on the DAG data, and send the executable transaction set to each slave node. It can be understood that the master node 1 can also only send the DAG data of multiple transactions to each slave node, and each slave node can generate an executable transaction set based on the DAG data.

[0069] In step S207, the slave node executes the transaction based on the DAG data.

[0070] Taking slave node 2 as an example, after obtaining the executable transaction set based on DAG data, slave node 2 first executes the transactions in the executable transaction set. Since the in-degree of transactions in the executable transaction set is zero, that is, its execution will not conflict with other transactions, master node 1 can execute multiple transactions in the executable transaction set in parallel.

[0071] Specifically, reference Figure 3 , the executable transaction set initially includes transaction Tx1 and transaction Tx2. Slave node 2 can execute transaction Tx1 and transaction Tx2 in parallel. After completing the execution of transaction Tx1, slave node 2 can reduce the in-degree of transaction Tx4 by 1. After completing the execution of transaction Tx2, slave node 2 can reduce the in-degree of transaction Tx3 and transaction Tx4 by 1 in the DAG table, so that the in-degree of transaction Tx3 becomes 0. At this time, slave node 2 can put transaction Tx3 into the executable transaction set, that is, slave node 2 can execute transaction Tx3. After completing the execution of transaction Tx3, slave node 2 reduces the in-degree of transaction Tx4 and transaction Tx5 by 1, so that the in-degree of transaction Tx4 becomes 0. Similarly, slave node 2 can put transaction Tx4 into the executable transaction set.

[0072] Figure 4This is an architecture diagram of a blockchain master node in an embodiment of this specification, including:

[0073] A pre-execution unit 41 is configured to pre-execute a received first transaction and generate a pre-execution read-write set of the first transaction, wherein the pre-execution read-write set includes access to a first variable;

[0074] A generating unit 42 is configured to generate DAG data according to the pre-execution read-write set of the first transaction and an identifier of a second transaction that is previously recorded and most recently updates the first variable, wherein the second transaction is a transaction that is most recently executed before the pre-execution of the first transaction and updates the pre-execution state of the first variable after the pre-execution, and the DAG data indicates a time sequence in which the first transaction and the second transaction access the first variable;

[0075] The sending unit 43 is used to send the DAG data to the slave node of the blockchain.

[0076] In one embodiment, the pre-execution unit is specifically configured to pre-execute a received first transaction based on a pre-execution status set, and after pre-executing the first transaction, update the pre-execution status set based on a pre-execution read-write set of the first transaction.

[0077] In one implementation, the DAG data includes DAG tables of each of the multiple transactions that have been pre-executed, and the DAG table of each transaction includes the number of subsequent transactions and in-degree transactions of the transaction in the DAG graph.

[0078] In one embodiment, the pre-execution read-write set includes a read operation on the first variable, and the generation unit 42 is specifically used to: record the first transaction as a successor transaction of the second transaction in the DAG table of the second transaction, and increase the in-degree of the first transaction by 1 in the DAG table of the first transaction.

[0079] In one embodiment, the pre-execution read-write set includes a write operation on the first variable, and the generation unit 42 is specifically used to: read the DAG table of the second transaction, and in the case where the second transaction has a successor fourth transaction, record the first transaction as a successor transaction of the fourth transaction in the DAG table of the fourth transaction, increase the in-degree of the first transaction by 1 in the DAG table of the first transaction, and record the first transaction as the transaction that most recently updated the first variable.

[0080] In one embodiment, the generating unit 42 is specifically used to: when the second transaction has no subsequent transaction, record the first transaction as a subsequent transaction of the second transaction in the DAG table of the second transaction, increase the in-degree of the first transaction by 1 in the DAG table of the first transaction, and record the first transaction as the transaction that most recently updated the first variable.

[0081] In one embodiment, the master node further includes: an acquisition unit (not shown), configured to acquire a first set according to the DAG tables of the multiple transactions, wherein the first set includes transactions with zero in-degree among the multiple transactions,

[0082] The sending unit 43 is further configured to send the first set to the slave node.

[0083] Figure 5 This is an architecture diagram of a blockchain slave node in an embodiment of this specification, including:

[0084] A receiving unit 51 is used to receive DAG data from a master node of the blockchain, wherein the DAG data indicates a time sequence in which a first transaction and a second transaction access a first variable;

[0085] The execution unit 52 is configured to execute the first transaction and the second transaction based on the DAG data.

[0086] Through the solution for executing transactions in the blockchain provided by the embodiments of this specification, the slave nodes can execute non-conflicting transactions in parallel according to the DAG data generated by the master node, and the conflicting transactions can be executed sequentially according to the order in the DAG data, thereby improving the transaction execution efficiency.

[0087] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, 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, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0088] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

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

[0090] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

[0091] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0092] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0093] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0094] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0095] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0096] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0097] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0098] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present 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.

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

[0100] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0101] The above description is only an example of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims.

Claims

1. A method for executing a transaction in a blockchain system, the blockchain system comprising a master node and a slave node, the method comprising: The master node pre-executes the received first transaction to generate a pre-execution read-write set of the first transaction, wherein the pre-execution read-write set includes access to a first variable; The master node generates DAG data according to the pre-execution read-write set of the first transaction and the identifier of the second transaction that has been previously recorded and has most recently updated the first variable, wherein the DAG data includes DAG tables of each of the multiple transactions that have been pre-executed, and the DAG table of each transaction includes the number of subsequent transactions and in-degree transactions of the transaction in the DAG graph, the second transaction is the most recent transaction before the pre-execution of the first transaction and updates the pre-execution state of the first variable after the pre-execution, and the DAG data indicates the time sequence of the first transaction and the second transaction accessing the first variable; The master node sends the DAG data to the slave node; The slave node executes the first transaction and the second transaction based on the DAG data.

2. According to the method according to claim 1, the master node pre-executes the first transaction received, including: the master node pre-executes the first transaction received based on a pre-execution status set, and after pre-executing the first transaction, updates the pre-execution status set based on the pre-execution read-write set of the first transaction.

3. The method according to claim 1, wherein the pre-execution read-write set includes a read operation on the first variable, and the master node generates DAG data according to the pre-execution read-write set of the first transaction and an identifier of a second transaction that has been previously recorded and has most recently updated the first variable, comprising: The master node records the first transaction as a successor transaction of the second transaction in the DAG table of the second transaction, and increases the in-degree of the first transaction by 1 in the DAG table of the first transaction.

4. The method according to claim 1, wherein the pre-execution read-write set includes a read operation on the first variable, the second transaction identifier is an empty transaction identifier, and the master node generates DAG data according to the pre-execution read-write set of the first transaction and the identifier of the second transaction that most recently updated the first variable and was previously recorded, comprising: The master node records the identifier of the first transaction in association with the empty transaction identifier of the first variable; After completing pre-execution of the first transaction, the master node pre-executes the received third transaction to generate a pre-execution read-write set of the third transaction, where the pre-execution read-write set of the third transaction includes a write operation on the first variable; The master node records the third transaction as a successor transaction of the first transaction in the DAG table of the first transaction based on the pre-execution read-write set of the third transaction and the identifier of the first transaction recorded in association with the empty transaction identifier of the first variable, increases the in-degree of the third transaction by 1 in the DAG table of the third transaction, and records the third transaction as the transaction that most recently updates the first variable.

5. The method according to claim 1, wherein the pre-execution read-write set of the first transaction includes a write operation on the first variable, and the master node generates DAG data according to the pre-execution read-write set of the first transaction and an identifier of a second transaction that has been previously recorded and has most recently updated the first variable, comprising: The master node reads the DAG table of the second transaction, and in the case where the second transaction has a successor fourth transaction, records the first transaction as a successor transaction of the fourth transaction in the DAG table of the fourth transaction, increases the in-degree of the first transaction by 1 in the DAG table of the first transaction, and records the first transaction as the transaction that most recently updated the first variable.

6. The method according to claim 5, wherein the master node generates DAG data according to the pre-executed read-write set of the first transaction and the identifier of the second transaction that most recently updated the first variable and was previously recorded, further comprising: In the case that the second transaction has no successor transaction, the first transaction is recorded as a successor transaction of the second transaction in the DAG table of the second transaction, the in-degree of the first transaction is increased by 1 in the DAG table of the first transaction, and the first transaction is recorded as the transaction that most recently updated the first variable.

7. The method according to claim 1, further comprising: The master node obtains a first set according to the DAG tables of the multiple transactions, wherein the first set includes transactions with zero in-degree among the multiple transactions. The first set is sent to the slave node.

8. The method according to claim 7, wherein the first set includes the second transaction, the first transaction is a subsequent transaction of the second transaction, and the slave node executes the first transaction and the second transaction based on the DAG data, comprising: The slave nodes execute the transactions in the first set in parallel; After executing the second transaction, the in-degree of the first transaction is reduced by 1; In the case that the in-degree of the first transaction is reduced to 0, the first transaction is placed in the first set.

9. The method according to claim 2, wherein the pre-execution read-write set of the first transaction includes a read operation on a first variable, and the updating of the pre-execution state set based on the pre-execution read-write set of the first transaction includes: Determine whether the value of the first variable in the pre-execution read-write set is consistent with the value of the first variable in the pre-execution state set. If they are consistent, update the pre-execution state set based on the pre-execution read-write set of the first transaction. Generating DAG data includes generating DAG data in a consistent situation.

10. A blockchain system, comprising a master node and a slave node, The master node is used to: pre-execute a received first transaction to generate a pre-execution read-write set of the first transaction, wherein the pre-execution read-write set includes access to a first variable; generate DAG data according to the pre-execution read-write set of the first transaction and the identifier of a second transaction that has been previously recorded and has most recently updated the first variable, wherein the DAG data includes DAG tables of respective multiple transactions that have been pre-executed, wherein the DAG table of each transaction includes the number of subsequent transactions and in-degree transactions of the transaction in the DAG graph, wherein the second transaction is the most recent transaction before the pre-execution of the first transaction and updates the pre-execution state of the first variable after the pre-execution, and wherein the DAG data indicates the time sequence of the first transaction and the second transaction accessing the first variable; and send the DAG data to the slave node; The slave node is used to execute the first transaction and the second transaction based on the DAG data.

11. A master node of a blockchain system, comprising: A pre-execution unit, configured to pre-execute a received first transaction and generate a pre-execution read-write set of the first transaction, wherein the pre-execution read-write set includes access to a first variable; a generating unit, configured to generate DAG data according to the pre-execution read-write set of the first transaction and the identifier of the second transaction that has been previously recorded and has most recently updated the first variable, wherein the DAG data includes DAG tables of respective multiple transactions that have been pre-executed, wherein the DAG table of each transaction includes the number of subsequent transactions and in-degree transactions of the transaction in the DAG graph, wherein the second transaction is the most recent transaction before the pre-execution of the first transaction and updates the pre-execution state of the first variable after the pre-execution, and wherein the DAG data indicates a time sequence in which the first transaction and the second transaction access the first variable; A sending unit is used to send the DAG data to a slave node of the blockchain system.

12. According to the master node of claim 11, the pre-execution unit is specifically used to pre-execute the received first transaction based on the pre-execution status set, and after pre-execution of the first transaction is completed, update the pre-execution status set based on the pre-execution read-write set of the first transaction.

13. According to the master node of claim 11, the pre-execution read-write set includes a read operation on the first variable, and the generation unit is specifically used to: record the first transaction as a successor transaction of the second transaction in the DAG table of the second transaction, and increase the in-degree of the first transaction by 1 in the DAG table of the first transaction.

14. According to the master node of claim 11, the pre-execution read-write set includes a write operation on the first variable, and the generation unit is specifically used to: read the DAG table of the second transaction, and in the case where the second transaction has a successor fourth transaction, record the first transaction as a successor transaction of the fourth transaction in the DAG table of the fourth transaction, increase the in-degree of the first transaction by 1 in the DAG table of the first transaction, and record the first transaction as the transaction that most recently updated the first variable.

15. According to the master node of claim 14, the generation unit is specifically used to: in the case that the second transaction has no successor transaction, record the first transaction as the successor transaction of the second transaction in the DAG table of the second transaction, increase the in-degree of the first transaction by 1 in the DAG table of the first transaction, and record the first transaction as the transaction that most recently updated the first variable.

16. The master node according to claim 11, further comprising: an acquiring unit, configured to acquire a first set according to the DAG tables of the multiple transactions, wherein the first set includes transactions with an in-degree of zero among the multiple transactions, The sending unit is further configured to send the first set to the slave node.

17. A slave node of a blockchain system, comprising: A receiving unit, configured to receive DAG data from a master node of the blockchain system, wherein the DAG data includes a DAG table of each of a plurality of transactions that have been pre-executed, wherein the DAG table of each transaction includes a number of subsequent transactions and in-degree transactions of the transaction in the DAG graph, wherein the DAG data indicates a time sequence in which a first transaction and a second transaction access a first variable, wherein the DAG data is generated by the master node according to a pre-execution read-write set of the first transaction and an identifier of a second transaction that has been previously recorded and has most recently updated the first variable, wherein the pre-execution read-write set is generated by the master node when pre-executing the first transaction, and wherein the pre-execution read-write set includes access to the first variable; An execution unit, configured to execute the first transaction and the second transaction based on the DAG data.

Images