CN111090888B

CN111090888B - Contract verification method and device

Info

Publication number: CN111090888B
Application number: CN202010191188.8A
Authority: CN
Inventors: 吴因佥; 邱鸿霖; 吴行行
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-03-18
Filing date: 2020-03-18
Publication date: 2020-07-07
Anticipated expiration: 2040-03-18
Also published as: CN111090888A; WO2021184882A1

Abstract

This specification provides a method and apparatus for verifying contracts, the method comprising: obtaining a remote attestation report of an under-link trusted execution environment created by an under-link privacy computing node; when determining that the under-chain trusted execution environment is trusted according to the remote certification report, acquiring contract information to be verified of a target under-chain contract deployed at the node, wherein the contract information to be verified is signed by the node in the under-chain trusted execution environment by using an identity private key of the node, and the identity private key is maintained by the node in the under-chain trusted execution environment; and under the condition that the signature verification and the contract information verification pass, determining that the target under-chain contract is executed by the node in an under-chain trusted execution environment when the target under-chain contract is invoked through a preplan mechanism. The scheme can ensure data security and privacy protection.

Description

Contract verification method and device

Technical Field

One or more embodiments of the present disclosure relate to the field of verifiable computing technologies, and in particular, to a method and an apparatus for verifying a contract.

Background

In the related art, one way to meet privacy requirements in various scenarios is to implement privacy protection through encryption technologies such as Homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledge proof), which also brings serious performance loss. A Trusted Execution Environment (TEE) is another solution. The TEE can play a role of a black box in hardware, a code and data operating system layer executed in the TEE cannot be peeped, and the TEE can be operated only through an interface defined in advance in the code. In terms of efficiency, due to the black-box nature of the TEE, plaintext data is operated on in the TEE, rather than complex cryptographic operations in homomorphic encryption, and computational process efficiency is not lost.

Disclosure of Invention

In view of the above, one or more embodiments of the present disclosure provide a method and an apparatus for verifying a contract, which can securely implement operations of verifying a contract in a chained environment.

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

according to a first aspect of one or more embodiments of the present specification, there is provided a method of validating a contract, comprising:

the method comprises the steps that a client side obtains a remote attestation report of a chain lower trusted execution environment created by a chain lower privacy computing node, and the remote attestation report is generated after an authentication server verifies self-recommendation information generated by the chain lower privacy computing node aiming at the chain lower trusted execution environment;

the client acquires contract information to be verified of a target under-chain contract deployed at the under-chain private computing node under the condition that the under-chain trusted execution environment is determined to be trusted according to the remote attestation report, wherein the contract information to be verified is signed by the under-chain private computing node in the under-chain trusted execution environment by using a node identity private key of the under-chain private computing node, and the node identity private key is generated by the under-chain private computing node in the under-chain trusted execution environment;

the client performs signature verification on the contract information to be verified by using the node identity public key of the private computation node under the chain, performs contract information verification on the contract information to be verified according to the contract information of the contract under the target chain, and determines that the contract under the target chain is executed by the private computation node under the chain in the trusted execution environment under the chain when the client initiates calling on the contract under the target chain through a preplanning machine mechanism of the block chain node under the condition that the signature verification and the contract information verification pass.

According to a second aspect of one or more embodiments of the present specification, there is provided a method of validating a contract, comprising:

the method comprises the steps that a chain down privacy computing node provides a remote attestation report of a chain down trusted execution environment created by the chain down privacy computing node to a client, and the remote attestation report is generated after verification of self-recommendation information generated by the chain down privacy computing node aiming at the chain down trusted execution environment is carried out by an authentication server;

the under-chain privacy computing node providing, to the client, contract information to be verified for a target under-chain contract deployed at the under-chain privacy computing node, the contract information to be verified being signed by the under-chain privacy computing node within the under-chain trusted execution environment using a node identity private key of the under-chain privacy computing node, the node identity private key being generated by the under-chain privacy computing node within the under-chain trusted execution environment;

and under the condition that the client determines that the under-chain trusted execution environment is trusted according to the remote certification report, the client performs signature verification on the contract information to be verified by adopting the node identity public key of the under-chain private computation node, performs contract information verification on the contract information to be verified according to the contract information of the target under-chain contract, and under the condition that the signature verification and the contract information verification pass, determines that the target under-chain contract is executed in the under-chain trusted execution environment by the under-chain private computation node when the client initiates calling on the target under-chain contract through a language predictor mechanism of a block chain node.

According to a third aspect of one or more embodiments of the present specification, there is provided a method of validating a contract, comprising:

the method comprises the steps that a client side obtains a remote attestation report of a trusted execution environment created aiming at a private computing node, and the remote attestation report is generated after an authentication server verifies self-recommendation information generated by the private computing node aiming at the trusted execution environment;

the client acquires contract information to be verified of a target intelligent contract deployed at the private computing node under the condition that the trusted execution environment is determined to be trusted according to the remote attestation report, wherein the contract information to be verified is signed by the private computing node in the trusted execution environment by adopting an identity private key of the private computing node, and the identity private key is maintained by the private computing node in the trusted execution environment;

the client performs signature verification on the contract information to be verified by adopting the identity public key of the privacy computing node, performs contract information verification on the contract information to be verified according to the contract information of the target intelligent contract, and determines that the target intelligent contract is executed in the trusted execution environment by the privacy computing node when the client initiates calling on the target intelligent contract under the condition that the signature verification and the contract information verification pass.

According to a fourth aspect of one or more embodiments of the present specification, there is provided a method of validating a contract, comprising:

a privacy computing node provides a remote attestation report of a trusted execution environment created by the privacy computing node to a client, wherein the remote attestation report is generated by an authentication server after verification of self-recommendation information generated by the privacy computing node for the trusted execution environment;

the private computing node providing to the client to-be-verified contract information for a target intelligent contract deployed at the private computing node, the to-be-verified contract information being signed by the private computing node within the trusted execution environment with a private identity key of the private computing node, the private identity key being maintained by the private computing node within the trusted execution environment;

and the client side adopts the identity public key of the private computing node to carry out signature verification on the contract information to be verified under the condition that the trusted execution environment is determined to be trusted according to the remote certification report, carries out contract information verification on the contract information to be verified according to the contract information of the target intelligent contract, and determines that the target intelligent contract is executed in the trusted execution environment by the private computing node when the client side initiates calling on the target intelligent contract under the condition that the signature verification and the contract information verification pass.

According to a fifth aspect of one or more embodiments of the present specification, there is provided an apparatus for validating a contract, comprising:

the report acquisition unit enables a client to acquire a remote attestation report of a linked trusted execution environment created by a linked privacy computing node, wherein the remote attestation report is generated by verifying self-recommendation information generated by the linked privacy computing node aiming at the linked trusted execution environment by an authentication server;

a contract information obtaining unit, configured to, when the client determines that the under-chain trusted execution environment is trusted according to the remote attestation report, obtain contract information to be verified, which is to be contracted under a target under-chain deployed at the under-chain private computing node, where the contract information to be verified is signed by the under-chain private computing node in the under-chain trusted execution environment using a node identity private key of the under-chain private computing node, where the node identity private key is generated by the under-chain private computing node in the under-chain trusted execution environment;

and the verification unit enables the client to perform signature verification on the contract information to be verified by adopting the node identity public key of the private calculation node under the chain, performs contract information verification on the contract information to be verified according to the contract information of the contract under the target chain, and determines that the contract under the target chain is executed by the private calculation node under the chain in a trusted execution environment under the chain when the client initiates calling on the contract under the target chain through a preplanning mechanism of the block chain node under the condition that the signature verification and the contract information verification pass.

According to a sixth aspect of one or more embodiments of the present specification, there is provided an apparatus for validating a contract, comprising:

a report providing unit, which enables a chain privacy computing node to provide a remote attestation report of a chain trusted execution environment created by the chain privacy computing node to a client, wherein the remote attestation report is generated by an authentication server after verification of self-recommendation information generated by the chain privacy computing node for the chain trusted execution environment;

a contract information providing unit that causes the private computing node to provide, to the client, contract information to be verified for a target private chain contract deployed at the private computing node, the contract information to be verified being signed by the private computing node within the trusted execution environment under the chain using a node identity private key of the private computing node under the chain, the node identity private key being generated by the private computing node under the chain within the trusted execution environment under the chain;

According to a seventh aspect of one or more embodiments of the present specification, there is provided an apparatus for validating a contract, comprising:

the report acquisition unit enables a client to acquire a remote attestation report of a trusted execution environment created by a private computing node, wherein the remote attestation report is generated by verifying self-recommendation information generated by the private computing node aiming at the trusted execution environment through an authentication server;

a contract information obtaining unit, configured to enable the client to obtain to-be-verified contract information of a target intelligent contract deployed at the private computing node in a case that the trusted execution environment is determined to be trusted according to the remote attestation report, where the to-be-verified contract information is signed by the private computing node in the trusted execution environment by using an identity private key of the private computing node, and the identity private key is maintained by the private computing node in the trusted execution environment;

and the verification unit enables the client to adopt the identity public key of the privacy computing node to carry out signature verification on the contract information to be verified, carry out contract information verification on the contract information to be verified according to the contract information of the target intelligent contract, and determine that the target intelligent contract is executed in the trusted execution environment by the privacy computing node when the client initiates calling on the target intelligent contract under the condition that the signature verification and the contract information verification pass.

According to an eighth aspect of one or more embodiments of the present specification, there is provided an apparatus for validating a contract, comprising:

a report providing unit, which enables a privacy computing node to provide a remote attestation report aiming at a trusted execution environment created by the privacy computing node to a client, wherein the remote attestation report is generated by an authentication server after verification of self-recommendation information generated by the privacy computing node aiming at the trusted execution environment;

a contract information providing unit that causes the privacy computing node to provide to the client to-be-verified contract information of a target intelligent contract deployed at the privacy computing node, the to-be-verified contract information being signed by the privacy computing node within the trusted execution environment with an identity private key of the privacy computing node, the identity private key being maintained by the privacy computing node within the trusted execution environment;

According to a ninth aspect of one or more embodiments herein, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method according to the first, second, third or fourth aspect by executing the executable instructions.

According to a tenth aspect of one or more embodiments of the present specification, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, perform the steps of the method according to the first, second, third or fourth aspect.

In summary, the present specification enables the private computing node to provide a secure and reliable operating environment by implementing the trusted execution environment on the private computing node, and the reliability of the trusted execution environment can be verified by the remote attestation, so that it is determined that the private computing node can safely and faithfully invoke the contract to complete the private computing under the chain when both the signature verification and the contract information verification pass.

Drawings

Fig. 1 is a flowchart of a cluster key sharing method according to an exemplary embodiment.

FIG. 2 is a schematic diagram of cluster identity formation between private compute nodes in a chain according to an example embodiment.

FIG. 3 is a schematic diagram of a scenario for implementing remote attestation, according to an example embodiment.

FIG. 4 is a schematic diagram of another scenario for implementing remote attestation, provided by an example embodiment.

FIG. 5 is a scenario diagram of a deployment of a contract under a chain provided by an exemplary embodiment.

FIG. 6 is a scenario diagram of another deployment subcohain contract provided by an exemplary embodiment.

FIG. 7 is a flowchart of a client-side validation contract provided by an exemplary embodiment.

FIG. 8 is a schematic diagram of a verification of a contract under a chain provided by an exemplary embodiment.

FIG. 9 is a schematic illustration of another verification of a contract under a chain provided by an exemplary embodiment.

FIG. 10 is a scenario diagram of a call under-chain contract provided by an exemplary embodiment.

FIG. 11 is a flowchart of a verification contract on the private compute node side of a chain provided by an exemplary embodiment.

FIG. 12 is a flowchart of another client-side validation contract provided by an exemplary embodiment.

FIG. 13 is a flowchart of another authentication contract on the private computing node side provided by an exemplary embodiment.

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

FIG. 15 is a block diagram of an apparatus for client-side verification of a linked-down contract according to an example embodiment.

Fig. 16 is a block diagram of an apparatus for verifying a contract under a chain on a side of a privacy-preserving compute node according to an example embodiment.

FIG. 17 is a block diagram of an apparatus for client-side validation contracts provided by an exemplary embodiment.

Fig. 18 is a block diagram of an apparatus for privacy computing node side validation contracts provided by an example embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments. It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present specification. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

Blockchains are generally divided into three types: public chain (Public Blockchain), private chain (PrivateBlockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participants joining the public chain can read the data record on the chain, participate in transaction, compete for the accounting right of the new block, and the like, and each participant (i.e. node) can freely join and leave the network. The private chain is opposite, the data writing authority of the network is controlled by a certain organization or organization, and the data reading authority is regulated by the organization; briefly, the private chain can be a weakly centralized system with strict restrictions and few participating nodes, so that the private chain is more suitable for use within a particular organization. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in the federation chain usually has a corresponding entity organization or organization, and participants jointly maintain the operation of the block chain by authorizing to join the network and forming a profit-related federation.

In the blockchain network, corresponding blockchain transactions (transaction for short) are submitted to blockchain link points, and the blockchain transactions are executed by the blockchain link points, so that the corresponding operation purpose is realized. For any of the above types of blockchains, the blockchain link points may be implemented by creating a TEE and implementing the TEE as a secure execution environment for blockchain transactions. The TEE is a trusted execution environment that is based on a secure extension of the CPU hardware and is completely isolated from the outside. TEE was originally proposed by Global Platform to address the secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications parallel to the operating system. The industry is concerned with TEE solutions, and almost all mainstream chip and Software consortiums have their own TEE solutions, such as TPM (Trusted Platform Module) in Software, and Intel SGX (Software Guard Extensions) in hardware, ARM Trustzone, and AMD PSP (Platform Security Processor).

The Intel SGX (hereinafter referred to as SGX) technology is taken as an example. The blockchain node may create enclave (enclosure or enclave) based on SGX technology as a TEE for performing blockchain transactions. The block link point may allocate a partial area EPC (enclosure Page Cache, Enclave Page Cache, or Enclave Page Cache) in the memory by using a newly added processor instruction in the CPU, so as to reside the above-mentioned enclosure. The memory area corresponding to the EPC is encrypted by a memory Encryption engine mee (memory Encryption engine) inside the CPU, the contents (code and data in the enclave) in the memory area can be decrypted only in the CPU core, and a key for Encryption and decryption is generated and stored in the CPU only when the EPC is started. It can be seen that the security boundary of enclave only includes itself and the CPU, and no matter privileged or non-privileged software can not access enclave, even an operating system administrator and a VMM (virtual machine monitor, or called Hypervisor) can not affect code and data in enclave, so that the enclave has extremely high security.

Based on the decentralized architecture of the blockchain network, each blockchain transaction on the blockchain needs to be executed on all blockchain nodes in the blockchain network, so as to ensure that the blockchain account book data maintained by each blockchain node are consistent. If the transaction logic is simple, such as bitcoin for example, the blockchain transaction is only used for implementing the transfer operation, and this will not cause excessive resource consumption even if the blockchain transaction needs to be executed at all blockchain nodes. However, if the blockchain provides the functionality of an intelligent contract and the blockchain transaction invokes the intelligent contract, the situation may be quite different. The intelligent contracts on the blockchain are contracts which can be triggered to be executed by transactions on a blockchain system, and the intelligent contracts can be defined by the form of codes.

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

In the deployment stage, a user sends a transaction containing information for creating the intelligent contract to the Ethernet shop network, the data field of the transaction contains the code (such as byte code) of the intelligent contract, and the to field of the transaction is empty. Each node in the ethernet network performs this transaction via the EVM and generates a corresponding contract instance. After the agreement is achieved between the nodes through the consensus mechanism, the intelligent contract corresponding to the transaction is successfully created, a contract account corresponding to the intelligent contract appears on the block chain, the contract account has a specific contract address, and the contract code (namely the code of the intelligent contract) or the hash value of the contract code is stored in the contract account, and the contract code is used for controlling the action of the corresponding intelligent contract.

In the calling phase, a user (which can be the same as or different from the user who deploys the intelligent contract) sends a transaction for calling the intelligent contract to the Ethernet network, wherein the from field of the transaction is the address of the external account corresponding to the user, the to field of the transaction is the contract address of the intelligent contract required to be called, and the data field contains a method and parameters for calling the intelligent contract. After the agreement is achieved among the nodes through a consensus mechanism, the intelligent contract called by the transaction statement is independently executed on each node of the Ethernet network in a specified mode, and all execution records and data are stored in the block chain, so that the transaction certificate which cannot be tampered and cannot be lost is stored in the block chain after the transaction is completed.

As previously mentioned, the EVM is a well-behaved virtual machine; similarly, other blockchains may employ other types of virtual machines, such as WASM (WebAssembly) virtual machines, and the like. In summary, when the intelligent contract invoked by the transaction is used for implementing relatively complex logic, the process of executing the code of the intelligent contract by the node through the virtual machine consumes relatively more computing resources, and since all nodes in the block chain network need to execute the code of the intelligent contract, the consumption of the computing resources is multiplied as the number of the nodes is increased. Therefore, although the combination of the TEE technology can relatively reduce the resource consumption of a single blockchain node and accelerate the transaction execution efficiency, the resource consumption and waste are still great for the whole blockchain network.

For this reason, the present specification proposes to deploy the private Computation nodes under the chain (i.e., the private Computation nodes under the chain), to transfer the Computation operations that would otherwise need to be performed on all block chain nodes to the private Computation nodes under the chain for execution, and the block chain link nodes only need to obtain the Computation results from the private Computation nodes under the chain and update the block chain ledger data based on the Computation results, and to prove that the Computation results are actually performed as expected in the trusted execution environment based on a Verifiable computing (Verifiable computing) technology, so as to greatly reduce the resource consumption on the chain while ensuring the reliability.

As described above, by deploying an intelligent contract at a block link point, the block link node can execute the code of the intelligent contract to achieve the corresponding computing requirement; similarly, code for performing computing tasks may be deployed at the down-chain private computing node such that the down-chain private computing node may execute the code to fulfill the respective computing requirements. For ease of understanding, contracts deployed at blockchain nodes are referred to herein as on-chain contracts, contracts deployed at private compute nodes under-chain are referred to herein as off-chain contracts; of course, whether it is a chain contract or a chain contract, it is essentially a piece of code that can be executed within a virtual machine.

Similar to the above-described block chain nodes, a down-chain TEE (i.e., a down-chain trusted execution environment) may be created on the down-chain private compute node, which is based on a CPU hardware-implemented fully-isolated trusted execution environment from the outside. The chain privacy computing node can realize deployment operation of chain contracts and call execution operation after deployment through the chain TEE by creating the chain TEE, and ensure data security and privacy protection in the operation process. For example, a down-link contract may be deployed on a down-link private compute node and a WASM virtual machine may be deployed within a down-link TEE created by the down-link private compute node. Then, when a user initiates a computation task based on the WASM program to the down-link privacy computing node, the down-link privacy computing node may read the down-link contract into the down-link TEE and compile the down-link contract into the WASM bytecode, and execute the compiled WASM bytecode in the WASM virtual machine by using the WASM virtual machine as an execution engine.

The method comprises the steps that a single-node type down-link privacy computing node can be configured to execute computing tasks; or, high-concurrency and high-availability private computing services can be provided for users in a form of a linked private computing cluster, so that the problems of load balancing, fault transfer, dynamic expansion and capacity reduction of nodes and the like are solved. The down-link privacy computing cluster may include a control node and a plurality of down-link privacy computing nodes, where each node is configured to deploy the same down-link contract (at least one) to execute a computing task, and the control node is configured to uniformly manage all the down-link privacy computing nodes in the cluster. The following describes a process of requesting a private computing node to join a cluster under a control node management link.

When any one of the down-link privacy computing nodes requests to join the down-link privacy computing cluster, the control node may initiate a challenge to the node and receive a remote attestation report returned by the node. Remote attestation reports result from remote attestation processes directed to the down-link TEE on the down-link privacy computing node. The remote attestation report is generated by the authentication server after verifying self-referral information generated by the down-link privacy computing node, wherein the self-referral information is related to the down-link TEE created on the down-link privacy computing node. The chain lower privacy computing node generates a remote attestation report by generating self-referral information related to chain lower TEE and generating the remote attestation report after the self-referral information is verified by the authentication server, so that the remote attestation report can be used for indicating that the chain lower TEE on the chain lower privacy computing node can be trusted. In other words, the remote attestation report is generated by the authentication server after verifying the self-referral information generated by the down-link privacy computing node for its own down-link TEE.

For example, taking the Intel SGX technology as an example, the under-chain TEE is an enclave created on the under-chain privacy computing node for implementing the under-chain privacy computing, and the remote attestation process also involves another special enclave on the under-chain privacy computing node, namely, quoting enclave (QE for short), and the QE is an architectural enclave (architectural enclave) provided and signed by Intel. The enclave first needs to generate a REPORT structure for local authentication, and the QE verifies whether the enclave is on the same platform as itself based on the REPORT structure, and then the QE encapsulates the REPORT structure into a structure body quite (i.e. self-recommendation information), and uses an epid (enhanced private authentication) key for signing. The EPID key not only represents a platform of the privacy computation node, but also represents the credibility of the bottom hardware of the privacy computation node, and can bind information such as the version of processor firmware and the like, and only QE can access the EPID key for signing the structure QUOTE. In the SGX technology, the authentication server may be an IAS (intel authentication service) server provided by intel corporation, and the chain lower privacy computing node sends the signed structure body quite to the IAS server, so that the IAS server can verify the signature and return a corresponding remote Attestation report to the chain lower privacy computing node.

After obtaining the remote attestation report of the private computation node under the chain, the control node may verify, according to the remote attestation report, whether the corresponding private computation node under the chain is trusted, specifically, whether a TEE under the chain deployed on the private computation node under the chain is trusted, and use the private computation node under the chain as a member node of the private computation cluster under the chain through a request of the private computation node under the chain to join the private computation cluster under the condition that the TEE under the chain is determined to be trusted.

In particular, the down-chain privacy computing node, upon creating the down-chain TEE, generates self-referral information for implementing remote attestation, which may be used to anchor and solidify information of the down-chain TEE, such that a resulting remote attestation report including the self-referral information may be used to characterize a state of the down-chain TEE and to verify whether the down-chain TEE is authentic. For example, the self-referral information may include a first hash value to be verified, where the first hash value to be verified is a hash value of preset information in the chain TEE, and for example, the preset information may include all codes deployed in the chain TEE, a public key of a developer of the chain TEE, and the like. Taking the IntelSGX technique as an example, the hash value generated corresponding to all codes deployed in the TEE under the chain is MREnclave, and the hash value generated corresponding to the public key of the developer of the TEE under the chain is MRSigner, that is, the first hash value to be verified may include MREnclave and MRSigner.

The Intel SGX technique is still used as an example. As described above, after the chain down privacy computing node sends the signed structure body quite to the IAS server, the IAS server verifies the signature according to the maintained public key set, and returns a remote attestation report (i.e., an AVR report) to the chain down privacy computing node, where the remote attestation report includes: the structure QUOTE and the signature verification result, and the IAS server signs the remote attestation report with a private key held by the IAS server.

Accordingly, after obtaining the remote attestation report, the control node may first perform signature verification on the remote attestation report according to the public key of the IAS server, and if the verification passes, it indicates that the remote attestation report is indeed generated by the IAS server and has not been tampered or data is lost in the data transmission process. The control node may obtain the public key of the IAS server in any way, such as when a remote attestation report is provided to the control node, it may also associate a certificate chain providing the IAS, so that the control node may extract the public key of the IAS server from the certificate chain. The control node may then extract the structure body quite and signature verification results from the remote attestation report. The control node can check the signature verification result at first, if the signature verification result is verified, the CPU of the privacy computation node under the chain holds the private key provided by the Intel, so that the TEE under the chain is established on a reliable hardware platform, and other verification operations can be continuously executed; if the signature verification result is that the signature is not verified, the control node can judge that the down-link privacy computing platform is unreliable without continuing other verification operations. Then, the control node may extract the hash values MREnclave and MRSigner from within the structure quate, that is, MREnclave to be checked and MRSigner to be checked; meanwhile, the control node obtains in advance a first standard hash value of the above-mentioned preset information of the sub-chain TEE, such as reliable values of MREnclave and MRSigner (hereinafter referred to as reliable MREnclave and reliable MRSigner), compares the MREnclave to be checked with the reliable MREnclave, and compares the MRSigner to be checked with the reliable MRSigner. Then, the control node may use "MREnclave to be checked is consistent with the trusted MREnclave, and MRSigner to be checked is consistent with the trusted MRSigner" as a precondition that the TEE is trusted under the acknowledgement chain; in other words, if the MREnclave to be checked is not consistent with the trusted MREnclave, or the MRSigner to be checked is not consistent with the trusted MRSigner, the control node determines that the chain-down TEE of the chain-down privacy computing node is not trusted, and if all the preconditions set by the control node are satisfied, the chain-down TEE of the chain-down privacy computing node can be confirmed to be trusted. In addition, the operation of verifying the signature verification result by the control node and the operation of verifying the MREnable to be verified and the MRSigner to be verified do not have a necessary sequence, and the two operations can be completely independent.

Besides MREnclave and MRSigner, the control node may also verify the trustworthiness of the privacy computation node under the chain by other preconditions. For example, after creating the down-link TEE, the down-link privacy computing node may generate a key pair representing its own identity information within the down-link TEE, and create its own node identity information in the down-link TEE, where the node identity information is related to the above-mentioned key pair corresponding to the identity information, for example, the node identity information may include a public key of the key pair (i.e., a node identity public key). Wherein there may be one or more groups of key pairs representing identity information, for example, one group of key pairs is a key pair for signing and verifying (i.e. a signing key pair), and one group of key pairs is a key pair for encrypting and decrypting (i.e. an encrypting key pair), the node identity information may include a public signature key in the signing key pair and an encrypting public key in the encrypting key pair. In a set of key pairs, there may exist multiple public keys corresponding to different encryption algorithms, and these public keys are all included in the node identity information. In addition, the node identity information may also include other information (i.e., other identity information) related to the private computing node under the link, such as a software version, a domain name of the node, a partition name of the node, and the like, which is not limited in this specification. Then, after the node identity information is generated by the down-link privacy computing node in the down-link TEE (for example, generated during initialization of the down-link TEE), the generated node identity information may be subjected to hash computation to obtain a second standard hash value. And the down-link privacy computing node may add this second standard hash value to the structure body quantum when generating the structure body quantum.

Accordingly, the control node may perform signature verification from the remote attestation report after receiving the remote attestation report. And under the condition that the signature verification passes, the control node can extract a signature verification result and a second standard hash value contained in the remote certification report, verify the signature verification result, and verify whether the node identity information of the privacy computing node under the link is correct by using the second standard hash value, and the two verification steps do not have necessary sequence and can be completely independent. And assuming that the control node firstly verifies the signature verification result and continuously verifies the node identity information of the down-link privacy computing node by using the second standard hash value under the condition that the signature verification result is verified. In order to verify the node identity information of the privacy-preserving computation node, the control node needs to acquire the node identity information of the privacy-preserving computation node, for example, the remote attestation report may be provided to the control node and the node identity information may be provided in association, although the control node may also obtain the node identity information in other manners or at other times. Then, the control node may perform hash calculation on the obtained node identity information to obtain a second hash value to be verified, compare the calculated second hash value to be verified with the second standard hash value, and use the comparison result as a precondition for confirming that the privacy computation node under the chain is authentic. If the second hash value to be verified passes verification, the obtained node identity information can be proved to be the node identity information generated by the private computation node under the chain in the TEE of the node under the chain. Then, the private key in the key pair representing the identity information is owned only by the down-link privacy computing node, and the down-link privacy computing node can complete operations such as signature and encrypted communication.

Two judgment conditions adopted when the node is verified for the privacy computation under the link are listed, namely verification for the first hash value to be tested and verification for the node identity information. Other determination conditions may also be used, and are not listed here. When the trust verification is performed on the private computing node under the link, one or more judgment conditions can be selected. For example, the first hash value to be verified and the node identity information may be verified at the same time; alternatively, in some cases, only the node identity information may be verified, while the first hash value to be verified may be unverified or partially verified. For example, the control node may set a trust level, and determine whether to verify or partially verify the first hash value to be verified according to the trust level, for example, when the trust level is 0, the first hash value to be verified is not required to be verified, when the trust level is 1, the MRSigner in the first hash value to be verified is verified, when the trust level is 2, the MREnclave in the first hash value to be verified is verified, and the like.

In the above embodiment, the node identity information includes identity-related information of the private computation node, such as a node identity public key representing the node identity. The node identity information may further include information related to the chain TEE, and then the chain privacy computing node performs hash computation on the generated node identity information to obtain a hash value after generating the node identity information in the chain TEE of the chain privacy computing node itself, and when the hash value is added to the structure body queue, the hash value is equivalent to the effect of simultaneously realizing the first hash value to be tested and the second standard hash value. For example, the node identity information may include, in addition to information such as a signature public key and an encryption public key, values of MREnclave and MRSigner, so that a hash value obtained by hash calculation of the node identity information is related to the identity of the node privacy computation node under the link and the TEE under the link. Accordingly, the control node may perform signature verification from the remote attestation report after receiving the remote attestation report. And under the condition that the signature verification passes, the control node can extract a signature verification result and the hash value contained in the remote certification report, verify the signature verification result, and verify whether the node identity information of the privacy computing node under the link is correct by using the hash value, and the two verification steps do not have a necessary sequence and can be completely independent. And assuming that the control node firstly verifies the signature verification result and continuously verifies the node identity information of the privacy computation node under the chain by using the hash value under the condition that the signature verification result is verified. In order to verify the node identity information of the down-link privacy computing node, the control node needs to acquire the node identity information of the down-link privacy computing node, which is not described herein again. Then, the control node may perform 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 included in the remote attestation report, and use the comparison result as a precondition for confirming that the privacy computing node under the link is authentic. Therefore, the verification of the two aspects in the foregoing can be realized only by one comparison in the embodiment, which is helpful for improving the verification efficiency.

It should be noted that the verification process of the remote attestation report by the control node may further include other operations, such as determining whether the chain TEE operates in the test mode (risk of data leakage exists in the test mode) according to the content of the remote attestation report, and so on, which is not described herein again.

Based on the above method for verifying the private computation nodes under the chain, the control node can add the verified nodes into the private computation cluster under the chain, so as to establish a private computation cluster under the chain containing a plurality of private computation nodes under the chain. After the establishment of the private computing cluster, uniform identity information, for example, called a cluster identity key, needs to be generated for the private computing nodes. The cluster identity key may include a cluster encryption key pair and a cluster signature key pair, and each of the chain privacy computing nodes needs to maintain the cluster encryption private key and the cluster signature private key in their respective chain TEE. By generating uniform identity information for each node in the down-link privacy computing cluster, an external object docked with the down-link privacy computing cluster does not need to pay attention to the fact that the other party is a single down-link privacy computing node or the down-link privacy computing cluster, only needs to be used as an object and interacted with the object, and does not need to pay attention to details of the node or the cluster behind.

Fig. 1 is a flowchart of a cluster key sharing method according to an exemplary embodiment. As shown in fig. 1, the method may include the steps of:

102, any node in the down-link privacy computing cluster acquires a first remote attestation report sent by other nodes in the down-link privacy computing cluster, where the first remote attestation report is generated by an authentication server after verifying first self-referral information generated by the other nodes for a created first down-link trusted execution environment.

In this embodiment, for the first remote attestation report of the other node and the generated first self-referral information, reference may be made to the explanations in the foregoing, and details are not repeated here. And after obtaining the first remote attestation report, the any node may determine whether the first downlinked trusted execution environment created by the other node is trusted according to the first remote attestation report. Specifically, the signature verification may be performed on the first remote attestation report according to the public key of the authentication server, and when the signature verification passes and the remote authentication result included in the first remote attestation report is that the remote authentication passes, a first hash value to be verified is extracted from the first self-recommended information carried in the first remote attestation report, where the first hash value to be verified is a hash value of preset information in the trusted execution environment under the first chain. After the first hash value to be tested is extracted, comparing a first standard hash value which is obtained in advance and aims at the preset information with the first hash value to be tested, and using the comparison result as a precondition for confirming that the trusted execution environment under the first chain is trusted. Similarly, the specific process of determining whether the first-chain trusted execution environment is trusted may refer to the process of determining, by the control node, whether the chain trusted execution environment to be joined with the node is trusted, which is not described herein again.

And 104, acquiring a cluster identity key corresponding to the private computing cluster under the chain by any node, wherein the cluster identity key is generated in a trusted execution environment under a second chain created by any node, and the cluster identity key is used for encrypting and decrypting interaction data and/or signing and checking a signature during the process that a block chain link interacts with each node in the private computing cluster under the chain to deploy or invoke a contract under the chain.

In this embodiment, when a cluster identity needs to be generated, the control node may select a certain linked privacy computation node as a master node and other linked privacy computation nodes as slave nodes, and the master node generates a key pair (cluster identity key) representing the cluster identity and further shares the key pair to each slave node, so that all the linked privacy computation nodes maintain a uniform key pair representing the cluster identity. For example, after each node in the down-link privacy computing cluster has generated its own node identity information, the control node selects "any node" in step 104 as a master node, generates a cluster identity key corresponding to the down-link privacy computing cluster in the down-link TEE created by itself, and further acquires the generated cluster identity key to implement a sharing operation when the cluster identity key needs to be shared with other nodes.

Step 106, in a case where the any node determines that the trusted execution environment under the first chain is trusted according to the first remote attestation report, the any node sends the cluster identity key and a second remote attestation report to the other node, in a case where the second remote attestation report indicates that the trusted execution environment under the second chain is trusted, the cluster identity key is approved by the other node, and the second remote attestation report is generated by an authentication server after verifying second self-referral information generated by the any node for the trusted execution environment under the second chain.

In this embodiment, the other node approves the cluster identity key when determining that the second remote attestation report indicates that the trusted execution environment in the second chain is trusted, so as to maintain the cluster identity key in the trusted execution environment in the first chain of the other node.

Before sending the cluster identity key to the other nodes, the any node may verify the first node identity information of the other nodes. Further, since the first node identity information includes the node identity public keys of the other nodes, the node identity public key included in the first node identity information can be acquired to encrypt the cluster identity key under the condition that the first node identity information passes the verification, so that the cluster identity key can be decrypted only by the other nodes through the node identity private keys of the other nodes, and the security that the cluster identity key is shared by any node to the other nodes is ensured. Specifically, the any node may obtain first node identity information provided by the other node (for example, the other node may associate the first node identity information with a first remote attestation report and send the first remote attestation report to the any node), and perform hash calculation on the obtained first node identity information to obtain a second hash value to be verified, where the first node identity information includes a node identity public key of the other node and other identity information of the other node. Meanwhile, the any node obtains a 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 obtained by performing hash calculation on the generated node identity information after the other node generates its own node identity information in the first-chain trusted execution environment. Further, the any node compares the second hash value to be verified with the second standard hash value, and obtains the node identity public key included in the node identity information of the other node if the comparison result is consistent, so that the cluster identity key is signed by using the node identity private key of the any node, and the signed cluster identity key is encrypted by using the node identity public keys of the other node. And when the any node shares the encrypted cluster identity key with the other nodes, sending the second remote certification report of the any node and the encrypted cluster identity key to the other nodes in an associated manner so as to certify the identity. Then, the other nodes decrypt the received cluster identity key by using the node identity private key of the other nodes under the condition that the trusted execution environment under the second chain created by the any node is determined to be trusted according to the second remote attestation report, verify the signature of the cluster identity key by using the node identity public key included in the node identity information of the any node, and maintain the cluster identity key in the trusted execution environment under the first chain under the condition that the signature verification is passed.

The manner of obtaining the node identity public key of any node is similar to the manner of obtaining the node identity public key of other nodes by any node. In particular, the any node may provide second node identity information to the other node (e.g., the any node may send the second node identity information to the other node in association with a second remote attestation report), the second node identity information including a node identity public key of the any node and other identity information of the any node. Meanwhile, the any node provides a third standard hash value to the other node (for example, the third standard hash value may be included in a second remote attestation report), and the third standard hash value is obtained by performing hash calculation on the generated node identity information after the any node generates its own node identity information in the second chain trusted execution environment. Then, the other nodes decrypt the received cluster identity key by using the node identity private keys of the other nodes under the condition that a third hash value to be verified obtained by performing hash calculation on the second node identity information is consistent with a third standard hash value, verify the signature of the cluster identity key by using the node identity public key included in the node identity information of any node, and maintain the cluster identity key in the trusted execution environment under the first chain under the condition that the signature verification is passed.

Therefore, before the cluster identity key is shared by any node to other nodes, the other nodes need to be verified, and after the cluster identity key shared by any node is received by other nodes, the any node also needs to be verified, so that the security of the shared cluster identity key is ensured.

As shown in fig. 2, assuming that the private computation cluster includes several private computation nodes, such as node 20, node 21, node 22, etc., a uniform cluster identity needs to be established among these nodes. First, each of the down-link privacy computing nodes creates a down-link TEE, and creates node identities within the respective down-link TEEs, such as node 20 creating TEE1, and creating a Key pair Key-0 representing its own node identity within TEE1, node 21 creating TEE2, and creating a Key pair Key-1 representing its own node identity within TEE1, node 22 creating TEE3, and creating a Key pair Key-2 representing its own node identity within TEE1, and so on. The timing of each of the down-link privacy computing nodes joining the cluster is often different, and thus the timing of creating the down-link TEE and the node identity is also different. Generally, a node needs to initiate an application to a control node of a down-link privacy cluster, and the control node may initiate a challenge to the node issuing the application to verify a hardware environment of the node, software running in a down-link TEE, and the like, and add the node to the down-link privacy computing cluster after the verification is passed, so that the node becomes a down-link privacy computing node.

When the cluster identity needs to be generated, the control node may select a certain linked privacy computing node as a master node and other linked privacy computing nodes as slave nodes, the master node generates a key pair representing the cluster identity, and then shares the key pair to each slave node, so that all the linked privacy computing nodes maintain a uniform key pair representing the cluster identity. As shown in fig. 2, assume that node 20 is selected to be the master node, nodes 21-22, etc. to be the slave nodes. First, node 20 generates a Key pair representing the cluster identity, i.e., a cluster identity Key pair C-Key, within TEE 1. Then, the node 20 initiates a challenge to each slave node, so that the slave nodes, such as the node 21 and the node 22, generate remote attestation reports, respectively, which may refer to the foregoing description and is not described herein again. MREnclave, MRSigner, hash values of node identity information, etc. may be contained within the remote attestation report. The node 20 receives the remote attestation report and the node identity information returned from each slave node, respectively, and verifies it in the manner described above to determine whether each slave node is authentic.

Taking node 21 as an example, assume that node 20 determines that node 21 is trusted by way of remote attestation. In the Key pair Key-0 representing the identity of the node 20, for example, a group of signature Key pairs Key-0-S and a group of encryption Key pairs Key-0-T, the node 20 may use the private signature Key in the signature Key pair Key-0-S to sign the cluster identity Key pair C-Key. Meanwhile, the node identity information provided by the node 21 to the node 20 contains a public Key in the Key pair Key-1 representing the identity of the node 21, such as a signature public Key in the signature Key pair Key-1-S and an encryption public Key in the encryption Key pair Key-1-T. Therefore, the node 20 may encrypt the C-Key and its signature data of the above cluster identity Key pair by using the encryption Key to encrypt the encryption public Key in Key-1-T, obtain an encrypted Key pair, and send the encrypted Key pair to the node 21.

Node 20 also triggers the obtaining of a remote attestation report generated for its own created TEE1 in the manner described earlier, and node 20 sends this remote attestation report, in addition to sending the above-described encrypted key pair to node 21, along with node identity information of node 20 itself, to node 21 for node 21 to authenticate node 20. Under the condition that the node 20 is verified and determined to be credible, the node 21 decrypts the received encrypted Key pair by using an encryption private Key in Key-1-T of an encryption Key pair maintained by the node to obtain a cluster identity Key pair C-Key and signature data thereof; and the node 21 extracts the signature public Key in the Key-0-S of the signature Key pair from the node identity information of the node 20, verifies the decrypted signature data, if the signature verification is successful, 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 private computation cluster under the chain. Similarly, in the above manner, the master node may share the cluster identity Key pair C-Key to each slave node, so that all the down-link privacy computation nodes in the down-link privacy computation cluster obtain the cluster identity Key pair C-Key finally.

Whether the private computing nodes are in the form of single nodes or in the form of private computing clusters, a deploying party of the contract under the chain can deploy the contract under the chain in the private computing nodes under the chain for subsequent invoking and executing the computing task.

The client of the deployer may initiate a challenge to the down-chain privacy computing node and receive a remote attestation report back from the down-chain privacy computing node. For example, the client may initiate a down-link challenge to the down-link privacy computing node, that is, the process of initiating the challenge is independent of the blockchain network, so that the consensus process between blockchain nodes may be skipped and the interactions in the up-link and down-link chains may be reduced, so that the challenge of the client to the down-link privacy computing node has higher operation efficiency. For another example, the client may take the form of an on-chain challenge, such as the client may submit a challenge transaction to a blockchain node, the challenge transaction may include challenge information that may be transmitted by the blockchain node to the off-chain privacy computing node through a prolog mechanism, and the challenge information may be used to initiate a challenge to the off-chain privacy computing node.

Taking the scenario shown in fig. 3 as an example, in one case, the client 31 may directly initiate the challenge to the down-link privacy computing node 32 through the down-link channel, that is, the client 31 initiates the down-link challenge to the down-link privacy computing node 32, in another case, the client 31 may initiate the challenge to the down-link privacy computing node 32 through the blockchain network 33, that is, the client 31 initiates the up-link challenge to the down-link privacy computing node 33. the process of initiating the up-link challenge may include three steps, step ①, in which the client 31 submits a transaction for initiating the challenge, for example, called a challenge transaction, to the blockchain network 33, which may be received and executed by a certain node 33n within the blockchain network 33, step ②, in which the node 33n invokes a pre-prompter intelligent contract (for short, a pre-prompter contract), which may transfer the challenge information contained in the above challenge transaction to the down-link prepro server 34, for example, the pre-prompter intelligent contract server 34 may generate an event including the challenge information, which may be sent to the under-link computing node ③ through the down-link computing node 32.

When a client 31 initiates a challenge to a private down-link computing node 32 through an up-link channel, it refers to data interaction between a block-link network 33 and the private down-link computing node 32, i.e. data interaction on and off the link, which may be realized by a preplanning contract cooperating with a preplanning server 34 through the above-mentioned step ②, and the cooperation mechanism between the preplanning contract and the preplanning server 34 is a preplanning mechanism, wherein a transaction submitted to a node 33n by the client 31 should directly or indirectly invoke the preplanning contract described above to trigger the preplanning mechanism, wherein if the contract address of the preplanning contract is filled in the to field of the transaction, it indicates that the transaction directly invokes the preplanning contract, if the contract address of a contract on a link is filled in the to field of the transaction, and the contract on the link invokes the preplanning contract, it indicates that the transaction indirectly invokes the preplanning contract as a preplanning contract address, it may be considered as a result of a data transfer from the up-link contract to the private down-link, and may be transferred from the data exchange to the down-link contract, and the data exchange may be carried from the down-link to the data exchange process.

Whether a challenge is a down-link challenge or an up-link challenge, the privacy-down-link computing node may, upon receiving a challenge initiated by the client, temporarily trigger a remote attestation process as described above and generate a corresponding remote attestation report, which is then fed back to the client. Alternatively, the downlink privacy computing node, upon receiving the client-initiated challenge, provides the remote attestation report to the client without temporarily triggering the remote attestation process if a pre-generated remote attestation report already exists locally. The remote attestation report locally existing in the down-link privacy computing node may be generated by the down-link privacy computing node triggered in response to a challenge of another challenger other than the client, for example, the other challenger may include another client, a control node in the down-link privacy computing cluster where the down-link privacy computing node is located, a KMS server, and the like, which is not limited in this specification. Thus, the down-link privacy computing node, upon receiving the client-initiated challenge, may first look to see if there is a previously generated remote attestation report locally, and if so, feed back the remote attestation report to the client, otherwise temporarily trigger the remote attestation process. The remote attestation report may have a certain time limit, such as 30 minutes or other duration, the overtime remote attestation report may be considered to be invalid by the client, and the linked privacy computing node may also actively clear the invalid remote attestation report to avoid feedback to the client.

Data interaction between devices is involved in the process that a client initiates a challenge to a down-link privacy computing node or the process that the down-link privacy computing node feeds back a remote attestation report to the client. Taking the scenario shown in fig. 3 as an example, the involved data interactions may include: data interaction between client 31 and down-link privacy computing node 32 (client 31 issues down-link challenge to down-link privacy computing node 32, down-link privacy computing node 32 returns remote attestation report to client 31), data interaction between client 31 and node 33n (client 31 sends challenge transaction to node 33n, node 33n returns remote attestation report to client 31), data interaction between the node 33n and the talker server 34 (the talker server 34 reads challenge information from the node 33n, the talker server 34 feeds back a remote attestation report to the node 33 n), data interaction between the talker server 34 and the down-link privacy computing node 32 (the talker server 34 sends challenge information to the down-link privacy computing node 32, the down-link privacy computing node 32 returns a remote attestation report to the talker server 34), and so on. In the process of implementing any data interaction, there is a possibility of leakage of data transmitted between the data sending party and the data receiving party, and the node 33n links the challenge transaction to the public, so that information leakage can be avoided by performing encrypted transmission on the data.

Take the example where client 31 submits a challenge transaction to node 33 n. The challenge transaction initiates an on-chain challenge to the down-chain privacy computing node 32, so that the node 33n can perform chain linking after the challenge transaction submitted by the client 31 is identified with other nodes, and verify the challenge behavior of the client 31. However, if the client 31 does not want his/her challenge behavior to be freely known by other users, the challenge transaction can be privacy protected. The client 31 may encrypt the challenge transaction, and the node 33n may receive the encrypted challenge transaction, which may ensure that the content of the challenge transaction is not leaked during transmission. The chain TEE may be deployed at the node 33n, and the node 33n may decrypt the encrypted challenge transaction within the chain TEE after reading the encrypted challenge transaction into the chain TEE, which may ensure that the decrypted challenge transaction only exists within the chain TEE and does not leak. Node 33n links the encrypted challenge transaction directly and manages the viewing rights of the encrypted data to restrict users who can view the challenge transaction, while other users can only obtain the encrypted challenge transaction when viewing the blockchain data directly. In fact, node 33n may ensure that data requiring privacy protection can only be decrypted to plaintext form within the TEE on the chain, and ciphertext form once it leaves the TEE on the chain.

The encrypted transmission for the challenge transaction may take the form of symmetric encryption or asymmetric encryption. When symmetric encryption is used, the client 31 and the node 33n respectively maintain the same symmetric Key, for example, the symmetric Key can be obtained by negotiation between the client 31 and the node 33n through an algorithm such as DH (Diffie-Hellman) or ECDH (explicit customer Diffie-Hellman), or distributed to the client 31 and the node 33n by a KMS (Key Management Service) server, and the Key source is not limited in this specification. When the key is distributed by the KMS server, the KMS server may determine that the on-chain TEE at the node 33n is trusted by means of remote attestation, which is similar to the remote attestation process of the client 31 to the down-chain privacy computing node 32, and then encrypt and transmit the key into the on-chain TEE, which will not be described herein again. Then, the client 31 may encrypt the challenge transaction by using the above symmetric key, and the node 33n maintains the symmetric key in the chain TEE, so that the encrypted challenge transaction is read into the chain TEE, and a decryption operation is performed by using the symmetric key to obtain the above challenge transaction. The encryption algorithm used for symmetric encryption may include, for example, DES algorithm, 3DES algorithm, TDEA algorithm, Blowfish algorithm, RC5 algorithm, IDEA algorithm, and the like.

When asymmetric encryption is employed, the node 33n maintains a private key with an asymmetric key, for example, referred to as a node private key, and the client 31 can obtain a node public key corresponding to the node private key. The asymmetric key may be generated by the node 33n within the chain TEE or distributed to the node 33n by the KMS server, and the key source is not limited in this description. Similarly, when the key is distributed by the KMS server, the KMS server may determine that the on-chain TEE at node 33n is authentic by way of remote attestation, and then cryptographically transmit the key into the on-chain TEE. Then, the client 31 may encrypt the challenge transaction through the node public key, and the node 33n maintains the node private key in the chain TEE, so that the encrypted challenge transaction is read into the chain TEE, and a decryption operation is performed through the node private key to obtain the above challenge transaction. Asymmetric encryption algorithms used for asymmetric encryption may include, for example, RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), and the like.

The encrypted transmission for the challenge transaction may also take the form of a combination of symmetric encryption and asymmetric encryption. The client 31 may maintain a symmetric key, for example, the symmetric key may be randomly generated by the client 31, and the client 31 may obtain a public key of the asymmetric key. The client 31 may encrypt the challenge transaction by using the symmetric key to obtain an encrypted challenge transaction, encrypt the symmetric key by using the asymmetric key to obtain an encrypted key, and transmit the encrypted challenge transaction and the encrypted key to the node 33n by using the client 31. Correspondingly, the node 33n reads the encrypted challenge transaction and the encrypted key into the chain TEE, decrypts the encrypted key through the node private key to obtain a symmetric key, and decrypts the encrypted challenge transaction through the symmetric key. In comparison, the encryption and decryption efficiency of the symmetric encryption is relatively higher but the security is relatively lower, while the encryption and decryption efficiency of the asymmetric encryption is relatively lower but the security is relatively higher, so that the encryption and decryption efficiency and the security can be both considered based on a form of combining the symmetric encryption and the asymmetric encryption.

Similarly, in the process of other data interaction, the same symmetric key is maintained between the data sender and the data receiver, or the data sender maintains a public key with an asymmetric key, the data receiver maintains a private key with an asymmetric key, or a symmetric encryption and asymmetric encryption form is combined, so that data encryption transmission between any data sender and any data receiver can be realized, which is not described herein again.

The down-link privacy computing node may belong to a down-link privacy computing cluster that includes a plurality of down-link privacy computing nodes. The interaction process between a client and a single down-link privacy computing node may refer to the embodiments described above if there is complete independence between the individual down-link privacy computing nodes. In another mode, the down-link privacy computing cluster may include a control node, and the control node may perform unified management on all down-link privacy computing nodes in the cluster. For example, the client may initiate a challenge to the control node and receive a remote attestation report of the above-described private computing node from the control node. Similar to the previous embodiments, the client may initiate a down-link challenge to the control node, or the client may submit a challenge transaction to the blockchain node, the challenge transaction containing challenge information that is transmitted by the blockchain node to the control node through a predictive mechanism, so that the control node returns a remote attestation report of the down-link privacy computation node to the client.

Taking the scenario shown in fig. 4 as an example, in one case, the client 41 may directly initiate a challenge to the control node 42 through a down-link channel, that is, the client 41 may initiate a down-link challenge to the control node 42, in another case, the client 41 may initiate a challenge to the control node 42 through the blockchain network 43, that is, the client 41 may initiate an up-link challenge to the control node 42, the process of initiating the up-link challenge may include three steps, step ①, the client 41 submits a transaction for initiating the challenge to the blockchain network 43, for example, called a challenge transaction, which may be received and executed by a certain node 43n within the blockchain network 43, step ②, the node 43n invokes a pre-deployed pre-language machine intelligent contract (abbreviated pre-language machine contract), which may transfer challenge information included in the challenge transaction to a pre-language machine server 44 under the link, for example, the pre-language machine contract may generate an event including the challenge information, and the pre-language machine server 44 may listen to the event generated by the pre-language machine contract server to obtain the pre-language machine contract information ③, and send the challenge information to the control node 42 through the down-link channel.

When the client 41 initiates a challenge to the control node 42, the challenge target may be set as a certain down-link privacy computing node, such as the down-link privacy computing node 42n, in the cluster where the control node 42 is located, and then the control node 42 returns a remote attestation report corresponding to the down-link privacy computing node 42n to the client 41 according to the received challenge. The client 41 may not set the challenge target, and then the control node 42 selects from the down-chain privacy computing cluster after receiving the challenge, for example, returns a remote attestation report corresponding to the down-chain privacy computing node 42n to the client 41 when the down-chain privacy computing node 42n is selected.

After receiving the challenge initiated by the client 41, the control node 42 may forward the challenge to the down-link privacy computing node 42n, so that the down-link privacy computing node 42n temporarily triggers the remote attestation process to generate a corresponding remote attestation report, and then feeds the remote attestation report back to the client 41 through the control node 42. Alternatively, the control node 42 may forward the challenge to the down-link privacy computing node 42n after receiving the challenge initiated by the client 41, and if there is already a pre-generated remote attestation report on the down-link privacy computing node 42n, the down-link privacy computing node 42n returns the remote attestation report to the control node 42, which is provided by the control node 42 to the client 41 without temporarily triggering the remote attestation process. Alternatively, after receiving the challenge initiated by the client 41, if there is already a pre-generated remote attestation report corresponding to the down-link privacy computing node 42n locally at the control node 42, the down-link privacy computing node 42n provides the remote attestation report to the client 41 without forwarding the challenge to the down-link privacy computing node 42n or without the down-link privacy computing node 42n thus temporarily triggering the remote attestation process. The remote attestation report locally existing in the down-link privacy computing node 42n may be generated by the down-link privacy computing node 42n in response to a challenge of another challenger other than the client 41, for example, the other challenger may include another client, the control node 42, the KMS server, and the like, which is not limited in this specification. While the down-link privacy computing node 42n provides remote attestation reports to the other challengers described above through the control node 42, the control node 42 may cache the received remote attestation reports. Thus, after receiving the challenge initiated by the client 41, the control node 42 may first check to see whether there is a previously obtained remote attestation report locally, and if so, feed back the remote attestation report to the client 41, otherwise, forward the challenge to the down-link privacy computing node 42 n; and, the down-link privacy computing node 42n, upon receiving the challenge, may first look to see if there is a previously obtained remote attestation report locally, and if so, feed back the remote attestation report to the control node 42, otherwise temporarily trigger the remote attestation process. Where the remote attestation report may have a certain time limit, such as 40 minutes or other duration, the remote attestation report that is out of time may be considered to be invalid by the client 41, and the control node 42 or the down-link privacy computing node 42n may also actively clear the invalid remote attestation report to avoid feedback to the client 41.

In the embodiment shown in fig. 4, data interaction may occur between the client 41 and the control node 42, between the control node 42 and the down-link privacy computing node 42n, between the client 41 and the node 43n, between the node 43n and the predictive server 44, between the predictive server 44 and the control node 42, and so on. For any data interaction process, the encrypted data transmission scheme as described above may be adopted, and the encrypted data transmission scheme includes a form of symmetric encryption, asymmetric encryption, or a combination of both forms, which is not described herein again.

Or, for the situation of the privacy computing cluster under the link, based on that each privacy computing node under the link maintains a cluster identity key in each chain TEE, the privacy computing cluster under the link can be regarded as a whole, the control node selects a node responding to the client, and each node in the privacy computing cluster under the link does not adopt a node identity key of itself but adopts the cluster identity key to encrypt and decrypt the interactive data or generate and verify a signature in the process of interacting with external equipment (such as a block chain node, the client and the like). The way of encrypting and decrypting by using the cluster identity key or generating and verifying the signature is similar to the above process using the node identity key, and is not described herein again.

Based on the scheme, the deployment party can deploy the down-chain contract to the down-chain privacy computing node through the client under the condition that the down-chain privacy computing node is determined to be credible. The contract under the link is similar to the contract on the link executed by the block link node, and may be a bytecode running in the virtual machine, which is not described herein again. By carrying out encryption transmission on the byte codes of the contract under the link, data leakage or modification and the like can be avoided in the transmission process, and the privacy and the safety are ensured.

Similar to the aforementioned challenge process, the client may encrypt and transmit the bytecode of the contract under the link to the private computing node under the link through a link-down approach, that is, the transmission process for the bytecode is independent of the blockchain network, so that the consensus process between blockchain nodes can be skipped, and the inter-operation under the link up is reduced, so that the transmission efficiency of the bytecode is higher. Or, the client may encrypt and transmit the bytecode for the contract under the chain to the privacy computing node under the chain through an on-chain path, for example, the client generates an under-chain contract deployment transaction, where the under-chain contract deployment transaction includes a bytecode ciphertext obtained by encrypting the bytecode, the client encrypts the under-chain contract deployment transaction and submits the encrypted under-chain contract deployment transaction to the block link point, and the encrypted under-chain contract deployment transaction may be decrypted in an on-chain TEE created at the block link point to obtain the bytecode ciphertext, and then the block link point transmits the bytecode ciphertext to the privacy computing node under the chain through a preplan mechanism.

Taking the scenario shown in fig. 5 as an example, in one case, the client 51 may encrypt the transport bytecode directly to the down-link privacy computing node 52 through the down-link channel, that is, the client 51 may transmit the encrypted bytecode ciphertext to the down-link privacy computing node 52 down-link, in another case, the client 51 may encrypt the transport bytecode to the down-link privacy computing node 52 through the blockchain network 53, that is, the client 51 may transmit the encrypted bytecode ciphertext to the down-link privacy computing node 52 up-link, the process of the up-link encryption transmission may include three steps, step ①, the client 51 may submit a transaction for deploying a down-link contract to the blockchain network 53, that is, a down-link contract deployment transaction, which may be received and executed by a certain node 53n within the blockchain network 53, step ②, the node 53n invokes a prolog machine contract, which may transfer the bytecode included in the down-link contract deployment to a prolog machine server 55 under-link, for example, the prolog machine contract may generate an event including the prolog machine contract, and may generate the prolog machine contract by the contraction server ③, thereby generating the prolog machine contract to generate the events to be transmitted to the down-link through the contraction channel network 3655.

In the process of the down-link encryption transmission, only data interaction between the client 51 and the down-link privacy computing node 52 is involved, and the encryption transmission scheme of the symmetric encryption, the asymmetric encryption, or a combination of the two may be adopted as described above, and will not be described herein again. During the process of encryption transmission on the chain, data interaction among a plurality of objects is involved, and byte codes are required to be ensured to be always in an encryption state. For example, when the client 51 submits the under-link contract deployment transaction to the node 53n, the under-link contract deployment transaction may be cryptographically transmitted by a cryptographic transmission scheme such as the symmetric encryption, the asymmetric encryption, or a combination thereof described above, such that the bytecode included in the under-link contract deployment transaction is in a cryptographically protected state. The bytecode contained in the contract deployment transaction under the chain may be in a plaintext state or a ciphertext state. If the node is in the ciphertext state, it is indicated that the client 51 encrypts the bytecode, and then adds the bytecode ciphertext to the data field of the contract deployment transaction under the chain, and the client 51 should ensure that only the privacy computation node 52 under the chain in the final link can decrypt the bytecode ciphertext, but neither the other node 53n nor the predictive server 55 can decrypt the bytecode ciphertext, then after the node 53n decrypts the contract deployment transaction under the chain in the TEE created by itself to obtain the bytecode ciphertext, the predictive server 55 can directly read the bytecode ciphertext, and then the predictive server 55 transmits the bytecode ciphertext to the privacy computation node 52 under the chain. If the node is in the plaintext state, which indicates that the client 51 directly adds the plaintext bytecode to the data field of the contract deployment transaction under the chain, and the contract deployment transaction under the chain can call a contract on the chain, the node 53n decrypts the contract deployment transaction under the chain in the TEE on the chain to obtain the plaintext bytecode, and then executes the contract on the chain through the virtual machine deployed in the TEE on the chain, so that the bytecode is encrypted into a corresponding bytecode ciphertext in the TEE on the chain, the bytecode ciphertext is ensured to be decrypted only by the privacy computing node 52 under the chain, and then the bytecode ciphertext is read by the prediction machine server 55 and is further transmitted to the privacy computing node 52 under the chain.

When the bytecode is encrypted, a symmetric encryption, an asymmetric encryption, or a combination of both may be used, which is not limited in this specification. When asymmetric encryption or a combination of symmetric encryption and asymmetric encryption is used, a group of asymmetric key pairs is involved, the client 51 or the node 53n needs to know the public key of the asymmetric key pair, and the private key of the asymmetric key pair needs to be maintained by the down-link privacy computing node 52, so that the down-link privacy computing node 52 can decrypt the received bytecode ciphertext based on the private key. For example, the asymmetric key pair may be the encryption key pair generated by the down-chain privacy computing node 52 in the down-chain TEE, described above; accordingly, after receiving the bytecode ciphertext, the down-link privacy computing node 52 reads the bytecode ciphertext into the down-link TEE, and decrypts the bytecode ciphertext based on the encryption private key, thereby obtaining the bytecode of the plaintext.

After the node 52 for privacy under the chain decrypts the bytecode in the plaintext in the TEE under the chain, the bytecode may be re-encrypted in the TEE under the chain and then stored in a storage space outside the TEE under the chain, for example, a hard disk of the node 52 for privacy under the chain, so as to complete deployment of the contract under the chain. Here, the node 52 typically uses a symmetric key to encrypt and store the bytecode by symmetric encryption, so that the decryption operation can be performed faster than in the form of asymmetric encryption when the bytecode is called later. The symmetric key may be generated by the down-chain privacy computing node 52 in the down-chain TEE, or distributed by other objects to the down-chain privacy computing node 52 by way of encrypted transmission. For example, the symmetric key described above may be distributed to the down-chain privacy computing node 52 by the KMS server initiating a challenge to the down-chain privacy computing node 52 and verifying that the down-chain privacy computing node 52 is trusted by remote attestation. The down-link privacy computing node 52 may take the symmetric key distributed by the KMS server as a root key and apply a derivative key derived based on the root key to the encrypted storage for the bytecode. For another example, based on the Intel SGX technology, the symmetric Key may be an RSK (root Seal Key) Key burned in an e-fuses storage circuit in the CPU of the down-link privacy computing node 52, or a derivative Key (i.e., Seal Key) derived from the RSK Key. Of course, the node 52 may also encrypt and store the byte codes by using asymmetric encryption or a combination of symmetric encryption and asymmetric encryption, which is not limited in this specification.

In addition to securely storing the bytecode of the down-link contract at the down-link privacy computing node 52, the client 51 may specify to the down-link privacy computing node 52 an execution engine for executing the bytecode. For example, in an offline TEE created at the offline privacy computing node 52, several execution engines may be deployed, such as one or more of an EVM, a WASM virtual machine, and so on, and particularly in the case where multiple execution engines are deployed simultaneously, the client 51 may send, to the offline privacy computing node 52, execution engine specifying information associated with the above bytecode, which indicates to the offline privacy computing node 52 the execution engine for executing the above bytecode, such as employing an EVM or WSAM virtual machine, and so on. For example, the bytecode and the execution engine specifying information may be packaged and encrypted and then transmitted to the down-link privacy computing node 52; the bytecode and the execution engine specifying information may also be encrypted and transmitted separately, where the execution engine specifying information should include information of the corresponding bytecode or the contract under the chain, such as a hash value of the bytecode, so as to determine which contract under the chain the execution engine specifying information corresponds to based on the information. Accordingly, when deploying the contract under the chain, the privacy-preserving computation node 52 under the chain needs to mark information of an execution engine that the bytecode needs to adopt, in addition to encrypting and storing the bytecode, so that an appropriate virtual machine is selected as the execution engine for processing the corresponding bytecode in a subsequent calling process.

In the above manner, the client 51 may deploy more down-link contracts to the down-link privacy computing node 52; similarly, other clients may also deploy the down-link contract to the down-link privacy computing node 52. To facilitate management, and subsequent invocation of the under-chain contract, the under-chain privacy computing node 52 may generate a corresponding contract ID for the deployed under-chain contract, with a one-to-one correspondence between the under-chain contract and the contract ID. For example, after completing the deployment operation for the contract under the chain, the privacy-preserving computation node 52 under the chain may perform a hash operation on the bytecode of the contract under the chain to obtain a first hash value, and use the first hash value as the contract ID of the contract under the chain. Of course, the contract ID may be generated by the down-link privacy computing node 52 in other manners, which is not limited in this specification.

The first hash value described above may also have other effects if it is used as a contract ID for a contract under a chain. After deployment is completed, the down-link privacy computation node 52 may feed back deployment result information to the client 51, where the deployment result information includes the first hash value, and the client 51 may further perform hash computation on the bytecode sent by itself to obtain a second hash value, and compare the first hash value with the second hash value: if the two are consistent, the bytecode deployed by the down-link privacy computing node 52 is correct and has no error, and the bytecode is not replaced or has other accidents in the transmission process, and the client 51 can confirm that the deployment of the down-link privacy computing node 52 is successful; if the two are not consistent, the client 51 may consider that the deployment of the under-chain contract fails, or that the deployed under-chain contract is at risk. The client 51 may mark successfully deployed in-chain contracts as trusted contracts and unsuccessfully deployed in-chain contracts as untrusted contracts or as non-maintained, so that calls may be made in subsequent processes only for trusted contracts. If the client 51 transmits the bytecode to the down-link privacy computing node 52 through the down-link path, the down-link privacy computing node 52 returns the deployment result information to the client 51 through the down-link path as well; if the client 51 transmits the bytecode to the down-link privacy computing node 52 through the up-link path, the down-link privacy computing node 52 also feeds back the deployment result information to the client 51 through the up-link path.

When the private computation nodes under the chain belong to the private computation cluster under the chain, the control node uniformly manages all the private computation nodes under the chain in the cluster, and then in the process of deploying the contract on the chain, the client side firstly encrypts and transmits the byte codes to the control node, and then the control node forwards the byte codes to one or more private computation nodes under the chain in the cluster, so that the byte codes of the contract on the chain are deployed to one or more private computation nodes under the chain in the cluster. If the private computing nodes are deployed to a plurality of the down-link private computing nodes, the down-link private computing nodes can simultaneously provide calling capacity aiming at the same down-link contract, so that parallel down-link private computing is realized, and load balancing can be realized among the plurality of the down-link private computing nodes.

Taking the scenario shown in fig. 6 as an example, in one case, the client 61 may directly send the bytecode ciphertext to the control node 62 through a link-down channel, that is, the client 61 transmits the bytecode to the control node 62 in a link-down encrypted manner, and then the bytecode is forwarded to one or more link-down privacy computing nodes in the cluster by the control node 62. in another case, the client 61 may transmit the bytecode in an encrypted manner to the control node 62 through the blockchain network 63, that is, the client 61 transmits the bytecode ciphertext encrypted onto the control node 62 in a link-up encrypted manner, the process of the link-up encrypted transmission may include three steps, step ①, the client 61 submits a transaction for deploying a link-down contract, that is, a link-down contract deployment transaction, to the blockchain network 63, which may be received and executed by a certain node 63n in the blockchain network 63, step ②, the node 63n invokes a prolog machine which may pass the bytecode included in the link-down contract deployment to a prolog machine 64 under the link, for example, the prolog machine contract code which may be generated by the prolog machine, and then forwarded to the control node 62 through a link-down channel network ③, and thus, the prolog machine may listen to the prefix server, and thus generate a plurality of the prolog machine.

If only one down-chain privacy computing node, such as the down-chain privacy computing node 62n shown in fig. 6, is needed, similar to the embodiment shown in fig. 5, the client 61 or the node 63n only needs to ensure that the down-chain privacy computing node 62n can decrypt when encrypting the bytecode. For example, the encryption public key generated by the down-link privacy computing node 62n in the down-link TEE may be used to encrypt the bytecode, and after receiving the bytecode ciphertext, the down-link privacy computing node 62n may decrypt the bytecode ciphertext through the encryption private key in the down-link TEE, so as to obtain the plaintext bytecode. Meanwhile, the client 61 may carry deployment target indication information, and the control node 62 may determine, according to the deployment target indication information, that the corresponding deployment target is the down-link privacy computing node 62n, so as to accurately forward the bytecode ciphertext to the down-link privacy computing node 62n without forwarding to other down-link privacy computing nodes in the cluster. If the client 61 does not carry the deployment target indication information, the control node 62 may forward the bytecode ciphertext to all the down-link privacy computing nodes in the cluster, but only the down-link privacy computing node 62n can successfully decrypt and complete the deployment.

If the deployment is required to be performed on a plurality of the down-link privacy computing nodes in the cluster, in addition to an independent deployment mode, the down-link contract may be safely deployed to the plurality of the down-link privacy computing nodes at the same time in the present specification. As mentioned above, each of the private computation nodes under the chain has its own node identity information, and the node identity information relates to a key pair created by each of the private computation nodes under the chain within its own TEE, such as an encryption key pair and a signature key pair, or a key pair that combines encryption and signature functions. The following description will be given taking an encryption key pair and a signature key pair as examples. Based on that each private calculation node under the chain maintains a cluster identity key in each TEE under the chain, the private calculation cluster under the chain can be regarded as a whole, and the cluster identity keys shared by all the nodes are utilized to safely deploy the contract under the chain to a plurality of private calculation nodes under the chain, so that the plurality of private calculation nodes under the chain can decrypt the received byte code ciphertext smoothly. The cluster identity key may include a cluster encryption key pair and a cluster signature key pair, and through the above process of sharing the cluster identity key, each of the down-link privacy computing nodes maintains a cluster encryption private key and a cluster signature private key in the respective down-link TEE, so that the client 61 or the node 63n can ensure that each of the down-link privacy computing nodes can decrypt the bytecode through the cluster encryption private key in the respective down-link TEE as long as the client uses the cluster encryption public key to encrypt the bytecode, thereby obtaining the bytecode and completing deployment. Of course, even if the encryption key is deployed to only a single down-link privacy computing node, the above-mentioned cluster encryption public key may be used to encrypt the bytecode as long as the corresponding down-link privacy computing node can decrypt smoothly. In fact, based on the cluster identity, the client 61 does not need to pay attention to the other party as a single down-link privacy computing node or a down-link privacy computing cluster, and only needs to take the other party as an object and interact with the object, and does not need to pay attention to the details of the nodes or clusters behind.

Taking said any node in the embodiment of fig. 1 as an example, the deployer may initiate a challenge to said any node before deploying the target under-chain contract to said any node, and then said any node may provide its own remote attestation report, i.e. the second remote attestation report, to the deployer in response to the challenge initiated by the deployer. Wherein the deployer may send the encrypted target down-link contract if it is determined from the second remote attestation report that the second down-link trusted execution environment (i.e., the down-link trusted execution environment created by the any node) is trusted. For example, the group identity public key in the group identity key may be used to encrypt the bytecode of the contract under the target link, and then the encrypted bytecode is sent to any node. After receiving the encrypted target under-chain contract, any node decrypts the target under-chain contract through the cluster identity private key in the cluster identity key in the trusted execution environment under the second chain and deploys the target under-chain contract. After the deployment of the target under-chain contract is completed, in the case that the block link point initiates a call to the target under-chain contract through the preplan mechanism, the any node may execute the target under-chain contract in the second under-chain trusted execution environment, and feed back the execution result to the block link point through the preplan mechanism.

In addition, in the challenge process described above, if the challenge needs to be sent to the down-link privacy computing node instead of the control node directly feeding back the remote attestation report, the challenge information may also be encrypted by using the cluster encryption public key, as long as the corresponding down-link privacy computing node can decrypt the challenge smoothly. However, if it is desired that the control node directly feeds back the remote attestation report (a remote attestation report obtained in advance, or obtained by the control node initiating a challenge to the down-link privacy computing node), the challenge information should be encrypted by using the identity public key of the control node, so as to ensure that the control node can perform decryption by using the identity private key within the TEE created by the control node.

In the embodiment shown in fig. 6, the client 61 may send execution engine specifying information, so that the execution engine for executing the bytecode may be known by the down-link privacy computing node where the down-link contract is deployed, which is not described herein again, and reference may be made to the embodiment shown in fig. 5. In addition, the client 61 may receive deployment result information, where the deployment result information includes a hash value of the contract under the chain, such as a first hash value, so that the client 61 may compare the first hash value with a second hash value corresponding to the bytecode sent by the client 61, so as to determine whether the contract on the chain is successfully deployed by the privacy computation node under the chain. If the contract on the link is deployed to a plurality of privacy computation nodes under the link, the control node 62 only needs to ensure that the deployment result information fed back by all privacy computation nodes under the link is consistent, and transmit the deployment result information fed back by any privacy computation node under the link to the client 61.

Based on the above embodiments, the present specification may effectively verify, based on a remote attestation manner, the hardware security of the private computation node under the chain, the software correctness of the TEE under the chain, and the like, so that, when the private computation node under the chain is verified to be trusted, the contract under the chain is safely deployed to the private computation node under the chain in an encrypted transmission manner, and the contract under the chain is only executed within the TEE under the chain created by the private computation node under the chain, which has extremely high security, can undertake the task of private computation under the chain distributed by the block link points, and ensure that the task of private technique under the chain is executed safely, reliably, and efficiently. Meanwhile, when the computing task is executed on the private computing nodes under the chain, a consensus mechanism among the nodes is not involved, so that the computing task only needs to be executed on a single private computing node under the chain, and compared with an on-chain contract which is limited by the consensus mechanism and needs to be executed by all block chain nodes, the resource consumption caused by the execution of the computing task can be greatly reduced.

In the technical solution of the present specification, except that the private computing node under the chain may have a unified cluster identity, a contract identity may be generated for a contract under the chain deployed on the private computing node under the chain. When multiple down-link privacy computing nodes exist in the cluster, each down-link privacy computing node can establish a contract identity for the down-link contract deployed by itself, and the contract identities generated by different down-link privacy computing nodes for the same down-link contract are the same.

In the example of deploying target under-chain contracts at various nodes described above, when a target under-chain contract is deployed in any node in the under-chain privacy computing cluster, that node may generate a contract identity key for the target under-chain contract. As an exemplary embodiment, the any node, within the created under-chain trusted execution environment, generates a contract identity key corresponding to the target under-chain contract based on the common factor of each node within the under-chain private computation cluster and the global identification information of the target under-chain contract (the under-chain contract deployed by each node in the private computation cluster is the same, and the global identification information of the same under-chain contract deployed by each node is the same). And the execution result is signed by adopting a contract identity key in the chain lower trusted execution environment of any node, and the signed execution result can be fed back to the block chain node through the predictive engine mechanism. As can be seen, each of the down-link privacy computing nodes generates a contract identity key for the down-link contract that has been deployed by itself in the above manner, and it can be ensured that the contract identity keys generated by each of the nodes for the same down-link contract are also the same. Meanwhile, compared with a mode that any node uniformly generates the contract identity key and then shares the contract identity key with other nodes, the efficiency of generating the contract identity key by each node is higher. It should be noted that the key generation algorithm can be flexibly selected according to actual situations, such as a bcrypt algorithm, a scrypt algorithm, PBKDF2, and the like.

In one case, the common factor may be generated by the control node and issued by the control node in unison as each node joins the cluster, so that each node joining the cluster may maintain the common factor. In another case, the common factor includes a cluster identity key corresponding to the privacy computing cluster, the cluster identity key being used to encrypt and decrypt and/or sign and verify interactive data during interaction of the block-link nodes with nodes in the down-chain privacy computing cluster to deploy or invoke down-chain contracts.

By way of example, the contract identity key may include a contract encryption key pair and a contract signature key pair; the contract identity public key comprises a public key in a contract encryption key pair and a public key in a contract signature key pair, and the contract identity private key comprises a private key in the contract encryption key pair and a private key in the contract signature key pair. Then, in addition to encrypting the call request using the cluster identity public key, the client or the block link point may also encrypt information of the access data included in the call request using the contract encryption public key. After receiving a call request aiming at a contract under a certain chain, the private computation node under the chain decrypts the encrypted information of the access data in the call request by adopting a contract encryption private key corresponding to the contract under the chain, thereby ensuring that the information of the access data can only be obtained by the called contract under the chain and can not be obtained by other contracts under the chain. And after the execution result of the contract under the target chain is obtained, the private computation node under the chain signs the execution result by adopting a contract identity private key of the contract under the target chain in the trusted execution environment under the chain before feeding the execution result back to the block chain link point through a preplan mechanism, and then the signed execution result is judged to be generated by the contract under the target chain under the condition that the signature verification is carried out on the execution result by adopting a contract identity public key of the contract under the target chain and the signature verification is passed. In other words, the private chain computing node may sign the execution result with the contract signature private key of the invoked contract under the chain, and the client or node may verify the execution result with the contract signature public key to determine that the execution result was indeed generated by the invoked contract under the chain

The chain privacy computing node can select a uniform cluster identity key and a contract ID of a chain contract, and derive the cluster identity key and the contract ID by adopting a key derivation algorithm to obtain a corresponding contract identity key, and because the cluster identity keys are the same and the contract IDs of different chain contracts are different, the following can be ensured: different down-link contracts deployed on the same down-link privacy computing node have different contract identities, while the same down-link contract deployed on different down-link privacy computing nodes have the same contract identity. Correspondingly, when the control node distributes the received call request, the control node only needs to pay attention to the idle degree of each linked privacy computing node in the cluster, and performs task distribution based on the idle degree without paying attention to other information. The key derivation algorithm may be flexibly selected according to actual situations, for example, a PBKDF2 key derivation algorithm may be used, but this specification is not limited thereto.

Based on the chain contract deployment scheme of the present specification, the block link point may allocate the computation task to the chain privacy computation node, and invoke the chain contract deployed on the chain privacy computation node, and execute the chain contract in the chain TEE created by the chain privacy computation node to complete the computation task. Through technologies such as remote certification, encrypted transmission, signature-based identity verification and the like, the reliability of a calculation result obtained by the privacy calculation node under the chain can be ensured, data leakage cannot be caused in the calculation process, and the method has extremely high safety. After the calculation is completed, the block chain link points can update the block chain account book data according to the calculation result, can perform solidification evidence storage on the calculation result, and can support later verification aiming at the calculation result. Meanwhile, compared with the uplink data generated after the block link point performs the on-chain contract, the calculation result generated based on the off-chain contract is relatively shorter, so that the calculation result is beneficial to saving the on-chain storage space when being linked.

Before the user calls the target under-chain contract through the client, the user can initiate a challenge to the target under-chain contract deployed in the under-chain privacy computing node to ensure that the target under-chain contract deployed in the under-chain privacy computing node is credible, and then the computing task is executed according to the expectation of the user.

FIG. 7 is a flowchart of a method for a client-side validation contract provided by an exemplary embodiment. As shown in fig. 7, the method may include the steps of:

step 702, a client acquires a remote attestation report of a trusted execution environment created by a private computing node under a link, where the remote attestation report is generated by an authentication server after verifying self-referral information generated by the private computing node under the link for the trusted execution environment under the link.

In the embodiment, two forms of single node and the private computation cluster under the chain are included. According to the single-node form, the identity information of the private computing node under the chain is the node identity information of the private computing node under the chain, the identity private key of the private computing node under the chain is the node identity private key of the private computing node under the chain, and the identity public key of the private computing node under the chain is the node identity public key of the private computing node under the chain. For the form of the down-link privacy computing cluster, under the condition that the down-link privacy computing node belongs to the down-link privacy computing cluster, the down-link privacy computing node represents the down-link privacy computing cluster to interact with an external object. Therefore, the identity information of the privacy computation node under the link is the cluster identity information of the privacy computation cluster under the link, the identity public key of the privacy computation node under the link is the cluster identity public key in the cluster identity key of the privacy computation cluster under the link, and the identity private key of the privacy computation node under the link is the cluster identity private key in the cluster identity key. The cluster identity key is used for encrypting and decrypting the interactive data and/or signing and verifying the signature in the process that the block link node interacts with each node in the private computation cluster under the chain to deploy or call contract under the chain.

Taking the first identity information as an example, for a single-node form, the first identity information provided by the private computation node under the chain is node identity information (not including a node identity private key) of the private computation node under the chain, the identity public key is a node identity public key of the private computation node under the chain, and the other identity information (the identity information except the identity public key) is other node identity information of the private computation node under the chain, that is, the other node identity information except the node identity public key in the node identity information. For the form of the down-link privacy computing cluster, the first identity information provided by the down-link privacy computing node is the cluster identity information of the down-link privacy computing cluster, the identity public key is the cluster identity public key of the down-link privacy computing cluster, and the other identity information (the identity information except the identity public key) is the identity information of the other nodes. And for the second identity information provided by the private computing node under the chain, on the basis of the first identity information, the hash value of the preset information of the trusted execution environment under the chain is also included, and other contents are the same and are not repeated herein.

Step 704, the client, in a case that it is determined that the under-chain trusted execution environment is trusted according to the remote attestation report, acquires contract information to be verified of a target under-chain contract deployed at the under-chain private computing node, where the contract information to be verified is signed by the under-chain private computing node in the under-chain trusted execution environment by using an identity private key of the under-chain private computing node, and the identity private key is maintained by the under-chain private computing node in the under-chain trusted execution environment.

Step 706, the client performs signature verification on the contract information to be verified by using the node identity public key of the private computation node under the chain, performs contract information verification on the contract information to be verified according to the contract information of the contract under the target chain, and determines that the contract under the target chain is executed by the private computation node under the chain in the trusted execution environment under the chain when the client initiates calling on the contract under the target chain through the preplan mechanism of the block chain node under the condition that the signature verification and the contract information verification pass.

For a single node form, as shown in fig. 8, similar to the embodiment shown in fig. 3, the client 81 may initiate a challenge down-link or a challenge up-link to the privacy-computation-node 82. the process of initiating the challenge up-link may include three steps, step ①, the client 81 submitting a transaction to the blockchain network 83 for initiating a challenge to the target-link contract, for example, a challenge transaction, which may be received and executed by a certain node 83n within the blockchain network 83, step ②, the node 83n invoking a pre-deployed preproduction contract, which may transfer challenge information contained in the challenge transaction to a preproduction server 84 down-link, for example, the preproduction contract may generate an event containing the challenge information, and the preproduction server 84 may listen to the contract-generated event to obtain the challenge information, step ③, the preproduction server 84 sending the challenge information to the control node 82 through a channel down-link.

By initiating a challenge for a target down-link contract deployed by the down-link privacy computing node 82, the client 81 may obtain a remote attestation report for the down-link TEE created by the down-link privacy computing node 82, the remote attestation report being generated by the authentication server after verifying the self-referral information generated by the down-link privacy computing node 82 for the down-link TEE. In one case, a challenge is initiated by the client 81 to the down-chain privacy computing node 82, the challenge is a target down-chain contract deployed by the down-chain privacy computing node 82, and the remote attestation report and the contract information to be verified returned by the down-chain privacy computing node 82 in response to the challenge are received, that is, the down-chain privacy computing node 82 returns the remote attestation report and the contract information to be verified to the client 81 in one time in response to the challenge. In another case, the client 81 initiates a challenge to the down-chain privacy computing node 82, the challenge target is a down-chain TEE created by the down-chain privacy computing node 82, and then receives a remote attestation report returned by the down-chain privacy computing node 82, and in a case that the down-chain TEE is determined to be trusted according to the remote attestation report, sends an acquisition request for contract information of a target down-chain contract deployed at the down-chain privacy computing node 82 to the down-chain privacy computing node 82, and receives contract information to be verified returned by the down-chain privacy computing node 82 in response to the acquisition request. In the case where the down-link TEE is determined to be untrusted based on the remote attestation report, there is no need to request the down-link privacy computing node 82 to obtain contract information for the target down-link contract (i.e., contract information to be verified).

Wherein the client 81 may initiate a challenge to the challenge target through an on-chain challenge. For example, a challenge transaction for the challenge target is submitted to the blockchain node 83n, and the challenge transaction includes challenge information transmitted by the blockchain node 83n to the down-chain privacy computing node 82 through the prolog mechanism, and the challenge information is used for initiating a challenge to the challenge target. Alternatively, the client 81 initiates the down-link challenge directly to the challenge target in the down-link privacy computing node 82.

In this embodiment, the operation of the client 81 to verify the down-link TEE of the down-link privacy computing node 82 according to the remote attestation report may include: and performing signature verification on the remote certification report according to a public key of the authentication server, extracting a first hash value to be verified from self-recommended information carried by the remote certification report under the condition that the signature verification is passed and a remote authentication result contained in the remote certification report is that the remote certification report passes the authentication, wherein the first hash value to be verified is a hash value of preset information of the TEE under the chain, and comparing a first standard hash value which is obtained in advance and aims at the TEE under the chain with the first hash value to be verified. Wherein, the consistency of the comparison result is used as a precondition for confirming the credibility of the TEE under the chain. It should be noted that, in this part, reference may be made to the foregoing process of verifying the node to be added by the control node, and details are not described herein again.

As shown in fig. 8, in an embodiment, after the node identity information of the node 82 is generated in the chain TEE, the generated node identity information may be subjected to hash calculation to obtain a second standard hash value; the generated node identity information includes a node identity public key of the down-link privacy computing node 82 and other identity information of the down-link privacy computing node 82. Then, the client 81 may verify the first node identity information (i.e., the declared node identity information, which includes the node identity public key of the private computing node 82 under the chain and other identity information of the private computing node 82 under the chain, and is not necessarily real data, and may be understood as the identity information to be verified) provided by the private computing node 82 under the chain by using the second standard hash value, and obtain the node identity public key included in the node identity information of the private computing node 82 under the verifiable chain if the verification passes, so as to complete the subsequent verification of the contract under the target chain by using the node identity public key. For example, the client performs hash calculation on the acquired first node identity information to obtain a second hash value to be checked, and compares the second hash value to be checked with a second standard hash value provided by the down-link privacy computing node 82, so as to determine that the node identity information is verified under the condition that the comparison result is consistent. Since the node identity information is generated and calculated by the down-link privacy computing node 82 in the down-link TEE, and then the second standard hash value is obtained, after the down-link TEE is judged to be trusted according to the remote certification report, if the second hash value to be verified is the same as the second standard hash value, it is indicated that the first node identity information provided by the privacy computing node 82 is the node identity information generated in the down-link TEE, and therefore the node identity public key included therein is the actual node identity public key of the privacy computing node 82, and the actual node identity public key of the privacy computing node 82 can be used for verifying the signature of the privacy computing node 82. The downlink privacy computation node 82 may send the second standard hash value, the remote attestation report, and the first node identity information to the client 81. It should be noted that, in this part, reference may be made to the foregoing process of verifying the node to be added by the control node, and details are not described herein again.

As shown in fig. 8, in another embodiment, the node identity information generated by the down-link privacy computing node 82 in the down-link TEE includes a node identity public key of the down-link privacy computing node 82, other identity information of the down-link privacy computing node 82, and a hash value of preset information of the down-link TEE, and then the down-link privacy computing node 82 performs hash calculation on the generated node identity information after generating the node identity information in the down-link TEE to obtain a third standard hash value, and then the third standard hash value is equivalent to simultaneously implementing the functions of the first hash value to be checked and the second standard hash value. In particular, the down-link privacy computing node 82 may provide the client 81 with the remote attestation report, the third standard hash value, and the second node identity information (which may be understood at this time as the identity information to be verified). The second node identity information comprises a node identity public key of the down-link privacy computing node 82, other identity information of the down-link privacy computing node 82 and a fourth hash value to be verified, wherein the fourth hash value to be verified is a hash value of preset information of the down-link TEE; meanwhile, the second node identity information is declared node identity information, and is not necessarily real node identity information of the down-link privacy computing node 82. Then, the client 81 performs signature verification on the remote attestation report according to the public key of the authentication server, performs hash calculation on the acquired second node identity information to obtain a third hash value to be verified under the condition that the signature verification is passed and the remote authentication result included in the remote attestation report is that the remote authentication result is passed, and compares the third hash value to be verified with the third standard hash value. When the comparison result is consistent, it is described that the second node identity information provided by the privacy computing node 82 is the node identity information generated in the chain TEE, that is, the fourth hash value to be verified included therein is the hash value of the actual preset information of the chain TEE. Therefore, a fourth standard hash value and a fourth hash value to be checked, which are obtained in advance and are used for the chain TEE preset information, are further compared, and the comparison result is consistent to be used as a precondition for confirming that the chain TEE is credible. Meanwhile, the node identity public key included in the second node identity information may be determined as the actual node identity public key of the privacy computing node 82, and may be used to perform signature verification on the contract information to be verified. The downlink privacy computation node 82 may send the third standard hash value, the remote attestation report, and the second node identity information to the client 81. It should be noted that, in this part, reference may be made to the foregoing process of verifying the node to be added by the control node, and details are not described herein again.

Under the condition that the client 81 determines that the chain-down TEE is credible according to the remote certification report, acquiring contract information to be verified of a target chain-down contract arranged at the chain-down privacy computing node 82, wherein the contract information to be verified is signed by the chain-down privacy computing node 82 in the chain-down TEE by using a node identity private key of the client, and the node identity private key is generated by the chain-down privacy computing node 82 in the chain-down TEE. For example, the down-chain privacy computing node 82 may read the deployed target down-chain contract into the down-chain TEE and sign with its own node identity private key.

The client 81 performs signature verification on the contract information to be verified by using the node identity public key of the down-link privacy computing node 82, and performs contract information verification on the contract information to be verified according to the contract information of the target down-link contract. Wherein the node identity public key is in a public state, such as the node identity public key is published to the outside by the private computing node 82 in the chain for acquisition by the client 81. Alternatively, the client 81 obtains the node identity information of the privacy computation node 82 through the verification link. Meanwhile, contract information of the target down-link contract may also be in a public state, such as the deployment direction of the target down-link contract developing the contract information to be acquired by the client 81. The contract information may include information such as a name, a description, a version number, a bytecode hash value, and a contract identity public key of the linked contract, which is not limited in this specification.

In the event that the signature verification and contract information verification pass, the client 81 may determine that the client 81 is executing in the down-chain TEE trusted execution environment by the down-chain privacy computing node 82 when a call is initiated to the target down-chain contract through the prolog mechanism of the blockchain node. In this specification, the process of verifying the contract under the chain is to verify that the contract under the chain of the privacy computing node 82 is trusted, and then, under the condition that the contract under the chain of the privacy computing node 82 is trusted, if the signature is verified to obtain that the contract information to be verified provided by the privacy computing node 82 under the chain is indeed signed by the node identity private key (maintained in the TEE under the chain) of the privacy computing node 82 under the chain, it can be determined that the currently challenged contract under the chain is a target contract under the chain running in the TEE of the privacy computing node 82 under the chain, that is, it is ensured that the contract under the target chain deployed in the privacy computing node 82 under the chain is trusted, and the computing task can be executed according to the expectation of the user.

For the form of a private computing cluster down the chain, as shown in fig. 9, client 91 may initiate a challenge down the chain or a challenge up the chain to control node 92, similar to the embodiment shown in fig. 4, the process of initiating a challenge up the chain may include three steps, step ①, client 91 submitting a transaction to a blockchain network 93 for initiating a challenge to a target link down contract, for example, called a challenge transaction, which may be received and executed by a certain node 93n within blockchain network 93, step ②, node 93n invoking a pre-deployed preproduction contract that may pass challenge information contained in the challenge transaction to a preproduction server 94 down the chain, for example, preproduction contract may generate an event containing the challenge information, and preproduction server 94 may listen for the contract generated event to obtain the challenge information, step ③, preproduction server 94 sending the challenge information to control node 92 through a channel down the chain.

The private computing cluster in the chain as a whole provides the functionality of performing computing tasks outward. In this case, each node in the cluster may be deployed with the same contract under the link, and then each node may perform a computing task on behalf of the cluster, for example, the computing task may be distributed by the control node. Therefore, when each node performs data interaction with the outside on behalf of the cluster, the data interacted with the outside is decrypted or signed by using the cluster identity key representing the cluster identity, rather than using the node identity key of the node itself. Correspondingly, when the external object interacts with the cluster through the client, the cluster is regarded as a whole without paying attention to the internal structure of the cluster, and therefore the cluster identity key is adopted for encryption or signature verification.

As shown in fig. 9, a user may initiate a challenge to a target under-chain contract deployed in a cluster through a client 91 before invoking the target under-chain contract in the cluster through the client 91. The control node 92, upon receiving the challenge, may select any node in the cluster to respond to the challenge. For example, the master node for generating the cluster identity key may be selected, or a slave node in the cluster may be selected, and the specification does not limit the manner of selecting the node responding to the challenge. The example of node 92n responding to the challenge is illustrated. Control node 92 selects node 92n to respond to the challenge on behalf of the cluster, providing a cluster remote attestation report on behalf of the cluster to the challenger. The cluster remote attestation report is generated by the authentication server after verifying the self-referral information generated by the node 92n for the own chain TEE, that is, the cluster remote attestation report is a remote attestation report corresponding to the chain TEE of the node 92 n. Specifically, the self-recommendation information carried by the cluster remote attestation report includes a first hash value to be verified, where the first hash value to be verified is a hash value of preset information of the chain-down TEE of the node 92n, the first hash value to be verified is used for the challenger to perform signature verification and pass signature verification on the cluster remote attestation report according to the public key of the authentication server, and when the remote authentication result included in the cluster remote attestation report is authenticated, the cluster remote attestation report is compared with a first standard hash value (for example, a trusted hash value of the preset information of the chain-down TEE) for the chain-down TEE obtained in advance, and the comparison result is consistent and is used as a precondition for the challenger to confirm that the chain-down TEE is authentic. The process of verifying the chain-down TEE by the challenger according to the cluster remote certification report may refer to the content of the chain-down TEE verified by the control node to be added to the node, which is not described herein again. In effect, the challenger reports the verified down-chain TEE from the cluster remote attestation as the down-chain TEE for node 92 n.

As shown in fig. 9, in an embodiment, when the node 92n generates its own node identity information in the chain TEE, cluster identity information representing a cluster may also be generated in the chain TEE, and the generated cluster identity information is subjected to hash calculation to obtain a second standard hash value; the generated cluster identity information includes the cluster identity public key and other identity information except the node identity public key in the node identity information of the node 92 n. In other words, based on representing a cluster by node 92n, the difference between the node identity information of node 92n and the cluster identity information is: the public key recorded in the node identity information is a node identity public key, and the public key recorded in the cluster identity information is a cluster identity public key; otherwise, the identity information is the same. Then, the client 91 may verify the first cluster identity information (i.e., the declared cluster identity information, which includes the cluster identity public key and other identity information of the node 92n, and is not necessarily real data, and may be understood as identity information to be verified) provided by the node 92n by using the second standard hash value, and obtain the cluster identity public key included in the cluster identity information when the verification passes, so as to complete the subsequent verification of the contract under the target link by using the cluster identity public key. For example, the client performs hash calculation on the acquired first cluster identity information to obtain a second hash value to be verified, and compares the second hash value to be verified with a second standard hash value provided by the node 92n, so as to determine that the cluster identity authentication is passed when the comparison result is consistent. Since the cluster identity information is generated and calculated by the node 92n in the chain TEE, and then the second standard hash value is obtained, after the chain TEE is judged to be trusted according to the remote certification report, if the second hash value to be verified is the same as the second standard hash value, it is indicated that the first cluster identity information provided by the privacy calculation node 92 is the cluster identity information generated in the chain TEE, so that the cluster identity public key included therein is the cluster identity public key corresponding to the cluster actually maintained by the privacy calculation node 92, and the cluster identity public key actually maintained by the privacy calculation node 92 can be used for verifying the signature of the privacy calculation node 92. The node 92n may send the second standard hash value, the remote attestation report, and the first cluster identity information to the client 91 through the control node 92. It should be noted that, in this part, reference may be made to the foregoing process of verifying the node to be added by the control node, and details are not described herein again.

As shown in fig. 9, in another embodiment, the cluster identity information generated by the node 92n in the chain-down TEE may include a cluster identity public key, hash values of other identity information except the node identity public key in the node identity information of the node 92n and preset information of the chain-down TEE, and then the node 92n generates the cluster identity information in its own chain-down TEE, and performs hash calculation on the generated cluster identity information to obtain a third standard hash value, where the third standard hash value is equivalent to simultaneously implementing the functions of the first hash value to be tested and the second standard hash value. In particular, node 92n may provide the client 91 with a remote attestation report, a third standard hash value, and second cluster identity information (which at this point may be understood as identity information to be verified). The second cluster identity information comprises a cluster identity public key, other identity information of the node 92n and a fourth hash value to be verified, wherein the fourth hash value to be verified is a hash value of preset information of the TEE under the link; meanwhile, the second cluster identity information is declared cluster identity information, and is not necessarily real cluster identity information provided for the node 92 n. Then, the client 91 performs signature verification on the remote attestation report according to the public key of the authentication server, performs hash calculation on the acquired second cluster identity information to obtain a third hash value to be verified under the condition that the signature verification is passed and the remote authentication result included in the remote attestation report is that the remote authentication result is passed, and compares the third hash value to be verified with a third standard hash value. When the comparison result is consistent, it is indicated that the second cluster identity information provided by the privacy computing node 92 is the cluster identity information generated in the chain TEE, that is, the fourth hash value to be verified included therein is the hash value of the actual preset information of the chain TEE. Therefore, a fourth standard hash value and a fourth hash value to be checked, which are obtained in advance and are used for the chain TEE preset information, are further compared, and the comparison result is consistent to be used as a precondition for confirming that the chain TEE is credible. Meanwhile, the cluster identity public key included in the second cluster identity information may be determined as the cluster identity public key actually maintained by the privacy computing node 92, and may be used to perform signature verification on the contract information to be verified. The node 92n may send the third standard hash value, the remote attestation report, and the second cluster identity information to the client 91 through the control node 92. It should be noted that, in this part, reference may be made to the foregoing process of verifying the node to be added by the control node, and details are not described herein again.

Similar to the embodiment shown in fig. 8, the cluster remote attestation report and the contract information to be verified are sent to the control node 92 by the node 92n, and then forwarded to the client 91 by the control node 92. The control node 92 may provide the cluster remote attestation report and the contract information to be verified to the client 91 together, or may provide the cluster remote attestation report first, and after the client 91 passes verification according to the cluster remote attestation report, obtain the contract information to be verified from the node 92n to provide the contract information to be verified to the client 91. The contract information to be verified is contract information of a target under-chain contract deployed at the node 92n, and the node 92n performs signature in the under-chain TEE of the node 92n by using a cluster identity private key (maintained in the under-chain TEE of the node 92 n). For example, the node 92n reads the target under-chain contract deployed at the node 92n into the under-chain TEE and signs with the cluster identity private key.

The client 91 performs signature verification on the contract information to be verified by using the cluster identity public key under the condition that the chain TEE is determined to be credible (namely the chain TEE of the node 92n, the node 92n represents the cluster, and the user cannot sense other nodes in the cluster) according to the cluster remote certification report, and performs contract information verification on the contract information to be verified according to the contract information of the target chain contract. Wherein the cluster identity public key is in a public state, for example, the control node 91 publishes the cluster identity public key to the outside for being acquired by the client 91. Alternatively, the client 91 obtains the cluster identity information by the above-mentioned method. Meanwhile, contract information of the target down-link contract may also be in a public state, such as the deployment direction of the target down-link contract developing the contract information to be acquired by the client 91. The contract information may include information such as a name, a description, a version number, a bytecode hash value, and a contract identity public key of the linked contract, which is not limited in this specification.

Similar to the principle of verifying the target under-chain contract in the single-node form described above, in the case that the signature verification and contract information verification pass, the client 91 may determine that the client 91 initiated a call to the target under-chain contract through the prolog mechanism of the blockchain node, which was executed by the node 92n in the under-chain TEE trusted execution environment, i.e., ensure that the target under-chain contract deployed in the node 92n is trusted, and may perform the computing task as intended by the user.

It should be noted that, in the form of the down-link privacy computing cluster, each type of remote attestation report may have a certain time limit, such as 30 minutes or other duration, and the remote attestation report that is out of time is determined to be invalid. For example, the remote attestation reports involved in the process of sharing the cluster identity key are all acquired by the nodes from the authentication server control node in real time, and the cluster remote attestation reports can be cached locally by the control node and set the aging duration.

The block chain node updates the block chain ledger data according to the calculation result, or refers to performing uplink on the calculation result, and the method may include: generating a block chain transaction, adding a calculation result to a data field of the transaction, and adding each block chain link point to a block body of a latest block after the block chain transaction passes consensus, so that updating of block chain account data is realized, namely, the uplink of the calculation result is completed; or, the block link point updates the state of the related account according to the calculation result, the related account may be, for example, an external account corresponding to the user or a contract account corresponding to a contract on the chain, the update of the state of the related account may cause a value change of a root of a state tree (state tree), and the root of the state tree may be included in the block header of the latest block, thereby implementing the update of the block chain account data, that is, equivalent to linking the calculation result.

The contract under the chain in this specification may implement any computational logic defined by the user. For example, the under-chain contract may be used to verify whether the amount of the encrypted order data stored on the blockchain is correct, and feed back the verification result to the chain; for another example, the under-link contract may be used to perform secure computation on the multi-party data according to a preset algorithm, that is, secure multi-party computation, and feed back the computation result to the link, and so on, which is not described herein any more.

As shown in FIG. 10, assume that client 1001 wishes to make a call to a deployed under-chain contract (such as after verifying that the target under-chain contract passes). The client 1001 may send a call request to the control node 1002 through a downlink channel, where the call request is encrypted by using a public key of a cluster identity, and the control node 1002 may distribute the call request to a certain downlink privacy computing node in the cluster, such as the node 1002n, based on a load balancing algorithm, where the node 1002n responds to the call request. The node 1002n decrypts the call request by the cluster identity private key in the chain TEE created by itself, and obtains the information of the contract ID, the function name and the parameter data included in the call request. The contract ID may be, for example, a hash of the bytecode of the contract under the chain, so that the node 1002n can find the bytecode of the corresponding deployed contract under the chain based on the hash. The contract under the chain may contain multiple functions, so the function name may specify the function that the client 1001 wishes to call; if the contract under the chain contains only one function, or if the client 1001 wishes to call all functions in the contract under the chain, the information of the function name may also be omitted from the call request. The information of the entry data may be the entry parameter data itself, or the description information of the entry parameter data, for example, the description information may be a storage address, so that the node 1002n may obtain the entry parameter data accordingly, and particularly, when the client 1001 itself is not the data owner, the interaction between the client 1001 and the data owner may be omitted, and the data amount of the call request may be reduced, and the transmission speed thereof may be increased. Then, the node 1002n may execute the byte code of the down-link contract in the down-link TEE to process the in-parameter data, thereby obtaining a corresponding call result. The node 1002n may encrypt the call result in the down-link TEE and feed back the call result to the client 1001 through the control node 1002.

The client 1001 may send a call request to the control node 1002 through an on-chain channel. The client 1001 may submit a contract-down-link call transaction to the blockchain network 1003, which includes a call request encrypted by the client 1001 using the cluster identity public key. Of course, the contract invoking transaction itself under the link may also be encrypted for transmission, for example, the contract invoking transaction is encrypted by using the public key of the cluster identity, or other encryption methods, which may refer to the content of the data encryption transmission described above, and will not be described herein again. The chain contract invocation transaction may invoke a predictive engine contract such that the predictive engine contract generates a corresponding contract event for the invocation request included in the transaction, which contract event is heard by the predictive engine server 1004 before the invocation request is retrieved by the predictive engine server 1004 and transmitted to the control node 1002. The control node 1002 then distributes the invocation request, for example, to the down-link privacy computing node 1002n for response. And, the control node 1002 may feed back the invocation result to the chain through a prediction mechanism, and the node 1003n may initiate a transaction actively, and chain the invocation result, or the node 1003n may feed back the invocation result to the client 1001, and the client 1001 re-initiates a transaction to chain the invocation result.

If the import parameter data is blockchain data, the client 1001 may submit an encrypted contract-down-link call transaction to the blockchain network 1003, where the contract-down-link call transaction includes information of a contract ID, a function name, and the import parameter data, and the contract-down-link call transaction calls an contract on the link for acquiring the import parameter data. After receiving the encrypted under-chain contract invoking transaction, the node 1003n decrypts the on-chain TEE created by the node 1003n, executes the invoked on-chain contract through a virtual machine deployed in the on-chain TEE to obtain blockchain data serving as entry data, the blockchain data is usually in an encrypted state, the node 1003n can decrypt the data in the on-chain TEE into a plaintext, then packages the blockchain data of the plaintext and a contract ID and a function name included in the under-chain contract invoking transaction into an invoking request, encrypts the invoking request in the on-chain TEE by using a cluster identity public key, then transmits the invoking request to the control node 1002 based on a preplan mechanism, and the control node 1002 distributes the invoking request to the under-chain privacy computing node 1002n for response. And, the control node 1002 may feed back the call result to the chain through a prediction mechanism, and the node 1003n may chain the call result.

In addition to encrypting the call request using the cluster identity public key, the client 1001 or node 1003n may encrypt information of the access data included in the call request using a contract encryption public key. After receiving a call request for a contract under a certain chain, the private chain computing node 1002n decrypts the encrypted information of the access data in the call request by using the contract encryption private key corresponding to the contract under the chain, thereby ensuring that the information of the access data can only be obtained by the called contract under the chain and cannot be obtained by other contracts under the chain. And after obtaining the invocation result (i.e., the execution result obtained by executing the down-chain contract), the down-chain privacy computing node 1002n may sign the invocation result through the contract signature private key of the invoked down-chain contract, and the client 1001 or node 1003n may check and sign through the contract signature public key, thereby determining that the invocation result is indeed generated by the invoked down-chain contract.

In the embodiment shown in fig. 10, the example of the private computation cluster is described. In fact, the client 1001 may also directly interact with a single down-link privacy computing node to invoke a down-link contract deployed on the down-link privacy computing node, which is not described herein again.

It should be noted that, in this specification, the encryption and decryption, the generation of the signature and the verification of the signature may use the same set of key pairs, or configure a set of encryption key pairs and a set of signature key pairs separately. Wherein, in a set of key pairs, there may be multiple public keys and corresponding private keys at the same time, corresponding to different encryption algorithms. In the following, a node identity key is taken as an example, and a cluster identity key and a contract identity key are similar to the node identity key.

In one case, the node identity key is a set of key pairs comprising a node identity public key and a node identity private key. The node identity public key can be used for encrypting data, and then the node identity private key can be used for decrypting the data; the node identity private key can be used for signing data, and then the node identity public key can be used for signature verification of the data. In another case, two sets of key pairs, respectively a node encryption key pair and a node signing key pair, may be configured. The node encryption key pair is used for encrypting and decrypting data, and the node signature key pair is used for signing and verifying signature of the data.

Corresponding to the above embodiment of the client side, the present specification also proposes an embodiment of the private computation node side in the chain, and the description related to the embodiment of the client side may also be applied to the embodiment of the private computation node side in the chain, which is not described again in the following.

Accordingly, FIG. 11 is a flowchart of a method for verifying contracts on the private computing node side of a chain according to an exemplary embodiment. As shown in fig. 11, the method may include the steps of:

step 1102, a down-link privacy computing node provides a remote attestation report of a down-link trusted execution environment created by the down-link privacy computing node to a client, wherein the remote attestation report is generated by an authentication server after verification of self-recommendation information generated by the down-link privacy computing node for the down-link trusted execution environment.

As previously described, the operation of the down-link privacy computing node to provide a client with a remote attestation report for a down-link trusted execution environment created by the down-link privacy computing node may include: receiving a challenge initiated by the client to the downlink privacy computation node, and returning the remote attestation report to the client; or, when the down-link privacy computing node belongs to the down-link privacy computing cluster, after receiving the fight initiated by the client, the control node of the down-link privacy computing cluster sends the remote attestation report to the control node, and the remote attestation report is returned to the client by the control node.

As described above, the self-referral information carried by the remote attestation report includes a first hash value to be verified, where the first hash value to be verified is a hash value of preset information of the trusted execution environment under the chain, and the first hash value to be verified is used for comparing, by the client, a first standard hash value obtained in advance for the trusted execution environment under the chain when the signature verification is performed on the remote attestation report according to the public key of the authentication server and the signature verification passes and a remote authentication result included in the remote attestation report is authentication passing, and a comparison result is consistent and is used as a precondition for the client to confirm that the trusted execution environment under the chain is trusted.

And 1104, the private chain computing node providing, to the client, contract information to be verified of a target private chain contract deployed at the private chain computing node, where the contract information to be verified is signed by the private chain computing node in the trusted chain execution environment by using an identity private key of the private chain computing node, where the identity private key is maintained by the private chain computing node in the trusted chain execution environment.

And under the condition that the client determines that the under-chain trusted execution environment is trusted according to the remote certification report, the client performs signature verification on the contract information to be verified by adopting the identity public key of the under-chain privacy computation node, performs contract information verification on the contract information to be verified according to the contract information of the target under-chain contract, and under the condition that the signature verification and the contract information verification pass, determines that the target under-chain contract is executed in the under-chain trusted execution environment by the under-chain privacy computation node when the client initiates calling on the target under-chain contract through a prompter mechanism of a block chain node.

In an embodiment, the downlink privacy computing node provides first identity information to the client, where the first identity information includes an identity public key of the downlink privacy computing node and other identity information of the downlink privacy computing node, and the first identity information is subjected to hash calculation by the client to obtain a second hash value to be verified;

the chain privacy computing node provides a second standard hash value for the client, and the second standard hash value is obtained by performing hash computation on generated identity information after the chain privacy computing node generates identity information of the chain privacy computing node in the chain trusted execution environment;

the second standard hash value is used for being compared with the second hash value to be verified, and the client acquires the identity public key contained in the first identity information of the privacy computation node under the condition that the comparison result is consistent.

In another embodiment, the down-link privacy computing node provides second identity information of the down-link privacy computing node to the client, where the second identity information includes an identity public key of the down-link privacy computing node, other identity information of the down-link privacy computing node, and a fourth hash value to be checked, and the fourth hash value to be checked is a hash value of preset information of the down-link trusted execution environment;

the chain privacy computing node provides a third standard hash value for the client, and the third standard hash value is obtained by performing hash calculation on generated identity information after the chain privacy computing node generates the identity information of the chain privacy computing node in the chain trusted execution environment;

the second identity information is subjected to signature verification on the remote certification report at the client according to the public key of the authentication server, and is subjected to hash calculation by the client under the condition that the signature verification is passed and the remote authentication result contained in the remote certification report is authenticated, so as to obtain a third hash value to be verified; the precondition for confirming that the trusted execution environment under the chain is trusted comprises that the fourth hash value to be verified is consistent with a fourth standard hash value, which is obtained by the client in advance and is specific to the trusted execution environment under the chain, under the condition that the third hash value to be verified is consistent with the third standard hash value; the identity public key included in the second identity information is used for signature verification of the contract information to be verified.

As mentioned above, the identity information of the down-link privacy computing node is the node identity information of the down-link privacy computing node, the identity private key is the node identity private key of the down-link privacy computing node, and the identity public key is the node identity public key of the down-link privacy computing node; or, in a case that the down-link privacy computing node belongs to a down-link privacy computing cluster, the identity information is cluster identity information of the down-link privacy computing cluster, the identity public key is a cluster identity public key in a cluster identity key of the down-link privacy computing cluster, and the identity private key is a cluster identity private key in the cluster identity key; the cluster identity key is used for encrypting and decrypting interaction data and/or signing and verifying a signature in the process of interacting block chain nodes with each node in the private computation cluster under the chain to deploy or call contract under the chain.

As previously described, the under-link privacy computing node executes the target under-link contract in response to a call initiated by a block-link node to the deployed target under-link contract through a prophetic mechanism; the invocation of the target under-chain contract by the block link point is triggered by an invocation transaction submitted by the client for the target under-chain contract.

As previously described, the under-chain privacy computing node feeds back, through the oracle mechanism, to a blockchain node an execution result that is generated by the target under-chain contract in response to invocation of the blockchain node and that is signed within the under-chain trusted execution environment by a contract identity private key of the target under-chain contract; wherein the execution result is determined to be generated by the target down-chain contract when the execution result is signature verified using the contract identity public key of the target down-chain contract and passes the signature verification.

As described above, the contract information includes the contract identity public key of the target down-link contract, and when the client initiates a call to the target down-link contract through the preplan mechanism of the block link node, the contract identity public key is used to encrypt the entry parameter data used when the target down-link contract is called, and the encrypted entry parameter data is decrypted by the contract identity private key of the target down-link contract.

In the technical scheme of the specification, the client can directly interact with the privacy computing node to complete operations of deploying the intelligent contract on the privacy computing node, initiating a challenge to the intelligent contract, verifying the intelligent contract, calling the intelligent contract and the like, the operations are not required to be completed through a preplanning machine mechanism of the block chain, and meanwhile, a computing result obtained by calling the intelligent contract deployed on the privacy computing node is not required to be fed back to the block chain. In this case, since no distinction between on-chain and off-chain is involved, the "private computing node under the chain" is hereinafter referred to as "private computing node", the "trusted execution environment under the chain" is referred to as "trusted execution environment", and the "target contract under the chain" is referred to as "target intelligent contract". However, the principle of the technical solution is similar to the above embodiments, and the implementation details can be referred to the above embodiments, so that the detailed description is not repeated below.

FIG. 12 is a flowchart of another method for client-side validation contracts provided by an exemplary embodiment. As shown in fig. 12, the method may include the steps of:

step 1202, a client acquires a remote attestation report of a trusted execution environment created by a private computing node, where the remote attestation report is generated by an authentication server after verifying self-referral information generated by the private computing node for the trusted execution environment.

Step 1204, the client, in a case that it is determined that the trusted execution environment is trusted according to the remote attestation report, obtains contract information to be verified of a target intelligent contract deployed at the private computing node, where the contract information to be verified is signed by the private computing node in the trusted execution environment by using an identity private key of the private computing node, and the identity private key is maintained by the private computing node in the trusted execution environment.

As described above, the client performs signature verification on the remote attestation report according to the public key of the authentication server; under the condition that the signature verification is passed and the remote authentication result contained in the remote attestation report is passed, extracting a first hash value to be verified from the self-referral information carried by the remote attestation report, wherein the first hash value to be verified is the hash value of the preset information of the trusted execution environment; and comparing a first standard hash value which is obtained in advance and aims at the trusted execution environment with the first hash value to be verified, and using the comparison result as a precondition for confirming that the trusted execution environment is trusted.

In step 1206, the client performs signature verification on the contract information to be verified by using the identity public key of the privacy computing node, performs contract information verification on the contract information to be verified according to the contract information of the target intelligent contract, and determines that the target intelligent contract is executed in the trusted execution environment by the privacy computing node when the client initiates call to the target intelligent contract under the condition that the signature verification and the contract information verification pass.

As described above, the client acquires first identity information provided by the privacy computing node, and performs hash computation on the acquired first identity information to obtain a second hash value to be verified, where the first identity information includes an identity public key of the privacy computing node and other identity information of the privacy computing node; the client acquires a second standard hash value provided by the privacy computing node, wherein the second standard hash value is obtained by performing hash calculation on generated identity information after the privacy computing node generates the identity information of the privacy computing node in the trusted execution environment; and the client compares the second hash value to be verified with the second standard hash value, and acquires the identity public key contained in the first identity information of the privacy computation node under the condition that the comparison result is consistent.

As described above, the client performs signature verification on the remote attestation report according to the public key of the authentication server, and acquires the second identity information provided by the privacy computation node when the signature verification passes and the remote authentication result included in the remote attestation report is that the remote authentication passes, and performs hash computation on the acquired second identity information to obtain a third hash value to be verified, where the second identity information includes the identity public key of the privacy computation node, other identity information of the privacy computation node, and a fourth hash value to be verified, and the fourth hash value to be verified is a hash value of the preset information of the trusted execution environment; acquiring a third standard hash value provided by the privacy computing node, and comparing the third hash value to be verified with the third standard hash value, wherein the third standard hash value is obtained by performing hash calculation on generated identity information after the privacy computing node generates the identity information of the privacy computing node in the trusted execution environment; under the condition that the third hash value to be verified is consistent with the third standard hash value, comparing a fourth standard hash value which is obtained in advance and aims at the trusted execution environment with the fourth hash value to be verified, and using the consistency of the comparison result as a precondition for confirming that the trusted execution environment is trusted; the identity public key included in the second identity information is used for signature verification of the contract information to be verified.

As mentioned above, the identity information of the privacy computing node is the node identity information of the privacy computing node, the identity private key is the node identity private key of the privacy computing node, and the identity public key is the node identity public key of the privacy computing node; alternatively, the first and second electrodes may be,

under the condition that the privacy computation node belongs to a private computation cluster under a chain, the identity information is cluster identity information of the private computation cluster under the chain, the identity public key is a cluster identity public key in a cluster identity key of the private computation cluster under the chain, and the identity private key is a cluster identity private key in the cluster identity key; and the cluster identity key is used for encrypting and decrypting the interactive data and/or signing and checking the signature in the process that the client interacts with each node in the down-link privacy computing cluster to deploy or call the intelligent contract.

As described previously, the client obtains an execution result fed back by the private computing node, the execution result being generated by the target intelligent contract in response to the client's invocation and being signed by a contract identity private key of the target intelligent contract within the trusted execution environment; and the client judges that the execution result is generated by the target intelligent contract under the condition that the execution result is subjected to signature verification by adopting the contract identity public key of the target intelligent contract and passes the signature verification.

As described above, the contract information includes the contract identity public key of the target intelligent contract, and when the client initiates a call to the target intelligent contract, the contract identity public key is used to encrypt the input parameter data used when the target intelligent contract is called, and the encrypted input parameter data is decrypted by the contract identity private key of the target intelligent contract.

Accordingly, FIG. 13 is a flow diagram of another method for privacy computing node side validation contracts provided by an exemplary embodiment. As shown in fig. 13, the method may include the steps of:

in step 1302, a privacy computing node provides a remote attestation report of a trusted execution environment created by the privacy computing node to a client, where the remote attestation report is generated by an authentication server after verifying referral information generated by the privacy computing node for the trusted execution environment.

As described above, the self-referral information carried by the remote attestation report includes a first hash value to be verified, where the first hash value to be verified is a hash value of preset information of the trusted execution environment, the first hash value to be verified is used for comparing, by the client, a first standard hash value obtained in advance for the trusted execution environment when the signature verification is performed on the remote attestation report according to the public key of the authentication server and the signature verification is passed and a remote authentication result included in the remote attestation report is a pass authentication, and a comparison result is consistent and is used as a precondition for the client to confirm that the trusted execution environment is trusted.

In step 1304, the privacy computing node provides, to the client, contract information to be verified of a target intelligent contract deployed at the privacy computing node, where the contract information to be verified is signed by the privacy computing node in the trusted execution environment using an identity private key of the privacy computing node, where the identity private key is maintained by the privacy computing node in the trusted execution environment.

As described above, the client performs signature verification on the contract information to be verified by using the identity public key of the privacy computing node under the condition that the trusted execution environment is determined to be trusted according to the remote attestation report, performs contract information verification on the contract information to be verified according to the contract information of the target intelligent contract, and determines that the target intelligent contract is executed in the trusted execution environment by the privacy computing node when the client initiates a call to the target intelligent contract under the condition that the signature verification and the contract information verification pass.

As described above, the privacy computing node provides first identity information to the client, where the first identity information includes an identity public key of the privacy computing node and other identity information of the privacy computing node, and the first identity information is subjected to hash calculation by the client to obtain a second hash value to be checked; the privacy computing node provides a second standard hash value to the client, and the second standard hash value is obtained by performing hash computation on generated identity information after the privacy computing node generates identity information of the privacy computing node in the trusted execution environment; the second standard hash value is used for being compared with the second hash value to be verified, and the client acquires the identity public key contained in the first identity information of the privacy computation node under the condition that the comparison result is consistent.

As described above, the privacy computing node provides second identity information of the privacy computing node to the client, where the second identity information includes an identity public key of the privacy computing node, other identity information of the privacy computing node, and a fourth hash value to be verified, and the fourth hash value to be verified is a hash value of the preset information of the trusted execution environment; the privacy computing node provides a third standard hash value to the client, and the third standard hash value is obtained by performing hash computation on generated identity information after the privacy computing node generates identity information of the privacy computing node in the trusted execution environment; the second identity information is subjected to signature verification on the remote certification report at the client according to the public key of the authentication server, and is subjected to hash calculation by the client under the condition that the signature verification is passed and the remote authentication result contained in the remote certification report is authenticated, so as to obtain a third hash value to be verified; the precondition for confirming that the trusted execution environment is trusted includes that the fourth hash value to be verified is consistent with a fourth standard hash value, which is obtained by the client in advance and is specific to the trusted execution environment, when the third hash value to be verified is consistent with the third standard hash value; the identity public key included in the second identity information is used for signature verification of the contract information to be verified.

As previously described, the private computing node feeds back to the client an execution result generated by the target intelligent contract in response to the invocation of the blockchain node and signed within the trusted execution environment by a contract identity private key of the target intelligent contract; wherein the execution result is determined to be generated by the target intelligent contract when the execution result is signature-verified by using the contract identity public key of the target intelligent contract and passes the signature verification.

As described above, the contract information includes the contract identity public key of the target intelligent contract, and when the client initiates a call to the target intelligent contract, the contract identity public key is used to encrypt the input parameter data used when the target intelligent contract is called, and the encrypted input parameter data is decrypted by the contract identity private key of the target intelligent contract. In correspondence with the above method embodiments, the present specification also provides embodiments of an apparatus for validating a contract.

Embodiments of the apparatus for validating a contract of the present specification can be applied to an electronic device. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.

Referring to fig. 14, fig. 14 is a schematic block diagram of an apparatus according to an exemplary embodiment. As shown in fig. 14, at the hardware level, the device includes a processor 1402, an internal bus 1404, a network interface 1406, a memory 1408, and a non-volatile storage 1410, although other hardware required for service may be included. The processor 1402 reads a corresponding computer program from the non-volatile storage 1410 into the memory 1408 and runs the computer program, forming a means for validating the contract on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to FIG. 15, in one software implementation, the means for validating the contract at the client side may include:

a report acquisition unit 1501, configured to enable a client to acquire a remote attestation report for a trusted execution environment under a link created by a private computing node under a link, where the remote attestation report is generated by an authentication server after verification of self-recommendation information generated by the private computing node under the link for the trusted execution environment under the link;

a contract information obtaining unit 1502 that, in a case where it is determined that the under-chain trusted execution environment is trusted according to the remote attestation report, causes the client to obtain contract information to be verified for a target under-chain contract deployed at the under-chain private computing node, where the contract information to be verified is signed by the under-chain private computing node within the under-chain trusted execution environment using an identity private key of the under-chain private computing node, where the identity private key is maintained by the under-chain private computing node within the under-chain trusted execution environment;

the verifying unit 1503 is configured to enable the client to perform signature verification on the contract information to be verified by using the identity public key of the private computing node under the chain, perform contract information verification on the contract information to be verified according to the contract information of the target contract under the chain, and determine that the target contract under the chain is executed by the private computing node under the chain in a trusted execution environment under the chain when the client initiates invocation on the target contract under the chain through a prolog mechanism of a block chain node under the condition that the signature verification and the contract information verification pass.

Optionally, the report acquiring unit 1501 is further configured to:

enabling the client to initiate a challenge to the down-link privacy computing node and receive a remote attestation report returned by the down-link privacy computing node; alternatively, the first and second electrodes may be,

and under the condition that the down-link privacy computing node belongs to the down-link privacy computing cluster, enabling the client to initiate a challenge to a control node of the down-link privacy computing cluster and receive a remote attestation report returned by the control node.

Optionally, the report acquiring unit 1501 is further configured to:

enabling the client to submit a challenge transaction to a block link point, wherein challenge information contained in the challenge transaction can be transmitted to the downlink privacy computation node or the control node through a prediction machine mechanism by the block link point; alternatively, the first and second electrodes may be,

causing the client to initiate a down-link challenge to the down-link privacy computing node or the control node.

Optionally, the report acquiring unit 1501 is further configured to:

causing the client to initiate a challenge to the control node with a challenge target set to the down-link privacy computing node, causing the control node to return a remote attestation report of the down-link privacy computing node; alternatively, the first and second electrodes may be,

and enabling the client to initiate a challenge to the control node, wherein the challenge target is not set, and enabling the control node to select the down-link privacy computation node from the down-link privacy computation cluster and return a remote certification report of the down-link privacy computation node.

Optionally, the contract information acquiring unit 1501 is further configured to:

performing signature verification on the remote attestation report according to the public key of the authentication server;

under the condition that the signature verification is passed and the remote authentication result contained in the remote attestation report is passed, extracting a first hash value to be verified from the self-referral information carried by the remote attestation report, wherein the first hash value to be verified is the hash value of the preset information of the trusted execution environment under the chain;

and comparing a first standard hash value which is obtained in advance and aims at the trusted execution environment under the chain with the first hash value to be verified, and using the comparison result as a precondition for confirming that the trusted execution environment under the chain is trusted.

enabling the client to acquire first identity information provided by the down-link privacy computing node, and performing hash computation on the acquired first identity information to obtain a second hash value to be verified, wherein the first identity information comprises an identity public key of the down-link privacy computing node and other identity information of the down-link privacy computing node;

enabling the client to obtain a second standard hash value provided by the private computing node under the chain, wherein the second standard hash value is obtained by performing hash calculation on generated identity information after the private computing node under the chain generates identity information in the trusted execution environment under the chain;

and comparing the second hash value to be verified with the second standard hash value by the client, and acquiring the identity public key contained in the first identity information of the privacy computation node under the condition that the comparison result is consistent.

enabling the client to perform signature verification on the remote certification report according to the public key of the authentication server, and under the condition that the signature verification is passed and the remote authentication result contained in the remote certification report is passed, acquiring second identity information provided by the private calculation node under the chain, and performing hash calculation on the acquired second identity information to acquire a third hash value to be verified, wherein the second identity information contains the identity public key of the private calculation node under the chain, other identity information of the private calculation node under the chain 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 trusted execution environment under the chain;

enabling the client to obtain a third standard hash value provided by the private computing node under the chain, and comparing the third hash value to be verified with the third standard hash value, wherein the third standard hash value is obtained by performing hash computation on generated identity information after the private computing node under the chain generates identity information in a trusted execution environment under the chain;

comparing a fourth standard hash value which is obtained in advance and aims at the trusted execution environment under the chain with the fourth hash value to be verified under the condition that the third hash value to be verified is consistent with the third standard hash value by the client, and using the consistency of a comparison result as a precondition for confirming the trusted execution environment under the chain; the identity public key included in the second identity information is used for signature verification of the contract information to be verified.

Optionally, the identity information of the down-link privacy computing node is the node identity information of the down-link privacy computing node, the identity private key is the node identity private key of the down-link privacy computing node, and the identity public key is the node identity public key of the down-link privacy computing node; alternatively, the first and second electrodes may be,

under the condition that the down-link privacy computing node belongs to the down-link privacy computing cluster, the identity information is cluster identity information of the down-link privacy computing cluster, the identity public key is a cluster identity public key in a cluster identity key of the down-link privacy computing cluster, and the identity private key is a cluster identity private key in the cluster identity key; the cluster identity key is used for encrypting and decrypting interaction data and/or signing and verifying a signature in the process of interacting block chain nodes with each node in the private computation cluster under the chain to deploy or call contract under the chain.

Optionally, the method further includes:

a calling unit 1504, which causes the client to submit a call transaction for the target under-chain contract to a blockchain node, where the call transaction is used to instruct the blockchain node to initiate a call to the target under-chain contract deployed by the under-chain privacy computing node through a prolog mechanism.

Optionally, the method further includes:

a result obtaining unit 1505 enabling the client to obtain an execution result fed back to the blockchain node by the private computation node through the preplan mechanism, the execution result being generated by the target down-chain contract in response to the calling of the blockchain node and being signed by a contract identity private key of the target down-chain contract within the trusted execution environment;

the determining unit 1506 is configured to enable the client to determine that the execution result is generated by the target down-chain contract when the execution result is subjected to signature verification by using the contract identity public key of the target down-chain contract and passes the signature verification.

Optionally, the contract information includes a contract identity public key of the target down-link contract, and when the client initiates a call to the target down-link contract through a prediction machine mechanism of a block link node, the contract identity public key is used to encrypt input parameter data used when the target down-link contract is called, and the encrypted input parameter data is decrypted by the contract identity private key of the target down-link contract.

Referring to fig. 16, in one software implementation, the apparatus for verifying contracts on the private computing node side of the chain may include:

a report providing unit 1601, configured to cause a down-link privacy computing node to provide a remote attestation report of a down-link trusted execution environment created by the down-link privacy computing node to a client, where the remote attestation report is generated by an authentication server after verification of self-referral information generated by the down-link privacy computing node for the down-link trusted execution environment;

an information providing unit 1602, configured to cause the private chain computing node to provide, to the client, contract information to be verified of a target private chain contract deployed at the private chain computing node, where the contract information to be verified is signed by the private chain computing node within the trusted chain execution environment using an identity private key of the private chain computing node, where the identity private key is maintained by the private chain computing node within the trusted chain execution environment;

Optionally, the report providing unit 1601 is further configured to:

causing the down-link privacy computing node to receive a challenge initiated by the client to the down-link privacy computing node, and return the remote attestation report to the client; alternatively, the first and second electrodes may be,

under the condition that the private computing node under the chain belongs to the private computing cluster under the chain, after a control node of the private computing cluster under the chain receives a challenge initiated by the client, the private computing node under the chain sends the remote attestation report to the control node, and the remote attestation report is returned to the client by the control node.

Optionally, the self-referral information carried by the remote attestation report includes a first hash value to be verified, where the first hash value to be verified is a hash value of preset information of the trusted execution environment under the chain, the first hash value to be verified is used for comparing, by the client, a first standard hash value which is obtained in advance for the trusted execution environment under the chain when the signature verification is performed on the remote attestation report according to the public key of the authentication server and the signature verification passes and a remote authentication result included in the remote attestation report is a pass authentication, and a comparison result is consistent and is used as a precondition for the client to confirm that the trusted execution environment under the chain is trusted.

Optionally, the information providing unit 1602 is further configured to:

enabling the down-link privacy computing node to provide first identity information to the client, wherein the first identity information comprises an identity public key of the down-link privacy computing node and other identity information of the down-link privacy computing node, and the first identity information is subjected to hash calculation by the client to obtain a second hash value to be checked;

enabling the down-link privacy computing node to provide a second standard hash value for the client, wherein the second standard hash value is obtained by performing hash calculation on generated identity information after the down-link privacy computing node generates identity information of the down-link privacy computing node in the down-link trusted execution environment;

Optionally, the information providing unit 1602 is further configured to:

enabling the down-link privacy computing node to provide second identity information of the down-link privacy computing node to the client, wherein the second identity information comprises an identity public key of the down-link privacy computing node, other identity information of the down-link privacy computing node and a fourth hash value to be verified, and the fourth hash value to be verified is a hash value of preset information of the down-link trusted execution environment;

enabling the down-link privacy computing node to provide a third standard hash value for the client, wherein the third standard hash value is obtained by performing hash calculation on generated identity information after the down-link privacy computing node generates identity information of the down-link privacy computing node in the down-link trusted execution environment;

Optionally, the method further includes:

an executing unit 1603, enabling the private under-chain computing node to respond to a call initiated by a block link node to the deployed target under-chain contract through a preplan mechanism, and executing the target under-chain contract; the invocation of the target under-chain contract by the block link point is triggered by an invocation transaction submitted by the client for the target under-chain contract.

Optionally, the method further includes:

a feedback unit 1604 that causes the private under-chain computing node to feed back, through the prolog mechanism, an execution result to a block chain node, the execution result being generated by the target under-chain contract in response to the invocation of the block chain node and signed by a contract identity private key of the target under-chain contract within the under-chain trusted execution environment;

wherein the execution result is determined to be generated by the target down-chain contract when the execution result is signature verified using the contract identity public key of the target down-chain contract and passes the signature verification.

Referring to fig. 17, in another software implementation, the client-side apparatus for validating a contract may include:

a report acquisition unit 1701 that causes a client to acquire a remote attestation report of a trusted execution environment created for a private computing node, the remote attestation report being generated by an authentication server after verifying referral information generated by the private computing node for the trusted execution environment;

a contract information obtaining unit 1702, configured to, in a case where it is determined that the trusted execution environment is trusted according to the remote attestation report, obtain to-be-verified contract information of a target intelligent contract deployed at the private computing node, where the to-be-verified contract information is signed by the private computing node in the trusted execution environment using an identity private key of the private computing node, and the identity private key is maintained by the private computing node in the trusted execution environment;

a verification unit 1703, configured to enable the client to perform signature verification on the contract information to be verified by using the identity public key of the private computing node, perform contract information verification on the contract information to be verified according to the contract information of the target intelligent contract, and determine that the target intelligent contract is executed in the trusted execution environment by the private computing node when the client initiates call to the target intelligent contract when the signature verification and the contract information verification pass.

Optionally, the contract information obtaining unit 1702 is specifically configured to:

under the condition that the signature verification is passed and the remote authentication result contained in the remote attestation report is passed, extracting a first hash value to be verified from the self-referral information carried by the remote attestation report, wherein the first hash value to be verified is the hash value of the preset information of the trusted execution environment;

and comparing a first standard hash value which is obtained in advance and aims at the trusted execution environment with the first hash value to be verified, and using the comparison result as a precondition for confirming that the trusted execution environment is trusted.

Optionally, the verification unit 1703 is specifically configured to:

the client acquires first identity information provided by the privacy computing node, and performs hash computation on the acquired first identity information to obtain a second hash value to be verified, wherein the first identity information comprises an identity public key of the privacy computing node and other identity information of the privacy computing node;

the client acquires a second standard hash value provided by the privacy computing node, wherein the second standard hash value is obtained by performing hash calculation on generated identity information after the privacy computing node generates the identity information of the privacy computing node in the trusted execution environment;

and the client compares the second hash value to be verified with the second standard hash value, and acquires the identity public key contained in the first identity information of the privacy computation node under the condition that the comparison result is consistent.

Optionally, the contract verification unit 1703 is specifically configured to:

performing signature verification on the remote certification report according to the public key of the authentication server, acquiring second identity information provided by the privacy computing node under the condition that the signature verification is passed and a remote authentication result contained in the remote certification report is passed, and performing hash calculation on the acquired second identity information to obtain a third hash value to be verified, wherein the second identity information contains the identity public key of the privacy computing node, other identity information of the privacy computing node and a fourth hash value to be verified, and the fourth hash value to be verified is a hash value of preset information of the trusted execution environment;

acquiring a third standard hash value provided by the privacy computing node, and comparing the third hash value to be verified with the third standard hash value, wherein the third standard hash value is obtained by performing hash calculation on generated identity information after the privacy computing node generates the identity information of the privacy computing node in the trusted execution environment;

under the condition that the third hash value to be verified is consistent with the third standard hash value, comparing a fourth standard hash value which is obtained in advance and aims at the trusted execution environment with the fourth hash value to be verified, and using the consistency of the comparison result as a precondition for confirming that the trusted execution environment is trusted; the identity public key included in the second identity information is used for signature verification of the contract information to be verified.

Optionally, the identity information of the privacy computing node is node identity information of the privacy computing node, the identity private key is a node identity private key of the privacy computing node, and the identity public key is a node identity public key of the privacy computing node; alternatively, the first and second electrodes may be,

Optionally, the verification unit 1703 is further configured to:

the client acquires an execution result fed back by the privacy computing node, wherein the execution result is generated by the target intelligent contract in response to the calling of the client and is signed by a contract identity private key of the target intelligent contract in the trusted execution environment;

and the client judges that the execution result is generated by the target intelligent contract under the condition that the execution result is subjected to signature verification by adopting the contract identity public key of the target intelligent contract and passes the signature verification.

Optionally, the contract information includes a contract identity public key of the target intelligent contract, and when the client initiates a call to the target intelligent contract, the contract identity public key is used to encrypt input parameter data used when the target intelligent contract is called, and the encrypted input parameter data is decrypted by the contract identity private key of the target intelligent contract.

Referring to fig. 18, in another software implementation, the apparatus for validating a contract at the private computing node side may include:

a report providing unit 1801, configured to enable a privacy computing node to provide a remote attestation report of a trusted execution environment created by the privacy computing node to a client, where the remote attestation report is generated by an authentication server after verification of self-referral information generated by the privacy computing node for the trusted execution environment;

a contract information providing unit 1802 that causes the private computing node to provide to the client to-be-verified contract information of a target intelligent contract disposed at the private computing node, the to-be-verified contract information being signed by the private computing node within the trusted execution environment with an identity private key of the private computing node, the identity private key being maintained by the private computing node within the trusted execution environment;

the client side adopts the identity public key of the privacy computing node to carry out signature verification on the contract information to be verified under the condition that the trusted execution environment is determined to be trusted according to the remote certification report, carries out contract information verification on the contract information to be verified according to the contract information of the target intelligent contract, and determines that the target intelligent contract is executed in the trusted execution environment by the privacy computing node when the client side initiates calling on the target intelligent contract under the condition that the signature verification and the contract information verification pass.

Optionally, the self-referral information carried by the remote attestation report includes a first hash value to be verified, where the first hash value to be verified is a hash value of preset information of the trusted execution environment, the first hash value to be verified is used for comparing, by the client, the signature verification of the remote attestation report according to the public key of the authentication server and the signature verification passing, and when a remote authentication result included in the remote attestation report is a pass authentication, a first standard hash value obtained in advance for the trusted execution environment, and a comparison result is consistent and is used as a precondition for the client to confirm that the trusted execution environment is trusted.

Optionally, the report providing unit 1801 is specifically configured to:

the privacy computing node provides first identity information to the client, the first identity information comprises an identity public key of the privacy computing node and other identity information of the privacy computing node, and the first identity information is subjected to hash calculation by the client to obtain a second hash value to be checked;

the privacy computing node provides a second standard hash value to the client, and the second standard hash value is obtained by performing hash computation on generated identity information after the privacy computing node generates identity information of the privacy computing node in the trusted execution environment;

Optionally, the report providing unit 1801 is specifically configured to:

the privacy computing node provides second identity information of the privacy computing node to the client, the second identity information comprises an identity public key of the privacy computing node, other identity information of the privacy computing node and a fourth hash value to be verified, and the fourth hash value to be verified is a hash value of preset information of the trusted execution environment;

the privacy computing node provides a third standard hash value to the client, and the third standard hash value is obtained by performing hash computation on generated identity information after the privacy computing node generates identity information of the privacy computing node in the trusted execution environment;

the second identity information is subjected to signature verification on the remote certification report at the client according to the public key of the authentication server, and is subjected to hash calculation by the client under the condition that the signature verification is passed and the remote authentication result contained in the remote certification report is authenticated, so as to obtain a third hash value to be verified; the precondition for confirming that the trusted execution environment is trusted includes that the fourth hash value to be verified is consistent with a fourth standard hash value, which is obtained by the client in advance and is specific to the trusted execution environment, when the third hash value to be verified is consistent with the third standard hash value; the identity public key included in the second identity information is used for signature verification of the contract information to be verified.

Optionally, the contract information providing unit 1802 is further configured to:

causing the private computing node to feed back to the client an execution result, the execution result generated by the target intelligent contract in response to invocation by the blockchain node and signed by a contract identity private key of the target intelligent contract within the trusted execution environment;

wherein the execution result is determined to be generated by the target intelligent contract when the execution result is signature-verified by using the contract identity public key of the target intelligent contract and passes the signature verification.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.

As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The description has been presented with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the description. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

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

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

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

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

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

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

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

Claims

1. A method of validating a contract, comprising:

the client acquires contract information to be verified of a target under-chain contract deployed at the under-chain privacy computing node under the condition that the under-chain trusted execution environment is determined to be trusted according to the remote attestation report, wherein the contract information to be verified is signed by the under-chain privacy computing node in the under-chain trusted execution environment by using an identity private key of the under-chain privacy computing node, and the identity private key is maintained by the under-chain privacy computing node in the under-chain trusted execution environment;

the client performs signature verification on the contract information to be verified by adopting the identity public key of the private computing node under the chain, performs contract information verification on the contract information to be verified according to the contract information of the contract under the target chain, and determines that the contract under the target chain is executed by the private computing node under the chain when the client initiates calling on the contract under the target chain through a preplanning machine mechanism of the block chain node under the condition that the signature verification and the contract information verification pass.

2. The method of claim 1, the client obtaining a remote attestation report for an offline trusted execution environment created by an offline private computing node, comprising:

the client initiates a challenge to the down-link privacy computation node and receives a remote certification report returned by the down-link privacy computation node; alternatively, the first and second electrodes may be,

and under the condition that the down-link privacy computing node belongs to the down-link privacy computing cluster, the client initiates a challenge to a control node of the down-link privacy computing cluster and receives a remote attestation report returned by the control node.

3. The method of claim 2, the client initiating a challenge operation to the down-link privacy computing node or the control node, comprising:

the client submits a challenge transaction to a blockchain node, and challenge information contained in the challenge transaction is transmitted to the down-chain privacy computing node or the control node by the blockchain node through a prediction machine mechanism; alternatively, the first and second electrodes may be,

The client initiates a downlink challenge to the downlink privacy computation node or the control node.

4. The method of claim 2, the client initiating a challenge to a control node of the down-link privacy computing cluster, comprising:

the client initiates a challenge to the control node, sets a challenge target to the private calculation node under the chain, and enables the control node to return a remote certification report of the private calculation node under the chain; alternatively, the first and second electrodes may be,

and the client initiates a challenge to the control node, and the challenge target is not set, so that the control node selects the down-link privacy computation node from the down-link privacy computation cluster and returns a remote certification report of the down-link privacy computation node.

5. The method of claim 1, further comprising:

6. The method of claim 1, further comprising:

the client acquires first identity information provided by the down-link privacy computing node, and performs hash computation on the acquired first identity information to obtain a second hash value to be verified, wherein the first identity information comprises an identity public key of the down-link privacy computing node and other identity information except the identity public key;

the client side obtains a second standard hash value provided by the private computing node under the chain, and the second standard hash value is obtained by performing hash calculation on generated identity information after the private computing node under the chain generates identity information of the private computing node under the chain in the trusted execution environment;

7. The method of claim 1, further comprising:

performing signature verification on the remote certification report according to the public key of the authentication server, and under the condition that the signature verification is passed and the remote authentication result contained in the remote certification report is that the remote certification report passes the authentication, acquiring second identity information provided by the private calculation node under the chain, and performing hash calculation on the acquired second identity information to acquire a third hash value to be verified, wherein the second identity information contains an identity public key of the private calculation node under the chain, a fourth hash value to be verified and other identity information except the identity public key and the fourth hash value to be verified, and the fourth hash value to be verified is the hash value of the preset information of the trusted execution environment under the chain;

acquiring a third standard hash value provided by the private computing node under the chain, and comparing the third hash value to be verified with the third standard hash value, wherein the third standard hash value is obtained by performing hash computation on generated identity information after the private computing node under the chain generates identity information in the trusted execution environment under the chain;

under the condition that the third hash value to be verified is consistent with the third standard hash value, comparing a fourth standard hash value which is obtained in advance and aims at the trusted execution environment under the chain with the fourth hash value to be verified, and using the consistency of a comparison result as a precondition for confirming that the trusted execution environment under the chain is trusted; the identity public key included in the second identity information is used for signature verification of the contract information to be verified.

8. The method according to claim 6 or 7, wherein the identity information of the down-link privacy computing node is the node identity information of the down-link privacy computing node, the identity private key is the node identity private key of the down-link privacy computing node, and the identity public key is the node identity public key of the down-link privacy computing node; alternatively, the first and second electrodes may be,

9. The method of claim 1, further comprising:

the client submits a call transaction for the target under-chain contract to a blockchain node, the call transaction being used to instruct the blockchain node to initiate a call to the target under-chain contract deployed by the under-chain privacy computing node through a prophetic mechanism.

10. The method of claim 1, further comprising:

the client side obtains an execution result fed back to the block chain node by the private computing node under the chain through the language predicting machine mechanism, wherein the execution result is generated by the target chain contract in response to the calling of the block chain node and is signed by a contract identity private key of the target chain contract in the trusted execution environment under the chain;

and the client judges that the execution result is generated by the target down-chain contract under the condition that the execution result is subjected to signature verification by adopting the contract identity public key of the target down-chain contract and passes the signature verification.

11. The method according to claim 1, wherein the contract information includes a contract identity public key of the target down-link contract, and when the client initiates a call to the target down-link contract through a prolog mechanism of a blockchain node, the contract identity public key is used to encrypt input parameter data used when the target down-link contract is called, and the encrypted input parameter data is decrypted by the contract identity private key of the target down-link contract.

12. A method of validating a contract, comprising:

the under-chain privacy computing node providing to the client, contract information to be verified for a target under-chain contract deployed at the under-chain privacy computing node, the contract information to be verified being signed by the under-chain privacy computing node within the under-chain trusted execution environment with an identity private key of the under-chain privacy computing node, the identity private key being maintained by the under-chain privacy computing node within the under-chain trusted execution environment;

13. The method of claim 12, the down-link privacy computing node providing a remote attestation report to a client for a down-link trusted execution environment created by the down-link privacy computing node, comprising:

receiving a challenge initiated by the client to the downlink privacy computation node, and returning the remote attestation report to the client; alternatively, the first and second electrodes may be,

and under the condition that the down-link privacy computing node belongs to the down-link privacy computing cluster, after receiving the fight initiated by the client, the control node of the down-link privacy computing cluster sends the remote attestation report to the control node, wherein the remote attestation report is returned to the client by the control node.

14. The method of claim 12, wherein the self-referral information carried by the remote attestation report includes a first hash to be verified, the first hash to be verified is a hash of preset information of the trusted execution environment under the chain, the first hash to be verified is used for comparing, when the signature verification is performed on the remote attestation report according to a public key of the authentication server and the signature verification is passed, and a remote authentication result included in the remote attestation report is authentication passed, a first standard hash value which is obtained in advance for the trusted execution environment under the chain is compared, and a comparison result is consistent as a precondition that the client confirms that the trusted execution environment under the chain is trusted.

15. The method of claim 12, further comprising:

the method comprises the steps that a first identity information is provided for a client by a down-link privacy computing node, the first identity information comprises an identity public key of the down-link privacy computing node and other identity information except the identity public key, and the first identity information is subjected to Hash calculation by the client to obtain a second Hash value to be verified;

16. The method of claim 12, further comprising:

the private computing node under the chain provides second identity information of the private computing node to the client, the second identity information comprises an identity public key of the private computing node under the chain, a fourth hash value to be verified and other identity information except the identity public key and the fourth hash value to be verified, and the fourth hash value to be verified is a hash value of preset information of the trusted execution environment under the chain;

17. The method according to claim 15 or 16, wherein the identity information of the down-link privacy computing node is the node identity information of the down-link privacy computing node, the identity private key is the node identity private key of the down-link privacy computing node, and the identity public key is the node identity public key of the down-link privacy computing node; alternatively, the first and second electrodes may be,

18. The method of claim 12, further comprising:

the under-chain privacy computing node executes the target under-chain contract in response to a call initiated by a block link point to the deployed target under-chain contract through a prophetic mechanism; the invocation of the target under-chain contract by the block link point is triggered by an invocation transaction submitted by the client for the target under-chain contract.

19. The method of claim 12, further comprising:

the private under-chain computing node feeds back an execution result to the block chain node through the prolog mechanism, the execution result is generated by the target under-chain contract in response to the invocation of the block chain node, and is signed by a contract identity private key of the target under-chain contract within the trusted under-chain execution environment;

20. The method according to claim 12, wherein the contract information includes a contract identity public key of the target down-link contract, and when the client initiates a call to the target down-link contract through a prolog mechanism of a blockchain node, the contract identity public key is used to encrypt input parameter data used when the target down-link contract is called, and the encrypted input parameter data is decrypted by the contract identity private key of the target down-link contract.

21. A method of validating a contract, comprising:

22. The method of claim 21, further comprising:

23. The method of claim 21, further comprising:

the client acquires first identity information provided by the privacy computing node, and performs hash computation on the acquired first identity information to obtain a second hash value to be verified, wherein the first identity information comprises an identity public key of the privacy computing node and other identity information except the identity public key;

24. The method of claim 21, further comprising:

performing signature verification on the remote certification report according to the public key of the authentication server, acquiring second identity information provided by the privacy computing node under the condition that the signature verification is passed and a remote authentication result contained in the remote certification report is that the remote certification report passes the authentication, and performing hash calculation on the acquired second identity information to obtain a third hash value to be verified, wherein the second identity information comprises an identity public key of the privacy computing node, a fourth hash value to be verified and other identity information except the identity public key and the fourth hash value to be verified, and the fourth hash value to be verified is a hash value of preset information of the trusted execution environment;

25. The method according to claim 23 or 24, wherein the identity information of the private computing node is node identity information of the private computing node, the identity private key is a node identity private key of the private computing node, and the identity public key is a node identity public key of the private computing node; alternatively, the first and second electrodes may be,

26. The method of claim 21, further comprising:

27. The method of claim 21, wherein the contract information includes a contract identity public key of the target intelligent contract, and when the client initiates a call to the target intelligent contract, the contract identity public key is used to encrypt input parameter data used when the target intelligent contract is called, and the encrypted input parameter data is decrypted by a contract identity private key of the target intelligent contract.

28. A method of validating a contract, comprising:

29. The method of claim 28, wherein the self-referral information carried by the remote attestation report includes a first hash to be verified, the first hash to be verified is a hash of preset information of the trusted execution environment, the first hash to be verified is used for comparing, by the client, with a first standard hash value obtained in advance for the trusted execution environment if the remote attestation report is signature-verified and signature-verified according to a public key of the authentication server, and a remote authentication result included in the remote attestation report is authenticated, and a comparison result is consistent to be a precondition for the client to confirm that the trusted execution environment is trusted.

30. The method of claim 28, further comprising:

the privacy computing node provides first identity information to the client, the first identity information comprises an identity public key of the privacy computing node and other identity information except the identity public key, and the first identity information is subjected to hash computation by the client to obtain a second hash value to be verified;

31. The method of claim 28, further comprising:

the privacy computing node provides second identity information of the privacy computing node to the client, the second identity information comprises an identity public key of the privacy computing node, a fourth hash value to be verified and other identity information except the identity public key and the fourth hash value to be verified, and the fourth hash value to be verified is a hash value of the preset information of the trusted execution environment;

32. The method according to claim 30 or 31, wherein the identity information of the private computing node is node identity information of the private computing node, the identity private key is a node identity private key of the private computing node, and the identity public key is a node identity public key of the private computing node; alternatively, the first and second electrodes may be,

33. The method of claim 28, further comprising:

the private computing node feeding back to the client an execution result, the execution result generated by the target intelligent contract in response to invocation of a block link point and signed by a contract identity private key of the target intelligent contract within the trusted execution environment;

34. The method of claim 28, wherein the contract information includes a contract identity public key of the target intelligent contract, and when the client initiates a call to the target intelligent contract, the contract identity public key is used to encrypt input parameter data used when the target intelligent contract is called, and the encrypted input parameter data is decrypted by a contract identity private key of the target intelligent contract.

35. An apparatus for validating a contract, comprising:

a contract information obtaining unit, configured to, when the client determines that the under-chain trusted execution environment is trusted according to the remote attestation report, obtain contract information to be verified, which is to be contracted under a target under-chain deployed at the under-chain private computing node, where the contract information to be verified is signed by the under-chain private computing node in the under-chain trusted execution environment using an identity private key of the under-chain private computing node, where the identity private key is maintained by the under-chain private computing node in the under-chain trusted execution environment;

and the verification unit enables the client to adopt the identity public key of the private computation node under the chain to carry out signature verification on the contract information to be verified, carry out contract information verification on the contract information to be verified according to the contract information of the contract under the target chain, and determine that the contract under the target chain is executed by the private computation node under the chain in a trusted execution environment under the chain when the client initiates calling on the contract under the target chain through a preplanning mechanism of the block chain node under the condition that the signature verification and the contract information verification pass.

36. An apparatus for validating a contract, comprising:

an information providing unit, which enables the private computing node to provide contract information to be verified of a target private chain contract arranged at the private computing node to the client, wherein the contract information to be verified is signed by the private computing node in the trusted execution environment under the chain by using an identity private key of the private computing node under the chain, and the identity private key is maintained by the private computing node under the chain in the trusted execution environment under the chain;

37. An apparatus for validating a contract, comprising:

38. An apparatus for validating a contract, comprising:

39. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

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

40. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 34.