WO2025025431A1 - Data management method and apparatus, and system - Google Patents

Abstract

One or more embodiments of the present description provide a data management method and apparatus, and a system. The method is applied to a block chain system in a data management system, the data management system further comprises a data owner and a data acquirer, and a data management contract deployed in the block chain system records an acquisition rule and a use rule of target data belonging to the data owner. The method comprises: in response to receiving data acquisition information which is for target data and submitted by a data acquirer, executing a data management contract to determine whether the data acquisition information satisfies an acquisition rule; determining data use information for the target data, and executing the data management contract to determine whether the data use information satisfies a use rule; if the data acquisition information satisfies the acquisition rule and/or the data use information satisfies the use rule, transmitting to the data acquirer credential information for the target data, the credential information being used to instruct a data owner to assist the data acquirer in acquiring the target data and/or an operation result thereof.

Description

Data management method, device and system Technical Field

One or more embodiments of the present specification relate to the field of blockchain technology, and in particular, to a data management method, device, and system.

Background Art

In the relevant technology, if the data processor needs to use the data held by the data owner, it needs to initiate a request for the data to the data owner so that the relevant personnel of the data owner can verify one by one whether the data processor meets all the authorization conditions of the requested data, and then decide whether to authorize the data to the data processor for its processing and use.

Since this method usually requires manual verification of whether the data processor meets the authorization conditions for the data it requests, on the one hand, the communication and interaction methods are cumbersome and inefficient, which is not conducive to the efficient authorization of the data held by the data owner; on the other hand, it is often difficult for the data owner to disclose the conditions for use of the data and the specific verification process, and there is a possibility of secret operations in the verification process, resulting in low credibility of data authorization.

Summary of the invention

In view of this, one or more embodiments of the present specification provide a data management method, device, and system.

To achieve the above-mentioned purpose, one or more embodiments of the present specification provide the following technical solutions: According to the first aspect of one or more embodiments of the present specification, a data management method is proposed, which is applied to a blockchain system in a data management system, wherein the data management system also includes a data owner and a data acquirer, and the data management contract deployed in the blockchain system records the acquisition rules and usage rules of the target data, and the target data belongs to the data owner. The method includes: in response to receiving data acquisition information for the target data submitted by the data acquirer, executing the data management contract, and the data management contract is used to determine whether the data acquisition information satisfies the acquisition rules; determining data usage information for the target data and executing the data management contract, and the data management contract is used to determine whether the data usage information satisfies the usage rules; when the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules, the credential information for the target data is disclosed to the data acquirer, and the credential information is used to instruct the data owner to assist the data acquirer in obtaining the target data and/or the operation result obtained after performing a preset operation on the target data.

According to a second aspect of one or more embodiments of the present specification, a data management system is proposed, including a blockchain system, a data owner and a data acquirer, wherein the data management contract deployed in the blockchain system records the acquisition rules and usage rules of the target data, and the target data belongs to the data owner, wherein the data acquirer is used to submit data acquisition information for the target data to the blockchain system; the blockchain system is used to execute the data management contract, and the data management contract is used to determine whether the data acquisition information satisfies the acquisition rules; determine data usage information for the target data and execute the data management contract, and the data management contract is used to determine whether the data usage information satisfies the usage rules; and, when the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules, disclose the credential information for the target data to the data acquirer; the data owner is used to assist the data acquirer in obtaining the target data and/or the operation result obtained after performing a preset operation on the target data when receiving the credential information provided by the data acquirer.

According to a third aspect of one or more embodiments of the present specification, a data management device is proposed, which is applied to a blockchain system in a data management system, wherein the data management system also includes a data owner and a data acquirer, and the data management contract deployed in the blockchain system records the acquisition rules and usage rules of the target data, and the target data belongs to the data owner. The device includes: a first execution unit, which is used to execute the data management contract in response to receiving data acquisition information for the target data submitted by the data acquirer, and the data management contract is used to determine whether the data acquisition information satisfies the acquisition rules; a second execution unit, which is used to determine data usage information for the target data and execute the data management contract, and the data management contract is used to determine whether the data usage information satisfies the usage rules; an information transmission unit, which is used to transmit the credential information for the target data to the data acquirer when the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules, and the credential information is used to instruct the data owner to assist the data acquirer in obtaining the target data and/or the operation result obtained after performing a preset operation on the target data.

According to a fourth aspect of one or more embodiments of this specification, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor executes the executable instructions to implement Now the method described in the first aspect.

According to a fifth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

The data management system described in this specification includes a blockchain system, a data owner and a data acquirer, and a data management contract is deployed in the blockchain system, and the acquisition rules and usage rules of the target data belonging to the data owner are recorded in the contract. In response to receiving the data acquisition information for the target data submitted by the data acquirer, the blockchain network executes the data management contract to determine whether the data acquisition information meets the acquisition rules; in addition, the data usage information for the target data is determined and the data management contract is executed to determine whether the data usage information meets the usage rules; and, when the data acquisition information meets the acquisition rules and/or the data usage information meets the usage rules, the credential information for the target data is disclosed to the data acquirer, which is used to instruct the data owner to assist the data acquirer in obtaining the target data and/or the operation result obtained after performing a preset operation on the target data.

It can be seen that this solution records the acquisition rules and usage rules of the target data in the data management contract deployed by the blockchain system, and the contract verifies whether the data acquisition information submitted by the data acquirer meets the acquisition rules, and verifies whether the corresponding data usage information meets the usage rules, and then determines whether to disclose the credential information used to obtain the target data or its calculation results to the data acquirer based on the verification results, that is, the blockchain system and the data management contract deployed on it are used to realize the on-chain automated and refined authorization for the target data. On the one hand, the acquisition rules and usage rules of the target data are recorded in the data management contract deployed on the chain, and the blockchain system completes the authorization for the target data on the chain based on the contract, which significantly reduces the data management burden of the data owner in the data authorization process and helps to improve the efficiency of data authorization. On the other hand, the acquisition rules and usage rules of the target data are recorded in the data management contract for public disclosure, so that all relevant parties in the data authorization process (such as the data acquirer) can flexibly view the above rules; and the verification of whether the data acquisition information meets the acquisition rules and the verification of whether the data usage information meets the usage rules are completed on the chain by the smart contract, so that the verification process and results can be openly and transparently stored on the chain, which helps to avoid the black box operations that may arise from off-chain verification and improves the transparency and credibility of the data authorization process.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of an example environment provided by an exemplary embodiment.

FIG. 2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment.

FIG. 3 is a flow chart of a data management method provided by an exemplary embodiment.

FIG. 4 is a schematic diagram of the structure of a data management system provided by an exemplary embodiment.

FIG. 5 is a schematic structural diagram of a device provided by an exemplary embodiment.

FIG. 6 is a block diagram of a data management device provided by an exemplary embodiment.

DETAILED DESCRIPTION

Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Instead, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may be combined into a single step for description in other embodiments.

FIG. 1 is a schematic diagram of an example environment provided by an exemplary embodiment. As shown in FIG. 1 , the example environment 100 allows entities to participate in a blockchain network 102. The blockchain network 102 may be a public type, a private type, or a consortium type blockchain network. The example environment 100 may include computing devices 104, 106, 108, 110, 112, and a network 114; in one embodiment, the network 114 may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and is connected to a website, a user device (e.g., a computing device), and a backend system. In one embodiment, any computing device may access the network 114 via wired and/or wireless communication.

In some cases, computing devices 106, 108 may be nodes of a cloud computing system (not shown), or each computing device 106, 108 may be a separate cloud computing system including multiple computers interconnected by a network and operating as a distributed processing system.

In one embodiment, computing devices 104-108 may run any appropriate computing system to enable them to serve as nodes in blockchain network 102; for example, computing devices 104-108 may include but are not limited to servers, desktop computers, laptop computers, tablet computing devices, smart phones, and wearable devices. In one embodiment, computing devices 104-108 may belong to related entities and be used to implement corresponding services, such as the service that can be used to manage transactions between a certain entity or multiple entities.

In one embodiment, computing devices 104-108 respectively store blockchain ledgers corresponding to blockchain network 102. Computing device 104 may be (or include) a network server for providing browser functions, which may provide visualization information related to blockchain network 102 based on network 114. In some cases, computing device 104 may not participate in block verification, but monitor blockchain network 102 to determine when other nodes (such as computing devices 106-108) reach consensus, and generate a corresponding blockchain visualization user interface accordingly.

In one embodiment, computing device 104 may receive a request for a blockchain visual user interface initiated by a client device (e.g., computing device 110 or computing device 112). In some cases, a node of blockchain network 102 may also serve as a client device, such as a user of computing device 108 may use a browser running on computing device 108 to send the above request to computing device 104.

In response to the above request, the computing device 104 may generate a blockchain visual user interface (such as a web page) based on the stored blockchain ledger, and send the generated blockchain visual user interface to the requesting client device. If the blockchain network 102 is a private type or a consortium type blockchain network, the request for the blockchain visual user interface may include user authorization information. Before the blockchain visual user interface is generated and sent to the requesting client device, the computing device 104 may verify the user authorization information and return the corresponding blockchain visual user interface after the verification is passed.

The blockchain visualization user interface may be displayed on a client device (e.g., may be displayed in the user interface 116 shown in FIG. 1 ). When the blockchain ledger is updated, the display content of the user interface 116 may also be updated accordingly. In addition, the user's interaction with the user interface 116 may result in a request for other user interfaces, such as displaying a block list, block details, a transaction list, transaction details, an account list, account details, a contract list, contract details, or a search result page generated by a user's search of the blockchain network.

Fig. 2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment. As shown in Fig. 2, the conceptual architecture 200 includes an entity layer 202, a hosting service layer 204, and a blockchain network layer 206. For example, the entity layer 202 may include three entities: entity 1, entity 2, and entity 3, each of which has its own transaction management system 208.

In one embodiment, the hosting service layer 204 may include an interface 210 corresponding to each transaction management system 208. For example, each transaction management system 208 communicates with its respective interface 210 through a network (e.g., network 114 in FIG. 1 ) using a protocol (e.g., Hypertext Transfer Protocol Secure (HTTPS)). In some examples, each interface 210 may provide a communication connection between the respective transaction management system 208 and the blockchain network layer 206; more specifically, the interface 210 may communicate with the blockchain network 212 of the blockchain network layer 206. In some examples, the communication between the interface 210 and the blockchain network layer 206 may be implemented using a remote procedure call (RPC). In some examples, the interface 210 may provide an API interface for accessing the blockchain network 212 to the transaction management system 208.

In one embodiment, the blockchain network 212 is provided in the form of a peer-to-peer network, which includes multiple nodes 214, and these nodes 214 are respectively used to persist the blockchain ledger 216 formed by the block chain data; wherein, only one blockchain ledger 216 is shown in FIG2, but there may be multiple blockchain ledgers 216 or copies thereof in the blockchain network 212, for example, each node 214 may respectively maintain a blockchain ledger 216 or a copy thereof.

It should be pointed out that the transaction described in this specification refers to a piece of data created by a user through a blockchain client and ultimately published to the distributed database of the blockchain. Among them, transactions in the blockchain can be divided into transactions in a narrow sense and transactions in a broad sense. A transaction in a narrow sense refers to a value transfer published by a user to the blockchain; for example, in a traditional Bitcoin blockchain network, a transaction can be a transfer initiated by a user in the blockchain. A transaction in a broad sense refers to a piece of business data with business intent published by a user to the blockchain; for example, an operator can build a consortium chain based on actual business needs, and rely on the consortium chain to deploy some other types of online services that are not related to value transfer (for example, rental business, vehicle dispatch business, insurance claims business, credit services, medical services, etc.), and in this type of consortium chain, a transaction can be a business message or business request with business intent published by a user in the consortium chain.

Blockchain is generally divided into three types: public chain (Public Blockchain), private chain (Private Blockchain) and consortium chain (Consortium Blockchain). In addition, there are many types of combinations, such as private chain + consortium chain, consortium chain + public chain and other different combinations. Among them, the public chain has the highest degree of decentralization. Among them, participants who join the public chain can read data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, each participant (ie, node) can freely join and exit the network and perform related operations. The private chain is the opposite. The write permission of the network is controlled by an organization or institution, and the data reading permission is regulated by the organization. Simply put, a private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain It is more suitable for use within a specific organization. The alliance chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants join the network through authorization and form a stakeholder alliance to jointly maintain the operation of the blockchain.

Whether it is a public chain, a private chain or a consortium chain, it may provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code.

Taking Ethereum as an example, it supports users to create and call some complex logic in the Ethereum network. The core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and each Ethereum node can run EVM. EVM is a Turing-complete virtual machine, which means that various complex logics can be implemented through it. The smart contracts published and called by users in the Ethereum network are run on EVM. Among them, after a blockchain node completes the publication of any smart contract on the Ethereum network, it can be regarded as the contract being deployed in the Ethereum network.

In the field of blockchain, another important concept is account. Taking Ethereum as an example, Ethereum usually divides accounts into two categories: external accounts and contract accounts. External accounts are accounts directly controlled by users, also known as user accounts. Contract accounts are accounts created by users through external accounts and contain contract codes (i.e. smart contracts). Of course, for some blockchain models derived from the Ethereum architecture, the account types supported by the blockchain can be further expanded, which is not specifically limited in this manual.

For accounts in the blockchain, a structure is usually used to maintain the account status. When a transaction in a block is executed, the status of the account related to the transaction in the blockchain will usually change.

In an example, the structure of an account usually includes fields such as Balance, Nonce, Code, and Storage. Among them: the Balance field is used to maintain the current account balance of the account; the Nonce field is used to maintain the number of transactions of the account; it is a counter used to ensure that each transaction can and can only be processed once, effectively avoiding replay attacks;

The Code field, for a contract account, is usually used to maintain the contract code of the account; in actual applications, the Code field usually only maintains the hash value of the contract code; therefore, the Code field is usually also called the Codehash field. For external accounts, the Code field is usually empty.

The Storage field is used to maintain the storage content of the account (the default field value is empty). For a contract account, an independent storage space is usually allocated to store the storage content of the contract account, such as the status data generated by the contract execution. This independent storage space is usually called the account storage of the contract account.

The storage content of the contract account is usually constructed into an MPT (Merkle Patricia Trie) tree data structure and stored in the above independent storage space; among them, the MPT tree constructed based on the storage content of the contract account is usually also called the Storage tree. The Storage field usually only maintains the root node of the Storage tree; therefore, the Storage field is usually also called the StorageRoot field.

In view of the technical problems existing in the aforementioned related technologies, this specification proposes a data management solution. In this solution, a data management contract is deployed and executed in a blockchain system to verify whether the data acquisition information related to the target data meets the acquisition rules of the target data recorded in the contract and whether the data usage information meets the usage rules of the target data recorded in the contract, so as to decide whether to disclose to the data acquirer the credential information used to instruct the data owner to assist the data acquirer in obtaining the data acquirer and/or its calculation results, thereby realizing the on-chain automation and refined authorization of the target data. The technical solution of this specification is described below in conjunction with an embodiment.

FIG3 is a flow chart of a data management method provided by an exemplary embodiment. As shown in FIG3, the method is applied to a blockchain system in a data management system, the data management system also includes a data owner and a data acquirer, and the data management contract deployed in the blockchain system records the acquisition rules and usage rules of the target data, and the target data belongs to the data owner. The method includes steps 302-306.

Step 302: in response to receiving the data acquisition information for the target data submitted by the data acquirer, executing the data management contract, wherein the data management contract is used to determine whether the data acquisition information satisfies the acquisition rule.

In one embodiment, the blockchain system may only include a blockchain network composed of blockchain nodes, or may also include a blockchain network and its associated BaaS (Backend as a Service) platform (composed of computing devices such as a server). There may be one or more copies of managed data belonging to the data owner, wherein, in the case of multiple copies, the multiple copies of managed data may be independent of each other, or there may be any form of association relationship, and this specification does not limit this. In addition, one or more copies of managed data may constitute a data set (i.e., the managed data is managed in the form of a data set), and multiple copies of managed data belonging to the data owner may constitute one or more data sets, which are also regarded as belonging to the data owner. In the case of constituting multiple data sets, the intersection between any two data sets may be an empty set (i.e., the two data sets contain different managed data respectively), or the intersection may also be a true subset of the two data sets (i.e., the two data sets contain part of the same managed data respectively).

In one embodiment, the managed data belonging to the data owner can be maintained by the data owner himself, such as storing the managed data in the local storage space of the data owner or in a storage space such as a database that has a network connection with the data owner. Alternatively, it can also be maintained by a preset trustee (such as one designated by the data owner), such as by the trustee. The custodian stores the managed data in a preset storage space associated with the custodian (such as the local storage space of the custodian, or a database managed by the custodian, etc.). As the manager of the managed data, the data owner or the custodian can perform appropriate read/write processing on the managed data to implement management operations such as adding, deleting, modifying and querying the data.

For all managed data belonging to the data owner, the data owner can authorize at least part of the managed data to other related parties (such as data acquisition parties) for use. This part of the managed data is called authorized data. In this solution, the data owner can record the acquisition rules and usage rules of the authorized data in the data management contract maintained by the blockchain system. Based on this, the related parties (such as data acquisition parties) who want to obtain and use the authorized data can submit data acquisition information corresponding to the acquisition rules to the blockchain system (for the target data in the authorized data) in order to obtain the credential information for this part of the target data revealed by the blockchain system (specifically, the following acquisition credentials, usage credentials or comprehensive credentials), and further use the information to obtain the target data and/or its calculation results from the data owner. It can be seen that the data acquisition party can request to obtain authorization for one or more of the authorized data, and the one or more authorized data requested by the data acquisition party is the target data described in this specification. In other words, the target data described in this specification is one or more authorized data belonging to the data owner requested by the data acquisition party (actually also the managed data belonging to the data owner). In the case where the managed data belonging to the data owner constitutes a data set, if the target data contains only one data, the data belongs to a certain data set; and if the target data contains multiple data, the data may belong to one or more data sets.

It should be pointed out that any of the "managed data", "authorizable data" and "target data" mentioned in this specification should be understood as a broad concept, such as numbers, text, images, audio, video, code, program, model (such as artificial intelligence model), etc. This specification does not limit this.

For the authorizable data belonging to the data owner, the data management contract deployed in the blockchain system can record the acquisition rules and usage rules of these authorizable data; given that the target data is at least part of the authorizable data, the acquisition rules and usage rules of the target data can naturally be recorded in the contract. Because the subsequent blockchain system needs to execute the data management contract to determine whether the relevant information of the target data (i.e., the data acquisition information and data usage information) meets the corresponding rules (i.e., the acquisition rules and usage rules), before the blockchain system executes the data management contract, the data owner can pre-configure the corresponding rules for the target data in the data management contract. Among them, the rule configuration process for the target data is not essentially different from the rule configuration process for any authorizable data. The rule configuration process for any authorizable data is used as an example for explanation below.

When deciding that the managed data belonging to itself can be authorized to other related parties for use (i.e., determining that the data is authorizable data), the data owner can determine the acquisition rules and usage rules corresponding to any authorizable data according to the preset plan, sharing requirements, authorization intention and/or the data type of the target data. Of course, the rules for multiple authorizable data can be determined and configured in batches.

The acquisition rules of any authorizable data may include multiple rules. For example, an algorithm list may be included, and the algorithms recorded in the algorithm list are used to characterize the processing algorithms that the data owner allows the data acquirer to implement on the data - that is, the data acquirer (after obtaining the authorization for any of the authorizable data) is authorized to use the processing algorithm to process the any of the authorizable data. Among them, the processing algorithm may include but is not limited to a hash algorithm, a privacy intersection algorithm, an encryption/decryption algorithm, etc., and any processing algorithm may specifically be an algorithm formula or an algorithm identifier, which will not be repeated. For another example, the acquisition rules may also include a credit score range to ensure that only data acquirers whose credit scores on the preset platform meet the range can be authorized to obtain the data. It can be seen that by setting the credit score range in a higher range, some data acquirers with good credit can be effectively controlled to obtain authorization for any of the authorizable data, so as to ensure that the authorized data can be processed according to the requirements of the data owner as much as possible.

In addition to the above-mentioned algorithm list and credit score range, the acquisition rules may also include geographical ranges (the corresponding data acquisition information may include the geographical location information of the data acquirer), number segments (the corresponding data acquisition information may include the identity number and network address of the data acquirer), etc. The specific content of the acquisition rules may be reasonably set by the data owner according to its own needs for the target data, and this specification does not limit this. Of course, the acquisition rules may include at least one of the above-mentioned multiple rules, such as only one of the algorithm list and the credit score range, or both. Exemplarily, the acquisition rule for any authorizable data Di may be "data Di, privacy intersection and hash calculation, credit score not less than 800 points", indicating that data Di can only be authorized to data acquirers with a credit score not less than 800 points for privacy intersection calculation.

Similarly, the usage rules of any authorized data may also include multiple rules. For example, it may include the validity period of the certificate (the corresponding data usage information may include the current time, the time when the data acquisition information is received, and the time when the acquisition certificate is received), the maximum number of uses (the corresponding data usage information may include the total number of times the blockchain system receives the usage certificate or the data acquisition information submitted by the data acquisition party), the effective frequency range (the corresponding data usage information may include the number of times the blockchain system receives the usage certificate or the data acquisition information The current frequency of the data usage information) etc. For specific information, please refer to the following relevant embodiments for determining whether the data usage information satisfies the usage rules, which will not be described here.

It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

Given that the number of target data that the data acquirer requests to obtain authorization for may be multiple (i.e., the target data may include multiple authorizable data), in order to accurately determine the requested target data and its related rules, the data owner can configure the corresponding relationship between the data identifier of the authorizable data and the related rules in the data management contract to implement the configuration of the data and its related rules. The data owner may also submit the above-mentioned corresponding relationships of multiple authorizable data in batches so that these corresponding relationships can be configured in batches in the same data management contract. There may be an association relationship between the multiple authorizable data, such as data of the same type, data generated in the same manner, data of the same batch generated within a period of time, etc. By deploying the acquisition rules corresponding to these associated (similar) data in the same data management contract, batch management and batch authorization of these data can be implemented, which helps to improve data management and authorization efficiency.

Taking any authorizable data as an example, the correspondence between the data identifier of any authorizable data and its acquisition rules may be called the first correspondence, and the correspondence between the data identifier of any authorizable data and its usage rules may be called the second correspondence. Among them, the data owner may submit the first correspondence and/or the second correspondence to the blockchain network so that the blockchain network can complete the configuration. For example, only one of the above-mentioned first correspondence and second correspondence may be submitted, or both may be submitted at the same time, and this specification does not limit this. The submitted first correspondence includes the data identifier of any authorizable data and the acquisition rules of the data; similarly, the submitted second correspondence includes the data identifier of any authorizable data and the usage rules of the data.

According to the different structures of the blockchain system, the data owner can flexibly adopt the corresponding method to submit the corresponding relationship of any authorized data (i.e., the above-mentioned first corresponding relationship and/or the second corresponding relationship). For example, in the case where the blockchain system only includes the blockchain network, the data owner can (through the client device used by itself) directly initiate a contract deployment transaction containing the above-mentioned corresponding relationship to the blockchain node in the network, so that each node can deploy the data management contract containing the corresponding relationship in the blockchain system by executing the transaction. For another example, in the case where the blockchain system includes the blockchain network and the BaaS platform, the data owner can (through the client device used by itself) initiate a contract deployment request containing the above-mentioned corresponding relationship to the BaaS platform, so that the BaaS platform can respond to the request and initiate a contract deployment transaction containing the corresponding relationship to the blockchain node in the blockchain system, and then each node can deploy the data management contract containing the corresponding relationship in the blockchain system by executing the transaction. It can be seen that in different submission methods, the client device used by the data owner can realize different functions.

Since the blockchain system may have deployed a data management contract when the corresponding relationship is received, the received acquisition rule can be configured in different ways depending on whether the data management contract is deployed.

For example, if the data management contract has not been deployed in the blockchain system, the blockchain system can deploy the data management contract containing the corresponding relationship on the chain. In this way, the configuration of the acquisition rules can be realized while deploying the data management contract, simplifying the contract processing logic. For another example, if the blockchain system has already deployed a data management contract, the blockchain system can configure the received corresponding relationship in the (already deployed) data management contract. Among them, the contract can be pre-deployed by any relevant party (such as the data owner, BaaS platform or other independent third party, etc.), and the pre-deployed contract may not record the corresponding relationship of any data, or the pre-deployed contract may also record the corresponding relationship belonging to any data owner (possibly including the data owner) in advance (before configuring the received corresponding relationship). In this way, the data owner can configure the above-mentioned corresponding relationship of any authorizable data in the pre-deployed data management contract, thereby adding a new corresponding relationship in the contract or updating an existing corresponding relationship, realizing flexible configuration and management of rules.

Among them, when a data management contract has been deployed in the blockchain system, for any data identifier of any authorized data contained in any received corresponding relationship and its corresponding rules (when any corresponding relationship is a first corresponding relationship, the rule is an acquisition rule; when any corresponding relationship is a second corresponding relationship, the rule is a usage rule), any corresponding relationship can be configured in the contract in a corresponding manner according to the record of the data identifier and the rules in the contract.

If the data identifier of any authorizable data and the rules in any corresponding relationship are not recorded in the data management contract, then any corresponding relationship is added to the data management contract; if the data identifier of any authorizable data is already recorded in the data management contract, then the rules in any corresponding relationship are used to update the corresponding rules corresponding to the data identifier in the data management contract; if the rules in any corresponding relationship are already recorded in the data management contract, then the data identifier in any corresponding relationship is added to the identifier set corresponding to the rule in the data management contract.

For example, if the data identifier of any authorizable data and the rules in any corresponding relationship are not recorded in the data management contract, then any corresponding relationship may be added to the data management contract, that is, the rules corresponding to the data identifier of any authorizable data may be added to the contract, thereby adding the entire corresponding relationship. For another example, if the data identifier of any authorizable data has been recorded in the data management contract, the rules in any corresponding relationship may be used to update the corresponding rules corresponding to the data identifier in the data management contract, that is, the corresponding rules (corresponding to any authorizable data) already recorded in the data management contract are updated to the rules in any corresponding relationship, thereby updating the existing rules. For another example, if the rules in any corresponding relationship have been recorded in the data management contract, the data identifier in the corresponding relationship (that is, the data identifier of any authorizable data) may be added to the identifier set corresponding to the rule in the data management contract, thereby adding the data identifier contained in any corresponding relationship to the contract.

Table 1 below is a table of correspondence between data identifiers of authorizable data and their corresponding rules recorded in a data management contract provided by an exemplary embodiment. In the correspondence recorded in Table 1, the first correspondence Relation-g is as follows: Relation-g1 is "Data1, Rule-g1", Relation-g2 is "Data2, Rule-g2", Relation-g3 is "Data3, Rule-g2", Relation-g4 is "Data4, Rule-g3", and Relation-g5 is "Data5, Rule-g4"; the second correspondence Relation-u is as follows: Relation-u1 is "Data1, Rule-u1", Relation-u2 is "Data2, Rule-u1", Relation-u3 is "Data3, Rule-u2", Relation-u4 is "Data4, Rule-u3", and Relation-u5 is empty (may not be set or cleared after setting). It can be seen that the identifier set corresponding to Rule-g2 includes Data2 and Data3, and the identifier set corresponding to Rule-u1 includes Data1 and Data2.

Table 1

For example, if the corresponding relationship between the authorizable data 6 and its acquisition rule does not exist in the current Table 1, then when the first corresponding relationship Relation-g6 submitted by the data owner to the blockchain system is "Data6, Rule-g5", the blockchain system can add Relation-g6 to Table 1. And/or, if the data owner submits Relation-u6 as "Data6, Rule-u5", the blockchain system can also add Relation-u6 to Table 1. Of course, the first corresponding relationship and the second corresponding relationship of the same authorizable data can also be submitted together to reduce the number of submissions. For example, the data owner can submit "Data6, Rule-g5, Rule-u5" so that the blockchain network can configure the above Relation-g6 and Relation-u6 respectively. For another example, for the corresponding relationship Relation-g1 that already exists in Table 1, if the data owner submits Relation1' as "Data1, Rule4", Rule1 corresponding to Data1 in Table 1 can be updated to Rule4. For another example, for the existing acquisition rule Rule2 in Table 1, if the data owner submits Relation6 as "Data6, Rule2", Data6 can be added to the tag set corresponding to Rule2 in Table 1. After the update, the new tag set corresponding to Rule2 includes Data2, Data3 and (newly added) Data6.

It should be noted that the content shown in Table 1 above is only exemplary, and Table 1 can be maintained in the data management contract in any appropriate form, such as in the form of key-value pairs, etc., and this specification does not limit this.

As mentioned above, smart contracts have corresponding contract accounts in the blockchain system. For data management contracts, any of the above correspondences can be recorded in the account storage of its contract account as the state data of the contract, such as stored in the Storage field of the contract account (as the value of the field). In fact, in addition to the aforementioned fields such as Balance, Nonce, Code and Storage, the contract account can also contain other fields, such as custom fields, etc. At this time, any of the above correspondences can also be stored in the custom fields. This specification does not limit the storage location of the corresponding relationship related to the authorized data in the contract account.

So far, the configuration process of the corresponding relationship related to any authorized data has been introduced. As shown in Figure 4, the data management system includes the data owner, the data acquirer and the blockchain system. According to the management contract, the contract records the data identifiers of the authorizable data (including target data) belonging to the data owner, as well as the first corresponding relationships and the second corresponding relationships related to these authorizable data. These corresponding relationships can be configured by the data owner through the aforementioned embodiments.

In addition to the data identifier of the authorizable data and its related corresponding relationship, the data management contract can also record the relevant information of the authorizable data so that the data acquirer with acquisition needs can view it. Among them, the relevant information can include meta information, which includes but is not limited to data name, data size, data type, etc. In addition, the relevant information can also include exemplary data (or typical data, sample data). For example, for multiple data sets consisting of authorizable data, the data management contract can also record the exemplary data of each data set, where the exemplary data of any data set is used to reflect the data characteristics of the authorizable data in the data set (the data characteristics can be the common characteristics of each authorizable data in the data set or at least part of the typical characteristics), so that the data acquirer can understand each authorizable data as fully as possible based on this information, so as to more accurately determine the authorizable data that can meet its own needs as the target data for subsequent requests. For example, the data acquirer can obtain the above-mentioned relevant information through the blockchain client used by itself, and view it in the blockchain visual user interface, so as to select at least part of the authorizable data that meets its own acquisition needs as the target data for the demand request. In addition, you can also obtain and view the acquisition rules of the target data to preliminarily determine whether your own conditions (including data acquisition information) meet the acquisition rules of the authorized data and target data, and submit the data acquisition information to the blockchain system if it is determined to be satisfied, so as to avoid the subsequent execution of the data management contract. The contract determines that the data acquisition information does not meet the acquisition rules and causes authorization failures, which to a certain extent improves the probability of successful authorization and authorization efficiency. Of course, the data acquirer can also not make the above preliminary judgment, but directly submit the data acquisition information for the target data that it needs to obtain after determining it. I will not go into details.

Among them, for the target data that is to be requested (i.e., the data owner wants to obtain authorization), the data acquirer can first determine the corresponding data acquisition information. The data acquisition information of any target data may include: the data identifier of the target data and the information to be verified corresponding to the acquisition rules of the target data, wherein the data identifier is used to indicate to the data management contract: which authorized data is the target data requested by the data acquirer; the information to be verified is used for subsequent judgment on whether the acquisition rules of the target data are met. In other words, the subsequent judgment on whether the data acquisition information meets the acquisition rules is to judge whether the information to be verified in the data acquisition information meets the acquisition rules. The information to be verified may include the aforementioned algorithm list, credit score, geographic location information, identity serial number, network address, etc., which will not be repeated here.

For example, the data acquisition information of any target data Dj may be "data Dj, privacy intersection, credit score is 900 points", which indicates that the data acquirer declares that it needs to acquire the target data Dj for privacy intersection, and the credit score of the data acquirer itself is 900 points. Of course, in the case where the data acquisition rule of data Dj also includes a geographical range and a network address, the data acquisition information may also include "geographical range is X area, network address is yyy", etc., to declare that it is located in X area and its network address is yyy, which will not be repeated.

In one embodiment, the data acquisition information may be included in a data acquisition transaction and submitted to the blockchain system, and the transaction is used to call the data management contract. For example, in the case where the blockchain system only includes a blockchain network, the data acquirer can directly initiate a data acquisition transaction containing data acquisition information to the blockchain node in the network (through its own client device). For another example, in the case where the blockchain system includes a blockchain network and a BaaS platform, the data acquirer can initiate a data acquisition request containing data acquisition information to the BaaS platform (through its own client device), so that the BaaS platform can initiate a data acquisition transaction containing the data acquisition information to the blockchain node in the blockchain system in response to the request. After the above data acquisition transaction passes consensus, the transaction will be synchronized to each blockchain node in the blockchain network and executed separately by each blockchain node.

As mentioned above, the data management contract records the acquisition rules of the target data. Based on this, after receiving the data acquisition information submitted by the data acquirer, the blockchain system can execute the contract to determine whether the data acquisition information meets the acquisition rules. Continuing from the above embodiment, when the data acquisition information is included in the data acquisition transaction that calls the data management contract and submitted to the blockchain system, the blockchain nodes in the blockchain system can use the data acquisition information carried by the transaction as an input parameter to execute the data management contract (the contract code in it) during the execution of the transaction, so that the contract can determine whether the data acquisition information meets the acquisition rules of the target data.

In one embodiment, the acquisition rules may include an algorithm list, and the data acquisition information may include a target algorithm. Among them, any algorithm in the algorithm list may specifically be an identifier such as the name or number of the algorithm, the algorithm rules of the algorithm, the relevant parameters of the algorithm, etc. As mentioned above, the algorithms recorded in the algorithm list are used to characterize the algorithms that the data owner allows the data acquirer to use when processing the target data, and the target algorithm is the algorithm declared by the data acquirer to use when processing the data after obtaining authorization for the target data. Therefore, if the target algorithm in the data acquisition information is recorded in the algorithm list, the data management contract can determine that the data acquisition information satisfies the acquisition rules. Correspondingly, if the target data is obtained using the acquisition credentials revealed by the blockchain system, the data acquirer can process the target data using the target algorithm. For example, the data acquirer can perform hash operations or encryption processing on the acquired target data; and/or, the target algorithm can be used to perform preset operations on the target data (such as privacy intersection operations involving multiple parties including the data owner, etc.), so that the data acquirer can use the acquisition credentials revealed by the blockchain system to obtain the operation results obtained after executing the preset operation.

In another embodiment, the acquisition rule may also include a credit score range, and the data acquisition information may include the credit score of the data acquirer on the preset platform. The credit score may be a specific value, such as 300 points, 500 points, 800 points, etc., and the credit score range may be a numerical range; of course, the credit score may also be a rating level, such as A, B, C, or excellent, good, medium, poor, etc., and the credit score range may be a level set including at least one rating level. It can be understood that the credit score can be used to measure the credit status of the data acquirer on the preset platform. Based on this, if the credit score of the data acquirer on the preset platform belongs to the credit score range, the data management contract can determine that the data acquisition information meets the acquisition rule. It can be seen that by setting the credit score range in a higher interval, the data acquirer with good credit can be effectively controlled to obtain the authorization for any authorizable data, while preventing the data acquirer with poor credit from obtaining the authorization, so as to ensure that the authorized data can be processed according to the requirements of the data owner. Continuing from the above embodiment, when the acquisition rule of the target data Di is "data Di, privacy intersection, credit score not less than 800 points", if the target algorithm in the data acquisition information submitted by the data acquirer is privacy intersection and the credit score of the data acquirer is 900 points, the data management contract can determine that the data acquisition information satisfies the acquisition rule of Di; or, if the target algorithm is not privacy intersection, or the credit score of the data acquirer is less than 800 points, the data management contract will determine that the data acquisition information does not satisfy the acquisition rule of Di.

In addition, the data management contract can call other contracts during the execution process, wherein the data acquisition information submitted by the data acquirer can include the contract address of other contracts, so that the data management contract can call other contracts according to the address. And/or, the data acquisition information can also include the storage address of other data, so that the data management contract can obtain necessary data according to the address during the execution process. For example, in the case where the aforementioned target algorithm is a multi-party operation algorithm, the storage address can be the access address of the aforementioned credit platform, and the data acquisition information can include the credit score of the data acquirer on the preset platform, and can also include the credit scores of one or more other participants (except the data owner and the data acquirer) on the preset platform. In this regard, the data management contract can access the preset platform according to the access address to verify the authenticity of these credit scores, and use the verification (i.e., determining that these credit scores are the real scores of the corresponding parties) as a prerequisite for determining that the data acquisition information meets the acquisition rules, so as to avoid the security risks that may be caused by the data acquirer forging the credit score.

As shown in FIG4 , in the Ethereum scenario, the blockchain node can run EVM, which includes a rule execution engine, such as an acquisition rule execution engine and a usage rule execution engine. In the process of executing the data management contract, the acquisition rule execution engine can be called to determine whether the data acquisition information submitted by the data acquirer meets the acquisition rules of the target data. In addition, the usage rule engine can be called to determine whether the subsequently determined data usage information meets the usage rules of the target data. The judgment process can be referred to in the following embodiment, which will not be repeated here.

Step 304: determine data usage information for the target data and execute the data management contract, wherein the data management contract is used to determine whether the data usage information satisfies the usage rules.

In one embodiment, the data management contract described in this specification may include multiple functions, such as an interface function and its corresponding functional function. Among them, when calling the contract, the blockchain transaction can specify the called interface function (in the contract) and its input parameters, so that in the process of specifying the contract, the functional function corresponding to the interface function processes the input parameters to obtain the corresponding contract execution result. As mentioned above, the data management contract is executed respectively in step 302 and step 304. In the specific implementation, the two steps can respectively call different interface functions of the data management contract, so as to realize different functions by executing the same data management contract: step 302 executes the contract to determine whether the data acquisition information meets the acquisition rules, and step 304 executes the contract to determine whether the data usage information meets the usage rules.

Step 306, when the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules, the credential information for the target data is disclosed to the data acquirer, and the credential information is used to instruct the data owner to assist the data acquirer in obtaining the target data and/or the calculation result obtained after performing a preset calculation on the target data.

The data management system described in this specification includes a blockchain system, a data owner, and a data acquirer. A data management contract is deployed in the blockchain system, and the contract records the acquisition rules and usage rules of the target data belonging to the data owner. In response to receiving the data acquisition information for the target data submitted by the data acquirer, the blockchain network executes the data management contract to determine whether the data acquisition information satisfies the acquisition rules; in addition, it determines the data usage information for the target data and executes the data management contract to determine whether the data usage information satisfies the usage rules; and, in the case where the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules, the data acquirer is informed of the data usage information for the target data. The credential information of the target data is used to instruct the data owner to assist the data acquirer in obtaining the target data and/or the operation result obtained after performing a preset operation on the target data.

It can be seen that this solution records the acquisition rules and usage rules of the target data in the data management contract deployed by the blockchain system, and the contract verifies whether the data acquisition information submitted by the data acquirer meets the acquisition rules, and verifies whether the corresponding data usage information meets the usage rules, and then determines whether to disclose the credential information used to obtain the target data or its calculation results to the data acquirer based on the verification results, that is, the blockchain system and the data management contract deployed on it are used to realize the on-chain automated and refined authorization for the target data. On the one hand, the acquisition rules and usage rules of the target data are recorded in the data management contract deployed on the chain, and the blockchain system completes the authorization for the target data on the chain based on the contract, which significantly reduces the data management burden of the data owner in the data authorization process and helps to improve the efficiency of data authorization. On the other hand, the acquisition rules and usage rules of the target data are recorded in the data management contract for public disclosure, so that all relevant parties in the data authorization process (such as the data acquirer) can flexibly view the above rules; and the verification of whether the data acquisition information meets the acquisition rules and the verification of whether the data usage information meets the usage rules are completed on the chain by the smart contract, so that the verification process and results can be openly and transparently stored on the chain, which helps to avoid the black box operations that may arise from off-chain verification and improves the transparency and credibility of the data authorization process.

Through the above-mentioned method, the data management contract can verify whether the relevant information of the target data meets the corresponding rules. When the data acquisition information meets the acquisition rules and/or the data usage information meets the usage rules, the blockchain network can reveal the credential information for the target data to the data acquirer. On the contrary, when the data acquisition information does not meet the acquisition rules, it can avoid revealing the acquisition credentials and reveal the authorization failure message for the target data to the data acquirer, so as to inform the data acquirer that the request for obtaining authorization for the target data from the data owner has failed.

The blockchain network can reveal the credential information in a variety of ways. For example, the credential information can be written into the data acquisition event recorded in the receipt generated by the data management contract, and the data acquirer has the right to monitor the receipt. For another example, the credential information can also be written into the contract account of the data management contract, and the data acquirer has the right to query the contract account. Among them, the revealed credential can be an acquisition credential, a usage credential, or a comprehensive credential. In view of the fact that each credential can be revealed in the above manner, the following is an explanation using the acquisition credential as an example:

For example, the blockchain network can write the acquisition credentials into the data acquisition event recorded in the receipt generated by the data management contract, such as the data field of the event, and the data acquirer has the monitoring permission for the receipt. In this way, the data acquirer can monitor the acquisition credentials written into the data acquisition event through the event monitoring callback mechanism, and perform subsequent processing according to the monitoring results.

Specifically, the execution result of the data management contract may include a receipt, which may include events related to the method called to execute the contract, such as a data acquisition event corresponding to a rule judgment method (used to determine whether the data acquisition information satisfies the acquisition rules). The topic of the data acquisition event may contain a predefined authorization event identifier to distinguish it from other events. For example, in the event, the content of the topic is the keyword authorization, and this keyword is different from the topic in the event generated by other methods. Then, by monitoring the topics contained in each event in the generated receipt, EVM can determine that it has monitored an event related to the execution of the aforementioned rule judgment method, that is, the data acquisition event, when it monitors a topic containing the keyword authorization. For example, the event in the receipt is as follows:

Then, when the data acquirer listens to the first event, since the content of the topic contained is other, it can be determined that the event is not related to the rule judgment method. When the second event is listened to, since the content of the topic contained is unauthorization, it is determined that the event is related to the rule judgment method, and then the data field corresponding to the event is read. At this time, the data field can be empty, or it can also contain the above-mentioned authorization failure message. Furthermore, when the third event is listened to, the content of the topic is an authorization event, and its data field can be empty, or it can also record the above-mentioned identifier. It can be understood that the above-mentioned second and third events can be generated by the blockchain network respectively after executing the data management contract twice, and the data owners, data acquirers, target data, etc. corresponding to the two executions can be the same or different, and will not be repeated.

For example, the content of the data field of the event in item 3 may include:

The acquisition credential ID can be globally unique in the data management system and is used to uniquely identify the acquisition credential generated this time. The data1 identifier, data2 identifier, and data3 identifier are used to represent the target data requested by the data acquirer this time, namely, data1, data2, and data3. The algorithm list 1, algorithm list 2, and algorithm list 3 are used to represent the algorithms used by the data acquirer when processing data1, data2, and data3.

For another example, the acquisition credential may also be written into the contract account of the data management contract, and the data acquirer may have query rights for the contract account. Among them. The acquisition credential may be specifically written into the Storage field of the contract account corresponding to the data management contract (as the value of the field). Alternatively, in the case where the contract account may also contain a custom field, the acquisition credential may also be written into the custom field. This specification does not limit the storage location of the acquisition credential in the contract account. It can be understood that the acquisition credential written into the above-mentioned field is used as the status data of the contract account corresponding to the data management contract. Based on this, the data acquirer can obtain the acquisition credential by querying the contract account corresponding to the data management contract.

As mentioned above, when the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules, the blockchain network can disclose the credential information for the target data to the data acquirer. For example, when the data acquisition information satisfies the acquisition rules, the disclosed credential information may include the acquisition credential; at the same time, when the data usage information satisfies the usage rules, the disclosed credential information may include the usage credential; specifically, the blockchain network can determine the data usage information for the target data based on the received acquisition credential submitted by the data acquirer; or, it can also determine the data usage information for the target data based on the received data acquisition information and/or the disclosed acquisition credential. For another example, the blockchain network can determine the data usage information for the target data based on the received data acquisition information; accordingly, when the data acquisition information satisfies the acquisition rules and the data usage information satisfies the usage rules, the comprehensive credential can be disclosed to the data acquirer. It can be seen that the disclosed credential information may be the acquisition credential, the usage credential or the comprehensive credential. In this regard, there may be multiple situations in the process of verifying whether the aforementioned information satisfies the corresponding rules and disclosing the corresponding credential information, which are described below.

In one embodiment, when the data management contract determines that the data acquisition information satisfies the acquisition rules, the blockchain network can reveal the acquisition credentials for the target data to the data acquirer, which is used to indicate that the data acquisition information provided by the data acquirer has been verified by the data management contract for the acquisition rules. After receiving the acquisition credentials revealed by the blockchain network, the data acquirer can submit the credentials to the blockchain network in order to obtain the corresponding usage credentials through the credentials (the usage credentials can be used by the data acquirer to request the data owner to use the target data). In the case of receiving the credentials submitted by the data acquirer, the blockchain network can determine the corresponding data usage information based on the credentials, and execute the data management contract again to determine whether the data usage information meets the usage rules of the target data by the contract, and reveal the usage credentials for the target data if it is determined to be satisfied. In this way, the data acquirer needs to first submit the data acquisition information to the blockchain network to obtain the acquisition credentials revealed by it, and then submit the acquisition credentials to it to obtain the usage credentials revealed by it-the usage credentials (or the acquisition credentials and usage credentials) can be used by the data acquirer to provide to the data owner to obtain its assistance.

Among them, the data acquirer can submit the credential immediately after receiving the acquisition credential to obtain the usage credential, or can submit the acquisition credential at some time after receiving the acquisition credential (according to its actual needs) to obtain the usage credential. It can be understood that each submission of the acquisition credential indicates that the data acquirer has the need to re-acquire the target data, and the usage credential can record the validity information of the credential (such as the validity period of the credential, the maximum number of uses, etc.), so as to accurately limit the data acquirer's behavior of using the credential to request the use of the target data, and realize the refined control of the target data authorization process.

For example, in the case where the usage rules include the validity period of the certificate, the data usage information may include the current time (when the data management contract makes a judgment), and/or, may also include the time when the certificate is received (i.e., the time when the blockchain network receives the certificate submitted by the data acquirer). Accordingly, if the current time is within the validity period of the certificate, the data management contract may determine that the data usage information is sufficient. Sufficient usage rules. Among them, the validity period of the credential can be a time interval, or it can also be a deadline. It can be seen that this method essentially sets an "aging" mechanism for the acquisition credential. By reasonably setting the validity period of the credential, flexible control of the "aging" of the acquisition credential can be achieved. For example, the data acquirer can be controlled to obtain the acquisition credential of the target data once and use the credential (obtain the usage credential) indefinitely (through the credential); or the data acquirer can only use the credential arbitrarily within a preset time period (such as one hour, one day, one week, one month, etc.) after obtaining the acquisition credential of any target data. If the time period is exceeded, the acquisition credential will automatically become invalid and cannot be used. Correspondingly, the acquisition credential can record its own credential validity period so that the data owner can judge whether the credential is invalid based on this.

For another example, in the case where the usage rules include the maximum number of uses of the target credential, the data usage information may include the total number of times the blockchain system receives the usage credential and the data acquisition information submitted by the data acquirer, wherein the total number of times the acquisition credential is received is the first total number, and the total number of times the data acquisition information initiated by the data acquirer for the target data (the specific content may be the same or different from the aforementioned data acquisition information) is received is the second total number. Accordingly, if the first total number or the second total number is less than the maximum number of uses, the data management contract may determine that the data usage information satisfies the usage rules. Among them, the maximum number of uses may be included in the aforementioned acquisition credential, and the total number may be obtained by the data management contract or the blockchain network querying the execution record of the contract. It can be seen that the first total number of times is essentially a "number of uses limit" mechanism set for the acquisition credential. By reasonably setting the maximum number of uses, flexible control of the "number of times the acquisition credential can be used" can be achieved, such as controlling the data acquirer to obtain the acquisition credential of the target data once and then use the credential (through the credential) as many times as desired; or controlling the data acquirer to obtain the acquisition credential of the target data once, so that the credential can only be used within the maximum number of uses. When the maximum number of uses is reached, the acquisition credential automatically becomes invalid and cannot be used again. The second total number of times is actually a "number of authorizations limit" mechanism set for the target data by the data acquirer, so that the number of times the data acquirer obtains the use credential does not exceed the maximum number of uses, thereby achieving a precise limit on the number of times the acquisition credential is exposed.

For another example, when the usage rules include a valid frequency range, the data usage information may include the current frequency of the blockchain system receiving the usage voucher or the data acquisition information; wherein, the frequency of receiving the acquisition voucher is the first current frequency, and the frequency of receiving the data acquisition information initiated by the data acquirer for the target data (the specific content may be the same or different from the aforementioned data acquisition information) is the second current frequency. Correspondingly, if the current frequency is within the valid frequency range, the data management contract can determine that the data usage information meets the usage rules. It can be seen that through the above-mentioned first current frequency, a "usage frequency limit" mechanism set for the acquisition voucher is set, which can realize flexible control of the "usage frequency" of the acquisition voucher; and through the above-mentioned second frequency, an "authorized frequency limit" mechanism for the target data is set, so that the frequency of the data acquirer obtaining the usage voucher does not exceed the valid frequency range, realizing accurate restrictions on the frequency of the acquisition voucher exposure, and avoiding the data acquirer from obtaining the usage voucher or using the target data too frequently.

In another embodiment, when the data management contract determines that the data acquisition information satisfies the acquisition rules, the blockchain network can reveal the acquisition credentials for the target data to the data acquirer, and the credentials are used to indicate that the data acquisition information provided by the data acquirer has passed the verification of the acquisition rules by the data management contract. In addition, the blockchain network can determine the data usage information based on the data acquisition information after receiving the data acquisition information, and/or determine the data usage information based on the credentials when the acquisition credentials are revealed, and in the process of executing the data management contract, the contract determines whether the data usage information satisfies the usage rules, and then reveals the usage credentials for the target data when it is judged to be satisfied. It can be seen that the blockchain network can determine the data usage information for the target data based on the received data acquisition information and/or the revealed acquisition credentials. The data acquirer only needs to submit the data acquisition information once (such as issuing a data acquisition transaction) to obtain the acquisition credentials and usage credentials revealed by the blockchain network.

In another embodiment, the blockchain network can determine the corresponding data usage information after receiving the data acquisition information submitted by the data acquirer. Thereafter, the data management contract can be executed to determine whether the data acquisition information satisfies the acquisition rules and whether the data usage information satisfies the usage rules. If both are satisfied, the comprehensive certificate is revealed. Among them, a part of the data usage information can also be determined according to the data acquisition information, and the content of the acquisition certificate is determined when the data acquisition information satisfies the acquisition rules (without generating the acquisition certificate), and then the other part of the data usage information is determined according to the content, and then the data management contract determines whether the above two parts of the data usage information meet the usage rules, and when it is determined that they meet, the comprehensive certificate is revealed, and the certificate can contain the content of the aforementioned (not actually generated) acquisition certificate. It can be seen that the blockchain network can determine the data usage information for the target data according to the received data acquisition information and/or the revealed acquisition certificate. The data acquirer only needs to submit the data acquisition information once (such as issuing a data acquisition transaction) to obtain the comprehensive certificate revealed by the blockchain network.

For example, when the data acquirer is U1, the usage rule of any target data Di can be {Di, U1, privacy intersection, expired = 600s, limit = 2, frequency = 120s/time, ...}. Among them, "expired = 600s" It indicates that the validity period of the certificate is 600s (i.e. 10 minutes), "limit=2" indicates that the maximum number of times the certificate can be used is 2 times, and "frequency=200s/time" indicates that the interval between two consecutive submissions of the certificate should be no less than 120s, that is, the target data Di can be requested to be used once every 2 minutes at the fastest.

In addition, the blockchain system can use a key (a symmetric key pre-negotiated by the data owner and the data acquirer, or the public key of the data acquirer, etc.) to encrypt the credential information and transmit the encrypted credential information to the data acquirer; accordingly, the data acquirer holding the key required for decryption (the symmetric key, or the private key of the data acquirer, etc.) can read and decrypt the encrypted credential information to obtain the plaintext credential information, while unrelated users cannot decrypt the encrypted credential information, thereby ensuring that the data acquirer obtains the credential information and preventing the credential information from being obtained by unrelated personnel when it is recorded in plaintext on the chain, that is, preventing the leakage of credential information and protecting the rights and interests of the data owner.

After obtaining the credential information transmitted by the blockchain network, the data acquirer can provide the information to the data owner; accordingly, the data owner can assist the data acquirer in obtaining the target data and/or the calculation results obtained after performing preset calculations on the target data in accordance with the instructions of the information.

In one embodiment, the data acquirer may initiate a data acquisition request including the credential information to the data owner, and the data owner may determine the corresponding target data in response to the request and return the data directly to the data acquirer for use. Alternatively, the data owner may perform a preset operation on the target data in response to the request and return the corresponding operation result to the data acquirer. Obviously, compared with directly providing the target data to the data acquirer, the data owner performs a preset operation on the target data and provides the corresponding operation result to the data acquirer. When the target data obtains the corresponding operation result through the above-mentioned preset operation, if the data acquirer cannot infer the value of the target data from the operation result, the disclosure of the target data can be limited while meeting the data acquisition needs of the data acquirer, so as to avoid the data acquirer from directly obtaining the target data itself, prevent the data acquirer from leaking the target data and infringing the rights and interests of the data owner, ensure that the target data is always held only by the data owner, and improve the security of the target data.

The preset operation performed on the target data should meet the data acquisition party's operation requirements for the target data. In one embodiment, the preset operation may include a multi-party operation jointly participated by the data owner and the data acquisition party. In this case, the server-side data acquisition party can only obtain the operation results of the multi-party operation, but cannot obtain the target data itself, which not only improves the data security of the target data itself, but also helps to reduce the data acquisition party's use burden on the target data and improve the use efficiency.

Among them, the operation rules of the preset operation can be predefined in the data management contract, such as as part of the algorithm list in the aforementioned acquisition rules; or it can also be submitted to the blockchain system together with the aforementioned data acquisition information (by the data acquirer) and transmitted to the data management contract, such as the operation rules and the data acquisition information can be included in the aforementioned data acquisition transaction to initiate to the blockchain system; or it can also be provided to the data owner together with the credential information (by the data acquirer), such as the operation rules and the credential information can be included in the aforementioned data acquisition request to initiate to the data owner, which will not be repeated. The data acquirer can flexibly select the above method to specify the operation rules for the target data to the data owner according to the actual situation, so as to instruct the data owner which algorithm to use to process the target data.

In addition, there may be different privacy levels between the various authorizable data held by the data owner; accordingly, data of different privacy levels may have differentiated processing methods. For example, the data owner may hold authorizable data with a relatively low privacy level and authorizable data with a relatively high privacy level, that is, authorizable data with a low privacy level and authorizable data with a high privacy level. Accordingly, when the target data belongs to a low privacy level, the target data can be provided to the data acquisition party, that is, the data owner does not care whether the data with a low privacy level will be leaked; and when the target data belongs to a high privacy level, the target data needs to be subjected to a preset operation so that the corresponding operation result is provided to the data acquisition party to ensure that the data with a high privacy level will not be leaked. If the target data contains authorizable data with a low privacy level and a high privacy level at the same time, the target data with a low privacy level can be directly provided to the data acquisition party, and the target data with a high privacy level can be provided to the data acquisition party after the operation result after the preset operation; or, especially when the data acquisition party has specified the operation rules of the preset operation to be adopted in the aforementioned data acquisition transaction or data acquisition request, all target data can be subjected to the preset operation together, and the operation result can be provided to the data acquisition party.

In the case of receiving the credential information provided by the data acquirer, in order to avoid the data authorization and value loss caused by the possible fraudulent behavior of the data acquirer such as tampering with the credentials, the data owner can also verify the authenticity of the credential information it receives. For example, the credential information or data acquisition request carries the relevant information of the aforementioned data acquisition transaction (such as the transaction hash and the block height of the transaction block, etc.) or the relevant information of the data management contract. In the case of relevant information (such as contract address, etc.), the data owner can request the blockchain system to query the corresponding credential information according to the above relevant information, and further determine whether the credential information received by itself (submitted by the data acquirer) is consistent with the credential information queried: if the two are consistent, it means that the received credential information has not been tampered with, indicating that the data acquirer provides the real credential information it received; conversely, if the two are inconsistent, it means that the data acquirer does not provide the real credential information it received. Among them, the above query process can be implemented through SPV (Simplified Payment Verification) technology; or, the data owner can also obtain the complete block from the blockchain system according to the above block height, and query the corresponding credential information generated by executing the data management contract from it, which will not be repeated.

For another example, the authenticity of the credential information provided by the data acquirer can also be verified by means of signature verification. For example, when the blockchain system transmits the credential information for the target data to the data acquirer, it can also transmit the signature made on the credential information by the public key of the data owner; accordingly, after receiving the credential information and its signature provided by the data acquirer, the data acquirer can use its own private key to verify the signature, and if the verification is passed, then assist the data acquirer in obtaining the target data and/or the calculation result obtained after performing the preset calculation on the target data. In other words, the target data and/or the calculation result obtained after performing the preset calculation on the target data can be assisted by the data owner to obtain the target data when the signature verification is passed, that is, the data owner can use the verification of the credential information as a prerequisite for assisting the data acquirer, so as to effectively avoid assisting the data acquirer in obtaining the target data and/or the calculation result when the data acquirer provides false credential information, thereby improving the accuracy and reliability of the authorization of the target data.

It is understandable that the credential information disclosed in the above manner can be used to prove that the data acquirer meets the conditions for acquiring the target data, and after obtaining the credential information, the data acquirer can use the credential to acquire the target data and/or calculation results. In this regard, further restrictions can be placed on the specific process of the data owner assisting the data acquirer in acquiring the target data and/or calculation results through the target data usage rules.

In addition, when assisting the data acquirer to obtain the target data, if the target data is stored locally on the data owner, the data can be directly returned to the data acquirer; or, if the target data is maintained by a preset trustee, the trustee can be instructed to return the data to the data acquirer. When assisting the data acquirer to obtain the calculation result obtained after performing a preset calculation on the target data, if the target data is stored locally, the data owner can use the target data to participate in the preset calculation and return the calculation result to the data acquirer; or a trusted related party can be called to use the target data to participate in the preset calculation, and the related party will return the calculation result directly to the data acquirer, or the related party will feed back the calculation result to the data owner, and the data owner will return it to the data acquirer, so as to avoid revealing the related parties directly involved in the preset calculation to the data acquirer. Similarly, if the target data is maintained by a preset trustee, the target data can be obtained from the trustee and a preset operation can be performed, and the operation result can be returned to the data acquirer; the trustee can also be instructed to use the target data to participate in the preset operation, and the trustee returns the operation result directly to the data acquirer, or the trustee feeds back the operation result to the data owner, and the data owner returns it to the data acquirer, so as to avoid revealing the trustee who directly maintains the target data to the data acquirer. The above-mentioned multiple assistance methods can be flexibly selected according to actual needs, and this specification does not limit this.

Furthermore, after obtaining the target data through the credential information, the data acquirer can directly process the data itself; and after obtaining the operation result obtained by performing a preset operation on the target data, the data acquirer can further process the operation result. As for the way in which the data acquirer processes the obtained target data or the operation result, this specification does not limit it.

At this point, the introduction to the aforementioned data management solution is complete, and the main steps of the data management method are briefly and intuitively introduced below in conjunction with Figure 4. As shown in Figure 4, the data management method includes steps 402-410.

In step 402, the data owner configures relevant rules for authorizable data including target data in the data management contract deployed in the blockchain system.

The data owner can configure the relevant rules in the process of deploying the data management contract, or can add or update the acquisition rules in the pre-deployed data management contract. For any authorizable data, the configured relevant rules include acquisition rules and/or usage rules.

Step 404: The data acquisition direction submits information to the blockchain system.

Step 406: The blockchain network reveals the credential information to the data acquirer.

There are multiple implementations of steps 404-406, which are described below.

Implementation A: Step 404a-1, the data acquisition direction submits data acquisition for the target data to the blockchain system information.

For example, the data acquirer can first obtain and view the acquisition rules from the chain, and when it preliminarily determines that its own conditions (i.e., the data acquisition information it can provide) meet the rules, submit the data acquisition information corresponding to the rules to the blockchain system to improve the authorization probability and processing efficiency.

Among them, the data acquirer can directly or indirectly (by initiating a data acquisition request) initiate a data acquisition transaction containing data acquisition information to the blockchain system. During the execution of the transaction, the blockchain system further executes the data management contract called by the transaction, so that the contract can determine whether the data acquisition information submitted by the data acquirer meets the acquisition rules recorded in the contract.

Step 406a-1, the blockchain network transmits the acquisition certificate to the data acquirer.

When the data management contract determines that the data acquisition information meets the acquisition rules, the blockchain network will provide the data acquirer with the acquisition credentials.

Step 404a-2: The data acquirer submits the acquisition certificate to the blockchain system.

After receiving the acquisition certificate, the data acquirer can submit the certificate at an appropriate time. The submission method is similar to the above data acquisition information submission method and will not be repeated here. After receiving the acquisition certificate, the blockchain network can determine the corresponding data usage information and execute the data management contract to determine whether the information meets the usage rules.

Step 406a-2, the blockchain network transmits the usage certificate to the data acquirer.

When the data management contract determines that the data usage information meets the usage rules, the blockchain network will provide the data acquirer with the usage certificate.

Implementation method B: Step 404b, the data acquisition direction submits data acquisition information for the target data to the blockchain system.

After receiving the data acquisition information, the blockchain network can determine the corresponding data usage information based on the information.

Step 406b-1, the blockchain network transmits the acquisition certificate to the data acquirer.

When the data management contract determines that the data acquisition information meets the acquisition rules, the blockchain network will provide the data acquirer with the acquisition certificate. In addition, the blockchain network can also determine the corresponding data usage information based on the certificate after generating or providing the acquisition certificate.

Step 406b-2: The blockchain network transmits the usage certificate to the data acquirer.

The data management contract is executed based on the determined data usage information. The contract determines whether the information meets the usage rules and, if so, reveals the usage credentials.

Among them, the above steps 406b-1 and 406b-2 can also be combined into one step 406b, that is, the blockchain network transmits the acquisition certificate and the usage certificate to the data acquirer together to reduce the number of interactions between the two.

Implementation method C: Step 404c, the data acquisition direction submits data acquisition information for the target data to the blockchain system.

After receiving the data acquisition information, the blockchain network can determine the corresponding data usage information based on the information, such as the current receiving frequency, the current total number of times, the receiving time, etc.

In step 406c, the blockchain network transmits the acquisition certificate to the data acquirer.

When the data management contract determines that the data acquisition information meets the acquisition rules, the content (which should be included) of the acquisition certificate is determined (but the certificate is not generated or disclosed), such as the data identifier of the target data, the identifier of the data acquirer, the algorithm list declared by the data acquirer, the validity period of the certificate, etc. In addition, after determining the above content of the acquisition certificate, the blockchain network can also determine the corresponding data usage information based on the certificate, such as the above content of the acquisition certificate.

The data management contract is executed based on the determined data usage information. The contract determines whether the information meets the usage rules and, if so, reveals the comprehensive certificate, which includes the above-mentioned content of the acquisition certificate (not actually generated).

In step 408, the data acquirer provides the received credential information to the data owner (eg, initiates a data acquisition request including the acquisition credential to the data owner) to request the data owner to use the target data.

Step 410: The data owner assists the data acquirer in obtaining the target data and/or performs a preset operation on the target data. The result of the calculation.

The data owner can verify the authenticity of the acquisition credentials and whether they meet the usage rules at the same time, and assist the data acquirer in obtaining the target data and/or operation results after the verification is passed. Of course, if the verification fails, the data acquirer should avoid assisting the data acquirer in obtaining the target data and/or operation results. In addition, a failure reminder message can be returned to the data acquirer to promptly inform the data acquirer of the failure to obtain the target data and/or operation results.

Corresponding to the aforementioned embodiment, the present specification also proposes a data management system, which includes a blockchain system, a data owner and a data acquirer, wherein the data management contract deployed in the blockchain system records the acquisition rules and usage rules of the target data, and the target data belongs to the data owner, wherein the data acquirer is used to submit data acquisition information for the target data to the blockchain system; the blockchain system is used to execute the data management contract, and the data management contract is used to determine whether the data acquisition information satisfies the acquisition rules; determine data usage information for the target data and execute the data management contract, and the data management contract is used to determine whether the data usage information satisfies the usage rules; and, when the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules, the credential information for the target data is disclosed to the data acquirer; the data owner is used to assist the data acquirer in obtaining the target data and/or the operation result obtained after performing a preset operation on the target data when receiving the credential information provided by the data acquirer.

FIG5 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG5. At the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, a memory 508, and a non-volatile memory 510, and may also include hardware required for other functions. One or more embodiments of this specification may be implemented based on software, such as the processor 502 reading the corresponding computer program from the non-volatile memory 510 into the memory 508 and then running it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or logic devices.

As shown in FIG. 6 , FIG. 6 is a block diagram of a data management device provided in this specification according to an exemplary embodiment. The device can be applied to the device shown in FIG. 5 to implement the technical solution of this specification.

The data management device is applied to a blockchain system in a data management system, the data management system also includes a data owner and a data acquirer, the data management contract deployed in the blockchain system records the acquisition rules and usage rules of the target data, the target data belongs to the data owner, and the device includes: a first execution unit 601, which is used to execute the data management contract in response to receiving data acquisition information for the target data submitted by the data acquirer, and the data management contract is used to determine whether the data acquisition information meets the acquisition rules; a second execution unit 602, which is used to determine the data usage information for the target data and execute the data management contract, and the data management contract is used to determine whether the data usage information meets the usage rules; a credential transmission unit 603, which is used to transmit the credential information for the target data to the data acquirer when the data acquisition information meets the acquisition rules and/or the data usage information meets the usage rules, and the credential information is used to instruct the data owner to assist the data acquirer in obtaining the target data and/or the operation result obtained after performing a preset operation on the target data.

Optionally, when the data acquisition information satisfies the acquisition rules, the transmitted credential information includes the acquisition credentials; the second execution unit 602 is specifically used to: determine the data usage information for the target data based on the received acquisition credentials submitted by the data acquirer; or, determine the data usage information for the target data based on the received data acquisition information and/or the transmitted acquisition credentials; wherein, when the data usage information satisfies the usage rules, the transmitted credential information includes the usage credentials.

Optionally, the second execution unit 602 is specifically used to: determine data usage information for the target data based on the received data acquisition information; the credential transmission unit 603 is specifically used to: transmit a comprehensive credential to the data acquisition party when the data acquisition information satisfies the acquisition rules and the data usage information satisfies the usage rules.

Optionally, the data usage information satisfies the usage rules, including at least one of the following: when the usage rules include the validity period of the credential, the data usage information includes the current time, the time of receiving the data acquisition information, and the time of receiving the acquisition credential, the current time, the time of receiving the data acquisition information, and the time of receiving the acquisition credential are within the validity period of the credential; when the usage rules include the maximum number of uses of the target credential, and the data usage information includes the total number of times the blockchain system receives the usage credential or the data acquisition information submitted by the data acquirer, the total number of times is less than the maximum number of uses; when the usage rules include the effective frequency range, and the data usage information includes the number of times the blockchain system receives the usage credential Or in the case of the current frequency of the data acquisition information, the current frequency is within the valid frequency range.

Optionally, the acquisition rules include an algorithm list, and the data acquisition information satisfies the acquisition rules, including: the target algorithm in the data acquisition information is recorded in the algorithm list, wherein the data acquisition party is used to obtain the target data through processing by the target algorithm, and/or the target algorithm is used to perform the preset operation.

Optionally, the preset operation includes a multi-party operation in which the data owner and the data acquirer jointly participate.

Optionally, the acquisition rule includes a credit score range, the data acquisition information includes the credit score of the data acquirer on a preset platform, and the data acquisition information satisfies the acquisition rule, including: the credit score of the data acquirer on the preset platform falls within the credit score range.

Optionally, the credential transmission unit 603 is specifically used to: write the credential information into the data acquisition event recorded by the receipt generated by the data management contract, and the data acquisition party has the right to monitor the receipt; or, write the credential information into the contract account of the data management contract, and the data acquisition party has the right to query the contract account.

Optionally, the credential disclosure unit 603 is specifically used to: disclose the credential information for the target data and the signature of the credential information made with the public key of the data owner to the data acquisition party, and the target data and/or the operation result obtained after performing a preset operation on the target data are obtained by the data owner with the assistance of the data acquisition party when the signature is verified.

Optionally, there is authorizable data belonging to the data owner, and the target data includes at least part of the authorizable data. The device also includes: a credential submission unit 604, which is used by the data owner to submit to the blockchain system a first correspondence between the data identifier of any authorizable data and its acquisition rule, and/or submit a second correspondence between the data identifier of any authorizable data and its usage rule; and a contract deployment unit 605, which is used by the blockchain system to deploy the data management contract containing the first correspondence and/or the second correspondence; or, a relationship configuration unit 606, which is used by the blockchain system to configure the first correspondence and/or the second correspondence in the data management contract when the data management contract has been deployed in the blockchain system.

Optionally, the relationship configuration unit 606 is specifically used for one of the following: if the data identifier of any authorizable data and the rules in any corresponding relationship are not recorded in the data management contract, then any corresponding relationship is added to the data management contract; if the data identifier of any authorizable data is already recorded in the data management contract, then the rules in any corresponding relationship are used to update the corresponding rules corresponding to the data identifier in the data management contract; if the rules in any corresponding relationship are already recorded in the data management contract, then the data identifier in any corresponding relationship is added to the identifier set corresponding to the rule in the data management contract.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined in this article, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive The term "comprising a set of elements" refers to the inclusion of a set of elements, such that a process, method, commodity, or device including a set of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity, or device. In the absence of further restrictions, an element defined by the phrase "comprising a ..." does not exclude the existence of other identical elements in the process, method, commodity, or device including the element.

The above is a description of a specific embodiment of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and/or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

The above description is merely a preferred embodiment of one or more embodiments of the present specification and is not intended to limit one or more embodiments of the present specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of the present specification shall be included in the scope of protection of one or more embodiments of the present specification.

Claims (15)

A data management method is applied to a blockchain system in a data management system, wherein the data management system also includes a data owner and a data acquirer, and the data management contract deployed in the blockchain system records acquisition rules and usage rules of target data, and the target data belongs to the data owner. The method includes: In response to receiving data acquisition information for the target data submitted by the data acquirer, executing the data management contract, wherein the data management contract is used to determine whether the data acquisition information satisfies the acquisition rule; Determine data usage information for the target data and execute the data management contract, wherein the data management contract is used to determine whether the data usage information satisfies the usage rules; In the case where the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules, the credential information for the target data is disclosed to the data acquirer, and the credential information is used to instruct the data owner to assist the data acquirer in obtaining the target data and/or the calculation result obtained after performing a preset calculation on the target data. According to the method of claim 1, when the data acquisition information satisfies the acquisition rule, the credential information transmitted includes an acquisition credential; and the determining of data usage information for the target data includes: Determine data usage information for the target data according to the acquisition credential submitted by the data acquirer; or, Determine data usage information for the target data according to the received data acquisition information and/or the disclosed acquisition credential; Wherein, when the data usage information satisfies the usage rules, the disclosed credential information includes a usage credential. The method according to claim 1, The determining of the data usage information for the target data includes: determining the data usage information for the target data according to the received data acquisition information; The step of transmitting credential information for the target data to the data acquirer when the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules comprises: transmitting comprehensive credentials to the data acquirer when the data acquisition information satisfies the acquisition rules and the data usage information satisfies the usage rules. According to the method of claim 2 or 3, the data usage information satisfies the usage rules, including at least one of the following: In the case where the usage rule includes a validity period of the credential, and the data usage information includes a current time, a receiving time of the data acquisition information, and a receiving time of the acquired credential, the current time, the receiving time of the data acquisition information, and the receiving time of the acquired credential are within the validity period of the credential; In the case where the usage rule includes the maximum number of uses of the target credential, and the data usage information includes the total number of times the blockchain system receives the usage credential or the data acquisition information submitted by the data acquirer, the total number of times is less than the maximum number of uses; In a case where the usage rules include a valid frequency range and the data usage information includes a current frequency at which the blockchain system receives the usage credential or the data acquisition information, the current frequency is within the valid frequency range. According to the method of claim 1, the acquisition rule includes an algorithm list, and the data acquisition information satisfies the acquisition rule, including: The target algorithm in the data acquisition information is recorded in the algorithm list, wherein the data acquisition party is used to obtain the target data through processing by the target algorithm, and/or the target algorithm is used to perform the preset operation. According to the method of claim 1, the preset operation includes a multi-party operation jointly participated by the data owner and the data acquirer. According to the method of claim 1, the acquisition rule includes a credit score range, the data acquisition information includes the credit score of the data acquirer on a preset platform, and the data acquisition information satisfies the acquisition rule, including: The credit score of the data acquirer on the preset platform falls within the credit score range. According to the method of claim 1, the blockchain system discloses credential information for the target data to the data acquirer, including: Writing the credential information into the data acquisition event recorded in the receipt generated by the data management contract, and the data acquisition party has the monitoring authority for the receipt; or The credential information is written into the contract account of the data management contract, and the data acquirer has query authority for the contract account. According to the method of claim 1, the blockchain system discloses credential information for the target data to the data acquirer, including: The credential information of the target data and the signature of the credential information made by the public key of the data owner are disclosed to the data acquisition party, and the target data and/or the operation result obtained after performing a preset operation on the target data are obtained by the data owner with the assistance of the data acquisition party when the signature is verified. According to the method of claim 1, there is authenticatable data belonging to the data owner, the target data includes at least part of the authenticatable data, and the method further comprises: The data owner submits to the blockchain system a first correspondence between the data identifier of any authorizable data and its acquisition rules, and/or submits a second correspondence between the data identifier of any authorizable data and its usage rules; and The blockchain system deploys the data management contract including the first corresponding relationship and/or the second corresponding relationship; or, In a case where the data management contract has been deployed in the blockchain system, the blockchain system configures the first corresponding relationship and/or the second corresponding relationship in the data management contract. According to the method of claim 10, the blockchain system configures any one of the first correspondence and the second correspondence in the data management contract, including one of the following: If the data identifier of any authorizable data and the rule in any corresponding relationship are not recorded in the data management contract, then any corresponding relationship is added to the data management contract; If the data identifier of any authorizable data has been recorded in the data management contract, then the corresponding rule corresponding to the data identifier in the data management contract is updated using the rule in any corresponding relationship; If the data management contract has recorded a rule in any of the corresponding relationships, the data identifier in any of the corresponding relationships is added to the identifier set corresponding to the rule in the data management contract. A data management system includes a blockchain system, a data owner and a data acquirer. The data management contract deployed in the blockchain system records the acquisition rules and usage rules of target data. The target data belongs to the data owner. The data acquisition party is used to submit data acquisition information for the target data to the blockchain system; The blockchain system is used to execute the data management contract, the data management contract is used to determine whether the data acquisition information satisfies the acquisition rules; determine data usage information for the target data and execute the data management contract, the data management contract is used to determine whether the data usage information satisfies the usage rules; and, when the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules, disclose the credential information for the target data to the data acquirer; The data owner is used to assist the data acquirer in obtaining the target data and/or the operation result obtained after performing a preset operation on the target data, upon receiving the credential information provided by the data acquirer. A data management device is applied to a blockchain system in a data management system, wherein the data management system also includes a data owner and a data acquirer, and the data management contract deployed in the blockchain system records acquisition rules and usage rules of target data, and the target data belongs to the data owner. The device includes: A first execution unit, configured to execute the data management contract in response to receiving data acquisition information for the target data submitted by the data acquirer, wherein the data management contract is configured to determine whether the data acquisition information satisfies the acquisition rule; a second execution unit, configured to determine data usage information for the target data and execute the data management contract, wherein the data management contract is configured to determine whether the data usage information satisfies the usage rules; An information disclosure unit is used to disclose credential information for the target data to the data acquirer when the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules, wherein the credential information is used to instruct the data owner to assist the data acquirer in obtaining the target data and/or the calculation result obtained after performing a preset calculation on the target data. An electronic device, comprising: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 1 to 11 by running the executable instructions. A computer-readable storage medium stores computer instructions, which, when executed by a processor, implement the method according to any one of claims 1 to 11.