CN110033265B

CN110033265B - Method, node and storage medium for implementing privacy protection in block chain

Info

Publication number: CN110033265B
Application number: CN201910122598.4A
Authority: CN
Inventors: 刘琦; 魏长征; 闫莺
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-02-19
Filing date: 2019-02-19
Publication date: 2020-09-11
Anticipated expiration: 2039-02-19
Also published as: CN110033265A

Abstract

One or more embodiments of the present specification provide a method, node, and storage medium for implementing privacy protection in a blockchain, where the method may include: the first block chain link point executes the transaction received from the client to obtain receipt data; when the first block link point determines that the transaction is a private transaction, setting corresponding access conditions for receipt data when the receipt data is stored; the first blockchain node determines that the access condition is satisfied when responding to an access request for the receipt data.

Description

Method, node and storage medium for implementing privacy protection in block chain

Technical Field

One or more embodiments of the present specification relate to the field of blockchain technology, and in particular, to a method, node, and storage medium for implementing privacy protection in a blockchain.

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 nodes in these blockchain networks sometimes need to be increased.

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.

In terms of addressing privacy, a Trusted Execution Environment (TEE) is another approach. The TEE can function as a black box in hardware, codes and data executed in the TEE cannot be peeped by an operating system layer, and the TEE can be operated only through an interface predefined in the codes. 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, efficiency loss does not exist in the calculation process, and therefore the safety and privacy of a block chain can be improved to a great extent on the premise of small performance loss by combining 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), ARMTrustzone (Trusted zone), and AMD PSP (Platform Security Processor).

Disclosure of Invention

In view of the above, one or more embodiments of the present specification provide a method, node, and storage medium for implementing privacy protection in a blockchain.

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, there is provided a method for implementing privacy protection in a blockchain, including:

the first block chain link point executes the transaction received from the client to obtain receipt data;

when the first block link point determines that the transaction is a private transaction, setting corresponding access conditions for receipt data when the receipt data is stored;

the first blockchain node determines that the access condition is satisfied when responding to an access request for the receipt data.

According to a second aspect of one or more embodiments of the present specification, there is provided a node in a blockchain for implementing privacy protection, including:

an execution unit for executing the transaction received from the client, resulting in receipt data;

the setting unit is used for setting corresponding access conditions for the receipt data when the receipt data is stored when the transaction is determined to be a private transaction;

a response unit to determine that the access condition is satisfied when responding to an access request for the receipt data.

According to a third aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first aspect.

Drawings

Fig. 1 is a flowchart of a method for implementing privacy protection in a blockchain according to an exemplary embodiment.

FIG. 2 is a schematic diagram of a transaction scenario provided by an exemplary embodiment.

Fig. 3 is a block diagram of a node in a blockchain for implementing privacy protection 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 federation chains, corresponding receipt (receipt) data may be generated after a transaction is performed for recording receipt information related to the transaction. For example, the receipt data from a node performing a transaction may include the following fields:

a blockHash field representing a hash value of the block where the transaction is located;

a block number field indicating the serial number of the block where the transaction is located;

a transactionHash field representing a hash value of the transaction;

a transactionIndex field indicating the sequence number of the transaction in the block in which the transaction is located;

a from field indicating an account address of the transaction generator;

a To field representing the account address of the transaction object (the To field is null when the transaction is used To create a smart contract);

a controlAddress field that represents an address of the created intelligent contract when the transaction is used to create the intelligent contract, and is otherwise null;

logs field, representing the log of the transaction.

When the node executes each transaction contained in a certain block, the corresponding receipt data can be generated after each transaction is executed, and the node can organize the receipt data corresponding to each transaction contained in the block according to a predefined tree structure and processing logic to form a receipt tree. By organizing the generated receipt tree, the corresponding query or verification efficiency can be greatly improved when the receipt data is queried or verified. For example, in the ether house, the receipt tree is organized by using an mpt (media Patricia tree) structure, where a leaf of the receipt tree is a hash value of receipt data corresponding to each transaction included in the block, and a receipt tree root (receiptRoot) is a root hash sequentially generated upward according to the hash value of the receipt data at the leaf. Of course, other types of tree structures may be used in other blockchain networks.

The following describes an implementation process of an embodiment of a method for implementing privacy protection in this specification with reference to fig. 1:

in step 102, the first block link point executes the transaction received from the client to obtain receipt data.

The transaction may be submitted by the client to the first blockchain node. For example, after the user generates the transaction at the client through the corresponding account, the transaction is submitted to the first blockchain node through the client. Taking fig. 2 as an example, the first tile nexus contains a transaction/query interface that can interface with a client so that the client can submit a transaction to the first tile nexus.

After the first block link point executes the transaction, in addition to obtaining the corresponding transaction execution result, receipt data is generated, and the receipt data is in a plaintext form, namely the plaintext receipt data.

Based on different privacy protection requirements, transactions can be divided into plaintext transactions of plaintext type and privacy transactions of privacy type. A type field may be added to the transaction so that the first blockchain node can identify the transaction type as either a clear text transaction or a private transaction based thereon. In the related art, such as in an ethernet network, transactions typically include fields to, value, data, and the like. On the basis of the related technology, the embodiment adds a type field, for example, characterized as a type field, in the transaction, and indicates the type of the related transaction based on the value of the type field; for example, when the type field is the first value, it indicates that the related transaction is a plaintext transaction, and when the type field is the second value, it indicates that the related transaction is a privacy transaction.

All contents of the plaintext transaction are in a plaintext form, namely, each field of the transaction is in a plaintext form, so that each field of the plaintext transaction can be directly read by the first block link point to implement related processing; meanwhile, the plaintext transaction is packed into blocks in plaintext form, and then recorded in a blockchain in plaintext form. Except that the type field of the privacy transaction is in a plaintext form, other fields are in a ciphertext form, so that on one hand, the transaction type of the first block chain link point can be quickly identified under the condition that decryption is not needed, differential processing is implemented on the plaintext transaction and the privacy transaction, on the other hand, the first block chain link point can be decrypted and read only by an object with a secret key through the ciphertext form, leakage of transaction information is avoided, the privacy transaction is packaged into blocks in the ciphertext form, and then the privacy transaction is recorded in the block chain in the ciphertext form.

All transactions in the etherhouse network are clear text transactions. And the first block link point can expand a mixed processing scheme which takes clear text transaction and privacy transaction into account on the basis. For example, as shown in fig. 2, the first chunk node may be divided into a regular execution environment and a trusted execution environment, the transaction submitted by the client first enters a "transaction/query interface" in the regular execution environment for type identification (for example, identifying the type field described above), the identified clear-text transaction is left in the regular execution environment for processing, and the identified private transaction is transferred to the trusted execution environment for processing. When the first blockchain node encrypts the plaintext receipt data in the trusted execution environment, in order to ensure that the encryption operation is smoothly implemented, in some scenarios, the plaintext transaction can be transmitted into the trusted execution environment to be executed, and the distinction from the private transaction is only that the plaintext transaction does not need to be decrypted and the corresponding plaintext execution result does not need to be encrypted.

When the plain text transaction is processed in the conventional execution environment, the whole processing process completely adopts a plain text mode, namely the plain text receipt data is obtained after the plain text transaction is processed by the first block link point, and the plain text receipt data is directly stored in the conventional execution environment. The trusted execution environment and the conventional execution environment are isolated from each other, the private transaction is in an encrypted state (except the type field) before entering the trusted execution environment, and the private transaction is decrypted into the plaintext transaction content in the trusted execution environment, so that the plaintext transaction content can be efficiently processed in the trusted execution environment on the premise of ensuring data security, and corresponding plaintext receipt data is generated in the trusted execution environment; further, when storing the plaintext receipt data, the plaintext receipt data needs to be encrypted into corresponding ciphertext receipt data, and then stored in a conventional execution environment, for example, the storage location of the plaintext receipt data corresponding to the plaintext transaction may be the same as the "packing + storage" module shown in fig. 2.

The transactions in this specification may be used to implement relatively simple processing logic, such as transfer logic similar to that of the related art. In this case, the clear text transaction or the privacy transaction can be independent of the intelligent contract.

The transactions in this specification may also be used to implement relatively complex processing logic, which may be implemented here by means of the smart contracts described above. Taking the ethernet house as an example, the support user creates and/or invokes some complex logic in the ethernet house network, which is the biggest challenge of the ethernet house to distinguish from the 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.

In one embodiment, the intelligent contracts of the present description may be divided into plaintext contracts of a plaintext type, privacy contracts of a privacy type. The contract code and the contract state of the plaintext contract are both stored at the node in plaintext form, and the contract code and the contract state of the privacy contract are both stored at the node in ciphertext form, so that the privacy contract has relatively higher privacy. When a transaction is used to create and/or invoke a smart contract, the smart contract may be considered to correspond to the transaction.

Since the first blockchain node processes the plaintext transaction outside the trusted execution environment and directly stores the plaintext execution result (such as the changed contract state) obtained by the processing into the external storage space, when the plaintext transaction is used for creating the intelligent contract, the intelligent contract is necessarily stored in the external storage space in the plaintext form, and thus the intelligent contract is necessarily a plaintext contract. Meanwhile, when the intelligent contract is called by the plaintext transaction, the intelligent contract called by the plaintext transaction can only be the plaintext contract because the privacy contract can be decrypted only in the trusted execution environment.

The first tile chain node may decrypt the privacy transaction in a Trusted Execution Environment (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 an enclosure (also called enclave), that is, an encrypted trusted execution area in memory, and a CPU protects data from being stolen. Taking the example that the first block link point adopts a CPU supporting SGX, a part of an area EPC (enclosure Page Cache, Enclave Page Cache, or Enclave Page Cache) may be allocated in the 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 private data can be encrypted and then transmitted to the enclosure in a ciphertext form, and the corresponding secret key is transmitted to the enclosure through remote certification. Then, the operation is performed by using the data under the encryption protection of the CPU, and the result is returned in a ciphertext form. In this mode, not only can the powerful calculation be utilized, but also data leakage is not worried about.

Because the privacy transaction is executed in the TEE, the intelligent contract corresponding to the privacy transaction can be the privacy contract, for example, the privacy transaction can create the intelligent contract in the TEE, and the contract code and the contract state of the intelligent contract can be encrypted in the TEE, so that the corresponding privacy contract is created; for another example, a privacy contract may be invoked for a privacy transaction, the privacy contract may be decrypted and executed in the TEE, and the contract state updated after execution may be updated and re-encrypted for storage; for another example, a private transaction may invoke a plaintext contract, which is executed in the TEE, with the updated contract state still stored in plaintext form.

Assuming that the above-described private transaction is generated at a certain client, the client may first generate clear text transaction content, and then encrypt the clear text transaction content with a key. The encryption can adopt symmetric encryption or asymmetric encryption. Accordingly, the first tile chain node may decrypt the private transaction with the corresponding key to obtain clear text transaction content. If the client encrypts the plaintext transaction content using a symmetric encryption scheme, i.e., using a symmetric key of a symmetric encryption algorithm, the first chunk node may decrypt the private transaction using the symmetric key of the symmetric encryption algorithm, accordingly. The encryption algorithm used for symmetric encryption is, for example, DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc. The symmetric key of the symmetric encryption algorithm may be generated by the generator of the privacy transaction, determined by the client and the first blockchain node negotiation, or sent by the key management server, for example.

If the plaintext transaction contents are encrypted in an asymmetric encryption manner, i.e. by using the public key of the asymmetric encryption algorithm, the first chunk node can decrypt the private transaction by using the private key of the asymmetric encryption algorithm correspondingly. Examples of asymmetric encryption algorithms are RSA, Elgamal, knapsack Algorithm, Rabin, D-H, ECC (elliptic curve encryption Algorithm), etc. The key of the asymmetric encryption algorithm may be, for example, a pair of a public key and a private key generated by the first chunk node, and the public key is sent to the client in advance, so that the client may encrypt the plaintext transaction content with the public key.

The key of the asymmetric encryption algorithm may also be generated by a key management server. Through a remote certification mode, the key management server sends the private key to the first blockchain node, and specifically, the private key can be transmitted into a surrounding ring of the first blockchain node. The first block link point 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, the client may be sent by a key management server. The client can encrypt the plaintext transaction content with the public key, and accordingly, the first blockchain node can decrypt the privacy transaction with the private key to obtain the plaintext transaction content contained in the privacy transaction.

The client can also adopt a mode of combining symmetric encryption with asymmetric encryption. For example, the client encrypts the plaintext transaction content by using a symmetric encryption algorithm, that is, encrypts the plaintext transaction content by using a symmetric key of the symmetric encryption algorithm, and encrypts a symmetric key used in the symmetric encryption algorithm by using an 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. Therefore, after the first block chain node receives the encrypted transaction, the first block chain node 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 plaintext transaction content.

For example, the key management server may send the private key of the asymmetric cryptographic algorithm to the enclosure of the first blockchain node and send the private key of the asymmetric cryptographic algorithm to the client through remote attestation. Therefore, the client can encrypt the plaintext transaction content by using the symmetric key of the symmetric encryption algorithm, that is, encrypt the plaintext transaction content by using the symmetric key of the symmetric encryption algorithm, and encrypt the symmetric key used in the symmetric encryption algorithm by using the public key of the asymmetric encryption algorithm. Furthermore, the client may send the private transaction and an encryption private key (obtained by encrypting a symmetric key adopted in the symmetric encryption algorithm with a public key of the asymmetric encryption algorithm) to the first blockchain node. After the first block link node receives the private transaction and the encrypted private key, the encrypted private key can be decrypted by using the private key of the asymmetric encryption algorithm to obtain a symmetric key of the symmetric encryption algorithm, and then the private transaction is decrypted by using the symmetric key of the symmetric encryption algorithm to obtain the plaintext transaction content. The encryption method is generally called digital envelope encryption.

And after the first block chain link point decrypts the private transaction, the plaintext transaction content is obtained. The clear text transaction content may contain code of the intelligent contract for creating the intelligent contract in the blockchain; the clear text transaction content may contain a contract address of a certain intelligent contract that has been created in the blockchain for invoking the intelligent contract.

Whether used to create or invoke an intelligent contract, a first block link point may pass code that executes the intelligent contract to complete a transaction. The first block link point may execute code of the intelligent contract in a trusted execution environment. When the code of the intelligent contract is positioned in the privacy transaction, the first block chain node decrypts the privacy transaction to obtain the plaintext transaction content, wherein the plaintext transaction content comprises the code of the intelligent contract in the plaintext; when the intelligent contract is created in advance and the privacy transaction is used for invoking the intelligent contract, if the intelligent contract is stored in advance in an encrypted manner by the first block link point, the first block link point can read the code of the intelligent contract in the encrypted text into the trusted execution environment and decrypt the code of the intelligent contract in the clear text. Multiple nested structures can be realized among the intelligent contracts; for example, the code in the intelligent contract 1 calls the intelligent contract 2, while the code in the intelligent contract 2 points to the contract address 3 generated by creating the intelligent contract code, so that when the privacy transaction calls the code in the intelligent contract 1, the intelligent contract code in said contract address 3 is indirectly called.

When the privacy transaction is used for creating the intelligent contract, the privacy transaction comprises the code of the intelligent contract, and the first block link point can decrypt the privacy transaction in the trusted execution environment to obtain the code of the intelligent contract contained in the privacy transaction and further execute the plain text code in the trusted execution environment. When the privacy transaction is used to invoke a privacy-type smart contract, the first blockchain node may decrypt the smart contract in the trusted execution environment to obtain corresponding plaintext code, and then execute the plaintext code in the trusted execution environment. When the privacy transaction is used to invoke a plaintext-type smart contract, the first blockchain node directly reads the plaintext code of the smart contract and executes the plaintext code in the trusted execution environment. Specifically, the first block link point may allocate a part of the area EPC in the memory by using a processor instruction newly added in the CPU, and encrypt the plaintext code by using an encryption engine MEE in the CPU and store the plaintext code in the EPC. The encrypted content in the EPC enters the CPU and is decrypted into plaintext. And in the CPU, the plaintext codes are operated to finish the execution process.

In SGX technology, the EVM may be loaded into the enclosure by executing the plaintext code of the intelligent contract. In the remote certification process, the key management server can calculate a hash value of a local EVM code, compare the hash value with the hash value of the EVM code loaded in the first block chain link point, and correctly use a comparison result as a necessary condition for passing the remote certification, thereby completing measurement of the code loaded on the SGX enclosure of the first block chain node. Measured, the correct EVM can execute the intelligent contract code in the SGX.

And 104, when the first block link point determines that the transaction is a private transaction, setting corresponding access conditions for the receipt data when the receipt data is stored.

In step 106, the first blockchain node determines that the access condition is satisfied when responding to an access request for the receipt data.

After the CPU executes the plaintext codes, the corresponding plaintext execution results are generated, and besides, plaintext receipt data is also generated. The content of the plaintext receipt data may include information contained in the above-described fields, or other extended information, and this description is not intended to be limiting. Although receipt data does not include information such as contract status values related to transactions, the privacy of users is still exposed to a certain extent. For example, when a user initiates a transaction to a first block link through a client, the transaction is used to query a value of a contract status, although the value of the contract status is not changed after the transaction is executed, the receipt data generated after the transaction is executed will expose the user to perform a related query operation.

Therefore, by setting the corresponding access condition for the receipt data, it is possible to control the access operation for the receipt data, to restrict the occurrence of random access, and to avoid the leakage of user privacy.

Then, when the requesting party requests the first block link point to access the receipt data, the first block link point may read the access condition corresponding to the receipt data, and when it is determined that the access condition is satisfied, the providing of the receipt data to the requesting party is allowed, otherwise the access operation should be prevented.

In an embodiment, the access condition may include: the requestor is on an access white list that contains objects that allow access to the receipt data. In another embodiment, the access condition may include: the requestor is not on an access blacklist that contains objects that are not allowed access to the receipt data. In contrast, the access to the white list has higher security, and the limitation of accessing the black list can be avoided by replacing the requester.

Wherein the requestor comprises at least one of: a user initiating the request (e.g., the user initiated a transaction to access the receipt data), a contract address of a smart contract initiating the request (e.g., code of the smart contract executed to access the receipt data), and a function initiating the access. Taking an access white list as an example, the object in the access white list can be a pre-agreed and unalterable object; or, the objects in the access white list may be increased or decreased according to actual situations, for example, after the transaction is created, the contract address of the intelligent contract corresponding to the transaction may be temporarily added to the access white list through offline negotiation or other negotiation, so that the intelligent contract corresponding to the transaction may access the receipt data.

The access condition may be a predefined uniform condition at the first block link point, i.e. the first block link point may set the uniform condition for all locally generated receipt data. Or, the access condition may be an individualized condition defined in the transaction, for example, when the user generates a transaction at the client, the user may set a corresponding individualized condition for the transaction in a targeted manner according to an authority management manner that the user wishes to adopt, so that the first block link point sets an access condition for the receipt data corresponding to the transaction based on the individualized condition, thereby satisfying the individualized requirement of the user.

The personalization condition may be located in the transaction, rather than in the code or other location of the smart contract to which the transaction corresponds. Then the personalization condition in the transaction may be used to set the corresponding access condition for the receipt data generated for the transaction; or, when there are multiple corresponding intelligent contracts in the transaction, the personalized condition in the transaction may be used to set corresponding access conditions for the receipt sub-data corresponding to each intelligent contract, that is, the personalized condition in the transaction may be a transaction-level condition or a contract-level condition.

The personalization condition may be located in the intelligent contract corresponding to the transaction, for example, in the code of the intelligent contract, so that the first blockchain node may execute the code of the intelligent contract when processing the transaction, thereby knowing the personalization condition included in the code of the intelligent contract. If a transaction contains only one smart contract, then the personalization conditions contained in the smart contract may be considered transaction-level conditions that may be used to set access conditions for receipt data generated by the execution of the transaction. If the transaction includes a plurality of intelligent contracts, the personalized condition included in each intelligent contract can be regarded as a contract level condition, and the access condition can be respectively set for the receipt sub-data corresponding to the corresponding intelligent contract according to the personalized condition included in each intelligent contract. When the transaction includes a plurality of smart contracts, a personalization condition may be included only in a certain smart contract, so that the personalization condition serves as a transaction-level condition for setting an access condition to receipt data generated by the transaction.

If the personalization condition is located in the code of the smart contract included in the transaction, the personalization condition in the code cannot generally be adjusted unless the version of the smart contract is updated. Thus, the personalization condition may also be located in another smart contract invoked by the smart contract in the transaction, and the personalization condition may be updated by creating a new smart contract and having the smart contract invoke the new smart contract. The personalization condition can also be adjusted each time by including it in the transaction.

Although the first block link point may set the access condition for the receipt data corresponding to all transactions, the requirements of different users are often different, for example, a part of users are relatively more interested in efficiency and can accept that no access condition is set for the receipt data, another part of users are relatively more interested in privacy and can accept that the condition setting and judgment process for the receipt data have an influence on efficiency, and then whether the access condition needs to be set for the receipt data can be determined for different scenes.

The first block link point may determine whether an access condition is set for receipt data according to a transaction type. Based on the above description, the first block link point may identify whether the transaction submitted by the client is of a plaintext type or a privacy type through a "transaction/query interface" module as shown in fig. 2. For a private transaction, the first block link point may set an access condition for receipt data corresponding to the private transaction using a uniform condition or a personalized condition; for the plaintext transaction, the first block link point does not need to set an access condition for the receipt data corresponding to the plaintext transaction.

The first blockchain node can be encrypted by using a secret key when storing receipt data corresponding to the transaction; when the requester meets the access condition, the first blockchain node returns the encrypted receipt data to the requester. The first block chain link point can provide data security protection for the receipt data from a data encryption dimension and an authority protection dimension simultaneously by encrypting the receipt data, thereby providing a better security protection effect.

Similarly to the process of generating a receipt tree in the related art, the encrypted receipt data is also used to calculate the root of the receipt tree, and the root is included in the block header of the block where the transaction is located. For example, when the MPT tree structure is used, the hash value of the encrypted receipt data will be used to construct the leaves of the receipt tree; of course, in some cases receipt data may be stored directly in plain text, and the hash of the receipt data in plain text is used to construct the leaves of the receipt tree as well, as will be described in more detail below.

The first block link point first generates receipt data in clear text form, which is then encrypted with a key. The encryption can adopt symmetric encryption or asymmetric encryption. If the first blockchain node encrypts the plaintext receipt data in a symmetric encryption manner, i.e., using a symmetric key of a symmetric encryption algorithm, the client (or other object holding the key) may decrypt the encrypted receipt data using the symmetric key of the symmetric encryption algorithm.

When the first blockchain node encrypts the receipt data in the clear text form with the symmetric key of the symmetric encryption algorithm, the symmetric key may be previously provided to the first blockchain node by the client. Then, only the client (which should actually be the user corresponding to the logged-in account on the client) and the first block link point grasp the symmetric key, so that only the client can decrypt the corresponding encrypted receipt data, and the decryption of the encrypted receipt data by an unrelated user or even a lawbreaker is avoided.

For example, when the client initiates a transaction to the first block link node, if the transaction is a private transaction, the client may encrypt the plaintext transaction content with the initial key of the symmetric encryption algorithm to obtain the private transaction; accordingly, the first block link point may be used to encrypt, directly or indirectly, the plaintext receipt data by obtaining the initial key. For example, the initial key may be pre-negotiated by the client and the first blockchain node, or sent by the key management server to the client and the first blockchain node, or sent by the client to the first blockchain node. When the initial key is sent to the first block chain node by the client, the client can encrypt the initial key by the public key of the asymmetric encryption algorithm and then send the encrypted initial key to the first block chain node, and the first block chain node decrypts the encrypted initial key by the private key of the asymmetric encryption algorithm to obtain the initial key, that is, the digital envelope encryption described above, which is not described herein again.

The first block link point may encrypt receipt data in clear text using the initial key described above. The initial keys used for different transactions may be the same, so that all transactions submitted by the same user are encrypted using the initial keys, or the initial keys used for different transactions may be different, for example, the client may randomly generate an initial key for each transaction, so as to improve security.

The first chunk chain node may generate a derivative key from the initial key and the impact factor, and encrypt receipt data in plaintext form with the derivative key. Compared with the method that the initial key is directly adopted for encryption, the derived key can increase the randomness, so that the difficulty of being broken is improved, and the safety protection of data is optimized. The impact factor may be related to the transaction; for example, the impact factor may include designated bits of the transaction hash value, such as the first chunk nexus may concatenate the initial key with the first 16 bits (or the first 32 bits, the last 16 bits, the last 32 bits, or other bits) of the transaction hash value and hash the concatenated string to generate the derivative key.

The first block link point can also adopt an asymmetric encryption mode, namely, the receipt data in a plaintext form is encrypted by using a public key of an asymmetric encryption algorithm, and accordingly, the client can decrypt the encrypted receipt data by using a private key of the asymmetric encryption algorithm. The key of the asymmetric encryption algorithm may be, for example, a pair of a public key and a private key generated by the client, and the public key is sent to the first blockchain node in advance, so that the first blockchain node may encrypt receipt data in a clear text form with the public key.

Although the first block link point can encrypt receipt data in plaintext form corresponding to all transactions, the demands of different users are different, for example, one part of users is more concerned about efficiency relatively and can accept the receipt data to be stored, another part of users is more concerned about privacy relatively and can accept the influence of encryption and decryption on the receipt data on efficiency, and whether the receipt data needs to be encrypted or not can be determined for different scenes.

The first block link point may determine whether to encrypt the receipt data according to the transaction type. Based on the above description, the first chunk node may identify whether the transaction submitted by the client is of a clear text type or a privacy type. For a private transaction, the first tile chain node may encrypt receipt data corresponding to the private transaction using a key. For example, after the first block chain node receives a transaction, the identified private transaction may be transmitted to the trusted execution environment through a "transaction/query interface" module as shown in fig. 2, so that the private transaction is executed in the trusted execution environment, and receipt data is generated, and then the receipt data is encrypted in the trusted execution environment, so as to obtain encrypted receipt data. While for clear text transactions, the first block link point may directly store the corresponding receipt data. For example, after the first blockchain node receives the transaction, the identified plaintext transaction may be executed in a normal execution environment other than the trusted execution environment through a "transaction/query interface" module shown in fig. 2, and then stored in plaintext form.

The first block link point may encrypt the receipt data using a key upon determining that the transaction contains an encrypted identification. When a user generates a transaction at a client, the client may provide the user with an option to determine whether to add an encrypted identification to the transaction. For example, when a user wishes to encrypt receipt data, an encryption identifier may be optionally added to a transaction, so that after the first blockchain node receives the transaction, the encryption identifier included in the transaction may be identified by a "transaction/query interface" module as shown in fig. 2, at this time, regardless of whether the transaction is a plaintext transaction or a private transaction, the transaction is transmitted to a trusted execution environment, so that the transaction is executed in the trusted execution environment, and receipt data is generated, and then the receipt data is encrypted in the trusted execution environment, so as to obtain encrypted receipt data. It can be seen that the encrypted identifier should exist in the transaction in clear text, so that the first chunk node can directly determine whether the encrypted identifier is included in the transaction without decrypting the encrypted identifier. When the user does not want to encrypt the receipt data, the user may choose not to add the encryption identifier in the transaction, so that after the first blockchain node receives the transaction, the transaction may be recognized through the "transaction/query interface" module shown in fig. 2 that does not include the encryption identifier, and then the first blockchain node needs to further recognize the type of the transaction, so as to transmit the private transaction into the trusted execution environment for execution, transmit the plaintext transaction in the conventional execution environment for execution, and directly store the obtained receipt data without encryption.

When a client generates a transaction, there may be one or more corresponding smart contracts for each transaction. Accordingly, receipt data generated as a result of a transaction being executed may include receipt sub-data corresponding to each smart contract, respectively. When a user generates a transaction, whether the receipt sub-data corresponding to each intelligent contract needs to be encrypted or not can be respectively determined, and corresponding encryption marks are added to the intelligent contracts needing to be encrypted. Compared with the transaction containing the encrypted identifier, the embodiment can realize the security protection at the contract level, has relatively finer granularity and can realize better security protection effect. Then, the first block link point may encrypt the receipt sub-data corresponding to the intelligent contract with the encrypted identifier, and the receipt sub-data corresponding to the intelligent contract without the encrypted identifier does not need to be encrypted. The encrypted identifiers added for each intelligent contract should be plaintext information, so that after the first block chain node receives a transaction, the first block chain node can be identified by a "transaction/query interface" module shown in fig. 2, for example, to determine whether at least one intelligent contract has a corresponding encrypted identifier, and specifically which intelligent contracts have a corresponding encrypted identifier and which intelligent contracts do not have the corresponding encrypted identifier.

When the first block node determines that the encrypted identifier exists in at least one intelligent contract corresponding to the transaction, the transaction can be transmitted to the trusted execution environment through the transaction/query interface module, so that the transaction is processed in the trusted execution environment. If the transaction is a plaintext transaction, the transaction can be directly executed without decryption, and the receipt subdata respectively corresponding to each intelligent contract can be obtained; if the transaction is a private transaction, corresponding plaintext transaction contents can be obtained by decryption in the trusted execution environment, and the plaintext transaction contents are executed in the trusted execution environment, so that receipt sub-data respectively corresponding to each intelligent contract is obtained. Then, the first block link point can encrypt the receipt subdata corresponding to the intelligent contract with the encryption identifier to obtain corresponding ciphertext receipt subdata, and the receipt subdata corresponding to the intelligent contract without the encryption identifier does not need to be encrypted.

When the first block link point determines that all the intelligent contracts corresponding to the transactions do not have encryption marks, the type of the transactions needs to be further determined, if the transactions are plaintext transactions, the transactions can be transmitted into a conventional execution environment through the transaction/query interface module to be executed, and if the transactions are private transactions, the transactions can be transmitted into a trusted execution environment through the transaction/query interface module to be executed. In a conventional execution environment, the plaintext transaction is directly executed by the first block chain node, and receipt sub-data respectively corresponding to each intelligent contract is obtained, and the receipt sub-data does not need to be encrypted. In a trusted execution environment, the first block link point decrypts the private transaction to obtain corresponding plaintext transaction contents, and the plaintext transaction contents are executed to obtain receipt sub-data respectively corresponding to each intelligent contract, and the receipt sub-data does not need to be encrypted.

The first block chain link point obtains corresponding receipt data by executing transaction, and after the receipt data is encrypted into the corresponding encrypted receipt data through the key, the encrypted receipt data can be actively fed back to the client initiating the transaction to be used as the receipt of the transaction. The first tile link point may store the encrypted receipt data so that the client may request and obtain the encrypted receipt data from the first tile link point at any time. Of course, if the clear text receipt data corresponding to the transaction does not require encryption, the first block link point may return the receipt data to the client, or the first block link point may store the receipt data and return the receipt data based on the client's response.

The first block link point implements a function by running code for implementing the function. Thus, for functions that need to be implemented in a trusted execution environment, the relevant code needs to be executed as well. For code executed in the trusted execution environment, relevant specifications and requirements of the trusted execution environment need to be met; accordingly, for codes used for realizing a certain function in the related art, the codes need to be rewritten in combination with the specifications and requirements of the trusted execution environment, so that not only is a relatively large development amount present, but also a vulnerability (bug) is easily generated in the rewriting process, and the reliability and stability of function realization are affected.

Therefore, the first block chain node can store the encrypted receipt data generated in the trusted execution environment to the external storage space outside the trusted execution environment by executing the storage function code outside the trusted execution environment (certainly, the receipt data in the trusted execution environment may not need to be encrypted, and the storage function code can also store the part of receipt data to the external storage space; here, the storage process of the encrypted receipt data is taken as an example for explanation), so that the storage function code can be a code used for realizing a storage function in the related art, and safe and reliable storage can be realized for the encrypted receipt data without rewriting the code in combination with the specifications and requirements of the trusted execution environment, and not only can the development amount of the related codes be reduced on the basis of not affecting the safety and reliability, furthermore, the TCB (Trusted Computing Base) can be reduced by reducing the relevant code of the Trusted execution environment, so that the additional security risk caused by the combination of the TEE technology and the block chain technology is in a controllable range.

In one embodiment, a first block chain node may execute write cache function code within a trusted execution environment to store the receipt data in a write cache within the trusted execution environment, such as the write cache may correspond to a "cache" as shown in fig. 2. Further, the first block link point encrypts the data in the write cache and outputs the encrypted data from the trusted execution environment to the external storage space. The write cache function code can be stored in the trusted execution environment in a plaintext form, and the cache function code in the plaintext form can be directly executed in the trusted execution environment; alternatively, the write cache function code may be stored outside the trusted execution environment in a ciphertext form, such as in the above-mentioned external storage space (for example, "pack + store" shown in fig. 2, where "pack" indicates that the first block chaining node packs the transaction into blocks outside the trusted execution environment), and the write cache function code in the ciphertext form may be read into the trusted execution environment, decrypted in the trusted execution environment into a plaintext code, and executed.

Write caching refers to a "buffering" mechanism provided to avoid causing a "shock" to an external storage space when data is written to the external storage space. For example, the above write cache may be implemented by using a buffer; of course, the write cache may also be implemented by using a cache, which is not limited in this specification. In fact, because the trusted execution environment is an isolated secure environment and the external storage space is located outside the trusted execution environment, the external storage space can be written into the data in the cache in batch by adopting a cache writing mechanism, so that the interaction times between the trusted execution environment and the external storage space are reduced, and the data storage efficiency is improved. Meanwhile, the trusted execution environment may need to call generated data in the process of continuously executing each plaintext transaction content, and if the data to be called is just located in the write cache, the data can be directly read from the write cache, so that on one hand, interaction with an external storage space can be reduced, on the other hand, a decryption process of the data read from the external storage space is omitted, and therefore data processing efficiency in the trusted execution environment is improved.

Of course, the write cache may also be established outside the trusted execution environment, for example, the first block node may execute the write cache function code outside the trusted execution environment, so as to store the encrypted receipt data in the write cache outside the trusted execution environment, and further store the data in the write cache in the external storage space.

In an embodiment, the first chunk chain node may encrypt the plaintext receipt data according to a query request initiated by a client and output the encrypted plaintext receipt data from the trusted execution environment to return to the client.

For example, the first tile link point may read the encrypted receipt data from the external storage space and return the encrypted receipt data to the client via the transaction/query interface shown in fig. 2.

For another example, the first block link point may read the receipt data from a read cache in the trusted execution environment, encrypt the receipt data, and output the encrypted receipt data from the trusted execution environment; and the receipt data is read into the trusted execution environment and stored in the read cache after the encrypted receipt data is decrypted into the receipt data. In other words, after the first blockchain node reads the encrypted receipt data from the external storage space and decrypts the encrypted receipt data into the receipt data, the receipt data may be stored in a read cache within the trusted execution environment by executing a read cache function code within the trusted execution environment, for example, the read cache may correspond to the "cache" shown in fig. 2; furthermore, for a query request initiated by the client or for data required by the trusted execution environment when executing the plaintext transaction content, data reading can be preferentially performed from the read cache, and if relevant data can be read, reading from the external storage space is not required, so that the number of interactions with the external storage space is reduced, and a data decryption process is omitted.

The read cache is to store the read data in the read cache space in the trusted execution environment in a plaintext form in order to reduce the number of interactions with the external storage space after reading the data from the external storage space into the trusted execution environment. For example, the above read cache may be implemented by using a cache; of course, the read cache may also be implemented by using a buffer, and this specification does not limit this.

The first chunk link node may support both the read cache mechanism and the write cache mechanism described above. With the continuous development of the cache technology, the same cache may not only be used for implementing data reading or data writing, but even simultaneously support the read-write operation of data, so that the boundary between the read cache and the write cache is sometimes not very clear, and thus fig. 2 only illustrates the cache without specifically distinguishing the specific type thereof, and may be configured and adjusted according to actual requirements.

Of course, the above-mentioned cache mechanism in the trusted execution environment may also be applied to the conventional execution environment, for example, implemented by "cache" in the conventional execution environment shown in fig. 2, but data reading and writing at this time only involves plaintext reading and writing, and it is not necessary to perform data encryption and decryption operations, and details are not described here.

An embodiment of a node for implementing hybrid transaction in a blockchain according to the present disclosure is described below with reference to fig. 3, where the node includes:

an execution unit 301, configured to execute a transaction received from a client, resulting in receipt data;

a setting unit 302, configured to set a corresponding access condition for the receipt data when the receipt data is stored when the transaction is determined to be a private transaction;

a response unit 303 for determining that the access condition is satisfied when responding to an access request for the receipt data.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified Programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Language, HDL, las, hdul (Hardware Description Language), vhal — Language, etc., which are currently used in most general. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

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 method for implementing privacy protection in a blockchain, comprising:

the first block chain link point executes the transaction received from the client to obtain receipt data; when the first block chain node determines that the transaction is a plaintext transaction, the plaintext transaction is executed through a virtual machine deployed in a conventional execution environment except a trusted execution environment to obtain the receipt data, and when the first block chain node determines that the transaction is a privacy transaction, the privacy transaction is decrypted through the virtual machine deployed in the trusted execution environment to obtain corresponding plaintext transaction content, and the plaintext transaction content is executed to obtain the receipt data;

when the first block link point determines that the transaction is a private transaction, setting corresponding access conditions for receipt data when the receipt data is stored under a link;

2. The method of claim 1, the access condition comprising:

the requesting party is in the access white list; or the like, or, alternatively,

the requestor is not on the access blacklist.

3. The method of claim 2, the requestor comprising at least one of: the user initiating the request, the contract address of the intelligent contract initiating the request, and the function initiating the request.

4. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,

the access condition is a predefined uniform condition at a link point of the first block; or the like, or, alternatively,

the access condition is a personalization condition defined in the transaction.

5. The method of claim 4, the transaction having a plurality of corresponding smart contracts, the receipt data including receipt sub-data corresponding to each smart contract, respectively; the personalization conditions include: the conditions of the receipt sub-data corresponding to all the intelligent contracts or the conditions of the receipt sub-data corresponding to each intelligent contract.

6. The method of claim 4, wherein the first and second light sources are selected from the group consisting of,

the personalization condition is located in the transaction; or the like, or, alternatively,

the personalized condition is positioned in an intelligent contract corresponding to the transaction; or the like, or, alternatively,

the personalization condition is located in another intelligent contract invoked by the intelligent contract corresponding to the transaction.

7. The method of claim 1, when the transaction is a clear text transaction, the receipt data corresponding to the clear text transaction is free of access conditions.

8. The method of claim 1, a first block link point storing the receipt data, comprising:

the first blockchain node executes storage function code outside the trusted execution environment to output receipt data corresponding to the private transaction from the trusted execution environment and store the receipt data to an external storage space outside the trusted execution environment.

9. The method of claim 1, the transaction being used to create and/or invoke a smart contract.

10. The method of claim 1, further comprising:

the first blockchain node encrypts the receipt data by using a secret key when storing the receipt data;

when the requester meets the access condition, the first blockchain node returns the encrypted receipt data to the requester.

11. The method of claim 10, a first block chain node encrypting the receipt data using a key, comprising:

the first blockchain node encrypts the receipt data using a key when the transaction is determined to be a private transaction.

12. The method of claim 11, the first tile chain node performing a transaction received from a client, comprising:

when the transaction is determined to be a private transaction, the first block chain node decrypts the private transaction in a trusted execution environment to obtain corresponding plaintext transaction content, and executes the plaintext transaction content;

wherein the receipt data is encrypted in the trusted execution environment.

13. The method of claim 11, further comprising:

when the first block chain node determines that the transaction is a plaintext transaction, executing the plaintext transaction outside a trusted execution environment;

the first block link point stores the receipt data.

14. The method of claim 10, wherein the first and second light sources are selected from the group consisting of,

the first block link point encrypts the receipt data using a key, comprising:

the first blockchain node encrypts the receipt data using a key upon determining that the transaction contains an encrypted identification.

15. The method of claim 14, the first tile chain node performing a transaction received from a client, comprising:

the first blockchain node executes the transaction in a trusted execution environment when determining that the transaction contains the encrypted identifier;

wherein the receipt data is encrypted in the trusted execution environment.

16. The method of claim 14, further comprising:

when the first blockchain node determines that the transaction does not contain the encrypted identifier, identifying the type of the transaction;

when the transaction is a private transaction, the first block chain node decrypts the private transaction in a trusted execution environment to obtain corresponding plaintext transaction content, and executes the plaintext transaction content to obtain receipt data;

when the transaction is a plaintext transaction, the first blockchain node executes the transaction outside the trusted execution environment to obtain receipt data;

the first block link point stores the receipt data.

17. The method of claim 10, the transaction having one or more corresponding intelligent contracts, the clear text receipt data including receipt sub-data corresponding to each intelligent contract, respectively; the first block link point encrypts the receipt data using a key, comprising:

when the first block chain node determines that any intelligent contract corresponding to the transaction has an encryption identifier, encrypting receipt sub-data corresponding to any intelligent contract into ciphertext receipt sub-data by using a key and storing the ciphertext receipt sub-data, wherein the ciphertext receipt data comprises the ciphertext receipt sub-data.

18. The method of claim 17, the first tile chain node performing a transaction received from a client, comprising:

when the first blockchain node determines that at least one intelligent contract corresponding to the transaction has the encryption identifier, executing the transaction in a trusted execution environment;

wherein receipt sub-data corresponding to the at least one smart contract is encrypted in the trusted execution environment.

19. The method of claim 17, further comprising:

when determining that all the intelligent contracts corresponding to the transactions have no encryption identifiers, the first block chain node identifies the types of the transactions;

the first block link point stores the receipt data.

20. The method of claim 19, the key comprising a key of a symmetric encryption algorithm or a key of an asymmetric encryption algorithm.

21. The method of claim 20, the key of the symmetric encryption algorithm comprising an initial key provided by the client; or, the key of the symmetric encryption algorithm comprises the initial key and a derivative key generated by the influence factor.

22. The method of claim 21, when the transaction is a private transaction, the private transaction is encrypted by the initial key, and the initial key is encrypted by a public key of an asymmetric encryption algorithm;

and the first block chain node decrypts by using a private key of the asymmetric encryption algorithm to obtain the initial key, decrypts the private transaction by using the initial key to obtain plaintext transaction content, and obtains the plaintext receipt data after the plaintext transaction content is executed.

23. The method of claim 21, wherein the initial key is generated by the client, determined by negotiation between the client and the first chunk link node, or sent by a key management server.

24. The method of claim 21, the impact factor being related to the transaction.

25. The method of claim 24, the impact factor comprising: a specified bit of the hash value for the transaction.

26. A node in a blockchain to implement privacy protection, comprising:

an execution unit for executing the transaction received from the client, resulting in receipt data; when the first block chain node determines that the transaction is a plaintext transaction, the plaintext transaction is executed through a virtual machine deployed in a conventional execution environment except a trusted execution environment to obtain the receipt data, and when the first block chain node determines that the transaction is a privacy transaction, the privacy transaction is decrypted through the virtual machine deployed in the trusted execution environment to obtain corresponding plaintext transaction content, and the plaintext transaction content is executed to obtain the receipt data;

the setting unit is used for setting corresponding access conditions for the receipt data when the receipt data is stored under a link when the transaction is determined to be a private transaction;

27. 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 25.