CN114285755A

CN114285755A - Cross-subnet interaction method and device, electronic equipment and storage medium

Info

Publication number: CN114285755A
Application number: CN202111663446.9A
Authority: CN
Inventors: 陶友贤
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-12-31
Filing date: 2021-12-31
Publication date: 2022-04-05
Also published as: WO2023124744A1

Abstract

The present specification provides a cross-subnet interaction method, apparatus, electronic device, and storage medium, wherein the method is applied to a first subnet node that maintains a subnet topology structure of a first blockchain subnet, network delay information corresponding to the subnet topology structure, and a node deployment situation on a node device where a subnet node in the first blockchain subnet is located; the method comprises the following steps: acquiring a message to be forwarded to a target block chain subnet; under the condition that the subnet nodes in the target zone chain subnet are not deployed on the node device where the first subnet node is located, determining a forwarding path with the minimum total delay between the first subnet node and the subnet nodes in the target zone chain subnet from the subnet topological structure based on network delay information, and forwarding a message to be forwarded to a second subnet node in the first zone chain subnet serving as a next hop on the determined forwarding path, otherwise, forwarding the message to be forwarded to the subnet nodes in the target zone chain subnet.

Description

Cross-subnet interaction method and device, electronic equipment and storage medium

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a cross-subnet interaction method and device, electronic equipment and a storage medium.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people. In some blockchain networks, there is sometimes a need for some nodes to implement small-scale transactions to avoid other nodes from obtaining these transactions and their associated data. Therefore, the block chain sub-network can be further established on the basis of the block chain main network.

However, since different blockchain subnets are isolated from each other, when a certain blockchain subnet receives a message that is to be sent to another blockchain subnet, how to efficiently route the message to a target blockchain subnet to which the message is to be sent is an urgent technical problem to be solved.

Disclosure of Invention

The invention aims to provide a cross-subnet interaction method, a cross-subnet interaction device, electronic equipment and a storage medium.

According to a first aspect of one or more embodiments of the present specification, a cross-subnet interaction method is provided, which is applied to a first subnet node in a first blockchain subnet in a blockchain system, where the blockchain system includes a blockchain master network and a blockchain subnet managed by the blockchain master network; the first subnet node maintains a subnet topology structure of the first blockchain subnet, network delay information corresponding to the subnet topology structure and a node deployment condition on node equipment where the subnet node in the first blockchain subnet is located; the method comprises the following steps:

acquiring a message to be forwarded to a target block chain subnet;

under the condition that the subnet nodes in the target block chain subnet are not deployed on the node device where the first subnet node is located, determining a forwarding path with the minimum total delay between the first subnet node and the subnet nodes in the target block chain subnet from the subnet topological structure based on the network delay information, and forwarding the message to be forwarded to a second subnet node in the first block chain subnet serving as a next hop on the determined forwarding path;

and forwarding the message to be forwarded to the subnet node in the target block chain subnet under the condition that the subnet node in the target block chain subnet is deployed on the node device where the first subnet node is located.

According to a second aspect of one or more embodiments of the present specification, a cross-subnet interaction device is provided, which is applied to a first subnet node in a first blockchain subnet in a blockchain system, where the blockchain system includes a blockchain master network and a blockchain subnet managed by the blockchain master network; the first subnet node maintains a subnet topology structure of the first blockchain subnet, network delay information corresponding to the subnet topology structure and a node deployment condition on node equipment where the subnet node in the first blockchain subnet is located; the device comprises:

the message acquisition unit is used for acquiring a message to be forwarded which needs to be forwarded to a target block chain subnet;

a path forwarding unit, configured to, when it is determined that the subnet node in the target blockchain subnet is not deployed on the node device where the first subnet node is located, determine, based on the network delay information, a forwarding path with a minimum total delay between the first subnet node and the subnet node in the target blockchain subnet from the subnet topology, and forward the message to be forwarded to a second subnet node in the first blockchain subnet serving as a next hop on the determined forwarding path;

and the node forwarding unit is used for forwarding the message to be forwarded to the subnet node in the target blockchain subnet under the condition that the subnet node in the target blockchain subnet is deployed on the node device where the first subnet node is located.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic apparatus including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any of the first aspects by executing the executable instructions.

According to a fourth aspect of one or more embodiments of the present description, there is provided a computer-readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to any one of the first aspect.

In the above embodiment, the first subnet node in the first blockchain subnet determines, through the subnet topology of the first subnet node maintained by the first subnet node, the network delay information, and the node deployment situation on the node device where the subnet node in the first blockchain subnet is located, a forwarding path with the minimum total delay between the first subnet node and the subnet node in the target blockchain subnet is determined under the condition that the message to be forwarded to the target blockchain subnet is received, and transmits the message to be forwarded to the second subnet node of the next hop on the determined forwarding path in the form of rerouting forwarding, and then gradually transmits the message to the node device where the subnet node of the target blockchain subnet is deployed by the second subnet node. On one hand, the message which is wrongly routed to the first block chain sub-network can be redirected to the target block chain network to which the message needs to go, so that accidental events of message sending errors in a block chain system consisting of the block chain main network and the block chain sub-network managed by the block chain main network are avoided to a certain extent, and the block chain system is more reliable; on the other hand, because the first subnet node maintains the network delay information corresponding to the subnet topology structure, the message to be forwarded can be ensured to be forwarded through the forwarding path with the minimum total delay, and the forwarding efficiency of the message to be forwarded is optimized.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.

Fig. 1 is a schematic diagram of building a blockchain subnet based on a blockchain master network according to an exemplary embodiment.

Fig. 2 is a flow chart of a method of interacting across subnets, provided by an exemplary embodiment.

Fig. 3 is a schematic diagram of a subnet topology provided by an exemplary embodiment.

Fig. 4 is a schematic structural diagram of an apparatus according to an exemplary embodiment.

Fig. 5 is a block diagram of an apparatus interacting across subnets, provided in an exemplary embodiment.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

Due to the decentralized characteristic of the blockchain network, all blockchain nodes in the blockchain network can maintain the same blockchain data, and the special requirements of part of nodes cannot be met. Taking a federation chain as an example, all federation members (i.e., node members in a federation) may form a blockchain network, and all federation members respectively have corresponding blockchain nodes in the blockchain network, and may obtain all transactions and related data occurring on the blockchain network through the corresponding blockchain nodes. In some cases, however, there may be some security-required transactions that some coalition members wish to complete, which may both wish to be able to verify on the blockchain or to take advantage of other advantages of blockchain technology, and avoid other coalition members from viewing the transactions and associated data. Although the federating members can additionally build a new blockchain network in a manner similar to the blockchain network including all federating members described above, the new blockchain network is built from scratch, which consumes a lot of resources and is time-consuming in both the building process and the post-building configuration process. The demand between the members of the federation is often temporary or has a certain timeliness, so that the newly-built blockchain network can quickly lose significance due to the disappearance of the demand, thereby further increasing the link establishment cost of the blockchain network. The demands among the federation members often change, and the federation members corresponding to each demand often differ, so that a new blockchain network may need to be established whenever a change occurs in a federation member, thereby causing a great waste of resources and time.

For this purpose, the established blockchain network may be used as a blockchain master network, and a blockchain sub-network may be established on the basis of the blockchain master network. Then, in a federation chain scenario such as that described above, federation members can build the required blockchain subnets on a blockchain master basis based on their own needs, already participating in the blockchain master. Because the block chain sub-networks are established on the basis of the block chain main network, compared with the process of completely and independently establishing a block chain network, the block chain sub-networks are greatly reduced in consumed resources, required time consumption and the like, and are extremely high in flexibility.

The process of quickly establishing the block chain sub-network based on the block chain main network comprises the following steps: each block link point in a block chain main network respectively acquires a transaction for establishing a block chain sub-network, the transaction comprises configuration information of the block chain sub-network, the configuration information comprises identity information of node members participating in establishing the block chain sub-network, each block link point in the block chain main network respectively executes the transaction to reveal the configuration information, and when the configuration information comprises identity information of a node member corresponding to a first block link point, node equipment for deploying the first block chain node starts a second block chain node belonging to the block chain sub-network based on an innovation block comprising the configuration information.

For example, as shown in fig. 1, the main network of the blockchain is subnet0, and the subnet0 includes blockchain link points nodeA, nodeB, nodeC, nodeD, and nodeE. Assume nodeA, nodeB, nodeC, and nodeD wish to build a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to build a blockchain subnet, the transaction to build the blockchain subnet can be initiated by nodeA to subnet 0; if the nodeb is an administrator and only the administrator is allowed to initiate a transaction for building the blockchain subnet, nodeb a to nodeb d need to make a request to nodeb, so that nodeb initiates the transaction for building the blockchain subnet to subnet 0; if nodeE is an administrator but allows a normal user to initiate a transaction for building a blockchain subnet, nodeA-nodeE can both initiate the above transaction for building the blockchain subnet to subnet 0. Of course, the blockchain link point initiating the transaction for building the blockchain subnet does not necessarily participate in the built blockchain subnet, whether it is an administrator or a general user, for example, although the blockchain subnet is finally built by nodeA, nodeB, nodeC and nodeD, the transaction for building the blockchain subnet may be initiated by nodeE to subnet0, but the transaction for building the blockchain subnet is not necessarily initiated by nodeA to nodeD.

When the blockchain sub-network is constructed on the basis of the blockchain main network, it is easy to understand that a logical hierarchical relationship exists between the blockchain sub-network and the blockchain main network. For example, when building a blockchain subnet1 on subnet0 shown in fig. 1, subnet0 may be considered to be at a first level and subnet1 may be considered to be at a second level. In one case, the blockchain main network in this specification may be an underlying blockchain network, that is, the blockchain main network is not a blockchain sub-network constructed on the basis of other blockchain networks, for example, the subnet0 in fig. 1 may be regarded as a blockchain main network belonging to the underlying blockchain network type. In another case, the blockchain main network in this specification may also be a subnet of another blockchain network, for example, another blockchain subnet may be further configured on the basis of the subnet1 in fig. 1, and at this time, the subnet1 may be considered as the blockchain main network corresponding to the blockchain subnet, and this does not affect that the subnet1 belongs to the blockchain subnet created on the subnet0 at the same time. It can be seen that the blockchain main network and the blockchain sub-network are actually relative concepts, and the same blockchain network may be the blockchain main network in some cases and the blockchain sub-network in other cases.

After the transaction for establishing the blockchain sub-network is sent to the blockchain main network, the consensus nodes in the blockchain main network perform consensus, and after the consensus is passed, each main network node executes the transaction to complete establishment of the blockchain sub-network. The consensus process depends on the consensus mechanism employed, which is not limited by this specification.

The configuration information is included in the transaction of the block chain sub-network, and the configuration information can be used for configuring the block chain sub-network, so that the block chain sub-network meets networking requirements. For example, by including the identity information of the node members in the configuration information, it is possible to specify which blockchain nodes the constructed blockchain subnet includes.

The identity information of the node member may include a public key of the node, or other information capable of representing the node identity, 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 corresponding sets of public-private key pairs, and the private key is held by the blockchain node and the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Therefore, for blockchain nodes that are desired to be node members of a blockchain subnet, the public keys of these blockchain nodes can be added to the transaction of the building blockchain subnet as the identity information of the node members. The public and private key pair described above may be used in the process of signature verification. For example, in a signed consensus algorithm, such as the sub net1, the above-mentioned nodeA1 signs a message with its own private key, and broadcasts the signed message in the sub net1, while nodeB1, nodeC1 and nodeD1 can verify that the received message is signed with the public key of nodeA1 to confirm that the received message is indeed from nodeA1 and has not been tampered with.

The first master network node may be a blockchain node on the blockchain master network that belongs to a node member indicated by the configuration information. When the blockchain subnet is constructed, the first master network node does not directly participate in the construction of the blockchain subnet and becomes a node member thereof, but the first subnet node needs to be generated by the node device for deploying the first master network node and becomes a node member in the blockchain subnet by the first subnet node. The first main network node and the first sub-network node correspond to the same blockchain member, for example, correspond to the same alliance chain member in an alliance chain scene, but the first main network node belongs to a blockchain main network and the first sub-network node belongs to a blockchain sub-network, so that the blockchain member can participate in the transaction of the blockchain main network and the blockchain sub-network respectively; moreover, because the blockchain main network and the blockchain sub-network belong to two mutually independent blockchain networks, the blocks generated by the first main network node and the blocks generated by the first sub-network node are respectively stored in different storages (the adopted storages can be databases, for example) on the node device, so that mutual isolation between the storages used by the first main network node and the first sub-network node respectively is realized, and thus, data generated by the blockchain sub-network can only be synchronized among the node members of the blockchain sub-network, so that the blockchain members only participating in the blockchain main network cannot obtain the data generated by the blockchain sub-network, the data isolation between the blockchain main network and the blockchain sub-network is realized, and the transaction requirements between partial blockchain members (namely, the blockchain members participating in the blockchain sub-network) are met.

It can be seen that the first master network node and the first sub-network node are logically divided block chain link points, and from the perspective of physical devices, the node devices which are equivalent to the first master network node and the first sub-network node are deployed to participate in both the block chain master network and the block chain sub-network. Since the blockchain main network and the blockchain sub-network are independent from each other, so that the identity systems of the two blockchain networks are also independent from each other, even though the first main network node and the first sub-network node may adopt the same public key, the first main network node and the first sub-network node should be regarded as different blockchain nodes. For example, in fig. 1, the nodeA in subnet0 corresponds to a first master network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to a first sub-network node. It can be seen that, since the identity systems are independent of each other, even if the public key adopted by the first subnet node is different from that of the first master network node, the implementation of the solution in this specification is not affected.

Of course, the node members of the blockchain sub-network are not necessarily only part of the node members of the blockchain main network. In some cases, the node members of the blockchain subnet may be completely consistent with the node members of the blockchain main network, and at this time, all the blockchain members may obtain data on the blockchain main network and the blockchain subnet, but data generated by the blockchain main network and the blockchain subnet may still be isolated from each other, for example, one type of service may be implemented on the blockchain main network, and another type of service may be implemented on the blockchain subnet, 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 identifier of the blockchain subnet, the identity information of an administrator of the blockchain subnet, the attribute configuration for the blockchain platform code, and the like, which are not limited in this specification. The network identifier is used to uniquely characterize the blockchain subnet, and thus the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets established on the blockchain main network. Identity information of an administrator of the blockchain subnet, such as a public key of a node member as 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 building the blockchain subnet by using the blockchain master network is that since the first master network node is already deployed on the node device generating the first subnet node, the blockchain platform code used by the first master network node can be multiplexed on the first subnet node, so that repeated deployment of the blockchain platform code is avoided, and the building efficiency of the blockchain subnet is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node may reuse the attribute configuration adopted on the first master network node; if the configuration information includes the attribute configuration for the blockchain platform code, the first subnet node may adopt the attribute configuration, so that the attribute configuration adopted by the first subnet node is not limited by the attribute configuration of the first main network node and is not related to the first main network node. The attribute configuration for blockchain platform code may include at least one of: code version number, whether consensus is required, type of consensus algorithm, block size, etc., which is not limited in this specification.

The transactions that make up the blockchain subnet include transactions that invoke contracts. The address of the invoked smart contract, the method invoked and the incoming parameters may be specified in the transaction. For example, the contract invoked may be the aforementioned startup contract or system contract, the method invoked may be a method that builds a blockchain subnet, and the incoming parameters may include the configuration information described above. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

the from field is information of the initiator of the transaction, such as administeror indicating that the initiator is an Administrator; the to field is the address of the intelligent contract being called, for example, the intelligent 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 in the Subnet contract to build the blockchain Subnet may be AddSubnet (string), and string is a parameter in the AddSubnet () method, and the value of the parameter is represented by the aforementioned example, which is specifically the aforementioned configuration information.

Take the example that nodes nodeA-nodeE on Subnet0 execute a transaction that invokes the AddSubnet () method in the Subnet contract. After the transaction passes the consensus, nodeA-nodeE respectively execute the AddSubnet () method and transmit configuration information to obtain corresponding execution results.

After executing a transaction that invokes a 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 contract execution results may be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in the receipt. The message mechanism can implement message passing through events in the receipt to trigger the blockchain node to execute corresponding processing. The structure of the event may be, for example:

Event：

[topic][data]

......

in the above example, the number of events may be one or more; wherein, each event respectively comprises fields of a subject (topic) and data (data). The tile chain node may perform the preset process by listening to topic of the event, in case that predefined topic is listened to, 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, it is equivalent to that there is a client with a monitoring function at a monitoring party (e.g. a user with a monitoring requirement), for example, an SDK or the like for implementing the monitoring function is run on the client, and the client monitors events generated by the blockchain node, and the blockchain node only needs to generate a receipt normally. The passage of transaction information may be accomplished in other ways than through the event mechanism described above. For example, the monitoring code can be embedded in a blockchain platform code running at blockchain nodes, so that the monitoring code can monitor one or more data of transaction content of blockchain transactions, contract states of intelligent contracts, receipts generated by contracts and the like, and send the monitored data to a predefined monitoring party. Since the snoop code is deployed in the blockchain platform code, rather than at the snooper's client, this implementation based on snoop code is relatively more proactive than the event mechanism. The above monitoring code may be added by a developer of the blockchain platform in the development process, or may be embedded by the monitoring party based on the own requirement, which is not limited in this specification.

It can be seen that the execution result of the Subnet contract may include the configuration information, and the execution result may be in the receipt as described above, and the receipt may contain the event related to the execution of the AddSubnet () method, i.e., the networking event. The topoc of a networking event may contain a predefined networking event identification to distinguish it from other events. For example, in an event related to the execution of the AddSubnet () method, the content of topic is a keyword subnet, and the keyword is distinguished from topic in the event generated by other methods. Then, nodeb to nodeb can determine to listen to an event related to execution of the AddSubnet () method, that is, a networking event, by listening to topic included in each event in the generated receipt, in the case where topic including the keyword subnet is listened to. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

then, when nodeA-nodeE monitor 1 st event, because the contained topoic content is other, it is determined that the event is irrelevant to the AddSubnet () method; and when the 2 nd event is monitored, because the contained topic content is subnet, determining that the event is related to the AddSubnet () method, and further reading the 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；

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

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

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

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

}

where subnet1 is the network identification of the blockchain subnet that one wishes to create. Each blockchain link point in the blockchain master network may record network identifiers 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 the Subnet contract, for example, and may specifically correspond to values of one or more contract states included in the Subnet contract. Then, nodeA to nodeE may determine whether the subnet1 already exists according to the recorded network identifiers of all the blockchain subnets that have been created; if not, subnet1 is the new blockchain subnet that needs to be created currently, and if so, subnet1 is already present.

In addition to the network identifier of the new blockchain subnet that is desired to be created, a predefined new network identifier may be used, which indicates that the corresponding networking event is used to create the new blockchain subnet. For example, the subnet1 may be replaced by newsbnet, where newsbnet is a predefined new network identifier, and when the nodeA-nodeE recognizes that the data field includes newsbnet, it may be determined that the event including newsbnet is a networking event and a new blockchain subnet needs to be created.

Besides the network identification subnet1, the data field also contains the identity information of each node member. The node device deploying the first master network node may monitor the generated receipt, and obtain, by the node device deploying the first master network node, configuration information or an innovation block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first master network node belongs to the node member. Or the first block link point may monitor the generated receipt, and trigger the node device deploying the first block link node to acquire the configuration information or the created block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first block link point belongs to the node member.

As previously described, the node device may listen for receipts directly. Assuming that nodeA-nodeE are respectively deployed on the node devices 1-5, and the node devices 1-5 can monitor receipts respectively generated by the nodeA-nodeE, under the condition that the subnet1 is monitored to be a block chain subnet needing to be newly established, the node devices 1-5 further identify the identity information of the node members contained in the data field to determine the processing mode of the node devices. Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as a public key, an IP address, and a port number of nodeA, node device 1 generates a created block containing configuration information when obtaining the configuration information from the data field based on the above-mentioned message mechanism, and node device 1 deploys nodeA1 locally, and further loads the generated created block by nodeA1, thereby becoming a subnet node of subnet 1; similarly, node device 2 may generate nodeB1, node device 3 may generate nodeB c1, and node device 4 may generate nodeB 1. And if the node device 5 finds that the identity information included in the data field does not match with itself, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a block link point in subnet 1.

As mentioned above, the blockchain link point in the blockchain master network can listen for the receipt and trigger the node device to perform the relevant processing according to the listening result. For example, when determining that subnet1 is a blockchain subnet that needs to be newly built, nodeA to nodeE further identify the identity information of the node members included in the data field to determine their own processing methods. For example, nodeA-nodeD may find that the data field includes identity information such as their own public key, IP address, and port number, assuming nodeA-nodeD are respectively deployed on node devices 1-4, taking nodeA and node device 1 as an example: the nodeA triggers the node device 1, so that the node device 1 obtains the configuration information from the data field based on the message mechanism and generates a created block containing the configuration information, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated created block, so that the node device 1 becomes 1 subnet node in the subnet 1; similarly, nodeB will trigger NodeB1 to be generated by node device 2, nodeC will trigger NodeC1 to be generated by node device 3, and nodeD will trigger NodeD1 to be generated by node device 4. And the nodeE finds that the identity information contained in the data field is not matched with the nodeE, and if the nodeE is deployed on the node device 5, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a node in the subnet 1.

As mentioned above, the first master network node and the first subnet node do not necessarily adopt the same identity information. Therefore, in the above embodiment, the data field may include the identity information generated in advance for nodeA 1-nodeD 1, and be distinguished from the identity information of nodeA-nodeD. Taking nodeA and node device 1 as an example: if identity information of nodeA1 is found in the data field, node device 1 may generate a founding block, deploy nodeA1, and load the founding block by nodeA 1; alternatively, nodeA, if identity information of nodeA1 is found in the data field, will trigger node device 1 to generate a foundational block, deploy nodeA1, and load the foundational block by nodeA 1. The processing modes of other blockchain nodes or node devices are similar, and are not described in detail herein.

In addition to configuration information, the execution results of the contract may include a foundational block. In other words, in addition to including the configuration information in the data field, the created block including the configuration information may be generated directly in the process of executing the contract call, so that the created block is included in the data field, and then for the nodeA to nodeD described above, the corresponding node devices 1 to 4 may obtain the created block directly from the data field through a message mechanism without self-generation, and the deployment efficiency of nodeA1 to nodeD1 may be improved.

The node device realizes the deployment of a blockchain node on the node device by creating an instance of running blockchain platform codes in the process. For the first master network node, a first instance is created by the node device in the above process and formed by the first instance running blockchain platform code. Similarly, for the first subnet node, a second instance different from the first instance is created by the node device in the above process, and is formed by the second instance running the blockchain platform code. For example, the node device may first create a first instance in a 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 building the blockchain subnet, a second instance may be created in the process, where the second instance is different from the first instance, and forms a second blockchain node in the blockchain subnet. When the first instance and the second instance are located in the same process, the deployment difficulty of the first subnet node can be reduced and the deployment efficiency can be improved because cross-process interaction is not involved; of course, the second instance may also be in a different process on the node device than the first instance, and this specification does not limit this; for example, the 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 building the blockchain subnet, a second process different from the first process may be started, and a second instance different from the first instance may be created in the second process, so that the second blockchain node in the blockchain subnet is formed by the second instance. In fact, each block link point deployed on any node device referred to in the embodiments of this specification is a different block chain instance running on any node device, blocks generated by each block link point deployed on any node device are respectively stored in different storages (for example, a database) on any node device, and the storages used by each block link point deployed on any node device are isolated from each other.

By the method, the block chain sub-network can be created on the block chain main network. Taking fig. 1 as an example, the subnet0 originally includes nodeA to nodeE, and can construct subnet1 on the basis of subnet0, where subnet1 includes nodeA1 to nodeD1, and nodeA1, nodeB and nodeB1, nodeC and nodeC1, and nodeD1 are respectively deployed on the same node device. Similarly, a subnet2 or more block chain subnets can be constructed on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA1, nodeA2, nodeB1, nodeB2, nodeC1, nodeD1 and nodeD2, and nodeE2 are respectively deployed on the same node device. And, subnet1, subnet2, etc. may be used as new blockchain main networks, and a blockchain subnet is further constructed on the basis, which is similar to the construction of subnet1 or subnet2, and is not described herein again. As can be seen, in the manner of initiating a transaction on the blockchain main network to select a node member to create a blockchain subnet, the subnet nodes of the newly created blockchain subnet can all be deployed on the node device where the main network node of the blockchain main network is located, that is, from the perspective of the slave node device, the node device where the subnet node of the blockchain subnet is located belongs to the subset of the node device where the main network node is located, in other words, the main network node in the blockchain main network is deployed on the node device where the subnet node of the blockchain subnet is located.

In addition to the above-mentioned manner of selecting a node member to create a blockchain subnet by initiating a transaction on the blockchain main network, the blockchain subnet may be created by other means and managed by the blockchain main network. For example, a block chain sub-network (hereinafter referred to as a registration networking mode for short) may be established on the block chain main network through a registration mode, and an existing block chain network is directly registered to the block chain main network, so that the newly registered block chain network is managed by the block chain main network, and the newly registered block chain network becomes the block chain sub-network of the block chain main network. By means of the registration networking mode, subnet information of a block chain subnet to be established is directly registered to a block chain main network, so that the block chain main network obtains relevant information of the block chain subnet to be established (by receiving and executing a transaction which is sent by the block chain network to be established and used for carrying out association storage on identity information of the block chain subnet to be established and a subnet identifier distributed to the block chain network to be established), such as a subnet identifier and an operation state of the block chain subnet to be established, wherein public keys and plug-in configuration information of each node member, IP addresses and port information of each node device and the like, the information can be written into a contract state of a system contract corresponding to the block chain main network, and therefore the block chain main network obtains a management right of the block chain subnet to be established, and after the registration is completed, the block chain subnet establishment is completed. Since the registration networking manner does not require designating node members to form a blockchain subnet on the blockchain main network through transactions, subnet nodes in the blockchain subnet constructed through the registration networking manner may be completely or partially different from node devices disposed at each node in the blockchain main network, for example, subnet0 in fig. 1 creates a subnet4 (not shown in fig. 1) in the registration networking manner, and assuming that the main network nodes nodeA to nodeE included in the subnet0 themselves are disposed at the node devices 1 to 5, respectively, the subnet node corresponding to the subnet4 may be disposed at any node device other than the node devices 1 to 5, or one or more subnet nodes in the subnet4 may be disposed at any node device within the node devices 1 to 5, respectively (but it is still required to ensure that only one subnet node in the subnet4 is disposed at one node device), and other subnet nodes 4 are disposed at any node device other than the node devices 1 to 5, of course, the subnet nodes in subnet4 may all be deployed in node devices 1 to 5.

According to the foregoing description, by further establishing a blockchain subnet based on a blockchain main network, a blockchain system including the blockchain main network and the blockchain subnets managed thereby can be constructed. In the blockchain system, different blockchain subnets are isolated from each other, which causes that when a certain blockchain subnet receives a message to be forwarded which is to be sent to other blockchain subnets, the message to be forwarded can only be discarded due to lack of routing information of other blockchain subnets, so that a message which is incorrectly forwarded due to various reasons cannot be rerouted to a correct blockchain network, and this brings a challenge to the robustness of the blockchain system. Taking fig. 1 as an example, subnet2 and subnet1 belong to independent blockchain networks, and for subnet2, it only knows the existence of its subnet nodes nodeB2, nodeB2, nodeB2 and nodeB2, and the transaction initiated by subnet2 is not transferred to subnet0 or subnet1, but only sent to the subnet nodes in subnet2 for consensus and processing, so when subnet2 receives the transaction to be forwarded that should be sent to subnet1, it cannot find the corresponding routing information, and therefore it can only be discarded. In order to solve the problem, the present specification provides a cross-subnet interaction method, where a subnet topology structure of a first blockchain subnet, network delay information corresponding to the subnet topology structure, and a node deployment situation on a node device where a subnet node in the first blockchain subnet is located are maintained at a first subnet node, so that when the first subnet node acquires a message to be forwarded, which needs to be forwarded to a target blockchain subnet, a forwarding path with the smallest total delay between the first subnet node and the subnet node in the target blockchain subnet is determined, and the message to be forwarded is forwarded based on the forwarding path.

The cross-subnet interaction method related to the present specification is described in detail below with reference to fig. 2. Fig. 2 is a flow chart of a method of interacting across subnets, provided by an exemplary embodiment. The method is applied to a first subnet node in a first blockchain subnet in a blockchain system, wherein the blockchain system comprises a blockchain main network and a blockchain subnet managed by the blockchain main network; the first subnet node maintains a subnet topology structure of the first blockchain subnet, network delay information corresponding to the subnet topology structure and a node deployment condition on node equipment where the subnet node in the first blockchain subnet is located; the method comprises the following steps:

s202: and acquiring the message to be forwarded to the target block chain subnet.

The message to be forwarded according to the embodiments of the present specification is a message whose destination address is a target blockchain subnet or at least one subnet node in the target blockchain subnet, where the target blockchain subnet is different from the first blockchain subnet. In the blockchain system according to the embodiment of the present specification, since there are multiple layers of blockchain networks nested in the same physical node device architecture at the same time, there is a possibility that a message transmission or forwarding error occurs. Taking fig. 1 as an example, nodeA1 in subnet1 intends to send a message to nodeB1 located in subnet1, however, a forwarding error occurs in the message in the forwarding process, so that nodeA1 sends the message to nodeA2 located on node device 1 by mistake, and since nodeA2 belongs to subnet2, at this time, for nodeA2, the obtained message belongs to a to-be-forwarded message that needs to be forwarded to a target block chain subnet according to the embodiment of the present specification, and the to-be-forwarded message according to the embodiment of the present specification may include a block chain transaction.

In this embodiment, the subnet topology is generated based on a network connection relationship between each subnet node in the first blockchain subnet, and the network link corresponding to the network connection relationship includes: the block chain synchronization method comprises a consensus link established between consensus subnet nodes in a first block chain subnet and a synchronization link established between the consensus subnet nodes and non-consensus subnet nodes, wherein the consensus nodes refer to the block chain nodes participating in processes of transaction consensus, block packing and the like, and the non-consensus nodes refer to the block chain nodes not participating in processes of transaction consensus and only using for synchronizing blocks in the block packing process. Taking fig. 1 as an example, subnet nodes nodeA2, nodeB2, nodeC2 and nodeE2 in a blockchain subnet2 are respectively disposed on node device 1, node device 2, node device 3 and node device 5, and subnet nodes in subnet2 are consensus nodes, and any subnet node in subnet2 maintains a network connection relationship between each subnet node in subnet2, for example, a network connection relationship between each subnet node in subnet2 shown in fig. 1, where consensus links are established between nodeA2 and nodeE2, nodeA2 and nodeC2, nodeE2 and nodeB2, and nodeE2 and nodeB 2. Each subnet node in the subnet2 can also collect node deployment situations (which zone chain nodes are deployed) of the node device where the subnet node is located, and share with each other inside the subnet2, so that any subnet node in the subnet2 can also know the node deployment situations on the node device where each subnet node in the subnet2 is located, and thus a subnet topology structure that can be finally maintained by a first subnet node, for example, nodeE2, is shown in fig. 3, fig. 3 is a schematic diagram of a subnet topology structure provided by an exemplary embodiment, specifically, a schematic diagram of a subnet topology structure of the subnet2 in fig. 1, where the subnet topology structure includes network links between each subnet node in the subnet2, and records other zone chain nodes deployed on the node device where each subnet node is located.

The subnet topology can be represented in a graph form to represent the connection relationship between each subnet node in the first blockchain subnet, for example, the connection relationship of each subnet node in subnet2 shown in fig. 3 can be regarded as an expression form for representing the subnet topology, and of course, the subnet topology can also be represented in a matrix or table form, which is not limited herein.

In this embodiment of the present specification, the first subnet node further maintains network delay information corresponding to the subnet topology, where the network delay information includes: link delay of network links in the subnet topology, and/or node delay of subnet nodes in the subnet topology when forwarding messages. As shown in fig. 3, the first subnet node maintains not only the subnet topology among the subnet nodes but also the link delay of each network link and the node delay of each subnet node included in the subnet topology. The link delay of the network link refers to delay information required for forwarding the message on the network link, for example, the link delay of the network link between nodeb2 and nodeb2 in fig. 3 is 100; the node delay of the subnet node is time delay information required for a message to be forwarded out of the subnet node after entering the subnet node, and specifically includes a process of parsing, routing table lookup and forwarding the message by the subnet node, for example, the node delay of nodeA2 is 3 and the forwarding delay of nodeE2 is 5 in fig. 3. In this embodiment of the present description, a numerical value corresponding to a link delay and a node delay may represent a specific time delay duration, or may represent other time delay indexes having a correlation with the specific time delay duration, but a uniform unit is required between the link delay and the node delay. For example, the link delay 100 of the network link between nodeA2 and node 2 may be understood as 100 milliseconds (ms), i.e. 100ms is required to characterize a message passing through the network link, then the node delay 3 of nodeA2 may be understood as 3 ms.

S204: and under the condition that the subnet nodes in the target block chain subnet are not deployed on the node device where the first subnet node is located, determining a forwarding path with the minimum total delay between the first subnet node and the subnet nodes in the target block chain subnet from the subnet topological structure based on the network delay information, and forwarding the message to be forwarded to a second subnet node in the first block chain subnet serving as a next hop on the determined forwarding path.

In this embodiment of this specification, the message to be forwarded includes identity information of a target blockchain subnet, and the method further includes: and comparing the identity information corresponding to the blockchain network of each locally-deployed blockchain node of the node equipment where the first subnet node is located with the identity information of the target blockchain subnet, and determining whether the node equipment where the first subnet node is located is deployed with the subnet node in the target blockchain subnet. Specifically, the identity information carried by the message to be forwarded may include at least one of the following: the subnet identification of the target block chain subnet, and the public key or node identification of the target subnet node in the block chain subnet.

In a case that it is determined that a subnet node in the target blockchain subnet is not deployed on a node device where a first subnet node is located, the first subnet node first determines, according to a node deployment situation of a node device related to the first blockchain subnet (that is, a node device where each subnet node in the first blockchain subnet is located), whether a subnet node in the target blockchain subnet is deployed by the node device related to the first blockchain subnet, and in a case that it is determined that a subnet node in the target blockchain subnet is deployed by the target node device, determines the subnet node in the target blockchain subnet deployed by the target node device as the target subnet node, and then determines a forwarding path between the first subnet node and the target subnet node based on a subnet topology structure, in an embodiment of the present specification, the determination rule of the forwarding path is that: firstly, the message to be forwarded is sent to a relay subnet node in a first block chain subnet in target node equipment, and then the message with forwarding is forwarded to the target subnet node under the same node equipment by the relay subnet node.

For example, a first subnet node is nodeb2 in subnet2, which receives a message to be forwarded, which needs to be sent to subnet1, and therefore, it finds out from a node deployment situation of a node device related to subnet2 maintained by itself that all the node device 1, node device 2, and node device 3 are deployed with a subnet node in subnet1, and if nodeb2 determines that a target node device is node device 3 and a target subnet node is nodeb1, then nodeb2 needs to determine a forwarding path between nodeb1, according to the foregoing determination rule of the forwarding path, nodeb2 first determines that a transit subnet node is nodeb2 that belongs to subnet2, and then determines that a forwarding path of the message to be forwarded needs to be forwarded from nodeb2 to nodeb2 and finally forwarded to nodeb1, and therefore, in a forwarding path that a loop does not consider and a return from an original path, two forwarding paths between nodeb2 and nodeb2 include: first, nodeE2 → nodeA2 → nodeC2 → nodeC 1; second, nodeE2 → nodeB2 → nodeC2 → nodeC 1. After determining the two selectable forwarding paths, the node e2 further determines, based on the network delay information, a forwarding path with the minimum total delay between the node e2 and the node c1 from the two selectable forwarding paths, where the total delay corresponding to the forwarding path is a sum of a link delay of at least one network link that passes from the first subnet node to the target subnet node on the forwarding path and/or a node delay of at least one subnet node that passes through (excluding the first subnet node and the target subnet node). For example, taking fig. 3 as an example, since the total delay of all network links and all subnet nodes of the forwarding path route of nodeB2 → nodeB2 → nodeB2 → nodeB1 is 115, and the total delay of all network links and all subnet nodes of the forwarding path route of nodeB2 → nodeB2 → nodeB2 → nodeB1 is 155, the forwarding path finally determined by nodeB2 is nodeB2 → nodeB2 → nodeB2 → nodeB1, so that nodeB2 can further determine that the second subnet node as the next hop in the forwarding path is nodeB2, and then forward the message to be forwarded to nodeB 2.

The nodeB2 may select the nodeB1 as a target subnet node, or may also select the nodeB1 and/or nodeB1 as a target subnet node at the same time, and determine to obtain a forwarding path with the shortest total delay between the nodeB2 and the target subnet nodes according to the method for determining a forwarding path, and then the nodeB2 may select a globally optimal forwarding path with the shortest total delay from the forwarding paths determined based on different target subnet nodes, for example, in this embodiment of the present specification, based on the subnet topology and the network delay information shown in fig. 3, the globally optimal forwarding path finally determined by the nodeB2 should be nodeB2 → nodeB2 → nodeB1, and the total delay of the globally optimal forwarding path is 53.

S206: and forwarding the message to be forwarded to the subnet node in the target block chain subnet under the condition that the subnet node in the target block chain subnet is deployed on the node device where the first subnet node is located.

In the embodiment of the present specification, each blockchain node runs a virtual communication plug-in corresponding to the blockchain network where the node is located; the virtual communication plugins of the block chain nodes of different block chain networks are isolated from each other under the communication scene of cross-node equipment, but can realize intercommunication under the communication scene in the same node equipment. Taking fig. 1 as an example, each subnet node in subnet1 can implement network interconnection through its own running virtual communication plug, but the subnet node in subnet1 runs the virtual communication plug and is isolated from the virtual communication plug running in subnet node in subnet2, so that although a plurality of blockchain nodes may be deployed on the same node device at the same time, because these blockchain nodes do not use the same set of communication plug but use the virtual communication plugs corresponding to the blockchain network, different blockchain networks share the same set of physical node device architecture, but can implement network isolation at the network level. In particular, communication is allowed between virtual communication cards operating at different block chain nodes within the same node device, for example, the virtual communication cards operating respectively in nodeA, nodeA1 and nodeA2 deployed in node device 1 are interconnected.

The virtual communication plug-in related to the embodiment of the present specification may refer to a corresponding communication plug-in actually running on a node device, and in this case, if a plurality of block chain nodes are deployed on the same node device, communication plugs corresponding to the plurality of block chain nodes in number need to be deployed on the node device respectively, so as to be allocated to the corresponding plurality of block chain nodes respectively; or, the virtual communication plug-in may refer to a virtualized communication application in which communication plugs deployed on the same node device are logically distinguished, in this case, if the same node device is deployed with a plurality of block chain nodes, the same communication plug-in only needs to be operated on the node device, and then the virtualized communication applications corresponding to the plurality of block chain nodes in number are virtualized on the communication device to be respectively allocated to the corresponding plurality of block chain nodes.

In this embodiment of this specification, the forwarding the message to be forwarded to the second subnet node in the first blockchain subnet as the next hop on the determined forwarding path includes: and forwarding the message to be forwarded to a second communication plug-in operated by a second sub-network node from a first communication plug-in operated by a first sub-network node. Since the first subnet node and the second subnet node belong to the same block chain subnet, message forwarding can be realized by virtual communication plug-ins running between the first subnet node and the second subnet node. And forwarding the message to be forwarded to a subnet node in the target blockchain subnet includes: and forwarding the message to be forwarded to a target communication plug-in operated by the subnet node in the target block chain subnet deployed on the node device where the first subnet node is located by the first communication plug-in. Since the subnet node (target subnet node) in the target blockchain subnet and the first subnet node belong to different blockchain networks but are in the same node device, message forwarding can also be realized through virtual communication plug-ins operating with each other.

Optionally, the method further includes: and under the condition that a forwarding path does not exist between the first subnet node and the subnet node in the target block chain subnet, discarding the message to be forwarded, or forwarding the message to be forwarded to a master network node in the block chain master network, so that the master network node in the block chain master network forwards the message to be forwarded to the subnet node in the target block chain subnet according to the determined forwarding path under the condition that the forwarding path between the first subnet node and the subnet node in the target block chain subnet is determined according to a self-maintained master network topology structure and a node deployment condition on the node device where the master network node in the block chain master network is located. In this embodiment of the present specification, if a first subnet node determines, through a node deployment situation on a node device where a subnet node in a first blockchain subnet maintained by the first subnet node itself is located, that a subnet node in a target blockchain subnet is not deployed in node devices related to a first blockchain subnet, it indicates that correct forwarding of a message to be forwarded cannot be achieved only according to the first blockchain subnet, and therefore the message to be forwarded can only be discarded or forwarded to a master network node in a blockchain master network, and then a forwarding path between the first subnet node and the subnet node in the target blockchain subnet is determined by the master network node according to a master network topology structure of the blockchain master network and a node deployment situation on the node device where the master network node in the blockchain master network is located, and the master network node forwards the message to be forwarded instead according to the determined forwarding path, thereby further increasing the robustness of the blockchain system.

In an embodiment of this specification, the network delay information includes a link delay of a near-end network link and/or a link delay of a far-end network link in the subnet topology, where the near-end network link is a network link between the first subnet node and a neighboring subnet node thereof, and the far-end network link is a network link in the subnet topology other than the near-end network link. The neighbor subnet nodes of the first subnet node refer to subnet nodes directly connected with the first subnet node through a segment of network link, taking fig. 3 as an example, the neighbor subnet node corresponding to nodeA2 includes nodeA2 and nodeC2, and the neighbor subnet node of nodeC2 includes nodeA2 and nodeB 2.

For the first subnet node, two different types of network links are maintained, including a near-end network link and a far-end network link. The near-end network link refers to a network link directly connected with the first sub-network node, namely a network link between the first sub-network node and a neighboring sub-network node; the far-end network link refers to a network link that is not directly connected to the first subnet node, that is, a network link in the subnet topology structure other than the near-end network link corresponding to the first subnet node. Still taking fig. 3 as an example, the near-end network link corresponding to nodeA2 includes the network links between nodeC2 and nodeE2, and the far-end network link corresponding to nodeA2 includes the network links between nodeC2 and nodeB2, and between nodeE2 and nodeE 2.

And the first subnet node acquires the link delay according to different strategies according to different types of network links. The first sub-network node determines the link delay of the near-end network link according to the link delay of the local end and/or the link delay of the opposite end; the local end link delay is obtained by detecting the near end network link by a first sub-network node through a request response mechanism, and the opposite end link delay is obtained by detecting the near end network link by a neighbor sub-network node of the first sub-network node through the request response mechanism; and/or receiving link delay of the remote network link sent by a neighbor subnet node of the first subnet node, wherein the link delay of the remote network link is determined by link delay obtained by detecting the remote network link by at least one end subnet node of the remote network link through a request response mechanism.

The request response mechanism related to the embodiments of the present specification relates to interaction between a requester and a responder, and an initiator of the request response mechanism is considered to be the requester, and the request response mechanism is specifically implemented by the following means: the requester sends a request message carrying time t1 to the responder, and t1 is the local time of the requester when the requester sends the request message. After receiving the request message, the responder records local time t2 of the responder when the responder receives the request message, and then returns a response message generated in response to the request message to the requester, and simultaneously carries time t2 and time t3 in the response message, wherein t3 is the local time of the responder when the responder returns the response message, which is recorded by the responder. Finally, after the requester acquires the response message, the local time T4 of the requester when the requester receives the response message is recorded, then T2 and T3 are extracted from the acquired response message, then T0 is calculated as [ (T4-T1) - (T3-T2) ]/2, and the T0 is determined as the link delay T0 of the network link between the requester and the responder. In order to avoid the interference of the forwarding delay of the relay device, no other relay device exists between the requesting party and the answering party. The request messages and response messages involved in the request-response mechanism may be dedicated messages dedicated to calculating the link delay, or may be other normal service requests, or heartbeat messages in the network, and since the local processing time t3-t2 of the responder is taken into account when calculating the link delay, any type of request message and response message may be applied to the request-response mechanism to enable the requester to measure the associated link delay.

In this illustrative embodiment, the first subnet node may be determined by the request reply mechanism described above when determining the link delay of the near-end network link. For example, the first subnet node may actively initiate a request-response mechanism to its neighboring subnet node, so as to determine a link delay of the near-end network link between the first subnet node and the neighboring subnet node, where the link delay of the near-end network measured by the first subnet node through the request-response mechanism is referred to as a local link delay. On the other hand, for any network link, the two end subnet nodes included in the network link can measure the link delay of the network link by initiating the request-response mechanism, so the first subnet node can also directly obtain the link delay of the near-end network link between the first subnet node and the neighbor subnet node by receiving the link delay of the near-end network link between the first subnet node and the neighbor subnet node measured by the neighbor subnet node performing the request-response mechanism, and the link delay measured by the neighbor subnet node and provided to the near-end network link of the first subnet node is called as the opposite-end link delay. In summary, the first sub-network node may obtain the link delay of a near-end network link through two means, and therefore, the two means may also be selected or considered comprehensively, for example, the link delay of the near-end network link finally determined by the first sub-network node and recorded in the network delay information may include: the local end link delay, the opposite end link delay, or a weighted average of the local end link delay and the opposite end link delay. When the link delay of the near-end network link is determined to be the weighted average of the local-end link delay and the opposite-end link delay, the network delay information maintained by the first subnet node can be made more robust.

Taking fig. 3 as an example, assuming that the home link delay of the near-end network link between the nodeb2 and the nodeb2 measured by the initiate request response mechanism is 102, and the peer link delay of the near-end network link between the nodeb2 measured by the initiate request response mechanism is 98, for nodeb2, it may directly determine the home link delay 102 measured by itself as the link delay of the near-end network link between the nodeb2, or determine the peer link delay 98 measured by nodeb2 received from nodeb2 as the link delay of the near-end network link, and may also determine the average 100 of the home link delay and the peer link delay as the link delay of the near-end network link according to a weight ratio of 1:1, and record it in the network delay information maintained locally by nodeb 2.

Since the first subnet node can only directly measure the link delay of the near-end network link between the first subnet node and the neighboring subnet node, but cannot measure the link delay of the far-end network link, it is necessary to directly obtain the link delay of the far-end network link by receiving the link delay sharing message containing the link delay of the far-end network link sent or forwarded by the neighboring subnet node, and record the link delay to the corresponding far-end network link in the network delay information. In this embodiment of the present specification, the first sub-network node receives, by the first sub-network node, a link delay of the remote network link sent by a neighbor sub-network node of the first sub-network node, where the link delay of the remote network link is determined by a link delay obtained by at least one end sub-network node of the remote network link detecting the remote network link through a request response mechanism, for example, the link delay of the remote network link may include: the link delay obtained by detecting the subnet nodes at either end of the far-end network link, or the weighted average of the link delays obtained by respectively detecting the subnet nodes at both ends of the far-end network link. The link delay detected by any subnet node is the link delay for the remote network link, and the network delay information maintained by the first subnet node can be made more robust under the condition that the link delay of the remote network link is the weighted average of the link delays detected by the subnet nodes at both ends of the remote network link.

As shown in fig. 3, assuming that the first subnet node is nodeA2, for nodeA2, the link delay of the remote network link between nodeE2 and nodeB2 cannot be directly measured by the request-response mechanism, but needs to be measured and determined by nodeE2 and/or nodeB2 by initiating the request-response mechanism, and nodeE2 encapsulates the finally determined link delay of the remote network link into a link delay sharing message for transmission or forwarding to nodeA2, and nodeA2 updates the network delay information maintained by itself based on the acquired link delay of the remote network link.

The first subnet node may receive the measured far-end link delay from the neighbor subnet node, and in an embodiment, further includes: and receiving a response message sent by the neighbor subnet node of the first subnet node in a request response mechanism, wherein the response message comprises the opposite-end link delay and/or the link delay of the remote network link. In this embodiment, the opposite-end link delay and/or the link delay of the remote network link received by the first subnet node may be directly carried in a response message involved when the first subnet node initiates a request response mechanism to the neighbor subnet node, so that the first subnet node may obtain the opposite-end link delay and/or the link delay of the remote network link simultaneously under the condition of obtaining the local-end link delay only by initiating the request response mechanism once, thereby reducing the complexity of the network internal interaction. In another embodiment, the link delay of the peer network link and/or the link delay of the remote network link may also be carried in other messages sent by the neighbor subnet node or forwarded to the first subnet node.

As mentioned above, the network delay information includes: link delay of network links in the subnet topology, and/or node delay of subnet nodes in the subnet topology when forwarding messages. Optionally, the method further includes: acquiring node delay obtained by detecting any subnet node by at least one neighbor subnet node of any subnet node in the subnet topological structure, and determining the node delay of any subnet node according to the acquired node delay; and/or receiving a node latency of the any subnet node shared by other subnet nodes. In this embodiment of the present specification, the node delay of any subnet node needs to be measured by any neighbor subnet node corresponding to the subnet node, specifically, measured by any neighbor node corresponding to the subnet node through a backflow message mechanism.

The backflow message mechanism related to the embodiments of the present specification relates to interaction between a requester and a responder, and an initiator of the backflow message mechanism is considered to be the requester, and the backflow message mechanism is specifically implemented by the following means: the method comprises the steps that a requester firstly selects a responder and initiates a backflow message mechanism, firstly, the requester needs to construct a backflow message with a destination address pointing to the requester, and sends the backflow message to the responder according to a network link directly connected with the responder, and simultaneously records the local time t5 of the requester when the backflow message is sent. After receiving the reflow message, the responder finds out that the destination address of the reflow message is the requester through searching a routing table, so that the reflow message is returned to the requester as it is, after receiving the reflow message, the requester records the local time T6 of the requester, then calculates T1-T6-T5, obtains the forwarding delay T1 corresponding to the whole period from the requester to the requester, then the requester finds out the link delay T2 of the network link between the requester and the responder from the maintained network delay information, then calculates T3-T1-2-T2, and finally determines that the node delay corresponding to the responder is T3. The mechanism of the return message requires that no other transit device exists between the requesting party and the answering party because the mechanism of the return message measures the node delay of the forwarded message of the object, i.e. the answering party, and therefore, the addition of the other transit device will result in the failure of the measurement expectation.

In this embodiment of this specification, the detecting, by any neighbor subnet node of any subnet node, of any subnet node includes: and the any neighbor subnet node sends a backflow message to the any subnet node, the node delay of the any subnet node is determined according to the forwarding delay of the backflow message and the link delay of a network link between the any neighbor subnet node and the any subnet node, and the backflow message is a message that a destination address sent by the any neighbor subnet node to the any subnet node points to the any neighbor subnet node. As previously described, for a node latency of any subnet node, any neighbor subnet node of the any subnet node may initiate a backflow message mechanism to measure.

For the node delay of a certain neighbor subnet node of the first subnet node, the first subnet node may be directly detected by initiating a backflow message mechanism, and certainly, since the subnet node directly connected to the neighbor subnet node may not only include the first subnet node, the first subnet node may also receive the node delay corresponding to the neighbor subnet node measured by the subnet nodes through the backflow message mechanism, and use as a reference to finally determine the node delay corresponding to the neighbor subnet node. Taking fig. 3 as an example, assuming that node delay of node e2 detected by node a2 through initiating a backflow message mechanism to node e2 is 3, and node delay of node e2 detected by node b2 through initiating a backflow message mechanism to node e2 is 1, for node a2, node delay 3 measured by itself may be directly determined as node delay with node e2 and recorded in network delay information maintained locally by node a2, or node delay 1 measured by node b2 received from node b2 may be determined as node delay of node e2 and recorded in network delay information maintained locally by node a2, and an average value 5 of node delay 3 measured by itself and node delay 7 measured by node b2 may be determined as node delay of node e2 according to a weight ratio of 1:1 and recorded in network delay information maintained locally by node a 2.

For the first subnet node, it cannot detect and obtain the node delay of the subnet node except its neighbor subnet node through the backflow message mechanism, so the first subnet node can also obtain the node delay of any subnet node through other manners, for example, the first subnet node can directly receive the node delay of any subnet node shared by other subnet nodes. Taking fig. 3 as an example, the nodeB2 cannot directly detect the node delay of nodeB2, but the nodeB2 can measure, so the nodeB2 can directly receive the node delay sharing message that is sent by nodeB2 to nodeB2 and carries the nodeB2 node delay, thereby obtaining and determining that the node delay of nodeB2 is 3, and finally record it in the local network delay information. Certainly, the nodeB2 does not have to acquire the node delay of nodeB2 from nodeB2, and in fact, in the foregoing manner of acquiring the node delay, the network delay information maintained by nodeB2 actually includes the node delay of nodeB2, so nodeB2 may also receive the node delay sharing message that carries the node delay of nodeB2 and is sent by nodeB2, so as to acquire the node delay of nodeB 2.

The node delay of any sub-network node in the network delay information maintained by the first sub-network node includes: and the node delay obtained by detecting any subnet node by any neighbor subnet node of any subnet node, or the weighted average of the node delay obtained by detecting any subnet node by at least one neighbor subnet node of any subnet node. As described above, for the node delay of any subnet node, any neighbor node of any subnet node can be detected, so that when the first subnet node finally determines the node delay of any subnet node, the first subnet node can directly record the node delay of any subnet node, which is detected by any neighbor node of any subnet node, in the locally maintained network delay information, or can determine the weighted average of the node delays, which are detected by one or more neighbor subnet nodes of any subnet node, as the node delay of any subnet node, and record the weighted average in the locally maintained network delay information. In the case that the node delay of any subnet node is finally determined as the weighted average of the node delays detected by at least one neighbor subnet node of any subnet node, the network delay information maintained by the first subnet node can be made more robust.

Taking fig. 3 as an example, the nodeA2 may receive the node delay 1 of nodeA2 detected by the nodeA2 and the node delay 5 of nodeA2 detected by the nodeC2, respectively, at this time, the nodeA2 may optionally use one of the measured node delays of nodeA2 as the node delay of the nodeA2 in the locally maintained network delay information, or determine the weighted average 3 of the node delay measured by the nodeA2 and the node delay measured by the nodeC2 as the node delay of the nodeA2 in the network delay information according to the weight ratio of 1: 1.

FIG. 4 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 4, at the hardware level, the apparatus includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410, but may also include hardware required for other services. One or more embodiments of the present description may be implemented in software, such as by processor 402 reading corresponding computer programs from non-volatile storage 410 into memory 408 and then executing. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Fig. 5 is a block diagram of a cross-subnet interaction apparatus provided by the present specification according to an exemplary embodiment, which may be applied to the device shown in fig. 4 to implement the technical solution of the present specification; the device is applied to a first subnet node in a first blockchain subnet in a blockchain system, and the blockchain system comprises a blockchain main network and a blockchain subnet managed by the blockchain main network; the first subnet node maintains a subnet topology structure of the first blockchain subnet, network delay information corresponding to the subnet topology structure and a node deployment condition on node equipment where the subnet node in the first blockchain subnet is located; the device comprises:

a message obtaining unit 501, configured to obtain a message to be forwarded, which needs to be forwarded to a target blockchain subnet;

a path forwarding unit 502, configured to, when it is determined that the subnet node in the target blockchain subnet is not deployed on the node device where the first subnet node is located, determine, based on the network delay information, a forwarding path with a minimum total delay between the first subnet node and the subnet node in the target blockchain subnet from the subnet topology, and forward the message to be forwarded to a second subnet node in the first blockchain subnet serving as a next hop on the determined forwarding path;

a node forwarding unit 503, configured to forward the message to be forwarded to the subnet node in the target blockchain subnet when it is determined that the subnet node in the target blockchain subnet is deployed on the node device where the first subnet node is located.

Optionally, the network delay information includes a link delay of a near-end network link and/or a link delay of a far-end network link in the subnet topology structure, where the near-end network link is a network link between the first subnet node and a neighboring subnet node thereof, and the far-end network link is a network link in the subnet topology structure except for the near-end network link.

Optionally, the method further includes:

a link delay obtaining unit 504, configured to determine a link delay of the near-end network link according to a local-end link delay and/or an opposite-end link delay; the local end link delay is obtained by detecting the near end network link by a first sub-network node through a request response mechanism, and the opposite end link delay is obtained by detecting the near end network link by a neighbor sub-network node of the first sub-network node through the request response mechanism; and/or the presence of a gas in the gas,

and receiving the link delay of the remote network link sent by the neighbor subnet node of the first subnet node, wherein the link delay of the remote network link is determined by the link delay obtained by detecting the remote network link by at least one end subnet node of the remote network link through a request response mechanism.

Optionally, the method further includes:

the response receiving unit 505 receives a response message sent by a neighbor subnet node of the first subnet node in the request response mechanism, where the response message includes the link delay of the peer end and/or the link delay of the remote network link.

Alternatively to this, the first and second parts may,

the link delay of the near-end network link includes: the local end link delay, the opposite end link delay, or a weighted average of the local end link delay and the opposite end link delay;

the link delay of the remote network link includes: the link delay obtained by detecting the subnet nodes at either end of the far-end network link, or the weighted average of the link delays obtained by respectively detecting the subnet nodes at both ends of the far-end network link.

Optionally, the network delay information includes: link delay of network links in the subnet topology, and/or node delay of subnet nodes in the subnet topology when forwarding messages.

Optionally, the method further includes:

a node delay obtaining unit 506, configured to obtain a node delay obtained by detecting any subnet node by at least one neighbor subnet node of any subnet node in the subnet topology structure, and determine the node delay of any subnet node according to the obtained node delay; and/or the presence of a gas in the gas,

receiving a node latency of the any subnet node shared by other subnet nodes.

Optionally, detecting, by any neighbor subnet node of any subnet node, any subnet node includes:

and the any neighbor subnet node sends a backflow message to the any subnet node, the node delay of the any subnet node is determined according to the forwarding delay of the backflow message and the link delay of a network link between the any neighbor subnet node and the any subnet node, and the backflow message is a message that a destination address sent by the any neighbor subnet node to the any subnet node points to the any neighbor subnet node.

Optionally, the node delay of any subnet node includes:

and the node delay obtained by detecting any subnet node by any neighbor subnet node of any subnet node, or the weighted average of the node delay obtained by detecting any subnet node by at least one neighbor subnet node of any subnet node.

Optionally, the method further includes:

a master network forwarding unit 507, configured to discard the message to be forwarded when a forwarding path does not exist between the first subnet node and the subnet node in the target block chain subnet, or forward the message to be forwarded to the master network node in the block chain master network, so that when a forwarding path between the first subnet node and the subnet node in the target block chain subnet is determined according to a self-maintained master network topology structure and a node deployment situation on a node device where the master network node in the block chain master network is located by the master network node in the block chain master network, the message to be forwarded is forwarded to the subnet node in the target block chain subnet according to the determined forwarding path.

Optionally, the subnet topology is generated based on a network connection relationship between each subnet node in the first blockchain subnet.

Optionally, the network link corresponding to the network connection relationship includes: the block chain comprises a consensus link established between the consensus subnet nodes in the first blockchain subnet and a synchronous link established between the consensus subnet nodes and the non-consensus subnet nodes.

Optionally, each blockchain node runs a virtual communication plug-in corresponding to the blockchain network where the node is located; the virtual communication plugins of the block chain nodes of different block chain networks are isolated from each other under the communication scene of cross-node equipment;

the path forwarding unit 502 is specifically configured to: the message to be forwarded is forwarded to a second communication plug-in operated by a second sub-network node from a first communication plug-in operated by a first sub-network node;

the node forwarding unit 503 is specifically configured to: and forwarding the message to be forwarded to a target communication plug-in operated by the subnet node in the target block chain subnet deployed on the node device where the first subnet node is located by the first communication plug-in.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified Programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Language, HDL, las, software, Hardware Description Language (software Description Language), and so on. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, the present invention does not exclude that as future computer technology develops, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. 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, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of multiple sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

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

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 computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

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

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

1. A cross-subnet interaction method is applied to a first subnet node in a first blockchain subnet in a blockchain system, wherein the blockchain system comprises a blockchain main network and a blockchain subnet managed by the blockchain main network; the first subnet node maintains a subnet topology structure of the first blockchain subnet, network delay information corresponding to the subnet topology structure and a node deployment condition on node equipment where the subnet node in the first blockchain subnet is located; the method comprises the following steps:

acquiring a message to be forwarded to a target block chain subnet;

2. The method according to claim 1, the network delay information comprising link delays of near-end network links and/or link delays of far-end network links in the sub-network topology, the near-end network links being network links between a first sub-network node and its neighboring sub-network nodes, the far-end network links being network links in the sub-network topology other than the near-end network links.

3. The method of claim 2, further comprising:

determining the link delay of the near-end network link according to the link delay of the local end and/or the link delay of the opposite end; the local end link delay is obtained by detecting the near end network link by a first sub-network node through a request response mechanism, and the opposite end link delay is obtained by detecting the near end network link by a neighbor sub-network node of the first sub-network node through the request response mechanism; and/or the presence of a gas in the gas,

4. The method of claim 3, further comprising:

and receiving a response message sent by the neighbor subnet node of the first subnet node in a request response mechanism, wherein the response message comprises the opposite-end link delay and/or the link delay of the remote network link.

5. The method of claim 3, wherein the first and second light sources are selected from the group consisting of,

6. The method of claim 1, the network delay information comprising: link delay of network links in the subnet topology, and/or node delay of subnet nodes in the subnet topology when forwarding messages.

7. The method of claim 6, further comprising:

acquiring node delay obtained by detecting any subnet node by at least one neighbor subnet node of any subnet node in the subnet topological structure, and determining the node delay of any subnet node according to the acquired node delay; and/or receiving a node latency of the any subnet node shared by other subnet nodes.

8. The method of claim 7, wherein any neighbor subnet node of any subnet node detects the any subnet node, comprising:

9. The method of claim 7, the node latency of any subnet node, comprising:

10. The method of claim 1, further comprising:

and under the condition that a forwarding path does not exist between the first subnet node and the subnet node in the target block chain subnet, discarding the message to be forwarded, or forwarding the message to be forwarded to a master network node in the block chain master network, so that the master network node in the block chain master network forwards the message to be forwarded to the subnet node in the target block chain subnet according to the determined forwarding path under the condition that the forwarding path between the first subnet node and the subnet node in the target block chain subnet is determined according to a self-maintained master network topology structure and a node deployment condition on the node device where the master network node in the block chain master network is located.

11. The method of claim 1, the subnet topology being generated based on network connection relationships between subnet nodes in the first blockchain subnet.

12. The method of claim 11, wherein the network link corresponding to the network connection relationship comprises: the block chain comprises a consensus link established between the consensus subnet nodes in the first blockchain subnet and a synchronous link established between the consensus subnet nodes and the non-consensus subnet nodes.

13. The method of claim 1, wherein each blockchain node runs a virtual communication plug-in corresponding to the blockchain network where the blockchain node is located; the virtual communication plugins of the block chain nodes of different block chain networks are isolated from each other under the communication scene of cross-node equipment;

the forwarding the message to be forwarded to a second subnet node in the first blockchain subnet as a next hop on the determined forwarding path includes: the message to be forwarded is forwarded to a second communication plug-in operated by a second sub-network node from a first communication plug-in operated by a first sub-network node;

the forwarding the message to be forwarded to a subnet node in the target blockchain subnet includes: and forwarding the message to be forwarded to a target communication plug-in operated by the subnet node in the target block chain subnet deployed on the node device where the first subnet node is located by the first communication plug-in.

14. A cross-subnet interaction device is applied to a first subnet node in a first blockchain subnet in a blockchain system, wherein the blockchain system comprises a blockchain main network and a blockchain subnet managed by the blockchain main network; the first subnet node maintains a subnet topology structure of the first blockchain subnet, network delay information corresponding to the subnet topology structure and a node deployment condition on node equipment where the subnet node in the first blockchain subnet is located; the device comprises:

15. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-13 by executing the executable instructions.

16. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 13.