CN114301828A - Cross-subnet interaction method and device, electronic equipment and storage medium - Google Patents
Cross-subnet interaction method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN114301828A CN114301828A CN202111669884.6A CN202111669884A CN114301828A CN 114301828 A CN114301828 A CN 114301828A CN 202111669884 A CN202111669884 A CN 202111669884A CN 114301828 A CN114301828 A CN 114301828A
- Authority
- CN
- China
- Prior art keywords
- node
- network
- node device
- link
- delay
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 128
- 230000003993 interaction Effects 0.000 title claims abstract description 38
- 238000003860 storage Methods 0.000 title claims abstract description 24
- 230000001934 delay Effects 0.000 claims abstract description 17
- 230000007246 mechanism Effects 0.000 claims description 51
- 230000004044 response Effects 0.000 claims description 44
- 230000006854 communication Effects 0.000 claims description 19
- 238000004891 communication Methods 0.000 claims description 19
- 230000001360 synchronised effect Effects 0.000 claims description 7
- 238000001514 detection method Methods 0.000 claims description 6
- 230000008569 process Effects 0.000 description 45
- 238000010586 diagram Methods 0.000 description 18
- 230000006870 function Effects 0.000 description 18
- 230000006855 networking Effects 0.000 description 18
- 238000012545 processing Methods 0.000 description 12
- 230000000977 initiatory effect Effects 0.000 description 10
- 230000006872 improvement Effects 0.000 description 9
- 238000012544 monitoring process Methods 0.000 description 9
- 238000004590 computer program Methods 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 5
- 230000014759 maintenance of location Effects 0.000 description 5
- 239000003999 initiator Substances 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000010276 construction Methods 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 108010001267 Protein Subunits Proteins 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 239000007795 chemical reaction product Substances 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000008034 disappearance Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 229920001296 polysiloxane Polymers 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The present specification provides a cross-subnet interaction method, apparatus, electronic device, and storage medium, wherein the method is applied to a first node device that maintains a network topology between node devices where each master network node in a block chain master network is respectively located and delays network delay information corresponding thereto; the method comprises the following steps: acquiring a cross-link message sent by a source subnet node in a first block link subnet to a target subnet node in a second block link subnet; and under the condition that the first node device is determined not to be the target node device where the target subnet node is located, determining a forwarding path with the minimum total delay between the first node device and the target node device from the network topology structure based on the network delay information, and forwarding the cross-link message to a second node device of a next hop of the forwarding path.
Description
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, there is no directly connected network link, but there is a need for information sharing and data interaction between the blockchain subnets, and therefore, how to enable efficient data interaction between the isolated blockchain subnets is a problem to be solved in this scenario.
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 node device, where a master network node in a block chain master network is deployed on the first node device, and a network topology structure between node devices where each master network node in the block chain master network is respectively located and network delay information corresponding to the network topology structure are maintained on the first node device; the block chain main network is used for managing a block chain sub-network, and main network nodes are also deployed on the node devices of the sub-network nodes in the block chain sub-network; the method comprises the following steps:
acquiring a cross-link message sent by a source subnet node in a first block link subnet to a target subnet node in a second block link subnet;
and under the condition that the first node device is determined not to be the target node device where the target subnet node is located, determining a forwarding path with the minimum total delay between the first node device and the target node device from the network topology structure based on the network delay information, and forwarding the cross-link message to a second node device which is the next hop on the determined forwarding path.
According to a second aspect of one or more embodiments of the present specification, a cross-subnet interaction apparatus is provided, which is applied to a first node device, where a master network node in a block chain master network is deployed on the first node device, and a network topology structure between node devices where each master network node in the block chain master network is respectively located and network delay information corresponding to the network topology structure are maintained on the first node device; the block chain main network is used for managing a block chain sub-network, and main network nodes are also deployed on the node devices of the sub-network nodes in the block chain sub-network; the device comprises:
the message acquisition unit is used for acquiring a chain crossing message sent from a source subnet node in the first blockchain subnet to a target subnet node in the second blockchain subnet;
and a path forwarding unit, configured to, when it is determined that the first node device is not a target node device where the target subnet node is located, determine, based on the network delay information, a forwarding path with a minimum total delay between the first node device and the target node device from the network topology, and forward the cross-link message to a second node device serving as a next hop on the determined forwarding path.
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, each node device deployed with a master network node maintains the network topology structure of each node device and the network delay information corresponding to the network topology structure, so that even if a network link directly connected to a target node device where a target subnet node is located does not exist locally in the first node device, a forwarding path with the minimum total delay between the first node device and the target node device may be determined from the network topology structure based on the network delay information, and a link-crossing message is first transmitted to a next-hop node device on the determined forwarding path in a rerouting forwarding manner, and then is gradually transmitted to the target node device by the next-hop node device according to the same method. On one hand, the scheme does not require a directly connected network link to be pre-established between the node device and the target node device, but can forward the cross-link message route to the target node device as long as the target node device is determined to have accessibility in the network topology structure, so as to ensure the normal operation of cross-link interactive service between block chain sub-networks, and can overcome the problem that the cross-link message is unreachable under the condition that the main network node contains both a common node and a non-common node; on the other hand, because the node device maintains network delay information corresponding to the network topology structure, it can be ensured that the cross-chain message can be forwarded through the forwarding path with the minimum total delay, and the forwarding efficiency of the cross-chain message 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 diagram of an application scenario in which an exemplary embodiment provides cross-chain interaction.
Fig. 3 is a diagram of an application scenario interacting across subnets, according to an exemplary embodiment.
Fig. 4 is a flow chart of a method of interacting across subnets, provided by an exemplary embodiment.
Fig. 5 is a schematic diagram of a network topology provided by an exemplary embodiment.
Fig. 6 is a schematic structural diagram of an apparatus according to an exemplary embodiment.
Fig. 7 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]
[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, nodeB and nodeB1, nodeB2, nodeC1 and nodeC2, nodeD and nodeD1, 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.
First, a brief description is given to a scheme of cross-chain interaction (also referred to as cross-subnet interaction) in this specification with reference to fig. 1 and fig. 2, so as to explain how cross-chain interaction is implemented by a blockchain main network between blockchain subnets without a direct network connection path between each blockchain subnet. As shown in fig. 1, a blockchain subnet1 and a blockchain subnet2 are created on the basis of a blockchain main network subnet0, and what is shown in fig. 2 is an application scene diagram for implementing cross-chain interaction based on subnet0 for subnet1 and subnet 2.
As shown in fig. 2, a nodeb 0-belonging nodeC and a nodeb 1-belonging nodeC1 are deployed on a node device 3 at the same time, where nodeb and nodeb1 are block link point instances (hereinafter referred to as blockchain nodes) formed by a node device 3 running a pre-deployed blockchain platform code in a locally deployed virtual machine, a nodeb is stored in a database corresponding to the nodeb as related data of the blockchain node in the running process, and a nodeb1 is stored in a database corresponding to nodeb1 as related data of another blockchain node in the running process. Similarly, the node device 5 is simultaneously deployed with a nodeb 0 and a nodeb2 belonging to a subnet2, and other node devices are also simultaneously deployed with a plurality of blockchain nodes, for example, the node device 1 shown in fig. 2 is simultaneously deployed with three blockchain nodes including nodeb a, nodeb1, and nodeb2 belonging to different blockchain networks, which is not described herein again. In addition, a blockchain consensus code can be deployed in any node device, and the node device can run the consensus code to form a consensus component instance locally; and, a P2P component code managed in a plug-in form may also be deployed in the node device, the node device may run the P2P component code to locally form a P2P component instance, that is, a P2P plug-in, for example, both node device 3 and node device 5 in fig. 2 run a P2P plug-in locally, and the P2P plug-in may be shared by different blockchain nodes on the same node device, for example, a nodeb and a nodeb1 in the node device 3 may call the same P2P plug-in running on the node device 3 to share functions and data thereof. The node device is also provided with a blockchain service code, and the node device can run the blockchain service code to locally form a service instance, where any node device can implement at least one service instance, such as a storage instance for implementing a data read/write function, a calculation instance for implementing a calculation function such as privacy calculation, and an encryption instance for implementing a data encryption function, and details are not repeated.
Taking an example that a source node c1 in a source blockchain network subnet1 sends a cross-chain message to a destination node e2 in a destination blockchain network subnet2, a process of completing cross-chain interaction between any blockchain link node in any blockchain subnet and another blockchain node in another blockchain network in this specification is described. In the cross-link scenario related to the embodiment of the present specification, each source node in the source blockchain network and each destination node in the destination blockchain network are respectively disposed with a master network node in the blockchain master network on a node device where each source node and each destination node in the destination blockchain network are located, a master network node nodeb is further disposed on a node device 3 to which nodeb1 in subnet1 belongs, and a master network node nodeb is further disposed on a node device 5 to which nodeb2 in subnet2 belongs, although there is no direct network connection link between subnet1 and subnet2, since a network connection link implemented when a subnet0 is formed has been previously established between nodeb1 and nodeb2, the network connection link implemented when nodeb 0 is formed, the network connection link implemented when nodeb 0 is a network connection link implemented for mutual communication between node devices 3 and node devices 5, and specifically, the network connection link implemented when subnet0 is a link used for establishing a common identification and/synchronization between common identification nodes in subnet0, thus, nodeC1 may send a cross-link message to be sent from node apparatus 3 to node apparatus 5 over the network connection link established between nodeC and nodeE.
In this embodiment of the present specification, while a master network node and a slave network node on the same node device share a blockchain communication plug running on the node device, for example, the aforementioned P2P plug, and the network connection link implemented when forming the subnet0 is specifically established by using the P2P plug on the node device 3 and the node device 5 respectively through nodeC and nodeE, since the P2P plug on the node device can be shared by each blockchain node on the node device, the nodeC1 in the subnet1 can establish a network connection with the P2P plug running on the node device 5 to which the nodeE2 belongs by invoking the P2P plug locally running on the node device 3, and thus sending a cross-link message to the node device 5 by means of the network connection based on the P2P plug implemented when forming the subnet0, thereby further implementing a network communication link with the nodeE2 at the source region and making a new network link between the network source region and the blockchain destination network connection not needed, network communication between a source node in the source block chain network and a destination node in the destination block chain network is realized through a network connection link pre-established by a main network of the bottom layer block chain.
Each node in the subnet1 may need to use data stored by each node in the subnet2 in the process of implementing a service function, so that the subnet1 may request the subnet2 to acquire the data, and in the process of acquiring the data through the cross-chain interaction scheme described in this specification, a nodeb1 and a nodeb are disposed in the node device 3, a nodeb2 and a nodeb are disposed in the node device 5, and the other blockchain nodes are disposed in other node devices, respectively. For example, subnet1 may send a cross-chaining request to subnet2 in an attempt to obtain the contract state for a particular field in a particular contract held in the subnet 2's node database. It is to be understood that "subnet 1 sends a cross-link request to subnet 2" is "subnet node (i.e., source node) in subnet1 sends a cross-link request to subnet node (i.e., destination node) in subnet 2".
Specifically, any node in the subnet1 may encapsulate the network identifier of the destination blockchain network subnet2 in a cross-chain request, and broadcast the cross-chain request to the P2P plug running on each node device in which the main network node is deployed through the network connection link of the subnet0 by calling the P2P plug locally deployed by the node device and shared with the main network node in the subnet 0. In an embodiment, if the nodeA1 in the subnet1 sends out the cross-link request through the P2P plug-in on the node device 1, then all other node devices 2 to 5 deployed with the main network node will receive the cross-link request, for example, after receiving the cross-link request, the P2P plug-in on the node device 5 will determine, according to the network identifier carried in the cross-link request, whether the node device 5 is locally deployed with a blockchain link point in the blockchain network corresponding to the network identifier, obviously, the nodeE2 in the subnet2 is deployed on the node device 5, and therefore, the P2P plug-in on the node device 5 will further forward the cross-link request to the nodeE2 based on the network identifier, and after receiving the cross-link request, the P2P plug-in the node device 3 will also forward based on the network identifier carried by the plug-in the node device 3, but since the node device 3 is not locally deployed with a blockchain link point in the subnet2, the node device will not retain the cross-link request, but further forwards the cross-link request to other node devices deployed with the primary network node. In addition, any node in the subnet1 can encapsulate, in addition to the network identifier in the cross-link request, the identity information of any node in the destination blockchain network, such as the node ID and the node public key, in the cross-link request, so that, in the process of invoking the P2P plugin to implement the cross-link transmission cross-link request, the P2P plugin can directly send to the node device specified by each node identity information carried in the cross-lead request in a point-to-point communication manner without sending to the node device to which each main network node belongs in a broadcast manner, for example, the nodeC1 in the subnet1 can encapsulate the identity information of the nodeE2 in the cross-link request and invoke the P2P plugin locally running in the node device 3, so that the P2P plugin can send the cross-link request to the nodeE2 deployed in the subnet2 and the node device 355 in the subnet0 in a unicast manner according to the identity information of the nodeE2, and then receive the P2 plugin on the node device 355 in the node 2P, in addition to forwarding the cross-chain request to nodeE2 through the network identifier carried by the cross-chain request, the cross-chain request may also be forwarded to nodeE2 directly through the identity information of nodeE2 carried by the cross-chain request.
The above process describes a process in which the source blockchain network sends a cross-link request to the destination blockchain network through a network connection link established between each master network node in the blockchain master network, and similarly, the destination blockchain network may also implement message transmission to the source blockchain network in a similar manner, for example, cross-link data corresponding to the blockchain request sent by the source node is returned to the source blockchain network, so that network communication between the source node in the source blockchain network and the destination node in the destination blockchain network is implemented through a formed bidirectional communication channel between the source blockchain network and the destination blockchain network.
Fig. 2 is merely an exemplary illustration of the blockchain subnet1 and subnet2 in connection with fig. 1. In fact, cross-chain interaction can be implemented between each blockchain network in fig. 1, and the description does not limit the relationship between blockchain networks interacting across chains. For example, the inter-chain interaction between the blockchain main network subnet0 and the blockchain subnet1, and between the blockchain main network subnet0 and the blockchain subnet2 can be implemented, and the specific process is not described again.
The implementation of the cross-chain interaction scheme depends on the network connection link established by the blockchain main network, specifically, the network link established between each main network node, but in an actual scenario, not all main network nodes are consensus nodes, but there may be some non-consensus nodes that do not participate in transaction consensus and only participate in block synchronization, and for the non-consensus nodes, network links are not pre-established with all other main network nodes, so for the node device where such non-consensus nodes are located, the sub-network nodes deployed thereon will not normally implement the cross-sub-network interaction process based on the cross-chain interaction scheme that depends on the consensus links established by the blockchain main network, as shown in fig. 3, fig. 3 is an application scenario diagram of cross-sub-network interaction provided by an exemplary embodiment, which is based on the scenario shown in fig. 1, assuming that only part of the main network nodes nodeA, nodeB and nodeD of the block chain main network subnet0 are consensus nodes, for the consensus nodes, two pairwise connected consensus links are established between them, but for the non-consensus nodes nodeC or nodeE on subnet0, since they do not need to participate in the consensus process, only a synchronous link for a synchronization block needs to be established with any one of the consensus nodes, e.g., a synchronous link is established between nodeC and nodeA, a synchronous link is established between nodeE and nodeB, but nodeC does not have a network link directly connected to nodeB, nodeD and nodeE, and for the same reason, no network link is directly connected to nodeA, nodeC and nodeD, which means that assuming that nodeC1 belonging to sublevel 1 deployed on the node device 3 simultaneously is not deployed to a node device on which nodeE is deployed, it is not expected that a message is sent across the network link (i.e) between nodeC1 and a node 82) which is expected to belong to a node device on which is deployed simultaneously deployed on node 3, and a node 82, which is not established in advance, and a node 82 which is a cross-node 82 is established When the chain message transmission fails, the network connection link established based on the block chain main network cannot realize cross-subnet interaction.
Therefore, the cross-subnet interaction implementation scheme based on the blockchain main network can be implemented only when network links exist among all main network nodes, but non-consensus nodes on the main network are not considered completely, which means that in the case that the main network nodes include both consensus nodes and non-consensus nodes, unreachable cross-chain messages may be caused. In order to solve the problem, this specification provides a cross-subnet interaction method, in which a cross-chain message sent from a source subnet node in a first blockchain subnet to a target subnet node in a second blockchain subnet is obtained, and in a case where it is determined that a first node device is not a target node device where the target subnet node is located, a forwarding path with a minimum total delay between the first node device and the target node device is determined, and the cross-chain message is forwarded to the second node device on the forwarding path as a next hop, or in a case where it is determined that the first node device is the target node device, the cross-chain message is forwarded to the target subnet node.
The cross-subnet interaction method related to the present specification is described in detail below with reference to fig. 4. Fig. 4 is a flow chart of a method of interacting across subnets, provided by an exemplary embodiment. The method is applied to first node equipment, main network nodes in a block chain main network are deployed on the first node equipment, and a network topology structure between node equipment where each main network node in the block chain main network is respectively located and network delay information corresponding to the network topology structure are maintained on the first node equipment; the block chain main network is used for managing a block chain sub-network, and main network nodes are also deployed on the node devices of the sub-network nodes in the block chain sub-network; the method comprises the following steps:
s202: and acquiring a cross-link message sent by a source subnet node in the first blockchain subnet to a target subnet node in the second blockchain subnet.
In this embodiment of this specification, the acquiring a cross-link message sent by a source subnet node in a first blockchain subnet to a target subnet node in a second blockchain subnet includes: acquiring the cross-chain message generated by the source subnet node under the condition that the source subnet node is deployed in the first node device; and under the condition that the source subnet node is not deployed in the first node device, acquiring the cross-chain message forwarded by other node devices. The first node device related to the embodiment of the present specification may include a source node device where a source subnet node that initiates a span message is located, and at this time, because the source subnet node is disposed in the first node device, the span message may be directly acquired from the source subnet node; or the first node device may also include a node device serving as a relay station for the cross-link message or a target node device serving as a destination of the cross-link message, and at this time, since the source subnet node is not deployed in the first node device, the first node device receives the cross-link message forwarded from another node device, so as to obtain the cross-link message.
Since the first node device is deployed with the master network node, the first node device may generate a network topology structure between the node devices deployed with the master network node by querying a network connection relationship of each master network node in the block chain master network, and since the block chain master network manages subnet information of each block chain subnet, which includes identity information of each node member in any block chain subnet, a node device where the node device is located, and the like, the network topology structure maintained by the first node device includes, in addition to the network connection relationship between the node devices, a condition of the subnet node deployed on each node device, that is, the network topology structure includes an entire network structure of the block chain system formed by the block chain master network and each block chain subnet. The network topology can be represented in a graph form, for example, from the overall network structure shown in fig. 5, it is possible to distinguish the situation of the sub-network nodes deployed on the node devices deployed with the main network node and the network link situation between the node devices anchored by the network connection relationship of the main network nodes. Therefore, the node deployment situation and the connection relationship of each node device shown in fig. 5 can be regarded as an expression form for representing the network topology, and of course, the network topology can also be represented in a matrix or a table form, which is not limited herein.
In an embodiment of the present disclosure, the network topology is generated based on a network connection relationship between each master network node in the block chain master network, and the network connection relationship includes: the block chain main network comprises a consensus link established between consensus main network nodes in the block chain main network and a synchronous link established between the consensus main network nodes and non-consensus main network nodes. Taking fig. 4 as an example, the master network nodes a to E in the subnet0 in the blockchain master network are respectively deployed on the node devices 1 to 5, and any node device may query the consensus type of each master network node on the blockchain master network through the locally deployed master network node, for example, the node device 1 may learn that the nodeA, nodeB, and nodeD in the subnet0 are consensus nodes through the contract state of the system contract deployed by the subnet0, while the nodeC is a non-consensus node and the anchored synchronization node thereof is nodeA, that is, the nodeC only goes from the synchronization block on the nodeA and does not participate in the processes of transaction consensus, blocking, and the nodeE is also a non-consensus node and the anchored synchronization node thereof is nodeB. By obtaining the above information, the node device 1 may establish a network connection relationship between each main network node in the block chain main network, such as the network connection relationship between each main network node in subnet0 shown in fig. 4, where a pairwise connected consensus link is established between nodeB, and nodeB is connected only to nodeB through a synchronization link. Since the main network nodes are deployed on the node devices, after the network connection relationship between the main network nodes is determined, the network topology between the node devices in which the respective master network nodes in the blockchain master network are located is thus also determined, and since node device 1 can also find the node devices where each node member is located in any blockchain subnet through contract state search of subnet management contracts deployed by subnet0, therefore, the network topology structure of each node device generated by the node device 1 through the network connection relationship of each main network node also includes the situation of the sub-network node locally deployed by each node device, namely, the network topology also includes the distribution situation of the sub-network nodes in each block chain sub-network on the node device, the network topology that the node apparatus 1 can ultimately maintain is then as shown in fig. 5, and similarly, other node apparatuses maintain the same network topology.
In this embodiment of the present specification, the first node device further maintains network delay information corresponding to the network topology, where the network delay information includes: link delay of network links in the network topology, and/or node delay of node devices in the network topology when forwarding messages. As shown in fig. 5, the first node device maintains not only the network topology between the node devices but also the link delay of each network link and the node delay of each node device included in the network 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 the node device 1 and the node device 2 in fig. 5 is 100; the node delay of the node device refers to time delay information required for a message to be forwarded out of the node device after entering the node device, and specifically includes a process of the node device analyzing, looking up a routing table and forwarding the message, for example, the node delay of the node device 1 in fig. 5 is 3, and the forwarding delay of the node device 4 is 5. 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, if the link delay 100 of the network link between node device 1 and node device 2 is understood to be 100 milliseconds (ms), i.e., 100ms is required to characterize a message passing through the network link, then the node delay 3 of node device 1 is understood to be 3 ms.
S204: and under the condition that the first node device is determined not to be the target node device where the target subnet node is located, determining a forwarding path with the minimum total delay between the first node device and the target node device from the network topology structure based on the network delay information, and forwarding the cross-link message to a second node device which is the next hop on the determined forwarding path.
In an embodiment of this specification, the cross-link message includes identity information of the target subnet node, and the method further includes: and comparing the identity information corresponding to each locally deployed block link point of the first node equipment with the identity information of the target subnet node to determine whether the first node equipment is the target node equipment. Because the cross-link message contains the identity information of the target subnet node and each node device locally maintains the identity information corresponding to each locally deployed block link node, therefore, the first node device can compare the identity information corresponding to each locally deployed block link point of the first node device with the identity information of the target subnet node, in the case of locally deployed block chain nodes with corresponding identity information identical to that contained in the cross-chain message, it may be determined that the first node device is a target node device and forward the cross-chain message to the blockchain node, in the case that the identity information of each locally deployed blockchain node is different from the identity information contained in the cross-chain message, it may be determined that the first node device is not the target node device, and therefore, a forwarding path needs to be further determined and the cross-link message needs to be forwarded. Specifically, the identity information carried by the cross-chain message may include at least one of the following: the node identifier of the target subnet node, the public key of the target subnet node, and the network identifier of the second blockchain subnet.
Because the network topology maintained by the first node device includes the network link connection relationship between the node devices, the first node device may generate a forwarding path between the first node device and the target node device, when determining the relative network location relationship between the first node device corresponding to the first node device and the target node device in the network topology and ensuring reachability. Taking the nodeC1 in the subnet1 in fig. 5 to send a cross-chain message to the node 2 in the subnet2, and the first node device is the nodeC1 and the node device 3 where the nodeC is located as an example, a process of generating a forwarding path and forwarding based on the path in this specification is described. Since the node device 3 is deployed with the source subnet node nodeb1, it may directly obtain a cross-chain message from the nodeb1 and read from the cross-chain message that the identity information corresponding to the target subnet node carried by the cross-chain message is a public key corresponding to nodeb2, obviously, the node device 3 is not deployed with nodeb2 and therefore does not maintain a public key corresponding to nodeb2, and then the node device 3 needs to determine a forwarding path from the node device 3 to the node device 5 (target node device) where nodeb2 is located based on the network topology, obviously, a network link that is not directly connected between the node device 3 and the node device 5 may be found according to the network topology, and in the forwarding path that does not consider a loop and an original return path, the forwarding path between the node device 3 and the node device 5 includes two paths: first, node device 3 → node device 1 → node device 2 → node device 5; second, node device 3 → node device 1 → node device 4 → node device 2 → node device 5. After determining the two selectable forwarding paths, the node device 4 further determines, based on the network delay information, a forwarding path with a minimum total delay between the node device 3 (first node device) and the node device 5 (target node device) 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 node device to the target node device on the forwarding path and/or a node delay of at least one node device that passes through the forwarding path (excluding the first node device and the target node device). Therefore, when determining the total delay of the forwarding path, the first node device may calculate only the link delays of all network links passing from the first node device to the target node device, may also calculate only the node delays of all node devices passing from the first node device to the target node device, and may also consider the link delays of all network links passing from the first node device to the target node device and the node delays of all node devices of the routes at the same time. For example, taking fig. 5 as an example, since the total delay of all network links and all node devices of the forwarding path route of node device 3 → node device 1 → node device 2 → node device 5 is 166, and the total delay of all network links and all node devices of the forwarding path route of node device 3 → node device 1 → node device 4 → node device 2 → node device 5 is 131, the forwarding path finally determined by node device 3 is node device 3 → node device 1 → node device 4 → node device 2 → node device 5, so that node device 3 can further determine that the second node device as the next hop in the forwarding path is node device 1, and then forward the cross-chain message to node device 1.
In this embodiment of this specification, the forwarding the cross-link message to the second node device on the forwarding path as the next hop includes: and forwarding the cross-link message to the second node device serving as the next hop on the forwarding path through a network link established between the main network node on the first node device and the main network node on the second node device. Specifically, the network link is established between a communication plug-in running on the first node device and a communication plug-in running on the second node device, for example, the aforementioned P2P plug-in; the main network node and the sub-network node on the same node device share the communication plug-in running on the node device. As introduced in the foregoing cross-chain interaction scheme, network communication between a source node in a source blockchain network and a destination node in a destination blockchain network can be achieved through network connection links (including a common link and a synchronization link) established by each master network node in a blockchain master network, so that a new network connection link does not need to be established between a second blockchain subnet and a first blockchain subnet, but through a network connection link established in advance by a bottom-layer blockchain master network.
Optionally, the method further includes: forwarding the cross-link message to the target subnet node if the first node device is determined to be the target node device.
Taking the nodeC1 in the subnet1 in fig. 7 to send the cross-chain message to the node 2 in the subnet2, and the first node device is the node 2 and the node device 5 where the node is located as an example, the process of the present specification that the cross-chain message is finally forwarded to the target subnet node is described. Since node device 5 is deployed with nodeb2, after node device 5 acquires a span message from another node device, the public key corresponding to nodeb2 read from the span message is also maintained local to node device 5, and then node device 5 forwards the span message to nodeb2 that has been deployed locally, thereby completing the whole process of cross-subnet interaction.
The scheme is applied to the first node equipment with a main network node, and the network topology structure of each node equipment where the main network node is located and the network delay information corresponding to the network topology structure are maintained on the first node equipment, so that even if a network link directly connected with target node equipment where a target sub-network node is located does not exist in the first node equipment locally, a forwarding path to the target node equipment can be found in a rerouting forwarding mode, cross-link information is firstly transmitted to other node equipment, and then the cross-link information is gradually transmitted to the target node equipment by other node equipment. Based on this, no matter whether a directly connected network link is established on the first node device through the blockchain main network in advance with the target node device, the cross-link message can be forwarded to the target node device under the condition that the target node device has accessibility on a physical link (including the condition that the target node device is directly connected through one segment of network link and is indirectly connected through multiple segments of network links), so that normal operation of cross-link interaction service between the blockchain sub networks is ensured, and the problem that the cross-link message is not accessible under the condition that the main network node contains both the common identification node and the non-common identification node is solved. Meanwhile, the process of determining the forwarding path takes the network delay information corresponding to the network topology structure into consideration, so that the cross-chain message can be forwarded through the forwarding path with the minimum total delay, and the forwarding efficiency of the cross-chain message is optimized.
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 network topology, where the near-end network link is a network link between the first node device and a neighboring node device thereof, and the far-end network link is a network link in the network topology other than the near-end network link. The neighbor node device of the first node device refers to a node device directly connected to the first node device through a network link, and taking fig. 5 as an example, the neighbor node device corresponding to the node device 1 includes a node device 2, a node device 3, and a node device 4, and the neighbor node device of the node device 4 includes the node device 1 and the node device 2.
For the first node device, 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 node device, namely a network link between the first node device and the neighbor node device; the far-end network link refers to a network link that is not directly connected to the first node device, that is, a network link in the network topology structure except for the near-end network link corresponding to the first node device. Still taking fig. 5 as an example, the near-end network links corresponding to the node device 1 include network links between the node device 1 and the node device 3, between the node device 4 and the node device 5, and the far-end network links corresponding to the node device 1 include network links between the node device 1 and the node device 2, between the node device 4 and the node device 2, and between the node device 2 and the node device 5.
The first node device obtains link delay according to different strategies according to different types of network links. The first node equipment 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 node device through a request response mechanism, and the opposite end link delay is obtained by detecting the near end network link by a neighbor node device of the first node device through the request response mechanism; and/or receiving link delay of the remote network link sent by a neighbor node device of the first node device, where 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 node device 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 node device may determine the link delay of the near-end network link by the request-reply mechanism described above. For example, the first node device may actively initiate a request-response mechanism to its neighboring node device, so as to determine a link delay of a near-end network link between the first node device and the neighboring node device, where the link delay of the near-end network measured by the first node device through the request-response mechanism is referred to as a local-end link delay. On the other hand, for any network link, the two end devices included in the network link may measure the link delay of the network link by initiating the request-response mechanism, so that the first node device may also directly obtain the link delay of the near-end network link between the first node device and the neighboring node device by receiving the link delay of the near-end network link between the first node device and the neighboring node device measured by the request-response mechanism of the neighboring node device, where the link delay of the near-end network link measured by the neighboring node device and provided to the first node device is referred to as the opposite-end link delay. In summary, the first node device 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 and recorded in the network delay information by the first node device 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 a weighted average of the local-end link delay and the opposite-end link delay, the network delay information maintained by the first node device can be made more robust.
Taking fig. 5 as an example, assume that the local end link delay of the near-end network link between node device 1 and node device 2 measured by initiating the request-reply mechanism is 102, and node device 2 measures the peer-to-peer link delay of the near-end network link through the origination request response mechanism to be 98, then, for node device 1, it may directly determine its own measured home link delay 102 as the link delay of the near-end network link with node device 2, or the opposite-end link delay 98 measured by the node device 2 and received from the node device 2 is determined as the link delay of the near-end network link, and the average 100 of the local-end link delay and the opposite-end link delay may also be determined as the link delay of the near-end network link according to the weight ratio of 1:1, and recorded in the network delay information locally maintained by the node device 1.
Since the first node device can only directly measure the link delay of the near-end network link between the first node device and the neighboring node device, 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 a link delay sharing message containing the link delay of the far-end network link, which is sent or forwarded by the neighboring node device, 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 node device receives, from the neighbor node device of the first node device, a link delay of the remote network link, where the link delay of the remote network link is determined by a link delay obtained by at least one end node device of the remote network link detecting the remote network link through a request response mechanism, and for example, the link delay of the remote network link may include: the link delay obtained by detection of any end node device of the far-end network link, or the weighted average of the link delays obtained by detection of the node devices at both ends of the far-end network link. The link delay detected by any end node device is the link delay for the far-end network link, and the network delay information maintained by the first node device can be made more robust under the condition that the link delay of the far-end network link is the weighted average of the link delays detected by the node devices at the two ends of the far-end network link.
As shown in fig. 5, assuming that the first node device is the node device 1, for the node device 1, the link delay of the remote network link between the node device 2 and the node device 5 cannot be directly measured by the request-response mechanism, but the node device 2 and/or the node device 5 need to measure and determine by initiating the request-response mechanism, and the node device 2 encapsulates the link delay of the finally determined remote network link into the link delay sharing message to be sent or forwarded to the node device 1, and the node device 1 updates the network delay information maintained by itself based on the acquired link delay of the remote network link.
The first node device may receive the measured far-end link delay from the neighboring node device, and in one embodiment, further includes: and receiving a response message sent by the neighbor node equipment of the first node equipment 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 node device may be directly carried in a response message involved when the first node device initiates a request response mechanism to the neighboring node device, so that the first node device 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 network internal interaction. In another embodiment, the peer link delay and/or the link delay of the remote network link may also be carried in other messages sent by the neighboring node device or forwarded to the first node device.
As mentioned above, the network delay information includes: link delay of network links in the network topology, and/or node delay of node devices in the network topology when forwarding messages. Optionally, the method further includes: acquiring node delay obtained by detecting any node device by at least one neighbor node device of any node device in the network topology structure, and determining the node delay of any node device according to the acquired node delay; and/or receiving the node delay of any node device shared by other node devices. In this embodiment of the present specification, the node delay of any node device needs to be measured by any neighbor node device corresponding to the node device, specifically, measured by any neighbor node corresponding to the node device 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 node device of any node device, of any node device includes: the method comprises the steps that any neighbor node device sends a backflow message to any node device, the node delay of any node device is determined according to the forwarding delay of the backflow message and the link delay of a network link between any neighbor node device and any node device, and the backflow message is a message that a destination address sent to any node device by any neighbor node device points to any neighbor node device. As previously described, for a node delay of any node device, any neighbor node device of the any node device may initiate a backflow message mechanism to measure.
For the node delay of a certain neighbor node device of the first node device, the first node device may directly detect the node delay by initiating the backflow message mechanism, and of course, since the node device directly connected to the neighbor node device may not only include the first node device, the first node device may also receive the node delay corresponding to the neighbor node device, which is measured by the node devices through the backflow message mechanism, and use the node delay as a reference to finally determine the node delay corresponding to the neighbor node device. Taking fig. 5 as an example, assuming that the node device 1 detects that the node delay of the node device 4 is 3 by initiating a backflow message mechanism to the node device 4, and at the same time, receives that the node delay of the node device 4 is 7 by initiating a backflow message mechanism to the node device 4 by the node device 2, for the node device 1, it may directly determine the node delay 3 measured by itself as the node delay with the node device 4 and record it in the network delay information locally maintained by the node device 1, or determine the node delay 7 measured by the node device 2 received from the node device 2 as the node delay of the node device 4 and record it in the network delay information locally maintained by the node device 1, or determine the average 5 of the node delay 3 measured by itself and the node delay 7 measured by the node device 2 as the node delay of the node device 4 according to the weight ratio of 1:1, and records it in network delay information maintained locally by the node apparatus 1.
For the first node device, it cannot detect the node delay of the node device other than the neighboring node device through the backflow message mechanism, so the first node device may also obtain the node delay of any node device through other manners, for example, the first node device may directly receive the node delay of any node device shared by other node devices. Taking fig. 5 as an example, the node device 1 cannot directly detect the node delay of the node device 5, but the node device 2 can measure the node delay, so that the node device 1 can directly receive the node delay sharing message which is sent to the node device 1 by the node device 2 and carries the node delay of the node device 5, thereby obtaining and determining that the node delay of the node device 5 is 2, and finally recording the node delay in the local network delay information. Certainly, the node device 1 does not need to acquire the node delay of the node device 5 from the node device 2, and in fact, the network delay information maintained by the node device 4 actually includes the node delay of the node device 5 through the aforementioned node delay acquisition manner, so the node device 1 may also receive the node delay sharing message carrying the node delay of the node device 5 and sent by the node device 4, so as to acquire the node delay of the node device 5.
The node delay of any node device in the network delay information maintained by the first node device includes: the node delay obtained by detecting any node device by any neighbor node device of any node device, or the weighted average of the node delays obtained by detecting any node device by at least one neighbor node device of any node device. As described above, for the node delay of any node device, any neighbor node of any node device may be detected, so that when the first node device finally determines the node delay of any node device, the first node device may directly record the node delay, which is detected by any neighbor node of any node device, for any node device in the locally maintained network delay information, or may determine a weighted average of the node delays, which are detected by one or more neighbor node devices of any node device for any node device, as the node delay of any node device, and record the node delay in the locally maintained network delay information. In the case that the node delay of any node device is finally determined as the weighted average of the node delays detected by at least one neighboring node device of any node device, the network delay information maintained by the first node device may be made more robust.
Taking fig. 5 as an example, the node device 1 may receive the node delay 1 of the node device 1 detected by the node device 3, the node delay 3 of the node device 1 detected by the node device 2, and the node delay 5 of the node device 1 detected by the node device 4, respectively, at this time, the node device 1 may optionally select the node delay of the node device 1 measured by one of the node devices as the node delay of the node device 1 in the locally maintained network delay information, or determine the weighted average 1.5 of the node delay measured by the node device 3 and the node delay measured by the node device 2 as the node delay of the node device 1 in the network delay information according to the weight ratio of 3:1, the weighted average 3 of the node delays of the node device 1 detected by the three node devices may also be determined as the node delay of the node device 1 in the network delay information according to the weight ratio of 1:1: 1.
FIG. 6 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 6, at the hardware level, the apparatus includes a processor 602, an internal bus 604, a network interface 606, a memory 608 and a non-volatile memory 610, 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 602 reading corresponding computer programs from non-volatile memory 610 into memory 608 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. 7 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. 6 to implement the technical solution of the present specification; the device is applied to first node equipment, main network nodes in a block chain main network are deployed on the first node equipment, and a network topology structure between node equipment where each main network node in the block chain main network is respectively located and network delay information corresponding to the network topology structure are maintained on the first node equipment; the block chain main network is used for managing a block chain sub-network, and main network nodes are also deployed on the node devices of the sub-network nodes in the block chain sub-network; the device comprises:
a message obtaining unit 701, configured to obtain a chain crossing message sent from a source subnet node in a first blockchain subnet to a target subnet node in a second blockchain subnet;
a path forwarding unit 702, configured to, when it is determined that the first node device is not the target node device where the target subnet node is located, determine, based on the network delay information, a forwarding path with the minimum total delay between the first node device and the target node device from the network topology, and forward the cross-link message to a second node device on the determined forwarding path as a next hop.
Optionally, the method further includes:
a node forwarding unit 703, configured to forward the cross-link message to the target subnet node when it is determined that the first node device is the target node device.
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 network topology, where the near-end network link is a network link between the first node device and a neighboring node device thereof, and the far-end network link is a network link in the network topology except for the near-end network link.
Optionally, the method further includes:
a link delay obtaining unit 704, 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 node device through a request response mechanism, and the opposite end link delay is obtained by detecting the near end network link by a neighbor node device of the first node device through the request response mechanism; and/or the presence of a gas in the gas,
receiving link delay of the remote network link sent by a neighbor node device of a first node device, where 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 node device of the remote network link through a request response mechanism.
Optionally, the method further includes:
a response receiving unit 705, configured to receive a response message sent by a neighboring node device of the first node device in a request response mechanism, where the response message includes the opposite-end link delay 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 detection of any end node device of the far-end network link, or the weighted average of the link delays obtained by detection of the node devices at both ends of the far-end network link.
Optionally, the network delay information includes: link delay of network links in the network topology, and/or node delay of node devices in the network topology when forwarding messages.
Optionally, the method further includes:
a node delay obtaining unit 706, configured to obtain a node delay obtained by detecting any node device by at least one neighboring node device of any node device in the network topology, and determine the node delay of any node device according to the obtained node delay; and/or the presence of a gas in the gas,
receiving the node delay of any node device shared by other node devices.
Optionally, the detecting, by any neighbor node device of any node device, of any node device includes:
the method comprises the steps that any neighbor node device sends a backflow message to any node device, the node delay of any node device is determined according to the forwarding delay of the backflow message and the link delay of a network link between any neighbor node device and any node device, and the backflow message is a message that a destination address sent to any node device by any neighbor node device points to any neighbor node device.
Optionally, the node delay of any node device includes:
the node delay obtained by detecting any node device by any neighbor node device of any node device, or the weighted average of the node delays obtained by detecting any node device by at least one neighbor node device of any node device.
Optionally, the network topology is generated based on a network connection relationship between each master network node in the block chain master network.
Optionally, the network link corresponding to the network connection relationship includes: the block chain main network comprises a consensus link established between consensus main network nodes in the block chain main network and a synchronous link established between the consensus main network nodes and non-consensus main network nodes.
Optionally, the message obtaining unit 701 is specifically configured to:
acquiring the cross-chain message generated by the source subnet node under the condition that the source subnet node is deployed in the first node device;
and under the condition that the source subnet node is not deployed in the first node device, acquiring the cross-chain message forwarded by other node devices.
Optionally, the cross-link message includes identity information of the target subnet node, and the apparatus further includes:
an identity confirmation unit 707, configured to compare identity information corresponding to each locally deployed block link node of the first node device with the identity information of the target subnet node, to determine whether the first node device is the target node device.
Optionally, the path forwarding unit 702 is specifically configured to:
and forwarding the cross-link message to the second node device serving as the next hop on the forwarding path through a network link established between the main network node on the first node device and the main network node on the second node device.
Optionally, the network link is established between a communication plug-in running on the first node device and a communication plug-in running on the second node device; the main network node and the sub-network node on the same node device share the communication plug-in running on the node device.
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 Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. 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 (19)
1. A cross-subnet interaction method is applied to first node equipment, wherein the first node equipment is provided with main network nodes in a block chain main network, and the first node equipment maintains a network topology structure between node equipment where each main network node in the block chain main network is respectively located and network delay information corresponding to the network topology structure; the block chain main network is used for managing a block chain sub-network, and main network nodes are also deployed on the node devices of the sub-network nodes in the block chain sub-network; the method comprises the following steps:
acquiring a cross-link message sent by a source subnet node in a first block link subnet to a target subnet node in a second block link subnet;
and under the condition that the first node device is determined not to be the target node device where the target subnet node is located, determining a forwarding path with the minimum total delay between the first node device and the target node device from the network topology structure based on the network delay information, and forwarding the cross-link message to a second node device which is the next hop on the determined forwarding path.
2. The method of 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 network topology, the near-end network links being network links between a first node device and its neighbor node devices, the far-end network links being network links in the 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 node device through a request response mechanism, and the opposite end link delay is obtained by detecting the near end network link by a neighbor node device of the first node device through the request response mechanism; and/or the presence of a gas in the gas,
receiving link delay of the remote network link sent by a neighbor node device of a first node device, where 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 node device of the remote network link through a request response mechanism.
4. The method of claim 3, further comprising:
and receiving a response message sent by the neighbor node equipment of the first node equipment 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,
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 detection of any end node device of the far-end network link, or the weighted average of the link delays obtained by detection of the node devices at both ends of the far-end network link.
6. The method of claim 1, the network delay information comprising: link delay of network links in the network topology, and/or node delay of node devices in the network topology when forwarding messages.
7. The method of claim 6, further comprising:
acquiring node delay obtained by detecting any node device by at least one neighbor node device of any node device in the network topology structure, and determining the node delay of any node device according to the acquired node delay; and/or the presence of a gas in the gas,
receiving the node delay of any node device shared by other node devices.
8. The method of claim 7, wherein any neighbor node device of the any node device detects the any node device, and the method comprises:
the method comprises the steps that any neighbor node device sends a backflow message to any node device, the node delay of any node device is determined according to the forwarding delay of the backflow message and the link delay of a network link between any neighbor node device and any node device, and the backflow message is a message that a destination address sent to any node device by any neighbor node device points to any neighbor node device.
9. The method of claim 7, the node latency of any node device, comprising:
the node delay obtained by detecting any node device by any neighbor node device of any node device, or the weighted average of the node delays obtained by detecting any node device by at least one neighbor node device of any node device.
10. The method of claim 1, the network topology being generated based on network connection relationships between master network nodes in the blockchain master network.
11. The method of claim 10, wherein the network link corresponding to the network connection relationship comprises: the block chain main network comprises a consensus link established between consensus main network nodes in the block chain main network and a synchronous link established between the consensus main network nodes and non-consensus main network nodes.
12. The method of claim 1, wherein the obtaining of the cross-link message sent by a source subnet node in a first blockchain subnet to a target subnet node in a second blockchain subnet comprises:
acquiring the cross-chain message generated by the source subnet node under the condition that the source subnet node is deployed in the first node device;
and under the condition that the source subnet node is not deployed in the first node device, acquiring the cross-chain message forwarded by other node devices.
13. The method of claim 1, the cross-link message including identity information of the target subnet node, the method further comprising:
and comparing the identity information corresponding to each locally deployed block link point of the first node equipment with the identity information of the target subnet node to determine whether the first node equipment is the target node equipment.
14. The method of claim 1, the forwarding the cross-link message to a second node device on the forwarding path as a next hop, comprising:
and forwarding the cross-link message to the second node device serving as the next hop on the forwarding path through a network link established between the main network node on the first node device and the main network node on the second node device.
15. The method of claim 14, wherein the network link is established between a communication plug-in running on a first node device and a communication plug-in running on a second node device; the main network node and the sub-network node on the same node device share the communication plug-in running on the node device.
16. The method of claim 1, further comprising:
forwarding the cross-link message to the target subnet node if the first node device is determined to be the target node device.
17. A cross-subnet interaction device is applied to first node equipment, wherein the first node equipment is provided with main network nodes in a block chain main network, and the first node equipment maintains a network topology structure between node equipment where each main network node in the block chain main network is respectively located and network delay information corresponding to the network topology structure; the block chain main network is used for managing a block chain sub-network, and main network nodes are also deployed on the node devices of the sub-network nodes in the block chain sub-network; the device comprises:
the message acquisition unit is used for acquiring a chain crossing message sent from a source subnet node in the first blockchain subnet to a target subnet node in the second blockchain subnet;
and a path forwarding unit, configured to, when it is determined that the first node device is not a target node device where the target subnet node is located, determine, based on the network delay information, a forwarding path with a minimum total delay between the first node device and the target node device from the network topology, and forward the cross-link message to a second node device serving as a next hop on the determined forwarding path.
18. 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-16 by executing the executable instructions.
19. 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 16.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111669884.6A CN114301828A (en) | 2021-12-31 | 2021-12-31 | Cross-subnet interaction method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111669884.6A CN114301828A (en) | 2021-12-31 | 2021-12-31 | Cross-subnet interaction method and device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114301828A true CN114301828A (en) | 2022-04-08 |
Family
ID=80974100
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111669884.6A Pending CN114301828A (en) | 2021-12-31 | 2021-12-31 | Cross-subnet interaction method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114301828A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114978507A (en) * | 2022-05-26 | 2022-08-30 | 福建博思软件股份有限公司 | Electronic bill block chain networking method, device, terminal and storage medium |
| CN115567542A (en) * | 2022-12-01 | 2023-01-03 | 杭州蚂蚁酷爱科技有限公司 | Node set maintenance method and device |
| CN116192692A (en) * | 2022-12-30 | 2023-05-30 | 蚂蚁区块链科技(上海)有限公司 | Method for distributing consensus data in block chain network and block chain network |
| WO2023124744A1 (en) * | 2021-12-31 | 2023-07-06 | 支付宝(杭州)信息技术有限公司 | Cross-subnet interaction |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113259455A (en) * | 2021-06-02 | 2021-08-13 | 支付宝(杭州)信息技术有限公司 | Cross-subnet interaction method and device |
-
2021
- 2021-12-31 CN CN202111669884.6A patent/CN114301828A/en active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113259455A (en) * | 2021-06-02 | 2021-08-13 | 支付宝(杭州)信息技术有限公司 | Cross-subnet interaction method and device |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023124744A1 (en) * | 2021-12-31 | 2023-07-06 | 支付宝(杭州)信息技术有限公司 | Cross-subnet interaction |
| CN114978507A (en) * | 2022-05-26 | 2022-08-30 | 福建博思软件股份有限公司 | Electronic bill block chain networking method, device, terminal and storage medium |
| CN115567542A (en) * | 2022-12-01 | 2023-01-03 | 杭州蚂蚁酷爱科技有限公司 | Node set maintenance method and device |
| CN116192692A (en) * | 2022-12-30 | 2023-05-30 | 蚂蚁区块链科技(上海)有限公司 | Method for distributing consensus data in block chain network and block chain network |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114301828A (en) | Cross-subnet interaction method and device, electronic equipment and storage medium | |
| CN113259455B (en) | Cross-subnet interaction method and device | |
| CN114285755B (en) | Cross-subnet interaction method and device, electronic equipment and storage medium | |
| CN113067904B (en) | Method for building block chain sub-network and block chain system | |
| CN113067897B (en) | Cross-chain interaction method and device | |
| CN113259457B (en) | Information synchronization method and device for block chain sub-network | |
| CN113067895B (en) | Method for building block chain sub-network and block chain system | |
| CN113098982B (en) | Block chain message transmission method and device | |
| WO2023050966A1 (en) | Blockchain data verification | |
| CN114363335B (en) | Cross-chain interaction method and device | |
| CN115134075A (en) | Cross-subnet calling method and device, electronic equipment and storage medium | |
| CN114374699B (en) | Cross-chain interaction method and audit method of cross-chain interaction | |
| CN113259120B (en) | Method for synchronizing node information lists | |
| CN114363162A (en) | Block chain log generation method and device, electronic equipment and storage medium | |
| CN113259458A (en) | Method and device for starting/closing block link point service | |
| CN114422520B (en) | Cross-chain interaction method and device | |
| WO2023124743A1 (en) | Block synchronization | |
| CN114866560B (en) | Block chain node migration method and device, electronic equipment and readable storage medium | |
| CN114422526B (en) | Block synchronization method and device, electronic equipment and storage medium | |
| CN114338714B (en) | Block synchronization method and device, electronic equipment and storage medium | |
| CN114095507B (en) | Cross-chain interaction method and block chain system | |
| CN114710350A (en) | Allocation method and device for callable resources | |
| CN115086338A (en) | Block chain subnet building method and device | |
| CN114338676B (en) | Block synchronization method and device, electronic equipment and storage medium | |
| CN114363359A (en) | Block synchronization method and device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20220408 |
|
| RJ01 | Rejection of invention patent application after publication |