CN114529417A

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

Info

Publication number: CN114529417A
Application number: CN202210182800.4A
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-24
Also published as: WO2023160083A1

Abstract

A method of performing a transaction in a blockchain, master node and slave nodes, the method comprising: the method comprises the steps that a main node pre-executes a plurality of received transactions, generates respective access lists of a plurality of variables and transaction information of each transaction, wherein each access list comprises a plurality of table entries which are arranged in sequence, each table entry comprises a sequence number of the table entry, a transaction identifier for accessing the variable and an access type, the sequence number corresponds to the access sequence of the transaction in the table entry to the variable, and the transaction information comprises the variable identifier for accessing the transaction and the sequence number corresponding to the access to the variable; the master node sends an access list of a plurality of variables and transaction information of a plurality of transactions to the slave node; the slave node performs a plurality of transactions based on the access list of the plurality of variables and transaction information for the plurality of transactions.

Description

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

Technical Field

Embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method for performing a transaction in a blockchain, 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 multiple transactions, and generates respective access lists of multiple variables and transaction information of the transactions, wherein the access lists comprise multiple list items which are sequentially arranged, each list item comprises a sequence number of the list item, a transaction identifier for accessing the variable and an access type, the sequence number corresponds to the access sequence of the transaction in the list item to the variable, and the transaction information comprises the variable identifier for accessing the transaction and the sequence number corresponding to the access of the variable;

the master node sends the access list of the variables and the transaction information of the transactions to the slave node;

the slave node performs the plurality of transactions based on the access list of the plurality of variables and transaction information for the plurality of transactions.

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

the main node is used for pre-executing a plurality of received transactions, and generating respective access lists of a plurality of variables and transaction information of each transaction, wherein each access list comprises a plurality of items which are arranged in sequence, each item comprises a sequence number of the item, a transaction identifier for accessing the variable and an access type, the sequence number corresponds to the access sequence of the transaction in the item to the variable, and the transaction information comprises the variable identifier for accessing the transaction and the sequence number corresponding to the access of the variable; transmitting the access list of the plurality of variables and the transaction information of the plurality of transactions to the slave node;

the slave node is configured to execute the plurality of transactions based on the accessed list of the plurality of variables and transaction information for the plurality of transactions.

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

the system comprises a pre-execution unit, a transaction processing unit and a processing unit, wherein the pre-execution unit is used for pre-executing a plurality of received transactions and generating respective access lists of a plurality of variables and transaction information of the transactions, the access lists comprise a plurality of items which are sequentially arranged, each item comprises a sequence number of the item, a transaction identifier for accessing the variable and an access type, the sequence number corresponds to an access sequence of the transaction in the item to the variable, and the transaction information comprises the variable identifier for accessing the transaction and the sequence number corresponding to the access of the variable;

a sending unit, configured to send the access list of the multiple variables and the transaction information of the multiple transactions to a slave node of the blockchain.

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

a receiving unit, configured to receive, from the master node, an access list of multiple variables and transaction information of multiple transactions, where the access list of multiple variables and the transaction information of multiple transactions are generated after the master node performs the multiple transactions in advance, where the access list includes multiple entries arranged in sequence, each entry includes a sequence number of the entry, a transaction identifier for accessing the variable, and an access type, the sequence number corresponds to an access sequence of the transaction in the entry to the variable, and the transaction information includes the variable identifier for accessing the transaction and the sequence number corresponding to the access to the variable;

an execution unit to execute the plurality of transactions based on the access list of the plurality of variables and the transaction information of the plurality of transactions.

According to the scheme for executing the transaction in the block chain, provided by the embodiment of the specification, the slave node executes the transaction according to the access queue of the variable generated by the master node and the transaction information, the transaction without conflict can be executed in parallel, and the transaction with conflict can be executed according to the sequence of the transactions recorded by the access queue, 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 one 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 schematic diagram of a process for generating an access list and transaction information in one embodiment of the present disclosure;

FIG. 4 is a schematic diagram of a process for executing a transaction in a slave node in one embodiment of the present description;

fig. 5 is an architecture diagram of a blockchain master node in an embodiment of the present specification;

fig. 6 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 is a block chain architecture diagram applied in an embodiment of the present disclosure. 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 successfully agrees on the consensus proposal, the nodes may perform the 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-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 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 block chain may provide the functionality of an intelligent contract. 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 referred to as 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 execution Transaction (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, first, in step S201, the master node 1 executes a plurality of received transactions in advance, and generates access lists for each of a plurality of variables and transaction information for each transaction.

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.

After each transaction is successfully pre-executed, the master node 1 maintains a variable latest state set (hereinafter, identified as a pre-execution state set) according to the read-write operation of each transaction on the variable, and pre-executes other transactions 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 judges 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, the transaction Txi is determined to be successfully pre-executed, and the pre-execution state set is updated according to the pre-execution read-write set of the transaction Txi, that is, the key value pair of the variable B in the pre-execution read-write set is updated to the pre-execution state set.

The master node 1 may update the access list of the variables after pre-execution completes each transaction, and generate transaction information for the transaction from the access list of the variables. The access list comprises a plurality of entries which are arranged in sequence, each entry comprises a sequence number of the entry, a transaction identifier for accessing the variable and an access type, and the sequence number corresponds to the access sequence of the transaction in the entry to the variable. Specifically, the access list may be in the form of a linked list. The access type includes a shared type and an exclusive type. If the transaction only comprises a read operation on a certain variable, the access type of the transaction on the variable is a shared type, and if the transaction only comprises a write operation on the certain variable or the transaction comprises a write operation and a read operation on the certain variable, the access type of the transaction on the variable is an exclusive type. The transaction information comprises variable identification of the transaction access and a sequence number corresponding to the access of the variable. The master node 1 may store, in a pre-execution read-write set of a transaction, a sequence number corresponding to access to a variable by the transaction in association with the variable being read or written.

Fig. 3 is a schematic diagram of a process for generating an access list and transaction information in an embodiment of the present disclosure.

Referring to the upper part of fig. 3, assuming that transaction a includes read access to variable x, the master node 1 updates the information of variable x in the variable information after transaction a is pre-executed. It is assumed that the access list of the variable x is not included in the current variable information, so that the master node 1 generates the 1 st entry of the access list of the variable x, where the 1 st entry is the head entry and the tail entry of the access list of the variable x. The sequence number in the 1 st entry is 0, the access type is a sharing type, and the transaction set (shown in { } in fig. 3) includes an identifier of transaction a (e.g., "a"). Meanwhile, the master node 1 adds the information of transaction a in the transaction information section, in which the identification of the variable x and the sequence number (e.g., "x.0") corresponding to the access of transaction a to the variable x are recorded in association.

Assuming that transaction B also includes a read access to variable x, after transaction B is pre-executed by host node 1, the access type of the tail entry (i.e., the entry with sequence number 0) in the access list of variable x may be determined to be a shared type according to the variable information, and therefore, host node 1 may directly add the identifier of transaction B to the transaction set in the entry. Meanwhile, the master node 1 adds the information of transaction B in the transaction information section, in which the identification of the variable x and the sequence number (e.g., "x.0") corresponding to the access of transaction B to the variable x are recorded in association.

It is to be appreciated that although transaction a and transaction B are shown to be written into one entry of the access queue in fig. 3, embodiments of the present disclosure are not limited thereto, and for example, transaction a and transaction B may be written into two entries with different sequence numbers, and the two entries may be executed in parallel according to the shared type.

Assuming that transaction C includes a write access to the variable, master node 1 generates the 1 st entry of the access list for variable y in the variable information after pre-executing transaction C, similar to above. The entry has a sequence number of 0, the access type is an exclusive type, and the transaction queue (shown in FIG. 3 as <) includes an identification of transaction C. The transaction queue is different from the transaction set in that when a transaction is executed (or whether the transaction is executable is verified), the order of arrangement of the transactions in the transaction queue is not required to be considered, but the order of arrangement of the transactions in the transaction queue is required to be considered. Meanwhile, the master node 1 adds the information of the transaction C in the transaction information section, in which the identification of the variable y and the sequence number (e.g., "y.0") corresponding to the access of the transaction C to the variable y are associatively recorded. It will be appreciated that the entry for variable y and transaction information for transaction C are similarly generated as shown in the upper portion of Table 3, assuming that transaction C includes a read operation for variable y in addition to a write operation for variable y.

That is, the master node 1 obtains the variable information and the transaction information shown in the upper part of fig. 3 after completing the transaction a, the transaction B, and the transaction C by pre-execution.

Referring to the middle of FIG. 3, assume transaction D includes a write access to variable x and a read access to variable y. After the transaction D is completed by pre-execution of the master node 1, for the variable x, since the access type of the current tail table entry of the variable x is the shared type (refer to the upper part of fig. 3), the master node 1 sequentially adds one table entry in the access list of the variable x as a new tail table entry. The sequence number of the newly added table entry is 1, the access type is an exclusive type, and the transaction queue includes the identifier of transaction D. For the variable y, since the access type of the current tail entry of the variable y is an exclusive type (refer to the upper part of fig. 3), the master node 1 sequentially adds one entry in the access list of the variable y as a new tail entry. The sequence number of the newly added table entry is 1, the access type is a sharing type, and the transaction set comprises the identifier of transaction D. Meanwhile, the master node 1 adds information of the transaction D in the transaction information in which the variable x and the sequence number 1 are associatively recorded, and the variable y and the sequence number 1 are associatively recorded.

Referring to the bottom of FIG. 3, assume transaction E includes a write access to variable x and a read access to variable y. After the transaction E is pre-executed by the master node 1, for the variable x, since the access type of the current tail entry of the variable x is the exclusive type (refer to the middle part of fig. 3), the master node 1 sequentially adds the identifier of the transaction D to the transaction queue in the tail entry. For the variable y, since the access type of the current tail table entry of the variable y is the shared type (refer to the middle part of fig. 3), the master node 1 adds the identifier of the transaction E to the transaction set in the tail table entry of the variable y. Meanwhile, the master node 1 adds information of the transaction E, in which the variable x and the sequence number 1 are recorded in association, and the variable y and the sequence number 1 are recorded in association, to the transaction information.

It will be appreciated that, although FIG. 3 schematically illustrates a transaction queue recording transaction D and transaction E into one entry, embodiments of the present description are not limited thereto. For example, transaction D and transaction E may be written into two entries with different sequence numbers, such that the order of execution of transaction D and transaction E may be indicated by the order of sequence numbers.

In one embodiment, in addition to recording the sequence number as shown in fig. 3, another version number may be recorded in the entry. For example, as shown in the middle of fig. 3, after the pre-execution completion transaction D adds the 2 nd entry of the variable x, the 2 nd entry is added with the version number "1" in addition to the sequence number "1", as shown in the lower part of fig. 3, and after the pre-execution completion transaction E, the version number is added with 1, that is, updated to "2", in the 2 nd entry of the variable x. In the shared type entry, a version number that is constant as a preset value or a null value may be set. Assuming that the transaction F includes reading of the variable x, when the host node reads the variable x when the transaction F is pre-executed, the sequence number and the version number of the tail table entry of the variable x when the variable x is read are recorded. Specifically, if the access queue of the variable x when the transaction F reads the variable x is shown in the upper middle of fig. 3, the sequence number of the tail table entry is recorded as 0, and the version number is null, and if the access queue of the variable x when the transaction F reads the variable x is shown in the middle of fig. 3, the sequence number of the tail table entry is recorded as 1, and the version number is 1. After the transaction F is pre-executed, the host node reads the latest sequence number and version number of the tail table entry of the current variable x again, if the latest sequence number and version number are consistent with the sequence number and version number recorded in the pre-execution process, the transaction F can be confirmed to read a correct value, the transaction F is pre-executed successfully, and if the latest sequence number and version number are inconsistent with the sequence number and version number recorded in the pre-execution process, the transaction F can be confirmed to read an incorrect value, and the transaction F is pre-executed unsuccessfully. Compared with the method for comparing the read variable state value with the variable current state value after the transaction is completed in the pre-execution, the method saves the data amount of reading and comparing and improves the efficiency of the pre-execution of the transaction.

In step S203, the master node 1 transmits the variable information and the transaction information to the slave node 2.

The master node 1 may pre-execute a plurality of transactions as described above, and thereby may acquire an access list of each of a plurality of variables accessed by the plurality of transactions and transaction information of each of the plurality of transactions. The master node 1 may send transaction information for the plurality of transactions and an access list of the plurality of variables as consensus offers to the respective slave nodes (including slave node 2). 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 transaction information for the plurality of transactions and an access list of the plurality of variables from other slave nodes.

In step S205, the slave node 2 executes the plurality of transactions based on the access list of the plurality of variables and the transaction information of the plurality of transactions.

The slave node 2 may execute transactions in parallel by multiple threads. Specifically, the plurality of variables in the variable information may be divided into a plurality of groups, so that each thread performs a transaction according to an access list of the plurality of variables in one group. For example, thread 1 may process an access list for variable x and thread 2 may process an access list for variable y in parallel.

Fig. 4 is a schematic diagram of a process of executing a transaction in a slave node in one embodiment of the present specification.

Referring to the top of FIG. 4, thread 1 first reads the head entry of the access list for variable x, and obtains the identification of transaction A and transaction B from the transaction set for this entry. Thread 1 then reads transaction information x.0 for transaction a, i.e., transaction a only accesses variable x and the sequence number corresponding to this access is 0, which is consistent with the sequence number in the header entry of the current variable x, and thus thread 1 determines that transaction a is currently executable. Similarly, thread 1 may determine that transaction B is currently executable. That is, transaction A and transaction B may currently be executed in parallel. Thread 1 may instruct another thread to perform transaction B such that transaction a and transaction B are performed in parallel in slave node 2. Thread 1 may also execute transaction a and transaction B serially, or in a "transaction B-transaction a" chronological order.

In parallel with thread 1, thread 2 reads the head entry of the access list for variable y, and obtains the identification of transaction C from the transaction queue for that entry. Thread 2 then reads transaction information y.0 for transaction C, and similarly may determine that transaction C is currently executable. Thus, thread 2 may perform transaction C. That is, parallel execution of a plurality of transactions is realized in the slave node 2 based on the variable information and the transaction information, and transaction execution efficiency is improved.

After executing transaction a, thread 1 deletes the identifier of transaction a in the transaction set in the header entry of variable x, and after executing transaction B, deletes the header entry as only transaction B remains in the transaction set, thereby obtaining the access list of variable x as shown in the middle of fig. 4.

Referring to the middle of FIG. 4, thread 1 again reads the current head entry of variable x, and obtains the identification of the first-ranked transaction D from the transaction queue for that entry. Thread 1 then reads transaction information x.1, y.1 for transaction D, i.e., transaction D accesses variable x with sequence number 1 and variable y with sequence number 1. Thread 1 can determine from the current variable information: the sequence number of the current head table entry of the variable x is 1 and is consistent with the sequence number of the transaction D access variable x, and the sequence number of the current head table entry of the variable y is 0 and is inconsistent with the sequence number of the transaction D access variable y. Thus, thread 1 may determine that transaction D is currently not executable, i.e., may need to wait until transaction C is executed. That is, the slave node 2 serially executes a plurality of transactions with variable access conflicts according to the variable information and the transaction information, and the accuracy of transaction execution is improved. Additionally, since transaction E is queued in the transaction queue after transaction D, thread 1 may determine that transaction E is not currently executable. After determining that the transaction D and the transaction E are currently not executable, the thread 1 may obtain other executable transactions according to the access lists of other variables in the group assigned to the thread 1 to perform transaction execution, and read the access list of the variable x again when idle to determine whether the transaction D may be executed.

Thread 2, after executing complete transaction C, deletes the current head entry in the access queue for variable y, resulting in the access queue shown in the lower portion of fig. 4.

Referring to the lower part of fig. 4, thread 1 determines the transaction in the head entry of variable x again, at this time, the sequence numbers corresponding to variable x and variable y in the transaction information in transaction D are consistent with the sequence numbers in the head entries of the variables in the variable information, and transaction D is arranged first in the transaction queue in the access list entry of variable x and is also located in the transaction set of the access list entry of another variable y accessed by transaction D (i.e. the transaction execution sequence is not involved), so thread 1 may determine that transaction D is executable and start to execute transaction D. Thread 1, after executing complete transaction D, may delete transaction D in the head entry of the access list for variable x and transaction D in the head entry of the access list for variable y.

Thread 2 may similarly determine whether a transaction in the transaction queue for variable y is executable, since thread 1 has already begun executing transaction D, thread 2 may determine that transaction D is not executable and proceed to determine whether transaction E is executable. Thread 2 reads transaction information x.1, y.1 for transaction E, i.e., transaction E accesses variable x with sequence number 1 and variable y with sequence number 1. Thread 2 can determine from the current variable information: the sequence number of the current head table entry of the variable x is 1 and is consistent with the sequence number of the transaction E access variable x, and the sequence number of the current head table entry of the variable y is 1 and is consistent with the sequence number of the transaction E access variable y. Thread 2 continues to determine from the access list of variable x the non-top position of transaction E in the transaction queue (i.e., after transaction D), and thus may confirm that transaction E is not currently executable. Thread 2 may execute transaction E after transaction D execution is complete.

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

a pre-execution unit 51, configured to pre-execute a plurality of received transactions, and generate an access list of each of a plurality of variables and transaction information of each transaction, where the access list includes a plurality of entries arranged in sequence, each entry includes a sequence number of the entry, a transaction identifier for accessing the variable, and an access type, the sequence number corresponds to an access sequence of the transaction in the entry to the variable, and the transaction information includes the variable identifier for accessing the transaction and the sequence number corresponding to the access of the variable;

a sending unit 52, configured to send the access list of the multiple variables and the transaction information of the multiple transactions to the slave node of the blockchain.

In one embodiment, in a plurality of entries in the access list, the access types of each two adjacent entries include a shared type and an exclusive type, the entries of the shared type include transaction identifications of one or more transactions that read the variable, and the entries of the exclusive type include transaction identifications of one or more transactions that write the variable sequentially.

In an embodiment, the multiple transactions include a first transaction, where the first transaction includes a read operation on the first variable, and the pre-execution unit 51 is specifically configured to:

after the first transaction is completed by pre-execution, in the case that a first entry of a first access list of the first variable, which is a current tail entry, is a shared type, adding an identifier of the first transaction to a transaction set of the first entry, and recording the first sequence number and the identifier of the first variable in association with each other in transaction information of the first transaction;

in a case that a first entry of a first access list of the first variable, which is a current tail entry, is an exclusive type, adding a second entry after the first entry in the first access list, the second entry including: and recording a second sequence number, a sharing type and a transaction set comprising a first transaction identifier into the transaction information of the first transaction in a manner of being associated with the identifier of the first variable.

In an embodiment, the multiple transactions include a first transaction, where the first transaction includes a write operation on the first variable, and the pre-execution unit 51 is specifically configured to:

after pre-execution of the first transaction is completed, in the case that a first entry of a first access list of the first variable, which is a current tail entry, is an exclusive type, the first transaction is sequentially added to a transaction queue in the first entry, and the first sequence number and an identifier of the first variable are recorded in transaction information of the first transaction in an associated manner;

in a case that a first entry of a first access list of the first variable, which is a current tail entry, is a shared type, adding a second entry in the first access list after the first entry, the second entry including: and recording a second sequence number, an exclusive type and a transaction queue comprising the identification of the first transaction into the transaction information of the first transaction in a way of being associated with the identification of the first variable.

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

In an embodiment, the pre-execution read-write set of the first transaction includes a read operation on a first variable, and the pre-execution unit 51 is specifically configured to: and 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 updating the pre-execution state set based on the pre-execution read-write set of the first transaction in the case of consistency.

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

a receiving unit 61, configured to receive, from the master node, an access list of multiple variables and transaction information of multiple transactions, where the access list of multiple variables and the transaction information of multiple transactions are generated after the master node performs the multiple transactions in advance, where the access list includes multiple entries arranged in sequence, each entry includes a sequence number of the entry, a transaction identifier for accessing the variable, and an access type, the sequence number corresponds to an access sequence of the transaction in the entry for the variable, and the transaction information includes the variable identifier for accessing the transaction and a sequence number corresponding to access to the variable;

an execution unit 62 for executing the plurality of transactions based on the access list of the plurality of variables and the transaction information of the plurality of transactions.

In an embodiment, the execution unit 62 is specifically configured to:

selecting a first access list of a first variable, wherein a current head table item of the first access list comprises an identifier of a first transaction;

reading transaction information of the first transaction, and determining a plurality of variables accessed by the first transaction and sequence numbers corresponding to the variables, wherein the variables comprise the first variable;

determining that the first transaction is not executable in the event that the sequence number corresponding to any of the plurality of variables is determined to be inconsistent with the sequence number in the head entry in the current access list for that variable.

In an embodiment, the execution unit 62 is specifically configured to:

after determining that a second transaction of the plurality of transactions is executable, executing the second transaction, the second transaction including access to a second variable;

deleting the second transaction in a current header entry in a second access list of the second variable.

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 for 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 operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. 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 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 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, as for the system embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and reference may be made to the partial description of the method embodiment for relevant points. 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 pre-executes a plurality of received transactions and generates respective access lists of a plurality of variables and transaction information of each transaction, wherein each access list comprises a plurality of items which are sequentially arranged, each item comprises a sequence number of the item, a transaction identifier for accessing the variable and an access type, the sequence number corresponds to the access sequence of the transaction in the item to the variable, and the transaction information comprises the variable identifier for transaction access and the sequence number corresponding to the access of the variable;

2. The method of claim 1, wherein the access types of each two adjacent entries in the plurality of entries in the access list include a shared type and an exclusive type, the shared type entry includes a transaction set for reading the variable, the exclusive type entry includes a transaction queue for writing the variable, and the transaction queue includes one or more transactions arranged in sequence.

3. The method of claim 2, wherein the plurality of transactions includes a first transaction that includes only a read operation on the first variable, the master node pre-executes the received plurality of transactions, and generating an access list for each of the plurality of variables and transaction information for each transaction includes:

after pre-executing to complete the first transaction, in a case that a first entry of a first access list of the first variable, which is a current tail entry, is a shared type, the master node adds an identifier of the first transaction to a transaction set of the first entry, and records the first sequence number and the identifier of the first variable in association with transaction information of the first transaction;

4. The method of claim 2, the plurality of transactions including a first transaction that includes a write operation to the first variable, the master node pre-executing the received plurality of transactions, generating an access list for each of the plurality of variables and transaction information for each transaction including:

after pre-executing to complete the first transaction, in a case that a first entry of a first access list of the first variable, which is a current tail entry, is an exclusive type, the master node sequentially adds the first transaction to a transaction queue in the first entry, and records the first sequence number and an identifier of the first variable in transaction information of the first transaction in an associated manner;

5. The method of claim 1 or 2, wherein the slave node performing the plurality of transactions based on the accessed list of the plurality of variables and transaction information for the plurality of transactions comprises:

selecting a first access list of a first variable from the slave node, wherein a current head table entry of the first access list comprises an identifier of a first transaction;

in an instance in which it is determined that the sequence number corresponding to any of the plurality of variables does not coincide with the sequence number in the head entry in the current access list for that variable, it is determined that the first transaction is not currently executable.

6. The method of claim 2 or 5, wherein the slave node performing the plurality of transactions based on the accessed list of the plurality of variables and the transaction information for the plurality of transactions further comprises:

selecting a second access list of a second variable from the slave node, wherein a current head table entry of the second access list comprises an identifier of a second transaction;

reading transaction information of the second transaction, and determining that the second transaction accesses a third variable, wherein the access corresponds to a second sequence number of the third variable;

after determining that the second sequence number is consistent with the sequence number of the current head entry in the third access list of the third variable and the access type of the current head entry in the third access list is an exclusive type, determining that the second transaction is not currently unexecutable when determining that the second transaction is not the first-ranked transaction in the transaction queue of the current head entry in the third access list.

7. The method of claim 5 or 6, wherein the slave node performing the plurality of transactions based on the accessed list of the plurality of variables and the transaction information for the plurality of transactions further comprises:

after determining that a fourth transaction of the plurality of transactions is executable, executing the fourth transaction, the fourth transaction including access to a fourth variable;

deleting said fourth transaction in a current header entry in a fourth access list of said fourth variable.

8. The method of claim 3 or 4, the pre-execution by the master node of the received plurality of transactions comprising pre-execution by the master node of a received first transaction based on a set of pre-execution states, the set of pre-execution states updated based on a set of pre-execution reads and writes of the first transaction after pre-execution completes the first transaction.

9. The method of claim 8, 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: and 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 updating the pre-execution state set based on the pre-execution read-write set of the first transaction in the case of consistency.

10. The method of claim 8, wherein the table entry further includes a version number, the version number indicates a version corresponding to the variable, the pre-execution read-write set of the first transaction includes a read operation on the first variable, and the method further comprises: when the master node pre-executes the first transaction, recording a latest first sequence number and a latest first version number of a tail table entry of the first variable corresponding to a read operation of the first variable, where updating the pre-execution state set based on a pre-execution read-write set of the first transaction includes: and determining whether the first sequence number and the first version number are consistent with the latest second sequence number and the latest second version number of the current tail table entry of the first variable, and updating the pre-execution state set based on the pre-execution read-write set of the first transaction in the case of consistency.

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

the main node is used for pre-executing a plurality of received transactions, and generating respective access lists of a plurality of variables and transaction information of each transaction, wherein each access list comprises a plurality of items which are arranged in sequence, each item comprises a sequence number of the item, a transaction identifier for accessing the variable and an access type, the sequence number corresponds to the access sequence of the transaction in the item to the variable, and the transaction information comprises the variable identifier for accessing the transaction and the sequence number corresponding to the access of the variable; transmitting the access list of the plurality of variables and transaction information of the plurality of transactions to the slave node;

12. A blockchain master node, comprising:

13. The master node of claim 12, wherein the access types of each two adjacent entries in the plurality of entries in the access list include a shared type and an exclusive type, the entries of the shared type include transaction identifiers of one or more transactions that read the variable, and the entries of the exclusive type include transaction identifiers of one or more transactions that write the variable sequentially.

14. The master node of claim 13, wherein the plurality of transactions comprises a first transaction that includes only a read operation of the first variable, and wherein the pre-execution unit is specifically configured to:

after the first transaction is completed by pre-execution, in the case that a first entry of a first access list of the first variable as a current tail entry is of a shared type, adding an identifier of the first transaction to a transaction set of the first entry, and recording the first sequence number in association with the identifier of the first variable into transaction information of the first transaction;

15. The master node of claim 13, wherein the plurality of transactions comprises a first transaction comprising a write operation to the first variable, and wherein the pre-execution unit is specifically configured to:

16. The master node of claim 14 or 15, 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.

17. The master node of claim 16, the pre-execution read-write set of the first transaction to include a read operation on a first variable, the pre-execution unit to: and 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 updating the pre-execution state set based on the pre-execution read-write set of the first transaction in the case of consistency.

18. A blockchain slave node comprising:

a receiving unit, configured to receive, from the master node, an access list of multiple variables and transaction information of multiple transactions, where the access list of multiple variables and the transaction information of multiple transactions are generated after the master node performs the multiple transactions in advance, where the access list includes multiple entries that are sequentially arranged, each entry includes a sequence number of the entry, a transaction identifier that accesses the variable, and an access type, the sequence number corresponds to an access sequence of the transaction in the entry to the variable, and the transaction information includes the variable identifier that the transaction accesses and a sequence number corresponding to the access of the variable;

19. The slave node according to claim 18, wherein the execution unit is specifically configured to:

20. The slave node according to claim 19, wherein the execution unit is specifically configured to: