WO2020238255A1 - 基于区块链的智能合约管理方法及装置、电子设备 - Google Patents

基于区块链的智能合约管理方法及装置、电子设备 Download PDF

Info

Publication number
WO2020238255A1
WO2020238255A1 PCT/CN2020/072055 CN2020072055W WO2020238255A1 WO 2020238255 A1 WO2020238255 A1 WO 2020238255A1 CN 2020072055 W CN2020072055 W CN 2020072055W WO 2020238255 A1 WO2020238255 A1 WO 2020238255A1
Authority
WO
WIPO (PCT)
Prior art keywords
smart contract
contract
code
target smart
target
Prior art date
Application number
PCT/CN2020/072055
Other languages
English (en)
French (fr)
Inventor
魏长征
闫莺
Original Assignee
创新先进技术有限公司
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 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Priority to US16/777,110 priority Critical patent/US10839107B2/en
Priority to US17/098,124 priority patent/US11048825B2/en
Publication of WO2020238255A1 publication Critical patent/WO2020238255A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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 in particular to a method and device for smart contract management based on blockchain, and electronic equipment.
  • Blockchain technology also known as distributed ledger technology, is an emerging technology in which several computing devices participate in "bookkeeping" and jointly maintain a complete distributed database. Because the blockchain technology has the characteristics of decentralization, openness and transparency, each computing device can participate in database records, and the rapid data synchronization between computing devices, the blockchain technology has been widely used in many fields. To apply.
  • This specification proposes a blockchain-based smart contract management method, which is applied to node devices in the blockchain; wherein, the node device is equipped with a trusted execution environment; the method includes:
  • the encrypted contract code of the target smart contract stored in the distributed ledger of the blockchain is obtained, and the encrypted target smart contract is The contract code is sent to the trusted execution environment;
  • the target smart contract is not a managed smart contract, extract the decryption key corresponding to the contract code of the target smart contract stored in the trusted execution environment, and pair the decryption key based on the extracted decryption key Decrypt the contract code of the target smart contract;
  • the decrypted contract code of the target smart contract is executed in the trusted execution environment, and the execution result is encrypted and sent to the distributed ledger of the blockchain for storage.
  • a decryption key corresponding to the encrypted smart contract contract code stored in the distributed ledger of the blockchain is stored in the trusted execution environment;
  • the decryption key corresponding to the managed smart contract stored in the trusted execution environment is set to prohibit extraction; or, the decryption key stored in the trusted execution environment does not include the decryption key corresponding to the managed smart contract Decryption key.
  • the method further includes:
  • a prompt message indicating that the target smart contract call failed is returned to the client.
  • the method further includes:
  • the acquisition of smart contract management rules includes:
  • the smart contract management rules are obtained from the distributed ledger of the management blockchain; wherein the smart contract management rules are generated by the management party calling the smart contract deployed on the management blockchain.
  • the smart contract management rules include: a smart contract blacklist composed of contract addresses of managed smart contracts;
  • the determining whether the target smart contract is a managed smart contract based on the smart contract management rules includes:
  • the contract address of the target smart contract matches any contract address in the smart contract blacklist, it is determined that the target smart contract is a managed smart contract; otherwise, it is determined that the target smart contract is not a managed smart contract.
  • the encryption method used for the contract code of the target smart contract includes any one of the following encryption methods: symmetric encryption, asymmetric encryption, symmetric encryption combined with asymmetric encryption;
  • the encryption method adopted for the execution result of the contract code of the target smart contract includes: a symmetric encryption method; or, an asymmetric encryption method.
  • the symmetric encryption combined with asymmetric encryption includes a digital envelope encryption method.
  • the trusted execution environment includes Intel SGX.
  • This specification also proposes a block chain-based smart contract management device, which is applied to node equipment in the block chain; wherein, the node equipment is equipped with a trusted execution environment; the device includes:
  • the obtaining module in response to the call transaction for the target smart contract initiated by the client, obtains the encrypted contract code of the target smart contract stored in the distributed ledger of the blockchain, and then combines the encrypted target Sending the contract code of the smart contract to the trusted execution environment;
  • a determining module acquiring smart contract management rules, and determining whether the target smart contract is a managed smart contract based on the smart contract management rules in a trusted execution environment;
  • the decryption module if the target smart contract is not a managed smart contract, extract the decryption key corresponding to the contract code of the target smart contract stored in the trusted execution environment, and based on the extracted decryption key Decrypt the contract code of the target smart contract;
  • the execution module executes the decrypted contract code of the target smart contract in the trusted execution environment, and sends the encrypted execution result to the distributed ledger of the blockchain for storage.
  • a decryption key corresponding to the encrypted smart contract contract code stored in the distributed ledger of the blockchain is stored in the trusted execution environment;
  • the decryption key corresponding to the managed smart contract stored in the trusted execution environment is set to prohibit extraction; or, the decryption key stored in the trusted execution environment does not include the decryption key corresponding to the managed smart contract Decryption key.
  • the device further includes:
  • the return module if the target smart contract is a managed smart contract, return a prompt message that the target smart contract call failed to the client.
  • the device further includes:
  • the receiving module receives the creation transaction for the target smart contract initiated by the client; wherein the creation transaction includes the encrypted contract code of the target smart contract;
  • the creation module in response to the creation transaction, executes the smart contract creation code in the trusted execution environment, creates a contract account corresponding to the target smart contract in the blockchain, and encrypts the encrypted
  • the contract code of the target smart contract is sent to the distributed ledger of the blockchain for storage.
  • the acquisition module :
  • the smart contract management rules are obtained from the distributed ledger of the management blockchain; wherein, the smart contract management rules are generated by the management party calling the smart contract deployed on the management blockchain.
  • the smart contract management rules include: a smart contract blacklist composed of contract addresses of managed smart contracts;
  • the determining module :
  • the contract address of the target smart contract matches any contract address in the smart contract blacklist, it is determined that the target smart contract is a managed smart contract; otherwise, it is determined that the target smart contract is not a managed smart contract.
  • the encryption method used for the contract code of the target smart contract includes any one of the following encryption methods: symmetric encryption, asymmetric encryption, symmetric encryption combined with asymmetric encryption;
  • the encryption method adopted for the execution result of the contract code of the target smart contract includes: a symmetric encryption method; or, an asymmetric encryption method.
  • the symmetric encryption combined with asymmetric encryption includes a digital envelope encryption method.
  • the trusted execution environment includes Intel SGX.
  • This specification also proposes a blockchain-based smart contract management method, which is applied to the node equipment in the blockchain; wherein the node equipment is equipped with a trusted execution environment; and the trusted execution environment stores the The decryption key corresponding to the contract code of the encrypted smart contract stored in the distributed ledger of the blockchain; the method includes:
  • the encrypted contract code of the target smart contract stored in the distributed ledger of the blockchain is obtained, and the encrypted target smart contract is The contract code is sent to the trusted execution environment;
  • the execution result of the contract code of the target smart contract is encrypted and sent to the distributed ledger of the blockchain for storage.
  • the method further includes:
  • target smart contract is a managed smart contract, delete the execution result of the contract code of the target smart contract, and return to the client a prompt message that the target smart contract call failed; or,
  • the target smart contract is a managed smart contract, store the execution result of the contract code of the target smart contract in the trusted execution environment, and set the execution result stored in the trusted execution environment to Prohibition of extraction; and, returning to the client a prompt message indicating that the target smart contract call failed.
  • This specification also proposes a block chain-based smart contract management device, which is applied to the node equipment in the block chain; wherein the node equipment is equipped with a trusted execution environment; and the trusted execution environment stores the The decryption key corresponding to the contract code of the encrypted smart contract stored in the distributed ledger of the blockchain; the device includes:
  • the second obtaining module in response to the call transaction for the target smart contract initiated by the client, obtains the encrypted contract code of the target smart contract stored in the distributed ledger of the blockchain, and combines the encrypted contract code of the target smart contract. Sending the contract code of the target smart contract to the trusted execution environment;
  • the first decryption module extracts the decryption key corresponding to the contract code of the target smart contract stored in the trusted execution environment, and decrypts the contract code of the target smart contract based on the extracted decryption key ;
  • the second execution module executes the decrypted contract code of the target smart contract in the trusted execution environment
  • the second determining module obtains smart contract management rules, and determines whether the target smart contract is a managed smart contract based on the smart contract management rules in a trusted execution environment; if the target smart contract is not a managed smart contract, Then, the execution result of the contract code of the target smart contract is encrypted and sent to the distributed ledger of the blockchain for storage.
  • the device further includes:
  • the second return module if the target smart contract is a managed smart contract, delete the execution result of the contract code of the target smart contract, and return to the client a prompt message that the target smart contract call failed; or,
  • the target smart contract is a managed smart contract, store the execution result of the contract code of the target smart contract in the trusted execution environment, and set the execution result stored in the trusted execution environment to Prohibition of extraction; and, returning to the client a prompt message indicating that the target smart contract call failed.
  • the node device in the blockchain executes the encrypted smart contract contract code in the trusted execution environment on board, only the unmanaged smart contract contract code can be decrypted and executed; therefore, On the basis of sufficient privacy protection for smart contracts, some managed smart contracts can be shielded by technical means to realize the supervision of smart contracts.
  • 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 schematic diagram of creating a smart contract and invoking a smart contract provided by an exemplary embodiment
  • Fig. 4 is a flowchart of a method for managing smart contracts based on a blockchain provided by an exemplary embodiment
  • Fig. 5 is a flowchart of another smart contract management method based on blockchain according to an exemplary embodiment
  • Fig. 6 is a schematic structural diagram of an electronic device provided by an exemplary embodiment
  • Fig. 7 is a block diagram of a smart contract management device based on blockchain provided by an exemplary embodiment
  • Fig. 8 is a block diagram of a block chain-based smart contract management device provided by an exemplary embodiment.
  • the steps of the corresponding method may not be executed in the order shown and described in this specification.
  • the method includes 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.
  • 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 the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each participant (ie, node) can freely join and exit the network, and perform related operations.
  • the private chain is the opposite.
  • the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization.
  • the private chain can be a weakly centralized system with strict restrictions and few participating nodes. 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.
  • Smart contract Whether it is a public chain, a private chain or a consortium chain, it may provide the function of smart contract (Smart contract).
  • 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
  • a contract account corresponding to the smart contract appears on the blockchain and has a specific address.
  • the contract code and account storage will be stored in the contract account.
  • the behavior of the smart contract is controlled by the contract code, and the storage of the smart contract's account saves the state of the contract.
  • smart contracts enable virtual accounts containing contract codes and account storage to be generated on the blockchain.
  • the data field of the transaction that contains the creation of the smart contract can store the bytecode of the smart contract.
  • the bytecode consists of a series of bytes, and each byte can identify an operation.
  • developers can choose a high-level language to write smart contract code instead of directly writing bytecode.
  • high-level languages such as Solidity, Serpent, and LLL languages.
  • smart contract code written in a high-level language it can be compiled by a compiler to generate bytecode that 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 state variables, functions, function modifiers, and events.
  • State variables are values permanently stored in the account storage of the smart contract and are used to save the state of the contract.
  • the storage state corresponding to the state variable in the smart contract's contract code is plaintext, and anyone can see its state without privacy protection settings and capabilities.
  • the EVM of node 1 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 that initiated the call of the smart contract.
  • the "0x692a70d2" in the to field represents the address of the smart contract being called.
  • the value field is the value of the ether in Ethereum.
  • the method and parameters for calling the smart contract stored in the data field.
  • the value of balance may change. Later, a certain client can view the current value of balance through a certain blockchain node (for example, node 6 in Figure 2).
  • Smart contracts can be 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 such a transaction is completed, the blockchain is stored and cannot be tampered with. , A transaction certificate that will not be lost.
  • FIG. 3 The schematic diagram of creating and calling smart contracts is shown in Figure 3. To create a smart contract in Ethereum, it needs to go through the process of writing a smart contract, turning it into bytecode, and deploying it to the blockchain. Invoking a smart contract in Ethereum is to initiate a transaction that points to a smart contract address. The smart contract code runs in a distributed manner in the virtual machine of each node in the Ethereum network.
  • TEE Trusted Execution Environment
  • TEE can play the role of a black box in the hardware. Neither the code executed in the TEE nor the data operating system layer can be peeped. Only the pre-defined interface in the code can operate on it.
  • TEE plaintext data is calculated in TEE instead of complex cryptographic operations in homomorphic encryption. There is no loss of efficiency 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. Almost all mainstream chip and software alliances have their own 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).
  • TPM Trust Platform Module
  • Intel SGX Software Guard Extensions
  • ARM Trustzone trust zone
  • AMD PSP Platinum Security Processor
  • the smart contract as a whole is regarded as data that needs privacy protection to be called and executed in the TEE, and all contract states are encrypted and stored on the blockchain. .
  • the security level of privacy protection can be improved to a certain extent, it also causes difficulties in data management.
  • the supervising party of the smart contract may have the need to supervise the execution process of the contract code of the smart contract and the corresponding execution results; but in the traditional blockchain and In the TEE-combined solution, the security level of smart contract execution is high, and the execution process and execution result of the smart contract are in an invisible privacy state; therefore, this makes it difficult to supervise the content of the smart contract.
  • this manual the purpose of this manual is to propose a technical solution to further realize the effective management of smart contracts on the basis of sufficient privacy protection for smart contracts in an application scenario that combines blockchain and TEE.
  • the contract code of the smart contract deployed on the blockchain can be encrypted and stored persistently in the distributed ledger of the blockchain.
  • the decryption key corresponding to the contract code of the encrypted smart contract stored in the distributed ledger of the blockchain can be stored in advance.
  • the stored decryption keys in the upper trusted execution environment may only contain the decryption keys corresponding to those supervised smart contracts; that is, , In a trusted execution environment, only the decryption keys corresponding to unsupervised smart contracts can be stored, but not those of supervised smart contracts.
  • all the decryption keys corresponding to smart contracts can be stored by default; and for the decryption keys corresponding to the supervised smart contracts stored in the trusted execution environment, you can It is set to prohibit extraction; that is, the decryption key corresponding to the contract code that is not the managed smart contract can be extracted normally.
  • the node device When the node device receives the call transaction for the target smart contract initiated by the client, it can obtain the encrypted contract code of the target smart contract stored in the distributed ledger of the blockchain, and the obtained encrypted contract code The contract code of the target smart contract is sent to the trusted execution environment carried by the node device.
  • the node device can obtain the smart contract management rules, and in the loaded trusted execution environment, based on the obtained smart contract Management rules to determine whether the target smart contract is a managed smart contract;
  • the node device can extract the decryption key corresponding to the contract code of the target smart contract stored in the trusted execution environment, and the contract code of the target smart contract Decrypt.
  • the node device After completing the decryption and obtaining the plaintext contract code of the target smart contract, the node device can execute the decrypted plaintext contract code in the trusted execution environment, and then encrypt the execution result and send it to the distributed ledger of the blockchain for storage .
  • the node device in the blockchain executes the encrypted smart contract contract code in the trusted execution environment on board, only the unmanaged smart contract contract code can be decrypted and executed; therefore, On the basis of sufficient privacy protection for smart contracts, some managed smart contracts can be shielded by technical means to realize the supervision of smart contracts.
  • FIG. 4 is a flowchart of a method for managing a smart contract based on a blockchain according to an exemplary embodiment. As shown in Fig. 4, the method is applied to a node device in a blockchain; wherein, the node device is equipped with a trusted execution environment; the method includes the following steps:
  • Step 402 in response to the call transaction for the target smart contract initiated by the client, obtain the encrypted contract code of the target smart contract stored in the distributed ledger of the blockchain, and combine the encrypted target Sending the contract code of the smart contract to the trusted execution environment;
  • Step 404 Obtain smart contract management rules, and determine whether the target smart contract is a managed smart contract based on the smart contract management rules in a trusted execution environment;
  • Step 406 If the target smart contract is not a managed smart contract, extract the decryption key corresponding to the contract code of the target smart contract stored in the trusted execution environment, and based on the extracted decryption key Decrypt the contract code of the target smart contract;
  • Step 408 Execute the decrypted contract code of the target smart contract in the trusted execution environment, and send the encrypted execution result to the distributed ledger of the blockchain for storage.
  • the management of smart contracts can specifically refer to the management party of the smart contract, who manages the execution process of the smart contract's contract code and the corresponding execution results.
  • the management of smart contracts specifically refers to the content supervision of the execution process of the contract code of the smart contract and the corresponding execution results; and in this management scenario, the above-mentioned management party Correspondingly, it can also refer to the supervisor of the smart contract.
  • the aforementioned managed smart contract is a supervised smart contract; the aforementioned smart contract management rules are smart contract supervision rules.
  • the user after the user has written the contract code of the smart contract, he can construct a creation transaction for creating the smart contract on the client based on the contract code of the smart contract, and send the transaction to the client End-to-end blockchain node equipment.
  • the client can further compile the contract code through the compiler to generate bytecode that can be deployed on the blockchain, and then based on the compiled code
  • the bytecode of the smart contract is used to "package" to generate a creation transaction for creating the smart contract, and send the transaction to the blockchain node device that interfaces with the client.
  • the client can use a key to encrypt the written contract code.
  • the client can directly encrypt the whole construction of the aforementioned creation transaction; or, it can only encrypt the bytecode itself of the smart contract carried in the aforementioned creation transaction; the specific encryption method Those skilled in the art can choose flexibly when implementing the technical solutions disclosed in this specification.
  • the encryption method used when encrypting the contract code can be symmetric encryption or asymmetric encryption.
  • the encryption algorithm used in symmetric encryption can be DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, etc.
  • the algorithm used for asymmetric encryption can be RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), etc.
  • the encryption method used when encrypting the contract code can also be a combination of symmetric encryption and asymmetric encryption.
  • This encryption method is generally referred to as the Digital Envelope (Digital Envelope) encryption method.
  • the client uses a symmetric encryption algorithm to encrypt the contract code, that is, uses the private key of the symmetric encryption algorithm to encrypt the contract code, and then uses the public key of the asymmetric encryption algorithm to encrypt the private key used in the above symmetric encryption algorithm. That is, first use the key of the symmetric encryption algorithm to encrypt the contract code; then use the key of the asymmetric encryption algorithm to further encrypt the key used to encrypt the contract code.
  • the node device in the blockchain After receiving the above creation transaction sent by the client, the node device in the blockchain can check whether the transaction is valid, the format is correct, whether the signature of the transaction is legal, etc., and after all checks and verifications are passed, The creation transaction can be executed in a trusted execution environment to complete the creation of a smart contract.
  • the function type of the transaction can be confirmed first;
  • the transaction function type is usually determined based on the transaction content carried in the transaction; for example, if the to field in the transaction is an empty account, and the data field of the transaction carries the bytecode that needs to be deployed ,
  • the transaction can be determined as a transaction for creating a smart contract; if the to field in the transaction points to the contract address of an existing smart contract, and the data field of the transaction carries the parameters required to call the smart contract, it can be determined This transaction is used to call the smart contract.
  • the smart contract creation code can be further executed in the above trusted and secure environment, a contract account corresponding to the smart contract is created on the blockchain, and the creation transaction
  • the contract code of the encrypted smart contract in is sent to the distributed ledger of the blockchain for storage.
  • the created contract account usually includes attribute fields such as Balance, Nonce, codehash, and storaghash.
  • the node device After the node device completes the creation of the contract account, it will fill in the hash value of the contract code in the creation transaction.
  • the above codehash field packs the above creation transaction into a block and sends it to other node devices in the blockchain, and stores it in the distributed ledger of the blockchain. That is, the original content of the smart contract's contract code is still stored in the original creation transaction and stored in the block of the blockchain. In the contract account corresponding to the smart contract, only the hash pointer of the smart contract's contract code needs to be maintained .
  • the consensus algorithms supported in the blockchain are usually divided into consensus algorithms where node devices need to compete for the accounting rights of each round of accounting cycles, and pre-election of accounting nodes for each round of accounting cycles (not required Competing for accounting rights) consensus algorithm.
  • the former is represented by consensus algorithms such as Proof of Work (POW), Proof of Stake (POS), and Delegated Proof of Stake (DPOS); the latter is represented by Practical Byzantine fault tolerance (Practical Byzantine Fault Tolerance, PBFT) and other consensus algorithms are representative.
  • POW Proof of Work
  • POS Proof of Stake
  • DPOS Delegated Proof of Stake
  • PBFT Practical Byzantine fault tolerance
  • PBFT Practical Byzantine Fault Tolerance
  • the node device can send the creation transaction to the accounting node if it is not the accounting node of this round.
  • the creation transaction can be executed during or before the process of packaging the creation transaction together with other transactions and generating a new block.
  • the accounting node packs the created transaction and other transactions to generate a new block, it can send the generated new block or the block header of the new block to other nodes for consensus.
  • this round of accounting nodes can package the created transaction and generate a new block, and send the generated new block or block header Go to other node devices for consensus verification. If other node devices receive a new block or block header, and there is no problem after verification, the new block can be appended to the end of the original blockchain to complete the accounting process and reach a consensus. When a consensus is reached, the deployment of the smart contract on the blockchain is completed. Among them, in the process of verifying the new block or block header sent by the accounting node, other node devices may also execute the aforementioned creation transaction contained in the block.
  • the specific process of executing the above transaction creation in the trusted execution environment can be specifically completed by the virtual machine deployed in the trusted execution environment; that is, the virtual machine deployed in the trusted execution environment It is the execution entity of the above-mentioned creation transaction; for example, in Ethereum, the node device usually executes the transaction through the equipped Ethereum Virtual Machine (EVM).
  • EVM Ethereum Virtual Machine
  • the user can construct a call transaction on the client to call the target smart contract, and send the transaction to the area docked with the client Block chain node equipment to initiate the call execution of the target smart contract that has been deployed.
  • the node device in the blockchain can still check whether the transaction is valid, the format is correct, whether the signature of the transaction is legal, etc., and after all checks and verifications are passed , Execute the call transaction in a trusted execution environment.
  • the function type of the transaction can be confirmed first; when it is confirmed that the transaction is a call transaction for invoking smart contracts, the distributed blockchain can be further obtained
  • the encrypted contract code of the target smart contract is stored in the ledger, and the obtained encrypted contract code of the target smart contract is sent to the trusted execution environment for execution in the trusted execution environment.
  • the decryption key corresponding to the encrypted smart contract contract code stored in the distributed ledger of the blockchain can be stored and maintained.
  • the above trusted execution environment can be equipped with a key generation algorithm.
  • the node device can be in the trusted execution environment. Call the carried key generation algorithm to create a root key for the contract account.
  • the root key includes a public-private key pair; the public key is used to encrypt the contract code and is held by the user; the private key is stored in a trusted execution environment and is used to encrypt the contract code Decryption; if symmetric encryption is used, the root key only includes a key used to encrypt and decrypt the contract code.
  • the decryption keys corresponding to the contract codes of all smart contracts included in the distributed ledger of the blockchain can be stored by default ;
  • the decryption key corresponding to the supervised smart contract stored in the trusted execution environment can be set to a state where extraction is prohibited.
  • the implementation means of how to set the decryption key corresponding to the contract code of the supervised smart contract stored and maintained in the above trusted execution environment to an unextractable state is not specifically limited in this specification;
  • a program code for controlling the extraction authority of the decryption key can be deployed in a trusted execution environment, and the program code can be specifically made up of hardware ( For example, as a trusted execution environment chip) to independently execute calls; and then the trusted execution environment can control the extraction authority of the stored and maintained decryption key by executing the above program code to ensure the trusted execution environment
  • the decryption key corresponding to the contract code of the supervised smart contract stored and maintained in the smart contract is in a state that cannot be extracted and exported.
  • other implementation manners may also be used for implementation, which will not be listed one by one in this specification.
  • the hardware that carries the trusted execution environment can further obtain the smart contract supervision rules, and in the trusted execution environment Determine whether the target smart contract is a supervised smart contract based on the obtained smart contract supervision rules.
  • the above-mentioned smart contract supervision rules may specifically be supervision rules that are independently generated by the supervisor and can be updated and modified in real time by the supervisor.
  • an independent regulatory blockchain can be deployed, and the smart contract for generating smart contract regulatory rules can be deployed on the regulatory blockchain.
  • Contract and declare in the smart contract the generation logic used to generate smart contract supervision rules.
  • the supervisor can construct a call transaction based on actual supervisory requirements to call the smart contract, dynamically generate smart contract supervision rules, and store the generated smart contract supervision rules in the distributed ledger of the supervision blockchain.
  • the dynamically generated smart contract supervision rules refer to the smart contract supervision rules actually used when the smart contract is supervised, and the newly generated smart contract supervision rules always prevail. If the regulatory requirements of the regulator change, the regulator can call the smart contract to regenerate new smart contract regulatory rules based on the new regulatory requirements.
  • the regulator can flexibly update the smart contract regulatory rules dynamically based on actual regulatory requirements.
  • the above smart contract supervision rules may specifically be a smart contract blacklist composed of the contract addresses of supervised smart contracts.
  • the supervisor needs to update the contract addresses of supervised smart contracts in the smart contract blacklist, the above description can be used
  • a smart contract blacklist is regenerated, and the contract address of the supervised smart contract in the smart contract blacklist can be flexibly deleted or added.
  • the hardware carrying the above-mentioned trusted execution environment can access the distributed ledger of the supervision blockchain when obtaining the supervision rules of the smart contract, and obtain the latest smart contract supervision from the distributed ledger of the supervision blockchain rule;
  • the smart contract supervision rules generated after calling the above smart contract deployed in the above supervision block chain can be stored in the state database of the above supervision block chain; for example, taking Ethereum as an example, the smart contract
  • the result of the call is usually stored in the receipt tree in the state database of the blockchain as part of the transaction receipt of the call transaction of this call.
  • the above-mentioned node equipment can monitor the data related to the above-mentioned smart contract stored in the state database of the above-mentioned supervision blockchain in real time. After the latest smart contract supervision rules generated by calling the smart contract are monitored, the smart contract supervision rules can be stored locally.
  • the hardware that carries the above-mentioned trusted execution environment can directly read the latest smart contract supervision rules locally from the node device.
  • the specific form of the above smart contract supervision rules is not specifically limited in this specification; for example, it can be a smart contract blacklist composed of the contract addresses of supervised smart contracts, or other forms other than the blacklist.
  • the hardware that carries the trusted execution environment is based on
  • the contract address of the target smart contract carried in the call transaction can be obtained first, and then the contract address of the target smart contract can be compared with Match the contract addresses of the supervised smart contracts in the above blacklist;
  • the above contract address is the account address of the contract account created for the smart contract; for example, taking Ethereum as an example, the address of the smart contract account is determined by the sender's address (0xf5e... or ) And transaction nonce (nonce) as input, generated by encryption algorithm.
  • the target smart contract can be determined to be a supervised smart contract; on the contrary, if the contract of the target smart contract The address does not match the contract address in the above blacklist; at this time, it can be determined that the target smart contract is not a supervised smart contract.
  • the above smart contract supervision rules may specifically also be the coding method of the contract address of the supervised smart contract. That is, the smart contract supervision rules can be used to supervise a type of smart contract whose contract address meets a specific encoding method.
  • the smart contract supervision rules can be used to supervise a type of smart contract whose contract address meets a specific encoding method.
  • it is to determine whether the coding method of the contract address of the above-mentioned target smart contract matches the above-mentioned smart contract supervision In the rules, the process of the agreed encoding method.
  • the decryption key stored in the trusted execution environment may not include the decryption key corresponding to the supervised smart contract; that is, in the above
  • the trusted execution environment can store the decryption key corresponding to the contract code of the unsupervised smart contract, but does not store and maintain the decryption key corresponding to the contract code of the supervised smart contract.
  • a user when a user successfully creates a contract account corresponding to a smart contract on the blockchain, he can call the key generation algorithm carried in the trusted execution environment to create a root key for the contract account; After the key is created, the smart contract supervision rules can be further obtained, and based on the obtained smart contract supervision rules in the trusted execution environment, it is determined whether the smart contract is a supervised smart contract; among them, it is determined whether the smart contract is The implementation process of the supervised smart contract will not be repeated.
  • the generated root key can be further stored and maintained in a trusted execution environment. Conversely, if it is determined that the target smart contract is a supervised smart contract, the trusted execution environment can no longer store and maintain the generated root key, and then you can choose to discard the generated root key; for example, if asymmetric encryption is used In this way, the public key in the root key can be sent to the user, while the private key in the root key is discarded; if symmetric encryption is used, a copy of the generated key can be sent to the user, and then The generated key is discarded.
  • the target smart contract is a supervised smart contract
  • the trusted execution environment stores the contract code corresponding to the supervised smart contract
  • the decryption key is forbidden to be extracted; or, the decryption key corresponding to the contract code of the supervised smart contract is not stored in the trusted execution environment; at this time, the decryption key cannot be extracted for the contract code of the target smart contract Decryption; that is, the contract code of the target smart contract cannot be executed; therefore, in this case, the calling process for the target smart contract can be directly terminated, and a prompt message indicating that the target smart contract call failed is returned to the client.
  • the contract code corresponding to the target smart contract is further extracted from the trusted execution environment And decrypt the contract code of the target smart contract based on the decryption key.
  • the method of decrypting the contract code of the target smart contract based on the extracted decryption key corresponds to the encryption method used when deploying the smart contract.
  • the contract code of the target smart contract is encrypted using symmetric encryption when deploying the target smart contract; for example, if the private key of a symmetric encryption algorithm is used for encryption, then the private key of symmetric encryption is used directly. The key can be decrypted.
  • the contract code of the target smart contract is encrypted using asymmetric encryption; for example, the private key of asymmetric encryption is used for encryption; at this time, the public key of asymmetric encryption is used directly Just decrypt it.
  • the contract code of the target smart contract uses a combination of symmetric encryption and asymmetric encryption; for example, the private key of the symmetric encryption algorithm is used to encrypt the contract code, and then the non-symmetric encryption is used.
  • the public key of the symmetric encryption algorithm encrypts the private key used in the above symmetric encryption algorithm.
  • the private key of the asymmetric encryption algorithm is used to decrypt the private key used in the above symmetric encryption algorithm; then the decrypted private key used in the above symmetric encryption algorithm is used to decrypt the encrypted contract code.
  • the trusted execution environment carried by the aforementioned node device may specifically be a trusted execution environment based on a secure extension of CPU hardware and completely isolated from the outside.
  • the trusted execution environment was first proposed by the 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.
  • TEE has also been rapidly developed and expanded.
  • 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.
  • the TEE mentioned now usually refers to this kind of hardware-assisted TEE technology.
  • cloud access requires remote access, and the end user is invisible to the hardware platform. Therefore, the first step in using TEE is to confirm the authenticity of TEE.
  • the current TEE technology has introduced a remote certification mechanism, which is endorsed by hardware vendors (mainly CPU vendors) and digital signature technology ensures that users can verify the state of the TEE.
  • security requirements that cannot be met by only secure resource isolation, further data privacy protection are also proposed.
  • Commercial 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’s 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 (enclave, also known as an enclave), which is an encrypted trusted execution area in the memory. Protect data from being stolen.
  • enclave also known as an enclave
  • the CPU can use the newly added processor instructions to allocate a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) in the memory, and pass the The encryption engine MEE (Memory Encryption Engine) encrypts the data.
  • EPC Enclave Page Cache, enclave page cache or enclave page cache
  • the encrypted content in EPC will be decrypted into plaintext only after entering the CPU. Therefore, in SGX, users can distrust the operating system, VMM (Virtual Machine Monitor), and even BIOS (Basic Input Output System). They only need to trust the CPU to ensure that private data will not leakage.
  • the private data can be encrypted and transferred to the circle in cipher text, and the corresponding secret key can also be passed into the circle through remote proof. Then, the data is used for calculation under the encryption protection of the CPU, and the result will be returned in ciphertext. In this mode, you can use powerful computing power without worrying about data leakage.
  • the node device can load the deployed virtual machine into the enclosure provided by SGX technology. After decrypting the contract code of the target smart contract based on the extracted decryption key, and obtaining the plaintext contract code of the target smart contract, the node device can use the newly added processor instructions in the CPU, which can be distributed in the memory
  • the plaintext contract code obtained by decryption is encrypted and stored in the EPC through the encryption engine MEE in the CPU.
  • the encrypted content in EPC is decrypted into plain text after entering the CPU. In the CPU, operations are performed on the plaintext code to complete the code execution process.
  • the node device executes the plaintext contract code of the target smart contract in the above executable environment, it can also encrypt the execution result of the plaintext contract code, and then send the encrypted execution result to the distributed blockchain
  • the ledger is stored.
  • the execution result of the plaintext contract code of the above-mentioned target smart contract usually causes the state of the smart contract to change; therefore, the execution result of the above-mentioned plaintext contract code is usually stored in the state database of the above-mentioned blockchain; for example, Taking Ethereum as an example, the execution result of the above-mentioned plaintext contract code is usually stored in the receipt tree in the state database of the blockchain as part of the transaction receipt of the calling transaction of this call.
  • the encryption method used when encrypting the execution result of the contract code of the target smart contract can be a symmetric encryption method or an asymmetric encryption method.
  • the encryption key used when writing the execution result of the contract code in the distributed ledger of the blockchain is usually called secret_key.
  • the secret_key can be a symmetric encryption key or an asymmetric encryption key; among them, if the secret_key is a symmetric encryption key, it is usually called a seal (Simple Encrypted Arithmetic Library) key.
  • the seal key can be a key sent by the key management server to the blockchain node after remote certification.
  • the node device in the blockchain executes the encrypted smart contract contract code in the trusted execution environment on board, only the unmanaged smart contract contract code can be decrypted and executed; therefore, On the basis of sufficient privacy protection for smart contracts, some managed smart contracts can be shielded by technical means to realize the supervision of smart contracts.
  • FIG. 5 is a flowchart of another smart contract management method based on blockchain provided by an exemplary embodiment.
  • the method is applied to a node device in a blockchain; wherein, the node device is equipped with a trusted execution environment; the trusted execution environment stores a distributed ledger with the blockchain
  • the decryption key corresponding to the contract code of the encrypted smart contract stored in the encrypted smart contract includes the following steps:
  • Step 502 in response to the call transaction for the target smart contract initiated by the client, obtain the encrypted contract code of the target smart contract stored in the distributed ledger of the blockchain, and combine the encrypted target Sending the contract code of the smart contract to the trusted execution environment;
  • Step 504 Extract the decryption key corresponding to the contract code of the target smart contract stored in the trusted execution environment, decrypt the contract code of the target smart contract based on the extracted decryption key, and Execute the decrypted contract code of the target smart contract in the trusted execution environment;
  • the decryption key corresponding to the contract code of all smart contracts included in the distributed ledger of the blockchain can be stored by default.
  • the decryption key corresponding to the target smart contract stored in the trusted execution environment can be extracted, based on the decryption key
  • the key decrypts the contract code of the target smart contract, and executes the decrypted contract code in a trusted execution environment.
  • Step 506 Obtain smart contract management rules, and determine whether the target smart contract is a managed smart contract based on the smart contract management rules in a trusted execution environment;
  • Step 508 If the target smart contract is not a managed smart contract, the execution result of the contract code of the target smart contract is encrypted and sent to the distributed ledger of the blockchain for storage.
  • the execution result of the contract code can be cached in the above trusted execution environment, and the decision can be made by further determining whether the target smart contract is a supervised smart contract Whether it is necessary to encrypt the execution result of the above contract code and send it to the distributed ledger of the blockchain for storage.
  • the hardware carrying the trusted execution environment can further obtain smart contract supervision rules, and determine whether the target smart contract is a supervised smart contract based on the obtained smart contract supervision rules in the trusted execution environment.
  • the specific implementation process will not be repeated, and the records in the previous embodiments can be referred to.
  • the cached execution result of the target smart contract's contract code can be deleted at this time, and the target smart contract call failure is returned to the aforementioned client Prompt message.
  • the execution result of the contract code of the target smart contract can also be switched from caching mode to persistence in a trusted execution environment Store, and set the execution result of the persistent storage in the trusted execution environment to a state where extraction is prohibited; at the same time, it can also return a prompt message that the target smart contract call failed to the client.
  • the target smart contract is not a supervised smart contract
  • the distributed ledger of the chain is stored.
  • the specific implementation process will not be repeated, and the records in the previous embodiments can be referred to.
  • this application also provides an embodiment of an apparatus.
  • this specification also provides an embodiment of a smart contract management device based on blockchain.
  • the embodiments of the blockchain-based smart contract management device in this specification can be applied to electronic equipment.
  • the device embodiments can be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory through the processor of the electronic device where it is located.
  • FIG. 6 it is a hardware structure diagram of the electronic equipment where the smart contract management device based on the blockchain of this specification is located, except for the processor, memory, network interface, and In addition to the non-volatile memory, the electronic device in which the device is located in the embodiment generally may include other hardware according to the actual function of the electronic device, which will not be repeated here.
  • Fig. 7 is a block diagram of a smart contract management device based on blockchain according to an exemplary embodiment of this specification.
  • the block chain-based smart contract management device 70 can be applied to the electronic device shown in FIG. 6, which is equipped with a trusted execution environment; including:
  • the first obtaining module 701 in response to the call transaction for the target smart contract initiated by the client, obtains the encrypted contract code of the target smart contract stored in the distributed ledger of the blockchain, and then encrypts the encrypted contract code of the target smart contract. Sending the contract code of the target smart contract to the trusted execution environment;
  • the first determining module 702 obtains smart contract management rules, and determines whether the target smart contract is a managed smart contract based on the smart contract management rules in a trusted execution environment;
  • the first execution module 704 executes the decrypted contract code of the target smart contract in the trusted execution environment, and sends the encrypted execution result to the distributed ledger of the blockchain for storage.
  • the trusted execution environment stores a decryption key corresponding to the encrypted smart contract contract code stored in the distributed ledger of the blockchain;
  • the decryption key corresponding to the managed smart contract stored in the trusted execution environment is set to prohibit extraction; or, the decryption key stored in the trusted execution environment does not include the decryption key corresponding to the managed smart contract Decryption key.
  • the device 70 further includes:
  • the first return module (not shown in FIG. 7), if the target smart contract is a managed smart contract, returns a prompt message that the target smart contract call failed to the client.
  • the device 70 further includes:
  • the receiving module receives the creation transaction for the target smart contract initiated by the client; wherein the creation transaction includes the encrypted contract code of the target smart contract;
  • the creation module in response to the creation transaction, executes the smart contract creation code in the trusted execution environment, creates a contract account corresponding to the target smart contract in the blockchain, and encrypts the encrypted
  • the contract code of the target smart contract is sent to the distributed ledger of the blockchain for storage.
  • the first obtaining module 701 the first obtaining module 701:
  • the smart contract management rules are obtained from the distributed ledger of the management blockchain; wherein, the smart contract management rules are generated by the management party calling the smart contract deployed on the management blockchain.
  • the smart contract management rules include: a smart contract blacklist composed of contract addresses of managed smart contracts;
  • the first determining module 702 The first determining module 702:
  • the contract address of the target smart contract matches any contract address in the smart contract blacklist, it is determined that the target smart contract is a managed smart contract; otherwise, it is determined that the target smart contract is not a managed smart contract.
  • the encryption method used for the contract code of the target smart contract includes any one of the following encryption methods: symmetric encryption, asymmetric encryption, symmetric encryption combined with asymmetric encryption ;
  • the encryption method adopted for the execution result of the contract code of the target smart contract includes: a symmetric encryption method; or, an asymmetric encryption method.
  • the combination of symmetric encryption and asymmetric encryption includes digital envelope encryption.
  • the trusted execution environment includes Intel SGX.
  • Fig. 8 is a block diagram of a smart contract management device based on blockchain according to an exemplary embodiment of this specification.
  • the block chain-based smart contract management device 80 can be applied to the electronic device shown in FIG. 6, the electronic device is equipped with a trusted execution environment; the trusted execution environment stores The decryption key corresponding to the encrypted smart contract contract code stored in the distributed ledger of the blockchain; including:
  • the second acquisition module 801 in response to the invocation transaction for the target smart contract initiated by the client, acquires the encrypted contract code of the target smart contract stored in the distributed ledger of the blockchain, and the encrypted contract code Sending the contract code of the target smart contract to the trusted execution environment;
  • the second decryption module 802 extracts the decryption key corresponding to the contract code of the target smart contract stored in the trusted execution environment, and performs processing on the contract code of the target smart contract based on the extracted decryption key Decrypt
  • the second execution module 803 executes the decrypted contract code of the target smart contract in the trusted execution environment
  • the second determination module 804 obtains smart contract management rules, and determines whether the target smart contract is a managed smart contract based on the smart contract management rules in a trusted execution environment; if the target smart contract is not a managed smart contract , The execution result of the contract code of the target smart contract is encrypted and sent to the distributed ledger of the blockchain for storage.
  • the device 80 further includes:
  • the second return module (not shown in Figure 8), if the target smart contract is a managed smart contract, delete the execution result of the contract code of the target smart contract, and return the target smart contract to the client The prompt message of call failure; or,
  • the target smart contract is a managed smart contract, store the execution result of the contract code of the target smart contract in the trusted execution environment, and set the execution result stored in the trusted execution environment to Prohibition of extraction; and, returning to the client a prompt message indicating that the target smart contract call failed.
  • 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 computer readable media, 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)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Databases & Information Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种基于区块链的智能合约管理方法，包括：响应于客户端发起的针对目标智能合约的调用交易，将加密后的目标智能合约的合约代码发送至区块链节点设备搭载的可信执行环境；获取智能合约管理规则，在可信执行环境中基于智能合约管理规则确定目标智能合约是否为被管理智能合约；如果不是，提取可信执行环境中存储的与目标智能合约的合约代码对应的解密密钥，并基于提取到的解密密钥对目标智能合约的合约代码进行解密；在可信执行环境中执行解密后的目标智能合约的合约代码，并将执行结果加密后发送至区块链的分布式账本进行存储。

Description

基于区块链的智能合约管理方法及装置、电子设备 技术领域
本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于区块链的智能合约管理方法及装置、电子设备。
背景技术
区块链技术，也被称之为分布式账本技术，是一种由若干台计算设备共同参与“记账”，共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性，使得区块链技术已在众多的领域中广泛的进行应用。
发明内容
本说明书提出一种基于区块链的智能合约管理方法，应用于区块链中的节点设备；其中，所述节点设备搭载了可信执行环境；所述方法包括：
响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；
如果所述目标智能合约不是被管理智能合约，提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，并基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密；
在所述可信执行环境中执行解密后的所述目标智能合约的合约代码，并将执行结果加密后发送至所述区块链的分布式账本进行存储。
可选的，所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥；
其中，所述可信执行环境中存储的与被管理智能合约对应的解密密钥被设置为禁止提取；或者，所述可信执行环境中存储的解密密钥不包括与被管理智能合约对应的解 密密钥。
可选的，所述方法还包括：
如果所述目标智能合约是被管理智能合约，向所述客户端返回所述目标智能合约调用失败的提示消息。
可选的，所述方法还包括：
接收客户端发起的针对目标智能合约的创建交易；其中，所述创建交易包括加密后的所述目标智能合约的合约代码；
响应于所述创建交易，在所述可信执行环境中执行智能合约创建代码，在所述区块链中创建与所述目标智能合约对应的合约账户，并将加密后的所述目标智能合约的合约代码发送至所述区块链的分布式账本进行存储。
可选的，所述获取智能合约管理规则，包括：
从管理区块链的分布式账本中获取智能合约管理规则；其中，所述智能合约管理规则由管理方调用部署在所述管理区块链上的智能合约，生成的智能合约管理规则。
可选的，所述智能合约管理规则包括：由被管理智能合约的合约地址构成的智能合约黑名单；
所述基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约，包括：
获取所述调用交易中的所述目标智能合约的合约地址；
将所述目标智能合约的合约地址与所述智能合约黑名单中的合约地址进行匹配；
如果所述目标智能合约的合约地址与所述智能合约黑名单中的任一合约地址匹配，确定所述目标智能合约为被管理智能合约；反之，确定所述目标智能合约不是被管理智能合约。
可选的，对所述目标智能合约的合约代码采用的加密方式，包括以下示出的加密方式中的任意一种：对称加密方式、非对称加密方式、对称加密结合非对称加密的方式；
对所述目标智能合约的合约代码的执行结果采用的加密方式，包括：对称加密方式；或者，非对称加密方式。
可选的，其中，所述对称加密结合非对称加密的方式，包括数字信封加密方式。
可选的，其中，所述可信执行环境包括Intel SGX。
本说明书还提出一种基于区块链的智能合约管理装置，应用于区块链中的节点设备；其中，所述节点设备搭载了可信执行环境；所述装置包括：
获取模块，响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
确定模块，获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；
解密模块，如果所述目标智能合约不是被管理智能合约，提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，并基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密；
执行模块，在所述可信执行环境中执行解密后的所述目标智能合约的合约代码，并将执行结果加密后发送至所述区块链的分布式账本进行存储。
可选的，所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥；
其中，所述可信执行环境中存储的与被管理智能合约对应的解密密钥被设置为禁止提取；或者，所述可信执行环境中存储的解密密钥不包括与被管理智能合约对应的解密密钥。
可选的，所述装置还包括：
返回模块，如果所述目标智能合约是被管理智能合约，向所述客户端返回所述目标智能合约调用失败的提示消息。
可选的，所述装置还包括：
接收模块，接收客户端发起的针对目标智能合约的创建交易；其中，所述创建交易包括加密后的所述目标智能合约的合约代码；
创建模块，响应于所述创建交易，在所述可信执行环境中执行智能合约创建代码，在所述区块链中创建与所述目标智能合约对应的合约账户，并将加密后的所述目标智能合约的合约代码发送至所述区块链的分布式账本进行存储。
可选的，所述获取模块：
从管理区块链的分布式账本中获取智能合约管理规则；其中，所述智能合约管理规则由管理方调用部署在所述管理区块链上的智能合约，生成的智能合约管理规则。
可选的，所述智能合约管理规则包括：由被管理智能合约的合约地址构成的智能合约黑名单；
所述确定模块：
获取所述调用交易中的所述目标智能合约的合约地址；
将所述目标智能合约的合约地址与所述智能合约黑名单中的合约地址进行匹配；
如果所述目标智能合约的合约地址与所述智能合约黑名单中的任一合约地址匹配，确定所述目标智能合约为被管理智能合约；反之，确定所述目标智能合约不是被管理智能合约。
可选的，对所述目标智能合约的合约代码采用的加密方式，包括以下示出的加密方式中的任意一种：对称加密方式、非对称加密方式、对称加密结合非对称加密的方式；
对所述目标智能合约的合约代码的执行结果采用的加密方式，包括：对称加密方式；或者，非对称加密方式。
可选的，其中，所述对称加密结合非对称加密的方式，包括数字信封加密方式。
可选的，其中，所述可信执行环境包括Intel SGX。
本说明书还提出一种基于区块链的智能合约管理方法，应用于区块链中的节点设备；其中，所述节点设备搭载了可信执行环境；所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥；所述方法包括：
响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密，并在所述可信执行环境中执行解密后的所述目标智能合约的合约代码；
获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；
如果所述目标智能合约不是被管理智能合约，则将所述目标智能合约的合约代码的执行结果加密后发送至所述区块链的分布式账本进行存储。
可选的，所述方法还包括：
如果所述目标智能合约是被管理智能合约，删除所述目标智能合约的合约代码的执行结果，并向所述客户端返回所述目标智能合约调用失败的提示消息；或者，
如果所述目标智能合约是被管理智能合约，在所述可信执行环境中存储所述目标智能合约的合约代码的执行结果，并将所述可信执行环境中存储的所述执行结果设置为禁止提取；以及，向所述客户端返回所述目标智能合约调用失败的提示消息。
本说明书还提出一种基于区块链的智能合约管理装置，应用于区块链中的节点设备；其中，所述节点设备搭载了可信执行环境；所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥；所述装置包括：
第二获取模块，响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
第一解密模块，提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密；
第二执行模块，在所述可信执行环境中执行解密后的所述目标智能合约的合约代码；
第二确定模块，获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；如果所述目标智能合约不是被管理智能合约，则将所述目标智能合约的合约代码的执行结果加密后发送至所述区块链的分布式账本进行存储。
可选的，所述装置还包括：
第二返回模块，如果所述目标智能合约是被管理智能合约，删除所述目标智能合约的合约代码的执行结果，并向所述客户端返回所述目标智能合约调用失败的提示消息；或者，
如果所述目标智能合约是被管理智能合约，在所述可信执行环境中存储所述目标智能合约的合约代码的执行结果，并将所述可信执行环境中存储的所述执行结果设置为 禁止提取；以及，向所述客户端返回所述目标智能合约调用失败的提示消息。
通过以上技术方案，由于区块链中的节点设备在搭载的可信执行环境中执行加密后的智能合约的合约代码时，只有不受管理的智能合约的合约代码可以进行解密和执行；因此，可以在对智能合约进行充分的隐私保护的基础上，通过技术手段对一些被管理智能合约进行内容屏蔽，来实现对智能合约的监管。
附图说明
图1是一示例性实施例提供的一种创建智能合约的示意图；
图2是一示例性实施例提供的调用智能合约的示意图；
图3是一示例性实施例提供的创建智能合约和调用智能合约的示意图；
图4是一示例性实施例提供的一种基于区块链的智能合约管理方法的流程图；
图5是一示例性实施例提供的另一种基于区块链的智能合约管理方法的流程图；
图6是一示例性实施例提供的一种电子设备的结构示意图；
图7是一示例性实施例提供的一种基于区块链的智能合约管理装置的框图；
图8是一示例性实施例提供的一种基于区块链的智能合约管理装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(Private  Blockchain)和联盟链(Consortium Blockchain)。此外，还有多种类型的结合，比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。而且，各参与者(即节点)可自由加入以及退出网络，并进行相关操作。私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，参与节点具有严格限制且少。这种类型的区块链更适合于特定机构内部使用。
联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；参与者通过授权加入网络并组成利益相关联盟，共同维护区块链运行。
不论是公有链、私有链还是联盟链，都可能提供智能合约(Smart contract)的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。
以以太坊为例，支持用户在以太坊网络中创建并调用一些复杂的逻辑，这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM)，每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机，这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上，虚拟机直接运行的是虚拟机代码(虚拟机字节码，下简称“字节码”)。部署在区块链上的智能合约可以是字节码的形式。
如图1所示，Bob将一个包含创建智能合约信息的交易(Transaction)发送到以太坊网络后，节点1的EVM可以执行这个交易并生成对应的合约实例。图中1中的“0x68e12cf284…”代表了这个合约的地址，交易的data字段保存的可以是字节码，交易的to字段为一个空的账户。节点间通过共识机制达成一致后，这个合约成功创建，后续用户可以调用这个合约。
合约创建后，区块链上出现一个与该智能合约对应的合约账户，并拥有一个特定的地址，合约代码和账户存储将保存在该合约账户中。智能合约的行为由合约代码控制，而智能合约的账户存储(Storage)则保存了合约的状态。换句话说，智能合约使得区块链上产生包含合约代码和账户存储的虚拟账户。
前述提到，包含创建智能合约的交易的data字段保存的可以是该智能合约的字节 码。字节码由一连串的字节组成，每一字节可以标识一个操作。基于开发效率、可读性等多方面考虑，开发者可以不直接书写字节码，而是选择一门高级语言编写智能合约代码。例如，采用诸如Solidity、Serpent、LLL语言等高级语言。对于采用高级语言编写的智能合约代码，可以经过编译器编译，生成可以部署到区块链上的字节码。
以Solidity语言为例，用其编写的合约与面向对象编程语言中的类(Class)很相似，在一个合约中可以声明多种成员，包括状态变量、函数、函数修改器、事件等。状态变量是永久存储在智能合约的账户存储中的值，用于保存合约的状态。
一般的，当一个智能合约部署在区块链后，智能合约的合约代码中的状态变量对应的存储状态是明文，任何人都可以看到其状态，无隐私保护的设置和能力。
如图2所示，仍以以太坊为例，Bob将一个包含调用智能合约信息的交易发送到以太坊网络后，节点1的EVM可以执行这个交易并生成对应的合约实例。图中2中交易的from字段是发起调用智能合约的账户的地址，to字段中的“0x692a70d2…”代表了被调用的智能合约的地址，value字段在以太坊中是以太币的值，交易的data字段保存的调用智能合约的方法和参数。调用智能合约后，balance的值可能改变。后续，某个客户端可以通过某一区块链节点(例如图2中的节点6)查看balance的当前值。
智能合约可以以规定的方式在区块链网络中每个节点独立的执行，所有执行记录和数据都保存在区块链上，所以当这样的交易完成后，区块链上就保存了无法篡改、不会丢失的交易凭证。
创建智能合约和调用智能合约的示意图如图3所示。以太坊中要创建一个智能合约，需要经过编写智能合约、变成字节码、部署到区块链等过程。以太坊中调用智能合约，是发起一笔指向智能合约地址的交易，智能合约代码分布式的运行在以太坊网络中每个节点的虚拟机中。
目前企业级的区块链平台技术上最大的两个挑战就是隐私和性能，往往这两个挑战很难同时解决。大多解决方案都是通过损失性能换取隐私，或者不大考虑隐私去追求性能。常见的解决隐私问题的加密技术，如同态加密(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，平台安全处理器)。
在传统的区块链与TEE相结合的解决方案中，为了实现隐私保护，智能合约整体被当作需要隐私保护的数据在TEE中进行调用执行，并将全部合约状态加密存储在区块链上。通过这种方式，虽然在某种程度上可以提升隐私保护的安全等级，但也对数据的管理造成困难。
例如，在示出的一种管理场景下，作为智能合约的监管一方，可能具有对智能合约的合约代码的执行过程以及对应的执行结果，进行内容监管的需求；但在传统的区块链与TEE相结合的解决方案中，智能合约执行的安全等级较高，智能合约的执行过程以及执行结果均处于一种不可见的隐私状态；因此，这就对智能合约的内容监管造成困难。
而在本说明书旨在提出一种在区块链与TEE相结合的应用场景中，在对智能合约进行充分的隐私保护的基础上，进一步实现对智能合约的有效管理的技术方案。
在实现时，在区块链上部署的智能合约的合约代码，可以加密后在区块链的分布式账本中进行持久化存储。而在区块链中的节点设备搭载的可信执行环境中，可以预先存储与区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥。
例如，以智能合约的内容监管的场景为例，在一种实施方式中，上可信执行环境中的存储的解密密钥，可以只包含那些受监管的智能合约对应的解密钥；也即，在可信执行环境中可以仅存储不受监管的智能合约对应的解密密钥，而并不存储那些受监管的智能合约的解密密钥。
在另一种实施方式中，上述可信执行环境中，可以默认存储所有的智能合约对应的解密密钥；而对于上述可信执行环境中存储的受监管的智能合约对应的解密密钥，可以被设置为禁止提取；也即，不是被管理智能合约的合约代码对应的解密密钥，可以被正常提取。
当节点设备收到客户端发起的针对目标智能合约的调用交易时，可以获取区块链的分布式账本中存储的加密后的该目标智能合约的合约代码，并将获取到的加密后的该目标智能合约的合约代码发送至该节点设备所搭载的可信执行环境。
在将加密的该目标智能合约的合约代码发送至该节点设备所搭载的可信执行环境之后，节点设备可以获取智能合约管理规则，并在搭载的可信执行环境中，基于获取到的智能合约管理规则，来确定该目标智能合约是否为被管理智能合约；
如果经过确认，认定该目标智能合约不是被管理智能合约，此时节点设备可以提取可信执行环境中存储的与该目标智能合约的合约代码对应的解密密钥，对该目标智能合约的合约代码进行解密。
当完成解密得到上述目标智能合约的明文合约代码后，节点设备可以在上述可信执行环境中，执行解密得到的明文合约代码，然后将执行结果加密后发送至区块链的分布式账本进行存储。
在以上技术方案中，由于区块链中的节点设备在搭载的可信执行环境中执行加密后的智能合约的合约代码时，只有不受管理的智能合约的合约代码可以进行解密和执行；因此，可以在对智能合约进行充分的隐私保护的基础上，通过技术手段对一些被管理智能合约进行内容屏蔽，来实现对智能合约的监管。
请参见图4，图4是一示例性实施例提供的一种基于区块链的智能合约管理方法的流程图。如图4所示，该方法应用于区块链中的节点设备；其中，所述节点设备搭载了可信执行环境；所述方法包括以下步骤：
步骤402，响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
步骤404，获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；
步骤406，如果所述目标智能合约不是被管理智能合约，提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，并基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密；
步骤408，在所述可信执行环境中执行解密后的所述目标智能合约的合约代码，并将执行结果加密后发送至所述区块链的分布式账本进行存储。
在本说明书中，对智能合约进行管理，具体可以是指智能合约的管理方，对智能合约的合约代码的执行过程以及对应的执行结果进行管理。
例如，在示出的一种管理场景下，对智能合约进行管理，具体是指对智能合约的合约代码的执行过程以及对应的执行结果进行内容监管；而在这种管理场景下，上述管理方相应的也可以是指智能合约的监管方。
以下将结合针对智能合约进行监管的管理场景，对本说明书的技术方案进行详细描述。在这种场景下，上述被管理智能合约即为被监管智能合约；上述智能合约管理规则即为智能合约监管规则。在本说明书中，用户在编写完成了智能合约的合约代码后，可以基于该智能合约的合约代码，在客户端上构建一笔用于创建智能合约的创建交易，并将交易发送给与该客户端对接的区块链节点设备。
例如，在实现时，如果用户采用高级语言编写智能合约的合约代码，则客户端可以进一步经过编译器对合约代码进行编译，生成可以部署到区块链上的字节码，然后基于编译生成的智能合约的字节码，来“打包”生成一笔用于创建智能合约的创建交易，并将交易发送给与该客户端对接的区块链节点设备。
需要说明的是，为保证用户编写完成的合约代码的隐私性，客户端可以采用密钥对编写完成的合约代码进行加密。
例如，在实现时，客户端可以直接对构建出的上述创建交易整体进行加密；或者，也可以仅对构建出的上述创建交易中携带的智能合约的字节码本身进行加密；具体的加密方式，本领域技术人员在将本说明书公开的技术方案付诸实现时，可以灵活的选择。
其中，对合约代码进行加密时所采用的加密方式，可以采用对称加密，也可以采用非对称加密。
例如，对称加密采用的加密算法，可以是DES算法，3DES算法，TDEA算法，Blowfish算法，RC5算法，IDEA算法等。非对称加密采用的算法，可以是RSA、Elgamal、背包算法、Rabin、D-H、ECC(椭圆曲线加密算法)等。
除此之外，对合约代码进行加密时所采用的加密方式，还可以采用对称加密和非对称加密相结合的方式。这种加密方式一般称之为数字信封(Digital Envelope)加密方式。
例如，客户端采用对称加密算法加密合约代码，即采用对称加密算法的私钥加密合约代码，然后再用非对称加密算法的公钥加密上述对称加密算法中所采用的私钥。也 即，先用对称加密算法的密钥，加密合约代码；再使用非对称加密算法的密钥，对加密上述合约代码时所使用的密钥进行进一步的加密。
区块链中的节点设备在收到客户端发送的上述创建交易后，可以检查该交易是否有效、格式是否正确，验证该交易的签名是否合法等，并在所有的检查和验证均通过后，可以在可信执行环境中执行该创建交易，完成智能合约的创建。
具体的，在可信执行环境中执行该创建交易之前，首先可以确认该笔交易的功能类型；
例如，以以太坊为例，通常是基于交易中携带的交易内容来确定交易的功能类型；比如，如果交易中的to字段为一个空的账户，并且交易的data字段携带需要部署的字节码，则可以认定该笔交易为用于创建智能合约的交易；如果交易中的to字段指向一个已经存在的智能合约的合约地址，并且交易的data字段携带调用智能合约所需的参数，则可以认定该笔交易为用于调用智能合约的交易。
当确认该笔交易为用于创建智能合约的创建交易，可以进一步在上述可信安全环境中执行智能合约创建代码，在区块链上创建一个与智能合约对应的合约账户，并将该创建交易中的加密后的智能合约的合约代码发送至区块链的分布式账本进行存储。
例如，以以太坊为例，创建的合约账户中通常会包括Balance、Nonce、codehash和storaghash等属性字段，节点设备在完成合约账户的创建后，会将创建交易中的合约代码的hash值填充至上述codehash字段，将上述创建交易打包进区块发送给区块链中的其它各节点设备，在区块链的分布式账本中进行存储。也即，智能合约的合约代码的原始内容，仍然存放在原始的创建交易保存在区块链的区块中，与该智能合约对应的合约账户中，仅需要维护智能合约的合约代码的hash指针。
一般的，区块链中支持的共识算法，通常分为节点设备需要争夺每一轮的记账周期的记账权的共识算法，和预先为每一轮记账周期选举记账节点(不需要争夺记账权)的共识算法。
例如，前者以工作量证明(Proof of Work,POW)、股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)等共识算法为代表；后者以实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)等共识算法为代表。
对于采用工作量证明(Proof of Work,POW)以及股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)等共识算法的支持智能合约的区块链 网络中，争夺记账权的节点都可以在接收到创建交易后执行该笔交易。争夺记账权的节点中可能其中一个在本轮争夺记账权的过程中胜出，成为记账节点。记账节点可以收到的该创建交易与其它交易一起打包并生成新的区块，并将生成的新的区块发送至其它节点进行共识。
对于采用实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)等共识算法的支持智能合约的区块链网络中，具有记账权的节点在本轮记账前已经商定好。因此，节点设备在接收到上述创建交易后，如果自身不是本轮的记账节点，则可以将该创建交易发送至记账节点。对于本轮的记账节点，在将该创建交易与其它交易一起打包并生成新区块的过程中或者之前，可以执行该创建交易。记账节点在将该创建交易与其它交易一起打包生成新区块后，可以将生成的新的区块或者该新的区块的区块头发送至其它节点进行共识。
如上所述，无论区块链采用以上示出的哪种共识算法，本轮的记账节点都可以将该创建交易打包并生成新的区块，并将生成的新的区块或者区块头发送至其它节点设备进行共识验证。如果其它节点设备接收到新的区块或者区块头后，经验证没有问题，可以将该新的区块追加到原有的区块链末尾，从而完成记账过程，达成共识。当达成共识后，也就完成了智能合约在区块链上的部署。其中，其它节点设备在验证记账节点发来的新的区块或区块头的过程中，也可以执行该区块中的包含的上述创建交易。
在本说明书中，在可信执行环境中执行上述创建交易的具体过程，具体可以是通过在上述可信执行环境中部署的虚拟机来完成；也即，可信执行环境中部署的虚拟机才是上述创建交易的执行主体；例如，以以太坊为例，节点设备通常是通过搭载的以太坊虚拟机(Ethereum Virtual Machine，EVM)来执行交易。
在本说明书中，当在区块链上完成了智能合约的部署之后，用户可以在客户端上构建一笔用于调用目标智能合约的调用交易，并将交易发送给与该客户端对接的区块链节点设备，来发起对已经部署完成的目标智能合约的调用执行。
区块链中的节点设备在收到客户端发送的上述调用交易后，仍然可以检查该交易是否有效、格式是否正确，验证该交易的签名是否合法等，并在所有的检查和验证均通过后，在可信执行环境中执行该调用交易。
具体的，在可信执行环境中执行该调用交易之前，首先也可以确认该笔交易的功能类型；当确认该笔交易为用于调用智能合约的调用交易，可以进一步获取区块链的分 布式账本中存储的加密后的该目标智能合约的合约代码，并将获取到的加密后的该目标智能合约的合约代码发送至上述可信执行环境，在上述可信执行环境中进行执行。
在本说明书中，在上述可信执行环境中，可以存储和维护与区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥。例如，在实际应用中，在上述可信执行环境中可以搭载密钥生成算法，当用户在区块链成功创建了一个与智能合约对应的合约账户时，节点设备可以在可信执行环境中，调用搭载的密钥生成算法，为该合约账户创建根密钥。
其中，如果采用非对称加密方式，该根密钥包括公私钥对；公钥用于对合约代码进行加密，由用户持有；私钥存储在可信执行环境中，用于对加密的合约代码进行解密；如果采用对称加密方式，该根密钥则仅包括一个用于对合约代码进行加密和解密的密钥。
其中，上述密钥生成算法的具体类型，以及基于上述密钥生成算法创建根密钥的具体实施过程，本说明书中不再进行详述。
在示出的一种实施方式中，为了实现对智能合约的监管，在上述可信执行环境中，可以默认存储区块链的分布式账本中收录的所有智能合约的合约代码对应的解密密钥；其中，为了实现监管的目的，对于上述可信执行环境中存储的受监管的智能合约对应的解密密钥，，可以将其设置为禁止提取的状态。
其中，关于如何将在上述可信执行环境中存储和维护的与被监管智能合约的合约代码对应的解密密钥设置为不可提取的状态的实施手段，在本说明书中不进行特别的限定；
例如，在示出的一种实现方式中，可以在可信执行环境中部署用于对解密密钥的提取权限进行控制的程序代码，该程序代码具体可以由承载该可信执行环境的硬件(比如，作为可信执行环境的芯片)来独立的进行调用执行；进而可信执行环境可以通过执行上述程序代码，对存储和维护的解密密钥的提取权限进行控制，以保障该可信执行环境中存储和维护的与被监管智能合约的合约代码对应的解密密钥，处于一种无法被提取和导出的状态。当然，除了以上示出的实现方式以外，在实际应用中，也可以通过其它的实现方式进行实施，在本说明书中不再进行一一列举。
在将获取到的加密后的上述目标智能合约的合约代码，发送至上述可信执行环境之后，承载该可信执行环境的硬件，可以进一步获取智能合约监管规则，并在该可信执行环境中基于获取到的智能合约监管规则确定该目标智能合约是否为被监管智能合约。
其中，上述智能合约监管规则，具体可以是由监管方自主生成，并且能够由监管方来进行实时的更新和修改的监管规则。
在示出的一种实施方式中，在以上描述的区块链的基础上，可以再部署一个独立的监管区块链，并在该监管区块链上部署用于生成智能合约监管规则的智能合约，并在该智能合约中声明用于生成智能合约监管规则的生成逻辑。进而，监管方可以基于实际的监管需求构建调用交易，来调用该智能合约，动态的生成智能合约监管规则，并将生成的智能合约监管规则在该监管区块链的分布式账本中进行存储。
其中，所述动态的生成智能合约监管规则，是指对智能合约进行监管时实际所使用的智能合约监管规则，总是以最新生成的智能合约监管规则为准。如果监管方的监管需求发生变化，监管方可以基于新的监管需求，来调用该智能合约重新生成新的智能合约监管规则。
通过这种方式，监管方可以基于实际的监管需求，来灵活的对智能合约监管规则进行动态更新。
例如，上述智能合约监管规则具体可以是由被监管智能合约的合约地址组成的智能合约黑名单，当监管方需要更新该智能合约黑名单中的被监管智能合约的合约地址时，可以通过以上描述的方式，通过调用上述智能合约，来重新生成一个智能合约黑名单，灵活的对智能合约黑名单中的被监管智能合约的合约地址进行删除或者增加。
相应的，承载上述可信执行环境的硬件，在获取智能合约监管规则时，可以访问该监管区块链的分布式账本，从该监管区块链的分布式账本中来获取最新的智能合约监管规则；
例如，在实现时，调用部署在上述监管区块链中的上述智能合约后生成的智能合约监管规则，可以存储在上述监管区块链的状态数据库中；比如，以以太坊为例，智能合约的调用结果，通常会作为本次调用的调用交易的交易收据的一部分内容，存储至区块链的状态数据库中的收据树中。而上述节点设备可以实时的监听上述监管区块链的状态数据库中存储的，与上述智能合约相关的数据。当监听到调用该智能合约生成的最新的智能合约监管规则后，可以将该智能合约监管规则在本地进行存储。而承载上述可信执行环境的硬件，则可以直接从该节点设备本地读取最新的智能合约监管规则。
其中，上述智能合约监管规则的具体形式，在本说明书中不仅进行特别限定；例如，具体可以是由被监管智能合约的合约地址构成的智能合约黑名单，也可以黑名单以 外的其他形式。
在示出的一种实施方式中，以上述智能合约监管规则是由被监管智能合约的合约地址构成的智能合约黑名单为例，在这种情况下，承载上述可信执行环境的硬件在基于获取到的最新的智能合约监管规则确定上述目标智能合约是否为被监管智能合约时，首先可以获取上述调用交易中携带的上述目标智能合约的合约地址，再将该目标智能合约的合约地址，与上述黑名单中的被监管智能合约的合约地址进行匹配；
其中，在本说明书中，上述合约地址就是为智能合约创建的合约账户的账户地址；例如，以以太坊为例，智能合约账户的地址是由发送者的地址(如图1中的0xf5e…或)和交易随机数(nonce)作为输入，通过加密算法生成的。
如果该目标智能合约的合约地址，与上述黑名单中的任一被监管智能合约的合约地址匹配；此时，可以确定该目标智能合约为被监管智能合约；反之，如果该目标智能合约的合约地址，与上述黑名单中的合约地址均不匹配；此时，可以确定该目标智能合约不是被监管智能合约。
需要说明的是，当上述智能合约监管规则为上述智能合约黑名单以外的其它形式的监管规则时，在基于获取到的最新的智能合约监管规则确定上述目标智能合约是否为被监管智能合约时的具体确认方式，也会随之发生变化，在本说明书中不再进行一一列举；
例如，在一种情况下，上述智能合约监管规则，具体也可以是被监管智能合约的合约地址的编码方式。也即，可以通过该智能合约监管规则，对合约地址满足特定的编码方式的一类智能合约进行监管。在这种情况下，在基于获取到的最新的智能合约监管规则确定上述目标智能合约是否为被监管智能合约时，即为确定上述目标智能合约的合约地址的编码方式，是否匹配上述智能合约监管规则中，所约定的编码方式的过程。
在示出的一种实施方式中，为了实现对智能合约的监管，上述可信执行环境中存储的解密密钥，也可以不包含受监管的智能合约对应的解密密钥；也即，在上述可信执行环境中可以存储与不受监管的智能合约的合约代码对应的解密密钥，而并不存储和维护与被监管的智能合约的合约代码对应的解密密钥。
例如，在实现时，当用户在区块链成功创建了一个与智能合约对应的合约账户时，可以调用可信执行环境中搭载的密钥生成算法，为该合约账户创建根密钥；当根密钥创建完成后，可以进一步获取智能合约监管规则，并在该可信执行环境中基于获取到的智 能合约监管规则来确定该智能合约是否为被监管智能合约；其中，确定该智能合约是否为被监管智能合约的实施过程不再赘述。
如果确定该目标智能合约不是被监管智能合约，则可以进一步在可信执行环境中存储和维护生成的根密钥。反之，如果确定该目标智能合约是被监管智能合约，则可信执行环境可以不再存储和维护生成的根密钥，此时可以选择将生成的根密钥丢弃；例如，如果采用非对称加密方式，可以将根密钥中的公钥发送给用户持有，而将根密钥中的私钥丢弃；如果采用对称加密方式，则可以将生成的密钥复制一份发送给用户，再将生成的该密钥丢弃。
在本说明书中，如果在该可信执行环境中基于获取到的智能合约监管规则确定上述目标智能合约是被监管智能合约，由于可信执行环境中存储的与被监管智能合约的合约代码对应的解密密钥是被禁止提取的；或者，可信执行环境中并没有存储被监管智能合约的合约代码对应的解密密钥；此时，无法提取到解密密钥对该目标智能合约的合约代码进行解密；也即，无法执行该目标智能合约的合约代码；因此，在这种情况下，可以直接终止针对该目标智能合约的调用过程，向上述客户端返回该目标智能合约调用失败的提示消息。
如果在该可信执行环境中基于获取到的智能合约监管规则确定该目标智能合约不是被监管智能合约，此时还进一步从该可信执行环境中，提取出与该目标智能合约的合约代码对应的解密密钥，并基于该解密密钥对该目标智能合约的合约代码进行解密。其中，基于提取出的解密密钥，对该目标智能合约的合约代码进行解密的方式，与在部署该智能合约时所采用的加密方式相对应。
如前所述，如果在部署该目标智能合约时，该目标智能合约的合约代码采用了对称加密的方式进行加密；比如，采用对称加密算法的私钥进行加密，此时直接使用对称加密的私钥进行解密即可。
如果在部署该目标智能合约时，该目标智能合约的合约代码采用了非对称加密的方式进行加密；比如，采用了非对称加密的私钥进行了加密；此时直接使用非对称加密的公钥进行解密即可。
进一步的，如果在部署该目标智能合约时，该目标智能合约的合约代码采用了对称加密和非对称加密相结合的方式；比如，采用用对称加密算法的私钥加密合约代码，然后再用非对称加密算法的公钥加密上述对称加密算法中所采用的私钥。此时先使用非 对称加密算法的私钥解密上述对称加密算法中所采用的私钥；再使用解密出的上述对称加密算法中所采用的私钥，对加密的合约代码进行解密。
在本说明书中，上述节点设备搭载的可信执行环境，具体可以是一个基于CPU硬件的安全扩展，且与外部完全隔离的可信执行环境。
可信执行环境最早是由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为例，该CPU可以利用新增的处理器指令，在内存中分配一部分区域EPC(Enclave Page Cache，围圈页面缓存或飞地页面缓存)，通过CPU内的加密引擎MEE(Memory Encryption Engine)对其中的数据进行加密。
EPC中加密的内容只有进入CPU后才会被解密成明文。因此，在SGX中，用户可以不信任操作系统、VMM(Virtual Machine Monitor，虚拟机监控器)、甚至BIOS(Basic Input Output System，基本输入输出系统)，只需要信任CPU便能确保隐私数据不会泄漏。实际应用中，可以将隐私数据加密后以密文形式传递至围圈中，并通过远 程证明将对应的秘钥也传入围圈。然后，在CPU的加密保护下利用数据进行运算，结果会以密文形式返回。这种模式下，既可以利用强大的计算力，又不用担心数据泄漏。
在这种情况下，节点设备可以将部署的虚拟机，加载进SGX技术提供的围圈中。当在基于提取出的解密密钥对上述目标智能合约的合约代码进行解密，获得该目标智能合约的明文合约代码以后，该节点设备可以利用CPU中新增的处理器指令，在内存中可以分配一部分区域EPC，通过CPU内的加密引擎MEE对上述解密得到的明文合约代码进行加密存入所述EPC中。EPC中加密的内容进入CPU后被解密成明文。在CPU中，对所述明文的代码进行运算，完成代码的执行过程。
当节点设备在上述可执行环境中，执行上述目标智能合约的明文合约代码后，还可以对该明文合约代码的执行结果进行加密，然后将加密后的执行结果发送至上述区块链的分布式账本进行存储。
例如，由于上述目标智能合约的明文合约代码的执行结果，通常会导致该智能合约的状态发生变化；因此，上述明文合约代码的执行结果通常会存储至上述区块链的状态数据库中；比如，以以太坊为例，上述明文合约代码的执行结果，通常会作为本次调用的调用交易的交易收据的一部分内容，存储至区块链的状态数据库中的收据树中。
其中，在本说明书中，对上述目标智能合约的合约代码的执行结果进行加密时所采用的加密方式，具体可以是对称加密方式，也可以是非对称加密方式，
例如，仍以上述可信执行环境为Intel SGX为例，在区块链的分布式账本中写入合约代码的执行结果时使用的加密密钥，通常称之为secret_key。该secret_key可以是对称加密的密钥，也可以是非对称加密密钥；其中，如果该secret_key是对称加密的密钥，通常称之为seal(Simple Encrypted Arithmetic Library)密钥。基于Intel SGX技术，该seal密钥，可以是通过远程证明后由密钥管理服务器发送给区块链节点的密钥。
在以上技术方案中，由于区块链中的节点设备在搭载的可信执行环境中执行加密后的智能合约的合约代码时，只有不受管理的智能合约的合约代码可以进行解密和执行；因此，可以在对智能合约进行充分的隐私保护的基础上，通过技术手段对一些被管理智能合约进行内容屏蔽，来实现对智能合约的监管。
请参见图5，图5是一示例性实施例提供的另一种基于区块链的智能合约管理方法的流程图。如图5所示，该方法应用于区块链中的节点设备；其中，所述节点设备搭载了可信执行环境；所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密 后的智能合约的合约代码对应的解密密钥；所述方法包括以下步骤：
步骤502，响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
步骤504，提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密，并在所述可信执行环境中执行解密后的所述目标智能合约的合约代码；
在本说明书中，在上述可信执行环境中，可以默认存储区块链的分布式账本中收录的所有智能合约的合约代码对应的解密密钥。
而在将加密的该目标智能合约的合约代码发送至该节点设备所搭载的可信执行环境之后，可以提取可信执行环境中存储的与该目标智能合约对应的解密密钥，基于该解密密钥对该目标智能合约的合约代码进行解密，并在可信执行环境中执行解密后的合约代码。
步骤506，获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；
步骤508，如果所述目标智能合约不是被管理智能合约，则将所述目标智能合约的合约代码的执行结果加密后发送至所述区块链的分布式账本进行存储。
在本说明书中，当目标智能合约的合约代码执行完毕后，可以在上述可信执行环境中缓存上述合约代码的执行结果，并通过进一步确定该目标智能合约是否为受监管的智能合约，来决策是否需要将上述合约代码的执行结果加密后发送至区块链的分布式账本进行存储。
具体的，承载该可信执行环境的硬件，可以进一步获取智能合约监管规则，并在该可信执行环境中基于获取到的智能合约监管规则来确定该目标智能合约是否为被监管智能合约。其中，具体的实施过程不再赘述，可以参考之前实施例的记载。
在示出的一种实施方式中，如果该目标智能合约是被监管智能合约，此时可以删除缓存的该目标智能合约的合约代码的执行结果，并向上述客户端返回该目标智能合约调用失败的提示消息。
在示出的另一种实施方式中，如果该目标智能合约是被管理智能合约，也可以将 该目标智能合约的合约代码的执行结果，由缓存模式切换为在可信执行环境中进行持久化存储，并将该可信执行环境中持久化存储的上述执行结果设置为禁止提取状态；同时，还可以向上述客户端返回该目标智能合约调用失败的提示消息。
当然，如果该目标智能合约不是被监管智能合约，此时可以针对上述可信执行环境中缓存的该目标智能合约的合约代码的执行结果进行加密，然后将加密后的执行结果发送至上述区块链的分布式账本进行存储。其中，具体的实施过程也不再赘述，可以参考之前实施例的记载。
在以上技术方案中，由于区块链中的节点设备在搭载的可信执行环境中执行解密的智能合约的合约代码之后，只有不受管理的智能合约的合约代码的执行结果进一步加密后发送至区块链的分布式账本进行存储；因此，可以在对智能合约进行充分的隐私保护的基础上，通过技术手段对一些被管理智能合约进行内容屏蔽，来实现对智能合约的监管。与上述方法实施例相对应，本申请还提供了装置的实施例。
与上述方法实施例相对应，本说明书还提供了一种基于区块链的智能合约管理装置的实施例。本说明书的基于区块链的智能合约管理装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图6所示，为本说明书的基于区块链的智能合约管理装置所在电子设备的一种硬件结构图，除了图6所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。
图7是本说明书一示例性实施例示出的一种基于区块链的智能合约管理装置的框图。
请参考图7，所述基于区块链的智能合约管理装置70可以应用在前述图6所示的电子设备中，所述电子设备搭载了可信执行环境；包括：
第一获取模块701，响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
第一确定模块702，获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；
第一解密模块703，如果所述目标智能合约不是被管理智能合约，提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，并基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密；
第一执行模块704，在所述可信执行环境中执行解密后的所述目标智能合约的合约代码，并将执行结果加密后发送至所述区块链的分布式账本进行存储。
在本实施例中，所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥；
其中，所述可信执行环境中存储的与被管理智能合约对应的解密密钥被设置为禁止提取；或者，所述可信执行环境中存储的解密密钥不包括与被管理智能合约对应的解密密钥。
在本实施例中，所述装置70还包括：
第一返回模块(图7中未示出)，如果所述目标智能合约是被管理智能合约，向所述客户端返回所述目标智能合约调用失败的提示消息。
在本实施例中，所述装置70还包括：
接收模块，接收客户端发起的针对目标智能合约的创建交易；其中，所述创建交易包括加密后的所述目标智能合约的合约代码；
创建模块，响应于所述创建交易，在所述可信执行环境中执行智能合约创建代码，在所述区块链中创建与所述目标智能合约对应的合约账户，并将加密后的所述目标智能合约的合约代码发送至所述区块链的分布式账本进行存储。
在本实施例中，所述第一获取模块701：
从管理区块链的分布式账本中获取智能合约管理规则；其中，所述智能合约管理规则由管理方调用部署在所述管理区块链上的智能合约，生成的智能合约管理规则。
在本实施例中，所述智能合约管理规则包括：由被管理智能合约的合约地址构成的智能合约黑名单；
所述第一确定模块702：
获取所述调用交易中的所述目标智能合约的合约地址；
将所述目标智能合约的合约地址与所述智能合约黑名单中的合约地址进行匹配；
如果所述目标智能合约的合约地址与所述智能合约黑名单中的任一合约地址匹配，确定所述目标智能合约为被管理智能合约；反之，确定所述目标智能合约不是被管理智能合约。
在本实施例中，对所述目标智能合约的合约代码采用的加密方式，包括以下示出的加密方式中的任意一种：对称加密方式、非对称加密方式、对称加密结合非对称加密的方式；
对所述目标智能合约的合约代码的执行结果采用的加密方式，包括：对称加密方式；或者，非对称加密方式。
在本实施例中，其中，所述对称加密结合非对称加密的方式，包括数字信封加密方式。
在本实施例中，其中，所述可信执行环境包括Intel SGX。
图8是本说明书一示例性实施例示出的一种基于区块链的智能合约管理装置的框图。
请参考图8，所述基于区块链的智能合约管理装置80可以应用在前述图6所示的电子设备中，所述电子设备搭载了可信执行环境；所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥；包括：
第二获取模块801，响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
第二解密模块802，提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密；
第二执行模块803，在所述可信执行环境中执行解密后的所述目标智能合约的合约代码；
第二确定模块804，获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；如果所述目标智能合约不是被管理智能合约，则将所述目标智能合约的合约代码的执行结果加密后发送至所述区块链的分布式账本进行存储。
在本实施例中，所述装置80还包括：
第二返回模块(图8中未示出)，如果所述目标智能合约是被管理智能合约，删除所述目标智能合约的合约代码的执行结果，并向所述客户端返回所述目标智能合约调用失败的提示消息；或者，
如果所述目标智能合约是被管理智能合约，在所述可信执行环境中存储所述目标智能合约的合约代码的执行结果，并将所述可信执行环境中存储的所述执行结果设置为禁止提取；以及，向所述客户端返回所述目标智能合约调用失败的提示消息。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备 所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (26)

  1. 一种基于区块链的智能合约管理方法，应用于区块链中的节点设备；其中，所述节点设备搭载了可信执行环境；所述方法包括：
    响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
    获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；
    如果所述目标智能合约不是被管理智能合约，提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，并基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密；
    在所述可信执行环境中执行解密后的所述目标智能合约的合约代码，并将执行结果加密后发送至所述区块链的分布式账本进行存储。
  2. 如权利要求1所述的方法，所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥；
    其中，所述可信执行环境中存储的与被管理智能合约对应的解密密钥被设置为禁止提取；或者，所述可信执行环境中存储的解密密钥不包括与被管理智能合约对应的解密密钥。
  3. 如权利要求2所述的方法，所述方法还包括：
    如果所述目标智能合约是被管理智能合约，向所述客户端返回所述目标智能合约调用失败的提示消息。
  4. 如权利要求1所述的方法，所述方法还包括：
    接收客户端发起的针对目标智能合约的创建交易；其中，所述创建交易包括加密后的所述目标智能合约的合约代码；
    响应于所述创建交易，在所述可信执行环境中执行智能合约创建代码，在所述区块链中创建与所述目标智能合约对应的合约账户，并将加密后的所述目标智能合约的合约代码发送至所述区块链的分布式账本进行存储。
  5. 如权利要求1所述的方法，所述获取智能合约管理规则，包括：
    从管理区块链的分布式账本中获取智能合约管理规则；其中，所述智能合约管理规则由管理方调用部署在所述管理区块链上的智能合约，生成的智能合约管理规则。
  6. 如权利要求1或5所述的方法，所述智能合约管理规则包括：由被管理智能合 约的合约地址构成的智能合约黑名单；
    所述基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约，包括：
    获取所述调用交易中的所述目标智能合约的合约地址；
    将所述目标智能合约的合约地址与所述智能合约黑名单中的合约地址进行匹配；
    如果所述目标智能合约的合约地址与所述智能合约黑名单中的任一合约地址匹配，确定所述目标智能合约为被管理智能合约；反之，确定所述目标智能合约不是被管理智能合约。
  7. 如权利要求1所述的方法，对所述目标智能合约的合约代码采用的加密方式，包括以下示出的加密方式中的任意一种：对称加密方式、非对称加密方式、对称加密结合非对称加密的方式；
    对所述目标智能合约的合约代码的执行结果采用的加密方式，包括：对称加密方式；或者，非对称加密方式。
  8. 如权利要求7所述的方法，其中，所述对称加密结合非对称加密的方式，包括数字信封加密方式。
  9. 如权利要求1所述的方法，其中，所述可信执行环境包括Intel SGX。
  10. 一种基于区块链的智能合约管理装置，应用于区块链中的节点设备；其中，所述节点设备搭载了可信执行环境；所述装置包括：
    第一获取模块，响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
    第一确定模块，获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；
    第一解密模块，如果所述目标智能合约不是被管理智能合约，提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，并基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密；
    第一执行模块，在所述可信执行环境中执行解密后的所述目标智能合约的合约代码，并将执行结果加密后发送至所述区块链的分布式账本进行存储。
  11. 如权利要求10所述的装置，所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥；
    其中，所述可信执行环境中存储的与被管理智能合约对应的解密密钥被设置为禁止 提取；或者，所述可信执行环境中存储的解密密钥不包括与被管理智能合约对应的解密密钥。
  12. 如权利要求11所述的装置，所述装置还包括：
    第一返回模块，如果所述目标智能合约是被管理智能合约，向所述客户端返回所述目标智能合约调用失败的提示消息。
  13. 如权利要求10所述的装置，所述装置还包括：
    接收模块，接收客户端发起的针对目标智能合约的创建交易；其中，所述创建交易包括加密后的所述目标智能合约的合约代码；
    创建模块，响应于所述创建交易，在所述可信执行环境中执行智能合约创建代码，在所述区块链中创建与所述目标智能合约对应的合约账户，并将加密后的所述目标智能合约的合约代码发送至所述区块链的分布式账本进行存储。
  14. 如权利要求10所述的装置，所述第一获取模块：
    从管理区块链的分布式账本中获取智能合约管理规则；其中，所述智能合约管理规则由管理方调用部署在所述管理区块链上的智能合约，生成的智能合约管理规则。
  15. 如权利要求10或14所述的装置，所述智能合约管理规则包括：由被管理智能合约的合约地址构成的智能合约黑名单；
    所述第一确定模块：
    获取所述调用交易中的所述目标智能合约的合约地址；
    将所述目标智能合约的合约地址与所述智能合约黑名单中的合约地址进行匹配；
    如果所述目标智能合约的合约地址与所述智能合约黑名单中的任一合约地址匹配，确定所述目标智能合约为被管理智能合约；反之，确定所述目标智能合约不是被管理智能合约。
  16. 如权利要求10所述的装置，对所述目标智能合约的合约代码采用的加密方式，包括以下示出的加密方式中的任意一种：对称加密方式、非对称加密方式、对称加密结合非对称加密的方式；
    对所述目标智能合约的合约代码的执行结果采用的加密方式，包括：对称加密方式；或者，非对称加密方式。
  17. 如权利要求16所述的装置，其中，所述对称加密结合非对称加密的方式，包括数字信封加密方式。
  18. 如权利要求10所述的装置，其中，所述可信执行环境包括Intel SGX。
  19. 一种基于区块链的智能合约管理方法，应用于区块链中的节点设备；其中，所 述节点设备搭载了可信执行环境；所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥；所述方法包括：
    响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
    提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密，并在所述可信执行环境中执行解密后的所述目标智能合约的合约代码；
    获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；
    如果所述目标智能合约不是被管理智能合约，则将所述目标智能合约的合约代码的执行结果加密后发送至所述区块链的分布式账本进行存储。
  20. 如权利要求19所述的方法，所述方法还包括：
    如果所述目标智能合约是被管理智能合约，删除所述目标智能合约的合约代码的执行结果，并向所述客户端返回所述目标智能合约调用失败的提示消息；或者，
    如果所述目标智能合约是被管理智能合约，在所述可信执行环境中存储所述目标智能合约的合约代码的执行结果，并将所述可信执行环境中存储的所述执行结果设置为禁止提取；以及，向所述客户端返回所述目标智能合约调用失败的提示消息。
  21. 一种基于区块链的智能合约管理装置，应用于区块链中的节点设备；其中，所述节点设备搭载了可信执行环境；所述可信执行环境中存储了与所述区块链的分布式账本中存储的加密后的智能合约的合约代码对应的解密密钥；所述装置包括：
    第二获取模块，响应于客户端发起的针对目标智能合约的调用交易，获取所述区块链的分布式账本中存储的加密后的所述目标智能合约的合约代码，并将加密后的所述目标智能合约的合约代码发送至所述可信执行环境；
    第二解密模块，提取所述可信执行环境中存储的与所述目标智能合约的合约代码对应的解密密钥，基于提取到的所述解密密钥对所述目标智能合约的合约代码进行解密；
    第二执行模块，在所述可信执行环境中执行解密后的所述目标智能合约的合约代码；
    第二确定模块，获取智能合约管理规则，并在可信执行环境中基于所述智能合约管理规则确定所述目标智能合约是否为被管理智能合约；如果所述目标智能合约不是被管理智能合约，则将所述目标智能合约的合约代码的执行结果加密后发送至所述区块链的分布式账本进行存储。
  22. 如权利要求21所述的装置，所述装置还包括：
    第二返回模块，如果所述目标智能合约是被管理智能合约，删除所述目标智能合约的合约代码的执行结果，并向所述客户端返回所述目标智能合约调用失败的提示消息；或者，
    如果所述目标智能合约是被管理智能合约，在所述可信执行环境中存储所述目标智能合约的合约代码的执行结果，并将所述可信执行环境中存储的所述执行结果设置为禁止提取；以及，向所述客户端返回所述目标智能合约调用失败的提示消息。
  23. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求1-9中任一项所述的方法。
  24. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求19-20中任一项所述的方法。
  25. 一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求1-9中任一项所述方法的步骤。
  26. 一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求19-20中任一项所述方法的步骤。
PCT/CN2020/072055 2019-05-30 2020-01-14 基于区块链的智能合约管理方法及装置、电子设备 WO2020238255A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/777,110 US10839107B2 (en) 2019-05-30 2020-01-30 Managing a smart contract on a blockchain
US17/098,124 US11048825B2 (en) 2019-05-30 2020-11-13 Managing a smart contract on a blockchain

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910464790.1A CN110245506B (zh) 2019-05-30 2019-05-30 基于区块链的智能合约管理方法及装置、电子设备
CN201910464790.1 2019-05-30

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/777,110 Continuation US10839107B2 (en) 2019-05-30 2020-01-30 Managing a smart contract on a blockchain

Publications (1)

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

Family

ID=67885468

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/072055 WO2020238255A1 (zh) 2019-05-30 2020-01-14 基于区块链的智能合约管理方法及装置、电子设备

Country Status (3)

Country Link
CN (2) CN110245506B (zh)
TW (1) TW202113645A (zh)
WO (1) WO2020238255A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113221151A (zh) * 2021-05-28 2021-08-06 数网金融有限公司 基于区块链的数据处理方法、装置及存储介质
CN113658005A (zh) * 2021-04-28 2021-11-16 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法和区块链系统
CN113689293A (zh) * 2021-08-09 2021-11-23 深圳前海微众银行股份有限公司 一种联盟链中智能合约文件确定方法及装置
CN113821570A (zh) * 2021-11-22 2021-12-21 中国信息通信研究院 基于区块链和sql的数据处理方法
CN114327803A (zh) * 2022-03-15 2022-04-12 北京百度网讯科技有限公司 区块链访问机器学习模型的方法、装置、设备和介质
CN116074115A (zh) * 2023-03-06 2023-05-05 广州市悦智计算机有限公司 一种基于智能合约实现跨链加密会话方法

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10839107B2 (en) 2019-05-30 2020-11-17 Advanced New Technologies Co., Ltd. Managing a smart contract on a blockchain
CN110245506B (zh) * 2019-05-30 2020-09-01 阿里巴巴集团控股有限公司 基于区块链的智能合约管理方法及装置、电子设备
CN113157635B (zh) * 2019-09-25 2024-01-05 支付宝(杭州)信息技术有限公司 在fpga上实现合约调用的方法及装置
CN110738567B (zh) * 2019-09-25 2021-02-09 支付宝(杭州)信息技术有限公司 基于fpga的安全智能合约处理器的交易处理方法及装置
CN110597888B (zh) * 2019-09-29 2023-10-27 腾讯科技（深圳）有限公司 基于区块链的虚拟资源获取方法及装置、介质、设备
CN111177738A (zh) * 2019-10-09 2020-05-19 北京海益同展信息科技有限公司 电子读物管理方法、装置、电子设备及存储介质
CN111523110B (zh) * 2019-11-08 2023-05-02 支付宝(杭州)信息技术有限公司 基于链代码的权限查询配置方法及装置
CN111047443B (zh) * 2019-11-29 2021-01-12 支付宝(杭州)信息技术有限公司 用户评分方法及装置、电子设备、计算机可读存储介质
CN111277414B (zh) * 2020-01-17 2023-06-20 南京邮电大学 基于rsa算法和智能合约的分布式公钥生成方法及装置
CN111461878A (zh) * 2020-03-10 2020-07-28 杭州溪塔科技有限公司 一种基于链外智能合约的区块链交易处理方法和系统
CN111090888B (zh) * 2020-03-18 2020-07-07 支付宝(杭州)信息技术有限公司 验证合约的方法及装置
CN111538521B (zh) * 2020-04-24 2024-02-09 中国工商银行股份有限公司 智能合约部署、交易方法及装置
CN111510462B (zh) * 2020-04-28 2022-07-08 拉扎斯网络科技（上海）有限公司 通信方法、系统、装置、电子设备和可读存储介质
CN111737256A (zh) * 2020-06-12 2020-10-02 北京众享比特科技有限公司 一种基于可信执行环境和区块链的数据库表操作方法和系统
WO2021253299A1 (zh) * 2020-06-17 2021-12-23 达闼机器人有限公司 数据处理方法、存储介质、电子设备及数据交易系统
CN112104748B (zh) * 2020-11-09 2021-02-26 百度在线网络技术（北京）有限公司 区块链数据的监管方法、装置、电子设备和存储介质
CN112883436A (zh) * 2021-02-08 2021-06-01 北京微芯区块链与边缘计算研究院 智能合约专用芯片装置及执行方法、区块链节点装置
CN113034140B (zh) * 2021-03-17 2023-07-18 深圳壹账通智能科技有限公司 实现智能合约加密的方法、系统、设备及存储介质
CN113011894B (zh) * 2021-03-29 2023-04-07 昆明理工大学 一种基于可信计算与智能合约的金融衍生品数字交易系统
CN113726733B (zh) * 2021-07-19 2022-07-22 东南大学 一种基于可信执行环境的加密智能合约隐私保护方法
CN113469815A (zh) * 2021-09-02 2021-10-01 支付宝(杭州)信息技术有限公司 数据管理方法及装置
CN114817399A (zh) * 2021-09-06 2022-07-29 支付宝(杭州)信息技术有限公司 区块管理方法及装置
CN114070584B (zh) * 2021-10-15 2024-02-06 北京智融云河科技有限公司 一种机密计算方法、装置、设备及存储介质
CN113901498B (zh) * 2021-10-15 2023-12-26 北京智融云河科技有限公司 一种数据共享方法、装置、设备及存储介质
CN113946864B (zh) * 2021-10-15 2024-03-19 北京智融云河科技有限公司 一种机密信息获取方法、装置、设备及存储介质
CN114663080A (zh) * 2022-04-08 2022-06-24 北京京东乾石科技有限公司 基于区块链系统实现的数据处理方法、装置、设备及介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107464118A (zh) * 2017-08-16 2017-12-12 济南浪潮高新科技投资发展有限公司 一种基于区块链智能合约的数据交易方法
CN108352014A (zh) * 2015-07-09 2018-07-31 里奎德市场集团公司 使用区块链技术交易、清算和结算证券交易的系统和方法
CN110245506A (zh) * 2019-05-30 2019-09-17 阿里巴巴集团控股有限公司 基于区块链的智能合约管理方法及装置、电子设备

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105812332A (zh) * 2014-12-31 2016-07-27 北京握奇智能科技有限公司 数据保护方法
US10447478B2 (en) * 2016-06-06 2019-10-15 Microsoft Technology Licensing, Llc Cryptographic applications for a blockchain system
US20180225661A1 (en) * 2017-02-07 2018-08-09 Microsoft Technology Licensing, Llc Consortium blockchain network with verified blockchain and consensus protocols
US10742393B2 (en) * 2017-04-25 2020-08-11 Microsoft Technology Licensing, Llc Confidentiality in a consortium blockchain network
US11055703B2 (en) * 2017-06-19 2021-07-06 Hitachi, Ltd. Smart contract lifecycle management
CN107342858B (zh) * 2017-07-05 2019-09-10 武汉凤链科技有限公司 一种基于可信环境的智能合约保护方法和系统
US11288740B2 (en) * 2017-12-29 2022-03-29 Intel Corporation Securing distributed electronic wallet shares
WO2019127531A1 (zh) * 2017-12-29 2019-07-04 深圳前海达闼云端智能科技有限公司 基于区块链的数据处理方法、装置、存储介质及电子设备
CN108647009A (zh) * 2018-03-22 2018-10-12 中钞信用卡产业发展有限公司杭州区块链技术研究院 区块链信息交互的装置、方法和存储介质
CN108898390B (zh) * 2018-06-27 2021-01-12 创新先进技术有限公司 基于区块链的智能合约调用方法及装置、电子设备
CN109345390A (zh) * 2018-09-25 2019-02-15 深圳市元征科技股份有限公司 一种智能合约访问方法、系统、设备及计算机存储介质
CN109660350A (zh) * 2018-10-31 2019-04-19 阿里巴巴集团控股有限公司 基于区块链的数据存证方法及装置、电子设备
CN109670335A (zh) * 2018-12-20 2019-04-23 众安信息技术服务有限公司 用于在区块链与链外数据之间进行交互的方法及装置
CN109766722B (zh) * 2019-01-22 2020-11-10 苏州同济区块链研究院有限公司 一种区块链中构建智能合约的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108352014A (zh) * 2015-07-09 2018-07-31 里奎德市场集团公司 使用区块链技术交易、清算和结算证券交易的系统和方法
CN107464118A (zh) * 2017-08-16 2017-12-12 济南浪潮高新科技投资发展有限公司 一种基于区块链智能合约的数据交易方法
CN110245506A (zh) * 2019-05-30 2019-09-17 阿里巴巴集团控股有限公司 基于区块链的智能合约管理方法及装置、电子设备

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113658005A (zh) * 2021-04-28 2021-11-16 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法和区块链系统
CN113221151A (zh) * 2021-05-28 2021-08-06 数网金融有限公司 基于区块链的数据处理方法、装置及存储介质
CN113689293A (zh) * 2021-08-09 2021-11-23 深圳前海微众银行股份有限公司 一种联盟链中智能合约文件确定方法及装置
CN113689293B (zh) * 2021-08-09 2024-02-06 深圳前海微众银行股份有限公司 一种联盟链中智能合约文件确定方法及装置
CN113821570A (zh) * 2021-11-22 2021-12-21 中国信息通信研究院 基于区块链和sql的数据处理方法
CN113821570B (zh) * 2021-11-22 2022-03-01 中国信息通信研究院 基于区块链和sql的数据处理方法
CN114327803A (zh) * 2022-03-15 2022-04-12 北京百度网讯科技有限公司 区块链访问机器学习模型的方法、装置、设备和介质
CN116074115A (zh) * 2023-03-06 2023-05-05 广州市悦智计算机有限公司 一种基于智能合约实现跨链加密会话方法

Also Published As

Publication number Publication date
TW202113645A (zh) 2021-04-01
CN110245506B (zh) 2020-09-01
CN110245506A (zh) 2019-09-17
CN113240519A (zh) 2021-08-10

Similar Documents

Publication Publication Date Title
WO2020238255A1 (zh) 基于区块链的智能合约管理方法及装置、电子设备
US11048825B2 (en) Managing a smart contract on a blockchain
CN110580418B (zh) 基于区块链账户的隐私数据查询方法及装置
CN110580414B (zh) 基于区块链账户的隐私数据查询方法及装置
WO2021088548A1 (zh) 基于智能合约的隐私数据查询方法及装置
CN110580413B (zh) 基于链下授权的隐私数据查询方法及装置
WO2020238959A1 (zh) 基于区块高度实现动态加密的方法及装置
CN110580245B (zh) 隐私数据的共享方法及装置
CN110263544B (zh) 结合交易类型和判断条件的收据存储方法和节点
WO2020233631A1 (zh) 基于交易类型的收据存储方法和节点
CN110245947B (zh) 结合交易与用户类型的条件限制的收据存储方法和节点
WO2020233635A1 (zh) 结合多类型维度的条件限制的收据存储方法和节点
WO2021088535A1 (zh) 基于智能合约的隐私数据查询方法及装置
WO2020233615A1 (zh) 结合用户类型与事件函数类型的收据存储方法和节点
WO2020233630A1 (zh) 基于用户类型的收据存储方法和节点
CN110580411B (zh) 基于智能合约的权限查询配置方法及装置
WO2020233628A1 (zh) 结合事件函数类型和判断条件的收据存储方法和节点
WO2020233624A1 (zh) 结合交易类型和事件函数类型的收据存储方法和节点
WO2020233619A1 (zh) 结合用户类型与交易类型的收据存储方法和节点
CN111523110A (zh) 基于链代码的权限查询配置方法及装置
WO2020233627A1 (zh) 多类型维度的收据存储方法和节点
WO2020238955A1 (zh) 基于交易偏移量实现动态加密的方法及装置
WO2020233632A1 (zh) 基于事件函数类型的收据存储方法和节点
WO2020233634A1 (zh) 结合交易与事件类型的条件限制的收据存储方法和节点
WO2020233633A1 (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: 20814681

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: 20814681

Country of ref document: EP

Kind code of ref document: A1