WO2020238958A1 - 基于合约状态的修改次序实现动态加密的方法及装置 - Google Patents

基于合约状态的修改次序实现动态加密的方法及装置 Download PDF

Info

Publication number
WO2020238958A1
WO2020238958A1 PCT/CN2020/092606 CN2020092606W WO2020238958A1 WO 2020238958 A1 WO2020238958 A1 WO 2020238958A1 CN 2020092606 W CN2020092606 W CN 2020092606W WO 2020238958 A1 WO2020238958 A1 WO 2020238958A1
Authority
WO
WIPO (PCT)
Prior art keywords
contract
state
encrypted
key
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2020/092606
Other languages
English (en)
French (fr)
Inventor
刘琦
闫莺
魏长征
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Original Assignee
Advanced New Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Publication of WO2020238958A1 publication Critical patent/WO2020238958A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and more particularly to a method and device for realizing dynamic encryption based on the modification sequence of contract status.
  • Blockchain technology is built on a transmission network (such as a peer-to-peer network).
  • the network nodes in the transmission network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data. Nodes in these blockchain networks sometimes need to be increased.
  • TEE Trusted Execution Environment
  • TEE can play the role of a black box in the hardware.
  • the code and data executed in the TEE cannot be peeped by the operating system layer, and can only be operated through the pre-defined interface in the code.
  • TEE In terms of efficiency, due to the black-box nature of TEE, what is calculated in TEE is plaintext data, rather than complex cryptographic operations in homomorphic encryption. There is no efficiency loss in the calculation process. Therefore, the combination with TEE can achieve less performance loss. Under the premise, the security and privacy of the blockchain are greatly improved. At present, the industry pays close attention to the TEE solution.
  • TEE solutions including TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions) in hardware. , Software Protection Extension), ARM Trustzone (trust zone) and AMD PSP (Platform Security Processor, platform security processor).
  • one or more embodiments of this specification provide a method and device for realizing dynamic encryption based on the modification sequence of the contract state.
  • a method for realizing dynamic encryption based on the modification sequence of the contract state including:
  • the blockchain node decrypts the received transaction in the trusted execution environment to determine the smart contract corresponding to the transaction;
  • the blockchain node executes the smart contract in a trusted execution environment, so that the contract state included in the smart contract is modified;
  • the blockchain node encrypts the state of the contract according to the public key and the influence factor in a trusted execution environment to write the encrypted contract state into the database, wherein the influence factor includes the state of the contract in the The order in which the smart contract is modified when it is executed.
  • a device for realizing dynamic encryption based on the modification sequence of contract status including:
  • the decryption unit decrypts the received transaction in the trusted execution environment to determine the smart contract corresponding to the transaction
  • the execution unit executes the smart contract in a trusted execution environment, so that the contract state contained in the smart contract is modified;
  • An encryption unit for encrypting the state of the contract in a trusted execution environment according to a public key and an impact factor, where the impact factor includes the order in which the contract state is modified when the smart contract is executed;
  • the storage unit is used to write the encrypted contract state into the database.
  • an electronic device including:
  • a memory for storing processor executable instructions
  • the processor implements the method according to the first aspect by running the executable instruction.
  • a computer-readable storage medium is provided, and computer instructions are stored thereon, which, when executed by a processor, implement the steps of the method described in the first aspect.
  • Fig. 1 is a schematic diagram of creating a smart contract according to an exemplary embodiment.
  • Fig. 2 is a schematic diagram of invoking a smart contract provided by an exemplary embodiment.
  • Fig. 3 is a flow chart of a method for realizing dynamic encryption based on the modification sequence of the contract state according to an exemplary embodiment.
  • Fig. 4 is a schematic diagram of encryption provided by an exemplary embodiment when the impact factor only includes the modified order of the contract state.
  • Fig. 5 is a schematic diagram of encryption when an impact factor includes both the modified order of the contract state and the block height provided by an exemplary embodiment.
  • Fig. 6 is a schematic diagram of encryption provided by an exemplary embodiment when the impact factor includes both the modified order of the contract state and the transaction offset.
  • FIG. 7 is a schematic diagram of encryption provided by an exemplary embodiment when the impact factor includes the block height, the transaction offset, and the modification sequence of the contract state.
  • Fig. 8 is a schematic structural diagram of a key-value pair of a contract state provided by an exemplary embodiment.
  • Fig. 9 is a schematic structural diagram of another key-value pair of a contract state provided by an exemplary embodiment.
  • Fig. 10 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • Fig. 11 is a block diagram of a device for realizing dynamic encryption based on the modification sequence of contract status according to an exemplary embodiment.
  • the steps of the corresponding method are not necessarily executed in the order shown and described in this specification.
  • the method may include more or fewer steps than described in this specification.
  • a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. description.
  • Block chains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
  • Participants of the blockchain are the blockchain nodes (or nodes for short).
  • the blockchain nodes can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks.
  • Each blockchain node forms the corresponding Blockchain network.
  • the most decentralized one is the public chain.
  • the public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks, and each participant can freely join and exit the network.
  • the private chain is the opposite.
  • the write permission of the relevant network is controlled by an organization or institution, and the data read permission is regulated by the organization or institution.
  • a private chain can be a weakly centralized system with strict restrictions and few participants.
  • This type of blockchain is more suitable for internal use by specific institutions.
  • the alliance chain is a block chain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain.
  • a smart contract on the blockchain is a contract that can be triggered and executed by a transaction on the blockchain system.
  • Smart contracts can be defined in the form of codes.
  • EVM Ethereum Virtual Machine
  • bytecode virtual machine code
  • the EVM of node 1 can execute the transaction and generate a corresponding contract instance.
  • the "0x6f8ae93" in the figure 1 represents the address of this contract, the data field of the transaction can be stored in bytecode, and the to field of the transaction is empty.
  • the contract is successfully created and can be called in the subsequent process.
  • a contract account corresponding to the smart contract appears on the blockchain, and has a specific address, and the contract code will be stored in the contract account.
  • the behavior of the smart contract is controlled by the contract code.
  • smart contracts make virtual accounts containing contract codes and storage (Storage) generated on the blockchain.
  • the EVM of a certain node can execute the transaction and generate a corresponding contract instance.
  • the from field of the transaction in Figure 2 is the address of the account of the transaction initiator (ie Bob), the "0x6f8ae93" in the to field represents the address of the called smart contract, and the value field in Ethereum is the value of Ether ,
  • the method and parameters of calling the smart contract are stored in the data field of the transaction. Smart contracts are executed independently on each node in the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain, so when the transaction is completed, the blockchain will be stored on the blockchain that cannot be tampered with. Lost transaction certificate.
  • smart contracts deployed on the blockchain can be in the form of bytecode.
  • the bytecode consists of a series of bytes, and each byte can identify an operation. Based on many considerations such as development efficiency and readability, developers can choose a high-level language to write smart contract code instead of directly writing bytecode.
  • the smart contract code written in a high-level language is compiled by a compiler to generate bytecode, and then the bytecode can be deployed on the blockchain.
  • the contract written in it is very similar to the class in the object-oriented programming language.
  • a variety of members can be declared in a contract, including contract status, functions, function modifiers, events, etc.
  • the contract state is the value permanently stored in the account storage of the smart contract and is used to save the state of the contract.
  • the storage state corresponding to the state of the "balance" contract is plaintext, and anyone can see its state, without privacy protection settings and capabilities. If users want to protect state privacy, the current solution of zero-knowledge proof and homomorphic encryption needs to be rewritten to rewrite this contract so that the state of the "balance" contract is encrypted and protected, and it needs to support all operations of balance in the encrypted domain. . Generally, this kind of encryption method is complex, and it is difficult to design a suitable algorithm to support it in the encryption domain. In some solutions that combine blockchain and TEE, in order to achieve privacy protection, part or all of the contract state of the smart contract is treated as data that needs privacy protection and stored in the database maintained by the blockchain node.
  • the physical carrier of the database may be a storage medium, such as a persistent storage medium.
  • TEE is a secure extension based on CPU hardware and a trusted execution environment completely isolated from the outside.
  • TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications.
  • ARM's Trust Zone technology is the first to realize the real commercial TEE technology.
  • the concept of TEE has also been rapidly developed and expanded. Compared with the originally proposed concept, TEE is a broader TEE. For example, server chip manufacturers Intel, AMD, etc. have successively introduced hardware-assisted TEE and enriched the concept and characteristics of TEE, which has been widely recognized in the industry.
  • TEEs including Intel SGX and AMD SEV, also provide memory encryption technology to limit trusted hardware to the inside of the CPU.
  • the data on the bus and memory are ciphertext to prevent malicious users from snooping.
  • Intel Software Protection Extensions (SGX) and other TEE technologies isolate code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for code execution.
  • the applications running in the TEE are protected by security and are almost impossible to be accessed by third parties.
  • SGX provides an enclave (also called an enclave), which is an encrypted trusted execution area in the memory, and the CPU protects data from being stolen.
  • enclave also called an enclave
  • a part of the area EPC Enclave Page Cache, enclave page cache or enclave page cache
  • the encryption engine MEE Memory Encryption Engine
  • Fig. 3 is a flow chart of a method for realizing dynamic encryption based on the modification sequence of the contract state according to an exemplary embodiment. As shown in Figure 3, this method is applied to blockchain nodes and can include the following steps:
  • Step 302 The blockchain node decrypts the received transaction in the trusted execution environment to determine the smart contract corresponding to the transaction.
  • the client can create a transaction, which is used to create or call a smart contract.
  • the client can encrypt the transaction with a 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 to determine the transaction The corresponding smart contract.
  • the data field of the transaction stores the code of the smart contract, so that after the blockchain node decrypts the transaction, the corresponding smart contract can be read from the data field of the transaction. contract.
  • the to field of the transaction contains the address of the called smart contract, so that after the blockchain node decrypts the transaction, the address of the smart contract can be read from the to field of the transaction, and Obtain the code of the corresponding smart contract based on this address.
  • a transaction When a transaction is used to call a smart contract, it can be a call of multiple nested structures. For example, the transaction directly calls smart contract 1, and the code of smart contract 1 calls smart contract 2, and the code in smart contract 2 points to the contract address of smart contract 3, so that the transaction actually calls the code of smart contract 3 indirectly . In this way, when the contract state defined in smart contract 1, smart contract 2 or smart contract 3 is modified, this manual can encrypt and store the modified contract state.
  • the client's encryption method for the transaction may be symmetric encryption, asymmetric encryption, or symmetric encryption combined with asymmetric encryption.
  • symmetric encryption the client encrypts the transaction with the encryption key, and the blockchain node decrypts the transaction with the same encryption key; correspondingly, the symmetric encryption algorithm used can be the DES algorithm, the 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc.
  • the client When using asymmetric encryption, the client encrypts the transaction with the public key, and the blockchain node decrypts the transaction with the private key; correspondingly, the asymmetric encryption algorithm used, such as RSA, Elgamal, knapsack algorithm, Rabin , DH, ECC (elliptic curve encryption algorithm), etc.
  • the client can use symmetric encryption algorithm to encrypt the transaction, that is, use the symmetric encryption algorithm to encrypt the transaction, and use the asymmetric encryption algorithm to encrypt the key used in the symmetric encryption algorithm, such as asymmetric encryption.
  • the public key of the encryption algorithm encrypts the key used in the symmetric encryption algorithm; in this way, after the blockchain node receives the encrypted transaction, it can first decrypt it with the private key of the asymmetric encryption algorithm to obtain the key of the symmetric encryption algorithm, and then Use the key of the symmetric encryption algorithm to decrypt the above transaction.
  • Step 304 The blockchain node executes the smart contract in a trusted execution environment, so that the contract state included in the smart contract is modified.
  • blockchain nodes can execute smart contracts in TEE to ensure that the state of the contract and its value will not leak.
  • the blockchain node can obtain the plaintext code of the smart contract corresponding to the transaction, and execute the obtained plaintext code in the TEE.
  • the blockchain node can use the newly added processor instructions in the CPU to allocate a part of the area EPC in the memory, and encrypt the above-mentioned plaintext code and store it in the EPC through the encryption engine MEE in the CPU.
  • the encrypted content in the EPC is decrypted into plaintext after entering the CPU, that is, the above-mentioned plaintext code, so that the CPU can perform operations on the plaintext code to complete the execution process.
  • the EVM can be loaded into the above-mentioned enclosure, so that the EVM can execute the above-mentioned plaintext code in the enclosure, thereby making full use of the powerful computing power of the CPU.
  • the key management server can calculate the hash value of the local EVM code and compare it with the hash value of the EVM code loaded in the blockchain node. The correct comparison result is a necessary condition for passing the remote certification.
  • the correct EVM can execute the plaintext code of the smart contract corresponding to the transaction in SGX, and ensure that all correct EVMs have the same result after executing the same piece of code.
  • Step 306 The blockchain node encrypts the contract state according to the public key and the influence factor in the trusted execution environment to write the encrypted contract state into the database, where the influence factor includes the contract state The modified sequence when the smart contract is executed.
  • storing the state of the contract in the blockchain from the perspective of the blockchain node, writes the state of the contract into a database, such as a local database.
  • the database is generally stored in a storage medium, more commonly a persistent storage medium.
  • the persistent storage medium may be a magnetic disk, a floppy disk, or a memory that can restore data after power-on so that it can be stored persistently.
  • the blockchain node can encrypt the state of the contract 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.
  • the randomness of the encrypted contract state can be increased through the differentiated impact factor.
  • the public key is the same, by using different impact factors, even if the contract states with the same value are encrypted, the resulting encrypted contract states will have different values. Therefore, compared to using public keys to encrypt all contract states, it can prevent criminals from mastering the law of value changes in the contract state after encryption, and prevent criminals from guessing the value of the contract state through trial and comparison. Higher security.
  • the impact factor may only include the order in which the contract status is modified when the corresponding smart contract is executed.
  • a number of contract states are defined in the smart contract. During the execution of the smart contract, some or all of the value of the contract state may be modified, and the number of modifications can be one or more times. The value modification of the contract state occurs sequentially, and the blockchain node can respectively determine the modification sequence corresponding to each contract state. For example, the contract state 1 is modified in the first, and the contract state 2 is modified in the fifth. Then the impact factor corresponding to contract state 1 can take the value 1, and the impact factor corresponding to contract state 2 can take the value 5.
  • Blockchain nodes can count the number of modifications that have occurred during the execution of the above smart contract through a counter.
  • the corresponding number of modifications is 1, indicating that the modification order of contract status 1 is 1, and contract status 2 When it is modified, the corresponding modification number is 5, indicating that the modified order of contract status 2 is 5.
  • the value of the contract state may be modified multiple times, so you can select the corresponding modification order when the contract state is modified at a certain time, such as the last time; still take the above counter statistical method as an example, when the contract state i is modified
  • the corresponding modification times are N1, N2, and N3
  • the modification order corresponding to the contract state i can be set to N3 (of course, it can also be N1 or N2, as long as it is distinguished from other contract states), However, N1 and N2 are discarded, so the modification order of each contract state does not necessarily change sequentially.
  • the value randomness of each encrypted contract state can be added to the contract state dimension to ensure the state of all encrypted contracts corresponding to the same transaction There will be no regular and followable value changes between them, and it can also ensure that the encrypted contract states will not produce regular and followable value changes between the contract states with different position offsets in different transactions.
  • a block chain network includes block B1 and block B2, the block height of block B1 is H1 and the block height of block B2 is H2.
  • block B1 contains transactions Tx1 and Tx2
  • block B2 contains transactions Tx3 and Tx4.
  • the position offsets of transactions Tx1 and Tx3 in blocks B1 and B2 are Offset1, and transaction Tx2.
  • the corresponding position offsets of Tx4 in blocks B1 and B2 are Offset2; at the same time, the contract states Balance1 and Balance2 are defined in transactions Tx1 and Tx3, and the contract states Balance3 and Balance4 are defined in transactions Tx2 and Tx4.
  • the impact factor only includes the order in which the contract state is modified when the smart contract is executed, as shown in Figure 4:
  • the contract states such as Balance1, Balance2, Balance3, and Balance4 involved in block B1
  • the contract states Balance1 and Balance2 are both It belongs to transaction Tx1, so Balance1 and Balance2 must respectively correspond to different modified orders.
  • Balance1 corresponds to the modified order U1
  • Balance2 corresponds to the modified order U2, so the public key Key128 (that is, the security version number 128) can be used.
  • the modified sequence U1 encrypts the contract state Balance1 to obtain the corresponding encrypted contract state S-Balance1-1, using the public key Key128 and the modified sequence U2 to encrypt the contract state Balance2, and obtain the corresponding encrypted contract state S-Balance2-1.
  • Balance3 and Balance4 must respectively correspond to different modified orders, for example, Balance3 corresponds to the modified order U1, and Balance4 corresponds to the modified order U2, so the public key can be used Key128 and the modified sequence U1 encrypt the contract state Balance3 to obtain the corresponding encrypted contract state S-Balance3-1, and use the public key Key128 and the modified sequence U2 to encrypt the contract state Balance4 to obtain the corresponding encrypted contract State S-Balance4-1.
  • Balance3 corresponds to the modified order U1
  • Balance4 corresponds to the modified order U2
  • the public key can be used Key128 and the modified sequence U1 encrypt the contract state Balance3 to obtain the corresponding encrypted contract state R-Balance3-1
  • the impact factor can further include other conditions.
  • other conditions can include “the block height of the block at the exchange” and "the transaction is located in the area.
  • One or more of them, such as the position offset in the block can be used to obtain the impact factor composed of multiple conditions, and the contract state can be encrypted in other dimensions.
  • the impact factor may be the block height of the block at the exchange and the order in which the contract state is modified when the smart contract is executed.
  • the block dimension and The encryption control of the state dimension makes the contract states generated by multiple transactions on different blocks have the same modification sequence, which will inevitably not cause regular and followable value changes in the contract state after encryption.
  • encryption control can be achieved through the condition "the order in which the contract states are modified when the smart contract is executed". This is because different contract states generated by the same transaction must have different modified orders ; For the contract states generated by multiple transactions in different blocks, even if these contract states have the same number of modifications in their respective transactions, they can be further encrypted by the condition "block height of the block at the exchange" Control, this is because transactions in different blocks must have different block heights.
  • Balance3 and Balance4 are from the same transaction Tx2, Balance3 and Balance4 must respectively correspond to different modified orders.
  • Balance3 corresponds to the modified order U1
  • Balance4 corresponds to the modified order U2
  • the block height H1 and the modified order U1 encrypt Balance3 to obtain the encrypted S-Balance3-3
  • the public key Key128, the block height H1 and the modified order U2 are used to encrypt Balance4 to obtain the encrypted S -Balance4-3.
  • Balance1 corresponds to modified
  • the sequence U1 and Balance2 correspond to the modified sequence U2. Therefore, Balance1 is encrypted by the public key Key128, the block height H2, and the modified sequence U1 to obtain the encrypted R-Balance1-3, and the public key Key128, zone
  • the block height H2 and the modified order U2 encrypt Balance2 to obtain the encrypted R-Balance2-3.
  • Balance3 and Balance4 are from the same transaction Tx4, Balance3 and Balance4 must respectively correspond to different modified orders.
  • Balance3 corresponds to the modified order U1
  • Balance4 corresponds to the modified order U2
  • the block height H2 and the modified order U1 encrypt Balance3 to obtain the encrypted R-Balance3-3
  • the public key Key128, the block height H2 and the modified order U2 are used to encrypt Balance4 to obtain the encrypted R -Balance4-3.
  • the impact factor may be the position offset of the transaction in the block, and the order in which the contract state is modified when the smart contract is executed.
  • the condition "contract state is executed in the smart contract The “modified order of the time” can realize the encryption control of the state dimension, and ensure that the different contract states generated by the same transaction will inevitably not cause the contract state after encryption to produce regular and followable value changes. Then when the impact factor includes the above two When the conditions are met, the encryption control of the transaction dimension and the state dimension can be realized, so that even if the contract states generated by different transactions on the same block have the same modification order, it will inevitably not make the contract state generation law after encryption follow. The value changes. Among them, for multiple contract states generated by the same transaction, encryption control can be achieved through the condition "the order in which the contract states are modified when the smart contract is executed".
  • Balance3 and Balance4 are from the same transaction Tx2, Balance3 and Balance4 must correspond to the same transaction offset and different modification orders, for example, the transaction offset of transaction Tx2 is Offset2, and Balance3 corresponds to the modification
  • the sequence U1 and Balance4 correspond to the modified sequence U2, so Balance3 is encrypted by the public key Key128, the transaction offset Offset2, and the modified sequence U1 to obtain the encrypted S-Balance3-3, and the public key Key128,
  • the transaction offset Offset2 and the modified order U2 encrypt Balance4 to obtain the encrypted S-Balance4-3.
  • Balance3 and Balance4 are from the same transaction Tx4, Balance3 and Balance4 must correspond to the same transaction offset and different modification orders, for example, the transaction offset of transaction Tx4 is Offset2, and Balance3 corresponds to the modification
  • the sequence U1 and Balance4 correspond to the modified sequence U2, so the balance3 is encrypted by the public key Key128, the transaction offset Offset2, and the modified sequence U1 to obtain the encrypted R-Balance3-3, and the public key Key128,
  • the transaction offset Offset2 and the modified order U2 encrypt Balance4 to obtain the encrypted R-Balance4-3.
  • the impact factor may be "the block height of the block where the exchange is located", “the position offset of the transaction in the block where the transaction is located” and “the order in which the contract state is modified when the smart contract is executed. ", it can realize the encryption control of the block dimension, transaction dimension and state dimension, so that the encrypted contract state generated by any two contract states will inevitably not produce regular and followable value changes, regardless of any two contracts. Whether the state comes from the same transaction or different transactions, and whether different transactions come from the same block or different blocks. Among them, for multiple contract states generated by the same transaction, encryption control can be achieved through the condition "the order in which the contract states are modified when the smart contract is executed".
  • Balance1 corresponds to the modified order U1
  • Balance2 corresponds to the modified order U2
  • Balance1 can be encrypted by public key Key128, block height H1, position offset Offset1, and modified sequence U1 to obtain encrypted S-Balance1-4, and through public key Key128, block The height H1, the position offset Offset1 and the modified order U2 encrypt the Balance2 to obtain the encrypted S-Balance2-4.
  • Balance3 and Balance4 come from transaction Tx2, Balance3 and Balance4 must respectively correspond to different modified orders.
  • Balance3 corresponds to the modified order U1
  • Balance4 corresponds to the modified order U2, and it is assumed that the position corresponding to the transaction Tx2 is biased.
  • Balance3 can be encrypted by the public key Key128, block height H1, position offset Offset2, and modified order U1 to obtain the encrypted S-Balance3-4, and the public key Key128,
  • the block height H1, the position offset Offset2, and the modified order U2 encrypt the Balance4 to obtain the encrypted S-Balance4-4.
  • Balance1 corresponds to the modified order U1 and Balance2 correspond to the modified order U2
  • the position offset corresponding to the transaction Tx3 is Offset1
  • Balance1 can be encrypted by the public key Key128, block height H2, position offset Offset1, and modified order U1 , Get encrypted R-Balance1-4, and encrypt Balance2 by public key Key128, block height H2, position offset Offset1, and modified order U2 to get encrypted R-Balance2-4.
  • Balance3 and Balance4 come from transaction Tx4, Balance3 and Balance4 must respectively correspond to different modified orders.
  • Balance3 corresponds to the modified order U1
  • Balance4 corresponds to the modified order U2.
  • the shift is Offset2
  • Balance3 can be encrypted by the public key Key128, block height H2, position offset Offset2, and modified order U1 to obtain the encrypted R-Balance3-4, and the public key Key128,
  • the block height H2, the position offset Offset2, and the modified order U2 encrypt the Balance4 to obtain the encrypted R-Balance4-4.
  • the blockchain node reads the received encrypted transaction into the trusted execution environment for decryption and executes the corresponding smart contract, and encrypts the modified contract state in the trusted execution environment, Then it is written into the database for storage to ensure that all outside the trusted execution environment are ciphertexts to ensure data security, and the trusted execution environment can be decrypted into plaintext for processing to make full use of the CPU's computing power.
  • the blockchain node can encrypt the above-mentioned contract state through the GCM (Galois/Counter Mode) algorithm; the letter G in GCM stands for GMAC (Galois message authentication code mode, Galois message verification code), The letter C stands for CTR (CounTeR counter mode).
  • the input of the GCM algorithm includes 3 parts: the data to be encrypted, the symmetric key and the initialization vector (IV, Initialization Vector).
  • the above contract status can be used as the data to be encrypted, and the above public key is required for the GCM algorithm.
  • the above-mentioned influence factor is used as the initialization vector required by the GCM algorithm to encrypt the contract state, and generate the corresponding encrypted contract state and the corresponding check code.
  • the check code can be used to verify the encryption The integrity of the post-contract state.
  • the blockchain node when the blockchain node stores the encrypted contract state, it can write the check code and the encrypted contract state into the database in association with each other. Then, in the subsequent decryption of the encrypted contract state, if the decryption fails, the encrypted contract state can be verified by the check code: when the verification is successful, it indicates that the data of the encrypted contract state is complete, which should be caused by other factors The resulting decryption failure, such as the input key or impact factor error; when the verification fails, it indicates that the data of the encrypted contract state is incomplete.
  • the blockchain node can generate a derived key according to the public key and the impact factor, for example, after the public key and the impact factor are spliced, a hash operation or other operations are performed to obtain the derived key; then, Blockchain nodes can encrypt the state of the contract according to the derived key to generate the encrypted contract state.
  • the public key is stored in a circle on the blockchain node. Since only the CPU can access the public key stored in the enclosure, the public key is sufficiently secure and cannot be obtained by criminals in theory, thereby ensuring the security of the encrypted contract state.
  • the public key can be distributed to the blockchain node by the key management server (KMS) after being remotely certified by the blockchain node; or, the public key can be negotiated between various nodes in the blockchain network; or , The public key can be obtained in other ways, and this manual does not restrict it.
  • KMS key management server
  • the key obtained based on the above method may not be a public key.
  • the key obtained through the aforementioned channel may be a security key, and the security key may realize version evolution, thereby evolving to obtain the aforementioned public key.
  • the above-mentioned public key can be a security key of a specified version; among the security keys of adjacent versions, the security key of the lower version is irreversibly calculated from the security key of the higher version, such as the highest version of the security key.
  • the security key is the root key, and other versions of the security key are irreversibly calculated directly or indirectly from the root key.
  • the security key of the lower version is obtained by the hash operation of the security key of the higher version and the preset information.
  • the security key of the lower version cannot be reversed to the security key of the higher version. It is helpful to realize the replacement of the public key through the version evolution of the security key, and avoid using the same public key for a long time.
  • the version evolution rule between the security keys can be as follows: the adjacent high version key and the adjacent low version key are hashed corresponding to the version number to obtain the adjacent low version key. For example, if you need to derive 256 versions of keys with version numbers ranging from 0 to 255, you can hash the root key with the version number 0xFF (corresponding to a decimal value of 255) to get the version number 255 Key key-255; by hashing the key key-255 and the version factor 0xFE (corresponding to the decimal value 254), the key key-254 with the version number of 254 is obtained; ...by changing the key -1 and the version factor 0x00 (corresponding to a decimal value of 0) are hashed to obtain a key-0 with a version number of 0.
  • the calculation between the high version key and the low version key is irreversible.
  • the key key-0 can be calculated from the key key-1 and the version factor 0x00, but the key cannot be passed.
  • -0 and version factor 0x00 deduces the key key-1. Therefore, a certain version of the security key can be selected and set as the public key used by the blockchain node to encrypt the contract state.
  • the blockchain node encrypts the contract state according to the public key and the influence factor to obtain the encrypted contract state. If the public key and the impact factor are fixed values, you only need to store the public key and the impact factor separately in the circle; however, if the public key or the impact factor has a dynamic value, that is, for different When the contract state is encrypted, different public keys or influence factors may be used. Then, when storing the encrypted contract state, the corresponding public key, influence factor, or information used to indicate its value should be stored in association. To facilitate subsequent decryption operations.
  • the impact factor can be associated with the encrypted contract status and written into the database.
  • the blockchain node stores the encrypted contract state in the form of key-value pairs.
  • the components of value can include: contract state after encryption, check value and impact factor.
  • the encrypted contract state can be obtained by encrypting according to the public key and the influence factor in the manner in the above embodiment.
  • the check value can also be obtained; of course, if the check value does not exist, the value may not contain the check value.
  • the value of the impact factor has many situations described above.
  • the impact factor includes block height, transaction offset, and modification order as an example, that is, the impact factor is determined by The block height, the position offset of the transaction in the block, and the order in which the contract status is modified when the smart contract is executed.
  • the blockchain node can obtain the influence factor required for decryption from the value of the key-value pair, thereby combining the public key to encrypt the state of the contract Decrypt.
  • the impact factor can be encrypted.
  • the blockchain node encrypts the impact factor in the TEE, so that the value contains the encrypted impact factor instead of the impact factor in plain text;
  • the impact factor in plain text cannot be directly obtained, which can further increase the decryption threshold of the encrypted contract state and improve security.
  • Blockchain nodes can use any key to encrypt the impact factor.
  • the aforementioned public key can also be used to encrypt the impact factor, in order to increase the diversity of keys and improve security, other keys different from the public key can be used to encrypt the impact factor.
  • the key for encrypting the impact factor can be another version, which is different from the public key; for example, the lowest version key with a version number of 0 can be used
  • the impact factor is encrypted, and the version number of the public key can be set to be necessarily greater than 0.
  • the public key may have version information, for example, the public key is a certain version of the security key mentioned above.
  • the blockchain node stores the key-value pair of the encrypted contract state, it can include the version information of the public key in the value, especially when the public key used by the blockchain node has a version update, the current application is
  • the version of the public key may be different from the historical public key used in the encryption of the previously stored encrypted contract state. Therefore, the version information contained in the value can help the blockchain node to accurately select the key to be used.
  • the value of the key-value pair may include an information field, and the information field may further include a version information subfield.
  • the version information subfield is used to record a public secret.
  • the version information of the key is a certain version of the security key mentioned above.
  • the blockchain node can encrypt the version information and add it to the value instead of recording the version information in plain text.
  • the key used to encrypt the version information can be a public key or other keys different from the public key. For example, similar to the aforementioned impact factor, the lowest version key with a version number of 0 can be used to pair the version information Encrypted.
  • this manual encrypts the state of the contract based on the public key and the influence factor.
  • the influence factor can be used to increase the randomness of the encrypted contract state to improve data security.
  • Fig. 10 is a schematic structural diagram of a device according to an exemplary embodiment.
  • the device includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile memory 1010.
  • the processor 1002 reads the corresponding computer program from the non-volatile memory 1010 to the memory 1008 and then runs it to form a device for dynamic encryption based on the modification sequence of the contract state at the logical level.
  • one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution body of the following processing flow is not limited to each
  • the logic unit can also be hardware or logic devices.
  • the device for realizing dynamic encryption based on the modification sequence of the contract state may include:
  • the decryption unit 1101 decrypts the received transaction in the trusted execution environment to determine the smart contract corresponding to the transaction;
  • the execution unit 1102 executes the smart contract in a trusted execution environment, so that the state of the contract included in the smart contract is modified;
  • the storage unit 1104 is used to write the encrypted contract state into the database.
  • the impact factor further includes at least one of the following: the block height of the block at the exchange, and the position offset of the transaction in the block.
  • the impact factor is written in a database in association with the encrypted contract state.
  • the impact factor is encrypted in the trusted execution environment, it is written in a database in association with the encrypted contract state.
  • the encryption unit 1103 is specifically configured to:
  • the public key is used as the symmetric key required by the GCM algorithm, and the influence factor is used as the initialization vector required by the GCM algorithm.
  • the contract state is encrypted by the GCM algorithm to generate the encrypted contract state and corresponding The check code; wherein the check code is written in the database in association with the encrypted contract state.
  • the encryption unit 1103 is specifically configured to:
  • the public key includes: a security key of a designated version; wherein, among the security keys of adjacent versions, the security key of the lower version is irreversibly calculated from the security key of the higher version.
  • the security key of the highest version is the root key, and the security keys of other versions are directly or indirectly calculated from the root key irreversibly.
  • the version information of the public key is written in a database in association with the encrypted contract state.
  • the version information of the public key is encrypted in a trusted execution environment, it is written in a database in association with the encrypted contract state.
  • a typical implementation device is a computer.
  • the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.
  • the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
  • processors CPU
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-permanent 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 computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, 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, CD-ROM, digital versatile disc (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 media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • first, second, third, etc. may be used in one or more embodiments of this specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as second information, and similarly, the second information may also be referred to as first information.
  • word “if” as used herein can be interpreted as "when” or “when” or "in response to determination”.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种基于合约状态的修改次序实现动态加密的方法及装置，该方法可以包括：区块链节点在可信执行环境中解密接收到的交易，以确定所述交易对应的智能合约（302）；所述区块链节点在可信执行环境中执行所述智能合约，使所述智能合约中包含的合约状态被修改（304）；所述区块链节点在可信执行环境中根据公共密钥和影响因子对所述合约状态进行加密，以将加密后合约状态写入数据库，其中所述影响因子包括所述合约状态在所述智能合约被执行时的被修改次序（306）。

Description

基于合约状态的修改次序实现动态加密的方法及装置 技术领域
本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于合约状态的修改次序实现动态加密的方法及装置。
背景技术
区块链技术构建在传输网络(例如点对点网络)之上。传输网络中的网络节点利用链式数据结构来验证与存储数据，并采用分布式节点共识算法来生成和更新数据。这些区块链网络中的节点有时需要增加。
目前企业级的区块链平台技术上最大的两个挑战就是隐私和性能，往往这两个挑战很难同时解决。大多解决方案都是通过损失性能换取隐私，或者不大考虑隐私去追求性能。常见的解决隐私问题的加密技术，如同态加密(Homomorphic encryption)和零知识证明(Zero-knowledge proof)等复杂度高，通用性差，而且还可能带来严重的性能损失。
在解决隐私方面，可信执行环境(Trusted Execution Environment,TEE)是另一种解决方式。TEE可以起到硬件中的黑箱作用，在TEE中执行的代码和数据都无法被操作系统层偷窥，只有通过代码中预先定义的接口才能对其进行操作。在效率方面，由于TEE的黑箱性质，在TEE中进行运算的是明文数据，而不是同态加密中的复杂密码学运算，计算过程没有效率损失，因此与TEE相结合可以在性能损失较小的前提下很大程度上提升区块链的安全性和隐私性。目前工业界十分关注TEE的方案，几乎所有主流的芯片和软件联盟都有自己的TEE解决方案，包括软件方面的TPM(Trusted Platform Module，可信赖平台模块)以及硬件方面的Intel SGX(Software Guard Extensions,软件保护扩展)、ARM Trustzone(信任区)和AMD PSP(Platform Security Processor，平台安全处理器)。
发明内容
有鉴于此，本说明书一个或多个实施例提供一种基于合约状态的修改次序实现动态加密的方法及装置。
为实现上述目的，本说明书一个或多个实施例提供技术方案如下：
根据本说明书一个或多个实施例的第一方面，提出了一种基于合约状态的修改次序实现动态加密的方法，包括：
区块链节点在可信执行环境中解密接收到的交易，以确定所述交易对应的智能合约；
所述区块链节点在可信执行环境中执行所述智能合约，使所述智能合约中包含的合约状态被修改；
所述区块链节点在可信执行环境中根据公共密钥和影响因子对所述合约状态进行加密，以将加密后合约状态写入数据库，其中所述影响因子包括所述合约状态在所述智能合约被执行时的被修改次序。
根据本说明书一个或多个实施例的第二方面，提出了一种基于合约状态的修改次序实现动态加密的装置，包括：
解密单元，在可信执行环境中解密接收到的交易，以确定所述交易对应的智能合约；
执行单元，在可信执行环境中执行所述智能合约，使所述智能合约中包含的合约状态被修改；
加密单元，在可信执行环境中根据公共密钥和影响因子对所述合约状态进行加密，其中所述影响因子包括所述合约状态在所述智能合约被执行时的被修改次序；
存储单元，用于将加密后合约状态写入数据库。
根据本说明书一个或多个实施例的第三方面，提出了一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器通过运行所述可执行指令以实现如第一方面所述的方法。
根据本说明书一个或多个实施例的第四方面，提出了一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如第一方面所述方法的步骤。
附图说明
图1是一示例性实施例提供的一种创建智能合约的示意图。
图2是一示例性实施例提供的一种调用智能合约的示意图。
图3是一示例性实施例提供的一种基于合约状态的修改次序实现动态加密的方法的流程图。
图4是一示例性实施例提供的一种影响因子仅包含合约状态的被修改次序时的加密示意图。
图5是一示例性实施例提供的一种影响因子同时包含合约状态的被修改次序与区块高度时的加密示意图。
图6是一示例性实施例提供的一种影响因子同时包含合约状态的被修改次序与交易偏移量时的加密示意图。
图7是一示例性实施例提供的一种影响因子同时包含区块高度、交易偏移量与合约状态的被修改次序时的加密示意图。
图8是一示例性实施例提供的一种合约状态的键值对的结构示意图。
图9是一示例性实施例提供的另一种合约状态的键值对的结构示意图。
图10是一示例性实施例提供的一种设备的结构示意图。
图11是一示例性实施例提供的一种基于合约状态的修改次序实现动态加密的装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(Private  Blockchain)和联盟链(Consortium Blockchain)。此外，还有多种类型的结合，比如私有链+联盟链、联盟链+公有链等不同组合形式。区块链的参与者即区块链节点(或简称节点)，区块链节点可以读取链上的数据记录、参与交易以及竞争新区块的记账权等，各个区块链节点组成了相应的区块链网络。在上述类型的区块链中，去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等，且各参与者可自由加入以及退出网络。私有链则相反，相关网络的写入权限由某个组织或者机构控制，数据读取权限受组织或机构的规定。简单来说，私有链可以为一个弱中心化系统，参与者具有严格限制且少。这种类型的区块链更适合于特定机构内部使用。联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；参与者通过授权加入网络并组成利益相关联盟，共同维护区块链运行。
不论是公有链、私有链还是联盟链，都可能提供智能合约的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。
以以太坊为例，支持用户在以太坊网络中创建并调用一些复杂的逻辑，这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM)，每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机，这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上，虚拟机直接运行的是虚拟机代码(虚拟机字节码，下简称“字节码”)。部署在区块链上的智能合约可以是字节码的形式。
例如图1所示，Bob将一个包含创建智能合约信息的交易发送到以太坊网络后，节点1的EVM可以执行这个交易并生成对应的合约实例。图中1中的“0x6f8ae93…”代表了这个合约的地址，交易的data字段保存的可以是字节码，交易的to字段为空。节点间通过共识机制达成一致后，这个合约成功创建，并且可以在后续过程中被调用。合约创建后，区块链上出现一个与该智能合约对应的合约账户，并拥有一个特定的地址，合约代码将保存在该合约账户中。智能合约的行为由合约代码控制。换句话说，智能合约使得区块链上产生包含合约代码和账户存储(Storage)的虚拟账户。
如图2所示，仍以以太坊为例，Bob将一个用于调用智能合约的交易发送到以太坊网络后，某一节点的EVM可以执行这个交易并生成对应的合约实例。图中2中交易的from字段是交易发起方(即Bob)的账户的地址，to字段中的“0x6f8ae93…”代表了 被调用的智能合约的地址，value字段在以太坊中是以太币的值，交易的data字段保存的调用智能合约的方法和参数。智能合约以规定的方式在区块链网络中每个节点独立的执行，所有执行记录和数据都保存在区块链上，所以当交易完成后，区块链上就保存了无法篡改、不会丢失的交易凭证。
如前所述，部署在区块链上的智能合约可以是字节码的形式。字节码由一连串的字节组成，每一字节可以标识一个操作。基于开发效率、可读性等多方面考虑，开发者可以不直接书写字节码，而是选择一门高级语言编写智能合约代码。高级语言编写的智能合约代码，经过编译器编译，生成字节码，进而该字节码可以部署到区块链上。以太坊支持的高级语言很多，如Solidity、Serpent、LLL语言等。
以Solidity语言为例，用其编写的合约与面向对象编程语言中的类(Class)很相似，在一个合约中可以声明多种成员，包括合约状态、函数、函数修改器、事件等。合约状态是永久存储在智能合约的账户存储中的值，用于保存合约的状态。
如下是以Solidity语言编写的一个简单的智能合约的代码示例：
Figure PCTCN2020092606-appb-000001
一般的，这个合约部署在区块链后，“balance”这个合约状态对应的存储状态是明文，任何人都可以看到其状态，无隐私保护的设置和能力。如果用户想将状态隐私保护起来，目前采用零知识证明、同态加密的解决方案，需要重新改写这个合约，使得“balance”这个合约状态加密保护起来，且需要支持balance在加密域上的所有运算。一般这种加密方式运算复杂，而且很难设计适合的算法在加密域上予以支持。而在有些区块链与TEE相结合的解决方案中，为了实现隐私保护，智能合约的部分或全部合约状态被当作 需要隐私保护的数据存储在区块链节点维护的数据库中。所述数据库，其物理载体可以是存储介质，例如持久性存储介质。
TEE是基于CPU硬件的安全扩展，且与外部完全隔离的可信执行环境。TEE最早是由Global Platform提出的概念，用于解决移动设备上资源的安全隔离，平行于操作系统为应用程序提供可信安全的执行环境。ARM的Trust Zone技术最早实现了真正商用的TEE技术。而伴随着互联网的高速发展，安全的需求越来越高，不仅限于移动设备，云端设备，数据中心都对TEE提出了更多的需求。TEE的概念也得到了高速的发展和扩充。现在所说的TEE相比与最初提出的概念已经是更加广义的TEE。例如，服务器芯片厂商Intel，AMD等都先后推出了硬件辅助的TEE并丰富了TEE的概念和特性，在工业界得到了广泛的认可。现在提起的TEE通常更多指这类硬件辅助的TEE技术。不同于移动端，云端访问需要远程访问，终端用户对硬件平台不可见，因此使用TEE的第一步就是要确认TEE的真实可信。因此现在的TEE技术都引入了远程证明机制，由硬件厂商(主要是CPU厂商)背书并通过数字签名技术确保用户对TEE状态可验证。
同时，仅仅是安全的资源隔离也可能无法满足安全需求，使得进一步的数据隐私保护也被提出。包括Intel SGX，AMD SEV在内的商用TEE也都提供了内存加密技术，将可信硬件限定在CPU内部，总线和内存的数据均是密文防止恶意用户进行窥探。例如，英特尔的软件保护扩展(SGX)等TEE技术隔离了代码执行、远程证明、安全配置、数据的安全存储以及用于执行代码的可信路径。在TEE中运行的应用程序受到安全保护，几乎不可能被第三方访问。
以Intel SGX技术为例，SGX提供了围圈(enclave，也称为飞地)，即内存中一个加密的可信执行区域，由CPU保护数据不被窃取。以某一区块链节点采用支持SGX的CPU为例，利用新增的处理器指令，在内存中可以分配一部分区域EPC(Enclave Page Cache，围圈页面缓存或飞地页面缓存)，通过CPU内的加密引擎MEE(Memory Encryption Engine)对其中的数据进行加密。EPC中加密的内容只有进入CPU后才会被解密成明文。因此，在SGX中，用户可以不信任操作系统、VMM(Virtual Machine Monitor，虚拟机监控器)、甚至BIOS(Basic Input Output System，基本输入输出系统)，只需要信任CPU便能确保隐私数据不会泄漏。因此，在CPU的加密保护下，可以在围圈内执行智能合约、生成合约状态，并对围圈内需要隐私保护的合约状态进行加密，然后将得到的密文合约状态传出后存储，从而既可以利用CPU强大的计算力，又不用担心数据泄漏。
图3是一示例性实施例提供的一种基于合约状态的修改次序实现动态加密的方法的流程图。如图3所示，该方法应用于区块链节点，可以包括以下步骤：
步骤302，区块链节点在可信执行环境中解密接收到的交易，以确定所述交易对应的智能合约。
在一实施例中，客户端可以创建交易，该交易用于创建或调用智能合约。客户端可以通过密钥对该交易进行加密，并将加密后的交易发送至区块链节点，使得区块链节点可以在可信执行环境中对该加密后的交易进行解密，从而确定该交易对应的智能合约。
如前所述，当上述交易用于创建智能合约时，该交易的data字段保存有智能合约的代码，使得区块链节点解密该交易后，可以从该交易的data字段中读取对应的智能合约。当上述交易用于调用智能合约时，该交易的to字段包含被调用的智能合约的地址，使得区块链节点解密该交易后，可以从该交易的to字段中读取智能合约的地址，并基于该地址获取相应智能合约的代码。
当交易用于调用智能合约时，可以是多重嵌套结构的调用。例如，交易直接调用智能合约1，而该智能合约1的代码调用了智能合约2，且智能合约2中的代码指向了智能合约3的合约地址，使得交易实际上间接调用了智能合约3的代码。这样，不论是智能合约1、智能合约2还是智能合约3中定义的合约状态被修改时，本说明书均可以对修改后的合约状态进行加密存储。
在一实施例中，客户端对交易的加密方式可以为对称加密、非对称加密，或者对称加密结合非对称加密。当采用对称加密时，客户端通过加密密钥对交易进行加密，而区块链节点通过相同的加密密钥对交易进行解密；相应的，所采用的对称加密算法可以是DES算法，3DES算法，TDEA算法，Blowfish算法，RC5算法，IDEA算法等。当采用非对称加密时，客户端通过公钥对交易进行加密、区块链节点通过私钥对交易进行解密；相应的，所采用的非对称加密算法，例如是RSA、Elgamal、背包算法、Rabin、D-H、ECC(椭圆曲线加密算法)等。当采用对称加密结合非对称加密时，客户端可以采用对称加密算法加密交易，即采用对称加密算法的密钥加密交易，并用非对称加密算法加密对称加密算法中采用的密钥，譬如采用非对称加密算法的公钥加密对称加密算法中采用的密钥；这样，区块链节点接收到加密的交易后，可以先采用非对称加密算法的私钥进行解密，得到对称加密算法的密钥，进而用对称加密算法的密钥解密上述交易。
步骤304，所述区块链节点在可信执行环境中执行所述智能合约，使所述智能合约 中包含的合约状态被修改。
如前所述，区块链节点可以通过在TEE中执行智能合约，以确保合约状态及其取值不会发生泄漏。例如，经过前述的解密过程后，区块链节点可以获得交易对应的智能合约的明文代码，并在TEE中执行所获得的明文代码。具体的，区块链节点可以利用CPU中新增的处理器指令，在内存中可以分配一部分区域EPC，通过CPU内的加密引擎MEE对上述明文代码进行加密存入所述EPC中。EPC中加密的内容进入CPU后被解密成明文，即上述的明文代码，使得CPU可以对该明文代码进行运算，完成执行过程。
在SGX技术中，可以将EVM加载进上述的围圈中，使得EVM可以在围圈内执行上述的明文代码，从而充分利用CPU的强大算力。在远程证明过程中，密钥管理服务器可以计算本地EVM代码的hash值，并与区块链节点中加载的EVM代码的hash值比对，比对结果正确作为通过远程证明的一个必要条件，从而完成对区块链节点SGX围圈加载的代码的度量。经过度量，正确的EVM可以在SGX中执行交易对应的智能合约的明文代码，并且确保所有正确EVM在执行同一段代码后的结果相同。
一般的，CPU执行智能合约的明文代码后，该明文代码中定义的部分或全部合约状态会发生变化，即部分或全部合约状态被修改，本说明书可以针对这些被修改的合约状态进行可靠加密后，存储至区块链节点维护的数据库中，以实现高级别的数据安全与隐私保护。
步骤306，所述区块链节点在可信执行环境中根据公共密钥和影响因子对所述合约状态进行加密，以将加密后合约状态写入数据库，其中所述影响因子包括所述合约状态在所述智能合约被执行时的被修改次序。
在一实施例中，将合约状态存入区块链，从区块链节点的角度，是将该合约状态写入数据库，例如本地的数据库。所述数据库，一般存储于存储介质之中，更多见的是持久性存储介质。所述持久性存储介质，可以是磁盘、软盘，也可以是通电后可恢复数据从而可以持久存储的内存之类。
在一实施例中，区块链节点可以根据公共密钥和影响因子对合约状态进行加密，使得到的加密后合约状态的取值同时受到公共密钥和影响因子的作用，在公共密钥相同的情况下，可以通过差异化的影响因子来增加加密后合约状态的随机性。换言之，当公共密钥相同的情况下，通过采用不同的影响因子，即便针对相同取值的合约状态进行加密，所得到的加密后合约状态也将具有不同取值。因此，相比于对所有合约状态均采用公共 密钥进行加密，可以避免不法分子掌握加密后合约状态的取值变化规律，防止不法分子通过尝试和比对而推测出合约状态的取值，具有更高的安全性。
在一实施例中，影响因子可以仅包含合约状态在相应的智能合约被执行时的被修改次序。智能合约中定义了若干合约状态，在智能合约被执行的过程中，部分或全部合约状态的取值可能发生修改，且修改次数可以为一次或多次。对合约状态的取值修改是依次发生的，而区块链节点可以分别确定各个合约状态对应的被修改次序，比如合约状态1在第1个被修改、合约状态2在第5个被修改，那么合约状态1对应的影响因子可以取值为1、合约状态2对应的影响因子可以取值为5。区块链节点可以通过计数器统计上述智能合约被执行的过程中已发生的修改次数，比如合约状态1被修改时对应的修改次数为1、表明合约状态1的被修改次序为1，合约状态2被修改时对应的修改次数为5、表明合约状态2的被修改次序为5。当然，合约状态的取值可能发生多次修改，那么可以选取该合约状态在某一次修改时对应的被修改次序，比如最后一次；仍以上述计数器的统计方式为例，当合约状态i被修改时对应的修改次数分别为N1、N2和N3时，可以将该合约状态i对应的被修改次序设定为N3(当然，也可以为N1或N2，只要与其他合约状态予以区分即可)，而N1和N2则被丢弃，所以各个合约状态的被修改次序并不一定是依次变化的，往往会由于部分合约状态被多次修改而产生取值的跳跃性变化，但这并不影响各个合约状态分别采用不同的影响因子进行加密。而对于不同交易所产生的合约状态，不论这些交易处于同一区块或不同区块，只要合约状态对应的被修改次序不同，均可以确保相同取值的合约状态对应于不同取值的加密后合约状态。可见，当影响因子为合约状态在相应的智能合约被执行时的被修改次序时，可以在合约状态维度上增加各个加密后合约状态的取值随机性，确保同一交易对应的所有加密后合约状态之间不会产生规律可循的取值变化，也可以确保不同交易中位置偏移量不同的合约状态分别对应的加密后合约状态之间不会产生规律可循的取值变化。
假定在某一区块链网络中包含区块B1和区块B2，区块B1的区块高度为H1、区块B2的区块高度为H2。为了便于理解，假定区块B1中包含交易Tx1、Tx2，区块B2中包含交易Tx3、Tx4，交易Tx1、Tx3在区块B1、B2中分别对应的位置偏移量均为Offset1，而交易Tx2、Tx4在区块B1、B2中分别对应的位置偏移量均为Offset2；同时，交易Tx1、Tx3中均定义了合约状态Balance1、Balance2，交易Tx2、Tx4中均定义了合约状态Balance3、Balance4。
当影响因子仅包含合约状态在智能合约被执行时的被修改次序时，如图4所示：对 于区块B1中涉及的Balance1、Balance2、Balance3和Balance4等合约状态，由于合约状态Balance1与Balance2均属于交易Tx1，因而Balance1与Balance2必然分别对应于不同的被修改次序，譬如Balance1对应于被修改次序U1、Balance2对应于被修改次序U2，因而可以采用公共密钥Key128(即版本号为128的安全密钥，可参见下文关于密钥版本的描述；或者，可以采用其他形式的公共密钥，此处仅用于举例)和被修改次序U1对合约状态Balance1进行加密、得到对应的加密后合约状态S-Balance1-1，而采用公共密钥Key128和被修改次序U2对合约状态Balance2进行加密、得到对应的加密后合约状态S-Balance2-1。同时，由于合约状态Balance3与Balance4均属于交易Tx2，因而Balance3与Balance4必然分别对应于不同的被修改次序，譬如Balance3对应于被修改次序U1、Balance4对应于被修改次序U2，因而可以采用公共密钥Key128和被修改次序U1对合约状态Balance3进行加密、得到对应的加密后合约状态S-Balance3-1，而采用公共密钥Key128和被修改次序U2对合约状态Balance4进行加密、得到对应的加密后合约状态S-Balance4-1。
类似地，对于区块B2而言，由于合约状态Balance1与Balance2均属于交易Tx3，因而Balance1与Balance2必然分别对应于不同的被修改次序，譬如Balance1对应于被修改次序U1、Balance2对应于被修改次序U2，因而可以采用公共密钥Key128和被修改次序U1对合约状态Balance1进行加密、得到对应的加密后合约状态R-Balance1-1，而采用公共密钥Key128和被修改次序U2对合约状态Balance2进行加密、得到对应的加密后合约状态R-Balance2-1。同时，由于合约状态Balance3与Balance4均属于交易Tx4，因而Balance3与Balance4必然分别对应于不同的被修改次序，譬如Balance3对应于被修改次序U1、Balance4对应于被修改次序U2，因而可以采用公共密钥Key128和被修改次序U1对合约状态Balance3进行加密、得到对应的加密后合约状态R-Balance3-1，而采用公共密钥Key128和被修改次序U2对合约状态Balance4进行加密、得到对应的加密后合约状态R-Balance4-1。
除了“合约状态在智能合约被执行时的被修改次序”之外，影响因子还可以进一步包含其他条件，比如其他条件可以包括“交易所处区块的区块高度”、“交易在所处区块中的位置偏移量”等其中的一个或多个，以得到由多个条件组合而成的影响因子，可以在其他维度上对合约状态实施加密操作。
在一实施例中，影响因子可以为交易所处区块的区块高度、合约状态在智能合约被执行时的被修改次序。结合上文分别对条件“交易所处区块的区块高度”、条件“合约 状态在智能合约被执行时的被修改次序”的描述，可知：条件“交易所处区块的区块高度”可以实现区块维度的加密控制、确保不同区块之间必然不会使得加密后合约状态产生规律可循的取值变化，条件“合约状态在智能合约被执行时的被修改次序”可以实现状态维度的加密控制、确保同一交易产生的不同合约状态之间必然不会使得加密后合约状态产生规律可循的取值变化，那么当影响因子同时包含上述两个条件时，可以实现区块维度和状态维度的加密控制，使得不同区块上的多个交易分别产生的合约状态之间即便具有相同的被修改次序，也必然不会使得加密后合约状态产生规律可循的取值变化。其中，对于同一交易产生的多个合约状态，可以通过条件“合约状态在智能合约被执行时的被修改次序”实现加密控制，这是由于同一交易产生的不同合约状态必然具有不同的被修改次序；而对于不同区块的多个交易分别产生的合约状态，即便这些合约状态在各自的交易中具有相同的被修改次数，也可以进一步通过条件“交易所处区块的区块高度”实现加密控制，这是由于不同区块的交易必然具有不同的区块高度。
仍以上述的区块B1、B2为例。如图5所示，当区块链节点同时考量区块高度与合约状态的被修改次序时，对于区块B1涉及的Balance1、Balance2、Balance3和Balance4等合约状态，由于Balance1与Balance2来自于同一交易Tx1，使得Balance1与Balance2必然分别对应于不同的被修改次序，譬如Balance1对应于被修改次序U1、Balance2对应于被修改次序U2，因而通过公共密钥Key128、区块高度H1与被修改次序U1对Balance1进行加密，得到加密后的S-Balance1-3，而通过公共密钥Key128、区块高度H1与被修改次序U2对Balance2进行加密，得到加密后的S-Balance2-3。同时，由于Balance3与Balance4来自于同一交易Tx2，使得Balance3与Balance4必然分别对应于不同的被修改次序，譬如Balance3对应于被修改次序U1、Balance4对应于被修改次序U2，因而通过公共密钥Key128、区块高度H1与被修改次序U1对Balance3进行加密，得到加密后的S-Balance3-3，而通过公共密钥Key128、区块高度H1与被修改次序U2对Balance4进行加密，得到加密后的S-Balance4-3。
类似地，对于区块B2涉及的Balance1、Balance2、Balance3和Balance4等合约状态，由于Balance1与Balance2来自于同一交易Tx3，使得Balance1与Balance2必然分别对应于不同的被修改次序，譬如Balance1对应于被修改次序U1、Balance2对应于被修改次序U2，因而通过公共密钥Key128、区块高度H2与被修改次序U1对Balance1进行加密，得到加密后的R-Balance1-3，而通过公共密钥Key128、区块高度H2与被修改次序U2对Balance2进行加密，得到加密后的R-Balance2-3。同时，由于Balance3与 Balance4来自于同一交易Tx4，使得Balance3与Balance4必然分别对应于不同的被修改次序，譬如Balance3对应于被修改次序U1、Balance4对应于被修改次序U2，因而通过公共密钥Key128、区块高度H2与被修改次序U1对Balance3进行加密，得到加密后的R-Balance3-3，而通过公共密钥Key128、区块高度H2与被修改次序U2对Balance4进行加密，得到加密后的R-Balance4-3。
在一实施例中，影响因子可以为交易在所处区块中的位置偏移量、合约状态在智能合约被执行时的被修改次序。结合上文分别对条件“交易在所处区块中的位置偏移量”、条件“合约状态在智能合约被执行时的被修改次序”的描述，可知：条件“交易在所处区块中的位置偏移量”可以实现交易维度的加密控制、确保同一区块内的不同交易之间必然不会使得加密后合约状态产生规律可循的取值变化，条件“合约状态在智能合约被执行时的被修改次序”可以实现状态维度的加密控制、确保同一交易产生的不同合约状态之间必然不会使得加密后合约状态产生规律可循的取值变化，那么当影响因子同时包含上述两个条件时，可以实现交易维度和状态维度的加密控制，使得同一区块上的不同交易分别产生的合约状态之间即便具有相同的被修改次序，也必然不会使得加密后合约状态产生规律可循的取值变化。其中，对于同一交易产生的多个合约状态，可以通过条件“合约状态在智能合约被执行时的被修改次序”实现加密控制，这是由于同一交易产生的不同合约状态必然具有不同的被修改次序；而对于同一区块的不同交易分别产生的合约状态，即便这些合约状态在各自的交易中具有相同的被修改次数，也可以进一步通过条件“交易在所处区块中的位置偏移量”实现加密控制，这是由于同一区块的不同交易必然具有不同的位置偏移量。
仍以上述的区块B1、B2为例。如图6所示，当区块链节点同时考量交易偏移量与合约状态的被修改次序时，对于区块B1涉及的Balance1、Balance2、Balance3和Balance4等合约状态，由于Balance1与Balance2来自于同一交易Tx1，使得Balance1与Balance2必然分别对应于相同的交易偏移量、不同的被修改次序，譬如交易Tx1的交易偏移量为Offset1，以及Balance1对应于被修改次序U1、Balance2对应于被修改次序U2，因而通过公共密钥Key128、交易偏移量Offset1与被修改次序U1对Balance1进行加密，得到加密后的S-Balance1-3，而通过公共密钥Key128、交易偏移量Offset1与被修改次序U2对Balance2进行加密，得到加密后的S-Balance2-3。同时，由于Balance3与Balance4来自于同一交易Tx2，使得Balance3与Balance4必然分别对应于相同的交易偏移量、不同的被修改次序，譬如交易Tx2的交易偏移量为Offset2，以及Balance3对应于被修 改次序U1、Balance4对应于被修改次序U2，因而通过公共密钥Key128、交易偏移量Offset2与被修改次序U1对Balance3进行加密，得到加密后的S-Balance3-3，而通过公共密钥Key128、交易偏移量Offset2与被修改次序U2对Balance4进行加密，得到加密后的S-Balance4-3。
类似地，对于区块B2而言，由于Balance1与Balance2来自于同一交易Tx3，使得Balance1与Balance2必然分别对应于相同的交易偏移量、不同的被修改次序，譬如交易Tx3的交易偏移量为Offset1，以及Balance1对应于被修改次序U1、Balance2对应于被修改次序U2，因而通过公共密钥Key128、交易偏移量Offset1与被修改次序U1对Balance1进行加密，得到加密后的R-Balance1-3，而通过公共密钥Key128、交易偏移量Offset1与被修改次序U2对Balance2进行加密，得到加密后的R-Balance2-3。同时，由于Balance3与Balance4来自于同一交易Tx4，使得Balance3与Balance4必然分别对应于相同的交易偏移量、不同的被修改次序，譬如交易Tx4的交易偏移量为Offset2，以及Balance3对应于被修改次序U1、Balance4对应于被修改次序U2，因而通过公共密钥Key128、交易偏移量Offset2与被修改次序U1对Balance3进行加密，得到加密后的R-Balance3-3，而通过公共密钥Key128、交易偏移量Offset2与被修改次序U2对Balance4进行加密，得到加密后的R-Balance4-3。
在一实施例中，影响因子可以为“交易所处区块的区块高度”、“交易在所处区块中的位置偏移量”和“合约状态在智能合约被执行时的被修改次序”，可以实现区块维度、交易维度和状态维度的加密控制，使得任意两个合约状态所产生的加密后合约状态都必然不会产生规律可循的取值变化，而不论该任意两个合约状态是否来自同一交易或不同交易、不同交易是否来自同一区块或不同区块。其中，对于同一交易产生的多个合约状态，可以通过条件“合约状态在智能合约被执行时的被修改次序”实现加密控制，这是由于同一交易产生的不同合约状态必然具有不同的被修改次序；而对于同一区块的不同交易分别产生的合约状态，即便这些合约状态在各自的交易中具有相同的被修改次数，也可以进一步通过条件“交易在所处区块中的位置偏移量”实现加密控制，这是由于同一区块的不同交易必然具有不同的位置偏移量；而对于不同区块的多个交易分别产生的合约状态，即便这些合约状态在各自的交易中具有相同的被修改次数，也可以进一步通过条件“交易所处区块的区块高度”实现加密控制，这是由于不同区块的交易必然具有不同的区块高度。
仍以上述的区块B1、B2为例。如图7所示，当区块链节点同时考量区块高度、交 易对应的位置偏移量与合约状态的被修改次序时，对于区块B1涉及的Balance1、Balance2、Balance3和Balance4等合约状态，由于Balance1与Balance2来自于交易Tx1，使得Balance1与Balance2必然分别对应于不同的被修改次序，譬如Balance1对应于被修改次序U1、Balance2对应于被修改次序U2，同时假定交易Tx1对应的位置偏移量为Offset1，那么可以通过公共密钥Key128、区块高度H1、位置偏移量Offset1和被修改次序U1对Balance1进行加密，得到加密后的S-Balance1-4，而通过公共密钥Key128、区块高度H1、位置偏移量Offset1和被修改次序U2对Balance2进行加密，得到加密后的S-Balance2-4。同时，由于Balance3与Balance4来自于交易Tx2，使得Balance3与Balance4必然分别对应于不同的被修改次序，譬如Balance3对应于被修改次序U1、Balance4对应于被修改次序U2，同时假定交易Tx2对应的位置偏移量为Offset2，那么可以通过公共密钥Key128、区块高度H1、位置偏移量Offset2和被修改次序U1对Balance3进行加密，得到加密后的S-Balance3-4，而通过公共密钥Key128、区块高度H1、位置偏移量Offset2和被修改次序U2对Balance4进行加密，得到加密后的S-Balance4-4。
类似地，对于区块B2涉及的Balance1、Balance2、Balance3和Balance4等合约状态，由于Balance1与Balance2来自于交易Tx3，使得Balance1与Balance2必然分别对应于不同的被修改次序，譬如Balance1对应于被修改次序U1、Balance2对应于被修改次序U2，同时假定交易Tx3对应的位置偏移量为Offset1，那么可以通过公共密钥Key128、区块高度H2、位置偏移量Offset1和被修改次序U1对Balance1进行加密，得到加密后的R-Balance1-4，而通过公共密钥Key128、区块高度H2、位置偏移量Offset1和被修改次序U2对Balance2进行加密，得到加密后的R-Balance2-4。同时，由于Balance3与Balance4来自于交易Tx4，使得Balance3与Balance4必然分别对应于不同的被修改次序，譬如Balance3对应于被修改次序U1、Balance4对应于被修改次序U2，同时假定交易Tx4对应的位置偏移量为Offset2，那么可以通过公共密钥Key128、区块高度H2、位置偏移量Offset2和被修改次序U1对Balance3进行加密，得到加密后的R-Balance3-4，而通过公共密钥Key128、区块高度H2、位置偏移量Offset2和被修改次序U2对Balance4进行加密，得到加密后的R-Balance4-4。
在一实施例中，区块链节点将收到的加密后的交易读入可信执行环境中进行解密并执行对应的智能合约，并在可信执行环境中对产生修改的合约状态进行加密，然后写入数据库中进行存储，确保可信执行环境之外均为密文、以保证数据安全性，而可信执行 环境之内可以解密为明文进行处理、以充分利用CPU的算力。
区块链节点在可信执行环境中根据公共密钥和影响因子对合约状态进行加密时，存在多种可选用的加密手段，可以借鉴相关技术中的加密解决方案。下面对两种可能采用的加密解决方案予以介绍。
在一实施例中，区块链节点可以通过GCM(Galois/Counter Mode)算法对上述的合约状态进行加密；GCM中的字母G代表GMAC(Galois message authentication code mode,伽罗瓦消息验证码)、字母C代表CTR(CounTeR计数器模式)。GCM算法的输入包括3部分：待加密数据、对称密钥和初始化向量(IV，Initialization Vector)，本说明书中可以将上述的合约状态作为待加密数据、将上述的公共密钥作为GCM算法所需的对称密钥、将上述的影响因子作为GCM算法所需的初始化向量，从而对合约状态进行加密，生成相应的加密后合约状态和相应的校验码，该校验码可以用于校验加密后合约状态的完整性。
因此，区块链节点在存储加密后合约状态时，可以将校验码与加密后合约状态相关联地写入数据库。那么，在后续针对加密后合约状态进行解密时，如果解密失败可以通过校验码对加密后合约状态进行校验：当校验成功时，表明加密后合约状态的数据完整，应当是由其他因素导致的解密失败，比如输入的密钥或影响因子错误；当校验失败时，表明加密后合约状态的数据不完整。
在另一实施例中，区块链节点可以根据公共密钥和影响因子生成衍生密钥，比如将公共密钥与影响因子拼接后进行哈希运算或其他运算，以得到衍生密钥；然后，区块链节点可以根据衍生密钥对合约状态进行加密，生成加密后合约状态。
在一实施例中，公共密钥存储于区块链节点上的围圈中。由于仅CPU能够访问围圈内存储的公共密钥，使得该公共密钥足够安全，理论上无法被不法分子获得，从而确保了加密后合约状态的安全性。
公共密钥可以由区块链节点通过远程证明后，由密钥管理服务器(KMS)分配至该区块链节点；或者，公共密钥可由区块链网络中的各个节点之间协商得到；或者，可以通过其他方式得到公共密钥，本说明书并不对此进行限制。
基于上述途径获得的密钥可以并非公共密钥。例如，上述渠道获得的密钥可以为安全密钥，而该安全密钥可以实现版本演化，从而演化得到上述的公共密钥。换言之，上述的公共密钥可以为指定版本的安全密钥；其中，在相邻版本的安全密钥中，低版本的 安全密钥由高版本的安全密钥不可逆地计算得到，譬如最高版本的安全密钥为根密钥(root key)，而其他版本的安全密钥直接或间接由根密钥不可逆地计算得到。比如低版本的安全密钥由高版本的安全密钥与预设信息进行哈希运算得到，那么由于哈希运算的特性，使得低版本的安全密钥无法逆推出高版本的安全密钥，这样有助于通过安全密钥的版本演进实现对公共密钥的更换，而避免长时间使用相同的公共密钥。并且，在更换公共密钥时，可以确保更换后密钥的版本总是高于更换前密钥的版本，以确保：一方面，即便先前使用的密钥发生泄漏，也可以更换为高版本的密钥而及时止损；另一方面，只要拥有高版本的密钥，即可演化得到低版本的密钥，对先前所使用的密钥进行兼容，从而对先前加密的合约状态进行解密。
安全密钥之间的版本演化规则可以为：相邻的高版本密钥与相邻的低版本密钥对应的版本号进行哈希运算，得到相邻的低版本密钥。例如，如果需要衍生出版本号分别为0～255的256个版本的密钥，可以将根密钥与版本号0xFF(对应的十进制取值为255)进行哈希计算，得到版本号为255的密钥key-255；通过将密钥key-255与版本因子0xFE(对应的十进制取值为254)进行哈希计算，得到版本号为254的密钥key-254；……通过将密钥key-1与版本因子0x00(对应的十进制取值为0)进行哈希计算，得到版本号为0的密钥key-0。由于哈希算法的特性，使得高版本密钥与低版本密钥之间的计算不可逆，比如可以由密钥key-1与版本因子0x00计算得到密钥key-0，但是不能够通过密钥key-0与版本因子0x00反推出密钥key-1。因此，可以选定某一版本的安全密钥，并将其设置为区块链节点所使用的公共密钥，以用于对合约状态进行加密处理。
如前所述，区块链节点根据公共密钥和影响因子对合约状态进行加密，以得到加密后合约状态。如果公共密钥和影响因子为固定取值，那么只需要将公共密钥、影响因子分别单独存储于围圈中即可；但是，如果公共密钥或影响因子具有动态取值，即对于不同的合约状态进行加密时，可能采用不同的公共密钥或影响因子，那么应当在存储加密后合约状态时，对相应采用的公共密钥、影响因子或者用于表明其取值的信息进行关联存储，以便于后续实施解密操作。
假定影响因子的取值存在动态变化，可以将影响因子与加密后合约状态相关联地写入数据库。例如图8所示，区块链节点以键值对(key-value)的形式对加密后合约状态进行存储。Key的取值可以参考相关技术中的方式确定，比如key＝hash(RLP(value))，即key的取值为RLP(Recursive Length Prefix，递归长度前缀)编码后的value的哈希值。而value的组成部分可以包括：加密后合约状态、校验值和影响因子。加密后合约 状态可由上述实施例中的方式，根据公共密钥和影响因子进行加密得到。而当采用诸如GCM算法或其他加密算法实施加密时，还可以得到校验值；当然，如果不存在校验值，那么value中可以不包含校验值。而影响因子的取值存在上文所述的多种情况，图8中以影响因子同时包含区块高度、交易偏移量和修改次序为例，即影响因子由“交易所处区块的区块高度”、“交易在所处区块中的位置偏移量”和“合约状态在智能合约被执行时的被修改次序”构成。
基于图8所示的实施例，区块链节点在读取这一键值对后，可以从该键值对的value中获得解密所需的影响因子，从而结合公共密钥对加密后合约状态进行解密。而在一些场景中，可以对影响因子进行加密，譬如在存储阶段由区块链节点在TEE中对影响因子进行加密，使得value中包含加密后的影响因子，而非明文形式的影响因子；相应地，在读取如图8所示的键值对后，将无法直接得到明文形式的影响因子，可以进一步提升对加密后合约状态的解密门槛，提升安全性。
区块链节点可以采用任意密钥对影响因子进行加密。虽然也可以采用上述的公共密钥对影响因子进行加密，但是为了增加密钥的多样性、提升安全性，可以采用区别于公共密钥的其他密钥对影响因子进行加密。例如，当公共密钥为前述某一版本的密钥时，对影响因子进行加密的密钥可以为另一版本，从而区别于公共密钥；譬如，可以采用版本号为0的最低版本密钥对影响因子进行加密，而公共密钥的版本号可被设定为必然大于0。
公共密钥可能存在版本信息，譬如公共密钥为上述某一版本的安全密钥。区块链节点在针对加密后合约状态的键值对进行存储时，可以在value中包含公共密钥的版本信息，尤其是区块链节点使用的公共密钥存在版本更新的情况下，当前采用的公共密钥的版本可能区别于先前存储的加密后合约状态在加密时采用的历史公共密钥，因而value中所含的版本信息可以帮助区块链节点准确选取所需采用的密钥。例如图9所示，在图8所示实施例的基础上，在键值对的value中可以包含信息字段，该信息字段可以进一步包含版本信息子字段，该版本信息子字段用于记录公共密钥的版本信息。
其中，区块链节点可以对版本信息进行加密后，添加至value中，而非采用明文形式记录版本信息。用于对版本信息加密的密钥可以为公共密钥，或者区别于公共密钥的其他密钥，比如与前述的影响因子相类似的，可以采用版本号为0的最低版本密钥对版本信息进行加密。
综上所述，本说明书根据公共密钥和影响因子对合约状态进行加密，相比于单纯采用公共密钥进行加密，可以通过影响因子增加加密后合约状态的随机性，以提升数据安全性。
图10是一示例性实施例提供的一种设备的示意结构图。请参考图10，在硬件层面，该设备包括处理器1002、内部总线1004、网络接口1006、内存1008以及非易失性存储器1010，当然还可能包括其他业务所需要的硬件。处理器1002从非易失性存储器1010中读取对应的计算机程序到内存1008中然后运行，在逻辑层面上形成基于合约状态的修改次序实现动态加密的装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图11，在软件实施方式中，该基于合约状态的修改次序实现动态加密的装置可以包括：
解密单元1101，在可信执行环境中解密接收到的交易，以确定所述交易对应的智能合约；
执行单元1102，在可信执行环境中执行所述智能合约，使所述智能合约中包含的合约状态被修改；
加密单元1103，在可信执行环境中根据公共密钥和影响因子对所述合约状态进行加密，其中所述影响因子包括所述合约状态在所述智能合约被执行时的被修改次序；
存储单元1104，用于将加密后合约状态写入数据库。
可选的，所述影响因子还包括以下至少之一：所述交易所处区块的区块高度、所述交易在所处区块中的位置偏移量。
可选的，所述影响因子被与所述加密后合约状态相关联地写入数据库。
可选的，所述影响因子在可信执行环境中被加密后，与所述加密后合约状态相关联地写入数据库。
可选的，加密单元1103具体用于：
将所述公共密钥作为GCM算法所需的对称密钥、将所述影响因子作为GCM算法所需的初始化向量，通过GCM算法对所述合约状态进行加密，生成所述加密后合约状态和相应的校验码；其中，所述校验码被与所述加密后合约状态相关联地写入数据库。
可选的，加密单元1103具体用于：
根据所述公共密钥和所述影响因子生成衍生密钥；
根据所述衍生密钥对所述合约状态进行加密，生成所述加密后合约状态。
可选的，所述公共密钥包括：指定版本的安全密钥；其中，在相邻版本的安全密钥中，低版本的安全密钥由高版本的安全密钥不可逆地计算得到。
可选的，最高版本的安全密钥为根密钥，其他版本的安全密钥直接或间接由所述根密钥不可逆地计算得到。
可选的，所述公共密钥的版本信息被与所述加密后合约状态相关联地写入数据库。
可选的，所述公共密钥的版本信息在可信执行环境中被加密后，与所述加密后合约状态相关联地写入数据库。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其 他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (13)

  1. 一种基于合约状态的修改次序实现动态加密的方法，包括：
    区块链节点在可信执行环境中解密接收到的交易，以确定所述交易对应的智能合约；
    所述区块链节点在可信执行环境中执行所述智能合约，使所述智能合约中包含的合约状态被修改；
    所述区块链节点在可信执行环境中根据公共密钥和影响因子对所述合约状态进行加密，以将加密后合约状态写入数据库，其中所述影响因子包括所述合约状态在所述智能合约被执行时的被修改次序。
  2. 根据权利要求1所述的方法，所述影响因子还包括以下至少之一：
    所述交易在所处区块中的位置偏移量、所述交易所处区块的区块高度。
  3. 根据权利要求1或2所述的方法，所述影响因子被与所述加密后合约状态相关联地写入数据库。
  4. 根据权利要求3所述的方法，所述影响因子在可信执行环境中被加密后，与所述加密后合约状态相关联地写入数据库。
  5. 根据权利要求1所述的方法，所述区块链节点在可信执行环境中根据公共密钥和影响因子对所述合约状态进行加密，包括：
    所述区块链节点将所述公共密钥作为GCM算法所需的对称密钥、将所述影响因子作为GCM算法所需的初始化向量，通过GCM算法对所述合约状态进行加密，生成所述加密后合约状态和相应的校验码；其中，所述校验码被与所述加密后合约状态相关联地写入数据库。
  6. 根据权利要求1所述的方法，所述区块链节点在可信执行环境中根据公共密钥和影响因子对所述合约状态进行加密，包括：
    所述区块链节点根据所述公共密钥和所述影响因子生成衍生密钥；
    所述区块链节点根据所述衍生密钥对所述合约状态进行加密，生成所述加密后合约状态。
  7. 根据权利要求1所述的方法，所述公共密钥包括：指定版本的安全密钥；其中，在相邻版本的安全密钥中，低版本的安全密钥由高版本的安全密钥不可逆地计算得到。
  8. 根据权利要求7所述的方法，最高版本的安全密钥为根密钥，其他版本的安全密钥直接或间接由所述根密钥不可逆地计算得到。
  9. 根据权利要求7所述的方法，所述公共密钥的版本信息被与所述加密后合约状态相关联地写入数据库。
  10. 根据权利要求9所述的方法，所述公共密钥的版本信息在可信执行环境中被加密后，与所述加密后合约状态相关联地写入数据库。
  11. 一种基于合约状态的修改次序实现动态加密的装置，包括：
    解密单元，在可信执行环境中解密接收到的交易，以确定所述交易对应的智能合约；
    执行单元，在可信执行环境中执行所述智能合约，使所述智能合约中包含的合约状态被修改；
    加密单元，在可信执行环境中根据公共密钥和影响因子对所述合约状态进行加密，其中所述影响因子包括所述合约状态在所述智能合约被执行时的被修改次序；
    存储单元，用于将加密后合约状态写入数据库。
  12. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求1-10中任一项所述的方法。
  13. 一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如权利要求1-10中任一项所述方法的步骤。
PCT/CN2020/092606 2019-05-31 2020-05-27 基于合约状态的修改次序实现动态加密的方法及装置 Ceased WO2020238958A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910473002.5A CN110263547B (zh) 2019-05-31 2019-05-31 基于合约状态的修改次序实现动态加密的方法及装置
CN201910473002.5 2019-05-31

Publications (1)

Publication Number Publication Date
WO2020238958A1 true WO2020238958A1 (zh) 2020-12-03

Family

ID=67916437

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/092606 Ceased WO2020238958A1 (zh) 2019-05-31 2020-05-27 基于合约状态的修改次序实现动态加密的方法及装置

Country Status (2)

Country Link
CN (1) CN110263547B (zh)
WO (1) WO2020238958A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110263547B (zh) * 2019-05-31 2021-07-20 创新先进技术有限公司 基于合约状态的修改次序实现动态加密的方法及装置
WO2020238878A1 (zh) * 2019-05-31 2020-12-03 创新先进技术有限公司 动态加密方法及装置
CN110266467B (zh) * 2019-05-31 2021-04-27 创新先进技术有限公司 基于区块高度实现动态加密的方法及装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107342858A (zh) * 2017-07-05 2017-11-10 武汉凤链科技有限公司 一种基于可信环境的智能合约保护方法和系统
CN107425982A (zh) * 2017-07-07 2017-12-01 众安信息技术服务有限公司 一种实现智能合约数据加密的方法和区块链
US9866375B2 (en) * 2010-05-27 2018-01-09 Bladelogic, Inc. Multi-level key management
CN108229962A (zh) * 2018-01-04 2018-06-29 众安信息技术服务有限公司 基于区块链的权限管理方法及系统
CN108632045A (zh) * 2018-05-10 2018-10-09 阿里巴巴集团控股有限公司 一种区块链数据处理方法、装置、处理设备及系统
US20180309567A1 (en) * 2017-04-25 2018-10-25 Microsoft Technology Licensing, Llc Confidentiality in a consortium blockchain network
CN110263547A (zh) * 2019-05-31 2019-09-20 阿里巴巴集团控股有限公司 基于合约状态的修改次序实现动态加密的方法及装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010056398A1 (en) * 2000-04-14 2001-12-27 E-Vantage International, Inc. Method and system for delivering foreign exchange risk management advisory solutions to a designated market
JP2007041223A (ja) * 2005-08-02 2007-02-15 Mitsubishi Electric Corp データ配信装置及びデータ通信システム
CN101330379B (zh) * 2007-06-22 2011-02-09 华为技术有限公司 一种密钥下发方法和设备
CN104463001A (zh) * 2014-12-19 2015-03-25 比特卡国际有限公司 一种独立生成和保存加密数字货币私钥的方法及承载加密数字货币私钥的装置
CN107809642B (zh) * 2015-02-16 2020-06-16 华为技术有限公司 用于视频图像编码和解码的方法、编码设备和解码设备
US20160321751A1 (en) * 2015-04-28 2016-11-03 Domus Tower, Inc. Real-time settlement of securities trades over append-only ledgers
CN106548330B (zh) * 2016-10-27 2018-03-16 上海亿账通区块链科技有限公司 基于区块链的交易验证方法及系统
CN107294709A (zh) * 2017-06-27 2017-10-24 阿里巴巴集团控股有限公司 一种区块链数据处理方法、装置及系统
CN107911216B (zh) * 2017-10-26 2020-07-14 矩阵元技术（深圳）有限公司 一种区块链交易隐私保护方法及系统
WO2019127531A1 (zh) * 2017-12-29 2019-07-04 深圳前海达闼云端智能科技有限公司 基于区块链的数据处理方法、装置、存储介质及电子设备
CN108377189B (zh) * 2018-05-09 2021-01-26 深圳壹账通智能科技有限公司 区块链上用户通信加密方法、装置、终端设备及存储介质
CN109191124B (zh) * 2018-08-16 2021-02-26 北京京东尚科信息技术有限公司 区块链网络、部署方法及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9866375B2 (en) * 2010-05-27 2018-01-09 Bladelogic, Inc. Multi-level key management
US20180309567A1 (en) * 2017-04-25 2018-10-25 Microsoft Technology Licensing, Llc Confidentiality in a consortium blockchain network
CN107342858A (zh) * 2017-07-05 2017-11-10 武汉凤链科技有限公司 一种基于可信环境的智能合约保护方法和系统
CN107425982A (zh) * 2017-07-07 2017-12-01 众安信息技术服务有限公司 一种实现智能合约数据加密的方法和区块链
CN108229962A (zh) * 2018-01-04 2018-06-29 众安信息技术服务有限公司 基于区块链的权限管理方法及系统
CN108632045A (zh) * 2018-05-10 2018-10-09 阿里巴巴集团控股有限公司 一种区块链数据处理方法、装置、处理设备及系统
CN110263547A (zh) * 2019-05-31 2019-09-20 阿里巴巴集团控股有限公司 基于合约状态的修改次序实现动态加密的方法及装置

Also Published As

Publication number Publication date
CN110263547B (zh) 2021-07-20
CN110263547A (zh) 2019-09-20

Similar Documents

Publication Publication Date Title
CN110245506B (zh) 基于区块链的智能合约管理方法及装置、电子设备
CN110266467B (zh) 基于区块高度实现动态加密的方法及装置
CN110032884B (zh) 区块链中实现隐私保护的方法及节点、存储介质
CN110245944B (zh) 基于用户类型的收据存储方法和节点
WO2021088548A1 (zh) 基于智能合约的隐私数据查询方法及装置
CN110245942B (zh) 结合用户类型和判断条件的收据存储方法和节点
CN110263544B (zh) 结合交易类型和判断条件的收据存储方法和节点
CN110245947B (zh) 结合交易与用户类型的条件限制的收据存储方法和节点
CN110264195A (zh) 结合代码标注与交易、用户类型的收据存储方法和节点
CN110264193B (zh) 结合用户类型与交易类型的收据存储方法和节点
WO2020233642A1 (zh) 有条件的结合代码标注与类型维度的收据存储方法和节点
CN110276610B (zh) 基于交易偏移量实现动态加密的方法及装置
WO2020233631A1 (zh) 基于交易类型的收据存储方法和节点
WO2020233613A1 (zh) 结合代码标注与交易类型的有条件的收据存储方法和节点
WO2021088533A1 (zh) 隐私数据的共享方法及装置
CN110266644A (zh) 结合代码标注与交易类型的收据存储方法和节点
WO2020233640A1 (zh) 结合代码标注与判断条件的收据存储方法和节点
WO2020233628A1 (zh) 结合事件函数类型和判断条件的收据存储方法和节点
WO2020233635A1 (zh) 结合多类型维度的条件限制的收据存储方法和节点
WO2020233614A1 (zh) 结合代码标注与事件类型的有条件的收据存储方法和节点
WO2020233624A1 (zh) 结合交易类型和事件函数类型的收据存储方法和节点
WO2020233633A1 (zh) 基于判断条件的收据存储方法和节点
WO2020233634A1 (zh) 结合交易与事件类型的条件限制的收据存储方法和节点
WO2020238958A1 (zh) 基于合约状态的修改次序实现动态加密的方法及装置
WO2020238878A1 (zh) 动态加密方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20812568

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20812568

Country of ref document: EP

Kind code of ref document: A1