CN111935318A

CN111935318A - Cross-link data verification method, device, equipment and medium

Info

Publication number: CN111935318A
Application number: CN202011037312.1A
Authority: CN
Inventors: 刘晓赫
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2020-09-28
Filing date: 2020-09-28
Publication date: 2020-11-13
Anticipated expiration: 2040-09-28
Also published as: CN111935318B

Abstract

The application discloses a cross-chain data verification method, a cross-chain data verification device, cross-chain data verification equipment and a cross-chain data verification medium, relates to the technical field of block chains, and is applicable to cloud computing and cloud services. The specific implementation scheme is as follows: based on the verification requirement of the target chain, sending a query request to the source chain; receiving data to be verified fed back by a feedback node in the source chain based on the query request; the data to be verified comprises a query request identifier and query data; and verifying the query data according to the query request identifier. The embodiment of the application improves the convenience and universality of cross-chain data verification.

Description

Cross-link data verification method, device, equipment and medium

Technical Field

The application relates to the technical field of computers, in particular to a block chain technology which can be used for cloud computing and cloud service, and specifically relates to a cross-chain data verification method, device, equipment and medium.

Background

With the continuous development of the block chain technology, a plurality of block chain forms such as public chains, alliance chains and private chains appear, each block chain is an independent consensus network, a data isolated island is formed, and the further development of block chain application ecology is hindered.

The cross-chain technology is a technology for solving interoperability between at least two blockchains, and can realize sharing of data on the chains in different blockchains, so a trusted mechanism is needed for verifying the cross-chain data.

The conventional merkel verification mechanism needs to store and calculate the block head of the block to be verified, needs to invest a large amount of storage resources and calculation resources, and has poor universality and incapability of adapting to various verification scenes.

Disclosure of Invention

The application provides a cross-chain data verification method, device, equipment and medium which are convenient to operate and good in universality.

According to an aspect of the present application, there is provided a cross-chain data verification method applied to a verification carrier, including:

based on the verification requirement of the target chain, sending a query request to the source chain;

receiving data to be verified fed back by a feedback node in the source chain based on the query request; the data to be verified comprises a query request identifier and query data;

and verifying the query data according to the query request identifier.

According to another aspect of the present application, there is also provided a cross-chain data verification method applied to a block link point in a source chain, including:

acquiring a query request initiated based on a verification requirement of a target chain;

and sending data to be verified comprising a query request identifier and query data to a verification carrier according to the query request so that the verification carrier verifies the query data according to the query request identifier.

According to another aspect of the present application, there is also provided a cross-chain data verification apparatus configured to a verification carrier, including:

the query request sending module is used for sending a query request to the source chain based on the verification requirement of the target chain;

a to-be-verified data receiving module, configured to receive to-be-verified data fed back by a feedback node in the source chain based on the query request; the data to be verified comprises a query request identifier and query data;

and the verification module is used for verifying the query data according to the query request identifier.

According to another aspect of the present application, there is also provided a cross-chain data verification apparatus configured at a block link point in a source chain, including:

the query request acquisition module is used for acquiring a query request initiated based on the verification requirement of the target chain;

and the to-be-verified data sending module is used for sending to-be-verified data comprising the query request identifier and the query data to a verification carrier according to the query request so that the verification carrier verifies the query data according to the query request identifier.

According to another aspect of the present application, there is also provided an electronic device, including:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute any one of the cross-chain data verification methods provided by the embodiments of the present application.

According to another aspect of the present application, there is also provided a non-transitory computer readable storage medium storing computer instructions for causing a computer to perform any one of the cross-chain data verification methods provided by the embodiments of the present application.

According to the technical scheme, the convenience and the universality of cross-chain data verification are improved.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The drawings are included to provide a better understanding of the present solution and are not intended to limit the present application. Wherein:

fig. 1A is a block diagram of a verification system according to an embodiment of the present application;

FIG. 1B is a flowchart of a cross-chain data verification method provided in an embodiment of the present application;

FIG. 2 is a flowchart of another cross-chain data verification method provided in an embodiment of the present application;

FIG. 3 is a flowchart of another cross-chain data verification method provided in an embodiment of the present application;

FIG. 4 is a flowchart of another cross-chain data verification method provided in an embodiment of the present application;

fig. 5 is a structural diagram of a cross-chain data verification apparatus according to an embodiment of the present application;

FIG. 6 is a block diagram of another cross-chain data verification apparatus provided in an embodiment of the present application;

FIG. 7 is a block diagram of an electronic device for implementing a cross-chain data verification method according to an embodiment of the present application.

Detailed Description

The following description of the exemplary embodiments of the present application, taken in conjunction with the accompanying drawings, includes various details of the embodiments of the application for the understanding of the same, which are to be considered exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Each of the cross-chain data verification methods and the cross-chain data verification apparatuses provided in the embodiments of the present application may be applied to a case where cross-chain data acquired by a target chain from a source chain is verified by a verification carrier, where the cross-chain data verification method may be executed by the cross-chain data verification apparatus, the apparatus is implemented by software and/or hardware, and is specifically configured in an electronic device serving as the verification carrier, and the electronic device may be a device carrying a block chain node.

In order to clearly introduce the technical solution of the embodiment of the present application, first, the verification system related to the present application will be described.

Referring to the verification system shown in fig. 1A, it comprises a source chain 10, a target chain 20 and a verification carrier 30. The target chain 20 performs cross-chain data acquisition from the source chain 10, and verifies the cross-chain data. When cross-chain data is verified, this is done by means of the verification carrier 20.

Illustratively, the source chain 10 and the target chain 20 may be homogeneous blockchains or heterogeneous blockchains, so that the verification carrier 20 can adapt to a verification scenario for cross-chain data of the homogeneous blockchains or the heterogeneous blockchains, which improves heterogeneous universality of cross-chain data verification.

Illustratively, the verification carrier includes, but is not limited to, a relay node, a blockchain node in the target chain, a blockchain node in the relay chain, and a trusted node of the target chain. The Trusted node may be a node device provided with a TEE (Trusted Execution Environment). It can be understood that, by enriching the variety of the verification carriers, the embodiment of the present application improves the system universality of the cross-chain data verification to which the embodiment of the present application relates.

Optionally, the cross-chain data may include blockchain essential data. The basic information of the block chain includes, but is not limited to, the mining difficulty, height, information and transaction processing log of a block in the source chain. Alternatively, the cross-chain data may include contract data. The contract data includes, but is not limited to, contract invocation logs, contract trigger events, and the like. It can be understood that by enriching the diversity of the cross-chain data, the cross-chain data verification operation of the embodiment of the application is not limited to the verification of specific data, and can adapt to the scenes of cross-chain access or sharing of different types of data, thereby improving the data universality of the cross-chain data verification.

Fig. 1B is a cross-chain data verification method provided in the embodiment of the present application, including:

s101, sending a query request to a source chain based on the verification requirement of the target chain.

Wherein, the source chain can be understood as a source block chain of cross-chain data; a target chain may be understood as a blockchain with cross-chain data usage requirements.

Optionally, the verification requirement may be generated after the target chain acquires the cross-chain data in the source chain, so as to verify the validity and the true existence of the acquired cross-chain data. Or optionally, the verification requirement may also be that the target chain is generated in the process of acquiring the cross-chain data in the source chain, and when the cross-chain data is acquired, the legitimacy and the true existence of the acquired cross-chain data are verified.

Illustratively, the query request may be a system level query request that queries for blockchain base data in the source chain. The basic data of the block chain includes, but is not limited to, the mining difficulty, height, information and transaction processing log of a block in the source chain.

Illustratively, the query request may also be a contract query request that queries for contract data in the source chain. The contract data includes, but is not limited to, contract invocation logs, contract trigger events, and the like.

In one embodiment, when the target chain has the verification requirement, a source query request is generated based on the verification requirement, and the source query request is sent to the verification carrier; the authentication carrier generates a query request based on the source query request that is sent to the source chain.

Wherein the source query request may be the same as or different from the query request sent to the source chain. In an alternative embodiment, if the source chain and the target chain belong to homogeneous blockchains, the source query request is the same as the query request sent to the source chain. In another alternative embodiment, if the source chain and the target chain belong to heterogeneous blockchains, the source query request may be understood as a request associated with a verification requirement generated based on a request rule of the target chain; the query request sent to the source chain may be understood as a request associated with the validation requirement generated based on the request rules of the source chain. When the source chain and the target chain belong to the heterogeneous block chain, the source query request needs to be encoded according to a request rule of the source chain, so that the source query request is converted into a query request adapted to the source chain.

In another embodiment, when the target chain has the verification requirement, a query request adapted to the source chain is generated based on the verification requirement, and the generated query request is sent to each blockchain node in the source chain via the verification carrier.

It will be appreciated that in order for the verification process to be more targeted, the source chain identification and query identification of cross-chain data need to be included in the verification requirements. The source chain identifier is used for uniquely characterizing the block chain, and source chain positioning can be performed based on the source chain identifier. The query identifier of the cross-chain data is used for uniquely representing the data in the source chain, so that the cross-chain data to be queried can be conveniently searched and obtained from the source chain.

Specifically, the verification carrier sends a query request to at least one block link node in the source chain based on the verification requirement of the target chain. Optionally, the transmitted block link point may be a trusted node in the source chain identified by the target chain; or optionally, the block link point may be any node in the randomly selected source chain; or alternatively, the block link points may also be all nodes in the source chain.

S102, receiving data to be verified fed back by a feedback node in a source chain based on the query request; the data to be verified comprises query request identification and query data.

The feedback node in the source chain may be understood as a node that feeds back data to be verified to the verification carrier in response to the query request.

Illustratively, a feedback node in a source chain receives a query request sent by a verification carrier; inquiring and acquiring inquiry data (namely cross-link data) according to the inquiry request, and generating to-be-verified data comprising an inquiry request identifier and the inquiry data; and the feedback node feeds back the data to be verified to the verification carrier so that the verification carrier verifies the query data based on the query request identifier.

Wherein the query request identification is used for uniquely distinguishing the query request. Illustratively, the query request identification may include, but is not limited to, information such as a feedback numeric abstract of the query request, a feedback request text of the query request, and a feedback timestamp of the query request.

Illustratively, the feedback digital abstract of the query request is obtained by performing hash calculation on the query request and is used for uniquely representing the content of the query request; the feedback request text of the query request is the query request and is used for uniquely representing the content of the query request; and the feedback time stamp of the query request is used for representing the feedback time of the data to be verified.

Optionally, after the feedback node performs hash calculation on the query request, a feedback digital abstract is obtained, and the feedback digital abstract is added to the data to be verified and fed back to the verification carrier for assisting in verifying the query data; or optionally, the feedback node takes the received query request text as a feedback request text, adds the feedback request text to the data to be verified, and feeds the feedback request text back to the verification carrier to assist in verifying the query data; or optionally, the feedback node takes a timestamp of the generated data to be verified as a feedback timestamp, and adds the feedback timestamp to the data to be verified and feeds the feedback timestamp back to the verification carrier, so as to assist in verifying the query data.

It can be understood that the query request identification is refined into identification information with different dimensions, so that a foundation is laid for multi-dimensional verification of query data.

And S102, verifying the query data according to the query request identifier.

And verifying the query data according to the corresponding relation between the query request identification in the data to be verified and the query request locally stored by the verification carrier. Specifically, if the query request identifier has a corresponding relationship with a query request locally stored in the verification carrier, the query data passes verification; and if the query request identification does not have the corresponding relation with the query request locally stored by the verification carrier, the query data verification is not passed.

In the cross-chain data query process, the query request identifier and the query data are carried in the data to be verified, and the query data is verified through the query request identifier, so that the block header data of a source chain where the query data is located does not need to be stored in a verification carrier, and the data storage amount of the verification carrier in the cross-chain data verification is reduced. Meanwhile, the query data is verified through the query request identifier instead of a Mercker verification mechanism, the data operand is small, and the convenience of cross-link data verification is improved. In addition, the method does not need to rely on the construction of the Mercker tree in the cross-chain data verification process, so that the organizational structure of the source chain is not particularly limited, and the universality of cross-chain data verification is improved.

In order to further improve the accuracy of the verification result and further ensure the cross-chain security, in an optional embodiment, the query data may be verified again by using other data besides the query request identifier.

Optionally, the query data may be verified according to existence of the node address of the feedback node in the source chain.

For example, the node address of the blockchain node of the source chain may be stored in advance in other storage devices or cloud terminals local to the verification carrier or associated with the verification carrier; correspondingly, the verification carrier searches and acquires the node address of the block chain node of the source chain from a local storage device, other storage devices associated with the verification carrier or a cloud end; if the verification carrier can find the node address of the feedback node, the feedback node is shown to exist in the source chain really, and the query data is verified to pass; if the node address of the feedback node cannot be found, the feedback node does not exist in the source chain, and the query data is not verified at the moment.

It can be understood that by introducing the node address of the feedback node, the true existence of the feedback node in the source chain can be verified, and the hidden danger brought to the accuracy of data query and the safety of the use process due to the false feedback node is reduced.

Optionally, the signature of the signature information of the feedback node may be checked, and the query data may be verified according to the result of the check.

For example, the account public key of the blockchain node of the source chain may be stored in advance in other storage devices or cloud terminals local to or associated with the verification carrier; correspondingly, the verification carrier searches and acquires the account public key of the block chain node of the source chain from a local storage device, other storage devices associated with the verification carrier or a cloud end; the verification carrier verifies the signature information of the data to be verified by the feedback node according to the searched account public key; if the verification is successful, the feedback node is shown to exist really in the source chain, namely the authenticity of the fed-back data to be verified is ensured, and the query data is verified at the moment; if the verification fails, it is indicated that the feedback node does not exist in the source chain, that is, the fed-back data to be verified may have a false condition, and at this time, the query data is not verified.

It can be understood that the true existence of the feedback node in the source chain and the authenticity of the fed-back data to be verified can be verified by verifying the signature information of the feedback node, so that the feedback node is prevented from being false, and hidden troubles brought to the accuracy of data query and the safety of the use process are reduced.

Optionally, it may also be determined whether the number of feedback nodes meets a consensus algorithm of the source chain, and the query data is verified according to the determination result.

Illustratively, the verification carrier may determine the threshold number of consensus nodes according to a consensus algorithm followed by the source chain; if the number of feedback nodes for feeding back the data to be verified, namely the number of received node signatures is smaller than the consensus node number threshold, it is indicated that the query result does not meet the consensus algorithm of the source chain, and the query data is not verified at this time; if the number of feedback nodes for feeding back the data to be verified, that is, the number of received node signatures is not less than the consensus node number threshold, it is indicated that the query result satisfies the consensus algorithm of the source chain, and the query data is verified at this time.

In an alternative embodiment, the consensus algorithm may include a BFT (Byzantine Fault Tolerance) class consensus algorithm, such as PBFT (Practical Byzantine Fault Tolerance), hotspot BFT (hotspot Byzantine Fault Tolerance), etc., where the determined threshold of the number of consensus nodes may be (n-1) × 2/3, where n is the total number of blockchain nodes in the source chain.

In another alternative embodiment, the consensus algorithm may include a CFT (Fault Tolerance) type consensus algorithm, such as a Raft distributed consistency algorithm, and since such a type of consensus short burst can only tolerate a Fault node, all node mean values are used in a trusted environment, so that only one consensus node signature is needed, that is, the threshold of the number of formula nodes is 1.

It can be understood that the correctness of the query data can be ensured and the safety of the use process of the query data is improved by introducing the number of the feedback nodes and carrying out consensus algorithm verification.

On the basis of the above technical solutions, the embodiments of the present application further provide an optional embodiment, which is used to refine the query request identifier into identifier information of different dimensions, so as to implement multidimensional verification on query data.

Referring to fig. 2, a cross-chain data verification method includes:

s201, based on the verification requirement of the target chain, sending a query request to the source chain.

S202, receiving data to be verified fed back by a feedback node in a source chain based on the query request; the data to be verified comprises a query request identifier and query data; the query request identification includes at least one of a feedback numeric summary of the query request, a feedback request text of the query request, and a feedback timestamp of the query request.

And S203, verifying the query data according to the query request identifier.

In an alternative embodiment, the query request identification may include feedback request text of the query request; correspondingly, the verification of the query data according to the query request identifier may be: determining the consistency of the query request text and the feedback request text; and verifying the query data according to the consistency result.

Exemplarily, the verification carrier compares a query request text of a query request sent by the verification carrier with a feedback request text in the data to be verified; if the text content is consistent, the data to be verified corresponds to the query request sent by the verification carrier, and at the moment, the query data in the data to be verified corresponds to the query request, and the query data is verified to be passed; if the text content is inconsistent, it indicates that the data to be verified does not correspond to the query request sent by the verification carrier, and correspondingly, the query data in the data to be verified does not necessarily correspond to the query request, and the verification of the query data is not passed.

In order to simplify the data computation amount of text content consistency comparison, hash calculation can be carried out on the query request text and the feedback request text in the data to be verified respectively to obtain a standard digital abstract and a feedback digital abstract; and determining the consistency of the text content of the query request text and the feedback request text in the data to be verified according to the consistency of the standard digital abstract and the feedback digital abstract.

It can be understood that, by introducing the digital abstract of the query request, the corresponding relationship between the query request and the fed back data to be verified can be verified, thereby providing a guarantee for the accuracy of the query data.

In another alternative embodiment, the query request identifies a feedback digital summary that includes the query request; correspondingly, the verification of the query data according to the query request identifier may be: determining a digital abstract of the query request as a standard digital abstract; and verifying the query data according to the standard digital abstract and the feedback digital abstract.

Exemplarily, the verification carrier performs hash calculation on a query request sent by the verification carrier to obtain a standard digital digest; comparing the standard digital abstract with a feedback digital abstract in the data to be verified; if the standard digital abstract is consistent with the feedback digital abstract in the data to be verified, the feedback data to be verified is corresponding to the query request, and the query data in the data to be verified is considered to be also corresponding to the query request at the moment, so that the query data is verified; if the standard digital abstract is inconsistent with the feedback digital abstract in the data to be verified, the feedback data to be verified is not corresponding to the query request, the query data in the corresponding data to be verified is also not necessarily corresponding to the query request, and the query data is not verified at this time.

It can be understood that, by introducing the digital abstract of the query request, the corresponding relationship between the query request and the fed back data to be verified can be verified, thereby providing a guarantee for the accuracy of the query data. Meanwhile, a digital abstract comparison mode is adopted to replace text comparison, and the data operation amount of corresponding relation verification is reduced.

In yet another alternative embodiment, the query request identification may include feedback request text of the query request; correspondingly, the verification of the query data according to the query request identifier may be: verifying the query data according to the source query request and the feedback request text related to the query request; the source query request is generated by a block chain link point in the target chain based on the validation requirements.

Because the source query request is generated by the block chain link points in the target chain based on the verification requirement, the source query request is considered to be capable of adapting to the request rule of the target chain; since the query request sent to the source chain is generated by the authentication carrier based on the authentication requirement and sent to the blockchain node of the source chain, that is, transmitted in the source chain, the query request sent to the source chain can adapt to the request rule of the source chain. When the source chain and the target chain belong to heterogeneous block chains, a certain difference exists between the content coding formats of the query request sent to the source chain and the content coding formats of the source query request. In order to avoid that the query request generated by the verification carrier and sent to the source chain does not correspond to the source query request generated by the target chain, the corresponding relationship between the source query request and the feedback request text in the data to be verified needs to be verified, so that the transaction request, the feedback request text and the source query request sent to the source chain have unique corresponding relationship, and the accuracy of querying the data is further ensured.

Optionally, the query data is verified according to the source query request and the feedback request text associated with the query request, and the verification may be: coding the feedback request text according to the request rule of the target chain to obtain a request text to be verified; and if the text of the request to be verified is the same as the source query request, verifying the query data to be passed.

Specifically, the feedback request text is coded according to the request rule of the target chain to obtain a to-be-verified request text adapted to the target chain; if the feedback request text is consistent with the query request sent to the source chain, the encoded request text to be verified is necessarily consistent with the source query request, and at this time, the query request sent to the source chain, the feedback request text and the source query request have a unique corresponding relationship, so that the query data is determined to be data corresponding to the verification requirement of the target chain.

If the feedback request text is inconsistent with the query request sent to the source chain, the text of the request to be verified obtained after encoding is different from the source query request necessarily, and at this time, an error occurs in the corresponding relationship among the query request sent to the source chain, the feedback request text and the source query request, so that the query data is determined not to be data corresponding to the verification requirement of the target chain. In summary, the query data may be considered to be not verified in the case that the text of the request to be verified is different from the source query request.

Or optionally, the query data is verified according to the source query request and the feedback request text associated with the query request, which may be: coding the source query request according to the request rule of the source chain to obtain a request text to be verified; and if the request text to be verified is the same as the feedback request text, verifying the query data.

Specifically, the source query request is encoded according to a request rule of a source chain to obtain a to-be-verified request text adapted to the source chain; if the feedback request text is consistent with the query request sent to the source chain, the encoded text of the request to be verified is necessarily consistent with the feedback request text, and at this time, the query request sent to the source chain, the feedback request text and the source query request have a unique corresponding relationship, so that the query data is determined to be data corresponding to the verification requirement of the target chain.

If the feedback request text is inconsistent with the query request sent to the source chain, the coded request text to be verified is inevitably different from the feedback request text, and at this time, an error occurs in the corresponding relationship among the query request sent to the source chain, the feedback request text and the source query request, so that the query data is determined not to be the data corresponding to the verification requirement of the target chain. In summary, the query data may be considered to be not verified under the condition that the request text to be verified is different from the feedback request text.

In another alternative embodiment, the query request may include a feedback timestamp of the query request; correspondingly, the verifying the query data according to the query request identifier comprises the following steps: and if the time difference between the feedback timestamp and the generation timestamp of the query request is greater than the set time threshold, the query data is not verified.

Exemplarily, if the time difference between the feedback timestamp and the generation timestamp of the query request is greater than the set time threshold, it indicates that the response of the query request is invalid, and at this time, the query data is considered to be not verified; if the time difference between the feedback timestamp and the generation timestamp of the query request is not greater than the set time threshold, it is indicated that the response of the query request is valid, and at this time, the query data is considered to be valid under the limitation condition of generating the timestamp, that is, the query data passes verification.

It can be understood that the timeliness of the query data is limited by the feedback timestamp and the generation timestamp, so that the timeliness of the query data can be ensured, and the influence of data failure on the target chain of the query data with high updating efficiency is avoided.

According to the embodiment of the application, the query request identification is refined into the identification information with different dimensions, so that the verification of the query data under different dimensions is realized, the accuracy, the timeliness and the like of the query data are ensured, and the security of a target chain to the use process of the query data is guaranteed.

In an optional embodiment of the present application, a cross-chain data verification method is further provided, where the cross-chain data verification method is applied to a blockchain node of a source chain to cooperate with a verification carrier to verify data in the source chain based on a verification requirement of a target chain on cross-chain data of the source chain.

Referring to fig. 3, a cross-chain data verification method includes:

s301, acquiring a query request initiated based on the verification requirement of the target chain.

Specifically, a query request initiated by the verification carrier based on the verification requirement of the target chain is obtained.

Optionally, the verification requirement may be generated after the target chain acquires the cross-chain data in the source chain, so as to verify the validity and the true existence of the acquired cross-chain data. Or optionally, the verification requirement may also be that the target chain is generated in the process of acquiring the cross-chain data in the source chain, and the legitimacy and the true existence of the acquired cross-chain data are verified when the cross-chain data are acquired.

In one embodiment, when the target chain has the verification requirement, a source query request is generated based on the verification requirement, and the source query request is sent to the verification carrier; the authentication carrier generates a query request based on the source query request that is sent to the source chain. Accordingly, the block link point in the source chain acquires and responds to the query request.

In another embodiment, when the target chain has the verification requirement, a query request adapted to the source chain is generated based on the verification requirement, and the generated query request is sent to each blockchain node in the source chain via the verification carrier. Accordingly, the block link point in the source chain acquires and responds to the query request.

S302, sending data to be verified including the query request identifier and the query data to the verification carrier according to the query request, so that the verification carrier verifies the query data according to the query request identifier.

Illustratively, the block chain link points in the source chain perform query acquisition of query data (i.e. cross-chain data) according to the query request, and generate to-be-verified data including query request identification and query data; and feeding back the data to be verified to the verification carrier so that the verification carrier verifies the query data based on the query request identifier. The verification process of the verification carrier for the query data can be referred to the foregoing embodiments, and is not described herein again.

Optionally, after performing hash calculation on the query request by the block link node in the source chain, obtaining a feedback digital abstract, and adding the feedback digital abstract into the data to be verified and feeding the feedback digital abstract back to the verification carrier for assisting in verifying the query data; or optionally, the block link node in the source chain takes the received query request text as a feedback request text, adds the feedback request text to the data to be verified, and feeds the data to be verified back to the verification carrier for assisting in verifying the query data; or optionally, the block link point in the source chain takes a time stamp for generating the data to be verified as a feedback time stamp, and adds the feedback time stamp to the data to be verified and feeds the data to be verified back to the verification carrier for assisting in verifying the query data.

Illustratively, the query data includes, but is not limited to, blockchain base data and contract data in the source chain. It can be understood that by enriching the diversity of the cross-chain data, the cross-chain data verification operation of the embodiment of the application is not limited to the verification of specific data, and can adapt to the scenes of cross-chain access or sharing of different types of data, thereby improving the data universality of the cross-chain data verification.

It should be noted that the source chain and the target chain may belong to a homogeneous block chain or a heterogeneous block chain, so that the verification carrier can adapt to a scene of verifying cross-chain data of the homogeneous block chain or the heterogeneous block chain, and the heterogeneous universality of cross-chain data verification is improved.

According to the method and the device, when the block chain link point in the source chain responds to the query request initiated by the target chain-based verification requirement, the to-be-verified data comprising the query request identifier and the query data are sent to the verification carrier, and a foundation is laid for the verification carrier to verify the query data based on the query request identifier. By the technical scheme, the block header data of the source chain where the query data are located does not need to be stored in the verification carrier, and the data storage amount of the verification carrier in cross-chain data verification is reduced. Meanwhile, the query data is verified through the query request identifier instead of a Mercker verification mechanism, the data operand is small, and the convenience of cross-link data verification is improved. In addition, the method does not need to rely on the construction of the Mercker tree in the cross-chain data verification process, so that the organizational structure of the source chain is not particularly limited, and the universality of cross-chain data verification is improved.

On the basis of the above technical solutions, an embodiment of the present application further provides a preferred implementation manner, and referring to fig. 4, the method for cross-chain data verification includes:

s401, the target link node generates a source query request according to a target link coding rule based on self verification requirements.

S402, the target link node sends the source query request to the verification carrier.

And S403, the verification carrier converts the source query request into a target query request according to the encoding rule of the source chain, and marks and generates a timestamp.

S404, the verification carrier sends a target query request to the source chain node.

S405, the source link node acquires query data according to the target query request and generates a digital abstract of the target query request as a feedback digital abstract.

S406, the source link node signs the target query request, the feedback digital abstract, the feedback timestamp and the query data through the public key thereof to generate the data to be verified.

And S407, the source link node sends the data to be verified to the verification carrier.

S408, verifying the node address of the carrier local search source chain node to verify the node address validity.

Specifically, if the verification carrier can find the node address of the source link node locally, the node address validity verification is passed; if the verification carrier cannot find the node address of the source link node locally, the node address validity verification is not passed.

And S409, the verification carrier verifies the signature of the data to be verified according to the locally stored public key of the source chain node so as to verify the validity of the signature.

Specifically, if the verification carrier succeeds in verifying the signature of the data to be verified according to the locally stored public key of the source chain node, the validity verification of the signature passes; and if the verification carrier fails to verify the signature of the data to be verified according to the locally stored public key of the source chain node, the signature validity verification fails.

S410, the verification carrier determines a threshold value of the number of the consensus nodes according to the consensus algorithm of the source chain.

S411, the verification carrier verifies the legitimacy of the consensus algorithm according to whether the signature number of the source link node feeding back the data to be verified meets the threshold of the number of consensus nodes.

Specifically, if the signature number of the source link node feeding back the data to be verified is smaller than the threshold value of the number of the consensus nodes, the validity verification of the consensus algorithm fails; if the signature number of the source chain node feeding back the data to be verified is not less than the threshold value of the number of the consensus nodes, the validity verification of the consensus algorithm is passed

And S412, the verification carrier determines the consistency of the standard digital abstract and the feedback digital abstract of the target query request so as to verify the request content.

Specifically, if the standard digital abstract and the feedback digital abstract are the same, the requested content passes verification; and if the standard digital abstract and the feedback digital abstract are different, the requested content verification is not passed.

And S413, the verification carrier converts the target query request in the data to be verified into the query request to be verified according to the coding rule of the target chain.

S414, the verification carrier determines the consistency of the query request to be verified and the source query request so as to verify the request type.

Specifically, if the query request to be verified is the same as the source query request, the request type verification is passed; and if the query request to be verified is different from the source query request, the request type verification is not passed.

And S415, verifying the query timeliness of the carrier according to the time interval between the feedback time stamp and the generation time stamp.

If the time interval between the feedback timestamp and the generation timestamp is smaller than the set interval threshold, the timeliness verification is passed; and if the time interval between the feedback timestamp and the generation timestamp is not less than the set interval threshold, the timeliness verification is not passed. Wherein the set interval threshold is determined by a technician as needed or empirically.

It should be noted that, in the embodiment of the present application, no limitation is imposed on the sequence of the verification operations, and the verification operations may be executed sequentially or concurrently.

S416, if the verification is passed, inquiring data to verify to pass; otherwise, the query data validation fails.

It should be noted that the node address validity, the signature validity, the request content verification, the request type verification and the query timeliness verification of each source link node feeding back the data to be verified all pass, and if the consensus algorithm validity verification of the target query request passes, it indicates that the query data verification passes; otherwise, the query data fails to verify.

S417, the verification carrier feeds back the query data and the verification result to the target link node.

The verification result may include a final verification result, and may further include at least one of different types of verification results, such as node address validity, signature validity, request content verification, request type verification, query timeliness verification, consensus algorithm validity, and the like.

According to the method and the device, the verification of the cross-link data can be realized only by verifying the basic information of the configuration source chain in the carrier and without synchronizing the block header in the source chain. Meanwhile, the embodiment of the application adopts a new verification mechanism completely different from the Mercker verification mechanism, and does not need to make requirements on the organizational structure of block chain data in the source chain, namely does not need to limit that the source chain must adopt a Mercker tree, so that cross-chain verification has heterogeneous universality. In addition, the embodiment of the application can verify the block chain basic data and the contract data in the source chain, so that the verification operation has data universality.

As an implementation of each of the above cross-chain data verification methods, the present application further provides an embodiment of a cross-chain data verification apparatus. Referring to fig. 5, a cross-chain data verification apparatus 500 configured in a verification carrier includes: a query request sending module 501, a to-be-verified data receiving module 502 and a verifying module 503. Wherein the content of the first and second substances,

a query request sending module 501, configured to send a query request to a source chain based on a verification requirement of a target chain;

a to-be-verified data receiving module 502, configured to receive to-be-verified data fed back by a feedback node in the source chain based on the query request; the data to be verified comprises a query request identifier and query data;

and the verification module 503 is configured to verify the query data according to the query request identifier.

Further, the query request identification includes at least one of a feedback numeric summary of the query request, a feedback request text of the query request, and a feedback timestamp of the query request.

Further, if the query request identifier includes a feedback digital summary of the query request, the verification module 503 includes:

the standard digital abstract determining unit is used for determining a digital abstract of the query request as a standard digital abstract;

and the digital abstract verification unit is used for verifying the query data according to the standard digital abstract and the feedback digital abstract.

Further, if the query request identifier includes a feedback request text of the query request, the verification module 503 includes:

the request text verification unit is used for verifying the query data according to the source query request and the feedback request text related to the query request; the source query request is generated by a block chain link point in the target chain based on the validation requirements.

Further, the request text authentication unit includes:

the first coding subunit is used for coding the feedback request text according to the request rule of the target chain to obtain a request text to be verified;

the first request text verification subunit is used for verifying the query data if the request text to be verified is the same as the source query request;

the second coding subunit is used for coding the source query request according to the request rule of the source chain to obtain a request text to be verified;

and the second request text verification subunit is used for verifying the query data if the request text to be verified is the same as the feedback request text.

Further, if the query request identifier includes a feedback timestamp of the query request, the verification module 503 includes:

and the time stamp verification unit is used for failing to verify the query data if the time difference between the feedback time stamp and the generation time stamp of the query request is greater than a set time threshold.

Further, the verification carrier includes at least one of a relay node, a blockchain node in the target chain, a blockchain node in the relay chain, and a trusted node of the target chain.

Further, the query data includes at least one of blockchain base data and contract data.

Further, the source chain and the target chain belong to a homogeneous blockchain or a heterogeneous blockchain.

Further, the verification module 503 further includes at least one of the following:

the node address verification subunit is used for verifying the query data according to the existence of the node address of the feedback node in the source chain;

the node signature verification subunit is used for verifying the signature of the signature information of the feedback node and verifying the query data according to the signature verification result; and the number of the first and second groups,

and the consensus algorithm verifying subunit is used for determining whether the number of the feedback nodes meets the consensus algorithm of the source chain or not and verifying the query data according to the determination result.

The cross-chain data verification device can execute the cross-chain data verification method provided by any embodiment of the invention, and has corresponding functional modules and beneficial effects for executing the cross-chain data verification method.

According to an embodiment of the present application, an electronic device and a readable storage medium are also provided.

As an implementation of each of the above cross-chain data verification methods, the present application also provides an embodiment of another cross-chain data verification apparatus. Referring to fig. 6, a cross-chain data verification apparatus 600 configured at block link points in a source chain includes: a query request obtaining module 601 and a to-be-verified data sending module 602. Wherein the content of the first and second substances,

a query request obtaining module 601, configured to obtain a query request initiated based on a verification requirement of a target chain;

a to-be-verified data sending module 602, configured to send to the verification carrier, the to-be-verified data including the query request identifier and the query data according to the query request, so that the verification carrier verifies the query data according to the query request identifier.

Fig. 7 is a block diagram of an electronic device implementing the cross-chain data verification method according to the embodiment of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present application that are described and/or claimed herein. The electronic device is the aforementioned verification carrier, and may include, but is not limited to, a block chain node in the target chain, a relay node, a block chain node in the relay chain, and a trusted node of the target chain.

As shown in fig. 7, the electronic apparatus includes: one or more processors 701, a memory 702, and interfaces for connecting the various components, including a high-speed interface and a low-speed interface. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions for execution within the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input/output apparatus (such as a display device coupled to the interface). In other embodiments, multiple processors and/or multiple buses may be used, along with multiple memories and multiple memories, as desired. Also, multiple electronic devices may be connected, with each device providing portions of the necessary operations (e.g., as a server array, a group of blade servers, or a multi-processor system). In fig. 7, one processor 701 is taken as an example.

The memory 702 is a non-transitory computer readable storage medium as provided herein. The memory stores instructions executable by the at least one processor to cause the at least one processor to perform the cross-chain data validation method provided herein. The non-transitory computer readable storage medium of the present application stores computer instructions for causing a computer to perform the cross-chain data validation method provided herein.

The memory 702 is used as a non-transitory computer readable storage medium, and can be used for storing non-transitory software programs, non-transitory computer executable programs, and modules, such as program instructions/modules corresponding to the cross-chain data verification method in the embodiment of the present application (for example, the query request sending module 501, the to-be-verified data receiving module 502, and the verification module 503 shown in fig. 5, or the query request obtaining module 601 and the to-be-verified data sending module 602 shown in fig. 6). The processor 701 executes various functional applications of the server and data processing by running non-transitory software programs, instructions, and modules stored in the memory 702, that is, implements the cross-chain data verification method in the above method embodiments.

The memory 702 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created by use of an electronic device implementing the cross-chain data verification method, and the like. Further, the memory 702 may include high speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory 702 may optionally include memory located remotely from the processor 701, which may be connected over a network to an electronic device implementing the cross-chain data verification method. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The electronic device implementing the cross-chain data verification method may further include: an input device 703 and an output device 704. The processor 701, the memory 702, the input device 703 and the output device 704 may be connected by a bus or other means, and fig. 7 illustrates an example of a connection by a bus.

The input device 703 may receive input numeric or character information and generate key signal inputs related to user settings and function control of an electronic apparatus implementing the cross-link data verification method, such as a touch screen, keypad, mouse, track pad, touch pad, pointer stick, one or more mouse buttons, track ball, joystick, or like input device. The output devices 704 may include a display device, auxiliary lighting devices (e.g., LEDs), and tactile feedback devices (e.g., vibrating motors), among others. The display device may include, but is not limited to, a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, and a plasma display. In some implementations, the display device can be a touch screen.

Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), the internet, and blockchain networks.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also called a cloud computing server or a cloud host, and is a host product in a cloud computing service system, so that the defects of high management difficulty and weak service expansibility in the traditional physical host and VPS service are overcome.

According to the technical scheme of the embodiment of the application, in the cross-chain data query process, the query request identification and the query data are carried in the data to be verified, and the query data are verified through the query request identification, so that the block header data of a source chain where the query data are located do not need to be stored in the verification carrier, and the data storage amount of the verification carrier in the cross-chain data verification is reduced. Meanwhile, the query data is verified through the query request identifier instead of a Mercker verification mechanism, the data operand is small, and the convenience of cross-link data verification is improved. In addition, the method does not need to rely on the construction of the Mercker tree in the cross-chain data verification process, so that the organizational structure of the source chain is not particularly limited, and the universality of cross-chain data verification is improved.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present application may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in the present application can be achieved, and the present invention is not limited herein.

The above-described embodiments should not be construed as limiting the scope of the present application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A cross-chain data verification method is applied to a verification carrier and comprises the following steps:

and verifying the query data according to the query request identifier.

2. The method of claim 1, wherein the query request identification includes at least one of a feedback numeric summary of the query request, a feedback request text of the query request, and a feedback timestamp of the query request.

3. The method of claim 2, wherein if the query request identifier comprises a feedback digital summary of the query request, the validating the query data according to the query request identifier comprises:

determining a digital abstract of the query request as a standard digital abstract;

and verifying the query data according to the standard digital abstract and the feedback digital abstract.

4. The method of claim 2, wherein if the query request identifier includes a feedback request text of the query request, the verifying the query data according to the query request identifier comprises:

verifying the query data according to the source query request associated with the query request and the feedback request text; the source query request is generated by a block chain link point in the target chain based on validation requirements.

5. The method of claim 4, wherein the verifying the query data according to the source query request and the feedback request text associated with the query request comprises:

coding the feedback request text according to the request rule of the target chain to obtain a request text to be verified; if the text of the request to be verified is the same as the source query request, the query data is verified to be passed; alternatively, the first and second electrodes may be,

coding the source query request according to the request rule of the source chain to obtain a request text to be verified; and if the request text to be verified is the same as the feedback request text, the query data is verified to be passed.

6. The method of claim 2, wherein, if the query request identifier includes a feedback timestamp of the query request, the verifying the query data according to the query request identifier comprises:

and if the time difference between the feedback timestamp and the generation timestamp of the query request is greater than a set time threshold, the query data is not verified.

7. The method of any of claims 1-6, wherein the authentication carrier comprises at least one of a relay node, a blockchain node in the target chain, a blockchain node in a relay chain, and a trusted node of the target chain.

8. The method of any of claims 1-6, wherein the query data includes at least one of blockchain base data and contract data.

9. The method of any of claims 1-6, wherein the source chain and the target chain belong to a homogeneous blockchain or a heterogeneous blockchain.

10. The method of any of claims 1-6, wherein the method further comprises at least one of:

verifying the query data according to the existence of the node address of the feedback node in the source chain;

checking the signature information of the feedback node, and verifying the query data according to the result of checking the signature; and the number of the first and second groups,

and determining whether the number of the feedback nodes meets a consensus algorithm of the source chain, and verifying the query data according to a determination result.

11. A cross-chain data verification method is applied to block chain link points in a source chain and comprises the following steps:

12. The method of claim 11, wherein the query request identification includes at least one of a feedback numeric summary of the query request, a feedback request text of the query request, and a feedback timestamp of the query request.

13. The method of claim 11 or 12, wherein the query data comprises at least one of blockchain base data and contract data.

14. The method of claim 11 or 12, wherein the source chain and the target chain belong to a homogeneous blockchain or a heterogeneous blockchain.

15. A cross-link data verification device configured on a verification carrier, comprising:

16. The apparatus of claim 15, wherein the query request identification comprises at least one of a feedback numeric summary of the query request, a feedback request text of the query request, and a feedback timestamp of the query request.

17. The apparatus of claim 16, wherein if the query request identification includes a feedback digital digest of the query request, the verification module comprises:

a standard digital abstract determining unit, configured to determine a digital abstract of the query request as a standard digital abstract;

18. The apparatus of claim 16, wherein if the query request identifier includes a feedback request text of the query request, the verification module comprises:

a request text verification unit, configured to verify the query data according to a source query request associated with the query request and the feedback request text; the source query request is generated by a block chain link point in the target chain based on validation requirements.

19. The apparatus of claim 18, wherein the request text verification unit comprises:

the first request text verification subunit is used for passing the verification of the query data if the request text to be verified is the same as the source query request;

20. The apparatus of claim 16, wherein if the query request identification includes a feedback timestamp of the query request, the validation module comprises:

and the time stamp verifying unit is used for verifying the query data if the time difference between the feedback time stamp and the generation time stamp of the query request is greater than a set time threshold.

21. The apparatus of any of claims 15-20, wherein the authentication carrier comprises at least one of a relay node, a blockchain node in the target chain, a blockchain node in a relay chain, and a trusted node of the target chain.

22. The apparatus of any of claims 15-20, wherein the query data comprises at least one of blockchain base data and contract data.

23. The apparatus of any of claims 15-20, wherein the source chain and the target chain belong to a homogeneous blockchain or a heterogeneous blockchain.

24. The apparatus of any of claims 15-20, wherein the validation module further comprises at least one of:

and the consensus algorithm verifying subunit is used for determining whether the number of the feedback nodes meets the consensus algorithm of the source chain or not and verifying the query data according to a determination result.

25. A cross-chain data validation apparatus configured at block link points in a source chain, comprising:

26. The apparatus of claim 25, wherein the query request identification comprises at least one of a feedback numeric summary of the query request, a feedback request text of the query request, and a feedback timestamp of the query request.

27. The apparatus of claim 25 or 26, wherein the query data comprises at least one of blockchain base data and contract data.

28. The apparatus of claim 25 or 26, wherein the source chain and the target chain belong to a homogeneous blockchain or a heterogeneous blockchain.

29. An electronic device, comprising:

at least one processor; and

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a cross-chain data validation method as claimed in any one of claims 1 to 14.

30. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform a cross-chain data validation method as recited in any of claims 1-14.