CN111090876A

CN111090876A - Contract calling method and device

Info

Publication number: CN111090876A
Application number: CN202010191197.7A
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-05-01
Anticipated expiration: 2040-03-18
Also published as: CN111090876B; WO2021184963A1; CN111898153B; CN111898153A

Abstract

The present specification provides a method and an apparatus for invoking a contract, where the method may include: a data user generates a call request aiming at a contract under a chain, wherein the call request comprises target ciphertext data obtained by encrypting target plaintext data and a verifiable statement aiming at the use right of the target plaintext data; the data user submits the calling request to the private computing node under the chain with the contract under the chain through a preplan mechanism of a block chain, the calling request is used for indicating the private computing node under the chain to execute the contract under the chain in the trusted execution environment under the chain created by the private computing node under the chain under the condition that a calling condition is met, and the calling condition comprises that the data owner of the target plaintext data is determined to grant the use right to the data user according to the verifiable statement. The procedure of invoking the contract described above can ensure data security and privacy protection.

Description

Contract calling method and device

Technical Field

One or more embodiments of the present specification relate to the field of verifiable computing technologies, and in particular, to a method and an apparatus for invoking 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 specification provide a method and apparatus for invoking a contract.

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 invoking a contract, comprising:

a data user generates a call request aiming at a contract under a chain, wherein the call request comprises target ciphertext data obtained by encrypting target plaintext data and a verifiable statement aiming at the use right of the target plaintext data;

the data user submits the calling request to the private computing node under the chain with the contract under the chain through a preplan mechanism of a block chain, the calling request is used for indicating the private computing node under the chain to execute the contract under the chain in the trusted execution environment under the chain created by the private computing node under the chain under the condition that a calling condition is met, and the calling condition comprises that the data owner of the target plaintext data is determined to grant the use right to the data user according to the verifiable statement.

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

the method comprises the steps that a chain privacy computing node receives a call request of a chain contract deployed by a data user through a block chain prediction machine mechanism, wherein the call request comprises target ciphertext data obtained by encrypting target plaintext data and a verifiable statement of the use right of the target plaintext data;

the chain lower privacy computation node executes the chain lower contract in the chain lower credible execution environment created by the chain lower privacy computation node to process the target plaintext data under the condition that a calling condition is met, wherein the calling condition comprises that the data owner of the target plaintext data is granted the use right to the data user according to the verifiable statement.

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

a data user generates a call request aiming at an intelligent contract, wherein the call request comprises target ciphertext data obtained by encrypting target plaintext data and a verifiable statement aiming at the use right of the target plaintext data;

the data using direction submits the calling request to a private computing node which is provided with the intelligent contract, the calling request is used for indicating the private computing node to execute the intelligent contract in a trusted execution environment created by the private computing node to process the target plaintext data under the condition that a calling condition is met, and the calling condition comprises that the data owner of the target plaintext data is determined to grant the using right to the data using party according to the verifiable statement.

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

the method comprises the steps that a privacy computing node receives a call request of an intelligent contract deployed by a data user aiming at the privacy computing node, wherein the call request comprises target ciphertext data obtained by encrypting target plaintext data and a verifiable statement aiming at the use right of the target plaintext data;

the privacy computing node executes the intelligent contract in a trusted execution environment created by the privacy computing node to process the target plaintext data under the condition that a calling condition is met, wherein the calling condition comprises that the data owner of the target plaintext data is determined to grant the use right to the data user according to the verifiable statement.

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

a generation unit that causes a data usage party to generate a call request for a contract under a link, the call request including target ciphertext data obtained by encrypting target plaintext data and a verifiable declaration of a usage right for the target plaintext data;

and a submitting unit, which enables the data user to submit the call request to the down-chain privacy computing node deployed with the down-chain contract through a preplan mechanism of the block chain, wherein the call request is used for instructing the down-chain privacy computing node to execute the down-chain contract in the down-chain trusted execution environment created by the down-chain privacy computing node to process the target plaintext data under the condition that a call condition is met, and the call condition comprises that the data owner of the target plaintext data is determined to be granted the use right to the data user according to the verifiable statement.

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

the system comprises a receiving unit, a data processing unit and a verification unit, wherein the receiving unit enables a private calculation node under the chain to receive a call request of a contract under the chain, which is submitted by a data user through a prolog mechanism of a block chain and is deployed for the private calculation node under the chain, and the call request comprises target ciphertext data obtained by encrypting target plaintext data and a verifiable statement of the use right of the target plaintext data;

and the execution unit enables the private computation node under the chain to execute the contract under the chain in the trusted execution environment under the chain created by the private computation node under the chain under the condition that a calling condition is met, wherein the calling condition comprises that the data owner of the target plaintext data is determined to grant the use right to the data user according to the verifiable statement.

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

the generating unit enables a data user to generate a calling request aiming at the intelligent contract, wherein the calling request comprises target ciphertext data obtained by encrypting target plaintext data and a verifiable statement aiming at the use right of the target plaintext data;

and a submitting unit, which enables the data using direction to submit the call request to a private computing node deployed with the intelligent contract, wherein the call request is used for instructing the private computing node to execute the intelligent contract in a trusted execution environment created by the private computing node to process the target plaintext data under the condition that a call condition is met, and the call condition comprises that the data owner of the target plaintext data is determined to grant the using right to the data using party according to the verifiable statement.

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

the system comprises a receiving unit, a data processing unit and a data processing unit, wherein the receiving unit enables a privacy computing node to receive a call request of an intelligent contract which is submitted by a data user and is deployed aiming at the privacy computing node, and the call request comprises target ciphertext data obtained by encrypting target plaintext data and a verifiable statement aiming at the use right of the target plaintext data;

and the execution unit enables the privacy computing node to execute the intelligent contract in the trusted execution environment created by the privacy computing node to process the target plaintext data under the condition that a calling condition is met, wherein the calling condition comprises that the data owner of the target plaintext data is determined to grant the use right to the data user according to the verifiable statement. 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.

Drawings

FIG. 1 is a flow diagram of a method for validating a contract under a chain in accordance with an illustrative embodiment.

2-3 are scenario diagrams of a method for validating contracts under a chain provided by an exemplary embodiment.

FIG. 4 is a flowchart of a method for invoking contracts on the data consumer side as provided by an exemplary embodiment.

FIG. 5 is a schematic diagram of a scenario in which a method for invoking a contract is provided by an exemplary embodiment.

Fig. 6 is a flow diagram of creating a DID provided by an exemplary embodiment.

FIG. 7 is a flow diagram of a data authorization process provided by an exemplary embodiment.

FIG. 8 is a flowchart of another method for invoking a contract provided by an exemplary embodiment.

FIG. 9 is a flowchart of a method for invoking contracts on the private compute node side of a chain according to an exemplary embodiment.

FIG. 10 is a flowchart of another method for invoking contracts on the data consumer side as provided by an exemplary embodiment.

FIG. 11 is a flowchart of another method for privacy-preserving compute node-side invocation contracts provided by an exemplary embodiment.

FIG. 12 is a schematic block diagram of an apparatus provided in an exemplary embodiment.

FIG. 13 is a block diagram of an apparatus for invoking contracts on the data consumer side according to an example embodiment.

Fig. 14 is a block diagram of an apparatus for invoking contracts on the private computing node side of a chain according to an example embodiment.

FIG. 15 is a block diagram of another apparatus for invoking contracts on the data consumer side as provided by an exemplary embodiment.

FIG. 16 is a block diagram of another apparatus for invoking contracts on the private computing node side provided by an exemplary 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. 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.

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. The user can initiate a computation task based on the WASM program to the down-link privacy computation node as a data user of the target data, and the computation task is used for calling the down-link contract to compute the target data (namely, the target data is the entry data of the down-link contract), so that the down-link privacy computation node can read the down-link contract into the down-link TEE and compile the down-link contract into WASM byte codes, and the WASM virtual machine is used as an execution engine to execute the compiled WASM byte codes in the WASM virtual machine so as to compute the target data. It should be noted that any computation logic defined by a user may be implemented by the link contract in this specification. 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.

Before the data user calls the under-chain contract through the client, a challenge can be initiated on the under-chain contract deployed in the under-chain privacy computing node so as to ensure that the 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. 1 is a flow diagram of a method for validating a contract under a chain in accordance with an illustrative embodiment. As shown in fig. 1, the method may include the steps of:

step 102, the data user acquires a remote attestation report aiming at the under-chain trusted execution environment, and the remote attestation report is generated by an authentication server after verification of self-referral information generated by the under-chain privacy computing node aiming at the under-chain trusted execution environment.

In this embodiment, the down-link privacy computing node includes two forms, a single node and a down-link privacy computing cluster. For a single-node form, a data user directly challenges a private computation node down a chain, so as to receive a remote attestation report returned by the private computation node down the chain. In this case, 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 of the down-link privacy computing node is the node identity private key of the down-link privacy computing node, and the identity public key of the down-link privacy computing node is the node identity public key of the down-link privacy computing node. Aiming at the form of the down-link privacy computing cluster, under the condition that the down-link privacy computing nodes belong to the down-link privacy computing cluster, the data using party initiates challenges to the control nodes of the down-link privacy computing cluster, and the control nodes select the nodes in the down-link privacy computing cluster to respond to the challenges, so that a remote certification report of the selected nodes is obtained, and the remote certification report is returned to the data using party. In this case, the down-link privacy computing node interacts with the external object on behalf of the down-link privacy computing cluster. 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 verifying signature and signature of the interactive data 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. For the generation of the cluster identity key, any node in the cluster can be selected by the control node of the linked privacy computation cluster as a main node to generate the cluster identity key, and the cluster identity key is shared by other nodes in the cluster.

And 104, under the condition that the data user determines that the under-chain trusted execution environment is trusted according to the remote certification report, acquiring contract information to be verified of the under-chain contract deployed at the under-chain private computing node, 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 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.

In this embodiment, the remote attestation report results from a remote attestation process directed to a down-link TEE on a down-link private 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.

Taking an Intel SGX technology as an example, the under-chain TEE is an enclave created on the under-chain privacy computing node and used 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, a 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 identification) key for signature. 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 computing node under the chain, the data consumer may verify, according to the remote attestation report, whether the corresponding private computing node under the chain is trusted, specifically, whether the TEE under the chain deployed on the private computing node under the chain is trusted, and further verify, if it is determined that the TEE under the chain is trusted, the contract under the chain (executed within the trusted TEE under the chain) deployed at the private computing node under the chain.

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 data user 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 data consumer may obtain the public key of the IAS server through any means, such as when a remote attestation report is provided to the data consumer, the data consumer may also associate a certificate chain providing the IAS server, so that the data consumer may extract the public key of the IAS server from the certificate chain. The data consumer can then extract the structure QUOTE and signature verification results from the remote attestation report. The data user 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 data user can judge that the down-link privacy computing platform is unreliable without continuing other verification operations. Then, the data user can extract the hash values MREnclave and MRSigner from the structure quate, that is, MREnclave to be checked and MRSigner to be checked; meanwhile, the data user obtains a first standard hash value of the preset information of the sub-chain TEE in advance, such as credible values of MREnclave and MRSigner (hereinafter, referred to as credible MREnclave and credible MRSigner), compares the MREnclave to be checked with the credible MREnclave, and compares the MRSigner to be checked with the credible MRSigner. Then, the data user may use "MREnclave to be checked is consistent with trusted MREnclave, and MRSigner to be checked is consistent with trusted MRSigner" as a precondition that the TEE is trusted under the validation 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 data user determines that the chain-down TEE of the chain-down privacy computation node is not trusted, and if all the preconditions set by the data user are satisfied, the chain-down TEE of the chain-down privacy computation node can be confirmed to be trusted. In addition, the operation of the data user for verifying the signature verification result and the operation for 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 data consumer can verify the trustworthiness of the privacy computation nodes under the chain through 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 signature and signature verification (i.e., a signature key pair), and one group of key pairs is a key pair for encryption and decryption (i.e., an encryption key pair), the node identity information may include a signature public key in the signature key pair and an encryption public key in the encryption 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 data consumer, upon receiving the remote attestation report, can perform signature verification from the remote attestation report. Under the condition that the signature verification is passed, the data user can extract the signature verification result and the 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 data user 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 private computing node, the data user needs to obtain the node identity information of the private computing node, for example, while the remote attestation report is provided to the data user, the data user may provide the node identity information in an associated manner, and of course, the data user may obtain the node identity information in other manners or at other times. Then, the data user 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 calculation node under the chain is trusted. 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, a trust level may be set on the data user, and it is determined 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 data consumer, upon receiving the remote attestation report, can perform signature verification from the remote attestation report. Under the condition that the signature verification passes, the data user can extract the 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 data user firstly verifies the signature verification result and continuously verifies the node identity information of the down-link privacy computing node 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 data user needs to obtain the node identity information of the down-link privacy computing node, which is not described herein again. Then, the data user can 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 contained in the remote attestation report, and use the comparison result as a precondition for confirming that the privacy calculation node under the chain is credible. 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 data user 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 the like, which is not described herein again.

And 106, the data user adopts the identity public key of the private computation node under the chain to carry out signature verification on the contract information to be verified, carries out contract information verification on the contract information to be verified according to the contract information of the contract under the chain, and determines that the contract under the chain is executed by the private computation node under the chain in the trusted execution environment under the chain when the data user initiates calling on the contract under the chain through the prompter mechanism under the condition that the signature verification and the contract information verification are passed.

In this embodiment, for the cluster form, after the establishment of the private computing cluster under the chain is completed, uniform identity information, for example, called a cluster identity key, needs to be generated for the private computing nodes under the chain. The cluster identity key may include a cluster encryption key pair and a cluster signature key pair, and each of the down-chain privacy computing nodes needs to maintain the cluster encryption private key and the cluster signature private key in the respective down-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. Taking the first identity information of the private computing node under the chain as an example, for a single-node form, the first identity information provided by the private computing node under the chain is node identity information (not including a node identity private key) of the private computing node under the chain, the identity public key is a node identity public key of the private computing node under the chain, and other identity information (other identity information except the identity public key in the identity information) is other node identity information of the private computing node under the chain, that is, 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 of 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 described herein again. The following describes the challenge procedure in the form of a single node and a cluster in detail with reference to fig. 2-3.

As shown in fig. 2, for a single node, the client 21 of the data consumer may initiate a challenge down-link or a challenge up-link to the privacy-down-link computing node 22, the process of initiating the challenge up-link may include three steps, step ①, in which the client 21 submits a transaction, referred to as a challenge transaction, to the blockchain network 23 for initiating a challenge to a contract down-link, the challenge transaction being received and executed by a certain node 23n within the blockchain network 23, step ②, in which the node 23n invokes a pre-deployed predicting machine contract, which may transfer challenge information contained in the challenge transaction to the predicting machine server 24 down-link, for example, the predicting machine contract may generate an event containing the challenge information, and the predicting machine server 24 may listen to the event generated by the predicting machine contract to obtain the challenge information, and step ③, in which the predicting machine server 24 sends the challenge information to the challenge node 22 through a channel down-link.

By challenging the down-link contract deployed by the down-link privacy computing node 22, the client 21 may obtain a remote attestation report for the down-link TEE created by the down-link privacy computing node 22, the remote attestation report being generated by the authentication server after verifying the self-referral information generated by the down-link privacy computing node 22 for the down-link TEE. In one case, the client 21 issues a challenge to the down-link privacy computing node 22, the challenge is targeted to the down-link contract deployed by the down-link privacy computing node 22, and then receives the remote attestation report and the contract information to be verified returned by the down-link privacy computing node 22 in response to the challenge, that is, the down-link privacy computing node 22 returns the remote attestation report and the contract information to be verified to the client 21 in one time in response to the challenge. In another case, the client 21 initiates a challenge to the down-chain privacy computing node 22, where the challenge is a down-chain TEE created by the down-chain privacy computing node 22, and then receives a remote attestation report returned by the down-chain privacy computing node 22, and in a case where it is determined from the remote attestation report that the down-chain TEE is authentic, sends an acquisition request for contract information of a down-chain contract deployed at the down-chain privacy computing node 22 to the down-chain privacy computing node 22, and receives contract information to be verified returned by the down-chain privacy computing node 22 in response to the acquisition request. In the event that 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 22 for contract information (i.e., contract information to be verified) for the down-link contract.

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

As shown in fig. 2, in an embodiment, after the node identity information of the node 22 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 22 and other identity information of the down-link privacy computing node 22. Then, the client 21 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 22 under the chain and other identity information of the private computing node 22 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 22 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 22 under the verifiable chain if the verification passes, so as to complete the subsequent verification of the contract under the chain by using the node identity public key. For example, the client 21 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 22, so as to determine that the node identity information passes verification when the comparison result is consistent. Since the node identity information is generated and calculated by the down-link privacy computing node 22 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 22 is the node identity information generated in the down-link TEE, so that the node identity public key included therein is the actual node identity public key of the privacy computing node 22, and the actual node identity public key of the down-link privacy computing node 22 can be used for verifying the signature of the privacy computing node 22. The downlink privacy computation node 22 may send the second standard hash value, the remote attestation report, and the first node identity information to the client 21. It should be noted that, reference may be made to the process of verifying the privacy-preserving-node in step 104, and details are not described herein again.

As shown in fig. 2, in another embodiment, the node identity information generated by the down-link privacy computing node 22 in the down-link TEE includes a node identity public key of the down-link privacy computing node 22, other identity information of the down-link privacy computing node 22, and a hash value of preset information of the down-link TEE, and then the down-link privacy computing node 22 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 22 may provide the client 21 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 includes a node identity public key of the down-link privacy computing node 22, other identity information of the down-link privacy computing node 22, and a fourth hash value to be verified, where 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 22. Then, the client 21 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 passes the authentication, and compares the third hash value to be verified with a third standard hash value. When the comparison result is consistent, it indicates that the second node identity information provided by the privacy computing node 22 is the node identity information generated in the chain TEE, that is, the fourth hash value to be checked 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 22, and may be used to perform signature verification on the contract information to be verified. The downlink privacy computation node 22 may send the third standard hash value, the remote attestation report, and the second node identity information to the client 21. It should be noted that, reference may be made to the process of verifying the privacy-preserving-node in step 104, and details are not described herein again.

Under the condition that the client 21 determines that the chain-down TEE is credible according to the remote certification report, acquiring contract information to be verified of the chain-down contract deployed at the chain-down privacy computing node 22, wherein the contract information to be verified is signed by the chain-down privacy computing node 22 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 22 in the chain-down TEE. For example, the down-link privacy computing node 22 may read the deployed down-link contract into the down-link TEE and sign with its own node identity private key.

The client 21 performs signature verification on the contract information to be verified by using the node identity public key of the private calculation node 22, and performs contract information verification on the contract information to be verified according to the contract information of the contract under the chain. 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 22 for acquisition by the client 21. Alternatively, the client 21 obtains the node identity information of the privacy computation node 22 through the above-mentioned verification. Meanwhile, the contract information of the linked contract may also be in a public state, such as the deployment direction of the linked contract developing the contract information to be acquired by the client 21. 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 21 may determine that the client 21 executed in the down-chain TEE trusted execution environment by the down-chain privacy computing node 22 when a call is initiated to the down-chain contract by 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 22 is trusted, and then, in the case of verifying that the contract under the chain of the privacy computing node 22 is trusted, if the contract information to be verified provided by the privacy computing node 22 under the chain is obtained by verifying the signature and is indeed signed by the node identity private key (maintained in the contract under the chain) of the privacy computing node 22 under the chain, it may be determined that the contract under the chain which is currently challenged is the contract under the chain which runs in the contract under the chain of the privacy computing node 22 under the chain, that is, it is ensured that the contract under the chain deployed in the privacy computing node 22 under the chain is trusted, and the computing task may be executed according to the expectation of the user.

The process of initiating a chain challenge may include three steps, step ①, where the client 31 submits a transaction to the blockchain network 33 for initiating a challenge to a chain contract, for example, a so-called challenge transaction, which may be received and executed by a certain node 33n within the blockchain network 33, step ②, where the node 33n invokes a pre-deployed predicting-machine contract that may transfer challenge information contained in the challenge transaction to the chain predicting-machine server 34, for example, the predicting-machine contract may generate an event containing the challenge information, and the predicting-machine server 34 may listen to the event generated by the predicting-machine contract to obtain the challenge information, and step ③, where the predicting-machine server 34 sends the challenge information to the control node 32 through a chain channel.

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. 3, a user may initiate a challenge to an under-chain contract deployed in a cluster through a client 31 before invoking the under-chain contract in the cluster through the client 31. The control node 32, 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 node 32n is illustrated as responding to the challenge. Control node 32 selects node 32n to respond to the challenge on behalf of the cluster, providing the challenger with a cluster remote attestation report on behalf of the cluster. The cluster remote attestation report is generated by the authentication server after verifying the self-referral information generated by the node 32n 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 32 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 32n, 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 that the remote authentication result passes authentication, 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) obtained in advance for the chain-down TEE, and the comparison result is consistent and is used as a precondition that the challenger confirms that the chain-down TEE is trusted. 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 32 n.

As shown in fig. 3, in an embodiment, when the node 32n 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 32 n. In other words, based on representing a cluster by node 32n, the difference between the node identity information of node 32n 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 31 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 32n, and is not necessarily real data, and may be understood as identity information to be verified) provided by the node 32n 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 link 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 32n, so as to determine that the cluster identity authentication is passed when the comparison result is consistent. Since the cluster identity information is generated by the node 32n in the chain TEE and calculated to obtain the second standard hash value, 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 computing node 32 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 computing node 32, and the cluster identity public key actually maintained by the privacy computing node 32 can be used for verifying the signature of the privacy computing node 32. The node 32n may send the second standard hash value, the remote attestation report, and the first cluster identity information to the client 31 through the control node 32. It should be noted that, reference may be made to the process of verifying the privacy-preserving-node in step 104, and details are not described herein again.

As shown in fig. 3, in another embodiment, the cluster identity information generated by the node 32n in the chain-down TEE may include a cluster identity public key, and hash values of other identity information except the node identity public key in the node identity information of the node 32n and preset information of the chain-down TEE, so that after the node 32n generates the cluster identity information in its own chain-down TEE, the generated cluster identity information is subjected to hash calculation to obtain a third standard hash value, and the third standard hash value is equivalent to simultaneously implement the functions of the first hash value to be tested and the second standard hash value. In particular, the node 32n may provide the client 31 with the remote attestation report, the third standard hash value, and the second cluster identity information (which may be understood at this time as the identity information to be verified). The second cluster identity information comprises a cluster identity public key, other identity information of the node 32n 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 32 n. Then, the client 31 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 passes the authentication, 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 32 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 32, and may be used to perform signature verification on the contract information to be verified. The node 32n may send the third standard hash value, the remote attestation report, and the second cluster identity information to the client 31 through the control node 32. It should be noted that, reference may be made to the process of verifying the privacy-preserving-node in step 104, and details are not described herein again.

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

The client 31 performs signature verification on the contract information to be verified by using the cluster identity public key and performs contract information verification on the contract information to be verified according to the contract information of the contract under the link under the condition that the link TEE is determined to be credible (namely the link TEE of the node 32n, the node 32n represents the cluster, and a user cannot sense other nodes in the cluster) according to the cluster remote certification report. The cluster identity public key is in a public state, for example, the control node 31 publishes the cluster identity public key to the outside for being acquired by the client 31. Alternatively, the client 31 obtains the cluster identity information by the above-mentioned method of verifying the cluster identity information. Meanwhile, the contract information of the linked contract may also be in a public state, such as the deployment direction of the linked contract developing the contract information to be acquired by the client terminal 31. 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 contract under the chain in the single-node form described above, in the case that the signature verification and the contract information verification pass, the client 31 may determine that when the client 31 initiates a call to the contract under the chain through the prolog mechanism of the blockchain node, the contract under the chain is executed by the node 32n in the TEE trusted execution environment under the chain, that is, the contract under the chain deployed in the node 32n is guaranteed to be trusted, and a computing task may be executed as expected 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.

In the under-chain contract invocation scheme of the present specification, a block link point may assign a computation task to an under-chain privacy computation node and invoke an under-chain contract deployed on the under-chain privacy computation node to complete the computation task by executing the under-chain contract within an under-chain TEE created by the under-chain privacy computation node. 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.

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.

Furthermore, the target data is used as the input parameter of the contract under the chain, and also belongs to the privacy data of the data owner of the target data. Therefore, for privacy protection, for users who need to invoke a contract under a link to process target data (hereinafter referred to as data users), the data owner can perform authority control on the use rights of the users to the target data. Meanwhile, target data in a plaintext form is held only by a data owner, the data owner can encrypt the target data in the plaintext form (hereinafter referred to as target plaintext data) to obtain target data in a ciphertext form (hereinafter referred to as target ciphertext data), and can decrypt the target ciphertext data only in a chain TEE of the chain privacy computation node. Then, the data owner may provide the target ciphertext data to the user granted the usage right, so that the user subsequently invokes the private computing node under the chain to decrypt the target ciphertext data in the TEE under the chain and execute the contract under the chain to process the decrypted target plaintext data. The method for invoking the chain contract based on the data authority control is described below with reference to fig. 4 to 7.

FIG. 4 is a flowchart of a method for invoking contracts on the data consumer side as provided by an exemplary embodiment. As shown in fig. 4, the method may include the steps of:

step 402, a data user generates a call request for a contract under a chain, wherein the call request comprises target ciphertext data obtained by encrypting target plaintext data and a verifiable statement of the use right of the target plaintext data.

In this embodiment, the precondition for the data user to contract and process the target plaintext data (i.e. understand to use the target plaintext data) under the call execution chain includes: the data owning party of the target plaintext data grants the data using party the right to use the target plaintext data. For example, the data owner may encrypt target plaintext data owned by the data owner to obtain target ciphertext data, and declare that the target ciphertext data needs to be used only by authorization of the data owner. Then, before invoking the contract under the chain, the data user needs to initiate an authorization request for the target plaintext data to the data owner, perform an audit on the data user by the data owner, and after the audit is passed, issue a VC (Verifiable statement) for the usage right of the target plaintext data to the data user, and provide the target ciphertext data. After the data user obtains the VC, the VC can be presented to the privacy calculation node under the chain when the target plaintext data is processed by subsequently calling the contract under the chain, the privacy calculation node under the chain checks the use right of the data user for the target plaintext data according to the VC, and the contract under the chain is executed under the condition that the check is passed so as to complete the processing of the target plaintext data.

In this embodiment, similarly, the way in which the data usage direction submits the call request to the privacy computing node under the chain is different for the single-node form and the cluster form. And under the condition that the privacy computation node under the chain is in a single-node form, the data use direction submits a call request to the blockchain node, and the blockchain node forwards the call request to the privacy computation node under the chain through a prediction machine mechanism. Under the condition that the private computing nodes under the chain belong to the private computing cluster under the chain, the data using direction block chain nodes submit calling requests, the block chain nodes forward the calling requests to the control nodes of the private computing cluster under the chain through a prediction machine mechanism, and then the control nodes forward the calling requests to the private computing nodes under the chain in the cluster. The cluster form is described in detail below with reference to fig. 5, and the single-node form is similar to this.

As shown in FIG. 5, assume that a client 51 of a data consumer wishes to make a call to a deployed under-chain contract (such as after verifying the under-chain contract passes). The client 51 may send a call request to the control node 52 through a downlink channel, where the call request is encrypted by using the public key of the cluster identity, and the control node 52 may distribute the call request to a certain downlink privacy computing node in the cluster, such as the node 52n, based on a load balancing algorithm, where the node 52n responds to the call request. The node 52n decrypts the invocation request by the cluster identity private key in the chain TEE created by itself, thereby obtaining the entry data included in the invocation request. Node 52n may then execute the subcohain contracted bytecode in the subcohain TEE to process the inbound parameter data to obtain a corresponding call result. Further, the node 52n may encrypt the call result in the chain TEE and feed the call result back to the client 51 through the control node 52.

The client 51 may send a call request to the control node 52 through an on-chain channel. The client 51 may submit a contract-down-link call transaction to the blockchain network 53, which includes a call request encrypted by the client 51 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 intercepted by the predictive engine server 54, after which the invocation request is retrieved by the predictive engine server 54 and transmitted to the control node 52. The control node 52 then distributes the invocation request, such as to the down-link privacy computing node 52n, for response. And the control node 52 may feed back the call result to the chain through the prediction mechanism, and the node 53n may initiate a transaction at its own initiative and chain the call result, or the node 53n may feed back the call result to the client 51, and the client 51 re-initiates a transaction and chains the call result.

If the access parameter data is block chain data, namely the data owner has the target ciphertext data provided by the data user to be stored in the block chain, the target ciphertext data can be acquired from the block chain by the data user. The client 51 may submit an encrypted down-link contract call transaction to the blockchain network 53, the down-link contract call transaction including information of the inbound parameter data and the down-link contract call transaction calling an up-link contract for obtaining the inbound parameter data. After receiving the encrypted under-chain contract invocation transaction, the node 53n decrypts the on-chain TEE, executes the invoked on-chain contract through a virtual machine deployed in the on-chain TEE to obtain blockchain data used as entry data, the node 53n may decrypt the blockchain data in the on-chain TEE into a plaintext, packages the blockchain data of the plaintext into an invocation request, encrypts the invocation request by using a cluster identity public key in the on-chain TEE, transmits the invocation request to the control node 52 based on a propheter mechanism, and the control node 52 distributes the invocation request to the under-chain privacy computation node 52n for response. And, the control node 52 may feed back the call result to the chain through the prediction mechanism, and the node 53n may chain the call result.

In the embodiment shown in fig. 5, the example of the private computation cluster is described. In fact, the client 51 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.

Step 404, the data user submits the call request to the private computing node under the chain deployed with the contract under the chain through a preplan mechanism of the block chain, the call request is used for instructing the private computing node under the chain to execute the contract under the trusted execution environment under the chain created by the private computing node under the chain to process the target plaintext data under the condition that a call condition is met, and the call condition comprises that the data owner of the target plaintext data is determined to grant the use right to the data user according to the VC.

In this embodiment, the identity of the data owner, the identity of the data consumer, and the VC are recorded in the call request, and these pieces of information are written into the call request by the data consumer. In other words, the information contained in the call request is provided by the data user, and is used for declaring that the VC is the VC issued by the data user to the data owner of the target plaintext data, and the information in the call request is possible to be forged. Specifically, the counterfeit case includes at least one of: the identity of the data owner recorded in the invocation request is not the identity of the actual data owner, the identity of the data consumer recorded in the invocation request is not the identity of the actual data consumer, the VC included in the invocation request is not issued by the actual data owner, and the VC included in the invocation request is not issued to the actual data consumer. Therefore, after receiving the call request, the down-link privacy computing node should perform the check operation for the above situation to find out the problem of falsification, so as to improve the security of the data. As an exemplary embodiment, in the case that the following verification operations are all passed, the linked privacy computing node may verify that the VC in the call request is a VC issued by a data owner (actual data owner) to a data user (actual data user submitting the call request), that is, it is determined that the data owner grants the data user the right to use the target plaintext data: the data processing method comprises the steps of a first authenticity check operation aiming at the identity of a data owner recorded in a call request, a second authenticity check operation aiming at the identity of a data user recorded in the call request, a third authenticity check operation aiming at an actual issuer of the VC as the data owner, and a fourth authenticity check operation aiming at an actual issuer of the VC as the data user. Wherein the issuers and issuers are understood to be: the VC is issued by an issuing party issuing object. It should be noted that there is no limitation on the execution sequence between the first authenticity check operation and the fourth authenticity check operation.

Identities may be created for individual users by DIS (Decentralized identity Service). The DIS may provide the user with a DID (Decentralized identity) that is not restricted by any single registry, identity facilitator, or authentication center, and is completely controlled by the user himself.

Based on the ID representing the data user and the data owner by DID, the data owner provides the VC to the data user and provides the target ciphertext data, and also provides the first signature information obtained by signing the target plaintext data by using the private key corresponding to the DID of the data owner, so that the first signature information can be used for proving the identity of the data owner. For example, the target plaintext data itself may be directly signed to obtain the first signature information, or the target plaintext data may be hashed to obtain a hash value, and then the hash value is signed to obtain the first signature information. Meanwhile, when the data user generates the call request, in order to prove the identity of the data user, the private key corresponding to the DID of the data user is adopted to sign the call request to obtain corresponding second signature information, and the second signature information is added to the call request. In summary, the call request at least includes the target ciphertext data, the VC, the DID of the data user, the first signature information corresponding to the target plaintext data, the DID of the data owner, and the second signature information corresponding to the call request.

Based on the process of generating the call request, the down-link privacy computing node can perform signature verification on first signature information corresponding to target plaintext data in the call request through a first user public key; wherein the first user public key corresponds to the first DID of the data owner (not necessarily the actual data owner) recorded in the invocation request. Since only the actual data owner holds the target plaintext data (the target ciphertext data obtained by encrypting the target plaintext data is provided for other users), in the case that the signature verification is passed (it is described that the first signature information is obtained by the actual data owner by signing the target plaintext data with its own private key), it is described that the first DID of the data owner recorded in the invocation request is the DID of the actual data owner, and it can be determined that the first authenticity check operation is passed.

Similarly, the chain privacy computing node can judge that the second authenticity check operation passes under the condition that the second signature information corresponding to the call request in the call request is subjected to signature verification through the second user public key and the signature verification passes; wherein the second user public key corresponds to the second DID of the data consumer recorded in the invocation request.

On the basis, in the case that the DID of the actual issuing party of the VC is matched with the first DID, the VC in the calling request is issued by the actual data owner, so that the third authenticity check operation can be judged to be passed. And in the case that the DID of the actual issuing object of the VC matches the second DID, it means that the VC in the call request is received by the actual data consumer (i.e., issued to the actual data consumer), and therefore it can be determined that the fourth authenticity check operation passes.

In this embodiment, when an issuer of a VC issues the VC, it records its own DID and the DID of an object to be issued in the VC; meanwhile, the VC is signed by a private key corresponding to the DID of the VC, and the signature is recorded in the VC for proving the identity of the VC. Thus, the DID of the actual issuer of the VC and the DID of the actual issuer of the VC can be determined by: reading the DID of the issuer of the VC record in the calling request, acquiring a third user public key corresponding to the read DID, performing signature verification on the signature of the VC record in the calling request by adopting the third user public key, and taking the DID of the issuer of the VC record in the calling request as the DID of the actual issuer under the condition that the signature verification is passed; and taking the DID of the issuing object recorded by the VC in the calling request as the DID of the actual issuing object.

In this embodiment, the VC includes a call rule defined by the data owner for the target plaintext data, that is, how the target plaintext data is used by the issuing object of the VC is specified. The calling rule can carry out detailed control on the use right of the target plaintext data; for example, a contract function that allows processing of target plaintext data in a contract under a chain, a validity period of a right to use the target plaintext data, a number of times that the contract under the chain is allowed to be invoked to process the target plaintext data, and a frequency that allows the contract under the chain to be invoked to process the target plaintext data. Therefore, in step 404, after determining that the data owner of the target plaintext data grants the use right to the data consumer according to the VC, the private computation node further needs to check whether the call operation indicated by the call request conforms to the call rule defined by the VC, that is, the call condition further includes that the call operation indicated by the call request conforms to the call rule defined by the VC.

In this embodiment, the data owner may encrypt the target plaintext data by using the contract identity public key of the contract under the chain to obtain the target ciphertext data, thereby ensuring that the target plaintext data can only be obtained by the called contract under the chain, but not by other contract under the chain. And a contract identity private key corresponding to the contract identity public key is maintained in the chain TEE of the chain privacy computing node, so that the chain privacy computing node can decrypt target ciphertext data in a call request by adopting the contract identity private key after receiving the call request aiming at the chain contract.

Similarly, after obtaining a calling result (i.e., an execution result obtained by executing the contract under the chain), the private computation node under the chain may sign the calling result by using the contract identity private key of the called contract under the chain in the TEE under the chain, and after obtaining the execution result that the private computation node under the chain feeds back to the block chain node through the preplanser mechanism, the client of the data user may perform signature verification on the execution result by using the contract identity public key of the called contract under the chain, and when the signature verification passes, determine that the execution result is generated by the called contract under the chain.

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.

As can be seen from the above embodiments, the data owner may encrypt the own target plaintext data to obtain target ciphertext data, provide the target ciphertext data to the data user, and issue the VC of the usage right for the target plaintext data to the data user, so that the permission control on the usage right of the target plaintext data may be implemented, that is, the control on which users call the linked contract to process the target plaintext data is allowed. Through the authorization mechanism aiming at the target plaintext data, the use right of the target plaintext data is controlled by the data owner, and the privacy security of the data owner can be effectively improved. Furthermore, DID is introduced to represent the identity of each user during authorization, so that the identity of each user is really owned and controlled by the user, the user can autonomously create the identity of the user, and the identity management is completely decentralized.

For ease of understanding, the following describes in detail the process in which the data owner issues VC for the target plaintext data usage rights to the data consumer in conjunction with fig. 6-8, and the data consumer processes the target plaintext data by invoking the downchain contract via the VC.

Fig. 6 is a flow diagram of creating a DID provided by an exemplary embodiment. As shown in fig. 6, the method may include the steps of:

in step 602, the data user creates a DID, a public key and a private key corresponding to the DID, and a corresponding DID document through the user client.

In this embodiment, the public key corresponding to the data consumer DID needs to be issued to the blockchain for storage, and the private key corresponding to the data consumer DID is stored by the data consumer, for example, in the consumer client.

In the DIS system, a DID (Decentralized identity) corresponds to an entity (e.g., a user such as a data user or a data owner), and a specific usage manner of the DID is described by a DID Document (DID Document) corresponding to the DID. The DID document is used for describing how to use the corresponding DID, and at least comprises a public key of the corresponding DID; besides, information such as encryption mode, certification purpose, authentication method and service endpoint can be recorded. Wherein the certification goal is combined with a verification method to provide a mechanism to certify an object. For example, a DID document may specify a particular authentication method, such as a public cryptographic key or a pseudonym biometric protocol, that may be used to authenticate a method created for a purpose. The service endpoint supports trusted interaction with the DID controller. DID and DID documents can be directly registered on a blockchain or other distributed network without applying to a centralized registration authority, and by utilizing the characteristics of non-falsification, hash encryption and the like of blockchain and other distributed network technologies, the digital identity can be really owned and controlled by a user, and no intermediary (even a DID technology provider) is contacted to the identity and data of the owner control user.

In step 604, the consumer client creates a transaction for crediting the DID and DID documents.

In step 606, the consumer client initiates the transaction for crediting the DID and DID documents to the blockchain nexus.

At step 608, the blockchain node validates the DID and DID documents on the blockchain.

It should be noted that the blockchain storing the DID and DID documents and the blockchain calling the contract under the chain by using the predictive engine mechanism may be the same blockchain or different blockchains.

In step 610, the user side client obtains a response piece for successful DID creation from the block link point.

In this embodiment, after storing the DID and DID documents, the blockchain node may generate an event for logging success of the DID and DID documents, and store the event into the blockchain log. Then, the client of the user can obtain the event through a callback mechanism of the blockchain, so as to determine that the DID and the DID document have been certified on the blockchain, that is, the data user creates the DID successfully. Meanwhile, a corresponding prompt message can be generated for the data user to check so as to inform the data user that the DID creation on the chain is successful.

FIG. 7 is a flow diagram of a data authorization process provided by an exemplary embodiment. As shown in fig. 7, the process may include the steps of:

at step 702, the data consumer creates an authorization request (containing consumer DID, consumer information, and signature) for the target plaintext data via the consumer client.

In this embodiment, when creating the authorization request, the user information is recorded in the authorization request for the data owner to check whether the data user qualifies for the target plaintext data usage right, that is, the data owner decides whether to authorize the target plaintext data usage right to the data user according to the user information. Meanwhile, the client of the user signs the authorization request by adopting a private key corresponding to the DID of the user, and records the obtained signature in the authorization request so as to indicate the identity of the data user.

In step 704, the consumer client sends an authorization request to the owner client of the data owner.

In step 706, the owning client reads the data consumer DID contained in the authorization request.

In step 708, the owning client initiates a query transaction for the consumer DID to the block nexus.

Step 710, the blockchain node queries the DID document corresponding to the DID of the user.

In step 712, the owner client obtains the queried DID document.

In step 714, the owning client uses the public key in the DID document to sign and verify the signature in the authorization request.

In this embodiment, as can be seen from the process of creating the DID shown in fig. 6, the public key corresponding to the user DID is recorded in the DID document of the user DID, and then the public key can be used to verify whether the user DID in the authorization request is the actual DID of the data user, that is, whether the data user is a legal owner of the user DID in the authorization request.

In this embodiment, besides the above-mentioned manner of adding a signature to the authorization request, an authentication challenge for DID may be initiated by the owning client to the using client to complete verification of the used DID. Specifically, the DID authorization request created by the user client does not need to add a signature, but the owning client initiates a DID authentication challenge (DID auth challenge) message to the user client after acquiring the public key recorded in the DID document corresponding to the user DID, where the message includes a random string for requesting the user client to sign the string with the private key of the user DID. And after receiving the DID authentication challenge message, the client of the user signs the character string by adopting the private key of the DID of the user and sends the character string and the signature to the client of the owner. Then, the owning client may use the public key in the DID document to perform signature verification on the signature, and further, if the signature verification passes, confirm that the data consumer is the legitimate owner of the consumer DID recorded in the authorization request.

In step 716, the owning client checks the user information in the authorization request if the signature verification passes, so as to determine whether to grant the data user the right to use the target plaintext data.

In this embodiment, in addition to the above-mentioned online auditing manner, the data owner may provide the data owner with the user information offline for auditing by the data owner. The specific auditing mode can be flexibly set according to the actual situation; of course, this description is not intended to be limiting.

In step 718, in case of passing the audit, the owning client creates a VC of the usage right of the user for the target plaintext data.

In this embodiment, the DID is an identifier of an entity, and specific information such as which rights, capabilities, behaviors, and assets the entity has is expressed by the VC. It is noted that a DID may have one or more VCs. For example, the following fields may be included in a VC:

an issuer: a declaration issuer (issuer);

didubject: the DID of the declaration recipient (issuing object);

expire: declaring an expiration time;

issue date: declaring an issuance time;

claim: the declaration content can be plaintext, ciphertext, Hash and the like;

proof: and (5) proving effectiveness.

Assume that the data owner has also previously created its own DID in the manner of fig. 6 described above. Then, the data owner may record its own DID in the issuer, record the DID of the data user who passed the audit in the didubject, record the validity period of the usage right of the target plaintext data in the expire, record the time when the VC is issued in the issuance date, record, in the container, a contract function that allows processing of the target plaintext data in the contract under the chain, the number of times that allows processing of the target plaintext data by calling the contract under the chain (i.e., the number of times that the target plaintext data is used), and the frequency that allows processing of the target plaintext data by calling the contract under the chain (i.e., the frequency that the target plaintext data is used). In order to prove that the VC is issued by the data owner, the data owner needs to sign the VC with its own private key and record the signature in proof. Of course, the above description of the fields and the calling rules contained in the VC is only an example, and can be flexibly adjusted according to actual situations in practical applications.

In step 720, the owning client returns the VC and the signature body of the data owner to the consumer client.

In this embodiment, the signature body of the data owner at least includes first signature information, and the first signature information is obtained by signing the target plaintext data by the owner client using a private key corresponding to its DID.

In step 722, the consumer client saves the VC and the signature body.

FIG. 8 is a flowchart of another method for invoking a contract provided by an exemplary embodiment. As shown in fig. 8, the calling process may include the following steps:

step 802, the consumer client creates a call request.

In this embodiment, the user client may obtain target ciphertext data obtained by encrypting the target plaintext data by using the contract identity public key of the contract under the chain by the data owner, and further create a call request when the contract under the chain needs to be called to process the target plaintext data, where the call request includes the target ciphertext data, the VC obtained from the data owner, the data user DID, the signature of the data user, and the signature body of the data owner. The signature of the data user can be obtained by the user client by signing the call request by using a private key corresponding to the DID of the data user. Of course, the call request may also contain information related to the calling operation, such as a contract ID of the contract under the chain, a function name of the called function, and the like. The contract ID may be, for example, a hash of the bytecode of the contract under the chain, so that the privacy-compliant computing node under the chain (possibly deployed with multiple contracts under the chain) can find the bytecode of the corresponding deployed contract under the chain based on the contract ID. The contract under the chain may contain multiple functions, so the function name may indicate the function that the data consumer wishes to call; if the contract under the chain only contains one function, or the data user wishes to call all functions in the contract under the chain, the information of the function name can be omitted from the call request.

Of course, the target ciphertext data may be the reference data, and may be the blockchain data, and the call request may not include the target ciphertext data itself, but may include the description information of the reference data (for example, the reference or storage address of the reference data on the blockchain). The user client may send a call request to the private computing node, for example, the user client may provide a contract call transaction to the blockchain network, where the contract call transaction includes the call request, and the contract call transaction is used to call a contract on the blockchain for obtaining the entry parameter data of the blockchain certificate. Of course, the contract invoking transaction itself may also be transmitted in an encrypted manner, which may refer to the content of the data encrypted transmission described above, and will not be described herein again. Then, after receiving the encrypted under-chain contract invoking transaction, the block link node decrypts the under-chain contract in its own chain TEE, and then executes the invoked on-chain contract through a virtual machine deployed in the on-chain TEE, thereby acquiring the block chain data (i.e., target ciphertext data) serving as the entry parameter data according to the description information recorded in the invoking request. The blockchain nexus may then send the blockchain data to the down-link privacy computing node along with the call request through a predictive engine mechanism. For example, the blockchain node may write the blockchain data into the call request, or package the blockchain data and the call request to send to the down-chain privacy computing node, or read data, such as VC, a signature body, and a DID, included in the call request, and regenerate a call request according to the data and the blockchain data, and send the regenerated call request to the down-chain privacy computing node.

And step 804, the client of the user side submits a call request to the down-link privacy computation node.

And step 806, decrypting the target ciphertext data in the chain TEE by the chain privacy computing node.

Step 808, the down-link privacy computing node initiates a query transaction for the data consumer DID and the data owner DID to the block link.

In this embodiment, in one case, the data owner DID and the data consumer DID may be directly recorded in the call request. The signature body of the data owner may include a data owner DID. In this case, the data owner DID is used as the first DID of the data owner recorded in the call request, and the data consumer DID is used as the second DID of the data consumer recorded in the call request. In another case, the invocation request may not directly record the data owner DID and the data consumer DID, but may use the issuer recorded in the VC in the invocation request as the first DID and the issuer recorded in the VC in the invocation request as the second DID.

In the present embodiment, the query transaction includes a data consumer DID and a data owner DID, so that a corresponding DID document is queried from a blockchain (a blockchain for storing the DID and DID documents). Certainly, the link privacy computing node queries the block chain for the DID document of the data user, and the DID document of the data owner may be independent of each other, and no priority exists. For example, the private computation node under the chain may also query the block chain for the DID document of the data user first, and then query the DID document of the data owner; or, the block chain is inquired about the DID document of the data owner first, and then the DID document of the data user is inquired about.

In step 810, the block nodes query the DID document of the data user and the DID document of the data owner.

In step 812, the linked privacy computation node obtains the DID document queried by the blockchain node.

In step 814, the down-link privacy computing node verifies the signature of the data owner.

In step 816, the private computation node verifies the signature of the data user.

In the embodiment, a data owner DID, a data consumer DID and a VC are recorded in the call request, and these information are provided by the data consumer to declare that the VC is a VC issued by the data owner of the target plaintext data to the data consumer, and there is a possibility of forgery of the above information in the call request. Specifically, the counterfeit case includes at least one of: the data owner DID recorded in the invocation request is not the actual data owner DID (the actual data owner DID is the DID of the actual owner of the target plaintext data), the data consumer DID recorded in the invocation request is not the actual data consumer DID (for example, the data consumer initiating the invocation request fills the DID of another user to impersonate the user), the VC included in the invocation request is not issued by the actual data owner, and the VC included in the invocation request is not issued to the actual data consumer.

Therefore, the private computation node under the chain can perform signature verification on the signature (i.e. the first signature information) recorded in the signature body through the public key (i.e. the first user public key) recorded in the DID document of the data owner. Since only the actual data owner holds the target plaintext data (the target ciphertext data is provided to other users), the target plaintext data can be signed, and other users cannot sign the target plaintext data, the data owner DID (i.e., the first DID) recorded in the invocation request is indicated as the actual data owner DID under the condition that the signature verification is passed (the signature in the signature body is obtained by the actual data owner signing the target plaintext data by using the private key corresponding to the DID). Taking a digital signature manner as an example, when a data owner provides a signature body, a hash calculation is performed on target plaintext data to obtain a first hash value, then a private key corresponding to a self DID is used to sign the first hash value to obtain first signature information, and the first signature information is added to the signature body. The privacy computation node under the chain decrypts the target ciphertext data through the step 806 to obtain target plaintext data, performs hash computation on the target plaintext data to obtain a second hash value, and performs signature verification on the first signature information based on the second hash value and the public key recorded in the DID document of the data owner, so that the DID of the data owner recorded in the call request is determined to be the actual DID of the data owner under the condition that the signature verification is passed, and the possibility of counterfeiting the DID of the data owner is eliminated.

It should be noted that there may be multiple pairs of asymmetric keys for signature by the data owner, and then when the data owner provides the signature body, the data owner may add a public key ID to the signature body, where the public key corresponding to the public key ID and a private key used for signing target plaintext data are a pair of asymmetric key pairs.

Similarly, the second signature information recorded in the call request is obtained by signing the call request by the data user by using a private key corresponding to the DID of the data user. Therefore, the down-link privacy computation node may perform signature verification on the second signature information by using a public key (i.e., a second user public key) recorded in the DID document of the data user, and in a case that the signature verification is passed, determine that the second DID of the data user recorded in the invocation request is the actual data user DID.

In step 818, the down-link privacy computation node checks whether the actual issuer of the VC is the data owner.

And step 820, the down-link privacy computation node checks whether the actually issued object of the VC is a data user.

The verification performed in the above step 814-816 further verifies whether the VC in the invocation request is the VC issued by the data owner to the data consumer. For example, when the data owner DID and the data consumer DID recorded in the call request pass the verification, if the DID of the actual issuer of the VC matches the data owner DID, it indicates that the VC in the call request was issued by the actual data owner. And if the DID of the actual issuing object of the VC is matched with the DID of the data user, the VC in the calling request is received by the actual data user (namely, issued to the actual data user). It should be noted that there is no limitation on the time sequence between steps 814 and 820, and the sequence in this embodiment is only an example.

As can be seen from the process of issuing a VC in fig. 7, when an issuer of a VC issues the VC, it records its own DID and the DID of an issuing object in the VC, and at the same time, signs the VC with a private key corresponding to its own DID, and records the signature in the proof of its own identity. Firstly, first

The data owner DID and the data consumer DID recorded in the call request are verified and the verification is explained by way of example. And if the DID of the issuer recorded in the VC is different from the DID of the data owner or the DID of the issuer recorded in the VC is different from the DID of the data user, indicating that the VC is incorrect, and judging that the target plaintext data is forbidden to be used. Otherwise, further reading the issuer DID recorded by the issuers of the VC, acquiring a third user public key (namely, the public key recorded in the DID document of the data owner) corresponding to the read issuer DID, performing signature verification on the signature recorded in the proof by adopting the third user public key, and confirming that the VC passes the verification under the condition that the signature verification passes, namely confirming that the issuer DID recorded by the VC is the DID of the actual issuer (also the actual data owner DID); and the issuing object DID recorded by the VC is the DID of the actual issuing object (also the actual data consumer DID).

In step 822, the down-link privacy computing node checks whether the call operation conforms to the call rule defined in the VC.

In this embodiment, after confirming that the VC in the call request is a VC issued by a data owner (actual data owner) of the target plaintext data to a data consumer (i.e., actual data consumer submitting the call request), the link privacy computing node may approve the call rule defined in the VC, i.e., the call rule defined in the VC is trusted. Then, the usage right of the data user for the target plaintext data can be further controlled according to the calling rule.

It may be checked whether the invocation operation indicated by the invocation request complies with the invocation rules defined in the VC. If yes, go to step 824; otherwise, the data user is judged to forbid executing the under-chain contract to process the target plaintext data. For example, when the use right of the data user for the target plaintext data is judged to be expired according to the expire in the VC, the execution of the contract under the chain is prohibited to process the target plaintext data. For another example, when the contract function that the data user needs to call does not conform to the contract function defined in the call rule that allows the target plaintext data to be processed, the execution chain contract is prohibited from processing the target plaintext data. Of course, the specific content of the calling rule can be flexibly set according to the actual requirement, and the specification does not limit this.

At step 824, the down-link privacy computing node performs the down-link contract within the TEE.

In step 826, the private chain computing node signs the execution result within the TEE using the contract identity private key of the contract under the chain.

And step 828, feeding back the execution result to the user client by the down-link privacy computation node.

In step 830, the user client verifies the execution result with the contract public key of the linked contract.

Corresponding to the above embodiment of the data consumer side, the present specification also proposes an embodiment of the node side of the privacy computation under the chain, and the description related to the embodiment of the data consumer side may also be applied to the embodiment of the node side of the privacy computation under the chain, which is not described in detail below.

Accordingly, FIG. 9 is a flowchart of a method for chaining invocation contracts on the private computing node side provided by an exemplary embodiment. As shown in fig. 9, the method may include the steps of:

in step 902, a down-link privacy computing node receives a call request for a down-link contract deployed by a down-link privacy computing node, which is submitted by a data user through a prolog mechanism of a block chain, where the call request includes target ciphertext data obtained by encrypting target plaintext data and a verifiable statement of a usage right for the target plaintext data.

As described above, the downlinked privacy computing node receives the call request forwarded by the blockchain node through the prolog mechanism, and the call request is submitted to the blockchain node by the data consumer; alternatively, the first and second electrodes may be,

under the condition that the private computing node belongs to the private computing cluster, the private computing node receives the call request forwarded by the control node of the private computing cluster, and the call request is submitted to the block chain node by the data user and forwarded to the control node by the block chain node through the prediction mechanism.

Step 904 the down-link privacy computing node executes the down-link contract within the down-link trusted execution environment created by the down-link privacy computing node to process the target plaintext data if a call condition is satisfied, the call condition including determining that a data owner of the target plaintext data grants the usage right to the data consumer according to the verifiable statement.

As described above, the node determines that the data owner has granted the use right to the data consumer if the following checking operations are passed:

a first authenticity check operation for the identity of the data owner recorded in the invocation request, a second authenticity check operation for the identity of the data consumer recorded in the invocation request, a third authenticity check operation for the actual issuer of the verifiable statement as the data owner, and a fourth authenticity check operation for the actual issuer of the verifiable statement as the data consumer.

As described above, the down-link privacy computing node determines that the first authenticity check operation passes when signature verification is performed on first signature information corresponding to the target plaintext data in the invocation request through a first user public key, and the signature verification passes, where the first user public key corresponds to a first decentralized identity identifier of the data owner recorded in the invocation request;

the down-link privacy computing node judges that the second authenticity check operation passes under the condition that the second signature information corresponding to the calling request in the calling request is subjected to signature verification through a second user public key and the signature verification passes, wherein the second user public key corresponds to a second decentralized identity identifier of the data user recorded in the calling request;

the down-link privacy computing node determining that the third authenticity check operation passes if a decentralized identity identifier of a physical issuer of the verifiable claims matches the first decentralized identity identifier;

the downlink privacy computing node determines that the fourth authenticity check operation passes if the decentralized identity identifier of the actual object of issuance of the verifiable claim matches the second decentralized identity identifier.

As described above, the down-link privacy computing node may read the decentralized identity identifier of the issuer that can verify the statement record in the invocation request, and obtain the third user public key corresponding to the read decentralized identity identifier; signature verification is carried out on the signature of the verifiable statement record in the calling request by adopting the third user public key, and the decentralized identity identifier of the issuer of the verifiable statement record in the calling request is used as the decentralized identity identifier of the actual issuer under the condition that the signature verification is passed; and taking the decentralized identity identifier of the issuing object recorded by the verifiable statement in the calling request as the decentralized identity identifier of the actual issuing object.

As mentioned above, the calling condition further includes that the calling operation indicated by the calling request conforms to the calling rule defined by the verifiable declaration.

As previously mentioned, the invocation rule includes at least one of:

the contract function allowing the target plaintext data to be processed in the contract under the chain, the validity period of the usage right of the target plaintext data, the number of times the contract under the chain is allowed to be called to process the target plaintext data, and the frequency of allowing the contract under the chain to be called to process the target plaintext data.

As described above, the target ciphertext data is obtained by encrypting the target plaintext data by the data owner using the contract identity public key of the contract under the chain, a contract identity private key corresponding to the contract identity public key is maintained in the trusted execution environment under the chain, and the target ciphertext data is decrypted by the private computing node under the chain in the trusted execution environment under the chain using the contract identity private key.

As described above, the private chain computing node signs an execution result obtained by executing the private chain contract with a contract identity private key of the private chain contract in the trusted chain execution environment;

the private computation node under the chain feeds back the execution result to the block chain link point through the language predicting machine mechanism so as to be obtained by the data user, and the data user judges that the execution result is generated by the contract under the 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 chain and the signature verification is passed.

As described above, prior to receiving the invocation request, the private chain computing node provides a remote attestation report for the trusted chain execution environment to a data consumer, the remote attestation report being generated by an authentication server after verification of referral information generated by the private chain computing node for the trusted chain execution environment;

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

and under the condition that the data user confirms that the under-chain trusted execution environment is trusted according to the remote certification report, the contract information to be verified is subjected to signature verification by adopting the identity public key of the under-chain privacy computing node, the contract information to be verified is subjected to contract information verification according to the contract information of the under-chain contract, and under the condition that the signature verification and the contract information verification are passed, the under-chain contract is executed in the under-chain trusted execution environment by the under-chain privacy computing node when the data user confirms that the under-chain contract is invoked through a prediction machine mechanism of a block chain node.

As described above, the down-link privacy computing node receives a challenge issued by the data consumer to the down-link privacy computing node, and returns the remote attestation report to the data consumer; 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 a control node of the down-link privacy computing cluster receives a challenge initiated by the data user, sending the remote attestation report to the control node, wherein the remote attestation report is returned to the data user 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 data consumer, 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 is passed and a remote authentication result included in the remote attestation report is authenticated, and a comparison result is consistent and is used as a precondition for the data consumer to confirm that the trusted execution environment under the chain is trusted.

As mentioned above, the down-link privacy computation node provides the data consumer with first identity information, where the first identity information includes an identity public key of the down-link privacy computation node and other identity information of the down-link privacy computation node, and the first identity information is subjected to hash computation by the data consumer to obtain a second hash value to be verified;

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

the second standard hash value is used for being compared with the second hash value to be verified, and the data user 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 private computing node under the chain provides second identity information of the private computing node to the data consumer, where the second identity information includes an identity public key of the private computing node under the chain, other identity information of the private computing node under the chain, and a fourth hash value to be checked, where the fourth hash value to be checked is a hash value of preset information of the trusted execution environment under the chain;

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

the second identity information is subjected to signature verification on the remote certification report according to the public key of the authentication server by the data user, and is subjected to hash calculation by the data user to obtain a third hash value to be verified under the condition that the signature verification is passed and the remote authentication result contained in the remote certification report is passed; wherein, the precondition for confirming that the trusted execution environment under the chain is trusted includes that, when the third hash value to be verified is consistent with the third standard hash value, the fourth hash value to be verified is consistent with a fourth standard hash value, which is obtained by the data consumer in advance and is for 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.

As previously described, an identity private key corresponding to the identity public key is maintained within the linked trusted execution environment; and the private chain computing node decrypts the calling request by adopting the identity private key in the trusted chain execution environment, and the calling request is encrypted by the data user by adopting the identity public key of the private chain computing node.

As described above, the identity private key of the down-link privacy computing node is a node identity private key in the node identity keys of the down-link privacy computing node, and the identity public key of the down-link privacy computing node is a node identity public key in the node identity keys; during the process that a block link node interacts with the offline privacy computation node to deploy or invoke an offline contract, the node identity key is used for encrypting and decrypting interaction data and/or verifying signature and signature; 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 public key of the down-link privacy computing node is a cluster identity public key in a cluster identity key of the down-link privacy computing cluster, and the identity private key of the down-link privacy computing node 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 verifying signature and signature of the interaction data 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.

In the technical scheme of the specification, a data user can directly interact with the privacy computing node through a user client to complete operations of deploying an 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 a 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. 10 is a flowchart of another method for invoking contracts on the data consumer side as provided by an exemplary embodiment. As shown in fig. 10, the method may include the steps of:

in step 1002, the data user generates a call request for the intelligent contract, where the call request includes target ciphertext data obtained by encrypting the target plaintext data and a verifiable statement of the usage right for the target plaintext data.

And 1004, the data using direction submits the calling request to a private computing node deployed with the intelligent contract, wherein the calling request is used for instructing the private computing node to execute the intelligent contract in a trusted execution environment created by the private computing node to process the target plaintext data under the condition that a calling condition is met, and the calling condition comprises that the data owning direction of the target plaintext data is granted the using right to the data using party according to the verifiable statement.

As described above, the privacy computing node determines that the data owner has granted the use right to the data consumer when all of the following verification operations pass:

As described above, in the case that the signature verification is performed on the first signature information corresponding to the target plaintext data in the invocation request through a first user public key, and the signature verification is passed, it is determined that the first authenticity check operation is passed, where the first user public key corresponds to the first decentralized identity identifier of the data owner recorded in the invocation request;

under the condition that signature verification is carried out on second signature information corresponding to the calling request in the calling request through a second user public key, and the signature verification is passed, judging that the second authenticity check operation is passed, wherein the second user public key corresponds to a second decentralized identity identifier of the data user recorded in the calling request;

determining that the third authenticity check operation passes if a decentralized identity identifier of a physical issuer of the verifiable claim matches the first decentralized identity identifier;

in the event that the decentralized identity identifier of the actual object of issuance of the verifiable claim matches the second decentralized identity identifier, determining that the fourth authenticity check operation passed.

As previously described, the decentralized identity of the actual issuer and the decentralized identity of the actual issuer are determined by:

reading a decentralized identity identifier of an issuer capable of verifying statement records in the calling request, and acquiring a third user public key corresponding to the read decentralized identity identifier;

signature verification is carried out on the signature of the verifiable statement record in the calling request by adopting the third user public key, and the decentralized identity identifier of the issuer of the verifiable statement record in the calling request is used as the decentralized identity identifier of the actual issuer under the condition that the signature verification is passed; and the number of the first and second groups,

and taking the decentralized identity identifier of the issuing object recorded by the verifiable statement in the calling request as the decentralized identity identifier of the actual issuing object.

As previously mentioned, the invocation rule includes at least one of:

the intelligent contract comprises a contract function which is allowed to process the target plaintext data, a validity period of the usage right of the target plaintext data, the number of times of allowing the intelligent contract to be called to process the target plaintext data, and the frequency of allowing the intelligent contract to be called to process the target plaintext data.

As previously described, prior to submitting the invocation request, the data consumer obtains a remote attestation report for the trusted execution environment, the remote attestation report generated by an authentication server after verifying self-referral information generated by the private computing node for the trusted execution environment;

the data user acquires contract information to be verified of the 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;

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

As described above, the data consumer 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.

As described above, the data user 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 data user 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 data user in the trusted execution environment;

and the data user 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 data user performs signature verification on the remote attestation report according to the public key of the authentication server, and obtains the second identity information provided by the privacy computing 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 calculation on the obtained 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 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;

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.

Accordingly, FIG. 11 is a flowchart of a method for privacy-preserving compute node-side invocation contracts provided by an exemplary embodiment. As shown in fig. 11, the method may include the steps of:

step 1102, a privacy computing node receives a call request of an intelligent contract deployed for the privacy computing node, the call request being submitted by a data user, where the call request includes target ciphertext data obtained by encrypting target plaintext data and a verifiable statement of a usage right for the target plaintext data.

And 1104, the privacy computing node executes the intelligent contract in the trusted execution environment created by the privacy computing node to process the target plaintext data under the condition that a calling condition is met, wherein the calling condition comprises that the data owner of the target plaintext data is determined to grant the use right to the data user according to the verifiable statement.

As described above, the privacy computing node determines that the data owner has granted the use right to the data consumer if all of the following checking operations pass:

As described above, the privacy computing node determines that the first authenticity check operation passes under the condition that the signature verification is performed on the first signature information corresponding to the target plaintext data in the invocation request through a first user public key, and the signature verification passes, where the first user public key corresponds to the first decentralized identity identifier of the data owner recorded in the invocation request;

the privacy computing node judges that the second authenticity check operation passes under the condition that the second signature information corresponding to the calling request in the calling request is subjected to signature verification through a second user public key and the signature verification passes, wherein the second user public key corresponds to a second decentralized identity identifier of the data user recorded in the calling request;

the privacy computing node determining that the third authenticity check operation passes if a decentralized identity identifier of a physical issuer of the verifiable claim matches the first decentralized identity identifier;

the privacy computing node determines that the fourth authenticity check operation passes if the decentralized identity identifier of the actual issuing object of the verifiable claim matches the second decentralized identity identifier.

As previously described, the determining, by the privacy computing node, the decentralized identity identifier of the actual issuer and the decentralized identity identifier of the actual issuer comprises:

As previously mentioned, the invocation rule includes at least one of:

As previously described, prior to receiving the invocation request, a private computing node provides a remote attestation report for the trusted execution environment to a data consumer, the remote attestation report generated by an authentication server after verification of self-referral information generated by the private computing node for the trusted execution environment;

the private computing node providing to the data consumer contract information to be verified for the intelligent 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 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 contract information to be verified is subjected to signature verification on the contract information to be verified by the data user by adopting the identity public key of the private computing node under the condition that the trusted execution environment is determined to be trusted according to the remote certification report, the contract information to be verified is subjected to contract information verification on the contract information to be verified according to the contract information of the intelligent contract, and the intelligent contract is executed in the trusted execution environment by the private computing node when the data user initiates invocation on the intelligent contract under the condition that the signature verification and the contract information verification are passed.

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, and the first hash value to be verified is used for comparing, when the data user performs signature verification and signature verification on the remote attestation report according to the public key of the authentication server and the remote attestation report passes the signature verification, with a first standard hash value which is obtained in advance for the trusted execution environment, and a comparison result is consistent and is used as a precondition for the data user to confirm that the trusted execution environment is trusted.

As mentioned above, the privacy computing node provides first identity information to the data consumer, 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 hashed by the data consumer to obtain a second hash value to be verified;

the privacy computing node provides a second standard hash value to the data user, 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;

As described above, the privacy computing node provides second identity information of the privacy computing node to the data consumer, 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 data user, and 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;

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

Corresponding to the above method embodiments, the present specification also provides embodiments of a device for invoking a contract.

The embodiment of the contract invoking device in the specification can be applied to the electronic equipment. 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. 12, fig. 12 is a schematic block diagram of an apparatus according to an exemplary embodiment. As shown in fig. 12, at the hardware level, the apparatus includes a processor 1202, an internal bus 1204, a network interface 1206, a memory 1208, and a non-volatile storage 1212, although other hardware required for services may be included. The processor 1202 reads a corresponding computer program from the nonvolatile memory 1212 into the memory 1208 and then runs the computer program, thereby forming a device for calling 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. 13, in a software implementation, the apparatus for invoking the contract on the data consumer side may include:

a generation unit 1301 causing a data user to generate a call request for a contract under a link, where the call request includes target ciphertext data obtained by encrypting target plaintext data and a verifiable statement of a usage right for the target plaintext data;

a submitting unit 1302, configured to enable the data consumer to submit, through a preplan mechanism of the block chain, the call request to the offline privacy computing node where the offline contract is deployed, where the call request is used to instruct the offline privacy computing node to execute the offline contract within the offline trusted execution environment created by the offline privacy computing node to process the target plaintext data if a call condition is met, where the call condition includes that it is determined that the data owner of the target plaintext data grants the usage right to the data consumer according to the verifiable statement.

Optionally, the submitting unit 1302 is specifically configured to:

enabling the data use direction blockchain node to submit the call request, and forwarding the call request to the down-link privacy computing node through the preloader mechanism by the blockchain 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 data using direction submits the calling request to a blockchain node, the blockchain node forwards the calling request to a control node of the down-link privacy computing cluster through the propheter mechanism, and the calling request is forwarded to the down-link privacy computing node by the control node.

Optionally, when the following verification operations are all passed, the down-link privacy computing node determines that the data owning party has granted the right to use by the data using party:

Alternatively to this, the first and second parts may,

under the condition that signature verification is carried out on first signature information corresponding to the target plaintext data in the calling request through a first user public key, and the signature verification is passed, judging that the first authenticity verification operation is passed, wherein the first user public key corresponds to a first decentralized identity identifier of the data owner recorded in the calling request;

Optionally, the decentralized identity identifier of the actual issuer and the decentralized identity identifier of the actual issuer are determined by the following method:

Optionally, the calling condition further includes that a calling operation indicated by the calling request conforms to a calling rule defined by the verifiable statement.

Optionally, the invoking rule includes at least one of:

Optionally, the target ciphertext data is obtained by encrypting the target plaintext data by the data owner using a contract identity public key of the contract under the chain, a contract identity private key corresponding to the contract identity public key is maintained in the trusted execution environment under the chain, and the target ciphertext data is decrypted by the private computing node under the chain using the contract identity private key in the trusted execution environment under the chain.

Optionally, the submitting unit 1302 is specifically configured to:

enabling the data user to obtain an execution result fed back to a block chain node by the private computing node through the preplan mechanism, wherein the execution result is obtained by the private computing node executing the contract under the chain and is signed by a contract identity private key of the contract under the chain in the trusted execution environment under the chain;

and the data user judges that the execution result is generated by the contract under the chain under the condition that the execution result is subjected to signature verification by adopting the contract identity public key of the contract under the chain and the signature verification is passed.

Optionally, before submitting the call request, the apparatus further includes:

a report obtaining unit 1303, configured to enable the data consumer to obtain a remote attestation report for the under-link trusted execution environment, where the remote attestation report is generated by an authentication server after verifying self-referral information generated by the under-link privacy computing node for the under-link trusted execution environment;

an information obtaining unit 1304, configured to, in a case where the data consumer determines that the under-chain trusted execution environment is trusted according to the remote attestation report, obtain contract information to be verified of the 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 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;

the verifying unit 1305 enables the data user 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 contract under the chain, and determine that the contract under the chain is executed by the private computing node under the chain when the data user initiates a call to the contract under the chain through the prompter mechanism under the condition that the signature verification and the contract information verification pass.

Optionally, the report obtaining unit 1303 is specifically configured to:

enabling the data using direction to initiate a challenge to the down-link privacy computing node and receiving 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, the data using direction 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.

Optionally, the information obtaining unit 1304 is specifically configured to:

enabling the data user to perform 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.

Optionally, the verification unit 1305 is specifically configured to:

enabling the data user to obtain first identity information provided by the down-link privacy computing node, and performing hash computation on the obtained 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;

the data user acquires 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;

Optionally, the information obtaining unit 1304 is specifically configured to:

enabling the data user to perform signature verification on the remote certification report according to the public key of the authentication server, acquire second identity information provided by the private computation node under the chain when the signature verification is passed and a remote authentication result contained in the remote certification report is passed, and perform hash computation 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 computation node under the chain, other identity information of the private computation node under the chain 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 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.

Optionally, the data user encrypts the call request by using the identity public key of the private computing node under the chain, an identity private key corresponding to the identity public key is maintained in the trusted execution environment under the chain, and the call request is decrypted by using the identity private key in the trusted execution environment under the chain by the private computing node under the chain.

Optionally, the identity private key of the down-link privacy computing node is a node identity private key in a node identity key of the down-link privacy computing node, and the identity public key of the down-link privacy computing node is a node identity public key in the node identity key; during the process that a block link node interacts with the offline privacy computation node to deploy or invoke an offline contract, the node identity key is used for encrypting and decrypting interaction data and/or verifying signature and signature; alternatively, the first and second electrodes may be,

Referring to fig. 14, in another software implementation, the apparatus for invoking contracts at the side of the down-link privacy computing node may include:

a receiving unit 1401, configured to enable a down-link privacy computing node to receive a call request for a down-link contract deployed by a down-link privacy computing node, where the call request is submitted by a data user through a prolog mechanism of a block chain, and includes target ciphertext data obtained by encrypting target plaintext data and a verifiable statement of a usage right for the target plaintext data;

an executing unit 1402, configured to cause the down-chain privacy computing node to execute the down-chain contract within the down-chain trusted execution environment created by the down-chain privacy computing node to process the target plaintext data if a call condition is satisfied, where the call condition includes that the data owner of the target plaintext data is granted the usage right to the data consumer according to the verifiable statement.

Optionally, the downlink privacy computation node receives the call request forwarded by the blockchain node through the talker predicting mechanism, and the call request is submitted to the blockchain node by the data consumer; alternatively, the first and second electrodes may be,

Optionally, the node under the chain privacy computing node determines that the data owning party has granted the right to use to the data using party when all the following verification operations pass:

Alternatively to this, the first and second parts may,

the lower-chain privacy computing node judges that the first authenticity check operation passes under the condition that the first signature information corresponding to the target plaintext data in the calling request is subjected to signature verification through a first user public key and the signature verification passes, wherein the first user public key corresponds to a first decentralized identity identifier of the data owner recorded in the calling request;

Optionally, the execution unit 1402 is specifically configured to:

enabling the down-link privacy computing node to read the decentralized identity identifier of the issuer capable of verifying the statement record in the calling request, and acquiring a third user public key corresponding to the read decentralized identity identifier;

Optionally, the invoking rule includes at least one of:

Optionally, the execution unit 1402 is specifically configured to:

the chain privacy computing node adopts a contract identity private key of the chain contract to sign an execution result obtained by executing the chain contract in the chain trusted execution environment;

Optionally, before receiving the invocation request, the apparatus further includes:

a report providing unit 1403, which causes the down-link privacy computing node to provide a remote attestation report for the down-link trusted execution environment to a data consumer, where 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;

an information providing unit 1404 that causes the down-link private computing node to provide, to the data consumer, contract information to be verified for the down-link contract deployed at the down-link private computing node, the contract information to be verified being signed by the down-link private computing node within the down-link trusted execution environment with an identity private key of the down-link private computing node, the identity private key being maintained by the down-link private computing node within the down-link trusted execution environment;

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

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

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, and the first hash value to be verified is used for comparing, when the data user performs signature verification and signature verification on the remote attestation report according to the public key of the authentication server and the remote attestation report passes the signature verification and includes a remote authentication result that is authenticated, a first standard hash value obtained in advance for the trusted execution environment under the chain, and the comparison result is consistent and is used as a precondition that the data user confirms that the trusted execution environment under the chain is trusted.

Optionally, the information providing unit 1404 is specifically configured to:

enabling the down-link privacy computation node to provide first identity information to the data user, wherein the first identity information comprises an identity public key of the down-link privacy computation node and other identity information of the down-link privacy computation node, and the first identity information is subjected to hash computation by the data user to obtain a second hash value to be verified;

providing a second standard hash value to the data user, wherein the second standard hash value is obtained by performing hash calculation on generated identity information after the private computation node under the chain generates identity information of the private computation node under the chain in the trusted execution environment;

Optionally, the information providing unit 1404 is specifically configured to:

enabling the private computing node under the chain to provide second identity information of the private computing node under the chain to the data user, wherein the second identity information comprises an identity public key of the private computing node under the chain, other identity information of the private computing node under the chain 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 trusted execution environment under the chain;

providing a third standard hash value to the data user, wherein the third standard hash value is obtained by performing hash calculation on generated identity information after the private computation node under the chain generates identity information of the private computation node under the chain in the trusted execution environment;

Optionally, an identity private key corresponding to the identity public key is maintained in the trusted execution environment under the chain; the submission unit 1401 is specifically configured to:

and the private chain computing node decrypts the calling request by adopting the identity private key in the trusted chain execution environment, and the calling request is encrypted by the data user by adopting the identity public key of the private chain computing node.

Referring to fig. 15, in another software implementation, the apparatus for invoking the contract on the data consumer side may include:

a generation unit 1501 that causes a data usage side to generate a call request for an intelligent contract, the call request including target ciphertext data obtained by encrypting target plaintext data and a verifiable declaration of a usage right for the target plaintext data;

a submitting unit 1502 enabling the data usage direction to submit the call request to the privacy computing node with the intelligent contract, where the call request is used to instruct the privacy computing node to execute the intelligent contract in the trusted execution environment created by the privacy computing node to process the target plaintext data if a call condition is met, where the call condition includes that the data owner of the target plaintext data grants the usage right to the data user according to the verifiable statement.

Optionally, when the following verification operations are all passed, the privacy computing node determines that the data owning party grants the right to use the data to the data using party:

Alternatively to this, the first and second parts may,

Optionally, the invoking rule includes at least one of:

Optionally, before submitting the call request, the apparatus further includes:

a report obtaining unit 1503 that causes the data consumer to obtain a remote attestation report for the trusted execution environment, the remote attestation report being generated by an authentication server after verifying self-referral information generated by the private computing node for the trusted execution environment;

an information obtaining unit 1504 that, in a case where it is determined from the remote attestation report that the trusted execution environment is trusted, obtains contract information to be verified of the intelligent 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 using 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 verifying unit 1505 enables the data user to perform 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 intelligent contract, and determines that the intelligent contract is executed in the trusted execution environment by the privacy computing node when the data user initiates calling on the intelligent contract under the condition that the signature verification and the contract information verification are passed.

Optionally, the report obtaining unit 1503 is specifically 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;

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 information obtaining unit 1504 is specifically configured to:

the data user 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;

Optionally, the information obtaining unit 1504 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;

Referring to fig. 16, in another software implementation, the apparatus for invoking contracts on the private computing node side may include:

a receiving unit 1601, configured to enable a privacy computing node to receive a call request of an intelligent contract deployed for the privacy computing node, where the call request is submitted by a data user, and includes target ciphertext data obtained by encrypting target plaintext data and a verifiable statement of a usage right for the target plaintext data;

an executing unit 1602, causing the private computing node to execute the smart contract within the trusted execution environment created by the private computing node to process the target plaintext data if a calling condition is satisfied, where the calling condition includes that the data owner of the target plaintext data is granted the usage right to the data consumer according to the verifiable statement.

Optionally, the privacy computing node determines that the data owning party grants the right to use to the data using party when the following verification operations are all passed:

Alternatively to this, the first and second parts may,

the privacy computing node judges that the first authenticity check operation passes under the condition that signature verification is performed on first signature information corresponding to the target plaintext data in the calling request through a first user public key, and the signature verification passes, wherein the first user public key corresponds to a first decentralized identity identifier of the data owner recorded in the calling request;

Optionally, the determining, by the privacy computing node, the decentralized identity identifier of the actual issuer and the decentralized identity identifier of the actual issuer includes:

Optionally, the invoking rule includes at least one of:

a report providing unit 1603, which enables the private computing node to provide a remote attestation report aiming at the trusted execution environment to a data user, wherein the remote attestation report is generated by verifying self-referral information generated by the private computing node aiming at the trusted execution environment by an authentication server;

an information providing unit 1604 that causes the private computing node to provide to the data consumer contract information to be verified for the smart 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 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;

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 data user, 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 passes and a remote authentication result included in the remote attestation report is that the remote authentication passes, and a comparison result is consistent and used as a precondition for the data user to confirm that the trusted execution environment is trusted.

Optionally, the information providing unit 1604 is specifically configured to:

the privacy computing node provides first identity information to the data user, 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 data user to obtain a second hash value to be verified;

Optionally, the information providing unit 1604 is specifically configured to:

the private computing node provides second identity information of the private computing node to the data user, the second identity information comprises an identity public key of the private computing node, other identity information of the private 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 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.

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 invoking a contract, comprising:

2. The method of claim 1, the data consumer submitting the invocation request to a down-link privacy compute node deployed with the down-link contract through a prolog mechanism of a blockchain, comprising:

the data use direction blockchain node submits the call request, and the blockchain node forwards the call request to the down-link privacy computing node through the preloader mechanism; alternatively, the first and second electrodes may be,

3. The method of claim 1, the down-link privacy computing node determining that the data owner granted the usage rights to the data consumer if all of the following checking operations pass:

4. The method of claim 3, wherein the first and second light sources are selected from the group consisting of,

5. The method of claim 4, determining the de-centralized identity of the actual issuer and the de-centralized identity of the actual issuer by:

6. The method of claim 1, the invocation condition further comprising an invocation rule defined by the verifiable statement that a calling operation indicated by the invocation request conforms to.

7. The method of claim 6, the invocation rule including at least one of:

8. The method of claim 1, the target ciphertext data being encrypted by the data owner using a contract identity public key of the contract under the chain, a contract identity private key corresponding to the contract identity public key being maintained within the trusted execution environment under the chain, the target ciphertext data being decrypted by the private computing node under the chain within the trusted execution environment using the contract identity private key.

9. The method of claim 1, further comprising:

the data user acquires an execution result fed back to a block chain node by the private computing node through the prompter mechanism, wherein the execution result is obtained by executing the contract under the chain by the private computing node and is signed by a contract identity private key of the contract under the chain in the trusted execution environment under the chain;

10. The method of claim 1, prior to submitting the call request, the method further comprising:

the data user acquires a remote attestation report aiming at the chain-down trusted execution environment, wherein the remote attestation report is generated by an authentication server after verification of self-recommendation information generated by the chain-down private computing node aiming at the chain-down trusted execution environment;

the data user acquires contract information to be verified of the contract under the chain deployed at the private computing node under the chain under the condition that the trusted execution environment under the chain is determined to be trusted according to the remote attestation report, the contract information to be verified is signed by the private computing node under the chain in the trusted execution environment under the chain by adopting 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;

and the data user adopts the identity public key of the private computation node under the chain to carry out signature verification on the contract information to be verified, carries out contract information verification on the contract information to be verified according to the contract information of the contract under the chain, and determines that the contract under the chain is executed by the private computation node under the chain in the trusted execution environment under the chain when the data user initiates calling on the contract under the chain through the prompter mechanism under the condition that the signature verification and the contract information verification are passed.

11. The method of claim 10, the data consumer obtaining a remote attestation report for the under-chain trusted execution environment, comprising:

the data using direction 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,

12. The method of claim 10, the data consumer verifying the under-chain trusted execution environment from the remote attestation report, comprising:

13. The method of claim 10, further comprising:

the data user 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 of the down-link privacy computing node;

14. The method of claim 10, the data consumer verifying the under-chain trusted execution environment from the remote attestation report, 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 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;

15. The method of claim 1, the invocation request being encrypted by the data consumer using an identity public key of the private, linked computing node, the trusted execution environment having maintained therein an identity private key corresponding to the identity public key, the invocation request being decrypted by the private, linked computing node within the trusted execution environment using the identity private key.

16. The method according to any one of claims 13 to 15, wherein the identity private key of the down-link privacy computing node is a node identity private key in the node identity keys of the down-link privacy computing node, and the identity public key of the down-link privacy computing node is a node identity public key in the node identity keys; during the process that a block link node interacts with the offline privacy computation node to deploy or invoke an offline contract, the node identity key is used for encrypting and decrypting interaction data and/or verifying signature and signature; alternatively, the first and second electrodes may be,

17. A method of invoking a contract, comprising:

18. The method of claim 17, the down-link privacy computing node receiving a call request submitted by a data consumer through a prolog mechanism of a blockchain for a down-link contract deployed by the down-link privacy computing node, comprising:

the private calculation node under the chain receives the call request forwarded by the block chain node through the prediction machine mechanism, and the call request is submitted to the block chain node by the data user; alternatively, the first and second electrodes may be,

19. The method of claim 17, the down-link privacy computing node determining that the data owner granted the usage rights to the data consumer if all of the following check operations pass:

20. The method of claim 19, wherein the first and second portions are selected from the group consisting of,

21. The method of claim 20, the down-link privacy computing node determining the de-centralization identity of the actual issuer and the de-centralization identity of the actual issuer, comprising:

22. The method of claim 17, the invocation condition further comprising an invocation rule defined by the verifiable statement that a calling operation indicated by the invocation request conforms to.

23. The method of claim 22, the invocation rule including at least one of:

24. The method of claim 18, the target ciphertext data to be encrypted by the data owner using a contract identity public key of the contract under the chain, a contract identity private key corresponding to the contract identity public key being maintained within the trusted execution environment under the chain, the target ciphertext data to be decrypted by the private computing node under the chain within the trusted execution environment under the chain using the contract identity private key.

25. The method of claim 18, further comprising:

26. The method of claim 18, prior to receiving the invocation request, the method further comprising:

the method comprises the steps that a chain down privacy computing node provides a remote attestation report aiming at a chain down trusted execution environment to a data user, and the remote attestation report is generated after an authentication server verifies self-recommendation information generated by the chain down privacy computing node aiming at the chain down trusted execution environment;

27. The method of claim 26, the downlinked private computing node providing a remote attestation report for the downlinked trusted execution environment to a data consumer, comprising:

receiving a challenge issued by the data consumer to the down-link privacy computing node, and returning the remote attestation report to the data consumer; alternatively, the first and second electrodes may be,

28. The method of claim 26, the self-referral information carried by the remote attestation report including a first hash to be verified within, the first hash to be verified being a hash of preset information of the trusted execution environment under the chain, the first hash to be verified being used for the data consumer to compare with a first standard hash value previously obtained for the trusted execution environment under the chain if the remote attestation report is signature verified and signature verified according to a public key of the authentication server and the remote attestation report includes a remote authentication result that is authenticated, and the comparison result is consistent as a precondition for the data consumer to confirm that the trusted execution environment under the chain is trusted.

29. The method of claim 26, further comprising:

the data user provides the data user with first identity information, the first identity information comprises an identity public key of the data user and other identity information of the data user, and the first identity information is subjected to hash calculation by the data user to obtain a second hash value to be verified;

30. The method of claim 26, further comprising:

the private computing node under the chain provides second identity information of the private computing node under the chain to the data user, the second identity information comprises an identity public key of the private computing node under the chain, other identity information of the private computing node under the chain 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 trusted execution environment under the chain;

31. The method of claim 17, an identity private key corresponding to the identity public key is maintained within the linked trusted execution environment; the method further comprises the following steps:

32. The method according to any of claims 29-31, wherein the identity private key of the down-link privacy computing node is a node identity private key in the node identity keys of the down-link privacy computing node, and the identity public key of the down-link privacy computing node is a node identity public key in the node identity keys; during the process that a block link node interacts with the offline privacy computation node to deploy or invoke an offline contract, the node identity key is used for encrypting and decrypting interaction data and/or verifying signature and signature; alternatively, the first and second electrodes may be,

33. A method of invoking a contract, comprising:

34. The method of claim 33, the privacy computing node determining that the data owner has granted the usage rights to the data consumer if all of the following verification operations pass:

35. The method of claim 34, wherein said step of selecting said target,

36. The method of claim 35, determining the de-centralized identity of the actual issuer and the de-centralized identity of the actual issuer by:

37. The method of claim 33, the invocation condition further comprising an invocation rule defined by the verifiable statement that a calling operation indicated by the invocation request conforms to.

38. The method of claim 37, the invocation rule including at least one of:

39. The method of claim 33, prior to submitting the call request, the method further comprising:

the data user acquires a remote attestation report aiming at the trusted execution environment, wherein the remote attestation report is generated by an authentication server after verifying self-recommendation information generated by the private computing node aiming at the trusted execution environment;

40. The method of claim 39, the data consumer verifying the trusted execution environment from the remote attestation report, comprising:

41. The method of claim 39, further comprising:

42. The method of claim 39, the data consumer verifying the trusted execution environment from the remote attestation report, comprising:

43. A method of invoking a contract, comprising:

44. The method of claim 43, the privacy computing node determining that the data owner has granted the usage rights to the data consumer if all of the following checking operations pass:

45. The method of claim 44, wherein said step of selecting said target,

46. The method of claim 45, the privacy computing node determining a decentralized identity identifier of the actual issuer and a decentralized identity identifier of the actual issuer comprising:

47. The method of claim 43, the invocation condition further comprising an invocation rule indicated by said invocation request conforming to said verifiable statement definition.

48. The method of claim 47, the invocation rule including at least one of:

49. The method of claim 43, prior to receiving the invocation request, further comprising:

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

50. The method of claim 49, the self-referral information carried by the remote attestation report including a first hash to be verified within, the first hash to be verified being a hash of preset information of the trusted execution environment, the first hash to be verified being used for the data consumer to compare with a first standard hash previously obtained 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 the remote attestation report includes a remote authentication result that is authenticated, and the comparison result is consistent as a precondition for the data consumer to confirm that the trusted execution environment is trusted.

51. The method of claim 49, further comprising:

52. The method of claim 49, further comprising:

53. An apparatus for invoking a contract, comprising:

54. An apparatus for invoking a contract, comprising:

55. An apparatus for invoking a contract, comprising:

56. An apparatus for invoking a contract, comprising:

and the execution unit enables the privacy computing node to execute the intelligent contract in the trusted execution environment created by the privacy computing node to process the target plaintext data under the condition that a calling condition is met, wherein the calling condition comprises that the data owner of the target plaintext data is determined to grant the use right to the data user according to the verifiable statement.

57. 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-52 by executing the executable instructions.

58. 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 52.