Blockchain data backup method, device, storage medium and electronic device

By obtaining the status information and change data of blockchain data and asynchronously storing them in the backup processing sequence, the transaction impact problem caused by blockchain ledger damage is solved, and efficient data backup and network availability are achieved.

CN114036002BActive Publication Date: 2025-09-12NEUSOFT CORP
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202111335577.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-11-11
Publication Date
2025-09-12
Estimated Expiration
2041-11-11

AI Technical Summary

Technical Problem

Damage to the blockchain ledger affects the transaction process, and existing technologies cannot effectively back up data, affecting the availability and performance of the blockchain network.

Method used

By obtaining the status information and change data of blockchain data, asynchronously storing it in the backup processing sequence, dividing the storage partitions based on the description information, and using signature verification and hash value verification to ensure data integrity, a backup process independent of the target node is achieved.

Benefits of technology

It achieves effective backup of blockchain data, reduces the performance impact of the backup process on the target node, ensures data integrity and availability, and avoids the degradation of blockchain network performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114036002B_ABST
    Figure CN114036002B_ABST
Patent Text Reader

Abstract

The present disclosure relates to a blockchain data backup method, device, storage medium, and electronic device. The method comprises: obtaining status information of the blockchain data of a target node; obtaining change data of the blockchain data when the status information indicates a change in the blockchain data of the target node; adding the change data as data to be backed up to a backup processing sequence; and asynchronously storing the data to be backed up in the backup processing sequence into a backup data space. The above technical solution can achieve the effect of backing up the blockchain data of the target node. Moreover, this backup method is independent of the blockchain data processing logic of the target node itself, thereby reducing the impact of the backup process on the blockchain data processing performance of the target node.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain technology, and in particular to a blockchain data backup method, device, storage medium, and electronic device. Background Art

[0002] Blockchain technology enables the collective maintenance of a reliable database through a decentralized and trustless approach. Due to the immutable and traceable nature of blockchain ledgers, it has broad application scenarios in cross-border payments, credential services, and finance.

[0003] In related scenarios, the blockchain ledger may also be damaged, thereby affecting the related transaction process. Summary of the Invention

[0004] The purpose of this disclosure is to provide a blockchain data backup method, device, storage medium and electronic device to solve the above-mentioned related technical problems.

[0005] To achieve the above objectives, according to a first aspect of an embodiment of the present disclosure, a blockchain data backup method is provided, comprising:

[0006] Obtain the status information of the target node's blockchain data;

[0007] When the state information indicates that the blockchain data of the target node has changed, obtaining change data of the blockchain data;

[0008] Adding the changed data as data to be backed up to a backup processing sequence;

[0009] The data to be backed up in the backup processing sequence is asynchronously stored in the backup data space.

[0010] Optionally, it also includes:

[0011] When storing target data to be backed up in the backup data space, obtaining a first hash value of the blockchain data of the target node, wherein the target data to be backed up is preset data to be backed up in the backup processing sequence;

[0012] Obtaining a second hash value of the backup blockchain data in the backup data space;

[0013] If the first hash value is inconsistent with the second hash value, rolling back the backup blockchain data in the backup data space from the current backup node to the previous backup node;

[0014] The data to be backed up between the previous backup node and the current backup node is backed up again.

[0015] Optionally, it also includes:

[0016] After the backup is completed, the blockchain data is sampled to obtain multiple blockchain sampling data;

[0017] Calculating data credential information based on the plurality of blockchain sampled data;

[0018] The data credential information and the index information of the multiple blockchain sampling data are sent to the target node.

[0019] Optionally, calculating data credential information based on the plurality of blockchain sampled data includes:

[0020] Constructing a Merkle tree based on the plurality of blockchain sampling data;

[0021] Calculate the first root hash value of the Merkle tree to obtain the data credential information;

[0022] Among them, the index information of the blockchain sampling data is used by the target node to obtain multiple target blockchain data from the backup data space. The target node calculates a second root hash value based on the obtained multiple target blockchain data, and verifies the ledger data of the blockchain data by comparing the data certificate information and the second root hash value.

[0023] Optionally, adding the changed data as data to be backed up to a backup processing sequence includes:

[0024] Parsing the change data to obtain description information of the change data, where the description information includes one or more of the channel information to which the change data belongs, the name of the smart contract corresponding to the change data, and the timestamp of the change data;

[0025] The changed data and description information of the changed data are added to the backup processing sequence.

[0026] Optionally, the step of asynchronously storing the data to be backed up in the backup processing sequence into a backup data space includes:

[0027] When storing each data to be backed up, obtaining description information of the data to be backed up;

[0028] Determining a target storage partition for the data to be backed up in the backup data space according to the acquired description information, wherein the backup data space is divided into multiple storage partitions based on one or more of channel information, smart contract name, and timestamp;

[0029] The data to be backed up is saved in the target storage partition.

[0030] Optionally, adding the changed data as data to be backed up to a backup processing sequence includes:

[0031] Signing the changed data to obtain signature information of the changed data;

[0032] Adding the changed data and signature information of the changed data to a backup processing sequence;

[0033] The step of asynchronously storing the data to be backed up in the backup processing sequence into the backup data space includes:

[0034] For each piece of data to be backed up in the backup processing sequence, verify the data to be backed up using the signature information of the data to be backed up;

[0035] If the verification is successful, the data to be backed up is stored in the backup data space.

[0036] Optionally, it also includes:

[0037] receiving a data backup request from the target node, where the data backup request is generated by the target node when a storage exception occurs;

[0038] The data to be backed up in the data backup request is added to the backup processing sequence.

[0039] Optionally, it also includes:

[0040] receiving a data query request from the target node, wherein the data query request includes information about the data to be queried;

[0041] Acquire the data to be queried from the backup data space according to the information of the data to be queried;

[0042] The acquired data to be queried is sent to the target node.

[0043] According to a second aspect of an embodiment of the present disclosure, a blockchain data backup device is provided, comprising:

[0044] The first acquisition module is used to obtain the status information of the blockchain data of the target node;

[0045] A second acquisition module is configured to acquire change data of the blockchain data when the state information indicates that the blockchain data of the target node has changed;

[0046] An execution module, configured to add the changed data as data to be backed up to a backup processing sequence;

[0047] The first backup module is configured to asynchronously store the data to be backed up in the backup processing sequence into a backup data space.

[0048] Optionally, it also includes:

[0049] a third acquisition module, configured to acquire a first hash value of the blockchain data of the target node when storing the target data to be backed up in the backup data space, wherein the target data to be backed up is the preset data to be backed up in the backup processing sequence;

[0050] A fourth acquisition module, configured to obtain a second hash value of the backup blockchain data in the backup data space;

[0051] A first data processing module is configured to roll back the backup blockchain data in the backup data space from the current backup node to the previous backup node when the first hash value is inconsistent with the second hash value;

[0052] The second backup module is used to re-backup the data to be backed up between the previous backup node and the current backup node.

[0053] Optionally, it also includes:

[0054] A sampling module is used to sample the blockchain data after the backup is completed to obtain multiple blockchain sampling data;

[0055] A calculation module, configured to calculate data credential information based on the plurality of blockchain sampled data;

[0056] The credential sending module is used to send the data credential information and the index information of the multiple blockchain sampling data to the target node.

[0057] Optionally, the calculation module includes:

[0058] A construction submodule, configured to construct a Merkle tree based on the plurality of blockchain sampling data;

[0059] A calculation submodule, configured to calculate the first root hash value of the Merkle tree to obtain the data credential information;

[0060] Among them, the index information of the blockchain sampling data is used by the target node to obtain multiple target blockchain data from the backup data space. The target node calculates a second root hash value based on the obtained multiple target blockchain data, and verifies the ledger data of the blockchain data by comparing the data certificate information and the second root hash value.

[0061] Optionally, the execution module includes:

[0062] a data parsing submodule, configured to parse the change data to obtain description information of the change data, wherein the description information includes one or more of the channel information to which the change data belongs, the name of the smart contract corresponding to the change data, and the timestamp of the change data;

[0063] The data adding submodule is used to add the changed data and the description information of the changed data to the backup processing sequence.

[0064] Optionally, the first backup module includes:

[0065] An acquisition submodule, configured to acquire description information of each data to be backed up when storing the data to be backed up;

[0066] a determination submodule, configured to determine a target storage partition of the data to be backed up in the backup data space based on the acquired description information, wherein the backup data space is divided into multiple storage partitions based on one or more of channel information, smart contract name, and timestamp;

[0067] The first storage submodule is configured to store the data to be backed up in the target storage partition.

[0068] Optionally, the execution module includes:

[0069] A signature submodule, configured to sign the changed data to obtain signature information of the changed data;

[0070] An execution submodule, configured to add the changed data and signature information of the changed data to a backup processing sequence;

[0071] The first backup module includes:

[0072] A signature verification submodule, configured to verify each to-be-backed-up data in the backup processing sequence by using the signature information of the to-be-backed-up data;

[0073] The second storage submodule is configured to store the data to be backed up in the backup data space if the verification is passed.

[0074] Optionally, it also includes:

[0075] A receiving module, configured to receive a data backup request from the target node, wherein the data backup request is generated by the target node when a storage anomaly occurs;

[0076] The second data processing module is configured to add the data to be backed up in the data backup request to the backup processing sequence.

[0077] According to a third aspect of an embodiment of the present disclosure, a non-temporary computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the steps of the method described in any one of the first aspects are implemented.

[0078] According to a fourth aspect of the embodiments of the present disclosure, there is provided an electronic device, including:

[0079] a memory having a computer program stored thereon;

[0080] A processor is used to execute the computer program in the memory to implement the steps of any one of the methods described in the first aspect above.

[0081] Taking the application of the above technical solution to a third-party backup device as an example, the backup device can monitor the status of the target node's blockchain data and obtain status information. If the status information indicates a change in the blockchain data, the backup device can obtain the blockchain data change data and add the change data to the backup processing sequence. The backup device can also store the data to be backed up in the backup processing sequence in the backup data space through asynchronous storage.

[0082] This method can achieve the effect of backing up the blockchain data of the target node. Moreover, this backup method is independent of the blockchain data processing logic of the target node itself, thus reducing the impact of the backup process on the blockchain data processing performance of the target node.

[0083] Other features and advantages of the present disclosure will be described in detail in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0084] The accompanying drawings are used to provide a further understanding of the present disclosure and constitute a part of the specification. Together with the following detailed description, they are used to explain the present disclosure but do not constitute a limitation of the present disclosure. In the accompanying drawings:

[0085] Figure 1 This is a flowchart of a blockchain data backup method shown in an exemplary embodiment of the present disclosure.

[0086] Figure 2 It is a block diagram of a backup data space shown in an exemplary embodiment of the present disclosure.

[0087] Figure 3 This is a flowchart of a blockchain data backup method shown in an exemplary embodiment of the present disclosure.

[0088] Figure 4 This is a flowchart of a blockchain data backup method shown in an exemplary embodiment of the present disclosure.

[0089] Figure 5 The figure is a flowchart of a blockchain data backup shown in an exemplary embodiment of the present disclosure.

[0090] Figure 6 It is a block diagram of a blockchain data backup device shown in an exemplary embodiment of the present disclosure.

[0091] Figure 7 It is a block diagram of an electronic device shown in an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0092] The following describes the specific embodiments of the present disclosure in detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only used to illustrate and explain the present disclosure and are not intended to limit the present disclosure.

[0093] Before introducing the blockchain data backup method, device, storage medium, and electronic device disclosed herein, we first describe the application scenarios of the present disclosure. The various embodiments provided in the present disclosure can be used, for example, to back up data on blockchain nodes.

[0094] In related scenarios, blockchain nodes or their storage media may malfunction, leading to issues like abnormal blockchain data read and write, data loss, and other issues, which in turn render the relevant blockchain node functions unusable. When endorsement nodes experience these malfunctions, they can further impact the performance of the blockchain network, even rendering it unavailable.

[0095] To this end, the present disclosure provides a blockchain data backup method. Figure 1 This is a flowchart of a blockchain data backup method shown in an exemplary embodiment of the present disclosure, with reference to Figure 1 , the method comprising:

[0096] In step 11, the state information of the blockchain data of the target node is obtained. The target node can be any node in the blockchain network that needs to perform blockchain data backup.

[0097] For example, the method is applied to a third-party backup device. The backup device can be configured to monitor the blockchain data of a target node. For example, if the target node stores blockchain data in a local database, the backup device can monitor the local database. If the target node is monitored performing an operation on the local database (e.g., a write or delete operation), the backup device can determine that a change has occurred in the blockchain data.

[0098] In step 12, when the status information indicates that the blockchain data of the target node has changed, the change data of the blockchain data is obtained.

[0099] Here, blockchain data may include block data within a blockchain. For example, when a new block is generated within a blockchain network, the target node may store the newly generated block. In this case, the changed data may be the newly generated block, and step 12 may involve the backup device acquiring the newly generated block.

[0100] In some implementation scenarios, the blockchain may store a hash value of the transaction data, and the target node may store at least a portion of the transaction data corresponding to the hash value. In this case, the change data may include the change data in the transaction data stored locally on the target node.

[0101] In step 13, the changed data is added to the backup processing sequence as data to be backed up.

[0102] For example, the change data can be treated as a new event and added to the backup event processing sequence. The backup device can also store multiple change data and add the change data to the backup processing sequence when a preset condition is met. The preset condition can be, for example, that the size of the change data is greater than a capacity threshold, that the duration of storing the change data is greater than a duration threshold, etc.

[0103] In some implementation scenarios, the changed data may be processed when it is added to the backup processing sequence. For example, in one possible implementation, adding the changed data as data to be backed up to the backup processing sequence (step 13) includes:

[0104] Parse the change data to obtain descriptive information of the change data. Here, the descriptive information may include one or more of the channel information to which the change data belongs, the name of the smart contract corresponding to the change data, and the timestamp of the change data. For example, in some scenarios, the descriptive information may be: channel name + smart contract name + number. Among them, the number may be a timestamp, so that the timing of the change data can be represented. In some scenarios, the number may also be other numbers (such as a sequence field), and the present disclosure does not limit this. In addition, characters (such as "#") may be used to separate different fields in the description information for easy parsing and processing.

[0105] In this way, the change data and the description information of the change data can be added to the backup processing sequence.

[0106] In step 14, the data to be backed up in the backup processing sequence is asynchronously stored in a backup data space. Here, the backup data space may be, for example, a preset backup database.

[0107] Continuing with the above example, in the case where the description information of the changed data is added to the backup processing sequence, step 14 may include:

[0108] When storing each data to be backed up, description information of the data to be backed up is obtained, and a target storage partition of the data to be backed up in the backup data space is determined according to the obtained description information.

[0109] Figure 2 This is a block diagram of a backup data space shown in the present disclosure. Figure 2 The backup data space can be divided into multiple storage partitions based on one or more of the channel information, smart contract name, and timestamp (i.e., the namespace in the figure). Taking channels as an example, if there are channels 1 and 2, storage partition 1 can be allocated to channel 1 in the backup data space, and storage partition 2 can be allocated to channel 2. In this way, if the description information of the data to be backed up indicates that the data to be backed up belongs to channel 1, the target storage partition corresponding to the data to be backed up can be determined to be storage partition 1.

[0110] In this way, the data to be backed up can be saved in the determined target storage partition.

[0111] The following is an example of the data storage process. Figure 2 In a storage partition, storage files can include metafiles and master files. Metafiles can store information such as data indexes, file offsets, file pointers, checkpoint offsets, and file sizes. Master files can store change data, such as data IDs and ledger data. The master file can consist of one or more subfiles. In some scenarios, each subfile can be as large as 64MB. When a file exceeds 64MB, a new subfile is created.

[0112] When storing data to be backed up, the target storage partition can be determined based on the description of the data to be backed up. The metafile of the target storage partition is then read to obtain the current data storage file pointer and file offset of the target storage partition. In this way, the data to be backed up can be written to the target storage partition in an appended manner based on the current data storage file pointer and file offset, and the metafile of the target storage partition is recorded and updated.

[0113] That is to say, the above technical solution can partition and store the backup data according to the type of the backup data, thereby facilitating the management of the backup files.

[0114] In a possible implementation, adding the changed data as data to be backed up to a backup processing sequence (step 13) includes:

[0115] Sign the changed data to obtain signature information of the changed data. Add the changed data and the signature information of the changed data to the backup processing sequence. The signature information may be obtained by, for example, signing the changed data using the backup device's own private key. Please refer to the description of the signing process in the relevant technology, which is not detailed in this disclosure.

[0116] In the case where the signature information is added to the backup processing sequence, the step of asynchronously storing the data to be backed up in the backup processing sequence into the backup data space (step 14) includes:

[0117] For each data to be backed up in the backup processing sequence, the data to be backed up is verified using the signature information of the data to be backed up, and if the verification passes, the data to be backed up is stored in the backup data space.

[0118] For example, a hash value of the data to be backed up can be calculated, and the signature information can be decrypted using the public key of the backup device. This way, the decrypted hash value of the data to be backed up can be compared with the calculated hash value to verify the correctness of the data to be backed up. This improves data security during the backup process.

[0119] In the above technical solution, the backup device can monitor the status of the blockchain data of the target node and obtain status information. If the status information indicates a change in the blockchain data, the backup device can obtain the change data of the blockchain data. In this way, the backup device can add the change data to the backup processing sequence. The backup device can also store the data to be backed up in the backup processing sequence in the backup data space through asynchronous storage.

[0120] This method can achieve the effect of backing up the blockchain data of the target node. Moreover, this backup method is independent of the blockchain data processing logic of the target node itself, thus reducing the impact of the backup process on the blockchain data processing performance of the target node.

[0121] In some scenarios, the target node may experience data writing anomalies. In this case, the target node needs to back up data, but the blockchain data of the target node has not changed.

[0122] Therefore, in one possible implementation, the method further includes:

[0123] Receive a data backup request from the target node, where the data backup request is generated by the target node when a storage anomaly occurs, and add the data to be backed up in the data backup request to the backup processing sequence.

[0124] In this way, when the target node storage is abnormal, the blockchain data can also be backed up through the above technical solution, which helps to improve the integrity of the backup data.

[0125] Figure 3 This is a flowchart of a blockchain data backup method provided by the present disclosure. Figure 3 As shown, the method includes:

[0126] S31, obtaining the status information of the blockchain data of the target node.

[0127] S32, when the state information indicates that the blockchain data of the target node has changed, obtain change data of the blockchain data.

[0128] S33: Add the changed data as data to be backed up to the backup processing sequence.

[0129] S34: asynchronously storing the data to be backed up in the backup processing sequence into the backup data space.

[0130] S35: When the target data to be backed up is stored in the backup data space, a first hash value of the blockchain data of the target node is obtained.

[0131] The target data to be backed up is the preset data to be backed up in the backup processing sequence, and the preset data to be backed up can be set according to application requirements. For example, the last data to be backed up in the backup processing sequence can be used as the target data to be backed up.

[0132] In some scenarios, the target data to be backed up may also refer to each data to be backed up in the backup processing sequence. In this case, the first hash value of the blockchain data of the target node can be obtained after each data to be backed up is stored.

[0133] S36: Obtain a second hash value of the backup blockchain data in the backup data space.

[0134] S37: If the first hash value is inconsistent with the second hash value, the backup blockchain data in the backup data space is rolled back from the current backup node to the previous backup node.

[0135] It should be understood that multiple backup nodes may exist during the backup process. For example, in the time dimension, there may be multiple backup time nodes, such as a backup time node at 9:00 and a backup time node at 10:00. In this case, step S37 may mean that when the first hash value and the second hash value are inconsistent, the backup blockchain data in the backup data space is restored to the backup blockchain data at the backup time node at 9:00.

[0136] S38: Re-backup the data to be backed up between the previous backup node and the current backup node.

[0137] Continuing with the above example, step S38 may refer to re-backing up the changed data of the blockchain data generated between 9:00 and 10:00.

[0138] In other words, the backup data can be verified and re-backed up when an abnormality occurs. In this way, the correctness of the backup data can be guaranteed.

[0139] It should be noted that in some scenarios, the backup blockchain data may include an identifier indicating that the data is the backup data. In some scenarios, the target node may also back up partial blockchain data. In these cases, even if the backup blockchain data is correct, the hash values ​​calculated for the backup blockchain data and the target node's blockchain data may differ.

[0140] For this purpose, refer to Figure 4 A flowchart of a blockchain data backup method is shown. In one possible implementation, the method includes:

[0141] S41, obtaining the status information of the blockchain data of the target node.

[0142] S42, when the state information indicates that the blockchain data of the target node has changed, obtain change data of the blockchain data.

[0143] S43: Add the changed data as data to be backed up to the backup processing sequence.

[0144] S44: asynchronously storing the data to be backed up in the backup processing sequence into the backup data space.

[0145] S45: After the backup is completed, the blockchain data is sampled to obtain a plurality of blockchain sample data.

[0146] For example, the blockchain data can be divided into multiple data intervals based on the required number of samples. For example, if the blockchain data includes N transaction data, if M data are to be sampled, the N transactions can be divided (e.g., evenly) into M data intervals. In this way, each of the data intervals can be traversed, and a data item can be randomly sampled from the traversed data interval, ultimately obtaining the multiple blockchain sample data items.

[0147] It should be noted that if the target node backs up part of the blockchain data, sampling can be performed within the backed-up blockchain data range. In addition, in order to improve the effectiveness of data credential information, the amount of sampled data can also be increased in some scenarios (such as the entire blockchain data), and this disclosure does not impose any restrictions on this.

[0148] S46, calculating data credential information based on the multiple blockchain sampling data.

[0149] For example, a Merkle tree may be constructed based on the plurality of blockchain sampling data, and a first root hash value of the Merkle tree may be calculated, and the first root hash value may be used as the data credential information.

[0150] S47: Send the data credential information and the index information of the multiple blockchain sampling data to the target node.

[0151] Here, the index information of the blockchain sample data may be a pointer to the blockchain sample data. The index information can be used to obtain the corresponding blockchain sample data from the blockchain data of the target node, and the index information can also be used to obtain the corresponding target blockchain data from the backup blockchain data.

[0152] In this way, by sending the data certificate information and the index information of the multiple blockchain sampling data to the target node, when the blockchain data of the target node is lost, the correctness of the recovered blockchain data can also be verified based on the data certificate information and the index information of the multiple blockchain sampling data.

[0153] For example, the target node can retrieve multiple target blockchain data from the backup data space based on the index information of the blockchain sample data. The target node can also construct a Merkle tree for the retrieved multiple target blockchain data and calculate a second root hash value. In this way, the target node can verify the blockchain ledger data by comparing the data credential information with the second root hash value. If the data credential information and the second root hash value are consistent, the data is credible.

[0154] Using the above technical solution, when restoring blockchain data, the target node can also verify the restored blockchain data based on the data credential information, thereby further enhancing the credibility of the blockchain data. In some possible implementations, the process of calculating the ledger credential information can also be performed through a trusted execution environment, thereby enhancing the credibility of the data credential information.

[0155] In one possible implementation, the method further includes:

[0156] Receive a data query request from the target node, the data query request including information about the data to be queried, such as a description of the data to be queried. In this case, the data to be queried can be retrieved from the backup data space based on the information about the data to be queried, and the retrieved data to be queried can be sent to the target node.

[0157] For example, the backup device can determine the storage partition of the data to be queried in the backup data space based on the descriptive information of the data to be queried (such as the channel name, contract name, etc.) and obtain the metafile of the storage partition. In this way, the backup device can obtain the pointer and offset of the master file corresponding to the data to be queried from the checkpoint information in the metafile, and then obtain the queried data from the storage partition.

[0158] In this way, even if a target node experiences anomalies in blockchain data reading and writing, the target node can still store and read blockchain data using the aforementioned method. In other words, the target node can still execute the corresponding blockchain data processing logic. Therefore, this technical solution solves the problem of blockchain node or blockchain network unavailability caused by blockchain data corruption or loss, while also avoiding the problem of blockchain network performance degradation caused by data synchronization between blockchain nodes.

[0159] It should be noted that the blockchain data backup method provided by this disclosure is described using a backup device as the execution end in the above embodiment. However, in practice, the method can also be executed by the target node. For example, relevant services can be configured on the target node, and the steps involved in this method can be implemented through the configured services.

[0160] Reference Figure 5 A flowchart of blockchain data backup is shown. In some scenarios, data sending service, data receiving service and data synchronization service can be configured in the target node.

[0161] The data sending service can monitor and detect blockchain data on a target node. When the target node's blockchain data changes, the service can retrieve the blockchain data change data. The service can also digitally sign the acquired change data using its own private key and send the change data to the data receiving service as a data event.

[0162] Here, a data event can include a data subject and content. The data subject can, for example, be: the name of the channel to which the data belongs + the name of the smart contract corresponding to the data + the data ID. During implementation, for example, the character "#" can be used to separate fields in the data subject. The event ID can be generated based on a timestamp, thereby reflecting the order of data events. The definition of data content can, for example, be: a digital signature + blockchain change data. During implementation, the character "#" can also be used to separate fields. In addition, data events can be sent in batches. For example, when the number of generated data events exceeds a quantity threshold, all data events are sent together to the data receiving service. This approach can improve system performance.

[0163] The Data Receiving Service can be used to receive data events and store them in an append-to-log format. In some scenarios, the Data Receiving Service can monitor and receive data events sent by the Data Sending Service in real time, and parse the received data events. Continuing with the above example, when parsing data events, the Data Receiving Service can, for example, use the character "#" to separate strings within the data subject and data content to obtain relevant data information. This information may include, for example, channel names, contract names, data IDs, digital signatures, and ledger data. In this way, the Data Receiving Service can store data events in an append-to-log format. For example, newly received data events can be added to the backup event processing sequence.

[0164] The Data Synchronization Service processes data events within the event processing sequence and achieves data synchronization by replaying them. For example, for a captured data event, the Data Synchronization Service can verify the blockchain change data contained in the data event using a digital signature. During verification, the Data Synchronization Service decrypts the digital signature using the public key of the Data Sending Service to obtain a hash value of the blockchain change data. The Data Synchronization Service then calculates the hash value of the blockchain change data contained in the data event and compares it with the decrypted hash value. If the two match, verification passes; if they do not, verification fails.

[0165] If the data verification passes, the data synchronization service can replay the data events. For example, based on the order of the data events, the data operations (such as write, delete) corresponding to the data events can be executed in sequence. In this way, by replaying the data events, blockchain data storage synchronization can be achieved and blockchain data backup can be completed. The backed-up data may include, for example, blockchain historical data, blockchain transaction data, and blockchain status data, which is not limited in this disclosure. In addition, please refer to the above-mentioned storage process for details. Figure 1 For the sake of brevity, this disclosure will not elaborate on this.

[0166] Based on the same inventive concept, the present disclosure also provides a blockchain data backup device. Figure 6 This is a block diagram of a blockchain data backup device shown in the present disclosure, referring to Figure 6 , the apparatus 600 includes:

[0167] The first acquisition module 601 is used to obtain the status information of the blockchain data of the target node;

[0168] A second acquisition module 602 is configured to acquire change data of the blockchain data when the state information indicates that the blockchain data of the target node has changed;

[0169] An execution module 603 is configured to add the changed data as data to be backed up to a backup processing sequence;

[0170] The first backup module 604 is configured to asynchronously store the data to be backed up in the backup processing sequence into a backup data space.

[0171] Taking the application of the above technical solution to a third-party backup device as an example, the backup device can monitor the status of the blockchain data of the target node and obtain status information. If the status information indicates a change in the blockchain data, the backup device can obtain the change data of the blockchain data. In this way, the backup device can add the change data to the backup processing sequence. The backup device can also store the data to be backed up in the backup processing sequence in the backup data space through asynchronous storage.

[0172] This method can achieve the effect of backing up the blockchain data of the target node. Moreover, this backup method is independent of the blockchain data processing logic of the target node itself, thus reducing the impact of the backup process on the blockchain data processing performance of the target node.

[0173] Optionally, the apparatus 600 further includes:

[0174] a third acquisition module, configured to acquire a first hash value of the blockchain data of the target node when storing the target data to be backed up in the backup data space, wherein the target data to be backed up is the preset data to be backed up in the backup processing sequence;

[0175] A fourth acquisition module, configured to obtain a second hash value of the backup blockchain data in the backup data space;

[0176] A first data processing module is configured to roll back the backup blockchain data in the backup data space from the current backup node to the previous backup node when the first hash value is inconsistent with the second hash value;

[0177] The second backup module is used to re-backup the data to be backed up between the previous backup node and the current backup node.

[0178] Optionally, the apparatus 600 further includes:

[0179] A sampling module is used to sample the blockchain data after the backup is completed to obtain multiple blockchain sampling data;

[0180] A calculation module, configured to calculate data credential information based on the plurality of blockchain sampled data;

[0181] The credential sending module is used to send the data credential information and the index information of the multiple blockchain sampling data to the target node.

[0182] Optionally, the calculation module includes:

[0183] A construction submodule, configured to construct a Merkle tree based on the plurality of blockchain sampling data;

[0184] A calculation submodule, configured to calculate the first root hash value of the Merkle tree to obtain the data credential information;

[0185] Among them, the index information of the blockchain sampling data is used by the target node to obtain multiple target blockchain data from the backup data space. The target node calculates a second root hash value based on the obtained multiple target blockchain data, and verifies the ledger data of the blockchain data by comparing the data certificate information and the second root hash value.

[0186] Optionally, the execution module 603 includes:

[0187] a data parsing submodule, configured to parse the change data to obtain description information of the change data, wherein the description information includes one or more of the channel information to which the change data belongs, the name of the smart contract corresponding to the change data, and the timestamp of the change data;

[0188] The data adding submodule is used to add the changed data and the description information of the changed data to the backup processing sequence.

[0189] Optionally, the first backup module 604 includes:

[0190] An acquisition submodule, configured to acquire description information of each data to be backed up when storing the data to be backed up;

[0191] a determination submodule, configured to determine a target storage partition of the data to be backed up in the backup data space based on the acquired description information, wherein the backup data space is divided into multiple storage partitions based on one or more of channel information, smart contract name, and timestamp;

[0192] The first storage submodule is configured to store the data to be backed up in the target storage partition.

[0193] Optionally, the execution module 603 includes:

[0194] A signature submodule, configured to sign the changed data to obtain signature information of the changed data;

[0195] An execution submodule, configured to add the changed data and signature information of the changed data to a backup processing sequence;

[0196] The first backup module 604 includes:

[0197] A signature verification submodule, configured to verify each to-be-backed-up data in the backup processing sequence by using the signature information of the to-be-backed-up data;

[0198] The second storage submodule is configured to store the data to be backed up in the backup data space if the verification is passed.

[0199] Optionally, the apparatus 600 further includes:

[0200] A receiving module, configured to receive a data backup request from the target node, wherein the data backup request is generated by the target node when a storage anomaly occurs;

[0201] The second data processing module is configured to add the data to be backed up in the data backup request to the backup processing sequence.

[0202] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0203] The present disclosure also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the blockchain data backup method provided by the present disclosure.

[0204] The present disclosure also provides an electronic device, comprising:

[0205] a memory having a computer program stored thereon;

[0206] A processor is configured to execute the computer program in the memory to implement the steps of the blockchain data backup method provided in the present disclosure.

[0207] Figure 7 FIG. 7 is a block diagram of an electronic device 700 according to an exemplary embodiment. Figure 7 As shown, the electronic device 700 may include: a processor 701 , a memory 702 , and may further include one or more of a multimedia component 703 , an input / output (I / O) interface 704 , and a communication component 705 .

[0208] The processor 701 is used to control the overall operation of the electronic device 700 to complete all or part of the steps in the above-mentioned blockchain data backup method. The memory 702 is used to store various types of data to support the operation of the electronic device 700. This data may include, for example, instructions for any application or method operating on the electronic device 700, as well as application-related data, such as contact information, sent and received messages, images, audio, video, etc. The memory 702 can be implemented by any type of volatile or non-volatile storage device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 703 may include a screen and an audio component. The screen may be, for example, a touch screen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signal may be further stored in the memory 702 or sent via the communication component 705. The audio component also includes at least one speaker for outputting audio signals. The I / O interface 704 provides an interface between the processor 701 and other interface modules. The above-mentioned other interface modules may be a keyboard, a mouse, buttons, etc. These buttons may be virtual buttons or physical buttons. The communication component 705 is used for wired or wireless communication between the electronic device 700 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IOT, eMTC, or other 5G, etc., or a combination of one or more thereof, is not limited here. Therefore, the corresponding communication component 705 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0209] In an exemplary embodiment, the electronic device 700 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-mentioned blockchain data backup method.

[0210] In another exemplary embodiment, a computer-readable storage medium including program instructions is further provided. When the program instructions are executed by a processor, the steps of the above-mentioned blockchain data backup method are implemented. For example, the computer-readable storage medium may be the aforementioned memory 702 including the program instructions. The program instructions may be executed by the processor 701 of the electronic device 700 to implement the above-mentioned blockchain data backup method.

[0211] In another exemplary embodiment, a computer program product is further provided, which includes a computer program that can be executed by a programmable device, and has a code portion for performing the above-mentioned blockchain data backup method when executed by the programmable device.

[0212] The preferred embodiments of the present disclosure are described in detail above in conjunction with the accompanying drawings. However, the present disclosure is not limited to the specific details of the above embodiments. Within the technical concept of the present disclosure, various simple modifications can be made to the technical solutions of the present disclosure, and these simple modifications all fall within the scope of protection of the present disclosure.

[0213] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any appropriate manner without contradiction. In order to avoid unnecessary repetition, the present disclosure will not further describe various possible combinations.

[0214] In addition, the various embodiments of the present disclosure may be arbitrarily combined, and as long as they do not violate the concept of the present disclosure, they should also be regarded as the contents disclosed by the present disclosure.

Claims

1. A blockchain data backup method, characterized in that: include: Obtain the status information of the target node's blockchain data; When the state information indicates that the blockchain data of the target node has changed, obtaining change data of the blockchain data; Adding the changed data as data to be backed up to a backup processing sequence; Asynchronously storing the data to be backed up in the backup processing sequence into the backup data space; After the backup is completed, the blockchain data is sampled to obtain multiple blockchain sampling data; Calculating data credential information based on the plurality of blockchain sampled data; Sending the data credential information and the index information of the plurality of blockchain sampled data to the target node; The step of calculating data credential information based on the plurality of blockchain sampled data includes: Constructing a Merkle tree based on the plurality of blockchain sampling data; Calculate the first root hash value of the Merkle tree to obtain the data credential information; Among them, the index information of the blockchain sampling data is used by the target node to obtain multiple target blockchain data from the backup data space. The target node calculates a second root hash value based on the obtained multiple target blockchain data, and verifies the ledger data of the blockchain data by comparing the data certificate information and the second root hash value.

2. The method according to claim 1, characterized in that Also includes: When storing target data to be backed up in the backup data space, obtaining a first hash value of the blockchain data of the target node, wherein the target data to be backed up is preset data to be backed up in the backup processing sequence; Obtaining a second hash value of the backup blockchain data in the backup data space; If the first hash value is inconsistent with the second hash value, rolling back the backup blockchain data in the backup data space from the current backup node to the previous backup node; The data to be backed up between the previous backup node and the current backup node is backed up again.

3. The method according to claim 1 or 2, characterized in that The step of adding the changed data as data to be backed up to a backup processing sequence includes: Parsing the change data to obtain description information of the change data, where the description information includes one or more of the channel information to which the change data belongs, the name of the smart contract corresponding to the change data, and the timestamp of the change data; The changed data and description information of the changed data are added to the backup processing sequence.

4. The method according to claim 3, characterized in that The step of asynchronously storing the data to be backed up in the backup processing sequence into the backup data space includes: When storing each data to be backed up, obtaining description information of the data to be backed up; Determining a target storage partition for the data to be backed up in the backup data space according to the acquired description information, wherein the backup data space is divided into multiple storage partitions based on one or more of channel information, smart contract name, and timestamp; The data to be backed up is saved in the target storage partition.

5. The method according to claim 1 or 2, characterized in that The step of adding the changed data as data to be backed up to a backup processing sequence includes: Signing the changed data to obtain signature information of the changed data; Adding the changed data and signature information of the changed data to a backup processing sequence; The step of asynchronously storing the data to be backed up in the backup processing sequence into the backup data space includes: For each piece of data to be backed up in the backup processing sequence, verify the data to be backed up using the signature information of the data to be backed up; If the verification is successful, the data to be backed up is stored in the backup data space.

6. The method according to claim 1 or 2, characterized in that Also includes: receiving a data backup request from the target node, where the data backup request is generated by the target node when a storage anomaly occurs; The data to be backed up in the data backup request is added to the backup processing sequence.

7. A blockchain data backup device, characterized in that: include: The first acquisition module is used to obtain the status information of the blockchain data of the target node; A second acquisition module is configured to acquire change data of the blockchain data when the state information indicates that the blockchain data of the target node has changed; An execution module, configured to add the changed data as data to be backed up to a backup processing sequence; A first backup module, configured to asynchronously store the data to be backed up in the backup processing sequence into a backup data space; A sampling module is used to sample the blockchain data after the backup is completed to obtain multiple blockchain sampling data; A calculation module, configured to calculate data credential information based on the plurality of blockchain sampled data; A credential sending module, configured to send the data credential information and the index information of the plurality of blockchain sampled data to the target node; The computing module includes: A construction submodule, configured to construct a Merkle tree based on the plurality of blockchain sampling data; A calculation submodule, configured to calculate the first root hash value of the Merkle tree to obtain the data credential information; Among them, the index information of the blockchain sampling data is used by the target node to obtain multiple target blockchain data from the backup data space. The target node calculates a second root hash value based on the obtained multiple target blockchain data, and verifies the ledger data of the blockchain data by comparing the data certificate information and the second root hash value.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

9. An electronic device, characterized in that: include: a memory having a computer program stored thereon; A processor, configured to execute the computer program in the memory to implement the steps of the method according to any one of claims 1 to 6.

Citation Information

Patent Citations

  • Database snapshot for managing state synchronization

    US20210117385A1