Methods of performing transactions, blockchains, primary nodes and secondary nodes

Abstract

A method for executing transactions in a blockchain, a blockchain, a master node and a slave node, the method comprising: the master node pre-executing a plurality of received transactions, generating a plurality of variable respective access lists and respective transaction information of the transactions, wherein the access list comprises a plurality of entries arranged in sequence, each entry comprising a sequence number of the entry, a transaction identifier accessing the variable and an access type, the sequence number corresponding to an access order of the transaction in the entry to the variable, and the transaction information comprising a variable identifier accessed by the transaction and a sequence number corresponding to the access to the variable; the master node sending the access lists of the plurality of variables and the transaction information of the plurality of transactions to the slave node; and the slave node executing the plurality of transactions based on the access lists of the plurality of variables and the transaction information of the plurality of transactions.

Description

TECHNICAL FIELD

[0001] The embodiment of the present specification belongs to the technical field of blockchains, and particularly relates to a method for executing transactions in a blockchain, a blockchain, a master node and a slave node. BACKGROUND

[0002] A blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism and encryption algorithm. In a blockchain system, data blocks are combined into a chain-type data structure in a sequential manner according to time sequence, and are guaranteed to be non-tamperable and non-forgable by cryptography. Due to the characteristics of decentralization, information non-tamperability and autonomy, the blockchain has attracted more and more attention and application. However, since the transactions calling the smart contract cannot predict the accessed variables before execution, they cannot be executed in parallel. SUMMARY

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

[0004] The first aspect of the present specification provides a method for executing transactions in a blockchain, the blockchain comprising a master node and a slave node, the method comprising:

[0005] The master node pre-executes a plurality of received transactions, generates a plurality of variable access lists and transaction information of each transaction, wherein the access list comprises a plurality of table entries arranged in sequence, each table entry comprising a sequence number of the table entry, a transaction identifier accessing the variable and an access type, the sequence number corresponding to the access order of the transaction in the table entry to the variable, and the transaction information comprising a variable identifier accessed by the transaction and a sequence number corresponding to the access to the variable;

[0006] The master node sends the access lists of the plurality of variables and the transaction information of the plurality of transactions to the slave node;

[0007] The slave node executes the plurality of transactions based on the access lists of the plurality of variables and the transaction information of the plurality of transactions.

[0008] The second aspect of the present specification provides a blockchain comprising a master node and a slave node,

[0009] The master node is configured to pre-execute the received plurality of transactions, generate an access list of each of a plurality of variables and transaction information of each of the plurality of transactions, wherein the access list comprises a plurality of entries arranged in sequence, each entry comprising a sequence number of the entry, a transaction identifier accessing the variable and an access type, the sequence number corresponding to an access sequence of the variable by the transaction in the entry, and the transaction information comprising a variable identifier accessed by the transaction and a sequence number corresponding to the access of the variable; and send the access list of the plurality of variables and the transaction information of the plurality of transactions to the slave node.

[0010] The slave node is configured 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.

[0011] The third aspect of the present specification provides a blockchain master node, comprising:

[0012] a pre-execution unit configured to pre-execute a plurality of received transactions, generate an access list of each of a plurality of variables and transaction information of each of the plurality of transactions, wherein the access list comprises a plurality of entries arranged in sequence, each entry comprising a sequence number of the entry, a transaction identifier accessing the variable and an access type, the sequence number corresponding to an access sequence of the variable by the transaction in the entry, and the transaction information comprising a variable identifier accessed by the transaction and a sequence number corresponding to the access of the variable;

[0013] a sending unit configured to send the access list of the plurality of variables and the transaction information of the plurality of transactions to a slave node of the blockchain.

[0014] The fourth aspect of the present specification provides a blockchain slave node, comprising:

[0015] a receiving unit configured to receive an access list of a plurality of variables and transaction information of a plurality of transactions from the master node, the access list of the plurality of variables and the transaction information of the plurality of transactions being generated after the master node pre-executes the plurality of transactions, wherein the access list comprises a plurality of entries arranged in sequence, each entry comprising a sequence number of the entry, a transaction identifier accessing the variable and an access type, the sequence number corresponding to an access sequence of the variable by the transaction in the entry, and the transaction information comprising a variable identifier accessed by the transaction and a sequence number corresponding to the access of the variable;

[0016] an execution unit configured 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.

[0017] The scheme for executing transactions in the blockchain provided by the embodiment of the present specification is executed by the slave node according to the access queue of the variable generated by the master node and the transaction information, and for the transactions without conflicts, the transactions can be executed in parallel, and for the transactions with conflicts, the transactions can be executed in sequence according to the sequence of the transactions recorded in the access queue, thereby improving the transaction execution efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings required in the embodiment description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can be obtained by those skilled in the art without creative labor.

[0019] Figure 1 The blockchain architecture diagram applied to an embodiment of the present specification;

[0020] Figure 2 The method flow chart for executing transactions in the blockchain in an embodiment of the present specification;

[0021] Figure 3 The process schematic diagram for generating access list and transaction information in an embodiment of the present specification;

[0022] Figure 4 The process schematic diagram for executing transactions in the slave node in an embodiment of the present specification;

[0023] Figure 5 The architecture diagram of the blockchain master node in an embodiment of the present specification;

[0024] Figure 6 The architecture diagram of a blockchain slave node in an embodiment of the present specification. DETAILED DESCRIPTION

[0025] In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the present specification will be described clearly and completely in the following with reference to the drawings in the embodiments of the present specification. Obviously, the described embodiments are only some embodiments of the present specification, not all. Based on the embodiments in the present specification, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the present specification.

[0026] Figure 1 The blockchain architecture diagram applied to an embodiment of the present specification is shown. As shown in the figure, Figure 1In the blockchain, for example, there are 6 nodes including the master node 1 and the slave nodes 2-6. The connection between the nodes schematically represents a P2P (Peer to Peer) connection. All the nodes store the full amount of the ledger, that is, all the blocks and the state of all the accounts. Each node in the blockchain produces the same state in the blockchain by executing the same transactions, and each node in the blockchain stores the same state database. The difference is that the master node 1 can be responsible for receiving transactions from the client and initiating a consensus proposal to each slave node, which includes, for example, a plurality of transactions in a block to be chunked (for example, block B1) and the submission order of each transaction in the consensus proposal. After the nodes in the blockchain reach a consensus on the consensus proposal, each node can execute the plurality of transactions according to the submission order in the consensus proposal, thereby generating the block B1.

[0027] It can be understood that Figure 1 The blockchain shown is only exemplary, and the embodiments of the present specification are not limited to being applied to Figure 1 The blockchain shown, for example, can also be applied to a blockchain system including sharding.

[0028] In addition, Figure 1 Although the blockchain includes 6 nodes in the above description, the embodiments of the present specification are not limited thereto, but can include other numbers of nodes. Specifically, the nodes included in the blockchain can meet the Byzantine Fault Tolerance (BFT) requirement. The Byzantine Fault Tolerance requirement can be understood as that there can be a Byzantine node inside the blockchain, but the blockchain does not exhibit Byzantine behavior externally. 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, for example, the Practical Byzantine Fault Tolerance (PBFT).

[0029] The transaction in the blockchain field can refer to a task unit executed in the blockchain and recorded in the blockchain. The transaction usually includes a sending field (From), a receiving field (To), and a data field (Data). In the case of a transfer transaction, the From field represents the account address that initiates the transaction (i.e., initiates the transfer task to another account), the To field represents the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract in the blockchain, the From field represents the account address that initiates the transaction, the To field represents the account address of the contract called by the transaction, and the Data field includes the function name in the called contract and the input parameters of the function, etc., for obtaining the code of the function from the blockchain and executing the code of the function when the transaction is executed.

[0030] A smart contract can be provided in a blockchain. A smart contract on a blockchain is a contract that can be triggered by a transaction to be executed on a blockchain system. A smart contract can be defined in the form of code. In Ethereum, a smart contract is invoked by initiating a transaction pointing to the address of the smart contract, so that each node in the Ethereum network runs the smart contract code distributedly. It should be noted that a smart contract can be created by a user or set by the system in a genesis block. Such a contract is generally referred to as a genesis contract. Generally, the genesis contract can set some data structures, parameters, attributes and methods of the blockchain. In addition, an account with system administrator permission can create or modify a system-level contract (referred to as a system contract). The system contract can be used to add data structures of different businesses in the blockchain.

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

[0032] In the scenario of invoking a contract, for example, Bob sends a transaction for invoking a smart contract to a blockchain as shown in Figure 1 The from field of the transaction is the address of the account of the transaction initiator (i.e., Bob), the "0x6f8ae93…" in the to field represents the address of the invoked smart contract, and the data field of the transaction includes the method and parameters of the invoked smart contract. After the transaction is consensus in the blockchain, each node in the blockchain can execute the transaction respectively, so as to execute the contract respectively, and update the state database based on the execution of the contract.

[0033] In the related art, in order to improve the transaction per second (TPS) index in the blockchain, the execution speed of the transaction needs to be accelerated. To this end, the blockchain node can accelerate the execution speed of the transaction by executing the transaction in parallel. In one implementation, the blockchain node can execute the transaction in parallel by multiple processes in a single machine, and in another implementation, the blockchain node can be deployed in a server cluster to execute the transaction in parallel by multiple servers. Generally, for a transfer transaction, the blockchain node first divides multiple transactions into multiple transaction groups according to the accounts accessed by the transactions, and each transaction group does not access the same account, so that each transaction group can be executed in parallel. However, when a smart contract is called in a transaction, the variables accessed in the transaction cannot be predicted before the transaction is executed, so that multiple transactions cannot be effectively grouped, and the transactions cannot be executed in parallel.

[0034] In another related art, the transaction can be executed by a master node, and the execution result is sent to a slave node for verification. In order to speed up the verification stage, the master node only packs non-conflicting transactions during execution, and defers conflicting transactions to the next block packing, so that the slave node can achieve concurrent verification. However, in this way, when the conflict rate between transactions is high, these transactions will be placed in different blocks, which reduces system performance and increases storage costs.

[0035] Figure 2 For the method flowchart of executing a transaction in a blockchain in an embodiment of the present specification, the method can be executed by Figure 1 the master node and each slave node shown in Figure 2 The master node 1 and the slave node 2 are shown as an example in

[0036] As shown in Figure 2 First, in step S201, the master node 1 pre-executes the received multiple transactions to generate an access list of each variable and transaction information of each transaction.

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

[0038] After successfully pre-executing each transaction, the master node 1 maintains the latest state set of the variable (hereinafter referred to as the pre-execution state set) according to the read and write operations of each transaction on the variable, and pre-executes other transactions according to the pre-execution state set.

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

[0040] After the master node 1 completes the pre-execution of the transaction Txi, it determines whether the pre-execution read set of the transaction Txi is consistent with the variable values in the pre-execution state set. If not, it means that the transaction Txi conflicts with other previously pre-executed transactions, and the master node 1 re-pre-executes the transaction Txi. If yes, it means that the transaction Txi is successfully pre-executed, and the master node 1 updates the pre-execution state set according to the pre-execution read-write set of the transaction Txi, i.e., updates the key-value pair of variable B in the pre-execution read-write set to the pre-execution state set.

[0041] The master node 1 can update the access list of a variable after completing the pre-execution of each transaction, and generate transaction information of the transaction according to the access list of the variable. The access list includes a plurality of table entries arranged in sequence, each table entry including a sequence number of the table entry, a transaction identifier accessing the variable, and an access type, and the sequence number corresponds to an access sequence of the transaction accessing the variable in the table entry. Specifically, the access list can be in the form of a linked list. The access type includes a shared type and an exclusive type. If a transaction only includes a read operation on a variable, the access type of the transaction accessing the variable is the shared type, and if a transaction only includes a write operation on a variable or includes a write operation and a read operation on a variable, the access type of the transaction accessing the variable is the exclusive type. The transaction information includes a variable identifier accessed by the transaction and a sequence number corresponding to the access of the variable by the transaction. The master node 1 can store the sequence number corresponding to the access of the variable by the transaction in the pre-execution read-write set of the transaction in association with the read or write variable.

[0042] Figure 3 A schematic diagram of the process of generating the access list and the transaction information in an embodiment of the present specification.

[0043] Reference Figure 3In the upper part, assuming that transaction A includes read access to variable x, master node 1 updates the information of variable x in the variable information after pre-execution of transaction A. Assuming that the current variable information does not include the access list of variable x, master node 1 generates the first entry of the access list of variable x. This first entry is both the head entry and the tail entry of the access list of variable x. The sequence number of this first entry is 0, the access type is shared, and the transaction set ( Figure 3 The transaction information section (shown by {}) includes the identifier of transaction A (e.g., "A"). Masternode 1 also adds information about transaction A to the transaction information section, which associates the identifier of variable x with the sequence number (e.g., "x.0") corresponding to transaction A's access to variable x.

[0044] Assuming that transaction B also includes a read access to variable x, after pre-executing transaction B, master node 1 can determine, based on the variable information, that the access type of the last entry in the access list for variable x (i.e., the entry with sequence number 0) is shared. Therefore, master node 1 can directly add transaction B's identifier to the transaction set in that entry. Simultaneously, master node 1 adds transaction B's information to the transaction information section, which associates the identifier of variable x with the sequence number corresponding to transaction B's access to variable x (e.g., "x.0").

[0045] I understand. Figure 3 Although it is shown that both transaction A and transaction B are written into one table entry of the access queue, the embodiments of this specification are not limited to this. For example, transaction A and transaction B can also be written into two table entries with different sequence numbers, and the sharing type in the two table entries is used to determine whether the two variables can be executed in parallel.

[0046] Assuming that transaction C includes write access to a variable, after pre-execution of transaction C, master node 1 generates the first entry in the access list of variable y in the variable information, similar to the above. The sequence number of this entry is 0, the access type is exclusive, and the transaction queue ( Figure 3 The transaction queue is different from the transaction set described above in that, when executing a transaction (or verifying whether a transaction is executable), the order of the transactions in the transaction set does not need to be considered, but the order of the transactions in the transaction queue needs to be considered. At the same time, the master node 1 adds the information of transaction C to the transaction information section, in which the identifier of variable y and the sequence number corresponding to the access of variable y by transaction C (for example, "y.0") are recorded in association. It can be understood that, assuming that transaction C includes a read operation on variable y in addition to a write operation on variable y, the table entry of variable y and the transaction information of transaction C shown in the upper part of Table 3 are generated in the same way.

[0047] That is, after the master node 1 completes the pre-execution of transactions A, B, and C, it obtainsFigure 3 The variable information and the transaction information shown in the upper part.

[0048] Referring to the middle part of FIG. 1C, assume that the transaction D includes write access to the variable x and read access to the variable y. After pre-executing the transaction D, the master node 1 sequentially adds a table item as a new tail table item in the access list of the variable x. The added table item has a sequence number of 1, an access type of exclusive type, and an identification of the transaction D in the transaction queue. For the variable y, since the access type of the current tail table item of the variable y is shared type (refer to the upper part of FIG. 1C), the master node 1 sequentially adds a table item as a new tail table item in the access list of the variable y. The added table item has a sequence number of 1, an access type of shared type, and an identification of the transaction D in the transaction set. Meanwhile, the master node 1 adds information of the transaction D in the transaction information, which records the variable x and the sequence number 1 in association, and records the variable y and the sequence number 1 in association. Figure 3 Figure 3 Figure 3 Referring to the lower part of FIG. 1C, assume that the transaction E includes write access to the variable x and read access to the variable y. After pre-executing the transaction E, the master node 1 sequentially adds an identification of the transaction D in the transaction queue in the tail table item of the variable x. For the variable y, since the access type of the current tail table item of the variable y is shared type (refer to the middle part of FIG. 1C), the master node 1 adds an identification of the transaction E in the transaction set in the tail table item of the variable y. Meanwhile, the master node 1 adds information of the transaction E in the transaction information, which records the variable x and the sequence number 1 in association, and records the variable y and the sequence number 1 in association.

[0049] Referring to the lower part of FIG. 1C, assume that the transaction E includes write access to the variable x and read access to the variable y. After pre-executing the transaction E, the master node 1 sequentially adds an identification of the transaction D in the transaction queue in the tail table item of the variable x. For the variable y, since the access type of the current tail table item of the variable y is shared type (refer to the middle part of FIG. 1C), the master node 1 adds an identification of the transaction E in the transaction set in the tail table item of the variable y. Meanwhile, the master node 1 adds information of the transaction E in the transaction information, which records the variable x and the sequence number 1 in association, and records the variable y and the sequence number 1 in association. Figure 3 Figure 3 Figure 3

[0050] It can be understood that, although the lower part of FIG. 1C shows that the transaction D and the transaction E are recorded in the transaction queue in one table item, the embodiments of the present specification are not limited thereto. For example, the transaction D and the transaction E can be written in two table items of different sequence numbers, so that the execution order of the transaction D and the transaction E can be indicated by the order of the sequence numbers. Figure 3

[0051] In an implementation, in the table item, in addition to recording the sequence number as shown in the lower part of FIG. 1C, another version number can also be recorded. For example, as shown in FIG. 1D, a version number 1 is recorded in the table item of the variable x, and a version number 2 is recorded in the table item of the variable y. Figure 3 Figure 3 ​​​​​​​As shown in the middle part of FIG. 2B, after the pre-execution of the transaction D, the second table entry of the variable x is added with a version number "1" in addition to the sequence number "1". Figure 3 As shown in the lower part of FIG. 2B, after the pre-execution of the transaction E, the version number of the second table entry of the variable x is increased by 1, i.e., updated to "2". In the shared table entry, the version number can be set as a constant preset value or a null value. Assuming that the transaction F includes a read of the variable x, when the master node pre-executes the transaction F, the sequence number and the version number of the tail table entry of the variable x recorded 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 as shown in the upper part of FIG. 2B, then the sequence number of the tail table entry recorded is 0, and the version number is null. Figure 4 As shown in the upper part of FIG. 2B, then the sequence number of the tail table entry recorded is 0, and the version number is null. If the access queue of the variable x when the transaction F reads the variable x is as shown in the middle part of FIG. 2B, Figure 4 As shown in the middle part of FIG. 2B, then the sequence number of the tail table entry recorded is 0, and the version number is null. If the access queue of the variable x when the transaction F reads the variable x is as shown in the middle part of FIG. 2B,

[0052] In step S203, the master node 1 sends the variable information and the transaction information to the slave node 2.

[0053] The master node 1 can pre-execute a plurality of transactions as described above, so as to obtain 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 can send the transaction information of the plurality of transactions and the access list of the plurality of variables to each of the slave nodes (including the slave node 2) as a consensus proposal. The master node 1 can also send the received plurality of transactions to each of the slave nodes. It can be understood that each of the slave nodes can also receive the plurality of transactions from other slave nodes or clients. Each of the slave nodes can also receive the transaction information of the plurality of transactions and the access list of the plurality of variables from other slave nodes.

[0054] 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.

[0055] The transactions can be executed in parallel by multiple threads in the slave node 2. Specifically, multiple variables in the variable information can be divided into multiple groups, so that each thread executes transactions according to the access list of multiple variables in one group. For example, thread 1 can process the access list of variable x, and thread 2 can process the access list of variable y in parallel.

[0056] Figure 4 A process of executing transactions in a slave node in an embodiment of the present specification is schematically shown.

[0057] Referring to Figure 4 The upper part of FIG. 1, thread 1 first reads the head entry of the access list of variable x, and obtains the identities of transaction A and transaction B from the transaction set in the head entry. Then, thread 1 reads the transaction information x.0 of transaction A, that is, transaction A only accesses variable x, and the corresponding sequence number of the access is 0, which is consistent with the sequence number in the head entry of the current variable x, so thread 1 determines that transaction A is currently executable. Similarly, thread 1 can determine that transaction B is currently executable. That is, transaction A and transaction B can be executed in parallel at present. Thread 1 can instruct another thread to execute transaction B, so that transaction A and transaction B are executed in parallel in slave node 2. Thread 1 can also execute transaction A and transaction B in series, or execute transaction A and transaction B in series in the order of “transaction B - transaction A”.

[0058] In parallel with thread 1, thread 2 reads the head entry of the access list of variable y, and obtains the identity of transaction C from the transaction queue in the head entry. Then, thread 2 reads the transaction information y.0 of transaction C, and similarly determines that transaction C is currently executable. Therefore, thread 2 can execute transaction C. That is, in slave node 2, multiple transactions are executed in parallel according to the variable information and the transaction information, and the transaction execution efficiency is improved.

[0059] After thread 1 executes transaction A, the identity of transaction A in the transaction set in the head entry of variable x is deleted, and after executing transaction B, the head entry is deleted because only transaction B is left in the transaction set, so that the access list of variable x shown in the middle part of FIG. 1 is obtained. Figure 4

[0060] Referring to Figure 4 ​In the middle of the process, thread 1 again reads the current header entry for variable x and obtains the identifier of transaction D, which is ranked first in the transaction queue. Thread 1 then reads transaction D's transaction information, x.1, y.1. This indicates that transaction D accessed variable x with sequence number 1 and variable y with sequence number 1. Based on the current variable information, thread 1 determines that the sequence number of the current header entry for variable x is 1, which matches the sequence number used by transaction D to access variable x. The sequence number of the current header entry for variable y is 0, which does not match the sequence number used by transaction D to access variable y. Therefore, thread 1 determines that transaction D is currently unexecutable and must wait for transaction C to complete before it can be executed. This means that slave node 2, based on variable and transaction information, enables serial execution of multiple transactions with variable access conflicts, improving transaction execution accuracy. Furthermore, since transaction E is ranked after transaction D in the transaction queue, thread 1 determines that transaction E is currently unexecutable. After determining that transactions D and E are currently not executable, thread 1 can obtain other executable transactions based on the access lists of other variables in the group assigned to thread 1 for transaction execution, and read the access list of variable x again when idle to determine whether transaction D can be executed.

[0061] After executing transaction C, thread 2 deletes the current header entry in the access queue of variable y and obtains Figure 5 The access queue is shown in the lower middle section.

[0062] refer to Figure 6 At the bottom of the process, thread 1 again checks the transaction in the header entry of variable x. At this point, the sequence numbers corresponding to variables x and y in the transaction information of transaction D are consistent with the sequence numbers in the header entries of each variable in the variable information. Furthermore, transaction D is ranked first in the transaction queue in the access list entry of variable x and is also in the transaction set of the access list entry of another variable y accessed by transaction D (i.e., the transaction execution order is not affected). Therefore, thread 1 determines that transaction D is executable and begins executing transaction D. After completing transaction D, thread 1 deletes transaction D from the header entry of variable x's access list and the header entry of variable y's access list.

[0063] Thread 2 can similarly determine whether a transaction in the transaction queue of variable y is executable, since thread 1 has started to execute transaction D, thread 2 can determine that transaction D is not executable, and proceed to determine whether transaction E is executable. Thread 2 reads the transaction information x.1, y.1 of transaction E, i.e., transaction E accesses variable x with sequence number 1 and variable y with sequence number 1. According to the current variable information, thread 2 can determine that the sequence number of the current head table entry of variable x is 1, which is consistent with the sequence number of transaction E accessing variable x, and the sequence number of the current head table entry of variable y is 1, which is consistent with the sequence number of transaction E accessing variable y. Thread 2 continues to determine, according to the access list of variable x, that transaction E is in a position other than the first position in the transaction queue (i.e., after transaction D), and thus confirms that transaction E is currently not executable. Thread 2 can execute transaction E after transaction D is executed.

[0064] Figure 1 For the architecture diagram of the blockchain master node in an embodiment of the present specification, it includes:

[0065] The pre-execution unit 51 is configured to pre-execute the received plurality of transactions, and generate an access list of each variable and transaction information of each transaction, wherein the access list includes a plurality of sequentially arranged table entries, each table entry includes a sequence number of the table entry, a transaction identifier 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 includes a variable identifier accessed by the transaction and a sequence number corresponding to the access to the variable.

[0066] The sending unit 52 is configured to send the access list of the plurality of variables and the transaction information of the plurality of transactions to the slave node of the blockchain.

[0067] In an embodiment, in the plurality of table entries in the access list, the access types of each two adjacent table entries include a shared type and an exclusive type, the table entry of the shared type includes a transaction identifier of one or more transactions reading the variable, and the table entry of the exclusive type includes a transaction identifier of one or more transactions writing the variable in sequence.

[0068] In an embodiment, the plurality of transactions includes a first transaction, the first transaction includes a read operation on the first variable, and the pre-execution unit 51 is specifically configured to:

[0069] After pre-executing the first transaction, in a case where the first table entry as the current tail table entry of the first access list of the first variable is of the shared type, the identifier of the first transaction is added to the transaction set of the first table entry, and the first sequence number is recorded in the transaction information of the first transaction in association with the identifier of the first variable.

[0070] In a case where the first table item as a current tail table item in the first access list of the first variable is of the exclusive type, a second table item is added after the first table item in the first access list, the second table item including: a second sequence number, a shared type, a transaction set including an identification of the first transaction, and the second sequence number is recorded into transaction information of the first transaction in association with an identification of the first variable.

[0071] In an embodiment, the plurality of transactions includes a first transaction, the first transaction including a write operation on the first variable, and the pre-execution unit 51 is specifically configured to:

[0072] In a case where the first table item as a current tail table item in the first access list of the first variable is of the exclusive type, a second table item is added after the first table item in the first access list, the second table item including: a second sequence number, a shared type, a transaction set including an identification of the first transaction, and the second sequence number is recorded into transaction information of the first transaction in association with an identification of the first variable.

[0073] In a case where the first table item as a current tail table item in the first access list of the first variable is of the exclusive type, a second table item is added after the first table item in the first access list, the second table item including: a second sequence number, a shared type, a transaction set including an identification of the first transaction, and the second sequence number is recorded into transaction information of the first transaction in association with an identification of the first variable.

[0074] 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 pre-execution of the first transaction is completed, update the pre-execution state set based on a pre-execution read-write set of the first transaction.

[0075] In an embodiment, the pre-execution read-write set of the first transaction includes a read operation on the first variable, and the pre-execution unit 51 is specifically configured to: determine whether a value of the first variable in the pre-execution read-write set is consistent with a value of the first variable in the pre-execution state set, and in a case of consistency, update the pre-execution state set based on the pre-execution read-write set of the first transaction.

[0076] Figure 1 An architecture diagram of a blockchain slave node in an embodiment of the present specification includes:

[0077] The receiving unit 61 is configured to receive, from the master node, an access list of a plurality of variables and transaction information of a plurality of transactions, the access list of the plurality of variables and the transaction information of the plurality of transactions being generated by the master node after pre-executing the plurality of transactions, wherein the access list comprises a plurality of entries arranged in sequence, each entry comprising a sequence number of the entry, a transaction identifier of a transaction accessing the variable, and an access type, the sequence number corresponding to an access sequence of the transaction in the entry to the variable, and the transaction information comprising a variable identifier accessed by the transaction and a sequence number corresponding to the access to the variable.

[0078] The execution unit 62 is configured 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.

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

[0080] select a first access list of a first variable, the current head entry of the first access list comprising an identifier of a first transaction;

[0081] read the transaction information of the first transaction, and determine a plurality of variables accessed by the first transaction and a sequence number corresponding to each variable, the plurality of variables comprising the first variable;

[0082] in a case where the sequence number corresponding to any variable in the plurality of variables is inconsistent with the sequence number in the head entry in the current access list of the variable, determine that the first transaction is not executable.

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

[0084] after determining that a second transaction in the plurality of transactions is executable, execute the second transaction, the second transaction comprising an access to a second variable;

[0085] delete the second transaction in the current head entry in the second access list of the second variable.

[0086] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0087] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, 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 can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that, in addition to being implemented in pure computer readable program code form, the controller can perfectly well be implemented to perform the same functions in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. by means of logical programming of the method steps. Such a controller can thus be considered a hardware component, and the means comprised therein for performing the various functions can also be considered structures within the hardware component. Alternatively, or even, the means for performing the various functions can be considered both software modules implementing the method and structures within the hardware component.

[0088] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of computer technology in the future, computers implementing the functions of the above embodiments can be personal computers, laptop computers, vehicle-mounted human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, electronic mail devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0089] Although the method operations of the embodiments of the present specification are described in sequential order, some of the operations can in practical implementations be performed concurrently, in parallel, or in a different order. The above description of the embodiments of the present specification is provided as an example only and is not intended to be limiting. For example, the steps recited in the examples or flow charts can include more, fewer, or different steps than those described. The order in which the steps are presented is merely one example and is not intended to be limiting. The steps can be performed in an order different than presented, or performed in parallel, or in a different order, for example in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment. The terms "comprise", "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 can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Exclusion of such elements is only present if it is expressly stated that these elements are excluded. For example, use of the terms "first", "second", or the like does not denote any order or importance, but rather the terms are used to distinguish one element from another.

[0090] For ease of description, the above apparatuses are described in functional modules for description. Of course, when implementing one or more of the present specification, the functions of the modules can be implemented in one or more software and / or hardware, or the modules implementing the same function can be implemented by a combination of sub-modules or sub-units. The above-described apparatus embodiments are only illustrative. For example, the division of the units is only a logical function division, and in actual implementation, another division mode can be used, for example, a plurality of units or components can be combined or integrated into another system, or some features can be omitted or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed elements can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0091] The present application is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as combinations of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions of one or more flows and / or blocks Figure 1 The apparatuses that implement the functions specified in one or more flows and / or blocks.

[0092] These computer program instructions can 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 instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0093] These computer program instructions can 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 ​ function specified in the flow or flows and / or blocks ​ of the block or blocks.

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

[0095] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0096] Computer-readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage, graphene storage, or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0097] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, a system or a computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable code.

[0098] The one or more embodiments described herein can 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. The one or more embodiments described herein 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 can be located in both local and remote computer storage media including memory storage devices.

[0099] The various embodiments described in this specification are described in the context of progressive embodiments, with each embodiment building on the previous one. The same or similar parts between embodiments are cross-referenced as appropriate. Each embodiment focuses on the differences between that embodiment and the previous one. In particular, the system embodiments are described relatively simply, as they are substantially similar to the method embodiments. In the description of the specification, the description of the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the specific feature, structure, material or characteristic being described in connection with that embodiment or example is included in at least one embodiment or example in the specification. Illustrative representations of the above terms in the specification are not necessarily referring to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics being described can be combined in any suitable manner in one or more embodiments or examples. Furthermore, the skilled person can combine and combine features of different embodiments or examples and characteristics of different embodiments or examples in a manner that is not mutually contradictory.

[0100] The above description merely provides examples of the one or more embodiments described in this specification and does not limit the one or more embodiments described in this specification. The one or more embodiments described in this specification can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the one or more embodiments described in this specification should be included in the scope of the claims.

Claims

1. A method for executing transactions in a blockchain, the blockchain comprising a master node and a slave node, the method comprising: the master node pre-executing a plurality of received transactions, generating an access list for each of a plurality of variables and transaction information for each of the transactions, wherein the access list comprises a plurality of entries arranged in sequence, each entry comprising a sequence number of the entry, an identifier of a transaction accessing the variable and an access type, the sequence number corresponding to an access order of the transaction in the entry to the variable, and the transaction information comprising an identifier of the variable accessed by the transaction and a sequence number corresponding to the access to the variable; the master node sending the access list for each of the plurality of variables and the transaction information for each of the transactions to the slave node; and the slave node executing the plurality of transactions based on the access list for each of the plurality of variables and the transaction information for each of the transactions.

2. The method of claim 1, wherein, In the plurality of entries in the access list, the access type of each two adjacent entries comprises a shared type and an exclusive type, the entry of the shared type comprises a set of transactions reading the variable, and the entry of the exclusive type comprises a queue of transactions writing the variable, the queue of transactions comprising one or more transactions arranged in sequence. 3.The method of claim 2, the plurality of transactions comprising a first transaction, the first transaction comprising only a read operation to a first variable, the master node pre-executing the plurality of received transactions, generating the access list for each of the plurality of variables and the transaction information for each of the transactions comprising: the master node, after pre-executing the first transaction, in a case that a first entry of the first access list for the first variable as a current tail entry is of the shared type, adding an identifier of the first transaction to the set of transactions of the first entry, and recording a first sequence number in association with the identifier of the first variable to the transaction information of the first transaction; and in a case that the first entry of the first access list for the first variable as the current tail entry is of the exclusive type, adding a second entry to the first access list after the first entry, the second entry comprising a second sequence number, the shared type and the set of transactions comprising the identifier of the first transaction, and recording the second sequence number in association with the identifier of the first variable to the transaction information of the first transaction. 4.The method of claim 2, the plurality of transactions comprising a first transaction, the first transaction comprising a write operation to a first variable, the master node pre-executing the plurality of received transactions, generating the access list for each of the plurality of variables and the transaction information for each of the transactions comprising: the master node, after pre-executing the first transaction, in a case that a first entry of the first access list for the first variable as a current tail entry is of the exclusive type, adding a sequence of the first transaction to the queue of transactions in the first entry, and recording a first sequence number in association with the identifier of the first variable to the transaction information of the first transaction. In a case where a first table item as a current tail table item in a first access list of the first variable is of a shared type, a second table item is added in the first access list after the first table item, the second table item comprising a second sequence number, an exclusive type, and a transaction queue comprising an identification of a first transaction, and the second sequence number is recorded into transaction information of the first transaction in association with an identification of the first variable.

5. The method of claim 2, wherein, The slave node executes the plurality of transactions based on the access lists of the plurality of variables and the transaction information of the plurality of transactions further comprises: The slave node selects a second access list of a second variable, a current head table item of the second access list comprising an identification of a second transaction; The slave node reads transaction information of the second transaction, and determines that the second transaction accesses a third variable, and the access corresponds to a second sequence number of the third variable; After determining that the second sequence number is consistent with a sequence number of a current head table item in a third access list of the third variable, and an access type of the current head table item in the third access list is of an exclusive type, the slave node determines that the second transaction is currently not executable in a case where the second transaction is determined to be not a first transaction in a transaction queue of the current head table item in the third access list.

6. The method of claim 5, wherein, The slave node executes the plurality of transactions based on the access lists of the plurality of variables and the transaction information of the plurality of transactions further comprises: After determining that a fourth transaction in the plurality of transactions is executable, the slave node executes the fourth transaction, the fourth transaction comprising an access to a fourth variable; The slave node deletes the fourth transaction in a current head table item in a fourth access list of the fourth variable.

7. The method of claim 1 or 2, wherein, The slave node executes the plurality of transactions based on the access lists of the plurality of variables and the transaction information of the plurality of transactions comprises: The slave node selects a first access list of a first variable, a current head table item of the first access list comprising an identification of a first transaction; The slave node reads transaction information of the first transaction, and determines a plurality of variables accessed by the first transaction and a sequence number corresponding to each variable, the plurality of variables comprising the first variable; In a case where a sequence number corresponding to any variable in the plurality of variables is inconsistent with a sequence number in a head table item in a current access list of the variable, the slave node determines that the first transaction is currently not executable.

8. The method of claim 7, wherein, The slave node executes the plurality of transactions based on the access lists of the plurality of variables and the transaction information of the plurality of transactions further comprises: The slave node selects a second access list of a second variable, a current head table item of the second access list comprising an identification of a second transaction; The slave node reads transaction information of the second transaction, and determines that the second transaction accesses a third variable, and the access corresponds to a second sequence number of the third variable; After determining that the second sequence number is consistent with a sequence number of a current head table item in a third access list of the third variable, and an access type of the current head table item in the third access list is of an exclusive type, the slave node determines that the second transaction is currently not executable in a case where the second transaction is determined to be not a first transaction in a transaction queue of the current head table item in the third access list.

9. The method of claim 7, wherein, The slave node executes the plurality of transactions based on the access list of the plurality of variables and the transaction information of the plurality of transactions further includes: After determining that a fourth transaction in the plurality of transactions is executable, the fourth transaction is executed, the fourth transaction including access to a fourth variable; A current head entry in a fourth access list of the fourth variable is deleted.

10. The method of claim 3 or 4, wherein the pre-executing the received plurality of transactions by the master node includes pre-executing a first transaction received by the master node based on a pre-execution state set, and after pre-executing the first transaction, updating the pre-execution state set based on a pre-execution read-write set of the first transaction.

11. The method of claim 10, the pre-execution read-write set of the first transaction comprising a read operation on a first variable, the updating the pre-execution state set based on the pre-execution read-write set of 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 in the case of consistency, updating the pre-execution state set based on the pre-execution read-write set of the first transaction.

12. The method according to claim 10, wherein the table entry further includes a version number, the version number indicating 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 includes: The master node records the latest first sequence number and first version number of the tail entry of the first variable corresponding to the read operation of the first variable when pre-executing the first transaction, and the updating the pre-execution state set based on the pre-execution read-write set of the first transaction includes: determining whether the first sequence number and the first version number are consistent with the latest second sequence number and second version number of the current tail entry of the first variable, and in the case of consistency, updating the pre-execution state set based on the pre-execution read-write set of the first transaction.

13. A blockchain system comprising a master node and a slave node, The master node is configured to pre-execute the received plurality of transactions, generate a plurality of variable-specific access lists and transaction information for each of the transactions, wherein The access list includes a plurality of entries arranged in sequence, each entry including a sequence number of the entry, a transaction identifier accessing the variable, and an access type, the sequence number corresponding to the access order of the variable by the transaction in the entry, and the transaction information includes a variable identifier accessed by the transaction and a sequence number corresponding to the access to the variable; and the sending unit is configured to send 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 access list of the plurality of variables and the transaction information of the plurality of transactions.

14. A blockchain master node device, comprising: a pre-execution unit 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, wherein the access list includes a plurality of entries arranged in sequence, each entry including a sequence number of the entry, a transaction identifier accessing the variable, and an access type, the sequence number corresponding to the access order of the variable by the transaction in the entry, and the transaction information includes a variable identifier accessed by the transaction and a sequence number corresponding to the access to the variable; a sending unit configured to send the access list of the plurality of variables and the transaction information of the plurality of transactions to a slave node of the blockchain.

15. The master node device of claim 14, wherein, In the plurality of entries in the access list, the access types of each two adjacent entries include a shared type and an exclusive type, the entry of the shared type includes transaction identifiers of one or more transactions reading the variable, and the entry of the exclusive type includes transaction identifiers of one or more transactions writing the variable arranged in sequence.

16. The master node device according to claim 15, wherein the plurality of transactions include a first transaction, the first transaction only includes a read operation on a first variable, and the pre-execution unit is specifically configured to: After pre-execution completes the first transaction, if a first entry, which is a current tail entry, in a first access list of the first variable is of a shared type, adding an identifier of the first transaction to a transaction set of the first entry, and recording a first sequence number in association with the identifier of the first variable in transaction information of the first transaction; In a case where a first entry as a current tail entry in the first access list of the first variable is of an exclusive type, a second entry is added after the first entry in the first access list, the second entry including: A second sequence number, a sharing type, and a transaction set including a first transaction identifier, wherein the second sequence number is associated with the identifier of the first variable and recorded in the transaction information of the first transaction.

17. The master node device according to claim 15, wherein the plurality of transactions include a first transaction, the first transaction includes a write operation on a first variable, and the pre-execution unit is specifically configured to: After the pre-execution completes the first transaction, if a first entry, which is a current tail entry, in a first access list of the first variable is of an exclusive type, sequentially adding the first transaction to a transaction queue in the first entry, and recording a first sequence number in association with an identifier of the first variable in transaction information of the first transaction; In case the first table entry of the first access list of the first variable, which is the current tail table entry, is of a shared type, a second table entry is added in the first access list after the first table entry, the second table entry comprising: A second sequence number, an exclusive type, and a transaction queue including an identifier of the first transaction, and recording the second sequence number in association with the identifier of the first variable in the transaction information of the first transaction.

18. The master node device according to claim 16 or 17, wherein the pre-execution unit is specifically configured to pre-execute the received first transaction based on the pre-execution status set, and after pre-execution of the first transaction is completed, update the pre-execution status set based on the pre-execution read-write set of the first transaction.

19. According to the master node device according to claim 18, the pre-execution read-write set of the first transaction includes a read operation on the first variable, and the pre-execution unit is specifically used to: determine whether the value of the first variable in the pre-execution read-write set is consistent with the value of the first variable in the pre-execution status set, and if consistent, update the pre-execution status set based on the pre-execution read-write set of the first transaction.

20. A blockchain slave node device, comprising: a receiving unit, configured to receive, from a master node, an access list of multiple variables and transaction information of multiple transactions, wherein the access list of multiple variables and the transaction information of multiple transactions are generated by the master node after pre-executing the multiple transactions, wherein the access list includes multiple entries arranged in sequence, each entry including a sequence number of the entry, a transaction identifier for accessing the variable, and an access type, the sequence number corresponding to the order in which the transactions in the entry access the variable, and the transaction information including the variable identifier accessed by the transaction and the sequence number corresponding to the access to the variable; An execution unit is configured to execute the plurality of transactions based on the access lists of the plurality of variables and the transaction information of the plurality of transactions.

21. The slave node device of claim 20, wherein, The execution unit is specifically used for: select a first access list of a first variable, a current head entry of the first access list comprising an identification of a first transaction; read transaction information of the first transaction, and determine a plurality of variables accessed by the first transaction and a sequence number corresponding to each variable, the plurality of variables comprising the first variable; in a case where a sequence number corresponding to any variable in the plurality of variables is inconsistent with a sequence number in a head entry in a current access list of the variable, determine that the first transaction is currently not executable.

22. The slave node device according to claim 21, wherein: The execution unit is specifically configured to: after determining that a second transaction in the plurality of transactions is executable, execute the second transaction, the second transaction comprising an access to a second variable; delete the second transaction from a current head entry in a second access list of the second variable.

Images