WO2023050966A1 - Vérification de données de chaîne de blocs - Google Patents

Vérification de données de chaîne de blocs Download PDF

Info

Publication number
WO2023050966A1
WO2023050966A1 PCT/CN2022/104372 CN2022104372W WO2023050966A1 WO 2023050966 A1 WO2023050966 A1 WO 2023050966A1 CN 2022104372 W CN2022104372 W CN 2022104372W WO 2023050966 A1 WO2023050966 A1 WO 2023050966A1
Authority
WO
WIPO (PCT)
Prior art keywords
subnet
data
main network
blockchain
verification
Prior art date
Application number
PCT/CN2022/104372
Other languages
English (en)
Chinese (zh)
Inventor
卓海振
Original Assignee
支付宝(杭州)信息技术有限公司
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司, 蚂蚁区块链科技(上海)有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2023050966A1 publication Critical patent/WO2023050966A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database

Definitions

  • 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.
  • 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.
  • 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.
  • one or more embodiments of this specification provide a method, device, electronic device and storage medium for verifying blockchain data.
  • 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
  • another method for verifying blockchain data is proposed, which is applied to the main network nodes in the blockchain main network.
  • 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 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
  • 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
  • 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
  • a blockchain system 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,
  • the subnet nodes in the blockchain subnet are located
  • 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.
  • 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.
  • 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.
  • the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification.
  • the method may include more or less steps than those described in this specification.
  • 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.
  • all blockchain nodes in the blockchain network will maintain the same block data, which cannot meet the special needs of some nodes.
  • all consortium members that is, node members in the consortium
  • all consortium members 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • the block chain main network is subnet0, and the subnet0 includes
  • the blockchain nodes are nodeA, nodeB, nodeC, nodeD, nodeE, etc.
  • 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.
  • the blockchain node that initiates the transaction to form a blockchain subnet does not necessarily participate in the established blockchain subnet.
  • 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.
  • 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.
  • the blockchain main network in this specification can also be a subnet of other blockchain networks.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the node members of the blockchain subnet are not necessarily only part of the node members of the blockchain main network.
  • the node members of the blockchain subnet can be completely consistent with the node members of the blockchain main network.
  • 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.
  • the two types of The business data generated by the business are isolated from each other.
  • 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.
  • 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.
  • the invoked contract can be the aforementioned genesis contract or system contract
  • the invoked method can be a method for building a blockchain subnet
  • the incoming parameters can include the above-mentioned configuration information.
  • the transaction may contain the following information:
  • the from field is the information of the initiator of the transaction.
  • Administrator indicates that the initiator is an administrator; the to field is the address of the called smart contract.
  • 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.
  • 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.
  • genesis is used to represent the The value of the parameter, the genesis is specifically the aforementioned configuration information.
  • nodeA ⁇ nodeE 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.
  • the content of the topic is the keyword subnet, and this keyword is different from the topic in the event generated by other methods.
  • 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.
  • the event in the receipt is as follows:
  • the content of the data field may include, for example:
  • 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.
  • 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.
  • a predefined new network identifier which indicates that the corresponding networking event is used to form a new blockchain subnet.
  • the above subnet1 can be replaced with newsubnet, which is a predefined new network identifier.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • nodeA and node device 1 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.
  • identity information such as nodeA's public key, IP address, and port number
  • the blockchain nodes in the blockchain main network can monitor receipts and trigger node devices to perform related processing according to the monitoring results.
  • 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.
  • 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.
  • 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.
  • 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 .
  • the data field may contain identity information generated in advance for nodeA1-nodeD1, which is different from the identity information of nodeA-nodeD.
  • 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.
  • the execution result of the contract can include the genesis block.
  • 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.
  • 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.
  • 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.
  • the node device creates the first instance in the above process, and the first instance runs the blockchain platform code to form.
  • 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.
  • 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.
  • the second instance may also be in separate nodes from the first instance
  • 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.
  • 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.
  • a blockchain subnet can be created on the blockchain mainnet.
  • subnet0 originally included nodeA ⁇ nodeE
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the data verification conditions maintained on the blockchain main network can be created or changed by sending transactions to the blockchain main network.
  • 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.
  • the above-mentioned subnet creation transaction for creating a new blockchain subnet is the aforementioned transaction for establishing a blockchain subnet.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the target data includes one of the following: transaction data, status data, and receipt data.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • the data description information may include transaction hash, account ID, contract address, parameter name and so on.
  • any main network node 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.
  • 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.
  • any mainnetwork node 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.
  • 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.
  • 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.
  • 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.
  • the existence of a candidate verification result can be used to indicate that the target data exists on any subnetwork node.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the same mainnet node may receive multiple candidate verification results broadcast from other mainnet nodes.
  • the candidate verification results generated by itself are also counted in its Among all candidate verification results obtained.
  • all candidate verification results obtained are from other main network nodes.
  • 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.
  • a candidate verification result with the same content from the candidate set obtained by itself. 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • the identity verification mechanism may be implemented by way of electronic signature/signature verification.
  • subnet0 is the blockchain main network
  • subnet1 is the first blockchain subnet
  • subnet2 is the second blockchain subnet
  • nodeA as the main network node
  • nodeB will generate a candidate verification result result_A
  • nodeC 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 .
  • 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.
  • 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.
  • nodeA 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the aforementioned candidate verification result is the candidate receipt
  • the aforementioned selected target verification result is the transaction receipt corresponding to the data verification transaction.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • subnet0 is the blockchain main network
  • subnet1 is the first blockchain subnet and subnet2 is the second blockchain subnet
  • 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.
  • 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.
  • 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;
  • 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.
  • any main network node will obtain the same candidate verification results to form the same candidate set.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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_
  • any main network node will obtain the same candidate verification results to form the same candidate set.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second blockchain subnet Exists on the second blockchain subnet.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second blockchain subnet Exists on the second blockchain subnet.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 target data includes one of the following: transaction data, status data, and receipt data.
  • 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.
  • 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.
  • 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.
  • the block chain subnet includes at least a first block chain subnet 610 and a second block chain subnet
  • 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
  • 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,
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 target data includes one of the following: transaction data, status data, and receipt data.
  • 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.
  • a typical implementing device is a computer.
  • 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.
  • 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.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • 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.
  • 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.
  • 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.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • 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.
  • computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.
  • 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.”

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

La présente description concerne un procédé et un appareil de vérification de données de chaîne de blocs, ainsi qu'un dispositif électronique et un support de stockage. Le procédé est appliqué à un système de chaîne de blocs qui comprend un sous-réseau de chaîne de blocs et un réseau principal de chaîne de blocs. Le procédé comprend les étapes dans lesquelles : un premier sous-réseau de chaîne de blocs initie une transaction de vérification de données sur un réseau principal de chaîne de blocs, la transaction de vérification de données étant utilisée pour vérifier si des données cibles sont présentes sur un second sous-réseau de chaîne de blocs ; un nœud quelconque de réseau principal dans le réseau principal de chaîne de blocs exécute la transaction de vérification de données, de façon à générer un résultat de vérification candidat lorsqu'un nœud quelconque de sous-réseau dans le second sous-réseau de chaîne de blocs est déployé sur un dispositif de nœud dans lequel se trouve le nœud de réseau principal, et diffuse le résultat de vérification candidat à d'autres nœuds de réseau principal dans le réseau principal de chaîne de blocs ; et un nœud quelconque de réseau principal détermine, parmi tous les résultats de vérification candidats acquis, un résultat de vérification cible qui satisfait une condition de vérification de données, de telle sorte que le premier sous-réseau de chaîne de blocs détermine, selon le résultat de vérification cible, si les données cibles sont présentes sur le second sous-réseau de chaîne de blocs.
PCT/CN2022/104372 2021-09-30 2022-07-07 Vérification de données de chaîne de blocs WO2023050966A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111160864.6 2021-09-30
CN202111160864.6A CN113886495B (zh) 2021-09-30 2021-09-30 验证区块链数据的方法、装置、电子设备和存储介质

Publications (1)

Publication Number Publication Date
WO2023050966A1 true WO2023050966A1 (fr) 2023-04-06

Family

ID=79004661

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/104372 WO2023050966A1 (fr) 2021-09-30 2022-07-07 Vérification de données de chaîne de blocs

Country Status (2)

Country Link
CN (1) CN113886495B (fr)
WO (1) WO2023050966A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113886495B (zh) * 2021-09-30 2024-05-24 支付宝(杭州)信息技术有限公司 验证区块链数据的方法、装置、电子设备和存储介质
CN117349867B (zh) * 2023-12-04 2024-02-09 成都峰潮信息技术有限公司 智能合约部署方法、系统、设备及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109040198A (zh) * 2018-07-13 2018-12-18 瑞典爱立信有限公司 信息生成和传递系统及方法
CN112685505A (zh) * 2021-01-07 2021-04-20 腾讯科技（深圳）有限公司 一种交易数据处理方法、装置、计算机设备及存储介质
WO2021073755A1 (fr) * 2019-10-18 2021-04-22 DFINITY Stiftung Messagerie dans des réseaux distribués
CN113259460A (zh) * 2021-06-02 2021-08-13 支付宝(杭州)信息技术有限公司 跨链交互方法及装置
CN113886495A (zh) * 2021-09-30 2022-01-04 支付宝(杭州)信息技术有限公司 验证区块链数据的方法、装置、电子设备和存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107301536B (zh) * 2017-06-12 2019-07-12 腾讯科技（深圳）有限公司 资源转移方法及装置
WO2019165330A1 (fr) * 2018-02-24 2019-08-29 Neji, Inc. Système et procédés de preuve d'un élément de réseau
WO2021030524A1 (fr) * 2019-08-15 2021-02-18 Telepathy Labs, Inc. Système et procédé pour interroger de multiples sources de données
JP2023506115A (ja) * 2019-10-18 2023-02-15 デフィニティ スティフトゥング 分散ネットワークの計算結果に対する読み出しアクセス
CN111539726B (zh) * 2020-04-20 2024-03-19 中国工商银行股份有限公司 区块链共识系统及方法
CN113259456B (zh) * 2021-06-02 2021-10-15 支付宝(杭州)信息技术有限公司 跨链交互方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109040198A (zh) * 2018-07-13 2018-12-18 瑞典爱立信有限公司 信息生成和传递系统及方法
WO2021073755A1 (fr) * 2019-10-18 2021-04-22 DFINITY Stiftung Messagerie dans des réseaux distribués
CN112685505A (zh) * 2021-01-07 2021-04-20 腾讯科技（深圳）有限公司 一种交易数据处理方法、装置、计算机设备及存储介质
CN113259460A (zh) * 2021-06-02 2021-08-13 支付宝(杭州)信息技术有限公司 跨链交互方法及装置
CN113886495A (zh) * 2021-09-30 2022-01-04 支付宝(杭州)信息技术有限公司 验证区块链数据的方法、装置、电子设备和存储介质

Also Published As

Publication number Publication date
CN113886495B (zh) 2024-05-24
CN113886495A (zh) 2022-01-04

Similar Documents

Publication Publication Date Title
WO2023050966A1 (fr) Vérification de données de chaîne de blocs
CN113259460B (zh) 跨链交互方法及装置
CN113067904B (zh) 组建区块链子网的方法和区块链系统
CN113259456B (zh) 跨链交互方法及装置
CN113067897B (zh) 跨链交互方法及装置
WO2023050986A1 (fr) Maintenance d'informations d'architecture de réseau de système de chaîne de blocs
CN113259453B (zh) 跨链交互方法及装置
WO2023124746A1 (fr) Commande d'autorisation d'interaction inter-sous-réseau
WO2024001022A1 (fr) Appel inter-sous-réseau
CN113067895A (zh) 组建区块链子网的方法和区块链系统
CN113259117B (zh) 同步节点信息列表的方法
CN113259120B (zh) 同步节点信息列表的方法
CN113259118B (zh) 同步节点信息列表的方法
CN113259461B (zh) 跨链交互方法和区块链系统
CN114363162A (zh) 区块链日志的生成方法及装置、电子设备、存储介质
CN113326290B (zh) 跨网查询控制方法
CN113259454B (zh) 跨链交互方法及装置
CN113067896B (zh) 区块链子网中加入节点的方法和区块链系统
CN113259464B (zh) 组建区块链子网的方法和区块链系统
CN114374699A (zh) 跨链交互方法和跨链交互的审计方法
WO2023207076A1 (fr) Procédé et appareil pour établir un sous-réseau de chaîne de blocs
CN113259463B (zh) 跨链交互方法和区块链系统
CN113067838B (zh) 跨链交互方法及装置
CN113259237B (zh) 区块链网络间的交易转发方法
CN116743765A (zh) 区块链系统、跨链交互方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22874363

Country of ref document: EP

Kind code of ref document: A1