CN112883067A

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

Info

Publication number: CN112883067A
Application number: CN202110481378.8A
Authority: CN
Inventors: 卓海振; 陆钟豪
Original assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-04-30
Filing date: 2021-04-30
Publication date: 2021-06-01

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; for each parameter read by the transactions, if the value of the parameter is not stored in the cache region, obtaining the value of the parameter from a state database, and storing the value of the parameter into the cache region; executing the plurality of transactions based on the values of the respective parameters stored in the cache. Therefore, during the execution of each transaction, the value of the parameter read by each transaction is not required to be acquired from the state database of the storage area one by one 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.

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 transactions and a blockchain node.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. 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 and a blockchain node.

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;

for each parameter read by the transactions, if the value of the parameter is not stored in the cache region, obtaining the value of the parameter from a state database, and storing the value of the parameter into the cache region;

executing the plurality of transactions based on the values of the respective parameters stored in the cache.

Optionally, the method further includes:

obtaining a first set of each of the plurality of transactions, the first set of any transaction including an identification of a parameter accessed by the transaction; the accessed parameters comprise read parameters;

wherein, for each parameter read by the plurality of transactions, if the value of the parameter is not stored in the cache region, obtaining the value of the parameter from the state database, and storing the value of the parameter in the cache region, includes:

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.

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

wherein said obtaining a respective first set of said plurality of transactions comprises: obtaining a respective first set of all transactions for the plurality of tiles;

wherein, for the identifier of the parameter read from each of the first sets of the transactions, if the value of the parameter is not stored in the cache region, obtaining the value of the parameter from the status database, and storing the value of the parameter in the cache region, includes: and for each read parameter identifier in the respective first set of all transactions, if the value of the parameter is not stored in the cache region, acquiring the value of the parameter from a state database, and storing the value of the parameter into the cache region.

Optionally, the accessed parameters further include written parameters;

wherein the method further comprises: grouping all transactions based on the identity of each accessed parameter in the respective first set of all transactions to obtain a plurality of transaction groups;

wherein said performing the plurality of transactions based on the values of the respective parameters stored in the cache comprises: 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 based on the values of the respective parameters stored in the cache.

Optionally, before performing all transactions belonging to the first block, the method further comprises:

and carrying out consensus on the execution results of the executed and completed partial transactions.

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 executed partial transactions are identified, the values of the write parameters included in the execution results of the transactions successfully identified in the partial transactions are stored in a second cache area in the cache area relative to the block to which each transaction successfully identified belongs.

Optionally, a previous block of the first block is a second block;

if the value of the parameter is not stored in the cache region, obtaining the value of the parameter from a state database includes:

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, if the values of the parameters are not stored in the first cache region and the second cache region, obtaining the values of the parameters from a state database.

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, after all transactions of the first block are executed and the consensus is completed, the method further includes:

in the case that it is determined that the block consensus on the second block is successful, generating a block header of the first block; the previous block of the first block is a second block;

performing block consensus on the first block;

and if the block consensus of the first block is successful, storing the block head of the first block into the block database.

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;

for each parameter read by the transactions, if the value of the parameter is not stored in the cache region, the control device acquires the value of the parameter from the state database of the storage device and stores the value of the parameter into the cache region; and sending the plurality of transactions and the values of the respective parameters stored in the cache area to the computing device;

the computing device executes the plurality of transactions based on the values of the respective parameters stored in the cache.

Optionally, the method further includes:

the control device obtains a first set of each of the plurality of transactions, the first set of any transaction including an identification of a parameter to which the transaction has access; the accessed parameters comprise read parameters;

wherein, for each parameter read by the plurality of transactions, if the value of the parameter 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 in the cache region, including:

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, the control device obtains the value of the parameter from the state database of the storage device and stores the value of the parameter in the cache region.

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

wherein the control device obtains a respective first set of the plurality of transactions, including: the control device acquires a first set of all transactions of the plurality of blocks;

wherein, for the identifier of the parameter read from each of the first sets of the transactions, if the value of the parameter corresponding to the identifier is not stored in the cache region, the control device obtains the value of the parameter from the status database of the storage device and stores the value of the parameter into the cache region, including: for each read parameter identifier in the respective first set of all transactions, if the value of the parameter 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 in the cache region.

Optionally, the accessed parameters further include written parameters;

wherein the method further comprises: the control device groups all transactions based on the identification of each accessed parameter in the respective first set of all transactions to obtain a plurality of transaction groups; and sending the plurality of transaction groups to the computing device;

wherein the computing device performs the plurality of transactions based on the values of the respective parameters stored in the cache area, including: the computing device performs the following processing on the plurality of transaction groups in parallel: for each transaction group, the transactions included in the transaction group are executed serially based on the values of the respective parameters stored in the cache.

Optionally, before the computing device performs all transactions belonging to the first block, the method further comprises:

the control device recognizes the execution result of the executed partial transaction.

wherein the method further comprises:

after the control device identifies the execution results of the executed partial transactions, the control device stores the values of the write parameters included in the execution results of the transactions successfully identified in the partial transactions in a second cache region of the cache regions relative to the respective blocks to which the transactions successfully identified belong.

Optionally, a previous block of the first block is a second block;

if the value of the parameter is not stored in the cache region, the control device obtains the value of the parameter from a state database of the storage device, and the method includes:

after determining that the written values of the parameters included in the execution results of the transactions successfully identified among all the transactions belonging to the second block are stored in the second cache area, if the values of the parameters are not stored in the first cache area and the second cache area, the control device obtains the values of the parameters from the state database of the storage device.

Optionally, the method further includes:

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.

in a case where it is determined that the block consensus on the second block is successful, the control means generates a block header of the first block; performing block consensus on the first block; the previous block of the first block is a second block;

if the block consensus of the first block is successful, the control device instructs the storage device to store the block head of the first block into the block database.

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

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

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

the storage module is used for acquiring the value of each parameter read by the plurality of transactions from the state database and storing the value of the parameter into the cache region if the value of the parameter is not stored in the cache region;

an execution module to execute the plurality of transactions based on values of the respective parameters stored in the cache.

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; for each parameter read by the transactions, if the value of the parameter is not stored in the cache region, obtaining the value of the parameter from a state database of the storage device, and storing the value of the parameter into the cache region; and sending the plurality of transactions and the values of the respective parameters stored in the cache area to the computing device;

the computing device is used for executing the plurality of transactions based on the values of the parameters stored in the cache region;

the storage device is used for storing the state database.

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

an acquisition unit configured to acquire a plurality of transactions belonging to a first block;

a storage unit, configured to, for each parameter read in the multiple transactions, if the value of the parameter is not stored in the cache region, obtain the value of the parameter from the state database of the block chain node, and store the value of the parameter in the cache region;

an instructing unit, configured to instruct the blockchain node to execute the multiple transactions based on the values of the parameters stored in the cache.

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

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

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

embodiments of the present disclosure provide a method for performing a blockchain transaction and a blockchain node, which acquire a plurality of transactions belonging to a first block, acquire, for each parameter read by the plurality of transactions, if a value of the parameter is not stored in a cache region, a value of the parameter from a status database, store the value of the parameter in the cache region, and perform the plurality of transactions based on the value of each parameter stored in the cache region. Since the present embodiment prefetches the values of the parameters read by the transactions belonging to the first block before the transactions belonging to the first block are executed. 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.

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

Drawings

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Detailed Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In step 204, for each parameter read from the transactions, if the value of the parameter 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, 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 this embodiment, a node of the blockchain may first obtain a plurality of transactions belonging to the first block and determine respective parameters read by the plurality of transactions. Before executing the plurality of transactions, the nodes of the blockchain may prefetch values of the respective parameters read by the plurality of transactions. Specifically, for any parameter, first, the value of the parameter is searched from the local cache region, and if the value of the parameter is not stored in the local cache region, the value of the parameter may be obtained from the state database and stored in the local cache region. Before executing the transactions, storing the values of the parameters read by the transactions belonging to the first block in the cache area.

It should be noted that, if only a plurality of transactions belonging to the first block are obtained, and for each parameter read by the plurality of transactions, if the value of the parameter is not stored in the buffer, the value of the parameter is obtained from the status database and stored in the buffer. If all transactions of the plurality of blocks are acquired, for each parameter read by all transactions, if the value of the parameter is not stored in the cache region, the value of the parameter is acquired from the state database and is stored in the cache region.

In step 206, the plurality of transactions are executed based on the values of the respective parameters stored in 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 the method for executing blockchain transaction provided in the foregoing embodiment of the present specification, a plurality of transactions belonging to a first block are obtained, for each parameter read by the plurality of transactions, if the value of the parameter is not stored in the cache region, the value of the parameter is obtained from the status database, the value of the parameter is stored in the cache region, and the plurality of transactions are executed based on the values of the parameters stored in the cache region. Since the present embodiment prefetches the values of the parameters read by the transactions belonging to the first block before the transactions belonging to the first block are executed. 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. 3 is a flow chart illustrating another method for performing blockchain transactions, according to an exemplary embodiment, which describes a process of storing a value of the parameter in a buffer, as shown in fig. 3, which may be applied to a node of any blockchain, and includes the following steps:

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

In step 304, 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 transactions belonging to the first block and the respective first sets of the transactions may be obtained (the transactions may be partial transactions belonging to the first block or all transactions belonging to the first block), and all transactions belonging to the plurality of blocks (the blocks include the first block) and the respective first sets of the transactions may also be obtained. 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 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 306, 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.

It should be noted that, if only the transactions belonging to the first block and the respective first sets of the transactions are obtained, and the identifier of each read parameter in the respective first sets of the transactions is determined, if the value of the parameter corresponding to the identifier is not stored in the cache region, the value of the parameter is obtained from the status database, and the value of the parameter is stored in the cache region. If all transactions of the plurality of blocks and the respective first sets of all transactions are acquired, and for each read parameter identifier in the respective first sets of all 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.

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 308, a plurality of transactions are performed based on the values of the various parameters stored in the cache.

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

In the method for performing blockchain transactions provided in the above embodiments of the present specification, a plurality of transactions belonging to a first block and a first set of each of the plurality of transactions are obtained, where the first set of any transaction may include an identifier of a parameter read by the transaction. For each read parameter identifier in the first set of each 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, storing the value of the parameter in the cache region, and executing the multiple transactions based on the values of the parameters stored in the cache region. 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 the IO operation, so that the IO operation of the nodes of the block chain during the execution of the transaction is further reduced, and the delay caused by the execution of the transaction is favorably reduced.

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

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

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

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

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

In step 408, the total transactions are grouped based on the identification of each accessed parameter in the respective first set of total transactions to obtain a plurality of transaction groups.

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

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

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

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

In step 410, the following processes are performed in parallel for the plurality of transaction groups: for each transaction group, the transactions included in the transaction group are executed serially based on the values of the respective parameters stored in the buffer.

In this embodiment, multiple transaction groups may be processed in parallel by asynchronous threads or different computing devices. For each transaction group, the transactions included in the transaction group may be executed serially based on the values of the respective parameters stored in the cache.

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

The blockchain transaction execution method provided by the above embodiments of the present specification obtains all transactions of a plurality of blocks and a respective first set of the all transactions, where the first set of any transaction includes an identification of a parameter read by the transaction and a parameter written by the transaction. And for each read parameter identifier in the respective first set of all transactions, if the value of the parameter is not stored in the cache region, acquiring the value of the parameter from the state database, and storing the value of the parameter in the cache region. And grouping all the transactions based on the respective first set of all the transactions to obtain a plurality of transaction groups, and processing the transaction groups in parallel, wherein for each transaction group, the transactions included in the transaction group are executed in series based on the values of the parameters stored in the cache region. In the embodiment, all transactions in the plurality of blocks are grouped to obtain a plurality of transaction groups, and the plurality of transaction groups are executed in parallel, so that the transaction in the next block is executed after the transactions in one block are executed, the efficiency of executing the transactions is improved, and the time delay caused by waiting for the completion of the transactions in the previous block is reduced.

As shown in fig. 5, fig. 5 is a flow chart of another block chain transaction execution method according to an exemplary embodiment, which describes in detail the process before the complete transaction belonging to the first block is executed, and the method can be applied to a node of any block chain, and includes the following steps:

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

In step 504, for each parameter read from the plurality of transactions, if the value of the parameter is not stored in the buffer, the value of the parameter is obtained from the status database and stored in the buffer.

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

In step 508, the results of the execution of the completed partial transaction 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.

It should be noted that the executed partial transactions may all belong to the first block, or some partial transactions may not belong to the first block. For example, if transaction group A includes transaction a, transaction b, transaction c, and transaction d. Transaction a, transaction b and transaction c are partial transactions belonging to the first block, and transaction d belongs to the next block of the first block. After the transaction group A is executed, the execution results corresponding to the transactions in the transaction group are identified. At this time, the executed partial transactions may have one part belonging to the first block and another part not belonging to the first block.

In this embodiment, the node of each block chain may perform hash calculation on the execution result corresponding to each transaction of the partial transaction, so as 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 result of the executed partial transaction may be commonly known in any other reasonable manner, and the embodiment is not limited in this respect.

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.

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

In the method for executing blockchain transactions provided in the foregoing embodiments of the present specification, a plurality of transactions belonging to a first block are obtained, for each parameter read by the plurality of transactions, if the value of the parameter is not stored in the cache region, the value of the parameter is obtained from the status database, and the value of the parameter is stored in the cache region, the plurality of transactions are executed based on the value of each parameter stored in the cache region, and the execution results of the executed partial transactions are identified together before all transactions belonging to the first block are executed. Since the execution result of the completed partial transaction is commonly known when the partial transaction is completed, the execution result can be returned to the client without waiting for the completion of all the transactions belonging to the first block. Thus, the latency incurred by waiting for all transactions belonging to the first block to be performed 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, for each parameter read from the transactions, if the value of the parameter is not stored in the buffer, the value of the parameter is obtained from the status database and stored in the buffer.

In one implementation manner of this embodiment, after determining that the values of the written parameters included in the execution results of the transactions that are successfully identified in all the transactions belonging to the second block are stored in the second buffer area, the following operations are performed: for the parameters read in the multiple transactions of the first block, if the value of the parameter is not stored in the first cache region and the second cache region, the value of the parameter is obtained from the state database, wherein the second block is a previous block of the first block.

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

In one implementation, any node in the blockchain system may obtain multiple transactions belonging to a first block. Before executing the transactions, the parameters read by the transactions may be predetermined, and the values of the parameters read by the transactions may be prefetched and stored in the local cache. After prefetching, the plurality of transactions may be executed based on values of various parameters stored in the local cache.

In another implementation, any node in the blockchain system may obtain all transactions for a plurality of blocks (including a first block) and a respective first set of the all transactions. The first set of any transaction may include an identification of parameters accessed by the transaction. The accessed parameters may include read parameters and write parameters. In one aspect, before executing the total transactions, pre-fetching values of the parameters read by the total transactions based on the respective first sets of the total transactions, and associatively storing the identifications and values of the parameters read by the total transactions in the local cache area. In another aspect, the transactions may be grouped based on their respective first sets to obtain a plurality of 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.

In step 608, the results of the execution of the completed partial transaction are identified.

In step 610, the values of the write parameters included in the execution results of the transactions successfully identified in the partial transactions are stored in a second cache area included in the cache area, with respect to the block to which each transaction 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 execution results of the executed completed partial transactions are identified, it may be determined whether the partial transactions are each executed successfully. For the transaction that is successfully identified in the partial transactions, the value of the parameter written in the transaction that is successfully identified may be obtained based on the execution result corresponding to the transaction that is successfully identified. And storing the value of the parameter written in the transaction which is successfully identified in the second cache region which is included in the cache region relative to the first block to which the transaction which is successfully identified belongs, thereby updating and maintaining the data stored in the cache region.

It should be noted that, for the same steps as in the embodiments of fig. 2 to 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 transaction provided in the foregoing embodiment of the present specification, a plurality of transactions belonging to a first block are obtained, for each parameter read by the plurality of transactions, if the value of the parameter is not stored in the buffer, the value of the parameter is obtained from the status database, and is stored in the buffer, and the plurality of transactions are executed based on the values of the parameters stored in the buffer. And after the execution results of the executed partial transactions are identified, storing the values of the write parameters included in the execution results of the transactions successfully identified in the partial transactions into a second cache region included in the cache region relative to the block to which each transaction successfully identified belongs. In this embodiment, after the partial transactions are successfully identified, the data in the maintenance buffer area is updated in time based on the values of the parameters written in the respective transactions that are successfully identified. Therefore, the problem of update and maintenance lag of transaction data is solved.

Fig. 7 is a flowchart illustrating another method for performing blockchain transaction according to an exemplary embodiment, which may be applied to a node of any blockchain, the method including the following steps:

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

In step 704, for each parameter read from the plurality of transactions, if the value of the parameter is not stored in the buffer, the value of the parameter is obtained from the status database and stored in the buffer.

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

In step 708, the results of the execution of the completed portion of the transaction are identified.

In step 710, the values of the write parameters included in the execution results of the respective successful transactions in the partial transactions are stored in a second cache area included in the cache area, with respect to the block to which the respective successful transactions belong.

In this embodiment, 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 successfully identified in the partial transactions may be stored in the second cache area with respect to the respective blocks to which the transactions successfully identified belong.

In step 712, the data of each transaction that completed the consensus is stored in the tile database as at least a portion of the tile to which it belongs.

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 data such as a transaction body of the transaction and an execution result of the transaction.

In step 714, after all transactions of the first block are performed and the block consensus is completed, in case it is determined that the block consensus on the second block is successful, a block header of the first block is generated based on the hash value of the second block and data of all transactions belonging to the first block, and the block consensus is performed on the first block.

In step 716, if the block identity of the first block is successful, the block header of the first block is stored in the block database.

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

In this embodiment, after completing all transactions in the first block, in case it is determined that the block consensus on the second block is successful, a block header of the first block may be generated based on the hash value of the second block and data of all transactions belonging to the first block, and the block consensus on the first block may be performed. Wherein the second block is a previous block of the first block. 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. If the block identity of the first block is successful, the block header of the first block can be stored in the block database.

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

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 first 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 first block are completed, the transaction of the next block is received, and if any transaction read parameter in the next block is any transaction write parameter in the first block, the value of the transaction write parameter in the first block stored in the buffer may be retained. And deleting the values of the parameters written by the other transactions in the first block stored in the cache region, thereby releasing part of the cache.

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

The method for executing blockchain transactions provided in the above-mentioned embodiment of the present specification obtains a plurality of transactions belonging to a first block, obtains a value of a parameter from a status database for each parameter read by the plurality of transactions, stores the value of the parameter into a buffer if the value of the parameter is not stored in the buffer, executes the plurality of transactions based on the value of each parameter stored in the buffer, identifies the execution results of the executed partial transactions to determine whether the partial transactions are executed successfully, stores the value of a write parameter included in the execution results of the respective transactions identified successfully in the partial transactions into a second buffer included in the buffer corresponding to the block to which the respective transactions identified successfully belong, and stores the data of the respective transactions identified successfully as at least a partial block body to which the respective transactions belong into a blockchain database, 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 second block is successful, a block header of the first block is generated based on the hash value of the second 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 in the block database, and the world state in the state database is updated according to the values of all the parameters stored in the second cache area relative to the first block. 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 directly updated 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 of update lag of transaction data in the database is solved, the blocking speed is improved, and the time delay is further reduced.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As shown in fig. 11, fig. 11 is a node of a blockchain shown in the present specification according to an exemplary embodiment, the node including: an acquisition module 1101, a storage module 1102 and an execution module 1103.

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

The storing module 1102 is configured to, for each parameter read in multiple transactions, obtain a value of the parameter from the status database if the value of the parameter is not stored in the cache region, and store the value of the parameter in the cache region.

An executing module 1103, configured to execute the multiple transactions based on the values of the parameters stored in the cache region.

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

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

Wherein the logging module 1102 is configured for:

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

In other embodiments, the accessed parameters further include written parameters.

Wherein, the node may further include: a grouping module (not shown in the figure).

The grouping module is used for grouping all the transactions based on the identification of each accessed parameter in the respective first set of all the transactions so as to obtain a plurality of transaction groups.

Wherein the executing module 1103 is configured to: 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 based on the values of the respective parameters stored in the buffer.

In other embodiments, the node may further include: 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 all the transactions belonging to the first block are executed.

In other embodiments, the cache region may include a first cache region and a second cache region. The storage submodule stores the value of the parameter into the cache region by the following method: and storing the value of the parameter into the first cache region.

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

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

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 generation module, a block consensus module and a block header storage module (not shown).

And the generating module is used for generating a block header of the first block based on the hash value of the second block and data of all transactions belonging to the first block in the case of determining that the block consensus on the second block is successful after all transactions of the first block are executed and the consensus is completed. Wherein the second block is a previous block of the first block.

The block consensus module is used for performing block consensus on the first block.

And the block head storing module is used for storing the block head of the first block into the block database if the block identification of the first block is successful.

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. 12, fig. 12 is a block diagram illustrating a structure of a node of a blockchain according to an exemplary embodiment, where the node may include: control means 1201, computing means 1202 and storage means 1203.

The control device 1201 is configured to obtain a plurality of transactions belonging to the first block. For each parameter read in multiple transactions, if the value of the parameter is not stored in the buffer, the value of the parameter is obtained from the status database of the storage device 1203, the value of the parameter is stored in the buffer, and the values of the parameters stored in the multiple transactions and the buffer are sent to the computing device 1202.

Computing means 1202 for performing a plurality of transactions based on the values of the respective parameters stored in the cache.

And a storage device 1203 for storing the state database.

As shown in fig. 13, fig. 13 is a block diagram illustrating a control apparatus for a blockchain node according to an exemplary embodiment of the present disclosure, where the control apparatus may include: acquisition section 1301, storage section 1302, and instruction section 1303.

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

The storing unit 1302 is configured to, for each parameter read in multiple transactions, if the value of the parameter is not stored in the cache region, obtain the value of the parameter from the state database of the block chain node, and store the value of the parameter in the cache region.

An indicating unit 1303 is configured to indicate the block link points to execute multiple transactions based on the values of the parameters stored in the buffer.

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

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

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

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

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

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

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

Claims

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

obtaining a plurality of transactions belonging to a first block;

2. The method of claim 1, wherein the method further comprises:

3. The method of claim 2, wherein said obtaining a plurality of transactions belonging to a first block comprises: obtaining all transactions for a plurality of blocks, the plurality of blocks including the first block;

4. The method of claim 3, wherein the accessed parameters further comprise written parameters;

5. The method of claim 1 or 3, wherein prior to performing all transactions belonging to the first block, the method further comprises:

6. The method of claim 5, 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:

7. The method of claim 6, wherein a previous block to the first block is a second block;

8. The method of claim 5, further comprising:

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

performing block consensus on the first block;

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

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:

12. The method of claim 11, wherein the method further comprises:

13. The method of claim 12, wherein the controlling device obtaining a plurality of transactions belonging to a first block comprises: the control device acquires all transactions of a plurality of blocks, wherein the plurality of blocks comprise the first block;

14. The method of claim 13, wherein the accessed parameters further comprise written parameters;

15. The method of claim 11 or 13, wherein prior to the computing device performing all transactions belonging to the first block, the method further comprises:

16. The method of claim 15, 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:

17. The method of claim 16, wherein a previous block to the first block is a second block;

18. The method of claim 15, further comprising:

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

20. The method according to claim 19, further comprising, after the values of the written parameters included in the execution results of the transactions that are successfully recognized among all transactions belonging to the first block are stored in the second buffer area: 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.

21. A block link point, comprising:

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

the storage device is used for storing the state database.

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

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

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