A data bloodline authentication and circulation method and system based on a trusted data space

Abstract

This invention discloses a method and system for data lineage confirmation and circulation based on a trusted data space. The method includes: generating a data DID for the current data of the data provider and constructing a DID document; when a data user needs the current data, a cross-chain gateway distributes the data usage request to all relevant parties based on the DID document; all relevant parties conduct a collaborative rights confirmation vote; if the vote passes, the data provider uses the data user's public key to encrypt the current data, and forms a encrypted data capsule with the encrypted current data, data usage policy, data DID, and lineage relationship chain; the capsule is sent to a trusted execution environment specified by the data user; enabling the user to decrypt and use the encrypted current data; if new derived data is generated, a new data DID and corresponding DID document are generated for the derived data. This method solves the problems of easily tampered data ownership, broken lineage, and uncontrolled circulation.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and more specifically, to a method and system for confirming and circulating data lineage based on a trusted data space. Background Technology

[0002] With the development of the digital economy, data has become a key factor of production. However, the market circulation of data elements faces severe challenges related to ownership, privacy, and security. Existing technologies for managing data ownership and controlling its circulation mainly exhibit the following models and drawbacks:

[0003] 1. Centralized Access Control Model: Enterprises or organizations record data ownership and access control lists through a centralized database or access control system. This model has the risk of a single point of failure, and system administrators have excessive power, allowing them to arbitrarily modify access records, lacking transparency and credibility. Once data is authorized to a third party, its subsequent copying, dissemination, and use are no longer under the control of the original owner.

[0004] 2. Blockchain-based hash-based notarization: This model stores the hash value (fingerprint) of data files on the blockchain to prove the existence and integrity of the data, sometimes accompanied by simple access policies. While this model can prevent tampering, it only solves the notarization problem of "what the data is," failing to address the control issues of "where the data is, who is using it, and how it is used." The data entity (file) is still freely copied and propagated off-chain, and hash notarization is completely decoupled from the data entity. Once the data is copied, its ownership claim becomes meaningless, and the data's derivative relationships and circulation paths cannot be traced, leading to a break in the "data lineage."

[0005] 3. Traditional data anonymization and sharing: This method involves removing personal identifiers from data using technical means before sharing. However, in complex data fusion and analysis scenarios, this approach carries the risk of re-identification and also fails to control whether the data is shared again or used for unauthorized purposes by the recipient.

[0006] In summary, existing technologies struggle to ensure continuous control over data ownership, clear traceability of data lineage, and collaborative authorization during data circulation. This makes it difficult to securely circulate and extract value from high-value, sensitive data (such as medical and health data, commercial data, and industrial data) across entities while protecting privacy and property rights, creating a dilemma of "data silos" and "circulation risks." Summary of the Invention

[0007] This invention provides a method and system for data lineage confirmation and circulation based on a trusted data space, in order to solve the problem in the prior art that data is difficult to safely circulate and extract value across entities while protecting privacy and property rights.

[0008] To achieve the above objectives, on the one hand, this invention provides a method for data lineage confirmation and circulation based on a trusted data space. This method includes: S1, generating corresponding identity DIDs for data providers and data users; generating a unique data DID for the current data of the data provider and constructing a DID document; storing the DID document on a cross-chain gateway and storing the hash of the DID document on the blockchain network; S2, when a data user needs the current data, the data user initiates a data usage request on the cross-chain gateway; the cross-chain gateway distributes the data usage request to all relevant parties of the current data based on the DID document; the relevant parties include the direct owner of the current data and the creators of all its ancestral data; S3, ... All relevant parties conduct collaborative voting based on preset voting rules through smart contracts on the blockchain to determine whether to approve the data usage application; S4, if the vote passes, the data provider uses the public key of the data user to encrypt the current data, and forms a encrypted data capsule bound to the data DID by combining the encrypted current data, data usage policy, data DID, and lineage chain; the encrypted data capsule is sent to the trusted execution environment specified by the data user; S5, the data user decrypts and uses the encrypted current data in the trusted execution environment. If new derivative data is generated, a new data DID and corresponding DID document are generated for the derivative data.

[0009] Optionally, the DID document includes: data DID, creator identity DID, data fingerprint, data description, lineage relationship chain, and data usage application and access records; wherein, the lineage relationship chain is used to record the DID documents of the parent data on which the current data depends.

[0010] Optionally, the cross-chain gateway distributes the data usage application to all relevant parties of the current data based on the DID document, including: the cross-chain gateway parses the DID document to obtain the DID document of the parent data on which the current data depends, and then parses the DID document of the parent data to obtain the parent identity DID, the DID document of the parent data on which the parent data depends, and so on, until tracing back to the top-level parent, thereby obtaining all relevant parties, and distributing the data usage application to all relevant parties of the current data.

[0011] Optionally, the preset voting rules include at least one of the following: the direct owner of the current data has veto power; or the consent of relevant parties exceeding a preset threshold is required.

[0012] Optionally, the trusted execution environment provides an isolated, verifiable, and secure computing environment; the encryption of the current data is performed in one of the trusted execution environments, and the encrypted current data is decrypted and used in another trusted execution environment; the transmission of the encrypted data capsule is performed within the trusted data space.

[0013] On the other hand, this invention provides a data lineage confirmation system based on DID and encrypted data capsules. The system includes: a generation and storage unit for generating corresponding identity DIDs for data providers and data users; generating a unique data DID for the current data of the data provider and constructing a DID document; storing the DID document on a cross-chain gateway and storing the hash of the DID document on the blockchain network; a usage application unit for initiating a data usage application on the cross-chain gateway when the data user needs the current data; the cross-chain gateway distributing the data usage application to all relevant parties of the current data based on the DID document; the relevant parties include the direct owner of the current data and the creators of all its ancestral data; and a voting unit for... All relevant parties conduct collaborative voting based on preset voting rules through smart contracts on the blockchain to determine whether to approve the data usage application. A capsule sending unit is used, if the vote passes, for the data provider to encrypt the current data using the data user's public key, and to form a encrypted data capsule bound to the data DID, consisting of the encrypted current data, data usage policy, data DID, and lineage chain; the encrypted data capsule is then sent to a trusted execution environment specified by the data user. A data derivation unit is used for the data user to decrypt and use the encrypted current data within the trusted execution environment; if new derived data is generated, a new data DID and corresponding DID document are generated for the derived data.

[0014] Optionally, the DID document includes: data DID, creator identity DID, data fingerprint, data description, lineage relationship chain, and data usage application and access records; wherein, the lineage relationship chain is used to record the DID documents of the parent data on which the current data depends.

[0015] Optionally, the cross-chain gateway distributes the data usage application to all relevant parties of the current data based on the DID document, including: the cross-chain gateway parses the DID document to obtain the DID document of the parent data on which the current data depends, and then parses the DID document of the parent data to obtain the parent identity DID, the DID document of the parent data on which the parent data depends, and so on, until tracing back to the top-level parent, thereby obtaining all relevant parties, and distributing the data usage application to all relevant parties of the current data.

[0016] Optionally, the preset voting rules include at least one of the following: the direct owner of the current data has veto power; or the consent of relevant parties exceeding a preset threshold is required.

[0017] Optionally, the trusted execution environment provides an isolated, verifiable, and secure computing environment; the encryption of the current data is performed in one of the trusted execution environments, and the encrypted current data is decrypted and used in another trusted execution environment; the transmission of the encrypted data capsule is performed within the trusted data space.

[0018] The beneficial effects of this invention are:

[0019] This invention provides a method and system for data lineage confirmation and circulation based on a trusted data space. This method ensures that data possesses an undeniable identity from its inception. Data circulates in the form of a secure capsule, with usage rights and access policies always accompanying the data itself. The original owner and subsequent contributors can continuously participate in controlling data usage, breaking the "one-time authorization, permanent loss of control" situation. It expands data usage authorization from a simple binary relationship of "owner-user" to collaborative decision-making by a "community of interests" based on lineage chains, achieving fairer and more refined data governance. It ensures that data encryption, transmission, decryption, and use occur only in a trusted execution environment, fundamentally preventing data leakage. Attached Figure Description

[0020] Figure 1 This is a flowchart of the data lineage confirmation and circulation method based on trusted data space provided in the embodiments of the present invention;

[0021] Figure 2 This is a schematic diagram of the structure of a data lineage confirmation and circulation system based on a trusted data space provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0023] Figure 1 This invention provides a method for confirming and circulating data lineage based on a trusted data space, such as... Figure 1 As shown, the method includes:

[0024] S1. Generate corresponding identity DIDs for data providers and data users; generate unique data DIDs for the current data of data providers and construct DID documents; store the DID documents in the cross-chain gateway and store the hash of the DID documents in the blockchain network;

[0025] In one alternative implementation, the participants include: Ankang Hospital (data provider A), which provides the original medical data, and Smart Medical Research Institute (data user B), which wishes to use the data for disease model research.

[0026] Ankang Hospital and the Smart Healthcare Research Institute each registered with the DID management module through the system's client application. The system generated an identity DID for Ankang Hospital: did:org:ankang_hospital, and an identity DID for the Smart Healthcare Research Institute: did:org:wisdom_research.

[0027] Ankang Hospital possesses a de-identified "Diabetic Retinopathy Screening Image Dataset". When the hospital decides to circulate this dataset as an asset, the system generates a unique data DID for it: did:data:dr_screening_dataset_v1.

[0028] Subsequently, the system constructs a document for the data DID, which includes: data DID, creator identity DID, data fingerprint, data description, lineage relationship chain, and data usage application and access records; wherein, the lineage relationship chain is used to record the DID documents of the parent data on which the current data depends.

[0029] The following is an example to illustrate this:

[0030] {

[0031] "@context": "https: / / www.w3.org / ns / did / v1",

[0032] "id": "did:data:dr_screening_dataset_v1", / / data DID

[0033] “creator”: “did:org:ankang_hospital”, / / creator identity

[0034] “dataFingerprint”: “sha256:7d8e1f2a3b4c5d6e...”, / / Hash fingerprint of the data

[0035] “metadata”: {

[0036] "type": "medical_image_dataset",

[0037] “description”: “Anonymized screening images for diabetic retinopathy, totaling 1000 cases”

[0038] "createdAt": "2024-01-15T08:30:00Z"

[0039] },

[0040] "lineage": [], / / As raw data, the lineage relationship chain is an empty array.

[0041] “accessHistory”: [] / / Initial access history is empty

[0042] }

[0043] The `lineage` field records the parent data's DID. Since this dataset is raw data with no parent source, it is empty. The `accessHistory` field records all subsequent access requests and results.

[0044] The generated DID document (complete content) is stored in the local cache or associated database of the cross-chain gateway for fast querying and parsing. Simultaneously, the system calculates the hash value (e.g., SHA-256) of the DID document and submits this hash value as a proof of ownership to the blockchain network (e.g., a consortium blockchain) for permanent and immutable storage. This process achieves "original text locally verifiable, fingerprint trusted on-chain."

[0045] S2. When a data user needs the current data, the data user initiates a data usage request on the cross-chain gateway; the cross-chain gateway distributes the data usage request to all relevant parties of the current data based on the DID document; all relevant parties include the direct owner of the current data and the creators of all its ancestral data.

[0046] Researchers at the Smart Healthcare Institute discovered a "diabetic retinopathy screening image dataset" in the data catalog and hoped to use it to develop an AI-assisted diagnostic model. The researchers submitted a data usage request to the cross-chain gateway through the system interface. The request information included: the target data DID (did:data:dr_screening_dataset_v1), the applicant's identity DID (did:org:wisdom_research), the purpose of use ("AI model training"), and proof of commitment to use a Trusted Execution Environment (TEE environment).

[0047] After receiving the application, the cross-chain gateway queries the local storage to obtain the complete DID document of the target data did:data:dr_screening_dataset_v1.

[0048] The cross-chain gateway distributes the data usage application to all relevant parties of the current data based on the DID document, including:

[0049] The cross-chain gateway parses the DID document to obtain the DID document of the parent data on which the current data depends, and then parses the DID document of the parent data to obtain the parent identity DID, the DID document of the parent data on which the parent data depends, and so on, until tracing back to the top-level parent, thereby obtaining all relevant parties, and distributing the data to all relevant parties of the current data using the application.

[0050] Specifically, the cross-chain gateway parses the `creator` field in the document to obtain the identity DID of the direct owner (also the creator): `did:org:ankang_hospital`. This is the first relevant party. The cross-chain gateway then parses the `lineage` field in the document. Since this field is an empty array in this example, it indicates that the ancestor has been traced to the top level and there is no ancestor data. At this point, the cross-chain gateway determines the set of "all relevant parties" as: `[did:org:ankang_hospital]`.

[0051] In another alternative implementation, suppose the research application uses a "multi-center fused dataset" (child) formed by merging the Ankang Hospital dataset (parent) and another hospital dataset (parent). When parsing the lineage field of the child dataset's DID document, the cross-chain gateway will find two parent entries. The cross-chain gateway will recursively retrieve the DID documents of these two parent datasets, parse out their creators, and ultimately the set of relevant parties will include the direct owner of the child dataset and the creators of the two parent datasets.

[0052] S3. All relevant parties conduct collaborative voting based on preset voting rules through smart contracts on the blockchain to determine whether to approve the data use application;

[0053] In one alternative implementation, the cross-chain gateway encapsulates the data usage request into a transaction, invoking the creation request function of a smart contract deployed on the blockchain network. The smart contract records the request on-chain and automatically generates a pending voting task for each staker based on the "all stakeholders" list provided by the gateway.

[0054] The preset voting rules include at least one of the following:

[0055] The direct owner of the current data has veto power;

[0056] Or may require the consent of relevant parties exceeding a preset threshold.

[0057] Specifically, Ankang Hospital's backend system detected an on-chain event and notified the administrator that "there is a pending application to use your asset did:data:dr_screening_dataset_v1." The administrator then viewed the application details (research institution qualifications, TEE certification, and usage description).

[0058] According to the pre-defined voting rules, in this example, the rule is that "the direct owner has veto power." After evaluation, the hospital administrator deemed the research objective compliant and cast a vote in favor by calling the smart contract's voting function through the client. If the rule were "more than 50% of the stakeholders must agree," and there are multiple stakeholders, then each stakeholder would need to vote, and the smart contract would tally the approval percentage.

[0059] S4. If the vote passes, the data provider uses the public key of the data user to encrypt the current data, and forms a encrypted data capsule with the encrypted current data, data usage policy, data DID, and lineage chain bound to the data DID; the encrypted data capsule is then sent to the trusted execution environment specified by the data user.

[0060] In one optional implementation, after the smart contract confirms the vote has passed, it updates the authorization status on-chain. Both the cross-chain gateway and the Ankang Hospital system receive an authorization success event. The Ankang Hospital's TEE environment connector (a security component deployed in the TEE hardware) then begins operation:

[0061] 1. Securely read the raw image dataset from the internal database of Ankang Hospital.

[0062] 2. Obtain the public key of the TEE environment designated by the Smart Healthcare Research Institute.

[0063] 3. Use the public key to encrypt the original image dataset to generate encrypted data (i.e., the encrypted current data).

[0064] The encrypted data (the current encrypted data), the data usage policy (such as "only for this model training, no copies may be retained"), the data DID (did:data:dr_screening_dataset_v1), and the lineage chain obtained from the DID document (empty in this example) are all encapsulated into a structured encrypted data capsule. This encrypted data capsule is logically strongly bound to the data DID.

[0065] The completed encrypted data capsule is sent from the TEE environment connector of Ankang Hospital via a secure communication link (such as a TLS-based channel). This transmission path is within a logically isolated trusted data space, ensuring the security of the transmission process.

[0066] S5. The data user decrypts and uses the encrypted current data within the trusted execution environment. If new derivative data is generated, a new data DID and a corresponding DID document are generated for the derivative data.

[0067] The encrypted data capsule was ultimately delivered to a remotely certified Trusted Execution Environment (TEE) requested by the Smart Healthcare Institute.

[0068] The encryption of the current data is performed in one of the trusted execution environments, and the decryption and use of the encrypted current data are performed in another trusted execution environment. Specifically, the encryption occurs in the TEE environment of the data provider (Ankang Hospital); the decryption and use will occur in the TEE environment of the data user (research institute).

[0069] Within the institute's TEE environment, a private key held only by the data user is used to decrypt the encrypted data capsule, restoring the original plaintext image dataset. Subsequently, the researcher's AI model training program runs within the secure area of ​​the TEE, reading this plaintext data for training. Throughout the entire process, the original plaintext data is never exposed outside the TEE's security boundaries.

[0070] After the model training is complete, a new "AI diagnostic model for diabetic retinopathy" (derived data) is generated. The system automatically triggers the following process:

[0071] 1. Generate a new data DID for this new model: did:data:dr_ai_model_v1.

[0072] 2. Construct its DID document; the lineage field of this DID document will contain key lineage information, such as:

[0073] “lineage”: [{

[0074] "parent":"did:data:dr_screening_dataset_v1", / / Parent data DID

[0075] "operation": "ai_training", / / Derivative operations

[0076] “operator”: “did:org:wisdom_research”, / / Derivative operator

[0077] "timestamp": "2024-05-27T10:00:00Z"

[0078] }]

[0079] This record clearly shows that the new model did:data:dr_ai_model_v1 originated from the original dataset of Ankang Hospital and was trained by the research institute, thus establishing an immutable data lineage.

[0080] Figure 2 This is a schematic diagram of the structure of a data lineage confirmation and circulation system based on a trusted data space provided in an embodiment of the present invention; as shown below. Figure 2 As shown, the system includes:

[0081] The generation storage unit 201 is used to generate corresponding identity DIDs for data providers and data users; generate a unique data DID for the current data of the data provider and construct a DID document; store the DID document in the cross-chain gateway and store the hash of the DID document in the blockchain network;

[0082] Application unit 202 is used to enable a data user to initiate a data usage application on the cross-chain gateway when the data user needs the current data; the cross-chain gateway distributes the data usage application to all relevant parties of the current data based on the DID document; the relevant parties include the direct owner of the current data and the creators of all its ancestral data.

[0083] Voting unit 203 is used by all relevant parties to conduct collaborative rights confirmation voting through a smart contract on the blockchain based on preset voting rules, in order to decide whether to approve the data use application;

[0084] The capsule sending unit 204 is configured to, if the vote passes, encrypt the current data using the public key of the data user, and form a encrypted data capsule bound to the data DID by the encrypted current data, data usage policy, data DID, and lineage chain; and send the encrypted data capsule to the trusted execution environment specified by the data user.

[0085] The data derivation unit 205 is used by the data user to decrypt and use the encrypted current data within the trusted execution environment. If new derived data is generated, a new data DID and a corresponding DID document are generated for the derived data.

[0086] In one optional implementation, the DID document includes: a data DID, a creator identity DID, a data fingerprint, a data description, a lineage relationship chain, and data usage application and access records; wherein, the lineage relationship chain is used to record the DID documents of the parent data on which the current data depends.

[0087] In an optional implementation, the cross-chain gateway distributes the data usage request to all relevant parties based on the DID document, including:

[0088] The cross-chain gateway parses the DID document to obtain the DID document of the parent data on which the current data depends, and then parses the DID document of the parent data to obtain the parent identity DID, the DID document of the parent data on which the parent data depends, and so on, until tracing back to the top-level parent, thereby obtaining all relevant parties, and distributing the data to all relevant parties of the current data using the application.

[0089] In one optional implementation, the preset voting rules include at least one of the following:

[0090] The direct owner of the current data has veto power;

[0091] Or may require the consent of relevant parties exceeding a preset threshold.

[0092] In one alternative implementation, the trusted execution environment provides an isolated, verifiable, and secure computing environment;

[0093] The encryption of the current data is performed in one trusted execution environment, and the encrypted current data is decrypted and executed in another trusted execution environment.

[0094] The transmission of the dense data capsule is performed within a trusted data space.

[0095] The system of the present invention corresponds to the method described above, and the specific implementation of the system will not be repeated here.

[0096] The beneficial effects of this invention are:

[0097] This invention provides a method and system for data lineage confirmation and circulation based on a trusted data space. This method ensures that data possesses an undeniable identity from its inception. Data circulates in the form of a secure capsule, with usage rights and access policies always accompanying the data itself. The original owner and subsequent contributors can continuously participate in controlling data usage, breaking the "one-time authorization, permanent loss of control" situation. It expands data usage authorization from a simple binary relationship of "owner-user" to collaborative decision-making by a "community of interests" based on lineage chains, achieving fairer and more refined data governance. It ensures that data encryption, transmission, decryption, and use occur only in a trusted execution environment, fundamentally preventing data leakage.

[0098] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A data bloodline certification and circulation method based on a trusted data space, characterized in that, include: S1. Generate corresponding identity DIDs for data providers and data users; generate unique data DIDs for the current data of data providers and construct DID documents; store the DID documents in the cross-chain gateway and store the hash of the DID documents in the blockchain network; S2. When a data user needs the current data, the data user initiates a data usage request on the cross-chain gateway; the cross-chain gateway distributes the data usage request to all relevant parties of the current data based on the DID document; all relevant parties include the direct owner of the current data and the creators of all its ancestral data. S3. All relevant parties conduct collaborative voting based on preset voting rules through smart contracts on the blockchain to determine whether to approve the data use application; S4. If the vote passes, the data provider uses the public key of the data user to encrypt the current data, and forms a encrypted data capsule with the encrypted current data, data usage policy, data DID, and lineage chain bound to the data DID; the encrypted data capsule is then sent to the trusted execution environment specified by the data user. S5. The data user decrypts and uses the encrypted current data within the trusted execution environment. If new derivative data is generated, a new data DID and a corresponding DID document are generated for the derivative data.

2. The method according to claim 1, characterized in that: The DID document includes: data DID, creator identity DID, data fingerprint, data description, lineage relationship chain, and data usage application and access records; wherein, the lineage relationship chain is used to record the DID documents of the parent data on which the current data depends.

3. The method of claim 1, wherein, The cross-chain gateway distributes the data usage application to all relevant parties of the current data based on the DID document, including: The cross-chain gateway parses the DID document to obtain the DID document of the parent data on which the current data depends, and then parses the DID document of the parent data to obtain the parent identity DID, the DID document of the parent data on which the parent data depends, and so on, until tracing back to the top-level parent, thereby obtaining all relevant parties, and distributing the data to all relevant parties of the current data using the application.

4. The method according to claim 1, characterized in that: The preset voting rules include at least one of the following: The direct owner of the current data has veto power; Or may require the consent of relevant parties exceeding a preset threshold.

5. The method according to claim 1, characterized in that: The Trusted Execution Environment provides an isolated, verifiable, and secure computing environment; The encryption of the current data is performed in one trusted execution environment, and the encrypted current data is decrypted and executed in another trusted execution environment. The transmission of the dense data capsule is performed within a trusted data space.

6. A data bloodline certification and circulation system based on a trusted data space, characterized in that, include: Generate storage units to generate corresponding identity DIDs for data providers and data users; generate unique data DIDs for the current data of data providers and construct DID documents; store the DID documents in the cross-chain gateway and store the hash of the DID documents in the blockchain network; The application unit is used to initiate a data usage application on the cross-chain gateway when a data user needs the current data; the cross-chain gateway distributes the data usage application to all relevant parties of the current data based on the DID document; the relevant parties include the direct owner of the current data and the creators of all its ancestral data. A voting unit is used by all relevant parties to conduct collaborative voting on the blockchain based on preset voting rules and through a smart contract to determine whether to approve the data use application. The capsule sending unit is configured to, if the vote passes, encrypt the current data using the public key of the data user, and form a encrypted data capsule bound to the data DID by the encrypted current data, data usage policy, data DID, and lineage chain; and send the encrypted data capsule to the trusted execution environment specified by the data user. The data derivation unit is used by the data user to decrypt and use the encrypted current data within the trusted execution environment. If new derived data is generated, a new data DID and a corresponding DID document are generated for the derived data.

7. The system according to claim 6, characterized in that: The DID document includes: data DID, creator identity DID, data fingerprint, data description, lineage relationship chain, and data usage application and access records; wherein, the lineage relationship chain is used to record the DID documents of the parent data on which the current data depends.

8. The system of claim 6, wherein, The cross-chain gateway distributes the data usage application to all relevant parties of the current data based on the DID document, including: The cross-chain gateway parses the DID document to obtain the DID document of the parent data on which the current data depends, and then parses the DID document of the parent data to obtain the parent identity DID, the DID document of the parent data on which the parent data depends, and so on, until tracing back to the top-level parent, thereby obtaining all relevant parties, and distributing the data to all relevant parties of the current data using the application.

9. The system according to claim 6, characterized in that: The preset voting rules include at least one of the following: The direct owner of the current data has veto power; Or may require the consent of relevant parties exceeding a preset threshold.

10. The system according to claim 6, characterized in that: The Trusted Execution Environment provides an isolated, verifiable, and secure computing environment; The encryption of the current data is performed in one trusted execution environment, and the encrypted current data is decrypted and executed in another trusted execution environment. The transmission of the dense data capsule is performed within a trusted data space.

Images