CN109831298B

CN109831298B - Method, node and storage medium for securely updating keys in blockchain

Info

Publication number: CN109831298B
Application number: CN201910100786.7A
Authority: CN
Inventors: 魏长征; 闫莺
Original assignee: Alibaba Group Holding Ltd
Current assignee: Ant Chain Technology Co ltd
Priority date: 2019-01-31
Filing date: 2019-01-31
Publication date: 2020-05-15
Anticipated expiration: 2039-01-31
Also published as: CN111614464A; CN109831298A; CN111614464B

Abstract

One or more embodiments of the present specification provide a method, a node, and a storage medium for securely updating a key in a blockchain, where the method may include: the block chain node determines an intelligent contract corresponding to the received transaction; the blockchain node executes the smart contract in a trusted execution environment; the block chain node is encrypted by a key when storing an execution result, and the key is generated by the block chain node according to a security key stored in the trusted execution environment; and when the version of the security key is updated by the block link node, updating the security key of the low version into the security key of the high version, wherein the security key of the low version is calculated irreversibly by the security key of the high version.

Description

Method for safely updating key in block chain, node and storage medium

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method, a node, and a storage medium for securely updating a key 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).

Disclosure of Invention

In view of the above, one or more embodiments of the present specification provide a method, a node, and a storage medium for securely updating a key in a blockchain.

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

according to a first aspect of one or more embodiments of the present specification, there is provided a method for securely updating a key in a blockchain, including:

the block chain node determines an intelligent contract corresponding to the received transaction;

the blockchain node executes the smart contract in a trusted execution environment;

the block chain node is encrypted by a key when storing an execution result, and the key is generated by the block chain node according to a security key stored in the trusted execution environment;

and when the version of the security key is updated by the block link node, updating the security key of the low version into the security key of the high version, wherein the security key of the low version is calculated irreversibly by the security key of the high version.

According to a second aspect of one or more embodiments of the present specification, there is provided a node for securely updating a key in a blockchain, including:

the determining unit is used for determining the intelligent contract corresponding to the received transaction;

an execution unit to execute the smart contract in a trusted execution environment;

a storage unit for storing an execution result;

an encryption unit, configured to encrypt, when storing the execution result, a key generated by the blockchain node according to a secure key saved in the trusted execution environment;

and the updating unit is used for updating the low-version security key into the high-version security key when the version of the security key is updated, wherein the low-version security key is obtained by irreversibly calculating the high-version security key.

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

Drawings

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

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

FIG. 3 is a schematic diagram of creating and invoking an intelligent contract according to an exemplary embodiment.

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

Fig. 5 is a schematic diagram of processing a blockchain transaction according to an exemplary embodiment.

Fig. 6 is a diagram illustrating a key version evolution according to an exemplary embodiment.

FIG. 7 is a diagram of a data structure for a contract state provided by an exemplary embodiment.

Fig. 8 is a block diagram of a node in a blockchain to implement privacy protection according to an exemplary embodiment.

Detailed Description

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

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

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

Whether public, private, or 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).

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 blockchain node.

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 implementation process of the embodiment of the method for implementing contract invocation in a block chain in the present specification is described as follows in conjunction with fig. 4:

in step 402, the first block link point determines an intelligent contract corresponding to the received transaction.

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

The transaction may also be forwarded by the second blockchain link point to the first blockchain node. For example, after the user generates the transaction at the client, the transaction is submitted to the second blockchain node through the client; the second blockchain node then further forwards the transaction to the first blockchain node. Taking fig. 5 as an example, the interface may interface with other blockchain nodes, for example, the other blockchain nodes may include the second blockchain node, so that the second blockchain node may forward the transaction to the first blockchain node. Similarly, the second tile chain node may also interface with the client through its own transaction/query interface to receive transactions submitted by the client.

For example, in a blockchain network employing consensus algorithms such as Proof of Work (POW), Proof of equity (POS), Proof of commission (DPOS), etc., a second blockchain node immediately spreads (e.g., broadcasts) the transaction submitted by the client to other blockchain nodes in the ethernet network.

For example, in a block chain network using a Practical Byzantine Fault Tolerance (PBFT) mechanism or the like, the bookkeeping node has been agreed before the current round of bookkeeping, so that after the second block chain node receives the transaction submitted by the client, if the second block chain node is not the bookkeeping node, the transaction is sent to the determined bookkeeping node, and the bookkeeping node packages the transaction (including the transaction) and sends the transaction to each verification node in a further consensus phase. When the second block link point is the determined accounting node, after the other block link points receive the transaction submitted by the client, the transaction can be forwarded to the second block link node; the second blockchain link may then package the transaction (or other transactions as well) to various verification nodes, including the first blockchain node, during the consensus phase.

In one embodiment, the transaction may be labeled as a private transaction through a transaction level label, so that the first block link point determines that an execution result (e.g., a contract state related to the intelligent contract) corresponding to the intelligent contract needs to be stored after encryption. For example, a type field may be added to the transaction such that the first blockchain may identify the transaction type as either a clear text transaction or a private transaction based thereon. In the related art, such as in an ethernet network, transactions typically include fields to, value, data, and the like. On the basis of the related technology, the embodiment adds a type field, for example, characterized as a type field, in the transaction, and indicates the type of the related transaction based on the value of the type field; for example, when the type field is the first value, it indicates that the related transaction is a plaintext transaction, and when the type field is the second value, it indicates that the related transaction is a privacy transaction.

In one embodiment, the intelligent contract may be labeled as a privacy processing type through contract level labeling, so that the first block link point determines that an execution result (such as a contract state related to the intelligent contract) corresponding to the intelligent contract needs to be stored after encryption. For example, a processing type marked on the intelligent contract required to be invoked may exist in the transaction, so that the first block link point may apply a corresponding processing operation to the intelligent contract invoked for the transaction, with respect to the processing type marked in the transaction. For example, the code of the intelligent contract may include a type field, and the first block link point may determine, based on a value of the type field included in the code of each intelligent contract, that the intelligent contract is a privacy processing type or a plaintext processing type; for another example, the privacy processing type intelligent contract may include a privacy identifier, and the plaintext processing type intelligent contract may not include the privacy identifier; for another example, a plaintext treatment type intelligent contract may contain a plaintext identifier, and a privacy treatment type intelligent contract may not contain the plaintext identifier; accordingly, the first block link point may distinguish between smart contracts of different processing types based on the above-described differences.

In one embodiment, the first block link point may decrypt the transaction in a Trusted Execution Environment (TEE) when the transaction is in an encrypted state. The TEE is a trusted execution environment that is based on a secure extension of the CPU hardware and is completely isolated from the outside. TEE was originally proposed by Global Platform to address the secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications parallel to the operating system. The Trust Zone technology of ARM realizes the real commercial TEE technology at the earliest.

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

Taking the Intel SGX technology as an example, SGX provides an enclosure (also called enclave), that is, an encrypted trusted execution area in memory, and a CPU protects data from being stolen. Taking the example that the first block link point adopts a CPU supporting SGX, a part of an area EPC (enclosure Page Cache, Enclave Page Cache, or Enclave Page Cache) may be allocated in the memory by using a newly added processor instruction, and data therein is encrypted by an Encryption engine mee (memory Encryption engine) in the CPU. The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. Therefore, in the SGX, a user may not trust an operating System, a VMM (Virtual Machine Monitor), or even a BIOS (Basic Input Output System), and only need to trust the CPU to ensure that private data is not leaked. In practical application, the private data can be encrypted and then transmitted to the enclosure in a ciphertext form, and the corresponding secret key is transmitted to the enclosure through remote certification. Then, the operation is performed by using the data under the encryption protection of the CPU, and the result is returned in a ciphertext form. In this mode, not only can the powerful calculation be utilized, but also data leakage is not worried about.

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

If the plaintext transaction content is encrypted in an asymmetric encryption manner, i.e. using the public key of the asymmetric encryption algorithm, the first chunk node may decrypt the transaction using the private key of the asymmetric encryption algorithm, 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 chunk node, and the public key is sent to the client before step 402, so that the client may encrypt the plaintext transaction content with the key in step 402.

The key of the asymmetric encryption algorithm may also be generated by a key management server. Through a remote certification mode, the key management server sends the private key to the first blockchain node, and specifically, the private key can be transmitted into a surrounding ring of the first blockchain node. The first block link point may comprise a plurality of enclosures and the private key may be passed into a security enclosure of the enclosures; for example, the security enclosure may be a qe (queuing enclosure) enclosure, rather than an ae (application enclosure) enclosure. For asymmetrically encrypted public keys, the client may be sent by a key management server. Thus, in step 402, the client may encrypt the plaintext transaction content with the public key, and accordingly, the first blockchain node may decrypt the transaction with the private key to obtain the plaintext transaction content included in the transaction.

The client can also adopt a mode of combining symmetric encryption with asymmetric encryption. For example, the client encrypts the plaintext transaction content by using a symmetric encryption algorithm, that is, encrypts the plaintext transaction content by using a private key of the symmetric encryption algorithm, and encrypts a 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 plaintext transaction content.

For example, the key management server may send the private key of the asymmetric cryptographic algorithm to the enclosure of the first blockchain node and send the public key of the asymmetric cryptographic algorithm to the client through remote attestation. Therefore, the client can encrypt the plaintext transaction content by adopting a symmetric encryption mode, namely encrypting the plaintext transaction content by adopting a private key of a symmetric encryption algorithm and encrypting the private key adopted in the symmetric encryption algorithm by using a public key of an asymmetric encryption algorithm. Further, the client may send the transaction and encryption 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 link node receives the transaction and the encrypted private key, the encrypted private key can be decrypted by using the private key of the asymmetric encryption algorithm to obtain the private key of the symmetric encryption algorithm, and then the transaction is decrypted by using the private key of the symmetric encryption algorithm to obtain the plaintext transaction content. The encryption method is generally called digital envelope encryption.

At step 404, the first blockchain node executes the intelligent contract in the trusted execution environment.

In one embodiment, the transaction is used to create a smart contract, which may contain the code of the smart contract. The first block link point completes creation of the intelligent contract by executing code of the intelligent contract included in the transaction in the trusted execution environment.

In one embodiment, the transaction is used to invoke a smart contract, and the transaction may contain a contract address for the invoked smart contract. The first block chain link point calls the corresponding intelligent contract code according to the contract address of the intelligent contract contained in the transaction. If the called intelligent contract is a plaintext contract, namely the code of the intelligent contract is stored in an external storage space in a plaintext form, the first block link point can directly read the plaintext code into a trusted execution environment for execution; if the called intelligent contract is a privacy contract, namely the code of the intelligent contract is stored in the external storage space in a ciphertext mode, the first block link point can decrypt the ciphertext code according to the key stored in the trusted execution environment and execute the decrypted plaintext code in the trusted execution environment.

At step 406, the first blockchain node encrypts, when storing the execution result, with a key generated by the blockchain node according to the security key saved in the trusted execution environment.

In an embodiment, the key may be a security key, that is, the security key is directly used as the key to encrypt the execution result.

In one embodiment, the key is generated by a preset algorithm from a security key, and the execution result is not directly encrypted by using the security key. In particular, the predetermined algorithm may involve an irreversible algorithm such as a hash algorithm, so that the security of the security key is not affected even if the key is compromised or leaked.

In an embodiment, the execution result relates to a plurality of contract states, each of which may be encrypted by the same key. For example, the key may be generated by the block link node according to the security key and at least one influence factor, and the influence factors adopted by different transactions are different, so that the data stored in the first block link node is encrypted by using a differentiated key, and the data stored in the first block link node may be protected from a smaller granularity, so as to obtain a better security protection. Compared with the method that the execution results of all transactions are encrypted by the same security key, the method and the device have the advantages that the number of the used keys is increased, so that even if a certain key is broken by a lawbreaker, only data encrypted by the key can be exposed, and as long as the security key in the trusted execution environment is not stolen, the security of most other data can still be ensured.

Meanwhile, when a lawbreaker grasps that a value is a and a ciphertext encrypted by using a security key is a, if execution results corresponding to all intelligent contracts are encrypted by using the security key, the lawbreaker can presume that the value of other contract states is a for other contract states with the ciphertext being a, and if the differentiated key in the specification is used, the lawbreaker can be prevented from presuming the plaintext value of the contract state based on the ciphertext value.

In an embodiment, after the first block link point concatenates the security key and the at least one influence factor, hash calculation is performed on the concatenation information, and the calculated hash value or a part (for example, the first 128 bits or other part) of the hash value is used as the key to encrypt the plaintext execution result of the transaction to obtain a corresponding ciphertext execution result.

The number and type of influencing factors used in generating the key are not limited. By selecting different influence factors or combinations of the influence factors, privacy protection at different levels can be realized so as to meet corresponding privacy protection requirements.

In one embodiment, the impact factors may include: a contract address of the intelligent contract. When the transaction is used for creating the intelligent contract, the first block link point can execute the creating operation of the intelligent contract by executing the code of the intelligent contract contained in the transaction, and determines the information of the contract address corresponding to the intelligent contract, so that the key is generated according to the security key and the information of the contract address, and the created intelligent contract is encrypted by the key. When the transaction is used for invoking the smart contract, the first block link point generates the contract address and the security key as the key by acquiring the contract address of the invoked smart contract, so as to encrypt the contract state related to the invoked smart contract through the key.

Accordingly, when user a initiates transactions R1, R2 associated with smart contracts S1, S2, respectively, the first blockchain node encrypts, after executing smart contract S1 in response to transaction R1, a key K1 corresponding to the contract address generation of smart contract S1 with the security key, and the first blockchain node encrypts, after executing smart contract S2 in response to transaction R2, a key K2 corresponding to the contract address generation of smart contract S2 with the security key. Then data encrypted with key K2 is in a secure state even if key K1 is compromised. Meanwhile, even if the plaintext of the state value Z1 related to the transaction R1 is the same as the plaintext of the state value Z2 related to the transaction R2, the encrypted data Z1m corresponding to the state value Z1 and the encrypted data Z2m corresponding to the state value Z2 are different due to the adoption of the differentiated keys K1 and K2, and therefore, the value relationship between the state values Z1 and Z2 cannot be estimated through the values of the encrypted data Z1m and Z2 m. Similarly, when the transactions respectively initiated by different users correspond to different smart contracts, the differentiated keys may also be obtained, and the specific case may refer to the above example.

In one embodiment, the impact factors may include: an account address of a contract creator of the intelligent contract. When a contract creator creates an intelligent contract, a transaction is submitted to the blockchain, the from field of the transaction is the account address of the contract creator, the to field is empty, the data field contains the code of the intelligent contract, and the account address of the contract creator can be known from the from field. In turn, the key may be generated from the security key and the account address described in the from field for encrypting the results of the execution of the transaction that invoked the smart contract. Although the same contract creator can create a plurality of intelligent contracts, all users (or at least more than one user) can create the intelligent contracts on the block chain, so that the key differentiation between the intelligent contracts created by different users can be realized at least, and the risk of data leakage is reduced.

Accordingly, when user B initiates transactions R3, R4 relating to smart contracts S3, S4, respectively, the first blockchain node encrypts, after executing smart contract S3 in response to transaction R3, a key K3 corresponding to the secure key and account address generation of the contract creator of smart contract S3, and the first blockchain node encrypts, after executing smart contract S4 in response to transaction R4, a key K4 corresponding to the secure key and account address generation of the contract creator of smart contract S4. Then data encrypted with key K4 is in a secure state even if key K3 is compromised. Meanwhile, even if the plaintext of the state value Z3 related to the transaction R3 is the same as the plaintext of the state value Z4 related to the transaction R4, the encrypted data Z3m corresponding to the state value Z3 and the encrypted data Z4m corresponding to the state value Z4 are not the same due to the adoption of the differentiated keys K3 and K4, and therefore, the value relationship between the state values Z3 and Z4 cannot be estimated through the values of the encrypted data Z3m and Z4 m. Similarly, when the transactions respectively initiated by different users correspond to smart contracts created by different users, the differentiated keys can also be obtained, and the specific case can refer to the above example.

In one embodiment, the impact factors may include: a code hash value of the intelligent contract. When different intelligent contracts are used for realizing different functions, the contained codes are different more or less inevitably, so that the hash values of the codes are completely different; even if the intelligent contracts are used for realizing the same functions, if different users write the intelligent contracts, even if the same user writes the intelligent contracts at different moments, at least part of contained codes have differences, so that the hash values of the codes are completely different. Thus, based on the difference in code hash values, different smart contracts are enabled to correspond to disparate keys. Then, similar to the embodiment that employs the contract address described above, when a transaction is used to create or invoke a smart contract, the transaction execution result can be made encrypted based on a different key when the code hash values of the smart contracts to which the transaction corresponds are different.

Accordingly, when user C initiates transactions R5, R6 associated with smart contracts S5, S6, respectively, the first blockchain node encrypts, after executing smart contract S5 in response to transaction R5, the key K5 corresponding to the code hash generation of the security key and smart contract S5, and the first blockchain node encrypts, after executing smart contract S6 in response to transaction R6, the key K6 corresponding to the code hash generation of the security key and smart contract S6. Then data encrypted with key K6 is in a secure state even if key K5 is compromised. Meanwhile, even if the plaintext of the state value Z5 related to the transaction R5 is the same as the plaintext of the state value Z6 related to the transaction R6, the encrypted data Z5m corresponding to the state value Z5 and the encrypted data Z6m corresponding to the state value Z6 are not the same due to the adoption of the differentiated keys K5 and K6, and therefore, the value relationship between the state values Z5 and Z6 cannot be presumed through the values of the encrypted data Z5m and Z6 m. Similarly, when the transactions respectively initiated by different users correspond to smart contracts with different codes, the differentiated keys can also be obtained, and the specific case can refer to the above example.

In one embodiment, the impact factors may include: an account address of an initiator of the transaction. When the initiator initiates a transaction to the first blockchain node, the from field of the transaction is the account address of the initiator, that is, the first blockchain node can know the account address of the initiator from the from field of the transaction, so as to generate a corresponding key with the security key. By adopting the account address of the initiator of the transaction as the influence factor, different users can adopt differential keys due to different account addresses of the initiator even when the same intelligent contract is called. Thus, even the same smart contract is enabled to correspond to disparate keys based on the difference in account addresses of the parties to the transaction.

Accordingly, when the user D, the user E initiate transactions R7, R8 relating to the smart contract S7, respectively, the first blockchain node encrypts the key K7 corresponding to the account address generation of the user D using the security key after executing the smart contract S7 in response to the transaction R7, and the first blockchain node encrypts the key K8 corresponding to the account address generation of the user E using the security key after executing the smart contract S7 in response to the transaction R8. Then data encrypted with key K8 is in a secure state even if key K7 is compromised. Meanwhile, even if the plaintext of the state value Z7 related to the transaction R7 is the same as the plaintext of the state value Z8 related to the transaction R8, the encrypted data Z7m corresponding to the state value Z7 and the encrypted data Z8m corresponding to the state value Z8 are different due to the adoption of the differentiated keys K7 and K8, and therefore, the value relationship between the state values Z7 and Z8 cannot be estimated through the values of the encrypted data Z7m and Z8 m. Similarly, when the transactions respectively initiated by different users correspond to different smart contracts, the differentiated keys may also be obtained, and the specific case may refer to the above example.

In an embodiment, affecting the shadow may include: a combination between a contract address of the intelligent contract, an account address of a contract creator of the intelligent contract, a code hash value of the intelligent contract, an account address of an initiator of the transaction, such as any two at a time, any three at a time, four at a time, and so on. Then, the key may be generated by sequentially concatenating the security key with each of the influencing shadows.

For example, when the shadow includes a contract address and a code hash value, unless a call is made to the same smart contract, different keys may be generated by the difference in contract addresses even if the code of the two smart contracts is identical.

For another example, when the influencing shadow includes the account address and the code hash value of the contract creator, unless the same smart contract is invoked, different keys may be generated by the difference in the code hash values even if a plurality of smart contracts created by the same user are identical, or different keys may be generated by the difference in the account addresses of the contract creators even if the code hash values of a plurality of smart contracts created by a plurality of contract creators, respectively, are identical.

For another example, when the impact factor includes a contract address, an account address of an initiator of a transaction, unless calls are made by the same initiator for the same smart contract, different keys may be generated even if calls are made by the same initiator for different smart contracts, or by different initiators for the same smart contract.

In an embodiment, the execution result relates to a plurality of contract states, different contract states being encryptable by different keys. Different keys are respectively adopted for the contract states related to the intelligent contract to encrypt, so that the privacy level is the state level, different keys can be adopted from the granularity of the contract states, and even if the contract states generated by the same transaction can be encrypted based on different keys. Compared with the method that the execution results of all transactions are encrypted by the same security key, the method and the device have the advantages that the number of the used keys is increased, so that even if a certain key is broken by a lawbreaker, only data encrypted by the key can be exposed, and as long as the security key in the trusted execution environment is not stolen, the security of most other data can still be ensured. Compared with privacy protection such as transaction level or contract level, namely different secret keys are adopted for different transactions or different contracts, and the same secret key is adopted for the same transaction or the same contract, the embodiment of the specification can achieve better privacy protection effect, and different cipher text values can be obtained based on encryption of different secret keys even if different contract states have the same plaintext value, so that lawless persons can be effectively prevented from presuming the plaintext value of the contract state based on the cipher text value.

In one embodiment, assume that a smart contract involves contract states X1-Xn, for n contract states, corresponding to keys K1-Kn, respectively. Then, the key Ki corresponding to the contract state Xi can be generated by the first block chain node according to the security key saved in the trusted execution environment and at least one private influence factor corresponding to the contract state Xi, wherein i is more than or equal to 1 and less than or equal to n.

In one embodiment, the impact factors for the generated key include two categories: private impact factors and public impact factors. The private impact factors are applicable only to the corresponding contract state, not to other contract states, such as the private impact factor of contract state X1, not to contract states X2-Xn. The common impact factor applies to all contract states simultaneously.

In one embodiment, the key Ki corresponding to the contract state Xi may be generated from a security key and at least one private impact factor corresponding to the contract state Xi. For example, the first chunk chain node may perform hash calculation on the splicing information after splicing the security key and at least one private influence factor corresponding to the contract state Xi, and use the calculated hash value or a part (such as the first 128 bits or other parts) of the hash value as the key Ki to encrypt for the contract state Xi. Since the private influence factors of the contract states are different, it can be ensured that the keys are different inevitably when the corresponding keys K1-Kn are generated, so that the contract states X1-Xn can be encrypted by using different keys respectively.

The private impact factors corresponding to contract states Xi may include: the occurrence order Pi of the contract states Xi in the intelligent contracts. When the code of the intelligent contract is executed at the first block link point, the contract states included in the intelligent contract code are sequentially read, and the appearance sequence P1 to Pn corresponding to each contract state can be used as one of the private influence factors corresponding to the contract states X1 to Xn. For example, when the first occurrence of the contract state X3, the private impact factor for the contract state X3 may include the occurrence order P3-1, and when the 88 th occurrence of the contract state X100, the private impact factor for the contract state X100 may include the occurrence order P100-88. Since different contract states always appear in different orders, it is ensured that the appearance orders P1 to Pn corresponding to the respective contract states are necessarily different.

The private impact factors corresponding to contract states Xi may include: a count value Qi corresponding to the appearance order. For the occurrence order of the contract states, the first block link point may not directly use the occurrence order, but use the count value Qi corresponding to the occurrence order as a private influence factor. If the counting is started from 1 each time and the counting interval is 1, the value of the counting value Qi and the value of the appearance sequence Pi can be the same; if the counting is not started from 1 or the counting interval is not 1, the value of the counting value Qi is not the same as the value of the appearance order Pi, but a predetermined numerical relationship is maintained, for example, when the counting is started from a and the counting interval is b, the numerical relationship is Qi ═ a + b × (Pi-1). Since different contract states always appear in different orders, it is ensured that the count values Q1 to Qn corresponding to the respective contract states are inevitably different based on the above numerical relationship.

The private impact factors corresponding to contract states Xi may include: a random number Si assigned to the contract state Xi. The first tile link point may directly assign the random numbers S1 to Sn to the contract states X1 to Xn, as long as it is ensured that the random numbers corresponding to the contract states do not overlap. Meanwhile, by adopting the random number Si, different random numbers can be distributed aiming at the same contract state in the intelligent contract even if different transactions call the same intelligent contract, so that differential keys are adopted for the contract states generated by different transactions, and the data security can be further enhanced.

Of course, there may be a plurality of private impact factors corresponding to the contract state Xi, such as a combination of any two or more of the private impact factors between the occurrence order Pi, the count value Qi, and the random number Si described above. Based on the larger number of private influence factors, when some private influence factors are leaked due to some reason, the corresponding private key cannot be calculated or inferred through other private influence factors.

In an embodiment, the generation of the key may be further related to a public impact factor on the basis of the private impact factor. For example, the first chunk chain node may perform hash calculation on the splicing information after splicing the security key, at least one private impact factor corresponding to the contract state Xi, and at least one public impact factor, and use the calculated hash value or a part (such as the first 128 bits or other parts) of the hash value as the key Ki to encrypt for the contract state Xi.

Since the private influence factors of the contract states are different, it can be ensured that the keys are different inevitably when the corresponding keys K1-Kn are generated, so that the contract states X1-Xn can be encrypted by using different keys. While other granularities or levels of privacy protection may be achieved by adding a common impact factor.

The key Ki corresponding to the contract state Xi may also be highly correlated with the history block. For example, the historical block height may be: the first blockchain node receives the transaction, and the height of the block in the blockchain account book is the height of the block. Since the history chunk height is related to the transaction, the keys can be differentiated at transaction granularity. For example, when the transactions R1 and R2 related to the intelligent contract S1 are initiated respectively, the private impact factors corresponding to the same contract state may be the same (usually different if random numbers are used) due to the same intelligent contract S1 being invoked, for example, the transactions R1 and R2 relate to the contract states Y1-Yn. If keys are generated based only on security keys and private impact factors, different keys K1_1 through K1_ n may be used between contract states Y1 through Yn for R1, and different keys K2_1 through K2_ n may be used between contract states for R2, but the same contract state may correspond to the same key in different transactions, such as K1_ i — K2_ i. However, since different transactions R1, R2 were submitted at different times, possibly corresponding to different history chunk heights, by incorporating the history chunk heights into the calculation of the keys, i.e., generating keys based on the security keys, private impact factors, and public impact factors (e.g., history chunk heights), the same contract state can be made to correspond to different keys in different transactions, i.e., K1_ i ≠ K2_ i.

Similar to the historical chunk height, the common impact factor may also include: the block height of the block where the transaction is located, the position offset of the transaction in the block where the transaction is located, and the like. These common impact factors may have an impact on the "transaction" granularity, such that when different transactions invoke the same smart contract (same contract address, or different contract addresses, same code hash value), the contract state of the smart contract corresponds to different keys in different transactions.

Other common influencing factors can also produce influences of other granularities.

For example, the common impact factors may include: the contract addresses of the intelligent contracts are such that when different transactions (same initiator or different initiators) call intelligent contracts of the same contract address, the same contract state corresponds to the same secret key, and when different transactions call intelligent contracts of different contract addresses, the same contract state (at least part of contract states of different contract addresses are different in general) corresponds to different secret keys.

For another example, the common impact factors may include: the code hash value of the intelligent contract enables the same contract state to correspond to the same secret key when different transactions (the same initiator or different initiators) call the intelligent contracts with the same code hash value, and the same contract state (at least part of contract states are different when the code hash values are different) corresponds to different secret keys when different transactions call the intelligent contracts with different code hash values.

For another example, the common impact factors may include: the account address of the contract creator of the intelligent contract ensures that the same contract state corresponds to different keys when different transactions (the same initiator or different initiators) respectively call a plurality of intelligent contracts with the same code but different creators.

For another example, the common impact factors may include: the account address of the initiator of the transaction enables the same contract state to correspond to the same secret key when the same user initiates calling aiming at the same intelligent contract, and the same contract state to correspond to different secret keys when different users respectively initiate calling aiming at the same intelligent contract.

Of course, there may be a plurality of common impact factors, such as a combination of any two or more of the above-mentioned historical block heights, block heights of blocks where the transaction is located, position offsets of the transaction in the blocks where the transaction is located, contract addresses of the intelligent contracts, code hash values of the intelligent contracts, account addresses of contract creators of the intelligent contracts, and account addresses of the parties that initiated the transaction. Based on a larger number of public influence factors, when some public influence factors are revealed for some reason, the corresponding private key is ensured not to be calculated or speculated through other public influence factors, and privacy protection of corresponding granularity can be realized.

And step 408, when the version of the security key is updated by the first block link point, updating the low-version security key into the high-version security key, wherein the low-version security key is calculated irreversibly from the high-version security key.

In one embodiment, only one security key may be maintained in the trusted execution environment, and the first chunk node may use the security key when encrypting for the key. For example, the security key may be a symmetric encryption key, such as a seal (simple Encrypted 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 security 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 security 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 an embodiment, several versions of the security key may be maintained in the trusted execution environment, and the low version of the security key is computed irreversibly from the high version of the security key. For example, as shown in fig. 6, the seal key may be used as the root key of the highest version, and based on the seal key, other keys of lower versions, for example, 256 versions with version numbers of 0 to 255, may be sequentially generated. The method comprises the steps that hash calculation is carried out on a seal key and a version factor 0xFF (the decimal value is 255, namely the version number of a key needing to be generated; of course, other values can also be adopted), and the key-255 with the version number of 255 is obtained; carrying out hash calculation on the key-255 and the version factor 0xFE to obtain the key-254 with the version number of 254; … … the key-0 with version number 0 is obtained by hashing the key-1 with a version factor of 0x 00. Due to the characteristics of the hash algorithm, the calculation between the high-version key and the low-version key is irreversible, for example, the key-0 can be calculated by the key-1 and the version factor 0x00, but the key-1 cannot be reversely deduced by the key-0 and the version factor 0x 00.

Then each blockchain node in the blockchain network may negotiate the version of the security key employed. For example, all block chain nodes agree to use the same security key of a certain version, so that all block chain nodes generate the corresponding keys in the same manner, and the ciphertext execution results stored after the same transaction is executed are ensured to be the same, thereby successfully completing consensus.

In order to indicate the key used in encryption for each contract state, the first block link point may store the encrypted contract state in association with the generation mode description information of the corresponding key. The generation mode description information of the key Ki may include: version information of the security key and a value of an influence factor corresponding to the contract state Xi. For example, as shown in fig. 7, the first chunk chain node may write version information of the security key in the Info field, write a value of the impact factor in the Nounce field, and write the encrypted contract status in the Cipher field, and the Tag field is used to verify the integrity of the Cipher field.

The Info field may be 4Bytes in length, with 2Bytes for writing the key version number and the remaining 2Bytes being reserved Bytes. The Nounce field may be 12Bytes in length, where 4Bytes is used to write the history block height, 4Bytes is used to write the location offset of the transaction in the block, and 4Bytes is used to write the count value. The length of the Cipher field may be 32 Bytes. The Tag field may be 16Bytes in length. Of course, other field lengths, field combinations, and the like may also be used, and this specification does not limit this. The first block link point may also encrypt the generation mode description information of the key Ki. For example, the lowest version of key-0 described above may be used for encryption to avoid a lawbreaker from inferring the corresponding contract status, such as by counting the value.

Then, when the first block link point needs to use a contracted state such as the structure shown in fig. 7, the processing operations employed include: indexing by key to value, the structure of which is shown in FIG. 7; the information and Nounce fields are decrypted by adopting the key-0, information such as a key version number, a history block height, an offset and a count value is determined, a corresponding key is generated, the content of the Cipher field is decrypted through the key, and the integrity of data can be verified through a Tag field (if Tag is generated based on plaintext, the decrypted data is verified, and if Tag is generated based on ciphertext, the data before decryption is verified).

If a certain version of the security key is used for a long time, the security risk may be increased, and therefore, the version of the used security key may be periodically or triggerably updated among the blockchain nodes in the blockchain network according to a preset rule or a temporary convention.

As described above, since the high-version key can be calculated to obtain the low-version security key, and the low-version security key cannot reversely derive the high-version security key, each block node can be used from the low-version security key, and only the low-version security key is allowed to be updated to the high-version security key, so that on one hand, after the low-version security key is lost, since the high-version security key cannot be reversely derived from the low-version security key, only the version of the key needs to be upgraded, that is, the loss can be stopped in time, and on the other hand, the low-version security key can be calculated at any time from the high-version security key, so that compatibility can be achieved for the encrypted data previously using the low-version security key.

The first block link point can utilize a newly added processor instruction in the CPU, a part of the area EPC can be allocated in the memory, and the plaintext code is encrypted and stored 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.

After the EVM executes the code of the intelligent contract, a value of the contract state may be output, and the first block link point may store the contract state by using a key-value structure, for example, the value corresponds to the value of the contract state, and the key is used to index the value. In the related art, only value is encrypted, but key is not encrypted, and the output of key by EVM is too simple, for example, the key value is equal to the occurrence order of the corresponding contract states in the intelligent contract, that is, the key value of the first output contract state corresponds to 0, the key value of the second output contract state corresponds to 1, and so on. Therefore, when the key values in the plaintext are used for storage, a lawless person can easily presume the contract states represented by the values corresponding to the key values according to the value-taking rules of the key values, and further can presume or guess the values of the contract states (such as the values of the contract states, whether the values of the contract states are the same, the value-taking size relations among the contract states, and the like) by comparing the ciphertext and the like, so that privacy leakage is easily caused.

Therefore, in the present specification, when the contract state is stored by the key-value pair structure, the value corresponding to the contract state is encrypted as well as the corresponding key, so that a lawbreaker cannot infer the contract state represented by the corresponding value from the encrypted key value, which is helpful to ensure data security.

In an embodiment, the first block link point may obtain a security key maintained in the trusted execution environment, and encrypt the key corresponding to the agreement state in a symmetric encryption manner or an asymmetric encryption manner. For example, when the security key is a private key of a symmetric encryption algorithm, the key corresponding to the contract status may be encrypted by the private key of the symmetric encryption algorithm, and then decrypted by the private key of the symmetric encryption algorithm. For another example, when the security key is a public key of the asymmetric encryption algorithm, the key corresponding to the agreement state may be encrypted by the public key of the asymmetric encryption algorithm, and then decrypted by the private key of the asymmetric encryption algorithm.

In an embodiment, the first block link point may splice the key corresponding to the contract state with the security key, perform hash calculation on the spliced data, and use the hash value obtained by calculation as the encrypted key. The hash calculation described above may be implemented, for example, by other hash algorithms such as SHA 256.

In one embodiment, the first chunk link point may encrypt the key corresponding to the agreement state by the lowest version of the security key. For example, for the keys key-0 to key-255 shown in fig. 6, the key corresponding to the agreement state may be encrypted by using the key-0, so that even if the key-0 is lost at the first block link point, the key-0 can be derived and calculated only by grasping keys of other arbitrary versions. Of course, the first block link point may encrypt the key corresponding to the agreement state by using keys of other versions, which is not limited in this specification.

In one embodiment, the same key may be used to encrypt the contract status and the key corresponding to the contract status.

In an embodiment, when the trusted execution environment includes the plurality of versions of the key, the contract state and the key corresponding to the contract state may be encrypted by using different keys, respectively. In fact, because the data security requirement of the contract state is relatively higher, the contract state can be encrypted by using a key with a relatively higher security level, and a key corresponding to the contract state can be encrypted by using a key with a relatively lower security level; for example, the version of the key used for encrypting the contract status may be higher than the version of the key used for encrypting the key corresponding to the contract status, so that even if the key corresponding to the contract status is broken, the key of the higher version cannot be reversely deduced, and the contract status is ensured to be in a safe state.

When a transaction received by a first blockchain node invokes a smart contract, the smart contract may involve a number of contract states. And for each contract state corresponding key-value pair structure: for lower security protection requirements, a uniform key can be adopted to encrypt the key in each key value pair structure, for example, the key-0 is uniformly adopted; although the "values" in the contract state, i.e., the key-value pair structure, may be encrypted using the same key, information such as the numerical value change condition and the numerical value association of the contract state may be exposed due to the linkage change between encrypted data.

Therefore, different keys can be used for encryption for each contract state related to the intelligent contract.

In one embodiment, different versions of the key may be used to encrypt different contract states, respectively. When the contract state related to the intelligent contract is less and the key version is sufficient, the mode can be adopted; however, if the contract states involved in a smart contract are large and exceed the number of key versions, it may result in the need to share the same version of the key between partial contract states or to temporarily generate more versions of the key.

In one embodiment, different contract states may use the same version of key, but other influencing factors may be added, so that the actually used key of each contract state is generated by a certain version of key and the influencing factor together, and it is ensured that each contract state is encrypted by using different keys, and no extra requirement is imposed on the number of key versions. The above description has been given in detail with respect to the case where the key is generated based on the security key and the impact factor, and will not be described here.

Generally, the contract state changes after the CPU executes the plaintext code. 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, an Intel SGX technology may be used, ENC represents enclave, secret _ key represents a key used when the SGX technology is used to write into a database, and private keys corresponding to different contract states are also different in this specification.

In an embodiment, the first blockchain node outputs encrypted key-value pair data corresponding to the contract state from the trusted execution environment, and stores the encrypted key-value pair data to an external storage space outside the trusted execution environment by executing a storage function code outside the trusted execution environment.

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

Therefore, the first block chain node can ensure that the encrypted execution result is sufficiently safe by carrying out encrypted storage on the execution result and only carrying out decryption through the trusted execution environment. On this basis, the first block link point executes the storage function code outside the Trusted execution environment and stores the encrypted execution result into the external storage space outside the Trusted execution environment, so that the storage function code can be a code for realizing a storage function in the related art, and the encrypted execution result can be safely and reliably stored without re-writing the code in combination with the specification and requirements of the Trusted execution environment, and not only can the development amount of the related code be reduced on the basis of not influencing the safety and reliability, but also the TCB (Trusted Computing Base) can be reduced by reducing the related code of the Trusted execution environment, so that the additionally caused safety risk is in a controllable range in the process of combining the TEE technology and the block chain technology.

In one embodiment, the first block chain node may execute the write cache function code in the trusted execution environment to store the plaintext execution result corresponding to the contract state in a write cache in the trusted execution environment, for example, the write cache may correspond to a "cache" as shown in fig. 5. Further, the first block link point encrypts the data in the write cache and outputs the encrypted data from the trusted execution environment to the external storage space. The write cache function code can be stored in the trusted execution environment in a plaintext form, and the cache function code in the plaintext form can be directly executed in the trusted execution environment; alternatively, the write cache function code may be stored outside the trusted execution environment in a ciphertext form, for example, in the above-mentioned external storage space (for example, the "storage space" shown in fig. 5), and the write cache function code in the ciphertext form may be read into the trusted execution environment, decrypted in the trusted execution environment to be a plaintext code, and executed.

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

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

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

For example, the first block link point may read a ciphertext contract state from the external storage space, read into the trusted execution environment after decrypting the ciphertext contract state into the plaintext contract state, and then output the plaintext contract state from the trusted execution environment after encrypting the plaintext contract state, for example, return the encrypted plaintext contract state to the client through the transaction/query interface shown in fig. 5.

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

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

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

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

a determining unit 801, configured to determine an intelligent contract corresponding to the received transaction;

an execution unit 802 for executing the smart contract in a trusted execution environment;

a storage unit 803 for storing the execution result;

an encrypting unit 804, configured to encrypt, when storing the execution result, a key generated by the blockchain node according to a secure key saved in the trusted execution environment;

an updating unit 805, configured to update the security key of the low version to the security key of the high version when the version of the security key is updated, where the security key of the low version is calculated irreversibly from the security key of the high version. For encrypting with a key when storing contract states involved in the smart contract, and different contract states correspond to different keys.

Optionally, the security key of the highest version includes a seal key, and the security keys of other versions are computed irreversibly from the seal key directly or indirectly.

Alternatively to this, the first and second parts may,

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.

Optionally, the security key is stored in a ring of the first blockchain node.

Optionally, there are several enclosures in the first block link point, and the security key is stored in the security enclosure.

Optionally, the security enclosure includes a QE enclosure.

Optionally, the execution result relates to a plurality of contract states, each contract state being encrypted by the same key.

Optionally, the key is generated by the blockchain node according to the security key and at least one impact factor.

Optionally, the influence factor includes at least one of: a contract address of the intelligent contract, a code hash value of the intelligent contract, an account address of a contract creator of the intelligent contract, an account address of an initiator of the transaction.

Optionally, the execution result relates to a plurality of contract states, different contract states being encrypted by different keys.

Optionally, the execution result relates to contract states X1-Xn, corresponding to keys K1-Kn, respectively; and generating a key Ki corresponding to the contract state Xi by the block chain nodes according to the security key and at least one influence factor corresponding to the contract state Xi, wherein i is more than or equal to 1 and less than or equal to n.

Optionally, the impact factor includes at least one of the following private impact factors: the occurrence sequence Pi of the contract states Xi in the intelligent contract, the counting values Qi corresponding to the occurrence sequence, and the random numbers Si assigned to the contract states Xi.

Optionally, the impact factors include at least one of the following common impact factors: historical block height, block height of a block in which the transaction is located, a position offset of the transaction in the block in which the transaction is located, a contract address of the intelligent contract, a code hash value of the intelligent contract, an account address of a contract creator of the intelligent contract, an account address of an initiator of the transaction.

Optionally, the block link point stores the encrypted contract status and the generation mode description information of the corresponding key in an associated manner.

Optionally, the generation mode description information of the secret key Ki includes: version information of the security key and a value of an influence factor corresponding to the contract state Xi.

Optionally, when the block chain node stores the contract state related to the execution result by using a key value pair structure, the contract state and the corresponding key are encrypted respectively.

Optionally, the encryption unit 804 is specifically configured to:

the block chain node acquires a security key maintained in the trusted execution environment, and encrypts a key corresponding to the agreement state in a symmetric encryption mode or an asymmetric encryption mode; or the like, or, alternatively,

and after splicing the key corresponding to the contract state and the security key by the block link point, performing hash calculation on spliced data, and taking the hash value obtained by calculation as the encrypted key.

Optionally, the blockchain node encrypts the key corresponding to the agreement state by using the security key of the lowest version.

Optionally, the storage unit 803 is specifically configured to: and the block chain node executes a storage function code outside the trusted execution environment and stores the encrypted execution result to an external storage space outside the trusted execution environment.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified Programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Lola, HDL, laspam, hardsradware (Hardware Description Language), vhjhd (Hardware Description Language), and vhigh-Language, which are currently used in most common. 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, computer readable media does not include transitory computer readable media (transmyedia) such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising 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 securely updating keys in a blockchain, comprising:

the block chain node is encrypted by a key when storing an execution result, and the key is generated by the block chain node according to a security key stored in the trusted execution environment; the safety key is sent to the block chain node by a key management server, or the safety key is obtained by negotiation between the block chain node and other block chain nodes;

2. The method of claim 1, wherein the highest version of security key comprises a simple encryption algorithm library seal key, and other versions of security keys are computed irreversibly from the seal key, directly or indirectly.

3. The method of claim 2, 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 a software protection extension SGX of the block chain node passes remote certification; or the like, or, alternatively,

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

4. The method of claim 1, the security key stored in a circle created by a software protection extension (SGX) of the blockchain node.

5. The method of claim 4, the block link points present several enclosures, the security keys being stored in QE enclosures.

6. The method of claim 1, the execution result relating to a plurality of contract states, each contract state being encrypted by the same key.

7. The method of claim 6, the key being generated by the blockchain node from the security key and at least one impact factor.

8. The method of claim 7, the impact factor comprising at least one of: a contract address of the intelligent contract, a code hash value of the intelligent contract, an account address of a contract creator of the intelligent contract, an account address of an initiator of the transaction.

9. The method of claim 1, the execution result relating to a plurality of contract states, different contract states being encrypted by different keys.

10. The method of claim 9, the execution result relating to contract states X1-Xn, corresponding to keys K1-Kn, respectively; and generating a key Ki corresponding to the contract state Xi by the block chain nodes according to the security key and at least one influence factor corresponding to the contract state Xi, wherein i is more than or equal to 1 and less than or equal to n.

11. The method of claim 10, the impact factors comprising at least one of the following private impact factors: the occurrence sequence Pi of the contract states Xi in the intelligent contract, the counting values Qi corresponding to the occurrence sequence, and the random numbers Si assigned to the contract states Xi.

12. The method of claim 10, the impact factors comprising at least one of the following common impact factors: historical block height, block height of a block in which the transaction is located, a position offset of the transaction in the block in which the transaction is located, a contract address of the intelligent contract, a code hash value of the intelligent contract, an account address of a contract creator of the intelligent contract, an account address of an initiator of the transaction.

13. The method of claim 10, further comprising:

and the block link point stores the encrypted contract state and the generation mode description information of the corresponding key in an associated manner.

14. The method according to claim 13, wherein the generation of the secret key Ki description information comprises: version information of the security key and a value of an influence factor corresponding to the contract state Xi.

15. The method according to claim 1, wherein when the block chain node stores the contract state related to the execution result by using a key value pair structure, the contract state and the corresponding key are encrypted respectively.

16. The method of claim 15, the block link point encrypting a key corresponding to a contract state, comprising:

17. The method of claim 16, the blockchain node encrypts a key corresponding to the contract state with a lowest version of the security key.

18. The method of claim 1, the blockchain node encrypting with a key when storing execution results, comprising:

and the block chain node executes a storage function code outside the trusted execution environment and stores the encrypted execution result to an external storage space outside the trusted execution environment.

19. A node in a blockchain for securely updating keys, comprising:

a storage unit for storing an execution result;

an encryption unit configured to encrypt, when storing the execution result, a key generated by the node from a secure key saved in the trusted execution environment; the security key is sent to the node by a key management server, or the security key is obtained by negotiation between the node and other nodes;

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