CN112988819B

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

Info

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

Abstract

The present specification provides a blockchain transaction execution method, a blockchain node, and a control device, according to which a plurality of transactions are obtained, the plurality of transactions including all transactions belonging to a first block and all transactions belonging to a second block; the first block is a previous block of the second block; obtaining a plurality of transaction groups based on the parameters read and written by the transactions respectively; performing the following processing in parallel for the plurality of transaction groups: for each transaction group, serially executing transactions included in the transaction group; and after determining that the block generation and the block consensus of the first block are finished and all transactions belonging to the second block are finished, finishing the generation of the second block and carrying out the block consensus on the second block. Thereby improving the performance of the blockchain system.

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, the plurality of transactions including all transactions belonging to a first block and all transactions belonging to a second block; the first block is a previous block of the second block;

obtaining a plurality of transaction groups based on the parameters read and written by the transactions respectively;

performing the following processing in parallel for the plurality of transaction groups: for each transaction group, serially executing transactions included in the transaction group;

and after determining that the block generation and the block consensus of the first block are finished and all transactions belonging to the second block are finished, finishing the generation of the second block and carrying out the block consensus on the second block.

Optionally, the method further includes: prior to executing the plurality of transactions, consensus is made on the results of the execution of the completed portion of the transactions.

Optionally, the method further includes:

and storing the data of each transaction which is recognized as at least part of the block body of the block to which the data belongs into a block database.

Optionally, the method further includes: after the execution results of the executed partial transactions are identified, storing the values of the write-in parameters included in the execution results of the successfully executed transactions in the executed partial transactions into a second cache region relative to the blocks to which the successfully executed transactions belong;

wherein the completing the generation of the second block comprises:

after the written parameter values included in the execution results of the respective transactions successfully executed in all the transactions belonging to the second block are stored in the second cache region, update data of the second block on the world state is acquired based on the parameter values stored in the second cache region relative to the second block, and a block header of the second block is generated based on the update data.

Optionally, after the block consensus of the second block is successful, the method further includes: and storing the block head of the second block into the block database.

Optionally, after the block consensus of the second block is successful, the method further includes: deleting the values of the parameters stored in the second cache area relative to the second block.

Optionally, the method further includes, for each parameter read in the multiple transactions, if the value of the parameter is not stored in the first cache region and the second cache region, obtaining the value of the parameter from the state database, and storing the value of the parameter in the first cache region; the serially executing, for each transaction group, the transactions included in the transaction group includes serially executing, for each transaction group, the transactions included in the transaction group based on the values of the parameters stored in the first cache region.

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

the control device acquires a plurality of transactions, obtains a plurality of transaction groups based on the read and written parameters of the transactions respectively, and sends the transaction groups to the computing device; the plurality of transactions includes all transactions belonging to a first block and all transactions belonging to a second block; the first block is a previous block of the second block;

the computing device performs the following processing for the plurality of transaction groups in parallel: for each transaction group, serially executing transactions included in the transaction group;

after determining that the block generation and the block consensus of the first block are completed and all transactions belonging to the second block are completed, the control device completes the generation of the second block and the block consensus of the second block.

Optionally, the method further includes: the control means makes a consensus on the execution results of the partial transactions that have been executed, before the plurality of transactions are executed.

Optionally, the node of the blockchain further includes a storage device; the method further comprises the following steps:

the control device instructs the storage device to store the data of each transaction that completed the consensus in the block database as at least a partial block of the block to which the storage device belongs.

Optionally, the method further includes: after the execution results of the executed partial transactions are identified, the control device stores the values of the write parameters included in the execution results of the successfully executed transactions in the executed partial transactions in a second cache area relative to the block to which each successfully executed transaction belongs;

wherein the control device completes generation of the second block, and includes:

after storing the values of the written parameters included in the execution results of the respective transactions that have been successfully executed out of all the transactions belonging to the second block into the second cache area, the control device acquires update data of the world state of the second block based on the values of the respective parameters stored in the second cache area with respect to the second block, and generates a block header of the second block based on the update data.

Optionally, after the block consensus of the second block is successful, the method further includes: the control means instructs the storage means to store the block header of the second block in the block database.

Optionally, after the block consensus of the second block is successful, the method further includes: the control device deletes the values of the parameters stored in the second cache area relative to the second block.

Optionally, the node of the blockchain further includes a storage device; the method further comprises, for each parameter read from the plurality of transactions, if the value of the parameter is not stored in either the first cache area or the second cache area, the control device obtaining the value of the parameter from the status database of the storage device and storing the value of the parameter in the first cache area; the computing device, for each transaction group, serially executing the transactions included in the transaction group includes, for each transaction group, serially executing the transactions included in the transaction group based on the values of the parameters stored in the first cache region.

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

a first obtaining module for obtaining a plurality of transactions, the plurality of transactions including all transactions belonging to a first block and all transactions belonging to a second block; the first block is a previous block of the second block;

the grouping module is used for obtaining a plurality of transaction groups based on the parameters read and written by the transactions respectively;

an execution module, configured to perform the following processing for the plurality of transaction groups in parallel: for each transaction group, serially executing transactions included in the transaction group;

and the block consensus module is used for finishing the generation of the second block and carrying out block consensus on the second block after determining that the block generation and consensus on the first block are finished and all transactions belonging to the second block are finished.

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

the control device is used for acquiring a plurality of transactions, obtaining a plurality of transaction groups based on the read and written parameters of the transactions respectively, and sending the transaction groups to the computing device; and after determining that the block generation and consensus for the first block is completed and all transactions belonging to the second block are performed, completing the generation of the second block and performing block consensus for the second block; the plurality of transactions includes all transactions belonging to a first block and all transactions belonging to a second block; the first block is a previous block of the second block;

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

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

a first acquisition unit configured to acquire a plurality of transactions including all transactions belonging to a first block and all transactions belonging to a second block; the first block is a previous block of the second block;

the grouping unit is used for obtaining a plurality of transaction groups based on the parameters read and written by the transactions respectively;

an indicating unit, configured to indicate the block link node to perform the following processing for the plurality of transaction groups in parallel: for each transaction group, serially executing transactions included in the transaction group;

and the block consensus unit is used for finishing the generation of the second block and carrying out block consensus on the second block after determining that the generation and consensus on the first block are finished and all transactions belonging to the second block are finished.

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 blockchain transactions and the blockchain node provided by the embodiments of the present specification obtain a plurality of transactions, where the plurality of transactions include all transactions belonging to a first block and all transactions belonging to a second block, obtain a plurality of transaction groups based on respective read and write parameters of the plurality of transactions, and perform the following processing for the plurality of transaction groups in parallel: for each transaction group, the transactions included in the transaction group are executed serially. After determining that the block generation and consensus for the first block is completed and all transactions belonging to the second block are performed, the block generation for the second block is completed and the block consensus is performed for the second block. In the embodiment, after the block generation and the block consensus of one block are determined to be completed and all transactions of the next block belonging to the block are performed, the generation of the next block is completed and the block consensus is performed on the next block, so that 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 schematic diagram illustrating a blockchain transaction execution scenario in accordance with an exemplary embodiment of the present description;

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

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

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

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

FIG. 10 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 is obtained, the plurality of transactions including all transactions belonging to the first block and all transactions belonging to the second block.

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

In step 304, a plurality of transaction groups are derived based on the parameters read and written by each of the plurality of transactions.

In this embodiment, the multiple transactions may be grouped together. Specifically, first, parameters for each of the plurality of transactions read and write may be determined. Determining that there is an access conflict transaction based on the parameters read and written by each of the plurality of transactions. Then, the plurality of transactions are grouped to obtain a plurality of transaction groups based on the determined result, so that the transactions with access conflict are grouped into the same transaction group, and the rest transactions without access conflict can be randomly distributed.

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

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

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

In this embodiment, for each parameter read in the multiple transactions, if the value of the parameter is not stored in the first buffer area and the second buffer area, the value of the parameter may be obtained from the status database and stored in the first buffer area. For each transaction group, the transactions included in the transaction group are executed serially based on the value of the parameter stored in the first cache region.

In this embodiment, before the execution of the plurality of transactions is completed, the execution results of the executed partial transactions may be identified. Specifically, the execution results of the multiple transactions may be consensus verified by multiple nodes of the blockchain to determine whether each of the multiple transactions was successfully executed. And storing the data of each transaction which is recognized as at least part of the block body of the block to which the data belongs into a block database. After the execution results of the executed partial transactions are identified, the values of the write parameters included in the execution results of the successfully executed transactions in the executed partial transactions are stored in the second cache area relative to the block to which each successfully executed transaction belongs.

In step 308, after determining that the block generation and consensus for the first block is completed and all transactions belonging to the second block are performed, the block generation for the second block is completed and the block consensus is performed for the second block.

In this embodiment, after the values of the written parameters included in the execution results of the respective transactions successfully executed in all the transactions belonging to the second block are stored in the second buffer, the update data of the second block to the world state may be acquired based on the values of the respective parameters stored in the second buffer relative to the second block, the block header of the second block may be generated based on the update data, and the second block may be block-shared. Specifically, the block consensus on the second block is to compare whether hash values of block headers of the second block corresponding to nodes of each block chain are the same, and if the hash values are 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.

In this embodiment, after the block identity of the second block is successful, the block header of the second block is stored in the block database. And may delete the values of the various parameters stored in the second cache area relative to the second chunk.

The method for performing blockchain transactions provided in the above embodiments of the present specification obtains a plurality of transactions, where the plurality of transactions includes all transactions belonging to a first block and all transactions belonging to a second block, obtains a plurality of transaction groups based on respective read and write parameters of the plurality of transactions, and performs the following processing for the plurality of transaction groups in parallel: for each transaction group, the transactions included in the transaction group are executed serially. After determining that the block generation and consensus for the first block is completed and all transactions belonging to the second block are performed, the block generation for the second block is completed and the block consensus is performed for the second block. In the embodiment, after the block generation and the block consensus of one block are determined to be completed and all transactions of the next block belonging to the block are performed, the generation of the next block is completed and the block consensus is performed on the next block, so that the performance of the block chain system is improved.

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. 4 is a flow chart illustrating a method of blockchain transaction execution according to an example 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 402, 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 404, the control device pre-fetches parameter values from the storage device for all transaction read parameters of the plurality of blocks.

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

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

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

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

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

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

In step 406, 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 408, the control device sends the values of the parameters and the transaction sets stored in the first buffer to the computing device.

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

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

In step 414, the control device identifies 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 416, 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 buffer of the above-mentioned buffers, 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 418, the control device requests that the data of each transaction that completed the consensus be stored in the tile database as at least a portion of the tile to which it belongs.

In step 420, 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 422, 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 424, 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 426, the storage device stores the block header of the block in the block database.

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

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

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

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

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

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

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

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

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

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

Then, before completing the transactions 1-18, the executed partial transactions can be identified by a plurality of nodes of the blockchain based on the result of executing the completed transactions to determine whether the partial transactions are executed successfully. For example, when all transactions in the transaction group a are executed and completed, all transactions in the transaction group a may be agreed (or, when the transactions 1 to 3 in the transaction group a are executed and completed, the transactions 1 to 3 may be agreed), and whether all transactions in the transaction group a are executed successfully or not may be determined. If the node A is an accounting node in the block chain or a node connected with the client side in an abutting mode, the execution result of each transaction which is successfully identified can be returned to the client side, and the execution failure information of the transaction which is failed in the identification can be returned to the client side. Then, after the completed partial transactions have been executed for consensus, for example, after all transactions in the transaction group a are agreed, the control device of the node a obtains the values of the written parameters included in the execution results of the respective transactions in the transaction group a for which consensus is successful, and stores the values of the written parameters included in the execution results of the respective transactions in the transaction group a for which consensus is successful in the second cache area, so as to update and maintain the data stored in the cache. Specifically, the control means of the node a may store, in the second buffer, the value of the parameter written included in the execution result of the transaction which is acknowledged as successful, corresponding to the block to which the transaction belongs. For a plurality of transactions which are successfully identified and executed in series in the same block, the values of the write-in parameters of the transactions are sequentially stored in the second cache region corresponding to the block according to the execution sequence of the transactions, so that the correctness of the parameter state is ensured. For example, as shown in fig. 5, 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. 5, 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. 5), 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. 6 shows a schematic structure of the block 101. As shown in fig. 6, 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, the control device generates a block header of the block 101 as shown in fig. 6 based on the hash value of the block 100 and data of all transactions belonging to the block 101 in the case where it is determined that the block consensus on the block 100 is successful. As shown in fig. 6, 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. 5, 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. 5, 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. 7, fig. 7 is a node of a blockchain shown in the present specification according to an exemplary embodiment, and the node may include: a first obtaining module 701, a grouping module 702, an executing module 703 and a block consensus module 704.

The first obtaining module 701 is configured to obtain a plurality of transactions, where the plurality of transactions include all transactions belonging to the first block and all transactions belonging to the second block. The first block is a previous block of the second block.

A grouping module 702, configured to obtain a plurality of transaction groups based on the parameters read and written by the transactions respectively.

An executing module 703, configured to perform the following processing for the multiple transaction groups in parallel: for each transaction group, the transactions included in the transaction group are executed serially.

And a block consensus module 704, configured to complete generation of the second block and perform block consensus on the second block after determining that block generation and consensus on the first block are completed and performing all transactions belonging to the second block are completed.

In some embodiments, the node may further comprise: a result consensus module (not shown).

The result consensus module is used for performing consensus on the execution results of the executed partial transactions before the execution of the plurality of transactions is completed.

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

The block storing module is used for storing the data of each identified transaction as at least part of the block to which the data of each identified transaction belongs into the block database.

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

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

The block consensus module 704 completes generation of the second block by: after the written parameter values included in the execution results of the respective transactions successfully executed in all the transactions belonging to the second block are stored in the second cache area, the update data of the second block on the world state is acquired based on the values of the respective parameters stored in the second cache area relative to the second block, and the block header of the second block is generated based on the update data.

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

The block head storage module is used for storing the block head of the second block into the block database after the block identification of the second block is successful.

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

And the deleting module is used for deleting the values of the parameters stored in the second cache area relative to the second block.

As shown in fig. 8, fig. 8 is a block diagram illustrating a structure of a node of a blockchain according to an exemplary embodiment, where the node may include: a control device 801 and a calculation device 802.

The control device 801 is configured to obtain a plurality of transactions, obtain a plurality of transaction groups based on parameters read and written by the transactions, and send the transaction groups to the computing device 802. And after determining that the block generation and consensus for the first block is completed and all transactions belonging to the second block are performed, completing the generation of the second block and performing the block consensus for the second block. The plurality of transactions includes all transactions belonging to a first block and all transactions belonging to a second block, the first block being a previous block to the second block.

A computing device 802 for performing the following in parallel for the plurality of transaction groups: for each transaction group, the transactions included in the transaction group are executed serially.

As shown in fig. 9, fig. 9 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 901, a grouping unit 902, an indicating unit 903 and a block identifying unit 904.

The first obtaining unit 901 is configured to obtain a plurality of transactions, where the plurality of transactions include all transactions belonging to a first block and all transactions belonging to a second block, and the first block is a previous block of the second block.

A grouping unit 902, configured to obtain a plurality of transaction groups based on the parameters read and written by the plurality of transactions respectively.

An instructing unit 903, configured to instruct the blockchain node to perform the following processing for the multiple transaction groups in parallel: for each transaction group, the transactions included in the transaction group are executed serially.

A block consensus unit 904, configured to complete the generation of the second block and perform block consensus on the second block after determining that the block generation and consensus on the first block are completed and performing all transactions belonging to the second block are completed.

In some embodiments, the control device may further include: result consensus unit (not shown in the figure).

The result consensus unit is used for performing consensus on the execution results of the executed partial transactions before executing and completing the plurality of transactions.

In other embodiments, the control device may further include: the block storing unit (not shown).

The block storing unit is used for indicating the block chain nodes to store the data of the common transactions as at least partial block of the block to which the block chain nodes belong in the block database.

In other embodiments, the control device may further include: a storage unit (not shown in the figure).

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

The block consensus unit 704 completes generation of the second block by: after the values of the written parameters included in the execution results of the respective transactions successfully executed in all the transactions belonging to the second block are stored in the second cache area, update data of the second block on the world state is acquired based on the values of the respective parameters stored in the second cache area relative to the second block, and a block header of the second block is generated based on the update data.

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

And the block head storing unit is used for indicating the block chain node to store the block head of the second block into the block database after the block consensus of the second block is successful.

In other embodiments, the control device may further include: a deletion unit (not shown in the figure).

And the deleting unit is used for deleting the values of the parameters stored in the second cache area relative to the second block.

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

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

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. 10. Referring to fig. 10, 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:

2. The method of claim 1, further comprising: prior to executing the plurality of transactions, consensus is made on the results of the execution of the completed portion of the transactions.

3. The method of claim 2, further comprising:

4. The method of claim 3, further comprising: after the execution results of the executed partial transactions are identified, storing the values of the write-in parameters included in the execution results of the successfully executed transactions in the executed partial transactions into a second cache region corresponding to the blocks to which the successfully executed transactions belong;

wherein the completing the generation of the second block comprises:

after the written parameter values included in the execution results of the respective transactions successfully executed in all the transactions belonging to the second block are stored in a second cache region, update data of the second block on the world state is acquired based on the parameter values stored in the second cache region corresponding to the second block, and a block header of the second block is generated based on the update data.

5. The method of claim 4, after successful block consensus for the second block, the method further comprising: and storing the block head of the second block into the block database.

6. The method of claim 4, after successful block consensus for the second block, the method further comprising: deleting the values of the parameters stored in the second cache area corresponding to the second block.

7. The method of claim 4, further comprising, for each parameter read from the plurality of transactions, if the value of the parameter is not stored in both the first cache area and the second cache area, retrieving the value of the parameter from a status database and storing the value of the parameter in the first cache area; the serially executing, for each transaction group, the transactions included in the transaction group includes serially executing, for each transaction group, the transactions included in the transaction group based on the values of the parameters stored in the first cache region.

8. A blockchain transaction execution method is applied to nodes of a blockchain, the nodes of the blockchain comprise a control device and a computing device, and the method comprises the following steps:

9. The method of claim 8, further comprising: the control means makes a consensus on the execution results of the partial transactions that have been executed, before the plurality of transactions are executed.

10. The method of claim 9, the nodes of the blockchain further comprising a storage device; the method further comprises the following steps:

11. The method of claim 10, further comprising: after the execution results of the executed partial transactions are identified, the control device stores the values of the write parameters included in the execution results of the successfully executed transactions in the executed partial transactions into a second cache region corresponding to the blocks to which the successfully executed transactions belong;

after storing the values of the written parameters included in the execution results of the respective transactions that have been successfully executed out of all the transactions belonging to the second block into a second cache area, the control device acquires update data of the second block on the world state based on the values of the respective parameters stored in the second cache area corresponding to the second block, and generates a block header of the second block based on the update data.

12. The method of claim 11, after successful block consensus for the second block, the method further comprising: the control means instructs the storage means to store the block header of the second block in the block database.

13. The method of claim 11, after successful block consensus for the second block, the method further comprising: the control device deletes the values of the parameters stored in the second cache area corresponding to the second block.

14. The method of claim 11, the nodes of the blockchain further comprising a storage device; the method further comprises, for each parameter read from the plurality of transactions, if the value of the parameter is not stored in either the first cache area or the second cache area, the control device obtaining the value of the parameter from the status database of the storage device and storing the value of the parameter in the first cache area; the computing device, for each transaction group, serially executing the transactions included in the transaction group includes, for each transaction group, serially executing the transactions included in the transaction group based on the values of the parameters stored in the first cache region.

15. A block link point, comprising:

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

the control device is used for acquiring a plurality of transactions, and the transactions comprise all transactions belonging to a first block and all transactions belonging to a second block; the first block is a previous block of the second block; obtaining a plurality of transaction groups based on the read and written parameters of the transactions respectively, and sending the transaction groups to the computing device; and after determining that the block generation and consensus for the first block is completed and all transactions belonging to the second block are performed, completing the generation of the second block and performing block consensus for the second block;

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

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

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