HK40017317B - Off-chain smart contract service based on trusted execution environment - Google Patents

Description

Off-chain smart contract services based on trusted execution environment

Background Technology

Distributed ledger systems (DLS), also known as consensus networks and/or blockchain networks, enable participating entities to securely and immutably store data. Without referencing any specific use case, DLS is often simply referred to as a blockchain network. Example types of blockchain networks can include public, private, and consortium blockchain networks. Public blockchain networks are open to all entities to use the DLS and participate in the consensus process. Private blockchain networks are provided for specific entities that centrally control read and write permissions. Consortium blockchain networks are provided for selected groups of entities that control the consensus process and include an access control layer.

Blockchain is a decentralized and tamper-proof distributed data storage technology. User data and contracts are logically operated and stored on the chain in a public manner. In many scenarios, users need to meet privacy protection requirements and do not want their data and logic to be disclosed to unauthorized parties.

While cryptography can be used to design enhanced privacy protections for certain specific scenarios, a more general and efficient solution is expected to address existing privacy issues in blockchain operations.

Summary of the Invention

The embodiments described herein include a computer-implemented method for off-chain smart contract services based on blockchain technology (referred to as blockchain off-chain smart contract services, or simply smart contract services). More specifically, the embodiments described herein aim to provide off-chain smart contract services capable of operating cross-chain data within a trusted execution environment (TEE).

In some embodiments, the actions include: a smart contract service provider, including a Trusted Computing Execution Environment (TEE), receiving from a client associated with a target blockchain network a request for cross-chain data to operate on one or more blockchain networks different from the target blockchain network, the smart contract service provider being located outside the target blockchain network; the smart contract service provider sending the request for the cross-chain data to a data access service provider; the smart contract service provider receiving the cross-chain data from the data access service provider; the TEE generating a result using the cross-chain data; and the smart contract service provider returning the result to the client. Other embodiments include corresponding systems, apparatuses, and computer programs encoded on a computer storage device and configured to perform the actions of the method.

In some embodiments, a non-transitory computer-readable storage medium is coupled to one or more computers and configured to execute instructions executable by one or more computers to perform the following: receiving, from a client associated with a target blockchain network, a smart contract service provider including a Trusted Computing Execution Environment (TEE) requesting cross-chain data for operating one or more blockchain networks different from the target blockchain network, wherein the smart contract service provider is outside the target blockchain network; sending the request for the cross-chain data to a data access service provider; receiving the cross-chain data from the data access service provider; generating a result using the cross-chain data via the TEE; and returning the result to the client.

In some embodiments, a system for providing smart contract services includes: an interface configured to receive, from a client associated with a target blockchain network, a request for cross-chain data to operate on one or more blockchain networks different from the target blockchain network; wherein the system is located outside the target blockchain network; and a trusted computing execution environment (TEE), wherein the TEE includes: one or more computers; and one or more computer-readable storage devices coupled to the one or more computers and configured to execute instructions executable by the one or more computers to: send a request for cross-chain data to a data access service provider; receive cross-chain data from the data access service provider; and generate a result using the cross-chain data; and wherein the interface is configured to return the result to the client.

These and other embodiments may each optionally include one or more of the following features:

The first feature can be combined with any of the following features, wherein the request for manipulating cross-chain data includes smart contract computation logic for manipulating cross-chain data.

The second feature can be combined with any of the following features, wherein the smart contract computation logic used to manipulate cross-chain data is designed by the client itself.

The third feature can be combined with any of the following features, where the result is generated by the TEE using cross-chain data to execute smart contract computation logic.

The fourth feature, which may be combined with any of the following features, also includes the smart contract service provider certifying to the client that the TEE includes a virtual machine operable to execute the smart contract computation logic in a request for manipulating cross-chain data.

The fifth feature, which may be combined with any of the following features, also includes the smart contract service provider certifying to the client that the smart contract service provider includes a TEE before receiving a request from the client for manipulating cross-chain data.

The sixth feature, which may be combined with any of the following features, also includes the smart contract service provider proving to the data access service provider that the smart contract service provider includes the TEE; and the smart contract service provider verifying that the data access service provider includes the TEE.

The seventh feature, which may be combined with any of the following features, also includes the upload of the results to the target blockchain network by the smart contract service provider.

The eighth feature, which may be combined with any of the following features, also includes uploading the result to the target blockchain network, whereby the smart contract service provider proves to the target blockchain network that the smart contract service provider includes a TEE.

The ninth feature can be combined with any of the following features, wherein the smart contract service provider includes cloud-based servers.

The tenth feature can be combined with any of the following features, where the result is signed by the TEE using a private key.

The eleventh feature can be combined with any of the following features, where cross-chain data is obtained from two or more blockchain networks.

In some embodiments, the actions include: a client associated with a target blockchain network generating a request for operating cross-chain data on one or more blockchain networks different from the target blockchain network, wherein the request for operating the cross-chain data includes smart contract computation logic for operating the cross-chain data; sending the request for operating the cross-chain data from the client to a smart contract service provider including a Trusted Computing Execution Environment (TEE), wherein the smart contract service provider is located outside the target blockchain network; and the client receiving a result from the smart contract service provider, wherein the result is generated by the TEE using the cross-chain data obtained by the smart contract service provider. Other embodiments include corresponding systems, apparatuses, and computer programs encoded on a computer storage device and configured to perform the actions of the method.

In some embodiments, a non-transitory computer-readable storage medium is coupled to one or more computers and configured to execute instructions executable by the one or more computers to implement the following: generating a request from a client associated with a target blockchain network for operating cross-chain data on one or more blockchain networks different from the target blockchain network, wherein the request for operating the cross-chain data includes smart contract computation logic for operating the cross-chain data; sending the request for operating the cross-chain data from the client to a smart contract service provider including a Trusted Computing Execution Environment (TEE), wherein the smart contract service provider is located outside the target blockchain network; and receiving a result from the smart contract service provider by the client, wherein the result is generated by the TEE using the cross-chain data obtained by the smart contract service provider.

In some embodiments, a system includes: one or more computers; and one or more computer-readable storage devices coupled to the one or more computers and configured to execute instructions executable by the one or more computers to implement: generating a request from a client associated with a target blockchain network for operating cross-chain data on one or more blockchain networks different from the target blockchain network, wherein the request for operating the cross-chain data includes smart contract computation logic for operating the cross-chain data; sending the request for operating the cross-chain data from the client to a smart contract service provider including a trusted computing execution environment (TEE), wherein the smart contract service provider is located outside the target blockchain network; and receiving a result from the smart contract service provider by the client, wherein the result is generated by the TEE using the cross-chain data obtained by the smart contract service provider.

These and other embodiments may each optionally include one or more of the following features:

The first feature, which may be combined with any of the following features, also includes the client sending the received result to the target blockchain network.

The second feature, which may be combined with any of the following features, also includes the client verifying that the smart contract service provider includes a TEE before sending a request for manipulating cross-chain data to the smart contract service provider.

The third feature, which may be combined with any of the following features, also includes client-verified TEE comprising a virtual machine operable to execute smart contract computation logic in requests for manipulating cross-chain data.

The fourth feature, which can be combined with any of the following features, also includes smart contract computation logic designed by the client to manipulate cross-chain data.

The fifth feature can be combined with any of the following features, wherein the client includes a software development kit (SDK).

The sixth feature can be combined with any of the following features, wherein the result is signed by the TEE using a private key, and the method also includes the client decrypting the received result using a public key corresponding to the private key.

The seventh feature, which may be combined with any of the following features, also includes having the client encrypt the request for manipulating cross-chain data before sending the request to the smart contract service provider.

The eighth feature can be combined with any of the following features, where cross-chain data is obtained from two or more blockchain networks.

This document also provides one or more non-transitory computer-readable storage media coupled to one or more processors and storing instructions thereon that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

This document also provides a system for implementing the methods provided herein. The system includes one or more processors and a computer-readable storage medium coupled to and storing instructions thereon that, when executed by the one or more processors, cause the one or more processors to perform operations according to embodiments of the methods provided herein.

The described off-chain smart contract service provider is not coupled to any specific blockchain network, therefore the services offered are not limited to specific types of contracts (e.g., configured for a specific blockchain network), but rather support user-defined off-chain computation. Furthermore, the described off-chain smart contract service provider supports cross-chain data access and allows untrusted parties to run smart contracts on private data from one or more blockchain networks. The described technology offers several advantages. For example, using a TEE as a temporary medium for performing computations can protect data privacy. Additionally, offloading computational tasks from the blockchain network to an off-chain TEE can save computation time and resources on the blockchain network. Moreover, since users can design their own computational logic according to their needs and requirements, the TEE uses this logic to perform computations, and can execute various computations in a more flexible manner.

It should be understood that the method described herein may include any combination of the aspects and features described herein. That is, the method described herein is not limited to the specific combination of aspects and features described herein, but also includes any combination of aspects and features provided.

Details of one or more embodiments thereof are set forth in the accompanying drawings and the following description. Other features and advantages of this document will become apparent from the specification, the drawings, and the claims.

Attached Figure Description

Figure 1 illustrates an example of an environment that can be used to perform the embodiments described herein.

Figure 2 illustrates an example of a conceptual structure according to an embodiment of this document.

Figure 3 illustrates an example of a process for providing cross-chain data services to a client according to embodiments of this document.

Figure 4 illustrates an example of a process that can be performed according to embodiments of this document.

Figure 5 illustrates an example of a module of a cross-chain data manipulation apparatus according to an embodiment of this document.

Figure 6 depicts an example illustration of a module showing another cross-chain data manipulation device according to an embodiment of this document.

The same reference numerals in each figure represent the same elements.

Detailed Implementation

The embodiments described herein include a computer-implemented method for an off-chain smart contract service based on blockchain technology (referred to as a blockchain off-chain smart contract service, or simply a smart contract service). More specifically, the embodiments described herein aim to provide off-chain smart contract services capable of operating cross-chain data in a trusted execution environment.

To provide further background for the embodiments described herein, and as stated above, a distributed ledger system (DLS), also known as a consensus network (e.g., composed of peer-to-peer nodes) and a blockchain network, enables participating entities to securely and immutably transact and store data. The term blockchain, as used herein, generally refers to a DLS without reference to any particular use case.

A blockchain is a data structure that stores transactions in a way that makes them immutable and subsequently verifiable. A blockchain consists of one or more blocks. Each block in the chain is linked to the preceding block by including its cryptographic hash. Each block also includes a timestamp, its own cryptographic hash, and one or more transactions. Transactions verified by nodes in the blockchain network are hashed and encoded into a Merkle tree. A Merkle tree is a data structure where data at the leaf nodes is hashed, and all hashes in each branch of the tree are linked to the root of that branch. This process continues along the tree to the root, where hashes representing all the data in the tree are stored. Hashes claiming to be stored in the tree can be quickly verified by determining if they are consistent with the tree's structure.

While a blockchain is a data structure used to store transactions, a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains. As mentioned above, blockchain networks can be provided as public, private, or consortium blockchain networks.

In public blockchain networks, the consensus process is controlled by the nodes of the consensus network. For example, hundreds, thousands, or even millions of entities can collaboratively operate a public blockchain network, with each entity operating at least one node within the network. Therefore, a public blockchain network can be considered a public network in terms of the participating entities. In some examples, a majority of entities (nodes) must sign each block for it to be valid and added to the blockchain (distributed ledger) of the blockchain network. Exemplary public blockchain networks include specific peer-to-peer payment networks that utilize distributed ledgers (called blockchains). However, as mentioned above, the term blockchain is generally used to refer to a distributed ledger and not specifically to any particular blockchain network.

Generally, public blockchain networks support public transactions. Public transactions are shared by all nodes within the public blockchain network and stored in the global blockchain. The global blockchain is a blockchain replicated across all nodes. That is, for the global blockchain, all nodes are in full state consensus. To reach consensus (e.g., agreeing to add a block to the blockchain), a consensus protocol is implemented within the public blockchain network. Examples of consensus protocols include, but are not limited to, Proof-of-Work (PoW), Proof-of-Stake (PoS), and Proof-of-Authority (PoA). PoW is further cited in this document as a non-restrictive example.

Generally, private blockchain networks are provided for a specific entity that centrally controls read and write permissions. This entity controls which nodes can participate in the blockchain network. Therefore, private blockchain networks are often referred to as permissioned networks, which restrict who is allowed to participate in the network and their level of participation (e.g., only in certain transactions). Various types of access control mechanisms can be employed (e.g., existing participants vote to add new entities, and regulatory bodies can control permissions).

Generally, consortium blockchain networks are private among the participating entities. In a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, one or more of which are operated by their respective entities (e.g., financial institutions, insurance companies). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, with each entity operating at least one node in the network. Therefore, a consortium blockchain network can be viewed as a private network associated with the participating entities. In some examples, each entity (node) must sign each block for it to be valid and added to the blockchain. In some examples, at least a subset of the entities (nodes) (e.g., at least seven entities) must sign each block for it to be valid and added to the blockchain.

A blockchain is a tamper-proof, shared digital ledger used to record transactions in public or private peer-to-peer networks. The ledger is distributed to all member nodes in the network, and the history of asset transactions occurring within the network is permanently recorded in blocks. Before participating in a transaction, nodes on a blockchain may need to perform computations using various technologies. Under current solutions, because each blockchain is independent, a node on one blockchain cannot communicate with other chains. For example, a node cannot read data from or exchange data with other blockchains. Furthermore, if complex computational logic and protocols are required, performing such computations entirely on the blockchain itself can consume significant computational resources and time, even if the node does not require data from other blockchains to perform the computation.

The embodiments described herein are further described in detail with reference to consortium blockchain networks, which are public among the participating entities. However, it is contemplated that the embodiments described herein can be implemented in any suitable type of blockchain network.

In light of the above background, the embodiments described herein are further described in detail. More specifically, as stated above, the embodiments described herein aim to provide off-chain smart contract services capable of operating cross-chain data in a trusted execution environment.

Technologies for addressing these issues may include using off-chain smart contract services to perform computations and manipulate cross-chain data. Smart contracts can be computer protocols designed to disseminate, verify, or enforce contracts in an informational manner. Smart contracts allow for the execution of trusted transactions without the involvement of third parties. These transactions are traceable and irreversible. Smart contracts include logic or computer programs that embody the protocols or rules of the transaction. For example, a smart contract may include logic that controls the transfer of digital currency or assets between parties under specific conditions. Smart contracts can be coded in programming languages and deployed to a blockchain network runtime platform.

In some embodiments, off-chain processing can be used to execute or enforce smart contracts. For example, the logic included in a smart contract can be executed outside the boundaries of the blockchain network, for instance, by an off-chain smart contract service provider, while still maintaining the trust and transparency of the blockchain network. For example, the off-chain smart contract service provider can be a computer, server, or other type of data processing device independent of the blockchain network. Through off-chain processing, smart contract logic can be executed in a Trusted Execution Environment (TEE) to maintain the trust and transparency of the blockchain network. A TEE can be used to execute the logic in a smart contract and perform other operations and transactions included in the smart contract outside the blockchain network. A TEE can bind code to a smart contract and provide various services such as authentication, key management, cerographical services, and interaction with the outside world. The trusted environment of the TEE ensures that only authorized code is allowed to access data, and this protection is enforced throughout the execution of the code within it. In some embodiments, the execution results of a smart contract returned by an off-chain smart contract service can be uploaded or otherwise transmitted to the blockchain network, for example, to update the state of the blockchain network. Therefore, off-chain smart contract service providers can offload computational loads from the blockchain network and have greater flexibility in executing different, complex computational logics and protocols.

In some embodiments, the described off-chain smart contract service provider is not coupled to any specific blockchain network, and therefore the services provided are not limited to a specified form of contract (e.g., configured for a specific blockchain network), but support user-defined off-chain computation.

Furthermore, the described off-chain smart contract service provider supports cross-chain data access and allows mutually distrustful parties to run smart contracts on private data from one or more blockchain networks. For example, a client on blockchain network A can define a smart contract that operates not only on client data from blockchain network A but also on data from a different blockchain network, blockchain network B. In some embodiments, the client invokes an off-chain contract service to execute its defined smart contract. The off-chain contract service can obtain the requested data from blockchain networks A and B, execute the client-defined smart contract outside of blockchain networks A and B to obtain the result, and then submit the result to blockchain network A to update the client's state.

Exemplary techniques are described to enable blockchain network nodes to perform complex computations and use data from one or more other blockchain networks to perform these computations more easily. These exemplary techniques may be based on a Trusted Execution Environment (TEE). A TEE is a secure area on a host processor that ensures the security, confidentiality, and integrity of code and data loaded into the environment. A TEE provides an isolated execution environment (e.g., using dedicated and isolated hardware) with multiple security features such as isolated execution, integrity of trusted applications, confidentiality of trusted data, and secure storage. The described off-chain smart contract service providers may include TEEs and the implementation of blockchain network computations within TEEs. The described techniques may offer several advantages. For example, using a TEE as a temporary medium to perform computations can protect data privacy. For instance, a user of blockchain network A needs data from blockchain networks B and C to perform computations. Typically, blockchain networks B and C are each closed chains and are unwilling to share their data with users of blockchain network A due to privacy concerns. By utilizing a TEE, computations can be performed without exposing detailed information about data from blockchain networks B and C to blockchain network A, while still enabling cross-chain data access and smart contract execution based on cross-chain data. Furthermore, as mentioned earlier, performing complex calculations on a blockchain network consumes the chain's computing resources. Offloading computational tasks from the blockchain network to an off-chain TEE can save the blockchain network's computation time and resources. Moreover, since users can design their own computational logic for the computations they need and request, the TEE uses this logic to execute computations, and can perform various computations in a more flexible and broader manner.

In some embodiments, the proposed technology can provide a general smart contract service with privacy protection. For example, due to privacy concerns, smart contracts used for financial transactions need to hide the transfer amount and the transacting parties (such as the sender and receiver). Under the proposed method, the sender can first encrypt the transaction content and then invoke an off-chain smart contract service. The off-chain smart contract service can decrypt the transaction content in the TEE, execute the transaction in the TEE, and then return the transaction result to the blockchain in ciphertext (e.g., with evidence that the transaction was executed with correct logic). After the blockchain network verifies the returned result, the result can be updated to reflect the latest state on the blockchain network.

In some embodiments, the proposed technology can provide cross-chain data computation services. As an example, the proposed technology can be used to calculate personal credit scores. In reality, people need to participate in various services involving credit assessment, such as bank loan applications, real estate leasing, and car rentals. Each service can be operated and maintained by an independent consortium blockchain network or a private blockchain network. Each service may not want to share data with other services, and in some cases, they may encrypt the personal data they possess. To obtain a comprehensive credit assessment of an individual from different domains, the proposed solution can be used. In some embodiments, the user can provide credit calculation logic (code) and data request authorization (e.g., using a signature or private key) to initiate a credit assessment request using a private channel. The services in the proposed solution request data from multiple chains and decrypt the data in a TEE, ensuring that results are generated under the correct computational logic. The results and a result certificate are returned to the user, who can verify the proof to guarantee the confidentiality and integrity of the data and logic. The user can then use this result and proof to provide a certified personal credit score to other nodes on their blockchain network.

In some embodiments, when a user needs to execute a transaction under a blockchain network contract, the complex calculations in the contract can be pre-processed by an off-chain smart contract service, and the results can then be uploaded and stored in the blockchain network. In some embodiments, the results can be directly used as input for transactions executed on the blockchain network, reducing the runtime of the blockchain network contract and improving efficiency. In these embodiments, if a user does not want to publicly disclose private contracts or security protocols implemented on the blockchain network, they can use an off-chain smart contract service for computation, and the data on the blockchain network can be reliably accessed.

Figure 1 illustrates an example of an environment 100 that can be used to perform the embodiments described herein. In some examples, environment 100 enables entities to participate in blockchain network 102. Environment 100 includes computing devices 106, 108 and network 110. In some examples, 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, network 110 can be accessed via wired and/or wireless communication links. In some examples, network 110 is capable of communicating with blockchain network 102 and is capable of communicating within blockchain network 102. Typically, network 110 represents one or more communication networks. In some cases, computing devices 106, 108 may be nodes (not shown) of a cloud computing system, or computing devices 106, 108 may each be a separate cloud computing system comprising multiple computers interconnected by a network and used as a distributed processing system.

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

Figure 2 illustrates an example of a conceptual architecture 200 according to embodiments herein. The example of conceptual architecture 200 includes participant systems 202, 204, and 206 corresponding to participant A, participant B, and participant C, respectively. Each participant (e.g., a user, enterprise) participates in a blockchain network 212, which is provided as a peer-to-peer network comprising multiple nodes 214, wherein at least some nodes immutably record information in a blockchain 216. Although a single blockchain 216 is schematically depicted in blockchain network 212, multiple copies of blockchain 216 are provided and maintained throughout blockchain network 212, as described further in detail herein.

In the described example, each participant system 202, 204, 206 is provided by, or represents, participant A, participant B, and participant C, respectively, and serves as a node 214 in the blockchain network. As used herein, a node generally refers to an independent system (such as a computer or server) connected to the blockchain network 212 and enabling participants to engage in the blockchain network. In the example of Figure 2, a participant corresponds to each node 214. However, it is contemplated that a participant may operate multiple nodes 214 within the blockchain network 212, and/or multiple participants may share a single node 214. In some examples, participant systems 202, 204, 206 communicate with or via the blockchain network 212 using protocols (e.g., Hypertext Transfer Protocol Security (HTTPS)) and/or using Remote Procedure Calls (RPC).

Node 214 can have different levels of participation within the blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miner nodes adding blocks to blockchain 216), while other nodes 214 may not participate. As another example, some nodes 214 may store a complete copy of blockchain 216, while other nodes 214 may store only a partial copy of blockchain 216. For example, data access permissions may restrict the amount of blockchain data that each participant stores within its respective system. In the example of Figure 2, participant systems 202, 204, and 206 store their respective complete copies 216', 216”, and 216”' of blockchain 216.

A blockchain (e.g., blockchain 216 in Figure 2) consists of a series of blocks, each storing data. Examples of data include transaction data representing a transaction between two or more participants. While "transaction" is used herein in a non-limiting manner, it is contemplated that any suitable data can be stored in a blockchain (e.g., documents, images, videos, audio). Examples of transactions may include, but are not limited to, the exchange of goods of value (e.g., assets, products, services, and currencies). Transaction data is stored immutably within the blockchain. That is, transaction data cannot be altered.

Before being stored in a block, transaction data is hashed. Hash processing is the process of converting transaction data (provided as string data) into a fixed-length hash value (also provided as string data). It is impossible to de-hash the hash value to obtain the transaction data. Hash processing ensures that even small changes to the transaction data will result in completely different hash values. Furthermore, as mentioned above, hash values have a fixed length. That is, regardless of the size of the transaction data, the length of the hash value is fixed. Hash processing involves processing the transaction data using a hash function to generate 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.

Transaction data for multiple transactions is hashed and stored in a block. For example, the hashes of two transactions are provided, and each transaction is hashed to provide another hash. This process is repeated until a single hash is provided for all transactions to be stored in the block. This hash is called the Merkle root hash and is stored in the block header. Any change in a transaction will result in a change to its hash, and ultimately, a change to the Merkle root hash.

Blocks are added to the blockchain via a consensus protocol. Multiple nodes in the blockchain network participate in the consensus protocol and compete to add blocks to the blockchain. These nodes are called miners (or miner nodes). The Proof-of-Work (PoW) described above is used as a non-restricted example.

Miner nodes execute a consensus process to add transactions to the blockchain. While multiple miner nodes participate in the consensus process, only one can write a block to the blockchain. That is, miner nodes compete to add their blocks to the blockchain during the consensus process. More specifically, miner nodes periodically collect pending transactions from a transaction pool (e.g., up to a predetermined limit on the number of transactions that can be included in a block, if any). The transaction pool includes transaction messages from participants in the blockchain network. Miner nodes construct blocks and add transactions to those blocks. Before adding multiple transactions to a block, a miner node checks if any of those transactions has already been included in a block on the blockchain. If a transaction has already been included in another block, it is discarded.

Miner nodes generate block headers, hash all transactions within a block, and combine hash values in pairs to generate further hash values until a single hash value (the Merkle root hash value) is provided for all transactions in the block. This hash value is added to the block header. Miners also determine the hash value of the most recent block in the blockchain (i.e., the last block added to the blockchain). Miner nodes also add a nonce and a timestamp to the block header. During mining, miner nodes attempt to find hash values that satisfy the required parameters. Miner nodes continuously change the nonce until they find a hash value that meets the required parameters.

In a blockchain network, each miner competes with others to find a hash value that meets the required parameters. Finally, one miner node finds the hash value and announces it to all other miner nodes in the network. The other miner nodes verify the hash value, and if it is correct, they verify every transaction in the block, accept the block, and append it to their copy of the blockchain. In this way, the global state of the blockchain is consistent across all miner nodes in the network. This process is the Proof-of-Work (PoW) consensus protocol.

A non-limiting example is provided with reference to Figure 2. In this example, participant A wishes to send funds to participant B. Participant A generates a transaction message (e.g., including sender, recipient, and numeric fields) and sends it to the blockchain network, thereby adding the transaction message to the transaction pool. Each miner node in the blockchain network creates a block and retrieves all transactions from the transaction pool (e.g., up to a predetermined limit on the number of transactions that can be added to a block, if any), and adds the transactions to the block. In this way, the transaction published by participant A is added to the block of the miner node.

In some blockchain networks, cryptography is used to maintain transaction privacy. For example, if two nodes want to keep transaction privacy so that other nodes in the blockchain network cannot know the details of the transaction, these two nodes can encrypt the transaction data. Examples of encryption include, but are not limited to, symmetric and asymmetric encryption. Symmetric encryption refers to an encryption process that uses a single key to both encrypt (generate ciphertext from plaintext) and decrypt (generate plaintext from ciphertext). In symmetric encryption, the same key can be used by multiple nodes, so each node can encrypt/decrypt the transaction data.

Asymmetric encryption uses key pairs, each consisting of a private key and a public key. The private key is known only to the corresponding node, while the public key is known to any or all other nodes in the blockchain network. A node can use another node's public key to encrypt data, and that encrypted data can be decrypted using another node's private key. For example, referring again to Figure 2, participant A can use participant B's public key to encrypt data and send the encrypted data to participant B. Participant B can use their private key to decrypt the encrypted data (ciphertext) and retrieve the original data (plaintext). A message encrypted using a node's public key can only be decrypted using that node's private key.

Asymmetric encryption is used to provide digital signatures, enabling participants in a transaction to verify the validity of the transaction and the other participants in the transaction. For example, a node can digitally sign a message, and another node can verify that the message was sent by that node based on participant A's digital signature. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, referring again to Figure 2, participant A sends a message to participant B. Participant A generates a hash value for the message and then encrypts the hash value using its private key to provide a digital signature for the encrypted hash value. Participant A attaches this digital signature to the message and sends the digitally signed message to participant B. Participant B decrypts the digital signature using participant A's public key and extracts the hash value. Participant B hashes the message and compares the hash values. If the hash values are the same, participant B can verify that the message did indeed come from participant A and has not been tampered with.

Figure 3 illustrates an example of a process 300 for providing cross-chain data services to a client according to embodiments of this document. In some embodiments, client 302 represents an application (e.g., a client application) associated with a blockchain network such as target blockchain network 306. For example, client 302 may include a client software development kit (SDK) for accessing and communicating with target blockchain network 306. Client 302 may be installed on a user's device (also referred to as a client terminal or node) (not shown in Figure 3). In some embodiments, a user can participate in transactions on target blockchain network 306 by initiating transactions using client 302. In some embodiments, the user's account information may be stored on target blockchain network 306, and the user has authorization to execute transactions on the target blockchain network. Client 302 can access and read data stored on target blockchain network 306. In some embodiments, to obtain cross-chain data, such as data from one or more different blockchain networks (e.g., 316, 318, and 320 in Figure 3), client 302 may require a relay or trusted data access service provider 312 to bridge communication gaps between client 302 on target blockchain network 306 and other different blockchain networks.

In some embodiments, client 302 may initiate a confidential transaction under a contract on the target blockchain network, and this transaction information is visible only to the user of client 302 and other possible participants or parties to the transaction, and not to any other parties on or outside the blockchain network. In some embodiments, client 302 needs to present the result to another entity on or outside the target blockchain network.

In some embodiments, transactions by client 302 of target blockchain network 306 may include various computational operations using data from target blockchain network 306 and/or cross-chain data (e.g., data from one or more different blockchain networks 316, 318, or 320). In some embodiments, transactions by client 302 of target blockchain network 306 may include results computed using data from target blockchain network 306 and/or cross-chain data. In some embodiments, transactions may include various computational logics and protocols. In some embodiments, the computations may be complex and may consume the computational resources of the blockchain network. In some embodiments, transactions may be specified in a smart contract designed by client 302.

For example, as shown in Figure 3, client 302 can use client SDK 304 to prepare a smart contract including its own designed computational logic and protocols to execute transactions based on cross-chain data (e.g., data from one or more different blockchain networks 316, 318, or 320). Client 302 can send the smart contract to smart contract service provider 308 for execution. Smart contract service provider 308 is located outside the target blockchain network 306, allowing smart contract service provider 308 to execute the computational logic and protocols defined in the smart contract independently of the target blockchain network 306.

Once the smart contract is received and analyzed, the smart contract service provider 308 determines that cross-chain data is required to execute the smart contract. The smart contract service provider 308 can send a request for cross-chain data to the trusted data access service provider 312 to obtain the cross-chain data. For example, the client 302 might want to perform a calculation of "a plus b", where a is data from the target blockchain network 306 and b is private data from blockchain network 316. In this case, the smart contract sent from the client 302 contains the computational logic for adding a and b together, as well as location indicators for the data a and b. The smart contract service provider 308 can then send a request to the trusted data access service provider 312 to obtain the private data b from blockchain network 316. In some embodiments, the smart contract may be encrypted to protect user privacy.

In some embodiments, the off-chain smart contract service provider 308 can be a cloud-based server provider. In some embodiments, such a cloud server provider can be an independent third-party service provider, such as in some instances where multiple entities are data resources for cross-chain data, and none of them want to upload their own data to a third-party service provider. In this case, these entities can build their own smart contract service provider.

The off-chain smart contract service provider 308 includes a Trusted Execution Environment (TEE) 310, which provides a secure computing execution environment. In some embodiments, the computing TEE 310 is a standalone hardware module, and its independence ensures the security of data executed within the TEE 310. In some embodiments, to configure the TEE 310 for blockchain network operation, one or more of a virtual machine, application interface, or operating system may be programmed, hard-coded, or otherwise configured into the TEE 310 to make the TEE 310 suitable for executing the computational logic defined in the smart contract. In some embodiments, before sending the smart contract to the off-chain smart contract service provider 308, the client 302 may verify whether the off-chain smart contract service provider 308 includes the TEE 310, and whether the TEE 310 includes an executor or environment corresponding to the client 302. For example, if the target blockchain network 306 is an Ethereum-based blockchain network, and the client 302's SDK 304 is an Ethereum-based client SDK (e.g., using the Solidity language), then before the client 302 sends a request to the off-chain smart contract service provider 308 to execute the smart contract, the client 302 may verify whether the TEE 310 includes an Ethereum Virtual Machine (EVM) for executing Ethereum-based computational logic (e.g., it supports the Solidity language).

Upon receiving a request to execute a smart contract, if the request is encrypted, TEE 310 first decrypts the request, parses the smart contract, and identifies the data required to execute it. TEE 310 can invoke Trusted Data Access Service Provider 312 to retrieve data from one or more different sources, for example, through Trusted Data Access Service Provider 312's Application Programming Interface (API) 314. Trusted Data Access Service Provider 312 is a trusted party capable of retrieving private data from one or more different blockchain networks. Trusted Data Access Service Provider 312 can provide trusted data to TEE 310 of Off-Chain Smart Contract Service Provider 308, ensuring the privacy and accuracy of the data.

In some embodiments, the Trusted Data Access Service Provider 312 may also include a TEE, for example, to retrieve data from the correct location on one or more different blockchain networks. In some embodiments, the logic of the TEE included in the Trusted Data Access Service Provider 312 is simpler than that of the TEE 310 in the Off-Chain Smart Contract Service Provider 308, because the former is primarily used for data retrieval and does not require computation on the retrieved data.

In some embodiments, a two-way verification process is performed between the off-chain smart contract service provider 308 and the trusted data access service provider 312 before the TEE 310 calls API 314. In some embodiments, during the verification process, each of them proves to the other that it includes the TEE.

In some embodiments, the Trusted Data Access Service Provider 312 may retrieve data from one or more different sources, including one or more blockchain networks, blockchain network sets, or blockchain network platforms (collectively, one or more blockchain networks). Examples of blockchain networks are shown as Mychain 316, Hyperleger 318, and Ethereum 320 in Figure 3. The obtained data is sent back to the TEE 310, which uses the obtained data to perform computational logic.

In some embodiments, after the computation result is generated in the computational TEE 310, the TEE 310 signs the result using its private key to prove the completeness and accuracy of the result. In some embodiments, the signature is proof that the computation result was executed by the TEE 310 according to the computational logic included in the smart contract sent by the client 302. Therefore, the result can be trusted by other nodes of the target blockchain network 306.

In some embodiments, TEE 310 returns the result to client 302. For example, client 302 decrypts the result using the public key corresponding to the private key of TEE 310. In some embodiments, client 302 uploads the result to target blockchain network 306, making the result usable for updating the state of client 302 or as input for transactions on target blockchain network 306. In some embodiments, client 302 may use the result for purposes unrelated to the blockchain network, such as calculating a user's average credit score. For example, a user may obtain data from different chains (each chain representing a corresponding service provider, such as car rental, bank loan, or home rental) and use that data to calculate the user's average credit score. The user may present the result to merchants without uploading it to any blockchain network.

In some embodiments, the TEE 310 can return the result directly to the target blockchain network 306. In this embodiment, before returning the result, the target blockchain network 306 can verify whether the off-chain smart contract service provider 308 includes the TEE required to establish trust between the off-chain smart contract service provider 308 and the target blockchain network 306.

Figure 4 illustrates an example of a process 400 that can be performed according to embodiments herein. In some embodiments, the exemplary process 400 may be performed using one or more computer-executable programs (which execute using one or more computing devices). For clarity, the following description generally describes method 400 in the context of the other figures herein. For example, client 420 may be client 302, smart contract service provider 430 may be off-chain smart contract service provider 308, trusted data access service provider 440 may be trusted data access service provider 312, blockchain network 450 may be Mychain 316, Hyperleger 318, and/or Ethereum 320, and target blockchain network 410 may be target blockchain network 306, as described with respect to Figure 3. However, it is understood that method 400 may be performed, for example, by any suitable system, environment, software, and hardware, or a combination of systems, environments, software, and hardware (appropriately). In some embodiments, the various steps of method 400 may be run in parallel, in combination, in cycles, or in any order.

At 412, a client 420 associated with the target blockchain network 410 generates a request for operating cross-chain data on one or more blockchain networks different from the target blockchain network. The request for operating the cross-chain data includes smart contract computation logic for operating the cross-chain data. In some embodiments, the request for operating the cross-chain data can be written as a smart contract. The request for operating the cross-chain data can be an example of a request for executing a smart contract as described with respect to Figure 3.

In some embodiments, the smart contract computation logic used to manipulate cross-chain data is designed by the client, allowing users to freely and flexibly specify the smart contract computation logic to achieve their purposes, and is not limited to the computation logic defined by the target blockchain network 410. In these embodiments, generating the request includes smart contract computation logic designed by the client for manipulating cross-chain data. In some embodiments, the client includes a software development kit (SDK) that allows users to write smart contract computation logic. In some embodiments, the computation logic can be written in the Solidity language. In some embodiments, the request for manipulating cross-chain data is encrypted by the client.

At 414, a client 420 associated with the target blockchain network 410 sends a request to the smart contract service provider 430 for cross-chain data operations on one or more blockchain networks different from the target blockchain network 410. The smart contract service provider 430 includes a Trusted Computing Execution Environment (TEE). The smart contract service provider 430 is located outside the target blockchain network 410. In some embodiments, the cross-chain data is obtained from two or more blockchain networks. In some embodiments, the smart contract service provider 430 includes a cloud-based server.

In some embodiments, the request for cross-chain data access is a data access request. In these embodiments, the TEE retrieves the data and returns it to the client 420.

In some embodiments, in addition to retrieving data from multiple blockchain networks, the TEE also operates on the data based on the smart contract computation logic included in the request. In some embodiments, the smart contract service provider 430 may configure the TEE, for example, by embedding the EVM into the TEE to enable the TEE to appropriately execute the smart contract computation logic included in the request.

In some embodiments, before sending a request to manipulate cross-chain data, at 426, client 420 verifies whether smart contract service provider 430 can securely execute smart contract computation logic. In some embodiments, this verification process includes: smart contract service provider 430 proving to client 420 that smart contract service provider 430 includes a TEE; smart contract service provider 430 proving to client 420 that the TEE includes a virtual machine operable to execute the smart contract computation logic in the request to manipulate cross-chain data.

For example, the TEE could be SGX. In this example, the provided signing and verification service is used to prove whether the smart contract service provider 430 includes SGX. Furthermore, to prove that the TEE includes the required EVM, the TEE calculates the hash of the script and code of the invoked EVM and then sends that hash to the client 420 for verification. Because the client 420 also has a complete set of EVM code, it can also calculate the hash of the script and code of its own EVM and compare the two hashes to see if they match.

In some embodiments, the client 420 and the smart contract service provider 430 may set up a key pair before generating the request. Therefore, after the smart contract service provider 430 receives a request signed using one of the keys, it can decrypt the request using the other key in the key pair. At 428, the smart contract service provider 430 decrypts and parses the received request. In some embodiments, the request is written in a data format predetermined during development, in which case the request is parsed based on each data segment.

At 435, the smart contract service provider 430 sends a request for cross-chain data to the data access service provider 440 to obtain the cross-chain data specified in the request for manipulating the cross-chain data. In some embodiments, before sending the request to the data access service provider 440, at 432, the smart contract service provider 430 verifies whether the trusted data access service provider 440 is capable of providing trusted cross-chain data from one or more blockchain networks different from the target blockchain network. In some embodiments, this verification process includes the smart contract service provider 430 verifying whether the data access service provider 440 includes a TEE.

In some embodiments, prior to sending a request to data access service provider 440, at 434, data access service provider 440 and smart contract service provider 430 may perform a verification process to establish trust between them. In some embodiments, this verification process includes smart contract service provider 430 proving to data access service provider 440 that smart contract service provider 430 includes a TEE. In some embodiments, in both steps 432 and 434, the existence of the TEE can be verified/proven using the same method as described in step 426.

At 436, the data access service provider 440 requests data from one or more blockchain networks 450 that are different from the target blockchain network 410.

At 438, the data access service provider 440 receives data from one or more blockchain networks 450 that are different from the target blockchain network 410.

At 439, the smart contract service provider 430 receives cross-chain data from the data access service provider 440. In some embodiments, cross-chain data is obtained from two or more blockchain networks.

At 441, the TEE of the smart contract service provider 430 generates a result by executing smart contract computation logic using the received cross-chain data. In some embodiments, the result is generated by the TEE that executes smart contract computation logic using cross-chain data. In some embodiments, the EVM execution code included in the TEE performs computations using the computation logic and the received data.

At 442, the smart contract service provider 430 signs the result. In some embodiments, the result is signed with a private key. For example, the TEE includes a private key isolated from the outside and other components of the TEE. In some embodiments, the signature signed with the private key is evidence that the result was generated within the TEE. In some embodiments, after the smart contract service provider 430 signs the result, the final output includes: the hash value of the result generated by the TEE and the result signed with the private key.

At 443, the smart contract service provider 430 returns the result to the client 420.

At 444, client 420 decrypts the received result. In some embodiments, client 420 uses the public key corresponding to the private key to decrypt the received result. In these embodiments, the received result includes the result generated by the TEE and the hash value of the signature of the result. In these embodiments, client 420 calculates the hash value of the result generated by the TEE using the private key and compares it with the hash value of the signature of the result to confirm whether they match.

At 446, client 420 sends the transaction to target blockchain network 410 based on the received result. In some embodiments, client 420 uploads the transaction to target blockchain network 410 to update the state of client 420 or to execute the transaction on target blockchain network 410.

In some embodiments, at 452, the smart contract service provider 430 uploads the result to the target blockchain network 410. In some embodiments, before uploading the result to the target blockchain network, at 448, the smart contract service provider proves to the target blockchain network that the smart contract service provider includes a TEE. The method used for proof here can be the same as the method used in step 426.

Referring to FIG5, FIG5 depicts an example illustration of the modules of an apparatus 500 according to an embodiment herein. Apparatus 500 may be an exemplary embodiment of a smart contract service provider including a Trusted Computing Execution Environment (TEE), wherein the smart contract service provider is located outside the target blockchain network. Apparatus 500 for cross-chain data operations can be used in off-chain smart contract systems based on blockchain network technology. Apparatus 500 may correspond to the embodiments shown in FIG3 and FIG4, and includes: a first receiver or first receiving unit 510 configured to receive a request from a client associated with the target blockchain network for operating cross-chain data on one or more blockchain networks different from the target blockchain network; a transmitter or sending unit 520 configured to send the request for cross-chain data; a second receiver or second receiving unit 530 configured to receive cross-chain data from a data access service provider; a generator or generating unit 540 configured to generate a result based on the cross-chain data from the data access service provider; and a user interface 550 configured to return the result to the client.

In an optional embodiment, the request for manipulating cross-chain data includes smart contract computation logic for manipulating cross-chain data.

In an optional embodiment, the smart contract computation logic used to manipulate cross-chain data is designed by the client itself.

In an optional embodiment, the apparatus 500 further includes: a first providing subunit configured to provide a TEE including a virtual machine operable to execute smart contract computation logic in a request for manipulating cross-chain data.

In an optional embodiment, the device 500 further includes: a second providing subunit configured to provide a smart contract service provider including a TEE before receiving a request from a client for operating cross-chain data.

In an optional embodiment, the apparatus 500 further includes: a third providing subunit configured to provide a smart contract service provider including a TEE; and a verification subunit configured to verify that the data access service provider includes a TEE.

In an optional embodiment, the device 500 further includes an uploading subunit configured to upload the result to the target blockchain network.

In an optional embodiment, the device 500 further includes: a fourth providing subunit configured to provide a smart contract service provider including a TEE before uploading the results to the target blockchain network.

In an alternative embodiment, the smart contract service provider includes a cloud-based server.

In an alternative embodiment, cross-chain data is obtained from two or more blockchain networks.

Referring to FIG6, FIG6 depicts an example illustration of modules of another device 600 according to an embodiment herein. Device 600 may be an exemplary embodiment of a client associated with a target blockchain network. Device 600 may be used in an off-chain smart contract system based on blockchain network technology. Device 600 may correspond to the embodiments shown in FIG3 and FIG4, and device 600 includes: a generator or generation unit 610 configured to generate a request for operating cross-chain data of one or more blockchain networks different from the target blockchain network, wherein the request for operating the cross-chain data includes smart contract computation logic for operating the cross-chain data; a sender or sending unit 620 configured to send the request for operating the cross-chain data to a smart contract service provider including a trusted computing execution environment (TEE), wherein the smart contract service provider is outside the target blockchain network; and a receiver or receiving unit 630 configured to receive a result from the smart contract service provider, wherein the result is generated by the TEE using cross-chain data obtained through the smart contract service provider.

In an optional embodiment, the device 600 further includes: a first sending subunit configured to send the received result to a target blockchain network.

In an optional embodiment, the apparatus 600 further includes a verification subunit configured to verify that the TEE includes a virtual machine operable to execute the smart contract computation logic in the request for manipulating cross-chain data before sending a request for manipulating cross-chain data to the smart contract service provider.

In an optional embodiment, device 600 further includes: a design subunit configured to design smart contract computation logic for manipulating cross-chain data.

In an alternative embodiment, the client includes a software development kit (SDK).

In an optional embodiment, the result is signed by the TEE using a private key, and the device 600 further includes a decryption subunit configured to decrypt the received result using a public key corresponding to the private key.

In an optional embodiment, the device 600 further includes: an encryption unit configured to encrypt the request for manipulating cross-chain data before sending the request to the smart contract service provider.

In an alternative embodiment, cross-chain data is obtained from two or more blockchain networks.

The systems, apparatus, modules, or units illustrated in the preceding embodiments may be implemented using computer chips or entities, or by using products with specific functions. A typical implementation device is a computer, which may be a personal computer, laptop computer, mobile phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email receiving and sending device, game console, tablet computer, wearable device, or any combination of these devices.

The implementation process for the function and role of each unit in the device can be referred to the corresponding steps in the preceding method. For simplicity, details are omitted here.

Since the apparatus implementation essentially corresponds to the method implementation, the relevant descriptions in the method implementation can be referenced for related components. The apparatus implementations described above are merely exemplary. Units described as separate components may or may not be physically independent, and components shown as units may or may not be physical units, may be located in one location, or may be distributed across multiple network units. Some or all modules can be selected based on actual needs to achieve the objectives of the solutions described herein. Those skilled in the art can understand and implement the embodiments of this application without inventive effort.

Figure 5 is a schematic diagram illustrating the internal functional modules and structure of a cross-chain data manipulation device. The cross-chain data manipulation device can be an example of a smart contract service provider that includes a Trusted Computing Execution Environment (TEE). The execution entity can essentially be an electronic device, which includes: one or more processors; and memory configured to store executable instructions from the one or more processors.

One or more processors are configured to: receive from a client associated with a target blockchain network a request for cross-chain data to operate on one or more blockchain networks different from the target blockchain network, wherein the smart contract service provider is outside the target blockchain network; send the request for cross-chain data to a data access service provider; receive the cross-chain data from the data access service provider; utilize the cross-chain data to generate a result via a TEE; and return the result to the client.

Optionally, the request for manipulating cross-chain data includes smart contract computation logic for manipulating cross-chain data.

Optionally, the smart contract computation logic used to manipulate cross-chain data is designed by the client itself.

Optionally, the result is generated by the TEE using cross-chain data to execute smart contract computation logic.

Optionally, one or more processors are configured to prove to the client that the TEE includes a virtual machine operable to execute smart contract computation logic in requests for manipulating cross-chain data.

Optionally, one or more processors are configured to prove to the client that the smart contract service provider includes a TEE before receiving a request from the client for manipulating cross-chain data.

Optionally, one or more processors are configured to prove to the data access service provider that the smart contract service provider includes a TEE; and to verify that the data access service provider includes a TEE.

Optionally, one or more processors are configured to upload the results to the target blockchain network.

Optionally, one or more processors are configured to prove to the target blockchain network that the smart contract service provider includes a TEE before uploading the results to the target blockchain network.

Optionally, smart contract service providers may include cloud-based servers.

Optionally, the result is signed using a private key via a TEE.

Optionally, cross-chain data is obtained from two or more blockchain networks.

Figure 6 is a schematic diagram illustrating the internal functional modules and structure of another cross-chain data manipulation device. This other cross-chain data manipulation device can be an example of a client associated with a target blockchain network. The execution entity can essentially be an electronic device, which includes: one or more processors; and memory configured to store executable instructions from the one or more processors.

One or more processors are configured to generate requests for operating cross-chain data on one or more blockchain networks different from the target blockchain network, wherein the requests for operating the cross-chain data include smart contract computation logic for operating the cross-chain data; send the requests for operating the cross-chain data to a smart contract service provider including a Trusted Computing Execution Environment (TEE), wherein the smart contract service provider is located outside the target blockchain network; and receive a result from the smart contract service provider, wherein the result is generated by the TEE using the cross-chain data obtained by the smart contract service provider.

Optionally, one or more processors are configured to send the received results to the target blockchain network.

Optionally, one or more processors are configured to verify that the smart contract service provider includes a TEE before sending a request for manipulating cross-chain data to the smart contract service provider.

Optionally, one or more processors are configured to verify that the TEE includes a virtual machine operable to execute smart contract computation logic in requests for manipulating cross-chain data.

Optionally, the client includes a software development kit (SDK).

Optionally, the result is signed using a private key via a TEE. One or more processors are configured to decrypt the received result using the public key corresponding to the private key.

Optionally, one or more processors are configured to encrypt the request for manipulating cross-chain data before sending the request to the smart contract service provider.

Optionally, cross-chain data is obtained from two or more blockchain networks.

The embodiments of the subjects, actions, and operations described herein can be implemented in digital electronic circuits, tangibly embodied computer software or firmware, computer hardware, including the structures disclosed herein and their structural equivalents, or combinations thereof. Embodiments of the subjects described herein can be implemented as one or more computer programs, for example, modules of one or more computer program instructions encoded on a computer program carrier for executing or controlling the operation of a data processing apparatus. The carrier can be a tangible, non-transitory computer storage medium. Optionally or additionally, the carrier can be an artificially generated propagation signal, such as a machine-generated electrical, optical, or electromagnetic signal, generated to encode information for transmission to a suitable receiver device for execution by the data processing apparatus. The computer storage medium can be, or is in part, a machine-readable storage device, a machine-readable storage substrate, a random or serial access storage device, or a combination thereof. The computer storage medium is not a propagation signal.

The term "data processing apparatus" includes various types of devices, apparatuses, and machines for processing data, including, for example, programmable processors, computers, or multiprocessors or computers. Data processing apparatuses may include special-purpose logic circuitry, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or graphics processing units (GPUs). In addition to hardware, the apparatus may also include code that creates an execution environment for computer programs, such as code that constitutes processor firmware, protocol stacks, database management systems, operating systems, or combinations thereof.

A computer program, also referred to or described as a program, software, software application, app, module, software module, engine, script, or code, may be written in any form of programming language, including compiled or interpreted languages, descriptive or procedural languages; it may be configured in any form, including as a standalone 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 by a data communication network at one or more locations.

A computer program may, but is not required to, correspond to a file in a file system. A computer program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple co-located files (e.g., multiple files storing one or more modules, subroutines, or code sections).

The processes and logical flows described herein can be executed by one or more computers executing one or more computer programs to perform operations by processing input data and producing outputs. The processes and logical flows can also be executed by dedicated logic circuitry (e.g., FPGA, ASIC, or GPU) or a combination of dedicated logic circuitry and one or more programmed computers.

A computer suitable for executing computer programs can be based on a general-purpose and/or special-purpose microprocessor, or any other type of central processing unit (CPU). Generally, the CPU receives instructions and data from read-only memory and/or random access memory. Computer elements may include a CPU for executing instructions and one or more memory devices for storing instructions and data. The CPU and memory may be supplemented with or integrated into special-purpose logic circuitry.

Typically, a computer is coupled to at least one non-transitory computer-readable storage medium (also known as a computer-readable memory). The storage medium coupled to the computer can be an internal component of the computer (e.g., an integrated hard disk drive) or an external component (e.g., a Universal Serial Bus (USB) hard disk drive or a storage system accessed via a network). Examples of storage media can include, for example, disks, magneto-optical or optical disks, solid-state drives, network storage resources such as cloud storage systems, or other types of storage media. However, the computer does not need to have these devices. Furthermore, the computer can be embedded in other devices such as mobile phones, personal digital assistants (PDAs), mobile audio or video players, game consoles, GPS receivers, or portable storage devices such as Universal Serial Bus (USB) flash drives, to name just a few.

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

This document uses the term "configured as" in relation to systems, devices, and computer program components. For a system of one or more computers, being configured to perform a specific operation or action means that the system has software, firmware, hardware, or a combination thereof installed thereon that, during operation, causes the system to perform said operation or action. For one or more computer programs, being configured to perform a specific operation or action means that the one or more programs include instructions that, when executed by a data processing device, cause that device to perform said operation or action. For a dedicated logic circuit, being configured to perform a specific operation or action means that the circuit has electronic logic that performs said operation or action.

While this document contains numerous details of specific embodiments, these should not be construed as limiting the scope of the claims as defined by the claims themselves, but rather as descriptions of specific features of particular embodiments. The multiple specific features described in the context of several individual embodiments herein may also be implemented in combinations of single embodiments. Conversely, different features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although the foregoing features may be described as functioning in certain combinations, and even initially claimed in this way, in some cases one or more features from the claimed combination may be removed, and claims may be made pointing to sub-combinations or variations thereof.

Similarly, although the operations are depicted in the accompanying drawings in a specific order and are stated in the claims, it should not be construed as requiring that these operations be performed in the specific order or sequentially shown, or that all of the shown operations be performed, in order to achieve the desired result. In some cases, multitasking in parallel may be advantageous. Furthermore, the division of various system modules and components in the above embodiments should not be construed as requiring such division in all embodiments, but rather should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. For example, the actions stated in the claims can be performed in a different order and still achieve the desired result. As an example, the processes depicted in the drawings do not require a specific order or sequence to achieve the desired result. In some cases, multitasking in parallel may be advantageous.

Claims (54)

1. A computer-implemented method, comprising: A smart contract service provider, including a Trusted Computing Execution Environment (TEE), receives a request from a client associated with a target blockchain network for operating cross-chain data from one or more blockchain networks different from the target blockchain network. The request for operating the cross-chain data includes smart contract computation logic for operating the cross-chain data. The smart contract computation logic is designed by the client itself. The client provides privacy-preserving general smart contract services and cross-chain data computation services. The smart contract service provider is located outside the target blockchain network. The smart contract service provider sends a request for the cross-chain data to the data access service provider; The smart contract service provider receives the cross-chain data from the data access service provider; The TEE generates the result using the cross-chain data; and The smart contract service provider then returns the result to the client. 2. The computer-implemented method according to claim 1, wherein the result is generated by the TEE using the cross-chain data to execute the smart contract computation logic. 3. The computer-implemented method according to claim 1, further comprising: The smart contract service provider proves to the client that the TEE includes a virtual machine capable of operating to execute the smart contract computation logic in a request to manipulate the cross-chain data. 4. The computer-implemented method according to claim 1, further comprising: Before receiving the request for cross-chain data manipulation from the client, the smart contract service provider proves to the client that the smart contract service provider includes the TEE. 5. The computer-implemented method according to claim 1, further comprising: The smart contract service provider proves to the data access service provider that the smart contract service provider includes the TEE; and The smart contract service provider verifies that the data access service provider includes a TEE. 6. The computer-implemented method according to claim 1, further comprising: The smart contract service provider uploads the results to the target blockchain network. 7. The computer-implemented method according to claim 6, further comprising: Before uploading the results to the target blockchain network, the smart contract service provider proves to the target blockchain network that the smart contract service provider includes the TEE. 8. The computer-implemented method according to claim 1, wherein the smart contract service provider includes a cloud-based server. 9. The computer-implemented method according to claim 1, wherein the result is signed by the TEE using a private key. 10. The computer-implemented method of claim 1, wherein the cross-chain data is obtained from two or more blockchain networks. 11. A computer-implemented method, comprising: A client associated with a target blockchain network generates a request for operating cross-chain data on one or more blockchain networks different from the target blockchain network. The request for operating the cross-chain data includes smart contract computation logic for operating the cross-chain data. The smart contract computation logic for operating the cross-chain data is designed by the client. The client provides a privacy-preserving general smart contract service and a cross-chain data computation service. The client sends the request for manipulating cross-chain data to a smart contract service provider that includes a Trusted Computing Execution Environment (TEE), wherein the smart contract service provider is located outside the target blockchain network; and The client receives the result from the smart contract service provider, wherein the result is generated by the TEE using the cross-chain data obtained by the smart contract service provider. 12. The computer-implemented method according to claim 11, further comprising: The client then sends the received result to the target blockchain network. 13. The computer-implemented method according to claim 11, further comprising: Before sending the request for manipulating cross-chain data to the smart contract service provider, the client verifies that the smart contract service provider includes the TEE. 14. The computer-implemented method according to claim 13, further comprising: The client verifies that the TEE includes a virtual machine capable of operating to execute the smart contract computation logic in a request for manipulating the cross-chain data. 15. The computer-implemented method of claim 11, wherein the client includes a software development kit (SDK). 16. The computer-implemented method of claim 11, wherein the result is signed by the TEE using a private key, and the method further comprises the client decrypting the received result using a public key corresponding to the private key. 17. The computer-implemented method according to claim 11, further comprising: Before sending the request for manipulating cross-chain data to the smart contract service provider, the client encrypts the request. 18. The computer-implemented method of claim 11, wherein the cross-chain data is obtained from two or more blockchain networks. 19. A non-transitory computer-readable storage medium coupled to one or more computers and configured with instructions executable by said one or more computers to implement the following: A smart contract service provider, including a Trusted Computing Execution Environment (TEE), receives a request from a client associated with a target blockchain network for operating cross-chain data from one or more blockchain networks different from the target blockchain network. The request for operating the cross-chain data includes smart contract computation logic for operating the cross-chain data. The smart contract computation logic is designed by the client itself. The client provides privacy-preserving general smart contract services and cross-chain data computation services. The smart contract service provider is located outside the target blockchain network. The smart contract service provider sends a request for the cross-chain data to the data access service provider; The smart contract service provider receives the cross-chain data from the data access service provider; The TEE generates the result using the cross-chain data; and The smart contract service provider then returns the result to the client. 20. The non-transitory computer-readable storage medium of claim 19, wherein the result is generated by the TEE using the cross-chain data to execute the smart contract computation logic. 21. The non-transitory computer-readable storage medium of claim 19, further configured with instructions executable by the one or more computers to implement the following: The smart contract service provider proves to the client that the TEE includes a virtual machine capable of operating to execute the smart contract computation logic in the request for manipulating cross-chain data. 22. The non-transitory computer-readable storage medium of claim 19, further configured with instructions executable by the one or more computers to implement the following: Before receiving a request from the client to manipulate cross-chain data, the smart contract service provider proves to the client that the smart contract service provider includes the TEE. 23. The non-transitory computer-readable storage medium of claim 19, further configured with instructions executable by the one or more computers to implement the following: The smart contract service provider proves to the data access service provider that the smart service provider includes the TEE; and The smart contract service provider verifies that the data access service provider includes a TEE. 24. The non-transitory computer-readable storage medium of claim 19, further configured with instructions executable by the one or more computers to implement the following: The smart contract service provider uploads the results to the target blockchain network. 25. The non-transitory computer-readable storage medium of claim 24, further configured with instructions executable by the one or more computers to implement the following: Before uploading the results to the target blockchain network, the smart contract service provider proves to the target blockchain network that the smart contract service provider includes the TEE. 26. The non-transitory computer-readable storage medium of claim 19, wherein the smart contract service provider includes a cloud-based server. 27. The non-transitory computer-readable storage medium of claim 19, wherein the result is signed by the TEE using a private key. 28. The non-transitory computer-readable storage medium of claim 19, wherein the cross-chain data is obtained from two or more blockchain networks. 29. A non-transitory computer-readable storage medium coupled to one or more computers and configured with instructions executable by said one or more computers to implement the following: A client associated with a target blockchain network generates a request for operating cross-chain data on one or more blockchain networks different from the target blockchain network. The request for operating the cross-chain data includes smart contract computation logic for operating the cross-chain data. The smart contract computation logic for operating the cross-chain data is designed by the client. The client provides a privacy-preserving general smart contract service and a cross-chain data computation service. The client sends a request to manipulate the cross-chain data to a smart contract service provider that includes a Trusted Computing Execution Environment (TEE), wherein the smart contract service provider is located outside the target blockchain network; and The client receives the result from the smart contract service provider, wherein the result is generated by the TEE using the cross-chain data obtained by the smart contract service provider. 30. The non-transitory computer-readable storage medium of claim 29, further configured with instructions executable by the one or more computers to implement the following: The client then sends the received result to the target blockchain network. 31. The non-transitory computer-readable storage medium of claim 29, further configured with instructions executable by the one or more computers to implement the following: Before sending the request for manipulating cross-chain data to the smart contract service provider, the client verifies that the smart contract provider includes the TEE. 32. The non-transitory computer-readable storage medium of claim 29, further configured with instructions executable by the one or more computers to implement the following: The client verifies that the TEE includes a virtual machine capable of executing the smart contract computation logic in a request to manipulate the cross-chain data. 33. The non-transitory computer-readable storage medium of claim 29, wherein the client includes a software development kit (SDK). 34. The non-transitory computer-readable storage medium of claim 29, wherein the result is signed by the TEE using a private key, and is further configured to be executable by the one or more computers to implement the following instructions: The client uses the public key corresponding to the private key to decrypt the received result. 35. The non-transitory computer-readable storage medium of claim 29, further configured with instructions executable by the one or more computers to implement the following: Before sending the request for manipulating cross-chain data to the smart contract service provider, the client encrypts the request. 36. The non-transitory computer-readable storage medium of claim 30, wherein the cross-chain data is obtained from two or more blockchain networks. 37. A system for providing smart contract services, comprising: An interface configured to receive requests from a client associated with a target blockchain network for operating cross-chain data from one or more blockchain networks different from the target blockchain network, wherein the requests for operating the cross-chain data include smart contract computation logic for operating the cross-chain data, the smart contract computation logic being designed by the client itself, the client providing privacy-preserving general smart contract services and cross-chain data computation services; wherein the system is located outside the target blockchain network; and A Trusted Computing Execution Environment (TEE), wherein the TEE includes: One or more computers; and One or more computer-readable storage devices, coupled to the one or more computers and configured with instructions executable by the one or more computers to implement the following: Send a request for the cross-chain data to the data access service provider; Receive the cross-chain data from the data access service provider; and The results are generated using the cross-chain data; and The interface is configured to return the result to the client. 38. The system of claim 37, wherein the result is generated by the TEE using the cross-chain data to execute the smart contract computation logic. 39. The system of claim 37, wherein the computer-readable storage medium is further configured with instructions executable by the one or more computers to implement the following: The smart contract service provider proves to the client that the TEE includes a virtual machine capable of operating to execute the smart contract computation logic in the request for manipulating cross-chain data. 40. The system of claim 37, wherein the computer-readable storage medium is further configured with instructions executable by the one or more computers to implement the following: Before receiving a request from the client to manipulate cross-chain data, the smart contract service provider proves to the client that the smart contract service provider includes the TEE. 41. The system of claim 37, wherein the computer-readable storage device is further configured with instructions executable by the one or more computers to implement the following: The smart contract service provider proves to the data access service provider that the smart contract service provider includes the TEE; and The smart contract service provider verifies that the data access service provider includes a TEE. 42. The system of claim 37, wherein the computer-readable storage device is further configured with instructions executable by the one or more computers to implement the following: The smart contract service provider uploads the results to the target blockchain network. 43. The system of claim 42, wherein the computer-readable storage device is further configured with instructions executable by the one or more computers to implement the following: Before uploading the results to the target blockchain network, the smart contract service provider proves to the target blockchain network that the smart contract service provider includes the TEE. 44. The system of claim 37, wherein the smart contract service provider includes a cloud-based server. 45. The system of claim 37, wherein the result is signed by the TEE using a private key. 46. The system of claim 37, wherein the cross-chain data is obtained from two or more blockchain networks. 47. A system for providing smart contract services, comprising: One or more computers; and One or more computer-readable storage devices, coupled to the one or more computers and configured with instructions executable by the one or more computers to implement the following: A client associated with a target blockchain network generates a request for operating cross-chain data on one or more blockchain networks different from the target blockchain network. The request for operating the cross-chain data includes smart contract computation logic for operating the cross-chain data. The smart contract computation logic for operating the cross-chain data is designed by the client. The client provides a privacy-preserving general smart contract service and a cross-chain data computation service. The client sends the request for manipulating cross-chain data to a smart contract service provider that includes a Trusted Computing Execution Environment (TEE), wherein the smart contract service provider is located outside the target blockchain network; and The client receives the result from the smart contract service provider, wherein the result is generated by the TEE using the cross-chain data obtained by the smart contract service provider. 48. The system of claim 47, wherein the computer-readable storage device is further configured with instructions executable by the one or more computers to implement the following: The client then sends the received result to the target blockchain network. 49. The system of claim 47, wherein the computer-readable storage device is further configured with instructions executable by the one or more computers to implement the following: Before sending the request for manipulating cross-chain data to the smart contract service provider, the client verifies that the smart contract service provider includes the TEE. 50. The system of claim 47, wherein the computer-readable storage device is further configured with instructions executable by the one or more computers to implement the following: The client verifies that the TEE includes a virtual machine capable of executing the smart contract computation logic in a request to manipulate the cross-chain data. 51. The system of claim 47, wherein the client includes a software development kit (SDK). 52. The system of claim 47, wherein the result is signed by the TEE using a private key, and the computer-readable storage device is further configured with instructions executable by the one or more computers to implement the following: The client uses the public key corresponding to the private key to decrypt the received result. 53. The system of claim 47, wherein the computer-readable storage device is further configured with instructions executable by the one or more computers to implement the following: Before sending the request for manipulating cross-chain data to the smart contract service provider, the client encrypts the request. 54. The system of claim 47, wherein the cross-chain data is obtained from two or more blockchain networks.