CN110032883B

CN110032883B - Method, system and node for realizing privacy protection in block chain

Info

Publication number: CN110032883B
Application number: CN201910100724.6A
Authority: CN
Inventors: 闫莺; 魏长征
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-01-31
Filing date: 2019-01-31
Publication date: 2020-05-29
Anticipated expiration: 2039-01-31
Also published as: CN110032883A

Abstract

The embodiment of the specification provides a method, a system and a node for realizing privacy protection in a block chain, and the method can comprise the following steps: the client encrypts the transaction and sends the encrypted transaction to a first block chain node, wherein a code of an intelligent contract corresponding to the transaction comprises a contract state marked by a privacy identifier and an access condition aiming at the contract state marked by the privacy identifier; code that decrypts the transaction to determine a corresponding smart contract, the code that executes the smart contract in a trusted execution environment; encrypting with a key while storing the contract status indicated by the privacy identifier; determining that the access condition is satisfied in response to an access request for a contractual state designated by the privacy identifier.

Description

Method, system and node for realizing privacy protection in block chain

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method, system, and node 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 play a role of a black box in hardware, a code and data operating system layer executed in the TEE cannot be peeped, and the TEE can be operated only through an interface defined in advance in the code. In the aspect of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptography operation in homomorphic encryption, and the efficiency of the calculation process is not lost, so that the safety and privacy of a block chain can be improved to a great extent on the premise of small performance loss by combining with the TEE. The industry is concerned with TEE solutions, and almost all mainstream chip and Software consortiums have their own TEE solutions, including Software-oriented TPM (Trusted Platform Module) and hardware-oriented Intel SGX (Software Guard Extensions), ARM Trustzone (Trusted zone), and AMD PSP (Platform Security Processor).

The intelligent contract appearing in the 2.0 era of the block chain promotes the application range of the block chain to a new height. With intelligent contracts, the blockchain can do no longer a single transfer transaction, but can also invoke a piece of code, which can be customized by the user.

In a traditional solution combining a blockchain and a TEE, in order to realize privacy protection, an intelligent contract is wholly regarded as data needing privacy protection to be operated in the TEE, and all contract states are stored on the blockchain in an encrypted mode. In fact, some contents in the intelligent contract may be sensitive so as to need privacy protection, and other contents are not sensitive and can be disclosed.

Disclosure of Invention

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

One or more embodiments of the present disclosure provide the following:

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 client encrypts the transaction and sends the encrypted transaction to a first block chain node, wherein a code of an intelligent contract corresponding to the transaction comprises a contract state marked by a privacy identifier and an access condition aiming at the contract state marked by the privacy identifier;

code that decrypts the transaction to determine a corresponding smart contract, the code that executes the smart contract in a trusted execution environment; encrypting with a key while storing the contract status indicated by the privacy identifier; determining that the access condition is satisfied in response to an access request for a contractual state designated by the privacy identifier.

According to a second 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 node receives encrypted transactions, and the codes of the intelligent contracts corresponding to the transactions comprise contract states marked by privacy identifiers and access conditions aiming at the contract states marked by the privacy identifiers;

code for the first block link point to decrypt the transaction to determine a corresponding smart contract;

code for a first blockchain node to execute the intelligent contract in a trusted execution environment; encrypting with a key while storing the contract status indicated by the privacy identifier; determining that the access condition is satisfied in response to an access request for a contractual state designated by the privacy identifier.

According to a third aspect of one or more embodiments of the present specification, a system for implementing privacy protection in a blockchain is provided, including a client and a first blockchain node, where:

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

the receiving unit is used for receiving the encrypted transaction, and the code of the intelligent contract corresponding to the transaction comprises contract state marked by a privacy identifier and access conditions aiming at the contract state marked by the privacy identifier;

a decryption unit for decrypting the transaction to determine the code of the corresponding smart contract;

an execution unit to execute code of the intelligent contract in a trusted execution environment;

an encryption unit configured to encrypt with a key when storing the contract status indicated by the privacy identifier;

a determination unit configured to determine that the access condition is satisfied in response to an access request for a contract state designated by the privacy identifier.

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

a processor;

a memory for storing processor-executable instructions;

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

According to a sixth aspect of one or more embodiments of the present specification, 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 second aspect as described above.

Drawings

FIG. 1 is a diagrammatic process of creating an intelligent contract of one embodiment of the present description;

FIG. 2 is a diagram process of invoking an intelligent contract, according to one embodiment of the present description;

FIG. 3 is a schematic diagram of creating an intelligent contract and invoking an intelligent contract in one embodiment of the present description;

FIG. 4 is a flow chart of one embodiment of a method of implementing privacy protection herein;

FIG. 5 is a flow chart of one embodiment of a method of implementing privacy protection herein;

FIG. 6 is a block diagram of an embodiment of a system implementing privacy protection in accordance with the present disclosure;

fig. 7 is a block diagram of an embodiment of a node implementing privacy protection according to the present disclosure.

Detailed Description

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

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

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

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

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

For example, as shown in fig. 1, after Bob sends a transaction containing information to create an intelligent contract to the ethernet network, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The data field of the transaction is stored with the byte code, and the to field of the transaction is an empty account. After the agreement is achieved between the nodes through the consensus mechanism, the contract is successfully created, and the subsequent user can call the contract.

After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address, and the contract code and the account storage are stored in the contract account. The behavior of the intelligent contract is controlled by the contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, an intelligent contract causes a virtual account to be generated on a blockchain that contains a contract code and an account store (Storage).

As mentioned above, the data field containing the transaction that created the smart contract holds what may be the byte code of the smart contract. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. The intelligent contract code written by the high-level language is compiled by a compiler to generate byte codes, and the byte codes can be deployed on the block chain. The high-level languages supported by Etherns are many, such as Solidity, Serpent, LLL, etc.

Taking the Solidity language as an example, the contract written by the method is similar to a Class (Class) in an object-oriented programming language, and various members including state variables, functions, function modifiers, events and the like can be declared in one contract. A state variable is a value permanently stored in the account storage of a smart contract that is used to save the state of the contract.

The following code example 1 is a simple intelligent contract written in the Solidity language:

generally, after the contract is deployed in a blockchain, the storage state corresponding to the state variable of "balance" is plaintext, and anyone can see the state without setting and capability of privacy protection. If a user wants to protect the state privacy, the current solution of zero knowledge proof and homomorphic encryption needs to rewrite the contract, so that the state variable of balance is protected by encryption and all operations of balance in an encryption domain need to be supported. Generally, the encryption method is complex in operation, and it is difficult to design a proper algorithm to support the encryption domain. In some solutions where blockchains are combined with TEE, all contract states of the intelligent contract are stored on the blockchain as data requiring privacy protection in order to achieve privacy protection. The block chain is a data set organized by specific logics stored in a database of nodes. The database, as described later, may be a storage medium, such as a persistent storage medium, in physical carrier. In fact, in the intelligent contract, privacy protection is only needed if the contract state of "balance" is sensitive, and other contents are not sensitive and can be disclosed.

Further, as shown in fig. 2, still taking the ethernet house as an example, after Bob sends a transaction containing the information of invoking the intelligent contract to the ethernet house network, the EVM of node 1 may execute the transaction and generate the corresponding contract instance. The from field of the transaction in fig. 2 is the address of the account from which the intelligent contract was initiated, the "0 x692a70d2 …" in the to field represents the address of the intelligent contract being invoked, the value field is the value in the etherhouse in the tai-currency, and the data field of the transaction holds the method and parameters for invoking the intelligent contract. After invoking the smart contract, the value of balance may change. Subsequently, a certain client can check the current value of balance through a certain block link point.

The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is completed, transaction certificates which cannot be tampered and cannot be lost are stored on the blockchain.

A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. An intelligent contract is created in an Ethernet workshop and needs to be subjected to the processes of compiling the intelligent contract, changing the intelligent contract into byte codes, deploying the intelligent contract to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, and the intelligent contract codes are operated in the virtual machine of each node in the Ethernet workshop in a distributed mode.

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

s402: the client encrypts the transaction and sends the encrypted transaction to the first block chain node, wherein a code of an intelligent contract corresponding to the transaction comprises a contract state marked by a privacy identifier and an access condition aiming at the contract state marked by the privacy identifier.

In the process of writing intelligent contract code, a privacy identifier may be employed to identify contract states that require privacy protection.

For example, in the case of writing "create intelligent contract" in the identity language, during the writing process, a privacy identifier may be used to identify a contract state that requires privacy protection. The contract states here are, for example, state variables in a programming language. Similarly, in the process of writing intelligent contracts in Serpent, LLL language, etc., the privacy identifier may also be used to identify state variables that need privacy protection.

The Solidity language currently mainly supports state variable types that may be: boolean, integrators, FixedPoint Numbers, Address, Fixed-size byte array, Address Literals, Rational addressing Literals, String Literals, Hexadecimal Literals, Enums.

The privacy identifier may be an identifier specifically indicating that privacy protection is required, for example, as indicated by a keyword such as configertial. Then, if the state variables supported by the above-mentioned solid language are to be protected in privacy, a privacy identifier of Confidential can be added in the front. Thus, the state variables that need privacy protection can be indicated by prefix of the configfinal. For example, the type of state variable that the identity language supports privacy protection may be: configurable Booleans, configurable integrators, configurable Fixed Point addresses, configurable Address addresses, configurable Fixed-size byte array, configurable Address weights, configurable Ration and integer weights, configurable Structural weights, configurable Hexademal weights, and configurable Enums.

For the above-mentioned code example 1, if "balance" is to be protected in privacy, it may be indicated by the privacy identifier confident before the type int defining balance (of course, the privacy identifier confident may also be placed after the type int defining balance), as shown in the following code example 2 (the underlined part represents the privacy identifier):

the state variable needing privacy protection is identified based on the privacy identifier, so that after the intelligent contract code is read by the first block chain node, privacy protection can be performed on a contract state corresponding to balance, for example, the contract state corresponding to balance is encrypted by a key and then stored, and for example, the contract state corresponding to balance can be stored in a database corresponding to the first block chain node.

The state variable marked by the privacy identifier and needing privacy protection is encrypted and stored, so that the plaintext value of the state variable can be obtained only by mastering the key adopted during encryption. But may result in an increased risk of leakage of the contracted state if the first blockchain node can be initiated with an access operation to the encrypted state variable on purpose.

Therefore, in the process of writing the intelligent contract code, for the contract state needing privacy protection, an access condition for the contract state needing privacy protection can be further added, so that when a user accesses the contract state needing privacy protection, corresponding access control can be realized, and random access is limited.

The access conditions added in the intelligent contract code may include personnel restrictions, i.e., access right management for different personnel. For example, an access white list may be defined, so that when an initiator of an access request is in the access white list corresponding to the contract state indicated by the privacy identifier, the initiator responds to the access request, otherwise, the initiator rejects the response or takes other limiting measures.

Taking the code example 2 as an example, if access control needs to be performed on "balance" protected by privacy, a relevant description may be added to the getBalance function, as shown in the following code example 3:

in this code example 3, an access white list is defined as "allowedreads," and only when a user located in the allowedreads initiates an access request, the first blockchain node returns a value of balance, otherwise, returns null.

Similarly, an access blacklist may be defined such that an initiator of an access request does not respond to the access request when the initiator is not in the access blacklist corresponding to the contract state indicated by the privacy identifier, and otherwise, the response may be rejected or other limiting measures may be taken. Still taking the code example 2 as an example, if access control needs to be performed on "balance" protected by privacy, a relevant description may be added to the getBalance function, as shown in the following code example 4:

in this code example 4, an access blacklist is defined as "forbidden reads", and when a user in the forbidden read initiates an access request, the first block link point will return to null, and when other users initiate access requests, the first block link point will return to the value of balance.

In the above embodiment, the access white list or the access black list may be directly recorded in the intelligent contract code; in other words, the user may add the above-described access white list or access black list to the intelligent contract code when writing the above-described intelligent contract code. Alternatively, the access white list or access black list may be recorded in another intelligent contract, and the access white list or access black list recorded in the another intelligent contract may be called in the intelligent contract code.

The access conditions added in the intelligent contract code may include state restrictions, i.e., the management of access operations according to the contract state.

The access authority of the contract state needing privacy protection can be limited according to the value of the contract state needing privacy protection; for example, a first preset threshold may be defined in the intelligent contract code, so that when the value of the contract state requiring privacy protection reaches the first preset threshold, access to the contract state requiring privacy protection is allowed, otherwise, access is not allowed. According to the value change condition of the contract state needing privacy protection, the first preset threshold value can be a value upper limit and/or a value lower limit.

For example, a reasonable value range may exist for a contract state requiring privacy protection, and the first preset threshold may be a boundary value of the reasonable value range. Therefore, when the value of the contract state needing to be protected is in a reasonable value range and does not reach the first preset threshold value, the contract state needing to be protected can be prevented from being accessed; and when the value of the contract state needing to be protected reaches the first preset threshold, the value is beyond a reasonable value range, and the contract state needing to be protected can be allowed to be accessed.

The access authority of the contract state needing privacy protection can be limited according to the values of other contract states different from the contract state needing privacy protection; for example, a second preset threshold may be defined in the intelligent contract code, so that when the value of the other contract state reaches the second preset threshold, access to the contract state requiring privacy protection is allowed, otherwise, access is not allowed. According to the value change condition of the contract state needing privacy protection, the second preset threshold value can be a value upper limit and/or a value lower limit.

The contract state needing privacy protection and the state variables corresponding to the other contract states can be positioned in the code of the same intelligent contract; alternatively, an intelligent contract in which the contract state requiring privacy protection is located may make a call to another intelligent contract, and the state variables corresponding to the other contract state may be located in the other intelligent contract.

The contract state needing privacy protection and the other contract states can have certain association, so that the access operation of the contract state needing privacy protection can be controlled based on the values of the other contract states. For example, a certain numerical relationship may be satisfied between the contract state requiring privacy protection and the other contract state, and when the other contract state does not reach the second preset threshold, it indicates that the value of the contract state requiring privacy protection is in a reasonable value range, and access to the contract state requiring privacy protection may be prevented; and when the other contract states reach a second preset threshold value, the value of the contract state needing privacy protection is beyond a reasonable value range, and the contract state needing privacy protection can be allowed to be accessed.

The access condition may comprise multiple types of conditions. For example, the access condition may include both the above-mentioned person restriction condition and status restriction condition, and the relationship between these conditions may be "and" or "for realizing access control to the contract status requiring privacy protection. When the relation of 'and' is adopted among a plurality of conditions, the contract state needing privacy protection can be accessed only when the conditions are simultaneously met; when the relation of 'OR' is adopted among a plurality of conditions, only at least one of the conditions is needed to be met, and the contract state needing privacy protection can be accessed.

The intelligent contract in the transaction received by the first blockchain node can be an intelligent contract written by a user in a high-level language on the first blockchain node, can also be an intelligent contract written by the user in the high-level language on a client, and can also be an intelligent contract in the transaction sent by the second blockchain node. Specifically, the intelligent contract in the transaction sent by the client through the second blockchain node may be used.

As previously mentioned, the smart contracts deployed on blockchains are typically in the form of bytecodes. If the intelligent contract is written by the user in the high-level language on the first block chain node, the first block chain node can also adopt a compiler to compile the intelligent contract written in the high-level language to generate byte codes. If an intelligent contract written by a user in a high-level language on a client is received, the intelligent contract written by the user in the high-level language can be compiled by the client by adopting a compiler to generate a byte code after the intelligent contract written by the user in the client is written by the user, and the intelligent contract in the byte code form is sent to a first block chain node, so that the intelligent contract in the byte code form is received by the first block chain node. In addition, after the user writes the intelligent contract on the client, the intelligent contract written in the high-level language can be directly sent to the first block chain node, and then the first block chain node can adopt the compiler to compile the intelligent contract written in the high-level language to generate the byte code. For the intelligent contract in the transaction sent by the second blockchain node and received by the first blockchain node, the intelligent contract is generally in the form of byte codes; of course, the first block link point may be an intelligent contract written in a high-level language, and the intelligent contract written in the high-level language may be compiled by a compiler to generate a bytecode.

In the process of compiling the intelligent contract written in the high-level language by the compiler, the compiler needs to be adjusted to process the contract state marked by the privacy identifier.

For the C () function part of the intelligent contract written in the conventional solid language in code example 1, the compiler compilation result is, for example, code example 5 shown below (the part … in/… is a comment, and the following part is a corresponding chinese comment if a chinese character is present):

/component function C () balance + ═ 1 compilation function C () balance + ═ 1 ═ greater/greater

tag_2

/pushes 1onto stack pushes 1 to the top of the stack, which 1 is the 1/will be assigned

0x1

/' pushies 0onto stack pushes 0 to the top of the stack, this 0 refers to balance which data is to be stored to position 0 of the contract account data store. After the two sentences are executed, two data items 0 and 1 are located from the top to the bottom in the stack

0x0

V balance +1 assigns balance to a value after balance +1 +

dup 2/. copy the second term from the top down in the stack, so this time the stack has three data items 1, 0, 1 from the top up >

swap 1/swap two items of data at the top of the stack, when the stack stores 0, 1 ×/greater/less

Store (0x0,0x1), counting down from the top of the stack, stores the second item data in the location identified by the first item, and pops both items off the stack. Here, data 1 is stored in the position 0, and since balance is already bound to the position 0, the assignment of balance 1 is completed. There is only one layer of data left in the stack: 1*/

sstore

pop/discard the top of stack data, when the stack becomes empty, waiting for the next instruction to execute ++

For the intelligent contract written in the solid language containing the privacy identifier to indicate the contract status in code example 2, the compiler compiled the result as shown in code example 6 (the part … in/… is a comment, and the chinese characters are corresponding chinese):

tag_2

0x1

0x0

V balance +1 assigns balance to a value after balance +1 +

And/or the Confidential _ sstore (0x0,0x1) encrypts and stores (0x0,0x1) the second item of data from the top of the stack to the position identified by the first item, and pops the two items out of the stack. Here, data 1 is stored in position 0, and balance has been previously bound to position 0, so that the assignment of balance being 1 is completed here. There is only one layer of data left in the stack: 1*/

Confidential_sstore

In the above byte code, the contract status balance that needs privacy protection is indicated by the privacy identifier configural.

The byte code also uses the keyword of Confidential to indicate the operation that needs privacy protection, which is the same as the intelligent contract written in the solid language, i.e. the same as the code example 2. It will be appreciated by those skilled in the art that different privacy identifiers may be employed in the bytecode than in code example 2, i.e., different privacy identifiers may be employed in the bytecode than in code written in a high-level language. If the bytecode is a privacy identifier in a code different from the code written in the high-level language, assuming that the privacy identifier in the code written in the high-level language is a first privacy identifier and the privacy identifier in the bytecode-form code is a second privacy identifier, the first privacy identifier and the second privacy identifier have a corresponding relationship.

As described above, if the user writes the intelligent contract in the high-level language directly on the first blockchain node, that is, the intelligent contract corresponding to the transaction received by the first blockchain node is written in the high-level language, the first blockchain node may also use the compiler to compile the intelligent contract written in the high-level language to generate the bytecode. In the generated intelligent contract in the form of byte codes, contract states needing privacy protection are marked in the intelligent contract codes through privacy identifiers. The intelligent contract written in the high-level language comprises contract states needing privacy protection marked by privacy identifiers. The privacy identifier in the code written in the high-level language corresponds to the privacy identifier in the code in bytecode form.

If the user writes the intelligent contract written by the high-level language on the client, the client can also adopt the compiler to compile the intelligent contract written by the high-level language to generate byte codes after the user writes the intelligent contract on the client, and then the intelligent contract in the form of the byte codes is sent to the first block chain node. Thus, when the first block link point receives a transaction, the intelligent contract corresponding to the transaction is the intelligent contract in the form of byte codes. The intelligent contract in the form of byte codes comprises contract states which need privacy protection and are marked through privacy identifiers. The intelligent contract written in the high-level language comprises contract states needing privacy protection marked by privacy identifiers. The privacy identifier in the code written in the high-level language corresponds to the privacy identifier in the code in bytecode form.

In addition, after the user writes the intelligent contract on the client, the intelligent contract written in the high-level language can be directly sent to the first blockchain node. The intelligent contract written in the high-level language comprises contract states needing privacy protection marked by privacy identifiers. Furthermore, the first block link point may be compiled by a compiler for an intelligent contract written in a high-level language to generate a bytecode. In the generated intelligent contract in the form of byte codes, contract states needing privacy protection are marked in the intelligent contract codes through privacy identifiers. The privacy identifier in the code written in the high-level language corresponds to the privacy identifier in the code in bytecode form.

As mentioned above, the intelligent contract received by the first blockchain node in the transaction sent by the second blockchain node is generally a byte code intelligent contract, and certainly does not exclude a high level language intelligent contract. Which may be further compiled by the first blockchain node to form a bytecode. Similarly, the privacy identifier in the latter high-level language written code corresponds to the privacy identifier in the bytecode-form code.

The client may encrypt the transaction containing the creation of the smart contract with a key. The encryption can adopt symmetric encryption or asymmetric encryption. The encryption algorithm used for symmetric encryption is, for example, DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc. Examples of asymmetric encryption algorithms are RSA, Elgamal, knapsack Algorithm, Rabin, D-H, ECC (elliptic curve encryption Algorithm), etc.

Alternatively, the client may encrypt the transaction containing the creation of the smart contract with a key, or may combine symmetric encryption with asymmetric encryption. For example, the client encrypts the transaction content using a symmetric encryption algorithm, i.e., encrypting the transaction containing the creation of the smart contract using the private key of the symmetric encryption algorithm, and encrypting the private key used in the symmetric encryption algorithm using an asymmetric encryption algorithm. Generally, a private key of an asymmetric encryption algorithm is used to encrypt a private 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 private key of the symmetric encryption algorithm, and then decrypt by using the private key of the symmetric encryption algorithm to obtain the transaction content, so that the code for creating the intelligent contract is obtained.

The first block link point receives a transaction containing an intelligent contract whose code includes a contract state that requires privacy protection as indicated by a privacy identifier.

The transaction sent by the client to the first blockchain node may also be a transaction involving invoking an intelligent contract. For this case, the client may encrypt the transaction containing the invoked smart contract with the key and send the encrypted transaction to the first blockchain node. The called intelligent contract may include a contract state that is indicated by a privacy identifier. The transaction may include a contract address of the invoked smart contract, and the associated smart contract may be invoked based on the contract address to obtain the code included in the smart contract. The called intelligent contract can call other intelligent contracts; alternatively, the transaction may include code for smart contracts that may make calls to other smart contracts to form a multiple nested structure between the smart contracts. When a multiple nested structure is implemented between intelligent contracts, for example, the code in the intelligent contract 1 calls the intelligent contract 2, and the code in the intelligent contract 2 points to the contract address 3 generated by creating the intelligent contract code, so that the calling of the code in the intelligent contract 1 indirectly calls the intelligent contract code in the contract address 3, and the contract state indicated by the privacy identifier may be included in the code in the contract address 3. This corresponds to invoking a contract state indicated by a privacy identifier in the intelligent contract 1. The specific implementation process is similar to the above process, and is not described herein again.

The transaction sent by the client to the first blockchain node may also be a transaction involving the creation and invocation of a smart contract. For this case, the client may encrypt a transaction containing the creation and invocation of a smart contract with a key and send the encrypted transaction to the first blockchain node, the smart contract including a contract state indicated by the privacy identifier. The specific implementation process is similar to the above process, and is not described herein again.

S404: code that decrypts the transaction to determine a corresponding smart contract, the code that executes the smart contract in a trusted execution environment; encrypting with a key while storing the contract status indicated by the privacy identifier; determining that the access condition is satisfied in response to an access request for a contractual state designated by the privacy identifier.

As previously described, the transaction received by the first blockchain node may be, for example, a transaction used to create and/or invoke a smart contract. For example, in an ethernet, after receiving a transaction sent from a client, the first tile node may check whether the transaction is valid, whether the format is correct, whether the signature of the transaction is valid, and the like.

Typically, the nodes in the Etherhouse are also accounting contested nodes, and thus the first blockchain node can perform the transaction locally as accounting contested node. If one of the nodes competing for accounting rights wins the current round of accounting rights, the node becomes the accounting node. If the first block link point wins the accounting right in the current round, the first block link point becomes an accounting node; of course, the first block link point is not a billing node if it does not win in the process of competing for billing right in this round, and other nodes may become billing nodes.

An intelligent contract is similar to a class in object-oriented programming, with the result of execution generating a contract instance corresponding to the intelligent contract, similar to generating an object corresponding to a class. Executing code that creates intelligent contracts in a transaction creates a contract account and deploys the contracts in account space. In the etherhouse, the address of the intelligent contract account is generated by an encryption algorithm with the address of the sender (e.g., 0xf5e … in fig. 1 or 0x14c5f88a … in fig. 2) and the transaction random number (nonce) as inputs. The contract address in fig. 2 is generated by the sender's address 0x14c5f88a … and the nonce in the transaction via an encryption algorithm.

In general, in a blockchain network supporting intelligent contracts using consensus algorithms such as Proof of Work (POW) and Proof of equity (POS), Proof of commission (DPOS), nodes competing for accounting rights may execute a transaction including creation of an intelligent contract after receiving the transaction. One of the nodes competing for the accounting right wins the accounting right in the current round of the accounting right competition, and becomes the accounting node. The accounting node may package the transaction associated with the smart contract with other transactions and generate a new block, and send the generated new block to other nodes for consensus. Adopts the following steps of,

For a block chain network supporting an intelligent contract with a Practical Byzantine Fault Tolerance (PBFT) mechanism and the like, nodes with the accounting right are already agreed before accounting in the current round. Therefore, after the first block link node receives the transaction related to the intelligent contract, if the first block link node is not the accounting node of the current round, the transaction can be sent to the accounting node. For the accounting node (which may be the first blockchain node) of the current round, the transaction related to the intelligent contract may be executed during or before the process of packaging the transaction related to the intelligent contract and generating the new block, or during or before the process of packaging the transaction related to the intelligent contract with other transactions and generating the new block. After the accounting node packages the transaction related to the intelligent contract (or packages other transactions together), and generates a new block, the generated new block or a block header is sent to other nodes for consensus.

As described above, in the blockchain network supporting the intelligent contract using the POW mechanism or the blockchain network supporting the intelligent contract using the POS, DPOS, or PBFT mechanism, the accounting node in the current round may package the transaction related to the intelligent contract and generate a new block, and send the generated new block or a block header to other nodes for consensus. If no problem is verified after other nodes receive the block or the block header, the new block can be added to the tail of the original block chain, so that the accounting process is completed, consensus is achieved, and the deployment of the intelligent contract on the block chain network is completed. Other nodes can also execute transactions related to intelligent contracts in the blocks in the process of verifying the new blocks or block headers sent by the accounting node.

The execution process may be generally executed by a virtual Machine, such as an Ethernet Virtual Machine (EVM). Typically, the EVM executes an intelligent contract in the form of a bytecode. When the EVM executes to a sstore as in code example 5, conventionally, the contract state is written to the database in a key-value pair (key-value pair) manner. Expressed in code, such as setstore (key, value).

In this embodiment, the first block link point may execute the decrypted smart contract code 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 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.

As described in S402, the client may encrypt the transaction containing the associated smart contract with a key. The encryption can adopt symmetric encryption or asymmetric encryption. In S404, accordingly, the first tile link point may decrypt the transaction with the corresponding key. If the client encrypts the transaction with a symmetric encryption scheme, i.e. with the private key of the symmetric encryption algorithm, in S402, the first chunk link point can decrypt the transaction with the private key of the symmetric encryption algorithm, accordingly, in S404. The encryption algorithm used for symmetric encryption is, for example, DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc. The key of the symmetric encryption algorithm may be determined by client and first chunk link node negotiation, for example.

If the client encrypts the transaction associated with the smart contract in an asymmetric encryption manner, i.e., using the private key of the asymmetric encryption algorithm in S402, the first chunk node may decrypt the transaction using the private key of the asymmetric encryption algorithm in S404 accordingly. 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 partition node, and the public key is sent to the client before S402, so that the client may encrypt the key for the transaction in S402.

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 circle may be a QE (listening enclosure) circle, rather than an AE (Application enclosure) circle. For asymmetrically encrypted public keys, the client may be sent by a key management server. Thus, in S402, the client may encrypt the transaction related to the smart contract with the public key, and accordingly, the first block link point may decrypt the transaction with the private key to obtain the code of the smart contract included or invoked by the transaction.

As described in S402, the client may also adopt a combination of symmetric encryption and asymmetric encryption. For example, the client encrypts the transaction content by using a symmetric encryption algorithm, that is, encrypts the transaction related to the smart contract by using a private key of the symmetric encryption algorithm, and encrypts the private 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 private key used in the 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 private key of the symmetric encryption algorithm, and then decrypt by using the private key of the symmetric encryption algorithm to obtain the transaction content, so that the code of the intelligent contract can be obtained.

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. Thus, in S402, the client may encrypt the transaction content by using the private key of the symmetric encryption algorithm, that is, encrypt the transaction related to the smart contract by using the private key of the symmetric encryption algorithm, and encrypt the private key used in the symmetric encryption algorithm by using the public key of the asymmetric encryption algorithm. Furthermore, the client may send the encrypted transaction and the encrypted private key (obtained by encrypting the private key adopted in the symmetric encryption algorithm with the public key of the asymmetric encryption algorithm) to the first blockchain node. After the first block chain link point receives the encrypted 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 private key of a symmetric encryption algorithm, and then the transaction is decrypted by the private key of the symmetric encryption algorithm to obtain a transaction plaintext, so that a code plaintext of a related intelligent contract is determined; for the scene of creating the intelligent contract, the trade plaintext comprises the code plaintext used for creating the intelligent contract, for the scene of calling the intelligent contract, the trade plaintext comprises the intelligent contract code plaintext used for calling other intelligent contracts, or the trade plaintext comprises the address plaintext of the intelligent contract required to be called. The encryption method is generally called digital envelope encryption.

In this way, the first block link point may execute the code of the intelligent contract in plaintext in the trusted execution environment. Specifically, the first block link point may use a processor instruction newly added in the CPU, may allocate a part of the area EPC in the memory, and encrypt and store the decrypted plaintext code in the EPC through an encryption engine MEE in the CPU. The encrypted content in the EPC enters the CPU and is decrypted into plaintext. And in the CPU, operating the code of the plaintext to finish the execution process.

In SGX technology, the code that executes the intelligent contract may load the EVM into the enclosure. 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.

Generally, the contract state changes after the CPU executes the plaintext code. And executing plaintext code of the intelligent contract in a trusted execution environment, wherein the contract state indicated by the privacy identifier in the intelligent contract also changes.

The contract status is stored in the block chain, and from the perspective of the block link point, is written to a database, such as a local database. The database is typically stored on a storage medium, more commonly a persistent storage medium. The persistent storage medium may be a magnetic disk, a floppy disk, or a memory or the like which can restore data after being powered on so as to be persistently stored.

The operation of writing to the database is represented by a code, such as setstore (key, ENC (value, secret _ key)). In the setstore (key, ENC (value _ key)), the key (key) may be written in the same manner as a conventional key. As for the writing of value, Intel SGX technology may be used, ENC denotes enclave, and secret _ key denotes a key used when writing to the database in SGX technology. The key may be a symmetric encryption key, such as a seal (SimpleEncrypted arithmetric Library) key. The seal key may be sent to the first blockchain node by the key management server after remote certification, and may be obtained by negotiation between each node (e.g., the first blockchain node and other blockchain nodes) in the blockchain. The key may also be a key for asymmetric encryption. The key may be stored in a bounding box 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 circle may be a QE circle, rather than an AE circle.

In this way, contract states identified in the intelligent contract code by the privacy identifier may be stored encrypted in the database. For contract states in the intelligent contract code that are not identified by the privacy identifier, the contract states may still be stored in the database in the clear. Compared with the prior art that all contract states of an intelligent contract are operated in a TEE as data needing privacy protection and stored in a database, the embodiment can flexibly encrypt and store the contract states indicating privacy protection.

Meanwhile, the access condition aiming at the contract state needing privacy protection is added in the intelligent contract, so that when a user accesses the contract state needing privacy protection, the access operation of the user can be controlled based on the access condition, random access to the contract state needing privacy protection is limited, the leakage risk of the contract state is reduced, and the data security is improved.

Fig. 5 illustrates an embodiment of a method for implementing privacy protection in this specification. This embodiment focuses on describing the implementation from the perspective of the first blockchain node. As shown in fig. 5, the method embodiment comprises:

s502: the first block chain node receives encrypted transactions, and the codes of the intelligent contracts corresponding to the transactions comprise contract states marked by privacy identifiers and access conditions aiming at the contract states marked by the privacy identifiers.

As previously mentioned, the contract state may include state variables in code written in the programming language used. Taking the example that a user writes a "create intelligent contract" in the identity language, in the writing process, a privacy identifier may be used to identify a contract state that needs privacy protection. The contract states here are, for example, state variables in a programming language. The privacy identifier may be an identifier specifically indicating that privacy protection is required, for example, as indicated by a keyword such as configertial. Then, if the state variables supported by the above-mentioned solid language are to be protected in privacy, a privacy identifier of Confidential can be added in the front. Thus, the state variables that need privacy protection can be indicated by prefix of the configfinal.

As described above, in the process of writing the intelligent contract code, for the contract state requiring privacy protection, an access condition for the contract state requiring privacy protection may be further added, so that when a user accesses the contract state requiring privacy protection, corresponding access control may be implemented, and random access may be restricted. For example, the access condition may include a person limitation condition, a status limitation condition, or both the person limitation condition and the status limitation condition, and the access control to the access initiator may be performed effectively from one or more dimensions.

The intelligent contract corresponding to the transaction received by the first blockchain node may include:

the user writes an intelligent contract in a high-level language on a first block chain node; or the like, or, alternatively,

the user writes an intelligent contract in a high-level language on the client; or the like, or, alternatively,

and the intelligent contract in the transaction sent by the second blockchain node.

As previously mentioned, the smart contracts deployed on blockchains are typically in the form of bytecodes. If the user directly writes the intelligent contract in the high-level language on the first block chain node, the first block chain node can also adopt a compiler to compile the intelligent contract written in the high-level language to generate byte codes. If an intelligent contract written by a user in a high-level language on a client is received, the intelligent contract written by the user in the high-level language can be compiled by the client by adopting a compiler to generate a byte code after the intelligent contract written by the user in the client is written by the user, and the intelligent contract in the byte code form is sent to a first block chain node, so that the intelligent contract in the byte code form is received by the first block chain node. In addition, after the user writes the intelligent contract on the client, the intelligent contract written in the high-level language can be directly sent to the first block chain node, and then the first block chain node can adopt the compiler to compile the intelligent contract written in the high-level language to generate the byte code. For the intelligent contract in the transaction sent by the second blockchain node and received by the first blockchain node, the intelligent contract is generally in the form of byte codes; of course, the first block link point may be an intelligent contract written in a high-level language, and the intelligent contract written in the high-level language may be compiled by a compiler to generate a bytecode.

In the process of compiling the intelligent contract written in the high-level language by the compiler, the compiler needs to be adjusted to process the contract state marked by the privacy identifier. Please refer to fig. 4 for an embodiment. As in the foregoing code examples 5 and 6, the compiled bytecode also uses the keyword of configertial to indicate an operation that needs privacy protection, which is the same as that in the intelligent contract written in the solid language, i.e., the same as that in code example 2. It will be appreciated by those skilled in the art that different privacy identifiers may be employed in the bytecode than in code example 2, i.e., different privacy identifiers may be employed in the bytecode than in code written in a high-level language. Even if the privacy identifier in the bytecode is different from the privacy identifier in the code written in the high-level language, the first privacy identifier and the second privacy identifier have a corresponding relationship, assuming that the privacy identifier in the code written in the high-level language is the first privacy identifier and the privacy identifier in the code in the form of the bytecode is the second privacy identifier.

And the encrypted transaction related to the intelligent contract is received by the first blockchain node, wherein the encryption mode adopts a symmetric encryption mode or an asymmetric encryption mode, or adopts a mode of combining symmetric encryption and asymmetric encryption. For example, the client may encrypt the transaction with a key. The encryption can adopt symmetric encryption or asymmetric encryption. Alternatively, the client may use a combination of symmetric encryption and asymmetric encryption. When the transaction is encrypted by using the symmetrically encrypted private key, the first block chain node decrypts the transaction by using the corresponding symmetrically encrypted private key to obtain a code of the intelligent contract; or when the transaction is encrypted by the private key of the asymmetric encryption algorithm, the first block chain node decrypts the transaction by the private key of the corresponding asymmetric encryption algorithm to obtain the code of the intelligent contract. The symmetric encryption is combined with an asymmetric encryption mode, including a digital envelope encryption mode.

For the transaction containing the intelligent contract encrypted by the private key of the symmetric encryption algorithm, the private key adopted in the symmetric encryption algorithm is encrypted by the private key of the asymmetric encryption algorithm, the private key of the symmetric encryption algorithm can be obtained by decrypting the first block link point by the private key of the asymmetric encryption algorithm, and the transaction content can be obtained by decrypting the first block link point by the private key of the symmetric encryption algorithm. The private key of the symmetric encryption algorithm is obtained by negotiation between the encryption party and the first block link node or is sent by the key management server. The private key of the symmetric encryption algorithm can also be generated by an encryption party, and the private key of the asymmetric encryption algorithm is sent to the enclosure of the first block chain node by the key management server through remote certification and is sent to the encryption party.

S504: code for the first block link point to decrypt the transaction to determine the corresponding smart contract.

The decryption process is as described above and will not be described in detail.

S506: code for a first blockchain node to execute the intelligent contract in a trusted execution environment; encrypting with a key while storing the contract status indicated by the privacy identifier; determining that the access condition is satisfied in response to an access request for a contractual state designated by the privacy identifier.

The first block link point may use a processor instruction newly added in the CPU, may allocate a part of the area EPC in the memory, and encrypt and store the decrypted plaintext code in the EPC through an encryption engine MEE in the CPU. The encrypted content in the EPC enters the CPU and is decrypted into plaintext. And in the CPU, operating the code of the plaintext to finish the execution process.

In SGX technology, the code that executes the intelligent contract may load the EVM into the enclosure. In the remote certification process, the key management server can calculate a hash value of a local EVM code, compares the hash value with the hash value of the EVM code loaded in the first block chain link point, and correctly uses 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.

From the perspective of a block link point, the contract state is written to a database, such as a local database. The database is typically stored on a storage medium, more commonly a persistent storage medium. The persistent storage medium may be a magnetic disk, a floppy disk, or a memory or the like which can restore data after being powered on so as to be persistently stored.

The key includes a symmetrically encrypted key or an asymmetrically encrypted key. The symmetrically encrypted keys include seal keys. The seal key may be sent by the key management server after the SGX of the first blockchain node passes the remote attestation.

The compiler mentioned in the above embodiments is applicable to a compiled language. That is, before the code is run, the whole needs to be converted by a compiler into a language understandable by a human (programming language) into a language understandable by a machine. In turn, the compiled code is executed by a virtual machine, such as the EVM described above. Applications written in a compiled language can run directly after compilation. The compiled language features fast running speed and high efficiency.

In addition, there is an interpreted language. Such interpreted languages are also human understandable languages (programming languages) and also require conversion to machine understandable languages for execution, but the conversion occurs at runtime. In other words, the interpreted language is directly presented in the form of source code, and is parsed into machine code and executed in real time when running. The program in the interpreted language does not need to be compiled before running, and is translated when running, and a special interpreter is responsible for interpreting the program code when each statement is executed. The interpreted language needs to be translated once per execution, and the efficiency is low. For example, JavaScript belongs to an interpreted language, which means that only when the code is running, the system knows whether the code is wrong. In other words, since the compiled language is compiled before it is run, the compiler checks all code, and thus does not generate low-level errors, such as using a non-existent name or using an incorrect name. JavaScript may present these problems.

In the above embodiments, an interpreted language may be used instead of a compiled language. That is, the intelligent contract code which can be written in an interpreted language and is received by the first block link point does not need to be compiled by a compiler. The intelligent contract code may be executed by an interpreter when executed. The interpreter is, for example, JIT compilation (Just In Time compilation) such as JVM (Java Virtual Machine).

Similarly, in SGX technology, the code that executes the smart contract may load the JVM into the enclosure. In the remote certification process, the key management server can calculate a hash value of a local JVM code, compare the hash value with the hash value of the JVM code loaded in the link point of the first block, 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 link node. Measured, the correct JVM can execute the intelligent contract code in the SGX.

An embodiment of a system for implementing privacy protection in a blockchain according to the present disclosure is described below with reference to fig. 6. In this embodiment, the system for implementing privacy protection includes a client 601 and a first blockchain node 602, where:

the client 601 encrypts the transaction and sends the encrypted transaction to the first block chain node, wherein a code of an intelligent contract corresponding to the transaction comprises a contract state marked by a privacy identifier and an access condition aiming at the contract state marked by the privacy identifier;

the first blockchain node 602 decrypts the transaction to determine code of the corresponding smart contract, which is executed in the trusted execution environment; encrypting with a key while storing the contract status indicated by the privacy identifier; determining that the access condition is satisfied in response to an access request for a contractual state designated by the privacy identifier.

Wherein the access condition comprises the following personnel restriction conditions: the initiator of the access request is in an access white list corresponding to a contract state marked by the privacy identifier; or the initiator of the access request is not in an access blacklist corresponding to the contract state marked by the privacy identifier. The access white list or the access black list is positioned in the intelligent contract corresponding to the transaction; or, the access white list or the access black list is located in another intelligent contract called by the intelligent contract corresponding to the transaction.

Wherein the access condition comprises the following state restriction conditions: the value of the contract state indicated by the privacy identifier reaches a first preset threshold value; or the values of other contract states different from the contract state indicated by the privacy identifier reach a second preset threshold value.

An embodiment of a node for implementing privacy protection in a blockchain in the present specification is described below with reference to fig. 7, where the node includes:

a receiving unit 701, configured to receive an encrypted transaction, where a code of an intelligent contract corresponding to the transaction includes a contract state indicated by a privacy identifier and an access condition for the contract state indicated by the privacy identifier;

a decryption unit 702 for decrypting the transaction to determine the code of the corresponding smart contract;

an execution unit 703 for executing code of the intelligent contract in a trusted execution environment;

an encrypting unit 704 configured to encrypt with a key when storing the contract status indicated by the privacy identifier;

a determining unit 705 configured to determine that the access condition is satisfied when responding to an access request for the contract status indicated by the privacy identifier.

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 manufacturing 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 Hardware Description Language), traffic, CUPL (core universal Programming Language), HDCal, jhddl (Java Hardware Description Language), Lava, Lola, HDL, PALASM, rhyd (Hardware Description Language), and the like, which are currently used in the field-Hardware Language. 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:

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

the initiator of the access request is in an access white list corresponding to a contract state marked by the privacy identifier; or the like, or, alternatively,

and the initiator of the access request is not in an access blacklist corresponding to the contract state marked by the privacy identifier.

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

the access white list or the access black list is positioned in the intelligent contract corresponding to the transaction; or the like, or, alternatively,

the access white list or the access black list is positioned in another intelligent contract called by the intelligent contract corresponding to the transaction.

4. The method of claim 1, the access condition comprising a state restriction condition:

the value of the contract state indicated by the privacy identifier reaches a first preset threshold value; or the like, or, alternatively,

and the values of other contract states different from the contract state indicated by the privacy identifier reach a second preset threshold value.

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

6. The method of claim 5, the key of the symmetric encryption algorithm comprising a seal key.

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

the seal key is sent by a key management server after the SGX of the first block chain node passes the remote certification; or the like, or, alternatively,

the seal key is obtained by negotiation between the first block chain link point and other block chain link points.

8. The method of claim 1, the key being stored in a bounding box of a first blockchain node.

9. The method of claim 8, wherein there are several enclosures for the first block link points, and the key is stored in a secure enclosure.

10. The method of claim 9, the security enclosure comprising a QE enclosure.

11. The method of claim 1, the trading the corresponding smart contract comprising:

and the client sends the intelligent contract in the transaction through the second blockchain node.

12. The method of claim 11, further comprising:

and for the intelligent contract written by a user in a high-level language on the first block chain node, the first block chain node adopts a compiler to compile the intelligent contract written by the high-level language to generate byte codes.

13. The method of claim 11, wherein for an intelligent contract written in a high-level language on a client by a user, the client further compiles the intelligent contract written in the high-level language by using a compiler to generate a bytecode, and then sends the intelligent contract in the form of the bytecode to the first blockchain node;

correspondingly, when the first block link point receives the transaction, the intelligent contract corresponding to the transaction is the intelligent contract in the form of byte codes.

14. The method of claim 11, wherein for a user's smart contract written in a high-level language on a client, the client sends the smart contract written in the high-level language to a first blockchain node; correspondingly, when the first block chain node receives the transaction, the intelligent contract corresponding to the transaction is an intelligent contract in a high-level language form; the method further comprises the following steps:

and compiling the intelligent contract compiled by the high-level language by the first block link point by adopting a compiler to generate byte codes.

15. The method of claim 11, the intelligent contract in the transaction sent by the client through the second blockchain node comprises an intelligent contract in bytecode or an intelligent contract written in a high-level language.

16. The method of claim 15, further comprising:

and for the intelligent contract written by the high-level language sent by the second block chain node, the first block chain node adopts a compiler to compile the intelligent contract written by the high-level language to generate byte codes.

17. The method of any of claims 12-16, the high-level language-form intelligent contract including therein contract states that need privacy protection as indicated by a first privacy identifier, the bytecode-form intelligent contract including therein contract states that need privacy protection as indicated by a second privacy identifier;

the first privacy identifier is the same as or corresponds to the second privacy identifier.

18. The method according to claim 1, wherein when the client encrypts the transaction, the encryption mode is a symmetric encryption mode or an asymmetric encryption mode, or a combination of symmetric encryption and asymmetric encryption.

19. The method of claim 18, the client encrypting the transaction with a private key of a symmetric encryption algorithm, the first blockchain node decrypting the transaction with the private key of the symmetric encryption algorithm to determine the code of the smart contract; or the like, or, alternatively,

the client encrypts the transaction by using a private key of an asymmetric encryption algorithm, and the first blockchain node decrypts the transaction by using the private key of the asymmetric encryption algorithm to determine a code of the intelligent contract.

20. The method of claim 18, wherein the symmetric encryption incorporates a non-symmetric encryption scheme, including a digital envelope encryption scheme.

21. The method of claim 20, the client encrypting the transaction with a private key of a symmetric encryption algorithm and encrypting a private key employed in the symmetric encryption algorithm with a private key of an asymmetric encryption algorithm;

correspondingly, after the first block chain node receives the encrypted transaction, the first block chain node decrypts by adopting the private key of the asymmetric encryption algorithm to obtain the private key of the symmetric encryption algorithm, and decrypts by using the private key of the symmetric encryption algorithm to obtain the transaction content.

22. The method according to claim 19 or 21, wherein the private key of the symmetric encryption algorithm is obtained by the client and the first chunk link node through negotiation, or is sent by a key management server.

23. The method of claim 21, the private key of the symmetric encryption algorithm being generated by the client, the private key of the asymmetric encryption algorithm being sent to the client by the key management server sending the private key of the asymmetric encryption algorithm to the enclosure of the first blockchain node through remote attestation.

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

25. The method of claim 1, the contract state designated by the privacy identifier stored on a persistent storage medium.

26. The method of claim 25, wherein the persistent storage medium comprises a magnetic disk, a floppy disk, or a memory that is powered on to recover data so that it may be persistently stored.

27. The method of claim 1, the trusted execution environment comprising an Intel SGX or AMD SEV or ARMTrustzone.

28. A method for implementing privacy protection in a blockchain, comprising:

29. The method of claim 28, the access condition comprising a personnel limitation condition:

30. The method of claim 29, wherein the first and second portions are selected from the group consisting of,

31. The method of claim 28, the access condition comprising a state restriction condition:

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

33. The method of claim 32, the key of the symmetric encryption algorithm comprising a seal key.

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

35. The method of claim 28, the key being stored in a circle of a first blockchain node.

36. The method of claim 35, wherein there are several enclosures for the first block link points, and the key is stored in a secure enclosure.

37. The method of claim 36, the security enclosure comprising a QE enclosure.

38. The method of claim 28, the trading the corresponding smart contract comprising:

39. The method of claim 38, further comprising:

40. The method of claim 38, wherein for an intelligent contract written in a high-level language on a client by a user, the client further compiles the intelligent contract written in the high-level language by using a compiler to generate a bytecode, and then sends the intelligent contract in the form of the bytecode to the first blockchain node;

41. The method of claim 38, wherein the client sends a high-level language intelligent contract to a first blockchain node for a user's high-level language intelligent contract on the client; correspondingly, when the first block chain node receives the transaction, the intelligent contract corresponding to the transaction is an intelligent contract in a high-level language form; the method further comprises the following steps:

42. The method of claim 38, wherein the intelligent contract in the transaction sent by the client via the second blockchain node comprises an intelligent contract in bytecode or an intelligent contract written in a high-level language.

43. The method of claim 42, further comprising:

44. A method according to any of claims 39-43, wherein the high-level language-form intelligent contract includes contract states that require privacy protection as indicated by a first privacy identifier, and wherein the bytecode-form intelligent contract includes contract states that require privacy protection as indicated by a second privacy identifier;

45. The method of claim 28, wherein the client encrypts the transaction by using a symmetric encryption scheme or an asymmetric encryption scheme, or a combination of symmetric encryption and asymmetric encryption.

46. The method of claim 45, the client encrypting the transaction with a private key of a symmetric encryption algorithm, the first blockchain node decrypting the transaction with the private key of the symmetric encryption algorithm to determine the code of the smart contract; or the like, or, alternatively,

47. The method of claim 45, wherein said symmetric encryption incorporates asymmetric encryption, including digital envelope encryption.

48. The method of claim 47, the client encrypting the transaction with a private key of a symmetric encryption algorithm and encrypting a private key employed in the symmetric encryption algorithm with a private key of an asymmetric encryption algorithm;

49. The method of claim 46 or 48, wherein the private key of the symmetric encryption algorithm is obtained by the client and the first chunk link node through negotiation, or is sent by a key management server.

50. The method of claim 48, the private key of the symmetric encryption algorithm being generated by the client, the key management server sending the private key of the asymmetric encryption algorithm to the client by sending the private key of the asymmetric encryption algorithm to the enclosure of the first blockchain node through remote attestation.

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

52. The method of claim 28, wherein the contract state indicated by the privacy identifier is stored on a persistent storage medium.

53. The method of claim 52, the persistent storage medium comprising a magnetic disk, floppy disk, or memory that is power-on recoverable of data so that it can be persistently stored.

54. The method of claim 28, the trusted execution environment comprising an Intel SGX or AMD SEV or ARMTrustzone.

55. A system for implementing privacy protection in a blockchain, comprising a client and a first blockchain node, wherein:

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

57. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 28-54 by executing the executable instructions.

58. 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 28 to 54.