Blockchain-based decentralized data backup method, recovery method and verification method

Abstract

The application relates to a blockchain-based decentralized data backup method, recovery method and verification method. The method comprises the following steps: receiving an encryption request sent by a backup agent of a client; the encryption request carries to-be-backed-up data, and the backup agent of the client acquires the to-be-backed-up data based on a backup instruction sent by a user through a backup control end; in response to the encryption request, a random number is acquired from a parallel chain of a decentralized network, a special encryption key of the current backup task is generated according to a saved master root key of the user and the random number; the to-be-backed-up data is encrypted according to the special encryption key to obtain encrypted backup data; and the encrypted backup data is returned to the backup agent; and the backup agent is used for writing the encrypted backup data into a storage end. By adopting the method, the data leakage risk caused by an attack on a service provider or internal sabotage can be fundamentally eliminated.

Description

Technical Field

[0001] This application relates to the fields of data security and storage technology, and in particular to a blockchain-based decentralized data backup method, recovery method, verification method, as well as a blockchain-based decentralized data backup system, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the deepening of digital transformation, data has become a core asset for enterprises and individuals. Correspondingly, data backup and recovery technologies, as the last line of defense for data security, are becoming increasingly important. Currently, mainstream backup solutions include local backup (disk, tape) and cloud backup services.

[0003] At the security level, modern backup systems generally integrate encryption capabilities to address risks such as ransomware, insider threats, and data breaches. A common advanced model combines backup service providers with a Key Management System (KMS). In this architecture, the backup system manages the lifecycle of encryption keys through the KMS, separating key management from backup operations and improving security. However, such systems are inherently centralized, and their security heavily relies on trust in both the KMS and backup service providers. Summary of the Invention

[0004] Therefore, it is necessary to provide a blockchain-based decentralized data backup method, recovery method, and verification method that enables trustlessness and zero-trust security, as well as a blockchain-based decentralized data backup system, computer equipment, computer-readable storage medium, and computer program product to address the aforementioned technical problems.

[0005] Firstly, this application provides a blockchain-based decentralized data backup method, including:

[0006] The client receives an encryption request sent by its backup agent; the encryption request carries the data to be backed up, and the client's backup agent obtains the data to be backed up based on the backup command sent by the user through the backup control terminal.

[0007] In response to the encryption request, a random number is obtained from the parachain of the decentralized network, and a dedicated encryption key for this backup task is generated based on the user's master root key and the random number.

[0008] The data to be backed up is encrypted using the dedicated encryption key to obtain encrypted backup data;

[0009] The encrypted backup data is returned to the backup agent; the backup agent is used to write the encrypted backup data to the storage terminal.

[0010] In one embodiment, after receiving the encryption request sent by the backup agent of the receiving client, the method further includes:

[0011] In response to the encryption request, the encryption code is obtained from the parachain;

[0012] The step of encrypting the data to be backed up according to the dedicated encryption key to obtain encrypted backup data includes:

[0013] The encryption code is invoked to encrypt the data to be backed up according to the dedicated encryption key, thereby obtaining the encrypted backup data.

[0014] In one embodiment, after receiving the encryption request sent by the backup agent of the receiving client, the method further includes:

[0015] In response to the encryption request, the hash value of the encryption code is obtained from the parachain;

[0016] After encrypting the data to be backed up according to the dedicated encryption key to obtain encrypted backup data, the process further includes:

[0017] Calculate the hash value of the encrypted backup data;

[0018] Construct a backup proof that includes the hash value of the encrypted backup data, the random number, and the hash value of the encrypted code;

[0019] The backup proof is submitted to the parachain of the decentralized network; the parachain collaborates with the relay chain of the decentralized network to perform final confirmation of the backup operation.

[0020] In one embodiment, after submitting the backup proof to the parachain of the decentralized network, the method further includes:

[0021] Receive transaction confirmation messages returned by the parachains of the decentralized network;

[0022] In response to the transaction confirmation message, a backup success message is returned to the backup agent.

[0023] Secondly, this application also provides a blockchain-based decentralized data recovery method, including:

[0024] Receive a recovery command sent by the backup control terminal; the recovery command carries a transaction identifier and storage location;

[0025] Based on the transaction identifier and the storage location, the corresponding encrypted backup data is obtained from the storage terminal;

[0026] Send a decryption request carrying the transaction identifier to the offline encryption worker node; the offline encryption worker node is used to obtain the corresponding backup proof from the parachain of the decentralized network according to the transaction identifier, and decrypt the encrypted backup data based on the backup proof to obtain the decrypted plaintext data;

[0027] Receive the plaintext data returned by the offline encryption working node and write the plaintext data to the recovery target location.

[0028] Thirdly, this application also provides a blockchain-based decentralized data verification method, including:

[0029] Retrieve encrypted backup data from the storage end, and query the finalized backup proof from the parachain of the decentralized network based on the transaction identifier;

[0030] Calculate the hash value of the encrypted backup data, and compare the hash value of the encrypted backup data with the hash value of the encrypted backup data recorded in the backup certificate;

[0031] If the comparison result shows that the two are consistent, the encrypted backup data is decrypted based on the backup proof to obtain the decrypted plaintext data.

[0032] Fourthly, this application also provides a blockchain-based decentralized data backup device, comprising:

[0033] A request receiving unit is used to receive an encrypted request sent by the backup agent of the client; the encrypted request carries the data to be backed up, and the backup agent of the client obtains the data to be backed up based on the backup instruction sent by the user through the backup control terminal;

[0034] A key derivation unit is used to respond to the encryption request by obtaining a random number from a parachain of the decentralized network and generating a dedicated encryption key for this backup task based on the user's master root key and the random number.

[0035] A data encryption unit is used to encrypt the data to be backed up according to the dedicated encryption key to obtain encrypted backup data;

[0036] A data sending unit is used to return the encrypted backup data to the backup agent; the backup agent is used to write the encrypted backup data to the storage terminal.

[0037] Fifthly, this application also provides a blockchain-based decentralized data recovery device, comprising:

[0038] The instruction receiving unit is used to receive recovery instructions sent by the backup control terminal; the recovery instructions carry a transaction identifier and storage location.

[0039] The data acquisition unit is used to acquire the corresponding encrypted backup data from the storage terminal based on the transaction identifier and the storage location;

[0040] The information sending unit is used to send a decryption request carrying the transaction identifier to the offline encryption working node; the offline encryption working node is used to obtain the corresponding backup proof from the parachain of the decentralized network according to the transaction identifier, and decrypt the encrypted backup data based on the backup proof to obtain the decrypted plaintext data.

[0041] The data receiving unit is used to receive the plaintext data returned by the offline encryption working node and write the plaintext data to the recovery target location.

[0042] Sixthly, this application also provides a blockchain-based decentralized data verification device, comprising:

[0043] The data acquisition unit is used to retrieve encrypted backup data from the storage end and to query the finalized backup proof from the parachain of the decentralized network based on the transaction identifier.

[0044] An integrity verification unit is used to calculate the hash value of the encrypted backup data and compare the hash value of the encrypted backup data with the hash value of the encrypted backup data recorded in the backup certificate.

[0045] The data decryption unit is used to decrypt the encrypted backup data based on the backup proof if the comparison result is consistent, so as to obtain the decrypted plaintext data.

[0046] Seventhly, this application also provides a blockchain-based decentralized data backup system, including an offline encrypted working node for the client, a backup agent, a backup control terminal, a decentralized network, and a storage terminal; the decentralized network includes parachains and relay chains, wherein...

[0047] The backup control terminal is used to send backup commands to the backup agent;

[0048] The backup agent is used to obtain the data to be backed up based on the backup instruction and send an encrypted request carrying the data to be backed up to the offline encryption working node.

[0049] The offline encryption worker node is used to respond to the encryption request by obtaining a random number from the parachain of the decentralized network, generating a dedicated encryption key for this backup task based on the user's master root key and the random number; encrypting the data to be backed up using the dedicated encryption key to obtain encrypted backup data; and returning the encrypted backup data to the backup agent.

[0050] The backup agent is used to write the encrypted backup data to the storage terminal.

[0051] Eighthly, this application also provides a computer device including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the method as described in any of the preceding claims.

[0052] Ninthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the preceding claims.

[0053] In a tenth aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the preceding claims.

[0054] The aforementioned blockchain-based decentralized data backup, recovery, and verification methods, along with the blockchain-based decentralized data backup system, computer equipment, computer-readable storage media, and computer program products, involve deploying an offline encrypted work node on the client side. This node receives encryption requests from the client's backup agent and, in response, retrieves a random number from a parachain of the decentralized network. Based on the user's stored master root key and the random number, it generates a dedicated encryption key for the current backup task. The backup data is then encrypted using this dedicated encryption key, resulting in encrypted backup data. This encrypted backup data is returned to the backup agent, which then writes it to the storage terminal. This method, by designing an offline encrypted work node on the client side and using the user's off-chain master root key combined with a unique random number obtained from the blockchain for each backup task, dynamically derives a dedicated encryption key in the client's memory. This off-chain key derivation mechanism ensures that the data key never leaves the client and is inaccessible to the service provider. This achieves true trustlessness and zero-trust security, eliminating the need for users to trust the backup service provider to properly safeguard the key. Service providers have absolutely no access to any of the user's key materials, fundamentally eliminating the risk of data breaches due to attacks on or malicious actions by the service provider. Furthermore, the root of the encryption key lies in the master root key that the user safeguards. As long as the user safeguards their master root key and has access to the public blockchain, they will always have the ability to recover their data, completely eliminating dependence on and lock-in to a single provider, thereby granting users ultimate sovereignty over their data. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 This is an application environment diagram of a blockchain-based decentralized data backup method in one embodiment;

[0057] Figure 2 This is a flowchart illustrating a blockchain-based decentralized data backup method in one embodiment.

[0058] Figure 3 This is a flowchart illustrating a blockchain-based decentralized data recovery method in one embodiment.

[0059] Figure 4 This is a flowchart illustrating a blockchain-based decentralized data verification method in one embodiment.

[0060] Figure 5 This is a component diagram of a blockchain-based decentralized system in one embodiment;

[0061] Figure 6 This is a sequence diagram of a blockchain-based decentralized data backup method in one embodiment;

[0062] Figure 7 This is a sequence diagram of a blockchain-based decentralized data recovery method in one embodiment;

[0063] Figure 8 This is a sequence diagram of a blockchain-based decentralized data verification method in one embodiment;

[0064] Figure 9 This is a block diagram of a blockchain-based decentralized data backup system in one embodiment;

[0065] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0067] It should be noted that the terms "comprising" and "having" as used in this application, and any variations thereof, are intended to cover non-exclusive inclusion.

[0068] It is understandable that the backup methods in related technologies utilize the traditional backup architecture of building an integrated centralized key management service (KMS). In this architecture, although encryption operations are performed on the client side, the authority, legitimacy, and lifecycle management of the keys are entirely controlled by the centralized KMS. Therefore, while this architecture solves the problem of the chaotic key management by the backup software itself, it still has the following issues:

[0069] (1) Risk of centralized root of trust: The security of the entire system depends on absolute trust in KMS and backup service provider. If KMS or backup control terminal is compromised by attackers, attackers may gain control of the keys, resulting in the decryption or permanent destruction of all backup data, which poses a single point of failure and systemic risk.

[0070] (2) Potential “super administrator” risks and backdoor issues: In centralized systems, “super administrators” within the service provider may have the authority to access user keys or data, which brings the risk of internal threats and privacy leaks. Users do not have complete control over their data.

[0071] (3) Vendor lock-in issue: The encryption scheme and key management are deeply tied to the proprietary system of a specific service provider. If users want to migrate to other service providers, the process will be extremely complicated, and they may even be forced to abandon historical backup data because they cannot export the keys.

[0072] To address the aforementioned issues, this application proposes a decentralized data backup method based on blockchain. This method migrates the root of trust of the backup system from a centralized KMS to a decentralized, tamper-proof blockchain network. By combining "on-chain logic" with "off-chain computation," it achieves trustlessness in backup operations, verifiability of the process, and self-sovereignty of user keys.

[0073] The blockchain-based decentralized data backup method provided in this application can be applied to, for example... Figure 1 The application environment shown includes:

[0074] (1) Infrastructure components:

[0075] Backup control unit: Its responsibilities are simplified to pure task orchestration and scheduling.

[0076] Storage side: Serves as a storage repository for encrypted data.

[0077] (2) Client-side components:

[0078] Backup Agent: Responsible for data I / O and communication with the backup control terminal.

[0079] Offline Crypto Worker: As defined in this application, this is a client component and core execution unit tightly integrated with the backup agent. It is responsible for performing all sensitive operations related to cryptography and blockchain interaction. For example, it safeguards the user's master root key (or accesses it securely), interacts with the blockchain, derives keys, executes encryption and decryption code, and submits backup proofs for backup operations.

[0080] (3) Decentralized network components:

[0081] Relay Chain: A centralized coordination chain that provides globally shared security and finality consensus to all parachains connected to it, serving as the system's ultimate trust anchor.

[0082] Parachain: An independent, customizable blockchain whose security is guaranteed by a relay chain, used to run the business logic of this application.

[0083] Pallet: As a module (or smart contract) on a parachain, it refers to a modular runtime component containing specific business logic. Its functions include: (a) storing and providing deterministic cryptographic code (WASM) for encryption and decryption; (b) providing a unique nonce for each backup task; and (c) receiving and immutably recording a cryptographic proof of backup for each backup operation, which includes key metadata such as the hash value of the encrypted backup data, the nonce, and the hash value of the cryptographic code.

[0084] Collator: A parachain node responsible for packaging and submitting proof transactions to the relay chain.

[0085] The backup control terminal 101 communicates with the backup agent 102 of the client via the network. The backup agent 102 communicates with the offline encryption worker node 103 and the storage terminal 105 respectively. The offline encryption worker node 103 also communicates with the parachain 104 in the decentralized network.

[0086] In the application scenario of this application, the user sends a backup task to the backup agent 102 through the backup control terminal 101. The backup agent 102 obtains the data to be backed up according to the backup instruction and sends an encryption request carrying the data to be backed up to the offline encryption worker node 103. The offline encryption worker node 103 responds to the encryption request, obtains a random number from the parachain 104 of the decentralized network, generates a special encryption key for this backup task based on the user's master root key and the random number, and further encrypts the data to be backed up according to the special encryption key to obtain encrypted backup data. The encrypted backup data is then returned to the backup agent 102, and the backup agent 102 writes the encrypted backup data to the storage terminal 105.

[0087] In one exemplary embodiment, such as Figure 2 As shown, a decentralized data backup method based on blockchain is provided, which can be applied to... Figure 1 Taking the offline encryption worker node 103 as an example, the following steps are included:

[0088] Step S210: Receive an encryption request sent by the client's backup agent; the encryption request carries the data to be backed up, and the client's backup agent obtains the data to be backed up based on the backup command sent by the user through the backup control terminal.

[0089] Specifically, a user initiates a backup task through the backup control terminal. The backup control terminal sends a backup instruction for the backup task to the client's backup agent. This backup instruction does not contain any key information. Based on the backup instruction, the backup agent reads the corresponding data to be backed up from the business application / data, generates an encryption request carrying the data to be backed up, and sends the encryption request to the offline encryption worker node, enabling the offline encryption worker node to encrypt the data to be backed up.

[0090] Step S220: In response to the encryption request, obtain a random number from the parachain of the decentralized network, and generate a dedicated encryption key for this backup task based on the saved user's master root key and the random number.

[0091] The master key is the root private key or mnemonic phrase that the user securely stores off-chain and is used to derive all subkeys.

[0092] Specifically, after receiving the encryption request from the backup agent, the offline encryption worker node requests a random number from the parachain of the decentralized network. Then, based on the user's pre-saved root key and the random number obtained from the parachain, it generates a dedicated encryption key for this backup task in memory.

[0093] More specifically, offline encryption work nodes can use deterministic key derivation functions, such as HKDF (HMAC-based Extract-and-Expand Key Derivation Function), to generate dedicated encryption keys by combining the user's master root key and random numbers.

[0094] Step S230: Encrypt the data to be backed up using a dedicated encryption key to obtain encrypted backup data.

[0095] Specifically, after the local key is derived on the offline encryption work node, local encryption can be performed based on the dedicated encryption key. That is, the backup data sent by the backup agent is encrypted using the dedicated encryption key to obtain encrypted backup data.

[0096] Step S240: Return encrypted backup data to the backup agent; the backup agent is used to write the encrypted backup data to the storage end.

[0097] In practice, after the offline encryption worker node completes the encryption of the data to be backed up, it performs further data storage operations, specifically returning the encrypted backup data to the backup agent, which then writes the encrypted backup data to the storage end.

[0098] In the aforementioned blockchain-based decentralized data backup method, an offline encrypted worker node is deployed on the client side. This node receives encryption requests from the client's backup agent and, in response, retrieves a random number from a parachain of the decentralized network. Based on the user's stored master root key and the random number, it generates a dedicated encryption key for the current backup task. The backup data is then encrypted using this dedicated encryption key, resulting in encrypted backup data. This encrypted backup data is returned to the backup agent, which then writes it to storage. This method, by designing an offline encrypted worker node on the client side and using the user's off-chain master root key, combined with a unique random number obtained from the blockchain for each backup task, dynamically derives a dedicated encryption key in the client's memory. This off-chain key derivation mechanism ensures that the data key never leaves the client and is inaccessible to the service provider. This achieves true trustlessness and zero-trust security, eliminating the need for users to trust the backup service provider to properly safeguard their keys. The service provider has absolutely no access to any of the user's key materials, fundamentally eliminating the risk of data leakage due to attacks on or malicious internal actions by the service provider. Furthermore, the root of the encryption key lies in the master root key that the user keeps safe. As long as the user keeps their master root key safe and can access the public blockchain, they will always have the ability to recover their data, completely getting rid of dependence on and lock-in to a single supplier, thereby realizing ultimate sovereignty over the user's data.

[0099] In an exemplary embodiment, after receiving the encryption request sent by the client's backup agent in step S210, the method further includes: in response to the encryption request, obtaining encryption code from the parachain.

[0100] Step S230 encrypts the data to be backed up using a dedicated encryption key to obtain encrypted backup data. This includes: calling encryption code to perform the operation of encrypting the data to be backed up using a dedicated encryption key to obtain encrypted backup data.

[0101] In practice, the offline encryption worker node requests a random number from the parachain of the decentralized network, and simultaneously requests the latest version of the encryption code, such as WASM code. When encrypting the backup data using a dedicated encryption key, the encryption code obtained from the parachain is used, and the derived dedicated encryption key is used to encrypt the backup data, resulting in encrypted backup data.

[0102] In this embodiment, the latest version of the encryption code is obtained from the parachain, and then the data to be backed up is encrypted using a dedicated encryption key. The encryption code on the blockchain is verified by the consensus of the entire network, which can avoid single points of failure or tampering. At the same time, the encryption logic on the blockchain cannot be modified privately after deployment, thereby ensuring that the encryption / decryption logic (encryption code) is transparent and trustworthy. Anyone can audit its security, avoiding backdoors that may exist in proprietary encryption algorithms and improving the transparency and openness of the system.

[0103] Furthermore, traditional backup architectures integrating centralized key management services (KMS) lack independent, cryptographically verifiable capabilities: users cannot independently verify whether their backups were genuine, complete, and completed at a specific point in time. Users can only see log records on the backup service provider's console, which are theoretically tamperable. The only way for users to confirm the validity of a backup is to perform a full recovery, which is costly and lacks real-time capability. Based on this, this application also proposes a cryptographically-level, tamper-proof auditing and verification capability.

[0104] In an exemplary embodiment, after receiving the encryption request sent by the client's backup agent in step S210, the method further includes: in response to the encryption request, obtaining the hash value of the encryption code from the parachain.

[0105] After encrypting the backup data according to the dedicated encryption key in step S230 to obtain the encrypted backup data, the method further includes: calculating the hash value of the encrypted backup data; constructing a backup proof containing the hash value of the encrypted backup data, a random number, and the hash value of the encryption code; submitting the backup proof to the parachain of the decentralized network; and the parachain and the relay chain of the decentralized network cooperating to perform final confirmation of the backup operation.

[0106] Among them, the proof of backup is a piece of data recorded on the blockchain, which is used to cryptographically prove that a certain piece of data was successfully backed up at a specific point in time.

[0107] In practice, after writing the encrypted backup data to the storage terminal, the offline encryption worker node will also perform a proof-on-chain operation, that is, upload the backup proof of the backup operation to the blockchain. Specifically, the backup proof includes the hash value of the encrypted backup data, a random number, and the hash value of the encrypted code. The hash value of the encrypted backup data is obtained by hashing the encrypted backup data after it is obtained; the hash value of the encrypted code is obtained when retrieving the encrypted code from the parachain of the decentralized network. After constructing the backup proof, it is submitted to the parachain of the decentralized network. The parachain collector packages the transaction and submits it to the relay chain. The offline encryption worker node waits for and confirms that the block in the relay chain containing the transaction has reached finality. At this point, the backup operation obtains an immutable, publicly verifiable completion certificate.

[0108] In some embodiments, for high-frequency backup scenarios, to reduce on-chain costs, it is not necessary to submit a transaction for each backup. Technologies such as Merkle trees can be used to aggregate multiple backup proofs over a period of time into a single Merkle root off-chain, and only this Merkle root is submitted to the blockchain, significantly reducing transaction fees and frequency.

[0109] Furthermore, in an exemplary embodiment, after submitting the backup proof to the parachain of the decentralized network, the method further includes: receiving a transaction confirmation message returned by the parachain of the decentralized network; and in response to the transaction confirmation message, returning a message indicating successful backup to the backup agent.

[0110] Specifically, after the offline encryption worker node submits the backup proof to the parachain of the decentralized network, the parachain returns transaction confirmation information. After receiving the transaction confirmation information, the offline encryption worker node reports to the backup agent, that is, returns a message of successful backup to the backup agent. The backup agent then reports the task completion to the backup control terminal.

[0111] In this embodiment, a backup proof is constructed by constructing a hash value containing the encrypted backup data, a random number, and the hash value of the encrypted code. This backup proof is then submitted to a parachain of the decentralized network. The parachain collaborates with the relay chain of the decentralized network to finalize the backup operation. This ensures that every successful backup has a "receipt" (on-chain proof) that is ultimately confirmed by the globally distributed network. Users can verify the integrity and existence of backups independently and at any time without performing costly recovery operations, greatly enhancing data trustworthiness and compliance auditing capabilities. Furthermore, it enhances resistance to high-level threats (such as ransomware): even if an attacker completely destroys the backup service provider's control and storage ends, as long as the user has other copies of the encrypted data (or can recover it from the damaged storage), combined with the on-chain immutable proof and their own master root key, the data can still be recovered.

[0112] In one exemplary embodiment, such as Figure 3 As shown, a decentralized data recovery method based on blockchain is also provided, which can be applied to... Figure 1 Taking Backup Agent 102 as an example, the following steps are included:

[0113] Step S310: Receive a recovery command sent by the backup control terminal; the recovery command carries the transaction identifier and storage location;

[0114] Step S320: Obtain the corresponding encrypted backup data from the storage terminal based on the transaction identifier and storage location;

[0115] Step S330: Send a decryption request carrying the transaction identifier to the offline encryption worker node; the offline encryption worker node is used to obtain the corresponding backup proof from the parachain of the decentralized network according to the transaction identifier, and decrypt the encrypted backup data based on the backup proof to obtain the decrypted plaintext data.

[0116] Step S340: Receive plaintext data returned by the offline encryption worker node and write the plaintext data to the recovery target location.

[0117] The blockchain-based decentralized data recovery method provided in this embodiment enables users to completely operate independently of backup service providers, using only their own master root key and publicly available backup proof on the blockchain to independently verify the integrity of backup data and derive the correct decryption key to recover the data.

[0118] In one exemplary embodiment, such as Figure 4 As shown, a decentralized data verification method based on blockchain is also provided, which can be applied to... Figure 1 Taking the user's client as an example, the explanation includes the following steps:

[0119] Step S410: Obtain encrypted backup data from the storage end, and query the finalized backup proof from the parachain of the decentralized network based on the transaction identifier;

[0120] Step S420: Calculate the hash value of the encrypted backup data and compare it with the hash value of the encrypted backup data recorded in the backup certificate;

[0121] Step S430: If the comparison result is consistent, the encrypted backup data is decrypted based on the backup proof to obtain the decrypted plaintext data.

[0122] Specifically, the user retrieves encrypted backup data from storage and queries the corresponding, finally confirmed backup proof from the parachain based on the transaction identifier. Integrity verification is then performed. Specifically, the user can use a verification tool to calculate the hash value of the retrieved encrypted backup data locally and compare it with the hash value of the encrypted backup data recorded in the backup proof. If they match, it proves that the encrypted backup data has not been tampered with after the backup was completed. The user-side tool (including the logic of the offline encryption worker node) then uses its stored master root key and a random number obtained from the on-chain proof to regenerate the correct dedicated encryption key in memory using the exact same derivation algorithm as during backup. Using the reconstructed dedicated encryption key and the encryption code obtained from the chain and verified by the hash value of the encryption code, the encrypted backup data is decrypted to recover the plaintext data.

[0123] The data verification method provided in this embodiment allows users to obtain encrypted backup data from the storage terminal and query the finalized backup proof from the parachain of the decentralized network based on the transaction identifier. The hash value of the encrypted backup data is calculated and compared with the hash value of the encrypted backup data recorded in the backup proof. If the comparison result is consistent, the encrypted backup data is decrypted based on the backup proof to obtain the decrypted plaintext data. This allows users to completely operate independently of the backup service provider, using only their own master root key and the publicly available backup proof on the chain to independently verify the integrity of backup data and derive the correct decryption key to recover the data.

[0124] To more clearly illustrate the embodiments of this application, the following description, in conjunction with the accompanying drawings, further explains the blockchain-based decentralized data backup, recovery, and verification method provided in this application.

[0125] refer to Figure 5 This is a component diagram of a blockchain-based decentralized system provided in one embodiment. Figure 6 A sequence diagram of a backup method provided in one embodiment includes the following steps:

[0126] 1. Users configure / initiate backup tasks in the backup control terminal (Web console).

[0127] 2. The backup control terminal (Web console) issues backup commands to the client's backup agent through the task scheduling engine.

[0128] 3. The backup agent reads the data to be backed up from the business application / data and sends it to the offline encrypted worker node to request encryption.

[0129] 4-5. The offline encryption worker node requests the encryption code, its hash value, and a random number from the parachain. Operations are performed in memory: based on the saved user's master root key and the random number, a dedicated encryption key (DEK) for this backup task is generated, and the encryption code is loaded.

[0130] 6-7. Encrypt the data to be backed up according to the encryption logic of the dedicated encryption key and encryption code to obtain encrypted backup data, and calculate the hash value of the encrypted backup data.

[0131] 8. Return encrypted backup data to the backup agent.

[0132] 9-11. The backup agent writes the encrypted backup data to the storage terminal, receives a message indicating successful write, and notifies the offline encryption worker node to request the submission of backup proof.

[0133] 12. Offline encrypted worker nodes construct backup proofs containing the hash value of the encrypted backup data, a random number, and the hash value of the encrypted code, and submit the backup proofs to the parachain of the decentralized network.

[0134] 13-16. Parachains and the relay chain undergo final confirmation. This includes: the parachain collector packages transactions and generates a new parachain block, submits the block header to the relay chain for verification and inclusion, the relay chain validator verifies and includes the parachain block header into a new relay chain block, the finality formula is executed, and after a vote by 2 / 3+ validators, the relay chain block is finally confirmed, and the finality proof is broadcast to the parachains.

[0135] 17. Parachains return transaction confirmation messages to offline encrypted worker nodes.

[0136] 18. In response to the transaction confirmation message, the offline encrypted worker node returns a backup success message to the backup agent.

[0137] 19. The backup agent reports the task success to the backup control terminal.

[0138] Figure 7 A sequence diagram of a blockchain-based decentralized data recovery method provided in one embodiment includes the following steps:

[0139] 20. The user initiates a recovery task (specifying the backup set) on the backup control terminal.

[0140] 21-22. The backup control terminal searches for the parachain proof (transaction ID) corresponding to the backup set in the metadata and issues a recovery instruction (including transaction ID and storage location) to the backup agent.

[0141] 23-24. In response to the recovery command, the backup agent retrieves the corresponding encrypted backup data from the storage device.

[0142] 25. The backup agent sends a decryption request carrying the transaction ID to the offline encrypted worker node.

[0143] 26-27. The offline encryption worker node queries the finally confirmed on-chain proof record based on the transaction ID to obtain the backup proof. Then, it performs the following operations in memory: derives a dedicated encryption key using the user's master root key and the random number in the backup proof; and retrieves the encryption code from the parachain based on the hash value of the encryption code in the backup proof.

[0144] 28-29. Use the derived dedicated encryption key and encryption code to decrypt the data to be backed up, obtain the decrypted plaintext data, and return it to the backup agent.

[0145] 30-31. The backup agent writes plaintext data to the recovery target location and reports the recovery task to the backup control terminal.

[0146] Figure 8 A sequence diagram of a blockchain-based decentralized data verification method provided in one embodiment includes the following steps:

[0147] 32-34. The user's client (independently) retrieves encrypted backup data from the storage, queries the finally confirmed on-chain proof record based on the transaction ID, obtains the backup proof, and starts the verification tool locally.

[0148] 35. Use your own master root key and the random number in the backup proof to regenerate the key.

[0149] 36. Recalculate the hash value of the encrypted backup data retrieved from the storage. If the locally calculated hash value is the same as the hash value of the on-chain backup proof, it indicates that the data integrity verification was successful.

[0150] 37. Decrypt the encrypted backup data using the derived dedicated encryption key and the encryption code in the backup certificate.

[0151] This method has the following features: (1) Introducing an off-chain key derivation mechanism: Design an offline crypto worker node, which uses the master seed stored off-chain by the user, combined with a unique random number (Nonce) obtained from the blockchain for each backup task, to dynamically derive the data encryption key in the client's memory. This process ensures that the data key never leaves the client and cannot be accessed by the service provider. (2) Creating an on-chain encryption logic and proof module: Deploy a proof and logic module on the blockchain (such as a parachain), which is responsible for: (a) storing and providing deterministic encryption code (WASM) for encryption and decryption; (b) providing a unique random number (Nonce) for each backup task; (c) receiving and recording the cryptographic backup proof (Proof-of-Backup) for each backup operation in an immutable manner, which contains key metadata such as the hash value of the encrypted backup data, the random number, and the hash value of the encryption code. (3) Restructuring the Backup and Verification Process: During backup, offline worker nodes obtain on-chain encrypted code and random numbers, derive keys to encrypt data, and then submit the backup proof to the chain, waiting for the proof to be finalized by the relay chain, thereby obtaining a cryptographically-level, irreversible completion certificate. During recovery or verification, users can completely operate independently of the backup service provider, relying solely on their own master root key and the publicly available backup proof on the chain to independently verify the integrity of the backup data and derive the correct decryption key to recover the data.

[0152] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0153] Based on the same inventive concept, this application also provides a blockchain-based decentralized data backup system for implementing the blockchain-based decentralized data backup method described above. The solution provided by this system is similar to the implementation described in the above method; therefore, the specific limitations of one or more blockchain-based decentralized data backup system embodiments provided below can be found in the limitations of the blockchain-based decentralized data backup method described above, and will not be repeated here.

[0154] In one exemplary embodiment, such as Figure 9 As shown, a blockchain-based decentralized data backup system is provided, including a backup control terminal 910, a client-side backup agent 920, an offline encrypted worker node 930, a decentralized network 940, and a storage terminal 950; the decentralized network includes parachains and relay chains, wherein...

[0155] Backup control terminal 910 is used to send backup commands to the backup agent;

[0156] Backup Agent 920 is used to obtain the data to be backed up based on backup instructions and send an encrypted request carrying the data to be backed up to the offline encrypted worker node;

[0157] Offline encryption worker node 930 is used to respond to encryption requests, obtain random numbers from the parachain of decentralized network 940, generate a dedicated encryption key for this backup task based on the saved user's master root key and the random number, encrypt the data to be backed up using the dedicated encryption key to obtain encrypted backup data, and return the encrypted backup data to the backup agent;

[0158] Backup agent 920 is used to write encrypted backup data to storage terminal 950.

[0159] In one embodiment, the offline encryption worker node 930 is also configured to, in response to an encryption request, obtain encryption code from the parachain; invoke the encryption code to perform an operation to encrypt the data to be backed up according to a dedicated encryption key, thereby obtaining encrypted backup data.

[0160] In one embodiment, the offline encryption worker node 930 is further configured to, in response to an encryption request, obtain the hash value of the encryption code from the parachain; calculate the hash value of the encryption backup data; construct a backup proof containing the hash value of the encryption backup data, a random number, and the hash value of the encryption code; submit the backup proof to the parachain of the decentralized network; and have the parachain and the relay chain of the decentralized network collaborate to perform final confirmation of the backup operation.

[0161] In one embodiment, the offline encrypted worker node 930 is also configured to receive transaction confirmation messages returned by the parachain of the decentralized network; and in response to the transaction confirmation messages, return a backup success message to the backup agent.

[0162] The modules in the aforementioned blockchain-based decentralized data backup system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the corresponding operations of each module.

[0163] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data required for data backup, recovery, and verification. The I / O interfaces allow the processor to exchange information with external devices. The communication interface allows communication with external terminals via a network connection. When executed by the processor, the computer program implements a blockchain-based decentralized data backup method.

[0164] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0165] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0166] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0167] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0168] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0169] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0170] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0171] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A decentralized data backup method based on blockchain, characterized in that, The method, applied to offline encrypted worker nodes deployed on a client, includes: The client receives an encryption request sent by its backup agent; the encryption request carries the data to be backed up, and the client's backup agent obtains the data to be backed up based on the backup command sent by the user through the backup control terminal. In response to the encryption request, a random number is obtained from the parachain of the decentralized network, and a dedicated encryption key for this backup task is generated based on the user's master root key and the random number. The data to be backed up is encrypted using the dedicated encryption key to obtain encrypted backup data; The encrypted backup data is returned to the backup agent; the backup agent is used to write the encrypted backup data to the storage terminal.

2. The method according to claim 1, characterized in that, After receiving the encryption request sent by the backup agent of the receiving client, the method further includes: In response to the encryption request, the encryption code is obtained from the parachain; The step of encrypting the data to be backed up according to the dedicated encryption key to obtain encrypted backup data includes: The encryption code is invoked to encrypt the data to be backed up according to the dedicated encryption key, thereby obtaining the encrypted backup data.

3. The method according to claim 1, characterized in that, After receiving the encryption request sent by the backup agent of the receiving client, the method further includes: In response to the encryption request, the hash value of the encryption code is obtained from the parachain; After encrypting the data to be backed up according to the dedicated encryption key to obtain encrypted backup data, the process further includes: Calculate the hash value of the encrypted backup data; Construct a backup proof that includes the hash value of the encrypted backup data, the random number, and the hash value of the encrypted code; The backup proof is submitted to the parachain of the decentralized network; the parachain collaborates with the relay chain of the decentralized network to perform final confirmation of the backup operation.

4. The method according to claim 3, characterized in that, After submitting the backup proof to the parachain of the decentralized network, the process further includes: Receive transaction confirmation messages returned by the parachains of the decentralized network; In response to the transaction confirmation message, a backup success message is returned to the backup agent.

5. The method according to claim 1, characterized in that, The method further includes: Receive a decryption request carrying a transaction identifier sent by the client's backup agent; the transaction identifier is obtained by the client's backup agent from a recovery command sent by the backup control terminal; Based on the transaction identifier, the corresponding backup proof is obtained from the parachain of the decentralized network. Based on the backup proof, the encrypted backup data is decrypted to obtain the decrypted plaintext data. The plaintext data is returned to the client's backup agent, causing the client's backup agent to write the plaintext data to the recovery target location.

6. A decentralized data backup system based on blockchain, characterized in that, This includes offline encrypted worker nodes for the client, backup agents, backup control terminals, a decentralized network, and storage terminals; the decentralized network includes parachains and relay chains, wherein... The backup control terminal is used by users to send backup commands to the backup agent; The backup agent is used to obtain the data to be backed up based on the backup instruction and send an encrypted request carrying the data to be backed up to the offline encryption working node. The offline encryption worker node is used to respond to the encryption request by obtaining a random number from the parachain of the decentralized network, generating a dedicated encryption key for this backup task based on the user's master root key and the random number; encrypting the data to be backed up using the dedicated encryption key to obtain encrypted backup data; and returning the encrypted backup data to the backup agent. The backup agent is used to write the encrypted backup data to the storage terminal.

7. The system according to claim 6, characterized in that, The user's client is also used to independently retrieve encrypted backup data from the storage end, and to query the finalized backup proof from the parachain of the decentralized network based on the transaction identifier; Calculate the hash value of the encrypted backup data, and compare the hash value of the encrypted backup data with the hash value of the encrypted backup data recorded in the backup certificate; if the comparison result is consistent, then decrypt the encrypted backup data based on the backup certificate to obtain the decrypted plaintext data.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images