WO2023160085A1 - Method for executing transaction, blockchain, master node, and slave node - Google Patents

Abstract

A method for executing a transaction in a blockchain, a blockchain, a master node, and a slave node. The method comprises: a main 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 comprises access to a first variable; the master node generates DAG data according to the pre-execution read-write set of the first transaction and an identifier of a previously recorded second transaction which most recently updates the first variable, wherein the second transaction is the transaction which most recently updates a pre-execution state of the first variable after pre-execution before the first transaction is pre-executed, wherein the DAG data indicates a time sequence in which the first transaction and the second transaction access the first variable; the master node sends the DAG data to a slave node; and the slave node executes the first transaction and the second transaction on the basis of the DAG data.

Description

Method of executing transactions, blockchain, master and slave nodes

This application claims the priority of the Chinese patent application filed with the State Intellectual Property Office of China on February 25, 2022, with the application number 202210181705.2, and the application title is "method for executing transactions, blockchain, master node and slave node", which The entire contents are incorporated by reference in this application.

technical field

The embodiments of this specification belong to the technical field of block chain, and in particular relate to a method for executing transactions in the block chain, the block chain, a master node and a slave node.

Background technique

Blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, the data blocks are combined into a chained data structure in a sequentially connected manner in chronological order, and a non-tamperable and unforgeable distributed ledger is cryptographically guaranteed. Due to the characteristics of decentralization, non-tamperable information, and autonomy, the blockchain has also received more and more attention and application. However, since the variables accessed cannot be predicted before the transactions calling smart contracts are executed, they usually cannot be executed in parallel.

Contents of the invention

The purpose of the present invention is to provide a method for executing transactions in the block chain, so that the slave nodes in the block chain can execute transactions in parallel according to the consensus proposal of the master node.

The first aspect of this specification provides a method for executing a transaction in a blockchain, the blockchain includes a master node and a slave node, and the method includes:

The master node pre-executes the received first transaction, and generates a pre-execution read-write set of the first transaction, and the pre-execution read-write set includes access to the 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 previously recorded second transaction that most recently updated the first variable, and the second transaction is the The most recent transaction before the first transaction updates the pre-execution state of the first variable after pre-execution, and the DAG data indicates the time sequence in which the first transaction and the second transaction access 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.

The second aspect of this specification provides a blockchain, the blockchain includes a master node and a slave node,

The master node is used to: pre-execute the received first transaction, generate a pre-execution read-write set of the first transaction, and the pre-execution read-write set includes access to the first variable; The pre-execution read-write set, the identification of the second transaction that most recently updated the first variable recorded earlier, generates DAG data, and the second transaction is the most recent post-pre-execution update before the pre-execution of the first transaction A transaction in the pre-execution state of the first variable, the DAG data indicating the time sequence in which the first transaction and the second transaction access the first variable; sending the DAG data to the slave node;

The slave node is configured to execute the first transaction and the second transaction based on the DAG data.

The third aspect of this specification provides a block chain master node, including:

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

A generation unit, configured to generate DAG data according to the pre-execution read-write set of the first transaction and the identifier of the previously recorded second transaction that most recently updated the first variable, and the second transaction is the pre-execution A transaction that updates the pre-execution state of the first variable after pre-execution, the most recent before the first transaction, and the DAG data indicates the time sequence in which the first transaction and the second transaction access the first variable;

A sending unit, configured to send the DAG data to the slave nodes of the block chain.

The fourth aspect of this specification provides a blockchain slave node, including:

a receiving unit, configured to receive DAG data from the master node of the blockchain, the DAG data indicating the time sequence in which the first transaction and the second transaction access the first variable;

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

Through the scheme of executing transactions in the blockchain provided by the embodiment of this specification, the slave node can execute the transactions without conflicts in parallel according to the DAG data generated by the master node, and the transactions with conflicts can be executed according to the order in the DAG data Execution, thereby improving the efficiency of transaction execution.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following will briefly introduce the drawings that need to be used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in this specification. , for those skilled in the art, other drawings can also be obtained according to these drawings without paying creative labor.

FIG. 1 is a block chain architecture diagram applied in the embodiment of this specification;

FIG. 2 is a flow chart of a method for executing a transaction in a blockchain in an embodiment of this specification;

Fig. 3 is a DAG diagram in an embodiment of this specification;

FIG. 4 is an architecture diagram of a block chain master node in an embodiment of this specification;

Fig. 5 is an architecture diagram of a block chain slave node in an embodiment of this specification.

Detailed ways

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 The embodiments are only some of the embodiments in this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by persons of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

Fig. 1 shows a block chain architecture diagram applied in the embodiment of this specification. As shown in FIG. 1 , the blockchain includes, for example, 6 nodes including a master node 1, a slave node 2 to a slave node 6. The connection between nodes schematically represents a P2P (Peer to Peer, point-to-point) connection. These nodes store a full amount of books, that is, store the status of all blocks and all accounts. Wherein, 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 initiate 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 each Information such as the order in which transactions are submitted. After the nodes in the blockchain successfully reach consensus on the consensus proposal, each node can execute the multiple transactions according to the order of submission in the consensus proposal, thereby generating block B1.

It can be understood that the block chain shown in FIG. 1 is only exemplary, and the embodiment of this description is not limited to be applied to the block chain shown in FIG. 1 , for example, it can also be applied to a block chain system including sharding.

In addition, although it is shown in FIG. 1 that the block chain includes 6 nodes, the embodiment of this specification is not limited thereto, but may include other numbers of nodes. Specifically, the nodes contained in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements. The Byzantine fault tolerance requirement can be understood as that there may be Byzantine nodes inside the blockchain, but the blockchain does not reflect Byzantine behavior externally. Generally, some Byzantine fault-tolerant 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-tolerant algorithm PBFT (Practical Byzantine Fault Tolerance).

A transaction in the blockchain field may refer to a unit of tasks performed and recorded in the blockchain. A transaction usually includes a sending field (From), a receiving field (To) and a data field (Data). Among them, when the transaction is a transfer transaction, the From field indicates the account address that initiated the transaction (that is, initiates a transfer task to another account), the To field indicates the account address that received the transaction (that is, received the transfer), and the Data field Include the transfer amount. In the case of a transaction calling a smart contract in the blockchain, the From field indicates the account address that initiated the transaction, the To field indicates the account address of the contract called by the transaction, and the Data field includes the function name in the calling contract, and the Data such as the incoming parameters of the function are used to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.

The function of smart contracts can be provided in the blockchain. Smart contracts on the blockchain are contracts that can be triggered 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 address of the smart contract, 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 creating 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, attributes 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). Wherein, the system contract can be used to add data structures of different business data in the blockchain.

In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (that is, deploying a contract) to the blockchain shown in Figure 1, and the data field of the transaction includes the code of the contract to be created ( Such as bytecode or machine code), 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, determine the contract address "0x6f8ae93...", each node adds the 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 The contract code is saved in the state storage of the contract, so the contract is created successfully.

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

In related technologies, in order to improve the transaction per second (TPS) indicator in the blockchain, it is necessary to accelerate the execution speed of transactions. To this end, transactions can be executed in parallel in blockchain nodes to speed up transaction execution. In one implementation, the blockchain node can execute transactions in parallel through multiple processes in a single machine. In another implementation, the blockchain node can be deployed in a server cluster and execute transactions in parallel through multiple servers. Usually, for transfer transactions, blockchain nodes first divide multiple transactions into multiple transaction groups according to the accounts accessed by the transactions, and each transaction group does not access the same account, 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 multiple transactions cannot be effectively grouped, and transactions cannot be executed in parallel.

In another related technology, the master node can execute the transaction and send the execution result to the slave node for verification. In order to speed up the verification phase, the master node will only package non-conflicting transactions during execution and postpone conflicting transactions to The next block is packed so that 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.

Fig. 2 is a flow chart of a method for executing a transaction in a block chain in an embodiment of this specification, the method can be executed by the master node and each slave node shown in Fig. 1, and master node 1 and slave node 2 are shown in Fig. 2 As an example, it is understood that other slave nodes in the blockchain perform the same operations as slave node 2.

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

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

In the process of pre-executing the transaction, the master node 1 maintains the latest state set of variables (identified as the pre-execution state set hereinafter) according to the read and write operations of each transaction on the variable, and pre-executes the transaction according to the pre-execution state set.

For example, a transaction Txi includes a read operation on variable A and a write operation on variable B. When the master node 1 pre-executes the transaction Txi and executes the read operation on the variable A, it determines whether the pre-execution state set has the value of the variable A, if not, reads the value of the variable A from the state database, and in the transaction Txi The key-value pair of variable A is recorded in the pre-execution read set, and the read value of variable A is stored in the pre-execution state set. If the value of variable A is included in the pre-execution state set, variable A is directly read from the pre-execution state set The value of , record the key-value pair of variable A in the pre-execution read set of transaction Txi. When the master node 1 executes the write operation on the variable B, it records the key-value pair of the variable B in the pre-execution write set of the transaction Txi. Thus, the pre-executed read-write set of the transaction Txi is obtained.

After the master node 1 completes the pre-execution of the transaction Txi, it judges whether the pre-execution read set of the transaction Txi is consistent with the variable values in the pre-execution state set. If the pre-execution transaction Txi is consistent, update the pre-execution state set according to the pre-execution read-write set of the transaction Txi, that is, update the key-value pair of variable B in the pre-execution read-write set to the pre-execution state set.

In step S203, the master node identifies according to the pre-execution read-write set of the transaction, the previously recorded transaction (hereinafter referred to as the latest transaction) that recently updated the transaction access variable (the pre-execution state) through pre-execution before the transaction pre-execution , to generate Directed Acyclic Graph (DAG) data between transactions, indicating the chronological order in which transactions access variables.

The DAG data is data used to indicate the DAG relationship between transactions, which may be in the form of graphs, tables, data, etc., which is not limited. For example, the DAG data includes the DAG table of each transaction, and the DAG table of the transaction Txi includes the subsequent transactions and the in-degrees of the transaction Txi, wherein the subsequent transaction refers to a variable accessed through pre-execution (this variable is also a variable accessed by the transaction Txi) The transaction whose chronological order is after transaction Txi is the transaction directly pointed to from transaction Txi in the DAG graph. The in-degree refers to the number of transactions pointing to the transaction TXi in the DAG graph.

Specifically, after master node 1 pre-executes transaction Txi, for variable A, master node 1 can determine the transaction that most recently updated variable A before the pre-execution of transaction Txi according to the latest transaction index of variable A, assuming that the latest transaction is transaction Txj, then the master node 1 can record the transaction Txi as a subsequent transaction in the DAG table of the transaction Txj, and add 1 to the in-degree of the transaction Txi in the DAG table of the transaction Txi. If the master node 1 determines that there is no transaction to update the variable A before the pre-execution of the transaction Txi according to the latest transaction index of the variable A, the master node 1 can bind the latest transaction index of the variable A to the empty transaction and associate with the empty transaction Record the transaction Txi for recording that the transaction Txi reads the variable A.

For variable B, master node 1 can determine the transaction that updated variable B before the pre-execution of transaction Txi according to the latest transaction index of variable B. Assuming that the latest transaction is Txk, master node 1 can determine Txk according to the DAG table of transaction Txk Whether there is a subsequent transaction, if there is a subsequent transaction Txm, the master node 1 can record the transaction Txi as a subsequent transaction in the DAG table of the transaction Txm, add 1 to the in-degree of the transaction Txi in the DAG table of the transaction Txi, and set The latest transaction index of variable B is bound to transaction Txi. If the master node 1 determines that Txk has no subsequent transaction according to the DAG table of the transaction Txk, the master node 1 can record the transaction Txi as a subsequent transaction in the DAG table of the transaction Txk, and add the in-degree of the transaction Txi to the DAG table of the transaction Txk 1, and bind the latest transaction index of variable B to transaction Txi.

In one example, master node 1 first pre-executes transaction Tx1, which includes a read operation on variable A. After pre-executing transaction Tx1, the master node 1 sets the latest transaction of variable A as an empty transaction, and sets transaction Tx1 as the associated record of the empty transaction. Based on this, it can be concluded that the in-degree of transaction Tx1 is 0, and as shown in Table 1 Show the DAG table that records transaction Tx1:

trade	Subsequent transaction	In-degree
Tx1	{}	0

Table 1

Wherein, "{}" in Table 1 indicates that the subsequent transaction set of Tx1 is an empty set, that is, there is no subsequent transaction.

Afterwards, the master node 1 pre-executes the transaction Tx2, and the transaction Tx2 includes a read operation on variable A and a write operation on variable B. After the master node 1 pre-executes and completes the transaction Tx2, according to the recent transaction indexes of variable A and variable B, it can be concluded that the latest transactions of variable A and variable B are all empty transactions, and the in-degree of transaction Tx2 can be concluded as 0. And record transaction Tx2 with the latest empty transaction of the above variable A, record transaction Tx2 as the latest transaction of variable B, and record the DAG table of the currently pre-executed completed transaction as shown in Table 2:

trade	Subsequent transaction	In-degree
Tx1	{}	0
Tx2	{}	0

Table 2

Afterwards, master node 1 pre-executes transaction Tx3, and transaction Tx3 includes a read operation on variable A and a read operation on variable B. After the master node 1 pre-executes and completes transaction Tx3, according to the latest transaction index of variable A and variable B, it can be concluded that the latest transaction of variable B is transaction Tx2. That is to say, during the pre-execution process, transaction Tx3 accesses variable B after transaction Tx2 writes variable B, so that the DAG relationship of transaction Tx2 pointing to transaction Tx3 can be recorded. In the DAG table of Tx2, transaction Tx3 is recorded as a subsequent transaction, and the in-degree is added to the DAG table of transaction Tx3 by 1 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 transactions as shown in Table 3:

trade	Subsequent transaction	In-degree
Tx1	{}	0
Tx2	{Tx3}	0
Tx3	{}	1

table 3

By recording the DAG relationship between transaction Tx2 and transaction Tx3 in this way, and executing the transaction Tx2 and transaction Tx3 according to the execution sequence indicated by the DAG relationship when executing the transaction, so that the state changes when executing transaction Tx2 and transaction Tx3 are consistent with the pre-execution, Therefore, the correctness of the DAG relationship among the various transactions is maintained, and multiple transactions with an in-degree of zero can be executed in parallel according to the DAG relationship, thereby improving the execution efficiency of the transactions.

At the same time, the master node 1 also associates transaction Tx3 with the most recent empty transaction of the above-mentioned variable A.

Afterwards, the master node 1 pre-executes the transaction Tx4, and the transaction Tx4 includes a write operation to variable A and a read operation to variable B. After master node 1 pre-executes and completes transaction Tx4, according to the latest transaction index of variable A, it can be concluded that the related transactions of variable A’s recent empty transaction include transactions Tx1, Tx2 and Tx3, so transaction Tx4 is recorded as Tx1, Tx2 and Tx3 respectively Subsequent transactions to indicate that transaction Tx4 is executed after the execution of Tx1, Tx2 and Tx3 is completed, so as to avoid the execution results of each transaction being different from the pre-execution results due to read-write conflicts. According to the latest transaction index of variable B, master node 1 can conclude that the latest transaction of variable B is transaction Tx2, so it records transaction Tx4 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:

trade	Subsequent transaction	In-degree
Tx1	{Tx4}	0
Tx2	{Tx3,Tx4}	0
Tx3	{Tx4}	1
Tx4	{}	3

Table 4

At the same time, master node 1 also binds the latest transaction index of variable A to transaction Tx4.

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

trade	Subsequent transaction	In-degree
Tx1	{Tx4}	0
Tx2	{Tx3,Tx4}	0
Tx3	{Tx4, Tx5}	1
Tx4	{Tx5}	3
Tx5	{}	2

table 5

At the same time, master node 1 also binds the latest transaction index of variable B with transaction Tx5. According to the DAG relationship among the currently pre-executed completed transactions, a DAG diagram as shown in FIG. 3 can be drawn, and the DAG diagram corresponds to the DAG data shown in Table 5.

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

The master node 1 may pre-execute multiple transactions as described above, generate DAG data among the multiple transactions, and send the DAG data of the multiple transactions to each slave node as a consensus proposal. Master node 1 can also send multiple received transactions to each slave node. It can be 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 plurality of transactions from other slave nodes.

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 according to the DAG data, and send the transaction set to each slave node together. For example, master node 1 sends the DAG data shown in Table 5 to each slave node, master node 1 can obtain an executable transaction set including transaction Tx1 and transaction Tx2 according to the DAG data, and send the executable transaction set to each slave node 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 according to the DAG data.

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

Taking the slave node 2 as an example, after the slave node 2 obtains the executable transaction set based on the DAG data, it first executes the transactions in the executable transaction set. Since the in-degrees of the transactions in the executable transaction set are all zero, that is, their execution will not conflict with other transactions, therefore, the master node 1 can execute multiple transactions in the executable transaction set in parallel.

Specifically, referring to FIG. 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 the slave node 2 completes the execution of the transaction Tx1, it can subtract 1 from the in-degree in the DAG table of the transaction Tx4. After the slave node 2 completes the execution of the transaction Tx2, the in-degrees of the transaction Tx3 and the transaction Tx4 can be respectively reduced by 1 in the DAG table, so that the in-degrees of the transaction Tx3 become 0. At this time, the slave node 2 can The transaction Tx3 is put into the executable transaction set, that is, the slave node 2 can execute the transaction Tx3. After completing the execution of transaction Tx3, slave node 2 will decrease the in-degrees of transaction Tx4 and transaction Tx5 by 1, so that the in-degrees of transaction Tx4 will become 0. Similarly, slave node 2 can put transaction Tx4 into the executable transaction set middle.

Fig. 4 is an architecture diagram of a block chain master node in an embodiment of this specification, including:

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

The generation unit 42 is configured to generate DAG data according to the pre-execution read-write set of the first transaction and the identifier of the previously recorded second transaction that most recently updated the first variable, and the second transaction is the pre-execution The most recent transaction before the first transaction that updates the pre-execution state of the first variable after pre-execution, and the DAG data indicates the chronological order in which the first transaction and the second transaction access the first variable ;

A sending unit 43, configured to send the DAG data to the slave nodes of the block chain.

In one embodiment, the pre-execution unit is specifically configured to pre-execute the received first transaction based on the pre-execution state set, and after the pre-execution completes the first transaction, based on the pre-execution read of the first transaction A write set updates the pre-execution state set.

In one embodiment, the DAG data includes DAG tables of multiple transactions that have been pre-executed, and the DAG table of each transaction includes the number of subsequent transactions and inbound transactions of the transaction in the DAG graph.

In one embodiment, the pre-execution read-write set includes a read operation on the first variable, and the generation unit 42 is specifically configured to: add the first transaction to the DAG table of the second transaction Recording as a subsequent transaction of the second transaction, adding 1 to the in-degree of the first transaction in the DAG table of the first transaction.

In one embodiment, the pre-execution read-write set includes a write operation on the first variable, and the generating unit 42 is specifically configured to: read the DAG table of the second transaction, and in the second Where the transaction has a subsequent fourth transaction, record the first transaction as the successor transaction of the fourth transaction in the DAG table of the fourth transaction, and record all the subsequent transactions in the DAG table of the first transaction The in-degree of the first transaction is increased by 1, and the first transaction is recorded as the transaction for which the first variable is updated most recently.

In one embodiment, the generating unit 42 is specifically configured to: record the first transaction as the second transaction in the DAG table of the second transaction when the second transaction has no subsequent transaction For the subsequent transaction of the second transaction, add 1 to the in-degree of the first transaction in the DAG table of the first transaction, and record the first transaction as the transaction that most recently updated the first variable.

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

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

Fig. 5 is an architecture diagram of a block chain slave node in an embodiment of this specification, including:

A receiving unit 51, configured to receive DAG data from the master node of the blockchain, the DAG data indicating the time sequence in which the first transaction and the second transaction access the first variable;

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

Through the scheme of executing transactions in the blockchain provided by the embodiment of this specification, the slave node can execute the transactions without conflicts in parallel according to the DAG data generated by the master node, and the transactions with conflicts can be executed according to the order in the DAG data Execution, thereby improving the efficiency of transaction execution.

In the 1990s, the improvement of a technology can be clearly distinguished as an improvement in hardware (for example, improvements in circuit structures such as diodes, transistors, and switches) or improvements in software (improvement in method flow). However, with the development of technology, the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules. For example, a programmable logic device (Programmable Logic Device, PLD) (such as a field programmable gate array (Field Programmable Gate Array, FPGA)) is such an integrated circuit, the logic function of which is determined by the user's programming of the device. It is programmed by the designer to "integrate" a digital system on a PLD, instead of asking a chip manufacturer to design and make a dedicated integrated circuit chip. Moreover, nowadays, instead of making integrated circuit chips by hand, this kind of programming is mostly realized by "logic compiler (logic compiler)" software, which is similar to the software compiler used when program development and writing, but before compiling The original code of the computer must also be written in a specific programming language, which is called a hardware description language (Hardware Description Language, HDL), and there is not only one kind of 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., are currently the most commonly used The most popular are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logical programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain a hardware circuit for realizing the logic method flow.

The controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), 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 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 realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.

The systems, devices, modules, or units described in the above embodiments can be specifically 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 future computer technology, the computer that realizes the functions of the above embodiments can 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 , media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

Although one or more embodiments of the present specification provide the operation steps of the method described in the embodiment or the flowchart, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps enumerated in the embodiments is only one of the execution sequences of many steps, and does not represent the only execution sequence. When an actual device or terminal product is executed, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (such as a parallel processor or multi-thread processing environment, or even a distributed data processing environment). The term "comprising", "comprising" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, product, or apparatus comprising a set of elements includes not only those elements, but also other elements not expressly listed elements, or also elements inherent in such a process, method, product, or apparatus. Without further limitations, it is not excluded that there are additional identical or equivalent elements in a process, method, product or device comprising said elements. For example, if the words first, second, etc. are used, they are used to indicate names and do not indicate any particular order.

For the convenience of description, when describing the above devices, functions are divided into various modules and described separately. Of course, when implementing one or more of the present specification, the functions of each module can be realized in the same or more software and/or hardware, and the modules that realize the same function can also be realized by a combination of multiple submodules or subunits, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated. to another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The present 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 should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

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

Memory may include non-permanent storage in computer readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, 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 Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

Those skilled in the art should understand that one or more embodiments of this specification may be provided as a method, system or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. The form of the product.

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

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment 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 for relevant parts, refer to part of the description of the method embodiment. In the description of this specification, descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific examples", or "some examples" mean that specific features described in connection with the embodiment or example , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the described specific features, structures, materials or characteristics may be combined in any suitable manner in any one or more embodiments or examples. In addition, those skilled in the art can combine and combine different embodiments or examples and features of different embodiments or examples described in this specification without conflicting with each other.

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, various modifications and changes may occur in one or more embodiments of this description. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims (19)

1. A method of executing a transaction in a blockchain, the blockchain comprising a master node and a slave node, the method comprising:

   The master node pre-executes the received first transaction, and generates a pre-execution read-write set of the first transaction, and the pre-execution read-write set includes access to the first variable;

   The master node generates directed acyclic graph DAG data according to the pre-executed read-write set of the first transaction and the identifier of the previously recorded second transaction that most recently updated the first variable, and the second transaction is The most recent transaction prior to pre-execution of said first transaction that updates the pre-execution state of said first variable after pre-execution, said DAG data indicating that said first transaction and said second transaction access said first variable time sequence;

   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, said master node pre-executing the received first transaction comprises: said master node pre-executing the received first transaction based on the pre-execution state set, and after the pre-execution completes the first transaction, The pre-execution state set is updated based on the pre-execution read-write set of the first transaction.
3. The method according to claim 1 or 2, wherein the DAG data includes the respective DAG tables of multiple transactions that have been pre-executed, and the DAG table of each transaction includes the subsequent transactions and input of the transaction in the DAG graph. number of transactions.
4. The method according to claim 3, wherein the pre-execution read-write set includes a read operation on the first variable, and the master node according to the pre-execution read-write set of the first transaction, the latest update of the previous record The identification of the second transaction of the first variable, generating DAG data includes:

   The master node records the first transaction as a subsequent transaction of the second transaction in the DAG table of the second transaction, and records the in-degree of the first transaction in the DAG table of the first transaction plus 1.
5. According to the method according to claim 3, the pre-execution read-write set includes the read operation of the first variable, the second transaction identifier is an empty transaction identifier, and the master node pre-executes according to the first transaction Executing the read-write set, the previously recorded identification of the second transaction that most recently updated the first variable, and generating DAG data includes:

   The master node records the identifier of the first transaction in association with the empty transaction identifier of the first variable;

   After the pre-execution of the first transaction is completed, the master node pre-executes the received third transaction to generate a pre-execution read-write set of the third transaction, and the pre-execution read-write set of the third transaction includes all The write operation of the first variable;

   According to 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, the master node stores the all in the DAG table of the first transaction The third transaction is recorded as the successor transaction of the first transaction, and the in-degree of the third transaction is added to the DAG table of the third transaction by 1, and the third transaction is recorded as the latest update of the first transaction. Variable transactions.
6. According to the method according to claim 3, the pre-execution read-write set of the first transaction includes a write operation on the first variable, and the master node according to the pre-execution read-write set of the first transaction, prior The identifier of the second transaction that most recently updated the first variable is recorded, and the DAG data generation includes:

   The master node reads the DAG table of the second transaction, and in the case where the second transaction has a subsequent fourth transaction, records the first transaction in the DAG table of the fourth transaction as the For the subsequent transaction of the fourth transaction, add 1 to the in-degree of the first transaction in the DAG table of the first transaction, and record the first transaction as the transaction that most recently updated the first variable.
7. According to the method according to claim 6, the generation of DAG data by the master node according to the pre-executed read-write set of the first transaction and the identifier of the previously recorded second transaction that most recently updated the first variable further includes: In the case that the second transaction has no successor transaction, the first transaction is recorded in the DAG table of the second transaction as the successor transaction of the second transaction, and in the DAG table of the first transaction Adding 1 to the in-degree of the first transaction, and recording the first transaction as the latest update of the first variable.
8. The method according to claim 3, further comprising:

   The master node obtains a first set according to the respective DAG tables of the multiple transactions, and the first set includes transactions whose in-degrees are zero among the multiple transactions,

   Sending the first set to the slave node.
9. The method according to claim 8, 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 second transaction based on the DAG data A transaction and said second transaction include:

   The slave node executes the transactions in the first set in parallel; after executing the second transaction, the in-degree of the first transaction is decremented by 1; when the in-degree of the first transaction is reduced to 0 In case, the first transaction is put into the first set.
10. 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 pre-execution state set is updated based on the pre-execution read-write set of the first transaction Including: determining 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, and if they are consistent, pre-execution based on the first transaction The read-write set updates the pre-execution state set, and the generating DAG data includes generating DAG data in a consistent situation.
11. A blockchain comprising a master node and a slave node,

    The master node is used to: pre-execute the received first transaction, generate a pre-execution read-write set of the first transaction, and the pre-execution read-write set includes access to the first variable; The pre-execution read-write set, the identification of the second transaction that most recently updated the first variable recorded earlier, generates DAG data, and the second transaction is the most recent post-pre-execution update before the pre-execution of the first transaction A transaction in the pre-execution state of the first variable, the DAG data indicating the time sequence in which the first transaction and the second transaction access the first variable; sending the DAG data to the slave node;

    The slave node is configured to execute the first transaction and the second transaction based on the DAG data.
12. A blockchain master node comprising:

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

    A generation unit, configured to generate DAG data according to the pre-execution read-write set of the first transaction and the identifier of the previously recorded second transaction that most recently updated the first variable, and the second transaction is the pre-execution A transaction that updates the pre-execution state of the first variable after pre-execution, the most recent before the first transaction, and the DAG data indicates the time sequence in which the first transaction and the second transaction access the first variable;

    A sending unit, configured to send the DAG data to the slave nodes of the block chain.
13. According to the master node according to claim 12, the pre-execution unit is specifically configured to pre-execute the received first transaction based on the pre-execution state set, and after the pre-execution completes the first transaction, based on the first transaction The pre-execution read-write set updates the pre-execution state set.
14. The master node according to claim 12 or 13, wherein the DAG data includes the respective DAG tables of multiple transactions that have been pre-executed, and the DAG table of each transaction includes the subsequent transactions and The number of inbound transactions.
15. According to the master node according to claim 14, the pre-execution read-write set includes a read operation on the first variable, and the generating unit is specifically configured to: add the first variable in the DAG table of the second transaction A transaction is recorded as a subsequent transaction of the second transaction, and the in-degree of the first transaction is added by 1 in the DAG table of the first transaction.
16. According to the master node according to claim 14, the pre-execution read-write set includes a write operation on the first variable, and the generating unit is specifically configured to: read the DAG table of the second transaction, and in the Where the second transaction has a subsequent fourth transaction, the first transaction is recorded in the DAG table of the fourth transaction as the successor transaction of the fourth transaction, and in the DAG table of the first transaction Adding 1 to the in-degree of the first transaction, and recording the first transaction as the latest update of the first variable.
17. According to the master node according to claim 16, the generating unit is specifically configured to: record the first transaction in the DAG table of the second transaction as the For the subsequent transaction of the second transaction, add 1 to the in-degree of the first transaction in the DAG table of the first transaction, and record the first transaction as the transaction that most recently updated the first variable.
18. The master node according to claim 14, further comprising:

    An acquisition unit, configured to acquire a first set according to the respective DAG tables of the plurality of transactions, the first set includes transactions whose in-degrees are zero among the plurality of transactions,

    The sending unit is further configured to send the first set to the slave node.
19. A blockchain slave node, comprising:

    a receiving unit, configured to receive DAG data from the master node of the blockchain, the DAG data indicating the time sequence in which the first transaction and the second transaction access the first variable;

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

Images