Blockchain-based data sharing method, device and related equipment

Abstract

The embodiment of the application discloses a data sharing method and device based on a block chain and related equipment, which can be applied to the technical field of block chains. The method comprises the following steps: obtaining a verifiable voucher for a data use object issued by a block chain node; obtaining a decentralized providing identity file corresponding to a decentralized providing identity of a data providing object in the verifiable voucher from the block chain node based on the decentralized providing identity; performing voucher verification on the verifiable voucher through the decentralized providing identity file, and when the verifiable voucher is verified successfully, pulling business data corresponding to a target data directory from a first database corresponding to the data providing object, and sending the business data corresponding to the target data directory to a second sharing agent node, so that the second sharing agent node stores the business data corresponding to the target data directory into a second database corresponding to the data use object. The embodiment of the application helps to improve the security of data sharing.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to blockchain-based data sharing methods, devices, and related equipment. Background Technology

[0002] Currently, when a data user (such as user A) needs to obtain business data from a data provider (such as user B), the terminal device corresponding to the data provider (such as user B) can directly publish the business data to be shared to a centralized business platform. In this way, the data user (such as user A) can use the business data shared by the data provider on the centralized business platform.

[0003] However, the inventors discovered in practice that when data providers and users share data through a centralized business platform, there is a risk that the business data provided by the data provider may be leaked if the centralized business platform is compromised. This would reduce the security of the business data during data sharing. Therefore, how to improve the security of data sharing is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a blockchain-based data sharing method, apparatus, and related equipment, which enables data sharing through the interaction between the sharing proxy node corresponding to the data provider and the blockchain node, thereby helping to improve the security of data sharing.

[0005] This application provides a blockchain-based data sharing method, wherein the shared proxy nodes associated with the blockchain node include a first shared proxy node corresponding to the data provider and a second shared proxy node corresponding to the data user. The method is executed by the first shared proxy node and includes:

[0006] Obtain verifiable credentials issued by the blockchain node for the data user; the verifiable credentials are determined based on the verifiable claims configured by the data provider for the data user; the verifiable claims are used to instruct the data provider to authorize the data user to obtain business data corresponding to the shared data directory; the verifiable credentials are used to instruct the data user to selectively obtain business data corresponding to a target data directory in the shared data directory.

[0007] Based on the data provided by the verifiable credentials, a decentralized identity identifier is provided, and the decentralized identity file corresponding to the decentralized identity identifier is obtained from the blockchain node;

[0008] The identity file is provided in a decentralized manner to verify the verifiable credentials. When the verifiable credentials are successfully verified, the business data corresponding to the target data directory is retrieved from the first database corresponding to the data provider object, and the business data corresponding to the target data directory is sent to the second shared agent node so that the second shared agent node stores the business data corresponding to the target data directory into the second database corresponding to the data user object.

[0009] This application provides a blockchain-based data sharing device. The shared proxy nodes associated with the blockchain nodes include a first shared proxy node corresponding to a data provider and a second shared proxy node corresponding to a data user. The device operates on the first shared proxy node. The device includes:

[0010] The credential acquisition module is used to acquire verifiable credentials issued by blockchain nodes for data users. Verifiable credentials are determined based on verifiable claims configured by the data provider for the data user. Verifiable claims are used to instruct the data provider to authorize the data user to acquire business data corresponding to the shared data directory. Verifiable credentials are used to instruct the data user to selectively acquire business data corresponding to a target data directory in the shared data directory.

[0011] An identity file acquisition module is provided, which is used to provide decentralized identity identifiers for objects based on data in verifiable credentials, and to obtain the decentralized identity file corresponding to the decentralized identity identifier from the blockchain node;

[0012] The credential verification module is used to verify verifiable credentials by providing identity files in a decentralized manner. When the verifiable credentials are successfully verified, the module retrieves the business data corresponding to the target data directory from the first database corresponding to the data provider object and sends the business data corresponding to the target data directory to the second shared agent node, so that the second shared agent node stores the business data corresponding to the target data directory into the second database corresponding to the data user object.

[0013] This application provides a blockchain-based data sharing method, wherein the shared proxy nodes associated with the blockchain node include a first shared proxy node corresponding to the data provider and a second shared proxy node corresponding to the data user. The method is executed by the blockchain node and includes:

[0014] A verifiable credential for the data user is issued to the first shared agent node corresponding to the data provider. The verifiable credential is determined based on the verifiable claim configured by the data provider for the data user. The verifiable claim is used to instruct the data provider to authorize the data user to obtain business data corresponding to the shared data directory. The verifiable credential is used to instruct the data user to selectively obtain business data corresponding to the target data directory in the shared data directory.

[0015] Upon receiving a request from the first shared agent node to obtain the identity file of the data provider object in the verifiable credential, the decentralized provider identity file corresponding to the decentralized provider identity file is determined based on the decentralized provider identity identifier of the data provider object carried in the identity file acquisition request. The decentralized provider identity file is then returned to the first shared agent node, enabling the first shared agent node to verify the verifiable credential using the decentralized provider identity file. If the verification of the verifiable credential is successful, the business data corresponding to the target data directory is retrieved from the first database corresponding to the data provider object, and the business data corresponding to the target data directory is sent to the second shared agent node, enabling the second shared agent node to store the business data corresponding to the target data directory in the second database corresponding to the data user object.

[0016] This application provides a blockchain-based data sharing device. The shared proxy nodes associated with the blockchain nodes include a first shared proxy node corresponding to a data provider and a second shared proxy node corresponding to a data user. The device operates on the blockchain nodes and includes:

[0017] The credential issuance module is used to issue verifiable credentials for data users to the first shared agent node corresponding to the data provider object. The verifiable credentials are determined based on the verifiable declaration configured by the data provider object for the data user object. The verifiable declaration is used to instruct the data provider object to authorize the data user object to obtain business data corresponding to the shared data directory. The verifiable credentials are used to instruct the data user object to selectively obtain business data corresponding to the target data directory in the shared data directory.

[0018] An identity file distribution module is provided. When a request for obtaining an identity file for a data provider object in a verifiable credential is received from the first shared agent node, the module determines the decentralized identity file corresponding to the decentralized identity identifier of the data provider object carried in the identity file acquisition request, and returns the decentralized identity file to the first shared agent node. This allows the first shared agent node to verify the verifiable credential using the decentralized identity file. If the verification of the verifiable credential is successful, the module retrieves the business data corresponding to the target data directory from the first database corresponding to the data provider object and sends the business data corresponding to the target data directory to the second shared agent node. This allows the second shared agent node to store the business data corresponding to the target data directory in the second database corresponding to the data user object.

[0019] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the method provided in this application.

[0020] One embodiment of this application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in this application embodiment.

[0021] In this embodiment, the first shared proxy node corresponding to the data provider can obtain verifiable credentials from the blockchain node. Upon successful verification of the verifiable credentials based on the data provider's decentralized identity file, the first shared proxy node retrieves the business data corresponding to the target directory data from the first database corresponding to the data provider and sends this business data to the second shared proxy node. Throughout the entire business data acquisition process, the data provider does not need to send the shared business data to any third-party platform. Instead, upon determining that the data user can access the business data, it directly sends the business data from its own database to the data user's database, significantly reducing the risk of business data leakage. Furthermore, by verifying the data user's verifiable credentials, and ensuring that the decentralized identity file used to verify the verifiable credentials is on-chain to the blockchain, the reliability is high. This guarantees that the business data obtained by the data user is authorized by the data provider, thus preventing the arbitrary acquisition of the business data provided by the data provider. Therefore, in this embodiment, data sharing is achieved through the interaction between the shared proxy node corresponding to the data provider and the blockchain node, which helps improve the security of data sharing. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram of the structure of a blockchain-based data sharing system provided in an embodiment of this application;

[0024] Figure 2 This is a schematic diagram illustrating a scenario of a blockchain-based data sharing method provided in an embodiment of this application;

[0025] Figure 3 This is a flowchart illustrating a blockchain-based data sharing method provided in an embodiment of this application;

[0026] Figure 4 This is a schematic diagram illustrating the effect of a data directory provided in an embodiment of this application;

[0027] Figure 5 This is a schematic diagram of the architecture of a data sharing system provided in an embodiment of this application;

[0028] Figure 6 This is a flowchart illustrating a credential verification process provided in an embodiment of this application;

[0029] Figure 7 This is a flowchart illustrating a blockchain-based data sharing method provided in an embodiment of this application;

[0030] Figure 8 This is a flowchart illustrating a process for creating a participating object, as provided in an embodiment of this application.

[0031] Figure 9 This is a schematic diagram illustrating the process of publishing and applying for a data catalog, as provided in an embodiment of this application.

[0032] Figure 10 This is a flowchart illustrating the creation process of a verifiable claim provided in an embodiment of this application;

[0033] Figure 11 This is a schematic diagram of a data sharing task publishing process provided in an embodiment of this application;

[0034] Figure 12 This is a schematic diagram of another data sharing task publishing process provided in an embodiment of this application;

[0035] Figure 13 This is a schematic diagram of a process for performing a data sharing task provided in an embodiment of this application;

[0036] Figure 14 This is a schematic diagram of the architecture of another data sharing system provided in the embodiments of this application;

[0037] Figure 15 This is a schematic diagram of the real-time interaction of a blockchain-based data sharing system provided in an embodiment of this application;

[0038] Figure 16 This is a schematic diagram of the structure of a blockchain-based data sharing device provided in an embodiment of this application;

[0039] Figure 17 This is a schematic diagram of the structure of a blockchain-based data sharing device provided in an embodiment of this application;

[0040] Figure 18 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0041] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0042] The following describes some technical terms used in the embodiments of this application:

[0043] Decentralized Identity (DID) is an identity built on a blockchain-based digital identity system. This decentralized identity system features guaranteed data authenticity and trustworthiness, protection of user privacy and security, and strong portability. Its advantages include: Decentralization: Based on blockchain, it avoids identity data being controlled by a single centralized authority. Self-controlled Identity: Based on DPKI (Distributed Public Key Infrastructure), each user's identity is not controlled by a trusted third party, but by its owner, allowing individuals to manage their own identities autonomously. Trusted Data Exchange: Identity-related data is anchored on the blockchain, and the authentication process does not rely on the application providing the identity.

[0044] Decentralized Identity Authentication (DID): A DID is a specific formatted string used to represent the digital identity of an entity. This entity can be a person, machine, or thing, such as the data provider directory, data provider object, or data user object mentioned in this application. The format of a DID is: did:tdid:c44:0x5c660f58f991382b12852f6a5f2d28f56a28b9bd. Here, did indicates that the identifier is a DID, tdid represents the DID method, indicating which scheme (method) was used to define and operate this DID, and 0x5c660f58f991382b12852f6a5f2d28f56a28b9bd is the unique identifier string for this DID.

[0045] Decentralized Identity Files (DID documents): Each DID identifier corresponds to a DID document (DIDDocument), which contains: the DID identifier, public key, timestamp, etc. Generally, the DID identifier can be used as the key, and the DID document as the value, stored in the blockchain. Leveraging the blockchain's immutability and shared data access characteristics, trusted data can be quickly accessed and retrieved during identity verification.

[0046] A Verifiable Claim (VC) is a descriptive statement issued by an object with a decentralized identity to endorse certain properties of another object with a decentralized identity, and includes its own digital signature (i.e., claim proof information) to prove the authenticity of these properties, similar to a digital certificate.

[0047] A verifiable presentation (VP) is data in which the holder of a VC (data usage object) declares their identity to a verifier (such as the data sharing management node corresponding to the data provider). Normally, the VC holder can directly present the full VC. However, in some cases, for privacy protection, it may not be necessary to present the complete VC content; instead, some attributes may be selectively disclosed, or no attributes may be disclosed at all. In such cases, a VP can be generated based on the VC and submitted to a verifier for verification.

[0048] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a blockchain-based data sharing system provided in an embodiment of this application. The data sharing system may include a terminal device cluster 100, a data sharing management node 200a, a sharing agent node 300a, and a blockchain network 400a, etc.

[0049] What is understandable is that Figure 1 The terminal device cluster 100a shown may include one or more terminal devices. The number of terminal devices in the terminal device cluster 100a is not limited here. For example, such as... Figure 1 As shown, the terminal devices in the terminal device cluster 100a may include terminal device 10a, terminal device 10b, ..., terminal device 10n, etc. A client corresponding to the data sharing platform can run on any terminal device, allowing the business object (such as a user) corresponding to the terminal device to share data based on this client. For example, the data provider and data user involved in this embodiment can interact with the data sharing management node through the corresponding terminal device. Any terminal device may include, but is not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, smart speakers, and other smart home appliances.

[0050] It is understood that a data sharing management node can be a server used for data sharing management of business objects. For example, the data sharing management node can be a server for data sharing management of an organization (such as an enterprise or institution), and the number of data sharing management nodes in the data sharing system is not limited here. The data sharing management node provided in this application embodiment can be a node used to provide blockchain-based trusted computing services, thereby combining blockchain technology with a Trusted Execution Environment (TEE), which helps to improve the security of data sharing throughout the entire data sharing process. The data sharing management node can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0051] In this system, a shared proxy node (such as shared proxy node 300a) can be a node used to actually perform data sharing tasks. This shared proxy node can correspond to an organization (such as an enterprise or institution) and can also be called a data sharing proxy gateway node. This shared proxy node can be created at the request of a shared management object within the organization (i.e., an object within the organization used for data sharing management). The number of shared proxy nodes in this data sharing system is not limited here. This shared proxy node can be a shared proxy node associated with a blockchain node corresponding to the blockchain; that is, a shared proxy node can be a node registered on the blockchain.

[0052] Among them, such as Figure 1 The blockchain network 400a shown may include multiple blockchain nodes; the number of blockchain nodes in blockchain network 400a will not be limited here. Figure 1 As shown, the multiple blockchain nodes in blockchain network 400a may specifically include blockchain node 11a, blockchain node 11b, blockchain node 11c, blockchain node 11d, etc. These blockchain nodes can be used to jointly maintain the blockchain; for example, the blockchain stored on each node in blockchain network 400a (e.g., blockchain nodes 11a, 11b, 11c, and 11d) is blockchain 11e.

[0053] like Figure 1As shown, both the data sharing management node 200a and the shared proxy node 300a can establish network connections with blockchain nodes 11a, 11b, 11c, and 11d to interact with the blockchain nodes in the blockchain network 400a when the data sharing management node 200a and the shared proxy node 300a are connected to the blockchain network 400a. The specific interaction process will be described in detail later.

[0054] It should be understood that the blockchain involved in this application embodiment is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is mainly used to organize data in chronological order and encrypt it into a ledger, making it tamper-proof and forgery-proof, while also enabling data verification, storage, and updating. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer. A blockchain includes a series of blocks sequentially generated in chronological order, each block recording the block data packaged and submitted by blockchain nodes in the blockchain system.

[0055] It should be understood that one or more smart contracts (also simply referred to as contracts) can be deployed on the blockchain of the aforementioned blockchain network (e.g., blockchain network 400a) (e.g., blockchain 11e). These smart contracts can be distinguished by contract identifiers, which may include one or more of the following: contract call address (also simply referred to as contract address), contract identifier (ID), or contract name. In business transactions initiated by user clients, the contract call address, contract identifier, or contract name of the smart contract can also be carried to specify the smart contract to be executed. In this embodiment, the smart contracts deployed on the blockchain may include data sharing contracts for data sharing. These data sharing contracts can be used to provide data sharing services to data providers and data users. For example, the data sharing contract can be used to process identity on-chain transactions, identity on-chain transactions, directory usage application transactions, declaration on-chain transactions, shared task on-chain transactions, and so on.

[0056] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating a scenario of a blockchain-based data sharing method provided in an embodiment of this application. For example... Figure 2As shown, a blockchain node (such as blockchain node 11a) in blockchain network 400a can send a verifiable credential V1 to a first shared proxy node 211a (step S21a). The first shared proxy node 211a can be a shared proxy node corresponding to a data providing object (such as user U1). The data providing object can refer to an object used to provide business data for other objects to obtain.

[0057] The verifiable credential V1 can be submitted by a data user (e.g., user U2) to a blockchain node (e.g., blockchain node 11a) in blockchain network 400a. This verifiable credential V1 is determined based on a verifiable claim configured by the data provider for the data user, which instructs the data provider to authorize the data user to obtain business data corresponding to the shared data directory. The verifiable credential V1 also instructs the data user to selectively obtain business data corresponding to a target data directory within the shared data directory. For example... Figure 2 As shown, the verifiable credential V1 (such as...) Figure 2 As shown in 201a), it can include decentralized provision of identity (such as...) for data providers. Figure 2 As shown in 202a), and the target data directory selected by the data user (such as...). Figure 2 (As shown in 203a). Here, decentralized identity provision can refer to the decentralized identity of the data provision object.

[0058] Furthermore, the first shared agent node 211a can obtain a decentralized identity file from the blockchain node based on the decentralized identity identifier (step S22a). This decentralized identity file can be the decentralized identity file corresponding to the decentralized identity identifier, that is, the decentralized identity file of the data provider object.

[0059] Furthermore, the first shared agent node 211a can verify the verifiable credential V1 by providing an identity file in a decentralized manner (step S23a). Then, upon successful verification of the verifiable credential V1, it retrieves the business data corresponding to the target data directory from the first database corresponding to the data provider (step S24a). This first database can refer to a database used to store the business data provided by the data provider. The method for verifying the verifiable credential V1 can be found in subsequent descriptions and will not be elaborated here. Successful verification of the verifiable credential V1 indicates that the verifiable credential is a credential of the data user and that the data user has the permission to use the business data corresponding to the target data directory. Only then will the first shared agent node provide the business data corresponding to the target data directory to the data user, that is, retrieve the business data corresponding to the target data directory from the first database.

[0060] Furthermore, the first shared proxy node 211a can send the business data corresponding to the target data directory to the second shared proxy node 212a (step S25a), thereby the second shared proxy node 212a sends the business data corresponding to the target data directory to the second database corresponding to the data user. The second database refers to a database used to store the business data obtained by the data user. The second shared proxy node 212a can be a shared proxy node corresponding to the data user; it can be the same shared proxy node as the first shared proxy node, or it can be a different shared proxy node, which is not limited here.

[0061] It is understood that the above scenarios are merely examples and do not constitute a limitation on the application scenarios of the technical solutions provided in the embodiments of this application. The technical solutions of this application can also be applied to other scenarios. For example, as those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0062] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a blockchain-based data sharing method provided in an embodiment of this application. The shared proxy nodes associated with the blockchain node include a first shared proxy node corresponding to the data provider and a second shared proxy node corresponding to the data user. The method is executed by the first shared proxy node, as described above. Figure 2 The shared proxy node 211a in the method. The method may include at least the following steps S101-S103.

[0063] S101. Obtain a verifiable credential issued by the blockchain node for the data user; the verifiable credential is determined based on the verifiable declaration configured by the data provider for the data user; the verifiable declaration is used to instruct the data provider to authorize the data user to obtain the business data corresponding to the shared data directory; the verifiable credential is used to instruct the data user to selectively obtain the business data corresponding to the target data directory in the shared data directory.

[0064] In this context, the data provider can refer to an object that provides business data for other objects to access, and the data user can refer to an object that accesses business data from other objects. The data provider and data user can be the same data object or different data objects; this is not limited here. Optionally, if the data provider and data user are the same object (e.g., both being the first object), data sharing can be achieved through the data sharing method provided in this application embodiment, or the first object can directly access the business data from the database where the business data is stored; this is not limited here. The business data can be any data used for data processing. For example, the business data can be employee information in an organization (e.g., company Q1), or it can be the registration account information of a software application; this is not limited here.

[0065] The shared data directory refers to the data directory corresponding to the business data obtained by the data provider's authorized data user object. This shared data directory includes all or part of the directory entries in the data directory corresponding to the business data provided by the data provider (i.e., the provided data directory). The data directory corresponding to any business data can include directory entries indicated by one or more data fields in the corresponding business data. One data field indicates one directory entry; that is, the data directory can include one or more directory entries. For example, if the business data is employee information in an organization (such as company Q1), and each employee's information includes multiple data fields, such as "name," "age," "graduated school," and "degree," then the data directory corresponding to this business data can include directory entries such as "name," "age," "graduated school," and "degree." Accordingly, the shared data directory can include directory entries indicated by data fields in the business data obtained by the data provider's authorized data user object, and the provided data directory includes directory entries indicated by data fields in the business data provided by the data provider.

[0066] The target data directory can refer to the data directory corresponding to the business data requested by the data user. This target data directory can be selected by the data user from the shared data directory; that is, it can refer to the data fields selectively disclosed by the data user. For a more detailed description of the data directory, please refer to the above description. Therefore, the target data directory can be the set of directory entries indicated by the data fields in the business data that the data provider authorizes the data user to obtain.

[0067] The directory entries in the target data directory can be all or part of the directory entries in the shared data directory. For example, the data directory (i.e., the shared data directory) of the business data obtained by the data provider (e.g., user U1) and the data user (e.g., user U2) can include four directory entries: "Name", "Age", "Graduated School", and "Degree". Then, user U2 can select the target data directory from the shared data directory. For example, user U2 can select "Name" and "Age" as the target data directory, meaning that the directory entries in the target data directory are part of the directory entries in the shared data directory. Or, user U2 can select all four directory entries: "Name", "Age", "Graduated School", and "Degree" as the target data directory, meaning that the directory entries in the target data directory are all the directory entries in the shared data directory.

[0068] For example, see Figure 4 , Figure 4 This is a schematic diagram illustrating the effect of a data directory provided in an embodiment of this application. For example... Figure 4 As shown, a data provider object can publish a data directory corresponding to the business data it provides. This data directory can include multiple directory entries, such as... Figure 4 The data directory provided, as shown in section 401a, can contain directory entries such as X1, X2, ..., X7. The data user then selects all or some of the directory entries from the provided data directory as shared data directories to request usage rights to the shared data directory from the data provider. For example, ... Figure 4 The shared data directory shown in 402a can contain directory entries such as X1, X2, ..., X4. These directory entries in shared data directory 402a are a subset of those in data directory 401a. Furthermore, the data user selects all or part of the directory entries from the shared data directory as the target data directory to request the corresponding business data, such as... Figure 4 The target data directory shown in 403a may contain directory entries such as directory entry X1, directory entry X2, ..., directory entry X2. The directory entries in the target data directory 403a are some of the directory entries in the shared data directory 402a.

[0069] The verifiable credential can be a credential used to obtain business data corresponding to the target data directory. This verifiable credential can be determined based on the verifiable declaration configured by the data provider for the data user. It can be either a first-type or a second-type verifiable credential. Specifically, if the directory entries in the target data directory are all directory entries in the shared data directory, then the verifiable credential can be a first-type verifiable credential; that is, a first-type verifiable credential is determined when the target data directory selected by the data user is all directory entries in the shared data directory. If the directory entries in the target data directory are only some directory entries in the shared data directory, then the verifiable credential can be a second-type verifiable credential; that is, a second-type verifiable credential is determined when the target data directory selected by the data user is only some directory entries in the shared data directory.

[0070] The first type of verifiable credential can refer to a verifiable statement, meaning that the first type of verifiable credential can be a credential that directly uses the verifiable statement as its credential. The second type of verifiable credential can refer to a verifiable expression determined based on a verifiable statement, meaning that the second type of verifiable credential can be a credential that uses the verifiable expression as its credential after determining the verifiable expression based on the verifiable statement.

[0071] In this context, a verifiable claim can refer to a credential granted by a data provider to a data user to access business data corresponding to a shared data directory. This verifiable claim is configured by the data provider for the data user. In other words, after the data provider configures a verifiable claim for the data user, the data user can access the business data corresponding to all or part of the directory entries in the shared data directory based on this verifiable claim. Essentially, the data user has the permission to access the business data corresponding to all or part of the directory entries (such as the target data directory) in the shared data directory.

[0072] In one embodiment, the verifiable claim is determined by a first data sharing management node corresponding to the data provider, and the verifiable claim is determined by a second data sharing management node corresponding to the data user. The first data sharing management node can be a general term for servers used to manage data sharing for the data provider; the second data sharing management node can also be a general term for servers used to manage data sharing for the data user. The first and second data sharing management nodes can be the same server or different servers, without limitation. The data sharing management node provided in this embodiment can be a node used to provide blockchain-based trusted computing services, thereby combining blockchain technology with a Trusted Execution Environment (TEE), which helps to improve the security of data sharing throughout the entire data sharing process.

[0073] For example, the content of the verifiable declaration is as follows:

[0074] {

[0075] / / The following is the metadata of the verifiable declaration.

[0076] "issuer":"did:tdid:c44:0x5c660f58f991382b12852f6a5f2d28f56a28b9bd", / / Decentralized use of identity identifiers for credential authorization objects. This provides the decentralized identity identifier for the object being issued.

[0077] "expirationDate":"2050-12-01T10:00:00+08:00", / / Expiration date

[0078] "issuanceDate":"2024-05-16T16:44:59+08:00", / / Publish time ...

[0080] "type":["VerifiableCredential"], / / Certificate type

[0081] / / The following is the declaration body information of the verifiable declaration.

[0082] "credentialSubject":{

[0083] "id": Data User Object DID, / / Decentralized identity identifier for the data user object, which can be a verified credential for authorization.

[0084] "data_source_did": Provides the DID of the data directory, / / Provides a decentralized directory identity for the data directory.

[0085] "DataItemsHash":["11111","22222","33333","44444"] / / Directory hash array

[0086] / / The following are directory entries in the shared data directory

[0087] "DataItems":[{

[0088] "Type":"string", / / The field type of the data field corresponding to a directory entry.

[0089]

[0090] A verifiable claim can include claim metadata, claim subject information, and claim proof information. The claim metadata can be used to describe the data of the verifiable claim. The verifiable claim can include a decentralized identity identifier for the credential authorization object (i.e., the object used to grant access to business data), which can provide a decentralized identity identifier for the object providing the claim. It can also include the expiration time (i.e., the end date of the verifiable claim's validity period) and the publication time (i.e., the time when the verifiable claim was issued). It can also include the credential type of the verifiable claim, which is also the claim type (also referred to as the first type). Alternatively, the verifiable claim can include other information, which is not limited here.

[0091] The claim body information can refer to the main content of the verifiable claim. This claim body information may include the decentralized identity of the credential-granted object of the verifiable claim (i.e., the object authorized by the verifiable claim), which in this case can be the decentralized user identity of the data user. The claim body information may also include the decentralized directory identity of the data directory provider (i.e., the decentralized identity of the data directory provider). It may also include a target hash array, which can be an array used to record the hash values ​​of each directory entry in the shared data directory. The claim body information may also include directory entries in the shared data directory, each of which may include information such as the field type, field description, and field name of the corresponding data field. The claim body information may also include claim key signature information and an identifier for the public key used to determine the claim key signature information, indicating which public key the data provider uses to sign.

[0092] The declaration proof information is obtained by the first data sharing management node corresponding to the data provider object signing the declaration content information based on the private key of the data provider object, and is used to identify that the verifiable declaration was determined by the data provider object.

[0093] Based on the above description, when the first data sharing management node generates a verifiable declaration, it can do so based on the declaration metadata, the declaration subject information, and the declaration proof information. For example, it can specifically generate a verifiable declaration based on the decentralized provider identity of the data provider object, the decentralized user identity of the data user object, the decentralized directory identity, the directory entries in the target hash array shared data directory, the declaration key signature information, and the declaration proof information.

[0094] For example, the content that can be verified is shown below:

[0095] {

[0096] / / The following is the expression metadata of the verifiable expression.

[0097] "type":"VerifiablePresentation", ........

[0099] / / The following is the content of the verifiable statements included in the verifiable expression.

[0100] "verifiableCredential":[{

[0101] "issuer":

[0102]

[0103] }],

[0104] / / The following is the information for expressing proof.

[0105] "proof":{

[0106] / / Data uses the object's signature information for this verifiable representation ......

[0108] }

[0109] }

[0110] A verifiable representation can include representation metadata, representation subject information, and representation proof information. The representation metadata describes the data of the verifiable representation. The verifiable representation can also include its credential type, which is the representation type (or secondary type).

[0111] The main content of the expression can refer to the core information of the verifiable expression. This main content can include the content of the verifiable statement, such as the statement metadata, the decentralized identity identifier of the credential authorization object, the directory hash array, the statement's key signature information, and the identifier of the public key used to determine the statement's key signature information. Furthermore, this main content can also include the target data directory selectively disclosed by the data user and the data indexes corresponding to the directory entries in the target data directory, instead of all directory entries in the shared data directory. Essentially, the directory entries of the shared data directory in the verifiable statement are replaced by the target data directory selectively disclosed by the data user and the data indexes corresponding to the directory entries in the target data directory. This allows for the retrieval of business data from a subset of directory entries in the shared data directory (i.e., directory entries in the target data directory) based on the verifiable expression, improving the flexibility of data sharing.

[0112] The expression proof information is obtained by the second data sharing management node corresponding to the data user signing the expression content information based on the private key of the data user, and is used to identify that the verifiable expression was determined by the data user.

[0113] Based on the above description, when the first data sharing management node generates a verifiable expression, it can do so by generating the verifiable expression based on the expression metadata, the expression subject information, and the expression proof information. For example, it can replace the directory entries of the shared data directory in the verifiable declaration with the target data directory selectively disclosed by the data user and the data index corresponding to the directory entries in the target data directory to obtain the expression subject information of the verifiable expression, thereby generating the verifiable expression based on the expression metadata, the expression subject information, and the expression proof information.

[0114] In some scenarios, any data sharing management node (such as a first data sharing management node or a second data sharing management node) can be used to manage data sharing among corresponding organizations (such as enterprises or institutions). Different organizations correspond to different data sharing management nodes. Furthermore, business objects within an organization (such as enterprise employees or institution personnel) can authorize other objects to obtain business data based on the corresponding data sharing management node, or they can apply to obtain business data from other objects based on the corresponding data sharing management node. Specifically, if the data user and the data provider belong to the same organization, then the first data sharing management node corresponding to the data provider and the second data sharing management node corresponding to the data user are the same data sharing management node; if the data user and the data provider belong to different organizations, then the first data sharing management node corresponding to the data provider and the second data sharing management node corresponding to the data user are different data sharing management nodes.

[0115] For example, see Figure 5 , Figure 5 This is a schematic diagram of the architecture of a data sharing system provided in an embodiment of this application. Figure 5As shown, the data sharing system may include a blockchain network 400a, which may include blockchain nodes LD1, LD2, LD3, LD4, etc. The system may also include a data provider object U1 (the aforementioned data provider object) in organization Z1, a database KD1 (the first database) of organization Z1, and a data sharing management node GD1 (the first data sharing management node) and a sharing agent node WD1 (the first sharing agent node) corresponding to organization Z1. Optionally, it may also include a sharing management object G1 corresponding to organization Z1, which can be the sharing management object corresponding to data sharing management node GD1 (e.g., the first sharing management object). The data sharing system may also include data user object U2 (i.e., the aforementioned data user object) in organization Z2, database KD2 (i.e., the second database) of organization Z2, and data sharing management node GD2 (i.e., the second data sharing management node) and sharing agent node WD2 (i.e., the second sharing agent node) corresponding to organization Z2. Optionally, it may also include sharing management object G2 corresponding to organization Z2. The sharing management object G2 may be the sharing management object corresponding to data sharing management node GD2 (e.g., it may be the second sharing management object).

[0116] In one possible implementation, obtaining verifiable credentials for a data user issued by a blockchain node may include the following steps: ① Receiving target task data sent by the blockchain node; the target task data refers to the data of a data sharing task associated with a data provider; the data sharing task is generated by the second data sharing management node corresponding to the data user based on the verifiable credentials of the data user when it receives the data sharing request from the data user; ② Obtaining the verifiable credentials of the data user from the target task data.

[0117] The data sharing task can refer to a task whereby a data user requests business data. This task is generated by the second data sharing management node corresponding to the data user when it receives the data sharing request, based on the data user's verifiable credentials. Specifically, when the second data sharing management node receives the data sharing request, it can determine the verifiable credentials based on the target data directory and verifiable declaration in the request, and then construct the data sharing task based on these credentials. The description of the second data sharing management node can be found above and will not be repeated here. The data sharing request can refer to a request from a data user to obtain business data corresponding to a target data directory, and this request may include the target data directory selected by the data user.

[0118] When generating a data sharing task based on verifiable credentials, the second data sharing management node can construct the task by using the verifiable credentials, reading database information, and writing database information. The read database information refers to the information of the database where the business data corresponding to the target data directory is stored, such as the database address, database port, database name, and table name. The write database information refers to the information of the database to which the business data corresponding to the target data directory is to be written, such as the database address, database port, database name, and table name. The data sharing task also includes other information, such as the task creation time, which is not limited here.

[0119] In one embodiment, the database information to be read can be determined by the second data sharing management node from the decentralized directory identity file (DID file) when it obtains the DID file corresponding to the shared data directory from the blockchain node. This DID file can be submitted to the blockchain node by the data provider through the first data sharing management node. The DID file can include the data directory corresponding to the business data provided by the data provider (i.e., the provided data directory) and the database information corresponding to the business data provided by the data provider. Therefore, the second data sharing management node can determine the database information to read based on the database information in the DID file.

[0120] The target task data refers to the data of the data sharing task associated with the data providing object. This target task data may include the data sharing task and its task signature information. The task signature information is obtained by the second data sharing management node signing the data sharing task based on the private key of the data using object.

[0121] In one embodiment, receiving target task data sent by a blockchain node may include the following steps: ① receiving task data sent by a blockchain node and determining the credential authorization object of the verifiable credential from the verifiable credentials in the task data; ② if the credential authorization object of the verifiable credential is a data provider object, then determining the task data as the target task data of the data sharing task associated with the data provider object.

[0122] The task data can be any task data obtained by the first shared proxy node from the blockchain node. The method for determining this task data can refer to the relevant description of the target task data above, and will not be repeated here. In this embodiment, after obtaining the task data of any data sharing task submitted by any business object (such as a data user object), the blockchain node can send the task data to the shared proxy node corresponding to each business object (such as a data provider object). Then, the shared proxy node corresponding to each business object can determine whether the obtained task data is associated with the corresponding business object (such as a data provider object). If so, the data sharing task can be executed; otherwise, the task data can be discarded, meaning the data sharing task will not be executed further. Based on this, it is not necessary for the data provider object to upload to a centralized platform for the data user object to obtain; instead, each shared proxy node can be responsible for executing the data sharing tasks associated with the corresponding data provider object, which helps improve data security during data sharing.

[0123] In this context, the credential authorization object can refer to the object used to grant access rights to business data, that is, the object used to issue verifiable claims. When the verifiable credential is a Type I verifiable credential, the credential authorization object is the object that issued the verifiable claim indicated by the Type I verifiable credential. When the verifiable credential is a Type II verifiable credential, the credential authorization object is the object that issued the verifiable claim corresponding to the verifiable expression indicated by the Type II verifiable credential.

[0124] If the credential authorization object of the verifiable credential is a data provider object, it means that the task data is task data associated with the data provider object, thus identifying the task data as the target task data of the data sharing task associated with the data provider object, and then the data sharing task can be executed.

[0125] Conversely, if the credential authorization object for verifiable credentials is not a data provider object, it means that the task data is not associated with the data provider object, and the task data will be discarded directly, thus the data sharing task will no longer be executed.

[0126] In one embodiment, the verifiable credential is determined from the target task data issued by the blockchain node. The target task data refers to the data of a data sharing task associated with a data provider. The data sharing task is generated by the second data sharing management node corresponding to the data user when it receives a data sharing request from the data user, based on the verifiable credential. The target task data includes task signature information, which is obtained by the second data sharing management node signing the data sharing task based on the data user's private key. Therefore, before obtaining the decentralized identity file corresponding to the decentralized identity identifier from the blockchain node based on the decentralized identity identifier of the data provider in the verifiable credential, the method further includes... The process includes: ① determining the decentralized user identity of the data user from verifiable credentials; ② obtaining the decentralized user identity file corresponding to the decentralized user identity from the blockchain node based on the decentralized user identity, and obtaining the public key of the data user from the decentralized user identity file; the decentralized user identity and the decentralized user identity file are sent from the second data sharing management node to the blockchain node; ③ verifying the task signature information using the public key of the data user, and when the task signature information is successfully verified, executing the step of obtaining the decentralized provider identity file corresponding to the decentralized provider identity from the blockchain node based on the decentralized provider identity of the data provider in the verifiable credentials.

[0127] The description of the target task data core data sharing task can be found in the above descriptions and will not be repeated here.

[0128] Here, the decentralized use identity identifier can refer to the decentralized identity identifier (DID) of the data user object. Based on the above description, it can be seen that the verifiable credential may include the decentralized identity identifier of the credential-authorized object, so the decentralized use identity identifier of the data user object can be determined based on the decentralized identity identifier of the credential-authorized object in the verifiable credential.

[0129] The decentralized usage identity file can refer to the decentralized identity file corresponding to the decentralized usage identity identifier; that is, the decentralized usage identity file refers to the decentralized identity file of the data user. Therefore, obtaining the decentralized usage identity file corresponding to the decentralized usage identity identifier from the blockchain node based on the decentralized usage identity identifier can include the first shared proxy node sending a usage identity file retrieval request for the data user to the blockchain node. Upon receiving this usage identity retrieval request, the blockchain node can retrieve the decentralized usage identity file corresponding to the decentralized usage identity identifier from the blockchain based on the usage identity retrieval request and return the decentralized usage identity file to the first shared proxy node. This usage identity file retrieval request can be a request to obtain the decentralized identity file of the data user, and the usage identity file retrieval request can carry the decentralized usage identity identifier.

[0130] In one embodiment, a blockchain node may store an identity mapping relationship (e.g., referred to as an identity mapping relationship) between decentralized user identity identifiers and decentralized user identity files. This identity mapping relationship refers to the mapping relationship between decentralized identity identifiers (e.g., decentralized user identity identifiers) and decentralized identity files (e.g., decentralized user identity files). This identity mapping relationship can be determined based on an identity-on-chain transaction sent by a second data sharing management node. This identity-on-chain transaction can be used to instruct the establishment of an identity mapping relationship between the decentralized user identity identifier of a data user object and the corresponding decentralized user identity file. Thus, when a blockchain node writes the identity-on-chain transaction to the blockchain, it is equivalent to writing the identity mapping relationship between the decentralized user identity identifier and the decentralized user identity file into the blockchain. This identity-on-chain transaction can be generated by the second data sharing management node when it receives a second identity creation request sent by the corresponding shared management object (e.g., referred to as the second shared management object). This second identity creation request can be used to instruct the second data sharing management node to create a decentralized identity identifier and a decentralized identity file for the data user object. The shared management object can be an object used to manage business objects (such as users) of the corresponding data shared management node. For example, the shared management object of the second data shared management node can become the second shared management object.

[0131] Therefore, the process by which a blockchain node retrieves the decentralized identity file corresponding to the decentralized identity identifier based on the identity acquisition request can include: querying the blockchain for an identity mapping relationship that matches the decentralized identity identifier of the data user, and determining the decentralized identity file corresponding to the decentralized identity identifier based on the queried identity mapping relationship. For example, if the blockchain stores an identity mapping relationship G1 between a decentralized identity identifier B2 and a decentralized identity file W2, and the decentralized identity identifier (i.e., decentralized usage identity identifier) ​​of the data user (such as user U2) is B2, then the blockchain node can find the identity mapping relationship G2 based on the decentralized identity identifier B2, thereby determining the decentralized identity file W2 in the identity mapping relationship G2 as the decentralized usage identity file of the data user, and returning the decentralized usage identity file to the first shared agent node.

[0132] Optionally, the processing logic for a blockchain node to obtain a decentralized identity file (such as a decentralized use identity file) can be implemented by calling an identity file acquisition interface. For example, a blockchain node can call the identity file acquisition interface based on a decentralized use identity identifier to obtain the decentralized use identity file corresponding to the decentralized use identity identifier. In other words, the parameter passed to the identity file acquisition interface is the decentralized use identity identifier.

[0133] The decentralized identity file may include the public key of the data user object. This public key can be used to sign and verify signature information determined based on the data user object's private key. It is understood that the decentralized identity file may also include the data user object's decentralized identity identifier and basic object information. This basic object information may include the data user object's unique object identifier in the second data sharing management node, the data user object's name, and the data user object's object role, etc. The object role can refer to the role of a business object (such as a data user object) in the corresponding data sharing management node (such as the second data sharing management node). This object role can be configured for the data user object by the shared management object of the data sharing management node (such as the second data sharing management node), which can be an object used to manage the business objects (such as users) of the corresponding data sharing management node. This object role can include data provider roles, data user roles, etc. A data provider role refers to the role that provides business data, while a data user role refers to the role that acquires business data. Any business object can be configured as a data provider, a data user, or both simultaneously, depending on the business needs of the shared management object. Accordingly, if a business object (such as user U1) is configured as a data provider, then user U1 can provide business data for other business objects to acquire, thus acting as a data provider object. If a business object (such as user U2) is configured as a data user, then user U2 can acquire business data provided by other business objects, thus acting as a data user object.

[0134] As described above, the task signature information is obtained by the second data sharing management node signing the data sharing task using the private key of the data user. The first sharing agent node can then verify the task signature information using the public key of the data user. If the task signature verification is successful, it indicates that the data sharing task was submitted by the data user and has not been maliciously tampered with. The first sharing agent node then continues to execute the data sharing task, specifically by obtaining the decentralized identity file corresponding to the decentralized identity identifier from the blockchain node based on the decentralized identity identifier of the data provider in the verifiable credential. Conversely, if the task signature verification fails, it indicates that the data sharing task was not submitted by the data user and may have been maliciously tampered with. Therefore, the task should not be executed further, thus preventing unauthorized access to business data and ensuring the security of data sharing.

[0135] S102. Based on the decentralized identity identifier of the data provider object in the verifiable credential, obtain the decentralized identity file corresponding to the decentralized identity identifier from the blockchain node.

[0136] Here, the decentralized identity provider can refer to the decentralized identity (DID) of the data provider object. Based on the above description, it can be seen that the verifiable credential may include the decentralized identity of the credential-authorized object, and therefore the decentralized identity of the data provider object can be determined based on the decentralized identity of the credential-authorized object in the verifiable credential.

[0137] The decentralized identity file refers to the decentralized identity file corresponding to the decentralized identity identifier. In other words, it refers to the decentralized identity file of the data provider. Therefore, obtaining the decentralized identity file corresponding to the decentralized identity identifier from the blockchain node can be done by referring to the above description of obtaining a decentralized identity file. Specifically, the first shared proxy node sends a request to the blockchain node to obtain the identity file for the data provider. Upon receiving this request, the blockchain node can obtain the decentralized identity file corresponding to the decentralized identity identifier from the blockchain and return it to the first shared proxy node. This request can be for obtaining the decentralized identity file of the data provider, and it may carry the decentralized identity identifier.

[0138] In one embodiment, a blockchain node may store an identity mapping relationship (e.g., referred to as an identity mapping relationship) between a decentralized identity provider and a decentralized identity file. This identity mapping relationship refers to the mapping relationship between a decentralized identity provider (e.g., a decentralized identity provider) and a decentralized identity file (e.g., a decentralized identity file). This identity mapping relationship can be determined based on an identity-on-chain transaction sent by a first data sharing management node. This identity-on-chain transaction can be used to instruct the establishment of an identity mapping relationship between the decentralized identity provider of the data provider object and the corresponding decentralized identity file. Thus, when the blockchain node writes the identity-on-chain transaction to the blockchain, it is equivalent to writing the identity mapping relationship between the decentralized identity provider and the decentralized identity file into the blockchain. This identity-on-chain transaction can be generated by the first data sharing management node when it receives a first identity creation request sent by the corresponding shared management object (e.g., the first shared management object). This first identity creation request can be used to instruct the first data sharing management node to create a decentralized identity provider and a decentralized identity file for the data provider object.

[0139] Therefore, the process by which a blockchain node retrieves the decentralized identity file corresponding to the decentralized identity identifier based on the identity acquisition request can include: querying the blockchain for an identity mapping relationship that matches the decentralized identity identifier of the data provider, and determining the decentralized identity file corresponding to the decentralized identity identifier based on the queried identity mapping relationship. For example, if the blockchain stores an identity mapping relationship G1 between a decentralized identity identifier B1 and a decentralized identity file W1, and the decentralized identity identifier (i.e., the decentralized identity identifier) ​​of the data provider (such as user U1) is B1, then the blockchain node can find the identity mapping relationship G1 based on the decentralized identity identifier B1, thereby determining the decentralized identity file W1 in the identity mapping relationship G1 as the decentralized identity file of the data provider, and returning the decentralized identity file to the first shared agent node.

[0140] The decentralized identity provision file may include the public key of the data provider object. This public key can be used to sign and verify signature information determined based on the data provider object's private key. It is understood that the decentralized identity provision file may also include the data provider object's decentralized identity identifier and basic object information. This basic object information may include the data provider object's unique object identifier in the second data sharing management node, the data provider object's name, and the data provider object's role, etc. The description of the object role can be found in the relevant descriptions above and will not be repeated here.

[0141] For example, the contents of a decentralized identity file for a data provider object would look like this:

[0142]

[0143]

[0144] S103. Verify the verifiable credentials by providing identity files in a decentralized manner. When the verifiable credentials are successfully verified, retrieve the business data corresponding to the target data directory from the first database corresponding to the data provider object, and send the business data corresponding to the target data directory to the second shared agent node so that the second shared agent node stores the business data corresponding to the target data directory into the second database corresponding to the data user object.

[0145] Verification of verifiable credentials can be used to determine whether the target data directory requested by the data user is authorized by the data provider. The verification methods may differ depending on the type of verifiable credential (e.g., Type I or Type II verifiable credential). For Type I verifiable credentials, the declaration information in the verifiable statement can be directly verified to confirm whether the verifiable statement was issued by the data provider to the data user (i.e., the target data directory obtained by the data user is authorized by the data provider). Successful verification of the declaration information indicates successful verification of the Type I verifiable credential. For Type I verifiable credentials, the expression information in the verifiable expression must first be verified to confirm whether the verifiable expression was submitted by the data user. If the expression information is successfully verified, the key signature information in the declaration within the verifiable expression is further verified to confirm whether the target data directory selectively disclosed by the data user is authorized by the data provider. Only when the key signature information in the declaration within the verifiable expression is successfully verified is successful verification of the Type II verifiable credential.

[0146] In one embodiment, verifiable credentials include a first type of verifiable credentials, which refers to a verifiable claim. The first type of verifiable credentials is determined by the second data sharing management node when it determines that the target data directory selected by the data user is all directory entries of the shared data directory. The verifiable claim includes claim content information and claim proof information. The claim proof information is obtained by the first data sharing management node corresponding to the data provider signing the claim content information based on the private key of the data provider. Therefore, credential verification of verifiable credentials through a decentralized identity provision file may include the following steps: ① If the verifiable credential is a first type of verifiable credential, then determine the public key of the data provider from the decentralized identity provision file; ② Based on the public key of the data provider and the claim content information, sign and verify the claim proof information to obtain a verification result for the claim proof information; ③ Based on the verification result for the claim proof information, determine the first credential verification result for the first type of verifiable credential. The first credential verification result is used to indicate whether the verification of the first type of verifiable credential was successful or failed.

[0147] The declaration content information can be information used to determine the proof information of the declaration. This declaration content information can be all the information in the verifiable declaration except for the proof information (i.e., declaration metadata and declaration body information), or it can only include the declaration body information in the verifiable declaration; there is no limitation here. For a description of the declaration body information and declaration metadata, please refer to the relevant descriptions above; they will not be repeated here.

[0148] Based on the above description, the declaration proof information is obtained by the first data sharing management node corresponding to the data provider signing the declaration content information based on the data provider's private key. Therefore, the signature verification of the declaration proof information can be performed based on the data provider's public key and the declaration content information. The verification result of the declaration proof information can be used to indicate whether the verification was successful or failed. If the verification is successful, it means that the declaration was issued by the data provider to the data user (i.e., the target data directory obtained by the data user is authorized by the data provider). Conversely, if the verification fails, it means that the declaration was not issued by the data provider to the data user (i.e., the target data directory obtained by the data user is not authorized by the data provider).

[0149] The first voucher verification result refers to the result obtained from verifying a first-type verifiable voucher. This result indicates whether the verification of the first-type verifiable voucher was successful or failed. Specifically, if the verification result of the declared proof information indicates successful verification, then the verification of the first-type verifiable voucher is confirmed to be successful; conversely, if the verification result of the declared proof information indicates failed verification, then the verification of the first-type verifiable voucher is confirmed to have failed.

[0150] As described above, a verifiable credential may include credential type information. Therefore, this embodiment may further include: determining the type of the verifiable credential based on the credential type information in the verifiable credential; if the credential type information indicates that the verifiable credential is of a first type, then the verifiable credential is determined to be a first-class verifiable credential; conversely, if the credential type information indicates that the verifiable credential is of a second type, then the verifiable credential is determined to be a second-class verifiable credential. The first type may refer to the verifiable credential being a type of verifiable declaration (also known as a declaration type), and the second type may refer to the verifiable credential being a type of verifiable expression (also known as an expression type).

[0151] In one embodiment, verifiable credentials include a second type of verifiable credentials, which refers to a verifiable expression determined based on a verifiable claim. The second type of verifiable credentials is determined by the second data sharing management node when it determines that the target data directory selected by the data user is a subset of directory entries in the shared data directory. The verifiable expression includes expression content information and expression proof information. The expression content information includes key information of the expressible claim, key signature information of the claim, and the target data directory. The key signature information of the claim is obtained by the first data sharing management node corresponding to the data provider signing the key information of the claim based on the private key of the data provider. The expression proof information is obtained by the second data sharing management node corresponding to the data user signing the expression content information of the verifiable expression based on the private key of the data provider. Therefore, by providing identity files in a decentralized manner to verify verifiable credentials, it is possible to... The process includes the following steps: ① If the verifiable credential is a Type II verifiable credential, obtain the decentralized user identity file of the data user from the blockchain node, and determine the public key of the data user from the decentralized user identity file; ② Based on the public key of the data user and the expression content information, perform signature verification on the expression proof information to obtain the verification result for the expression proof information; ③ If the verification result for the expression proof information indicates successful verification, determine the public key of the data provider from the decentralized provider identity file; ④ Based on the public key of the data provider, the declaration key information, and the target data directory, perform signature verification on the declaration key signature information to obtain the verification result for the declaration key signature information; ⑤ Based on the verification result for the declaration key signature information, determine the second credential verification result for verifying the Type II verifiable credential; the second credential verification result is used to indicate whether the verification of the Type II verifiable credential was successful or failed.

[0152] The description of the second type of verifiable credentials can be found in the above descriptions and will not be repeated here.

[0153] The expression content information can be information used to determine the expression proof information. This expression content information can be all information in the verifiable expression except for the expression proof information (i.e., proof metadata and expression subject information), or it can only include the expression subject information in the verifiable expression; there is no limitation here. For a description of the expression subject information and expression metadata, please refer to the relevant descriptions above; they will not be repeated here.

[0154] Based on the above description, the expression proof information is obtained by the second data sharing management node corresponding to the data user signing the expression content information of the verifiable expression based on the private key of the data provider. Therefore, the signature verification of the expression proof information can be performed based on the public key of the data user and the expression content information. The method for obtaining the decentralized user identity file of the data user from the blockchain node and determining the public key of the data user from the decentralized user identity file can be referred to the relevant descriptions above and will not be repeated here. The verification result of the expression proof information can be used to indicate whether the verification was successful or failed. If the verification is successful, it means that the verifiable expression was submitted by the data user; conversely, if the verification fails, it means that the verifiable expression was not submitted by the data user.

[0155] Based on the above description, the declared key signature information is obtained by the first data sharing management node corresponding to the data provider signing the declared key information based on the data provider's private key. Therefore, the declared key signature information can be verified based on the data provider's public key, the declared key information, and the target data directory. The verification result of the declared key signature information indicates whether the verification was successful or failed. If the verification is successful, it means that the target data directory selectively disclosed by the data user is authorized by the data provider; conversely, if the verification fails, it means that the target data directory selectively disclosed by the data user is not authorized by the data provider.

[0156] The key information declared may include the hash value (e.g., the declaration hash value) of each directory entry in the shared data directory. In this embodiment, when verifying the key signature information, the key signature information can be verified based on the hash value (e.g., the verification hash value) calculated from the target data directory recorded in the verifiable expression, the declaration hash values ​​of the directory entries in the shared data directory that are different from the target data directory included in the key information, and the public key of the data provider. Optionally, the key information declared may also include the decentralized user identity of the data user and the decentralized directory identity of the data provider. In this case, the key signature information can be verified based on the hash value (e.g., the verification hash value) calculated from the target data directory recorded in the verifiable expression, the hash values ​​of other directory entries in the shared data directory excluding the target data directory, the decentralized user identity, the decentralized directory identity, and the public key of the data provider. Understandably, by verifying the key information declared above, when data users selectively disclose some directory items in the shared data directory (i.e., the target data directory), it is also possible to accurately verify whether the selected directory items (i.e., the target data directory) are directory items in the shared data directory authorized by the data provider. This allows data users to more flexibly select the business data they need to obtain, thereby improving the flexibility of data sharing.

[0157] The second credential verification result refers to the result obtained from verifying a second type of verifiable credential. This result indicates whether the verification of the second type of verifiable credential was successful or failed. Specifically, if the verification result of the declared key signature information indicates successful verification, then the verification of the second type of verifiable credential is confirmed to be successful; conversely, if the verification result of the declared key signature information indicates failed verification, then the verification of the second type of verifiable credential is confirmed to have failed.

[0158] In one embodiment, the shared data directory includes N directory entries, where N is a positive integer; the declaration key information includes a directory hash array of N directory entries, where the directory hash array includes the declaration hash values ​​corresponding to the N directory entries; the target data directory includes M directory entries from the N directory entries, where M is a positive integer less than N; the expression content information includes M directory entries and the data indices of the M directory entries in the directory hash array; then, based on the public key of the data provider object, the declaration key information, and the target data directory, the signature verification of the declaration key signature information can be performed to obtain the verification result for the declaration key signature information, which may include the following steps: ① Obtain the target data directory from the expression content information. ① Calculate the verification hash value corresponding to each of the M directory entries in the directory; ② Based on the data index of each of the M directory entries in the directory hash array, find the declaration hash value corresponding to each of the M directory entries in the directory hash array, and replace the declaration hash value corresponding to each of the M directory entries in the directory hash array with the verification hash value corresponding to each of the M directory entries to obtain the verification directory hash array; ③ Replace the directory hash array in the declaration key information with the verification directory hash array to obtain the verification declaration key information; ④ Based on the public key of the data provider object and the verification declaration key information, perform signature verification on the declaration key signature information to obtain the verification result for the declaration key signature information.

[0159] As described above, the directory entries in the target data directory can be all or part of the directory entries in the shared data directory. Therefore, the shared data directory includes N directory entries, and the target data directory can include M directory entries from the N directory entries, where M is a positive integer less than N.

[0160] The target hash array can be used to record the declaration hash value of each directory entry in the shared data directory. The declaration hash value refers to the hash value of each directory entry in the shared data directory when a verifiable declaration is issued. When the shared data directory includes N directory entries, the directory hash array in the declaration key information can be used to record the declaration hash values ​​corresponding to each of the N directory entries. The declaration hash value of each directory entry is stored in the array position corresponding to a different data index in the target hash array; that is, each directory entry has a corresponding data index in the target hash array. For example, a shared data directory includes directory items X1, X2, X3, and X4. The directory hash array can be DataItemsHas:["H11111","H22222","H33333","H44444"]. Here, the declared hash value of directory item X1 is H11111, stored at the position corresponding to data index S0, so the data index corresponding to directory item X1 is S0; the declared hash value of directory item X2 is H22222, stored at the position corresponding to data index S1, so the data index corresponding to directory item X2 is S1; and so on, the declared hash value of directory item X3 is H33333, the corresponding data index is S2, and the declared hash value of directory item X4 is H44444, the corresponding data index is S3.

[0161] The verification hash value can be calculated based on the hash values ​​of the M directory entries included in the content information. The verification hash value corresponding to each of the M directory entries can be calculated by performing a hash calculation on each of the M directory entries separately, thus obtaining the verification hash value corresponding to each of the M directory entries.

[0162] Specifically, based on the data indices of the M directory items in the directory hash array, the declaration hash values ​​corresponding to the M directory items can be found from the directory hash array. For example, the directory hash array can be DataItemsHas:["H11111","H22222","H33333","H44444"], and the target data directory items include directory item X1 and directory item X2. The data index corresponding to directory item X1 is S0, and the data index corresponding to directory item X2 is S1. Then, based on the data indices S0 and S1, the declaration hash values ​​"H11111" and "H22222" corresponding to directory item X1 and directory item X2 can be determined from the target hash array.

[0163] The verification directory hash array can be an array used to verify the declared key signature information. This verification directory hash array is obtained by replacing the declaration hash values ​​corresponding to the M directory entries in the directory hash array with the verification hash values ​​corresponding to the M directory entries. It is understood that, in this embodiment, for the verification of the declared key signature information to pass, the verification hash values ​​corresponding to the M directory entries must be consistent with the declaration hash values ​​corresponding to the M directory entries.

[0164] Specifically, the verification claim key information can be used to verify the claim key signature information. This verification claim key information can be obtained by replacing the directory hash array in the claim key information with a verification directory hash array. Based on the above description, if the claim key information includes a directory hash array and a decentralized usage identity identifier of the data usage object, then the verification claim key information can include both the verification directory hash array and the decentralized usage identity identifier.

[0165] In one embodiment, verifying the signature of a key signature information based on the public key of the data provider and the key information of the verification claim may include: performing a hash calculation on the key information of the verification claim to obtain a verification digest; decrypting the key signature information of the verification claim based on the public key of the data provider to obtain a reference digest corresponding to the key signature information of the verification claim; comparing the reference digest with the verification digest to obtain a comparison result; and determining the verification result of the key signature information of the verification claim based on the comparison result. If the comparison result indicates that the reference digest and the verification digest are the same, then the verification result of the key signature information of the verification claim indicates that the verification of the key signature information of the verification claim is successful; otherwise, if the comparison result indicates that the reference digest and the verification digest are different, then the verification result of the key signature information of the verification claim indicates that the verification of the key signature information of the verification claim fails. Here, the verification digest refers to the hash value obtained by hash calculation on the key information of the verification claim, and the reference digest can refer to the hash value obtained by decrypting the key signature information of the verification claim based on the public key of the data provider. It should be understood that the reference digest can be obtained by the first data sharing management node performing a hash calculation on the declaration key information. Specifically, the first data sharing management node can perform a hash calculation on the declaration key information to obtain the reference digest, and then encrypt the reference digest based on the private key of the data provider object to obtain the declaration key signature information.

[0166] For example, see Figure 6 , Figure 6 This is a flowchart illustrating a credential verification process provided in an embodiment of this application. Figure 6As shown, the first shared proxy node can obtain verifiable credentials (step S601a) and then determine the type of verifiable credentials (step S602a). If the verifiable credentials are of the first type, the public key of the data provider can be determined from the decentralized identity provision file. Based on the public key of the data provider and the declaration content information, the declaration proof information is signed and verified to obtain the verification result for the declaration proof information (step S603a). Then, it is determined whether the verification result for the declaration proof information indicates successful or unsuccessful verification (step S604a). If the verification result for the declaration proof information indicates successful verification, it is determined that the first type of verifiable credentials has been successfully verified (step S605a). Otherwise, if the verification result for the declaration proof information indicates unsuccessful verification, it is determined that the first type of verifiable credentials has failed to be verified (step S606a).

[0167] If the verifiable credential is a second type of verifiable credential, the public key of the data user is determined from the decentralized identity file. Based on the public key of the data user and the expression content information, the expression proof information is signed and verified to obtain the verification result for the expression proof information (step S607a). Then, it is determined whether the verification result for the expression proof information indicates successful or unsuccessful verification (step S608a). If the verification result for the expression proof information indicates unsuccessful verification, it is determined that the verification of the second type of verifiable credential has failed (step S609a). If the verification result for the expressed proof information indicates successful verification, then based on the public key of the data provider, the key information of the declaration, and the target data directory, the key signature information of the declaration is signed and verified to obtain the verification result for the key signature information of the declaration (step S610a). It is then determined whether the verification result for the key signature information of the declaration indicates successful or unsuccessful verification (step S611a). If the verification result for the key signature information of the declaration indicates unsuccessful verification, then it is determined that the verification of the second type of verifiable credential has failed (step S609a). Conversely, if the verification result for the key signature information of the declaration indicates successful verification, then it is determined that the verification of the second type of verifiable credential has been successful (step S612a).

[0168] Here, the first database can refer to the database corresponding to the data provider object, and the second database can refer to the database corresponding to the data user object. The second shared proxy node can refer to the shared proxy node corresponding to the data user object; the description of the second shared proxy node can be found in the above description.

[0169] When sending the business data corresponding to the target data directory to the second shared proxy node, the business data can be encrypted to obtain encrypted business data, which is then sent to the second shared proxy node. The second shared proxy node can then decrypt the encrypted business data to obtain the business data corresponding to the target data directory, and finally store the business data corresponding to the target data directory in the second database corresponding to the data user.

[0170] In this embodiment, the first shared proxy node corresponding to the data provider can obtain verifiable credentials from the blockchain node. Upon successful verification of the verifiable credentials based on the data provider's decentralized identity file, the first shared proxy node retrieves the business data corresponding to the target directory data from the first database corresponding to the data provider and sends this business data to the second shared proxy node. Throughout the entire business data acquisition process, the data provider does not need to send the shared business data to any third-party platform. Instead, upon determining that the data user can access the business data, it directly sends the business data from its own database to the data user's database, significantly reducing the risk of business data leakage. Furthermore, by verifying the data user's verifiable credentials, and ensuring that the decentralized identity file used to verify the verifiable credentials is on-chain to the blockchain, the reliability is high. This guarantees that the business data obtained by the data user is authorized by the data provider, thus preventing the arbitrary acquisition of the business data provided by the data provider. Therefore, in this embodiment, data sharing is achieved through the interaction between the shared proxy node corresponding to the data provider and the blockchain node, which helps improve the security of data sharing.

[0171] Further, please see Figure 7 , Figure 7 This is a flowchart illustrating a blockchain-based data sharing method provided in an embodiment of this application. The shared proxy nodes associated with the blockchain node include a first shared proxy node corresponding to the data provider and a second shared proxy node corresponding to the data user. The method is executed by the blockchain node, as described above. Figure 2 The method may include at least the following steps S201-S202. (The method refers to any blockchain node in the blockchain network 400a.)

[0172] S201. Issue a verifiable credential to the first shared agent node corresponding to the data provider object for the data user object; the verifiable credential is determined based on the verifiable declaration configured by the data provider object for the data user object; the verifiable declaration is used to instruct the data provider object to authorize the data user object to obtain the business data corresponding to the shared data directory; the verifiable credential is used to instruct the data user object to selectively obtain the business data corresponding to the target data directory in the shared data directory.

[0173] For details regarding verifiable credentials, please refer to the relevant description in step S101 above; they will not be repeated here.

[0174] In one embodiment, issuing verifiable credentials for the data user to the first shared proxy node corresponding to the data provider may include the following steps: ① Receiving a shared task on-chain transaction sent by the second data sharing management node corresponding to the data user; the shared task on-chain transaction carries the target task data of the data sharing task created by the data user, which is generated by the second data sharing management node based on the verifiable credentials of the data user when it receives the data sharing request from the data user; ② When writing the task on-chain transaction to the blockchain, sending the target task data containing the verifiable credentials to the first shared proxy node.

[0175] In this context, "shared task on-chain transaction" refers to a transaction used to upload data-sharing tasks to the blockchain. For details regarding the target task data, please refer to the descriptions above; they will not be repeated here.

[0176] Understandably, after a blockchain node writes a shared task transaction sent by any data sharing management node (such as a second data sharing management node) onto the blockchain, it can send the target task data containing verifiable credentials to the shared proxy nodes corresponding to each data sharing management node. This allows each network management node to sort the task data associated with its corresponding data provider. The blockchain node can process the shared task transaction based on the aforementioned data sharing contract before writing it onto the blockchain.

[0177] In one embodiment, when the first data sharing management node corresponding to the data provider receives a data directory publishing request (i.e., a request to publish a data directory) sent by the data provider, it can publish the data directory to the blockchain node. Specifically, the first data sharing node can send a data directory on-chain transaction corresponding to the data directory to the blockchain node, and then the blockchain node can write the data directory on-chain transaction to the blockchain to publish the data directory. The data user can then view the data directory published by the data provider on the blockchain through the second data sharing management node. Furthermore, the data user can select a shared data directory for which they need to apply for permission based on the viewed data directory. The second data sharing management node can then publish the data user's application for access to the shared data directory to the blockchain node. When the first data sharing management node receives the data user's application for access to the data directory published by itself (i.e., the first data sharing management node) from the blockchain, it can notify the data provider to approve the application to determine whether a verifiable statement authorizing the data user to access the shared data directory is required.

[0178] Specifically, the embodiments of this application may further include the following steps: ① receiving a data directory on-chain transaction sent by the first data sharing management node corresponding to the data provider, and writing the data directory on-chain transaction into the blockchain; the data directory on-chain transaction includes a decentralized directory identity identifier for providing the data directory and a decentralized directory identity file corresponding to the decentralized directory identity identifier; providing the data directory refers to the data directory corresponding to the business data provided by the data provider; ② receiving a data directory query request sent by the second data sharing management node corresponding to the data user, querying the decentralized directory identity file written into the blockchain based on the data directory query request, and returning the queried decentralized directory identity file to the second data sharing management node.

[0179] The data catalog on-chain transaction can be a transaction used to write the provided data catalog to the blockchain. This transaction includes a decentralized catalog identity identifier for the provided data catalog and a corresponding decentralized catalog identity file. The provided data catalog refers to the data catalog corresponding to the business data provided by the data provider; details can be found in the above description and will not be repeated here. When the blockchain writes the data catalog on-chain transaction, it is essentially publishing the provided data catalog to the blockchain. Blockchain nodes can process the data catalog on-chain transaction based on the aforementioned data sharing contract and then write it to the blockchain.

[0180] The decentralized directory identity identifier can be the decentralized identity identifier that provides the data directory, and the decentralized directory identity file can be the decentralized identity file corresponding to the decentralized directory identity identifier. In other words, the decentralized directory identity file can be the decentralized identity file that provides the data directory.

[0181] For example, the contents of a decentralized identity file that provides a data directory would look like this:

[0182]

[0183]

[0184] The directory query request can be a request to obtain a decentralized directory published on the blockchain. This data directory query request can be determined by the second data sharing management node when it receives a data directory query operation from a data user. Furthermore, when the blockchain node receives the data directory query request, it can query the full set of decentralized directory identity files written to the blockchain, or it can query the decentralized directory identity files written to the blockchain within a certain time frame (e.g., within the last 3 months), and then return the queried decentralized directory identity files to the second data sharing management node. This blockchain node can query the decentralized directory identity files written to the blockchain based on the aforementioned data sharing contract. Further, when the second data sharing management node detects that a data user is applying for access to business data in the shared data directory, it can initiate a directory usage application (i.e., an application to obtain access to business data in the shared data directory) to the blockchain node for the shared data directory selected by the data user. Specifically, this can be the second data sharing management node sending a directory usage application transaction to the blockchain node.

[0185] In one embodiment, this application embodiment may further include the following steps: ① Receiving a directory usage application transaction sent by the second data sharing management node corresponding to the data user; the directory usage application transaction refers to a transaction in which the data user applies for usage rights of business data for a shared data directory; the shared data directory is selected by the data user from the provided data directory; the provided data directory refers to the data directory corresponding to the business data provided by the data provider; the provided data directory is written into the blockchain through a data directory on-chain transaction sent by the first data sharing management node corresponding to the provided data directory; ② When writing the directory usage application transaction into the blockchain, the directory usage application transaction is sent to the first data sharing management node corresponding to the data provider, so that the first data sharing management node... When it is determined that the directory use application transaction is associated with the data provider, the directory use application transaction is written into the control database associated with the first data sharing management node. When the approval notification for the directory use application transaction is received, a verifiable statement for the data user is generated based on the target data directory, the decentralized use identity of the data user, and the decentralized use identity of the data provider. The statement corresponding to the verifiable statement is then sent to the blockchain node. When the statement is received, it is written into the blockchain and the verifiable statement in the statement is sent to the second data sharing management node so that the second data sharing management node can determine the verifiable credential based on the verifiable statement when requesting to obtain the business data corresponding to the target data directory.

[0186] In this context, a directory usage application transaction refers to a transaction in which a data user applies for access to business data within a shared data directory. The shared data directory is selected by the data user from the provided data directory; the specific determination process can be referred to the relevant descriptions above and will not be repeated here. The provided data directory refers to the data directory corresponding to the business data provided by the data provider; the method for publishing the provided data directory to the blockchain can be referred to the relevant descriptions above and will not be repeated here.

[0187] In one embodiment, when a blockchain node writes a directory usage request transaction to the blockchain, it can send the transaction to each data sharing management node that has subscribed to the data usage request, such as the first data sharing management node. Each data sharing management node can then process directory usage request transactions associated with its own data provider only when it detects such transactions. Conversely, it can discard directory usage request transactions not associated with its own data provider. This allows each data sharing management node to only process directory usage requests related to its own data provider. A data sharing management node (such as the first data sharing management node) can determine whether a directory usage request transaction is associated with a corresponding data provider by checking whether the publishing object of the data provider directory to which the shared data directory belongs in the directory usage request transaction is the data provider associated with that data sharing management node.

[0188] Based on this, when the first data sharing management node determines that the directory use application transaction is associated with the data provider object, it can store the directory use application transaction in the control database associated with the first data sharing management node. The control database can refer to the local database of the data sharing management node. Then, the first data sharing management node can perform subsequent processing on the directory use application transactions stored in the control database, thereby improving the efficiency and stability of data processing.

[0189] Furthermore, the first data sharing management node can obtain the approval results for directory use application transactions. For example, the first data sharing management node can send an approval notification to the data provider (specifically, the terminal device corresponding to the data provider), so that the data provider approves the directory use application transaction and submits the approval result to the first data sharing management node. Alternatively, the first data sharing management node can call the approval processing component to automatically approve the directory use application transaction. This approval processing component can be a component used to approve directory use application transactions, and its processing logic can be configured according to actual needs. For example, it can be approved based on a whitelist or blacklist, which is not limited here.

[0190] The description of verifiable claims can be found above and will not be repeated here. The first data sharing management node can generate verifiable claims for data users based on the target data directory, the decentralized identity of the data user, and the decentralized identity of the data provider. The specific method for generating verifiable claims can be found above and will not be repeated here.

[0191] Specifically, a declaration-on-chain transaction refers to a transaction used to add a verifiable declaration to the blockchain, and this transaction can include the verifiable declaration. Therefore, when a blockchain node writes a declaration-on-chain transaction to the blockchain, it is essentially adding the verifiable declaration to the blockchain.

[0192] Furthermore, blockchain nodes can send verifiable claims to the second data sharing management node, enabling the second data sharing management node to determine verifiable credentials based on the verifiable claims when requesting business data corresponding to the target data directory. Specifically, when the second data sharing management node receives a data sharing request from a data user, it determines the verifiable credentials based on the target data directory and the verifiable claims carried in the data sharing request. If the directory entries in the target data directory are all the directory entries of the shared data directory in the verifiable claims, the verifiable claims can be identified as first-type verifiable credentials. If the directory entries in the target data directory are only some of the directory entries of the shared data directory in the verifiable claims, a verifiable representation can be generated based on the verifiable claims and the target data directory, and the verifiable representation can be identified as second-type verifiable credentials.

[0193] S202. Upon receiving a request from the first shared agent node to obtain the identity file of the data provider object in the verifiable credential, the first shared agent node determines the decentralized identity file corresponding to the decentralized identity identifier based on the decentralized identity identifier of the data provider object carried in the identity file acquisition request, and returns the decentralized identity file to the first shared agent node so that the first shared agent node can verify the verifiable credential through the decentralized identity file. When the verification of the verifiable credential is successful, the first shared agent node retrieves the business data corresponding to the target data directory from the first database corresponding to the data provider object, and sends the business data corresponding to the target data directory to the second shared agent node so that the second shared agent node stores the business data corresponding to the target data directory in the second database corresponding to the data user object.

[0194] The description of providing the identity document retrieval request can be found above and will not be repeated here. The steps executed by the first shared agent node can be found above in steps S102-S103 and will not be repeated here.

[0195] In one embodiment, this application embodiment may further include: ① receiving a provision identity on-chain transaction sent by the first data sharing management node corresponding to the data provider object, and writing the provision identity on-chain transaction into the blockchain; the provision identity on-chain transaction is used to indicate the establishment of an identity mapping relationship between the decentralized use identity identifier of the data provider object and the decentralized provision identity file corresponding to the decentralized provision identity identifier; then, determining the decentralized provision identity file corresponding to the decentralized provision identity identifier based on the decentralized provision identity identifier of the data provider object carried in the identity file acquisition request includes: querying the blockchain for an identity mapping relationship that matches the decentralized provision identity identifier based on the decentralized provision identity identifier of the data provider object, and determining the decentralized provision identity file corresponding to the decentralized provision identity identifier based on the queried identity mapping relationship.

[0196] The introduction to providing identity for on-chain transactions can be found in the above descriptions, and the process of determining the decentralized provision of identity documents can also be found in the above descriptions, which will not be repeated here.

[0197] Please see Figure 8 , Figure 8 This is a flowchart illustrating the creation process of participating objects provided in an embodiment of this application. The process of creating participating objects (such as data users and data providers) for sharing from a shared management object (such as a first shared management object and a second shared management object) is described here with reference to the illustration, thereby enabling the decentralized identity files of the data provider and the data user to be uploaded to the blockchain. Specifically, the first shared management object can be used to create a data provider for data sharing. Specifically, S31, the first shared management object (which may specifically be the terminal device of the first shared management object) sends a first identity creation request to the first data shared management node; S32, the first data shared management node creates a decentralized providing identity identifier and a corresponding decentralized providing identity file for the data provider; S33, the first data shared management node sends an identity-uploading transaction to the blockchain node; S34a, the blockchain node returns a transaction identifier for the identity-uploading transaction to the first data shared management node; S34b, the first data shared management node returns a transaction identifier for the identity-uploading transaction to the first shared management object. The transaction identifier can be an identifier used to uniquely identify a transaction on the blockchain. This transaction identifier can be returned after the identity is written to the blockchain.

[0198] Among them, the second shared management object can be used to create data user objects for data sharing. Specifically, in S35, the second shared management object sends a second identity creation request to the second data sharing management node.

[0199] S36. The second data sharing management node creates a decentralized user identity identifier and a corresponding decentralized user identity file for the data user object; S37. The second data sharing management node sends an identity-on-chain transaction to the blockchain node; S38a. The blockchain node returns a transaction identifier for the identity-on-chain transaction to the second data sharing management node; S38b. The second data sharing management node returns a transaction identifier for the identity-on-chain transaction to the second shared management object.

[0200] Please see Figure 9 , Figure 9 This is a schematic diagram illustrating the process of publishing and applying for a data catalog according to an embodiment of this application. The diagram illustrates the process by which a data provider publishes a data catalog corresponding to business data for data sharing, and a data user applies for usage rights to the business data corresponding to the shared data catalog, thereby enabling the decentralized identity file of the data catalog to be uploaded to the blockchain. Specifically, the data provider can publish the data catalog on the blockchain through a first data sharing management node. Specifically, S41, the data provider (which may be its terminal device) sends a data catalog publishing request to the first data sharing management node; S42, the first data sharing management node creates a decentralized catalog identity identifier and a corresponding decentralized catalog identity file for the data catalog; S43, the first data sharing management node sends a data catalog uploading transaction to the blockchain node, which can be determined based on the decentralized catalog identity file; S44a, the blockchain node returns a transaction identifier for the data catalog uploading transaction to the first data sharing management node; S44b, the first data sharing management node returns the transaction identifier for the data catalog uploading transaction to the data provider.

[0201] Specifically, data users can submit a directory access application to the blockchain node through the second data sharing management node, requesting access to the corresponding business data in the shared data directory. The steps are as follows: S45, the data user (which may be the data user's terminal device) requests to view the provided data directory from the second data sharing management node; S46, the second data sharing management node sends a data directory query request to the blockchain node; S47, the blockchain node returns the queried decentralized directory identity file to the second data sharing management node; S48, the second data sharing management node returns the queried decentralized directory identity file to the data user; S49, the data user applies to the second data sharing management node for access to the business data in the shared data directory; S410, the second data sharing management node sends a directory access application transaction to the blockchain node; S411a, the blockchain node returns the transaction identifier of the directory access application transaction to the second data sharing management node; S411b, the second data sharing management node returns the transaction identifier of the directory access application transaction to the data user.

[0202] Please see Figure 10 , Figure 10 This is a flowchart illustrating the creation process of a verifiable claim provided in an embodiment of this application. The diagram illustrates the process by which a data provider approves a catalog usage application submitted by a data user, and, upon approval, generates a verifiable claim through a first data sharing management node. Specifically, S51, the blockchain node sends a directory usage application transaction to the first data sharing management node; this directory usage application transaction can be determined based on a directory usage application exclusively for data use; S52a, if it is irrelevant (i.e., the directory usage application transaction is not associated with the data provider), the first data sharing management node discards it; S52b, if it is relevant (i.e., the directory usage application transaction is associated with the data provider), the first data sharing management node writes the directory usage application transaction into the control database; S53, the first data sharing management node sends an approval notification to the data provider (which can specifically be the data provider's terminal device); S54, the data provider returns the approval result to the first data sharing management node; S55, if the approval is successful (i.e., the approval result indicates successful), the first data sharing management node generates a verifiable statement for the data user, and the specific method for generating the verifiable statement can be referred to the above description;

[0203] S56. The first data sharing management node sends a declaration of on-chain transaction to the blockchain node; S57a. The blockchain node returns the transaction identifier of the declaration of on-chain transaction to the first data sharing management node; S57b. The first data sharing management node returns the transaction identifier of the declaration of on-chain transaction to the data provider.

[0204] Please see Figure 11 , Figure 11 This is a schematic diagram illustrating a data sharing task publication process provided in an embodiment of this application. The diagram illustrates the process by which a data user creates and publishes a data sharing task for obtaining business data corresponding to all directory items through a second data sharing management node. Specifically, S61, the data user (which may specifically be the data user's terminal device) sends a data sharing request to the second data sharing management node; S62, the second data sharing management node creates a data sharing task based on a verifiable claim, specifically by determining a first type of verifiable credential based on the verifiable claim, thereby creating the data sharing task based on the first type of verifiable credential; S63, the second data sharing management node signs the data sharing task based on the data user's private key; S64, the second data sharing management node sends the shared task on-chain transaction to the blockchain node; S65a, the blockchain node returns the transaction identifier of the shared task on-chain transaction to the second data sharing management node; S65b, the second data sharing management node returns the transaction identifier of the shared task on-chain transaction to the data user.

[0205] Please see Figure 12 , Figure 12 This is a schematic diagram illustrating another process for publishing a data sharing task provided in this application embodiment. The diagram illustrates the process by which a data user creates and publishes a data sharing task for obtaining certain directory items through a second data sharing management node. Specifically, S71, the data user (which may specifically be the data user's terminal device) sends a data sharing request to the second data sharing management node; S72, the second data sharing management node generates a verifiable representation based on a verifiable declaration; S73, the second data sharing management node creates a data sharing task based on the verifiable representation, specifically by determining a second type of verifiable credential based on the verifiable representation, thereby creating the data sharing task based on the second type of verifiable credential; S74, the second data sharing management node signs the data sharing task based on the data user's private key; S75, the second data sharing management node sends the shared task on-chain transaction to the blockchain node; S76a, the blockchain node returns the transaction identifier of the shared task on-chain transaction to the second data sharing management node; S76b, the second data sharing management node returns the transaction identifier of the shared task on-chain transaction to the data user.

[0206] Please see Figure 13 , Figure 13This is a schematic diagram illustrating a process for executing a data sharing task provided in an embodiment of this application. The diagram illustrates the process by which the shared proxy node (i.e., the first shared proxy node) corresponding to the data providing object executes the data sharing task. Specifically, it first verifies the verifiable credentials, and upon successful credential verification, allows the user object to obtain the business data corresponding to the target data directory. Specifically, in S81, the blockchain node sends the target task data to the first shared agent node; in S82, the first shared agent node sends an identity acquisition request to the blockchain node; in S83, the blockchain node returns a decentralized identity file to the first shared agent node; in S84, the first shared agent node verifies the task signature information; in S85, if the verification fails, the data is discarded (i.e., the first shared agent node discards the target task data and no longer executes the data sharing task); in S86, if the verification succeeds, the first shared agent node sends an identity acquisition request to the blockchain node; in S87, the blockchain node returns a decentralized identity provision file to the first shared agent node; in S88, the first shared agent node verifies the verifiable credentials based on the decentralized identity file; the credential verification here can refer to the above. Figure 6 The relevant descriptions are not repeated here. S89. If verification fails, the data is discarded (i.e., the first shared agent node discards the target task data and no longer executes the data sharing task); S810. If verification succeeds, the first shared agent node retrieves the business data corresponding to the target data directory from the first database; S811. The first shared agent node sends the business data corresponding to the target data directory to the second shared agent node; S812. The second shared agent node writes the business data corresponding to the target data directory into the second database.

[0207] Please see Figure 14 , Figure 14 This is a schematic diagram of the architecture of another data sharing system provided in an embodiment of this application. For example... Figure 14As shown, the data sharing system may include a blockchain network 400a, and multiple business objects (such as data users or data providers) and related equipment (such as corresponding data sharing management nodes, sharing agent nodes, databases, and control databases) associated with various organizations for data sharing. For example, the blockchain network 400a may include blockchain nodes LD1, LD2, LD3, LD4, etc. Similarly, the multiple organizations may include organization Z1, organization Z2, organization Z3, and organization Z4. This section describes the data sharing system in conjunction with a complete data sharing process. Each organization's sharing management object (such as sharing management object G1) can create participating users (i.e., participating objects) on its respective data sharing management node and assign object roles (such as data provider roles or data user roles) to the business objects. Each participating object (such as the data provider and data user mentioned above) will receive a decentralized identity identifier and a corresponding decentralized identity file.

[0208] Furthermore, shared management objects in various organizations can create corresponding shared proxy nodes (also known as data shared proxy gateway nodes) on the corresponding data shared management nodes. For example, a shared management object G1 (such as the second shared management object mentioned above) can request the creation of a corresponding shared proxy node from a data shared management node GD1 (such as the second data shared management node mentioned above). Then, the data shared management node GD1 can register the identity certificate of the shared proxy node WD1 on the blockchain, thereby configuring the shared proxy node WD1 corresponding to the data shared management node. As can be seen, as... Figure 14 The organization Z2 shown can be an organization that does not have a shared agent node configured.

[0209] Each shared proxy node (such as the first shared proxy node mentioned above) can be used to actually execute data sharing tasks, such as the shared proxy node WD3 corresponding to data provider object U1. The execution process of the data sharing task is to read the authorized business data from the database of the data provider object (such as the object database KD3 of data provider object U1), and transmit it to the database corresponding to the data user object (such as the shared proxy node WD1 corresponding to data user object U2) through the shared proxy node of the data user object.

[0210] Furthermore, data providers (such as data provider U1 in organization Z3) can publish a data provision catalog on the corresponding data sharing management node (such as data sharing management node GD3). The DID document (i.e., decentralized identity file) corresponding to the DID of the data provision catalog will display the database information, data field information (i.e., catalog entries), etc. of the corresponding business data. The DID (i.e., decentralized identity identifier) ​​of the data provision catalog and the corresponding decentralized identity file (i.e., DID document) will be stored on the blockchain.

[0211] Furthermore, data users (such as data user U2 in organization Z2 or data user U3 in organization Z4) can see all published data catalogs on the blockchain. They can then determine whether the data they need is the one described in the catalog and the provided data fields (i.e., catalog entries). If so, they can initiate a catalog usage request for the shared data catalog. Data users can request access to all or part of the business data corresponding to the catalog entries.

[0212] Furthermore, the data provider (such as data provider U1 in organization Z3) can subscribe to the directory usage application from the blockchain, and then approve the application by granting or rejecting it, thus determining whether the application is approved or rejected. If the data provider agrees to the data user's application for the specified shared data directory, it will issue a data directory authorization VC (i.e., the verifiable statement mentioned above) through the corresponding data sharing management node (such as data sharing management node GD3, i.e., the first data sharing management node mentioned above). This verifiable statement includes the data user's DID (i.e., decentralized user identity), the list of authorized fields (i.e., the shared data directory), the list of authorized field hashes (i.e., the directory hash array mentioned above, for selective disclosure), the data provider's key signature information, and the statement proof information, etc.

[0213] Furthermore, data users (such as data user U1 and data user U2) who have obtained the data catalog authorization VC (i.e., the verifiable declaration mentioned above) can initiate data sharing tasks as needed to obtain business data. Data users can provide the entire verifiable declaration to obtain business data, specifically the business data corresponding to all catalog entries in the authorized shared data catalog; they can also issue a VP (verifiable expression) to selectively disclose certain fields (i.e., selectively disclose certain catalog entries), thereby obtaining only the required specified fields (i.e., the target data catalog), thus achieving differentiated data sharing on demand.

[0214] In this embodiment, the first shared proxy node corresponding to the data provider can obtain verifiable credentials from the blockchain node. Upon successful verification of the verifiable credentials based on the data provider's decentralized identity file, the first shared proxy node retrieves the business data corresponding to the target directory data from the first database corresponding to the data provider and sends this business data to the second shared proxy node. Throughout the entire business data acquisition process, the data provider does not need to send the shared business data to any third-party platform. Instead, upon determining that the data user can access the business data, it directly sends the business data from its own database to the data user's database, significantly reducing the risk of business data leakage. Furthermore, by verifying the data user's verifiable credentials, and ensuring that the decentralized identity file used to verify the verifiable credentials is on-chain to the blockchain, the reliability is high. This guarantees that the business data obtained by the data user is authorized by the data provider, thus preventing the arbitrary acquisition of the business data provided by the data provider. Therefore, in this embodiment, data sharing is achieved through the interaction between the shared proxy node corresponding to the data provider and the blockchain node, which helps improve the security of data sharing.

[0215] Please see Figure 15 , Figure 15 This is a schematic diagram illustrating the interaction of a blockchain-based data sharing system provided in this application embodiment. The data sharing system may include blockchain nodes and shared proxy nodes associated with the corresponding blockchain nodes. The shared proxy nodes associated with the corresponding blockchain nodes include a first shared proxy node corresponding to a data provider and a second shared proxy node corresponding to a data user. The data sharing system may include:

[0216] S1501, The blockchain node issues a verifiable credential to the first shared agent node corresponding to the data provider object;

[0217] S1502, The first shared agent node sends a request to the blockchain node to obtain the identity file of the data provider object in the verifiable credential;

[0218] S1503. The blockchain node determines the decentralized identity file corresponding to the decentralized identity identifier based on the decentralized identity identifier of the data provider object carried in the identity file acquisition request.

[0219] S1504, The blockchain node will decentralizedly provide the identity file back to the first shared agent node;

[0220] S1505. The first shared agent node verifies the verifiable credentials by providing identity files in a decentralized manner, and when the verifiable credentials are successfully verified, it retrieves the business data corresponding to the target data directory from the first database corresponding to the data provider object.

[0221] S1506. The first shared agent node sends the business data corresponding to the target data directory to the second shared agent node.

[0222] S1507. The second shared agent node stores the business data corresponding to the target data directory into the second database corresponding to the data user object.

[0223] Please see Figure 16 , Figure 16 This is a schematic diagram of the structure of a blockchain-based data sharing device provided in an embodiment of this application. Figure 16 As shown, the shared proxy nodes associated with the blockchain node corresponding to the blockchain include a first shared proxy node corresponding to the data provider and a second shared proxy node corresponding to the data user. The blockchain-based data sharing device 1 can be a computer program (including program code) running on the first shared proxy node; for example, the blockchain-based data sharing device 1 is an application software. It is understood that the blockchain-based data sharing device 1 can be used to execute the corresponding steps in the blockchain-based data sharing method provided in the embodiments of this application. Figure 16 As shown, the blockchain-based data sharing device 1 may include: a credential acquisition module 11, an identity document acquisition module 12, and a credential verification module 13;

[0224] The credential acquisition module 11 is used to acquire verifiable credentials issued by the blockchain node for the data user; the verifiable credentials are determined based on the verifiable declaration configured by the data provider for the data user; the verifiable declaration is used to instruct the data provider to authorize the data user to acquire the business data corresponding to the shared data directory; the verifiable credentials are used to instruct the data user to selectively acquire the business data corresponding to the target data directory in the shared data directory.

[0225] The identity file acquisition module 12 is provided to provide decentralized identity identifiers for objects based on data in verifiable credentials, and to obtain the decentralized identity file corresponding to the decentralized identity identifier from the blockchain node;

[0226] The credential verification module 13 is used to verify verifiable credentials by providing identity files in a decentralized manner. When the verifiable credentials are successfully verified, the module retrieves the business data corresponding to the target data directory from the first database corresponding to the data provider object and sends the business data corresponding to the target data directory to the second shared agent node, so that the second shared agent node stores the business data corresponding to the target data directory into the second database corresponding to the data user object.

[0227] Among them, verifiable credentials include the first type of verifiable credentials, which refers to verifiable claims; the first type of verifiable credentials are determined by the second data sharing management node when determining that the target data directory selected by the data user is all the directory entries of the shared data directory; verifiable claims include claim content information and claim proof information, and the claim proof information is obtained by the first data sharing management node corresponding to the data provider signing the claim content information based on the private key of the data provider;

[0228] The credential acquisition module 11 is specifically used for:

[0229] If the verifiable credential is a Type I verifiable credential, then the public key of the data provider object is determined from the decentralized identity provision file;

[0230] Based on the public key of the data provider and the declaration content information, the declaration proof information is signed and verified to obtain the verification result for the declaration proof information;

[0231] Based on the verification results of the declared proof information, a first credential verification result is determined for the verification of the first type of verifiable credential; the first credential verification result is used to indicate whether the verification of the first type of verifiable credential was successful or unsuccessful.

[0232] The verifiable credentials include a second type of verifiable credentials, which refers to a verifiable expression determined based on a verifiable statement. This second type of verifiable credential is determined by the second data sharing management node when it determines that the target data directory selected by the data user is a subset of directory entries in the shared data directory. The verifiable expression includes expression content information and expression proof information. The expression content information includes the key information of the expressible statement, the key signature information of the statement, and the target data directory. The key signature information of the statement is obtained by the first data sharing management node corresponding to the data provider signing the key information of the statement based on the private key of the data provider. The expression proof information is obtained by the second data sharing management node corresponding to the data user signing the expression content information of the verifiable expression based on the private key of the data provider.

[0233] The credential acquisition module 11 is specifically used for:

[0234] If the verifiable credential is a second type of verifiable credential, then obtain the decentralized use identity file of the data user from the blockchain node, and determine the public key of the data user from the decentralized use identity file;

[0235] Based on the public key of the data user and the expression content information, the expression proof information is signed and verified to obtain the verification result for the expression proof information;

[0236] If the verification result for the expression proof information indicates that the verification of the expression proof information is successful, then the public key of the data provider object is determined from the decentralized identity provision file;

[0237] Based on the public key of the data provider, the key information of the declaration, and the target data directory, the key signature information of the declaration is signed and verified to obtain the verification result for the key signature information of the declaration.

[0238] Based on the verification results of the key signature information declared, a second credential verification result is determined for the verification of the second type of verifiable credential; the second credential verification result is used to indicate whether the verification of the second type of verifiable credential was successful or failed.

[0239] The shared data directory contains N directory entries, where N is a positive integer. The key information declaration includes a directory hash array of N directory entries, which contains the declaration hash values ​​corresponding to the N directory entries. The target data directory contains M directory entries from the N directory entries, where M is a positive integer less than N. The content information includes M directory entries and the data indices of the M directory entries in the directory hash array.

[0240] The credential acquisition module 11 is specifically used for:

[0241] Extract M directory entries from the target data directory from the content information, and calculate the verification hash value corresponding to each of the M extracted directory entries;

[0242] Based on the data indices of M directory entries in the directory hash array, find the declaration hash values ​​corresponding to the M directory entries in the directory hash array, replace the declaration hash values ​​corresponding to the M directory entries in the directory hash array with the verification hash values ​​corresponding to the M directory entries, and obtain the verification directory hash array.

[0243] Replace the directory hash array in the declaration key information with the verification directory hash array to obtain the verification declaration key information;

[0244] Based on the public key of the data provider and the key information of the verification claim, the key signature information of the claim is signed and verified to obtain the verification result for the key signature information of the claim.

[0245] The credential acquisition module 11 is specifically used for:

[0246] Receive target task data sent by blockchain nodes; target task data refers to the data sharing task associated with the data provider; the data sharing task is generated by the second data sharing management node corresponding to the data user when it receives the data sharing request from the data user, based on the verifiable credentials of the data user.

[0247] Data is obtained from the target task data using the object's verifiable credentials.

[0248] The credential acquisition module 11 is specifically used for:

[0249] Receive task data sent by blockchain nodes, and determine the credential authorization object of the verifiable credential from the verifiable credentials in the task data;

[0250] If the credential authorization object for verifiable credentials is a data provider object, then the task data is determined as the target task data of the data sharing task associated with the data provider object.

[0251] Among them, the verifiable credentials are determined from the target task data issued by the blockchain node. The target task data refers to the data of the data sharing task associated with the data provider. The data sharing task is generated by the second data sharing management node corresponding to the data user when it receives the data sharing request from the data user. The target task data includes task signature information, which is obtained by the second data sharing management node signing the data sharing task based on the private key of the data user.

[0252] The blockchain-based data sharing device 1 also includes: a task verification module 14;

[0253] Task verification module 14 is specifically used for:

[0254] Decentralized use of identity identifiers to determine data users from verifiable credentials;

[0255] Based on decentralized use identity identifiers, the decentralized use identity file corresponding to the decentralized use identity identifier is obtained from the blockchain node, and the public key of the data use object is obtained from the decentralized use identity file; the decentralized use identity identifier and the decentralized use identity file are sent from the second data sharing management node to the blockchain node;

[0256] The task signature information is verified by using the public key of the data provider object. When the task signature information is successfully verified, the decentralized provisioning identity identifier of the data provider object in the verifiable credential is executed, and the decentralized provisioning identity file corresponding to the decentralized provisioning identity identifier is obtained from the blockchain node.

[0257] Please see Figure 17 , Figure 17 This is a schematic diagram of the structure of a blockchain-based data sharing device provided in an embodiment of this application. Figure 17 As shown, the shared proxy nodes associated with the blockchain node corresponding to the blockchain include a first shared proxy node corresponding to the data provider and a second shared proxy node corresponding to the data user. The blockchain-based data sharing device 2 can be a computer program (including program code) running on the blockchain node, for example, the blockchain-based data sharing device 2 is an application software; it is understood that the blockchain-based data sharing device 2 can be used to execute the corresponding steps in the blockchain-based data sharing method provided in the embodiments of this application. Figure 17 As shown, the blockchain-based data sharing device 2 may include: a credential issuance module 21 and an identity document issuance module 22;

[0258] The credential issuance module 21 is used to issue verifiable credentials for data users to the first shared agent node corresponding to the data provider object. The verifiable credentials are determined based on the verifiable declaration configured by the data provider object for the data user object. The verifiable declaration is used to instruct the data provider object to authorize the data user object to obtain business data corresponding to the shared data directory. The verifiable credentials are used to instruct the data user object to selectively obtain business data corresponding to the target data directory in the shared data directory.

[0259] The identity file distribution module 22 is used to, upon receiving a request from the first shared agent node to obtain an identity file for the data provider object in the verifiable credential, determine the decentralized identity file corresponding to the decentralized identity identifier of the data provider object carried in the identity file acquisition request, and return the decentralized identity file to the first shared agent node so that the first shared agent node can verify the verifiable credential through the decentralized identity file. When the verification of the verifiable credential is successful, the module retrieves the business data corresponding to the target data directory from the first database corresponding to the data provider object and sends the business data corresponding to the target data directory to the second shared agent node so that the second shared agent node can store the business data corresponding to the target data directory in the second database corresponding to the data user object.

[0260] The blockchain-based data sharing device 1 may further include: a declaration generation module 23;

[0261] Among them, the declaration generation module 23 is specifically used for:

[0262] The data user receives a directory usage application transaction sent by the second data sharing management node corresponding to the data user; the directory usage application transaction refers to the transaction in which the data user applies for the right to use business data in the shared data directory; the shared data directory is selected by the data user from the provided data directory; the provided data directory refers to the data directory corresponding to the business data provided by the data provider; the provided data directory is written to the blockchain through the on-chain transaction of the provided data directory corresponding to the first data sharing management node corresponding to the data provider.

[0263] When writing a directory use application transaction to the blockchain, the directory use application transaction is sent to the first data sharing management node corresponding to the data provider. When the first data sharing management node determines that the directory use application transaction is associated with the data provider, it writes the directory use application transaction into the control database associated with the first data sharing management node. When it receives the approval notification for the directory use application transaction, it generates a verifiable statement for the data user based on the target data directory, the decentralized use identity of the data user, and the decentralized use identity of the data provider, and sends the statement corresponding to the verifiable statement to the blockchain node.

[0264] Upon receiving a declaration of a transaction on the blockchain, the declaration of the transaction is written into the blockchain, and the verifiable declaration in the declaration of the transaction is sent to the second data sharing management node, so that the second data sharing management node can determine the verifiable credential based on the verifiable declaration when requesting to obtain the business data corresponding to the target data directory.

[0265] The blockchain-based data sharing device 1 may also include: an identity file on-chain module 24;

[0266] Among them, the identity file on-chain module 24 is specifically used for:

[0267] The system receives the identity provision on-chain transaction sent by the first data sharing management node corresponding to the data provider object and writes the identity provision on-chain transaction into the blockchain. The identity provision on-chain transaction is used to indicate the establishment of an identity mapping relationship between the decentralized use identity identifier of the data provider object and the decentralized provision identity file corresponding to the decentralized provision identity identifier.

[0268] Based on the decentralized provider identity identifier of the data provider object carried in the identity file retrieval request, determine the decentralized provider identity file corresponding to the decentralized provider identity identifier, including:

[0269] Based on the decentralized identity identifier provided by the data provider, the blockchain is used to query the identity mapping relationship that matches the decentralized identity identifier, and the decentralized identity file corresponding to the decentralized identity identifier is determined based on the queried identity mapping relationship.

[0270] The voucher issuance module 21 is specifically used for:

[0271] The system receives a shared task on-chain transaction sent by the second data sharing management node corresponding to the data user object. The shared task on-chain transaction carries the target task data of the data sharing task created by the data user object. The data sharing task is generated by the second data sharing management node based on the verifiable credentials of the data user object when it receives the data sharing request from the data user object.

[0272] When writing the task transaction to the blockchain, the target task data containing verifiable credentials is sent to the first shared agent node.

[0273] Please see Figure 18 , Figure 18 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 18 As shown, the computer device can be the aforementioned first shared proxy node or blockchain node. The computer device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 18 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0274] In such Figure 18In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to execute the description of the blockchain-based data sharing method in any of the corresponding embodiments described above, which will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0275] Furthermore, it should be noted that this application also provides a computer-readable storage medium storing the computer program executed by the aforementioned blockchain-based data sharing device 1 and blockchain-based data sharing device 2. The computer program includes program instructions, which, when executed by the processor, enable the execution of the blockchain-based data sharing method described in the preceding embodiments. Therefore, these descriptions will not be repeated here. Additionally, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the embodiments of the computer-readable storage medium involved in this application, please refer to the description of the method embodiments of this application.

[0276] The aforementioned computer-readable storage medium can be a blockchain-based data sharing device provided in any of the foregoing embodiments or an internal storage unit of the aforementioned computer device, such as a hard drive or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0277] Furthermore, it should be noted that this application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in any of the preceding corresponding embodiments. Additionally, the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the embodiments of the computer program product or computer program involved in this application, please refer to the description of the method embodiments of this application.

[0278] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0279] 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, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. 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 application.

[0280] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data sharing method based on blockchain, characterized in that, The shared proxy nodes associated with the blockchain node corresponding to the blockchain include a first shared proxy node corresponding to the data provider and a second shared proxy node corresponding to the data user. The method is executed by the first shared proxy node, and the method includes: Obtain a verifiable credential issued by the blockchain node for the data user; the verifiable credential is determined based on a verifiable declaration configured by the data provider for the data user; the verifiable declaration is used to instruct the data provider to authorize the data user to obtain business data corresponding to the shared data directory; the verifiable credential is used to instruct the data user to selectively obtain business data corresponding to a target data directory in the shared data directory. Based on the decentralized identity identifier of the data provider object in the verifiable credential, obtain the decentralized identity file corresponding to the decentralized identity identifier from the blockchain node; The verifiable credentials are verified by providing the identity file in a decentralized manner. When the verification of the verifiable credentials is successful, the business data corresponding to the target data directory is retrieved from the first database corresponding to the data provider and sent to the second shared agent node, so that the second shared agent node stores the business data corresponding to the target data directory in the second database corresponding to the data user.

2. The method according to claim 1, characterized in that, The verifiable credentials include a first type of verifiable credentials, which refers to the verifiable declaration; the first type of verifiable credentials are determined by the second data sharing management node when it determines that the target data directory selected by the data user is all the directory entries of the shared data directory; the verifiable declaration includes declaration content information and declaration proof information, and the declaration proof information is obtained by the first data sharing management node corresponding to the data provider signing the declaration content information based on the private key of the data provider; The step of verifying the verifiable credentials by providing the identity file in a decentralized manner includes: If the verifiable credential is a first type of verifiable credential, then the public key of the data provider object is determined from the decentralized identity provision file; Based on the public key of the data provider and the declaration content information, the declaration proof information is signed and verified to obtain the verification result for the declaration proof information; Based on the verification results of the declared proof information, a first credential verification result is determined for the first type of verifiable credential; the first credential verification result is used to indicate whether the verification of the first type of verifiable credential was successful or failed.

3. The method according to claim 1, characterized in that, The verifiable credentials include a second type of verifiable credentials, which refers to a verifiable expression determined based on the verifiable declaration. The second type of verifiable credentials is determined by the second data sharing management node when it determines that the target data directory selected by the data user is a subset of directory entries in the shared data directory. The verifiable expression includes expression content information and expression proof information. The expression content information includes key declaration information, key declaration signature information, and the target data directory of the verifiable declaration. The key declaration signature information is obtained by the first data sharing management node corresponding to the data provider signing the key declaration information based on the private key of the data provider. The expression proof information is obtained by the second data sharing management node corresponding to the data user signing the expression content information of the verifiable expression based on the private key of the data provider. The step of verifying the verifiable credentials by providing the identity file in a decentralized manner includes: If the verifiable credential is the second type of verifiable credential, then the decentralized use identity file of the data user is obtained from the blockchain node, and the public key of the data user is determined from the decentralized use identity file; Based on the public key of the data user and the expression content information, the expression proof information is signed and verified to obtain the verification result for the expression proof information. If the verification result of the expression proof information indicates that the expression proof information has been successfully verified, then the public key of the data provider object is determined from the decentralized identity provision file; Based on the public key of the data provider, the key declaration information, and the target data directory, the key declaration signature information is signed and verified to obtain the verification result for the key declaration signature information. Based on the verification result of the key signature information of the declaration, a second credential verification result is determined for the second type of verifiable credential; the second credential verification result is used to indicate whether the verification of the second type of verifiable credential was successful or failed.

4. The method according to claim 3, characterized in that, The shared data directory includes N directory entries, where N is a positive integer. The key information declaration includes a directory hash array of the N directory entries, and the directory hash array includes the declaration hash value corresponding to each of the N directory entries. The target data directory includes M directory items from the N directory items, where M is a positive integer less than N; the content information includes the M directory items and the data index of the M directory items in the directory hash array; The method involves signing and verifying the key signature information of the declaration based on the public key of the data provider, the key declaration information, and the target data directory, to obtain a verification result for the key signature information of the declaration, including: Obtain the M directory items from the target data directory from the expression content information, and calculate the verification hash value corresponding to each of the M directory items; Based on the data indices corresponding to the M directory items in the directory hash array, the declaration hash values ​​corresponding to the M directory items are found in the directory hash array, and the declaration hash values ​​corresponding to the M directory items in the directory hash array are replaced with the verification hash values ​​corresponding to the M directory items, thus obtaining the verification directory hash array; Replace the directory hash array in the key declaration information with the verification directory hash array to obtain the key verification declaration information; Based on the public key of the data provided object and the key information of the verification statement, the key signature information of the statement is signed and verified to obtain the verification result for the key signature information of the statement.

5. The method according to claim 1, characterized in that, The step of obtaining the verifiable credentials issued by the blockchain node for the data user includes: Receive target task data sent by the blockchain node; the target task data refers to the data of the data sharing task associated with the data provider; the data sharing task is generated by the second data sharing management node corresponding to the data user when it obtains the data sharing request of the data user, based on the verifiable credentials of the data user. Obtain verifiable credentials for the data user from the target task data.

6. The method according to claim 5, characterized in that, The process of receiving the target task data sent by the blockchain node includes: Receive task data sent by the blockchain node, and determine the credential authorization object of the verifiable credential from the verifiable credentials in the task data; If the credential authorization object of the verifiable credential is the data provider object, then the task data is determined as the target task data of the data sharing task associated with the data provider object.

7. The method according to claim 1, characterized in that, The verifiable credential is determined from the target task data issued by the blockchain node. The target task data refers to the data of the data sharing task associated with the data provider. The data sharing task is generated by the second data sharing management node corresponding to the data user when it receives the data sharing request from the data user. The target task data includes task signature information, which is obtained by the second data sharing management node signing the data sharing task based on the private key of the data user. Before obtaining the decentralized provisioning identity file corresponding to the decentralized provisioning identity from the blockchain node based on the decentralized provisioning identity identifier of the data provisioning object in the verifiable credential, the method further includes: Determine the decentralized usage identity of the data user from the verifiable credentials; Based on the decentralized use identity identifier, the decentralized use identity file corresponding to the decentralized use identity identifier is obtained from the blockchain node, and the public key of the data use object is obtained from the decentralized use identity file; the decentralized use identity identifier and the decentralized use identity file are sent from the second data sharing management node to the blockchain node; The task signature information is verified by using the public key of the data provider object. When the task signature information is successfully verified, the step of obtaining the decentralized provisioning identity file corresponding to the decentralized provisioning identity from the blockchain node is performed based on the decentralized provisioning identity identifier of the data provider object in the verifiable credential.

8. A data sharing method based on blockchain, characterized in that, The shared proxy nodes associated with the blockchain node corresponding to the blockchain include a first shared proxy node corresponding to the data provider and a second shared proxy node corresponding to the data user. The method is executed by the blockchain node, and the method includes: A verifiable credential for the data user is issued to the first shared proxy node corresponding to the data provider; the verifiable credential is determined based on a verifiable claim configured by the data provider for the data user; the verifiable claim is used to instruct the data provider to authorize the data user to obtain business data corresponding to the shared data directory; the verifiable credential is used to instruct the data user to selectively obtain business data corresponding to a target data directory in the shared data directory. Upon receiving a request from the first shared proxy node to obtain the identity file of the data provider in the verifiable credential, the first shared proxy node determines the decentralized identity file corresponding to the decentralized identity identifier of the data provider carried in the identity file acquisition request, and returns the decentralized identity file to the first shared proxy node. This allows the first shared proxy node to verify the verifiable credential using the decentralized identity file. If the verification of the verifiable credential is successful, the first shared proxy node retrieves the business data corresponding to the target data directory from the first database corresponding to the data provider and sends the business data corresponding to the target data directory to the second shared proxy node. This allows the second shared proxy node to store the business data corresponding to the target data directory in the second database corresponding to the data user.

9. The method according to claim 8, characterized in that, The method further includes: The system receives a directory usage application transaction sent by the second data sharing management node corresponding to the data user; the directory usage application transaction refers to a transaction in which the data user applies for the right to use business data in the shared data directory; the shared data directory is selected by the data user from the provided data directory; the provided data directory refers to the data directory corresponding to the business data provided by the data provider; the provided data directory is written into the blockchain through a data directory on-chain transaction sent by the first data sharing management node corresponding to the provided data directory; When the directory usage application transaction is written into the blockchain, the directory usage application transaction is sent to the first data sharing management node corresponding to the data provider. This allows the first data sharing management node to write the directory usage application transaction into the control database associated with the first data sharing management node when it determines that the directory usage application transaction is associated with the data provider. Furthermore, when it receives the approval notification for the directory usage application transaction, it generates a verifiable declaration for the data user based on the target data directory, the decentralized usage identity of the data user, and the decentralized usage identity of the data provider. The on-chain transaction corresponding to the verifiable declaration is then sent to the blockchain node. Upon obtaining the on-chain declaration transaction, the on-chain declaration transaction is written into the blockchain, and the verifiable declaration in the on-chain declaration transaction is sent to the second data sharing management node, so that the second data sharing management node can determine the verifiable credential based on the verifiable declaration when requesting to obtain the business data corresponding to the target data directory.

10. The method according to claim 8, characterized in that, The method further includes: The system receives a blockchain-based identity provision transaction sent by the first data sharing management node corresponding to the data provider object, and writes the blockchain-based identity provision transaction into the blockchain. The blockchain-based identity provision transaction is used to indicate the establishment of an identity mapping relationship between the decentralized use identity identifier of the data provider object and the decentralized provision identity file corresponding to the decentralized provision identity identifier. The process of determining the decentralized provisioning identity file corresponding to the decentralized provisioning identity based on the decentralized provisioning identity identifier of the data provisioning object carried in the identity file acquisition request includes: Based on the decentralized identity identifier of the data provider object, query the blockchain for the identity mapping relationship that matches the decentralized identity identifier, and determine the decentralized identity file corresponding to the decentralized identity identifier based on the queried identity mapping relationship.

11. The method according to claim 8, characterized in that, The step of issuing verifiable credentials for the data user to the first shared proxy node corresponding to the data providing object includes: The system receives a shared task on-chain transaction sent by the second data sharing management node corresponding to the data user; the shared task on-chain transaction carries the target task data of the data sharing task created by the data user, and the data sharing task is generated by the second data sharing management node based on the verifiable credentials of the data user when it receives the data sharing request from the data user; When the task transaction is written to the blockchain, the target task data containing the verifiable credentials is sent to the first shared agent node.

12. A blockchain-based data sharing device, characterized in that, The shared proxy nodes associated with the blockchain node corresponding to the blockchain include a first shared proxy node corresponding to the data provider and a second shared proxy node corresponding to the data user. The device operates on the first shared proxy node, and the device includes: The credential acquisition module is used to acquire verifiable credentials issued by the blockchain node for the data user; the verifiable credentials are determined based on the verifiable declaration configured by the data provider for the data user; the verifiable declaration is used to instruct the data provider to authorize the data user to acquire business data corresponding to the shared data directory; the verifiable credentials are used to instruct the data user to selectively acquire business data corresponding to a target data directory in the shared data directory. An identity file acquisition module is provided, which is used to obtain the decentralized identity file corresponding to the decentralized identity identifier from the blockchain node based on the decentralized identity identifier of the data providing object in the verifiable credential; The credential verification module is used to verify the verifiable credential through the decentralized identity file. When the verifiable credential is successfully verified, the module retrieves the business data corresponding to the target data directory from the first database corresponding to the data provider and sends the business data corresponding to the target data directory to the second shared agent node, so that the second shared agent node stores the business data corresponding to the target data directory in the second database corresponding to the data user.

13. A data sharing device based on blockchain, characterized in that, The shared proxy nodes associated with the blockchain node corresponding to the blockchain include a first shared proxy node corresponding to the data provider and a second shared proxy node corresponding to the data user. The device operates on the blockchain node, and the device includes: The credential issuance module is used to issue verifiable credentials for the data user to the first shared proxy node corresponding to the data provider; the verifiable credentials are determined based on the verifiable declaration configured by the data provider for the data user; the verifiable declaration is used to instruct the data provider to authorize the data user to obtain business data corresponding to the shared data directory; the verifiable credentials are used to instruct the data user to selectively obtain business data corresponding to a target data directory in the shared data directory; An identity file distribution module is provided, which, upon receiving a request from the first shared proxy node to obtain an identity file for the data provider object in the verifiable credential, determines the decentralized identity file corresponding to the decentralized identity identifier of the data provider object carried in the identity file acquisition request, and returns the decentralized identity file to the first shared proxy node, so that the first shared proxy node can verify the verifiable credential using the decentralized identity file. If the verification of the verifiable credential is successful, the module retrieves the business data corresponding to the target data directory from the first database corresponding to the data provider object, and sends the business data corresponding to the target data directory to the second shared proxy node, so that the second shared proxy node stores the business data corresponding to the target data directory in the second database corresponding to the data user object.

14. A computer device, characterized in that, Including memory and processor; The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to invoke the computer programs so that the computer device performs the method according to any one of claims 1-11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-11.

Images