CN113302612B - Computer implementation method, system and device for cross-chain and cross-network data transmission - Google Patents

Computer implementation method, system and device for cross-chain and cross-network data transmission Download PDF

Info

Publication number
CN113302612B
CN113302612B CN202080009091.9A CN202080009091A CN113302612B CN 113302612 B CN113302612 B CN 113302612B CN 202080009091 A CN202080009091 A CN 202080009091A CN 113302612 B CN113302612 B CN 113302612B
Authority
CN
China
Prior art keywords
data
blockchain
network
ciphertext
chain
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202080009091.9A
Other languages
Chinese (zh)
Other versions
CN113302612A (en
Inventor
栗志果
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alipay Hangzhou Information Technology Co Ltd
Original Assignee
Alipay Hangzhou Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Hangzhou Information Technology Co Ltd filed Critical Alipay Hangzhou Information Technology Co Ltd
Publication of CN113302612A publication Critical patent/CN113302612A/en
Application granted granted Critical
Publication of CN113302612B publication Critical patent/CN113302612B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6272—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database by registering files or documents with a third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101—Auditing as a secondary aspect

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Databases & Information Systems (AREA)
  • Virology (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

One example method includes obtaining first data from a first blockchain link point of a first blockchain network, wherein the first blockchain network is associated with the internet, the first data to be recorded on a second blockchain associated with a second blockchain network, the second blockchain network associated with a private network. The first block link point may then encrypt the first data to generate ciphertext of the first data. The first block link point may then transmit the ciphertext to a gateway, the gateway including a server that stores the ciphertext, the ciphertext provided to a second block link node of the second block link network, the ciphertext decrypted by the second block link point to generate second data to be stored in the second block link, and a network device that interconnects the first block link network and the second block link network.

Description

Computer implementation method, system and device for cross-chain and cross-network data transmission
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.
A blockchain node of a blockchain network may need to perform cross-network and cross-chain communication with different blockchain nodes of different blockchain networks. Some blockchain networks may require a high standard of data privacy and security, so they may use a secure private computer network (spaced apart from the internet air) to connect their computing devices such that the internet's computing devices cannot exchange data with the private network's computing devices without permission. Some blockchain networks may not require such a high standard of data privacy and security, and therefore may rely on the internet to connect their computing devices. The isolation of the internet and private networks makes it difficult to transfer data between the internet and private networks. This can increase the difficulty when two computing devices of two different computer networks are associated with two different blockchain networks.
It is desirable to allow block link points of a block chain network to perform cross-network and cross-chain communications with different block link points of different block chain networks in a safe and efficient manner.
Disclosure of Invention
Embodiments of the described subject matter can include one or more features, alone or in combination.
For example, in one embodiment, a computer-implemented method for cross-chain and cross-network data transfer includes: obtaining first data from a first blockchain link point of a first blockchain network, wherein the first blockchain network is associated with the internet, the first data to be recorded on a second blockchain associated with a second blockchain network, the second blockchain network being associated with a private network; encrypting, by the first block link, the first data to generate ciphertext of the first data; and transmitting, by the first blockchain node, the ciphertext to a gateway, wherein the gateway includes a server that stores the ciphertext, the ciphertext being provided to a second blockchain node of the second blockchain network, the ciphertext being decrypted by the second blockchain node to generate second data to be stored in the second blockchain, and a network device that interconnects the first blockchain network and the second blockchain network.
In some embodiments, these general and specific aspects may be implemented using a system, method, or computer program, or any combination of systems, methods, or computer programs. The above and other described embodiments may each optionally include one or more of the following aspects:
in some embodiments, prior to obtaining the first data, the method further comprises: obtaining, by the first block link point, a cross-chain message comprising raw data; verifying, by the first block link point, that the raw data is stored in the first block chain; and converting, by the first block link point, the original data based on a conversion rule to obtain the first data, wherein the conversion rule is determined based on an input rule of the second block chain network.
In some embodiments, the input rules for the second blockchain network include at least one of: a plurality of input parameters input to an input of the second blockchain network; an encoding 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.
In some embodiments, the original data is obtained from the first blockchain by a third blockchain node, the cross-chain message being generated and sent by the third blockchain node.
In some embodiments, the method further comprises: generating a first hash value of the first data from the first chunk link point; and sending, by the first blockchain node, the first hash value to the gateway, wherein the first hash value is obtained from the gateway by the second blockchain node, generating a second hash value of the second data to compare with the first hash value, and storing the second data in the second blockchain in response to determining that the first hash value matches the second hash value.
In some embodiments, the method further comprises: generating, by the first block link point, one or more zero knowledge proofs associated with the first data; and transmitting, by the first blockchain node, the one or more zero knowledge proofs to the gateway, wherein the one or more zero knowledge proofs are used to determine that the ciphertext is secure, the ciphertext being stored in the server in response to determining that the ciphertext is secure.
In some embodiments, determining that the ciphertext is secure comprises at least one of: determining that data to be decrypted from the ciphertext does not include any keys defined in a restricted list maintained by the gateway; determining that data to be decrypted from the ciphertext satisfies the input rule of the second blockchain network; determining that a file to be decrypted from the ciphertext has a file type that is acceptable to the second blockchain network; or determining that data to be decrypted from the ciphertext does not contain malware or viruses.
In some embodiments, a data notification is sent to the second block link point, the second block link point is notified that the ciphertext is stored in the server, a data retrieval request is received from the second block link point in response to the data notification, and a network connection is established between the gateway and the second block link point in response to the data retrieval request.
In some embodiments, the method further comprises: obtaining, by the first blockchain node, an additional ciphertext from the gateway, wherein the gateway receives the additional ciphertext from the second blockchain network; decrypting, by the first block chain node, the additional ciphertext to generate third data; and storing, by the first block link point, the third data in the first block chain.
In some embodiments, the first blockchain network is associated with multiple parties to a contract and the private network is associated with a bank or court.
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 according to embodiments herein.
Fig. 5 depicts an example of a blockchain data validation process in a service system mode that may be performed according to embodiments herein.
Fig. 6 depicts an example of a blockchain data recording process in blockchain platform mode that may be performed according to embodiments herein.
Fig. 7 depicts an example of a blockchain data validation process in blockchain platform mode that can 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.
Techniques for block link point recording or validating ledger data are also described herein. In the prior art, block link points may typically record ledger data on a block chain using a standardized format. For example, the state data may be stored as key-value pairs in a tree structure. The tree structure may include one or more predetermined data fields. When a blockchain link point of a blockchain network receives a request from a requestor to record ledger data on a blockchain associated with the blockchain network, the requestor may not be in the standard format of the blockchain network, and thus the data fields included in the ledger data to be recorded may be different from the data fields provided in the standard format of the blockchain network. For example, the requestor may be different blockchain nodes of different blockchain networks, where the requestor's blockchain network uses a different standard format, and the ledger data to be recorded may include data fields that are different from the data fields provided in the standard format of the blockchain node that records the ledger data. Thus, a request to record ledger data on a blockchain may fail due to a mismatch in data fields.
Even if the requestor generates raw ledger data that meets the standard format of the blockchain network, another problem arises when the requestor converts the raw ledger data into a bitstream and sends the bitstream to the blockchain node that records the raw ledger data, where the blockchain node needs to decode the bitstream to obtain the raw ledger data and record the raw ledger data. For example, the block chain nodes recording the original ledger data and the block chain nodes of the requestor may utilize different conversion rules for conversion between the original ledger data and the bitstream, and thus the ledger data decoded by the block chain nodes for recording may be different from the original ledger data. Thus, the record may fail because the decoded ledger data may not meet the standard format of the blockchain node that records the original ledger data, even though the original ledger data may meet the standard format.
The present disclosure describes a viable solution to this problem. A block link point of a block chain network may determine a recording rule that includes one or more recording input parameters for ledger data to be recorded. The logging rules may be publicly available such that the requestor may include one or more logging input parameters in the ledger data to be logged. The recording rules may also include bitstream transformation rules such that the requester and block chain nodes may use the same bitstream transformation rules in the transformation between the original ledger data and the bitstream.
Techniques for cross-network and cross-chain communication are also described herein. A block link point of a block chain network may perform cross-network and cross-chain communication with different block link points of different block chain networks. For example, a contract's lifecycle may involve multiple steps, such as negotiating a contract, contracting a contract, recording a contract, performing a contract, etc., which may involve multiple entities, such as contract parties, financial institutions, judicial institutions, government agencies, etc. Some entities, such as financial, judicial, and governmental agencies, may require a high standard of data privacy and security, and therefore may use a secure private computer network (spaced apart from the internet) to connect their computing devices such that the computing devices of the internet cannot exchange data with the computing devices of the private network without permission. Some entities, such as parties to contracts, may not require such a high level of data privacy and security, and therefore may rely on the internet to connect their computing devices. The isolation of the internet and the private network creates technical problems for transferring data between the internet and the private network, particularly when an entity associated with the internet needs to communicate with an entity associated with the private network. Existing approaches may require the use of external memory (e.g., a USB flash drive, external hard disk, or other removable media) to transfer data between the internet and a private network.
This problem is magnified when two computing devices of two different computer networks are associated with two different blockchain networks. For example, a computing device associated with the internet may be a blockchain node of a blockchain network, and a computing device associated with a private network may be a different blockchain node of a different blockchain network. There may be challenges in cross-link communication between blockchain nodes associated with the internet and blockchain nodes associated with private networks. For example, the raw data may be stored on a blockchain associated with the internet in a standard format that includes one or more data fields. However, blockchain networks associated with private networks can only resolve different standard formats. As a result, the block-link points associated with the private network may not be able to resolve the raw data sent by the block-link nodes associated with the internet.
To handle data transfers between two blockchain nodes associated with two different computer networks and two different blockchain networks, the prior art may require an entity associated with one blockchain network to apply for permission to transfer data with the other blockchain network. For example, an entity needs to fill out an application form for multiple data transfers, and the application form needs to be manually reviewed. In addition, it may be necessary to negotiate conversion rules to format the data to be transmitted so that the block-link points receiving the data can use the conversion rules to convert the data into a standardized format that can be parsed by the block-link points. The negotiation of the manual auditing process and the conversion rules typically takes a long time to complete, thus reducing the efficiency of data transmission. Furthermore, since data transmission may rely on removable media and manual transfer of removable media, the data being transmitted may risk leakage from the removable media during transmission, and thus data privacy and security are low.
The present disclosure describes a possible solution to this problem. A gateway may be deployed to interconnect the internet and a private network. When the original data is transmitted from one blockchain node to another blockchain node, the blockchain node that transmits the original data may encrypt the original data and transmit the ciphertext to the gateway so that the plaintext of the original data is not exposed in the data transmission. Another blockchain node may then obtain the ciphertext from the gateway and decrypt the ciphertext to obtain the original data. Further, a block chain node that transmits the original data may convert the original data based on a predetermined conversion rule to obtain converted original data that can be parsed by another block chain node.
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 can send a private key-based digital signature to the service system so that the service system can authenticate the digital signature using a public key. This may provide an additional layer of data security in the transfer of data between the service system and the block chain based trusted platform. In some embodiments, a hash function or algorithm is used to verify whether data stored in the system has been altered. 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.
In some embodiments, the described techniques provide a predetermined logging rule for a blockchain-based trusted platform to log ledger data, wherein the logging rule provides one or more logging input parameters and an input format associated with the one or more logging input parameters for ledger data to be logged. This allows a requestor that intends to record ledger data on a blockchain-based trusted platform to include the one or more record-entry parameters in the ledger data and ensures that the requestor's input values to the one or more record-entry parameters satisfy the input format. In some embodiments, validation rules are also predetermined for the blockchain-based trusted platform, where the validation rules provide one or more validation input parameters and an input format associated with the one or more validation input parameters for ledger data to be validated. This allows a requestor who intends to validate ledger data on a blockchain-based trusted platform to include one or more validation input parameters in the ledger data and ensures that the input values of the requestor's one or more validation input parameters satisfy the input format. In some embodiments, the bitstream transformation rules are predetermined for a blockchain based trusted platform such that the requestor and the block link point at which ledger data is recorded or validated may use the same bitstream transformation rules in the transformation between the original ledger data and the bitstream. Thus, the described techniques may prevent recording or validation failures due to mismatches in data fields, data formats, and/or bitstream conversion rules. The described techniques may thus reduce data retransmission and data reprocessing due to recording or validation failures, thereby reducing consumption of computational, memory, and networking resources by blockchain nodes.
In some embodiments, the described techniques enable establishing a secure communication channel between a blockchain-based trusted platform and a requestor. The secure communication channel may be established based on, for example, a two-way Transport Layer Security (TLS) protocol, a two-way hypertext transfer protocol security (HTTPS) protocol, a one-way HTTPS protocol, etc. This may enhance data security for the transfer of ledger data between the blockchain-based trusted platform and the requestor.
In some embodiments, the described techniques provide a trusted timing module for generating a record timestamp, a trusted identity module for verifying a user identity associated with a requestor, and a trusted computing module for generating a blockchain transaction when recording raw ledger data. This may enable a blockchain-based trusted platform to maintain records of validated information about events (e.g., who, what, and when) that occurred during the recording of the original ledger data. Thus, the trustworthiness of the original ledger data recorded by the blockchain-based trusted platform may be enhanced.
In some embodiments, the described techniques enable a blockchain-based trusted platform to verify that original data (e.g., a data file) associated with ledger data has not been tampered with based on a hash value of the original data. The blockchain based trusted platform may compare the hash value of the raw data to the hash value recorded in the blockchain based trusted platform. If the trusted platform based on the blockchain finds that the hash value of the raw data matches the hash value recorded in the trusted platform based on the blockchain, the trusted platform based on the blockchain may determine that the raw data has not been tampered with. This allows the blockchain based trusted platform to verify the raw data without the requestor sending the raw data itself to the blockchain based trusted platform. Accordingly, data privacy and data security of the original data can be enhanced.
In some embodiments, the described technology provides a gateway to interconnect a blockchain network associated with the internet with another blockchain network associated with a private network. When one blockchain node of one blockchain network sends original data to another blockchain node of another blockchain network, the blockchain node sending the original data can encrypt the original data and send a ciphertext to a gateway. The block chaining point that receives the original data may then obtain the ciphertext from the gateway. This allows the ciphertext to remain encrypted in the data transfer between the two blockchain nodes, thereby improving the data privacy and security of the original data. In some embodiments, block-link points that transmit a ciphertext may generate one or more Zero Knowledge Proofs (ZKPs) associated with original data, where the one or more ZKPs may be used to determine that data to be decrypted from the ciphertext is secure without decrypting the ciphertext. This may reduce the security risk of private networks and the internet, for example, by reducing the risk of viruses or malware. Since the ciphertext can be verified without decryption, the data privacy and data security of the original data can be enhanced. In some embodiments, the block link point that sends the raw data may transform the raw data based on a predetermined transformation rule to obtain transformed raw data that is resolvable by another block chain node of another block chain network. This may prevent parsing failures due to mismatch of conversion rules of data fields, data formats and/or bit streams between two blockchain nodes. This may reduce data retransmission and data reprocessing due to parsing failures, thereby reducing consumption of computational, memory and network resources of the blockchain node.
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 DLS 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 of the transaction purported to be stored in the tree is consistent with the structure of the tree, the hash value can be quickly verified.
A blockchain is a decentralized or at least partially decentralized data structure for storing transactions, while a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains by broadcasting, validating, and confirming transactions, etc. As described above, the blockchain network may be provided as a public blockchain network, a private blockchain network, or a federated blockchain network. Embodiments herein are described in further detail with reference to federated blockchain networks. However, it is contemplated that embodiments herein may be implemented in any suitable type of blockchain network.
Typically, a federated blockchain network is private among the participating entities. In a federated blockchain network, the consensus process is controlled by a set of authorized nodes, which may be referred to as consensus nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, with each entity operating at least one node in the federated blockchain network.
In some examples, in a federated blockchain network, a global blockchain is provided as a blockchain that is replicated across all nodes. That is, all of the consensus nodes are in a fully consensus state with respect to the global blockchain. To achieve consensus (e.g., agree to add a block to a blockchain), a consensus protocol is implemented within a federated blockchain network. For example, a federated blockchain network may implement a 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, 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 tamper-resistantly record information in blockchain 216. 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 on behalf of participant a, participant B, and participant C, respectively, and functions 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 multiple nodes 214 within the blockchain network 212 may be operated by participants and/or that multiple participants may share a 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 valuables (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 will result in an entirely different hash value. 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 the 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 provisioned as an Enclave Page Cache (EPC) in memory and mapped to the application address space. The memory (e.g., DRAM) includes a reserved random access memory (PRM) for the SGX. Random access memory is the lowest BIOS level of contiguous memory space and is not accessible by any software. Each enclave page cache is a set of memory (e.g., 4 KB) allocated by the operating system to load application data and code in random access memory. Enclave Page Cache Metadata (EPCM) is the incoming address of the corresponding enclave page cache and ensures that each enclave page cache can only be shared by one enclave. That is, a single enclave may use multiple enclave page caches, while an enclave page cache is dedicated to a single enclave.
During execution of a trusted application, the processor operates in a so-called enclave mode when accessing data stored in an enclave. Operation in enclave mode would perform an additional hardware check for each memory access. In software 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, a 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 certificate comprises the local certificate being sent from the enclave to a so-called quote enclave, which verifies the local certificate and converts the local certificate to the remote certificate by signing the local certificate with an asymmetric certificate key. Remote authentication (quote) is provided to the challenger (e.g., the key management system of the blockchain network).
The challenger verifies the remote authentication using the authentication verification service. For SGX, intel provides Intel Authentication Service (IAS) which receives remote authentication from a challenger and verifies the remote authentication. More specifically, the IAS processes the remote authentication and provides a report (e.g., an Authentication Verification Report (AVR)) indicating whether the remote authentication has been verified. If not, an error may be indicated. If verified (the desired code is securely executed in the trusted execution environment), the challenger can start or continue to interact with the trusted application. For example, in response to authentication, the key management system (as a challenger) can issue an asymmetric cryptographic key (e.g., a public and private key pair) to a node executing a trusted execution environment (e.g., via a key exchange process such as elliptic curve Diffie-Hellman (ECDH)) to enable the node to securely communicate with other nodes and/or clients.
Techniques are described herein for implementing a blockchain-based system (which may be a trusted online system) that enhances trust between users and provides various services or processing tools to allow users to conduct transactions (e.g., legal litigation, business contract execution) 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 over 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, the 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 the 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 for 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 real estate agents, brokers, commercial banks, third party escrow, police stations, government agencies, and the like. In some embodiments, a subsystem that includes at least one blockchain node of 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 link point 308-2) may generate and record ledger data into a blockchain stored in the blockchain node based on data received from a user (e.g., user 302). The block chain data recording verification process in the two modes will be described in more detail below with reference to fig. 4 to 7.
Fig. 4 depicts an example of a 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.
The process 400 begins at step 410, where the user 402 sends data for recording to the service system 404. In some embodiments, user 402 may send a request to service system 404 to record data, where the request includes the data. In some embodiments, the data may be in the format of a digital document (e.g., a business agreement) or a digital file (e.g., a forensic image, video, etc.).
User 402 may be 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 the user identification to service system 404 along with the data, such that service system 404 may compare the received user identification with 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, wherlpool (Whirlpool) hash function, etc.). In some examples, service system 404 may apply a predetermined hash function to data received from a user and generate a hash value for the data. In some examples, 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 store 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), SSD, hard Disk Drive (HDD), or magnetic laminated recording (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, after 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 ledger data. After consensus is achieved between the consensus nodes, blockchain-based trusted platform 406 may record ledger data in blockchains stored in one or more participating nodes of 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 ledger data and/or a digital signature of blockchain-based trusted platform 406 that is generated based on the ledger data using a private key of 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 based on the ledger data using a private key of the blockchain-based trusted platform 406 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 can 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, hulup hash function, etc.). Ledger data may include additional information, such as metadata for the data. The metadata may include one or more of an author, a creation date, a modification date, and a file size of the data.
In the above example, the credential 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 verify the data, obtains the data from a local store of the service system 504. In some embodiments, the local storage 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 from the same cryptographic hash function or algorithm used to calculate the hash value in a previous data record process.
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 credential using the 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 storage 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, blockchain-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, the service system 404 triggers data logging after receiving data from the 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 store 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 subsystems 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 with 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 the 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 a 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 trusted platform 606 based on the blockchain. 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, hulup 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 not valid, 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 store of service system 704 after receiving the 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, the service system 704 sends the data obtained at step 712 to the 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 storage 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 the blockchain-based trusted platform 706, the service system 704 sends a verification response to the 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, the service system 704 may determine that the data stored in the service system 704 has not been tampered with. The service system 704 may also include the data in a verification response and send a verification response to the 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-described problems by providing a suite of service applications that utilize the functionality of a trusted time module 808, a trusted identity module 810, and a 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, what, 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 the 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 an application that provides services over a network and reduces the likelihood of counterfeiting or tampering by capturing a snapshot of each of a number of steps (or several significant points in time) in the process that provides the 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 who, when and what is associated with the event that occurred at the respective step or point in time, for example. The probability of forgery or falsification at each of the plurality of steps (or points in time) is smaller than the probability of forgery or falsification at a single step (or point in time). Trusted time module 808 provides a trusted or verified timestamp, 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 operating systems of the one or more data processors and is configured to provide enhanced confidentiality and integrity for code and loaded data executing within the one or more data processors. In some examples, an application or intelligent contract may invoke the functionality of a module through an API.
The trusted platform 800 based on block chains 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 indicating where the transaction occurred. For example, the trusted location module may be used to prove that infringement occurred in a geographic region and may litigation was raised to a courthouse 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: (ii) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online banking account, (ix) a user ID associated with a taxi-calling service, (x) a user ID associated with an online ordering service, (xi) a social security assurance code; (xii) A driver license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, (xv) an ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information.
In the example of fig. 9, a user 924 accesses the 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 receiving user instructions for processing the web pages (e.g., clicks for controlling navigation between 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 a 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, trusted identity module 908 may use any amount of information associated with a user account to verify the identity of 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 can 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 the chunk that includes the record and hash value to a blockchain 912, the blockchain 912 storing the record 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. The web browser 904 calls the trusted computing module 910 to update the block chain 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) in which 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 the beidou navigation satellite system maintained by china, the global positioning system maintained by the united states, the galileo global navigation satellite system maintained by the european union, the global orbiting navigation satellite system (GLONASS) maintained by russia, and/or the quasi-zenith satellite system maintained by 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 provided by a user during enrollment, such as one or more fingerprints, one or more voiceprints, or iris information.
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, one 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) under which the device operating system and applications run. The trusted execution environment may make it possible to build REE applications and services with better security and availability by partitioning the REE applications and services such that sensitive operations are limited to only the trusted execution environment and sensitive data (e.g., encryption keys).
In the example shown, 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 provisioned 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., 4 KB) allocated by the operating system to load application data and code in random access memory. Enclave Page Cache Metadata (EPCM) is the incoming 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 is the evidence itself verified, but the process of collecting or generating each piece of evidence is also verified. 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 intelligent 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 the TLS protocol and the HTTPS (hypertext transfer protocol secure) protocol, both of which 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 functionality 1332, cryptographic algorithm security functionality 1334, and key security functionality 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, the intelligent contract security functions 1332 may support the use of virtual machines to load and execute intelligent contracts. In this example, a separate virtual machine may be created for each blockchain transaction. When the blockchain transaction is completed, 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 hashing algorithms and functions. In some examples, cryptographic algorithm security function 1334 may support multiple sets of cryptographic suites as needed for different service scenarios. Table 1 below shows an example of an illustration of a cipher suite according to embodiments herein.
TABLE 1 description of cipher suite
Figure BDA0003160608920000271
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 illustrated example, 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 above example, 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, the cross-chain communication component 1418 is configured to allow communication between the block-link point 1412 and the cross-chain communication component 1438, and the cross-chain communication component 1438 is configured to allow communication between the block-link point 1432 and the 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 intelligent 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 inter-chain communication assemblies 1504, and blockchain network 1520 includes blockchain dots 1508 and inter-chain communication assemblies 1506. As shown, service intelligent contracts 1512 and cross-link intelligent contracts 1514 execute on block link points 1502 of block chain network 1510, while service intelligent contracts 1528 and cross-link intelligent 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-chain relay component 1516 may send ledger data and ledger certification to oracle machine 1518.
At step 1536, statement interpreter 1518 validates the ledger data and determines whether the ledger data is valid. In some embodiments, book prediction machine 1518 may validate ledger data based on ledger certification. In some examples, 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 step 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 accessing block chain network 1520.
Fig. 16 depicts an example 1600 of data storage in a blockchain based trusted platform according to embodiments herein. At a high level, the data storage 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 a block database 1612, a status database 1618, and an extension database 1624. Block database 1612 may store block chain data including a block header 1614 and a block bank 1616. State database 1618 may store state information related to the 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.
Block chain node 1602 may invoke virtual machine 1608 to execute the intelligent contract. In some embodiments, the virtual machine 1608 may be deployed in a trusted computing environment, such as a TEE. In some embodiments, the virtual machine 1608 may be configured to perform intelligent contract operations by executing instructions of an intelligent contract programming language. In some examples, the virtual machine 1608 may access resources external to the TEE during execution of the operation, such as an external server, a blockchain, a database, or other resource indicated by the operation. In some embodiments, access to external resources may be restricted or denied such that the overall execution of an operation depends only on data stored in the TEE (e.g., smart contract state). Such a limitation may also reduce the likelihood of tampering with the execution of the operation.
The intelligent contract operation may include an execution state of the intelligent contract (e.g., adding a document, updating a document state, etc.) associated with the requesting contract operation. 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 intelligent 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 upon 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 intelligent 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 for 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 can then use the hash value to locate 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. A cache-miss state may occur when the capacity of the KVP exceeds a certain threshold (e.g., 5 GB). A cache miss refers to a state in which data required for processing by a component or an application cannot be found in a cache memory. Cache misses may require a program or application to obtain 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 extension database 1624.
In some embodiments, the data stored in the intelligent contract pool 1626 is also recorded in the 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, the document 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 the document type. A hash value range may be predetermined and assigned to each intelligent contract pool 1626. For example, for a document with document ID 000001, md3 hash value is 769924EADBBF6F72C6581377419FCB77. Assuming there are 16 intelligent contract pools, the document may be stored in a seventh intelligent contract pool based on the first bit hexadecimal number of the hash value. Likewise, a document with a document ID of 000003 has an md3 hash value of 4DE1F0F6DA993FC4AB439CDCA5E084F6. The document may be stored in a fourth intelligent contract pool based on the first digit 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 to 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 block 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 month of creation and YYYY denotes the year of creation). 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, the blockchain-based trusted platform 1702 provides services to one or more contractual parties (e.g., contractual party a 1768 and contractual party B1770) such that contracts negotiated and signed by the contractual parties may be securely stored (e.g., in the blockchain database 1610 and the 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 authority 1774 may issue court orders and adjudications to determine contractor a 1768 as a debtor and 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 the contract, such as determining whether the contract complies with laws, regulations or regulations and evaluating and collecting customs, taxes and fees associated with importation and exportation of goods. Government agency 1776 may also be responsible for detecting fraudulent activity associated with 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, the intelligent contract data cache 1606 may store variable data in the form of intelligent contract data, and the 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 recording of contract data 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 the result of verifying the 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 organizational management. Chain domain management may provide network management and configuration management at the blockchain level. Node management may manage the joining or exiting of consensus nodes. The organization administration may specify access rights for entities accessing the platform. 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 entities accessing the platform and the privacy of transactions. 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 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 trusted platform 1702 based on a blockchain. 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 fields of the federation blockchain transaction are different than the data fields 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 can 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 transformation 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 comprising one or more recording input parameters, encode each data value of the respective recording input parameters into a respective small bit stream, determine an order in which the one or more recording input parameters are arranged in the bit stream, and concatenate the respective small bit streams to generate the bit stream.
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}. Then, the obtained bitstream is 100011011001.
After receiving ledger data, the bitstream included in the ledger data may then be converted into raw data including one or more record input parameters based on a conversion rule. For example, assuming that the bitstream 100011011001 is received, it 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 that the original ledger data does not satisfy the recording 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 implemented on one or more blockchain nodes or on one or more computing devices communicatively coupled to the one or more blockchain nodes (e.g., blockchain-based trusted platform 1702). For clarity of presentation, the following description generally 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, the client device obtains raw data, such as a contract file, and intends to verify whether the raw data was tampered with. The client device may then calculate a hash value of the raw data, generate ledger data including the hash value, and send the ledger data to a blockchain-based trusted platform for validation. The blockchain-based trusted platform may compare the hash value received from the client device to the hash value recorded on the blockchain. If the blockchain based trusted platform finds that the hash value recorded on the blockchain matches the hash value received from the client device, the blockchain based trusted platform can verify that the original data has not been tampered with. The blockchain based trusted platform may then send a verification receipt to the client device to indicate that the contract file has not been tampered with.
In some embodiments, the client device is associated with a second blockchain that is different from the first blockchain that receives ledger data. 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 that is different from the first standardized format. For example, a first blockchain may be a public blockchain and corresponding transactions have a standardized format that includes data fields such as total input, total output, cost, etc., a second blockchain may be a federation blockchain and corresponding transactions have a standardized format that includes data fields such as values, random numbers, gas limits, etc. If the client device packages data to be recorded in a federation blockchain transaction and sends the federation blockchain transaction to a public blockchain node for recording, the public blockchain node may not be able to resolve the federation blockchain transaction because, for example, the data field of the federation blockchain transaction is different from the data field of the public blockchain transaction. In some embodiments, the client device sends a cross-chain message including ledger data to the first blockchain based on the process discussed in fig. 15.
In some embodiments, ledger data includes one or more validation input parameters defined in a validation rule and accepted by a validation input interface. Ledger data may include one or more validation input parameters associated with structured data or unstructured data discussed in fig. 18.
If the ledger data is associated with structured data, the one or more validation input parameters may include one or more of: the verification method of the account book data is selected, the unique ID of the structured data, the service information of the structured data, the timestamp of the structured data and the 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 includes 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 can 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 may be sent to the client device via a verification output interface (e.g., verification output interface 1726).
At 1912, an error message may be sent via the verification output interface. In some embodiments, the error message indicates that the original ledger data does not satisfy the validation rules and one or more reasons that the original ledger data does not satisfy the validation rules. In some embodiments, the error message indicates that the original data associated with the ledger data was tampered with.
Fig. 20 depicts an example 2000 of cross-chain and cross-network data transfer according to embodiments herein. Example 2000 includes internet 2002, private network 2004, and gateways 2006a and 2006b. 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 2006b.
In some embodiments, a first plurality of blockchain nodes (e.g., blockchain point 1 2008a to blockchain point 5 2008e) of a first blockchain network are connected through 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 1 2010a through blockchain point 5 2010e) 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 institution, a governmental agency, or the like. In some embodiments, each blockchain node of the first and second plurality of blockchain nodes may access the blockchain based 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 routers of internet 2002 and routers of 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 can employ another single fiber to connect at least one network device of the gateway 2006a and a router of the private network. At least one network device of the gateway 2006a may be equipped with an optical receiver for connecting to a single optical fiber of the internet 2002 and an optical transmitter for connecting to a single optical 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 2006a. 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 2006b.
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 2010a. Process 2100 may be performed to send data from first blob link point 2008a to second blob link point 2010a. As discussed in the description of fig. 20, the first blockchain network 2008a is associated with the first blockchain network and connected to other blockchain nodes of the first blockchain network through the internet 2002, and the second blockchain network 2010a is associated with the second blockchain network and connected to other blockchain nodes 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, a first tile link point 2008a can obtain the original 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 obtaining 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, prior to the third blockchain node retrieving the original data, the third blockchain node may receive a data request from the private network requesting 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 the 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 convince one or more verifiers that a claim is correct without providing the one or more verifiers with any sensitive information.
ZKP algorithms typically include key generation algorithms, proof generation algorithms, and proof verification algorithms. The key generation algorithm is responsible for computing a proof key (which can be used as input data for generating a proof) and a verification key (which can be used as input data for verifying a proof). The proof generation algorithm is responsible for generating the proof. The proof verification algorithm is responsible for verifying the proof and obtaining a binary verification result that is 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 to be verified with the credential.
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 2006a. To determine whether this declaration is true, the ZKP may be generated by inputting at least the raw data, the ciphertext, and the restricted list into a credential generation algorithm.
Statement 2: the data to be decrypted from the ciphertext satisfies the input rules of the second blockchain network. To determine whether this declaration is true, the ZKP may be generated by inputting the raw data, the ciphertext, and the input rules of the second blockchain network into a credential generation algorithm.
Statement 3: the file to be decrypted from the ciphertext has a file type that is acceptable to the second blockchain network. To determine whether this declaration is true, the ZKP may be generated by inputting the raw data, the ciphertext, and a list of file types acceptable to the second blockchain network into a proof generation algorithm.
Statement 4: the data to be decrypted from the ciphertext does not contain malware or viruses. To determine whether the claim is true, the ZKP may be generated by inputting at least the original data, the ciphertext, and the code of the malware or virus into an evidence generation algorithm.
At 2114, the first block chaining point may send the ciphertext, the hash value, and one or more ZKPs to gateway 2006a.
At 2116, gateway 2006a may validate the ciphertext based on the one or more ZKPs.
Specifically, as a verifier of one or more ZKPs, gateway 2006a may input at least the one or more ZKPs and the ciphertext as input data into a proof verification algorithm, and then determine whether the ciphertext is secure based on the foregoing statement.
Again taking the zk-SNARK algorithm as an example, when zero knowledge verification is to be performed for one ZKP of the one or more ZKPs, the ZKP and ciphertext may be input as input data into the V algorithm of the zk-SNARK algorithm for computation. 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 gateway 2006a determines that the ciphertext is secure based on the one or more ZKPs, gateway 2006a stores the received ciphertext and the received hash value in at least one server included in gateway 2006a.
At 2120, gateway 2006a can send a data notification to second zone link point 2010a. The data notification may notify the second block link node that the ciphertext is 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 2006a. In response to the data retrieval request, a network connection may be established between gateway 2006a and second zone link point 2010a.
At 2124, gateway 2006a may send the ciphertext and hash value to a second block link point 2010a.
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 tile chain node 2010a may calculate a second hash value of the second data and compare the second hash value with the hash value. If the second hash value is the same as the hash value, the second block 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 may send a data receipt to the gateway 2006a. In some embodiments, the data receipt indicates that the ciphertext was successfully received and the second data is stored on the second blockchain. In some embodiments, the data receipt indicates one or more reasons that the second data is not stored on the second blockchain and that the second data is not stored on the second blockchain. The one or more reasons may include, for example, the ciphertext failed to be received by the second blockchain node 2010a, a 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 2008a. 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, first zone link point 2008a may be associated with a private network, while 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 ZKP 2210 to gateway 2006a. 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 2006a. The second block link point associated with bank 2204 may then obtain ciphertext 2208b from the server of gateway 2006a. 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 1 2302a through merchant N2302N) are associated with a merchant blockchain network that uses internet connectivity. Banks (e.g., bank 1 2304a through bank N2304N) are associated with a bank blockchain network that uses private banking network connections. A court (e.g., court 1 2306a through court N2306N) is associated with a court-block-chain network that uses a private court network connection.
For example, merchant 1 2302a wishes to send a contract to bank 1 2304a to record the contract on a bank block chain associated with the bank. A first block link point associated with merchant 1 2302a gets a contract from merchant block chain database 2310 or intelligent contract data cache 2308 and sends a cross-chain and cross-network message including the contract to a second block chain node associated with bank 1 2304a based on process 2100 discussed in fig. 21. Bank 1 2304a invokes the services of the blockchain-based trusted platform 1702, recording the contract in the bank blockchain based on the process 1800 discussed in fig. 18. Data security rules for private banking networks may require that contract data be stored in a computer server located in a 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, merchant 1 2302a may need to send a court order to court 1 2306a to execute the court order. The first block link point associated with merchant 1 2302a sends cross-chain and cross-network messages including court orders to the third block chain node associated with court 1 2306a based on process 2100 discussed in fig. 21. Court 1 2306a 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 block chain based trusted platform 1702 detects that the court order is to be verified based on the court data, the block chain based trusted platform 1702 accesses the court data in the court block chain database 2316 managed by the court block chain network and the court intelligent contract data cache 2318 located in the private court network to verify 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, blockchain-based trusted platform 1702 includes a rules database 2320 that includes information regarding the regulations of the various computer networks in which 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 bank 1 2304a calls the block chain based trusted platform 1702 to send the bank statement for merchant 1 2302a to court 1 2306a, the application layer 1704 may access the rules database 2320 to determine the data security rules for the private bank network, specify that the social security codes for the bank statement are to be edited when sending the bank statement out of the private bank network, and then the block chain based trusted platform 1702 may edit the social security codes for the bank statement and send the edited bank statement to court 1 230a.
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 the import tax that the customs authority determines will apply to the import goods).
For example, clearance approval module 2410 may send a message to the buyer indicating that the product is not from a sustainable source and that the buyer should donate an amount based on an agreement between members of the second group. The blockchain based 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 a trade. The operation of the blockchain-based trusted platform 1702 may be automated through the use of smart contracts to implement virtual customs 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 cross-chain and cross-network data transfer. For convenience, process 2500 is described as being performed by a system of one or more computers located at one or more locations and appropriately programmed according to the specification. For example, a suitably programmed blockchain-based system (e.g., blockchain-based trusted system 1702 of FIG. 17) may perform process 2500.
At 2502, a first blockchain link point of a first blockchain network associated with the internet obtains first data to be recorded on a second blockchain associated with a second blockchain network associated with the private network. In some embodiments, the first chunk chain node obtains a cross-chain message that includes the original data prior to obtaining the first data. The first block link point may then verify that the original data is stored in the first block chain. The first blockchain node may then convert the original data based on a conversion rule to obtain the first data, wherein the conversion rule is determined based on an input rule of the second blockchain network. In some embodiments, the input rules for the second blockchain network include at least one of: a plurality of input parameters to an input of a second blockchain network; an encoding scheme corresponding to each of the plurality of input parameters; or arranging an order of a plurality of input parameters in the input. In some embodiments, the original data is obtained from the first blockchain by the third blockchain node, and the cross-chain message is generated and sent by the third blockchain node.
At 2504, the first block chain node encrypts the first data to generate ciphertext of the first data. In some embodiments, the first chunk link point generates a first hash value of the first data. The first blockchain link may then send a first hash value to the gateway, where the first hash value is obtained from the gateway by the second blockchain node, generate a second hash value of the second data to compare with the first hash value, and store the second data in the second blockchain in response to determining that the first hash value matches the second hash value. In some embodiments, the first block link point generates one or more zero knowledge proofs associated with the first data. The first block chaining point may then send the one or more zero knowledge proofs to the gateway, wherein the one or more zero knowledge proofs are used to determine that the ciphertext is secure, and in response to determining that the ciphertext is secure, store the ciphertext in the server. In some embodiments, determining that the ciphertext is secure comprises at least one of: determining that data to be decrypted from the ciphertext does not include any keys defined in a restriction list maintained by the gateway; determining that data to be decrypted from the ciphertext satisfies an input rule of a second blockchain network; determining that the file to be decrypted from the ciphertext is of a file type that is acceptable to the second blockchain network; or determining that the data to be decrypted from the ciphertext does not include malware or viruses.
At 2506, the first blockchain endpoint transmits the ciphertext to a gateway, wherein the gateway includes a server and a network device, the server stores the ciphertext provided to a second blockchain node of the second blockchain network, the ciphertext is decrypted by the second blockchain endpoint to generate second data to be stored in the second blockchain, and the network device interconnects the first blockchain network and the second blockchain network. In some embodiments, a data notification is sent to the second block-link point, the second block-link point is notified that the ciphertext is stored in the server, wherein a data retrieval request is received from the second block-link point in response to the data notification, and a network connection is established between the gateway and the second block-link point in response to the data retrieval request. In some embodiments, the first blockchain node obtains an additional ciphertext from the gateway, wherein the gateway receives the additional ciphertext from the second blockchain network. The first block chain node may then decrypt the additional ciphertext to generate third data. The first block link point may then store the third data in the first block chain. In some embodiments, the first blockchain network is associated with multiple parties to the contract, wherein the private network is associated with a bank or court.
Fig. 26 is a schematic diagram of an example of modules of an apparatus 2600 in accordance with an embodiment of the present description.
Apparatus 2600 may be an example of an embodiment of a computer system configured for cross-chain and cross-network data transfer in a blockchain based trusted system. The apparatus 2600 may correspond to the above-described embodiment, and the apparatus 2600 comprises: an obtaining module 2602 for obtaining first data, wherein the first blockchain network is associated with the internet and the first data is to be recorded on a second blockchain associated with a second blockchain network associated with the private network; an encryption module 2604 to encrypt the first data to generate a ciphertext of the first data; and a transmitting module 2606 for transmitting the ciphertext to a gateway, wherein the gateway comprises a server that stores the ciphertext provided to a second blockchain node of the second blockchain network, the ciphertext decrypted by the second blockchain node to generate second data to be stored in the second blockchain, and a network device that interconnects the first blockchain network and the second blockchain network.
In an alternative embodiment, apparatus 2600 further comprises: a second obtaining module, configured to obtain a cross-chain message including original data; the verification module is used for verifying whether the original data is stored in the first block chain or not; and a conversion module for converting the original data based on a conversion rule to obtain the first data, wherein the conversion rule is determined based on an input rule of the second blockchain network.
In an alternative embodiment, the input rules for the second blockchain network include at least one of: a plurality of input parameters input to an input of the second blockchain network; an encoding scheme corresponding to each of the plurality of input parameters; or arranging an order of a plurality of input parameters in the input.
In an alternative embodiment, the original data is obtained from the first blockchain by the third blockchain node, and the cross-chain message is generated and sent by the third blockchain node.
In an alternative embodiment, apparatus 2600 further comprises: the first generation module is used for generating a first hash value of the first data; and a second sending module to send the first hash value to the gateway, wherein the second blockchain node obtains the first hash value from the gateway, generates a second hash value of the second data to compare with the first hash value, and in response to determining that the first hash value matches the second hash value, the second data is stored in the second blockchain.
In an alternative embodiment, the apparatus 2600 further comprises the following: a second generation module to generate one or more zero knowledge proofs associated with the first data; and a third sending module to send the one or more zero knowledge proofs to the gateway, wherein the one or more zero knowledge proofs are to determine that the ciphertext is secure, and in response to determining that the ciphertext is secure, store the ciphertext in the server.
In an alternative embodiment, determining that the ciphertext is secure includes at least one of: determining that data to be decrypted from the ciphertext does not include any keys defined in a restriction list maintained by the gateway; determining that data to be decrypted from the ciphertext satisfies an input rule of a second blockchain network; determining that the file to be decrypted from the ciphertext has a file type that is acceptable to the second blockchain network; or determining that the data to be decrypted from the ciphertext does not include malware or viruses.
In an alternative embodiment, a data notification is sent to the second block-link point, the second block-link point ciphertext is notified to be stored in the server, wherein a data retrieval request is received from the second block-link point in response to the data notification, and a network connection is established between the gateway and the second block-link point in response to the data retrieval request.
In an alternative embodiment, apparatus 2600 further comprises: a third obtaining module, configured to obtain an additional ciphertext from a gateway, where the gateway receives the additional ciphertext from the second blockchain network; a decryption module for decrypting the additional ciphertext to generate third data; and a storage module for storing the third data in the first block chain.
In an alternative embodiment, the first blockchain network is associated with multiple parties to the contract, wherein the private network is associated with a bank or court.
The systems, apparatuses, modules or units shown in the above embodiments may be implemented by using a computer chip or an entity, or may be implemented by using an article having a specific function. A typical embodiment device is a computer, and the computer may be a personal computer, laptop computer, cellular telephone, camera phone, smartphone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or any combination of these devices.
For example processing of the functions and actions of each module in the device, reference may be made to example processing of the corresponding steps in the previous methods. Details are omitted here for the sake of simplicity.
Since the apparatus embodiments substantially correspond to the method embodiments, reference may be made to the relevant description in the method embodiments for the relevant parts. The device embodiments described above are merely examples. 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 according to actual needs to achieve the objectives of the solution herein. Those of ordinary skill in the art will understand and appreciate the embodiments of the present application without inventive effort.
Referring again to fig. 26, it can 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 account data in a blockchain based trusted system. The actuator may be essentially an electronic device comprising: one or more processors; and one or more computer-readable memories configured to store executable instructions of 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 algorithms, methods, functions, processes, procedures, and processes as described in this specification. The present specification also provides one or more non-transitory computer-readable storage media coupled to 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 according to 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 that, when executed by the one or more processors, cause the one or more processors to perform operations according to method embodiments provided herein.
A system for implementing the methods provided herein is also 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 embodiments of the methods 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 any of the structures disclosed herein and structural equivalents thereof, or combinations of one or more of them. Embodiments of the subject matter described herein can be implemented as one or more computer programs, e.g., one or more modules of computer program instructions, encoded on a computer program carrier for execution by, or to control the operation of, data processing apparatus. For example, a computer program carrier may include one or more computer-readable storage media having instructions encoded thereon or stored thereon. The carrier may be a tangible, non-transitory computer-readable medium such as a magnetic, magneto-optical disk or an optical disk, a solid state drive, random Access Memory (RAM), read Only Memory (ROM), or other media types. Alternatively or additionally, the carrier may be an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium may be or be partially 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 the execution of a computer program may be based on general and/or special purpose microprocessors, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory and/or a random access memory. Elements of a computer may include a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or integrated in, special purpose logic circuitry.
Generally, a computer will also include or be operatively coupled to receive data from or transfer data to one or more storage devices. The storage device may be, for example, a magnetic, magneto-optical disk or optical disc, a solid state drive, or any other type of non-transitory computer-readable medium. However, a computer need not have such devices. Thus, a computer may be coupled to one or more storage devices, e.g., one or more memories located locally and/or remotely. For example, the computer may include one or more local memories as an integrated component of the computer, or the computer may be coupled to one or more remote memories located in a cloud network. In addition, a computer may also be embedded in another device, e.g., a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device such as a Universal Serial Bus (USB) flash drive, to name a few.
Components may be "coupled" to one another by being connected in communication with one another either directly or through one or more intermediate components, e.g., electrical or optical connections. These components may also be "coupled" to one another if one of the components is integrated into another component. For example, a storage component (e.g., an L2 cache component) integrated into a processor is "coupled" to the processor.
To provide for interaction with a user, embodiments of the subject matter described herein may be implemented on or configured to communicate with a computer having a display device, e.g., an LCD (liquid crystal display) monitor, for displaying information to the user and an input device, e.g., a keyboard and a pointing device, e.g., a mouse, a trackball, or a touch pad, by which the user can provide input to the computer. Other types of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and may receive input from the user in any form, 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 certain 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 the scope of what may be claimed is 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. Moreover, 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 claim 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 sequential order, to achieve desirable results. In some cases, multitasking parallel processing may be advantageous.

Claims (11)

1. A computer-implemented method for cross-chain and cross-network data transmission, comprising:
obtaining first data from a first blockchain link point of a first blockchain network, wherein the first blockchain network is associated with the internet, the first data to be recorded on a second blockchain associated with a second blockchain network, the second blockchain network being associated with a private network;
encrypting, by the first block link, the first data to generate ciphertext of the first data; and
transmitting, by the first blockchain node, the ciphertext to a gateway, wherein the gateway comprises a server that stores the ciphertext, the ciphertext being provided to a second blockchain node of the second blockchain network, the ciphertext being decrypted by the second blockchain node to generate second data to be stored in the second blockchain, and a network device that interconnects the first blockchain network and the second blockchain network;
prior to obtaining the first data, the method further comprises:
obtaining, by the first block link point, a cross-chain message comprising raw data;
verifying, by the first block link point, that the raw data is stored in a first block chain; and
transforming, by the first blockchain link point, the raw data based on a transformation rule to obtain the first data, wherein the transformation rule is determined based on an input rule of the second blockchain network.
2. The computer-implemented method of claim 1, wherein the input rules for the second blockchain network include at least one of:
a plurality of input parameters input to an input of the second blockchain network;
an encoding scheme corresponding to each of the plurality of input parameters; or
The order of the plurality of input parameters is arranged in the input.
3. The computer-implemented method of claim 1, wherein the original data is obtained from the first blockchain by a third blockchain node, the cross-chain message being generated and transmitted by the third blockchain node.
4. The computer-implemented method of claim 1, further comprising:
generating a first hash value of the first data from the first block link point; and
sending, by the first blockchain node, the first hash value to the gateway, wherein the first hash value is obtained from the gateway by the second blockchain node, generating a second hash value of the second data to compare with the first hash value, and storing the second data in the second blockchain in response to determining that the first hash value matches the second hash value.
5. The computer-implemented method of claim 1, further comprising:
generating, by the first block link point, one or more zero knowledge proofs associated with the first data; and
transmitting, by the first blockchain node, the one or more zero knowledge proofs to the gateway, wherein the one or more zero knowledge proofs are used to determine that the ciphertext is secure, the ciphertext being stored in the server in response to determining that the ciphertext is secure.
6. The computer-implemented method of claim 5, wherein determining that the ciphertext is secure comprises at least one of:
determining that data to be decrypted from the ciphertext does not include any keys defined in a restricted list, the restricted list maintained by the gateway;
determining that data to be decrypted from the ciphertext satisfies input rules of the second blockchain network;
determining that a file to be decrypted from the ciphertext has a file type that is acceptable by the second blockchain network; or
Determining that data to be decrypted from the ciphertext does not contain malware or virus.
7. The computer-implemented method of claim 1, wherein a data notification is sent to the second block link point to notify the second block link point that the ciphertext is stored in the server, a data retrieval request is received from the second block link point in response to the data notification, and a network connection is established between the gateway and the second block link point in response to the data retrieval request.
8. The computer-implemented method of claim 1, further comprising:
obtaining, by the first blockchain node, additional ciphertext from the gateway, wherein the gateway receives the additional ciphertext from the second blockchain network;
decrypting, by the first block chain node, the additional ciphertext to generate third data; and
storing, by the first block link point, the third data in the first block chain.
9. The computer-implemented method of claim 1, wherein the first blockchain network is associated with multiple parties to a contract and the private network is associated with a bank or court.
10. A system for cross-chain and cross-network data transfer, 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 to 9.
11. An apparatus for data transmission across chains and across a network, the apparatus comprising a plurality of modules for performing the method of any of claims 1 to 9.
CN202080009091.9A 2020-11-25 2020-11-25 Computer implementation method, system and device for cross-chain and cross-network data transmission Active CN113302612B (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/131412 WO2022109850A1 (en) 2020-11-25 2020-11-25 Blockchain-based trusted platform

Publications (2)

Publication Number Publication Date
CN113302612A CN113302612A (en) 2021-08-24
CN113302612B true CN113302612B (en) 2022-12-20

Family

ID=77318845

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080009091.9A Active CN113302612B (en) 2020-11-25 2020-11-25 Computer implementation method, system and device for cross-chain and cross-network data transmission

Country Status (3)

Country Link
EP (1) EP4066439A4 (en)
CN (1) CN113302612B (en)
WO (1) WO2022109850A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113852469B (en) * 2021-09-24 2024-03-22 成都质数斯达克科技有限公司 Method, device, equipment and readable storage medium for transmitting data between block chain nodes
CN115174126B (en) * 2022-09-08 2022-12-09 山东省计算中心（国家超级计算济南中心） Outsourcing data ciphertext searching method and system based on block chain and SGX

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11196573B2 (en) * 2017-03-06 2021-12-07 Nokia Technologies Oy Secure de-centralized domain name system
US10761877B2 (en) * 2017-07-21 2020-09-01 Intel Corporation Apparatuses, methods, and systems for blockchain transaction acceleration
US20190288833A1 (en) * 2018-03-16 2019-09-19 Walmart Apollo, Llc System and Method for Securing Private Keys Behind a Biometric Authentication Gateway
MY194395A (en) * 2018-12-19 2022-11-30 Advanced New Technologies Co Ltd Data isolation in a blockchain network
CN109873808A (en) * 2019-01-11 2019-06-11 平安科技（深圳）有限公司 Communication means and device, storage medium and electronic equipment between block chain node
US11487886B2 (en) * 2019-05-03 2022-11-01 International Business Machines Corporation Database private document sharing
US10929570B2 (en) * 2019-05-17 2021-02-23 Advanced New Technologies Co., Ltd. Method, apparatus, and electronic device for blockchain-based infringement evidence storage
CN110266655B (en) * 2019-05-30 2021-11-12 中国工商银行股份有限公司 Cross-chain interconnection method, device and system based on block chain
US10805069B1 (en) * 2019-11-12 2020-10-13 Xage Security, Inc. Multi-layer ledgers for multi-party secure data governance
CN110912937B (en) * 2019-12-23 2021-09-07 杭州中科先进技术研究院有限公司 Block chain-based digital certificate storage platform and certificate storage method
WO2020098832A2 (en) * 2020-02-03 2020-05-22 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable gurantees
SG11202012925RA (en) * 2020-02-03 2021-01-28 Alipay Hangzhou Inf Tech Co Ltd Blockchain-based trustable guarantees
CN111447174A (en) * 2020-02-19 2020-07-24 江苏荣泽信息科技股份有限公司 Data encryption method based on block chain
CN111416808B (en) * 2020-03-13 2021-04-13 财付通支付科技有限公司 Cross-block-chain data mutual storage method, device, equipment and storage medium
CN111917865B (en) * 2020-07-29 2022-09-20 成都质数斯达克科技有限公司 Block chain network system, gateway and networking method

Also Published As

Publication number Publication date
EP4066439A4 (en) 2022-12-14
WO2022109850A1 (en) 2022-06-02
CN113302612A (en) 2021-08-24
EP4066439A1 (en) 2022-10-05

Similar Documents

Publication Publication Date Title
US11360963B2 (en) Tracking and verification of physical assets
US20210091960A1 (en) Tracking and verification of physical assets
US11734259B2 (en) Anonymous database rating update
US11580240B2 (en) Protecting sensitive data
US11569996B2 (en) Anonymous rating structure for database
CN113302610B (en) Trusted platform based on blockchain
WO2022109851A1 (en) Blockchain-based trusted platform
AU2021210206B2 (en) Index structure for blockchain ledger
US11949794B2 (en) Data anonymization of blockchain-based processing pipeline
US11924348B2 (en) Honest behavior enforcement via blockchain
US20220329411A1 (en) Blockchain processing offload to network device
WO2020169129A2 (en) Blockchain-based message services for time-sensitive events
CN113302612B (en) Computer implementation method, system and device for cross-chain and cross-network data transmission
JP2023530594A (en) Permitted Event Processing in Distributed Databases
WO2022109848A1 (en) Blockchain-based trusted platform
US20210217100A1 (en) Storage management based on message feedback
CN113491090B (en) Trusted platform based on blockchain
JP2023098847A (en) Apparatus, method and computer program (selective audit process for privacy-preserving blockchain)
WO2023046409A1 (en) Digital asset platform with hsm verification
CN112016118B (en) Method and system for anonymous database rating update

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant