CN113468224A

CN113468224A - Method and device for storing and inquiring state data and executing transaction in block chain

Info

Publication number: CN113468224A
Application number: CN202111033651.7A
Authority: CN
Inventors: 谢桂鲁; 邓福喜
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-09-03
Filing date: 2021-09-03
Publication date: 2021-10-01

Abstract

According to the method, as the block chain can comprise a first state database for storing historical state data, each historical write-in state of each parameter related to each executed block in the block chain and a block identifier corresponding to each historical write-in state can be directly stored in the first state database. Therefore, when the state of the parameter is read or written, the number of IO operations is only one, and meanwhile, the inquiry of the historical state can be realized, so that the local call transaction of the preset type can be supported.

Description

Method and device for storing and inquiring state data and executing transaction in block chain

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for storing and querying status data and performing transactions in a blockchain.

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, the Etherhouse blockchain stores the world state in the form of a tree. Although the query of the history state can be realized, when the state is read or written, a plurality of IO operations are required. The HyperLegendre Fabric blockchain (Fabric blockchain for short) only maintains the latest world state, and the historical state is stored in the block database. Therefore, although the number of IO operations is only one when the latest state is read or written, the inquiry of the history state cannot be realized.

Disclosure of Invention

To solve one of the above technical problems, one or more embodiments of the present disclosure provide a method and apparatus for storing and querying status data in a blockchain and performing a transaction.

According to a first aspect, a method for querying historical status data from a block chain is provided, where the block chain includes a first status database, where the first status database includes at least one write status for each of at least one parameter, and a block identifier corresponding to each write status; the method is performed by a node of the blockchain, the method comprising:

determining a target parameter and a target block;

and querying the target state of the target parameter in the target block from the first state database.

According to a second aspect, there is provided a method of storing state data in a blockchain, the method being performed by a node of the blockchain, the blockchain comprising a first state database, the method comprising:

after completing execution of a first block, obtaining state update data for the first block; the state updating data comprises each parameter written in the first block and a writing state corresponding to each parameter;

and storing the state updating data and the block identifier of the first block into the first state database in an associated manner.

According to a third aspect, there is provided a method of performing a preset type of transaction, performed by a node of the blockchain, the method comprising:

receiving a first transaction, wherein the first transaction is a preset type of transaction; the first transaction is performed based on a target state of a target parameter at a target block; the target block is a history block;

querying the target state using the method of the first aspect;

performing the first transaction based on the target state.

According to a fourth aspect, there is provided an apparatus for querying historical status data from a block chain, the block chain including a first status database, the first status database including at least one write status for each of at least one parameter, and a block identifier corresponding to each write status; the apparatus is performed by a node of the blockchain, the apparatus comprising:

the determining module is used for determining a target parameter and a target block;

and the query module is used for querying the target state of the target parameter in the target block from the first state database.

According to a fifth aspect, there is provided an apparatus for storing state data in a blockchain, the apparatus being performed by a node of the blockchain, the blockchain comprising a first state database, the apparatus comprising:

an obtaining module, configured to obtain status update data for a first block after execution of the first block is completed; the state updating data comprises each parameter written in the first block and a writing state corresponding to each parameter;

and the storing module is used for storing the state updating data and the block identifier of the first block into the first state database in a correlation manner.

According to a sixth aspect, there is provided an apparatus for performing a preset type of transaction, performed by a node of the blockchain, the apparatus comprising:

the receiving module is used for receiving a first transaction, wherein the first transaction is a preset type of transaction; the first transaction is performed based on a target state of a target parameter at a target block; the target block is a history block;

a query module for querying the target state using the apparatus of any one of claims 12-18;

an execution module to execute the first transaction based on the target state.

According to a seventh aspect, there is provided a computer readable storage medium, storing a computer program which, when executed by a processor, implements the method of the first or second or third aspect described above.

According to an eighth aspect, there is provided a computing device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method of the first or second or third aspect when executing the program.

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

in the method and apparatus for storing and querying status data in a blockchain and performing a transaction in the blockchain according to embodiments of the present disclosure, since the blockchain may include a first status database storing historical status data, each historical write status of each parameter involved in a block that has been executed in the blockchain and a block identifier corresponding to each historical write status may be directly stored in the first status database. Since the world state does not need to be stored through the tree structure, the number of IO operations is only one when reading the state of the parameter (reading each layer from the root to the leaf node of the tree requires one disk IO operation). When the state of the parameter is written, the tree root of the tree storing the world state does not need to be calculated, and the number of IO operations is only once. In summary, when the state of the parameter is read or written, the number of IO operations is only one, and meanwhile, the query of the history state can be realized, so that the preset type of local call transaction can be supported.

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

Drawings

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

FIG. 1 is an architecture diagram illustrating a block chain system according to an exemplary embodiment of the present description;

FIG. 2a is a schematic diagram of an initial first state database and an initial second state database shown in accordance with an exemplary embodiment of the present description;

FIG. 2b is a schematic diagram of an updated first state database and second state database shown in accordance with an exemplary embodiment of the present description;

FIG. 2c is a schematic diagram of a first state database and a second state database shown in accordance with an exemplary embodiment of the present description;

FIG. 3 is a flow diagram illustrating a method of storing state data in a blockchain in accordance with an exemplary embodiment of the present description;

FIG. 4 is a flow diagram illustrating a method of querying historical state data from a blockchain in accordance with an exemplary embodiment of the present specification;

FIG. 5 is a block diagram illustrating an apparatus for querying historical state data from a blockchain in accordance with an exemplary embodiment;

FIG. 6 is a block diagram illustrating an apparatus for storing state data in a blockchain in accordance with an exemplary embodiment of the present description;

FIG. 7 is a block diagram illustrating an apparatus for performing a predetermined type of transaction in accordance with one exemplary embodiment of the present description.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which like numerals refer to the same or similar elements throughout the different views unless otherwise specified. 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.

In the existing block chain technology, because the storage mode of the world state is not perfect enough, the two aspects of reducing the number of IO operations and realizing the inquiry of the historical state during reading or writing the state are difficult to be considered. For example, the Etherhouse blockchain stores world states in the form of a tree. Although the query of the history state can be realized, since the state is read or written, one IO operation is required from the tree root of the tree to each layer of the leaf nodes. Therefore, the number of IO operations in reading or writing the state cannot be reduced. The HyperLegendre Fabric blockchain (Fabric blockchain for short) only maintains the latest world state, and the historical state is stored in the block database. Therefore, although the number of IO operations is only one when the latest state is read or written, the inquiry of the history state cannot be realized.

In the solution provided by the embodiment of the present specification, the block chain may include a first status database that stores historical status data, and each historical write status of each parameter involved in a block that has been executed in the block chain and a block identifier corresponding to each historical write status may be directly stored in the first status database in a key-value form. Therefore, when the state of the parameter is read or written, the number of IO operations is only one, and meanwhile, the inquiry of the historical state can be realized, so that more services processed based on the historical state can be supported. Optionally, the first state database may further include version numbers corresponding to the respective writing states, so as to improve efficiency of querying the historical states. Further, the blockchain may further include a second state database storing latest state data, and the current latest state of each parameter involved in a block that has been executed in the blockchain may be directly stored in the second state database in the form of a key value, so as to facilitate querying the latest state data.

As shown in fig. 1, an architecture diagram of a block chain system is shown in accordance with an exemplary embodiment.

In the architecture diagram shown in fig. 1, nodes 1 to 6 are all block link points in a block link system. It is to be understood that fig. 1 is merely illustrative of 6 blockchain nodes, and that virtually any number of blockchain nodes may be included in a blockchain system.

In the blockchain system, at least one blockchain link point can be interfaced with a client and receive a preset type of local call transaction from the interfaced client. The local call transaction is executed based on the historical state of the specified parameter at the specified historical block, the local call transaction need not be consensus, and can be executed only by the block link point that received the local call transaction. The block node may first look up the historical status of the specified parameter in the specified historical block and then perform the local call transaction based on the historical status without chaining the results.

In the embodiment, when the state of the parameter is read or written, the number of IO operations is only one, and meanwhile, the query of the history state can be realized, so that the preset type of local call transaction can be supported.

The scheme of the embodiment of the present specification is schematically described below with reference to a complete application example.

First, a node in the block chain executes a created block (block 0) of the block chain, where the write parameters involved in executing the block 0 include k1 and k2, the write states (the final write state of the execution completion block 0) of k1 and k2 are d11 and d21, respectively, and the set version numbers for d11 and d21 are both v 1. After performing the completion of block 0, the state update data of block 0 may be obtained, which includes the write state d11, version number v1 and block identification b0 for the write parameter k1, and the write state d21, version number v1 and block identification b0 for the write parameter k2 (block height may be used as block identification). As shown in fig. 2a, an initial first state database and an initial second state database may be generated based on the state update data of block 0.

Next, the next block (block 1) of block 0 is executed, where the write parameters involved in executing block 1 include k1 and k3, the write states corresponding to k1 and k3 are d12 and d31, respectively, and the version numbers are set to v2 and v1, respectively, for d12 and d31 (the state of one parameter is written once, and the version number is increased by one). After completing the execution of block 1, the state update data of block 1 may be obtained, the state update data of block 1 including the write state d12, version number v2 and block identification b1 for the write parameter k1, and the write state d31, version number v1 and block identification b1 for the write parameter k 3. As shown in fig. 2b, the first status database and the second status database may be updated based on the status update data of block 1. The state update data of the block 1 may be directly added to the first state database, and the write state data in the second state database is updated by using the latest write state of each write parameter involved in the state update data of the block 1, so that the second state database includes the latest write state corresponding to each parameter. By analogy, after the execution of other blocks is completed, the first state database and the second state database can be updated in the same manner.

When executing to tile 20, node a in the blockchain receives a local call transaction of the type mentioned in the embodiment of fig. 1, which needs to be executed in the state of tile 10 based on parameters k1 and k3, respectively. Node a may query the status of parameters k1 and k3, respectively, at block 10 before performing the local call transaction based on the results of the query. Specifically, the process of querying the states of the parameters k1 and k3 in the block 10 is as follows:

as shown in fig. 2c, the first status database and the second status database store data when block 20 is reached. The latest version numbers corresponding to the parameters k1 and k3, respectively, v9 and v5, may be read from the second status database. And querying the states of the parameters k1 and k3 in the block 10 respectively based on the latest version numbers corresponding to the parameters k1 and k3 respectively.

For parameter k1, first, data for parameter k1 (data in the dashed box in FIG. 2 c) may be obtained from the first state database. Then, based on the latest version number v9 corresponding to the parameter k1, the state of the parameter k1 in the block 10 is searched from the data of the parameter k1 by using a binary search algorithm, so that data traversal can be avoided, and the query efficiency is improved. For example, since the latest version number corresponding to the parameter k1 is v9 (i.e., the 9 th update), and the median value of the version numbers between v1 and v9 is v5, it can be first queried that the block corresponding to the parameter k1 with the version number v5 is b6, that is, the block is block 6, and precedes block 10. The median v7 between v5-v9 can be selected again, and the block identifier corresponding to the version number of the query parameter k1 is v7 can be selected. And so on until the parameter k1 is found to be v8 at the version number of the block 10 and the state is d 18.

For the parameter k3, the data of the parameter k3 may be obtained from the first state database, and then, based on the latest version number v5 corresponding to the parameter k3, the state of the parameter k3 in the block 10 is searched from the data of the parameter k3 by using a binary search algorithm. Since the identifier b10 of the block 10 is not found from the data of the parameter k3, but the block identifier b6 corresponding to the parameter k3 with the version number v3 and the block identifier b12 corresponding to the parameter k 4 are found, it can be seen that after the write update is performed on the parameter k3 at the block 6, the next write update on the parameter k3 is performed at the block 12. Therefore, the state of the parameter k3 in the block 10 is consistent with the writing state of the parameter k3 in the block 6, and the writing state d33 of the parameter k3 in the block 6 can be obtained as the state of the parameter k3 in the block 10.

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

As shown in fig. 3, fig. 3 is a flow chart illustrating a method of storing state data in a blockchain, which may be applied in a node of the blockchain, according to an example embodiment. The nodes of the blockchain may be implemented as any device, platform, server, or cluster of devices having computing, processing capabilities. The method comprises the following steps:

in step 302, after the execution of the first block is completed, state update data for the first block is obtained.

In this embodiment, the first block is any one of the blocks of the block chain, and the status update data for the first block includes respective parameters written in the first block and respective writing statuses corresponding to the respective parameters written in the first block. It should be noted that, if a parameter is updated in the first block multiple times, the last updated corresponding state is used as the writing state of the parameter in the first block. For example, the transaction involving write parameter k in the first block includes transaction a and transaction b, and transaction a is performed before transaction b. Then the write status of parameter k after transaction b is completed will be performed as the write status of parameter k in the first block.

Optionally, the status update data for the first block may further include a version number corresponding to a writing status of each parameter written in the first block, so as to facilitate subsequent data query. The version number corresponding to the write status of any parameter may indicate the number of writes to that parameter in the blockchain. It should be noted that if a parameter is written one or more times during the execution of a block, the last written value for the parameter is written to the first status database or the second status database only after the transaction in the block is completed, so that any written parameter involved in a block, regardless of the number of updates in the block, is written only once in the block chain. For example, the parameter k for writing in block 1 is written once in the block chain if it is updated once in block 1, and is also written once in the block chain if it is updated three times in block 1.

In step 304, the status update data and the block id of the first block are stored in a first status database in association.

In this embodiment, the blockchain includes a first status database that may be used to store historical status data for various parameters that are written. The status update data and the block identifier of the first block may be stored in the first status database in association. The identifier capable of representing the block height of the first block may be used as the block identifier of the first block, and it should be understood that the specific form of the block identifier is not limited in this embodiment.

Optionally, in step 306, the writing status of each parameter in the second status database is updated by using the status update data, so that the second status database includes the latest status of each parameter.

In this embodiment, the blockchain may further include a second status database, and the second status database may be configured to store the latest status data of each written parameter, so as to search the latest status data of the parameter when performing a transaction. The status update data may be used to update the write status of each parameter in the second status database such that the second status database includes the most recent status of each parameter.

In the method for storing status data in a block chain provided in the foregoing embodiments of the present specification, after the block is executed, each parameter written in the first block and a write status corresponding to each parameter are acquired as status update data for the block, and the status update data and a block identifier of the block are stored in a first status database in an associated manner, so that the first status database stores historical status data of each parameter written in the first status database. Since the world state does not need to be stored through the tree structure, the number of IO operations is only one when reading the state of the parameter (reading each layer from the root to the leaf node of the tree requires one disk IO operation). When the state of the parameter is written, the tree root of the tree storing the world state does not need to be calculated, and the number of IO operations is only once. Therefore, when the parameter state is read or written, the number of IO operations is only one, and meanwhile, the historical state can be inquired.

Fig. 4 is a flow chart illustrating a method for querying historical status data from a blockchain, which may be applied to nodes of the blockchain, according to an example embodiment, as shown in fig. 4. The nodes of the blockchain may be implemented as any device, platform, server, or cluster of devices having computing, processing capabilities. The method comprises the following steps:

in step 402, target parameters and target tiles are determined.

In this embodiment, the target parameter is a parameter to be queried, and the target block is a history block that has been completed. The target parameters and target tiles may be determined based on information carried by the query request or query transaction.

In step 404, the target state of the target parameter in the target block is queried from the first state database.

In this embodiment, the block chain may include a first status database, where the first status database includes at least one writing status of each parameter of the at least one parameter, and a block identifier corresponding to each writing status. Optionally, the first status database may further include version numbers corresponding to the respective writing statuses. The first state database may be created and updated in the manner of storing data provided by the embodiment of fig. 3.

In one implementation, the target state of the target parameter in the target block may be queried from the first state database in a traversal manner. In another implementation, querying the first status database for the target status of the target parameter at the target block may include: substep 412, obtaining target data from the first state database; substep 414, performing a query operation on the target data; in substep 416, if the target block identifier of the target block is found from the target data, obtaining a write-in status corresponding to the target block identifier from the target data as a target status; and if the target block identifier of the target block is not found in the target data, determining the reference identifier, and obtaining a write-in state corresponding to the reference identifier from the target data as the target state.

First, in sub-step 412, target data related to the target parameter may be obtained from the first status database, where the target data includes at least one first writing status of the target parameter and a block identifier corresponding to each first writing status. Optionally, the target data may further include version numbers corresponding to the first writing states.

Next, in sub-step 414, a query operation is performed on the target data. In one implementation, if the data size of the target data is small, the query operation may be directly performed on the target data in a traversal manner. In another implementation, if the data size of the target data is large, the latest version number corresponding to the target parameter may also be obtained, and the target block identifier may be queried from the target data based on the latest version number corresponding to the target parameter.

Specifically, the latest version number corresponding to the target parameter may be obtained as follows: the latest version number corresponding to the target parameter may be obtained from the first status database. Optionally, the block chain may further include a second status database, where the second status database includes a latest writing status corresponding to each parameter. Therefore, the latest version number corresponding to the target parameter can be obtained from the second state database.

The target block identifier may be queried from the target data based on the latest version number corresponding to the target parameter, where the query result includes the target block identifier of the target block found from the target data and the target block identifier of the target block not found from the target data: for example, the target block identification may be queried from the target data using a binary search algorithm based directly on the latest version number. For another example, a first block and a second block may also be determined, where the block identification of the first block corresponds to the first version number in the target data and the block identification of the second block corresponds to the latest version number in the target data. If the target block is a first block (i.e., the block identifier of the first block is the same as the block identifier of the target block), or the target block is a second block (i.e., the block identifier of the second block is the same as the block identifier of the target block), it may be determined that the query result is the target block identifier of the target block found from the target data. If the first block is behind the target block or the second block is in front of the target block, it may be determined that the target block id of the target block is not found in the target data. If the first block is before the target block and the second block is after the target block, the target block identifier needs to be queried from the target data by utilizing a binary search algorithm so as to further determine a query result.

Finally, in sub-step 416, if the target block id of the target block is found from the target data, the write status corresponding to the target block id is obtained from the target data as the target status.

Alternatively, in sub-step 418, if the target block identifier of the target block is not found from the target data, the reference identifier is determined, and the write status corresponding to the reference identifier is obtained from the target data as the target status. The reference mark indicates that the corresponding block is a block which is located before the target block and is closest to the target block, among the plurality of blocks recorded in the first state database for modifying the target parameter, that is, a block which is the last block before the target block for modifying the target parameter. For example, the plurality of chunk identifications of the target data record include b1, b2, b5, b6 and b9, which correspond to chunk 1, chunk 2, chunk 5, chunk 6 and chunk 9, respectively. If the target block is block 8, the block located before and closest to the target block among the blocks corresponding to the block identifiers of the target data record is block 6, so reference is made to block identifier b6 identified as block 6. It should be noted that, if there is no block for modifying the target parameter in the first status database, or none of the blocks for modifying the target parameter in the first status database is in front of the target block, the query result is empty, and a message "target status does not exist" may be returned.

The above embodiments of the present specification provide a method for querying historical status data from a block chain, which queries a target status of a target parameter in a target block from a first status database by determining the target parameter and the target block. Since the block chain may include a first status database storing historical status data, the historical write statuses of the parameters involved in the executed blocks in the block chain and the block identifiers corresponding to the historical write statuses may be directly stored in the first status database. Therefore, when reading or writing the state of the parameter, the number of IO operations is only one, and meanwhile, the query of the history state can be realized.

It should be noted that although in the above embodiments, the operations of the methods of the embodiments of the present specification have been 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.

In accordance with the foregoing embodiments of the method for storing and querying status data and performing transactions in a blockchain, the present disclosure also provides embodiments of an apparatus for storing and querying status data and performing transactions in a blockchain.

As shown in fig. 5, fig. 5 is a block diagram of an apparatus for querying historical status data from a blockchain according to an exemplary embodiment, where the blockchain includes a first status database, where the first status database includes at least one write status for each of at least one parameter, and a block identifier corresponding to each write status; the apparatus is deployed at a node of a blockchain, and may include: a determination module 501 and a query module 502.

The determining module 501 is configured to determine a target parameter and a target block.

The query module 502 is configured to query the first status database for the target status of the target parameter in the target block.

In some embodiments, query module 502 includes: an execution submodule and a first fetch submodule (not shown in the figure).

The execution submodule is used for searching the target block identifier of the target block from the target data corresponding to the target parameter in the first state database.

And the first obtaining sub-module is used for obtaining a writing state corresponding to the target block identifier from the target data as a target state when the target block identifier is found from the target data.

In other embodiments, query module 502 further comprises: a determination submodule and a second acquisition submodule (not shown in the figure).

And the second obtaining submodule is used for obtaining the target state based on the writing state corresponding to the block which is searched from the target data and modifies the target parameter before the target block when the target block identifier is not searched from the target data.

In other embodiments, the first state database further includes a version number corresponding to each of the write states.

Wherein the execution submodule is configured to: and acquiring the latest version number corresponding to the target parameter, and inquiring the target block identifier from the target data based on the latest version number.

In some embodiments, the blockchain further includes a second status database, where the second status database includes latest version numbers corresponding to the respective parameters.

The execution submodule acquires the latest version number corresponding to the target parameter in the following mode: and acquiring the latest version number corresponding to the target parameter from the second state database.

In other embodiments, the execution submodule queries the target block identifier from the target data based on the latest version number by: and querying the target block identification from the target data by utilizing a binary search algorithm based on the latest version number.

In other embodiments, the execution submodule queries the target block identifier from the target data based on the latest version number by: determining a first block and a second block; the block identification of the first block corresponds to a first version number in the target data; the block identification of the second block corresponds to the latest version number in the target data. If the first block is before the target block and the second block is after the target block, the target block identifier is queried from the target data by using a binary search algorithm.

It should be understood that the above-mentioned apparatus may be preset in a node of the blockchain, and may also be loaded into a node of the blockchain by downloading or the like. The corresponding modules in the above-mentioned device can cooperate with the modules in the nodes of the blockchain to realize the scheme of inquiring the historical state data from the blockchain.

As shown in fig. 6, fig. 6 is a block diagram of an apparatus for storing state data in a blockchain according to an exemplary embodiment, the apparatus being deployed at a node of the blockchain, the blockchain including a first state database, and the apparatus may include: an acquisition module 601 and a logging module 602.

The obtaining module 601 is configured to obtain, after the execution of the first block is completed, status update data for the first block, where the status update data includes each parameter written in the first block and a writing status corresponding to each parameter.

A storing module 602, configured to store the status update data and the block identifier of the first block into a first status database in an associated manner.

In some embodiments, the status update data further includes a version number of a write status corresponding to each of the parameters written in the first block.

In other embodiments, the blockchain further includes a second state database.

The apparatus may further include: and an updating module (not shown) for updating the writing status of each parameter written in the first block in the second status database by using the status updating data, so that the second status database includes the latest status of each parameter.

It should be understood that the above-mentioned apparatus may be preset in a node of the blockchain, and may also be loaded into a node of the blockchain by downloading or the like. The corresponding modules in the above-described apparatus may cooperate with modules in nodes of the blockchain to implement a scheme for storing state data in the blockchain.

As shown in fig. 7, fig. 7 is a block diagram of an apparatus for performing a predetermined type of transaction, the apparatus being deployed at a node of a blockchain according to an exemplary embodiment of the present disclosure, and the apparatus may include: a receiving module 701, a querying module 702 and an executing module 703.

The receiving module 701 is configured to receive a first transaction, where the first transaction is a preset type of transaction, the first transaction is executed based on a target state of a target block according to a target parameter, and the target block is a history block.

A query module 702 for querying the target status using the apparatus in fig. 5.

An executing module 703 is configured to execute the first transaction based on the target state.

It should be understood that the above-mentioned apparatus may be preset in a node of the blockchain, and may also be loaded into a node of the blockchain by downloading or the like. Corresponding modules in the above-described apparatus may cooperate with modules in nodes of the blockchain to implement a scheme for performing a predetermined type of transaction.

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 storing and querying status data in a blockchain and executing a transaction provided in any one of the embodiments of fig. 1 to 4.

One or more embodiments of the present specification further provide a computing device, including a memory and a processor, where the memory stores executable code, and the processor executes the executable code to implement the method for storing and querying status data and performing transactions in a blockchain as provided in any one of the embodiments of fig. 1 to 4.

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 method for inquiring historical state data from a block chain, wherein the block chain comprises a first state database, the first state database comprises at least one writing state of each parameter in at least one parameter and a block identifier corresponding to each writing state; the method is performed by a node of the blockchain, the method comprising:

determining a target parameter and a target block;

2. The method of claim 1, wherein said querying the target status of the target parameter at the target block from the first status database comprises:

searching a target block identifier of the target block from target data corresponding to the target parameter in the first state database;

and if the target block identification is found from the target data, acquiring a writing state corresponding to the target block identification in the target data as the target state.

3. The method of claim 2, wherein said querying the target status of the target parameter at the target block from the first status database further comprises:

and if the target block identifier is not found in the target data, acquiring the target state based on the write-in state corresponding to the block which is found in the target data and modifies the target parameter before the target block.

4. The method of claim 2, wherein the first state database further comprises a version number corresponding to each of the respective write states;

wherein the searching for the target block identifier of the target block from the target data corresponding to the target parameter in the first status database includes:

acquiring the latest version number corresponding to the target parameter;

and querying the target block identification from the target data based on the latest version number.

5. The method of claim 4, wherein the block chain further comprises a second status database, the second status database comprising a latest version number corresponding to each of the respective parameters;

wherein the obtaining of the latest version number corresponding to the target parameter includes:

and acquiring the latest version number corresponding to the target parameter from the second state database.

6. The method of claim 4, wherein said querying the target block identity from the target data based on the latest version number comprises:

and querying the target block identification from the target data by utilizing a binary search algorithm based on the latest version number.

7. The method of claim 4, wherein said querying the target block identity from the target data based on the latest version number comprises:

determining a first block and a second block; the block identification of the first block corresponds to a first version number in the target data; the block identification of the second block corresponds to the latest version number in the target data;

and if the first block is before the target block and the second block is after the target block, querying the target block identification from the target data by utilizing a binary search algorithm.

8. A method of storing state data in a blockchain, the method being performed by a node of the blockchain, the blockchain including a first state database, the method comprising:

9. The method of claim 8, wherein the status update data further comprises a version number of the write status corresponding to each of the parameters.

10. The method of claim 8, wherein the blockchain further comprises a second state database;

wherein the method further comprises: and updating the writing state of each parameter in the second state database by using the state updating data, so that the second state database comprises the latest state of each parameter.

11. A method of performing a preset type of transaction, performed by a node of the blockchain, the method comprising:

querying the target state using the method of any of claims 1-7;

performing the first transaction based on the target state.

12. A device for inquiring historical state data from a block chain, wherein the block chain comprises a first state database, the first state database comprises at least one writing state of each parameter in at least one parameter and a block identifier corresponding to each writing state; the apparatus is deployed at a node of the blockchain, and the apparatus comprises:

13. The apparatus of claim 12, wherein the query module comprises:

the execution submodule is used for searching a target block identifier of the target block from target data corresponding to the target parameter in the first state database;

and the first obtaining sub-module is used for obtaining a writing state corresponding to the target block identifier from the target data as the target state when the target block identifier is found from the target data.

14. The apparatus of claim 13, wherein the query module further comprises:

and a second obtaining sub-module, configured to, when the target block identifier is not found in the target data, obtain the target state based on a write state corresponding to a block that is found in the target data and that modifies the target parameter before the target block.

15. The apparatus of claim 13, wherein the first state database further comprises respective corresponding version numbers of the respective write states; wherein the execution submodule is configured to:

acquiring the latest version number corresponding to the target parameter;

16. The apparatus of claim 15, wherein the block chain further comprises a second status database, the second status database comprising a latest version number corresponding to each of the respective parameters;

the execution submodule acquires the latest version number corresponding to the target parameter in the following manner:

17. The apparatus of claim 15, wherein the execution submodule queries the target block identity from the target data based on the latest version number by:

18. The apparatus of claim 15, wherein the execution submodule queries the target block identity from the target data based on the latest version number by:

19. An apparatus for storing state data in a blockchain, the apparatus being deployed at a node of the blockchain, the blockchain including a first state database, the apparatus comprising:

20. The apparatus of claim 19, wherein the status update data further comprises a version number of a write status corresponding to each of the respective parameters.

21. The apparatus of claim 19, wherein the blockchain further comprises a second state database;

wherein the apparatus further comprises:

and the updating module is used for updating the writing state of each parameter in the second state database by using the state updating data, so that the second state database comprises the latest state of each parameter.

22. An apparatus for performing a predetermined type of transaction, deployed at a node of the blockchain, the apparatus comprising:

an execution module to execute the first transaction based on the target state.

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

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