CN114095507B

CN114095507B - Cross-chain interaction method and block chain system

Info

Publication number: CN114095507B
Application number: CN202111592802.2A
Authority: CN
Inventors: 陶友贤; 王江; 邓福喜
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-06-02
Filing date: 2021-06-02
Publication date: 2024-04-02
Anticipated expiration: 2041-06-02
Also published as: CN113259463B; CN113259463A; CN114095507A

Abstract

One or more embodiments of the present specification provide a cross-chain interaction method and a blockchain system; the method may include: source block chain link points in the source block chain network respectively initiate a cross-chain request to a plurality of target block chain nodes in the target block chain network; the target block chain nodes respectively respond to the cross-chain request, generate response results aiming at the cross-chain request, and return the generated response results to the source block chain link points; and the source block chain link points respectively receive response results returned by the target block chain nodes, and perform Bayesian fault-tolerant verification on the received response results according to the node numbers of the target block chain nodes, so that the response results passing the Bayesian fault-tolerant verification are used as response results of the target block chain network for the cross-chain request.

Description

Cross-chain interaction method and block chain system

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technology, and in particular, to a cross-chain interaction method and a blockchain system.

Background

Blockchain technology builds on top of transport networks (e.g., point-to-point networks). Nodes in the blockchain network verify and store data using a chained data structure and employ a distributed node consensus algorithm to generate and update the data. Different blockchain networks may be built to document different types of traffic data. In this scenario, there is a need for interactions between different blockchain networks, thus implementing some complex services through cross-chain interactions.

Disclosure of Invention

In view of this, one or more embodiments of the present description provide a cross-chain interaction method and blockchain system.

In order to achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, a cross-chain interaction method is provided, including:

source block chain link points in the source block chain network respectively initiate a cross-chain request to a plurality of target block chain nodes in the target block chain network;

the target block chain nodes respectively respond to the cross-chain request, generate response results aiming at the cross-chain request, and return the generated response results to the source block chain link points;

and the source block chain link points respectively receive response results returned by the target block chain nodes, and perform Bayesian fault-tolerant verification on the received response results according to the node numbers of the target block chain nodes, so that the response results passing the Bayesian fault-tolerant verification are used as response results of the target block chain network for the cross-chain request.

According to a second aspect of one or more embodiments of the present specification, there is provided a blockchain system, comprising:

A source blockchain network, source blockchain link points in the source blockchain network being used to initiate a cross-chain request to a plurality of destination blockchain nodes in the destination blockchain network, respectively; and respectively receiving response results returned by the target blockchain nodes for the cross-chain request, and carrying out Bayesian fault-tolerant verification on the received response results according to the node numbers of the target blockchain nodes so as to take the response results passing the Bayesian fault-tolerant verification as the response results of the target blockchain network for the cross-chain request.

The target block chain network is used for responding to the cross-chain request respectively, generating a response result aiming at the cross-chain request and returning the generated response result to the source block chain point.

Drawings

FIG. 1 is a schematic diagram of creating a smart contract provided by an exemplary embodiment.

FIG. 2 is a schematic diagram of a call to a smart contract provided by an exemplary embodiment.

FIG. 3 is a schematic diagram of creating and invoking a smart contract provided by an exemplary embodiment.

FIG. 4 is a flowchart of a cross-chain interaction method provided by an exemplary embodiment.

Fig. 5 is a schematic diagram of a blockchain subnetwork based on a blockchain subnetwork, according to an exemplary embodiment.

FIG. 6 is a schematic diagram of a blockchain network registered as a blockchain subnet provided by an exemplary embodiment.

Fig. 7 is a schematic diagram of a structure of a cross-subnet request according to an exemplary embodiment.

Fig. 8 is a schematic diagram of a blockchain system in accordance with an exemplary embodiment.

Detailed Description

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

It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there are many types of combinations, such as different combinations of private chain+federation chain, federation chain+public chain, and the like. Among them, the highest degree of decentralization is the public chain. Participants joining the public chain may read data records on the chain, participate in transactions, compete for billing rights for new blocks, and so forth. Moreover, each participant (i.e., node) is free to join and leave the network and perform related operations. The private chain is the opposite, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. In short, the private chain may be a weakly centralized system with few and strict restrictions on participating nodes. This type of blockchain is more suitable for use within a particular organization. The alliance chain is a block chain between public and private chains, and can realize 'partial decentralization'. Each node in the federation chain typically has an entity organization or organization corresponding thereto; participants join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation.

Whether public, private, or federation, it is possible to provide the functionality of a smart contract. Intelligent contracts on blockchains are contracts on blockchain systems that can be executed by transaction triggers. The smart contracts may be defined in the form of codes. In practice, the virtual machine runs directly on virtual machine code (virtual machine bytecode, hereinafter "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

For example, as shown in fig. 1, bob sends a transaction containing information to create a smart contract to the blockchain network, the EVM of node 1 may execute the transaction and generate the corresponding contract instance. "0x6f8ae93 …" in fig. 1 represents the address of this contract, the data field of the transaction may hold byte code and the to field of the transaction is empty. After agreement is reached between nodes through the consensus mechanism, this contract is successfully created and can be invoked in a subsequent process. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain, and the contract account is stored with a specific address. The behavior of the smart contract is controlled by the contract code. In other words, the smart contract causes a virtual account to be generated on the blockchain that includes a contract code and an account store (Storage).

As shown in fig. 2, bob sends a transaction for invoking a smart contract to the blockchain network, the EVM of a node may execute the transaction and generate the corresponding contract instance. The from field of the transaction in fig. 2 is the address of the account of the transaction initiator (i.e., bob), the "0x6f8ae93 …" in the to field represents the address of the called smart contract, and the data field of the transaction holds the method and parameters for calling the smart contract. The value of the policy may change after invoking the smart contract. Subsequently, a client may view the current value of the policy through a blockchain node (e.g., node 6 in FIG. 2). The intelligent contract is independently executed at each node in the blockchain network in a specified mode, all execution records and data are stored on the blockchain, so that when the transaction is completed, transaction credentials which cannot be tampered and cannot be lost are stored on the blockchain.

A schematic diagram of creating a smart contract and invoking a smart contract is shown in fig. 3. To create an intelligent contract in a blockchain, the intelligent contract needs to be written, compiled into byte codes, deployed to the blockchain and the like. Invoking the intelligent contract in the blockchain initiates a transaction directed to the intelligent contract address, and the intelligent contract code is distributed and operated in a virtual machine of each node in the blockchain network.

It should be noted that, in addition to the smart contracts that can be created by the user, the smart contracts can also be set by the system in the creation block. Such contracts are commonly referred to as an opening contract. In general, some blockchain networks may be configured with data structures, parameters, attributes, and methods in the creating contracts. In addition, an account with system administrator rights may create a system level contract, or modify a system level contract (simply referred to as a system contract). In addition, different blockchain networks may employ various virtual machines in addition to EVM, and are not limited in this regard.

After executing a transaction invoking the smart contract, a node in the blockchain network generates a corresponding receipt (receipt) for recording information related to executing the smart contract. In this way, information about the result of contract execution can be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in a receipt. The messaging mechanism may implement messaging through events in the receipt to trigger the blockchain node to perform the corresponding process. The structure of the event may be, for example:

Event：

[topic][data]

......

in the above examples, the number of events may be one or more; wherein each event includes fields such as a theme (topic) and data (data), respectively. The block link point may perform a preset process by listening to the topic of the event, in case of listening to the predefined topic, or read the related content from the data field of the corresponding event, and may perform the preset process based on the read content.

In the event mechanism described above, the client having the monitoring function is located at the monitoring party (such as the user having the monitoring requirement), for example, the SDK for implementing the monitoring function is running on the client, and the client monitors the event generated by the blockchain node, and the blockchain node only needs to normally generate the receipt. In addition to the event mechanism described above, the transmission of transaction information may be accomplished in other ways. For example, the listening code may be embedded in the blockchain platform code running at the blockchain point such that the listening code may listen to one or more of the transaction content of the blockchain transaction, the contract status of the smart contract, the receipt generated by the contract, etc., and send the monitored data to the predefined listener. Since the snoop code is deployed in the blockchain platform code, rather than at the client of the snooper, such a snoop code-based implementation is relatively more proactive than an event mechanism. The above-mentioned monitoring code may be added into the blockchain platform code by a developer of the blockchain platform in the development process, or may be embedded by a monitoring party based on the own requirement, which is not limited in this specification.

Blockchain technology differs from one of the decentralized features of conventional technology in that accounting is performed on individual nodes, otherwise known as distributed accounting, rather than conventional centralized accounting. The blockchain system is to be a hard-to-break, public, untampered, decentralised, honest and trusted system for data records, and needs to be secure, clear and irreversible for distributed data records in as short a time as possible. In different types of blockchain networks, in order to keep account books consistent among the nodes of each record account book, a consensus algorithm is generally adopted to ensure that the above-mentioned consensus mechanism is adopted. For example, a block granularity consensus mechanism may be implemented between blockchain nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is approved by other nodes, the other nodes record the same block. For another example, a transaction granularity consensus mechanism may be implemented between blockchain nodes, for example, after a node (e.g., a unique node) obtains a blockchain transaction, if the blockchain transaction is approved by other nodes, each node approving the blockchain transaction may respectively add the blockchain transaction to its own maintained latest block, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism that the blockchain node achieves the consensus of the whole network about the blockinformation (or blockdata), and can ensure that the latest block is accurately added to the blockchain. The consensus mechanisms of the current mainstream include: proof of Work (POW), proof of equity (POS), proof of commission (Delegated Proof of Stake, DPOS), practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithm, honeybadgenbft algorithm, etc.

There is a need for interactions between different blockchain networks to implement some complex services through cross-chain interactions. For example, when the blockchain network a executes the service, the blockchain network B needs to use the data maintained by the blockchain network B, then the blockchain network a is used as a source blockchain network, the blockchain network B is used as a destination blockchain network, and the source blockchain network requests the destination blockchain network for obtaining the data to be processed of the service to complete the execution of the related service. The cross-chain interaction process between the source blockchain network and the destination blockchain network is described in detail below in conjunction with fig. 4.

Referring to fig. 4, fig. 4 is a flowchart of a cross-link interaction method according to an exemplary embodiment. As shown in fig. 4, the method may include the steps of:

in step 402, source blockchain link points in a source blockchain network initiate a cross-chain request to a plurality of destination blockchain nodes in a destination blockchain network, respectively.

When the source blockchain network and the destination blockchain network are subjected to cross-chain interaction, a source blockchain node in the source blockchain network can initiate a cross-chain request to a destination blockchain node in the destination blockchain network. In order to ensure reliable transmission of the cross-chain request, a source blockchain node in the source blockchain subnet may send the cross-chain request to a plurality of destination nodes in the destination blockchain network, respectively. For example, a cross-chain request is sent to each destination node or designated destination node in the destination blockchain network to be responded to by the respective destination node. By the method for sending the cross-link request, even if part of the cross-link request is lost in the transmission process, the destination node in the destination block chain network can be guaranteed to receive the cross-link request to respond, so that the source block chain sub-network can be further guaranteed to successfully acquire the response result of the destination block chain network to the cross-link request. Of course, the number of the destination blockchain nodes can be flexibly set according to actual requirements, and the specification is not limited to this.

Step 404, the multiple destination blockchain nodes respectively respond to the cross-chain request, generate response results for the cross-chain request, and return the respective generated response results to the source blockchain node.

Each destination blockchain node that receives the cross-chain request may generate a corresponding response result and return the generated response result to the initiator of the received cross-chain request. For a source blockchain node in the source blockchain network, response results for the cross-chain request returned by the multiple destination blockchain nodes will be received. In this case, there is a case where the destination block link node is bad or fails, for example, the bad destination block chain node returns an erroneous response result, and the failed destination block chain node does not return a response result. For the case of disfigurement, the source subnet node will receive different response results for the same cross-link request, thereby causing inconsistent processing of the returned response results by each source subnet node. For the case of failure, the source subnet node will receive fewer response results than the number of destination blockchain nodes. For the above case, the source blockchain link point is required to screen out the response result therefrom as the response result of the destination blockchain network for the cross-chain request.

Step 406, the source block chain link point receives the response results returned by the plurality of destination block chain nodes, and performs a bayer fault-tolerant check on the received response results according to the node numbers of the plurality of destination block chain nodes, so as to use the response results passing the bayer fault-tolerant check as the response results of the destination block chain network for the cross-chain request.

Aiming at the situation that the link points of the target block are bad and faulty, the Bayesian fault-tolerant verification can be performed on the response results returned by all the target block chain nodes, so that the processing of the response results returned by all the source block chain nodes to the target block chain nodes is ensured to be consistent, namely the consistency of data processing in the cross-chain interaction is ensured.

Further, the cross-chain request may be initiated by at least one source blockchain node in the source blockchain network to a plurality of destination blockchain nodes, respectively. For example, a master node may be selected from a source blockchain network, and then only the master node initiates a cross-chain request to a plurality of destination blockchain nodes, respectively; alternatively, a cross-chain request is initiated by each source blockchain node or a designated plurality of source blockchain nodes in the source blockchain network to a plurality of destination blockchain nodes, respectively. And then, the at least one source block chain node receives the response result returned by each target block chain node in the plurality of target block chain nodes, and then the at least one source block chain node respectively sends the received response result to a main node of the source block chain network, the main node acquires the response results from all the target block chain nodes, and the Bayesian fault tolerance verification is carried out on the acquired response results according to the number of the nodes. The master node may be selected by a consensus algorithm employed by the source blockchain network.

For example, in the case that each source blockchain node in the source blockchain network sends a cross-chain request to each destination blockchain node, if the data loss in the transmission process is not considered, each source blockchain node in the source blockchain network will receive a response result returned by each destination blockchain node. For example, blockchain network a includes blockchain nodes 1, 2, 3, blockchain network b includes blockchain nodes 4, 5, 6, 7, for example, blockchain node 1, and blockchain nodes 2-3 are similar: the blockchain node 1 sends a cross-chain request to the blockchain nodes 4, 5, 6, 7, respectively, and then the blockchain node 1 will receive the response results returned by the blockchain nodes 4, 5, 6, 7, respectively.

Then, each source blockchain node may send the received response result to a master node of the source blockchain network, the master node obtains the response results from all destination nodes, and performs a bayer fault tolerance check on the obtained response results according to the number of nodes. The master node can be selected from the blockchain nodes in the source blockchain, for example, the source blockchain adopts a PBFT algorithm, and then the master node can be selected through the PBFT consensus algorithm, namely, the master node in the round of consensus performs Bayesian fault-tolerant verification on the acquired response result according to the number of nodes. Of course, any other way may be used to select the master node, such as designating a certain node as the master node, which is not limited in this specification.

For example, after receiving response results sent by other source blockchain nodes, the master node performs redundancy elimination processing on response results returned by the same destination blockchain node, that is, retains different identical response results therein, and eliminates identical response results therein. For example, the destination blockchain node 4 returns response results to the source blockchain nodes 1, 2 and 3, respectively, the source blockchain node 1 is the master node, and the source blockchain node 2 and the source blockchain node 3 send the response results returned by the destination blockchain node 4 to the source blockchain node 1. Then, the source blockchain node 1 will acquire three response results returned by the destination blockchain node 4, and then remove the same response result and reserve different response results. Similarly, redundancy is removed for other target blockchain nodes in the manner described above. Then, according to the conclusion of "3f+1< =n" of the pbft algorithm, the maximum fault-tolerant node number f= (n-1)/3, n supported by the pbft algorithm is the node number of the destination blockchain node. And then, for all the response results after redundancy elimination, if f+1 identical response results exist, judging that the fault-tolerant check passes, and taking the f+1 identical response results as response results returned by the final destination block chain network for subsequent processing.

Of course, the pbft algorithm supports both fault tolerant failed nodes and fault tolerant offending nodes. If only the fault-tolerant fault node is considered, a shift algorithm may be adopted, where f= (n-1)/2, n is the number of nodes of the destination node, and the fault-tolerant checking process is similar to the above, and will not be repeated here.

It should be noted that the above embodiment of sending a cross-chain request to each destination blockchain node by each source blockchain node is merely an exemplary example for cross-chain interaction. For example, the above-mentioned cross-chain interaction may also be accomplished by a master node of the source blockchain network and a master node of the destination blockchain network; alternatively, the above-described cross-chain interactions may also be accomplished by each source blockchain node of the source blockchain network with a master node of the destination blockchain network; alternatively, the above-described cross-chain interactions may also be accomplished by a master node of the source blockchain network with each destination blockchain node of the destination blockchain network, and so on; the present description is not limited thereto.

According to the above embodiment, through the above manner of respectively initiating the cross-link request to the plurality of target blockchain nodes by the source blockchain node and performing the bayer fault-tolerant verification on the response results of the plurality of target blockchain nodes, the consistency of the source blockchain network data processing in the cross-link interaction process can be ensured without introducing other additional components (such as using the cross-link relay, notary, and other manners, requiring additional configuration components). In other words, the cross-chain interaction scheme provided by the specification can enable the interaction process to be simple, light and efficient on the premise of ensuring the consistency of source blockchain network data processing in the cross-chain interaction process.

In the cross-chain interaction scheme of the present specification, the interaction process between the source blockchain network and the destination blockchain network is different due to the construction manner of the two blockchain networks. The following describes the corresponding interaction process in detail in connection with the construction of the source blockchain network and the destination blockchain network.

Because of the decentralization characteristic of the blockchain network, all nodes in the blockchain network are in peer-to-peer status, so that all blockchain nodes in the blockchain network can maintain the same block data, but some nodes sometimes have the requirement of realizing small-range transactions, and other nodes are prevented from acquiring the transactions and related data, so that the special requirements of part of nodes cannot be met. Taking a blockchain as an example, all the coalition members (i.e., node members in the coalition) can form a blockchain network, all the coalition members respectively have corresponding blockchain nodes in the blockchain network, and all transactions and related data occurring on the blockchain network can be obtained through the corresponding blockchain nodes. In some cases, however, there may be some coalition members desiring to complete transactions with security requirements, which may be desirable to both be able to document on the blockchain or to take advantage of other advantages of blockchain technology, and to avoid other coalition members from viewing such transactions and related data. Although the members of the federation may additionally build a new blockchain network in a manner similar to that described above that includes all of the members of the federation, building a new blockchain network from scratch requires significant resources and is time consuming, either in the process of building the blockchain network or in the process of post-build configuration. The requirements among the alliance members are often temporary or have certain timeliness, so that the new blockchain network quickly loses the meaning of existence due to the disappearance of the requirements, thereby further increasing the chain building cost of the blockchain network. The requirements between the members of the federation often vary, and the members of the federation corresponding to each requirement also often vary, so that a new blockchain network may need to be built whenever the members of the federation change, resulting in a great waste of resources and time.

The present description may use the established blockchain network as a blockchain master network and establish blockchain subnets based on the blockchain master network. Then, in a federated chain scenario such as that described above, federated members may build the required blockchain subnetwork on the blockchain subnetwork's basis based on their own needs, already participating in the blockchain subnetwork. Because the blockchain subnetwork is built on the basis of the blockchain main network, compared with a completely independent blockchain network, the building process of the blockchain subnetwork has the advantages of greatly reduced consumed resources, time consumption and the like, and extremely high flexibility. On one hand, the small-range transaction requirements among some node members can be met, and on the other hand, the management of the blockchain subnetwork can be conveniently realized through the blockchain main network.

Specifically, each blockchain link point in the blockchain main network respectively obtains the transactions that constitute the blockchain subnetwork. Wherein the transaction includes configuration information for the blockchain subnetwork, the configuration information including identity information of node members participating in the construction of the blockchain subnetwork. Then, each block link point in the block chain main network respectively executes the transaction to reveal the configuration information; when the configuration information comprises identity information of node members corresponding to the first block link points, node equipment for deploying the first block link points generates an creation block comprising the configuration information based on the transaction, and starts a second block link node belonging to the block link sub-network based on the creation block.

The transaction for constructing the blockchain sub-network can be initiated by an administrator of the blockchain main network, namely, the administrator is only allowed to construct the blockchain sub-network on the basis of the blockchain main network, and the construction authority of the blockchain sub-network is prevented from being opened to the common users, so that the safety problem caused by the construction authority is prevented. In some cases, a common user of the blockchain main network can be allowed to initiate the transaction for constructing the blockchain sub-network, so that the networking requirement of the common user is met, and the common user can still quickly construct the blockchain sub-network under the condition that an administrator is inconvenient to initiate the transaction.

For example, as shown in fig. 5, the blockchain home network is subnet0, and the blockchain nodes included in the subnet0 are nodeA, nodeB, nodeC, nodeD, nodeE, and the like. Suppose that node members corresponding to nodeA, nodeB, nodeC and nodeD, respectively, wish to build a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate transactions to build the blockchain subnetwork, then the above-described transactions to build the blockchain subnetwork may be initiated by nodeA to subnet 0; if nodeE is an administrator and only the administrator is allowed to initiate the transaction of building the blockchain subnetwork, then nodeA-nodeD need to request nodeE so that nodeE initiates the transaction of building the blockchain subnetwork to subnet 0; if nodeE is an administrator but allows a common user to initiate transactions to build a blockchain subnet, then each of nodeA-nodeE may initiate transactions to subnet0 to build a blockchain subnet as described above. Of course, whether an administrator or an ordinary user, the node members corresponding to the blockchain nodes that initiate transactions that constitute the blockchain subnetwork do not necessarily participate in the constituted blockchain subnetwork, e.g., although the blockchain subnetwork is ultimately constituted by the node members corresponding to nodeA, nodeB, nodeC and nodeD, respectively, the transactions that constitute the blockchain subnetwork may be initiated by nodeE to subnet0, and the transactions that constitute the blockchain subnetwork are not necessarily initiated by nodeA to nodeD.

When the blockchain subnetwork is built on the basis of the blockchain main network, it is easy to understand that a logical hierarchical relationship exists between the blockchain subnetwork and the blockchain main network. For example, when the blockchain subnet1 is built on the subnet0 shown in fig. 5, the subnet0 may be considered to be at the first layer and the subnet1 may be considered to be at the second layer. In one case, the blockchain master network in this specification may be an underlying blockchain network, i.e., a blockchain subnetwork that is not a blockchain subnetwork that is built on the basis of other blockchain networks, such as subnet0 in fig. 5, may be considered a blockchain master network that is of the underlying blockchain network type. In another case, the blockchain main network in the present specification may be a subnet of another blockchain network, for example, another blockchain subnet may be further constructed based on the subnet1 in fig. 5, where the subnet1 may be considered as the blockchain main network corresponding to the blockchain subnet, and this does not affect the creation of the blockchain sub network on the subnet0 while the subnet1 belongs to the blockchain sub network. It can be seen that the blockchain master network and the blockchain subnetwork are actually relative concepts, and that the same blockchain network may be a blockchain master network in some cases and a blockchain subnetwork in other cases.

After the transaction for constructing the block chain sub-network is sent to the block chain main network, the common node in the block chain main network performs common identification, and after the common identification is passed, each block chain link point executes the transaction so as to complete the construction of the block chain sub-network. The consensus process depends on the consensus mechanism employed, such as any of the consensus mechanisms described above, which is not limiting in this description.

By including configuration information in the transactions for constructing the blockchain sub-network, the configuration information may be used to configure the constructed blockchain sub-network so that the constructed blockchain sub-network meets networking requirements. For example, by including in the configuration information identity information of the node members participating in the construction of the blockchain subnetwork, it is possible to specify which node members the constructed blockchain subnetwork corresponds to.

The identity information of the node member may include a public key, or other information capable of characterizing the identity of the node member, such as a node ID, which is not limited in this specification. Taking a public key as an example, each blockchain node has one or more public and private key pairs, the private key is held by the blockchain node, and the public key is disclosed and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be represented by the public key, and the identity of the node member corresponding to the blockchain node can also be represented by the public key. Thus, for node members that wish to participate in the building blockchain subnetwork, the public keys of the corresponding blockchain nodes on the blockchain main network for those node members may be added to the transaction for the building blockchain subnetwork as the identity information for those node members. The public-private key pair described above may be used in the process of signature verification. For example, in a consensus algorithm with a signature, such as subnet1 described above, where the message is signed with its own maintained private key, the signed message is broadcast in subnet1, and the nodeB1, nodeC1, and nodeD1 can verify the signature of the received message with the public key of nodeA1 to confirm that the message received by themselves was indeed from nodeA1 and was not tampered with.

The first blockchain node may be a blockchain node on the blockchain master network that corresponds to a node member indicated by the configuration information. In constructing a blockchain subnetwork, rather than the first blockchain point directly participating in constructing the blockchain subnetwork, it is desirable that a second blockchain node be generated by a node device for deploying the first blockchain node and the second blockchain node participate in constructing the blockchain subnetwork. The first blockchain node and the second blockchain node correspond to the same node member, such as the same alliance chain member in an alliance chain scene, but the first blockchain node belongs to a blockchain main network and the second blockchain node belongs to a blockchain sub-network, so that the node member can participate in transactions of the blockchain main network and the blockchain sub-network respectively; and because the block chain main network and the block chain sub network belong to two block chain networks which are mutually independent, the blocks generated by the first block chain link point and the blocks generated by the second block chain node are respectively stored in different storages (the adopted storages can be databases for example) on the node equipment, and the mutual isolation between the storages respectively used by the first block chain node and the second block chain node is realized, so that the data generated by the block chain sub network can only be synchronized among the block chain nodes in the block chain sub network, so that the data generated on the block chain sub network can not be obtained by the node members only participating in the block chain main network, the data isolation between the block chain main network and the block chain sub network is realized, and the transaction requirement between part of the node members (namely the node members participating in the block chain sub network) is met.

The first blockchain node and the second blockchain node are logically partitioned blockchain nodes, and from a physical device perspective, the node device with the first blockchain node and the second blockchain node disposed thereon participates in the blockchain main network and the blockchain sub-network at the same time. Because the blockchain main network and the blockchain sub network are mutually independent, the identity systems of the two blockchain networks are mutually independent, and even if the first blockchain node and the second blockchain node can adopt identical public keys, the first blockchain node and the second blockchain node can still be regarded as different blockchain nodes. For example, in FIG. 5, nodeA in subnet0 corresponds to a first blockchain node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, the nodeA1 corresponds to a second blockchain node. Therefore, even if the public key adopted by the second blockchain node is different from the first blockchain node, the implementation of the scheme of the specification is not affected because the identity systems are independent.

Of course, the node members participating in the blockchain subnetwork are not necessarily only part of the node members participating in the blockchain main network. In some cases, node members participating in the blockchain subnetwork may be completely identical to node members participating in the blockchain subnetwork, where all node members may obtain data on the blockchain subnetwork and the blockchain subnetwork, but the data generated by the blockchain subnetwork and the blockchain subnetwork may still be isolated from each other, for example, one type of service may be implemented on the blockchain subnetwork, and another type of service may be implemented on the blockchain subnetwork, so that service data generated by the two types of services may be isolated from each other.

In addition to the identity information of the node members described above, the configuration information may include at least one of: the network identification of the blockchain subnetwork, identity information of an administrator of the blockchain subnetwork, attribute configuration for blockchain platform code, and the like, are not limiting in this description. The network identification is used to uniquely characterize the blockchain subnetwork, and thus the network identification of the blockchain subnetwork should be distinguished from the blockchain main network and other blockchain subnetworks built on the blockchain main network. The identity information of the administrator of the blockchain subnetwork, such as a public key that is a member of the node of the administrator; the administrators of the blockchain main network and the blockchain sub network may be the same or different.

One of the advantages of constructing the blockchain subnetwork through the blockchain main network is that the first blockchain node is already deployed on the node equipment generating the second blockchain node, so that the blockchain platform code used by the first blockchain node can be multiplexed on the second blockchain node, repeated deployment of the blockchain platform code is avoided, and the construction efficiency of the blockchain subnetwork is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the second blockchain node may multiplex the attribute configuration employed on the first blockchain node; if the configuration information includes an attribute configuration for the blockchain platform code, the second blockchain node may employ the attribute configuration such that the attribute configuration employed by the second blockchain node is not limited to the attribute configuration of the first blockchain node, independent of the first blockchain node. The attribute configuration for the blockchain platform code may include at least one of: code version number, whether consensus is required, consensus algorithm type, block size, etc., which is not limiting in this description.

The transactions that constitute the blockchain subnetwork include transactions that invoke contracts. The transaction may specify the address of the smart contract that was invoked, the method that was invoked, and the parameters that were entered. For example, the invoked contract may be the aforementioned creation contract or system contract, the invoked method may be a method of building a blockchain subnet, and the incoming parameters may include the configuration information described above.

For example, the structure of the Subnet system contract may contain the following information:

the subnet Id is used for representing a subnet identifier of the block chain subnet; pubkeys is used for representing identity information of subnet nodes of the blockchain subnet; the subtnetState is used for representing the running state (start, stop, invalid, etc.) of the blockchain subnetwork; genesis is used to represent the generation block information of the blockchain subnetwork. The data may be stored in a contract state of a Subnet system contract.

The transaction for building a blockchain subnetwork may contain the following information:

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

wherein the from field is information of the initiator of the transaction, such as an Administrator, indicating that the initiator is an Administrator; the to field is the address of the called smart contract, e.g., the smart contract may be a Subnet contract, and the to field is specifically the address of the Subnet contract; the method field is a called method, for example, the method used to construct the blockchain subnetwork in the Subnet contract may be AddSubnet (string), and string is a parameter in the AddSubnet () method, and the value of the parameter is represented by generation, which is specifically the configuration information described above in the above example.

Taking as an example the transactions that call the AddSubnet () method in the Subnet contract are performed by the nodes nodeA to nodeE on the Subnet 0. After the transaction passes the consensus, performing an AddSubNet () method by the nodeA to the nodeE respectively, and transmitting configuration information to obtain a corresponding execution result.

The execution result of the contract may include the configuration information, and the execution result may be in the receipt described above, and the receipt may include an event related to execution of the AddSubnet () method, that is, a networking event. Topic of networking events may contain predefined networking event identifications to distinguish from other events. For example, in an event related to execution of the AddSubnet () method, the content of the topic is a keyword subnet, and the keyword is distinguished from topic in an event generated by other methods. Then, the node apparatuses 1 to 5 of the nodeA to nodeE or the deployment nodeA to nodeE can determine to monitor the event related to execution of the AddSubnet () method, that is, the networking event, in the case of monitoring the topic including the keyword subnet by monitoring the topic included in each event in the generated receipt. For example, the event in the receipt is as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

then, when the 1 st event is monitored, since the content of the topic contained is other, it is determined that the event is irrelevant to the AddSubnet () method; and when the 2 nd event is monitored, determining that the event is related to an AddSubnet () method because the content of the topic is subnet, and further reading a data field corresponding to the event, wherein the data field contains the configuration information. Taking the example that the configuration information includes the public key of the node member of the blockchain subnet, the content of the data field may include, for example:

{subnet1；

A public key of nodeA, IP of nodeA, port number … of nodeA;

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

a public key of nodeC, IP of nodeC, port number … of nodeC;

a public key of nodeD, IP of nodeD, port number … of nodeD;

}

wherein, subnet1 is the network identification of the blockchain subnet that it is desired to create. Each blockchain node in the blockchain master network may record network identifications of all blockchain subnets that have been created on the blockchain master network, or other information related to the blockchain subnets, which may be maintained in a Subnet contract as described above, for example, and may specifically correspond to the value of one or more contract states contained in the Subnet contract. Then, it can be determined whether the subnet1 already exists according to the recorded network identifications of all the created blockchain subnets; if not, it is indicated that subnet1 is a new block chain subnet that currently needs to be created, and if so, it is indicated that subnet1 already exists.

In addition to employing network identifications of new blockchain subnets that are desired to be created, predefined new network identifications may also be employed that indicate corresponding networking events for building new blockchain subnets. For example, the subnet1 may be replaced by a newsubnet, where the newsubnet is a predefined newly created network identifier, and when it is identified that the data field contains the newsubnet, the nodes a to e may determine that the event containing the newsubnet is a networking event, and need to create a new blockchain subnet.

In addition to the network identifier subnet1, the data field also contains identity information of each node member participating in the construction of the blockchain subnet. The node equipment for deploying the first blockchain node can monitor the generated receipt, and acquire the configuration information or the creation block contained in the networking event by the node equipment for deploying the first blockchain node under the condition that the networking event is monitored and the content of the networking event contains the identity information of the node member corresponding to the first blockchain node. Or the first blockchain node may monitor the generated receipt, and trigger node equipment deploying the first blockchain node to acquire the configuration information or the creation block contained in the networking event when the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member.

As previously described, the node device may directly monitor the receipt. Assuming that nodes a to e are respectively disposed on the node devices 1 to 5, the node devices 1 to 5 can monitor receipts respectively generated by the nodes a to e, and if the subnet1 is a block chain subnet that needs to be newly constructed, the node devices 1 to 5 further identify identity information of node members contained in the data field to determine their own processing modes. Taking nodeA and node device 1 as examples: if the node device 1 finds that the data field contains identity information such as a public key, an IP address, a port number and the like of the nodeA, the node device 1 generates an creation block containing the configuration information when obtaining the configuration information from the data field based on the message mechanism, and the node device 1 deploys the nodeA1 locally, so that the created block is loaded by the nodeA1, thereby becoming a subnet node of the subnet 1; similarly, node device 2 may generate nodeB1, node device 3 may generate nodeC1, and node device 4 may generate nodeD1. And the node device 5 finds that the identity information contained in the data field is not matched with the identity information, so that the node device 5 does not generate an creation block according to the configuration information in the data field and does not generate a blockchain node in the subnet 1.

As previously described, a blockchain node in the blockchain master network may monitor receipts and trigger the node device to perform related processing based on the monitoring results. For example, if it is determined that subnet1 is a blockchain subnet that needs to be newly constructed, the nodeA-nodeE further identifies the identity information of the node members contained in the data field to determine its own processing mode. For example, nodeA to nodeD may find that the data field contains identity information such as its own public key, IP address, port number, etc., assuming that nodeA to nodeD are respectively disposed on the node devices 1 to 4, taking nodeA and node device 1 as examples: the nodeA triggers the node equipment 1, so that the node equipment 1 generates an creation block containing configuration information under the condition that the node equipment 1 obtains the configuration information from the data field based on the message mechanism, and the node equipment 1 deploys the nodeA1 locally, and the nodeA1 loads the generated creation block, thereby becoming a subnet node of the subnet 1; similarly, nodeB will trigger node device 2 to generate nodeB1, nodeC will trigger node device 3 to generate nodeC1, and nodeD will trigger node device 4 to generate nodeD1. And, the nodeE finds that the identity information contained in the data field is not matched with the nodeE, and assuming that the nodeE is deployed on the node device 5, the node device 5 does not generate an creation block according to the configuration information in the data field, and does not generate a blockchain node in the subnet 1.

As previously mentioned, the first blockchain node and the second blockchain node do not necessarily employ the same identity information. Thus, in the above embodiment, the data field may contain identity information generated in advance for the nodeA1 to nodeD1, and is distinguished from the identity information of the nodeA to nodeD. Still taking nodeA and node device 1 as examples: the node device 1 can generate an creation block, deploy the nodeA1, and load the creation block by the nodeA1 if the identity information of the nodeA1 is found in the data field; alternatively, nodeA if the identity information of nodeA1 is found in the data field, nodeA triggers the node device 1 to generate an created block, deploy nodeA1, and load the created block by nodeA 1. The processing manners of other blockchain nodes or node devices are similar and are not described in detail herein.

In addition to the configuration information, the execution result of the contract may include an creation block. In other words, in addition to the configuration information contained in the data field, the generation block containing the configuration information may be directly generated in the process of executing the contract call, so that the generation block is contained in the data field, and for the nodeA to nodeD described above, the corresponding node devices 1 to 4 may directly obtain the generation block from the data field through the message mechanism without self-generation, and may improve the deployment efficiency for the nodeA1 to nodeD 1.

In the present specification, the transaction for constructing the blockchain subnetwork may not be a transaction for calling the intelligent contract, so that the blockchain network that does not support the intelligent contract may also implement the technical solution of the present specification, thereby quickly creating the blockchain subnetwork on the basis of the blockchain main network. For example, a set of networking transaction type identifiers may be predefined, and when a transaction includes the networking transaction type identifier, the transaction is indicated as being for building a new blockchain subnet, i.e., the transaction is a transaction that builds a blockchain subnet. The blockchain platform code may include associated processing logic for constructing a blockchain sub-network, such that when executing a transaction, a first blockchain node running the blockchain platform code may trigger a node device deploying the first blockchain node to generate an creation block including the configuration information and initiate a second blockchain node, and load the creation block by the second blockchain node to form a blockchain node in the blockchain sub-network if the transaction is found to include the networking transaction type identifier and the identity information of the node member corresponding to the first blockchain node is included in the configuration information in the transaction.

The node device enables deployment of a blockchain node on the node device by creating an instance of running blockchain platform code in a process. For a first blockchain node, creating, by the node device, a first instance of running blockchain platform code in the process. For example, a node device may first create a first instance in a process to form a first blockchain node in a blockchain master network; and when the node member corresponding to the node device wants to participate in the construction of the blockchain sub-network, a second instance can be created in the process, wherein the second instance is different from the first instance, and a second blockchain node in the blockchain sub-network is formed by the second instance. Similarly, for a second blockchain node, a second instance of running blockchain platform code is created by the node device in the process described above. When the first instance and the second instance are located in the same process, because cross-process interaction is not involved, the deployment difficulty of the second blockchain node can be reduced, and the deployment efficiency can be improved. Of course, the second instance may also be in a different process on the node device than the first instance, which is not limited by the present description. For example, a node device may create a first instance in a first process to form a first blockchain node in a blockchain master network; when the node member corresponding to the node device wishes to participate in the construction of the blockchain sub-network, a second process different from the first process may be started, and a second instance may be created in the second process, where the second instance is different from the first instance, and further the second instance forms a second blockchain node in the blockchain sub-network.

By the method, the blockchain sub-network can be created on the blockchain main network. Taking fig. 5 as an example, the subnet0 originally includes the nodes a to e, and the subnet1 may be constructed on the basis of the subnet0, where the subnet1 includes the nodes a1 to d1, and the nodes a and a1, the nodes b and b1, the nodes c and c1, and the nodes d and d1 are respectively disposed on the same node device. Similarly, a subnet2 or more blockchain subnets may also be built on subnet0, where subnet2 contains nodeA2, nodeB2, nodeC2 and nodeE2, with nodeA and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC and nodeC1, nodeD and nodeD1, nodeE and nodeE2 deployed on the same node device, respectively. And, subnet1, subnet2, etc. can be used as a new blockchain main network, and a blockchain sub-network is further constructed on the basis, and the process is similar to the construction of subnet1 or subnet2, and is not repeated here.

By constructing the blockchain subnetwork in the above manner, a management relationship can be formed between the blockchain main network and the blockchain subnetwork, i.e., the blockchain main network can manage the blockchain subnetwork. In addition, the present disclosure also provides a method for forming a multi-layer blockchain system based on a registration mechanism, which can establish a management relationship between blockchain networks without using a building process, and manage the blockchain networks accordingly, so that the method is not limited by the way of establishing the blockchain networks.

Specifically, each blockchain link point in the first blockchain network receives a registration transaction, acquires identity information of the second blockchain network from the registration transaction, and associates and stores the acquired identity information of the second blockchain network with subnet identifications allocated to the second blockchain network to register the second blockchain network as a subnet of the first blockchain network. Then, each blockchain link point in the second blockchain network receives an anchoring transaction, acquires the identity information of the first blockchain network and the subnet identification allocated to the second blockchain network from the anchoring transaction, and updates the acquired identity information of the first blockchain network and the subnet identification allocated to the second blockchain network to the identity information of the second blockchain network to anchor the first blockchain network as a main network of the second blockchain network.

Unlike the above-described manner of building blockchain subnets on a blockchain master network, the second blockchain network may not be built on the basis of the first blockchain network, such that the building of the second blockchain network does not form a management relationship with the first blockchain network. On the basis, the management relation is established between the first block chain network and the second block chain network through a registration mechanism, so that the first block chain network becomes a main network of the second block chain network and the second block chain network becomes a sub-network of the first block chain network.

The registration transaction may be initiated by an administrator of the second blockchain network, i.e., only allowing the administrator to register the second blockchain network as a subnet of the other blockchain network, while avoiding opening registration rights to common members to prevent security problems resulting therefrom. In some cases, the common member of the second blockchain network may also be allowed to initiate the above-described registration transaction, such that the common member may still be able to quickly complete registration if the administrator is not convenient to initiate the transaction.

For example, as shown in fig. 6, the first blockchain network is subnet0, and the blockchain nodes included in the subnet0 are nodeA, nodeB, nodeC, nodeD, nodeE, and the like. Similar to the embodiment shown in fig. 5, corresponding blockchain subnets subnet1 and subnet2 are built on the basis of subnet0 to respectively establish management relationships between subnet0 and subnet1 and between subnet0 and subnet2, so that subnet0 can respectively manage subnet1 and subnet 2. Further, suppose there is a blockchain network that is a subnet3, the subnet3 includes blockchain nodes such as nodeK, nodeL, nodeM and nodeN, and the subnet3 is not built on the basis of subnet 0. If the nodeK is an administrator and only allows the administrator to initiate a registration transaction, then the registration transaction may be initiated by the nodeK to subnet 0; if nodeN is an administrator and only the administrator is allowed to initiate a registration transaction, then nodeK-nodeM need to request to nodeN so that nodeN initiates the registration transaction to subnet 0; if nodeN is an administrator but allows a general user to initiate a registration transaction, then each of nodeK-nodeL may initiate the registration transaction described above with subnet 0.

As described above, when the blockchain subnetwork is built on the basis of the blockchain main network, a logical hierarchical relationship exists between the blockchain subnetwork and the blockchain main network, so as to form a multi-layer blockchain system, and this mechanism is referred to as a dynamic networking mechanism in this specification. For example, when the blockchain subnets subnet1 and subnet2 are built on subnet0 as in fig. 6, subnet0 may be considered to be at the first layer, and subnet1 and subnet2 may be considered to be at the second layer. Similarly, a multi-layer blockchain system is formed by registering a second blockchain network as a subnet of a first blockchain network such that a logical hierarchical relationship is formed between the first and second blockchain networks, which is referred to herein as a registration mechanism. For example, by registering subnet3 with subnet0 as in fig. 6, subnet0 can be considered to be at the first layer and subnet3 at the second layer.

For the multi-layer blockchain system formed by the dynamic networking mechanism and the registration mechanism, the blockchain main network can be a bottom layer blockchain network, the bottom layer blockchain network is not a blockchain sub-network based on the dynamic networking mechanism on the basis of other blockchain networks, and the bottom layer blockchain network is not a sub-network of other blockchain networks through the registration mechanism, namely the bottom layer blockchain network does not have a corresponding main network and is not managed by other blockchain networks, for example, a subnet0 in fig. 6 can be considered as a blockchain main network belonging to the type of the bottom layer blockchain network; alternatively, the blockchain main network may be further configured to form another blockchain sub-network by using a dynamic networking mechanism or a registration mechanism, for example, another blockchain sub-network may be further configured to form another blockchain sub-network by using a dynamic networking mechanism based on the subnet1 (or the subnet2 or the subnet 3) in fig. 6, or another blockchain network may be registered as a sub-network of the subnet1 (or the subnet2 or the subnet 3), where the subnet1 (or the subnet2 or the subnet 3) may be considered as the blockchain main network corresponding to the blockchain sub-network, which does not affect the blockchain sub-network of the subnet1 (or the subnet2 or the subnet 3) belonging to the subnet0 at the same time. It can be seen that the blockchain master network and the blockchain subnetwork are actually relative concepts, and that the same blockchain network may be a blockchain master network in some cases and a blockchain subnetwork in other cases.

It should be noted that, in a multi-layer blockchain system, each group of blockchain main network and blockchain sub-network formed by a dynamic networking mechanism and a registration mechanism may be included at the same time, for example, the subnets 1 and 2 in fig. 6 become subnets of the subnets 0 through the dynamic networking mechanism, and the subnets 3 become subnets of the subnets 0 through the registration mechanism. Of course, in some cases, a multi-layer blockchain system may include only blockchain masters and blockchain subnets formed by dynamic networking mechanisms, or only blockchain masters and blockchain subnets formed by registration mechanisms.

The registration transaction described above includes a transaction that invokes a contract. The transaction may specify the address of the smart contract that was invoked, the method that was invoked, and the parameters that were entered. For example, the invoked contract may be the aforementioned creating contract or system contract, the invoked method may be a method of registering a blockchain subnet, and the incoming parameters may include identity information of the second blockchain network. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet-M

method：RegSubnet(string)

string：genesis

wherein the from field is information of the initiator of the transaction, such as an Administrator, indicating that the initiator is an Administrator; the to field is the address of the called smart contract, for example, the smart contract may be a Subnet-M contract, and the to field is specifically the address of the Subnet-M contract; the method field is a called method, for example, the method for registering a blockchain Subnet in a Subnet-M contract may be RegSubnet (string), and string is a parameter in the RegSubnet () method, and the value of the parameter is represented by generation, which is specifically the identity information of the second blockchain network.

Each block link point in the first block chain network executes the RegSubnet () method called by the registration transaction according to the received registration transaction, so as to correlate and store the identity information of the second block chain network with the subnet identification distributed to the second block chain network, thereby being equivalent to the first block chain network registering the second block chain network as a subnet of the first block chain network.

The identity information of the second blockchain network may include: the second blockchain network includes information for all blockchain nodes. For example, the information for each blockchain node may include: node public key, node IP, node port number, etc., which is not limited in this specification.

The subnet identification assigned to the second blockchain network, i.e., the subnet ID of the second blockchain network. The generation method of the subnet ID is not limited in this specification, as long as global uniqueness is ensured. For example, a subnet ID may be temporarily generated for the second blockchain network by the RegSubnet () method described above after being invoked. For another example, a subnet ID may be selected for the second blockchain network from a preformed pool of IDs after being invoked by the RegSubnet () method described above. For another example, the subnet ID may be generated by the second blockchain network itself and transmitted to the RegSubnet () method together with the identity information of the second blockchain network via the generation described above.

By executing the intelligent contracts described above, each blockchain node in the first blockchain network may generate a corresponding execution result. The execution result of the contract may include the subnet ID described above; in particular, where the subnet ID is assigned by the first blockchain network, rather than being self-generated by the second blockchain network, it is desirable to learn the subnet ID assigned to the second blockchain network in this manner. Of course, even if the subnet ID is generated by the second blockchain network, the execution result of the contract may be listened to determine whether the first blockchain network has completed registration by the second blockchain network. The execution result of the contract may include the receipt described previously, which may include an event related to execution of the RegSubnet () method, i.e., a subnet registration event. The topic of the subnet registration event may contain a predefined subnet registration event identification to distinguish it from other events. For example, in an event related to execution of the RegSubnet () method, the content of the topic is a keyword RegSubnet, and the keyword is distinguished from topic in an event generated by other methods. Then, by monitoring the topic contained in each event in the receipt generated by any blockchain node in the first blockchain network, it can be determined that an event related to executing the RegSubnet () method, i.e., a subnet registration event, is monitored in the case that the topic containing the keyword RegSubnet is monitored. For example, the event in the receipt is as follows:

Event：

[topic:other][data]

[topic:RegSubnet][data]

......

Then, when the 1 st event is monitored, since the content of the topic contained is other, it is determined that the event is irrelevant to the RegSubnet () method; and when the 2 nd event is monitored, determining that the event is related to a RegSubnet () method because the content of the topic is RegSubnet, and further reading a data field corresponding to the event, wherein the data field contains the subnet ID. In addition, the subnet registration event may also include identity information of the second blockchain network to facilitate determining that the subnet registration event was indeed generated for the second blockchain network.

Based on the monitored subnet registration event, it may be determined that the first blockchain network has registered the second blockchain network as its own subnet on the one hand, and the subnet ID of the second blockchain network may be known on the other hand. Accordingly, the anchoring transaction described below may be initiated accordingly to the second blockchain network to complete the anchoring of the relevant information.

The subnet registration event described above may be monitored at a blockchain node in a first blockchain network by an initiator of a registration transaction and in turn an anchor transaction initiated by the initiator to a second blockchain network. Subnet registration events may also be monitored by other objects than the initiator of the registration transaction and in turn initiate an anchor transaction to the second blockchain network. Of course, the initiator of the anchor transaction is not necessarily the same as the object that listens for the subnet registration event described above; in fact, there is no necessary association between the object initiating the registration transaction, the object listening to the subnet registration event and the object initiating the anchor transaction, and the same object or different objects may be selected according to the actual situation.

The registration transaction may not be a transaction of invoking an intelligent contract, so that a blockchain network that does not support the intelligent contract may also implement the technical solution of the present specification, thereby associating and verifying, by the first blockchain network, the identity information of the second blockchain network with the subnet identification allocated to the second blockchain network. For example, a subnet registration transaction type identifier may be predefined, which when included, indicates that the transaction is to be used to register a new blockchain subnet, i.e., the transaction is a registration transaction. The blockchain platform code may include associated processing logic for registering blockchain subnets such that when executing a transaction, a first blockchain node running the blockchain platform code may associate and verify identity information of a second blockchain network with subnet identification assigned to the second blockchain network based on the processing logic if the transaction is found to include the subnet registration transaction type identification. At this point, the subnet identification assigned to the second blockchain network may be included in the registration transaction; alternatively, the blockchain platform code may also contain logic that assigns subnet identifications such that the blockchain platform code may assign corresponding subnet IDs to the second blockchain network for registration transactions.

The registration transaction is transmitted to the first blockchain network, is commonly recognized by common nodes in the first blockchain network, and is executed by each blockchain link point after passing through the common nodes so as to register the second blockchain network as a sub-network of the second blockchain network. The consensus process depends on the consensus mechanism employed, such as any of the consensus mechanisms described above, which is not limiting in this description. Similarly, an anchor transaction described below, after being sent to the second blockchain network, is consensus by a consensus node within the second blockchain network and, after passing the consensus, is performed by each blockchain node to anchor the first blockchain network as its own main network. The consensus process depends on the consensus mechanism employed, such as any of the consensus mechanisms described above, which is not limiting in this description.

The identity information of the second blockchain network can anchor the management relationship between the first blockchain network and the second blockchain network by updating the identity information of the first blockchain network and the subnet identification allocated to the second blockchain network into the identity information of the second blockchain network. By combining the identity information of the second blockchain network and the subnet identification thereof, which are stored in the first blockchain network, mutual authentication and cross-validation are realized between the first blockchain network and the second blockchain network, so that the management relationship between the first blockchain network and the second blockchain network is ensured to be approved by both parties, and corresponding management operation can be realized based on the management relationship.

Similar to the registration transaction described above, the anchor transaction may be initiated by an administrator of the second blockchain network. In some cases, the above-described anchoring transaction may also be allowed to be initiated by a common member of the second blockchain network, such that the common member may still be able to quickly complete the anchoring in the event that an administrator is not convenient to initiate the transaction.

The anchor transaction described above includes a transaction that invokes a contract. The transaction may specify the address of the smart contract that was invoked, the method that was invoked, and the parameters that were entered. For example, the invoked contract may be an creating contract or a system contract in the second blockchain network, the invoked method may be a method of anchoring the blockchain master network, and the incoming parameters may include identity information of the first blockchain network and a subnet ID assigned to the second blockchain network. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet-S

method：AnchSubnet(string)

string：genesis

wherein the from field is information of the initiator of the transaction, such as an Administrator, indicating that the initiator is an Administrator; the to field is the address of the called smart contract, e.g., the smart contract may be a Subnet-S contract, and the to field is specifically the address of the Subnet-S contract; the method field is a called method, for example, in the Subnet-S contract, the method for anchoring the blockchain main network may be AnchSubnet (string), and string is a parameter in the AnchSubnet () method, and the value of the parameter is represented by generation, which is specifically the identity information of the first blockchain network and the Subnet ID allocated to the second blockchain network.

Each block link point in the second block chain network executes the Anchor sub network () method called by the Anchor transaction according to the received Anchor transaction, so as to update the identity information of the first block chain network and the subnet identification allocated to the second block chain network into the identity information of the second block chain network, thereby being equivalent to the second block chain network registering the first block chain network as its own main network. Wherein the second blockchain network may maintain its own identity information through the world state in the Subnet-S contract, then the updating the identity information of the second blockchain network may actually include updating the world state of the maintained identity information by invoking the Subnet-S contract.

The identity information of the first blockchain network may include at least one of: information of all blockchain nodes included in the first blockchain network, network identification of the first blockchain network, and the like. Wherein the information for each blockchain node may include: node public key, node IP, node port number, etc., which is not limited in this specification. By initiating an interrogation transaction to a blockchain link point in the first blockchain network, identity information of the first blockchain network may be obtained; of course, the identity information of the first blockchain network may also be obtained in other manners, which is not limited in this specification.

Based on the registration transaction and the anchoring transaction, a management relationship mutually approved by both sides is established between the first blockchain network and the second blockchain network, the management relationship enables the first blockchain network to become a main network of the second blockchain network, and the second blockchain network to become a sub-network of the first blockchain network, so that the first blockchain network can implement corresponding management operation on the second blockchain network based on the management relationship.

The management operations described above may include routing of blockchain messages. For example, if any of the first blockchain nodes receives a blockchain message that includes a subnet identification assigned to a second blockchain network, the blockchain node may query the identity information of the second blockchain network based on the subnet identification included in the blockchain message and forward the blockchain message to the second blockchain network because the first blockchain network has registered the identity information of the second blockchain network and its subnet identification. Therefore, based on the establishment of the management relationship, the first blockchain network can route the blockchain message to the second blockchain network, thereby being beneficial to improving the success rate of the transmission of the blockchain message. And when the network environment between a certain object and the first blockchain network is good and the network environment between the first blockchain network and the second blockchain network is poor, the first blockchain network can be used as a message transmission relay between the object and the second blockchain network, so that the transmission rate and the success rate of the blockchain messages can be improved. The blockchain message may include various types of messages such as blockchain transactions, blockdata, consensus messages, and the like, which are not limited in this specification.

Each blockchain node in the first blockchain network may also record an operational state of the second blockchain network, such as the operational state may include an available state, a deactivated state, a suspended state, and the like. Then, if any of the first blockchain nodes receives the blockchain message and determines that the blockchain message includes the subnet ID of the second blockchain network, the running state of the second blockchain network may be further queried, so that the blockchain message is forwarded when the second blockchain network is in an available state, otherwise, the blockchain message may not be forwarded to save network resources.

The management operations described above may include direct management for the second blockchain network. For example, management for the second blockchain network may be performed by initiating a management transaction for the second blockchain network to the first blockchain network. The initiator of the management transaction may be, for example, an administrator of the first blockchain network, although other objects are not excluded. Accordingly, each blockchain node in the first blockchain network may receive a management transaction, obtain a subnet identification and a management instruction allocated to the second blockchain network from the management transaction, and send the management instruction to the second blockchain network; specifically, the identity information of the corresponding subnet may be queried based on the subnet identification in the management transaction, such as sending a management instruction to the second blockchain network when the identity information of the second blockchain network is queried. And under the condition that each blockchain node in the second blockchain network determines that the management instruction is sent by the corresponding main network, executing the management instruction to complete corresponding management operation.

In actual operation, the management instructions may be transferred to the second blockchain network in a variety of ways. For example: the management instructions may be included in a subnet management event generated by the first blockchain network performing the management transaction, the subnet management event including the management instructions and a subnet identification included in the management transaction. Then, when the second blockchain network monitors the subnet management event including the subnet identification of the second blockchain network, it can be determined that the management instruction contained in the subnet management event is for the second blockchain network to manage the second blockchain network. Or, the node device where any blockchain node in the first blockchain network is located may monitor the subnet management event, and send a management instruction to the second blockchain network according to the subnet identifier included in the subnet management event. Alternatively, the first blockchain network may send the management instructions to the second blockchain network via a cross-chain mechanism in the related art during the execution of the management transaction.

The management instructions described above may be used to implement at least one of: the present description is not limited in this regard as to changing the operational state of the second blockchain network, managing blockchain nodes included in the second blockchain network, defining business rules for the second blockchain network, changing functional components used by the second blockchain network, and the like. When the management instructions are used to change the operating state of the second blockchain network, the operating state of the second blockchain network may be switched between an available state, a suspended state, and a deactivated state, for example. When the management instructions are used to manage blockchain nodes included in the second blockchain network, for example, the blockchain nodes included in the second blockchain network may be added, subtracted, or the like. When the management instruction is used to define the service rule of the second blockchain network, the service rule of the second blockchain network may be added, deleted or modified, where the service rule may include, for example, a data format of the second blockchain network supporting the decoded blockchain message, a contract deployment authority, a contract invoking authority, a contract upgrading authority on the second blockchain network, and data in the second blockchain network that needs to be interacted with and authenticated to the first blockchain network. When the management instructions are used to change the functional components used by the second blockchain network, the functional components are formed by running blockchain platform codes at each blockchain node in the second blockchain network, and may include, for example, a consensus component, a privacy preserving component, a cross-chain component, an under-chain secret computing component, a subnet management component, and the like, and the management instructions may be used to add or delete the functional components used by the second blockchain network, or change the functional components used by the second blockchain network, such as changing a consensus algorithm adopted by the consensus component, and the like.

Based on the multi-layer blockchain system formed by the dynamic networking mechanism or the registration mechanism, different blockchain networks can be constructed to store different types of service data. In this scenario, there is a need for interactions between different blockchain networks, thus implementing some complex services through cross-chain interactions. For example, when a certain blockchain sub-network under the blockchain main network executes a service, another blockchain network (which may be a blockchain sub-network corresponding to the blockchain main network or may be another blockchain network independent of the blockchain main network) needs to be used for maintaining data, then the blockchain sub-network is used as a source blockchain sub-network, the other blockchain network is used as a destination blockchain network, and the source blockchain sub-network requests to acquire the data to be processed of the service from the destination blockchain network to complete execution of the related service.

Specifically, the source blockchain network includes blockchain subnets corresponding to the blockchain main network, source subnet nodes in the source blockchain subnets initiate a cross-chain request to destination nodes in the destination blockchain network, the blockchain main network corresponding to the source blockchain subnets maintains node identity information of each subnet node in the active blockchain subnets, and the cross-chain request contains identity information used for representing node identities of the source subnet nodes. The destination blockchain network may be a blockchain sub-network under the blockchain main network (corresponding to the source blockchain sub-network), that is, the blockchain sub-network belonging to the blockchain main network together with the source blockchain sub-network. In this case, the cross-chain request is essentially a cross-subnet request for between subnets belonging to the same blockchain main network. Of course, the destination blockchain network may also be other blockchain networks independent of the blockchain master network, such as any blockchain network that does not have the hierarchical relationship with the blockchain master network.

Because the block chain main network and the source block chain sub-network have the hierarchical relationship, the block chain main network maintains node identity information of each sub-network node in the source block chain sub-network, and meanwhile, the cross-chain request comprises identity information used for representing the node identity of the source sub-network node, so that after receiving the cross-chain request, the destination node can query the block chain main network for the node identity information of the source sub-network node so as to verify the identity information contained in the cross-chain request, and the cross-chain request is processed under the condition that verification passes. By utilizing the hierarchical relationship between the blockchain main network and the source blockchain sub-network to carry out identity verification on the source sub-network node, other additional components (such as a cross-chain relay mode, a notary mode and the like and additional configuration components) are not required to be introduced, only the node identity information of the source sub-network node is required to be inquired to the blockchain main network in the verification process, the characteristics of the hierarchical relationship are fully utilized in the whole verification process, and the verification operation is simple, light and efficient on the premise that the identity of the source sub-network node can be accurately verified to ensure the data security.

For the source blockchain subnetwork, it may be formed by the dynamic networking mechanism or registration mechanism described above. In other words, the source blockchain subnetwork is built based on the blockchain main network; alternatively, the source blockchain subnetwork is a blockchain subnetwork registered with the blockchain main network. Further, the relevant contents describing the dynamic networking mechanism and the registration mechanism can be known from the above description: regardless of the mechanism by which the blockchain subnetworks of the blockchain main network are formed, a subnet management contract is deployed on the blockchain main network, and the subnet management contract is used for maintaining node identity information of subnet nodes in each blockchain subnet corresponding to the blockchain main network. Then, the destination node of the destination blockchain network may read the node identity information of the source subnet node maintained by the subnet management contract (deployed on the blockchain master network corresponding to the source blockchain subnet) to verify the identity information contained in the received cross-chain request.

Similarly, the target blockchain network may be a blockchain subnet constructed by the dynamic networking mechanism based on the blockchain main network corresponding to the source blockchain subnet, i.e. the target blockchain network is a blockchain subnet constructed based on the blockchain main network. In this case, the relevant content describing the dynamic networking mechanism can be known from the above description: and the node equipment for deploying the main network nodes in the block chain main network is also deployed with the sub-network nodes of the block chain sub-network. The main network node and the sub-network node which are deployed on the same node equipment share the blockchain plugin of the node equipment, so that the sub-network node can query the data about the blockchain main network maintained by the main network node through the blockchain plugin. Then, the destination node may read, through the blockchain plugin in the target node device of the destination node, the node identity information of the source subnet node maintained by the main network node deployed by the target node device, so as to verify the identity information contained in the received cross-chain request.

For example, the blockchain plugin may be a subnetplug in, and the main network node may invoke the subnetplug in to query the information of the blockchain subnetwork maintained by the Subnet system contract (i.e., the Subnet management contract), and store the information in memory as a shared portion of the blockchain main network and the corresponding blockchain subnetwork for querying. Meanwhile, the cross-link request comprises a subnet identifier of a source block chain subnet, and then the destination node can inquire node identity information of a subnet node in the source block chain subnet from the subnet plug in accordance with the subnet identifier contained in the received cross-link request.

The destination blockchain network may also be a blockchain subnet registered with the blockchain master network through the registration mechanism described above. In this case, a destination node in the destination blockchain network may submit a query transaction to the blockchain master network, the query transaction being for instructing the blockchain master network to query the source subnet node for node identity information to verify the identity information contained in the received cross-chain request.

In one case, the identification information may include a node identification declared by the source subnet node and a subnet identification of the affiliated blockchain subnet. In this case, after receiving the cross-link request, the destination node in the destination blockchain network may query the blockchain main network whether the node identifier declared by the source subnet node and the subnet identifier match, thereby checking the validity of the source subnet node. For example, as previously described, information of the blockchain subnetwork is maintained in the contract state of the subnet management contract deployed on the blockchain main network, and includes the subnetwork identification, the node identification of the corresponding subnetwork node, and the like.

In another case, the identification information may comprise a signature generated by the source subnet node based on its own node private key. In this case, after receiving the cross-link request, the destination node in the destination blockchain network may query the blockchain main network for the node public key of the source subnet node, and use the node public key to check the signature included in the cross-link request, thereby checking the validity of the signature. For example, as previously described, information for a blockchain subnet is maintained in the contract state of a subnet management contract deployed on the blockchain master network, including node public keys for subnet nodes within each blockchain subnet.

Of course, the identification information may include both the node identifier declared by the source subnet node and the subnet identifier of the affiliated blockchain subnet, as well as the signature generated by the source subnet node based on its own node private key. In other words, the verification operation includes the validity of the verification source subnet node and the validity of the verification signature described above. In summary, the condition for verification pass may include validity of the source subnet node and/or validity of the signature.

Meanwhile, in order to ensure the data privacy in the cross-link interaction process, the blockchain message transmitted by the cross-link request can be encrypted in a digital envelope mode. The digital envelope encryption mode combines a symmetric encryption algorithm and an asymmetric encryption algorithm. Specifically, the source subnet node encrypts the blockchain message to be transmitted by adopting the self symmetric key, and adds the encrypted blockchain message to the cross-chain request. Then, the source subnet node encrypts the symmetric key with the node public key of the destination node and adds the encrypted symmetric key to the cross-chain request. Correspondingly, after receiving the cross-link request, the destination node decrypts the symmetric key in the ciphertext form contained in the cross-link request by adopting the private key of the destination node to obtain the symmetric key in the plaintext form, and then decrypts the blockchain message contained in the cross-link request by the symmetric key.

Further, to ensure reliable transmission of the cross-chain request, a source subnet node in the source blockchain subnet may send the cross-chain request to each destination node in the destination blockchain network, respectively, to be responded to by each destination node. By the method for sending the cross-link request, even if part of the cross-link request is lost in the transmission process, the destination node in the destination block chain network can be guaranteed to receive the cross-link request to respond, so that the source block chain sub-network can be further guaranteed to successfully acquire the response result of the destination block chain network to the cross-link request. In the manner of transmitting the cross-chain request, the source subnet node in the source blockchain subnet can encrypt the own symmetric key by adopting the node public key of each destination node in the destination blockchain network respectively, and add each symmetric key obtained by encryption into the cross-chain request, and then the source subnet node sends the cross-chain request to each destination node in the destination blockchain network respectively. Correspondingly, after receiving the cross-link request, the destination node adopts the private key of the destination node to decrypt the symmetric keys in each ciphertext form contained in the cross-link request, and can successfully decrypt the symmetric keys encrypted by the public key of the destination node, and then decrypts the blockchain message contained in the cross-link request through the symmetric keys successfully decrypted. By adopting the mode of encrypting the symmetric key by the node public key of each destination node, the unified creation mode aiming at the cross-link request can be ensured, the operation of creating the cross-link request is simplified, and the source subnet node is prevented from carrying out differentiated processing on each destination node in the process of creating the cross-link request, for example, the symmetric key is encrypted by the node public key of each destination node and added into the cross-link request to be sent to the corresponding destination node.

For blockchain messages transmitted by a cross-chain request, events generated by the source blockchain subnet in the process of executing the smart contract may be used. Specifically, an intelligent contract is deployed on a source blockchain subnet, and a service initiator can initiate a first blockchain transaction for invoking the intelligent contract to the source blockchain subnet, wherein the first blockchain transaction indicates a network identifier of a target blockchain network, and the target blockchain network stores data to be processed of the intelligent contract. Then, the source subnetwork node may execute the smart contract in response to the first blockchain transaction to create a blockchain message for addition to the cross-chain request, the blockchain message indicating that the destination blockchain network returns the pending data of the smart contract.

For ease of understanding, the following describes the above interaction process in detail with reference to fig. 7, taking cross-subnet interaction between two blockchain subnets under the same blockchain main network as an example.

Assuming that the subnet a and the subnet b are both blockchain subnets of the blockchain main network subnet 0, the service contracts deployed on the subnet a are used for registering members for users, the registered members need to use the identification card numbers of the users, and the identification card numbers of the users are stored in the subnet b. Then, the user may initiate a blockchain transaction for invoking the service contract to the subnet a, where the blockchain transaction includes information such as a contract address of the service contract and a subnet identifier of the subnet b. At this time, subnet a is used as the source blockchain subnet, and subnet b is used as the destination blockchain subnet.

As shown in fig. 7, in the service layer, after receiving the blockchain transaction, the source subnet node in the subnet a may execute a service contract generation event, where the event includes the following fields:

biz_id: a service id;

request_id: request id;

src_subnet_id: a source block chain subnet identification;

dest_subnet_id: a destination block chain subnet identifier;

method of: calling a method;

args: calling parameters;

timetable: a time stamp.

After the source subnet node within the source blockchain subnet a monitors the event, the event is signed by invoking the SM message component at Signature Message layer (message signature layer) to authenticate the identity of the source subnet node. The node_id field is used for storing a node identifier of the source subnet node, the msg field is used for storing the field contained in the monitored event, and the sign field is used for storing signature data obtained by signing the content stored in the mag field by the source subnet node by adopting a node private key of the source subnet node.

The data obtained in the layer Signature Message is encrypted in a digital Envelope mode by calling an Envelope Message component in the layer Envelope Message (Message Envelope). Specifically, the source subnet node in the source blockchain subnet a may randomly generate a symmetric key K used by itself (each source subnet node may use the same or different symmetric keys), and then encrypt the contents of the node_id field, the msg field and the sign field by using the symmetric key K, and store the encrypted contents in the encryption_data field. Meanwhile, in a Subnet system contract deployed by the blockchain main network Subnet 0, node public keys of Subnet nodes in each blockchain Subnet are maintained. Therefore, the source Subnet node in the source blockchain Subnet a can query the node public key of each Subnet node in the Subnet b maintained in the Subnet system contract through the Subnet identification of the destination blockchain Subnet b, and then encrypt the symmetric key used by itself by using each node public key to obtain a plurality of symmetric keys en_ke1, en_ke2, en_ke3, and the like (in the figure, the destination blockchain Subnet b contains 3 destination Subnet nodes as an example) respectively, and store the symmetric keys in the encrypted_key field.

And encapsulating the data obtained by the Envelope Message layer into a cross-subnet request by calling a P2P Message component at a P2P Message layer. Specifically, the contents of the encrypted_key field and the encrypted_data field are stored into the data field. Meanwhile, the cross-subnet request also contains the following fields:

src_subnet_id: representing a source blockchain subnet identification;

dest_subnet_id: representing a destination blockchain subnet identification;

msg_type: a request type identification representing a request across subnets.

Meanwhile, in a Subnet system contract deployed in the blockchain main network Subnet 0, address information such as an IP address, a port number and the like of a Subnet node in each blockchain Subnet is maintained. Therefore, the source Subnet node in the source blockchain Subnet a can query the address information of each Subnet node in the Subnet b maintained in the Subnet system contract through the Subnet identification of the target blockchain Subnet b, so that after generating the Subnet crossing request, the Subnet crossing request is sent to each Subnet node in the target blockchain Subnet b according to the address information. Of course, the request of crossing the subnets can also be broadcast, and the receiver judges whether the receiver needs to respond to the received request of crossing the subnets according to the dest_subnet_id field.

Similarly, the subnet node in the target block chain subnet b is used as the target subnet node, and the received cross-subnet request is processed in each layer in turn. The destination subnet node adopts the private key of the destination subnet node to decrypt the symmetric keys in each ciphertext form stored in the encrypted_key field, the symmetric key encrypted by the public key of the destination subnet node can be successfully decrypted, and then the block chain message stored in the encrypted_data field is decrypted through the symmetric key which is successfully decrypted, so that the contents of the node_id field, the msg field and the sign field are obtained. At this point, the validity of the source subnet node and the validity of the signature may be checked. For example, node identification and node public key of each Subnet node within the corresponding blockchain Subnet maintained in the Subnet system contract may be queried based on the src_subnet_id of the cross-Subnet request. And then judging whether the inquired node identification contains the node identification stored in the node_id field, and judging that the validity check of the source subnet node passes when the inquired node identification contains the node identification stored in the node_id field. And then, checking the signature stored in the sign field by adopting a node public key corresponding to the node identifier stored in the node_id field, so as to judge that the signature verification of the source subnet node passes under the condition that the signature verification passes. After the validity of the source subnet node and the validity of the signature are checked, the contents stored in the msg field can be read to respond. For example, corresponding operations are executed according to the indication of the content stored in the method field and the args field, the data to be processed required by the intelligent contract is read, and then the data to be processed is returned to the sender of the received cross-chain request. It should be noted that, in the process of returning the data to be processed, the subnet b is used as the source blockchain subnet, the subnet a is used as the destination blockchain subnet, and the process of cross-chain interaction is similar to the above, and will not be repeated here.

Therefore, in the cross-subnet interaction process based on the blockchain main network, identity verification is carried out on the source subnet node by utilizing the hierarchical relation of the source blockchain subnet and the target blockchain subnet corresponding to the same blockchain main network, other additional components (such as data interaction between two subnets realized by using a cross-chain relay mode, a notary mode and the like and additional configuration components) are not needed, the characteristic of the hierarchical relation is fully utilized in the verification process, and the target subnet node only needs to directly query the blockchain main network for node identity information of the source subnet node, so that the verification operation is simpler, lighter and more efficient on the premise of accurately verifying the identity of the source subnet node to ensure the data security.

Further, taking the response result as the to-be-processed data of the intelligent contract as an example, after the source blockchain subnet obtains the to-be-processed data returned by the target blockchain network, a main node in the source blockchain subnet can initiate a second blockchain transaction containing the to-be-processed data in the source blockchain subnet, and the second blockchain transaction is used for calling the intelligent contract. Then, a consensus is initiated in the source blockchain subnetwork, and in the event that the second blockchain transaction passes the consensus, a source subnetwork node in the source blockchain subnetwork executes a smart contract to process the data to be processed in response to the second blockchain transaction.

And after determining the user identification card number returned by the target blockchain sub-network through fault tolerance verification, initiating a blockchain transaction containing the identification card number in the source blockchain sub-network by a main node in the source blockchain sub-network, wherein the blockchain transaction is used for calling the service contract. And then, a consensus is initiated in the source block chain sub-network, and under the condition that the block chain transaction passes through the consensus, each source sub-network node in the source block chain sub-network responds to the block chain transaction and executes a business contract to finish member registration according to the identification card number.

It should be noted that the above embodiment in which each source subnet node sends a cross-link request to each destination subnet node separately is merely an exemplary example for cross-link interaction. For example, the above-mentioned cross-chain interaction can also be accomplished by the master node of the source blockchain subnet and the master node of the destination blockchain network; alternatively, the above-mentioned cross-chain interaction may also be accomplished by each source subnet node of the source blockchain subnet with a master node of the destination blockchain network; alternatively, the above-described cross-chain interactions may also be accomplished by a master node of the source blockchain subnetwork with each destination node of the destination blockchain network, and so on; the present description is not limited thereto.

FIG. 8 is a schematic block diagram of a blockchain system provided by an exemplary embodiment. As shown in fig. 8, the blockchain system includes:

a source blockchain network 81, source blockchain link points in the source blockchain network 81 for respectively initiating a cross-chain request to a plurality of destination blockchain nodes in the destination blockchain network 82; and respectively receiving response results returned by the target blockchain nodes for the cross-chain request, and carrying out Bayesian fault-tolerant verification on the received response results according to the node numbers of the target blockchain nodes so as to take the response results passing the Bayesian fault-tolerant verification as the response results of the target blockchain network for the cross-chain request.

And the destination block chain network 82, wherein a plurality of destination block chain link points in the destination block chain network 82 are used for respectively responding to the cross-chain request, generating a response result aiming at the cross-chain request, and returning the respectively generated response result to the source block chain link points.

Optionally, the source blockchain link points in the source blockchain network 81 initiate a cross-chain request to a plurality of destination blockchain nodes in the destination blockchain network 82, respectively, including:

at least one source blockchain node in the source blockchain network 81 initiates the cross-chain request to the plurality of destination blockchain nodes, respectively;

Performing a bayer fault-tolerant check on the received response result according to the node numbers of the plurality of destination blockchain nodes, including: the at least one source block link point sends the received response results to a master node of the source block chain network 81, the master node obtains the response results from all destination block chain nodes, and the bayer fault-tolerant verification is performed on the obtained response results according to the number of the nodes.

Optionally, the master node comprises a master node selected by a consensus algorithm employed by the source blockchain network 81.

Optionally, the source blockchain network 81 includes a blockchain sub-network corresponding to a blockchain main network, the blockchain main network maintaining node identity information of each node in the source blockchain network 81, the cross-chain request including identification information for characterizing node identities of the source blockchain nodes; the method further comprises the steps of:

and the target blockchain nodes respectively query the blockchain main network for node identity information of the source blockchain node so as to verify the identity information, and respond to the cross-chain request under the condition that verification is passed.

Optionally, the destination blockchain network 82 includes a blockchain subnetwork built based on the blockchain main network.

Optionally, the node device for deploying the main network node in the blockchain main network is used for deploying the sub-network node of the blockchain sub-network, and the main network node and the sub-network node deployed on any node device share the blockchain plugin of the any node device; the plurality of destination blockchain nodes respectively query the blockchain main network for node identity information of the source blockchain node, including:

and the plurality of target blockchain nodes read the node identity information of the source blockchain node maintained by the main network node deployed by the target node equipment through the blockchain plugin deployed by the target node equipment.

Optionally, the destination blockchain network 82 includes a blockchain subnetwork registered with the blockchain main network.

Optionally, the querying, by the multiple destination blockchain nodes, node identity information of the source blockchain node from the blockchain main network includes:

and the plurality of target blockchain nodes respectively submit query transactions to the blockchain main network, wherein the query transactions are used for indicating the blockchain main network to query the node identity information of the source subnet node.

Optionally, the source blockchain network 81 is built based on the blockchain master network; alternatively, the source blockchain network 81 is a blockchain subnetwork registered with the blockchain main network.

Optionally, a subnet management contract is deployed on the blockchain main network, and the subnet management contract is used for maintaining node identity information of subnet nodes in each blockchain subnet corresponding to the blockchain main network; the plurality of destination blockchain nodes respectively query the blockchain main network for node identity information of the source blockchain node, including:

and the plurality of target blockchain nodes respectively read the node identity information of the source blockchain node maintained by the subnet management contract.

Optionally, the identification information includes a node identifier of the source block link point statement and a subnet identifier of the affiliated block link subnet; the plurality of destination blockchain nodes respectively query the blockchain main network for node identity information of the source blockchain node to verify the identity information, including:

the plurality of target blockchain nodes respectively inquire whether node identifiers stated by the source blockchain link points are matched with subnet identifiers or not from the blockchain main network.

Optionally, the identification information includes a signature generated by the source block link point based on a node private key of the source block link point; the plurality of destination blockchain nodes respectively query the blockchain main network for node identity information of the source blockchain node to verify the identity information, including:

and the plurality of target blockchain nodes respectively inquire the public key of the source blockchain node from the blockchain main network, and adopt the public key of the node to check the signature.

Optionally, the method further comprises:

the source block chain link point encrypts a block chain message to be transmitted by adopting a symmetric key, and adds the encrypted block chain message to the cross-chain request;

and the source block chain link point encrypts the symmetric key by adopting a node public key of each node in the plurality of target block chain nodes respectively, and adds each symmetric key obtained by encryption into the cross-chain request.

Optionally, the method further comprises:

the source blockchain point executes a smart contract deployed on the source blockchain network 81 in response to invoking a first blockchain transaction of the smart contract to create a blockchain message for addition to the cross-chain request, the blockchain message being used to instruct the destination blockchain network 82 to return pending data of the smart contract.

Optionally, the method further comprises:

a master node in the source blockchain network 81 initiates a second blockchain transaction containing the data to be processed within the source blockchain network 81, the second blockchain transaction for invoking the intelligent contract;

in the event that a second blockchain transaction passes a consensus, the source blockchain link point in the source blockchain network 81 executes the smart contract to process the pending data in response to the second blockchain transaction.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

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

The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.

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

The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.

Claims

1. A cross-chain interaction method, comprising:

source block chain link points in a source block chain sub-network managed by a block chain main network respectively initiate a cross-chain request to a plurality of target block chain nodes in a target block chain sub-network managed by the block chain main network; the system comprises a source block chain sub-network, a target block chain sub-network, a block chain plug-in and a block chain plug-in, wherein the block chain main network maintains node identity information of each node in the source block chain sub-network, the cross-chain request comprises identification information used for representing the node identity of the source block chain node, the target block chain sub-network comprises a block chain sub-network constructed based on the block chain main network, node equipment for deploying the main network node in the block chain main network is also used for deploying the sub-network node of the block chain sub-network, and the main network node and the sub-network node deployed in any node equipment share the block chain plug-in of any node equipment;

the source block chain link points respectively receive response results returned by the plurality of target block chain nodes, and perform Bayesian fault-tolerant verification on the received response results according to the node numbers of the plurality of target block chain nodes, so that the response results passing the Bayesian fault-tolerant verification are used as response results of the target block chain sub-network for the cross-chain request;

and the target block chain nodes read the node identity information of the source block chain node maintained by the main network node deployed by the target node equipment through the block chain plug-in units in the target node equipment deployed by the target node equipment so as to verify the identity information, and respond to the cross-chain request under the condition that the verification is passed.

2. The method according to claim 1,

the source block link point in the source block chain sub-network initiates a cross-chain request to a plurality of destination block chain nodes in a destination block chain sub-network, respectively, comprising:

At least one source blockchain node in the source blockchain subnetwork respectively initiates the cross-chain request to the plurality of destination blockchain nodes;

the performing the bayer fault-tolerant check on the received response result according to the node numbers of the plurality of destination blockchain nodes includes: and the at least one source block chain link point respectively sends the received response results to a main node of the source block chain sub-network, the main node obtains the response results from all target block chain nodes, and the Bayesian fault-tolerant verification is carried out on the obtained response results according to the number of the nodes.

3. The method of claim 2, the master node comprising a master node selected by a consensus algorithm employed by the source blockchain subnetwork.

4. The method of claim 1, the destination blockchain subnetwork comprising a blockchain subnetwork registered with the blockchain main network.

5. The method of claim 4, the plurality of destination blockchain nodes querying the blockchain master network for node identity information of the source blockchain node, respectively, comprising:

and the target blockchain nodes respectively submit query transactions to the blockchain main network, wherein the query transactions are used for indicating the blockchain main network to query the node identity information of the source blockchain node.

6. The method of claim 1, the identification information comprising a node identification of the source blockchain point declaration and a subnet identification of the affiliated blockchain subnet; the plurality of destination blockchain nodes respectively query the blockchain main network for node identity information of the source blockchain node to verify the identity information, including:

7. The method of claim 1, the identification information comprising a signature generated by the source block link point based on its own node private key; the plurality of destination blockchain nodes respectively query the blockchain main network for node identity information of the source blockchain node to verify the identity information, including:

8. The method of claim 1, wherein a subnet management contract is deployed on the blockchain main network, the subnet management contract being configured to maintain node identity information of subnet nodes in each blockchain subnet managed by the blockchain main network; the plurality of destination blockchain nodes respectively query the blockchain main network for node identity information of the source blockchain node, including:

9. The method of claim 1, the blockchain main network maintaining node identity information for each node in the destination blockchain subnetwork; the method further comprises the steps of:

and the source blockchain node queries the blockchain main network for node identity information of each node in the target blockchain sub network to determine the node number of the plurality of target blockchain nodes.

10. The method of claim 9, wherein a subnet management contract is deployed on the blockchain main network, the subnet management contract being configured to maintain node identity information of subnet nodes in each blockchain subnet managed by the blockchain main network; the source blockchain node querying the blockchain main network for node identity information of each node in the destination blockchain subnetwork, including:

and the source block chain link point reads node identity information of each node in the target block chain subnet maintained by the subnet management contract.

11. The method of claim 1, further comprising:

12. The method of claim 1, further comprising:

the source blockchain link point executes a smart contract deployed at the source blockchain subnet in response to invoking a first blockchain transaction of the smart contract to create a blockchain message for addition to the cross-chain request, the blockchain message being used to instruct the destination blockchain subnet to return pending data of the smart contract.

13. The method of claim 12, further comprising:

a master node in the source blockchain subnet initiates a second blockchain transaction containing the data to be processed in the source blockchain subnet, wherein the second blockchain transaction is used for calling the intelligent contract;

in the event that a second blockchain transaction passes a consensus, a source blockchain link point in the source blockchain subnet executes the smart contract to process the pending data in response to the second blockchain transaction.

14. A blockchain system, comprising:

A source blockchain sub-network managed by a blockchain main network, wherein source blockchain link points in the source blockchain sub-network are used for respectively initiating a cross-chain request to a plurality of target blockchain nodes in a target blockchain sub-network managed by the blockchain main network; the method comprises the steps of receiving response results returned by a plurality of target block chain nodes for the cross-chain request respectively, and carrying out Bayesian fault-tolerant verification on the received response results according to the node number of the target block chain nodes so as to take the response results passing the Bayesian fault-tolerant verification as response results of a target block chain sub-network for the cross-chain request; the system comprises a source block chain sub-network, a target block chain sub-network, a block chain plug-in and a block chain plug-in, wherein the block chain main network maintains node identity information of each node in the source block chain sub-network, the cross-chain request comprises identification information used for representing the node identity of the source block chain node, the target block chain sub-network comprises a block chain sub-network constructed based on the block chain main network, node equipment for deploying the main network node in the block chain main network is also used for deploying the sub-network node of the block chain sub-network, and the main network node and the sub-network node deployed in any node equipment share the block chain plug-in of any node equipment;

The target block chain sub-network managed by the block chain main network is used for responding to the cross-chain request respectively by a plurality of target block chain link points in the target block chain sub-network, generating a response result aiming at the cross-chain request and returning the generated response result to the source block chain link points respectively; and reading node identity information of the source blockchain node maintained by a main network node deployed by target node equipment through a blockchain plugin the target node equipment of each target blockchain node, so as to verify the identity information, and responding to the cross-chain request under the condition that verification is passed.