CN113435883A

CN113435883A - Method and device for realizing dynamic encryption based on transaction offset

Info

Publication number: CN113435883A
Application number: CN202110611080.4A
Authority: CN
Inventors: 刘琦; 闫莺; 魏长征
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd
Priority date: 2019-05-31
Filing date: 2019-05-31
Publication date: 2021-09-24
Anticipated expiration: 2039-05-31
Also published as: CN110276610B; WO2020238955A1; CN110276610A

Abstract

One or more embodiments of the present specification provide a method and an apparatus for implementing dynamic encryption based on transaction offset, where the method may include: the block chain node decrypts the received transaction in the trusted execution environment to determine an intelligent contract corresponding to the transaction; the blockchain node executes the intelligent contract in a trusted execution environment, so that contract state contained in the intelligent contract is modified; and the block chain node encrypts the contract state in a trusted execution environment according to a public key and an influence factor so as to write the encrypted contract state into a database, wherein the influence factor comprises the position offset of the transaction in the block.

Description

Method and device for realizing dynamic encryption based on transaction offset

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for implementing dynamic encryption based on transaction offsets.

Background

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

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

In terms of addressing privacy, a Trusted Execution Environment (TEE) is another approach. The TEE can function as a black box in hardware, codes and data executed in the TEE cannot be peeped by an operating system layer, and the TEE can be operated only through an interface predefined in the codes. In the aspect of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptography operation in homomorphic encryption, efficiency loss does not exist in the calculation process, and therefore the safety and privacy of a block chain can be improved to a great extent on the premise of small performance loss by combining the TEE. The industry is concerned with TEE solutions, and almost all mainstream chip and Software consortiums have their own TEE solutions, including Software-oriented TPM (Trusted Platform Module) and hardware-oriented Intel SGX (Software Guard Extensions), ARM Trustzone (Trusted zone), and AMD PSP (Platform Security Processor).

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and apparatus for implementing dynamic encryption based on transaction offset.

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

according to a first aspect of one or more embodiments of the present specification, there is provided a method for implementing dynamic encryption based on transaction offsets, including:

the block chain node decrypts the received transaction in the trusted execution environment to determine an intelligent contract corresponding to the transaction;

the blockchain node executes the intelligent contract in a trusted execution environment, so that contract state contained in the intelligent contract is modified;

and the block chain node encrypts the contract state in a trusted execution environment according to a public key and an influence factor so as to write the encrypted contract state into a database, wherein the influence factor comprises the position offset of the transaction in the block.

According to a second aspect of one or more embodiments of the present specification, there is provided an apparatus for implementing dynamic encryption based on transaction offset, including:

the decryption unit is used for decrypting the received transaction in the trusted execution environment so as to determine the intelligent contract corresponding to the transaction;

an execution unit that executes the intelligent contract in a trusted execution environment, causing a contract state included in the intelligent contract to be modified;

an encryption unit, which encrypts the contract state in a trusted execution environment according to a public key and an influence factor, wherein the influence factor comprises a position offset of the transaction in the block;

and the storage unit is used for writing the encrypted contract state into the database.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic apparatus including:

a processor;

a memory for storing processor-executable instructions;

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

According to a fourth aspect of one or more embodiments of the present description, a computer-readable storage medium is presented, 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 flow chart of a method for implementing dynamic encryption based on transaction offsets as provided by an exemplary embodiment.

FIG. 4 is a schematic diagram of encryption with impact factors including only transaction offsets according to an example embodiment.

FIG. 5 is a block diagram illustrating encryption when the impact factor includes both block height and transaction offset according to an exemplary embodiment.

FIG. 6 is a cryptographic representation of an impact factor incorporating both transaction offsets and a modified order of contract states provided by an exemplary embodiment.

FIG. 7 is a schematic diagram of encryption with impact factors comprising block height, transaction offset, and modified order of contract status, according to an exemplary embodiment.

FIG. 8 is a block diagram of a key-value pair for a contract state, provided in an exemplary embodiment.

FIG. 9 is a key-value pair structure diagram of another contract state provided by an exemplary embodiment.

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

Fig. 11 is a block diagram of an apparatus for implementing dynamic encryption based on transaction offsets according to an example 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 (Private Blockchain) 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 participants of the block chain are block chain nodes (or simply nodes), the block chain nodes can read data records on the chain, participate in transactions, compete for the accounting right of new blocks and the like, and each block chain node forms a corresponding block chain network. Among the above types of blockchains, the most decentralized is the public chain. The public chain is represented by bitcoin and ether house, the participant joining the public chain can read the data record on the chain, participate in transaction, compete for the accounting right of the new block, and the like, and each participant can freely join and leave the network. Private chains are the opposite, with the write rights of the associated network controlled by an organization or organization and the read rights of the data specified by the organization or organization. Briefly, a private chain can be a weakly centralized system with strict restrictions and few participants. This type of blockchain is more suitable for use within a particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.

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

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

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

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

As previously described, the smart contracts deployed on the blockchain may be in the form of bytecodes. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. The intelligent contract code written by the high-level language is compiled by a compiler to generate byte codes, and the byte codes can be deployed on the block chain. The high-level languages supported by Etherns are many, such as Solidity, Serpent, LLL, etc.

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

The following is an example of code for a simple intelligent contract written in the Solidity language:

generally, after the contract is deployed in a blockchain, the storage state corresponding to the contract state of "balance" is plaintext, and anyone can see the state without setting and capability of privacy protection. If a user wants to protect state privacy, the contract needs to be rewritten by adopting a zero-knowledge proof and homomorphic encryption solution at present, so that the contract state of balance is protected through encryption, and all operations of balance in an encryption domain need to be supported. Generally, the encryption method is complex in operation, and it is difficult to design a proper algorithm to support the encryption domain. In some solutions where blockchains are combined with TEE, some or all of the contract state of an intelligent contract is stored as data requiring privacy protection in a database maintained at blockchain nodes in order to achieve privacy protection. The physical carrier of the database may be a storage medium, such as a persistent storage medium.

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 high-speed 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, only secure resource isolation may not meet the security requirements, so that further data privacy protection is also proposed. 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 a CPU supporting SGX as an example of a certain block link point, a part of an EPC (enclosure Page Cache, Enclave Page Cache, or Enclave Page Cache) may be allocated in a memory by using a newly added processor instruction, and data therein is encrypted by an Encryption engine mee (memory Encryption engine) in the CPU. The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. Therefore, in the SGX, a user may not trust an operating System, a VMM (Virtual Machine Monitor), or even a BIOS (Basic Input Output System), and only need to trust the CPU to ensure that private data is not leaked. Therefore, under the encryption protection of the CPU, the intelligent contract can be executed in the enclosure, the contract state can be generated, the contract state which needs privacy protection in the enclosure is encrypted, and the obtained ciphertext contract state is transmitted and stored, so that the strong computing power of the CPU can be utilized, and data leakage does not need to be worried about.

Fig. 3 is a flowchart of a method for implementing dynamic encryption in a blockchain according to an exemplary embodiment. As shown in fig. 3, the method applied to the blockchain node may include the following steps:

in step 302, the blockchain node decrypts the received transaction in the trusted execution environment to determine the intelligent contract corresponding to the transaction.

In one embodiment, a client may create a transaction that is used to create or invoke a smart contract. The client can encrypt the transaction through the key and send the encrypted transaction to the blockchain node, so that the blockchain node can decrypt the encrypted transaction in a trusted execution environment, and the intelligent contract corresponding to the transaction is determined.

As mentioned above, when the transaction is used to create a smart contract, the data field of the transaction holds the code of the smart contract, so that after the block link point decrypts the transaction, the corresponding smart contract can be read from the data field of the transaction. When the transaction is used for invoking the intelligent contract, the to field of the transaction contains the address of the invoked intelligent contract, so that after the block link point decrypts the transaction, the address of the intelligent contract can be read from the to field of the transaction, and the code of the corresponding intelligent contract is obtained based on the address.

When the transaction is used to invoke a smart contract, it may be an invocation of multiple nested structures. For example, a transaction directly calls intelligent contract 1, while the code of intelligent contract 1 calls intelligent contract 2, and the code in intelligent contract 2 points to the contract address of intelligent contract 3, so that the transaction actually indirectly calls the code of intelligent contract 3. In this way, when the contract state defined in the smart contract 1, the smart contract 2, or the smart contract 3 is modified, the specification can encrypt and store the modified contract state.

In one embodiment, the encryption of the transaction by the client may be symmetric encryption, asymmetric encryption, or a combination of symmetric encryption and asymmetric encryption. When symmetric encryption is adopted, the client encrypts the transaction through an encryption key, and the block chain nodes decrypt the transaction through the same encryption key; correspondingly, the adopted symmetric encryption algorithm can be a DES algorithm, a 3DES algorithm, a TDEA algorithm, a Blowfish algorithm, an RC5 algorithm, an IDEA algorithm and the like. When asymmetric encryption is adopted, the client encrypts the transaction through a public key, and the block chain nodes decrypt the transaction through a private key; accordingly, the asymmetric encryption algorithm used is, for example, RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), etc. When symmetric encryption is combined with asymmetric encryption, the client can encrypt the transaction by adopting a symmetric encryption algorithm, namely encrypting the transaction by adopting a key of the symmetric encryption algorithm, and encrypting the key adopted in the symmetric encryption algorithm by using the asymmetric encryption algorithm, such as encrypting the key adopted in the symmetric encryption algorithm by adopting a public key of the asymmetric encryption algorithm; therefore, after the block chain node receives the encrypted transaction, the block chain node can firstly decrypt by adopting the private key of the asymmetric encryption algorithm to obtain the key of the symmetric encryption algorithm, and then decrypt the transaction by using the key of the symmetric encryption algorithm.

Step 304, the blockchain node executes the intelligent contract in a trusted execution environment, so that the contract state contained in the intelligent contract is modified.

As previously described, block link points may be enabled by performing intelligent contracts in the TEE to ensure that the contract state and its values do not leak. For example, after the decryption process, the block link point may obtain the plaintext code of the smart contract corresponding to the transaction, and execute the obtained plaintext code in the TEE. Specifically, the block link point may use a processor instruction newly added in the CPU, may allocate a part of the area EPC in the memory, and encrypt the plaintext code by using an encryption engine MEE in the CPU and store the plaintext code in the EPC. The encrypted content in the EPC is decrypted into a plaintext, i.e., the plaintext code, after entering the CPU, so that the CPU can perform an operation on the plaintext code to complete an execution process.

In the SGX technique, the EVM can be loaded into the enclosure, so that the EVM can execute the plain-text code in the enclosure, thereby fully utilizing the powerful computing power of the CPU. In the remote certification process, the key management server can calculate the hash value of the local EVM code, compare the hash value with the hash value of the EVM code loaded in the block chain link point, and correctly use the comparison result as a necessary condition for passing the remote certification, thereby completing the measurement of the code loaded by the block chain node SGX enclosure. Measured, the correct EVM can execute the plaintext code of the intelligent contract corresponding to the transaction in the SGX, and ensure that the results of all correct EVMs after executing the same code section are the same.

Generally, after the CPU executes the plaintext code of the intelligent contract, part or all of the contract states defined in the plaintext code may change, that is, part or all of the contract states are modified, and the specification may reliably encrypt the modified contract states and store the encrypted contract states in a database maintained by a block link point, so as to implement high-level data security and privacy protection.

And step 306, encrypting the contract state by the blockchain node in the trusted execution environment according to the public key and the influence factor to write the encrypted contract state into the database, wherein the influence factor comprises the position offset of the transaction in the block.

In one embodiment, the contract status is stored in the block chain, and from the perspective of the block link point, the contract status 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.

In an embodiment, the block chain nodes may encrypt the contract state according to the public key and the influence factor, so that the value of the encrypted contract state is simultaneously affected by the public key and the influence factor, and the randomness of the encrypted contract state may be increased by the differentiated influence factor under the condition that the public keys are the same. In other words, when the public keys are the same, by using different influencing factors, even if the encryption is performed on the contract states with the same value, the obtained encrypted contract states have different values. Therefore, compared with the method that all contract states are encrypted by adopting the public key, the method can prevent lawless persons from mastering the value change rule of the encrypted contract states, prevent the lawless persons from speculating the value of the contract states through trial and comparison, and has higher safety.

In one embodiment, the impact factor may only include the location offset of the transaction in the block where the transaction is located. The block comprises a plurality of packaged transactions which are arranged in sequence according to a certain sequence, and all the block chain nodes can execute the transactions in sequence according to the same sequence when executing the transactions contained in the block, so that the data consistency among all the block chain nodes is ensured. The position offset corresponding to the transaction is related to the arrangement sequence of the transaction in the block; for example, when the transaction is the first transaction in the block, the position offset of the transaction is 0, when the transaction is the second transaction in the block, the position offset of the transaction is 1, when the transaction is the ith transaction in the block, the position offset of the transaction is i-1, and so on. Therefore, for the contract states modified after the respective transactions in the same block are executed, because the respective transactions in the block correspond to completely different position offsets, when the block chain node encrypts the respective contract states according to the public key and the influence factor, even if the contract states have the same value, the obtained encrypted contract states are completely different, thereby increasing the value randomness of the encrypted contract states. For the transactions in different blocks, if the position offset amounts corresponding to the transactions are different, for example, transaction 1 with the position offset amount of offset1 in block H1, transaction 2 with the position offset amount of offset2 in block H2, and the like, it can be ensured that when the contract states corresponding to the transactions are encrypted, the encrypted contract states corresponding to the contract states with the same value also have different values. It can be seen that, when the influence factor is the position offset of the transaction in the block, the value randomness of each encrypted contract state can be increased in the transaction dimension, so that the value change of the rule that can be followed cannot be generated between the encrypted contract states corresponding to the transactions in the same block, and the value change of the rule that can be followed cannot be generated between the encrypted contract states corresponding to the transactions with different position offsets in different blocks.

Assuming that block B1 and block B2 are included in a certain blockchain network, the block height of block B1 is H1 and the block height of block B2 is H2. For convenience of understanding, it is assumed that the block B1 includes transactions Tx1 and Tx2, the block B2 includes transactions Tx3 and Tx4, the position offsets corresponding to the transactions Tx1 and Tx3 in the blocks B1 and B2 are Offset1, and the position offsets corresponding to the transactions Tx2 and Tx4 in the blocks B1 and B2 are Offset 2; meanwhile, the transactions Tx1 and Tx3 each define contract states Balance1 and Balance2, and the transactions Tx2 and Tx4 each define contract states Balance3 and Balance 4.

When the impact factor contains only the position offset of the transaction in the block where it is located, as shown in fig. 4: for the contract states of Balance1, Balance2, Balance3, Balance4 and the like involved in block B1, different transactions correspond to different transaction offsets in block B1, for example, transaction Tx1 to which Balance1 and Balance2 belong corresponds to transaction Offset1, transaction Tx 8 to which Balance3 and Balance 68692 belong corresponds to transaction Offset2, so that public Key128 (i.e., a security Key with a version number of 128, see the description below about the Key version) can be used, or other forms of public keys can be used, which are used only for example here) and transaction Offset1 are used to perform encryption operations on Balance1 and Balance2 in the contract states, so as to obtain S-Balance 42-1 corresponding to Balance1 and S-Balance2-1 corresponding to Balance 39 2 respectively. Meanwhile, encryption operations can be respectively carried out on the contract states Balance3 and Balance4 by adopting the public Key128 and the transaction Offset2, so that S-Balance3-1 corresponding to Balance3 and S-Balance4-1 corresponding to Balance4 are respectively obtained.

Similarly, for block B2, different transactions correspond to different transaction offsets in block B2, such as transaction Tx3 to which Balance1 and Balance2 belong corresponds to transaction Offset1, and transaction Tx4 to which Balance3 and Balance4 belong corresponds to transaction Offset2, so that encryption operations can be respectively performed on contract states Balance1 and Balance2 by using public Key128 and transaction Offset1, so as to respectively obtain R-Balance1-1 corresponding to Balance1 and R-Balance2-1 corresponding to Balance 2. Meanwhile, encryption operations can be respectively carried out on the contract states Balance3 and Balance4 by adopting the public Key128 and the transaction Offset2, so that R-Balance3-1 corresponding to Balance3 and R-Balance4-1 corresponding to Balance4 are respectively obtained.

In addition to the "offset of the position of the transaction in the located block", the influence factor may further include other conditions, for example, the other conditions may include one or more of "height of the block where the transaction is located", "modified order of the contract state when the intelligent contract is executed", and the like, so as to obtain the influence factor formed by combining a plurality of conditions, and the encryption operation may be performed on the contract state in other dimensions.

In one embodiment, the impact factor may be a tile height of the tile in which the transaction is located, a position offset of the transaction in the tile in which the transaction is located. In conjunction with the above description of the condition "height of block where transaction is located", and the condition "offset of position where transaction is located in block", respectively, it can be seen that: the condition 'the block height of the block where the transaction is located' can realize encryption control of the dimension of the block, ensure that the encrypted contract state cannot generate regular value change between different blocks necessarily, and the condition 'the position offset of the transaction in the block' can realize encryption control of the transaction dimension, ensure that the encrypted contract state cannot generate regular value change between different transactions in the same block necessarily, so when the influence factors simultaneously comprise the two conditions, the encryption control of the dimension of the block and the transaction dimension can be realized, so that the encrypted contract state cannot generate regular value change between different transactions necessarily, no matter whether the transactions are in the same block or different blocks. For different transactions in the same block, encryption control can be realized through the condition of 'position offset of the transaction in the block where the transaction is located', because different transactions in the same block necessarily have different position offsets; for different transactions of different blocks, even if the corresponding position offsets of the blocks where the transactions are located are the same, encryption control can be further realized by the condition of 'the block height of the block where the transactions are located', because the transactions of different blocks necessarily have different block heights.

The above-mentioned blocks B1 and B2 are also taken as examples. As shown in fig. 5, when the block link points simultaneously consider the position Offset amount corresponding to the block height and the transaction, for the contract states such as Balance1, Balance2, Balance3, Balance4 and the like related to the block B1, since Balance1 and Balance2 come from the transaction Tx1 and the position Offset amount corresponding to the transaction Tx1 is Offset1, Balance1 and Balance2 are encrypted respectively by the public Key128, the block height H1 and the position Offset amount Offset1, for example, S-Balance1-2 is obtained after encryption of Balance1, and S-Balance2-2 is obtained after encryption of Balance 2. Meanwhile, since Balance3 and Balance4 come from transaction Tx2, and the position Offset corresponding to the transaction Tx2 is Offset2, Balance3 and Balance4 are respectively encrypted through the public Key128, the block height H1 and the position Offset2, for example, Balance3 is encrypted to obtain S-Balance3-2, and Balance4 is encrypted to obtain S-Balance 4-2.

Similarly, for block B2, since Balance1 and Balance2 come from transaction Tx3, and the position Offset corresponding to the transaction Tx3 is Offset1, Balance1 and Balance2 are encrypted respectively by public Key128, block height H2 and position Offset1, for example, Balance1 is encrypted to obtain R-Balance1-2, and Balance2 is encrypted to obtain R-Balance 2-2. Meanwhile, Balance3 and Balance4 come from transaction Tx4, and the position Offset corresponding to the transaction Tx4 is Offset2, so that Balance3 and Balance4 are respectively encrypted through the public Key128, the block height H2 and the position Offset2, for example, Balance3 is encrypted to obtain R-Balance3-2, and Balance4 is encrypted to obtain R-Balance 4-2.

In one embodiment, the impact factor may be a position offset of the transaction in the block in which the transaction is located, a modified order of contract states when the smart contract is executed. In conjunction with the above description of the condition "the position offset of the transaction in the block where it is located", and the condition "the modified order of the contract states when the smart contract is executed", respectively, it can be seen that: the condition "position offset of the transaction in the block" can realize encryption control of transaction dimension, ensure that the encrypted contract state cannot generate value change with the rule being able to follow inevitably between different transactions in the same block, and the condition "modified order of the contract state when the intelligent contract is executed" can realize encryption control of state dimension, ensure that the encrypted contract state cannot generate value change with the rule being able to follow inevitably between different contract states generated by the same transaction, so when the influence factor contains the two conditions, encryption control of transaction dimension and state dimension can be realized, so that even if the contract states respectively generated by different transactions in the same block have the same modified order, value change with the rule being able to follow inevitably generated by the encrypted contract state cannot be realized. Wherein, for a plurality of contract states generated by the same transaction, the encryption control can be realized by the condition "the modified order of the contract states when the intelligent contract is executed", because different contract states generated by the same transaction necessarily have different modified orders; while for contract states respectively generated for different transactions of the same block, even if the contract states have the same number of times of being modified in the respective transactions, encryption control can be further realized by the condition "position offset of the transaction in the block where the transaction is located", since different transactions of the same block necessarily have different position offsets.

The above-mentioned blocks B1 and B2 are also taken as examples. As shown in fig. 6, when block link points simultaneously consider the modified orders of the transaction offsets and the contract states, for the contract states such as Balance1, Balance2, Balance3 and Balance4 involved in block B1, Balance1 and Balance2 come from the same transaction Tx1, so that Balance1 and Balance2 necessarily correspond to the same transaction Offset and different modified orders, for example, the transaction Offset of transaction Tx1 is Offset1, Balance1 corresponds to modified order U1 and Balance2 corresponds to modified order U2, and Balance1 is encrypted by public Key128, transaction Offset of 1 and modified order U1 to obtain encrypted S-Balance1-3, while Balance2 is encrypted by public Key128, transaction Offset of 1 and modified order U56 to obtain encrypted Balance 84863. Meanwhile, since Balance3 and Balance4 come from the same transaction Tx2, Balance3 and Balance4 necessarily correspond to the same transaction Offset and different modified orders respectively, for example, the transaction Offset of transaction Tx2 is Offset2, Balance3 corresponds to modified order U1, and Balance4 corresponds to modified order U2, Balance3 is encrypted through public Key128, transaction Offset2 and modified order U1 to obtain encrypted S-Balance3-3, and Balance4 is encrypted through public Key128, transaction Offset2 and modified order U2 to obtain encrypted S-Balance 4-3.

Similarly, for block B2, since Balance1 and Balance2 are from the same transaction Tx3, so that Balance1 and Balance2 necessarily correspond to the same transaction Offset and different modified orders respectively, for example, the transaction Offset of transaction Tx3 is Offset1, Balance1 corresponds to modified order U1, and Balance2 corresponds to modified order U2, Balance1 is encrypted by public Key128, transaction Offset of 1 and modified order U1, resulting in encrypted R-Balance1-3, and Balance2 is encrypted by public Key128, transaction Offset of 1 and modified order U2 resulting in encrypted R-Balance 2-3. Meanwhile, since Balance3 and Balance4 come from the same transaction Tx4, Balance3 and Balance4 necessarily correspond to the same transaction Offset and different modified orders respectively, for example, the transaction Offset of transaction Tx4 is Offset2, Balance3 corresponds to modified order U1, and Balance4 corresponds to modified order U2, Balance3 is encrypted through public Key128, transaction Offset2 and modified order U1 to obtain encrypted R-Balance3-3, and Balance4 is encrypted through public Key128, transaction Offset2 and modified order U2 to obtain encrypted R-Balance 4-3.

In one embodiment, the influence factor may be "block height of a block where the transaction is located", "position offset of the transaction in the block" and "modified order of the contract states when the smart contract is executed", and encryption control of the block dimension, the transaction dimension and the state dimension may be implemented, so that encrypted contract states generated by any two contract states do not necessarily generate regular value change, regardless of whether the any two contract states are from the same transaction or different transactions, and whether different transactions are from the same block or different blocks. Wherein, for a plurality of contract states generated by the same transaction, the encryption control can be realized by the condition "the modified order of the contract states when the intelligent contract is executed", because different contract states generated by the same transaction necessarily have different modified orders; for contract states respectively generated by different transactions of the same block, even if the contract states have the same modified times in the respective transactions, encryption control can be further realized through a condition of 'position offset of the transactions in the block', because different transactions of the same block necessarily have different position offsets; the contract states respectively generated for a plurality of transactions of different blocks can be further encrypted under the condition of "block height of the block where the transaction is located" even if the contract states have the same number of times of being modified in the respective transactions, since transactions of different blocks necessarily have different block heights.

The above-mentioned blocks B1 and B2 are also taken as examples. As shown in fig. 7, when block link points simultaneously consider the block heights, the transaction-corresponding position offsets, and the modified order of the contract states, for example, Balance1, Balance2, Balance3, Balance4, which are related to block B1, since Balance1 and Balance2 are from transaction Tx1, Balance1 and Balance2 respectively correspond to different modified orders, for example, Balance1 corresponds to modified order U1, Balance2 corresponds to modified order U2, and assuming that the transaction Tx1 corresponds to position Offset1, Balance1-4 can be encrypted by public Key128, block height H1, position Offset of 1, and modified order U1, and Balance1-4 can be encrypted, while Balance1 is encrypted by public Key128, block height H1, position Offset 72, and modified order U1, Balance 1-368744 is encrypted. Meanwhile, since Balance3 and Balance4 come from transaction Tx2, Balance3 and Balance4 necessarily correspond to different modified orders respectively, for example, Balance3 corresponds to modified order U1, Balance4 corresponds to modified order U2, and assuming that the position Offset corresponding to transaction Tx2 is Offset2, Balance3 can be encrypted through public Key128, block height H1, position Offset of 2 and modified order U1 to obtain encrypted S-Balance3-4, and Balance4 can be encrypted through public Key128, block height H1, position Offset of 2 and modified order U2 to obtain encrypted S-Balance 4-4.

Similarly, for the contract states of Balance1, Balance2, Balance3, Balance4 and Balance4 related to block B2, since Balance1 and Balance2 are from transaction Tx3, Balance1 and Balance2 necessarily correspond to different modified orders respectively, for example, Balance1 corresponds to modified order U1 and Balance2 corresponds to modified order U2, and assuming that the position Offset corresponding to transaction Tx3 is Offset1, Balance1 may be encrypted by public Key128, block height H2, position Offset1 and modified order U1 to obtain encrypted R-Balance1-4, while Balance2 may be encrypted by public Key128 Key, block height H2, position Offset1 and modified order U2 to obtain encrypted R-Balance R-2. Meanwhile, since Balance3 and Balance4 come from transaction Tx4, Balance3 and Balance4 necessarily correspond to different modified orders respectively, for example, Balance3 corresponds to modified order U1, Balance4 corresponds to modified order U2, and assuming that the position Offset corresponding to transaction Tx4 is Offset2, Balance3 can be encrypted through public Key128, block height H2, position Offset of 2 and modified order U1, so as to obtain encrypted R-Balance3-4, and Balance4 can be encrypted through public Key128, block height H2, position Offset of 2 and modified order U2, so as to obtain encrypted R-Balance 4-4.

In one embodiment, the block link point reads the received encrypted transaction into the trusted execution environment for decryption and executes the corresponding intelligent contract, encrypts the contract state which is modified in the trusted execution environment, and writes the contract state into the database for storage, so that the cryptograph is ensured outside the trusted execution environment to ensure data security, and the cryptograph can be decrypted into the plaintext in the trusted execution environment for processing to fully utilize the computing power of the CPU.

When the block chain node encrypts the contract state according to the public key and the influence factor in the trusted execution environment, various selectable encryption means exist, and the encryption solution in the related technology can be used for reference. Two possible encryption solutions are described below.

In one embodiment, the block link point may encrypt the contract status via a GCM (Galois/Counter Mode) algorithm; the letter G in the GCM represents GMAC (Galois message authentication code) and the letter C represents CTR (countter CounTeR mode). The inputs to the GCM algorithm include 3 parts: in this specification, the contract state may be used as data to be encrypted, the public key may be used as a symmetric key required by a GCM algorithm, and the influence factor may be used as an Initialization Vector required by the GCM algorithm, so as to encrypt the contract state, and generate a corresponding encrypted contract state and a corresponding check code, where the check code may be used to check the integrity of the encrypted contract state.

Thus, the blockchain node, when storing the encrypted contract state, may write a check code to the database in association with the encrypted contract state. Then, when subsequently decrypting the encrypted contract state, if the decryption fails, the encrypted contract state can be verified through the verification code: when the verification is successful, the data indicating the encrypted contract state is complete, and the decryption failure caused by other factors, such as an input key or an influence factor error; when the check fails, the data indicating the encrypted contract status is incomplete.

In another embodiment, the block nodes may generate the derived key according to the public key and the impact factor, for example, the public key and the impact factor are concatenated and then subjected to a hash operation or other operations to obtain the derived key; the block link node may then encrypt the contract state based on the derived key to generate an encrypted contract state.

In one embodiment, the public key is stored in a surrounding ring on a block link point. Because only the CPU can access the public key stored in the enclosure, the public key is safe enough and can not be obtained by lawless persons theoretically, and the safety of the encrypted contract state is ensured.

The public key can be distributed to the block chain nodes by a Key Management Server (KMS) after being remotely proved by the block chain nodes; or, the public key can be obtained by negotiation among all nodes in the block chain network; alternatively, the public key may be obtained in other ways, which is not limited by this specification.

The key obtained based on the above approach may not be a public key. For example, the key obtained by the channel may be a security key, and the security key may implement version evolution, so that the public key is evolved. In other words, the public key may be a security key of a specified version; among the neighboring versions of the security key, the lower version of the security key is irreversibly calculated from the higher version of the security key, for example, the highest version of the security key is a root key (root key), and the other versions of the security key are irreversibly calculated directly or indirectly from the root key. For example, the low-version security key is obtained by performing hash operation on the high-version security key and the preset information, and due to the characteristics of the hash operation, the low-version security key cannot be reversely deduced from the high-version security key, so that the public key can be replaced by the version evolution of the security key, and the same public key is prevented from being used for a long time. And, when the public key is replaced, the version of the key after replacement can be ensured to be always higher than that of the key before replacement, so as to ensure that: on one hand, even if the key used previously is leaked, the key can be replaced by a key with a high version to stop loss in time; on the other hand, as long as the high-version key is possessed, the low-version key can be evolved, and the previously used key is compatible, so that the previously encrypted contract state is decrypted.

The version evolution rules between security keys may be: and carrying out hash operation on the adjacent high-version secret key and the version number corresponding to the adjacent low-version secret key to obtain the adjacent low-version secret key. For example, if 256 versions of keys with version numbers of 0 to 255 are derived, hash calculation can be performed on the root key and the version number 0xFF (corresponding decimal value is 255) to obtain a key-255 with the version number of 255; carrying out hash calculation on the key-255 and a version factor 0xFE (the corresponding decimal value is 254) to obtain the key-254 with the version number of 254; … …, the key-0 with version number 0 is obtained by performing hash calculation on the key-1 and the version factor 0x00 (corresponding decimal value is 0). 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. Thus, a version of the security key may be selected and set as the public key used by the blockchain node for cryptographic processing of the contract state.

As described above, the block link node encrypts the contract status according to the public key and the influence factor to obtain the encrypted contract status. If the public key and the influence factor are fixed values, the public key and the influence factor are only required to be separately stored in the enclosure; however, if the public key or the impact factor has a dynamic value, that is, different public keys or impact factors may be used when encrypting different contract states, then when storing the encrypted contract state, the public key, the impact factor or information indicating the value should be stored in association with each other, so as to facilitate the subsequent decryption operation.

Given the dynamic change in the value of the impact factor, the impact factor may be written to the database in association with the encrypted contract state. For example, as shown in fig. 8, the blockchain node stores the encrypted contract state in the form of a key-value pair (key-value). The Key value may be determined by referring to a manner in the related art, such as Key hash (RLP (value)), that is, the Key value is a hash value of a value encoded by RLP (Recursive Length Prefix). While the components of value may include: a post-encryption contract state, a check value, and an impact factor. The encrypted contract status may be obtained by encrypting according to the public key and the influencing factor in the manner described in the above embodiment. When encryption is performed using, for example, the GCM algorithm or other encryption algorithms, a check value may also be obtained; of course, if no check value exists, the check value may not be included in the value. The values of the impact factors exist in the above-mentioned cases, and fig. 8 takes the case that the impact factors include the block height, the transaction offset and the modification order at the same time, that is, the impact factors are composed of "the block height of the block where the transaction is located", "the position offset of the transaction in the block" and "the modified order of the contract state when the intelligent contract is executed".

Based on the embodiment shown in fig. 8, after reading this key-value pair, the blockchain node may obtain the impact factor required for decryption from the value of the key-value pair, so as to decrypt the encrypted contract state in combination with the public key. In some scenarios, the impact factor may be encrypted, for example, the impact factor is encrypted in the TEE by the blockchain node in the storage stage, so that the value includes the encrypted impact factor instead of the impact factor in the form of plaintext; accordingly, after the key value pair shown in fig. 8 is read, the influence factor in the plaintext form cannot be directly obtained, so that the decryption threshold of the encrypted contract state can be further improved, and the security is improved.

The block chain node may encrypt the impact factor with any key. Although the above-mentioned public key may be used to encrypt the influencing factor, in order to increase the diversity of the key and improve the security, the influencing factor may be encrypted by using another key different from the public key. For example, when the public key is a key of a certain version, the key for encrypting the influencing factor can be of another version so as to be distinguished from the public key; for example, the impact factor may be encrypted using the lowest version key with a version number of 0, and the version number of the public key may be set to be necessarily greater than 0.

Version information may exist for the public key, such as a security key for which the public key is a version of the aforementioned version. When the blockchain node stores the key value pair of the encrypted contract state, the value may include version information of the public key, and particularly, when the version of the public key used by the blockchain node is updated, the version of the currently used public key may be different from the previously stored historical public key used in the encrypted contract state, so that the version information included in the value may help the blockchain node to accurately select the key to be used. For example, as shown in fig. 9, based on the embodiment shown in fig. 8, an information field may be included in the value of the key-value pair, and the information field may further include a version information subfield for recording version information of the public key.

The block link point can be added to the value after encrypting the version information, instead of recording the version information in a plaintext form. The key used for encrypting the version information may be a public key, or another key different from the public key, for example, the version information may be encrypted with the lowest version key having a version number of 0, similar to the aforementioned influencing factor.

In summary, compared with the method of encrypting by using a public key alone, the method of encrypting the contract state by using the public key according to the present specification can increase randomness of the encrypted contract state by using the impact factor, so as to improve data security.

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

Referring to fig. 11, in a software implementation, the apparatus for implementing dynamic encryption based on transaction offset may include:

a decryption unit 1101, configured to decrypt the received transaction in the trusted execution environment to determine a smart contract corresponding to the transaction;

an execution unit 1102 that executes the intelligent contract in a trusted execution environment, causing a contract state included in the intelligent contract to be modified;

an encryption unit 1103, configured to encrypt the contract state in the trusted execution environment according to a public key and an impact factor, where the impact factor includes a position offset of the transaction in the block;

a storage unit 1104, configured to write the encrypted contract status into the database.

Optionally, the influence factor further includes at least one of: the block height of the block in which the transaction is located, the modified order of the contract states when the smart contract is executed.

Optionally, the impact factor is written to a database in association with the encrypted contract state.

Optionally, the impact factor is written to the database in association with the encrypted contract state after being encrypted in the trusted execution environment.

Optionally, the encryption unit 1103 is specifically configured to:

the public key is used as a symmetric key required by the GCM algorithm, the influence factor is used as an initialization vector required by the GCM algorithm, the contract state is encrypted through the GCM algorithm, and the encrypted contract state and a corresponding check code are generated; wherein the check code is written to a database in association with the encrypted contract status.

Optionally, the encryption unit 1103 is specifically configured to:

generating a derived key according to the public key and the influence factor;

and encrypting the contract state according to the derived key to generate the encrypted contract state.

Optionally, the public key includes: a security key of a specified version; wherein, among the adjacent versions of the security key, the low version of the security key is irreversibly calculated from the high version of the security key.

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

Optionally, version information of the public key is written to a database in association with the encrypted contract state.

Optionally, after the version information of the public key is encrypted in the trusted execution environment, the version information is written to the database in association with the encrypted contract state.

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. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

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

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

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

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

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

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

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

Claims

1. A method for implementing dynamic encryption based on transaction offsets, comprising:

the block chain node decrypts the received transaction in a trusted execution environment and determines an intelligent contract corresponding to the transaction;

the blockchain node executes the intelligent contract in a trusted execution environment, causing a contract state of the intelligent contract to be modified;

the block chain node encrypts the contract state in a trusted execution environment according to a public key and an influence factor, and writes the encrypted contract state into a database; wherein the impact factor comprises a position offset of the transaction in the block in which the transaction is located.

2. The method of claim 1, wherein the position offset corresponding to a transaction is related to the rank order in the block, such that different transactions in the same block have different position offsets.

3. The method of claim 1, the writing encrypted contract state to a database comprising:

writing the impact factor to a database in association with the encrypted contract state.

4. The method of claim 3, the writing the impact factor to a database in association with the post-encryption contract state comprising:

encrypting the impact factor in a trusted execution environment, and writing the encrypted impact factor to a database in association with the encrypted contract state.

5. The method of claim 1, the impact factor further comprising: a block height of a block in which the exchange is located, and/or a modified order of the contract states when the intelligent contract is executed.

6. The method of claim 1, the blockchain node encrypting the contract state in a trusted execution environment according to a public key and an impact factor, comprising:

the block chain node uses the public key as a symmetric key required by a GCM algorithm, uses the influence factor as an initialization vector required by the GCM algorithm, encrypts the contract state through the GCM algorithm, and generates the encrypted contract state and a corresponding check code; wherein the check code is written to a database in association with the encrypted contract status.

7. The method of claim 1, the blockchain node encrypting the contract state in a trusted execution environment according to a public key and an impact factor, comprising:

the block chain node generates a derived key according to the public key and the influence factor;

and the block chain link point encrypts the contract state according to the derived key to generate the encrypted contract state.

8. The method of claim 1, the public key comprising: a security key of a specified version; wherein, among the adjacent versions of the security key, the low version of the security key is irreversibly calculated from the high version of the security key.

9. The method of claim 8, wherein the highest version of the security key is a root key, and other versions of the security key are computed irreversibly or directly from the root key.

10. The method of claim 8, wherein version information for the public key is written to a database in association with the encrypted contract state.

11. The method of claim 10, wherein version information of the public key is written to a database in association with the encrypted contract state after being encrypted in a trusted execution environment.

12. An apparatus for implementing dynamic encryption based on block height, comprising:

the decryption unit is used for decrypting the received transaction in the trusted execution environment and determining the intelligent contract corresponding to the transaction;

an execution unit to execute the intelligent contract in a trusted execution environment, causing a contract state of the intelligent contract to be modified;

the encryption unit encrypts the contract state in a trusted execution environment according to a public key and an influence factor, wherein the influence factor comprises a position offset of the transaction in the block;

13. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

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

14. 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 11.