CN115380303A - Trusted platform based on block chain - Google Patents

Abstract

Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for cross-chain communication in a blockchain based trusted system are disclosed. One of the methods includes receiving, by a first inter-chain communication component in a first blockchain network, a message including account data from a blockchain node in the first blockchain network. The first cross-chain communication component determines whether the ledger data is valid. If the ledger data is valid, the first cross-chain communication component generates formatted ledger data based on the ledger data and sends a cross-chain message including the formatted ledger data to a second cross-chain communication component in a second blockchain network.

Description

Trusted platform based on block chain

Technical Field

This document relates to a blockchain-based trusted platform for implementing trusted digital transactions.

Background

A Distributed Ledger System (DLS), which may also be referred to as a consensus network and/or blockchain network, enables participating entities to securely and tamperproof store data. Without reference to any particular use case, DLS is often referred to as a blockchain network. Examples of types of blockchain networks may include public blockchain networks, private blockchain networks, and federation blockchain networks. A federated blockchain network is provided for a selected entity group that controls the consensus process and includes an access control layer.

Digital networks have enabled people around the world to conveniently and efficiently find and interact with information. For example, social media platforms allow people to easily share messages, photos, and videos with friends and colleagues. Online shopping websites allow consumers to easily find information about various products and send payments electronically to purchase products from businesses around the world. News websites provide users with up-to-date information about events occurring around the world. The media platform provides a user with a large amount of music and movies for the user to download or stream online. The user may search for legal services online. The ride platform allows passengers to easily find vehicles using mobile phones and pay for them. As more and more people access the internet and digitally conduct more and more transactions, the number of fraudulent online activities and disputes between parties to digital transactions have increased.

In some cases, the digital data in the online transaction may contain errors, for example, the original data may be corrupted or tampered with or the original data may be intercepted by a hacker and replaced by counterfeit data during transmission. It may be difficult to prove or deny the authenticity and accuracy of the data. It is therefore desirable to allow users to conduct online digital transactions in a secure and efficient manner.

Disclosure of Invention

Embodiments of the subject matter can include one or more features, either alone or in combination.

For example, in one embodiment, a computer-implemented method for cross-chain communication includes: receiving, by a first inter-chain communication component in a first blockchain network, a message including account data from a blockchain point in the first blockchain network; determining, by the first cross-chain communication component, whether the ledger data is valid; generating, by the first cross-chain communication component, formatted ledger data based on the ledger data in response to determining that the ledger data is valid; and sending, by the first cross-chain communication component, a cross-chain message including the formatted ledger data to a second cross-chain communication component in a second blockchain network.

In some embodiments, these generalized and specialized aspects may be implemented using a system, method, or computer program, or any combination of systems, methods, and computer programs. The above and other described embodiments may each optionally include one or more of the following aspects:

in some embodiments, the block link points in the first block chain network comprise service intelligent contracts and cross-chain intelligent contracts, the method further comprising: receiving, by the cross-chain intelligent contract, a message from the service intelligent contract that includes the ledger data; and sending a message to the first cross-chain communication component through the cross-chain smart contract.

In some embodiments, the first cross-chain communication component comprises a relay component and receiving, by the first cross-chain communication component in the first blockchain network, a message comprising the ledger data from the blockchain node in the first blockchain network comprises: receiving, by the first cross-link communication component from the cross-link smart contract for the blockchain node through the relay component, a message including the ledger data.

In some embodiments, the method further comprises: obtaining, by the relay component, the ledger data from the message; and sending, by the relay component, the ledger data to a predictive teller.

In some embodiments, the first cross-chain communication component further comprises the propheter. Determining, by the first cross-chain communication component, whether the ledger data is valid, comprising: receiving, by the book agent, the ledger data from the relay component; and determining, by the predictive agent, whether the ledger data is valid.

In some embodiments, in response to determining that the ledger data is valid, generating, by the first cross-chain communication component, the formatted ledger data based on the ledger data comprises: in response to determining that the ledger data is valid, generating, by the predictive machine, the formatted ledger data based on the ledger data; and sending, by the predictive engine, the formatted ledger data to the relay component.

In some embodiments, sending, by the first cross-chain communication component to the second cross-chain communication component in the second blockchain network, the cross-chain message containing the formatted ledger data comprises: sending, by the relay component, a cross-chain message comprising the formatted ledger data to a second cross-chain communication component.

In some embodiments, the relay component is a first relay component, the second cross-chain communication component comprises a second relay component, the blockchain node in the first blockchain network is a first blockchain node, and the second blockchain network comprises a second blockchain node. The method further comprises the following steps: receiving, by the second relay component, the cross-chain message from the first relay component; obtaining, by the second relay component, the formatted ledger data from the cross-chain message; and transmitting, by the second relay component, the formatted ledger data to the second block link point.

In some embodiments, the cross-chain intelligent contract is a first cross-chain intelligent contract and the service intelligent contract is a first service intelligent contract. The second block link point comprises a second inter-chain intelligent contract and a second service intelligent contract, the method further comprising: receiving, by the second cross-chain smart contract, the formatted ledger data from the second relay component; determining, by the second cross-chain smart contract, whether the formatted ledger data is valid; obtaining, by the second cross-chain smart contract, the ledger data from the formatted ledger data in response to determining that the formatted ledger data is valid; and sending, by the second cross-chain intelligent contract, the obtained ledger data to the service intelligent contract.

It should be understood that any combination of the various aspects and features described herein may be included according to the methods described herein. That is, the methods according to the present disclosure are not limited to the combinations of the various aspects and features specifically described herein, but also include any combination of the various aspects and features provided.

The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other features and advantages of the disclosure will be apparent from the description and drawings, and from the claims.

Drawings

FIG. 1 is a diagram illustrating an example of an environment that may be used to perform embodiments herein.

Fig. 2 is a diagram illustrating an example of an architecture according to embodiments herein.

Fig. 3 depicts an example of a system for blockchain transactions according to embodiments herein.

Fig. 4 depicts an example of a blockchain data recording process in a service system mode that may be performed in accordance with embodiments herein.

Fig. 5 depicts an example of a blockchain data validation process in a service system mode that may be performed according to embodiments herein.

Fig. 6 depicts an example of a blockchain data recording process in blockchain platform mode that may be performed according to embodiments herein.

Fig. 7 depicts an example of a blockchain data validation process in blockchain platform mode that may be performed in accordance with embodiments herein.

Fig. 8 is a schematic diagram illustrating an example of a block chain based trusted platform according to embodiments herein.

Fig. 9 is a diagram illustrating an example of a system for online transactions, according to embodiments herein.

Fig. 10 is a diagram illustrating an example of a system for providing trusted time according to embodiments herein.

Fig. 11 is a diagram illustrating an example of a system for providing a trusted identity, according to embodiments herein.

Fig. 12 is a diagram illustrating an example of a system for trusted execution according to embodiments herein.

Fig. 13 is a diagram illustrating an example of an architecture for blockchain security according to embodiments herein.

Fig. 14 is a diagram illustrating an example of a cross-chain communication system according to embodiments herein.

Fig. 15 depicts an example of a process for cross-chain communication that may be performed in accordance with an embodiment herein.

Fig. 16 depicts an example of data storage in a blockchain-based trusted platform according to embodiments herein.

Fig. 17 depicts an example of a system for implementing a blockchain-based trusted platform according to embodiments herein.

Fig. 18 depicts an example of a process for recording ledger data according to embodiments herein.

Fig. 19 depicts an example of a process for validating ledger data according to embodiments herein.

Fig. 20 depicts an example of data transmission across chains and across networks according to embodiments herein.

Fig. 21 depicts an example of a process of data transfer across chains and across networks according to embodiments herein.

Fig. 22 depicts an example of data communication across a network and across a chain according to embodiments herein.

Fig. 23 depicts an example of a block chain based trusted platform according to embodiments herein.

Fig. 24 depicts another example of a blockchain based trusted platform according to embodiments herein.

Fig. 25 depicts an example of a process that may be performed according to embodiments herein.

Fig. 26 depicts an example of modules of an apparatus according to embodiments herein.

Like reference numbers and designations in the various drawings indicate like elements.

Detailed Description

Techniques for a trusted platform based on blockchains are described herein. These techniques typically involve blockchain transactions in a blockchain based trusted platform.

The techniques described herein produce several technical effects. In some embodiments, the described techniques may be applied in a variety of applications and scenarios to provide an efficient, trusted, scalable, and high-performance blockchain-based environment for online transactions. The described technology provides a blockchain-based trusted platform that allows users to conduct transactions (e.g., legal actions, business contract executions) in an efficient and secure manner in a blockchain-based environment. In some embodiments, the described techniques allow a user to access blockchain nodes deployed in a blockchain-based trusted platform through a service system that is external to the blockchain-based trusted platform. This prevents a user from directly accessing the blockchain node, thereby reducing the likelihood of malicious actors compromising the data stored in the blockchain node. In some embodiments, the described techniques support encryption and authentication using a key pair between a service system and a blockchain based trusted platform. For example, the service system may send public-key encrypted data to the blockchain-based trusted platform so that the blockchain-based trusted platform can decrypt the encrypted data using the private key. In an example, the blockchain-based trusted platform can send a private key-based digital signature to the service system so that the service system can authenticate the digital signature using a public key. This may provide an additional layer of data security in the transfer of data between the service system and the block chain based trusted platform. In some embodiments, a hash function or algorithm is used to verify whether data stored in the system has been changed. In one example, a service system or a trusted platform based on blockchain may calculate a hash value of received data and compare the hash value to a previously stored hash value. If the two hash values match, it may be determined that the data has not been changed. If the two hash values do not match, it may be determined that the data has been changed. This may reduce the likelihood of counterfeiting or tampering of data stored in the system.

In some embodiments, a blockchain-based trusted platform may be implemented in a Trusted Execution Environment (TEE). A TEE is a trusted execution environment within hardware (one or more processors, memory) that is isolated from the hardware's operating environment (e.g., operating System (OS), basic input/output system (BIOS)). A TEE is a separate secure area of a processor that ensures the confidentiality and integrity of code executing within the main processor and data loaded into the main processor. The blockchain and TEE techniques described herein may be used to generate highly reliable records related to online transactions. In addition to TEE, the described techniques also allow a blockchain-based trusted platform to utilize the functionality of a trusted time module, a trusted identity module, and a trusted computing module to authenticate documents and/or user identities in a manner that conforms to relevant evidence rules. This may enable an application of a blockchain-based trusted platform that provides a service to maintain a verification record of information (e.g., who, what, and when) about events that the service occurred at each of multiple steps or key points in time in a manner that is compliant (or more compliant) with evidence rules than previous systems. Thus, the trustworthiness of data generated by an application running in a trusted platform based on blockchains may be enhanced.

In some embodiments, the described techniques provide a cross-chain communication system that allows for reliable and efficient data transfer between two blockchain networks. In one example, a cross-chain communication system may utilize the functionality of service intelligence contracts and cross-chain intelligence contracts executed in blockchain nodes of a blockchain network. In an example, the cross-chain communication system can also utilize the functionality of a cross-chain relay component and an oracle machine (oracle machine) implemented in a cross-chain communication component of a blockchain network. The intelligent contracts and cross-chain communication components enable automatic and efficient cross-chain data transfer, for example, by converting ledger data into a unified data format.

Further background is provided for embodiments herein, as described above, a Distributed Ledger System (DLS), which may also be referred to as a consensus network (e.g., consisting of Peer-to-Peer (Peer) nodes) and a blockchain network, enables participating entities to securely and non-tamperproof conduct transactions and store data. Although the term blockchain is generally associated with a particular network and/or use case, blockchains as used herein generally refer to DLSs without reference to any particular use case.

Blockchains are data structures that store transactions in a manner that is not tamperproof by the transaction. Thus, the transactions recorded on the blockchain are reliable and trustworthy. A block chain includes one or more blocks. Each block in the chain is linked to the immediately preceding block in the chain by a cryptographic hash value (cryptographic hash) of the preceding block contained in the chain. Each tile also includes a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have been verified by nodes in the blockchain network are hashed and encoded into a merkel (Merkle) tree. A merkel tree is a data structure in which data at the leaf nodes of the tree is hashed and all hash values in each branch of the tree are concatenated at the root of the branch. This process proceeds down the tree up to the root of the entire tree where hash values representing all the data in the tree are stored. By determining whether the hash value of the transaction purported to be stored in the tree is consistent with the structure of the tree, the hash value can be quickly verified.

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

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

In some examples, in a federated blockchain network, a global blockchain is provided as a blockchain that is replicated across all nodes. That is, all of the consensus nodes are in a fully consensus state with respect to the global blockchain. To achieve consensus (e.g., agree to add a block to a blockchain), a consensus protocol is implemented within a federated blockchain network. For example, a federated blockchain network may implement a pragmatism fault tolerant (PBFT) consensus, which will be described in further detail below.

Fig. 1 is a diagram illustrating an example of anenvironment 100 that may be used to perform embodiments herein. In some examples,environment 100 enables entities to participate in afederated blockchain network 102. Theenvironment 100 includescomputing systems 106, 108 and anetwork 110. In some examples, the network 120 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 may be accessed through wired and/or wireless communication links. In some examples,network 110 enables communication withfederated blockchain network 102, as well as communication withinfederated blockchain network 102. In general,network 110 represents one or more communication networks. In some cases, thecomputing systems 106, 108 may be nodes of a cloud computing system (not shown), or each of thecomputing systems 106, 108 may be a separate cloud computing system that includes multiple computers interconnected by a network and functioning as a distributed processing system.

In the depicted example,computing systems 106, 108 may each include any suitable computing device capable of participating as a node infederated blockchain network 102. Examples of computing devices include, but are not limited to, servers, desktop computers, laptop computers, tablet computing devices, and smart phones. In some examples,computing systems 106, 108 carry one or more computer-implemented services for interacting withfederation blockchain network 102. For example, thecomputing system 106 may host a computer-implemented service of a first entity (e.g., user a), such as a transaction management system used by the first entity to manage its transactions with one or more other entities (e.g., other users). Thecomputing system 108 may host a computer-implemented service of a second entity (e.g., user B), such as a transaction management system used by the second entity to manage its transactions with one or more other entities (e.g., other users). In the example of fig. 1, thefederated blockchain network 102 is represented as a peer-to-peer network of nodes, and thecomputing systems 106, 108 provide the nodes of the first and second entities, respectively, participating in thefederated blockchain network 102.

Fig. 2 depicts an example of anarchitecture 200 according to embodiments herein. Theexemplary concept architecture 200 includesparticipant systems 202, 204, 206 corresponding to participant a, participant B, and participant C, respectively. Each participant (e.g., user, enterprise) participates in ablockchain network 212 provided as a peer-to-peer network that includes a plurality ofnodes 214, at least some of which record information in ablockchain 216 without tampering. As detailed further herein, although asingle blockchain 216 is schematically depicted inblockchain network 212, multiple copies ofblockchain 216 are provided and maintained onblockchain network 212.

In the depicted example, eachparticipant system 202, 204, 206 is provided by or represents participant a, participant B, and participant C, respectively, and serves as arespective node 214 in the blockchain network. As used herein, a node generally refers to an individual system (e.g., computer, server) that is connected to theblockchain network 212 and enables the respective participants to participate in the blockchain network. In the example of fig. 2, a participant corresponds to eachnode 214. However, it is contemplated that a participant may operatemultiple nodes 214 within theblockchain network 212, and/or that multiple participants may share asingle node 214. In some examples, theparticipant systems 202, 204, 206 communicate with or through theblockchain network 212 using a protocol (e.g., hypertext transfer protocol secure (HTTPS)) and/or using Remote Procedure Calls (RPCs).

Thenodes 214 may have different degrees of participation within theblockchain network 212. For example, somenodes 214 may participate in the consensus process (e.g., as miners' nodes that add tiles to the blockchain 216), whileother nodes 214 do not participate in the consensus process. As another example, somenodes 214 store a full copy ofblockchain 216, whileother nodes 214 store only partial copies ofblockchain 216. For example, data access permissions may restrict blockchain data stored by respective participants within their respective systems. In the example of fig. 2,participant systems 202, 204, and 206 storecomplete copies 216', 216", and 216"', respectively, ofblock chain 216.

A chain of blocks (e.g.,block chain 216 of fig. 2) consists of a chain of blocks, each block storing data. Examples of data include transaction data representing transactions between two or more participants. Although "transaction" is used herein by way of non-limiting example, it is contemplated that any suitable data may be stored in the blockchain (e.g., documents, images, video, audio). Examples of transactions may include, but are not limited to, the exchange of value (e.g., assets, products, services, currency). Transaction data is stored in the blockchain in a tamperproof manner. That is, the transaction data cannot be changed.

The transaction data is hashed prior to being stored in the chunk. The hash process is a process of converting transaction data (provided as character string data) into a hash value of a fixed length (also provided as character string data). It is not possible to perform a de-hash process (un-hash) on the hash value to obtain the transaction data. The hashing process ensures that even minor changes to the transaction data result in disparate hash values. Further, as described above, the hash value has a fixed length. That is, the length of the hash value is fixed regardless of the size of the transaction data. The hash process includes processing the transaction data through a hash function to generate a hash value. Examples of hash functions include, but are not limited to, secure Hash Algorithm (SHA) -256, which outputs a 256-bit hash value.

Transaction data for a plurality of transactions is hashed and stored in a block. For example, hash values for two transactions are provided, and themselves are hashed to provide another hash value. This process is repeated until a single hash value is provided for all transactions to be stored in the block. This hash value is called the Merkle root hash value and is stored in the header of the chunk. Any change in a transaction causes its hash value to change and ultimately the Merkle root hash value to change.

The block is added to the block chain by a consensus protocol. A plurality of nodes in a blockchain network participate in a consensus protocol and perform work to add a block to a blockchain. Such nodes are referred to as consensus nodes. The PBFT introduced above is used as a non-limiting example of a consensus protocol. The consensus node performs a consensus protocol to add transactions to the blockchain and updates the overall state of the blockchain network.

In more detail, the consensus node generates a chunk header, hashes all transactions in the chunk, and combines the hash values in pairs to generate further hash values until a single hash value (Merkle root hash value) is provided for all transactions in the chunk. This hash value is added to the block header. The consensus node also determines the hash value of the latest chunk in the chain of chunks (i.e., the last chunk added to the chain of chunks). The consensus node also adds a random value (nonce value) and a timestamp to the chunk header.

Typically, PBFT provides a practical byzantine state machine replication that is tolerant of byzantine errors (e.g., failed nodes, malicious nodes). This is achieved by assuming in the PBFT that a failure will occur (e.g., assuming there is an independent node failure and/or a manipulated message sent by a consensus node). In PBFT, consensus nodes are provided in a sequence comprising a primary consensus node and a backup consensus node. The master consensus node is changed periodically. The transaction is added to the blockchain by agreeing on the world state of the blockchain network by all consensus nodes within the blockchain network. In this process, messages are transmitted between the consensus nodes, and each consensus node proves that a message was received from a designated peer node and verifies that the message was not modified during transmission.

In PBFT, the consensus protocol is provided in multiple phases with all consensus nodes starting in the same state. First, a client sends a request to a master consensus node to invoke a service operation (e.g., perform a transaction within a blockchain network). In response to receiving the request, the primary consensus node multicasts the request to the backup consensus node. The backup consensus node executes the request and each node sends a reply to the client. The client waits until a threshold number of replies are received. In some examples, the client waits until f +1 replies are received, where f is the maximum number of failed consensus nodes that can be tolerated within the blockchain network. The end result is that a sufficient number of consensus nodes agree on the requirements for a record to be added to the blockchain and that record is either accepted or rejected.

In some blockchain networks, cryptographic schemes are implemented to maintain privacy of transactions. For example, two nodes may encrypt transaction data if they want to maintain transaction privacy so that other nodes in the blockchain network cannot see the details of the transaction. Examples of encryption include, but are not limited to, symmetric encryption 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 may be used for multiple nodes, so each node may encrypt/decrypt transaction data.

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

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

In some embodiments, nodes of and/or in communication with a blockchain network are capable of operating using a Trusted Execution Environment (TEE). At a higher level, a TEE is a trusted execution environment within hardware (one or more processors, memory) that is isolated from the hardware's operating environment (e.g., operating System (OS), basic input/output system (BIOS)). In more detail, the TEE is a separate secure area of the processor that ensures confidentiality and integrity of code executing within the main processor and data loaded into the main processor. Within the processor, the trusted execution environment runs in parallel with the operating system. At least part of a so-called Trusted Application (TA) executes within a trusted execution environment and has access to a processor and memory. With a trusted execution environment, trusted applications may be protected from other applications running in the host operating system. Further, the trusted execution environment cryptographically isolates the trusted applications from each other inside the trusted execution environment.

Examples of trusted execution environments include the software protection extensions (SGX) provided by Intel corporation of Santa Clara, calif. Although SGX is discussed herein by way of example, it is contemplated that any suitable trusted execution environment may be used to implement embodiments herein.

SGX provides a hardware-based trusted execution environment. In SGX, trusted hardware is the core of a Central Processing Unit (CPU), and a portion of physical memory is isolated to protect selected code and data. The isolated portion of memory is called an enclave (enclave). More specifically, the enclave is provided as an Enclave Page Cache (EPC) in memory and mapped to the application address space. The memory (e.g., DRAM) includes a reserved random access memory (PRM) for the SGX. Random access memory is the lowest BIOS level of contiguous memory space and is not accessible by any software. Each enclave page cache is a set of memory (e.g., 4 KB) allocated by the operating system to load application data and code in random access memory. Enclave Page Cache Metadata (EPCM) is the entry address of the corresponding enclave page cache and ensures that each enclave page cache can only be shared by one enclave. That is, a single enclave may use multiple enclave page caches, while an enclave page cache is dedicated to a single enclave.

During execution of a trusted application, the processor operates in a so-called enclave mode when accessing data stored in an enclave. Operation in enclave mode would perform an additional hardware check for each memory access. In software protected extensions (SGX), trusted applications are compiled into a trusted part and an untrusted part. For example, the OS, BIOS, privileged system code, virtual Machine Manager (VMM), system Management Mode (SMM), etc. cannot access the trusted section. In operation, the trusted application runs in the PRM of memory and creates an enclave. Trusted functions executed by trusted portions within the enclave are called by untrusted portions, and code executing within the enclave treats the data as clear data (unencrypted) and denies external access to the data. The trusted portion provides an encrypted response to the call and the trusted application continues to execute.

An authentication process may be performed to verify that desired code (e.g., a trusted portion of a trusted application) is being securely executed within a trusted execution environment provided by the SGX. Typically, the authentication process includes the trusted application receiving an authentication request from a challenger (e.g., another node in the blockchain network, a Key Management System (KMS) of the blockchain network). In response, the trusted application requests that it generate a remote authentication, also known as a quote (quote), on the fly. Generating the remote authentication includes the local authentication being sent from the enclave to a so-called quote enclave, which verifies the local authentication and converts the local authentication to the remote authentication by signing the local authentication using the asymmetric authentication key. Remote authentication (quote) is provided to the challenger (e.g., the key management system of the blockchain network).

The challenger verifies the remote authentication using the authentication verification service. For SGX, intel provides Intel Authentication Service (IAS) which receives remote authentication from a challenger and verifies the remote authentication. More specifically, the IAS processes the remote authentication and provides a report (e.g., an Authentication Verification Report (AVR)) indicating whether the remote authentication has been verified. If not, an error may be indicated. If verified (the desired code is securely executed in the trusted execution environment), the challenger can start or continue to interact with the trusted application. For example, in response to authentication, the key management system (as a challenger) can issue an asymmetric cryptographic key (e.g., a public and private key pair) to a node executing a trusted execution environment (e.g., via a key exchange process such as elliptic curve Diffie-Hellman (ECDH)) to enable the node to securely communicate with other nodes and/or clients.

Techniques are described herein for implementing a blockchain-based system (which may be a trusted online system) that enhances trust between users and provides various services or processing tools to allow users to conduct transactions (e.g., legal actions, business contract executions) in an efficient manner. Referring to fig. 3, fig. 3 shows an example of asystem 300 for blockchain transactions. In some embodiments,system 300 may be a blockchain system associated with a judicial agency and/or a user of a judicial service. Thesystem 300 may be deployed on a private network or the internet. In some embodiments,system 300 may be a blockchain system for executing and recording contracts or protocols (e.g., real estate contracts) between parties. In the example shown in fig. 3,system 300 includes a blockchain based trusted platform/system 312 that includes ablockchain access layer 314, participating nodes (e.g., nodes 308-1, 308-2, 310-1, and 310-2), and ablockchain platform layer 316. In some embodiments,blockchain access layer 314 may include a communication interface that allows entities external to blockchain-based trustedplatform 312 to communicate with participating nodes of blockchain-based trustedplatform 312. Theblockchain access layer 314 may include one or more of a Graphical User Interface (GUI), a command line, a script, and an Application Programming Interface (API). In some embodiments, theblockchain platform layer 316 may provide service capabilities of the internet information infrastructure and may support cloud storage deployments such as public clouds and private clouds.Blockchain platform layer 316 may also provide support for secure storage, analysis, and computation of data stored in trustedplatform 312.

The participating nodes of blockchain based trustedplatform 312 include blockchain nodes such as nodes 308-1 and 308-2. In the illustrated example, blockchain nodes 308-1 and 308-2 may be court or judicial agency deployed blockchain nodes. Blockchain-based trustedplatform 312 also includes third party blockchain nodes, such as nodes 310-1 and 310-2. In some embodiments, the third party blockchain node may have identity management, rights control functionality (e.g., rights management based on smart contracts, users, blockchains), and hierarchical access control. In some examples, third party nodes 310-1 and 310-2 may include blockchain nodes, such as credential issuer nodes, time service nodes, and forensics expert nodes (forensics expert nodes). Note that for illustrative purposes, blockchain-based trustedplatform 312 is shown to include nodes 308-1, 310-1, and 310-2. Blockchain-based trustedplatform 312 may include any suitable number of non-third party nodes and third party nodes. In some embodiments, one or more of nodes 308-1, 310-1, and 310-2 may be consensus nodes that participate in a consensus process for the blockchain based trustedplatform 312.

As previously described,blockchain access layer 314 may include a communication interface that allows entities external to blockchain-based trustedplatform 312 to communicate with participating nodes of blockchain-based trustedplatform 312. In the illustrated example, theblockchain access layer 314 may be configured to allow external service systems (e.g., service systems 306-1 through 306-6) to communicate with participating blockchain link points (e.g., nodes 308-1, 310-1, and 310-2) in the blockchain based trustedplatform 312. In some embodiments, service systems 306-1 through 306-6 may include computer systems that do not participate in the consensus process of blockchain based trustedplatform 312. Service systems 306-1 through 306-6 may be configured to provide services touser 302 by accessing a blockchain based trustedplatform 312. In some examples, a service system (e.g., service system 306-1) may allow a user to digitally fill in and submit legal documents according to consensus processes performed by participating nodes of the blockchain based trustedplatform 312 in a manner that complies with relevant legal regulations. In some examples, a service system (e.g., service system 306-2) may allow one party to execute a court order in a manner consistent with relevant legal provisions, such as digitally issuing a bank check out court order to an opposing bank. In some embodiments, one or more service systems of blockchain-based trustedplatform 312 and blockchain nodes may form a subsystem. In the illustrated example, service systems 306-1 and 306-2 and blockchain node 308-1 may form a subsystem 304-1 deployed in a judicial institution (e.g., court). Note that subsystem 304-1 is shown deployed in a judicial institution (e.g., court) for illustrative purposes only. Subsystem 304-1, as well as other subsystems 304-2 and 304-3, may be systems deployed in any suitable type of establishment or facility, such as real estate agents, brokers, commercial banks, third party escrow, police stations, government agencies, and the like. In some embodiments, a subsystem that includes at least one blockchain node of a blockchain-based trustedplatform 312 may be referred to as a node subsystem, while a subsystem that does not include any blockchain node of the blockchain-based trustedplatform 312 may be referred to as a non-node subsystem. In the illustrated example, subsystem 304-1 includes blockchain node 308-1 in blockchain-based trustedplatform 312, and thus the court in which subsystem 304-1 is deployed may be referred to as a court connected to the blockchain (e.g., a node court). Subsystem 304-2 does not include any blockchain nodes of blockchain-based trustedplatform 312, and thus the court in which subsystem 304-2 is deployed is referred to as a court that is not connected to a blockchain (e.g., a non-nodal court).

In some embodiments, the services provided by service systems 306-1 through 306-6 may include two types: blockchain data recording and blockchain data verification. In some examples, the blockchain data recording service may be initiated byuser 302 sending data in a digital document or file (e.g., legal file, business contract) to a service system (e.g., service system 306-1). The data may be processed by the service system and recorded into a blockchain stored in a blockchain-based trustedplatform 312 in a blockchain link point (e.g., blockchain node 308-1). The block chain data verification service may be initiated by a user sending a request to the service system to verify data. The service system receiving the request may process the request and validate the data. In some embodiments, ledger data may be generated during the blockchain data recording and validation process. In some embodiments, the blockchain data recording and verification process may be performed in one or more of a service system mode and a blockchain platform mode. In service system mode, a service system (e.g., service system 306-1) may generate ledger data based on data received from a user (e.g., user 302) and send the ledger data to a blockchain node (e.g., blockchain node 308-1) for logging. In a blockchain platform based mode, a blockchain node (e.g., blockchain link point 308-2) may generate and record ledger data into a blockchain stored in the blockchain node based on data received from a user (e.g., user 302). The block chain data recording verification process in the two modes will be described in more detail below with reference to fig. 4 to 7.

Fig. 4 depicts an example of a blockchaindata recording process 400 in a service system mode that can be performed in accordance with embodiments herein. For convenience,process 400 will be described as being performed by a system of one or more computers located at one or more locations and suitably programmed according to the present disclosure. For example, a suitably programmed blockchain-based system, such assystem 300 of FIG. 3, may performprocess 400.

Theprocess 400 begins atstep 410, where the user 402 sends data for recording to theservice system 404. In some embodiments, user 402 may send a request toservice system 404 for recording data, where the request includes the data. In some embodiments, the data may be in the format of a digital document (e.g., a business agreement) or a digital file (e.g., a forensic image, video, etc.).

User 402 may beuser 302 as described in the description of fig. 3. In some embodiments, user 402 may include, for example, any computer, module, server, or computing element encoded to perform the methods described herein. In some examples, the user 402 may include a web browser and a software application for providing various functions of a client computing device. In some embodiments,service system 404 may be a service system as described in the description of FIG. 3 (e.g., service system 306-1).

Atstep 412,service system 404 may trigger data logging after receiving data from user 402. In some embodiments,service system 404 may automatically trigger data recording in response to receiving data or a request from user 402. In some examples,service system 404 may include an intelligent contract for processing data or requests received from user 402. Once the smart contract receives data or a request from a user, the smart contract may automatically execute to perform the following data record processing.

In some embodiments,service system 404 may verify the identity of user 402 after receiving data from user 402. In some examples, user 402 may send a user identification toservice system 404 along with the data, such thatservice system 404 may compare the received user identification to the user identifications of authorized users stored inservice system 404. If it is determined that user 402 is an unauthorized user,service system 404 may ignore the request from user 402 and discard the data. If it is determined that user 402 is an authorized user,service system 404 may continue to process the received data.

Atstep 414,service system 404 computes a hash value based on the data received from user 402. In some embodiments, the hash value may be calculated according to a predetermined cryptographic hash function or algorithm (e.g., MD5 message digest algorithm, SHA-1 (secure hash algorithm 1) hash function, wherlpool (Whirlpool) hash function, etc.). In some examples,service system 404 may apply a predetermined hash function to data received from a user and generate a hash value for the data. In some examples, theservice system 404 may generate a hash value based on the data received from theuser 404 and the user identification of theuser 404.

Atstep 416,service system 404 stores the data received from user 402 in a local store ofservice system 404. In some embodiments, theservice system 404 may also include a local storage subsystem including a storage medium such as a non-volatile memory standard (NVME), an SSD, a Hard Disk Drive (HDD), or a magnetic burst cutting (SMR). In some embodiments, the local storage subsystem of theservice system 404 may be generated or expanded for better availability, partition tolerance, flexibility, and cost. For example, the local storage subsystem of theservice system 404 may be scaled by adding more servers or storage nodes and thereby increasing capacity and performance. The local storage subsystem may also use less expensive standard servers, drives, and networks. In some embodiments, the local storage subsystems of thestorage system 404 may increase the utilization of standard servers, and thus may result in less power consumption, maintenance costs, better cooling efficiency and space utilization, and the like.

In some embodiments, theservice system 404 may include a multi-tier storage subsystem including a plurality of storage devices configured to store data based on data access frequency. In some examples,service system 404 may include a first storage device, such as a cloud disk or cloud-based storage device (e.g., SSD cloud disk, embedded SSD (ESSD) cloud disk), to store the most frequently accessed data. Theservice system 404 may include a second storage device, such as a NAS (network attached storage) device, for storing data with a lower access frequency.

Atstep 418,service system 404 generates ledger data based on the hash value generated atstep 414 and sends the ledger data to blockchain-based trustedplatform 406. In some embodiments, blockchain-based trustedsystem 406 may be implemented as blockchain-based trustedsystem 312 of fig. 3. In some examples, blockchain-based trustedsystem 406 may include one or more blockchain nodes (e.g., blockchain node 308-1), andservice system 404 may send the account data to one blockchain node of blockchain-based trustedsystem 406. In some embodiments,service system 404 may send ledger data to blockchain-based trustedsystem 406 via a communication interface, such asblockchain access layer 314 of fig. 3.

In some embodiments, the ledger data includes the hash value generated atstep 414. Ledger data may include additional information, such as metadata for data received from user 402 and metadata for hash values. In some examples, the metadata may include one or more of an author of the data or hash value, a creation date, a modification date, and a file size.

In some embodiments, theservice system 404 may encrypt the ledger data according to a predetermined encryption function or algorithm. In some examples,service system 404 can encrypt the ledger data using a public key of blockchain-based trustedplatform 406 and send the encrypted ledger data to blockchain-based trustedplatform 406 to decrypt the encrypted ledger data by using its private key.

Atstep 420, upon receiving ledger data fromservice system 404, blockchain-based trustedplatform 406 stores the ledger data including the hash value in blockchain-based trustedplatform 406. In some embodiments, blockchain based trustedplatform 406 may store ledger data in one or more participating nodes of blockchain based trustedplatform 406. In some embodiments, one or more participating nodes of blockchain based trustedplatform 406 may be consensus nodes that participate in a consensus process of blockchains. In some embodiments, consensus nodes of blockchain based trusted platform 406 (e.g., blockchain nodes 308-1, 308-2 and/or third party blockchain nodes 310-1 and 310-2 of FIG. 3) may perform consensus processing on the ledger data. After consensus is achieved between the consensus nodes, the blockchain-based trustedplatform 406 may record ledger data in blockchains stored in one or more participating nodes of the blockchain-based trustedplatform 406.

In some embodiments, blockchain based trustedplatform 406 may receive encrypted ledger data fromservice system 404. In some examples, the encrypted ledger data may be encrypted using an asymmetric key encryption-based public key of the blockchain-based trustedplatform 406. The blockchain based trustedplatform 406 may decrypt the encrypted ledger data using a private key paired with the public key and obtain ledger data.

Atstep 422, trustedplatform 406 based on the blockchain generates a credential corresponding to the account data. In some embodiments, the credentials may include any suitable type of credentials for recording ledger data. In some examples, the credentials may include an identification of ledger data and/or a digital signature of blockchain-based trustedplatform 406 that is generated based on the ledger data using a private key of blockchain-based trustedplatform 406. In some embodiments, the credential may uniquely identify the account data.

Atstep 424, the blockchain based trustedplatform 406 may return the credential to theservice system 404. In some examples, the credentials may include a digital signature generated using a private key of the blockchain based trustedplatform 406 based on the ledger data such that theservice system 404 may verify the digital signature using a public key of the blockchain based trustedplatform 406.

Atstep 426,service system 404 sends the logging result to user 402 after receiving the credentials from trustedplatform 406 based on the blockchain. In some embodiments, the recorded result includes the credential. In some embodiments, the recording results include a notification to the user 402 indicating whether the data recording is complete. In some embodiments,service system 404 may verify the credential, for example, when the credential includes a digital signature of trustedplatform 406 based on the blockchain. In some examples,service system 404 may verify the digital signature using a public key of trustedplatform 406 based on the blockchain. If the digital signature is valid, theservice system 404 may send the credentials in the logging result to the user 402 and inform the user 402 in the logging result that the data logging is complete. If the digital signature is invalid,service system 404 may not send the credential to user 402, orservice system 404 may notify user 402 that the data record is not complete.

Fig. 5 depicts an example of a blockchaindata validation process 500 in a service system mode that may be performed in accordance with embodiments herein. For convenience,process 500 will be described as being performed by a system of one or more computers located at one or more locations and appropriately programmed according to the description herein. For example, a suitably programmed blockchain-based system, such assystem 300 of FIG. 3, may performprocess 500.

Process 500 begins atstep 510, whereuser 502 sends a request for authentication data toservice system 504.User 502 may beuser 302 as depicted in fig. 3. In some embodiments,user 502 may include, for example, any suitable computer, module, server, or computing element encoded to perform methods described herein. In some examples,user 502 may include a web browser and a software application for providing various functions of a client computing device. In some embodiments,service system 504 may be implemented as a service system in FIG. 3, such as service system 306-1.

In some embodiments, the request to validate data may include credentials corresponding to ledger data generated based on the data. In some embodiments, the credentials may be configured to uniquely identify the data and ledger data. In some examples, the credential and ledger data may be generated in a previous data record process similar to process 400 of fig. 4. In this example, ledger data may be generated byservice system 504 and recorded in a blockchain-based trustedplatform 506 in a previous data logging process. Ledger data may include hash values of data. In some embodiments, the hash value may be calculated by theservice system 504 according to a predetermined cryptographic hash function or algorithm (e.g., MD5 message digest algorithm, SHA-1 (secure hash algorithm 1) hash function, hulup hash function, etc.). Ledger data may include additional information, such as metadata for the data. The metadata may include one or more of an author, a creation date, a modification date, and a file size of the data.

In the above example, the credentials may be generated by the blockchain based trustedplatform 506 and sent to theuser 502 in a previous data record process. In some embodiments, the credentials may include an identification of ledger data. In some embodiments, the credentials may include a digital signature of blockchain-based trustedplatform 506 that is generated based on ledger data using a private key of blockchain-based trustedplatform 506.

Atstep 512, theservice system 504, after receiving the request to validate the data, obtains the data from a local store of theservice system 504. In some embodiments, the local storage ofservice system 504 may include storage media such as NVME, SSD, HDD, and SMR. In some embodiments,service system 502 may obtain the data based on credentials included in the request.

Atstep 514,service system 504 calculates a hash value based on the data obtained atstep 512. In some embodiments, the hash value may be calculated by theservice system 504 from the same cryptographic hash function or algorithm used to calculate the hash value in a previous data record process.

Atstep 516,service system 504 sends the computed hash value to blockchain-based trustedplatform 506. In some embodiments,service system 504 may send the credential with the computed hash value to blockchain-based trustedplatform 506. In some embodiments,service system 504 may encrypt the hash value and/or credential and send the encrypted information to blockchain-based trustedplatform 506. In some examples,service system 504 may encrypt the hash value and/or credentials using a public key of blockchain based trustedplatform 506, such that blockchain based trustedplatform 506 may decrypt the encrypted information using its private key.

Atstep 518, after receiving the hash value fromservice system 504, blockchain-based trustedplatform 506 compares the received hash value to hash values previously stored in blockchain-based trustedplatform 506. In some embodiments, blockchain-based trustedplatform 506 may receive encrypted hash values and/or credentials fromservice system 504. In some examples, the encrypted hash value and/or credential may be encrypted with a public key of the blockchain-based trustedplatform 506. The blockchain based trustedplatform 506 may decrypt the encrypted data using a private key paired with the public key and obtain a hash value and/or credentials.

In some embodiments, blockchain-based trustedplatform 506 may obtain ledger data from local storage of blockchain-based trustedplatform 506 in accordance with credentials received fromservice system 504 and obtain a hash value in the ledger data. In some embodiments, blockchain-based trustedplatform 506 may obtain ledger data from one or more participating blockchain nodes of blockchain-based trustedplatform 506 in accordance with the credentials and obtain a hash value in the ledger data.

Atstep 520, blockchain-based trustedplatform 506 sends the verification result toservice system 504. In some embodiments, the verification result includes a comparison of the received hash value instep 518 with the hash value in the hash data. In some embodiments, the verification result may also include a digital signature of trustedplatform 506 based on the blockchain. In some examples, a digital signature of blockchain-based trustedplatform 506 may be generated from at least one of the two hash values using a private key of blockchain-based trustedplatform 506.

At step 522, after receiving the verification result from blockchain-based trustedplatform 506,service system 504 sends a verification response touser 502. In some embodiments,service system 504 may verify the digital signature included in the verification result. In some examples,service system 504 may verify the digital signature using a public key of trustedplatform 506 based on the blockchain. In this example, if the digital signature is determined to be invalid,service system 504 may ignore the verification result. If the digital signature is determined to be valid, the service system may continue to process the verification result.

In some embodiments,service system 504 determines whether the two hash values match based on the verification result. If the two hash values match,service system 504 may determine that the data stored inservice system 504 has not been tampered with.Service system 504 may also include the data in a verification response and send a verification response touser 502 indicating that the data has not been tampered with. If the two hash values do not match,service system 504 may notifyuser 502 in a verification response that the data may have been tampered with.

Fig. 6 depicts an example of a blockchaindata recording process 600 under blockchain platform mode that can be performed in accordance with embodiments herein. For convenience,process 600 will be described as being performed by a system of one or more computers located at one or more locations and suitably programmed according to the present disclosure. For example, a suitably programmed blockchain-based system (e.g.,system 300 of fig. 3) may performprocess 600.

Process 600 begins atstep 610, whereuser 602 sends data for recording toservice system 604. In some embodiments,user 602 may send a request toservice system 604 for recording data, where the request includes the data. In some examples, the data may be included in a digital file or document, such as a legal document, a business contract, an image, a video, a web page, a spreadsheet, and so forth.

Theuser 602 may be theuser 302 as described in the description of fig. 3. In some embodiments,user 602 may include, for example, any suitable computer, module, server, or computing element encoded to perform the methods described herein. In some examples, theuser 602 may include a web browser and a software application for providing various functions of the client computing device. In some embodiments,service system 604 may be implemented as a service system (e.g., service system 306-1) as in FIG. 3.

Atstep 612, theservice system 404 triggers data logging after receiving data from theuser 602. In some embodiments, theservice system 604 may automatically trigger data recording in response to receiving data or a request from theuser 602. In some examples,service system 604 may include an intelligent contract for processing data or requests received fromusers 602. Once the smart contract receives data or a request from a user, the smart contract may automatically execute to perform the following data record processing.

In some embodiments, theservice system 604 may verify the identity of theuser 602 after receiving data from theuser 602. In some examples,user 602 may send the user identification to servingsystem 604 along with the data, such that servingsystem 604 may compare the received user identification to the user identifications of authorized users stored in servingsystem 604. If it is determined thatuser 602 is an unauthorized user,service system 604 may ignore the request fromuser 602 and discard the data. If it is determined thatuser 602 is an authorized user,service system 604 may continue to process the received data.

Atstep 614, theservice system 604 stores the data received from theuser 602 in a local store of theservice system 604. In some embodiments, theservice system 604 may include a local storage subsystem including a storage medium such as an NVME, SSD, HDD, or SMR. In some embodiments, the local storage subsystem of theservice system 604 may be generated or expanded for better availability, partition tolerance, flexibility, and cost. For example, the local storage subsystem of theservice system 604 may be scaled by adding more servers or storage nodes and thereby linearly increase capacity and performance. It can use standard servers, drives and networks that are inexpensive. In some embodiments, the local storage subsystem of thestorage system 604 may increase the utilization of standard servers, thus resulting in less power consumption, better cooling efficiency, better space utilization, less maintenance costs, and the like.

In some embodiments, theservice system 604 may include a multi-tier storage subsystem comprising a plurality of storage devices configured to store data based on data access frequency. In some examples,service system 604 may include a first storage device, such as a cloud disk or cloud-based storage device (e.g., SSD cloud disk, ESSD cloud disk), for storing the most frequently accessed data. Theservice system 604 may include a second storage device, such as a NAS device, for storing data with a lower frequency of access.

Atstep 616,service system 604 sends a request to record data to block chain based trustedplatform 606. In some embodiments, blockchain-based trustedplatform 606 may be implemented as blockchain-based trustedsystem 312 of fig. 3. In some embodiments, the request includes data received fromuser 602.

In some embodiments, theservice system 604 may send data to the blockchain-based trustedsystem 606 via a communication interface, such as theblockchain access layer 314 of fig. 3.

In some embodiments, theservice system 604 may encrypt the data and send the encrypted data in the request to the blockchain-based trustedplatform 606. In some embodiments, theservice system 604 may encrypt the data according to a predetermined encryption function or algorithm. In some examples, theservice system 604 may encrypt the data using a public key of the blockchain-based trustedplatform 606 so that the blockchain-based trustedplatform 606 may decrypt the encrypted data using its private key.

Atstep 618, the blockchain-based trustedplatform 606 calculates a hash value based on the data received from theservice system 604. In some embodiments, the blockchain based trustedplatform 606 may receive encrypted data from theservice system 604. In some examples, the encrypted data may be encrypted with a public key of the blockchain-based trustedplatform 606. The blockchain-based trustedplatform 606 may decrypt the encrypted data using a private key paired with the public key and obtain the data.

In some embodiments, the hash value may be calculated according to a predetermined cryptographic hash function or algorithm (e.g., MD5 message digest algorithm, SHA-1 (secure hash algorithm 1) hash function, hubbe hash function, etc.). In some examples, the blockchain-based trustedsystem 606 may apply a predetermined hash function to data received from theservice system 604 and generate a hash value for the data.

Atstep 620, blockchain-based trustedsystem 606 stores the hash value generated atstep 618. In some embodiments, blockchain-based trustedsystem 606 may generate and store ledger data based on the hash value. In some embodiments, ledger data may include hash values and/or additional data, such as metadata for data received fromuser 602 or metadata for hash values. In some examples, the metadata may include one or more of an author, a creation date, a modification date, and a file size of the data.

In some embodiments, blockchain-based trustedplatform 606 may store ledger data in one or more participating nodes of blockchain-based trustedplatform 606. In some embodiments, consensus nodes of blockchain-based trusted platform 606 (e.g., blockchain nodes 308-1, 308-2 and/or third party blockchain nodes 310-1 and 310-2 of fig. 3) may perform consensus processing on the account data. Upon agreement between the consensus nodes, blockchain-based trustedplatform 606 may record ledger data in blockchains stored in one or more participating nodes of blockchain-based trustedplatform 606.

Atstep 622, trustedplatform 606 based on the blockchain generates credentials corresponding to the ledger data. In some embodiments, the credentials may include any suitable type of credentials for recording ledger data. In some examples, the credentials may include an identification of ledger data. In some examples, the credentials may include a digital signature of the blockchain-based trustedplatform 606 that was generated based on the ledger data using a private key of the blockchain-based trustedplatform 606. In some embodiments, the credentials may be configured to uniquely identify the data and ledger data.

Atstep 624, the blockchain-based trustedplatform 606 returns the credential to theservice system 604. In some examples, the credentials may include a digital signature generated based on the ledger data using a private key of the blockchain-based trustedplatform 606, such that theservice system 604 may verify the digital signature using a public key of the blockchain-based trustedplatform 606.

Atstep 626, after receiving credentials from the blockchain based trustedplatform 606, theservice system 604 sends the recorded results to theuser 602. In some embodiments, the recorded result comprises a credential. In some embodiments, the recording results include a notification to theuser 602 indicating whether the data recording is complete. In some embodiments,service system 604 may verify the credential, for example, when the credential includes a digital signature of trustedplatform 406 based on the blockchain. In some examples,service system 604 may use a public key of trustedplatform 606 based on the blockchain to verify the digital signature included in the credential. If the digital signature is valid, theservice system 604 may send the credentials in the logging result to theuser 602 and notify theuser 602 in the logging result that the data logging is complete. If the digital signature is invalid, theservice system 604 may not send the credential to theuser 602 and notify theuser 602 that the data record is not complete.

Fig. 7 depicts an example of a blockchaindata validation process 700 in blockchain platform mode that can be performed in accordance with embodiments herein. For convenience,process 700 will be described as being performed by a system of one or more computers located at one or more locations and suitably programmed according to the present disclosure. For example, a suitably programmed blockchain-based system (e.g.,system 300 of fig. 3) may performprocess 700.

Process 700 begins atstep 710, whereuser 702 sends a request for authentication data toservice system 704.User 702 may beuser 302 as depicted in FIG. 3. In some embodiments,user 702 may include, for example, any suitable computer, module, server, or computing element encoded to perform methods described herein. In some examples,user 702 may include a web browser and a software application for providing various functionality of a client computing device. In some embodiments,service system 704 may be service system (e.g., service system 306-1) 300 as described in FIG. 3, such as service system 306-1.

In some embodiments, the request to validate data may include credentials for ledger data. In some embodiments, the credentials may be configured to uniquely identify the raw data and ledger data. In some examples, the credential and ledger data may be generated in a previous data logging process similar to process 600 of fig. 6. In this example, ledger data may be generated by theservice system 704 and recorded in the blockchain-based trustedplatform 706 in a previous data logging process. Ledger data may include hash values of the raw data. In some embodiments, the hash value may be calculated by theservice system 704 according to a predetermined cryptographic hash function or algorithm (e.g., MD5 message digest algorithm, SHA-1 (secure hash algorithm 1) hash function, hulup hash function, etc.). Ledger data may include additional information, such as metadata for the data and/or metadata for the hash value. The metadata may include one or more of an author, a creation date, a modification date, and a file size of the data.

In the above example, the credentials may be generated by the blockchain based trustedplatform 706 and sent to theuser 702 in a previous data record process. In some embodiments, the credentials may include an identification of ledger data. In some embodiments, the credentials may include a digital signature of the blockchain based trustedplatform 706 that is generated based on the ledger data using a private key of the blockchain based trustedplatform 706.

Atstep 712, theservice system 704 obtains data from local storage of theservice system 704 after receiving the request from theuser 702. In some embodiments, the local storage of theservice system 704 may include storage media such as NVME, SSD, HDD, or SMR. In some embodiments,service system 702 may obtain the data based on credentials included in the request.

Atstep 714,service system 704 sends the data obtained atstep 712 to blockchain-based trustedplatform 706. In some embodiments, theservice system 704 may send the credentials and the obtained data to the blockchain based trustedplatform 706. In some embodiments, theservice system 704 may encrypt the obtained data and/or credentials and send the encrypted information to the blockchain based trustedplatform 706. In some examples, theservice system 704 may encrypt the obtained data and/or credentials using a public key of the blockchain based trustedplatform 706 so that the blockchain based trustedplatform 706 may decrypt the encrypted information using its private key.

Atstep 716, blockchain-based trustedplatform 706 computes a hash value based on the data received fromservice system 704. In some embodiments, the hash value may be computed by the blockchain based trustedplatform 706 from the same cryptographic hash function or algorithm used to compute the hash value in the previous data record processing.

In some embodiments, the blockchain based trustedplatform 706 may receive encrypted data and/or credentials from theservice system 704. In some examples, the encrypted data and/or credentials may be generated using a public key of the blockchain-based trustedplatform 706. The blockchain based trustedplatform 706 may decrypt the encrypted data using a private key paired with a public key and obtain data and/or credentials.

Atstep 718, the blockchain based trustedplatform 706 compares the computed hash value to hash values previously stored in the blockchain based trustedplatform 706. In some embodiments, blockchain based trustedplatform 706 may obtain ledger data from local storage of blockchain based trustedplatform 706 in accordance with credentials received fromservice system 704 and obtain a hash value in the ledger data. In some embodiments, blockchain-based trustedplatform 706 may obtain ledger data from one or more participating blockchain nodes of blockchain-based trustedplatform 706 based on credentials and obtain a hash value in the ledger data. The obtained hash value may then be compared to the calculated hash value. In some embodiments, blockchain based trustedplatform 706 generates a verification result based on a comparison of the two hash values.

Atstep 720, the blockchain based trustedplatform 706 sends the verification result to theservice system 704. In some embodiments, the verification result includes the comparison of the two hash values as instep 718. In some embodiments, the verification result may also include a digital signature of trustedplatform 706 based on the blockchain. In some examples, the digital signature of the blockchain based trustedplatform 706 may be generated based on at least one of the two hash values using a private key of the blockchain based trustedplatform 706.

After receiving the verification result from blockchain based trustedplatform 706,service system 704 sends a verification response touser 702 atstep 722. In some embodiments, theservice system 704 may verify the digital signature included in the verification result. In some examples,service system 704 may verify the digital signature using a public key of trustedplatform 706 based on the blockchain. If the digital signature is determined to be invalid, theservice system 704 may ignore the verification result. If the digital signature is determined to be valid, theservice system 704 may continue to process the verification result.

In some embodiments, theservice system 704 determines whether the two hash values match based on the verification result. If the two hash values match, thenservice system 704 may determine that the data stored inservice system 704 has not been tampered with.Service system 704 may also include the data in a verification response and send a verification response touser 702 indicating that the data has not been tampered with. If the two hash values do not match,service system 704 may notifyuser 702 in a verification response that the data has been tampered with.

Fig. 8 is a schematic diagram illustrating an example of a blockchain based trustedplatform 800 according to embodiments herein. In some embodiments, blockchain based trustedplatform 800 may be implemented as blockchain based trustedplatform 312 of fig. 3. A blockchain based trustedplatform 800 as described herein may be implemented to enhance trust between users and provide various services or processing tools to allow users to perform online transactions in an efficient manner. In the example shown, trustedplatform 800 includes a trusted application layer 814 and a trusted services layer 816. The trusted application layer 814 includes a plurality of applications including a first application 802, asecond application 804, through annth application 806 that utilize the functionality of atrusted time module 808, a trustedidentity module 810, and a trustedcomputing module 812 in a trusted services layer 816. In some embodiments, theapplications 802, 804, 806, as well as thetrusted time module 808, the trustedidentity module 810, and the trustedcomputing module 812 may be implemented in each participating blockchain node of the blockchain based trusted platform.

The blockchain based trustedplatform 800 solves the above problems by providing a suite of service applications that utilize the functionality of the trustedtime module 808, the trustedidentity module 810, and the trustedcomputing module 812 to authenticate documents and/or user identities in a manner that conforms to (or is more conforming than previous systems to) relevant evidence rules.

In some embodiments, the blockchain based trustedplatform 800 is characterized by: the platform provides trusted time, trusted identity, and trusted computing to enable applications that provide services to maintain a verification record of information (e.g., who, when) about events that the service occurred at each of multiple steps or significant points in time in a manner that is consistent (or more consistent than previous systems) with evidence rules. These records may be added to the blockchain by consensus of the blockchain link points associated with law, law enforcement, or dispute resolution agencies. These records, once added, become immutable and can be trusted by the court or parties as evidence of the corresponding legal service or procedure.

For example, there are tools that provide hashing and digital signature functionality to allow a user to digitally sign data so that other users can verify that the data has not been altered since being endorsed by the digital signature and can verify the identity of the user that signed the data. However, there is still a possibility that the digitally signed data contains errors, e.g. before signing the data, the data has been damaged or tampered without the signer knowing, or the original digitally signed data is intercepted by a hacker during transmission and replaced by forged digitally signed data. Based solely on digitally signed data, it may be difficult to prove or deny the authenticity and accuracy of the data. Thus, it may be difficult to use digitally signed data in legal proceedings without further proof, such as an affidavit from a notary or licensed attorney proving the authenticity and accuracy of the data. The technical problem to be solved is how to improve the credibility of data generated by an online application providing legal services.

The blockchain based trustedplatform 800 enhances the trustworthiness of data generated by applications that provide services over a network and reduces the likelihood of counterfeiting or tampering by capturing a snapshot of each of a plurality of steps (or several significant points in time) in the process of providing services. Each snapshot may include information provided by the trustedtime module 808 and/or the trustedidentity module 810.Trusted platform 800 uses trustedcomputing module 812 to store snapshots in blockchains to process blockchain data. The snapshot may include information such as, for example, who, when, and what is associated with the event that occurred at the respective step or point in time. The probability of forgery or falsification at each of the plurality of steps (or points in time) is smaller than the probability of forgery or falsification at a single step (or point in time).Trusted time module 808 provides a trusted or verified timestamp, trustedidentity module 810 provides trusted or verified identity information, and trustedcomputing module 812 ensures the trustworthiness of the data recorded in the relevant blockchain.

In some embodiments, the functionality of themodules 808, 810, 812 may be invoked by one or more blockchain based applications or smart contracts executing in the TEE. The TEE is carried by the one or more data processors in isolation from operating systems of the one or more data processors and is configured to provide enhanced confidentiality and integrity for code and loaded data executing within the one or more data processors. In some examples, an application or smart contract may invoke the functionality of a module through an API.

The trustedplatform 800 based on block chains produces the following technical effects: service-related data provided by service applications supported by blockchain-based trustedplatform 800 has a higher degree of trust (as compared to previous systems). A highly reliable record of the history of transactions that occurred during the provision of the service, including the history of modifications to the document and responses from the parties, may be maintained.

In some embodiments, the trusted services layer 816 may include additional modules, such as a trusted location module, that provides an authenticated location that indicates where the transaction occurred. For example, the trusted location module may be used to prove that infringement occurs in a geographic region and may litigation a court with jurisdiction. For example, the trusted location module may generate verified location information based on data provided by a verified Global Positioning System (GPS) receiver connected to the client terminal.

Fig. 9 is a diagram illustrating an example of asystem 900 for online transactions according to embodiments herein. In the example shown,system 900 includes a block chain based trustedplatform 902. In some embodiments, the blockchain based trusted platform may be implemented as blockchain based trustedplatform 312 of fig. 3 or blockchain based trustedplatform 800 of fig. 8.

In some embodiments, trustedplatform 902 may be accessed over anetwork 914, such as the Internet.User 924 accesses trustedplatform 902 using aclient terminal 922, whichclient terminal 922 may be, for example, a mobile phone, a personal computer, or any computing device that may connect tonetwork 914. In some examples, trustedplatform 902 provides limited functionality to users that are not already registered withplatform 902.

When registered withplatform 902, the user has a user Identification (ID) that is used to identifyuser 924 whenuser 924 uses the tools and services ofplatform 902. Each registered user has an account associated withplatform 902 and may access the functionality ofplatform 902 after logging into the account. In some examples,user 924 may register withplatform 902 by providing personal information such as the user's phone number and email address. In some examples,user 924 may register withplatform 902 by providing biometric information, such as one or more fingerprints, one or more voiceprints, or iris information, through a fingerprint sensor, microphone, or iris scanner communicatively coupled withmodules 906, 908, 910. Whenuser 924 accesses functionality of trustedplatform 902, the user may provide additional information to trustedplatform 902, and trustedplatform 902 associates the additional information with a user account.

For example,user 924 may provide a mobile phone number so thatuser 924 may receive a message from trustedplatform 902 on a mobile phone.User 924 may provide payment account information so thatuser 924 may pay for services on trustedplatform 902. For example, the user account may include one or more of the following information that may be used to verify the identity of the user 924: (ii) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online banking account, (ix) a user ID associated with a taxi-calling service, (x) a user ID associated with an online ordering service, (xi) a social security assurance code; (xii) A driver license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, (xv) an ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information.

In the example of fig. 9, auser 924 accesses an internet evidencecollection web browser 904 to search for and view web pages on theinternet 914. A client component (not shown) of the web browser executes at theclient terminal 922 and provides a user interface for displaying web pages to theuser 924 and receiving user instructions for processing the web pages (e.g., clicks for controlling navigation between the web pages).

In some examples,user 924 usesweb browser 904 to access web page 918 (including, for example, web pages 918-1 and 918-2) hosted by the publisher onweb server 916.User 924 may initially provide the URL of the publisher's home page and then click on a web link to view the web page hosted onweb server 908. In some embodiments, when auser 924 browses a web page using an internet evidencecollection web browser 904, theweb browser 904 invokes the trustedidentity module 908 to verify the identity of theuser 924. For example, the trustedidentity module 908 may use any amount of information associated with a user account to verify the identity of theuser 924.

In the above example, whenever a predetermined type of event associated with the use ofweb browser 904 byuser 924 occurs,web browser 904 invokes trustedtime module 906 to obtain a verified timestamp of when the event occurred. The predetermined types of events may include, for example, receiving input from auser 924, providing output to theuser 924, and performing a predetermined type of action or calculation. Receiving input fromuser 924 may include, for example, receiving a URL for a web page, receiving a click command or selection command fromuser 924, receiving an edit command such as a copy command fromuser 924, or receiving a file command such as a save command fromuser 924. Providing output to theuser 924 can include, for example, displaying content of a web page to theuser 924, playing an audio file to theuser 924, or playing a video file to theuser 924.

Thus, whenever an event occurs in which theuser 924 performs a predetermined type of action, such as providing a URL to theweb browser 904, clicking a web link on the web page 918, copying text or images from the web page 918, or downloading content from the web page 918, theweb browser 904 performs the action requested by theuser 924, and also invokes the trustedtime module 906 to obtain a verified timestamp indicating the time at which the action was performed or the time at which the event occurred. Theweb browser 904 calls the trustedcomputing module 910 to generate a snapshot of the event, where the snapshot may be in the format of a record, including: the identity of theuser 924, a description of the event (e.g., a description of the action performed), a verified timestamp indicating when the event occurred (e.g., when the action was performed), and information about the web page associated with the action (e.g., a URL). The trustedcomputing module 910 generates a hash value for the record and adds the chunk that includes the record and the hash value to ablockchain 912, theblockchain 912 storing the record associated with theuser 924.

Upon each event occurrence,web browser 904 invokes trustedtime module 906 to obtain a verified timestamp indicating the time at which the event occurred.Web browser 904 calls trustedcomputing module 910 to updateblockchain 912 to add a record with information about the event.

The trustedplatform 902 is associated with one of the nodes of the blockchain network 930 (e.g., node 928) where theblockchain 912 is replicated across theblockchain network 930. For example, one of the nodes may be associated with acomputer server 926 that maintains a version ofblockchain 912.

Fig. 10 is a diagram illustrating an example of a system for providing trusted time according to embodiments herein. In some embodiments, thetrusted time module 1010 generates the validated timestamp based on time information assigned by a national standard institute coordinated Universal Time (UTC) 1020 or generated by a Global Positioning System (GPS)receiver 1030, wherein the Global Positioning System (GPS)receiver 1030 obtains the time information from a positioning system such as a beidou navigation satellite system maintained in china, a global positioning system maintained in the united states, a galileo global navigation satellite system maintained in the european union, a global orbiting navigation satellite system maintained in russia (GLONASS), and/or a quasi-zenith satellite system maintained in japan.

Fig. 11 is a diagram illustrating an example of a system for providing a trusted identity according to embodiments herein. In some embodiments, the trustedidentity module 1100 maintains auser account database 1102, theuser account database 1102 including information about registered users provided by the registered users themselves. The trustedidentity module 1100 also accesses other databases to verify the account information provided by the user. For example, the trustedidentity module 1100 may access thegovernment ID database 1104 to verify the accuracy of the government ID provided by the user. If the trustedidentity module 1100 determines that the government ID provided by the user matches the name or telephone number of another user listed in thegovernment ID database 1104, the trustedidentity module 1100 may generate an alert message indicating a possible fraudulent identity. In some embodiments, the trustedidentity module 1100 may have access to adatabase 1106 of accounts of users accessing online banking services (e.g., pay-for-use) that allows users to digitally pay for services provided on a trusted platform. The trustedidentity module 1100 may access adatabase 1108 related to accounts of users using the online payment service. The trustedidentity module 1100 may access adatabase 1110 relating to accounts of users using social media services provided on a trusted platform. The trustedidentity module 1100 may access adatabase 1112 related to accounts of users using communication services provided on the trusted platform.

The trustedidentity module 1100 may access adatabase 1118 associated with accounts of users of an online shopping service that allows users to shop for products online. The trustedidentity module 1100 may access adatabase 1116 related to the account of a user using an online entertainment service that allows the user to listen to music or watch movies by downloading or streaming the music or movies. The trustedidentity module 1100 may access abiometric database 1114, thedatabase 1114 storing biometric information, such as one or more fingerprints, one or more voiceprints, or iris information, provided by a user during enrollment.

In some embodiments, the trustedidentity module 1100 may attempt to verify the identity of the user using multiple databases, thereby increasing the trustworthiness of the verified identity information provided by the trustedidentity module 1100.

In some embodiments, thevarious databases 1104, 1106, 1108, 1110, 1112, 1114, 1116, and 1118 may be maintained independently of each other. For example, a user may modify information in an online banking account without modifying information in an online shopping account. The user may update the information in different accounts at different time periods. The same user may use different usernames or aliases for different services. Multiple users may share the same account, e.g., family members may share the same movie streaming account. The same user may open multiple accounts for a service, for example, a user may have multiple mobile phone numbers, multiple email addresses, and/or multiple messaging IDs. Thus, based on the information of a single database, it may not be sufficient to accurately verify the identity of the user. However, by combining information from multiple databases, the identity of the user may be more reliably verified.

Fig. 12 is a diagram illustrating an example of asystem 1200 for trusted execution according to embodiments herein. In some embodiments, nodes of and/or in communication with the blockchain network may operate using a Trusted Execution Environment (TEE) or a Rich Execution Environments (REE). Generally, a trusted execution environment is a secure, integrity protected processing environment that includes processing, memory, and storage functions. In some embodiments, the trusted execution environment may be isolated from the "normal" processing environment (e.g., REE) under which the device operating system and applications run. The trusted execution environment may make it possible to build REE applications and services with better security and availability by partitioning the REE applications and services such that sensitive operations are limited to only the trusted execution environment and sensitive data (e.g., encryption keys).

In the example shown, blocklink points 1210 and 1230 operate using both TEE and REE. As shown,virtual machines 1214 and 1234 operate using TEE, as docaches 1216 and 1236.Services 1212 and 1232 (e.g., transaction, query, distribution, and web services) run in the REE. Unlike caches that run in TEEs,storage 1218 and 1238 run in REEs.

A TEE is a trusted environment within hardware (one or more processors, memory) that is isolated from the hardware's operating environment (e.g., operating System (OS), basic input/output system (BIOS)). In more detail, the TEE is a separate, secure area of the processor that ensures privacy and integrity of code execution and data loaded in the main processor. Within the processor, the trusted execution environment runs in parallel with the operating system. At least part of a so-called Trusted Application (TA) executes within a trusted execution environment and has access to a processor and memory. With the trusted execution environment, the trusted application is protected from other application programs running in the host operating system. Further, the trusted execution environment cryptographically isolates trusted applications from each other within the trusted execution environment.

Examples of trusted execution environments include the software protection extensions (SGX) provided by Intel corporation of Santa Clara, calif. Although SGX is discussed herein by way of example, it is contemplated that embodiments herein may be implemented using any suitable trusted execution environment. SGX provides a hardware-based trusted execution environment. In SGX, trusted hardware is the core of a Central Processing Unit (CPU), and a portion of physical memory is isolated to protect selected code and data. The isolated portion of memory is called an enclave (enclave). More specifically, the enclave is provided as an Enclave Page Cache (EPC) in memory and mapped to the application address space. The memory (e.g., DRAM) includes a reserved random access memory (PRM) for SGX. Random access memory is the lowest BIOS level of contiguous memory space and is not accessible by any software. Each enclave page cache is a memory set (e.g., 4 KB) allocated by the operating system to load application data and code in random access memory. Enclave Page Cache Metadata (EPCM) is the entry address of the corresponding enclave page cache and ensures that each enclave page cache can only be shared by one enclave. That is, a single enclave may use multiple enclave page caches, while an enclave page cache is dedicated to a single enclave.

The blockchain and TEE techniques described above can be used to generate highly reliable records related to online transactions. Online transactions typically involve multiple steps. Instead of generating a verified record of the final outcome of the transaction (e.g., generating a hash value of data generated at the end of the transaction), the novel system described herein uses data generated during multiple events occurring in multiple steps of the transaction to generate a record that can be used to verify the transaction. A validated record of data derived from events associated with multiple steps of a transaction is much more reliable than a validated record based only on the end result of the transaction. In some embodiments, for each piece of data that needs to be verified, not only is each piece of data itself verified, but the process that generated each piece of data is also verified. The process of generating the piece of data may involve multiple steps, and each step of the process is validated. This ensures that the final data is highly reliable, since the probability that each step of the process is fraudulently modified is very low. In some embodiments, a tool for collecting evidence in the form of digital data is provided. For each piece of evidence that needs to be verified, not only the evidence itself is verified, but also the process that collects or generates each piece of evidence. The process of collecting or generating evidence may involve multiple steps, and each step of the process is validated. This ensures that the evidence collected or generated at the end of the process is highly reliable, since the probability of someone fraudulently modifying the data at each step of the process is very low.

Fig. 13 is a diagram illustrating an example of anarchitecture 1300 for blockchain security according to embodiments herein.Architecture 1300 may be implemented to provide security functionality to a blockchain based trusted system, such as blockchain based trustedplatform 312 of figure 3 or blockchain based trustedplatform 800 of figure 8. In the example shown, thesecurity architecture 1300 includes the following components: anapplication security component 1310, adata security component 1320, a protocol andalgorithm security component 1330, and asecurity management component 1340.

In some embodiments,application security component 1310 may include functionality such asidentity management functionality 1312,access control functionality 1314, and intelligentcontract auditing functionality 1316. In some embodiments, theidentity management function 1312 may include a credential-based authentication mechanism for user authentication. In some examples, credential-based authentication mechanisms may include authentication between a serving system and a block node and authentication between different block nodes using TLS (transport layer security). In this example, after authentication is successful, the service may be allowed to be transmitted on a reliable channel. Communications between the serving system and the block-level nodes and between the block-level nodes may be encrypted by TLS to mitigate malicious network attacks. In some embodiments, a blockchain based trusted system may support TLS protocol and HTTPS (hypertext transfer protocol secure) protocol, where both protocols may support credential-based mutual authentication. In some embodiments, HTTPS may be configured to support one-way authentication according to user requirements. In some embodiments, a handshake procedure may be implemented between block link points. Reliable communication between blockchain nodes can be achieved by requiring one blockchain node to verify the private key signature of another blockchain node in the handshake procedure. In some embodiments, theaccess control function 1314 may be configured to support access control to a user account. In some examples, theaccess control function 1314 may support different account access rights with different levels/priorities.Access control function 1314 may support different account permissions for different classes.Access control function 1314 may support mutual authorization of different accounts and modification of account permissions. Smartcontract audit function 1316 may provide security for smart contracts in terms of processing and implementation and manage the entire life cycle of the smart contract, including collaboration, auditing, initialization, upgrades, revocation, etc., to reduce security risks caused by code and service vulnerabilities.

Thedata security component 1320 includes astorage security function 1322 and atransport security function 1324. In some examples, thestorage security function 1322 may provide support for multi-node data storage such that data loss in a single blockchain node does not affect the entire blockchain network. Thestorage security function 1322 may provide a data synchronization mechanism between block link points to ensure proper replication of data and provide a data archiving tool for data archiving and backup. Thetransport security function 1324 may support private key-based transaction signatures to prevent tampering with transaction content. Thetransport security function 1324 may support a hashing mechanism that improves the data security of transactions recorded in the blockchain. Thetransmission security function 1324 may support non-visibility of confidential information through private transactions based on zero knowledge proofs to ensure that the confidential information is not available to third parties.

Protocol andalgorithm security component 1330 includes intelligentcontract security function 1332, cryptographicalgorithm security function 1334, andkey security function 1336. In some embodiments, smartcontract security function 1332 may provide support for code security, run mechanism security, service logic security, and user security. In some examples, the intelligentcontract security functions 1332 may support the use of virtual machines to load and execute intelligent contracts. In this example, a separate virtual machine may be created for each blockchain transaction. When the blockchain transaction is complete, the virtual machine used for the blockchain transaction may be destroyed. The virtual machine may be configured to detect inappropriate intelligent contract content and to interrupt execution of an intelligent contract having inappropriate content. In some embodiments, cryptographicalgorithm security function 1334 may provide practical security for encryption, signature, and hash algorithms and functions. In some examples, cryptographicalgorithm security function 1334 may support multiple sets of cryptographic suites as required by different service scenarios. Table 1 below shows an example of an illustration of a cipher suite according to embodiments herein.

TABLE 1 description of cipher suite

Key security function 1336 may provide security for keys, such as public and private keys, by maintaining a key management system. In some examples,key security function 1336 may support lifecycle management of keys and credentials, including generation, import, preservation, export, distribution, exchange, use, and update of keys and credentials.Key security function 1336 may support the secure storage of a private key used to generate a digital signature.Key security function 1336 may provide user information protection and user account locking in the event of a key loss.Key security function 1336 may also support private key loss reporting and signature protection mechanisms.

Thesecurity management component 1340 includes security audit functions 1342, supervisory support functions 1344, and configuration management functions 1346. In some examples, thesecurity audit function 1342 may support application log-based security audits. In this example, security audits may be performed on definable log command rules, print formats, alert levels, and time savings. The security audit may also include discovering, analyzing, and tracking exception events based on access time, IP address, behavior, and other information recorded in the log. In some embodiments,supervisory support function 1344 may support administrator permissions that allow users to access the blockchain network to obtain ledger data. In some embodiments, theconfiguration management function 1346 may support configuration and establishing a founder block to establish initial trust by configuring the trusted root and core parameters of the blockchain network.

Fig. 14 is a diagram illustrating an example of across-chain communication system 1400 according to embodiments herein. In some embodiments, across-chain system 1400 may be implemented to facilitate communication between different blockchain networks. For example, a judicial blockchain network may need to communicate with a public blockchain network to provide services to clients accessing the public blockchain network. A judicial blockchain network and a public blockchain network may be implemented in thecross-chain system 1400 to ensure data security during data transmission and storage in and between the two blockchain networks. In the example shown, thecross-chain system 1400 includes afirst blockchain network 1410 and asecond blockchain network 1430. In some embodiments, each blockchain network may include cross-chain communication components or nodes to facilitate communication between a blockchain link point of a blockchain network and a blockchain link point of another blockchain network. In the example above, the first blockchain network includes a firstblockchain link point 1412 and a firstcross-chain communication component 1418, and the second blockchain network includes a secondblockchain link point 1432 and a secondcross-chain communication component 1438. Note thatblock link points 1412 and 1432 are shown to each include one block chain node and one cross-chain communication component for illustrative purposes only.Blockchain nodes 1412 and 1432 may have any suitable number of blockchain nodes and cross-chain communication components.

In some embodiments, a cross-chain communication component may be configured as a communication interface that facilitates communication with the cross-chain communication component between a blockchain link in the same blockchain network and another cross-chain communication component in another blockchain network. In the example shown,cross-chain communication component 1418 is configured to allow communication betweenblock link point 1412 andcross-chain communication component 1438, andcross-chain communication component 1438 is configured to allow communication betweenblock link point 1432 andcross-chain communication component 1418. In this way, data communication can be achieved between twoblockchain nodes 1412 and 1432 indifferent blockchain networks 1410 and 1430 usingcross-chain communication components 1418 and 1438. In some embodiments, the cross-chain communication component may be configured to support data validation and data attestation on a local blockchain network. The cross-chain communication component can also be configured to support unified data format conversion, cross-chain communication network protocols, and routing of cross-chain messages.

In the example shown, each block link point includes a server side intelligent contract and a cross-chain intelligent contract. As shown, blocklink points 1412 include service intelligence contracts 1414 and cross-chain intelligence contracts 1416, whileblock link points 1432 include service intelligence contracts 1434 and cross-chain intelligence contracts 1436. In some embodiments, the service intelligence contract may be configured to allow a user to access blockchain nodes and submit blockchain transactions, such as transactions for logging data to a blockchain, transactions for transferring data to another blockchain network, and so forth. The cross-chain contract may be configured to implement a cross-chain protocol to facilitate communication between the block link node and the cross-chain communication component. In some examples, a cross-chain intelligent contract may be configured to support defining a cross-chain message format and a cross-chain message communication protocol. In some embodiments, a cross-chain intelligent contract may also be configured to validate cross-chain proofs and parse formatted data.

In the illustrated example, each cross-chain communication component includes a cross-chain relay component and a oracle machine. As shown,cross-chain communication component 1418 includescross-chain relay component 1420 andpropheter 1422, whilecross-chain communication component 1438 includescross-chain relay component 1440 andpropheter 1442. In some embodiments, the cross-chain relay component may be configured to extract ledger data and ledger proofs from messages received from cross-chain smart contracts. In the example shown,cross-chain relay component 1420 may receive a message from cross-chain smart contract 1416 and extract ledger data and ledger proofs from the message. In some embodiments, a cross-chain relay component may be configured to communicate with another cross-chain relay component in a different blockchain network. Continuing with the above example,cross-chain relay component 1420 may process the message from cross-chain smart contract 1416, extract ledger data from the message, generate a cross-chain message based on the ledger data, and send the cross-chain message tocross-chain relay component 1440. In some embodiments, the predictive engines (e.g.,predictive engines 1422 and 1442) may be configured to perform signature verification and perform unified data formatting on data received from the cross-chain relay component. In some embodiments, the prediction machine may include any suitable hardware and/or software to perform the methods described herein. Cross-chain communication using a cross-chain relay component and a propheter is discussed in more detail below with reference to FIG. 15.

FIG. 15 depicts an example of across-chain communication process 1500 that may be performed according to embodiments herein. For convenience,process 1500 will be described as being performed by a system of one or more computers located at one or more locations and suitably programmed according to the present disclosure. For example, a suitably programmed blockchain-based system, such assystem 1400 of FIG. 14, can performprocess 1500. In some embodiments, theblockchain networks 1510 and 1520 may be implemented asblockchain networks 1410 and 1430, respectively, of fig. 14. In the example shown,blockchain network 1510 includes blockchain dots 1502 and cross-chain communication components 1504, andblockchain network 1520 includes blockchain dots 1508 and cross-chain communication components 1506. As shown,service intelligence contracts 1512 andcross-chain intelligence contracts 1514 execute on block link points 1502 ofblock chain network 1510, whileservice intelligence contracts 1528 andcross-chain intelligence contracts 1526 execute on block link points 1508 ofblock chain network 1520.Cross-chain relay component 1516 andprolog engine 1518 are implemented in cross-chain communication component 1504, whilecross-chain relay component 1524 andprolog engine 1522 are implemented in cross-chain communication component 1506.

Process 1500 begins atstep 1530 whereservice intelligence contract 1512 sends a message including ledger data tocross-chain intelligence contract 1514. In some examples, ledger data may include legal documents, business contracts, and the like. In some embodiments, the format of ledger data may include images, videos, web pages, spreadsheets, and the like. In some embodiments, ledger data may include plaintext data and/or hash values of plaintext data.

Atstep 1532, the cross-chainsmart contract 1514 sends the message including ledger data to thecross-chain relay component 1516 after receiving the message. In some embodiments, cross-chainsmart contracts 1514 may send ledger proofs for ledger data in messages. In some embodiments, ledger certification includes a digital signature generated according to a predetermined encryption or cryptographic algorithm based on ledger data. In some examples, a digital signature may be generated based on ledger data using a private key of the block chain link point 1502 executing thecross-chain intelligence contract 1514.

Atstep 1534, thecross-link relay component 1516 sends the ledger data to theoracle 1518. In some embodiments,cross-link relay component 1516 obtains ledger data from messages received from cross-linksmart contracts 1514. In some embodiments, thecross-chain relay component 1516 also obtains ledger proofs from the message. In some embodiments,cross-link relay component 1516 may send ledger data and ledger certification to apresident machine 1518.

Atstep 1536,statement interpreter 1518 validates the ledger data and determines whether the ledger data is valid. In some embodiments,book prediction machine 1518 may validate ledger data based on ledger certification. In some examples, theoracle 1518 may verify a digital signature included in the ledger proof. If the digital signature is valid, thepredictive teller 1518 may determine that the ledger data is valid and continue processing the ledger data. If the digital signature is invalid, thebook machine 1518 may discard the account data.

Atstep 1538,predictive engine 1518 generates formatted ledger data based on the ledger data. In some embodiments, the predictive engine may format ledger data according to a unified data format, in accordance with a cross-chain communication protocol. In some embodiments,language book machine 1518 may generate formatted ledger data based on ledger data and ledger certification.

Instep 1540, thepredictive engine 1518 returns formatted ledger data to thecross-link relay component 1516. In some embodiments, thepredictive engine 1518 may generate a hash value of the formatted ledger data and send the hash value to thecross-chain relay component 1516.

Atstep 1542, thecross-chain relay component 1516, upon receiving the formatted ledger data from thetalker 1518, sends a cross-chain message to thecross-chain relay component 1524. In some embodiments,cross-chain relay component 1516 may generate cross-chain messages based on the formatted ledger data. In some embodiments, the cross-chain message may include formatted ledger data and a hash value of the formatted ledger data.

Atstep 1544,cross-chain relay component 1524 sends the formatted ledger data to cross-chainsmart contract 1526 after receiving the cross-chain message. In some embodiments,cross-link relay component 1524 obtains formatted ledger data from cross-link messages received fromcross-link relay component 1516. In some embodiments,cross-chain relay component 1524 may obtain a hash value of the formatted ledger data from the cross-chain message. In some embodiments,cross-chain relay component 1524 may send the hash value to cross-chainintelligent contract 1526 along with the formatted ledger data.

At 1546, cross-chainsmart contract 1526 validates the formatted ledger data and determines whether the formatted ledger data is valid. In some embodiments, cross-chainsmart contracts 1526 may validate formatted ledger data based on hash values received fromcross-chain relay component 1524. In some examples, cross-chainintelligent contracts 1526 may calculate a hash value for formatted ledger data and compare the calculated hash value to the received hash value. If the two hash values match, cross-chainintelligent contract 1526 may determine that the formatted ledger data is valid. If the two hash values do not match, cross-chainintelligent contract 1526 may determine that the formatted ledger data is invalid and discard the formatted ledger data. In some embodiments, cross-chainintelligent contracts 1526 may determine whether the format of the formatted ledger data matches a predetermined data format. Cross-chainintelligent contract 1526 may determine that the formatted ledger data is valid if the format of the formatted ledger data matches a predetermined data format. Cross-chainintelligent contract 1526 may determine that the formatted ledger data is invalid if the format of the formatted ledger data does not match the predetermined data format.

At 1548, cross-chainsmart contract 1526 parses the formatted ledger data. In some embodiments, cross-chainsmart contracts 1526 may perform a predetermined parsing method on the formatted ledger data, such as by converting the formatted ledger data into the original ledger data format. In some examples, cross-chainsmart contracts 1526 may obtain ledger data by converting formatted ledger data to an original ledger data format.

Atstep 1550, cross-chainsmart contract 1526 sends ledger data to servicesmart contract 1528 after obtaining ledger data by parsing formatted ledger data.Service intelligence contracts 1528 receive ledger data and make ledger data available to users accessingblock chain network 1520.

Fig. 16 depicts an example 1600 of data storage in a blockchain based trusted platform according to embodiments herein. At a high level, the data storage ofblock link points 1602 may include an intelligentcontract data cache 1606 and ablock chain database 1610. Intelligentcontract data cache 1606 may be used to store variable data managed by intelligent contracts, whileblockchain database 1610 may be used to store incremental immutable blockchain data, such as intelligent contract code, inputs, outputs, and execution logs of intelligent contracts.Blockchain database 1610 may be a key-value database, includingblockchain database 1612,state database 1618, andextension database 1624.Block database 1612 may store block chain data including ablock header 1614 and ablock bank 1616.State database 1618 may store state information related to blockchain data, includingstate tree 1620 andstorage tree 1622. Theextension database 1624 may store intelligent contract data that includes a plurality ofintelligent contract pools 1626 andmetadata 1628 associated with the plurality of intelligent contract pools 1626.

Block chain node 1602 may invoke virtual machine 1608 to execute the intelligent contract. In some embodiments, the virtual machine 1608 may be deployed in a trusted computing environment such as a TEE. In some embodiments, the virtual machine 1608 may be configured to perform intelligent contract operations by executing instructions of an intelligent contract programming language. In some examples, the virtual machine 1608 may access resources external to the TEE during execution of the operation, such as an external server, a blockchain, a database, or other resource indicated by the operation. In some embodiments, access to external resources may be restricted or denied such that the overall execution of an operation depends only on data stored in the TEE (e.g., smart contract state). Such a limitation may also reduce the likelihood of tampering with the execution of the operation.

The intelligent contract operation may include an execution state of the intelligent contract associated with the requesting contract operation (e.g., adding a document, updating a document state, etc.). During execution of the intelligent contract, a plurality of blockchain nodes of the blockchain network can respectively execute each instruction of the intelligent contract and generate a result indicating the execution state of the intelligent contract after the instruction is executed. The execution state may include data associated with the smart contract. Each executed instruction of a contract may alter the content of the data (e.g., store a value to be used by subsequent instructions in the intelligent contract).

After executing the instructions of the intelligent contract, the nodes of the blockchain network may agree on a new execution state after executing the instructions. This consensus process is performed on each instruction executed in the intelligent contract, thereby causing consensus to be reached as to the execution path of the intelligent contract. The execution path may be recorded as a corresponding smart contract execution event log recorded inblock database 1612. Finally, the final result of the execution (i.e., the output) is also recorded intile database 1612.

In general, the variable data may include document type, document ID, document status, modifiable data for document content, transaction hashes associated with document data stored in the smartcontract data cache 1606 andblockchain database 1610, link information provided for linking different documents associated with the same order, encryption keys, and a list of authorized users of the documents, among other things. In some embodiments, the intelligentcontract data cache 1606 may also store index data to associate variable data and non-variable data associated with the same document or transaction. As previously described, the index data may include a document ID associated with the document and a transaction hash associated with the transaction. Document IDs may be stored in the intelligentcontract data cache 1606 andblockchain database 1610 to link variable data and non-variable data associated with the same document. Transaction hashes may be stored in the intelligentcontract data cache 1606 andblockchain database 1612 to link variable data and non-variable data associated with the same transaction. In this way, when querying a document or a transaction associated with a document, variable data and immutable data can be identified from two storage locations.

The document type and document ID may indicate the type and ID of the document, respectively. The document state may indicate a state of the document. Modifiable data of document content may be specific content such as overhead that a creator of the document inserts into the document for data processing.

The transaction hash may be a hash value of immutable blockchain data stored inblockchain database 1610. The encryption key may comprise a symmetric key used to encrypt the document data before it is stored on the blockchain inblockchain database 1610. The encryption keys may also include encryption keys associated with users of the blockchain based trustedplatform 300 as described in the description of figure 3. The data stored inblockchain database 1610 may be encrypted to protect the privacy of the document owner.

The document owner may provide access to the plaintext document to another user of the trusted platform based on the blockchain by issuing an encrypted version of the symmetric key using a public key of the user. The encrypted data is immutable and stored in theblockchain database 1610, and a hash value of the encrypted data (i.e., a transaction hash) may be generated and stored with an encrypted version of the symmetric key to the smartcontract data cache 1606 under the same data structure. In general, the transaction hash may be used to link variable data stored in the intelligentcontract data cache 1606 with immutable blockchain data associated with the same order stored in theblockchain database 1610. For example, the order document and the one or more logistics documents associated with the order may include variable data stored in the intelligentcontract data cache 1606 and encrypted documents stored in theblockchain database 1610. The transaction hash for the encrypted document stored in theblockchain database 1610 may be stored with the variable data under the same data structure in the intelligentcontract data cache 1606. In this way, data stored in different locations can be linked at query time.

To query the data, a licensed user may search the smartcontract data cache 1606 to obtain the hash value and the encrypted version of the symmetric key. The user can decrypt the encrypted version of the symmetric key using his private key. If the symmetric key is successfully decrypted, the user may determine that he has access to the plaintext data. The user may then use the hash value to locate the encrypted data fromblockchain database 1610 and decrypt the encrypted data using the symmetric key.

In some embodiments, the variable data in the intelligentcontract data cache 1606 is stored as KVP. Cache storage may be a relatively high speed, high cost, and low capacity storage medium compared to other storage media such as hard disk drives. When the capacity of the KVP exceeds a certain threshold (e.g., 5 GB), a cache-miss state may occur. A cache miss refers to a state in which data required for processing by a component or an application cannot be found in a cache memory. Cache misses may require a program or application to retrieve data from other cache levels or main memory, resulting in execution delays.

In some embodiments, a plurality ofintelligent contract pools 1626 may be created inblockchain database 1610 to store at least a portion of the variable data managed by the intelligent contracts in intelligentcontract data cache 1606. At least a portion of the variable data may then be moved from the high cost cache storage to theblockchain database 1610 to reduce overall storage cost and mitigate cache miss conditions.

In some embodiments, a new intelligent contract address may be added to theconfiguration file 1604 by theblock link point 1602 to create a corresponding intelligent contract. When executing theconfiguration file 1604, the virtual machine 1608 may create an intelligent contract based on the intelligent contract address. When a corresponding intelligent contract is created, a pool of intelligent contracts corresponding to the intelligent contract may be automatically created in theextension database 1624.

In some embodiments, the data stored inintelligent contract pool 1626 is also recorded inblock database 1612 by consensus. In some embodiments, the data stored in the pool of intelligent contracts may be specifically managed by the respective intelligent contract. The contract IDs of the intelligent contracts may be added to the data stored in the respective intelligent contract pools so that the data in the pools may be easily queried, retrieved, or otherwise managed by the intelligent contracts.

In some embodiments, documents may be stored in one of theintelligent contract pools 1626 based on a hash value of one or more of the document ID or document type. A range of hash values may be predetermined and assigned to eachintelligent contract pool 1626. For example, for a document with a document ID of 000001, the md3 hash value is 769924EADBBF6F72C6581377419FCB77. Assuming there are 16 intelligent contract pools, the document may be stored in a seventh intelligent contract pool based on the first bit hexadecimal number of the hash value. Likewise, a document with a document ID of 000003 has an md3 hash value of 4DE1F0F6DA993FC4AB439CDCA5E084F6. The document may be stored in a fourth intelligent contract pool based on the first bit hexadecimal number of the hash value.

In some embodiments, the order file, logistics file, and payment file associated with the same order may be assigned the same file ID or tag. In this way,intelligent contract pools 1626, and blockchains 814 may be easily located when queried from the intelligentcontract data cache 1606 and them. To link documents associated with the same order stored in differentintelligent contract pools 1626, a document ID for the corresponding intelligent contract may be added to each document along with the corresponding document ID. In this way, documents may be retrieved from differentintelligent contract pools 1626 based on document ID. In some embodiments, the document ID may be a transaction hash of the corresponding document. The transaction hash may be used to locate corresponding immutable data stored intile database 1612.

In some embodiments, a new pool of intelligent contracts may be created periodically. For example, if a new pool of intelligent contracts is created each month, the intelligent contracts may be associated with a creation time (denoted as MMYYYY, where MM denotes the creation month and YYYY denotes the creation year). In this way, variable data created in a particular month may be stored in the intelligent contract pool created for that month.

In some embodiments, the documents may be stored in eachintelligent contract pool 1626 in a round robin fashion. In some examples, after the intelligent contract pool reaches its storage capacity, the variable data for the new document may be stored in the next intelligent contract pool. In some examples, after the intelligent contract pool stores variable data for a predetermined number of documents, the variable data for the new document may be stored in the next intelligent contract pool.

Fig. 17 depicts an example of a system 1700 for implementing a blockchain based trustedplatform 1702 according to embodiments herein. The blockchain based trustedplatform 1702 provides an integrated interface that allows users to manage information used in various stages of contract formulation and execution. In some embodiments, blockchain-based trustedplatform 1702 provides services to one or more contracting parties (e.g., contracting party a1768 and contracting party B1770) such that contracts negotiated and signed by the contracting parties may be securely stored (e.g., inblockchain database 1610 and intelligentcontract data cache 1606, as described in the description of fig. 16). In some embodiments, the blockchain-based trustedplatform 1702 may also provide services to other entities associated with the contract, such as one ormore banks 1772, one or more judicial bodies 1774, and one or more government bodies 1776, via a network 1764 (e.g., the internet).

The contractor a1768 may be a buyer purchasing services or goods from the contractor B1770. Contractor a1768 and contractor B1770 may negotiate a contract that defines the goods or services to be purchased, the date of delivery, the manner of payment, the amount of default, etc. When both parties to the contract agree to the terms of the contract, they may sign the contract, and either the contracting party a1768 or the contracting party B1770 may send a copy of the contract to the blockchain-based trustedplatform 1702 for record keeping, e.g., by storing the copy of the contract in theblockchain database 1610 and/or the intelligentcontract data cache 1606.

Thebank 1772 may maintain a bank account of the contracting parties and send and receive payments between the contracting parties.Bank 1772 may provide payment information related to the contract to trustedplatform 1702 based on the blockchain. The bank may generate a payment document including payment information related to the contract and send the payment document to the blockchain-based trustedplatform 1702.

Judicial agencies 1774 may resolve disputes during contract execution. For example, the contracting party a1768 may default to payment to the contracting party B1770. The judicial agency 1774 may issue court orders and adjudications to identify the contractor a1768 as a debtor and the contractor B1770 as a creditor. Judicial authority 1774 may send a copy of the court order to blockchain-based trustedplatform 1702 for record keeping, for example, by storing a copy of the court order inblockchain database 1610 and/or intelligentcontract data cache 1606. Contractor B1770 may then send a request to block-chain based trustedplatform 1702 to charge the decision amount from contractor a 1768. After verifying that the request is associated with a real court order stored in the blockchain, the blockchain-based trustedplatform 1702 may identify one or more bank accounts associated with the contractor a1768 having a total balance that is not less than the decision amount and transfer the decision amount from the one ormore bank accounts 1768 associated with the contractor a to the one or more bank accounts associated with the contractor B.

Government agency 1776 may be a governmental agency responsible for overseeing and regulating activities associated with the contract, such as determining whether the contract complies with laws, regulations or regulations, and evaluating and collecting customs, taxes and fees associated with importation and exportation of goods. Government agency 1776 may also be responsible for detecting fraudulent activity associated with contracts. Government agency 1776 may access and retrieve contracts stored in block chain based trustedplatform 1702.Trusted platform 1702 based on a blockchain may provide services to government agencies 1776, such as checking contracts for potential violations or fraud.

The blockchain based trustedplatform 1702 interacts with ablockchain network 1756 that includes a plurality ofblockchain nodes 1758 to securely record contract information in theblockchain database 1610 and the intelligentcontract data cache 1606. As described above, intelligentcontract data cache 1606 may store variable data in the form of intelligent contract data, andblockchain database 1610 may store incremental, immutable, persistent blockchain data. This provides a good balance between processing efficiency and storage cost of the blockchain data.

In some embodiments, blockchain based trustedplatform 1702 includes anapplication layer 1704, a trustedservices layer 1710, ablockchain layer 1718, aninfrastructure layer 1738, and atool platform 1744.

Theapplication layer 1704 may provide for convenient and secure access and processing of contract data by one or more contracting parties (e.g., contracting party a1768 and contracting party B1770, one ormore banks 1772, one or more jurisdictions 1774, and one or more government agencies 1776). For example, theapplication layer 1704 may include adata recording function 1706 that enables contract data to be recorded on a blockchain. Theapplication layer 1704 may also include adata verification function 1708 that enables verification of whether particular contract data is recorded on the blockchain. Theapplication layer 1704 may invoke other layers of the blockchain based trustedplatform 1702.

The trustedservices layer 1710 may provide trusted blockchain services to theapplication layer 1704 to ensure that data recorded on the blockchain is trusted. The trustedservice layer 1710 may include a trustedidentity module 1712, atrusted time module 1714, and a trustedcomputing module 1716.

Blockchain layer 1718 may provide core functionality for blockchain based trustedplatform 1702 and may includeAPI layer 1720, platform management layer 1734, and base services layer 1736.API layer 1720 may include an interface for inputting and outputting data to and from block chain based trustedplatform 1702. TheAPI layer 1720 may include: arecord input interface 1722 for receiving data to be recorded on the blockchain; arecord output interface 1724, configured to output a result of recording data on the blockchain; anauthentication input interface 1726 for receiving data to be authenticated based on the data recorded on the blockchain; averification output interface 1728 for outputting a result of verifying data based on the data recorded on the blockchain; a datahistory search interface 1730 for querying data recorded on the blockchain; thetransaction search interface 1732 is used to query transactions recorded on the blockchain. Platform management layer 1734 may provide management functions such as chain domain management, node management, and organizational management. Chain domain management may provide network management and configuration management at the blockchain level. Node management may manage the joining or exiting of consensus nodes. The organization administration may specify access rights for entities accessing the platform. Thebase services layer 1736 may include modules that provide basic functionality for the blockchain based trustedplatform 1702, such as a consensus policy module, a privacy protection module, a network protocol module, a blockchain storage module, a ZKP generation module, and a ZKP verification module. The consensus strategy module may enable block link points to agree on data to be recorded on the block chain. The privacy protection module may protect the identity of the entity accessing the platform and the privacy of the transaction. The network protocol module may enable reliable communication between blockchain nodes. The blockchain storage module may enable reliable storage of data on the blockchain. The ZKP generation module may be to generate one or more ZKPs based on the data to be hidden. The ZKP validation module may be configured to validate one or more ZKPs based on the input proof.

Infrastructure layer 1738 may provide computing and communication functionality for block chain based trustedplatform 1702.Infrastructure layer 1738 may provide cloud services such as public cloud 1740 andprivate cloud 1742.Infrastructure layer 1738 may ensure secure data storage, analysis, and computation.

Tool platform 1744 may provide tools for monitoring, managing, and operation and maintenance of block chain based trustedplatform 1702. Thetool platform 1744 may include astatistics display tool 1746, astatus monitoring tool 1748, alog collection tool 1750, aperformance analysis tool 1752, and anetwork topology tool 1754.

Fig. 18 depicts an example of aprocess 1800 for recording ledger data according to embodiments herein.Process 1800 may be performed by a blockchain-based trusted platform implemented on one or more blockchain nodes or on one or more computing devices communicatively coupled to one or more blockchain nodes (e.g., blockchain-based trusted platform 1702). For clarity of presentation, the following description generally describes theprocess 1800 in the context of other figures herein. However, it should be understood that theprocess 1800 may be suitably performed, for example, by any system, environment, software, and hardware, or combination of systems, environments, software, and hardware. In some embodiments, the various steps ofprocess 1800 may be run in parallel, combined, in a loop, or in any order.

At 1802, ledger data to be recorded on a blockchain may be received from a client device and via a record input interface (e.g., record input interface 1722). In some embodiments, the blockchain based trusted platform includes a data logging function (e.g., data logging function 1706) for logging ledger data on the blockchain; a data validation function (e.g., data validation function 1708) for validating ledger data recorded on a blockchain; a trusted service layer (e.g., trusted service layer 1710) to provide trusted computing; and a blockchain layer (e.g., blockchain layer 1718) including a record input interface and a record output interface (e.g., record output interface 1724).

In some embodiments, the client device is associated with a second blockchain that is different from the first blockchain in which data is to be recorded. In some embodiments, the first blockchain may store blockchain data in a first standardized format, and the second blockchain may store blockchain data in a second standardized format different from the first standardized format. For example, a first blockchain may be a public blockchain and a corresponding transaction has a standardized format that includes data fields such as total input, total output, cost, etc., while a second blockchain may be a federation blockchain and a corresponding transaction has a standardized format that includes data fields such as value, random number, gas limit (gas limit), etc. If the client device packages data to be recorded in a federation blockchain transaction and sends the federation blockchain transaction to a public blockchain node for recording, the public blockchain node may not be able to resolve the federation blockchain transaction because, for example, the data field of the federation blockchain transaction is different from the data field of the public blockchain transaction. In some embodiments, the client device sends a cross-chain message including ledger data to the first blockchain based on the process discussed in fig. 15.

In some embodiments, ledger data includes one or more logging input parameters defined in a logging rule and accepted by a logging input interface. In some embodiments, ledger data includes one or more record-entry parameters associated with structured data. The structured data may be, for example, data having a standardized format with one or more predetermined data fields. For example, the data records in the key value table may be structured data. As another example, a blockchain transaction having predetermined data fields (e.g., total input, total output, cost) may also be structured data. In some embodiments, at least one of a location of a data field of the structured data or a number of bits associated with the data field is predetermined in a standard format.

In some embodiments, ledger data includes one or more record-entry parameters associated with unstructured data. Unstructured data may be, for example, data that cannot be presented in a multidimensional table. For example, the unstructured data may be data files, such as text files, image files, video files, audio files, and the like.

If ledger data is associated with structured data, the one or more record input parameters may include one or more of: the data information of the structured data, the service information of the structured data, the timestamp of the structured data, the signature data of the structured data, and the block chain consensus result of the structured data. The data information of the structured data may include one or more of: the unique ID of the structured data and/or a hash value of the structured data and at least a portion of the structured data calculated based on a hash function. The service information of the structured data may include: such as an ID of a contract associated with the structured data, one or more IDs associated with parties to the contract, a name of the contract, etc. The timestamp of the structured data may indicate the time the structured data was created or last modified. The signature data of the structured data may be the structured data signed by using a private key of a user of the client device. The blockchain consensus result for the structured data may indicate whether blockchain consensus has been achieved for the structured data.

If ledger data is associated with a data file, the one or more record input parameters may include one or more of: the hash value of the data file, the attribute information of the data file, the service information of the data file, the timestamp of the data file, and the signature data of the data file. A hash value for the data file may be calculated based on the hash function and at least a portion of the data file. The attribute information of the data file may include one or more of the following: type, source, status, name, size of the data file, user associated with the client device, and update time. The service information for the data file may include, for example, an ID of a contract associated with the data file, one or more IDs associated with parties to the contract, a name of the contract, and so forth. The timestamp of the data file may indicate the time the data file was created or last modified. The signature data of the data file may be the data file signed by using a private key of a user of the client device.

In some embodiments, a secure communication channel is established between the client device and the blockchain-based trusted platform before the client device sends ledger data to the blockchain-based trusted platform. The secure communication channel may be established based on at least one of a two-way Transport Layer Security (TLS) protocol, a two-way hypertext transfer protocol security (HTTPS) protocol, or a one-way HTTPS protocol.

At 1804, it may be determined whether the original ledger data associated with the ledger data satisfies the logging rules.

In some embodiments, the original ledger data is the ledger data itself. In some embodiments, the ledger data comprises a bitstream, and the original ledger data is obtained by converting the bitstream based on a conversion rule. The conversion rule may be included in the recording rule. In some embodiments, prior to receiving ledger data via the record input interface, the client device may generate raw data that includes one or more record input parameters and convert the raw data to a bitstream based on the conversion rules. The conversion rules may include at least one of: a coding scheme corresponding to each of the one or more recording input parameters, or an order in which the one or more recording input parameters are arranged in the bitstream. For example, the client device may generate raw data including one or more recording input parameters, encode each data value of the respective recording input parameters into a respective small bitstream, determine an order in which the one or more recording input parameters are arranged in the bitstream, and concatenate the respective small bitstreams to generate the bitstream.

For example, the raw data includes three record input parameters:record input parameter 1, record input parameter 2, andrecord input parameter 3. The value of theinput parameter 1 is recorded as x. The value of input parameter 2 is recorded as y. The value of theinput parameter 3 is recorded as z. The coding scheme of the transformation rule may provide: x is coded as 1000, y is coded as 1001, and z is coded as 1101. The conversion rule may also refer to: the order in which the three recording input parameters are arranged in the bitstream is {recording input parameter 1,recording input parameter 3, recording input parameter 2}. The resulting bitstream is then 100011011001.

After receiving ledger data, the bitstream included in the ledger data may then be converted into raw data including one or more record input parameters based on a conversion rule. For example, assuming that the bitstream 100011011001 is received, it can be determined that therecording input parameter 1, therecording input parameter 3, and the recording input parameter 2 are received and their respective values are x, z, and y.

In some embodiments, the recording rule defines one or more recording input parameters accepted by the recording input interface. In some embodiments, for each of the one or more recording input parameters, the recording rule provides an input format in which the respective recording input parameter is to be used. For example, the record input parameter may be a variable accepted by the record input interface, the ledger data may include a value corresponding to the variable, and the input format of the record input parameter may be a data type of the variable, a size limit of the variable, characters excluded from use in the variable, and the like. In some embodiments, if the raw ledger data includes at least one of the one or more record-entry parameters and satisfies the entry format of the one or more record-entry parameters, then it is determined that the raw ledger data satisfies the record rule, andprocess 1800 proceeds to 1806. Otherwise, it is determined that the original ledger data does not satisfy the logging rules, andprocess 1800 proceeds to 1812.

At 1806, the original ledger data may be recorded on a block chain. In some embodiments, the trusted service layer may include a trusted time module (e.g., trusted time module 1712), a trusted identity module (e.g., trusted identity module 1714), and a trusted computing module (e.g., trusted computing module 1716). In some embodiments, the data logging function may invoke the trusted time module to generate a first logging timestamp that represents a time at which ledger data was received by the data logging function. In some embodiments, the data recording function may invoke the trusted identity module to verify a user identity associated with the client device and invoke the trusted time module to generate the second recording timestamp. The second record timestamp may represent the time the original ledger data was recorded on the blockchain. In some embodiments, the data logging function may invoke the trusted computing module to generate a blockchain transaction that includes the original ledger data, the user identity, the first logging timestamp, and the second logging timestamp. The blockchain transaction may then be shared with one or more blockchain link points to perform blockchain consensus, and the blockchain transaction may be added to the blockchain after the blockchain consensus is achieved.

At 1808, a record receipt can be generated. In some embodiments, the record receipt indicates that the original ledger data has been successfully recorded on the blockchain.

At 1810, a record receipt may be sent via a record output interface (e.g., record output interface 1724).

At 1812, an error message may be sent via the record output interface. In some embodiments, the error message indicates that the original ledger data does not satisfy the logging rules. In some embodiments, the error message may also include one or more reasons that the original ledger data does not satisfy the recording rules.

Fig. 19 depicts an example of aprocess 1900 for validating ledger data according to embodiments herein.Process 1900 may be performed by a blockchain-based trusted platform implemented on one or more blockchain nodes or on one or more computing devices communicatively coupled to the one or more blockchain nodes (e.g., blockchain-based trusted platform 1702). For clarity of presentation, the following description generally describesprocess 1900 in the context of other figures herein. However, it should be understood thatprocess 1900 may be suitably performed, for example, by any system, environment, software, and hardware, or combination of systems, environments, software, and hardware. In some embodiments, the various steps ofprocess 1900 may be performed in parallel, combined, looped, or in any order.

At 1902, the ledger data may be received from the client device and via an authentication input interface (e.g., authentication input interface 1726). In some embodiments, a client device obtains raw data, such as a contract file, and intends to verify whether the raw data has been tampered with. The client device may then calculate a hash value of the raw data, generate ledger data including the hash value, and send the ledger data to a blockchain-based trusted platform for validation. The blockchain-based trusted platform may compare the hash value received from the client device to the hash value recorded on the blockchain. If the blockchain based trusted platform finds that the hash value recorded on the blockchain matches the hash value received from the client device, the blockchain based trusted platform can verify that the original data has not been tampered with. The blockchain based trusted platform may then send a verification receipt to the client device to indicate that the contract file has not been tampered with.

In some embodiments, the client device is associated with a second blockchain that is different from the first blockchain that received ledger data. In some embodiments, a first blockchain may employ a first standardized format to store blockchain data and a second blockchain may employ a second standardized format different from the first standardized format to store blockchain data. For example, a first blockchain may be a public blockchain and the corresponding transaction has a standardized format that includes data fields such as total input, total output, cost, etc., a second blockchain may be a federation blockchain and the corresponding transaction has a standardized format that includes data fields such as value, random number, gas limit, etc. If the client device packages data to be recorded in a federation blockchain transaction and sends the federation blockchain transaction to a public blockchain node for recording, the public blockchain node may not be able to resolve the federation blockchain transaction because, for example, the data field of the federation blockchain transaction is different from the data field of the public blockchain transaction. In some embodiments, the client device sends a cross-chain message including ledger data to the first blockchain based on the process discussed in fig. 15.

In some embodiments, ledger data includes one or more validation input parameters defined in a validation rule and accepted by a validation input interface. Ledger data may include one or more validation input parameters associated with structured data or unstructured data discussed in fig. 18.

If ledger data is associated with structured data, the one or more validation input parameters may include one or more of: the verification method comprises the steps of selecting a verification method of account book data, unique ID of the structured data, service information of the structured data, time stamp of the structured data and signature data of the structured data. In some embodiments, a blockchain based trusted platform provides multiple authentication methods for client device selection. For example, the plurality of authentication methods may include a bitstream authentication method and a plaintext authentication method. Under a bitstream validation method, ledger data comprises a bitstream and requires conversion of the bitstream into data values of one or more validation input parameters before the ledger data can be validated. Under the plaintext validation approach, ledger data directly includes data values for one or more validation input parameters that do not require conversion. The unique ID of the structured data may be a hash value of the structured data calculated based on a hash function and at least a portion of the structured data. The service information for the structured data may include, for example, an ID of a contract associated with the structured data, one or more IDs associated with parties to the contract, a name of the contract, and so forth. The timestamp of the structured data may indicate the time the structured data was created or last modified. Signature data of the structured data can be signed by using a private key of a user of the client device.

If ledger data is associated with a data file, the one or more validation input parameters may include one or more of: the hash value of the data file, the service information of the data file, the timestamp of the data file, and the signature data of the data file. A hash value for the data file may be calculated based on the hash function and at least a portion of the data file. The service information of the data file may include: such as an ID of a contract associated with the data file, one or more IDs associated with parties to the contract, a name of the contract, etc. The timestamp of the data file may indicate the time the data file was created or last modified. The signature data of the data file may be the data file signed by using a private key of a user of the client device.

At 1904, it may be determined whether the original ledger data associated with the ledger data satisfies validation rules. In some embodiments, the original ledger data is the ledger data itself. In some embodiments, the ledger data comprises a bitstream, and the original ledger data is obtained by converting the bitstream based on a conversion rule. The conversion rule may be included in the validation rule. In some embodiments, the conversion between the bitstream and the raw data follows a similar process as discussed in fig. 18.

In some embodiments, the validation rule defines one or more validation input parameters accepted by the validation input interface. In some embodiments, for each validation input parameter of the one or more validation input parameters, the validation rule provides an input format in which the respective validation input parameter is to be employed. For example, the validation input parameter may be a variable accepted by the validation input interface, the ledger data may include a value corresponding to the variable, and the input format of the validation input parameter may be a data type of the variable, a size limit of the variable, characters excluded from use in the variable, and the like. In some embodiments, if the original ledger data includes at least one of the one or more validation input parameters and satisfies the input format of the one or more validation input parameters, then it is determined that the original ledger data satisfies the validation rule, andprocess 1900 proceeds to 1906. Otherwise, it is determined that the original ledger data does not satisfy the validation rules, andprocess 1900 proceeds to 1912.

At 1906, it may be determined whether the original ledger data was validated. In some embodiments, the original ledger data is validated if it matches the first ledger data recorded on the blockchain. In some embodiments, the original ledger data and the first ledger data both comprise a hash value of a data file or a hash value of structured data, and the original ledger data is determined to correspond to the first ledger data if the hash value included in the original ledger data matches the hash value included in the first ledger data. If it is determined that the original ledger data is validated,process 1900 proceeds to 1908. Otherwise,process 1900 proceeds to 1912.

At 1908, a verification receipt can be generated. In some embodiments, the validation receipt indicates that the original data associated with the ledger data has not been tampered with.

At 1910, a verification receipt may be sent to the client device via a verification output interface (e.g., verification output interface 1726).

At 1912, an error message may be sent via the verification output interface. In some embodiments, the error message indicates that the original ledger data does not satisfy the validation rules and one or more reasons that the original ledger data does not satisfy the validation rules. In some embodiments, the error message indicates that the original data associated with the ledger data was tampered with.

Fig. 20 depicts an example 2000 of cross-chain and cross-network data transfer according to embodiments herein. Example 2000 includesinternet 2002,private network 2004, andgateways 2006a and 2006b. In some embodiments, thegateways 2006a and 2006b are two different gateways, where thegateway 2006a processes data sent from theinternet 2002 to theprivate network 2004 and thegateway 2006b processes data sent from theprivate network 2004 to theinternet 2002. In some embodiments,gateway 2006a andgateway 2006b are the same gateway. In some embodiments, the only physical network path between theinternet 2002 and theprivate network 2004 is viagateways 2006a and 2006b.

In some embodiments, a first plurality of blockchain nodes (e.g.,blockchain point 1 2008a to blockchain point 5 2008e) of a first blockchain network are connected through theinternet 2002. For example, a first plurality of block link points may be associated with one or more participants of a contract. In some embodiments, a second plurality of blockchain nodes (e.g.,blockchain point 1 2010a to blockchain point 5 2010e) of the second blockchain network are connected by theprivate network 2004. The second plurality of blockchain nodes may be associated with, for example, a judicial agency, a financial institution, a governmental agency, or the like. In some embodiments, each blockchain node of the first and second plurality of blockchain nodes may access the blockchain based trustedplatform 1702 via theAPI layer 1720.

In some embodiments, thegateway 2006a includes at least one network device and at least one server. At least one network device may be interconnected with a router ofinternet 2002 and a router ofprivate network 2004. In some embodiments, thegateway 2006a allows one-way data transfer from the internet to the private network, or vice versa, but does not allow two-way data transfer between the internet and the private network.

In some embodiments, to perform unidirectional data transfer, thegateway 2006a employs a single fiber rather than a pair of fibers to connect at least one network device of thegateway 2006a and a router of the internet. Thegateway 2006a may employ another single fiber to connect at least one network device of thegateway 2006a and a router of a private network. At least one network device ofgateway 2006a may be equipped with an optical receiver for connecting to a single fiber ofinternet 2002 and an optical transmitter for connecting to a single fiber ofprivate network 2004, thereby allowing data transmission in a single direction frominternet 2002 toprivate network 2004. In some embodiments, at least one network device of thegateway 2006a employs an optical receiver for connecting to a single optical fiber of theprivate network 2004 and an optical transmitter for connecting to a single optical fiber of theinternet 2002, thereby allowing data transmission in a single direction from theprivate network 2004 to theinternet 2002.

In some embodiments, at least one server of thegateway 2006a stores theciphertext 2012 sent from a block chain node of a first block chain network, such that a second block chain node of a second block chain network may obtain theciphertext 2012 from the at least one server of thegateway 2006a. In some embodiments, at least one server ofgateway 2006b stores ciphertext 2014 sent from a block link point of the second blockchain network, such that the block link point of the first blockchain network may obtain ciphertext 2014 from the at least one server ofgateway 2006b.

Fig. 21 depicts an example of aprocess 2100 for cross-chain and cross-network data transfer according to embodiments herein. At a high level, the participants ofprocess 2100 include a firsttile link point 2008a, agateway 2006a, and a secondtile link point 2010a.Process 2100 may be performed to send data from firstblob link point 2008a to secondblob link point 2010a. As discussed in the description of fig. 20, a firstblockchain link point 2008a is associated with the first blockchain network and connected to other blockchain links of the first blockchain network through theinternet 2002, and a secondblockchain link point 2010a is associated with the second blockchain network and connected to other blockchain links of the second blockchain network through theprivate network 2004. The block link point of the first block chain network may record block chain data on the first block chain, and the block link point of the second block chain network may record block chain data on the second block chain.

At 2102, the firstchunk link point 2008a may obtain the raw data in the cross-chain message. The original data may be data recorded on the first blockchain. In some embodiments, prior to the firstblockchain link point 2008a retrieving the original data, a third blockchain node of the first blockchain network retrieves the original data from the first blockchain, generates a cross-chain message, and sends the cross-chain message to the first blockchain node. In some embodiments, the third blockchain node may receive a data request from the private network requesting the original data before the third blockchain node retrieves the original data. In some embodiments, the original data is a contract file recorded on the first blockchain, and the third blockchain node may send the contract file to the private network for recording on or verification by the second blockchain network.

At 2104, the first tile link point can verify that the raw data is stored in the first tile chain. The raw data may be verified using the process discussed in fig. 19.

At 2106, the first tile link point can transform the original data to obtain first data.

In some embodiments, the raw data includes one or more data values associated with one or more data fields arranged using a first standardized format of a first blockchain network. The first blockchain network may need to convert the raw data into a second standardized format that can be parsed by the second blockchain network. For example, the conversion is performed based on a conversion rule. The transformation rules may provide at least one of: an order of data fields to be arranged in the first data, or an encoding scheme of each data value included in each data field is converted. In some embodiments, the conversion rule is predetermined by the first blockchain network and the second blockchain network. In some embodiments, the second blockchain network determines the input rule according to at least one of a logging rule as discussed in fig. 18 or a validation rule as discussed in fig. 19, wherein the input rule provides at least one of: a plurality of input parameters input to the second blockchain network, a coding scheme corresponding to each of the plurality of input parameters, or an order in which the plurality of input parameters are arranged in the input. The first blockchain network may then determine a conversion rule based on the input rule. For example, if a data field is not included in the plurality of input parameters provided by the input rule, the first blockchain node does not include the data field in the first data.

In some embodiments, the first data comprises a bitstream obtained by encoding each data value of the data fields into a respective small bitstream, determining an order in which one or more data values are arranged in the bitstream, and splicing the respective small bitstreams to generate the bitstream.

At 2108, the first block link point may encrypt the first data to generate ciphertext. The encryption algorithm may be a symmetric encryption algorithm or an asymmetric encryption algorithm.

At 2110, the first chunk link point may generate a hash value of the first data.

At 2112, the first tile link point can generate one or more ZKPs associated with the first data. One or more ZKPs may be generated using a ZKP generation module as discussed in fig. 17 and based on ZKP algorithms, such as a zero-knowledge compact non-interactive knowledge point of knowledge (zk-SNARK) algorithm or a zero-knowledge scalable transparent knowledge point of knowledge (zk-STARK) algorithm. The one or more ZKPs may be used bygateway 2006a to confirm that the ciphertext is secure without decrypting the ciphertext.

ZKP is an encryption technique. Using this technique, the prover can let one or more verifiers believe that a certain claim is correct without providing the verifier or verifiers with any sensitive information.

ZKP algorithms typically include key generation algorithms, proof generation algorithms, and proof verification algorithms. The key generation algorithm is responsible for computing a proof key (which can be used as input data for generating a proof) and a verification key (which can be used as input data for verifying a proof). The proof generation algorithm is responsible for generating the proof. The proof verification algorithm is responsible for verifying the proof and obtaining binary verification results that are true or false.

Taking the zk-SNARK algorithm as an example, the zk-SNARK algorithm comprises three algorithms: G. p and V. The G algorithm represents a key generator, which is responsible for generating the attestation key and the authentication key. The P algorithm is responsible for generating the proof. The V algorithm is responsible for verifying the proof generated with the P algorithm and obtaining a verification result that is true or false.

It should be noted that when credentials are to be computed by block chain nodes based on a credential generation algorithm, the content of the input data to the credential generation algorithm typically depends on the statement that is to be verified with the credentials.

In some embodiments, the gateway 2006 determines that the ciphertext is secure when at least one of the following claims is true.

Statement 1: the data to be decrypted from the ciphertext does not include any keys defined in the restricted list maintained bygateway 2006a. To determine whether this declaration is true, the ZKP may be generated by inputting at least the raw data, the ciphertext, and the restricted list into a credential generation algorithm.

Statement 2: the data to be decrypted from the ciphertext satisfies the input rules of the second blockchain network. To determine whether this declaration is true, the ZKP may be generated by inputting the raw data, the ciphertext, and the input rules of the second blockchain network into a credential generation algorithm.

Statement 3: the file to be decrypted from the ciphertext has a file type that is acceptable to the second blockchain network. To determine whether this declaration is true, the ZKP may be generated by inputting the raw data, the ciphertext, and a list of file types acceptable to the second blockchain network into a proof generation algorithm.

Statement 4: the data to be decrypted from the ciphertext does not contain malware or viruses. To determine whether the claim is true, the ZKP may be generated by inputting at least the original data, the ciphertext, and the code of the malware or virus into an evidence generation algorithm.

At 2114, the first block link point may send the ciphertext, the hash value, and one or more ZKP togateway 2006a.

At 2116,gateway 2006a may validate the ciphertext based on the one or more ZKPs.

Specifically, as a verifier of one or more ZKPs,gateway 2006a may input at least the one or more ZKPs and the ciphertext as input data into a proof verification algorithm, and then determine whether the ciphertext is secure based on the foregoing statement.

Again taking the zk-SNARK algorithm as an example, when zero knowledge verification is to be performed on one of the one or more ZKPs, the ZKP and the ciphertext may be input as input data into the V algorithm of the zk-SNARK algorithm for calculation. If the output result of the V algorithm is true, then the assertion is verified as true using ZKP. Conversely, if the output result of the V algorithm is false, the assertion is verified as false using ZKP.

At 2118, when thegateway 2006a determines that the ciphertext is secure based on the one or more ZKPs, thegateway 2006a stores the received ciphertext and the received hash value in at least one server included in thegateway 2006a.

At 2120,gateway 2006a may send a data notification to secondtile link point 2010a. The data notification may notify the second block link point ciphertext to be stored in the at least one server.

At 2122, in response to the data notification, the secondtile link point 2010a can send a data retrieval request to thegateway 2006a. In response to the data retrieval request, a network connection may be established betweengateway 2006a and secondzone link point 2010a.

At 2124, thegateway 2006a can send the ciphertext and the hash value to the secondchunk link point 2010a.

At 2126, the secondblock link point 2010a may decrypt the ciphertext to generate second data. The second data may be identical to the first data if the first data or the ciphertext has not been tampered with in the data transmission. Otherwise, the second data may be different from the first data.

At 2128, the secondchunk link point 2010a may validate the second data based on the hash value. For example, the secondchunk link point 2010a may calculate a second hash value for the second data and compare the second hash value to the hash value. If the second hash value and the hash value are the same, the secondchunk chain node 2010a may determine that the first data or ciphertext has not been tampered with. Otherwise, the secondblock link point 2010a may determine that the first data or ciphertext was tampered with.

At 2130, the secondtile link point 2010a may store the one or more input parameters included in the second data on the second tile chain. In some embodiments, the second data comprises one or more input parameters as defined in the input rules of the second blockchain network. In some embodiments, the second data comprises a bitstream, and the secondblockchain link point 2010a converts the bitstream into one or more input parameters based on conversion rules used by the first blockchain node in converting the original data into the first data.

At 2132, the secondtile link point 2010a may send a data receipt to thegateway 2006a. In some embodiments, the data receipt indicates that the ciphertext was successfully received and the second data is stored on the second blockchain. In some embodiments, the data receipt indicates one or more reasons that the second data is not stored on the second blockchain and that the second data is not stored on the second blockchain. The one or more reasons may include, for example, the ciphertext failed to be received by thesecond blockchain node 2010a, the hash value of the ciphertext did not match the received hash value, the second data did not satisfy the input rules of the second blockchain network, and so on.

At 2134,gateway 2006a can send a data receipt to firsttile link point 2008a. In some embodiments, firstblob link point 2008a may resumeprocess 2100 if the data receipt indicates that the second data is not stored on the second blob chain.

In some embodiments, the firstblockchain link point 2008a may obtain additional ciphertext from thegateway 2006a, where the gateway 2006 receives the additional ciphertext from a blockchain node of the second blockchain network. The first block chaining point may then decrypt the additional ciphertext to generate third data, which is then stored in the first block chain.

In some embodiments,process 2100 may be performed to transmit data from a private network to the internet. That is, a firstzone link point 2008a may be associated with a private network, while a secondzone link point 2010a may be associated with the internet.

Fig. 22 depicts an example 2200 of cross-network and cross-chain data communications according to embodiments herein. At a high level, the example 2200 shows a process of sending adebtor 2202 associated with a first block link point of a first block chain network aloan contract 2206a to abank 2204 associated with a second block link point of a second block chain network. The first blockchain network may be connected through the internet and the second blockchain network may be connected through a private computer network that is air isolated from the internet.

A first block link point associated with a debtor may encrypt aloan contract 2206a to generate aciphertext 2208a, and generate one ormore ZKPs 2210 to prove that theciphertext 2208a is secure. The first block link point may sendciphertext 2208a and one ormore ZKPs 2210 togateway 2006a.Gateway 2006a may then verify that ciphertext 2208a is secure based on one or more ZKPs 2210, whileciphertext 2208a remains encrypted in the verification process. After successful verification, thegateway 2006a may then store theciphertext 2208a in a server of thegateway 2006a. The second block link point associated withbank 2204 may then obtain ciphertext 2208b from the server ofgateway 2006a. Thebank 2204 may then decrypt the ciphertext 2208b to obtain theoriginal loan contract 2206b and perform subsequent operations on theloan contract 2206 b.

Fig. 23 depicts an example 2300 of a blockchain-based trusted platform, according to embodiments herein. In some embodiments, blockchain-based trustedplatform 1702 may provide services to users in multiple computer networks by employing data security rules in the various computer networks. In this example, merchants (e.g.,merchant 1 2302a through merchant N2302N) are associated with a network of merchant blockchains that use internet connectivity. Banks (e.g.,bank 1 2304a through bank N2304N) are associated with a bank blockchain network that is connected using a private banking network. A court (e.g.,court 1 2306a through court N2306N) is associated with a court-block-chain network that uses a private court network connection.

For example,merchant 1 2302a wishes to send a contract tobank 1 2304a to record the contract on a bank block chain associated with the bank. The first blockchain link point associated withmerchant 1 2302a obtains a contract from merchant blockchain database 2310 or smartcontract data cache 2308 and sends cross-chain and cross-network messages including the contract to the second blockchain node associated withbank 1 2304a based onprocess 2100 discussed in fig. 21.Bank 1 2304a invokes the services of the blockchain-based trustedplatform 1702 to record the contract in the bank blockchain based on theprocess 1800 discussed in fig. 18. Data security rules for a private banking network may require that contract data be stored in a computer server located in the private banking network that is air isolated from the internet. When the blockchain based trustedplatform 1702 detects that a contract is to be recorded in a bank blockchain, the blockchain based trustedplatform 1702 records the contract in abank blockchain database 2312 managed by the bank blockchain network and a bank intelligentcontract data cache 2314 located in the private bank network.

In a similar manner,merchant 1 2302a may need to send a court order tocourt 1 2306a to execute the court order. The first block link point associated withmerchant 1 2302a sends cross-chain and cross-network messages including a court order to the third block chain node associated withcourt 1 2306a based onprocess 2100 discussed in fig. 21.Court 1 2306a invokes the services of the block chain based trustedplatform 1702, verifying the authenticity of the court order based on the process discussed in fig. 19. The data security rules of the private court network may require that court data be stored in a computer server located in the private court network that is air isolated from the internet. When the blockchain based trustedplatform 1702 detects that the court order is to be validated based on the court data, the blockchain based trustedplatform 1702 accesses the court data in thecourt blockchain database 2316 managed by the court blockchain network and the court intelligentcontract data cache 2318 located in the private court network to validate the court order based on the court data.

For another example, the blockchain based trustedplatform 1702 may treat merchant data, bank data, and court data differently. For example, each of the private banking network and the private court network may have data security rules that govern the procedures for handling sensitive data and the privacy protections applied to the sensitive data. In some embodiments, the blockchain based trustedplatform 1702 provides the same APIs to merchants, banks, and courts, but theapplication layer 1704 will handle sensitive data differently depending on the computer network associated with the sensitive data.

For example, the blockchain based trustedplatform 1702 includes arules database 2320 that includes information regarding the regulations of the various computer networks in which the blockchain based trustedplatform 1702 operates. Theapplication layer 1704 may access therules database 2320 and operate in accordance with the regulations of each computer network. For example, whenbank 1 2304a calls the block chain based trustedplatform 1702 to send the bank statement formerchant 1 2302a tocourt 1 2306a, theapplication layer 1704 may access therules database 2320 to determine the data security rules for the private bank network, specify that the social security codes for the bank statement are to be edited when sending the bank statement out of the private bank network, and then the block chain based trustedplatform 1702 may edit the social security codes for the bank statement and send the edited bank statement tocourt 1 230a.

Fig. 24 depicts another example 2400 of a blockchain based trusted platform according to embodiments herein. A blockchain based trustedplatform 1702 may be used to process custom clearance data based on a set of custom rules agreed upon by a group of people. For example, the block chain based trustedplatform 1702 may be used to process import customs clearance data when a first group of people in a country agree to follow a set of rules regarding import tax items for an item.

For example, a second group of environmentally conscious members may decide to purchase products primarily from sustainable sources and donate a percentage of the purchase price of goods purchased from non-sustainable sources to the environmental career. It is difficult for an individual to track products from sustainable or non-sustainable sources. The blockchain based trustedplatform 1702 allows the second group members to easily set rules to help achieve their goals. For example, the blockchain based trustedplatform 1702 may include arules database 2412 that specifies which consumer products are from sustainable sources, which agricultural products are produced using environmentally friendly methods, and which seafood products are produced by harvesting marine wildlife in a sustainable manner. The administrator may update therules database 2412 from time to time. A second group member (e.g.,first buyer 2402.., nth buyer 2404) may purchase products from a merchant (e.g.,first merchant 2406.., mth merchant 2408) through anonline commerce system 2414.

When a buyer purchases a product via theonline commerce system 2414 and indicates that the buyer belongs to a second group member, theonline commerce system 2414 sends the purchase data to the blockchain based trustedplatform 1702 and indicates that the purchase data is associated with the second group (e.g., via an ID associated with the second group). The blockchain based trustedplatform 1702 records the purchase data on a blockchain database 2418 and/or an intelligentcontract data cache 2416. The blockchain based trustedplatform 1702 includes aclearance approval module 2410 that analyzes the purchase data based on arules database 2412 to determine whether the purchased product is from a sustainable source. If the product is not from a sustainable source,clearance approval module 2410 determines the amount of the donation that the buyer should donate (this is similar to the amount of the import tax that the customs authority determines will apply to the import goods).

For example,clearance approval module 2410 may send a message to the buyer indicating that the product is not from a sustainable source and that the buyer should donate an amount based on an agreement between members of the second group. The blockchain based trustedplatform 1702 may communicate with the buyer's bank, request payment from the bank, and send the payment as a donation to, for example, an eco-nonprofit organization. Transactions performed by the blockchain based trustedplatform 1702 may be recorded in a blockchain database 2418 that may be verified by interested parties. The services provided by the blockchain based trustedplatform 1702 may be automated through the use of intelligent contracts.

In some embodiments, the blockchain-based trustedplatform 1702 may be used to process clearance data (e.g., import clearance data) in a virtual world, such as a gaming platform. For example, the game platform may allow players to establish a virtual country or kingdom, recruit other players to become citizens or ministers of the virtual country or kingdom, and establish their own rules or laws for the virtual country or kingdom. A citizen or minister of a country or kingdom may trade goods with others. A country or kingdom may raise funds (in the form of virtual currency) by imposing a tax on the trade. The operation of the blockchain based trustedplatform 1702 may be automated through the use of smart contracts to implement virtual clearance and taxes in the virtual world. This allows players of the online gaming platform to establish their own trade tax rules, making the online gaming platform more realistic and interesting.

Fig. 25 is a flow diagram of an example of aprocess 2500 for cross-chain communication. For convenience,process 2000 will be described as being performed by a system of one or more computers located at one or more locations and suitably programmed according to the present disclosure. For example, a suitably programmed blockchain-based system (e.g., blockchain-basedsystem 300 of fig. 3 or blockchain-basedsystem 1400 of fig. 14) may performprocess 2500.

At 2502, a first cross-chain communication component (e.g.,cross-chain communication component 1418 or 1504) in a first blockchain network (e.g.,blockchain network 1410 or 1510) receives a message from a blockchain link point (e.g.,blockchain link point 1412 or 1502) in the first blockchain network. In some embodiments, the message may include ledger data stored in blockchain nodes. In some embodiments, ledger data may include legal documents, business contracts, and the like. In some embodiments, the format of ledger data may include images, videos, web pages, spreadsheets, and the like. In some embodiments, ledger data may include plain text data and/or hash values of plain text data.

In some embodiments, the block link points in the first block chain network include service intelligence contracts (e.g., service intelligence contracts 1414 or 1512) and cross-chain intelligence contracts (e.g., cross-chain intelligence contracts 1416 or 1514). In some embodiments, a cross-chain intelligent contract receives a message including ledger data from a service intelligent contract and forwards the message to a first cross-chain communication component. In some embodiments, a cross-chain intelligent contract may send ledger proofs of ledger data in a message. In some embodiments, ledger certification includes a digital signature generated based on ledger data according to a predetermined encryption or cryptographic algorithm. In some embodiments, a digital signature may be generated based on the ledger data using a private key of the blockchain node.

In some embodiments, the first cross-chain communication component comprises a relay component (e.g.,cross-chain relay component 1420 or 1516). In some embodiments, the relay component receives a message including ledger data from a cross-chain intelligent contract of block link points. In some embodiments, the relay component may obtain ledger data and/or ledger certification in the message.

At 2504, the first cross-chain communication component determines whether ledger data is valid. In some embodiments, the relay component of the first cross-chain communication component obtains ledger data and/or ledger certification in the message and sends the ledger data and/or ledger certification to a presbyope (e.g.,presbyope 1422 or 1518) in the first cross-chain communication component. In some embodiments, the oracle determines whether ledger data is valid. In some embodiments, the predictive engine may validate ledger data based on ledger proofs. In some examples, the oracle may verify a digital signature included in the ledger proof. If the digital signature is valid, the predictive agent may determine that ledger data is valid and continue processing ledger data. If the digital signature is invalid, the predictive-teller may discard ledger data.

At 2506, the first cross-chain communication component generates formatted ledger data after determining that the ledger data is valid. In some embodiments, the predictive engine of the first cross-chain communication component generates formatted ledger data based on the ledger data and sends the ledger data back to the relay component. In some embodiments, the predictive engine may format ledger data according to a unified data format that conforms to a cross-chain communication protocol. In some embodiments, the predictive engine may generate formatted ledger data based on ledger data and ledger certification. In some embodiments, the predictive engine may generate a hash value of the formatted ledger data and send the hash value to the relay component.

At 2508, the first cross-chain communication component sends a cross-chain message to a second cross-chain communication component (e.g.,cross-chain communication component 1438 or 1506) in a second blockchain network (e.g.,blockchain network 1430 or 1520). In some embodiments, the cross-chain message includes formatted ledger data. In some embodiments, the cross-chain message may include the formatted ledger data and a hash value of the formatted ledger data. In some embodiments, the relay component sends the formatted ledger data and/or hash values in the cross-chain message to the second cross-chain communication component.

In some embodiments, the relay component of the first cross-chain communication component is a first relay component. The second cross-chain communication component includes a second relay component (e.g.,relay component 1440 or 1524). The block link point in the first block chain network is a first block chain node. The second blockchain network includes a second blockchain node (e.g.,blockchain link point 1432 or 1508). In some embodiments, the second relay component receives the cross-chain message from the first relay component and obtains formatted ledger data and/or hash values in the cross-chain message. The formatted ledger data and/or hash value is then sent by the second relay component to the second blockchain node.

In some embodiments, the cross-chain intelligent contract for the first blockchain node is a first cross-chain intelligent contract and the service intelligent contract for the first blockchain node is a first service intelligent contract. The second block link point comprises a second cross-link intelligent contract (e.g., cross-link intelligent contract 1436 or 1526) and a second service intelligent contract (e.g., service intelligent contract 1434 or 1528). In some embodiments, the second cross-link intelligent contract receives the formatted ledger data and/or the hash value from the second relay component and determines whether the formatted ledger data is valid. In some embodiments, the second cross-chain intelligent contract may validate the formatted ledger data based on the received hash value. In some embodiments, the second cross-chain intelligent contract may calculate a hash value of the formatted ledger data and compare the calculated hash value to the received hash value. If the two hash values match, the second cross-chain intelligent contract may determine that the formatted ledger data is valid. If the two hash values do not match, the second cross-chain intelligent contract may determine that the formatted ledger data is invalid and discard the formatted ledger data. In some embodiments, the second cross-chain intelligent contract may determine whether the format of the formatted ledger data matches a predetermined data format. The second cross-chain intelligent contract may determine that the formatted ledger data is valid if the format of the formatted ledger data matches a predetermined data format. The second cross-chain intelligent contract may determine that the formatted ledger data is invalid if the format of the formatted ledger data does not match the predetermined data format.

If the formatted ledger data is valid, the second cross-chain intelligent contract may obtain ledger data from the formatted ledger data and send the obtained ledger data to the second service intelligent contract. In some embodiments, the second cross-chain intelligent contract may parse the formatted ledger data. In some embodiments, the second cross-chain intelligent contract may perform a predetermined parsing method on the formatted ledger data, for example, by converting the formatted ledger data to an original ledger data format. In some embodiments, the second cross-chain intelligent contract may obtain ledger data by converting formatted ledger data to an original ledger data format. In some embodiments, the second service smart contract receives ledger data and may make the ledger data available to users accessing the second blockchain network.

Fig. 26 is a schematic diagram of an example of modules of anapparatus 2600 in accordance with an embodiment of the present description.

Apparatus 2600 may be an example of an embodiment of a computer system configured for cross-chain communication in a blockchain based trusted system. Theapparatus 2600 may correspond to the above-described embodiment, and theapparatus 2600 comprises the following: a receivingmodule 2602, configured to receive a message including account data from a block link point; a determiningmodule 2604, configured to determine whether the ledger data is valid; agenerating module 2606, configured to generate formatted ledger data; and asending module 2608 for sending the cross-chain message to another cross-chain communication component.

The systems, apparatuses, modules, or units shown in the foregoing embodiments may be implemented by using a computer chip or entity, or may be implemented by using a product having a specific function. Typical embodiment devices are computers, which may be personal computers, laptop computers, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email receiving and sending devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

For the implementation of the functions and actions of each module in the device, reference may be made to the implementation of the corresponding steps in the aforementioned methods. Details are omitted here for simplicity.

Since the apparatus embodiments substantially correspond to the method embodiments, reference is made to the relevant description in the method embodiments for the relevant components. The apparatus embodiments previously described are merely examples. Modules described as separate components may or may not be physically separate, and components displayed as modules may or may not be physical modules, may be located in one location, or may be distributed across multiple network modules. Some or all of the modules may be selected based on actual needs to achieve the goals of the present solution. One of ordinary skill in the art will understand and appreciate embodiments of the present application without undue inventive effort.

Referring again to fig. 26, it may be interpreted to show the internal functional modules and structure of the cross-chain communication device. A cross-chain communication device may be an example of a computer system configured for cross-chain communication in a block chain based trusted system. In essence, the execution subject may be an electronic device comprising the following: one or more processors; one or more computer-readable memories configured to store executable instructions for the one or more processors. In some embodiments, the one or more computer-readable memories are coupled to the one or more processors and have stored thereon programming instructions that are executable by the one or more processors to perform the algorithms, methods, functions, processes, procedures, and programs described herein. Also provided herein are one or more non-transitory computer-readable storage media coupled to one or more processors and having instructions stored 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.

Also provided herein are systems for implementing the methods provided herein. The system includes one or more processors, and a computer-readable storage medium coupled to the one or more processors and having instructions stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with method embodiments provided herein.

Embodiments of the subject matter, the acts, and the operations described herein may be implemented in digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware, structures comprising the structures disclosed herein and their structural equivalents, or combinations of one or more of them. Embodiments of the subject matter described herein can be implemented as one or more computer programs, e.g., one or more modules of computer program instructions, encoded on a computer program carrier for execution by, or to control the operation of, data processing apparatus. For example, a computer program carrier may include one or more computer-readable storage media having instructions encoded or stored thereon. The carrier may be a tangible, non-transitory computer-readable medium such as a magnetic, magneto-optical disk or an optical disk, a solid state drive, a Random Access Memory (RAM), a read-only memory (ROM), or other media types. Alternatively or additionally, the carrier may be an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by the data processing apparatus. The computer storage media may be, or be part of, a machine-readable storage device, a machine-readable storage substrate, a random or serial access storage device, or a combination of one or more of them. Computer storage media is not a propagated signal.

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

The computer program may correspond to a file in a file system, but may not necessarily correspond to a file in a file system. The computer program may be stored in: a portion of a file that holds other programs or data, e.g., in one or more scripts in a markup language document; in a single file dedicated to the program in question; or in multiple coordinated files, such as files that store one or more modules, sub programs, or portions of code.

Processors for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a non-transitory computer-readable medium coupled to the processor for execution of a computer program.

The term "data processing apparatus" encompasses all types of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The data processing device may comprise special purpose logic circuitry, e.g., an FPGA (field programmable gate array), an ASIC (application specific integrated circuit), or a GPU (graphics processing unit). The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

The processes and logic flows described herein can be performed by one or more computers or processors executing one or more computer programs to perform operations by operating on input data and generating output. The processes and logic flows can also be performed by, and in particular by, special purpose logic circuitry, e.g., an FPGA, an ASIC, or a GPU, or by a combination of special purpose logic circuitry and one or more programmed computers.

A computer suitable for executing a computer program may be based on a general and/or special purpose microprocessor, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory and/or a random access memory. Elements of a computer may include a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or integrated in, special purpose logic circuitry.

Generally, a computer will also include or be operatively coupled to receive data from or transfer data to one or more storage devices. The storage device may be, for example, a magnetic, magneto-optical disk or optical disc, a solid state drive, or any other type of non-transitory computer-readable medium. However, a computer need not have such devices. Thus, a computer may be coupled to one or more storage devices, e.g., one or more memories located locally and/or remotely. For example, the computer may include one or more local memories as an integrated component of the computer, or the computer may be coupled to one or more remote memories located in a cloud network. In addition, a computer may also be embedded in another device, e.g., a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device such as a Universal Serial Bus (USB) flash drive, to name a few.

Components may be "coupled" to one another by being connected in communication with one another either directly or through one or more intermediate components, e.g., electrical or optical connections. These components may also be "coupled" to one another if one of the components is integrated into another component. For example, a storage component (e.g., an L2 cache component) integrated into a processor is "coupled" to the processor.

To provide for interaction with a user, embodiments of the subject matter described herein may be implemented on or configured to communicate with a computer having a display device, e.g., an LCD (liquid crystal display) monitor, for displaying information to the user and an input device, e.g., a keyboard and a pointing device, e.g., a mouse, a trackball, or a touch pad, by which the user can provide input to the computer. Other types of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and may receive any form of input from the user, including acoustic, speech, or tactile input. Further, the computer may interact with the user by sending and receiving documents to and from the device used by the user; for example, by sending a web page to a web browser on the user device in response to a request received from the web browser, or by interacting with an application (app) running on the user device, such as a smartphone or electronic tablet. Computers may also interact with users by sending text messages or other forms of messages to personal devices, such as smartphones running messaging programs, and receiving response messages from users.

The term "configured" is used herein with respect to systems, apparatuses, and computer program components. For a system of one or more computers configured to perform particular operations or actions, it is meant that the system has installed thereon software, firmware, hardware, or a combination thereof that, when executed, causes the system to perform the operations or actions. For one or more computer programs configured to perform specific operations or actions, it is meant that the one or more programs include instructions, which when executed by a data processing apparatus, cause the apparatus to perform the operations or actions. By dedicated logic circuitry configured to perform a particular operation or action is meant that the circuitry has electronic logic to perform the operation or action.

Although this document contains many specific implementation details, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular embodiments, as defined by the claims themselves. Certain features that are described herein in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings and recited in the claims in a particular order, this should not be understood as: it may be desirable to perform the operations in the particular order shown, or in sequence, or to perform all of the operations shown, in order to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it 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 following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not require the particular order shown, or sequence, to achieve desirable results. In some cases, multitasking parallel processing may be advantageous.

Claims (11)

1. A computer-implemented method for cross-chain communication, the method comprising:

receiving, by a first inter-chain communication component in a first blockchain network, a message comprising account data from a blockchain node in the first blockchain network;

determining, by the first cross-chain communication component, whether the ledger data is valid;

generating, by the first cross-chain communication component, formatted ledger data based on the ledger data in response to determining that the ledger data is valid; and

sending, by the first cross-chain communication component, a cross-chain message comprising the formatted ledger data to a second cross-chain communication component in a second blockchain network.

2. The computer-implemented method of claim 1, wherein the blockchain link points in the first blockchain network include service intelligence contracts and cross-chain intelligence contracts, the method further comprising:

receiving, by the cross-chain intelligent contract, a message from the service intelligent contract that includes the ledger data; and

sending the message to the first cross-chain communication component through the cross-chain smart contract.

3. The computer-implemented method of any preceding claim, wherein the first cross-link communication component comprises a relay component, and receiving, by the first cross-link communication component in the first blockchain network, a message comprising the ledger data from the blockchain node in the first blockchain network comprises:

receiving, by the first cross-link communication component from the cross-link smart contract for the blockchain node through the relay component, a message including the ledger data.

4. The computer-implemented method of claim 3, further comprising:

obtaining, by the relay component, the ledger data from the message; and

sending, by the relay component, the ledger data to a predictive teller.

5. The computer-implemented method of claim 4, wherein the first cross-chain communication component further comprises the oracle machine, and determining, by the first cross-chain communication component, whether the ledger data is valid comprises:

receiving, by the book agent, the ledger data from the relay component; and

determining, by the predictive agent, whether the ledger data is valid.

6. The computer-implemented method of claim 5, wherein generating, by the first cross-chain communication component, the formatted ledger data based on the ledger data in response to determining that the ledger data is valid comprises:

generating, by the predictive machine, the formatted ledger data based on the ledger data in response to determining that the ledger data is valid; and

sending, by the predictive engine, the formatted ledger data to the relay component.

7. The computer-implemented method of claim 6, wherein sending, by the first cross-chain communication component, the cross-chain message containing the formatted ledger data to the second cross-chain communication component in the second blockchain network comprises:

sending, by the relay component, a cross-chain message comprising the formatted ledger data to a second cross-chain communication component.

8. The computer-implemented method of claim 7, wherein the relay component is a first relay component, the second cross-link communication component comprises a second relay component, the blockchain node in the first blockchain network is a first blockchain node, the second blockchain network comprises a second blockchain node, the method further comprising:

receiving, by the second relay component, the cross-chain message from the first relay component;

obtaining, by the second relay component, the formatted ledger data from the cross-chain message; and

transmitting, by the second relay component, the formatted ledger data to the second block link point.

9. The computer-implemented method of claim 8, wherein the cross-chain intelligent contract is a first cross-chain intelligent contract, the service intelligent contract is a first service intelligent contract, the second block-chain link point comprises a second cross-chain intelligent contract and a second service intelligent contract, the method further comprising:

receiving, by the second cross-chain smart contract, the formatted ledger data from the second relay component;

determining, by the second cross-chain intelligent contract, whether the formatted ledger data is valid;

obtaining, by the second cross-chain smart contract, the ledger data from the formatted ledger data in response to determining that the formatted ledger data is valid; and

sending, by the second cross-chain intelligent contract, the obtained ledger data to the service intelligent contract.

10. A system for cross-chain communication, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executed by the one or more processors to perform the method of any of claims 1-9.

11. An apparatus for cross-chain communication, the apparatus comprising a plurality of modules to perform the method of any of claims 1 to 9.

Images