CN112884588B

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

Info

Publication number: CN112884588B
Application number: CN202110481503.5A
Authority: CN
Inventors: 卓海振; 陆钟豪
Original assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-04-30
Filing date: 2021-04-30
Publication date: 2021-08-03
Anticipated expiration: 2041-04-30
Also published as: CN112884588A

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; executing the plurality of transactions; consensus is made on the results of the execution of the plurality of transactions; using the data of each transaction which is identified in common as at least part of the block body of the first block and storing the data into a block database; after all transactions of the first block are executed and the consensus is completed, storing the block head of the first block into the block database. Therefore, the purpose of reducing time delay is achieved, and the performance of the block chain system is improved.

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:

obtaining a plurality of transactions belonging to a first block;

executing the plurality of transactions;

consensus is made on the results of the execution of the plurality of transactions;

using the data of each transaction which is identified in common as at least part of the block body of the first block and storing the data into a block database;

after all transactions of the first block are executed and the consensus is completed, storing the block head of the first block into the block database.

Optionally, the storing the data of each transaction that completes the consensus in a block database as at least a partial block of the first block includes:

and after the execution results of at least part of the transactions belonging to the first block are identified, storing the data of at least part of the transactions belonging to the first block into a block database as at least part of the block body of the first block.

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 determined to be successful, generating a block header of the first block.

Optionally, the consensus on the execution results of the multiple transactions includes: performing consensus verification on the execution results of the plurality of transactions by a plurality of nodes of the blockchain to determine whether the respective execution of the plurality of transactions is successful.

Optionally, the generating a block header of the first block includes:

generating a block header for the first block based on the hash value of a block preceding the first block and data of all transactions belonging to 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; the storing the value of the parameter into the buffer area includes: storing the value of the parameter in the first cache region;

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.

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, a computing device and a storage 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 computing device executes the plurality of transactions and returns execution results of the plurality of transactions to the control device;

the control device identifies the execution results of the plurality of transactions together and instructs the storage device to store the data of each transaction which completes the identification as at least part of the block body of the first block into a block database;

after all transactions of the first block are executed and the consensus is completed, the control device instructs the storage device to store the block header of the first block into the block database.

Optionally, the data instructing the storage device to complete the identified transactions is stored in a block database as at least a partial block of the first block, and includes:

after the consensus on the execution result of the at least partial transaction belonging to the first block is completed, instructing the storage device to store the data of the at least partial transaction belonging to the first block as the at least partial block body of the first block in a 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 it is determined that the block identification for the previous block of the first block is successful, the control device generates a block header of the first block.

Optionally, the generating, by the control device, a block header of the first block includes:

the control device generates a block header of the first block based on a hash value of a block previous to the first block and data of all transactions belonging to 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 control device successfully identifies the blocks of the first block, the control device instructs the storage device to store the block header 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.

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.

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

a first acquisition module for acquiring a plurality of transactions belonging to a first block;

an execution module to execute the plurality of transactions;

the result consensus module is used for performing consensus on the execution results of the plurality of transactions;

the block storing module is used for storing the data of each transaction which finishes the consensus into a block database as at least part of the block of the first block;

and 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 are identified.

According to a fourth aspect, there is provided a node of a blockchain, the node of the blockchain comprising control means, computing means and storage 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 identifying the execution results of the plurality of transactions, and instructing the storage device to store the data of each transaction which is identified as being completed as at least part of the block body of the first block into a block database; after all transactions of the first block are executed and the consensus is completed, instructing the storage device to store a block header of the first block into the block database;

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;

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

a result consensus unit for consensus on the execution results of the plurality of transactions;

the block body storing unit is used for indicating the block chain nodes to store the data of the commonly recognized transactions into a block database as at least part of block bodies of the first block;

and 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.

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:

the method for performing a blockchain transaction and the blockchain node provided by the embodiments of the present disclosure acquire a plurality of transactions belonging to a first block, perform the plurality of transactions, identify the execution results of the plurality of transactions, store data of each identified transaction as at least a part of a block of the first block in a block database, and store a block header of the first block in the block database after all transactions of the first block are performed and identified. 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.

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. 1 is an architecture diagram illustrating a blockchain system according to an exemplary embodiment of the present disclosure;

FIG. 2 is a block chain node structure diagram of any one of the block chain nodes in the block chain system shown in accordance with an exemplary embodiment;

FIG. 3 is a flow chart illustrating a method of performing blockchain transactions 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 schematic diagram illustrating a blockchain transaction execution scenario in accordance with an exemplary embodiment of the present description;

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

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

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

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

FIG. 13 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.

As shown in fig. 1, an architecture diagram of a block chain system is shown in accordance with an exemplary embodiment. Fig. 2 is a schematic structural diagram of any blockchain node in the blockchain system.

In the architecture diagram shown in fig. 1, nodes 1 to 6 are all block link points in a block link system. It is to be understood that fig. 1 is merely illustrative 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. 2, 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. 3, fig. 3 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 302, a plurality of transactions belonging to a first block are obtained.

In this embodiment, only a plurality of transactions belonging to the first block (the plurality of transactions may be partial transactions belonging to the first block or all transactions belonging to the first block) may be acquired, and all transactions belonging to a plurality of blocks (the plurality of blocks include the first block) may also be acquired. It is to be understood that the present embodiment is not limited in terms of the particular manner in which the plurality of transactions belonging to the first block are obtained.

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 results of the execution of the plurality of transactions are identified.

In this embodiment, the execution results of the plurality of transactions that have been executed and completed may be identified in common. 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.

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 transactions may be identified in any other reasonable manner, and the embodiment is not limited in this respect.

In this embodiment, after the consensus on the execution results is completed, a receipt after the consensus on each of the plurality of transactions can be obtained based on the results of the consensus. A receipt after the respective consensus of the plurality of transactions may be returned to the client by an accounting node in the blockchain system, or a node interfacing with the client. The accounting node or the node interfacing with the client can be any node in the blockchain system.

In step 308, the data of each transaction that completed the consensus is stored in the block database as at least a partial block of the first block.

In this embodiment, the data of each transaction that has completed the consensus may be stored in the tile database as at least a partial tile of the tile to which the transaction belongs. Specifically, after the consensus on the execution result of the at least partial transaction belonging to the first block is completed, the data of the at least partial transaction may be stored in the block database as the at least partial block of the first block. 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 all transactions of the first block are performed and the block consensus is completed, in a case where it is determined that the block consensus on 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 consensus is performed on the first block. If the block consensus of the first block is successful, the block head of the first block is stored into the block database.

The method for performing blockchain transactions provided in the above embodiments of the present specification obtains a plurality of transactions belonging to a first block, performs the plurality of transactions, identifies the execution results of the plurality of transactions, stores data of each identified transaction as at least a part of a block of the first block in a block database, and stores a block header of the first block in the block database after all transactions of the first block are performed and identified. 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 method for performing blockchain transaction, according to an exemplary embodiment, which describes a process of generating a blockhead of a first block, 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 a first block are obtained.

In step 404, the plurality of transactions are performed.

In step 406, the results of the execution of the plurality of transactions are identified.

In this embodiment, before all transactions belonging to the first block are executed, the execution results of the executed partial transactions may be commonly known. Specifically, the execution results of the partial transactions may be consensus-verified by a plurality of nodes of the blockchain to determine whether the partial transactions are each successfully executed. In one implementation, the transactions belonging to the first block may be grouped to obtain a plurality of transaction groups, and when one transaction group is completed, the execution results corresponding to the respective transactions of the transaction group are identified. In another implementation, the execution results of the predetermined number of transactions may also be identified in the order of completion of execution.

In this embodiment, after the consensus on each execution result is completed, a receipt after the consensus on each transaction can be obtained based on the result of the consensus. The receipt of the respective consensus of the partial transactions may be returned to the client by an accounting node in the blockchain system, or a node interfacing with the client. The accounting node or the node interfacing with the client can be any node in the blockchain system.

In step 408, the data of each transaction that completed the consensus is stored in the block database as at least a partial block of the first block.

In step 410, a block header is generated for the first block at least after the consensus is completed for the execution results of all transactions belonging to the first block.

In this embodiment, after the execution results of all transactions belonging to the first block are completely identified and it is determined that the block identification performed on the previous block of the first block is successful, the block header of the first block may be generated based on the hash value of the previous block of the first block and data of all transactions belonging to the first block.

In step 412, after all transactions for 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 all transactions of the first block are executed and the block consensus is completed, the block consensus is performed on the first block. If the block consensus of the first block is successful, the block head of the first block is stored into the block database.

Specifically, the block consensus compares whether hash values of block headers of the first blocks corresponding to the nodes of the block chains are all the same, and if the hash values are all the same, the block consensus is successful. The block header may include, but is not limited to, data such as a transaction root, a status root, and a receipt root, and the correctness of the block header and the correctness of the world status are verified by recognizing the block header.

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

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, performs the plurality of transactions, and identifies results of the plurality of transactions. And storing the data of all the transactions which are commonly recognized into a block database as at least part of block bodies of the first block, generating a block head of the first block at least after the execution results of all the transactions belonging to the first block are commonly recognized, and storing the block head of the first block into the block database after all the transactions of the first block are executed and commonly recognized. Due to the embodiment, after the execution results of all transactions belonging to the first block are known, the block header of the first block is generated, thereby improving the performance of the blockchain system.

As shown in fig. 5, fig. 5 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 502, a plurality of transactions belonging to a first block are obtained.

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 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, the transactions and the respective first sets are packed into data packets corresponding to the first block, and the data packets corresponding to the first block are 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 packages the transactions into a data packet corresponding to the first block, 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, the transactions may be packaged into packets corresponding to the first block and the packets corresponding to the first block may be 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 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 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. For example, after determining that the written values of the parameters included in the execution results of the transactions successfully identified in all the transactions belonging to the second block are all stored in the second cache region, for the identifier of each read parameter in the respective first set of the transactions of the first block, if the value of the parameter corresponding to the identifier is not stored in both the first cache region and the second cache region, the value of the parameter is obtained from the status database. Wherein the second block is a previous block of the first block.

In step 508, 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 510, the results of the execution of the plurality of transactions are identified together.

In step 512, the data of each transaction that completed the consensus is stored in the block database as at least a partial block of the first block.

In step 514, 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.

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 embodiment of the present specification, a plurality of transactions belonging to a first block are obtained, a first set of each of the plurality of transactions is obtained, and for an identifier of a parameter read from each of the first sets 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 the value of the parameter is stored in the cache region. Executing the multiple transactions based on the values of the parameters stored in the cache area, performing consensus on the execution results of the multiple transactions, storing the data of the consensus-completed transactions into the block database as at least part of block bodies of the first block, and storing the block heads of the first block into the block database after all transactions of the first block are executed and the consensus is completed. 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. 6 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. 6, which may be applied to a node of any blockchain, including the steps of:

in step 602, a plurality of transactions belonging to a first block are obtained.

In step 604, 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 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 results of the execution of the plurality of transactions are identified.

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 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.

In step 614, the data of each transaction that completed the consensus is stored in the tile database as at least a portion of the tile of the first tile.

In step 616, 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.

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 above embodiments of the present disclosure, a plurality of transactions belonging to a first block and a first set of the transactions are obtained. And 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 cache region, acquiring the value of the parameter from the state database, and storing the value of the parameter into the cache region. The method comprises the steps of executing a plurality of transactions based on values of parameters stored in a cache region, commonly identifying execution results of the transactions, and storing values of write-in parameters included in the execution results of the transactions successfully identified in the transactions into a second cache region included in the cache region relative to a block to which each transaction successfully identified belongs after commonly identifying the execution results of the transactions. And storing the data of the identified transactions into the block database as at least part of block bodies of the first block, and storing the block head of the first block into the block database after all transactions of the first block are executed and the identification is completed. 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.

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. 7 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 702, the control device obtains all transactions of the 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 704, the control device pre-fetches parameter values from the storage device for all transactional 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 706, the control device groups all transactions of the plurality of blocks 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 708, the control device sends the values of the parameters and the transaction sets stored in the first buffer to the computing device.

In step 710, 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 the 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 712, the computing device sends the control device the results of the execution of the completed partial transaction.

In step 714, the control device agrees on the results of the execution of the completed portion of the transaction.

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 716, the control device stores the value of the write parameter included in the execution result of each transaction that is successfully acknowledged in a second one of the cache areas with respect to the block to which the respective 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 718, 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 720, 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 transaction 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 722, 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 724, 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 726, the storage device stores the block header of the block in the block database.

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

In step 730, the storage device updates the world state 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. 8, 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. 8, 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. 8), 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. 9 shows a schematic structure of the block 101. As shown in fig. 9, 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. 9 based on the hash value of the block 100 and data of all transactions belonging to the block 101. As shown in fig. 9, 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. 8, 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. 8, 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. 10, fig. 10 is a node of a blockchain shown in the present specification according to an exemplary embodiment, and the node may include: the system comprises a first obtaining module 1001, an executing module 1002, a result consensus module 1003, a chunk storing module 1004 and a chunk header storing module 1005.

The first obtaining module 1001 is configured to obtain a plurality of transactions belonging to a first block.

An execution module 1002 is configured to execute the plurality of transactions.

A result consensus module 1003 for performing consensus on the execution results of the plurality of transactions.

The block storing module 1004 is configured to store the data of each transaction that completes the consensus in the block database as at least a part of the block of the first block.

The tile header storing module 1005 is configured to store the tile header of the first tile into the tile database after all transactions of the first tile are performed and the consensus is completed.

In some embodiments, the chunk store module 1004 is configured to:

and after the execution result of the at least part of the transaction belonging to the first block is identified, storing the data of the at least part of the transaction belonging to the first block into the block database as at least part of the block body of the first block.

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 determined to be successful, a block header of the first block is generated.

In other embodiments, the result consensus module 1003 is configured to: and carrying out consensus verification on the execution results of the plurality of transactions through a plurality of nodes of the blockchain so as to determine whether the plurality of transactions are executed successfully respectively.

In other embodiments, the generating module generates the tile header for the first tile by: a block header for the first block is generated based on the hash value of the previous block to the first block and data of all transactions belonging to the first block.

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 tile header storing module 1005 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).

And the storing module 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 execution module 1002 is configured to: 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 into a buffer, comprising: the value of the parameter is stored 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.

As shown in fig. 11, fig. 11 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 1101, computing device 1102, and storage device 1103.

The control device 1101 is configured to obtain a plurality of transactions belonging to the first block, and send the plurality of transactions to the computing device 1102. And performing consensus on the execution results of the multiple transactions, and instructing the storage device 1103 to store the data of each transaction that completes the consensus in the tile database as at least a part of the tile body of the first tile. After all transactions for the first tile are performed and the consensus is completed, the storage device 1103 is instructed to store the tile header of the first tile into the tile database.

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

As shown in fig. 12, fig. 12 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 acquiring unit 1201, an indicating unit 1202, a result recognizing unit 1203, a block storing unit 1204 and a block head storing unit 1205.

The first obtaining unit 1201 is configured to obtain a plurality of transactions belonging to a first block.

An indicating unit 1202 is configured to instruct the tile link node to perform multiple transactions.

A result consensus unit 1203 is used for performing consensus on the execution results of the plurality of transactions.

The block storing unit 1204 is configured to instruct the block links to store the data of the identified transactions as at least a part of the block of the first block in the block database.

A block header storing unit 1205, configured to instruct the block link node to store the block header of the first block into the block database after all transactions of the first block are performed and the consensus is completed.

In some embodiments, the chunk store unit 1204 is configured to:

after the consensus on the execution results of the at least partial transactions belonging to the first block is completed, instructing the block link to store the data of the at least partial transactions belonging to the first block as at least a partial block body of the first block in the block database.

In other embodiments, the control device further comprises: 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 determined to be successful, a block header of the first block is generated.

In other embodiments, the result consensus unit 1203 is configured to: and carrying out consensus verification on the execution results of the plurality of transactions through a plurality of nodes of the blockchain so as to determine whether the plurality of transactions are executed successfully respectively.

In other embodiments, the generating unit generates the block header of the first block by: a block header for the first block is generated based on the hash value of the previous block to the first block and data of all transactions belonging to the first block.

In other embodiments, the control device 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 1205 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 device 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 device 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 of the block chain node 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, and storing the value of the parameter into the cache region.

Wherein the indication unit 1202 is configured for: 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, this controlling means can also 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 device may further include: an update unit (not shown in the figure).

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

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 a blockchain transaction provided in any one of the embodiments of fig. 2 to 7.

Corresponding to the above block chain transaction execution method, one or more embodiments of the present specification also propose a schematic block diagram of an electronic device according to an exemplary embodiment of the present specification shown in fig. 13. Referring to fig. 13, 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:

obtaining a plurality of transactions belonging to a first block; the plurality of transactions are partial transactions belonging to a first block;

executing the plurality of transactions;

2. The method of claim 1, further comprising: 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.

3. The method of claim 2, 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 determined to be successful, generating a block header of the first block.

4. The method of claim 1, wherein the consensus on the results of the execution of the plurality of transactions comprises: performing consensus verification on the execution results of the plurality of transactions by a plurality of nodes of the blockchain to determine whether the respective execution of the plurality of transactions is successful.

5. The method of claim 2 or 3, wherein the generating a block header for the first block comprises:

6. The method of claim 2 or 3, wherein after generating the tile header for the first tile, further comprising: performing block consensus on the first block;

7. The method of any of claims 1-3, further comprising: 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.

8. The method of claim 7, further comprising: 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;

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

wherein the method further comprises:

10. The method according to claim 9, 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:

11. A blockchain transaction execution method applied to a blockchain node, the blockchain node comprising a control device, a computing device and a storage device, the method comprising:

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 belonging to a first block;

12. The method of claim 11, further comprising: 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.

13. The method of claim 12, wherein the controlling device 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: after the execution results of all transactions belonging to the first block are completely identified and it is determined that the block identification for the previous block of the first block is successful, the control device generates a block header of the first block.

14. The method of claim 11, wherein the controlling device generating a tile header for the first tile comprises:

15. The method according to claim 12 or 13, wherein after generating the tile header for the first tile, further comprising: the control device performs block consensus on the first block;

16. The method according to any one of claims 11-13, further comprising: 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.

17. The method of claim 16, further comprising: 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;

18. The method of claim 17, wherein the cache region comprises a first cache region and a second cache region; the storing the value of the parameter into the buffer area includes: storing the value of the parameter in the first cache region;

wherein the method further comprises:

19. The method according to claim 18, 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:

20. A block link point, comprising:

a first acquisition module for acquiring a plurality of transactions belonging to a first block; the plurality of transactions are partial transactions belonging to a first block;

an execution module to execute the plurality of transactions;

21. A block link point comprises a control device, a calculation device and a storage device;

the control device is used for acquiring a plurality of transactions belonging to a first block and sending the transactions to the computing device; the plurality of transactions are partial transactions belonging to a first block; and identifying the execution results of the plurality of transactions, and instructing the storage device to store the data of each transaction which is identified as being completed as at least part of the block body of the first block into a block database; after all transactions of the first block are executed and the consensus is completed, instructing the storage device to store a block header of the first block into the block database;

22. 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 belonging to a first block;

23. 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-19.

24. 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-19.