WO2021184961A1 - 部署合约的方法及装置 - Google Patents
部署合约的方法及装置 Download PDFInfo
- Publication number
- WO2021184961A1 WO2021184961A1 PCT/CN2021/073809 CN2021073809W WO2021184961A1 WO 2021184961 A1 WO2021184961 A1 WO 2021184961A1 CN 2021073809 W CN2021073809 W CN 2021073809W WO 2021184961 A1 WO2021184961 A1 WO 2021184961A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- chain
- node
- client
- computing node
- bytecode
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/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
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
Definitions
- One or more embodiments of this specification relate to the field of verifiable computing technology, and in particular, to a method and device for deploying a contract.
- 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, and only the pre-defined interface in the code can operate on it.
- plaintext data is calculated in TEE instead of complex cryptographic operations in homomorphic encryption, and there is no loss in the efficiency of the calculation process.
- one or more embodiments of this specification provide a method and device for deploying a contract, which can safely implement the operation of deploying a contract in an off-chain environment.
- a method for deploying a contract which includes: a client obtains a remote certification report for a private off-chain computing node, and the remote certification report is verified by an authentication server.
- the self-recommendation information generated by the off-chain private computing node is generated after verification.
- the self-recommendation information is related to the off-chain trusted execution environment created on the off-chain private computing node;
- the off-chain private computing node is trusted, the bytecode of the off-chain contract is encrypted and transmitted to the off-chain private computing node, and the off-chain private computing node is decrypted in the off-chain trusted execution environment Obtain the bytecode and deploy; wherein, in the case where the blockchain node initiates a call to the off-chain contract through the oracle mechanism, the deployed bytecode is executed in the off-chain trusted execution environment , And the execution result is fed back to the blockchain node through the oracle mechanism.
- a method for deploying a contract which includes: a private off-chain computing node receives a challenge from a client, and provides a remote attestation report to the client, and the remote The certification report is generated by the authentication server after verifying the self-recommendation information generated by the off-chain private computing node, and the self-recommendation information is related to the off-chain trusted execution environment created on the off-chain private computing node; the off-chain privacy The computing node receives the bytecode of the off-chain contract encrypted and transmitted by the client, and the bytecode is sent by the client when it is determined that the off-chain privacy computing node is credible according to the remote attestation report; The off-chain private computing node decrypts the bytecode in the off-chain trusted execution environment, and deploys the bytecode; wherein, the blockchain node uses the oracle mechanism to verify the chain When the next contract initiates a call, the deployed bytecode is
- a method for deploying a contract includes: a blockchain node receives a challenge transaction initiated by a client, and returns to the client the private computing node's A remote attestation report, which is generated by an authentication server after verifying the self-recommendation information generated by the off-chain private computing node, and the self-recommendation information is related to the off-chain trusted execution environment created on the off-chain private computing node Relevant; the blockchain node receives the encrypted off-chain contract deployment transaction initiated by the client, and decrypts it in the on-chain trusted execution environment to obtain the bytecode secret contained in the off-chain contract deployment transaction The bytecode ciphertext is obtained by encrypting the bytecode of the off-chain contract by the client, and the off-chain contract deployment transaction is determined by the client according to the remote attestation report.
- the private computing node is initiated when the private computing node is trusted; the blockchain node transmits the bytecode ciphertext to the off-chain private computing node through the oracle mechanism, and the off-chain private computing node in the chain
- the bytecode is decrypted in a trusted execution environment and deployed; wherein, when the blockchain node initiates a call to the off-chain contract through the oracle mechanism, the deployed bytecode is in the It is executed in the trusted execution environment under the chain, and the execution result is fed back to the blockchain node through the oracle mechanism.
- a method for deploying a contract which includes: the control node of the off-chain private computing cluster receives the challenge initiated by the client, and selects from the off-chain private computing cluster A private off-chain computing node, and provide the client with a remote attestation report corresponding to the selected off-chain private computing node.
- the remote attestation report is self-recommended by the authentication server for the selected off-chain private computing node
- the information is generated after verification, and the self-recommendation information is related to the off-chain trusted execution environment created on the selected off-chain private computing node; wherein, all off-chain private computing nodes in the off-chain private computing cluster
- the software and hardware configurations are consistent; the control node receives the bytecode of the off-chain contract encrypted and transmitted by the client, and the bytecode is determined by the client according to the remote attestation report to determine the off-chain privacy computing cluster
- the control node forwards the received bytecode ciphertext to all off-chain privacy computing nodes in the off-chain privacy computing cluster, and the byte
- the code ciphertext can be decrypted by each off-chain private computing node in its own off-chain trusted execution environment to obtain the bytecode, and deploy the bytecode; among them, the blockchain node uses the oracle mechanism In the case of
- a method for deploying a contract which includes: a client obtains a remote certification report for a private computing node, and the remote certification report is calculated by an authentication server on the privacy
- the self-recommendation information generated by the node is generated after verification, and the self-recommendation information is related to the trusted execution environment created on the private computing node; the client determines the trustworthiness of the private computing node according to the remote attestation report
- the bytecode of the smart contract is encrypted and transmitted to the private computing node, and the private computing node decrypts the bytecode in the trusted execution environment and deploys it.
- a method for deploying a contract which includes: a private computing node receives a challenge from a client, and provides a remote attestation report to the client, the remote attestation report Generated by the authentication server after verifying the self-recommendation information generated by the private computing node, the self-recommendation information is related to the trusted execution environment created on the private computing node; the private computing node receives the encrypted transmission from the client
- the bytecode of the smart contract the bytecode is sent by the client when it is determined that the private computing node is trustworthy according to the remote attestation report; the private computing node is in the trusted execution environment
- the bytecode is obtained by decryption, and the bytecode is deployed.
- a method for deploying a contract including: a control node of a private computing cluster receives a challenge initiated by a client, and a private computing node is selected from the private computing cluster , And provide the client with a remote attestation report corresponding to the selected private computing node.
- the remote attestation report is generated by the authentication server after verifying the self-recommended information generated by the selected private computing node.
- the self-recommended information Related to the trusted execution environment created on the selected private computing node; wherein, the software and hardware configurations of all private computing nodes in the private computing cluster are consistent; the control node receives the encrypted transmission of the intelligent client
- the bytecode of the contract the bytecode is sent by the client under the condition that the privacy computing node in the privacy computing cluster is credible according to the remote attestation report; the control node will receive the word
- the code ciphertext is forwarded to all private computing nodes in the privacy computing cluster, and the bytecode ciphertext can be decrypted by each private computing node in its own trusted execution environment to obtain the bytecode, and the The bytecode is deployed.
- a device for deploying a contract including: a verification unit that enables the client to obtain a remote certification report for a private computing node under the chain, and the remote certification report is certified by The server verifies the self-recommendation information generated by the off-chain private computing node and generates it, and the self-recommendation information is related to the off-chain trusted execution environment created on the off-chain private computing node; the deployment unit enables the client to log in If it is determined according to the remote certification report that the off-chain private computing node is trustworthy, the bytecode of the off-chain contract is encrypted and transmitted to the off-chain private computing node, and the off-chain private computing node will The bytecode is decrypted in an off-chain trusted execution environment and deployed; wherein, when a blockchain node initiates a call to the off-chain contract through the oracle mechanism, the deployed bytecode is in the It is executed in an off-chain trusted execution environment
- a device for deploying a contract including: a report providing unit that enables the off-chain private computing node to receive a challenge from a client and provide remote certification to the client Report, the remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the off-chain private computing node, and the self-recommendation information is related to the off-chain trusted execution environment created on the off-chain private computing node;
- the contract receiving unit enables the off-chain privacy computing node to receive the bytecode of the off-chain contract encrypted and transmitted by the client, and the bytecode is determined by the client according to the remote attestation report.
- the private computing node is sent when it is trusted; the contract deployment unit enables the off-chain private computing node to decrypt in the off-chain trusted execution environment to obtain the bytecode, and deploy the bytecode; Wherein, in the case that the blockchain node initiates a call to the off-chain contract through the oracle mechanism, the deployed bytecode is executed in the off-chain trusted execution environment, and the execution result passes through the oracle The mechanism is fed back to the blockchain node.
- a device for deploying a contract including: a report transmission unit, so that the blockchain node receives the challenge transaction initiated by the client, and returns the chain to the client
- the remote attestation report of the next private computing node is generated by the authentication server after verifying the self-recommendation information generated by the off-chain private computing node, and the self-recommendation information is consistent with the chain created on the off-chain private computing node.
- the contract acquisition unit enables the blockchain node to receive the encrypted off-chain contract deployment transaction initiated by the client, and decrypt it in the on-chain trusted execution environment to obtain the off-chain
- the bytecode ciphertext contained in the contract deployment transaction is obtained by the client encrypting the bytecode of the off-chain contract
- the off-chain contract deployment transaction is obtained by the client according to
- the remote attestation report is initiated when the off-chain privacy computing node is determined to be trusted
- the contract transmission unit enables the blockchain node to transmit the bytecode ciphertext to the off-chain privacy through the oracle mechanism Computing node, the off-chain private computing node decrypts and deploys the bytecode in the off-chain trusted execution environment; wherein, the blockchain node uses the oracle mechanism to verify the off-chain contract
- the deployed bytecode is executed in the trusted off-chain execution environment, and the execution result is fed back to the blockchain node through the or
- a device for deploying a contract including: a report providing unit, which enables the control node of the off-chain privacy computing cluster to receive the challenge initiated by the client, and from the chain Select an off-chain privacy computing node in the lower privacy computing cluster, and provide the client with a remote attestation report corresponding to the selected off-chain privacy computing node.
- the remote attestation report is verified by the authentication server on the selected off-chain
- the self-recommendation information generated by the private computing node is generated after verification, and the self-recommendation information is related to the off-chain trusted execution environment created on the selected off-chain private computing node; wherein, all the off-chain private computing clusters
- the software and hardware configurations of the off-chain privacy computing nodes are consistent;
- the contract receiving unit enables the control node to receive the bytecode of the off-chain contract encrypted and transmitted by the client, and the bytecode is used by the client according to the
- the remote attestation report is sent when it is determined that the off-chain privacy computing node in the off-chain privacy computing cluster is trusted;
- the contract forwarding unit enables the control node to forward the received bytecode ciphertext to the off-chain
- the bytecode ciphertext can be decrypted by each off-chain private computing node in its own off-chain trusted execution environment to obtain the byte
- a device for deploying a contract including: a verification unit that enables the client to obtain a remote certification report for a private computing node, and the remote certification report is issued by an authentication server
- the self-recommendation information generated by the private computing node is generated after verification, and the self-recommendation information is related to the trusted execution environment created on the private computing node;
- the private computing node is trusted, the bytecode of the smart contract is encrypted and transmitted to the private computing node, and the private computing node decrypts the bytecode in the trusted execution environment and deploys it .
- a device for deploying a contract including: a report providing unit, which enables a private computing node to receive a challenge from a client, and provides a remote attestation report to the client
- the remote attestation report is generated after the authentication server verifies the self-recommendation information generated by the private computing node, and the self-recommendation information is related to the trusted execution environment created on the private computing node;
- the contract receiving unit enables the The privacy computing node receives the bytecode of the smart contract encrypted and transmitted by the client, and the bytecode is sent by the client when it is determined that the privacy computing node is credible according to the remote attestation report; contract deployment Unit to enable the private computing node to decrypt the bytecode in the trusted execution environment, and deploy the bytecode.
- a device for deploying a contract including: a report providing unit, which enables the control node of a privacy computing cluster to receive a challenge initiated by a client, and from the privacy computing cluster A private computing node is selected from within, and a remote certification report corresponding to the selected private computing node is provided to the client.
- the remote certification report is verified by the authentication server after the self-recommended information generated by the selected private computing node Generated, the self-recommendation information is related to the trusted execution environment created on the selected private computing node; wherein the software and hardware configurations of all private computing nodes in the private computing cluster are consistent; the contract receiving unit makes the The control node receives the bytecode of the smart contract encrypted and transmitted by the client, and the bytecode is determined by the client when the private computing node in the private computing cluster is credible according to the remote attestation report.
- the contract forwarding unit enables the control node to forward the received bytecode ciphertext to all private computing nodes in the privacy computing cluster, and the bytecode ciphertext can be sent by each private computing node to itself
- the bytecode is obtained by decrypting in a trusted execution environment, and the bytecode is deployed.
- an electronic device including: a processor; a memory for storing executable instructions of the processor; wherein the processor runs the executable Instructions to implement the method described in the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect, the sixth aspect, or the seventh aspect.
- a computer-readable storage medium which stores computer instructions, and when the instructions are executed by a processor, the first aspect, the second aspect, and the first aspect are implemented.
- this manual implements an off-chain trusted execution environment on off-chain private computing nodes, so that off-chain private computing nodes can provide a safe and reliable operating environment, and the reliability of the off-chain trusted execution environment can be verified by The remote proof is verified, so that the contract can be safely and reliably deployed in the trusted execution environment of the chain, ensuring that the off-chain private computing node securely and faithfully completes the off-chain privacy calculation.
- Fig. 1 is a flowchart of a method for deploying a contract on the client side according to an exemplary embodiment.
- Fig. 2 is a schematic diagram of a scenario for realizing remote certification provided by an exemplary embodiment.
- Fig. 3 is a schematic diagram of another scenario for realizing remote certification provided by an exemplary embodiment.
- Fig. 4 is a schematic diagram of a scenario for deploying an off-chain contract according to an exemplary embodiment.
- Fig. 5 is a schematic diagram of another scenario for deploying an off-chain contract according to an exemplary embodiment.
- Fig. 6 is a schematic diagram of forming a cluster identity between off-chain privacy computing nodes according to an exemplary embodiment.
- Fig. 7 is a schematic diagram of a scenario for invoking an off-chain contract according to an exemplary embodiment.
- Fig. 8 is a flowchart of a method for deploying a contract on the side of an off-chain privacy computing node provided by an exemplary embodiment.
- Fig. 9 is a flowchart of a method for deploying a contract on a blockchain node side according to an exemplary embodiment.
- Fig. 10 is a flowchart of a method for controlling a deployment contract on a node side provided by an exemplary embodiment.
- Fig. 11 is a flowchart of another method for deploying an off-chain contract on the client side according to an exemplary embodiment.
- Fig. 12 is a flowchart of another method for deploying a contract on the side of an off-chain privacy computing node provided by an exemplary embodiment.
- Fig. 13 is a flowchart of another method for controlling a deployment contract on the node side according to an exemplary embodiment.
- Fig. 14 is a schematic structural diagram of a device provided by an exemplary embodiment.
- Fig. 15 is a block diagram of an apparatus for deploying a contract on the client side according to an exemplary embodiment.
- Fig. 16 is a block diagram of a device for deploying a contract on the side of an off-chain privacy computing node provided by an exemplary embodiment.
- Fig. 17 is a block diagram of a device for deploying a contract on a blockchain node side according to an exemplary embodiment.
- Fig. 18 is a block diagram of a device for controlling a deployment contract on the node side according to an exemplary embodiment.
- Fig. 19 is a block diagram of another device for deploying a contract on the client side according to an exemplary embodiment.
- Fig. 20 is a block diagram of another device for deploying a contract on the side of an off-chain privacy computing node provided by an exemplary embodiment.
- Fig. 21 is a block diagram of another device for controlling node-side deployment contracts 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 may include more or fewer steps than described in this specification.
- a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. describe.
- Blockchain is generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
- 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, etc., and each participant (ie, node) can freely join and Exit the network.
- the private chain is the opposite.
- the network's data write permission is controlled by an organization or institution, and the data read permission is regulated by the organization; in simple terms, the private chain can be a weakly centralized system with strict restrictions and few participating nodes.
- consortium chain is a block chain between public chain and private chain, which can realize "partial decentralization".
- Each node in the alliance chain usually has a corresponding entity or organization, and participants are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain.
- blockchain nodes can create a TEE and realize the TEE as a secure execution environment for blockchain transactions.
- TEE is a secure extension based on CPU hardware and a trusted execution environment that is completely isolated from the outside.
- TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications. At present, the industry is very concerned about TEE solutions.
- TEE solutions such as 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), etc.
- Blockchain nodes can create enclaves (enclaves or enclaves) based on SGX technology to serve as TEEs for executing blockchain transactions.
- the blockchain node uses the newly added processor instructions in the CPU to allocate a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) in the memory to reside in the above-mentioned enclave.
- the memory area corresponding to the above EPC is encrypted by the memory encryption engine MEE (Memory Encryption Engine) inside the CPU.
- MEE Memory Encryption Engine
- the content in the memory area can only be decrypted in the CPU core and used for encryption and decryption.
- the key is only generated and stored in the CPU when the EPC is started.
- the security boundary of the enclave only includes itself and the CPU, and neither privileged or non-privileged software can access the enclave, even the operating system administrator and VMM (virtual machine monitor, or Hypervisor).
- VMM virtual machine monitor, or Hypervisor
- Every blockchain transaction on the blockchain needs to be executed on all blockchain nodes in the blockchain network to ensure that each blockchain node is maintained
- the blockchain ledger data is consistent. If the transaction logic is relatively simple, such as Bitcoin as an example, the blockchain transaction is only used to realize the transfer operation. At this time, even if the blockchain transaction needs to be executed on all blockchain nodes, it will not cause excessive resource consumption. . However, if the blockchain provides the function of a smart contract, and the blockchain transaction calls the smart contract, then the situation may be quite different.
- a smart contract on the blockchain is a contract that can be triggered by a transaction to execute on the blockchain system, and the smart contract can be defined in the form of code.
- EVM Ethereum Virtual Machine
- Every Ethereum node can run EVM.
- EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it.
- Users who publish and call smart contracts in Ethereum run on the EVM.
- virtual machine code virtual machine bytecode, hereinafter referred to as "bytecode"
- the smart contract is divided into two stages: deployment and invocation.
- the user sends a transaction containing information about creating a smart contract to the Ethereum network.
- the data field of the transaction contains the code (such as bytecode) of the smart contract, and the to field of the transaction is empty.
- Each node in the Ethereum network executes this transaction through the EVM and generates a corresponding contract instance.
- the smart contract corresponding to the above transaction is successfully created, and a contract account corresponding to the smart contract appears on the blockchain.
- the contract account has a specific contract address and contract code (i.e., smart contract).
- the code) or the hash value of the contract code is stored in the contract account, and the contract code is used to control the behavior of the corresponding smart contract.
- the user (which can be the same or different from the user who deployed the smart contract) sends a transaction for invoking the smart contract to the Ethereum network.
- the from field of the transaction is the address of the external account corresponding to the user, and the to field is The contract address of the smart contract to be called.
- the data field contains the method and parameters for calling the smart contract.
- EVM is a Turing complete virtual machine; similarly, other blockchains can also use other types of virtual machines, such as WASM (WebAssembly) virtual machines.
- WASM WebAssembly
- the process of executing the code of the smart contract by the node through the virtual machine consumes relatively more computing resources, and because all nodes in the blockchain network need The code that executes the smart contract, so as the number of nodes increases, the consumption of computing resources will increase exponentially. Therefore, although the combination of TEE technology can relatively reduce the resource consumption of a single blockchain node and speed up transaction execution efficiency, it will still cause great resource consumption and waste for the entire blockchain network.
- this manual proposes to deploy private computing nodes (ie, off-chain private computing nodes) under the chain, which can transfer the computing operations that originally needed to be performed on all blockchain nodes to the off-chain private computing nodes for execution.
- the chain node only needs to obtain the calculation result from the off-chain private computing node and update the blockchain ledger data based on the calculation result, and can prove that the above calculation result is indeed in a credible execution based on the verifiable computation (Verifiable Computation) technology
- the environment is executed as expected, which greatly reduces the resource consumption on the chain while ensuring reliability.
- the blockchain node can execute the code of the smart contract to achieve corresponding computing requirements; similarly, the code for performing computing tasks can be deployed off-chain
- the off-chain private computing node can execute code to achieve corresponding computing requirements.
- the contract deployed on the blockchain node is called the on-chain contract
- the contract deployed on the off-chain privacy computing node is called the off-chain contract; of course, whether it is an on-chain contract or an off-chain contract, Its essence is a piece of code that can be executed in a virtual machine.
- Fig. 1 is a flowchart of a method for deploying a contract on the client side according to an exemplary embodiment. As shown in FIG. 1, the method may include step 102 to step 104.
- Step 102 The client obtains a remote certification report for the off-chain private computing node.
- the off-chain TEE created on the off-chain private computing node is similar to the on-chain TEE created on the blockchain node described above, and is based on a trusted execution environment that is completely isolated from the outside and implemented by CPU hardware.
- the off-chain privacy computing node can implement the deployment operation of the off-chain contract and the call execution operation after deployment through the off-chain TEE, and ensure data security and privacy protection during the operation.
- the remote attestation report is generated from the remote attestation process for the off-chain TEE on the off-chain private computing node.
- the remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the off-chain private computing node, and the self-recommended information is related to the off-chain TEE created on the off-chain private computing node.
- the off-chain private computing node generates the self-recommended information related to the off-chain TEE, and the authentication server verifies the self-recommended information to generate a remote attestation report, so that the remote attestation report can be used to indicate the off-chain TEE on the off-chain private computing node Trustworthy.
- the off-chain TEE is an enclave created on the off-chain private computing node to realize off-chain privacy computing.
- the remote attestation process also involves another special enclave on the off-chain private computing node, namely Quoting enclave (QE for short), QE is an architectural enclave (Architectural Enclave) provided and signed by Intel.
- the above enclave first needs to generate a REPORT structure for local authentication, and QE verifies whether the enclave is on the same platform as itself based on the REPORT structure, and then QE encapsulates the REPORT structure into a structure QUOTE (ie Self-recommended information), and use the EPID (enhanced privacy identification) key to sign.
- the EPID key not only represents the platform of the off-chain private computing node, but also represents the credibility of the underlying hardware of the off-chain private computing node. It can also bind information such as the version of the processor firmware, and only QE can access the EPID key. , To sign the above-mentioned structure QUOTE.
- the above authentication server can be the IAS (Intel Attestation Service) server provided by Intel.
- the off-chain privacy computing node sends the signed structure QUOTE to the IAS server, so that the IAS server can verify the signature and Return the corresponding remote certification report to the off-chain privacy computing node.
- the client can initiate a challenge to the off-chain private computing node and receive the remote attestation report returned by the off-chain private computing node.
- the client can initiate an off-chain challenge to the off-chain private computing node, that is, the process of initiating the challenge has nothing to do with the blockchain network, so that the consensus process between blockchain nodes can be skipped and the interaction between on-chain and off-chain can be reduced. , So that the client's challenge to the off-chain private computing node has a higher operational efficiency.
- the client can take the form of an on-chain challenge.
- the client can submit a challenge transaction to a blockchain node.
- the challenge information contained in the challenge transaction can be transmitted by the blockchain node to the off-chain private computing node through the oracle mechanism.
- the challenge information is used to initiate a challenge to the off-chain private computing node.
- the client 21 can directly initiate a challenge to the off-chain private computing node 22 through an off-chain channel, that is, the client 21 initiates an off-chain challenge to the off-chain private computing node 22.
- the client 21 may initiate a challenge to the off-chain private computing node 22 through the blockchain network 23, that is, the client 21 initiates an on-chain challenge to the off-chain private computing node 22.
- the initiation process of an on-chain challenge can include three steps: Step 1, the client 21 submits a transaction for initiating a challenge to the blockchain network 23, such as a challenge transaction, which can be used by the blockchain network 23 A certain node 23n within the network receives and executes; step 2, node 23n calls the pre-deployed oracle smart contract (referred to as the oracle contract), which can transmit the challenge information contained in the above-mentioned challenge exchange to the off-chain prediction
- the oracle server 24, for example, the oracle contract can generate events containing the challenge information, and the oracle server 24 can obtain the above-mentioned challenge information by monitoring the events generated by the oracle contract; step 3, the oracle server 24 passes the challenge information through The off-chain channel is sent to the off-chain privacy computing node 22.
- the client 21 When the client 21 initiates a challenge to the off-chain private computing node 22 through the on-chain channel, it involves the data interaction between the blockchain network 23 and the off-chain private computing node 22, that is, the data interaction on and off the chain.
- the interaction process can be realized by the oracle contract and the oracle server 24 through the aforementioned step 2.
- the coordination mechanism between the oracle contract and the oracle server 24 is the oracle mechanism.
- the transaction submitted by the client 21 to the node 23n should directly or indirectly call the aforementioned oracle contract to trigger the oracle mechanism.
- the contract address of the oracle contract is filled in the to field of the transaction, it indicates that the transaction directly calls the oracle contract; if the contract address of a certain chain contract is filled in the to field of the transaction, and the chain is on The contract calls the oracle contract, indicating that the transaction indirectly calls the oracle contract.
- the contract on the chain calls the oracle contract.
- the contract address of the oracle contract is pre-written in the bytecode of the on-chain contract.
- the contract address of the oracle contract can be used as the call. Enter the parameters of the contract on the chain, and fill the entered parameters into the data field of the above transaction.
- the oracle mechanism can also transmit data from the chain to the chain.
- the oracle server 24 can transmit the data to the oracle contract, and then the oracle server 24 can transmit the data to the oracle contract.
- the contract transmits off-chain data to the data demander.
- the off-chain data here can include remote certification reports or privacy calculation results generated by invoking the off-chain contract.
- transferring data from the chain to the chain can be regarded as a "request” process, and transferring data from the chain to the chain can be regarded as a "response” process. These two processes usually appear in pairs. .
- the off-chain private computing node can temporarily trigger the remote attestation process as described above and generate the corresponding remote attestation report, and then report the remote attestation Feedback to the client. Or, when the off-chain private computing node receives a challenge initiated by the client, if a pre-generated remote attestation report already exists locally, the off-chain private computing node provides the remote attestation report to the client without temporarily triggering remote attestation process. Among them, the remote attestation report of the off-chain private computing node can be triggered by the off-chain private computing node in response to the challenge of other challengers except the client.
- the other challenger may include other clients, This manual does not limit the control node and KMS server in the off-chain privacy computing cluster where the off-chain privacy computing node is located. Therefore, after receiving the challenge initiated by the client, the off-chain private computing node can first check whether there is a previously generated remote attestation report locally, and if there is, the remote attestation report is fed back to the client, otherwise the remote attestation process is temporarily triggered. Among them, the remote attestation report can have a certain time limit, such as 30 minutes or other duration. The timed out remote attestation report can be deemed invalid by the client, and the off-chain privacy computing node can also actively clear the invalid remote attestation report to avoid feedback To the client.
- the data interaction involved may include: data interaction between the client 21 and the off-chain private computing node 22 (the client 21 initiates an off-chain challenge to the off-chain private computing node 22, The lower privacy computing node 22 returns a remote certification report to the client 21), the data interaction between the client 21 and the node 23n (the client 21 sends a challenge transaction to the node 23n, and the node 23n returns a remote certification report to the client 21), the node Data interaction between 23n and the oracle server 24 (the oracle server 24 reads the challenge information from the node 23n, the oracle server 24 feeds back the remote certification report to the node 23n), between the oracle server 24 and the off-chain privacy computing node 22 Data interaction (the oracle server 24 sends challenge information to
- the data transmitted between the data sender and the data receiver may leak, and the node 23n will link the challenge transaction to the chain to cause the challenge transaction to be disclosed, so the data can be exchanged
- the method of encrypted transmission avoids information leakage.
- the client 21 Take the client 21 submitting a challenge transaction to the node 23n as an example.
- an on-chain challenge is initiated to the off-chain private computing node 22, so that the node 23n can perform a consensus on the challenge transaction submitted by the client 21 with other nodes and then upload it to the chain to record the challenge behavior of the client 21.
- the challenge transaction can be protected for privacy.
- the client 21 can encrypt the challenge transaction, and the node 23n can receive the encrypted challenge transaction, which can ensure that the content of the challenge transaction will not be leaked during the transmission process.
- the on-chain TEE can be deployed at the node 23n, and the node 23n can read the encrypted challenge transaction into the on-chain TEE and decrypt it in the on-chain TEE to ensure that the decrypted challenge transaction only exists in the on-chain TEE. It will leak.
- Node 23n directly uploads encrypted challenge transactions to the chain and manages the viewing authority of encrypted data to limit users who can view challenge transactions, while other users can only obtain encrypted challenge transactions when viewing blockchain data directly .
- the node 23n can ensure that the data that needs privacy protection can only be decrypted into plaintext form in the on-chain TEE, and once it leaves the on-chain TEE, all are in ciphertext form.
- the form of symmetric encryption or asymmetric encryption can be adopted.
- the client 21 and the node 23n maintain the same symmetric key respectively.
- the symmetric key can be used by the client 21 and the node 23n through DH (Diffie-Hellman) or ECDH (Elliptic Curve Diffie-Hellman). It is obtained through negotiation of other algorithms, or distributed by a KMS (Key Management Service) server to the client 21 and the node 23n. This specification does not limit the source of the key.
- the KMS server can confirm that the TEE on the chain at node 23n is trustworthy through remote attestation, and then encrypt the key and transmit it to the TEE on the chain.
- the remote attestation method is paired with the client 21
- the remote certification process of the off-chain privacy computing node 22 is similar, and will not be repeated here.
- the client 21 can encrypt the challenge transaction through the above-mentioned symmetric key, and the node 23n maintains the symmetric key in the on-chain TEE, and thus reads the encrypted challenge transaction into the on-chain TEE, and passes the symmetric key.
- the key performs a decryption operation to obtain the above-mentioned challenge transaction.
- the encryption algorithm used by the symmetric encryption may include, for example, the DES algorithm, the 3DES algorithm, the TDEA algorithm, the Blowfish algorithm, the RC5 algorithm, and the IDEA algorithm.
- the node 23n When asymmetric encryption is used, the node 23n maintains a private key with an asymmetric key, such as a node private key, and the client 21 can obtain the node public key corresponding to the node private key.
- the asymmetric key can be generated by the node 23n in the TEE on the chain, or distributed to the node 23n by the KMS server. This specification does not limit the source of the key.
- the KMS server can determine the trustworthiness of the TEE on the chain at the node 23n by means of remote certification, and then encrypt and transmit the key to the TEE on the chain.
- the client 21 can encrypt the challenge transaction through the node public key, and the node 23n maintains the node private key in the on-chain TEE, and thus reads the encrypted challenge transaction into the on-chain TEE and executes it through the node’s private key.
- the decryption operation obtains the above-mentioned challenge transaction.
- the asymmetric encryption algorithm used in the asymmetric encryption may include, for example, RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), etc.
- a combination of symmetric encryption and asymmetric encryption can also be used.
- the client 21 can maintain a symmetric key.
- the symmetric key can be randomly generated by the client 21, and the client 21 can obtain the public key in the aforementioned asymmetric key.
- the client 21 can encrypt the challenge transaction with the symmetric key, obtain the encrypted challenge transaction, and encrypt the symmetric key with the asymmetric key to obtain the encrypted key, and then the client 21 simultaneously encrypts the encrypted challenge transaction with the encrypted challenge transaction. Then the key is transmitted to the node 23n.
- the node 23n reads the encrypted challenge transaction and the encrypted key into the TEE on the chain, first decrypts the encrypted key with the node's private key to obtain the symmetric key, and then encrypts the challenge transaction with the symmetric key Decrypt.
- the encryption and decryption efficiency of symmetric encryption is relatively higher, but the security is relatively low, while the encryption and decryption efficiency of asymmetric encryption is relatively low, but the security is relatively higher. Therefore, based on the comparison between symmetric encryption and asymmetric encryption The combined form can take into account the efficiency and security of encryption and decryption.
- the data sender and the data receiver maintain the same symmetric key, or the data sender maintains the public key of the asymmetric key, and the data receiver maintains the non-symmetric key.
- the private key of the symmetric key, or the combination of symmetric encryption and asymmetric encryption can realize the encrypted transmission of data between any data sender and data receiver, which will not be repeated here.
- An off-chain private computing node may belong to an off-chain private computing cluster, and the off-chain private computing cluster includes multiple off-chain private computing nodes. If the privacy computing nodes under each chain are completely independent, then the interaction process between the client and a single privacy computing node under the chain can refer to the above-mentioned embodiments.
- the off-chain privacy computing cluster may include a control node, and the control node will uniformly manage all off-chain privacy computing nodes in the cluster. For example, the client can initiate a challenge to the control node, and receive the remote certification report of the off-chain privacy computing node returned by the control node.
- the client can initiate an off-chain challenge to the control node, or the client can submit a challenge transaction to the blockchain node, and the challenge information contained in the challenge transaction is transmitted by the blockchain node through the oracle mechanism To the control node, the control node returns the remote certification report of the off-chain privacy computing node to the client.
- the client 31 can directly initiate a challenge to the control node 32 through an off-chain channel, that is, the client 31 initiates an off-chain challenge to the control node 32.
- the client 31 may initiate a challenge to the control node 32 through the blockchain network 33, that is, the client 31 initiates an on-chain challenge to the control node 32.
- the process of initiating a challenge on the chain can include three steps: Step 1, the client 31 submits a transaction for initiating a challenge to the blockchain network 33, such as a challenge transaction, which can be used by the blockchain network 33 A certain node 33n in the network receives and executes; step 2, node 33n invokes the pre-deployed oracle smart contract (referred to as the oracle contract), which can transmit the challenge information contained in the above-mentioned challenge exchange to the off-chain prediction
- the oracle server 34 for example, the oracle contract can generate events containing the challenge information, and the oracle server 34 can obtain the above-mentioned challenge information by monitoring the events generated by the oracle contract; step 3, the oracle server 34 passes the challenge information through The off-chain channel is sent to the control node 32.
- the challenge target can be set to a certain off-chain private computing node in the cluster where the control node 32 is located, such as off-chain private computing node 32n, then the control node 32 will receive The challenge is to return the remote certification report corresponding to the off-chain privacy computing node 32n to the client 31.
- the client 31 may not set a challenge target.
- the control node 32 selects from the off-chain private computing cluster. For example, when the off-chain private computing node 32n is selected, the client 31 returns the The remote attestation report corresponding to the off-chain privacy computing node 32n.
- control node 32 after the control node 32 receives the challenge initiated by the client 31, it can forward the challenge to the off-chain privacy computing node 32n, so that the off-chain privacy computing node 32n temporarily triggers the remote attestation process to generate a corresponding remote attestation report. Then feedback to the client 31 through the control node 32.
- the control node 32 after the control node 32 receives the challenge initiated by the client 31, it can forward the challenge to the off-chain privacy computing node 32n, and if the off-chain privacy computing node 32n already has a pre-generated remote attestation report, then the off-chain The privacy computing node 32n returns the remote certification report to the control node 32, and the control node 32 provides it to the client 31 without temporarily triggering the remote certification process.
- the off-chain private computing node 32n provides the remote certification report to The client 31 does not need to forward the challenge to the off-chain private computing node 32n, nor does it need the off-chain private computing node 32n to temporarily trigger the remote attestation process.
- the remote attestation report locally existing in the off-chain private computing node 32n may be triggered by the off-chain private computing node 32n in response to a challenge from a challenger other than the client 31.
- the other challenger may include other challengers.
- the client, control node 32, KMS server, etc. are not restricted in this specification.
- the control node 32 can cache the received remote certification report. Therefore, after the control node 32 receives the challenge initiated by the client 31, it can first check whether there is a previously obtained remote attestation report locally, and if there is, the remote attestation report will be fed back to the client 31, otherwise the challenge will be forwarded to the chain.
- the off-chain private computing node 32n can first check whether there is a previously obtained remote certification report locally, if it exists, the remote certification report will be fed back to the control node 32, otherwise temporarily Trigger the remote attestation process.
- the remote attestation report may have a certain time limit, such as 30 minutes or other duration. The timed out remote attestation report can be deemed invalid by the client 31, and the control node 32 or the off-chain privacy computing node 32n can also actively clear the invalid Remote attestation report to avoid feedback to client 31.
- Step 104 When the client determines that the off-chain private computing node is credible according to the remote certification report, the client encrypts the bytecode of the off-chain contract and transmits it to the off-chain private computing node.
- the off-chain private computing node decrypts the bytecode in the off-chain trusted execution environment and deploys it.
- the client can verify whether the corresponding off-chain private computing node is credible according to the remote attestation report, specifically whether the off-chain TEE deployed on the off-chain private computing node is available letter.
- the off-chain private computing node creates the off-chain TEE, it generates self-recommendation information for remote attestation.
- This self-recommendation information can be used to anchor and solidify the information of the off-chain TEE, so that the final result contains the self-recommendation information
- the remote attestation report can be used to characterize the status of the off-chain TEE and to verify whether the off-chain TEE is trustworthy.
- the self-recommendation information may include the first hash value to be verified, and the first hash value to be verified is the hash value of the preset information of the off-chain TEE.
- the preset information may include all the deployed in the off-chain TEE.
- the code, the public key of the developer of the TEE under the chain, etc. Taking Intel SGX technology as an example, the hash value generated by all codes deployed in the off-chain TEE is MREnclave, and the hash value generated by the developer’s public key corresponding to the off-chain TEE is MRSigner, which is the first waiting
- the verification hash value can include MREnclave and MRSigner.
- the IAS server performs signature verification based on the maintained public key set, and returns a remote certification report (that is, AVR) to the off-chain privacy computing node.
- Report contains: the structure QUOTE and the signature verification result, and the IAS server uses its own private key to sign the remote attestation report.
- the client can first perform signature verification on the remote attestation report according to the public key of the IAS server. If the verification is passed, it indicates that the remote attestation report is indeed generated by the IAS server and is in the process of data transmission. No data has been tampered with or lost.
- the client can obtain the public key of the IAS server through any means. For example, when a remote attestation report is provided to the client, it can also be associated with the certificate chain that provides the IAS, so that the client can extract the public key of the IAS server from the certificate chain. Then, the client can extract the structure QUOTE and the signature verification result from the remote attestation report. The client can first view the signature verification result.
- the off-chain TEE is established on a reliable hardware platform and can continue to perform other operations. Verification operation: If the signature verification result is that the verification is not passed, the client can determine that the off-chain privacy computing platform is unreliable, and there is no need to continue other verification operations.
- the client can extract the above-mentioned hash values MREnclave and MRSigner from the structure QUOTE, that is, the MREnclave to be verified and the MRSigner to be verified; at the same time, the client obtains the trusted value of the MREnclave and MRSigner of the off-chain TEE in advance, for example, These are the trusted MREnclave and the trusted MRSigner.
- the MREnclave to be tested is compared with the trusted MRSigner, and the MRSigner to be tested is compared with the trusted MRSigner.
- the client can use "the MREnclave to be tested is consistent with the trusted MREnclave, and the MRSigner to be tested is consistent with the trusted MRSigner" as a prerequisite for confirming the trustworthiness of the private computing node under the chain; in other words, if the MREnclave to be tested is inconsistent with the trusted MREnclave , Or if the MRSigner to be verified is inconsistent with the trusted MRSigner, the client determines that the off-chain private computing node is not trusted, and if all the preconditions set by the client are met, it can confirm that the off-chain private computing node is trusted. In addition, there is no inevitable sequence between the operation of the client to verify the signature verification result and the verification of the MREnclave to be verified and the MRSigner to be verified, and the two can be completely independent.
- the client can also verify the credibility of the off-chain private computing node through other preconditions. For example, after an off-chain private computing node creates an off-chain TEE, it can generate a key pair representing its own identity information in the off-chain TEE, and the off-chain private computing node creates its own node identity information in the off-chain TEE.
- the node identity information is related to the above-mentioned key pair corresponding to the identity information.
- the node identity information may include the public key in the key pair.
- the key pair representing the identity information can exist in one or more groups.
- the node identity information may include the signature public key in the signature key pair and the encryption public key in the encryption key pair. In a set of key pairs, corresponding to different encryption algorithms, there may be multiple public keys at the same time, and these public keys are all included in the above-mentioned node identity information.
- the node identity information may also include other information related to the off-chain private computing node, such as software version, domain name, partition name, etc. This specification does not limit this. Then, when the off-chain privacy computing node generates the structure QUOTE, it can calculate the hash value of the node identity information, and add the hash value to the structure QUOTE as the second hash value to be verified.
- the client can perform signature verification from the remote certification report.
- the client can extract the signature verification result and the second to-be-verified hash value contained in the remote certification report, and verify them separately, and there is no inevitable sequence for the verification of the two. They can be completely independent. It is assumed that the client first verifies the signature verification result, and continues to verify the second hash value to be verified if the signature verification result is passed verification. In order to verify the second hash value to be verified, the client needs to obtain the node identity information of the off-chain private computing node.
- the node identity information can be associated and provided, of course, the client can also pass Obtain the node's identity information in other ways or at other times. Then, the client can perform a hash calculation on the obtained node identity information, compare the calculated hash value with the above-mentioned second hash value to be verified, and use the same comparison result as a confirmation that the off-chain privacy computing node is trusted Prerequisites. If the second hash value to be verified is verified, it can be proved that the identity information of the off-chain private computing node is initialized and generated in the off-chain TEE, and the private key in the key pair representing the identity information is only owned by the off-chain private computing node. Owned, and the private computing node under the chain can complete operations such as signing and encrypting communication.
- the above judgment conditions can be selected.
- the first hash value to be verified and the second hash value to be verified can be verified at the same time; or, in some cases, only the second hash value to be verified can be verified, and the first hash value to be verified No verification or partial verification is possible.
- the client can set a trust level, and determine whether to verify or partially verify the first hash value to be verified according to the trust level.
- the trust level is 0, there is no need to verify the first hash value to be verified, and the trust level is 1.
- verifying the MRSigner in the first hash value to be verified and when the trust level is 2, verify the MEnclave in the first hash value to be verified.
- the node identity information includes information related to the identity of the off-chain private computing node, such as a public key representing the identity.
- the node identity information can also include information related to the off-chain TEE.
- the node identity information can also contain the values of MREnclave and MRSigner, so that the hash value to be verified obtained by hashing the identity information of the node can be combined with the off-chain
- the identity of the private computing node is related to the off-chain TEE.
- the client can perform signature verification from the remote certification report.
- the client can extract the signature verification result and the hash value to be verified contained in the remote certification report, and verify them separately, and there is no inevitable sequence for the verification of the two.
- the room can be completely independent.
- the client first verifies the signature verification result, and continues to verify the hash value to be verified if the signature verification result is passed verification.
- the client needs to obtain the node identity information of the off-chain private computing node, which will not be repeated here. Then, the client can perform a hash calculation on the obtained node identity information, compare the calculated hash value with the above-mentioned hash value to be verified, and use the consistency of the comparison result as a prerequisite to confirm the trustworthiness of the off-chain private computing node condition. It can be seen that this embodiment only needs one comparison to realize the verification in the two aspects mentioned above, which helps to improve the verification efficiency.
- the client's verification process of the remote attestation report can also include other operations, such as determining whether the off-chain TEE is running in test mode (there is a risk of data leakage in test mode) based on the content of the remote attestation report, etc., here is no longer one by one Go into details.
- the client can deploy an off-chain contract to the off-chain private computing node when it is determined that the off-chain private computing node is trustworthy.
- the off-chain contract is similar to the on-chain contract executed by the blockchain node, and both can be bytecodes running in a virtual machine, so I won’t repeat them here.
- By encrypting and transmitting the bytecode of the off-chain contract data leakage or modification can be avoided during the transmission process, and privacy and security can be ensured.
- the client can encrypt and transmit the bytecode of the off-chain contract to the off-chain private computing node through the off-chain channel, that is, the transmission process for the bytecode has nothing to do with the blockchain network, so that it can be Skip the consensus process between blockchain nodes and reduce the interactive operations on and off the chain, making bytecode transmission more efficient.
- the client can encrypt and transmit the bytecode of the off-chain contract to the off-chain private computing node through the on-chain channel.
- the client generates an off-chain contract deployment transaction, and the off-chain contract deployment transaction includes the encryption of the bytecode.
- the obtained bytecode ciphertext the client encrypts the off-chain contract deployment transaction and submits it to the blockchain node.
- the encrypted off-chain contract deployment transaction can be decrypted and obtained in the on-chain TEE created at the blockchain node.
- the bytecode ciphertext is then transmitted to the off-chain privacy computing node by the blockchain node through the oracle mechanism.
- the client 41 can directly transmit the bytecode encrypted to the off-chain privacy computing node 42 through the off-chain channel, that is, the client 41 transmits the encrypted bytecode ciphertext to the off-chain privacy computing node 42 off-chain.
- the client 41 can transmit the bytecode encrypted to the off-chain privacy computing node 42 through the blockchain network 43, that is, the client 41 transmits the encrypted bytecode encryption to the off-chain privacy computing node 42 on the chain.
- the process of encrypted transmission on the chain can include three steps: Step 1, the client 41 submits a transaction for deploying an off-chain contract to the blockchain network 43, that is, an off-chain contract deployment transaction.
- the off-chain contract deployment transaction can be A certain node 43n in the blockchain network 43 receives and executes; step 2, node 43n calls the oracle contract, which can transfer the bytecode contained in the above-mentioned off-chain contract deployment transaction to the off-chain oracle
- the server 44 for example, the oracle contract can generate an event containing the bytecode, and the oracle server 44 can obtain the aforementioned bytecode by listening to the event generated by the oracle contract; step 3, the oracle server 44 transfers the bytecode
- the code is sent to the off-chain privacy computing node 42 through the off-chain channel.
- the off-chain encrypted transmission In the process of off-chain encrypted transmission, only the data interaction between the client 41 and the off-chain private computing node 42 is involved.
- the symmetric encryption, asymmetric encryption, or a combination of the two encryption transmission schemes described above can be used. I won't repeat them here.
- the process of encrypted transmission on the chain data interaction between multiple objects is involved, and it is necessary to ensure that the bytecode is always in an encrypted state.
- the client 41 submits an off-chain contract deployment transaction to the node 43n
- the off-chain contract deployment transaction can be encrypted and transmitted through the encrypted transmission scheme of symmetric encryption, asymmetric encryption, or a combination of the two as described above, so that The bytecode contained in the off-chain contract deployment exchange is encrypted and protected.
- the bytecode contained in the off-chain contract deployment exchange may be in a plaintext state or a ciphertext state. If it is in the ciphertext state, it means that after the client 41 encrypts the bytecode, it adds the bytecode ciphertext to the data field of the off-chain contract deployment transaction, and the client 41 should ensure that the bytecode ciphertext is only the final link
- the off-chain privacy computing node 42 can decrypt, but the other nodes 43n, oracle server 44 cannot decrypt, then the node 43n decrypts the off-chain contract deployment transaction in the on-chain TEE created by itself to obtain the bytecode secret
- the oracle server 44 can directly read the bytecode ciphertext, and then the oracle server 44 transmits the bytecode ciphertext to the off-chain privacy computing node 42.
- the client 41 directly adds the bytecode of the clear text to the data field of the off-chain contract deployment transaction, and the off-chain contract deployment transaction can call an on-chain contract, then the node 43n will perform the pairing in the on-chain TEE.
- the virtual machine deployed in the on-chain TEE can execute the above-mentioned on-chain contract, thereby encrypting the bytecode into the corresponding bytecode in the on-chain TEE And ensure that the bytecode ciphertext can only be decrypted by the off-chain privacy computing node 42, and then the oracle server 44 reads the bytecode ciphertext, and then transmits the bytecode ciphertext to the off-chain Privacy computing node 42.
- symmetric encryption When encrypting bytecode, symmetric encryption, asymmetric encryption or a combination of the two can be used, and this specification does not limit this.
- asymmetric encryption or a combination of symmetric encryption and asymmetric encryption When asymmetric encryption or a combination of symmetric encryption and asymmetric encryption is used, a set of asymmetric key pairs is involved, and the client 41 or node 43n needs to know the public key of the asymmetric key pair, and the asymmetric encryption The private key of the key pair needs to be maintained by the off-chain privacy computing node 42 so that the off-chain privacy computing node 42 can decrypt the received bytecode cipher text based on the private key.
- the asymmetric key pair may be the aforementioned encryption key pair generated by the off-chain privacy computing node 42 in the off-chain TEE; accordingly, the off-chain privacy computing node 42 receives the bytecode ciphertext Afterwards, the bytecode ciphertext is read into the off-chain TEE, and the bytecode ciphertext is decrypted based on the encrypted private key to obtain the bytecode of the plaintext.
- the off-chain privacy computing node 42 After the off-chain privacy computing node 42 decrypts the plaintext bytecode in the off-chain TEE, it can re-encrypt the bytecode in the off-chain TEE and store it in a storage space outside the off-chain TEE, such as off-chain privacy In the hard disk of the computing node 42, the deployment of the off-chain contract is thus completed.
- the off-chain privacy computing node 42 usually uses a symmetric key to encrypt the bytecode and store it in a symmetric encryption manner, so that when the bytecode is subsequently called, compared to the form of asymmetric encryption. In other words, the decryption operation can be completed faster.
- the symmetric key can be generated by the off-chain privacy computing node 42 in the off-chain TEE, or distributed to the off-chain privacy computing node 42 by other objects through encrypted transmission.
- the KMS server can initiate a challenge to the off-chain private computing node 42 and distribute the above-mentioned symmetric key to the off-chain private computing node 42 under the condition that the authenticity of the off-chain private computing node 42 is verified through remote certification.
- the off-chain privacy computing node 42 may use the symmetric key distributed by the KMS server as the root key, and apply the derived key derived from the root key to the encrypted storage of the bytecode.
- the above-mentioned symmetric key can be an RSK (Root Seal Key) key burned in the e-fuses storage circuit in the CPU of the privacy computing node 42 under the chain, or derived from the RSK key Derived key (ie Seal Key).
- RSK Root Seal Key
- the off-chain privacy computing node 42 can also use asymmetric encryption or a combination of symmetric encryption and asymmetric encryption to encrypt and store the bytecode, which is not limited in this specification.
- the client 41 can also indicate to the off-chain private computing node 42 an execution engine for executing the bytecode.
- an execution engine for executing the bytecode.
- several execution engines such as one or more of EVM, WASM virtual machine, etc., can be deployed, especially when multiple execution engines are deployed at the same time
- the client 41 can send the execution engine designation information associated with the above-mentioned bytecode to the off-chain private computing node 42.
- the execution engine designation information indicates to the off-chain private computing node 42 the execution engine used to execute the above-mentioned bytecode.
- the bytecode and the execution engine specified information can be packaged and encrypted, and then transmitted to the off-chain privacy computing node 42; or the bytecode and execution engine specified information can be encrypted and transmitted separately.
- the execution engine specified information should be Contains the corresponding bytecode or information of the off-chain contract, such as the hash value of the bytecode, so as to determine which off-chain contract the execution engine specified information corresponds to.
- the off-chain privacy computing node 42 deploys an off-chain contract, in addition to encrypting and storing the bytecode, it also needs to mark the information of the execution engine that the bytecode needs to use, so that it can be used in subsequent calls. Based on this, an appropriate virtual machine is selected as the execution engine for processing the corresponding bytecode.
- the client 41 can deploy more off-chain contracts to the off-chain privacy computing node 42; similarly, other clients can also deploy off-chain contracts to the off-chain privacy computing node 42.
- the off-chain privacy computing node 42 may generate a corresponding contract ID for the deployed off-chain contract, and there is a one-to-one correspondence between the off-chain contract and the contract ID. For example, after completing the deployment operation for the off-chain contract, the off-chain privacy computing node 42 may perform a hash operation on the bytecode of the off-chain contract to obtain the first hash value, and use the first hash value as The contract ID of the off-chain contract.
- the off-chain privacy computing node 42 can also generate the contract ID in other ways, and this specification does not limit this.
- the first hash value may also have other functions.
- the off-chain privacy computing node 42 can feed back the deployment result information to the client 41.
- the deployment result information includes the above-mentioned first hash value, and the client 41 can also hash the bytecode sent by itself.
- the second hash value is calculated, and the first hash value is compared with the second hash value: if the two are the same, it indicates that the bytecode deployed by the off-chain privacy computing node 42 is correct and has not been transmitted during transmission.
- the client 41 can confirm that the off-chain contract is successfully deployed at the off-chain privacy computing node 42; and if the two are inconsistent, the client 41 can think that the off-chain contract deployment failed, or the deployed off-chain contract exists risk.
- the client 41 may mark the successfully deployed off-chain contract as a trusted contract, and the unsuccessfully deployed off-chain contract as an untrusted contract or unmaintained, so that in the subsequent process, only the trusted contract is called.
- the off-chain privacy computing node 42 If the client 41 transmits the bytecode to the off-chain privacy computing node 42 through the off-chain channel, the off-chain privacy computing node 42 also returns the deployment result information to the client 41 through the off-chain channel; if the client 41 sends the byte code The code is transmitted to the off-chain privacy computing node 42 through the on-chain channel, and then the off-chain privacy computing node 42 also feeds back the deployment result information to the client 41 through the on-chain approach.
- the off-chain private computing node can belong to the off-chain private computing cluster. If each off-chain private computing node is completely independent, then the client will interact with each off-chain private computing node and implement the deployment operation of the on-chain contract, and the client will interact with each off-chain private computing node. Refer to the embodiment shown in FIG. 4 for the interaction process, which will not be repeated here. In another way, the control node manages all the off-chain privacy computing nodes in the cluster in a unified manner.
- the client first encrypts the bytecode and transmits it to the control node, and then the control node The node forwards to one or more off-chain privacy computing nodes in the cluster, thereby deploying the bytecode of the on-chain contract to one or more off-chain privacy computing nodes in the cluster.
- these off-chain private computing nodes can provide the ability to call the same off-chain contract at the same time, so as to realize parallel off-chain private computing, and it can also be used in multiple off-chain private computing nodes. Achieve load balancing between.
- the client 51 can directly send the bytecode ciphertext to the control node 52 through the off-chain channel, that is, the client 51 encrypts and transmits the bytecode under the chain to the control node 52, and then forwards the bytecode to the cluster by the control node 52 One or more private computing nodes under the chain.
- the client 51 can transmit the bytecode encrypted to the control node 52 through the blockchain network 53, that is, the client 51 transmits the encrypted bytecode ciphertext to the control node 52 on the chain.
- the process of encrypted transmission on the chain can include three steps: Step 1, the client 51 submits to the blockchain network 53 a transaction for deploying an off-chain contract, that is, an off-chain contract deployment transaction.
- the off-chain contract deployment transaction can be A certain node 53n in the blockchain network 53 receives and executes; step 2, the node 53n calls the oracle contract, which can transfer the bytecode contained in the above-mentioned off-chain contract deployment transaction to the off-chain oracle
- the server 54 for example, the oracle contract can generate an event containing the bytecode, and the oracle server 54 can obtain the above bytecode by listening to the event generated by the oracle contract; step 3, the oracle server 54 transfers the bytecode
- the code is sent to the control node 52 through the off-chain channel, and then forwarded by the control node 52 to one or more off-chain privacy computing nodes in the cluster.
- the client 51 or node 53n is encrypting the bytecode
- the encryption public key generated by the off-chain privacy computing node 52n in the off-chain TEE can be used to encrypt the bytecode
- the off-chain privacy computing node 52n can use the off-chain TEE after receiving the bytecode ciphertext.
- the bytecode ciphertext is decrypted by encrypting the private key to obtain the bytecode of the plaintext.
- the client 51 can carry deployment target indication information, and the control node 52 can determine that the corresponding deployment target is the off-chain privacy computing node 52n according to the deployment target indication information, so as to accurately forward the bytecode ciphertext to the off-chain privacy computing Node 52n does not need to be forwarded to other off-chain privacy computing nodes in the cluster. If the client 51 does not carry the deployment target indication information, the control node 52 can forward the bytecode ciphertext to all the off-chain private computing nodes in the cluster, but only the off-chain private computing node 52n can successfully decrypt and complete the deployment.
- each off-chain private computing node has its own node identity information, and the node identity information relates to the key pair created by each off-chain private computing node in its respective off-chain TEE, such as an encryption key Pair and signature key pair, or a key pair that takes into account both encryption and signature functions.
- the encryption key pair and the signature key pair takes the encryption key pair and the signature key pair as an example for description.
- the cluster identity information can include a cluster encryption key pair and a cluster signature key pair.
- Each of the above-mentioned privacy computing nodes under the chain needs to maintain the cluster encryption private key and the cluster signature private key in their respective chain TEEs, then the client 51 or As long as the node 53n uses the cluster encryption public key to encrypt the bytecode, it can ensure that all the above-mentioned off-chain privacy computing nodes can decrypt with the cluster encryption private key in their respective off-chain TEEs, thereby obtaining the bytecode and completing deploy.
- the above-mentioned cluster encryption public key can also be used to encrypt the bytecode, as long as the corresponding off-chain private computing node can successfully decrypt it.
- the client 51 does not need to pay attention to whether the other party is a single off-chain private computing node or off-chain private computing cluster. It only needs to use it as an object and interact with the object. Details of the node or cluster.
- the cluster encryption public key can also be used to encrypt the challenge information, as long as the corresponding The off-chain private computing node can decrypt successfully.
- the challenge information should be encrypted with the control node’s identity public key. Ensure that the control node can achieve decryption through the identity private key in the TEE created by itself.
- each off-chain privacy computing node creates an off-chain TEE, and creates a node identity in the respective off-chain TEE.
- node 60 creates TEE1
- node 61 creates TEE2
- creates a key pair Key-1 representing its own node identity in TEE1
- node 62 creates TEE3
- creates a key pair Key-2 representing its own node identity in TEE1 Wait.
- each off-chain private computing node joining the cluster is often different, so the timing of creating the off-chain TEE and node identity is also different.
- a node needs to initiate an application to the control node of the privacy cluster under the chain, and the control node will initiate a challenge to the node that made the application to verify the hardware environment of the node, the software running in the off-chain TEE, etc., and after the verification is passed, The node joins the off-chain privacy computing cluster, making the node become an off-chain privacy computing node.
- the control node can select a certain off-chain private computing node as the master node, and other off-chain private computing nodes as slave nodes.
- the master node generates a key pair representing the cluster identity, and then The key pair is shared to each slave node, and finally all the private computing nodes under the chain maintain a unified key pair that represents the identity of the cluster.
- node 60 is selected as a master node, and nodes 61-62, etc., as slave nodes.
- the node 60 generates a key pair representing the cluster identity in TEE1, that is, the cluster identity key pair C-Key.
- the node 60 initiates a challenge to each slave node, so that the slave nodes such as the node 61 and the node 62 respectively generate a remote certification report.
- the remote attestation report can include information such as MREnclave, MRSigner, and hash value of node identity information.
- the node 60 receives the remote certification report and node identity information returned by each slave node, and verifies it in the manner described above to determine whether each slave node is trustworthy.
- the node 60 determines that the node 61 is trustworthy by means of remote certification.
- the key pair Key-0 representing the identity of the node 60
- it contains a set of signature key pair Key-0-S and a set of encryption key pair Key-0-T
- the node 60 can use the signature key pair Key
- the signature private key in -0-S signs the above-mentioned cluster identity key pair C-Key.
- the node identity information provided by node 61 to node 60 includes the public key in the key pair Key-1 representing the identity of node 61, such as the signature public key and encryption key in the signature key pair Key-1-S.
- the encryption public key in Key-1-T Therefore, the node 60 can use the encryption key to encrypt the public key in Key-1-T, encrypt the above-mentioned cluster identity key to C-Key and its signature data, obtain the encrypted key pair, and send it to the node 61.
- the node 60 also triggers to obtain the remote certification report generated for the TEE1 created by itself based on the method described above.
- the node 60 also sends the remote certification report and the node
- the node identity information of 60 itself is sent to the node 61 for the node 61 to verify the node 60.
- the node 61 verifies that the node 60 is credible, it uses the encryption key maintained by itself to decrypt the encrypted private key in Key-1-T to obtain the cluster identity key pair C-Key and its signature data; and, node 61 extracts the signature public key in Key-0-S from the node identity information of node 60, and verifies the signature data obtained by decryption.
- the node 61 determines that the decrypted cluster identity key pair C-Key is valid, and determines that the key pair C-Key can represent the cluster identity of the off-chain privacy computing cluster. Similarly, through the above method, the master node can share the cluster identity key pair C-Key to each slave node, so that all off-chain privacy computing nodes in the off-chain privacy computing cluster can obtain the cluster identity key pair C- Key.
- the client 51 can send execution engine designation information, so that the off-chain privacy computing node deployed with the off-chain contract can learn the execution engine used to execute the above bytecode accordingly. It will not be repeated, and reference may be made to the embodiment shown in FIG. 4.
- the client 51 may receive deployment result information, which includes the hash value of the off-chain contract, such as the first hash value, so that the client 51 can compare the first hash value with the byte sent by itself.
- the second hash value corresponding to the code is compared to determine whether the off-chain privacy computing node successfully deploys the above-mentioned on-chain contract, which will not be repeated here, and the embodiment shown in FIG. 4 can be referred to.
- control node 52 only needs to ensure that the deployment result information fed back by all off-chain private computing nodes are consistent, and transmit the deployment result information fed back by any off-chain private computing node to Client 51 is fine.
- this specification can effectively verify the hardware security of the off-chain private computing nodes and the software correctness of the off-chain TEE based on remote certification, so as to verify the trustworthiness of the off-chain private computing nodes.
- the off-chain contract is safely deployed to the off-chain private computing node through encrypted transmission, and the off-chain contract is only executed in the off-chain TEE created by the off-chain private computing node, which has extremely high security and can bear the block
- the off-chain privacy computing tasks assigned by the chain nodes and to ensure that the off-chain privacy technical tasks are executed safely, reliably, and efficiently.
- the computing task is executed on the off-chain private computing node
- the consensus mechanism between nodes is not involved, so it only needs to execute the computing task on a single off-chain private computing node, which is compared with the consensus mechanism.
- the on-chain contract is required to be executed by all blockchain nodes, it can greatly save the resource consumption caused by the execution of computing tasks.
- blockchain nodes can distribute computing tasks to off-chain private computing nodes, and call the off-chain contracts deployed on the off-chain private computing nodes, through the chain created by the off-chain private computing nodes
- the off-chain contract is executed in the TEE to complete the above-mentioned calculation tasks.
- the blockchain node can update the blockchain ledger data according to the calculation result, can solidify the calculation result, and can support the later verification of the calculation result.
- the calculation result generated based on the off-chain contract is relatively shorter. Therefore, when the calculation result is uploaded to the chain, it is helpful to save Storage space on the chain.
- the blockchain node updates the blockchain ledger data according to the calculation result, or it is called uploading the calculation result to the chain.
- the method can include: generating a blockchain transaction and adding the calculation result to the data field of the transaction. After the block chain transaction has passed the consensus, it can be added by each block chain node to the block body of the latest block, thereby realizing the update of the block chain ledger data, that is, completing the chaining of the calculation result; or,
- the blockchain node updates the state of the related account according to the calculation result.
- the related account can be, for example, the external account corresponding to the user or the contract account corresponding to the contract on the chain.
- the update of the state of the related account will cause the state tree to change.
- the value of the root of the tree changes, and the root of the state tree will be included in the block header of the latest block, thereby realizing the update of the blockchain ledger data, which is equivalent to uploading the calculation result to the chain.
- the off-chain contract in this manual can implement any calculation logic defined by the user.
- the off-chain contract can be used to verify whether the amount of encrypted order data stored on the blockchain is correct, and the verification result is fed back to the chain; for another example, the off-chain contract can be used to secure multi-party data according to a preset algorithm Calculations are safe multi-party calculations, and the calculation results are fed back to the chain, etc., so I won’t repeat them here.
- the client 71 wishes to call the deployed off-chain contract.
- the client 71 can send a call request to the control node 72 through an off-chain channel.
- the call request is encrypted with the cluster identity public key.
- the control node 72 can allocate the call request to a certain off-chain privacy in the cluster based on the load balancing algorithm.
- the computing node, such as node 72n responds to the call request by the node 72n.
- the node 72n decrypts the call request through the cluster identity private key in the off-chain TEE created by itself, and obtains the contract ID, function name, and input data information contained in the call request.
- the contract ID can be, for example, the hash value of the bytecode of the off-chain contract, so that the node 72n can find the corresponding bytecode of the deployed off-chain contract.
- the off-chain contract may contain multiple functions, so the function name can indicate the function that the client 71 wants to call; if the off-chain contract only contains one function, or the client 71 wants to call all the functions in the off-chain contract, then the call request is also included. You can omit the function name information.
- the information of the input parameter data may be the input parameter data itself, or the description information of the input parameter data. For example, the description information may be a storage address, etc., so that the node 72n can obtain the input parameter data accordingly, especially when the client 71 itself is not data.
- the interaction between the client 71 and the data owner can be omitted, the amount of data requested by the call can also be reduced, and the transmission speed can be accelerated.
- the node 72n can execute the bytecode of the off-chain contract in the off-chain TEE to process the input parameter data, so as to obtain the corresponding call result.
- the node 72n may encrypt the call result in the off-chain TEE, and then feed it back to the client 71 via the control node 72.
- the client 71 can send a call request to the control node 72 through an on-chain channel.
- the client 71 may submit an off-chain contract invocation transaction to the blockchain network 73.
- the off-chain contract invocation transaction includes a invocation request, and the invocation request is encrypted by the client 71 using the cluster identity public key.
- the off-chain contract call transaction itself can also be encrypted transmission, which can refer to the content of data encrypted transmission described above, which will not be repeated here.
- the off-chain contract call transaction can call the oracle contract, so that the oracle contract generates a corresponding contract event for the call request contained in the exchange. After the contract event is monitored by the oracle server 74, the oracle server 74 obtains the call request and Transmitted to the control node 72.
- control node 72 distributes the call request to, for example, the off-chain privacy computing node 72n to respond. And, the control node 72 can feed the call result back to the chain through the oracle mechanism, and the node 73n can actively initiate a transaction to upload the call result to the chain, or the node 73n can feed back the call result to the client 71, and the client The terminal 71 re-initiates a transaction to upload the result of the call to the chain.
- the client 71 can submit an encrypted off-chain contract call transaction to the blockchain network 73.
- the off-chain contract call transaction includes the contract ID, function name, and input parameter data, and
- the off-chain contract call transaction calls the on-chain contract used to obtain input parameter data.
- node 73n receives the encrypted off-chain contract call transaction, it decrypts it in the on-chain TEE, and then executes the called on-chain contract through the virtual machine deployed in the on-chain TEE to obtain the block that is used as the input data.
- Chain data The blockchain data is usually encrypted.
- Node 73n can decrypt it into plaintext in the on-chain TEE, and then package the plaintext blockchain data with the contract ID and function name contained in the off-chain contract call exchange as The call request is encrypted using the cluster identity public key in the on-chain TEE, and then transmitted to the control node 72 based on the oracle mechanism, and the control node 72 distributes the call request to the off-chain privacy computing node 72n for response. . And, the control node 72 can feed back the call result to the chain through the oracle mechanism, and the node 73n can upload the call result to the chain.
- contract identities can be generated for off-chain contracts deployed on off-chain private computing nodes.
- each off-chain privacy computing node can establish a contract identity for its deployed off-chain contract, and the contract identities generated by different off-chain privacy computing nodes for the same off-chain contract are the same .
- off-chain privacy computing nodes can generate corresponding contract identities for off-chain contracts based on the unified cluster identity and the contract ID of the off-chain contract.
- the cluster identities are the same but the contract IDs of different off-chain contracts are necessarily different, it can be ensured : Different off-chain contracts deployed on the same chain of private computing nodes have different contract identities, and the same off-chain contracts deployed on different off-chain privacy computing nodes have the same contract identities.
- the control node 72 allocates the received call request, it only needs to pay attention to the degree of idleness of the privacy computing nodes in each chain in the cluster, and perform task allocation based on the degree of idleness, without paying attention to other information.
- the contract identity can be defined by the contract identity key pair.
- the contract identity can include a contract encryption key pair and a contract signature key pair.
- the client 71 or the node 73n may also use the contract encryption public key to encrypt the information of the input data contained in the call request.
- the off-chain privacy computing node 72n After the off-chain privacy computing node 72n receives a call request for a certain off-chain contract, it uses the contract encryption private key corresponding to the off-chain contract to decrypt the encrypted input data information in the call request, thereby ensuring the entry of parameters Data information can only be obtained by the called off-chain contract, but not by other off-chain contracts.
- the off-chain privacy computing node 72n can sign the call result through the contract signature private key of the called off-chain contract, and the client 71 or node 73n can verify the signature through the contract signature public key. Therefore, it is determined that the call result is indeed generated by the called off-chain contract.
- an off-chain privacy computing cluster is taken as an example for description.
- the client 71 can also directly interact with a single off-chain private computing node to invoke the off-chain contract deployed on the off-chain private computing node, which will not be repeated here.
- this specification also proposes other embodiments on the off-chain privacy node side, blockchain node side, control node side, etc.
- the description involved in the client-side embodiment can also be The embodiments applicable to these sides will not be described in detail below.
- FIG. 8 is a flowchart of a method for deploying a contract on the side of an off-chain privacy computing node provided by an exemplary embodiment. As shown in FIG. 8, the method may include step 802 to step 806.
- step 802 the off-chain privacy computing node receives the challenge from the client, and provides a remote attestation report to the client.
- the remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the off-chain private computing node, and the self-recommendation information is related to the off-chain trusted execution environment created on the off-chain private computing node.
- the off-chain private computing node can receive the challenge information transmitted by the blockchain node through the oracle mechanism.
- the challenge information is extracted by the blockchain node from the challenge transaction submitted by the client; or, the off-chain private computing node Can receive the off-chain challenge initiated by the client.
- the off-chain private computing node can receive the challenge directly initiated by the client; or, in the case that the off-chain private computing node belongs to the off-chain private computing cluster, the off-chain private computing node can receive the off-chain private computing cluster.
- the challenge forwarded by the control node the challenge is initiated by the client to the control node and the challenge target is set by the client as the off-chain private computing node; or, the off-chain private computing node can receive the off-chain private computing cluster’s control node forwarding
- the challenge is initiated by the client to the control node and the challenge goal is not set, while the off-chain private computing node is selected by the controlling node from the off-chain private computing cluster.
- the off-chain private computing node can generate self-recommendation information in response to the above challenge, and the above-mentioned remote attestation report is generated by the authentication server after verifying the self-recommended information; or, the off-chain private computing node can respond to other
- the challenge of the challenger generates the above-mentioned self-recommendation information
- the remote attestation report is generated after the authentication server verifies the self-recommendation information.
- Step 804 the off-chain privacy computing node receives the bytecode of the off-chain contract encrypted and transmitted by the client, and the bytecode is determined by the client according to the remote attestation report to determine the off-chain privacy computing Sent when the node is trusted.
- the remote attestation report can be signed by the authentication server.
- the remote attestation report carries self-recommendation information.
- the self-recommendation information contains the first hash value to be verified, and the first hash value to be verified is the value of the trusted execution environment under the chain.
- the hash value of the preset information, the first hash value to be checked is used to compare with the trusted hash value obtained in advance by the client for the trusted execution environment under the chain, and the comparison result is consistent and confirmed by the client A prerequisite for the trustworthiness of private computing nodes under the chain.
- the node identity information that the off-chain private computing node can provide to the client is related to the key representing the identity of the off-chain private computing node;
- the self-recommendation information also contains the second to-be-verified
- the hash value, the second hash value to be checked is the hash value of the node identity information when the off-chain privacy computing node generates the self-recommended information, and the second hash value to be checked is used to compare with the node identity information, and compare The consistent result is used as a prerequisite for the client to confirm the trustworthiness of the private computing node under the chain.
- the node identity information that the off-chain private computing node can provide to the client is related to the key representing the identity of the off-chain private computing node, and the node identity information includes the trusted execution environment under the chain Related information; among them, the remote attestation report is signed by the authentication server; the remote attestation report carries self-recommendation information, and the self-recommendation information contains the hash value to be verified, and the hash value to be verified is used for the hash value of the node identity information obtained by the client. The value is expected to be compared, and the comparison result is consistent as a prerequisite for the client to confirm the trustworthiness of the off-chain private computing node.
- the off-chain private computing node can receive the bytecode ciphertext transmitted by the blockchain node through the oracle mechanism.
- the bytecode ciphertext is created by the blockchain node in the trusted execution environment on the chain created by itself.
- the encrypted off-chain contract deployment transaction submitted by the client is decrypted and obtained; or, the off-chain privacy computing node may receive the bytecode encrypted and transmitted off-chain by the client.
- the off-chain private computing node can directly obtain the encrypted transmission bytecode from the client; or, in the case that the off-chain private computing node belongs to the off-chain private computing cluster, the off-chain private computing node can receive the chain The bytecode ciphertext forwarded by the control node of the next privacy computing cluster, and the bytecode ciphertext is transmitted from the client to the control node.
- Step 806 The off-chain private computing node decrypts to obtain the bytecode in the off-chain trusted execution environment, and deploys the bytecode.
- the deployed bytecode is executed in the off-chain trusted execution environment, and the execution result is fed back to the block through the oracle mechanism Chain node.
- the bytecode can be transmitted after being encrypted by the public key of the asymmetric key pair, and the private key of the asymmetric key pair is maintained by the off-chain privacy computing node.
- the private key of the asymmetric key pair can only be maintained by the off-chain private computing node, or the private key of the asymmetric key pair can be It is jointly maintained by all off-chain private computing nodes in the off-chain private computing cluster.
- the off-chain privacy computing node can receive the execution engine designation information associated with the bytecode sent by the client, and set the corresponding execution engine for the bytecode according to the execution engine designation information.
- the off-chain private computing node can generate deployment result information, and the deployment result information includes the first hash value obtained by the off-chain private computing node hashing the deployed bytecode; the off-chain private computing node can The deployment result information is returned to the client.
- the first hash value is used to compare with the second hash value of the bytecode held by the client, and the comparison result is consistent as the client confirms that the off-chain contract is off-chain A prerequisite for successful deployment at the privacy computing node.
- FIG. 9 is a flowchart of a method for deploying a contract on a blockchain node side according to an exemplary embodiment. As shown in FIG. 9, the method may include step 902 to step 906.
- step 902 the blockchain node receives the challenge transaction initiated by the client, and returns the remote certification report of the off-chain private computing node to the client.
- the remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the off-chain private computing node.
- the self-recommendation information is related to the off-chain trusted execution environment created on the off-chain private computing node.
- blockchain nodes can read encrypted challenge transactions into the trusted execution environment on the chain for decryption, and obtain the challenge information contained in the challenge transaction; blockchain nodes can transmit the challenge information through the oracle mechanism To the off-chain private computing node, or to the control node of the off-chain private computing cluster to which the off-chain private computing node belongs; the blockchain node can receive the remote certification report returned by the off-chain private computing node or the control node and provide it to the client.
- Step 904 the blockchain node receives the encrypted off-chain contract deployment transaction initiated by the client, and decrypts it in the on-chain trusted execution environment to obtain the bytecode contained in the off-chain contract deployment transaction Ciphertext, the bytecode ciphertext is obtained by encrypting the bytecode of the off-chain contract by the client, and the off-chain contract deployment transaction is determined by the client on the chain according to the remote attestation report Initiated when the next privacy computing node is trusted.
- the remote attestation report can be triggered by the off-chain private computing node in response to the client's challenge; or, the remote attestation report can be triggered by the off-chain private computing node in response to the challenge of other challengers.
- the remote attestation report can be signed by the authentication server, and the remote attestation report carries self-recommendation information.
- the self-recommendation information includes the first hash value to be verified, and the first hash value to be verified is the pre-test of the trusted execution environment under the chain.
- the hash value of the information, the first hash value to be checked is used to compare with the trusted hash value obtained in advance by the client for the trusted execution environment off-chain, and the comparison result is consistent as the client confirms the off-chain privacy A prerequisite for the trustworthiness of computing nodes.
- the blockchain node can receive the node identity information returned by the off-chain private computing node and provide it to the client.
- the node identity information is related to the key representing the identity of the off-chain private computing node; among them, the self-recommended information It also contains a second hash value to be verified, the second hash value to be verified is the hash value of the node identity information when the off-chain privacy computing node generates the self-recommended information, and the second hash value to be verified is used to communicate with the node identity information
- the comparison and the consistency of the comparison result is used as a prerequisite for the client to confirm the trustworthiness of the off-chain private computing node.
- the blockchain node can receive the node identity information returned by the off-chain private computing node and provide it to the client.
- the node identity information is related to the key representing the identity of the off-chain private computing node, and the node identity information includes Information related to the trusted execution environment under the chain; among them, the remote attestation report is signed by the authentication server; the remote attestation report carries self-recommendation information, and the self-recommendation information contains the hash value to be verified, which is used for the information obtained with the client
- the hash value of the node identity information is compared, and the comparison result is consistent as a prerequisite for the client to confirm the trustworthiness of the off-chain private computing node.
- Step 906 the blockchain node transmits the bytecode ciphertext to the off-chain private computing node through the oracle mechanism, and the off-chain private computing node decrypts it in the off-chain trusted execution environment Obtain the bytecode and deploy.
- the deployed bytecode is executed in the off-chain trusted execution environment, and the execution result is fed back to the block through the oracle mechanism Chain node.
- the blockchain node can directly transmit the bytecode ciphertext to the off-chain private computing node through the oracle mechanism; or, when the off-chain private computing node belongs to the off-chain private computing cluster, the blockchain The node can transmit the bytecode ciphertext to the control node of the privacy computing cluster under the chain through the oracle mechanism, and forward it from the control node to the privacy computing node under the chain; among them, the bytecode ciphertext is also forwarded to the off-chain by the control node Other off-chain privacy computing nodes in the privacy computing cluster.
- the bytecode can be transmitted after being encrypted by the public key of the asymmetric key pair, and the private key of the asymmetric key pair is maintained by the off-chain privacy computing node.
- the private key of the asymmetric key pair can only be maintained by the off-chain private computing node, or the private key of the asymmetric key pair can be It is jointly maintained by all off-chain private computing nodes in the off-chain private computing cluster.
- Blockchain nodes can decrypt in the trusted execution environment on the chain to obtain the execution engine specified information contained in the off-chain contract deployment exchange; blockchain nodes can transmit the execution engine specified information to the off-chain private computing node through the oracle mechanism.
- the execution engine designation information indicates the execution engine used to execute the bytecode to the private computing node under the chain.
- the blockchain node can receive the deployment result information returned by the off-chain private computing node and provide it to the client.
- the deployment result information includes the off-chain private computing node hashing the deployed bytecode.
- the first hash value among them, the first hash value is used to compare with the second hash value of the bytecode held by the client, and the comparison result is consistent as the client confirms the off-chain contract in the off-chain privacy calculation A prerequisite for successful deployment at the node.
- FIG. 10 is a flowchart of a method for controlling a deployment contract on the node side provided by an exemplary embodiment. As shown in FIG. 10, the method may include step 1002 to step 1006.
- Step 1002 the control node of the off-chain privacy computing cluster receives the challenge initiated by the client, selects an off-chain privacy computing node from the off-chain privacy computing cluster, and provides the selected off-chain privacy computing node to the client Corresponding remote attestation report; wherein, the software and hardware configurations of all off-chain privacy computing nodes in the off-chain privacy computing cluster are consistent.
- the remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the selected off-chain private computing node.
- the self-recommendation information is related to the off-chain trusted execution environment created on the selected off-chain private computing node. .
- control node can receive the challenge information transmitted by the blockchain node through the oracle mechanism.
- the challenge information is extracted by the blockchain node from the challenge transaction submitted by the client; or the control node can receive the challenge initiated by the client Off-chain challenges.
- the remote attestation report can be triggered by the selected off-chain private computing node in response to a challenge initiated by the client; or, the remote attestation report can be generated by the selected off-chain private computing node in response to other challengers’ requests. Triggered by challenge.
- the selected off-chain privacy computing node can be designated by the client; or, the selected off-chain privacy computing node can be selected by the control node in a preset manner.
- Step 1004 The control node receives the bytecode of the off-chain contract encrypted and transmitted by the client.
- the bytecode is determined by the client in the off-chain privacy computing cluster according to the remote attestation report. Sent when the off-chain privacy computing node is trusted.
- control node can receive the bytecode ciphertext transmitted by the blockchain node through the oracle mechanism, and the bytecode ciphertext is submitted to the client by the blockchain node in the trusted execution environment on the chain created by itself
- the encrypted off-chain contract deployment transaction is obtained after decryption; or, the control node can receive the bytecode encrypted and transmitted off-chain by the client.
- step 1006 the control node forwards the received bytecode ciphertext to all off-chain privacy computing nodes in the off-chain privacy computing cluster, and the bytecode ciphertext can be used by each off-chain privacy computing node.
- the bytecode is obtained by decrypting in its own off-chain trusted execution environment, and the bytecode is deployed.
- the deployed bytecode is executed in an off-chain trusted execution environment at any off-chain private computing node, and the execution result is Feedback to the blockchain nodes through the oracle mechanism.
- the bytecode can be encrypted by the public key of the asymmetric key pair and then transmitted, and the private key of the asymmetric key pair is jointly maintained by all the off-chain privacy computing nodes in the off-chain privacy computing cluster.
- the control node can receive the execution engine specified information associated with the bytecode sent by the client, and forward it to all off-chain private computing nodes in the off-chain privacy computing cluster.
- the execution engine specified information is used to instruct each off-chain private computing node Set the corresponding execution engine for the bytecode.
- the control node can receive deployment result information from any off-chain privacy computing node in the off-chain privacy computing cluster.
- the deployment result information includes the first result obtained by any off-chain privacy computing node hashing the deployed bytecode.
- a hash value the control node can return deployment result information to the client.
- the first hash value is used to compare with the second hash value of the bytecode held by the client, and the consistency of the comparison result is regarded as the client confirmation A prerequisite for the successful deployment of the off-chain contract at the off-chain privacy computing node in the off-chain privacy computing cluster.
- the client can also directly interact with the private computing node to complete operations such as deploying smart contracts on the private computing node, without the need to use the oracle mechanism of the blockchain to complete the above operations, and at the same time, the private computing
- the deployment result of the node on the smart contract does not need to be fed back to the blockchain.
- off-chain private computing nodes will be referred to as “private computing nodes”
- off-chain trusted execution environment will be referred to as “trusted execution environment”.
- the "target chain contract” is called the "target smart contract”.
- the principle of the technical solution is similar to the above-mentioned embodiment, and the implementation details involved include the creation process of the trusted execution environment by the private computing node, the generation process of the remote certification report by the private computing node, and the verification process of the remote certification report by the client.
- the encryption and decryption scheme of the bytecode, the verification of the deployment result by the client, etc. reference may also be made to the above-mentioned embodiment, so the detailed description will not be given below.
- Fig. 11 is a flowchart of another method for deploying an off-chain contract on the client side according to an exemplary embodiment. As shown in FIG. 11, the method may include step 1102 to step 1104.
- Step 1102 The client obtains a remote attestation report for the privacy computing node.
- the client can initiate a challenge to the private computing node and receive a remote certification report returned by the private computing node; or, in the case that the private computing node belongs to a private computing cluster, the The client can initiate a challenge to the control node of the privacy computing cluster, and receive a remote certification report returned by the control node.
- the client can initiate a challenge to the control node and the challenge target is set to the private computing node, so that the control node returns the remote attestation report of the private computing node; or, the The client may initiate a challenge to the control node and the challenge target is not set, so that the control node selects the private computing node from the private computing cluster and returns the remote attestation report of the private computing node.
- the remote attestation report may be triggered by the private computing node in response to the challenge initiated by the client; or, the remote attestation report may be generated by the private computing node in response to other challengers’ requests. Triggered by challenge.
- the client can perform signature verification on the remote certification report according to the public key of the certification server; in the case where the signature is verified and the remote certification result contained in the remote certification report is certified
- the client extracts a first hash value to be verified from the self-recommendation information carried in the remote attestation report, and the first hash value to be verified is preset information of the trusted off-chain execution environment The hash value; the client compares the pre-obtained trusted hash value for the trusted execution environment off-chain with the first hash value to be verified, and confirms that the comparison result is consistent A prerequisite for the trustworthiness of a private computing node.
- the client can obtain the node identity information provided by the private computing node, and the node identity information is related to the key representing the identity of the private computing node; the client proves from the remote Extracting a second to-be-verified hash value from the self-recommendation information carried in the report, and the second to-be-verified hash value is the hash value of the node identity information when the privacy computing node generates the self-recommendation information; The client computer calculates and obtains the hash value of the node identity information, compares the calculated hash value with the second hash value to be verified, and uses the consistency of the comparison result as a prerequisite for confirming that the privacy computing node is trustworthy .
- the client can obtain the node identity information provided by the private computing node, the node identity information is related to the key representing the identity of the private computing node, and the node identity information includes all Information related to the trusted execution environment under the chain; the client performs signature verification on the remote attestation report according to the public key of the authentication server; after the signature is verified and the remote attestation report contains the remote attestation result: In the case of passing the authentication, the client extracts the hash value to be verified from the self-recommendation information carried in the remote attestation report, and the hash value to be verified is when the privacy computing node generates the self-recommendation information The hash value of the node identity information; the client calculates and obtains the hash value of the node identity information, compares the calculated hash value with the hash value to be verified, and uses the consistency of the comparison result as the confirmation The prerequisites for the trustworthiness of private computing nodes are described.
- Step 1104 When the client determines that the private computing node is credible according to the remote certification report, the client encrypts the bytecode of the smart contract and transmits it to the private computing node. The bytecode is decrypted in the trusted execution environment and deployed.
- the client can directly encrypt the bytecode and transmit it to the privacy computing node; or, in the case that the privacy computing node belongs to a privacy computing cluster, the client can transmit the The bytecode is encrypted and transmitted to the control node of the privacy computing cluster, and is forwarded by the control node to the privacy computing node; wherein, the control node is also forwarded to other privacy computing nodes in the privacy computing cluster.
- the bytecode can be transmitted after being encrypted by the public key of the asymmetric key pair, and the private key of the asymmetric key pair is maintained by the privacy computing node.
- the private key of the asymmetric key pair may be maintained only by the private computing node, or the private key of the asymmetric key pair The key can be jointly maintained by all private computing nodes in the private computing cluster.
- the client can send the execution engine designation information associated with the bytecode to the privacy computing node, and the execution engine The designated information indicates to the privacy computing node an execution engine for executing the bytecode.
- the client may receive deployment result information, where the deployment result information includes the first hash value obtained by the privacy computing node hashing the deployed bytecode; the client may The first hash value is compared with the second hash value of the bytecode held by itself, and if the comparison result is consistent, it is confirmed that the smart contract is successfully deployed at the privacy computing node.
- Fig. 12 is a flowchart of another method for deploying a smart contract on the side of a privacy computing node provided by an exemplary embodiment. As shown in FIG. 12, the method may include step 1202 to step 1206.
- Step 1202 The privacy computing node receives the challenge from the client, and provides a remote attestation report to the client.
- the private computing node may receive a challenge directly initiated by the client; or, in the case that the private computing node belongs to a private computing cluster, the private computing node may receive a request from the private computing cluster.
- the challenge forwarded by the control node the challenge is initiated by the client to the control node and the challenge target is set by the client as the private computing node; or, the private computing node may receive the private computing
- the challenge forwarded by the control node of the cluster, the challenge is initiated by the client to the control node and the challenge target is not set, and the private computing node is selected by the control node from the private computing cluster.
- the private computing node may generate the self-recommendation information in response to the challenge, and the remote attestation report is generated after the authentication server verifies the self-recommendation information; or, the private computing node
- the self-recommendation information may be generated in response to challenges of other challengers, and the remote attestation report is generated after the authentication server verifies the self-recommendation information.
- Step 1204 the privacy computing node receives the bytecode of the smart contract encrypted and transmitted by the client, and the bytecode is determined by the client according to the remote attestation report to determine the trustworthiness of the privacy computing node Send it down.
- the remote attestation report is signed by the authentication server, the remote attestation report carries the self-recommendation information, and the self-recommendation information includes the first hash value to be checked, and the first hash to be checked
- the value is the hash value of the preset information of the off-chain trusted execution environment, and the first to-be-checked hash value is used to communicate with the client's pre-obtained credibility for the off-chain trusted execution environment.
- the hash values are compared, and the comparison result is consistent as a prerequisite for the client to confirm that the privacy computing node is trustworthy.
- the node identity information provided by the private computing node to the client is related to the key representing the identity of the private computing node; wherein the self-recommendation information also includes the first 2.
- the hash value to be verified, the second hash value to be verified is the hash value of the identity information of the node when the privacy computing node generates the self-recommendation information, and the second hash value to be verified is used with all
- the node identity information is compared, and the comparison result is consistent as a prerequisite for the client to confirm that the private computing node is trustworthy.
- the node identity information provided by the private computing node to the client is related to the key representing the identity of the private computing node, and the node identity information includes the Information related to the trusted execution environment under the chain; wherein the remote attestation report is signed by the authentication server; the remote attestation report carries the self-recommendation information, and the self-recommendation information contains the hash value to be verified, and the The verification hash value is used for comparison with the hash value of the node identity information obtained by the client, and the consistency of the comparison result is used as a prerequisite for the client to confirm that the privacy computing node is trustworthy.
- the private computing node directly obtains the encrypted transmission of the bytecode from the client; or, in the case that the private computing node belongs to a private computing cluster, the private computing node receives the The bytecode ciphertext forwarded by the control node of the privacy computing cluster, and the bytecode ciphertext is transmitted by the client to the control node.
- Step 1206 The private computing node decrypts the bytecode in the trusted execution environment, and deploys the bytecode.
- the bytecode is encrypted by the public key of the asymmetric key pair and then transmitted, and the private key of the asymmetric key pair is maintained by the privacy computing node.
- the private key of the asymmetric key pair is only maintained by the private computing node, or the private key of the asymmetric key pair It is jointly maintained by all private computing nodes in the private computing cluster.
- the privacy computing node can receive the execution engine designation information associated with the bytecode sent by the client; the privacy The computing node may set a corresponding execution engine for the bytecode according to the execution engine designation information.
- the privacy computing node may generate deployment result information, and the deployment result information includes the first hash value obtained by the privacy computing node hashing the deployed bytecode; the privacy computing The node may return the deployment result information to the client, the first hash value is used to compare with the second hash value of the bytecode held by the client, and the consistency of the comparison result is regarded as all
- the client confirms a prerequisite for the successful deployment of the smart contract at the privacy computing node.
- Fig. 13 is a flowchart of another method for deploying a smart contract on the control node side according to an exemplary embodiment. As shown in FIG. 13, the method may include step 1302 to step 1306.
- Step 1302 The control node of the privacy computing cluster receives the challenge initiated by the client, selects a privacy computing node from the privacy computing cluster, and provides the client with a remote certification report corresponding to the selected privacy computing node.
- the remote attestation report is triggered by the selected private computing node in response to the challenge initiated by the client; or, the remote attestation report is generated by the selected private computing node in response to Triggered by the challenges of other challengers.
- the selected privacy computing node is designated by the client; or, the selected privacy computing node is selected by the control node in a preset manner.
- Step 1304 the control node receives the bytecode of the smart contract encrypted and transmitted by the client, and the bytecode is determined by the client according to the remote attestation report to determine the privacy computing node in the privacy computing cluster Sent if you can trust it.
- the bytecode is encrypted by the public key of the asymmetric key pair and then transmitted, and the private key of the asymmetric key pair is jointly maintained by all the private computing nodes in the private computing cluster.
- control node can receive the execution engine designation information associated with the bytecode sent by the client, and forward it to all For all private computing nodes in the private computing cluster, the execution engine designation information is used to instruct each private computing node to set a corresponding execution engine for the bytecode.
- Step 1306 The control node forwards the received bytecode ciphertext to all private computing nodes in the privacy computing cluster, and the bytecode ciphertext can be executed by each private computing node in its own trustworthy manner.
- the bytecode is obtained by decryption in the environment, and the bytecode is deployed.
- the control node receives deployment result information from any private computing node in the private computing cluster, and the deployment result information includes any private computing node performing a hash of the deployed bytecode.
- the first hash value obtained by the Greek operation; the control node returns the deployment result information to the client, and the first hash value is used to communicate with the second hash value of the bytecode held by the client.
- the desired value is compared, and the comparison result is consistent as a prerequisite for the client to confirm that the smart contract is successfully deployed at the private computing node in the private computing cluster.
- Fig. 14 is a schematic structural diagram of a device according to an exemplary embodiment.
- the device includes a processor 1402, an internal bus 1404, a network interface 1406, a memory 1408, and a non-volatile memory 1410.
- the processor 1402 reads the corresponding computer program from the non-volatile memory 1410 to the memory 1408 and then runs it to form a device for deploying the contract on a logical level.
- one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, and so on. That is to say, the execution subject of the following processing flow is not limited to each
- the logic unit can also be a hardware or a logic device.
- the device for deploying the contract may include: a verification unit 1501, which enables the client to obtain a remote certification report for the off-chain private computing node, and the remote certification report is issued by the authentication server
- the self-recommendation information generated by the off-chain private computing node is generated after verification, and the self-recommendation information is related to the off-chain trusted execution environment created on the off-chain private computing node
- the deployment unit 1502 enables the client to log in If it is determined according to the remote certification report that the off-chain private computing node is trustworthy, the bytecode of the off-chain contract is encrypted and transmitted to the off-chain private computing node, and the off-chain private computing node will The bytecode is decrypted in an off-chain trusted execution environment and deployed; wherein, when a blockchain node initiates a call to the off-chain contract through the oracle mechanism, the deployed bytecode is in the It is executed in an off-chain trusted execution environment, and
- the verification unit 1501 is specifically configured to: enable the client to initiate a challenge to the off-chain privacy computing node and receive a remote attestation report returned by the off-chain privacy computing node; or, in the off-chain privacy In the case that the computing node belongs to the off-chain privacy computing cluster, the client is caused to initiate a challenge to the control node of the off-chain privacy computing cluster, and receive a remote attestation report returned by the control node.
- the verification unit 1501 is specifically configured to: enable the client to submit a challenge transaction to a blockchain node, and the challenge information contained in the challenge transaction can be transmitted to the chain by the blockchain node through an oracle mechanism. Down the private computing node or the control node; or, make the client initiate an off-chain challenge to the off-chain private computing node or the control node.
- the verification unit 1501 is specifically configured to: enable the client to initiate a challenge to the control node and the challenge target is set to the off-chain privacy computing node, so that the control node returns to the off-chain privacy computing Remote attestation report of the node; or, make the client initiate a challenge to the control node and the challenge goal is not set, make the control node select the off-chain private computing node from the off-chain private computing cluster and Return the remote certification report of the off-chain privacy computing node.
- the remote attestation report is triggered by the off-chain privacy computing node in response to a challenge initiated by the client; or, the remote attestation report is generated by the off-chain privacy computing node in response to other challengers The challenge is triggered.
- the verification unit 1501 is specifically configured to: enable the client to perform signature verification on the remote certification report according to the public key of the certification server; after the signature is verified and the remote certification report contains the remote certification result
- the client is allowed to extract the first to-be-verified hash value from the self-recommendation information carried in the remote attestation report, and the first to-be-verified hash value is the off-chain available Trust the hash value of the preset information of the execution environment; enable the client to compare the pre-obtained trusted hash value for the off-chain trusted execution environment with the first hash value to be verified, and The consistency of the comparison result is used as a prerequisite for confirming the trustworthiness of the off-chain privacy computing node.
- the verification unit 1501 is specifically configured to: enable the client to obtain node identity information provided by the off-chain private computing node, where the node identity information is related to a key representing the identity of the off-chain private computing node ; Enable the client to extract a second to-be-verified hash value from the self-recommendation information carried in the remote attestation report, where the second to-be-verified hash value is the off-chain privacy computing node to generate the self-recommendation
- the verification unit 1501 is specifically configured to: enable the client to obtain node identity information provided by the off-chain private computing node, where the node identity information is related to a key representing the identity of the off-chain private computing node , And the node identity information includes information related to the trusted execution environment under the chain; enable the client to perform signature verification on the remote attestation report according to the public key of the authentication server; If the remote authentication result contained in the remote attestation report is passed authentication, the client is caused to extract the hash value to be verified from the self-recommendation information carried in the remote attestation report, and the hash value to be verified is The hash value of the node identity information when generating the self-recommended information for the off-chain privacy computing node; the client is allowed to calculate the hash value of the node identity information obtained, and the calculated hash value is compared with the The hash value is checked for comparison, and the comparison result is consistent as a prerequisite for confirming the trustworthiness of the off-chain privacy computing node.
- the deployment unit 1502 is specifically configured to: enable the client to generate an off-chain contract deployment transaction, where the off-chain contract deployment transaction includes the bytecode ciphertext obtained by encrypting the bytecode; and, The client encrypts the off-chain contract deployment transaction and submits it to the blockchain node.
- the encrypted off-chain contract deployment transaction can be decrypted in the trusted execution environment on the chain created at the blockchain node, And the blockchain node transmits the bytecode ciphertext obtained by decrypting the transaction to the off-chain privacy computing node through the oracle mechanism; or, the client is made to encrypt and transmit the bytecode off-chain To the off-chain privacy computing node.
- the deployment unit 1502 is specifically configured to: enable the client to directly encrypt and transmit the bytecode to the off-chain privacy computing node; or, the off-chain privacy computing node belongs to an off-chain privacy computing cluster
- the client is allowed to encrypt and transmit the bytecode to the control node of the off-chain privacy computing cluster, and the control node forwards it to the off-chain privacy computing node; wherein, the control The node also forwards to other off-chain privacy computing nodes in the off-chain privacy computing cluster.
- the bytecode is encrypted by the public key of the asymmetric key pair and then transmitted, and the private key of the asymmetric key pair is maintained by the off-chain privacy computing node.
- the private key of the asymmetric key pair is only maintained by the off-chain privacy computing node, or the asymmetric secret
- the private key of the key pair is jointly maintained by all the off-chain privacy computing nodes in the off-chain privacy computing cluster.
- the device further includes: an engine specifying unit 1503, which enables the client to send the bytecode to the off-chain private computing node
- the associated execution engine designation information indicates to the off-chain private computing node an execution engine for executing the bytecode.
- a result receiving unit 1504 to enable the client to receive deployment result information, where the deployment result information includes the first data obtained by hashing the deployed bytecode by the off-chain privacy computing node Hash value; result verification unit 1505, which enables the client to compare the first hash value with the second hash value of the bytecode held by itself, and confirm the comparison if the result of the comparison is consistent
- the off-chain contract is successfully deployed at the off-chain privacy computing node.
- the device for deploying the contract may include: a report providing unit 1601, which enables the off-chain private computing node to receive the challenge from the client and provide the client with A remote attestation report, which is generated by an authentication server after verifying the self-recommendation information generated by the off-chain private computing node, and the self-recommendation information is related to the off-chain trusted execution environment created on the off-chain private computing node Related; contract receiving unit 1602, enabling the off-chain privacy computing node to receive the bytecode of the off-chain contract encrypted and transmitted by the client, the bytecode being determined by the client according to the remote attestation report The off-chain private computing node is sent when it is trusted; the contract deployment unit 1603 enables the off-chain private computing node to decrypt the bytecode in the trusted off-chain execution environment, and compare the byte code Code is deployed; where, in the case where the blockchain node initiates a call
- the report providing unit 1601 is specifically configured to: enable the off-chain privacy computing node to receive challenge information transmitted by the blockchain node through the oracle mechanism, and the challenge information is transmitted by the blockchain node from the client It is extracted from the submitted challenge transaction; or, the off-chain privacy computing node is made to receive the off-chain challenge initiated by the client.
- the report providing unit 1601 is specifically configured to: enable the off-chain private computing node to receive the challenge directly initiated by the client; or, in the case that the off-chain private computing node belongs to an off-chain private computing cluster, Make the off-chain private computing node receive the challenge forwarded by the control node of the off-chain private computing cluster, the challenge is initiated by the client to the control node and the challenge target is set by the client as the Off-chain private computing node; or, enabling the off-chain private computing node to receive the challenge forwarded by the control node of the off-chain private computing cluster, where the challenge is initiated by the client to the control node and the challenge target is not set It is determined that the off-chain privacy computing node is selected by the control node from the off-chain privacy computing cluster.
- it further includes: an information generating unit 1604 for enabling the off-chain private computing node to generate the self-recommendation information in response to the challenge, and the remote attestation report is verified by the authentication server after the self-recommendation information Generate; or, make the off-chain privacy computing node generate the self-recommendation information in response to challenges from other challengers, and the remote attestation report is generated after the authentication server verifies the self-recommendation information.
- an information generating unit 1604 for enabling the off-chain private computing node to generate the self-recommendation information in response to the challenge, and the remote attestation report is verified by the authentication server after the self-recommendation information Generate; or, make the off-chain privacy computing node generate the self-recommendation information in response to challenges from other challengers, and the remote attestation report is generated after the authentication server verifies the self-recommendation information.
- the remote attestation report is signed by the authentication server, the remote attestation report carries the self-recommendation information, and the self-recommendation information includes a first hash value to be verified, and the first hash value to be verified Is the hash value of the preset information of the off-chain trusted execution environment, and the first to-be-checked hash value is used with the client's pre-obtained trusted hash value for the off-chain trusted execution environment.
- the desired value is compared, and the comparison result is consistent as a prerequisite for the client to confirm that the off-chain privacy computing node is trustworthy.
- a first identity providing unit 1605 which enables the off-chain private computing node to provide node identity information to the client, and the node identity information is related to the identity of the off-chain private computing node.
- the self-recommendation information also contains a second to-be-verified hash value, and the second to-be-verified hash value is the hash value of the node identity information when the off-chain privacy computing node generates the self-recommendation information Hence, the second hash value to be verified is used for comparison with the node identity information, and the consistency of the comparison result is used as a prerequisite for the client to confirm that the off-chain privacy computing node is trustworthy.
- a second identity providing unit 1606, which enables the off-chain private computing node to provide node identity information to the client, and the node identity information is related to the identity of the off-chain private computing node.
- the key is related, and the node identity information includes information related to the trusted execution environment under the chain; wherein, the remote certification report is signed by the authentication server; the remote certification report carries the self-recommended information,
- the self-recommendation information includes a hash value to be verified, and the hash value to be verified is used to compare with the hash value of the node identity information obtained by the client, and the comparison result is consistent as the client confirms the A prerequisite for the trustworthiness of off-chain private computing nodes.
- the contract receiving unit 1602 is specifically configured to: enable the off-chain privacy computing node to receive the bytecode ciphertext transmitted by the blockchain node through the oracle mechanism, and the bytecode ciphertext is generated by the blockchain
- the node decrypts the encrypted off-chain contract deployment transaction submitted by the client in the trusted execution environment on the chain created by itself; or makes the off-chain privacy computing node receive the encrypted off-chain transmission of the client The bytecode.
- the contract receiving unit 1602 is specifically configured to: enable the off-chain private computing node to directly obtain the encrypted transmission of the bytecode from the client; or, the off-chain private computing node belongs to the off-chain In the case of a private computing cluster, the off-chain private computing node is made to receive the bytecode ciphertext forwarded by the control node of the off-chain private computing cluster, and the bytecode ciphertext is transmitted from the client to the Control node.
- the bytecode is encrypted by the public key of the asymmetric key pair and then transmitted, and the private key of the asymmetric key pair is maintained by the off-chain privacy computing node.
- the private key of the asymmetric key pair is only maintained by the off-chain privacy computing node, or the asymmetric secret
- the private key of the key pair is jointly maintained by all the off-chain privacy computing nodes in the off-chain privacy computing cluster.
- the device further includes: an information receiving unit 1607, which enables the off-chain privacy computing node to receive and the byte sent by the client Execution engine designation information associated with the code; engine setting unit 1608, the off-chain privacy computing node sets a corresponding execution engine for the bytecode according to the execution engine designation information.
- a result generation unit 1609 which causes the off-chain private computing node to generate deployment result information, where the deployment result information includes the off-chain private computing node hashing the deployed bytecode.
- the first hash value of the; the result return unit 1610 enables the off-chain privacy computing node to return the deployment result information to the client, and the first hash value is used to communicate with the client’s
- the second hash value of the section code is compared, and the comparison result is consistent as a prerequisite for the client to confirm that the off-chain contract is successfully deployed at the off-chain privacy computing node.
- the device for deploying the contract may include: a report transmission unit 1701, which enables the blockchain node to receive the challenge transaction initiated by the client and return it to the client
- the remote certification report of the off-chain private computing node is generated by the authentication server after verifying the self-recommendation information generated by the off-chain private computing node.
- the self-recommendation information is the same as the one created on the off-chain private computing node.
- the off-chain trusted execution environment is related; the contract acquisition unit 1702 enables the blockchain node to receive the encrypted off-chain contract deployment transaction initiated by the client, and decrypt it in the on-chain trusted execution environment to obtain the The bytecode ciphertext contained in the off-chain contract deployment transaction, the bytecode ciphertext is obtained by encrypting the bytecode of the off-chain contract by the client, and the off-chain contract deployment transaction is obtained by the client Initiated when the off-chain privacy computing node is determined to be trusted according to the remote attestation report; the contract transmission unit 1703 enables the blockchain node to transmit the bytecode ciphertext to the The off-chain private computing node is decrypted by the off-chain private computing node in the off-chain trusted execution environment to obtain the bytecode and deploy; wherein, the blockchain node uses the oracle mechanism to When the off-chain contract initiates a call, the deployed bytecode can be executed in the off-chain trusted execution environment, and the execution result can be fed back to
- the report transmission unit 1701 is specifically configured to: enable the blockchain node to read the encrypted challenge transaction into the trusted execution environment on the chain for decryption, and obtain the challenge contained in the challenge transaction Information; enable the blockchain node to transmit the challenge information to the off-chain private computing node through the oracle mechanism, or to the control node of the off-chain private computing cluster to which the off-chain private computing node belongs; make all The blockchain node receives the remote certification report returned by the off-chain privacy computing node or the control node and provides it to the client.
- the contract transmission unit 1703 is specifically configured to: enable the blockchain node to directly transmit the bytecode ciphertext to the off-chain private computing node through the oracle mechanism; or, to make the off-chain private computing node
- the blockchain node is made to transmit the bytecode ciphertext to the control node of the off-chain privacy computing cluster through the oracle mechanism, and the control node forwards it to The off-chain privacy computing node; wherein the bytecode ciphertext is also forwarded by the control node to other off-chain privacy computing nodes in the off-chain privacy computing cluster.
- the remote attestation report is triggered by the off-chain private computing node in response to a challenge from the client; or, the remote attestation report is generated by the off-chain private computing node in response to a challenge from another challenger And the trigger is generated.
- the remote attestation report is signed by the authentication server, and the remote attestation report carries the self-recommendation information, and the self-recommendation information includes a first hash value to be verified, and the first hash value to be verified
- the value is the hash value of the preset information of the off-chain trusted execution environment, and the first to-be-checked hash value is used to communicate with the client's pre-obtained credibility for the off-chain trusted execution environment.
- the hash values are compared, and the comparison result is consistent as a prerequisite for the client to confirm that the off-chain privacy computing node is trustworthy.
- a first identity forwarding unit 1704 to enable the blockchain node to receive the node identity information returned by the off-chain privacy computing node, and provide it to the client, the node identity information and the representative The secret key of the identity of the off-chain private computing node is related; wherein the self-recommendation information further includes a second to-be-verified hash value, and the second to-be-verified hash value is generated by the off-chain private computing node
- the hash value of the node identity information at the time of self-recommendation information, the second to-be-checked hash value is used for comparison with the node identity information, and the comparison result is consistent as the client confirms the off-chain privacy calculation A prerequisite for node trustworthiness.
- a second identity forwarding unit 1705 which enables the blockchain node to receive the node identity information returned by the off-chain privacy computing node, and provide it to the client, the node identity information and the representative
- the key of the identity of the off-chain private computing node is related, and the node identity information includes information related to the off-chain trusted execution environment; wherein, the remote attestation report is signed by the authentication server;
- the remote attestation report carries the self-recommendation information, the self-recommendation information includes a hash value to be verified, and the hash value to be verified is used to compare with the hash value of the node identity information obtained by the client, and the comparison result Consistency is used as a prerequisite for the client to confirm that the off-chain privacy computing node is trustworthy.
- the bytecode is encrypted by the public key of the asymmetric key pair and then transmitted, and the private key of the asymmetric key pair is maintained by the off-chain privacy computing node.
- the private key of the asymmetric key pair is only maintained by the off-chain privacy computing node, or the asymmetric secret
- the private key of the key pair is jointly maintained by all the off-chain privacy computing nodes in the off-chain privacy computing cluster.
- the device further includes: an information decryption unit 1706, which enables the blockchain node to decrypt the information obtained in the on-chain trusted execution environment.
- a result transmission unit 1708 to enable the blockchain node to receive the deployment result information returned by the off-chain privacy computing node and provide it to the client, where the deployment result information includes the chain
- the values are compared, and the comparison result is consistent as a prerequisite for the client to confirm that the off-chain contract is successfully deployed at the off-chain privacy computing node.
- the device for deploying the contract may include: a report providing unit 1801 to enable the control node of the off-chain privacy computing cluster to receive the challenge initiated by the client, and from the off-chain privacy A private off-chain computing node is selected in the computing cluster, and a remote certification report corresponding to the selected off-chain private computing node is provided to the client.
- the remote certification report is calculated by the authentication server on the selected off-chain privacy computing node.
- the self-recommendation information generated by the node is generated after verification, and the self-recommendation information is related to the off-chain trusted execution environment created on the selected off-chain private computing node; wherein, all off-chains in the off-chain private computing cluster
- the software and hardware configurations of the privacy computing nodes are consistent; the contract receiving unit 1802 enables the control node to receive the bytecode of the off-chain contract encrypted and transmitted by the client, and the bytecode is used by the client according to the remote
- the attestation report is sent when the off-chain privacy computing node in the off-chain privacy computing cluster is trusted; the contract forwarding unit 1803 enables the control node to forward the received bytecode ciphertext to the off-chain
- the bytecode ciphertext can be decrypted by each off-chain private computing node in its own off-chain trusted execution environment to obtain the bytecode, and the word The code is deployed; where, in the case that the blockchain no
- the report providing unit 1801 is specifically configured to: enable the control node to receive challenge information transmitted by the blockchain node through the oracle mechanism, the challenge information being a challenge submitted by the blockchain node from the client It is extracted from the transaction; or, the control node is made to receive the off-chain challenge initiated by the client.
- the remote attestation report is triggered by the selected off-chain privacy computing node in response to the challenge initiated by the client; or, the remote attestation report is generated by the selected off-chain privacy computing node. Nodes are triggered in response to challenges from other challengers.
- the contract receiving unit 1802 is specifically configured to: enable the control node to receive the bytecode ciphertext transmitted by the blockchain node through the oracle mechanism, and the bytecode ciphertext is sent by the blockchain node to itself
- the encrypted off-chain contract deployment transaction submitted by the client is decrypted in the created on-chain trusted execution environment; or, the control node is made to receive the bytecode encrypted and transmitted off-chain by the client.
- the selected off-chain privacy computing node is designated by the client; or, the selected off-chain privacy computing node is selected by the control node in a preset manner.
- the bytecode is encrypted by the public key of the asymmetric key pair and then transmitted, and the private key of the asymmetric key pair is transmitted by all the off-chain privacy computing nodes in the off-chain privacy computing cluster. Maintain together.
- the device further includes: an engine specifying unit 1804, which enables the control node to receive the bytecode associated with the bytecode sent by the client
- the execution engine specified information of the off-chain privacy computing cluster is forwarded to all off-chain privacy computing nodes in the off-chain privacy computing cluster.
- the execution engine specified information is used to instruct each off-chain privacy computing node to set corresponding Execution engine.
- a result receiving unit 1805 which enables the control node to receive deployment result information from any off-chain privacy computing node in the off-chain privacy computing cluster, where the deployment result information includes any off-chain privacy computing
- the node performs a hash operation on the deployed bytecode to obtain the first hash value
- the result returning unit 1806 enables the control node to return the deployment result information to the client, and the first hash value is used It is compared with the second hash value of the bytecode held by the client, and the comparison result is consistent, as the client confirms the off-chain privacy of the off-chain contract in the off-chain privacy computing cluster A prerequisite for successful deployment at the compute node.
- the device for deploying the contract may include: a verification unit 1901, which enables the client to obtain a remote certification report for a private computing node, and the remote certification report is issued by the authentication server
- the self-recommendation information generated by the private computing node is generated after verification, and the self-recommendation information is related to the trusted execution environment created on the private computing node;
- the bytecode of the smart contract is encrypted and transmitted to the private computing node, and the private computing node decrypts the bytecode in the trusted execution environment. deploy.
- the verification unit 1901 is specifically configured to: enable the client to initiate a challenge to the private computing node and receive a remote certification report returned by the private computing node; or, when the private computing node belongs to a private computing cluster In the case of enabling the client to initiate a challenge to the control node of the privacy computing cluster, and receive the remote certification report returned by the control node.
- the verification unit 1901 is specifically configured to: enable the client to initiate a challenge to the control node and the challenge target is set to the private computing node, and make the control node return the remote proof of the private computing node Report; or, make the client initiate a challenge to the control node and the challenge goal is not set, make the control node select the private computing node from the private computing cluster and return to the remote of the private computing node Proof report.
- the remote attestation report is triggered by the private computing node in response to a challenge initiated by the client; or, the remote attestation report is triggered by the private computing node in response to a challenge from another challenger produce.
- the verification unit 1901 is specifically configured to: enable the client to perform signature verification on the remote certification report according to the public key of the authentication server; after the signature is verified and the remote certification report contains the remote certification result
- the client is allowed to extract the first to-be-verified hash value from the self-recommendation information carried in the remote attestation report, and the first to-be-verified hash value is the trusted execution
- the hash value of the preset information of the environment enabling the client to compare the pre-obtained trusted hash value for the trusted execution environment with the first hash value to be verified, and the comparison result is consistent As a prerequisite for confirming the trustworthiness of the privacy computing node.
- the verification unit 1901 is specifically configured to: enable the client to obtain node identity information provided by the private computing node, where the node identity information is related to a key representing the identity of the private computing node;
- the client extracts a second hash value to be verified from the self-recommendation information carried in the remote attestation report, where the second hash value to be verified is the node identity information when the privacy computing node generates the self-recommendation information
- the hash value the client computer calculates the hash value of the node identity information obtained, compares the calculated hash value with the second hash value to be verified, and confirms that the comparison result is consistent A prerequisite for the trustworthiness of a private computing node.
- the verification unit 1901 is specifically configured to: enable the client to obtain node identity information provided by the private computing node, where the node identity information is related to a key representing the identity of the private computing node, and the Node identity information includes information related to the trusted execution environment; enables the client to perform signature verification on the remote attestation report according to the public key of the authentication server; when the signature is verified and the remote attestation report contains If the result of the remote authentication is passed authentication, the client is allowed to extract the hash value to be verified from the self-recommendation information carried in the remote attestation report, and the hash value to be verified is the privacy computing node Generate the hash value of the node identity information when the self-recommended information is generated; make the client calculate the hash value of the node identity information obtained, compare the calculated hash value with the hash value to be verified, and The consistency of the comparison result is used as a prerequisite for confirming the trustworthiness of the privacy computing node.
- the deployment unit 1902 is specifically configured to: enable the client to directly encrypt and transmit the bytecode to the private computing node; or, when the private computing node belongs to a private computing cluster, enable all The client encrypts and transmits the bytecode to the control node of the privacy computing cluster, and forwards it to the privacy computing node by the control node; wherein, the control node also forwards it to the privacy computing cluster Other privacy computing nodes.
- the bytecode is encrypted by the public key of the asymmetric key pair and then transmitted, and the private key of the asymmetric key pair is maintained by the privacy computing node.
- the private key of the asymmetric key pair is only maintained by the private computing node, or the private key of the asymmetric key pair The key is jointly maintained by all private computing nodes in the private computing cluster.
- the device further includes: an engine specifying unit 1903, which enables the client to send the execution associated with the bytecode to the privacy computing node Engine designation information, where the execution engine designation information indicates to the privacy computing node an execution engine for executing the bytecode.
- an engine specifying unit 1903 which enables the client to send the execution associated with the bytecode to the privacy computing node Engine designation information, where the execution engine designation information indicates to the privacy computing node an execution engine for executing the bytecode.
- a result receiving unit 1904 to enable the client to receive deployment result information, where the deployment result information includes a first hash obtained by the privacy computing node performing a hash operation on the deployed bytecode Value; the result verification unit 1905 enables the client to compare the first hash value with the second hash value of the bytecode held by itself, and confirm the smart contract if the comparison result is consistent The deployment is successful at the privacy computing node.
- the device for deploying the contract may include: a report providing unit 2001, which enables the privacy computing node to receive a challenge from a client and provide remote certification to the client
- the remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the private computing node, and the self-recommendation information is related to the trusted execution environment created on the private computing node
- the contract receiving unit 2002 makes The privacy computing node receives the bytecode of the smart contract encrypted and transmitted by the client, and the bytecode is sent by the client when it is determined that the privacy computing node is credible according to the remote attestation report
- the contract deployment unit 2003 enables the private computing node to decrypt the bytecode in the trusted execution environment, and deploy the bytecode.
- the report providing unit 2001 is specifically configured to: enable the private computing node to receive a challenge directly initiated by the client; or, when the private computing node belongs to a private computing cluster, enable the private computing node to Receive a challenge forwarded by the control node of the privacy computing cluster, where the challenge is initiated by the client to the control node and the challenge target is set by the client as the privacy computing node; or, enable the privacy
- the computing node receives the challenge forwarded by the control node of the privacy computing cluster.
- the challenge is initiated by the client to the control node and the challenge target is not set. Select from the computing cluster.
- it further includes: an information generating unit 2004 that enables the privacy computing node to generate the self-recommendation information in response to the challenge, and the remote attestation report is generated after the authentication server verifies the self-recommendation information;
- the private computing node is made to generate the self-recommendation information in response to a challenge from another challenger, and the remote attestation report is generated after the authentication server verifies the self-recommendation information.
- the remote attestation report is signed by the authentication server, the remote attestation report carries the self-recommendation information, and the self-recommendation information includes a first hash value to be verified, and the first hash value to be verified Is the hash value of the preset information of the trusted execution environment, and the first hash value to be checked is used to compare with the trusted hash value obtained in advance by the client for the trusted execution environment , And the comparison result is consistent as a prerequisite for the client to confirm that the privacy computing node is trustworthy.
- a first identity providing unit 2005 for enabling the private computing node to provide node identity information to the client, where the node identity information is related to a key representing the identity of the private computing node;
- the self-recommendation information further includes a second hash value to be checked, and the second hash value to be checked is the hash value of the node identity information when the privacy computing node generates the self-recommendation information, and the first 2.
- the hash value to be checked is used for comparison with the node identity information, and the consistency of the comparison result is used as a prerequisite for the client to confirm that the privacy computing node is trustworthy.
- a second identity providing unit 2006 for enabling the private computing node to provide node identity information to the client, where the node identity information is related to a key representing the identity of the private computing node, And the node identity information includes information related to the trusted execution environment; wherein, the remote attestation report is signed by the authentication server; the remote attestation report carries the self-recommendation information, and the self-recommendation information includes Check the hash value, the hash value to be checked is used to compare with the hash value of the node identity information obtained by the client, and the comparison result is consistent as the client confirms that the privacy computing node is trustworthy Prerequisites.
- the contract receiving unit 2002 is specifically configured to: enable the private computing node to directly obtain the encrypted transmission bytecode from the client; or, when the private computing node belongs to a private computing cluster , Enabling the privacy computing node to receive the bytecode ciphertext forwarded by the control node of the privacy computing cluster, and the bytecode ciphertext is transmitted by the client to the control node.
- the bytecode is encrypted by the public key of the asymmetric key pair and then transmitted, and the private key of the asymmetric key pair is maintained by the privacy computing node.
- the private key of the asymmetric key pair is only maintained by the private computing node, or the private key of the asymmetric key pair is All private computing nodes in the private computing cluster are jointly maintained.
- the device further includes: an information receiving unit 2007, which enables the privacy computing node to receive the data associated with the bytecode sent by the client Execution engine designation information; the engine setting unit 2008 enables the privacy computing node to set a corresponding execution engine for the bytecode according to the execution engine designation information.
- a result generation unit 2009 for causing the privacy computing node to generate deployment result information, where the deployment result information includes the first hash operation obtained by the privacy computing node on the deployed bytecode. Hope value; the result return unit 2010 enables the privacy computing node to return the deployment result information to the client, and the first hash value is used with the second hash value of the bytecode held by the client The desired value is compared, and the comparison result is consistent as a prerequisite for the client to confirm that the smart contract is successfully deployed at the privacy computing node.
- the device for deploying the contract may include: a report providing unit 2101 to enable the control node of the privacy computing cluster to receive the challenge initiated by the client, and from the privacy computing cluster A private computing node is selected from within, and a remote certification report corresponding to the selected private computing node is provided to the client.
- the remote certification report is verified by the authentication server after the self-recommended information generated by the selected private computing node Generated, the self-recommendation information is related to the trusted execution environment created on the selected private computing node; wherein the software and hardware configurations of all private computing nodes in the private computing cluster are consistent; the contract receiving unit 2102 makes all The control node receives the bytecode of the smart contract encrypted and transmitted by the client, and the bytecode is used by the client to determine the trustworthiness of the privacy computing node in the privacy computing cluster according to the remote attestation report
- the contract forwarding unit 2103 enables the control node to forward the received bytecode ciphertext to all the privacy computing nodes in the privacy computing cluster, and the bytecode ciphertext can be separately sent by each privacy computing node
- the bytecode is obtained by decrypting in its own trusted execution environment, and the bytecode is deployed.
- the remote attestation report is triggered by the selected private computing node in response to the challenge initiated by the client; or, the remote attestation report is generated by the selected private computing node in response to other Triggered by the challenge of the challenger.
- the selected privacy computing node is designated by the client; or, the selected privacy computing node is selected by the control node in a preset manner.
- the bytecode is encrypted by a public key of an asymmetric key pair and then transmitted, and the private key of the asymmetric key pair is jointly maintained by all private computing nodes in the privacy computing cluster.
- the device further includes: an engine specifying unit 2104, which enables the control node to receive the bytecode associated with the bytecode sent by the client
- the execution engine designation information of is forwarded to all private computing nodes in the privacy computing cluster, and the execution engine designation information is used to instruct each private computing node to set a corresponding execution engine for the bytecode.
- a result receiving unit 2105 to enable the control node to receive deployment result information from any private computing node in the private computing cluster, where the deployment result information includes any pair of private computing nodes
- the first hash value obtained by performing a hash operation on the deployed bytecode the result returning unit 2106 enables the control node to return the deployment result information to the client, and the first hash value is used with
- the second hash value of the bytecode held by the client is compared, and the comparison result is consistent as a prerequisite for the client to confirm that the smart contract is successfully deployed at the private computing node in the private computing cluster condition.
- a typical implementation device is a computer.
- the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.
- the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
- processors CPU
- input/output interfaces network interfaces
- memory volatile and non-volatile memory
- the memory may include non-permanent memory in a computer readable medium, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer readable media.
- RAM random access memory
- ROM read-only memory
- flash RAM flash memory
- Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
- the information can be computer-readable instructions, data structures, program modules, or other data.
- Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, 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.
- computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
- first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, 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)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Medical Informatics (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)
- Storage Device Security (AREA)
Abstract
一种部署合约的方法及装置,方法包括:客户端获取针对链下隐私计算节点的远程证明报告,远程证明报告由认证服务器对链下隐私计算节点产生的自荐信息进行验证后生成,自荐信息与链下隐私计算节点上创建的链下可信执行环境相关(102);客户端在根据远程证明报告确定链下隐私计算节点可信的情况下,将链下合约的字节码加密传输至链下隐私计算节点,由链下隐私计算节点在链下可信执行环境中解密得到字节码并部署(104);其中,在区块链节点通过预言机机制对链下合约发起调用的情况下,部署的字节码可在链下可信执行环境中执行,且执行结果可通过预言机机制反馈至区块链节点。本方法可以实现计算过程的隐私保护。
Description
本说明书一个或多个实施例涉及可验证计算技术领域,尤其涉及一种部署合约的方法及装置。
针对各种场景下的隐私需求,一种方式是通过同态加密(Homomorphic encryption)和零知识证明(Zero-knowledge proof)等加密技术实现隐私保护,但也随之带来了严重的性能损失。可信执行环境(Trusted Execution Environment,TEE)是另一种解决方式。TEE可以起到硬件中的黑箱作用,在TEE中执行的代码和数据操作系统层都无法偷窥,只有代码中预先定义的接口才能对其进行操作。在效率方面,由于TEE的黑箱性质,在TEE中进行运算的是明文数据,而不是同态加密中的复杂密码学运算,计算过程效率没有损失。
发明内容
有鉴于此,本说明书一个或多个实施例提供一种部署合约的方法及装置,能够在链下环境内安全实现部署合约的操作。
根据本说明书一个或多个实施例的第一方面,提出了一种部署合约的方法,包括:客户端获取针对链下隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下,将链下合约的字节码加密传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
根据本说明书一个或多个实施例的第二方面,提出了一种部署合约的方法,包括:链下隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;所述链下隐私计算节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发送;所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
根据本说明书一个或多个实施例的第三方面,提出了一种部署合约的方法,包括:区块链节点接收客户端发起的挑战交易,并向所述客户端返回链下隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;所述区块链节点接收所述客户端发起的经过加密的链下合约部署交易,在所述链上可信执行环境中解密得到所述链下合约部署交易所含的字节码密文,所述字节码密文由所述客户端对链下合约的字节码进行加密得到,所述链下合约部署交易由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发起;所述区块链节点通过预言机机制将所述字节码密文传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署;其中,在所述区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
根据本说明书一个或多个实施例的第四方面,提出了一种部署合约的方法,包括: 链下隐私计算集群的控制节点接收客户端发起的挑战,从所述链下隐私计算集群内选取一链下隐私计算节点,并向所述客户端提供被选取的链下隐私计算节点对应的远程证明报告,所述远程证明报告由认证服务器对所述被选取的链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述被选取的链下隐私计算节点上创建的链下可信执行环境相关;其中,所述链下隐私计算集群内的所有链下隐私计算节点的软硬件配置一致;所述控制节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算集群内的链下隐私计算节点可信的情况下发送;所述控制节点将收到的字节码密文分别转发至所述链下隐私计算集群内的所有链下隐私计算节点,所述字节码密文可由各个链下隐私计算节点分别在自身的链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在任一链下隐私计算节点处的链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
根据本说明书一个或多个实施例的第五方面,提出了一种部署合约的方法,包括:客户端获取针对隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述隐私计算节点上创建的可信执行环境相关;所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下,将智能合约的字节码加密传输至所述隐私计算节点,由所述隐私计算节点在所述可信执行环境中解密得到所述字节码并部署。
根据本说明书一个或多个实施例的第六方面,提出了一种部署合约的方法,包括:隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述隐私计算节点上创建的可信执行环境相关;所述隐私计算节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下发送;所述隐私计算节点在所述可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
根据本说明书一个或多个实施例的第七方面,提出了一种部署合约的方法,包括:隐私计算集群的控制节点接收客户端发起的挑战,从所述隐私计算集群内选取一隐私计算节点,并向所述客户端提供被选取的隐私计算节点对应的远程证明报告,所述远程证明报告由认证服务器对所述被选取的隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述被选取的隐私计算节点上创建的可信执行环境相关;其中,所述隐私计算集群内的所有隐私计算节点的软硬件配置一致;所述控制节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算集群内的隐私计算节点可信的情况下发送;所述控制节点将收到的字节码密文分别转发至所述隐私计算集群内的所有隐私计算节点,所述字节码密文可由各个隐私计算节点分别在自身的可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
根据本说明书一个或多个实施例的第八方面,提出了一种部署合约的装置,包括:验证单元,使客户端获取针对链下隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;部署单元,使所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下,将链下合约的字节码加密传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
根据本说明书一个或多个实施例的第九方面,提出了一种部署合约的装置,包括: 报告提供单元,使链下隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;合约接收单元,使所述链下隐私计算节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发送;合约部署单元,使所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
根据本说明书一个或多个实施例的第十方面,提出了一种部署合约的装置,包括:报告传输单元,使区块链节点接收客户端发起的挑战交易,并向所述客户端返回链下隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;合约获取单元,使所述区块链节点接收所述客户端发起的经过加密的链下合约部署交易,在所述链上可信执行环境中解密得到所述链下合约部署交易所含的字节码密文,所述字节码密文由所述客户端对链下合约的字节码进行加密得到,所述链下合约部署交易由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发起;合约传输单元,使所述区块链节点通过预言机机制将所述字节码密文传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署;其中,在所述区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
根据本说明书一个或多个实施例的第十一方面,提出了一种部署合约的装置,包括:报告提供单元,使链下隐私计算集群的控制节点接收客户端发起的挑战,从所述链下隐私计算集群内选取一链下隐私计算节点,并向所述客户端提供被选取的链下隐私计算节点对应的远程证明报告,所述远程证明报告由认证服务器对所述被选取的链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述被选取的链下隐私计算节点上创建的链下可信执行环境相关;其中,所述链下隐私计算集群内的所有链下隐私计算节点的软硬件配置一致;合约接收单元,使所述控制节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算集群内的链下隐私计算节点可信的情况下发送;合约转发单元,使所述控制节点将收到的字节码密文分别转发至所述链下隐私计算集群内的所有链下隐私计算节点,所述字节码密文可由各个链下隐私计算节点分别在自身的链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在任一链下隐私计算节点处的链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
根据本说明书一个或多个实施例的第十二方面,提出了一种部署合约的装置,包括:验证单元,使客户端获取针对隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述隐私计算节点上创建的可信执行环境相关;部署单元,使所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下,将智能合约的字节码加密传输至所述隐私计算节点,由所述隐私计算节点在所述可信执行环境中解密得到所述字节码并部署。
根据本说明书一个或多个实施例的第十三方面,提出了一种部署合约的装置,包括:报告提供单元,使隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述隐私计算节点上创建的可信执行环境相关;合约接收单元, 使所述隐私计算节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下发送;合约部署单元,使所述隐私计算节点在所述可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
根据本说明书一个或多个实施例的第十四方面,提出了一种部署合约的装置,包括:报告提供单元,使隐私计算集群的控制节点接收客户端发起的挑战,从所述隐私计算集群内选取一隐私计算节点,并向所述客户端提供被选取的隐私计算节点对应的远程证明报告,所述远程证明报告由认证服务器对所述被选取的隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述被选取的隐私计算节点上创建的可信执行环境相关;其中,所述隐私计算集群内的所有隐私计算节点的软硬件配置一致;合约接收单元,使所述控制节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算集群内的隐私计算节点可信的情况下发送;合约转发单元,使所述控制节点将收到的字节码密文分别转发至所述隐私计算集群内的所有隐私计算节点,所述字节码密文可由各个隐私计算节点分别在自身的可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
根据本说明书一个或多个实施例的第十五方面,提出了一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器通过运行所述可执行指令以实现如第一方面、第二方面、第三方面、第四方面、第五方面、第六方面或第七方面所述的方法。
根据本说明书一个或多个实施例的第十六方面,提出了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如第一方面、第二方面、第三方面、第四方面、第五方面、第六方面或第七方面所述方法的步骤。
综上所述,本说明书通过在链下隐私计算节点上实现链下可信执行环境,使得链下隐私计算节点可以提供安全可靠的运行环境,并且该链下可信执行环境的可靠性可以通过远程证明予以验证,从而能够将合约安全可靠地部署于该链下可信执行环境内,确保链下隐私计算节点安全并且忠实地完成链下隐私计算。
图1是一示例性实施例提供的一种客户端侧的部署合约的方法的流程图。
图2是一示例性实施例提供的一种实现远程证明的场景示意图。
图3是一示例性实施例提供的另一种实现远程证明的场景示意图。
图4是一示例性实施例提供的一种部署链下合约的场景示意图。
图5是一示例性实施例提供的另一种部署链下合约的场景示意图。
图6是一示例性实施例提供的一种链下隐私计算节点之间形成集群身份的示意图。
图7是一示例性实施例提供的一种调用链下合约的场景示意图。
图8是一示例性实施例提供的一种链下隐私计算节点侧的部署合约的方法的流程图。
图9是一示例性实施例提供的一种区块链节点侧的部署合约的方法的流程图。
图10是一示例性实施例提供的一种控制节点侧的部署合约的方法的流程图。
图11是一示例性实施例提供的另一种客户端侧的链下合约的部署方法的流程图。
图12是一示例性实施例提供的另一种链下隐私计算节点侧的部署合约的方法的流程图。
图13是一示例性实施例提供的另一种控制节点侧的部署合约的方法的流程图。
图14是一示例性实施例提供的一种设备的结构示意图。
图15是一示例性实施例提供的一种客户端侧的部署合约的装置的框图。
图16是一示例性实施例提供的一种链下隐私计算节点侧的部署合约的装置的框图。
图17是一示例性实施例提供的一种区块链节点侧的部署合约的装置的框图。
图18是一示例性实施例提供的一种控制节点侧的部署合约的装置的框图。
图19是一示例性实施例提供的另一种客户端侧的部署合约的装置的框图。
图20是一示例性实施例提供的另一种链下隐私计算节点侧的部署合约的装置的框图。
图21是一示例性实施例提供的另一种控制节点侧的部署合约的装置的框图。
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是:在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。
区块链一般被划分为三种类型:公有链(Public Blockchain),私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外,还有多种类型的结合,比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表,加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等,且各参与者(即节点)可自由加入以及退出网络。私有链则相反,该网络的数据写入权限由某个组织或者机构控制,数据读取权限受组织规定;简单来说,私有链可以为一个弱中心化系统,参与节点具有严格限制且少,因而私有链更适合于特定机构内部使用。联盟链则是介于公有链以及私有链之间的区块链,可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织,参与者通过授权加入网络并组成利益相关联盟,共同维护区块链运行。
在区块链网络中,通过向区块链节点提交相应的区块链交易(简称交易),并由区块链节点执行区块链交易,以实现相应的操作目的。对于上述任何类型的区块链而言,区块链节点均可以通过创建TEE,并将TEE实现为区块链交易的安全执行环境。TEE是基于CPU硬件的安全扩展,且与外部完全隔离的可信执行环境。TEE最早是由Global Platform提出的概念,用于解决移动设备上资源的安全隔离,平行于操作系统为应用程序提供可信安全的执行环境。目前工业界十分关注TEE的方案,几乎所有主流的芯片和软件联盟都有自己的TEE解决方案,比如软件方面的TPM(Trusted Platform Module,可信赖平台模块)以及硬件方面的Intel SGX(Software Guard Extensions,软件保护扩展)、ARM Trustzone(信任区)和AMD PSP(Platform Security Processor,平台安全处理器)等。
以Intel SGX(以下简称SGX)技术为例。区块链节点可以基于SGX技术创建enclave(围圈或飞地),以作为用于执行区块链交易的TEE。其中,区块链节点利用CPU中新增的处理器指令,在内存中可以分配一部分区域EPC(Enclave Page Cache,围圈页面缓存或飞地页面缓存),以用于驻留上述的enclave。上述EPC对应的内存区域被CPU内部的内存加密引擎MEE(Memory Encryption Engine)加密,该内存区域中的内容(enclave中的代码和数据)只有在CPU内核中才能够被解密,且用于加解密的密钥只有在EPC启动时生成并存储在CPU中。可见,enclave的安全边界只包含其自身和CPU,无论是特权或非特权软件都无法访问enclave,即便是操作系统管理员和VMM(virtual machine monitor,虚拟机监视器;或称为,Hypervisor)也无法影响enclave中的代码和数据,因而具有极高的安全性,并且在上述安全性保障的前提下,CPU能够在enclave 中对明文形式的区块链交易进行处理,具有极高的运算效率,从而兼顾了数据安全性和计算效率。
基于区块链网络的去中心化架构,使得区块链上的每笔区块链交易都需要在区块链网络内的所有区块链节点上执行,以确保每个区块链节点所维护的区块链账本数据一致。如果交易逻辑较为简单,比如以比特币为例,区块链交易仅用于实现转账操作,此时即便区块链交易需要在所有区块链节点都执行,也不会导致过多的资源消耗。但是,如果区块链提供了智能合约的功能,而区块链交易调用了智能合约,那么情况可能大不相同。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约,智能合约可以通过代码的形式定义。
以以太坊为例,支持用户在以太坊网络中创建并调用一些复杂的逻辑,这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM),每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机,这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上,虚拟机直接运行的是虚拟机代码(虚拟机字节码,下简称“字节码”)。智能合约分为部署和调用两个阶段。
在部署阶段,用户将一个包含创建智能合约信息的交易发送至以太坊网络,该交易的data字段包含智能合约的代码(如字节码),该交易的to字段为空。以太坊网络中的各个节点分别通过EVM执行这个交易,并生成对应的合约实例。在节点间通过共识机制达成一致后,上述交易对应的智能合约创建成功,区块链上出现一个与该智能合约对应的合约账户,该合约账户拥有一个特定的合约地址,合约代码(即智能合约的代码)或合约代码的哈希值保存在该合约账户中,该合约代码用于控制相应的智能合约的行为。
在调用阶段,用户(可以与部署智能合约的用户相同或不同)将一个用于调用智能合约的交易发送到以太坊网络,该交易的from字段是该用户对应的外部账户的地址,to字段是所需调用的智能合约的合约地址,data字段包含调用智能合约的方法和参数。在节点间通过共识机制达成一致后,上述交易声明调用的智能合约以规定的方式在以太坊网络的每个节点上独立执行,所有执行记录和数据都保存在区块链上,所以当交易完成后,区块链上就保存了无法篡改、不会丢失的交易凭证。
如前所述,EVM是一个图灵完备的虚拟机;类似地,其他区块链也可以采用其他类型的虚拟机,比如WASM(WebAssembly)虚拟机等。总之,当交易调用的智能合约用于实现相对复杂的逻辑时,节点通过虚拟机执行该智能合约的代码的过程会消耗相对较多的计算资源,并且由于区块链网络内的所有节点都需要执行该智能合约的代码,因此随着节点数量的增加会导致计算资源的消耗量成倍增长。因此,虽然结合TEE技术可以相对减少单个区块链节点的资源消耗、加快交易执行效率,但就整个区块链网络而言,仍然会造成极大的资源消耗和浪费。
为此,本说明书提出了在链下部署隐私计算节点(即链下隐私计算节点),可以将原本需要在所有区块链节点上执行的计算操作转移至链下隐私计算节点处执行,区块链节点只需要从链下隐私计算节点处获取计算结果并基于该计算结果更新区块链账本数据即可,并且可以基于可验证计算(Verifiable Computation)技术证明上述的计算结果确实是在可信执行环境内按照预期执行,从而在确保可靠性的同时,极大地降低了链上的资源消耗。
如前所述,通过在区块链节点部署智能合约,使得区块链节点可以执行该智能合约的代码以实现相应的计算需求;类似地,可以将用于执行计算任务的代码部署在链下隐私计算节点处,使得链下隐私计算节点可以执行代码以实现相应的计算需求。为了便于理解,本说明书中将部署于区块链节点的合约称为链上合约、将部署于链下隐私计算节点的合约称为链下合约;当然,无论是链上合约还是链下合约,其本质都是一段可以 在虚拟机内执行的代码。
图1是一示例性实施例提供的一种客户端侧的部署合约的方法的流程图。如图1所示,该方法可以包括步骤102~步骤104。
步骤102,客户端获取针对链下隐私计算节点的远程证明报告。
在链下隐私计算节点上创建的链下TEE,与前文所述的区块链节点上创建的链上TEE相似,都是基于CPU硬件实现的与外部完全隔离的可信执行环境。链下隐私计算节点通过创建链下TEE,可以通过该链下TEE实现对链下合约的部署操作以及部署后的调用执行操作,并确保操作过程中的数据安全和隐私保护。
远程证明报告产生于针对链下隐私计算节点上的链下TEE的远程证明过程。远程证明报告由认证服务器对链下隐私计算节点产生的自荐信息进行验证后生成,该自荐信息与链下隐私计算节点上创建的链下TEE相关。链下隐私计算节点通过产生与链下TEE相关的自荐信息,并由认证服务器对该自荐信息进行验证后产生远程证明报告,使得远程证明报告可以用于表明链下隐私计算节点上的链下TEE可信任。例如,以Intel SGX技术为例,链下TEE为链下隐私计算节点上创建的用于实现链下隐私计算的enclave,远程证明过程还涉及到链下隐私计算节点上另一个特殊的enclave,即quoting enclave(简称QE),QE是由英特尔提供并签名的架构型enclave(Architectural Enclave)。上述enclave首先需要生成一用于本地认证的REPORT(报告)结构,并由QE基于该REPORT结构验证该enclave是否与自身处于同一平台上,而后由QE将该REPORT结构封装为一结构体QUOTE(即自荐信息),并使用EPID(enhanced privacy identification)密钥进行签名。EPID密钥不仅代表链下隐私计算节点这一平台,还代表链下隐私计算节点的底层硬件的可信度,还可以绑定处理器固件的版本等信息,并且只有QE才能访问到EPID密钥,以用于对上述的结构体QUOTE进行签名。在SGX技术中,上述的认证服务器可以为英特尔公司提供的IAS(Intel Attestation Service)服务器,链下隐私计算节点向IAS服务器发送经过签名的上述结构体QUOTE,使得IAS服务器可以对签名进行验证,并向链下隐私计算节点返回相应的远程证明报告。
客户端可以向链下隐私计算节点发起挑战,并接收链下隐私计算节点返回的远程证明报告。例如,客户端可以向链下隐私计算节点发起链下挑战,即发起挑战的过程与区块链网络无关,这样可以跳过区块链节点之间的共识过程、减少链上链下的交互操作,使得客户端向链下隐私计算节点的挑战具有更高的操作效率。再例如,客户端可以采用链上挑战的形式,比如客户端可以向区块链节点提交挑战交易,该挑战交易所含的挑战信息可由区块链节点通过预言机机制传输至链下隐私计算节点,且该挑战信息用于向链下隐私计算节点发起挑战。
以如图2所示的场景为例。一种情况下,客户端21可以通过链下渠道直接向链下隐私计算节点22发起挑战,即客户端21向链下隐私计算节点22发起链下挑战。另一种情况下,客户端21可以通过区块链网络23向链下隐私计算节点22发起挑战,即客户端21向链下隐私计算节点22发起链上挑战。链上挑战的发起过程可以包括三个步骤:步骤①,客户端21向区块链网络23提交一笔用于发起挑战的交易,比如称之为挑战交易,该挑战交易可由区块链网络23内的某一节点23n接收和执行;步骤②,节点23n调用预先部署的预言机智能合约(简称预言机合约),该预言机合约可以将上述挑战交易所含的挑战信息传递至链下的预言机服务器24,比如预言机合约可以产生包含该挑战信息的事件,而预言机服务器24可以通过监听预言机合约产生的事件,从而获取上述的挑战信息;步骤③,预言机服务器24将挑战信息通过链下渠道发送至链下隐私计算节点22。
客户端21通过链上渠道向链下隐私计算节点22发起挑战时,涉及到区块链网络23与链下隐私计算节点22之间的数据交互,即链上、链下的数据交互,该数据交互过程可以由预言机合约与预言机服务器24通过上述的步骤②配合实现,该预言机合约与 预言机服务器24之间的配合机制即为预言机机制。其中,客户端21向节点23n提交的交易应当直接或间接调用上述的预言机合约,以触发预言机机制。其中,如果将预言机合约的合约地址填入该交易的to字段,表明该交易直接调用了预言机合约;如果将某一链上合约的合约地址填入该交易的to字段,且该链上合约调用了预言机合约,表明该交易间接调用了预言机合约。链上合约调用预言机合约,一种情况下可以是在链上合约的字节码中预先写入了预言机合约的合约地址,另一种情况下可以是将预言机合约的合约地址作为调用该链上合约时的入参,并将该入参填入上述交易的data字段。除了将挑战信息或其他数据从链上传递至链下,预言机机制还可以将数据从链下传递至链上,具体可由预言机服务器24将链下数据传递至预言机合约,然后由预言机合约将链下数据传递至数据需求方,比如这里的链下数据可以包括远程证明报告或者调用链下合约所产生的隐私计算结果等。在上述的预言机机制中,将数据从链上传递至链下可以视为“请求”过程,将数据从链下传递至链上可以视为“响应”过程,这两个过程通常成对出现。
无论是链下挑战或链上挑战,链下隐私计算节点在收到客户端发起的挑战后,均可以临时触发如前文所述的远程证明过程并产生相应的远程证明报告,然后将远程证明报告反馈至客户端。或者,链下隐私计算节点在收到客户端发起的挑战时,如果本地已经存在预先生成的远程证明报告,那么链下隐私计算节点将该远程证明报告提供至客户端,而无需临时触发远程证明过程。其中,链下隐私计算节点本地存在的远程证明报告,可以是该链下隐私计算节点响应于除客户端之外的其他挑战者的挑战而触发产生,比如该其他挑战者可以包括其他客户端、链下隐私计算节点所处的链下隐私计算集群中的控制节点、KMS服务器等,本说明书并不对此进行限制。因此,链下隐私计算节点在收到客户端发起的挑战后,可以首先查看本地是否存在先前生成的远程证明报告,如果存在则将该远程证明报告反馈至客户端,否则临时触发远程证明过程。其中,远程证明报告可以具有一定的时限性,比如30分钟或其他时长,超时的远程证明报告可以被客户端认定为失效,链下隐私计算节点也可以主动清除已失效的远程证明报告以避免反馈至客户端。
客户端向链下隐私计算节点发起挑战的过程中,或者链下隐私计算节点向客户端反馈远程证明报告的过程中,涉及到设备之间的数据交互。以图2所示的场景为例,所涉及的数据交互可以包括:客户端21与链下隐私计算节点22之间的数据交互(客户端21向链下隐私计算节点22发起链下挑战,链下隐私计算节点22向客户端21返回远程证明报告)、客户端21与节点23n之间的数据交互(客户端21向节点23n发送挑战交易、节点23n向客户端21返回远程证明报告)、节点23n与预言机服务器24之间的数据交互(预言机服务器24从节点23n读取挑战信息、预言机服务器24向节点23n反馈远程证明报告)、预言机服务器24与链下隐私计算节点22之间的数据交互(预言机服务器24向链下隐私计算节点22发送挑战信息、链下隐私计算节点22向预言机服务器24返回远程证明报告)等。在实现上述任一数据交互的过程中,数据发送方与数据接收方之间传输的数据存在泄漏的可能性,并且节点23n会将挑战交易上链导致该挑战交易被公开,因此可以通过对数据进行加密传输的方式,避免造成信息泄露。
以客户端21向节点23n提交挑战交易为例。通过挑战交易向链下隐私计算节点22发起链上挑战,使得节点23n可以将客户端21提交的挑战交易与其他节点进行共识后上链,对客户端21的挑战行为进行存证。但是,如果客户端21并不希望自己的挑战行为被其他用户随意获知,可以对挑战交易进行隐私保护。客户端21可以对挑战交易进行加密,而节点23n可以接收经过加密的挑战交易,这样可以确保传输过程中不会造成挑战交易的内容泄露。节点23n处可以部署链上TEE,并且节点23n可以将经过加密的挑战交易读入该链上TEE后,在链上TEE内解密,可以确保解密得到的挑战交易仅存在于链上TEE内、不会外泄。节点23n直接将经过加密的挑战交易上链,并且通过对加密数据的查看权限进行管理,可以限制能够查看挑战交易的用户,而其他用户直接查 看区块链数据时仅能够获得加密后的挑战交易。实际上,节点23n可以确保需要隐私保护的数据仅在链上TEE内能够被解密为明文形式,一旦离开链上TEE均采用密文形式。
针对挑战交易的加密传输,可以采用对称加密或非对称加密的形式。当采用对称加密时,客户端21和节点23n分别维护有相同的对称密钥,比如该对称密钥可由客户端21与节点23n通过诸如DH(Diffie-Hellman)或ECDH(Elliptic Curve Diffie–Hellman)等算法协商得到,或者由KMS(Key Management Service,密钥管理服务)服务器分发至客户端21和节点23n,本说明书并不限制密钥来源。当密钥由KMS服务器分发时,KMS服务器可以通过远程证明的方式确定节点23n处的链上TEE可信,然后将密钥加密传输至该链上TEE内,远程证明的方式与客户端21对链下隐私计算节点22的远程证明过程类似,此处暂不赘述。那么,客户端21可以通过上述的对称密钥对挑战交易进行加密,而节点23n将对称密钥维护于链上TEE中,因而将经过加密的挑战交易读入链上TEE内,并通过该对称密钥执行解密操作得到上述的挑战交易。对称加密采用的加密算法,例如可以包括DES算法,3DES算法,TDEA算法,Blowfish算法,RC5算法,IDEA算法等。
当采用非对称加密时,节点23n维护有非对称密钥的私钥,比如称之为节点私钥,而客户端21可以获得该节点私钥对应的节点公钥。非对称密钥可由节点23n在链上TEE内生成,或者由KMS服务器分发至该节点23n,本说明书并不限制密钥来源。类似地,当密钥由KMS服务器分发时,KMS服务器可以通过远程证明的方式确定节点23n处的链上TEE可信,然后将密钥加密传输至该链上TEE内。那么,客户端21可以通过节点公钥对挑战交易进行加密,而节点23n将节点私钥维护于链上TEE中,因而将经过加密的挑战交易读入链上TEE内,并通过节点私钥执行解密操作得到上述的挑战交易。非对称加密采用的非对称加密算法,例如可以包括RSA、Elgamal、背包算法、Rabin、D-H、ECC(椭圆曲线加密算法)等。
针对挑战交易的加密传输,还可以采用对称加密与非对称加密相结合的形式。客户端21可以维护一对称密钥,比如该对称密钥可由客户端21随机生成,且客户端21可以获得上述非对称密钥中的公钥。客户端21可以通过对称密钥对挑战交易进行加密、得到加密后挑战交易,并通过非对称密钥加密该对称密钥、得到加密后密钥,然后客户端21同时将加密后挑战交易与加密后密钥传输至节点23n。相应的,节点23n将加密后挑战交易与加密后密钥读入链上TEE内,首先通过节点私钥对加密后密钥进行解密、得到对称密钥,然后通过对称密钥对加密后挑战交易进行解密。相比较而言,对称加密的加解密效率相对更高、但安全性相对较低,而非对称加密的加解密效率相对较低、但安全性相对更高,因此基于对称加密与非对称加密相结合的形式,可以兼顾加解密效率与安全性。
类似地,在其他数据交互的过程中,通过使得数据发送方与数据接收方之间维护相同的对称密钥,或者使得数据发送方维护有非对称密钥的公钥、数据接收方维护有非对称密钥的私钥,或者结合对称加密与非对称加密的形式,可以实现任意的数据发送方与数据接收方之间的数据加密传输,此处不再赘述。
链下隐私计算节点可能属于链下隐私计算集群,该链下隐私计算集群包含多个链下隐私计算节点。如果各个链下隐私计算节点之间完全独立,那么客户端与单个链下隐私计算节点之间的交互过程可以参考上文所述的实施例。而另一种方式下,链下隐私计算集群可以包含一控制节点,并由该控制节点对集群内的所有链下隐私计算节点进行统一管理。比如,客户端可以向控制节点发起挑战,并接收控制节点返回的上述链下隐私计算节点的远程证明报告。与前述实施例相类似的,客户端可以向控制节点发起链下挑战,或者客户端可以向区块链节点提交挑战交易,该挑战交易所含的挑战信息由区块链节点通过预言机机制传输至控制节点,使得控制节点向客户端返回链下隐私计算节点的远程证明报告。
以如图3所示的场景为例。一种情况下,客户端31可以通过链下渠道直接向控制节点32发起挑战,即客户端31向控制节点32发起链下挑战。另一种情况下,客户端31可以通过区块链网络33向控制节点32发起挑战,即客户端31向控制节点32发起链上挑战。链上挑战的发起过程可以包括三个步骤:步骤①,客户端31向区块链网络33提交一笔用于发起挑战的交易,比如称之为挑战交易,该挑战交易可由区块链网络33内的某一节点33n接收和执行;步骤②,节点33n调用预先部署的预言机智能合约(简称预言机合约),该预言机合约可以将上述挑战交易所含的挑战信息传递至链下的预言机服务器34,比如预言机合约可以产生包含该挑战信息的事件,而预言机服务器34可以通过监听预言机合约产生的事件,从而获取上述的挑战信息;步骤③,预言机服务器34将挑战信息通过链下渠道发送至控制节点32。
客户端31向控制节点32发起挑战时,可以将挑战目标设定为控制节点32所处集群内的某一链下隐私计算节点,比如链下隐私计算节点32n,那么控制节点32会根据收到的挑战,向客户端31返回链下隐私计算节点32n对应的远程证明报告。客户端31也可以不设定挑战目标,那么控制节点32收到挑战后,从链下隐私计算集群中进行选择,比如在选取了链下隐私计算节点32n的情况下,向客户端31返回该链下隐私计算节点32n对应的远程证明报告。
其中,控制节点32在收到客户端31发起的挑战后,可以将该挑战转发至链下隐私计算节点32n,使得链下隐私计算节点32n临时触发远程证明过程,以产生相应的远程证明报告,然后通过控制节点32反馈至客户端31。或者,控制节点32在收到客户端31发起的挑战后,可以将该挑战转发至链下隐私计算节点32n,而如果链下隐私计算节点32n上已经存在预先生成的远程证明报告,那么链下隐私计算节点32n将该远程证明报告返回控制节点32,由控制节点32提供至客户端31,而无需临时触发远程证明过程。或者,控制节点32在收到客户端31发起的挑战后,如果本地已经存在预先生成的对应于链下隐私计算节点32n的远程证明报告,那么链下隐私计算节点32n将该远程证明报告提供至客户端31,而无需向链下隐私计算节点32n转发挑战,也无需链下隐私计算节点32n因此临时触发远程证明过程。其中,链下隐私计算节点32n本地存在的远程证明报告,可以是该链下隐私计算节点32n响应于除客户端31之外的其他挑战者的挑战而触发产生,比如该其他挑战者可以包括其他客户端、控制节点32、KMS服务器等,本说明书并不对此进行限制。而链下隐私计算节点32n通过控制节点32将远程证明报告提供至上述的其他挑战者时,控制节点32可以对收到的远程证明报告进行缓存。因此,控制节点32在收到客户端31发起的挑战后,可以首先查看查看本地是否存在先前获得的远程证明报告,如果存在则将该远程证明报告反馈至客户端31,否则将挑战转发至链下隐私计算节点32n;以及,链下隐私计算节点32n在收到挑战后,可以首先查看查看本地是否存在先前获得的远程证明报告,如果存在则将该远程证明报告反馈至控制节点32,否则临时触发远程证明过程。其中,远程证明报告可以具有一定的时限性,比如30分钟或其他时长,超时的远程证明报告可以被客户端31认定为失效,控制节点32或链下隐私计算节点32n也可以主动清除已失效的远程证明报告以避免反馈至客户端31。
在图3所示的实施例中,客户端31与控制节点32之间、控制节点32与链下隐私计算节点32n之间、客户端31与节点33n之间、节点33n与预言机服务器34之间、预言机服务器34与控制节点32之间等,均可能产生数据交互。对于任意的数据交互过程,均可以采用如前文所述的加密数据传输方案,包括对称加密、非对称加密或两者结合的形式,此处不再赘述。
步骤104,所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下,将链下合约的字节码加密传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署。
客户端在获得链下隐私计算节点的远程证明报告之后,可以根据该远程证明报告 来验证相应的链下隐私计算节点是否可信,具体指该链下隐私计算节点上部署的链下TEE是否可信。
如前所述,链下隐私计算节点创建链下TEE后,产生用于实现远程证明的自荐信息,该自荐信息可以用于锚定和固化链下TEE的信息,使得最终得到的包含该自荐信息的远程证明报告可以用于表征链下TEE的状态,并用于验证该链下TEE是否可信。例如,自荐信息中可以包含第一待检验哈希值,该第一待检验哈希值为链下TEE的预设信息的哈希值,比如该预设信息可以包括链下TEE内部署的所有代码、该链下TEE的开发者的公钥等。以Intel SGX技术为例,对应于链下TEE内部署的所有代码所生成的哈希值为MREnclave,对应于链下TEE的开发者的公钥所生成的哈希值为MRSigner,即第一待检验哈希值可以包括MREnclave和MRSigner。
仍以Intel SGX技术为例。如前所述,链下隐私计算节点向IAS服务器发送经过签名的结构体QUOTE后,由IAS服务器根据所维护的公钥集合进行签名验证,并向链下隐私计算节点返回远程证明报告(即AVR报告),该远程证明报告中包含:结构体QUOTE和签名验证结果,并且IAS服务器采用自身持有的私钥对该远程证明报告进行签名。
相应地,客户端在获取远程证明报告后,可以首先根据IAS服务器的公钥对该远程证明报告进行签名验证,如果验证通过则表明该远程证明报告确实由IAS服务器生成,且在数据传输过程中未被篡改或丢失数据。客户端可以通过任意途径获得IAS服务器的公钥,譬如远程证明报告被提供至客户端时,还可以关联提供IAS的证书链,使得客户端可以从该证书链中提取IAS服务器的公钥。然后,客户端可以从远程证明报告中提取结构体QUOTE和签名验证结果。客户端可以首先查看签名验证结果,如果签名验证结果为通过验证,表明链下隐私计算节点的CPU持有由Intel提供的私钥,因而链下TEE建立在可靠的硬件平台上,可以继续执行其他验证操作;如果签名验证结果为未通过验证,客户端可以判定链下隐私计算平台不可靠,无需继续其他验证操作。然后,客户端可以从结构体QUOTE内提取上述的哈希值MREnclave和MRSigner,即待检验MREnclave和待检验MRSigner;同时,客户端预先获得了链下TEE的MREnclave和MRSigner的可信值,比如称之为可信MREnclave和可信MRSigner,并将待检验MREnclave与可信MREnclave进行比较、将待检验MRSigner与可信MRSigner进行比较。那么,客户端可以将“待检验MREnclave与可信MREnclave一致,且待检验MRSigner与可信MRSigner一致”作为确认链下隐私计算节点可信的前提条件;换言之,如果待检验MREnclave与可信MREnclave不一致,或者待检验MRSigner与可信MRSigner不一致,客户端就判定链下隐私计算节点不可信,而如果客户端设定的所有前提条件都被满足,就可以确认链下隐私计算节点可信。此外,客户端对于签名验证结果进行验证的操作,与针对待检验MREnclave和待检验MRSigner进行验证的操作之间,并不存在必然的先后顺序,两者之间可以完全独立。
除了MREnclave和MRSigner之外,客户端还可以通过其他的前提条件对链下隐私计算节点的可信度进行验证。例如,链下隐私计算节点在创建链下TEE后,可以在链下TEE内生成代表自身的身份信息的密钥对,并且链下隐私计算节点在链下TEE中创建自身的节点身份信息,该节点身份信息与上述对应于身份信息的密钥对相关,比如该节点身份信息可以包含该密钥对中的公钥。其中,代表身份信息的密钥对可以存在一组或多组,比如一组密钥对为用于签名与验签的密钥对(即签名密钥对),一组密钥对为用于加密与解密的密钥对(即加密密钥对),则节点身份信息可以包括签名密钥对中的签名公钥和加密密钥对中的加密公钥。在一组密钥对中,对应于不同的加密算法,可能同时存在多个公钥,这些公钥均被包含于上述的节点身份信息中。此外,节点身份信息还可以包含其他与链下隐私计算节点相关的信息,比如软件版本、所在域名、所在分区名等,本说明书并不对此进行限制。那么,链下隐私计算节点在生成结构体QUOTE时, 可以计算上述节点身份信息的哈希值,并将该哈希值作为第二待检验哈希值添加至结构体QUOTE中。
相应地,客户端在收到远程证明报告后,可以从该远程证明报告进行签名验证。在签名验证通过的情况下,客户端可以提取远程证明报告所含的签名验证结果和第二待检验哈希值,并分别予以验证,且对于两者的验证并不存在必然的先后顺序,两者之间可以完全独立。假定客户端首先验证签名验证结果,并在签名验证结果为通过验证的情况下,继续对第二待检验哈希值进行验证。为了对第二待检验哈希值进行验证,客户端需要获取链下隐私计算节点的节点身份信息,比如远程证明报告被提供至客户端的同时,可以关联提供节点身份信息,当然客户端也可以通过其他方式或在其他时刻获得该节点身份信息。然后,客户端可以对获得的节点身份信息进行哈希计算,将计算得到的哈希值与上述的第二待检验哈希值进行比较,并将比较结果一致作为确认链下隐私计算节点可信的前提条件。如果第二待检验哈希值通过验证,可以证明链下隐私计算节点的身份信息是在链下TEE内初始化生成,上述代表身份信息的密钥对中的私钥仅由链下隐私计算节点所拥有,且该链下隐私计算节点能够完成签名、加密通讯等操作。
以上列举了两种针对链下隐私计算节点进行验证时采用的判断条件,即针对第一待检验哈希值的验证、针对第二待检验哈希值的验证。还可以采用其他的判断条件,此处不再一一列举。在针对链下隐私计算节点进行可信验证时,可以选用上述的一个或多个判断条件。例如,可以同时针对第一待检验哈希值和第二待检验哈希值进行验证;或者,在一些情况下,可以仅验证第二待检验哈希值,而对第一待检验哈希值可以不验证或者部分验证。例如,客户端上可以设置信任等级,并根据信任等级确定是否验证或部分验证第一待检验哈希值,比如信任等级为0时,不需要验证第一待检验哈希值,信任等级为1时,验证第一待检验哈希值中的MRSigner,信任等级为2时,验证第一待检验哈希值中的MREnclave等。
在上述实施例中,节点身份信息包含了链下隐私计算节点的身份相关的信息,比如代表身份的公钥等。节点身份信息还可以包含与链下TEE相关的信息,那么对节点身份信息进行哈希计算,并将得到的待检验哈希值添加至结构体QUOTE时,该待检验哈希值相当于同时实现了上述第一待检验哈希值和第二待检验哈希值的作用。例如,节点身份信息除了包含签名公钥和加密公钥等信息之外,还可以包含MREnclave和MRSigner的值,使得对该节点身份信息进行哈希计算得到的待检验哈希值,同时与链下隐私计算节点的身份、链下TEE相关。相应的,客户端在收到远程证明报告后,可以从该远程证明报告进行签名验证。在签名验证通过的情况下,客户端可以提取远程证明报告所含的签名验证结果和待检验哈希值,并分别予以验证,且对于两者的验证并不存在必然的先后顺序,两者之间可以完全独立。假定客户端首先验证签名验证结果,并在签名验证结果为通过验证的情况下,继续对待检验哈希值进行验证。为了对待检验哈希值进行验证,客户端需要获取链下隐私计算节点的节点身份信息,此处不再赘述。然后,客户端可以对获得的节点身份信息进行哈希计算,将计算得到的哈希值与上述的待检验哈希值进行比较,并将比较结果一致作为确认链下隐私计算节点可信的前提条件。可见,本实施例仅需一次比较,即可实现前文中两方面的验证,有助于提升验证效率。
客户端对远程证明报告的验证过程,还可以包括其他操作,比如根据远程证明报告的内容确定链下TEE是否运行于测试模式(测试模式下存在数据泄露的风险)等,此处不再一一赘述。
基于上述方案,客户端在确定链下隐私计算节点可信的情况下,可以向链下隐私计算节点部署链下合约。链下合约与区块链节点所执行的链上合约类似,均可以为运行于虚拟机中的字节码,此处不再赘述。通过对链下合约的字节码进行加密传输,可以避免在传输过程中发生数据泄露或修改等,确保隐私性和安全性。
与前述的挑战过程相类似的,客户端可以通过链下途径将链下合约的字节码加密 传输至链下隐私计算节点,即针对字节码的传输过程与区块链网络无关,这样可以跳过区块链节点之间的共识过程、减少链上链下的交互操作,使得字节码的传输效率更高。或者,客户端可以通过链上途径将链下合约的字节码加密传输至链下隐私计算节点,比如客户端生成链下合约部署交易,该链下合约部署交易中包含对字节码进行加密得到的字节码密文,客户端将链下合约部署交易加密后提交至区块链节点,加密后的链下合约部署交易可在区块链节点处创建的链上TEE内被解密、得到字节码密文,然后由区块链节点通过预言机机制将该字节码密文传输至链下隐私计算节点。
以如图4所示的场景为例。一种情况下,客户端41可以通过链下渠道直接向链下隐私计算节点42加密传输字节码,即客户端41向链下隐私计算节点42链下传输加密后的字节码密文。另一种情况下,客户端41可以通过区块链网络43向链下隐私计算节点42加密传输字节码,即客户端41向链下隐私计算节点42链上传输加密后的字节码密文。链上加密传输的过程可以包括三个步骤:步骤①,客户端41向区块链网络43提交一笔用于部署链下合约的交易,即链下合约部署交易,该链下合约部署交易可由区块链网络43内的某一节点43n接收和执行;步骤②,节点43n调用预言机合约,该预言机合约可以将上述链下合约部署交易所含的字节码传递至链下的预言机服务器44,比如预言机合约可以产生包含该字节码的事件,而预言机服务器44可以通过监听预言机合约产生的事件,从而获取上述的字节码;步骤③,预言机服务器44将字节码通过链下渠道发送至链下隐私计算节点42。
在链下加密传输的过程中,仅涉及到客户端41与链下隐私计算节点42之间的数据交互,可以采用如前文所述的对称加密、非对称加密或两者结合的加密传输方案,此处不再赘述。在链上加密传输的过程中,涉及到多个对象之间的数据交互,需要确保字节码始终处于加密状态。例如,在客户端41向节点43n提交链下合约部署交易时,可以通过如前文所述的对称加密、非对称加密或两者结合的加密传输方案对该链下合约部署交易进行加密传输,使得链下合约部署交易所含的字节码处于加密保护状态。其中,链下合约部署交易所含的字节码可能处于明文状态或密文状态。如果处于密文状态,表明客户端41对字节码进行加密后,将字节码密文添加至链下合约部署交易的data字段,并且客户端41应当确保该字节码密文仅最终环节的链下隐私计算节点42能够解密,而其他的节点43n、预言机服务器44等均无法解密,那么节点43n在自身创建的链上TEE内对链下合约部署交易进行解密后得到字节码密文后,预言机服务器44可以直接读取该字节码密文,然后由预言机服务器44将该字节码密文传输至链下隐私计算节点42。如果处于明文状态,表明客户端41直接将明文的字节码添加至链下合约部署交易的data字段,而该链下合约部署交易可以调用一链上合约,那么节点43n在链上TEE内对链下合约部署交易进行解密后得到明文的字节码后,可以通过链上TEE内部署的虚拟机执行上述链上合约,从而在链上TEE内将字节码加密为相应的字节码密文,并确保该字节码密文仅能够由链下隐私计算节点42能够解密,然后由预言机服务器44读取该字节码密文,并进而将该字节码密文传输至链下隐私计算节点42。
针对字节码进行加密时,可以采用对称加密、非对称加密或两者结合的方式,本说明书并不对此进行限制。当采用非对称加密或者对称加密与非对称加密结合的方式时,涉及到一组非对称密钥对,客户端41或节点43n需要获知该非对称密钥对的公钥,且该非对称密钥对的私钥需要由链下隐私计算节点42所维护,使得该链下隐私计算节点42可以基于该私钥对收到的字节码密文进行解密。例如,该非对称密钥对可以为前文所述的、链下隐私计算节点42在链下TEE中产生的加密密钥对;相应地,链下隐私计算节点42在收到字节码密文后,将该字节码密文读入链下TEE中,并基于加密私钥对该字节码密文进行解密,从而得到明文的字节码。
链下隐私计算节点42在链下TEE中解密得到明文的字节码后,可以在链下TEE中对字节码进行重新加密后,存储至链下TEE之外的存储空间,比如链下隐私计算节 点42的硬盘中,从而完成对链下合约的部署。此处,链下隐私计算节点42通常采用一对称密钥,通过对称加密的方式对字节码进行加密并存储,这样在后续调用该字节码时,相比于采用非对称加密的形式而言,可以更快地完成解密操作。该对称密钥可由链下隐私计算节点42在链下TEE中生成,或者由其他对象通过加密传输的方式分发至链下隐私计算节点42。例如,可由KMS服务器对链下隐私计算节点42发起挑战,并通过远程证明验证该链下隐私计算节点42可信的情况下,向该链下隐私计算节点42分发上述的对称密钥。链下隐私计算节点42可以将KMS服务器分发的对称密钥作为根密钥,并将基于该根密钥派生得到的衍生密钥应用于针对字节码的加密存储。再例如,基于Intel SGX技术,上述对称密钥可以为烧录于链下隐私计算节点42的CPU内e-fuses存储电路中的RSK(Root Seal Key)密钥,或者该RSK密钥派生得到的衍生密钥(即Seal Key)。当然,链下隐私计算节点42也可以采用非对称加密或者对称加密与非对称加密结合的方式,对字节码进行加密存储,本说明书并不对此进行限制。
除了在链下隐私计算节点42处安全存储链下合约的字节码之外,客户端41还可以向链下隐私计算节点42指明用于执行该字节码的执行引擎。例如,在链下隐私计算节点42处创建的链下TEE中,可以部署有若干执行引擎,比如EVM、WASM虚拟机等中的一个或多个,尤其是在同时部署了多种执行引擎的情况下,客户端41可以向链下隐私计算节点42发送与上述字节码相关联的执行引擎指定信息,该执行引擎指定信息向链下隐私计算节点42指示用于执行上述字节码的执行引擎,比如采用EVM还是WSAM虚拟机等。例如,可以将字节码与执行引擎指定信息打包加密后,一并传输至链下隐私计算节点42;也可以分别对字节码和执行引擎指定信息进行加密传输,此时执行引擎指定信息应当包含相应的字节码或者链下合约的信息,比如字节码的哈希值等,以便于据此确定执行引擎指定信息对应于哪个链下合约。相应的,链下隐私计算节点42在部署链下合约时,除了对字节码进行加密存储之外,还需标注出字节码所需采用的执行引擎的信息,从而在后续的调用过程中据此选用恰当的虚拟机,以作为处理相应字节码的执行引擎。
通过上述方式,客户端41可以向链下隐私计算节点42部署更多的链下合约;类似地,其他客户端也可以向链下隐私计算节点42部署链下合约。为了便于管理,以及便于后续对链下合约进行调用,链下隐私计算节点42可以为部署的链下合约生成相应的合约ID,链下合约与合约ID之间一一对应。例如,在完成针对链下合约的部署操作后,链下隐私计算节点42可以对该链下合约的字节码进行哈希运算,得到第一哈希值,并将该第一哈希值作为该链下合约的合约ID。当然,链下隐私计算节点42也可以通过其他方式生成合约ID,本说明书并不对此进行限制。
如果将上述的第一哈希值作为链下合约的合约ID,那么该第一哈希值还可以具有其他作用。在完成部署后,链下隐私计算节点42可以向客户端41反馈部署结果信息,该部署结果信息包含上述的第一哈希值,而客户端41还可以对自己发出的字节码进行哈希计算得到第二哈希值,并将第一哈希值与第二哈希值进行比较:如果两者一致,表明链下隐私计算节点42部署的字节码正确无误,没有在传输过程中被替换或者发生其他意外,客户端41可以确认链下合约在链下隐私计算节点42处部署成功;而如果两者不一致,客户端41可以认为链下合约部署失败,或者已部署的链下合约存在风险。客户端41可以将成功部署的链下合约标记为可信合约,将未成功部署的链下合约标记为不可信合约或不维护,从而在后续过程中仅针对可信合约进行调用。如果客户端41将字节码通过链下途径传输至链下隐私计算节点42,那么链下隐私计算节点42同样通过链下途径将部署结果信息返回至客户端41;如果客户端41将字节码通过链上途径传输至链下隐私计算节点42,那么链下隐私计算节点42同样通过链上途径将部署结果信息反馈至客户端41。
如前所述,链下隐私计算节点可以属于链下隐私计算集群。如果各个链下隐私计 算节点之间完全独立,那么客户端分别与每个链下隐私计算节点进行交互,并实现对链上合约的部署操作,且客户端与每个链下隐私计算节点之间的交互过程均可以参考图4所示的实施例,此处不再赘述。而另一种方式下,由控制节点对集群内的所有链下隐私计算节点进行统一管理,那么客户端在部署链上合约的过程中,首先将字节码加密传输至控制节点,然后由控制节点转发至集群内的一个或多个链下隐私计算节点,从而将链上合约的字节码部署至集群内的一个或多个链下隐私计算节点。如果部署至多个链下隐私计算节点,那么这些链下隐私计算节点可以同时向外提供针对同一链下合约的调用能力,从而实现并行的链下隐私计算,还可以在多个链下隐私计算节点之间实现负载均衡。
以如图5所示的场景为例。一种情况下,客户端51可以通过链下渠道直接向控制节点52发送字节码密文,即客户端51向控制节点52链下加密传输字节码,进而由控制节点52转发至集群内的一个或多个链下隐私计算节点。另一种情况下,客户端51可以通过区块链网络53向控制节点52加密传输字节码,即客户端51向控制节点52链上传输加密后的字节码密文。链上加密传输的过程可以包括三个步骤:步骤①,客户端51向区块链网络53提交一笔用于部署链下合约的交易,即链下合约部署交易,该链下合约部署交易可由区块链网络53内的某一节点53n接收和执行;步骤②,节点53n调用预言机合约,该预言机合约可以将上述链下合约部署交易所含的字节码传递至链下的预言机服务器54,比如预言机合约可以产生包含该字节码的事件,而预言机服务器54可以通过监听预言机合约产生的事件,从而获取上述的字节码;步骤③,预言机服务器54将字节码通过链下渠道发送至控制节点52,并进而由控制节点52转发至集群内的一个或多个链下隐私计算节点。
如果仅需部署至一个链下隐私计算节点,比如图5所示的链下隐私计算节点52n,那么与图4所示实施例相类似的,客户端51或节点53n在针对字节码进行加密时,只需要确保该链下隐私计算节点52n能够解密即可。例如,可以采用该链下隐私计算节点52n在链下TEE内生成的加密公钥对字节码进行加密,而链下隐私计算节点52n在收到字节码密文后,可以在链下TEE内通过加密私钥对该字节码密文进行解密,从而获得明文的字节码。同时,客户端51可以携带部署目标指示信息,控制节点52可以根据该部署目标指示信息确定相应的部署目标为链下隐私计算节点52n,从而将字节码密文准确转发至该链下隐私计算节点52n,而无需转发至集群内其他的链下隐私计算节点。如果客户端51并未携带部署目标指示信息,控制节点52可以将字节码密文转发至集群内的所有链下隐私计算节点,但只有链下隐私计算节点52n能够成功解密并完成部署。
如果需要部署至集群内的多个链下隐私计算节点,除了独立部署的方式之外,本说明书中还可以将链下合约同时向多个链下隐私计算节点进行安全部署。如前所述,每个链下隐私计算节点都存在各自的节点身份信息,且节点身份信息涉及到每个链下隐私计算节点在各自的链下TEE内创建的密钥对,比如加密密钥对和签名密钥对,或者兼顾加密与签名功能的密钥对。下面以加密密钥对和签名密钥对为例进行说明。为了将链下合约同时向多个链下隐私计算节点进行安全部署,需要确保多个链下隐私计算节点都能够顺利解密收到的字节码密文。为此,需要为这些链下隐私计算节点生成统一的身份信息,比如称为集群身份信息。集群身份信息可以包括集群加密密钥对和集群签名密钥对,上述的各个链下隐私计算节点均需在各自的链下TEE内维护集群加密私钥、集群签名私钥,那么客户端51或节点53n只要使用集群加密公钥对字节码进行加密,即可确保上述的各个链下隐私计算节点均能够在各自的链下TEE内通过集群加密私钥进行解密,从而获得字节码并完成部署。当然,即便仅部署至单个链下隐私计算节点,也可以采用上述的集群加密公钥对字节码进行加密,只要相应的链下隐私计算节点能够顺利解密即可。实际上,基于集群身份,客户端51并不需要关注对方为单个链下隐私计算节点或者链下隐私计算集群,只需要将其作为一个对象并与该对象进行交互即可,无需关注于背后的节点或集群的细节。
此外,在前文所述的挑战过程中,如果需要将挑战发送至链下隐私计算节点,而非由控制节点直接反馈远程证明报告,那么也可以采用集群加密公钥对挑战信息进行加密,只要相应的链下隐私计算节点能够顺利解密即可。但是,如果希望控制节点直接反馈远程证明报告(预先获得的远程证明报告,或者由控制节点向链下隐私计算节点发起挑战而得到),则应当采用控制节点的身份公钥对挑战信息进行加密,确保控制节点能够在自身创建的TEE内通过身份私钥实现解密。
如图6所示,假定链下隐私计算集群中包括节点60、节点61、节点62等若干链下隐私计算节点,需要在这些节点之间建立统一的集群身份。首先,每个链下隐私计算节点分别创建链下TEE,并分别在各自的链下TEE内创建节点身份,比如节点60创建了TEE1,并在TEE1内创建了代表自身节点身份的密钥对Key-0,节点61创建了TEE2,并在TEE1内创建了代表自身节点身份的密钥对Key-1、节点62创建了TEE3,并在TEE1内创建了代表自身节点身份的密钥对Key-2等。各个链下隐私计算节点加入集群的时机往往不同,因而创建链下TEE和节点身份的时机也不同。通常,节点需要向链下隐私集群的控制节点发起申请,而控制节点会向发出申请的节点发起挑战,以验证该节点的硬件环境、链下TEE内运行的软件等,并在验证通过后将该节点加入链下隐私计算集群,使得该节点成为链下隐私计算节点。
在需要生成集群身份时,控制节点可以将某一链下隐私计算节点选取为主节点、其他的链下隐私计算节点为从节点,由主节点生成代表集群身份的密钥对,并进而将该密钥对分享至各个从节点,最终使得所有链下隐私计算节点都维护了统一的、代表集群身份的密钥对。如图6所示,假定节点60被选取为主节点、节点61-62等为从节点。首先,节点60在TEE1内生成代表集群身份的密钥对,即集群身份密钥对C-Key。然后,节点60分别向各个从节点发起挑战,使得节点61、节点62等从节点分别生成远程证明报告,该过程可以参考前文所述,此处不再赘述。在远程证明报告内可以包含MREnclave、MRSigner、节点身份信息的哈希值等信息。节点60分别接收各个从节点返回的远程证明报告和节点身份信息,并通过如前文所述的方式进行验证,以确定各个从节点是否可信。
以节点61为例,假定节点60通过远程证明的方式确定该节点61可信。在上述代表节点60身份的密钥对Key-0中,譬如包含一组签名密钥对Key-0-S和一组加密密钥对Key-0-T,节点60可以采用签名密钥对Key-0-S中的签名私钥对上述的集群身份密钥对C-Key进行签名。同时,在节点61向节点60提供的节点身份信息中,包含代表节点61身份的密钥对Key-1中的公钥,比如签名密钥对Key-1-S中的签名公钥、加密密钥对Key-1-T中的加密公钥。因此,节点60可以采用加密密钥对Key-1-T中的加密公钥,对上述的集群身份密钥对C-Key及其签名数据进行加密,得到加密后密钥对,并发送至节点61。
节点60也基于前文所述的方式,触发获得针对自身创建的TEE1而生成的远程证明报告,而节点60除了向节点61发送上述的加密后密钥对之外,还将该远程证明报告以及节点60自身的节点身份信息发送至节点61,以供节点61对该节点60进行验证。而节点61在验证确定节点60可信的情况下,通过自身维护的加密密钥对Key-1-T中的加密私钥对收到的加密后密钥对进行解密,得到集群身份密钥对C-Key及其签名数据;以及,节点61从节点60的节点身份信息中提取出签名密钥对Key-0-S中的签名公钥,并针对上述解密得到的签名数据进行验证,如果签名验证成功,则节点61认定解密得到的集群身份密钥对C-Key有效,确定该密钥对C-Key可以代表链下隐私计算集群的集群身份。类似地,通过上述方式,主节点可以将集群身份密钥对C-Key共享至各个从节点,最终使得链下隐私计算集群中的所有链下隐私计算节点均获得该集群身份密钥对C-Key。
在如图5所示的实施例中,客户端51可以发送执行引擎指定信息,使得部署了链 下合约的链下隐私计算节点可以据此获知用于执行上述字节码的执行引擎,此处不再赘述,可以参考图4所示的实施例。另外,客户端51可以收到部署结果信息,该部署结果信息包含链下合约的哈希值,比如第一哈希值,使得客户端51可以将该第一哈希值与自己发出的字节码对应的第二哈希值进行比较,从而确定链下隐私计算节点是否成功部署了上述的链上合约,此处不再赘述,可以参考图4所示的实施例。如果链上合约被部署至多个链下隐私计算节点,控制节点52只需要确保所有链下隐私计算节点反馈的部署结果信息都一致,并将任意一个链下隐私计算节点反馈的部署结果信息传输至客户端51即可。
基于上述实施例,本说明书可以基于远程证明的方式对链下隐私计算节点的硬件安全性、链下TEE的软件正确性等方面进行有效验证,从而在验证链下隐私计算节点可信的情况下,将链下合约通过加密传输的方式安全部署至链下隐私计算节点,并且该链下合约仅在链下隐私计算节点创建的链下TEE内执行,具有极高的安全性,可以承担区块链节点分配的链下隐私计算任务,并确保该链下隐私技术任务安全、可靠、高效地执行。同时,由于计算任务在链下隐私计算节点上执行时,并不涉及到节点之间的共识机制,因而只需要在单个链下隐私计算节点上执行该计算任务即可,相比于受共识机制的限制而使得所有区块链节点都需要执行的链上合约而言,能够极大地节省执行计算任务所带来的资源消耗。
基于本说明书的链下合约部署方案,区块链节点可以将计算任务分配至链下隐私计算节点,并调用链下隐私计算节点上部署的链下合约,通过在链下隐私计算节点创建的链下TEE内执行该链下合约,以完成上述的计算任务。通过远程证明、加密传输、基于签名的身份验证等技术,可以确保链下隐私计算节点得到的计算结果可靠,并且在计算过程中不会造成数据泄露,具有极高的安全性。在计算完成后,区块链节点可以根据计算结果对区块链账本数据进行更新,可以对计算结果进行固化存证,而且可以支持针对该计算结果的后期验证。同时,相比于区块链节点在执行链上合约后所产生的上链数据而言,基于链下合约产生的计算结果本身相对更加简短,因而将该计算结果上链时,有助于节省链上存储空间。
区块链节点根据计算结果更新区块链账本数据,或者称为对计算结果进行上链,其方式可以包括:生成一笔区块链交易,将计算结果添加至交易的data字段,当该区块链交易通过共识后,可被各个区块链节点添加至最新区块的区块体中,从而实现了区块链账本数据的更新,亦即完成了对该计算结果的上链;或者,区块链节点根据计算结果对相关账户的状态进行更新,该相关账户譬如可以为用户对应的外部账户或者链上合约对应的合约账户,该相关账户的状态更新会导致状态树(state tree)的树根发生取值变化,而该状态树的树根会被包含于最新区块的区块头,从而实现了区块链账本数据的更新,亦即相当于将该计算结果上链。
本说明书中的链下合约,可以实现用户定义的任何计算逻辑。例如,链下合约可以用于验证区块链上存储的加密订单数据的金额是否正确,并将验证结果反馈至链上;再例如,链下合约可以用于根据预设算法对多方数据进行安全计算,即安全多方计算,并将计算结果反馈至链上等,此处不再一一赘述。
如图7所示,假定客户端71希望对已部署的链下合约进行调用。该客户端71可以通过链下渠道向控制节点72发送调用请求,该调用请求采用集群身份公钥进行加密,控制节点72可以基于负载均衡算法将该调用请求分配至集群内的某个链下隐私计算节点,比如节点72n,由该节点72n对调用请求进行响应。节点72n在自身创建的链下TEE中通过集群身份私钥解密调用请求,获得调用请求中包含的合约ID、函数名和入参数据的信息。合约ID譬如可以为链下合约的字节码的哈希值,使得节点72n可以据此找到相应的已部署的链下合约的字节码。链下合约可能包含多个函数,因而函数名可以指明客户端71希望调用的函数;如果链下合约仅包含一个函数,或者客户端71希望调用 链下合约中的所有函数,那么调用请求中也可以省去函数名的信息。入参数据的信息可以为入参数据本身,或者入参数据的描述信息,比如该描述信息可以为存储地址等,使得节点72n可以据此获取入参数据,尤其是当客户端71本身并非数据拥有者的情况下,可以省去客户端71与数据拥有者之间的交互,还可以降低调用请求的数据量、加快其传输速度。然后,节点72n可以在链下TEE中执行链下合约的字节码,以针对入参数据进行处理,从而得到相应的调用结果。节点72n可以在链下TEE中对该调用结果进行加密后,经由控制节点72反馈至客户端71。
客户端71可以通过链上渠道向控制节点72发送调用请求。客户端71可以向区块链网络73提交链下合约调用交易,该链下合约调用交易中包含调用请求,该调用请求由客户端71采用集群身份公钥进行加密。当然,链下合约调用交易本身也可以是加密传输的,这可以参考前文所述的数据加密传输的内容,此处不再赘述。链下合约调用交易可以调用预言机合约,使得预言机合约针对该交易所含的调用请求产生相应的合约事件,该合约事件被预言机服务器74监听到之后,由预言机服务器74获取调用请求并传输至控制节点72。然后,控制节点72将调用请求分配至诸如链下隐私计算节点72n进行响应。以及,控制节点72可以通过预言机机制将调用结果反馈至链上,而节点73n可以主动发起一笔交易,将该调用结果上链,或者节点73n可以将调用结果反馈至客户端71,由客户端71重新发起一笔交易将该调用结果上链。
如果入参数据为区块链数据,客户端71可以向区块链网络73提交加密后的链下合约调用交易,该链下合约调用交易中包含合约ID、函数名和入参数据的信息,并且该链下合约调用交易调用了用于获取入参数据的链上合约。节点73n收到加密后的链下合约调用交易后,在链上TEE中进行解密,然后通过链上TEE内部署的虚拟机执行被调用的链上合约,以获取被作为入参数据的区块链数据,该区块链数据通常处于加密状态,节点73n可以在链上TEE内解密为明文,然后将该明文的区块链数据与链下合约调用交易所含的合约ID、函数名打包为调用请求,并在链上TEE内采用集群身份公钥对该调用请求进行加密,而后基于预言机机制传输至控制节点72,由控制节点72将调用请求分配至诸如链下隐私计算节点72n进行响应。以及,控制节点72可以通过预言机机制将调用结果反馈至链上,而节点73n可以将该调用结果上链。
除了链下隐私计算节点可以存在统一的集群身份之外,可以为链下隐私计算节点上部署的链下合约生成合约身份。当集群内存在多个链下隐私计算节点时,每个链下隐私计算节点可以为自身已部署的链下合约建立合约身份,且不同链下隐私计算节点针对同一链下合约生成的合约身份相同。例如,链下隐私计算节点可以根据统一的集群身份和链下合约的合约ID,为链下合约生成相应的合约身份,由于集群身份相同、而不同链下合约的合约ID必然不同,因而可以确保:同一链下隐私计算节点上部署的不同链下合约存在不同的合约身份,而不同链下隐私计算节点上部署的同一链下合约存在相同的合约身份。相应地,控制节点72在分配收到的调用请求时,只需要关注于集群内的各个链下隐私计算节点的空闲程度,并基于空闲程度进行任务分配,而无需关注其他信息。
合约身份可由合约身份密钥对所定义。例如,合约身份可以包括合约加密密钥对和合约签名密钥对。那么,客户端71或节点73n除了采用集群身份公钥对调用请求进行加密之外,还可以采用合约加密公钥对调用请求内所含的入参数据的信息进行加密。链下隐私计算节点72n在收到针对某一链下合约的调用请求后,采用该链下合约对应的合约加密私钥对调用请求内加密后的入参数据的信息进行解密,从而确保入参数据的信息只能由被调用的链下合约所获得,而不会被其他链下合约获得。以及,在得到调用结果后,链下隐私计算节点72n可以通过被调用的链下合约的合约签名私钥对调用结果进行签名,而客户端71或节点73n可以通过合约签名公钥进行验签,从而确定该调用结果确实是由被调用的链下合约所产生。
在图7所示实施例中,以链下隐私计算集群为例进行描述。实际上,客户端71也可以直接与单个链下隐私计算节点进行交互,以调用该链下隐私计算节点上部署的链下合约,此处不再赘述。
对应于上述客户端侧的实施例,本说明书还提出了链下隐私节点侧、区块链节点侧、控制节点侧等其他方面的实施例,在客户端侧实施例中所涉及的描述同样可以适用于这些侧的实施例,下文中不再对此进行赘述。
相应地,图8是一示例性实施例提供的一种链下隐私计算节点侧的部署合约的方法的流程图。如图8所示,该方法可以包括步骤802~步骤806。
步骤802,链下隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告。
如前所述,远程证明报告由认证服务器对链下隐私计算节点产生的自荐信息进行验证后生成,该自荐信息与链下隐私计算节点上创建的链下可信执行环境相关。
如前所述,链下隐私计算节点可以接收区块链节点通过预言机机制传输的挑战信息,挑战信息由区块链节点从客户端提交的挑战交易中提取得到;或者,链下隐私计算节点可以接收客户端发起的链下挑战。
如前所述,链下隐私计算节点可以接收客户端直接发起的挑战;或者,在链下隐私计算节点属于链下隐私计算集群的情况下,链下隐私计算节点可以接收链下隐私计算集群的控制节点转发的挑战,该挑战由客户端向控制节点发起且挑战目标被客户端设定为所述链下隐私计算节点;或者,链下隐私计算节点可以接收链下隐私计算集群的控制节点转发的挑战,该挑战由客户端向控制节点发起且挑战目标未设定,而链下隐私计算节点由控制节点从链下隐私计算集群中选取。
如前所述,链下隐私计算节点可以响应于上述的挑战而产生自荐信息,而上述的远程证明报告由认证服务器对该自荐信息进行验证后生成;或者,链下隐私计算节点可以响应于其他挑战者的挑战而产生上述的自荐信息,而远程证明报告由认证服务器对该自荐信息进行验证后生成。
步骤804,所述链下隐私计算节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发送。
如前所述,远程证明报告可以由认证服务器进行签名,远程证明报告携带自荐信息,该自荐信息包含第一待检验哈希值,该第一待检验哈希值为链下可信执行环境的预设信息的哈希值,该第一待检验哈希值用于与客户端预先获得的针对上述链下可信执行环境的可信哈希值进行比较,且比较结果一致被作为客户端确认该链下隐私计算节点可信的前提条件。
如前所述,链下隐私计算节点可以向客户端提供的节点身份信息,该节点身份信息与代表该链下隐私计算节点的身份的密钥相关;其中,自荐信息内还包含第二待检验哈希值,该第二待检验哈希值为链下隐私计算节点生成自荐信息时的节点身份信息的哈希值,该第二待检验哈希值用于与节点身份信息进行比较,且比较结果一致被作为客户端确认该链下隐私计算节点可信的前提条件。
如前所述,链下隐私计算节点可以向客户端提供的节点身份信息,该节点身份信息与代表链下隐私计算节点的身份的密钥相关,且节点身份信息包含与链下可信执行环境相关的信息;其中,远程证明报告由认证服务器进行签名;远程证明报告携带自荐信息,该自荐信息包含待检验哈希值,该待检验哈希值用于与客户端获得的节点身份信息的哈希值进行比较,且比较结果一致被作为客户端确认链下隐私计算节点可信的前提条件。
如前所述,链下隐私计算节点可以接收区块链节点通过预言机机制传输的字节码密文,该字节码密文由区块链节点在自身创建的链上可信执行环境内对客户端提交的加 密后的链下合约部署交易进行解密后得到;或者,链下隐私计算节点可以接收客户端链下加密传输的所述字节码。
如前所述,链下隐私计算节点可以直接从客户端处获得加密传输的字节码;或者,在链下隐私计算节点属于链下隐私计算集群的情况下,链下隐私计算节点可以接收链下隐私计算集群的控制节点转发的字节码密文,该字节码密文由客户端传输至控制节点。
步骤806,所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
如前所述,在区块链节点通过预言机机制对链下合约发起调用的情况下,部署的字节码在链下可信执行环境中执行,且执行结果通过预言机机制反馈至区块链节点。
如前所述,字节码可以由非对称密钥对的公钥进行加密后传输,且非对称密钥对的私钥被链下隐私计算节点所维护。
如前所述,在链下隐私计算节点属于链下隐私计算集群的情况下,非对称密钥对的私钥可以仅被链下隐私计算节点所维护,或者非对称密钥对的私钥可以被链下隐私计算集群内的所有链下隐私计算节点共同维护。
如前所述,链下可信执行环境中可以部署有若干执行引擎。链下隐私计算节点可以接收客户端发送的与字节码相关联的执行引擎指定信息,并根据执行引擎指定信息为字节码设定相应的执行引擎。
如前所述,链下隐私计算节点可以生成部署结果信息,部署结果信息包含链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;链下隐私计算节点可以向客户端返回所述部署结果信息,第一哈希值用于与客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为客户端确认链下合约在链下隐私计算节点处部署成功的前提条件。
相应地,图9是一示例性实施例提供的一种区块链节点侧的部署合约的方法的流程图。如图9所示,该方法可以包括步骤902~步骤906。
步骤902,区块链节点接收客户端发起的挑战交易,并向所述客户端返回链下隐私计算节点的远程证明报告。
如前所述,远程证明报告由认证服务器对链下隐私计算节点产生的自荐信息进行验证后生成,自荐信息与链下隐私计算节点上创建的链下可信执行环境相关。
如前所述,区块链节点可以将经过加密的挑战交易读入链上可信执行环境中进行解密,得到挑战交易所含的挑战信息;区块链节点可以通过预言机机制将挑战信息传输至链下隐私计算节点,或者传输至链下隐私计算节点所属链下隐私计算集群的控制节点;区块链节点可以接收链下隐私计算节点或控制节点返回的远程证明报告并提供至客户端。
步骤904,所述区块链节点接收所述客户端发起的经过加密的链下合约部署交易,在所述链上可信执行环境中解密得到所述链下合约部署交易所含的字节码密文,所述字节码密文由所述客户端对链下合约的字节码进行加密得到,所述链下合约部署交易由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发起。
如前所述,远程证明报告可以由链下隐私计算节点响应于客户端的挑战而触发产生;或者,远程证明报告可以由链下隐私计算节点响应于其他挑战者的挑战而触发产生。
如前所述,远程证明报告可以由认证服务器进行签名,且远程证明报告携带自荐信息,自荐信息包含第一待检验哈希值,第一待检验哈希值为链下可信执行环境的预设信息的哈希值,第一待检验哈希值用于与客户端预先获得的针对链下可信执行环境的可信哈希值进行比较,且比较结果一致被作为客户端确认链下隐私计算节点可信的前提条件。
如前所述,区块链节点可以接收链下隐私计算节点返回的节点身份信息,并提供至客户端,节点身份信息与代表链下隐私计算节点的身份的密钥相关;其中,自荐信息 内还包含第二待检验哈希值,第二待检验哈希值为链下隐私计算节点生成自荐信息时的节点身份信息的哈希值,第二待检验哈希值用于与节点身份信息进行比较,且比较结果一致被作为客户端确认链下隐私计算节点可信的前提条件。
如前所述,区块链节点可以接收链下隐私计算节点返回的节点身份信息,并提供至客户端,节点身份信息与代表链下隐私计算节点的身份的密钥相关,且节点身份信息包含与链下可信执行环境相关的信息;其中,远程证明报告由认证服务器进行签名;远程证明报告携带自荐信息,自荐信息包含待检验哈希值,待检验哈希值用于与客户端获得的节点身份信息的哈希值进行比较,且比较结果一致被作为客户端确认链下隐私计算节点可信的前提条件。
步骤906,所述区块链节点通过预言机机制将所述字节码密文传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署。
如前所述,在区块链节点通过预言机机制对链下合约发起调用的情况下,部署的字节码在链下可信执行环境中执行,且执行结果通过预言机机制反馈至区块链节点。
如前所述,区块链节点可以通过预言机机制直接将字节码密文传输至链下隐私计算节点;或者,在链下隐私计算节点属于链下隐私计算集群的情况下,区块链节点可以通过预言机机制将字节码密文传输至链下隐私计算集群的控制节点,并由控制节点转发至链下隐私计算节点;其中,字节码密文还被控制节点转发至链下隐私计算集群中的其他链下隐私计算节点。
如前所述,字节码可以由非对称密钥对的公钥进行加密后传输,且非对称密钥对的私钥被链下隐私计算节点所维护。
如前所述,在链下隐私计算节点属于链下隐私计算集群的情况下,非对称密钥对的私钥可以仅被链下隐私计算节点所维护,或者非对称密钥对的私钥可以被链下隐私计算集群内的所有链下隐私计算节点共同维护。
如前所述,链下可信执行环境中可以部署有若干执行引擎。区块链节点可以在链上可信执行环境中解密得到链下合约部署交易所含的执行引擎指定信息;区块链节点可以通过预言机机制将执行引擎指定信息传输至链下隐私计算节点,执行引擎指定信息向链下隐私计算节点指示用于执行字节码的执行引擎。
如前所述,区块链节点可以接收链下隐私计算节点返回的部署结果信息,并提供至客户端,部署结果信息包含链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;其中,第一哈希值用于与客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为客户端确认链下合约在链下隐私计算节点处部署成功的前提条件。
相应地,图10是一示例性实施例提供的一种控制节点侧的部署合约的方法的流程图。如图10所示,该方法可以包括步骤1002~步骤1006。
步骤1002,链下隐私计算集群的控制节点接收客户端发起的挑战,从所述链下隐私计算集群内选取一链下隐私计算节点,并向所述客户端提供被选取的链下隐私计算节点对应的远程证明报告;其中,所述链下隐私计算集群内的所有链下隐私计算节点的软硬件配置一致。
如前所述,远程证明报告由认证服务器对被选取的链下隐私计算节点产生的自荐信息进行验证后生成,自荐信息与被选取的链下隐私计算节点上创建的链下可信执行环境相关。
如前所述,控制节点可以接收区块链节点通过预言机机制传输的挑战信息,挑战信息由区块链节点从客户端提交的挑战交易中提取得到;或者,控制节点可以接收客户端发起的链下挑战。
如前所述,远程证明报告可以由被选取的链下隐私计算节点响应于客户端发起的挑战而触发产生;或者,远程证明报告可以由被选取的链下隐私计算节点响应于其他挑 战者的挑战而触发产生。
如前所述,被选取的链下隐私计算节点可以由客户端指定;或者,被选取的链下隐私计算节点可以由控制节点按照预设方式选取。
步骤1004,所述控制节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算集群内的链下隐私计算节点可信的情况下发送。
如前所述,控制节点可以接收区块链节点通过预言机机制传输的字节码密文,字节码密文由区块链节点在自身创建的链上可信执行环境内对客户端提交的加密后的链下合约部署交易进行解密后得到;或者,控制节点可以接收客户端链下加密传输的字节码。
步骤1006,所述控制节点将收到的字节码密文分别转发至所述链下隐私计算集群内的所有链下隐私计算节点,所述字节码密文可由各个链下隐私计算节点分别在自身的链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
如前所述,在区块链节点通过预言机机制对链下合约发起调用的情况下,部署的字节码在任一链下隐私计算节点处的链下可信执行环境中执行,且执行结果通过预言机机制反馈至区块链节点。
如前所述,字节码可以由非对称密钥对的公钥进行加密后传输,且非对称密钥对的私钥被链下隐私计算集群内的所有链下隐私计算节点共同维护。
如前所述,链下可信执行环境中部署有若干执行引擎。控制节点可以接收客户端发送的与字节码相关联的执行引擎指定信息,并转发至链下隐私计算集群内的所有链下隐私计算节点,执行引擎指定信息用于指示各个链下隐私计算节点为字节码设定相应的执行引擎。
如前所述,控制节点可以从链下隐私计算集群内的任一链下隐私计算节点处接收部署结果信息,部署结果信息包含任一链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;控制节点可以向客户端返回部署结果信息,第一哈希值用于与客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为客户端确认链下合约在链下隐私计算集群内的链下隐私计算节点处部署成功的前提条件。
在本说明书的技术方案中,还可由客户端直接与隐私计算节点进行交互以完成在隐私计算节点上部署智能合约等操作,而无需通过区块链的预言机机制来完成上述操作,同时隐私计算节点对于智能合约的部署结果也无需反馈至区块链。在该情况下,由于不涉及链上和链下的区分,下文将“链下隐私计算节点”称为“隐私计算节点”,将“链下可信执行环境”称为“可信执行环境”,将“目标链下合约”称为“目标智能合约”。但是,技术方案的原理与上述实施例类似,所涉及的实施细节比如隐私计算节点对可信执行环境的创建过程、隐私计算节点对远程证明报告的生成过程、客户端对远程证明报告的验证过程、对字节码的加解密方案、客户端对部署结果的验证等,同样可参考上述实施例,因此下文不再进行详细描述。
图11是一示例性实施例提供的另一种客户端侧的链下合约的部署方法的流程图。如图11所示,该方法可以包括步骤1102~步骤1104。
步骤1102,客户端获取针对隐私计算节点的远程证明报告。
如前所述,所述客户端可以向所述隐私计算节点发起挑战,并接收所述隐私计算节点返回的远程证明报告;或者,在所述隐私计算节点属于隐私计算集群的情况下,所述客户端可以向所述隐私计算集群的控制节点发起挑战,并接收所述控制节点返回的远程证明报告。
如前所述,所述客户端可以向所述控制节点发起挑战且挑战目标被设定为所述隐私计算节点,使所述控制节点返回所述隐私计算节点的远程证明报告;或者,所述客户端可以向所述控制节点发起挑战且挑战目标未设定,使所述控制节点从所述隐私计算集 群中选取所述隐私计算节点并返回所述隐私计算节点的远程证明报告。
如前所述,所述远程证明报告可以由所述隐私计算节点响应于所述客户端发起的挑战而触发产生;或者,所述远程证明报告可以由所述隐私计算节点响应于其他挑战者的挑战而触发产生。
如前所述,所述客户端可以根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名通过验证且所述远程证明报告所含的远程认证结果为通过认证的情况下,所述客户端从所述远程证明报告携带的所述自荐信息内提取出第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值;所述客户端将预先获得的针对所述链下可信执行环境的可信哈希值与所述第一待检验哈希值进行比较,并将比较结果一致作为确认所述隐私计算节点可信的前提条件。
如前所述,所述客户端可以获取所述隐私计算节点提供的节点身份信息,所述节点身份信息与代表所述隐私计算节点的身份的密钥相关;所述客户端从所述远程证明报告携带的所述自荐信息内提取出第二待检验哈希值,所述第二待检验哈希值为所述隐私计算节点生成所述自荐信息时的节点身份信息的哈希值;所述客户端计算获取的节点身份信息的哈希值,将计算出的哈希值与所述第二待检验哈希值进行比较,并将比较结果一致作为确认所述隐私计算节点可信的前提条件。
如前所述,所述客户端可以获取所述隐私计算节点提供的节点身份信息,所述节点身份信息与代表所述隐私计算节点的身份的密钥相关,且所述节点身份信息包含与所述链下可信执行环境相关的信息;所述客户端根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名通过验证且所述远程证明报告所含的远程认证结果为通过认证的情况下,所述客户端从所述远程证明报告携带的所述自荐信息内提取出待检验哈希值,所述待检验哈希值为所述隐私计算节点生成所述自荐信息时的节点身份信息的哈希值;所述客户端计算获取的节点身份信息的哈希值,将计算出的哈希值与所述待检验哈希值进行比较,并将比较结果一致作为确认所述隐私计算节点可信的前提条件。
步骤1104,所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下,将智能合约的字节码加密传输至所述隐私计算节点,由所述隐私计算节点在所述可信执行环境中解密得到所述字节码并部署。
如前所述,所述客户端可以直接将所述字节码加密传输至所述隐私计算节点;或者,在所述隐私计算节点属于隐私计算集群的情况下,所述客户端可以将所述字节码加密传输至所述隐私计算集群的控制节点,并由所述控制节点转发至所述隐私计算节点;其中,所述控制节点还转发至所述隐私计算集群中的其他隐私计算节点。
如前所述,所述字节码可以由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述隐私计算节点所维护。
如前所述,在所述隐私计算节点属于隐私计算集群的情况下,所述非对称密钥对的私钥可以仅被所述隐私计算节点所维护,或者所述非对称密钥对的私钥可以被所述隐私计算集群内的所有隐私计算节点共同维护。
如前所述,所述链下可信执行环境中部署有若干执行引擎;所述客户端可以向所述隐私计算节点发送与所述字节码相关联的执行引擎指定信息,所述执行引擎指定信息向所述隐私计算节点指示用于执行所述字节码的执行引擎。
如前所述,所述客户端可以接收部署结果信息,所述部署结果信息包含所述隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;所述客户端可以将所述第一哈希值与自身持有的字节码的第二哈希值进行比较,并在比较结果一致的情况下确认所述智能合约在所述隐私计算节点处部署成功。
图12是一示例性实施例提供的另一种隐私计算节点侧的智能合约的部署方法的流程图。如图12所示,该方法可以包括步骤1202~步骤1206。
步骤1202,隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报 告。
如前所述,所述隐私计算节点可以接收所述客户端直接发起的挑战;或者,在所述隐私计算节点属于隐私计算集群的情况下,所述隐私计算节点可以接收所述隐私计算集群的控制节点转发的挑战,所述挑战由所述客户端向所述控制节点发起且挑战目标被所述客户端设定为所述隐私计算节点;或者,所述隐私计算节点可以接收所述隐私计算集群的控制节点转发的挑战,所述挑战由所述客户端向所述控制节点发起且挑战目标未设定,所述隐私计算节点由所述控制节点从所述隐私计算集群中选取。
如前所述,所述隐私计算节点可以响应于所述挑战而产生所述自荐信息,所述远程证明报告由所述认证服务器对所述自荐信息进行验证后生成;或者,所述隐私计算节点可以响应于其他挑战者的挑战而产生所述自荐信息,所述远程证明报告由所述认证服务器对所述自荐信息进行验证后生成。
步骤1204,所述隐私计算节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下发送。
如前所述,所述远程证明报告由所述认证服务器进行签名,所述远程证明报告携带所述自荐信息,所述自荐信息包含第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于与所述客户端预先获得的针对所述链下可信执行环境的可信哈希值进行比较,且比较结果一致被作为所述客户端确认所述隐私计算节点可信的前提条件。
如前所述,所述隐私计算节点向所述客户端提供的节点身份信息,所述节点身份信息与代表所述隐私计算节点的身份的密钥相关;其中,所述自荐信息内还包含第二待检验哈希值,所述第二待检验哈希值为所述隐私计算节点生成所述自荐信息时的节点身份信息的哈希值,所述第二待检验哈希值用于与所述节点身份信息进行比较,且比较结果一致被作为所述客户端确认所述隐私计算节点可信的前提条件。
如前所述,所述隐私计算节点向所述客户端提供的节点身份信息,所述节点身份信息与代表所述隐私计算节点的身份的密钥相关,且所述节点身份信息包含与所述链下可信执行环境相关的信息;其中,所述远程证明报告由所述认证服务器进行签名;所述远程证明报告携带所述自荐信息,所述自荐信息包含待检验哈希值,所述待检验哈希值用于与所述客户端获得的节点身份信息的哈希值进行比较,且比较结果一致被作为所述客户端确认所述隐私计算节点可信的前提条件。
如前所述,所述隐私计算节点直接从所述客户端处获得加密传输的所述字节码;或者,在所述隐私计算节点属于隐私计算集群的情况下,所述隐私计算节点接收所述隐私计算集群的控制节点转发的字节码密文,所述字节码密文由所述客户端传输至所述控制节点。
步骤1206,所述隐私计算节点在所述可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
如前所述,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述隐私计算节点所维护。
如前所述,在所述隐私计算节点属于隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述隐私计算节点所维护,或者所述非对称密钥对的私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
如前所述,所述链下可信执行环境中部署有若干执行引擎;所述隐私计算节点可以接收所述客户端发送的与所述字节码相关联的执行引擎指定信息;所述隐私计算节点可以根据所述执行引擎指定信息为所述字节码设定相应的执行引擎。
如前所述,所述隐私计算节点可以生成部署结果信息,所述部署结果信息包含所述隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;所述隐私计算节点 可以向所述客户端返回所述部署结果信息,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述智能合约在所述隐私计算节点处部署成功的前提条件。
图13是一示例性实施例提供的另一种控制节点侧的智能合约的部署方法的流程图。如图13所示,该方法可以包括步骤1302~步骤1306。
步骤1302,隐私计算集群的控制节点接收客户端发起的挑战,从所述隐私计算集群内选取一隐私计算节点,并向所述客户端提供被选取的隐私计算节点对应的远程证明报告。
如前所述,所述远程证明报告由所述被选取的隐私计算节点响应于所述客户端发起的挑战而触发产生;或者,所述远程证明报告由所述被选取的隐私计算节点响应于其他挑战者的挑战而触发产生。
如前所述,所述被选取的隐私计算节点由所述客户端指定;或者,所述被选取的隐私计算节点由所述控制节点按照预设方式选取。
步骤1304,所述控制节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算集群内的隐私计算节点可信的情况下发送。
如前所述,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
如前所述,所述链下可信执行环境中部署有若干执行引擎;所述控制节点可以接收所述客户端发送的与所述字节码相关联的执行引擎指定信息,并转发至所述隐私计算集群内的所有隐私计算节点,所述执行引擎指定信息用于指示各个隐私计算节点为所述字节码设定相应的执行引擎。
步骤1306,所述控制节点将收到的字节码密文分别转发至所述隐私计算集群内的所有隐私计算节点,所述字节码密文可由各个隐私计算节点分别在自身的可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
如前所述,所述控制节点从所述隐私计算集群内的任一隐私计算节点处接收部署结果信息,所述部署结果信息包含所述任一隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;所述控制节点向所述客户端返回所述部署结果信息,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述智能合约在所述隐私计算集群内的隐私计算节点处部署成功的前提条件。
图14是一示例性实施例提供的一种设备的示意结构图。请参考图14,在硬件层面,该设备包括处理器1402、内部总线1404、网络接口1406、内存1408以及非易失性存储器1410,当然还可能包括其他业务所需要的硬件。处理器1402从非易失性存储器1410中读取对应的计算机程序到内存1408中然后运行,在逻辑层面上形成部署合约的装置。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
请参考图15,在客户端侧的软件实施方式中,该部署合约的装置可以包括:验证单元1501,使客户端获取针对链下隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;部署单元1502,使所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下,将链下合约的字节码加密传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通 过所述预言机机制反馈至所述区块链节点。
可选的,验证单元1501具体用于:使所述客户端向所述链下隐私计算节点发起挑战,并接收所述链下隐私计算节点返回的远程证明报告;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,使所述客户端向所述链下隐私计算集群的控制节点发起挑战,并接收所述控制节点返回的远程证明报告。
可选的,验证单元1501具体用于:使所述客户端向区块链节点提交挑战交易,所述挑战交易所含的挑战信息可由所述区块链节点通过预言机机制传输至所述链下隐私计算节点或所述控制节点;或者,使所述客户端向所述链下隐私计算节点或所述控制节点发起链下挑战。
可选的,验证单元1501具体用于:使所述客户端向所述控制节点发起挑战且挑战目标被设定为所述链下隐私计算节点,使所述控制节点返回所述链下隐私计算节点的远程证明报告;或者,使所述客户端向所述控制节点发起挑战且挑战目标未设定,使所述控制节点从所述链下隐私计算集群中选取所述链下隐私计算节点并返回所述链下隐私计算节点的远程证明报告。
可选的,所述远程证明报告由所述链下隐私计算节点响应于所述客户端发起的挑战而触发产生;或者,所述远程证明报告由所述链下隐私计算节点响应于其他挑战者的挑战而触发产生。
可选的,验证单元1501具体用于:使所述客户端根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名通过验证且所述远程证明报告所含的远程认证结果为通过认证的情况下,使所述客户端从所述远程证明报告携带的所述自荐信息内提取出第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值;使所述客户端将预先获得的针对所述链下可信执行环境的可信哈希值与所述第一待检验哈希值进行比较,并将比较结果一致作为确认所述链下隐私计算节点可信的前提条件。
可选的,验证单元1501具体用于:使所述客户端获取所述链下隐私计算节点提供的节点身份信息,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关;使所述客户端从所述远程证明报告携带的所述自荐信息内提取出第二待检验哈希值,所述第二待检验哈希值为所述链下隐私计算节点生成所述自荐信息时的节点身份信息的哈希值;使所述客户端计算获取的节点身份信息的哈希值,将计算出的哈希值与所述第二待检验哈希值进行比较,并将比较结果一致作为确认所述链下隐私计算节点可信的前提条件。
可选的,验证单元1501具体用于:使所述客户端获取所述链下隐私计算节点提供的节点身份信息,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关,且所述节点身份信息包含与所述链下可信执行环境相关的信息;使所述客户端根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名通过验证且所述远程证明报告所含的远程认证结果为通过认证的情况下,使所述客户端从所述远程证明报告携带的所述自荐信息内提取出待检验哈希值,所述待检验哈希值为所述链下隐私计算节点生成所述自荐信息时的节点身份信息的哈希值;使所述客户端计算获取的节点身份信息的哈希值,将计算出的哈希值与所述待检验哈希值进行比较,并将比较结果一致作为确认所述链下隐私计算节点可信的前提条件。
可选的,部署单元1502具体用于:使所述客户端生成链下合约部署交易,所述链下合约部署交易中包含对所述字节码进行加密得到的字节码密文;以及,所述客户端将所述链下合约部署交易加密后提交至区块链节点,加密后的链下合约部署交易可在所述区块链节点处创建的链上可信执行环境内被解密,并由所述区块链节点通过预言机机制将解密交易得到的字节码密文传输至所述链下隐私计算节点;或者,使所述客户端在链下将所述字节码加密传输至所述链下隐私计算节点。
可选的,部署单元1502具体用于:使所述客户端直接将所述字节码加密传输至所述链下隐私计算节点;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,使所述客户端将所述字节码加密传输至所述链下隐私计算集群的控制节点,并由所述控制节点转发至所述链下隐私计算节点;其中,所述控制节点还转发至所述链下隐私计算集群中的其他链下隐私计算节点。
可选的,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述链下隐私计算节点所维护。
可选的,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述链下隐私计算节点所维护,或者所述非对称密钥对的私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
可选的,所述链下可信执行环境中部署有若干执行引擎;所述装置还包括:引擎指定单元1503,使所述客户端向所述链下隐私计算节点发送与所述字节码相关联的执行引擎指定信息,所述执行引擎指定信息向所述链下隐私计算节点指示用于执行所述字节码的执行引擎。
可选的,还包括:结果接收单元1504,使所述客户端接收部署结果信息,所述部署结果信息包含所述链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;结果验证单元1505,使所述客户端将所述第一哈希值与自身持有的字节码的第二哈希值进行比较,并在比较结果一致的情况下确认所述链下合约在所述链下隐私计算节点处部署成功。
请参考图16,在链下隐私计算节点侧的软件实施方式中,该部署合约的装置可以包括:报告提供单元1601,使链下隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;合约接收单元1602,使所述链下隐私计算节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发送;合约部署单元1603,使所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码可在所述链下可信执行环境中执行,且执行结果可通过所述预言机机制反馈至所述区块链节点。
可选的,报告提供单元1601具体用于:使所述链下隐私计算节点接收区块链节点通过预言机机制传输的挑战信息,所述挑战信息由所述区块链节点从所述客户端提交的挑战交易中提取得到;或者,使所述链下隐私计算节点接收所述客户端发起的链下挑战。
可选的,报告提供单元1601具体用于:使所述链下隐私计算节点接收所述客户端直接发起的挑战;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,使所述链下隐私计算节点接收所述链下隐私计算集群的控制节点转发的挑战,所述挑战由所述客户端向所述控制节点发起且挑战目标被所述客户端设定为所述链下隐私计算节点;或者,使所述链下隐私计算节点接收所述链下隐私计算集群的控制节点转发的挑战,所述挑战由所述客户端向所述控制节点发起且挑战目标未设定,所述链下隐私计算节点由所述控制节点从所述链下隐私计算集群中选取。
可选的,还包括:信息产生单元1604,使所述链下隐私计算节点响应于所述挑战而产生所述自荐信息,所述远程证明报告由所述认证服务器对所述自荐信息进行验证后生成;或者,使所述链下隐私计算节点响应于其他挑战者的挑战而产生所述自荐信息,所述远程证明报告由所述认证服务器对所述自荐信息进行验证后生成。
可选的,所述远程证明报告由所述认证服务器进行签名,所述远程证明报告携带所述自荐信息,所述自荐信息包含第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于与所述客户端预先获 得的针对所述链下可信执行环境的可信哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
可选的,还包括:第一身份提供单元1605,使所述链下隐私计算节点向所述客户端提供的节点身份信息,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关;其中,所述自荐信息内还包含第二待检验哈希值,所述第二待检验哈希值为所述链下隐私计算节点生成所述自荐信息时的节点身份信息的哈希值,所述第二待检验哈希值用于与所述节点身份信息进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
可选的,还包括:第二身份提供单元1606,使所述链下隐私计算节点向所述客户端提供的节点身份信息,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关,且所述节点身份信息包含与所述链下可信执行环境相关的信息;其中,所述远程证明报告由所述认证服务器进行签名;所述远程证明报告携带所述自荐信息,所述自荐信息包含待检验哈希值,所述待检验哈希值用于与所述客户端获得的节点身份信息的哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
可选的,合约接收单元1602具体用于:使所述链下隐私计算节点接收区块链节点通过预言机机制传输的字节码密文,所述字节码密文由所述区块链节点在自身创建的链上可信执行环境内对客户端提交的加密后的链下合约部署交易进行解密后得到;或者,使所述链下隐私计算节点接收所述客户端链下加密传输的所述字节码。
可选的,合约接收单元1602具体用于:使所述链下隐私计算节点直接从所述客户端处获得加密传输的所述字节码;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,使所述链下隐私计算节点接收所述链下隐私计算集群的控制节点转发的字节码密文,所述字节码密文由所述客户端传输至所述控制节点。
可选的,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述链下隐私计算节点所维护。
可选的,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述链下隐私计算节点所维护,或者所述非对称密钥对的私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
可选的,所述链下可信执行环境中部署有若干执行引擎;所述装置还包括:信息接收单元1607,使所述链下隐私计算节点接收所述客户端发送的与所述字节码相关联的执行引擎指定信息;引擎设定单元1608,所述链下隐私计算节点根据所述执行引擎指定信息为所述字节码设定相应的执行引擎。
可选的,还包括:结果生成单元1609,使所述链下隐私计算节点生成部署结果信息,所述部署结果信息包含所述链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;结果返回单元1610,使所述链下隐私计算节点向所述客户端返回所述部署结果信息,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下合约在所述链下隐私计算节点处部署成功的前提条件。
请参考图17,在区块链节点侧的软件实施方式中,该部署合约的装置可以包括:报告传输单元1701,使区块链节点接收客户端发起的挑战交易,并向所述客户端返回链下隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;合约获取单元1702,使所述区块链节点接收所述客户端发起的经过加密的链下合约部署交易,在所述链上可信执行环境中解密得到所述链下合约部署交易所含的字节码密文,所述字节码密文由所述客户端对链下合约的字节码进行加密得到,所述链下合约部署交易由所述客户端在根据所述远程证明报告确定所述链下隐私计 算节点可信的情况下发起;合约传输单元1703,使所述区块链节点通过预言机机制将所述字节码密文传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署;其中,在所述区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码可在所述链下可信执行环境中执行,且执行结果可通过所述预言机机制反馈至所述区块链节点。
可选的,报告传输单元1701具体用于:使所述区块链节点将经过加密的所述挑战交易读入所述链上可信执行环境中进行解密,得到所述挑战交易所含的挑战信息;使所述区块链节点通过预言机机制将所述挑战信息传输至所述链下隐私计算节点,或者传输至所述链下隐私计算节点所属链下隐私计算集群的控制节点;使所述区块链节点接收所述链下隐私计算节点或所述控制节点返回的远程证明报告并提供至所述客户端。
可选的,合约传输单元1703具体用于:使所述区块链节点通过预言机机制直接将所述字节码密文传输至链下隐私计算节点;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,使所述区块链节点通过预言机机制将所述字节码密文传输至所述链下隐私计算集群的控制节点,并由所述控制节点转发至所述链下隐私计算节点;其中,所述字节码密文还被所述控制节点转发至所述链下隐私计算集群中的其他链下隐私计算节点。
可选的,所述远程证明报告由所述链下隐私计算节点响应于所述客户端的挑战而触发产生;或者,所述远程证明报告由所述链下隐私计算节点响应于其他挑战者的挑战而触发产生。
可选的,所述远程证明报告由所述认证服务器进行签名,且所述远程证明报告携带所述自荐信息,所述自荐信息包含第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于与所述客户端预先获得的针对所述链下可信执行环境的可信哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
可选的,还包括:第一身份转发单元1704,使所述区块链节点接收所述链下隐私计算节点返回的节点身份信息,并提供至所述客户端,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关;其中,所述自荐信息内还包含第二待检验哈希值,所述第二待检验哈希值为所述链下隐私计算节点生成所述自荐信息时的节点身份信息的哈希值,所述第二待检验哈希值用于与所述节点身份信息进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
可选的,还包括:第二身份转发单元1705,使所述区块链节点接收所述链下隐私计算节点返回的节点身份信息,并提供至所述客户端,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关,且所述节点身份信息包含与所述链下可信执行环境相关的信息;其中,所述远程证明报告由所述认证服务器进行签名;所述远程证明报告携带所述自荐信息,所述自荐信息包含待检验哈希值,所述待检验哈希值用于与所述客户端获得的节点身份信息的哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
可选的,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述链下隐私计算节点所维护。
可选的,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述链下隐私计算节点所维护,或者所述非对称密钥对的私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
可选的,所述链下可信执行环境中部署有若干执行引擎;所述装置还包括:信息解密单元1706,使所述区块链节点在所述链上可信执行环境中解密得到所述链下合约部署交易所含的执行引擎指定信息;引擎指定单元1707,使所述区块链节点通过预言机机制将所述执行引擎指定信息传输至所述链下隐私计算节点,所述执行引擎指定信息向所 述链下隐私计算节点指示用于执行所述字节码的执行引擎。
可选的,还包括:结果传输单元1708,使所述区块链节点接收所述链下隐私计算节点返回的部署结果信息,并提供至所述客户端,所述部署结果信息包含所述链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;其中,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下合约在所述链下隐私计算节点处部署成功的前提条件。
请参考图18,在控制节点侧的软件实施方式中,该部署合约的装置可以包括:报告提供单元1801,使链下隐私计算集群的控制节点接收客户端发起的挑战,从所述链下隐私计算集群内选取一链下隐私计算节点,并向所述客户端提供被选取的链下隐私计算节点对应的远程证明报告,所述远程证明报告由认证服务器对所述被选取的链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述被选取的链下隐私计算节点上创建的链下可信执行环境相关;其中,所述链下隐私计算集群内的所有链下隐私计算节点的软硬件配置一致;合约接收单元1802,使所述控制节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算集群内的链下隐私计算节点可信的情况下发送;合约转发单元1803,使所述控制节点将收到的字节码密文分别转发至所述链下隐私计算集群内的所有链下隐私计算节点,所述字节码密文可由各个链下隐私计算节点分别在自身的链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码可在任一链下隐私计算节点处的链下可信执行环境中执行,且执行结果可通过所述预言机机制反馈至所述区块链节点。
可选的,报告提供单元1801具体用于:使所述控制节点接收区块链节点通过预言机机制传输的挑战信息,所述挑战信息由所述区块链节点从所述客户端提交的挑战交易中提取得到;或者,使所述控制节点接收所述客户端发起的链下挑战。
可选的,所述远程证明报告由所述被选取的链下隐私计算节点响应于所述客户端发起的挑战而触发产生;或者,所述远程证明报告由所述被选取的链下隐私计算节点响应于其他挑战者的挑战而触发产生。
可选的,合约接收单元1802具体用于:使所述控制节点接收区块链节点通过预言机机制传输的字节码密文,所述字节码密文由所述区块链节点在自身创建的链上可信执行环境内对客户端提交的加密后的链下合约部署交易进行解密后得到;或者,使所述控制节点接收所述客户端链下加密传输的所述字节码。
可选的,所述被选取的链下隐私计算节点由所述客户端指定;或者,所述被选取的链下隐私计算节点由所述控制节点按照预设方式选取。
可选的,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
可选的,所述链下可信执行环境中部署有若干执行引擎;所述装置还包括:引擎指定单元1804,使所述控制节点接收所述客户端发送的与所述字节码相关联的执行引擎指定信息,并转发至所述链下隐私计算集群内的所有链下隐私计算节点,所述执行引擎指定信息用于指示各个链下隐私计算节点为所述字节码设定相应的执行引擎。
可选的,还包括:结果接收单元1805,使所述控制节点从所述链下隐私计算集群内的任一链下隐私计算节点处接收部署结果信息,所述部署结果信息包含所述任一链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;结果返回单元1806,使所述控制节点向所述客户端返回所述部署结果信息,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下合约在所述链下隐私计算集群内的链下隐私计算节点处部署成功的前提条件。
请参考图19,在另一客户端侧的软件实施方式中,该部署合约的装置可以包括:验证单元1901,使客户端获取针对隐私计算节点的远程证明报告,所述远程证明报告由 认证服务器对所述隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述隐私计算节点上创建的可信执行环境相关;部署单元1902,使所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下,将智能合约的字节码加密传输至所述隐私计算节点,由所述隐私计算节点在所述可信执行环境中解密得到所述字节码并部署。
可选的,验证单元1901具体用于:使所述客户端向所述隐私计算节点发起挑战,并接收所述隐私计算节点返回的远程证明报告;或者,在所述隐私计算节点属于隐私计算集群的情况下,使所述客户端向所述隐私计算集群的控制节点发起挑战,并接收所述控制节点返回的远程证明报告。
可选的,验证单元1901具体用于:使所述客户端向所述控制节点发起挑战且挑战目标被设定为所述隐私计算节点,使所述控制节点返回所述隐私计算节点的远程证明报告;或者,使所述客户端向所述控制节点发起挑战且挑战目标未设定,使所述控制节点从所述隐私计算集群中选取所述隐私计算节点并返回所述隐私计算节点的远程证明报告。
可选的,所述远程证明报告由所述隐私计算节点响应于所述客户端发起的挑战而触发产生;或者,所述远程证明报告由所述隐私计算节点响应于其他挑战者的挑战而触发产生。
可选的,验证单元1901具体用于:使所述客户端根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名通过验证且所述远程证明报告所含的远程认证结果为通过认证的情况下,使所述客户端从所述远程证明报告携带的所述自荐信息内提取出第一待检验哈希值,所述第一待检验哈希值为所述可信执行环境的预设信息的哈希值;使所述客户端将预先获得的针对所述可信执行环境的可信哈希值与所述第一待检验哈希值进行比较,并将比较结果一致作为确认所述隐私计算节点可信的前提条件。
可选的,验证单元1901具体用于:使所述客户端获取所述隐私计算节点提供的节点身份信息,所述节点身份信息与代表所述隐私计算节点的身份的密钥相关;使所述客户端从所述远程证明报告携带的所述自荐信息内提取出第二待检验哈希值,所述第二待检验哈希值为所述隐私计算节点生成所述自荐信息时的节点身份信息的哈希值;使所述客户端计算获取的节点身份信息的哈希值,将计算出的哈希值与所述第二待检验哈希值进行比较,并将比较结果一致作为确认所述隐私计算节点可信的前提条件。
可选的,验证单元1901具体用于:使所述客户端获取所述隐私计算节点提供的节点身份信息,所述节点身份信息与代表所述隐私计算节点的身份的密钥相关,且所述节点身份信息包含与所述可信执行环境相关的信息;使所述客户端根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名通过验证且所述远程证明报告所含的远程认证结果为通过认证的情况下,使所述客户端从所述远程证明报告携带的所述自荐信息内提取出待检验哈希值,所述待检验哈希值为所述隐私计算节点生成所述自荐信息时的节点身份信息的哈希值;使所述客户端计算获取的节点身份信息的哈希值,将计算出的哈希值与所述待检验哈希值进行比较,并将比较结果一致作为确认所述隐私计算节点可信的前提条件。
可选的,部署单元1902具体用于:使所述客户端直接将所述字节码加密传输至所述隐私计算节点;或者,在所述隐私计算节点属于隐私计算集群的情况下,使所述客户端将所述字节码加密传输至所述隐私计算集群的控制节点,并由所述控制节点转发至所述隐私计算节点;其中,所述控制节点还转发至所述隐私计算集群中的其他隐私计算节点。
可选的,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述隐私计算节点所维护。
可选的,在所述隐私计算节点属于链下隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述隐私计算节点所维护,或者所述非对称密钥对的私钥被所述隐私计算 集群内的所有隐私计算节点共同维护。
可选的,所述可信执行环境中部署有若干执行引擎;所述装置还包括:引擎指定单元1903,使所述客户端向所述隐私计算节点发送与所述字节码相关联的执行引擎指定信息,所述执行引擎指定信息向所述隐私计算节点指示用于执行所述字节码的执行引擎。
可选的,还包括:结果接收单元1904,使所述客户端接收部署结果信息,所述部署结果信息包含所述隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;结果验证单元1905,使所述客户端将所述第一哈希值与自身持有的字节码的第二哈希值进行比较,并在比较结果一致的情况下确认所述智能合约在所述隐私计算节点处部署成功。
请参考图20,在另一隐私计算节点侧的软件实施方式中,该部署合约的装置可以包括:报告提供单元2001,使隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述隐私计算节点上创建的可信执行环境相关;合约接收单元2002,使所述隐私计算节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下发送;合约部署单元2003,使所述隐私计算节点在所述可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
可选的,报告提供单元2001具体用于:使所述隐私计算节点接收所述客户端直接发起的挑战;或者,在所述隐私计算节点属于隐私计算集群的情况下,使所述隐私计算节点接收所述隐私计算集群的控制节点转发的挑战,所述挑战由所述客户端向所述控制节点发起且挑战目标被所述客户端设定为所述隐私计算节点;或者,使所述隐私计算节点接收所述隐私计算集群的控制节点转发的挑战,所述挑战由所述客户端向所述控制节点发起且挑战目标未设定,所述隐私计算节点由所述控制节点从所述隐私计算集群中选取。
可选的,还包括:信息产生单元2004,使所述隐私计算节点响应于所述挑战而产生所述自荐信息,所述远程证明报告由所述认证服务器对所述自荐信息进行验证后生成;或者,使所述隐私计算节点响应于其他挑战者的挑战而产生所述自荐信息,所述远程证明报告由所述认证服务器对所述自荐信息进行验证后生成。
可选的,所述远程证明报告由所述认证服务器进行签名,所述远程证明报告携带所述自荐信息,所述自荐信息包含第一待检验哈希值,所述第一待检验哈希值为所述可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于与所述客户端预先获得的针对所述可信执行环境的可信哈希值进行比较,且比较结果一致被作为所述客户端确认所述隐私计算节点可信的前提条件。
可选的,还包括:第一身份提供单元2005,使所述隐私计算节点向所述客户端提供的节点身份信息,所述节点身份信息与代表所述隐私计算节点的身份的密钥相关;其中,所述自荐信息内还包含第二待检验哈希值,所述第二待检验哈希值为所述隐私计算节点生成所述自荐信息时的节点身份信息的哈希值,所述第二待检验哈希值用于与所述节点身份信息进行比较,且比较结果一致被作为所述客户端确认所述隐私计算节点可信的前提条件。
可选的,还包括:第二身份提供单元2006,使所述隐私计算节点向所述客户端提供的节点身份信息,所述节点身份信息与代表所述隐私计算节点的身份的密钥相关,且所述节点身份信息包含与所述可信执行环境相关的信息;其中,所述远程证明报告由所述认证服务器进行签名;所述远程证明报告携带所述自荐信息,所述自荐信息包含待检验哈希值,所述待检验哈希值用于与所述客户端获得的节点身份信息的哈希值进行比较,且比较结果一致被作为所述客户端确认所述隐私计算节点可信的前提条件。
可选的,合约接收单元2002具体用于:使所述隐私计算节点直接从所述客户端处 获得加密传输的所述字节码;或者,在所述隐私计算节点属于隐私计算集群的情况下,使所述隐私计算节点接收所述隐私计算集群的控制节点转发的字节码密文,所述字节码密文由所述客户端传输至所述控制节点。
可选的,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述隐私计算节点所维护。
可选的,在所述隐私计算节点属于隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述隐私计算节点所维护,或者所述非对称密钥对的私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
可选的,所述可信执行环境中部署有若干执行引擎;所述装置还包括:信息接收单元2007,使所述隐私计算节点接收所述客户端发送的与所述字节码相关联的执行引擎指定信息;引擎设定单元2008,使所述隐私计算节点根据所述执行引擎指定信息为所述字节码设定相应的执行引擎。
可选的,还包括:结果生成单元2009,使所述隐私计算节点生成部署结果信息,所述部署结果信息包含所述隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;结果返回单元2010,使所述隐私计算节点向所述客户端返回所述部署结果信息,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述智能合约在所述隐私计算节点处部署成功的前提条件。
请参考图21,在另一控制节点侧的软件实施方式中,该部署合约的装置可以包括:报告提供单元2101,使隐私计算集群的控制节点接收客户端发起的挑战,从所述隐私计算集群内选取一隐私计算节点,并向所述客户端提供被选取的隐私计算节点对应的远程证明报告,所述远程证明报告由认证服务器对所述被选取的隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述被选取的隐私计算节点上创建的可信执行环境相关;其中,所述隐私计算集群内的所有隐私计算节点的软硬件配置一致;合约接收单元2102,使所述控制节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算集群内的隐私计算节点可信的情况下发送;合约转发单元2103,使所述控制节点将收到的字节码密文分别转发至所述隐私计算集群内的所有隐私计算节点,所述字节码密文可由各个隐私计算节点分别在自身的可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
可选的,所述远程证明报告由所述被选取的隐私计算节点响应于所述客户端发起的挑战而触发产生;或者,所述远程证明报告由所述被选取的隐私计算节点响应于其他挑战者的挑战而触发产生。
可选的,所述被选取的隐私计算节点由所述客户端指定;或者,所述被选取的隐私计算节点由所述控制节点按照预设方式选取。
可选的,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
可选的,所述链下可信执行环境中部署有若干执行引擎;所述装置还包括:引擎指定单元2104,使所述控制节点接收所述客户端发送的与所述字节码相关联的执行引擎指定信息,并转发至所述隐私计算集群内的所有隐私计算节点,所述执行引擎指定信息用于指示各个隐私计算节点为所述字节码设定相应的执行引擎。
可选的,还包括:结果接收单元2105,使所述控制节点从所述隐私计算集群内的任一隐私计算节点处接收部署结果信息,所述部署结果信息包含所述任一隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;结果返回单元2106,使所述控制节点向所述客户端返回所述部署结果信息,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述智能合约在所述隐私计算集群内的隐私计算节点处部署成功的前提条件。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现, 或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。
Claims (69)
- 一种部署合约的方法,包括:客户端获取针对链下隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下,将链下合约的字节码加密传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
- 根据权利要求1所述的方法,所述客户端获取针对链下隐私计算节点的远程证明报告,包括:所述客户端向所述链下隐私计算节点发起挑战,并接收所述链下隐私计算节点返回的远程证明报告;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述客户端向所述链下隐私计算集群的控制节点发起挑战,并接收所述控制节点返回的远程证明报告。
- 根据权利要求2所述的方法,所述客户端向所述链下隐私计算节点或所述控制节点发起挑战,包括:所述客户端向区块链节点提交挑战交易,所述挑战交易所含的挑战信息可由所述区块链节点通过预言机机制传输至所述链下隐私计算节点或所述控制节点;或者,所述客户端向所述链下隐私计算节点或所述控制节点发起链下挑战。
- 根据权利要求2所述的方法,所述客户端向所述链下隐私计算集群的控制节点发起挑战,包括:所述客户端向所述控制节点发起挑战且挑战目标被设定为所述链下隐私计算节点,使所述控制节点返回所述链下隐私计算节点的远程证明报告;或者,所述客户端向所述控制节点发起挑战且挑战目标未设定,使所述控制节点从所述链下隐私计算集群中选取所述链下隐私计算节点并返回所述链下隐私计算节点的远程证明报告。
- 根据权利要求1所述的方法,所述远程证明报告由所述链下隐私计算节点响应于所述客户端发起的挑战而触发产生;或者,所述远程证明报告由所述链下隐私计算节点响应于其他挑战者的挑战而触发产生。
- 根据权利要求1所述的方法,所述客户端根据所述远程证明报告对所述链下隐私计算节点进行验证,包括:所述客户端根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名通过验证且所述远程证明报告所含的远程认证结果为通过认证的情况下,所述客户端从所述远程证明报告携带的所述自荐信息内提取出第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值;所述客户端将预先获得的针对所述链下可信执行环境的可信哈希值与所述第一待检验哈希值进行比较,并将比较结果一致作为确认所述链下隐私计算节点可信的前提条件。
- 根据权利要求1所述的方法,所述客户端根据所述远程证明报告对所述链下隐私计算节点进行验证,包括:所述客户端获取所述链下隐私计算节点提供的节点身份信息,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关;所述客户端从所述远程证明报告携带的所述自荐信息内提取出第二待检验哈希值, 所述第二待检验哈希值为所述链下隐私计算节点生成所述自荐信息时的节点身份信息的哈希值;所述客户端计算获取的节点身份信息的哈希值,将计算出的哈希值与所述第二待检验哈希值进行比较,并将比较结果一致作为确认所述链下隐私计算节点可信的前提条件。
- 根据权利要求1所述的方法,所述客户端根据所述远程证明报告对所述链下隐私计算节点进行验证,包括:所述客户端获取所述链下隐私计算节点提供的节点身份信息,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关,且所述节点身份信息包含与所述链下可信执行环境相关的信息;所述客户端根据所述认证服务器的公钥对所述远程证明报告进行签名验证;在签名通过验证且所述远程证明报告所含的远程认证结果为通过认证的情况下,所述客户端从所述远程证明报告携带的所述自荐信息内提取出待检验哈希值,所述待检验哈希值为所述链下隐私计算节点生成所述自荐信息时的节点身份信息的哈希值;所述客户端计算获取的节点身份信息的哈希值,将计算出的哈希值与所述待检验哈希值进行比较,并将比较结果一致作为确认所述链下隐私计算节点可信的前提条件。
- 根据权利要求1所述的方法,所述客户端将链下合约的字节码加密传输至所述链下隐私计算节点,包括:所述客户端生成链下合约部署交易,所述链下合约部署交易中包含对所述字节码进行加密得到的字节码密文;以及,所述客户端将所述链下合约部署交易加密后提交至区块链节点,加密后的链下合约部署交易可在所述区块链节点处创建的链上可信执行环境内被解密,并由所述区块链节点通过预言机机制将解密交易得到的字节码密文传输至所述链下隐私计算节点;或者,所述客户端在链下将所述字节码加密传输至所述链下隐私计算节点。
- 根据权利要求1所述的方法,所述客户端将链下合约的字节码加密传输至所述链下隐私计算节点,包括:所述客户端直接将所述字节码加密传输至所述链下隐私计算节点;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述客户端将所述字节码加密传输至所述链下隐私计算集群的控制节点,并由所述控制节点转发至所述链下隐私计算节点;其中,所述控制节点还转发至所述链下隐私计算集群中的其他链下隐私计算节点。
- 根据权利要求1所述的方法,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述链下隐私计算节点所维护。
- 根据权利要求11所述的方法,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述链下隐私计算节点所维护,或者所述非对称密钥对的私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
- 根据权利要求1所述的方法,所述链下可信执行环境中部署有若干执行引擎;所述方法还包括:所述客户端向所述链下隐私计算节点发送与所述字节码相关联的执行引擎指定信息,所述执行引擎指定信息向所述链下隐私计算节点指示用于执行所述字节码的执行引擎。
- 根据权利要求1所述的方法,还包括:所述客户端接收部署结果信息,所述部署结果信息包含所述链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;所述客户端将所述第一哈希值与自身持有的字节码的第二哈希值进行比较,并在比较结果一致的情况下确认所述链下合约在所述链下隐私计算节点处部署成功。
- 一种部署合约的方法,包括:链下隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;所述链下隐私计算节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发送;所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
- 根据权利要求15所述的方法,所述链下隐私计算节点接收源自客户端的挑战,包括:所述链下隐私计算节点接收区块链节点通过预言机机制传输的挑战信息,所述挑战信息由所述区块链节点从所述客户端提交的挑战交易中提取得到;或者,所述链下隐私计算节点接收所述客户端发起的链下挑战。
- 根据权利要求15所述的方法,所述链下隐私计算节点接收源自客户端的挑战,包括:所述链下隐私计算节点接收所述客户端直接发起的挑战;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述链下隐私计算节点接收所述链下隐私计算集群的控制节点转发的挑战,所述挑战由所述客户端向所述控制节点发起且挑战目标被所述客户端设定为所述链下隐私计算节点;或者,所述链下隐私计算节点接收所述链下隐私计算集群的控制节点转发的挑战,所述挑战由所述客户端向所述控制节点发起且挑战目标未设定,所述链下隐私计算节点由所述控制节点从所述链下隐私计算集群中选取。
- 根据权利要求15所述的方法,还包括:所述链下隐私计算节点响应于所述挑战而产生所述自荐信息,所述远程证明报告由所述认证服务器对所述自荐信息进行验证后生成;或者,所述链下隐私计算节点响应于其他挑战者的挑战而产生所述自荐信息,所述远程证明报告由所述认证服务器对所述自荐信息进行验证后生成。
- 根据权利要求15所述的方法,所述远程证明报告由所述认证服务器进行签名,所述远程证明报告携带所述自荐信息,所述自荐信息包含第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于与所述客户端预先获得的针对所述链下可信执行环境的可信哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
- 根据权利要求15所述的方法,还包括:所述链下隐私计算节点向所述客户端提供的节点身份信息,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关;其中,所述自荐信息内还包含第二待检验哈希值,所述第二待检验哈希值为所述链下隐私计算节点生成所述自荐信息时的节点身份信息的哈希值,所述第二待检验哈希值用于与所述节点身份信息进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
- 根据权利要求15所述的方法,还包括:所述链下隐私计算节点向所述客户端提供的节点身份信息,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关,且所述节点身份信息包含与所述链下可信执行环境相关的信息;其中,所述远程证明报告由所述认证服务器进行签名;所述远程证明报告携带所述自荐信息,所述自荐信息包含待检验哈希值,所述待检验哈希值用于与所述客户端获得 的节点身份信息的哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
- 根据权利要求15所述的方法,所述链下隐私计算节点接收所述客户端加密传输的链下合约的字节码,包括:所述链下隐私计算节点接收区块链节点通过预言机机制传输的字节码密文,所述字节码密文由所述区块链节点在自身创建的链上可信执行环境内对客户端提交的加密后的链下合约部署交易进行解密后得到;或者,所述链下隐私计算节点接收所述客户端链下加密传输的所述字节码。
- 根据权利要求15所述的方法,所述链下隐私计算节点接收所述客户端加密传输的链下合约的字节码,包括:所述链下隐私计算节点直接从所述客户端处获得加密传输的所述字节码;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述链下隐私计算节点接收所述链下隐私计算集群的控制节点转发的字节码密文,所述字节码密文由所述客户端传输至所述控制节点。
- 根据权利要求15所述的方法,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述链下隐私计算节点所维护。
- 根据权利要求24所述的方法,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述链下隐私计算节点所维护,或者所述非对称密钥对的私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
- 根据权利要求15所述的方法,所述链下可信执行环境中部署有若干执行引擎;所述方法还包括:所述链下隐私计算节点接收所述客户端发送的与所述字节码相关联的执行引擎指定信息;所述链下隐私计算节点根据所述执行引擎指定信息为所述字节码设定相应的执行引擎。
- 根据权利要求15所述的方法,还包括:所述链下隐私计算节点生成部署结果信息,所述部署结果信息包含所述链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;所述链下隐私计算节点向所述客户端返回所述部署结果信息,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下合约在所述链下隐私计算节点处部署成功的前提条件。
- 一种部署合约的方法,包括:区块链节点接收客户端发起的挑战交易,并向所述客户端返回链下隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;所述区块链节点接收所述客户端发起的经过加密的链下合约部署交易,在链上可信执行环境中解密得到所述链下合约部署交易所含的字节码密文,所述字节码密文由所述客户端对链下合约的字节码进行加密得到,所述链下合约部署交易由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发起;所述区块链节点通过预言机机制将所述字节码密文传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署;其中,在所述区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
- 根据权利要求28所述的方法,所述区块链节点向所述客户端返回链下隐私计 算节点的远程证明报告,包括:所述区块链节点将经过加密的所述挑战交易读入所述链上可信执行环境中进行解密,得到所述挑战交易所含的挑战信息;所述区块链节点通过预言机机制将所述挑战信息传输至所述链下隐私计算节点,或者传输至所述链下隐私计算节点所属链下隐私计算集群的控制节点;所述区块链节点接收所述链下隐私计算节点或所述控制节点返回的远程证明报告并提供至所述客户端。
- 根据权利要求28所述的方法,所述区块链节点通过预言机机制将所述字节码密文传输至链下隐私计算节点,包括:所述区块链节点通过预言机机制直接将所述字节码密文传输至链下隐私计算节点;或者,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述区块链节点通过预言机机制将所述字节码密文传输至所述链下隐私计算集群的控制节点,并由所述控制节点转发至所述链下隐私计算节点;其中,所述字节码密文还被所述控制节点转发至所述链下隐私计算集群中的其他链下隐私计算节点。
- 根据权利要求28所述的方法,所述远程证明报告由所述链下隐私计算节点响应于所述客户端的挑战而触发产生;或者,所述远程证明报告由所述链下隐私计算节点响应于其他挑战者的挑战而触发产生。
- 根据权利要求28所述的方法,所述远程证明报告由所述认证服务器进行签名,且所述远程证明报告携带所述自荐信息,所述自荐信息包含第一待检验哈希值,所述第一待检验哈希值为所述链下可信执行环境的预设信息的哈希值,所述第一待检验哈希值用于与所述客户端预先获得的针对所述链下可信执行环境的可信哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
- 根据权利要求28所述的方法,还包括:所述区块链节点接收所述链下隐私计算节点返回的节点身份信息,并提供至所述客户端,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关;其中,所述自荐信息内还包含第二待检验哈希值,所述第二待检验哈希值为所述链下隐私计算节点生成所述自荐信息时的节点身份信息的哈希值,所述第二待检验哈希值用于与所述节点身份信息进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
- 根据权利要求28所述的方法,还包括:所述区块链节点接收所述链下隐私计算节点返回的节点身份信息,并提供至所述客户端,所述节点身份信息与代表所述链下隐私计算节点的身份的密钥相关,且所述节点身份信息包含与所述链下可信执行环境相关的信息;其中,所述远程证明报告由所述认证服务器进行签名;所述远程证明报告携带所述自荐信息,所述自荐信息包含待检验哈希值,所述待检验哈希值用于与所述客户端获得的节点身份信息的哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下隐私计算节点可信的前提条件。
- 根据权利要求28所述的方法,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述链下隐私计算节点所维护。
- 根据权利要求35所述的方法,在所述链下隐私计算节点属于链下隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述链下隐私计算节点所维护,或者所述非对称密钥对的私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
- 根据权利要求28所述的方法,所述链下可信执行环境中部署有若干执行引擎;所述方法还包括:所述区块链节点在所述链上可信执行环境中解密得到所述链下合约部署交易所含的执行引擎指定信息;所述区块链节点通过预言机机制将所述执行引擎指定信息传输至所述链下隐私计算节点,所述执行引擎指定信息向所述链下隐私计算节点指示用于执行所述字节码的执行引擎。
- 根据权利要求28所述的方法,还包括:所述区块链节点接收所述链下隐私计算节点返回的部署结果信息,并提供至所述客户端,所述部署结果信息包含所述链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;其中,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下合约在所述链下隐私计算节点处部署成功的前提条件。
- 一种部署合约的方法,包括:链下隐私计算集群的控制节点接收客户端发起的挑战,从所述链下隐私计算集群内选取一链下隐私计算节点,并向所述客户端提供被选取的链下隐私计算节点对应的远程证明报告,所述远程证明报告由认证服务器对所述被选取的链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述被选取的链下隐私计算节点上创建的链下可信执行环境相关;其中,所述链下隐私计算集群内的所有链下隐私计算节点的软硬件配置一致;所述控制节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算集群内的链下隐私计算节点可信的情况下发送;所述控制节点将收到的字节码密文分别转发至所述链下隐私计算集群内的所有链下隐私计算节点,所述字节码密文可由各个链下隐私计算节点分别在自身的链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在任一链下隐私计算节点处的链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
- 根据权利要求39所述的方法,所述控制节点接收客户端发起的挑战,包括:所述控制节点接收区块链节点通过预言机机制传输的挑战信息,所述挑战信息由所述区块链节点从所述客户端提交的挑战交易中提取得到;或者,所述控制节点接收所述客户端发起的链下挑战。
- 根据权利要求39所述的方法,所述远程证明报告由所述被选取的链下隐私计算节点响应于所述客户端发起的挑战而触发产生;或者,所述远程证明报告由所述被选取的链下隐私计算节点响应于其他挑战者的挑战而触发产生。
- 根据权利要求39所述的方法,所述控制节点接收所述客户端加密传输的链下合约的字节码,包括:所述控制节点接收区块链节点通过预言机机制传输的字节码密文,所述字节码密文由所述区块链节点在自身创建的链上可信执行环境内对客户端提交的加密后的链下合约部署交易进行解密后得到;或者,所述控制节点接收所述客户端链下加密传输的所述字节码。
- 根据权利要求39所述的方法,所述被选取的链下隐私计算节点由所述客户端指定;或者,所述被选取的链下隐私计算节点由所述控制节点按照预设方式选取。
- 根据权利要求39所述的方法,所述字节码由非对称密钥对的公钥进行加密后 传输,且所述非对称密钥对的私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
- 根据权利要求39所述的方法,所述链下可信执行环境中部署有若干执行引擎;所述方法还包括:所述控制节点接收所述客户端发送的与所述字节码相关联的执行引擎指定信息,并转发至所述链下隐私计算集群内的所有链下隐私计算节点,所述执行引擎指定信息用于指示各个链下隐私计算节点为所述字节码设定相应的执行引擎。
- 根据权利要求39所述的方法,还包括:所述控制节点从所述链下隐私计算集群内的任一链下隐私计算节点处接收部署结果信息,所述部署结果信息包含所述任一链下隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;所述控制节点向所述客户端返回所述部署结果信息,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述链下合约在所述链下隐私计算集群内的链下隐私计算节点处部署成功的前提条件。
- 一种部署合约的方法,包括:客户端获取针对隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述隐私计算节点上创建的可信执行环境相关;所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下,将智能合约的字节码加密传输至所述隐私计算节点,由所述隐私计算节点在所述可信执行环境中解密得到所述字节码并部署。
- 根据权利要求47所述的方法,所述客户端将智能合约的字节码加密传输至所述隐私计算节点,包括:所述客户端直接将所述字节码加密传输至所述隐私计算节点;或者,在所述隐私计算节点属于隐私计算集群的情况下,所述客户端将所述字节码加密传输至所述隐私计算集群的控制节点,并由所述控制节点转发至所述隐私计算节点;其中,所述控制节点还转发至所述隐私计算集群中的其他隐私计算节点。
- 根据权利要求47所述的方法,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述隐私计算节点所维护。
- 根据权利要求49所述的方法,在所述隐私计算节点属于隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述隐私计算节点所维护,或者所述非对称密钥对的私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
- 根据权利要求47所述的方法,还包括:所述客户端接收部署结果信息,所述部署结果信息包含所述隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;所述客户端将所述第一哈希值与自身持有的字节码的第二哈希值进行比较,并在比较结果一致的情况下确认所述智能合约在所述隐私计算节点处部署成功。
- 一种部署合约的方法,包括:隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述隐私计算节点上创建的可信执行环境相关;所述隐私计算节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下发送;所述隐私计算节点在所述可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
- 根据权利要求52所述的方法,所述隐私计算节点接收所述客户端加密传输的 智能合约的字节码,包括:所述隐私计算节点直接从所述客户端处获得加密传输的所述字节码;或者,在所述隐私计算节点属于隐私计算集群的情况下,所述隐私计算节点接收所述隐私计算集群的控制节点转发的字节码密文,所述字节码密文由所述客户端传输至所述控制节点。
- 根据权利要求52所述的方法,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述隐私计算节点所维护。
- 根据权利要求54所述的方法,在所述隐私计算节点属于隐私计算集群的情况下,所述非对称密钥对的私钥仅被所述隐私计算节点所维护,或者所述非对称密钥对的私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
- 根据权利要求52所述的方法,还包括:所述隐私计算节点生成部署结果信息,所述部署结果信息包含所述隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;所述隐私计算节点向所述客户端返回所述部署结果信息,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述智能合约在所述隐私计算节点处部署成功的前提条件。
- 一种部署合约的方法,包括:隐私计算集群的控制节点接收客户端发起的挑战,从所述隐私计算集群内选取一隐私计算节点,并向所述客户端提供被选取的隐私计算节点对应的远程证明报告,所述远程证明报告由认证服务器对所述被选取的隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述被选取的隐私计算节点上创建的可信执行环境相关;其中,所述隐私计算集群内的所有隐私计算节点的软硬件配置一致;所述控制节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算集群内的隐私计算节点可信的情况下发送;所述控制节点将收到的字节码密文分别转发至所述隐私计算集群内的所有隐私计算节点,所述字节码密文可由各个隐私计算节点分别在自身的可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
- 根据权利要求57所述的方法,所述被选取的隐私计算节点由所述客户端指定;或者,所述被选取的隐私计算节点由所述控制节点按照预设方式选取。
- 根据权利要求57所述的方法,所述字节码由非对称密钥对的公钥进行加密后传输,且所述非对称密钥对的私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
- 根据权利要求57所述的方法,还包括:所述控制节点从所述隐私计算集群内的任一隐私计算节点处接收部署结果信息,所述部署结果信息包含所述任一隐私计算节点对所部署的字节码进行哈希运算得到的第一哈希值;所述控制节点向所述客户端返回所述部署结果信息,所述第一哈希值用于与所述客户端持有的字节码的第二哈希值进行比较,且比较结果一致被作为所述客户端确认所述智能合约在所述隐私计算集群内的隐私计算节点处部署成功的前提条件。
- 一种部署合约的装置,包括:验证单元,使客户端获取针对链下隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;部署单元,使所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下,将链下合约的字节码加密传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署;其中,在区块链节点通 过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
- 一种部署合约的装置,包括:报告提供单元,使链下隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;合约接收单元,使所述链下隐私计算节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发送;合约部署单元,使所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
- 一种部署合约的装置,包括:报告传输单元,使区块链节点接收客户端发起的挑战交易,并向所述客户端返回链下隐私计算节点的远程证明报告,所述远程证明报告由认证服务器对所述链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述链下隐私计算节点上创建的链下可信执行环境相关;合约获取单元,使所述区块链节点接收所述客户端发起的经过加密的链下合约部署交易,在链上可信执行环境中解密得到所述链下合约部署交易所含的字节码密文,所述字节码密文由所述客户端对链下合约的字节码进行加密得到,所述链下合约部署交易由所述客户端在根据所述远程证明报告确定所述链下隐私计算节点可信的情况下发起;合约传输单元,使所述区块链节点通过预言机机制将所述字节码密文传输至所述链下隐私计算节点,由所述链下隐私计算节点在所述链下可信执行环境中解密得到所述字节码并部署;其中,在所述区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在所述链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
- 一种部署合约的装置,包括:报告提供单元,使链下隐私计算集群的控制节点接收客户端发起的挑战,从所述链下隐私计算集群内选取一链下隐私计算节点,并向所述客户端提供被选取的链下隐私计算节点对应的远程证明报告,所述远程证明报告由认证服务器对所述被选取的链下隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述被选取的链下隐私计算节点上创建的链下可信执行环境相关;其中,所述链下隐私计算集群内的所有链下隐私计算节点的软硬件配置一致;合约接收单元,使所述控制节点接收所述客户端加密传输的链下合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述链下隐私计算集群内的链下隐私计算节点可信的情况下发送;合约转发单元,使所述控制节点将收到的字节码密文分别转发至所述链下隐私计算集群内的所有链下隐私计算节点,所述字节码密文可由各个链下隐私计算节点分别在自身的链下可信执行环境中解密得到所述字节码,并对所述字节码进行部署;其中,在区块链节点通过预言机机制对所述链下合约发起调用的情况下,部署的所述字节码在任一链下隐私计算节点处的链下可信执行环境中执行,且执行结果通过所述预言机机制反馈至所述区块链节点。
- 一种部署合约的装置,包括:验证单元,使客户端获取针对隐私计算节点的远程证明报告,所述远程证明报告由 认证服务器对所述隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述隐私计算节点上创建的可信执行环境相关;部署单元,使所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下,将智能合约的字节码加密传输至所述隐私计算节点,由所述隐私计算节点在所述可信执行环境中解密得到所述字节码并部署。
- 一种部署合约的装置,包括:报告提供单元,使隐私计算节点接收源自客户端的挑战,向所述客户端提供远程证明报告,所述远程证明报告由认证服务器对所述隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述隐私计算节点上创建的可信执行环境相关;合约接收单元,使所述隐私计算节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算节点可信的情况下发送;合约部署单元,使所述隐私计算节点在所述可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
- 一种部署合约的装置,包括:报告提供单元,使隐私计算集群的控制节点接收客户端发起的挑战,从所述隐私计算集群内选取一隐私计算节点,并向所述客户端提供被选取的隐私计算节点对应的远程证明报告,所述远程证明报告由认证服务器对所述被选取的隐私计算节点产生的自荐信息进行验证后生成,所述自荐信息与所述被选取的隐私计算节点上创建的可信执行环境相关;其中,所述隐私计算集群内的所有隐私计算节点的软硬件配置一致;合约接收单元,使所述控制节点接收所述客户端加密传输的智能合约的字节码,所述字节码由所述客户端在根据所述远程证明报告确定所述隐私计算集群内的隐私计算节点可信的情况下发送;合约转发单元,使所述控制节点将收到的字节码密文分别转发至所述隐私计算集群内的所有隐私计算节点,所述字节码密文可由各个隐私计算节点分别在自身的可信执行环境中解密得到所述字节码,并对所述字节码进行部署。
- 一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器通过运行所述可执行指令以实现如权利要求1-60中任一项所述的方法。
- 一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如权利要求1-60中任一项所述方法的步骤。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010190876.2A CN111090875B (zh) | 2020-03-18 | 2020-03-18 | 部署合约的方法及装置 |
| CN202010190876.2 | 2020-03-18 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2021184961A1 true WO2021184961A1 (zh) | 2021-09-23 |
Family
ID=70400540
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2021/073809 Ceased WO2021184961A1 (zh) | 2020-03-18 | 2021-01-26 | 部署合约的方法及装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (2) | CN112329041B (zh) |
| WO (1) | WO2021184961A1 (zh) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113961918A (zh) * | 2021-12-15 | 2022-01-21 | 北京中科金财科技股份有限公司 | 一种基于预言机的链下数据协同方法及其系统 |
| CN114172655A (zh) * | 2021-11-07 | 2022-03-11 | 西安链融科技有限公司 | 一种安全多方计算数据系统、方法、设备及数据处理终端 |
| CN114611159A (zh) * | 2022-05-10 | 2022-06-10 | 富算科技(上海)有限公司 | 基于tee的安全计算方法、系统及存储介质 |
| CN115795238A (zh) * | 2022-12-01 | 2023-03-14 | 蚂蚁区块链科技(上海)有限公司 | 进行隐私计算的方法 |
| EP4120166A4 (en) * | 2020-06-03 | 2023-08-30 | Tencent Technology (Shenzhen) Company Limited | METHOD AND DEVICE FOR PROCESSING BLOCKCHAIN MESSAGES, COMPUTERS AND READABLE STORAGE MEDIUM |
| CN116938452A (zh) * | 2023-09-15 | 2023-10-24 | 天津太极风控网络科技有限公司 | 一种加密备份账套的云审计方法 |
| CN116956341A (zh) * | 2023-06-25 | 2023-10-27 | 中国农业大学 | 基于区块链的sgx分布式隐私保护方法 |
| CN117728961A (zh) * | 2024-02-07 | 2024-03-19 | 成都信息工程大学 | 一种区块链中可信时间服务预言机的方法和系统 |
| EP4576658A1 (fr) * | 2023-12-21 | 2025-06-25 | Commissariat à l'Energie Atomique et aux Energies Alternatives | Procédé d'attestation à distance décentralisé |
Families Citing this family (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10419225B2 (en) | 2017-01-30 | 2019-09-17 | Factom, Inc. | Validating documents via blockchain |
| US10817873B2 (en) | 2017-03-22 | 2020-10-27 | Factom, Inc. | Auditing of electronic documents |
| US10270599B2 (en) | 2017-04-27 | 2019-04-23 | Factom, Inc. | Data reproducibility using blockchains |
| US10873457B1 (en) | 2017-09-13 | 2020-12-22 | Inveniam.io, LLC | Data structure having internal self-references suitable for immutably representing and verifying data generated over time |
| US11134120B2 (en) | 2018-05-18 | 2021-09-28 | Inveniam Capital Partners, Inc. | Load balancing in blockchain environments |
| US10783164B2 (en) | 2018-05-18 | 2020-09-22 | Factom, Inc. | Import and export in blockchain environments |
| US11170366B2 (en) | 2018-05-18 | 2021-11-09 | Inveniam Capital Partners, Inc. | Private blockchain services |
| US11276056B2 (en) | 2018-08-06 | 2022-03-15 | Inveniam Capital Partners, Inc. | Digital contracts in blockchain environments |
| US11989208B2 (en) | 2018-08-06 | 2024-05-21 | Inveniam Capital Partners, Inc. | Transactional sharding of blockchain transactions |
| US11444749B2 (en) | 2020-01-17 | 2022-09-13 | Inveniam Capital Partners, Inc. | Separating hashing from proof-of-work in blockchain environments |
| CN112329041B (zh) * | 2020-03-18 | 2024-01-23 | 支付宝(杭州)信息技术有限公司 | 部署合约的方法及装置 |
| CN113438289B (zh) * | 2020-07-08 | 2023-05-12 | 支付宝(杭州)信息技术有限公司 | 基于云计算的区块链数据处理方法及装置 |
| CN111814202B (zh) | 2020-08-31 | 2020-12-11 | 支付宝(杭州)信息技术有限公司 | 一种执行智能合约的方法、区块链节点和存储介质 |
| CN111770206B (zh) | 2020-08-31 | 2020-12-29 | 支付宝(杭州)信息技术有限公司 | 一种部署智能合约的方法、区块链节点和存储介质 |
| CN112422500B9 (zh) * | 2020-09-25 | 2026-02-03 | 北京熠智科技有限公司 | 跨平台数据传输方法以及装置、存储介质、电子装置 |
| CN112785202A (zh) * | 2021-02-20 | 2021-05-11 | 支付宝(杭州)信息技术有限公司 | 资产管理方法、装置及系统 |
| US12597066B2 (en) | 2021-03-26 | 2026-04-07 | Inveniam Capital Partners, Inc. | Federated data room server and method for use in blockchain environments |
| US12008526B2 (en) | 2021-03-26 | 2024-06-11 | Inveniam Capital Partners, Inc. | Computer system and method for programmatic collateralization services |
| CN113139205B (zh) * | 2021-04-06 | 2022-02-01 | 华控清交信息科技(北京)有限公司 | 一种安全计算方法、通用计算引擎、用于安全计算的装置和安全计算系统 |
| CN113221166A (zh) * | 2021-05-11 | 2021-08-06 | 支付宝(杭州)信息技术有限公司 | 一种获取区块链数据的方法、装置、电子设备及存储介质 |
| CN113242246B (zh) * | 2021-05-16 | 2022-09-20 | 西北工业大学 | 一种基于区块链的身份认证方法 |
| US12137179B2 (en) | 2021-06-19 | 2024-11-05 | Inveniam Capital Partners, Inc. | Systems and methods for processing blockchain transactions |
| US12007972B2 (en) | 2021-06-19 | 2024-06-11 | Inveniam Capital Partners, Inc. | Systems and methods for processing blockchain transactions |
| CN113726733B (zh) * | 2021-07-19 | 2022-07-22 | 东南大学 | 一种基于可信执行环境的加密智能合约隐私保护方法 |
| CN114022162B (zh) * | 2021-10-27 | 2024-12-03 | 杭州安影科技有限公司 | 基于可信执行环境的梯次电池溯源系统及方法 |
| CN113869901B (zh) * | 2021-12-02 | 2022-05-10 | 腾讯科技(深圳)有限公司 | 密钥生成方法、装置、计算机可读存储介质及计算机设备 |
| CN116388965A (zh) * | 2021-12-23 | 2023-07-04 | 华为技术有限公司 | 一种可信证明方法及通信装置 |
| CN114338043B (zh) * | 2022-01-05 | 2025-05-02 | 江苏幺贰凌玖科技服务有限公司 | 跨迪链征信数据加密存储及信用评分隐私计算方案 |
| CN114896635B (zh) * | 2022-04-29 | 2026-02-24 | 蚂蚁区块链科技(上海)有限公司 | 一种数据处理方法、装置、电子设备和存储介质 |
| CN114896639B (zh) * | 2022-04-29 | 2026-02-24 | 蚂蚁区块链科技(上海)有限公司 | 一种数据处理方法、装置、电子设备和存储介质 |
| CN114911572B (zh) * | 2022-05-11 | 2025-10-10 | 杭州趣链科技有限公司 | 链下计算约束方法、装置、计算机设备及介质 |
| CN114900320B (zh) * | 2022-06-21 | 2024-04-26 | 杭州安恒信息安全技术有限公司 | 一种tee节点认证方法、装置、设备及介质 |
| CN115134067B (zh) * | 2022-06-29 | 2025-04-18 | 蚂蚁区块链科技(上海)有限公司 | 检测隐私数据泄漏的方法 |
| CN115098866A (zh) * | 2022-06-29 | 2022-09-23 | 蚂蚁区块链科技(上海)有限公司 | 检测隐私数据泄漏的方法 |
| CN116012150A (zh) * | 2022-07-25 | 2023-04-25 | 天津理工大学 | 一种比特币交易自治消息提取及解析方法 |
| CN115422581B (zh) * | 2022-08-30 | 2024-03-08 | 北京火山引擎科技有限公司 | 一种数据处理方法及装置 |
| CN115632787B (zh) * | 2022-10-10 | 2025-10-31 | 福州启元信息科技有限责任公司 | 联盟链中节点权限的管理方法、装置及电子设备 |
| CN117176406A (zh) * | 2023-08-22 | 2023-12-05 | 中国银联股份有限公司 | 一种智能合约部署方法、装置、计算设备及存储介质 |
| CN118869359B (zh) * | 2024-09-24 | 2025-05-06 | 济南浪潮数据技术有限公司 | 应用迁移方法、装置、电子设备、存储介质及程序产品 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109670335A (zh) * | 2018-12-20 | 2019-04-23 | 众安信息技术服务有限公司 | 用于在区块链与链外数据之间进行交互的方法及装置 |
| CN109727131A (zh) * | 2018-12-28 | 2019-05-07 | 苏州鸿链信息科技有限公司 | 一种基于区块链合约层的链下执行交易方法及系统 |
| US20190140846A1 (en) * | 2017-11-03 | 2019-05-09 | Microsoft Technology Licensing, Llc | Provisioning trusted execution environment(s) based on chain of trust including platform |
| CN110520884A (zh) * | 2018-12-13 | 2019-11-29 | 阿里巴巴集团控股有限公司 | 基于可信执行环境的链外智能合约服务 |
| CN110580412A (zh) * | 2019-11-08 | 2019-12-17 | 支付宝(杭州)信息技术有限公司 | 基于链代码的权限查询配置方法及装置 |
| CN111090875A (zh) * | 2020-03-18 | 2020-05-01 | 支付宝(杭州)信息技术有限公司 | 部署合约的方法及装置 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180123779A1 (en) * | 2016-11-01 | 2018-05-03 | Jiangang Zhang | Flexible Blockchain Smart-Contract Deployment |
| CN111767555B (zh) * | 2019-01-31 | 2024-07-09 | 创新先进技术有限公司 | 区块链中实现隐私保护的方法及节点、存储介质 |
| CN110457875B (zh) * | 2019-07-31 | 2021-04-27 | 创新先进技术有限公司 | 基于区块链的数据授权方法及装置 |
| CN110580413B (zh) * | 2019-11-08 | 2020-03-24 | 支付宝(杭州)信息技术有限公司 | 基于链下授权的隐私数据查询方法及装置 |
| CN110889696A (zh) * | 2019-11-27 | 2020-03-17 | 杭州趣链科技有限公司 | 一种基于sgx技术的联盟区块链秘钥存储方法、装置、设备及介质 |
-
2020
- 2020-03-18 CN CN202011281665.6A patent/CN112329041B/zh active Active
- 2020-03-18 CN CN202010190876.2A patent/CN111090875B/zh active Active
-
2021
- 2021-01-26 WO PCT/CN2021/073809 patent/WO2021184961A1/zh not_active Ceased
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190140846A1 (en) * | 2017-11-03 | 2019-05-09 | Microsoft Technology Licensing, Llc | Provisioning trusted execution environment(s) based on chain of trust including platform |
| CN110520884A (zh) * | 2018-12-13 | 2019-11-29 | 阿里巴巴集团控股有限公司 | 基于可信执行环境的链外智能合约服务 |
| CN109670335A (zh) * | 2018-12-20 | 2019-04-23 | 众安信息技术服务有限公司 | 用于在区块链与链外数据之间进行交互的方法及装置 |
| CN109727131A (zh) * | 2018-12-28 | 2019-05-07 | 苏州鸿链信息科技有限公司 | 一种基于区块链合约层的链下执行交易方法及系统 |
| CN110580412A (zh) * | 2019-11-08 | 2019-12-17 | 支付宝(杭州)信息技术有限公司 | 基于链代码的权限查询配置方法及装置 |
| CN111090875A (zh) * | 2020-03-18 | 2020-05-01 | 支付宝(杭州)信息技术有限公司 | 部署合约的方法及装置 |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP4120166A4 (en) * | 2020-06-03 | 2023-08-30 | Tencent Technology (Shenzhen) Company Limited | METHOD AND DEVICE FOR PROCESSING BLOCKCHAIN MESSAGES, COMPUTERS AND READABLE STORAGE MEDIUM |
| CN114172655A (zh) * | 2021-11-07 | 2022-03-11 | 西安链融科技有限公司 | 一种安全多方计算数据系统、方法、设备及数据处理终端 |
| CN114172655B (zh) * | 2021-11-07 | 2024-03-08 | 西安链融科技有限公司 | 一种安全多方计算数据系统、方法、设备及数据处理终端 |
| CN113961918B (zh) * | 2021-12-15 | 2022-03-25 | 北京中科金财科技股份有限公司 | 一种基于预言机的链下数据协同方法及其系统 |
| CN113961918A (zh) * | 2021-12-15 | 2022-01-21 | 北京中科金财科技股份有限公司 | 一种基于预言机的链下数据协同方法及其系统 |
| CN114611159A (zh) * | 2022-05-10 | 2022-06-10 | 富算科技(上海)有限公司 | 基于tee的安全计算方法、系统及存储介质 |
| CN115795238A (zh) * | 2022-12-01 | 2023-03-14 | 蚂蚁区块链科技(上海)有限公司 | 进行隐私计算的方法 |
| CN116956341A (zh) * | 2023-06-25 | 2023-10-27 | 中国农业大学 | 基于区块链的sgx分布式隐私保护方法 |
| CN116938452A (zh) * | 2023-09-15 | 2023-10-24 | 天津太极风控网络科技有限公司 | 一种加密备份账套的云审计方法 |
| CN116938452B (zh) * | 2023-09-15 | 2023-12-08 | 天津太极风控网络科技有限公司 | 一种加密备份账套的云审计方法 |
| EP4576658A1 (fr) * | 2023-12-21 | 2025-06-25 | Commissariat à l'Energie Atomique et aux Energies Alternatives | Procédé d'attestation à distance décentralisé |
| FR3157593A1 (fr) * | 2023-12-21 | 2025-06-27 | Commissariat à l'Energie Atomique et aux Energies Alternatives | Procédé d’attestation à distance décentralisé |
| CN117728961A (zh) * | 2024-02-07 | 2024-03-19 | 成都信息工程大学 | 一种区块链中可信时间服务预言机的方法和系统 |
| CN117728961B (zh) * | 2024-02-07 | 2024-05-28 | 成都信息工程大学 | 一种区块链中可信时间服务预言机的方法和系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111090875B (zh) | 2020-10-02 |
| CN112329041B (zh) | 2024-01-23 |
| CN111090875A (zh) | 2020-05-01 |
| CN112329041A (zh) | 2021-02-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111090875B (zh) | 部署合约的方法及装置 | |
| CN111092727B (zh) | 共享集群密钥的方法及装置 | |
| CN111090888B (zh) | 验证合约的方法及装置 | |
| CN111092726B (zh) | 生成共享合约密钥的方法及装置 | |
| CN111090874B (zh) | 调用合约的方法及装置 | |
| CN111090876B (zh) | 调用合约的方法及装置 | |
| WO2021184975A1 (zh) | 链上数据的链下隐私计算方法及装置 | |
| WO2021184973A1 (zh) | 访问外部数据的方法及装置 | |
| CN110580413B (zh) | 基于链下授权的隐私数据查询方法及装置 | |
| HK40045913B (zh) | 部署合约的方法及装置 | |
| HK40044599B (zh) | 调用合约的方法及装置 | |
| HK40043789B (zh) | 生成共享合约密钥的方法及装置 | |
| HK40045913A (zh) | 部署合约的方法及装置 | |
| HK40044599A (zh) | 调用合约的方法及装置 | |
| HK40029292A (zh) | 部署合约的方法及装置 | |
| HK40029292B (zh) | 部署合约的方法及装置 | |
| HK40028999A (zh) | 生成共享合约密钥的方法及装置 | |
| HK40028999B (zh) | 生成共享合约密钥的方法及装置 | |
| HK40029288B (zh) | 调用合约的方法及装置 | |
| HK40029288A (zh) | 调用合约的方法及装置 | |
| HK40043789A (zh) | 生成共享合约密钥的方法及装置 | |
| HK40029291A (zh) | 验证合约的方法及装置 | |
| HK40029291B (zh) | 验证合约的方法及装置 | |
| HK40041347B (zh) | 共享集群密钥的方法及装置 | |
| HK40041347A (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: 21770485 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: 21770485 Country of ref document: EP Kind code of ref document: A1 |