CN114547203A

CN114547203A - Method for executing transaction, block chain, main node and slave node

Info

Publication number: CN114547203A
Application number: CN202210181705.2A
Authority: CN
Inventors: 刘晓建; 张兆勇
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-02-25
Filing date: 2022-02-25
Publication date: 2022-05-27
Also published as: WO2023160085A1

Abstract

A method of performing a transaction in a blockchain, a master node and a slave node. The method comprises the following steps: the main 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 comprises access to a first variable; the main node generates DAG data according to a pre-execution read-write set of a first transaction and a previously recorded identifier of a second transaction which updates the first variable recently, wherein the second transaction is a transaction which updates a pre-execution state of the first variable recently after the pre-execution before the pre-execution of the first transaction, and the DAG data indicates a time sequence of accessing the first variable by the first transaction and the second transaction; the master node sends DAG data to the slave nodes; the slave node performs the first transaction and the second transaction based on the DAG data.

Description

Method for executing transaction, block chain, main node and slave node

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a method for executing transactions in a block chain, a master node and a slave node.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people. However, transactions that invoke smart contracts are generally not able to be executed in parallel because the accessed variables cannot be predicted prior to execution.

Disclosure of Invention

The invention aims to provide a method for executing transaction in a block chain, which enables slave nodes in the block chain to execute transaction in parallel according to consensus proposal of a master node.

A first aspect of the specification provides a method of performing a transaction in a blockchain, the blockchain comprising a master node and a slave node, the method comprising:

the main 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 comprises access to a first variable;

generating, by the master node, DAG data according to a pre-execution read-write set of the first transaction and a previously recorded identification of a second transaction that most recently updated the first variable, the second transaction being a transaction that most recently updated a pre-execution state of the first variable after pre-execution before pre-execution of the first transaction, the DAG data indicating a temporal order in which the first transaction and the second transaction access the first variable;

the master node sending the DAG data to the slave node;

the slave node performs the first transaction and the second transaction based on the DAG data.

A second aspect of the specification provides a blockchain comprising a master node and a slave node,

the master node is configured to: pre-executing a received first transaction, and generating a pre-execution read-write set of the first transaction, wherein the pre-execution read-write set comprises access to a first variable; generating DAG data according to a pre-execution read-write set of the first transaction and a previously recorded identification of a second transaction which recently updates the first variable, wherein the second transaction is a transaction which recently updates a pre-execution state of the first variable after pre-execution before the first transaction is pre-executed, and the DAG data indicates a time sequence of accessing the first variable by the first transaction and the second transaction; sending the DAG data to the slave node;

the slave node is to perform the first transaction and the second transaction based on the DAG data.

A third aspect of the present specification provides a blockchain master node, comprising:

the system comprises a pre-execution unit, a pre-execution unit and a processing unit, wherein the pre-execution unit is used for pre-executing a received first transaction and generating a pre-execution read-write set of the first transaction, and the pre-execution read-write set comprises access to a first variable;

a generating unit, configured to generate DAG data according to a pre-execution read-write set of the first transaction and a previously recorded identifier of a second transaction that most recently updates the first variable, where the second transaction is a transaction that most recently updates a pre-execution state of the first variable after pre-execution before pre-execution of the first transaction, and the DAG data indicates a time sequence of access to the first variable by the first transaction and the second transaction;

a sending unit, configured to send the DAG data to a slave node of the block chain.

A fourth aspect of the present specification provides a blockchain slave node, comprising:

a receiving unit to receive DAG data from a master node of the blockchain, the DAG data indicating a temporal order of access of the first transaction and the second transaction to the first variable;

an execution unit to execute the first transaction and the second transaction based on the DAG data.

According to the scheme for executing the transactions in the block chain provided by the embodiment of the specification, the slave nodes can execute the transactions without conflict in parallel according to the DAG data generated by the master node, and execute the transactions with conflict in sequence according to the sequence in the DAG data, so that the transaction execution efficiency is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.

FIG. 1 is a block chain architecture diagram applied in an embodiment of the present disclosure;

FIG. 2 is a flow diagram of a method for performing transactions in a blockchain in one embodiment of the present description;

FIG. 3 is a DAG diagram in one embodiment of the present description;

fig. 4 is an architecture diagram of a block chain master node in an embodiment of the present specification;

fig. 5 is an architecture diagram of a blockchain slave node in an embodiment of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

Fig. 1 shows a block chain architecture diagram applied in the embodiment of the present specification. As shown in fig. 1, the block chain includes, for example, 6 nodes including a master node 1, a slave node 2, and a slave node 6. The lines between the nodes schematically represent P2P (Peer-to-Peer) connections. All the nodes store the full-amount accounts, namely the states of all the blocks and all the accounts. Wherein each node in the blockchain generates the same state in the blockchain by performing the same transaction, each node in the blockchain storing the same state database. In contrast, the master node 1 may be responsible for receiving transactions from clients and initiating consensus proposals to the respective slave nodes, including information such as a number of transactions in a tile to be blocked (e.g., tile B1) and the order of submission of the respective transactions. After the node in the blockchain agrees on the consensus proposal successfully, the nodes may perform the multiple transactions according to the order of submission in the consensus proposal, thereby generating block B1.

It is to be appreciated that the blockchain shown in fig. 1 is merely exemplary, and that the embodiments of the present specification are not limited to application to the blockchain shown in fig. 1, and may also be applied to a blockchain system including slices, for example.

In addition, although fig. 1 shows that the blockchain includes 6 nodes, the embodiments of the present specification are not limited thereto, and may include other numbers of nodes. Specifically, the nodes included in the block chain can meet the Byzantine Fault Tolerance (BFT) requirement. The byzantine fault tolerance requirement can be understood as that byzantine nodes can exist in a block chain, and the block chain does not show the byzantine behavior to the outside. Generally, 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).

A transaction in the blockchain domain may refer to a unit of task that is performed in the blockchain and recorded in the blockchain. The transaction typically includes a send field (From), a receive field (To), and a Data field (Data). Where the transaction is a transfer transaction, the From field indicates the address of the account From which the transaction was initiated (i.e., From which a transfer task To another account was initiated), the To field indicates the address of the account From which the transaction was received (i.e., From which a transfer was received), and the Data field includes the transfer amount. In the case of a transaction calling an intelligent contract in a blockchain, a From field represents an account address for initiating the transaction, a To field represents an account address of the contract called by the transaction, and a Data field includes Data such as a function name in the calling contract and incoming parameters To the function, so as To obtain code of the function From the blockchain and execute the code of the function when the transaction is executed.

The function of the intelligent contract can be provided in the block chain. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code. The intelligent contract is called in the Ethernet workshop, and a transaction pointing to the intelligent contract address is initiated, so that each node in the Ethernet workshop network runs the intelligent contract code in a distributed mode. It should be noted that, in addition to the creation of the smart contracts by the users, the smart contracts may also be set by the system in the creation block. Such contracts are generally referred to as foundational contracts. In general, the data structure, parameters, attributes and methods of some blockchains may be set in the startup contract. Further, an account with system administrator privileges may create a contract at the system level, or modify a contract at the system level (simply a system contract). Wherein the system contract is usable to add data structures for different services in a blockchain.

In the scenario of contract deployment, for example, Bob sends a transaction containing information to create an intelligent contract (i.e., a deployment contract) into the blockchain as shown in fig. 1, the data field of the transaction includes the code (e.g., bytecode or machine code) of the contract to be created, and the to field of the transaction is null to indicate that the transaction is for contract deployment. After the agreement is achieved among the nodes through a consensus mechanism, a contract address '0 x6f8ae93 …' of the contract is determined, each node adds a contract account corresponding to the contract address of the intelligent contract in a state database, allocates a state storage corresponding to the contract account, and stores a contract code in the state storage of the contract, so that the contract creation is successful.

In the scenario of invoking a contract, for example, Bob sends a transaction for invoking a smart contract into the blockchain as shown in fig. 1, where the from field of the transaction is the address of the account of the transaction initiator (i.e., Bob), and "0 x6f8ae93 …" in the to field represents the address of the invoked smart contract, and the data field of the transaction includes the method and parameters for invoking the smart contract. After the transaction is identified in the blockchain, each node in the blockchain can execute the transaction respectively, so that the contract is executed respectively, and the state database is updated based on the execution of the contract.

In the related art, in order to increase a per second transaction execution (TPS) index in a blockchain, it is necessary to increase the execution speed of a transaction. For this reason, the execution speed of the transaction can be increased by executing the transaction in parallel in the blockchain node. In one embodiment, the blockchain nodes may execute transactions in parallel by multiple processes in a single machine, and in another embodiment, the blockchain nodes may be deployed in a server cluster and execute transactions in parallel by multiple servers. Generally, for transfer transactions, the block link points first divide the transactions into transaction groups according to the account accessed by the transaction, and the same account is not accessed between each transaction group, so that each transaction group can be executed in parallel. However, when a smart contract is invoked in a transaction, the variables accessed in the transaction cannot be predicted prior to execution of the transaction, so that multiple transactions cannot be effectively grouped, and thus transactions cannot be executed in parallel.

In another related technique, the master node may perform the transaction and send the result to the slave node for verification, and to speed up the verification phase, the master node may only pack non-conflicting transactions during the execution, and defer the conflicting transactions until the next block is packed, so that the slave node can perform concurrent verification. However, in this approach, when the conflict rate between transactions is high, the transactions may be placed in different blocks, reducing system performance and increasing storage costs.

Fig. 2 is a flowchart of a method for executing a transaction in a blockchain in an embodiment of the present specification, where the method may be executed by a master node and each slave node shown in fig. 1, and a master node 1 and a slave node 2 are shown in fig. 2 as an example, and it is understood that other slave nodes in the blockchain perform the same operation as the slave node 2.

As shown in fig. 2, at step S201, the master node pre-executes the received transaction, generating a pre-executed read-write set of transactions.

The pre-execution refers to the execution of the transaction by the master node prior to making the consensus proposal. Before making consensus offers, the host node 1 has not set the order of submission of the individual transactions, and the host node 1 may make pre-executions of the transactions in any order. For example, the master node 1 may pre-execute each received transaction in the sequence of receiving each transaction, or the master node 1 may pre-execute a plurality of transactions in parallel after receiving the plurality of transactions at the same time.

The master node 1 maintains a variable latest state set (hereinafter, referred to as a pre-execution state set) according to read-write operations of variables for each transaction in the process of pre-executing the transaction, and pre-executes the transaction according to the pre-execution state set.

For example, transaction Txi includes a read operation to variable a and a write operation to variable B. When transaction Txi is pre-executed, when a read operation on variable a is executed, the host node 1 determines whether the pre-execution state set has a value of variable a, if not, the value of variable a is read from the state database, the key-value pair of variable a is recorded in the pre-execution read set of transaction Txi, 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, the value of variable a is directly read from the pre-execution state set, and the key-value pair of variable a is recorded in the pre-execution read set of transaction Txi. When the host node 1 executes a write operation on the variable B, the key-value pair of the variable B is recorded in the pre-execution write set of the transaction Txi. Resulting in a pre-executed read-write set for transaction Txi.

After completing the pre-execution of the transaction Txi, the host node 1 determines whether the pre-execution read set of the transaction Txi is consistent with the variable value in the pre-execution state set, if the variable values are inconsistent, the transaction Txi is re-pre-executed if the variable values are inconsistent, and if the variable values are consistent, the pre-execution state set is updated according to the pre-execution read-write set of the transaction Txi, that is, the key value pairs of the variables B in the pre-execution read-write set are updated to the pre-execution state set.

In step S203, the master node generates Directed Acyclic Graph (DAG) data between transactions according to the pre-execution read-write set of transactions, the transaction (hereinafter, referred to as the latest transaction) identification recorded in advance that updates (the pre-execution state of) the transaction access variable most recently by pre-execution before the transaction is pre-executed, indicating the time order of the transaction access variables.

The DAG data is data indicating a DAG relationship between transactions, and may be in a graphic form, a table form, a data form, or the like, which is not limited thereto. For example, the DAG data includes a DAG table for each transaction, including the successor transactions and the degree of the successor transactions of the transaction Txi, where the successor transactions refer to transactions following the transaction Txi by the time order of pre-execution access to a variable (which is also the variable accessed by the transaction Txi), and the transactions pointed to directly from the transaction Txi in the DAG graph. The degree of income refers to the number of transactions directed to transaction Txi in the DAG graph.

Specifically, after the host node 1 completes the transaction Txi in the pre-execution, for the variable a, the host node 1 may determine, according to the latest transaction index of the variable a, that the transaction of the variable a was updated most recently before the pre-execution of the transaction Txi, and if the latest transaction is the transaction Txj, the host node 1 may record the transaction Txi as a subsequent transaction in a DAG table of the transaction Txj, and add 1 to the number of entries of the transaction Txi in the DAG table of the transaction Txi. If the master node 1 determines from the last transaction index of the variable a that the transaction of the variable a was not updated before the pre-execution of the transaction Txi, the master node 1 may bind the last transaction index of the variable a with a null transaction and record the transaction Txi in association with the null transaction for recording that the transaction Txi read the variable a.

For the variable B, the master node 1 may determine, according to the latest transaction index of the variable B, that the transaction of the variable B is updated most recently before the pre-execution of the transaction Txi, and assuming that the latest transaction is Txk, the master node 1 may determine whether Txk has a subsequent transaction according to the DAG table of the transaction Txk, and if there is a subsequent transaction Txm, the master node 1 may record the transaction Txi as a subsequent transaction in the DAG table of the transaction Txm, add 1 to the number of entries of the transaction Txi in the DAG table of the transaction Txi, and bind the latest transaction index of the variable B with the 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 may record the transaction Txi as a subsequent transaction in the DAG table of the transaction Txk, add 1 to the access number of the transaction Txi in the DAG table of the transaction Txi, and bind the latest transaction index of the variable B with the transaction Txi.

In one example, the master node 1 first pre-executes transaction Tx1, which transaction Tx1 includes a read operation to variable A. After pre-executing the completed transaction Tx1, the master node 1 sets the latest transaction of variable a as a null transaction and records the transaction Tx1 for the null transaction, from which it can be found that the number of entries of the transaction Tx1 is 0, and records the DAG table of the transaction Tx1 as shown in table 1:

trading	Subsequent transactions	Degree of penetration
			Tx1	{}	0

TABLE 1

Where "{ }" in table 1 indicates that the set of subsequent transactions of Tx1 is an empty set, i.e., there are no subsequent transactions.

Thereafter, the master node 1 pre-executes transaction Tx2, transaction Tx2 includes a read operation to variable A and a write operation to variable B. After pre-executing the completed transaction Tx2, the master node 1 may determine that the latest transactions of the variable a and the variable B are both null transactions according to the latest transaction index of the variable a and the variable B, and accordingly may determine that the number of entries of the transaction Tx2 is 0, and associate and record the transaction Tx2 with the latest null transaction of the variable a, record the transaction Tx2 as the latest transaction of the variable B, and record a DAG table of the transaction that has been currently pre-executed and completed as shown in table 2:

trading	Subsequent transactions	Degree of penetration
			Tx1	{}	0
Tx2	{}	0

TABLE 2

Thereafter, the master node 1 pre-executes transaction Tx3, transaction Tx3 includes a read operation for variable A and a read operation for variable B. After pre-execution completes the transaction Tx3, the master node 1 can derive the latest transaction of the variable B as the transaction Tx2 according to the latest transaction index of the variable A and the variable B. That is, during pre-execution, transaction Tx3 accesses variable B after transaction Tx2 writes to variable B, whereby the DAG relationship that transaction Tx2 points to transaction Tx3 may be recorded, for example, by an arrow in the DAG graph, or transaction Tx3 may be recorded as a subsequent transaction in the DAG table of transaction Tx2, and the number of entries may be incremented by 1 in the DAG table of transaction Tx3 to indicate the order of execution of transaction Tx3 and transaction Tx2, i.e., transaction Tx3 executes after transaction Tx 2. For example, master node 1 may record a DAG table for a transaction that has currently been pre-executed for completion as shown in Table 3:

trading	Subsequent transactions	Degree of penetration
			Tx1	{}	0
Tx2	{Tx3}	0
			Tx3	{}	1

TABLE 3

By thus recording the DAG relationship between the deal Tx2 and the deal Tx3 and executing the deal Tx2 and the deal Tx3 in the execution order indicated by the DAG relationship when the deals are executed, the state change when the deals Tx2 and the deals Tx3 are executed is consistent with the pre-execution, so that the correctness of the DAG relationship between the deals is maintained, and a plurality of deals with zero in-degree can be executed in parallel according to the DAG relationship, thereby improving the execution efficiency of the deals.

At the same time, the master node 1 also records the transaction Tx3 with the last empty transaction of variable a above.

Thereafter, the master node 1 pre-executes transaction Tx4, transaction Tx4 includes a write operation to variable A and a read operation to variable B. After the pre-execution of the completion transaction Tx4, the master node 1 may derive the associated transaction of the most recent empty transaction of the variable a from the most recent transaction index of the variable a including the transactions Tx1, Tx2 and Tx3, and thus record the transaction Tx4 as the successor transaction of each of Tx1, Tx2 and Tx3 to indicate that the transaction Tx4 is executed after the completion of the transactions Tx1, Tx2 and Tx3 is executed, thereby avoiding the execution result of each transaction from being different from the pre-execution result due to read-write collision. The master node 1 may derive the most recent transaction for variable B as transaction Tx2 from the most recent transaction index for variable B, and thus record transaction Tx4 as a successor to transaction Tx 2. Master node 1 may record the DAG table for the transaction that is currently pre-executed for completion as shown in table 4:

trading	Subsequent transactions	Degree of penetration
			Tx1	{Tx4}	0
Tx2	{Tx3,Tx4}	0
			Tx3	{Tx4}	1
Tx4	{}	3

TABLE 4

At the same time, master node 1 also binds the last transaction index of variable a with transaction Tx 4.

Thereafter, the master node 1 pre-executes transaction Tx5, transaction Tx4 including a write operation to variable B. After pre-execution of the completed transaction Tx5, the master node 1 may derive the latest transaction for variable B as Tx2 from the latest transaction index for variable A, and thus may record transaction Tx5 as a successor to the successors of transaction Tx2 (transaction Tx3 and transaction Tx 4). Master node 1 may record the DAG table for the transaction that has currently been pre-executed for completion as shown in table 5:

trading	Subsequent transactions	Degree of penetration
			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 last transaction index of variable B with transaction Tx 5. A DAG graph, as shown in fig. 3, corresponding to the DAG data shown in table 5, may be drawn according to the DAG relationship between transactions that have currently been pre-executed for completion.

At step S205, the master node 1 transmits DAG data for a plurality of transactions to the respective slave nodes.

The master node 1 may pre-execute a plurality of transactions as described above, generate DAG data between the plurality of transactions, and transmit the DAG data of the plurality of transactions to the respective slave nodes as consensus proposals. The master node 1 may also send the received plurality of transactions to the respective slave nodes. It will be appreciated that each slave node may also receive multiple transactions from other slave nodes or clients. Each slave node may also receive DAG data for the multiple transactions from other slave nodes.

In addition to transmitting DAG data of a plurality of transactions to each slave node, the master node 1 may generate a set of executable transactions with an input number of 0 from the DAG data, and transmit the set of transactions together to each slave node. For example, the master node 1 transmits DAG data shown in table 5 to the respective slave nodes, and the master node 1 may obtain an executable transaction set including the transaction Tx1 and the transaction Tx2 from the DAG data and transmit the executable transaction set to the respective slave nodes. It will be appreciated that master node 1 may also only send DAG data for multiple transactions to each slave node, from which each slave node may generate a set of executable transactions.

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

Taking slave node 2 as an example, after obtaining the DAG data-based set of executable transactions, slave node 2 first executes the transactions in the set of executable transactions. Since the number of entries of the transactions in the executable transaction set is zero, i.e. the execution thereof does not conflict with other transactions, the master node 1 may execute a plurality of transactions in the executable transaction set in parallel.

Specifically, referring to FIG. 3, the set of executable transactions initially includes transaction Tx1 and transaction Tx 2. The slave node 2 may execute the transaction Tx1 and the transaction Tx2 in parallel. The slave node 2, after completing execution of the transaction Tx1, may subtract 1 from the incoming number in the DAG table for the transaction Tx 4. After slave node 2 completes the execution of transaction Tx2, its in-degree numbers may be respectively decremented by 1 in the DAG tables for transaction Tx3 and transaction Tx4, so that the in-degree number for transaction Tx3 becomes 0, at which time slave node 2 may place transaction Tx3 into the set of executable transactions, i.e., slave node 2 may execute transaction Tx 3. After slave node 2 completes the execution of transaction Tx3, the in-degree of transactions Tx4 and Tx5 are decremented by 1 so that the in-degree of transaction Tx4 becomes 0, and similarly, slave node 2 may place transaction Tx4 into the set of executable transactions.

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

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

a generating unit 42, configured to generate DAG data according to the pre-execution read-write set of the first transaction, and an identifier of a previously recorded second transaction that most recently updates the first variable, where the second transaction is a transaction that most recently updated a pre-execution state of the first variable after pre-execution before pre-execution of the first transaction, and the DAG data indicates a time sequence of accessing the first variable by the first transaction and the second transaction;

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

In an embodiment, the pre-execution unit is specifically configured to pre-execute the received first transaction based on a pre-execution state set, and update the pre-execution state set based on a pre-execution read-write set of the first transaction after the first transaction is completed by pre-execution.

In one embodiment, the DAG data includes a DAG table for each of the plurality of transactions that have been completed by pre-execution, the DAG table for each transaction including a number of successors and entries of the transaction in a DAG graph.

In an embodiment, the set of pre-executed read/write operations includes a read operation on the first variable, and the generating unit 42 is specifically configured to: recording the first transaction as a successor to the second transaction in a DAG table for the second transaction, and adding 1 to the in-degree number for the first transaction in a DAG table for the first transaction.

In an embodiment, the set of pre-executed read-write sets includes a write operation on the first variable, and the generating unit 42 is specifically configured to: reading a DAG table of the second transaction, in the case that the second transaction has a subsequent fourth transaction, recording the first transaction as the subsequent transaction of the fourth transaction in the DAG table of the fourth transaction, adding 1 to the number of entries of the first transaction in the DAG table of the first transaction, and recording the first transaction as the transaction of which the first variable is updated recently.

In an embodiment, the generating unit 42 is specifically configured to: in the case that the second transaction has no successor transaction, recording the first transaction as a successor transaction of the second transaction in a DAG table of the second transaction, adding 1 to the in-degree number of the first transaction in a DAG table of the first transaction, and recording the first transaction as a transaction which has recently updated the first variable.

In one embodiment, the master node further comprises: an obtaining unit (not shown) configured to obtain a first set according to a DAG table of each of the transactions, where the first set includes transactions with an in-degree of zero in the transactions,

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

Fig. 5 is an architecture diagram of a blockchain slave node in an embodiment of the present specification, including:

a receiving unit 51, configured to receive DAG data from the master node of the block chain, where the DAG data indicates a time order of access to the first variable by the first transaction and the second transaction;

an execution unit 52 to execute the first transaction and the second transaction based on the DAG data.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above described 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.

Although one or more embodiments of the present description provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of multiple sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

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 will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The 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 Discs (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 a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, one or more embodiments of the present description 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 take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the present description 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 can 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 memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

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

the main node generates Directed Acyclic Graph (DAG) data according to a pre-execution read-write set of the first transaction and a previously recorded identifier of a second transaction which updates the first variable recently, wherein the second transaction is a transaction which updates a pre-execution state of the first variable recently after the pre-execution before the pre-execution of the first transaction, and the DAG data indicates a time sequence of the first transaction and the second transaction for accessing the first variable;

the master node sending the DAG data to the slave node;

2. The method of claim 1, the pre-executing by the master node the received first transaction comprising pre-executing by the master node the received first transaction based on a set of pre-execution states, the set of pre-execution states being updated based on a set of pre-execution reads and writes for the first transaction after the pre-execution completes the first transaction.

3. The method as in claim 1 or 2, wherein the DAG data comprises a DAG table for each of a plurality of transactions that have been pre-executed for completion, each transaction's DAG table comprising a number of subsequent transactions and in-degree transactions for the transaction in a DAG graph.

4. The method of claim 3, the pre-execution read-write set including a read operation on the first variable, the generating, by the master node, DAG data based on the pre-execution read-write set of the first transaction, a previously recorded identification of a second transaction that most recently updated the first variable comprising:

the master node records the first transaction as a successor to the second transaction in a DAG table of the second transaction, and adds 1 to the in-degree number of the first transaction in the DAG table of the first transaction.

5. The method of claim 3, wherein the pre-execution read-write set includes a read operation on the first variable, the second transaction identifier is a null transaction identifier, and the generating, by the master node, DAG data according to the pre-execution read-write set of the first transaction and an identifier of a previously recorded second transaction that most recently updated the first variable comprises:

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

after the host node completes the first transaction through pre-execution, pre-executing a received third transaction to generate a pre-execution read-write set of the third transaction, wherein the pre-execution read-write set of the third transaction comprises write operation on the first variable;

and the main node records the third transaction as a subsequent transaction of the first transaction in a DAG table of the first transaction 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, adds 1 to the access number of the third transaction in the DAG table of the third transaction, and records the third transaction as a transaction of updating the first variable recently.

6. The method of claim 3, the pre-execution read-write set of the first transaction including a write operation to the first variable, the generating, by the master node, DAG data based on the pre-execution read-write set of the first transaction, a previously recorded identification of a second transaction that most recently updated the first variable comprising:

and the main node reads the DAG table of the second transaction, records the first transaction as a subsequent transaction of a fourth transaction in the DAG table of the fourth transaction in the case that the second transaction has the subsequent fourth transaction, adds 1 to the incoming degree of the first transaction in the DAG table of the first transaction, and records the first transaction as a transaction of which the first variable is updated recently.

7. The method of claim 6, the master node generating DAG data based on the pre-executed read-write set of the first transaction, a previously recorded identification of a second transaction that most recently updated the first variable further comprising: in the case that the second transaction has no successor transaction, recording the first transaction as a successor transaction of the second transaction in a DAG table of the second transaction, adding 1 to the in-degree number of the first transaction in a DAG table of the first transaction, and recording the first transaction as a transaction which has recently updated the first variable.

8. The method of claim 3, further comprising:

the master node acquires a first set according to a DAG table of each of the plurality of transactions, wherein the first set comprises transactions with zero incoming degree in the plurality of transactions,

sending the first set to the slave node.

9. The method of claim 8, the first set including the second transaction, the first transaction being a successor to the second transaction, the slave node performing the first and second transactions based on the DAG data comprising:

the slave nodes execute the transactions in the first set in parallel; after the second transaction is executed, subtracting 1 from the in-degree number of the first transaction; placing the first transaction in the first set in the event that the number of entries of the first transaction decreases to 0.

10. The method of claim 2, the set of pre-execution reads and writes for the first transaction comprising read operations on a first variable, the updating the set of pre-execution states based on the set of pre-execution reads and writes for the first transaction comprising: 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 so, updating the pre-execution state set based on the pre-execution read-write set of the first transaction, wherein the generating DAG data comprises generating DAG data in the consistent case.

11. A blockchain comprising a master node and a slave node,

12. A blockchain master node, comprising:

13. The master node of claim 12, wherein the pre-execution unit is specifically configured to pre-execute the received first transaction based on a pre-execution state set, and update the pre-execution state set based on a pre-execution read-write set of the first transaction after the pre-execution completes the first transaction.

14. The master node of claim 12 or 13, wherein the DAG data comprises a DAG table for each of the plurality of transactions that have been pre-executed for completion, the DAG table for each transaction comprising a number of subsequent transactions and in-degree transactions for the transaction in a DAG graph.

15. The master node of claim 14, wherein the set of pre-executed reads and writes includes a read operation on the first variable, and the generating unit is specifically configured to: recording the first transaction as a successor to the second transaction in a DAG table for the second transaction, adding 1 to the in-degree of the first transaction in the DAG table for the first transaction.

16. The master node of claim 14, wherein the pre-execution read-write set includes a write operation on the first variable, and the generation unit is specifically configured to: reading a DAG table of the second transaction, in the case that the second transaction has a subsequent fourth transaction, recording the first transaction as the subsequent transaction of the fourth transaction in the DAG table of the fourth transaction, adding 1 to the number of entries of the first transaction in the DAG table of the first transaction, and recording the first transaction as the transaction of which the first variable is updated recently.

17. The master node of claim 16, the generating unit to: in the case that the second transaction has no successor transaction, recording the first transaction as a successor transaction of the second transaction in a DAG table of the second transaction, adding 1 to the in-degree number of the first transaction in a DAG table of the first transaction, and recording the first transaction as a transaction which has recently updated the first variable.

18. The master node of claim 14, further comprising:

an obtaining unit, configured to obtain a first set according to a DAG table of each of the multiple transactions, where the first set includes transactions with an in-degree number of zero in the multiple transactions,

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

19. A blockchain slave node, comprising: