Blockchain-based multi-modal heterogeneous data cross-domain management and trusted discovery method

Abstract

This invention discloses a blockchain-based method and apparatus for cross-domain management and trusted discovery of multimodal heterogeneous data, relating to the fields of data discovery and blockchain technology. The method includes: constructing a cross-chain data collaboration architecture, which uses blockchain intermediary nodes to complete cross-chain message forwarding, interface adaptation, and event monitoring, and combines a lightweight proof protocol and main-chain smart contracts to confirm the sidechain status, providing on-chain evidence for cross-domain data registration, access applications, and result traceability; abstracting a unified discovery object model from multimodal heterogeneous data resources, enabling public and non-public data to enter the data discovery process in a consistent manner; and employing a two-stage search method based on domain profiling, which generates domain profiling by aggregating discovery object information within a domain and selecting candidate data domains, performing multi-dimensional similarity calculations, association expansion, and unified sorting within the candidate domains to reduce the search overhead caused by full-domain traversal.

Description

Technical Field

[0001] This invention relates to the fields of data discovery and blockchain technology, and in particular to a method and apparatus for cross-domain management and trusted discovery of multimodal heterogeneous data based on blockchain. Background Technology

[0002] With the rapid development of high-end manufacturing, aerospace, electronic information, and new energy industries, technological innovation is increasingly reliant on data resources. However, in practical applications, large amounts of data are distributed across different platforms, collected and managed according to their respective processes. The same type of data object may correspond to different structures on different platforms. Platform data also exhibits varying degrees of openness, making cross-platform sharing impossible. Consequently, while data, as a new type of production resource, can accumulate continuously, it is difficult to form a unified data space capable of discovery, understanding, and on-demand reuse. The value of data in practical applications remains far from being fully realized.

[0003] To alleviate issues such as fragmented records, difficulties in defining responsibilities, and insufficient process traceability in multi-entity data sharing, blockchain technology is increasingly being introduced into data sharing platforms to enhance the traceability and auditability of data access processes. However, different entities may choose different blockchain systems based on their own business needs, and the resource isolation between existing data platforms further manifests as chain-level isolation in the blockchain environment. For multimodal heterogeneous data sharing, the system must not only address the structural differences of multimodal heterogeneous data itself but also solve the challenges of message transmission, status confirmation, and result recording across blockchains.

[0004] After the establishment of cross-domain collaboration mechanisms, multimodal heterogeneous data sharing must further address practical application challenges in the discovery phase. Traditional keyword retrieval mainly relies on literal word matching, which struggles to handle hierarchical categories, interval conditions, and structured attributes in multimodal heterogeneous data. Multimodal heterogeneous data discovery is also constrained by factors such as data not leaving its domain, on-chain state confirmation, and differences in metadata structure, making it impossible to simply apply methods used for retrieving ordinary datasets.

[0005] Therefore, building a cross-domain collaboration mechanism for cross-blockchain environments, and on this basis forming a unified representation and discovery method for multimodal heterogeneous data, is of great significance for unlocking the value of data. Summary of the Invention

[0006] To address the technical challenges of existing technologies in data collaboration across data domains and heterogeneous blockchain environments, unified organization of multimodal heterogeneous data, and discovery of cross-domain multimodal heterogeneous data, this invention provides a blockchain-based method and apparatus for cross-domain management and trusted discovery of multimodal heterogeneous data. The technical solution is as follows: On the one hand, a blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data is provided. This method is implemented by a blockchain-based device for cross-domain management and trusted discovery of multimodal heterogeneous data, and includes: S1. Construct a cross-chain data collaboration architecture for heterogeneous blockchains; wherein the architecture consists of multiple independent data domains and a blockchain convergence network located between the domains; each data domain deploys a blockchain; wherein the blockchain is divided into a main chain that coordinates the overall situation and side chains deployed in each data domain, and different data domains communicate and collaborate across domains through the blockchain convergence network; wherein the blockchain convergence network includes convergence nodes and a lightweight proof protocol module; S2. The uploaded multimodal heterogeneous data is divided into public data and non-public data. Each of them generates its own multimodal heterogeneous data discovery object according to the corresponding rules. After cross-chain verification of each discovery object through the side chain, the facilitator node and the lightweight proof protocol module, it is uploaded to the main chain to complete the global registration. S3. Perform two-stage cross-domain data discovery for the discovered objects in each data domain. In the first stage, extract the summary information of all discovered objects in each data domain and aggregate them to generate a domain-level profile. Combine this with the received user query requests to filter and obtain a set of candidate data domains. S4. Based on the obtained candidate data domain set, the second stage of processing is carried out. Multi-dimensional similarity calculations are performed on the discovered objects within the candidate data domain set to filter and obtain an initial candidate object set. Based on the association relationship of the discovered objects, the results are expanded, the initial candidate object set is uniformly sorted and deduplicated, and the discovered object results are output.

[0007] On the other hand, a blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device is provided. This device is applied to a blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery method, and includes: A building unit is used to construct a cross-chain data collaboration architecture for heterogeneous blockchains. This architecture consists of multiple independent data domains and a blockchain convergence network located between the domains. Each data domain deploys one blockchain. The blockchains are divided into a main chain that coordinates the overall operation and side chains deployed within each data domain. Different data domains communicate and collaborate across domains through the blockchain convergence network. The blockchain convergence network includes convergence nodes and a lightweight proof-of-capacity protocol module. The processing unit is used to divide the uploaded multimodal heterogeneous data into public data and non-public data, generate their respective multimodal heterogeneous data discovery objects according to the corresponding rules, and upload their respective discovery objects to the main chain after cross-chain verification through the side chain, the fuser node and the lightweight proof protocol module to complete global registration. The first-stage data discovery unit is used to perform two-stage cross-domain data discovery of the objects to be discovered in each data domain. In the first stage, the summary information of all objects to be discovered in each data domain is extracted and aggregated to generate a domain-level profile. Combined with the received user query requests, the profile is filtered to obtain a set of candidate data domains. The second-stage data discovery unit is used to perform second-stage processing based on the obtained candidate data domain set. It performs multi-dimensional similarity calculations on the discovered objects within the candidate data domain set to filter and obtain an initial candidate object set. Based on the association relationship of the discovered objects, it expands the results, uniformly sorts and removes duplicates from the initial candidate object set, and outputs the discovered object results.

[0008] On the other hand, a blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device is provided. The blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device includes: a processor; a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, any one of the methods described above for blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery is implemented.

[0009] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction is stored in the storage medium, the at least one instruction being loaded and executed by a processor to implement any of the above-described methods for cross-domain management and trusted discovery of multimodal heterogeneous data based on blockchain.

[0010] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following: This invention proposes a solution to the problems of data registration, state tracking, access control, and result confirmation under cross-data domain and cross-blockchain conditions, while taking into account the practical constraints of public data sharing and non-public data not leaving the domain. It provides traceable and verifiable on-chain evidence for cross-domain data registration and access processes. This invention unifies the representation of multimodal heterogeneous data from different sources during the discovery and management process, organizing it into comparable, traceable, and parsable data objects. This allows public and non-public data to enter the data discovery process in a consistent form, thereby reducing the impact of underlying data heterogeneity on cross-domain retrieval. This invention locates data objects from multiple data domains, effectively compressing the cross-domain search scope, achieving a good balance between query efficiency and result coverage, and providing a foundation for resource parsing and controlled access, thus unlocking data value. Attached Figure Description

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

[0012] Figure 1 This is a flowchart of a blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data, provided by an embodiment of the present invention. Figure 2 This is a diagram of a cross-chain data collaboration system architecture for heterogeneous blockchains provided in an embodiment of the present invention. Figure 3 This is a diagram of the cross-chain data collaboration function architecture for heterogeneous blockchains provided in this embodiment of the invention; Figure 4 This is a data interaction diagram between the main chain and side chain provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the overall process of the two-stage search method provided in this embodiment of the invention; Figure 6 This is a block diagram of a blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of a blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device provided in an embodiment of the present invention. Detailed Implementation

[0013] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0014] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0015] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0016] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0017] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0018] This invention provides a blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data. This method can be implemented using a blockchain-based device for cross-domain management and trusted discovery of multimodal heterogeneous data, which can be a terminal or a server. Figure 1 The flowchart shown is for a blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data. The processing flow of this method may include the following steps: S1. Construct a cross-chain data collaboration architecture for heterogeneous blockchains; the architecture consists of multiple independent data domains and a blockchain convergence network located between the domains; each data domain deploys a blockchain; the blockchain is divided into a main chain that coordinates the overall situation and side chains deployed in each data domain, and different data domains communicate and collaborate across domains through the blockchain convergence network; the blockchain convergence network includes convergence nodes and lightweight proof protocol modules.

[0019] Optionally, different chains are deployed for different data management entities or resource management scopes within a data domain. The main chain plays a coordinating role, serving as the blockchain deployed on the system's main platform and undertaking global registration, request organization, and result recording in cross-domain collaboration. Side chains, on the other hand, are responsible for maintaining the local data state and processing local responses within their respective data domains. A data domain is the basic unit for data resource organization, on-chain registration, and local management in a cross-chain data collaboration system oriented towards heterogeneous blockchains. Among them, the facilitator node is responsible for sidechain event listening, on-chain information reception, namespace isolation, and confirmation information forwarding; The lightweight proof protocol module is responsible for proving the operation information and object state returned by the sidechain.

[0020] in, Figure 2 The diagram shown is an architecture diagram of a cross-chain data collaboration system for heterogeneous blockchains provided by an embodiment of the present invention. Figure 2Data domains 1, 2, and 3 correspond to different data management entities or resource management scopes. Data domain 1 deploys main chain 1, while data domains 2 and 3 deploy side chains 1 and 2, respectively. Different data domains maintain relative independence in terms of management boundaries and on-chain states, avoiding direct point-to-point coupling and interaction. Instead, cross-domain communication and collaboration are achieved through inter-domain blockchain interoperators. Main chain 1, side chain 1, and side chain 2 do not directly call each other but establish bidirectional connections with the blockchain interoperator network. Main chain 1 plays a coordinating role, serving as the blockchain deployed on the system's main platform. It primarily handles global registration, request organization, and result recording in cross-domain collaboration. Side chains 1 and 2 are responsible for maintaining local data states and processing local responses within their respective data domains.

[0021] Among them, such as Figure 3 The diagram shown is a cross-chain data collaboration functional architecture diagram for heterogeneous blockchains provided by an embodiment of the present invention. Functionally, it can be divided into an application service layer, a cross-chain collaboration layer, a blockchain network layer, and an off-chain storage layer. This division represents a logical structure, intended to illustrate the tasks undertaken by each functional module during cross-chain data collaboration, and does not imply that the system strictly follows a fixed hierarchical transmission of requests during operation. The functions of each layer include: The application service layer provides a unified entry point for external users and is responsible for handling common functions directly related to business, including user registration, identity authentication, permission management, data upload, metadata management, data discovery, request parsing, format conversion, logging, and audit trails.

[0022] The cross-chain collaboration layer, located between the application service layer and the blockchain network layer, is responsible for the conversion, forwarding, and coordination of cross-domain requests across different blockchains. This layer includes a blockchain convergent layer, shared access support, and lightweight protocol proof. The blockchain convergent layer has multiple nodes, each connected to a blockchain network, responsible for message passing, interface adaptation, and event listening. The shared access support handles message sharing and log storage for the convergent nodes. The lightweight protocol proof module verifies key results in cross-chain interactions through checkpoint synchronization, receipt confirmation, and digest proof, ensuring that the processing results of cross-domain requests have verifiable acceptance criteria.

[0023] The blockchain network layer is the foundational environment for on-chain registration, control, and evidence storage, and it consists of a main chain and multiple side chains. Specifically, the main chain, located in the global coordination layer, is responsible for cross-domain object registration, result confirmation, state tracking, and providing a unified query entry point. Side chains, located within their respective data domains, are responsible for registering, updating, and confirming objects discovered within their domain, as well as maintaining shared state within that domain. Essentially, side chains in this architecture are business chains focused on domain-specific data management; their classification is based on whether they assume global coordination responsibilities, not on whether they exist as functional extensions of the main chain. Through collaboration between the main chain and side chains, the system can simultaneously achieve unified organization and domain-specific autonomy.

[0024] The off-chain storage layer is responsible for preserving the original data entities, forming a structure of on-chain registration and off-chain storage together with the blockchain network layer. Public data is stored in a centrally managed storage environment for easy maintenance and access, while non-public data remains within its respective data domain, participating in cross-domain collaborative discovery only through on-chain metadata, index information, or content summaries. This storage partitioning mechanism allows the system to simultaneously meet the needs of centralized management of public data and the requirement that non-public data remains within its domain.

[0025] Cross-domain data sharing mainly revolves around the cross-chain collaboration layer and the blockchain network layer, such as... Figure 4 The diagram illustrates the data interaction between the main chain and side chain according to an embodiment of the present invention. The side chain first completes data-related operations within its local domain and generates an on-chain registration result. This result includes the side chain identifier, data operation, data discovery object, on-chain block information, and transaction information. Next, the side chain sends the registration result to the connected fusing node. After receiving the information returned by the side chain, the blockchain fusing node invokes its local service to construct a proof request message and sends it to the lightweight proof protocol module. The lightweight proof protocol module verifies the state of the relevant object, calculates new state information, and binds the side chain operation result with the current object state, generating a proof receipt and a state binding result. Finally, the lightweight proof protocol module returns the proof receipt to the blockchain fusing node. The fusing node further organizes the information returned by the side chain and the proof receipt into main chain confirmation information and uploads it to the main chain through the fusing node connected to the main chain. The main chain's smart contract then completes the final registration, state update, and global confirmation.

[0026] The facilitator node can perform several functions, including: 1. Identity Authentication: Before joining, a fusing node needs to configure a local key, node certificate, chain access address, and contract interface in the corresponding namespace. Sidechain fusing nodes join the corresponding sidechain network accordingly, while mainchain fusing nodes connect to the mainchain smart contract. After starting, the node participates in message sending, event receiving, and contract invocation based on its data domain identity, ensuring that cross-chain operations are associated with a specific data domain, node, and on-chain account.

[0027] 2. Namespace Isolation: Namespaces are used to isolate the runtime contexts of different blockchains. In this embodiment of the invention, the main chain and each side chain have their own independent namespaces, which are used to maintain the connection configuration, identity information, contract interface, event listening scope, and return result format of the corresponding chain. Therefore, contract calls, event processing, and message flow of different chains are independent of each other, avoiding state confusion between heterogeneous chains in the same convergence network.

[0028] 3. Message Passing: The fusing nodes form a node network through peer-to-peer communication links. After receiving the on-chain operation results, the sidechain namespace organizes the sidechain identifier, data operation, data discovery object, and on-chain block transaction information into a unified message and transmits it to the lightweight proof protocol module and the main chain namespace. This process enables controlled communication between different namespaces, avoiding direct coupling between the main chain and the sidechain.

[0029] 4. Event Listening: The fusing node listens for data upload and update events in the corresponding sidechain namespace and receives information such as transaction hashes, block heights, and event digests. This function is used to perceive the results of on-chain operations completed on the sidechain and organize them into structured information required for proof processing and mainchain confirmation.

[0030] 5. Contract Interface Adaptation: The facilitator node provides a unified encapsulation of contract interfaces across different blockchains. For upper-layer processes, the node offers consistent entry points for contract calls and event reception; for lower-layer chains, the node converts unified operations into local calls executable on the target chain. This feature enables the system to uniformly call smart contracts from different blockchains, reducing the complexity of heterogeneous chain collaboration.

[0031] In one feasible implementation, a lightweight proof-of-concept module is used to bind the data operation results returned by the sidechain to the state records that can be referenced by the main chain, providing a basis for confirmation that the main chain accepts the registration results from the sidechain. This protocol does not perform complete verification of the underlying consensus process of heterogeneous blockchains, but rather forms a lightweight confirmation method oriented towards data state changes, focusing on data operations, object discovery, and checkpoint recording. The specific implementation process includes: 1. Checkpoint Construction: When constructing a checkpoint, the system collects data discovery objects that participate in sharing within the domain; secondly, the system performs deterministic sorting according to the object identifier in ascending order, and calculates each object as a leaf node of a hash tree; the leaf nodes are merged layer by layer and hashed upwards to obtain the checkpoint root; 2. Checkpoint Update: For new operations, the sidechain fusing node adds the corresponding discovery object to the shared object set of the domain; for update operations, it replaces the original discovery object and updates the version status; for invalidation operations, it retains the object record and modifies its status flag. After completing the object status set update, the sidechain fusing node recalculates the checkpoint root, forming a new checkpoint record. This new checkpoint can be submitted to the lightweight proof protocol module as the new checkpoint field in the proof request message.

[0032] 3. Checkpoint Verification: Checkpoint verification is performed by the Lightweight Proof Protocol module. After receiving a proof request, the protocol module uses the old checkpoint as the starting point of the state and, in conjunction with the current operation type, the discovered object, and the object digest, re-verifies the checkpoint result after the object state change. If the calculated result matches the new checkpoint in the proof request, it indicates that the object change has been correctly incorporated into the new shared object state. If the two do not match, it indicates a mismatch between the object state change, checkpoint calculation, or sidechain event information, and the protocol rejects the current state confirmation.

[0033] 4. After successful verification, the lightweight proof protocol module generates a proof receipt message and returns it to the main chain facilitator node. Upon receiving the proof receipt message, the main chain facilitator node organizes the proof receipt, sidechain transaction identifier, new checkpoint, and object state change information into main chain confirmation information and submits it to the main chain side smart contract.

[0034] 5. The main chain confirmation process is triggered by the main chain fusing node calling the contract confirmation function. This function receives parameters such as sidechain identifier, object identifier, operation type, sidechain transaction identifier, new checkpoint, proof receipt, and time information. The contract first checks the completeness of the parameters, ensuring that key fields such as sidechain identifier, object identifier, transaction identifier, and proof receipt are not empty. Second, it checks whether the transaction identifier and receipt identifier already exist in the processed index. If they already exist, the submission is rejected. After completing the basic checks, the contract reads the latest checkpoint of the sidechain stored on the main chain and compares it with the old checkpoint in the confirmation record to ensure that the current state update is based on the previous confirmed state of the main chain. When the proof receipt result is valid and the old checkpoint is consistent with the current record of the main chain, the contract writes the new checkpoint into the latest state record of the sidechain's data field and updates the checkpoint version and confirmation time simultaneously. At the same time, the contract writes the object change record and marks the sidechain transaction identifier and proof receipt identifier as processed. In this way, subsequent queries can obtain the latest checkpoint of the domain based on the sidechain identifier, or trace the corresponding cross-chain confirmation record based on the object identifier or transaction identifier.

[0035] In one feasible implementation, the blockchain fusing module is responsible for submitting sidechain events and proof receipts, the lightweight proof protocol module is responsible for checkpoint verification, and the main chain smart contract is responsible for parameter validation, state writing, replay protection, and audit queries. Through this implementation, the system can complete main chain confirmation and traceable registration of sidechain data operation results with relatively low on-chain overhead.

[0036] S2. The uploaded multimodal heterogeneous data is divided into public data and non-public data. Each of them generates its own multimodal heterogeneous data discovery object according to the corresponding rules. After cross-chain verification by the sidechain, the facilitator node and the lightweight proof protocol module, the discovery object is uploaded to the main chain to complete the global registration.

[0037] Optionally, the multimodal heterogeneous data discovery object is defined as a quintuple, represented by the following formula (1): (1) Here, ID represents the object identity identifier, used to uniquely identify a discovered object; SEM represents the discovery-level semantic profile, used to carry the core metadata that the object needs to expose during the discovery phase; COMMIT represents the consistency commitment, used to record the correspondence between the object and the on-chain registered transactions; RESOLVE represents the parsing information, used to explain the location method and access point of the resource corresponding to the object, and also includes version and validity; LINK represents the association relationship, used to describe the version derivation, reference or experimental simulation correspondence between the object and other objects.

[0038] Among them, the Discovery Object (DO) is introduced during the data upload phase. It further organizes the information already available during the data upload phase, retains the basic descriptive ability of metadata for resources, and further supplements the location, verification, and association information required for the subsequent discovery process. It uniformly extracts and encapsulates the information that the discovery task truly needs, so that data resources from different sources can enter the same discovery space in a consistent manner.

[0039] Both public and non-public data generate corresponding Discovery Objects (DOs) during the upload phase. The difference lies in the resource location, access path, and registration method associated with the DO. Public data corresponds to off-chain resources that can be directly accessed by the main platform, while non-public data corresponds to data resources that are reserved within the domain and subject to controlled access.

[0040] In one feasible implementation, the specific process of uploading public data and generating discovery objects includes: 1. Open a data node to submit public data, its metadata, and raw content to the web server. The metadata mainly includes title, summary, category, tags, and attribute descriptions, and the ID, SEM, and LINK parts of the DO can be extracted.

[0041] 2. After receiving the request, the web server writes the original content of the public data to the cloud server storage; 3. After the cloud server completes the write operation, it returns the storage location or access reference of the data to the web server. This result is used as the RESOLDE part of the DO (Document Requirement). 4. The web server generates the DO basic field. Since it has not yet been registered on the sidechain, the COMMIT content is empty. 5. The web server sends metadata and basic DO fields to the sidechain. After on-chain registration on the sidechain, the fusing agent fills in the sidechain block and transaction information into the COMMIT, thus completing the DO generation. Subsequently, the fusing agent sends the complete DO to the main chain for on-chain registration. 6. The blockchain network returns a confirmation message to the web server, indicating that DO has completed the on-chain write; 7. The web server returns a successful public data registration result to the public data node.

[0042] In one feasible implementation, the specific process of uploading non-public data and generating discovery objects includes: 1. Non-public data nodes submit non-public data and its metadata to the web server; 2. The web server uploads the original content of non-public data to the IPFS network within the local domain; 3. After the IPFS network completes storage, it returns the Content Identifier (CID) corresponding to the data to the web server. This result describes the location of the original data in the distributed storage within the domain and can serve as an important component of the RESOLVE section in the DO (Document Requirement). 4. The web server generates the DO basic field. Since it has not yet been registered on the sidechain, the COMMIT content is empty. 5. The web server sends metadata and basic DO fields to the sidechain. After the sidechain is registered on-chain, the fusing agent fills in the sidechain block and transaction information into the COMMIT, and the DO is now fully generated. Subsequently, the fusing agent sends the complete DO to the main chain for on-chain registration.

[0043] 6. The blockchain network returns a confirmation message to the web server; 7. The web server returns a successful registration result for non-public data to the non-public data node.

[0044] One feasible implementation method is, for example Figure 5The diagram shows the overall process of the two-stage search method provided in this embodiment of the invention. Taking a multi-domain DO set and a user query request as input, the method first generates a set of domain profiles by aggregating information from the discovery layer and selects candidate domains based on the query object. Then, it performs object-level multidimensional similarity calculations within the candidate domains to form an initial candidate set. Finally, it expands the results by combining the relationships between DOs and obtains the final result set through unified sorting and deduplication.

[0045] S3. Perform two-stage cross-domain data discovery for the discovered objects in each data domain. In the first stage, extract the summary information of all discovered objects in each data domain and aggregate them to generate a domain-level profile. Combine this with the received user query requests to filter and obtain a set of candidate data domains.

[0046] Optionally, the specific implementation process of S3 includes S31-S35: S31. Let the set of discovered objects in data domain d be Od={DO1,DO2,…,DOn}; extract the category label, keywords, condition range, and time range fields from the set of discovered objects to form an object-level discovery summary. ;in, This represents the set of categories to which the discovered object DOi belongs; This represents the set of keywords extracted from the title, abstract, tags, and keyword content. This indicates the range of conditions involved in the discovery object, which is a range constraint. Indicates the time range corresponding to the data release or update; S32. Aggregate the discovery summaries of all discovered objects within the same domain to generate a domain-level profile; wherein, the domain-level profile includes: a set of object categories within the domain, a set of keywords within the domain, a set of condition ranges within the domain, and a time range within the domain; Specifically, for the category set and keyword set, a set union operation is used to preserve the category space and keyword space covered by the domain; for the condition range set, the ranges of fields with the same name are merged according to the field type to obtain the overall coverage range of the domain on the relevant condition range; for the time range, the overall time coverage range of the domain's data resources is determined based on the time information of the objects discovered within the domain. The domain profile corresponding to data domain d can be defined as follows: ; in, Represents a collection of object categories within a domain; Represents the set of keywords within a domain; Represents the set of conditions within the domain; Time range within the domain; in, It can be expressed by the following formula (2): (2) in, It can be expressed by the following formula (3): (3) in, It can be expressed by the following formula (4): (4) in, It can be expressed by the following formula (5): (5) MergeRange(·) represents the operation of merging range-type conditions according to field type; MergeTime(·) represents the operation of merging time ranges. This represents the set of discovered objects in the data domain d.

[0047] S33. Standardize the received user query requests into a unified query object; wherein, the query object is represented as... , Constraints for object categories, As a keyword constraint, For the condition range constraint, Time range constraint; S34. Compare the query object with the domain-level profile and calculate the coverage of the domain profile to the query. Based on the coverage, calculate the matching degree between the data domain d and the query object. The matching degree between the data field d and the query object Q can be expressed by the following formula (6): (6) in, Indicates the coverage of categories; Indicates keyword coverage; Indicates the coverage of the condition range; This indicates the time range coverage, and its value range is [0,1].

[0048] For set-type features such as categories and keywords, query coverage is used to calculate the matching degree. This is because the focus of the candidate domain selection stage is not on the symmetrical similarity between the domain profile and the query set, but rather on the extent to which the category constraints and keyword constraints given in the query requirements can be covered by the domain.

[0049] The category coverage can be expressed by the following formula (7): (7) The keyword coverage can be expressed by the following formula (8): (8) in, This indicates the degree of coverage of query category constraints within the domain profile category set; This indicates the degree of coverage of the query keyword constraints within the domain profile keyword set.

[0050] For interval-type features such as condition range and time range, interval length coverage is used as the metric. Since the condition range within the same data domain may consist of multiple discontinuous intervals, the range feature in the domain profile is represented as the union of several intervals. Let the query condition range be... The set of conditions in the domain profile is Then the coverage of the condition range It can be expressed by the following formula (9): (9) Where µ(·) represents the total length of the interval set. When it consists of multiple discontinuous intervals, ∩ This represents the overlapping portion of the query interval and the union of these intervals, and its length is the sum of the lengths of all overlapping sub-intervals.

[0051] The time range coverage can be expressed by the following formula (10): (10) in, This indicates the total length of the time range covered by this field.

[0052] S35. Based on the matching degree between data domain d and the query object, define the total matching score of the query object in data domain d; sort all domains in descending order according to the total matching score, and select the top k domains with the highest scores as the candidate domain set.

[0053] In one feasible implementation, the total matching score of the query object in data domain d is the arithmetic mean of the coverage of each dimension, which can be expressed by the following formula (11): (11) In one feasible implementation, the first k domains as a candidate domain set can be represented by the following formula (12): (12) in, This indicates that the first k fields are considered as the candidate field set. This represents the total match score of the query object in data field d.

[0054] In the first stage, cross-domain data discovery is transformed from a unified traversal of the entire domain to a coarse-grained screening within the domain-level space. This significantly reduces the candidate size for subsequent object-level matching, improves the overall discovery efficiency, and allows the discovery process to first focus on the domain-level resource coverage features, without having to access the fine-grained semantic information of all objects in the initial stage.

[0055] S4. Based on the obtained candidate data domain set, the second stage of processing is carried out. Multi-dimensional similarity calculations are performed on the discovered objects within the candidate data domain set to filter and obtain an initial candidate object set. Based on the association relationship of the discovered objects, the results are expanded, the initial candidate object set is uniformly sorted and deduplicated, and the discovered object results are output.

[0056] Optionally, multi-dimensional similarity includes: category similarity, keyword similarity, range similarity, and structural similarity; Among them, category similarity is used to measure the degree of consistency between the category constraints in the query and the category information of the object; Keyword similarity is used to measure the degree of overlap between the query keyword set and the object keyword set. Among them, range similarity is used to measure the degree of fit between objects in terms of time and other interval-type conditions; Structural similarity measures the completeness of the organization of objects across the semantic fields required by the query.

[0057] Optionally, the specific implementation process of S4 includes S41-S416: S41. Construct a candidate object space from all discovered objects in the candidate domain set; based on the candidate object space, calculate the similarity score between any candidate object and the query object based on category similarity, keyword similarity, range similarity, and structural similarity. Here, all objects in the candidate domain set constitute the candidate object space OQ. For any object DOi∈OQ, its relevance to the query is calculated from four aspects: category similarity, keyword similarity, range similarity, and structural similarity.

[0058] Let the set of query categories be . The object category set is Then, the Jaccard similarity is used to define the category matching degree, which is expressed by the following formula (13): (13) Here, J(·,·) represents the Jaccard similarity. This dimension measures the degree of overlap between the query category and the object category, ensuring that the object is first located in a relatively consistent semantic category space, thereby avoiding the inclusion of objects that are obviously unrelated in the category in the subsequent ranking.

[0059] Let the set of keywords for the object be . Then, the keyword matching degree is defined using Jaccard similarity, which can be expressed by the following formula (14): (14) The role of this dimension is to characterize the similarity of objects in terms of topic expression and descriptive semantics, thereby supplementing the fine-grained semantic information that category matching cannot reflect.

[0060] For the k-th interval field involved in the query, let the query interval be... Its object range is .

[0061] In one feasible implementation, the interval matching degree on the field can be defined using the interval Jaccard similarity, expressed by the following formula (15): (15) in, Indicates the overlap length between the query range and the object range; This represents the length of the union of the query interval and the target interval. This definition reflects both the degree to which the query interval is covered by the target interval and the precision of the target interval itself. When the two are completely disjoint, the matching degree is 0; when they are completely identical, the matching degree is 1; when the target interval is wider than the query interval, the matching degree decreases as the union length increases.

[0062] In one feasible implementation, after calculating the interval matching degree for each of the multiple interval fields in the query, the matching results of the fields are averaged to obtain the overall range similarity score between object DOi and query Q, which can be expressed by the following formula (16): (16) In one feasible implementation, structural similarity matching is introduced to measure the organizational integrity of objects across the semantic fields required by the query. A query bitmap and an object bitmap are constructed separately within a unified semantic field space; wherein, the query bitmap is... The object bitmap is If the query or object provides valid information in the j-th semantic field, the corresponding position is set to 1; otherwise, it is set to 0. Using cosine similarity calculation, the structural similarity matching definition of objects can be expressed by the following formula (17): (17) The structural similarity matching of objects does not directly evaluate whether field values ​​are consistent, but rather whether the object provides sufficiently complete information on the key fields required by the query. The necessity of introducing this dimension lies in the fact that during calculations such as range matching, if some objects are missing fields required by the query, and the missing values ​​are filled in by default or treated leniently, it can easily lead to objects receiving excessively high scores. Structural similarity matching can correct this situation: when an object is missing key fields required by the query, the overlap between its bitmap and the query bitmap will decrease, thus suppressing its performance in the overall ranking. Therefore, this dimension measures not the local matching of objects on existing fields, but whether the object truly possesses the field structure to carry the information required for this query.

[0063] S42. Based on the similarity score between any candidate object and the query object, calculate the direct matching score of all candidate objects in the candidate object space to the query object, expressed by the following formula (18): (18) in, This represents the direct match score of all candidate objects in the candidate object space for the query object. Indicates candidate objects The overall category of the query object Q; Indicates candidate objects Overall keyword similarity score with query object Q; Indicates candidate objects Similarity score to the overall range of the query object Q; Indicates candidate objects The overall structural similarity score with the query object Q; S43. Based on the direct matching scores of all candidate objects in the candidate object space to the query object, sort them in descending order of matching scores, and select the k objects with the highest scores to form an initial candidate set; perform association expansion on the initial candidate set to obtain an expanded object set; The first k objects constitute the initial candidate set. It can be expressed by the following formula (19): (19) In this embodiment, after the initial candidate set is formed, further association expansion is performed based on the LINK relationship of DOs. This embodiment of the invention considers that some objects, although not necessarily having the highest direct match with the query, have meaningful associations with high-scoring candidate objects, such as the correspondence between experimental objects and simulation objects, the citation relationship or version association relationship between paper objects and experimental objects, and derivation relationships. These objects can supplement the final result set with contextual information and therefore should be included in the candidate results. Let's assume... The new set of objects obtained through association extension is It can be expressed by the following formula (20): (20) Among them, for the objects obtained by expansion First, the direct match score between the expanded object and the query is calculated, and then its supplementary role in the association expansion is considered. Let the set of objects from which the expanded objects originate be... Its source score is defined by the following formula (21): (twenty one) S44. Calculate the direct match score between the extended object set and the query object; assign deterministic relation gains to the extended objects according to the relation type, and define the relation gains; Among them, a deterministic relation gain is assigned to the extended object according to the relation type. Let the relation type between the objects be rel(DOi,DOj), then the relation gain can be expressed by the following formula (22): (twenty two) in, Indicates relational gain; Indicates version association; Indicates a derivation relationship; Indicates the relation type; Indicates the correspondence between experimental simulations; Indicates a reference relationship.

[0064] S45. Calculate the expansion score of the extended object based on the direct matching score and relational gain between the extended object set and the query object; In one feasible implementation, the expansion score of the extended object It can be obtained by calculating the arithmetic mean of the source score and the relation gain, expressed by the following formula (23): (twenty three) S46. Based on the extended score, sort the initial candidate objects and extended objects in a unified manner, and output the final sorting score of the objects; sort all objects in descending order according to the final sorting score of the objects, and remove duplicates according to the object identifier ID, and select the top k objects with the highest scores as the final discovered objects.

[0065] Among them, the final sorting score of the object It can be expressed by the following formula (24): (twenty four) The final result of the object discovery is expressed by the following formula (25): (25) in, Combined results.

[0066] In one feasible implementation, the object-level discovery process consists of four stages: similarity calculation, initial screening, association expansion, and unified ranking. First, through comprehensive matching based on dimensions such as category, keywords, interval conditions, and structural integrity, initial candidate objects that are relatively close to the query requirements are obtained. Second, based on the initial results, the relationships between objects are used to expand the results and supplement related objects with contextual connections. Finally, the directly matched objects and the expanded objects are uniformly ranked to form the final result set.

[0067] Optionally, after the steps of S4, which involve performing a second-stage processing based on the obtained candidate data domain set, calculating multi-dimensional similarity among the discovered objects within the candidate data domain set, filtering to obtain an initial candidate object set, expanding the results based on the association relationships of the discovered objects, uniformly sorting and deduplicating the initial candidate object set, and outputting the discovered object results, the process also includes: The discovered object results are sent to the blockchain conduit, which then forwards them to the main chain for access registration, authorization confirmation, and resource resolution.

[0068] In actual system operation, cross-domain data discovery not only needs to return a set of relevant discovery objects, but also needs to further combine the data openness attributes to complete access registration, authorization confirmation, and resource resolution. Because public and non-public data differ in storage location, access control, and acquisition methods, the processing flow after obtaining the discovery results is different.

[0069] In one feasible implementation, the specific process of cross-domain data discovery to obtain publicly available data includes: 1. The data requester submits a data discovery request to the web server. The request includes constraint information such as object category, keywords, condition range, and time range. After receiving the request, the web server organizes it into a unified query object Q, which serves as the input for subsequent discovery processing. 2. The web server performs a two-stage search process based on the query object Q, obtaining a set of DO results R={DO1,DO2,...,DOn} related to the query request. Subsequent retrieval processes are built upon the publicly available data target object DOi selected by the user from the result set R. 3. When a user decides to further view or obtain a public data object DOi, the web server generates a corresponding access request around the object and sends the object identifier IDi, the request identifier reqID, and the requester's identity information to the blockchain exchange. 4. After receiving the request, the blockchain conduit forwards it to the main chain for access registration; after the main chain completes the registration process, it returns the approval result; the blockchain conduit then forwards the approval result to the web server. 5. Once the approval is successful, the web server reads the parsed information RESOLVEi from the target object DOi and sends a public data retrieval request to the cloud server based on the storage location and access entry point recorded therein.

[0070] In one feasible implementation, the specific process of cross-domain data discovery to obtain non-public data includes: 1. The data requester submits a data discovery request to the web server; 2. The web server performs a two-stage search to obtain a set of DO results R={DO1,DO2,...,DOn} related to the query requirements; 3. When a user requests access to a non-public data object DOi, the web server generates an access request around the object and sends the object identifier IDi, the request identifier reqID, and the applicant's identity information to the blockchain exchange. 4. The blockchain intermediary forwards the data to the main chain for access registration; 5. The main chain will return the registration result corresponding to this access request to the blockchain exchanger; this return result indicates that the access request has been recorded on the main chain side; 6. After the main chain registration is completed, the blockchain intermediary continues to forward the access request to the target side chain. At this point, the access request enters the processing stage from the main platform side to the target data domain side. 7. The target sidechain completes the approval process according to the domain access control rules and returns the approval result to the blockchain fiducializer; the approval result clearly indicates whether the access request is allowed to proceed to the subsequent data acquisition stage; 8. After receiving the approval results from the sidechain, the blockchain conduit will send the final results back to the web server, so that the application side can obtain the approval results from both the main chain and the corresponding sidechain. Both must be approved before the data can be accessed. 9. When the approval result is passed, the Web server initiates a non-public data retrieval request to IPFS within the domain based on the RESOLVEi parsing information in the target object's DOi; where RESOLVEi is used to provide the data location information corresponding to the object, enabling the Web server to parse the target data resource based on the object; 10. PFS returns the corresponding non-public data content based on RESOLVEi; the web server organizes the returned data results and feeds back the data content list to the data requester, completing the process of non-public data from query request, object discovery, main chain registration, side chain approval to data acquisition.

[0071] This invention can be applied to the following fields: In the materials field, under a new materials big data center architecture of one main platform + N data resource nodes, data such as experimental records, simulation results, test data, and process parameters generated during materials research and development can be managed and shared across multiple resource nodes; In the medical field, it protects medical privacy data, enables secure sharing of electronic medical records and mutual recognition of examination and test results among medical institutions, and constructs a trusted data space; In the financial field, it isolates highly sensitive data in the financial industry, enabling verification of business data and linkage of asset supervision among financial institutions.

[0072] This invention proposes a solution to the problems of data registration, state tracking, access control, and result confirmation under cross-data domain and cross-blockchain conditions, while taking into account the practical constraints of public data sharing and non-public data not leaving the domain. It provides traceable and verifiable on-chain evidence for cross-domain data registration and access processes. This invention unifies the representation of multimodal heterogeneous data from different sources during the discovery and management process, organizing it into comparable, traceable, and parsable data objects. This allows public and non-public data to enter the data discovery process in a consistent form, thereby reducing the impact of underlying data heterogeneity on cross-domain retrieval. This invention locates data objects from multiple data domains, effectively compressing the cross-domain search scope, achieving a good balance between query efficiency and result coverage, and providing a foundation for resource parsing and controlled access, thus unlocking data value.

[0073] Figure 6 This is a block diagram of a blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device, provided by an embodiment of the present invention. This device is used for a blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery method. (Refer to...) Figure 6 The device includes a construction unit 610, a processing unit 620, a first-stage data discovery unit 630, and a second-stage data discovery unit 640. Wherein: Construction unit 610 is used to construct a cross-chain data collaboration architecture for heterogeneous blockchains; wherein, the architecture consists of multiple independent data domains and a blockchain convergence network located between the domains; each data domain deploys a blockchain; wherein, the blockchain is divided into a main chain that coordinates the overall situation and side chains deployed in each data domain, and different data domains communicate and collaborate across domains through the blockchain convergence network; wherein, the blockchain convergence network includes convergence nodes and a lightweight proof protocol module; The processing unit 620 is used to divide the uploaded multimodal heterogeneous data into public data and non-public data, generate their respective multimodal heterogeneous data discovery objects according to the corresponding rules, and upload their respective discovery objects to the main chain after cross-chain verification through the side chain, the fuser node and the lightweight proof protocol module to complete global registration. The first-stage data discovery unit 630 is used to perform two-stage cross-domain data discovery of the discovery objects in each data domain. In the first stage, the summary information of all discovery objects in each data domain is extracted and aggregated to generate a domain-level profile. Combined with the received user query requests, the profile is filtered to obtain a set of candidate data domains. The second-stage data discovery unit 640 is used to perform second-stage processing based on the obtained candidate data domain set. It performs multi-dimensional similarity calculations on the discovered objects within the candidate data domain set to filter and obtain an initial candidate object set. Based on the association relationship of the discovered objects, it expands the results, uniformly sorts and removes duplicates from the initial candidate object set, and outputs the discovered object results.

[0074] Optionally, different chains are deployed for different data management entities or resource management scopes corresponding to the data domains. The main chain plays a coordinating role and undertakes the functions of global registration, request organization, and result recording in cross-domain collaboration. The side chains are responsible for maintaining the local data status and processing local responses within their respective data domains.

[0075] Among them, the facilitator node is responsible for sidechain event listening, on-chain information reception, namespace isolation, and confirmation information forwarding; The lightweight proof protocol module is responsible for proving the operation information and object state returned by the sidechain.

[0076] Optionally, the multimodal heterogeneous data discovery object is defined as a quintuple, represented by the following formula (26): (26) Here, ID represents the object identity identifier, used to uniquely identify a discovered object; SEM represents the discovery-level semantic profile, used to carry the core metadata that the object needs to expose during the discovery phase; COMMIT represents the consistency commitment, used to record the correspondence between the object and the on-chain registered transactions; RESOLVE represents the parsing information, used to explain the location method and access point of the resource corresponding to the object, and also includes version and validity; LINK represents the association relationship, used to describe the version derivation, reference or experimental simulation correspondence between the object and other objects.

[0077] Optionally, the first-stage data discovery unit 630 is used for: Let the set of discovered objects in data domain d be Od={DO1,DO2,…,DOn}; extract the category label, keywords, condition range, and time range fields from the set of discovered objects to form an object-level discovery summary. ;in, This represents the set of categories to which the discovered object DOi belongs; This represents the set of keywords extracted from the title, abstract, tags, and keyword content. This indicates the range of conditions involved in the discovery object, which is a range constraint. Indicates the time range corresponding to the data release or update; The discovery summaries of all discovered objects within the same domain are aggregated to generate a domain-level profile; the domain-level profile includes: a set of object categories within the domain, a set of keywords within the domain, a set of condition ranges within the domain, and a time range within the domain. Specifically, for the category set and keyword set, a set union operation is used to preserve the category space and keyword space covered by the domain; for the condition range set, the ranges of fields with the same name are merged according to the field type to obtain the overall coverage range of the domain on the relevant condition range; for the time range, the overall time coverage range of the domain's data resources is determined based on the time information of the objects discovered within the domain. The received user query requests are standardized into a unified query object; whereby the query object is represented as... , Constraints for object categories, As a keyword constraint, For the condition range constraint, Time range constraint; The query object is compared with the domain-level profile, and the coverage of the domain profile with the query is calculated. Based on the coverage, the matching degree between the data domain d and the query object is calculated. Based on the matching degree between data domain d and the query object, the total matching score of the query object in data domain d is defined; all domains are sorted in descending order according to the total matching score, and the top k domains with the highest scores are selected as the candidate domain set.

[0078] Optionally, the multi-dimensional similarity includes: category similarity, keyword similarity, range similarity, and structural similarity; Among them, category similarity is used to measure the degree of consistency between the category constraints in the query and the category information of the object; Keyword similarity is used to measure the degree of overlap between the query keyword set and the object keyword set; Among them, range similarity is used to measure the degree of fit between objects in terms of time and other interval-type conditions; Structural similarity measures the completeness of the organization of objects across the semantic fields required by the query.

[0079] Optionally, the second-stage data discovery unit 640 is used for: All discovered objects in the candidate domain set constitute the candidate object space; based on the candidate object space, the similarity score between any candidate object and the query object is calculated based on category similarity, keyword similarity, range similarity and structural similarity. Based on the similarity score between any candidate object and the query object, the direct matching score of all candidate objects in the candidate object space to the query object is calculated, and expressed by the following formula (27): (27) in, This represents the direct match score of all candidate objects in the candidate object space for the query object. Indicates candidate objects The overall category of the query object Q; Indicates candidate objects Overall keyword similarity score with query object Q; Indicates candidate objects Similarity score to the overall range of the query object Q; Indicates candidate objects The overall structural similarity score with the query object Q; Based on the direct matching scores of all candidate objects in the candidate object space to the query object, they are sorted in descending order of matching scores, and the top k objects with the highest scores are selected to form an initial candidate set; the initial candidate set is then expanded by association to obtain an expanded object set. Calculate the direct match score between the extended object set and the query object; assign deterministic relation gains to the extended objects based on the relation type, and define the relation gains; Calculate the expansion score of the expanded object based on the direct matching score and relation gain between the expanded object set and the query object; The initial candidate objects and extended objects are uniformly sorted based on the extended scores, and the final sorting scores of the objects are output. All objects are sorted in descending order according to their final sorting scores, and duplicates are removed based on the object ID. The top k objects with the highest scores are selected as the final discovered objects.

[0080] Optionally, after the steps of performing a second-stage processing based on the obtained candidate data domain set, calculating multi-dimensional similarity of the discovered objects within the candidate data domain set to filter and obtain an initial candidate object set; expanding the results based on the association relationships of the discovered objects, uniformly sorting and deduplicating the initial candidate object set, and outputting the discovered object results, the process further includes: The discovered object results are sent to the blockchain conduit, which then forwards them to the main chain for access registration, authorization confirmation, and resource resolution.

[0081] This invention proposes a solution to the problems of data registration, state tracking, access control, and result confirmation under cross-data domain and cross-blockchain conditions, while taking into account the practical constraints of public data sharing and non-public data not leaving the domain. It provides traceable and verifiable on-chain evidence for cross-domain data registration and access processes. This invention unifies the representation of multimodal heterogeneous data from different sources during the discovery and management process, organizing it into comparable, traceable, and parsable data objects. This allows public and non-public data to enter the data discovery process in a consistent form, thereby reducing the impact of underlying data heterogeneity on cross-domain retrieval. This invention locates data objects from multiple data domains, effectively compressing the cross-domain search scope, achieving a good balance between query efficiency and result coverage, and providing a foundation for resource parsing and controlled access, thus unlocking data value.

[0082] Figure 7 This is a schematic diagram of the structure of a blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device provided in an embodiment of the present invention, as shown below. Figure 7 As shown, a blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device may include the above-mentioned... Figure 6 The illustrated device is a blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery apparatus. Optionally, the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery apparatus 710 may include a first processor 2001.

[0083] Optionally, the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device 710 may also include a memory 2002 and a transceiver 2003.

[0084] The first processor 2001, memory 2002, and transceiver 2003 can be connected via a communication bus.

[0085] The following is combined Figure 7 A detailed introduction to each component of the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device 710 is provided below: The first processor 2001 is the control center of the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device 710. It can be a single processor or a collective term for multiple processing elements. For example, the first processor 2001 can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of the present invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0086] Optionally, the first processor 2001 can perform various functions of the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device 710 by running or executing software programs stored in the memory 2002 and calling data stored in the memory 2002.

[0087] In a specific implementation, as one example, the first processor 2001 may include one or more CPUs, for example... Figure 7 CPU0 and CPU1 are shown in the diagram.

[0088] In a specific implementation, as one example, the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device 710 may also include multiple processors, for example... Figure 7 The first processor 2001 and the second processor 2004 are shown in the diagram. Each of these processors can be a single-core processor or a multi-core processor. Here, a processor can refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0089] The memory 2002 is used to store the software program that executes the present invention, and is controlled by the first processor 2001 to execute it. The specific implementation method can be referred to the above method embodiment, and will not be repeated here.

[0090] Optionally, the memory 2002 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 2002 may be integrated with the first processor 2001 or exist independently, and may be connected via the interface circuit of the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device 710. Figure 7 (Not shown in the image) is coupled to the first processor 2001, and this embodiment of the invention does not specifically limit this.

[0091] The transceiver 2003 is used to communicate with network devices or with terminal devices.

[0092] Alternatively, transceiver 2003 may include a receiver and a transmitter. Figure 7 (Not shown separately). The receiver is used to implement the receiving function, and the transmitter is used to implement the transmitting function.

[0093] Optionally, the transceiver 2003 can be integrated with the first processor 2001 or exist independently, and can be connected via the interface circuit of the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device 710. Figure 7 (Not shown in the image) is coupled to the first processor 2001, and this embodiment of the invention does not specifically limit this.

[0094] It should be noted that, Figure 7 The structure of the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device 710 shown does not constitute a limitation on the router. Actual blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery devices may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0095] Furthermore, the technical effects of the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device 710 can be referenced from the technical effects of the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery method described in the above method embodiments, and will not be repeated here.

[0096] It should be understood that the first processor 2001 in the embodiments of the present invention may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or it may be any conventional processor, etc.

[0097] It should also be understood that the memory in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0098] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0099] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0100] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0101] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0102] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0103] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0104] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0105] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0106] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0107] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0108] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data, characterized in that, The method includes: S1. Construct a cross-chain data collaboration architecture for heterogeneous blockchains; wherein the architecture consists of multiple independent data domains and a blockchain convergence network located between the domains; each data domain deploys a blockchain; wherein the blockchain is divided into a main chain that coordinates the overall situation and side chains deployed in each data domain, and different data domains communicate and collaborate across domains through the blockchain convergence network; wherein the blockchain convergence network includes convergence nodes and a lightweight proof protocol module; S2. The uploaded multimodal heterogeneous data is divided into public data and non-public data. Each of them generates its own multimodal heterogeneous data discovery object according to the corresponding rules. After cross-chain verification of each discovery object through the side chain, the facilitator node and the lightweight proof protocol module, it is uploaded to the main chain to complete the global registration. S3. Perform two-stage cross-domain data discovery for the discovered objects in each data domain. In the first stage, extract the summary information of all discovered objects in each data domain and aggregate them to generate a domain-level profile. Combine this with the received user query requests to filter and obtain a set of candidate data domains. S4. Based on the obtained candidate data domain set, the second stage of processing is carried out. Multi-dimensional similarity calculations are performed on the discovered objects within the candidate data domain set to filter and obtain an initial candidate object set. Based on the association relationship of the discovered objects, the results are expanded, the initial candidate object set is uniformly sorted and deduplicated, and the discovered object results are output.

2. The blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data as described in claim 1, characterized in that, The data domains are deployed with different chains for different data management entities or resource management scopes. The main chain plays a coordinating role, undertaking the functions of global registration, request organization, and result recording in cross-domain collaboration. The side chains are responsible for maintaining the local data status and processing local responses within their respective data domains. Among them, the facilitator node is responsible for sidechain event listening, on-chain information reception, namespace isolation, and confirmation information forwarding; The lightweight proof protocol module is responsible for proving the operation information and object state returned by the sidechain.

3. The X-based blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data as described in claim 1, characterized in that, The multimodal heterogeneous data discovery object is defined as a quintuple, represented by the following formula (1): （1） Here, ID represents the object identity identifier, used to uniquely identify a discovered object; SEM represents the discovery-level semantic profile, used to carry the core metadata that the object needs to expose during the discovery phase; COMMIT represents the consistency commitment, used to record the correspondence between the object and the on-chain registered transactions; RESOLVE represents the parsing information, used to explain the location method and access point of the resource corresponding to the object, and also includes version and validity; LINK represents the association relationship, used to describe the version derivation, reference or experimental simulation correspondence between the object and other objects.

4. The blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data as described in claim 1, characterized in that, In the first stage of S3, summary information of all discovered objects in each data domain is extracted and aggregated to generate a domain-level profile. This profile is then filtered in conjunction with received user query requests to obtain a set of candidate data domains, including: S31. Let the set of discovered objects in data domain d be Od={DO1,DO2,…,DOn}; extract the category label, keywords, condition range, and time range fields from the set of discovered objects to form an object-level discovery summary. ;in, This represents the set of categories to which the discovered object DOi belongs; This represents the set of keywords extracted from the title, abstract, tags, and keyword content. This indicates the range of conditions involved in the discovery object, which is a range constraint. Indicates the time range corresponding to the data release or update; S32. Aggregate the discovery summaries of all discovered objects within the same domain to generate a domain-level profile; wherein, the domain-level profile includes: a set of object categories within the domain, a set of keywords within the domain, a set of condition ranges within the domain, and a time range within the domain; Specifically, for the category set and keyword set, a set union operation is used to preserve the category space and keyword space covered by the domain; for the condition range set, the ranges of fields with the same name are merged according to the field type to obtain the overall coverage range of the domain on the relevant condition range; for the time range, the overall time coverage range of the domain's data resources is determined based on the time information of the objects discovered within the domain. S33. Standardize the received user query requests into a unified query object; wherein, the query object is represented as... , Constraints for object categories, As a keyword constraint, For the condition range constraint, Time range constraint; S34. Compare the query object with the domain-level profile and calculate the coverage of the domain profile to the query. Based on the coverage, calculate the matching degree between the data domain d and the query object. S35. Based on the matching degree between data domain d and the query object, define the total matching score of the query object in data domain d; sort all domains in descending order according to the total matching score, and select the top k domains with the highest scores as the candidate domain set.

5. The blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data as described in claim 1, characterized in that, The multi-dimensional similarity includes: category similarity, keyword similarity, range similarity, and structural similarity; Among them, category similarity is used to measure the degree of consistency between the category constraints in the query and the category information of the object; Keyword similarity is used to measure the degree of overlap between the query keyword set and the object keyword set. Among them, range similarity is used to measure the degree of fit between objects in terms of time and other interval-type conditions; Structural similarity measures the completeness of the organization of objects across the semantic fields required by the query.

6. The blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data as described in claim 1, characterized in that, The second stage of processing in S4 is based on the obtained candidate data domain set. Multi-dimensional similarity calculations are performed on the discovered objects within the candidate data domain set to filter and obtain an initial candidate object set. Based on the relationships between the discovered objects, the results are expanded. The initial candidate object set is uniformly sorted and deduplicated, and the discovered object results are output, including: S41. Construct a candidate object space from all discovered objects in the candidate domain set; based on the candidate object space, calculate the similarity score between any candidate object and the query object based on category similarity, keyword similarity, range similarity, and structural similarity. S42. Based on the similarity score between any candidate object and the query object, calculate the direct matching score of all candidate objects in the candidate object space to the query object, expressed by the following formula (2): （2） in, This represents the direct match score of all candidate objects in the candidate object space for the query object. Indicates candidate objects The overall category of the query object Q; Indicates candidate objects Overall keyword similarity score with query object Q; Indicates candidate objects Similarity score to the overall range of the query object Q; Indicates candidate objects The overall structural similarity score with the query object Q; S43. Based on the direct matching scores of all candidate objects in the candidate object space to the query object, sort them in descending order of matching scores, and select the k objects with the highest scores to form an initial candidate set; perform association expansion on the initial candidate set to obtain an expanded object set; S44. Calculate the direct match score between the extended object set and the query object; assign deterministic relation gains to the extended objects according to the relation type, and define the relation gains; S45. Calculate the expansion score of the extended object based on the direct matching score and relational gain between the extended object set and the query object; S46. Based on the extended score, sort the initial candidate objects and extended objects in a unified manner, and output the final sorting score of the objects; sort all objects in descending order according to the final sorting score of the objects, and remove duplicates according to the object identifier ID, and select the top k objects with the highest scores as the final discovered objects.

7. The blockchain-based method for cross-domain management and trusted discovery of multimodal heterogeneous data as described in claim 1, characterized in that, The second stage of processing in S4 is based on the obtained candidate data domain set. Multi-dimensional similarity calculations are performed on the discovered objects within the candidate data domain set to filter and obtain an initial candidate object set. After expanding the results based on the relationships between the discovered objects, uniformly sorting and deduplicating the initial candidate object set, and outputting the discovered object results, the process also includes: The discovered object results are sent to the blockchain conduit, which then forwards them to the main chain for access registration, authorization confirmation, and resource resolution.

8. A blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device, wherein the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device is used to implement the blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery method as described in any one of claims 1-7, characterized in that, The device includes: A building unit is used to construct a cross-chain data collaboration architecture for heterogeneous blockchains. This architecture consists of multiple independent data domains and a blockchain convergence network located between the domains. Each data domain deploys one blockchain. The blockchains are divided into a main chain that coordinates the overall operation and side chains deployed within each data domain. Different data domains communicate and collaborate across domains through the blockchain convergence network. The blockchain convergence network includes convergence nodes and a lightweight proof-of-capacity protocol module. The processing unit is used to divide the uploaded multimodal heterogeneous data into public data and non-public data, generate their respective multimodal heterogeneous data discovery objects according to the corresponding rules, and upload their respective discovery objects to the main chain after cross-chain verification through the side chain, the fuser node and the lightweight proof protocol module to complete global registration. The first-stage data discovery unit is used to perform two-stage cross-domain data discovery of the objects to be discovered in each data domain. In the first stage, the summary information of all objects to be discovered in each data domain is extracted and aggregated to generate a domain-level profile. Combined with the received user query requests, the profile is filtered to obtain a set of candidate data domains. The second-stage data discovery unit is used to perform second-stage processing based on the obtained candidate data domain set. It performs multi-dimensional similarity calculations on the discovered objects within the candidate data domain set to filter and obtain an initial candidate object set. Based on the association relationship of the discovered objects, it expands the results, uniformly sorts and removes duplicates from the initial candidate object set, and outputs the discovered object results.

9. A blockchain-based device for cross-domain management and trusted discovery of multimodal heterogeneous data, characterized in that: The blockchain-based multimodal heterogeneous data cross-domain management and trusted discovery device includes: processor; A memory storing computer-readable instructions that, when executed by the processor, implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that can be invoked by a processor to execute the method as described in any one of claims 1 to 7.

Images