CN111639362B

CN111639362B - Method, node and storage medium for implementing privacy protection in blockchain

Info

Publication number: CN111639362B
Application number: CN202010429988.9A
Authority: CN
Inventors: 刘琦; 魏长征; 闫莺
Original assignee: Advanced New Technologies Co 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: 2023-12-22
Anticipated expiration: 2039-02-19
Also published as: CN110008737B; CN110008737A; CN111639362A

Abstract

One or more embodiments of the present specification provide a method, node, and storage medium for implementing privacy protection in a blockchain, the method may include: the method comprises the steps that a first block chain link point receives a transaction initiated by a client, wherein one or more corresponding intelligent contracts exist in the transaction; a first block link point performing the transaction to obtain plaintext receipt data, the plaintext receipt data comprising plaintext receipt sub-data corresponding respectively to each smart contract; when the first blockchain node determines that the encryption identifier exists in the first intelligent contract corresponding to the transaction, encrypting the plaintext Wen Shouju subdata corresponding to the first intelligent contract into ciphertext receipt subdata by using a secret key, wherein the ciphertext receipt data corresponding to the plaintext receipt data comprises the ciphertext receipt subdata; the first block link point stores the cryptogram receipt data.

Description

Method, node and storage medium for implementing privacy protection in blockchain

Technical Field

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

Background

Blockchain technology builds on top of transport networks (e.g., point-to-point networks). Network nodes in the transport network utilize the chained data structures to validate and store data and employ distributed node consensus algorithms to generate and update data. Nodes in these blockchain networks sometimes need to be added.

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

In addressing privacy, trusted execution environments (Trusted Execution Environment, TEE) are another solution. The TEE may act as a black box in the hardware, and code and data executed in the TEE cannot be peeped by the operating system layer, and can only be operated through a predefined interface in the code. In terms of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptographic operation in homomorphic encryption, and efficiency loss is avoided in the calculation process, so that the safety and privacy of the blockchain can be improved to a large extent on the premise of small performance loss by combining the TEE. The current industry is concerned with TEE solutions, with almost all mainstream chip and software alliances having their own TEE solutions, including TPM (Trusted Platform Module ) on software and Intel SGX (Software Guard Extensions, software protection extension), ARMTrustzone (trust zone) and AMD PSP (Platform Security Processor ) on hardware.

Disclosure of Invention

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

In order 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 of implementing privacy protection in a blockchain, comprising:

the method comprises the steps that a first block chain link point receives a transaction initiated by a client, wherein one or more corresponding intelligent contracts exist in the transaction;

a first block link point performing the transaction to obtain plaintext receipt data, the plaintext receipt data comprising plaintext receipt sub-data corresponding respectively to each smart contract;

when the first blockchain node determines that the encryption identifier exists in the first intelligent contract corresponding to the transaction, encrypting the plaintext Wen Shouju subdata corresponding to the first intelligent contract into ciphertext receipt subdata by using a secret key, wherein the ciphertext receipt data corresponding to the plaintext receipt data comprises the ciphertext receipt subdata;

the first block link point stores the cryptogram receipt data.

According to a second aspect of one or more embodiments of the present specification, there is provided a node in a blockchain that implements privacy protection, comprising:

The receiving unit is used for receiving a transaction initiated by the client, wherein one or more corresponding intelligent contracts exist in the transaction;

an execution unit for the transaction to obtain plain text receipt data, the plain text receipt data including plain text receipt sub-data corresponding to each smart contract, respectively;

an encryption unit, configured to encrypt, using a key, plaintext Wen Shouju subdata corresponding to a first smart contract into ciphertext receipt subdata when it is determined that an encryption identifier exists in the first smart contract corresponding to the transaction, where the ciphertext receipt data corresponding to the plaintext receipt data includes the ciphertext receipt subdata;

and the storage unit is used for storing the ciphertext receipt data.

According to a third aspect of one or more embodiments of the present description, a computer-readable storage medium is presented, on which computer instructions are stored, which instructions, 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 provided in 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 nodes implementing privacy protection in a blockchain in accordance with an exemplary embodiment.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to 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 aspects of one or more embodiments of the present description as detailed in the accompanying claims.

It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there are many types of combinations, such as different combinations of private chain+federation chain, federation chain+public chain, and the like. Among them, the highest degree of decentralization is the public chain. The public chain is represented by bitcoin and ethernet, and participants joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like. Moreover, each participant (i.e., node) is free to join and leave the network and perform related operations. The private chain is the opposite, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. In short, the private chain may be a weakly centralized system with few and strict restrictions on participating nodes. This type of blockchain is more suitable for use within a particular organization. The alliance chain is a block chain between public and private chains, and can realize 'partial decentralization'. Each node in the federation chain typically has an entity organization or organization corresponding thereto; participants join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation.

Whether public, private, or alliance, corresponding receipt (receipt) data may be generated after the transaction is performed for recording receipt information associated with the transaction. Taking ethernet as an example, receipt data from a node executing a transaction may include the following fields:

a blockHash field representing a hash value of a block in which the exchange is located;

a block number field, which indicates the sequence number of the block where the transaction is located;

a transactionHash field representing a hash value of the transaction;

a transactionIndex field, representing the sequence number of the transaction in the block at which it is located;

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

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

a condactaddress field representing an address of the created smart contract when the transaction is used to create the smart contract, otherwise empty;

logs field, representing a log of transactions.

When each transaction contained in a certain block is executed by a node, corresponding receipt data is 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 generation of the receipt tree, when inquiring or verifying receipt data, the corresponding inquiring or verifying efficiency can be greatly improved. For example, the above-mentioned receipt tree is generated in the ethernet by adopting the MPT (Merkle Patricia Tree) structure organization, the leaf of the receipt tree is the hash value of the receipt data corresponding to each transaction contained in the block, and the receipt tree root (receipts root) is the 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 employed in other blockchain networks.

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

at step 102, a first block link point receives a client-initiated transaction, the transaction having one or more corresponding smart contracts.

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 blockchain node includes a transaction/query interface that interfaces with a client such that the client can submit a transaction to the first blockchain node.

At step 104, the first block link point performs the transaction to obtain plaintext receipt data comprising plaintext receipt sub-data corresponding respectively to each smart contract.

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

Based on different privacy protection requirements, transactions may be classified into clear text transactions of clear text type, privacy transactions of privacy type. A type field may be added to the transaction so that the first blockchain node may identify the transaction type as either a clear text transaction or a private transaction based thereon. In the related art, for example, in an ethernet network, a transaction typically contains fields such as to, value, data. On the basis of the related technology, the embodiment adds a type field, such 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 a first value, the related transaction is indicated as a clear text transaction, and when the type field is a second value, the related transaction is indicated as a private transaction.

All contents of the plaintext transaction are in a plaintext form, namely all fields of the transaction are in a plaintext form, so that the first blockchain node can directly read all the fields of the plaintext transaction to implement related processing; at the same time, the plaintext transaction is packed into blocks in plaintext form, which are then recorded in the blockchain in plaintext form. Besides the type field adopts a plaintext form, other fields adopt a ciphertext form, so that on one hand, a first blockchain node can quickly identify the transaction type under the condition that decryption is not needed, and therefore differentiation processing is implemented for the plaintext transaction and the privacy transaction, and on the other hand, the privacy transaction can only be decrypted and read by an object with a secret key by adopting the ciphertext form, so that leakage of transaction information is avoided, and the privacy transaction is packaged into blocks in the ciphertext form, and is recorded in a blockchain in the ciphertext form.

All transactions in the ethernet network are plain text transactions. The first blockchain node can expand a mixed processing scheme which gives consideration to plaintext transactions and private transactions on the basis of the first blockchain node. For example, as shown in fig. 2, the first blockchain node may be divided into a regular execution environment and a trusted execution environment, where transactions submitted by clients first enter a "transaction/query interface" in the regular execution environment for type identification (e.g., identifying the type field described above), leave identified plain-text transactions in the regular execution environment for processing, and pass identified private transactions 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 smooth implementation of encryption operation, plaintext transactions may be transferred into the trusted execution environment for execution in some scenarios, and the distinction between the first blockchain node and the private transaction is only that the plaintext transactions do not need to be decrypted and the corresponding plaintext execution results do not need to be encrypted.

When the conventional execution environment processes the plaintext transaction, the whole processing process completely adopts a plaintext mode, namely, the plaintext transaction is processed by the first blockchain node to obtain the plaintext receipt data, and the plaintext 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 plaintext transaction content in the trusted execution environment, so that the plaintext transaction content can be efficiently processed in the trusted execution environment and corresponding plaintext receipt data is generated in the trusted execution environment on the premise of ensuring data security; further, when the plaintext receipt data is stored, it needs to be encrypted into corresponding ciphertext receipt data, and then stored in a conventional execution environment, for example, the plaintext receipt data corresponding to the plaintext transaction is stored in the same location, which may be a "package+store" module as 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 in the related art. In this case, either the plain or private transaction described above may be independent of the smart 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 as an example, support users create and/or invoke some complex logic in the ethernet network, which is the biggest challenge for ethernet to distinguish from the bitcoin blockchain technology. At the heart of the ethernet as a programmable blockchain is an Ethernet Virtual Machine (EVM), which can be run by each ethernet node. The EVM is a graphics-complete virtual machine, meaning that various complex logic can be implemented by it. The user's issuing and invoking of the smart contract in the ethernet is running on the EVM. In practice, the virtual machine runs directly on virtual machine code (virtual machine bytecode, hereinafter "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

In one embodiment, the smart contracts of the present specification may be divided into plaintext contracts of plaintext type, privacy contracts of privacy type. The contract code and the contract state of the plaintext contract are both stored at the node in plaintext form, while the contract code and the contract state of the privacy contract are both stored at the node in ciphertext form, such 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.

Because 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 a plaintext form, and therefore the intelligent contract is necessarily a plaintext contract. Meanwhile, when the smart contract is invoked by the plaintext transaction, the smart contract invoked by the plaintext transaction can only be the plaintext contract because the privacy contract can only be decrypted in the trusted execution environment.

The first blockchain node may decrypt the private transaction in a trusted execution environment (Trusted Execution Environment, TEE). TEE is a trusted execution environment based on a secure extension of CPU hardware and completely isolated from the outside. TEE was originally proposed by Global Platform for resolving secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications in parallel to the operating system. The ARM Trust Zone technology has at the earliest realized the true commercial TEE technology.

Along with the high-speed development of the internet, the requirements for security are higher and higher, and the requirements for the TEE are more provided for mobile equipment, cloud equipment and data centers. The TEE concept has also been developed and expanded at a high rate. The TEE now has been a more generalized TEE than the originally proposed concept. For example, server chip manufacturers Intel, AMD, etc. have successively introduced hardware-assisted TEEs and enriched the concepts and characteristics of TEEs, which have been widely accepted in the industry. The TEE now lifted is often more directed to such hardware assisted TEE technology. Unlike the mobile terminal, the cloud access needs remote access, and the terminal user is invisible to the hardware platform, so that the first step of using the TEE is to confirm the true credibility of the TEE. Therefore, the existing TEE technology introduces a remote attestation mechanism, and a hardware manufacturer (mainly a CPU manufacturer) endorses 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 secure resource isolation is met, and further data privacy protection is also proposed. Commercial TEEs, including Intel SGX, AMD SEV, also provide memory encryption techniques that limit trusted hardware to the CPU, and the data on the bus and memory are ciphertext to prevent malicious users from snooping. TEE technology, such as intel's software protection extension (SGX), isolates code execution, remote attestation, security 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 Intel SGX technology as an example, SGX provides an enclosure (also called enclave), i.e., an encrypted trusted execution area in memory, that protects data from theft by the CPU. Taking the first block link point as an example, a CPU supporting SGX is adopted, and with a newly added processor instruction, a part of region EPC (Enclave Page Cache, enclosure page cache or enclave page cache) can be allocated in the memory, and the data in the region EPC 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. Thus, in SGX, a user may not trust the operating system, VMM (Virtual Machine Monitor ), or even BIOS (Basic Input Output System, basic input output System), but only trust the CPU to ensure that private data does not leak. In practical application, the privacy data can be encrypted and then transmitted to the enclosure in a ciphertext mode, and the corresponding secret key is also transmitted to the enclosure through remote certification. Then, the data is used for operation under the encryption protection of the CPU, and the result is returned in the form of ciphertext. In this mode, a strong computational power can be utilized without worrying about data leakage.

Since the private transaction is executed in the TEE, the intelligent contract corresponding to the private transaction may be a private contract, for example, the private transaction may create an intelligent contract in the TEE, and the contract code and contract state of the intelligent contract may be encrypted in the TEE, thereby creating a corresponding private contract; for another example, a privacy transaction may invoke a privacy contract that is decrypted and executed approximately in the TEE, and the contract state that is updated after execution may be updated and stored re-encrypted; for another example, a privacy transaction may invoke a clear text contract that, after being executed in the TEE, the contract state in which the update occurred is still stored in clear text.

Assuming that the private transaction described above is generated at a client, the client may first generate the plaintext transaction content and then encrypt the plaintext transaction content with a key. The encryption can be symmetric encryption or asymmetric encryption. Accordingly, the first blockchain node may decrypt the private transaction with the corresponding key to obtain the plaintext transaction content. If the client encrypts the plaintext transaction content in a symmetric encryption manner, i.e., with a symmetric key of a symmetric encryption algorithm, the first blockchain node may decrypt the private transaction with the symmetric key of the symmetric encryption algorithm accordingly. The encryption algorithm adopted by the symmetric encryption is, for example, a DES algorithm, a 3DES algorithm, a TDEA algorithm, a Blowfish algorithm, an RC5 algorithm, an IDEA algorithm and the like. The symmetric key of the symmetric encryption algorithm may be generated by the generating party of the private transaction, or determined by negotiation between the client and the first block link point, or transmitted by the key management server.

If the plaintext transaction content is encrypted in an asymmetric encryption manner, i.e., with a public key of an asymmetric encryption algorithm, the first blockchain node may decrypt the private transaction with a private key of the asymmetric encryption algorithm accordingly. Asymmetric encryption algorithms such as RSA, elgamal, knapsack algorithm, rabin, D-H, ECC (elliptic Curve encryption algorithm) and the like. The key of the asymmetric encryption algorithm may be, for example, a pair of public key and private key generated by the first block link point and sent to the client in advance, so that the client may encrypt the plaintext transaction content with the public key.

The keys of the asymmetric encryption algorithm may also be generated by a key management server. The key management server sends the private key to the first blockchain node by way of remote attestation, which may specifically be in the enclosure of the incoming first blockchain node. The first blockchain node may include a plurality of enclosures, and the private key may be passed into a security enclosure of the enclosures; for example, the safety enclosure may be a QE (Quoting Enclave) enclosure instead of a AE (Application Enclave) enclosure. For asymmetric encrypted public keys, the key management server may send to the client. The client may then encrypt the plaintext transaction content using the public key, and the first blockchain node may decrypt the private transaction using the private key accordingly to obtain the plaintext transaction content that the private transaction comprises.

The client may also use a combination of symmetric encryption and asymmetric encryption. For example, the client encrypts the plaintext transaction content using a symmetric encryption algorithm, i.e., a symmetric key of the symmetric encryption algorithm is used to encrypt the plaintext transaction content, and an asymmetric encryption algorithm is used to encrypt the symmetric key used in the symmetric encryption algorithm. In general, a public key of an asymmetric encryption algorithm is used to encrypt a symmetric key used in the symmetric encryption algorithm. Thus, after the first block link point receives the encrypted transaction, the first block link point can firstly adopt the private key of the asymmetric encryption algorithm to decrypt, so as to obtain the symmetric key of the symmetric encryption algorithm, and further use the symmetric key of the symmetric encryption algorithm to decrypt, so as to obtain the plaintext transaction content.

For example, the key management server may send the private key of the asymmetric encryption algorithm to the enclosure of the first blockchain node and send the private key of the asymmetric encryption algorithm to the client through remote attestation. Thus, the client may encrypt the plaintext transaction content using the symmetric key of the symmetric encryption algorithm, i.e., the symmetric key of the symmetric encryption algorithm, and encrypt the symmetric key employed in the symmetric encryption algorithm using the public key of the asymmetric encryption algorithm. Further, the client may send the private transaction and an encrypted private key (obtained by encrypting a symmetric key employed in the symmetric encryption algorithm with a public key of the asymmetric encryption algorithm) to a first blockchain node. After the first block link point receives the private transaction and the encrypted private key, the private key of the asymmetric encryption algorithm can be firstly used for decrypting the encrypted private key to obtain a symmetric key of the symmetric encryption algorithm, and then the symmetric key of the symmetric encryption algorithm is used for decrypting the private transaction to obtain plaintext transaction content. The encryption scheme is generally referred to herein as digital envelope encryption.

And after the first blockchain node decrypts the private transaction, obtaining the plaintext transaction content. The clear text transaction content may contain code for an intelligent contract for creating the intelligent contract in the blockchain; the plaintext transaction content may contain a contract address of a smart contract that has been created in the blockchain for invoking the smart contract.

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

When a private transaction is used to create a smart contract, the private transaction includes the code of the smart contract, and the first blockchain node may decrypt the private transaction in the trusted execution environment to obtain the code of the smart contract that it includes, and then execute the plaintext code in the trusted execution environment. When a privacy transaction is used to invoke a privacy-type smart contract, the first blockchain node may decrypt the smart contract in a trusted execution environment to obtain a corresponding plaintext code, and then execute the plaintext code in the trusted execution environment. When a private transaction is used to invoke a clear text type smart contract, a first block link point directly reads the clear text code of the smart contract and executes the clear text code in a trusted execution environment. Specifically, the first blockchain node may allocate a part of the region EPC in the memory by using a newly added processor instruction 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 is decrypted into plaintext after entering the CPU. And in the CPU, the plaintext codes are operated to finish the execution process.

In SGX technology, executing the plain text code of the smart contract, EVM may be loaded into the enclosure. In the remote proving process, the key management server can calculate the hash value of the local EVM code, compare the hash value with the hash value of the EVM code loaded in the first block chain link point, and the comparison result is correct as a necessary condition for passing the remote proving, so that the measurement of the code loaded on the first block chain node SGX enclosure is completed. Through the metrics, the correct EVM may execute the smart contract code in the SGX.

And 106, when the first blockchain node determines that the encryption identifier exists in the first intelligent contract corresponding to the transaction, encrypting the plaintext Wen Shouju subdata corresponding to the first intelligent contract into ciphertext receipt subdata by using a secret key, wherein the ciphertext receipt data corresponding to the plaintext receipt data comprises the ciphertext receipt subdata.

Step 108, the first block link point stores the cryptogram receipt data.

After the CPU executes the plaintext code, plaintext receipt data is generated in addition to the corresponding plaintext execution result. The content of the plain receipt data may include information contained in several of the fields described above, or other extension information, which is not limiting in this specification.

The first blockchain node encrypts the plaintext receipt data so that only a portion of the objects (e.g., the transaction-initiating clients) can decrypt the plaintext receipt data to obtain corresponding plaintext receipt data, thereby avoiding exposing the plaintext receipt data. For example, when a user initiates a transaction to a first blockchain node through a client, the transaction is used for inquiring the value of a certain contract state, and although the value of the contract state is not changed after the transaction is executed, receipt data generated after the transaction is executed exposes the user to implement related inquiry operation, so that the privacy of the user can be protected by encrypting clear text receipt data.

Similar to the process of generating a receipt tree in the related art, the above-described cryptographically correct receipt data is also used to calculate the root of the receipt tree, and the root is contained in the block header of the block where the transaction is located. For example, when using an MPT tree structure, the hash value of the ciphertext receipt data described above would be used to construct the leaves of the receipt tree; of course, in some cases, the plain text receipt data may also be stored directly, and then the hash values of these plain text receipt data are also used to construct the leaves of the receipt tree, as will be described in more detail below.

The first block link point first generates plaintext receipt data and then encrypts the plaintext receipt data with a key. The encryption can be symmetric encryption or asymmetric encryption. If the first blockchain node encrypts the plaintext receipt data with a symmetric encryption scheme, i.e., with a symmetric key of a symmetric encryption algorithm, the client (or other object holding the key) may decrypt the ciphertext receipt data with the symmetric key of the symmetric encryption algorithm.

The first blockchain node encrypts the plaintext receipt data with a symmetric key of a symmetric encryption algorithm that may be pre-provided by the client to the first blockchain node. Then, only the client (actually the user corresponding to the logged account on the client) and the first block link point master the symmetric key, so that only the client can decrypt the corresponding encrypted receipt data, and the encrypted receipt data is prevented from being decrypted by unrelated users and even lawbreakers.

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

The first blockchain node may encrypt the plain-text receipt data using the initial key as described above. The initial keys adopted by different transactions may be the same, so that all transactions submitted by the same user are encrypted by adopting the initial keys, or the initial keys adopted by 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 blockchain node may generate a derivative key from the initial key and the influencing factor and encrypt the plaintext receipt data with the derivative key. Compared with the encryption by directly adopting the initial key, the derivative key can increase the randomness, thereby improving the difficulty of being broken and being beneficial to optimizing the safety protection of the data. The impact factor may be related to the transaction; for example, the influencing factor may include a specified bit of the transaction hash value, such as the first blockchain node 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 blockchain node may also encrypt the plaintext receipt data using an asymmetric encryption scheme, i.e., using a public key of an asymmetric encryption algorithm, and accordingly, the client may decrypt the ciphertext receipt data using a private key of the asymmetric encryption algorithm. The key of the asymmetric encryption algorithm may be, for example, a pair of public and private keys generated by the client and sent in advance to the first blockchain node so that the first blockchain node can encrypt the plaintext receipt data with the public key.

Although the first blockchain node may encrypt the plain text receipt data corresponding to all transactions, the needs of different users are often different, for example, a part of users are relatively more focused on efficiency and can accept to store the plain text receipt data, another part of users are relatively more focused on privacy and can accept the influence of encryption and decryption of the receipt data on efficiency, so that whether the plain text receipt data needs to be encrypted or not can be determined according to different scenes.

The client, upon generating the transactions, may have one or more corresponding smart contracts for each transaction. Accordingly, the plaintext receipt data generated by the execution of the transaction may include plaintext receipt sub-data corresponding to each smart contract, respectively. When a user generates a transaction, whether plaintext receipt sub-data corresponding to each intelligent contract needs to be encrypted or not can be respectively determined, and a corresponding encryption identifier is added for the intelligent contract needing to be encrypted. Compared with the transaction containing the encrypted identifier, the embodiment can realize contract-level security protection, has relatively finer granularity and can realize better security protection effect. Then, the first blockchain node may encrypt the plaintext receipt sub-data corresponding to the smart contract for which the encryption identification exists, while the plaintext receipt sub-data corresponding to the smart contract for which the encryption identification does not exist does not need to be encrypted. The encrypted identifier added for each smart contract should be clear text information so that after the first block link point receives the transaction, it can be identified by a "transaction/query interface" module such as that shown in fig. 2 to determine whether at least one smart contract has the corresponding encrypted identifier, and specifically which smart contracts have the corresponding encrypted identifier and which do not.

When the first block link point determines that at least one intelligent contract corresponding to the transaction has the encrypted identification, the transaction can be transmitted into 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 plaintext receipt sub-data respectively corresponding to each intelligent contract can be obtained; if the transaction is a private transaction, the corresponding plaintext transaction content can be decrypted in the trusted execution environment and executed in the trusted execution environment, so that plaintext receipt sub-data respectively corresponding to each intelligent contract is obtained. Then, the first blockchain node may encrypt the plaintext receipt sub-data corresponding to the smart contract with the encryption identifier to obtain corresponding ciphertext receipt sub-data, where encryption is not required for the plaintext receipt sub-data corresponding to the smart contract without the encryption identifier.

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

The first blockchain node obtains corresponding plaintext receipt data by executing a transaction, encrypts the plaintext receipt data into corresponding ciphertext receipt data by a secret key, and can actively feed back the ciphertext receipt data to a client side initiating the transaction to serve as a receipt of the transaction. The first blockchain node may store the cryptogram receipt data such that the client may request and obtain the cryptogram receipt data from the first blockchain node at any time. Of course, if the plaintext receipt data corresponding to the transaction does not need to be encrypted, the first blockchain node may return the plaintext receipt data to the client, or the first blockchain node may store the plaintext receipt data and return the plaintext receipt data based on the response of the client.

The first blockchain node 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 also needs to be executed. And for code executing in a trusted execution environment, the code needs to meet the relevant specifications and requirements of the trusted execution environment; accordingly, for the code for implementing a certain function in the related art, code writing needs to be re-performed in combination with specifications and requirements of a trusted execution environment, so that a relatively large development amount exists, and loopholes (bugs) are easily generated in the re-writing process, thereby influencing the reliability and stability of the implementation of the function.

Therefore, the first blockchain node may store the ciphertext receipt data generated in the trusted execution environment to an external storage space outside the trusted execution environment by executing the storage function code outside the trusted execution environment (of course, the storage function code may not need encryption, and the storage function code may also store the part of plaintext receipt data to the external storage space; taking the storage process of the ciphertext receipt data as an example here for illustration), so that the storage function code may be code for implementing the storage function in the related art, and may implement safe and reliable storage for the ciphertext receipt data without combining with the specification and the requirement of the trusted execution environment, thereby not only reducing the development amount of relevant code on the basis of not affecting the safety and reliability, but also reducing the TCB (Trusted Computing Base ) by reducing the relevant code of the trusted execution environment, and enabling the additional safety risk caused in the process of combining the TEE technology with the blockchain technology to be in a controllable range.

In one embodiment, the first blockchain node may execute write caching function code within the trusted execution environment to store the plaintext 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 store the encrypted data in the external storage space. The write cache function code can be stored in a plaintext form in the trusted execution environment, and the cache function code in the plaintext form can be directly executed in the trusted execution environment; or, 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 (such as "packing+storing" shown in fig. 2, where "packing" indicates that the first blockchain 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 into plaintext code in the trusted execution environment, and executed.

Write caching refers to a "buffering" mechanism provided to avoid causing a "shock" to the external storage space when writing data to the external storage space. For example, the write cache described above may be implemented using buffers; of course, the write cache may also be implemented by using a cache, which is not limited in this specification. In practice, since the trusted execution environment is an isolated safe environment and the external storage space is located outside the trusted execution environment, the data in the cache can be written into the external storage space in batches by adopting a write cache 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 the generated data in the process of continuously executing each piece of plaintext transaction content, if the data to be called is just in the write cache, the data can be directly read from the write cache, so that interaction with an external storage space can be reduced, and on the other hand, the decryption process of the data read from the external storage space is omitted, thereby improving the data processing efficiency in the trusted execution environment.

Of course, the write cache may also be established outside the trusted execution environment, for example, the first blockchain node may execute the write cache function code outside the trusted execution environment, thereby storing the ciphertext receipt data into the write cache outside the trusted execution environment, and further storing the data in the write cache into the external storage space.

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

For example, the first blockchain node may read the ciphertext receipt data from the external storage space and return the encrypted plaintext receipt data to the client via the transaction/inquiry interface shown in fig. 2.

For another example, the first blockchain node may read the plaintext receipt data from a read cache within the trusted execution environment and encrypt the plaintext receipt data for output from the trusted execution environment; and the plaintext receipt data is read from the external storage space into the plaintext receipt data, and then read into the trusted execution environment and stored into the read cache. In other words, after the first blockchain node reads the ciphertext receipt data from the external storage space and decrypts the ciphertext receipt data into the plaintext receipt data, the plaintext receipt data may be stored in a read cache in the trusted execution environment by executing a read cache function code in the trusted execution environment, for example, the read cache may correspond to the "cache" shown in fig. 2; further, for the query request initiated by the client or for the data required by the trusted execution environment when executing the plaintext transaction content, the data can be preferentially read from the read cache, and if the related data can be read, the data does not need to be read from the external storage space, so that the interaction times with the external storage space are reduced, and the data decryption process is avoided.

The read cache refers to that after data is read into the trusted execution environment from the external storage space, in order to reduce the number of interactions with the external storage space, the read data can be stored in a plaintext form in the read cache space in the trusted execution environment. For example, the above-mentioned read cache may be implemented by using a cache; of course, the read buffer may also be implemented by using buffer, which is not limited in this specification.

The first blockchain node may support both the read caching mechanism and the write caching mechanism described above. With the continuous development of the cache technology, the same cache may not only be used to implement data reading or data writing, but also support data reading and writing operations at the same time, so that the boundary between the read cache and the write cache is sometimes not quite clear, and thus, fig. 2 only illustrates the cache, but does not specifically distinguish the specific types thereof, and may be configured and adjusted according to actual requirements.

Of course, the above-mentioned caching mechanism in the trusted execution environment may be applied to a conventional execution environment, for example, implemented by "caching" in the conventional execution environment shown in fig. 2, where, however, data reading and writing only involves plaintext reading and writing, and data encryption and decryption operations need not be implemented, which is not repeated herein.

An embodiment of a node for implementing a hybrid transaction in a blockchain is described in this specification with reference to fig. 3, including:

a receiving unit 301, configured to receive a transaction initiated by a client, where one or more corresponding smart contracts exist in the transaction;

an execution unit 302 for the transaction to obtain plain text receipt data, the plain text receipt data including plain text receipt sub-data corresponding to each smart contract, respectively;

an encrypting unit 303, configured to encrypt, when it is determined that the encryption identifier exists in the first smart contract corresponding to the transaction, plaintext Wen Shouju sub-data corresponding to the first smart contract into ciphertext receipt sub-data using a key, where ciphertext receipt data corresponding to the plaintext receipt data includes the ciphertext receipt sub-data;

and a storage unit 304 for storing the cryptogram receipt data.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of 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, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, 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 of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, 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 functionally divided into various units, respectively. Of course, the functions of each element may be implemented in one or more software and/or hardware elements when implemented in the present specification.

It will be appreciated by those skilled in the art that 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 flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations 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.

The 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 volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

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 storage media for a computer 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, read only 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 or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

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 one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can 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 are also possible or may be advantageous.

The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments 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 or 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, these 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 of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.

The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.

Claims

1. A method of implementing privacy protection in a blockchain, comprising:

the block link point receives a transaction initiated by a client, wherein one or more corresponding intelligent contracts exist in the transaction;

performing the transaction by block link points to obtain plain text receipt data, the plain text receipt data including plain text receipt sub-data corresponding to respective intelligent contracts;

when determining that the encryption identifier exists in the first intelligent contract corresponding to the transaction, the blockchain node encrypts the plaintext Wen Shouju subdata corresponding to the first intelligent contract into ciphertext receipt subdata by using a secret key, wherein the ciphertext receipt data corresponding to the plaintext receipt data comprises the ciphertext receipt subdata; when the encryption identifier does not exist in the second intelligent contract corresponding to the transaction, the ciphertext receipt data comprises plaintext receipt sub-data corresponding to the second intelligent contract;

The block link point stores the cryptogram receipt data.

2. The method of claim 1, further comprising:

when determining that all intelligent contracts corresponding to the transaction do not have encryption identifications, the blockchain node identifies the type of the transaction;

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

the block link point stores the resulting plain text receipt data.

3. The method of claim 2, the identifying the type of transaction comprising:

determining the type of the transaction according to the value of the type field of the plaintext in the transaction; wherein the first value of the type field is used to indicate that the transaction is a clear text transaction and the second value of the type field is used to indicate that the transaction is a private transaction.

4. The method according to claim 2,

the executing the plaintext transaction content in the trusted execution environment comprises: executing the plaintext transaction content by a virtual machine deployed in the trusted execution environment;

Said executing said plain text transaction outside of a trusted execution environment comprising: and executing the plaintext transaction by a virtual machine deployed in a conventional execution environment outside the trusted execution environment.

5. The method of claim 1, further comprising:

when any intelligent contract is added with the encryption identification, the blockchain node determines that the encryption identification exists in any intelligent contract.

6. The method of claim 1, block link points performing the transaction, comprising:

when determining that at least one intelligent contract corresponding to the transaction has an encryption identifier, the blockchain node executes the transaction in a trusted execution environment;

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

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

8. The method of claim 7, 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 an influence factor.

9. The method of claim 8, 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;

The block link point adopts the private key of the asymmetric encryption algorithm to decrypt to obtain the initial key, and adopts the initial key to decrypt the private transaction to obtain the plaintext transaction content, and the plaintext transaction content is executed to obtain the plaintext receipt data.

10. The method of claim 8, the impact factor being related to the transaction.

11. The method of claim 10, the impact factor comprising: the hash value of the transaction is specified in bits.

12. The method of claim 1, the block link point storing cryptogram receipt data, comprising:

the blockchain node executes storage function code outside of the trusted execution environment to store the cryptograph receipt data to an external storage space outside of the trusted execution environment.

13. The method of claim 1, further comprising:

the blockchain node executes write cache function codes in a trusted execution environment to store the plaintext receipt data into a write cache in the trusted execution environment;

and the block chain link encrypts the plaintext receipt data in the write cache and outputs the encrypted plaintext receipt data from the trusted execution environment to be stored in an external storage space outside the trusted execution environment.

14. The method of claim 13, the write cache function code being stored in plain text form in the trusted execution environment; or, the write cache function code is stored outside the trusted execution environment in a ciphertext form.

15. The method of claim 1, the cryptogram receipt data being used to calculate a root of a receipt tree, the root being contained in a block header of a block in which the exchange is located.

16. The method of claim 1, the transaction creation and/or invocation of the smart contract being validated as corresponding to the transaction.

17. A node in a blockchain that implements privacy protection, comprising:

an execution unit for the transaction to obtain plain text receipt data, the plain text receipt data including plain text receipt sub-data corresponding to respective smart contracts;

an encryption unit, configured to encrypt, using a key, plaintext Wen Shouju subdata corresponding to a first intelligent contract corresponding to the transaction into ciphertext receipt subdata when it is determined that the encryption identifier exists in the first intelligent contract, where ciphertext receipt data corresponding to the plaintext receipt data includes the ciphertext receipt subdata; when the encryption identifier does not exist in the second intelligent contract corresponding to the transaction, the ciphertext receipt data comprises plaintext receipt sub-data corresponding to the second intelligent contract;

And the storage unit is used for storing the ciphertext receipt data.

18. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-16.