WO2021184968A1 - 共享集群密钥的方法及装置 - Google Patents

共享集群密钥的方法及装置 Download PDF

Info

Publication number
WO2021184968A1
WO2021184968A1 PCT/CN2021/073946 CN2021073946W WO2021184968A1 WO 2021184968 A1 WO2021184968 A1 WO 2021184968A1 CN 2021073946 W CN2021073946 W CN 2021073946W WO 2021184968 A1 WO2021184968 A1 WO 2021184968A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
chain
cluster
identity
key
Prior art date
Application number
PCT/CN2021/073946
Other languages
English (en)
French (fr)
Inventor
吴因佥
邱鸿霖
吴行行
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2021184968A1 publication Critical patent/WO2021184968A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

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 sharing a cluster key.
  • 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 sharing a cluster key, which can safely implement the operation of sharing a cluster key in an off-chain environment.
  • a method for sharing cluster keys includes: any node in the off-chain private computing cluster obtains data sent by other nodes in the off-chain private computing cluster
  • the first remote attestation report, the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by the other nodes for the first-chain trusted execution environment created; any node obtains the corresponding
  • the cluster identity key of the off-chain privacy computing cluster, the cluster identity key is generated in the second chain trusted execution environment created by any node, and the blockchain node and the off-chain privacy
  • the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification; any node is in accordance with the first If a remote attestation report determines that the trusted execution environment under the first chain is trustworthy, the cluster identity key and a second remote attestation report are sent to the other nodes, and
  • a method for sharing a cluster key includes: any node in the off-chain private computing cluster provides the second node in the off-chain private computing cluster.
  • a remote attestation report the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by any node for the first chain trusted execution environment created; the any node receives The cluster identity key corresponding to the off-chain private computing cluster and the second remote attestation report sent by the other node under the condition that the trusted execution environment under the first chain is credible according to the first remote attestation report ,
  • the cluster identity key is generated in the second chain trusted execution environment created by the other nodes, and the blockchain node interacts with each node in the off-chain privacy computing cluster to deploy or call off-chain
  • the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification
  • the second remote attestation report is verified by the authentication server to the other nodes on the
  • a method for sharing cluster keys includes: any node in a privacy computing cluster obtains a first remote certificate sent by other nodes in the privacy computing cluster
  • the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by the other nodes for the first trusted execution environment created; the acquisition of any node corresponding to the privacy computing cluster
  • the cluster identity key is generated in a second trusted execution environment created by any node, and the client interacts with each node in the privacy computing cluster to deploy or call smart contracts
  • the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification; any node determines that the first trusted execution environment is trustworthy according to the first remote attestation report
  • the cluster identity is recognized by the other node, and the second remote attestation report
  • a method for sharing a cluster key includes: any node in a privacy computing cluster provides a first remote attestation report to other nodes in the privacy computing cluster
  • the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by any node for the first trusted execution environment;
  • the cluster identity key is used to perform interactive data Encryption and decryption and/or signature verification
  • the second remote attestation report is generated by the authentication server after verifying the second self-recommendation information generated by the other nodes for the second trusted execution environment; It is determined that the cluster identity key is recognized if the second remote attestation report indicates that the second trusted execution environment is credible.
  • a device for sharing a cluster key including: a report obtaining unit to enable any node in the off-chain privacy computing cluster to obtain the off-chain privacy computing cluster
  • the first remote attestation report sent by other nodes in the first remote attestation report, the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by the other nodes for the created first-chain trusted execution environment;
  • the obtaining unit enables the any node to obtain the cluster identity key corresponding to the off-chain privacy computing cluster, and the cluster identity key is generated in the second off-chain trusted execution environment created by any node
  • the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification
  • a sending unit which enables any node to send the cluster identity key and the first node to the other nodes when it is determined that the trusted execution environment
  • a remote attestation report where the cluster identity key is maintained in the trusted execution environment under the first chain when it is determined that the trusted execution environment under the second chain is trustworthy according to the second remote attestation report
  • the second remote attestation report is generated by the authentication server after verifying the second self-recommendation information generated by any node for the second chain trusted execution environment.
  • a device for sharing cluster keys including: a report providing unit, so that any node in the off-chain privacy computing cluster can report to the off-chain privacy computing cluster.
  • the other nodes in the network provide a first remote attestation report, and the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by any node for the first-chain trusted execution environment created; the receiving unit , Enabling the any node to receive the cluster corresponding to the off-chain privacy computing cluster sent by the other node when the first off-chain trusted execution environment is determined to be credible according to the first remote attestation report The identity key and the second remote attestation report.
  • the cluster identity key is generated in the trusted execution environment of the second chain created by the other nodes, and is used in each of the blockchain node and the off-chain privacy computing cluster.
  • the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification, and the second remote attestation report is reported by the authentication server to the other nodes.
  • the second self-recommendation information generated by the trusted execution environment of the second chain is generated after verification; the processing unit causes any node to determine the trusted execution of the second chain according to the second remote attestation report If the environment is trusted, the cluster identity key is maintained in the trusted execution environment under the first chain.
  • a device for sharing cluster keys including: a report obtaining unit to enable any node in the off-chain privacy computing cluster to obtain the off-chain privacy computing cluster
  • the first remote attestation report sent by other nodes in the first remote attestation report, the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by the other nodes for the created first chain trusted execution environment;
  • the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification; sending; Unit, enabling any node to send the cluster identity key and the second remote to the other nodes when it is determined that the trusted execution environment under the first chain is credible
  • a device for sharing cluster keys including: a report providing unit that enables any node in the off-chain privacy computing cluster to report to the off-chain privacy computing cluster
  • the other nodes in the network provide a first remote attestation report, and the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by any node for the first-chain trusted execution environment created; the receiving unit , Enabling the any node to receive the cluster corresponding to the off-chain privacy computing cluster sent by the other node when the first off-chain trusted execution environment is determined to be credible according to the first remote attestation report
  • the identity key and the second remote attestation report, the cluster identity key is generated in the trusted execution environment of the second chain created by the other nodes, and performed on the client and each node in the privacy computing cluster under the chain
  • the cluster identity key is used to encrypt and decrypt interactive data and
  • the second self-recommendation information generated by the trusted execution environment of the second chain is generated after verification; the processing unit enables any node to determine that the trusted execution environment of the second chain is available according to the second remote attestation report In the case of trust, the cluster identity key is maintained in the trusted execution environment under the first chain.
  • an electronic device including: a processor; a memory for storing executable instructions of the processor; wherein the processor runs the executable instructions In order to realize the method as described in the first aspect, the second aspect, the third aspect or the fourth aspect.
  • a computer-readable storage medium is provided with computer instructions stored thereon.
  • the instructions are executed by a processor, the first aspect, the second aspect, and the third 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 attestation is verified, so that the cluster key can be generated safely and reliably, and shared among the nodes in the cluster.
  • Fig. 1 is a flowchart of a method for sharing a cluster key according to an exemplary embodiment.
  • Fig. 2 is a schematic diagram of forming a cluster identity between off-chain privacy computing nodes according to an exemplary embodiment.
  • Fig. 3 is a schematic diagram of a scenario for realizing remote certification provided by an exemplary embodiment.
  • Fig. 4 is a schematic diagram of another scenario for realizing remote certification provided by an exemplary embodiment.
  • Fig. 5 is a schematic diagram of a scenario for deploying an off-chain contract according to an exemplary embodiment.
  • Fig. 6 is a schematic diagram of another scenario for deploying an off-chain contract according to an exemplary embodiment.
  • Fig. 7 is a schematic diagram of verifying an off-chain contract according to an exemplary embodiment.
  • Fig. 8 is a schematic diagram of another verification off-chain contract provided by an exemplary embodiment.
  • Fig. 9 is a schematic diagram of a scenario for invoking an off-chain contract provided by an exemplary embodiment.
  • 10-12 are a flowchart of another method for sharing a cluster key provided by an exemplary embodiment.
  • Fig. 13 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • Fig. 14 is a block diagram of a device for sharing a cluster key provided by an exemplary embodiment.
  • Figures 15-17 are block diagrams of another device for sharing cluster keys 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. It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as second information
  • 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”.
  • Block chains are 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.
  • off-chain TEE ie, off-chain trusted execution environment
  • the off-chain TEE is based on a trusted execution environment implemented by CPU hardware that is completely isolated from the outside.
  • 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.
  • an off-chain contract can be deployed on an off-chain private computing node
  • a WASM virtual machine can be deployed in an off-chain TEE created by the off-chain private computing node.
  • the off-chain private computing node can read the off-chain contract into the off-chain TEE and compile it into WASM bytecode, using the WASM virtual machine as the execution engine , And execute the compiled WASM bytecode in the WASM virtual machine.
  • a single-node form of off-chain private computing nodes can be configured to perform computing tasks; alternatively, users can be provided with high-concurrency and highly available private computing services in the form of off-chain private computing clusters, thereby solving node load balancing, failover, and Issues such as dynamic expansion and shrinkage.
  • the off-chain privacy computing cluster may include a control node and multiple off-chain privacy computing nodes, each node is used to deploy the same off-chain contract (at least one) to perform computing tasks, and the control node will All off-chain privacy computing nodes are managed uniformly. The following describes the process of the private computing node under the control node management chain requesting to join the cluster.
  • the control node can initiate a challenge to the node and receive the remote attestation report returned by the node.
  • 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 remote attestation report is generated by the authentication server after verifying the self-recommended information generated by the off-chain private computing node for its own off-chain TEE.
  • 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 control node After the control node obtains the remote attestation report of the off-chain private computing node, it can verify whether the corresponding off-chain private computing node is credible according to the remote attestation report, which specifically refers to verifying whether the off-chain TEE deployed on the off-chain private computing node is Trusted, and when the off-chain TEE is determined to be trusted, the off-chain private computing node is requested to join the off-chain private computing cluster, and the off-chain private computing node is regarded as a member node of the off-chain private computing cluster.
  • the remote attestation report specifically refers to verifying whether the off-chain TEE deployed on the off-chain private computing node is Trusted
  • the off-chain private computing node After the off-chain private computing node creates the off-chain TEE, it generates self-recommendation information for remote attestation.
  • the 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 in the off-chain TEE.
  • the preset information may include all 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.
  • control node after the control node obtains the remote certification report, it can first perform signature verification on the remote certification report according to the public key of the IAS server. If the verification is passed, it indicates that the remote certification report is indeed generated by the IAS server, and during the data transmission process No data has been tampered with or lost.
  • the control node can obtain the public key of the IAS server through any means. For example, when the remote certification report is provided to the control node, it can also associate the certificate chain that provides the IAS, so that the control node can extract the public key of the IAS server from the certificate chain. Then, the control node can extract the structure QUOTE and the signature verification result from the remote certification report. The control node can first view the signature verification result.
  • the off-chain TEE is established on a reliable hardware platform and can continue to execute other operations. Verification operation; if the signature verification result is that the verification is not passed, the control node can determine that the off-chain privacy computing platform is unreliable, and there is no need to continue other verification operations.
  • the control node 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 control node obtains the first standard hash of the above-mentioned preset information of the off-chain TEE in advance.
  • the value for example, is the trusted value of MREnclave and MRSigner (hereinafter referred to as trusted MREnclave and trusted MRSigner), and compares the MREnclave to be tested with the trusted MRSigner, and compares the MRSigner to be tested with the trusted MRSigner.
  • the control node 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 the authenticity of the TEE under the confirmation chain; in other words, if the MREnclave to be tested is inconsistent with the trusted MREnclave, or If the MRSigner to be checked is inconsistent with the trusted MRSigner, the controlling node will determine that the off-chain TEE of the off-chain private computing node is not trusted, and if all the preconditions set by the controlling node are met, the off-chain private computing node can be confirmed.
  • the off-chain TEE is credible.
  • there is no inevitable sequence between the operation of the control node to verify the signature verification result and the operation of verifying the MREnclave to be verified and the MRSigner to be verified and the two can be completely independent.
  • the control node 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 aforementioned key pair corresponding to the identity information.
  • the node identity information may include the public key in the key pair (ie, the node identity public key).
  • 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 (ie, other identity information), such as software version, domain name, partition name, etc. This specification does not limit this.
  • the off-chain privacy computing node After the off-chain privacy computing node generates node identity information in its own off-chain TEE (for example, generated when the off-chain TEE is initialized), the generated node identity information can be hashed to obtain the second standard hash value.
  • the second standard hash value can be added to the structure QUOTE.
  • the control node can perform signature verification from the remote certification report.
  • the control node can extract the signature verification result and the second standard hash value contained in the remote certification report, and verify the signature verification result, and use the second standard hash value to verify the private computing node under the chain. Whether the node identity information is correct, and there is no inevitable sequence between the two verification steps, and the two can be completely independent. It is assumed that the control node first verifies the signature verification result, and if the signature verification result is passed, it continues to use the second standard hash value to verify the node identity information of the off-chain private computing node.
  • the control node In order to verify the node identity information of the off-chain private computing node, the control node needs to obtain the node identity information of the off-chain private computing node. For example, when the remote certification report is provided to the control node, the node identity information can be provided in association. Of course, the control node The node identity information can also be obtained in other ways or at other times. Then, the control node may perform a hash calculation on the obtained node identity information to obtain a second to-be-verified hash value, and compare the calculated second to-be-verified hash value with the above-mentioned second standard hash value, and The consistency of the comparison results is used as a prerequisite for confirming the trustworthiness of the private computing nodes under the chain.
  • the second hash value to be verified passes the verification, it can be proved that the obtained node identity information is exactly the node identity information generated by the off-chain privacy computing node in its own off-chain TEE. Then, the private key in the key pair representing the identity information is only owned by the off-chain private computing node, and the off-chain private computing node can complete operations such as signing and encrypting communication.
  • judgment conditions for verification of off-chain private computing nodes namely, verification of the first to-be-verified hash value and verification of node identity information.
  • Other judgment conditions can also be used, which will not be listed here.
  • the control node 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 the node identity public key representing the identity of the node.
  • the node identity information can also include information related to the off-chain TEE. Then, after the off-chain privacy computing node generates the node identity information in its own off-chain TEE, the generated node identity information is hashed to obtain the hash value, and When the hash value is added to the structure QUOTE, the hash value is equivalent to simultaneously realizing the functions of the first hash value to be checked and the second standard hash value.
  • the node identity information can also include the values of MREnclave and MRSigner, so that the hash value obtained by the hash calculation of the node identity information is also related to the off-chain privacy calculation.
  • the identity of the node is related to the off-chain TEE.
  • the control node can perform signature verification from the remote certification report.
  • the control node can extract the signature verification result and the hash value contained in the remote certification report, and verify the signature verification result, and use the hash value to verify whether the node identity information of the private computing node under the chain is verified It is correct, and there is no inevitable sequence between the two verification steps, and the two can be completely independent. It is assumed that the control node first verifies the signature verification result, and if the signature verification result is passed, it continues to use the hash value to verify the node identity information of the off-chain private computing node. In order to verify the node identity information of the off-chain private computing node, the control node needs to obtain the node identity information of the off-chain private computing node, which will not be repeated here.
  • control node can perform a hash calculation on the obtained node identity information to obtain a hash value to be verified, compare the calculated hash value to be verified with the hash value contained in the above remote certification report, and compare Consistency of the results is used as a prerequisite for confirming the trustworthiness of the off-chain private computing nodes. 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 verification process of the remote attestation report by the control node 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. I will not repeat them one by one.
  • the control node can add the verified nodes to the off-chain private computing cluster, thereby establishing an off-chain private computing cluster that includes multiple off-chain private computing nodes.
  • an off-chain private computing cluster that includes multiple off-chain private computing nodes.
  • the cluster identity key may include a cluster encryption key pair and a cluster signature key pair.
  • Fig. 1 is a flowchart of a method for sharing a cluster key according to an exemplary embodiment. As shown in FIG. 1, the method may include step 102 to step 106.
  • Step 102 Any node in the off-chain privacy computing cluster obtains a first remote attestation report sent by other nodes in the off-chain privacy computing cluster.
  • the first remote attestation report is created by the authentication server for the other nodes.
  • the first self-recommendation information generated by the trusted execution environment under the first chain is generated after verification.
  • any node can determine whether the first off-chain trusted execution environment created by the other nodes is credible according to the first remote attestation report.
  • the first remote attestation report can be signed and verified according to the public key of the authentication server, and if the signature verification is passed and the remote attestation result contained in the first remote attestation report is certified, the first remote attestation report
  • the first to-be-verified hash value is extracted from the carried first self-recommendation information, and the first to-be-verified hash value is the hash value of the preset information in the trusted execution environment under the first chain.
  • the first standard hash value obtained in advance for the preset information is compared with the first hash value to be checked, and the comparison result is consistent as the confirmation point.
  • the prerequisites for the credibility of the trusted execution environment under the first chain are described.
  • the specific process of determining whether the trusted execution environment under the first chain is trusted can refer to the above-mentioned process for the control node to determine whether the trusted execution environment under the chain to be added to the contact is trusted, which will not be repeated here.
  • Step 104 The any node obtains a cluster identity key corresponding to the off-chain privacy computing cluster, and the cluster identity key is generated in a second chain trusted execution environment created by any node, and In the process of a blockchain node interacting with each node in the off-chain privacy computing cluster to deploy or call an off-chain contract, the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification.
  • the control node when a cluster identity needs to be generated, can select a certain off-chain private computing node as a master node, and other off-chain private computing nodes as slave nodes, and the master node generates a key representing the cluster identity Pair (cluster identity key), and then share the key pair to each slave node, so that all off-chain private computing nodes maintain a unified key pair that represents the cluster identity. For example, after each node in the off-chain privacy computing cluster has generated its own node identity information, the control node selects "any node" in step 104 as the master node, and generates the corresponding node in the off-chain TEE created by itself. The cluster identity key of the off-chain privacy computing cluster, and then when the cluster identity key needs to be shared with other nodes, the generated cluster identity key is obtained to implement the sharing operation.
  • Step 106 In the case that the any node determines that the trusted execution environment under the first chain is credible according to the first remote certification report, send the cluster identity key and the second remote to the other nodes Attestation report, when the second remote attestation report indicates that the trusted execution environment under the second chain is trustworthy, the cluster identity key is recognized by the other nodes, and the second remote attestation report is certified by The server verifies the second self-recommendation information generated by any node against the trusted execution environment under the second chain and generates it.
  • the other node recognizes the cluster identity key under the condition that the second remote attestation report indicates that the trusted execution environment under the second chain is trustworthy, so that the trusted execution environment under the first chain of its own The cluster identity key is maintained within.
  • any node Before sending the cluster identity key to the other node, any node may first verify the first node identity information of the other node. Further, since the identity information of the first node includes the node identity public key of the other nodes, the node identity public key contained in the identity information of the first node can be obtained if the verification is passed to encrypt the cluster identity key, Therefore, only the other node can decrypt the cluster identity key through its own node identity private key, thereby ensuring the security of any node sharing the cluster identity key with the other nodes.
  • the any node may obtain the first node identity information provided by the other node (for example, the other node may associate the first node identity information with the first remote attestation report and send it to the any node ), and perform a hash calculation on the acquired identity information of the first node to obtain a second hash value to be verified.
  • the first node identity information includes the node identity public key of the other node and the identity public key of the other node Other identifying information.
  • the any node obtains the second standard hash value provided by the other node (for example, the second standard hash value may be included in the first remote attestation report), and the second standard hash value is determined by the The other nodes generate their own node identity information in the trusted execution environment under the first chain and then hash the generated node identity information. Further, the any node compares the second hash value to be verified with the second standard hash value, and obtains the node identity information contained in the node identity information of the other nodes when the comparison result is consistent. Therefore, the node identity private key of any node is used to sign the cluster identity key, and the node identity public key of the other node is used to encrypt the signed cluster identity key.
  • the second standard hash value may be included in the first remote attestation report
  • any node shares the encrypted cluster identity key with the other nodes, it associates its second remote attestation report with the encrypted cluster identity key and sends it to the other node to prove its identity. Then, when the other node determines that the trusted execution environment under the second chain created by any node is credible according to the second remote certification report, the node identity private key of the other node is used to pair the received cluster The identity key is decrypted, and the node identity public key contained in the node identity information of any node is used to verify the signature of the cluster identity key, and if the signature verification is passed, it can be accessed under the first chain.
  • the cluster identity key is maintained in the trust execution environment.
  • the method for obtaining the node identity public key of any node is similar to the method for obtaining the node identity public key of the other node by any node.
  • the any node may provide the second node identity information to the other node (for example, the any node may associate the second node identity information with the second remote attestation report and send it to the other node)
  • the second node identity information includes the node identity public key of any node and other identity information of any node.
  • the any node provides a third standard hash value to the other nodes (for example, the third standard hash value may be included in the second remote attestation report), and the third standard hash value is determined by the After any node generates its own node identity information in the second chain trusted execution environment, it is obtained by hashing the generated node identity information. Then, when the third hash value to be verified obtained by hashing the identity information of the second node is consistent with the third standard hash value, the other node adopts the node identity private key pair of the other node The received cluster identity key is decrypted, and the node identity public key contained in the node identity information of any node is used to verify the signature of the cluster identity key. The cluster identity key is maintained in an off-chain trusted execution environment.
  • the third standard hash value may be included in the second remote attestation report
  • any node shares the cluster identity key with the other nodes, it needs to verify the other nodes, and the other nodes receive the cluster identity key shared by any node. After that, it is also necessary to verify any of the nodes, so as to ensure the security of the shared cluster identity key.
  • each off-chain privacy computing node creates an off-chain TEE, and creates a node identity in the respective off-chain TEE.
  • node 20 creates TEE1
  • node 21 creates TEE2
  • creates a key pair Key-1 representing its own node identity in TEE1
  • node 22 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.
  • Fig. 2 it is assumed that node 20 is selected as a master node, and nodes 21-22, etc., as slave nodes.
  • the node 20 generates a key pair representing the cluster identity in TEE1, that is, the cluster identity key pair C-Key.
  • the node 20 respectively initiates a challenge to each slave node, so that the slave nodes such as the node 21 and the node 22 respectively generate remote certification reports.
  • the remote attestation report can include information such as MREnclave, MRSigner, and hash value of node identity information.
  • the node 20 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 20 determines that the node 21 is trustworthy by means of remote certification.
  • the node 20 contains a set of signature key pair Key-0-S and a set of encryption key pair Key-0-T, and the node 20 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 21 to node 20 includes the public key in the key pair Key-1 representing the identity of node 21, 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 20 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 twenty one.
  • the node 20 also triggers to obtain the remote certification report generated for the TEE1 created by itself based on the method described above.
  • the node 20 also sends the remote certification report and the node
  • the node identity information of 20 itself is sent to the node 21 for the node 21 to verify the node 20.
  • the node 21 verifies that the node 20 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, the node 21 extracts the signature public key in Key-0-S from the node identity information of the node 20, and verifies the signature data obtained by decryption.
  • the node 21 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 deployer of an off-chain contract can deploy an off-chain contract in the off-chain private computing node for subsequent calls to perform computing tasks.
  • the client of the deploying party 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 31 can directly initiate a challenge to the off-chain private computing node 32 through an off-chain channel, that is, the client 31 initiates an off-chain challenge to the off-chain private computing node 32.
  • the client 31 may initiate a challenge to the off-chain private computing node 32 through the blockchain network 33, that is, the client 31 initiates an on-chain challenge to the off-chain private computing node 33.
  • 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 off-chain privacy computing node 32.
  • the client 31 When the client 31 initiates a challenge to the off-chain private computing node 32 through the on-chain channel, it involves the data interaction between the blockchain network 33 and the off-chain private computing node 32, that is, the data interaction on and off the chain.
  • the interaction process can be realized by the oracle contract and the oracle server 34 through the aforementioned step 2.
  • the coordination mechanism between the oracle contract and the oracle server 34 is the oracle mechanism.
  • the transaction submitted by the client 31 to the node 33n 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 34 can transmit the data to the oracle contract, and then the oracle server 34 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 31 and the off-chain private computing node 32 (the client 31 initiates an off-chain challenge to the off-chain private computing node 32, The lower privacy computing node 32 returns a remote certification report to the client 31), the data interaction between the client 31 and the node 33n (the client 31 sends a challenge transaction to the node 33n, and the node 33n returns a remote certification report to the client 31), the node Data interaction between the oracle server 34 and the oracle server 34 (the oracle server 34 reads the challenge information from the node 33n, and the oracle server 34 feeds back the remote certification report to the node 33n), between the oracle server 34 and the off-chain privacy computing node 32 Data interaction (the oracle server
  • the data transmitted between the data sender and the data receiver may leak, and the node 33n 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 31 Take the client 31 submitting a challenge transaction to the node 33n as an example.
  • an on-chain challenge is initiated to the off-chain private computing node 32, so that the node 33n can perform a consensus on the challenge transaction submitted by the client 31 with other nodes and then upload it to the chain to record the challenge behavior of the client 31.
  • the challenge transaction can be protected for privacy.
  • the client 31 can encrypt the challenge transaction, and the node 33n can receive the encrypted challenge transaction, which can ensure that the content of the challenge transaction will not be leaked during the transmission process.
  • Node 33n can deploy the on-chain TEE, and node 33n 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 33n 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 directly viewing blockchain data .
  • the node 33n can ensure that the data that needs privacy protection can only be decrypted into plain text in the on-chain TEE, and once it leaves the on-chain TEE, it will be in cipher text.
  • the form of symmetric encryption or asymmetric encryption can be adopted.
  • the client 31 and the node 33n maintain the same symmetric key respectively.
  • the symmetric key can be used by the client 31 and the node 33n through DH (Diffie-Hellman) or ECDH (Elliptic Curve Diffie-Hellman). It may be obtained through algorithm negotiation or distributed by a KMS (Key Management Service) server to the client 31 and the node 33n. This specification does not limit the source of the key.
  • the KMS server can determine the trustworthiness of the TEE on the chain at node 33n 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 31
  • the remote certification process of the off-chain privacy computing node 32 is similar, and will not be repeated here.
  • the client 31 can encrypt the challenge transaction with the above-mentioned symmetric key, and the node 33n 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 33n When asymmetric encryption is used, the node 33n maintains a private key with an asymmetric key, such as a node private key, and the client 31 can obtain the node public key corresponding to the node private key.
  • the asymmetric key can be generated by the node 33n in the TEE on the chain, or distributed to the node 33n 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 33n by means of remote certification, and then encrypt and transmit the key to the TEE on the chain.
  • the client 31 can encrypt the challenge transaction through the node public key, and the node 33n 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 31 can maintain a symmetric key.
  • the symmetric key can be randomly generated by the client 31, and the client 31 can obtain the public key in the aforementioned asymmetric key.
  • the client 31 can encrypt the challenge transaction with a symmetric key, obtain the encrypted challenge transaction, and encrypt the symmetric key with an asymmetric key to obtain the encrypted key, and then the client 31 simultaneously encrypts the encrypted challenge transaction with the encrypted challenge transaction.
  • the key is then transmitted to the node 33n.
  • the node 33n 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 41 can directly initiate a challenge to the control node 42 through an off-chain channel, that is, the client 41 initiates an off-chain challenge to the control node 42.
  • the client 41 may initiate a challenge to the control node 42 through the blockchain network 43, that is, the client 41 initiates an on-chain challenge to the control node 42.
  • the process of initiating a challenge on the chain can include three steps: Step 1, the client 41 submits a transaction for initiating a challenge to the blockchain network 43, such as a challenge transaction, which can be used by the blockchain network 43 A certain node 43n in the network receives and executes; step 2, node 43n 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 44 for example, the oracle contract can generate events containing the challenge information, and the oracle server 44 can obtain the above-mentioned challenge information by monitoring the events generated by the oracle contract; step 3, the oracle server 44 passes the challenge information through The off-chain channel is sent to the control node 42.
  • the challenge target can be set to a certain off-chain private computing node in the cluster where the control node 42 is located, such as off-chain private computing node 42n, then the control node 42 will receive The challenge is to return the remote certification report corresponding to the off-chain privacy computing node 42n to the client 41.
  • the client 41 may not set a challenge target.
  • the control node 42 selects from the off-chain private computing cluster. For example, if the off-chain private computing node 42n is selected, it will return this to the client 41.
  • the remote certification report corresponding to the off-chain privacy computing node 42n is provided.
  • control node 42 after the control node 42 receives the challenge initiated by the client 41, it can forward the challenge to the off-chain privacy computing node 42n, so that the off-chain privacy computing node 42n temporarily triggers the remote attestation process to generate a corresponding remote attestation report. Then feedback to the client 41 through the control node 42.
  • control node 42 can forward the challenge to the off-chain privacy computing node 42n, and if there is already a pre-generated remote attestation report on the off-chain privacy computing node 42n, then the off-chain The privacy computing node 42n returns the remote certification report to the control node 42, and the control node 42 provides it to the client 41 without temporarily triggering the remote certification process.
  • the off-chain privacy computing node 42n provides the remote certification report to The client 41 does not need to forward the challenge to the off-chain private computing node 42n, nor does it need the off-chain private computing node 42n to temporarily trigger the remote attestation process.
  • the remote attestation report of the off-chain private computing node 42n can be triggered by the off-chain private computing node 42n in response to challenges from other challengers except the client 41.
  • the other challengers may include other challengers.
  • the control node 42 may cache the received remote certification report. Therefore, after the control node 42 receives the challenge initiated by the client 41, it can first check whether there is a previously obtained remote certification report locally, and if it exists, the remote certification report will be fed back to the client 41, otherwise the challenge will be forwarded to the chain Under the private computing node 42n; and, after receiving the challenge, the off-chain private computing node 42n can first check whether there is a previously obtained remote certification report locally, and if it exists, the remote certification report will be fed back to the control node 42, otherwise temporarily Trigger the remote attestation process.
  • the remote attestation report can have a certain time limit, such as 40 minutes or other duration.
  • the timed out remote attestation report can be deemed invalid by the client 41, and the control node 42 or the off-chain privacy computing node 42n can also actively clear the invalid Remote attestation report to avoid feedback to the client 41.
  • each off-chain private computing node based on the fact that each off-chain private computing node maintains a cluster identity key in their respective off-chain TEE, the off-chain private computing cluster can be regarded as a whole, which is selected by the control node
  • each node in the off-chain privacy computing cluster interacts with external devices (such as blockchain nodes, clients, etc.) instead of using its own node identity key, but the cluster identity key Encrypt and decrypt interactive data, or generate and verify signatures.
  • the method of using the cluster identity key for encryption and decryption, or generating and verifying the signature is similar to the above-mentioned process of using the node identity key, and will not be repeated here.
  • the deployer can deploy an off-chain contract to the off-chain private computing node under the condition that the off-chain private computing node is determined to be trustworthy through the client.
  • 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 51 can directly transmit the bytecode encrypted to the off-chain privacy computing node 52 through the off-chain channel, that is, the client 51 transmits the encrypted bytecode ciphertext to the off-chain privacy computing node 52 off-chain.
  • the client 51 can encrypt and transmit the bytecode to the off-chain privacy computing node 52 through the blockchain network 53, that is, the client 51 transmits the encrypted bytecode to the off-chain privacy computing 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 55 for example, the oracle contract can generate an event containing the bytecode, and the oracle server 55 can obtain the above bytecode by listening to the event generated by the oracle contract; step 3, the oracle server 55 transfers the bytecode
  • the code is sent to the off-chain privacy computing node 52 through the off-chain channel.
  • the off-chain encrypted transmission only the data interaction between the client 51 and the off-chain privacy computing node 52 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 51 submits an off-chain contract deployment transaction to the node 53n
  • 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 51 encrypts the bytecode, it adds the bytecode ciphertext to the data field of the off-chain contract deployment transaction, and the client 51 should ensure that the bytecode ciphertext is only the final link
  • the off-chain privacy computing node 52 can decrypt, but other nodes 53n, oracle server 55, etc.
  • node 53n decrypts the off-chain contract deployment transaction in the on-chain TEE created by itself to obtain the bytecode secret
  • the oracle server 55 can directly read the bytecode ciphertext, and then the oracle server 55 transmits the bytecode ciphertext to the off-chain privacy computing node 52.
  • the node 53n 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
  • the oracle server 55 reads the bytecode ciphertext, and then transmits the bytecode ciphertext to the off-chain Privacy computing node 52.
  • 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 51 or node 53n 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 52, so that the off-chain privacy computing node 52 can decrypt the received bytecode ciphertext based on the private key.
  • the asymmetric key pair may be the aforementioned encryption key pair generated by the off-chain privacy computing node 52 in the off-chain TEE; accordingly, the off-chain privacy computing node 52 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 52 After the off-chain privacy computing node 52 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 52, the deployment of the off-chain contract is thus completed.
  • the off-chain privacy computing node 52 usually uses a symmetric key to encrypt and store the bytecode through symmetric encryption, so that when the bytecode is subsequently invoked, it is less expensive than using 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 52 in the off-chain TEE, or distributed to the off-chain privacy computing node 52 by other objects through encrypted transmission.
  • the KMS server can initiate a challenge to the off-chain private computing node 52, and in the case where the off-chain private computing node 52 is verified to be trusted through remote certification, the above-mentioned symmetric key is distributed to the off-chain private computing node 52.
  • the off-chain privacy computing node 52 can 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 may be an RSK (Root Seal Key) key burned in the e-fuses storage circuit in the CPU of the off-chain privacy computing node 52, or derived from the RSK key Derived key (ie Seal Key).
  • RSK Room Seal Key
  • the off-chain privacy computing node 52 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 51 can also indicate to the off-chain private computing node 52 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 51 can send the execution engine designation information associated with the above-mentioned bytecode to the off-chain private computing node 52, and the execution engine designation information indicates to the off-chain private computing node 52 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 52; or the bytecode and execution engine specified information can be encrypted and transmitted separately.
  • the execution engine specified information should 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 52 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 51 can deploy more off-chain contracts to the off-chain privacy computing node 52; similarly, other clients can also deploy off-chain contracts to the off-chain privacy computing node 52.
  • the off-chain privacy computing node 52 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 52 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 52 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 52 can feed back deployment result information to the client 51.
  • the deployment result information includes the above-mentioned first hash value, and the client 51 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 52 is correct and has not been transmitted during transmission.
  • the client 51 can confirm that the off-chain contract is successfully deployed at the off-chain privacy computing node 52; and if the two are inconsistent, the client 51 can think that the off-chain contract deployment failed, or the deployed off-chain contract exists risk.
  • the client 51 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 only the trusted contract is called in the subsequent process.
  • the off-chain privacy computing node 52 If the client 51 transmits the bytecode to the off-chain privacy computing node 52 through the off-chain channel, the off-chain privacy computing node 52 also returns the deployment result information to the client 51 through the off-chain channel; if the client 51 sends the byte code The code is transmitted to the off-chain privacy computing node 52 through the on-chain channel, and the off-chain privacy computing node 52 also feeds back the deployment result information to the client 51 through the on-chain channel.
  • the control node When the off-chain private computing node belongs to the off-chain private computing cluster, the control node will uniformly manage all the off-chain private computing nodes in the cluster, then the client first encrypts the bytecode transmission during the process of deploying the on-chain contract To the control node, the control node forwards it to one or more off-chain private computing nodes in the cluster, so as to deploy the bytecode of the on-chain contract to one or more off-chain private computing nodes in the cluster. If deployed to multiple off-chain private computing nodes, then 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 61 can directly send the bytecode ciphertext to the control node 62 through the off-chain channel, that is, the client 61 encrypts and transmits the bytecode under the chain to the control node 62, and then forwards the bytecode to the cluster by the control node 62 One or more private computing nodes under the chain.
  • the client 61 can transmit the bytecode encrypted to the control node 62 through the blockchain network 63, that is, the client 61 transmits the encrypted bytecode ciphertext to the control node 62 chain.
  • the process of encrypted transmission on the chain can include three steps: Step 1, the client 61 submits to the blockchain network 63 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 63n in the blockchain network 63 receives and executes; step 2, the node 63n 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 64 for example, the oracle contract can generate an event containing the bytecode, and the oracle server 64 can obtain the above bytecode by monitoring the event generated by the oracle contract; step 3, the oracle server 64 can generate the bytecode
  • the code is sent to the control node 62 through the off-chain channel, and then forwarded by the control node 62 to one or more off-chain privacy computing nodes in the cluster.
  • the client 61 or node 63n is encrypting the bytecode
  • the client 61 or node 63n is encrypting the bytecode
  • the encryption public key generated by the off-chain privacy computing node 62n in the off-chain TEE can be used to encrypt the bytecode
  • the off-chain privacy computing node 62n 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 61 can carry deployment target indication information, and the control node 62 can determine that the corresponding deployment target is the off-chain privacy computing node 62n according to the deployment target indication information, so as to accurately forward the bytecode ciphertext to the off-chain privacy computing
  • the node 62n does not need to be forwarded to other off-chain privacy computing nodes in the cluster. If the client 61 does not carry the deployment target indication information, the control node 62 can forward the bytecode ciphertext to all the off-chain private computing nodes in the cluster, but only the off-chain private computing node 62n 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 off-chain private computing cluster can be regarded as a whole, and the above-mentioned cluster identity key shared by each node can be used to simultaneously hold the off-chain contract.
  • the cluster identity key may include a cluster encryption key pair and a cluster signature key pair.
  • Cluster signature private key then client 61 or node 63n only needs to use the cluster encryption public key to encrypt the bytecode, to ensure that the above-mentioned private off-chain computing nodes can all be encrypted privately through the cluster in their respective off-chain TEEs.
  • the key is decrypted to obtain the bytecode and complete the deployment.
  • the above-mentioned cluster encryption public key can also be used to encrypt the bytecode, as long as the corresponding off-chain privacy computing node can successfully decrypt it.
  • the client 61 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 deployer before deploying the target off-chain contract to any node, the deployer can initiate a challenge to any node, and then any node can respond to The challenge initiated by the deployer provides the deployer with its own remote attestation report, that is, the second remote attestation report.
  • the deployer can send the encrypted target off-chain contract under the condition that the second chain trusted execution environment (that is, the off-chain trusted execution environment created by any node) is credible according to the second remote attestation report .
  • the cluster identity public key in the cluster identity key can be used to encrypt the bytecode of the contract under the target chain, and then the encrypted bytecode can be sent to any node.
  • any node After receiving the encrypted target chain contract, any node decrypts the target chain contract and deploys it in the second chain trusted execution environment through the cluster identity private key in the cluster identity key. After the deployment of the contract under the target chain is completed, when the blockchain node initiates a call to the contract under the target chain through the oracle mechanism, any node can be in the trusted execution environment under the second chain The contract under the target chain is executed, and the execution result is fed back to the blockchain node through the oracle mechanism.
  • 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.
  • the client 61 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-mentioned bytecode. It will not be repeated, and reference may be made to the embodiment shown in FIG. 5.
  • the client 61 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 61 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. 5 can be referred to.
  • control node 62 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 61 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.
  • 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 .
  • any node in the created off-chain trusted execution environment uses the key generation algorithm shared between the nodes in the off-chain privacy computing cluster, based on the sharing of the nodes in the off-chain privacy computing cluster.
  • the factor and the global identification information of the contract under the target chain (the off-chain contract deployed by each node in the privacy computing cluster is the same, and the global identification information of the same off-chain contract deployed by each node is the same), and the contract identity corresponding to the contract under the target chain is generated Key.
  • the target chain contract is executed in the trusted execution environment of any node in the chain trusted execution environment of any node when the blockchain node initiates a call to the target chain contract deployed on any node through the oracle mechanism, and the execution result
  • the contract identity key is used to sign in the trusted execution environment of any node under the chain, and the signed execution result can be fed back to the blockchain node through the oracle mechanism.
  • the contract identity key generated by each node itself is more efficient.
  • the key generation algorithm can be flexibly selected according to the actual situation, such as bcrypt algorithm, scrypt algorithm, PBKDF2, etc.
  • the sharing factor can be generated by the control node and issued uniformly by the control node when each node joins the cluster, so each node that joins the cluster can maintain the sharing factor.
  • the sharing factor includes a cluster identity key corresponding to the privacy computing cluster, and the cluster identity key is used to interact with each node in the off-chain privacy computing cluster for deployment or In the process of invoking the off-chain contract, the interactive data is encrypted and decrypted and/or signature verification is performed.
  • the contract identity key can include a contract encryption key pair and a contract signing key pair; among them, the contract identity public key includes the public key in the contract encryption key pair and the public key in the contract signing key pair.
  • the identity private key includes the private key in the contract encryption key pair and the private key in the contract signature key pair.
  • the off-chain privacy computing node After the off-chain privacy computing node 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 input data
  • the information of can only be obtained by the called off-chain contract, and will not be obtained by other off-chain contracts.
  • the off-chain privacy computing node uses the target chain contract in its own off-chain trusted execution environment before feeding back the execution result to the blockchain node through the oracle mechanism.
  • the contract identity private key signs the execution result
  • the signed execution result is determined to be generated by the target chain contract when the execution result is signed and verified by the contract identity public key of the target chain contract and the signature verification is passed.
  • the off-chain privacy computing node can sign the execution result through the contract signature private key of the called off-chain contract, and the client or node can verify the execution result through the contract signature public key to determine that the execution result is indeed Generated by the called off-chain contract
  • the off-chain privacy computing node can select a unified cluster identity key and the contract ID of the off-chain contract, and use a key derivation algorithm to derive the cluster identity key and contract ID to obtain the corresponding contract identity key.
  • the key is the same, but the contract IDs of different off-chain contracts must be different, so it can be ensured that different off-chain contracts deployed on the same chain of private computing nodes have different contract identities, and different off-chain private computing nodes are deployed on the same chain of off-chain The contracts have the same contract identity.
  • the control node allocates the received call request, it only needs to pay attention to the idleness of each off-chain privacy computing node in the cluster, and perform task assignment based on the idleness without paying attention to other information.
  • the key derivation algorithm can be flexibly selected according to the actual situation, for example, the PBKDF2 key derivation algorithm can be used, of course, this specification does not limit this.
  • 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 needs 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 user Before the user calls the target chain contract through the client, he can challenge the target chain contract deployed in the off-chain private computing node to ensure that the target off-chain contract deployed in the off-chain private computing node is credible, and then executes according to the user's expectations Computing tasks.
  • the following describes the challenge process in single-node form and cluster form in conjunction with Figures 7-8.
  • the client 71 can initiate an off-chain challenge or an on-chain challenge to the off-chain privacy computing node 72.
  • the initiation process of an on-chain challenge can include three steps: Step 1, the client 71 submits to the blockchain network 73 a transaction for initiating a challenge to the target off-chain contract, such as a challenge transaction, which can be A certain node 73n in the blockchain network 73 receives and executes; step 2, the node 73n calls the pre-deployed oracle contract, which can transmit the challenge information contained in the above-mentioned challenge transaction to the oracle server under the chain 74.
  • a challenge transaction such as a challenge transaction
  • the node 73n calls the pre-deployed oracle contract, which can transmit the challenge information contained in the above-mentioned challenge transaction to the oracle server under the chain 74.
  • the oracle contract can generate events containing the challenge information, and the oracle server 74 can obtain the above-mentioned challenge information by monitoring the events generated by the oracle contract; step 3, the oracle server 74 passes the challenge information through the off-chain The channel is sent to the control node 72.
  • the client 71 can obtain the remote attestation report for the off-chain TEE created by the off-chain private computing node 72.
  • the remote attestation report is verified by the authentication server on the off-chain privacy
  • the computing node 72 is generated after verifying the self-recommendation information generated by the off-chain TEE.
  • the client 71 initiates a challenge to the off-chain private computing node 72, and the challenge target is the target off-chain contract deployed by the off-chain private computing node 72, and then receives the off-chain private computing node 72 in response to the challenge.
  • the remote attestation report and the contract information to be verified that is, the off-chain privacy computing node 72 returns the remote attestation report and the contract information to be verified to the client 71 at one time.
  • the client 71 initiates a challenge to the off-chain private computing node 72.
  • the challenge target is the off-chain TEE created by the off-chain private computing node 72, and then receives the remote attestation report returned by the off-chain private computing node 72.
  • the off-chain TEE is determined to be credible according to the remote attestation report
  • the contract information to be verified returned by the off-chain privacy computing node 72 in response to the acquisition request is received.
  • the off-chain TEE is determined to be untrustworthy according to the remote attestation report, there is no need to request the off-chain privacy computing node 72 for contract information of the target off-chain contract (that is, the contract information to be verified).
  • the client 71 can initiate a challenge to the challenge target through an on-chain challenge. For example, submit a challenge transaction for the challenge target to the blockchain node 73n, and the challenge information contained in the challenge transaction is transmitted to the off-chain private computing node 72 by the blockchain node 73n through the oracle mechanism, and the challenge information is used to challenge The goal initiates a challenge.
  • the client 71 directly initiates an off-chain challenge to the challenge target in the off-chain privacy computing node 72.
  • the operation of the client 71 to verify the off-chain TEE of the off-chain privacy computing node 72 according to the remote attestation report may include: verifying the remote attestation report by signature according to the public key of the authentication server, and after the signature verification is passed And if the remote authentication result contained in the remote attestation report is certified, the first to-be-verified hash value is extracted from the self-recommendation information carried in the remote attestation report, and the first to-be-verified hash value is the preset information of the off-chain TEE Then compare the pre-obtained first standard hash value for the off-chain TEE with the first hash value to be verified.
  • this part of the content can refer to the aforementioned process of the control node verifying the node to be added, which will not be repeated here.
  • the generated node identity information can be hashed to obtain the second standard hash value; Among them, the generated node identity information includes the node identity public key of the off-chain private computing node 72 and other identity information of the off-chain private computing node 72. Then, the client 71 can use the second standard hash value to verify the identity information of the first node provided by the off-chain private computing node 72 (that is, the declared node identity information, including the node identity public key of the off-chain private computing node 72 and the off-chain
  • the other identity information of the private computing node 72 may not necessarily be real data.
  • the identity information to be verified if the verification is passed, the node contained in the node identity information of the private computing node 72 under the verifiable chain is obtained.
  • the identity public key is used to complete the subsequent verification of the contract under the target chain by using the node’s identity public key.
  • the client performs a hash calculation on the acquired identity information of the first node to obtain the second hash value to be verified, and compares the second hash value to be verified with the second standard provided by the off-chain privacy calculation node 72 The hash values are compared, and if the comparison results are consistent, it is determined that the node identity information verification is passed.
  • the node identity information is generated by the off-chain privacy computing node 72 in the off-chain TEE and calculated to obtain the second standard hash value, after determining the authenticity of the off-chain TEE according to the remote attestation report, if the second hash value to be verified
  • the first node identity information provided by the private computing node 72 is the node identity information generated in the off-chain TEE, and the node identity public key contained therein is the actual node of the private computing node 72
  • the identity public key, and the actual node identity public key of the private computing node 72 can be used to verify the signature of the private computing node 72.
  • the off-chain privacy computing node 72 can send the second standard hash value, the remote certification report, and the identity information of the first node to the client 71 together. It should be noted that this part of the content can refer to the aforementioned process of the control node verifying the node to be added, which will not be repeated here.
  • the off-chain private computing node 72 generates its own node identity information in the off-chain TEE, including the node identity public key of the off-chain private computing node 72, and the off-chain private computing node 72 Other identity information and the hash value of the preset information of the off-chain TEE, then the off-chain privacy computing node 72 generates the node identity information in its own off-chain TEE, and then hashes the generated node identity information to obtain the third standard Hash value, then the third standard hash value is equivalent to simultaneously achieving the functions of the first to-be-checked hash value and the second standard hash value.
  • the off-chain privacy computing node 72 can provide the client 71 with a remote certification report, a third standard hash value, and second node identity information (this can be understood as the identity information to be verified).
  • the second node identity information includes the node identity public key of the off-chain privacy computing node 72, other identity information of the off-chain privacy computing node 72, and the fourth hash value to be verified, and the fourth hash value to be verified is the chain The hash value of the preset information of the lower TEE; at the same time, the second node identity information is the declared node identity information, not necessarily the real node identity information of the off-chain private computing node 72.
  • the client 71 performs signature verification on the remote attestation report according to the public key of the authentication server, and when the signature verification is passed and the remote attestation result contained in the remote attestation report is authenticated, the obtained second node identity
  • the information is hashed to obtain the third hash value to be verified, and the third hash value to be verified is compared with the third standard hash value.
  • the comparison result is consistent, it means that the second node identity information provided by the privacy computing node 72 is the node identity information generated in the off-chain TEE, that is, the fourth hash value to be verified contained therein is the actual value of the off-chain TEE.
  • the hash value of the preset information is consistent.
  • the pre-obtained fourth standard hash value for the preset information of the off-chain TEE is further compared with the fourth hash value to be verified, and the comparison result is consistent as a prerequisite for confirming the authenticity of the off-chain TEE condition.
  • the node identity public key contained in the second node identity information can be determined as the actual node identity public key of the privacy computing node 72, which can be used to perform signature verification on the contract information to be verified.
  • the off-chain privacy computing node 72 can send the third standard hash value, the remote certification report, and the identity information of the second node to the client 71 together. It should be noted that this part of the content can refer to the aforementioned process of the control node verifying the node to be added, which will not be repeated here.
  • the client 71 determines that the off-chain TEE is trustworthy according to the remote attestation report, it obtains the to-be-verified contract information of the target off-chain contract deployed at the off-chain private computing node 72, and the to-be-verified contract information is used by the off-chain private computing node 72
  • the node identity private key is used to sign in the off-chain TEE, and the node identity private key is generated by the off-chain privacy computing node 72 in the off-chain TEE.
  • the off-chain privacy computing node 72 can read the deployed target off-chain contract into the off-chain TEE and sign it with its own node identity private key.
  • the client 71 uses the node identity public key of the off-chain private computing node 72 to perform signature verification on the contract information to be verified, and to perform contract information verification on the contract information to be verified based on the contract information of the target chain off-chain contract.
  • the node identity public key is in a public state, for example, the off-chain privacy computing node 72 publicly releases the node identity public key to the client 71 to obtain it.
  • the client 71 obtains the node identity information of the private computing node 72 under the above-mentioned verification chain.
  • the contract information of the contract under the target chain may also be in a public state.
  • the contract information may include the name, description, version number, bytecode hash value, contract identity public key and other information of the off-chain contract, which is not restricted in this specification.
  • the client 71 can determine that when the client 71 initiates a call to the target chain contract through the oracle mechanism of the blockchain node, the target chain contract is controlled by the off-chain privacy computing node 72 is executed in an off-chain TEE trusted execution environment.
  • the process of verifying the off-chain contract in this manual is to first verify that the off-chain TEE of the off-chain private computing node 72 is trustworthy.
  • the off-chain TEE of the off-chain private computing node 72 is trusted, if the signature is verified to be off-chain
  • the contract information to be verified provided by the privacy computing node 72 is indeed signed by the node identity private key (maintained in the off-chain TEE) of the off-chain privacy computing node 72, and then it can be determined that the currently challenged off-chain contract is running in off-chain privacy computing
  • the target off-chain contract in the off-chain TEE of the node 72 is to ensure that the target off-chain contract deployed in the off-chain privacy computing node 72 is credible and can perform computing tasks as expected by the user.
  • the client 81 can initiate an off-chain challenge or an on-chain challenge to the control node 82.
  • the process of initiating a challenge on the chain can include three steps: Step 1, the client 81 submits to the blockchain network 83 a transaction for initiating a challenge to the target chain contract, such as a challenge transaction, which can be A certain node 83n in the blockchain network 83 receives and executes; step 2, the node 83n calls the pre-deployed oracle contract, which can transmit the challenge information contained in the above-mentioned challenge transaction to the oracle server under the chain 84.
  • the oracle contract can generate events containing the challenge information, and the oracle server 84 can obtain the above-mentioned challenge information by monitoring the events generated by the oracle contract; step 3, the oracle server 84 passes the challenge information through the off-chain The channel is sent to the control node 82.
  • the off-chain privacy computing cluster as a whole provides the function of performing computing tasks.
  • each node in the cluster is deployed with the same off-chain contract, then each node can perform computing tasks on behalf of the cluster, for example, the computing tasks can be distributed by the control node. Therefore, when each node interacts with the outside on behalf of the cluster, it uses the cluster identity key representing the identity of the cluster to decrypt or sign the data interacting with the outside, instead of using the node identity key of the node itself.
  • an external object interacts with the cluster through the client, it regards the cluster as a whole and does not need to care about the internal structure of the cluster, so the cluster identity key is used for encryption or signature verification.
  • the user before calling the target off-chain contract in the cluster through the client 81, the user can challenge the target off-chain contract deployed in the cluster through the client 81 (each node in the off-chain privacy computing cluster After deploying the contract under the target chain, the challenge is initiated).
  • the control node 82 After the control node 82 receives the challenge, it can select any node in the cluster to respond to the challenge. For example, the master node used to generate the cluster identity key can be selected, or the slave node in the cluster can be selected. This specification does not limit the method of selecting the node that responds to the challenge. Take the node 82n responding to the challenge as an example for description.
  • the control node 82 selects the node 82n to respond to the challenge on behalf of the cluster, and provides the challenger with a cluster remote certification report on behalf of the cluster.
  • the cluster remote certification report is generated by the authentication server after verifying the self-recommendation information generated by the node 82n for its own off-chain TEE, that is, the cluster remote certification report is a remote certification report corresponding to the off-chain TEE of node 82n.
  • the self-recommendation information carried in the cluster remote certification report contains the first to-be-verified hash value.
  • the first to-be-verified hash value is the hash value of the preset information of the off-chain TEE of node 82n.
  • the verification hash value is used by the challenger to verify the signature of the cluster remote attestation report according to the public key of the authentication server, and the signature verification is passed, and the remote attestation result contained in the cluster remote attestation report is certified.
  • the first standard hash value of the off-chain TEE (for example, the trusted hash value of the above-mentioned preset information of the off-chain TEE) is compared, and the comparison result is consistent as a prerequisite for the challenger to confirm the authenticity of the off-chain TEE.
  • the process of the challenger verifying the off-chain TEE according to the cluster remote certification report can refer to the content of the aforementioned control node to verify the off-chain TEE of the node to be added, which will not be repeated here.
  • the off-chain TEE verified by the challenger according to the cluster remote attestation report is the off-chain TEE of node 82n.
  • node 82n when node 82n generates its own node identity information in the off-chain TEE, it can also generate cluster identity information representing the cluster in the off-chain TEE, and perform a check on the generated cluster identity information.
  • the hash calculation obtains the second standard hash value; wherein the generated cluster identity information includes the cluster identity public key and the node identity information of the node 82n other than the node identity public key.
  • the difference between the node identity information of the node 82n and the cluster identity information is: the public key recorded in the node identity information is the node identity public key, and the public key recorded in the cluster identity information is the cluster Identity public key; other than this, other identity information is the same.
  • the client 81 can use the second standard hash value to verify the first cluster identity information provided by the node 82n (that is, the declared cluster identity information, including the cluster identity public key and other identity information of the node 82n, which is not necessarily real data.
  • the identity information to be verified if the verification is passed, the cluster identity public key contained in the cluster identity information is obtained, so as to use the cluster identity public key to complete subsequent verification of the contract under the target chain.
  • the client performs a hash calculation on the acquired first cluster identity information to obtain the second hash value to be verified, and performs the second hash value to be verified with the second standard hash value provided by the node 82n Compare, and determine that the cluster identity verification is passed if the comparison results are consistent.
  • the cluster identity information is generated by the node 82n in the off-chain TEE and calculated to obtain the second standard hash value, after determining the authenticity of the off-chain TEE according to the remote attestation report, if the second hash value to be verified is consistent with the second standard If the hash value is the same, it means that the first cluster identity information provided by the privacy computing node 82 is the cluster identity information generated in the off-chain TEE, so that the cluster identity public key contained therein is the actual maintenance of the privacy computing node 82 corresponding to the cluster.
  • the cluster identity public key, and the cluster identity public key actually maintained by the private computing node 82 can be used to verify the signature of the private computing node 82.
  • the node 82n can send the second standard hash value, the remote certification report, and the first cluster identity information to the client 81 through the control node 82. It should be noted that this part of the content can refer to the aforementioned process of the control node verifying the node to be added, which will not be repeated here.
  • the cluster identity information generated by the node 82n in the off-chain TEE may include the cluster identity public key, other identity information other than the node identity public key in the node identity information of the node 82n, and The hash value of the preset information of the off-chain TEE, after the node 82n generates the cluster identity information in its own off-chain TEE, the generated cluster identity information is hashed to obtain the third standard hash value, then the third standard The hash value is equivalent to simultaneously achieving the functions of the first hash value to be checked and the second standard hash value.
  • the node 82n can provide the client 81 with a remote certification report, a third standard hash value, and second cluster identity information (this can be understood as the identity information to be verified).
  • the second cluster identity information includes the cluster identity public key, other identity information of the node 82n, and a fourth hash value to be verified, and the fourth hash value to be verified is the hash value of the preset information of the off-chain TEE;
  • the second cluster identity information is the declared cluster identity information, and not necessarily the real cluster identity information provided by the node 82n.
  • the client 81 performs signature verification on the remote certification report according to the public key of the authentication server, and when the signature verification is passed and the remote certification result contained in the remote certification report is certified, the acquired second cluster identity
  • the information is hashed to obtain the third hash value to be verified, and the third hash value to be verified is compared with the third standard hash value.
  • the comparison result is consistent, it means that the second cluster identity information provided by the privacy computing node 82 is the cluster identity information generated in the off-chain TEE, that is, the fourth hash value to be verified is the actual value of the off-chain TEE.
  • the hash value of the preset information is consistent.
  • the pre-obtained fourth standard hash value for the preset information of the off-chain TEE is further compared with the fourth hash value to be verified, and the comparison result is consistent as a prerequisite for confirming the authenticity of the off-chain TEE condition.
  • the cluster identity public key included in the second cluster identity information can be determined as the cluster identity public key actually maintained by the privacy computing node 82, which can be used to perform signature verification on the contract information to be verified.
  • the node 82n can send the third standard hash value, the remote certification report, and the second cluster identity information to the client 81 through the control node 82. It should be noted that this part of the content can refer to the aforementioned process of the control node verifying the node to be added, which will not be repeated here.
  • the cluster remote certification report and the contract information to be verified are sent by the node 82n to the control node 82, and then forwarded by the control node 82 to the client 81.
  • the control node 82 can provide the cluster remote certification report and the contract information to be verified to the client 81 together, or can provide the cluster remote certification report first, and obtain the pending verification from the node 82n after the client 81 passes the verification according to the cluster remote certification report Contract information to provide the client 81 with contract information to be verified.
  • the contract information to be verified is the contract information of the target off-chain contract deployed at node 82n, and is performed by node 82n in the off-chain TEE of node 82n using the cluster identity private key (maintained in the off-chain TEE of node 82n) sign.
  • the node 82n reads the target off-chain contract deployed at the node 82n into the off-chain TEE, and uses the cluster identity private key to sign.
  • the cluster identity public key is used for treatment Verify the contract information for signature verification, and verify the contract information to be verified based on the contract information of the contract under the target chain.
  • the cluster identity public key is in a public state, for example, the control node 81 publicly releases the cluster identity public key to the client 81 to obtain it.
  • the client 81 obtains the cluster identity information through the above-mentioned method of verifying cluster identity information.
  • the contract information of the contract under the target chain may also be in a public state, for example, the deployment direction of the contract under the target chain is publicly released for the client 81 to obtain the contract information.
  • the contract information may include the name, description, version number, bytecode hash value, contract identity public key and other information of the off-chain contract, which is not restricted in this specification.
  • the client 81 can determine that the client 81 is verifying the contract under the target chain through the oracle mechanism of the blockchain node.
  • the target off-chain contract is executed by the node 82n in the off-chain TEE trusted execution environment, that is, it is ensured that the target off-chain contract deployed in the node 82n is credible and can perform computing tasks as expected by the user.
  • various remote attestation reports can have a certain time limit, such as 30 minutes or other durations, and the time-out remote attestation report is judged to be invalid.
  • the remote certification report involved in the process of sharing the cluster identity key is obtained by the node from the authentication server control node in real time, and the cluster remote certification report can be cached locally by the control node and the aging time can be set.
  • 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 91 wishes to call the deployed off-chain contract (for example, after the verification target off-chain contract is passed).
  • the client 91 can send a call request to the control node 92 through an off-chain channel.
  • the call request is encrypted using the cluster identity public key.
  • the control node 92 can allocate the call request to an off-chain privacy calculation in the cluster based on the load balancing algorithm.
  • the node 92n responds to the call request.
  • the node 92n 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 92n 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 91 wants to call; if the off-chain contract contains only one function, or the client 91 wants to call all 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 92n can obtain the input parameter data accordingly, especially when the client 91 itself is not data.
  • the interaction between the client 91 and the data owner can be omitted, and the amount of data requested by the call can also be reduced, and the transmission speed can be accelerated.
  • the node 92n can execute the bytecode of the off-chain contract in the off-chain TEE to process the incoming parameter data, so as to obtain the corresponding call result.
  • the node 92n can encrypt the call result in the off-chain TEE, and then feed it back to the client 91 via the control node 92.
  • the client 91 can send a call request to the control node 92 through an on-chain channel.
  • the client 91 may submit an off-chain contract invocation transaction to the blockchain network 93, and the off-chain contract invocation transaction includes a invocation request, and the invocation request is encrypted by the client 91 using the cluster identity public key.
  • the off-chain contract call transaction itself can also be encrypted transmission, such as using the cluster identity public key to encrypt the call transaction, or other encryption methods. For this, please refer to the content of data encryption 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.
  • the oracle server 94 After the contract event is monitored by the oracle server 94, the oracle server 94 obtains the call request and Transmitted to the control node 92. Then, the control node 92 distributes the call request to, for example, the off-chain privacy computing node 92n to respond. In addition, the control node 92 can feed the call result back to the chain through the oracle mechanism, and the node 93n can initiate a transaction to upload the call result to the chain, or the node 93n can feed back the call result to the client 91, and the client The terminal 91 re-initiates a transaction to upload the call result to the chain.
  • the client 91 can submit an encrypted off-chain contract invocation transaction to the blockchain network 93.
  • the off-chain contract invocation transaction includes the contract ID, function name and input parameter information, and
  • the off-chain contract call transaction calls the on-chain contract used to obtain input parameter data.
  • node 93n receives the encrypted off-chain contract call transaction, it decrypts it in the on-chain TEE created by node 93n, and then executes the called on-chain contract through the virtual machine deployed in the on-chain TEE to obtain the input parameters
  • the blockchain data of the data is usually in an encrypted state.
  • the node 93n can decrypt it into plaintext in the on-chain TEE, and then call the plaintext blockchain data and the off-chain contract to the contract ID,
  • the function name is packaged into a call request, and the call request is encrypted using the cluster identity public key in the on-chain TEE, and then transmitted to the control node 92 based on the oracle mechanism, and the control node 92 distributes the call request to such as off-chain privacy computing Node 92n responds.
  • the control node 92 can feed back the call result to the chain through the oracle mechanism, and the node 93n can upload the call result to the chain.
  • the client 91 or the node 93n 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 92n After the off-chain privacy computing node 92n 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, so as to ensure 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 92n can sign the calling result through the contract signature private key of the called off-chain contract, and the client 91 or node 93n can use the contract signature public key to verify the signature, so as to confirm 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 91 can also directly interact with a single off-chain private computing node to invoke an off-chain contract deployed on the off-chain private computing node, which will not be repeated here.
  • the encryption and decryption in this manual can use the same set of key pairs, or configure a set of encryption key pairs and a set of signature key pairs separately.
  • a group of key pairs corresponding to different encryption algorithms, there may be multiple public keys and corresponding private keys at the same time.
  • the following takes the node identity key as an example for description.
  • the cluster identity key and contract identity key are similar.
  • the node identity key is a set of key pairs, including the node identity public key and the node identity private key.
  • the node identity public key can be used to encrypt data, then the node identity private key can be used to decrypt the data; the node identity private key can be used to sign the data, then the node identity public key can be used to sign and verify the data .
  • two sets of key pairs can be configured, namely a node encryption key pair and a node signature key pair. Among them, the node encryption key pair is used to encrypt and decrypt data, and the node signature key pair is used to sign data and verify the signature.
  • any node in the cluster shares the cluster identity key with other nodes, and the sharing process is described from the side of any node.
  • any node in the cluster receives the cluster identity key shared by other nodes (that is, the other nodes share the cluster identity key with any node), and from any node The sharing process is described on the side. It should be noted that the description involved in the sharing process shown in FIG. 1 can also be applied to the sharing process shown in FIG. 10, which will not be repeated hereafter.
  • FIG. 10 is a flowchart of another method for sharing a cluster key according to an exemplary embodiment.
  • the sharing process may include step 1002 to step 1006.
  • Step 1002 any node in the off-chain privacy computing cluster provides a first remote attestation report to other nodes in the off-chain privacy computing cluster, and the first remote attestation report is created by the authentication server for the any node.
  • the first self-recommendation information generated by the trusted execution environment under the first chain is generated after verification.
  • Step 1004 the any node receives the data corresponding to the off-chain privacy computing cluster sent by the other node when the first off-chain trusted execution environment is determined to be credible according to the first remote attestation report.
  • the cluster identity key and the second remote attestation report the cluster identity key is generated in the trusted execution environment of the second chain created by the other nodes, in the blockchain node and the off-chain privacy computing cluster
  • the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification
  • the second remote attestation report is verified by the authentication server on the other
  • the node is generated after verifying the second self-recommendation information generated by the trusted execution environment under the second chain.
  • the operation for any node to determine the credibility of the trusted execution environment under the second chain according to the second remote attestation report includes: verifying the second remote attestation according to the public key of the authentication server The report is subjected to signature verification; in the case where the signature verification is passed and the remote authentication result contained in the second remote attestation report is certified, extract the first from the second self-recommendation information carried in the second remote attestation report.
  • the hash value to be checked, the first hash value to be checked is the hash value of the preset information in the trusted execution environment under the second chain; the first standard for the preset information obtained in advance is used.
  • the hope value is compared with the first hash value to be checked, and the comparison result is consistent as a prerequisite for confirming the trustworthiness of the trusted execution environment under the second chain.
  • the any node provides the first node identity information to the other nodes, and the first node identity information includes the node identity public key of any node and other identity information of the any node ,
  • the first identity information is hashed by the other nodes to obtain a second hash value to be verified;
  • any node provides a second standard hash value to the other node, and the second standard
  • the hash value is obtained by hashing the generated node identity information after any node generates its own node identity information in the trusted execution environment of the first chain; the second standard hash value is compared with When the second hash values to be verified are consistent, the cluster identity key is signed by the other node using the node identity private key of the other node, and the node identity public key of any node is used. The key encrypts the signed cluster identity key.
  • the any node obtains the identity information of the second node provided by the other node, and performs a hash calculation on the identity information of the second node to obtain the third hash value to be verified.
  • the node identity information includes the node identity public key of the other node and other identity information of the other node; the any node obtains the third standard hash value provided by the other node, and the third standard hash value It is obtained by hashing the generated node identity information after the other node generates its own node identity information in the trusted execution environment under the second chain; the any node is in the third to-be-verified Ha If the desired value is consistent with the third standard hash value, the node identity private key of any node is used to decrypt the received cluster identity key, and the node identity information of the other nodes contains Verify the signature of the cluster identity key with the node identity public key of, and maintain the cluster identity key in the trusted execution environment under the first chain if the signature verification is passed.
  • the cluster identity private key in the key decrypts the target chain contract and deploys it; in the case where the blockchain node initiates a call to the target chain contract through the oracle mechanism, it is trusted in the first chain
  • the target chain contract is executed in the execution environment, and the execution result is fed back to the blockchain node through the oracle mechanism.
  • the any node before the any node receives the encrypted target off-chain contract, the any node responds to the challenge initiated by the deployer of the target off-chain contract and provides the deployer with The first remote attestation report; wherein the encrypted target off-chain contract is sent by the deploying party when it is determined that the trusted execution environment under the first chain is credible according to the first remote attestation report .
  • any node adopts the target chain contract in the first chain trusted execution environment.
  • the contract identity private key in the contract identity key signs the execution result
  • the signed execution result uses the contract identity public key in the contract identity key to sign the execution result and pass the signature In the case of verification, it is determined to be generated by the target chain contract.
  • the operation of any node to generate the contract identity key of the off-chain contract of the target chain includes: using the off-chain private computing cluster in the trusted execution environment of the first chain.
  • the shared key generation algorithm generates the contract identity key based on the cluster identity key and the global identification information of the target chain contract; wherein, the target chain contract is deployed in the off-chain privacy calculation At each node in the cluster.
  • any node provides the cluster remote attestation report to the challenger of the target chain contract.
  • the cluster remote attestation report is generated after the authentication server verifies the first self-recommendation information; the challenger is provided with the contract information to be verified of the contract under the target chain deployed at any node, and the to-be-verified
  • the contract information is signed by any node in the trusted execution environment under the first chain using the cluster identity private key in the cluster identity key; the contract information to be verified is signed by the challenger according to the
  • the cluster identity public key in the cluster identity key is used to perform signature verification on the contract information to be verified, and according to the The contract information of the contract under the target chain performs contract information verification on the contract information to be verified, and when the signature verification and contract information verification pass, it is determined that the challenger is verifying the contract information through the oracle mechanism
  • the first self-recommendation information carried in the cluster remote certification report contains a fourth hash value to be verified, and the fourth hash value to be verified is the value of the trusted execution environment under the first chain.
  • the hash value of the preset information, the fourth hash value to be verified is used by the challenger to verify the signature of the cluster remote attestation report according to the public key of the authentication server and the signature verification is passed, and the If the remote authentication result contained in the cluster remote attestation report is passed authentication, it is compared with the pre-obtained fourth standard hash value for the preset information in the trusted execution environment under the first chain, and the comparison result is consistent As a prerequisite for the challenger to confirm that the trusted execution environment under the first chain is credible.
  • any node provides cluster identity information to the challenger, and the cluster identity information includes the cluster identity public key in the cluster identity key and the node identity information of any node except for the cluster identity information.
  • the identity information other than the node identity public key of any node the cluster identity information is hashed by the challenger to obtain the fifth hash value to be verified; the any node sends the challenger to the Provide a fifth standard hash value, the fifth standard hash value is hashed after the cluster identity information is generated by any node in the trusted execution environment under the first chain Calculated; the fifth standard hash value is used for comparison with the fifth hash value to be verified, and the challenger obtains the cluster identity information contained in the cluster identity information if the comparison result is consistent The cluster identity public key.
  • the challenger initiates a challenge after each node in the off-chain privacy computing cluster deploys the target off-chain contract, and the challenge initiated is controlled by the off-chain privacy computing cluster's control node Receive, and forward to any node.
  • the any node receives the invocation transaction initiated by the blockchain node to the contract under the target chain through the oracle mechanism, and the invocation transaction is performed using the cluster identity public key in the cluster identity key Encrypted, the invocation transaction is received by the control node of the off-chain privacy computing cluster, and forwarded to any node according to the load of the off-chain privacy computing cluster; in the first-chain trusted execution environment
  • the cluster identity private key in the cluster identity key is used to decrypt the call transaction, so as to execute the target chain contract in response to the decrypted call transaction.
  • Step 1006 The any node recognizes the cluster identity key when it is determined that the second remote attestation report indicates that the trusted execution environment under the second chain is trustworthy.
  • any node recognizes the cluster identity key under the condition that the second remote attestation report indicates that the trusted execution environment under the second chain is trustworthy, so that the trusted execution environment under the first chain of its own The cluster identity key is maintained within.
  • the client can also directly interact with the private computing node to complete operations such as deploying smart contracts on the private computing node, initiating challenges to the smart contract, verifying the smart contract, and invoking the smart contract without passing through the zone.
  • the oracle mechanism of the block chain completes the above operations, and at the same time, the calculation results obtained by invoking the smart contract deployed on the privacy computing node do not need to be fed back to the block chain.
  • “off-chain privacy computing nodes” will be referred to as “privacy computing nodes”
  • “off-chain privacy computing clusters” will be referred to as “privacy computing clusters”.
  • Off-chain trusted execution environment is called “trusted execution environment”
  • off-chain contract is called “smart contract”.
  • principle of the technical solution is similar to the foregoing embodiment, and the involved implementation details can also refer to the foregoing embodiment, so the detailed description will not be given below.
  • FIG. 11 is a flowchart of another method for sharing a cluster key provided by an exemplary embodiment. As shown in FIG. 11, the method may include step 1102 to step 1106.
  • Step 1102 Any node in the privacy computing cluster obtains a first remote attestation report sent by other nodes in the privacy computing cluster.
  • the first self-recommendation information generated by the execution environment is generated after verification.
  • any node performs signature verification on the first remote certification report according to the public key of the certification server; after the signature verification is passed and the remote certification result contained in the first remote certification report is certified
  • extracting a first hash value to be verified from the first self-recommendation information carried in the first remote attestation report, and the first hash value to be verified in the first trusted execution environment The hash value of the preset information; the first standard hash value obtained in advance for the preset information in the first trusted execution environment is compared with the first hash value to be verified, and the comparison result is consistent As a prerequisite for confirming that the first trusted execution environment is credible.
  • Step 1104 the any node obtains a cluster identity key corresponding to the privacy computing cluster, the cluster identity key is generated in a second trusted execution environment created by any node, In the process of each node in the privacy computing cluster interacting to deploy or invoke smart contracts, the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification.
  • Step 1106 In the case where the first trusted execution environment is determined to be credible according to the first remote attestation report, any node sends the cluster identity key and the second remote attestation report to the other nodes In the case that the second remote attestation report indicates that the second trusted execution environment is trustworthy, the cluster identity key is recognized by the other nodes, and the second remote attestation report is verified by the authentication server Any node is generated after verifying the second self-recommendation information generated by the second trusted execution environment.
  • the any node obtains the first node identity information provided by the other nodes, and performs a hash calculation on the obtained first node identity information to obtain the second hash value to be verified.
  • the first node identity information includes the node identity public key of the other node and the other identity information of the other node; the second standard hash value provided by the other node is obtained, and the second standard hash value is determined by the After other nodes generate their own node identity information in the first trusted execution environment, perform hash calculation on the generated node identity information; hash the second to-be-verified hash value with the second standard hash value The value is compared, and the node identity public key contained in the node identity information of the other nodes is obtained if the comparison result is consistent; the node identity private key of any node is used to sign the cluster identity key, And the node identity public key of the other nodes is used to encrypt the signed cluster identity key.
  • any node provides second node identity information to the other nodes, and the second node identity information includes the node identity public key of any node and other identity information of any node
  • the any node provides a third standard hash value to the other nodes, the third standard hash value is generated by any node in the second trusted execution environment after its own node identity information Perform hash calculation on the generated node identity information; wherein, in the case where the third hash value to be verified obtained by hash calculation on the second node identity information is consistent with the third standard hash value
  • the other node uses the node identity private key of the other node to decrypt the received cluster identity key, and uses the node identity public key contained in the node identity information of any node to verify the cluster identity secret. And maintain the cluster identity key in the first trusted execution environment if the signature verification is passed.
  • any node receives the target smart contract encrypted by the cluster identity public key in the cluster identity key, it passes through the second trusted execution environment in the second trusted execution environment.
  • the cluster identity private key in the cluster identity key decrypts and deploys the target smart contract; in the case where the client initiates a call to the target smart contract, executes the target smart contract in the second trusted execution environment The target smart contract, and the execution result is fed back to the client.
  • any node in response to the challenge initiated by the deployer of the target smart contract, any node provides the second remote attestation report to the deployer; wherein the encrypted target smart contract is owned by the deployer.
  • the deploying party determines that the second trusted execution environment is credible according to the second remote attestation report.
  • any node in the second trusted execution environment uses the contract identity private key in the contract identity key of the target smart contract to sign the execution result.
  • the execution result is determined to be generated by the target smart contract when the execution result is signed and verified by the contract identity public key in the contract identity key and the signature verification is passed.
  • the operation of generating the contract identity key of the target smart contract includes: adopting the key generation algorithm shared between the nodes in the privacy computing cluster in the second trusted execution environment, based on all The cluster identity key and the global identification information of the target smart contract generate the contract identity key; wherein the target smart contract is deployed at each node in the privacy computing cluster.
  • any node before the client initiates a call to the target smart contract, any node provides the cluster remote attestation report to the challenger of the target smart contract, and the cluster remote attestation report is certified by
  • the server verifies the second self-recommended information and generates it; provides the challenger with the to-be-verified contract information of the target smart contract deployed at any node, and the to-be-verified contract information is
  • the node uses the cluster identity private key in the cluster identity key to sign in the second trusted execution environment, and the cluster identity private key in the cluster identity key is maintained by any node in the first 2.
  • the cluster identity key In a trusted execution environment; when the challenger determines that the second trusted execution environment is credible according to the cluster remote attestation report for the contract information to be verified, the cluster identity key is used
  • the cluster identity public key performs signature verification on the contract information to be verified, and performs contract information verification on the contract information to be verified according to the contract information of the target smart contract, and when the signature verification and contract information verification pass, It is determined that when the challenger initiates a call to the target smart contract through the oracle mechanism of a blockchain node, the target smart contract is executed by any node in the second trusted execution environment.
  • the second self-recommendation information carried in the cluster remote certification report contains a fourth hash value to be verified, and the fourth hash value to be verified is a preset value of the second trusted execution environment
  • the hash value of the information, the fourth hash value to be verified is used by the challenger to verify the signature of the cluster remote certification report according to the public key of the authentication server and the signature verification is passed, and the cluster remote
  • the remote authentication result contained in the certification report is passed authentication, it is compared with the pre-obtained fourth standard hash value for the preset information in the second trusted execution environment, and the comparison result is consistent as the challenge
  • the party confirms the prerequisites for the credibility of the second trusted execution environment.
  • the any node provides cluster identity information to the challenger, and the cluster identity information includes the cluster identity public key in the cluster identity key and the node identity information of any node
  • the cluster identity information is hashed by the challenger to obtain the fifth hash value to be verified
  • the challenger provides a fifth standard hash value, and the fifth standard hash value is hashed by any node after the cluster identity information is generated in the second trusted execution environment.
  • the fifth standard hash value is used to compare with the fifth hash value to be verified, and the challenger obtains all the cluster identity information contained in the cluster identity information if the comparison result is consistent.
  • the cluster identity public key is used to compare with the fifth hash value to be verified.
  • the any node receives the call transaction initiated by the client to the target smart contract, the call transaction is encrypted with the cluster identity public key in the cluster identity key, and the call The transaction is received by the control node of the privacy computing cluster, and forwarded to any node according to the load of the privacy computing cluster; the cluster in the cluster identity key is used in the second trusted execution environment The identity private key decrypts the call transaction to execute the target smart contract in response to the decrypted call transaction.
  • FIG. 12 is a flowchart of another method for sharing a cluster key provided by an exemplary embodiment. As shown in FIG. 12, the method may include step 1202 to step 1206.
  • Step 1202 Any node in the privacy computing cluster provides a first remote attestation report to other nodes in the privacy computing cluster.
  • the first self-recommendation information generated by the execution environment is generated after verification.
  • the operation for any node to determine the credibility of the second trusted execution environment according to the second remote attestation report includes: performing the second remote attestation report according to the public key of the authentication server Signature verification; in the case where the signature verification is passed and the remote authentication result contained in the second remote attestation report is certified, extract the first to-be-verified from the second self-recommendation information carried in the second remote attestation report
  • the hash value, the first to-be-checked hash value is the hash value of the preset information in the second trusted execution environment; the pre-obtained first hash value for the preset information in the second trusted execution environment
  • a standard hash value is compared with the first hash value to be checked, and the comparison result is consistent as a prerequisite for confirming that the second trusted execution environment is trustworthy.
  • Step 1204 The any node receives the cluster identity key corresponding to the private computing cluster sent by the other node when the first trusted execution environment is determined to be credible according to the first remote attestation report And a second remote attestation report, the cluster identity key is generated in a second trusted execution environment created by the other nodes, and the client interacts with each node in the privacy computing cluster to deploy or call smart contracts
  • the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification
  • the second remote attestation report is generated by the authentication server to the other nodes for the second trusted execution environment
  • the second self-recommendation information is generated after verification.
  • Step 1206 The any node approves the cluster identity key when it is determined that the second remote attestation report indicates that the second trusted execution environment is credible.
  • the any node provides the first node identity information to the other nodes, and the first node identity information includes the node identity public key of any node and other identity information of the any node ,
  • the first identity information is hashed by the other nodes to obtain a second hash value to be verified;
  • any node provides a second standard hash value to the other node, and the second standard
  • the hash value is obtained by hashing the generated node identity information after any node generates its own node identity information in the first trusted execution environment; the second standard hash value is compared with the When the second hash value to be verified is consistent, the cluster identity key is signed by the other node using the node identity private key of the other node, and the node identity public key pair of any node is used The signed cluster identity key is encrypted.
  • the any node obtains the identity information of the second node provided by the other node, and performs a hash calculation on the identity information of the second node to obtain the third hash value to be verified.
  • the node identity information includes the node identity public key of the other node and other identity information of the other node; the any node obtains the third standard hash value provided by the other node, and the third standard hash value After the other node generates its own node identity information in the second trusted execution environment, it is obtained by hashing the generated node identity information; the third hash value to be verified by any node
  • the node identity private key of any node is used to decrypt the received cluster identity key, and the node contained in the node identity information of the other node is used
  • the identity public key verifies the signature of the cluster identity key, and maintains the cluster identity key in the first trusted execution environment if the signature verification is passed.
  • any node receives the target smart contract encrypted by the cluster identity public key in the cluster identity key, it passes through the first trusted execution environment in the first trusted execution environment.
  • the cluster identity private key in the cluster identity key decrypts the target smart contract and deploys it; in the case where the client initiates a call to the target smart contract, executes the target smart contract in the first trusted execution environment The target smart contract, and the execution result is fed back to the client.
  • any node before receiving the encrypted target smart contract, any node responds to the challenge initiated by the deployer of the target smart contract and provides the first remote attestation report to the deployer ; Wherein, the encrypted target smart contract is sent by the deploying party when it is determined that the first trusted execution environment is credible according to the first remote attestation report.
  • the contract identity private key pair in the contract identity key of the target smart contract is used in the first trusted execution environment
  • the execution result is signed, and the signed execution result is determined by the target when the execution result is signed and verified by the contract identity public key in the contract identity key and the signature verification is passed. Smart contract generation.
  • the operation of any node to generate the contract identity key of the target smart contract includes: adopting the key shared between the nodes in the privacy computing cluster in the first trusted execution environment A generating algorithm generates the contract identity key based on the cluster identity key and the global identification information of the target smart contract; wherein the target smart contract is deployed at each node in the privacy computing cluster.
  • any node before the client initiates a call to the target smart contract, any node provides the cluster remote attestation report to the challenger of the target smart contract, and the cluster remote attestation report is certified by
  • the server verifies the first self-recommendation information and generates it; provides the challenger with the to-be-verified contract information of the target smart contract deployed at any of the nodes, and the to-be-verified contract information is
  • the node uses the cluster identity private key in the cluster identity key to sign in the first trusted execution environment; the challenger determines the first step according to the cluster remote attestation report for the contract information to be verified.
  • the cluster identity public key in the cluster identity key is used to perform signature verification on the contract information to be verified, and the contract information to be verified is verified according to the contract information of the target smart contract Contract information is verified by contract information, and when signature verification and contract information verification are passed, it is determined that when the challenger initiates a call to the target smart contract through the oracle mechanism of the blockchain node, the target smart contract Is executed by any node in the first trusted execution environment.
  • the first self-recommendation information carried in the cluster remote certification report contains a fourth hash value to be verified, and the fourth hash value to be verified is a preset value of the first trusted execution environment
  • the hash value of the information, the fourth hash value to be verified is used by the challenger to verify the signature of the cluster remote certification report according to the public key of the authentication server and the signature verification is passed, and the cluster remote If the remote authentication result contained in the certification report is passed authentication, it is compared with the pre-obtained fourth standard hash value for the preset information in the first trusted execution environment, and the comparison result is consistent as the challenge
  • the party confirms the preconditions for the credibility of the first credible execution environment.
  • any node provides cluster identity information to the challenger, and the cluster identity information includes the cluster identity public key in the cluster identity key and the node identity information of any node except for the cluster identity information.
  • the identity information other than the node identity public key of any node the cluster identity information is hashed by the challenger to obtain the fifth hash value to be verified; the any node sends the challenger to the Provide a fifth standard hash value, the fifth standard hash value is obtained by hashing the cluster identity information after any node generates the cluster identity information in the first trusted execution environment
  • the fifth standard hash value is used for comparison with the fifth hash value to be verified, and the challenger obtains the cluster identity contained in the cluster identity information if the comparison result is consistent Public key.
  • the any node receives the call transaction initiated by the client to the target smart contract, the call transaction is encrypted with the cluster identity public key in the cluster identity key, and the call The transaction is received by the control node of the privacy computing cluster, and forwarded to any node according to the load of the privacy computing cluster; the cluster in the cluster identity key is used in the first trusted execution environment The identity private key decrypts the call transaction to execute the target smart contract in response to the decrypted call transaction.
  • this specification also provides an embodiment of an apparatus for sharing a cluster key.
  • the embodiment of the device for sharing the cluster key in this specification can be applied to electronic equipment.
  • the device embodiments can be implemented by software, or can be implemented by hardware or a combination of software and hardware.
  • Taking software implementation as an example as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory through the processor of the electronic device where it is located.
  • FIG. 13 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • the device includes a processor 1302, an internal bus 1304, a network interface 1306, a memory 1308, and a non-volatile memory 1310.
  • the processor 1302 reads the corresponding computer program from the non-volatile memory 1310 to the memory 1308 and then runs it to form a device for sharing the cluster key 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 sharing the cluster key may include: a report obtaining unit 1401, which enables any node in the off-chain privacy computing cluster to obtain the off-chain privacy computing
  • the first remote attestation report sent by other nodes in the cluster, the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by the other nodes for the first-chain trusted execution environment created
  • the key obtaining unit 1402 enables any node to obtain the cluster identity key corresponding to the off-chain privacy computing cluster, and the cluster identity key is in the second chain trusted execution environment created by any node Generated, in the process of the blockchain node interacting with each node in the off-chain privacy computing cluster to deploy or call the off-chain contract, the cluster identity key is used to encrypt, decrypt and/or sign the interactive data Verification;
  • the sending unit 1403 which enables any node to send the cluster identity secret to the other nodes when the trusted execution environment under the first chain is determined to be credible according
  • the cluster identity key is recognized by the other nodes, and the second The remote certification report is generated by the authentication server after verifying the second self-recommendation information generated by any node for the second chain trusted execution environment.
  • the report obtaining unit 1401 is specifically configured to: perform signature verification on the first remote attestation report according to the public key of the authentication server; If the result is that the authentication is passed, the first to-be-verified hash value is extracted from the first self-recommendation information carried in the first remote attestation report, and the first to-be-verified hash value is the first chain
  • the hash value of the preset information in the trusted execution environment under the trusted execution environment; the first standard hash value obtained in advance for the preset information in the trusted execution environment under the first chain and the first hash value to be verified The comparison is made, and the consistency of the comparison result is taken as a prerequisite for confirming that the trusted execution environment under the first chain is credible.
  • the sending unit 1403 is specifically configured to: obtain the first node identity information provided by the other node, and compare the obtained first node identity information A node’s identity information is hashed to obtain a second to-be-verified hash value, the first node’s identity information includes the node identity public key of the other node and other identity information of the other node; and the other node’s identity information is obtained;
  • the second standard hash value provided by the node, and the second standard hash value is used by the other node to hash the generated node identity information after the other node generates its own node identity information in the trusted execution environment under the first chain It is calculated; the second hash value to be verified is compared with the second standard hash value, and the node identity information contained in the node identity information of the other nodes is obtained if the comparison result is consistent.
  • the node identity private key of any node is used to sign the cluster identity key, and the node identity
  • the sending unit 1403 is specifically configured to: any node provides second node identity information to the other nodes, and the second node identity information includes the node identity public key of any node and the any node identity information.
  • Other identity information of a node any node provides a third standard hash value to the other nodes, and the third standard hash value is determined by any node in the trusted execution environment under the second chain
  • the generated node identity information is hashed to obtain its own node identity information; wherein, the third to-be-verified hash value obtained by the hash calculation of the second node identity information is compared with the third
  • the other node uses the node identity private key of the other node to decrypt the received cluster identity key, and uses the node identity contained in the node identity information of any node
  • the public key verifies the signature of the cluster identity key, and maintains the cluster identity key in the trusted execution environment under the first chain if the signature verification is passed.
  • the sending unit 1403 is specifically configured to: in the case of receiving the target off-chain contract encrypted by the cluster identity public key in the cluster identity key, in the second chain trusted execution environment In the cluster identity key, the cluster identity private key in the cluster identity key decrypts the target chain contract and deploys; in the case where the blockchain node initiates a call to the target chain contract through the oracle mechanism, in the The target chain contract is executed in the second chain trusted execution environment, and the execution result is fed back to the blockchain node through the oracle mechanism.
  • the sending unit 1403 is further configured to: respond to the challenge initiated by the deployer of the target off-chain contract, The deploying party provides the second remote attestation report; wherein the encrypted target off-chain contract is determined by the deploying party according to the second remote attesting report to determine the trusted execution environment of the second chain. Send in case of letter.
  • the sending unit 1403 is specifically configured to: use all nodes in the trusted execution environment under the second chain.
  • the contract identity private key in the contract identity key of the contract under the target chain signs the execution result, and the signed execution result uses the contract identity public key in the contract identity key to the execution result If the signature verification is performed and the signature verification is passed, it is determined to be generated by the target chain off-chain contract.
  • the operation of generating the contract identity key for the off-chain contract of the target chain includes: generating a secret key shared between the nodes in the off-chain privacy computing cluster in the second chain trusted execution environment Algorithm to generate the contract identity key based on the cluster identity key and the global identification information of the target chain off-chain contract; wherein the target off-chain contract is deployed at each node in the off-chain privacy computing cluster .
  • the sending unit 1403 is specifically configured to: any node provides the cluster to the challenger of the target chain contract A remote certification report, where the cluster remote certification report is generated by the authentication server after verifying the second self-recommendation information;
  • the challenger is provided with the to-be-verified contract information of the target chain contract deployed at any node, and the to-be-verified contract information is used by any node in the trusted execution environment of the second chain
  • the cluster identity private key in the cluster identity key is used for signing, and the cluster identity private key in the cluster identity key is maintained by any node in the trusted execution environment under the second chain;
  • the contract information to be verified is obtained by the challenger using the cluster identity public key pair in the cluster identity key in the case of determining that the trusted execution environment under the second chain is credible according to the cluster remote attestation report.
  • the target chain contract is executed by any node in the trusted execution environment of the second chain.
  • the second self-recommendation information carried in the cluster remote attestation report includes a fourth hash value to be verified, and the fourth hash value to be verified is a prediction of the trusted execution environment under the second chain.
  • the fourth hash value to be verified is used by the challenger to verify the signature of the cluster remote certification report according to the public key of the authentication server and the signature verification is passed, and the cluster If the remote authentication result contained in the remote attestation report is passed authentication, it is compared with the pre-obtained fourth standard hash value for the preset information in the trusted execution environment under the second chain, and the comparison result is consistent as The challenger confirms the preconditions for the trustworthiness of the trusted execution environment under the second chain.
  • the sending unit 1403 is specifically configured to: any node provides cluster identity information to the challenger, and the cluster identity information includes the cluster identity public key in the cluster identity key and the identity of the any node In the node identity information, other identity information except the node identity public key of any node, the cluster identity information is hashed by the challenger to obtain the fifth hash value to be verified; The node provides a fifth standard hash value to the challenger, and the fifth standard hash value is generated by any node in the trusted execution environment of the second chain after generating the cluster identity information for the challenger.
  • the cluster identity information is obtained by hash calculation; the fifth standard hash value is used for comparison with the fifth hash value to be verified, and the challenger obtains the cluster identity when the comparison result is consistent
  • the cluster identity public key contained in the information is specifically configured to: any node provides cluster identity information to the challenger, and the cluster identity information includes the cluster identity public key in the cluster identity key and the identity of the any node In the node identity information, other identity information except the no
  • the challenger initiates a challenge after deploying the target off-chain contract on each node in the off-chain privacy computing cluster, and the initiated challenge is received by the control node of the off-chain privacy computing cluster , And forward to any node.
  • the sending unit 1403 is specifically configured to: receive a call transaction initiated by a blockchain node to the contract under the target chain through the oracle mechanism, and the call transaction uses the cluster identity public key in the cluster identity key Encryption, the invocation transaction is received by the control node of the off-chain privacy computing cluster, and forwarded to any node according to the load of the off-chain privacy computing cluster; trusted execution off the second chain
  • the cluster identity private key in the cluster identity key is used to decrypt the invocation transaction, so as to execute the target off-chain contract in response to the decrypted invocation transaction.
  • the device for sharing the cluster key may include: a report providing unit 1501 to enable any node in the off-chain privacy computing cluster to report to the off-chain privacy computing Other nodes in the cluster provide a first remote attestation report, the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by any node for the first-chain trusted execution environment created; and receiving; Unit 1502, enabling the any node to receive the data corresponding to the off-chain privacy computing cluster sent by the other node in the case of determining that the first off-chain trusted execution environment is credible according to the first remote attestation report
  • the cluster identity key and the second remote attestation report, the cluster identity key is generated in the second chain trusted execution environment created by the other nodes, in the blockchain node and the off-chain privacy computing cluster During the process of each node interacting to deploy or call an off-chain contract, the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification
  • the report providing unit 1501 is specifically configured to: perform signature verification on the second remote certification report according to the public key of the authentication server; after the signature verification is passed and the remote certification result contained in the second remote certification report is In the case of passing the authentication, the first hash value to be verified is extracted from the second self-recommendation information carried in the second remote attestation report, and the first hash value to be verified is available under the second chain.
  • the hash value of the preset information in the trusted execution environment comparing the first standard hash value obtained in advance for the preset information in the trusted execution environment under the second chain with the first hash value to be verified , And the consistency of the comparison result is used as a prerequisite for confirming the credibility of the trusted execution environment under the second chain.
  • the report providing unit 1501 is specifically configured to: the any node provides first node identity information to the other nodes, and the first node identity information includes the node identity public key of the any node and the Other identity information of any node, the first identity information is hashed by the other node to obtain the second hash value to be verified; the any node provides the second standard hash to the other node The second standard hash value is obtained by hashing the generated node identity information after any node generates its own node identity information in the trusted execution environment under the first chain; When the second standard hash value is consistent with the second hash value to be verified, the cluster identity key is signed by the other node using the node identity private key of the other node, and the The node identity public key of any node encrypts the signed cluster identity key.
  • the report providing unit 1501 is specifically configured to: the any node obtains the second node identity information provided by the other nodes, and hash the second node identity information to obtain the third to-be-verified Ha Hence, the second node identity information includes the node identity public key of the other node and other identity information of the other node; the any node obtains the third standard hash value provided by the other node, so The third standard hash value is obtained by hashing the generated node identity information after the other node generates its own node identity information in the trusted execution environment under the second chain; When the third hash value to be verified is consistent with the third standard hash value, the node identity private key of any node is used to decrypt the received cluster identity key, and the other The node identity public key included in the node identity information of the node verifies the signature of the cluster identity key, and maintains the cluster identity key in the trusted execution environment under the first chain if the signature verification is passed.
  • the processing unit 1503 is further configured to: in the case of receiving the target off-chain contract encrypted by the cluster identity public key in the cluster identity key, perform the trusted execution environment under the first chain In the cluster identity key, the cluster identity private key in the cluster identity key is used to decrypt the target chain contract and deploy; in the case where the blockchain node initiates a call to the target chain contract through the oracle mechanism, in the The target off-chain contract is executed in the first-chain off-chain trusted execution environment, and the execution result is fed back to the blockchain node through the oracle mechanism.
  • the processing unit 1503 is further configured to: make any node respond to the challenge initiated by the deployer of the target off-chain contract to the deployment The party provides the first remote attestation report; wherein the encrypted target off-chain contract is determined by the deploying party based on the first remote attestation report to determine the credibility of the trusted execution environment under the first chain Send it down.
  • the processing unit 1503 is further configured to: enable the any node to use in the trusted execution environment under the first chain
  • the contract identity private key in the contract identity key of the contract under the target chain signs the execution result
  • the signed execution result uses the contract identity public key in the contract identity key to execute the execution
  • the signature verification is performed and the signature verification is passed, it is determined to be generated by the target chain off-chain contract.
  • the operation of any node to generate the contract identity key of the contract under the target chain includes: using the off-chain privacy computing cluster in the first-chain trusted execution environment between nodes in the off-chain private computing cluster.
  • the shared key generation algorithm generates the contract identity key based on the cluster identity key and the global identification information of the target chain contract; wherein, the target chain contract is deployed in the off-chain privacy computing cluster At each node in the.
  • the report providing unit 1501 is further configured to: any node provides the challenger of the target chain contract Cluster remote certification report, the cluster remote certification report is generated after the authentication server verifies the first self-recommendation information; provides the challenger with the pending verification of the target chain contract deployed at any node Contract information, the contract information to be verified is signed by any node in the trusted execution environment under the first chain using the cluster identity private key in the cluster identity key; the contract information to be verified is When the challenger determines that the trusted execution environment under the first chain is credible according to the cluster remote certification report, the challenger uses the cluster identity public key in the cluster identity key to perform the verification on the contract information to be verified.
  • Signature verification and verify the contract information of the contract to be verified according to the contract information of the contract under the target chain, and if the signature verification and contract information verification pass, it is determined that the challenger is passing the blockchain node
  • the target chain contract is executed by any node in the first chain trusted execution environment.
  • the first self-recommendation information carried in the cluster remote attestation report includes a fourth hash value to be verified, and the fourth hash value to be verified is a prediction of the trusted execution environment under the first chain.
  • the fourth hash value to be verified is used by the challenger to verify the signature of the cluster remote certification report according to the public key of the authentication server and the signature verification is passed, and the cluster If the remote authentication result contained in the remote attestation report is certified, it is compared with the pre-obtained fourth standard hash value for the preset information in the trusted execution environment under the first chain, and the comparison result is consistent as The challenger confirms the preconditions for the credibility of the trusted execution environment under the first chain.
  • the report providing unit 1501 is further configured to: the any node provides cluster identity information to the challenger, and the cluster identity information includes the cluster identity public key in the cluster identity key and the any node In the node identity information of any node other than the node identity public key of any node, the cluster identity information is hashed by the challenger to obtain the fifth hash value to be verified; A node provides a fifth standard hash value to the challenger, and the fifth standard hash value is determined by any node after generating the cluster identity information in the trusted execution environment under the first chain. The cluster identity information is obtained by hash calculation; the fifth standard hash value is used for comparison with the fifth hash value to be verified, and the challenger obtains the cluster if the comparison result is consistent The cluster identity public key included in the identity information.
  • the challenger initiates a challenge after deploying the target off-chain contract on each node in the off-chain privacy computing cluster, and the initiated challenge is received by the control node of the off-chain privacy computing cluster , And forward to any node.
  • the receiving unit 1502 is further configured to: receive a call transaction initiated by a blockchain node to the contract under the target chain through the oracle mechanism, and the call transaction uses the cluster identity public key in the cluster identity key Encryption, the call transaction is received by the control node of the off-chain privacy computing cluster, and forwarded to any node according to the load of the off-chain privacy computing cluster; trusted execution off the first chain
  • the cluster identity private key in the cluster identity key is used to decrypt the invocation transaction, so as to execute the target off-chain contract in response to the decrypted invocation transaction.
  • the device for sharing the cluster key may include: a report obtaining unit 1601, which enables any node in the privacy computing cluster to obtain other nodes in the privacy computing cluster
  • the first remote attestation report sent, the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by the other nodes for the first trusted execution environment created;
  • the key acquisition unit 1602 makes The any node obtains the cluster identity key corresponding to the privacy computing cluster, the cluster identity key is generated in the second trusted execution environment created by the any node, and the client communicates with the privacy computing cluster.
  • the cluster identity key is used to encrypt and decrypt the interactive data and/or signature verification; the sending unit 1603 makes any node in accordance with
  • the first remote attestation report determines that the first trusted execution environment is credible
  • the cluster identity key and the second remote attestation report are sent to the other nodes, and the second remote attestation report indicates
  • the cluster identity key is recognized by the other nodes, and the second remote attestation report is reported by the authentication server to the second trusted
  • the second self-recommendation information generated by the execution environment is generated after verification.
  • the report obtaining unit 1601 is specifically configured to: perform signature verification on the first remote attestation report according to the public key of the authentication server; after the signature verification is passed and the remote attestation result contained in the first remote attestation report is In the case of passing the authentication, extract the first to-be-verified hash value from the first self-recommendation information carried in the first remote attestation report, and the first to-be-verified hash value is the first trusted execution
  • the consistent result is used as a prerequisite for confirming that the first trusted execution environment is credible.
  • the sending unit 1603 is further configured to: enable the any node to obtain the first node identity information provided by the other node, And perform a hash calculation on the acquired identity information of the first node to obtain a second hash value to be verified.
  • the first node identity information includes the node identity public key of the other node and other identities of the other node Information; obtain a second standard hash value provided by the other node, the second standard hash value is generated by the other node after generating its own node identity information in the first trusted execution environment
  • the identity information is obtained by hash calculation; the second hash value to be verified is compared with the second standard hash value, and the node identity information of the other nodes is obtained if the comparison result is consistent.
  • the node identity public key of any node; the node identity private key of any node is used to sign the cluster identity key, and the node identity public key of the other nodes is used to encrypt the signed cluster identity key.
  • the sending unit 1603 is specifically configured to: any node provides second node identity information to the other nodes, and the second node identity information includes the node identity public key of any node and the any node identity information.
  • Other identity information of a node any node provides a third standard hash value to the other nodes, and the third standard hash value is generated by any node in the second trusted execution environment
  • the generated node identity information is hashed to obtain its own node identity information; wherein, the third hash value to be verified obtained by the hash calculation of the second node identity information is compared with the third standard Ha If the values are the same, the other node uses the node identity private key of the other node to decrypt the received cluster identity key, and uses the node identity public key contained in the node identity information of any node
  • the signature of the cluster identity key is verified, and the cluster identity key is maintained in the first trusted execution environment if the signature verification is passed.
  • the sending unit 1603 is specifically configured to: in the case of receiving the target smart contract encrypted by the cluster identity public key in the cluster identity key, pass all the smart contracts in the second trusted execution environment.
  • the cluster identity private key in the cluster identity key decrypts the target smart contract and deploys it; in the case where the client initiates a call to the target smart contract, executes all in the second trusted execution environment
  • the target smart contract is described, and the execution result is fed back to the client.
  • the sending unit 1603 is further configured to: make any node respond to the challenge initiated by the deployer of the target smart contract and send The deploying party provides the second remote attestation report; wherein the encrypted target smart contract is determined by the deploying party based on the second remote attestation report to determine the credibility of the second trusted execution environment Send it down.
  • the sending unit 1603 is further configured to: make any node adopt the target smart contract in the second trusted execution environment
  • the contract identity private key in the contract identity key signs the execution result
  • the signed execution result uses the contract identity public key in the contract identity key to sign the execution result and passes In the case of signature verification, it is determined to be generated by the target smart contract.
  • the operation of generating the contract identity key of the target smart contract includes: adopting a key generation algorithm shared between nodes in the privacy computing cluster in the second trusted execution environment, based on the The cluster identity key and the global identification information of the target smart contract generate the contract identity key; wherein the target smart contract is deployed at each node in the privacy computing cluster.
  • the sending unit 1603 is further configured to: make any node provide the cluster remote attestation report to the challenger of the target smart contract, so The cluster remote certification report is generated after the authentication server verifies the second self-recommendation information; the challenger is provided with the contract information to be verified of the target smart contract deployed at any node, and the to-be-verified
  • the contract information is signed by any node in the second trusted execution environment using the cluster identity private key in the cluster identity key, and the cluster identity private key in the cluster identity key is signed by the any node.
  • a node is maintained in the second trusted execution environment; the contract information to be verified is used by the challenger when the second trusted execution environment is determined to be credible according to the cluster remote attestation report.
  • the cluster identity public key in the cluster identity key performs signature verification on the contract information to be verified, and performs contract information verification on the contract information to be verified according to the contract information of the target smart contract, and performs signature verification and contract verification If the information is verified, it is determined that when the challenger initiates a call to the target smart contract through the oracle mechanism of the blockchain node, the target smart contract is used by any node in the second trusted Execution in the execution environment.
  • the second self-recommendation information carried in the cluster remote certification report includes a fourth hash value to be verified, and the fourth hash value to be verified is preset information of the second trusted execution environment
  • the fourth hash value to be verified is used by the challenger to verify the signature of the cluster remote certification report according to the public key of the authentication server and the signature verification is passed, and the cluster remote certification If the remote authentication result contained in the report is passed authentication, it is compared with the pre-obtained fourth standard hash value for the preset information in the second trusted execution environment, and the comparison result is consistent as the challenger A prerequisite for confirming that the second trusted execution environment is credible.
  • the sending unit 1603 is further configured to: enable any node to provide cluster identity information to the challenger, and the cluster identity information includes the cluster identity public key in the cluster identity key and the any node In the node identity information of any node other than the node identity public key of any node, the cluster identity information is hashed by the challenger to obtain the fifth hash value to be verified; A node provides a fifth standard hash value to the challenger, and the fifth standard hash value is generated by any node in the second trusted execution environment after the cluster identity information is generated for the cluster.
  • the identity information is obtained by hash calculation; the fifth standard hash value is used for comparison with the fifth hash value to be verified, and the challenger obtains the cluster identity information if the comparison result is consistent
  • the sending unit 1603 is further configured to: receive a call transaction initiated by the client to the target smart contract, the call transaction is encrypted with the cluster identity public key in the cluster identity key, and the The call transaction is received by the control node of the privacy computing cluster, and forwarded to any node according to the load of the privacy computing cluster; in the second trusted execution environment, the cluster identity key is used The cluster identity private key decrypts the call transaction to execute the target smart contract in response to the decrypted call transaction.
  • the device for sharing the cluster key may include: a report providing unit 1701 to enable any node in the privacy computing cluster to report to other nodes in the privacy computing cluster.
  • a first remote attestation report the first remote attestation report is generated by the authentication server after verifying the first self-recommendation information generated by any node for the first trusted execution environment created;
  • the receiving unit 1702 causes the Any node receives the cluster identity key corresponding to the privacy computing cluster and the second remote certification sent by the other node when the first trusted execution environment is determined to be credible according to the first remote certification report Report that the cluster identity key is generated in the second trusted execution environment created by the other nodes, and when the client interacts with each node in the privacy computing cluster to deploy or invoke smart contracts,
  • the cluster identity key is used to encrypt and decrypt interactive data and/or signature verification
  • the second remote attestation report is the second self-recommended information generated by the authentication server to the other nodes for the second trusted execution environment Generated after verification
  • the operation for any node to determine that the second trusted execution environment is trustworthy according to the second remote attestation report includes: signing the second remote attestation report according to the public key of the authentication server Verification; in the case where the signature verification is passed and the remote authentication result contained in the second remote attestation report is certified, extract the first to-be-inspected Ukraine from the second self-recommendation information carried in the second remote attestation report Hope value, the first hash value to be checked is the hash value of the preset information in the second trusted execution environment; the pre-obtained first hash value for the preset information in the second trusted execution environment The standard hash value is compared with the first hash value to be checked, and the comparison result is consistent as a prerequisite for confirming that the second trusted execution environment is trustworthy.
  • the report providing unit 1701 is further configured to: the any node provides first node identity information to the other nodes, and the first node identity information includes the node identity public key of the any node and the Other identity information of any node, the first identity information is hashed by the other node to obtain the second hash value to be verified; the any node provides the second standard hash to the other node Value, the second standard hash value is obtained by hashing the generated node identity information after any node generates its own node identity information in the first trusted execution environment; in the second When the standard hash value is consistent with the second hash value to be verified, the cluster identity key is signed by the other node using the node identity private key of the other node, and any one The node identity public key of the node encrypts the signed cluster identity key.
  • the report providing unit 1701 is further configured to: the any node obtains the second node identity information provided by the other node, and hashes the second node identity information to obtain the third to-be-verified Ha Hence, the second node identity information includes the node identity public key of the other node and other identity information of the other node; the any node obtains the third standard hash value provided by the other node, so The third standard hash value is obtained by hashing the generated node identity information after the other node generates its own node identity information in the second trusted execution environment; the any node is in the first trusted execution environment.
  • the node identity private key of any node is used to decrypt the received cluster identity key, and the other node’s
  • the node identity public key included in the node identity information verifies the signature of the cluster identity key, and maintains the cluster identity key in the first trusted execution environment if the signature verification is passed.
  • the processing unit 1703 is further configured to: in the case of receiving the target smart contract encrypted by the cluster identity public key in the cluster identity key, pass all the smart contracts in the first trusted execution environment.
  • the cluster identity private key in the cluster identity key decrypts and deploys the target smart contract; in the case where the client initiates a call to the target smart contract, executes all the smart contracts in the first trusted execution environment
  • the target smart contract is described, and the execution result is fed back to the client.
  • the report providing unit 1701 is further configured to: make any node respond to the challenge initiated by the deployer of the target smart contract, and report to the deployer The first remote attestation report is provided; wherein the encrypted target smart contract is sent by the deployer when it is determined that the first trusted execution environment is credible according to the first remote attestation report.
  • the processing unit 1703 is further configured to: make any node use the contract identity key of the target smart contract in the first trusted execution environment
  • the contract identity private key in the contract identity key signs the execution result
  • the signed execution result is when the contract identity public key in the contract identity key is used to sign the execution result and pass the signature verification. , Is determined to be generated by the target smart contract.
  • the operation of generating the contract identity key of the target smart contract by any node includes: generating a key shared between nodes in the privacy computing cluster in the first trusted execution environment The algorithm generates the contract identity key based on the cluster identity key and the global identification information of the target smart contract; wherein the target smart contract is deployed at each node in the privacy computing cluster.
  • the processing unit 1703 is further configured to: any node provides the cluster remote attestation report to the challenger of the target smart contract, and The cluster remote certification report is generated after the authentication server verifies the first self-recommendation information; the challenger is provided with the contract information to be verified of the target smart contract deployed at any node, and the contract to be verified The information is signed by any node in the first trusted execution environment using the cluster identity private key in the cluster identity key; the contract information to be verified is used by the challenger in the cluster remote
  • the certification report determines that the first trusted execution environment is credible
  • the cluster identity public key in the cluster identity key is used to perform signature verification on the contract information to be verified, and according to the contract of the target smart contract
  • the information performs contract information verification on the contract information to be verified, and when the signature verification and contract information verification are passed, it is determined that when the challenger initiates a call to the target smart contract through the oracle mechanism of the blockchain node ,
  • the cluster remote certification report is generated after the authentication server verifies the
  • the first self-recommendation information carried in the cluster remote certification report includes a fourth hash value to be verified, and the fourth hash value to be verified is preset information of the first trusted execution environment
  • the fourth hash value to be verified is used by the challenger to verify the signature of the cluster remote certification report according to the public key of the authentication server and the signature verification is passed, and the cluster remote certification If the remote authentication result contained in the report is passed authentication, it is compared with the pre-obtained fourth standard hash value for the preset information in the first trusted execution environment, and the comparison result is consistent as the challenger A prerequisite for confirming that the first trusted execution environment is credible.
  • the processing unit 1703 is further configured to: the any node provides cluster identity information to the challenger, and the cluster identity information includes the cluster identity public key in the cluster identity key and the identity of the any node In the node identity information, other identity information except the node identity public key of any node, the cluster identity information is hashed by the challenger to obtain the fifth hash value to be verified; The node provides a fifth standard hash value to the challenger, and the fifth standard hash value is determined by any node after the cluster identity information is generated in the first trusted execution environment. Information is obtained by hash calculation; the fifth standard hash value is used to compare with the fifth hash value to be verified, and the challenger obtains the cluster identity information when the comparison result is consistent The cluster identity public key included.
  • the processing unit 1703 is further configured to: receive a call transaction initiated by the client to the target smart contract, where the call transaction is encrypted using the cluster identity public key in the cluster identity key, and the The invocation transaction is received by the control node of the privacy computing cluster, and forwarded to any node according to the load of the privacy computing cluster; in the first trusted execution environment, the cluster identity key is used The cluster identity private key decrypts the call transaction to execute the target smart contract in response to the decrypted call transaction.
  • a typical implementation device is a computer.
  • the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.
  • this specification can be provided as a method, a system, or a computer program product. Therefore, this specification may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • This specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network.
  • program modules can be located in local and remote computer storage media including storage devices.
  • These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device.
  • the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment.
  • the instructions provide steps for implementing the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and 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”.

Abstract

本说明书提供一种共享集群密钥的方法及装置，该方法包括：链下隐私计算集群中的任一节点获取其他节点发送的对应于第一链下可信执行环境的第一远程证明报告；获取在任一节点的第二链下可信执行环境内生成的集群身份密钥，在区块链节点与各节点进行交互以部署或调用链下合约的过程中，集群身份密钥用于对交互数据进行加密解密和/或签名验签；在根据第一远程证明报告确定第一链下可信执行环境可信的情况下，向其他节点发送集群身份密钥和第二远程证明报告，在第二远程证明报告表明第二链下可信执行环境可信的情况下，集群身份密钥被其他节点认可。上述共享密钥的过程可确保数据安全，从而后续各节点可通过集群身份密钥进行隐私保护。

Description

共享集群密钥的方法及装置 技术领域
本说明书一个或多个实施例涉及可验证计算技术领域，尤其涉及一种共享集群密钥的方法及装置。
背景技术
针对各种场景下的隐私需求，一种方式是通过同态加密(Homomorphic encryption)和零知识证明(Zero-knowledge proof)等加密技术实现隐私保护，但也随之带来了严重的性能损失。可信执行环境(Trusted Execution Environment,TEE)是另一种解决方式。TEE可以起到硬件中的黑箱作用，在TEE中执行的代码和数据操作系统层都无法偷窥，只有代码中预先定义的接口才能对其进行操作。在效率方面，由于TEE的黑箱性质，在TEE中进行运算的是明文数据，而不是同态加密中的复杂密码学运算，计算过程效率没有损失。
发明内容
有鉴于此，本说明书一个或多个实施例提供一种共享集群密钥的方法及装置，能够在链下环境内安全实现共享集群密钥的操作。
根据本说明书一个或多个实施例的第一方面，提出了一种共享集群密钥的方法，包括：链下隐私计算集群中的任一节点获取所述链下隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；所述任一节点获取对应于所述链下隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签；所述任一节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，所述集群身份密钥在根据所述第二远程证明报告确定所述第二链下可信执行环境可信的情况下，被维护在所述第一链下可信执行环境内，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成。
根据本说明书一个或多个实施例的第二方面，提出了一种共享集群密钥的方法，包括：链下隐私计算集群中的任一节点向所述链下隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下发送的对应于所述链下隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成；所述任一节点在根据所述第二远程证明报告确定所述第二链下可信执行环境可信的情况下，在所述第一链下可信执行环境内维护所述集群身份密钥。
根据本说明书一个或多个实施例的第三方面，提出了一种共享集群密钥的方法，包括：隐私计算集群中的任一节点获取所述隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一可信执行环境产生的第一自荐信息进行验证后生成；所述任一节点获取对应于所述隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二可信执行环境内生成，在客户端与所述隐私计算集群中的各节点进行交互以部署或调用智能合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签；所述任一节点在根据所述 第一远程证明报告确定所述第一可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，在所述第二远程证明报告表明所述第二可信执行环境可信的情况下，所述集群身份密钥被所述其他节点认可，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二可信执行环境产生的第二自荐信息进行验证后生成。
根据本说明书一个或多个实施例的第四方面，提出了一种共享集群密钥的方法，包括：隐私计算集群中的任一节点向所述隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一可信执行环境产生的第一自荐信息进行验证后生成；所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下发送的对应于所述隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二可信执行环境内生成，在客户端与所述隐私计算集群中的各节点进行交互以部署或调用智能合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二可信执行环境产生的第二自荐信息进行验证后生成；所述任一节点在确定出所述第二远程证明报告表明所述第二可信执行环境可信的情况下认可所述集群身份密钥。
根据本说明书一个或多个实施例的第五方面，提出了一种共享集群密钥的装置，包括：报告获取单元，使链下隐私计算集群中的任一节点获取所述链下隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；密钥获取单元，使所述任一节点获取对应于所述链下隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签；发送单元，使所述任一节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，所述集群身份密钥在根据所述第二远程证明报告确定所述第二链下可信执行环境可信的情况下，被维护在所述第一链下可信执行环境内，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成。
根据本说明书一个或多个实施例的第六方面，提出了一种共享集群密钥的装置，包括：报告提供单元，使链下隐私计算集群中的任一节点向所述链下隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；接收单元，使所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下发送的对应于所述链下隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成；处理单元，使所述任一节点在根据所述第二远程证明报告确定所述第二链下可信执行环境可信的情况下，在所述第一链下可信执行环境内维护所述集群身份密钥。
根据本说明书一个或多个实施例的第七方面，提出了一种共享集群密钥的装置，包括：报告获取单元，使链下隐私计算集群中的任一节点获取所述链下隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；密钥获取单 元，使所述任一节点获取对应于所述链下隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二链下可信执行环境内生成，在客户端与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签；发送单元，使所述任一节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，所述集群身份密钥在根据所述第二远程证明报告确定所述第二链下可信执行环境可信的情况下，被维护在所述第一链下可信执行环境内，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成。
根据本说明书一个或多个实施例的第八方面，提出了一种共享集群密钥的装置，包括：报告提供单元，使链下隐私计算集群中的任一节点向所述链下隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；接收单元，使所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下发送的对应于所述链下隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二链下可信执行环境内生成，在客户端与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成；处理单元，使所述任一节点在根据所述第二远程证明报告确定所述第二链下可信执行环境可信的情况下，在所述第一链下可信执行环境内维护所述集群身份密钥。
根据本说明书一个或多个实施例的第九方面，提出了一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器通过运行所述可执行指令以实现如第一方面、第二方面、第三方面或第四方面所述的方法。
根据本说明书一个或多个实施例的第十方面，提出了一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如第一方面、第二方面、第三方面或第四方面的步骤。
综上所述，本说明书通过在链下隐私计算节点上实现链下可信执行环境，使得链下隐私计算节点可以提供安全可靠的运行环境，并且该链下可信执行环境的可靠性可以通过远程证明予以验证，从而能够安全可靠地生成集群密钥，并在集群内的节点之间实现共享。
附图说明
图1是一示例性实施例提供的一种共享集群密钥的方法的流程图。
图2是一示例性实施例提供的一种链下隐私计算节点之间形成集群身份的示意图。
图3是一示例性实施例提供的一种实现远程证明的场景示意图。
图4是一示例性实施例提供的另一种实现远程证明的场景示意图。
图5是一示例性实施例提供的一种部署链下合约的场景示意图。
图6是一示例性实施例提供的另一种部署链下合约的场景示意图。
图7是一示例性实施例提供的一种验证链下合约的示意图。
图8是一示例性实施例提供的另一种验证链下合约的示意图。
图9是一示例性实施例提供的一种调用链下合约的场景示意图。
图10-12是一示例性实施例提供的另一种共享集群密钥的方法的流程图。
图13是一示例性实施例提供的一种设备的结构示意图。
图14是一示例性实施例提供的一种共享集群密钥的装置的框图。
图15-17是一示例性实施例提供的另一种共享集群密钥的装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
区块链一般被划分为三种类型：公有链(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)技术证明上述的计算结果确实是在可信执行环境内按照预期执行，从而在确保可靠性的同时，极大地降低了链上的资源消耗。
如前所述，通过在区块链节点部署智能合约，使得区块链节点可以执行该智能合约的代码以实现相应的计算需求；类似地，可以将用于执行计算任务的代码部署在链下隐私计算节点处，使得链下隐私计算节点可以执行代码以实现相应的计算需求。为了便于理解，本说明书中将部署于区块链节点的合约称为链上合约、将部署于链下隐私计算节点的合约称为链下合约；当然，无论是链上合约还是链下合约，其本质都是一段可以在虚拟机内执行的代码。
与上述区块链节点类似，可在链下隐私计算节点上创建链下TEE(即链下可信执行环境)，该链下TEE基于CPU硬件实现的与外部完全隔离的可信执行环境。链下隐私计算节点通过创建链下TEE，可以通过该链下TEE实现对链下合约的部署操作以及部署后的调用执行操作，并确保操作过程中的数据安全和隐私保护。举例而言，可在链下隐私计算节点上部署链下合约，并在该链下隐私计算节点创建的链下TEE内部署WASM虚拟机。那么当用户向链下隐私计算节点发起一基于WASM程序的计算任务时，链下隐私计算节点可将链下合约读入链下TEE内并编译成WASM字节码，以WASM虚拟机作为执行引擎，将编译得到的WASM字节码在WASM虚拟机中执行。
可配置单节点形式的链下隐私计算节点来执行计算任务；或者，可通过链下隐私计算集群的形式向用户提供高并发和高可用的隐私计算服务，从而解决节点的负载均衡、故障转移、动态扩展缩容等问题。其中，该链下隐私计算集群可以包含一控制节点和多个链下隐私计算节点，各节点用于部署相同的链下合约(至少一个)以执行计算任务，并由该控制节点对集群内的所有链下隐私计算节点进行统一管理。下面对控制节点管理链下隐私计算节点请求加入集群的过程进行说明。
当任一链下隐私计算节点请求加入链下隐私计算集群时，控制节点可以向该节点发起挑战，并接收该节点返回的远程证明报告。远程证明报告产生于针对链下隐私计算节点上的链下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服务器可以对签名进行验证，并向链下隐私计算节点返回相应的远程证明报告。
控制节点在获得链下隐私计算节点的远程证明报告之后，可以根据该远程证明报告来验证相应的链下隐私计算节点是否可信，具体指验证该链下隐私计算节点上部署的链下TEE是否可信，并在确定链下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一致”作为确认链下TEE可信的前提条件；换言之，如果待检验MREnclave与可信MREnclave不一致，或者待检验MRSigner与可信MRSigner不一致，控制节点就判定该链下隐私计算节点的链下TEE不可信，而如果控制节点设定的所有前提条件都被满足，就可以确认该链下隐私计算节点的链下TEE可信。此外，控制节点对于签名验证结果进行验证的操作，与针对待检验MREnclave和待检验MRSigner进行验证的操作之间，并不存在必然的先后顺序，两者之间可以完全独立。
除了MREnclave和MRSigner之外，控制节点还可以通过其他的前提条件对链下隐私计算节点的可信度进行验证。例如，链下隐私计算节点在创建链下TEE后，可以在链下TEE内生成代表自身的身份信息的密钥对，并且链下隐私计算节点在链下TEE中创建自身的节点身份信息，该节点身份信息与上述对应于身份信息的密钥对相关，比如该节点身份信息可以包含该密钥对中的公钥(即节点身份公钥)。其中，代表身份信息的密钥对可以存在一组或多组，比如一组密钥对为用于签名与验签的密钥对(即签名密钥对)，一组密钥对为用于加密与解密的密钥对(即加密密钥对)，则节点身份信息可以包括签名密钥对中的签名公钥和加密密钥对中的加密公钥。在一组密钥对中，对应于不同的加密算法，可能同时存在多个公钥，这些公钥均被包含于上述的节点身份信息中。此外，节点身份信息还可以包含其他与链下隐私计算节点相关的信息(即其他身份信息)，比如软件版本、所在域名、所在分区名等，本说明书并不对此进行限制。那么，链下隐私计算节点在自身的链下TEE内生成节点身份信息(比如在链下TEE初始化时生成)后，可对生成的节点身份信息进行哈希计算得到第二标准哈希值。而链下隐私计算节点在生成结构体QUOTE时，可以将该第二标准哈希值添加至结构体QUOTE中。
相应的，控制节点在收到远程证明报告后，可以从该远程证明报告进行签名验证。在签名验证通过的情况下，控制节点可以提取远程证明报告所含的签名验证结果和第二标准哈希值，并验证签名验证结果，以及利用第二标准哈希值验证链下隐私计算节点的节点身份信息是否正确，且两验证步骤之间并不存在必然的先后顺序，两者之间可以完全独立。假定控制节点首先验证签名验证结果，并在签名验证结果为通过验证的情况下， 继续利用第二标准哈希值对链下隐私计算节点的节点身份信息进行验证。为了对链下隐私计算节点的节点身份信息进行验证，控制节点需要获取链下隐私计算节点的节点身份信息，比如远程证明报告被提供至控制节点的同时，可以关联提供节点身份信息，当然控制节点也可以通过其他方式或在其他时刻获得该节点身份信息。然后，控制节点可以对获得的节点身份信息进行哈希计算得到第二待校验哈希值，将计算得到的第二待校验哈希值与上述的第二标准哈希值进行比较，并将比较结果一致作为确认链下隐私计算节点可信的前提条件。如果第二待检验哈希值通过验证，可以证明获得的节点身份信息正是链下隐私计算节点在自身的链下TEE内生成的节点身份信息。那么，上述代表身份信息的密钥对中的私钥仅由链下隐私计算节点所拥有，且该链下隐私计算节点能够完成签名、加密通讯等操作。
以上列举了两种针对链下隐私计算节点进行验证时采用的判断条件，即针对第一待检验哈希值的验证、针对节点身份信息的验证。还可以采用其他的判断条件，此处不再一一列举。在针对链下隐私计算节点进行可信验证时，可以选用上述的一个或多个判断条件。例如，可以同时针对第一待检验哈希值和节点身份信息进行验证；或者，在一些情况下，可以仅验证节点身份信息，而对第一待检验哈希值可以不验证或者部分验证。例如，控制节点上可以设置信任等级，并根据信任等级确定是否验证或部分验证第一待检验哈希值，比如信任等级为0时，不需要验证第一待检验哈希值，信任等级为1时，验证第一待检验哈希值中的MRSigner，信任等级为2时，验证第一待检验哈希值中的MREnclave等。
在上述实施例中，节点身份信息包含了链下隐私计算节点的身份相关的信息，比如代表节点身份的节点身份公钥等。节点身份信息还可以包含与链下TEE相关的信息，那么链下隐私计算节点在自身的链下TEE内生成节点身份信息后，对生成的节点身份信息进行哈希计算得到哈希值，并将该哈希值添加至结构体QUOTE时，该哈希值相当于同时实现了上述第一待检验哈希值和第二标准哈希值的作用。例如，节点身份信息除了包含签名公钥和加密公钥等信息之外，还可以包含MREnclave和MRSigner的值，使得对该节点身份信息进行哈希计算得到的哈希值，同时与链下隐私计算节点的身份、链下TEE相关。相应的，控制节点在收到远程证明报告后，可以从该远程证明报告进行签名验证。在签名验证通过的情况下，控制节点可以提取远程证明报告所含的签名验证结果和该哈希值，并验证签名验证结果，以及利用该哈希值验证链下隐私计算节点的节点身份信息是否正确，且两验证步骤之间并不存在必然的先后顺序，两者之间可以完全独立。假定控制节点首先验证签名验证结果，并在签名验证结果为通过验证的情况下，继续利用该哈希值对链下隐私计算节点的节点身份信息进行验证。为了对链下隐私计算节点的节点身份信息进行验证，控制节点需要获取链下隐私计算节点的节点身份信息，此处不再赘述。然后，控制节点可以对获得的节点身份信息进行哈希计算得到待校验哈希值，将计算得到的待校验哈希值与上述远程证明报告所含的哈希值进行比较，并将比较结果一致作为确认链下隐私计算节点可信的前提条件。可见，本实施例仅需一次比较，即可实现前文中两方面的验证，有助于提升验证效率。
需要说明的是，控制节点对远程证明报告的验证过程，还可以包括其他操作，比如根据远程证明报告的内容确定链下TEE是否运行于测试模式(测试模式下存在数据泄露的风险)等，此处不再一一赘述。
基于上述验证链下隐私计算节点的方式，控制节点可将验证通过的节点加入链下隐私计算集群，从而建立一包含多个链下隐私计算节点的链下隐私计算集群。而在完成对链下隐私计算集群的建立后，需要为这些链下隐私计算节点生成统一的身份信息，比如称为集群身份密钥。集群身份密钥可以包括集群加密密钥对和集群签名密钥对，上述的各个链下隐私计算节点均需在各自的链下TEE内维护集群加密私钥、集群签名私钥。通过为链下隐私计算集群中的各个节点生成统一的身份信息，与链下隐私计算集群对接 的外部对象并不需要关注对方为单个链下隐私计算节点或者链下隐私计算集群，只需要将其作为一个对象并与该对象进行交互即可，无需关注于背后的节点或集群的细节。
图1是一示例性实施例提供的一种共享集群密钥的方法的流程图。如图1所示，该方法可以包括步骤102～步骤106。
步骤102，链下隐私计算集群中的任一节点获取所述链下隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成。
在本实施例中，针对所述其他节点的第一远程证明报告和产生的第一自荐信息，可参考前述内容中的解释，在此不再赘述。而在获取第一远程证明报告后，所述任一节点可根据第一远程证明报告确定所述其他节点创建的第一链下可信执行环境是否可信。具体而言，可根据认证服务器的公钥对第一远程证明报告进行签名验证，并在签名验证通过且第一远程证明报告包含的远程认证结果为通过认证的情况下，从第一远程证明报告携带的第一自荐信息内提取出第一待检验哈希值，该第一待检验哈希值为第一链下可信执行环境中预设信息的哈希值。在提取出第一待检验哈希值后，将预先获得的针对所述预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第一链下可信执行环境可信的前提条件。类似的，确定第一链下可信执行环境是否可信的操作的具体过程，可参考上述控制节点确定待加入接点的链下可信执行环境是否可信的过程，在此不再赘述。
步骤104，所述任一节点获取对应于所述链下隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签。
在本实施例中，在需要生成集群身份时，控制节点可以将某一链下隐私计算节点选取为主节点、其他的链下隐私计算节点为从节点，由主节点生成代表集群身份的密钥对(集群身份密钥)，并进而将该密钥对分享至各个从节点，最终使得所有链下隐私计算节点都维护了统一的、代表集群身份的密钥对。例如，在链下隐私计算集群内的各个节点均已生成自身的节点身份信息之后，控制节点选取上述步骤104中的“任一节点”作为主节点，在自身创建的链下TEE内生成对应于链下隐私计算集群的集群身份密钥，进而在需要向其他节点共享集群身份密钥时，获取生成的集群身份密钥实施共享操作。
步骤106，所述任一节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，在所述第二远程证明报告表明所述第二链下可信执行环境可信的情况下，所述集群身份密钥被所述其他节点认可，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成。
在本实施例中，所述其他节点在确定出第二远程证明报告表明第二链下可信执行环境可信的情况下认可集群身份密钥，从而在自身的第一链下可信执行环境内维护集群身份密钥。
而所述任一节点在向所述其他节点发送所述集群身份密钥之前，可先对所述其他节点的第一节点身份信息进行验证。进一步的，由于第一节点身份信息中包含所述其他节点的节点身份公钥，可在验证通过的情况下获取第一节点身份信息中包含的节点身份公钥以对集群身份密钥进行加密，使得只有所述其他节点通过自身的节点身份私钥才可对集群身份密钥进行解密，从而保证了所述任一节点向所述其他节点共享集群身份密钥的安全性。具体而言，所述任一节点可获取所述其他节点提供的第一节点身份信息(比如，所述其他节点可将第一节点身份信息与第一远程证明报告关联发送至所述任一节点)，并对获取到的第一节点身份信息进行哈希计算以得到第二待校验哈希值，所述第一节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息。同 时，所述任一节点获取所述其他节点提供的第二标准哈希值(比如，第二标准哈希值可包含在第一远程证明报告中)，所述第二标准哈希值由所述其他节点在所述第一链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到。进一步的，所述任一节点将第二待校验哈希值与第二标准哈希值进行比较，并在比较结果一致的情况下获取所述其他节点的节点身份信息中包含的节点身份公钥，从而采用所述任一节点的节点身份私钥对所述集群身份密钥进行签名，并采用所述其他节点的节点身份公钥对签名后的集群身份密钥进行加密。所述任一节点在向所述其他节点共享加密后的集群身份密钥时，将自身的第二远程证明报告与加密后的集群身份密钥关联发送至所述其他节点以证明身份。那么，所述其他节点在根据第二远程证明报告确定所述任一节点创建的第二链下可信执行环境可信的情况下，采用所述其他节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述任一节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一链下可信执行环境内维护所述集群身份密钥。
而针对获取所述任一节点的节点身份公钥的方式，与所述任一节点获取所述其他节点的节点身份公钥的方式类似。具体而言，所述任一节点可向所述其他节点提供第二节点身份信息(比如，所述任一节点可将第二节点身份信息与第二远程证明报告关联发送至所述其他节点)，第二节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息。同时，所述任一节点向所述其他节点提供第三标准哈希值(比如，第三标准哈希值可包含在第二远程证明报告中)，所述第三标准哈希值由所述任一节点在所述第二链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到。那么，所述其他节点在对第二节点身份信息进行哈希计算得到的第三待校验哈希值与第三标准哈希值一致的情况下，采用所述其他节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述任一节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一链下可信执行环境内维护所述集群身份密钥。
由此可见，所述任一节点在向所述其他节点共享集群身份密钥之前，需对所述其他节点进行验证，而所述其他节点在接收到所述任一节点共享的集群身份密钥之后，同样也需要对所述任一节点进行验证，从而保证共享集群身份密钥的安全性。
如图2所示，假定链下隐私计算集群中包括节点20、节点21、节点22等若干链下隐私计算节点，需要在这些节点之间建立统一的集群身份。首先，每个链下隐私计算节点分别创建链下TEE，并分别在各自的链下TEE内创建节点身份，比如节点20创建了TEE1，并在TEE1内创建了代表自身节点身份的密钥对Key-0，节点21创建了TEE2，并在TEE1内创建了代表自身节点身份的密钥对Key-1、节点22创建了TEE3，并在TEE1内创建了代表自身节点身份的密钥对Key-2等。各个链下隐私计算节点加入集群的时机往往不同，因而创建链下TEE和节点身份的时机也不同。通常，节点需要向链下隐私集群的控制节点发起申请，而控制节点会向发出申请的节点发起挑战，以验证该节点的硬件环境、链下TEE内运行的软件等，并在验证通过后将该节点加入链下隐私计算集群，使得该节点成为链下隐私计算节点。
在需要生成集群身份时，控制节点可以将某一链下隐私计算节点选取为主节点、其他的链下隐私计算节点为从节点，由主节点生成代表集群身份的密钥对，并进而将该密钥对分享至各个从节点，最终使得所有链下隐私计算节点都维护了统一的、代表集群身份的密钥对。如图2所示，假定节点20被选取为主节点、节点21-22等为从节点。首先，节点20在TEE1内生成代表集群身份的密钥对，即集群身份密钥对C-Key。然后，节点20分别向各个从节点发起挑战，使得节点21、节点22等从节点分别生成远程证明报告，该过程可以参考前文所述，此处不再赘述。在远程证明报告内可以包含MREnclave、MRSigner、节点身份信息的哈希值等信息。节点20分别接收各个从节点返回的远程证 明报告和节点身份信息，并通过如前文所述的方式进行验证，以确定各个从节点是否可信。
以节点21为例，假定节点20通过远程证明的方式确定该节点21可信。在上述代表节点20身份的密钥对Key-0中，譬如包含一组签名密钥对Key-0-S和一组加密密钥对Key-0-T，节点20可以采用签名密钥对Key-0-S中的签名私钥对上述的集群身份密钥对C-Key进行签名。同时，在节点21向节点20提供的节点身份信息中，包含代表节点21身份的密钥对Key-1中的公钥，比如签名密钥对Key-1-S中的签名公钥、加密密钥对Key-1-T中的加密公钥。因此，节点20可以采用加密密钥对Key-1-T中的加密公钥，对上述的集群身份密钥对C-Key及其签名数据进行加密，得到加密后密钥对，并发送至节点21。
节点20也基于前文所述的方式，触发获得针对自身创建的TEE1而生成的远程证明报告，而节点20除了向节点21发送上述的加密后密钥对之外，还将该远程证明报告以及节点20自身的节点身份信息发送至节点21，以供节点21对该节点20进行验证。而节点21在验证确定节点20可信的情况下，通过自身维护的加密密钥对Key-1-T中的加密私钥对收到的加密后密钥对进行解密，得到集群身份密钥对C-Key及其签名数据；以及，节点21从节点20的节点身份信息中提取出签名密钥对Key-0-S中的签名公钥，并针对上述解密得到的签名数据进行验证，如果签名验证成功，则节点21认定解密得到的集群身份密钥对C-Key有效，确定该密钥对C-Key可以代表链下隐私计算集群的集群身份。类似地，通过上述方式，主节点可以将集群身份密钥对C-Key共享至各个从节点，最终使得链下隐私计算集群中的所有链下隐私计算节点均获得该集群身份密钥对C-Key。
无论是针对单节点形式的链下隐私计算节点，还是链下隐私计算集群的形式，链下合约的部署方均可在链下隐私计算节点中部署链下合约，以供后续调用执行计算任务。
部署方的客户端可以向链下隐私计算节点发起挑战，并接收链下隐私计算节点返回的远程证明报告。例如，客户端可以向链下隐私计算节点发起链下挑战，即发起挑战的过程与区块链网络无关，这样可以跳过区块链节点之间的共识过程、减少链上链下的交互操作，使得客户端向链下隐私计算节点的挑战具有更高的操作效率。再例如，客户端可以采用链上挑战的形式，比如客户端可以向区块链节点提交挑战交易，该挑战交易所含的挑战信息可由区块链节点通过预言机机制传输至链下隐私计算节点，且该挑战信息用于向链下隐私计算节点发起挑战。
以如图3所示的场景为例。一种情况下，客户端31可以通过链下渠道直接向链下隐私计算节点32发起挑战，即客户端31向链下隐私计算节点32发起链下挑战。另一种情况下，客户端31可以通过区块链网络33向链下隐私计算节点32发起挑战，即客户端31向链下隐私计算节点33发起链上挑战。链上挑战的发起过程可以包括三个步骤：步骤①，客户端31向区块链网络33提交一笔用于发起挑战的交易，比如称之为挑战交易，该挑战交易可由区块链网络33内的某一节点33n接收和执行；步骤②，节点33n调用预先部署的预言机智能合约(简称预言机合约)，该预言机合约可以将上述挑战交易所含的挑战信息传递至链下的预言机服务器34，比如预言机合约可以产生包含该挑战信息的事件，而预言机服务器34可以通过监听预言机合约产生的事件，从而获取上述的挑战信息；步骤③，预言机服务器34将挑战信息通过链下渠道发送至链下隐私计算节点32。
客户端31通过链上渠道向链下隐私计算节点32发起挑战时，涉及到区块链网络33与链下隐私计算节点32之间的数据交互，即链上、链下的数据交互，该数据交互过程可以由预言机合约与预言机服务器34通过上述的步骤②配合实现，该预言机合约与预言机服务器34之间的配合机制即为预言机机制。其中，客户端31向节点33n提交的交易应当直接或间接调用上述的预言机合约，以触发预言机机制。其中，如果将预言机 合约的合约地址填入该交易的to字段，表明该交易直接调用了预言机合约；如果将某一链上合约的合约地址填入该交易的to字段，且该链上合约调用了预言机合约，表明该交易间接调用了预言机合约。链上合约调用预言机合约，一种情况下可以是在链上合约的字节码中预先写入了预言机合约的合约地址，另一种情况下可以是将预言机合约的合约地址作为调用该链上合约时的入参，并将该入参填入上述交易的data字段。除了将挑战信息或其他数据从链上传递至链下，预言机机制还可以将数据从链下传递至链上，具体可由预言机服务器34将链下数据传递至预言机合约，然后由预言机合约将链下数据传递至数据需求方，比如这里的链下数据可以包括远程证明报告或者调用链下合约所产生的隐私计算结果等。在上述的预言机机制中，将数据从链上传递至链下可以视为“请求”过程，将数据从链下传递至链上可以视为“响应”过程，这两个过程通常成对出现。
无论是链下挑战或链上挑战，链下隐私计算节点在收到客户端发起的挑战后，均可以临时触发如前文所述的远程证明过程并产生相应的远程证明报告，然后将远程证明报告反馈至客户端。或者，链下隐私计算节点在收到客户端发起的挑战时，如果本地已经存在预先生成的远程证明报告，那么链下隐私计算节点将该远程证明报告提供至客户端，而无需临时触发远程证明过程。其中，链下隐私计算节点本地存在的远程证明报告，可以是该链下隐私计算节点响应于除客户端之外的其他挑战者的挑战而触发产生，比如该其他挑战者可以包括其他客户端、链下隐私计算节点所处的链下隐私计算集群中的控制节点、KMS服务器等，本说明书并不对此进行限制。因此，链下隐私计算节点在收到客户端发起的挑战后，可以首先查看本地是否存在先前生成的远程证明报告，如果存在则将该远程证明报告反馈至客户端，否则临时触发远程证明过程。其中，远程证明报告可以具有一定的时限性，比如30分钟或其他时长，超时的远程证明报告可以被客户端认定为失效，链下隐私计算节点也可以主动清除已失效的远程证明报告以避免反馈至客户端。
客户端向链下隐私计算节点发起挑战的过程中，或者链下隐私计算节点向客户端反馈远程证明报告的过程中，涉及到设备之间的数据交互。以图3所示的场景为例，所涉及的数据交互可以包括：客户端31与链下隐私计算节点32之间的数据交互(客户端31向链下隐私计算节点32发起链下挑战，链下隐私计算节点32向客户端31返回远程证明报告)、客户端31与节点33n之间的数据交互(客户端31向节点33n发送挑战交易、节点33n向客户端31返回远程证明报告)、节点33n与预言机服务器34之间的数据交互(预言机服务器34从节点33n读取挑战信息、预言机服务器34向节点33n反馈远程证明报告)、预言机服务器34与链下隐私计算节点32之间的数据交互(预言机服务器34向链下隐私计算节点32发送挑战信息、链下隐私计算节点32向预言机服务器34返回远程证明报告)等。在实现上述任一数据交互的过程中，数据发送方与数据接收方之间传输的数据存在泄漏的可能性，并且节点33n会将挑战交易上链导致该挑战交易被公开，因此可以通过对数据进行加密传输的方式，避免造成信息泄露。
以客户端31向节点33n提交挑战交易为例。通过挑战交易向链下隐私计算节点32发起链上挑战，使得节点33n可以将客户端31提交的挑战交易与其他节点进行共识后上链，对客户端31的挑战行为进行存证。但是，如果客户端31并不希望自己的挑战行为被其他用户随意获知，可以对挑战交易进行隐私保护。客户端31可以对挑战交易进行加密，而节点33n可以接收经过加密的挑战交易，这样可以确保传输过程中不会造成挑战交易的内容泄露。节点33n处可以部署链上TEE，并且节点33n可以将经过加密的挑战交易读入该链上TEE后，在链上TEE内解密，可以确保解密得到的挑战交易仅存在于链上TEE内、不会外泄。节点33n直接将经过加密的挑战交易上链，并且通过对加密数据的查看权限进行管理，可以限制能够查看挑战交易的用户，而其他用户直接查看区块链数据时仅能够获得加密后的挑战交易。实际上，节点33n可以确保需要隐私保护的数据仅在链上TEE内能够被解密为明文形式，一旦离开链上TEE均采用密文形式。
针对挑战交易的加密传输，可以采用对称加密或非对称加密的形式。当采用对称加密时，客户端31和节点33n分别维护有相同的对称密钥，比如该对称密钥可由客户端31与节点33n通过诸如DH(Diffie-Hellman)或ECDH(Elliptic Curve Diffie–Hellman)等算法协商得到，或者由KMS(Key Management Service，密钥管理服务)服务器分发至客户端31和节点33n，本说明书并不限制密钥来源。当密钥由KMS服务器分发时，KMS服务器可以通过远程证明的方式确定节点33n处的链上TEE可信，然后将密钥加密传输至该链上TEE内，远程证明的方式与客户端31对链下隐私计算节点32的远程证明过程类似，此处暂不赘述。那么，客户端31可以通过上述的对称密钥对挑战交易进行加密，而节点33n将对称密钥维护于链上TEE中，因而将经过加密的挑战交易读入链上TEE内，并通过该对称密钥执行解密操作得到上述的挑战交易。对称加密采用的加密算法，例如可以包括DES算法，3DES算法，TDEA算法，Blowfish算法，RC5算法，IDEA算法等。
当采用非对称加密时，节点33n维护有非对称密钥的私钥，比如称之为节点私钥，而客户端31可以获得该节点私钥对应的节点公钥。非对称密钥可由节点33n在链上TEE内生成，或者由KMS服务器分发至该节点33n，本说明书并不限制密钥来源。类似地，当密钥由KMS服务器分发时，KMS服务器可以通过远程证明的方式确定节点33n处的链上TEE可信，然后将密钥加密传输至该链上TEE内。那么，客户端31可以通过节点公钥对挑战交易进行加密，而节点33n将节点私钥维护于链上TEE中，因而将经过加密的挑战交易读入链上TEE内，并通过节点私钥执行解密操作得到上述的挑战交易。非对称加密采用的非对称加密算法，例如可以包括RSA、Elgamal、背包算法、Rabin、D-H、ECC(椭圆曲线加密算法)等。
针对挑战交易的加密传输，还可以采用对称加密与非对称加密相结合的形式。客户端31可以维护一对称密钥，比如该对称密钥可由客户端31随机生成，且客户端31可以获得上述非对称密钥中的公钥。客户端31可以通过对称密钥对挑战交易进行加密、得到加密后挑战交易，并通过非对称密钥加密该对称密钥、得到加密后密钥，然后客户端31同时将加密后挑战交易与加密后密钥传输至节点33n。相应的，节点33n将加密后挑战交易与加密后密钥读入链上TEE内，首先通过节点私钥对加密后密钥进行解密、得到对称密钥，然后通过对称密钥对加密后挑战交易进行解密。相比较而言，对称加密的加解密效率相对更高、但安全性相对较低，而非对称加密的加解密效率相对较低、但安全性相对更高，因此基于对称加密与非对称加密相结合的形式，可以兼顾加解密效率与安全性。
类似地，在其他数据交互的过程中，通过使得数据发送方与数据接收方之间维护相同的对称密钥，或者使得数据发送方维护有非对称密钥的公钥、数据接收方维护有非对称密钥的私钥，或者结合对称加密与非对称加密的形式，可以实现任意的数据发送方与数据接收方之间的数据加密传输，此处不再赘述。
链下隐私计算节点可能属于链下隐私计算集群，该链下隐私计算集群包含多个链下隐私计算节点。如果各个链下隐私计算节点之间完全独立，那么客户端与单个链下隐私计算节点之间的交互过程可以参考上文所述的实施例。而另一种方式下，链下隐私计算集群可以包含一控制节点，并由该控制节点对集群内的所有链下隐私计算节点进行统一管理。比如，客户端可以向控制节点发起挑战，并接收控制节点返回的上述链下隐私计算节点的远程证明报告。与前述实施例相类似的，客户端可以向控制节点发起链下挑战，或者客户端可以向区块链节点提交挑战交易，该挑战交易所含的挑战信息由区块链节点通过预言机机制传输至控制节点，使得控制节点向客户端返回链下隐私计算节点的远程证明报告。
以如图4所示的场景为例。一种情况下，客户端41可以通过链下渠道直接向控制节点42发起挑战，即客户端41向控制节点42发起链下挑战。另一种情况下，客户端 41可以通过区块链网络43向控制节点42发起挑战，即客户端41向控制节点42发起链上挑战。链上挑战的发起过程可以包括三个步骤：步骤①，客户端41向区块链网络43提交一笔用于发起挑战的交易，比如称之为挑战交易，该挑战交易可由区块链网络43内的某一节点43n接收和执行；步骤②，节点43n调用预先部署的预言机智能合约(简称预言机合约)，该预言机合约可以将上述挑战交易所含的挑战信息传递至链下的预言机服务器44，比如预言机合约可以产生包含该挑战信息的事件，而预言机服务器44可以通过监听预言机合约产生的事件，从而获取上述的挑战信息；步骤③，预言机服务器44将挑战信息通过链下渠道发送至控制节点42。
客户端41向控制节点42发起挑战时，可以将挑战目标设定为控制节点42所处集群内的某一链下隐私计算节点，比如链下隐私计算节点42n，那么控制节点42会根据收到的挑战，向客户端41返回链下隐私计算节点42n对应的远程证明报告。客户端41也可以不设定挑战目标，那么控制节点42收到挑战后，从链下隐私计算集群中进行选择，比如在选取了链下隐私计算节点42n的情况下，向客户端41返回该链下隐私计算节点42n对应的远程证明报告。
其中，控制节点42在收到客户端41发起的挑战后，可以将该挑战转发至链下隐私计算节点42n，使得链下隐私计算节点42n临时触发远程证明过程，以产生相应的远程证明报告，然后通过控制节点42反馈至客户端41。或者，控制节点42在收到客户端41发起的挑战后，可以将该挑战转发至链下隐私计算节点42n，而如果链下隐私计算节点42n上已经存在预先生成的远程证明报告，那么链下隐私计算节点42n将该远程证明报告返回控制节点42，由控制节点42提供至客户端41，而无需临时触发远程证明过程。或者，控制节点42在收到客户端41发起的挑战后，如果本地已经存在预先生成的对应于链下隐私计算节点42n的远程证明报告，那么链下隐私计算节点42n将该远程证明报告提供至客户端41，而无需向链下隐私计算节点42n转发挑战，也无需链下隐私计算节点42n因此临时触发远程证明过程。其中，链下隐私计算节点42n本地存在的远程证明报告，可以是该链下隐私计算节点42n响应于除客户端41之外的其他挑战者的挑战而触发产生，比如该其他挑战者可以包括其他客户端、控制节点42、KMS服务器等，本说明书并不对此进行限制。而链下隐私计算节点42n通过控制节点42将远程证明报告提供至上述的其他挑战者时，控制节点42可以对收到的远程证明报告进行缓存。因此，控制节点42在收到客户端41发起的挑战后，可以首先查看查看本地是否存在先前获得的远程证明报告，如果存在则将该远程证明报告反馈至客户端41，否则将挑战转发至链下隐私计算节点42n；以及，链下隐私计算节点42n在收到挑战后，可以首先查看查看本地是否存在先前获得的远程证明报告，如果存在则将该远程证明报告反馈至控制节点42，否则临时触发远程证明过程。其中，远程证明报告可以具有一定的时限性，比如40分钟或其他时长，超时的远程证明报告可以被客户端41认定为失效，控制节点42或链下隐私计算节点42n也可以主动清除已失效的远程证明报告以避免反馈至客户端41。
在图4所示的实施例中，客户端41与控制节点42之间、控制节点42与链下隐私计算节点42n之间、客户端41与节点43n之间、节点43n与预言机服务器44之间、预言机服务器44与控制节点42之间等，均可能产生数据交互。对于任意的数据交互过程，均可以采用如前文所述的加密数据传输方案，包括对称加密、非对称加密或两者结合的形式，此处不再赘述。
或者，针对链下隐私计算集群的情况，基于各个链下隐私计算节点在各自的链下TEE内均维护有集群身份密钥，可将链下隐私计算集群视为一个整体，由控制节点在选取响应客户端的节点，链下隐私计算集群中各节点在与外界设备(比如区块链节点、客户端等)进行交互的过程中，并非采用自身的节点身份密钥，而是采用集群身份密钥对交互数据进行加密与解密，或者生成与验证签名。其中，采用集群身份密钥进行加密与解密，或者生成与验证签名的方式与上述采用节点身份密钥的过程类似，在此不再赘述。
基于上述方案，部署方通过客户端在确定链下隐私计算节点可信的情况下，可以向链下隐私计算节点部署链下合约。链下合约与区块链节点所执行的链上合约类似，均可以为运行于虚拟机中的字节码，此处不再赘述。通过对链下合约的字节码进行加密传输，可以避免在传输过程中发生数据泄露或修改等，确保隐私性和安全性。
与前述的挑战过程相类似的，客户端可以通过链下途径将链下合约的字节码加密传输至链下隐私计算节点，即针对字节码的传输过程与区块链网络无关，这样可以跳过区块链节点之间的共识过程、减少链上链下的交互操作，使得字节码的传输效率更高。或者，客户端可以通过链上途径将链下合约的字节码加密传输至链下隐私计算节点，比如客户端生成链下合约部署交易，该链下合约部署交易中包含对字节码进行加密得到的字节码密文，客户端将链下合约部署交易加密后提交至区块链节点，加密后的链下合约部署交易可在区块链节点处创建的链上TEE内被解密、得到字节码密文，然后由区块链节点通过预言机机制将该字节码密文传输至链下隐私计算节点。
以如图5所示的场景为例。一种情况下，客户端51可以通过链下渠道直接向链下隐私计算节点52加密传输字节码，即客户端51向链下隐私计算节点52链下传输加密后的字节码密文。另一种情况下，客户端51可以通过区块链网络53向链下隐私计算节点52加密传输字节码，即客户端51向链下隐私计算节点52链上传输加密后的字节码密文。链上加密传输的过程可以包括三个步骤：步骤①，客户端51向区块链网络53提交一笔用于部署链下合约的交易，即链下合约部署交易，该链下合约部署交易可由区块链网络53内的某一节点53n接收和执行；步骤②，节点53n调用预言机合约，该预言机合约可以将上述链下合约部署交易所含的字节码传递至链下的预言机服务器55，比如预言机合约可以产生包含该字节码的事件，而预言机服务器55可以通过监听预言机合约产生的事件，从而获取上述的字节码；步骤③，预言机服务器55将字节码通过链下渠道发送至链下隐私计算节点52。
在链下加密传输的过程中，仅涉及到客户端51与链下隐私计算节点52之间的数据交互，可以采用如前文所述的对称加密、非对称加密或两者结合的加密传输方案，此处不再赘述。在链上加密传输的过程中，涉及到多个对象之间的数据交互，需要确保字节码始终处于加密状态。例如，在客户端51向节点53n提交链下合约部署交易时，可以通过如前文所述的对称加密、非对称加密或两者结合的加密传输方案对该链下合约部署交易进行加密传输，使得链下合约部署交易所含的字节码处于加密保护状态。其中，链下合约部署交易所含的字节码可能处于明文状态或密文状态。如果处于密文状态，表明客户端51对字节码进行加密后，将字节码密文添加至链下合约部署交易的data字段，并且客户端51应当确保该字节码密文仅最终环节的链下隐私计算节点52能够解密，而其他的节点53n、预言机服务器55等均无法解密，那么节点53n在自身创建的链上TEE内对链下合约部署交易进行解密后得到字节码密文后，预言机服务器55可以直接读取该字节码密文，然后由预言机服务器55将该字节码密文传输至链下隐私计算节点52。如果处于明文状态，表明客户端51直接将明文的字节码添加至链下合约部署交易的data字段，而该链下合约部署交易可以调用一链上合约，那么节点53n在链上TEE内对链下合约部署交易进行解密后得到明文的字节码后，可以通过链上TEE内部署的虚拟机执行上述链上合约，从而在链上TEE内将字节码加密为相应的字节码密文，并确保该字节码密文仅能够由链下隐私计算节点52能够解密，然后由预言机服务器55读取该字节码密文，并进而将该字节码密文传输至链下隐私计算节点52。
针对字节码进行加密时，可以采用对称加密、非对称加密或两者结合的方式，本说明书并不对此进行限制。当采用非对称加密或者对称加密与非对称加密结合的方式时，涉及到一组非对称密钥对，客户端51或节点53n需要获知该非对称密钥对的公钥，且该非对称密钥对的私钥需要由链下隐私计算节点52所维护，使得该链下隐私计算节点52可以基于该私钥对收到的字节码密文进行解密。例如，该非对称密钥对可以为前文所 述的、链下隐私计算节点52在链下TEE中产生的加密密钥对；相应地，链下隐私计算节点52在收到字节码密文后，将该字节码密文读入链下TEE中，并基于加密私钥对该字节码密文进行解密，从而得到明文的字节码。
链下隐私计算节点52在链下TEE中解密得到明文的字节码后，可以在链下TEE中对字节码进行重新加密后，存储至链下TEE之外的存储空间，比如链下隐私计算节点52的硬盘中，从而完成对链下合约的部署。此处，链下隐私计算节点52通常采用一对称密钥，通过对称加密的方式对字节码进行加密并存储，这样在后续调用该字节码时，相比于采用非对称加密的形式而言，可以更快地完成解密操作。该对称密钥可由链下隐私计算节点52在链下TEE中生成，或者由其他对象通过加密传输的方式分发至链下隐私计算节点52。例如，可由KMS服务器对链下隐私计算节点52发起挑战，并通过远程证明验证该链下隐私计算节点52可信的情况下，向该链下隐私计算节点52分发上述的对称密钥。链下隐私计算节点52可以将KMS服务器分发的对称密钥作为根密钥，并将基于该根密钥派生得到的衍生密钥应用于针对字节码的加密存储。再例如，基于Intel SGX技术，上述对称密钥可以为烧录于链下隐私计算节点52的CPU内e-fuses存储电路中的RSK(Root Seal Key)密钥，或者该RSK密钥派生得到的衍生密钥(即Seal Key)。当然，链下隐私计算节点52也可以采用非对称加密或者对称加密与非对称加密结合的方式，对字节码进行加密存储，本说明书并不对此进行限制。
除了在链下隐私计算节点52处安全存储链下合约的字节码之外，客户端51还可以向链下隐私计算节点52指明用于执行该字节码的执行引擎。例如，在链下隐私计算节点52处创建的链下TEE中，可以部署有若干执行引擎，比如EVM、WASM虚拟机等中的一个或多个，尤其是在同时部署了多种执行引擎的情况下，客户端51可以向链下隐私计算节点52发送与上述字节码相关联的执行引擎指定信息，该执行引擎指定信息向链下隐私计算节点52指示用于执行上述字节码的执行引擎，比如采用EVM还是WSAM虚拟机等。例如，可以将字节码与执行引擎指定信息打包加密后，一并传输至链下隐私计算节点52；也可以分别对字节码和执行引擎指定信息进行加密传输，此时执行引擎指定信息应当包含相应的字节码或者链下合约的信息，比如字节码的哈希值等，以便于据此确定执行引擎指定信息对应于哪个链下合约。相应的，链下隐私计算节点52在部署链下合约时，除了对字节码进行加密存储之外，还需标注出字节码所需采用的执行引擎的信息，从而在后续的调用过程中据此选用恰当的虚拟机，以作为处理相应字节码的执行引擎。
通过上述方式，客户端51可以向链下隐私计算节点52部署更多的链下合约；类似地，其他客户端也可以向链下隐私计算节点52部署链下合约。为了便于管理，以及便于后续对链下合约进行调用，链下隐私计算节点52可以为部署的链下合约生成相应的合约ID，链下合约与合约ID之间一一对应。例如，在完成针对链下合约的部署操作后，链下隐私计算节点52可以对该链下合约的字节码进行哈希运算，得到第一哈希值，并将该第一哈希值作为该链下合约的合约ID。当然，链下隐私计算节点52也可以通过其他方式生成合约ID，本说明书并不对此进行限制。
如果将上述的第一哈希值作为链下合约的合约ID，那么该第一哈希值还可以具有其他作用。在完成部署后，链下隐私计算节点52可以向客户端51反馈部署结果信息，该部署结果信息包含上述的第一哈希值，而客户端51还可以对自己发出的字节码进行哈希计算得到第二哈希值，并将第一哈希值与第二哈希值进行比较：如果两者一致，表明链下隐私计算节点52部署的字节码正确无误，没有在传输过程中被替换或者发生其他意外，客户端51可以确认链下合约在链下隐私计算节点52处部署成功；而如果两者不一致，客户端51可以认为链下合约部署失败，或者已部署的链下合约存在风险。客户端51可以将成功部署的链下合约标记为可信合约，将未成功部署的链下合约标记为不可信合约或不维护，从而在后续过程中仅针对可信合约进行调用。如果客户端51将 字节码通过链下途径传输至链下隐私计算节点52，那么链下隐私计算节点52同样通过链下途径将部署结果信息返回至客户端51；如果客户端51将字节码通过链上途径传输至链下隐私计算节点52，那么链下隐私计算节点52同样通过链上途径将部署结果信息反馈至客户端51。
当链下隐私计算节点属于链下隐私计算集群时，由控制节点对集群内的所有链下隐私计算节点进行统一管理，那么客户端在部署链上合约的过程中，首先将字节码加密传输至控制节点，然后由控制节点转发至集群内的一个或多个链下隐私计算节点，从而将链上合约的字节码部署至集群内的一个或多个链下隐私计算节点。如果部署至多个链下隐私计算节点，那么这些链下隐私计算节点可以同时向外提供针对同一链下合约的调用能力，从而实现并行的链下隐私计算，还可以在多个链下隐私计算节点之间实现负载均衡。
以如图6所示的场景为例。一种情况下，客户端61可以通过链下渠道直接向控制节点62发送字节码密文，即客户端61向控制节点62链下加密传输字节码，进而由控制节点62转发至集群内的一个或多个链下隐私计算节点。另一种情况下，客户端61可以通过区块链网络63向控制节点62加密传输字节码，即客户端61向控制节点62链上传输加密后的字节码密文。链上加密传输的过程可以包括三个步骤：步骤①，客户端61向区块链网络63提交一笔用于部署链下合约的交易，即链下合约部署交易，该链下合约部署交易可由区块链网络63内的某一节点63n接收和执行；步骤②，节点63n调用预言机合约，该预言机合约可以将上述链下合约部署交易所含的字节码传递至链下的预言机服务器64，比如预言机合约可以产生包含该字节码的事件，而预言机服务器64可以通过监听预言机合约产生的事件，从而获取上述的字节码；步骤③，预言机服务器64将字节码通过链下渠道发送至控制节点62，并进而由控制节点62转发至集群内的一个或多个链下隐私计算节点。
如果仅需部署至一个链下隐私计算节点，比如图6所示的链下隐私计算节点62n，那么与图5所示实施例相类似的，客户端61或节点63n在针对字节码进行加密时，只需要确保该链下隐私计算节点62n能够解密即可。例如，可以采用该链下隐私计算节点62n在链下TEE内生成的加密公钥对字节码进行加密，而链下隐私计算节点62n在收到字节码密文后，可以在链下TEE内通过加密私钥对该字节码密文进行解密，从而获得明文的字节码。同时，客户端61可以携带部署目标指示信息，控制节点62可以根据该部署目标指示信息确定相应的部署目标为链下隐私计算节点62n，从而将字节码密文准确转发至该链下隐私计算节点62n，而无需转发至集群内其他的链下隐私计算节点。如果客户端61并未携带部署目标指示信息，控制节点62可以将字节码密文转发至集群内的所有链下隐私计算节点，但只有链下隐私计算节点62n能够成功解密并完成部署。
如果需要部署至集群内的多个链下隐私计算节点，除了独立部署的方式之外，本说明书中还可以将链下合约同时向多个链下隐私计算节点进行安全部署。如前所述，每个链下隐私计算节点都存在各自的节点身份信息，且节点身份信息涉及到每个链下隐私计算节点在各自的链下TEE内创建的密钥对，比如加密密钥对和签名密钥对，或者兼顾加密与签名功能的密钥对。下面以加密密钥对和签名密钥对为例进行说明。基于各个链下隐私计算节点在各自的链下TEE内均维护有集群身份密钥，可将链下隐私计算集群视为一个整体，利用上述在各个节点共享的集群身份密钥将链下合约同时向多个链下隐私计算节点进行安全部署，从而确保多个链下隐私计算节点都能够顺利解密收到的字节码密文。其中，集群身份密钥可以包括集群加密密钥对和集群签名密钥对，经上述共享集群身份密钥的过程，各个链下隐私计算节点在各自的链下TEE内均维护有集群加密私钥、集群签名私钥，那么客户端61或节点63n只要使用集群加密公钥对字节码进行加密，即可确保上述的各个链下隐私计算节点均能够在各自的链下TEE内通过集群加密私钥进行解密，从而获得字节码并完成部署。当然，即便仅部署至单个链下隐私计 算节点，也可以采用上述的集群加密公钥对字节码进行加密，只要相应的链下隐私计算节点能够顺利解密即可。实际上，基于集群身份，客户端61并不需要关注对方为单个链下隐私计算节点或者链下隐私计算集群，只需要将其作为一个对象并与该对象进行交互即可，无需关注于背后的节点或集群的细节。
以图1实施例中的所述任一节点为例，部署方在向所述任一节点部署目标链下合约之前，可向所述任一节点发起挑战，那么所述任一节点可响应于部署方发起的挑战，向部署方提供自身的远程证明报告，即第二远程证明报告。其中，部署方可在根据第二远程证明报告确定第二链下可信执行环境(即所述任一节点创建的链下可信执行环境)可信的情况下发送加密后的目标链下合约。比如，可采用集群身份密钥中的集群身份公钥对目标链下合约的字节码进行加密，再将加密后的字节码发送至所述任一节点。所述任一节点在接收到被加密的目标链下合约后，在第二链下可信执行环境中通过集群身份密钥中的集群身份私钥解密目标链下合约并进行部署。而在完成对目标链下合约的部署之后，在区块链节点通过预言机机制对所述目标链下合约发起调用的情况下，所述任一节点可在第二链下可信执行环境中执行目标链下合约，并通过预言机机制将执行结果反馈至区块链节点。
此外，在前文所述的挑战过程中，如果需要将挑战发送至链下隐私计算节点，而非由控制节点直接反馈远程证明报告，那么也可以采用集群加密公钥对挑战信息进行加密，只要相应的链下隐私计算节点能够顺利解密即可。但是，如果希望控制节点直接反馈远程证明报告(预先获得的远程证明报告，或者由控制节点向链下隐私计算节点发起挑战而得到)，则应当采用控制节点的身份公钥对挑战信息进行加密，确保控制节点能够在自身创建的TEE内通过身份私钥实现解密。
在如图6所示的实施例中，客户端61可以发送执行引擎指定信息，使得部署了链下合约的链下隐私计算节点可以据此获知用于执行上述字节码的执行引擎，此处不再赘述，可以参考图5所示的实施例。另外，客户端61可以收到部署结果信息，该部署结果信息包含链下合约的哈希值，比如第一哈希值，使得客户端61可以将该第一哈希值与自己发出的字节码对应的第二哈希值进行比较，从而确定链下隐私计算节点是否成功部署了上述的链上合约，此处不再赘述，可以参考图5所示的实施例。如果链上合约被部署至多个链下隐私计算节点，控制节点62只需要确保所有链下隐私计算节点反馈的部署结果信息都一致，并将任意一个链下隐私计算节点反馈的部署结果信息传输至客户端61即可。
基于上述实施例，本说明书可以基于远程证明的方式对链下隐私计算节点的硬件安全性、链下TEE的软件正确性等方面进行有效验证，从而在验证链下隐私计算节点可信的情况下，将链下合约通过加密传输的方式安全部署至链下隐私计算节点，并且该链下合约仅在链下隐私计算节点创建的链下TEE内执行，具有极高的安全性，可以承担区块链节点分配的链下隐私计算任务，并确保该链下隐私技术任务安全、可靠、高效地执行。同时，由于计算任务在链下隐私计算节点上执行时，并不涉及到节点之间的共识机制，因而只需要在单个链下隐私计算节点上执行该计算任务即可，相比于受共识机制的限制而使得所有区块链节点都需要执行的链上合约而言，能够极大地节省执行计算任务所带来的资源消耗。
在本说明书的技术方案中，除了链下隐私计算节点可以存在统一的集群身份之外，可以为链下隐私计算节点上部署的链下合约生成合约身份。当集群内存在多个链下隐私计算节点时，每个链下隐私计算节点可以为自身已部署的链下合约建立合约身份，且不同链下隐私计算节点针对同一链下合约生成的合约身份相同。
以上述在各个节点处部署目标链下合约为例，当在链下隐私计算集群中的任一节点中部署目标链下合约时，该任一节点可针对目标链下合约生成合约身份密钥。作为一示例性实施例，该任一节点在创建的链下可信执行环境内采用链下隐私计算集群内各节 点之间共用的密钥生成算法，基于链下隐私计算集群内各节点的共用因子和目标链下合约的全局标识信息(隐私计算集群中各节点部署的链下合约相同，且各节点部署的同一链下合约的全局标识信息相同)，生成对应于目标链下合约的合约身份密钥。其中，目标链下合约在区块链节点通过预言机机制对部署于该任一节点的目标链下合约发起调用的情况下在该任一节点的链下可信执行环境内执行，且执行结果在该任一节点的链下可信执行环境内被采用合约身份密钥进行签名，经签名后的执行结果可通过预言机机制反馈至区块链节点。可见，各个链下隐私计算节点通过上述方式来为自身已部署的链下合约生成合约身份密钥，可以保证各个节点针对同一链下合约生成的合约身份密钥也相同。同时，相比于由任一节点来统一生成合约身份密钥再向其他节点共享的方式，合约身份密钥由各个节点自身生成的效率更高。需要说明的是，密钥生成算法可根据实际情况灵活选取，比如bcrypt算法、scrypt算法、PBKDF2等。
在一种情况下，共用因子可由控制节点生成，并由控制节点在各个节点加入集群时统一下发，那么加入集群的每个节点均可维护该共用因子。在另一种情况下，共用因子包括对应于隐私计算集群的集群身份密钥，该集群身份密钥用于在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，对交互数据进行加密解密和/或签名验签。
举例而言，合约身份密钥可以包括合约加密密钥对和合约签名密钥对；其中，合约身份公钥包含合约加密密钥对中的公钥和合约签名密钥对中的公钥，合约身份私钥包含合约加密密钥对中的私钥和合约签名密钥对中的私钥。那么，客户端或区块链节点除了采用集群身份公钥对调用请求进行加密之外，还可以采用合约加密公钥对调用请求内所含的入参数据的信息进行加密。链下隐私计算节点在收到针对某一链下合约的调用请求后，采用该链下合约对应的合约加密私钥对调用请求内加密后的入参数据的信息进行解密，从而确保入参数据的信息只能由被调用的链下合约所获得，而不会被其他链下合约获得。以及，在得到目标链下合约的执行结果后，链下隐私计算节点在通过预言机机制将执行结果反馈至区块链节点之前，在自身的链下可信执行环境内采用目标链下合约的合约身份私钥对执行结果进行签名，那么，签名后的执行结果在采用目标链下合约的合约身份公钥对执行结果进行签名验证且通过签名验证的情况下，被判定由目标链下合约生成。换言之，链下隐私计算节点可以通过被调用的链下合约的合约签名私钥对执行结果进行签名，而客户端或节点可以通过合约签名公钥进行验签，从而确定该执行结果确实是由被调用的链下合约所产生
链下隐私计算节点可以选取统一的集群身份密钥和链下合约的合约ID，并采用密钥衍生算法对集群身份密钥和合约ID进行衍生以得到相应的合约身份密钥，由于集群身份密钥相同、而不同链下合约的合约ID必然不同，因而可以确保：同一链下隐私计算节点上部署的不同链下合约存在不同的合约身份，而不同链下隐私计算节点上部署的同一链下合约存在相同的合约身份。相应地，控制节点在分配收到的调用请求时，只需要关注于集群内的各个链下隐私计算节点的空闲程度，并基于空闲程度进行任务分配，而无需关注其他信息。其中，密钥衍生算法可根据实际情况灵活选取，比如可以采用PBKDF2密钥衍生算法，当然本说明书并不对此进行限制。
基于上述实施例，本说明书可以基于远程证明的方式对链下隐私计算节点的硬件安全性、链下TEE的软件正确性等方面进行有效验证，从而在验证链下隐私计算节点可信的情况下，将链下合约通过加密传输的方式安全部署至链下隐私计算节点，并且该链下合约仅在链下隐私计算节点创建的链下TEE内执行，具有极高的安全性，可以承担区块链节点分配的链下隐私计算任务，并确保该链下隐私技术任务安全、可靠、高效地执行。同时，由于计算任务在链下隐私计算节点上执行时，并不涉及到节点之间的共识机制，因而只需要在单个链下隐私计算节点上执行该计算任务即可，相比于受共识机制的限制而使得所有区块链节点都需要执行的链上合约而言，能够极大地节省执行计算 任务所带来的资源消耗。
基于本说明书的链下合约部署方案，区块链节点可以将计算任务分配至链下隐私计算节点，并调用链下隐私计算节点上部署的链下合约，通过在链下隐私计算节点创建的链下TEE内执行该链下合约，以完成上述的计算任务。通过远程证明、加密传输、基于签名的身份验证等技术，可以确保链下隐私计算节点得到的计算结果可靠，并且在计算过程中不会造成数据泄露，具有极高的安全性。在计算完成后，区块链节点可以根据计算结果对区块链账本数据进行更新，可以对计算结果进行固化存证，而且可以支持针对该计算结果的后期验证。同时，相比于区块链节点在执行链上合约后所产生的上链数据而言，基于链下合约产生的计算结果本身相对更加简短，因而将该计算结果上链时，有助于节省链上存储空间。
用户通过客户端调用目标链下合约之前，可对链下隐私计算节点中部署的目标链下合约发起挑战，以确保链下隐私计算节点中部署的目标链下合约可信，进而按照用户预期执行计算任务。下面结合图7-8分别针对单节点形式和集群形式的挑战过程进行说明。
如图7所示，针对单节点的形式，与图3所示实施例类似，客户端71可向链下隐私计算节点72发起链下挑战或者链上挑战。链上挑战的发起过程可以包括三个步骤：步骤①，客户端71向区块链网络73提交一笔用于向目标链下合约发起挑战的交易，比如称之为挑战交易，该挑战交易可由区块链网络73内的某一节点73n接收和执行；步骤②，节点73n调用预先部署的预言机合约，该预言机合约可以将上述挑战交易所含的挑战信息传递至链下的预言机服务器74，比如预言机合约可以产生包含该挑战信息的事件，而预言机服务器74可以通过监听预言机合约产生的事件，从而获取上述的挑战信息；步骤③，预言机服务器74将挑战信息通过链下渠道发送至控制节点72。
通过对链下隐私计算节点72部署的目标链下合约发起挑战，客户端71可获取针对链下隐私计算节点72创建的链下TEE的远程证明报告，该远程证明报告由认证服务器对链下隐私计算节点72针对链下TEE产生的自荐信息进行验证后生成。在一种情况下，由客户端71向链下隐私计算节点72发起挑战，挑战目标为链下隐私计算节点72部署的目标链下合约，进而接收链下隐私计算节点72响应于该挑战返回的所述远程证明报告和所述待验证合约信息，即链下隐私计算节点72响应于该挑战，将所述远程证明报告和所述待验证合约信息一次性返回至客户端71。在另一种情况下，由客户端71向链下隐私计算节点72发起挑战，挑战目标为链下隐私计算节点72创建的链下TEE，进而接收链下隐私计算节点72返回的远程证明报告，并在根据所述远程证明报告确定所述链下TEE可信的情况下，向链下隐私计算节点72发送针对部署于链下隐私计算节点72处的目标链下合约的合约信息的获取请求，接收链下隐私计算节点72响应于所述获取请求返回的待验证合约信息。而在根据所述远程证明报告确定所述链下TEE不可信的情况下，则无需再向链下隐私计算节点72请求获取目标链下合约的合约信息(即待验证合约信息)。
其中，客户端71可通过链上挑战向挑战目标发起挑战。比如，向区块链节点73n提交针对挑战目标的挑战交易，该挑战交易包含的挑战信息由区块链节点73n通过预言机机制传输至链下隐私计算节点72，所述挑战信息用于向挑战目标发起挑战。或者，客户端71直接向链下隐私计算节点72中的挑战目标发起链下挑战。
在本实施例中，客户端71根据远程证明报告对链下隐私计算节点72的链下TEE进行验证的操作可以包括：根据认证服务器的公钥对远程证明报告进行签名验证，并在签名验证通过且远程证明报告包含的远程认证结果为通过认证的情况下，从远程证明报告携带的自荐信息内提取出第一待检验哈希值，第一待检验哈希值为链下TEE的预设信息的哈希值，再将预先获得的针对该链下TEE的第一标准哈希值与第一待检验哈希值进行比较。其中，将比较结果一致作为确认该链下TEE可信的前提条件。需要说明 的是，此部分内容可参考前述控制节点验证待加入节点的过程，在此不再赘述。
如图7所示，在一实施例中，链下隐私计算节点72在链下TEE内生成自身的节点身份信息后，可对生成的节点身份信息进行哈希计算得到第二标准哈希值；其中，所生成的节点身份信息中包含链下隐私计算节点72的节点身份公钥和链下隐私计算节点72的其他身份信息。那么，客户端71可利用第二标准哈希值验证链下隐私计算节点72提供的第一节点身份信息(即声明的节点身份信息，包含链下隐私计算节点72的节点身份公钥和链下隐私计算节点72的其他身份信息，不一定为真实数据，此时可理解为待验证身份信息)，并在验证通过的情况下获取可验证链下隐私计算节点72的节点身份信息中包含的节点身份公钥，从而利用该节点身份公钥完成后续对目标链下合约的验证。比如，客户端对获取到的第一节点身份信息进行哈希计算以得到第二待校验哈希值，并将第二待校验哈希值与链下隐私计算节点72提供的第二标准哈希值进行比较，从而在比较结果一致的情况下判定节点身份信息验证通过。由于节点身份信息由链下隐私计算节点72在链下TEE内生成并计算得到第二标准哈希值，那么在根据远程证明报告判定链下TEE可信后，若第二待校验哈希值与第二标准哈希值相同，则说明隐私计算节点72提供的第一节点身份信息为在链下TEE内生成的节点身份信息，从而其中包含的节点身份公钥为隐私计算节点72实际的节点身份公钥，而隐私计算节点72实际的节点身份公钥可用于验证隐私计算节点72的签名。其中，链下隐私计算节点72可将第二标准哈希值、远程证明报告、第一节点身份信息一同发送至客户端71。需要说明的是，此部分内容可参考前述控制节点验证待加入节点的过程，在此不再赘述。
如图7所示，在另一实施例中，链下隐私计算节点72在链下TEE内生成自身的节点身份信息包含链下隐私计算节点72的节点身份公钥、链下隐私计算节点72的其他身份信息和链下TEE的预设信息的哈希值，那么链下隐私计算节点72在自身的链下TEE内生成节点身份信息后，对生成的节点身份信息进行哈希计算得到第三标准哈希值，那么第三标准哈希值相当于同时实现了上述第一待检验哈希值和第二标准哈希值的作用。具体而言，链下隐私计算节点72可向客户端71提供远程证明报告、第三标准哈希值和第二节点身份信息(此时可理解为待验证身份信息)。其中，第二节点身份信息包含链下隐私计算节点72的节点身份公钥、链下隐私计算节点72的其他身份信息和第四待校验哈希值，第四待校验哈希值为链下TEE的预设信息的哈希值；同时，第二节点身份信息为声明的节点身份信息，并不一定为链下隐私计算节点72的真实节点身份信息。那么，客户端71在根据认证服务器的公钥对远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下，对获取到的第二节点身份信息进行哈希计算以得到第三待校验哈希值，并将第三待校验哈希值与第三标准哈希值进行比较。当比较结果为一致时，说明隐私计算节点72提供的第二节点身份信息为在链下TEE内生成的节点身份信息，也即其中包含的第四待校验哈希值为链下TEE的实际预设信息的哈希值。因此，进一步将预先获得的针对所述链下TEE预设信息的第四标准哈希值与第四待检验哈希值进行比较，并将比较结果一致作为确认所述链下TEE可信的前提条件。同时，第二节点身份信息包含的节点身份公钥可判定为隐私计算节点72实际的节点身份公钥，可用于对待验证合约信息进行签名验证。其中，链下隐私计算节点72可将第三标准哈希值、远程证明报告、第二节点身份信息一同发送至客户端71。需要说明的是，此部分内容可参考前述控制节点验证待加入节点的过程，在此不再赘述。
客户端71在根据远程证明报告确定链下TEE可信的情况下，获取部署于链下隐私计算节点72处的目标链下合约的待验证合约信息，待验证合约信息被链下隐私计算节点72在链下TEE内采用自身的节点身份私钥进行签名，节点身份私钥由链下隐私计算节点72在链下TEE内生成。比如，链下隐私计算节点72可将部署的目标链下合约读入链下TEE内并采用自身的节点身份私钥进行签名。
客户端71采用链下隐私计算节点72的节点身份公钥对待验证合约信息进行签名验证，以及根据目标链下合约的合约信息对待验证合约信息进行合约信息验证。其中，节点身份公钥处于公开状态，比如链下隐私计算节点72向外公开发布节点身份公钥以由客户端71获取。或者，客户端71通过上述验证链下隐私计算节点72的节点身份信息的方式获取。同时，目标链下合约的合约信息也可处于公开状态，比如目标链下合约的部署方向外公开发布合约信息以由客户端71获取。其中，合约信息可以包括链下合约的名称、描述、版本号、字节码哈希值、合约身份公钥等信息，本说明书并不对此进行限制。
在签名验证和合约信息验证通过的情况下，客户端71可确定客户端71在通过区块链节点的预言机机制对目标链下合约发起调用时，该目标链下合约由链下隐私计算节点72在链下TEE可信执行环境中执行。本说明书中验证链下合约的过程为先验证链下隐私计算节点72的链下TEE可信，那么在验证链下隐私计算节点72的链下TEE可信的情况下，若验证签名得到链下隐私计算节点72提供的待验证合约信息确实由链下隐私计算节点72的节点身份私钥(维护在链下TEE内)签名，则可确定出当前挑战的链下合约为运行在链下隐私计算节点72的链下TEE内的目标链下合约，即确保链下隐私计算节点72中部署的目标链下合约可信，可按照用户预期执行计算任务。
如图8所示，针对链下隐私计算集群的形式，与图4所示实施例类似，客户端81可向控制节点82发起链下挑战或者链上挑战。链上挑战的发起过程可以包括三个步骤：步骤①，客户端81向区块链网络83提交一笔用于向目标链下合约发起挑战的交易，比如称之为挑战交易，该挑战交易可由区块链网络83内的某一节点83n接收和执行；步骤②，节点83n调用预先部署的预言机合约，该预言机合约可以将上述挑战交易所含的挑战信息传递至链下的预言机服务器84，比如预言机合约可以产生包含该挑战信息的事件，而预言机服务器84可以通过监听预言机合约产生的事件，从而获取上述的挑战信息；步骤③，预言机服务器84将挑战信息通过链下渠道发送至控制节点82。
链下隐私计算集群作为一个整体向外提供执行计算任务的功能。其中，集群内各个节点均部署有相同的链下合约，那么各个节点均可以代表集群来执行计算任务，比如，计算任务可由控制节点来分配。因此，各个节点在代表集群与外部进行数据交互时，使用代表集群身份的集群身份密钥来对与外部交互的数据进行解密或签名，而非使用节点自身的节点身份密钥。相应的，外部对象在通过客户端与集群进行交互时，将集群视为一个整体而无需关心集群内部的结构，因此采用集群身份密钥进行加密或验证签名。
如图8所示，用户在通过客户端81调用集群中的目标链下合约之前，可通过客户端81对集群中部署的目标链下合约发起挑战(在链下隐私计算集群中的每个节点均部署目标链下合约后发起挑战)。控制节点82在接收到挑战后，可选取集群中的任意节点来响应该挑战。比如，可选取上述用于生成集群身份密钥的主节点，或者选取集群中的从节点，本说明书并不对选取响应挑战的节点的方式进行限制。以节点82n响应挑战为例进行说明。控制节点82选取节点82n来代表集群响应挑战，向挑战方提供代表集群的集群远程证明报告。其中，集群远程证明报告由认证服务器对节点82n针对自身的链下TEE产生的自荐信息进行验证后生成，即集群远程证明报告为对应于节点82n的链下TEE的远程证明报告。具体而言，集群远程证明报告携带的自荐信息内包含第一待检验哈希值，该第一待检验哈希值为节点82n的链下TEE的预设信息的哈希值，该第一待检验哈希值用于挑战方在根据认证服务器的公钥对集群远程证明报告进行签名验证并签名验证通过，且集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对链下TEE的第一标准哈希值(比如，为链下TEE的上述预设信息的可信哈希值)进行比较，且比较结果一致被作为挑战方确认链下TEE可信的前提条件。其中，挑战方根据集群远程证明报告验证链下TEE的过程可参考前述控制节点验证待加入节点的链下TEE的内容，在此不再赘述。实际上，挑战方根据集群远程证明报告 验证的链下TEE为节点82n的链下TEE。
如图8所示，在一实施例中，节点82n在链下TEE内生成自身的节点身份信息时，还可在链下TEE内生成代表集群的集群身份信息，并对生成的集群身份信息进行哈希计算得到第二标准哈希值；其中，所生成的集群身份信息中包含集群身份公钥和节点82n的节点身份信息中除节点身份公钥以外的其他身份信息。换言之，基于通过节点82n来代表集群，节点82n的节点身份信息与集群身份信息之间的差异在于：节点身份信息中记录的公钥为节点身份公钥，集群身份信息中记录的公钥为集群身份公钥；持此之外，其他身份信息相同。那么，客户端81可利用第二标准哈希值验证节点82n提供的第一集群身份信息(即声明的集群身份信息，包含集群身份公钥和节点82n的其他身份信息，不一定为真实数据，此时可理解为待验证身份信息)，并在验证通过的情况下获取集群身份信息中包含的集群身份公钥，从而利用该集群身份公钥完成后续对目标链下合约的验证。比如，客户端对获取到的第一集群身份信息进行哈希计算以得到第二待校验哈希值，并将第二待校验哈希值与节点82n提供的第二标准哈希值进行比较，从而在比较结果一致的情况下判定集群身份验证通过。由于集群身份信息由节点82n在链下TEE内生成并计算得到第二标准哈希值，那么在根据远程证明报告判定链下TEE可信后，若第二待校验哈希值与第二标准哈希值相同，则说明隐私计算节点82提供的第一集群身份信息为在链下TEE内生成的集群身份信息，从而其中包含的集群身份公钥为隐私计算节点82实际维护的对应于集群的集群身份公钥，而隐私计算节点82实际维护的集群身份公钥可用于验证隐私计算节点82的签名。其中，节点82n可通过控制节点82将第二标准哈希值、远程证明报告、第一集群身份信息一同发送至客户端81。需要说明的是，此部分内容可参考前述控制节点验证待加入节点的过程，在此不再赘述。
如图8所示，在另一实施例中，节点82n在链下TEE内生成的集群身份信息可包含集群身份公钥、节点82n的节点身份信息中除节点身份公钥以外的其他身份信息和链下TEE的预设信息的哈希值，那么节点82n在自身的链下TEE内生成集群身份信息后，对生成的集群身份信息进行哈希计算得到第三标准哈希值，那么第三标准哈希值相当于同时实现了上述第一待检验哈希值和第二标准哈希值的作用。具体而言，节点82n可向客户端81提供远程证明报告、第三标准哈希值和第二集群身份信息(此时可理解为待验证身份信息)。其中，第二集群身份信息包含集群身份公钥、节点82n的其他身份信息和第四待校验哈希值，第四待校验哈希值为链下TEE的预设信息的哈希值；同时，第二集群身份信息为声明的集群身份信息，并不一定为节点82n提供的真实集群身份信息。那么，客户端81在根据认证服务器的公钥对远程证明报告进行签名验证并在签名验证通过且所述远程证明报告包含的远程认证结果为通过认证的情况下，对获取到的第二集群身份信息进行哈希计算以得到第三待校验哈希值，并将第三待校验哈希值与第三标准哈希值进行比较。当比较结果为一致时，说明隐私计算节点82提供的第二集群身份信息为在链下TEE内生成的集群身份信息，也即其中包含的第四待校验哈希值为链下TEE的实际预设信息的哈希值。因此，进一步将预先获得的针对所述链下TEE预设信息的第四标准哈希值与第四待检验哈希值进行比较，并将比较结果一致作为确认所述链下TEE可信的前提条件。同时，第二集群身份信息包含的集群身份公钥可判定为隐私计算节点82实际维护的集群身份公钥，可用于对待验证合约信息进行签名验证。其中，节点82n可通过控制节点82将第三标准哈希值、远程证明报告、第二集群身份信息一同发送至客户端81。需要说明的是，此部分内容可参考前述控制节点验证待加入节点的过程，在此不再赘述。
与上述图7所示的实施例类似，集群远程证明报告和待验证合约信息由节点82n发送至控制节点82，再由控制节点82转发至客户端81。控制节点82可一并向客户端81提供集群远程证明报告和待验证合约信息，也可先提供集群远程证明报告，并在客户端81根据集群远程证明报告验证通过后再向节点82n获取待验证合约信息以向客户端 81提供待验证合约信息。其中，待验证合约信息为部署在节点82n处的目标链下合约的合约信息，并由节点82n在节点82n的链下TEE内采用集群身份私钥(维护在节点82n的链下TEE内)进行签名。比如，节点82n将部署在节点82n处的目标链下合约读入链下TEE内，并采用集群身份私钥进行签名。
客户端81在根据集群远程证明报告确定链下TEE可信(即节点82n的链下TEE，由节点82n代表集群，用户感知不到集群内的其他节点)的情况下，采用集群身份公钥对待验证合约信息进行签名验证，以及根据目标链下合约的合约信息对待验证合约信息进行合约信息验证。其中，集群身份公钥处于公开状态，比如控制节点81向外公开发布集群身份公钥以由客户端81获取。或者，客户端81通过上述验证集群身份信息的方式获取。同时，目标链下合约的合约信息也可处于公开状态，比如目标链下合约的部署方向外公开发布合约信息以由客户端81获取。其中，合约信息可以包括链下合约的名称、描述、版本号、字节码哈希值、合约身份公钥等信息，本说明书并不对此进行限制。
与上述单节点形式中验证目标链下合约的原理类似，在签名验证和合约信息验证通过的情况下，客户端81可确定客户端81在通过区块链节点的预言机机制对目标链下合约发起调用时，该目标链下合约由节点82n在链下TEE可信执行环境中执行，即确保节点82n中部署的目标链下合约可信，可按照用户预期执行计算任务。
需要说明的是，在链下隐私计算集群的形式中，各类远程证明报告可以具有一定的时限性，比如30分钟或其他时长，超时的远程证明报告被判定为失效。比如，共享集群身份密钥过程中涉及的远程证明报告均由节点实时向认证服务器控制节点获取，而集群远程证明报告可由控制节点在本地缓存并设定老化时长。
区块链节点根据计算结果更新区块链账本数据，或者称为对计算结果进行上链，其方式可以包括：生成一笔区块链交易，将计算结果添加至交易的data字段，当该区块链交易通过共识后，可被各个区块链节点添加至最新区块的区块体中，从而实现了区块链账本数据的更新，亦即完成了对该计算结果的上链；或者，区块链节点根据计算结果对相关账户的状态进行更新，该相关账户譬如可以为用户对应的外部账户或者链上合约对应的合约账户，该相关账户的状态更新会导致状态树(state tree)的树根发生取值变化，而该状态树的树根会被包含于最新区块的区块头，从而实现了区块链账本数据的更新，亦即相当于将该计算结果上链。
本说明书中的链下合约，可以实现用户定义的任何计算逻辑。例如，链下合约可以用于验证区块链上存储的加密订单数据的金额是否正确，并将验证结果反馈至链上；再例如，链下合约可以用于根据预设算法对多方数据进行安全计算，即安全多方计算，并将计算结果反馈至链上等，此处不再一一赘述。
如图9所示，假定客户端91希望对已部署的链下合约进行调用(比如在验证目标链下合约通过之后)。客户端91可以通过链下渠道向控制节点92发送调用请求，该调用请求采用集群身份公钥进行加密，控制节点92可以基于负载均衡算法将该调用请求分配至集群内的某个链下隐私计算节点，比如节点92n，由该节点92n对调用请求进行响应。节点92n在自身创建的链下TEE中通过集群身份私钥解密调用请求，获得调用请求中包含的合约ID、函数名和入参数据的信息。合约ID譬如可以为链下合约的字节码的哈希值，使得节点92n可以据此找到相应的已部署的链下合约的字节码。链下合约可能包含多个函数，因而函数名可以指明客户端91希望调用的函数；如果链下合约仅包含一个函数，或者客户端91希望调用链下合约中的所有函数，那么调用请求中也可以省去函数名的信息。入参数据的信息可以为入参数据本身，或者入参数据的描述信息，比如该描述信息可以为存储地址等，使得节点92n可以据此获取入参数据，尤其是当客户端91本身并非数据拥有者的情况下，可以省去客户端91与数据拥有者之间的交互，还可以降低调用请求的数据量、加快其传输速度。然后，节点92n可以在链下TEE中执行链下合约的字节码，以针对入参数据进行处理，从而得到相应的调用结果。节点92n 可以在链下TEE中对该调用结果进行加密后，经由控制节点92反馈至客户端91。
客户端91可以通过链上渠道向控制节点92发送调用请求。客户端91可以向区块链网络93提交链下合约调用交易，该链下合约调用交易中包含调用请求，该调用请求由客户端91采用集群身份公钥进行加密。当然，链下合约调用交易本身也可以是加密传输的，比如采用集群身份公钥对调用交易进行加密，或者其他加密方式，这可以参考前文所述的数据加密传输的内容，此处不再赘述。链下合约调用交易可以调用预言机合约，使得预言机合约针对该交易所含的调用请求产生相应的合约事件，该合约事件被预言机服务器94监听到之后，由预言机服务器94获取调用请求并传输至控制节点92。然后，控制节点92将调用请求分配至诸如链下隐私计算节点92n进行响应。以及，控制节点92可以通过预言机机制将调用结果反馈至链上，而节点93n可以主动发起一笔交易，将该调用结果上链，或者节点93n可以将调用结果反馈至客户端91，由客户端91重新发起一笔交易将该调用结果上链。
如果入参数据为区块链数据，客户端91可以向区块链网络93提交加密后的链下合约调用交易，该链下合约调用交易中包含合约ID、函数名和入参数据的信息，并且该链下合约调用交易调用了用于获取入参数据的链上合约。节点93n收到加密后的链下合约调用交易后，在节点93n创建的链上TEE中进行解密，然后通过链上TEE内部署的虚拟机执行被调用的链上合约，以获取被作为入参数据的区块链数据，该区块链数据通常处于加密状态，节点93n可以在链上TEE内解密为明文，然后将该明文的区块链数据与链下合约调用交易所含的合约ID、函数名打包为调用请求，并在链上TEE内采用集群身份公钥对该调用请求进行加密，而后基于预言机机制传输至控制节点92，由控制节点92将调用请求分配至诸如链下隐私计算节点92n进行响应。以及，控制节点92可以通过预言机机制将调用结果反馈至链上，而节点93n可以将该调用结果上链。
客户端91或节点93n除了采用集群身份公钥对调用请求进行加密之外，还可以采用合约加密公钥对调用请求内所含的入参数据的信息进行加密。链下隐私计算节点92n在收到针对某一链下合约的调用请求后，采用该链下合约对应的合约加密私钥对调用请求内加密后的入参数据的信息进行解密，从而确保入参数据的信息只能由被调用的链下合约所获得，而不会被其他链下合约获得。以及，在得到调用结果(即执行链下合约得到的执行结果)后，链下隐私计算节点92n可以通过被调用的链下合约的合约签名私钥对调用结果进行签名，而客户端91或节点93n可以通过合约签名公钥进行验签，从而确定该调用结果确实是由被调用的链下合约所产生。
在图9所示实施例中，以链下隐私计算集群为例进行描述。实际上，客户端91也可以直接与单个链下隐私计算节点进行交互，以调用该链下隐私计算节点上部署的链下合约，此处不再赘述。
需要说明的是，本说明书中加密与解密，生成签名与验证签名，可采用同一组密钥对，或者分别配置一组加密密钥对和一组签名密钥对。其中，在一组密钥对中，对应于不同的加密算法，可能同时存在多个公钥和相应的私钥。下面以节点身份密钥为例进行说明，集群身份密钥和合约身份密钥与此类似。
在一种情况下，节点身份密钥为一组密钥对，包含节点身份公钥和节点身份私钥。其中，节点身份公钥可用于对数据进行加密，那么可采用节点身份私钥对该数据进行解密；节点身份私钥可用于对数据进行签名，那么可采用节点身份公钥对该数据进行签名验证。在另一种情况下，可配置两组密钥对，分别为节点加密密钥对和节点签名密钥对。其中，节点加密密钥对用于对数据进行加密与解密，节点签名密钥对用于对数据进行签名与验证签名。
在图1所示实施例中，由集群内的任一节点向其他节点共享集群身份密钥，从该任一节点侧对共享过程进行描述。相应的，在图10所示实施例中，由集群内的任一节点接收其他节点共享的集群身份密钥(即由其他节点向该任一节点共享集群身份密钥)， 从该任一节点侧对共享过程进行描述。需要说明的是，图1所示的共享过程中所涉及的描述同样可以适用于图10所示的共享过程，下文中不再对此进行赘述。
请参见图10，图10是一示例性实施例提供的另一种共享集群密钥的方法的流程图。如图10所示，该共享过程可以包括步骤1002～步骤1006。
步骤1002，链下隐私计算集群中的任一节点向所述链下隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成。
步骤1004，所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下发送的对应于所述链下隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成。
如前所述，所述任一节点根据所述第二远程证明报告确定所述第二链下可信执行环境可信的操作包括：根据所述认证服务器的公钥对所述第二远程证明报告进行签名验证；在签名验证通过且所述第二远程证明报告包含的远程认证结果为通过认证的情况下，从所述第二远程证明报告携带的所述第二自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第二链下可信执行环境中预设信息的哈希值；将预先获得的针对所述预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第二链下可信执行环境可信的前提条件。
如前所述，所述任一节点向所述其他节点提供第一节点身份信息，所述第一节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息，所述第一身份信息被所述其他节点进行哈希计算以得到第二待校验哈希值；所述任一节点向所述其他节点提供第二标准哈希值，所述第二标准哈希值由所述任一节点在所述第一链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；在所述第二标准哈希值与所述第二待校验哈希值一致的情况下，所述集群身份密钥被所述其他节点采用所述其他节点的节点身份私钥进行签名，并采用所述任一节点的节点身份公钥对签名后的集群身份密钥进行加密。
如前所述，所述任一节点获取所述其他节点提供的第二节点身份信息，并对所述第二节点身份信息进行哈希计算得到第三待校验哈希值，所述第二节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；所述任一节点获取所述其他节点提供的第三标准哈希值，所述第三标准哈希值由所述其他节点在所述第二链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；所述任一节点在所述第三待校验哈希值和所述第三标准哈希值一致的情况下，采用所述任一节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述其他节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一链下可信执行环境内维护所述集群身份密钥。
如前所述，在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标链下合约的情况下，在所述第一链下可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标链下合约并进行部署；在区块链节点通过预言机机制对所述目标链下合约发起调用的情况下，在所述第一链下可信执行环境中执行所述目标链下合约，并通过所述预言机机制将执行结果反馈至所述区块链节点。
如前所述，所述任一节点在接收到加密后的所述目标链下合约之前，所述任一节点响应于所述目标链下合约的部署方发起的挑战，向所述部署方提供所述第一远程证明报告；其中，加密后的所述目标链下合约由所述部署方在根据所述第一远程证明报告确 定所述第一链下可信执行环境可信的情况下发送。
如前所述，所述任一节点在通过所述预言机机制将执行结果反馈至所述区块链节点之前，在所述第一链下可信执行环境内采用所述目标链下合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标链下合约生成。
如前所述，所述任一节点生成所述目标链下合约的合约身份密钥的操作包括：在所述第一链下可信执行环境内采用所述链下隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标链下合约的全局标识信息生成所述合约身份密钥；其中，所述目标链下合约部署在所述链下隐私计算集群中的各个节点处。
如前所述，在区块链节点通过预言机机制对所述目标链下合约发起调用之前，所述任一节点向所述目标链下合约的挑战方提供所述集群远程证明报告，所述集群远程证明报告由认证服务器对所述第一自荐信息进行验证后生成；向所述挑战方提供部署于所述任一节点处的所述目标链下合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第一链下可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名；所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第一链下可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标链下合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标链下合约发起调用时，所述目标链下合约由所述任一节点在所述第一链下可信执行环境中执行。
如前所述，所述集群远程证明报告携带的所述第一自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第一链下可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第一链下可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第一链下可信执行环境可信的前提条件。
如前所述，所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第一链下可信执行环境内生成所述集群身份信息后对所述集群身份信息进行哈希计算得到；所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集群身份信息中包含的所述集群身份公钥。
如前所述，所述挑战方在所述链下隐私计算集群中的每个节点均部署所述目标链下合约后发起挑战，且所发起的挑战由所述链下隐私计算集群的控制节点接收，以及转发至所述任一节点。
如前所述，所述任一节点接收区块链节点通过预言机机制对所述目标链下合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述链下隐私计算集群的控制节点接收，并根据所述链下隐私计算集群的负载情况转发至所述任一节点；在所述第一链下可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标链下合约。
步骤1006，所述任一节点在确定出所述第二远程证明报告表明所述第二链下可信 执行环境可信的情况下认可所述集群身份密钥。
如前所述，所述任一节点在确定出第二远程证明报告表明第二链下可信执行环境可信的情况下认可集群身份密钥，从而在自身的第一链下可信执行环境内维护集群身份密钥。
在本说明书的技术方案中，还可由客户端直接与隐私计算节点进行交互以完成在隐私计算节点上部署智能合约、向智能合约发起挑战、验证智能合约和调用智能合约等操作，而无需通过区块链的预言机机制来完成上述操作，同时调用部署于隐私计算节点的智能合约得到的计算结果也无需反馈至区块链。在该情况下，由于不涉及链上和链下的区分，下文将“链下隐私计算节点”称为“隐私计算节点”，将“链下隐私计算集群”称为“隐私计算集群”，将“链下可信执行环境”称为“可信执行环境”，将“链下合约”称为“智能合约”。但是，技术方案的原理与上述实施例类似，所涉及的实施细节同样可参考上述实施例，因此下文不再进行详细描述。
相应地，图11是一示例性实施例提供的另一种共享集群密钥的方法的流程图。如图11所示，该方法可以包括步骤1102～步骤1106。
步骤1102，隐私计算集群中的任一节点获取所述隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一可信执行环境产生的第一自荐信息进行验证后生成。
如前所述，所述任一节点根据所述认证服务器的公钥对所述第一远程证明报告进行签名验证；在签名验证通过且所述第一远程证明报告包含的远程认证结果为通过认证的情况下，从所述第一远程证明报告携带的所述第一自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第一可信执行环境中预设信息的哈希值；将预先获得的针对所述第一可信执行环境中预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第一可信执行环境可信的前提条件。
步骤1104，所述任一节点获取对应于所述隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二可信执行环境内生成，在客户端与所述隐私计算集群中的各节点进行交互以部署或调用智能合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签。
步骤1106，所述任一节点在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，在所述第二远程证明报告表明所述第二可信执行环境可信的情况下，所述集群身份密钥被所述其他节点认可，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二可信执行环境产生的第二自荐信息进行验证后生成。
如前所述，所述任一节点获取所述其他节点提供的第一节点身份信息，并对获取到的第一节点身份信息进行哈希计算以得到第二待校验哈希值，所述第一节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；获取所述其他节点提供的第二标准哈希值，所述第二标准哈希值由所述其他节点在所述第一可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；将所述第二待校验哈希值与所述第二标准哈希值进行比较，并在比较结果一致的情况下获取所述其他节点的节点身份信息中包含的节点身份公钥；采用所述任一节点的节点身份私钥对所述集群身份密钥进行签名，并采用所述其他节点的节点身份公钥对签名后的集群身份密钥进行加密。
如前所述，所述任一节点向所述其他节点提供第二节点身份信息，所述第二节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息；所述任一节点向所述其他节点提供第三标准哈希值，所述第三标准哈希值由所述任一节点在所述第二可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；其中，在对所述第二节点身份信息进行哈希计算得到的第三待校验哈希值与所述 第三标准哈希值一致的情况下，所述其他节点采用所述其他节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述任一节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一可信执行环境内维护所述集群身份密钥。
如前所述，所述任一节点在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标智能合约的情况下，在所述第二可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标智能合约并进行部署；在所述客户端对所述目标智能合约发起调用的情况下，在所述第二可信执行环境中执行所述目标智能合约，并将执行结果反馈至所述客户端。
如前所述，所述任一节点响应于所述目标智能合约的部署方发起的挑战，向所述部署方提供所述第二远程证明报告；其中，加密后的所述目标智能合约由所述部署方在根据所述第二远程证明报告确定所述第二可信执行环境可信的情况下发送。
如前所述，所述任一节点在所述第二可信执行环境内采用所述目标智能合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标智能合约生成。
如前所述，生成所述目标智能合约的合约身份密钥的操作包括：在所述第二可信执行环境内采用所述隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标智能合约的全局标识信息生成所述合约身份密钥；其中，所述目标智能合约部署在所述隐私计算集群中的各个节点处。
如前所述，在所述客户端对所述目标智能合约发起调用之前，所述任一节点向所述目标智能合约的挑战方提供所述集群远程证明报告，所述集群远程证明报告由认证服务器对所述第二自荐信息进行验证后生成；向所述挑战方提供部署于所述任一节点处的所述目标智能合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第二可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名，所述集群身份密钥中的集群身份私钥由所述任一节点维护在所述第二可信执行环境内；所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第二可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标智能合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标智能合约发起调用时，所述目标智能合约由所述任一节点在所述第二可信执行环境中执行。
如前所述，所述集群远程证明报告携带的所述第二自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第二可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第二可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第二可信执行环境可信的前提条件。
如前所述，还包括：所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第二可信执行环境内生成所述集群身份信息后对所述集群身份信息进行哈希计算得到；所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集群身份信息中包含的所述集群身份公钥。
如前所述，所述任一节点接收所述客户端对所述目标智能合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述隐私计算集群的控制节点接收，并根据所述隐私计算集群的负载情况转发至所述任一节点；在所述第二可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标智能合约。
相应地，图12是一示例性实施例提供的另一种共享集群密钥的方法的流程图。如图12所示，该方法可以包括步骤1202～步骤1206。
步骤1202，隐私计算集群中的任一节点向所述隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一可信执行环境产生的第一自荐信息进行验证后生成。
如前所述，所述任一节点根据所述第二远程证明报告确定所述第二可信执行环境可信的操作包括：根据所述认证服务器的公钥对所述第二远程证明报告进行签名验证；在签名验证通过且所述第二远程证明报告包含的远程认证结果为通过认证的情况下，从所述第二远程证明报告携带的所述第二自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第二可信执行环境中预设信息的哈希值；将预先获得的针对所述第二可信执行环境中预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第二可信执行环境可信的前提条件。
步骤1204，所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下发送的对应于所述隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二可信执行环境内生成，在客户端与所述隐私计算集群中的各节点进行交互以部署或调用智能合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二可信执行环境产生的第二自荐信息进行验证后生成。
步骤1206，所述任一节点在确定出所述第二远程证明报告表明所述第二可信执行环境可信的情况下认可所述集群身份密钥。
如前所述，所述任一节点向所述其他节点提供第一节点身份信息，所述第一节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息，所述第一身份信息被所述其他节点进行哈希计算以得到第二待校验哈希值；所述任一节点向所述其他节点提供第二标准哈希值，所述第二标准哈希值由所述任一节点在所述第一可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；在所述第二标准哈希值与所述第二待校验哈希值一致的情况下，所述集群身份密钥被所述其他节点采用所述其他节点的节点身份私钥进行签名，并采用所述任一节点的节点身份公钥对签名后的集群身份密钥进行加密。
如前所述，所述任一节点获取所述其他节点提供的第二节点身份信息，并对所述第二节点身份信息进行哈希计算得到第三待校验哈希值，所述第二节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；所述任一节点获取所述其他节点提供的第三标准哈希值，所述第三标准哈希值由所述其他节点在所述第二可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；所述任一节点在所述第三待校验哈希值和所述第三标准哈希值一致的情况下，采用所述任一节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述其他节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一可信执行环境内维护所述集群身份密钥。
如前所述，所述任一节点在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标智能合约的情况下，在所述第一可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标智能合约并进行部署；在所述客户端对所述目标智能合约发 起调用的情况下，在所述第一可信执行环境中执行所述目标智能合约，并将执行结果反馈至所述客户端。
如前所述，所述任一节点在接收到加密后的所述目标智能合约之前，响应于所述目标智能合约的部署方发起的挑战，向所述部署方提供所述第一远程证明报告；其中，加密后的所述目标智能合约由所述部署方在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下发送。
如前所述，所述任一节点在将执行结果反馈至所述客户端之前，在所述第一可信执行环境内采用所述目标智能合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标智能合约生成。
如前所述，所述任一节点生成所述目标智能合约的合约身份密钥的操作包括：在所述第一可信执行环境内采用所述隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标智能合约的全局标识信息生成所述合约身份密钥；其中，所述目标智能合约部署在所述隐私计算集群中的各个节点处。
如前所述，在所述客户端对所述目标智能合约发起调用之前，所述任一节点向所述目标智能合约的挑战方提供所述集群远程证明报告，所述集群远程证明报告由认证服务器对所述第一自荐信息进行验证后生成；向所述挑战方提供部署于所述任一节点处的所述目标智能合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第一可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名；所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第一可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标智能合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标智能合约发起调用时，所述目标智能合约由所述任一节点在所述第一可信执行环境中执行。
如前所述，所述集群远程证明报告携带的所述第一自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第一可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第一可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第一可信执行环境可信的前提条件。
如前所述，所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第一可信执行环境内生成所述集群身份信息后对所述集群身份信息进行哈希计算得到；所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集群身份信息中包含的所述集群身份公钥。
如前所述，所述任一节点接收所述客户端对所述目标智能合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述隐私计算集群的控制节点接收，并根据所述隐私计算集群的负载情况转发至所述任一节点；在所述第一可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标智能合约。
需要说明的是，上述共享集群身份密钥的具体过程可参考上述图1所示的实施例，下文中不再对此进行赘述。
与上述方法实施例相对应，本说明书还提供了共享集群密钥的装置的实施例。
本说明书的共享集群密钥的装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。
从硬件层面而言，请参考图13，图13是一示例性实施例提供的一种设备的示意结构图。如图13所示，在硬件层面，该设备包括处理器1302、内部总线1304、网络接口1306、内存1308以及非易失性存储器1310，当然还可能包括其他业务所需要的硬件。处理器1302从非易失性存储器1310中读取对应的计算机程序到内存1308中然后运行，在逻辑层面上形成共享集群密钥的装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
在一实施例中，请参考图14，在软件实施方式中，该共享集群密钥的装置可以包括：报告获取单元1401，使链下隐私计算集群中的任一节点获取所述链下隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；密钥获取单元1402，使所述任一节点获取对应于所述链下隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签；发送单元1403，使所述任一节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，在所述第二远程证明报告表明所述第二链下可信执行环境可信的情况下，所述集群身份密钥被所述其他节点认可，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成。
可选的，所述报告获取单元1401具体用于：根据所述认证服务器的公钥对所述第一远程证明报告进行签名验证；在签名验证通过且所述第一远程证明报告包含的远程认证结果为通过认证的情况下，从所述第一远程证明报告携带的所述第一自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第一链下可信执行环境中预设信息的哈希值；将预先获得的针对所述第一链下可信执行环境中预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第一链下可信执行环境可信的前提条件。
可选的，所述任一节点在向所述其他节点发送所述集群身份密钥之前，发送单元1403具体用于：获取所述其他节点提供的第一节点身份信息，并对获取到的第一节点身份信息进行哈希计算以得到第二待校验哈希值，所述第一节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；获取所述其他节点提供的第二标准哈希值，所述第二标准哈希值由所述其他节点在所述第一链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；将所述第二待校验哈希值与所述第二标准哈希值进行比较，并在比较结果一致的情况下获取所述其他节点的节点身份信息中包含的节点身份公钥；采用所述任一节点的节点身份私钥对所述集群身份密钥进行签名，并采用所述其他节点的节点身份公钥对签名后的集群身份密钥进行加密。
可选的，发送单元1403具体用于：所述任一节点向所述其他节点提供第二节点身份信息，所述第二节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息；所述任一节点向所述其他节点提供第三标准哈希值，所述第三标准哈希值由所述任一节点在所述第二链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；其中，在对所述第二节点身份信息进行哈希计算得到 的第三待校验哈希值与所述第三标准哈希值一致的情况下，所述其他节点采用所述其他节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述任一节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一链下可信执行环境内维护所述集群身份密钥。
可选的，发送单元1403具体用于：在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标链下合约的情况下，在所述第二链下可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标链下合约并进行部署；在区块链节点通过预言机机制对所述目标链下合约发起调用的情况下，在所述第二链下可信执行环境中执行所述目标链下合约，并通过所述预言机机制将执行结果反馈至所述区块链节点。
可选的，所述任一节点在接收到加密后的所述目标链下合约之前，可选的，发送单元1403还用于：响应于所述目标链下合约的部署方发起的挑战，向所述部署方提供所述第二远程证明报告；其中，加密后的所述目标链下合约由所述部署方在根据所述第二远程证明报告确定所述第二链下可信执行环境可信的情况下发送。
可选的，所述任一节点在通过所述预言机机制将执行结果反馈至所述区块链节点之前，发送单元1403具体用于：在所述第二链下可信执行环境内采用所述目标链下合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标链下合约生成。
可选的，生成所述目标链下合约的合约身份密钥的操作包括：在所述第二链下可信执行环境内采用所述链下隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标链下合约的全局标识信息生成所述合约身份密钥；其中，所述目标链下合约部署在所述链下隐私计算集群中的各个节点处。
可选的，在区块链节点通过预言机机制对所述目标链下合约发起调用之前，发送单元1403具体用于：所述任一节点向所述目标链下合约的挑战方提供所述集群远程证明报告，所述集群远程证明报告由认证服务器对所述第二自荐信息进行验证后生成；
向所述挑战方提供部署于所述任一节点处的所述目标链下合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第二链下可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名，所述集群身份密钥中的集群身份私钥由所述任一节点维护在所述第二链下可信执行环境内；所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第二链下可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标链下合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标链下合约发起调用时，所述目标链下合约由所述任一节点在所述第二链下可信执行环境中执行。
可选的，所述集群远程证明报告携带的所述第二自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第二链下可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第二链下可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第二链下可信执行环境可信的前提条件。
可选的，发送单元1403具体用于：所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第二链下可信执行环境内生成所 述集群身份信息后对所述集群身份信息进行哈希计算得到；所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集群身份信息中包含的所述集群身份公钥。
可选的，所述挑战方在所述链下隐私计算集群中的每个节点均部署所述目标链下合约后发起挑战，且所发起的挑战由所述链下隐私计算集群的控制节点接收，以及转发至所述任一节点。
可选的，发送单元1403具体用于：接收区块链节点通过预言机机制对所述目标链下合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述链下隐私计算集群的控制节点接收，并根据所述链下隐私计算集群的负载情况转发至所述任一节点；在所述第二链下可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标链下合约。
在一实施例中，请参考图15，在软件实施方式中，该共享集群密钥的装置可以包括：报告提供单元1501，使链下隐私计算集群中的任一节点向所述链下隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；接收单元1502，使所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下发送的对应于所述链下隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成；处理单元1503，使所述任一节点在确定出所述第二远程证明报告表明所述第二链下可信执行环境可信的情况下认可所述集群身份密钥。
可选的，报告提供单元1501具体用于：根据所述认证服务器的公钥对所述第二远程证明报告进行签名验证；在签名验证通过且所述第二远程证明报告包含的远程认证结果为通过认证的情况下，从所述第二远程证明报告携带的所述第二自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第二链下可信执行环境中预设信息的哈希值；将预先获得的针对所述第二链下可信执行环境中预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第二链下可信执行环境可信的前提条件。
可选的，报告提供单元1501具体用于：所述任一节点向所述其他节点提供第一节点身份信息，所述第一节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息，所述第一身份信息被所述其他节点进行哈希计算以得到第二待校验哈希值；所述任一节点向所述其他节点提供第二标准哈希值，所述第二标准哈希值由所述任一节点在所述第一链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；在所述第二标准哈希值与所述第二待校验哈希值一致的情况下，所述集群身份密钥被所述其他节点采用所述其他节点的节点身份私钥进行签名，并采用所述任一节点的节点身份公钥对签名后的集群身份密钥进行加密。
可选的，报告提供单元1501具体用于：所述任一节点获取所述其他节点提供的第二节点身份信息，并对所述第二节点身份信息进行哈希计算得到第三待校验哈希值，所述第二节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；所述任一节点获取所述其他节点提供的第三标准哈希值，所述第三标准哈希值由所述其他节点在所述第二链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；所述任一节点在所述第三待校验哈希值和所述第三标准哈希值一致的情况下，采用所述任一节点的节点身份私钥对接收到的集群身份密钥进行解 密，以及采用所述其他节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一链下可信执行环境内维护所述集群身份密钥。
可选的，处理单元1503还用于：在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标链下合约的情况下，在所述第一链下可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标链下合约并进行部署；在区块链节点通过预言机机制对所述目标链下合约发起调用的情况下，在所述第一链下可信执行环境中执行所述目标链下合约，并通过所述预言机机制将执行结果反馈至所述区块链节点。
可选的，在接收到加密后的所述目标链下合约之前，处理单元1503还用于：使所述任一节点响应于所述目标链下合约的部署方发起的挑战，向所述部署方提供所述第一远程证明报告；其中，加密后的所述目标链下合约由所述部署方在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下发送。
可选的，在通过所述预言机机制将执行结果反馈至所述区块链节点之前，处理单元1503还用于：使所述任一节点在所述第一链下可信执行环境内采用所述目标链下合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标链下合约生成。
可选的，所述任一节点生成所述目标链下合约的合约身份密钥的操作包括：在所述第一链下可信执行环境内采用所述链下隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标链下合约的全局标识信息生成所述合约身份密钥；其中，所述目标链下合约部署在所述链下隐私计算集群中的各个节点处。
可选的，在区块链节点通过预言机机制对所述目标链下合约发起调用之前，报告提供单元1501还用于：所述任一节点向所述目标链下合约的挑战方提供所述集群远程证明报告，所述集群远程证明报告由认证服务器对所述第一自荐信息进行验证后生成；向所述挑战方提供部署于所述任一节点处的所述目标链下合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第一链下可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名；所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第一链下可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标链下合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标链下合约发起调用时，所述目标链下合约由所述任一节点在所述第一链下可信执行环境中执行。
可选的，所述集群远程证明报告携带的所述第一自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第一链下可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第一链下可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第一链下可信执行环境可信的前提条件。
可选的，报告提供单元1501还用于：所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第一链下可信执行环境内生成所述集群身份信息后对所述集群身份信息进行哈希计算得到；所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集 群身份信息中包含的所述集群身份公钥。
可选的，所述挑战方在所述链下隐私计算集群中的每个节点均部署所述目标链下合约后发起挑战，且所发起的挑战由所述链下隐私计算集群的控制节点接收，以及转发至所述任一节点。
可选的，接收单元1502还用于：接收区块链节点通过预言机机制对所述目标链下合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述链下隐私计算集群的控制节点接收，并根据所述链下隐私计算集群的负载情况转发至所述任一节点；在所述第一链下可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标链下合约。
在一实施例中，请参考图16，在软件实施方式中，该共享集群密钥的装置可以包括：报告获取单元1601，使隐私计算集群中的任一节点获取所述隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一可信执行环境产生的第一自荐信息进行验证后生成；密钥获取单元1602，使所述任一节点获取对应于所述隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二可信执行环境内生成，在客户端与所述隐私计算集群中的各节点进行交互以部署或调用智能合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签；发送单元1603，使所述任一节点在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，在所述第二远程证明报告表明所述第二可信执行环境可信的情况下，所述集群身份密钥被所述其他节点认可，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二可信执行环境产生的第二自荐信息进行验证后生成。
可选的，报告获取单元1601具体用于：根据所述认证服务器的公钥对所述第一远程证明报告进行签名验证；在签名验证通过且所述第一远程证明报告包含的远程认证结果为通过认证的情况下，从所述第一远程证明报告携带的所述第一自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第一可信执行环境中预设信息的哈希值；将预先获得的针对所述第一可信执行环境中预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第一可信执行环境可信的前提条件。
可选的，所述任一节点在向所述其他节点发送所述集群身份密钥之前，发送单元1603还用于：使所述任一节点获取所述其他节点提供的第一节点身份信息，并对获取到的第一节点身份信息进行哈希计算以得到第二待校验哈希值，所述第一节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；获取所述其他节点提供的第二标准哈希值，所述第二标准哈希值由所述其他节点在所述第一可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；将所述第二待校验哈希值与所述第二标准哈希值进行比较，并在比较结果一致的情况下获取所述其他节点的节点身份信息中包含的节点身份公钥；采用所述任一节点的节点身份私钥对所述集群身份密钥进行签名，并采用所述其他节点的节点身份公钥对签名后的集群身份密钥进行加密。
可选的，发送单元1603具体用于：所述任一节点向所述其他节点提供第二节点身份信息，所述第二节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息；所述任一节点向所述其他节点提供第三标准哈希值，所述第三标准哈希值由所述任一节点在所述第二可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；其中，在对所述第二节点身份信息进行哈希计算得到的第三待校验哈希值与所述第三标准哈希值一致的情况下，所述其他节点采用所述其他节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述任一节点的节点身份 信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一可信执行环境内维护所述集群身份密钥。
可选的，发送单元1603具体用于：在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标智能合约的情况下，在所述第二可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标智能合约并进行部署；在所述客户端对所述目标智能合约发起调用的情况下，在所述第二可信执行环境中执行所述目标智能合约，并将执行结果反馈至所述客户端。
可选的，所述任一节点在接收到加密后的所述目标智能合约之前，发送单元1603还用于：使所述任一节点响应于所述目标智能合约的部署方发起的挑战，向所述部署方提供所述第二远程证明报告；其中，加密后的所述目标智能合约由所述部署方在根据所述第二远程证明报告确定所述第二可信执行环境可信的情况下发送。
可选的，所述任一节点在将执行结果反馈至所述客户端之前，发送单元1603还用于：使所述任一节点在所述第二可信执行环境内采用所述目标智能合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标智能合约生成。
可选的，生成所述目标智能合约的合约身份密钥的操作包括：在所述第二可信执行环境内采用所述隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标智能合约的全局标识信息生成所述合约身份密钥；其中，所述目标智能合约部署在所述隐私计算集群中的各个节点处。
可选的，在所述客户端对所述目标智能合约发起调用之前，发送单元1603还用于：使所述任一节点向所述目标智能合约的挑战方提供所述集群远程证明报告，所述集群远程证明报告由认证服务器对所述第二自荐信息进行验证后生成；向所述挑战方提供部署于所述任一节点处的所述目标智能合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第二可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名，所述集群身份密钥中的集群身份私钥由所述任一节点维护在所述第二可信执行环境内；所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第二可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标智能合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标智能合约发起调用时，所述目标智能合约由所述任一节点在所述第二可信执行环境中执行。
可选的，所述集群远程证明报告携带的所述第二自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第二可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第二可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第二可信执行环境可信的前提条件。
可选的，发送单元1603还用于：使所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第二可信执行环境内生成所述集群身份信息后对所述集群身份信息进行哈希计算得到；所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集群身份信息中包含的所述集群身份公钥。
可选的，发送单元1603还用于：接收所述客户端对所述目标智能合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述隐私计算集群的控制节点接收，并根据所述隐私计算集群的负载情况转发至所述任一节点；在所述第二可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标智能合约。
在一实施例中，请参考图17，在软件实施方式中，该共享集群密钥的装置可以包括：报告提供单元1701，使隐私计算集群中的任一节点向所述隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一可信执行环境产生的第一自荐信息进行验证后生成；接收单元1702，使所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下发送的对应于所述隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二可信执行环境内生成，在客户端与所述隐私计算集群中的各节点进行交互以部署或调用智能合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二可信执行环境产生的第二自荐信息进行验证后生成；处理单元1703，使所述任一节点在确定出所述第二远程证明报告表明所述第二可信执行环境可信的情况下认可所述集群身份密钥。
可选的，所述任一节点根据所述第二远程证明报告确定所述第二可信执行环境可信的操作包括：根据所述认证服务器的公钥对所述第二远程证明报告进行签名验证；在签名验证通过且所述第二远程证明报告包含的远程认证结果为通过认证的情况下，从所述第二远程证明报告携带的所述第二自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第二可信执行环境中预设信息的哈希值；将预先获得的针对所述第二可信执行环境中预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第二可信执行环境可信的前提条件。
可选的，报告提供单元1701还用于：所述任一节点向所述其他节点提供第一节点身份信息，所述第一节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息，所述第一身份信息被所述其他节点进行哈希计算以得到第二待校验哈希值；所述任一节点向所述其他节点提供第二标准哈希值，所述第二标准哈希值由所述任一节点在所述第一可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；在所述第二标准哈希值与所述第二待校验哈希值一致的情况下，所述集群身份密钥被所述其他节点采用所述其他节点的节点身份私钥进行签名，并采用所述任一节点的节点身份公钥对签名后的集群身份密钥进行加密。
可选的，报告提供单元1701还用于：所述任一节点获取所述其他节点提供的第二节点身份信息，并对所述第二节点身份信息进行哈希计算得到第三待校验哈希值，所述第二节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；所述任一节点获取所述其他节点提供的第三标准哈希值，所述第三标准哈希值由所述其他节点在所述第二可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；所述任一节点在所述第三待校验哈希值和所述第三标准哈希值一致的情况下，采用所述任一节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述其他节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一可信执行环境内维护所述集群身份密钥。
可选的，处理单元1703还用于：在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标智能合约的情况下，在所述第一可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标智能合约并进行部署；在所述客户端对所述目标智能合约发起调用的情况下，在所述第一可信执行环境中执行所述目标智能合约，并将执行结果反馈至所述客户端。
可选的，在接收到加密后的所述目标智能合约之前，报告提供单元1701还用于：使所述任一节点响应于所述目标智能合约的部署方发起的挑战，向所述部署方提供所述第一远程证明报告；其中，加密后的所述目标智能合约由所述部署方在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下发送。
可选的，在将执行结果反馈至所述客户端之前，处理单元1703还用于：使所述任一节点在所述第一可信执行环境内采用所述目标智能合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标智能合约生成。
可选的，所述任一节点生成所述目标智能合约的合约身份密钥的操作包括：在所述第一可信执行环境内采用所述隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标智能合约的全局标识信息生成所述合约身份密钥；其中，所述目标智能合约部署在所述隐私计算集群中的各个节点处。
可选的，在所述客户端对所述目标智能合约发起调用之前，处理单元1703还用于：所述任一节点向所述目标智能合约的挑战方提供所述集群远程证明报告，所述集群远程证明报告由认证服务器对所述第一自荐信息进行验证后生成；向所述挑战方提供部署于所述任一节点处的所述目标智能合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第一可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名；所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第一可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标智能合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标智能合约发起调用时，所述目标智能合约由所述任一节点在所述第一可信执行环境中执行。
可选的，所述集群远程证明报告携带的所述第一自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第一可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第一可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第一可信执行环境可信的前提条件。
可选的，处理单元1703还用于：所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第一可信执行环境内生成所述集群身份信息后对所述集群身份信息进行哈希计算得到；所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集群身份信息中包含的所述集群身份公钥。
可选的，处理单元1703还用于：接收所述客户端对所述目标智能合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述隐私计算集群的控制节点接收，并根据所述隐私计算集群的负载情况转发至所述任一节点；在所述第一可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标智能合约。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、 媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本说明书的实施例可提供为方法、系统、或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备 所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (56)

  1. 一种共享集群密钥的方法，包括：
    链下隐私计算集群中的任一节点获取所述链下隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；
    所述任一节点获取对应于所述链下隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签；
    所述任一节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，在所述第二远程证明报告表明所述第二链下可信执行环境可信的情况下，所述集群身份密钥被所述其他节点认可，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成。
  2. 根据权利要求1所述的方法，所述任一节点根据所述第一远程证明报告确定所述第一链下可信执行环境可信的操作包括：
    根据所述认证服务器的公钥对所述第一远程证明报告进行签名验证；
    在签名验证通过且所述第一远程证明报告包含的远程认证结果为通过认证的情况下，从所述第一远程证明报告携带的所述第一自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第一链下可信执行环境中预设信息的哈希值；
    将预先获得的针对所述第一链下可信执行环境中预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第一链下可信执行环境可信的前提条件。
  3. 根据权利要求1所述的方法，所述任一节点在向所述其他节点发送所述集群身份密钥之前，还包括：
    获取所述其他节点提供的第一节点身份信息，并对获取到的第一节点身份信息进行哈希计算以得到第二待校验哈希值，所述第一节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；
    获取所述其他节点提供的第二标准哈希值，所述第二标准哈希值由所述其他节点在所述第一链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；
    将所述第二待校验哈希值与所述第二标准哈希值进行比较，并在比较结果一致的情况下获取所述其他节点的节点身份信息中包含的节点身份公钥；
    采用所述任一节点的节点身份私钥对所述集群身份密钥进行签名，并采用所述其他节点的节点身份公钥对签名后的集群身份密钥进行加密。
  4. 根据权利要求3所述的方法，还包括：
    所述任一节点向所述其他节点提供第二节点身份信息，所述第二节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息；
    所述任一节点向所述其他节点提供第三标准哈希值，所述第三标准哈希值由所述任一节点在所述第二链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；
    其中，在对所述第二节点身份信息进行哈希计算得到的第三待校验哈希值与所述第三标准哈希值一致的情况下，所述其他节点采用所述其他节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述任一节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一链下可信执行 环境内维护所述集群身份密钥。
  5. 根据权利要求1所述的方法，还包括：
    在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标链下合约的情况下，在所述第二链下可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标链下合约并进行部署；
    在区块链节点通过预言机机制对所述目标链下合约发起调用的情况下，在所述第二链下可信执行环境中执行所述目标链下合约，并通过所述预言机机制将执行结果反馈至所述区块链节点。
  6. 根据权利要求5所述的方法，所述任一节点在接收到加密后的所述目标链下合约之前，还包括：
    响应于所述目标链下合约的部署方发起的挑战，向所述部署方提供所述第二远程证明报告；
    其中，加密后的所述目标链下合约由所述部署方在根据所述第二远程证明报告确定所述第二链下可信执行环境可信的情况下发送。
  7. 根据权利要求5所述的方法，所述任一节点在通过所述预言机机制将执行结果反馈至所述区块链节点之前，还包括：
    在所述第二链下可信执行环境内采用所述目标链下合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标链下合约生成。
  8. 根据权利要求7所述的方法，生成所述目标链下合约的合约身份密钥的操作包括：
    在所述第二链下可信执行环境内采用所述链下隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标链下合约的全局标识信息生成所述合约身份密钥；
    其中，所述目标链下合约部署在所述链下隐私计算集群中的各个节点处。
  9. 根据权利要求5所述的方法，在区块链节点通过预言机机制对所述目标链下合约发起调用之前，所述方法还包括：
    所述任一节点向所述目标链下合约的挑战方提供所述集群远程证明报告，所述集群远程证明报告由认证服务器对所述第二自荐信息进行验证后生成；
    向所述挑战方提供部署于所述任一节点处的所述目标链下合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第二链下可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名，所述集群身份密钥中的集群身份私钥由所述任一节点维护在所述第二链下可信执行环境内；
    所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第二链下可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标链下合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标链下合约发起调用时，所述目标链下合约由所述任一节点在所述第二链下可信执行环境中执行。
  10. 根据权利要求9所述的方法，所述集群远程证明报告携带的所述第二自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第二链下可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第二链下可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第二链 下可信执行环境可信的前提条件。
  11. 根据权利要求9所述的方法，还包括：
    所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；
    所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第二链下可信执行环境内生成所述集群身份信息后对所述集群身份信息进行哈希计算得到；
    所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集群身份信息中包含的所述集群身份公钥。
  12. 根据权利要求9所述的方法，所述挑战方在所述链下隐私计算集群中的每个节点均部署所述目标链下合约后发起挑战，且所发起的挑战由所述链下隐私计算集群的控制节点接收，以及转发至所述任一节点。
  13. 根据权利要求9所述的方法，还包括：
    接收区块链节点通过预言机机制对所述目标链下合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述链下隐私计算集群的控制节点接收，并根据所述链下隐私计算集群的负载情况转发至所述任一节点；
    在所述第二链下可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标链下合约。
  14. 一种共享集群密钥的方法，包括：
    链下隐私计算集群中的任一节点向所述链下隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；
    所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下发送的对应于所述链下隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成；
    所述任一节点在确定出所述第二远程证明报告表明所述第二链下可信执行环境可信的情况下认可所述集群身份密钥。
  15. 根据权利要求14所述的方法，所述任一节点根据所述第二远程证明报告确定所述第二链下可信执行环境可信的操作包括：
    根据所述认证服务器的公钥对所述第二远程证明报告进行签名验证；
    在签名验证通过且所述第二远程证明报告包含的远程认证结果为通过认证的情况下，从所述第二远程证明报告携带的所述第二自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第二链下可信执行环境中预设信息的哈希值；
    将预先获得的针对所述第二链下可信执行环境中预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第二链下可信执行环境可信的前提条件。
  16. 根据权利要求14所述的方法，还包括：
    所述任一节点向所述其他节点提供第一节点身份信息，所述第一节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息，所述第一节点身份信息 被所述其他节点进行哈希计算以得到第二待校验哈希值；
    所述任一节点向所述其他节点提供第二标准哈希值，所述第二标准哈希值由所述任一节点在所述第一链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；
    在所述第二标准哈希值与所述第二待校验哈希值一致的情况下，所述集群身份密钥被所述其他节点采用所述其他节点的节点身份私钥进行签名，并采用所述任一节点的节点身份公钥对签名后的集群身份密钥进行加密。
  17. 根据权利要求16所述的方法，还包括：
    所述任一节点获取所述其他节点提供的第二节点身份信息，并对所述第二节点身份信息进行哈希计算得到第三待校验哈希值，所述第二节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；
    所述任一节点获取所述其他节点提供的第三标准哈希值，所述第三标准哈希值由所述其他节点在所述第二链下可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；
    所述任一节点在所述第三待校验哈希值和所述第三标准哈希值一致的情况下，采用所述任一节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述其他节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一链下可信执行环境内维护所述集群身份密钥。
  18. 根据权利要求14所述的方法，还包括：
    在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标链下合约的情况下，在所述第一链下可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标链下合约并进行部署；
    在区块链节点通过预言机机制对所述目标链下合约发起调用的情况下，在所述第一链下可信执行环境中执行所述目标链下合约，并通过所述预言机机制将执行结果反馈至所述区块链节点。
  19. 根据权利要求18所述的方法，所述任一节点在接收到加密后的所述目标链下合约之前，还包括：
    响应于所述目标链下合约的部署方发起的挑战，向所述部署方提供所述第一远程证明报告；
    其中，加密后的所述目标链下合约由所述部署方在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下发送。
  20. 根据权利要求18所述的方法，所述任一节点在通过所述预言机机制将执行结果反馈至所述区块链节点之前，还包括：
    在所述第一链下可信执行环境内采用所述目标链下合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标链下合约生成。
  21. 根据权利要求20所述的方法，所述任一节点生成所述目标链下合约的合约身份密钥的操作包括：
    在所述第一链下可信执行环境内采用所述链下隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标链下合约的全局标识信息生成所述合约身份密钥；
    其中，所述目标链下合约部署在所述链下隐私计算集群中的各个节点处。
  22. 根据权利要求18所述的方法，在区块链节点通过预言机机制对所述目标链下合约发起调用之前，所述方法还包括：
    所述任一节点向所述目标链下合约的挑战方提供所述集群远程证明报告，所述集群 远程证明报告由认证服务器对所述第一自荐信息进行验证后生成；
    向所述挑战方提供部署于所述任一节点处的所述目标链下合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第一链下可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名；
    所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第一链下可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标链下合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标链下合约发起调用时，所述目标链下合约由所述任一节点在所述第一链下可信执行环境中执行。
  23. 根据权利要求22所述的方法，所述集群远程证明报告携带的所述第一自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第一链下可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第一链下可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第一链下可信执行环境可信的前提条件。
  24. 根据权利要求22所述的方法，还包括：
    所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；
    所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第一链下可信执行环境内生成所述集群身份信息后对所述集群身份信息进行哈希计算得到；
    所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集群身份信息中包含的所述集群身份公钥。
  25. 根据权利要求22所述的方法，所述挑战方在所述链下隐私计算集群中的每个节点均部署所述目标链下合约后发起挑战，且所发起的挑战由所述链下隐私计算集群的控制节点接收，以及转发至所述任一节点。
  26. 根据权利要求22所述的方法，还包括：
    接收区块链节点通过预言机机制对所述目标链下合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述链下隐私计算集群的控制节点接收，并根据所述链下隐私计算集群的负载情况转发至所述任一节点；
    在所述第一链下可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标链下合约。
  27. 一种共享集群密钥的方法，包括：
    隐私计算集群中的任一节点获取所述隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一可信执行环境产生的第一自荐信息进行验证后生成；
    所述任一节点获取对应于所述隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二可信执行环境内生成，在客户端与所述隐私计算集群中的各节点进行交互以部署或调用智能合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签；
    所述任一节点在根据所述第一远程证明报告确定所述第一可信执行环境可信的情 况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，在所述第二远程证明报告表明所述第二可信执行环境可信的情况下，所述集群身份密钥被所述其他节点认可，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二可信执行环境产生的第二自荐信息进行验证后生成。
  28. 根据权利要求27所述的方法，所述任一节点根据所述第一远程证明报告确定所述第一可信执行环境可信的操作包括：
    根据所述认证服务器的公钥对所述第一远程证明报告进行签名验证；
    在签名验证通过且所述第一远程证明报告包含的远程认证结果为通过认证的情况下，从所述第一远程证明报告携带的所述第一自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第一可信执行环境中预设信息的哈希值；
    将预先获得的针对所述第一可信执行环境中预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第一可信执行环境可信的前提条件。
  29. 根据权利要求27所述的方法，所述任一节点在向所述其他节点发送所述集群身份密钥之前，还包括：
    获取所述其他节点提供的第一节点身份信息，并对获取到的第一节点身份信息进行哈希计算以得到第二待校验哈希值，所述第一节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；
    获取所述其他节点提供的第二标准哈希值，所述第二标准哈希值由所述其他节点在所述第一可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；
    将所述第二待校验哈希值与所述第二标准哈希值进行比较，并在比较结果一致的情况下获取所述其他节点的节点身份信息中包含的节点身份公钥；
    采用所述任一节点的节点身份私钥对所述集群身份密钥进行签名，并采用所述其他节点的节点身份公钥对签名后的集群身份密钥进行加密。
  30. 根据权利要求29所述的方法，还包括：
    所述任一节点向所述其他节点提供第二节点身份信息，所述第二节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息；
    所述任一节点向所述其他节点提供第三标准哈希值，所述第三标准哈希值由所述任一节点在所述第二可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；
    其中，在对所述第二节点身份信息进行哈希计算得到的第三待校验哈希值与所述第三标准哈希值一致的情况下，所述其他节点采用所述其他节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述任一节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证通过的情况下在所述第一可信执行环境内维护所述集群身份密钥。
  31. 根据权利要求27所述的方法，还包括：
    在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标智能合约的情况下，在所述第二可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标智能合约并进行部署；
    在所述客户端对所述目标智能合约发起调用的情况下，在所述第二可信执行环境中执行所述目标智能合约，并将执行结果反馈至所述客户端。
  32. 根据权利要求31所述的方法，所述任一节点在接收到加密后的所述目标智能合约之前，还包括：
    响应于所述目标智能合约的部署方发起的挑战，向所述部署方提供所述第二远程证明报告；
    其中，加密后的所述目标智能合约由所述部署方在根据所述第二远程证明报告确定所述第二可信执行环境可信的情况下发送。
  33. 根据权利要求31所述的方法，所述任一节点在将执行结果反馈至所述客户端之前，还包括：
    在所述第二可信执行环境内采用所述目标智能合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标智能合约生成。
  34. 根据权利要求33所述的方法，生成所述目标智能合约的合约身份密钥的操作包括：
    在所述第二可信执行环境内采用所述隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标智能合约的全局标识信息生成所述合约身份密钥；
    其中，所述目标智能合约部署在所述隐私计算集群中的各个节点处。
  35. 根据权利要求31所述的方法，在所述客户端对所述目标智能合约发起调用之前，所述方法还包括：
    所述任一节点向所述目标智能合约的挑战方提供所述集群远程证明报告，所述集群远程证明报告由认证服务器对所述第二自荐信息进行验证后生成；
    向所述挑战方提供部署于所述任一节点处的所述目标智能合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第二可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名，所述集群身份密钥中的集群身份私钥由所述任一节点维护在所述第二可信执行环境内；
    所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第二可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标智能合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标智能合约发起调用时，所述目标智能合约由所述任一节点在所述第二可信执行环境中执行。
  36. 根据权利要求35所述的方法，所述集群远程证明报告携带的所述第二自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第二可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第二可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第二可信执行环境可信的前提条件。
  37. 根据权利要求35所述的方法，还包括：
    所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；
    所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第二可信执行环境内生成所述集群身份信息后对所述集群身份信息进行哈希计算得到；
    所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集群身份信息中包含的所述集群身份公钥。
  38. 根据权利要求35所述的方法，还包括：
    接收所述客户端对所述目标智能合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述隐私计算集群的控制节点接收，并根据所述隐私计算集群的负载情况转发至所述任一节点；
    在所述第二可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标智能合约。
  39. 一种共享集群密钥的方法，包括：
    隐私计算集群中的任一节点向所述隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一可信执行环境产生的第一自荐信息进行验证后生成；
    所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下发送的对应于所述隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二可信执行环境内生成，在客户端与所述隐私计算集群中的各节点进行交互以部署或调用智能合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二可信执行环境产生的第二自荐信息进行验证后生成；
    所述任一节点在确定出所述第二远程证明报告表明所述第二可信执行环境可信的情况下认可所述集群身份密钥。
  40. 根据权利要求39所述的方法，所述任一节点根据所述第二远程证明报告确定所述第二可信执行环境可信的操作包括：
    根据所述认证服务器的公钥对所述第二远程证明报告进行签名验证；
    在签名验证通过且所述第二远程证明报告包含的远程认证结果为通过认证的情况下，从所述第二远程证明报告携带的所述第二自荐信息内提取出第一待检验哈希值，所述第一待检验哈希值为所述第二可信执行环境中预设信息的哈希值；
    将预先获得的针对所述第二可信执行环境中预设信息的第一标准哈希值与所述第一待检验哈希值进行比较，并将比较结果一致作为确认所述第二可信执行环境可信的前提条件。
  41. 根据权利要求39所述的方法，还包括：
    所述任一节点向所述其他节点提供第一节点身份信息，所述第一节点身份信息包含所述任一节点的节点身份公钥和所述任一节点的其他身份信息，所述第一节点身份信息被所述其他节点进行哈希计算以得到第二待校验哈希值；
    所述任一节点向所述其他节点提供第二标准哈希值，所述第二标准哈希值由所述任一节点在所述第一可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；
    在所述第二标准哈希值与所述第二待校验哈希值一致的情况下，所述集群身份密钥被所述其他节点采用所述其他节点的节点身份私钥进行签名，并采用所述任一节点的节点身份公钥对签名后的集群身份密钥进行加密。
  42. 根据权利要求41所述的方法，还包括：
    所述任一节点获取所述其他节点提供的第二节点身份信息，并对所述第二节点身份信息进行哈希计算得到第三待校验哈希值，所述第二节点身份信息包含所述其他节点的节点身份公钥和所述其他节点的其他身份信息；
    所述任一节点获取所述其他节点提供的第三标准哈希值，所述第三标准哈希值由所述其他节点在所述第二可信执行环境内生成自身的节点身份信息后对生成的节点身份信息进行哈希计算得到；
    所述任一节点在所述第三待校验哈希值和所述第三标准哈希值一致的情况下，采用所述任一节点的节点身份私钥对接收到的集群身份密钥进行解密，以及采用所述其他节点的节点身份信息中包含的节点身份公钥验证所述集群身份密钥的签名，并在签名验证 通过的情况下在所述第一可信执行环境内维护所述集群身份密钥。
  43. 根据权利要求39所述的方法，还包括：
    在接收到被采用所述集群身份密钥中的集群身份公钥加密后的目标智能合约的情况下，在所述第一可信执行环境中通过所述集群身份密钥中的集群身份私钥解密所述目标智能合约并进行部署；
    在所述客户端对所述目标智能合约发起调用的情况下，在所述第一可信执行环境中执行所述目标智能合约，并将执行结果反馈至所述客户端。
  44. 根据权利要求43所述的方法，所述任一节点在接收到加密后的所述目标智能合约之前，还包括：
    响应于所述目标智能合约的部署方发起的挑战，向所述部署方提供所述第一远程证明报告；
    其中，加密后的所述目标智能合约由所述部署方在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下发送。
  45. 根据权利要求43所述的方法，所述任一节点在将执行结果反馈至所述客户端之前，还包括：
    在所述第一可信执行环境内采用所述目标智能合约的合约身份密钥中的合约身份私钥对所述执行结果进行签名，签名后的所述执行结果在采用所述合约身份密钥中的合约身份公钥对所述执行结果进行签名验证且通过签名验证的情况下，被判定由所述目标智能合约生成。
  46. 根据权利要求45所述的方法，所述任一节点生成所述目标智能合约的合约身份密钥的操作包括：
    在所述第一可信执行环境内采用所述隐私计算集群内各节点之间共用的密钥生成算法，基于所述集群身份密钥和所述目标智能合约的全局标识信息生成所述合约身份密钥；
    其中，所述目标智能合约部署在所述隐私计算集群中的各个节点处。
  47. 根据权利要求43所述的方法，在所述客户端对所述目标智能合约发起调用之前，所述方法还包括：
    所述任一节点向所述目标智能合约的挑战方提供所述集群远程证明报告，所述集群远程证明报告由认证服务器对所述第一自荐信息进行验证后生成；
    向所述挑战方提供部署于所述任一节点处的所述目标智能合约的待验证合约信息，所述待验证合约信息被所述任一节点在所述第一可信执行环境内采用所述集群身份密钥中的集群身份私钥进行签名；
    所述待验证合约信息由所述挑战方在根据所述集群远程证明报告确定所述第一可信执行环境可信的情况下，采用所述集群身份密钥中的集群身份公钥对所述待验证合约信息进行签名验证，以及根据所述目标智能合约的合约信息对所述待验证合约信息进行合约信息验证，并在签名验证和合约信息验证通过的情况下，确定所述挑战方在通过区块链节点的预言机机制对所述目标智能合约发起调用时，所述目标智能合约由所述任一节点在所述第一可信执行环境中执行。
  48. 根据权利要求47所述的方法，所述集群远程证明报告携带的所述第一自荐信息内包含第四待检验哈希值，所述第四待检验哈希值为所述第一可信执行环境的预设信息的哈希值，所述第四待检验哈希值用于所述挑战方在根据所述认证服务器的公钥对所述集群远程证明报告进行签名验证并签名验证通过，且所述集群远程证明报告包含的远程认证结果为通过认证的情况下，与预先获得的针对所述第一可信执行环境中预设信息的第四标准哈希值进行比较，且比较结果一致被作为所述挑战方确认所述第一可信执行环境可信的前提条件。
  49. 根据权利要求47所述的方法，还包括：
    所述任一节点向所述挑战方提供集群身份信息，所述集群身份信息中包含集群身份密钥中的集群身份公钥和所述任一节点的节点身份信息中除所述任一节点的节点身份公钥以外的其他身份信息，所述集群身份信息被所述挑战方进行哈希计算以得到第五待校验哈希值；
    所述任一节点向所述挑战方提供第五标准哈希值，所述第五标准哈希值由所述任一节点在所述第一可信执行环境内生成所述集群身份信息后对所述集群身份信息进行哈希计算得到；
    所述第五标准哈希值用于与所述第五待校验哈希值进行比较，且所述挑战方在比较结果一致的情况下获取所述集群身份信息中包含的所述集群身份公钥。
  50. 根据权利要求47所述的方法，还包括：
    接收所述客户端对所述目标智能合约发起的调用交易，所述调用交易被采用所述集群身份密钥中的集群身份公钥进行加密，所述调用交易由所述隐私计算集群的控制节点接收，并根据所述隐私计算集群的负载情况转发至所述任一节点；
    在所述第一可信执行环境内采用所述集群身份密钥中的集群身份私钥对所述调用交易进行解密，以响应于解密后的调用交易执行所述目标智能合约。
  51. 一种共享集群密钥的装置，包括：
    报告获取单元，使链下隐私计算集群中的任一节点获取所述链下隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；
    密钥获取单元，使所述任一节点获取对应于所述链下隐私计算集群的集群身份密钥，所述集群身份密钥在所述任一节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签；
    发送单元，使所述任一节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，在所述第二远程证明报告表明所述第二链下可信执行环境可信的情况下，所述集群身份密钥被所述其他节点认可，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成。
  52. 一种共享集群密钥的装置，包括：
    报告提供单元，使链下隐私计算集群中的任一节点向所述链下隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一链下可信执行环境产生的第一自荐信息进行验证后生成；
    接收单元，使所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一链下可信执行环境可信的情况下发送的对应于所述链下隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二链下可信执行环境内生成，在区块链节点与所述链下隐私计算集群中的各节点进行交互以部署或调用链下合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二链下可信执行环境产生的第二自荐信息进行验证后生成；
    处理单元，使所述任一节点在确定出所述第二远程证明报告表明所述第二链下可信执行环境可信的情况下认可所述集群身份密钥。
  53. 一种共享集群密钥的装置，包括：
    报告获取单元，使隐私计算集群中的任一节点获取所述隐私计算集群中其他节点发送的第一远程证明报告，所述第一远程证明报告由认证服务器对所述其他节点针对创建的第一可信执行环境产生的第一自荐信息进行验证后生成；
    密钥获取单元，使所述任一节点获取对应于所述隐私计算集群的集群身份密钥，所 述集群身份密钥在所述任一节点创建的第二可信执行环境内生成，在客户端与所述隐私计算集群中的各节点进行交互以部署或调用智能合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签；
    发送单元，使所述任一节点在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下，向所述其他节点发送所述集群身份密钥和第二远程证明报告，在所述第二远程证明报告表明所述第二可信执行环境可信的情况下，所述集群身份密钥被所述其他节点认可，所述第二远程证明报告由认证服务器对所述任一节点针对所述第二可信执行环境产生的第二自荐信息进行验证后生成。
  54. 一种共享集群密钥的装置，包括：
    报告提供单元，使隐私计算集群中的任一节点向所述隐私计算集群中其他节点提供第一远程证明报告，所述第一远程证明报告由认证服务器对所述任一节点针对创建的第一可信执行环境产生的第一自荐信息进行验证后生成；
    接收单元，使所述任一节点接收所述其他节点在根据所述第一远程证明报告确定所述第一可信执行环境可信的情况下发送的对应于所述隐私计算集群的集群身份密钥和第二远程证明报告，所述集群身份密钥在所述其他节点创建的第二可信执行环境内生成，在客户端与所述隐私计算集群中的各节点进行交互以部署或调用智能合约的过程中，所述集群身份密钥用于对交互数据进行加密解密和/或签名验签，所述第二远程证明报告由认证服务器对所述其他节点针对所述第二可信执行环境产生的第二自荐信息进行验证后生成；
    处理单元，使所述任一节点在确定出所述第二远程证明报告表明所述第二可信执行环境可信的情况下认可所述集群身份密钥。
  55. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求1-50中任一项所述的方法。
  56. 一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如权利要求1-50中任一项所述方法的步骤。
PCT/CN2021/073946 2020-03-18 2021-01-27 共享集群密钥的方法及装置 WO2021184968A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010191189.2A CN111092727B (zh) 2020-03-18 2020-03-18 共享集群密钥的方法及装置
CN202010191189.2 2020-03-18

Publications (1)

Publication Number Publication Date
WO2021184968A1 true WO2021184968A1 (zh) 2021-09-23

Family

ID=70400544

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/073946 WO2021184968A1 (zh) 2020-03-18 2021-01-27 共享集群密钥的方法及装置

Country Status (2)

Country Link
CN (2) CN111092727B (zh)
WO (1) WO2021184968A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113761582A (zh) * 2021-09-29 2021-12-07 山东省计算中心（国家超级计算济南中心） 基于群签名的可监管区块链交易隐私保护方法及系统
CN114422215A (zh) * 2021-12-31 2022-04-29 国网安徽省电力有限公司合肥供电公司 一种基于区块链的跨平台和可信能源数据共享系统及方法
CN114553590A (zh) * 2022-03-17 2022-05-27 北京字节跳动网络技术有限公司 数据传输方法及相关设备
CN115021939A (zh) * 2022-06-30 2022-09-06 中国联合网络通信集团有限公司 身份认证方法、装置、设备及存储介质
CN115412275A (zh) * 2022-05-23 2022-11-29 蚂蚁区块链科技(上海)有限公司 一种基于可信执行环境的隐私计算系统及方法
CN117176346A (zh) * 2023-11-01 2023-12-05 中电信量子科技有限公司 分布式量子密钥链路控制方法及密钥管理系统

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111092727B (zh) * 2020-03-18 2020-07-17 支付宝(杭州)信息技术有限公司 共享集群密钥的方法及装置
CN111669434B (zh) * 2020-05-18 2023-07-04 支付宝实验室(新加坡)有限公司 一种通信群组的建立方法、系统、装置及设备
CN111740838B (zh) * 2020-05-22 2023-04-07 上海链民信息科技有限公司 一种区块链数据可信上链方法及系统
CN112087304B (zh) * 2020-09-18 2021-08-17 湖南红普创新科技发展有限公司 可信计算环境的异构融合方法、装置及相关设备
CN112465501B (zh) * 2020-11-11 2023-07-14 中国人民大学 基于区块链的版权存证及侵权行为自动取证的方法及系统
CN112507340B (zh) * 2020-11-30 2023-01-31 国家电网有限公司信息通信分公司 用于能源互联网节点的可信验证的系统、方法和存储介质
CN114598484B (zh) * 2020-12-01 2024-03-19 中移(苏州)软件技术有限公司 一种证书更新方法、装置、集群及存储介质
CN112910989B (zh) * 2021-01-28 2022-09-02 浙江网商银行股份有限公司 基于区块链的数据处理系统、方法及装置
CN112861155A (zh) * 2021-02-25 2021-05-28 浙江清华长三角研究院 一种在去中心计算场景的公钥发布方法
CN112926051B (zh) * 2021-03-25 2022-05-06 支付宝(杭州)信息技术有限公司 多方安全计算方法和装置
CN113761496B (zh) * 2021-10-21 2024-04-09 支付宝(杭州)信息技术有限公司 一种基于区块链的身份校验方法及装置和电子设备
CN114117522A (zh) * 2021-11-23 2022-03-01 上海交通大学 基于区块链和可信执行环境的车联网数据共享实现方法
CN114884714B (zh) * 2022-04-26 2024-03-26 北京百度网讯科技有限公司 任务处理方法、装置、设备及存储介质
CN114584307B (zh) * 2022-05-07 2022-09-02 腾讯科技（深圳）有限公司 一种可信密钥管理方法、装置、电子设备和存储介质
CN115576958B (zh) * 2022-12-08 2023-03-07 杭银消费金融股份有限公司 一种生产设备监管报表的数据校验方法、设备及介质
CN116192392B (zh) * 2023-02-15 2023-11-24 南京航空航天大学 一种基于椭圆曲线的具有隐私保护的轻量级匿名认证方法
CN116405929B (zh) * 2023-06-09 2023-08-15 贵州联广科技股份有限公司 适用于集群通讯的安全访问处理方法及系统
CN117235693B (zh) * 2023-11-14 2024-02-02 杭州安恒信息技术股份有限公司 一种可信执行环境的可信认证和安全通道建立方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109861980A (zh) * 2018-12-29 2019-06-07 阿里巴巴集团控股有限公司 一种建立可信计算集群的方法和装置
WO2019137565A2 (en) * 2019-04-26 2019-07-18 Alibaba Group Holding Limited Distributed key management for trusted execution environments
US20190220603A1 (en) * 2019-03-27 2019-07-18 Intel Corporation Fast and secure protocol to bootstrap a blockchain by restoring the blockchain state using trusted execution environment
CN111092727A (zh) * 2020-03-18 2020-05-01 支付宝(杭州)信息技术有限公司 共享集群密钥的方法及装置
CN111092726A (zh) * 2020-03-18 2020-05-01 支付宝(杭州)信息技术有限公司 生成共享合约密钥的方法及装置
CN111090888A (zh) * 2020-03-18 2020-05-01 支付宝(杭州)信息技术有限公司 验证合约的方法及装置

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8799451B2 (en) * 2009-01-28 2014-08-05 Headwater Partners I Llc Verifiable service policy implementation for intermediate networking devices
US10860951B2 (en) * 2015-10-28 2020-12-08 Qomplx, Inc. System and method for removing biases within a distributable model
US10498541B2 (en) * 2017-02-06 2019-12-03 ShocCard, Inc. Electronic identification verification methods and systems
DE102018101307A1 (de) * 2017-02-22 2018-08-23 Intel Corporation Techniken für SGX-Enklaven-Fernauthentifizierung
GB201707788D0 (en) * 2017-05-15 2017-06-28 Nchain Holdings Ltd Computer-implemented system and method
US10567359B2 (en) * 2017-07-18 2020-02-18 International Business Machines Corporation Cluster of secure execution platforms
US10554634B2 (en) * 2017-08-18 2020-02-04 Intel Corporation Techniques for shared private data objects in a trusted execution environment
US20190065406A1 (en) * 2017-11-17 2019-02-28 Intel Corporation Technology For Establishing Trust During A Transport Layer Security Handshake
CN110011801B (zh) * 2018-11-16 2020-10-20 创新先进技术有限公司 可信应用程序的远程证明方法及装置、电子设备
WO2019072297A2 (en) * 2018-12-13 2019-04-18 Alibaba Group Holding Limited INTELLIGENT CONTRACT SERVICE OUTSIDE CHAIN REGISTRY ("OFF-CHAIN") BASED ON A CONFIDENTIAL EXECUTION ENVIRONMENT
CN109474430B (zh) * 2019-01-10 2022-03-22 四川虹微技术有限公司 一种集群密钥生成方法、装置及其存储介质
CN109561110B (zh) * 2019-01-19 2021-06-04 北京工业大学 一种基于sgx的云平台审计日志保护方法
CN111614464B (zh) * 2019-01-31 2023-09-29 创新先进技术有限公司 区块链中安全更新密钥的方法及节点、存储介质
WO2019179543A2 (en) * 2019-03-27 2019-09-26 Alibaba Group Holding Limited Retrieving public data for blockchain networks using trusted execution environments
CN110750803B (zh) * 2019-10-18 2021-04-09 支付宝(杭州)信息技术有限公司 数据提供和融合的方法及装置
CN111523110B (zh) * 2019-11-08 2023-05-02 支付宝(杭州)信息技术有限公司 基于链代码的权限查询配置方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109861980A (zh) * 2018-12-29 2019-06-07 阿里巴巴集团控股有限公司 一种建立可信计算集群的方法和装置
US20190220603A1 (en) * 2019-03-27 2019-07-18 Intel Corporation Fast and secure protocol to bootstrap a blockchain by restoring the blockchain state using trusted execution environment
WO2019137565A2 (en) * 2019-04-26 2019-07-18 Alibaba Group Holding Limited Distributed key management for trusted execution environments
CN111092727A (zh) * 2020-03-18 2020-05-01 支付宝(杭州)信息技术有限公司 共享集群密钥的方法及装置
CN111092726A (zh) * 2020-03-18 2020-05-01 支付宝(杭州)信息技术有限公司 生成共享合约密钥的方法及装置
CN111090888A (zh) * 2020-03-18 2020-05-01 支付宝(杭州)信息技术有限公司 验证合约的方法及装置

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113761582A (zh) * 2021-09-29 2021-12-07 山东省计算中心（国家超级计算济南中心） 基于群签名的可监管区块链交易隐私保护方法及系统
CN113761582B (zh) * 2021-09-29 2023-06-16 山东省计算中心（国家超级计算济南中心） 基于群签名的可监管区块链交易隐私保护方法及系统
CN114422215A (zh) * 2021-12-31 2022-04-29 国网安徽省电力有限公司合肥供电公司 一种基于区块链的跨平台和可信能源数据共享系统及方法
CN114553590A (zh) * 2022-03-17 2022-05-27 北京字节跳动网络技术有限公司 数据传输方法及相关设备
CN114553590B (zh) * 2022-03-17 2023-08-22 抖音视界有限公司 数据传输方法及相关设备
CN115412275A (zh) * 2022-05-23 2022-11-29 蚂蚁区块链科技(上海)有限公司 一种基于可信执行环境的隐私计算系统及方法
CN115021939A (zh) * 2022-06-30 2022-09-06 中国联合网络通信集团有限公司 身份认证方法、装置、设备及存储介质
CN115021939B (zh) * 2022-06-30 2024-04-09 中国联合网络通信集团有限公司 身份认证方法、装置、设备及存储介质
CN117176346A (zh) * 2023-11-01 2023-12-05 中电信量子科技有限公司 分布式量子密钥链路控制方法及密钥管理系统
CN117176346B (zh) * 2023-11-01 2024-03-08 中电信量子科技有限公司 分布式量子密钥链路控制方法及密钥管理系统

Also Published As

Publication number Publication date
CN111988141B (zh) 2022-08-02
CN111988141A (zh) 2020-11-24
CN111092727A (zh) 2020-05-01
CN111092727B (zh) 2020-07-17

Similar Documents

Publication Publication Date Title
WO2021184968A1 (zh) 共享集群密钥的方法及装置
WO2021184882A1 (zh) 验证合约的方法及装置
WO2021184962A1 (zh) 生成共享合约密钥的方法及装置
WO2021184961A1 (zh) 部署合约的方法及装置
WO2021184973A1 (zh) 访问外部数据的方法及装置
WO2021184970A1 (zh) 调用合约的方法及装置
WO2021184963A1 (zh) 调用合约的方法及装置
WO2021184975A1 (zh) 链上数据的链下隐私计算方法及装置
CN110580413B (zh) 基于链下授权的隐私数据查询方法及装置
CN110580418B (zh) 基于区块链账户的隐私数据查询方法及装置
CN110580262B (zh) 基于智能合约的隐私数据查询方法及装置
CN110580412B (zh) 基于链代码的权限查询配置方法及装置
WO2021073170A1 (zh) 数据提供和融合的方法及装置
CN110580245B (zh) 隐私数据的共享方法及装置
CN111475829A (zh) 基于区块链账户的隐私数据查询方法及装置
CN110580411B (zh) 基于智能合约的权限查询配置方法及装置
CN114866409B (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: 21772616

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

Country of ref document: EP

Kind code of ref document: A1