Blockchain-based data management method, apparatus, and blockchain node

Abstract

A kind of data management method, device and blockchain node based on blockchain, involve blockchain system and computing node, smart contract is deployed in the blockchain system, contract state of smart contract includes the disaster recovery information of target data, disaster recovery information includes the data identifier of target data, first hash and backup data.The computing node calculates the second hash of the data corresponding to data identifier that it holds, and sends the first transaction containing data identifier and second hash to blockchain system;Blockchain system obtains the first query result that can indicate whether first hash and second hash are the same according to the first transaction inquires disaster recovery information;When first hash and second hash are different, computing node sends the second transaction containing data identifier to blockchain system;Blockchain system obtains the second query result containing disaster recovery data according to the second transaction inquires disaster recovery information;Computing node can then obtain target data according to backup data in the second query result.

Description

TECHNICAL FIELD

[0001] The embodiment of the present specification belongs to the field of blockchains, and particularly relates to a data management method and device based on a blockchain and a blockchain node. BACKGROUND

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism and encryption algorithm. In a blockchain system, data blocks are combined into a chain-type data structure in a sequential manner according to time sequence, and the distributed ledger is ensured to be non-tamperable and non-forgable by means of cryptography. Due to the characteristics of decentralization, information non-tamperability and autonomy, blockchain has attracted more and more attention and application. SUMMARY

[0003] The purpose of the present application is to provide a data management method and device based on a blockchain and a blockchain node.

[0004] In a first aspect, a data management method based on a blockchain is provided, which relates to a blockchain system and a computing node, the blockchain system has a smart contract deployed therein, the contract state of the smart contract includes disaster recovery information of target data, and the disaster recovery information includes a data identifier, a first hash and disaster recovery data of the target data. The method comprises: the computing node calculates a second hash of the data corresponding to the data identifier held by the computing node, and sends a first transaction to the blockchain system, wherein the first transaction includes the data identifier and the second hash; the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the first transaction, and obtains a first query result indicating whether the first hash and the second hash are the same; the computing node receives the first query result from the blockchain system, and in the case where the first query result indicates that the first hash and the second hash are different, sends a second transaction to the blockchain system, wherein the second transaction includes the data identifier; the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the second transaction, and obtains a second query result including the disaster recovery data; and the computing node receives the second query result from the blockchain system, and acquires the target data according to the disaster recovery data.

[0005] In a second aspect, a blockchain-based data management method is provided, involving a blockchain system and a computing node, the blockchain system having a smart contract deployed therein, a disaster recovery information of target data being included in a contract state of the smart contract, the disaster recovery information including a data identifier of the target data, a first hash and disaster recovery data, the method being performed by the computing node, and the method comprising: calculating a second hash of data corresponding to the data identifier and held by the computing node, and sending a first transaction to the blockchain system, the first transaction including the data identifier and the second hash, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the first transaction, and obtains a first query result indicating whether the first hash and the second hash are the same; receiving the first query result from the blockchain system, and in a case where the first query result indicates that the first hash and the second hash are different, sending a second transaction to the blockchain system, the second transaction including the data identifier, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the second transaction, and obtains a second query result including the disaster recovery data; and receiving the second query result from the blockchain system, and obtaining the target data according to the disaster recovery data.

[0006] In a third aspect, a blockchain-based data management method is provided, involving a blockchain system and a computing node, the blockchain system having a smart contract deployed therein, a disaster recovery information of target data being included in a contract state of the smart contract, the disaster recovery information including a data identifier of the target data, a first hash and disaster recovery data, the method being performed by a blockchain node in the blockchain system, and the method comprising: receiving a first transaction from the computing node, the first transaction including the data identifier and a second hash of data corresponding to the data identifier and held by the computing node; querying the disaster recovery information in the contract state of the smart contract according to the first transaction, obtaining a first query result indicating whether the first hash and the second hash are the same, and sending the first query result to the computing node; receiving a second transaction from the computing node, the second transaction being sent by the computing node in a case where the first query result indicates that the first hash and the second hash are different, the second transaction including the data identifier; querying the disaster recovery information in the contract state of the smart contract according to the second transaction, obtaining a second query result including the disaster recovery data, and sending the second query result to the computing node, so that the computing node obtains the target data according to the disaster recovery data.

[0007] In a fourth aspect, a blockchain-based data management apparatus is provided, which involves a blockchain system and a computing node, the blockchain system has a smart contract deployed therein, and disaster recovery information of target data is included in a contract state of the smart contract, the disaster recovery information includes a data identifier of the target data, a first hash, and disaster recovery data, the apparatus is deployed in the computing node, and the apparatus includes: a hash calculation unit, configured to calculate a second hash of data held by the apparatus and corresponding to the data identifier; a transaction sending unit, configured to send a first transaction to the blockchain system, the first transaction includes the data identifier and the second hash, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the first transaction, and obtains a first query result indicating whether the first hash and the second hash are the same; a result processing unit, configured to receive the first query result from the blockchain system, and trigger the transaction sending unit if the first query result indicates that the first hash and the second hash are different; the transaction sending unit is further configured to send a second transaction to the blockchain system under the triggering of the result processing unit, the second transaction includes the data identifier, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the second transaction, and obtains a second query result including the disaster recovery data; and the result processing unit is further configured to receive the second query result from the blockchain system, and obtain the target data according to the disaster recovery data.

[0008] In a fifth aspect, a blockchain node in a blockchain system is provided, the blockchain system has a smart contract deployed therein, and disaster recovery information of target data is included in a contract state of the smart contract, the disaster recovery information includes a data identifier of the target data, a first hash, and disaster recovery data, and the blockchain node includes: a transaction receiving unit, configured to receive a first transaction from a computing node, the first transaction includes the data identifier and a second hash of data held by the computing node and corresponding to the data identifier; a transaction processing unit, configured to query the disaster recovery information in the contract state of the smart contract according to the first transaction, and obtain a first query result indicating whether the first hash and the second hash are the same; a result returning unit, configured to send the first query result to the computing node; the transaction receiving unit is further configured to receive a second transaction from the computing node, the second transaction is sent by the computing node if the first query result indicates that the first hash and the second hash are different, and the second transaction includes the data identifier; the transaction processing unit is further configured to query the disaster recovery information in the contract state of the smart contract according to the second transaction, and obtain a second query result including the disaster recovery data; and the result returning unit is further configured to send the second query result to the computing node, so that the computing node obtains the target data according to the disaster recovery data.

[0009] In a sixth aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores computer programs / instructions, and the processor executes the computer programs / instructions to implement the method in the second or third aspect.

[0010] In a seventh aspect, a computer readable storage medium is provided, which stores computer programs / instructions, and when the computer programs / instructions are executed in a computing device, the computing device executes the method in the second or third aspect.

[0011] In the scheme of the embodiments of the present specification, a smart contract is deployed in a blockchain system, wherein the contract state of the smart contract includes disaster recovery information of target data, and the disaster recovery information includes a data identifier corresponding to the target data, a first hash, and disaster recovery data; a computing node can calculate a second hash of data held by the computing node and corresponding to the data identifier of the target data, and send a first transaction including the data identifier and the second hash to the blockchain system; the blockchain system can query the disaster recovery information of the target data in the contract state of the smart contract according to the first transaction, and obtain a first query result that can be used to indicate whether the first hash and the second hash are the same; after obtaining the first query result from the blockchain system, if the first query result indicates that the first hash and the second hash are different, it means that the data corresponding to the data identifier stored by the computing node is not the target data, in other words, it means that the target data stored by the computing node has an error; therefore, the computing node can send a second transaction including the data identifier to the blockchain system in the case that the first query result indicates that the first hash and the second hash are different, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the second transaction, and returns a second query result including the disaster recovery data to the computing node; further, the computing node can recover the correct target data according to the disaster recovery data. In this way, the computing node can effectively find out whether the target data held by the computing node has an error, and recover the target data in the case that the target data held by the computing node has an error. BRIEF DESCRIPTION OF DRAWINGS

[0012] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained according to these drawings without creative labor.

[0013] Figure 1 The system framework diagram of the technical solutions provided in the embodiments of the present specification is shown in the following figure:

[0014] Figure 2This is a flowchart illustrating a blockchain-based data management method provided in the embodiments of this specification;

[0015] Figure 3 This is a schematic diagram of the structure of a blockchain-based data management device provided in the embodiments of this specification;

[0016] Figure 4 This is a schematic diagram of the structure of a blockchain node in a blockchain system provided in the embodiments of this specification. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0018] A blockchain system is a distributed network built from multiple nodes. Any two nodes within it communicate at the application layer through a peer-to-peer (P2P) network. See also... Figure 1 As shown, a blockchain system can, for example, contain nodes 1 to 4. Any two nodes from 1 to 4 can communicate at the application layer via a P2P network. The blockchain system utilizes a decentralized (or multi-centralized) distributed ledger constructed using a chain-like block structure, stored on each (or most) node in the distributed blockchain network. Therefore, the blockchain system needs to address the consistency and correctness of the ledger data across multiple decentralized (or multi-centralized) nodes. Each node in the blockchain system runs a blockchain program. Under certain fault-tolerance requirements, a consensus mechanism ensures that all loyal nodes have the same transactions, thereby guaranteeing consistent execution results for the same transactions. Multiple transactions arranged in sequence are packaged into a block, and the world state is updated based on the execution results of these transactions.

[0019] A transaction in a blockchain system refers to a task unit executed and recorded within the blockchain system. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract in the blockchain system, the From field represents the account address initiating the transaction, the To field represents the account address of the contract called by the transaction, and the Data field includes the function name in the called contract and the parameters passed to that function, which is used to retrieve and execute the function's code from the blockchain system during transaction execution.

[0020] Transactions can originate from computing nodes connected to the blockchain system, or they can be initiated by blockchain nodes within the blockchain system.

[0021] Smart contracts in a blockchain system are contracts that can be triggered and executed by transactions. Smart contracts can be defined in the form of code. For example, calling a smart contract in a consortium blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the consortium blockchain network to run the smart contract code in a distributed manner. It's important to note that besides users creating smart contracts, the system can also set smart contracts in the genesis block. These contracts are generally called genesis contracts. Typically, genesis contracts can set some data structures, parameters, attributes, and methods of the blockchain system. Furthermore, accounts with system administrator privileges can create or modify system-level contracts (referred to as system contracts).

[0022] In smart contract deployment scenarios, a transaction containing smart contract creation information (i.e., a transaction used to create a smart contract) can be sent to the blockchain system. The `from` field of this transaction is the account address of the transaction initiator, the `data` field includes the code of the smart contract to be created (such as bytecode or machine code), and the `to` field is empty to indicate that the transaction is used to deploy the contract. After nodes reach a consensus through the consensus mechanism, the contract address is determined, a contract account corresponding to the smart contract's contract address is added to the state database, state storage corresponding to the contract account is allocated, and the contract code is stored in the smart contract's state storage.

[0023] In scenarios involving contract invocation, a transaction for invoking a smart contract can be sent to the blockchain system. The `from` field of this transaction is the account address of the transaction initiator, the `to` field is the contract address of the smart contract being invoked, and the `data` field includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction within the blockchain system, each node can execute the transaction, thereby executing the smart contract and updating the corresponding state database based on the execution of the smart contract.

[0024] It's important to note that contract accounts typically also possess some state. These states are defined by state variables within the smart contract and acquire new values ​​during the smart contract's creation and execution. Contract accounts can be used to store the contract states related to the smart contract. Once an event triggers a clause in the smart contract (meeting the execution conditions), the code can be executed automatically. In a blockchain system, the contract state of a smart contract is stored in a storage trie. The hash value of the root node of this storage trie is stored in `storage_root`, thus locking all contract states of that contract under that contract account through hashing. The storage trie is an MPT tree structure that stores a key-value mapping from state addresses to state values. From the root node to the leaf node, each node stores the address of a state variable, and each leaf node stores the value of a state variable.

[0025] This specification provides at least one blockchain-based data management method, apparatus, and blockchain node in its embodiments. A smart contract is deployed in the blockchain system, wherein the contract state of the smart contract includes disaster recovery information for target data. This disaster recovery information includes a data identifier corresponding to the target data, a first hash, and disaster recovery data. A computing node can calculate a second hash of the data it holds that corresponds to the data identifier of the target data, and send a first transaction containing the data identifier and the second hash to the blockchain system. The blockchain system can query the disaster recovery information of the target data in the contract state of the smart contract based on the first transaction, obtaining a first query result that can be used to indicate whether the first hash and the second hash are the same. After obtaining the first query result from the blockchain system, if the first query result indicates that the first hash and the second hash are different, it means that the data it stores corresponding to the data identifier is not the target data; in other words, it means that the target data it stores has been corrupted. Therefore, if the first query result indicates that the first hash and the second hash are different, the computing node can send a second transaction containing the data identifier to the blockchain system, causing the blockchain system to query the disaster recovery information in the contract state of the smart contract based on the second transaction, obtain and return a second query result containing disaster recovery data to the computing node. Furthermore, the computing node can restore the correct target data based on the disaster recovery data. In this way, computing nodes can effectively detect whether the target data they hold has been corrupted, and restore the target data if they find that the target data they hold has been corrupted.

[0026] Figure 2 This is a flowchart illustrating a blockchain-based data management method provided in the embodiments of this specification. The method involves a blockchain system and computing nodes, wherein a smart contract C1 is deployed within the blockchain system.

[0027] See Figure 2 As shown, the method may include, but is not limited to, some or all of the following steps S201 to S215.

[0028] In step S201, the computing node sends a third transaction to the blockchain system, which includes disaster recovery information for the target data. The disaster recovery information includes at least the data identifier T, the first hash H1, and the disaster recovery data for the target data.

[0029] When it is necessary to ensure the correctness of the target data held by the compute node, the compute node can obtain the disaster recovery information of the target data through user operations. The first hash H1 refers to the original hash of the target data that has not experienced errors. Disaster recovery data is used to support the compute node in correctly recovering the target data; for example, when the amount of target data is relatively small, the target data itself can be used as disaster recovery data; or, when the amount of target data is relatively large, the target data can be split into multiple data fragments that can be used to recover the target data, for example, split into multiple data fragments using erasure coding algorithms, and then distributed storage of these multiple data fragments is performed by the compute node and / or several other compute nodes, and the storage paths of these multiple data fragments are used as the disaster recovery data of the target data.

[0030] Disaster recovery information can also include the location information of the target data. For example, if the target data is a piece of data stored in a database table, then the location information of the target data may include the database identifier and the table identifier; or if the target data is a value cached in a compute node according to a key-value pair, then the location information of the target data may be its corresponding key; or if the target data is dedicated data belonging to a specific application, then the location information of the target data may be the identifier of the interface program in that application that is publicly exposed for passing the target data to the target data.

[0031] Disaster recovery information can also include its corresponding generation time.

[0032] The third transaction is used to invoke smart contract C1 deployed in the blockchain system. For example, the To field of the third transaction may include the contract address of smart contract C1 in the blockchain system, and the Data field of the third transaction may include disaster recovery information of the target data. Optionally, it may also include the function identifier of the first function F1 called in smart contract C1.

[0033] In step S203, the blockchain system stores disaster recovery information in the contract state of smart contract C1 based on the third transaction.

[0034] The blockchain system can execute smart contract C1 based on a third transaction. For example, it can execute the first function F1 based on the function identifier of the first function F1 included in the Data field of the third transaction, thereby storing the disaster recovery information in the contract state of smart contract C1.

[0035] The aforementioned steps S201 and S203 are optional; for example, step S201 can be executed by other computing nodes.

[0036] The target data held by the compute node may be erroneous; for example, the target data may be maliciously modified by an intruder, or the compute node itself may experience software or hardware errors that cause the target data it holds to become erroneous. In other words, the data currently held by the compute node corresponding to data identifier T may be erroneous target data instead of the correct target data.

[0037] To facilitate timely detection by computing nodes of whether errors have occurred in the target data they hold, computing nodes can periodically execute the following steps S2051 and S2053 at predetermined time intervals; or, to minimize resource waste by computing nodes, computing nodes can execute the following steps S2051 and S2053 only when they need to use the target data.

[0038] Step S2051: The computing node calculates the second hash H2 of the data it holds corresponding to the data identifier T1.

[0039] The data corresponding to data identifier T1 refers to the target data held by the computing node at the current moment. As mentioned earlier, the target data held by the computing node at the current moment may have been corrupted, and the computing node has not yet been aware of this error.

[0040] In step S2053, the computing node sends the first transaction to the blockchain system, which includes the data identifier T and the second hash H2 of the target data.

[0041] The first transaction is used to invoke smart contract C1 deployed in the blockchain system. For example, the To field of the first transaction may include the contract address of smart contract C1 in the blockchain system, and the Data field of the first transaction may include the data identifier T and the second hash H2. Optionally, it may also include the function identifier of the second function F2 called in smart contract C1.

[0042] In step S207, the blockchain system queries the disaster recovery information of the target data in the contract state of smart contract C1 according to the first transaction, and obtains the first query result, which indicates whether the first hash H1 and the second hash H2 are the same.

[0043] The blockchain system can execute smart contract C1 based on the first transaction. For example, it can execute the second function F2 based on the function identifier of the second function F2 included in the Data field of the first transaction. This achieves the following: based on the data identifier T of the target data included in the Data field of the first transaction, the disaster recovery information of the target data is queried in the contract state of the smart contract. The first hash H1 and the second hash H2 contained in the disaster recovery information of the target data are compared for equality. Based on the result of the equality comparison, a first query result is generated to indicate whether the first hash H1 and the second hash H2 are the same.

[0044] In one possible implementation, the first query result may also include the time when the disaster recovery information was generated.

[0045] Step S2091: The computing node receives the first query result from the blockchain system.

[0046] In step S2093, if the first query result indicates that the first hash H1 and the second hash H2 are different, the computing node sends a second transaction to the blockchain system, which includes the data identifier T.

[0047] If the first query result indicates that the first hash H1 and the second hash H2 are different, it means that the data held by the computing node corresponding to the data identifier T1 is not the target data; in other words, the target data it holds has been corrupted. When the first query result indicates that the first hash H1 and the second hash H2 are different, the computing node can directly initiate a second transaction without the intervention of the computing node's administrator; or the computing node can present the information indicating that the target data held by the computing node has been corrupted to the computing node's administrator through a graphical user interface, so that the administrator can decide whether and when to restore the target data according to the actual situation. For example, if the first query structure includes the generation time of the target data, the administrator may determine, based on the time difference between the current time and the generation time, that the computing node may no longer use the target data in the subsequent process, and thus may not trigger the computing node to initiate a second transaction; or, the administrator may independently decide to trigger the computing node to initiate a second transaction at an appropriate time based on the computing node's usage of the target data.

[0048] The second transaction is used to invoke smart contract C1 deployed in the blockchain system. For example, the To field of the second transaction may include the contract address of smart contract C1 in the blockchain system, and the Data field of the second transaction may include the data identifier T. Optionally, it may also include the function identifier of the third function F3 called in smart contract C1.

[0049] In step S211, the blockchain system queries the disaster recovery information of the target data in the contract state of smart contract C1 according to the second transaction, and obtains the second query result, which includes the disaster recovery data of the target data.

[0050] The blockchain system can execute smart contract C1 based on the second transaction. For example, it can execute the third function F3 based on the function identifier of the third function F3 included in the Data field of the second transaction, thereby achieving the following: based on the data identifier T of the target data included in the Data field of the second transaction, the disaster recovery information of the target data is queried in the contract state of smart contract C1, and then the disaster recovery data of the target data is read from the disaster recovery information of the target data, and a second query result containing at least the disaster recovery data is generated.

[0051] In one possible implementation, the second query result may also include the first hash H1 of the target data.

[0052] In one possible implementation, the second query result may also include the location information of the target data.

[0053] Step S2131: The computing node receives the second query result from the blockchain system.

[0054] Step S2133: The computing node obtains the target data based on the disaster recovery data in the second query result.

[0055] When the disaster recovery data is the target data, the compute node can directly use the disaster recovery data in the second query result as the target data. When the disaster recovery data is the storage path corresponding to multiple data shards of the target data, the compute node obtains the multiple data shards according to the storage path of the multiple data shards, and then generates the target data based on some or all of the multiple data shards. For the target data obtained by the compute node in step S2133, if the second query result includes the first hash H1 of the target data, the compute node can also use the first hash H1 to verify the correctness of the target data it obtained.

[0056] If the second query result includes the location information of the target data, the computing node can also perform the following step S215 to store the target data to the corresponding location according to the location information of the target data.

[0057] For example, if the target data is a record stored in a database table, and its location information includes, for example, the database identifier and the table identifier, then the compute node can generate a corresponding data storage request based on the table identifier and the target data. It then sends the data storage request to the corresponding database based on the database identifier, and the database responds to the storage request to store the target data in the corresponding table. Alternatively, if the target data is a cached value in the compute node using key-value pairs, and its location information is its corresponding key, then the compute node can replace the value of the corresponding key with the target data obtained in step S3. Furthermore, if the target data is proprietary data belonging to a specific application, and its location information is the identifier of an interface program publicly exposed within that application for passing the target data, then the compute node can use the identifier of this interface program to make local or remote calls to pass the target data to the target node.

[0058] In the aforementioned method embodiments, each method step executed by the blockchain system can be specifically executed by a blockchain node within the blockchain system.

[0059] Based on the same concept as the foregoing method embodiments, this specification also provides a blockchain-based data management device 300, involving a blockchain system and a computing node. The blockchain system deploys smart contracts, and the contract state of the smart contracts includes disaster recovery information for target data. This disaster recovery information includes the data identifier, first hash, and disaster recovery data of the target data. The device 300 is deployed in the computing node. See also... Figure 3 As shown, the device 300 includes: a hash calculation unit 301 configured to calculate a second hash of the data it holds corresponding to the data identifier; a transaction sending unit 303 configured to send a first transaction to the blockchain system, including the data identifier and the second hash, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the first transaction to obtain a first query result, wherein the first hash and the second hash are the same; a result processing unit 305 configured to receive the first query result from the blockchain system and trigger the transaction sending unit 303 if the result processing unit 305 indicates that the first hash and the second hash are different; the transaction sending unit 303 is further configured to send a second transaction to the blockchain system, including the data identifier, triggered by the result processing unit 305, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the second transaction to obtain a second query result, including the disaster recovery data; the result processing unit 305 is further configured to receive the second query result from the blockchain system and obtain the target data according to the disaster recovery data.

[0060] Based on the same concept as the foregoing method embodiments, this specification also provides a blockchain node 400 in a blockchain system. The blockchain system deploys smart contracts, and the contract state of the smart contracts includes disaster recovery information for target data. This disaster recovery information includes the data identifier, first hash, and disaster recovery data of the target data. See also... Figure 4As shown, the blockchain node 400 includes: a transaction receiving unit 401 configured to receive a first transaction from a computing node, including the data identifier and a second hash of data held by the computing node and corresponding to the data identifier; a transaction processing unit 403 configured to query the disaster recovery information in the contract state of the smart contract based on the first transaction to obtain a first query result, wherein the first hash and the second hash are the same; a result returning unit 405 configured to send the first query result to the computing node; the transaction receiving unit 401 is further configured to receive a second transaction from the computing node, the second transaction being sent by the computing node when the first query result indicates that the first hash and the second hash are different, including the data identifier; the transaction processing unit 403 is further configured to query the disaster recovery information in the contract state of the smart contract based on the second transaction to obtain a second query result, including the disaster recovery data; the result returning unit 405 is further configured to send the second query result to the computing node, so that the computing node obtains the target data based on the disaster recovery data.

[0061] This specification also provides a computing device in its embodiments, including a memory and a processor. The memory stores computer programs / instructions, and when the processor executes the computer programs / instructions, it implements the various method steps performed by the blockchain system or computing node in the foregoing method embodiments of this specification.

[0062] This specification also provides a computer-readable storage medium storing a computer program / instruction, which, when executed in a computing device, causes the computing device to perform the various method steps executed by the blockchain system or computing node in the aforementioned method embodiments.

[0063] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0064] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0065] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0066] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0067] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0068] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0069] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0070] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0071] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0072] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0073] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0074] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0075] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0076] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0077] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for data management based on a blockchain, involving a blockchain system and a computing node, wherein the blockchain system is deployed with a smart contract, and the contract state of the smart contract comprises disaster recovery information of target data, and the disaster recovery information comprises a data identifier, a first hash and disaster recovery data of the target data, and the method comprises: the computing node calculates a second hash of data corresponding to the data identifier held by the computing node, and sends a first transaction to the blockchain system, wherein the first transaction comprises the data identifier and the second hash; the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the first transaction, and obtains a first query result indicating whether the first hash and the second hash are the same; the computing node receives the first query result from the blockchain system, and in the case that the first query result indicates that the first hash and the second hash are different, sends a second transaction to the blockchain system, wherein the second transaction comprises the data identifier; the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the second transaction, and obtains a second query result comprising the disaster recovery data; the computing node receives the second query result from the blockchain system, and acquires the target data according to the disaster recovery data. 2.The method of claim 1, wherein the disaster recovery information further comprises location information corresponding to the target data, and the first query result further comprises the location information. The method further comprises: the computing node stores the target data to a corresponding location according to the location information. 3.The method of claim 1, wherein the disaster recovery data is the target data. Or, the disaster recovery data comprises storage paths corresponding to a plurality of data shards of the target data. 4.The method of any one of claims 1-3, further comprising: the computing node sends a third transaction to the blockchain system, wherein the third transaction comprises the disaster recovery information; the blockchain system stores the disaster recovery information in the contract state of the smart contract according to the third transaction. 5.A method for data management based on a blockchain, involving a blockchain system and a computing node, wherein the blockchain system is deployed with a smart contract, and the contract state of the smart contract comprises disaster recovery information of target data, and the disaster recovery information comprises a data identifier, a first hash and disaster recovery data of the target data, and the method is performed by the computing node, and comprises: the computing node calculates a second hash of data corresponding to the data identifier held by the computing node, and sends a first transaction to the blockchain system, wherein the first transaction comprises the data identifier and the second hash, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the first transaction, and obtains a first query result indicating whether the first hash and the second hash are the same; the computing node receives the first query result from the blockchain system, and in the case that the first query result indicates that the first hash and the second hash are different, sends a second transaction to the blockchain system, wherein the second transaction comprises the data identifier, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the second transaction, and obtains a second query result comprising the disaster recovery data; receive the second query result from the blockchain system, and obtain the target data according to the disaster recovery data.

6. The method of claim 5, wherein the disaster recovery information further comprises location information corresponding to the target data, and the first query result further comprises the location information. The method further includes storing the target data to a corresponding location according to the location information.

7. The method of claim 5, wherein the disaster recovery data is the target data. Alternatively, the disaster recovery data includes storage paths corresponding to multiple data shards of the target data.

8. The method of any one of claims 5-7, further comprising: send a third transaction to the blockchain system, the third transaction including the disaster recovery information, so that the blockchain system stores the disaster recovery information in the contract state of the smart contract according to the third transaction.

9. A blockchain-based data management method, involving a blockchain system and a computing node, the blockchain system deploying a smart contract, a contract state of the smart contract including disaster recovery information of target data, the disaster recovery information including a data identifier of the target data, a first hash, and disaster recovery data, the method being performed by a blockchain node in the blockchain system, and the method including: receiving a first transaction from the computing node, the first transaction including the data identifier and a second hash of data held by the computing node and corresponding to the data identifier; querying the disaster recovery information in the contract state of the smart contract according to the first transaction to obtain a first query result indicating whether the first hash and the second hash are the same, and sending the first query result to the computing node; receiving a second transaction from the computing node, the second transaction being sent by the computing node in a case where the first query result indicates that the first hash and the second hash are different, the second transaction including the data identifier; querying the disaster recovery information in the contract state of the smart contract according to the second transaction to obtain a second query result including the disaster recovery data, and sending the second query result to the computing node, so that the computing node obtains the target data according to the disaster recovery data.

10. The method of claim 9, wherein the disaster recovery information further includes location information corresponding to the target data, and the first query result further includes the location information.

11. The method of claim 9, wherein the disaster recovery data is the target data. Alternatively, the disaster recovery data includes storage paths corresponding to multiple data shards of the target data.

12. The method of any one of claims 9-11, the method further including: receiving a third transaction from the computing node, the third transaction including the disaster recovery information storing the disaster recovery information in the contract state of the smart contract according to the third transaction.

13. A blockchain-based data management apparatus, involving a blockchain system and a computing node, the blockchain system deploying a smart contract, a contract state of the smart contract including disaster recovery information of target data, the disaster recovery information including a data identifier of the target data, a first hash, and disaster recovery data, the apparatus being deployed in the computing node, and the apparatus including: a hash calculation unit configured to calculate a second hash of data held by the computing node and corresponding to the data identifier. a transaction sending unit, configured to send a first transaction to the blockchain system, wherein the first transaction comprises the data identifier and the second hash, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the first transaction, and obtains a first query result indicating whether the first hash and the second hash are the same; a result processing unit, configured to receive the first query result from the blockchain system, and trigger the transaction sending unit if the first query result indicates that the first hash and the second hash are different; the transaction sending unit is further configured to send a second transaction to the blockchain system under the triggering of the result processing unit, wherein the second transaction comprises the data identifier, so that the blockchain system queries the disaster recovery information in the contract state of the smart contract according to the second transaction, and obtains a second query result comprising the disaster recovery data; the result processing unit is further configured to receive the second query result from the blockchain system, and obtain the target data according to the disaster recovery data.

14. A blockchain node in a blockchain system, wherein a smart contract is deployed in the blockchain system, and disaster recovery information of target data is included in a contract state of the smart contract, the disaster recovery information comprising a data identifier of the target data, a first hash, and disaster recovery data, the blockchain node comprising: a transaction receiving unit, configured to receive a first transaction from a computing node, wherein the first transaction comprises the data identifier and a second hash of data corresponding to the data identifier and held by the computing node; a transaction processing unit, configured to query the disaster recovery information in the contract state of the smart contract according to the first transaction, and obtain a first query result indicating whether the first hash and the second hash are the same; a result returning unit, configured to send the first query result to the computing node; the transaction receiving unit is further configured to receive a second transaction from the computing node, wherein the second transaction is sent by the computing node if the first query result indicates that the first hash and the second hash are different, and the second transaction comprises the data identifier; the transaction processing unit is further configured to query the disaster recovery information in the contract state of the smart contract according to the second transaction, and obtain a second query result comprising the disaster recovery data; the result returning unit is further configured to send the second query result to the computing node, so that the computing node obtains the target data according to the disaster recovery data.

15. A computing device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the method of any one of claims 5-12 when executing the computer program.

16. A computer readable storage medium, which stores a computer program, and when the computer program is executed in a computing device, the computing device executes the method of any one of claims 5-12.

Images