WO2021184973A1 - 访问外部数据的方法及装置 - Google Patents
访问外部数据的方法及装置 Download PDFInfo
- Publication number
- WO2021184973A1 WO2021184973A1 PCT/CN2021/074240 CN2021074240W WO2021184973A1 WO 2021184973 A1 WO2021184973 A1 WO 2021184973A1 CN 2021074240 W CN2021074240 W CN 2021074240W WO 2021184973 A1 WO2021184973 A1 WO 2021184973A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- oracle
- node
- external data
- chain
- computing node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Definitions
- One or more embodiments of this specification relate to the field of verifiable computing technology, and in particular, to a method and device for accessing external data.
- TEE Trusted Execution Environment
- TEE can play the role of a black box in the hardware. Neither the code executed in the TEE nor the data operating system layer can be peeped, and only the pre-defined interface in the code can operate on it.
- plaintext data is calculated in TEE instead of complex cryptographic operations in homomorphic encryption, and there is no loss in the efficiency of the calculation process.
- one or more embodiments of this specification provide a method and device for accessing external data.
- a method for accessing external data including: off-chain private computing nodes execute off-chain contracts called by blockchain nodes in an off-chain trusted execution environment
- an external data access request is generated in the off-chain trusted execution environment, and the external data access request is encrypted and transmitted to the oracle
- the chain The lower privacy computing node receives the external data request response encrypted by the oracle machine, and the external data request response is generated and encrypted by the oracle machine in the trusted execution environment of the oracle machine according to the access result to the remote server
- the chain The lower privacy computing node decrypts in the off-chain trusted execution environment to obtain the external data request response, and completes the execution operation of the off-chain contract according to the external data request response.
- a method for accessing external data includes: an oracle receiving an external data access request encrypted and transmitted by a private computing node under the chain, and the external data access request
- the off-chain private computing node is initiated in response to the external data access demand of the off-chain contract; when the off-chain contract is called by the blockchain node, the off-chain private computing node is in the off-chain trusted execution environment Internal execution; the oracle machine decrypts the external data access request in the oracle trusted execution environment, and accesses the remote server according to the external data access request; the oracle machine is in the oracle trusted execution environment according to the access result
- the external data request response is created internally and encrypted, and the encrypted external data request response is returned to the off-chain privacy computing node; the external data request response is used to participate in the chain after being decrypted in the off-chain trusted execution environment The execution operation of the next contract.
- a method for accessing external data which includes: a control node in an oracle cluster receives an external data access request encrypted and transmitted by a private computing node under the chain, and the external The data access request is initiated by the off-chain privacy computing node in the off-chain trusted execution environment in the process of executing the off-chain contract called by the blockchain node in response to the external data access demand of the off-chain contract;
- the control node decrypts the external data access request in the trusted execution environment of the control node, and forwards the external data access request to the selected oracle node in the cluster, and the external data access request is used to instruct the selected oracle node
- the oracle node accesses the remote server; the control node receives the external data request response returned by the selected oracle node according to the access result, and encrypts the external data request response in the trusted execution environment of the control node Then, the encrypted external data request response is returned to the off-chain privacy
- a method for accessing external data includes: a private computing node executes a smart contract in a trusted execution environment of a node, and executes a trusted execution on the node.
- An external data access request is generated in the environment, and the external data access request is encrypted and transmitted to the oracle; the privacy computing node receives the external data request response encrypted and returned by the oracle, and the external data request response is determined by the oracle.
- the computer generates and encrypts in the trusted execution environment of the oracle machine according to the access result to the remote server; the private computing node decrypts in the trusted execution environment of the node to obtain the external data request response, and responds according to the external data request Complete the execution of the smart contract.
- a method for accessing external data including: an oracle receives an external data access request encrypted and transmitted by a privacy computing node, and the external data access request is determined by the privacy computing node.
- the computing node initiates the process of executing the smart contract in the trusted execution environment of the node; the oracle decrypts in the trusted execution environment of the oracle to obtain the external data access request, and accesses the remote server according to the external data access request; The oracle machine creates an external data request response in the trusted execution environment of the oracle machine according to the access result and encrypts it, and returns the encrypted external data request response to the privacy computing node; the external data request response is used to log on the node Participate in the execution of the smart contract after decryption in the trusted execution environment.
- a method for accessing external data including: a control node in an oracle cluster receives an external data access request encrypted and transmitted by a private computing node, and the external data access The request is initiated by the privacy computing node in the process of executing the smart contract in the trusted execution environment of the node; the control node decrypts in the trusted execution environment of the control node to obtain the external data access request, and sends it to the selected group in the cluster
- the oracle node forwards the external data access request, and the external data access request is used to instruct the selected oracle node to access a remote server; the control node receives the data returned by the selected oracle node according to the access result External data request response, and after the external data request response is encrypted in the trusted execution environment of the control node, the encrypted external data request response is returned to the privacy computing node.
- a device for accessing external data including: a request unit, which enables the off-chain private computing node to execute in the off-chain trusted execution environment and be called by the blockchain node
- a request unit which enables the off-chain private computing node to execute in the off-chain trusted execution environment and be called by the blockchain node
- an external data access request is generated in the off-chain trusted execution environment, and the external data access request is encrypted and transmitted to the oracle Response unit, enabling the off-chain privacy computing node to receive the external data request response encrypted by the oracle machine, and the external data request response is determined by the oracle machine in the trusted execution environment of the oracle machine according to the access result to the remote server
- the feedback unit enables the off-chain private computing node to decrypt in the off-chain trusted execution environment to obtain the external data request response, and complete the execution of the off-chain contract according to the external data request response .
- an apparatus for accessing external data including: a receiving unit, which enables the oracle to receive an external data access request encrypted and transmitted by a private computing node under the chain.
- the access request is initiated by the off-chain privacy computing node in response to the external data access demand of the off-chain contract; when the off-chain contract is called by the blockchain node, the off-chain private computing node will be in the off-chain Execute in a trusted execution environment; an access unit to enable the oracle to decrypt the external data access request in the oracle trusted execution environment, and to access the remote server according to the external data access request; a return unit to enable the The oracle machine creates an external data request response in the trusted execution environment of the oracle machine according to the access result and encrypts it, and returns the encrypted external data request response to the off-chain privacy computing node; the external data request response is used to log on the chain Participate in the execution of the off-chain contract after decryption
- a device for accessing external data including: a request receiving unit to enable the control node in the oracle cluster to receive the external data access encrypted and transmitted by the private computing node under the chain Request, the external data access request is in response to the external data access of the off-chain contract when the off-chain privacy computing node executes the off-chain contract called by the blockchain node in the off-chain trusted execution environment Initiated upon demand; a request forwarding unit that enables the control node to decrypt the external data access request in the trusted execution environment of the control node, and forward the external data access request to the selected oracle node in the cluster, the The external data access request is used to instruct the selected oracle node to access the remote server; the result return unit enables the control node to receive the external data request response returned by the selected oracle node according to the access result, and control After encrypting the external data request response in the trusted execution environment of the node, the encrypted external data request response
- an apparatus for accessing external data including: a request unit to enable a private computing node to execute a smart contract in a trusted execution environment of the node, in the process of Generate an external data access request in the trusted execution environment of the node, and encrypt and transmit the external data access request to the oracle; the response unit enables the privacy computing node to receive the external data request response encrypted and returned by the oracle, the The external data request response is generated and encrypted by the oracle machine in the trusted execution environment of the oracle machine according to the access result to the remote server; the feedback unit enables the private computing node to decrypt and obtain the data in the trusted execution environment of the node.
- the external data request response is to complete the execution operation of the smart contract according to the external data request response.
- an apparatus for accessing external data including: a receiving unit that enables the oracle to receive an external data access request encrypted and transmitted by a privacy computing node, and the external data access The request is initiated by the private computing node in the process of executing the smart contract in the trusted execution environment of the node; the access unit enables the oracle to decrypt the external data access request in the trusted execution environment of the oracle, and to obtain the external data access request according to the The external data access request accesses the remote server; a return unit that enables the oracle to create an external data request response in the oracle trusted execution environment according to the access result and encrypt it, and return the encrypted external data request response to the privacy computing node The external data request response is used to participate in the execution of the smart contract after being decrypted in the trusted execution environment of the node.
- an apparatus for accessing external data including: a request receiving unit to enable the control node in the oracle cluster to receive the external data access request encrypted and transmitted by the privacy computing node ,
- the external data access request is initiated by the privacy computing node in the process of executing the smart contract in the trusted execution environment of the node;
- the request forwarding unit enables the control node to decrypt the external data in the trusted execution environment of the control node Data access request, and forward the external data access request to the selected oracle node in the cluster, the external data access request is used to instruct the selected oracle node to access the remote server;
- the result return unit makes the The control node receives the external data request response returned by the selected oracle node according to the access result, and after encrypting the external data request response in the trusted execution environment of the control node, it returns the encrypted external data request response The privacy computing node.
- an electronic device including: a processor; a memory for storing executable instructions of the processor; wherein the processor runs the executable Instructions to implement the method described in the first, second, third, fourth, fifth, or sixth aspect.
- a computer-readable storage medium is provided with computer instructions stored thereon.
- the instructions are executed by a processor, the first aspect, the second aspect, and the first aspect are implemented.
- Fig. 1 is a flowchart of a method for accessing external data on the side of an off-chain privacy computing node shown in an exemplary embodiment of the present specification.
- Fig. 2 is a flowchart of accessing external data in the process of invoking an off-chain contract by a blockchain node according to an exemplary embodiment of this specification.
- Fig. 3 is a flowchart of a method for accessing external data on the oracle side according to an exemplary embodiment of the present specification.
- Fig. 4 is a flowchart of a method for an oracle to control node-side access to external data according to an exemplary embodiment of this specification.
- Fig. 5 is a flowchart of a method for accessing external data on the side of a private computing node shown in an exemplary embodiment of the present specification.
- Fig. 6 is a flowchart of another method for accessing external data on the oracle side according to an exemplary embodiment of the present specification.
- Fig. 7 is a flowchart of another method for an oracle to control node-side access to external data shown in an exemplary embodiment of the present specification.
- Fig. 8 is a schematic diagram of accessing external data based on a single oracle node according to an exemplary embodiment of the present specification.
- Fig. 9 is an interaction diagram showing a method for accessing external data based on a single oracle node according to an exemplary embodiment of the present specification.
- Fig. 10 is a flowchart of remote certification for a single oracle node according to an exemplary embodiment of the present specification.
- Fig. 11 is a schematic diagram of accessing external data based on an oracle cluster according to an exemplary embodiment of the present specification.
- Fig. 12 is an interaction diagram showing a method for accessing external data based on an oracle cluster according to an exemplary embodiment of the present specification.
- Fig. 13 is a flowchart of remote attestation performed by oracle nodes in an oracle cluster according to an exemplary embodiment of the present specification.
- Fig. 14 is a schematic structural diagram of an electronic device shown in an exemplary embodiment of this specification.
- Fig. 15 is a block diagram of a device for accessing external data on the side of an off-chain privacy computing node shown in an exemplary embodiment of the present specification.
- Fig. 16 is a block diagram of a device for accessing external data on the oracle side according to an exemplary embodiment of this specification.
- Fig. 17 is a block diagram of a device for accessing external data on the node side of an oracle machine according to an exemplary embodiment of the present specification.
- Fig. 18 is a block diagram of an apparatus for accessing external data on the side of a privacy computing node shown in an exemplary embodiment of the present specification.
- Fig. 19 is a block diagram showing another device for accessing external data on the oracle side according to an exemplary embodiment of the present specification.
- Fig. 20 is a block diagram of another device for accessing external data on the node side of an oracle machine according to an exemplary embodiment of the present specification.
- the steps of the corresponding method may not be executed in the order shown and described in this specification.
- the method may include more or fewer steps than described in this specification.
- a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. describe.
- Block chains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
- the public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks, etc., and each participant (ie, node) can freely join and Exit the network.
- the private chain is the opposite.
- the network's data write permission is controlled by an organization or institution, and the data read permission is regulated by the organization; in simple terms, the private chain can be a weakly centralized system with strict restrictions and few participating nodes.
- consortium chain is a block chain between public chain and private chain, which can realize "partial decentralization".
- Each node in the alliance chain usually has a corresponding entity or organization, and participants are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain.
- blockchain nodes can create a TEE and realize the TEE as a secure execution environment for blockchain transactions.
- TEE is a secure extension based on CPU hardware and a trusted execution environment that is completely isolated from the outside.
- TEE was originally a concept proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications. At present, the industry is very concerned about TEE solutions.
- TEE solutions such as TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions) in hardware. , Software Protection Extension), ARM Trustzone (trust zone) and AMD PSP (Platform Security Processor, platform security processor), etc.
- Blockchain nodes can create enclaves (enclaves or enclaves) based on SGX technology to serve as TEEs for executing blockchain transactions.
- the blockchain node uses the newly added processor instructions in the CPU to allocate a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) in the memory to reside in the above-mentioned enclave.
- the memory area corresponding to the above EPC is encrypted by the memory encryption engine MEE (Memory Encryption Engine) inside the CPU.
- MEE Memory Encryption Engine
- the content in the memory area can only be decrypted in the CPU core and used for encryption and decryption.
- the key is only generated and stored in the CPU when the EPC is started.
- the security boundary of the enclave only includes itself and the CPU, and neither privileged or non-privileged software can access the enclave, even the operating system administrator and VMM (virtual machine monitor, or Hypervisor).
- VMM virtual machine monitor, or Hypervisor
- Every blockchain transaction on the blockchain needs to be executed on all blockchain nodes in the blockchain network to ensure that each blockchain node is maintained
- the blockchain ledger data is consistent. If the transaction logic is relatively simple, such as Bitcoin as an example, the blockchain transaction is only used to realize the transfer operation. At this time, even if the blockchain transaction needs to be executed on all blockchain nodes, it will not cause excessive resource consumption. . However, if the blockchain provides the function of a smart contract, and the blockchain transaction calls the smart contract, then the situation may be quite different.
- a smart contract on the blockchain is a contract that can be triggered by a transaction to execute on the blockchain system, and the smart contract can be defined in the form of code.
- EVM Ethereum Virtual Machine
- Every Ethereum node can run EVM.
- EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it.
- Users who publish and call smart contracts in Ethereum run on the EVM.
- virtual machine code virtual machine bytecode, hereinafter referred to as "bytecode"
- the smart contract is divided into two stages: deployment and invocation.
- the user sends a transaction containing information about creating a smart contract to the Ethereum network.
- the data field of the transaction contains the code (such as bytecode) of the smart contract, and the to field of the transaction is empty.
- Each node in the Ethereum network executes this transaction through the EVM and generates a corresponding contract instance.
- the smart contract corresponding to the above transaction is successfully created, and a contract account corresponding to the smart contract appears on the blockchain.
- the contract account has a specific contract address and contract code (i.e., smart contract).
- the code) or the hash value of the contract code is stored in the contract account, and the contract code is used to control the behavior of the corresponding smart contract.
- the user (which can be the same or different from the user who deployed the smart contract) sends a transaction for invoking the smart contract to the Ethereum network.
- the from field of the transaction is the address of the external account corresponding to the user, and the to field is The contract address of the smart contract to be called.
- the data field contains the method and parameters for calling the smart contract.
- EVM is a Turing complete virtual machine; similarly, other blockchains can also use other types of virtual machines, such as WASM (WebAssembly) virtual machines.
- WASM WebAssembly
- the process of executing the code of the smart contract by the node through the virtual machine consumes relatively more computing resources, and because all nodes in the blockchain network need The code that executes the smart contract, so as the number of nodes increases, the consumption of computing resources will increase exponentially. Therefore, although the combination of TEE technology can relatively reduce the resource consumption of a single blockchain node and speed up transaction execution efficiency, it will still cause great resource consumption and waste for the entire blockchain network.
- this manual proposes to deploy private computing nodes (ie, off-chain private computing nodes) under the chain, which can transfer the computing operations that originally needed to be performed on all blockchain nodes to the off-chain private computing nodes for execution.
- the chain node only needs to obtain the calculation result from the off-chain private computing node and update the blockchain ledger data based on the calculation result, and can prove that the above calculation result is indeed in a credible execution based on the verifiable computation (Verifiable Computation) technology
- the environment is executed as expected, which greatly reduces the resource consumption on the chain while ensuring reliability.
- the blockchain node can execute the code of the smart contract to achieve corresponding computing requirements; similarly, the code for performing computing tasks can be deployed off-chain
- the off-chain private computing node can execute code to achieve corresponding computing requirements.
- the contract deployed on the blockchain node is called the on-chain contract
- the contract deployed on the off-chain privacy computing node is called the off-chain contract; of course, whether it is an on-chain contract or an off-chain contract, Its essence is a piece of code that can be executed in a virtual machine.
- the external data here is different from the data on the chain, and the external data does not include the data maintained by the off-chain private computing node. Therefore, this manual provides an access plan for external data so that the off-chain privacy computing system nodes can securely and reliably obtain external data.
- Fig. 1 is a flowchart of a method for accessing external data on the side of an off-chain privacy computing node shown in an exemplary embodiment of the present specification. As shown in Figure 1, the method may include the following steps.
- step 102 in the process of executing the off-chain contract called by the blockchain node in the off-chain trusted execution environment, the off-chain private computing node responds to the external data access requirement of the off-chain contract, and the off-chain can be
- the external data access request is generated in the letter execution environment, and the external data access request is encrypted and transmitted to the oracle.
- the off-chain contract Before invoking the off-chain contract deployed on the off-chain privacy computing node through a call request, the off-chain contract needs to be safely deployed to the off-chain privacy computing node.
- the off-chain contract can be deployed by a certain client.
- the above-mentioned call request may be generated by a blockchain node in response to a transaction initiated by a certain client.
- the client that initiates the transaction and the client that deploys the contract under the chain may be the same client or different clients.
- the client can deploy an off-chain contract to the off-chain private computing node when it is determined that the off-chain private computing node is trustworthy.
- off-chain privacy computing nodes can create off-chain TEEs, and deployment operations and invocation operations for off-chain contracts are implemented through off-chain TEEs, thereby ensuring data security and privacy protection during operations.
- the off-chain TEE created on the off-chain private computing node is similar to the on-chain TEE created on the blockchain node described above, and is based on a trusted execution environment that is completely isolated from the outside and implemented by CPU hardware.
- the client verifies whether the off-chain private computing node is credible by obtaining the remote attestation report for the off-chain TEE created on the off-chain private computing node, specifically whether the off-chain TEE deployed on the off-chain private computing node is credible.
- the remote attestation report is generated from the remote attestation process for the off-chain TEE on the off-chain private computing node.
- the remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the off-chain private computing node, and the self-recommended information is related to the off-chain TEE created on the off-chain private computing node.
- the off-chain private computing node generates the self-recommended information related to the off-chain TEE, and the authentication server verifies the self-recommended information to generate a remote attestation report, so that the remote attestation report can be used to indicate the off-chain TEE on the off-chain private computing node Trustworthy.
- the off-chain TEE is an enclave created on the off-chain private computing node to realize off-chain privacy computing.
- the remote attestation process also involves another special enclave on the off-chain private computing node, namely Quoting enclave (QE for short), QE is an architectural enclave (Architectural Enclave) provided and signed by Intel.
- the above enclave first needs to generate a REPORT structure for local authentication, and QE verifies whether the enclave is on the same platform as itself based on the REPORT structure, and then QE encapsulates the REPORT structure into a structure QUOTE (ie Self-recommended information), and use the EPID (enhanced privacy identification) key to sign.
- the EPID key not only represents the platform of the off-chain private computing node, but also represents the credibility of the underlying hardware of the off-chain private computing node. It can also bind information such as the version of the processor firmware, and only QE can access the EPID key. , To sign the above-mentioned structure QUOTE.
- the above authentication server can be the IAS (Intel Attestation Service) server provided by Intel.
- the off-chain privacy computing node sends the signed structure QUOTE to the IAS server, so that the IAS server can verify the signature and Return the corresponding remote certification report to the off-chain privacy computing node.
- the off-chain privacy computing node After the off-chain privacy computing node creates an off-chain TEE, it generates self-recommendation information for remote certification.
- This self-recommendation information can be used to anchor and solidify the information of the off-chain TEE, so that the final remote certification report containing the self-recommendation information can be obtained. It is used to characterize the state of the TEE under the chain and to verify whether the TEE under the chain is credible.
- the self-recommendation information may include the first hash value to be verified, and the first hash value to be verified is the hash value of the preset information of the off-chain TEE.
- the preset information may include all the deployed in the off-chain TEE.
- the code, the public key of the developer of the TEE under the chain, etc. Taking Intel SGX technology as an example, the hash value generated by all codes deployed in the off-chain TEE is MREnclave, and the hash value generated by the developer’s public key corresponding to the off-chain TEE is MRSigner, which is the first waiting
- the verification hash value can include MREnclave and MRSigner.
- the IAS server performs signature verification based on the maintained public key set, and returns a remote certification report (that is, AVR) to the off-chain privacy computing node.
- Report contains: the structure QUOTE and the signature verification result, and the IAS server uses its own private key to sign the remote attestation report.
- the client can first perform signature verification on the remote attestation report according to the public key of the IAS server. If the verification is passed, it indicates that the remote attestation report is indeed generated by the IAS server and is in the process of data transmission. No data has been tampered with or lost.
- the client can obtain the public key of the IAS server through any means. For example, when a remote attestation report is provided to the client, it can also be associated with the certificate chain that provides the IAS, so that the client can extract the public key of the IAS server from the certificate chain. Then, the client can extract the structure QUOTE and the signature verification result from the remote attestation report. The client can first view the signature verification result.
- the off-chain TEE is established on a reliable hardware platform and can continue to perform other operations. Verification operation: If the signature verification result is that the verification is not passed, the client can determine that the off-chain privacy computing platform is unreliable, and there is no need to continue other verification operations.
- the client can extract the above-mentioned hash values MREnclave and MRSigner from the structure QUOTE, that is, the MREnclave to be verified and the MRSigner to be verified; at the same time, the client obtains the trusted value of the MREnclave and MRSigner of the off-chain TEE in advance, for example, These are the trusted MREnclave and the trusted MRSigner.
- the MREnclave to be tested is compared with the trusted MRSigner, and the MRSigner to be tested is compared with the trusted MRSigner.
- the client can use "the MREnclave to be tested is consistent with the trusted MREnclave, and the MRSigner to be tested is consistent with the trusted MRSigner" as a prerequisite for confirming the trustworthiness of the private computing node under the chain; in other words, if the MREnclave to be tested is inconsistent with the trusted MREnclave , Or if the MRSigner to be verified is inconsistent with the trusted MRSigner, the client determines that the off-chain private computing node is not trusted, and if all the preconditions set by the client are met, it can confirm that the off-chain private computing node is trusted. In addition, there is no inevitable sequence between the operation of the client to verify the signature verification result and the verification of the MREnclave to be verified and the MRSigner to be verified, and the two can be completely independent.
- the client can also verify the credibility of the off-chain private computing node through other preconditions. For example, after an off-chain private computing node creates an off-chain TEE, it can generate a key pair representing its own identity information in the off-chain TEE, and the off-chain private computing node creates its own node identity information in the off-chain TEE.
- the node identity information is related to the above-mentioned key pair corresponding to the identity information.
- the node identity information may include the public key in the key pair.
- the key pair representing the identity information can exist in one or more groups.
- the node identity information may include the signature public key in the signature key pair and the encryption public key in the encryption key pair. In a set of key pairs, corresponding to different encryption algorithms, there may be multiple public keys at the same time, and these public keys are all included in the above-mentioned node identity information.
- the node identity information may also include other information related to the off-chain private computing node, such as software version, domain name, partition name, etc. This specification does not limit this. Then, when the off-chain privacy computing node generates the structure QUOTE, it can calculate the hash value of the node identity information, and add the hash value to the structure QUOTE as the second hash value to be verified.
- the client can perform signature verification from the remote certification report.
- the client can extract the signature verification result and the second to-be-verified hash value contained in the remote certification report, and verify them separately, and there is no inevitable sequence for the verification of the two. They can be completely independent. It is assumed that the client first verifies the signature verification result, and continues to verify the second hash value to be verified if the signature verification result is passed verification. In order to verify the second hash value to be verified, the client needs to obtain the node identity information of the off-chain private computing node.
- the node identity information can be associated and provided, of course, the client can also pass Obtain the node's identity information in other ways or at other times. Then, the client can perform a hash calculation on the obtained node identity information, compare the calculated hash value with the above-mentioned second hash value to be verified, and use the same comparison result as a confirmation that the off-chain privacy computing node is trusted Prerequisites. If the second hash value to be verified is verified, it can be proved that the identity information of the off-chain private computing node is initialized and generated in the off-chain TEE, and the private key in the key pair representing the identity information is only owned by the off-chain private computing node. Owned, and the private computing node under the chain can complete operations such as signing and encrypting communication.
- the above judgment conditions can be selected.
- the first hash value to be verified and the second hash value to be verified can be verified at the same time; or, in some cases, only the second hash value to be verified can be verified, and the first hash value to be verified No verification or partial verification is possible.
- the client can set a trust level, and determine whether to verify or partially verify the first hash value to be verified according to the trust level.
- the trust level is 0, there is no need to verify the first hash value to be verified, and the trust level is 1.
- verifying the MRSigner in the first hash value to be verified and when the trust level is 2, verify the MEnclave in the first hash value to be verified.
- the node identity information includes information related to the identity of the off-chain private computing node, such as a public key representing the identity.
- the node identity information can also include information related to the off-chain TEE.
- the node identity information can also contain the values of MREnclave and MRSigner, so that the hash value to be verified obtained by hashing the identity information of the node can be combined with the off-chain
- the identity of the private computing node is related to the off-chain TEE.
- the client can perform signature verification from the remote certification report.
- the client can extract the signature verification result and the hash value to be verified contained in the remote certification report, and verify them separately, and there is no inevitable sequence for the verification of the two.
- the room can be completely independent.
- the client first verifies the signature verification result, and continues to verify the hash value to be verified if the signature verification result is passed verification.
- the client needs to obtain the node identity information of the off-chain private computing node, which will not be repeated here. Then, the client can perform a hash calculation on the obtained node identity information, compare the calculated hash value with the above-mentioned hash value to be verified, and use the consistency of the comparison result as a prerequisite to confirm the trustworthiness of the off-chain private computing node condition. It can be seen that this embodiment only needs one comparison to realize the verification in the two aspects mentioned above, which helps to improve the verification efficiency.
- the client's verification process of the remote attestation report can also include other operations, such as determining whether the off-chain TEE is running in test mode (there is a risk of data leakage in test mode) based on the content of the remote attestation report, etc., here is no longer one by one Go into details.
- the client can initiate a challenge to the off-chain private computing node and receive the remote certification report returned by the off-chain private computing node, so that it can determine whether the off-chain private computing node is credible based on the remote certification report.
- the client can initiate an off-chain challenge to the off-chain private computing node, that is, the process of initiating the challenge has nothing to do with the blockchain network, so that the consensus process between blockchain nodes can be skipped and the interaction between on-chain and off-chain can be reduced. , So that the client's challenge to the off-chain private computing node has a higher operational efficiency.
- the client can take the form of an on-chain challenge.
- the client can submit a challenge transaction to a blockchain node.
- the challenge information contained in the challenge transaction can be transmitted by the blockchain node to the off-chain private computing node through the oracle mechanism.
- the challenge information is used to initiate a challenge to the off-chain private computing node.
- the oracle mechanism is used to realize the operation of transferring data from the chain to the chain or from the chain to the chain.
- the coordination mechanism between the oracle contract and the oracle server is called the oracle mechanism.
- the on-chain challenge based on the oracle mechanism in the above; and the on-chain call based on the oracle mechanism in the following.
- the transaction submitted by the client to the blockchain node can directly or indirectly call the oracle contract to trigger the oracle mechanism.
- the contract address of the oracle contract is filled in the to field of the transaction, it indicates that the transaction directly calls the oracle contract; if the contract address of a certain chain contract is filled in the to field of the transaction, and the chain is on The contract calls the oracle contract, indicating that the transaction indirectly calls the oracle contract.
- the contract on the chain calls the oracle contract.
- the contract address of the oracle contract is pre-written in the bytecode of the on-chain contract.
- the contract address of the oracle contract can be used as the call. Enter the parameters of the contract on the chain, and fill the entered parameters into the data field of the above transaction.
- the oracle mechanism can also transfer data from off-chain to on-chain.
- the oracle server can transfer the off-chain data to the oracle contract, and then the oracle contract Pass the off-chain data to the data demander.
- the off-chain data here may include the privacy calculation results generated by invoking the off-chain contract.
- transferring data from the chain to the chain can be regarded as a "request” process, and transferring data from the chain to the chain can be regarded as a "response” process. These two processes usually appear in pairs. .
- An off-chain private computing node may belong to an off-chain private computing cluster, and the off-chain private computing cluster includes multiple off-chain private computing nodes. If the privacy computing nodes under each chain are completely independent, then the interaction process between the client and a single privacy computing node under the chain can refer to the above-mentioned embodiments.
- the off-chain privacy computing cluster may include a control node, and the control node will uniformly manage all off-chain privacy computing nodes in the cluster. For example, the client can initiate a challenge to the control node, and receive the remote certification report of the off-chain privacy computing node returned by the control node.
- the client can initiate an off-chain challenge to the control node, or the client can submit a challenge transaction to the blockchain node, and the challenge information contained in the challenge transaction is transmitted by the blockchain node through the oracle mechanism To the control node, the control node returns the remote certification report of the off-chain privacy computing node to the client.
- the off-chain private computing node can temporarily trigger the remote attestation process as described above and generate the corresponding remote attestation report, and then report the remote attestation Feedback to the client. Or, when the off-chain private computing node receives a challenge initiated by the client, if a pre-generated remote attestation report already exists locally, the off-chain private computing node provides the remote attestation report to the client without temporarily triggering remote attestation process. Among them, the remote attestation report of the off-chain private computing node can be triggered by the off-chain private computing node in response to the challenge of other challengers except the client.
- the other challenger may include other clients, This manual does not limit the control node and KMS server in the off-chain privacy computing cluster where the off-chain privacy computing node is located. Therefore, after receiving the challenge initiated by the client, the off-chain private computing node can first check whether there is a previously generated remote attestation report locally, and if there is, the remote attestation report is fed back to the client, otherwise the remote attestation process is temporarily triggered. Among them, the remote attestation report can have a certain time limit, such as 30 minutes or other duration. The timed out remote attestation report can be deemed invalid by the client, and the off-chain privacy computing node can also actively clear the invalid remote attestation report to avoid feedback To the client.
- the client can deploy an off-chain contract to the off-chain private computing node when it is determined that the off-chain private computing node is trustworthy. Similar to the aforementioned challenge process, the client can encrypt and transmit the bytecode of the off-chain contract to the off-chain private computing node through the off-chain channel, or the client can transfer the bytecode of the off-chain contract through the on-chain channel. Encrypted transmission to the off-chain private computing node. For example, the client generates an off-chain contract deployment transaction. The off-chain contract deployment transaction contains the bytecode ciphertext obtained by encrypting the bytecode, and the client encrypts the off-chain contract deployment transaction.
- the encrypted off-chain contract deployment transaction can be decrypted in the on-chain TEE created at the blockchain node to obtain the bytecode ciphertext, and then the blockchain node will use the oracle mechanism to convert The bytecode ciphertext is transmitted to the privacy computing node under the chain.
- the bytecode is encrypted and transmitted to the off-chain private computing node, similar to the aforementioned challenge process, it can be directly encrypted and transmitted to the off-chain private computing node, or it can be forwarded through the control node.
- the off-chain privacy computing node can decrypt the plaintext bytecode in the off-chain TEE, the bytecode can be re-encrypted in the off-chain TEE and stored in the storage space outside the off-chain TEE, such as off-chain privacy In the hard disk of the computing node, the deployment of the off-chain contract is completed.
- the off-chain privacy computing node usually uses a symmetric key to encrypt and store the bytecode through symmetric encryption, so that when the bytecode is subsequently called, it is compared to the form of asymmetric encryption. , The decryption operation can be completed faster.
- the symmetric key can be generated by the off-chain private computing node in the off-chain TEE, or distributed to the off-chain private computing node by other objects through encrypted transmission.
- the KMS server can initiate a challenge to the off-chain private computing node, and in the case of verifying the trustworthiness of the off-chain private computing node through remote certification, the above-mentioned symmetric key is distributed to the off-chain private computing node.
- the off-chain privacy computing node can use the symmetric key distributed by the KMS server as the root key, and apply the derived key derived from the root key to the encrypted storage of the bytecode.
- the above symmetric key can be the RSK (Root Seal Key) key burned in the e-fuses storage circuit in the CPU of the private computing node under the chain, or a derivative derived from the RSK key Key (ie Seal Key).
- RSK Room Seal Key
- the off-chain privacy computing node can also use asymmetric encryption or a combination of symmetric encryption and asymmetric encryption to encrypt and store the bytecode, which is not limited in this specification.
- the blockchain node can call the off-chain contract through the call request as described in the process of executing the transaction initiated by the client to realize the chain Next privacy calculations.
- the process of invoking an off-chain contract can include: Step 1, the client 21 submits a transaction to the blockchain network 22, which can be received and executed by a certain node in the blockchain network, such as node 22n Step 2, the node 22n forms an off-chain contract call request by executing the received transaction; Step 3, the oracle server 23 obtains the call request through the oracle mechanism, and sends it to the off-chain privacy computing node 24.
- the node 22n may perform a consensus on the transaction with other nodes and then upload the transaction on the chain, and deposit the transaction submitted by the client 21. However, if the client 21 does not want its behavior to be arbitrarily known to other users, the transaction can be protected for privacy.
- the client 21 can encrypt the submitted transaction, and the node 22n can receive the encrypted transaction, which can ensure that the content of the transaction will not be leaked during the transmission process.
- the node 22n can deploy the on-chain TEE, and the node 22n can read the encrypted transaction into the on-chain TEE and decrypt it in the on-chain TEE to ensure that the decrypted challenge transaction only exists in the on-chain TEE. Leak out.
- the transaction generated by the client 21 can directly include the encrypted call request, then the node 22n can decrypt the transaction in the on-chain TEE and obtain the ciphertext of the call request, and then the node 22n can transmit the ciphertext of the call request to the oracle mechanism.
- Off-chain privacy computing node the transaction generated by the client 21 may contain a call request in plain text, then the client 21 usually needs to encrypt the transaction and ensure that the node 22n decrypts the call request in the plain text in the on-chain TEE, and then TEE on the chain
- the call request is encrypted inside, and then the encrypted call request is transmitted to the off-chain privacy computing node 24 through the oracle mechanism.
- the transaction generated by the client 21 does not include a call request, and the node 22n actively generates a call request in the on-chain TEE during the process of executing the on-chain contract called by the transaction in the on-chain TEE.
- the call request can include the identification information of the off-chain contract that needs to be called, so that the off-chain private computing node can be accurately called.
- the call request can include the information of the input data, such as the input data itself or the storage address of the input data, etc., so that the off-chain private computing node can execute the off-chain contract through the virtual machine deployed in the off-chain TEE to target the input.
- the storage address of the input data may belong to a remote server, and the off-chain private computing node needs to obtain the input data through the external data access scheme in this specification in order to complete the execution of the off-chain contract.
- an off-chain private computing node executes an off-chain contract to process input data, it may need external data provided by a remote server, and the external data can be obtained through the external data access scheme in this specification.
- the encrypted transmission of the call request can be in the form of symmetric encryption or asymmetric encryption. Encrypted transmission of the call request can ensure that the content of the call request will not be leaked during the transmission process. Assume that the call request is generated and encrypted by the client:
- the client and the off-chain private computing node maintain the same symmetric key.
- the symmetric key can be used by the client and the off-chain private computing node through DH (Diffie-Hellman) or ECDH (Elliptic Curve). Diffie-Hellman) and other algorithms are negotiated or distributed by the KMS (Key Management Service) server to the client and private computing nodes under the link. This manual does not limit the source of the key.
- the KMS server can transmit the key to the client during the process of remote certification of the private computing node under the chain by the client.
- the client can encrypt the call request with the above-mentioned symmetric key, and the off-chain private computing node maintains the symmetric key in the off-chain TEE, so the off-chain private computing node accepts the call transmitted by the blockchain node Request, the off-chain privacy computing node reads the encrypted invocation request into the off-chain TEE, and executes the decryption operation through the symmetric key to obtain the above-mentioned invocation request, and performs related calculations.
- the encryption algorithm used by the symmetric encryption may include, for example, the DES algorithm, the 3DES algorithm, the TDEA algorithm, the Blowfish algorithm, the RC5 algorithm, and the IDEA algorithm.
- the off-chain private computing node When using asymmetric encryption, the off-chain private computing node maintains the private key of the node's asymmetric key, such as the off-chain node private key, and the client can obtain the off-chain node public key of the off-chain private computing node .
- the asymmetric key can be generated by the off-chain private computing node in the off-chain TEE, or distributed by the KMS server to the off-chain private computing node. This specification does not limit the source of the key.
- the KMS server can transmit the public key of the off-chain node to the client during the process of remote certification of the off-chain private computing node by the client.
- the client can encrypt the call request with the off-chain node public key, and the off-chain private computing node maintains the off-chain node private key in the off-chain TEE, thus reading the encrypted call request into the off-chain TEE. And perform the decryption operation through the private key of the node under the chain to obtain the above-mentioned call request.
- the asymmetric encryption algorithm used in the asymmetric encryption may include, for example, RSA, Elgamal, knapsack algorithm, Rabin, D-H, ECC (elliptic curve encryption algorithm), etc.
- a combination of symmetric encryption and asymmetric encryption can also be used.
- the client can maintain a symmetric key.
- the symmetric key can be randomly generated by the client, and the client can obtain the public key in the node asymmetric key.
- the client can encrypt the call request with a symmetric key, obtain the encrypted call request, and encrypt the symmetric key with an asymmetric key to obtain the encrypted key, and then the client can simultaneously encrypt the challenge transaction and the encrypted secret.
- the key is transmitted to the private computing node under the chain.
- the off-chain privacy computing node reads the encrypted call request and the encrypted key into the off-chain TEE, first decrypts the encrypted key with the off-chain node’s private key to obtain the symmetric key, and then passes the symmetric key Decrypt the encrypted call request.
- the encryption and decryption efficiency of symmetric encryption is relatively higher, but the security is relatively low, while the encryption and decryption efficiency of asymmetric encryption is relatively low, but the security is relatively higher. Therefore, based on the comparison between symmetric encryption and asymmetric encryption The combined form can take into account the efficiency and security of encryption and decryption.
- the data sender and the data receiver maintain the same symmetric key, or the data sender maintains the public key with the asymmetric key, and the data receiver
- the party maintains a private key with an asymmetric key, or a combination of symmetric encryption and asymmetric encryption can realize data encrypted transmission between any data sender and data receiver, which will not be repeated here.
- An off-chain private computing node may belong to an off-chain private computing cluster, and the off-chain private computing cluster includes multiple off-chain private computing nodes. If the privacy computing nodes under each chain are completely independent, then the interaction process between the client and a single privacy computing node under the chain can refer to the above-mentioned embodiments.
- the off-chain privacy computing cluster can include a control node, and the control node will uniformly manage all off-chain privacy computing nodes in the cluster. For example, the client can send a call request to the control node, and receive the off-chain privacy calculation result of the off-chain privacy computing node returned by the control node.
- off-chain private computing nodes belong to off-chain private computing clusters
- these off-chain private computing nodes can generate unified identity information, such as cluster identity information.
- the cluster identity information may include a cluster encryption key pair and a cluster signature key pair.
- Each of the above-mentioned privacy computing nodes under the chain needs to maintain the cluster encryption private key and the cluster signature private key in their respective chain TEEs. Then, as long as the client or blockchain node encrypts the call request with the cluster encryption public key, it can ensure that each of the above-mentioned off-chain private computing nodes can decrypt with the cluster-encrypted private key in their respective off-chain TEE, thereby calling ask.
- the client does not need to pay attention to whether the other party is a single off-chain private computing node or off-chain private computing cluster. It only needs to use it as an object and interact with the object, without paying attention to the nodes or clusters behind it. detail.
- contract identities can be generated for off-chain contracts deployed on off-chain private computing nodes.
- each off-chain privacy computing node can establish a contract identity for its deployed off-chain contract, and the contract identities generated by different off-chain privacy computing nodes for the same off-chain contract are the same .
- off-chain privacy computing nodes can generate corresponding contract identities for off-chain contracts based on the unified cluster identity and the contract ID of the off-chain contract.
- the contract identity can be defined by the contract identity key pair.
- the contract identity can include a contract encryption key pair and a contract signature key pair.
- the contract encryption public key can also be used to encrypt the information of the input parameter data contained in the call request.
- the off-chain privacy computing node can sign the call result through the contract signature private key of the called off-chain contract, and the client or blockchain node can verify the signature through the contract signature public key. Therefore, it is determined that the call result is indeed generated by the called off-chain contract.
- the off-chain TEE created by the off-chain privacy computing node is isolated from the outside.
- the off-chain TEE executes the off-chain contract
- the off-chain TEE cannot directly achieve external access to obtain the required external data. Therefore, in this specification, an oracle can be used to assist the off-chain TEE, so that the off-chain TEE can obtain the required external data under the premise of ensuring security.
- the off-chain privacy computing node 24 executes the off-chain contract, if there is an external data access request, it can create an external data access request through step 4 and send it to the oracle 25 to trigger the oracle 25 to pair The remote server accesses it and returns the corresponding external data request response.
- External data access interfaces can be defined in the bytecode of the off-chain contract.
- the off-chain privacy computing node executes the off-chain contract in the off-chain TEE, it can generate a corresponding external data access request by calling the external data access interface.
- An off-chain contract can contain multiple functions, and not every function must call an external data access interface. At the same time, even if a function can call the external data access interface, it is not necessarily called every time it is executed.
- the above call request can include an input parameter indicating whether to call the external data access interface. The value of the input parameter determines whether to call the external data access interface.
- the off-chain private computing node can restrict the access behavior of external data access requests. For example, you can write the IP addresses that are allowed to be accessed into a preset whitelist, and match the IP addresses of the target visitors of the external data access request with the whitelist, so that only the IP addresses recorded for the whitelist are allowed Access; similarly, you can also write IP addresses that are not allowed to be accessed into the preset blacklist, and match the IP address of the target access object of the external data access request with the blacklist, thereby prohibiting the blacklist Record the IP address for access.
- the field restriction and content restriction of the external data access request can be recorded in the configuration file, so as to prevent the external data access request from including sensitive fields or sensitive content.
- the fields in the external data access request can be checked. It is detected that there are fields or request content that do not meet the access requirements in the external data access request, or the destination IP address is not in the preset blank. In the case of a list, it is forbidden to perform operations to access external data.
- the data format supported by the off-chain private computing node and the oracle may be different.
- the external data access request generated by the off-chain private computing node may not be successfully recognized by the oracle, which will cause the failure of external data access. Therefore, after the off-chain private computing node executes the off-chain contract to generate the external data access request in the first format, it can actively convert the external data access request in the first format into the second format, and this step is encrypted and transmitted to the oracle. It is an external data access request converted into the second format.
- the off-chain privacy computing node can actively convert the external data request response in the second format into the first format, and then respond to the external data request in the first format Be dealt with.
- the process of the off-chain private computing node sending an external data access request to the oracle, or the process of the oracle returning an external data request response to the off-chain private computing node involves data interaction between devices.
- the external data access request and the external data request response can be encrypted and transmitted separately through symmetric encryption, asymmetric encryption, or a combination of the two.
- the off-chain TEE is created at the off-chain privacy computing node, and the oracle TEE is created at the oracle, which can ensure that the encryption and decryption operations of the external data access request and the external data request response are implemented in the TEE, so it can be in the data All aspects of the interaction ensure extremely high security.
- the oracle can be a single oracle node, or it can be an oracle cluster containing multiple oracle nodes.
- the oracle cluster includes a control node and oracle nodes other than the control node.
- the public key used by the off-chain privacy computing node for encryption can be the oracle encryption public key, and the corresponding prediction
- the machine encryption private key can be held by the aforementioned single oracle node and represent the identity of the single oracle node, or the oracle encryption private key can be held by or represented by a certain oracle node in the aforementioned oracle cluster.
- the identity of the oracle node, or the oracle encryption private key may be jointly held by all the oracle nodes in the oracle cluster and represent the cluster identity of these oracle nodes, or the oracle encryption private key may be
- the control node in the oracle cluster holds and represents the identity of the control node.
- the off-chain private computing node is based on the encryption public key of the single oracle node in the off-chain TEE
- the external data access request is encrypted, and the encrypted external data access request is sent to the oracle node for decryption by the oracle node based on the maintained oracle encryption private key.
- the off-chain private computing node can directly interact with the oracle node, and the process is the same as that of a single oracle node.
- the off-chain private computing node can select a certain oracle node from the oracle cluster according to its own needs; or, the off-chain private computing node can negotiate with the control node of the oracle cluster to determine which oracle in the cluster.
- the node processes the external data access request, and the off-chain privacy computing node uses the oracle encryption public key corresponding to the oracle node for encryption.
- the off-chain private computing node may first request an oracle node to process this external data access request from the control node when it needs to access external data, and after receiving the request response from the control node , Determine the assigned oracle node based on the information in the response, and encrypt the external data access request based on the oracle encryption public key corresponding to the oracle node.
- the control node may actively send the allocated oracle node to the off-chain privacy computing node.
- control node can determine the performance status of the oracle nodes in the cluster according to the preset period, and use the oracle node with better performance as the oracle node for processing external data access requests in the time period based on the load balancing algorithm, and Actively inform the off-chain privacy computing node of the oracle node's information.
- all external data access requests are encrypted by the oracle encryption public key corresponding to the oracle node, and the control node sends all received external data access requests to the oracle node To process.
- the control node can also determine multiple oracle nodes at the same time.
- the off-chain privacy computing node can select an oracle node from them, and use the oracle encryption public key corresponding to the selected oracle node to perform external data access requests. Encrypted, and the off-chain privacy computing node can inform the control node of the selected oracle node information, such as the oracle encryption public key corresponding to the oracle node or its hash value, or the control node assigned to the oracle node Node ID, etc., so that the control node can accurately forward to the selected oracle node after receiving the external data access request.
- the control node can accurately forward to the selected oracle node after receiving the external data access request.
- the oracle encryption private key can be maintained by the control node of the oracle cluster.
- the encrypted external data access request is sent to the control node, and after being decrypted by the control node, it is forwarded to the oracle node in the oracle cluster for processing, so that the off-chain private computing node does not need Focusing on the number of nodes in the oracle cluster and the identity of each node, etc., the oracle cluster can be interacted as a whole "oracles", which can simplify the interaction process.
- the control node decrypts the external data access request, it can select an oracle node from the oracle cluster randomly or based on a load balancing algorithm, and use the public key corresponding to the identity of the selected oracle node to pair in the TEE
- the external data access request is re-encrypted, and the re-encrypted external data access request is sent to the oracle node, and the oracle node will decrypt and process it in the created oracle TEE according to the private key corresponding to its own identity, And the public-private key pair corresponding to the identity of the oracle node is created in the oracle TEE.
- Step 104 The off-chain privacy computing node receives an external data request response encrypted by the oracle machine, and the external data request response is generated by the oracle machine in the trusted execution environment of the oracle machine according to the access result to the remote server And encrypted.
- the oracle machine accesses the remote server according to the received external data access request to obtain the corresponding access result.
- the access process may include the following steps: step 5, the oracle machine 25 initiates access to the remote server 26 based on the external data access request; step 6, the remote server 26 returns the access result to the oracle machine 25; step 7, prediction The machine 25 creates an external data request response based on the access result, and returns it to the off-chain privacy computing node 24.
- the external data access request can include the target data and the information of the remote server 26, and the oracle 25 can access the remote server 26 and obtain the corresponding target data as the result of the above-mentioned access; or, the external data access request can only include
- the oracle machine 25 can determine the corresponding remote server 26 according to the information of the target data, and access the remote server 26 according to the information of the target data. After receiving the access result returned by the remote server 26, the oracle 25 may create a corresponding external data request response based on the received access result.
- the off-chain private computing node can pre-verify whether the oracle is trustworthy. For example, the oracle TEE created by the oracle can be verified through remote attestation. If the verification is passed, it indicates that the oracle has a reliable hardware platform and software environment to determine the prediction. The machine is credible. On this basis, the off-chain private computing node can store the oracle signature public key locally for the above-mentioned signature verification operation; conversely, if the oracle is verified as untrusted, the off-chain private computing node will not If the oracle signature public key is stored locally, the above verification operation will not be implemented, and the received external data request response will not be used for the subsequent operations of the off-chain contract.
- the oracle TEE created by the oracle can be verified through remote attestation. If the verification is passed, it indicates that the oracle has a reliable hardware platform and software environment to determine the prediction. The machine is credible.
- the off-chain private computing node can store the oracle signature public
- the aforementioned oracle may be a single oracle node, and the off-chain privacy computing node may directly interact with the oracle node to obtain the remote attestation report corresponding to the oracle node.
- the above-mentioned oracle may be an oracle cluster.
- Each oracle node in the oracle cluster creates an oracle TEE, and the off-chain private computing node can obtain the remote attestation report corresponding to all the oracle nodes in the cluster. It is used to verify whether the oracle TEE created by each oracle node is credible. For example, it can be obtained by the control node initiating a challenge to each oracle node.
- control node can initiate a challenge to each oracle node in the cluster, and each oracle node generates self-recommendation information related to the oracle TEE and sends it to the authentication server, so that the authentication server verifies the self-recommendation information and generates a corresponding Remote attestation report, and return the report to the corresponding oracle node, each oracle node forwards the remote attestation report to the control node after receiving the remote attestation report, and the control node forwards the remote attestation report to the off-chain privacy computing node.
- the off-chain private computing node can verify each remote attestation report obtained separately.
- the verification process can refer to the description of the remote attestation process described above. The difference is only the change between the challenger and the challenged party, which will not be repeated here. .
- the remote attestation report if an off-chain private computing node confirms that a certain oracle node is trustworthy, then the off-chain private computing node will locally store the oracle signature public key corresponding to the oracle node; in other words, the off-chain private computing node All the oracle signature public keys corresponding to the oracle nodes that are verified as trusted are stored locally, and the oracle signature public keys corresponding to the oracle nodes that are verified as untrusted are not stored.
- the oracle node can maintain the oracle encryption private key that represents its own identity, and the oracle signature private key is similar to the oracle encryption private key, and is also generated by the oracle node in the oracle TEE created by the oracle node. And can represent the identity of the oracle node.
- the oracle machine can sign the created external data request response based on the oracle machine signature private key.
- the off-chain private computing node can verify the received external data request response based on the pre-obtained oracle signature public key. If the signature verification is successful, it indicates that the received external data request response did come from the oracle, and no abnormal conditions such as data loss occurred during the transmission process, that is, the received external data request response is credible, so the off-chain privacy computing node can If the verification is successful, follow-up operations on the off-chain contract are completed according to the external data request response.
- the off-chain private computing node only maintains locally the oracle signature public key corresponding to the oracle node that is verified to be trusted
- the successful verification can ensure that the oracle node processing the external data access request is pre-verified. Trusted nodes, to avoid impersonation of untrusted oracle nodes, help to improve data security.
- the oracle encryption key pair and the oracle signing key pair can be the same key pair , It can also be a different key pair.
- the public key used is the oracle encryption public key corresponding to the control node in the oracle cluster, then because the external The data request response must be generated by a certain oracle node, so the encryption key pair of the oracle involved and the signature key pair of the oracle must not be the same key pair at this time.
- the oracle When the oracle sends an external data request response to the off-chain privacy computing node, it performs encrypted transmission for the external data request response.
- the encrypted transmission process for external data request responses is similar to the aforementioned encrypted transmission process for call requests.
- the data receivers are all off-chain privacy computing nodes, but the data sender becomes an oracle. Similar to the encrypted transmission process for the call request, when the external data request response is encrypted and transmitted, symmetric encryption, asymmetric encryption, or a digital envelope combining the two can be used.
- the public key of the off-chain node needs to be used, and the corresponding private key of the off-chain node can only be maintained by the off-chain private computing node as the receiver, representing the off-chain node.
- the node identity of the private computing node may also represent the cluster identity of the private off-chain private computing cluster where the off-chain private computing node is located, and is jointly maintained by all off-chain private computing nodes in the cluster.
- Step 106 The off-chain privacy computing node decrypts in the off-chain trusted execution environment to obtain the external data request response, and completes the execution operation of the off-chain contract according to the external data request response.
- the execution result can also be encrypted and fed back to the blockchain node.
- the process may include the following steps: Step 8, the off-chain privacy computing node 24 completes the execution of the off-chain contract based on the external data request response, and feeds back the execution result to the oracle server 23; Step 9, prediction The machine server 23 forwards the execution result to the node 22n in the blockchain network, so that the blockchain node 22n completes the execution of the contract on the chain based on the execution result; step 10, the blockchain node 22n completes the contract on the chain After the operation is executed, the execution result of the contract on the chain is returned to the client 21.
- the off-chain privacy computing node 24 completes the execution of the off-chain contract based on the external data request response, and feeds back the execution result to the oracle server 23
- Step 9 prediction The machine server 23 forwards the execution result to the node 22n in the blockchain network, so that the blockchain node 22n completes the execution of the contract on the chain based on the execution result; step 10, the blockchain
- the oracle server 23 used by the blockchain node 22n to implement off-chain interaction and the oracle 25 used by the off-chain privacy computing node 24 to access external data have different identifiers. This is for convenience Reflects the differences in the interactive objects and interactive data faced by the blockchain node 22n and the off-chain privacy computing node 24, but in fact, the oracle server 23 and the oracle 25 can be physically deployed on the same device. Can be deployed on different devices, this manual does not limit this.
- the technical solution of this specification detects that there is an external data access requirement during the execution of the off-chain contract, it can initiate access to the remote server through the oracle, and then obtain the required external data to complete the off-chain Execution of the contract.
- the off-chain contract By creating an off-chain TEE at the off-chain private computing node, creating an oracle TEE at the oracle, and implementing encrypted data transmission between the off-chain private computing node and the oracle, the off-chain contract, external data access request, The external data request and response are in plaintext state only in the TEE, and are in the ciphertext state outside the TEE, so that while realizing external data access, it can ensure data security and meet the needs of privacy protection.
- this specification also proposes other embodiments on the oracle side, the control node side in the oracle cluster, etc.
- the description involved in the off-chain privacy computing node side embodiment The same can be applied to the embodiments on these sides, which will not be described in detail below.
- FIG. 3 is a flowchart of a method for accessing external data on the oracle side according to an exemplary embodiment of this specification. As shown in Figure 3, the method may include the following steps.
- Step 302 The oracle receives the external data access request encrypted and transmitted by the off-chain private computing node, and the external data access request is initiated by the off-chain private computing node in response to the external data access demand of the off-chain contract;
- a contract is called by a blockchain node, it is executed by the off-chain private computing node in the off-chain trusted execution environment.
- the oracle may be a single oracle node or an oracle cluster containing multiple oracle nodes (including control nodes and oracle nodes other than control nodes).
- the oracle encryption public key used for encryption by the off-chain private computing node can be the encryption public key of a single oracle node or the encryption public key of an oracle node other than the control node in the oracle cluster, or it can be the control node in the oracle cluster The encrypted public key.
- the oracle can receive the external data access request encrypted by the oracle encryption public key in the off-chain TEE by the off-chain private computing node, and decrypt the received external data access request based on the oracle encryption private key.
- the aforementioned oracle encryption public key may be the encryption public key of a single oracle node, or may be the encryption public key of an oracle node other than the control node in the oracle cluster.
- the off-chain private computing node encrypts the external data access request based on the encryption public key of the single oracle node in the off-chain TEE, and The encrypted external data access request is sent to the single oracle node to be decrypted by the single oracle node based on the maintained encrypted private key.
- the off-chain privacy computing node is based on the encryption public key of any oracle node in the off-chain TEE.
- the key encrypts the external data access request, and sends the encrypted external data access request to the control node in the oracle cluster, and the control node forwards the encrypted external data access request to any of the oracle nodes.
- Any oracle node performs decryption based on the maintained encrypted private key.
- the control node in the oracle cluster can receive the external data access request encrypted by the oracle encryption public key in the off-chain TEE by the off-chain private computing node, and maintain the oracle encryption private key based on the control node.
- the encrypted external data access request is decrypted and forwarded to the oracle node in the oracle cluster for processing.
- the oracle encryption public key used by the off-chain privacy computing node to encrypt the external data access request is the encryption public key of the control node; wherein, the encrypted public key is based on the oracle encryption private key maintained by the control node.
- the decrypted external data access request and forwarding it to the oracle node in the oracle cluster for processing may include: decrypting the received external data access request based on the encrypted private key maintained by the control node, and based on any oracle node The encrypted public key of the re-encrypts the external data access request, and forwards the re-encrypted external data access request to any oracle node.
- off-chain private computing nodes and oracles may support different data encoding formats. Therefore, the off-chain privacy computing node can convert the external data access request in the first format into the second format after generating it.
- the external data access request in the second format sent by the off-chain privacy computing node received by the oracle is converted from the external data access request in the first format by the off-chain privacy computing node; and the external data access request in the first format is Generated under the execution of an off-chain contract.
- Step 304 The oracle machine decrypts in the oracle machine trusted execution environment to obtain the external data access request, and accesses the remote server according to the external data access request.
- Step 306 The oracle creates an external data request response in the trusted execution environment of the oracle according to the access result and encrypts it, and returns the encrypted external data request response to the off-chain privacy computing node; the external data request response is used Participate in the execution of the off-chain contract after decryption in the off-chain trusted execution environment.
- the oracle After the oracle creates an external data request response based on the access result, it can also sign the external data request response based on the maintained oracle signature private key to prove the external data request response to the off-chain private computing node Reliability.
- the off-chain private computing node in order to enable the off-chain private computing node to verify the signed external data request response based on the pre-maintained oracle signature public key, it is necessary to obtain the oracle signature public key in advance. To this end, it can also include the process of remote certification of the oracle.
- the oracle signature private key is maintained by the oracle node; the oracle node can return a remote attestation report to the off-chain private computing node; the remote attestation report is verified by the authentication server
- the self-recommendation information generated by the oracle node is generated after verification, and the self-recommendation information is related to the TEE created on the oracle node; in the case that the oracle node is determined to be trustworthy according to the remote attestation report, the oracle signature public key is
- the privacy computing nodes under the chain are stored locally.
- the oracle signature private key is maintained by the oracle node in the cluster that responds to external data access requests; the control node in the oracle cluster returns each prediction in the cluster to the off-chain private computing node
- Each remote certification report is generated by the authentication server after verifying the self-recommendation information generated by the corresponding oracle node, and the self-recommendation information is related to the TEE created on the corresponding oracle node; according to the remote certification
- the oracle signature public key of the trusted oracle node is stored locally by the off-chain private computing node.
- the oracle can use the off-chain node public key to encrypt the created external data request response, and return the encrypted external data request response to the off-chain privacy
- the computing node uses the off-chain private computing node to decrypt the encrypted external data request response based on the off-chain node's private key.
- the off-chain private computing node belongs to the off-chain private computing cluster
- the off-chain node private key is only maintained by the off-chain private computing node, or the off-chain node private key is in the off-chain private computing cluster All off-chain privacy computing nodes are jointly maintained.
- the external data request response created based on the access result also uses the second format; the external data request response in the second format is returned to the off-chain privacy computing node Afterwards, the off-chain private computing node is converted into the external data request response in the first format; the off-chain private computing node can complete the execution operation of the off-chain contract based on the external data request response in the first format.
- FIG. 4 is a flowchart of a method for an oracle to control node access to external data according to an exemplary embodiment of this specification. As shown in Figure 4, the method may include the following steps.
- Step 402 the control node in the oracle cluster receives the external data access request encrypted and transmitted by the off-chain private computing node, and the external data access request is executed by the off-chain private computing node in the trusted execution environment under the chain.
- the off-chain contract invoked by the chain node it is initiated in response to the external data access demand of the off-chain contract.
- the off-chain private computing node encrypts the external data access request based on the encrypted public key of the control node.
- the control node receives the external data access request sent by the off-chain private computing node, the control node TEE The received external data access request is decrypted based on the maintained encryption private key of the control node.
- Step 404 The control node decrypts the external data access request in the trusted execution environment of the control node, and forwards the external data access request to the selected oracle node in the cluster, where the external data access request is used for Instruct the selected oracle node to access the remote server.
- control node After the control node receives the external data access request, it can select a trusted node in the cluster as the oracle node for processing this external data access request (this trusted node is the one selected in this step).
- Oracle node can re-encrypt the external data access request based on the encrypted public key of the trusted node in the control node TEE, and send the re-encrypted external data access request to the trusted node.
- Step 406 The control node receives the external data request response returned by the selected oracle node according to the access result, and encrypts the external data request response in the trusted execution environment of the control node.
- the external data request response is returned to the off-chain privacy computing node.
- the selected oracle node After the selected oracle node receives the re-encrypted external data access request sent by the control node, it can use the encrypted private key maintained by itself in the selected oracle TEE (that is, the trusted node’s Encrypted private key) for decryption; and initiates access to the corresponding remote server based on the decrypted external data access request.
- the encrypted private key maintained by itself in the selected oracle TEE that is, the trusted node’s Encrypted private key
- the selected oracle node can create an external data request response in the TEE based on the access result, and sign it with the signature private key of the selected oracle ; After the signed external data access request is verified by the off-chain privacy computing node based on the pre-obtained oracle public key (that is, the encrypted public key of the selected oracle), it is used to complete the execution of the off-chain contract .
- the off-chain private computing node can obtain the encrypted public key of the selected oracle in a variety of ways.
- the control node may send a remote report certificate to the off-chain private computing node; after the remote attestation report is verified by the off-chain private computing node, the oracle node corresponding to the remote attestation is determined to be a trusted node;
- the public key information of the node is stored locally by the private computing node under the chain.
- the off-chain private computing node may obtain the public key information of all trusted nodes in the oracle cluster in advance.
- control node can send the remote certification report corresponding to all the oracle nodes in the cluster to the off-chain private computing node; the off-chain private computing node verifies the received remote certification report, and corresponds to the remote certification report that is successfully verified
- the oracle node of is determined as a trusted node, and the signature public key information of all trusted nodes is stored locally.
- the remote attestation report of the oracle nodes in the cluster can be received by the control node, and based on the remote attestation report to determine whether the oracle node is a trusted node; after receiving the external data access request sent by the off-chain private computing node
- the control node can allocate a trusted node to process the external data access request based on the principle of load balancing.
- the principle of the technical solution is similar to the above-mentioned embodiment, and the implementation details involved include the creation process of the trusted execution environment by the private computing node, the generation process of the remote certification report by the private computing node, and the verification process of the remote certification report by the client.
- the above embodiments can also be referred to, so the detailed description will not be given below.
- Fig. 5 is a flowchart of a method for accessing external data on the side of a private computing node shown in an exemplary embodiment of the present specification. As shown in Figure 1, the method may include the following steps.
- Step 502 During the process of executing the smart contract in the trusted execution environment of the node, the private computing node generates an external data access request in the trusted execution environment of the node, and encrypts the external data access request to the oracle.
- the smart contract can be deployed by a certain client.
- the above smart contract may be executed in response to a transaction initiated by a certain client.
- the client that initiates the transaction and the client that deploys the smart contract may be the same client or different clients.
- the process of the private computing node sending an external data access request to the oracle machine or the process of the oracle machine returning an external data request response to the private computing node involves data interaction between devices.
- the external data access request and the external data request response can be encrypted and transmitted separately through symmetric encryption, asymmetric encryption or a combination of the two.
- the private computing node can encrypt the external data access request based on the oracle encryption public key in the trusted execution environment of the node, and the encrypted external data
- the data access request is sent to the oracle.
- the oracle may include an oracle node that maintains the oracle encryption private key; or, in the case that the oracle is an oracle cluster, the oracle encryption private key is maintained by the control node of the oracle cluster, and the encrypted private key is maintained by the oracle cluster.
- the external data access request is decrypted by the control node and forwarded to the oracle node in the oracle cluster for processing.
- the data formats supported by the private computing node and the oracle may be different, resulting in the external data access request generated by the private computing node, which may not be successfully recognized by the oracle, resulting in failure to access external data. Therefore, after the privacy computing node executes the smart contract to generate the external data access request in the first format, it can actively convert the external data access request in the first format into the second format, and the encrypted transmission to the oracle in this step is the conversion to External data access request in the second format. Correspondingly, after the oracle returns the external data request response in the second format, the privacy computing node can actively convert the external data request response in the second format into the first format, and then process the external data request response in the first format .
- the private computing node can restrict the access behavior of external data access requests. For example, you can write the IP addresses that are allowed to be accessed into a preset whitelist, and match the IP addresses of the target visitors of the external data access request with the whitelist, so that only the IP addresses recorded for the whitelist are allowed Access; similarly, you can also write IP addresses that are not allowed to be accessed into the preset blacklist, and match the IP address of the target access object of the external data access request with the blacklist, thereby prohibiting the blacklist Record the IP address for access.
- the field restriction and content restriction of the external data access request can be recorded in the configuration file, so as to prevent the external data access request from including sensitive fields or sensitive content.
- the fields in the external data access request can be checked. It is detected that there are fields or request content that do not meet the access requirements in the external data access request, or the destination IP address is not in the preset blank. In the case of a list, it is forbidden to perform operations to access external data.
- Step 504 The privacy computing node receives an external data request response encrypted by the oracle machine, and the external data request response is generated and encrypted by the oracle machine in the trusted execution environment of the oracle machine according to the access result to the remote server. .
- the external data request response is signed by the oracle signature private key; after receiving the external data access request, the privacy computing node can send a signature to the external data based on the pre-obtained oracle signature public key. Data request response is verified. Wherein, the privacy computing node completes the execution operation of the smart contract according to the external data request response when confirming that the signature verification is successful.
- the privacy computing node can also obtain a remote attestation report for the oracle node, The remote attestation report is generated after the authentication server verifies the self-recommendation information generated by the oracle node, and the self-recommendation information is related to the trusted execution environment created on the oracle node; In the case that the oracle node is trusted, the privacy computing node stores the oracle signature public key locally;
- the oracle signature private key is maintained by the oracle node in the cluster that responds to the external data access request; the private computing node can also obtain the data
- the remote attestation report of each oracle node in the cluster, each remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the corresponding oracle node, and the self-recommendation information is related to the trusted execution environment created on the corresponding oracle node
- the privacy computing node determines a trusted oracle node according to the remote certification report, and saves the corresponding oracle signature public key locally.
- the oracle when the oracle sends an external data request response to the privacy computing node, it performs encrypted transmission for the external data request response.
- the encrypted transmission process for external data request responses is similar to the aforementioned encrypted transmission process for call requests.
- the data receivers are all private computing nodes, but the data sender becomes an oracle. Similar to the encrypted transmission process for the call request, when the external data request response is encrypted and transmitted, symmetric encryption, asymmetric encryption, or a digital envelope combining the two can be used.
- the node public key needs to be used, and the corresponding node private key can only be maintained by the private computing node as the receiver, representing the node identity of the private computing node under the chain , Can also represent the cluster identity of the private computing cluster where the private computing node is located, and is jointly maintained by all private computing nodes in the cluster.
- Step 506 The private computing node decrypts in the trusted execution environment of the node to obtain the external data request response, and completes the execution operation of the smart contract according to the external data request response.
- the privacy computing node After the privacy computing node receives the external data access request, it can convert the acquired external data request response in the second format into the external data request response in the first format; the privacy computing node is based on the The external data request response in the first format completes the execution operation of the smart contract.
- this specification also proposes other embodiments on the oracle side, the control node side in the oracle cluster, etc.
- the description involved in the embodiment on the privacy computing node side can also be applied to The embodiments on these sides will not be described in detail below.
- FIG. 6 is a flowchart of another method for accessing external data on the oracle side according to an exemplary embodiment of this specification. As shown in Figure 6, the method may include the following steps.
- Step 602 The oracle receives the external data access request encrypted and transmitted by the private computing node, and the external data access request is initiated by the private computing node during the execution of the smart contract in the trusted execution environment of the node.
- the oracle may be a single oracle node or an oracle cluster containing multiple oracle nodes (including control nodes and oracle nodes other than control nodes).
- the oracle encryption public key used by the privacy computing node for encryption can be the encryption public key of a single oracle node or the encryption public key of an oracle node other than the control node in the oracle cluster, or it can be the encryption of the control node in the oracle cluster Public key.
- the oracle machine can receive the external data access request encrypted by the oracle machine encryption public key in the node TEE by the private computing node, and decrypt the received external data access request based on the oracle machine encryption private key.
- the aforementioned oracle encryption public key may be the encryption public key of a single oracle node, or may be the encryption public key of an oracle node other than the control node in the oracle cluster.
- the privacy computing node encrypts the external data access request based on the encryption public key of the single oracle node in the node TEE, and encrypts the encrypted public key.
- the external data access request is sent to the single oracle node to be decrypted by the single oracle node based on the maintained encrypted private key.
- the privacy computing node is based on the encryption public key of any oracle node in the node TEE to the external
- the data access request is encrypted, and the encrypted external data access request is sent to the control node in the oracle cluster, and the control node forwards the encrypted external data access request to any oracle node, so that the The oracle node performs decryption based on the maintained encrypted private key.
- the control node in the oracle cluster can receive the external data access request that the private computing node encrypts based on the oracle encryption public key in the node TEE, and based on the oracle encryption private key maintained by the control node.
- the encrypted external data access request is decrypted and forwarded to the oracle node in the oracle cluster for processing.
- the oracle encryption public key used by the privacy computing node to encrypt the external data access request is the encryption public key of the control node; wherein, the encrypted external encryption key is based on the oracle encryption private key maintained by the control node.
- forwarding to the oracle node in the oracle cluster for processing may include: decrypting the received external data access request based on the encrypted private key maintained by the control node, and based on the encryption of any oracle node The public key re-encrypts the external data access request, and forwards the re-encrypted external data access request to any oracle node.
- privacy computing nodes and oracles may support different data encoding formats. Therefore, the privacy computing node can convert the external data access request in the first format into the second format after generating it.
- the external data access request in the second format sent by the privacy computing node received by the oracle is obtained by the privacy computing node's conversion of the external data access request in the first format; and the external data access request in the first format is in the execution of the smart contract. Circumstances.
- Step 604 The oracle machine decrypts in the oracle machine trusted execution environment to obtain the external data access request, and accesses the remote server according to the external data access request.
- Step 606 The oracle creates an external data request response in the trusted execution environment of the oracle according to the access result and encrypts it, and returns the encrypted external data request response to the privacy computing node; the external data request response is used to The node participates in the execution operation of the smart contract after decryption in the trusted execution environment.
- the oracle After the oracle creates an external data request response based on the access result, it can also sign the external data request response based on the maintained oracle signature private key to prove to the private computing node that the external data request response is reliable sex.
- the private computing node in order to enable the private computing node to verify the response to a signed external data request based on the pre-maintained oracle signature public key, it is necessary to obtain the oracle signature public key in advance. To this end, it can also include the process of remote certification of the oracle.
- the oracle signature private key is maintained by the oracle node; the oracle node can return a remote attestation report to the privacy computing node; the remote attestation report is predicted by the authentication server
- the self-recommendation information generated by the oracle node is generated after verification, and the self-recommendation information is related to the TEE created on the oracle node; in the case that the oracle node is determined to be trustworthy according to the remote attestation report, the oracle signature public key is The compute node is stored locally.
- the oracle signature private key is maintained by the oracle node in the cluster that responds to external data access requests; the control node in the oracle cluster returns to the privacy computing node to each oracle node in the cluster
- Each remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the corresponding oracle node, and the self-recommendation information is related to the TEE created on the corresponding oracle node; it is determined according to the remote attestation report
- the oracle signature public key of the trusted oracle node is stored locally by the private computing node.
- the oracle can use the node public key to encrypt the created external data request response, and return the encrypted external data request response to the privacy computing node.
- the private computing node decrypts the encrypted external data request response based on the node's private key.
- the node private key is only maintained by the private computing node, or the node private key is jointly maintained by all private computing nodes in the private computing cluster.
- the external data request response created based on the access result also uses the second format; after the external data request response in the second format is returned to the privacy computing node, The private computing node converts the external data request response in the first format; the private computing node can complete the execution operation of the smart contract based on the external data request response in the first format.
- FIG. 7 is a flowchart of another method for an oracle to control node-side access to external data shown in an exemplary embodiment of this specification. As shown in Figure 7, the method may include the following steps.
- control node in the oracle cluster receives an external data access request encrypted and transmitted by the private computing node, and the external data access request is initiated by the private computing node during the execution of the smart contract in the trusted execution environment of the node.
- the private computing node encrypts the external data access request based on the encryption public key of the control node.
- the control node TEE controls maintenance-based The node encryption private key decrypts the received external data access request.
- Step 704 The control node decrypts the external data access request in the trusted execution environment of the control node, and forwards the external data access request to the selected oracle node in the cluster, where the external data access request is used for Instruct the selected oracle node to access the remote server.
- control node After the control node receives the external data access request, it can select a trusted node in the cluster as the oracle node for processing this external data access request (this trusted node is the one selected in this step).
- Oracle node can re-encrypt the external data access request based on the encrypted public key of the trusted node in the control node TEE, and send the re-encrypted external data access request to the trusted node.
- Step 706 The control node receives the external data request response returned by the selected oracle node according to the access result, and encrypts the external data request response in the trusted execution environment of the control node, and then encrypts the external data request response.
- the external data request response is returned to the privacy computing node.
- the selected oracle node After the selected oracle node receives the re-encrypted external data access request sent by the control node, it can use the encrypted private key maintained by itself in the selected oracle TEE (that is, the trusted node’s Encrypted private key) for decryption; and initiates access to the corresponding remote server based on the decrypted external data access request.
- the encrypted private key maintained by itself in the selected oracle TEE that is, the trusted node’s Encrypted private key
- the selected oracle node can create an external data request response in the TEE based on the access result, and sign it with the signature private key of the selected oracle After the signed external data access request is verified by the privacy computing node based on the pre-obtained oracle public key (that is, the encrypted public key of the selected oracle), it is used to complete the execution of the smart contract.
- the private computing node can obtain the encryption public key of the selected oracle in a variety of ways.
- the control node may send a remote report certificate to the private computing node; after the remote certificate report is verified by the private computing node, the oracle node corresponding to the remote certificate is determined to be a trusted node; the public key of the trusted node The information is stored locally by the privacy computing node.
- the private computing node may obtain the public key information of all trusted nodes in the oracle cluster in advance.
- control node can send the remote attestation report corresponding to all the oracle nodes in the cluster to the private computing node; the private computing node verifies the received remote attestation report, and reports the successfully verified remote attestation to the corresponding oracle node Determine as a trusted node, and save the signature public key information of all trusted nodes locally.
- the remote attestation report of the oracle node in the cluster can be received by the control node, and based on the remote attestation report to determine whether the oracle node is a trusted node; in the case of receiving an external data access request sent by the privacy computing node , The control node can allocate a trusted node to process the external data access request based on the principle of load balancing.
- FIG. 8 is a schematic diagram of accessing external data based on a single oracle node according to an exemplary embodiment of this specification
- FIG. 9 is a schematic diagram of accessing external data based on a single oracle node according to an exemplary embodiment of this specification.
- Interactive diagram As shown in FIG. 9, a single oracle node is called an Oracle node, and the interaction process may include steps 901 to 913.
- step 901 the off-chain privacy computing node executes the off-chain contract.
- the off-chain contract is pre-deployed at the off-chain privacy computing node.
- the off-chain privacy computing node encrypts the bytecode of the off-chain contract in the off-chain TEE and stores it outside the off-chain TEE, such as a hard disk.
- the off-chain privacy computing node can respond to the received call request, read the contract ID of the off-chain contract that needs to be called from the call request, and find the encrypted bytecode of the corresponding off-chain contract according to the contract ID, After encryption, the bytecode is read into the TEE under the chain, and then decrypted in the TEE under the chain to obtain the bytecode of the plaintext.
- the execution engine of the off-chain contract is deployed in the off-chain TEE, such as EVM (Ethereum Virtual Machine), WASM virtual machine or other types of virtual machines.
- the off-chain privacy computing node executes the above-mentioned bytecode through the virtual machine in the off-chain TEE, that is, executes the above-mentioned off-chain contract. If multiple types of execution engines are deployed in the off-chain TEE, usually when the off-chain private computing node deploys the off-chain contract, it will also record the information of the virtual machine used to execute the off-chain contract to ensure that the off-chain contract is When called, use the correct virtual machine to execute the off-chain contract.
- An off-chain contract may contain multiple functions.
- the call request can include the function name to instruct the off-chain private computing node to execute only the function corresponding to the function name through the virtual machine, instead of all the bytecodes of the off-chain contract.
- a call request for an off-chain contract can come from a blockchain node.
- the blockchain node receives a transaction submitted by the client, and generates off-chain privacy computing requirements during the execution of the transaction, thereby passing the oracle mechanism Transfer the call request to the private computing node under the chain.
- the call request for the off-chain contract can also originate from the client.
- the client directly sends the call request to the off-chain privacy computing node through the off-chain channel.
- step 902 the off-chain privacy computing node creates an external data access request.
- the external data access interface can be defined in the off-chain contract, and the external data access interface can be called by one or more functions in the off-chain contract.
- the off-chain private computing node can create the above-mentioned external data access request, so as to realize the access operation for the external data.
- the external data access request may include the IP address of the remote server to be accessed and the content to be accessed (such as storage address, keywords, etc.).
- the off-chain privacy computing node can be pre-configured with a security file, and the security file is used to securely filter the generated external data access requests.
- the security file may include one or more of field restrictions on external data access requests, access content restrictions, and IP address restrictions. Among them, field restrictions and access content restrictions can be implemented by checking the fields in the external data access request based on the security file.
- IP address restriction can be implemented based on the IP whitelist. For example, when the destination IP address in the external data access request is not in the IP whitelist, the execution operation of accessing external data is not allowed.
- the HTTPS model includes the HTTP model and the SSL model.
- the HTTP model can include information such as the remote server address, remote server port, request method (such as GET/POST), resource access path, version protocol, HTTPS request header, HTTPS request body, etc.; in the SSL model, trust can be included
- the value of fields such as the address and port of the remote server can be defined in the off-chain contract, so that the corresponding external data access request must include the address and port of the above-mentioned remote server defined in the off-chain contract, that is, off-chain
- the remote server defined by the contract is a fixed server; alternatively, the address and port of the remote server can be defined as empty in the off-chain contract and defined by the parameters included in the call request, so that the corresponding external data access request includes The address and port of the remote server indicated by the call request, that is, the remote server defined by the off-chain contract is not fixed.
- the off-chain private computing node If the oracle node does not support the above-mentioned HTTPS protocol or the external data access request of other protocols generated by the off-chain private computing node, the off-chain private computing node also needs to format the created external data access request to enable the oracle node Able to smoothly process received external data access requests.
- a format conversion interface can be set in advance, and the format conversion can be performed by calling the interface when format conversion is required.
- the format conversion interface can be used to indicate a prediction (Oracle) coding model, which contains the general bytecode of the prediction coding format (that is, the second format in the previous article), and only the creation of The specific information in the external data access request using the off-chain node coding format (that is, the first format in the preceding text) can be copied to the prediction coding model.
- a prediction (Oracle) coding model which contains the general bytecode of the prediction coding format (that is, the second format in the previous article), and only the creation of The specific information in the external data access request using the off-chain node coding format (that is, the first format in the preceding text) can be copied to the prediction coding model.
- this conversion method is only illustrative, and how to implement the format conversion can be determined by those skilled in the art according to actual conditions.
- step 903 the external data access request created by the off-chain privacy computing node is encrypted.
- the off-chain privacy computing node since there is only a single oracle node, the off-chain privacy computing node reads the encrypted public key of the oracle node into the off-chain TEE, and uses the encrypted public key to create external data in the off-chain TEE.
- the access request is encrypted.
- Step 904 the off-chain privacy computing node sends an encrypted external data access request to the oracle node.
- Step 905 The oracle node decrypts the received external data access request.
- the oracle node decrypts the received external data access request in the TEE created by the oracle node based on the encrypted private key maintained by the oracle node.
- step 906 the prediction node creates a remote server access request based on the external data access request.
- the oracle node can directly read the data in the external data access request after decrypting the external data access request in step 905, and based on the external data
- the content of the access request initiates access to the remote server.
- the prediction node may include creating a remote server access request based on the read IP address, port and other information of the remote server to initiate a request to the remote server.
- the remote server access request may include external data information, which is used to instruct the remote server to obtain corresponding external data.
- the prediction node can encrypt the remote server access request in the TEE created by itself to avoid exposing the information of the external data contained in the request during the transmission process.
- Step 907 The oracle node sends an access request to the remote server.
- step 908 the remote server returns the access result to the prediction node.
- step 909 the prediction node creates an external data request response based on the returned access result.
- the remote server needs to read the encrypted remote server access request into the TEE created by itself, and perform a decryption operation in the TEE to obtain the remote server access request in plain text.
- the remote server can encrypt the access result in the TEE created by itself, and then return the encrypted access result to the prediction node.
- the oracle node After the oracle node receives the access result returned by the remote server, it can decrypt the access result in the TEE created by the oracle node, read the data in the access result, and create an external data request response based on the read data.
- Step 910 The prediction node encrypts and signs the created external data request response.
- the oracle node After the oracle node creates the external data request response, it also signs in the TEE with the signature private key of the oracle node, and encrypts the external data request response based on the encrypted public key of the off-chain privacy computing node, and then transmits it to the off-chain privacy computing node.
- the off-chain private computing node can decrypt and verify the signature to ensure that the response to the external data request is reliable.
- Fig. 10 is a flow chart of remote certification for a single oracle node according to an exemplary embodiment of this specification.
- the off-chain private computing node to remotely prove the oracle node mainly includes the following steps: step 1, the off-chain private computing node initiates a challenge to the oracle node; step 2, After receiving the challenge information, the oracle node generates self-recommendation information related to the oracle TEE and sends it to the authentication server; step 3, the authentication server verifies the self-recommendation information of the oracle, and generates a remote certification report based on the verification result; and returns it to Oracle: Step 4, the oracle machine forwards the remote attestation report to the off-chain private computing node, so that the off-chain private computing node determines whether the oracle node is credible based on the remote attestation report.
- the authentication server signs the remote attestation report with its own signature private key and then returns it to prove the reliability of the remote attestation report (the device that receives the remote attestation report can be based on the signature of the authentication server.
- the key verifies whether the remote attestation report was created by the authentication server).
- the remote attestation report can be forwarded by the oracle to the off-chain privacy node, or directly sent by the authentication server to the off-chain privacy computing node.
- the off-chain privacy computing node After the off-chain privacy computing node receives the remote certification report and successfully verifies the signature based on the public key of the authentication server, it can save the signature public key of the oracle node locally for use in response to the external data request returned by the oracle. Sign verification.
- step 911 the oracle node returns an encrypted external data request response to the off-chain privacy computing node.
- Step 912 the off-chain privacy computing node verifies and decrypts the received external data request response.
- the off-chain privacy computing node After the off-chain privacy computing node receives the external data request response, it can verify the signature based on the public key of the oracle obtained in advance, and decrypt the external data request response based on the encrypted private key maintained by itself after the verification is successful. In this step, since the encryption is performed first and then the signature is verified in step 910, the signature is first verified and then decrypted in this step.
- the reason for adopting this order in this embodiment is that in the case of a signature verification failure, the request response itself is proved to be unreliable, and there is no need to perform steps such as decryption; if the signature is performed first and then the encryption is performed in step 910, then in this step Priority is required for decryption and signature verification. In this case, even if the request response itself is unreliable, two steps of decryption and signature verification are still required for the request response.
- the specific operation can be determined by those skilled in the art according to actual needs.
- step 913 the off-chain privacy computing node completes the execution of the off-chain contract based on the decrypted and verified external data request response.
- the execution of the off-chain contract can be completed according to the obtained external data.
- the execution result can also be fed back to the blockchain node through the oracle under the blockchain in Figure 2, so that the blockchain node can complete the execution of the on-chain contract.
- the off-chain privacy computing node can also belong to the off-chain privacy computing cluster.
- the blockchain node can call any trusted off-chain privacy computing node in the cluster to execute the off-chain contract.
- the off-chain privacy computing cluster usually contains a control node, and the control node can also assign a trusted node as the off-chain privacy computing node that executes the off-chain contract. At this time, if any trusted node in the cluster needs to access External data can interact with the oracle through the control node.
- the technical solution of this specification can be used to initiate access to a remote server through a single oracle node by the off-chain private computing node when an external data access requirement is detected during the execution of the off-chain contract.
- the external data request response created based on the returned access result completes the execution of the off-chain contract.
- the off-chain privacy computing node performs remote certification to the oracle node in advance, thereby ensuring the reliability of the oracle node.
- the off-chain private computing node determines that the oracle node is a trusted node based on remote proof, it locally saves the signature public key of the oracle node, so that the signature public key of the oracle node is returned after receiving the oracle node.
- the external data request After the external data request is responded, it can be verified. The security and integrity of the data are ensured through such a verification mechanism.
- the encryption key pair and the signature key pair of the oracle node may be the same key pair. This approach simplifies the complexity of encryption and decryption and signature verification while ensuring data security and integrity.
- FIG. 11 is a schematic diagram of accessing external data based on an oracle cluster according to an exemplary embodiment of this specification.
- Fig. 12 is an interaction diagram showing a method for accessing external data based on an oracle cluster according to an exemplary embodiment of the present specification.
- the oracle cluster can be called an Oracle cluster.
- the cluster contains a control node.
- the oracle nodes in the cluster other than the control node are called Entity.
- This method can Including step 1201 to step 1217.
- step 1201 the off-chain privacy computing node executes the off-chain contract.
- step 90 is similar to step 901, and reference may be made to the introduction of step 901, which will not be repeated here.
- Step 1202 the off-chain privacy computing node creates an external data access request.
- step 902 This step is similar to step 902, and reference may be made to the introduction of step 902, which will not be repeated here.
- Step 1203 the external data access request created by the off-chain privacy computing node is encrypted with the encryption public key of the prediction control node.
- the off-chain privacy computing node reads the encrypted public key of a single oracle node into the off-chain TEE, and based on the encrypted public key in the chain In the lower TEE, the created external data access request is encrypted; and in this embodiment, the off-chain privacy computing node reads the encrypted public key of the control node into the off-chain TEE, and is based on the encrypted public key of the control node in the off-chain
- the external data access request created in TEE is encrypted.
- the off-chain privacy computing node encrypts the external data access request based on the encryption public key of the oracle node that actually processes the external data access request; and in this embodiment, it is based on the encryption public key of the control node
- the external data access request is encrypted, but the control node does not process the external data access request in this application.
- the off-chain private computing node does not need to negotiate with the control node in advance which entity in the cluster will process the external data access request, and it does not need to use the oracle encryption public key corresponding to the entity for encryption.
- Step 1204 The off-chain privacy computing node sends an encrypted external data access request to the oracle control node.
- Step 1205 The prediction control node decrypts the received external data access request based on the control node encryption private key.
- the prediction control node decrypts the received external data access request in the TEE created by the control node based on the encrypted private key maintained by the control node.
- the prediction control node after receiving the external data access request, the prediction control node also needs to assign an entity to the external data access request to process the external data access request.
- the oracle cluster includes the oracle control node and A, B, C... several entities.
- control node After the control node receives the external data access request, it assigns entity A as the oracle node for processing this external data access request, that is, the initiation of access to the remote server and other operations are performed by entity A, and entity A will be used in the subsequent steps
- entity A will be used in the subsequent steps
- the assigned entity introduces the interaction process.
- the control node can use multiple methods to allocate entities that process external data access requests. For ease of presentation, this process will be referred to as the allocation entity in the following text.
- an entity can be selected from the oracle cluster randomly or based on a load balancing algorithm to process this external data access request.
- the control node allocates entities based on a load balancing algorithm. Specifically, the control node can separately obtain the load status of each entity in the cluster upon receiving an external data access request, and based on the load balancing algorithm, regard the entity with better performance as the one responsible for processing the external data access request.
- Oracle node Oracle node.
- control node can also monitor the load status of each entity in the cluster in real time, and when an external data access request is received, determine an entity with better performance based on the load balance algorithm that has been obtained.
- load balance algorithm that has been obtained.
- the remote attestation method can be implemented in a variety of ways. In this embodiment, the method as shown in FIG. 10 can be used to remotely prove the entities in the cluster.
- FIG. 13 is a flow chart of remotely attesting oracle nodes in an oracle cluster according to an exemplary embodiment of this specification.
- This process may include the following steps: Step 1, the prediction control node initiates a challenge to all entities in the cluster; Step 2, any entity in the cluster, after receiving the challenge information, generates self-recommendation information related to the entity’s TEE and sends it to the certification Server; step 3, after receiving the self-recommendation information sent by any entity, the authentication server verifies the self-recommendation information, and generates a corresponding remote attestation report based on the verification result and returns it to any entity; step 4, all received authentication The entity of the remote certification report returned by the server returns the remote certification report to the prediction control node.
- the prediction control node After receiving all remote certification reports, the prediction control node verifies all remote certification reports, and determines the entity corresponding to the successfully verified remote certification report as a trusted node.
- all remote certification reports can be determined to be trusted.
- the cluster formed by the entities of the node is determined to be a trusted cluster.
- the off-chain private computing node can request a remote attestation report from the prediction control node, so that the off-chain private computing node can verify whether the entities in the prediction cluster are trustworthy; when the off-chain private computing node determines any entity based on the remote attestation report
- the signature public key of any entity can be stored locally.
- the off-chain private computing node can also initiate a challenge to the control node, and then the control node forwards the challenge information to each entity.
- the specific process of obtaining the remote attestation report is consistent with the challenge initiated by the control node, and will not be repeated here.
- the predictive control node can use the load balancing algorithm to allocate the entities. In this way, the load situation of each entity can be better balanced, and the situation of excessive load of a single entity is avoided, thereby improving the stability of the performance of the entire cluster.
- the prediction control node After the prediction control node decrypts the external data access request based on the control node encryption private key and distributes the entity, the prediction control node can be based on the distributed encryption public key of the entity (in this embodiment, it is the encryption public key of entity A) Encrypt external data access requests. In this way, the prediction control node does not need to negotiate with the off-chain privacy computing node in advance the entity used to process this external data access request, which reduces the number of interactions and improves access efficiency.
- Step 1206 The prediction control node re-encrypts the external data access request based on the encryption public key of the entity A.
- the prediction control node In order to ensure that the data is transmitted in the form of ciphertext and can be decrypted by the entity A, it is necessary for the prediction control node to re-encrypt the external data access request based on the encryption public key of the entity A obtained in advance.
- Step 1207 The prediction control node sends the re-encrypted external data access request to the entity A.
- Step 1208 Entity A decrypts the received external data access request based on its own encryption private key.
- Entity A decrypts the received external data access request in the TEE created by entity A based on the encrypted private key maintained by itself.
- Step 1209 Entity A creates a remote access request based on the decrypted external data access request.
- step 906 This step is similar to step 906, and reference may be made to the introduction of step 906, which will not be repeated here.
- Step 1210 Entity A initiates access to the remote server.
- Step 1211 The remote server returns the access result to the entity A.
- Step 1212 Entity A creates an external data request response based on the received access result.
- step 909 is similar to step 909 except that the execution subject is entity A, and can refer to the introduction of step 909, which will not be repeated here.
- Step 1213 Entity A encrypts and signs the created external data request response.
- entity A After entity A creates the external data request response, it also signs in the TEE with the private key of entity A's signature, and encrypts the external data request response based on the encrypted public key of the private computing node under the chain, and then transmits it to the oracle control node Off-chain privacy computing node.
- the off-chain private computing node can decrypt and verify the signature to ensure that the response to the external data request is reliable.
- the off-chain privacy computing node needs to remotely prove the entity A in advance.
- the off-chain private computing node usually only interacts with the control node of the oracle cluster, that is, the off-chain private computing node interacts with the oracle cluster as a whole "oracle". Therefore, under normal circumstances, it is necessary to remotely prove all entities in the oracle cluster in advance. In this embodiment, it is predicted that the control node may have remotely proven the entities in the cluster in advance (as described in step 1205).
- the control node when the control node receives the remote certification report acquisition request sent by the off-chain privacy computing node, it only needs to send the remote certification report corresponding to all entities retained in the control node to the off-chain privacy computing node.
- the lower privacy computing node can verify whether all entities in the prediction cluster are trusted nodes after receiving all remote attestation reports, and save the signature public key of the trusted node that is successfully verified locally.
- the off-chain private computing node stores the signature public keys of all trusted entities. Therefore, no matter which entity returns the external data request response, the off-chain privacy computing node can verify the received external data request response based on the stored signature public key.
- the above remote certification process can be initiated by the control node in the off-chain privacy computing cluster. After the verification is successful, the information will be synchronized to all the clusters. Off-chain privacy computing node.
- any off-chain private computing node in the cluster can also synchronize the verification information to other off-chain private computing nodes after performing the above verification process; in order to further ensure the reliability of the verification, all off-chain private computing nodes in the cluster can also be used separately authenticating.
- Step 1214 Entity A sends the encrypted external data request response to the prediction control node.
- Step 1215 The prediction control node forwards the encrypted external data request response to the off-chain privacy computing node.
- the off-chain privacy computing node belongs to the off-chain privacy computing cluster, it is usually necessary to send the external data request response to the control node of the off-chain privacy computing cluster, and then the control node forwards it to the chain that sends the corresponding external data access request Down the privacy computing node.
- Step 1216 the off-chain privacy computing node responds to the received external data request to verify the signature and decrypt it.
- the off-chain privacy computing node locally retains the signature public key information of all trusted entities, and the signature public key of entity A can be used to verify the response to the external data request; and the private key pair of the off-chain node maintained by itself
- the external data request response is decrypted. Similar to the previous embodiment, when entity A first encrypts the external data request response and then signs it, in this step, the external data request response is first verified and then decrypted.
- signature encryption and signature verification and decryption sequence please refer to the introduction of step 912, which will not be repeated here.
- step 1217 the off-chain privacy computing node completes the execution of the off-chain contract based on the decrypted and verified external data request response.
- step 913 The content of this step is similar to that of step 913, and reference may be made to the related introduction in step 913, which will not be repeated here.
- the oracle encryption public key (belonging to the control node) used by the off-chain private computing node to encrypt external data access requests is used with the off-chain private computing node to respond to external data requests
- the oracle signature private key (belonging to the entity A) for the verification must not belong to the same key pair.
- this embodiment introduces the concept of an oracle cluster, so that when the off-chain private computing node accesses external data, there are more oracle nodes to choose from. It is understandable that in an oracle cluster, if a single node fails, external data can still be accessed through the oracle node. In other words, this embodiment improves the reliability of transmission by setting up an oracle cluster.
- the off-chain private computing node since the off-chain private computing node encrypts the external data access request based on the encryption public key of the control node, the off-chain private computing node does not need to communicate with the oracle in advance when there is an external data access requirement. Control node negotiation (which oracle node in the cluster is responsible for processing this external data access request), thereby reducing the number of interactions and improving access efficiency.
- the oracle control node remotely certifies all the oracle nodes in the oracle cluster in advance, the oracle nodes in the cluster (the aforementioned trusted oracle cluster) are all trusted nodes. In this way, when the off-chain private computing node has external data access requirements, the oracle control node can allocate the oracle node for processing this external data access request based on the load balancing principle.
- Fig. 14 is a schematic structural diagram of an electronic device according to an exemplary embodiment.
- the device includes a processor 1402, an internal bus 1404, a network interface 1406, a memory 1408, and a non-volatile memory 1410.
- the processor 1402 reads the corresponding computer program from the non-volatile memory 1410 to the memory 1408 and then runs it to form a device for accessing external data on a logical level.
- one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, and so on. That is to say, the execution subject of the following processing flow is not limited to each
- the logic unit can also be a hardware or a logic device.
- the device for accessing external data may include: a request unit 1501 to enable the off-chain private computing node to execute the blockchain in an off-chain trusted execution environment In the process of the off-chain contract invoked by the node, in response to the external data access demand of the off-chain contract, an external data access request is generated in the off-chain trusted execution environment, and the external data access request is encrypted and transmitted to Oracle; response unit 1502, which enables the off-chain privacy computing node to receive an external data request response encrypted by the oracle.
- the feedback unit 1503 enables the off-chain private computing node to decrypt in the off-chain trusted execution environment to obtain the external data request response, and complete the response to the external data request according to the external data request response. Execution operations of off-chain contracts.
- the request unit 1501 is further configured to: enable the off-chain private computing node to encrypt the external data access request based on the oracle encryption public key in the off-chain trusted execution environment, and to combine the encrypted An external data access request is sent to the oracle; wherein the oracle includes an oracle node that maintains the oracle encryption private key; or, in the case that the oracle is an oracle cluster, the oracle is encrypted The private key is maintained by the control node of the oracle cluster, and the encrypted external data access request is decrypted by the control node and forwarded to the oracle node in the oracle cluster for processing.
- the external data request response is signed by the oracle signature private key; further comprising: a signature verification unit 1504, which enables the off-chain private computing node to request the external data based on the oracle signature public key obtained in advance The signature verification is performed in response; wherein the off-chain privacy computing node confirms that the signature verification is successful, and completes the execution operation of the off-chain contract according to the external data request response.
- a signature verification unit 1504 which enables the off-chain private computing node to request the external data based on the oracle signature public key obtained in advance
- the signature verification is performed in response; wherein the off-chain privacy computing node confirms that the signature verification is successful, and completes the execution operation of the off-chain contract according to the external data request response.
- it further includes: an authentication unit 1505.
- the oracle is an oracle node
- the oracle signature private key is maintained by the oracle node
- the off-chain privacy computing node is allowed to obtain information specific to the oracle.
- the remote attestation report of the node is generated by the authentication server after verifying the self-recommendation information generated by the oracle node, and the self-recommendation information is related to the trusted execution environment created on the oracle node;
- the off-chain private computing node is made to store the oracle signature public key locally; in the case that the oracle is a cluster of oracle, the oracle is The signed private key is maintained by the oracle node in the cluster that responds to the external data access request; the off-chain private computing node is made to obtain the remote certification report for each oracle node in the cluster, and each remote certification report is issued by the authentication server
- the self-recommendation information generated by the corresponding oracle node is generated after verification, and the self-recommendation information is related to the trusted execution environment created on the corresponding oracle node; and the off-chain private computing
- the external data request response is encrypted by the oracle machine in the trusted execution environment of the oracle machine using the public key of the off-chain node; the response unit 1502 is further configured to: enable the off-chain private computing node to receive the The oracle machine encrypts the returned external data request response, and decrypts the received external data request response through the private key of the off-chain node in an off-chain trusted execution environment.
- the off-chain node’s private key is only maintained by the off-chain private computing node, or the off-chain node’s private key is maintained by the off-chain node. All off-chain privacy computing nodes in the privacy computing cluster are jointly maintained.
- the request unit 1501 is further configured to: enable the off-chain privacy computing node to obtain an external data access request in the first format generated by executing the off-chain contract, and convert the obtained external data access request into The second format; enable the off-chain private computing node to encrypt and transmit the external data access request converted into the second format to the oracle; the feedback unit 1503 is further configured to: enable the off-chain private computing node to obtain The external data request response in the second format is converted into the external data request response in the first format; the off-chain privacy computing node is made to complete the execution operation of the off-chain contract based on the external data request response in the first format.
- a checking unit 1506 which enables the off-chain privacy computing node to check the fields in the external data access request; when it is detected that the external data access request has a field that does not meet the access requirements or When the content of the request or the destination IP address is not in the preset whitelist, the operation of accessing external data is prohibited.
- the device for accessing external data may include: a receiving unit 1601, which enables the oracle to receive an external data access request encrypted and transmitted by a private computing node under the chain.
- the request is initiated by the off-chain privacy computing node in response to the external data access demand of the off-chain contract; when the off-chain contract is called by the blockchain node, the off-chain privacy computing node can be used off-chain.
- the access unit 1602 enables the oracle to decrypt the external data access request in the trusted execution environment of the oracle, and access the remote server according to the external data access request; the return unit 1603 to enable all
- the oracle machine creates an external data request response in the trusted execution environment of the oracle machine according to the access result and encrypts it, and returns the encrypted external data request response to the off-chain privacy computing node; the external data request response is used to Participate in the execution of the off-chain contract after decryption in the off-chain trusted execution environment.
- the receiving unit 1601 is further configured to: if the oracle is an oracle node, enable the oracle to receive the off-chain private computing node based on the oracle in the off-chain trusted execution environment. Encrypt the external data access request encrypted by the public key, and decrypt the received external data access request based on the oracle encryption private key; or, if the oracle is an oracle cluster, make the oracle cluster
- the control node receives the external data access request based on the oracle encryption public key encryption by the off-chain private computing node in the off-chain trusted execution environment, and requests the nodes in the cluster based on the oracle encryption private key maintained by the control node
- the encrypted external data access request is processed.
- a signing unit 1604 which enables the oracle to sign the external data request response based on the oracle signature private key.
- the returning unit 1603 is further configured to: enable the oracle to perform the off-chain privacy calculation The node returns a remote attestation report; the remote attestation report is generated by the authentication server after verifying the self-recommendation information generated by the oracle node, and the self-recommendation information is related to the trusted execution environment created on the oracle node; If the remote attestation report confirms that the oracle node is trusted, the oracle signature public key is stored locally by the off-chain private computing node; in the case that the oracle is an oracle cluster, the oracle signature private key is used by the cluster Oracle node maintenance in response to the external data access request; the returning unit 1603 is further configured to: make the control node in the oracle cluster return to the off-chain privacy computing node the information of each oracle node in the cluster Remote report certification
- the returning unit 1603 is further configured to: enable the oracle to encrypt the created external data request response using the off-chain node public key, and return the encrypted external data request response to the off-chain privacy computing Node; the encrypted external data request response is received by the off-chain privacy computing node and decrypted based on the off-chain node's private key.
- the off-chain node’s private key is only maintained by the off-chain private computing node, or the off-chain node’s private key is maintained by the off-chain node. All off-chain privacy computing nodes in the privacy computing cluster are jointly maintained.
- the receiving unit 1601 is further configured to: enable the oracle to receive the external data access request encrypted and transmitted by the off-chain private computing node, including: enabling the oracle to receive the second sent by the off-chain private computing node The external data access request in the second format; the external data access request in the second format is converted from the external data access request in the first format generated by the off-chain privacy computing node when the off-chain contract is executed;
- the returning unit 1603 is further configured to return the encrypted external data request response to the off-chain privacy computing node, including: enabling the oracle to return the external data request response in the second format to the off-chain privacy Computing node; the external data request response in the second format is converted by the off-chain private computing node to the external data request response in the first format; the off-chain private computing node is based on the external data request response in the first format Complete the execution of the off-chain contract.
- the device for accessing external data may include: a request receiving unit 1701 to enable the control node in the oracle cluster to receive the external data encrypted and transmitted by the off-chain private computing node Access request, the external data access request is in response to the external data of the off-chain contract when the off-chain privacy computing node executes the off-chain contract called by the blockchain node in the off-chain trusted execution environment
- the request forwarding unit 1702 enables the control node to decrypt the external data access request in the trusted execution environment of the control node, and forward the external data access request to the selected oracle node in the cluster,
- the external data access request is used to instruct the selected oracle node to access the remote server;
- the result return unit 1703 enables the control node to receive the external data request response returned by the selected oracle node according to the access result, And after the external data request response is encrypted in the trusted execution environment of the control node, the encrypted external data request response is returned to the off
- the external data request response is created by the selected oracle node in the oracle trusted execution environment, and is signed by the selected oracle using the oracle private key; after the signing After the off-chain privacy computing node verifies the signature based on the public key of the oracle machine obtained in advance, the external data request response of is used to complete the execution operation of the off-chain contract.
- it further includes: a report sending unit 1704 to enable the control node to send a remote attestation report to the off-chain privacy computing node; after the remote attestation report is verified by the off-chain privacy computing node, the The oracle node corresponding to the remote attestation is determined to be a trusted node; the public key information of the trusted node is stored locally by the off-chain privacy computing node.
- a report receiving unit 1705 that enables the control node to receive a remote certification report of the oracle node in the oracle cluster, and verify whether the oracle node is credible based on the remote report certification Node; the control node in the case of receiving the external data access request sent by the off-chain privacy computing node, based on load balancing, allocates a trusted node for processing the external data access request.
- the device for accessing external data may include: a request unit 1801 to enable the private computing node to execute the smart contract in the trusted execution environment of the node.
- the external data access request is generated in the trusted execution environment of the node, and the external data access request is encrypted and transmitted to the oracle;
- the response unit 1802 enables the privacy computing node to receive the external data request response encrypted and returned by the oracle, so
- the external data request response is generated and encrypted by the oracle machine in the trusted execution environment of the oracle machine according to the access result to the remote server;
- the feedback unit 1803 enables the private computing node to be decrypted and obtained in the node trusted execution environment
- the external data request response completes the execution operation of the smart contract according to the external data request response.
- the request unit 1801 is further configured to: enable the private computing node to encrypt the external data access request based on the oracle encryption public key in the trusted execution environment of the node, and access the encrypted external data
- the request is sent to the oracle; wherein, the oracle includes an oracle node that maintains the oracle encryption private key; or, in the case that the oracle is an oracle cluster, the oracle encryption private key is The control node of the oracle cluster is maintained, and the encrypted external data access request is decrypted by the control node and forwarded to the oracle node in the oracle cluster for processing.
- the external data request response is signed by the oracle signature private key; further comprising: a signature verification unit 1804, which enables the privacy computing node to respond to the external data request response based on the oracle signature public key obtained in advance Sign verification; wherein the privacy computing node confirms that the verification is successful, according to the external data request response to complete the execution operation of the smart contract.
- a signature verification unit 1804 which enables the privacy computing node to respond to the external data request response based on the oracle signature public key obtained in advance Sign verification; wherein the privacy computing node confirms that the verification is successful, according to the external data request response to complete the execution operation of the smart contract.
- the external data request response is encrypted by the oracle machine using the node public key in the oracle trusted execution environment; the response unit 1802 is further configured to: the privacy computing node receives the encrypted return from the oracle machine External data request response, and decrypt the received external data request response through the node's private key in the trusted execution environment of the node.
- the node private key is only maintained by the private computing node, or the node private key is jointly maintained by all private computing nodes in the private computing cluster.
- the device for accessing external data may include: a receiving unit 1901 that enables the oracle to receive an external data access request encrypted and transmitted by a privacy computing node.
- the access request is initiated by the private computing node during the execution of the smart contract in the trusted execution environment of the node;
- the access unit 1902 enables the oracle to decrypt the external data access request in the trusted execution environment of the oracle, and Access the remote server according to the external data access request;
- the return unit 1903 enables the oracle to create and encrypt an external data request response in the trusted execution environment of the oracle according to the access result, and return the encrypted external data request response to the Privacy computing node;
- the external data request response is used to participate in the execution of the smart contract after decryption in the trusted execution environment of the node.
- the receiving unit 1901 is further configured to: in the case that the oracle is an oracle node, the oracle receives that the private computing node encrypts the public key based on the oracle encryption in the node trusted execution environment And decrypt the received external data access request based on the oracle encryption private key; or, in the case that the oracle is an oracle cluster, the control node in the oracle cluster receives the The private computing node encrypts the external data access request based on the oracle encryption public key in the trusted execution environment of the node, and decrypts the encrypted external data access request based on the oracle encryption private key maintained by the control node and forwards it to The oracle node in the oracle cluster performs processing.
- a signing unit 1904 which enables the oracle to sign the external data request response based on the oracle signature private key.
- the returning unit 1903 is further configured to: enable the oracle to encrypt the created external data request response using the node public key, and return the encrypted external data request response to the privacy computing node;
- the encrypted external data request response is decrypted by the privacy computing node based on the node's private key after being received.
- the node private key is only maintained by the private computing node, or the node private key is jointly maintained by all private computing nodes in the private computing cluster.
- the device for accessing external data may include: a request receiving unit 2001, which enables the control node in the oracle cluster to receive the encrypted transmission of the private computing node from the outside Data access request, the external data access request is initiated by the private computing node during the execution of the smart contract in the trusted execution environment of the node; the request forwarding unit 2002 enables the control node to decrypt in the trusted execution environment of the control node Obtain the external data access request, and forward the external data access request to the selected oracle node in the cluster, where the external data access request is used to instruct the selected oracle node to access the remote server; the result return unit 2003, enable the control node to receive the external data request response returned by the selected oracle node according to the access result, and encrypt the external data request response in the trusted execution environment of the control node, and the encrypted data The external data request response is returned to the privacy computing node.
- a request receiving unit 2001 which enables the control node in the oracle cluster to receive the encrypted transmission of the private computing
- the external data request response is created by the selected oracle node in the oracle trusted execution environment, and is signed by the selected oracle using the oracle private key; after the signing
- the response to the external data request is used to complete the execution of the smart contract after the privacy computing node verifies the signature based on the public key of the oracle obtained in advance.
- a typical implementation device is a computer.
- the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.
- the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
- processors CPU
- input/output interfaces network interfaces
- memory volatile and non-volatile memory
- the memory may include non-permanent memory in a computer readable medium, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer readable media.
- RAM random access memory
- ROM read-only memory
- flash RAM flash memory
- Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
- the information can be computer-readable instructions, data structures, program modules, or other data.
- Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media, can be used to store information that can be accessed by computing devices.
- computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
- first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
- first information may also be referred to as second information, and similarly, the second information may also be referred to as first information.
- word “if” as used herein can be interpreted as "when” or “when” or "in response to determination”.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
Abstract
提供一种访问外部数据的方法及装置;该方法应用于链下隐私计算节点,该链下隐私计算节点中建立有可信执行环境,该方法可以在接收到区块链节点发送的链下合约调用请求后,在可信执行环境中执行链下合约,并在链下合约存在外部数据访问需求的情况下,通过预言机向远程服务器发起访问,并基于预言机返回的基于访问结果创建的外部数据请求响应完成对链下合约的执行,进而向区块链节点返回执行结果。本方法可以在访问外部数据的过程中实现隐私保护。
Description
本说明书一个或多个实施例涉及可验证计算技术领域,尤其涉及一种访问外部数据的方法及装置。
针对各种场景下的隐私需求,一种方式是通过同态加密(Homomorphic encryption)和零知识证明(Zero-knowledge proof)等加密技术实现隐私保护,但也随之带来了严重的性能损失。可信执行环境(Trusted Execution Environment,TEE)是另一种解决方式。TEE可以起到硬件中的黑箱作用,在TEE中执行的代码和数据操作系统层都无法偷窥,只有代码中预先定义的接口才能对其进行操作。在效率方面,由于TEE的黑箱性质,在TEE中进行运算的是明文数据,而不是同态加密中的复杂密码学运算,计算过程效率没有损失。
发明内容
有鉴于此,本说明书一个或多个实施例提供一种访问外部数据的方法及装置。
根据本说明书一个或多个实施例的第一方面,提出了一种访问外部数据的方法,包括:链下隐私计算节点在链下可信执行环境中执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求,在所述链下可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机;所述链下隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密;所述链下隐私计算节点在所述链下可信执行环境内解密获得所述外部数据请求响应,根据所述外部数据请求响应完成对所述链下合约的执行操作。
根据本说明书一个或多个实施例的第二方面,提出了一种访问外部数据的方法,包括:预言机接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点响应于链下合约的外部数据访问需求而发起;所述链下合约在被区块链节点调用的情况下,由所述链下隐私计算节点在链下可信执行环境内执行;所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器;所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述链下隐私计算节点;所述外部数据请求响应用于在所述链下可信执行环境内解密后参与所述链下合约的执行操作。
根据本说明书一个或多个实施例的第三方面,提出了一种访问外部数据的方法,包括:预言机集群中的控制节点接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点在链下可信执行环境内执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求而发起;所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问;所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经过加密的外部数据请求响应返回所述链下隐私计算节点。
根据本说明书一个或多个实施例的第四方面,提出了一种访问外部数据的方法,包括:隐私计算节点在节点可信执行环境中执行智能合约的过程中,在所述节点可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机;所述隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密;所述隐私计算节点在所述节点可信执行环境内解密获得所述外部数据请求响应,根据所述外部 数据请求响应完成对所述智能合约的执行操作。
根据本说明书一个或多个实施例的第五方面,提出了一种访问外部数据的方法,包括:预言机接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起;所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器;所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述隐私计算节点;所述外部数据请求响应用于在所述节点可信执行环境内解密后参与所述智能合约的执行操作。
根据本说明书一个或多个实施例的第六方面,提出了一种访问外部数据的方法,包括:预言机集群中的控制节点接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起;所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问;所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经过加密的外部数据请求响应返回所述隐私计算节点。
根据本说明书一个或多个实施例的第七方面,提出了一种访问外部数据的装置,包括:请求单元,使链下隐私计算节点在链下可信执行环境中执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求,在所述链下可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机;响应单元,使所述链下隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密;反馈单元,使所述链下隐私计算节点在链下可信执行环境内解密获得所述外部数据请求响应,根据所述外部数据请求响应完成对所述链下合约的执行操作。
根据本说明书一个或多个实施例的第八方面,提出了一种访问外部数据的装置,包括:接收单元,使预言机接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点响应于链下合约的外部数据访问需求而发起;所述链下合约在被区块链节点调用的情况下,由所述链下隐私计算节点在链下可信执行环境内执行;访问单元,使所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器;返回单元,使所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述链下隐私计算节点;所述外部数据请求响应用于在所述链下可信执行环境内解密后参与所述链下合约的执行操作。
根据本说明书一个或多个实施例的第九方面,提出了一种访问外部数据的装置,包括:请求接收单元,使预言机集群中的控制节点接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点在链下可信执行环境内执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求而发起;请求转发单元,使所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问;结果返回单元,使所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经过加密的外部数据请求响应返回所述链下隐私计算节点。
根据本说明书一个或多个实施例的第十方面,提出了一种访问外部数据的装置,包括:请求单元,使隐私计算节点在节点可信执行环境中执行智能合约的过程中,在所述节点可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至 预言机;响应单元,使所述隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密;反馈单元,使所述隐私计算节点在所述节点可信执行环境内解密获得所述外部数据请求响应,根据所述外部数据请求响应完成对所述智能合约的执行操作。
根据本说明书一个或多个实施例的第十一方面,提出了一种访问外部数据的装置,包括:接收单元,使预言机接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起;访问单元,使所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器;返回单元,使所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述隐私计算节点;所述外部数据请求响应用于在所述节点可信执行环境内解密后参与所述智能合约的执行操作。
根据本说明书一个或多个实施例的第十二方面,提出了一种访问外部数据的装置,包括:请求接收单元,使预言机集群中的控制节点接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起;请求转发单元,使所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问;结果返回单元,使所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经过加密的外部数据请求响应返回所述隐私计算节点。
根据本说明书一个或多个实施例的第十三方面,提出了一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器通过运行所述可执行指令以实现如第一方面、第二方面、第三方面、第四方面、第五方面或第六方面所述的方法。
根据本说明书一个或多个实施例的第十四方面,提出了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如第一方面、第二方面、第三方面、第四方面、第五方面或第六方面所述方法的步骤。
图1是本说明书一示例性实施例示出的一种链下隐私计算节点侧的访问外部数据的方法的流程图。
图2是本说明书一示例性实施例示出的区块链节点调用链下合约过程中访问外部数据的流程图。
图3是本说明书一示例性实施例示出的一种预言机侧的访问外部数据的方法的流程图。
图4是本说明书一示例性实施例示出的一种预言机控制节点侧的访问外部数据的方法的流程图。
图5是本说明书一示例性实施例示出的一种隐私计算节点侧的访问外部数据的方法的流程图。
图6是本说明书一示例性实施例示出的另一种预言机侧的访问外部数据的方法的流程图。
图7是本说明书一示例性实施例示出的另一种预言机控制节点侧的访问外部数据的方法的流程图。
图8是本说明书一示例性实施例示出的一种基于单一预言机节点访问外部数据的示意图。
图9是本说明书一示例性实施例示出的一种基于单一预言机节点访问外部数据的 方法的交互图。
图10是本说明书一示例性实施例示出的一种对单一预言机节点进行远程证明的流程图。
图11是本说明书一示例性实施例示出的一种基于预言机集群访问外部数据的示意图。
图12是本说明书一示例性实施例示出的一种基于预言机集群访问外部数据的方法的交互图。
图13是本说明书一示例性实施例示出的一种预言机集群中的预言机节点进行远程证明的流程图。
图14是本说明书一示例性实施例示出的一种电子设备的示意结构图。
图15是本说明书一示例性实施例示出的一种链下隐私计算节点侧的访问外部数据的装置框图。
图16是本说明书一示例性实施例示出的一种预言机侧的访问外部数据的装置框图。
图17是本说明书一示例性实施例示出的一种预言机控制节点侧的访问外部数据的装置框图。
图18是本说明书一示例性实施例示出的一种隐私计算节点侧的访问外部数据的装置框图。
图19是本说明书一示例性实施例示出的另一种预言机侧的访问外部数据的装置框图。
图20是本说明书一示例性实施例示出的另一种预言机控制节点侧的访问外部数据的装置框图。
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是:在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。
区块链一般被划分为三种类型:公有链(Public Blockchain)、私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外,还有多种类型的结合,比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表,加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等,且各参与者(即节点)可自由加入以及退出网络。私有链则相反,该网络的数据写入权限由某个组织或者机构控制,数据读取权限受组织规定;简单来说,私有链可以为一个弱中心化系统,参与节点具有严格限制且少,因而私有链更适合于特定机构内部使用。联盟链则是介于公有链以及私有链之间的区块链,可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织,参与者通过授权加入网络并组成利益相关联盟,共同维护区块链运行。
在区块链网络中,通过向区块链节点提交相应的区块链交易(简称交易),并由区块链节点执行区块链交易,以实现相应的操作目的。对于上述任何类型的区块链而言,区块链节点均可以通过创建TEE,并将TEE实现为区块链交易的安全执行环境。TEE是基于CPU硬件的安全扩展,且与外部完全隔离的可信执行环境。TEE最早是由Global Platform提出的概念,用于解决移动设备上资源的安全隔离,平行于操作系统为应用程序提供可信安全的执行环境。目前工业界十分关注TEE的方案,几乎所有主流的芯片和软件联盟都有自己的TEE解决方案,比如软件方面的TPM(Trusted Platform Module,可信赖平台模块)以及硬件方面的Intel SGX(Software Guard Extensions,软件保护扩展)、ARM Trustzone(信任区)和AMD PSP(Platform Security Processor,平台安全处理器)等。
以Intel SGX(以下简称SGX)技术为例。区块链节点可以基于SGX技术创建enclave(围圈或飞地),以作为用于执行区块链交易的TEE。其中,区块链节点利用CPU中新增的处理器指令,在内存中可以分配一部分区域EPC(Enclave Page Cache,围圈页面缓存或飞地页面缓存),以用于驻留上述的enclave。上述EPC对应的内存区域被CPU内部的内存加密引擎MEE(Memory Encryption Engine)加密,该内存区域中的内容(enclave中的代码和数据)只有在CPU内核中才能够被解密,且用于加解密的密钥只有在EPC启动时生成并存储在CPU中。可见,enclave的安全边界只包含其自身和CPU,无论是特权或非特权软件都无法访问enclave,即便是操作系统管理员和VMM(virtual machine monitor,虚拟机监视器;或称为,Hypervisor)也无法影响enclave中的代码和数据,因而具有极高的安全性,并且在上述安全性保障的前提下,CPU能够在enclave中对明文形式的区块链交易进行处理,具有极高的运算效率,从而兼顾了数据安全性和计算效率。
基于区块链网络的去中心化架构,使得区块链上的每笔区块链交易都需要在区块链网络内的所有区块链节点上执行,以确保每个区块链节点所维护的区块链账本数据一致。如果交易逻辑较为简单,比如以比特币为例,区块链交易仅用于实现转账操作,此时即便区块链交易需要在所有区块链节点都执行,也不会导致过多的资源消耗。但是,如果区块链提供了智能合约的功能,而区块链交易调用了智能合约,那么情况可能大不相同。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约,智能合约可以通过代码的形式定义。
以以太坊为例,支持用户在以太坊网络中创建并调用一些复杂的逻辑,这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM),每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机,这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上,虚拟机直接运行的是虚拟机代码(虚拟机字节码,下简称“字节码”)。智能合约分为部署和调用两个阶段。
在部署阶段,用户将一个包含创建智能合约信息的交易发送至以太坊网络,该交易的data字段包含智能合约的代码(如字节码),该交易的to字段为空。以太坊网络中的各个节点分别通过EVM执行这个交易,并生成对应的合约实例。在节点间通过共识机制达成一致后,上述交易对应的智能合约创建成功,区块链上出现一个与该智能合约对应的合约账户,该合约账户拥有一个特定的合约地址,合约代码(即智能合约的代码)或合约代码的哈希值保存在该合约账户中,该合约代码用于控制相应的智能合约的行为。
在调用阶段,用户(可以与部署智能合约的用户相同或不同)将一个用于调用智能合约的交易发送到以太坊网络,该交易的from字段是该用户对应的外部账户的地址,to字段是所需调用的智能合约的合约地址,data字段包含调用智能合约的方法和参数。在节点间通过共识机制达成一致后,上述交易声明调用的智能合约以规定的方式在以太坊网络的每个节点上独立执行,所有执行记录和数据都保存在区块链上,所以当交易完成后,区块链上就保存了无法篡改、不会丢失的交易凭证。
如前所述,EVM是一个图灵完备的虚拟机;类似地,其他区块链也可以采用其他类型的虚拟机,比如WASM(WebAssembly)虚拟机等。总之,当交易调用的智能合约 用于实现相对复杂的逻辑时,节点通过虚拟机执行该智能合约的代码的过程会消耗相对较多的计算资源,并且由于区块链网络内的所有节点都需要执行该智能合约的代码,因此随着节点数量的增加会导致计算资源的消耗量成倍增长。因此,虽然结合TEE技术可以相对减少单个区块链节点的资源消耗、加快交易执行效率,但就整个区块链网络而言,仍然会造成极大的资源消耗和浪费。
为此,本说明书提出了在链下部署隐私计算节点(即链下隐私计算节点),可以将原本需要在所有区块链节点上执行的计算操作转移至链下隐私计算节点处执行,区块链节点只需要从链下隐私计算节点处获取计算结果并基于该计算结果更新区块链账本数据即可,并且可以基于可验证计算(Verifiable Computation)技术证明上述的计算结果确实是在可信执行环境内按照预期执行,从而在确保可靠性的同时,极大地降低了链上的资源消耗。
如前所述,通过在区块链节点部署智能合约,使得区块链节点可以执行该智能合约的代码以实现相应的计算需求;类似地,可以将用于执行计算任务的代码部署在链下隐私计算节点处,使得链下隐私计算节点可以执行代码以实现相应的计算需求。为了便于理解,本说明书中将部署于区块链节点的合约称为链上合约、将部署于链下隐私计算节点的合约称为链下合约;当然,无论是链上合约还是链下合约,其本质都是一段可以在虚拟机内执行的代码。
链下合约在执行过程中,可能需要依赖于外部数据。这里的外部数据区别于链上数据,并且该外部数据不包括链下隐私计算节点维护的数据。因此,本说明书通过提供外部数据的访问方案,使得链下隐私计算系节点能够安全、可靠地获得外部数据。
图1是本说明书一示例性实施例示出的一种链下隐私计算节点侧的访问外部数据的方法的流程图。如图1所示,该方法可以包括以下步骤。
步骤102,链下隐私计算节点在链下可信执行环境中执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求,在所述链下可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机。
在通过调用请求来调用链下隐私计算节点上部署的链下合约之前,需要将链下合约安全部署至该链下隐私计算节点处。链下合约可由某个客户端完成部署。上述的调用请求可能是区块链节点响应于某个客户端发起的交易而产生,这里发起交易的客户端与上述部署链下合约的客户端可以为同一客户端,或者不同的客户端。
客户端在确定链下隐私计算节点可信的情况下,可以向链下隐私计算节点部署链下合约。如前所述,链下隐私计算节点可以创建链下TEE,而针对链下合约的部署操作和调用操作均通过该链下TEE实现,从而确保操作过程中的数据安全和隐私保护。在链下隐私计算节点上创建的链下TEE,与前文所述的区块链节点上创建的链上TEE相似,都是基于CPU硬件实现的与外部完全隔离的可信执行环境。客户端通过获取针对链下隐私计算节点上创建的链下TEE的远程证明报告,验证该链下隐私计算节点是否可信,具体指该链下隐私计算节点上部署的链下TEE是否可信。
远程证明报告产生于针对链下隐私计算节点上的链下TEE的远程证明过程。远程证明报告由认证服务器对链下隐私计算节点产生的自荐信息进行验证后生成,该自荐信息与链下隐私计算节点上创建的链下TEE相关。链下隐私计算节点通过产生与链下TEE相关的自荐信息,并由认证服务器对该自荐信息进行验证后产生远程证明报告,使得远程证明报告可以用于表明链下隐私计算节点上的链下TEE可信任。例如,以Intel SGX技术为例,链下TEE为链下隐私计算节点上创建的用于实现链下隐私计算的enclave,远程证明过程还涉及到链下隐私计算节点上另一个特殊的enclave,即quoting enclave(简称QE),QE是由英特尔提供并签名的架构型enclave(Architectural Enclave)。上述enclave首先需要生成一用于本地认证的REPORT(报告)结构,并由QE基于该REPORT结构验证该enclave是否与自身处于同一平台上,而后由QE将该REPORT结构封装为 一结构体QUOTE(即自荐信息),并使用EPID(enhanced privacy identification)密钥进行签名。EPID密钥不仅代表链下隐私计算节点这一平台,还代表链下隐私计算节点的底层硬件的可信度,还可以绑定处理器固件的版本等信息,并且只有QE才能访问到EPID密钥,以用于对上述的结构体QUOTE进行签名。在SGX技术中,上述的认证服务器可以为英特尔公司提供的IAS(Intel Attestation Service)服务器,链下隐私计算节点向IAS服务器发送经过签名的上述结构体QUOTE,使得IAS服务器可以对签名进行验证,并向链下隐私计算节点返回相应的远程证明报告。
链下隐私计算节点创建链下TEE后,产生用于实现远程证明的自荐信息,该自荐信息可以用于锚定和固化链下TEE的信息,使得最终得到的包含该自荐信息的远程证明报告可以用于表征链下TEE的状态,并用于验证该链下TEE是否可信。例如,自荐信息中可以包含第一待检验哈希值,该第一待检验哈希值为链下TEE的预设信息的哈希值,比如该预设信息可以包括链下TEE内部署的所有代码、该链下TEE的开发者的公钥等。以Intel SGX技术为例,对应于链下TEE内部署的所有代码所生成的哈希值为MREnclave,对应于链下TEE的开发者的公钥所生成的哈希值为MRSigner,即第一待检验哈希值可以包括MREnclave和MRSigner。
仍以Intel SGX技术为例。如前所述,链下隐私计算节点向IAS服务器发送经过签名的结构体QUOTE后,由IAS服务器根据所维护的公钥集合进行签名验证,并向链下隐私计算节点返回远程证明报告(即AVR报告),该远程证明报告中包含:结构体QUOTE和签名验证结果,并且IAS服务器采用自身持有的私钥对该远程证明报告进行签名。
相应地,客户端在获取远程证明报告后,可以首先根据IAS服务器的公钥对该远程证明报告进行签名验证,如果验证通过则表明该远程证明报告确实由IAS服务器生成,且在数据传输过程中未被篡改或丢失数据。客户端可以通过任意途径获得IAS服务器的公钥,譬如远程证明报告被提供至客户端时,还可以关联提供IAS的证书链,使得客户端可以从该证书链中提取IAS服务器的公钥。然后,客户端可以从远程证明报告中提取结构体QUOTE和签名验证结果。客户端可以首先查看签名验证结果,如果签名验证结果为通过验证,表明链下隐私计算节点的CPU持有由Intel提供的私钥,因而链下TEE建立在可靠的硬件平台上,可以继续执行其他验证操作;如果签名验证结果为未通过验证,客户端可以判定链下隐私计算平台不可靠,无需继续其他验证操作。然后,客户端可以从结构体QUOTE内提取上述的哈希值MREnclave和MRSigner,即待检验MREnclave和待检验MRSigner;同时,客户端预先获得了链下TEE的MREnclave和MRSigner的可信值,比如称之为可信MREnclave和可信MRSigner,并将待检验MREnclave与可信MREnclave进行比较、将待检验MRSigner与可信MRSigner进行比较。那么,客户端可以将“待检验MREnclave与可信MREnclave一致,且待检验MRSigner与可信MRSigner一致”作为确认链下隐私计算节点可信的前提条件;换言之,如果待检验MREnclave与可信MREnclave不一致,或者待检验MRSigner与可信MRSigner不一致,客户端就判定链下隐私计算节点不可信,而如果客户端设定的所有前提条件都被满足,就可以确认链下隐私计算节点可信。此外,客户端对于签名验证结果进行验证的操作,与针对待检验MREnclave和待检验MRSigner进行验证的操作之间,并不存在必然的先后顺序,两者之间可以完全独立。
除了MREnclave和MRSigner之外,客户端还可以通过其他的前提条件对链下隐私计算节点的可信度进行验证。例如,链下隐私计算节点在创建链下TEE后,可以在链下TEE内生成代表自身的身份信息的密钥对,并且链下隐私计算节点在链下TEE中创建自身的节点身份信息,该节点身份信息与上述对应于身份信息的密钥对相关,比如该节点身份信息可以包含该密钥对中的公钥。其中,代表身份信息的密钥对可以存在一组或多组,比如一组密钥对为用于签名与验签的密钥对(即签名密钥对),一组密钥对为 用于加密与解密的密钥对(即加密密钥对),则节点身份信息可以包括签名密钥对中的签名公钥和加密密钥对中的加密公钥。在一组密钥对中,对应于不同的加密算法,可能同时存在多个公钥,这些公钥均被包含于上述的节点身份信息中。此外,节点身份信息还可以包含其他与链下隐私计算节点相关的信息,比如软件版本、所在域名、所在分区名等,本说明书并不对此进行限制。那么,链下隐私计算节点在生成结构体QUOTE时,可以计算上述节点身份信息的哈希值,并将该哈希值作为第二待检验哈希值添加至结构体QUOTE中。
相应地,客户端在收到远程证明报告后,可以从该远程证明报告进行签名验证。在签名验证通过的情况下,客户端可以提取远程证明报告所含的签名验证结果和第二待检验哈希值,并分别予以验证,且对于两者的验证并不存在必然的先后顺序,两者之间可以完全独立。假定客户端首先验证签名验证结果,并在签名验证结果为通过验证的情况下,继续对第二待检验哈希值进行验证。为了对第二待检验哈希值进行验证,客户端需要获取链下隐私计算节点的节点身份信息,比如远程证明报告被提供至客户端的同时,可以关联提供节点身份信息,当然客户端也可以通过其他方式或在其他时刻获得该节点身份信息。然后,客户端可以对获得的节点身份信息进行哈希计算,将计算得到的哈希值与上述的第二待检验哈希值进行比较,并将比较结果一致作为确认链下隐私计算节点可信的前提条件。如果第二待检验哈希值通过验证,可以证明链下隐私计算节点的身份信息是在链下TEE内初始化生成,上述代表身份信息的密钥对中的私钥仅由链下隐私计算节点所拥有,且该链下隐私计算节点能够完成签名、加密通讯等操作。
以上列举了两种针对链下隐私计算节点进行验证时采用的判断条件,即针对第一待检验哈希值的验证、针对第二待检验哈希值的验证。还可以采用其他的判断条件,此处不再一一列举。在针对链下隐私计算节点进行可信验证时,可以选用上述的一个或多个判断条件。例如,可以同时针对第一待检验哈希值和第二待检验哈希值进行验证;或者,在一些情况下,可以仅验证第二待检验哈希值,而对第一待检验哈希值可以不验证或者部分验证。例如,客户端上可以设置信任等级,并根据信任等级确定是否验证或部分验证第一待检验哈希值,比如信任等级为0时,不需要验证第一待检验哈希值,信任等级为1时,验证第一待检验哈希值中的MRSigner,信任等级为2时,验证第一待检验哈希值中的MREnclave等。
在上述实施例中,节点身份信息包含了链下隐私计算节点的身份相关的信息,比如代表身份的公钥等。节点身份信息还可以包含与链下TEE相关的信息,那么对节点身份信息进行哈希计算,并将得到的待检验哈希值添加至结构体QUOTE时,该待检验哈希值相当于同时实现了上述第一待检验哈希值和第二待检验哈希值的作用。例如,节点身份信息除了包含签名公钥和加密公钥等信息之外,还可以包含MREnclave和MRSigner的值,使得对该节点身份信息进行哈希计算得到的待检验哈希值,同时与链下隐私计算节点的身份、链下TEE相关。相应的,客户端在收到远程证明报告后,可以从该远程证明报告进行签名验证。在签名验证通过的情况下,客户端可以提取远程证明报告所含的签名验证结果和待检验哈希值,并分别予以验证,且对于两者的验证并不存在必然的先后顺序,两者之间可以完全独立。假定客户端首先验证签名验证结果,并在签名验证结果为通过验证的情况下,继续对待检验哈希值进行验证。为了对待检验哈希值进行验证,客户端需要获取链下隐私计算节点的节点身份信息,此处不再赘述。然后,客户端可以对获得的节点身份信息进行哈希计算,将计算得到的哈希值与上述的待检验哈希值进行比较,并将比较结果一致作为确认链下隐私计算节点可信的前提条件。可见,本实施例仅需一次比较,即可实现前文中两方面的验证,有助于提升验证效率。
客户端对远程证明报告的验证过程,还可以包括其他操作,比如根据远程证明报告的内容确定链下TEE是否运行于测试模式(测试模式下存在数据泄露的风险)等,此处不再一一赘述。
客户端可以向链下隐私计算节点发起挑战,并接收链下隐私计算节点返回的远程证明报告,从而可以根据远程证明报告确定链下隐私计算节点是否可信。例如,客户端可以向链下隐私计算节点发起链下挑战,即发起挑战的过程与区块链网络无关,这样可以跳过区块链节点之间的共识过程、减少链上链下的交互操作,使得客户端向链下隐私计算节点的挑战具有更高的操作效率。再例如,客户端可以采用链上挑战的形式,比如客户端可以向区块链节点提交挑战交易,该挑战交易所含的挑战信息可由区块链节点通过预言机机制传输至链下隐私计算节点,且该挑战信息用于向链下隐私计算节点发起挑战。
本说明书中通过预言机机制实现将数据从链上传递至链下或者从链下传递至链上的操作。本说明书中将预言机合约与预言机服务器之间的配合机制称为预言机机制。比如,上文中基于预言机机制实现的链上挑战;以及,下文中基于预言机机制实现的链上调用等。其中,客户端向区块链节点提交的交易可以直接或间接调用预言机合约,以触发预言机机制。其中,如果将预言机合约的合约地址填入该交易的to字段,表明该交易直接调用了预言机合约;如果将某一链上合约的合约地址填入该交易的to字段,且该链上合约调用了预言机合约,表明该交易间接调用了预言机合约。链上合约调用预言机合约,一种情况下可以是在链上合约的字节码中预先写入了预言机合约的合约地址,另一种情况下可以是将预言机合约的合约地址作为调用该链上合约时的入参,并将该入参填入上述交易的data字段。除了将调用请求或其他数据从链上传递至链下,预言机机制还可以将数据从链下传递至链上,具体可由预言机服务器将链下数据传递至预言机合约,然后由预言机合约将链下数据传递至数据需求方,比如这里的链下数据可以包括调用链下合约所产生的隐私计算结果等。在上述的预言机机制中,将数据从链上传递至链下可以视为“请求”过程,将数据从链下传递至链上可以视为“响应”过程,这两个过程通常成对出现。
链下隐私计算节点可能属于链下隐私计算集群,该链下隐私计算集群包含多个链下隐私计算节点。如果各个链下隐私计算节点之间完全独立,那么客户端与单个链下隐私计算节点之间的交互过程可以参考上文所述的实施例。而另一种方式下,链下隐私计算集群可以包含一控制节点,并由该控制节点对集群内的所有链下隐私计算节点进行统一管理。比如,客户端可以向控制节点发起挑战,并接收控制节点返回的上述链下隐私计算节点的远程证明报告。与前述实施例相类似的,客户端可以向控制节点发起链下挑战,或者客户端可以向区块链节点提交挑战交易,该挑战交易所含的挑战信息由区块链节点通过预言机机制传输至控制节点,使得控制节点向客户端返回链下隐私计算节点的远程证明报告。
无论是链下挑战或链上挑战,链下隐私计算节点在收到客户端发起的挑战后,均可以临时触发如前文所述的远程证明过程并产生相应的远程证明报告,然后将远程证明报告反馈至客户端。或者,链下隐私计算节点在收到客户端发起的挑战时,如果本地已经存在预先生成的远程证明报告,那么链下隐私计算节点将该远程证明报告提供至客户端,而无需临时触发远程证明过程。其中,链下隐私计算节点本地存在的远程证明报告,可以是该链下隐私计算节点响应于除客户端之外的其他挑战者的挑战而触发产生,比如该其他挑战者可以包括其他客户端、链下隐私计算节点所处的链下隐私计算集群中的控制节点、KMS服务器等,本说明书并不对此进行限制。因此,链下隐私计算节点在收到客户端发起的挑战后,可以首先查看本地是否存在先前生成的远程证明报告,如果存在则将该远程证明报告反馈至客户端,否则临时触发远程证明过程。其中,远程证明报告可以具有一定的时限性,比如30分钟或其他时长,超时的远程证明报告可以被客户端认定为失效,链下隐私计算节点也可以主动清除已失效的远程证明报告以避免反馈至客户端。
基于上述方案,客户端在确定链下隐私计算节点可信的情况下,可以向链下隐私 计算节点部署链下合约。与前述的挑战过程相类似的,客户端可以通过链下途径将链下合约的字节码加密传输至链下隐私计算节点,或者,客户端可以通过链上途径将链下合约的字节码加密传输至链下隐私计算节点,比如客户端生成链下合约部署交易,该链下合约部署交易中包含对字节码进行加密得到的字节码密文,客户端将链下合约部署交易加密后提交至区块链节点,加密后的链下合约部署交易可在区块链节点处创建的链上TEE内被解密、得到字节码密文,然后由区块链节点通过预言机机制将该字节码密文传输至链下隐私计算节点。在将字节码加密传输至链下隐私计算节点时,与前述的挑战过程类似,可以直接加密传输至链下隐私计算节点,也可以通过控制节点实现转发。
链下隐私计算节点可以在链下TEE中解密得到明文的字节码后,可以在链下TEE中对字节码进行重新加密后,存储至链下TEE之外的存储空间,比如链下隐私计算节点的硬盘中,从而完成对链下合约的部署。此处,链下隐私计算节点通常采用一对称密钥,通过对称加密的方式对字节码进行加密并存储,这样在后续调用该字节码时,相比于采用非对称加密的形式而言,可以更快地完成解密操作。该对称密钥可由链下隐私计算节点在链下TEE中生成,或者由其他对象通过加密传输的方式分发至链下隐私计算节点。例如,可由KMS服务器对链下隐私计算节点发起挑战,并通过远程证明验证该链下隐私计算节点可信的情况下,向该链下隐私计算节点分发上述的对称密钥。链下隐私计算节点可以将KMS服务器分发的对称密钥作为根密钥,并将基于该根密钥派生得到的衍生密钥应用于针对字节码的加密存储。再例如,基于Intel SGX技术,上述对称密钥可以为烧录于链下隐私计算节点的CPU内e-fuses存储电路中的RSK(Root Seal Key)密钥,或者该RSK密钥派生得到的衍生密钥(即Seal Key)。当然,链下隐私计算节点也可以采用非对称加密或者对称加密与非对称加密结合的方式,对字节码进行加密存储,本说明书并不对此进行限制。
针对链下隐私计算节点处已经部署的链下合约,区块链节点在执行客户端发起的交易的过程中,可以通过如前所述的调用请求,对该链下合约进行调用,以实现链下隐私计算。例如图2所示,调用链下合约的过程可以包括:步骤①,客户端21向区块链网络22提交一笔交易,该交易可由区块链网络中的某一节点例如节点22n接收并执行;步骤②,节点22n通过执行接收到的交易,形成链下合约调用请求;步骤③,预言机服务器23通过预言机机制获得调用请求,并发送至链下隐私计算节点24。
针对客户端21提交的交易,节点22n可以将该交易与其他节点进行共识后上链,对客户端21提交的交易进行存证。但是,如果客户端21并不希望自己的行为被其他用户随意获知,可以对交易进行隐私保护。客户端21可以对提交的交易进行加密,而节点22n可以接收经过加密的交易,这样可以确保传输过程中不会造成交易的内容泄露。节点22n处可以部署链上TEE,并且节点22n可以将经过加密的交易读入该链上TEE后,在链上TEE内解密,可以确保解密得到的挑战交易仅存在于链上TEE内、不会外泄。
客户端21生成的交易中可以直接包含经过加密的调用请求,那么节点22n可以在链上TEE内解密交易、得到调用请求密文,然后节点22n可以通过预言机机制将该调用请求密文传输至链下隐私计算节点。或者,客户端21生成的交易中可以包含明文的调用请求,那么客户端21通常需要对交易进行加密传输,并确保节点22n在链上TEE内解密得到明文的调用请求后,再在链上TEE内对调用请求进行加密,然后通过预言机机制将加密后的调用请求传输至链下隐私计算节点24。或者,客户端21生成的交易中并未包含调用请求,而节点22n在链上TEE内执行该交易调用的链上合约的过程中,主动在链上TEE内生成调用请求。
链下隐私计算节点处可以部署很多链下合约。调用请求中可以包含所需调用的链下合约的标识信息,以便链下隐私计算节点实现准确调用。调用请求中可以包含入参数据的信息,比如该入参数据本身或入参数据的存储地址等,使得链下隐私计算节点可以 通过链下TEE内部署的虚拟机执行链下合约,以针对入参数据进行处理。例如,入参数据的存储地址可能属于某一远程服务器,则链下隐私计算节点需要通过本说明书的外部数据访问方案,获取该入参数据以便完成链下合约的执行。再例如,链下隐私计算节点在执行链下合约以处理入参数据的过程中,可能需要某一远程服务器所提供的外部数据,则可以通过本说明书的外部数据访问方案来获取该外部数据。
针对调用请求的加密传输,可以采用对称加密或非对称加密的形式。通过对调用请求进行加密传输可以确保传输过程中不会造成调用请求的内容泄露。假定调用请求由客户端生成并加密:
当采用对称加密时,客户端和链下隐私计算节点分别维护有相同的对称密钥,比如该对称密钥可由客户端与链下隐私计算节点通过诸如DH(Diffie-Hellman)或ECDH(Elliptic Curve Diffie–Hellman)等算法协商得到,或者由KMS(Key Management Service,密钥管理服务)服务器分发至客户端和节链下隐私计算节点,本说明书并不限制密钥来源。当密钥由KMS服务器分发时,KMS服务器可以在客户端对链下隐私计算节点进行远程证明的过程中,将密钥传输至客户端处。那么,客户端可以通过上述的对称密钥对调用请求进行加密,而链下隐私计算节点将对称密钥维护于链下TEE中,因而链下隐私计算节点接受到由区块链节点传输的调用请求,链下隐私计算节点将经过加密的调用请求读入链下TEE内,并通过该对称密钥执行解密操作得到上述的调用请求,并进行相关的计算。对称加密采用的加密算法,例如可以包括DES算法,3DES算法,TDEA算法,Blowfish算法,RC5算法,IDEA算法等。
当采用非对称加密时,链下隐私计算节点维护有节点非对称密钥的私钥,比如称之为链下节点私钥,而客户端可以获得该链下隐私计算节点的链下节点公钥。非对称密钥可由链下隐私计算节点在链下TEE内生成,或者由KMS服务器分发至该链下隐私计算节点,本说明书并不限制密钥来源。类似地,当密钥由KMS服务器分发时,KMS服务器可以在客户端对链下隐私计算节点进行远程证明的过程中,将链下节点公钥传输至客户端处。那么,客户端可以通过链下节点公钥对调用请求进行加密,而链下隐私计算节点将链下节点私钥维护于链下TEE中,因而将经过加密的调用请求读入链下TEE内,并通过链下节点私钥执行解密操作得到上述的调用请求。非对称加密采用的非对称加密算法,例如可以包括RSA、Elgamal、背包算法、Rabin、D-H、ECC(椭圆曲线加密算法)等。
针对调用请求的加密传输,还可以采用对称加密与非对称加密相结合的形式。客户端可以维护一对称密钥,比如该对称密钥可由客户端随机生成,且客户端可以获得上述节点非对称密钥中的公钥。客户端可以通过对称密钥对调用请求进行加密、得到加密后调用请求,并通过非对称密钥加密该对称密钥、得到加密后密钥,然后客户端同时将加密后挑战交易与加密后密钥传输至链下隐私计算节点。相应的,链下隐私计算节点将加密后调用请求与加密后密钥读入链下TEE内,首先通过链下节点私钥对加密后密钥进行解密、得到对称密钥,然后通过对称密钥对加密后调用请求进行解密。相比较而言,对称加密的加解密效率相对更高、但安全性相对较低,而非对称加密的加解密效率相对较低、但安全性相对更高,因此基于对称加密与非对称加密相结合的形式,可以兼顾加解密效率与安全性。
类似地,在本说明书所涉及的其他数据交互过程中,通过使得数据发送方与数据接收方之间维护相同的对称密钥,或者使得数据发送方维护有非对称密钥的公钥、数据接收方维护有非对称密钥的私钥,或者结合对称加密与非对称加密的形式,可以实现任意的数据发送方与数据接收方之间的数据加密传输,此处不再赘述。
链下隐私计算节点可能属于链下隐私计算集群,该链下隐私计算集群包含多个链下隐私计算节点。如果各个链下隐私计算节点之间完全独立,那么客户端与单个链下隐私计算节点之间的交互过程可以参考上文所述的实施例。而另一种方式下,链下隐私计 算集群可以包含一控制节点,并由该控制节点对集群内的所有链下隐私计算节点进行统一管理。比如,客户端可以向控制节点发送调用请求,并接收控制节点返回的上述链下隐私计算节点的链下隐私计算结果。
在链下隐私计算节点属于链下隐私计算集群的情况下,这些链下隐私计算节点可以生成统一的身份信息,比如称为集群身份信息。集群身份信息可以包括集群加密密钥对和集群签名密钥对,上述的各个链下隐私计算节点均需在各自的链下TEE内维护集群加密私钥、集群签名私钥。那么客户端或区块链节点只要使用集群加密公钥对调用请求进行加密,即可确保上述的各个链下隐私计算节点均能够在各自的链下TEE内通过集群加密私钥进行解密,从而调用请求。基于集群身份,客户端并不需要关注对方为单个链下隐私计算节点或者链下隐私计算集群,只需要将其作为一个对象并与该对象进行交互即可,无需关注于背后的节点或集群的细节。
除了链下隐私计算节点可以存在统一的集群身份之外,可以为链下隐私计算节点上部署的链下合约生成合约身份。当集群内存在多个链下隐私计算节点时,每个链下隐私计算节点可以为自身已部署的链下合约建立合约身份,且不同链下隐私计算节点针对同一链下合约生成的合约身份相同。例如,链下隐私计算节点可以根据统一的集群身份和链下合约的合约ID,为链下合约生成相应的合约身份,由于集群身份相同、而不同链下合约的合约ID必然不同,因而可以确保:同一链下隐私计算节点上部署的不同链下合约存在不同的合约身份,而不同链下隐私计算节点上部署的同一链下合约存在相同的合约身份。
合约身份可由合约身份密钥对所定义。例如,合约身份可以包括合约加密密钥对和合约签名密钥对。那么,除了采用集群身份公钥对调用请求进行加密之外,还可以采用合约加密公钥对调用请求内所含的入参数据的信息进行加密。链下隐私计算节点在收到针对某一链下合约的调用请求后,采用该链下合约对应的合约加密私钥对调用请求内加密后的入参数据的信息进行解密,从而确保入参数据的信息只能由被调用的链下合约所获得,而不会被其他链下合约获得。以及,在得到调用结果后,链下隐私计算节点可以通过被调用的链下合约的合约签名私钥对调用结果进行签名,而客户端或区块链节点可以通过合约签名公钥进行验签,从而确定该调用结果确实是由被调用的链下合约所产生。
链下隐私计算节点所创建的链下TEE与外部隔离,在链下TEE执行链下合约的过程中,链下TEE无法直接实现外部访问以获得所需的外部数据。因此,本说明书中可以通过预言机协助链下TEE,使得链下TEE能够在确保安全性的前提下获得所需的外部数据。以图2为例,链下隐私计算节点24在执行链下合约的过程中,如果存在外部数据访问请求,可以通过步骤④创建外部数据访问请求,并发送至预言机25,触发预言机25对远程服务器进行访问,并返回相应的外部数据请求响应。
链下合约的字节码中可以定义有外部数据访问接口。链下隐私计算节点在链下TEE中执行链下合约的过程中,通过调用该外部数据访问接口可以生成相应的外部数据访问请求。链下合约中可以包含多个函数,并非每个函数都必须调用外部数据访问接口。同时,即便某一函数能够调用外部数据访问接口,也并非在每次执行时都必然会调用,比如可以在上述的调用请求中包含用于指示是否调用外部数据访问接口的入参,从而基于该入参的取值来确定是否调用外部数据访问接口。
链下隐私计算节点可以对外部数据访问请求的访问行为进行限制。例如,可以将允许进行访问的IP地址写入预设的白名单中,并将外部数据访问请求的目标访问对象的IP地址与该白名单进行匹配,从而仅允许针对该白名单记录的IP地址进行访问;类似地,也可以将不允许进行访问的IP地址写入预设的黑名单,并将外部数据访问请求的目标访问对象的IP地址与该黑名单进行匹配,从而禁止针对该黑名单记录的IP地址进行访问。再例如,可以在配置文件中记录对外部数据访问请求的字段限制和内容限制, 从而避免外部数据访问请求中包含敏感字段或敏感内容等。因此,在生成外部数据访问请求后,可以对外部数据访问请求中的字段进行检查,在检测到外部数据访问请求中存在不符合访问要求的字段或请求内容,或者目的IP地址未处于预设白名单的情况下,禁止执行访问外部数据的操作。
链下隐私计算节点与预言机所支持的数据格式可能不同,造成链下隐私计算节点所生成的外部数据访问请求,可能无法被预言机顺利识别,进而造成对外部数据访问失败。因此,链下隐私计算节点在执行链下合约产生第一格式的外部数据访问请求后,可以主动将第一格式的外部数据访问请求转换为第二格式,而本步骤加密传输至预言机的即为转换为第二格式的外部数据访问请求。相应地,在预言机返回第二格式的外部数据请求响应后,链下隐私计算节点可以主动将第二格式的外部数据请求响应转换为第一格式,然后对该第一格式的外部数据请求响应予以处理。
在本说明书中,链下隐私计算节点向预言机发送外部数据访问请求的过程中,或者预言机向链下隐私计算节点返回外部数据请求响应的过程中,涉及到设备之间的数据交互。如前所述,可以通过对称加密、非对称加密或两者结合的方式,对外部数据访问请求和外部数据请求响应分别进行加密传输。其中,链下隐私计算节点处创建了链下TEE,预言机处创建了预言机TEE,可以确保对外部数据访问请求和外部数据请求响应的加密、解密操作均在TEE中实现,因而可以在数据交互的各个环节均确保了极高的安全性。
在实际应用中,预言机可以为单一的预言机节点,也可以为包含有多个预言机节点的预言机集群。其中,在预言机包含多个预言机节点的情况下,预言机集群中包含控制节点,以及控制节点以外的预言机节点。在基于非对称加密或数字信封(即对称加密与非对称加密结合)的方式进行数据交互的过程中,链下隐私计算节点用于加密的公钥可以为预言机加密公钥,而相应的预言机加密私钥可以由上述的单一预言机节点所持有、代表该单一预言机节点的身份,或者该预言机加密私钥可以由上述预言机集群中的某一预言机节点所持有、代表该预言机节点的身份,或者该预言机加密私钥可以由上述预言机集群中的所有预言机节点所共同持有、代表这些预言机节点的集群身份,或者该预言机加密私钥可以由上述预言机集群中的控制节点所持有、代表该控制节点的身份。
在上述预言机加密公钥对应于单一预言机节点,或者预言机集群中某一预言机节点的身份的情况下,链下隐私计算节点在链下TEE内基于该单一预言机节点的加密公钥对外部数据访问请求进行加密,并将加密后的外部数据访问请求发送至该预言机节点,以由该预言机节点基于维护的预言机加密私钥进行解密。
当预言机加密公钥对应于预言机集群中某一预言机节点的身份时,链下隐私计算节点与该预言机节点可以直接交互,那么其过程与单一预言机节点的情况无异。链下隐私计算节点可以根据自身的需求,从预言机集群中选取某一预言机节点;或者,链下隐私计算节点可以与预言机集群的控制节点进行协商,以确定由集群中哪一预言机节点对外部数据访问请求进行处理,而链下隐私计算节点采用该预言机节点对应的预言机加密公钥进行加密。在一种实施方式中,链下隐私计算节点可以在需要访问外部数据的情况下,先向控制节点请求一预言机节点用于处理本次外部数据访问请求,在接收到控制节点的请求响应后,基于响应中的信息确定分配的预言机节点,并基于该预言机节点对应的预言机加密公钥对外部数据访问请求进行加密。在另一实施方式中,可以由控制节点主动向链下隐私计算节点发送分配的预言机节点。比如,控制节点可以按照预设周期确定集群中预言机节点的性能状况,并基于负载均衡算法将性能状况较好的预言机节点作为该时间段用于处理外部数据访问请求的预言机节点,并主动将该预言机节点的信息告知链下隐私计算节点。在这种机制下,在该时间段内,所有外部数据访问请求均通过该预言机节点对应的预言机加密公钥进行加密,控制节点将所有接收到的外部数据访问请求发送至该预言机节点进行处理。当然,控制节点也可以同时确定出的多个预言机节点, 链下隐私计算节点可以从中选取一预言机节点,并采用被选取的预言机节点对应的预言机加密公钥对外部数据访问请求进行加密,并且链下隐私计算节点可以向控制节点告知被选取的预言机节点的信息,比如该预言机节点对应的预言机加密公钥或其哈希值,或者控制节点为该预言机节点分配的节点ID等,使得控制节点在接收到该外部数据访问请求后可以准确转发至上述被选取的预言机节点。
如前所述,在预言机集群场景下,预言机加密私钥可由该预言机集群的控制节点维护。在这种情况下,加密后的外部数据访问请求被发送至该控制节点,并由该控制节点解密后,转发至所述预言机集群内的预言机节点进行处理,使得链下隐私计算节点无需关注于预言机集群内的节点数量和各个节点的身份等,可以将预言机集群作为一个整体的“预言机”进行交互,可以简化交互过程。其中,控制节点在对外部数据访问请求解密后,可以随机或基于负载均衡算法从预言机集群内选取一预言机节点,采用对应于该被选取的预言机节点的身份的公钥在TEE内对外部数据访问请求进行重新加密,并将重新加密后的外部数据访问请求发送至该预言机节点,由该预言机节点在创建的预言机TEE内根据对应于自身身份的私钥进行解密和处理,且对应于该预言机节点的身份的公私钥对被创建于该预言机TEE内。
步骤104,所述链下隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密。
预言机根据接收到的外部数据访问请求,对远程服务器予以访问,以获取相应的访问结果。例如图2所示,访问过程可以包括下述步骤:步骤⑤,预言机25基于外部数据访问请求向远程服务器26发起访问;步骤⑥,远程服务器26向预言机25返回访问结果;步骤⑦,预言机25基于访问结果创建外部数据请求响应,并返回至链下隐私计算节点24。外部数据访问请求中可以包含目标数据和远程服务器26的信息,预言机25可以据此访问远程服务器26并获取相应的目标数据,以作为上述的访问结果;或者,外部数据访问请求中可以仅包含目标数据的信息,而预言机25可以根据该目标数据的信息确定相应的远程服务器26,并针对该远程服务器26予以访问。预言机25在接收到远程服务器26返回的访问结果后,可以基于接收到的访问结果创建对应的外部数据请求响应。
链下隐私计算节点可以预先验证预言机是否可信,比如可以通过远程证明的方式对预言机创建的预言机TEE进行验证,如果验证通过则表明预言机具有可靠的硬件平台和软件环境,确定预言机可信。在此基础上,链下隐私计算节点可以在本地存储预言机的预言机签名公钥,以用于上述的验签操作;反之,如果预言机被验证为不可信,链下隐私计算节点不会在本地存储预言机签名公钥,那么上述的验签操作将无法实施,也就不会将收到的外部数据请求响应用于链下合约的后续操作。
上述的预言机可以为单个预言机节点,链下隐私计算节点可以直接与该预言机节点进行交互,以获取该预言机节点对应的远程证明报告。或者,上述的预言机可以为预言机集群,该预言机集群内的每个预言机节点分别创建预言机TEE,而链下隐私计算节点可以获取集群内所有预言机节点分别对应的远程证明报告,以用于验证各个预言机节点所创建的预言机TEE是否可信。例如,可以由控制节点向各个预言机节点发起挑战的方式获得。具体的,控制节点可以向集群中的各个预言机节点发起挑战,各个预言机节点分别生成与预言机TEE相关的自荐信息并发送至认证服务器,以由认证服务器对自荐信息进行验证后生成相应的远程证明报告,并将该报告返回至对应的预言机节点,各个预言机节点在接收到远程证明报告后向控制节点转发,而控制节点将远程证明报告转发至链下隐私计算节点。
链下隐私计算节点可以分别对获取的每份远程证明报告进行验证,验证过程可以参考前文所述的远程证明过程的相关描述,差异仅在于挑战方与被挑战方的变化,此处 不再赘述。根据远程证明报告,如果链下隐私计算节点确认某一预言机节点可信,那么该链下隐私计算节点将在本地存储该预言机节点对应的预言机签名公钥;换言之,链下隐私计算节点在本地存储所有被验证为可信的预言机节点对应的预言机签名公钥,而不会存储被验证为不可信的预言机节点对应的预言机签名公钥。如前所述,预言机节点可以维护有代表自身身份的预言机加密私钥,而预言机签名私钥与预言机加密私钥类似,同样由预言机节点在自身创建的预言机TEE内生成,并且可以代表该预言机节点的身份。
预言机可以基于预言机签名私钥对创建的外部数据请求响应进行签名。相应地,链下隐私计算节点可以基于预先获取的预言机签名公钥对接收到的外部数据请求响应进行验签。如果验签成功,表明收到的外部数据请求响应确实来自预言机,并且在传输过程中未发生数据丢失等异常情况,即收到的外部数据请求响应可信,因而链下隐私计算节点可以在验签成功的情况下,根据外部数据请求响应完成对链下合约的后续操作。而在链下隐私计算节点仅在本地维护被验证为可信的预言机节点对应的预言机签名公钥的情况下,验签成功可以确保处理外部数据访问请求的预言机节点为预先验证过的可信节点,避免不可信的预言机节点进行冒充,有助于提升数据安全性。
对于同一预言机节点而言,如果该预言机节点存在对应的预言机加密密钥对和预言机签名密钥对,该预言机加密密钥对和预言机签名密钥对可以为同一密钥对,也可以为不同密钥对。而在本说明书的技术方案中,如果链下隐私计算节点在对外部数据访问请求进行加密的过程中,采用的公钥是预言机集群中的控制节点对应的预言机加密公钥,那么由于外部数据请求响应必然由某一预言机节点生成,因而此时所涉及的预言机加密密钥对与预言机签名密钥对必然不是同一密钥对。
预言机向链下隐私计算节点发送外部数据请求响应时,针对该外部数据请求响应进行加密传输。针对外部数据请求响应的加密传输过程,与前述的针对调用请求的加密传输过程类似,数据接收方均为链下隐私计算节点,只是数据发送方变为了预言机。与针对调用请求的加密传输过程相类似,针对外部数据请求响应进行加密传输时,可以采用对称加密、非对称加密或两者结合的数字信封等方式。并且,当采用非对称加密或数字信封的形式时,需要使用链下节点公钥,而相应的链下节点私钥可以仅由作为接收方的该链下隐私计算节点所维护、代表该链下隐私计算节点的节点身份,也可以代表该链下隐私计算节点所处的链下隐私计算集群的集群身份、由集群内的所有链下隐私计算节点共同维护。
步骤106,所述链下隐私计算节点在所述链下可信执行环境内解密获得所述外部数据请求响应,根据所述外部数据请求响应完成对所述链下合约的执行操作。
在完成对链下合约的执行操作之后,还可以将执行结果加密反馈至区块链节点。例如图2所示,该过程可以包括以下步骤:步骤⑧,链下隐私计算节点24基于外部数据请求响应完成链下合约的执行操作,并将执行结果反馈至预言机服务器23;步骤⑨,预言机服务器23将执行结果转发至区块链网络中的节点22n,以由区块链节点22n基于该执行结果完成对链上合约的执行操作;步骤⑩,区块链节点22n完成链上合约的执行操作后,向客户端21返回链上合约的执行结果。在图2所示的实施例中,区块链节点22n用于实现链下交互的预言机服务器23、链下隐私计算节点24用于访问外部数据的预言机25具有不同标识,这是为了便于体现出区块链节点22n、链下隐私计算节点24所面临的交互对象、交互数据等所存在的差异,但实际上预言机服务器23与预言机25在物理结构上可以部署于同一设备,也可以部署于不同设备,本说明书并不对此进行限制。
由上述技术方案可知,本说明书的技术方案在检测到链下合约的执行过程中存在外部数据访问需求的情况下,可以通过预言机向远程服务器发起访问,进而获得需要的外部数据以完成链下合约的执行。通过在链下隐私计算节点处创建链下TEE、在预言机 处创建预言机TEE,并且在链下隐私计算节点与预言机之间实现加密的数据传输,使得链下合约、外部数据访问请求、外部数据请求响应都只在TEE内才处于明文状态,而在TEE外均处于密文状态,从而在实现外部数据访问的同时,能够确保数据安全性并满足隐私保护的需求。
对应于上述链下隐私节点侧的实施例,本说明书还提出了预言机侧、预言机集群中的控制节点侧等其他方面的实施例,在链下隐私计算节点侧实施例中所涉及的描述同样可以适用于这些侧的实施例,下文中不再对此进行赘述。
相应的,图3是本说明书一示例性实施例示出的一种预言机侧的访问外部数据的方法的流程图。如图3所示,该方法可以包括以下步骤。
步骤302,预言机接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点响应于链下合约的外部数据访问需求而发起;所述链下合约在被区块链节点调用的情况下,由所述链下隐私计算节点在链下可信执行环境内执行。
如前所述,该预言机可以为单一预言机节点,也可以为包含多个预言机节点的预言机集群(包含控制节点,以及控制节点以外的预言机节点)。链下隐私计算节点用于加密的预言机加密公钥可以为单一预言机节点的加密公钥或预言机集群中控制节点以外的预言机节点的加密公钥,也可以为预言机集群中控制节点的加密公钥。
如前所述,预言机可以接收链下隐私计算节点在链下TEE内基于预言机加密公钥加密的外部数据访问请求,并基于预言机加密私钥对接收到的外部数据访问请求进行解密。其中,上述预言机加密公钥可以为单一预言机节点的加密公钥,也可以为预言机集群中控制节点以外的预言机节点的加密公钥。
如前所述,在预言机加密公钥为单一预言机节点的情况下,链下隐私计算节点在链下TEE内基于该单一预言机节点的加密公钥对外部数据访问请求进行加密,并将加密后的外部数据访问请求发送至该单一预言机节点,以由该单一预言机节点基于维护的加密私钥进行解密。
如前所述,在预言机加密公钥为预言机集群中控制节点以外的预言机节点的加密公钥的情况下,链下隐私计算节点在链下TEE内基于任一预言机节点的加密公钥对外部数据访问请求进行加密,并将加密后的外部数据访问请求发送至预言机集群中的控制节点,并由控制节点将加密的外部数据访问请求转发至该任一预言机节点,以由该任一预言机节点基于维护的加密私钥进行解密。
如前所述,预言机集群中的控制节点可以接收链下隐私计算节点在链下TEE内基于预言机加密公钥加密的外部数据访问请求,并基于该控制节点维护有的预言机加密私钥对所述加密后的外部数据访问请求解密后转发至所述预言机集群内的预言机节点进行处理。在该实施方式中,链下隐私计算节点用于加密外部数据访问请求的预言机加密公钥为控制节点的加密公钥;其中,基于控制节点维护有的预言机加密私钥对所述加密后的外部数据访问请求解密后转发至所述预言机集群内的预言机节点进行处理可以包括:基于控制节点维护的加密私钥对接收到的外部数据访问请求进行解密,并基于任一预言机节点的加密公钥对外部数据访问请求进行重新加密,并向该任一预言机节点转发重新加密的外部数据访问请求。
如前所述,链下隐私计算节点与预言机可能支持不同的数据编码格式。因此,链下隐私计算节点在生成第一格式的外部数据访问请求后可以将其转换为第二格式。换言之,预言机接收到的链下隐私计算节点发送的第二格式的外部数据访问请求由链下隐私计算节点对第一格式的外部数据访问请求转换得到;而第一格式的外部数据访问请求在执行链下合约的情况下产生。
步骤304,所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器。
步骤306,所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述链下隐私计算节点;所述外部数据请求响应用于在所述链下可信执行环境内解密后参与所述链下合约的执行操作。
如前所述,预言机在基于访问结果创建外部数据请求响应后,还可以基于维护的预言机签名私钥对该外部数据请求响应进行签名,以向链下隐私计算节点证明该外部数据请求响应的可靠性。
如前所述,为了使链下隐私计算节点能够基于预先维护的预言机的签名公钥对带有签名的外部数据请求响应进行验签,需要预先获取预言机签名公钥。为此,还可以包括对预言机进行远程证明的过程。其中,在该预言机为预言机节点的情况下,预言机签名私钥由该预言机节点维护;该预言机节点可以向链下隐私计算节点返回远程证明报告;该远程证明报告由认证服务器对该预言机节点产生的自荐信息进行验证后生成,该自荐信息与该预言机节点上创建的TEE相关;在根据该远程证明报告确定预言机节点可信的情况下,预言机签名公钥被所述链下隐私计算节点保存在本地。在该预言机为预言机集群的情况下,预言机签名私钥由集群中响应于外部数据访问请求的预言机节点维护;预言机集群中的控制节点向链下隐私计算节点返回集群中各个预言机节点的远程报告证明,每一远程证明报告由认证服务器对相应预言机节点产生的自荐信息进行验证后生成,所述自荐信息与相应预言机节点上创建的TEE相关;在根据所述远程证明报告确定出可信预言机节点的情况下,所述可信预言机节点的预言机签名公钥被所述链下隐私计算节点保存在本地。
如前所述,在基于访问结果创建外部数据请求响应后,预言机可以采用链下节点公钥对创建的外部数据请求响应进行加密,并将加密的外部数据请求响应返回给所述链下隐私计算节点,以由链下隐私计算节点基于链下节点私钥对加密的外部数据请求响应进行解密。其中,在链下隐私计算节点属于链下隐私计算集群的情况下,链下节点私钥仅被所述链下隐私计算节点所维护,或者链下节点私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
如前所述由于预言机采用第二格式对数据进行编码,因此,基于访问结果创建的外部数据请求响应也采用第二格式;该第二格式的外部数据请求响应在返回至链下隐私计算节点后,将由链下隐私计算节点转换为第一格式的外部数据请求响应;链下隐私计算节点可以基于所述第一格式的外部数据请求响应完成对所述链下合约的执行操作。
相应的,图4是本说明书一示例性实施例示出的一种预言机控制节点侧的访问外部数据的方法的流程图。如图4所示,该方法可以包括以下步骤。
步骤402,预言机集群中的控制节点接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点在链下可信执行环境内执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求而发起。
如前所述,链下隐私计算节点基于控制节点的加密公钥对外部数据访问请求进行加密,控制节点在接收到链下隐私计算节点发送的外部数据访问请求的情况下,在控制节点TEE中基于维护的控制节点加密私钥对接收到的外部数据访问请求进行解密。
步骤404,所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问。
如前所述,控制节点在接收到外部数据访问请求后,可以在集群中选取一可信节点作为处理本次外部数据访问请求的预言机节点(该可信节点即为本步骤中被选取的预言机节点);并可以在控制节点TEE中基于该可信节点的加密公钥对外部数据访问请求进行重新加密,并将重新加密后的外部数据访问请求发送至该可信节点。
步骤406,所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经 过加密的外部数据请求响应返回所述链下隐私计算节点。
如前所述,被选取的预言机节点在接收到控制节点发送的重新加密后的外部数据访问请求后,可以在被选预言机TEE中基于自身维护的加密私钥(即该可信节点的加密私钥)进行解密;并基于解密后的外部数据访问请求向相应的远程服务器发起访问。
如前所述,在接收到远程服务器返回的访问结果后,该被选取的预言机节点可以在TEE中基于该访问结果创建外部数据请求响应,并用该被选取的预言机的签名私钥进行签名;该签名后的外部数据访问请求在链下隐私计算节点基于预先获取的预言机公钥(即该被选取的预言机的加密公钥)验签后,用于完成对链下合约的执行操作。
如前所述,链下隐私计算节点可以通过多种方式获取被选取预言机的加密公钥。例如,可以由控制节点向链下隐私计算节点发送远程报告证明;远程证明报告由链下隐私计算节点进行验证后,将所述远程证明对应的预言机节点确定为可信节点;所述可信节点的公钥信息被链下隐私计算节点保存在本地。在一种实施方式中,链下隐私计算节点可以预先获取预言机集群中所有可信节点的公钥信息。此时,可以由控制节点向链下隐私计算节点发送集群中所有预言机节点对应的远程证明报告;由链下隐私计算节点对接收到远程证明报告进行验证,并将验证成功的远程证明报告对应的预言机节点确定为可信节点,并将所有可信节点的签名公钥信息在本地保存。
如前所述,可以由控制节点接收集群中预言机节点的远程证明报告,并基于远程证明报告确定预言机节点是否为可信节点;在接收到链下隐私计算节点发送的外部数据访问请求的情况下,控制节点可以基于负载均衡的原则分配一可信节点用于处理该外部数据访问请求。
在本说明书的技术方案中,还可以在隐私计算节点执行智能合约的过程中,执行对外部数据进行访问等操作,而无需在区块链通过预言机机制来调用隐私计算节点中的智能合约的情况下,才执行访问外部数据的操作,同时隐私计算节点对于智能合约的执行结果也无需反馈至区块链。在该情况下,由于不涉及链上和链下的区分,下文将“链下隐私计算节点”称为“隐私计算节点”,将“链下可信执行环境”称为“节点可信执行环境”,将“链下合约”称为“智能合约”。但是,技术方案的原理与上述实施例类似,所涉及的实施细节比如隐私计算节点对可信执行环境的创建过程、隐私计算节点对远程证明报告的生成过程、客户端对远程证明报告的验证过程、对字节码的加解密方案、预言机访问外部数据等,同样可参考上述实施例,因此下文不再进行详细描述。
图5是本说明书一示例性实施例示出的一种隐私计算节点侧的访问外部数据的方法的流程图。如图1所示,该方法可以包括以下步骤。
步骤502,隐私计算节点在节点可信执行环境中执行智能合约的过程中,在所述节点可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机。
如前所述,在隐私计算节点执行智能合约之前,需要将智能合约安全部署至该隐私计算节点处。智能合约可由某个客户端完成部署。上述的智能合约可能是响应于某个客户端发起的交易而执行,这里发起交易的客户端与部署智能合约的客户端可以为同一客户端,或者不同的客户端。
如前所述,隐私计算节点向预言机发送外部数据访问请求的过程中,或者预言机向隐私计算节点返回外部数据请求响应的过程中,涉及到设备之间的数据交互。可以通过对称加密、非对称加密或两者结合的方式,对外部数据访问请求和外部数据请求响应分别进行加密传输。
如前所述,隐私计算节点在将外部数据访问请求传输至预言机的过程中,可以在节点可信执行环境内基于预言机加密公钥对外部数据访问请求进行加密,并将加密后的外部数据访问请求发送至所述预言机。其中,该预言机可以包括维护有预言机加密私钥的预言机节点;或者,在该预言机为预言机集群的情况下,预言机加密私钥由预言机集 群的控制节点维护,加密后的外部数据访问请求被控制节点解密后转发至预言机集群内的预言机节点进行处理。
如前所述,隐私计算节点与预言机所支持的数据格式可能不同,造成隐私计算节点所生成的外部数据访问请求,可能无法被预言机顺利识别,进而造成对外部数据访问失败。因此,隐私计算节点在执行智能合约产生第一格式的外部数据访问请求后,可以主动将第一格式的外部数据访问请求转换为第二格式,而本步骤加密传输至预言机的即为转换为第二格式的外部数据访问请求。相应地,在预言机返回第二格式的外部数据请求响应后,隐私计算节点可以主动将第二格式的外部数据请求响应转换为第一格式,然后对该第一格式的外部数据请求响应予以处理。
如前所述,隐私计算节点可以对外部数据访问请求的访问行为进行限制。例如,可以将允许进行访问的IP地址写入预设的白名单中,并将外部数据访问请求的目标访问对象的IP地址与该白名单进行匹配,从而仅允许针对该白名单记录的IP地址进行访问;类似地,也可以将不允许进行访问的IP地址写入预设的黑名单,并将外部数据访问请求的目标访问对象的IP地址与该黑名单进行匹配,从而禁止针对该黑名单记录的IP地址进行访问。再例如,可以在配置文件中记录对外部数据访问请求的字段限制和内容限制,从而避免外部数据访问请求中包含敏感字段或敏感内容等。因此,在生成外部数据访问请求后,可以对外部数据访问请求中的字段进行检查,在检测到外部数据访问请求中存在不符合访问要求的字段或请求内容,或者目的IP地址未处于预设白名单的情况下,禁止执行访问外部数据的操作。
步骤504,所述隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密。
如前所述,所述外部数据请求响应由预言机签名私钥进行签名;所述隐私计算节点在接收到所述外部数据访问请求后,可以基于预先获取的预言机签名公钥对所述外部数据请求响应进行验签。其中,所述隐私计算节点在确认验签成功的情况下,根据所述外部数据请求响应完成对所述智能合约的执行操作。
如前所述,在所述预言机为预言机节点的情况下,预言机签名私钥由所述预言机节点维护;所述隐私计算节点还可以获取针对所述预言机节点的远程证明报告,所述远程证明报告由认证服务器对所述预言机节点产生的自荐信息进行验证后生成,所述自荐信息与所述预言机节点上创建的可信执行环境相关;在根据所述远程证明报告确定所述预言机节点可信的情况下,所述隐私计算节点将预言机签名公钥在本地保存;
如前所述,在所述预言机为预言机集群的情况下,预言机签名私钥由集群中响应于所述外部数据访问请求的预言机节点维护;所述隐私计算节点还可以分别获取针对集群中各个预言机节点的远程证明报告,每一远程证明报告由认证服务器对相应预言机节点产生的自荐信息进行验证后生成,所述自荐信息与相应预言机节点上创建的可信执行环境相关;所述隐私计算节点根据所述远程证明报告确定出可信的预言机节点,并将相应的预言机签名公钥在本地保存。
如前所述,预言机向隐私计算节点发送外部数据请求响应时,针对该外部数据请求响应进行加密传输。针对外部数据请求响应的加密传输过程,与前述的针对调用请求的加密传输过程类似,数据接收方均为隐私计算节点,只是数据发送方变为了预言机。与针对调用请求的加密传输过程相类似,针对外部数据请求响应进行加密传输时,可以采用对称加密、非对称加密或两者结合的数字信封等方式。并且,当采用非对称加密或数字信封的形式时,需要使用节点公钥,而相应的节点私钥可以仅由作为接收方的该隐私计算节点所维护、代表该链下隐私计算节点的节点身份,也可以代表该隐私计算节点所处的隐私计算集群的集群身份、由集群内的所有隐私计算节点共同维护。
步骤506,所述隐私计算节点在所述节点可信执行环境内解密获得所述外部数据请 求响应,根据所述外部数据请求响应完成对所述智能合约的执行操作。
如前所述,在所述隐私计算节点接收到外部数据访问请求后,可以将获取到的第二格式的外部数据请求响应转换为第一格式的外部数据请求响应;所述隐私计算节点基于所述第一格式的外部数据请求响应完成对所述智能合约的执行操作。
对应于上述隐私节点侧的实施例,本说明书还提出了预言机侧、预言机集群中的控制节点侧等其他方面的实施例,在隐私计算节点侧实施例中所涉及的描述同样可以适用于这些侧的实施例,下文中不再对此进行赘述。
相应的,图6是本说明书一示例性实施例示出的另一种预言机侧的访问外部数据的方法的流程图。如图6所示,该方法可以包括以下步骤。
步骤602,预言机接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起。
如前所述,该预言机可以为单一预言机节点,也可以为包含多个预言机节点的预言机集群(包含控制节点,以及控制节点以外的预言机节点)。隐私计算节点用于加密的预言机加密公钥可以为单一预言机节点的加密公钥或预言机集群中控制节点以外的预言机节点的加密公钥,也可以为预言机集群中控制节点的加密公钥。
如前所述,预言机可以接收隐私计算节点在节点TEE内基于预言机加密公钥加密的外部数据访问请求,并基于预言机加密私钥对接收到的外部数据访问请求进行解密。其中,上述预言机加密公钥可以为单一预言机节点的加密公钥,也可以为预言机集群中控制节点以外的预言机节点的加密公钥。
如前所述,在预言机加密公钥为单一预言机节点的情况下,隐私计算节点在节点TEE内基于该单一预言机节点的加密公钥对外部数据访问请求进行加密,并将加密后的外部数据访问请求发送至该单一预言机节点,以由该单一预言机节点基于维护的加密私钥进行解密。
如前所述,在预言机加密公钥为预言机集群中控制节点以外的预言机节点的加密公钥的情况下,隐私计算节点在节点TEE内基于任一预言机节点的加密公钥对外部数据访问请求进行加密,并将加密后的外部数据访问请求发送至预言机集群中的控制节点,并由控制节点将加密的外部数据访问请求转发至该任一预言机节点,以由该任一预言机节点基于维护的加密私钥进行解密。
如前所述,预言机集群中的控制节点可以接收隐私计算节点在节点TEE内基于预言机加密公钥加密的外部数据访问请求,并基于该控制节点维护有的预言机加密私钥对所述加密后的外部数据访问请求解密后转发至所述预言机集群内的预言机节点进行处理。在该实施方式中,隐私计算节点用于加密外部数据访问请求的预言机加密公钥为控制节点的加密公钥;其中,基于控制节点维护有的预言机加密私钥对所述加密后的外部数据访问请求解密后转发至所述预言机集群内的预言机节点进行处理可以包括:基于控制节点维护的加密私钥对接收到的外部数据访问请求进行解密,并基于任一预言机节点的加密公钥对外部数据访问请求进行重新加密,并向该任一预言机节点转发重新加密的外部数据访问请求。
如前所述,隐私计算节点与预言机可能支持不同的数据编码格式。因此,隐私计算节点在生成第一格式的外部数据访问请求后可以将其转换为第二格式。换言之,预言机接收到的隐私计算节点发送的第二格式的外部数据访问请求由隐私计算节点对第一格式的外部数据访问请求转换得到;而第一格式的外部数据访问请求在执行智能合约的情况下产生。
步骤604,所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器。
步骤606,所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述隐私计算节点;所述外部数据请求响 应用于在所述节点可信执行环境内解密后参与所述智能合约的执行操作。
如前所述,预言机在基于访问结果创建外部数据请求响应后,还可以基于维护的预言机签名私钥对该外部数据请求响应进行签名,以向隐私计算节点证明该外部数据请求响应的可靠性。
如前所述,为了使隐私计算节点能够基于预先维护的预言机的签名公钥对带有签名的外部数据请求响应进行验签,需要预先获取预言机签名公钥。为此,还可以包括对预言机进行远程证明的过程。其中,在该预言机为预言机节点的情况下,预言机签名私钥由该预言机节点维护;该预言机节点可以向隐私计算节点返回远程证明报告;该远程证明报告由认证服务器对该预言机节点产生的自荐信息进行验证后生成,该自荐信息与该预言机节点上创建的TEE相关;在根据该远程证明报告确定预言机节点可信的情况下,预言机签名公钥被所述隐私计算节点保存在本地。在该预言机为预言机集群的情况下,预言机签名私钥由集群中响应于外部数据访问请求的预言机节点维护;预言机集群中的控制节点向隐私计算节点返回集群中各个预言机节点的远程报告证明,每一远程证明报告由认证服务器对相应预言机节点产生的自荐信息进行验证后生成,所述自荐信息与相应预言机节点上创建的TEE相关;在根据所述远程证明报告确定出可信预言机节点的情况下,所述可信预言机节点的预言机签名公钥被所述隐私计算节点保存在本地。
如前所述,在基于访问结果创建外部数据请求响应后,预言机可以采用节点公钥对创建的外部数据请求响应进行加密,并将加密的外部数据请求响应返回给所述隐私计算节点,以由隐私计算节点基于节点私钥对加密的外部数据请求响应进行解密。其中,在隐私计算节点属于隐私计算集群的情况下,节点私钥仅被所述隐私计算节点所维护,或者节点私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
如前所述由于预言机采用第二格式对数据进行编码,因此,基于访问结果创建的外部数据请求响应也采用第二格式;该第二格式的外部数据请求响应在返回至隐私计算节点后,将由隐私计算节点转换为第一格式的外部数据请求响应;隐私计算节点可以基于所述第一格式的外部数据请求响应完成对所述智能合约的执行操作。
相应的,图7是本说明书一示例性实施例示出的另一种预言机控制节点侧的访问外部数据的方法的流程图。如图7所示,该方法可以包括以下步骤。
步骤702,预言机集群中的控制节点接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起。
如前所述,隐私计算节点基于控制节点的加密公钥对外部数据访问请求进行加密,控制节点在接收到隐私计算节点发送的外部数据访问请求的情况下,在控制节点TEE中基于维护的控制节点加密私钥对接收到的外部数据访问请求进行解密。
步骤704,所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问。
如前所述,控制节点在接收到外部数据访问请求后,可以在集群中选取一可信节点作为处理本次外部数据访问请求的预言机节点(该可信节点即为本步骤中被选取的预言机节点);并可以在控制节点TEE中基于该可信节点的加密公钥对外部数据访问请求进行重新加密,并将重新加密后的外部数据访问请求发送至该可信节点。
步骤706,所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经过加密的外部数据请求响应返回所述隐私计算节点。
如前所述,被选取的预言机节点在接收到控制节点发送的重新加密后的外部数据访问请求后,可以在被选预言机TEE中基于自身维护的加密私钥(即该可信节点的加密私钥)进行解密;并基于解密后的外部数据访问请求向相应的远程服务器发起访问。
如前所述,在接收到远程服务器返回的访问结果后,该被选取的预言机节点可以在TEE中基于该访问结果创建外部数据请求响应,并用该被选取的预言机的签名私钥进行签名;该签名后的外部数据访问请求在隐私计算节点基于预先获取的预言机公钥(即该被选取的预言机的加密公钥)验签后,用于完成对智能合约的执行操作。
如前所述,隐私计算节点可以通过多种方式获取被选取预言机的加密公钥。例如,可以由控制节点向隐私计算节点发送远程报告证明;远程证明报告由隐私计算节点进行验证后,将所述远程证明对应的预言机节点确定为可信节点;所述可信节点的公钥信息被隐私计算节点保存在本地。在一种实施方式中,隐私计算节点可以预先获取预言机集群中所有可信节点的公钥信息。此时,可以由控制节点向隐私计算节点发送集群中所有预言机节点对应的远程证明报告;由隐私计算节点对接收到远程证明报告进行验证,并将验证成功的远程证明报告对应的预言机节点确定为可信节点,并将所有可信节点的签名公钥信息在本地保存。
如前所述,可以由控制节点接收集群中预言机节点的远程证明报告,并基于远程证明报告确定预言机节点是否为可信节点;在接收到隐私计算节点发送的外部数据访问请求的情况下,控制节点可以基于负载均衡的原则分配一可信节点用于处理该外部数据访问请求。
下面以单一预言机节点为例,结合图8和图9对本说明书的技术方案进行介绍。其中,图8是本说明书一示例性实施例示出的一种基于单一预言机节点访问外部数据的示意图,图9是本说明书一示例性实施例示出的一种基于单一预言机节点访问外部数据的交互图。如图9所示,将单一预言机节点称为预言(Oracle)节点,交互过程可以包括步骤901~步骤913。
步骤901,链下隐私计算节点执行链下合约。
链下合约被预先部署于链下隐私计算节点处。链下隐私计算节点在链下TEE中对链下合约的字节码进行加密后,存储至链下TEE的外部,比如硬盘中。链下隐私计算节点可以响应于接收到的调用请求,从调用请求中读取需要调用的链下合约的合约ID,并根据该合约ID查找相应的链下合约的加密后字节码,将该加密后字节码读入链下TEE内,然后在链下TEE内解密得到明文的字节码。
链下TEE中部署有链下合约的执行引擎,比如EVM(以太坊虚拟机)、WASM虚拟机或其他类型的虚拟机。链下隐私计算节点通过链下TEE内的虚拟机执行上述的字节码,即执行上述的链下合约。如果链下TEE中部署了多种类型的执行引擎,通常链下隐私计算节点在部署链下合约时,还会记录用于执行该链下合约的虚拟机的信息,以确保在该链下合约被调用时,采用正确的虚拟机执行该链下合约。链下合约可能包含多个函数。调用请求中可以包含函数名,以指示链下隐私计算节点通过虚拟机仅执行该函数名对应的函数,而非链下合约的所有字节码。
针对链下合约的调用请求,可以来源于区块链节点,比如区块链节点接收客户端提交的一笔交易,并在执行该交易的过程中产生链下隐私计算需求,从而通过预言机机制向链下隐私计算节点传输调用请求。或者,针对链下合约的调用请求还可以来源于客户端,比如客户端通过链下渠道直接将调用请求发送至链下隐私计算节点。
步骤902,链下隐私计算节点创建外部数据访问请求。
在开发人员编译链下合约的过程中,可以在链下合约中定义外部数据访问接口,该外部数据访问接口可由链下合约中的一个或多个函数所调用。在执行链下合约的过程中,通过调用该外部数据访问接口,可使链下隐私计算节点创建上述的外部数据访问请求,以实现针对外部数据的访问操作。
外部数据访问请求中可以包含所要访问的远程服务器的IP地址,以及所要访问的内容(比如存储地址、关键词等)。出于安全性的考量,链下隐私计算节点处可以预先配置有安全文件,该安全文件用于对产生的外部数据访问请求进行安全过滤。比如,安 全文件中可以包含对外部数据访问请求的字段限制、访问内容限制、IP地址限制等中的一种或多种。其中,字段限制和访问内容限制可以基于安全文件对外部数据访问请求中的字段进行检查实现,比如,当检测到外部数据访问请求中存在不符合访问要求的字段或请求内容时,不允许进行访问外部数据的执行操作;IP地址限制可以基于IP白名单实现,比如当外部数据访问请求中的目的IP地址不在该IP白名单内时,不允许进行访问外部数据的执行操作。
开发人员可以根据预先定义的外部数据访问请求模型编译生成链下合约,使得链下合约可以支持符合该模型的外部数据访问请求。例如,当该模型为HTTPS请求模型时,链下合约所创建的外部数据访问请求为相应的HTTPS请求。HTTPS模型包括HTTP模型和SSL模型。在HTTP模型中可以包含远程服务器地址、远程服务器的端口、请求方法(如GET/POST)、访问资源的路径、版本协议、HTTPS请求头、HTTPS请求体等信息;在SSL模型中则可以包含信任的远程服务器的CA根证书、与远程服务器建立TLS连接所使用的客户端证书以及该证书对应的Key值等信息。其中,远程服务器的地址和端口等字段的取值,可以在链下合约中定义,使得相应生成的外部数据访问请求中必然包含链下合约中定义的上述远程服务器的地址和端口,即链下合约所定义的远程服务器为固定服务器;或者,远程服务器的地址和端口可以在链下合约中定义为空,并由调用请求中包含的参数所定义,使得相应生成的外部数据访问请求中包含由调用请求所指示的远程服务器的地址和端口,即链下合约所定义的远程服务器不固定。
如果预言节点并不支持上述的HTTPS协议或者链下隐私计算节点所产生的其他协议的外部数据访问请求,则链下隐私计算节点还需要对创建的外部数据访问请求进行格式转换,以使预言节点能够顺利处理接收到的外部数据访问请求。为实现格式转换的功能,可以预先设置一格式转换接口,并可以在需要进行格式转换时,通过调用该接口进行格式转换。举例而言,该格式转换接口可以用于指示预言(Oracle)编码模型,该编码模型中包含预言编码格式(即前文中的第二格式)的通用字节码,在转换过程中只需将创建的采用链下节点编码格式(即前文中的第一格式)的外部数据访问请求中的特定信息复制到该预言编码模型中即可。当然,该转换方式仅是示意性的,具体如何实现格式转换可以由本领域技术人员根据实际情况确定。
步骤903,链下隐私计算节点创建的外部数据访问请求进行加密。
在本实施例中,由于只存在单一预言节点,因此链下隐私计算节点将该预言节点的加密公钥读入链下TEE内,并基于该加密公钥在链下TEE中对创建的外部数据访问请求进行加密。
步骤904,链下隐私计算节点向预言节点发送加密后的外部数据访问请求。
步骤905,预言节点对接收到的外部数据访问请求进行解密。
在本实施例中,预言节点基于自身维护的加密私钥,在该预言节点所创建的TEE内对接收到的外部数据访问请求进行解密。
步骤906,预言节点基于外部数据访问请求创建远程服务器访问请求。
由于在步骤902中已经将外部数据访问请求转化为预言编码格式,因此,预言节点在步骤905对外部数据访问请求解密后,可以直接读取该外部数据访问请求中的数据,并根据该外部数据访问请求的内容向远程服务器发起访问。例如,预言节点可以包括基于读取的远程服务器的IP地址、端口等信息创建远程服务器访问请求,以向远程服务器发起请求。
远程服务器访问请求中可以包含外部数据的信息,用于指示远程服务器获取相应的外部数据。预言节点可以在自身创建的TEE内对远程服务器访问请求进行加密,以避免在传输过程中暴露请求中所含的外部数据的信息。
步骤907,预言节点向远程服务器发送访问请求。
步骤908,远程服务器向预言节点返回访问结果。
步骤909,预言节点基于返回的访问结果创建外部数据请求响应。
如果远程服务器访问请求被加密,远程服务器需要将加密后的远程服务器访问请求读入自身创建的TEE内,并在该TEE内执行解密操作,以得到明文的远程服务器访问请求。
类似地,远程服务器可以在自身创建的TEE内对访问结果进行加密,然后将加密后的访问结果返回预言节点。在预言节点接收到远程服务器返回的访问结果后,可以在该预言节点创建的TEE内对访问结果进行解密,读取该访问结果中的数据,并基于读取的数据创建外部数据请求响应。
步骤910,预言节点对创建的外部数据请求响应进行加密并签名。
预言节点在创建外部数据请求响应后,还在TEE内通过预言节点的签名私钥进行签名,以及基于链下隐私计算节点的加密公钥对外部数据请求响应进行加密,然后传输至链下隐私计算节点。相应地,链下隐私计算节点可以通过解密和验签,确保得到的外部数据请求响应是否可靠。
为实现本步骤签名和加密的操作,需要对预言节点进行远程证明。为方便理解该远程证明的过程可参考图10。图10为本说明书一示例性实施例示出的一种对单一预言机节点进行远程证明的流程图。
由图10可知,在单一预言机的情况下,链下隐私计算节点对预言机节点进行远程证明主要包括以下几个步骤:步骤①,链下隐私计算节点向预言机节点发起挑战;步骤②,预言机节点接收到挑战信息后,生成与预言机TEE相关的自荐信息并发送给认证服务器;步骤③,认证服务器对预言机的自荐信息进行验证,并基于验证结果生成远程证明报告;并返回给预言机;步骤④,预言机将该远程证明报告转发给链下隐私计算节点,以由链下隐私计算节点基于该远程证明报告确定预言机节点是否可信。
在上述过程中,认证服务器在用自身的签名私钥对远程证明报告签名后再返回,以此证明该远程证明报告的可靠性(接收到该远程证明报告的设备可以基于该认证服务器的签名公钥验证该远程证明报告是否为认证服务器创建的)。其中,远程证明报告可以由预言机转发至链下隐私节点,也可以由认证服务器直接发送至链下隐私计算节点。链下隐私计算节点在接收到远程证明报告并基于认证服务器的公钥验签成功后,便可将预言机节点的签名公钥保存在本地,以用于对预言机返回的外部数据请求响应进行验签。
步骤911,预言节点向链下隐私计算节点返回加密的外部数据请求响应。
步骤912,链下隐私计算节点对接收到的外部数据请求响应进行验签并解密。
链下隐私计算节点接收到外部数据请求响应后,可以基于预先获取的预言机公钥进行验签,并在验签成功后基于自身维护的加密私钥对外部数据请求响应进行解密。在本步骤中,由于步骤910中先加密后验签,因此本步骤先进行验签后解密。本实施例采用这种顺序的原因在于,在验签失败的情况下,证明该请求响应本身不可靠,无需再进行解密等步骤;若步骤910中优先进行签名后进行加密,那么,本步骤中需要优先解密再进行验签,这种情况下,即使请求响应本身不可靠,仍需要对请求响应进行解密和验签两个步骤。当然,具体如何操作,本领域技术人员可以根据实际需求确定。
步骤913,链下隐私计算节点基于解密并验签后的外部数据请求响应完成链下合约的执行操作。
在从外部数据请求响应中获取到外部数据后,即可根据获取到的外部数据完成链下合约的执行操作。在链下合约执行完成后还可以通过图2中区块链下的预言机将执行结果反馈给区块链节点,以由区块链节点完成对链上合约的执行操作。
链下隐私计算节点也可以属于链下隐私计算集群。在这种情况下,区块链节点可以调用集群中任一可信的链下隐私计算节点执行链下合约。其中,链下隐私计算集群中通常包含一控制节点,也可以由该控制节点分配一可信节点作为执行链下合约的链下隐私计算节点,此时,若集群中任一可信节点需要访问外部数据即可通过控制节点与预言 机进行交互。
由上述技术方案可知,本说明书的技术方案可以在链下合约执行过程中检测到存在外部数据访问需求的情况下,可以由链下隐私计算节点通过单一预言机节点向远程服务器发起访问,并借助基于返回的访问结果创建的外部数据请求响应完成对链下合约的执行操作。
进一步的,在创建外部数据访问请求之前,链下隐私计算节点预先对预言机节点进行了远程证明,进而确保了预言机节点的可靠性。其次,链下隐私计算节点在基于远程证明确定预言机节点为可信节点的情况下,在本地保存有预言机节点的签名公钥,使得在接收到预言机节点返回的带有预言机签名的外部数据请求响应后,能够对其进行验签。通过这样的验签机制确保了数据的安全性和完整性。
再进一步的,在本实施例中,预言机节点的加密密钥对与签名密钥对可以为同一密钥对。这样的方式使得在保证数据安全性和完整性的前提下,简化了加解密以及签名验签的复杂程度。
下面以预言机为预言机集群为例,结合图11和图12对本说明书的技术方案进行介绍。其中,图11是本说明书一示例性实施例示出的一种基于预言机集群访问外部数据的示意图。图12是本说明书一示例性实施例示出的一种基于预言机集群访问外部数据的方法的交互图。如图12所示,在该方法中可以将预言机集群称为预言(Oracle)集群,集群中包含一控制节点,将集群中除控制节点以外的预言节点称为实体(Entity),该方法可以包括步骤1201~步骤1217。
步骤1201,链下隐私计算节点执行链下合约。
本步骤与步骤901相类似,可参照步骤901的介绍,在此不作赘述。
步骤1202,链下隐私计算节点创建外部数据访问请求。
本步骤与步骤902相类似,可参照步骤902的介绍,在此不作赘述。
步骤1203,链下隐私计算节点创建的外部数据访问请求,并用预言控制节点的加密公钥进行加密。
在本实施例中,与上一实施例不同的是,在上一实施例中,链下隐私计算节点将单一预言节点的加密公钥读入链下TEE内,并基于该加密公钥在链下TEE中对创建的外部数据访问请求进行加密;而在本实施例中,链下隐私计算节点将控制节点的加密公钥读入链下TEE内,并基于控制节点的加密公钥在链下TEE中对创建的外部数据访问请求进行加密。换言之,在上一实施例中,链下隐私计算节点基于实际处理外部数据访问请求的预言节点的加密公钥对外部数据访问请求进行加密;而在本实施例中,基于控制节点的加密公钥对外部数据访问请求进行加密,但控制节点本申请并不对外部数据访问请求进行处理。
通过这样的方式,链下隐私计算节点无需与控制节点预先协商由集群中哪一实体对外部数据访问请求进行处理,同时也无需采用该实体对应的预言机加密公钥进行加密。
步骤1204,链下隐私计算节点向预言控制节点发送加密后的外部数据访问请求。
步骤1205,预言控制节点基于控制节点加密私钥对接收到的外部数据访问请求进行解密。
在本实施例中,预言控制节点基于自身维护的加密私钥,在该控制节点所创建的TEE内对接收到的外部数据访问请求进行解密。除此之外,预言控制节点在接收到外部数据访问请求后,还需要给本次外部数据访问请求分配一实体用于处理本次外部数据访问请求。具体的,可参考图11所述的设备架构图。如图11所示,预言机集群中包括预言控制节点以及A、B、C…若干个实体。控制节点在接收到外部数据访问请求后,将实体A分配为处理本次外部数据访问请求的预言机节点,即向远程服务器发起访问等操作均由实体A执行,后续步骤中将以实体A为分配得到的实体对交互过程进行介绍。
其中,控制节点可以采用多种方式分配处理外部数据访问请求的实体。为方便表 述,后文中将该过程简称为分配实体。例如,可以随机或基于负载均衡算法从预言机集群中选取一实体用于处理本次外部数据访问请求。在本实施例中,控制节点基于负载均衡算法分配实体。具体的,控制节点可以在接收到外部数据访问请求的情况下,分别获取集群中每一实体的负载情况,并基于负载均衡算法将性能状况较好的实体作为负责本次处理外部数据访问请求的预言机节点。除此之外,控制节点也可以通过实时监控集群中各个实体负载情况,在接收到外部数据访问请求的情况下,基于负载均衡算法对已获取的负载情况确定出性能较好的实体。当然,上述举例仅是示意性的,具体的如何实现基于负载均衡算法分配实体可由本领域技术人员根据实际情况确定,在此不作限定。
在采用负载均衡算法分配实体之前,还需要确定集群中所有实体是否为可信节点。为此,需要预先对集群中各个实体进行远程证明。远程证明的方式可以通过多种方式实现。在本实施例中,可以采用如图10所述的方法对集群中的实体进行远程证明。
图13为本说明书一示例性实施例示出的一种对预言机集群中的预言机节点进行远程证明的流程图。该过程可以包括以下步骤:步骤①,由预言控制节点向集群中所有实体发起挑战;步骤②,集群中任一实体在接收到挑战信息后,生成与实体中TEE相关的自荐信息并发送给认证服务器;步骤③,认证服务器在接收到任一实体发送的自荐信息后,对自荐信息进行验证,并基于验证结果生成相应的远程证明报告并返回给该任一实体;步骤④,所有接收到认证服务器返回的远程证明报告的实体,将该远程证明报告返回给预言控制节点。预言控制节点在接收到所有远程证明报告后,对所有远程证明报告进行验证,并将验证成功的远程证明报告对应的实体确定为可信节点,在本实施例中,可以将所有确定为可信节点的实体组成的集群确定为可信集群。进一步的,链下隐私计算节点可以向预言控制节点请求获取远程证明报告,以由链下隐私计算节点验证预言集群中的实体是否可信;当链下隐私计算节点基于远程证明报告确定任一实体可信时,可以将该任一实体的签名公钥保存在本地。关于认证服务器如何证明远程证明报告可靠性的内容可参照步骤910中的介绍,在此不作赘述。
当然,除了由控制节点对集群中的实体发起挑战,也可以由链下隐私计算节点向控制节点发起挑战,再由控制节点向各个实体转发该挑战信息。具体获取远程证明报告的过程与控制节点发起挑战一致,在此不作赘述。
在通过上述方式确定集群中的实体均为可信节点的情况下,预言控制节点即可采用负载均衡算法分配实体。通过这样的方式,能够较好地平衡各个实体的负载情况,避免了单个实体负载过高的情况,进而提高整个集群性能的稳定性。
预言控制节点在基于控制节点加密私钥对外部数据访问请求解密并且分配实体后,预言控制节点可以基于分配得到的实体的加密公钥(在本实施例中,即为实体A的加密公钥)对外部数据访问请求进行加密。通过这样的方式,预言控制节点无需预先与链下隐私计算节点协商用于处理本次外部数据访问请求的实体,减少了交互次数,进而提高了访问效率。
步骤1206,预言控制节点基于实体A的加密公钥对外部数据访问请求重新加密。
为保证数据以密文的形式进行传输,并且能够被实体A解密,需要由预言控制节点基于预先获取的实体A的加密公钥对外部数据访问请求重新加密。
步骤1207,预言控制节点将重新加密后的外部数据访问请求发送至实体A。
步骤1208,实体A基于自身加密私钥对接收到的外部数据访问请求进行解密。
实体A基于自身维护的加密私钥,在实体A所创建的TEE内对接收到的外部数据访问请求进行解密。
步骤1209,实体A基于解密后的外部数据访问请求创建远程访问请求。
本步骤与步骤906相类似,可参照步骤906的介绍,在此不作赘述。
步骤1210,实体A向远程服务器发起访问。
步骤1211,远程服务器向实体A返回访问结果。
步骤1212,实体A基于接收到的访问结果创建外部数据请求响应。
本步骤除执行主体为实体A以外,与步骤909相类似,可参照步骤909的介绍,在此不作赘述。
步骤1213,实体A对创建的外部数据请求响应进行加密并签名。
实体A在创建外部数据请求响应后,还在TEE内通过实体A的签名私钥进行签名,以及基于链下隐私计算节点的加密公钥对外部数据请求响应进行加密,然后通过预言控制节点传输至链下隐私计算节点。相应地,链下隐私计算节点可以通过解密和验签,确保得到的外部数据请求响应是否可靠。
与上一实施例相类似,链下隐私计算节点需要预先对实体A进行远程证明。在实际操作中,链下隐私计算节点通常只与预言集群的控制节点交互,即链下隐私计算节点将预言机集群作为一个整体的“预言机”进行交互。因此,通常情况下,需要预先对预言集群中的所有实体进行远程证明。由于在本实施例中,预言控制节点可能已经预先对集群中的实体进行了远程证明(如步骤1205所述)。在这种情况下,当控制节点接收到链下隐私计算节点发送的远程证明报告获取请求时,只需将保留于控制节点中的所有实体对应的远程证明报告发送至链下隐私计算节点,链下隐私计算节点可以在接收到所有远程证明报告后验证预言集群中所有实体是否为可信节点,并将验证成功的可信节点的签名公钥保存在本地。换言之,在远程证明后,链下隐私计算节点中保存有所有可信实体的签名公钥。因此,无论外部数据请求响应由哪一实体返回,链下隐私计算节点均可以基于保存的签名公钥对接收到的外部数据请求响应进行验签。
值得注意的是,在链下隐私计算节点属于链下隐私计算集群的情况下,上述远程证明的过程可由链下隐私计算集群中的控制节点发起,在验证成功后,将信息同步至集群中所有链下隐私计算节点。当然,也可以由集群中任一链下隐私计算节点执行上述验证过程后,将验证信息同步至其他链下隐私计算节点;为了进一步确保验证的可靠性,还可以由集群中所有链下隐私计算节点分别进行验证。
步骤1214,实体A将加密后的外部数据请求响应发送至预言控制节点。
步骤1215,预言控制节点将加密的外部数据请求响应转发至链下隐私计算节点。
在链下隐私计算节点属于链下隐私计算集群的情况下,通常需要将该外部数据请求响应发送至链下隐私计算集群的控制节点,再由该控制节点转发至发送对应外部数据访问请求的链下隐私计算节点。
步骤1216,链下隐私计算节点对接收到的外部数据请求响应验签并解密。
在链下隐私计算节点本地保留有所有可信实体的签名公钥信息,可以利用其中实体A的签名公钥对接收到外部数据请求响应进行验签;以及基于自身维护的链下节点私钥对该外部数据请求响应进行解密。与上一实施例相类似,在实体A先对外部数据请求响应进行加密、后进行签名的情况下,在本步骤优先对外部数据请求响应进行验签,后进行解密。关于签名加密,以及验签解密的顺序介绍可参照步骤912的介绍,在此不作赘述。
步骤1217,链下隐私计算节点基于解密并验签后的外部数据请求响应完成链下合约的执行操作。
本步骤内容与步骤913相类似,可参照步骤913中相关介绍,在此不作赘述。值得注意的是,在本实施例中,链下隐私计算节点用于对外部数据访问请求进行加密的预言机加密公钥(属于控制节点),与链下隐私计算节点用于对外部数据请求响应进行验签的预言机签名私钥(属于实体A)一定不属于同一密钥对。
与上一实施例相比,由于本实施例引入了预言机集群的概念,使得链下隐私计算节点在访问外部数据的情况下,有更多可选择预言机节点。可以理解的是,在预言机集群中,若单一节点发生故障,仍可以通过预言机节点实现外部数据的访问。换言之,本实施例通过设置预言机集群的方式提高了传输的可靠性。
进一步的,在本实施例中,由于链下隐私计算节点基于控制节点的加密公钥对外部数据访问请求进行加密,使得链下隐私计算节点存在外部数据访问需求的情况下,无需预先与预言机控制节点协商(由集群中哪一预言机节点负责本次外部数据访问请求的处理),进而减少了交互的次数,提高了访问效率。
再进一步的,由于预言机控制节点预先对预言机集群中的所有预言机节点进行了远程证明,使得集群(前述可信预言机集群)中的预言机节点均为可信节点。这样的方式,使得在链下隐私计算节点有外部数据访问需求的情况下,预言机控制节点可以基于负载均衡原则分配用于处理本次外部数据访问请求的预言机节点。
图14是一示例性实施例提供的一种电子设备的示意结构图。请参考图14,在硬件层面,该设备包括处理器1402、内部总线1404、网络接口1406、内存1408以及非易失性存储器1410,当然还可能包括其他业务所需要的硬件。处理器1402从非易失性存储器1410中读取对应的计算机程序到内存1408中然后运行,在逻辑层面上形成访问外部数据的装置。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
请参考图15,在链下隐私计算节点侧的软件实施方式中,该访问外部数据的装置可以包括:请求单元1501,使链下隐私计算节点在链下可信执行环境中执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求,在所述链下可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机;响应单元1502,使所述链下隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密;反馈单元1503,使所述链下隐私计算节点在所述链下可信执行环境内解密获得所述外部数据请求响应,根据所述外部数据请求响应完成对所述链下合约的执行操作。
可选的,所述请求单元1501进一步用于:使所述链下隐私计算节点在链下可信执行环境内基于预言机加密公钥对所述外部数据访问请求进行加密,并将加密后的外部数据访问请求发送至所述预言机;其中,所述预言机包括维护有预言机加密私钥的预言机节点;或者,在所述预言机为预言机集群的情况下,所述预言机加密私钥由所述预言机集群的控制节点维护,加密后的外部数据访问请求被所述控制节点解密后转发至所述预言机集群内的预言机节点进行处理。
可选的,所述外部数据请求响应由预言机签名私钥进行签名;还包括:验签单元1504,使所述链下隐私计算节点基于预先获取的预言机签名公钥对所述外部数据请求响应进行验签;其中,所述链下隐私计算节点在确认验签成功的情况下,根据所述外部数据请求响应完成对所述链下合约的执行操作。
可选的,还包括:认证单元1505,在所述预言机为预言机节点的情况下,预言机签名私钥由所述预言机节点维护;使所述链下隐私计算节点获取针对该预言机节点的远程证明报告,所述远程证明报告由认证服务器对所述预言机节点产生的自荐信息进行验证后生成,所述自荐信息与所述预言机节点上创建的可信执行环境相关;在根据所述远程证明报告确定所述预言机节点可信的情况下,使所述链下隐私计算节点将预言机签名公钥在本地保存;在所述预言机为预言机集群的情况下,预言机签名私钥由集群中响应于所述外部数据访问请求的预言机节点维护;使所述链下隐私计算节点分别获取针对集群中各个预言机节点的远程证明报告,每一远程证明报告由认证服务器对相应预言机节点产生的自荐信息进行验证后生成,所述自荐信息与相应预言机节点上创建的可信执行环境相关;使所述链下隐私计算节点根据所述远程证明报告确定出可信的预言机节点,并将相应的预言机签名公钥在本地保存。
可选的,所述外部数据请求响应由预言机在预言机可信执行环境内采用链下节点 公钥进行加密;所述响应单元1502进一步用于:使所述链下隐私计算节点接收所述预言机加密返回的外部数据请求响应,并在链下可信执行环境中通过链下节点私钥对接收到的外部数据请求响应进行解密。
可选的,在所述链下隐私计算节点属于链下隐私计算集群的情况下,链下节点私钥仅被所述链下隐私计算节点所维护,或者链下节点私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
可选的,所述请求单元1501进一步用于:使所述链下隐私计算节点获取执行所述链下合约产生的第一格式的外部数据访问请求,并将获取到的外部数据访问请求转换为第二格式;使所述链下隐私计算节点将转换为第二格式的外部数据访问请求加密传输至预言机;所述反馈单元1503进一步用于:使所述链下隐私计算节点将获取到的第二格式的外部数据请求响应转换为第一格式的外部数据请求响应;使所述链下隐私计算节点基于所述第一格式的外部数据请求响应完成对所述链下合约的执行操作。
可选的,还包括:检查单元1506,使所述链下隐私计算节点对所述外部数据访问请求中的字段进行检查;在检测到所述外部数据访问请求中存在不符合访问要求的字段或请求内容,或者目的IP地址未处于预设白名单的情况下,禁止执行访问外部数据的操作。
请参考图16,在预言机侧的软件实施方式中,该访问外部数据的装置可以包括:接收单元1601,使预言机接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点响应于链下合约的外部数据访问需求而发起;所述链下合约在被区块链节点调用的情况下,由所述链下隐私计算节点在链下可信执行环境内执行;访问单元1602,使所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器;返回单元1603,使所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述链下隐私计算节点;所述外部数据请求响应用于在所述链下可信执行环境内解密后参与所述链下合约的执行操作。
可选的,所述接收单元1601进一步用于:在所述预言机为预言机节点的情况下,使所述预言机接收所述链下隐私计算节点在链下可信执行环境内基于预言机加密公钥加密的外部数据访问请求,并基于预言机加密私钥对接收到的外部数据访问请求进行解密;或者,在所述预言机为预言机集群的情况下,使所述预言机集群中的控制节点接收所述链下隐私计算节点在链下可信执行环境内基于预言机加密公钥加密的外部数据访问请求,并基于该控制节点维护有的预言机加密私钥请求集群内的节点对所述加密后的外部数据访问请求进行处理。
可选的,还包括:签名单元1604,使所述预言机基于预言机签名私钥对所述外部数据请求响应进行签名。
可选的,在所述预言机为预言机节点的情况下,预言机签名私钥由该预言机节点维护;所述返回单元1603进一步用于:使所述预言机向所述链下隐私计算节点返回远程证明报告;所述远程证明报告由认证服务器对该预言机节点产生的自荐信息进行验证后生成,所述自荐信息与该预言机节点上创建的可信执行环境相关;在根据所述远程证明报告确定预言机节点可信的情况下,预言机签名公钥被所述链下隐私计算节点保存在本地;在所述预言机为预言机集群的情况下,预言机签名私钥由集群中响应于所述外部数据访问请求的预言机节点维护;所述返回单元1603进一步用于:使所述预言机集群中的控制节点向所述链下隐私计算节点返回集群中各个预言机节点的远程报告证明,每一远程证明报告由认证服务器对相应预言机节点产生的自荐信息进行验证后生成,所述自荐信息与相应预言机节点上创建的可信执行环境相关;在根据所述远程证明报告确定出可信预言机节点的情况下,所述可信预言机节点的预言机签名公钥被所述链下隐私计算节点保存在本地。
可选的,所述返回单元1603进一步用于:使所述预言机采用链下节点公钥对创建的外部数据请求响应进行加密,并将加密的外部数据请求响应返回给所述链下隐私计算节点;所述加密的外部数据请求响应由所述链下隐私计算节点在接收后基于链下节点私钥进行解密。
可选的,在所述链下隐私计算节点属于链下隐私计算集群的情况下,链下节点私钥仅被所述链下隐私计算节点所维护,或者链下节点私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
可选的,所述接收单元1601进一步用于:使所述预言机接收链下隐私计算节点加密传输的外部数据访问请求,包括:使所述预言机接收所述链下隐私计算节点发送的第二格式的外部数据访问请求;所述第二格式的外部数据访问请求由所述链下隐私计算节点在执行所述链下合约的情况下产生的第一格式的外部数据访问请求转换得到;所述返回单元1603进一步用于,使所述将加密后的外部数据请求响应返回所述链下隐私计算节点,包括:使所述预言机将第二格式的外部数据请求响应返回所述链下隐私计算节点;所述第二格式的外部数据请求响应由所述链下隐私计算节点转换为第一格式的外部数据请求响应;所述链下隐私计算节点基于所述第一格式的外部数据请求响应完成对所述链下合约的执行操作。
请参考图17,在预言机控制节点侧的软件实施方式中,该访问外部数据的装置可以包括:请求接收单元1701,使预言机集群中的控制节点接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点在链下可信执行环境内执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求而发起;请求转发单元1702,使所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问;结果返回单元1703,使所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经过加密的外部数据请求响应返回所述链下隐私计算节点。
可选的,所述外部数据请求响应由所述被选取的预言机节点在预言机可信执行环境内创建,并由所述被选取的预言机通过预言机私钥进行签名;所述签名后的外部数据请求响应在所述链下隐私计算节点基于预先获取的预言机公钥验签后,用于完成对所述链下合约的执行操作。
可选的,还包括:报告发送单元1704,使所述控制节点向所述链下隐私计算节点发送远程证明报告;所述远程证明报告由所述链下隐私计算节点验证通过后,将所述远程证明对应的预言机节点确定为可信节点;所述可信节点的公钥信息被所述链下隐私计算节点保存在本地。
可选的,还包括:报告接收单元1705,使所述控制节点接收所述预言机集群中的预言机节点的远程证明报告,并基于所述远程报告证明验证所述预言机节点是否为可信节点;所述控制节点在接收到所述链下隐私计算节点发送的外部数据访问请求的情况下,基于负载均衡分配一可信节点用于处理该外部数据访问请求。
请参考图18,在隐私计算节点侧的软件实施方式中,该访问外部数据的装置可以包括:请求单元1801,使隐私计算节点在节点可信执行环境中执行智能合约的过程中,在所述节点可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机;响应单元1802,使所述隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密;反馈单元1803,使所述隐私计算节点在所述节点可信执行环境内解密获得所述外部数据请求响应,根据所述外部数据请求响应完成对所述智能合约的执行操作。
可选的,所述请求单元1801进一步用于:使所述隐私计算节点在节点可信执行环境内基于预言机加密公钥对所述外部数据访问请求进行加密,并将加密后的外部数据访问请求发送至所述预言机;其中,所述预言机包括维护有预言机加密私钥的预言机节点;或者,在所述预言机为预言机集群的情况下,所述预言机加密私钥由所述预言机集群的控制节点维护,加密后的外部数据访问请求被所述控制节点解密后转发至所述预言机集群内的预言机节点进行处理。
可选的,所述外部数据请求响应由预言机签名私钥进行签名;还包括:验签单元1804,使所述隐私计算节点基于预先获取的预言机签名公钥对所述外部数据请求响应进行验签;其中,所述隐私计算节点在确认验签成功的情况下,根据所述外部数据请求响应完成对所述智能合约的执行操作。
可选的,所述外部数据请求响应由预言机在预言机可信执行环境内采用节点公钥进行加密;所述响应单元1802进一步用于:所述隐私计算节点接收所述预言机加密返回的外部数据请求响应,并在节点可信执行环境中通过节点私钥对接收到的外部数据请求响应进行解密。
可选的,在所述隐私计算节点属于隐私计算集群的情况下,节点私钥仅被所述隐私计算节点所维护,或者节点私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
请参考图19,在另一种预言机侧的软件实施方式中,该访问外部数据的装置可以包括:接收单元1901,使预言机接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起;访问单元1902,使所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器;返回单元1903,使所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述隐私计算节点;所述外部数据请求响应用于在所述节点可信执行环境内解密后参与所述智能合约的执行操作。
可选的,所述接收单元1901进一步用于:在所述预言机为预言机节点的情况下,所述预言机接收所述隐私计算节点在节点可信执行环境内基于预言机加密公钥加密的外部数据访问请求,并基于预言机加密私钥对接收到的外部数据访问请求进行解密;或者,在所述预言机为预言机集群的情况下,所述预言机集群中的控制节点接收所述隐私计算节点在节点可信执行环境内基于预言机加密公钥加密的外部数据访问请求,并基于该控制节点维护的预言机加密私钥对所述加密后的外部数据访问请求解密后转发至所述预言机集群内的预言机节点进行处理。
可选的,还包括:签名单元1904,使所述预言机基于预言机签名私钥对所述外部数据请求响应进行签名。
可选的,所述返回单元1903进一步用于:使所述预言机采用节点公钥对创建的外部数据请求响应进行加密,并将加密的外部数据请求响应返回给所述隐私计算节点;所述加密的外部数据请求响应由所述隐私计算节点在接收后基于节点私钥进行解密。
可选的,在所述隐私计算节点属于隐私计算集群的情况下,节点私钥仅被所述隐私计算节点所维护,或者节点私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
请参考图20,在另一种预言机控制节点侧的软件实施方式中,该访问外部数据的装置可以包括:请求接收单元2001,使预言机集群中的控制节点接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起;请求转发单元2002,使所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问;结果返回单元2003,使所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响 应进行加密后,将经过加密的外部数据请求响应返回所述隐私计算节点。
可选的,所述外部数据请求响应由所述被选取的预言机节点在预言机可信执行环境内创建,并由所述被选取的预言机通过预言机私钥进行签名;所述签名后的外部数据请求响应在所述隐私计算节点基于预先获取的预言机公钥验签后,用于完成对所述智能合约的执行操作。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说 明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。
Claims (39)
- 一种访问外部数据的方法,包括:链下隐私计算节点在链下可信执行环境中执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求,在所述链下可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机;所述链下隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密;所述链下隐私计算节点在所述链下可信执行环境内解密获得所述外部数据请求响应,根据所述外部数据请求响应完成对所述链下合约的执行操作。
- 根据权利要求1所述的方法,将所述外部数据访问请求加密传输至预言机,包括:所述链下隐私计算节点在链下可信执行环境内基于预言机加密公钥对所述外部数据访问请求进行加密,并将加密后的外部数据访问请求发送至所述预言机;其中,所述预言机包括维护有预言机加密私钥的预言机节点;或者,在所述预言机为预言机集群的情况下,所述预言机加密私钥由所述预言机集群的控制节点维护,加密后的外部数据访问请求被所述控制节点解密后转发至所述预言机集群内的预言机节点进行处理。
- 根据权利要求1所述的方法,所述外部数据请求响应由预言机签名私钥进行签名;所述方法还包括:所述链下隐私计算节点基于预先获取的预言机签名公钥对所述外部数据请求响应进行验签;其中,所述链下隐私计算节点在确认验签成功的情况下,根据所述外部数据请求响应完成对所述链下合约的执行操作。
- 根据权利要求3所述的方法,在所述预言机为预言机节点的情况下,预言机签名私钥由所述预言机节点维护;所述方法还包括:所述链下隐私计算节点获取针对所述预言机节点的远程证明报告,所述远程证明报告由认证服务器对所述预言机节点产生的自荐信息进行验证后生成,所述自荐信息与所述预言机节点上创建的可信执行环境相关;在根据所述远程证明报告确定所述预言机节点可信的情况下,所述链下隐私计算节点将预言机签名公钥在本地保存;在所述预言机为预言机集群的情况下,预言机签名私钥由集群中响应于所述外部数据访问请求的预言机节点维护;所述方法还包括:所述链下隐私计算节点分别获取针对集群中各个预言机节点的远程证明报告,每一远程证明报告由认证服务器对相应预言机节点产生的自荐信息进行验证后生成,所述自荐信息与相应预言机节点上创建的可信执行环境相关;所述链下隐私计算节点根据所述远程证明报告确定出可信的预言机节点,并将相应的预言机签名公钥在本地保存。
- 根据权利要求1所述的方法,所述外部数据请求响应由预言机在预言机可信执行环境内采用链下节点公钥进行加密;所述链下隐私计算节点接收所述预言机加密返回的外部数据请求响应,包括:所述链下隐私计算节点接收所述预言机加密返回的外部数据请求响应,并在链下可信执行环境中通过链下节点私钥对接收到的外部数据请求响应进行解密。
- 根据权利要求5所述的方法,在所述链下隐私计算节点属于链下隐私计算集群的情况下,链下节点私钥仅被所述链下隐私计算节点所维护,或者链下节点私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
- 根据权利要求1所述的方法,所述链下隐私计算节点在所述链下可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机;包括:所述链下隐私计算节点获取执行所述链下合约产生的第一格式的外部数据访问请求,并将获取到的外部数据访问请求转换为第二格式;所述链下隐私计算节点将转换为第二格式的外部数据访问请求加密传输至预言机;所述根据所述外部数据请求响应完成对所述链下合约的执行操作,包括:所述链下隐私计算节点将获取到的第二格式的外部数据请求响应转换为第一格式的外部数据请求响应;所述链下隐私计算节点基于所述第一格式的外部数据请求响应完成对所述链下合约的执行操作。
- 根据权利要求1所述的方法,还包括:所述链下隐私计算节点对所述外部数据访问请求中的字段进行检查;在检测到所述外部数据访问请求中存在不符合访问要求的字段或请求内容,或者目的IP地址未处于预设白名单的情况下,所述链下隐私计算节点禁止执行访问外部数据的操作。
- 一种访问外部数据的方法,包括:预言机接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点响应于链下合约的外部数据访问需求而发起;所述链下合约在被区块链节点调用的情况下,由所述链下隐私计算节点在链下可信执行环境内执行;所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器;所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述链下隐私计算节点;所述外部数据请求响应用于在所述链下可信执行环境内解密后参与所述链下合约的执行操作。
- 根据权利要求9所述的方法,所述预言机接收链下隐私计算节点加密传输的外部数据访问请求,包括:在所述预言机为预言机节点的情况下,所述预言机接收所述链下隐私计算节点在链下可信执行环境内基于预言机加密公钥加密的外部数据访问请求,并基于预言机加密私钥对接收到的外部数据访问请求进行解密;或者,在所述预言机为预言机集群的情况下,所述预言机集群中的控制节点接收所述链下隐私计算节点在链下可信执行环境内基于预言机加密公钥加密的外部数据访问请求,并基于该控制节点维护的预言机加密私钥对所述加密后的外部数据访问请求解密后转发至所述预言机集群内的预言机节点进行处理。
- 根据权利要求9所述的方法,还包括:所述预言机基于预言机签名私钥对所述外部数据请求响应进行签名。
- 根据权利要求11所述的方法,在所述预言机为预言机节点的情况下,预言机签名私钥由该预言机节点维护;所述方法还包括:所述预言机向所述链下隐私计算节点返回远程证明报告;所述远程证明报告由认证服务器对该预言机节点产生的自荐信息进行验证后生成,所述自荐信息与该预言机节点上创建的可信执行环境相关;在根据所述远程证明报告确定预言机节点可信的情况下,预言机签名公钥被所述链下隐私计算节点保存在本地;在所述预言机为预言机集群的情况下,预言机签名私钥由集群中响应于所述外部数据访问请求的预言机节点维护;所述方法还包括:所述预言机集群中的控制节点向所述链下隐私计算节点返回集群中各个预言机节点的远程报告证明,每一远程证明报告由认证服务器对相应预言机节点产生的自荐信息进行验证后生成,所述自荐信息与相应预言机节点上创建的可信执行环境相关;在根据所述远程证明报告确定出可信预言机节点的情况下,所述可信预言机节点的预言机签名公钥被所述链下隐私计算节点保存在本地。
- 根据权利要求9所述的方法,所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,包括:所述预言机采用链下节点公钥对创建的外部数据请求响应进行加密,并将加密的外部数据请求响应返回给所述链下隐私计算节点;所述加密的外部数据请求响应由所述链下隐私计算节点在接收后基于链下节点私钥进行解密。
- 根据权利要求13所述的方法,在所述链下隐私计算节点属于链下隐私计算集群的情况下,链下节点私钥仅被所述链下隐私计算节点所维护,或者链下节点私钥被所述链下隐私计算集群内的所有链下隐私计算节点共同维护。
- 根据权利要求9所述的方法,所述预言机接收链下隐私计算节点加密传输的外部数据访问请求,包括:所述预言机接收所述链下隐私计算节点发送的第二格式的外部数据访问请求;所述第二格式的外部数据访问请求由所述链下隐私计算节点在执行所述链下合约的情况下产生的第一格式的外部数据访问请求转换得到;所述将加密后的外部数据请求响应返回所述链下隐私计算节点,包括:所述预言机将第二格式的外部数据请求响应返回所述链下隐私计算节点;所述第二格式的外部数据请求响应由所述链下隐私计算节点转换为第一格式的外部数据请求响应;所述链下隐私计算节点基于所述第一格式的外部数据请求响应完成对所述链下合约的执行操作。
- 一种访问外部数据的方法,包括:预言机集群中的控制节点接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点在链下可信执行环境内执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求而发起;所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问;所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经过加密的外部数据请求响应返回所述链下隐私计算节点。
- 根据权利要求16所述的方法,所述外部数据请求响应由所述被选取的预言机节点在预言机可信执行环境内创建,并由所述被选取的预言机通过预言机私钥进行签名;所述签名后的外部数据请求响应在所述链下隐私计算节点基于预先获取的预言机公钥验签后,用于完成对所述链下合约的执行操作。
- 根据权利要求16所述的方法,还包括:所述控制节点向所述链下隐私计算节点发送远程证明报告;所述远程证明报告由所述链下隐私计算节点验证通过后,将所述远程证明对应的预言机节点确定为可信节点;所述可信节点的公钥信息被所述链下隐私计算节点保存在本地。
- 根据权利要求16所述的方法,还包括:所述控制节点接收所述预言机集群中的预言机节点的远程证明报告,并基于所述远程报告证明验证所述预言机节点是否为可信节点;所述控制节点在接收到所述链下隐私计算节点发送的外部数据访问请求的情况下,基于负载均衡分配一可信节点用于处理该外部数据访问请求。
- 一种访问外部数据的方法,包括:隐私计算节点在节点可信执行环境中执行智能合约的过程中,在所述节点可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机;所述隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加 密;所述隐私计算节点在所述节点可信执行环境内解密获得所述外部数据请求响应,根据所述外部数据请求响应完成对所述智能合约的执行操作。
- 根据权利要求20所述的方法,将所述外部数据访问请求加密传输至预言机,包括:所述隐私计算节点在节点可信执行环境内基于预言机加密公钥对所述外部数据访问请求进行加密,并将加密后的外部数据访问请求发送至所述预言机;其中,所述预言机包括维护有预言机加密私钥的预言机节点;或者,在所述预言机为预言机集群的情况下,所述预言机加密私钥由所述预言机集群的控制节点维护,加密后的外部数据访问请求被所述控制节点解密后转发至所述预言机集群内的预言机节点进行处理。
- 根据权利要求20所述的方法,所述外部数据请求响应由预言机签名私钥进行签名;所述方法还包括:所述隐私计算节点基于预先获取的预言机签名公钥对所述外部数据请求响应进行验签;其中,所述隐私计算节点在确认验签成功的情况下,根据所述外部数据请求响应完成对所述智能合约的执行操作。
- 根据权利要求20所述的方法,所述外部数据请求响应由预言机在预言机可信执行环境内采用节点公钥进行加密;所述隐私计算节点接收所述预言机加密返回的外部数据请求响应,包括:所述隐私计算节点接收所述预言机加密返回的外部数据请求响应,并在节点可信执行环境中通过节点私钥对接收到的外部数据请求响应进行解密。
- 根据权利要求23所述的方法,在所述隐私计算节点属于隐私计算集群的情况下,节点私钥仅被所述隐私计算节点所维护,或者节点私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
- 一种访问外部数据的方法,包括:预言机接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起;所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器;所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述隐私计算节点;所述外部数据请求响应用于在所述节点可信执行环境内解密后参与所述智能合约的执行操作。
- 根据权利要求25所述的方法,所述预言机接收隐私计算节点加密传输的外部数据访问请求,包括:在所述预言机为预言机节点的情况下,所述预言机接收所述隐私计算节点在节点可信执行环境内基于预言机加密公钥加密的外部数据访问请求,并基于预言机加密私钥对接收到的外部数据访问请求进行解密;或者,在所述预言机为预言机集群的情况下,所述预言机集群中的控制节点接收所述隐私计算节点在节点可信执行环境内基于预言机加密公钥加密的外部数据访问请求,并基于该控制节点维护的预言机加密私钥对所述加密后的外部数据访问请求解密后转发至所述预言机集群内的预言机节点进行处理。
- 根据权利要求25所述的方法,还包括:所述预言机基于预言机签名私钥对所述外部数据请求响应进行签名。
- 根据权利要求25所述的方法,所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,包括:所述预言机采用节点公钥对创建的外部数据请求响应进行加密,并将加密的外部数据请求响应返回给所述隐私计算节点;所述加密的外部数据请求响应由所述隐私计算节点在接收后基于节点私钥进行解密。
- 根据权利要求28所述的方法,在所述隐私计算节点属于隐私计算集群的情况下,节点私钥仅被所述隐私计算节点所维护,或者节点私钥被所述隐私计算集群内的所有隐私计算节点共同维护。
- 一种访问外部数据的方法,包括:预言机集群中的控制节点接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起;所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问;所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经过加密的外部数据请求响应返回所述隐私计算节点。
- 根据权利要求30所述的方法,所述外部数据请求响应由所述被选取的预言机节点在预言机可信执行环境内创建,并由所述被选取的预言机通过预言机私钥进行签名;所述签名后的外部数据请求响应在所述隐私计算节点基于预先获取的预言机公钥验签后,用于完成对所述智能合约的执行操作。
- 一种访问外部数据的装置,包括:请求单元,使链下隐私计算节点在链下可信执行环境中执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求,在所述链下可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机;响应单元,使所述链下隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密;反馈单元,使所述链下隐私计算节点在链下可信执行环境内解密获得所述外部数据请求响应,根据所述外部数据请求响应完成对所述链下合约的执行操作。
- 一种访问外部数据的装置,包括:接收单元,使预言机接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点响应于链下合约的外部数据访问需求而发起;所述链下合约在被区块链节点调用的情况下,由所述链下隐私计算节点在链下可信执行环境内执行;访问单元,使所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器;返回单元,使所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述链下隐私计算节点;所述外部数据请求响应用于在所述链下可信执行环境内解密后参与所述链下合约的执行操作。
- 一种访问外部数据的装置,包括:请求接收单元,使预言机集群中的控制节点接收链下隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述链下隐私计算节点在链下可信执行环境内执行被区块链节点调用的链下合约的过程中,响应于所述链下合约的外部数据访问需求而发起;请求转发单元,使所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据 访问请求用于指示被选取的预言机节点对远程服务器进行访问;结果返回单元,使所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经过加密的外部数据请求响应返回所述链下隐私计算节点。
- 一种访问外部数据的装置,包括:请求单元,使隐私计算节点在节点可信执行环境中执行智能合约的过程中,在所述节点可信执行环境中生成外部数据访问请求,并将所述外部数据访问请求加密传输至预言机;响应单元,使所述隐私计算节点接收所述预言机加密返回的外部数据请求响应,所述外部数据请求响应由所述预言机根据对远程服务器的访问结果在预言机可信执行环境内生成并加密;反馈单元,使所述隐私计算节点在所述节点可信执行环境内解密获得所述外部数据请求响应,根据所述外部数据请求响应完成对所述智能合约的执行操作。
- 一种访问外部数据的装置,包括:接收单元,使预言机接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起;访问单元,使所述预言机在预言机可信执行环境内解密得到所述外部数据访问请求,并根据所述外部数据访问请求访问远程服务器;返回单元,使所述预言机根据访问结果在预言机可信执行环境内创建外部数据请求响应并加密,将加密后的外部数据请求响应返回所述隐私计算节点;所述外部数据请求响应用于在所述节点可信执行环境内解密后参与所述智能合约的执行操作。
- 一种访问外部数据的装置,包括:请求接收单元,使预言机集群中的控制节点接收隐私计算节点加密传输的外部数据访问请求,所述外部数据访问请求由所述隐私计算节点在节点可信执行环境内执行智能合约的过程中发起;请求转发单元,使所述控制节点在控制节点可信执行环境内解密得到所述外部数据访问请求,并向集群内被选取的预言机节点转发所述外部数据访问请求,所述外部数据访问请求用于指示被选取的预言机节点对远程服务器进行访问;结果返回单元,使所述控制节点接收所述被选取的预言机节点根据访问结果返回的外部数据请求响应,并在控制节点可信执行环境内对所述外部数据请求响应进行加密后,将经过加密的外部数据请求响应返回所述隐私计算节点。
- 一种电子设备,包括:处理器;用于存储处理器可执行任务的存储器;其中,所述处理器通过运行所述可执行指令以实现如权利要求1-31中任一项所述的方法。
- 一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如权利要求1-31中任一项所述方法的步骤。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010191190.5 | 2020-03-18 | ||
| CN202010191190.5A CN111092914B (zh) | 2020-03-18 | 2020-03-18 | 访问外部数据的方法及装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2021184973A1 true WO2021184973A1 (zh) | 2021-09-23 |
Family
ID=70400583
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2021/074240 Ceased WO2021184973A1 (zh) | 2020-03-18 | 2021-01-28 | 访问外部数据的方法及装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN111092914B (zh) |
| WO (1) | WO2021184973A1 (zh) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114172662A (zh) * | 2021-12-03 | 2022-03-11 | 工银科技有限公司 | 区块链外部数据获取方法及装置 |
| CN114338667A (zh) * | 2021-12-06 | 2022-04-12 | 南京理工大学 | 辅助工业区块链智能合约的数据预言机架构及其运行方法 |
| CN114331446A (zh) * | 2022-03-15 | 2022-04-12 | 北京百度网讯科技有限公司 | 区块链的链外服务实现方法、装置、设备和介质 |
| CN114357508A (zh) * | 2021-12-27 | 2022-04-15 | 东北大学秦皇岛分校 | 一种基于预言机与区块链的物联网数据共享系统及方法 |
| CN114760105A (zh) * | 2022-03-22 | 2022-07-15 | 杭州锘崴信息科技有限公司 | 一种安全防护系统以及安全防护方法 |
| CN114969724A (zh) * | 2022-07-28 | 2022-08-30 | 山东省计算中心(国家超级计算济南中心) | 一种外部数据源数据可信上链方法及系统 |
| CN115297119A (zh) * | 2022-10-09 | 2022-11-04 | 江西信惠链科技有限公司 | 基于区块链和验证计算的联合征信方法及系统 |
| CN116055066A (zh) * | 2023-03-31 | 2023-05-02 | 北京微芯感知科技有限公司 | 一种基于区块链和预言机的ca系统 |
| CN116414894A (zh) * | 2021-12-31 | 2023-07-11 | 浙商银行股份有限公司 | 一种区块链获取数据的方法、设备及计算机可读存储介质 |
| CN116961912A (zh) * | 2022-04-15 | 2023-10-27 | 腾讯科技(深圳)有限公司 | 基于区块链的数据获取方法、装置、设备、介质及产品 |
| CN118332566A (zh) * | 2024-05-13 | 2024-07-12 | 山东大学 | 一种基于tee的链上链下安全可信协同计算方法及装置 |
| WO2025233340A1 (en) * | 2024-05-06 | 2025-11-13 | Circular Global Ledgers Sa | Random number generation on peer-to-peer decentralized ledger network |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111092914B (zh) * | 2020-03-18 | 2020-06-26 | 支付宝(杭州)信息技术有限公司 | 访问外部数据的方法及装置 |
| CN111625814B (zh) * | 2020-05-12 | 2022-11-04 | 卓尔智联(武汉)研究院有限公司 | 风控计算的处理设备、处理方法、处理装置和存储介质 |
| CN111953648A (zh) * | 2020-06-22 | 2020-11-17 | 北京欧链科技有限公司 | 基于区块链预言机的数据处理方法、装置及电子设备 |
| CN112003942B (zh) * | 2020-08-25 | 2023-04-21 | 杭州时戳信息科技有限公司 | 链下数据请求响应方法、系统、节点设备与存储介质 |
| CN112003941A (zh) * | 2020-08-25 | 2020-11-27 | 杭州时戳信息科技有限公司 | 分发链下数据请求的方法、系统、节点设备与存储介质 |
| CN111767578B (zh) * | 2020-08-31 | 2021-06-04 | 支付宝(杭州)信息技术有限公司 | 一种数据检验方法、装置及设备 |
| CN112073413B (zh) * | 2020-09-08 | 2022-12-06 | 深圳市金蚁云数字科技有限公司 | 在线化联盟链管理方法、装置、计算机设备及存储介质 |
| CN111930523B (zh) * | 2020-09-28 | 2024-09-24 | 支付宝(杭州)信息技术有限公司 | 一种用于服务集群的负载均衡方法和系统 |
| CN114679284B (zh) * | 2020-12-24 | 2024-11-08 | 中国移动通信有限公司研究院 | 可信远程证明系统及其存储、验证方法、存储介质 |
| CN112650605A (zh) * | 2020-12-30 | 2021-04-13 | 杭州趣链科技有限公司 | 一种基于智能合约的预言机调用过程实现方法及装置 |
| CN112948465B (zh) * | 2021-03-10 | 2022-09-06 | 工银科技有限公司 | 基于区块链的数据处理方法和装置 |
| CN113221166A (zh) * | 2021-05-11 | 2021-08-06 | 支付宝(杭州)信息技术有限公司 | 一种获取区块链数据的方法、装置、电子设备及存储介质 |
| CN113609225B (zh) * | 2021-08-09 | 2023-06-02 | 北京神州数码方圆科技有限公司 | 基于did的区块链数据交换方法及系统 |
| CN113872828B (zh) * | 2021-09-27 | 2022-12-30 | 深圳前海微众银行股份有限公司 | 区块链预言机状态监控方法 |
| CN114511311A (zh) * | 2022-01-28 | 2022-05-17 | 武汉天喻信息产业股份有限公司 | 一种智能合约设备及智能合约处理方法 |
| CN114726858B (zh) * | 2022-03-31 | 2024-07-09 | 蚂蚁区块链科技(上海)有限公司 | 一种数据处理方法、装置、电子设备和存储介质 |
| CN118210631A (zh) * | 2024-03-29 | 2024-06-18 | 北京火山引擎科技有限公司 | 用于边缘计算的集群负载均衡方法、服务器和电子设备 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9875368B1 (en) * | 2015-06-30 | 2018-01-23 | Google Llc | Remote authorization of usage of protected data in trusted execution environments |
| CN109670335A (zh) * | 2018-12-20 | 2019-04-23 | 众安信息技术服务有限公司 | 用于在区块链与链外数据之间进行交互的方法及装置 |
| WO2019180702A1 (en) * | 2018-03-18 | 2019-09-26 | Valid Network Ltd | Method and system for assessing future execution of a smart contract based on previous executions on a blockchain-based platform |
| CN110473096A (zh) * | 2019-07-31 | 2019-11-19 | 阿里巴巴集团控股有限公司 | 基于智能合约的数据授权方法及装置 |
| CN110520884A (zh) * | 2018-12-13 | 2019-11-29 | 阿里巴巴集团控股有限公司 | 基于可信执行环境的链外智能合约服务 |
| CN111092914A (zh) * | 2020-03-18 | 2020-05-01 | 支付宝(杭州)信息技术有限公司 | 访问外部数据的方法及装置 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11165589B2 (en) * | 2017-05-11 | 2021-11-02 | Shapeshift Ag | Trusted agent blockchain oracle |
| US11977924B2 (en) * | 2017-12-26 | 2024-05-07 | Akamai Technologies, Inc. | High performance distributed system of record with distributed random oracle |
| CN109727131A (zh) * | 2018-12-28 | 2019-05-07 | 苏州鸿链信息科技有限公司 | 一种基于区块链合约层的链下执行交易方法及系统 |
| CN110060158B (zh) * | 2019-03-07 | 2020-06-09 | 阿里巴巴集团控股有限公司 | 基于变长编码的智能合约执行方法和装置 |
| EP3673617B1 (en) * | 2019-03-27 | 2021-11-17 | Advanced New Technologies Co., Ltd. | Retrieving public data for blockchain networks using trusted execution environments |
| CN109981679B (zh) * | 2019-04-08 | 2021-08-10 | 上海点融信息科技有限责任公司 | 在区块链网络中执行事务的方法和装置 |
| CN110335151B (zh) * | 2019-07-09 | 2022-12-20 | 郭小川 | 配合智能合约应用的中心化预言机、信息输出方法及系统 |
-
2020
- 2020-03-18 CN CN202010191190.5A patent/CN111092914B/zh active Active
-
2021
- 2021-01-28 WO PCT/CN2021/074240 patent/WO2021184973A1/zh not_active Ceased
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9875368B1 (en) * | 2015-06-30 | 2018-01-23 | Google Llc | Remote authorization of usage of protected data in trusted execution environments |
| WO2019180702A1 (en) * | 2018-03-18 | 2019-09-26 | Valid Network Ltd | Method and system for assessing future execution of a smart contract based on previous executions on a blockchain-based platform |
| CN110520884A (zh) * | 2018-12-13 | 2019-11-29 | 阿里巴巴集团控股有限公司 | 基于可信执行环境的链外智能合约服务 |
| CN109670335A (zh) * | 2018-12-20 | 2019-04-23 | 众安信息技术服务有限公司 | 用于在区块链与链外数据之间进行交互的方法及装置 |
| CN110473096A (zh) * | 2019-07-31 | 2019-11-19 | 阿里巴巴集团控股有限公司 | 基于智能合约的数据授权方法及装置 |
| CN111092914A (zh) * | 2020-03-18 | 2020-05-01 | 支付宝(杭州)信息技术有限公司 | 访问外部数据的方法及装置 |
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114172662A (zh) * | 2021-12-03 | 2022-03-11 | 工银科技有限公司 | 区块链外部数据获取方法及装置 |
| CN114338667A (zh) * | 2021-12-06 | 2022-04-12 | 南京理工大学 | 辅助工业区块链智能合约的数据预言机架构及其运行方法 |
| CN114357508A (zh) * | 2021-12-27 | 2022-04-15 | 东北大学秦皇岛分校 | 一种基于预言机与区块链的物联网数据共享系统及方法 |
| CN116414894A (zh) * | 2021-12-31 | 2023-07-11 | 浙商银行股份有限公司 | 一种区块链获取数据的方法、设备及计算机可读存储介质 |
| CN114331446A (zh) * | 2022-03-15 | 2022-04-12 | 北京百度网讯科技有限公司 | 区块链的链外服务实现方法、装置、设备和介质 |
| CN114760105B (zh) * | 2022-03-22 | 2023-06-06 | 杭州锘崴信息科技有限公司 | 一种安全防护系统以及安全防护方法 |
| CN114760105A (zh) * | 2022-03-22 | 2022-07-15 | 杭州锘崴信息科技有限公司 | 一种安全防护系统以及安全防护方法 |
| CN116961912A (zh) * | 2022-04-15 | 2023-10-27 | 腾讯科技(深圳)有限公司 | 基于区块链的数据获取方法、装置、设备、介质及产品 |
| CN114969724B (zh) * | 2022-07-28 | 2022-11-04 | 山东省计算中心(国家超级计算济南中心) | 一种外部数据源数据可信上链方法及系统 |
| CN114969724A (zh) * | 2022-07-28 | 2022-08-30 | 山东省计算中心(国家超级计算济南中心) | 一种外部数据源数据可信上链方法及系统 |
| CN115297119B (zh) * | 2022-10-09 | 2023-02-03 | 江西信惠链科技有限公司 | 基于区块链和验证计算的联合征信方法及系统 |
| CN115297119A (zh) * | 2022-10-09 | 2022-11-04 | 江西信惠链科技有限公司 | 基于区块链和验证计算的联合征信方法及系统 |
| CN116055066A (zh) * | 2023-03-31 | 2023-05-02 | 北京微芯感知科技有限公司 | 一种基于区块链和预言机的ca系统 |
| WO2025233340A1 (en) * | 2024-05-06 | 2025-11-13 | Circular Global Ledgers Sa | Random number generation on peer-to-peer decentralized ledger network |
| CN118332566A (zh) * | 2024-05-13 | 2024-07-12 | 山东大学 | 一种基于tee的链上链下安全可信协同计算方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111092914A (zh) | 2020-05-01 |
| CN111092914B (zh) | 2020-06-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2021184973A1 (zh) | 访问外部数据的方法及装置 | |
| CN111092727B (zh) | 共享集群密钥的方法及装置 | |
| CN111092726B (zh) | 生成共享合约密钥的方法及装置 | |
| CN111090888B (zh) | 验证合约的方法及装置 | |
| CN111541785B (zh) | 基于云计算的区块链数据处理方法及装置 | |
| CN111090875B (zh) | 部署合约的方法及装置 | |
| CN111090874B (zh) | 调用合约的方法及装置 | |
| CN111090876B (zh) | 调用合约的方法及装置 | |
| HK40036312B (zh) | 基於云计算的区块链数据处理方法及装置 | |
| HK40036312A (zh) | 基於云计算的区块链数据处理方法及装置 | |
| HK40029000B (zh) | 访问外部数据的方法及装置 | |
| HK40029000A (zh) | 访问外部数据的方法及装置 | |
| HK40043789B (zh) | 生成共享合约密钥的方法及装置 | |
| HK40028999A (zh) | 生成共享合约密钥的方法及装置 | |
| HK40028999B (zh) | 生成共享合约密钥的方法及装置 | |
| HK40029291A (zh) | 验证合约的方法及装置 | |
| HK40029291B (zh) | 验证合约的方法及装置 | |
| HK40043789A (zh) | 生成共享合约密钥的方法及装置 | |
| HK40044599B (zh) | 调用合约的方法及装置 | |
| HK40044599A (zh) | 调用合约的方法及装置 | |
| HK40045913B (zh) | 部署合约的方法及装置 | |
| HK40041347A (zh) | 共享集群密钥的方法及装置 | |
| HK40041347B (zh) | 共享集群密钥的方法及装置 | |
| HK40029001A (zh) | 共享集群密钥的方法及装置 | |
| HK40029001B (zh) | 共享集群密钥的方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 21771637 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 21771637 Country of ref document: EP Kind code of ref document: A1 |