CN112884587A

CN112884587A - Block chain transaction execution method, block chain node and control device

Info

Publication number: CN112884587A
Application number: CN202110481458.3A
Authority: CN
Inventors: 卓海振; 陆钟豪
Original assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-04-30
Filing date: 2021-04-30
Publication date: 2021-06-01
Anticipated expiration: 2041-04-30
Also published as: CN112884587B

Abstract

The present specification provides a blockchain transaction execution method, a blockchain node, and a control device, according to which a plurality of transactions belonging to a first block are acquired, the plurality of transactions being part of all transactions belonging to the first block; executing the plurality of transactions; the execution results of the plurality of transactions are consensus before all transactions belonging to the first block are executed. The delay caused by waiting for all transactions belonging to the first block to be performed is reduced.

Description

Block chain transaction execution method, block chain node and control device

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method for performing blockchain transaction, a blockchain node, and a control device.

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. The block chain is a chain data structure formed by combining data blocks in a sequential connection mode according to a time sequence, and is a distributed account book which is guaranteed in a cryptographic mode and cannot be tampered and forged. 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.

Currently, after determining the transactions included in the block through consensus, each node of the block chain is notified of the transactions included in the block. Each node of the block chain acquires and executes a plurality of transactions in the block, generates the block according to the execution results of the transactions, and stores the block in a block database of the node after the generated block is identified. An accounting node in the blockchain, for example, may return a receipt of the transaction to the user after consensus on the blocks.

Disclosure of Invention

One or more embodiments of the present disclosure are directed to a method for performing a blockchain transaction, a blockchain node and a control device.

According to a first aspect, there is provided a method for performing a blockchain transaction, applied to a node of a blockchain, including:

acquiring a plurality of transactions belonging to a first block, wherein the plurality of transactions are partial transactions in all transactions belonging to the first block;

executing the plurality of transactions;

the execution results of the plurality of transactions are consensus before all transactions belonging to the first block are executed.

Optionally, the method further includes:

after the execution results of the plurality of transactions are identified in common, the execution results of the transactions with successful identification are returned to the user equipment.

Optionally, the method further includes:

after the execution results of the transactions are identified, storing the data of the transactions in a block database as a partial block of the first block.

Optionally, after all transactions of the first block are executed and the consensus is completed, the method further comprises:

and storing the block head of the first block into the block database.

Optionally, the method further includes:

generating a block header for the first block at least after the consensus is completed for the execution results of all transactions belonging to the first block.

Optionally, the generating a block header of the first block at least after the execution results of all the transactions belonging to the first block are completely identified includes: and after the execution results of all the transactions belonging to the first block are subjected to consensus and the block consensus on the previous block of the first block is successful, generating a block header of the first block.

Optionally, after generating the block header of the first block, the method further includes: performing block consensus on the first block;

wherein the storing the block header of the first block into the block database includes: and if the block consensus of the first block is successful, storing the block head of the first block into the block database.

Optionally, the method further includes:

a first set of each of the plurality of transactions is obtained, the first set of any transaction including an identification of a parameter read by that transaction.

Optionally, the method further includes:

for each read parameter identifier in the respective first set of the multiple transactions, if the value of the parameter corresponding to the identifier is not stored in the cache region, obtaining the value of the parameter from the state database, and storing the value of the parameter into the cache region;

wherein the executing the plurality of transactions comprises: executing the plurality of transactions based on the values of the respective parameters stored by the cache.

Optionally, the cache region includes a first cache region and a second cache region; storing the value of the parameter into the buffer area comprises storing the value of the parameter into the first buffer area;

wherein the method further comprises:

after the execution results of the multiple transactions are identified in common, the values of the write parameters included in the execution results of the transactions that are identified successfully in the multiple transactions are stored in the second cache area relative to the blocks to which the transactions that are identified successfully belong.

Optionally, after the values of the written parameters included in the execution results of the transactions successfully identified in all the transactions belonging to the first block are stored in the second buffer area, the method further includes: and updating the world state in the state database according to the values of the parameters stored in the second cache region relative to the first block.

Optionally, the first set of any transaction further includes an identification of parameters written by the transaction;

wherein the obtaining of the plurality of transactions belonging to the first block comprises: obtaining all transactions for a plurality of blocks, the plurality of blocks including the first block;

wherein the executing the plurality of transactions comprises:

grouping the total transactions based on their respective first sets to obtain a plurality of transaction groups;

performing the following processing on the plurality of transaction groups in parallel: for each transaction group, the transactions included in the transaction group are executed serially.

Optionally, the consensus on the execution results of the multiple transactions includes: the results of execution of a predetermined number of transactions consecutively executed in any transaction group are identified, the predetermined number of transactions including the plurality of transactions.

According to a second aspect, there is provided a blockchain transaction execution method applied to a node of a blockchain, the node of the blockchain including a control device and a computing device, the method including:

the control device acquires a plurality of transactions belonging to a first block and sends the transactions to the computing device; the plurality of transactions are partial transactions in all transactions belonging to the first block;

the computing device executes the plurality of transactions and returns execution results of the plurality of transactions to the control device;

the control means agrees on the execution results of the plurality of transactions before the computing means executes all transactions belonging to the first block.

Optionally, the method further includes:

after the execution results of the plurality of transactions are identified in common, the control device returns the execution results of the transactions with successful identification to the user equipment.

Optionally, the node of the blockchain further includes a storage device; the method further comprises the following steps: after the consensus on the execution results of the plurality of transactions is completed, the control device instructs the storage device to store the data of the plurality of transactions in a block database as a partial block of the first block.

the control means instructs the storage means to store the block header of the first block in the block database.

Optionally, the method further includes:

the control means generates a block header of the first block at least after the execution results of all transactions belonging to the first block have completed consensus.

Optionally, the generating, by the control device, a block header of the first block at least after the execution results of all the transactions belonging to the first block are completely identified, includes: after the execution results of all transactions belonging to the first block are completely identified and the block identification of the previous block of the first block is successful, the control device generates a block header of the first block.

Optionally, after generating the block header of the first block, the method further includes: the control device performs block consensus on the first block;

wherein the controlling means instructs the storing means to store the block header of the first block into the block database, including: if the block consensus of the first block is successful, the control device instructs the storage device to store the block head of the first block into the block database.

Optionally, the method further includes:

the control device obtains a respective first set of the plurality of transactions, the first set of any transaction including an identification of a parameter read by that transaction.

Optionally, the method further includes:

for each read parameter identifier in the respective first set of the multiple transactions, if the value of the parameter corresponding to the identifier is not stored in the cache region, the control device obtains the value of the parameter from the state database of the storage device and stores the value of the parameter into the cache region;

wherein the computing device performs the plurality of transactions, including: the computing device executes the plurality of transactions based on the values of the respective parameters stored by the cache.

wherein the method further comprises:

after the execution results of the plurality of transactions are agreed, the control device stores the value of the write parameter included in the execution result of each transaction that is successfully agreed among the plurality of transactions in the second buffer area with respect to the block to which each transaction that is successfully agreed belongs.

Optionally, after the values of the written parameters included in the execution results of the transactions successfully identified in all the transactions belonging to the first block are stored in the second buffer area, the method further includes: and the control device instructs the storage device to update the world state in the state database according to the values of the parameters stored in the second cache region relative to the first block.

wherein the control device obtains a plurality of transactions belonging to a first block, including: the control device acquires all transactions of a plurality of blocks, wherein the plurality of blocks comprise the first block;

wherein the method further comprises:

the control device groups all the transactions based on the respective first set of all the transactions to obtain a plurality of transaction groups;

the computing device performs the plurality of transactions, including:

the computing device performs the following processing on the plurality of transaction groups in parallel: for each transaction group, the transactions included in the transaction group are executed serially.

Optionally, the controlling device agrees with the execution results of the plurality of transactions, and includes: the control means makes a consensus on the results of the execution of a predetermined number of transactions consecutively executed in any transaction group, the predetermined number of transactions including the plurality of transactions.

According to a third aspect, there is provided a node of a blockchain, the node comprising:

the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring a plurality of transactions belonging to a first block, and the transactions are partial transactions in all transactions belonging to the first block;

an execution module to execute the plurality of transactions;

and the result consensus module is used for performing consensus on the execution results of the plurality of transactions before all the transactions belonging to the first block are executed and completed.

According to a fourth aspect, there is provided a node of a blockchain, the node of the blockchain comprising control means and computing means;

the control device is used for acquiring a plurality of transactions belonging to a first block and sending the transactions to the computing device; and prior to the computing device performing all transactions belonging to the first block, consensus on the results of the performance of the plurality of transactions; the plurality of transactions are partial transactions in all transactions belonging to the first block;

the computing device is used for executing the plurality of transactions and returning the execution results of the plurality of transactions to the control device.

According to a fifth aspect, there is provided a control apparatus for a blockchain node, comprising:

a first acquisition unit for acquiring a plurality of transactions belonging to a first block; the plurality of transactions are partial transactions in all transactions belonging to the first block;

an instructing unit configured to instruct the block link point to execute the plurality of transactions;

a result consensus unit, configured to perform consensus on the execution results of the plurality of transactions before all transactions belonging to the first block are executed by the block link point.

According to a sixth aspect, there is provided a computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of any of the first or second aspects above.

According to a seventh aspect, there is provided a computing device comprising a memory having stored therein executable code and a processor that, when executing the executable code, implements the method of any of the first or second aspects above.

The technical scheme provided by the embodiment of the specification can have the following beneficial effects:

embodiments of the present disclosure provide a method for performing blockchain transactions and a blockchain node, which acquire a plurality of transactions belonging to a first block, where the plurality of transactions are partial transactions in all transactions belonging to the first block. The plurality of transactions are performed. The execution results of the plurality of transactions are consensus before all transactions belonging to the first block are executed. Since the execution result of the completed partial transaction is identified when the partial transaction is completed, the execution result of the transaction which is successfully identified can be returned to the user equipment without waiting for all the transactions belonging to the first block to be completed. Thus, the latency incurred by waiting for all transactions belonging to the first block to be performed is reduced.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1A is an architectural diagram of a blockchain system shown in accordance with an exemplary embodiment of the present description;

fig. 1B is a block chain node structure diagram of any one of the block chain nodes in the block chain system shown in the present specification according to an exemplary embodiment;

FIG. 2 is a flow chart illustrating a method of performing blockchain transactions according to an exemplary embodiment of the present description;

FIG. 3 is a flow chart illustrating another blockchain transaction execution method according to an exemplary embodiment of the present description;

FIG. 4 is a flow chart illustrating another blockchain transaction execution method according to an exemplary embodiment of the present description;

FIG. 5 is a flow chart illustrating another blockchain transaction execution method according to an exemplary embodiment of the present description;

FIG. 6 is a flow chart illustrating another blockchain transaction execution method according to an exemplary embodiment of the present description;

FIG. 7 is a flow chart illustrating another blockchain transaction execution method according to an exemplary embodiment of the present description;

FIG. 8 is a flow chart illustrating another blockchain transaction execution method according to an exemplary embodiment of the present description;

FIG. 9 is a schematic diagram illustrating a blockchain transaction execution scenario in accordance with an exemplary embodiment of the present description;

FIG. 10 is a schematic diagram of another blockchain transaction execution scenario shown in the present specification in accordance with an exemplary embodiment;

FIG. 11 is a block diagram illustrating a block link point according to an exemplary embodiment of the present disclosure;

FIG. 12 is a block diagram illustrating another block chain node structure according to an example embodiment;

fig. 13 is a block diagram illustrating a control apparatus for a blockchain node according to an exemplary embodiment of the present disclosure;

FIG. 14 is a block diagram illustrating a computing device according to an example embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the specification, as detailed in the appended claims.

The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

Fig. 1A is an architecture diagram illustrating a block chain system according to an exemplary embodiment. Fig. 1B is a schematic structural diagram of any blockchain node in the blockchain system.

In the architecture diagram shown in fig. 1A, nodes 1 to 6 are all block link points in a block link system. It is to be understood that fig. 1A is merely exemplary of 6 blockchain nodes, and that virtually any number of blockchain nodes may be included in a blockchain system. In a blockchain node, a billing node (which may be any one of blockchain nodes) may be included, and the billing node may determine at least a plurality of transactions and an order of execution of the plurality of transactions. In this embodiment, the accounting node may also determine the key to the parameter read and the key to the parameter written for each transaction. In some implementations, the accounting node may package the order of the plurality of transactions and the keys for the parameters read and the keys for the parameters written for each transaction into a packet corresponding to the block and send the packet to the other respective blockchain nodes in the blockchain system. In other implementations, the accounting node may also pack the plurality of transactions, the order of the plurality of transactions, and the key for the parameter read and the key for the parameter written for each transaction into a packet corresponding to the block, and send the packet to each other block chain node in the block chain system.

In the schematic diagram shown in fig. 1B, each blockchain node may comprise control means M, computing means C and storage means S. Wherein the control means M may be used to perform various operations other than transactions. The control means M may comprise an acquisition module, a pre-fetching module, a grouping module, a consensus module, a communication module, a processing module, etc. The control device M is further provided with a buffer area, and the buffer area may include a first buffer area, a second buffer area and a third buffer area. Computing device C may be used to perform transactions. The computing means C may comprise any number of computing modules, independent of each other. The storage device S stores a block database and a status database of the block chain, and the like. The control device M, the computing device C and the storage device S may be respectively a single entity computing apparatus or a cluster of computing apparatuses, or may be a virtual device in one of the computing apparatuses for implementing a specific function.

Specifically, for any blockchain node in the blockchain system, the obtaining module of the control device M of the blockchain node may first obtain all transactions of the plurality of blocks, an execution order of the all transactions, and a respective first set of each transaction in the all transactions, where the first set of any transaction includes a key of the parameter read by the transaction and a key of the parameter written by the transaction.

In one aspect, the pre-fetch module of the control device M may determine the key of the parameter read by each transaction and determine the value of the parameter read by each transaction based on the first set of each transaction. And recording the key value pairs of the parameters read by each transaction in the cache region. Specifically, the prefetch module may obtain keys of each parameter read by each transaction from the first set of each transaction, and search, in the first cache region and the second cache region of the cache region, values corresponding to the keys of each parameter (i.e., values of the parameter). For any parameter, if neither the first cache region nor the second cache region stores the value corresponding to the key of the parameter, the prefetch module may obtain the value of the parameter from the state database stored in the storage device S, and store the value in the first cache region. If the value corresponding to the key of the parameter is stored in the second cache region, the value of the parameter may be recorded in the first cache region by way of reference. And at least storing the key value pair of the parameter read by each transaction in the cache region.

On the other hand, the obtaining module of the control device M may transmit all transactions of the obtained plurality of blocks, the execution order of all transactions, and the keys of the parameters read by each transaction and the keys of the parameters written by each transaction in all transactions to the grouping module. The grouping module may determine transactions having an association relationship based on keys of the parameters read by the respective transactions and keys of the parameters written by the respective transactions, and group the total transactions based on a result of the determination to obtain a plurality of transaction groups. The transactions with the association relation are all divided into the same transaction group, and the rest transactions without the association relation can be randomly distributed. The transaction with the association relationship may be a transaction in which the read or write parameters overlap.

Then, the communication module of the control device M may transmit the acquired transaction groups and the key-value pairs of the parameters read by the respective transactions stored in the buffer to the computing device C, and the computing device C may process the transaction groups in parallel based on the key-value pairs of the parameters read by the respective transactions. One computing module in the computing device C may correspond to an independent thread or an independent computing device, and different computing modules may execute different transaction groups in parallel. For each transaction group, the individual transactions included in the transaction group are executed serially. The computing means C may return the results of the execution of the respective transactions to the communication module of the control means M. And storing the execution result of each transaction in a third cache region by the communication module.

For any one of the blocks, before the computing apparatus C performs all transactions in the block (for example, each time a transaction of a group of transactions is performed), the consensus module of the control apparatus M may perform consensus on the execution results of the performed partial transactions by interacting with the consensus modules of other nodes of the blockchain to determine whether the partial transactions are performed successfully. The processing module of the control device M may store the consensus results for each transaction in the third cache area with respect to each transaction, and the node in the block chain, which is docked with the client, may return the execution results of each transaction that is successfully agreed to the client after the consensus.

After the execution results of the executed partial transactions are identified, the processing module of the control device M may obtain the values of the write parameters included in the execution results of the respective transactions successfully identified in the partial transactions, and store the values of the write parameters included in the execution results of the respective transactions successfully identified in the second cache area with respect to the respective blocks to which the respective transactions successfully identified in the second cache area belong.

Then, after the consensus on the execution result of at least part of the transactions belonging to the block is completed, the storage module of the control device M may send a write request to the storage device S, where the write request carries the transaction body of the at least part of the transactions, the execution result and the consensus result of the transactions obtained from the third buffer, and the like, and the execution result is, for example, in the form of a transaction receipt. The storage device S takes the transaction body and the execution result of the at least partial transaction as at least partial block body of the block according to the write request, stores the data into a block database, and stores the consensus result of the at least partial transaction into the block database.

After all transactions in the block are executed and the block is identified successfully, the processing module of the control device M may read the current world state from the storage device S and generate a block header of the block based on the hash value of the previous block, the current world state and data of all transactions belonging to the block, in case it is determined that the block identification of the previous block of the block is successful.

Finally, the consensus module of the control device M may perform block consensus on the block based on the generated block header. If the block identity of the block is successful, the memory module of the control device M may send a block writing request to the memory device S, so that the memory device S stores the block header of the block into the block database. In addition, after the values of the written parameters included in the execution results of the respective transactions that are successfully recognized among all the transactions belonging to the block are stored in the second buffer, the world state in the state database may be updated according to the values of the respective parameters stored in the second buffer with respect to the block. The processing module of the control device M may then delete from the second buffer the values of the various parameters stored with respect to the block.

The embodiments provided in the present specification will be described in detail with reference to specific examples.

As shown in fig. 2, fig. 2 is a flow chart illustrating a method for performing a blockchain transaction according to an exemplary embodiment, which may be applied to any node of a blockchain. Those skilled in the art will appreciate that the nodes of the blockchain may be any computing, processing capable device, platform, server, or cluster of devices. The method comprises the following steps:

in step 202, a plurality of transactions belonging to the first block are obtained, the plurality of transactions being part of all transactions belonging to the first block.

In this embodiment, only the multiple transactions of the first block may be obtained, or all the transactions of the multiple blocks (including the first block) may be obtained, which is not limited in this aspect.

In step 204, the plurality of transactions are executed.

In one implementation, any node in the blockchain system may pre-fetch values of parameters read by the transactions in advance before executing the transactions. Specifically, for a read parameter of any transaction, a value of the parameter is first searched from the local cache region, and if the value of the parameter is not stored in the local cache region, the value of the parameter is obtained from the state database and is stored in the local cache region. After parameter prefetching for the transactions as described above, the node may execute the transactions based on the values of the parameters stored in the local cache.

In another implementation, any node in the blockchain system may obtain all transactions for a plurality of blocks (including the first block) and group all transactions for the plurality of blocks to obtain a plurality of transaction groups, and process the plurality of transaction groups in parallel. For each transaction group, the transactions included in the transaction group are executed serially.

In yet another implementation, all transactions for a plurality of blocks (including the first block) may be obtained for any node in the blockchain system. In one aspect, the values of the parameters read for the entire transaction may be prefetched and stored in a local cache prior to execution of the entire transaction. Alternatively, the entire transactions may be grouped to obtain multiple transaction groups. Then, based on the values of the respective parameters stored by the cache area, a plurality of transaction groups are processed in parallel. For each transaction group, the transactions included in the transaction group are executed serially.

In step 206, the execution results of the plurality of transactions are identified before all transactions belonging to the first block are executed.

In this embodiment, before all the transactions belonging to the first block are executed, the execution results of the executed transactions may be identified. Specifically, the execution results of the multiple transactions may be consensus verified by multiple nodes of the blockchain to determine whether each of the multiple transactions was successfully executed. The plurality of transactions may be transactions belonging to a transaction group, or may be a preset number of transactions arranged according to an execution sequence. It is to be understood that the present embodiment is not limited in this respect.

In this embodiment, the node of each block chain may perform hash calculation on the execution result corresponding to each of the multiple transactions, to obtain a hash value of each execution result. And comparing the hash values of the execution results to finish the consensus of the execution results. For any transaction, if the hash values of the execution results corresponding to the transaction obtained by the nodes of each blockchain or the nodes of the blockchains with the number larger than the preset number are the same, it is determined that the transaction is successfully executed. It will be appreciated that the execution results of the executed multiple transactions may be identified in any other reasonable manner, and the embodiment is not limited in this respect.

In this embodiment, after completing the consensus on each execution result, an accounting node in the blockchain system or a node interfacing with the user equipment may also return the execution result of the transaction for which the consensus is successful to the user equipment. The accounting node or the node interfacing with the user equipment may be any node in the blockchain system.

The method for performing blockchain transactions provided in the above embodiments of the present disclosure obtains a plurality of transactions belonging to a first block, where the plurality of transactions are partial transactions of all transactions belonging to the first block. The plurality of transactions are performed. The execution results of the plurality of transactions are consensus before all transactions belonging to the first block are executed. Since the execution result of the completed partial transaction is identified when the partial transaction is completed, the execution result of the transaction which is successfully identified can be returned to the user equipment without waiting for all the transactions belonging to the first block to be completed. Thus, the latency incurred by waiting for all transactions belonging to the first block to be performed is reduced.

Fig. 3 is a flow chart illustrating another method for performing blockchain transactions, according to an exemplary embodiment, which describes a process of updating a blockchain database, and which may be applied to a node of any blockchain, as shown in fig. 3, including the steps of:

in step 302, a plurality of transactions belonging to the first block are obtained, wherein the plurality of transactions are partial transactions of all transactions belonging to the first block.

In step 304, the plurality of transactions are executed.

In one implementation, any node in the blockchain system may obtain multiple transactions belonging to the first block and obtain parameters read by each of the multiple transactions. The values of the parameters read for the plurality of transactions may be pre-fetched prior to execution of the plurality of transactions. Specifically, for any parameter read in a transaction, a value of the parameter is first searched from a local cache region, and if the value of the parameter is not stored in the local cache region, the value of the parameter is obtained from a state database and stored in the local cache region. After parameter prefetching for the transactions as described above, the node may execute the transactions based on the values of the parameters stored in the local cache.

In another implementation, any node in the blockchain system may group all transactions of the plurality of blocks based on the obtained parameters read and written by each transaction of the plurality of blocks to obtain a plurality of transaction groups, and process the plurality of transaction groups in parallel. For each transaction group, the transactions included in the transaction group are executed serially.

In yet another implementation, all transactions for a plurality of blocks (including the first block) may be obtained for any node in the blockchain system. In one aspect, the values of the parameters read for the entire transaction may be pre-fetched in advance and stored in a local cache before the entire transaction is executed. Alternatively, the entire transactions may be grouped to obtain multiple transaction groups. Then, based on the values of the respective parameters stored by the cache area, a plurality of transaction groups are processed in parallel. For each transaction group, the transactions included in the transaction group are executed serially.

In step 306, the execution results of the plurality of transactions are identified before all transactions belonging to the first block are executed.

In this embodiment, before all the transactions belonging to the first block are executed, the execution results of the executed transactions may be identified. The node of each block chain may perform hash calculation on the execution result corresponding to each of the multiple transactions, to obtain a hash value of each execution result. And comparing the hash values of the execution results to finish the consensus of the execution results. For any transaction, if the hash values of the execution results corresponding to the transaction obtained by the nodes of each blockchain or the nodes of the blockchains with the number larger than the preset number are the same, it is determined that the transaction is successfully executed. It will be appreciated that the execution results of the executed multiple transactions may be identified in any other reasonable manner, and the embodiment is not limited in this respect.

In step 308, after the results of the transactions are identified, the data of the transactions are stored as part of the first block in the block database.

In this embodiment, the data of each transaction that has completed the consensus may be stored in the tile database as at least a portion of the tile of the first tile. The data of any transaction may at least include the transaction body of the transaction, the execution result and other data. The consensus result of the at least partial transaction may also be stored in the tile database.

In step 310, after all transactions of the first block are performed and the consensus is completed, the block header of the first block is stored in the block database.

In this embodiment, after the execution results of all transactions belonging to the first block are completely recognized and it is determined that the block recognition of the previous block of the first block is successful, in the case where it is determined that the block recognition of the previous block of the first block is successful, a block header of the first block is generated based on the hash value of the previous block of the first block and data of all transactions belonging to the first block, and the block recognition of the first block is performed. If the block consensus of the first block is successful, the block head of the first block is stored into the block database.

It should be noted that, for the same steps as in the embodiment of fig. 2, details are not repeated in the embodiment of fig. 3, and related contents may refer to the embodiment of fig. 2.

The method for performing blockchain transactions provided in the foregoing embodiments of the present specification obtains a plurality of transactions belonging to a first block, where the plurality of transactions are partial transactions of all transactions belonging to the first block, performs the plurality of transactions, and performs consensus on the execution results of the plurality of transactions before performing all transactions belonging to the first block. After the execution results of the multiple transactions are identified, the data of the multiple transactions are stored in the block database as part of the block body of the first block, and after the execution and identification of all the transactions of the first block are completed, the block head of the first block is stored in the block database. In this embodiment, a part of the data which is obtained by performing the consensus and belongs to the transaction of the first block is stored in the block database as the block of the first block, and then the block header of the first block is stored in the block database after all the transactions of the first block are performed and the consensus is completed. Therefore, the purpose of reducing time delay is achieved, and the performance of the block chain system is improved.

As shown in fig. 4, fig. 4 is a flow chart of another blockchain transaction execution method according to an exemplary embodiment, which describes in detail a process of executing multiple transactions, and the method can be applied to a node of any blockchain, and includes the following steps:

in step 402, a plurality of transactions belonging to the first block are obtained, the plurality of transactions being part of all transactions belonging to the first block.

In step 404, a respective first set of the plurality of transactions is obtained.

In this embodiment, the first set of any transaction may include an identification of parameters accessed by that transaction. For example, the identifier of the parameter may be a key of the parameter, a mapping number of the parameter, or a unique identifier of the parameter in any other reasonable form. It is to be understood that the present embodiment is not limited to the specific form of the parameter identifier. Wherein the accessed parameters may comprise at least the read parameters.

In this embodiment, only the multiple transactions of the first block and the respective first sets of the multiple transactions may be obtained, or all the transactions of the multiple blocks (the multiple blocks include the first block) and the respective first sets of all the transactions may be obtained, which is not limited in this respect.

In an implementation manner of this embodiment, the accounting node in the blockchain system may determine a plurality of transactions, and further obtain an identifier of a parameter accessed by each transaction, to obtain a respective first set of the plurality of transactions. Then, based on the plurality of transactions and the respective first set, a packet corresponding to the first block is obtained, and the packet corresponding to the first block is sent to other respective block chain nodes in the block chain system. Thus, for a non-accounting node, the plurality of transactions belonging to the first block and the respective first set of the plurality of transactions may be obtained directly from the data packet corresponding to the first block. For the accounting node, the identification of the parameters accessed by each transaction may be obtained by pre-executing each transaction (the world state is not changed when the transaction is pre-executed). Alternatively, the identification of parameters of each transaction access pre-recorded in the smart contract may be read, and so on. It is to be understood that the present embodiment is not limited in the particular manner in which the accounting node obtains an identification of the parameters of each transaction access.

In another implementation manner of this embodiment, after determining a plurality of transactions, the accounting node in the blockchain system directly obtains a data packet corresponding to the first block based on the plurality of transactions, and sends the data packet corresponding to the first block to each other blockchain node in the blockchain system. For a non-accounting node, the plurality of transactions belonging to the first block may be obtained directly from the data packet corresponding to the first block. For any node in the blockchain system, the identification of the parameter accessed by each transaction can be obtained by pre-executing each transaction. Alternatively, the identification of parameters of each transaction access pre-recorded in the smart contract may be read, and so on.

In yet another implementation manner of this embodiment, after obtaining the multiple transactions, any one node in the blockchain system may obtain, from each transaction, an identifier of a parameter that is accessed by the node, to obtain a first set of each of the multiple transactions. Specifically, the predetermined field of any transaction contains an identification of the parameters accessed by that transaction. For the accounting node in the blockchain system, after the plurality of transactions are obtained, on one hand, the identifier of the parameter accessed by each transaction can be obtained from the preset field of each transaction, so as to obtain the first set of each transaction. In another aspect, a packet corresponding to the first block may be obtained based on the plurality of transactions and sent to other respective blockchain nodes in the blockchain system. For a non-accounting node in the blockchain system, after obtaining a plurality of transactions, identifiers of parameters accessed by each transaction can also be obtained from preset fields of each transaction, so as to obtain a first set of each transaction. In the implementation manner, each transaction includes the identifier of the parameter accessed by each transaction, so that each node in the blockchain system can directly acquire the first set from each transaction, thereby reducing the preparation time before executing the transaction.

In step 406, for each identifier of the parameter read from each of the first sets of the transactions, if the value of the parameter corresponding to the identifier is not stored in the buffer, the value of the parameter is obtained from the status database and stored in the buffer.

In this embodiment, a node of the blockchain first obtains a plurality of transactions belonging to the first block and a first set of the transactions. Prior to executing the plurality of transactions, the nodes of the blockchain may prefetch values of the parameters read by the plurality of transactions based on the respective first set of the plurality of transactions. Specifically, for an identifier of a parameter read from any of the first set of any transaction, first, a value of the parameter corresponding to the identifier is searched for from the local cache region, and if the value of the parameter corresponding to the identifier is not stored in the local cache region, the value of the parameter is obtained from the state database, and the identifier and the value of the parameter are stored in the local cache region in an associated manner (for example, in the form of a key-value pair). So that before executing the plurality of transactions, the identification and the value of the parameter read by all transactions belonging to the first block are stored in the cache region.

In this embodiment, the cache region may include at least a first cache region, and the first cache region may be configured to store the identifier and the value of the parameter read from the respective first set of each transaction. Optionally, the cache region may further include a second cache region, and the second cache region may be configured to store the identification and the value of the parameter written in the respective first set of each transaction.

In step 408, the plurality of transactions are executed based on the values of the respective parameters stored by the cache.

In this embodiment, the nodes of the blockchain may execute the transactions based on the values of the parameters stored in the cache.

In step 410, the execution results of the plurality of transactions are identified before all transactions belonging to the first block are executed.

It should be noted that, for the same steps as in the embodiments of fig. 2 to fig. 3, details are not repeated in the embodiment of fig. 4, and related contents can refer to the embodiments of fig. 2 to fig. 3.

In the method for executing blockchain transactions provided in the foregoing embodiment of the present specification, a plurality of transactions belonging to a first block are obtained, where the plurality of transactions are partial transactions in all transactions belonging to the first block, a first set of each of the plurality of transactions is obtained, for an identifier of a parameter read in each of the first set of each of the plurality of transactions, if a value of the parameter corresponding to the identifier is not stored in a cache region, a value of the parameter is obtained from a status database and stored in the cache region, and the plurality of transactions are executed based on the values of the parameters stored in the cache region. The execution results of the plurality of transactions are consensus before all transactions belonging to the first block are executed. Since the embodiment prestores the identifier and the value of the parameter read by each transaction of the first block in the cache before the execution of the plurality of transactions belonging to the first block, the node of the block chain can execute each transaction based on the value of each parameter stored in the cache. Therefore, during the execution of each transaction, the value of the parameter read by each transaction does not need to be acquired one by one from the state database of the storage area through IO operation, so that the IO operation of the nodes of the block chain during the execution of the transaction is reduced, and the time delay caused by the execution of the transaction is reduced.

Fig. 5 is a flow chart illustrating another blockchain transaction execution method, according to an exemplary embodiment, which describes a process of maintaining a cache, as shown in fig. 5, which may be applied to a node of any blockchain, including the steps of:

in step 502, a plurality of transactions belonging to the first block are obtained, the plurality of transactions being part of all transactions belonging to the first block.

In step 504, a respective first set of the plurality of transactions is obtained.

In this embodiment, the first set of any transaction may include an identification of parameters accessed by that transaction. For example, the identifier of the parameter may be a key of the parameter, a mapping number of the parameter, or a unique identifier of the parameter in any other reasonable form. It is to be understood that the present embodiment is not limited to the specific form of the parameter identifier. Wherein the accessed parameters comprise at least the read parameters.

In step 506, for each identifier of the parameter read from the respective first set of the multiple transactions, if the value of the parameter corresponding to the identifier is not stored in the buffer, the value of the parameter is obtained from the status database and stored in the buffer.

In step 508, the plurality of transactions are executed based on the values of the respective parameters stored by the cache.

In step 510, the execution results of the plurality of transactions are identified before all transactions belonging to the first block are executed.

In step 512, after the execution results of the transactions are identified, the values of the write parameters included in the execution results of the transactions that are successfully identified in the transactions are stored in a second cache area included in the cache area, with respect to the block to which each transaction that is successfully identified belongs.

In this embodiment, the cache region may include a first cache region and a second cache region, where the first cache region may be configured to store the identifier and the value of the parameter read in the respective first set of each transaction, and the second cache region may be configured to store the identifier and the value of the parameter written in the respective first set of each transaction.

In this embodiment, after the results of the execution of the plurality of transactions are identified, it may be determined whether the respective execution of the plurality of transactions is successful. For a transaction that is successfully identified among the plurality of transactions, the value of the parameter written in the transaction that is successfully identified may be obtained based on the execution result corresponding to the transaction that is successfully identified. And storing the value of the parameter written in the transaction which is successfully identified in the second cache region which is included in the cache region relative to the first block to which the transaction which is successfully identified belongs, thereby updating and maintaining the data stored in the cache region.

It should be noted that, for the same steps as in the embodiments of fig. 2 to fig. 4, description is not repeated in the embodiment of fig. 5, and related contents may refer to the embodiments of fig. 2 to fig. 4.

In the method for executing blockchain transactions provided in the foregoing embodiments of the present specification, a plurality of transactions belonging to a first block are obtained, where the plurality of transactions are partial transactions in all transactions belonging to the first block, and a first set of each of the plurality of transactions is obtained. And for the identifier of each read parameter in the first set of each transaction, if the value of the parameter corresponding to the identifier is not stored in the cache region, acquiring the value of the parameter from the state database, storing the value of the parameter into the cache region, and executing the transactions based on the values of the parameters stored in the cache region. The execution results of the multiple transactions are identified together before all the transactions belonging to the first block are executed, and after the execution results of the multiple transactions are identified together, the values of the write-in parameters included in the execution results of the transactions successfully identified in the multiple transactions are stored in a second cache area included in the cache area relative to the block to which each transaction successfully identified belongs. In this embodiment, after the partial transactions are successfully identified, the data in the maintenance buffer area is updated in time based on the values of the parameters written in the respective transactions that are successfully identified. Therefore, the problem of update and maintenance lag of transaction data is solved.

Fig. 6 is a flow chart illustrating another blockchain transaction execution method according to an exemplary embodiment describing a process of updating a status database, as shown in fig. 6, which may be applied to a node of any blockchain, including the steps of:

in step 602, a plurality of transactions belonging to the first block are obtained, wherein the plurality of transactions are partial transactions of all transactions belonging to the first block.

In step 604, a respective first set of the plurality of transactions is obtained.

In step 606, for each read parameter identifier in the first set of the transactions, if the value of the parameter corresponding to the identifier is not stored in the buffer, the value of the parameter is obtained from the status database and stored in the buffer.

In step 608, the plurality of transactions are executed based on the values of the respective parameters stored in the cache.

In step 610, the execution results of the plurality of transactions are identified before all transactions belonging to the first block are executed.

In step 612, after the execution results of the multiple transactions are identified, the values of the write parameters included in the execution results of the transactions that are successfully identified in the multiple transactions are stored in a second cache area included in the cache area, with respect to the block to which each transaction that is successfully identified belongs.

In step 614, after the values of the written parameters included in the execution results of the respective transactions successfully identified among all the transactions belonging to the first block are stored in the second buffer, the world state in the state database is updated according to the values of the respective parameters stored in the second buffer with respect to the first block.

It should be noted that, for the same steps as in the embodiments of fig. 2 to 5, details are not repeated in the embodiment of fig. 6, and related contents may refer to the embodiments of fig. 2 to 5.

In the method for executing blockchain transactions provided in the foregoing embodiments of the present specification, a plurality of transactions belonging to a first block are obtained, where the plurality of transactions are partial transactions in all transactions belonging to the first block, and a first set of each of the plurality of transactions is obtained. And for the identifier of each read parameter in the first set of each transaction, if the value of the parameter corresponding to the identifier is not stored in the cache region, acquiring the value of the parameter from the state database, storing the value of the parameter into the cache region, and executing the transactions based on the values of the parameters stored in the cache region. The execution results of the multiple transactions are identified together before all the transactions belonging to the first block are executed, and after the execution results of the multiple transactions are identified together, the values of the write-in parameters included in the execution results of the transactions successfully identified in the multiple transactions are stored in a second cache area included in the cache area relative to the block to which each transaction successfully identified belongs. After the values of the written parameters included in the execution results of the respective transactions successfully recognized among all the transactions belonging to the first block are stored in the second buffer area, the world state in the state database is updated based on the values of the respective parameters stored in the second buffer area with respect to the first block. In the embodiment, after the written parameter values included in the execution results of the successfully recognized transactions in all the transactions belonging to the first block are stored in the second buffer area, the world state in the state database is updated in time, so that the time delay caused by updating the database is reduced.

As shown in fig. 7, fig. 7 is a flow chart of another blockchain transaction execution method according to an exemplary embodiment, which describes a process of executing a plurality of transactions, and the method can be applied to a node of any blockchain, and includes the following steps:

in step 702, all transactions for a plurality of blocks are obtained.

In step 704, a respective first set of all transactions is obtained.

In this embodiment, the plurality of blocks may include a first block. After a plurality of consensus, all transactions of the plurality of blocks and a respective first set of the all transactions may be obtained. Wherein the first set of any transaction may include an identification of parameters accessed by that transaction. For example, the identifier of the parameter may be a key of the parameter, a mapping number of the parameter, or a unique identifier of the parameter in any other reasonable form. It is to be understood that the present embodiment is not limited to the specific form of the parameter identifier. Wherein the accessed parameters include read parameters and write parameters.

In step 706, the total transactions are grouped based on their respective first set to obtain a plurality of transaction groups.

In this embodiment, all transactions for the multiple blocks may be grouped together. Specifically, first, a respective first set of all transactions for the plurality of tiles may be obtained. Then, a plurality of transactions for which an access conflict exists may be determined from the respective first set of all transactions. And grouping all transactions based on the determined result to obtain a plurality of transaction groups, so that the transactions with access conflict are grouped into the same transaction group, and the rest transactions without access conflict can be randomly distributed.

The transaction in which the access conflict exists may be a transaction in which the read or write parameters overlap. In one implementation, it may be determined that there is an access conflict for at least two transactions that read the same parameters or at least two transactions that write the same parameters. In another implementation, it may be determined that there is an access conflict between a transaction of the write parameter a and a transaction of the respective read parameter a. For example, if the read parameters of transaction A include a and the write parameters of transaction B include a, then it may be determined that there is an access conflict between transaction A and transaction B.

In this embodiment, the number of transactions included in each transaction group may be the same or different, and the transactions included in each transaction group may be sorted in the order of transaction reception time. It will be appreciated that all transactions may be grouped in other ways, and the present embodiment is not limited to the specific manner of grouping.

For example, all transactions for the acquired plurality of blocks include transaction 1, transaction 2, transaction 3, transaction 4, transaction 5, transaction 6, transaction 7, transaction 8, transaction 9, and transaction 10. Based on the respective first set of transactions, it may be determined that there is an access conflict for transactions 1 and 3, and an access conflict for transactions 3 and 7; there is an access conflict for transaction 4, transaction 6, and transaction 9; there are no access conflicts between the remaining transactions 2, 5, 8, and 10 and others. Transaction 1, transaction 3, and transaction 7 may be divided into a transaction group, transaction 4, transaction 6, and transaction 9 may be divided into a transaction group, and transaction 2, transaction 5, transaction 8, and transaction 10 may be divided into a transaction group.

In step 708, the following processes are performed in parallel for the plurality of transaction groups: for each transaction group, the transactions included in the transaction group are executed serially.

In this embodiment, multiple transaction groups may be processed in parallel by asynchronous threads or different computing devices. For each transaction group, the transactions included in the transaction group may be performed serially.

In step 710, the execution results of the plurality of transactions are identified before all transactions belonging to the first block are executed.

In this embodiment, the results of the execution of a predetermined number of transactions consecutively executed in any transaction group, the predetermined number of transactions including the plurality of transactions, may be agreed.

It should be noted that, for the same steps as in the embodiments of fig. 2 to 6, details are not repeated in the embodiment of fig. 7, and related contents can refer to the embodiments of fig. 2 to 6.

In the blockchain transaction execution method provided by the above embodiments of the present specification, all transactions of a plurality of blocks and a first set of the all transactions are obtained, the first set of any transaction includes an identifier of a parameter read by the transaction and a parameter written by the transaction, the all transactions are grouped based on the first set of the all transactions to obtain a plurality of transaction groups, and a plurality of transaction groups are processed in parallel, where, for each transaction group, the transactions included in the transaction group are executed in series. The execution results of the plurality of transactions are consensus before all transactions belonging to the first block are executed. In the embodiment, all transactions in the plurality of blocks are grouped to obtain a plurality of transaction groups, and the plurality of transaction groups are executed in parallel, so that the transaction in the next block is executed after the transactions in one block are executed, the efficiency of executing the transactions is improved, and the time delay caused by waiting for the completion of the transactions in the previous block is reduced.

It should be noted that although in the above-described embodiments, the operations of the methods of the embodiments of the present specification are described in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Rather, the steps depicted in the flowcharts may change the order of execution. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.

Fig. 8 is a flow chart illustrating a method of blockchain transaction execution in accordance with an exemplary embodiment. The method is performed by the control device, the computing device and the storage device of the nodes of the blockchain together, and it is understood that only one node of the blockchain is shown in the figure as a schematic representation and only one computing device is shown in the nodes of the blockchain as a schematic representation.

In step 802, the control device obtains all transactions for a plurality of tiles and a respective first set of the all transactions.

In this embodiment, the control device of each blockchain node in the blockchain system may first obtain all transactions of the plurality of blocks and a respective first set of the all transactions. Wherein the first set of any transaction may include an identification of parameters accessed by that transaction. For example, the identifier of the parameter may be a key of the parameter, a mapping number of the parameter, or a unique identifier of the parameter in any other reasonable form. It is to be understood that the present embodiment is not limited to the specific form of the parameter identifier. The accessed parameters may include read parameters and write parameters.

In one implementation, after the control device obtains all transactions of the plurality of blocks, a respective first set of each transaction may be obtained by pre-executing each transaction. Alternatively, the respective first set of each transaction pre-recorded in the smart contract may also be read, and so on.

In another implementation, after the control device receives a plurality of data packets of the plurality of blocks and obtains all transactions of the plurality of blocks, the control device may directly obtain a respective first set of each transaction from the received data packets.

In yet another implementation, the preset fields of each transaction include an identification of the parameters read and an identification of the parameters written for that transaction. After the control device obtains all transactions of the plurality of blocks, the control device may directly obtain the respective first set of each transaction from the preset field in each transaction.

In step 804, the control device pre-fetches parameter values from the storage device for all transaction read parameters of the plurality of blocks.

Specifically, in one embodiment, after the world state of the previous block of the plurality of blocks has been stored in the storage device, for each identifier of the parameter read in the respective first set of all transactions of the plurality of blocks, it is determined whether a first buffer included in the buffer stores a value of the parameter corresponding to the identifier, if not, the control device sends a read request for the parameter to the storage device, the storage device reads the value of the parameter from the state database after receiving the read request and sends the value of the parameter to the control device, and the control device stores the key-value pair of the parameter into the first buffer after receiving the value of the parameter.

In another embodiment, after the execution results of all transactions included in the previous block of the plurality of blocks have been agreed to end and the execution results of the transactions that are agreed to succeed have been updated into the second buffer included in the buffer, for each read parameter identification in the respective first set of all transactions of the plurality of blocks, it is determined whether a parameter value corresponding to the identification is stored in the first buffer and the second buffer, and if not, the control device receives the parameter value from the storage device and stores the parameter value in the first buffer, similar to the previous embodiment. If the second cache region stores the value of the parameter corresponding to the identifier, the control device stores the value into the first cache region, or references the value of the parameter in the first cache region.

In a further embodiment, after the execution results of all transactions included in the previous block of the plurality of blocks have been agreed to end and the execution results of the transactions that are agreed to succeed have been updated into the second buffer, the control device determines the identities of all read parameters included in all transactions, deletes the identity storing the value of the parameter corresponding to the identity in the second buffer from the identities of all read parameters, and thereby obtains all target identities. The control device can obtain the values of the parameters corresponding to all the target identifications from the storage device through at least one read request, and store the values of the parameters corresponding to the target identifications into the first cache region.

In this embodiment, the control device may first determine whether the values of the parameters read by all transactions of the plurality of blocks are stored in the buffer based on the identification of each read parameter in the first set of all transactions. Then, the control device may send a request to the storage device to request to acquire a value of a parameter not stored in the buffer area among values of parameters read by the respective transactions, based on a result of the determination.

In this embodiment, the storage device, in response to a request sent by the control device, obtains the values of the parameters that are not stored in the buffer area from the status database, and returns the values of the parameters to the control device together. Therefore, the control device only needs to perform IO operation once between the control device and the storage device in the process of processing the transaction of one or more blocks, and the time delay caused by transaction execution is reduced.

In this embodiment, after receiving the value of the parameter not stored in the buffer sent by the storage device, the control device stores the value of the parameter not stored in the buffer into a first buffer in the buffers.

In step 806, the control device groups all transactions of the plurality of tiles based on their respective first sets to obtain a plurality of transaction groups.

In this embodiment, the control device may group all transactions of the plurality of blocks based on the respective first sets of all transactions to obtain a plurality of transaction groups. Specifically, first, the control device may acquire a respective first set of all transactions of the plurality of blocks.

Then, a plurality of transactions with access conflicts can be determined according to the respective first sets of all transactions, and all transactions are grouped to obtain a plurality of transaction groups based on the determined result, so that the transactions with access conflicts are classified into the same transaction group, and the rest transactions without access conflicts can be randomly distributed. The number of transactions included in each transaction group may be the same or different, and the transactions included in each transaction group may be sorted in order of transaction receipt time.

It will be appreciated that all transactions may be grouped in other ways, and the present embodiment is not limited to the specific manner of grouping.

In step 808, the control device sends the values of the parameters and the transaction sets stored in the first cache area to the computing device.

In step 810, the computing device processes multiple transaction groups in parallel based on the values of the respective parameters stored in the first cache, and for each transaction group, serially executes the transactions included in that transaction group.

In this embodiment, the control device may send the values of the parameters stored in the first buffer to the computing device together with the transaction sets. The computing device may process multiple transaction groups in parallel based on the received values for the various parameters described above. For each transaction group, the transactions included in the transaction group are executed serially in order of transaction receipt time.

In the embodiment, all transactions in a plurality of blocks are grouped to obtain a plurality of transaction groups, and the transaction groups are executed in parallel, and the transaction of the next block is executed after the transaction in one block is executed, so that the efficiency of executing the transaction is improved, and the time delay caused by waiting for the completion of the transaction in the previous block is reduced.

In step 812, the computing device sends the control device the results of the execution of the completed partial transaction.

In step 814, the control device identifies the results of the executed partial transactions that have been completed.

In this embodiment, for any one of the plurality of blocks, before the computing device completes all transactions in the block, the execution result of the executed partial transactions may be sent to the control device. And carrying out consensus verification on the executed partial transactions among the nodes of the block chains by the control device so as to determine whether each transaction in the partial transactions is executed successfully.

In this embodiment, the control device may store the consensus result of each transaction into a third cache region included in the cache region, and the node in the block chain, which is docked with the client, may return the execution result of each transaction that is successfully agreed to the client after the consensus.

When the partial transaction of one block is completed, the execution result of the completed partial transaction is identified, and a receipt after the identification obtained based on the result of the identification can be returned to the client without waiting for the completion of the execution of all the transactions in the block. Thus, the latency incurred by waiting for all transactions in the block to be performed is reduced.

In step 816, the control device stores the value of the write parameter included in the execution result of each transaction that is successfully acknowledged in the second one of the cache areas with respect to the block to which the transaction that is successfully acknowledged belongs.

In this embodiment, after the execution results of the executed partial transactions are identified, the control device may update the data in the second buffer area by using the written parameter value included in the execution results of the transactions successfully identified. And enabling the values of all the parameters stored in the second cache region to be the latest obtained numerical values, namely the latest state of the parameters.

In this embodiment, after the partial transaction consensus is successful, the data stored in the second buffer area is updated in time based on the value of the parameter written in the transaction with successful consensus. Therefore, the problem of transaction data update lag is solved.

In step 818, the control device requests that the data of each transaction that has completed the consensus be stored in the tile database as at least a portion of the tile to which the control device belongs.

In step 820, the storage device stores the data of each transaction that completed the consensus as at least a partial block of the block to which the storage device belongs in the block database.

In this embodiment, for any one of the plurality of blocks, after the consensus on the execution result of the at least partial transaction belonging to the block is completed, the control device may obtain data of the at least partial transaction, and send a request to the storage device to request the storage device to store the data of the at least partial transaction as the at least partial block of the block in the block database. The storage device responds to the request, and stores the at least part of transaction data as the block of the block into the block database. The data of any transaction may at least include the transaction body of the transaction, the execution result and other data. The consensus result of the at least partial transaction may also be stored in the tile database.

In step 822, after all transactions of any one of the plurality of blocks are performed and the block is identified, the control device generates a block header of the block and performs block identification on the block.

In this embodiment, for any one of the plurality of blocks, after all transactions of the block are performed and the consensus is completed, in a case where the control device determines that the block consensus on the previous block of the block is successful, the control device may generate a block header of the block based on the hash value of the previous block and data of all transactions belonging to the block. And performing block consensus on the block based on the block header.

In step 824, if the block identity of the block is successful, the control device requests to store the block header of the block into the block database.

In step 826, the storage device stores the block header of the block in the block database.

In step 828, the control device requests an update of the world state in the state database.

In step 830, the storage device updates the world states in the state database.

In this embodiment, after the world state in the state database is updated according to the values of the parameters stored in the second buffer area relative to the block, part of the data in the second buffer area used for updating the state database may be deleted to release part of the buffer. For example, after all transactions in the block are completed, the transaction of the next block is received, and if any transaction read parameter in the next block is a transaction write parameter in the block, the value of the transaction write parameter in the block stored in the cache may be retained. And deleting the values of the parameters written by the other transactions in the block stored in the cache region, thereby releasing part of the cache.

In this embodiment, the partial transaction may be stored in the block database as a block, and for any one of the blocks, a block before the block is generated, and all transactions of the block are performed to complete regeneration of the block head of the block and store the block head of the block in the block database. In addition, in the embodiment, the buffer area is used for storing and updating the values of the parameters written in each transaction, so that the state database of the block chain can be updated directly by using the data stored in the buffer area, and the data of each transaction which is identified in common can be stored in the block database. Therefore, the problem that the updating of the transaction data in the database is delayed is solved.

The following description is intended to illustrate aspects of one or more embodiments of the disclosure, as a whole, with reference to a single example application.

The application scenario may be: node a of the blockchain processes the transactions in block 101, block 102 and block 103. The node A comprises a control device, a computing device and a storage device.

Specifically, first, after a plurality of nodes of the block chain are identified, data packets corresponding to each of the block 101, the block 102, and the block 103 are sent to each node of the block chain, a first set of transactions belonging to the block may be included in the data packet corresponding to any one of the blocks, and the first set of transactions includes keys of the read parameters and the write parameters of the transaction. Wherein, the block 101 corresponds to transactions 1-6, the block 102 corresponds to transactions 7-12, and the block 103 corresponds to transactions 13-18. The control device of the node A receives the data packets corresponding to the block 101, the block 102 and the block 103, acquires the transactions 1 to 6 and the respective first sets from the data packets corresponding to the block 101, acquires the transactions 7 to 12 and the respective first sets from the data packets corresponding to the block 102, and acquires the transactions 13 to 18 and the respective first sets from the data packets corresponding to the block 103.

Then, on the one hand, the control device of the node A searches the values of the read parameters corresponding to the transactions 1 to 18 from the cache area based on the first sets of the transactions 1 to 18. Based on the search result, it is determined that the values of the read parameters corresponding to each of transaction 1, transaction 3, and transaction 9 are stored in the second buffer (e.g., the stored values of the write parameters corresponding to block 100), and the control device obtains the values of these parameters from the second buffer and stores them in the first buffer. The values of the read parameters corresponding to transactions 2, 4-8, and 10-18 are not stored in the second cache area. The control device of the node A can acquire the values of the read parameters corresponding to the transactions 2, 4 to 8 and 10 to 18 from the state database of the storage device of the node A through at least one read operation, and store the acquired data in the first cache region. The first cache region stores the key and the value of the read parameter corresponding to each of the transactions 1 to 18.

On the other hand, the control device of the node a may form the parameter set by using the first set of each of the transactions 1 to 18. According to the parameter set, it is determined that access conflicts exist in the transactions 1 to 3, 6 and 7, access conflicts exist in the transactions 4, 5 and 11 to 13, and access conflicts do not exist in the rest of the transactions 8 to 10 and 14 to 18. The transactions 1-18 can be grouped together, so that a plurality of transactions with access conflict are all grouped into the same transaction group, and the rest transactions without access conflict can be randomly distributed. Transaction group a, transaction group b, and transaction group c may be obtained. The transaction group a comprises transactions 1-3, transactions 6, transactions 7 and transactions 16, the transaction group b comprises transactions 4, transactions 5, transactions 11-13 and transactions 17, and the transaction group c comprises transactions 8-10, transactions 14-15 and transactions 18.

Then, the control device of the node a may send the key and the value of the read parameter corresponding to each of the transactions 1 to 18 stored in the first cache area, and the transaction group a, the transaction group b, and the transaction group c to the computing device of the node a. The computing device can execute transaction group a, transaction group b and transaction group c in parallel based on the key and value of the read parameter corresponding to each of transactions 1-18. And, for any one transaction group, the transactions included in the transaction group are serially executed in turn. The computing device may return the results of performing the completed transaction to the computing device at any time.

Then, before completing the transactions 1-18, the executed partial transactions can be identified by a plurality of nodes of the blockchain based on the result of executing the completed transactions to determine whether the partial transactions are executed successfully. For example, when all transactions in the transaction group a are executed and completed, all transactions in the transaction group a may be agreed (or, when the transactions 1 to 3 in the transaction group a are executed and completed, the transactions 1 to 3 may be agreed), and whether all transactions in the transaction group a are executed successfully or not may be determined. If the node A is an accounting node in the block chain or a node connected with the client side in an abutting mode, the execution result of each transaction which is successfully identified can be returned to the client side, and the execution failure information of the transaction which is failed in the identification can be returned to the client side. Then, after the completed partial transactions have been executed for consensus, for example, after all transactions in the transaction group a are agreed, the control device of the node a obtains the values of the written parameters included in the execution results of the respective transactions in the transaction group a for which consensus is successful, and stores the values of the written parameters included in the execution results of the respective transactions in the transaction group a for which consensus is successful in the second cache area, so as to update and maintain the data stored in the cache. Specifically, the control means of the node a may store, in the second buffer, the value of the parameter written included in the execution result of the transaction which is acknowledged as successful, corresponding to the block to which the transaction belongs. For a plurality of transactions which are successfully identified and executed in series in the same block, the values of the write-in parameters of the transactions are sequentially stored in the second cache region corresponding to the block according to the execution sequence of the transactions, so that the correctness of the parameter state is ensured. For example, as shown in fig. 9, in the case where the transactions 1 to 3 in the transaction group a are all agreed to be successful, the values value1 and value2 of the written parameters key1 and key2 included in the execution result of the transaction 1 are first stored in the second buffer corresponding to the block 101 to which the transaction 1 belongs, i.e., in the write set of the block 101 in fig. 9, and then the parameter value written in the transaction 2 is stored in the write set of the block 101 in the second buffer, and assuming that the value3 of the written parameter key1 is included in the transaction 2, the value1 of the previously written key1 is overwritten with the value3 in the write set of the block 101 (not shown in fig. 9), and then the value of the parameter written in the transaction 3 is stored in the write set of the block 101. After the values of the write parameters of all the transactions in the block 101 that have been successfully agreed to are thus stored in the write set of the block 101, since the write set is obtained by storing the transactions after the transactions are agreed to in a small lot, the values of the parameters included in the write set can be directly updated to the world state corresponding to the block 101 in the state database. Then, after all transactions (transaction 1-transaction 6) in the block 101 are completed and identified, the control device of the node a may store the data of all transactions (transaction 1-transaction 6) in the block 101 as the block of the block 101 into the block database of the storage device of the node a. Fig. 10 shows a schematic structure of the block 101. As shown in fig. 10, the block 101 includes a block header and a block, and the block includes data of each of the transactions 1 to 6, where the data of each transaction includes, for example, a transaction body of the transaction and data of an execution result. The transaction entities of transaction 1 to transaction 6 may be stored in a data structure of a transaction tree, and the receipts of transaction 1 to transaction 6 may be stored in a data structure of a receipt tree.

Then, in a case where it is determined that the block consensus on the block 100 is successful, the control device generates a block header of the block 101 as shown in fig. 10 based on the hash value of the block 100 and data of all transactions belonging to the block 101. As shown in fig. 10, the block header includes data such as a header hash, a parent hash, a transaction root, a receipt root, and a status root. The head hash is a hash value of data except the head hash in the block head of the block 101, the parent hash is a head hash of the block 100, the transaction root is a root hash value of a transaction tree in the block 101, the receipt root is a root hash value of a receipt tree in the block 101, and the status root is a root hash value of a status tree corresponding to the block 101. The control device may determine, based on the write set of the block 101 in fig. 9, a change to the state tree by the block 101, and thereby obtain a root hash value of the state tree in the change.

Thereafter, the control apparatus may perform block consensus on the block 101, i.e., verify whether the header hashes of the block 101 are consistent (or approximately consistent) together with the plurality of nodes, and determine that the block consensus is successful if consistent. If the block identity of the block 101 is successful, the block header of the block 101 is stored in the block database of the storage device.

After the block consensus on the block 101 is successful, the control device of the node a may update the world state in the state database of the storage device by using the obtained change of the state tree by the block 101. After the block consensus of the block 101 is successful, the control device may delete the write set of the block 101 in fig. 9, thereby releasing the cache.

And so on, after completing all transactions of the blocks 102 and 103 in sequence, updating the state database and the block database in the storage device in sequence. After the world state in the state database is updated with respect to block 103, the keys and values of the parameters corresponding to block 103 in the second cache may be temporarily reserved for parameter prefetching for the next block.

By applying the scheme, when each transaction is executed, the value of the parameter read by each transaction is not required to be obtained from the state database of the storage area through IO operation, so that the IO operation of the nodes of the block chain is reduced, the purpose of reducing time delay is achieved, the transaction execution efficiency is improved, the problem of transaction data update lag is solved, the value of the parameter stored in the cache area can be more accurate, and the transaction execution success rate is improved.

In correspondence with the above embodiments of the method for performing blockchain transactions, the present specification also provides embodiments of nodes of blockchain.

As shown in fig. 11, fig. 11 is a node of a blockchain shown in the present specification according to an exemplary embodiment, and the node may include: a first obtaining module 1101, an executing module 1102 and a result consensus module 1103.

The first obtaining module 1101 is configured to obtain a plurality of transactions belonging to the first block, where the plurality of transactions are partial transactions in all transactions belonging to the first block.

An execution module 1102 for executing the plurality of transactions.

A result consensus module 1103, configured to perform consensus on the execution results of the plurality of transactions before all transactions belonging to the first block are executed.

In some embodiments, the node may further comprise: a return module (not shown in the figure).

The return module is used for returning the execution result of the transaction which is successfully agreed to the user equipment after the execution results of the plurality of transactions are agreed.

In other embodiments, the node may further include: the block is stored in a module (not shown).

The block storing module is used for storing the data of the transactions into the block database as part of the block of the first block after the execution results of the transactions are identified.

In other embodiments, the node may further include: the block header is stored in a module (not shown).

The block head storing module is used for storing the block head of the first block into the block database after all transactions of the first block are executed and the consensus is completed.

In other embodiments, the node may further include: a generating module (not shown in the figure).

The generating module is used for generating the block head of the first block at least after the execution results of all the transactions belonging to the first block are identified.

In other embodiments, the generating module is configured to: after the execution results of all transactions belonging to the first block are completely identified and the block identification of the previous block of the first block is successful, a block header of the first block is generated.

In other embodiments, the node may further include: a block consensus module (not shown).

The block consensus module is used for performing block consensus on the first block after generating a block header of the first block.

Wherein the block header storing module is configured to: if the block consensus of the first block is successful, the block head of the first block is stored in the block database.

In other embodiments, the node may further include: a second acquisition module (not shown).

The second acquisition module is used for acquiring a first set of each of the plurality of transactions, and the first set of any transaction comprises an identifier of a parameter read by the transaction.

In other embodiments, the node may further include: and logging module (not shown).

The storage module is used for acquiring the value of each read parameter identifier in each first set of the plurality of transactions from the state database if the value of the parameter corresponding to the identifier is not stored in the cache region, and storing the value of the parameter into the cache region.

Wherein the execution module 1102 is configured for: a plurality of transactions are executed based on the values of the respective parameters stored in the cache area.

In other embodiments, the cache region includes a first cache region and a second cache region. Storing the value of the parameter in a buffer, including storing the value of the parameter in the first buffer.

Wherein, the node may further include: a memory module (not shown).

The storage module is configured to store, after the execution results of the multiple transactions are identified in common, the values of the write parameters included in the execution results of the transactions that are identified successfully in the multiple transactions in the second cache area with respect to the respective blocks to which the transactions that are identified successfully belong.

In other embodiments, the node may further include: update module (not shown).

And the updating module is used for updating the world state in the state database according to the values of the parameters stored in the second cache region relative to the first block after the written-in parameters included in the execution results of the transactions successfully identified in all the transactions belonging to the first block are all stored in the second cache region.

In further embodiments, the first set of any transaction further includes an identification of a parameter written by the transaction.

Wherein the first obtaining module 1101 is configured to: all transactions are obtained for a plurality of blocks, including a first block.

Wherein the execution module 1102 is configured for: all transactions are grouped based on their respective first sets to obtain a plurality of transaction groups. The following processes are performed in parallel for a plurality of transaction groups: for each transaction group, the transactions included in the transaction group are executed serially.

In other embodiments, the result consensus module 1103 is configured to: the results of execution of a predetermined number of transactions consecutively executed in any transaction group are identified, the predetermined number of transactions including a plurality of transactions.

As shown in fig. 12, fig. 12 is a block diagram illustrating a structure of a node of a blockchain according to an exemplary embodiment, where the node may include: control device 1201 and computing device 1202.

The control device 1201 is configured to obtain a plurality of transactions belonging to the first block, and send the plurality of transactions to the computing device 1202; and consensus is made on the execution results of the plurality of transactions before the computing device 1202 executes all transactions belonging to the first block. The plurality of transactions are part of all transactions belonging to the first block.

The computing device 1202 is configured to execute a plurality of transactions, and return execution results of the plurality of transactions to the control device 1201.

As shown in fig. 13, fig. 13 is a block diagram illustrating a control apparatus for a blockchain node according to an exemplary embodiment of the present disclosure, where the control apparatus may include: a first obtaining unit 1301, an indicating unit 1302 and a result identifying unit 1303.

The first obtaining unit 1301 is configured to obtain multiple transactions belonging to the first block, where the multiple transactions are partial transactions in all transactions belonging to the first block.

The instructing unit 1302 is configured to instruct the block link point to perform a plurality of transactions.

The result consensus unit 1303 is configured to perform consensus on the execution results of the multiple transactions before all transactions belonging to the first block are executed at the block link point.

In some embodiments, the control apparatus for a blockchain node may further include: a return unit (not shown in the figure).

The return unit is used for returning the execution result of the transaction with successful consensus to the user equipment after the execution results of the plurality of transactions are consensus.

In other embodiments, the control apparatus for a blockchain node may further include: the block storing unit (not shown).

The block storing unit is used for indicating the block link points to store the data of the plurality of transactions as partial blocks of the first block into the block database after the execution results of the plurality of transactions are identified.

In other embodiments, the control apparatus for a blockchain node may further include: a block header storing unit (not shown).

The block head storing unit is used for indicating the block link point to store the block head of the first block into the block database after all transactions of the first block are executed and the consensus is completed.

In other embodiments, the control apparatus for a blockchain node may further include: a generating unit (not shown in the figure).

The generating unit is used for generating the block head of the first block at least after the execution results of all the transactions belonging to the first block are identified.

In further embodiments, the generating unit is configured to: after the execution results of all transactions belonging to the first block are completely identified and the block identification of the previous block of the first block is successful, a block header of the first block is generated.

In other embodiments, the control apparatus for a blockchain node may further include: a block consensus unit (not shown).

The block consensus unit is used for performing block consensus on the first block after generating a block header of the first block.

Wherein the block header storing unit is configured to: if the block consensus of the first block is successful, the indicated block link point stores the block header of the first block into the block database.

In other embodiments, the control apparatus for a blockchain node may further include: a second acquisition unit (not shown in the figure).

The second acquisition unit is used for acquiring a first set of each of the plurality of transactions, and the first set of any transaction comprises the identifier of the parameter read by the transaction.

In other embodiments, the control apparatus for a blockchain node may further include: a logging unit (not shown in the figure).

And the storing unit is used for acquiring the value of the parameter from the state database and storing the value of the parameter into the cache region if the value of the parameter corresponding to the identifier is not stored in the cache region for the identifier of each read parameter in the respective first set of the plurality of transactions.

Wherein the indication unit 1302 is configured to: the block link point is instructed to perform a plurality of transactions based on the values of the various parameters stored in the buffer.

Wherein, the control device for the block chain node may further include: a storage unit (not shown in the figure).

The storage unit is configured to store, after the execution results of the multiple transactions are identified in common, the value of the write parameter included in the execution result of each transaction that is identified successfully in the multiple transactions in the second cache area with respect to the block to which each transaction that is identified successfully belongs.

In other embodiments, the control apparatus for a blockchain node may further include: an update unit (not shown in the figure).

The updating unit is used for updating the world state in the state database according to the values of the parameters stored in the second cache region relative to the first block after the written-in parameters included in the execution results of the transactions successfully identified in all the transactions belonging to the first block are stored in the second cache region.

Wherein the first obtaining unit 1301 is configured to: all transactions are obtained for a plurality of blocks, including a first block.

Wherein the indication unit 1302 is configured to: all transactions are grouped based on their respective first sets to obtain a plurality of transaction groups. Indicating the block link point to perform the following processing on a plurality of transaction groups in parallel: for each transaction group, the transactions included in the transaction group are executed serially.

In other embodiments, the result consensus unit 1303 is configured to: the results of execution of a predetermined number of transactions consecutively executed in any transaction group are identified, the predetermined number of transactions including a plurality of transactions.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of one or more embodiments of the present specification. One of ordinary skill in the art can understand and implement it without inventive effort.

One or more embodiments of the present specification further provide a computer-readable storage medium storing a computer program, where the computer program can be used to execute the method for performing blockchain transaction provided in any one of the embodiments of fig. 2 to 8.

Corresponding to the above-described blockchain transaction execution method, one or more embodiments of the present specification further propose a schematic block diagram of an electronic device according to an exemplary embodiment of the present specification shown in fig. 14. Referring to fig. 14, at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, but may also include hardware required for other services. The processor reads a corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to form the block chain transaction execution device on a logic level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

It will be further appreciated by those of ordinary skill in the art that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application. The software modules may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

The above-mentioned embodiments, objects, technical solutions and advantages of the present application are described in further detail, it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present application, and are not intended to limit the scope of the present application, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present application should be included in the scope of the present application.

Claims

1. A blockchain transaction execution method is applied to nodes of a blockchain, and the method comprises the following steps:

executing the plurality of transactions;

2. The method of claim 1, further comprising:

3. The method of claim 1, further comprising:

4. The method of claim 3, after all transactions of the first block are performed and consensus is complete, the method further comprising:

and storing the block head of the first block into the block database.

5. The method of claim 4, further comprising:

6. The method of claim 5, wherein generating a tile header for the first tile at least after the consensus is completed for the execution results of all transactions belonging to the first tile comprises: and after the execution results of all the transactions belonging to the first block are subjected to consensus and the block consensus on the previous block of the first block is successful, generating a block header of the first block.

7. The method of any of claims 4-6, after generating the tile header for the first tile, the method further comprising: performing block consensus on the first block;

8. The method of any of claims 1-6, further comprising:

9. The method of claim 8, further comprising:

10. The method of claim 9, wherein the cache region comprises a first cache region and a second cache region; storing the value of the parameter into the buffer area comprises storing the value of the parameter into the first buffer area;

wherein the method further comprises:

11. The method according to claim 10, wherein after the values of the written parameters included in the execution results of the transactions that are successfully recognized among all the transactions belonging to the first block are stored in the second buffer, further comprising: and updating the world state in the state database according to the values of the parameters stored in the second cache region relative to the first block.

12. The method of claim 8, wherein the first set of any transaction further includes an identification of parameters written by that transaction;

wherein the executing the plurality of transactions comprises:

13. The method of claim 12, wherein said consensus of the results of the execution of the plurality of transactions comprises: the results of execution of a predetermined number of transactions consecutively executed in any transaction group are identified, the predetermined number of transactions including the plurality of transactions.

14. A block link point, comprising:

an execution module to execute the plurality of transactions;

15. A block link point comprises a control device and a calculation device;

16. A control apparatus for a blockchain node, comprising:

17. A computer-readable storage medium, having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of any of claims 1-13.

18. A computing device comprising a memory having executable code stored therein and a processor that, when executing the executable code, implements the method of any of claims 1-13.