CN111475849A

CN111475849A - Private data query method and device based on block chain account

Info

Publication number: CN111475849A
Application number: CN202010419432.1A
Authority: CN
Inventors: 刘琦; 闫莺
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2019-11-08
Filing date: 2019-11-08
Publication date: 2020-07-31
Anticipated expiration: 2039-11-08
Also published as: CN110580418B; CN111475849B; CN110580418A; WO2021088546A1

Abstract

One or more embodiments of the present specification provide a method and an apparatus for querying private data based on a blockchain account; the method is applied to the block chain node and can comprise the following steps: when receiving a query transaction aiming at target privacy data initiated by a query party, reading a transaction identifier of a historical transaction related to the target privacy data and identity information of an initiator of the historical transaction, wherein the transaction identifier is contained in the query transaction; determining a blockchain account of the initiator according to the identity information of the initiator, and determining the query authority of the query party for the target privacy data according to the query authority recorded in the blockchain account; and when the determined inquiry authority is allowed to be inquired, acquiring the target privacy data, reading the acquired target privacy data into a trusted execution environment, and decrypting the acquired target privacy data so as to be acquired by the inquirer.

Description

Private data query method and device based on block chain account

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for querying private data based on a blockchain account.

Background

The blockchain technique is built on top of a transport network, such as a point-to-point network. Network nodes in a transport network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data.

The two biggest challenges in the current enterprise-level blockchain platform technology are privacy and performance, which are often difficult to solve simultaneously. Most solutions trade privacy for loss of performance or do not consider privacy much to pursue performance. Common encryption technologies for solving privacy problems, such as Homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledge proof), have high complexity and poor universality, and may cause serious performance loss.

Trusted Execution Environment (TEE) is another way to address privacy concerns. The TEE can play a role of a black box in hardware, a code and data operating system layer executed in the TEE cannot be peeped, and the TEE can be operated only through an interface defined in advance in the code. In the aspect of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptography operation in homomorphic encryption, and the efficiency of the calculation process is not lost, so that the safety and privacy of a block chain can be improved to a great extent on the premise of small performance loss by combining with the TEE. The industry is concerned with TEE solutions, and almost all mainstream chip and Software consortiums have their own TEE solutions, including Software-oriented TPM (Trusted Platform Module) and hardware-oriented Intel SGX (Software Guard Extensions), ARM Trustzone (Trusted zone), and Platform Security Processor (Platform Security Processor).

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and an apparatus for querying private data based on a blockchain account.

To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, a method for querying private data based on a blockchain account is provided, which is applied to a blockchain node; the method comprises the following steps:

when receiving a query transaction aiming at target privacy data initiated by a query party, reading a transaction identifier of a historical transaction related to the target privacy data and identity information of an initiator of the historical transaction, wherein the transaction identifier is contained in the query transaction;

determining a blockchain account of the initiator according to the identity information of the initiator, and determining the query authority of the query party for the target privacy data according to the query authority recorded in the blockchain account;

and when the determined inquiry authority is allowed to be inquired, acquiring the target privacy data, reading the acquired target privacy data into a trusted execution environment, and decrypting the acquired target privacy data so as to be acquired by the inquirer.

According to a second aspect of one or more embodiments of the present specification, a method for querying private data is provided, which is applied to a blockchain node; the method comprises the following steps:

when receiving a query transaction aiming at target privacy data sent by a query party, reading a transaction identifier of a historical transaction related to the target privacy data and identity information of an initiator of the historical transaction, wherein the transaction identifier is contained in the query transaction;

when the target privacy data is the historical transaction, determining a blockchain account of the initiator according to the identity information of the initiator, and determining the query authority of the query party for the historical transaction according to the query authority recorded in the blockchain account;

when the target privacy data is other transaction related data different from the historical transaction, reading a contract address of a service contract called by the historical transaction and contained in the inquiry transaction, acquiring the service contract according to the contract address, and executing an authority control code defined in the service contract to determine the inquiry authority of the inquirer for the target privacy data;

According to a third aspect of one or more embodiments of the present specification, there is provided a private data query apparatus based on blockchain accounts, which is applied to a blockchain node; the device comprises:

the transaction reading unit is used for reading a transaction identifier of a historical transaction related to target privacy data and identity information of an initiator of the historical transaction, wherein the transaction identifier is contained in the query transaction and is used for reading the transaction identifier of the historical transaction and the identity information of the initiator of the historical transaction when receiving the query transaction aiming at the target privacy data initiated by a query party;

the authority inquiry unit is used for determining a blockchain account of the initiator according to the identity information of the initiator and determining the inquiry authority of the inquirer for the target privacy data according to the inquiry authority recorded in the blockchain account;

and the data acquisition unit is used for acquiring the target privacy data and reading the acquired target privacy data into a trusted execution environment for decryption when the determined inquiry authority is allowed to be inquired so as to be acquired by the inquirer.

According to a fourth aspect of one or more embodiments of the present specification, a device for querying private data is provided, which is applied to a blockchain node; the device comprises:

the transaction reading unit is used for reading a transaction identifier of a historical transaction related to target privacy data and identity information of an initiator of the historical transaction, wherein the transaction identifier is contained in the query transaction and is used for the historical transaction when receiving the query transaction aiming at the target privacy data sent by a query party;

the first permission query unit is used for determining a blockchain account of the initiator according to the identity information of the initiator when the target privacy data is the historical transaction, and determining the query permission of the inquirer for the historical transaction according to the query permission recorded in the blockchain account;

the second permission query unit is used for reading a contract address of a service contract called by the historical transaction and contained in the query transaction when the target privacy data is other transaction related data different from the historical transaction, acquiring the service contract according to the contract address, and executing a permission control code defined in the service contract to determine the query permission of the query party for the target privacy data;

According to a fifth aspect of one or more embodiments herein, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of the first aspect by executing the executable instructions.

According to a sixth aspect of one or more embodiments herein, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method according to the second aspect by executing the executable instructions.

According to a seventh aspect of one or more embodiments of the present description, a computer-readable storage medium is proposed, on which computer instructions are stored, which instructions, when executed by a processor, implement the steps of the method according to the first aspect.

According to an eighth aspect of one or more embodiments of the present description, a computer-readable storage medium is proposed, on which computer instructions are stored, which instructions, when executed by a processor, implement the steps of the method according to the second aspect.

Drawings

FIG. 1 is a schematic diagram of creating an intelligent contract, provided by an exemplary embodiment.

FIG. 2 is a schematic diagram of a calling smart contract provided by an exemplary embodiment.

FIG. 3 is a schematic diagram of a call service contract provided by an exemplary embodiment.

Fig. 4 is a flowchart of a method for querying private data according to an exemplary embodiment.

Fig. 5 is a flowchart of another private data query method provided by an example embodiment.

Fig. 6 is a flowchart of another private data query method provided by an exemplary embodiment.

Fig. 7 is a flowchart of another private data query method provided by an example embodiment.

Fig. 8 is a schematic structural diagram of an apparatus according to an exemplary embodiment.

Fig. 9 is a block diagram of a device for querying private data based on blockchain accounts according to an exemplary embodiment.

Fig. 10 is a schematic structural diagram of another apparatus provided in an exemplary embodiment.

Fig. 11 is a block diagram of a query device for private data according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chain (Public Blockchain), private chain (PrivateBlockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participators joining the public chain can read the data record on the chain, participate in transaction, compete for accounting right of new blocks, and the like. Furthermore, each participant (i.e., node) is free to join and leave the network and perform related operations. Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.

Whether public, private, or alliance, may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking the ethernet as an example, the support user creates and invokes some complex logic in the ethernet network, which is the biggest challenge of ethernet to distinguish from bitcoin blockchain technology. The core of the ethernet plant as a programmable blockchain is the ethernet plant virtual machine (EVM), each ethernet plant node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

For example, as shown in fig. 1, after Bob sends a transaction containing information to create an intelligent contract to the ethernet network, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The "0 x6f8ae93 …" in fig. 1 represents the address of the contract, the data field of the transaction holds the byte code, and the to field of the transaction is empty. After agreement is reached between the nodes through the consensus mechanism, this contract is successfully created and can be invoked in subsequent procedures. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address, and the contract code is stored in the contract account. The behavior of the intelligent contract is controlled by the contract code. In other words, an intelligent contract causes a virtual account to be generated on a blockchain that contains a contract code and an account store (Storage).

As shown in fig. 2, still taking an ethernet house as an example, after Bob sends a transaction for invoking an intelligent contract to the ethernet house network, the EVM of a certain node may execute the transaction and generate a corresponding contract instance. The from field of the transaction in fig. 2 is the address of the account of the transaction initiator (i.e., Bob), the "0 x6f8ae93 …" in the to field represents the address of the smart contract called, and the value field is the value of tai-currency in the etherhouse, and the data field of the transaction holds the method and parameters for calling the smart contract. The intelligent contract is independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is completed, transaction certificates which cannot be tampered and cannot be lost are stored on the blockchain.

After executing Bob-initiated transaction, a node in the blockchain network generates corresponding receipt (receipt) data for recording receipt information related to the transaction. In this way, information regarding the results of the execution of the transaction may be obtained by querying the receipt of the transaction. Taking the ether house as an example, the receipt data obtained by the node executing the transaction may include the following:

a Result field indicating the execution Result of the transaction;

a Gas used field representing a Gas value consumed by the transaction;

l ogs field representing a log generated by the transaction, the log may further include a From field representing an account address of the initiator of the call, a To field representing an account address of the called object (such as a smart contract), a To field representing a subject of the log, a L og data field representing log data, etc.;

an Output field, representing the Output of the transaction.

Generally, receipt data generated after a transaction is executed is stored in a clear text form, so that anyone can see the contents of the receipt fields contained in the receipt data, and the setting and the capability of privacy protection are not provided. In some combined blockchain and TEE solutions, the entire content of the receipt data is stored on the blockchain as data requiring privacy protection in order to achieve privacy protection. The block chain is a data set organized by specific logics stored in a database of nodes. The physical carrier of the database, as described later, may be a storage medium, such as a persistent storage medium. In fact, only part of the receipt data may be sensitive, while other content is not sensitive, only privacy protection is required for the sensitive content, other content can be disclosed, and even in some cases, retrieval of part of the content may be required to drive implementation of relevant operations, and then implementing privacy protection for the part of the content will affect implementation of the retrieval operations.

The process of protecting the privacy of the user may be as shown in fig. 3:

step 302, the user a creates a transaction for invoking the service contract and sends the created transaction to the blockchain node.

User a may invoke a smart contract (i.e., a business contract) deployed on the blockchain by creating a transaction (including the account address of the invoked smart contract) to cause the blockchain node to execute the business contract to complete the corresponding business. For privacy protection, user a may encrypt the created transaction using digital envelope encryption that combines a symmetric encryption algorithm and an asymmetric encryption algorithm. Specifically, the transaction content is encrypted by using a symmetric encryption algorithm (i.e., the transaction content is encrypted by using a symmetric key used by itself), and then the symmetric key is encrypted by using a public key of an asymmetric encryption algorithm.

At step 304, the block link points execute the service contract.

After receiving the encrypted transaction, the blockchain node reads the transaction into the TEE, decrypts by using the private key of the asymmetric encryption algorithm to obtain a symmetric key, decrypts the transaction by using the symmetric key obtained by decryption to obtain transaction content, and then executes a service code of a service contract in the TEE.

At step 306, the block nodes store privacy data associated with the transaction.

In one aspect, the blockchain nexus, upon receiving the transaction (after consensus), issues the transaction (encrypted in the form of a digital envelope) onto the blockchain for crediting. On the other hand, after the block chain link point executes the transaction, the related data obtained by executing the transaction is encrypted and stored (issued to the block chain for storage or stored locally); where the transaction receipt corresponding to the transaction may be encrypted using a symmetric key used by user a and the contract status data obtained in response to executing the business contract in response to the transaction may be encrypted using a particular symmetric key internal to the TEE. In addition, data such as account attribute information of the user a, account attribute information of a service contract, and a contract code of the service contract may also be encrypted by using a specific symmetric key inside the TEE. The data encrypted by the block chain nodes all belong to the private data of the user A on the block chain.

In the above-described scenario of privacy protection, a user may need to share private data related to a service implemented by the user using a blockchain to some specific users for viewing, that is, the specific users may view private data related to a historical transaction initiated by the user. Then, query permissions may be set for the user's private data for other users that are allowed to query.

In an etherhouse or blockchain model derived based on the architecture of the etherhouse, the accounts may include external accounts, contract accounts, and the like. An external account is typically owned by the user (individual or organization), and is directly controlled by the user, also referred to as a user account; the contract account corresponds to the intelligent contract in the blockchain and is created by the user through the external account. The structure of each type of account is similar, and may include, for example, a Nonce field, a Balance field, a Code field, a Storage field, and so on. The value of the Nonce field of each account starts from 0, and the value of the Nonce field is sequentially increased along with the transaction initiated by the corresponding account, so that the Nonce values contained in each transaction initiated by the account are different, thereby avoiding replay attack. The Balance field is used to store the Balance. The Code field is used to store the contract Code of the intelligent contract (in practical applications, only the hash value of the contract Code is usually maintained in the Code field, so the Code field is also usually called the Code hash field), and thus the Code field of the external account is usually empty. The Storage field is used for storing the value of the account at the corresponding node in the state tree.

Of course, the account structure supported by the blockchain can be further expanded to meet the requirements of various application scenarios. Therefore, the meaning of the existing account field can be expanded or the field can be added, so that the query authority can be set for the privacy data of the user. For example, the Code field of the external account is used for recording the inquiry authority formulated by the corresponding user; or, the newly added field "permission" is used for recording the query authority formulated by the corresponding user.

Therefore, based on the above improvement on the account structure, the user can set up the inquiry authority of the privacy data related to the transaction initiated by the user in the own blockchain account (external account). In other words, the query authority of the private data is controlled by the user himself. The following describes a query scheme of the corresponding private data with reference to fig. 4. Fig. 4 is a flowchart of a method for querying private data based on a blockchain account according to an exemplary embodiment. As shown in fig. 4, the method applied to the blockchain node may include the following steps:

step 402, when receiving a query transaction aiming at target privacy data initiated by a query party, reading a transaction identifier of a historical transaction related to the target privacy data and identity information of an initiator of the historical transaction, wherein the transaction identifier is contained in the query transaction.

In this embodiment, a specific smart contract for identifying query transactions may be deployed on the blockchain. As an exemplary embodiment, the principle of identifying query transactions may be to treat any transaction received by a block node as a query transaction when the transaction is used to invoke the specified smart contract. For example, an administrator of the blockchain may previously deploy a distribution contract (e.g., initiate a transaction to create a smart contract) on the blockchain, the distribution contract configured with a contract address, and when the to field of the transaction received by the blockchain node records the contract address, the transaction may be determined to belong to the query transaction. Specifically, the contract address of the distribution contract is written into a preset address list, and when the address recorded in the to field of the received transaction belongs to the address list, it is determined that the received transaction belongs to the inquiry transaction. The address list may be recorded in a system contract (for recording the address list) or may be recorded in a chain code. Thus, when the inquiring party needs to inquire about the private data, the to field of the initiated transaction should record the contract address of the distribution contract as described above.

Or, the transaction types supported by the blockchain can be expanded to expand the transaction for inquiring the private data, namely, the inquiry transaction. For example, a type field is added to the transaction format, and when "inquiry" is recorded in the type field, it indicates that the transaction belongs to a query transaction. Therefore, when the inquiring party needs to inquire the private data, the type field of the created transaction should be written to "inquiry".

The transaction identifier of the historical transaction related to the target privacy data and the identity information of the initiator of the historical transaction, which are contained in the query transaction, can be recorded in the data field of the query transaction or any other existing or newly added fields.

Step 404, determining a blockchain account of the initiator according to the identity information of the initiator, and determining the query authority of the querier for the target privacy data according to the query authority recorded in the blockchain account.

In one embodiment, the query permissions may be formulated in the blockchain account in the form of a white list. For example, the initiator of the historical transaction may configure a white list in its own blockchain account, and the query authority of the user for the privacy data of the initiator recorded in the white list is allowed to be queried. Then, after determining the blockchain account of the initiator according to the identity information of the initiator included in the query transaction, the white list configured in the blockchain account can be read, and when the query party is recorded in the white list, the query authority of the query party for the target privacy data is determined to be allowed to be queried.

Further, the transaction types supported by the blockchain can be expanded to expand the transactions for updating the white list, i.e. updating the transactions. Then, when the initiator of the historical transaction needs to update the white list maintained in the own blockchain account, an update transaction for the white list can be initiated, and after receiving the update transaction, the blockchain nodes update the white list according to the update content of the white list contained in the update transaction. It should be noted that, for the update transaction, the above-mentioned digital envelope encryption mode in the embodiment shown in fig. 3 may also be adopted, and the decryption process is also similar thereto, and is not described again here.

In another embodiment, query permissions may be formulated in the blockchain account in the form of query conditions. For example, the initiator of the historical transaction may set a query condition for the private data in its own blockchain account. Then, after determining the blockchain account of the initiator according to the identity information of the initiator included in the query transaction, it may be determined whether the identity information meets the query condition recorded in the blockchain account, and when the identity information of the query party meets the query condition, it may be determined that the query authority of the query party for the target privacy data is allowed to be queried. The query condition may be flexibly set according to actual requirements, for example, the query authority of the querying party may be set as allowed query when the credit score of the querying party exceeds a preset credit threshold. Of course, the one or more embodiments of the present description are not so limited.

And step 406, when the determined inquiry authority is allowed to be inquired, acquiring the target privacy data, reading the acquired target privacy data into a trusted execution environment, and decrypting the data so as to obtain the data by the inquiring party.

In this embodiment, the private data is stored in an encrypted manner for the protection of the user private data described above. Therefore, when the inquiry authority of the inquiring party is determined to be allowed to inquire, the target privacy data is obtained (for example, the target privacy data can be obtained according to the transaction identifier), and the obtained target privacy data is read into the trusted execution environment to be decrypted so as to be obtained by the inquiring party. The decryption method used is different (because the encryption method is different) according to the data type contained in the target private data.

When the target privacy data includes the historical transaction and/or the transaction receipts of the historical transaction, as can be seen from the embodiment shown in fig. 3, the historical transaction and the transaction receipts of the historical transaction are encrypted by using the symmetric key used by the initiator of the historical transaction. Thus, after the historical transaction and/or transaction receipts for the historical transaction are obtained, the symmetric key used by the initiator (i.e., user a in the embodiment shown in fig. 3) may be obtained, and then the historical transaction and/or transaction receipts for the historical transaction may be decrypted within the TEE using the symmetric key. For the acquisition of the symmetric key used by the initiator, a symmetric key used for encrypting the historical transaction may be acquired first (the symmetric key is encrypted by a public key used by the initiator, that is, in the embodiment shown in fig. 3, a digital envelope is used for encryption), and the symmetric key is decrypted in the TEE by using a private key corresponding to the public key used by the initiator to obtain a decrypted symmetric key.

The symmetric key used by the initiator can be generated by the initiator through a symmetric encryption algorithm, or obtained by negotiation between the initiator and the block link node, or obtained by sending through a key management server. For example, the symmetric encryption algorithm may be DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, or the like. A public key used by the initiator is sent to the initiator through remote certification by the key management server, the TEE of the block chain node is established by the SGX framework, and a private key corresponding to the public key is sent to a ring (also called enclave) of the block chain node through remote certification by the key management server. And the asymmetric encryption algorithm for generating the public key and the private key may be, for example, RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), etc.

When the target privacy data includes at least one of account attribute information of the initiator of the historical transaction, account attribute information of the service contract, contract code of the service contract, and contract status data of the service contract, as can be seen from the embodiment shown in fig. 3, these privacy data are encrypted by using a specific symmetric key inside the TEE. Thus, after obtaining these private data, they may be decrypted within the TEE by the specific symmetric key of the blockchain node. And for a specific symmetric key in the TEE, the SGX architecture at the block chain link point is remotely certified and then sent by a key management server, or is obtained by negotiation between the block chain link point and other block chain nodes.

In this embodiment, similar to the above-mentioned manner of encrypting the historical transaction to protect privacy, when the inquiring party initiates the inquiry transaction, the inquiring party may also encrypt the created inquiry transaction by using the symmetric key used by itself, and encrypt the symmetric key by using the public key used by itself. Therefore, after receiving the query transaction, the blockchain node decrypts the symmetric key of the encrypted query transaction by using the private key corresponding to the public key used by the querying party in the TEE, and then decrypts the query transaction by using the symmetric key obtained by decryption to obtain the transaction content contained in the query transaction. After the target privacy data are obtained and decrypted, the block chain nodes can encrypt the decrypted target privacy data through the symmetric key of the inquiring party, so that the inquiring party can decrypt and check the target privacy data through the symmetric key used by the inquiring party, and the target privacy data are prevented from being leaked.

The sources of the symmetric key, the public key and the private key used for privacy protection for the inquiring party are similar to those described above, and are not described herein again. Of course, the asymmetric keys (public key and private key) used in the process may be the asymmetric keys used for privacy protection for the initiator.

In this embodiment, since the identity information of the initiator included in the query transaction is only the identity information declared by the query party, the identity information is not necessarily the actual identity information of the initiator of the historical transaction, that is, there is a risk that the query party falsifies the identity information of the initiator. Therefore, after determining that the query authority of the querying party is allowed to query, the blockchain node may obtain the historical transaction according to the transaction identifier (i.e., transaction ID, which is usually a hash value of the transaction) of the historical transaction included in the query transaction, so as to determine the identity information of the initiator of the historical transaction (i.e., the actual identity information of the initiator) according to the obtained historical transaction. When the determined identity information is inconsistent with the identity information of the initiator contained in the query transaction, the operation of acquiring the target privacy data is prohibited, so that the condition that the user privacy data is stolen by the inquirer through forging the identity information of the initiator can be effectively eliminated.

In this embodiment, when it is determined that the query right of the querying party is query prohibition, the step of verifying the identity information of the initiator by obtaining the historical transaction is not required. Since the checking step is unnecessary operation under the condition that the inquiry authority of the inquirer is the inquiry prohibition, the occupation of processing resources of the block chain nodes can be reduced, and the performance of the block chain nodes is improved. Meanwhile, when the inquiry authority of the inquirer is determined to be inquiry prohibition, contract receipt data for indicating that the inquirer prohibits inquiring target privacy data can be generated to be viewed by the inquirer.

As can be seen from the above technical solution, the query authority of the private data (related to the historical transaction) is controlled by the initiator of the historical transaction. In addition to this, the respective query permissions may be controlled by different users for different types of private data. Specifically, the inquiry authority of the historical transaction itself is controlled by the initiator of the historical transaction (i.e., the manner of control by the blockchain account of the initiator), and the inquiry authority of other transaction-related data different from the historical transaction is controlled by the service contract called by the historical transaction, i.e., by the deployer of the service contract. The following describes a query scheme of the corresponding private data with reference to fig. 5. Fig. 5 is a flowchart of a method for querying private data according to an exemplary embodiment. As shown in fig. 5, the method applied to the blockchain node may include the following steps:

step 502, when receiving a query transaction aiming at target privacy data sent by a query party, reading a transaction identifier of a historical transaction related to the target privacy data and identity information of an initiator of the historical transaction, wherein the transaction identifier is included in the query transaction.

Step 504, when the target privacy data is the historical transaction, determining a blockchain account of the initiator according to the identity information of the initiator, and determining a query right of the query party for the historical transaction according to a query right recorded in the blockchain account.

In this embodiment, the other transaction-related data may include at least one of: a transaction receipt corresponding to the historical transaction, account attribute information of an originator of the historical transaction, account attribute information of a business contract, a contract code of the business contract, contract status data of the business contract. Wherein the historical transaction itself is created by the initiator, so the inquiry authority of the historical transaction is controlled by the initiator; and other transaction-related data, which is distinguished from the historical transaction, is associated with (generated by or belonging to) the business contract invoked by the historical transaction, so that the query right of the other transaction-related data is controlled by the party deploying the business contract. Through the setting mechanism of the inquiry authority, the inquiry authority of the private data can be flexibly controlled.

It should be noted that, the implementation process of the step 504 may refer to the process of the step 404 in the embodiment shown in fig. 3, and is not described herein again.

Step 506, when the target privacy data is other transaction related data different from the historical transaction, reading a contract address of a service contract called by the historical transaction and included in the query transaction, acquiring the service contract according to the contract address, and executing an authority control code defined in the service contract to determine the query authority of the querying party for the target privacy data.

In the present embodiment, when developing a service contract, in addition to defining a service code in the service contract, an authority control code of private data related to a transaction invoking the service contract needs to be defined in the service contract for determining whether a querying party for the private data is allowed to query. Through the mode of defining the authority control code in the service contract, the association relationship can be established between the private data and the authority control code for controlling the inquiry authority of the private data, so that each service contract can control the private data related to the transaction for calling the service contract.

The development and deployment of business contracts can be accomplished by the roles of blockchain users, blockchain members, blockchain administrators, and the like. Taking a federation chain as an example, a member of the blockchain (or a user or an administrator of the blockchain) with accounting authority sets the authority control rule, and the authority control rule is defined in a service contract (service codes are also defined) in the form of an authority control code. After the development of the business contract is completed, the blockchain member can issue the business contract to the federation chain through any node device in the federation chain, and after the business contract is identified by member node devices (such as a plurality of authority node devices with accounting authority) specified by parts in the federation chain, the business contract is collected to a distributed database (namely a distributed ledger) of the federation chain. Based on the manner in which the service contract is deployed, the deployer of the service contract (i.e., the general user or general member with billing authority) may control whether others are permitted to query for private data associated with the transaction sent to the service contract (i.e., the transaction that invoked the service contract).

The consensus algorithm supported in the blockchain may include:

the first kind of consensus algorithm, namely the consensus algorithm that the node device needs to contend for the accounting right of each round of accounting period; consensus algorithms such as Proof of Work (POW), Proof of equity (POS), Proof of commission rights (DPOS), etc.;

the second kind of consensus algorithm, namely the consensus algorithm which elects accounting nodes in advance for each accounting period (without competing for accounting right); for example, a consensus algorithm such as a Practical Byzantine Fault Tolerance (PBFT) is used.

In a blockchain network employing a first type of consensus algorithm, node devices competing for billing rights can execute a transaction upon receipt. One of the node devices competing for the accounting right may win in the process of competing for the accounting right in the current round, and become an accounting node. The accounting node may package the received transaction with other transactions to generate a latest block and send the generated latest block or a block header of the latest block to other node devices for consensus.

In the block chain network adopting the second type of consensus algorithm, the node equipment with the accounting right is agreed before accounting in the current round. Thus, the node device, after receiving the transaction, may send the transaction to the accounting node if it is not the accounting node of its own round. For the accounting node of the current round, the transaction may be performed during or before packaging the transaction with other transactions to generate the latest block. After generating the latest block, the accounting node may send the latest block or a block header of the latest block to other node devices for consensus.

As described above, regardless of which consensus algorithm is used by the blockchain, the accounting node of the current round may pack the received transaction to generate the latest block, and send the generated latest block or the block header of the latest block to other node devices for consensus verification. If no problem is verified after other node equipment receives the latest block or the block header of the latest block, the latest block can be added to the tail of the original block chain, so that the accounting process of the block chain is completed. The transaction contained in the block may also be performed during the verification of a new block or block header from the accounting node by other nodes.

Based on the manner of deploying the service contracts for controlling the query authority, each service contract only controls the query authority of the private data related to the transaction for invoking itself. Therefore, when a user (as an inquiring party) initiates an inquiry transaction aiming at target privacy data related to historical transactions (initiated by any other user), the block chain node needs to determine a service contract for controlling the inquiry authority of the target privacy data, and then the service contract can be called to realize authority control.

And aiming at the mode that the block chain nodes invoke the service contracts to realize authority control, a distribution contract can be deployed on the block chain in advance for identifying whether the transaction received by the block chain nodes is a query transaction, and when the received transaction is the query transaction, corresponding service contracts are further invoked to execute authority control codes (which can be understood as the inquiry transaction is distributed to the corresponding service contracts). Specifically, on the basis of the distribution contract in the embodiment shown in fig. 4 described above, a distribution code for calling a service contract to execute the authority control code defined in the service contract may be further defined in the distribution contract. Therefore, when the inquiring party needs to inquire other transaction related data except the historical transactions, the inquiring transaction created by the inquiring party is the transaction for invoking the distribution contract; at the same time, the contract address of the business contract invoked by the historical transaction may be recorded in the query transaction. Then, when any transaction received by the block node is used for invoking a distribution contract, the any transaction can be used as a query transaction, and the distribution contract is invoked to execute the distribution code defined in the distribution contract, so that the corresponding service contract (i.e. the service contract invoked by the historical transaction) is further invoked to execute the authority control code according to the contract address contained in the query transaction. Taking an ether house as an example, the content of the to field in the query transaction created by the query party is a contract address of a distribution contract, and the content of the to field in the historical transaction, namely the contract address of a service contract called by the historical transaction, is also recorded in the query transaction.

The distribution contract may be designed as a system-level intelligent contract based on the distribution contract serving as a "distribution query transaction". Thus, development and deployment of distribution contracts may be accomplished by an administrator of the blockchain. Also taking a federation chain as an example, a manager with administrative authority develops distribution logic (calls a service contract according to a contract address of the service contract called by a historical transaction recorded in a query transaction) and defines the distribution logic in the distribution contract in the form of distribution code. After completing development of a distribution contract, an administrator may publish the distribution contract for deployment on a federation chain (similar to the process described above for deploying intelligent contracts).

In one case, the distribution contract may be deployed through the creation block of the block chain, that is, the distribution contract is deployed when the block chain is built, and the contract code of the distribution contract is recorded in the creation block. In another case, the distribution contract may be deployed in a subsequent process of building the blockchain; for example, during the subsequent use process, the administrator wants to add the authority query function. The administrator may then initiate a transaction to create a distribution contract to deploy the distribution contract onto the blockchain. Wherein the to field of the transaction is an empty string, the binary code for initializing the contract is specified in the data field, and the execution result of the code will be the contract code when the contract is called later.

In the technical scheme of the specification, besides the service contract is called by deploying the distribution contract to realize authority control, the distribution logic can be solidified into the chain code in the form of the distribution code and issued together with the chain code, so that the subsequent redeployment by an administrator is not needed, and the contract code is solidified in the chain code, so that the contract code is controllable, and the safety is effectively improved. In other words, the distribution of query transactions to the respective business contracts is accomplished by the block link points themselves, without having to do so by invoking intelligent contracts.

It should be noted that the type of the request initiated on the blockchain by the user accessing the blockchain may specifically refer to a transaction (transaction) adopted in a conventional blockchain. Of course, the type of the request initiated on the blockchain by the user accessing the blockchain may be other than a transaction, and other forms of instructions, messages, and the like with a standard data structure may also be used. In the following embodiments, a request initiated on a blockchain by a user accessing the blockchain will be described as an example of a transaction.

In this embodiment, the authority control rule defined in the form of the authority control code in the service contract can be flexibly set according to the actual requirement; of course, one or more embodiments of the present description are not limited to the specific content of the entitlement control rules. In one case, the identity information of the inquiring party can be used as the basis for the authority control. Correspondingly, when the inquiring party creates the inquiring transaction, the inquiring transaction should include the identity information of the inquiring party. For example, the identity information of the inquiring party is the account ID (i.e., account address) of the inquiring party, which may be recorded in the from field of the inquiry transaction. Further, the authority control rule may be set to allow the inquiring party to inquire the corresponding private data when the identity information of the inquiring party meets a specific condition. For example, when the inquiring party belongs to a pre-specified inquiring user set, the inquiring authority of the inquiring party can be determined as allowing to inquire, or when the credit score of the inquiring party exceeds a preset credit threshold value, the inquiring authority of the inquiring party can be determined as allowing to inquire, and the like. Therefore, when determining the query authority of the inquirer, the authority control code defined in the service contract can be executed to determine the query authority of the inquirer for the target private data according to the identity information of the inquirer.

In another case, the identity information of the inquiring party and the identity information of the initiator of the historical transaction can be jointly used as the basis for the authority control, and correspondingly, when the inquiring party creates the inquiring transaction, the inquiring transaction also includes the identity information of the initiator of the historical transaction. Then, the authority control rule may be set to allow the querying party to query the corresponding privacy data when the identity information of the querying party and the identity information of the initiator meet a specific condition. For example, an inquiry group and an inquired group are recorded in the authority control rule, and members belonging to the inquiry group allow to view the private data of the inquired group members; or directly recording the corresponding relation of other users which can be checked by each user in the authority control rule; or when the inquirer and the initiator belong to the same team, the inquiry authority of the inquirer can be determined as allowing inquiry, and the like. Therefore, when determining the query authority of the inquirer, the authority control code defined in the service contract can be executed to determine the query authority of the inquirer for the target private data according to the identity information of the inquirer and the identity information of the initiator.

In another case, the identity information of the initiator of the historical transaction may be used as a basis for the authority control, and accordingly, when the query transaction is created by the query party, the query transaction should include the identity information of the initiator of the historical transaction. Then, the authority control rule may be set to allow the inquiring party to inquire the corresponding privacy data when the identity information of the initiator meets a specific condition. For example, when the initiator belongs to a pre-specified set of users that can be queried, the query authority of the querying party can be determined as being allowed to be queried, or when the credit score of the initiator exceeds a preset credit threshold, the query authority of the querying party can be determined as being allowed to be queried, and the like. Therefore, when determining the query authority of the inquirer, the authority control code defined in the service contract can be executed to determine the query authority of the inquirer for the target privacy data according to the identity information of the initiator.

When the basis of the authority control includes the identity information of the initiator of the historical transaction, since the identity information of the initiator included in the query transaction is only the identity information declared by the query party, the identity information is not necessarily the actual identity information of the initiator of the historical transaction, that is, there is a risk that the query party falsifies the identity information of the initiator. Therefore, after determining that the query authority of the querying party is allowed to query, the blockchain node may obtain the historical transaction according to the transaction identifier (i.e., transaction ID, which is usually a hash value of the transaction) of the historical transaction included in the query transaction, so as to determine the identity information of the initiator of the historical transaction (i.e., the actual identity information of the initiator) according to the obtained historical transaction. When the determined identity information is inconsistent with the identity information of the initiator contained in the query transaction, the operation of acquiring the target privacy data is prohibited, so that the condition that the user privacy data is stolen by the inquirer through forging the identity information of the initiator can be effectively eliminated.

Similarly, the query transaction is created by the querying party, and the contract address of the business contract invoked by the historical transaction included in the query transaction is declared by the querying party, so that the contract address is not necessarily the contract address of the business contract actually invoked by the historical transaction, that is, there is a risk that the querying party falsifies the contract address. Therefore, after determining that the query authority of the querying party is allowed to query, the blockchain node may obtain the historical transaction according to the transaction identifier (i.e., the transaction ID, which is usually a hash value of the transaction) of the historical transaction included in the query transaction, so as to determine the contract address of the service contract actually invoked by the historical transaction according to the obtained historical transaction. And when the determined contract address is inconsistent with the contract address of the service contract called by the historical transaction included in the query transaction, the operation of acquiring the target privacy data is prohibited, so that the condition that the query party steals the user privacy data by forging the contract address can be effectively eliminated.

Taking an ether house as an example, data such as a hash value (serving as a transaction identifier) of a historical transaction, a contract address (i.e., to field content of the historical transaction) of a service contract called by the historical transaction, identity information (i.e., from field content of the historical transaction) of an initiator of the historical transaction, and the like can be recorded in a data (also written as input) field of an inquiry transaction, after determining that inquiry authority of an inquirer is allowed to inquire, a blockchain node can acquire the historical transaction (stored and verified on a blockchain) from the blockchain according to the hash value of the historical transaction, and read out content recorded in the from field of the historical transaction and to field content of the historical transaction, and if the read-out content of the from field is the same as the content of the from field declared in the inquiry transaction, further execute an operation of acquiring target private data; otherwise, the operation of acquiring the target privacy data is prohibited. Similarly, if the read to field content is the same as the to field content declared in the query transaction, the operation of obtaining the target privacy data can be further executed; otherwise, the operation of acquiring the target privacy data is prohibited.

And step 508, when the determined inquiry authority is allowed to inquire, acquiring the target privacy data, reading the acquired target privacy data into a trusted execution environment, and decrypting the data so as to acquire the data by the inquiring party.

In this embodiment, the process of encrypting and decrypting the query transaction and the private data is similar to the embodiment shown in fig. 4, and is not described herein again.

In this embodiment, when it is determined that the query right of the querying party is query prohibition, the step of verifying the identity information of the initiator or verifying the contract address of the service contract by obtaining the historical transaction does not need to be performed. Since the checking step is unnecessary operation under the condition that the inquiry authority of the inquirer is the inquiry prohibition, the occupation of processing resources of the block chain nodes can be reduced, and the performance of the block chain nodes is improved. Meanwhile, when the inquiry authority of the inquirer is determined to be inquiry prohibition, contract receipt data for indicating that the inquirer prohibits inquiring target privacy data can be generated to be viewed by the inquirer.

For ease of understanding, the process of the querier viewing the target private data is illustrated below in conjunction with FIGS. 6-7.

As shown in fig. 6, adapting to the scenario of fig. 3, after user a initiates a transaction to invoke a service contract, user a may share the transaction with user B, or user B may have a need to view the transaction. Then, the process of querying the historical transaction by the user B as the querying party may include the following steps:

user B creates a query transaction through the client used, step 602.

In this embodiment, the to field of the query transaction records the contract address of the distribution contract, while the hash value of the historical transaction (i.e., the transaction ID) and the content of the from field (the address of the originator of the historical transaction) may also be recorded in the data field (or other field) of the query transaction. The hash value of the historical transaction and the address of the initiator can be obtained by the user B and the user a through offline sharing, or obtained by any other method.

In step 604, user B encrypts the query transaction with the digital envelope via the client.

In step 606, user B initiates a query transaction to the block nodes via the client.

At step 608, the blockchain node decrypts the query transaction within the TEE.

The TEE is a trusted execution environment that is based on a secure extension of the CPU hardware and is completely isolated from the outside. TEE was originally proposed by Global Platform to address the secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications parallel to the operating system. The Trust Zone technology of ARM realizes the real commercial TEE technology at the earliest. Along with the rapid development of the internet, the security requirement is higher and higher, and more requirements are provided for the TEE by mobile equipment, cloud equipment and a data center. The concept of TEE has also been developed and expanded at a high rate. The concept now referred to as TEE has been a more generalized TEE than the concept originally proposed. For example, server chip manufacturers Intel, AMD, etc. have introduced hardware-assisted TEE in turn and enriched the concept and characteristics of TEE, which have gained wide acceptance in the industry. The mention of TEE now is more generally directed to such hardware assisted TEE techniques. Unlike the mobile terminal, the cloud access requires remote access, and the end user is not visible to the hardware platform, so the first step of using the TEE is to confirm the authenticity and credibility of the TEE. Therefore, the current TEE technology introduces a remote attestation mechanism which is endorsed by a hardware manufacturer (mainly a CPU manufacturer) and ensures that a user can verify the TEE state through a digital signature technology. Meanwhile, the security requirement which cannot be met by only safe resource isolation is also met, and further data privacy protection is also provided. Commercial TEE including Intel SGX, AMD SEV also provide memory encryption techniques, limiting trusted hardware within the CPU, with the data of the bus and memory being ciphertext to prevent snooping by malicious users. For example, TEE technology such as intel's software protection extensions (SGX) isolates code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for executing code. Applications running in the TEE are secured and are almost impossible to access by third parties.

Taking the Intel SGX technology as an example, SGX provides a bounding box, i.e., an encrypted trusted execution area in the memory, and the CPU protects data from being stolen. Taking a block link point using a CPU supporting SGX as an example, a part of an area EPC (enclosure Page Cache, Enclave Page Cache, or Enclave Page Cache) may be allocated in a memory by using a newly added processor instruction, and data therein is encrypted by an Encryption engine mee (memory Encryption engine) in the CPU. The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. Therefore, in the SGX, a user may not trust an operating System, a VMM (Virtual Machine Monitor), or even a BIOS (Basic Input Output System), and only need to trust the CPU to ensure that private data is not leaked.

In practical application, the key of the asymmetric encryption algorithm can be generated by the key management server. Through a remote certification mode, the key management server sends the private key to the blockchain node, specifically, the private key can be transmitted into a surrounding ring of the blockchain node. The blockchain node may comprise a plurality of enclosures, and the private key may be passed into a security enclosure of the enclosures; for example, the security enclosure may be a qe (queuing enclosure) enclosure, rather than an ae (application enclosure) enclosure. For asymmetrically encrypted public keys, they may be sent by the key management server to the user's client. Then, the client may encrypt the created transaction using a symmetric encryption algorithm, that is, encrypt the transaction content using the symmetric key of the symmetric encryption algorithm, and encrypt the symmetric key used in the symmetric encryption algorithm using the asymmetric encryption algorithm. Generally, a public key of an asymmetric encryption algorithm is used to encrypt a symmetric key used in a symmetric encryption algorithm. The above encryption mode is called digital envelope encryption, so that after the block chain nodes receive the encrypted transaction, the block chain nodes can firstly decrypt by using the private key of the asymmetric encryption algorithm to obtain the symmetric key of the symmetric encryption algorithm, and then decrypt by using the symmetric key of the symmetric encryption algorithm to obtain the transaction content.

At step 610, the block link points determine that the received transaction is a query transaction that invokes a distribution contract.

In this embodiment, the to field content of any transaction is read by the tile link point after the transaction is received. When the to field content is a contract address of a distribution contract, indicating that the transaction is for invoking a distribution contract, then the transaction may be determined to be a query transaction.

At step 612, the blockchain nexus determines the blockchain account of user a from the from field of the historical transaction.

And step 614, determining the query authority of the user B by the block chain link point according to the query authority recorded in the block chain account of the user A.

For example, the white list configured in the blockchain account of user a is shown in table 1:

private white list
	User B
User C
	User D
……

TABLE 1

As can be seen from table 1, the user B belongs to a member in the white list, and therefore, the query authority of the user B can be determined as being allowed to query.

Further, the transaction types supported by the blockchain can be expanded to expand the transactions for updating the white list, i.e. updating the transactions. For example, a type field is added to the transaction format, and when "update" is recorded in the type field, it indicates that the transaction belongs to an update transaction. Therefore, when the initiator of the historical transaction needs to update the white list maintained in the own blockchain account, the type field of the created transaction should be written into "update", and the update content for the white list can be recorded in the data field of the update transaction or any other existing or newly added fields. Then, when the initiator of the historical transaction needs to update the white list maintained in the own blockchain account, an update transaction for the white list can be initiated, and after receiving the update transaction, the blockchain nodes update the white list according to the update content of the white list contained in the update transaction. It should be noted that, for the update transaction, the above-mentioned digital envelope may also be used for encryption, and the decryption process is similar thereto, and is not described herein again.

And step 616, after the query authority of the user B is determined to be allowed to query, the block link points acquire historical transactions according to hash values of the historical transactions.

At step 618, the block link point reads the historical transaction into the TEE for decryption.

In the present embodiment, as can be seen from the embodiment shown in fig. 3, the private data is stored in an encrypted manner for the purpose of privacy protection. Meanwhile, the encryption modes adopted are different according to different data types contained in the private data. Therefore, after the target privacy data is acquired according to the hash value of the historical transaction, the acquired target privacy data is read into the TEE to be decrypted so as to be acquired by the inquiring party.

When the target privacy data comprises historical transactions, as can be seen from the embodiment shown in fig. 3 described above, the historical transactions are encrypted using the symmetric key used by user a. Therefore, after the historical transaction is obtained, the symmetric key used by the user a can be obtained, and then the historical transaction is decrypted by the symmetric key in the TEE, so that the historical transaction of the plaintext content is obtained. For the acquisition of the symmetric key used by the user a, a symmetric key used for encrypting the historical transaction (the symmetric key is encrypted by the public key used by the user a) may be acquired first, and the symmetric key is decrypted in the TEE by the private key corresponding to the public key used by the user a to obtain the decrypted symmetric key.

In step 620, the chunk node checks the from field of the historical transaction included in the query transaction.

In this embodiment, the address of the initiator recorded in the query transaction is filled in by user B, so the address of the initiator should be understood as the address of the initiator of the historical transaction declared by user B. However, the actual address of the initiator of the historical transaction is not necessarily the address of the initiator declared by the user B, i.e., there is a possibility that the user B forges. Therefore, under the condition that the query authority of the user B is determined to be allowed to be queried, the block chain node can further verify the address of the initiator of the historical transaction declared by the user B, and therefore the security of the private data is guaranteed.

For example, after determining that the query authority of the user B is allowed to query, the block link point may obtain a historical transaction (stored and certified on the block chain) from the block chain according to a hash value of the historical transaction, and read the content of a from field record of the historical transaction, and if the read from field content is the same as the content of a from field declared in the query transaction, the check is passed; otherwise, the check fails. It should be noted that, when it is determined that the query authority of the querying party is query prohibition, the checking step is unnecessary, and therefore the checking step is not required to be performed, so that the occupation of processing resources of the block chain nodes can be reduced, and the performance of the block chain nodes can be improved.

Further, after the inquiry authority of the user B is determined to be inquiry prohibition by using the service contract, a contract receipt about the inquiry prohibition target private data of the user B can be generated for the user B to check. Or returning a receipt of the query inhibition to the user B by the block chain node to inform the user B that the query authority is the query inhibition.

At step 622, the block link point encrypts the obtained historical transaction with the symmetric key of user B.

User B views the historical transactions, step 624.

In one embodiment, after encrypting the historical transaction, the blockchain node may generate an event containing the historical transaction and store the event in the blockchain log, and then the user B may use the client to retrieve the event through a callback mechanism of the blockchain, so as to view the historical transaction. After the historical transaction is obtained, the user B decrypts the historical transaction by adopting the symmetric key used by the user B through the client side, and then the historical transaction of the plaintext content can be obtained.

In another embodiment, the block link node may directly return the encrypted historical transaction to the client used by the user B after encrypting the historical transaction. Similarly, the user B decrypts the historical transaction by using the symmetric key used by the user B through the client, so as to obtain the historical transaction of the plaintext content.

It should be noted that the specific implementation process of the query authority of other transaction related data controlled by the initiator of the historical transaction (i.e. controlled by the blockchain account of the initiator) may refer to the above step 602-624, and the principle is similar, and will not be described herein again.

As shown in fig. 7, in the scenario of fig. 3, after the user a initiates a transaction for invoking a service contract, the user a may share other transaction-related data different from the transaction with the user B, or the user B may have a need to view the other transaction-related data. Then, the process of querying the target privacy data by the user B as the querying party may include the following steps:

user B creates a query transaction through the client used, step 702.

In this embodiment, the to field of the query transaction records the contract address of the distribution contract, while the hash value of the historical transaction (i.e., the transaction ID), the content of the from field (the address of the initiator of the historical transaction), and the content of the to field (the contract address of the service contract invoked by the historical transaction) may also be recorded in the data field (or other fields) of the query transaction. The hash value of the historical transaction, the address of the initiator and the contract address of the service contract can be obtained by the user B and the user A through offline sharing or any other method.

In step 704, user B encrypts the query transaction with the digital envelope via the client.

In step 706, user B initiates a query transaction to the block node via the client.

At step 708, the blockchain node decrypts the query transaction within the TEE.

In the present embodiment, the encryption and decryption processes of steps 704 and 708 are similar to those of steps 604 and 608 in the embodiment shown in fig. 6, and are not described herein again.

At step 710, the block link points determine that the received transaction is a query transaction that invokes a distribution contract.

At step 712, the block link points invoke distribution contracts.

In step 714, the distribution contract determines the business contract invoked by the historical transaction according to the to field of the historical transaction recorded in the query transaction.

At step 716, the distribution contract invokes the business contract.

At step 718, the business contract determines the query permissions of user B based on the from field of the query transaction and the from field of the historical transaction.

In this embodiment, the identity information of the inquiring party and the initiator of the historical transaction are taken as the basis of the permission control together. For example, the right control rule (defined in the service contract in the form of right control code) records the query group and the queried group, and the members belonging to the query group are allowed to view the private data of the members of the queried group; or directly recording the corresponding relation of other users which can be checked by each user in the authority control rule. Wherein, the account address is used as the identity information of the user. Then, the block node executes the authority control code defined in the service contract, so as to determine the inquiry authority of the user B according to the account address of the inquiring party (from field content of inquiry transaction) and the account address of the initiator of the historical transaction (from field content of historical transaction).

Step 720, the service contract returns the query authority of the user B to the block link point.

In step 722, after determining that the query authority of the user B is allowed, the block nodes check the from field and the to field of the historical transaction.

In this embodiment, the address of the initiator and the contract address of the service contract recorded in the query transaction are filled in by user B, so that the address of the initiator is understood to be the address of the initiator of the historical transaction declared by user B, and the contract address is understood to be the contract address of the service contract invoked by the historical transaction declared by user B. However, the address of the initiator actually used for the historical transaction is not necessarily the address of the initiator stated by the user B, and the contract address of the service contract actually invoked for the historical transaction is not necessarily the contract address stated by the user B, that is, there is a possibility that the user B forges. For example, the user B may deploy the service contract on the blockchain by the above-mentioned manner of deploying the service contract, and the authority control code defined in the service contract allows the user B to view the private data of the user a; then, the user B may fill in the contract address of the service contract invoked by the historical transaction initiated by the user a as the contract address of the service contract deployed by the user B. Therefore, under the condition that the query authority of the user B is determined to be allowed to be queried, the block chain node can further verify the address of the initiator of the historical transaction and the contract address declared by the user B, and therefore the security of the private data is guaranteed.

For example, after determining that the query authority of the user B is allowed to query, the block link point may obtain a history transaction (stored in the block chain) from the block chain according to a hash value of the history transaction, and read a content of a from field record of the history transaction and a to field content of the history transaction, and if the read from field content is the same as a content of a from field declared in the query transaction, may further perform an operation of obtaining the target privacy data; otherwise, the operation of acquiring the target privacy data is prohibited. Similarly, if the read to field content is the same as the to field content declared in the query transaction, the operation of obtaining the target privacy data can be further executed; otherwise, the operation of acquiring the target privacy data is prohibited.

It should be noted that, when it is determined that the query authority of the querying party is query prohibition, the checking step is unnecessary, and therefore the checking step is not required to be performed, so that the occupation of processing resources of the block chain nodes can be reduced, and the performance of the block chain nodes can be improved.

In step 724, the block link points obtain other transaction related data.

At step 726, the block link point reads other transaction related data into the TEE for decryption.

In the present embodiment, as can be seen from the embodiment shown in fig. 3, the private data is stored in an encrypted manner for the purpose of privacy protection. Meanwhile, the encryption modes adopted are different according to different data types contained in the private data. Thus, after the target privacy data is obtained (e.g., other transaction-related data may be obtained from the hash value of the historical transaction), the obtained target privacy data is read into the trusted execution environment for decryption to be obtained by the querying party.

When the target privacy data comprises transaction receipts for historical transactions, as can be seen from the embodiment shown in fig. 3 described above, the transaction receipts for historical transactions are each encrypted using a symmetric key used by the initiator of the historical transactions. Therefore, after the transaction receipts of the historical transaction are acquired, the symmetric key used by the user a can be acquired, and then the transaction receipts of the historical transaction can be decrypted by the symmetric key in the TEE. For the acquisition of the symmetric key used by the initiator, a symmetric key used for encrypting the historical transaction (the symmetric key is encrypted by the public key used by the user a) may be acquired first, and the symmetric key is decrypted in the TEE by the private key corresponding to the public key used by the user a to obtain the decrypted symmetric key.

When the target privacy data includes at least one of account attribute information of user a, account attribute information of the service contract, contract code of the service contract, contract status data of the service contract, these privacy data may be decrypted within the TEE by the specific symmetric key of the blockchain node.

For example, if 256 versions of keys derived from 0 to 255 are required, the keys derived from the versions of 0 to 255 can be generated by a decimal secret key (that is, the key derived from the decimal key 254 is 255 x key, that is, the key derived from the decimal key 254 is a hash key 254, the version of the key derived from the decimal key 254 is a version number of 0-255 x key, that is, the key derived from the decimal key 254 x key 254, that is, the key derived from the decimal key 254 x key, that is a version number of 0-255 x key, that is a hash key derived from the decimal key derived from 0-255 x key, that is a version number of 0-255 x key, and a hash key derived from the decimal key 254 x-255 x key, that is a version number of 0-255 x-1, that is a version number of 0-1, that is a hash key derived from the decimal key, that is a hash key derived from the decimal key derived from the decimal key derived from the key equivalent of 0-255 x-1, or a hash key of the hash key of 0 hash key.

Then a version of the derived key may be specified as the seal key described above to encrypt the private data. Further, the version of the seal key may be updated, and based on the above characteristics, the seal key should be updated from the low version key to the high version key, so that even if the low version key is leaked, the high version key cannot be deduced reversely, and sufficient data security is ensured.

At step 728, the block segment node encrypts other transaction related data using the symmetric key of user B.

User B views other transaction related data, step 730.

In an embodiment, after encrypting other transaction-related data, the blockchain link point may generate an event containing the other transaction-related data and store the event in the blockchain log, and then, the user B may use the client to obtain the event through a callback mechanism of the blockchain, so as to view the other transaction-related data. After acquiring other transaction related data, the user B decrypts the other transaction related data by using the symmetric key used by the user B through the client, so as to obtain other transaction related data of the plaintext content.

In another embodiment, the block link point may directly return the encrypted other transaction related data to the client used by the user B after encrypting the other transaction related data. Similarly, the user B decrypts the other transaction related data by using the symmetric key used by the user B through the client, and thus obtains the other transaction related data of the plaintext content.

Certainly, the query authority of the historical transaction may also be controlled by the service contract invoked by the historical transaction, that is, controlled by the deployment party of the service contract, and the specific implementation process of the control manner may refer to the above step 702 and step 730, which have similar principles and are not described herein again.

Therefore, according to the private data query scheme in the specification, the user A can share the private data between the user A and the user B without sharing the symmetric key used by the user A with the user B, so that the safety and the convenience are improved.

Corresponding to the above method embodiments, the present specification further provides an embodiment of a device for querying private data based on a blockchain account.

The embodiments of the private data query device in the present specification can be applied to electronic devices. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.

Referring to fig. 8, fig. 8 is a schematic block diagram of an apparatus according to an exemplary embodiment. As shown in fig. 8, at the hardware level, the apparatus includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810, but may also include hardware required for other services. The processor 802 reads a corresponding computer program from the non-volatile memory 810 into the memory 808 and then runs the computer program to form a private data query device based on the blockchain account on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 9, in a software implementation, the querying device applied to the blockchain node may include:

the transaction reading unit 901 is configured to, when receiving a query transaction for target privacy data initiated by a query party, read a transaction identifier of a historical transaction related to the target privacy data and identity information of an initiator of the historical transaction, which are included in the query transaction;

an authority query unit 902, configured to determine a blockchain account of the initiator according to the identity information of the initiator, and determine a query authority of the requestor for the target privacy data according to a query authority recorded in the blockchain account;

and the data acquisition unit 903, configured to, when the determined query permission is a permission query, acquire the target privacy data, read the acquired target privacy data into a trusted execution environment, and decrypt the read target privacy data so as to be acquired by the querying party.

Optionally, the method further includes:

the transaction identification unit 904, when any transaction received is used to invoke a specified smart contract, takes the any transaction as the inquiry transaction.

Optionally, the target privacy data includes at least one of:

the historical transaction, a transaction receipt corresponding to the historical transaction, account attribute information of an originator of the historical transaction, account attribute information of a business contract invoked by the historical transaction, a contract code of the business contract, contract status data of the business contract.

Optionally, the target privacy data comprises the historical transactions and/or the transaction receipts; the data obtaining unit 903 is specifically configured to:

obtaining a symmetric key used by the initiator;

decrypting the historical transaction and/or the transaction receipt with the symmetric key within the trusted execution environment.

Optionally, the data obtaining unit 903 is further configured to:

obtaining a symmetric key for encrypting the historical transaction, the symmetric key being encrypted by a public key used by the initiator;

and decrypting the symmetric key in the trusted execution environment through a private key corresponding to the public key used by the initiator to obtain a decrypted symmetric key.

Optionally, the public key used by the initiator is sent to the initiator by a key management server through a remote attestation, the trusted execution environment of the blockchain node is established by an SGX framework, and the private key corresponding to the public key is sent to the enclosure of the blockchain node by the key management server through the remote attestation.

Optionally, the target privacy data includes at least one of account attribute information of an initiator of the historical transaction, account attribute information of the business contract, contract code of the business contract, and contract status data of the business contract; the data obtaining unit 903 is specifically configured to:

decrypting the target privacy data within the trusted execution environment with a particular symmetric key of the blockchain node.

Optionally, the trusted execution environment of the blockchain node is established by an SGX architecture, and the specific symmetric key is sent by a key management server after the SGX architecture of the blockchain node is remotely certified, or is obtained by negotiating between the blockchain node and another blockchain node.

Optionally, the symmetric key for encrypting the inquiry transaction is encrypted by a public key used by the inquiring party;

after receiving the query transaction, the apparatus further comprises: the transaction decryption unit 905 is configured to decrypt the symmetric key used for encrypting the query transaction in the trusted execution environment through a private key corresponding to the public key used by the querying party, and decrypt the query transaction through the decrypted symmetric key to obtain transaction content included in the query transaction;

after decrypting the target privacy data, the apparatus further comprises: and a data encryption unit 906 that encrypts the decrypted target privacy data with the symmetric key of the inquiring party.

Optionally, after determining that the query right is allowed to be queried, the apparatus further includes:

a transaction obtaining unit 907 for obtaining the historical transaction according to the transaction identifier;

an identity determining unit 908, which determines identity information of an initiator of the historical transaction according to the obtained historical transaction;

an identity verification unit 909 that prohibits execution of the operation of acquiring the target privacy data when the determined identity information is not consistent with the identity information of the initiator included in the inquiry transaction.

Optionally, the method further includes:

and the privacy processing unit 910, when the determined inquiry authority is to prohibit inquiry, generating contract receipt data for indicating that the inquiring party prohibits inquiry of the target privacy data for being viewed by the inquiring party.

Optionally, a white list is configured in the blockchain account of the initiator, and the query permission of the user recorded in the white list for the private data of the initiator is allowed to be queried; the permission query unit 902 is specifically configured to:

and when the inquiring party is recorded in the white list, determining that the inquiring authority of the inquiring party for the target privacy data is allowed to be inquired.

Optionally, the method further includes:

a transaction receiving unit 911, which receives an update transaction for the white list initiated by the initiator;

an updating unit 912 configured to update the white list according to the update content of the white list included in the update transaction.

Optionally, a query condition for the private data of the initiator is recorded in the blockchain account of the initiator; the permission query unit 902 is specifically configured to:

and when the identity information of the inquirer meets the inquiry condition, determining the inquiry authority of the inquirer for the target privacy data as permission to inquire.

Correspondingly, the present specification also provides an embodiment of a device for querying private data.

Referring to fig. 10, fig. 10 is a schematic block diagram of an apparatus according to an exemplary embodiment. As shown in fig. 10, at the hardware level, the device includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile storage 1010, although other hardware required for services may be included. The processor 1002 reads a corresponding computer program from the non-volatile memory 1010 into the memory 1008 and then runs the computer program, thereby forming a query device of the private data on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 11, in a software implementation, the querying device for the private data is applied to a blockchain node, and may include:

the transaction reading unit 1101 is used for reading a transaction identifier of a historical transaction related to target privacy data and identity information of an initiator of the historical transaction, wherein the transaction identifier is contained in the query transaction and is used for reading the transaction identifier and the identity information of the initiator of the historical transaction;

a first permission query unit 1102, configured to determine, when the target privacy data is the historical transaction, a blockchain account of the initiator according to the identity information of the initiator, and determine, according to a query permission recorded in the blockchain account, a query permission of the query party for the historical transaction;

a second permission query unit 1103, configured to, when the target privacy data is other transaction related data different from the historical transaction, read a contract address of a service contract called by the historical transaction and included in the query transaction, obtain the service contract according to the contract address, and execute a permission control code defined in the service contract to determine a query permission of the querying party for the target privacy data;

and a data acquisition unit 1104, when the determined inquiry authority is to allow inquiry, acquiring the target privacy data, reading the acquired target privacy data into a trusted execution environment, and decrypting the data so as to acquire the data by the inquiring party.

Optionally, the other transaction-related data comprises at least one of:

a transaction receipt corresponding to the historical transaction, account attribute information of an originator of the historical transaction, account attribute information of the business contract, a contract code of the business contract, contract status data of the business contract.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A private data query method based on a block chain account is applied to a block chain node; the method comprises the following steps:

when receiving a query transaction aiming at target privacy data and initiated by a query party, reading identity information of an initiator of a historical transaction contained in the query transaction, wherein the historical transaction is related to the target privacy data;

determining a blockchain account of an initiator of the historical transaction according to the identity information, and determining the query authority of the inquirer for the target privacy data according to the query authority recorded in the blockchain account;

and when the determined inquiry authority is allowed to be inquired, reading the acquired target privacy data into the trusted execution environment maintained by the block link point for decryption, so as to be acquired by the inquirer.

2. The method of claim 1, further comprising:

when any transaction received is used to invoke a specified smart contract, the any transaction is taken as a query transaction.

3. The method of claim 1, the target privacy data comprising at least one of:

4. The method of claim 3, the target privacy data comprising the historical transactions and/or the transaction receipts; the reading of the acquired target privacy data into the trusted execution environment maintained by the block link point for decryption includes:

obtaining a symmetric key used by an initiator of the historical transaction;

5. The method of claim 4, the obtaining a symmetric key used by an initiator of the historical transaction, comprising:

obtaining a symmetric key for encrypting the historical transaction, the symmetric key being encrypted by a public key used by an initiator of the historical transaction;

and decrypting the symmetric key in the trusted execution environment through a private key corresponding to a public key used by an initiator of the historical transaction to obtain a decrypted symmetric key.

6. The method of claim 5, wherein a public key used by an initiator of the historical transaction is sent by a key management server to the initiator of the historical transaction through remote attestation, the trusted execution environment is established by an SGX framework, and a private key corresponding to the public key is sent by the key management server to a bounding box of the blockchain node through remote attestation.

7. The method of claim 3, the target privacy data comprising at least one of account attribute information of an initiator of the historical transaction, account attribute information of the business contract, contract code of the business contract, contract status data of the business contract; the reading of the acquired target privacy data into the trusted execution environment maintained by the block link point for decryption includes:

decrypting the target private data within the trusted execution environment with a symmetric key of the blockchain node.

8. The method of claim 7, wherein the trusted execution environment is established by an SGX architecture, and the symmetric key is sent by a key management server after the SGX architecture of the blockchain node is remotely certified, or is negotiated between the blockchain node and other blockchain nodes.

9. The method of claim 1, a symmetric key that encrypts the query transaction is encrypted by a public key used by the querying party;

after receiving the query transaction, the method further comprises: decrypting the symmetric key for encrypting the query transaction by a private key corresponding to the public key used by the inquiring party in the trusted execution environment, and decrypting the query transaction by the symmetric key obtained by decryption to obtain transaction content contained in the query transaction;

after decrypting the target privacy data, the method further comprises: and encrypting the decrypted target privacy data through the symmetric key of the inquiring party.

10. The method of claim 1, wherein the query transaction includes a transaction identification of the historical transaction; the method further comprises the following steps:

acquiring the historical transaction according to the transaction identifier;

determining identity information of an initiator of the historical transaction according to the acquired historical transaction;

and when the determined identity information is inconsistent with the identity information of the initiator of the historical transaction contained in the query transaction, prohibiting executing the operation of acquiring the target privacy data.

11. The method of claim 1, further comprising:

and when the determined query authority is the query prohibition, generating contract receipt data for showing that the inquirer prohibits querying the target privacy data so as to be viewed by the inquirer.

12. The method of claim 1, wherein a white list is configured in a blockchain account of an initiator of the historical transaction, and a query right of a user for privacy data of the initiator of the historical transaction recorded in the white list is allowed; the determining the query authority of the querier for the target privacy data according to the query authority recorded in the blockchain account includes:

13. The method of claim 12, further comprising:

receiving an update transaction aiming at the white list initiated by an initiator of the historical transaction;

and updating the white list according to the updating content of the white list contained in the updating transaction.

14. The method of claim 1, wherein a query condition for privacy data of an initiator of the historical transaction is recorded in a blockchain account of the initiator of the historical transaction; the determining the query authority of the querier for the target privacy data according to the query authority recorded in the blockchain account includes:

15. The method of claim 1, wherein the query transaction includes a transaction identification of the historical transaction; the method further comprises the following steps:

and acquiring the target privacy data according to the transaction identifier.

16. A method for inquiring private data is applied to a block chain node; the method comprises the following steps:

receiving query transaction aiming at target privacy data sent by a query party, and determining the data type of the target privacy data;

when the target privacy data comprise historical transactions related to the target privacy data, reading identity information of an initiator of the historical transactions contained in the inquiry transaction, determining a blockchain account of the initiator of the historical transactions according to the identity information, and determining inquiry authority of the inquirer for the historical transactions according to inquiry authority recorded in the blockchain account; when the target privacy data comprises other transaction related data different from the historical transaction, reading a contract address of a business contract called by the historical transaction and contained in the inquiry transaction, and calling the business contract according to the contract address to execute an authority control code defined in the business contract so as to determine the inquiry authority of the inquirer for the other transaction related data；

17. The method of claim 16, the other transaction-related data comprising at least one of:

18. The method of claim 16, wherein a business code defined in the business contract is executed if a block link point responds to the historical transactions.

19. The method of claim 16, after determining that the querying authority of the querying party for the other transaction-related data is query permission, the method further comprises:

reading a transaction identifier of the historical transaction contained in the query transaction, and acquiring the corresponding historical transaction according to the transaction identifier;

determining a contract address of an acquired business contract actually called by the historical transaction;

and when the determined contract address is inconsistent with the contract address contained in the query transaction, prohibiting the operation of acquiring the target privacy data.

20. The method of claim 1, further comprising:

when any transaction received is used to invoke a distribution contract, the any transaction is treated as a query transaction.

21. The method of claim 20, the invoking the service contract according to the contract address to execute the entitlement control code defined in the service contract, comprising:

and calling the distribution contract to execute the distribution code defined in the distribution contract so as to call the service contract to execute the authority control code defined in the service contract according to the contract address.

22. The method of claim 20, wherein the distribution code defined in the distribution contract is recorded in a founder block of a blockchain.

23. The method of claim 16, where the target privacy data comprises the historical transaction and/or a transaction receipt corresponding to the historical transaction, the reading the acquired target privacy data into a trusted execution environment maintained by the blockchain node for decryption, comprising:

obtaining a symmetric key used by an initiator of the historical transaction;

24. The method of claim 23, the obtaining a symmetric key used by an initiator of the historical transaction, comprising:

25. The method of claim 24, wherein a public key used by an initiator of the historical transaction is sent by a key management server to the initiator of the historical transaction through remote attestation, the trusted execution environment is established by an SGX framework, and a private key corresponding to the public key is sent by the key management server to a bounding box of the blockchain node through remote attestation.

26. The method of claim 16, where the target privacy data includes at least one of account attribute information of an initiator of the historical transaction, account attribute information of the business contract, contract code of the business contract, and contract state data of the business contract, the reading of the obtained target privacy data into a trusted execution environment maintained by the block link point for decryption, comprising:

27. The method of claim 26, wherein the trusted execution environment is established by an SGX architecture, and the symmetric key is sent by a key management server after the SGX architecture of the blockchain node is remotely certified, or is negotiated between the blockchain node and other blockchain nodes.

28. The method of claim 16, a symmetric key that encrypts the query transaction is encrypted by a public key used by the querying party;

29. The method of claim 16, wherein the query transaction includes a transaction identification of the historical transaction; the method further comprises the following steps:

acquiring the historical transaction according to the transaction identifier;

30. The method of claim 16, further comprising:

31. The method of claim 16, wherein a white list is configured in the blockchain account of the initiator of the historical transaction, and the query authority of the user recorded in the white list for the privacy data of the initiator of the historical transaction is allowed; the determining the query authority of the querying party for the historical transaction according to the query authority recorded in the blockchain account includes:

and when the inquiring party is recorded in the white list, determining that the inquiring authority of the inquiring party for the historical transaction is allowed to be inquired.

32. The method of claim 31, further comprising:

33. The method of claim 16, wherein a query condition for privacy data of an initiator of the historical transaction is recorded in a blockchain account of the initiator of the historical transaction; the determining the query authority of the querying party for the historical transaction according to the query authority recorded in the blockchain account includes:

and when the identity information of the inquiring party meets the inquiring condition, determining that the inquiring authority of the inquiring party for the historical transaction is allowed to be inquired.

34. The method of claim 16, wherein the query transaction includes a transaction identification of the historical transaction; the method further comprises the following steps:

and acquiring the target privacy data according to the transaction identifier.

35. A private data inquiry device based on a block chain account is applied to a block chain node; the device comprises:

the transaction reading unit is used for reading identity information of an initiator of historical transactions contained in query transactions when the query transactions aiming at target privacy data and initiated by a query party are received, wherein the historical transactions are related to the target privacy data;

the authority inquiry unit is used for determining a blockchain account of an initiator of the historical transaction according to the identity information and determining inquiry authority of the inquirer for the target privacy data according to the inquiry authority recorded in the blockchain account; and the data acquisition unit reads the acquired target private data into the trusted execution environment maintained by the block link point to be decrypted when the determined inquiry authority is allowed to be inquired, so that the target private data is acquired by the inquirer.

36. A private data query device is applied to a block chain node; the device comprises:

the transaction reading unit is used for receiving inquiry transactions aiming at target privacy data sent by an inquiry party and determining the data type of the target privacy data;

the authority inquiry unit is used for reading identity information of an initiator of the historical transaction contained in the inquiry transaction when the target privacy data comprises the historical transaction related to the target privacy data, determining a blockchain account of the initiator of the historical transaction according to the identity information, and determining inquiry authority of the inquirer for the historical transaction according to the inquiry authority recorded in the blockchain account; when the target privacy data comprises other transaction related data different from the historical transaction, reading a contract address of a business contract called by the historical transaction and contained in the inquiry transaction, and calling the business contract according to the contract address to execute an authority control code defined in the business contract so as to determine the inquiry authority of the inquirer for the other transaction related data；

And the data acquisition unit reads the acquired target private data into the trusted execution environment maintained by the block link point to be decrypted when the determined inquiry authority is allowed to be inquired, so that the target private data is acquired by the inquirer.

37. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-34 by executing the executable instructions.

38. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 34.