Retrieve public data from blockchain networks using a highly available trusted execution environment

Abstract

A method, system and apparatus for enhancing the security of a blockchain network, including a computer program encoded on a computer storage medium. An implementation includes receiving a request for data from a data source; sending the request to a relay system located outside the blockchain network and including a multi-node cluster, the multi-node cluster including a plurality of relay system nodes; receiving a result provided from the relay system node, the result being digitally signed using a private key of the relay system node; verifying that the relay system node is registered; verifying the integrity of the result based on the public key of the relay system node and the digital signature of the result in response to verifying that the relay system node is registered; and sending the result to a client in response to verifying the integrity of the result.

Description

Technical Field

[0001] This article deals with providing data to a blockchain network from external data sources. Background Art

[0002] A distributed ledger system (DLS), which may also be referred to as a consensus network and / or a blockchain network, enables participating entities to store data securely and permanently. Without reference to any specific use case, a DLS is often referred to as a blockchain network. Examples of types of blockchain networks may include a consortium blockchain network provided for a group of selected entities, which controls the consensus process, and which includes an access control layer.

[0003] Smart contracts are programs that are executed on the blockchain. Smart contracts contain a set of predefined rules under which the parties agreed to by the smart contract interact with each other. If the predefined rules of the smart contract are met, the agreement defined in the smart contract is automatically executed. Smart contracts are generally tamper-proof and can facilitate, verify and enforce the negotiation or execution of agreements or transactions.

[0004] In some cases, smart contracts running within a blockchain network require input from outside the blockchain network to evaluate pre-defined rules and perform corresponding actions. However, smart contracts themselves cannot directly access external data sources. Therefore, relay agents can be used to retrieve external data and submit the data to the blockchain for processing by smart contracts. However, this process may cause security issues, such as potential attack vectors (e.g., distributed denial of service (DDoS) attacks). In addition, each client will need to authenticate the remote agent separately, which will hinder scalability and increase resource overhead (e.g., processor, bandwidth). In some cases, each request submitted by the client is processed by a relay agent that the client has authenticated. If the relay agent fails or is inaccessible, the client request cannot be processed correctly, resulting in service unavailability.

[0005]

[0004] Although techniques have been proposed to address security and other issues associated with data retrieval from external data sources, a more efficient solution to these issues would be advantageous. Summary of the invention

[0006] This article describes techniques for retrieving data from external data sources for processing within a blockchain network.

[0007] Embodiments of the present invention relate to a relay system including a multi-node cluster, which is used to retrieve publicly available data and / or services from an external data source in a verifiable and highly available manner. In some embodiments, remote authentication is performed on each of the multiple relay system nodes in the multi-node cluster, and the remote authentication generates a key pair (public key, private key) for each relay system node. Each relay system node operates using a trusted execution environment (TEE). The relay system smart contract is used for remote authentication of the relay system node, which can be publicly audited, eliminating the need for individual customers to repeat remote authentication. The verified relay system node is registered for use by the relay system smart contract. The relay system controller can periodically check and record the status of each relay system node in the multi-node cluster. The relay system controller assigns each client request to an available relay system node in the multi-node cluster to query an external data source. The response including the query result is digitally signed using the private key of the relay system node. The relay system smart contract can verify whether the response is sent by a registered relay system node. The integrity of the response can be verified by the Relay System smart contract using the public key of the Relay System node.

[0008] The subject matter described herein is provided as a specific embodiment, achieving one or more of the following technical advantages. In some embodiments, a multi-node cluster for retrieving or accessing data and / or services from an external data source is provided, wherein the status of the relay system nodes in the multi-node cluster is periodically checked and recorded by the relay system controller. As described herein, by deploying the relay system nodes in the cluster, the relay system controller can automatically assign customer service requests to the available relay system nodes in the cluster, thereby avoiding service unavailability due to failure of individual relay system nodes. Therefore, the embodiments of this article improve the overall service availability of the relay system for querying Internet data sources. In some embodiments, the integrity of the response returned from the external data source to the blockchain network is ensured. Therefore, the embodiments of this article improve the integrity of the communication between the blockchain network and the components of the relay system, which are used to retrieve data outside the blockchain network. In this way, the potential attack channels of malicious users are reduced, thereby enhancing security. In some embodiments, the relay system helps to avoid direct contact between users and relay system nodes, thereby avoiding exposing the location or access point of the relay system nodes. Therefore, the relay system nodes are less likely to be discovered and attacked by malicious participants on the network in various forms, such as, for example, distributed denial of service (DDoS) attacks. This improves the security of the relay system nodes, which in turn further improves the security of communications between the blockchain network and the relay system nodes.

[0009] Also provided herein is one or more non-transitory computer-readable storage media, which are coupled to one or more processors and have instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations according to embodiments of the method provided herein.

[0010] The present invention also provides a system for implementing the method provided herein. The system includes one or more processors and a computer-readable storage medium coupled to the one or more processors and having instructions stored thereon, and when the instructions are executed by the one or more processors, the one or more processors are prompted to perform operations according to the implementation of the method provided herein.

[0011] It is understood that the method according to this article may include any combination of the aspects and features described herein. That is, the method according to this article is not limited to the combination of the aspects and features specifically described herein, but includes any combination of the aspects and features provided.

[0012] The details of one or more implementations of the present invention are set forth in the accompanying drawings and the description below. Other features and advantages of the present invention will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 The present invention is a diagram showing an example of an environment that can be used to implement embodiments of the present invention.

[0014] Figure 2 is an illustration of an example of a conceptual architecture according to embodiments of the present invention.

[0015] Figure 3 is a diagram of an example of a system according to an embodiment of the present invention.

[0016] Figure 4 An example of a signal flow according to an embodiment of the present invention is depicted.

[0017] Figure 5 An example of a signal flow according to an embodiment of the present invention is depicted.

[0018] Figure 6 An example of a signal flow according to an embodiment of the present invention is depicted.

[0019] Figure 7 Depicted are examples of processes that may be performed according to embodiments herein.

[0020] Figure 8 Depicted are module examples of devices according to embodiments herein.

[0021] The same reference numerals and designs in different drawings denote the same elements. DETAILED DESCRIPTION

[0022] This article describes a technique for retrieving data from an external data source for processing within a blockchain network. Embodiments of this article relate to a relay system that includes a multi-node cluster used to retrieve or access data and / or services from an external data source in a verifiable and highly available manner. In some embodiments, remote authentication is performed on each of a plurality of relay system nodes in the multi-node cluster, and the remote authentication generates a key pair (public key, private key) for each relay system node. Each relay system node operates using a trusted execution environment (TEE). The relay system smart contract is used for remote authentication of the relay system node, which can be publicly audited, eliminating the need for a single client to repeat remote authentication. Verified relay system nodes are registered for use by the relay system smart contract. The relay system controller can periodically check and record the status of each relay system node in the multi-node cluster. The relay system controller assigns client requests to available relay system nodes in the cluster to query external data sources. The response including the query result is digitally signed using the private key of the relay system node. The relay system smart contract can verify whether the response is sent by a registered relay system node. The integrity of the response can be verified by the Relay System smart contract using the public key of the Relay System node.

[0023] To provide further background for embodiments of the present invention, as described above, a distributed ledger system (DLS), which may also be referred to as a consensus network (e.g., composed of peer nodes) and a blockchain network, enables participating entities to conduct transactions and store data securely and immutably. Although the term blockchain is often associated with specific networks and / or use cases, blockchain as used herein generally refers to a DLS without reference to any specific use case.

[0024] A blockchain is a data structure that stores transactions in a way that they cannot be tampered with. Therefore, transactions recorded on the blockchain are reliable and trustworthy. A blockchain includes one or more blocks. Each block in the chain is linked to the previous block by a cryptographic hash of the previous block immediately preceding it in the chain. Each block also includes a timestamp, its own cryptographic hash, and one or more transactions. Transactions that have been verified by nodes in the blockchain network are hashed and compiled into a Merkle tree. A Merkle tree is a data structure in which the data at the leaf nodes of the tree are hashed, and all hash values ​​in each branch of the tree are connected at the root of the branch. This process continues along the tree until the root of the entire tree, where hash values ​​representing all the data in the tree are stored. Hash values ​​that claim to be transactions stored in the tree can be quickly verified by determining whether they are consistent with the structure of the tree.

[0025] A blockchain is a decentralized or at least partially decentralized data structure for storing transactions, and a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains by broadcasting, verifying, and confirming transactions. As described above, a blockchain network can be provided as a public blockchain network, a private blockchain network, or a consortium blockchain network. Embodiments of the present invention are further described in detail herein with reference to consortium blockchain networks. However, it is contemplated that embodiments of the present invention can be implemented in any suitable type of blockchain network.

[0026] Typically, consortium blockchain networks are private among participating entities. In a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, which may be referred to as consensus nodes, with one or more consensus nodes operated by the respective entity (e.g., financial institution, insurance company). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) may operate a consortium blockchain network, with each entity operating at least one node in the consortium blockchain network.

[0027] In some examples, in a consortium blockchain network, a global blockchain is provided as a blockchain that is replicated across all nodes. That is, all consensus nodes are in full consensus on the global blockchain. In order to reach consensus (e.g., agree to add a block to the blockchain), a consensus protocol is implemented within the consortium blockchain network. For example, the consortium blockchain network can implement a practical Byzantine fault tolerance (PBFT) consensus, which is described in further detail below.

[0028] Figure 1 1 is a diagram showing an example of an environment 100 that can be used to perform embodiments of the present invention. In some examples, the exemplary environment 100 enables entities to participate in a consortium blockchain network 102. The exemplary environment 100 includes computing devices 106, 108 and a network 110. In some examples, the network 110 includes a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and connects websites, user devices (e.g., computing devices), and backend systems. In some examples, the network 110 can be accessed via a wired and / or wireless communication link.

[0029] In the example shown, computing systems 106, 108 may each include any suitable computing system capable of participating as a node in consortium blockchain network 102. Exemplary computing devices include, but are not limited to, servers, desktop computers, laptops, tablet computing devices, and smartphones. In some examples, computing systems 106, 108 host one or more computer-implemented services for interacting with consortium blockchain network 102. For example, computing system 106 may host a computer-implemented service for a first entity (e.g., user A), such as a transaction management system for the first entity to manage its transactions with one or more other entities (e.g., other users). Computing system 108 may host a computer-implemented service for a second entity (e.g., user B), such as a transaction management system for the second entity to manage its transactions with one or more other entities (e.g., other users). Figure 1 In the example of FIG. 1 , the consortium blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing systems 106 and 108 respectively provide nodes of a first entity and a second entity participating in the consortium blockchain network 102 .

[0030] Figure 2 An example of a conceptual architecture 200 according to embodiments of the present invention is described. The conceptual architecture 200 includes a physical layer 202, a bearer service layer 204, and a blockchain network layer 206. In the depicted example, the physical layer 202 includes three participants, participant A, participant B, and participant C, each of which has its own transaction management system 208.

[0031] In the example shown, the bearer service layer 204 includes an interface 210 for each transaction management system 208. In some examples, each transaction management system 208 communicates with each other over a network (e.g., Figure 1 In some examples, each interface 210 provides a communication connection between the corresponding transaction management system 208 and the blockchain network layer 206. More specifically, the interface 210 communicates with the blockchain network 212 of the blockchain network layer 206. In some examples, the communication between the interface 210 and the blockchain network layer 206 is performed using a remote procedure call (RPC). In some examples, the interface 210 "hosts" a blockchain network node for the respective transaction management system 208. For example, the interface 210 provides an application programming interface (API) for accessing the blockchain network 212.

[0032] As described herein, the blockchain network 212 is provided as a peer-to-peer network including a plurality of nodes 214. The plurality of nodes 214 record information in an unalterable manner in a blockchain 216. Although a single blockchain 216 is schematically depicted, multiple copies of the blockchain 216 are provided and maintained in the blockchain network 212. For example, each node 214 stores a copy of the blockchain. In some embodiments, the blockchain 216 stores information associated with transactions conducted between two or more entities participating in the consortium blockchain network.

[0033] Blockchain (e.g. Figure 2 The blockchain 216 of the present invention is composed of a series of blocks, each of which stores data. Exemplary data includes transaction data representing a transaction between two or more participants. Although transactions are used in this article as a non-limiting example, it is contemplated that any suitable data can be stored in the blockchain (e.g., documents, images, videos, audio). Exemplary transactions can include, but are not limited to, the exchange of valuables (e.g., assets, products, services). Transaction data is stored in the blockchain in an unalterable manner. That is, the transaction data cannot be changed.

[0034] Before the transaction data is stored in the block, the transaction data is hashed. Hashing is the process of converting the transaction data (provided as string data) into a fixed-length hash value (also provided as string data). It is impossible to un-hash the hash value to obtain the transaction data. Hashing ensures that even a small change in the transaction data will result in a completely different hash value. In addition, as mentioned above, the hash value has a fixed length. That is, regardless of the size of the transaction data, the length of the hash value is fixed. Hashing includes processing the transaction data through a hash function to produce a hash value. Examples of hash functions include, but are not limited to, the Secure Hash Algorithm (SHA-256), which outputs a 256-bit hash value.

[0035] The transaction data of multiple transactions are hashed and stored in a block. For example, the hashes of two transactions are provided and they themselves are hashed to provide another hash. This process is repeated until a single hash is provided for all transactions to be stored in a block. This hash is called the Merkle root hash and is stored in the header of the block. Changes in any transaction will cause its hash to change and ultimately cause the Merkle root hash to change.

[0036] Blocks are added to the blockchain through a consensus protocol. Multiple nodes in the blockchain network participate in the consensus protocol and work to add blocks to the blockchain. These nodes are called consensus nodes. The PBFT introduced above is used as a non-limiting example of a consensus protocol. Consensus nodes execute the consensus protocol to add transactions to the blockchain and update the overall state of the blockchain network.

[0037] In further detail, the consensus node produces a block header, hashes all transactions in the block, and combines hashes in pairs to produce further hashes until a single hash (Merkle root hash) is provided for all transactions in the block. This hash is added to the block header. The consensus node also determines the hash of the most recent block in the blockchain (i.e., the most recent block added to the blockchain). The consensus node also adds a random number (nonce) and a timestamp to the block header.

[0038] In general, PBFT provides practical Byzantine state machine replication that tolerates Byzantine faults (e.g., faulty nodes, malicious nodes). This is achieved in PBFT by assuming that failures will occur (e.g., assuming that there are independent node failures and / or manipulated messages sent by consensus nodes). In PBFT, consensus nodes are provided in an order that includes a primary consensus node and a backup consensus node. The primary consensus node changes periodically. Transactions are added to the blockchain by consensus nodes within the blockchain network reaching an agreement on the world state of the blockchain network. In this process, messages are transmitted between consensus nodes, and each consensus node proves that the message is received from a specified peer node and verifies that the message has not been modified during transmission.

[0039] In PBFT, the consensus protocol is provided in multiple phases, and all consensus nodes start in the same state. First, the client sends a request to the primary consensus node to invoke a service operation (e.g., execute a transaction within the blockchain network). In response to receiving the request, the primary consensus node multicasts the request to the backup consensus nodes. The backup consensus nodes execute the request, and each node sends a reply to the client. The client waits until a threshold number of replies are received. In some examples, the client waits to receive f+1 replies, where f is the maximum number of faulty consensus nodes that can be tolerated in the blockchain network. The end result is that a sufficient number of consensus nodes agree on the order in which records are to be added to the blockchain, and the records are either accepted or rejected.

[0040] In some blockchain networks, cryptography is used to maintain transaction privacy. For example, if two nodes want to keep a transaction private so that other nodes in the blockchain network cannot see the details of the transaction, then the nodes can encrypt the transaction data. Exemplary encryption processes include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to the encryption process of using a single key for encryption (generating ciphertext from plaintext) and decryption (generating plaintext from ciphertext). In symmetric encryption, the same key can be used for multiple nodes, so each node can encrypt / decrypt transaction data.

[0041] Asymmetric encryption uses key pairs, each of which consists of a private key known only to the respective node and a public key known to any or all other nodes in the blockchain network. One node can encrypt data using the public key of another node, and the encrypted data can be decrypted using the private key of another node. For example, referring again to Figure 2 , participant A can encrypt data using participant B's public key and send the encrypted data to participant B. Participant B can decrypt the encrypted data (ciphertext) using its private key and extract the original data (plaintext). Messages encrypted using a node's public key can only be decrypted using that node's private key.

[0042] Asymmetric encryption is used to provide digital signatures, which enable participants in a transaction to confirm the other participants in the transaction and the validity of the transaction. For example, one node can digitally sign a message, and another node can confirm that the message was sent by participant A based on the digital signature of participant A. Digital signatures can also be used to ensure that the message has not been tampered with during transmission. For example, again referring to Figure 2 , Participant A will send a message to Participant B. Participant A generates a hash value of the message and then encrypts the hash value using its private key to provide a digital signature as an encrypted hash value. Participant A appends the digital signature to the message and sends the message with the digital signature to Participant B. Participant B decrypts the digital signature using Participant A's public key and extracts the hash. Participant B hashes the message and compares the hash values. If the hash values ​​are the same, Participant B can confirm that the message is indeed from Participant A and has not been tampered with.

[0043] In some embodiments, nodes of a blockchain network and / or nodes communicating with a blockchain network may operate using a TEE. At a high level, a TEE is a trusted environment within hardware (one or more processors, memory) that is isolated from the hardware's operating environment (e.g., operating system (OS), basic input / output system (BIOS)). In more detail, a TEE is an independent secure area of ​​a processor that ensures the confidentiality and integrity of code execution and data loaded in the main processor. Within the processor, the TEE runs in parallel with the OS. At least some of the so-called trusted applications (TAs) are executed within the TEE and have access to the processor and memory. Through the TEE, the TA is protected from other applications running in the main OS. In addition, the TEE cryptographically isolates TAs from each other within the TEE.

[0044] An example of a TEE includes Software Guard Extensions (SGX) provided by Intel Corporation of Santa Clara, California, U.S. Although SGX is discussed herein by way of example, it is contemplated that embodiments herein may be implemented using any suitable TEE.

[0045] SGX provides a hardware-based TEE. In SGX, the trusted hardware is a dead zone of the central processing unit (CPU), and a portion of the physical memory is isolated to protect selected code and data. The isolated portion of the memory is called an enclave. More specifically, the enclave is provided as an enclave page cache (EPC) in the memory and mapped to the application address space. The memory (e.g., DRAM) includes a reserved random access memory (PRM) for SGX. The PRM is a continuous storage space at the lowest BIOS level and cannot be accessed by any software. Each EPC is a set of memory (e.g., 4KB) that is allocated by the OS to load application data and code in the PRM. The EPC metadata (EPCM) is the entry address of each EPC and ensures that each EPC can only be shared by one enclave. That is, a single enclave can use multiple EPCs, and one EPC is dedicated to a single enclave.

[0046] During the execution of TA, the processor operates in the so-called enclave mode when accessing data stored in the enclave. Operation in enclave mode enforces additional hardware checks on each memory access. In SGX, TA is compiled into a trusted part and an untrusted part. The trusted part is not accessible by, for example, the OS, BIOS, privileged system code, virtual machine manager (VMM), system management mode (SMM), etc. In operation, TA runs and creates an enclave within the PRM of the memory. The trusted function executed by the trusted part within the enclave is called by the untrusted part, and the code executed within the enclave treats the data as plaintext data (unencrypted), and external access to the data is denied. The trusted part provides an encrypted response to the call and TA continues to execute.

[0047] An attestation process may be performed to verify that the intended code (e.g., a trusted portion of the TA) is securely executed within the TEE providing SGX. Typically, the attestation process includes the TA receiving an attestation request from a challenger (e.g., another node in the blockchain network, a key management system KMS of the blockchain network). In response, the TA asks its enclave to generate a remote attestation, also referred to as a quote. Generating the remote attestation includes sending the local attestation from the enclave to a so-called quote enclave, which verifies the local attestation and converts the local attestation to a remote attestation by signing the local attestation with an asymmetric attestation key. The remote attestation (quote) is provided to the challenger (e.g., the KMS of the blockchain network).

[0048] The challenger uses the attestation verification service to verify the remote attestation. For SGX, Intel provides the Intel Attestation Service (IAS), which receives the remote attestation from the challenger and verifies the remote attestation. More specifically, the IAS processes the remote attestation and provides a report (e.g., an attestation verification report (AVR)) that indicates whether the remote attestation is verified. If not verified, an error may be indicated. If verified (the expected code is securely executed in the TEE), the challenger may initiate or continue to interact with the TA. For example, in response to verification, the KMS (as a challenger) may issue an asymmetric encryption key (e.g., a public and private key pair) to the node executing the TEE (e.g., through a key exchange process such as Elliptic Curve Diffie-Hellman (ECDH)) to enable the node to communicate securely with other nodes and / or clients.

[0049] In some blockchain networks, so-called smart contracts can be executed. Smart contracts can be described as digital representations of real-world legal contracts with contractual terms that affect the parties. In an example context, smart contracts are implemented, stored, updated (as needed), and executed within a consortium blockchain network. Contracting parties (e.g., buyers and sellers) associated with a smart contract are represented as nodes in the consortium blockchain network. In some examples, contracting parties can include entities (e.g., commercial enterprises) associated with a smart contract (e.g., as parties to the smart contract).

[0050] In more detail, smart contracts are provided as computer executable programs that are executed on a blockchain (e.g., a node within a blockchain network). A smart contract contains a set of predefined rules under which the parties to the smart contract agree to interact with each other. If the predefined rules of the smart contract are met, the agreement defined in the smart contract is automatically executed. Smart contracts are generally tamper-proof and can facilitate, verify, and enforce the negotiation or execution of an agreement or transaction.

[0051] In some cases, smart contracts executed within a blockchain network require input from outside the blockchain network to evaluate predefined rules and perform corresponding actions. By way of non-limiting example, a smart contract may need to make a decision based on a stock quote that comes from a data source external to the blockchain network. As another non-limiting example, a smart contract may need to make a decision based on account information of an account maintained outside the blockchain network. However, a smart contract itself cannot directly query external data sources.

[0052] Traditional approaches include using a relay agent to retrieve external data and submit the data to the blockchain for processing by smart contracts. However, this processing may lead to security issues such as the leakage of secure information (e.g., credentials that may be required to access external data sources). For example, traditional approaches may use TEE to prove that the relay agent has honestly executed a specified query request. However, due to the openness of the blockchain, all query requests are visible to all users (nodes) in the blockchain network. Therefore, there is a risk of permission leakage for query requests that require access to external data sources that require access control (e.g., query). For example, there is a risk that the request string may be intercepted, modified, and replayed, resulting in information leakage or other issues.

[0053] In a conventional method of using SGX, a TA or a portion of a TA executed in an enclave (enclave program) acts as a relay node to access an external data source. For example, an enclave program can send a query request (e.g., an HTTPS request) to an Internet-based data source and can provide a response to the smart contract that initiated the request. In some examples, a privacy field function is provided, which can be used to encrypt sensitive information (e.g., access credentials) using the public key of the enclave. In some examples, the relay node decrypts the privacy field using the private key of the enclave, calls the HTTPS client to access the target Internet-based data source, receives the requested data, and digitally signs the returned data using the private key. After digital signing, the data will be returned to the smart contract that initiated the request.

[0054] However, this traditional approach has disadvantages. An exemplary disadvantage of directly encrypting the privacy field is that the request with the ciphertext of the privacy field has no integrity protection. For example, a user carries an encrypted API key field in a request to request all authorization information of an Internet-based data source. An attacker can intercept the communication. Although the attacker cannot directly decrypt the plaintext of the API key information, the attacker can modify the request to construct a request to access the information using the same privacy field and send it to the relay node. This may lead to the leakage of sensitive information (e.g., credentials).

[0055] In view of the above background, the embodiments of this document are intended to use a relay system and a TEE to query an external data source (e.g., an Internet-based data source). More specifically, as further described in detail herein, the embodiments of this document provide a multi-node cluster including multiple relay system nodes, each of which executes a TEE. The state of each relay system node is maintained, and in response to a client request for external data, a relay system node can be selected from the multi-node cluster. In this way, the availability of the relay system is guaranteed. The embodiments of this document further provide an authorization request integrity check while protecting sensitive information (e.g., credentials). In this way, as further described in detail herein, the embodiments of this document address the shortcomings of traditional methods, such as preventing user authority leakage.

[0056] Figure 3 300 . As shown, the system 300 includes a blockchain 302, a relay system controller 308, a multi-node cluster 309 including a plurality of relay system nodes 310, an authentication service 312, and a network 314 (e.g., the Internet). In the depicted example, the blockchain 302 includes a client smart contract 304 and a relay system smart contract 306. In general, the relay system smart contract 306, the relay system controller 308, and the relay system nodes 310 provide a relay system that enables data external to the blockchain 302 to be retrieved and used within the blockchain 302.

[0057] In some embodiments, the relay system node 310 is implemented using TEE technology (e.g., Intel SGX). Typically, the authentication service 312 verifies the legitimacy of the relay system node 310 for the client smart contract 304. Examples of authentication services include the IAS described above. As described herein, the relay system smart contract 306, the relay system controller 308, and the relay system node 310 operate together as a relay system to relay data or requests from the client smart contract 304 to the network 314 (e.g., an external data source accessible via the network 314), and relay data or request results from the network 314 to the client smart contract 304.

[0058] The client smart contract 304 is a smart contract that operates as a requester requesting data or services from the network 314. In some embodiments, the offline owner of the client smart contract 304 (e.g., a client or user (not shown)) can send data or requests to the client smart contract 304, or generate data or service requests at the client smart contract 304. The data or request can be a datagram element. The client smart contract 304 is communicatively coupled to the relay system contract 306. For example, the client smart contract 304 can send a request to the relay system smart contract 306 and receive a request result from the relay system smart contract 306.

[0059] As described above, the relay system smart contract 306, the relay system controller 308, and the relay system node 310 operate together as a relay system to relay data or requests from the client smart contract 304 to the network 314, and to relay data or request results from the network 314 to the client smart contract 304. The relay system smart contract 306 is a smart contract within the relay system that acts as a front end for the blockchain 302. The relay system smart contract 306 includes or operates as an application program interface (API) to the client smart contract 304 to process requests from the client smart contract 304 and relay the requests to other components of the relay system (e.g., the relay system controller 308), and to process request results from the relay system controller 308 and relay the request results to the client smart contract 304. In some embodiments, the relay system smart contract 306 verifies the signature associated with the request result before relaying the request result to the client smart contract 304. In short, the relay system smart contract 306 is a smart contract that provides an interface between the blockchain 302 and relay system components (e.g., the relay system controller 308) outside the blockchain 302. The relay system smart contract 306 accepts requests from components (e.g., the client smart contract 304) executed within the blockchain 302 and returns corresponding responses.

[0060] The relay system controller 308 includes any suitable computer, processor, module, or computing element for relaying requests from the relay system smart contract 306 to the relay system node 310, and relaying request results from the relay system node 310 to the relay system smart contract 306. Therefore, the relay system controller 308 operates as a monitoring entity that monitors the status of the relay system smart contract 306 because the relay system smart contract 306 is not directly connected to the network 314.

[0061] The relay system controller 308 also relays an authentication proof 320 indicating the legitimacy of the relay system node 310 from the relay system node 310 to the authentication service 312. In some embodiments, the authentication proof 320 includes a measurement 322 of the relay system node 310 and a signature 326 of the relay system node 310. The measurement 322 of the relay system node 310 may include a hash value of an initial state of the relay system node 310. The signature 326 of the relay system node 310 included in the authentication proof 320 may include the measurement 322 of the relay system node 310 signed using an authentication key of the relay system node 310.

[0062] In some embodiments, the authentication key of the relay system node 310 includes an Enhanced Privacy Identifier (EPID) private key. EPID is an algorithm provided by Intel for authenticating trusted systems while protecting privacy. Typically, each member of the network (e.g., a computer or server) is assigned an EPID private key for signing authentication evidence, and the verifier of the authentication evidence in the network stores the EPID public key paired with the EPID private key of other members of the network. Each member can use its own EPID private key to generate a signature for the authentication evidence, and the verifier can use the EPID public key to verify the signatures of other members. Therefore, the EPID key can be used to prove that a device (such as a computer or server) is a trusted device.

[0063] Authentication evidence 320 may further include public key 324 generated by relay system node 310. If authentication evidence 320 includes public key 324 generated by relay system node 310, signature 326 of relay system node 310 includes measurement value 322 and public key 324 signed using the authentication key of relay system node 310.

[0064] The relay system node 310 includes any suitable server, computer, module, or computing element to receive and complete requests from the blockchain 302. For example, the relay system node 310 can receive and process off-chain service requests from clients and query external data sources in the network 314, such as HTTPS-enabled Internet services. Before processing a request from a client or client smart contract 304, the relay system node 310 can generate an authentication proof 320 and send the authentication proof 320 to the authentication service 312 to verify the legitimacy of the relay system node 310. In some embodiments, the relay system node 310 generates a key pair including a public key 324 and a private key, and includes the public key 324 in the authentication proof 320. The public key 324 can be further relayed to the relay system smart contract 306 by the relay system controller 308 for future communication between the relay system smart contract 306 and the relay system node 310. For example, the relay system node 310 may sign the request result using a private key, and the relay system smart contract 306 may use the public key 324 to verify the signed request result.

[0065] exist Figure 3 In the depicted example, multiple relay system nodes 310 can form a multi-node cluster 309. Each relay system node 310 of the cluster is individually verified by the relay system smart contract 306 during the authentication process. Therefore, each verified relay system node 310 of the multi-node cluster 309 can be used to query the Internet data source 314.

[0066] The authentication service 312 includes any suitable server, computer, module or computing element to verify the legitimacy of the authentication evidence 320 forwarded from the relay system node 310 by the relay system controller 308. As described above, the authentication evidence 320 includes the measurement value 322 of the relay system node 310, the signature 326 of the relay system node 310, and / or the public key 324 generated by the relay system node 310. After receiving the authentication evidence 320, the authentication service 312 verifies the signature 326 of the relay system node 310 in the authentication evidence 320 and generates an authentication verification report (AVR) 330.

[0067] Authentication service 312 verifies signature 326 in authentication evidence 320 using an authentication key of authentication service 312. In some implementations, authentication key of authentication service 312 includes an EPID public key that is paired with an EPID private key used by relay system node 310 to sign authentication evidence 320. After verifying the signature in authentication evidence 320, authentication service 312 generates AVR 330 that includes authentication evidence 320, a verification result 334 indicating whether signature 326 in authentication evidence 320 is valid, and signature 336 of authentication service 312.

[0068] In some embodiments, the AVR 330 includes the authentication evidence 320 and does not include the signature 326 of the relay system node 310. For example, the AVR 330 may include the measurement 322 of the relay system node 310, the public key 324 generated by the relay system node 310, the verification result 334, and the signature 336 of the authentication service 312. In some embodiments, the signature 336 of the authentication service 312 includes the authentication evidence 320 and the verification result 334 signed using a report signing key of the authentication service 312 (e.g., a private key used by the authentication service 312 to sign the authentication verification report). Note that the report signing key may be different from the authentication key of the authentication service 312.

[0069] like Figure 3 The relay system shown in can be used to retrieve publicly available data and / or services from external data sources. The entire retrieval process includes three stages. In the first stage, the relay system smart contract 306 authenticates the relay system nodes 310 in the multi-node cluster 309 and registers (stores) the authenticated relay system nodes 310. In the second stage, the relay system controller 308 checks the status of the relay system nodes 310 in the multi-node cluster 309 and determines the available relay system nodes 310. In the third stage, the client smart contract 304 retrieves publicly available data and / or services from the external data source 314 through the relay system smart contract 306, the relay system controller 308 and the available relay system nodes 310 in the multi-node cluster 309.

[0070] Figure 4 An example of a signal flow 400 according to an embodiment of the present invention is shown. The signal flow 400 represents an authentication verification process. For convenience, the process will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to the present invention. For example, an appropriately programmed distributed system (e.g., Figure 1 Blockchain system 100; Figure 3 The system 300) can perform the processing.

[0071] Typically, in operation, the relay system controller 308 receives the authentication evidence from the relay system node 310 and sends the authentication evidence to the authentication service 312 to verify the authentication evidence. The relay system controller 308 receives an AVR from the authentication service 312, which indicates the legitimacy of the relay system node 310 based on the verification of the signature of the relay system node 310 in the authentication evidence. The relay system controller 308 further relays the AVR including the signature of the authentication service 312 to the relay system smart contract 306.

[0072] At the beginning, before challenging the relay system node 310 for authentication evidence, the relay system controller 308 obtains the measurement value (e.g., a summary of the initial state) of the relay system node 310. In some embodiments, the relay system controller 308 obtains the measurement value from the relay system node 310. In an alternative embodiment, the relay system controller 308 obtains the measurement value from the developer of the relay system node 310. The relay system controller 308 forwards the measurement value of the relay system node 310 to the relay system smart contract 306. The relay system smart contract 306 registers (stores) the measurement value of the relay system node 310 for future use. For example, the relay system smart contract 306 can compare the stored measurement value with another measurement value in the AVR received from the authentication service 312.

[0073] exist Figure 4 In an example of , the relay system controller 308 sends (410) an authentication request (e.g., a challenge) to the relay system node 310. The authentication request is sent to the relay system node 310 to request authentication evidence indicating the legitimacy or validity of the relay system node 310. In some embodiments, the authentication evidence includes a measurement of the relay system node 310 and a signature of the relay system node 310. The measurement of the relay system node 310 may include a hash value of an initial state of the relay system node 310. For example, the measurement of the relay system node 310 may include a hash value of a processing code implemented on the relay system node 310.

[0074] In response to the authentication request, the relay system node 310 generates (412) authentication evidence. As described above, the authentication evidence indicates the legitimacy or validity of the relay system node 310 and may include a measurement value and a signature of the relay system node 310. In some embodiments, the authentication evidence also includes a public key generated by the relay system node 310. For example, the relay system node 310 may generate a random encryption key pair including a private key and a public key using a predetermined key generation algorithm such as the Rivest-Shamir-Adleman (RSA) algorithm. In some examples, the public key is provided in the authentication evidence to be sent to the relay system smart contract 306 and may be used for future communications between the relay system smart contract 306 and the relay system node 310. For example, the relay system node 310 may sign the request result using the private key, and the relay system smart contract 306 may use the public key to verify the signed request result.

[0075] In some embodiments, the measurement value of the relay system node 310 includes a hash value of the initial state of the relay system node 310. The signature of the relay system node 310 in the authentication evidence includes the measurement value signed using the authentication key of the relay system node 310 and a public key generated by the relay system node 310. In some embodiments, the authentication key of the relay system node 310 includes an EPID private key. The authentication evidence signed using the EPID private key can be verified by a verifier using an EPID public key paired with the EPID private key to prove the authenticity of the device that generated the authentication evidence.

[0076] The relay system node 310 sends (414) authentication evidence to the relay system controller 308. The authentication evidence sent to the relay system controller 308 may include the measurement value of the relay system node 310, the public key generated by the relay system node 310, and the signature of the relay system node 310, the signature of the relay system node 310 including the measurement value and the public key signed using the EPID private key of the relay system node 310.

[0077] The relay system controller 308 forwards (416) the authentication evidence to the authentication service 312. In some implementations, the relay system controller 308 sends an authentication verification request to the authentication service 312. The authentication verification request includes the authentication evidence sent from the relay system node 310 and some supplementary information, such as, for example, a descriptor indicating whether the relay system node 310 uses SGX platform services.

[0078] In response to receiving the authentication evidence forwarded by the relay system controller 308, the authentication service 312 verifies (418) the authentication evidence. As previously described, the authentication evidence includes the measurement value of the relay system node 310, the public key generated by the relay system node 310, and the signature of the relay system node 310. The authentication service 312 can verify the authentication evidence by verifying the signature of the relay system node 310 in the authentication evidence using the authentication key of the authentication service 312. For example, the authentication service 312 can verify the signature of the relay system node 310 using the EPID public key of the authentication verification server, which is paired with the EPID private key used by the relay system node 310 to sign the authentication evidence.

[0079] If the authentication service 312 determines that the signature of the relay system node 310 in the authentication evidence is valid, the authentication service 312 can determine that the relay system node 310 is a real or legal device. If the authentication service 312 determines that the signature of the relay system node 310 in the authentication evidence is invalid, the authentication service 312 can determine that the relay system node 310 is an unauthentic or illegal device and reject any subsequent data and requests from the relay system node 310.

[0080] The authentication service 312 generates (420) an AVR based on the verification of the authentication evidence. In some embodiments, the AVR may include the authentication evidence of the relay system node 310, the authentication verification result, and the digital signature of the authentication service 312. In some embodiments, the AVR may include the authentication evidence of the relay system node 310, but not the signature of the relay system node 310. For example, the AVR may include the measurement value of the relay system node 310, the public key generated by the relay system node 310, the authentication verification result, and the signature of the authentication service 312.

[0081] The authentication verification result in the AVR indicates whether the signature of the relay system node 310 is valid. For example, the authentication verification result may include a value "valid" or "OK" indicating that the signature of the relay system node 310 is valid, or may include a value "invalid" indicating that the signature is invalid.

[0082] In some embodiments, the signature of the authentication service 312 includes the authentication evidence and the authentication verification result signed using a report signing key. The report signing key can be a private key used by the authentication service 312 to sign the AVR. In some embodiments, the report signing key is generated by the authentication service 312 using a predetermined key generation algorithm. For example, the report signing key can be generated using the RSA secure hash algorithm (SHA) 256. Note that the report signing key is different from the authentication key (e.g., the EPID public key) used by the authentication service 312 to verify the authentication evidence.

[0083] In some implementations, authentication service 312 sends (422) the AVR to relay system controller 308. As described above, the AVR includes a cryptographically signed identity verification report of relay system node 310 and may include authentication evidence of relay system node 310, authentication verification results, and the digital signature of authentication service 312.

[0084] In some embodiments, after receiving the AVR from the authentication service 312, the relay system controller 308 forwards (424) the AVR to the relay system smart contract 306. The relay system smart contract 306 verifies (426) the AVR. For example, the relay system smart contract 306 can verify the signature of the authentication service 312 in the AVR. In some embodiments, the relay system smart contract 306 uses a report signing certificate to verify the signature of the authentication service 312. The report signing certificate can be an X.509 digital certificate. The report signing certificate can include a public key that is generated by the authentication service 312 and is paired with a report signing key that the authentication service 312 uses to sign the AVR. If the relay system smart contract 306 verifies that the signature of the authentication service 312 in the AVR is valid, the relay system smart contract 306 determines that the AVR was indeed sent by the authentication service 312. If the relay system smart contract 306 determines that the signature of the authentication service 312 in the AVR is invalid, the relay system smart contract 306 determines that the authentication verification report is not authentic and will reject the AVR. The relay system smart contract 306 may further check the authentication verification result in the AVR to determine whether the authentication evidence of the relay system node 310 is valid. In some embodiments, the relay system smart contract 306 further compares the measurement value in the authentication evidence with the measurement value pre-stored in the relay system smart contract 306 to determine whether the authentication evidence is valid.

[0085] In response to determining that the AVR is authentic and the authentication proof of the relay system node 310 is valid, the relay system smart contract 306 registers (428) the relay system node 310 as a valid or legal device. The relay system smart contract 306 may further store a public key included in the authentication proof and generated by the relay system node 310. The public key will be used by the relay system smart contract 306 for future communications between the relay system smart contract 306 and the relay system node 310.

[0086] Figure 5 An example of a signal flow 500 according to an embodiment of the present invention is shown. Signal flow 500 represents a process for checking the node status of a relay system node 310 of a multi-node cluster 309 according to an embodiment of the present invention. For convenience, the process will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to the present invention. For example, an appropriately programmed distributed system (e.g., Figure 1 Blockchain system 100; Figure 3 The system 300) can perform the processing.

[0087] Typically, in operation, the relay system controller 308 periodically sends status requests to the relay system nodes 310 in the multi-node cluster 309. The relay system nodes 310 reply with status responses upon receiving the status requests. The relay system controller 308 records the status of the relay system nodes 310 based on their status responses.

[0088] In more detail, the relay system controller 308 sends a status request (502) to the relay system node 310a of the multi-node cluster 309. The multi-node cluster 309 includes a plurality of relay system nodes 310, for example, 310a and 310b. Note that Figure 5 The multi-node cluster 309 may include any suitable number of relay system nodes 310 , which are shown as including relay system nodes 310 a and 310 b for illustrative purposes only.

[0089] The relay system node 310a processes (504) the status request and sends (506) a status response to the relay system controller 308. For example, if the relay system node 310a is in a normal state, it may send a status confirmation message to the relay system controller 308. As another example, if the relay system node 310a is in an abnormal state, it may not respond to the status request.

[0090] The relay system controller 308 records (508) the status of the relay system node 310a based on the status response of the relay system node 310a. For example, if the relay system controller 308 receives a status confirmation message from the relay system node 310, it records the status of the relay system node 310a as "available". As another example, if the relay system node 310A does not respond within a predetermined time window, the relay system controller 308 records the status of the relay system node 310a as "unavailable".

[0091] The relay system controller 308 may send status requests to other relay system nodes 310 in the cluster, such as, for example, the relay system node 310 b. The relay system controller 308 may send (510) the status request to the relay system node 310 b, which processes (512) the status request and sends (514) a status response to the relay system controller 308. The relay system controller 308 records (516) the status of the relay system node 310 b based on the status response of the relay system node 310 b.

[0092] As described above, the relay system controller 308 periodically queries the node status of the relay system nodes 310 in the cluster and records the status of the relay system nodes 310. Later, when receiving a data query from an external data source, the relay system controller 308 can select one of the relay system nodes 310 that is recorded as available to process the query.

[0093] Figure 6 An example of a process 600 for performing data retrieval is shown. For convenience, process 500 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to the present invention. For example, an appropriately programmed distributed system (e.g., Figure 1 Blockchain system 100 and Figure 3 The system 300 may perform the process 600 .

[0094] Typically, in operation, the client smart contract 304 generates a request to be relayed by the relay system smart contract 306 to the relay system controller 308. The relay system controller 308 selects an available relay system node 310 in the multi-node cluster 309. The selected relay system node 310 queries the Internet data source 314. In some examples, the Internet data source 314 is a public data source and no credentials are required for access. The relay system node 310 receives a response from the Internet data source 314, and the relay system smart contract 306 verifies the response and returns it to the client smart contract 304 according to the embodiments of this document.

[0095] In more detail, the client smart contract 304 sends (602) a request for data or services from an Internet-based data source 314. The request is sent from the client smart contract 304 to the relay system smart contract 306. In some examples, the request may be a request for publicly available data of a publicly accessible website. The request may include a plaintext portion, such as a web address (URL) of the Internet data source 314 and one or more request parameters (e.g., parameters representing the requested data and / or services). In response to receiving the request, the relay system smart contract 306 forwards (604) the request as a log message to the relay system controller 308.

[0096] The relay system controller 308 selects (606) a relay system node 310 from a plurality of relay system nodes 310 in the multi-node cluster 309. For example, as described herein, the relay system controller 308 periodically queries the relay system nodes 310 in the multi-node cluster 309 and records the status of the relay system nodes 310. In some examples, the relay system controller 308 randomly selects a relay system node 310 from the available relay system nodes 310 in the cluster. In other examples, the relay system controller 308 selects an available relay system node 310 with the smallest workload from the relay system nodes 310 in the cluster.

[0097] The relay system controller 308 sends a request (608) to the relay system node 310 determined at 606. In some examples, the relay system controller 308 sends the request with an indicator of the relay system node 310 that is to receive the request (e.g., the relay system node 310 selected by the relay system controller 308). For example, the request can be modified by the relay system controller 308 to include an identifier (e.g., a URL) of the relay system node 310.

[0098] In response to receiving the request, the relay system node 310 queries (610) the Internet data source 314. For example, the relay system node 310 can formulate a query to request (e.g., using an HTTP GET method) data from the Internet data source 314. In some examples, the query can include one or more request parameters. In response to receiving the query, the Internet data source 314 processes (612) the query to provide a response. For example, the Internet data source 314 can process the one or more request parameters to identify data responsive to the one or more request parameters and provide a result including the data. The Internet data source 314 sends (614) the result to the relay system node 310.

[0099] The relay system node 310 processes (616) the result to provide a response. According to an embodiment of the present invention, the relay system node 310 signs the result using its private key to provide a response. As described herein, the private key is generated during remote authentication of the relay system node 310. In more detail, the result or at least a portion of the result (e.g., data) is processed by the relay system node 310 through a hash function to provide a first hash value. Examples of hash functions include, but are not limited to, SHA-256. The relay system node 310 generates a digital signature based on the first hash value and the private key. For example, the first hash value and the private key are processed by a signature algorithm that provides a digital signature. The relay system node 310 provides a response including the result (e.g., data) and the digital signature. The relay system node 310 sends a response (618) to the relay system controller 308, and the relay system controller 308 sends a response (620) to the relay system smart contract 306.

[0100] The relay system smart contract 306 processes (622) the response to verify that the response was sent by the registered relay system node 310 and to ensure the integrity of the response. As previously described, the relay system smart contract 306 registers (stores) the relay system node 310 authenticated during authentication. In some embodiments, the response may include a unique identifier (e.g., a URL) of the relay system node 310, and the relay system smart contract 306 may match the identifier in the response with the identifier (e.g., a URL) of the registered relay system node 310. If the match is successful, the relay system smart contract 306 determines that the response was sent by the registered relay system node 310 and may proceed to check the integrity of the response. If the match is unsuccessful, the relay system smart contract 306 determines that the response was not sent by the registered relay system node 310 and may reject the response.

[0101] According to an embodiment of the present disclosure, the relay system smart contract 306 further processes the result (e.g., data) through a hash function (e.g., SHA-256) to provide a second hash value. The relay system smart contract 306 processes the digital signature and public key of the relay system node 310 through a verification algorithm to provide a first hash value. For example, the relay system smart contract 306 decrypts the digital signature using the public key to display the first hash value. As described herein, the public key is generated during remote authentication of the relay system node 310.

[0102] The relay system smart contract 306 verifies the integrity of the response based on the first hash value and the second hash value. For example, the relay system smart contract 306 compares the first hash value to the second hash value. If the first hash value and the second hash value are different, the response has been tampered with and is untrustworthy. Therefore, the relay system smart contract 306 does not provide the result (e.g., data) to any downstream component (e.g., a client smart contract), and / or may flag an error. If the first hash value and the second hash value are the same, the integrity of the response is intact. Therefore, the relay system smart contract 306 provides (624) the result (e.g., data) to the client smart contract 304 for further processing.

[0103] Figure 7 An example of a process 700 that may be performed according to embodiments of the present invention is shown. In some embodiments, the example process 700 may be performed using one or more computer executable programs that are executed using one or more computing devices. In some examples, the example process 700 may be performed by a relay system for retrieving data external to a blockchain network (e.g., a relay system smart contract 306, a relay system controller 308, Figure 3 Relay system node 310).

[0104] A request is received (702). For example, Figure 3 The relay system controller 308 receives a request from the client smart contract 304 through the relay system smart contract 306. In some examples, as described herein, the client smart contract 304 generates a request that includes an identification of a data source to be queried (e.g., a URL) and one or more request parameters. Select a relay system node 310 (704). For example, the relay system controller 308 selects an available relay system node 310 in the multi-node cluster 309. In some embodiments, the relay system controller 308 randomly selects an available relay system node 310 in the cluster. In an optional embodiment, the relay system controller 308 selects an available relay system node 310 with the smallest workload among the relay system nodes 310 in the cluster. Send a request (706). For example, the relay system controller 308 forwards the request to the selected relay system node 310.

[0105] Query the data source (708). For example, the relay system node 310 constructs a query (e.g., a new request) that includes one or more request parameters of the request it received (e.g., the initial request). For example, the new request may include a plaintext data element that includes the URL of the Internet data source 314 to be queried and one or more request parameters. The relay system node 310 uses the query to query the Internet-based data source 314.

[0106] Receive a result from a data source (710). In some examples, the Internet-based data source 314 processes the query and returns a request result (e.g., a data value) to the relay system node 310. Prepare a response (712), and send the response (714). For example, the relay system node 310 can generate a signature that includes the request result signed using a private key of the relay system node 310, as described herein. The private key used by the relay system node 310 to sign the request result is generated during an earlier remote authentication of the relay system node 310.

[0107] Receive a response and determine whether the response is valid (716). For example, the relay system smart contract 306 processes the response to verify whether the response is sent by the registered relay system node 310 and ensure the integrity of the response. In some embodiments, the response may include a unique identifier (e.g., a URL) of the relay system node 310, and the relay system smart contract 306 may match the identifier with the identifier (e.g., URL) of the registered relay system node 310. If the match is successful, the relay system smart contract 306 determines that the response is sent by the registered relay system node 310 and may continue to check the integrity of the response. If the match is unsuccessful, the relay system smart contract 306 determines that the response is not sent by the registered relay system node 310.

[0108] To check the integrity of the response, the relay system smart contract 306 calculates a hash value based on the request result (e.g., data value). The relay system smart contract 306 then uses the public key to obtain the hash value of the request result and determines whether it matches the calculated hash value. If the two hash values ​​match, the relay system smart contract 306 determines that the request result is valid. If the two hash values ​​do not match, the relay system smart contract 306 determines that the request result is invalid and can reject the request result. If the response is not sent by the registered relay system node 310 and / or the request result is invalid, an error is indicated (718) and the exemplary process 700 ends. If the response is sent by the registered relay system node 310, the request result is valid and the integrity of the request result remains unchanged, then the request result is used (720). For example, the result is provided to the client smart contract 304 for further processing.

[0109] As described herein, the embodiments of this invention achieve one or more technical effects compared to traditional systems. In some embodiments, a multi-node cluster of relay system nodes is provided for retrieving or accessing data and / or services from an external data source, wherein the status of the relay system nodes in the multi-cluster is periodically checked and recorded by the relay system controller. As described herein, by deploying the relay system nodes in a multi-node cluster, the relay system controller can automatically assign client service requests to available relay system nodes in the multi-node cluster to avoid service unavailability due to a single node failure. Therefore, the embodiments of this invention improve the overall service availability of the relay system for querying Internet data sources. In some embodiments, the integrity of the response provided back to the blockchain network from the external data source is ensured. Therefore, the embodiments of this invention improve the integrity of the communication between the components of the blockchain network and the relay system, and the components of the relay system are used to retrieve data outside the blockchain network. In this way, the potential attack channels of malicious users are reduced to enhance security. In some embodiments, the relay system avoids direct contact between the user and the relay system node, thereby avoiding exposing the location or access point of the relay system node. Therefore, the relay system node is less likely to be discovered and attacked in various forms by malicious participants on the network, such as, for example, DDoS attacks. This improves the security of the relay system nodes, which in turn further improves the security of communications between the blockchain network and the relay system nodes.

[0110] Figure 8 An example of a module of an apparatus 800 according to an embodiment of the present invention is shown. The apparatus 800 can be an example implementation of a relay system smart contract executed within a blockchain network. In some examples, the relay system smart contract sends requests to one or more components of the relay system outside the blockchain network and receives responses from these components, as well as queries data sources outside the blockchain network.

[0111] The device 800 may correspond to the implementation described above, and the device 800 includes the following: a receiving module 802, which is used to receive a request for data from a data source; a sending module 804, which is used to send the request to a multi-node cluster outside the blockchain network, the multi-node cluster including multiple relay system components; a receiving module 806, which is used to receive a result of the relay system component from the multi-node cluster, and the result is digitally signed using the private key of the relay system component; a verification module 808, which is used to verify whether the relay system component is registered on the relay system smart contract; a verification module 810, which is used to verify the integrity of the result based on the public key of the relay system component and the digital signature of the result in response to verifying that the relay system component is registered; and a sending module 812, which is used to send the result to a client within the blockchain network in response to verifying the integrity of the result.

[0112] Generally, the innovative aspects of the subject matter described herein can be implemented by the following operations: a relay system smart contract executed within a blockchain network receives a request for data from a data source, the relay system smart contract sends the request to a relay system, which is external to the blockchain network and includes a multi-node cluster, the multi-node cluster includes multiple relay system nodes, the relay system smart contract receives a result provided from a relay system node of the multi-node cluster, the result is digitally signed using a public key of the relay system node, the relay system smart contract verifies that the relay system node is registered on the relay system smart contract; in response to the relay system node being registered, the relay system smart contract verifies the integrity of the result based on the public key of the relay system node and the digital signature of the result, and in response to verifying the integrity of the result, sends the result to a client within the blockchain network.

[0113] The above and other embodiments may each optionally include one or more of the following features individually or in combination: the relay system controller periodically sends status queries to multiple relay system nodes in a multi-node cluster and receives status responses from multiple relay system nodes; if a status response is received from a relay system node in the multi-node cluster within a predetermined time window, the relay system controller records the status of the relay system node as available; if no status response is received from a relay system node in the multi-node cluster within a predetermined time window, the relay system controller records the status of the relay system node as unavailable; the relay system controller selects a relay system node in the multi-node cluster with an available status, and The request is sent to the relay system node; the relay system smart contract verifies the integrity of the result by comparing a first hash value with a second hash value, wherein the first hash value is determined by decrypting the digital signature using a public key, and the second hash value is calculated using the result and the hash function; the relay system node executes a trusted execution environment (TEE), and the private key and public key of the relay system node are provided during the authentication process of the TEE; the relay system controller performs authentication processing on each relay system node in the multi-node cluster, and the relay system controller provides the public key of each relay system component to the relay system smart contract; the data source includes an Internet-based data source; the client includes a client smart contract.

[0114] The systems, devices, modules or units shown in the previous embodiments may be implemented by using a computer chip or entity, or may be implemented by using a product with specific functions. A typical implementation device is a computer, which may 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 transceiver device, a game console, a tablet computer, a wearable device or any combination of these devices.

[0115] The systems, devices, modules or units shown in the above embodiments may be implemented using a computer chip or entity, or may be implemented using a product with specific functions. A typical implementation device is a computer, which may be a personal computer, a laptop, a mobile phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, a game console, a tablet computer, a wearable device or any combination of these devices.

[0116] For the implementation process of the functions and effects of each unit in the device, reference can be made to the implementation process of the corresponding steps in the previous method. For the sake of simplicity, the details are omitted here.

[0117] Since the device implementation method basically corresponds to the method implementation method, for the relevant parts, reference may be made to the relevant description in the method implementation method. The device implementation method described above is only an example. The units described as independent parts may or may not be physically independent, and the parts shown as units may or may not be physical units, may be located in one location, or may be distributed on multiple network units. Some or all modules may be selected based on actual needs to achieve the objectives of the technical solutions of this article. A person of ordinary skill in the art can understand and implement the implementation methods of this article without creative efforts.

[0118] The embodiments and actions and operations of the subject matter described herein may be implemented in digital electronic circuits, tangible computer software or firmware, computer hardware (including the structures disclosed herein and their structural equivalents), or may be implemented in one or more combinations thereof. The embodiments of the subject matter described herein may be implemented as one or more computer programs, for example, one or more modules of computer program instructions, encoded on a computer program carrier for execution by a data processing device or for controlling the operation of a data processing device. The carrier may be a tangible, non-transitory computer storage medium. Alternatively or additionally, the carrier may be an artificially generated propagation signal, for example, a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to an appropriate receiving device for execution by a data processing device. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access storage device, or a combination of one or more thereof, or may be part of a machine-readable storage device, a machine-readable storage substrate, a random or serial access storage device, or a combination of one or more thereof. A computer storage medium is not a propagation signal.

[0119] The term "data processing apparatus" includes various devices, apparatus and machines for processing data, including, for example, a programmable processor, a computer or multiple processors or computers. The data processing apparatus may include special-purpose logic circuits, such as a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or a graphics processing unit (GPU). In addition to hardware, the device may also include code that creates an execution environment for a computer program, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0120] A computer program, which may also be referred to or described as a program, software, software application, application, module, software module, engine, script or code, may be written in any form of programming language (including compiled or interpreted languages, declarative or procedural languages); it may be deployed in any form, including as a stand-alone program or as a module, component, engine, subroutine or other unit suitable for execution in a computing environment, which may include one or more computers interconnected at one or more locations by a data communications network.

[0121] A computer program may, but need not, correspond to a file in a file system. A computer program may be stored as part of a file that holds other programs or data, such as one or more scripts in a markup language document, a single file dedicated to a related program, or multiple coordinated files, such as a file storing one or more modules, subroutines, or portions of code.

[0122] The processes and logic flows described herein may be performed by one or more computers executing one or more computer programs to perform operations by operating on input data and generating output. The processes and logic flows may also be performed by a special purpose logic circuit (e.g., an FPGA, ASIC, or GPU) or a combination of a special purpose logic circuit and one or more programmed computers.

[0123] Computers suitable for executing computer programs may be based on general or special purpose microprocessors, or both, or any other type of central processing unit. Typically, the central processing unit will receive instructions and data from a read-only memory or a random access memory, or both. Elements of a computer may include a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory may be supplemented or incorporated by special purpose logic circuits.

[0124] Typically, a computer will also include one or more mass storage devices, or be operably coupled to receive data from or transfer data to one or more mass storage devices. The mass storage device may be, for example, a magnetic disk, a magneto-optical disk, an optical disk, or a solid-state drive. However, a computer need not have such a device. In addition, a computer may be embedded in other devices, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few examples.

[0125] To provide interaction with a user, embodiments of the subject matter described herein may be implemented on or configured to communicate with a computer having a display device (e.g., an LCD (liquid crystal display) display) for displaying information to a user and an input device through which a user can provide input to the computer, such as a keyboard and a pointing device, such as a mouse, trackball, or touchpad. Other types of devices may also be used to provide interaction with a user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; the user's input may be received in any form, including sound, voice, or tactile input. In addition, a computer may interact with a user by sending documents to and receiving documents from a device used by a user; for example, by sending a web page to a web browser on a user's device in response to a request received from the web browser, or by interacting with an application running on a user's device (e.g., a smartphone or electronic device). In addition, a computer may interact with a user by sending text messages or other forms of messages to a personal device (e.g., a smartphone running a messaging application) and receiving a response message from the user.

[0126] The term "configured to" is used herein with respect to systems, devices, and computer program components. With respect to a system of one or more computers, being configured to perform a particular operation or action means that the system has installed thereon software, firmware, hardware, or a combination thereof that, when run, causes the system to perform the operation or action. With respect to one or more computer programs, being configured to perform a particular operation or action means that the one or more programs include instructions that, when executed by a data processing device, cause the device to perform the operation or action. With respect to a special purpose logic circuit, being configured to perform a particular operation or action means that the circuit has electronic logic to perform the operation or action.

[0127] Although this document contains many specific implementation details, it should not be interpreted as limiting the scope of the claims, which are defined by the claims themselves, but rather as a description of specific features of specific implementations. Certain features described herein in the context of separate implementations may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented in multiple implementations, either individually or in any suitable sub-combination. In addition, although the above features may be described as working in certain combinations, and may even be initially claimed as such, one or more features of the claimed combination may be deleted from the combination in some cases, and the claims may be directed to sub-combinations or variations of sub-combinations.

[0128] Likewise, although operations are depicted in the drawings and stated in the claims in a particular order, this should not be construed as requiring that such operations be performed in the particular order shown or in sequential order, or that all of the operations shown be performed to obtain the desired results. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above-described embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

[0129] Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the operations described in the claims can be performed in a different order and still achieve the desired results. As an example, the processes shown in the accompanying drawings do not necessarily require the particular order or sequential order shown to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous.

Claims

1. A computer-implemented method for retrieving data from a data source located outside a blockchain network, the method being applied to a relay system smart contract executed within the blockchain network, the method comprising: receiving a request from a client within the blockchain network for data from the data source; The request is sent to a relay system controller of a relay system located outside the blockchain network, so that the relay system controller selects a relay system node with an available status and sends the request to the relay system node; wherein the relay system controller periodically sends status queries to multiple relay system nodes, and records the status of the relay system nodes that have fed back status responses within a preset time window as available; receiving a result provided from the relay system node, the result having a digital signature generated using a private key of the relay system node, the result including the requested data from the data source; In response to verifying that the relay system node is registered on the relay system smart contract, verifying the integrity of the result based on the public key of the relay system node and the digital signature, and in response to verifying the integrity of the result, sending the result to the client.

2. The method according to claim 1, wherein the verifying the integrity of the result based on the public key of the relay system node and the digital signature comprises: The integrity of the result is verified by comparing a first hash value determined by decrypting the digital signature using the public key with a second hash value calculated using the result and a hash function.

3. The method according to claim 1, wherein: The relay system node executes a trusted execution environment TEE, and the public key and the private key of the relay system node are provided during an authentication process of the TEE.

4. The method according to claim 3, wherein: The relay system controller performs the authentication process on each relay system node, and the relay system controller provides the public key of each relay system node to the relay system smart contract.

5. The method according to claim 1, wherein: The data source includes an Internet-based data source.

6. The method according to claim 1, wherein: The client includes a client smart contract.

7. The method according to claim 1, wherein: The relay system controller records the status of the relay system node that has not fed back a status response within a preset time window as unavailable.

8. The method according to claim 3, wherein: The TEE includes: software protection extension SGX.

9. A device for retrieving data from a data source located outside a blockchain network, the device comprising a plurality of modules for executing the method of any one of claims 1 to 8.

10. A system for retrieving data from a data source located outside a blockchain network, comprising: one or more computers; as well as One or more computer-readable memories, coupled to the one or more computers and having instructions stored thereon, the instructions being executable by the one or more computers to perform the method of any one of claims 1 to 8.

Images