Distributed-based intellectual property digital asset storage system

Abstract

The application discloses a distributed intellectual property digital asset storage system and relates to the technical field of distributed storage.The right management layer is composed of an alliance chain network and comprises a right tree contract, a proxy re-encryption proxy contract and a retrievability proof scheduling contract.The right tree contract is used for maintaining the right level state machine of intellectual property assets.The proxy re-encryption proxy contract is used for hosting re-encryption keys and performing proxy re-encryption operations.The retrievability proof scheduling contract is used for periodically performing storage node availability audits.After the message locking encryption mechanism is adopted, only one copy of ciphertext of the same intellectual property asset is stored in the whole network, the increase in the number of storage nodes does not cause repeated storage, the storage utilization of the system is greatly improved, the storage resource consumption is proportional to the number of intellectual property asset types rather than the number of users.

Description

Technical Field

[0001] This invention relates to the field of distributed storage technology, specifically to a distributed intellectual property digital asset storage system. Background Technology

[0002] With the rapid development of the digital economy, the scale and types of intellectual property digital assets continue to expand, covering various forms such as patent technical documents, software source code, industrial design drawings, artificial intelligence model weights, and large-scale training datasets. These assets have both extremely high commercial value and strict legal attributes, and their storage and circulation management face multiple challenges in terms of security, compliance, and efficiency.

[0003] Currently, the industry widely adopts distributed intellectual property asset management solutions that combine the InterPlanetary File System (IPFS) with blockchain hash storage. The typical architecture is as follows: the intellectual property asset holder uses their own public key to encrypt the original file on the client, uploads the ciphertext to the distributed file network, the network returns the content identifier, and then calls the smart contract to write the asset metadata, content identifier and holder's public key address into the blockchain to complete the storage. This architecture has three fundamental technical defects in the intellectual property digital asset management scenario.

[0004] First, there is a storage efficiency defect. Since each user uses an independent public key to encrypt the same file, the same plaintext generates different ciphertexts under the randomness of encryption, resulting in different content addressing hashes. The content deduplication mechanism of the distributed network is completely ineffective, and the storage cost increases linearly or even exponentially with the user scale. In scenarios with a large number of concurrent applications for intellectual property assets, the storage cost is unsustainable.

[0005] Second, there are shortcomings in the efficiency of ownership transfer. The entire lifecycle of intellectual property asset operations, such as pledging, transferring, and sublicensing, requires the original rights holder to complete the entire data transfer process of downloading, decrypting, re-encrypting, and re-uploading. For large engineering data packets or artificial intelligence training datasets that reach gigabyte or even terabyte levels, this process generates unacceptable network bandwidth and computing overhead, and cannot guarantee data consistency within the operation window, lacking atomicity guarantees.

[0006] Third, there is a flaw in the uncontrolled data security boundary. After a node fails, the distributed storage network rebuilds the data on any healthy node through random addressing across the entire network, without distinguishing the ownership of the target node's permissions. This leads to the uncontrollable spread of confidential intellectual property data copies to unauthorized or non-compliant nodes, and the consistency between the physical storage distribution and the scope of legal authorization cannot be guaranteed.

[0007] The aforementioned three deficiencies create fundamental obstacles for existing solutions in formal intellectual property management scenarios, necessitating the development of systematic technical solutions. Summary of the Invention

[0008] This invention aims to solve three technical problems that exist simultaneously in existing distributed intellectual property digital asset storage systems: the technical contradiction between encrypted deduplication and data privacy protection, the systemic overload and data inconsistency risk of dynamic ownership transfer, and the risk of loss of control over authorization boundaries during the data reconstruction process after node failure.

[0009] To address the aforementioned technical issues, this invention provides a distributed intellectual property digital asset storage system. This system comprises five core layers: a user interaction layer, an ownership management layer, a key service layer, a distributed storage layer, and a data block layer. Each layer interacts through standardized interfaces, forming a closed-loop technology.

[0010] The system achieves the above technical objectives through the following three core mechanisms.

[0011] Core Mechanism 1: Ownership-Aware Two-Layer Encryption Deduplication Mechanism This system adopts a two-layer encryption architecture that deeply couples message locking encryption and ciphertext policy attribute-based encryption, dividing data storage into two dimensions: a physical storage layer and a logical permission layer.

[0012] The physical storage layer is responsible for encrypted cross-node deduplication of data blocks, including intellectual property asset documents. Perform a content hash operation, use the resulting hash digest as the symmetric encryption key, and perform symmetric encryption on the file content to generate ciphertext. Since the encryption key is entirely determined by the file content, identical plaintext will inevitably generate identical ciphertext, and their content identifiers will also be completely identical. This achieves ciphertext deduplication at the physical level, eliminating duplicate storage. Specifically: ; ; in, The plaintext of the original intellectual property asset documents to be stored; This is a collision-resistant hash function using the SHA3-256 algorithm, outputting a 256-bit digest. The message is uniquely identified by the content of the file, which is used to lock the symmetric key for encryption. It uses the AES-256-GCM symmetric encryption algorithm; The ciphertext generated after the file is encrypted using message locking is stored in a distributed storage layer.

[0013] The logical permission layer is responsible for implementing permission isolation protection for the encryption key locked in the above messages.

[0014] Employing a ciphertext policy attribute-based encryption algorithm, based on the ownership access control policy tree of intellectual property assets. Lock the encryption key for the message Encryption is performed to generate the key ciphertext. : ; in, The public key of the ciphertext policy attribute-based encryption system issued by the attribute licensing authority; For example, the access control policy tree tied to this intellectual property asset. ; The attribute-based encrypted ciphertext of the message lock encryption key is approximately several hundred to several thousand bytes in size and is stored in a smart contract or on-chain storage.

[0015] Holding a policy tree Private key attributes Users (attribute set) ,and The original file can be decrypted and obtained by executing the ciphertext policy attribute base decryption recovery message to lock the encryption key.

[0016] This mechanism achieves both ciphertext deduplication and fine-grained ownership isolation capabilities simultaneously through the architecture design of message-locked encryption keys, i.e. attribute-based encryption objects. It also supports independent management of various complex permission types such as implementation rights, sublicensing rights, revenue rights, and regional transfer rights.

[0017] Core Mechanism Two: Atomic Incremental Ownership Transfer Mechanism Based on Proxy Re-encryption When ownership of intellectual property assets is transferred, the data is physically encrypted. Remain unchanged, only the attribute controlling decryption permissions is encrypted as the base ciphertext. By using a proxy to re-encrypt and transform the file, it is changed from being decryptable under the original rights holder's attribute structure to being decryptable under the new rights holder's attribute structure. Since the key ciphertext size is extremely small, the communication overhead of the entire ownership transfer is completely decoupled from the size of the original file.

[0018] The original rights holder uses their own private key and the new rights holder's public key locally to generate a re-encryption key: ; Proxy smart contracts deployed on the blockchain execute proxy re-encrypted computations: ; in, The private key of the original rights holder; The public key for the new rights holder; For the re-encryption key from the original rights holder to the new rights holder; To lock the encrypted key attribute base encrypted ciphertext for messages that can be decrypted under the original rights holder attribute structure; To lock the encrypted key attribute base encrypted ciphertext for messages that can be decrypted under the new rights holder attribute structure.

[0019] The proxy smart contract encapsulates the proxy re-encryption operation and the rights tree state update in the same blockchain atomic transaction. After the transaction is successfully committed, the contract immediately destroys the re-encryption key and does not persist it on the chain to prevent contract nodes from using the key to carry out continuous decryption attacks. If any abnormality occurs during the execution of the transaction, the entire transaction is rolled back to the initial state to ensure the atomicity of ownership transfer.

[0020] Core Mechanism 3: Adaptive Replica Fault Tolerance and Retrievability Proof Mechanism Based on Dynamic Ownership State This system introduces the concept of an authorized storage node pool at the distributed hash table layer and binds it to the rights tree in smart contracts in real time. For each intellectual property asset, the system maintains the following mapping relationship: ; in, Indicates at time ,assets The set of valid authorized storage nodes; Represents the first in the network One storage node; Represents a node The set of attributes held; Assets At any moment The current valid access policy is provided in real time by the rights tree contract.

[0021] The system adopts a dynamic retrievability proof protocol based on BLS signatures. It performs periodic availability audits on each intellectual property asset within the authorized node pool. The retrievability proof scheduling contract randomly selects a set of challenges and broadcasts the challenges to all storage nodes in the authorized node pool. The system verifies the aggregated proofs of nodes through elliptic curve bilinear pairing, confirming that the remote storage node has completely saved the corresponding data block without downloading the complete file.

[0022] When the searchability proof audit detects a node failure, the system removes the failed node from the authorized node pool and constructs a candidate fault-tolerant node set: ; in, Represents the set of candidate fault-tolerant nodes. This represents the set difference operation. The node computation is completely decoupled from the original file size, reducing the transfer latency from minutes to seconds, while ensuring operational consistency through smart contract atomic transactions. 3. This invention ensures that data copies circulate only within the authorized node pool through an adaptive reconstruction mechanism that binds dynamic retrievability proof to the rights tree, and that the physical storage distribution of IP assets maintains strong consistency with the scope of legal authorization, thereby fundamentally eliminating data compliance risks.

[0023] 4. This invention, through the combination of encrypted policy attribute-based encryption and a rights tree, enables the system to support independent control of various complex permission types such as implementation rights, sublicensing rights, territorial transfer rights, and pledge rights, meeting the needs of intellectual property full lifecycle management. (This has been marked as invalid.)

[0024] After verifying that the size of the candidate fault-tolerant node set meets the minimum recoverable block requirement of the erasure coding scheme, the system selects the target reconstruction node from the candidate node set according to the storage load balancing strategy. Using the erasure coding blocks stored in other healthy nodes in the candidate node set, the data reconstruction is completed within the boundary of the candidate fault-tolerant node set. During the entire reconstruction process, all transmitted data are message-locked encrypted ciphertext blocks, and plaintext data does not appear in the network. This mechanism forces that the data reconstruction target node must belong to the current authorized storage node pool, fundamentally eliminating the risk of intellectual property data copies spreading outside the authorized boundary.

[0025] Compared with the prior art, the beneficial effects of the present invention by adopting the above technical solution are as follows: 1. After adopting the message locking encryption mechanism, the same intellectual property assets are stored in only a single ciphertext across the entire network. The increase in the number of storage nodes will not cause duplicate storage, the system storage utilization rate is greatly improved, and the storage resource consumption is proportional to the number of types of intellectual property assets, rather than proportional to the number of users. 2. This invention uses a proxy re-encryption mechanism to ensure that ownership change operations only involve key-level re-encryption operations, which is completely decoupled from the original file size. The transfer delay is reduced from minutes to seconds, while the consistency of operations is guaranteed by smart contract atomic transactions. 3. This invention ensures that data copies circulate only within the authorized node pool through an adaptive reconstruction mechanism that binds dynamic retrievability proof to the rights tree, and that the physical storage distribution of IP assets maintains strong consistency with the scope of legal authorization, thereby fundamentally eliminating data compliance risks.

[0026] 4. This invention combines encrypted policy attribute base encryption with a rights tree, enabling the system to support independent control of various complex permission types such as implementation rights, sublicensing rights, regional transfer rights, and pledge rights, thus meeting the needs of intellectual property full lifecycle management. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of the five-layer overall architecture of the system of the present invention; Figure 2 This is a schematic diagram of the double-layer encryption deduplication process of the present invention; Figure 3 This is a schematic diagram of the intellectual property ownership transfer and adaptive fault-tolerant mechanism of the present invention. Detailed Implementation

[0028] The following is in conjunction with the appendix Figure 1-3 The specific embodiments of the present invention will be further described below. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0029] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0030] The distributed intellectual property digital asset storage system proposed in this invention consists of five core layers.

[0031] The user interaction layer includes client nodes for different roles such as intellectual property asset holders, licensees, and regional agents. Each role holds a set of attributes issued by the attribute licensing authority and interacts with the ownership management layer through a standardized application programming interface.

[0032] The ownership management system is composed of a consortium blockchain network and includes three types of smart contract modules: the rights tree contract, the proxy re-encryption proxy contract, and the searchability proof scheduling contract. These modules are responsible for maintaining the rights tree state machine, managing the re-encryption key, and scheduling the searchability proof challenge, respectively.

[0033] The key service layer contains a cluster of attribute authorization agency nodes, which is responsible for the management of ciphertext policy attributes and encryption master keys, as well as the issuance of user attribute private keys, and maintains bidirectional communication with the rights tree contract.

[0034] The distributed storage layer consists of a modified network based on the Kademlia distributed hash table protocol. Nodes are divided into two categories: authorized storage nodes and candidate fault-tolerant nodes, with node eligibility maintained in real-time by a rights-tree contract. The distributed storage layer of this system is designed to be compatible with the Hadoop ecosystem's distributed file system architecture, represented by HDFS. Authorized storage nodes can be mapped to HDFS data node roles, and the authorized node pool maintained by the rights-tree contract can be mapped to the block location management function of the HDFS name node, thereby achieving seamless integration and deployment in Hadoop databases and big data processing environments.

[0035] The data block layer displays a Merkle directed acyclic graph data structure, with each leaf node representing a message-locked encrypted data block and the root node pointing to the metadata of the complete file.

[0036] II. Specific Implementation Methods of Core Mechanism 1 The complete implementation process of the ownership-aware two-layer encryption deduplication mechanism is as follows.

[0037] The client has original intellectual property asset files to store. Perform content hashing to calculate the message lock encryption key, where The SHA3-256 algorithm is used, and the output is a 256-bit binary digest. This operation is performed locally on the client, and the plaintext content of the file does not leave the client. At the same time, according to the block partitioning rules of the Merkle directed acyclic graph (default 256KB per block), the content identifier sequence of each data block and the root node content identifier are pre-calculated. .

[0038] The client sends data to the distributed hash network through the distributed hash table query interface. The existence query request constructs a lookup message for the Kademlia protocol, along with... Route hopping ( (Total number of network nodes) Query the responsible node that stores the key.

[0039] Execute branch processing based on the query results, if If the ciphertext already exists in the distributed hash network, it indicates that the ciphertext of the same intellectual property asset already exists on the network. Skip the file encryption and upload steps, and directly proceed to the attribute-based encryption key encapsulation stage. If it does not exist, proceed to the initial storage process: The client will send the file Divide into according to Merkle's directed acyclic graph rule. Data blocks For each data block Perform AES-256-GCM symmetric encryption to generate ciphertext blocks. All ciphertext blocks and their Merkle directed acyclic graph structures are uploaded to the distributed hash network, where each responsible node performs block verification and stores the data in the database.

[0040] During the attribute-based encryption key encapsulation phase, the client obtains the system public key from the attribute licensing authority and constructs an access control policy tree based on the ownership configuration of this intellectual property storage. (The leaf nodes of the policy tree are attribute predicates, and the internal nodes are threshold operators AND, OR, and...) -of- ), execute ciphertext policy attribute base encryption to generate key ciphertext The size is approximately several hundred to several thousand bytes, much smaller than the original intellectual property document.

[0041] The client calls the asset registration interface of the blockchain rights tree contract to register the globally unique identifier of the intellectual property asset and the content identifier of the root node of the Merkle directed acyclic graph. The attribute base of the message locking encryption key is used to encrypt the ciphertext. Serialization representation of access control policy tree Original rights holder attribute set The tuple consisting of the registration timestamp is written to the root node of the on-chain rights tree, and the notarization hash is returned after the transaction is completed. At this point, the double-layer encrypted storage and on-chain notarization are completed.

[0042] When an authorized user needs to access intellectual property assets, the corresponding key ciphertext is read from the on-chain rights tree contract. Using attribute-authorized authority issued documents that satisfy the policy tree Private key attributes Decryption is performed to restore the message lock encryption key. Then, the ciphertext file is retrieved from the distributed hash network by content identifier and symmetric decryption is performed locally to obtain the original file.

[0043] In HDFS-compatible deployment scenarios, ciphertext blocks It can be stored in HDFS blocks on Hadoop data nodes. The block replica placement strategy is replaced by the original rack-aware strategy by the constraints of the authorized storage node pool. The block mapping table of the NameNode is supplemented by the content identifier index of the rights tree contract, realizing low-intrusion integration with the existing Hadoop ecosystem infrastructure.

[0044] III. Specific Implementation Methods of Core Mechanism Two The complete implementation process of the atomic incremental ownership transfer mechanism based on proxy re-encryption is as follows.

[0045] The original rights holder (referred to as Alice) initiates an ownership transfer application, specifying the public key of the new rights holder (referred to as Bob) in the client. Transfer types (full transfer, partial authorization or pledge) and new ownership strategy tree The transfer initiation interface of the proxy re-encryption proxy contract is called to write the transfer request hash onto the chain, which serves as the locking basis for subsequent atomic transactions.

[0046] Alice uses her private key locally. Public key with new rights holder Generate re-encryption key The re-encryption key and its digital signature are submitted to the agent re-encryption agent contract through an end-to-end encryption channel.

[0047] After all the following conditions are met in the proxy re-encryption proxy contract verification, the blockchain atomic transaction is initiated: Alice's signature verification of the re-encryption key is successful; Alice is indeed the current valid rights holder of the corresponding intellectual property asset in the rights tree; the transfer application hash is consistent with the on-chain lock record.

[0048] Within an atomic transaction, the contract execution proxy performs re-encrypted computation. The re-encryption key is destroyed immediately after re-encryption is completed and is not persistently stored on the chain to prevent contract nodes from using the key to carry out continuous decryption attacks.

[0049] Within the same atomic transaction, the rights tree contract performs the following state update: sets the state of the node corresponding to Alice in the rights tree to "transferred" and records the transfer timestamp; Create a new child node for Bob in the rights tree, and write the intellectual property asset identifier, content identifier, and the re-encrypted key ciphertext into it. New ownership strategy tree Bob's attribute set and transfer timestamp; Update the authorized node pool index of the corresponding asset in the distributed hash network, add Bob's storage node address to the set of valid authorized nodes, and perform downgrade or removal operations on Alice's entry in the set of authorized nodes according to the transfer type.

[0050] The blockchain network performs consensus confirmation on the block containing all the above operations. If consensus is successful, the transaction is committed, and the contract sends an on-chain event notification to Bob's client address; If any anomaly occurs during the consensus process, the entire transaction is rolled back to the state before the atomic transaction was initiated, and the system maintains its integrity.

[0051] After Bob's client receives the transfer completion event, it uses the attribute authorization authority-issued document that satisfies the new ownership policy tree. Private key attributes The message is decrypted to obtain the encryption key, and the ciphertext file is retrieved from the distributed hash network by its content identifier. Local decryption is then performed to obtain the original intellectual property asset file. Throughout the entire ownership transfer process, the plaintext content of the original file does not need to be transmitted over the network, and the physical location and content of the ciphertext remain unchanged in the distributed network.

[0052] IV. Specific Implementation Methods of Core Mechanism Three The complete implementation process of the adaptive replica fault tolerance and retrievability proof mechanism based on dynamic ownership status is as follows.

[0053] During the system initialization phase, for the file Pre-computed authentication tag set for each data block , of which The BLS certification label for each data block is: ; in, The audited private key held by the scheduling contract serves as proof of retrievability. Let be the hash value of the i-th ciphertext block; This indicates a byte string concatenation operation.

[0054] The searchability proof scheduling contract triggers a full audit task at a preset period (default 24 hours, which can be configured by the right holder according to the value level of the intellectual property assets). It reads the authorized storage node pool from the current rights tree state, broadcasts a random challenge set to all nodes in the set, and sets a response timeout threshold (default 300 seconds).

[0055] Storage nodes receive challenge sets (in For block indexes, For random coefficients, After determining the number of challenge blocks, calculate the linear aggregation value. With aggregated BLS signature Aggregate proof Return to the scheduling contract.

[0056] The scheduling contract performs BLS batch pairing verification and passes the verification equation: ; in This represents the pairing operation for bilinear elliptic curves. It is an elliptic curve generator.

[0057] For nodes that fail to return a valid proof or whose proof verification fails within the timeout threshold, they are marked as invalid and the invalidation event is recorded in the rights tree contract.

[0058] The system queries the current authorized storage node pool in real time from the rights tree contract, removes all nodes marked as invalid, and constructs a candidate fault-tolerant node set. .

[0059] The system verifies that the size of the candidate fault-tolerant node set meets the requirements of the adopted erasure coding scheme (this system uses Reed-Solomon codes, with encoding parameters as follows). Minimum number of recoverable blocks Requirements.

[0060] If this condition is not met, the contract will issue an emergency warning to all rights holders and initiate an emergency expansion process, inviting new nodes with the corresponding attributes to join the authorized storage node pool. If the conditions are met, the target reconstruction node is selected from the candidate fault-tolerant node set according to the storage load balancing strategy: ; in, Used storage space for nodes For nodes Total storage space, target rebuild node The node with the lowest storage load ratio among the candidate fault-tolerant node set.

[0061] The retrievability proof scheduling contract sends a data reconstruction instruction to other healthy nodes within the candidate fault-tolerant node set. The healthy nodes then transmit the coded blocks stored within them to the target reconstruction node, based on the Reed-Solomon erasure coding recovery algorithm. ,Depend on The invalid data block is decoded and reconstructed. During the entire reconstruction process, all transmitted data are message-locked encrypted ciphertext blocks, and plaintext data does not appear on the network.

[0062] Target Reconstruction Node After the data block reconstruction is completed, a local retrievability proof self-verification is performed on the reconstruction result. The verification result is then reported to the scheduling contract. After the contract confirms the verification is successful, the replica distribution record in the distributed hash network routing table is updated. The address of the failed node is added to the replica index, and the address of the failed node is removed from the replica index. At this point, the adaptive fault-tolerant reconstruction is completed. The entire reconstruction process is strictly limited to the set of candidate fault-tolerant nodes, and the intellectual property asset replicas will not spread beyond the authorization boundary.

[0063] In HDFS-compatible deployment scenarios, the above replica reconstruction process can work in conjunction with the HDFS block reporting mechanism. After receiving a block loss report from a data node, the NameNode uses the authorized storage node pool of the rights tree contract as a constraint to replace the original rack-aware replica placement strategy to select the target node for reconstruction, thereby naturally integrating the authorized boundary constraints into the storage management system of the Hadoop database.

[0064] V. Comprehensive Implementation Method for System Lifecycle Throughout the complete lifecycle of the system, intellectual property assets undergo four main operations: initial storage, ownership transfer, access by authorized parties, and periodic availability audits. These three core mechanisms work together to ensure the security, compliance, and efficiency of intellectual property assets in a distributed storage environment.

[0065] The rights tree continuously evolves its state structure along with the life cycle of intellectual property assets: the root node is the original rights holder, the child nodes are licensees at all levels, and each node records the node identifier, attribute set, current state and bound attributes, as well as encrypted information. The node state switches between active, partially transferred, transferred and invalid according to the authorization operation, which fully records the ownership hierarchy and historical change trajectory of intellectual property assets.

[0066] Each ownership transfer or authorization change operation synchronously triggers an update of the authorized storage node pool, ensuring that the physical node permission configuration of the distributed storage layer and the legal authorization status of the on-chain rights tree remain strongly consistent in real time, fundamentally eliminating the systemic defect in the management of intellectual property digital assets where physical storage distribution and legal authorization scope are mutually exclusive.

[0067] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of the present invention. Therefore, any modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall fall within the protection scope defined by the claims of the present invention.

Claims

1. A distributed intellectual property digital asset storage system, characterized in that, The system includes a user interaction layer, an ownership management layer, a key service layer, a distributed storage layer, and a data block layer; The user interaction layer includes client nodes that hold a set of attributes issued by the attribute authorization authority, and each client node interacts with the ownership management layer through a standardized interface; The ownership management layer is composed of a consortium blockchain network, including a rights tree contract, a proxy re-encryption proxy contract, and a searchability proof scheduling contract. The rights tree contract is used to maintain the ownership hierarchy state machine of intellectual property assets. The proxy re-encryption proxy contract is used to host the re-encryption key and perform proxy re-encryption operations. The searchability proof scheduling contract is used to periodically perform storage node availability audits. The key service layer includes a cluster of attribute authorization agency nodes, which is responsible for the management of the ciphertext policy attribute base encryption master key and the issuance of user attribute private keys. The distributed storage layer consists of a network based on the Kademlia distributed hash table protocol. Storage nodes are divided into two categories: authorized storage nodes and candidate fault-tolerant nodes. The qualification of authorized storage nodes is determined by the authorized storage node pool maintained in real time by the rights tree contract. The data block layer is composed of a Merkle directed acyclic graph structure, where each leaf node is a message-locked encrypted data block and the root node points to the metadata of the complete file. The system works in concert through a dual-layer encryption deduplication mechanism that is aware of ownership, an atomic incremental ownership transfer mechanism based on proxy re-encryption, and an adaptive replica fault tolerance mechanism based on dynamic ownership status. The dual-layer encryption deduplication mechanism uses the content hash digest of the intellectual property asset file as the message locking encryption key to perform symmetric encryption on the file, and uses the access control policy tree to perform ciphertext policy attribute base encryption on the message locking encryption key to generate a key ciphertext stored in the rights tree contract. The ownership transfer mechanism performs proxy re-encryption calculation within the blockchain atomic transaction and destroys the re-encryption key immediately after the calculation is completed. The adaptive replica fault tolerance mechanism forces the data reconstruction target node to be limited to the authorized storage node pool maintained in real time by the rights tree contract, thereby realizing the secure storage, ownership management and compliant transfer of intellectual property digital assets.

2. The system according to claim 1, characterized in that, The ownership-aware two-layer encryption deduplication mechanism includes two dimensions: physical storage layer encryption deduplication and logical permission layer key protection. The implementation method of the physical storage layer encryption and deduplication is as follows: the client has intellectual property asset files to be stored. Perform a content hash operation and use the resulting hash digest as the message locking encryption key. Perform symmetric encryption on the file content to generate ciphertext. This achieves ciphertext-level deduplication among distributed nodes by leveraging the characteristic that identical content will inevitably generate identical ciphertext. The implementation method of the logical permission layer key protection is as follows: the client uses the access control policy tree of intellectual property assets. Lock the encryption key for the message Perform ciphertext policy attribute-based encryption to generate key ciphertext. ciphertext of the key Storing in the rights tree contract allows holding to satisfy the strategy tree. Only the user of the private key can decrypt the message to obtain the message locking encryption key and then access the original file; The access control policy tree The leaf nodes are attribute predicates, and the internal nodes are AND, OR, and... -of- Threshold operators support independent control over implementation rights, sublicensing rights, revenue rights, and regional transfer rights.

3. The system according to claim 2, characterized in that, The physical storage layer encryption and deduplication further includes a deduplication hit determination step; The deduplication hit detection step is implemented as follows: Before performing file encryption and uploading, the client pre-calculates the root node content identifier. The Kademlia protocol is used to send lookup messages to the distributed hash network. Existence query; If the query result indicates that the file already exists, the file encryption and upload steps are skipped, and the ciphertext policy attribute and encryption key encapsulation steps are executed directly. If the query result is not found, the file is divided into blocks according to the Merkle directed acyclic graph rule, symmetric encryption is performed on each block, and the file is uploaded to the distributed hash network. Then, the ciphertext policy attribute base encryption key encapsulation step is performed. After key encapsulation is completed, the client calls the asset registration interface of the rights tree contract to register the globally unique identifier of the intellectual property asset and the root node content identifier. Key ciphertext The access control policy tree is serialized, and the original rights holder attribute set and registration timestamp are written into the root node of the rights tree to complete on-chain evidence storage.

4. The system according to claim 1, characterized in that, The implementation method of the atomic incremental ownership transfer mechanism based on proxy re-encryption is as follows: The original rights holder uses their own private key and the new rights holder's public key to generate a re-encryption key locally on the client side, and submits it to the agent re-encryption agent contract with digital signature through an end-to-end encryption channel; After the proxy re-encryption proxy contract verifies the validity of the signature, the consistency of the ownership of rights, and the consistency of the transfer application lock record, it initiates a blockchain atomic transaction. Within the atomic transaction, it performs proxy re-encryption calculation, transforming the decryptable key ciphertext under the original rights holder attribute structure into a decryptable key ciphertext under the new rights holder attribute structure. After the proxy re-encryption calculation is completed, the re-encryption key is destroyed immediately and is not persistently stored on the chain. Within the same atomic transaction, the rights tree contract updates the original rights holder node status to "transferred", creates a new child node for the new rights holder and writes the re-encrypted key ciphertext and the new ownership strategy tree, and synchronously updates the authorized storage node pool index of the corresponding asset in the distributed storage layer. The blockchain network performs consensus confirmation on blocks containing all the above operations. If the consensus is successful, the transaction is committed. If any abnormality occurs during the consensus process, the entire transaction is rolled back to the state before the atomic transaction was started. Throughout the ownership transfer process, the physical encrypted text of the intellectual property asset documents remains unchanged in its storage location and content within the distributed storage layer, thus decoupling the communication overhead of ownership changes from the original document size.

5. The system according to claim 1, characterized in that, In the aforementioned adaptive replica fault-tolerant mechanism based on dynamic ownership status, the authorized storage node pool is bound to the rights tree contract in real time. For each intellectual property asset, the members of the authorized storage node pool are determined by the following conditions: The set of attributes held by a node satisfies the valid access strategy for the asset at the current moment; Each ownership transfer or authorization change operation synchronously triggers an update of the authorized storage node pool; The retrievability proof scheduling contract performs periodic challenge-response audits on all storage nodes in the authorized storage node pool. Through the BLS batch signature verification mechanism based on elliptic curve bilinear pairing operation, it confirms that each node has completely saved the corresponding data block without downloading the complete file. When an audit detects a storage node failure, the system removes the failed node from the authorized storage node pool, constructs a candidate fault-tolerant node set, verifies that the size of the candidate fault-tolerant node set meets the minimum recoverable block requirement of Reed-Solomon erasure coding, selects a target reconstruction node from the candidate fault-tolerant node set according to the storage load balancing strategy, and completes data reconstruction within the boundary of the candidate fault-tolerant node set. Throughout the reconstruction process, all transmitted data are message-locked encrypted ciphertext blocks.

6. The system according to claim 5, characterized in that, The audit period for the searchability proof scheduling contract can be configured by the rights holder based on the value level of the intellectual property assets; When the size of the candidate fault-tolerant node set does not meet the minimum recoverable block requirement of Reed-Solomon erasure coding, the retrievability proof scheduling contract sends an emergency alarm notification to all rights holders and initiates an emergency expansion process, inviting new nodes holding attribute sets that match the current valid access policy to join the authorized storage node pool.

7. The system according to claim 1, characterized in that, The distributed storage layer is compatible with the HDFS distributed file system architecture. The authorized storage nodes correspond to the HDFS data node roles. The authorized storage node pool maintained by the rights tree contract corresponds to the block location management function of the HDFS name node. The selection of the target node for replica reconstruction after a data node failure is subject to the mandatory constraint of the authorized storage node pool, replacing the original rack-aware replica placement strategy. This integrates the authorized boundary constraints into the Hadoop database storage management system, achieving low-intrusion integration and deployment of the existing Hadoop ecosystem infrastructure.

8. The system according to claim 2, characterized in that, In the physical storage layer encryption and deduplication process, the hash function uses the SHA3-256 algorithm, the symmetric encryption algorithm uses AES-256-GCM, and the initialization vector corresponding to each data block is randomly generated by the system with a length of 96 bits, and is stored together with the ciphertext block in the distributed storage layer.

9. The system according to claim 4, characterized in that, The proxy re-encryption mechanism adopts a one-way non-interactive proxy re-encryption scheme, during which the proxy smart contract cannot know the plaintext content of the file; After the proxy re-encryption calculation is completed, the proxy contract will remove the re-encryption key from the contract storage within the same atomic transaction. The lifespan of the re-encryption key is strictly limited to a single atomic transaction.

10. The system according to claim 1, characterized in that, In the rights tree contract, each node of the rights tree records a node identifier, attribute set, current state and bound attribute base encrypted ciphertext. The node state switches between four states: active, partially transferred, transferred and invalid, according to authorized operations. The connection between nodes indicates the authorization type, including full transfer, partial implementation rights and pledge; The historical state of the rights tree is immutably stored on the blockchain, fully recording the ownership hierarchy and lifecycle changes of intellectual property assets.

Images