Data management method and apparatus, and system

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

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and more particularly, to a data management method, device, and system. Background Art

[0002] In related technologies, if a 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 for the requested data, and then decide whether to authorize the data to the data processor for its processing and use.

[0003] 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 data usage conditions and the specific verification process. The verification process may be operated in secret, resulting in low credibility of data authorization.

[0004] Summary of the Invention

[0005] In view of this, one or more embodiments of this specification provide a data management method, device, and system.

[0006] To achieve the above-mentioned objectives, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this 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, wherein 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, wherein 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, revealing credential information for the target data to the data acquirer, wherein the credential information is used to instruct the data owner to assist the data acquirer in obtaining the target data and / or performing a preset operation on the target data to obtain the operation result.

[0007] According to a second aspect of one or more embodiments of this 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 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.

[0008] According to a third aspect of one or more embodiments of this 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 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.

[0009] According to a fourth aspect of one or more embodiments of this specification, an electronic device is proposed, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the method described in the first aspect by running the executable instructions.

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

[0011] 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, if the data acquisition information satisfies the acquisition rules and / or the data usage information satisfies the usage rules, the data acquirer is provided with the credential information for the target data, 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.

[0012] As can be seen, this solution records the acquisition and usage rules of the target data in the data management contract deployed by the blockchain system. This contract verifies whether the data acquisition information submitted by the data acquirer satisfies the acquisition rules and whether the corresponding data usage information satisfies the usage rules. Based on the verification results, it determines whether to disclose the credential information used to obtain the target data or its calculation results to the data acquirer. This means that the blockchain system and the data management contract deployed on it achieve automated and refined authorization of the target data on the chain. On the one hand, recording the acquisition and usage rules of the target data in the data management contract deployed on the chain, and having the blockchain system complete the authorization of the target data on the chain based on this contract, significantly reduces the data management burden on the data owner during the data authorization process and helps 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 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

[0013] FIG1 is a schematic diagram of an example environment provided by an exemplary embodiment.

[0014] FIG2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment.

[0015] FIG3 is a flow chart of a data management method provided by an exemplary embodiment.

[0016] FIG4 is a schematic structural diagram of a data management system provided by an exemplary embodiment.

[0017] FIG5 is a schematic structural diagram of a device provided by an exemplary embodiment.

[0018] FIG6 is a block diagram of a data management device provided by an exemplary embodiment. DETAILED DESCRIPTION

[0019] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

[0020] 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 method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down 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.

[0021] FIG1 is a schematic diagram of an example environment provided by an exemplary embodiment. As shown in FIG1 , example environment 100 allows entities to participate in a blockchain network 102. Blockchain network 102 can be a public, private, or consortium blockchain network. Example environment 100 may include computing devices 104, 106, 108, 110, 112, and a network 114. In one embodiment, network 114 may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and may be connected to websites, user devices (e.g., computing devices), and backend systems. In one embodiment, any computing device may access network 114 via wired and / or wireless communications.

[0022] 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 comprising multiple computers interconnected by a network and operating as a distributed processing system.

[0023] In one embodiment, computing devices 104-108 may run any suitable computing system capable of serving 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, smartphones, and wearable devices. In one embodiment, computing devices 104-108 may belong to relevant entities and be used to implement corresponding services, such as managing transactions between a particular entity or multiple entities.

[0024] In one embodiment, computing devices 104-108 each store a blockchain ledger corresponding to blockchain network 102. Computing device 104 may be (or include) a web server for providing browser functionality, which may provide visual information related to blockchain network 102 over network 114. In some cases, computing device 104 may not participate in block validation, but instead monitor blockchain network 102 to determine when other nodes (such as computing devices 106-108) reach consensus and generate a corresponding blockchain visual user interface accordingly.

[0025] In one embodiment, computing device 104 may receive a request for a blockchain visual user interface from 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. For example, a user of computing device 108 may use a browser running on computing device 108 to send the request to computing device 104.

[0026] In response to the above request, computing device 104 may generate a blockchain visual user interface (e.g., a webpage) based on the stored blockchain ledger and send the generated blockchain visual user interface to the requesting client device. If blockchain network 102 is a private or consortium blockchain network, the request for the blockchain visual user interface may include user authorization information. Before generating the blockchain visual user interface and sending it to the requesting client device, computing device 104 may verify the user authorization information and return the corresponding blockchain visual user interface if the verification is successful.

[0027] The blockchain visualization user interface can be displayed on a client device (e.g., user interface 116 shown in FIG. 1 ). When the blockchain ledger is updated, the content displayed in user interface 116 can also be updated accordingly. Furthermore, user interaction with user interface 116 may result in requests for other user interfaces, such as a block list, block details, transaction list, transaction details, account list, account details, contract list, contract details, or a search results page generated by a user searching the blockchain network.

[0028] Figure 2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment. As shown in Figure 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 with its own transaction management system 208.

[0029] In one embodiment, the managed services 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 via 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 its 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, communication between the interface 210 and the blockchain network layer 206 may be implemented using remote procedure calls (RPCs). In some examples, the interface 210 may provide the transaction management system 208 with an API for accessing the blockchain network 212 .

[0030] In one embodiment, the blockchain network 212 is provided in the form of a peer-to-peer network, which includes multiple nodes 214, each of which is used to persist a blockchain ledger 216 formed by blockchain data; wherein, only one blockchain ledger 216 is shown in Figure 2, but multiple blockchain ledgers 216 or copies thereof may exist in the blockchain network 212, for example, each node 214 may respectively maintain a blockchain ledger 216 or a copy thereof.

[0031] It should be noted 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 blockchain's distributed database. Blockchain transactions can be divided into narrow and broad categories. A narrow transaction refers to a transfer of value published by a user to the blockchain; for example, in the traditional Bitcoin blockchain network, a transaction can be a transfer initiated by a user within the blockchain. A broad transaction refers to business data published by a user to the blockchain with business intent. For example, an operator can build a consortium chain based on actual business needs and rely on it to deploy other types of online services unrelated to value transfer (such as rental services, vehicle dispatch services, insurance claims services, credit services, medical services, etc.). In such a consortium chain, a transaction can be a business message or business request published by a user within the consortium chain with business intent.

[0032] Blockchains are generally categorized into three types: public, private, and consortium. Furthermore, various combinations exist, such as private + consortium, or consortium + public. Public blockchains offer the highest degree of decentralization. Participants in a public blockchain can access data records, participate in transactions, and compete for the right to record new blocks. Furthermore, participants (i.e., nodes) can freely join and exit the network and perform related operations. In contrast, private blockchains have write permissions controlled by a specific organization or institution, while data read permissions are regulated by that organization. Simply put, a private blockchain can be a weakly centralized system with a small number of participating nodes, strictly limited in scope. This type of blockchain is more suitable for internal use within a specific organization. Consortium blockchains fall somewhere between public and private blockchains, achieving "partial decentralization." Each node in a consortium chain typically has a corresponding entity or organization. Participants join the network through authorization and form a stakeholder alliance to jointly maintain the blockchain's operations.

[0033] Whether it's a public, private, or consortium blockchain, they all offer smart contract functionality. 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 code.

[0034] Taking Ethereum as an example, users can create and invoke complex logic within the Ethereum network. At the core of Ethereum, a programmable blockchain, is the Ethereum Virtual Machine (EVM), which runs on every Ethereum node. The EVM is a Turing-complete virtual machine, meaning it can implement a wide range of complex logic. Smart contracts published and invoked on the Ethereum network run on the EVM. Once a blockchain node publishes a smart contract on the Ethereum network, the contract is considered deployed on the network.

[0035] Another important concept in the blockchain world is the account. Taking Ethereum as an example, accounts are generally divided 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 code (i.e., smart contracts). Of course, some blockchain models derived from the Ethereum architecture can further expand the account types supported by the blockchain, and this is not specifically limited in this specification.

[0036] 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.

[0037] 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; 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 preventing replay attacks;

[0038] The Code field, for contract accounts, is typically used to maintain the contract code for that account. In practice, the Code field typically only maintains the hash value of the contract code; therefore, the Code field is often also called the Codehash field. For external accounts, the Code field is typically empty.

[0039] 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 contract execution. This independent storage space is usually called the account storage of the contract account.

[0040] The storage content of a 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 also commonly referred to as the Storage tree. The Storage field usually only maintains the root node of the Storage tree; therefore, the Storage field is also commonly referred to as the StorageRoot field.

[0041] To address the technical issues existing in the aforementioned related technologies, this specification proposes a data management solution. In this solution, a data management contract is deployed and executed within a blockchain system to verify whether the data acquisition information related to the target data satisfies the target data acquisition rules and whether the data usage information satisfies the target data usage rules recorded in the contract. This determines whether to disclose to the data acquirer credential information instructing the data owner to assist the data acquirer in obtaining the data and / or its computation results, thereby achieving automated and refined authorization of the target data on-chain. The technical solution of this specification is described below with reference to examples.

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

[0043] 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 rules.

[0044] In one embodiment, the blockchain system may include only 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. In the case of multiple copies, these multiple copies of managed data may be independent of each other or may have any form of association, and this specification is not limited to this. Furthermore, one or more copies of managed data may constitute a dataset (i.e., the managed data is managed as a dataset), and multiple copies of managed data belonging to the data owner may constitute one or more datasets, which are also considered to belong to the data owner. In the case of constituting multiple datasets, the intersection between any two datasets may be an empty set (i.e., the two datasets each contain different managed data), or the intersection may be a proper subset of the two datasets (i.e., the two datasets each contain some of the same managed data).

[0045] In one embodiment, the managed data belonging to the data owner can be maintained by the data owner itself, such as storing the managed data in the data owner's local storage space or a storage space such as a database with a network connection to the data owner. Alternatively, it can also be maintained by a preset custodian (such as designated by the data owner), such as having the custodian store the managed data in a preset storage space associated with the custodian (such as the custodian's local storage space or a database managed by it). 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.

[0046] 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 (for the target data in the authorized data) to the blockchain system in order to obtain the credential information for this part of the target data (specifically, the following acquisition credentials, usage credentials or comprehensive credentials) revealed by the blockchain system, and further use this 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. 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 the one or more authorized data belonging to the data owner (actually also the managed data belonging to the data owner) requested by the data acquisition party. 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; if the target data contains multiple data, the data may belong to one or more data sets.

[0047] It should be pointed out that any data mentioned in this specification as "managed data", "authorized data" and "target data" 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.

[0048] For authorizable data belonging to the data owner, the data management contract deployed in the blockchain system can record the acquisition and usage rules of this authorizable data. Given that the target data is at least part of the authorizable data, the acquisition and usage rules of the target data can naturally also be recorded in the contract. Because the blockchain system will subsequently need 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 and usage rules), the data owner can pre-configure the corresponding rules for the target data in the data management contract before the blockchain system executes the data management contract. The rule configuration process for the target data is essentially the same as the rule configuration process for any authorizable data. The rule configuration process for any authorizable data is used as an example to illustrate below.

[0049] When deciding to authorize the use of managed data belonging to the data owner to other parties (i.e., determining that the data is authorizable data), the data owner can determine the corresponding acquisition and use rules for any of the authorizable data based on the preset plan, sharing requirements, authorization intentions, and / or the data type of the target data. Of course, rules for multiple authorizable data can be determined and configured in batches.

[0050] The acquisition rules of any authorizable data may include multiple rules. For example, it may include an algorithm list, 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 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 here. 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 interval, certain 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 in accordance with the requirements of the data owner.

[0051] In addition to the above-mentioned algorithm list and credit score range, the acquisition rules may also include a geographical range (the corresponding data acquisition information may include the geographical location information of the data acquirer), a number segment (the corresponding data acquisition information may include the identity serial 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.

[0052] Similarly, the usage rules for any authorizable data may also include multiple rules. For example, they may include the validity period of the credential (the corresponding data usage information may include the current time, the time the data acquisition information is received, and the time the acquisition credential is received), the maximum number of uses (the corresponding data usage information may include the total number of times the blockchain system has received the usage credential or the data acquisition information submitted by the data acquirer), the effective frequency range (the corresponding data usage information may include the current frequency at which the blockchain system receives the usage credential or the data acquisition information), etc. For specific information, please refer to the relevant embodiments below for determining whether data usage information meets the usage rules, which will not be repeated here.

[0053] 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 relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0054] 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 realize the configuration of the data and its related rules. The data owner can 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 way, 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 realized, which helps to improve data management and authorization efficiency.

[0055] Taking any authorizable data as an example, the correspondence between the data identifier of any authorizable data and its acquisition rules may be referred to as the first correspondence, and the correspondence between the data identifier of any authorizable data and its usage rules may be referred to as the second correspondence. 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 first correspondence and the 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.

[0056] Depending on the structure of the blockchain system, the data owner can flexibly adopt corresponding methods to submit the corresponding relationship of any authorized data (i.e., the first corresponding relationship and / or the second corresponding relationship mentioned above). For example, in the case where the blockchain system only includes a blockchain network, the data owner can (through its own client device) 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 a blockchain network and a BaaS platform, the data owner can (through its own client device) 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 achieve different functions.

[0057] Since the blockchain system may have already 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.

[0058] For example, if a data management contract has not yet 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 acquisition rules can be configured at the same time as the data management contract is deployed, simplifying the contract processing logic. For another example, if the blockchain system already has a data management contract deployed, the blockchain system can configure the received corresponding relationship in the (already deployed) data management contract. This contract can be pre-deployed by any relevant party (such as the data owner, the BaaS platform, or other independent third party). The pre-deployed contract may not record any data corresponding relationship. Alternatively, the pre-deployed contract may pre-record (before configuring the received corresponding relationship) corresponding relationships belonging to any data owner (possibly including the data owner). In this way, the data owner can configure the above-mentioned corresponding relationship for any authorized data in the pre-deployed data management contract, thereby adding a new corresponding relationship or updating an existing one in the contract, achieving flexible configuration and management of rules.

[0059] 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 based on the record of the data identifier and the rules in the contract.

[0060] 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.

[0061] 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 the any corresponding relationship can be added to the data management contract, that is, the rules corresponding to the data identifier of any authorizable data are added to the contract, thereby adding the any corresponding relationship as a whole. For another example, if the data identifier of any authorizable data is already recorded in the data management contract, then the rules in any corresponding relationship can 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 achieving the update of the existing rules. For another example, if the rules in any corresponding relationship are already recorded in the data management contract, then the data identifier in the corresponding relationship (that is, the data identifier of any authorizable data) can 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.

[0062] Table 1 below is a table of correspondences between data identifiers of authorizable data and their corresponding rules, as recorded in a data management contract, provided by an exemplary embodiment. In the correspondences 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 (it may not be set or has been cleared after being set). 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.

[0063] Table 1

[0064] For example, if the corresponding relationship between authorizable data 6 and its acquisition rule currently does not exist in Table 1, then if the data owner submits the first corresponding relationship, Relation-g6, as "Data6, Rule-g5" to the blockchain system, 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 and second corresponding relationships for 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 Relation-g6 and Relation-u6 separately. For another example, for the existing corresponding relationship, Relation-g1, 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 acquisition rule Rule2 that already exists 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.

[0065] 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. This manual does not limit this.

[0066] As previously mentioned, smart contracts have corresponding contract accounts in the blockchain system. For data management contracts, any of the aforementioned correspondences can be recorded in the account storage of its contract account as contract status data, such as in the Storage field of the contract account (as the value of this field). In fact, in addition to the aforementioned fields such as Balance, Nonce, Code, and Storage, a contract account can also contain other fields, such as custom fields, in which case any of the aforementioned correspondences can also be stored. This specification does not limit the storage location of the correspondences related to authorizable data in the contract account.

[0067] This concludes the process of configuring the corresponding relationships associated with any authorizable data. The data management system shown in Figure 4 includes a data owner, a data acquirer, and a blockchain system. The blockchain system deploys a data management contract that records the data identifiers of the authorizable data (including target data) belonging to the data owner, as well as the first and second corresponding relationships associated with the authorizable data. These corresponding relationships can be configured by the data owner using the methods described in the previous embodiments.

[0068] In addition to the data identifiers of the authorizable data and their corresponding relationships, the data management contract can also record relevant information about the authorizable data so that data acquirers with acquisition needs can view it. The relevant information can include meta-information, including but 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 exemplary data for 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 common characteristics or at least some typical characteristics of each authorizable data in the data set). This allows the data acquirer to fully understand each authorizable data based on this information, thereby more accurately determining 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 it uses and view it in the blockchain visual user interface 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. If it is determined to be satisfied, then submit the data acquisition information to the blockchain system to minimize the subsequent execution of the data management contract. This will cause authorization failures due to the contract determining that the data acquisition information does not meet the acquisition rules, thereby improving the probability of successful authorization and authorization efficiency to a certain extent. Of course, the data acquirer can also avoid the above preliminary judgment and directly submit data acquisition information for the target data after determining that it needs to obtain it. This will not be repeated here.

[0069] Among them, for the target data that the data acquirer wants to request to obtain (i.e., to obtain authorization from the data owner), 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 target data the data acquirer requests to obtain is specifically which authorized data; the information to be verified is used to subsequently determine whether the acquisition rules of the target data are met. In other words, the subsequent determination of whether the data acquisition information meets the acquisition rules is to determine 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.

[0070] For example, the data acquisition information for any target data Dj may be "data Dj, privacy intersection, credit score 900." This information indicates that the data acquirer declares that it needs to acquire the target data Dj for privacy intersection and that its credit score is 900. Of course, if the data acquisition rules for data Dj also include a geographic scope and a network address, the data acquisition information may also include "geographic scope is region X, network address is yyy" to declare that the data acquirer is located in region X and has a network address of yyy. This will not be repeated here.

[0071] In one embodiment, the data acquisition information can 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 (through its own client device) directly initiate a data acquisition transaction containing the data acquisition information to the blockchain node in the network. For another example, in the case where the blockchain system includes a blockchain network and a BaaS platform, the data acquirer can (through its own client device) initiate a data acquisition request containing the data acquisition information to the BaaS platform, so that the BaaS platform can respond to the request and initiate a data acquisition transaction containing the data acquisition information to the blockchain node in the blockchain system. After the above-mentioned 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.

[0072] As previously mentioned, the data management contract records the target data acquisition rules. Based on this, upon receiving the data acquisition information submitted by the data acquirer, the blockchain system can execute the contract to determine whether the data acquisition information satisfies the acquisition rules. Continuing from the previous embodiment, when the data acquisition information is included in a 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 in the transaction as an input parameter to execute the data management contract (the contract code therein) during the execution of the transaction to determine whether the data acquisition information satisfies the target data acquisition rules.

[0073] In one embodiment, the acquisition rules may include an algorithm list, and the data acquisition information may include a target algorithm. Any algorithm in the algorithm list may specifically include an identifier such as the algorithm's name or number, the algorithm's algorithm rules, and related parameters of the algorithm. As previously mentioned, the algorithms recorded in the algorithm list are used to represent the algorithms that the data owner allows the data acquirer to use when processing the target data. The target algorithm is the algorithm declared by the data acquirer to use when processing the target 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. Accordingly, 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, such as performing hash operations or encryption on the obtained target data; and / or, the target algorithm can be used to perform a preset operation on the target data (such as a privacy intersection operation involving multiple parties including the data owner, etc.), so that the data acquirer can obtain the operation result obtained after executing the preset operation using the acquisition credentials revealed by the blockchain system.

[0074] In another embodiment, the acquisition rules may also include a credit score range, and the data acquisition information may include the data acquirer's credit score on a pre-set platform. The credit score can be a specific numerical value, such as 300, 500, or 800, in which case the credit score range can be a numerical range. Alternatively, the credit score can be a rating level, such as A, B, or C, or excellent, good, fair, or poor, in which case the credit score range can be a set of rating levels including at least one rating level. It is understood that the credit score can be used to measure the creditworthiness of the data acquirer on the pre-set platform. Based on this, if the data acquirer's credit score on the pre-set platform falls within the credit score range, the data management contract can determine that the data acquisition information satisfies the acquisition rules. Thus, by setting the credit score range to a higher range, data acquirers with good credit can be effectively restricted from obtaining authorization for any authorizable data, while preventing data acquirers with poor credit from obtaining authorization, thereby ensuring that the authorized data can be processed in accordance with the data owner's requirements. 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, then the data management contract can determine that the data acquisition information meets 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, then the data management contract will determine that the data acquisition information does not meet the acquisition rule of Di.

[0075] In addition, the data management contract can call other contracts during execution, wherein the data acquisition information submitted by the data acquirer can include the contract address of the other contract, so that the data management contract can call the other contract 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 execution. 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. 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 (other than 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, thereby avoiding the security risks that may arise from the data acquirer falsifying the credit scores.

[0076] As shown in Figure 4, in the Ethereum scenario, blockchain nodes can run the EVM, which includes rule execution engines, such as an acquisition rule execution engine and a usage rule execution engine. During the execution of the data management contract, the acquisition rule execution engine can be invoked to determine whether the data acquisition information submitted by the data acquirer satisfies the target data acquisition rules. Furthermore, the usage rule engine can be invoked to determine whether subsequently determined data usage information satisfies the target data usage rules. This determination process is described in the examples below and will not be further elaborated here.

[0077] 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.

[0078] 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. When calling the contract, a blockchain transaction may specify the interface function (in the contract) to be called and its input parameters, so that during 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 previously described, the data management contract is executed separately in steps 302 and 304. In a specific implementation, the two steps may respectively call different interface functions of the data management contract, thereby achieving different functions by executing the same data management contract: step 302 executes the contract to determine whether the data acquisition information satisfies the acquisition rules, and step 304 executes the contract to determine whether the data usage information satisfies the usage rules.

[0079] 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. 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.

[0080] 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, if the data acquisition information satisfies the acquisition rules and / or the data usage information satisfies the usage rules, the data acquirer is provided with the credential information for the target data, 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.

[0081] As can be seen, this solution records the acquisition and usage rules of the target data in the data management contract deployed by the blockchain system. This contract verifies whether the data acquisition information submitted by the data acquirer satisfies the acquisition rules and whether the corresponding data usage information satisfies the usage rules. Based on the verification results, it determines whether to disclose the credential information used to obtain the target data or its calculation results to the data acquirer. This means that the blockchain system and the data management contract deployed on it achieve automated and refined authorization of the target data on the chain. On the one hand, recording the acquisition and usage rules of the target data in the data management contract deployed on the chain, and having the blockchain system complete the authorization of the target data on the chain based on this contract, significantly reduces the data management burden on the data owner during the data authorization process and helps 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 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.

[0082] Through the aforementioned approach, the data management contract can verify whether the relevant information of the target data meets the corresponding rules. If the data acquisition information meets the acquisition rules and / or the data usage information meets the usage rules, the blockchain network can disclose the credential information for the target data to the data acquirer. Conversely, if the data acquisition information does not meet the acquisition rules, the blockchain network can avoid disclosing the acquisition credentials and instead disclose an authorization failure message for the target data to the data acquirer, informing the data acquirer that the request for authorization for the target data from the data owner has failed.

[0083] 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 credentials can be acquisition credentials, usage credentials, or comprehensive credentials. Since each credential can be revealed in the above manner, the following is an example of obtaining a credential:

[0084] 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 writing it into the data field of the event. The data acquirer has monitoring rights 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 based on the monitoring results.

[0085] 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 the rule judgment method (used to determine whether the data acquisition information meets 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:

[0086] 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 two executions of the data management contract, 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.

[0087] For example, the content of the data field of the third event may include:

[0088] The acquisition credential ID can be globally unique within the data management system and is used to uniquely identify the currently generated acquisition credential. The data1 identifier, data2 identifier, and data3 identifier are used to represent the target data requested by the data acquirer, namely, data1, data2, and data3, respectively. Algorithm list 1, algorithm list 2, and algorithm list 3 are used to represent the algorithms used by the data acquirer to process data1, data2, and data3, respectively.

[0089] For another example, the acquisition credential can also be written into the contract account of the data management contract, and the data acquirer can have query authority for the contract account. Among them. The acquisition credential can 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 can also contain custom fields, the acquisition credential can 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.

[0090] As previously mentioned, if the data acquisition information satisfies the acquisition rules and / or the data usage information satisfies the usage rules, the blockchain network can disclose credential information for the target data to the data acquirer. For example, if the data acquisition information satisfies the acquisition rules, the disclosed credential information may include an acquisition credential; and if the data usage information satisfies the usage rules, the disclosed credential information may include a usage credential. Specifically, the blockchain network can determine the data usage information for the target data based on the acquisition credential submitted by the data acquirer. Alternatively, the blockchain network can 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, if the data acquisition information satisfies the acquisition rules and the data usage information satisfies the usage rules, the blockchain network can disclose a comprehensive credential to the data acquirer. It can be seen that the disclosed credential information may be an acquisition credential, a usage credential, or a comprehensive credential. The process of verifying whether the aforementioned information satisfies the corresponding rules and disclosing the corresponding credential information may involve various scenarios, each of which is described below.

[0091] In one embodiment, if the data management contract determines that the data acquisition information satisfies the acquisition rules, the blockchain network can provide the data acquirer with an acquisition credential for the target data. This credential indicates that the data acquisition information provided by the data acquirer has been verified by the data management contract against the acquisition rules. After receiving the acquisition credential provided by the blockchain network, the data acquirer can submit the credential to the blockchain network in order to obtain the corresponding usage credential (the usage credential can be used by the data acquirer to request the use of the target data from the data owner). Upon receiving the credential submitted by the data acquirer, the blockchain network can determine the corresponding data usage information based on the credential and re-execute the data management contract to determine whether the data usage information satisfies the usage rules of the target data. If so, the usage credential for the target data is provided. In this way, the data acquirer needs to first submit the data acquisition information to the blockchain network to obtain the acquisition credential provided by the blockchain network, and then submit the acquisition credential to the blockchain network to obtain the usage credential provided by the blockchain network. The usage credential (or the acquisition credential and usage credential) can then be provided by the data acquirer to the data owner to obtain their assistance.

[0092] The data acquirer can submit the acquisition credential immediately after receiving it to obtain a usage credential, or can submit the acquisition credential at some point after receiving it (according to its actual needs) to obtain a usage credential. It is understandable that each submission of the acquisition credential indicates that the data acquirer has a 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.) to accurately limit the data acquirer's use of the credential to request the use of the target data, thereby achieving refined control over the target data authorization process.

[0093] For example, if the usage rules include a credential validity period, the data usage information may include the current time (as determined by the data management contract) and / or the time the credential was received (i.e., the time the blockchain network receives the credential submitted by the data acquirer). Accordingly, if the current time or the time the credential was received falls within the credential validity period, the data management contract may determine that the data usage information satisfies the usage rules. The credential validity period may be a time interval or an expiration time. This approach essentially provides an "aging" mechanism for the credential. By properly setting the credential validity period, flexible control over the credential "aging" can be achieved. For example, a data acquirer can be controlled to obtain a target data credential once and then use it (via the credential) indefinitely. Alternatively, a data acquirer can be controlled to use the credential only within a preset time period (e.g., one hour, one day, one week, one month, etc.) after obtaining the credential for any target data. Beyond this time period, the credential automatically expires and cannot be used. Correspondingly, the credential validity period can be recorded in the credential itself so that the data owner can determine whether the credential is invalid.

[0094] For another example, when 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 as 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. The maximum number of uses may be included in the aforementioned acquisition credential, and the total number may be obtained by querying the execution record of the contract by the data management contract or the blockchain network. It can be seen that the first total number of times essentially sets a "number of uses limit" mechanism for the acquisition credential. By reasonably setting the maximum number of uses, it is possible to achieve flexible control over the "number of times the acquisition credential can be used." For example, the data acquirer can be controlled to obtain the acquisition credential of the target data once and then use the credential (through the credential) an unlimited number of times; or after the data acquirer obtains the acquisition credential of the target data once, the credential can only be used up to the maximum number of uses. When the maximum number of uses is reached, the acquisition credential automatically expires and cannot be used again. The second total number of times actually sets an "authorization number limit" mechanism for the target data for the data acquirer, so that the number of times the data acquirer obtains the use credential does not exceed the maximum number of uses, thus achieving a precise limit on the number of times the acquisition credential is revealed.

[0095] For another example, where the usage rules include a valid frequency range, the data usage information may include the current frequency at which the blockchain system receives the usage credentials or the data acquisition information; the frequency at which the acquisition credentials are received is the first current frequency, and the frequency at which the data acquisition party receives data acquisition information for the target data (the specific content of which may be the same as or different from the aforementioned data acquisition information) is the second current frequency. Accordingly, if the current frequency is within the valid frequency range, the data management contract may determine that the data usage information satisfies the usage rules. Thus, the first current frequency establishes a "usage frequency limit" mechanism for the acquisition credentials, enabling flexible control over the "usage frequency" of the acquisition credentials; while the second frequency establishes an "authorized frequency limit" mechanism for the target data, ensuring that the frequency at which the data acquisition party obtains the usage credentials does not exceed the valid frequency range, thereby precisely limiting the frequency of the acquisition credentials being disclosed and preventing the data acquisition party from obtaining the usage credentials or using the target data too frequently.

[0096] In another embodiment, if the data management contract determines that the data acquisition information satisfies the acquisition rules, the blockchain network can provide the data acquirer with an acquisition credential for the target data. This credential indicates that the data acquisition information provided by the data acquirer has passed the data management contract's verification of the acquisition rules. Furthermore, the blockchain network can determine data usage information based on the data acquisition information after receiving it, and / or determine data usage information based on the credential when the acquisition credential is disclosed. During the execution of the data management contract, the contract determines whether the data usage information satisfies the usage rules, and if so, discloses the usage credential for the target data. Thus, the blockchain network can determine data usage information for the target data based on the received data acquisition information and / or the disclosed acquisition credential. The data acquirer only needs to submit the data acquisition information once (e.g., publish a data acquisition transaction) to obtain the acquisition credential and usage credential disclosed by the blockchain network.

[0097] 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, it is also possible to determine a portion of the data usage information based on the data acquisition information, and determine the content of the acquisition certificate (without generating an acquisition certificate) if the data acquisition information satisfies the acquisition rules, and then determine another portion of the data usage information based on the content. The data management contract then determines whether the above two portions of data usage information satisfy the usage rules, and if it is determined that they do, a comprehensive certificate is revealed. The certificate may include 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 based on 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.

[0098] For example, if the data acquirer is U1, the usage rules for any target data Di can be {Di, U1, privacy intersection, expired = 600s, limit = 2, frequency = 120s / time, ...}. "expired = 600s" indicates that the credential is valid for 600s (i.e., 10 minutes), "limit = 2" indicates that the credential can be used a maximum of 2 times, and "frequency = 200s / time" indicates that the interval between two consecutive credential submissions must be no less than 120s, meaning that the target data Di can be requested at most once every 2 minutes.

[0099] 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 who holds 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 and 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 unrelated personnel from obtaining the credential information when it is recorded in plain text on the chain, that is, avoiding the leakage of credential information and protecting the rights and interests of the data owner.

[0100] After obtaining the credential information transmitted by the blockchain network, the data acquirer can provide this 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 this information.

[0101] In one embodiment, the data acquirer may initiate a data acquisition request containing 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 to 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, thereby preventing the data acquirer from directly obtaining the target data itself, preventing the data acquirer from leaking the target data and infringing the rights and interests of the data owner, ensuring that the target data is always held only by the data owner, and improving the security of the target data.

[0102] The pre-set computations performed on the target data should satisfy the data acquirer's computational requirements for the target data. In one embodiment, the pre-set computations may include multi-party computations involving both the data owner and the data acquirer. In this case, the server-side data acquirer only obtains the results of the multi-party computations and cannot obtain the target data itself. This not only improves the security of the target data itself, but also helps reduce the burden on the data acquirer in using the target data and improves its efficiency.

[0103] 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 they can 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 and initiated to the blockchain system; or they can 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 and initiated to the data owner, which will not be repeated here. 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.

[0104] Furthermore, the various authorizable data held by the data owner may have different privacy levels; accordingly, data with different privacy levels can be processed differently. For example, a data owner may hold authorizable data with a relatively low privacy level and authorizable data with a relatively high privacy level, namely, low-privacy authorizable data and high-privacy authorizable data. Accordingly, when the target data has a low privacy level, the target data can be provided to the data acquirer, meaning the data owner is not concerned about whether the low-privacy data will be leaked. However, when the target data has a high privacy level, the target data needs to be subjected to a preset operation, so that the corresponding operation results are provided to the data acquirer to ensure that the high-privacy data is not leaked. If the target data contains both low-privacy and high-privacy authorizable data, the low-privacy target data can be provided directly to the data acquirer, and the high-privacy target data can be subjected to the preset operation, and the operation results provided to the data acquirer. Alternatively, especially if the data acquirer has specified the required preset operation rules in the aforementioned data acquisition transaction or data acquisition request, all target data can be subjected to the preset operation, and the operation results provided to the data acquirer.

[0105] 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 possible fraudulent behavior such as tampering with the credentials by the data acquirer, the data owner can also verify the authenticity of the credential information it received. For example, if 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 block where the transaction occurs) or the relevant information of the data management contract (such as the 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 it received (submitted by the data acquirer) is consistent with the credential information it queried: if the two are consistent, it means that the received credential information has not been tampered with, indicating that the data acquirer provided the authentic credential information it received; conversely, if the two are inconsistent, it means that the data acquirer provided is not the authentic credential information it received. Among them, the above query process can be implemented through SPV (Simplified Payment Verification) technology; alternatively, the data owner can also obtain a 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 here.

[0106] 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 reveals the credential information for the target data to the data acquirer, it can also reveal 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 successful, it can assist the data acquirer in obtaining the target data and / or the calculation result obtained after performing the preset operation on the target data. In other words, the target data and / or the calculation result obtained after performing the preset operation on the target data can be assisted by the data owner to obtain if the signature verification is successful, that is, the data owner can use the verification of the credential information as a prerequisite for assisting the data acquirer, thereby effectively avoiding 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.

[0107] It is understood that the credential information disclosed in the aforementioned manner can be used to prove that the data acquirer meets the requirements for obtaining the target data. After obtaining the credential information, the data acquirer can use the credential to obtain the target data and / or calculation results. Furthermore, the specific process by which the data owner assists the data acquirer in obtaining the target data and / or calculation results can be further restricted through the use rules of the target data.

[0108] In addition, when assisting the data acquirer in obtaining the target data, if the target data is stored locally on the data owner, the data can be returned directly to the data acquirer; or, if the target data is maintained by a preset custodian, the custodian can be instructed to return the data to the data acquirer. When assisting the data acquirer in obtaining the result of a preset operation performed on the target data, if the target data is stored locally, the data owner can use the target data to participate in the preset operation and return the result to the data acquirer; or the data owner can call on a trusted party to use the target data to participate in the preset operation, and have the party return the result directly to the data acquirer, or have the party feed back the result to the data owner, and have the data owner return it to the data acquirer, so as to avoid revealing the parties directly involved in the preset operation to the data acquirer. Similarly, if the target data is maintained by a preset custodian, the target data can be obtained from the custodian and a preset operation can be performed, and the operation result can be returned to the data acquirer. Alternatively, the custodian can be instructed to use the target data to participate in the preset operation, and the custodian can return the operation result directly to the data acquirer, or the custodian can feed back the operation result to the data owner, and the data owner can return it to the data acquirer, so as to avoid revealing the custodian 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 manual does not limit them.

[0109] Furthermore, after obtaining the target data using the credential information, the data acquirer may directly process the data itself; and after obtaining the result of a predetermined operation performed on the target data, the data acquirer may further process the result. This specification does not limit the manner in which the data acquirer processes the obtained target data or the result of the operation.

[0110] 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.

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

[0112] The data owner can configure the relevant rules during the deployment of the data management contract, or can add or update the access rules in a pre-deployed data management contract. For any authorized data, the configured relevant rules include access rules and / or usage rules.

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

[0114] In step 406, the blockchain network transmits the credential information to the data acquirer.

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

[0116] Implementation method A: Step 404a-1: The data acquisition direction submits data acquisition information for the target data to the blockchain system.

[0117] 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.

[0118] 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.

[0119] In step 406a-1, the blockchain network transmits the acquisition certificate to the data acquirer.

[0120] When the data management contract determines that the data acquisition information meets the acquisition rules, the blockchain network will provide the acquisition credentials to the data acquirer.

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

[0122] After receiving the access certificate, the data acquirer can submit it at an appropriate time. The submission method is similar to the data acquisition information submission method described above and will not be repeated here. After receiving the access 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.

[0123] In step 406a-2, the blockchain network transmits the usage certificate to the data acquirer.

[0124] When the data management contract determines that the data usage information meets the usage rules, the blockchain network will provide the usage credentials to the data acquirer.

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

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

[0127] In step 406b-1, the blockchain network transmits the acquisition certificate to the data acquirer.

[0128] If the data management contract determines that the data acquisition information meets the acquisition rules, the blockchain network will provide the data acquisition party with an acquisition certificate. Alternatively, after generating or providing the acquisition certificate, the blockchain network can also determine the corresponding data usage information based on the certificate.

[0129] In step 406b-2, the blockchain network transmits the usage certificate to the data acquirer.

[0130] 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.

[0131] 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 at the same time to reduce the number of interactions between the two.

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

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

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

[0135] When the data management contract determines that the data acquisition information satisfies the acquisition rules, it determines the content (that should be included) of the acquisition credential (but does not generate or disclose the credential), 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 credential, etc. Furthermore, after determining the above-mentioned contents of the acquisition credential, the blockchain network may also determine corresponding data usage information based on the credential, such as the above-mentioned contents of the acquisition credential.

[0136] 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).

[0137] 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.

[0138] In step 410 , the data owner assists the data acquirer in obtaining the target data and / or the calculation result after performing a preset calculation on the target data.

[0139] The data owner can verify the authenticity of the acquisition credentials and whether they meet the usage rules. If the verification is successful, the data owner can assist the data acquirer in obtaining the target data and / or calculation results. Of course, if the verification fails, the data owner should refrain from assisting the data acquirer in obtaining the target data and / or calculation 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 calculation results.

[0140] Corresponding to the aforementioned embodiment, this 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 meets 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 meets the usage rules; and, when the data acquisition information meets the acquisition rules and / or the data usage information meets 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.

[0141] FIG5 is a schematic structural diagram of a device provided by an exemplary embodiment. Referring 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 software implementation, one or more embodiments of this specification do not exclude other implementation methods, 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.

[0142] As shown in FIG6 , FIG6 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 FIG5 to implement the technical solution of this specification.

[0143] The data management device is applied to a blockchain system in a data management system, and 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. 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 satisfies the acquisition rules; a second execution unit 602, 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; a credential transmission unit 603, which is used to transmit 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.

[0144] Optionally, when the data acquisition information satisfies the acquisition rules, the transmitted credential information includes the acquisition credential; the second execution unit 602 is specifically used to: determine the data usage information for the target data based on the received acquisition credential 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 credential; wherein, when the data usage information satisfies the usage rules, the transmitted credential information includes the usage credential.

[0145] Optionally, the second execution unit 602 is specifically used to: determine the data usage information for the target data based on the received data acquisition information; the credential disclosure unit 603 is specifically used to: disclose the comprehensive credential to the data acquisition party when the data acquisition information meets the acquisition rules and the data usage information meets the usage rules.

[0146] 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 a valid frequency range, and the data usage information includes the 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.

[0147] 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.

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

[0149] 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.

[0150] Optionally, the credential transmission unit 603 is specifically used to: write the credential information 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; or write the credential information into the contract account of the data management contract, and the data acquirer has the right to query the contract account.

[0151] Optionally, the credential disclosure unit 603 is specifically used to: disclose the credential information of the target data and the signature of the credential information made by 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 assisted by the data owner to obtain the data acquisition party when the signature is verified.

[0152] 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 rules, and / or submit a second correspondence between the data identifier of any authorizable data and its usage rules; 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.

[0153] 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.

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

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

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

[0157] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. 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 disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, 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 herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0158] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0159] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0160] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "an," "the," 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 otherwise. 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.

[0161] 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, such 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, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when..." or "when..." or "in response to determining."

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

Claims

1. 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 the acquisition rules and usage rules of the target data, and the target data belongs to the data owner. The method comprises: 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.

2. 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: Determining 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.

3. The method according to claim 1, The determining of data usage information for the target data includes: Determining 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.

4. The method according to claim 2 or 3, wherein 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.

5. The method according to claim 1, wherein the acquisition rule comprises an algorithm list, and the data acquisition information satisfies the acquisition rule, comprising: 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.

6. 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.

7. The method according to claim 1, wherein 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.

8. According to the method of claim 1, the blockchain system discloses the 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.

9. According to the method of claim 1, the blockchain system discloses the 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.

10. The method according to claim 1, wherein there is authenticatable data belonging to a data owner, and 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 a data identifier of any authorizable data and its acquisition rule, and / or submits a second correspondence between a data identifier of any authorizable data and its usage rule; as well as, 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.

11. According to the method of claim 10, the blockchain system configures any one of the first corresponding relationship and the second corresponding relationship 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.

12. A data management system, comprising 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 target data, and the target data belongs to the data owner, wherein: 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.

13. A data management device, 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 use rules of the target data, and the target data belongs to the data owner, and 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.

14. 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.

15. A computer-readable storage medium having computer instructions stored thereon, wherein the instructions are executed by a processor to implement the method according to any one of claims 1 to 11.

Images