WO2023050966A1

WO2023050966A1 - Blockchain data verification

Info

Publication number: WO2023050966A1
Application number: PCT/CN2022/104372
Authority: WO
Inventors: 卓海振
Original assignee: 支付宝(杭州)信息技术有限公司; 蚂蚁区块链科技(上海)有限公司
Priority date: 2021-09-30
Filing date: 2022-07-07
Publication date: 2023-04-06
Also published as: CN113886495A

Abstract

Provided in the present description are a blockchain data verification method and apparatus, and an electronic device and a storage medium. The method is applied to a blockchain system that includes a blockchain subnet and a blockchain main net. The method comprises: a first blockchain subnet initiating a data verification transaction to a blockchain main net, wherein the data verification transaction is used for verifying whether target data is present on a second blockchain subnet; any one main net node in the blockchain main net executing the data verification transaction, so as to generate a candidate verification result when any one subnet node in the second blockchain subnet is deployed on a node device in which the main net node is located, and broadcasting the candidate verification result to other main net nodes in the blockchain main net; and any one main net node determining, from among all acquired candidate verification results, a target verification result that meets a data verification condition, such that the first blockchain subnet determines, according to the target verification result, whether the target data is present on the second blockchain subnet.

Description

Verify blockchain data

technical field

One or more embodiments of this specification relate to the technical field of blockchain, and in particular to a method, device, electronic device, and storage medium for verifying blockchain data.

Background technique

Blockchain technology is built on top of transmission networks such as peer-to-peer networks. Nodes in the blockchain network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data. In related technologies, based on the privacy requirements of blockchain data, blockchain subnets will be established on the basis of the blockchain main network, so that each blockchain subnet is independent and isolated from each other, so there is data sharing between each other. Verify requirements. Traditional cross-chain technology can meet the data verification requirements between different blockchain subnets, but the process is usually cumbersome and time-consuming, and ignores the trust that the blockchain main network can serve as data verification between different blockchain subnets Base.

Contents of the invention

In view of this, one or more embodiments of this specification provide a method, device, electronic device and storage medium for verifying blockchain data.

In order to achieve the above purpose, one or more embodiments of this specification provide the following technical solutions: According to the first aspect of one or more embodiments of this specification, a method for verifying blockchain data is proposed, which is applied to network and the block chain system of the block chain main network, wherein the node device where the subnet node in the block chain subnet is located is deployed with the main network node in the block chain main network, and the block chain The block chain subnet includes at least a first block chain subnet and a second block chain subnet, and the main network nodes in the block chain main network maintain data verification conditions corresponding to the second block chain subnet; the method includes: The first block chain subnet initiates a data verification transaction to the block chain main network, and the data verification transaction is used to verify whether the target data exists on the second block chain subnet; The network node executes the data verification transaction to generate a candidate verification result under the condition that any subnet node in the second block chain subnet is deployed on the node device where any main network node is located, and the Candidate verification results are broadcast to other main network nodes in the blockchain main network, wherein the candidate verification results are used to indicate whether the target data exists on any of the subnet nodes; The node determines a target verification result that satisfies the data verification condition from all the obtained candidate verification results, so that the first blockchain subnet can determine whether the target data exists in the second blockchain subnet according to the target verification result. net.

According to the second aspect of one or more embodiments of this specification, another method for verifying blockchain data is proposed, which is applied to the main network nodes in the blockchain main network. In a block chain system composed of block chain subnets, the node device where the subnetwork nodes in the block chain subnet are located is deployed with the main network nodes in the block chain main network, and the block chain subnet is at least Including the first block chain subnet and the second block chain subnet, the main network node in the block chain main network maintains the data verification conditions corresponding to the second block chain subnet; the method includes: receiving the first zone The data verification transaction initiated by the block chain subnet to the block chain main network, the data verification transaction is used to verify whether the target data exists on the second block chain subnet; Generate a candidate verification result when any subnet node in the second blockchain subnet is deployed on the network, and broadcast the candidate verification result to other main network nodes in the blockchain main network, wherein the The candidate verification result is used to indicate whether the target data exists on any subnetwork node; determine a target verification result that satisfies the data verification condition from all the obtained candidate verification results, so as to be used by the first block The chain subnet determines whether the target data exists in the second blockchain subnet according to the target verification result.

According to the third aspect of one or more embodiments of this specification, a device for verifying blockchain data is proposed, which is applied to the main network nodes in the blockchain main network, and the blockchain main network and block In the block chain system composed of the chain subnet, the node device where the subnet node in the block chain subnet is located is deployed with the main network node in the block chain main network, and the block chain subnet includes at least The first block chain subnet and the second block chain subnet, the main network node in the block chain main network maintains the data verification conditions corresponding to the second block chain subnet; the device includes: a transaction receiving module, used To receive the data verification transaction initiated by the first block chain subnet to the block chain main network, the data verification transaction is used to verify whether the target data exists on the second block chain subnet; the transaction execution module is used to execute the Data verification transaction, to generate a candidate verification result when any subnet node in the second block chain subnet is deployed on the node device where it is located, and broadcast the candidate verification result to the block chain master Other main network nodes in the network, wherein, the candidate verification result is used to indicate whether the target data exists on any subnet node; the condition verification module is used to determine one of the obtained candidate verification results A target verification result that satisfies the data verification condition, so that the first block chain subnet can determine whether the target data exists in the second block chain subnet according to the target verification result.

According to a fourth aspect of one or more embodiments of this specification, a blockchain system is proposed, including a blockchain subnet and a blockchain main network, wherein the subnet nodes in the blockchain subnet are located The main network nodes in the block chain main network are deployed on the node device, and the block chain subnet includes at least the first block chain subnet and the second block chain subnet, and the block chain main network The main network node maintains the data verification conditions corresponding to the second block chain subnet; the system includes: the first block chain subnet, used to initiate a data verification transaction to the block chain main network, and the data verification transaction is used for Whether there is target data on the second block chain sub-net for verification; block chain main network, any main network node in the block chain main network executes the data verification transaction, so that any main network node in the block chain Generate a candidate verification result when any subnet node in the second block chain subnet is deployed on the node device, and broadcast the candidate verification result to other main network nodes in the block chain main network, Wherein, the candidate verification result is used to indicate whether the target data exists on any of the subnetwork nodes; the any main network node determines a data verification result that satisfies the data verification condition from all obtained candidate verification results. A target verification result, so that the first block chain subnet can determine whether the target data exists in the second block chain subnet according to the target verification result.

According to a fifth aspect of the embodiments of this specification, there is provided an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein, the processor executes the executable instructions to implement the above verification area The steps of the method of blockchain data.

According to a sixth aspect of the embodiments of the present specification, there is provided a computer-readable storage medium on which executable instructions are stored; wherein, when the instructions are executed by a processor, the steps of the above-mentioned method for verifying blockchain data are implemented.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the specification.

Description of drawings

Fig. 1 is a schematic diagram of a blockchain system including a blockchain main network and a blockchain subnet provided by an exemplary embodiment.

Fig. 2 is a flowchart of a method for verifying blockchain data provided by an exemplary embodiment.

Fig. 3 is a flow chart of another method for verifying blockchain data provided by an exemplary embodiment.

Fig. 4 is a schematic structural diagram of a device provided by an exemplary embodiment.

Fig. 5 is a block diagram of a device for verifying blockchain data provided by an exemplary embodiment.

Fig. 6 is an architecture diagram of a system for verifying blockchain data provided by an exemplary embodiment.

Detailed ways

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. Implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with aspects of one or more embodiments of the present specification as recited in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or less steps than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.

Due to the decentralized nature of the blockchain network, all blockchain nodes in the blockchain network will maintain the same block data, which cannot meet the special needs of some nodes. Taking the consortium chain as an example, all consortium members (that is, node members in the consortium) can form a blockchain network, and all consortium members have corresponding blockchain nodes in the blockchain network, and can pass the corresponding zone Block chain nodes obtain all transactions and related data that occur on the block chain network. However, in some cases, there may be some alliance members who want to complete some transactions with privacy requirements. These alliance members hope that these transactions can be stored on the blockchain or take advantage of other advantages of blockchain technology, and can avoid other transactions. Affiliate members see these transactions and related data. Although these alliance members can additionally form a new blockchain network, the establishment method is similar to the above-mentioned blockchain network that includes all alliance members, but building a new blockchain network from scratch requires a lot of resources, and regardless of The establishment process of the blockchain network or the configuration process after completion is very time-consuming. The needs among alliance members are often temporary or have a certain timeliness, so that the newly built blockchain network will soon lose the meaning of existence due to the disappearance of demand, thus further increasing the chain construction cost of the above-mentioned blockchain network . However, the needs of alliance members often change, and the alliance members corresponding to each demand are often different. Therefore, whenever the alliance members change, it may be necessary to form a new blockchain network, resulting in resource and time constraints. A lot of waste.

To this end, the established blockchain network can be used as the blockchain main network, and a blockchain subnet can be formed on the basis of the blockchain main network. Then, in the consortium chain scenario such as the one mentioned above, the consortium members can build the required blockchain subnet based on their own needs while already participating in the blockchain main network. Since the blockchain subnet is established on the basis of the blockchain main network, the construction process of the blockchain subnet is compared to the completely independent establishment of a blockchain network, the resources consumed and the time required, etc. Both are greatly reduced, and the flexibility is extremely high.

The process of quickly establishing a blockchain subnet based on the blockchain main network is as follows: each blockchain node in the blockchain main network obtains a transaction for establishing a blockchain subnet, and the transaction includes the configuration information of the blockchain subnet , the configuration information includes the identity information of the node members participating in the formation of the block chain subnet, each block chain node in the block chain main network respectively executes the transaction to disclose the configuration information, when the When the configuration information includes the identity information of the node members corresponding to the first block chain node, the node device deploying the first block chain node starts the first block belonging to the block chain subnet based on the genesis block containing the configuration information. Two blockchain nodes.

The transaction of establishing a blockchain subnet can be initiated by the administrator of the blockchain main network, that is, only the administrator is allowed to establish a blockchain subnet on the basis of the blockchain main network, and avoid opening the establishment authority of the blockchain subnet to Normal users to prevent security issues caused by this. In some cases, ordinary users of the blockchain main network can also be allowed to initiate the above-mentioned transaction of establishing a blockchain subnet to meet the networking needs of ordinary users, so that ordinary users can still initiate transactions when the administrator is inconvenient. It is possible to quickly form a blockchain subnet.

Fig. 1 is a schematic diagram of a block chain system including a block chain main network and a block chain subnet provided by an exemplary embodiment. Taking the example shown in Fig. 1, the block chain main network is subnet0, and the subnet0 includes The blockchain nodes are nodeA, nodeB, nodeC, nodeD, nodeE, etc. Assume that nodeA, nodeB, nodeC and nodeD want to form a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to form a blockchain subnet, then nodeA can initiate the above-mentioned transaction to form a blockchain subnet to subnet0; If nodeE is an administrator and only allows the administrator to initiate the transaction of establishing a blockchain subnet, then nodeA~nodeD needs to make a request to nodeE, so that nodeE initiates the above transaction of establishing a blockchain subnet to subnet0; if nodeE is an administrator but allows Ordinary users initiate a transaction to establish a blockchain subnet, then nodeA～nodeE can initiate the above transaction to subnet0 to establish a blockchain subnet. Of course, whether it is an administrator or an ordinary user, the blockchain node that initiates the transaction to form a blockchain subnet does not necessarily participate in the established blockchain subnet. network, but nodeE can initiate the above-mentioned transaction of establishing a blockchain subnet to subnet0, and not necessarily nodeA~nodeD initiate the transaction of establishing a blockchain subnet.

When a blockchain subnet is established on the basis of the blockchain main network, it is easy to understand that there will be a logical hierarchical relationship between the blockchain subnet and the blockchain main network. For example, when a blockchain subnet subnet1 is established on subnet0 shown in Figure 1, it can be considered that subnet0 is at the first layer and subnet1 is at the second layer. In one case, the blockchain main network in this specification can be the underlying blockchain network, that is, the blockchain main network is not a blockchain subnet formed on the basis of other blockchain networks, such as the subnet0 can be regarded as the blockchain mainnet belonging to the underlying blockchain network type. In another case, the blockchain main network in this specification can also be a subnet of other blockchain networks. For example, another blockchain subnet can be further established on the basis of subnet1 in Figure 1. At this time, it can be considered subnet1 is the blockchain main network corresponding to the blockchain subnet, and this does not affect that subnet1 also belongs to the blockchain subnet created on subnet0. It can be seen that the blockchain main network and the blockchain subnet are actually relative concepts. The same blockchain network can be the blockchain main network in some cases and the blockchain subnet in other cases.

After the above-mentioned transaction for establishing a blockchain subnet is sent to the blockchain main network, the consensus nodes in the blockchain main network will conduct a consensus, and after the consensus is passed, each main network node will execute the transaction to complete the block The formation of the chain subnet. The consensus process depends on the consensus mechanism adopted, such as any consensus mechanism mentioned above, and this description does not limit it.

By including the configuration information in the above-mentioned transaction of establishing the blockchain subnet, the configuration information can be used to configure the established blockchain subnet so that the established blockchain subnet meets the networking requirements. For example, by including the identity information of node members in the configuration information, it is possible to specify which blockchain nodes are included in the established blockchain subnet.

The identity information of the node members may include the public key of the node, or other information that can represent the identity of the node such as the node ID, which is not limited in this specification. Taking the public key as an example, each blockchain node has one or more sets of corresponding public-private key pairs. The blockchain node holds the private key and the public key is public and uniquely corresponds to the private key. Therefore, it can be passed The public key is used to represent the identity of the corresponding blockchain node. Therefore, for blockchain nodes that want to be node members of the blockchain subnet, the public keys of these blockchain nodes can be added to the above-mentioned transaction of forming the blockchain subnet as the identity information of the above-mentioned node members. The above-mentioned public-private key pair can be used in the process of signature verification. For example, in a consensus algorithm with a signature, for example, nodeA1 in subnet1 uses its own private key to sign the message, and then broadcasts the signed message in subnet1, while nodeB1, nodeC1 and nodeD1 can use the public key of nodeA1 Signature verification is performed on the received message to confirm that the message received by itself is indeed from nodeA1 and has not been tampered with.

The first main network node may be a blockchain node on the blockchain main network that is a node member indicated by the configuration information. When building a blockchain subnet, instead of the first main network node directly participating in the establishment of the blockchain subnet and becoming its node member, the first subnet node needs to be generated by the node device used to deploy the first main network node , and the first subnetwork node becomes a node member in the blockchain subnetwork. The first main network node and the first subnet node correspond to the same blockchain member, for example, in the alliance chain scenario, they correspond to the same alliance chain member, but the first main network node The node belongs to the blockchain subnet, so that the blockchain members can participate in the transactions of the blockchain main network and the blockchain subnet respectively; and, since the blockchain main network and the blockchain subnet belong to two independent Blockchain network, so that the blocks generated by the first main network node and the blocks generated by the first subnet node are respectively stored in different storages on the node device (the storage used can be a database, for example), realizing the first The storage used by the main network node and the first subnet node is isolated from each other, so the data generated by the blockchain subnet will only be synchronized among the node members of the blockchain subnet, so that only those who participate in the blockchain main The blockchain members of the network cannot obtain the data generated on the blockchain subnet, which realizes the data isolation between the blockchain main network and the blockchain subnet, and satisfies the requirements of some blockchain members (that is, the districts participating in the blockchain subnet). Transaction requirements between blockchain members).

It can be seen that the first main network node and the first subnet node are logically divided blockchain nodes, and from the perspective of physical equipment, it is equivalent to deploying the first main network node and the first subnet node The node devices participate in the blockchain main network and the blockchain subnet at the same time. Since the blockchain main network and the blockchain subnet are independent of each other, the identity systems of the two blockchain networks are also independent of each other, so even if the first main network node and the first subnet node can use exactly the same public key, the two should still be considered as different blockchain nodes. For example, in FIG. 1 , nodeA in subnet0 is equivalent to the first main network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 is equivalent to the first subnet node. It can be seen that since the identity systems are independent of each other, even if the public key used by the first subnet node is different from that of the first main network node, it will not affect the implementation of the scheme in this specification.

Of course, the node members of the blockchain subnet are not necessarily only part of the node members of the blockchain main network. In some cases, the node members of the blockchain subnet can be completely consistent with the node members of the blockchain main network. At this time, all blockchain members can obtain the data on the blockchain main network and the blockchain subnet, but The data generated by the blockchain main network and the blockchain subnet can still be isolated from each other. For example, by implementing one type of business on the blockchain main network and another type of business on the blockchain subnet, the two types of The business data generated by the business are isolated from each other.

In addition to the above-mentioned identity information of node members, the configuration information may also include at least one of the following: the network identifier of the blockchain subnet, the identity information of the administrator of the blockchain subnet, the The attribute configuration of the code, etc., is not limited in this specification. The network identifier is used to uniquely represent the blockchain subnet, so the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets formed on the blockchain main network. The identity information of the administrator of the blockchain subnet can be, for example, the public key of the node member who is the administrator; the administrators of the blockchain main network and the blockchain subnet can be the same or different.

One of the advantages of building a blockchain subnet through the blockchain mainnet is that since the first mainnet node has already been deployed on the node device that generates the first subnetwork node, the area used by the first mainnet node can be The block chain platform code is reused on the first subnet node, which eliminates the repeated deployment of the block chain platform code and greatly improves the efficiency of the block chain subnet. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node can reuse the attribute configuration adopted on the first main network node; if the configuration information includes the attribute configuration for the blockchain platform code attribute configuration, the first subnetwork node can adopt the attribute configuration, so that the attribute configuration adopted by the first subnetwork node is not limited to the attribute configuration of the first main network node, and has nothing to do with the first main network node. The attribute configuration for the blockchain platform code can include at least one of the following: code version number, whether consensus is required, consensus algorithm type, block size, etc., which are not limited in this specification.

Transactions that form blockchain subnets include transactions that call contracts. The transaction can specify the address of the called smart contract, the method called and the parameters passed in. For example, the invoked contract can be the aforementioned genesis contract or system contract, the invoked method can be a method for building a blockchain subnet, and the incoming parameters can include the above-mentioned configuration information. In one embodiment, the transaction may contain the following information:

from: Administrator

to: Subnet

method: AddSubnet(string)

string: genesis

Among them, the from field is the information of the initiator of the transaction. For example, Administrator indicates that the initiator is an administrator; the to field is the address of the called smart contract. For example, the smart contract can be a Subnet contract, and the to field is specifically the Subnet The address of the contract; the method field is the calling method. For example, the method used to build a blockchain subnet in the Subnet contract can be AddSubnet(string), and string is the parameter in the AddSubnet() method. In the above example, genesis is used to represent the The value of the parameter, the genesis is specifically the aforementioned configuration information.

Take nodes nodeA~nodeE on Subnet0 executing a transaction calling the AddSubnet() method in the Subnet contract as an example. After the transaction passes the consensus, nodeA～nodeE respectively execute the AddSubnet() method and pass in the configuration information to obtain the corresponding execution results.

The execution result of the contract may include the configuration information, and the execution result may be included in the above-mentioned receipt, which may include an event related to the execution of the AddSubnet() method, that is, a networking event. The topic of networking events can contain predefined networking event identifiers to distinguish them from other events. For example, in the event related to the execution of the AddSubnet() method, the content of the topic is the keyword subnet, and this keyword is different from the topic in the event generated by other methods. Then, by monitoring the topics contained in each event in the generated receipt, nodeA~nodeE can determine to monitor the event related to the execution of the AddSubnet() method, that is, the networking event, when the topic containing the keyword subnet is monitored. For example, the event in the receipt is as follows:

Event:

[topic:other][data]

[topic:subnet][data]

…

Then, when nodeA~nodeE listens to the first event, because the content of the included topic is other, it is determined that the event has nothing to do with the AddSubnet() method; and, when nodeA~nodeE listens to the second event, because the content of the included The content of the topic is subnet, determine that the event is related to the AddSubnet() method, and then read the data field corresponding to the event, which contains the above configuration information. Taking the configuration information including the public key of the node member of the blockchain subnet as an example, the content of the data field may include, for example:

{subnet1;

The public key of nodeA, the IP of nodeA, the port number of nodeA...;

public key of nodeB, IP of nodeB, port number of nodeB...;

The public key of nodeC, the IP of nodeC, the port number of nodeC...;

The public key of nodeD, the IP of nodeD, the port number of nodeD...;

}

Among them, subnet1 is the network identifier of the blockchain subnet you want to create. Each blockchain node in the blockchain main network can record the network identifiers of all blockchain subnets that have been created on the blockchain main network, or other information related to these blockchain subnets, such information can be maintained in In the above-mentioned Subnet contract, it may specifically correspond to the values of one or more contract states included in the Subnet contract. Then, nodeA～nodeE can determine whether the above-mentioned subnet1 already exists according to the recorded network identifiers of all blockchain subnets that have been created; if it does not exist, it means that subnet1 is a new blockchain subnet that needs to be created currently, and if it exists, it means subnet1 already exists.

In addition to adopting the network identifier of the new blockchain subnet you want to create, you can also use a predefined new network identifier, which indicates that the corresponding networking event is used to form a new blockchain subnet. For example, the above subnet1 can be replaced with newsubnet, which is a predefined new network identifier. When nodeA~nodeE recognizes that the data field contains newsubnet, they can determine that the event containing this newsubnet is a networking event, and a new one needs to be created. Blockchain subnet.

In addition to the network identifier subnet1, the above data field also includes identity information of each node member and so on. The node device deploying the first main network node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first main network node belongs to the node member, the deployment second A node device of a main network node obtains the configuration information or the genesis block included in the networking event. Alternatively, the first blockchain node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member, trigger the deployment of the first blockchain node. A node device of a blockchain node acquires the configuration information or the genesis block included in the networking event.

As mentioned earlier, node devices can listen for receipts directly. Assuming that nodeA～nodeE are respectively deployed on node devices 1～5, and node devices 1～5 can monitor the receipts generated by nodeA～nodeE respectively, then when it is detected that subnet1 is a blockchain subnet that needs to be newly established, node device 1 ~5 will further identify the identity information of the node members contained in the data field to determine its own processing method. Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as nodeA's public key, IP address, and port number, then node device 1 obtains configuration information from the data field based on the above message mechanism , generate a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and then nodeA1 will load the generated genesis block, thus becoming a subnet node of subnet1; similarly, node device 2 can generate nodeB1, node Device 3 can generate nodeC1, and node device 4 can generate nodeD1. And, node device 5 will find that the identity information contained in the data field does not match itself, then the node device 5 will not generate a genesis block according to the configuration information in the data field, nor will it generate a blockchain node in subnet1.

As mentioned above, the blockchain nodes in the blockchain main network can monitor receipts and trigger node devices to perform related processing according to the monitoring results. For example, nodeA～nodeE will further identify the identity information of the node members contained in the data field in order to determine their own processing methods when they determine that subnet1 is a blockchain subnet that needs to be newly established. For example, nodeA~nodeD will find that the data field contains their own identity information such as their public key, IP address, and port number. Assume that nodeA~nodeD are deployed on node devices 1~4 respectively. Taking nodeA and node device 1 as an example: nodeA will Trigger node device 1, so that node device 1 obtains configuration information from the data field based on the above message mechanism and generates a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and nodeA1 will load the generated genesis block, Thus, it becomes a subnet node in subnet1; similarly, nodeB will trigger node device 2 to generate nodeB1, nodeC will trigger node device 3 to generate nodeC1, and nodeD will trigger node device 4 to generate nodeD1. And, nodeE will find that the identity information contained in the data field does not match itself, assuming that nodeE is deployed on node device 5, then the node device 5 will not generate a genesis block based on the configuration information in the data field, nor will it generate subnet1 nodes in .

As mentioned above, the first main network node and the first subnet node do not necessarily use the same identity information. Therefore, in the above embodiment, the data field may contain identity information generated in advance for nodeA1-nodeD1, which is different from the identity information of nodeA-nodeD. Still take nodeA and node device 1 as an example: if node device 1 finds the identity information of nodeA1 in the data field, it can generate a genesis block, deploy nodeA1, and nodeA1 loads the genesis block; or, if nodeA is in the data field If the identity information of nodeA1 is found in , then nodeA will trigger node device 1 to generate a genesis block, deploy nodeA1, and nodeA1 will load the genesis block. The processing methods of other blockchain nodes or node devices are similar and will not be repeated here.

In addition to configuration information, the execution result of the contract can include the genesis block. In other words, in addition to including configuration information in the data field, you can also directly generate a genesis block containing configuration information in the process of executing the contract call, so that the genesis block is included in the data field, then for the above nodeA ~ nodeD and In other words, the corresponding node devices 1-4 can directly obtain the genesis block from the data field through the message mechanism without generating it by themselves, which can improve the deployment efficiency of nodeA1-nodeD1.

In this specification, the transaction of establishing a blockchain subnet may not be a transaction that calls a smart contract, so that a blockchain network that does not support smart contracts can also implement the technical solution of this specification, so that on the basis of the blockchain main network Quickly create a blockchain subnet. For example, a group of network transaction type identifiers can be pre-defined, and when the transaction contains the network transaction type identifier, it indicates that the transaction is used to form a new blockchain subnet, that is, the transaction is a transaction to form a blockchain subnet. The blockchain platform code can contain relevant processing logic for component blockchain subnets, so that when the first main network node running the blockchain platform code executes a transaction, if it finds that the transaction contains the above-mentioned networking transaction type identification, and the first main network node belongs to the node member indicated by the configuration information in the transaction, based on the above processing logic, the node device deploying the first main network node can be triggered to generate a genesis block containing the configuration information and start the first A subnetwork node, the first subnetwork node loads the genesis block to form a blockchain node in the blockchain subnetwork.

The node device implements the deployment of a blockchain node on the node device by creating an instance of running the blockchain platform code in the process. For the first main network node, the node device creates the first instance in the above process, and the first instance runs the blockchain platform code to form. Similarly, for the first subnetwork node, the node device creates a second instance different from the first instance in the above process, and the second instance runs the blockchain platform code to form. For example, the node device can first create the first instance in the process to form the first blockchain node in the blockchain main network; In the above process, a second instance is created, which is different from the above-mentioned first instance, and the second instance forms a second blockchain node in the blockchain subnet. When the first instance and the second instance are in the same process, because no cross-process interaction is involved, the difficulty of deploying the first subnet node can be reduced and the deployment efficiency can be improved; of course, the second instance may also be in separate nodes from the first instance In different processes on the device, this specification does not limit this; for example, the node device can create the first instance in the first process to form the first blockchain node in the blockchain main network; and when the node When the node member corresponding to the device wants to participate in the establishment of a blockchain subnet, it can start a second process different from the first process, and create a second instance in the second process, which is different from the first instance above. Furthermore, the second instance forms a second blockchain node in the blockchain subnet. In fact, each blockchain node deployed on any node device involved in the embodiments of this specification is a different blockchain instance running on any node device, and each blockchain node deployed on any node device The blocks generated by the nodes are respectively stored in different storages (such as databases) on any node device, and the storages used by each blockchain node deployed by any node device are isolated from each other.

Through the above method, a blockchain subnet can be created on the blockchain mainnet. Taking Figure 1 as an example, subnet0 originally included nodeA~nodeE, and subnet1 can be built on the basis of subnet0. This subnet1 includes nodeA1~nodeD1, and nodeA and nodeA1, nodeB and nodeB1, nodeC and nodeC1, nodeD and nodeD1 are respectively deployed in on the same node device. Similarly, subnet2 or more blockchain subnets can also be established on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeD and nodeD1, nodeE and nodeE2 are respectively deployed on the same node device. And, subnet1, subnet2, etc. can be used as the new blockchain main network, and a blockchain subnet can be further formed on this basis. The process is similar to the formation of subnet1 or subnet2, and will not be repeated here.

As mentioned above, the different blockchain subnets established on the blockchain mainnet through the above methods are independent and isolated from each other. Received by nodeA2, nodeB2, nodeC2 and nodeE2 in subnet2. Therefore, different blockchain subnets logically belong to different blockchain networks. In related technologies, the credible cross-chain interaction between different blockchain networks needs to be completed through cross-chain protocols, such as side chain technology, witness mechanism or relay technology, etc., but the traditional cross-chain technology adopts The implementation of cross-chain protocols is usually cumbersome and time-consuming. Moreover, traditional cross-chain protocols do not take into account the differences between cross-chain scenarios between blockchain subnets and traditional cross-chain scenarios, and ignore the blockchain The main network can serve as the basis of trust for data verification between different blockchain subnets, which requires traditional cross-chain protocols between different blockchain subnets to achieve trusted verification of each other's blockchain data.

For this reason, this specification proposes a method for verifying blockchain data, which is applied to a blockchain system including a blockchain subnet and a blockchain main network, wherein the subnet nodes in the blockchain subnet are The main network node in the block chain main network is deployed on the node device at the location, and the block chain subnet includes at least a first block chain subnet and a second block chain subnet, and in the block chain main network The main network node maintains the data verification conditions corresponding to the second blockchain subnet, which allows the first blockchain subnet to verify the existence of blockchain data from the second blockchain subnet , through the correlation between the blockchain main network and each blockchain subnet on the network architecture at the node device level, the blockchain main network can be used as a trust medium between different blockchain subnets to achieve simpler data verification protocol.

Fig. 2 is a flowchart of a method for verifying blockchain data provided by an exemplary embodiment. The method is applied to a block chain system including a block chain subnet and a block chain main network, wherein the node device where the subnet node in the block chain subnet is located is deployed with the block chain in the block chain main network The main network nodes of the blockchain subnet include at least the first blockchain subnet and the second blockchain subnet, and the main network nodes in the blockchain main network maintain data corresponding to the second blockchain subnet Verifying the conditions, the method includes the following steps.

Step 202, the first blockchain subnet initiates a data verification transaction to the blockchain main network, and the data verification transaction is used to verify whether the target data exists on the second blockchain subnet.

The first blockchain subnet involved in the embodiment of this specification is the demander of the data verification service, which has the requirement to verify the target data. For example, the first blockchain subnet has acquired the target data, but it is not clear whether the target data really comes from the second blockchain subnet, or, although the first blockchain subnet has not acquired the target data, it still hopes to Verify that the target data corresponding to a certain data description information exists in the second blockchain subnet truthfully as the blockchain data of the second blockchain subnet, then the first blockchain subnet can pass to the blockchain The main network initiates a data verification transaction to verify whether the target data exists on the second blockchain subnet.

In the embodiment of this specification, it involves a blockchain system including a blockchain subnet and a blockchain main network, such as the blockchain system composed of subnet0, subnet1 and subnet2 shown in Figure 1, where subnet0 is Blockchain main network, while subnet1 and subnet2 are blockchain subnets. Assuming that subnet1 is the first blockchain subnet and subnet2 is the second blockchain subnet, node devices 1, 2, 3 and 4 where the subnet nodes nodeA1, nodeB1, nodeC1 and nodeD1 are located in subnet1 are respectively deployed with subnet0 nodeA, nodeB, nodeC and nodeD, and the node devices 1, 2, 3 and 5 where the subnet nodes nodeA2, nodeB2, nodeC2 and nodeE2 in subnet2 are located are respectively deployed with nodeA, nodeB, nodeC and nodeE in subnet0. Therefore, there must be a main network node deployed on the node device where the subnet node is deployed. The main network nodes in the blockchain main network maintain data verification conditions corresponding to the second blockchain subnet, for example, each main network node nodeA-nodeE in subnet0 maintains data verification conditions corresponding to subnet2, of course , each main network node nodeA～nodeE also maintains data verification conditions corresponding to subnet1.

In the embodiment of this specification, the data verification conditions maintained on the blockchain main network can be created or changed by sending transactions to the blockchain main network. For example, a subnetwork creation transaction for creating a new blockchain subnet may be initiated to the blockchain mainnet, and the blockchain mainnet responds to the subnetwork creation transaction for creating a new blockchain subnetwork so that the zone The main network node in the block chain main network obtains and maintains the data verification conditions corresponding to the new blockchain subnet after executing the subnet creation transaction, and the subnet creation transaction contains the data corresponding to the new blockchain subnet Verify conditions. In the embodiment of this specification, the above-mentioned subnet creation transaction for creating a new blockchain subnet is the aforementioned transaction for establishing a blockchain subnet. Since the blockchain main network needs to maintain the data verification conditions of each blockchain subnet, therefore The data verification conditions of the new blockchain subnet can be carried in the subnet creation transaction, so that the blockchain main network can maintain the data verification conditions corresponding to the new blockchain subnet as soon as the new blockchain subnet is created, for example The data verification condition is stored in the contract state corresponding to the new blockchain subnet in the aforementioned Subnet contract (system contract).

For another example, a condition change transaction for updating the data verification conditions corresponding to the second blockchain subnet may also be initiated to the main network of the blockchain, and a transaction for updating the data verification conditions corresponding to the second blockchain subnet may be initiated to the main network of the blockchain. The condition change transaction of the data verification condition corresponding to the second block chain subnet, so that the main network node in the block chain main network will update the data verification condition maintained by itself to the new one after executing the condition change transaction. Data verification conditions, the condition modification transaction includes the new data verification conditions corresponding to the second block chain subnet. In the embodiment of this specification, when the second blockchain subnet changes due to factors such as the total number of nodes and the consensus algorithm, it is necessary to immediately adjust the data verification conditions corresponding to the blockchain subnet to ensure blockchain data verification. Therefore, by initiating a condition change transaction to the blockchain main network to update the data verification conditions corresponding to the second blockchain subnet, the second block maintained in the blockchain main network The data verification conditions corresponding to the chain subnet are adjusted in a timely manner. When the data verification conditions are maintained in the smart contract deployed on the blockchain main network, the condition change transaction will update the smart contract used to record the second blockchain subnet. The network corresponds to the contract status of the data verification conditions, and finally updates the world status of the blockchain main network. Of course, it is also possible to initiate a condition change transaction to the blockchain main network to update the data verification conditions corresponding to other blockchain subnets, and this specification does not impose any restrictions on this.

In the embodiment of this specification, any subnet node in the first blockchain subnet can initiate a data verification transaction to the node device where it is located, so as to forward the data verification transaction to the blockchain main network. Since the main network node is deployed on the node device where the subnetwork node is located, the node device can verify the network identification field in the transaction by identifying the data initiated by the subnetwork node in the first blockchain subnetwork (for example, the zone The network identifier subnet0 of the block chain main network, so as to know that the transaction needs to be routed to the block chain main network instead of the first block chain subnet or other block chain networks. At this time, the transaction routing module in the node device (such as the consensus module ) will pass the data verification transaction to the local main network node. At the same time, the transaction routing module can also broadcast the transaction to other main network nodes in the blockchain main network through the pre-established consensus link in the blockchain main network. network nodes, so that the first blockchain subnet can initiate a data verification transaction to the blockchain main network. In the embodiment of this specification, since the main network nodes in the blockchain main network and the subnet nodes in the blockchain subnet are deployed on the same node device, multiple blockchain nodes deployed on the same node device They share the same consensus module with each other, which makes it possible to send transactions from the first blockchain subnet to the blockchain mainnet.

In the embodiment of this specification, the target data includes one of the following: transaction data, status data, and receipt data. Among them, transaction data, status data and receipt data are logically organized into corresponding tree structures to facilitate subsequent data verification. The tree structure formed by transaction data may be called a transaction tree, the tree structure formed by state data may be called a state tree, and the tree structure formed by receipt data may be called a receipt tree.

Step 204, any main network node in the blockchain main network executes the data verification transaction, so that any one of the second blockchain subnets is deployed on the node device where any main network node is located. In the case of a subnet node, a candidate verification result is generated, and the candidate verification result is broadcast to other main network nodes in the blockchain main network, wherein the candidate verification result is used to indicate that any subnet Whether the target data exists on the node.

After the first blockchain subnet initiates a data verification transaction in the blockchain main network, each main network node in the blockchain main network will receive and execute the data verification transaction, for example, when the data verification transaction includes calling the In the case of the transaction of the data verification smart contract deployed on the blockchain main network, each main network node will respectively call the locally maintained data verification smart contract to execute the contract logic as in step 204 when executing the data verification transaction.

The data verification transaction involved in this specification includes the data description information of the target data and the network identification of the second blockchain subnet. Wherein, the network identifier is used to indicate any main network node: determine the subnetwork node corresponding to the network identifier deployed on the node device where it is located as any subnetwork node; the data description The information is used to instruct the any main network node to: determine the data matching the data description information on the any sub-network node as the target data. Wherein, the data description information may include transaction hash, account ID, contract address, parameter name and so on. In this embodiment, when any main network node executes a data verification transaction, it will first determine that the data verification transaction is used for the second blockchain subnet according to the network identifier of the second blockchain subnet carried in the data verification transaction. network data, so that any main network node will check whether any subnetwork node in the second blockchain subnetwork is deployed on the node device where it is located, and when it is determined that any subnetwork node is deployed In the case of network nodes, candidate verification results are generated, and the generated candidate verification results are broadcast to other main network nodes in the blockchain main network through the consensus module. Specifically, when it is determined that any of the subnetwork nodes is deployed, any mainnetwork node will further verify the data description information of the target data carried in the transaction according to the data. Match whether the target data corresponding to the data description information exists in the local database. If the target data is successfully matched, it proves that the target data corresponding to the data description information does exist in the second blockchain sub-chain deployed by the node device where it is located. In the subnet node corresponding to the network, the candidate verification result generated at this time will contain indication information indicating that the target data exists on any subnet node; similarly, if any main network node does not match the If the target data is to prove that the target data corresponding to the data description information does not exist in any of the subnetwork nodes, the candidate verification result generated at this time will contain a An indication of the target data. The fundamental reason why any of the above-mentioned main network nodes can access the local database corresponding to any sub-network node is that in the embodiment of this specification, the main network node and zone in the blockchain main network are deployed on the same node device. Therefore, although the blockchain main network and the second blockchain subnet logically belong to different blockchain networks, the corresponding main network nodes and subnet nodes are deployed in the same On the node device, this makes it possible to completely realize unauthorized management at the node device level, that is, the main network node can have the right to access other sub The database corresponding to the network nodes creates a cross-chain interaction channel based on node equipment.

In an embodiment, any main network node generates a candidate verification result when it is determined that any subnet node is deployed on the node device where it is located, and that any subnet node maintains the target data , and broadcast the candidate verification result to other main network nodes in the blockchain main network, but no subnet node is deployed on the node device where it is determined, or although any subnet node is deployed If the target data is not maintained by any sub-network node but the target data is not maintained by any sub-network node, no candidate verification result is generated. In this embodiment of the specification, the existence of a candidate verification result can be used to indicate that the target data exists on any subnetwork node.

In the embodiment of this specification, if any main network node determines that no subnet node in the second blockchain subnet is deployed on the node device where it is located, it does not generate the candidate verification result, Or generate candidate verification results containing preset invalid data and broadcast to other main network nodes in the blockchain main network. In the embodiment of this specification, for the main network node where the node device is not deployed with any subnet node in the second blockchain subnet, it is obviously unable to make a decision on whether the target data exists in the second blockchain subnet. Effective judgment, so such main network nodes do not need to generate candidate verification results, but collect candidate verification results broadcast by other main network nodes as the basis for judgment. Of course, such main network nodes can also generate candidate verification results containing invalid data And broadcast, for example, the candidate verification result generated and broadcast contains "unknown" to indicate that the main network node corresponding to the candidate verification result cannot effectively judge whether the target data exists in the second blockchain subnet, so there is no Reference value, so when other main network nodes receive candidate verification results containing "unknown", they will discard it and not count it into all candidate verification results received, thus preventing those main network nodes that cannot make valid judgments from The selection of the final target verification result forms interference, and can be used to determine that each main network node has indeed received the verification transaction and made a response, so as to rule out the situation that the main network node does not respond normally. In other words, if you do not receive candidate verification results (even if unknown) returned by each main network node, it indicates that there may be network problems or downtime.

Any of the above-mentioned main network nodes can check whether any subnetwork node in the second blockchain subnetwork is deployed on the node device where it is located in a variety of ways. In one embodiment, the data verification smart contract can maintain the membership information (such as node public key) of each blockchain subnet managed by the blockchain main network, for example, the contract account corresponding to the data verification smart contract can be maintained , as the contract status under the contract account. Therefore, any of the above-mentioned main network nodes can verify the contract account corresponding to the smart contract by reading data to obtain the node public key set of each node member in the second blockchain subnet, so that any of the main network nodes can The maintained node public key is compared, if the node public key of any main network node is included in the node public key set corresponding to the second blockchain subnet, it means that any main network node belongs to the second block The node member of the chain subnet, that is, any subnet node in the second blockchain subnet is deployed on the node device where any main network node is located; if the node public key of any main network node is not included in The set of node public keys corresponding to the second blockchain subnet indicates that any of the main network nodes does not belong to the node members of the second blockchain subnet, that is, the node device where any of the main network nodes is located does not deploy Any subnetwork node in the second blockchain subnetwork. In another embodiment, the membership information of each blockchain subnet managed by the blockchain mainnet is not maintained by the data verification smart contract, but is maintained as a contract state by the subnetwork deployed on the blockchain mainnet. In the contract account corresponding to the smart contract. Therefore, in the process of executing data verification transactions, the data verification smart contract can read the identity of each node member in the second blockchain subnet from the contract account of the subnet management smart contract in response to the call of any main network node The information is used to determine whether any of the above-mentioned subnetwork nodes is deployed on the node device where any mainnetwork node is located. In yet another embodiment, any main network node has previously judged whether any subnet node is deployed on the node device where it is located, and maintains the judgment result in any main network node. Therefore, when any When a main network node needs to check whether any subnet node in the second blockchain subnet is deployed on the node device where it is located, it only needs to read the judgment result maintained in advance to judge the node device where it is located. Whether any subnetwork nodes are deployed on it.

Step 206, said any main network node determines a target verification result that satisfies the data verification condition from all obtained candidate verification results, so that the first blockchain subnetwork can determine the target verification result according to the target verification result Whether the data exists in the second blockchain subnet.

As mentioned above, each main network node in the blockchain main network needs to perform data verification transactions, and broadcast candidate verification when the subnet node in the second blockchain network is deployed in the node device where it is located. As a result, the same mainnet node may receive multiple candidate verification results broadcast from other mainnet nodes. Among them, for the main network node where the node device is deployed with the subnet node in the second blockchain network, in addition to receiving the candidate verification results of other main network nodes, the candidate verification results generated by itself are also counted in its Among all candidate verification results obtained. For the main network nodes whose node devices are not deployed with subnet nodes in the second blockchain network, since they do not generate corresponding candidate verification results, all candidate verification results obtained are from other main network nodes. Candidate verification results received by the node.

In the embodiment of this specification, each main network node in the blockchain main network will theoretically receive the same number of candidate verification results with the same content (that is, all candidate verification results) after completing the candidate verification result broadcast stage. to form a candidate set. In order for each main network node to select a candidate verification result with the same content from the candidate set obtained by itself, it is necessary to follow a unified selection rule, that is, the aforementioned data of each main network node maintained in the blockchain main network Verify conditions. Therefore, according to the data verification conditions for the second blockchain subnet, each main network node selects candidate verification results with the same content from their respective candidate sets as the above-mentioned target verification results.

In order to ensure that the target verification results with the same content are selected, the data verification conditions may include at least one of the following: among all the candidate verification results, the candidate verification results with the same content exceed the first preset number, and all the candidate verification results Candidate verification results with the same content and exceeding the first preset number are used as target verification results. The candidate verification results with the same content among all the candidate verification results are from the preset main network node, and the candidate verification results with the same content and originating from the preset main network node among all the candidate verification results are taken as the target verification results. All candidate verification results with the same content and originating from subnetwork nodes in the second blockchain subnet exceed the second preset number, and all candidate verification results with the same content and originating from the second blockchain subnetwork Candidate verification results of the subnetwork nodes in and exceeding the second preset number are used as target verification results.

It should be pointed out that when the data verification conditions include at least two of the above, in order to prevent the existence of multiple candidate verification results with different content that all meet the data verification conditions, resulting in inconsistent target verification results selected by each main network node, it is necessary to ensure that the final selection is The target verification result of can satisfy all data verification conditions at the same time. And, although this manual only lists the above three data verification conditions, in fact, the data verification conditions can be expanded arbitrarily to meet the actual needs of users or specific verification scenarios. For example, in the broadcast stage of candidate verification results, if any main network The node generates a candidate verification result when it is determined that any of the subnet nodes is deployed on the node device where it is located, and broadcasts the candidate verification result to other main network nodes in the blockchain main network. If no subnetwork node is deployed on the node device, no candidate verification result is generated, because in this case, as long as a candidate verification result is generated, it means that the target exists on any subnetwork node Therefore, it can be considered that the content of all candidate verification results must be the same, and at this time, the candidate verification condition can be set to at least one of the following: the candidate verification results among all the candidate verification results exceed the first preset number; Candidate verification results among all candidate verification results are from preset main network nodes; among all candidate verification results, candidate verification results from subnet nodes in the second blockchain subnet exceed a second preset number. Alternatively, a time limit condition is added, for example, the candidate verification condition is set as: the candidate verification results among all the candidate verification results determined within a preset time period exceed the first preset number, etc., and this specification does not make any restrictions on this .

In the embodiment of this specification, in order to ensure the credibility of any main network node in determining the target verification result based on data verification conditions, it is necessary to ensure that the candidate verification results received by any main network node from other main network nodes are indeed from the zone Therefore, it is necessary to introduce an identity verification mechanism to ensure the legitimacy of the received candidate verification results (from the main network nodes in the blockchain main network). In an embodiment, the identity verification mechanism may be implemented by way of electronic signature/signature verification. Taking Figure 1 as an example, assuming that subnet0 is the blockchain main network, subnet1 is the first blockchain subnet and subnet2 is the second blockchain subnet, according to the aforementioned logic of generating and broadcasting candidate verification results, broadcast the candidate verification results After the stage is completed, nodeA, as the main network node, will generate a candidate verification result result_A, and will also receive results from nodeB, nodeC and nodeE respectively (these main network nodes are located on the node devices where the second blockchain subnet is deployed). The result_B, result_C and result_E broadcasted by the subnet nodes in . Obviously, for nodeA, it can only ensure that the result_A generated by itself is legal, but it cannot confirm the legitimacy of other candidate verification results received from other main network nodes. Based on this, in the candidate verification result broadcast stage, the any main network node is required to sign the candidate verification result and then broadcast it to the main network other than the any main network node in the blockchain main network. network nodes, so as to ensure that any candidate verification result received by any main network node from other main network nodes contains a corresponding electronic signature. For example, when nodeA receives result_B, result_C and result_E, it will also Electronic signatures sign_B, sign_C and sign_E corresponding to result_B, result_C and result_E are received, wherein sign_B, sign_C and sign_E are respectively obtained by signing result_B, result_C and result_E by nodeB, nodeC and nodeE through their respective node private keys. Therefore, nodeA can verify sign_B, sign_C and sign_E respectively according to the node public keys of nodeB, nodeC and nodeE maintained locally. If the electronic signature verification is successful, it proves that the candidate verification result corresponding to the electronic signature is indeed from its own The declared main network node has legitimacy. In this way, any main network node can first verify the signature of the candidate verification results received from other main network nodes through the above-mentioned identity verification mechanism, and use the successful candidate verification results as all candidate verification results , so that all candidate verification results include: self-generated candidate verification results and candidate verification results received from other main network nodes and successfully verified, so as to ensure that all candidate verification results in the candidate set for selecting target verification results The legitimacy of the results to ultimately ensure the credibility of the selected target verification results.

In the embodiment of this specification, in addition to ensuring that all candidate verification results in the candidate set come from the main network node through the identity verification mechanism, some means can also be used to prevent malicious or faulty main network nodes from repeatedly broadcasting multiple identical or Different candidate validation results. Since the repeatedly sent candidate verification results still meet the legality based on the above-mentioned signature and signature verification technology, they will not be screened out by the identity verification mechanism, but it will obviously destroy the composition of all candidate verification results in the candidate set, and may Ultimately, the verification result of the determined target is not credible. Therefore, it is necessary to establish a deduplication mechanism to prevent untrustworthiness caused by replay failures. For example, after nodeA completes the above identity verification mechanism and determines the legal candidate set, it is necessary to further count the candidate verification results from the same main network node in the candidate set (the number of successful signature verifications using the same node public key), if found If the candidate set contains at least two candidate verification results from the same main network node, it proves that the main network node sent a replay failure. At this time, the candidate verification results from the main network node can be directly removed from the candidate set , or select one of the at least two candidate verification results as the only valid candidate verification result and keep it in the candidate set, and the others are eliminated. In this way, all candidate verification results in the candidate set finally determined through the above-mentioned identity verification mechanism and de-duplication mechanism will have both legality and source exclusivity (referring to a candidate verification result, the candidate set except the candidate Candidate verification results other than the verification result do not originate from the main network node from which the candidate verification result originates), so as to avoid the problem that the final target verification result is not credible due to multiple broadcasts of candidate verification results by malicious or faulty main network nodes .

In an embodiment, the candidate verification result includes a candidate receipt; the method further includes: any main network node setting the target verification result as a transaction receipt corresponding to the data verification transaction. In the embodiment of this specification, the aforementioned candidate verification result is the candidate receipt, and the aforementioned selected target verification result is the transaction receipt corresponding to the data verification transaction. Just as the receipt generated after the execution of the aforementioned transactions that form the blockchain subnet can be passed through the message mechanism, the transaction receipt corresponding to the data verification transaction can also be sent to the first blockchain subnet of the same node device through the event monitoring mechanism. Obtained by the subnetwork nodes in . Therefore, the first block chain subnetwork can obtain the transaction receipt through the following way: the subnetwork nodes in the first block chain subnetwork monitor the transaction receipt generated by the main network node deployed on the node device where it is located. Since each main network node will select a transaction receipt with the same content after executing the data verification transaction, and the node equipment of each subnet node in the first blockchain subnet is also equipped with a main network node, so for Each subnet node in the first block chain subnet can obtain the transaction receipt by monitoring the main network node on the node device where it is located, so that the first block chain subnet obtains the transaction receipt.

In the embodiment of this specification, the main network nodes in the blockchain main network are mainly divided into the following two stages in the process of executing data verification transactions: the first stage occurs when each main network node just receives the data verification transaction When each main network node decides whether to generate candidate verification results and broadcast the candidate verification results, this stage is called the voting stage; the second stage occurs when each main network node receives candidate verification results from other main network nodes Finally, based on the data verification conditions corresponding to the maintained second blockchain network, a candidate verification result that satisfies the data verification conditions is determined from all the candidate verification results obtained by itself as the target verification result, and it is transparently transmitted to the second block chain network. A blockchain subnetwork, this process is called the consensus phase. In one embodiment, the data verification transaction includes a transaction calling the data verification smart contract deployed on the main network of the block chain; the execution of the data verification transaction by any of the main network nodes includes: calling the data verification smart contract A smart contract is used to generate the candidate verification result and determine the target verification result. Therefore, the data verification smart contract deployed on any main network node responds to the contract logic executed by the data verification exchange, including judging whether the node device where it is located is deployed with any subnet node in the second blockchain network, From the local database corresponding to any of the subnetwork nodes, the logic of checking whether the target data exists beyond authority, generating and broadcasting candidate verification results, and at the same time, the contract logic also includes determining a satisfactory data from all the obtained candidate verification results The target verification result of the verification condition, that is, the contract logic involved in the data verification smart contract in the embodiment of this specification includes the necessary processes of both the voting stage and the consensus stage. Or, in another embodiment, the data verification transaction includes a transaction calling the data verification smart contract deployed on the main network of the block chain; the execution of the data verification transaction by any main network node includes: calling the said data verification smart contract to generate said candidate verification results; said any main network node determines a target verification result that satisfies said data verification conditions from all obtained candidate verification results, including: The consensus module deployed on the main network node determines the target verification result. In this embodiment, the contract logic executed by the data verification smart contract in response to the data verification transaction only includes judging whether the node device where it is located is deployed with any sub-network node in the second blockchain network, from any In the local database corresponding to the subnet node, the logic of checking whether the target data exists beyond authority, generating and broadcasting the candidate verification result is the necessary process of the voting stage, and after that, the necessary process of the consensus stage carried out by any main network node is It is completed by the consensus module of the node device where any main network node itself is located. Therefore, the consensus module must maintain the data verification conditions corresponding to the second blockchain subnet, and in the embodiment of this specification, The data verification condition is maintained by the data verification smart contract; and/or, the data verification condition is maintained by other smart contracts. Therefore, the consensus module needs to access the local database corresponding to the main network node to read the data verification conditions corresponding to the second blockchain subnet from the data verification smart contract or other smart contracts. It should be pointed out that the other smart contracts mentioned above include The aforementioned Subnet contract not only records the data verification conditions corresponding to the second blockchain subnet, but also records the data verification conditions corresponding to all other blockchain subnets under the management of the blockchain main network.

In the embodiment of this specification, the first blockchain subnet can verify whether the target data exists on the second blockchain subnet by checking the content contained in the target verification result. In an embodiment, when the any main network node determines that the target data exists on the any sub-network node, it generates the candidate verification result containing the target data; the any main network node When the network node determines that the target data does not exist in the subnet node in the second blockchain subnet deployed on the node device where any main network node is located, generate the candidate that does not contain the target data. verification result; at the same time, the subnet node in the first block chain subnetwork determines that the target data exists in the second block chain subnetwork under the condition that the target data is included in the target verification result; the first block If the target data is not included in the target receipt, the sub-network nodes in the chain subnet determine that the target data does not exist in the second block chain subnet. The following uses an example to describe the embodiment of this specification in detail. Taking Figure 1 as an example, assume that subnet0 is the blockchain main network, subnet1 is the first blockchain subnet and subnet2 is the second blockchain subnet, and nodeA1 in subnet1 Holds a transaction hash, and wants to verify whether the transaction data corresponding to the transaction hash (the target data in this embodiment is the transaction data) is maintained in subnet2, so nodeA1 submits a request to the node device 1 where it is located The consensus module sends out data verification transactions, and carries the network identifier of subnet0 in the data verification transaction to indicate the destination blockchain network to which the transaction is sent, and at the same time carries the network identifier of subnet2 to indicate the target blockchain used to verify the target data Network, and the transaction hash that carries the data description information to indicate the target data that needs to be verified. The consensus module in node device 1 determines that the transaction is sent to subnet2 according to the network identifier of subnet0 in the data verification transaction, and then broadcasts the data verification transaction to each main network node in subnet0 according to the consensus link in subnet0, including nodeA located locally on node device 1, and nodeB-nodeE located on node devices 2-5. After any main network node receives the data verification transaction, based on the network identifier of subent2 carried in the data verification transaction, it first judges whether the node device 1 where it is located has deployed a subnet node belonging to subnet2. For example, if the main network node nodeA belonging to the subnet node nodeA2 in subnet2 is deployed on the node device where it is located, it will further obtain the blockchain account book of subnet2 in the database corresponding to nodeA2, and verify the transaction hash carried in the transaction according to the data. Hope to check whether the transaction corresponding to the transaction hash exists in the blockchain ledger. If it exists, nodeA will take out the transaction and write it into the generated candidate verification result result_A, and broadcast result_A to other main network nodes; For nodeB, assuming that there is no transaction corresponding to the transaction hash in the database corresponding to nodeB2 deployed on node device 2 where nodeB is located, the candidate verification result result_B generated by nodeB will carry empty or invalid data, and result_B Broadcast to other main network nodes; for nodeD, since the node device 4 where nodeD is located is not deployed with subnet nodes belonging to subnet2, nodeD may not generate candidate verification results, and the operations of other main network nodes are similar. I won’t go into details here. Therefore, when all main network nodes complete the generation and broadcast of candidate verification results, the voting phase ends and enters the consensus phase.

After the voting phase ends, any main network node will obtain the same candidate verification results to form the same candidate set. For example, nodeA will receive candidate verification results result_B, result_C and result_E from nodeB, nodeC and nodeE respectively, plus The result_A generated by itself constitutes a candidate set including result_A, result_B, result_C, and result_E. Similarly, other main network nodes such as nodeB~nodeE will also obtain the same candidate set including result_A, result_B, result_C, and result_E. Then, any main network node will determine the target verification result from the candidate set according to the data verification conditions corresponding to the second blockchain subnet maintained by itself. The number exceeds 2", so any main network node needs to compare and check the contents of all candidate verification results in the candidate set. Assume that the contents of result_A, result_C and result_E are the same transaction data, and result_B contains empty data, then according to the above data verification conditions, it is obvious that result_A, result_C and result_E have the same content and the number exceeds 2, so any one of the candidate verification results can be determined as the target verification result. nodeA～nodeE will perform the operation of the above consensus stage to determine the target verification result of the same content, although the specific determination results may appear that nodeA～C determine result_A as the target verification result, nodeD～E determine result_C as the target verification result, etc. Similar situation, but because the content of result_A, result_C and result_E is the same, but the source is different (the source information is not reflected in the candidate verification result), it will not affect each main network node will finally determine the target verification result with the same content. a fundamental goal. Then, any main network node will reveal the confirmed target verification result. For example, nodeA will reveal the target verification result containing transaction data on node device 1, so that the subnet1 that is also deployed on node device 1 Subnet node nodeA1 obtains the target verification result, and nodeA1 determines that the transaction corresponding to the transaction hash it holds does exist in subnet2 when checking that the target verification result contains the transaction data corresponding to the transaction hash, and finally Satisfy the verification requirements of nodeA1 as the demander of the data verification service for the corresponding data, and at the same time, nodeA1 also obtains the transaction data corresponding to the transaction hash held by it. In the same way, other main network nodes will also perform similar operations to reveal the target verification results on their respective node devices, so that each subnet node in subnet1 can obtain the target verification results and verify the results according to the target If the transaction data is contained in , it is determined that the transaction data does exist in subnet2.

In another embodiment, the data verification transaction sent by the first block chain subnet includes the target data; any of the main network nodes compares the data on any of the subnet nodes with the target data Compare, and generate the candidate verification result containing the comparison result; meanwhile, the subnetwork nodes in the first block chain subnet determine that the comparison result contained in the target verification result is consistent with the comparison Next, it is determined that the target data exists in the second block chain subnet; when the subnet node in the first block chain subnet determines that the comparison result contained in the target verification result is inconsistent with the comparison, It is determined that the target data does not exist in the second blockchain subnet. Still taking Figure 1 as an example, assuming that subnet0 is the blockchain main network, subnet1 is the first blockchain subnet and subnet2 is the second blockchain subnet, nodeA1 in subnet1 holds a contract state and the data corresponding to the contract state ID and the contract address of the contract where the contract state is located, and wants to verify whether the contract state held by it (the target data in this embodiment is the contract state) is maintained in subnet2, so nodeA1 sends the node device 1 where it is located The consensus module in the data verification transaction sends out the data verification transaction, and carries the network identification of subnet0 in the data verification transaction to indicate the destination blockchain network to which the transaction is sent, and carries the network identification of subnet2 to indicate the target block used to verify the target data Chain network, and carry the contract address and data identifier as data description information to indicate the target data that needs to be verified. The consensus module in node device 1 determines that the transaction is sent to subnet2 according to the network identifier of subnet0 in the data verification transaction, and then broadcasts the data verification transaction to each main network node in subnet0 according to the consensus link in subnet0, including nodeA located locally on node device 1, and nodeB-nodeE located on node devices 2-5. After any main network node receives the data verification transaction, based on the network identifier of subent2 carried in the data verification transaction, it first judges whether the node device 1 where it is located has deployed a subnet node belonging to subnet2. For example, if the main network node nodeA belonging to the subnet node nodeA2 in subnet2 is deployed on the node device where it is located, it will further obtain the contract storage space corresponding to the contract address carried in the data verification transaction from the database corresponding to nodeA2, and according to the data The data identifier carried in the verification transaction is checked in the contract storage space to see if the contract state corresponding to the data identifier exists, and if the contract state exists, it is taken out and compared with the contract state carried in the data verification transaction, assuming If the comparison result is consistent, then nodeA writes the result of the consistent comparison into the generated candidate verification result result_A, and broadcasts result_A to other main network nodes; for nodeB, it is assumed that nodeB is located in node device 2 The contract status corresponding to the data identifier can be searched in the database corresponding to nodeB2 deployed on the network, but the contract status retrieved from the database is inconsistent with the contract status carried in the data verification transaction, then the candidate verification result result_B generated by nodeB will be Write the comparison results that are inconsistent, and broadcast result_B to other main network nodes; for nodeD, since the node device 4 where nodeD is located is not deployed with subnet nodes belonging to subnet2, nodeD can not To generate candidate verification results, the operations of other main network nodes are similar and will not be repeated here. Therefore, when all main network nodes complete the generation and broadcast of candidate verification results, the voting phase ends and enters the consensus phase.

After the voting phase ends, any main network node will obtain the same candidate verification results to form the same candidate set. For example, nodeA will receive candidate verification results result_B, result_C and result_E from nodeB, nodeC and nodeE respectively, plus The result_A generated by itself forms a candidate set including result_A, result_B, result_C, and result_E. Similarly, other main network nodes such as nodeB~nodeE will also obtain the same candidate set including result_A, result_B, result_C, and result_E. Then, any main network node will determine the target verification result from the candidate set according to the data verification condition corresponding to the second blockchain subnet maintained by itself, assuming that the data verification condition is "the source of the candidate verification result with the same content in all candidate verification results nodeA and nodeB", so any main network node needs to compare and check the content of all candidate verification results in the candidate set, assuming that the contents of result_A, result_C and result_E are all consistent comparison results (like " yes"), and result_B contains inconsistent comparison results (such as "no"), then according to the above data verification conditions, it is obvious that the contents of result_A and result_B from nodeA and nodeB are different, so in the candidate set There is no candidate verification result that satisfies the above data verification conditions, so the target verification result cannot be determined. In this case, the candidate verification result with the comparison result that is inconsistent can be used as the target verification result, that is, result_B is determined as the target Verification result; or, it is also possible to be indeterminate and not reveal the target verification result. At this time, subnet1 will consider that the contract state does not exist in subnet2 because of the waiting timeout. NodeA～nodeE will perform the operation of the above consensus stage to determine the target verification result of the same content, or they will not be sure of the target verification result. Then, when nodeA～nodeE determine the same target verification result result_B, any main network node will reveal the confirmed target verification result result_B, for example, nodeA will send the target verification result containing transaction data to the node device 1, so that the subnet node nodeA1 belonging to subnet1 that is also deployed on node device 1 obtains the target verification result, and nodeA1 confirms that the target verification result contains an inconsistent comparison result. The contract status held by itself does not exist in subnet2, so as to finally meet the verification requirements of nodeA1 as the demander of the data verification service for the corresponding data. The target verification result is revealed on the device, but since the target verification result does not carry the contract status as the target data, in the case that other main network nodes do not hold the contract status themselves, the subnet nodes in subnet1 except nodeA It will be impossible to know what target data does not exist in subnet2 through the "no" in the target verification result, which has the effect of privacy protection.

Fig. 3 is a flowchart of a method for verifying blockchain data provided by an exemplary embodiment. The method is applied to the main network nodes in the blockchain main network. In the blockchain system composed of the blockchain main network and the blockchain subnet, the subnet nodes in the blockchain subnet are located The main network nodes in the blockchain main network are deployed on the node device, and the blockchain subnet includes at least the first blockchain subnet and the second blockchain subnet, and the main network nodes in the blockchain main network The network node maintains data verification conditions corresponding to the second block chain subnet; the method includes: step 302, receiving a data verification transaction initiated by the first block chain subnet to the block chain main network, and the data verification transaction is used for Verify whether the target data exists on the second block chain subnet; step 304, execute the data verification transaction, so that when any subnet node in the second block chain subnet is deployed on the node device where it is located Generate candidate verification results, and broadcast the candidate verification results to other main network nodes in the blockchain main network, wherein the candidate verification results are used to indicate whether the Target data; step 306, determine a target verification result that satisfies the data verification condition from all obtained candidate verification results, so that the first block chain subnet can determine whether the target data exists in the Second blockchain subnet.

As mentioned above, the data verification conditions include at least one of the following: the candidate verification results with the same content among all the candidate verification results exceed the first preset number; the candidate verification results with the same content among all the candidate verification results Originated from a preset main network node; the content of all candidate verification results is the same and the candidate verification results originating from subnet nodes in the second blockchain subnet exceed a second preset number.

As mentioned above, the candidate verification result includes a candidate receipt; the method further includes: setting the target verification result as a transaction receipt corresponding to the data verification transaction.

As mentioned above, the first block chain subnet obtains the transaction receipt through the following method: the subnet nodes in the first block chain subnet listen to the transaction receipt generated by the main network node deployed on the node device where it is located.

As mentioned above, the data verification transaction includes the data description information of the target data and the network identifier of the second blockchain subnet; wherein, the network identifier is used to instruct the main network node to: put itself on the node device The deployed sub-network node corresponding to the network identifier is determined as the any sub-network node; the data description information is used to instruct the main network node: match any sub-network node with the data Data describing information is determined as the target data.

As mentioned above, the broadcasting of the candidate verification results to other main network nodes in the blockchain main network includes: broadcasting the candidate verification results to the blockchain main network after signing A main network node other than any main network node; wherein, all candidate verification results include: candidate verification results generated by itself and candidate verification results received from other main network nodes and successfully verified.

As mentioned above, the generating the candidate verification result includes: when it is determined that the target data exists on the any subnetwork node, generating the candidate verification result containing the target data, so that the first A subnetwork node in a block chain subnet determines that the target data exists in a second block chain subnet when the target verification result includes the target data.

As mentioned above, the data verification transaction includes the target data; the generation of the candidate verification results includes: comparing the data on any subnetwork node with the target data, and generating a comparison The candidate verification result of the result, so that the subnet node in the first block chain subnet determines the target data when the comparison result contained in the target verification result is determined to be consistent. Exists on the second blockchain subnet.

As mentioned above, it also includes: responding to and executing a subnet creation transaction for creating a new blockchain subnet, obtaining and maintaining the data verification conditions corresponding to the new blockchain subnet, and the subnet creation transaction includes the new zone The data verification conditions corresponding to the block chain subnet.

As mentioned above, it also includes: responding to and executing a condition change transaction for updating the data verification conditions corresponding to the second blockchain subnet, updating the data verification conditions maintained by itself to new data verification conditions, the The condition modification transaction includes the new data verification condition corresponding to the second blockchain subnet.

As mentioned above, the data verification transaction includes the transaction of calling the data verification smart contract deployed on the main network of the block chain; the execution of the data verification transaction includes: calling the data verification smart contract to generate the The candidate verification result is determined and the target verification result is determined.

As mentioned above, the data verification transaction includes the transaction of calling the data verification smart contract deployed on the main network of the block chain; the execution of the data verification transaction includes: calling the data verification smart contract to generate the The candidate verification result; the determining a target verification result that satisfies the data verification condition from all the obtained candidate verification results includes: determining the target verification result through a locally deployed consensus module.

As mentioned above, the data verification condition is maintained by the data verification smart contract; and/or, the data verification condition is maintained by other smart contracts.

As mentioned above, the target data includes one of the following: transaction data, status data, and receipt data.

Fig. 4 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 4 , at the hardware level, the device includes a processor 402 , an internal bus 404 , a network interface 406 , a memory 408 and a non-volatile memory 410 , and of course may include hardware required by other services. One or more embodiments of this specification may be implemented based on software, for example, the processor 402 reads a corresponding computer program from the non-volatile memory 410 into the memory 408 and executes it. Of course, in addition to software implementations, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each A logic unit, which can also be a hardware or logic device.

As shown in Figure 5, Figure 5 is a block diagram of a device for verifying blockchain data provided in this specification according to an exemplary embodiment, and the device can be applied to the device shown in Figure 4 to realize the Technical solutions. The device is applied to the main network nodes in the blockchain main network. In the blockchain system composed of the blockchain main network and the blockchain subnet, the subnet nodes in the blockchain subnet are located The main network nodes in the blockchain main network are deployed on the node device, and the blockchain subnet includes at least the first blockchain subnet and the second blockchain subnet, and the main network nodes in the blockchain main network The network node maintains the data verification conditions corresponding to the second block chain subnet; the device includes: a transaction receiving module 501, which is used to receive the data verification transaction initiated by the first block chain subnet to the block chain main network, and the data The verification transaction is used to verify whether the target data exists on the second block chain subnet; the transaction execution module 502 is used to execute the data verification transaction to deploy the second block chain subnet on the node device where it is located. In the case of any subnet node, a candidate verification result is generated, and the candidate verification result is broadcast to other main network nodes in the blockchain main network, wherein the candidate verification result is used to indicate that any Whether the target data exists on the subnetwork node; the condition verification module 503 is used to determine a target verification result that satisfies the data verification condition from all the obtained candidate verification results, so that the first block chain subnet can use The target verification result determines whether the target data exists in the second block chain subnetwork.

As mentioned above, the candidate verification result includes a candidate receipt; the device further includes: a receipt setting module 504, configured to set the target verification result as a transaction receipt corresponding to the data verification transaction.

As mentioned above, the transaction execution module 502 is specifically configured to: broadcast the candidate verification result to the main network nodes in the blockchain main network except any main network node after signing; wherein, All the candidate verification results include: candidate verification results generated by itself and candidate verification results received from other main network nodes and successfully verified.

As mentioned above, the transaction execution module 502 is specifically configured to: generate the candidate verification result containing the target data when it is determined that the target data exists on any of the subnetwork nodes, so that the first A subnetwork node in a block chain subnet determines that the target data exists in a second block chain subnet when the target verification result includes the target data.

As mentioned above, the data verification transaction includes the target data; the transaction execution module 502 is specifically configured to: compare the data on any subnetwork node with the target data, and generate an inclusion ratio The candidate verification result of the result, so that the subnet node in the first block chain subnet determines the target data when the comparison result contained in the target verification result is determined to be consistent. Exists on the second blockchain subnet.

As mentioned above, it also includes: a subnet creation transaction execution module 505, which is used to respond to and execute a subnet creation transaction for creating a new blockchain subnet, acquire and maintain the data verification conditions corresponding to the new blockchain subnet, and The subnet creation transaction includes the data verification conditions corresponding to the new blockchain subnet.

As mentioned above, it also includes: a condition change transaction execution module 506, which is used to respond to and execute a condition change transaction for updating the data verification conditions corresponding to the second blockchain subnet, and convert the data verification conditions maintained by itself to The new data verification condition is updated, and the condition modification transaction includes the new data verification condition corresponding to the second block chain subnet.

As mentioned above, the data verification transaction includes the transaction of calling the data verification smart contract deployed on the main network of the block chain; the transaction execution module 502 is specifically used to: call the data verification smart contract to generate the Candidate verification results and determine the target verification result.

As mentioned above, the data verification transaction includes the transaction of calling the data verification smart contract deployed on the main network of the block chain; the transaction execution module 502 is specifically used to: call the data verification smart contract to generate the a candidate verification result; and, through a locally deployed consensus module, determine the target verification result.

Correspondingly, this specification also provides a device, the device includes a processor; a memory for storing processor-executable instructions; wherein, the processor is configured to implement the implementation verification area provided by all the above method embodiments The steps of the method of blockchain data.

Correspondingly, this specification also provides a computer-readable storage medium on which executable instructions are stored; wherein, when the instructions are executed by the processor, the methods for verifying blockchain data provided by all the above method embodiments are implemented. A step of.

As shown in Figure 6, Figure 6 is an architecture diagram of a system for verifying blockchain data provided by this specification according to an exemplary embodiment. It can be intuitively shown from the figure that the first blockchain subnet 610 Any deployed subnetwork node is in the same node device as a certain mainnet node in the blockchain mainnet 600 . The block chain system includes a block chain subnet and a block chain main network 600, wherein, the node device where the subnet node in the block chain subnet is located is deployed with the block chain main network 600. network nodes, the block chain subnet includes at least a first block chain subnet 610 and a second block chain subnet, and the main network nodes in the block chain main network 600 maintain data corresponding to the second block chain subnet Verification conditions; the system includes: a first block chain subnet 610, which is used to initiate a data verification transaction to the block chain main network 600, and the data verification transaction is used to verify whether there is target data on the second block chain subnet Block chain main network 600, any main network node in the block chain main network 600 executes the data verification transaction, so that the second block is deployed on the node device where any main network node is located In the case of any subnet node in the chain subnet, a candidate verification result is generated, and the candidate verification result is broadcast to other main network nodes in the blockchain main network 600, wherein the candidate verification result is used for Indicate whether the target data exists on any of the subnet nodes; any of the main network nodes determines a target verification result that satisfies the data verification conditions from all obtained candidate verification results, and the first district The block chain subnet 610 determines whether the target data exists in the second block chain subnet according to the target verification result.

As mentioned above, the candidate verification results include candidate receipts; the block chain main network 600 is also used to: enable any of the main network nodes to set the target verification result as the transaction corresponding to the data verification transaction Receipt.

As mentioned above, the first block chain subnet 610 obtains the transaction receipt through the following method: make the subnet nodes in the first block chain subnet 610 listen to the transaction receipt generated by the main network node deployed on the node device where it is located. transaction receipt.

As mentioned above, the data verification transaction includes the data description information of the target data and the network identification of the second blockchain subnet; wherein, the network identification is used to indicate that any main network node: The subnetwork node deployed on the device corresponding to the network identifier is determined as any subnetwork node; the data description information is used to indicate any main network node: match any subnetwork node The data based on the data description information is determined as the target data.

As mentioned above, the blockchain main network 600 is specifically used to: enable any of the main network nodes to sign the candidate verification result and broadcast it to the blockchain main network 600 A main network node other than the main network node; wherein, all the candidate verification results include: candidate verification results generated by itself and candidate verification results received from other main network nodes and successfully verified.

As mentioned above, the block chain main network 600 is specifically used to: make any of the main network nodes determine that the target data exists on any of the sub-network nodes, generate a block containing the target data the candidate verification result; the first blockchain subnetwork 610 is also used to: make the subnetwork nodes in the first blockchain subnetwork 610 determine that the target data is included in the target verification result The target data exists in the second blockchain subnet.

As mentioned above, the data verification transaction includes the target data; the block chain main network 600 is specifically used to: enable the any main network node to combine the data on the any sub-network node with the The target data is compared, and the candidate verification result containing the comparison result is generated; the first block chain subnetwork 610 is also used to: make the subnetwork nodes in the first block chain subnetwork 610 determine the target If the comparison result included in the verification result is consistent, it is determined that the target data exists in the second blockchain subnetwork.

As mentioned above, the block chain main network 600 is also used to: respond to the subnet creation transaction for creating a new block chain subnet, so that the main network nodes in the block chain main network 600 execute the Obtain and maintain the data verification conditions corresponding to the new blockchain subnet after the subnet creation transaction, and the subnet creation transaction includes the data verification conditions corresponding to the new blockchain subnet.

As mentioned above, the block chain main network 600 is also used for: changing the transaction in response to the conditions for updating the data verification conditions corresponding to the second block chain subnet, so that the block chain main network 600 After executing the condition change transaction, the main network node in the node updates the data verification condition maintained by itself to the new data verification condition, and the condition change transaction includes the new data verification corresponding to the second blockchain subnet. condition.

As mentioned above, the data verification transaction includes the transaction of invoking the data verification smart contract deployed on the block chain main network 600; the block chain main network 600 is specifically used to: enable any main network node to call the The data verification smart contract is used to generate the candidate verification result and determine the target verification result.

As mentioned above, the data verification transaction includes the transaction of invoking the data verification smart contract deployed on the block chain main network 600; the block chain main network 600 is specifically used to: enable any main network node to call the The data verification smart contract is used to generate the candidate verification result; and the target verification result is determined through the consensus module deployed on any main network node.

As for the above device or system embodiments, since they basically correspond to the method embodiments, for relevant parts, please refer to part of the description of the method embodiments. The device embodiments described above are only illustrative, and the modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, that is, they may be located in One place, or it can be distributed to multiple network modules. Part or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. It can be understood and implemented by those skilled in the art without creative effort.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Combinations of any of these devices.

For the convenience of description, when describing the above devices, functions are divided into various units and described separately. Of course, when implementing this specification, the functions of each unit can be implemented in one or more pieces of software and/or hardware.

Those skilled in the art should understand that the embodiments of the present invention may be provided as methods, systems, or computer program products. Accordingly, the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

The specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The present description may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.

Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

The foregoing describes specific embodiments of this specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

Terms used in one or more embodiments of the present specification are for the purpose of describing specific embodiments only, and are not intended to limit the one or more embodiments of the present specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a", "the", and "the" are also intended to include the plural forms unless the context clearly dictates otherwise. It should also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of this specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "at" or "when" or "in response to a determination."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. should be included in the scope of protection of one or more embodiments of this specification.

Claims

A method for verifying blockchain data, applied to a blockchain system including a blockchain subnet and a blockchain main network, wherein the node device where the subnet node in the blockchain subnet is located is deployed with The main network node in the block chain main network, the block chain subnet includes at least the first block chain subnet and the second block chain subnet, and the main network node in the block chain main network maintains the first The data verification conditions corresponding to the two block chain subnets; the method includes:

The first blockchain subnet initiates a data verification transaction to the blockchain main network, and the data verification transaction is used to verify whether the target data exists on the second blockchain subnet;

Any main network node in the blockchain main network executes the data verification transaction, so that any subnet node in the second blockchain subnet is deployed on the node device where the any main network node is located In the case of , a candidate verification result is generated, and the candidate verification result is broadcast to other main network nodes in the blockchain main network, wherein the candidate verification result is used to indicate whether any subnet node is said target data exists;

The any main network node determines a target verification result that satisfies the data verification condition from all obtained candidate verification results, so that the first blockchain subnet can determine whether the target data exists according to the target verification result on the second blockchain subnet.
The method according to claim 1, the data verification conditions include at least one of the following:

Candidate verification results with the same content among all candidate verification results exceed a first preset number;

The candidate verification results with the same content among all the candidate verification results come from the preset main network node;

Among all the candidate verification results, the candidate verification results with the same content and originating from subnetwork nodes in the second blockchain subnetwork exceed a second preset number.
The method of claim 1, the candidate verification result comprising a candidate receipt; the method further comprising:

The any main network node sets the target verification result as the transaction receipt corresponding to the data verification transaction.
According to the method described in claim 3, the first blockchain subnet obtains the transaction receipt through the following means:

The subnetwork nodes in the first blockchain subnetwork monitor the transaction receipt generated by the mainnet node deployed on the node device where they are located.
The method according to claim 1, the data verification transaction includes the data description information of the target data and the network identification of the second blockchain subnet; wherein,

The network identifier is used to indicate any main network node: determine the subnetwork node corresponding to the network identifier deployed on the node device where it is located as the any subnetwork node;

The data description information is used to instruct the any main network node to determine the data matching the data description information on any sub-network node as the target data.
According to the method according to claim 1, said any main network node broadcasts said candidate verification result to other main network nodes in said block chain main network, comprising:

The any main network node signs the candidate verification result and broadcasts it to the main network nodes in the blockchain main network except the any main network node;

Wherein, all the candidate verification results include: candidate verification results generated by itself and candidate verification results received from other main network nodes and successfully verified.
The method according to claim 1,

The generation of the candidate verification result by any main network node includes: when the any main network node determines that the target data exists on the any sub-network node, generating the candidate validation results;

The method further includes: if the subnetwork node in the first blockchain subnetwork includes the target data in the target verification result, determining that the target data exists in the second blockchain subnetwork.
The method of claim 1, said data verification transaction comprising said target data;

The generation of the candidate verification result by any main network node includes: comparing the data on the any sub-network node with the target data by the any main network node, and generating all the verification results containing the comparison result. Describe candidate validation results;

The method further includes: when the subnetwork node in the first block chain subnetwork determines that the comparison result included in the target verification result is the same as the comparison result, determining that the target data exists in the second area Block chain subnet.
The method according to claim 1, further comprising:

The block chain main network responds to the subnet creation transaction for creating a new block chain subnet, so that the main network nodes in the block chain main network obtain and maintain the The data verification conditions corresponding to the new block chain subnet, the subnet creation transaction includes the data verification conditions corresponding to the new block chain subnet.
The method according to claim 1, further comprising:

The block chain main network responds to the condition change transaction for updating the data verification conditions corresponding to the second block chain subnet, so that the main network nodes in the block chain main network perform the condition change After the transaction, the data verification condition maintained by itself is updated to a new data verification condition, and the condition modification transaction includes the new data verification condition corresponding to the second blockchain subnet.
The method according to claim 1, wherein the data verification transaction includes a transaction calling a data verification smart contract deployed on the main network of the block chain; the execution of the data verification transaction by any of the main network nodes includes:

Invoking the data verification smart contract to generate the candidate verification result and determine the target verification result.
The method according to claim 1, wherein the data verification transaction comprises a transaction invoking a data verification smart contract deployed on the main network of the block chain;

The execution of the data verification transaction by any main network node includes: calling the data verification smart contract to generate the candidate verification result;

The any main network node determines a target verification result that satisfies the data verification condition from all obtained candidate verification results, including: determining the target verification result through the consensus module deployed on any main network node Validation results.
According to the method according to claim 11 or 12, the data verification conditions are maintained by the data verification smart contract; and/or, the data verification conditions are maintained by other smart contracts.
The method according to claim 1, said target data comprises one of the following: transaction data, status data, receipt data.
A block chain system, including a block chain subnet and a block chain main network, wherein the node device where the subnet node in the block chain subnet is located is deployed with the main block chain in the block chain main network network node, the block chain subnet includes at least the first block chain subnet and the second block chain subnet, and the main network node in the block chain main network maintains the data verification conditions corresponding to the second block chain subnet ; the system includes:

The first block chain subnet is used to initiate a data verification transaction to the block chain main network, and the data verification transaction is used to verify whether the target data exists on the second block chain subnet;

Block chain main network, any main network node in the block chain main network executes the data verification transaction, so that the second block chain subnet is deployed on the node device where the any main network node is located In the case of any sub-network node of the blockchain, a candidate verification result is generated, and the candidate verification result is broadcast to other main network nodes in the blockchain main network, wherein the candidate verification result is used to indicate that any Whether the target data exists on a sub-network node; said any main network node determines a target verification result that satisfies the data verification condition from all obtained candidate verification results, so that the first block chain sub-network The target verification result determines whether the target data exists in the second blockchain subnet.
A method for verifying block chain data, applied to the main network nodes in the block chain main network, in the block chain system composed of the block chain main network and the block chain subnet, the block chain subnet The main network node in the block chain main network is deployed on the node device where the subnet node in the block chain is located, and the block chain subnet includes at least the first block chain subnet and the second block chain subnet, the The main network node in the blockchain main network maintains data verification conditions corresponding to the second blockchain subnet; the method includes:

Receive a data verification transaction initiated by the first block chain subnet to the block chain main network, and the data verification transaction is used to verify whether the target data exists on the second block chain subnet;

Execute the data verification transaction to generate a candidate verification result when any subnet node in the second blockchain subnet is deployed on the node device where it is located, and broadcast the candidate verification result to the zone Other main network nodes in the block chain main network, wherein the candidate verification result is used to indicate whether the target data exists on any of the subnet nodes;

Determine a target verification result that satisfies the data verification condition from all obtained candidate verification results, so that the first blockchain subnet can determine whether the target data exists in the second blockchain subnet according to the target verification result .
The method according to claim 16, the data verification condition comprises at least one of the following:

Candidate verification results with the same content among all candidate verification results exceed a first preset number;

The candidate verification results with the same content among all the candidate verification results come from the preset main network node;

Among all the candidate verification results, the candidate verification results with the same content and originating from subnetwork nodes in the second blockchain subnetwork exceed a second preset number.
The method of claim 16, the candidate verification result comprising a candidate receipt; the method further comprising:

The target verification result is set as the transaction receipt corresponding to the data verification transaction.
According to the method described in claim 18, the first blockchain subnet obtains the transaction receipt through the following means:

The subnetwork nodes in the first blockchain subnetwork monitor the transaction receipt generated by the mainnet node deployed on the node device where they are located.
The method according to claim 16, the data verification transaction includes the data description information of the target data and the network identification of the second blockchain subnet; wherein,

The network identifier is used to indicate the main network node: determine the subnetwork node corresponding to the network identifier deployed on the node device where it is located as the any subnetwork node;

The data description information is used to instruct the main network node to determine the data matching the data description information on any sub-network node as the target data.
The method according to claim 16, said broadcasting said candidate verification result to other main network nodes in said blockchain main network, comprising:

Sign the candidate verification result and broadcast it to the main network nodes in the blockchain main network except any main network node;

Wherein, all the candidate verification results include: candidate verification results generated by itself and candidate verification results received from other main network nodes and successfully verified.
The method according to claim 16, said generating the candidate verification result comprises: generating the candidate verification result containing the target data when it is determined that the target data exists on the any subnetwork node , so that the subnetwork nodes in the first blockchain subnetwork determine that the target data exists in the second blockchain subnetwork when the target verification result contains the target data.
The method of claim 16, said data verification transaction comprising said target data;

The generating the candidate verification result includes: comparing the data on the any subnetwork node with the target data, and generating the candidate verification result including the comparison result, so that the first block chain subnet The sub-network nodes in the network determine that the target data exists in the second block chain sub-network when it is determined that the comparison result included in the target verification result is a consistent comparison.
The method of claim 16, further comprising:

Respond to and execute the subnet creation transaction used to create a new blockchain subnet, acquire and maintain the data verification conditions corresponding to the new blockchain subnet, and the subnet creation transaction includes the data verification conditions corresponding to the new blockchain subnet .
The method of claim 16, further comprising:

Responding to and executing a condition change transaction for updating the data verification condition corresponding to the second blockchain subnet, updating the data verification condition maintained by itself to a new data verification condition, the condition change transaction includes the second zone The new data verification conditions corresponding to the block chain subnet.
The method according to claim 16, wherein the data verification transaction includes a transaction calling a data verification smart contract deployed on the main network of the block chain; the execution of the data verification transaction includes:

Invoking the data verification smart contract to generate the candidate verification result and determine the target verification result.
The method according to claim 16, wherein the data verification transaction comprises a transaction invoking a data verification smart contract deployed on the main network of the block chain;

The execution of the data verification transaction includes: calling the data verification smart contract to generate the candidate verification result;

The determining a target verification result satisfying the data verification condition from all obtained candidate verification results includes: determining the target verification result through a locally deployed consensus module.
The method according to claim 26 or 27, the data verification condition is maintained by the data verification smart contract; and/or, the data verification condition is maintained by other smart contracts.
The method of claim 16, said target data comprising one of: transaction data, status data, receipt data.
A device for verifying block chain data, applied to the main network nodes in the block chain main network, in the block chain system composed of the block chain main network and the block chain subnet, the block chain subnet The main network node in the block chain main network is deployed on the node device where the subnet node in the block chain is located, and the block chain subnet includes at least the first block chain subnet and the second block chain subnet, the The main network node in the blockchain main network maintains data verification conditions corresponding to the second blockchain subnet; the device includes:

The transaction receiving module is used to receive the data verification transaction initiated by the first block chain subnet to the block chain main network, and the data verification transaction is used to verify whether the target data exists on the second block chain subnet;

The transaction execution module is used to execute the data verification transaction, so as to generate a candidate verification result when any subnet node in the second blockchain subnet is deployed on the node device where it is located, and send the candidate verification result to The result is broadcast to other main network nodes in the blockchain main network, wherein the candidate verification result is used to indicate whether the target data exists on any subnet node;

A condition verification module, configured to determine a target verification result that satisfies the data verification condition from all obtained candidate verification results, so that the first block chain subnet can determine whether the target data exists in the Second blockchain subnet.
A computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method according to any one of claims 16-29 are implemented.
An electronic device comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to any one of claims 1-14 or 16-29 by running the executable instructions.