Digital asset protection method and system based on distributed storage

Abstract

The invention relates to the technical field of data storage and security technologies, and particularly discloses a digital asset protection method and system based on distributed storage. The system comprises a data preprocessing module, a distributed storage network module, a dynamic verification module and a recovery and auditing module, and by performing blocking, encryption and redundancy storage on digital assets and combining an improved consensus algorithm and a periodic verification mechanism, dynamic verification of data integrity and automatic exception repair are achieved, and the data integrity recovery and auditing efficiency is improved. And resource allocation is optimized based on policy management and a node reputation mechanism, so that a closed-loop digital asset full-life-cycle protection system is constructed, and the data security and reliability are improved.

Description

Technical Field

[0001] This invention belongs to the field of data storage and security technology, specifically relating to a method and system for protecting digital assets based on distributed storage. Background Technology

[0002] Distributed storage technology, as an important branch of modern information technology, achieves high availability, scalability, and fault tolerance by distributing data across multiple independent nodes. In key areas such as finance, the Internet of Things, and intellectual property protection, distributed storage systems have become core infrastructure supporting large-scale digital asset management.

[0003] Among these, distributed storage-based digital asset protection methods aim to ensure the integrity, authenticity, and immutability of digital asset data during storage and transmission. These methods typically rely on cryptographic principles and distributed consensus mechanisms to build a trusted data storage environment.

[0004] Existing technologies commonly employ traditional data integrity verification methods such as hash verification; however, these methods have limitations. Hash verification can only detect whether data has been tampered with when it is accessed, but it cannot provide proof of immutability with timestamps and authentication, and the storage of a single hash value itself may become a target for attack.

[0005] In a purely distributed storage architecture, digital asset data is at risk of being tampered with or permanently lost due to potential malicious behavior by nodes or failures such as network partitions.

[0006] Furthermore, existing methods lack a mechanism to deeply integrate data integrity proof with the characteristics of distributed systems, making it difficult to achieve full lifecycle protection of digital assets while maintaining the advantages of system decentralization.

[0007] Therefore, how to build an efficient, reliable, and tamper-proof digital asset protection mechanism in a distributed storage environment has become an urgent technical challenge. Summary of the Invention

[0008] The present invention aims to provide a digital asset protection method and system based on distributed storage, so as to solve the technical problem that the existing technology lacks an efficient, reliable and tamper-proof full life cycle protection mechanism for digital assets in a distributed storage environment.

[0009] This invention provides a digital asset protection system based on distributed storage, which includes a data preprocessing module, a distributed storage network module, a dynamic verification module, and a recovery and auditing module.

[0010] The data preprocessing module receives raw digital asset data, performs block processing and encryption encoding on the data, and generates a set of data blocks and corresponding metadata.

[0011] The distributed storage network module consists of multiple storage nodes, which are used to store a set of data blocks according to a preset redundancy strategy and maintain a distributed ledger based on an improved consensus algorithm. This ledger records the storage location information and integrity verification records of all data blocks.

[0012] The dynamic verification module periodically or based on triggered events sends challenge requests to storage nodes and collects data ownership proofs from the nodes. The verification algorithm then verifies the proofs to confirm data integrity.

[0013] When the recovery and auditing module detects data corruption or loss, it initiates a data repair process and records all verification and repair operations to the audit log.

[0014] Furthermore, the data preprocessing module performs the following block processing procedure: the original digital asset data is divided into multiple fixed-size data blocks, the cryptographic hash value of each data block is calculated as a data fingerprint, and the data block set is encoded using an erasure coding algorithm to generate a data block set containing the original data blocks and the verification data blocks.

[0015] Metadata includes the data fingerprint, data block index, erasure coding parameters, and data owner identifier for each data block.

[0016] Furthermore, in the distributed storage network module, the execution process of the improved consensus algorithm is as follows: storage nodes participating in the consensus are assigned different voting weights based on their storage contribution and historical verification pass rate. In each storage cycle, the nodes vote on the storage transactions of the data blocks generated in the current cycle. When a transaction receives a weighted vote of more than a preset threshold, the transaction is confirmed and recorded in a new block of the distributed ledger.

[0017] Each block header in a distributed ledger contains the hash value of the previous block, a timestamp, and the Merkle root hash of all stored transactions in the current block.

[0018] Furthermore, the verification process of the dynamic verification module is as follows: the verification module generates a random number as a challenge value and sends the challenge value to multiple target nodes that store specific data blocks. The target nodes use their stored data blocks and challenge values ​​as input to run the specified proof generation function, generate a data possession proof, and return it to the verification module.

[0019] The verification module uses the corresponding data fingerprint stored locally and the received challenge value to run the verification function and verify the returned proof. If the verification passes, the data is deemed complete; otherwise, the recovery and auditing module is triggered.

[0020] Furthermore, the proof generation function employs an algebraic structure based on bilinear mapping, taking data blocks, challenge values, and node private keys as inputs, and outputting a proof in the form of a digital signature.

[0021] The verification function uses the public key, data fingerprint, and challenge value of the corresponding node to determine the data ownership by verifying the validity of the digital signature.

[0022] Furthermore, the data repair process of the recovery and auditing module is as follows: when the dynamic verification module detects that a data block is lost or damaged, the recovery and auditing module first locates other available nodes in the distributed ledger that store a copy of the data block or related verification blocks. Then, according to the erasure coding parameters, it downloads a sufficient number of data blocks or verification blocks from the available nodes, reconstructs the original data block through the erasure coding decoding algorithm, and finally stores the reconstructed data block to the new available node and updates the corresponding storage location information in the distributed ledger.

[0023] Furthermore, the audit log recording process is as follows: all challenge requests initiated by the dynamic verification module, received proofs, verification results, and data repair operations performed by the recovery and audit module are encapsulated as audit events. These audit events are digitally signed and broadcast to the distributed storage network module, and after consensus confirmation, they are recorded in a specific audit block of the distributed ledger.

[0024] Each audit event includes the event type, the identifier of the data block involved, the operation timestamp, the execution node identifier, and the operation result status.

[0025] Furthermore, the system also includes a policy management module, which allows data owners to set data protection policies, including the number of data redundancies, the frequency of verification challenges, the damage threshold that triggers data recovery, and the reputation admission conditions for storage nodes.

[0026] The policy management module compiles data protection policies into executable code and deploys them to the distributed storage network module, ensuring that the operation of each module conforms to the preset policies.

[0027] Furthermore, the reputation admission criteria for storage nodes are dynamically evaluated based on the node's historical online rate, data verification pass rate, and participation in consensus voting. The evaluation results are recorded in the distributed ledger in the form of reputation scores.

[0028] The policy management module periodically checks the reputation score of nodes. If the score is less than the preset admission threshold, the node is marked as an untrusted node, and the data migration process is triggered to migrate the data blocks stored on the node to nodes with qualified reputation.

[0029] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0030] 1. This invention constructs a closed-loop digital asset protection system by integrating multiple modules such as data preprocessing, distributed storage, dynamic verification, and recovery auditing. This system not only enhances data reliability and confidentiality during the data storage stage through block-based, encrypted, and redundant storage, but also promptly detects data anomalies through periodic dynamic verification in the post-storage stage. It automatically triggers a data repair mechanism when anomalies occur, thereby achieving continuous protection of digital assets throughout their entire lifecycle and reducing the risk of data loss or tampering due to node failures or malicious attacks.

[0031] 2. The improved consensus algorithm employed in this invention incorporates a node's storage contribution and verification history into the voting weight calculation, giving trusted nodes greater say in the consensus process. This enhances the overall security and stability of the distributed storage network. Combined with a dynamic verification mechanism based on cryptographic principles, the system can generate highly secure data ownership proofs and provide tamper-proof verification records, offering an auditable and traceable guarantee for the integrity of digital assets.

[0032] 3. The policy management module and reputation mechanism introduced in this invention enable the system to flexibly configure policies based on the importance and security requirements of data assets, and to quantitatively evaluate and manage the behavior of storage nodes. This design achieves fine-grained control of protection policies and adaptive optimization of resources, ensuring long-term reliable operation and efficient maintenance of the system in complex and ever-changing distributed environments. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the overall technical solution architecture of the digital asset protection system based on distributed storage proposed in this invention;

[0034] Figure 2 This is a schematic diagram of the core principle framework of the improved consensus algorithm in this invention;

[0035] Figure 3 This is a logical flowchart of data preprocessing and dynamic verification in this invention;

[0036] Figure 4 This is a schematic diagram of the multi-level interaction relationship and data flow between the storage node and the verification module in this invention;

[0037] Figure 5This is a data repair process and audit event recording framework diagram of the recovery and auditing module in this invention; Detailed Implementation

[0038] This embodiment details the specific technical implementation of a digital asset protection system based on distributed storage. Please refer to the appendix. Figure 1 The system consists of a data preprocessing module, a distributed storage network module, a dynamic verification module, a recovery and auditing module, and a policy management module. These modules work together to form a closed-loop protection system for digital assets throughout their entire lifecycle, from data entry to long-term maintenance.

[0039] The data preprocessing module is the entry point for the system to process raw digital assets. This module receives raw digital asset data streams from users or upstream systems. Raw digital asset data can be any form of electronic file or data stream, ranging in size from several kilobytes to several terabytes.

[0040] The data preprocessing module first performs format analysis and validity verification on the input data to ensure that the data conforms to the system processing specifications.

[0041] Subsequently, the module initiates the chunking process. This process divides the complete raw digital asset data into multiple fixed-size blocks. The block size can be configured according to the policy management module, typically 1MB, 4MB, or 16MB. For any data portion smaller than a complete block, a standard padding algorithm is used to ensure all blocks have a uniform size.

[0042] After the data is divided into blocks, the data preprocessing module calculates a cryptographic hash value for each block. The hash algorithm can be SHA256, SHA512, or SM3, and the result serves as the unique data fingerprint for that block. The data fingerprint length is 256 bits or 512 bits, depending on the chosen algorithm.

[0043] Next, the module initiates the erasure coding sub-process. This sub-process takes all data blocks as input and applies a specific erasure coding algorithm for encoding. The encoding process generates two sets of outputs: one set of original data blocks and the other set of parity data blocks. Together, these sets constitute the data block set used for distributed storage.

[0044] Erasure coding parameters include the number of data blocks K and the number of parity blocks M, and their ratio determines the system's redundancy level and recovery capability. For example, when K is 10 and M is 4, the system can tolerate the simultaneous loss of up to 4 arbitrary data blocks or parity blocks and still fully recover the original data.

[0045] After the encoding process is complete, the data preprocessing module generates metadata corresponding to the set of data blocks. Metadata is a structured data record whose fields include the data fingerprint of each data block, the index number of the data block in the original file, the erasure coding algorithm used, the specific values ​​of K and M, the unique identifier of the data owner, and the timestamp of data preprocessing. The metadata itself is also hashed and digitally signed to ensure its integrity and trustworthy origin.

[0046] Finally, the data preprocessing module outputs the data block set and metadata to the distributed storage network module for subsequent storage.

[0047] The distributed storage network module is responsible for the persistent storage of data block sets and the maintenance of their global state. Please refer to the appendix. Figure 1 This module consists of a physically distributed network of storage nodes. Each storage node is an independent computing and storage entity, equipped with a processor, memory, network interface, and high-capacity storage device.

[0048] Storage nodes are interconnected via the Internet or a dedicated network.

[0049] Internally, the module maintains a distributed ledger based on an improved consensus algorithm. This distributed ledger is an append-only chained data structure that records all transactions related to data block storage. Upon receiving a set of data blocks and metadata from the data preprocessing module, the distributed storage network module initiates a data storage transaction. This transaction involves allocating and storing specific data blocks or checksum blocks on one or more eligible storage nodes.

[0050] The selection of storage nodes follows a preset redundancy strategy defined by the policy management module. This strategy typically requires each data block or parity block to have copies stored on multiple nodes distributed across physical locations or network topologies. The typical number of redundancies is 3 or 5. Details of the storage transaction, including the data block identifier, storage node identifier, storage time, and data block type, are encapsulated into a transaction record.

[0051] An improved consensus algorithm is used to confirm the network-wide consistency of these transaction records. Please refer to the appendix. Figure 2 The improved consensus algorithm is executed jointly by the storage nodes participating in the consensus process within the network. Each storage node is assigned a dynamic voting weight based on its storage contribution and historical verification pass rate. The storage contribution is calculated comprehensively based on the total amount of data currently stored by the node, the storage duration, and the data access frequency.

[0052] The historical verification pass rate is derived from the data integrity verification reports periodically released by the dynamic verification module. The calculation of voting weights is a normalization process, ensuring that the sum of the weights of all nodes is 1. Each storage cycle, such as every 10 seconds or every minute, involves a node voting on all data block storage transactions generated within the current cycle.

[0053] The voting process is concurrent, with each node independently judging the validity of each transaction. The criteria for judgment include whether the transaction format is correct, whether the storage node has sufficient storage space, and whether the storage node's reputation meets the requirements. Nodes digitally sign their voting decisions using their private key.

[0054] After the voting concludes, each node broadcasts its signed voting results. Each transaction needs to receive more than a preset threshold, such as 67% of the total voting weight, to be considered valid and confirmed.

[0055] Confirmed transactions are bundled together to form a new block. The construction of a new block includes generating a block header and storing a list of transactions. The block header contains the hash value of the previous block, calculated using the SHA256 algorithm, and is 256 bits long.

[0056] The block header also includes a timestamp accurate to milliseconds, and a Merkle root hash of all storage transactions within the current block. The Merkle root hash is calculated by performing a binary hash tree on the transaction list and is used to quickly verify the integrity of the block content. The new block is broadcast to all storage nodes via a peer-to-peer network, and each node appends it to its local copy of the ledger after verifying the block's validity.

[0057] Through this process, the distributed storage network module not only securely stores data blocks, but also maintains an immutable distributed ledger that records the history of all storage operations.

[0058] The dynamic verification module is responsible for continuously monitoring data integrity. This module runs independently or as a service process on a trusted node. Its core function is to periodically, or based on specific triggered events, challenge the storage node to verify whether it indeed holds and has access to the specified data block.

[0059] Please refer to the attached document. Figure 3 The dynamic verification module's workflow begins with the challenge generation subprocess. This subprocess is automatically activated based on a preset strategy, such as every 24 hours or when the system load is below a certain threshold.

[0060] The module first randomly selects a batch of data block identifiers to be verified from the distributed ledger. For each selected data block identifier, the module generates a cryptographically secure random number as a challenge value. The challenge value is typically 128 bits or 256 bits long to ensure its unpredictability.

[0061] Subsequently, the challenge distribution sub-process is initiated. The module locates all target nodes storing the specific data block based on information recorded in the distributed ledger. Location information includes the node's network address. The dynamic verification module sends the challenge value to each target node via a secure network channel, such as a TLS-based encrypted connection. The message sent explicitly specifies the identifier of the data block being challenged.

[0062] Please refer to the attached document. Figure 4 Upon receiving the challenge request, the target node immediately enters the proof generation phase. The node first retrieves the challenged data block from its local storage. This retrieval process includes file system access and data reading. After confirming the data block is accessible, the node runs the proof generation function. The proof generation function employs an algebraic structure based on a bilinear mapping. The function's input parameters include three parts: the complete data block content, the received challenge value, and the node's own private key.

[0063] The function's execution involves specific algebraic operations, ultimately outputting a digital signature-based proof. This proof is a fixed-length string, such as 512 bits, that condenses the association between the data block content and the challenge value, and can only be generated using the node's private key.

[0064] The node then returns this proof to the dynamic verification module via the network. After issuing the challenge, the dynamic verification module enters the proof collection and verification phase. The module sets a timeout window, for example, 30 seconds, to wait for responses from all target nodes.

[0065] For each returned proof, the module initiates a verification subprocess. The verification subprocess runs a verification function. The verification function takes three parts as input: the public key of the corresponding node, which can be obtained from a distributed ledger or a pre-built certificate store; the data fingerprint of the corresponding data block stored locally; and the challenge value initially sent.

[0066] The verification function checks the validity of the digital signature-based proof through specific calculations. The core of the verification process is verifying whether the following mathematical relationship holds: the proof was generated by the correct private key based on the correct data block and challenge value. The verification algorithm ensures that the generated proof passes verification only if the node actually holds the complete and correct data block. The verification function outputs a boolean result, true or false.

[0067] For each challenged data block, the dynamic verification module needs to collect and verify the proofs from all replica nodes storing that data block.

[0068] If the proofs of all required copies pass verification, the data block is considered to be in an intact state. If the proof verification of any required copy fails or times out without response, the data block is considered to have a potential risk, and an anomaly alarm signal is immediately sent to the recovery and auditing module. The alarm signal includes the identifier of the abnormal data block, the identifier of the failed node, and a timestamp.

[0069] The recovery and auditing module is responsible for performing repair operations when data anomalies are detected, and for logging all critical system events for auditing purposes. Please refer to the appendix. Figure 5 When the recovery and auditing module receives an alarm signal from the dynamic verification module regarding the loss or corruption of a certain data block, it immediately activates the data repair process.

[0070] The first step in the remediation process is to locate available resources. The module queries the distributed ledger to identify other online and reputable nodes that store the anomalous data block, or nodes that store the relevant verification data block, based on the identifier of the anomalous data block. The query criteria include the node's online status and reputation score.

[0071] The second step is data download and reconstruction. The recovery and auditing module calculates the minimum number of data blocks required to reconstruct the original data blocks based on the erasure coding parameters. For example, with a configuration of K = 10 and M = 4, only 10 blocks need to be successfully downloaded from the available original data blocks or checksum blocks. The module concurrently initiates data download requests to these available nodes.

[0072] The download process employs a chunked transmission and verification mechanism to ensure the integrity and correctness of data transmission. Once a sufficient number of data blocks have been collected, the module initiates the erasure coding decoding algorithm.

[0073] The decoding algorithm uses the collected data blocks and known erasure coding parameters to perform inverse mathematical operations, accurately reconstructing the lost or corrupted original data blocks. The reconstruction process takes place in memory, and immediately after completion, the hash value of the reconstructed data block is calculated and compared with the original data fingerprint recorded in the metadata to ensure the correctness of the reconstruction.

[0074] The third step is re-storage and update. The recovery and auditing module selects one or more suitable nodes from the currently available, reputable storage node pool to store the newly reconstructed data blocks. The selection strategy considers the load balancing and geographical distribution of the nodes. Subsequently, the module initiates a data storage transaction to store the reconstructed data blocks on the newly selected nodes.

[0075] The storage transaction is submitted to the distributed storage network module, confirmed by the improved consensus algorithm, and recorded in a new block of the distributed ledger, thereby updating the storage location information of the data block. Simultaneously, the recovery and auditing module continuously runs the audit log recording subprocess.

[0076] This subprocess captures specific operations occurring within the system and encapsulates them as audit events. The sources of audit events include every challenge request initiated by the dynamic verification module, every data possession certificate received, the result of every verification operation, and every data repair operation performed by the recovery and audit module itself. Each audit event is a structured record.

[0077] The event log includes an event type field to distinguish different operations such as challenge, proof, verification, and repair; a data block identifier field; an operation timestamp field accurate to milliseconds; an identifier field for the node or module that performed the operation; and an operation result status field, such as success, failure, or timeout. Before logging, each audit event is digitally signed by the module or node that generated it to ensure the authenticity and non-repudiation of the event.

[0078] The signed audit events are broadcast to the distributed storage network modules. Upon receiving these audit events, the storage nodes in the network treat them as a special type of transaction. These audit transactions also require verification and confirmation through an improved consensus algorithm.

[0079] Once a transaction receives sufficient votes of sufficient weight, it is packaged into a specific audit block in the distributed ledger. Audit blocks are structurally similar to regular storage transaction blocks, but their transaction type is marked as audit for easier subsequent querying and analysis.

[0080] Through this mechanism, all critical protection operations are permanently and immutably recorded.

[0081] The policy management module provides the system with flexible and centralized policy control capabilities. This module typically provides a user interface that allows data owners or system administrators to set and adjust digital asset protection policies. A data protection policy is a collection of configurable parameters.

[0082] The core parameters include the number of data redundancy copies, which defines the number of copies of each data block or check block stored in the distributed network. The value range is usually between 2 and 10, with a default value of 3.

[0083] The frequency parameter of the verification challenge defines the time interval at which the dynamic verification module initiates integrity checks. It can be set to a fixed period, such as once per hour or once per day, or it can be set to an event-based trigger mode, such as when the system is idle.

[0084] The corruption threshold parameter that triggers data recovery defines how many data block replicas must fail before the repair process is initiated. For example, setting it to 1 means that repair will be triggered as soon as any replica fails.

[0085] The reputation admission criteria for storage nodes are a set of rules used to evaluate the credibility of nodes. These include minimum requirements for the node's historical online rate, such as greater than 99.5%, minimum requirements for data verification pass rate, such as greater than 99.9%, and requirements for participation in consensus voting, such as a participation rate of greater than 95% in the past week.

[0086] After receiving these policy parameters, the policy management module compiles them into executable code or configuration scripts that can be recognized and executed internally by the system. The compilation process ensures the correctness and security of the policy logic. The compiled policy code is deployed to the relevant modules of the system, especially the distributed storage network module and the dynamic verification module. The deployment mechanism can be push update or module-initiated pull.

[0087] Each module strictly adheres to these deployed policies during operation. For example, when selecting storage nodes, the distributed storage network module rigorously checks whether the node's reputation score meets the admission criteria set in the policy. The policy management module also maintains a dynamic storage node reputation evaluation system.

[0088] The evaluation system continuously collects node behavior data from various modules. The collected data includes the online rate, calculated as the ratio of a node's actual online time to its total online time; the verification pass rate, calculated as the ratio of the number of times a node successfully passed verification in each dynamic verification to the total number of challenges; and the voting activity, calculated as the ratio of the number of rounds a node actually participated in voting during the consensus process to the total number of consensus rounds.

[0089] These raw data are weighted and calculated to arrive at a comprehensive reputation score, typically ranging from 0 to 100. The reputation score calculation model can be optimized periodically. The evaluation results, i.e., the current reputation score of each node, are recorded periodically, for example, every 6 hours, in a distributed ledger to ensure their transparency and immutability.

[0090] The policy management module itself also periodically, for example daily, checks the latest reputation scores of all active nodes. This checking process is automated. The module compares each node's reputation score with the admission threshold set in the policy. The admission threshold is a preset value, such as 80 points.

[0091] If a node's reputation score is found to be below the admission threshold, the policy management module will immediately mark the node as an untrusted node. The marking operation includes updating the node's status flag in the system's internal status table.

[0092] Simultaneously, the policy management module sends a data migration instruction to the recovery and auditing module. The instruction contains the identifier of the marked node and a list of all data blocks that need to be migrated from that node.

[0093] After receiving the instruction, the recovery and auditing module initiates a data migration process similar to the data repair process. This process securely and completely migrates the data blocks stored on the untrusted node to other reputable and available nodes. Once the migration is complete, the module updates the storage location information in the distributed ledger, thereby ensuring that the data is always stored in a trusted node environment.

[0094] This embodiment constructs a highly automated, secure, and reliable digital asset protection system through the deep collaboration and refined design of the five core modules mentioned above. From block encryption and redundant coding when data enters the system, to consensus-based rights confirmation and dynamic verification during storage, to rapid repair and full-process auditing when anomalies occur, and finally supplemented by flexible policy management and node reputation mechanisms, the system achieves comprehensive, auditable, adaptive, and continuous protection of digital assets in a fully distributed storage environment.

[0095] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0096] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A digital asset protection system based on distributed storage, characterized in that, include: The data preprocessing module is used to receive raw digital asset data, and to perform block processing and encryption encoding on the raw digital asset data to generate a set of data blocks and corresponding metadata. The distributed storage network module consists of multiple storage nodes, which are used to store the data block set according to a preset redundancy strategy and maintain a distributed ledger based on an improved consensus algorithm. The distributed ledger records the storage location information and integrity verification records of all data blocks. The dynamic verification module is used to periodically or based on triggering events to initiate challenge requests to the storage node, collect data possession proofs from the storage node, and verify the data possession proofs through a verification algorithm to confirm data integrity. The recovery and auditing module is used to initiate a data repair process when data corruption or loss is detected, and to record all verification and repair operations to the audit log. The policy management module allows data owners to set data protection policies, compile the data protection policies into executable code, and deploy them to the distributed storage network module.

2. The digital asset protection system based on distributed storage according to claim 1, characterized in that, The block processing procedure performed by the data preprocessing module is as follows: The raw digital asset data is divided into multiple fixed-size data blocks; For each data block, calculate its cryptographic hash value as a data fingerprint; use erasure coding algorithm to encode the data block set to generate a data block set containing the original data block and the verification data block; The metadata includes the data fingerprint, data block index, erasure coding parameters, and data owner identifier for each data block.

3. A digital asset protection system based on distributed storage according to claim 1, characterized in that, The execution process of the improved consensus algorithm is as follows: Storage nodes participating in the consensus are assigned different voting weights based on their storage contribution and historical verification pass rate; Within each storage cycle, nodes vote on the storage transactions of data blocks generated in the current cycle; When a transaction receives a weighted vote of more than a preset threshold, the transaction is confirmed and recorded in a new block of the distributed ledger; Each block header of the distributed ledger contains the hash value of the previous block, a timestamp, and the Merkle root hash of all stored transactions in the current block.

4. A digital asset protection system based on distributed storage according to claim 1, characterized in that, The verification process of the dynamic verification module is as follows: The verification module generates a random number as the challenge value; The challenge value is sent to multiple target nodes that store specific data blocks; The target node uses its stored data block and challenge value as input to run the specified proof generation function, generate a data ownership proof, and return it to the verification module. The verification module uses the corresponding data fingerprint stored locally and the received challenge value to run the verification function and verify the returned proof. If the verification passes, the data is deemed complete; otherwise, the recovery and auditing module is triggered.

5. A digital asset protection system based on distributed storage according to claim 4, characterized in that, The proof generation function adopts an algebraic structure based on bilinear mapping. Its inputs are a data block, a challenge value, and the node's private key, and its output is a proof in the form of a digital signature. The verification function uses the public key, data fingerprint, and challenge value of the corresponding node to determine data ownership by verifying the validity of the digital signature.

6. A digital asset protection system based on distributed storage according to claim 1, characterized in that, The data recovery and auditing module's data repair process is as follows: When the dynamic verification module detects that a data block is lost or corrupted, the recovery and auditing module first locates other available nodes that store a copy of the data block or related verification blocks from the distributed ledger; Based on the erasure coding parameters, download a sufficient number of data blocks or parity blocks from available nodes; reconstruct the original data blocks using the erasure coding decoding algorithm. The reconstructed data blocks are stored on new available nodes, and the corresponding storage location information in the distributed ledger is updated.

7. A digital asset protection system based on distributed storage according to claim 1, characterized in that, The recording process of the audit log is as follows: All challenge requests initiated by the dynamic verification module, received proofs, verification results, and data repair operations performed by the recovery and auditing module are encapsulated as audit events; The audit event is digitally signed and broadcast to the distributed storage network module, and after consensus confirmation, it is recorded in a specific audit block of the distributed ledger; Each audit event includes the event type, the identifier of the data block involved, the operation timestamp, the execution node identifier, and the operation result status.

8. A digital asset protection system based on distributed storage according to claim 1, characterized in that, The data protection strategy includes the number of data redundancies, the frequency of verification challenges, the damage threshold that triggers data recovery, and the reputation admission conditions for storage nodes. The policy management module compiles the data protection policy into executable code and deploys it to the distributed storage network module to ensure that the operation of each module conforms to the preset policy.

9. A digital asset protection system based on distributed storage according to claim 8, characterized in that, The reputation admission criteria for the storage nodes are dynamically evaluated based on the nodes' historical online rate, data verification pass rate, and their enthusiasm for participating in consensus voting. The assessment results are recorded in the distributed ledger in the form of a credit score; The policy management module periodically checks the reputation score of nodes. If the score is less than the preset admission threshold, the node is marked as an untrusted node and a data migration process is triggered to migrate the data blocks stored on the node to nodes with qualified reputation. The credit score update process is as follows: Obtain data on the node's historical online rate, data verification pass rate, and participation in consensus voting; The data is weighted and calculated based on a preset evaluation model to generate the current reputation score; Record the current credit score to the distributed ledger; The strategy management module determines the trust status of nodes and makes data migration decisions based on the recorded reputation scores.

10. A method for protecting digital assets based on distributed storage, characterized in that, Digital asset protection is achieved using the distributed storage-based digital asset protection system described in any one of claims 1-9.

Images