Data processing method and related equipment

Abstract

The embodiment of the invention provides a data processing method and related equipment, the method is applied to a relay object, the relay object is connected with N block chain networks, N is a positive integer, and the method comprises the steps of obtaining a current block height of a block chain corresponding to a target block chain network; the target block chain network is any one block chain network in the N block chain networks; if the current block height is greater than a record block height of a target block chain network in the relay object, obtaining an update block from a block chain corresponding to the target block chain network according to the record block height and the current block height, the block height of the update block being greater than the record block height; according to the Merkel tree corresponding to the update block, generating a storage certificate of storage data included in the update block; in the embodiment of the invention, the target storage data of the evidence storage data is generated according to the evidence storage data and the evidence storage proof included in the update block, and the target storage data is stored, so that the security and reliability of the evidence storage data can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a data processing method and related equipment. Background Art

[0002] Blockchain is a combination of innovative technologies, including distributed data storage, smart contracts, consensus mechanisms, encryption algorithms, and other technologies. Its core mechanism is a distributed accounting technology maintained by multiple parties in an untrusted competitive environment. It has the characteristics of openness, tamper-proofing, anonymity, decentralization, and traceability, which can greatly expand the breadth and depth of people's collaboration.

[0003] Currently, in many business areas, important data is uploaded to the blockchain for on-chain evidence storage. The existing method of storing evidence is to upload the data to a single blockchain for data storage. However, practice has shown that if the blockchain fails or is attacked, the stored data is likely to be lost or damaged, thus affecting the security and reliability of the stored data. Summary of the Invention

[0004] The embodiments of the present application provide a data processing method and related equipment, which can improve the security and reliability of stored evidence data.

[0005] In one aspect, an embodiment of the present application provides a data processing method, which is applied to a relay object, wherein the relay object is connected to N blockchain networks, where N is a positive integer, and the method includes:

[0006] Get the current block height of the blockchain corresponding to the target blockchain network; the target blockchain network is any blockchain network among N blockchain networks;

[0007] If the current block height is greater than the recorded block height of the target blockchain network in the relay object, then based on the recorded block height and the current block height, an update block is obtained from the blockchain corresponding to the target blockchain network. The block height of the update block is greater than the recorded block height.

[0008] Generate a proof of existence for the evidence data included in the updated block based on the Merkle tree corresponding to the updated block;

[0009] Based on the evidence data and evidence proof included in the updated block, the target storage data of the evidence data is generated, and the target storage data is stored and processed.

[0010] In one aspect, an embodiment of the present application provides a data processing device, which is applied to a relay object, the relay object being connected to N blockchain networks, where N is a positive integer, and the device includes:

[0011] An acquisition unit, configured to acquire the current block height of a blockchain corresponding to a target blockchain network; the target blockchain network is any one of the N blockchain networks;

[0012] a processing unit configured to obtain an update block from the blockchain corresponding to the target blockchain network according to the recorded block height and the current block height if the current block height is greater than the recorded block height of the target blockchain network in the relay object, wherein the block height of the update block is greater than the recorded block height;

[0013] The processing unit is further configured to generate a proof of evidence for the evidence data included in the updated block based on the Merkle tree corresponding to the updated block;

[0014] The processing unit is further used to generate target storage data of the evidence data based on the evidence data and evidence proof included in the update block, and to perform storage processing on the target storage data.

[0015] In one aspect, an embodiment of the present application provides a computer device, comprising:

[0016] a processor suitable for executing a computer program;

[0017] Computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the above-mentioned data processing method is implemented.

[0018] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program, and the computer program is loaded by a processor and executes the above-mentioned data processing method.

[0019] On the one hand, an embodiment of the present application provides a computer program product, which includes a computer program or computer instructions, and when the computer program or computer instructions are executed by a processor, the above-mentioned data processing method is implemented.

[0020] In an embodiment of the present application, a relay object is connected to N blockchain networks, and the relay object obtains the current block height of the blockchain corresponding to the target blockchain network; the target blockchain network is any blockchain network among the N blockchain networks; if the current block height is greater than the recorded block height of the target blockchain network in the relay object, then based on the recorded block height and the current block height, an update block is obtained from the blockchain corresponding to the target blockchain network, and the block height of the update block is greater than the recorded block height. By comparing the current block height and the recorded block height, the relay object can store the evidence data in the latest block of the blockchain. Based on the Merkle tree corresponding to the update block, an evidence certificate for the evidence data included in the update block is generated; based on the evidence data and the evidence certificate included in the update block, target storage data for the evidence data is generated, and storage processing is performed on the target storage data. It can be seen that by introducing a relay object and establishing a connection between the relay object and the blockchain network, the blockchain block height can be compared with the record block height recorded in the relay object, thereby realizing the storage of the evidence data on the blockchain in the relay object. In this way, the evidence data can be stored both on the blockchain and in the relay object. To a certain extent, it can effectively avoid the security of the evidence data being affected by the blockchain failure, thereby improving the security of the evidence data. In addition, when storing the evidence data in the relay object, the embodiment of the present application will generate an evidence certificate for the evidence data. The authenticity of the evidence data can be proved by the evidence certificate, which also effectively improves the security and reliability of the evidence data. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0022] Figure 1A A schematic diagram of a blockchain network provided in an embodiment of the present application;

[0023] Figure 1B A schematic diagram of a blockchain provided in an embodiment of the present application;

[0024] Figure 1C A schematic diagram of block generation provided in an embodiment of the present application;

[0025] Figure 2 An architectural diagram of a data processing system provided in an embodiment of the present application;

[0026] Figure 3 A schematic diagram of the structure of a relay node provided in an embodiment of the present application;

[0027] Figure 4 A schematic diagram of a blockchain network registration process for a relay object provided in an embodiment of the present application;

[0028] Figure 5 A schematic diagram of a process for storing evidence data on a blockchain into a relay object provided in an embodiment of the present application;

[0029] Figure 6 A schematic diagram of distributed storage of relay objects provided in an embodiment of the present application;

[0030] Figure 7 A schematic diagram of a process for querying and verifying stored evidence data provided in an embodiment of the present application;

[0031] Figure 8 A flowchart of a data processing method provided in an embodiment of the present application;

[0032] Figure 9 A schematic diagram of a process for storing data in multiple relay nodes provided in an embodiment of the present application;

[0033] Figure 10 A flowchart of another data processing method provided in an embodiment of the present application;

[0034] Figure 11 A schematic diagram of the confidence scores of various blockchains provided in an embodiment of the present application;

[0035] Figure 12 A schematic diagram of a multi-chain trustworthiness judgment process for stored evidence data provided in an embodiment of the present application;

[0036] Figure 13 A schematic diagram of the structure of a data processing device provided in an embodiment of the present application;

[0037] Figure 14 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0039] The present application embodiment relates to a blockchain network, such as Figure 1AThe blockchain network shown in the figure is a network used for data sharing between node devices, and the blockchain network may include multiple node devices. Each node device can receive input transaction data during normal operation and maintain the shared data within the blockchain network based on the received transaction data. To ensure information interoperability within the blockchain network, information connections can exist between each node device in the blockchain network, and information can be transmitted between node devices through such information connections. For example, when any node device in the blockchain network receives input transaction data, the other node devices in the blockchain network obtain the input transaction data according to the consensus algorithm and store the transaction data as data in the shared data, ensuring that the data stored on all node devices in the blockchain network is consistent.

[0040] Each node device in a blockchain network has a corresponding node identifier, and each node device in the blockchain network can store the node identifiers of other node devices in the blockchain network so that the generated blocks can be broadcast to other node devices in the blockchain network based on the node identifiers of other node devices. Each node device can maintain a node identifier list as shown in the table below, and the node device name and node identifier are stored in the node identifier list. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node device. Table 1 only uses the IP address as an example for explanation.

[0041] Table 1

[0042] Node device name Node ID Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.XXX.XXX

[0043] Every node in a blockchain network stores an identical blockchain. Blockchain is a novel application model that combines distributed data storage, peer-to-peer transmission, consensus mechanisms, encryption algorithms, and other computer technologies. Blockchain is essentially a decentralized database, a series of data blocks linked using cryptographic methods. Each block contains information about a batch of network transactions, which is used to verify the validity of the information (to prevent counterfeiting) and generate the next block.

[0044] The blockchain consists of multiple blocks, see Figure 1BThe blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the characteristic value, version number, timestamp, and difficulty value of the input transaction data, and the block body stores a set of transaction data. The next block of the genesis block uses the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the characteristic value of the input transaction data of the current block, the characteristic value of the block header of the parent block, the version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input transaction data in the block. It should be understood that the blockchain includes blocks for storing transaction data and may also include configuration blocks. The configuration blocks are used to store configuration information for all node devices. Configuration information may include, but is not limited to, certificate information.

[0045] When generating each block in the blockchain, see Figure 1C When a node device in the blockchain receives input transaction data, it verifies the input transaction data. After verification, it stores the input transaction data in the transaction pool and updates the hash tree (also known as the Merkle tree) used to record the input transaction data. The Merkle tree is a binary tree in which each leaf node contains a hash value in the transaction data set, and each non-leaf node contains a combined hash of the hash values ​​of its child nodes. Afterwards, the update timestamp is updated to the time when the input transaction data was received, and different random numbers are tried, and the eigenvalue calculation is performed multiple times so that the calculated eigenvalue can satisfy the following formula:

[0046] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0047] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input transaction data; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.

[0048] In this way, when a random number that satisfies the above formula is calculated, the transaction data can be stored accordingly, and the block header and block body can be generated to obtain the current block. Subsequently, the node device of the blockchain will send the newly generated block to other node devices in the blockchain network according to the node identification of other node devices in the blockchain network. The other node devices will verify the newly generated block and add it to the blockchain they store after verification.

[0049] From the above-mentioned storage of transaction data on the blockchain, it can be seen that these transaction data are only stored in a single blockchain, and the transaction data includes evidence data, that is, the evidence data is also stored in a single blockchain. In this way, if the blockchain fails or is attacked, it is very likely that the evidence data will be lost or damaged, thereby affecting the reliability and security of the evidence data; at the same time, because the evidence data only depends on a single blockchain, the credibility of the evidence data is limited by the security and stability of the blockchain. If there is a problem with the blockchain, the credibility of the evidence data may also be affected. Based on this, the embodiment of the present application provides a data processing solution. This data processing solution introduces a relay object, and any blockchain network can register with the relay object. After successful registration, the blockchain network and the relay object can establish a connection and generate an evidence certificate (such as a Merkle certificate) for the evidence data stored on the blockchain corresponding to the blockchain network, and store the evidence data and the evidence certificate in the relay object. In this way, the evidence data can be stored not only on the blockchain, but also in the relay object, thereby ensuring the reliability and security of the evidence data and reducing the risk of single point failure. Furthermore, relay objects can include one or more relay nodes, and evidence data can be distributedly stored across one or more relay nodes. This distributed storage of evidence content within relay objects effectively ensures the reliability and security of evidence data, reducing the risk of single points of failure. When querying evidence data, the requesting end can directly retrieve it from the relay object. If the evidence data is stored on multiple blockchains, the confidence level of the evidence data can be determined based on the confidence parameter determination mechanism of each blockchain (i.e., based on the confidence parameters of each blockchain). The introduction of relay objects thus enables the sharing of evidence data across multiple blockchains. This means that blockchains can mutually verify and query evidence data through relay objects, improving the availability and interoperability of evidence data. Furthermore, relay objects allow for direct access to evidence data stored on the corresponding blockchain. This avoids the additional storage and transaction burden imposed on each blockchain by cross-chain data sharing, mitigates security issues associated with cross-chain operations, and reduces cross-chain costs.

[0050] The transaction data involved in this application can be data in any scenario, and the evidence data can be data that is relatively important and needs to be retained in the transaction data. That is, the data processing solution provided by the embodiment of this application can be applied to multiple scenarios, such as data copyright scenarios, supply chain traceability scenarios, cross-chain financial scenarios, Internet of Things scenarios, electronic certificate scenarios, etc. The following uses several specific examples to illustrate the application of the data processing solution provided by the implementation of this application in different scenarios:

[0051] (1) Data copyright scenario:

[0052] In the field of digital content creation (such as literary works, music, pictures, videos, etc.), the evidence data can be copyright information in the field of digital content creation, such as the literary work is written by XX, etc.; the data processing solution provided by the embodiment of this application can help authors store and verify the copyright information of their works in both the blockchain and the relay object.

[0053] (2) Supply chain traceability scenario:

[0054] In supply chain management, evidence data can include information about each link from production to sales of goods, such as information about producers and sellers, areas where goods pass through, and so on. The data processing solution provided by the embodiment of the present application can not only record information about each link involved in the supply chain process on each blockchain, but also store the information about the supply chain process recorded on each blockchain in the relay object, so that full trusted traceability can be achieved. In addition, when the relay object stores the information about the supply chain process recorded on the blockchain, the evidence data is verified through evidence proof (Merkle proof), so that consumers can verify the authenticity and quality of the goods, improving the user experience.

[0055] (3) Cross-chain financial services:

[0056] In the financial field, evidence data can include resource transfer amounts between blockchains, commodity payment information, cross-chain payment information, cross-chain lending information, credit information of objects, and so on. The data processing solution provided by the embodiment of this application can not only store such evidence data on different blockchains, but also store it in relay objects, which can improve the authenticity and reliability of the evidence data, thereby achieving better financial services (cross-chain financial services). In addition, when the evidence data is the credit information or loan information of the object, based on the confidence parameter determination mechanism of each blockchain, financial institutions can more accurately assess the credit status of the object and reduce risks.

[0057] (4) IoT device management:

[0058] In the field of the Internet of Things, evidence data may include device identity authentication, status data, and operation records. In this case, through the data processing solution provided by the embodiment of the present application, not only can these evidence data be stored on the blockchain, but also these evidence data can be stored in relay objects to achieve trusted management of devices. In addition, the embodiment of the present application involves a query unit (such as a distributed cuckoo filter), which allows objects to quickly query device information and improve device management efficiency. In addition, based on the confidence parameter determination mechanism of each blockchain, device manufacturers and service providers can evaluate the security and reliability of devices in real time, improving user experience.

[0059] (5) Application of electronic certificates:

[0060] In areas such as government affairs, education, and healthcare, evidence data can include various electronic certificates (such as various certificates and business licenses). Through the data processing solution provided in the embodiments of this application, not only can these evidence data be stored on the blockchain, but they can also be stored in relay objects, thereby improving the trustworthy verification and security of the certificates. In addition, through evidence proof (Merkle proof), objects (such as users) can quickly verify the authenticity of the certificates, reducing the risk of forgery and tampering. At the same time, the relay object can improve the interoperability of electronic certificates across different fields and systems, simplifying the verification process.

[0061] (6) Internet of Vehicles scenarios

[0062] In the intelligent transportation system scenario or the Internet of Vehicles scenario, the evidence data may include the vehicle's operating status, vehicle's operating trajectory, and so on. Through the data processing solution provided in the embodiment of the present application, not only can these evidence data be stored on the blockchain, but these evidence data can also be stored in the relay object, thereby improving the reliability and security of vehicle-related information. The so-called Intelligent Traffic System (ITS), also known as the Intelligent Transportation System (ITS), is an effective and comprehensive application of advanced science and technology (information technology, computer technology, data communication technology, sensor technology, electronic control technology, automatic control theory, operations research, artificial intelligence, etc.) to transportation, service control, and vehicle manufacturing, strengthening the connection between vehicles, roads, and users, thereby forming a comprehensive transportation system that ensures safety, improves efficiency, improves the environment, and saves energy.

[0063] Next, the data processing system provided in the embodiments of the present application is described.

[0064] See Figure 2, is an architectural diagram of a data processing system provided in an embodiment of the present application. The data processing system includes a relay object 105 and at least one blockchain network (such as Figure 2 The blockchain network 101, blockchain network 102, blockchain network 103 and blockchain network 104 are shown in FIG. 1 ). The relay object can establish a connection with each blockchain network to implement data interaction. The blockchain network may include multiple node devices, and the relay object may include one or more relay nodes, such as Figure 2 In the example of the embodiment of the present invention, when there are multiple relay nodes, the relay object can be a relay cluster composed of multiple relay nodes. It should be understood that the embodiment of the present application does not impose any restrictions on the number of blockchain networks, node devices in the blockchain network, and relay objects. The following is an example of blockchain network 101, in which:

[0065] The blockchain network 101 establishes a connection with the relay object 105 and sends the evidence data stored on the blockchain to the relay object 105 for storage; in addition, when the blockchain network 101 needs to query the evidence data (such as the evidence data on other blockchains), the node devices in the blockchain network 101 can directly query the required evidence data from the relay object, so there is no need to query the evidence data across chains, and the evidence data can be quickly obtained.

[0066] The relay nodes in the relay object can interact with node devices in the blockchain network 101, such as obtaining the evidence data on the blockchain maintained by the node devices and generating evidence certificates for the evidence data to verify the authenticity of the evidence data. In addition, the relay nodes can monitor whether new blocks are generated on the blockchain corresponding to the blockchain network 101. If a new block is generated, they can also obtain the evidence data in the new block (hereinafter referred to as the update block) for storage.

[0067] It should be understood that a node device can be a terminal device or a server, and a relay node can be a terminal device or a server. The above-mentioned terminal devices can be smartphones, tablets, laptops, desktop computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, etc.

[0068] Among them, see Figure 3, is a schematic diagram of the structure of a relay node provided in an embodiment of the present application. The relay node in the relay object deploys multiple modules to store the evidence data on the blockchain corresponding to each blockchain network. The following is a detailed introduction to each module of the relay node:

[0069] 1.1 Service Interface Module

[0070] The service interface module is used to provide an interface for interacting with external systems. Schematically, the external systems can be various blockchain networks. The service interface module can include the following submodules: a certificate verification interface, a data acquisition interface, and a blockchain registration interface.

[0071] 1.1.1 Evidence Verification Interface

[0072] This interface is used to verify the authenticity of stored evidence. An object (such as a user) can submit the stored evidence hash of the stored evidence data. The relay node can call the evidence verification interface to query the corresponding stored evidence data based on the stored evidence hash and use the evidence proof to verify the authenticity of the stored evidence data.

[0073] 1.1.2 Data Acquisition Interface

[0074] This interface is used to obtain evidence data. An object (e.g., a user) submits the evidence hash of the evidence data. The relay node queries and returns the evidence data corresponding to the evidence hash through the data acquisition interface. Optionally, it can also return metadata and verification data for the evidence data. Alternatively, an object can submit the evidence hash and related metadata for the evidence data. The relay node can query and return the evidence data corresponding to the evidence hash based on the evidence hash and related metadata through the data acquisition interface.

[0075] 1.1.3 Blockchain Registration Interface

[0076] This interface is used to establish a communication connection with the blockchain network, or to connect the blockchain network to the relay object to establish a connection with the blockchain network. The blockchain service provider or blockchain management platform submits node information of the node device in the blockchain network through this blockchain registration interface. The node information includes at least one of the following: connection information (such as network address (such as IP address), port), and certificate information. The relay node registers the blockchain network with the relay object based on the node information through this blockchain registration interface and activates the data collection module to collect the evidence data stored in the blockchain corresponding to the blockchain network.

[0077] 1.2 Data Acquisition Module

[0078] The data collection module is responsible for collecting evidence data from the node devices corresponding to each blockchain. The data collection module includes the following submodules: blockchain node client plug-in, block transaction parser, and evidence proof generator; among them:

[0079] 1.2.1 Blockchain node client plug-in

[0080] This plugin collects transaction data from the blockchain network. Each blockchain corresponds to a specific blockchain node client plugin. The blockchain node client plugin monitors the blockchain for newly generated blocks and sends them to the block transaction parser on the relay node.

[0081] 1.2.2 Block Transaction Parser

[0082] The block transaction parser is used to parse blocks, obtain transaction data, and extract evidence data from the transaction data. Based on a predefined evidence data storage structure, the block transaction parser parses the evidence data, evidence hash, and metadata contained in the transaction data. Metadata includes any one or more of the blockchain information on which the evidence data resides and attribute information about the evidence data. Blockchain information can include, for example, the block hash, block height, and source blockchain network. Attribute information can include, for example, the size of the evidence data and the file type of the evidence data.

[0083] 1.2.3 Evidence Proof Generator

[0084] The Evidence Proof Generator is used to generate an evidence proof (such as a Merkle proof) to prove the authenticity of the evidence data. The Evidence Proof Generator is used to calculate the path of the transaction data in the Merkle tree based on the Merkle tree on the blockchain and return this path as a Merkle proof to the Evidence Verification Module. It should be understood that the transaction data includes the evidence data, so the path of the transaction data in the Merkle tree is also the path of the evidence data in the Merkle tree.

[0085] 1.3 Evidence Verification Module

[0086] The evidence verification module is used to verify the authenticity and completeness of the evidence data based on the collected evidence data and evidence certificates.

[0087] 1.4 Storage Module

[0088] The storage module is used to store and manage evidence data. The storage module includes the following submodules: a query unit, a cache unit, an evidence hash and URL mapping table, and a storage unit; wherein:

[0089] 1.4.1 Query Unit

[0090] The query unit is used to quickly query whether the evidence data exists in the relay object. The query unit can realize efficient query and verification of the evidence data. Among them, the query unit can be a cuckoo filter. When the evidence data is distributed and stored in each relay node in the relay object, the query unit can be a distributed cuckoo filter. The cuckoo filter is a probabilistic data structure used to efficiently store and query elements in a set. It is an improvement on the Bloom filter, providing higher space efficiency and lower false alarm rate. The distributed cuckoo filter is to apply the cuckoo filter to a distributed system (such as the relay object in the embodiment of the present application). By storing and querying data on multiple nodes, it realizes efficient processing of large-scale data sets. In the embodiment of the present application, the distributed cuckoo filter is used to quickly determine whether the evidence data exists in the relay object, reducing query time and network overhead. The query unit is used to store the evidence hash of the evidence data and, upon receiving a data query request for a certain evidence data, determine whether it is in the relay object and return the query result.

[0091] 1.4.2 Cache Unit

[0092] The cache unit is used to cache hotspot evidence data to quickly respond to query requests, thereby improving the query efficiency of evidence data. The so-called hotspot evidence data refers to evidence data with an access frequency greater than the corresponding frequency threshold. For example, if a certain evidence data is accessed 100 times in 2 minutes and the access frequency of this evidence data is greater than the frequency threshold, then this evidence data is considered hotspot evidence data and the cache unit can cache this evidence data. Optionally, the cache unit can store the evidence data in memory based on the access frequency and time of the evidence data in order to respond to query requests.

[0093] 1.4.3 Evidence Hash and Address Information Mapping Table

[0094] The evidence hash and address information mapping table is used to store the mapping relationship between the full evidence hash in the relay object and its corresponding address information. The address information here is used to indicate the address in the storage unit where the evidence data corresponding to the corresponding evidence hash is stored; when the object queries the evidence data, it can find the corresponding address information through the evidence hash of the evidence data, and thus obtain detailed information about the evidence data based on the address information. Illustratively, the address information can be a URL (Uniform Resource Locator).

[0095] 1.4.4 Storage Unit

[0096] The storage unit is used to store the evidence data in a distributed manner in the relay object. Through distributed storage technology, the high availability and fault tolerance of the evidence data in the relay object are ensured, reducing the risk of single point failure.

[0097] 1.4.5 Blockchain Certificate and Connection Storage Module

[0098] The Blockchain Certificate and Connection Storage module manages the node information of each blockchain's corresponding node devices. When a new blockchain network joins the relay object through the blockchain registration interface, the Blockchain Certificate and Connection Storage module stores the node information of the corresponding blockchain node devices for subsequent evidence data collection and verification.

[0099] 1.5 Cluster Monitoring and Management Module

[0100] The cluster monitoring and management module is responsible for real-time monitoring and management of each relay node, including the following modules: node indicator collection module, node management module, and node monitoring visualization module, among which:

[0101] 1.5.1 Node indicator collection module

[0102] This module is used to collect the operating indicators of relay nodes, such as CPU usage, memory usage, disk usage, etc. These indicators will be used to evaluate the performance and stability of relay nodes and provide decision-making basis for the node management module.

[0103] 1.5.2 Node Management Module

[0104] This module is used to manage the working status of relay nodes. The node management module can expand, shrink, and replace relay nodes based on node indicators and business needs to ensure high availability and stability of the cluster.

[0105] 1.5.3 Node Monitoring Visualization Module

[0106] This module provides a visual monitoring interface that displays the real-time operating status and performance indicators of relay nodes. Administrators can use the monitoring interface to understand the operating status of the cluster and promptly identify and address potential problems.

[0107] In summary, the collaborative work of these modules enables efficient query, verification, and storage of multi-chain trusted evidence, providing secure and reliable trusted evidence services for objects. At the same time, the cluster monitoring and management module ensures the high availability and stability of the entire relay object.

[0108] Based on the above-mentioned data processing system and multiple modules deployed by the node devices, the data processing process provided by the embodiment of the present application is described below. The data processing process provided by the embodiment of the present application includes the following three parts: (1) the blockchain network registers with the relay object; (2) the relay object monitors the evidence data in the blockchain network and stores it in a distributed manner in the relay object; (3) the evidence data query and verification process (i.e. the object queries and verifies the evidence data through the client or smart contract. The following will be described one by one:

[0109] (1) Blockchain network registers with relay objects: see Figure 4 , is a schematic diagram of a blockchain network registration process for a relay object provided in an embodiment of the present application. The blockchain network registration process for a relay object includes the following steps:

[0110] S1. The blockchain management platform collects node information from each node device in the blockchain network. This node information includes at least one of the following: connection information and certificate information. In one implementation, the blockchain management platform can manage at least one blockchain network. This management includes monitoring the operating status of node devices in the blockchain network and collecting node device certificate information. This will be explained below using the example of blockchain network 101 registering with a relay object.

[0111] S2. The blockchain management platform sends a registration request to the relay object, where the registration request includes node information of each node device in the blockchain network 101. In one implementation, the blockchain management platform sends the registration request to any relay node in the relay object.

[0112] S3. The relay node in the relay object calls the blockchain registration interface in the service interface module to receive the registration request.

[0113] S4. In response to the registration request, the service interface module in the relay node verifies whether it can properly connect to the node device in the blockchain network 101. If a proper connection is established with the node device in the blockchain network, step S6 is executed; otherwise, step S5 is executed. A proper connection means that the relay node and the node device can establish communication and exchange information.

[0114] S5. The relay node returns a prompt message to the blockchain management platform indicating an abnormal connection with the node device in the blockchain network 101.

[0115] S6. The relay node obtains the configuration block from the node device. The configuration block stores configuration information about all node devices in the blockchain network 101. The configuration information includes: certificate information of the node device, etc.

[0116] S7. The relay node compares the certificate information of the node device in the configuration information with the certificate information in the node information of the corresponding node device. If the certificate information of the node device in the configuration information is consistent with the certificate information in the node information of the corresponding node device, execute step S9; otherwise, execute S8.

[0117] S8. The relay node returns a certificate verification exception prompt to the blockchain management platform.

[0118] S9. The relay node checks whether the certificates of each node device are issued by a trusted certificate authority. If the certificates of each node device are issued by a trusted certificate authority, S11 is executed. If the certificates of any node device are not issued by a trusted certificate authority, S10 is executed. The trusted certificate authority can be pre-set.

[0119] S10. The relay node returns a prompt message to the blockchain management platform indicating that the node device’s certificate is untrustworthy.

[0120] S11. The storage module in the relay node stores the node information of each node device. In one implementation, the storage module in the relay node can store the node information of each node device in the blockchain certificate and connection storage module.

[0121] S12. The relay node forwards the node information of each node device to other relay nodes. In one implementation, upon receiving the node information of each node device, the other relay nodes may directly store the street store information of each node device. In another implementation, upon receiving the node information of each node device, the other relay nodes may verify the certificate information of each node device and verify whether the certificate of each node device is issued by a trusted certificate authority. If the certificate of each node device is verified successfully, the other relay nodes may store the node information of each node device.

[0122] S13. Determine whether all relay nodes have successfully stored the node information of each node device. If all relay nodes have successfully stored the node information of each node device, execute step S15; if there is a relay node that fails to store the node information of each node device, execute step S14.

[0123] S14. When any relay node determines that there is another relay node that fails to store the node information of each node device, the relay node that has stored the node information needs to delete the blockchain certificate and the node information of each node device in the connected storage module, and return a prompt message of synchronization abnormality to the blockchain management platform.

[0124] S15. The blockchain network 101 successfully registers with the relay object and successfully establishes a connection with the relay object. The relay node can return a prompt message indicating successful registration to the blockchain management platform.

[0125] To sum up, any blockchain network can initiate a registration request to the relay object according to the registration process of the above-mentioned blockchain network 101, thereby establishing a connection with the relay object. In this way, the relay object can store the evidence data on the blockchain corresponding to the blockchain network, thereby improving the security of the evidence data.

[0126] (2) Relay objects monitor the evidence data in the blockchain network and store it in distributed form in relay objects: Figure 5 , which is a schematic diagram of a process for storing evidence data on a blockchain into a relay object provided by an embodiment of the present application. Here, blockchain network 101 is also used as an example to illustrate that the process for storing evidence data on a blockchain into a relay object includes the following steps:

[0127] S21. The master relay node in the relay object can query the node devices in the blockchain network 101 for the current block height of the blockchain corresponding to the blockchain network 101. The current block height refers to the block height of the most recently generated block on the blockchain. Specifically, the master relay node includes a blockchain node client plug-in; the master relay node calls the blockchain node client plug-in corresponding to the blockchain through the data acquisition module, and the blockchain node client plug-in calls the data acquisition interface in the service interface module to query the node devices in the blockchain network 101 for the current block height. The master relay node can be any relay node in the relay object, or it can be a relay node voted by the relay nodes in the relay object. The embodiment of the present application does not impose any restrictions on the method for determining the master relay node.

[0128] In one implementation, the master relay node can query the node devices in the blockchain network 101 in real time for the current block height of the blockchain corresponding to the blockchain network 101. In another implementation, the node devices in the blockchain network 101 are queried for the current block height of the blockchain corresponding to the blockchain network 101 at regular intervals (e.g., every 1 hour, 30 minutes, etc.). In the embodiment of the present application, a timing device (e.g., a timer) can be set for each blockchain network. Schematically, the blockchain corresponding to the blockchain network 101 is set with a timing device. When the timer corresponding to the timing device arrives, the master relay node can query the node devices in the blockchain network 101 for the current block height of the blockchain corresponding to the blockchain network 101.

[0129] S22. The master relay node may determine whether the current block height is greater than the recorded block height of the blockchain network in the relay object. The recorded block height refers to the block height of the blockchain network 101 that has been obtained and recorded in the relay object. If the current block height is greater than the recorded block height, step S24 is executed. If the current block height is less than or equal to the recorded block height, step S23 is executed.

[0130] S23. The master relay node continues to monitor whether there is a newly generated block on the blockchain.

[0131] S24. The blockchain node client plug-in in the master relay node invokes the data acquisition interface in the service interface module to obtain an updated block from the node device in blockchain network 101. An updated block refers to a block whose height is greater than the recorded block height. It should be understood that the number of updated blocks may be one or more. For example, if the recorded block height is 3 and the current block height is 5, this means that two updated blocks have been recently generated on the blockchain. At this point, the blockchain node client plug-in invokes the data acquisition interface in the service interface module to obtain these two updated blocks from the node device in blockchain network 101.

[0132] S25. The block transaction parser in the data collection module of the master relay node parses and updates all transaction data in the block; each transaction data may include stored evidence data.

[0133] S26. The proof generator generates a proof of all the evidence data in the updated block.

[0134] S27. The data collection module in the main relay node packages the evidence data, metadata, and evidence certificate in each transaction data to obtain the target storage data of each evidence data.

[0135] S28. The storage module in the master relay node dynamically distributes the target storage data of each evidence data to different relay nodes for storage based on the evidence hash.

[0136] In one implementation, the target storage data of each evidence data can be dynamically distributed to different relay nodes for storage according to a certain number of backups. For example, if the number of backups is 4, then the target storage data of each evidence data can be distributed to 4 different relay nodes for storage. It should be understood that the number of relay nodes and the relay nodes used to store the target storage data of each evidence data can be the same or different. Figure 6 FIG. 1 is a schematic diagram of a distributed storage of relay objects provided by an embodiment of the present application. Figure 6In the example, the relay object may include three relay nodes (i.e., relay node 1, relay node 2, and relay node 3), and each relay node will deploy a query unit, a storage unit, a cache unit, and a mapping table of evidence hash and address information. The target storage data of evidence data 1, the target storage data of evidence data 2, the target storage data of evidence data 4, and the target storage data of evidence data 6 can be stored in the storage unit of relay node 1; the target storage data of evidence data 1, the target storage data of evidence data 3, the target storage data of evidence data 5, and the target storage data of evidence data 6 can be stored in the storage unit of relay node 2; the target storage data of evidence data 2, the target storage data of evidence data 3, the target storage data of evidence data 4, and the target storage data of evidence data 5 can be stored in the storage unit of relay node 3.

[0137] S29. Each relay node stores the evidence hash corresponding to the corresponding target storage data in the query unit.

[0138] S30. Each relay node stores the evidence hash and the target storage data of the evidence data in the storage unit.

[0139] S31. Each relay node obtains the address information of the target storage data in the storage unit when storing the evidence data. Schematically, the address information may be a URL.

[0140] S32. Each relay node broadcasts the mapping relationship between the evidence hash and the address information in the storage unit when the storage target stores data.

[0141] S33. After receiving the mapping relationship between the evidence hash and address information broadcast by other relay nodes, any relay node stores the mapping relationship. Specifically, any relay node maintains a mapping table of evidence hash and address information, which stores the mapping relationship between the full amount of evidence hash and address information. After receiving the mapping relationship, any relay node can store the mapping relationship in the mapping table of evidence hash and address information, for example Figure 6 In the evidence hash and address information mapping table maintained by relay node 1, relay node 2 and relay node 3, the address information of the evidence data when it is stored in the storage unit of other relay nodes is stored. In this way, according to the mapping table, the storage location of any evidence data can be determined, thereby facilitating the subsequent search for the required evidence data.

[0142] S34. The master relay node determines whether the target storage data of the evidence data has been successfully stored in the relay node. If the target storage data of the evidence data has failed to be stored in the relay node, step S35 is executed. The reason for the storage failure may be a relay node failure or insufficient memory resources. If the target storage data of the evidence data has been successfully stored in the relay node, step S36 is executed.

[0143] S35. The master relay node sends a notification message to each relay node, which is used to notify the target relay node storing the evidence data to roll back the failed content, that is, to restore to the state before the target storage data stored the evidence data.

[0144] S36: Determine that the target storage data of the evidence data is successfully stored.

[0145] In summary, the embodiments of the present application can store the evidence data in multiple blockchains in a relay object. This can, to a certain extent, avoid the data problems caused by storing the evidence data on a single blockchain, which makes it difficult to share data between different blockchains. This improves the availability and value of the evidence data and avoids the transaction burden brought by some cross-chain operations that can achieve data sharing. In addition, it can also avoid the problem that the stored evidence data fails or is attacked on the blockchain, resulting in the loss or damage of the evidence data, thereby affecting the reliability and security of the evidence data, thereby greatly improving the security and reliability of the evidence data. In addition, by storing the evidence data both on the blockchain and in the relay object, the problem of credibility being limited by the security and stability of the blockchain is solved, and the credibility of the evidence data can also be improved.

[0146] (3) Evidence data query and verification process: Figure 7 FIG. 1 is a flow chart of querying and verifying stored evidence data provided by an embodiment of the present application. The process of querying and verifying stored evidence data includes the following steps:

[0147] S41. The requesting end may send a data query request to a relay node in the relay object. The data query request carries the target evidence hash and is used to request the evidence data corresponding to the target evidence hash. In one implementation, the requesting end may send the data query request to the relay node by invoking a client or a smart contract. It should be understood that for the sake of convenience in the following description, the relay object that receives the data query request sent by the requesting end is referred to as the requesting relay node.

[0148] S42. In response to the data query request, the evidence verification interface of the requesting relay node invokes the evidence validation module to query the home relay node for the target evidence hash. In one implementation, the requesting relay node maintains a mapping table between evidence hashes and address information. The requesting relay node can retrieve the address information corresponding to the target evidence hash from the mapping table and parse the address information to determine the home relay node for the target evidence hash.

[0149] S43. The requesting relay node determines whether the home relay node is itself (ie, the requesting relay node). If so, step S45 is executed, otherwise step S44 is executed;

[0150] S44 requests the relay node to forward the data query request to the home relay node;

[0151] S45. The home relay node queries the storage unit of the storage module to determine whether the target evidential hash is stored in the relay object. If the target evidential hash is found to be stored in the relay object, it means that the evidential data corresponding to the target evidential hash exists in the storage unit, and S47 is executed. If the target evidential hash is not found to be stored in the relay object, it means that the evidential data corresponding to the target evidential hash does not exist in the storage unit, and S46 is executed. Specifically, if the evidential hash is stored in the storage unit, the home relay node may query whether the target evidential hash is in the storage unit. If so, it determines that the target evidential hash is stored in the relay object. If not, it determines that the target evidential hash is not stored in the relay object.

[0152] S46. The home relay node returns a prompt result indicating that the data does not exist, and executes step S52.

[0153] S47. The home relay node successfully queries the cache unit for the evidential data corresponding to the target evidential hash. If successful, step S48 is executed. It should be understood that the evidential data corresponding to the target evidential hash can be obtained from the stored data of the evidential data stored in the cache unit. If the query of the evidential data corresponding to the target evidential hash from the cache unit fails, step S49 is executed.

[0154] S48. The home relay node returns the evidence data corresponding to the target evidence hash queried from the cache unit and executes step S52.

[0155] S49. The home relay node successfully queries the storage unit for the evidential data corresponding to the target evidential hash. If successful, step S51 is executed. It should be understood that the evidential data corresponding to the target evidential hash can be obtained from the storage data stored in the storage unit. If the evidential data corresponding to the target evidential hash fails to be queried from the storage unit, step S50 is executed.

[0156] S50. The home relay node returns a prompt message indicating that the evidence data does not exist, and executes step 52;

[0157] S51. The home relay node returns the evidence data corresponding to the target evidence hash queried from the storage unit and executes step S52.

[0158] S52. Determine whether the home relay node is a requesting relay node. If not, execute step S53; if so, execute step S54.

[0159] S53. The home relay node returns the result to the request relay node. The result here may include: a prompt message that the evidence data does not exist or the result includes the evidence data corresponding to the target evidence hash.

[0160] S54. Request the relay node to invoke the evidence verification module and return the result to the requesting client. If the result includes a prompt indicating that the evidence data does not exist, then this prompt is returned to the requesting client. If the result includes evidence data, the evidence data may be returned to the requesting client. In one implementation, the evidence data and a result indicating whether the evidence data is trustworthy may be packaged into a return value, which is then returned to the requesting client. Optionally, verification data or metadata corresponding to the evidence data may also be returned to the requesting client.

[0161] In summary, the requesting end can directly obtain the evidence data from the relay object, which solves the data island problem caused by the difficulty in sharing data between different blockchains, improves the convenience of information exchange between blockchains, and improves the availability and value of data. In addition, it can avoid the use of cross-chain technology to achieve data sharing between different blockchains, which brings additional storage and transaction burdens to each chain. It can solve the need to deal with complex protocols and security issues in cross-chain operations and reduce the cost of cross-chain data acquisition. It should be understood that in the embodiment of the present application, any blockchain network can access the relay object. The embodiment of the present application can better adapt to the trusted evidence needs in a multi-chain environment. With the development of blockchain technology and the increase in application scenarios, the scalability is significantly improved compared to the single-chain evidence solution.

[0162] Next, the data processing method provided in the embodiments of the present application is described.

[0163] See Figure 8 , is a flow chart of a data processing method provided in an embodiment of the present application. The data processing method is applied to a relay object, which includes one or more relay nodes. The data processing method provided in an embodiment of the present application can be executed by any relay node in the relay object. The data processing method provided in an embodiment of the present application may include the following steps S801-S805:

[0164] S801. Obtain the current block height of the blockchain corresponding to the target blockchain network; the target blockchain network is any blockchain network among N blockchain networks.

[0165] The current block height refers to the height of the most recently generated block on the blockchain corresponding to the target blockchain network. The relay object can connect to N blockchain networks, and after the connection, the blockchain network and the relay object exchange data, where N is a positive integer. When a blockchain network needs to establish a connection with the relay object, the blockchain network must register with the relay object. In one implementation, the blockchain management platform or the target blockchain network can send a registration request to the relay object, which includes the node information of each node device in the target blockchain network. In response, the relay object can receive the registration request for the target blockchain network and, in response to the registration request, verify each node device based on its node information. If each node device passes verification, the node information of each node device is stored in the relay object, indicating that the target blockchain network has successfully registered with the relay object and confirming that the blockchain network has established a connection with the relay object. If any node device fails verification, indicating that the target blockchain network has failed to register with the relay object, a registration failure prompt message is returned. The node information can include certificate information and connection information, with the connection information including at least one of the following: the node device's network address (e.g., IP address) and port.

[0166] Among them, the verification process of each node device based on the node information of each node device includes at least one of the following: (1) based on the network address of each node device, try to establish a connection with each node device. If the connection is successfully established with each node device, the verification of each node device is passed. If the connection with each node device fails, the verification of each node device fails. (2) Obtaining a configuration block from the blockchain corresponding to the target blockchain network, in which the configuration block stores the configuration information of each node device; verifying each node device based on the configuration information and node information of each node device. In one implementation, the configuration information includes the certificate information of the node device. The certificate information in the node information of each node device can be compared with the certificate information in the configuration information of each node device. If the certificate information in the node information of each node device is consistent with the certificate information in the configuration information of each node device, the verification of each node device is passed; if the certificate information in the node information of any node device is inconsistent with the corresponding certificate information in the configuration information, the verification of each node device fails. In another implementation, if the certificate information in the node information of each node device is consistent with the certificate information in the configuration information of each node device, it is also possible to verify whether the certificate of each node device is issued by a trusted certificate authority; if the certificate of each node device is issued by a trusted certificate authority, the verification of each node device is passed; if there is a node device whose certificate is not issued by a trusted certificate authority, the verification of each node device fails.

[0167] Among them, storing the node information of each node device in the relay object may include: sending the node information of each node device to all relay nodes in the relay object, so that all relay nodes store the node device information in their own blockchain certificates and connection storage modules.

[0168] In one implementation, obtaining the current block height of the blockchain corresponding to the target blockchain network includes: upon the expiration of the timer corresponding to the relay node timer in the relay object, sending a block query request to a node device in the target blockchain network, wherein the block query request is used to trigger the node device in the target blockchain network to return the current block height of the blockchain; and receiving the current block height of the blockchain returned by the node device in the target blockchain network based on the block query request. Of course, embodiments of the present application can also obtain the current block height of the blockchain corresponding to the target blockchain network in real time.

[0169] S802. If the current block height is greater than the recorded block height of the target blockchain network in the relay object, then based on the recorded block height and the current block height, obtain an updated block from the blockchain corresponding to the target blockchain network, and the block height of the updated block is greater than the recorded block height.

[0170] The recorded block height refers to the block height that the relay object has retrieved from the target blockchain network. When the target blockchain network has just established a connection with the relay object, the recorded block height is considered empty. The number of update blocks can be one or more. Specifically, the relay node in the relay object can send a block acquisition request including the recorded block height to a node device in the target blockchain network. The node device can then query the blockchain for an update block with a block height greater than the recorded block height and return the updated block to the relay node in the relay object.

[0171] S803. Generate a proof of evidence for the evidence data included in the updated block based on the Merkle tree corresponding to the updated block.

[0172] The evidence proof is used to verify whether the evidence data exists in the blockchain corresponding to the target blockchain network, thereby ensuring the credibility and authenticity of the evidence data. A Merkle tree is used to store one or more transaction data. The Merkle tree is a binary tree in which each leaf node contains the hash value of a transaction data set. In one implementation, based on the Merkle tree corresponding to the update block, an evidence proof of the evidence data included in the update block is generated, including: parsing the update block to obtain transaction data, wherein the transaction data includes the evidence data; determining the path of the transaction data in the Merkle tree based on the Merkle tree corresponding to the update block; and generating an evidence proof of the evidence data based on the path of the transaction data in the Merkle tree. It should be understood that the transaction data includes the evidence data, and the path of the transaction data in the Merkle tree is also the path of the evidence data in the Merkle tree. Therefore, in the embodiments of the present application, the path of the transaction data in the Merkle tree can be used as the evidence proof of the evidence data, and the evidence proof of the evidence data can be a Merkle proof. Merkle proofs allow you to verify the existence of a piece of evidence in a Merkle tree without having to know the details of the entire set of evidence. By verifying that the evidence exists in the blockchain corresponding to the target blockchain network, Merkle proofs can effectively ensure the credibility and authenticity of the evidence.

[0173] S804. Generate target storage data for the evidence data based on the evidence data and evidence proof included in the update block.

[0174] In one implementation, generating target storage data for the evidence data based on the evidence data and evidence proof included in the update block includes: verifying the evidence data included in the update block based on the evidence proof. Specifically, determining the root node of a Merkle tree based on the evidence hash and the evidence proof. If the root node of the determined Merkle tree is consistent with the root node of the Merkle tree itself, the verification passes, indicating that the evidence data is on the blockchain corresponding to the target blockchain network. Otherwise, the verification fails. If the verification passes, the evidence data and evidence proof included in the update block are packaged according to the evidence data storage structure to obtain the target storage data for the evidence data.

[0175] The evidence data storage structure includes: data hash field (dataHash), metadata field (metadata), and verification data storage field (verificationData).

[0176] The data hash field is used to store the evidence hash of the evidence data, which is used to uniquely identify and verify the evidence data.

[0177] The metadata field is used to store metadata for the evidence data. Metadata includes any one or more of the following: blockchain information on which the evidence data resides and attribute information about the evidence data. The blockchain information on which the evidence data resides includes at least one of the following: the timestamp when the evidence data was stored on the blockchain, the blockchain network from which the evidence data originated, the block height at which the evidence data was recorded, the block hash containing the evidence data, the identifier of the transaction data storing the evidence data on the blockchain, the signer who signed the evidence data, and the signature information. Attribute information for the evidence data includes at least one of the following: the size of the evidence data, the file type of the evidence data (e.g., file types such as text, image, audio, etc.), the file extension of the evidence data (e.g., if the file type is text, the file extension is .txt; if the file type is image, the file extension is .jpg; if the file type is audio, the file extension is .mp3), the owner of the evidence data, a brief description of the evidence data, and so on.

[0178] The metadata field may include at least the following fields: ① Timestamp field (timestamp): used to store the timestamp when the evidence data is stored in the blockchain; ② Source field (sourceChain): used to store the blockchain network of the source of the evidence data; ③ Block height field (blockHeight): used to store the block height of the block where the evidence data is recorded; ④ Block hash field (blockHash): used to store the block hash containing the evidence data; ⑤ Transaction identification field (transactionID): used to store the identifier of the transaction data when the evidence data is stored on the blockchain; ⑥ Signature field (signatures): used to store the signature and signature information for signing the evidence data; ⑦ Data field (dataSize): used to store the size of the evidence data; ⑧ File type field (fileType): used to store the file type of the evidence data; ⑨ Data extension field (fileExtension): used to store the file extension of the evidence data; ⑩ Object field (dataOwner): used to store the owner of the evidence data; Description field (dataDescription): used to store descriptive information about the evidence data.

[0179] The verification data storage field is used to store verification data, which is used to verify whether the evidence data exists in the blockchain corresponding to the target blockchain network. The verification data includes any one or more of the evidence proof and the transaction information of the transaction data associated with the evidence data. The verification data storage field includes a proof field (merkleProof) and a transaction field (anchorTransaction). The proof field is used to store the Merkle proof, and the transaction field is used to store the transaction information of the transaction data associated with the evidence data. The transaction information includes the transaction identifier, the block hash of the transaction data, and the block height of the transaction data. The authenticity of the evidence data can also be verified through the transaction information of the transaction data. The evidence data storage structure can be shown in Table 2:

[0180] Table 2

[0181]

[0182]

[0183] S805: Perform storage processing on the target storage data.

[0184] The storage processing of target storage data includes the following implementation methods:

[0185] Method 1: performing storage processing on the target storage data includes: distributing and storing the target storage data in all relay nodes included in the relay object. That is, each relay node can store the target storage data.

[0186] Method 2: An embodiment of the present application may provide a dynamic distribution mechanism, which may dynamically determine one or more target relay nodes for different evidence data. In one implementation, one or more target relay nodes are determined from one or more relay nodes included in the relay object to store the target storage data. Storage processing of the target storage data includes: determining one or more target relay nodes for storing the target storage data from one or more relay nodes according to the dynamic distribution mechanism, and storing the target storage data in one or more target relay nodes. By storing the target storage data in multiple relay nodes, the reliability and security of the evidence data are ensured, and the risk of single point failure is reduced.

[0187] Indicative, such as Figure 9 As shown in FIG, a flow chart of a plurality of relay nodes storing data provided by an embodiment of the present application is provided. The relay objects include relay node 1, relay node 2, and relay node 3. At this time, relay node 2 obtains 5 evidence data from the target blockchain network and generates storage data for each evidence data, which are represented as: tx0-tx4 respectively. Relay node 2 uses a dynamic distribution mechanism to store these 5 storage data in the corresponding target relay nodes, as shown in FIG. Figure 9 In the example, tx0, tx1, tx3 and tx4 are stored in relay node 2; tx0, tx2 and tx4 are stored in relay node 1; tx1, tx2 and tx3 are stored in relay node 3.

[0188] In one implementation, each relay node is equipped with a query unit and a storage unit. The query unit is used to store the evidential hash of the evidential data and to quickly verify whether the evidential data corresponding to the evidential hash is stored in the relay object or relay node. The storage unit is used to store the evidential hash and the corresponding storage data. Storing the target storage data in one or more target relay nodes may specifically include: inserting the evidential hash of the evidential data into the query unit of each target relay node; and storing the evidential hash of the evidential data and the target storage data in the storage unit of each target relay node.

[0189] The dynamic distribution mechanism may include a backup quantity mechanism, a data backup parameter mechanism, etc. According to the dynamic distribution mechanism, determining one or more target relay nodes for storing target storage data from one or more relay nodes may include the following implementations:

[0190] (1) Backup Quantity Mechanism: The backup quantity of the evidence data is set. Determining one or more target relay nodes for storing the target data from one or more relay nodes includes selecting relay nodes that meet the backup quantity from the multiple relay nodes as target relay nodes. For example, if the backup quantity is three, three relay nodes must be selected from the multiple relay nodes as target relay nodes.

[0191] (2) Data backup parameter mechanism: The target relay node is determined based on the data backup parameters of each relay node. The data backup parameters include at least one of the following: business type, smart contract type, and node status. The node status may include but is not limited to: CPU (Central Processing Unit) usage, memory usage, disk usage, etc.

[0192] In this implementation, determining one or more target relay nodes for storing target storage data from one or more relay nodes includes: obtaining data backup parameters of each relay node, the data backup parameters including at least one of the following: business type, smart contract type, and node status; and determining one or more target relay nodes for storing target storage data from one or more relay nodes based on the data backup parameters.

[0193] (1) If the data backup parameters include a business type, that is, each relay node corresponds to a business type, then the relay node that matches the business type of the evidence data is determined as the target relay node. Specifically, the business type of the evidence data can be determined, and a relay node that matches the business type of the evidence data is determined from multiple relay nodes as the target relay node. The business type can be, for example, insurance business, inquiry business, loan business, etc. Schematically, the relay object includes three relay nodes, where relay node 1 and relay node 2 correspond to the insurance business type. Assuming that the evidence data is insurance-related certification information, and the business type of the evidence data is the insurance business type, then relay node 1 and relay node 2 corresponding to the insurance business type can be selected from the three relay nodes as the target relay nodes.

[0194] (2) If the data backup parameters include the smart contract type, that is, each relay node corresponds to a smart contract type, then the relay node that matches the smart contract type called when processing the evidence data will be used as the target relay node. Specifically, the smart contract type called when processing the evidence data can be determined, and the relay node that matches the smart contract type can be determined from multiple relay nodes as the target relay node. The smart contract type can be, for example, an insurance-type smart contract, a smart contract that processes commodity sales, and so on. Schematically, the relay object includes three relay nodes, wherein relay node 1 and relay node 2 correspond to insurance-type smart contracts. Assuming that an insurance-type smart contract needs to be called when processing the evidence data, relay node 1 and relay node 2 can be selected from the three relay nodes as target relay nodes.

[0195] (3) If the data backup parameters include node status, a relay node is selected from one or more relay nodes as a target relay node based on the node status of each relay node. In one implementation, the node status is used to indicate the current memory usage of the corresponding relay node, and a relay node with a smaller current memory usage can be selected as the target relay node. In another implementation, the node status is used to indicate whether the corresponding node device is in a normal operating state, and a relay node that is currently in a normal operating state can be selected as the target relay node.

[0196] It should be understood that in an embodiment of the present application, the target relay node for storing the target storage data can be determined based on at least two of the business type, the smart contract type, and the node status. Schematically, the target relay node is determined from one or more relay nodes based on the business type and the node status, such as selecting a relay node that matches the business type of the evidence data and has a smaller memory footprint as indicated by the node status as the target relay node. In addition, the data backup parameters and the number of backups can also be combined to determine the target relay node from multiple relay nodes. Specifically, based on the data backup parameters, multiple candidate relay nodes for storing the target storage data are determined from multiple relay nodes, and then based on the number of backups, one or more target relay nodes for storing the target storage data are determined from the multiple candidate relay nodes. The embodiment of the present application does not impose any limitation on the implementation method of determining one or more target relay nodes for storing the target storage data.

[0197] Optionally, after a relay node successfully stores the target storage data of the evidence data, it is necessary to broadcast the address information of the target storage data in the relay node's storage unit to other relay nodes in the relay object, so that other relay nodes store this address information so that the location of the evidence data can be determined later. Specifically, the address information of the target storage data in the relay node's storage unit is obtained. A notification message is sent to each relay node, carrying the address information of the target storage data in the relay node's storage unit. The notification message is used to trigger all relay nodes in the relay object to store the mapping relationship between the evidence hash and the address information of the evidence data.

[0198] Optionally, the relay nodes in the relay object are deployed with a cache unit, which is used to store evidence data with an access frequency greater than a frequency threshold. The frequency threshold can be set as needed. Specifically, the relay node can obtain the access frequency of the evidence data it stores and store the evidence data with an access frequency greater than the frequency threshold and the evidence hash in the cache unit. In this way, when the evidence data is accessed again, the evidence data can be quickly retrieved from the cache unit, improving the efficiency of evidence data acquisition. Of course, the storage data of the evidence data can also be stored in the cache unit, and the storage data can be directly retrieved from the cache unit, thereby obtaining the evidence data from the storage data.

[0199] In an embodiment of the present application, a relay object is connected to N blockchain networks, and the relay object obtains the current block height of the blockchain corresponding to the target blockchain network; the target blockchain network is any blockchain network among the N blockchain networks; if the current block height is greater than the recorded block height of the target blockchain network in the relay object, then based on the recorded block height and the current block height, an update block is obtained from the blockchain corresponding to the target blockchain network, and the block height of the update block is greater than the recorded block height. By comparing the current block height and the recorded block height, the relay object can store the evidence data in the latest block of the blockchain. Based on the Merkle tree corresponding to the update block, an evidence certificate for the evidence data included in the update block is generated; based on the evidence data and the evidence certificate included in the update block, target storage data for the evidence data is generated, and storage processing is performed on the target storage data. It can be seen that by introducing a relay object and establishing a connection between the relay object and the blockchain network, the blockchain block height can be compared with the record block height recorded in the relay object, thereby realizing the storage of the evidence data on the blockchain in the relay object. In this way, the evidence data can be stored both on the blockchain and in the relay object. To a certain extent, it can effectively avoid the security of the evidence data being affected by the blockchain failure, thereby improving the security of the evidence data. In addition, when storing the evidence data in the relay object, the embodiment of the present application will generate an evidence certificate for the evidence data. The authenticity of the evidence data can be proved by the evidence certificate, which also effectively improves the security and reliability of the evidence data.

[0200] Next, the detailed process of querying the evidence data from the relay object involved in the embodiment of this application is described in detail. Figure 10 , is a flow chart of another data processing method provided in an embodiment of the present application. The data processing method is applied to a relay object, which includes one or more relay nodes. The data processing method provided in an embodiment of the present application can be executed by any relay node in the relay object, and the data processing method may include the following steps S1001-S1004:

[0201] S1001. Receive a data query request initiated by a requester, including the target evidence hash. Specifically, the requester can send the data query request to a relay object through a client or by invoking a smart contract. Any relay node in the relay object can receive the data query request initiated by the requester.

[0202] S1002. In response to a data query request, determine the home relay node where the target evidence hash is located; the home relay node is any relay node among one or more relay nodes.

[0203] S1003. Obtain the evidence data corresponding to the target evidence hash from the home relay node.

[0204] In one implementation, a determination is made as to whether the home relay node is a requesting relay node. If so, the evidentiary data corresponding to the target evidentiary hash is obtained from the home relay node. If not, the mapping relationship between the evidentiary hash and address information is obtained. The requesting relay node is a relay node that receives a data query request initiated by a requesting end. Based on the mapping relationship between the evidentiary hash and address information, the address information corresponding to the target evidentiary hash is determined. The data query request is then forwarded to the home relay node based on the address information corresponding to the target evidentiary hash. The evidentiary data corresponding to the target evidentiary hash, returned by the home relay node based on the data query request, is received.

[0205] Among them, the belonging relay node includes a query unit and a storage unit, the query unit stores the evidence hash, and the storage unit stores the evidence hash and the corresponding storage data; obtaining the evidence data corresponding to the target evidence hash from the belonging relay node, which can specifically include: querying in the query unit of the belonging relay node whether the target evidence hash is stored in the relay object; if it is found to be stored in the relay object, obtaining the storage data corresponding to the target evidence hash from the storage unit of the belonging relay node; obtaining the evidence data corresponding to the target evidence hash from the storage data corresponding to the target evidence hash.

[0206] In some optional implementations, the home relay node includes a cache unit, and obtaining the evidence data corresponding to the target evidence hash from the home relay node may specifically include: querying in the query unit of the home relay node whether the target evidence hash is stored in the relay object; if it is found to be stored in the relay object, obtaining the storage data corresponding to the target evidence hash from the cache unit of the home relay node; and obtaining the evidence data corresponding to the target evidence hash from the storage data corresponding to the target evidence hash.

[0207] S1004. Return the evidence data corresponding to the target evidence hash to the requesting end.

[0208] In some optional implementations, the stored data includes metadata, and the metadata and evidence data in the stored data can be returned to the requesting end.

[0209] In another optional implementation, since a single blockchain does not have complete credibility, the embodiment of the present application stores the evidence data on multiple blockchains. For example, the evidence data corresponding to the resource exchange business can be stored on the blockchain corresponding to the bank, and can also be stored on the blockchain corresponding to the third-party institution. In this case, the confidence parameters of each blockchain can be used for weighting to make a confidence judgment on the evidence data. Specifically, the target evidence data is stored on the blockchains corresponding to M blockchain networks, where one blockchain network corresponds to one blockchain, and M is an integer less than or equal to N; the evidence data corresponding to the target evidence hash is returned to the requesting end, including the following steps ①-④:

[0210] ① Obtain the confidence parameters of each blockchain in M ​​blockchains.

[0211] The confidence parameters include at least one of the following: the number of transactions St of the blockchain in the first historical time period, the transaction success rate Pt of the blockchain in the second historical time period; the number of node devices k corresponding to the blockchain, the number of objects (such as the number of users) U connected to the blockchain network corresponding to the blockchain, the number of objects Ut increased by the blockchain network corresponding to the blockchain in the third historical time period, and the level l of the blockchain. The first historical time period, the second historical time period, and the third historical time period can be the same or different. For example, the first historical time period, the second historical time period, and the third historical time period can be the last three days, the last hour, etc., and this embodiment of the application does not impose any restrictions on this. The level of the blockchain can be set according to demand. For example, the level of the blockchain can be set according to the importance of the data stored on the blockchain. For example, if the data stored on a blockchain is more important, the level of the blockchain can be set to a higher level.

[0212] ② Determine the confidence score of each blockchain based on the confidence parameters of each blockchain.

[0213] In one implementation, the confidence parameters include the number of transactions, transaction success rate, number of node devices, number of objects, number of objects added, and the blockchain's level. Taking a target blockchain among the blockchains corresponding to a network of M blockchains as an example, determining the confidence score of each blockchain based on its confidence parameters may specifically include: determining a coefficient Ql corresponding to the target blockchain's level based on the correspondence between level and coefficient; and determining the target blockchain's confidence score based on a preset coefficient, the number of transactions, transaction success rate, number of node devices, number of objects, number of objects added, and the coefficient corresponding to the target blockchain's level. The target blockchain's confidence score is calculated as follows: Ql*a*St*Pt*Ut+Ql*b*k*U, where a and b are preset coefficients.

[0214] It should be understood that since the confidence parameters of the blockchain are constantly changing and updating, in the embodiments of this application, the confidence scores of each blockchain are dynamically changing. Figure 11 , is a schematic diagram of the confidence scores of each blockchain provided in the embodiment of this application. Figure 11 In the example, the confidence score of the blockchain corresponding to blockchain network 101 is 32; the confidence score of the blockchain corresponding to blockchain network 102 is 32; the confidence score of the blockchain corresponding to blockchain network 101 is 35; and the confidence score of the blockchain corresponding to blockchain network 104 is 25.

[0215] ③ According to the confidence score of each blockchain, determine the confidence level of the evidence data corresponding to the target evidence hash.

[0216] In one implementation, determining the confidence level of the evidence data corresponding to the target evidence hash based on the confidence scores of each blockchain may include: summing the confidence scores of each blockchain to obtain the confidence level of the evidence data corresponding to the target evidence hash. Figure 11 As shown, the evidence data corresponding to the target evidence hash is stored in the blockchain corresponding to blockchain network 101, the blockchain corresponding to blockchain network 102, and the blockchain corresponding to blockchain network 103. At this time, the confidence level of the evidence data corresponding to the target evidence hash is 32+32+35=99.

[0217] In another implementation, the confidence scores of each blockchain can be averaged to obtain the confidence of the evidence data corresponding to the target evidence hash.

[0218] ④ Based on the confidence level, the query result is returned to the requesting end. The query result includes the evidence data corresponding to the target evidence hash. The query result is used to indicate the confidence level of the evidence data corresponding to the target evidence hash.

[0219] In one implementation, returning the query result to the requesting end according to the confidence level may include: returning the query result including the stored evidence data and the confidence level to the requesting end. In another implementation, determining whether the confidence level is greater than a confidence level threshold, and if the confidence level is greater than the confidence level threshold, returning the stored evidence data and the query result indicating that the stored evidence data is credible to the requesting end; illustratively, as Figure 11 In the example, the confidence level of the evidence data corresponding to the target evidence hash is 99, which is greater than the confidence threshold of 90. Therefore, the evidence data corresponding to the target evidence hash is determined to be credible. If the confidence level is less than or equal to the confidence threshold, the evidence data and the query result indicating that the evidence data is untrustworthy are returned to the requesting end.

[0220] For easier understanding, see Figure 12, is a schematic diagram of a process for multi-chain trust judgment of evidence data provided by an embodiment of the present application, the process including the following steps: (1) after the relay node successfully queries the evidence data corresponding to the target evidence hash from the cache or distributed storage, the evidence data corresponding to the target evidence hash is stored in M ​​blockchains; the relay node can obtain the number of transactions St of each blockchain in the M blockchains in the first historical time period; (2) the relay node obtains the transaction success rate Pt of each of the above blockchains in the second historical time period; (3) the relay node obtains the number of node devices k corresponding to each of the above blockchains; (4) the relay node obtains the number of objects U connected to the blockchain network corresponding to each of the above blockchains; (5) The relay node obtains the number of objects Ut that have grown in each of the above blockchains during the third historical time period; (6) The relay node obtains the level l of each of the above blockchains, and obtains the coefficient Ql corresponding to the level of each blockchain based on the level of each blockchain; (7) The relay node calculates the confidence score of each blockchain according to Ql*a*St*Pt*Ut+Ql*b*k*U; (8) The relay node determines the confidence of the evidence data corresponding to the above target evidence hash based on the confidence score of each blockchain; (9) Determine whether the confidence is greater than the confidence threshold. If the confidence is greater than the confidence threshold, execute step (10); if the confidence is less than or equal to the confidence threshold, execute step (11). (10) The relay node returns the evidence data and the result that the evidence data is credible to the requesting end. (11) The relay node returns the evidence data and the result that the evidence data is uncredible to the requesting end.

[0221] To summarize, in the embodiments of the present application, when the evidence data is stored in multiple blockchains, factors such as the number of transactions, transaction success rate, number of nodes, number of objects, etc. of each blockchain can be comprehensively considered to achieve the goal of jointly determining the reliability of the evidence data for multiple blockchains; this can improve the accuracy of the entire relay object's judgment on the credibility of the evidence data and reduce the risk of misjudgment caused by local problems in a single blockchain.

[0222] In an embodiment of the present application, a data query request initiated by a requesting end is received, the data query request including a target evidence hash; in response to the data query request, a home relay node for the target evidence hash is determined; the home relay node is any one of N relay nodes; evidence data corresponding to the target evidence hash is obtained from the home relay node; and the evidence data corresponding to the target evidence hash is returned to the requesting end. In this embodiment of the present application, evidence data can be obtained directly from the relay node, which avoids the additional transaction burden and transaction costs imposed on each blockchain by implementing cross-chain technology to share data between different blockchains.

[0223] Next, the data processing device provided in the embodiments of the present application is described.

[0224] See Figure 13 , Figure 13 is a structural diagram of a data processing device provided in an embodiment of the present application. The data processing device may be a computer program (including program code) in a computer device. For example, the data processing device may be an application software in a computer device. The data processing device may be used to execute Figure 8 or Figure 10 Some or all of the steps in the method embodiment shown. Figure 13 The data processing device is applied to a relay object, and the relay object establishes a connection with N blockchain networks, where N is a positive integer; the data processing device includes the following units:

[0225] An acquiring unit 1301 is configured to acquire a current block height of a blockchain corresponding to a target blockchain network; the target blockchain network is any one of the N blockchain networks;

[0226] Processing unit 1302 is configured to obtain an update block from the blockchain corresponding to the target blockchain network based on the recorded block height and the current block height if the current block height is greater than the recorded block height of the target blockchain network in the relay object, wherein the block height of the update block is greater than the recorded block height;

[0227] The processing unit 1302 is further configured to generate a proof of evidence for the evidence data included in the updated block based on the Merkle tree corresponding to the updated block;

[0228] The processing unit 1302 is further used to generate target storage data of the evidence data based on the evidence data and evidence proof included in the update block, and perform storage processing on the target storage data.

[0229] The processing unit 1302 is specifically configured to:

[0230] Parse the updated block to obtain transaction data, which includes evidence data;

[0231] According to the Merkle tree corresponding to the updated block, the path of the transaction data in the Merkle tree is determined; the Merkle tree is used to store one or more transaction data;

[0232] Generate a proof of existence for the stored data based on the path of the transaction data in the Merkle tree.

[0233] The processing unit 1302 is specifically configured to:

[0234] Verify the stored data included in the updated block based on the stored proof;

[0235] If the verification is successful, the evidence data and evidence certificate included in the updated block are packaged according to the evidence data storage structure to obtain the target storage data of the evidence data;

[0236] The evidence data storage structure includes: a data hash field, a metadata field, and a verification data storage field; the data hash field is used to store the evidence hash of the evidence data;

[0237] The metadata field is used to store metadata of the evidence data; metadata includes: any one or more of the blockchain information where the evidence data is located and the attribute information of the evidence data;

[0238] The verification data storage field is used to store verification data, which is used to verify whether the evidence data exists in the blockchain corresponding to the target blockchain network. The verification data includes any one or more of the transaction information of the evidence proof and the transaction data associated with the evidence data.

[0239] The relay object includes one or more relay nodes, each of which is equipped with a query unit and a storage unit. The processing unit 1302 is specifically configured to:

[0240] determining, from the one or more relay nodes, one or more target relay nodes for storing target storage data;

[0241] Inserting the attestation hash of the attestation data into the query unit of each target relay node; and

[0242] The evidence hash of the evidence data and the target storage data are stored in the storage unit of each target relay node.

[0243] The processing unit 1302 is specifically configured to:

[0244] Obtain data backup parameters for each relay node, which include at least one of the following: business type, smart contract type, and node status;

[0245] determining, from the one or more relay nodes, one or more target relay nodes for storing target storage data according to the data backup parameter;

[0246] Among them, if the data backup parameters include the business type, the relay node that matches the business type of the evidence data will be determined as the target relay node; if the data backup parameters include the type of smart contract, the relay node that matches the smart contract type called when processing the evidence data will be determined as the target relay node; if the data backup parameters include the node status, the relay node will be selected from one or more relay nodes as the target relay node according to the node status of each relay node.

[0247] The processing unit 1302 is further configured to:

[0248] After the relay node successfully stores the target storage data of the evidence data, obtain the address information of the target storage data in the storage unit of the relay node;

[0249] A notification message is sent to each relay node, which carries the address information of the target storage data in the storage unit of the relay node. The notification message is used to trigger all relay nodes in the relay object to store the mapping relationship between the evidence hash and address information of the evidence data.

[0250] The relay object includes one or more relay nodes, and the processing unit 1302 is further configured to:

[0251] Receive a data query request initiated by the requester, which includes the target evidence hash;

[0252] In response to a data query request, determine the home relay node where the target evidence hash is located; the home relay node is any relay node among one or more relay nodes;

[0253] Obtain the evidence data corresponding to the target evidence hash from the home relay node;

[0254] Return the evidence data corresponding to the target evidence hash to the requesting end.

[0255] Each relay node stores a mapping relationship between the full amount of evidence hash and address information. The processing unit 1302 is specifically configured to:

[0256] If the home relay node is not the request relay node, obtain the mapping relationship between the stored hash and the address information; the request relay node refers to the relay node that receives the data query request initiated by the requesting end;

[0257] Based on the mapping relationship between the evidence hash and the address information, determine the address information corresponding to the target evidence hash;

[0258] Forward the data query request to the home relay node based on the address information corresponding to the target evidence hash;

[0259] Receive the evidence data corresponding to the target evidence hash returned by the home relay node based on the data query request.

[0260] The home relay node includes a query unit and a storage unit, wherein the query unit stores the evidence hash, and the storage unit stores the evidence hash and corresponding storage data; the processing unit 1302 is specifically configured to:

[0261] Querying the query unit of the home relay node whether the target evidence hash is stored in the relay object;

[0262] If the query is stored in the relay object, the storage data corresponding to the target evidence hash is obtained from the storage unit of the home relay node;

[0263] Get the evidence data corresponding to the target evidence hash from the storage data corresponding to the target evidence hash.

[0264] The target evidence data is stored on blockchains corresponding to M blockchain networks, where one blockchain network corresponds to one blockchain, and M is an integer less than or equal to N. The processing unit 1302 is specifically configured to:

[0265] Get the confidence parameters of each blockchain in M ​​blockchains;

[0266] Determine the confidence score of each blockchain based on the confidence parameters of each blockchain;

[0267] Determine the confidence level of the evidence data corresponding to the target evidence hash based on the confidence scores of each blockchain;

[0268] Based on the confidence level, the query result is returned to the requesting end. The query result includes the evidence data corresponding to the target evidence hash. The query result is used to indicate the confidence level of the evidence data corresponding to the target evidence hash.

[0269] The processing unit 1302 is further configured to:

[0270] Receive a registration request for a target blockchain network, where the registration request includes node information of each node device in the target blockchain network;

[0271] In response to the registration request, obtain a configuration block from the blockchain corresponding to the target blockchain network, where the configuration block stores configuration information for each node device;

[0272] Verify each node device based on its configuration information and node information;

[0273] If all node devices are verified, the node information of each node device is stored in the relay object, and the blockchain network is connected to the relay object.

[0274] In an embodiment of the present application, a relay object is connected to N blockchain networks, and the relay object obtains the current block height of the blockchain corresponding to the target blockchain network; the target blockchain network is any blockchain network among the N blockchain networks; if the current block height is greater than the recorded block height of the target blockchain network in the relay object, then based on the recorded block height and the current block height, an update block is obtained from the blockchain corresponding to the target blockchain network, and the block height of the update block is greater than the recorded block height. By comparing the current block height and the recorded block height, the relay object can store the evidence data in the latest block of the blockchain. Based on the Merkle tree corresponding to the update block, an evidence certificate for the evidence data included in the update block is generated; based on the evidence data and the evidence certificate included in the update block, target storage data for the evidence data is generated, and storage processing is performed on the target storage data. It can be seen that by introducing a relay object and establishing a connection between the relay object and the blockchain network, the blockchain block height can be compared with the record block height recorded in the relay object, thereby realizing the storage of the evidence data on the blockchain in the relay object. In this way, the evidence data can be stored both on the blockchain and in the relay object. To a certain extent, it can effectively avoid the security of the evidence data being affected by the blockchain failure, thereby improving the security of the evidence data. In addition, when storing the evidence data in the relay object, the embodiment of the present application will generate an evidence certificate for the evidence data. The authenticity of the evidence data can be proved by the evidence certificate, which also effectively improves the security and reliability of the evidence data.

[0275] Next, the computer device provided in the embodiments of the present application is described.

[0276] Furthermore, the present invention also provides a schematic diagram of the structure of a computer device. Figure 14 The computer device may be the relay node described above. The computer device may include a processor 1401, an input device 1402, an output device 1403, and a memory 1404. The processor 1401, input device 1402, output device 1403, and memory 1404 are connected via a bus. The memory 1404 is configured to store a computer program, which includes program instructions. The processor 1401 is configured to execute the program instructions stored in the memory 1404.

[0277] The processor 1401 executes the following operations by running the program instructions in the memory 1404:

[0278] Get the current block height of the blockchain corresponding to the target blockchain network; the target blockchain network is any blockchain network among N blockchain networks;

[0279] If the current block height is greater than the recorded block height of the target blockchain network in the relay object, then based on the recorded block height and the current block height, an update block is obtained from the blockchain corresponding to the target blockchain network. The block height of the update block is greater than the recorded block height.

[0280] Generate a proof of existence for the evidence data included in the updated block based on the Merkle tree corresponding to the updated block;

[0281] Based on the evidence data and evidence proof included in the update block, the target storage data of the evidence data is generated, and the target storage data is stored and processed.

[0282] When the processor 1401 generates the evidence proof of the evidence data included in the updated block based on the Merkle tree corresponding to the updated block, it may specifically perform the following operations:

[0283] Parse the updated block to obtain transaction data, which includes evidence data;

[0284] According to the Merkle tree corresponding to the updated block, the path of the transaction data in the Merkle tree is determined; the Merkle tree is used to store one or more transaction data;

[0285] Generate a proof of existence for the stored data based on the path of the transaction data in the Merkle tree.

[0286] When the processor 1401 generates the target storage data of the evidence data based on the evidence data and the evidence proof included in the update block, it may specifically perform the following operations:

[0287] Verify the stored data included in the updated block based on the stored proof;

[0288] If the verification is successful, the evidence data and evidence certificate included in the updated block are packaged according to the evidence data storage structure to obtain the target storage data of the evidence data;

[0289] The evidence data storage structure includes: a data hash field, a metadata field, and a verification data storage field; the data hash field is used to store the evidence hash of the evidence data;

[0290] The metadata field is used to store metadata of the evidence data; metadata includes: any one or more of the blockchain information where the evidence data is located and the attribute information of the evidence data;

[0291] The verification data storage field is used to store verification data, which is used to verify whether the evidence data exists in the blockchain corresponding to the target blockchain network. The verification data includes any one or more of the transaction information of the evidence proof and the transaction data associated with the evidence data.

[0292] The relay object includes one or more relay nodes, each of which is equipped with a query unit and a storage unit. When the processor 1401 performs storage processing on the target storage data, it may specifically perform the following operations:

[0293] determining, from the one or more relay nodes, one or more target relay nodes for storing target storage data;

[0294] Inserting the attestation hash of the attestation data into the query unit of each target relay node; and

[0295] The evidence hash of the evidence data and the target storage data are stored in the storage unit of each target relay node.

[0296] When the processor 1401 determines one or more target relay nodes for storing target storage data from one or more relay nodes, it may specifically perform the following operations:

[0297] Obtain data backup parameters for each relay node, which include at least one of the following: business type, smart contract type, and node status;

[0298] determining, from the one or more relay nodes, one or more target relay nodes for storing target storage data according to the data backup parameter;

[0299] Among them, if the data backup parameters include the business type, the relay node that matches the business type of the evidence data will be determined as the target relay node; if the data backup parameters include the type of smart contract, the relay node that matches the smart contract type called when processing the evidence data will be determined as the target relay node; if the data backup parameters include the node status, the relay node will be selected from one or more relay nodes as the target relay node according to the node status of each relay node.

[0300] The processor 1401 may further perform the following operations:

[0301] After the relay node successfully stores the target storage data of the evidence data, obtain the address information of the target storage data in the storage unit of the relay node;

[0302] A notification message is sent to each relay node, which carries the address information of the target storage data in the storage unit of the relay node. The notification message is used to trigger all relay nodes in the relay object to store the mapping relationship between the evidence hash and address information of the evidence data.

[0303] The relay object includes one or more relay nodes. The processor 1401 may further perform the following operations:

[0304] Receive a data query request initiated by the requester, which includes the target evidence hash;

[0305] In response to a data query request, determine the home relay node where the target evidence hash is located; the home relay node is any relay node among one or more relay nodes;

[0306] Obtain the evidence data corresponding to the target evidence hash from the home relay node;

[0307] Return the evidence data corresponding to the target evidence hash to the requesting end.

[0308] Each relay node stores a mapping relationship between the full amount of evidence hash and address information. When the processor 1401 obtains the evidence data corresponding to the target evidence hash from the home relay node, it may specifically perform the following operations:

[0309] If the home relay node is not the request relay node, obtain the mapping relationship between the stored hash and the address information; the request relay node refers to the relay node that receives the data query request initiated by the requesting end;

[0310] Based on the mapping relationship between the evidence hash and the address information, determine the address information corresponding to the target evidence hash;

[0311] Forward the data query request to the home relay node based on the address information corresponding to the target evidence hash;

[0312] Receive the evidence data corresponding to the target evidence hash returned by the home relay node based on the data query request.

[0313] The home relay node includes a query unit and a storage unit. The query unit stores the evidential hash, and the storage unit stores the evidential hash and corresponding stored data. When the processor 1401 obtains the evidential data corresponding to the target evidential hash from the home relay node, it may perform the following operations:

[0314] Querying the query unit of the home relay node whether the target evidence hash is stored in the relay object;

[0315] If the query is stored in the relay object, the storage data corresponding to the target evidence hash is obtained from the storage unit of the home relay node;

[0316] Get the evidence data corresponding to the target evidence hash from the storage data corresponding to the target evidence hash.

[0317] The target evidence data is stored on blockchains corresponding to M blockchain networks, where one blockchain network corresponds to one blockchain, and M is an integer less than or equal to N. When the processor 1401 returns the evidence data corresponding to the target evidence hash to the requesting end, it can specifically perform the following operations:

[0318] Get the confidence parameters of each blockchain in M ​​blockchains;

[0319] Determine the confidence score of each blockchain based on the confidence parameters of each blockchain;

[0320] Determine the confidence level of the evidence data corresponding to the target evidence hash based on the confidence scores of each blockchain;

[0321] Based on the confidence level, the query result is returned to the requesting end. The query result includes the evidence data corresponding to the target evidence hash. The query result is used to indicate the confidence level of the evidence data corresponding to the target evidence hash.

[0322] The processor 1401 may further perform the following operations:

[0323] Receive a registration request for a target blockchain network, where the registration request includes node information of each node device in the target blockchain network;

[0324] In response to the registration request, obtain a configuration block from the blockchain corresponding to the target blockchain network, where the configuration block stores configuration information for each node device;

[0325] Verify each node device based on its configuration information and node information;

[0326] If all node devices are verified, the node information of each node device is stored in the relay object, and the blockchain network is connected to the relay object.

[0327] In an embodiment of the present application, a relay object is connected to N blockchain networks, and the relay object obtains the current block height of the blockchain corresponding to the target blockchain network; the target blockchain network is any blockchain network among the N blockchain networks; if the current block height is greater than the recorded block height of the target blockchain network in the relay object, then based on the recorded block height and the current block height, an update block is obtained from the blockchain corresponding to the target blockchain network, and the block height of the update block is greater than the recorded block height. By comparing the current block height and the recorded block height, the relay object can store the evidence data in the latest block of the blockchain. Based on the Merkle tree corresponding to the update block, an evidence certificate for the evidence data included in the update block is generated; based on the evidence data and the evidence certificate included in the update block, target storage data for the evidence data is generated, and storage processing is performed on the target storage data. It can be seen that by introducing a relay object and establishing a connection between the relay object and the blockchain network, the blockchain block height can be compared with the record block height recorded in the relay object, thereby realizing the storage of the evidence data on the blockchain in the relay object. In this way, the evidence data can be stored both on the blockchain and in the relay object. To a certain extent, it can effectively avoid the security of the evidence data being affected by the blockchain failure, thereby improving the security of the evidence data. In addition, when storing the evidence data in the relay object, the embodiment of the present application will generate an evidence certificate for the evidence data. The authenticity of the evidence data can be proved by the evidence certificate, which also effectively improves the security and reliability of the evidence data.

[0328] In the embodiments of the present application, the term "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories), or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more units. In addition, each unit can be part of an overall unit that includes the function of the unit.

[0329] In addition, it should be noted that the present invention also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program, and the computer program includes program instructions. When the processor executes the above program instructions, it can execute the above Figure 8 or Figure 10 The method in the corresponding embodiment will therefore not be described in detail here. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application. As an example, the program instructions can be deployed on a computer device, or executed on multiple computer devices located in one location, or executed on multiple computer devices distributed in multiple locations and interconnected by a communication network.

[0330] According to one aspect of the present application, a computer program product is provided, the computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, so that the computer device can perform the above-mentioned Figure 8 or Figure 10 The method in the corresponding embodiment will therefore not be described in detail here.

[0331] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The program can be stored in a computer-readable storage medium, and when executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0332] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A data processing method, characterized in that: The method is applied to a relay object, the relay object being connected to N blockchain networks, where N is a positive integer, and the method includes: Obtaining the current block height of the blockchain corresponding to the target blockchain network; the target blockchain network is any blockchain network among the N blockchain networks; If the current block height is greater than the recorded block height of the target blockchain network in the relay object, then, based on the recorded block height and the current block height, an update block is obtained from the blockchain corresponding to the target blockchain network, where the block height of the update block is greater than the recorded block height; Generate a proof of evidence for the evidence data included in the update block based on the Merkle tree corresponding to the update block; Based on the evidence data and the evidence proof included in the update block, target storage data of the evidence data is generated, and storage processing is performed on the target storage data.

2. The method according to claim 1, wherein Generating a proof of evidence for the evidence data included in the update block according to the Merkle tree corresponding to the update block includes: Parsing the update block to obtain transaction data, wherein the transaction data includes evidence data; Determining, according to the Merkle tree corresponding to the update block, a path of the transaction data in the Merkle tree; the Merkle tree is used to store one or more transaction data; According to the path of the transaction data in the Merkle tree, a proof of the stored data is generated.

3. The method according to claim 1, wherein Generating target storage data for the evidence data according to the evidence data and the evidence proof included in the update block includes: Verifying the stored data included in the update block based on the stored proof; If the verification is successful, the evidence data and the evidence certificate included in the update block are packaged according to the evidence data storage structure to obtain the target storage data of the evidence data; The evidence data storage structure includes: a data hash field, a metadata field, and a verification data storage field; the data hash field is used to store the evidence hash of the evidence data; The metadata field is used to store metadata of the evidence data; the metadata includes: any one or more of the blockchain information where the evidence data is located and the attribute information of the evidence data; The verification data storage field is used to store verification data, and the verification data is used to verify whether the evidence data exists in the blockchain corresponding to the target blockchain network. The verification data includes any one or more of the transaction information of the evidence certificate and the transaction data associated with the evidence data.

4. The method according to claim 1, wherein The relay object includes one or more relay nodes, each of which is equipped with a query unit and a storage unit. The storage processing of the target storage data includes: determining, from the one or more relay nodes, one or more target relay nodes for storing the target storage data; Inserting the evidence hash of the evidence data into the query unit of each target relay node; and The evidence hash of the evidence data and the target storage data are stored in the storage unit of each target relay node.

5. The method according to claim 4, wherein The determining, from the one or more relay nodes, one or more target relay nodes for storing the target storage data comprises: Obtain data backup parameters for each relay node, where the data backup parameters include at least one of the following: business type, smart contract type, and node status; determining, from the one or more relay nodes, one or more target relay nodes for storing the target storage data according to the data backup parameter; Among them, if the data backup parameters include a business type, the relay node that matches the business type of the evidence data will be determined as the target relay node; if the data backup parameters include a smart contract type, the relay node that matches the smart contract type called when processing the evidence data will be determined as the target relay node; if the data backup parameters include a node status, a relay node will be selected from the one or more relay nodes as the target relay node based on the node status of each relay node.

6. The method according to claim 4, wherein The method further comprises: After the relay node successfully stores the target storage data of the evidence data, obtaining address information of the target storage data in the storage unit of the relay node; A notification message is sent to each relay node, where the notification message carries the address information of the target storage data in the storage unit of the relay node, and the notification message is used to trigger all relay nodes in the relay object to store the mapping relationship between the evidence hash of the evidence data and the address information.

7. The method according to claim 3, wherein The relay object includes one or more relay nodes, and the method further includes: Receive a data query request initiated by a requesting end, wherein the data query request includes a target evidence hash; In response to the data query request, determining a home relay node where the target evidence hash is located; the home relay node is any one of the one or more relay nodes; Obtaining, from the home relay node, the evidence data corresponding to the target evidence hash; Return the evidence data corresponding to the target evidence hash to the requesting end.

8. The method according to claim 7, wherein: Each relay node stores a mapping relationship between a full amount of evidence hash and address information, and obtaining evidence data corresponding to the target evidence hash from the home relay node includes: If the home relay node is not a request relay node, obtaining a mapping relationship between the stored hash and the address information; the request relay node refers to a relay node that receives the data query request initiated by the requesting end; Determine the address information corresponding to the target evidence hash based on the mapping relationship between the evidence hash and the address information; Forwarding the data query request to the home relay node according to the address information corresponding to the target evidence hash; Receive the evidence data corresponding to the target evidence hash returned by the home relay node based on the data query request.

9. The method according to claim 8, wherein The home relay node includes a query unit and a storage unit, wherein the query unit stores a stored hash, and the storage unit stores the stored hash and corresponding stored data; The obtaining, from the home relay node, the evidence data corresponding to the target evidence hash, includes: querying, in a query unit of the home relay node, whether the target evidence hash is stored in the relay object; If the query finds that the target evidence hash is stored in the relay object, then obtaining the storage data corresponding to the target evidence hash from the storage unit of the home relay node; Obtain the evidence data corresponding to the target evidence hash from the stored data corresponding to the target evidence hash.

10. The method according to claim 7, wherein: The target evidence data is stored on blockchains corresponding to M blockchain networks, where one blockchain network corresponds to one blockchain, and M is an integer less than or equal to N; returning the evidence data corresponding to the target evidence hash to the requesting end includes: Get the confidence parameters of each blockchain in M ​​blockchains; Determining a confidence score for each blockchain based on the confidence parameters of each blockchain; Determining the confidence level of the evidence data corresponding to the target evidence hash based on the confidence scores of the blockchains; Based on the confidence level, a query result is returned to the requesting end, where the query result includes the evidence data corresponding to the target evidence hash, and the query result is used to indicate the confidence level of the evidence data corresponding to the target evidence hash.

11. The method according to claim 1, wherein The method further comprises: Receive a registration request for a target blockchain network, the registration request including node information of each node device in the target blockchain network; In response to the registration request, obtaining a configuration block from the blockchain corresponding to the target blockchain network, wherein the configuration block stores configuration information of each node device; Performing verification processing on each node device based on the configuration information and node information of each node device; If the verification of each node device is successful, the node information of each node device is stored in the relay object, and it is determined that the blockchain network is connected to the relay object.

12. A data processing device, characterized in that: The device is applied to a relay object, wherein the relay object is connected to N blockchain networks, where N is a positive integer, and comprises: an acquisition unit, configured to acquire a current block height of a blockchain corresponding to a target blockchain network; the target blockchain network being any one of the N blockchain networks; a processing unit, configured to, if the current block height is greater than the recorded block height of the target blockchain network in the relay object, obtain an update block from the blockchain corresponding to the target blockchain network according to the recorded block height and the current block height, wherein the block height of the update block is greater than the recorded block height; The processing unit is further configured to generate, based on the Merkle tree corresponding to the update block, a proof of evidence for the evidence data included in the update block; The processing unit is further configured to generate target storage data of the evidence data based on the evidence data and the evidence proof included in the update block, and perform storage processing on the target storage data.

13. A computer device, characterized in that: include: a processor suitable for executing a computer program; A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by the processor, the data processing method according to any one of claims 1 to 11 is executed.

14. A computer-readable storage medium, characterized in that The computer storage medium stores a computer program, and when the computer program is executed by a processor, the data processing method according to any one of claims 1 to 11 is executed.

15. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the data processing method according to any one of claims 1 to 11 is implemented.

Images