阅读说明：本技术 基于区块链的可信平台 (Trusted platform based on block chain ) 是由 栗志果 于 2020-11-25 设计创作，主要内容包括：本文公开了用于在基于区块链的可信系统中维护数据的方法、系统和装置,包括编码在计算机存储介质上的计算机程序。所述方法之一包括由服务计算机系统从客户端设备接收数据。由所述服务计算机系统将所述数据发送到基于区块链的可信系统。由所述服务计算机系统从所述基于区块链的可信系统接收与所述数据对应的凭证。由所述服务计算机系统将所述凭证发送到所述客户端设备。(Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for maintaining data in a blockchain based trusted system are disclosed. One of the methods includes receiving, by a service computer system, data from a client device. Sending, by the service computer system, the data to a block chain based trusted system. Receiving, by the service computer system, credentials corresponding to the data from the blockchain-based trusted system. Sending, by the service computer system, the credential to the client device.)

1. A computer-implemented method for maintaining ledger data, comprising:

Receiving, by a service computer system, data from a client device;

sending, by the serving computer system, the data to a block chain based trusted system;

receiving, by the service computer system, credentials corresponding to the data from the blockchain-based trusted system; and

sending, by the service computer system, the credential to the client device.

2. The computer-implemented method of claim 1, further comprising:

receiving, by the service computer system, a request from the client device to store the data, the request including the data.

3. The computer-implemented method of any of the preceding claims, further comprising:

after receiving the data from the client device, generating, by the service computer system, a request to store the data, the request including the data; and

sending, by the serving computer system, the request to store the data to the blockchain-based trusted system.

4. The computer-implemented method of any of the preceding claims, further comprising:

storing, by the service computer system, the data in a local memory of the service computer system.

5. The computer-implemented method of any of the preceding claims, further comprising:

after receiving the data from the serving computer system, calculating, by the blockchain-based trusted system, a hash value of the data;

generating, by the blockchain-based trusted system, ledger data comprising the hash value;

storing, by the blockchain-based trusted system, the ledger data in the blockchain-based trusted system;

generating, by the blockchain-based trusted system, credentials corresponding to the data; and

sending, by the blockchain-based trusted system, the credential corresponding to the data to the serving computer system.

6. The computer-implemented method of any of the preceding claims, wherein the ledger data further comprises metadata of the data.

7. The computer-implemented method of any of the preceding claims, wherein the credentials corresponding to the data comprise an identification of the ledger data or a digital signature of the blockchain-based trusted system.

8. The computer-implemented method of any of the preceding claims, further comprising:

After storing the data in a local memory of the service computing system, receiving, by the service computing system, a first request to verify the data;

retrieving, by the service computer system, the data from a local memory of the service computer system; and

sending, by the serving computer system, a second request to verify the obtained data to the blockchain-based trusted system, the second request including the obtained data.

9. The computer-implemented method of any of the preceding claims, wherein the first request to verify the data comprises the credential.

10. The computer-implemented method of any of the preceding claims, wherein the hash value is a first hash value, and the method further comprises:

in response to receiving a second request from the serving computing system to verify the obtained data, calculating, by the blockchain-based trusted system, a second hash value based on the obtained data;

determining, by the blockchain-based trusted system, whether the first hash value matches the second hash value; and

sending, by the blockchain-based trusted system, a verification result to the serving computer system, the verification result including a comparison of the first hash value and the second hash value.

11. The computer-implemented method of any of the preceding claims, further comprising:

after receiving the verification result from the blockchain based trusted system, determining, by the service computer system, based on the verification result, whether the first hash value and the second hash value match.

12. The computer-implemented method of any of the preceding claims, further comprising:

sending, by the service computer system, a notification to the client device indicating that the data has not been tampered with in response to determining, based on the verification result, that the first hash value matches the second hash value.

13. The computer-implemented method of any of the preceding claims, further comprising:

sending, by the service computer system, a notification to the client device indicating that tampering has occurred in response to determining, based on the verification result, that the first hash value does not match the second hash value.

14. A system for maintaining data, 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 executable by the one or more processors to perform the method of any of claims 1-13.

15. An apparatus for maintaining data, the apparatus comprising a plurality of modules for performing the method of any of claims 1 to 13.

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 a vehicle and pay for it using a mobile phone. As more and more people access the internet and conduct more and more transactions digitally, 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 described subject matter may include one or more features, either alone or in combination.

For example, in one embodiment, a method for maintaining data comprises: receiving, by a service computer system, data from a client device; sending, by the serving computer system, the data to a block chain based trusted system; receiving, by the service computer system, credentials corresponding to the data from the blockchain-based trusted system; and sending, by the service computer system, the credential to the client device.

In some embodiments, these general and specific aspects may be implemented using a system, method, or computer program, or any combination of systems, methods, and computer programs. Optionally, the foregoing and other described embodiments may each include one or more of the following:

in some embodiments, the method further comprises: receiving, by the service computer system, a request from the client device to store the data, the request including the data.

In some embodiments, the method further comprises: after receiving the data from the client device, generating, by the service computer system, a request to store the data, the request including the data; and sending, by the serving computer system, a request to the blockchain-based trusted system to store the data.

In some embodiments, the method further comprises: storing, by the service computer system, the data in a local memory of the service computer system.

In some embodiments, the method further comprises: after receiving the data from the serving computer system, calculating, by the blockchain-based trusted system, a hash value of the data; generating, by the blockchain-based trusted system, ledger data comprising the hash value; storing, by the blockchain-based trusted system, the ledger data in the blockchain-based trusted system; generating, by the blockchain-based trusted system, credentials corresponding to the data; and sending, by the blockchain-based trusted system, credentials corresponding to the data to the serving computer system.

In some embodiments, the ledger data further comprises metadata of the data.

In some embodiments, the method further comprises: the credentials corresponding to the data include an identification of the ledger data.

In some embodiments, the method further comprises: after storing the data in a local memory of the service computing system, receiving, by the service computing system, a first request to verify the data; retrieving, by the service computer system, the data from a local memory of the service computer system; and sending, by the serving computer system, a second request to the blockchain-based trusted system to verify the obtained data.

In some embodiments, the first request to validate the data comprises an identification of the ledger data.

In some embodiments, the hash value is a first hash value, and the method further comprises: in response to receiving a second request from the serving computing system to verify the obtained data, calculating, by the blockchain-based trusted system, a second hash value based on the obtained data; determining, by the blockchain-based trusted system, whether the first hash value matches the second hash value; and sending, by the blockchain-based trusted system, a verification result to the serving computer system, the verification result including a comparison of the first hash value and the hash value.

In some embodiments, the method further comprises: after receiving the verification result from the blockchain based trusted system, determining, by the service computer system, based on the verification result, whether the first hash value and the second hash value match.

In some embodiments, the method further comprises: sending, by the service computer system, a notification to the client device indicating that the data has not been tampered with in response to determining, based on the verification result, that the first hash value matches the second hash value.

In some embodiments, the method further comprises: sending, by the service computer system, a notification to the client device indicating that tampering has occurred in response to determining, based on the verification result, that the first hash value does not match the second hash value.

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 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 in accordance with 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 embodiments 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 networks and across chains 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 block chain based trusted platform 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 nodes, thereby reducing the likelihood of malicious actors compromising the data stored in the blockchain nodes. 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 may send the private key-based digital signature to the service system so that the service system can authenticate the digital signature using the 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 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 transaction-untamperable manner. 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) that contains the preceding block. 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 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 purporting to be a transaction 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 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 Practical Byzantine Fault Tolerant (PBFT) consensus, which will be described in further detail below.

Fig. 1 is a diagram illustrating an example of an environment 100 that may be used to perform embodiments herein. In some examples, environment 100 enables entities to participate in a federated blockchain network 102. The environment 100 includes computing systems 106, 108 and a network 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 with federated blockchain network 102, as well as communication within federated blockchain network 102. In general, network 110 represents one or more communication networks. In some cases, the computing systems 106, 108 may be nodes of a cloud computing system (not shown), or each of the computing 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 in federation 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 with federation blockchain network 102. For example, the computing 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). The computing 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, the federated blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing systems 106, 108 provide the nodes of the first and second entities, respectively, participating in the federated blockchain network 102.

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

In the depicted example, each participant system 202, 204, 206 is provided by or represents participant a, participant B, and participant C, respectively, and serves as a respective 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 the blockchain network 212 and enables the respective participants to participate in the blockchain network. In the example of fig. 2, a participant corresponds to each node 214. However, it is contemplated that a participant may operate multiple nodes 214 within the blockchain network 212, and/or that multiple participants may share a single node 214. In some examples, the participant systems 202, 204, 206 communicate with or through the blockchain network 212 using a protocol (e.g., hypertext transfer protocol secure (HTTPS)) and/or using Remote Procedure Calls (RPCs).

The nodes 214 may have different degrees of participation within the blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miners' nodes that add tiles to the blockchain 216), while other nodes 214 do not participate in the consensus process. As another example, some nodes 214 store a full copy of blockchain 216, while other nodes 214 store only partial copies of blockchain 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 store full copies 216', 216 ", and 216"', respectively, of block 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 blocks are 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., 4KB) 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 the trusted application, the processor operates in a so-called enclave mode when accessing data stored in the enclave. Operation in enclave mode would perform an additional hardware check for each memory access. In software protection 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 (e.g., via a key exchange process, such as elliptic curve Diffie-hellman (ecdh)) an asymmetric cryptographic key (e.g., a public and private key pair) to a node executing a trusted execution environment 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 a system 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. The system 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 a blockchain access layer 314, participating nodes (e.g., nodes 308-1, 308-2, 310-1, and 310-2), and a blockchain platform layer 316. In some embodiments, blockchain access layer 314 may include a communication interface that allows entities external to blockchain-based trusted platform 312 to communicate with participating nodes of blockchain-based trusted platform 312. The blockchain 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, the blockchain 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 trusted platform 312.

The participating nodes of blockchain based trusted platform 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 trusted platform 312 also includes third party blockchain nodes, such as nodes 310-1 and 310-2. In some embodiments, third party blockchain nodes 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 trusted platform 312 is shown to include nodes 308-1, 310-1, and 310-2. Blockchain-based trusted platform 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 trusted platform 312.

As previously described, blockchain access layer 314 may include a communication interface that allows entities external to blockchain-based trusted platform 312 to communicate with participating nodes of blockchain-based trusted platform 312. In the illustrated example, blockchain 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 a blockchain based trusted platform 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 trusted platform 312. Service systems 306-1 through 306-6 may be configured to provide services to user 302 by accessing a blockchain based trusted platform 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 trusted platform 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 trusted platform 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 a real estate agent, a broker, a commercial bank, a third party escrow, a police department, a government agency, and so forth. In some embodiments, a subsystem that includes at least one blockchain node of blockchain-based trusted platform 312 may be referred to as a node subsystem, while a subsystem that does not include any blockchain node of blockchain-based trusted platform 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 trusted platform 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 trusted platform 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 by user 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 trusted platform 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 node 308-2) may generate ledger data based on data received from a user (e.g., user 302) and record the ledger data into a blockchain stored in the blockchain node. 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 blockchain data 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 as system 300 of FIG. 3, may perform process 400.

Process 400 begins at step 410, where user 402 sends data for recording to service system 404. In some embodiments, user 402 may send a request to service 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.).

The user 402 may be the user 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).

At step 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 intelligent contracts for processing data or requests received from users 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 to service system 404 along with the data, such that service system 404 may compare the received user identification to the user identifications of authorized users stored in service 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.

At step 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, and wherlpool (whilpool) 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, service system 404 may generate a hash value based on data received from user 404 and a user identification of user 404.

At step 416, service system 404 stores the data received from user 402 in a local memory of service system 404. In some embodiments, the service 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 the service system 404 may be generated or expanded for better availability, partition tolerance, flexibility, and cost. For example, the local storage subsystem of the service 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 the storage 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, the service 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. The service system 404 may include a second storage device, such as a NAS (network attached storage) device, for storing data with a lower access frequency.

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

In some embodiments, the ledger data includes the hash value generated at step 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, the service system 404 may encrypt the ledger data according to a predetermined encryption function or algorithm. In some examples, service system 404 may encrypt the ledger data using a public key of blockchain-based trusted platform 406 and send the encrypted ledger data to blockchain-based trusted platform 406 to decrypt the encrypted ledger data using its private key.

At step 420, upon receiving ledger data from service system 404, blockchain-based trusted platform 406 stores the ledger data including the hash value in blockchain-based trusted platform 406. In some embodiments, blockchain based trusted platform 406 may store ledger data in one or more participating nodes of blockchain based trusted platform 406. In some embodiments, one or more participating nodes of blockchain based trusted platform 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 account data. After consensus is achieved between the consensus nodes, the blockchain-based trusted platform 406 may record ledger data in blockchains stored in one or more participating nodes of the blockchain-based trusted platform 406.

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

At step 422, the blockchain-based trusted platform 406 generates credentials 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 the ledger data and/or a digital signature of the blockchain-based trusted platform 406 that was generated based on the ledger data using a private key of the blockchain-based trusted platform 406. In some embodiments, the credential may uniquely identify the account data.

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

At step 426, service system 404 sends the logging results to user 402 after receiving the credentials from blockchain-based trusted platform 406. 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 trusted platform 406 based on the blockchain. In some examples, service system 404 may verify the digital signature using a public key of trusted platform 406 based on the blockchain. If the digital signature is valid, the service system 404 may send the credentials in the logging result to the user 402 and notify 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, or service system 404 may notify user 402 that the data record is not complete.

Fig. 5 depicts an example of a blockchain data 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 as system 300 of FIG. 3, may perform process 500.

Process 500 begins at step 510, where user 502 sends a request to service system 504 for authentication data. The user 502 may be the user 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 logging process similar to process 400 of fig. 4. In this example, ledger data may be generated by service system 504 and recorded in a blockchain-based trusted platform 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 the service 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, hubbe 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 trusted platform 506 and sent to the user 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 trusted platform 506 that is generated based on ledger data using a private key of blockchain based trusted platform 506.

At step 512, the service system 504, after receiving the request to validate the data, obtains the data from the local memory of the service system 504. In some embodiments, the local memory of service 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.

At step 514, service system 504 calculates a hash value based on the data obtained at step 512. In some embodiments, the hash value may be calculated by the service system 504 based on the same cryptographic hash function or algorithm used to calculate the hash value in the previous data record processing.

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

At step 518, after receiving the hash value from service system 504, blockchain-based trusted platform 506 compares the received hash value to hash values previously stored in blockchain-based trusted platform 506. In some embodiments, blockchain based trusted platform 506 may receive encrypted hash values and/or credentials from service system 504. In some examples, the encrypted hash value and/or credential may be encrypted with a public key of blockchain-based trusted platform 506. The blockchain based trusted platform 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 trusted platform 506 may obtain ledger data from local memory of blockchain based trusted platform 506 in accordance with credentials received from service system 504 and obtain a hash value in the ledger data. In some embodiments, blockchain-based trusted platform 506 may obtain ledger data from one or more participating blockchain nodes of blockchain-based trusted platform 506 in accordance with the credentials and obtain a hash value in the ledger data.

At step 520, block chain based trusted platform 506 sends the verification result to service system 504. In some embodiments, the verification result includes a comparison of the received hash value in step 518 with the hash value in the hash data. In some embodiments, the verification result may also include a digital signature of trusted platform 506 based on the blockchain. In some examples, a digital signature of blockchain-based trusted platform 506 may be generated from at least one of the two hash values using a private key of blockchain-based trusted platform 506.

At step 522, service system 504 sends a verification response to user 502 after receiving the verification result from blockchain-based trusted platform 506. 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 trusted platform 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 in service system 504 has not been tampered with. Service system 504 may also include the data in a verification response and send a verification response to user 502 indicating that the data has not been tampered with. If the two hash values do not match, service system 504 may notify user 502 in a verification response that the data may have been tampered with.

Fig. 6 depicts an example of a blockchain data 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 perform process 600.

Process 600 begins at step 610, where user 602 sends data for recording to service system 604. In some embodiments, the user 602 may send a request to the service 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.

The user 602 may be the user 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, the user 602 may include a web browser and a software application for providing various functions of a 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.

At step 612, service system 404 triggers data logging after receiving data from user 602. In some embodiments, the service system 604 may automatically trigger data recording in response to receiving data or a request from the user 602. In some examples, service system 604 may include an intelligent contract for processing data or requests received from users 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, the service system 604 may verify the identity of the user 602 after receiving data from the user 602. In some examples, user 602 may send the user identification to serving system 604 along with the data, such that serving system 604 may compare the received user identification to the user identifications of authorized users stored in serving system 604. If it is determined that user 602 is an unauthorized user, service system 604 may ignore the request from user 602 and discard the data. If it is determined that user 602 is an authorized user, service system 604 may continue to process the received data.

At step 614, the service system 604 stores the data received from the user 602 in a local memory of the service system 604. In some embodiments, the service 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 the service system 604 may be generated or expanded for better availability, partition tolerance, flexibility, and cost. For example, the local storage subsystem of the service 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 the storage 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, the service 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. The service system 604 may include a second storage device, such as a NAS device, for storing data that has a lower frequency of access.

At step 616, service system 604 sends a request to record data to block chain based trusted platform 606. In some embodiments, blockchain based trusted platform 606 may be implemented as blockchain based trusted system 312 of fig. 3. In some embodiments, the request includes data received from user 602.

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

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

At step 618, blockchain-based trusted platform 606 computes a hash value based on the data received from service system 604. In some embodiments, the blockchain based trusted platform 606 may receive encrypted data from the service system 604. In some examples, the encrypted data may be encrypted with a public key of the blockchain-based trusted platform 606. The blockchain based trusted platform 606 may decrypt the encrypted data using a private key paired with a 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, hurpu hash function, etc.). In some examples, the blockchain-based trusted system 606 may apply a predetermined hash function to data received from the service system 604 and generate a hash value for the data.

At step 620, blockchain-based trusted system 606 stores the hash value generated at step 618. In some embodiments, blockchain-based trusted system 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 from user 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 trusted platform 606 may store ledger data in one or more participating nodes of blockchain-based trusted platform 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 trusted platform 606 may record ledger data in blockchains stored in one or more participating nodes of blockchain-based trusted platform 606.

At step 622, trusted platform 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 trusted platform 606 that was generated based on the ledger data using a private key of the blockchain-based trusted platform 606. In some embodiments, the credentials may be configured to uniquely identify the data and ledger data.

At step 624, the blockchain-based trusted platform 606 returns the credentials to the service 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 trusted platform 606, such that the service system 604 may verify the digital signature using a public key of the blockchain-based trusted platform 606.

At step 626, after receiving credentials from the blockchain based trusted platform 606, the service system 604 sends the recorded results to the user 602. In some embodiments, the recorded result comprises a credential. In some embodiments, the recording results include a notification to the user 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 trusted platform 406 based on the blockchain. In some examples, service system 604 may verify the digital signature included in the credential using a public key of trusted platform 606 based on the blockchain. If the digital signature is valid, the service system 604 may send the credentials in the logging result to the user 602 and notify the user 602 in the logging result that the data logging is complete. If the digital signature is invalid, the service system 604 may not send the credential to the user 602 and notify the user 602 that the data record is not complete.

Fig. 7 depicts an example of a blockchain data 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 perform process 700.

Process 700 begins at step 710, where user 702 sends a request to service system 704 for authentication data. User 702 may be user 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 the service system 704 and recorded in the blockchain-based trusted platform 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 the service 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 trusted platform 706 and sent to the user 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 trusted platform 706 that is generated based on the ledger data using a private key of the blockchain based trusted platform 706.

At step 712, service system 704 obtains data from a local memory of service system 704 after receiving a request from user 702. In some embodiments, the local storage of the service 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.

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

At step 716, blockchain-based trusted platform 706 computes a hash value based on the data received from service system 704. In some embodiments, the hash value may be computed by the blockchain based trusted platform 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 trusted platform 706 may receive encrypted data and/or credentials from the service system 704. In some examples, the encrypted data and/or credentials may be generated using a public key of the blockchain-based trusted platform 706. The blockchain based trusted platform 706 may decrypt the encrypted data using a private key paired with a public key and obtain data and/or credentials.

At step 718, the blockchain based trusted platform 706 compares the computed hash value to hash values previously stored in the blockchain based trusted platform 706. In some embodiments, blockchain based trusted platform 706 may obtain ledger data from local memory of blockchain based trusted platform 706 in accordance with credentials received from service system 704 and obtain a hash value in the ledger data. In some embodiments, blockchain-based trusted platform 706 may obtain ledger data from one or more participating blockchain nodes of blockchain-based trusted platform 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 trusted platform 706 generates a verification result based on a comparison of the two hash values.

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

After receiving the verification result from blockchain based trusted platform 706, service system 704 sends a verification response to user 702 at step 722. In some embodiments, the service 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 trusted platform 706 based on the blockchain. If the digital signature is determined to be invalid, the service system 704 may ignore the verification result. If the digital signature is determined to be valid, the service system 704 may continue to process the verification result.

In some embodiments, the service system 704 determines whether the two hash values match based on the verification result. If the two hash values match, then service system 704 may determine that the data stored in service system 704 has not been tampered with. Service system 704 may also include the data in a verification response and send a verification response to user 702 indicating that the data has not been tampered with. If the two hash values do not match, service system 704 may notify user 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 trusted platform 800 according to embodiments herein. In some embodiments, blockchain based trusted platform 800 may be implemented as blockchain based trusted platform 312 of fig. 3. A blockchain based trusted platform 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, trusted platform 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, a second application 804, through an nth application 806 that utilize the functionality of a trusted time module 808, a trusted identity module 810, and a trusted computing module 812 in a trusted services layer 816. In some embodiments, the applications 802, 804, 806, as well as the trusted time module 808, the trusted identity module 810, and the trusted computing module 812 may be implemented in each participating blockchain node of a blockchain based trusted platform.

The blockchain based trusted platform 800 solves the above problems by providing a suite of service applications that utilize the functionality of the trusted time module 808, the trusted identity module 810, and the trusted computing 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 trusted platform 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 trustworthiness of data generated by online applications providing legal services.

The blockchain based trusted platform 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 trusted time module 808 and/or the trusted identity module 810. Trusted platform 800 uses trusted computing 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 trusted or verified timestamps, trusted identity module 810 provides trusted or verified identity information, and trusted computing module 812 ensures the trustworthiness of the data recorded in the relevant blockchain.

In some embodiments, the functionality of the modules 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 an operating system 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 block chain based trusted platform 800 produces the following technical effects: service-related data provided by service applications supported by blockchain-based trusted platform 800 has a higher degree of trust (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 a system 900 for online transactions according to embodiments herein. In the example shown, system 900 includes a block chain based trusted platform 902. In some embodiments, the blockchain based trusted platform may be implemented as blockchain based trusted platform 312 of fig. 3 or blockchain based trusted platform 800 of fig. 8.

In some embodiments, trusted platform 902 may be accessed over a network 914, such as the Internet. User 924 accesses trusted platform 902 using client terminal 922, which client terminal 922 may be, for example, a mobile phone, a personal computer, or any computing device that may connect to network 914. In some examples, trusted platform 902 provides limited functionality to users that are not already registered with platform 902.

When registered at the platform 902, the user has a user Identification (ID) that is used to identify the user 924 when the user 924 uses the tools and services of the platform 902. Each registered user has an account associated with platform 902 and may access the functionality of platform 902 after logging into the account. In some examples, user 924 may register with platform 902 by providing personal information such as the user's phone number and email address. In some examples, user 924 may register with platform 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 with modules 906, 908, 910. When user 924 accesses functionality of trusted platform 902, the user may provide additional information to trusted platform 902, and trusted platform 902 associates the additional information with the user account.

For example, user 924 may provide a mobile phone number so that user 924 may receive a message from trusted platform 902 on a mobile phone. User 924 may provide payment account information so that user 924 may pay for services on trusted platform 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: (i) 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, a user 924 accesses an internet evidence collection web browser 904 to search for and view web pages on the internet 914. A client component (not shown) of the web browser executes at the client terminal 922 and provides a user interface for displaying web pages to the user 924 and for receiving user instructions for processing the web pages (e.g., clicks for controlling navigation between the web pages).

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

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

Thus, whenever an event occurs in which the user 924 performs a predetermined type of action, such as providing a URL to the web 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, the web browser 904 performs the action requested by the user 924, and also invokes the trusted time module 906 to obtain a verified timestamp indicating the time at which the action was performed or the time at which the event occurred. The web browser 904 calls the trusted computing module 910 to generate a snapshot of the event, where the snapshot may be in the format of a record, including: the identity of the user 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 trusted computing module 910 generates a hash value for the record and adds a chunk including the record and the hash value to a blockchain 912, the blockchain 912 storing records associated with the user 924.

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

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

Fig. 10 is a diagram illustrating an example of a system for providing trusted time according to embodiments herein. In some embodiments, the trusted 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 trusted identity module 1100 maintains a user account database 1102, the user account database 1102 including information about registered users provided by the registered users themselves. The trusted identity module 1100 also accesses other databases to verify the account information provided by the user. For example, the trusted identity module 1100 may access the government ID database 1104 to verify the accuracy of the government ID provided by the user. If the trusted identity module 1100 determines that the government ID provided by the user matches the name or telephone number of another user listed in the government ID database 1104, the trusted identity module 1100 may generate an alert message indicating a possible fraudulent identity. In some embodiments, the trusted identity module 1100 may have access to a database 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 trusted identity module 1100 may access a database 1108 related to accounts of users using the online payment service. The trusted identity module 1100 may access a database 1110 relating to accounts of users using social media services provided on a trusted platform. The trusted identity module 1100 may access a database 1112 related to accounts of users using communication services provided on the trusted platform.

The trusted identity module 1100 may access a database 1118 associated with the user's account with an online shopping service that allows the user to shop for products online. The trusted identity module 1100 may access a database 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 trusted identity module 1100 may access a biometric database 1114, the database 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 trusted identity 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 trusted identity module 1100.

In some embodiments, the various 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 a system 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) in 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, block link points 1210 and 1230 operate using both TEE and REE. As shown, virtual machines 1214 and 1234 operate using TEE, as do caches 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 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 memory set (e.g., 4KB) 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. The verified record of data derived from events associated with multiple steps of a transaction is much more reliable than a verified record based solely 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 modifying the data fraudulently in each step of the process is very low.

Fig. 13 is a diagram illustrating an example of an architecture 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 trusted platform 312 of figure 3 or blockchain based trusted platform 800 of figure 8. In the example shown, the security architecture 1300 includes the following components: an application security component 1310, a data security component 1320, a protocol and algorithm security component 1330, and a security management component 1340.

In some embodiments, application security component 1310 may include functionality such as identity management functionality 1312, access control functionality 1314, and smart contract auditing functionality 1316. In some embodiments, the identity 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-linked points and between the block-linked points 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 a handshake procedure. In some embodiments, the access control function 1314 may be configured to support access control to a user account. In some examples, the access 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. Smart contract 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.

The data security component 1320 includes a storage security function 1322 and a transport security function 1324. In some examples, the storage 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. Storage security function 1322 may provide a data synchronization mechanism between block link points to ensure proper replication of data and provide a data archive tool for data archiving and backup. The transport security function 1324 may support private key-based transaction signatures to prevent tampering with transaction content. The transport security function 1324 may support a hashing mechanism that improves the data security of transactions recorded in the blockchain. The transmission 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 and algorithm security component 1330 includes intelligent contract security function 1332, cryptographic algorithm security function 1334, and key security function 1336. In some embodiments, smart contract security function 1332 may provide support for code security, run mechanism security, service logic security, and user security. In some examples, smart contract security functions 1332 may support loading and executing smart contracts using virtual machines. 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, cryptographic algorithm security function 1334 may provide practical security for encryption, signature, and hash algorithms and functions. In some examples, cryptographic algorithm security function 1334 may support multiple sets of cryptographic suites as required by different service scenarios. Table 1 below shows an example of an explanation of a cipher suite according to an embodiment 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.

The security management component 1340 includes security audit functions 1342, supervisory support functions 1344, and configuration management functions 1346. In some examples, the security 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, the configuration 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 a cross-chain communication system 1400 according to embodiments herein. In some embodiments, a cross-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 the cross-chain system 1400 to ensure data security during data transmission and storage in and between the two blockchain networks. In the example shown, the cross-chain system 1400 includes a first blockchain network 1410 and a second 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 first blockchain link point 1412 and a first cross-chain communication component 1418, and the second blockchain network includes a second blockchain link point 1432 and a second cross-chain communication component 1438. Note that block 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 between block link point 1412 and cross-chain communication component 1438, and cross-chain communication component 1438 is configured to allow communication between block link point 1432 and cross-chain communication component 1418. In this manner, data communication can be achieved between two blockchain nodes 1412 and 1432 in different blockchain networks 1410 and 1430 using cross-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, block link points 1412 include service intelligence contracts 1414 and cross-chain intelligence contracts 1416, while block 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 includes cross-chain relay component 1420 and prolog engine 1422, while cross-chain communication component 1438 includes cross-chain relay component 1440 and prolog engine 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 to cross-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 a cross-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 as system 1400 of FIG. 14, can perform process 1500. In some embodiments, the blockchain networks 1510 and 1520 may be implemented as blockchain 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, and blockchain network 1520 includes blockchain dots 1508 and cross-chain communication components 1506. As shown, service intelligence contracts 1512 and cross-chain intelligence contracts 1514 execute on block link points 1502 of block chain network 1510, while service intelligence contracts 1528 and cross-chain intelligence contracts 1526 execute on block link points 1508 of block chain network 1520. Cross-chain relay component 1516 and prolog engine 1518 are implemented in cross-chain communication component 1504, while cross-chain relay component 1524 and prolog engine 1522 are implemented in cross-chain communication component 1506.

Process 1500 begins at step 1530, where service intelligence contract 1512 sends a message that includes ledger data to cross-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.

At step 1532, the cross-chain smart contract 1514 sends a message including ledger data to the cross-chain relay component 1516 after receiving the message. In some embodiments, cross-chain smart 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 the cross-chain intelligence contract 1514.

At step 1534, the cross-link relay component 1516 sends the ledger data to the oracle 1518. In some embodiments, cross-link relay component 1516 obtains ledger data from messages received from cross-link smart contracts 1514. In some embodiments, cross-link 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 a president machine 1518.

At step 1536, statement interpreter 1518 validates the ledger data and determines whether the ledger data is valid. In some embodiments, language book machine 1518 may validate ledger data based on ledger proofs. In some examples, the oracle 1518 may verify a digital signature included in the ledger proof. If the digital signature is valid, the predictive engine 1518 may determine that the ledger data is valid and continue processing the ledger data. If the digital signature is invalid, the book machine 1518 may discard the account data.

At step 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.

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

At step 1542, the cross-chain relay component 1516, upon receiving the formatted ledger data from the talker 1518, sends a cross-chain message to the cross-chain relay component 1524. In some embodiments, cross-chain relay component 1516 may generate a cross-chain message 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.

At step 1544, cross-chain relay component 1524 sends the formatted ledger data to cross-chain smart 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 from cross-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-chain intelligent contract 1526 along with the formatted ledger data.

At 1546, cross-chain smart contract 1526 validates the formatted ledger data and determines whether the formatted ledger data is valid. In some embodiments, cross-chain smart contracts 1526 may validate formatted ledger data based on hash values received from cross-chain relay component 1524. In some examples, cross-chain intelligent 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-chain intelligent contract 1526 may determine that the formatted ledger data is valid. If the two hash values do not match, cross-chain intelligent contract 1526 may determine that the formatted ledger data is invalid and discard the formatted ledger data. In some embodiments, cross-chain intelligent contracts 1526 may determine whether the format of the formatted ledger data matches a predetermined data format. Cross-chain intelligent 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-chain intelligent 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-chain smart contract 1526 parses the formatted ledger data. In some embodiments, cross-chain smart 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-chain smart contracts 1526 may obtain ledger data by converting formatted ledger data to an original ledger data format.

At step 1550, cross-chain smart contract 1526 sends ledger data to service smart 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 having access to blockchain 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 of block link points 1602 may include an intelligent contract data cache 1606 and a block chain database 1610. Intelligent contract data cache 1606 may be used to store variable data managed by intelligent contracts, while blockchain 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, including blockchain database 1612, state database 1618, and extension database 1624. Block database 1612 may store block chain data including block header 1614 and block body 1616. State database 1618 may store state information related to blockchain data, including state tree 1620 and storage tree 1622. The extension database 1624 may store intelligent contract data that includes a plurality of intelligent contract pools 1626 and metadata 1628 associated with the plurality of intelligent contract pools 1626.

Blockchain 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 may respectively execute each instruction of the intelligent contract and produce a result indicating an 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 values 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 in block database 1612. Finally, the final result of the execution (i.e., the output) is also recorded in tile 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 smart contract data cache 1606 and blockchain 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 intelligent contract 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 intelligent contract data cache 1606 and blockchain database 1610 to link variable data and non-variable data associated with the same document. Transaction hashes may be stored in the intelligent contract data cache 1606 and blockchain 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 in blockchain database 1610. The encryption key may comprise a symmetric key used to encrypt the document data before it is stored on the blockchain in blockchain database 1610. The encryption keys may also include encryption keys associated with users of the blockchain based trusted platform 300 as described in the description of figure 3. The data stored in blockchain 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 the blockchain 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 smart contract data cache 1606 under the same data structure. In general, the transaction hash may be used to link variable data stored in the intelligent contract data cache 1606 with immutable blockchain data associated with the same order stored in the blockchain 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 intelligent contract data cache 1606 and encrypted documents stored in the blockchain database 1610. The transaction hash of the encrypted document stored in the blockchain database 1610 may be stored with the variable data under the same data structure in the intelligent contract 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 smart contract 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 from blockchain database 1610 and decrypt the encrypted data using the symmetric key.

In some embodiments, the variable data in the intelligent contract 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., 5GB), a cache-miss state may occur. A cache miss refers to a state in which no data needed for processing by a component or application can be found in the 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 of intelligent contract pools 1626 may be created in blockchain database 1610 to store at least a portion of the variable data managed by the intelligent contracts in intelligent contract data cache 1606. At least a portion of the variable data may then be moved from the high-cost cache storage to the blockchain database 1610 to reduce overall storage costs and mitigate cache miss conditions.

In some embodiments, a new intelligent contract address may be added to configuration file 1604 by block link point 1602 to create a corresponding intelligent contract. When executing the configuration 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 the expansion database 1624.

In some embodiments, the data stored in intelligent contract pool 1626 is also recorded in block 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 the intelligent 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 each intelligent contract pool 1626. For example, for a document with a document ID of 000001, its md3 hash value is 769924EADBBF6F72C6581377419FCB 77. 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 a md3 hash value of 4DE1F0F6DA993FC4AB439CDCA5E084F 6. 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 data cache 1606, intelligent contract pool 1626, and blockchain 814 can be easily located when queried from them. To link documents associated with the same order stored in different intelligent 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 different intelligent 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 in tile 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 each intelligent 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 trusted platform 1702 according to embodiments herein. The blockchain based trusted platform 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 trusted platform 1702 provides services to one or more contracting parties (e.g., contracting party a 1768 and contracting party B1772) such that contracts negotiated and signed by the contracting parties may be securely stored (e.g., in blockchain database 1610 and intelligent contract data cache 1606, as described in the description of fig. 16). In some embodiments, the blockchain based trusted platform 1702 may also provide services to other entities associated with the contract, such as one or more banks 1772, one or more judicial agencies 1774, and one or more government agencies 1776, over a network 1764 (e.g., the internet).

The contractor a 1768 may be a buyer purchasing services or goods from the contractor B1770. Contractor a 1768 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 a 1768 or the contracting party B1770 may send a copy of the contract to the blockchain-based trusted platform 1702 for record keeping, e.g., by storing the copy of the contract in the blockchain database 1610 and/or the intelligent contract data cache 1606.

The bank 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 trusted platform 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 trusted platform 1702.

Judicial agencies 1774 may resolve disputes during contract execution. For example, the contracting party a 1768 may default to payment to the contracting party B1770. The judicial agency 1774 may issue court orders and adjudications to identify the contractor a 1768 as a debtor and the contractor B1770 as a creditor. Judicial authority 1774 may send a copy of the court order to blockchain-based trusted platform 1702 for record keeping, for example, by storing a copy of the court order in blockchain database 1610 and/or intelligent contract data cache 1606. The contractor B1770 may then send a request to the block chain based trusted platform 1702 to collect the decision amount from the contractor a 1768. After verifying that the request is associated with a real court order stored in the blockchain, the blockchain based trusted platform 1702 may identify one or more bank accounts having a total balance associated with the contractor a 1768 that is not less than the decision amount and transfer the decision amount from the one or more 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 contracts, such as determining whether the contract complies with laws, regulations or regulations, and evaluating and collecting customs, taxes and fees associated with imports and exports of goods. Government agency 1776 may also be responsible for detecting fraudulent activity associated with the contract. Government agency 1776 may access and retrieve contracts stored in block chain based trusted platform 1702. Block chain based trusted platform 1702 may provide services to government agencies 1776, such as checking for potential violations or fraud in contracts.

The blockchain based trusted platform 1702 interacts with a blockchain network 1756 that includes a plurality of blockchain nodes 1758 to securely record contract information in the blockchain database 1610 and the intelligent contract data cache 1606. As described above, intelligent contract data cache 1606 may store variable data in the form of intelligent contract data, and blockchain 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 trusted platform 1702 includes an application layer 1704, a trusted services layer 1710, a blockchain layer 1718, an infrastructure layer 1738, and a tool platform 1744.

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

The trusted services layer 1710 may provide trusted blockchain services to the application layer 1704 to ensure that data recorded on the blockchain is trusted. The trusted service layer 1710 may include a trusted identity module 1712, a trusted time module 1714, and a trusted computing module 1716.

Blockchain layer 1718 may provide core functionality for blockchain based trusted platform 1702 and may include API 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 trusted platform 1702. The API layer 1720 may include: a record input interface 1722 for receiving data to be recorded on the blockchain; a record output interface 1724, configured to output a result of recording data on the blockchain; an authentication input interface 1726 for receiving data to be authenticated based on the data recorded on the blockchain; a verification output interface 1728 for outputting a result of verifying data based on the data recorded on the blockchain; a data history search interface 1730 for querying data recorded on the blockchain; the transaction 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 organization 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. The base services layer 1736 may include modules that provide basic functionality for the blockchain based trusted platform 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 verification module may be to verify one or more ZKPs based on the input proof.

Infrastructure layer 1738 may provide computing and communication functionality for block chain based trusted platform 1702. Infrastructure layer 1738 may provide cloud services such as public cloud 1740 and private 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 trusted platform 1702. The tool platform 1744 may include a statistics display tool 1746, a status monitoring tool 1748, a log collection tool 1750, a performance analysis tool 1752, and a network topology tool 1754.

Fig. 18 depicts an example of a process 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 the process 1800 in the context of other figures herein. However, it should be understood that the process 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 of process 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 the 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, and record input parameter 3. The value of the input parameter 1 is recorded as x. The value of input parameter 2 is recorded as y. The value of the input 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 bit stream 100011011001 is received, it may be determined that the recording input parameter 1, the recording 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 that the respective recording input parameter employs. 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 input parameters and satisfies the input format of the one or more record input parameters, then it is determined that the raw ledger data satisfies the record rule, and process 1800 proceeds to 1806. Otherwise, it is determined that the original ledger data does not satisfy the logging rules, and process 1800 proceeds to 1812.

At 1806, the original ledger data may be recorded on the blockchain. 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 may 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 why the original ledger data did not satisfy the logging rules.

Fig. 19 depicts an example of a process 1900 for validating ledger data according to embodiments herein. Process 1900 may be performed by a blockchain-based trusted platform (e.g., blockchain-based trusted platform 1702) implemented on one or more blockchain nodes or on one or more computing devices communicatively coupled to the one or more blockchain nodes. For clarity of presentation, the following description generally describes process 1900 in the context of other figures herein. However, it should be understood that process 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 of process 1900 may be performed in parallel, combined, in a loop, 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 values 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, the ledger data includes one or more validation input parameters defined in the validation rules and accepted by the 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 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 the 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, the 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. 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.

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, and process 1900 proceeds to 1906. Otherwise, it is determined that the original ledger data does not satisfy the validation rules, and process 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 can 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 includes internet 2002, private network 2004, and gateways 2006a and 2006 b. In some embodiments, the gateways 2006a and 2006b are two different gateways, where the gateway 2006a processes data sent from the internet 2002 to the private network 2004 and the gateway 2006b processes data sent from the private network 2004 to the internet 2002. In some embodiments, gateway 2006a and gateway 2006b are the same gateway. In some embodiments, the only physical network path between the internet 2002 and the private network 2004 is via gateways 2006a and 2006 b.

In some embodiments, a first plurality of blockchain nodes (e.g., blockchain point 12008 a through blockchain point 52008 e) of the first blockchain network are connected by the internet 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 12010 a through blockchain point 52010 e) of the second blockchain network are connected by private network 2004. The second plurality of blockchain nodes may be associated with, for example, a judicial agency, a financial agency, a government agency, etc. In some embodiments, each blockchain node of the first and second plurality of blockchain nodes may access the blockchain based trusted platform 1702 via the API layer 1720.

In some embodiments, the gateway 2006a includes at least one network device and at least one server. At least one network device may be interconnected with a router of the internet 2002 and a router of the private network 2004. In some embodiments, the gateway 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, the gateway 2006a employs a single fiber rather than a pair of fibers to connect at least one network device of the gateway 2006a and a router of the internet. The gateway 2006a may employ another single fiber to connect at least one network device of the gateway 2006a and a router of a private network. At least one network device of the gateway 2006a may be equipped with an optical receiver for connecting to a single fiber of the internet 2002 and an optical transmitter for connecting to a single fiber of the private network 2004, thereby allowing data transmission in a single direction from the internet 2002 to the private network 2004. In some embodiments, at least one network device of the gateway 2006a employs an optical receiver for connecting to a single optical fiber of the private network 2004 and an optical transmitter for connecting to a single optical fiber of the internet 2002, thereby allowing data transmission in a single direction from the private network 2004 to the internet 2002.

In some embodiments, at least one server of gateway 2006a stores ciphertext 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 ciphertext 2012 from at least one server of gateway 2006 a. In some embodiments, at least one server of gateway 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 of gateway 2006 b.

Fig. 21 depicts an example of a process 2100 for cross-chain and cross-network data transfer according to embodiments herein. At a high level, the participants of process 2100 include a first tile link point 2008a, a gateway 2006a, and a second tile link point 2010 a. Process 2100 may be performed to send data from first blob link point 2008a to second blob link point 2010 a. As discussed in the description of fig. 20, a first blockchain point 2008a is associated with and connected to other blockchain points of the first blockchain network through the internet 2002, and a second blockchain point 2010a is associated with and connected to other blockchain points of the second blockchain network through the private 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 first chunk 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 first blockchain 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 by gateway 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 may be used as input data for generating a proof) and a verification key (which may 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 by gateway 2006 a. 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 statement 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 chaining point may send the ciphertext, the hash value, and one or more ZKPs to gateway 2006 a.

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 the gateway 2006a determines that the ciphertext is secure based on the one or more ZKPs, the gateway 2006a stores the received ciphertext and the received hash value in at least one server included in the gateway 2006 a.

At 2120, gateway 2006a can send a data notification to second zone link point 2010 a. 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 second tile link point 2010a can send a data retrieval request to the gateway 2006 a. In response to the data retrieval request, a network connection may be established between gateway 2006a and second zone link point 2010 a.

At 2124, the gateway 2006a can send the ciphertext and the hash value to the second chunk link point 2010 a.

At 2126, the second block 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 second chunk link point 2010a may validate the second data based on the hash value. For example, the second chunk 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 second chunk chain node 2010a may determine that the first data or ciphertext has not been tampered with. Otherwise, the second block link point 2010a may determine that the first data or ciphertext was tampered with.

At 2130, the second tile 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 second blockchain 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 second tile link point 2010a can send a data receipt to the gateway 2006 a. 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 the second 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 first tile link point 2008 a. In some embodiments, first blob link point 2008a may resume process 2100 if the data receipt indicates that the second data is not stored on the second blob chain.

In some embodiments, the first blockchain link point 2008a may obtain additional ciphertext from the gateway 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 first zone link point 2008a may be associated with a private network, while a second zone 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, example 2200 shows the process of sending a debtor 2202 associated with a first block-chain node of a first block-chain network a loan contract 2206a to a bank 2204 associated with a second block-chain node 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 a loan contract 2206a to generate a ciphertext 2208a and generate one or more ZKPs 2210 to prove that the ciphertext 2208a is secure. The first block link point may send ciphertext 2208a and one or more ZKPs 2210 to gateway 2006 a. Gateway 2006a may then verify that ciphertext 2208a is secure based on one or more ZKPs 2210, while ciphertext 2208a remains encrypted in the verification process. After successful verification, the gateway 2006a may then store the ciphertext 2208a in a server of the gateway 2006 a. The second block link point associated with bank 2204 may then obtain ciphertext 2208b from the server of gateway 2006 a. The bank 2204 may then decrypt the ciphertext 2208b to obtain the original loan contract 2206b and perform subsequent operations on the loan contract 2206 b.

Fig. 23 depicts an example 2300 of a blockchain-based trusted platform, according to embodiments herein. In some embodiments, blockchain based trusted platform 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 12302 a through merchant N2302N) are associated with a network of merchant blockchains using internet connectivity. A bank (e.g., bank 12304 a through bank N2304N) is associated with a bank blockchain network that is connected using a private banking network. Courts (e.g., courts 12306 a through courts N2306N) are associated with a courts blockchain network using a private courts network connection.

For example, the merchant 12302 a wishes to send a contract to the bank 12304 a to record the contract on a bank blockchain associated with the bank. A first blockchain link point associated with a merchant 12302 a obtains a contract from the merchant blockchain database 2310 or the smart contract data cache 2308 and sends a cross-chain and cross-network message including the contract to a second blockchain node associated with the bank 12304 a based on the process 2100 discussed in fig. 21. Bank 12304 a invokes the services of the blockchain based trusted platform 1702 to record the contract in the bank blockchain based on process 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 trusted platform 1702 detects that a contract is to be recorded in a bank blockchain, the blockchain based trusted platform 1702 records the contract in a bank blockchain database 2312 managed by the bank blockchain network and a bank intelligent contract data cache 2314 located in the private bank network.

In a similar manner, the merchant 12302 a may need to send a court order to the court 12306 a to execute the court order. The first blockchain link point associated with the merchant 12302 a sends cross-chain and cross-network messages including court orders to a third blockchain node associated with the court 12306 a based on the process 2100 discussed in fig. 21. The court 12306 a invokes the services of the block chain based trusted platform 1702, verifying the authenticity of the court order based on the process discussed in fig. 19. Data security rules for a 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 trusted platform 1702 detects that the court order is to be validated based on the court data, the blockchain based trusted platform 1702 accesses the court data in the court blockchain database 2316 managed by the court blockchain network and the court intelligent contract 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 trusted platform 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 trusted platform 1702 provides the same APIs to merchants, banks, and courts, but the application layer 1704 will handle sensitive data differently depending on the computer network associated with the sensitive data.

For example, the blockchain based trusted platform 1702 includes a rules database 2320 that includes information regarding the regulations of the various computer networks in which the blockchain based trusted platform 1702 operates. The application layer 1704 may access the rules database 2320 and operate in accordance with the regulations of each computer network. For example, when the bank 12304 a invokes the trusted platform 1702 based on the blockchain to send the bank statement of the merchant 12302 a to the court 12306 a, the application layer 1704 may access the rules database 2320 to determine the data security rules of the private banking network, specify that the social security code of the bank statement is to be edited when sending the bank statement outside the private banking network, and then the trusted platform 1702 based on the blockchain may edit the social security code of the bank statement and send the edited bank statement to the court 12306 a.

Fig. 24 depicts another example 2400 of a blockchain based trusted platform according to embodiments herein. A blockchain based trusted platform 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 trusted platform 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 commodities purchased from non-sustainable sources to the environmental career. It is difficult for an individual to track products from either sustainable or non-sustainable sources. The blockchain based trusted platform 1702 allows the second group members to easily set rules to help achieve their goals. For example, the blockchain based trusted platform 1702 may include a rules 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 the rules 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 an online commerce system 2414.

When a buyer purchases a product via the online commerce system 2414 and indicates that the buyer belongs to a second group member, the online commerce system 2414 sends the purchase data to the blockchain based trusted platform 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 trusted platform 1702 records the purchase data on a blockchain database 2418 and/or an intelligent contract data cache 2416. The blockchain based trusted platform 1702 includes a clearance approval module 2410 that analyzes the purchase data based on a rules 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 an 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 trusted platform 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 trusted platform 1702 may be recorded in a blockchain database 2418 that may be verified by interested parties. The services provided by the blockchain based trusted platform 1702 may be automated through the use of intelligent contracts.

In some embodiments, the blockchain based trusted platform 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 gaming platform may allow a player to establish a virtual country or kingdom, recruit other players to become citizens or ministers of the virtual country or kingdom, and establish 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 trusted platform 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 a process 2500 for recording and verifying blockchain data. 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 blockchain based system (e.g., the blockchain based system of fig. 3) may perform process 2500.

At 2502, a service computer system (e.g., service system 306-1 or 404) receives data from a client device (e.g., user 402). In some embodiments, a service computer system receives a request to store data from a client device, and the request includes the data. In some embodiments, the service computer system stores the data in local memory.

At 2504, the service computer system sends the data to a blockchain based trusted system (e.g., blockchain based trusted platform 312 or 606). In some embodiments, the service computer system generates a request to store data after receiving the data from the client device and sends the data in the request to the blockchain-based trusted system.

In some embodiments, the service computer system may encrypt the data and send the encrypted data in the request to the blockchain-based trusted system. In some embodiments, the service computer system may encrypt the data according to a predetermined encryption function or algorithm. In some examples, the serving computer system may encrypt the data using a public key of the trusted system based on the blockchain.

In some embodiments, the blockchain based trusted system may receive encrypted data from the serving computer system. In some examples, the encrypted data may be encrypted using a public key of a trusted system based on the blockchain. The blockchain based trusted system may decrypt the encrypted data and obtain the data using a private key paired with a public key.

In some embodiments, the blockchain based trusted system calculates a first hash value of the data after receiving the data from the serving computer system. In some embodiments, the blockchain-based trusted system generates ledger data based on the first hash value. In some embodiments, the ledger data includes the first hash value and additional information such as metadata of the data. In some embodiments, 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, the blockchain based trusted system stores ledger data in the blockchain based trusted system. In some embodiments, the blockchain-based trusted system may store ledger data in one or more blockchain nodes of the blockchain-based trusted system. In some embodiments, one or more blockchain nodes of the blockchain-based trusted system may be consensus nodes that participate in a consensus process. In some embodiments, consensus nodes of the blockchain based trusted system may perform consensus processing on the account data. Upon agreement between the consensus nodes, the blockchain-based trusted system may record ledger data stored in a blockchain of one or more blockchain nodes of the blockchain-based trusted system.

In some embodiments, a blockchain-based trusted system generates credentials corresponding to the data and sends the credentials to a service computer system. In some embodiments, the credentials may be configured to uniquely identify the data and/or ledger data. In some embodiments, the credentials include an identification of ledger data or a digital signature of a block chain-based trusted system. In some embodiments, a digital signature may be generated based on ledger data using a private key of a blockchain-based trusted system.

At 2506, the service computer system receives credentials from a blockchain based trusted system. As noted, the credentials may include an identification of the ledger data or a digital signature generated based on the ledger data using a private key of the blockchain-based trusted system.

At 2508, the service computer system sends the credentials to the client device. In some embodiments, the service computer system may verify the credential, for example, when the credential includes a digital signature of a trusted system based on the blockchain. In some embodiments, the service computer system may verify the digital signature included in the credential using a public key of the trusted system based on the blockchain.

In some embodiments, the service computer system may send the credentials in the logged results to the client device. In some embodiments, the recording result may further include a notification indicating whether the data recording is completed.

At 2510, the service computer system receives a first request to verify data to the blockchain based trusted system. In some embodiments, the first request comprises a credential. As noted, the credentials may be configured to uniquely identify the raw data and/or ledger data.

At 2512, the service computer system retrieves the data from the local memory. In some embodiments, the service computer system may obtain the data based on credentials included in the request.

At 2514, the serving computer system sends the obtained data to the block chain based trusted system. In some embodiments, the service computer system may send the obtained data to the blockchain-based trusted system in a second request for verification of the obtained data.

In some embodiments, the service computer system may send the obtained credentials for the data to a blockchain-based trusted system. In some embodiments, the service computer system may encrypt the obtained data and/or credentials and send the encrypted information to the blockchain-based trusted system. In some embodiments, the service computer system may encrypt the obtained data and/or credentials using a public key of the blockchain based trusted system.

In some embodiments, the blockchain-based trusted system may receive encrypted data and/or credentials from the service computer system and decrypt the encrypted data and obtain the data and/or credentials using a private key paired with a public key. In some embodiments, the blockchain based trusted system calculates a second hash value for the data based on the data received from the serving computer system.

In some embodiments, a blockchain-based trusted system may obtain ledger data from one or more blockchain link points of the blockchain-based trusted system based on credentials and obtain a first hash value in the ledger data. In some embodiments, the blockchain based trusted system compares the second hash value to the first hash value.

In some embodiments, the block chain based trusted system sends the comparison in the verification results to the service computer system. In some embodiments, the verification result may also include a digital signature of the trusted system based on the blockchain. In some embodiments, the digital signature of the blockchain-based trusted system may be generated using a private key of the blockchain-based trusted system based on at least one of the two hash values.

At 2516, the service computer system receives a verification of the trusted system based on the blockchain. The verification result may include a comparison result of two hash values and/or digital signatures of the trusted system based on the blockchain. In some embodiments, the service computer system may verify the digital signature using a public key of the trusted system based on the blockchain. If the digital signature is determined to be invalid, the service computer system may ignore the verification result. If the digital signature is determined to be valid, the service computer system may continue to process the verification result.

2518, the service computer system determines if the two hash values match. In some embodiments, the service computer system determines whether the two hash values match based on the received verification result. In some embodiments, if the two hash values match, the service computer system may determine that the data has not been tampered with. If the two hash values do not match, the service computer system may determine that the data has been tampered with.

At 2520, the service computer system sends a notification to the client device. In some embodiments, if the first hash value matches the second hash value, the service computer system may send a notification to the client device indicating that the data has not been tampered with. If the first hash value does not match the second hash value, the service computer system may send a notification to the client device indicating that the data has been tampered with.

Fig. 26 is an illustration of an example of modules of an apparatus 2600 in accordance with an embodiment herein.

Apparatus 2600 may be an example of an embodiment of a computer system configured to record and verify data in a blockchain based trusted system. The apparatus 2600 may correspond to the above-described embodiment, and the apparatus 2600 comprises the following: a first receiving module 2602 for receiving data from a client device; a first sending module 2604 for sending data to the trusted system based on the blockchain; a second receiving module 2606 for receiving credentials from a trusted system based on a blockchain; a second sending module 2608, configured to send the credential to the client device; a third receiving module 2610, configured to receive a first request from a client device to verify data; an obtaining module 2612 for obtaining data from a local storage; a third sending module 2614, configured to send the obtained data to a trusted system based on the blockchain; a fourth receiving module 2616, configured to receive a verification result of the block chain-based trusted system; a determining module 2618 for determining whether the two hash values match based on the verification result; a fourth sending module 2620 configured to send a notification to the client device.

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 an article 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.

As 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 device embodiments described previously are examples only. Modules described as separate components may or may not be physically separate, and components shown 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 as showing the internal functional modules and structure of the block chain data recording and verifying apparatus. The blockchain data recording and verifying apparatus may be an example of a computer system configured to record and verify blockchain data in a blockchain 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 may 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 optical disk, a solid state drive, Random Access Memory (RAM), Read Only Memory (ROM), or other media type. 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 medium may be or be in part 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 of a computer program for execution from a non-transitory computer-readable medium coupled to the processor.

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. Components may also be "coupled" to one another if one of the components is integrated into another component. For example, a storage component integrated into a processor (e.g., an L2 cache component) "couples" to a 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, trackball, or touch pad, through which the user may 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.