CN116192692A

CN116192692A - Method for distributing consensus data in block chain network and block chain network

Info

Publication number: CN116192692A
Application number: CN202211735064.7A
Authority: CN
Inventors: 虎振兴; 徐文博; 肖臻; 管圣杰; 丁秋雨; 李鹏泽; 石杰; 丁慧; 曾超
Original assignee: Peking University; Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Peking University; Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-12-30
Filing date: 2022-12-30
Publication date: 2023-05-30

Abstract

A method of data transmission delay detection in a blockchain network, comprising: receiving a detection message which is periodically broadcast and sent by a consensus node in the consensus sub-network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first moment when the consensus node sends the detection message; and in response to the detection message, adding a second network address of the target relay node and a second timestamp corresponding to a second moment when the target relay node transmits the detection message in the detection message, and continuously forwarding the detection message added with the second network address and the second timestamp to other non-consensus nodes which establish network connection with the target relay node, so that a common node in the other non-consensus nodes calculates data transmission delay of a data transmission path between the second network address serving as a transfer and the first network address based on the timestamps contained in the received detection message.

Description

Method for distributing consensus data in block chain network and block chain network

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a consensus data distribution method in a block chain network, the block chain network and node equipment.

Background

Blockchains are a decentralized, distributed ledger that does not require trust from a third party. The blockchain technology has the characteristics of multiparty writing, transparent disclosure, non-falsification and the like. Blockchains can be categorized into public chains, alliance chains, and private chains, depending on the admission mechanism. For the public chain, any node may join the blockchain network. The alliance chain has an access control function, and only authorized nodes can join the alliance chain network, so that the alliance chain is more safe and efficient than a public chain network, and is mainly used for mutual cooperation among enterprises or institutions. However, in practical application, when the scale of the blockchain node gradually increases, the existing network topology organization manner of the blockchain may cause low bandwidth utilization rate of data distribution, and slow data distribution speed, so that it is difficult to meet the requirement of efficient data transmission under a large-scale blockchain network.

Disclosure of Invention

The specification provides a data transmission delay detection method in a blockchain network, wherein the blockchain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively; the method is applied to any target relay node in any target area sub-network; comprising the following steps:

Receiving a detection message which is periodically broadcast and sent by a consensus node in the consensus sub-network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first time when the consensus node sends the detection message;

and in response to the probe message, adding a second network address of the target relay node and a second timestamp corresponding to a second time when the target relay node sends the probe message in the probe message, and continuously forwarding the probe message added with the second network address and the second timestamp to other non-consensus nodes which establish network connection with the target relay node, so that a common node in the other non-consensus nodes calculates data transmission delay of a data transmission path between the second network address serving as a relay and the first network address based on each timestamp contained in the received probe message.

The specification also provides a data transmission delay detection method in a blockchain network, wherein the blockchain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively; the method is applied to any target common node in any target area sub-network; comprising the following steps:

Receiving a detection message forwarded by a target relay node which establishes network connection with the target common node; the detection message is received by the target relay node, and the detection message is periodically broadcast and sent by a consensus node in the consensus sub-network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first moment when the consensus node sends the detection message; and adding a second network address of the target relay node in the probe message and a second timestamp corresponding to a second moment of the probe message transmission by the target relay node when the probe message is transmitted by the target relay node;

and calculating the data transmission delay of a data transmission path between the second network address serving as a transit and the first network address based on each time stamp contained in the received detection message.

The specification also provides

A blockchain network, comprising: a consensus sub-network composed of a plurality of consensus nodes, and at least one regional sub-network corresponding to different geographic locations respectively; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively;

The consensus node periodically broadcasts and transmits a detection message in the block chain network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first moment when the consensus node sends the detection message;

the relay node receives the detection message, responds to the received detection message, adds a second network address of the relay node and a second timestamp corresponding to a second moment when the relay node transmits the detection message in the detection message, and continuously broadcasts and transmits the detection message added with the second network address and the second timestamp to other non-consensus nodes which establish network connection with the relay node;

and a common node which establishes network connection with the relay node calculates data transmission delay of a data transmission path between the relay node and the first network address by taking the second network address as a transfer based on each time stamp contained in the received probe message.

The specification also provides node equipment in a blockchain network, wherein the blockchain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively; comprising the following steps:

The first receiving module is used for receiving the detection message which is periodically broadcast and sent by the consensus node in the consensus sub-network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first time when the consensus node sends the detection message;

and the sending module is used for responding to the detection message, adding a second network address of the target relay node and a second timestamp corresponding to a second moment when the target relay node sends the detection message in the detection message, and continuously forwarding the detection message added with the second network address and the second timestamp to other non-consensus nodes which establish network connection with the target relay node, so that a common node in the other non-consensus nodes calculates data transmission delay of a data transmission path between the second network address serving as a relay and the first network address based on the received timestamps contained in the detection message.

The second receiving module is used for receiving the detection message forwarded by the target relay node which establishes network connection with the target common node; the detection message is received by the target relay node, and the detection message is periodically broadcast and sent by a consensus node in the consensus sub-network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first moment when the consensus node sends the detection message; and adding a second network address of the target relay node in the probe message and a second timestamp corresponding to a second moment of the probe message transmission by the target relay node when the probe message is transmitted by the target relay node;

and the calculation module is used for calculating the data transmission delay of a data transmission path between the second network address serving as a transit and the first network address based on each time stamp contained in the received detection message.

In the above embodiment, on the one hand, by dividing the non-consensus node in the regional subnetwork into relay nodes that receive the consensus data from the consensus node; and the common node receives the common data forwarded by the relay node from the relay node, so that the common node in the common sub-network can distribute the common data to the relay node when distributing the common data to the non-common nodes in each regional sub-network, and then the common data are forwarded to each common node by the relay node without respectively distributing the common data to each non-common node, thereby reducing the bandwidth load of the common layer of the blockchain network when distributing the common data and improving the common efficiency.

On the other hand, the detection message periodically broadcast by the consensus node comprises the network address of the consensus node and a time stamp corresponding to the time when the consensus node transmits the detection message, and the relay node adds the network address of the relay node and the time stamp corresponding to the time when the relay node transmits the detection message when continuing to broadcast the detection message; therefore, for the common node in the regional subnetwork, after receiving the probe message, the data transmission delay of the data transmission path which takes the relay node as the relay and reaches the common node can be calculated based on each time stamp contained in the probe message, so that the common node can select the data transmission path with the minimum data transmission delay to receive the common data when receiving the common data, and the data transmission delay of the common node when distributing the common data can be effectively reduced.

Drawings

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

FIG. 1 is a networking architecture diagram of a blockchain network as illustrated in the present specification in accordance with an exemplary embodiment;

FIG. 2 is a flowchart illustrating a networking method of a blockchain network in accordance with an exemplary embodiment of the present description;

FIG. 3 is a flowchart illustrating a method of data transmission delay detection in a blockchain network according to an exemplary embodiment of the present disclosure;

FIG. 4 is a flowchart illustrating another method of data transmission delay detection in a blockchain network according to an exemplary embodiment of the present disclosure;

FIG. 5 is a schematic block diagram of an electronic device shown in accordance with an exemplary embodiment of the present disclosure;

FIG. 6 is a block diagram of a node device in a blockchain network as illustrated in the present specification in accordance with an exemplary embodiment;

fig. 7 is a block diagram of a node device in another blockchain network as illustrated in the present specification in accordance with an exemplary embodiment.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, 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 some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

The current network topology and networking mode adopted by the blockchain network during networking mainly comprise the following three modes.

1) Networking mode based on direct connection network topology

When the direct connection network topology is adopted for networking, all the consensus nodes of the consensus layer can be connected, other newly added non-consensus nodes (all nodes) can be directly connected with the consensus nodes to establish network connection, and the consensus nodes transmit the consensus result to the non-consensus nodes through the network connection.

The network topology is simple and practical in a small-scale networking scene, and the bandwidth of each consensus node is used for transmitting the consensus result to non-consensus nodes which establish network connection with the consensus nodes besides being used for data consensus. As the number of newly added nodes in the network increases, the network connection that the consensus node needs to keep increases, and the data that needs to be sent by the consensus node also increases.

Moreover, since bandwidth consumption when the consensus node sends data outwards is generally directly related to the number of nodes in the blockchain network that establish network connections with the consensus node, the greater the number of non-consensus nodes that establish network connections with the consensus node, the greater the uplink bandwidth load of the consensus node. When the number of non-consensus nodes establishing network connection with the consensus nodes is small, each non-consensus node can quickly receive the latest consensus result.

However, once the number of nodes establishing network connection with the consensus node reaches the upper limit and exceeds the bandwidth capability of the consensus node, the bandwidth load of the consensus layer is also drastically reduced, which may result in a decrease in data distribution efficiency, an increase in consensus time, a decrease in throughput, and the like, and eventually impairs the consensus capability of the entire system.

Therefore, the networking mode adopting the direct-connection network topology generally does not have good expansibility, and is difficult to deal with the scene of the blockchain network of the large-scale nodes.

2) Networking mode based on random mode

When the random networking mode is adopted for networking, the consensus nodes of the consensus layer can still be fully connected, and newly added non-consensus nodes can be preferentially connected with the consensus nodes to establish network connection. When the number of nodes establishing network connection with the consensus node reaches an upper limit, a newly added node can randomly select one node from the nodes with the consensus node established network connection as a relay node, and establish network connection with the relay node so as to receive consensus data from the relay node based on the network connection.

By adopting a random networking mode, although the bandwidth load of transmitting data to other non-consensus nodes by the consensus nodes can be effectively reduced, the physical topological relation among the nodes is not considered because the non-consensus nodes adopt random connection, and the neighbor of one node in a logical distance is likely to have great delay in the physical topology. Therefore, by adopting the networking mode, the transmission delay of the data can be increased, so that the fluctuation of the data transmission delay of the whole network is larger.

3) Networking mode based on cluster network topology

When networking is performed by adopting a cluster network topology, one consensus node can be used as a cluster head node to manage a plurality of child nodes. Each consensus node distributes data to its child nodes, which forward the data to each other.

However, with this networking approach, the robustness of the network is weak. Each consensus node is used as a cluster head node, and the consensus result is distributed to all child nodes in the affiliated cluster through the cluster head, and once the cluster head node is down, other nodes in one cluster cannot receive data in time, and only the data can be acquired through other consensus nodes or other all nodes.

Therefore, the networking mode based on the cluster network topology can cause poor robustness of the block chain network and insufficient robustness of the cluster network.

In summary, from the requirements of transmission delay, expandability and robustness, the current networking mode adopted by the blockchain during networking cannot meet the requirements of blockchain networking of large-scale nodes on data transmission efficiency and performance.

Referring to fig. 1, fig. 1 is a block chain networking framework for large-scale nodes according to the related art.

As shown in fig. 1, the networking architecture may include the following parts:

1: consensus subnetwork

The consensus sub-network may also be referred to as an internal network of the consensus layer. In the consensus sub-network, a plurality of consensus nodes can be included, and network connection can be established between the consensus nodes for data exchange in the data consensus process.

2: at least one regional subnetwork

In the networking architecture described above, the networks other than the consensus layer in the blockchain network may be divided into at least one regional subnetwork.

As shown in fig. 1, each regional subnetwork may be referred to as a zone, and each zone may contain multiple non-consensus nodes. Here, the non-consensus node generally refers to a full node in the blockchain network that does not participate in consensus. Different zones may correspond to different geographic locations, respectively.

The number of regional subnetworks included in the blockchain network is generally determined by the blockchain network size, regardless of the number of consensus nodes that the consensus layer participates in the consensus.

In order to reduce the bandwidth pressure of the consensus nodes when distributing the consensus data to the various zones, each consensus node may send data to only a part of the nodes in each zone, which we call a relay node. The relay node then forwards the consensus data distributed by the consensus node from the consensus layer to other nodes in the zone, and the nodes receiving the consensus data forwarded by the relay node are called common nodes.

With continued reference to fig. 1, for each non-consensus node in the regional subnetwork, at least one relay node and at least one common node may be included.

The relay node can establish network connection with the consensus node of the consensus layer, and is used for receiving the consensus data from the consensus node of the consensus layer.

The common node can establish network connection with the relay node and is used for receiving the consensus data forwarded by the relay node from the relay node.

For example, in practical application, the common node may send the transaction sent by the client to the relay node through a network connection with the relay node, and then the relay node submits the transaction to the consensus node in the consensus layer for consensus processing through a network connection with the consensus node of the consensus layer.

Correspondingly, after the transaction consensus submitted by each common node passes, the consensus node of the consensus layer can generate a block based on the transaction passing by the consensus, then send the block to the relay node through the network connection with the relay node, and then further send the block to the common node by the relay node based on the network connection with the common node.

It should be noted that, the connection relationship of each node in fig. 1 is only schematic, and is not used to limit the technical solution of the present disclosure in any way.

When the networking framework shown in fig. 1 is adopted to perform blockchain networking, when any network device to be added into the blockchain network joins the blockchain network, a target area sub-network corresponding to the geographic position of the network device can be determined first, and then registration for the target area sub-network can be initiated.

After the registration for the target area sub-network is completed, it may be further determined whether the network device satisfies a condition to become a relay node; if so, network connection can be established between the relay node and the consensus node in the consensus sub-network; if not, the network connection can be established between the common node and the relay node in the target area sub-network.

For example, to promote the robustness of the blockchain network, if the network device meets the condition of becoming a relay node, network connection can be established as the relay node with at least N consensus nodes in the consensus sub-network; wherein, the value of N is larger than the maximum fault-tolerant node number of the blockchain network. If the network equipment does not meet the condition of becoming a relay node, network connection can be established between the common node and at least M relay nodes in the target area sub-network; and M is a pre-calculated robustness threshold corresponding to the relay node in the target area sub-network.

It can be seen that the block chain networking is performed by using the networking framework shown in fig. 1, which can be suitable for a networking scene of a large-scale node.

For example, on the one hand, by dividing the blockchain network into a consensus sub-network and at least one regional sub-network corresponding to different geographic positions in advance, when a network device joins the blockchain network as a blockchain node, the network device can initiate registration aiming at the nearby target regional sub-network corresponding to the geographic position where the network device is located, and join the target regional sub-network as a blockchain node. Because the nodes in the same regional subnetwork are closer in physical topology and have lower data transmission delay, the nodes in the same regional subnetwork can transmit the data to be shared to the shared node more quickly, and can also receive the shared data which is distributed by the shared node and is completed by the shared node more quickly.

On the other hand, by dividing non-consensus nodes in the regional subnetwork into relay nodes receiving consensus data from the consensus nodes; and the common node receives the common data forwarded by the relay node from the relay node, so that the common node in the common sub-network can distribute the common data to the relay node when distributing the common data to the non-common nodes in each regional sub-network, and then the common data are forwarded to each common node by the relay node without respectively distributing the common data to each non-common node, thereby reducing the bandwidth load of the common layer of the blockchain network when distributing the common data and improving the common efficiency.

It can be seen that, based on the networking architecture shown in fig. 1, some common nodes can no longer directly receive the consensus data from the consensus nodes, but can receive the consensus nodes through the relay nodes, so as to relieve bandwidth pressure of the consensus nodes when distributing the consensus data.

However, although the networking framework shown in fig. 1 may alleviate the bandwidth pressure of the consensus node when distributing the consensus data to some extent, in practical application, a common node in each zone in the blockchain network shown in fig. 1 may establish network connection with multiple relay nodes at the same time, and each relay node in the multiple relay nodes may also establish network connection with multiple consensus nodes. This results in a number of data transmission channels between each common node and the respective common node, which relay nodes.

In view of this, in the present specification, a technical solution is proposed for detecting a transmission delay of a data transmission path between a normal node and each common node, which is relayed by a relay node, on the basis of the networking framework shown in fig. 1.

For each consensus node in the consensus sub-network, periodically broadcasting and sending a detection message in the block chain network; the probe message may include a first network address of the consensus node and a first timestamp corresponding to a first time when the consensus node sends the probe message;

For the relay node in each zone, after receiving the probe message, adding a second network address of the relay node and a second timestamp corresponding to a second time when the relay node sends the probe message into the probe message, and continuing broadcasting the probe message added with the second network address and the second timestamp to send to other non-consensus nodes which establish network connection with the relay node;

after receiving the probe message, the common node that establishes network connection with the relay node may calculate, based on each timestamp included in the received probe message, a data transmission delay of a data transmission path between the relay node and the first network address, with the second network address as a relay.

In the above embodiments, on the one hand, by dividing non-consensus nodes in the regional subnetwork further into relay nodes that receive consensus data from the consensus nodes; and the common node receives the common data forwarded by the relay node from the relay node, so that the common node in the common sub-network can distribute the common data to the relay node when distributing the common data to the non-common nodes in each regional sub-network, and then the common data are forwarded to each common node by the relay node without respectively distributing the common data to each non-common node, thereby reducing the bandwidth load of the common layer of the blockchain network when distributing the common data and improving the common efficiency.

Referring to fig. 2, fig. 2 is a flowchart illustrating a method of networking a blockchain network according to an exemplary embodiment of the present disclosure, which may be applied to any network device to be added to a blockchain network employing the networking architecture shown in fig. 1; the method comprises the following steps:

Step 202, determining a target area sub-network corresponding to the geographic position of the network equipment, and initiating registration for the target area sub-network;

the network device may specifically be a service device that is to join the blockchain network with the identity of the blockchain node. The specific device configuration of the service device is not particularly limited in the present specification; for example, taking the blockchain network as a federation chain as an example, the network device may specifically be a server device (such as a server or a server cluster) corresponding to a federation member in the federation chain.

As shown in fig. 1, since the blockchain network is divided into a plurality of zones corresponding to different geographic locations, when the network device joins the blockchain network as a blockchain link point, the network device may determine its own geographic location first, and then determine, according to its own geographic location, a target zone corresponding to the geographic location of the network device.

The geographical location of the network device may be the precise geographical location of the network device, or may be a relative geographical location of the network device, which is not particularly limited in the present specification.

For example, the precise geographic location may be specifically a precise positioning location of the network device; such as gps positioning coordinates. The relative geographic location may specifically be information of a region to which the network device is configured in advance; for example, taking the network device as a service device, the relative geographic location may specifically be a service device partition (Region) of a server cluster to which the service device belongs. The service device partition is usually identified by an administrative area to which a facility such as a machine room in which the server cluster is located belongs.

After determining the target zone corresponding to the own geographic location, the network device may further initiate a registration procedure for the target zone.

It should be noted that, before initiating registration for the target zone, the network device generally needs to complete registration for the blockchain network in advance.

In one embodiment, when the network device registers for the blockchain network, a registration request for the blockchain network may be initiated to a blockchain service platform (such as BaaS platform) by the blockchain service platform, so that the blockchain service platform performs a registration process for the network device in response to the registration request; wherein, the specific details of the registration process are not described in detail; for example, using a federation chain as an example, the registration process described above may generally include processes such as authorization and admission for the federation chain.

After the registration process of the blockchain service platform for the network device is completed, the network device can synchronize service data related to the blockchain network from the blockchain service platform in response to the completion of registration for the blockchain network; the service data related to the blockchain network may generally include information such as a network address (e.g., an IP address) of each consensus node in the blockchain network.

When the network device initiates the registration for the target zone, the registration may be implemented by packing a registration transaction and submitting the registration transaction to the blockchain network for execution.

In one embodiment shown, the network device may further construct a registration transaction for the target zone; the registration transaction may include registration information corresponding to the network device; the specific content of the registration information may specifically include a network address corresponding to the network device; of course, in practical application, other forms of information for registration may be included in addition to the network address corresponding to the network device; for example, the public key obtained by the network device after successfully registering the blockchain network, the network identifier (such as the network number) of the target zone requesting registration, etc. are not listed in this specification.

The network device may then submit the registered transaction to the consensus sub-network, consensus the registered transaction by each consensus node in the consensus sub-network, and store the registered transaction on the blockchain after the consensus passes to complete registration for the target area sub-network. And other non-consensus nodes in the target zone may be discovered by retrieving the registration transaction stored on the blockchain to newly join the non-consensus node of the target zone.

The specific type of the registration transaction is not particularly limited in the present specification, and may specifically be a native transaction type supported by a blockchain network, or may be an intelligent contract invoking transaction.

For example, in one example, an intelligent contract for registration management of a blockchain network may be deployed on the blockchain; in this case, the registration transaction may specifically be a smart contract invoking transaction corresponding to the smart contract; when the network device initiates registration for the target zone, a specific intelligent contract call transaction for the intelligent contract can be packaged, and the intelligent contract call transaction specifically can contain registration information serving as contract call parameters; the intelligent contract invoking transaction containing the registration information can then be submitted to the consensus sub-network to trigger each consensus node in the consensus sub-network to execute the execution code contained in the intelligent contract in a distributed manner to run the registration logic registering with respect to the target zone, and generate a registration Event (Event) of the network device with respect to the target zone.

Then, the generated registration event can be subjected to consensus so that the calling result of each consensus node on the intelligent contract is distributed and consistent; the registration event may include the above-mentioned registration information. After the registration event is commonly known, each consensus node can store the registration event on the blockchain to complete registration for the target area subnetwork. For example, the generated registration event may be stored in the database corresponding to the blockchain as a part of a transaction receipt (receipt) corresponding to the smart contract call transaction.

Step 204, in response to the completion of registration for the target area subnetwork, determining whether the network device satisfies a condition for becoming the relay node;

after the network device completes registration for the target zone, it may further determine whether the network device meets the condition of becoming the relay node, and confirm the node role of the network device in the target zone based on the determination result.

In one embodiment, before further determining whether the network device meets the condition of becoming the relay node, the network device first needs to acquire a registration transaction stored in a blockchain and submitted by other non-consensus nodes in the target zone, and acquire network addresses corresponding to the other non-consensus nodes in the target zone from the registration transaction, so as to discover the other non-consensus nodes in the target zone.

For example, taking the example that the registration transaction is a smart contract call transaction corresponding to the smart contract, in this case, the network device may monitor a blockchain for registration events for the target zone stored by other non-consensus nodes in the target zone generated by the smart contract; then, in response to the monitored registration event, the registration information of the other non-consensus nodes contained in the registration event for the target zone is acquired, and the network addresses corresponding to the other non-consensus nodes in the target zone are further acquired from the acquired registration information.

It should be noted that, since the registration event may include a network identifier of a target zone, when the network device monitors a registration event of another non-consensus node in the target zone generated by the smart contract stored in the blockchain for the target zone, the network device may specifically be implemented by monitoring a registration event including a network identifier of the target zone generated by the smart contract stored in the blockchain.

After the network device obtains the network addresses corresponding to the other non-consensus nodes in the target zone from the registration transaction, at least one network address can be randomly selected from the obtained network addresses corresponding to the non-consensus nodes in the target zone, and the network connection can be respectively established with the at least one non-consensus node corresponding to the at least one network address.

It should be noted that, the network connection respectively established by the network device and the at least one non-consensus node may be specifically used as an initialization transmission channel between the network device and other non-consensus nodes in the target zone after joining the target zone, where the initialization transmission channel is used for performing initialization information interaction with the other non-consensus nodes.

In practical application, if the network device fails to establish network connection with the at least one non-consensus node, in order to ensure that the network device can interact with initialization information of other non-consensus nodes, at least one network address can be reselected from network addresses corresponding to the obtained non-consensus nodes in the target zone, and network connection can be established with at least one non-consensus node corresponding to the reselected at least one network address.

Of course, if the network connection with the at least one non-consensus node that is reselected still fails at this time, it is also possible to continue to randomly select at least one network address from the network addresses of the non-consensus nodes in the neighbor zones of the target zone, and then establish a network connection with the at least one non-consensus node in the neighbor zone until the network device successfully establishes a network connection with the target zone or the at least one non-consensus node in the neighbor zone of the target zone.

In the present specification, after the network device successfully registers the target zone, it may further determine whether the network device itself satisfies a condition of becoming a relay node, and then confirm the node role of the network device itself in the target zone based on the determination result.

In one embodiment shown, the network device is the condition for the relay nodes in the target zone, specifically, whether there are a sufficient number of relay nodes in the target zone.

In this case, when judging whether the network device itself meets the condition of becoming the relay node, the network device may specifically acquire the number of relay nodes in the target area subnetwork first, and then determine whether the number of relay nodes in the target zone is lower than the threshold M.

The threshold M may specifically be a pre-calculated robustness threshold corresponding to the relay node in the target zone. The robustness threshold reflects the robustness requirements for the target zone. That is, when the number of relay nodes in a target zone is not less than M, the target zone is considered to meet the robustness requirement.

If the number of relay nodes in the target zone is lower than a threshold M, the network equipment can be determined to meet the condition of becoming a relay node; conversely, it may be determined that the network device does not satisfy the condition of becoming a relay node.

When the network device obtains the number of relay nodes in the target zone, the network device can be specifically realized by performing message interaction with other non-consensus nodes through the initialization transmission channel.

In one embodiment shown, the above-mentioned blockchain network supports message types for interaction between the nodes, which may specifically include the following messages:

and a get-relay-nodes message (denoted as a first message) for querying node information of relay nodes in the regional subnetwork corresponding to the message receiving node.

A relay-nodes message (denoted as a second message) for returning to the message sending node of the get-relay-nodes message the node information set of the relay node in the regional subnetwork in which it is located, maintained by the message receiving node.

In this case, the network device may specifically send the get-relay-nodes message to the at least one non-consensus node that has established the network connection when obtaining the number of relay nodes in the target zone through the message interaction between the initialization transmission channel and other non-consensus nodes. And said at least one non-consensus node may return a relay-nodes message to the network device after having acquired said get-relay-nodes message, respectively. After receiving the relay-nodes message, the network device may read a node information set of the relay nodes in the target zone maintained by the at least one non-consensus node, which is included in the message content of the relay-nodes message, and then determine the number of the relay nodes in the target zone based on the node information set; for example, in practical applications, the number of relay nodes in the target zone may be determined based on statistics of node information in the node information set.

If the at least one non-consensus node is a plurality of non-consensus nodes, the network device may acquire a plurality of relay-nodes messages returned by the plurality of non-consensus nodes, in which case, the network device may respectively read node information sets of relay nodes in the target zone maintained by the plurality of non-consensus nodes and included in message contents of the relay-nodes returned by the plurality of non-consensus nodes, and then take a union set for the read node information sets, and then determine the number of relay nodes in the target zone based on the obtained union set.

In one embodiment shown, the above-mentioned message types supported by the blockchain network for interaction between the nodes may include, in addition to messages such as get-relay-nodes messages and relay-nodes messages, in actual applications, messages as shown below:

and the relay message (marked as a third message) is used for declaring the message sending node as a relay node which operates normally.

In this case, the relay nodes in the target zone may broadcast and send relay messages in the target zone periodically, respectively; the message content of the relay message contains node information of the relay node. And other non-consensus nodes (including other relay nodes and other common nodes) in the target zone may respectively maintain a node information set corresponding to the relay nodes in the target zone, after receiving the relay message, may read the node information of the relay nodes contained in the message content of the relay message, and then add the node information to the locally maintained node information set.

A Leave message (denoted as a fourth message) for declaring that the messaging node exits the local subnetwork to which it belongs with the identity of the relay node.

In this case, when receiving the instruction to exit the regional subnetwork to which the relay node belongs, the relay node in the target zone may determine, in response to the instruction, a target common node that is a candidate relay node from the common nodes that have established network links with the relay node, and send a Leave message to the target common node to trigger the target common node to serve as a new relay node to replace the relay node, and the common nodes that have established network connections with the relay node, respectively establish network connections with other common nodes that have established network connections with the relay node, respectively establish network connections with the other common nodes that have established network connections with the relay node.

In this way, the number of relay nodes in each regional subnetwork can be maintained at a fixed level all the time, which helps to maintain the network stability of each regional subnetwork.

In practical application, the instruction to exit the area subnetwork to which the relay node belongs may be specifically an instruction to exit the area subnetwork to which the relay node belongs, which is manually input by an administrator of the relay node, or may be an instruction to exit the area subnetwork to which the relay node belongs, which is automatically triggered when the relay node does not respond to suspected downtime for a long time, and is not particularly limited in the present specification.

The specific determination method for determining the target common node serving as the candidate relay node from the common nodes establishing the network link with the relay node can be flexibly customized based on requirements in practical application, and is not particularly limited in the specification.

For example, in one example, the normal node to which each normal node is added earliest may be determined based on the time at which each normal node to which the relay node has established a network link joins the regional subnetwork to which the relay node belongs, and then the normal node may be determined as the target normal node as the candidate relay node.

Step 206, if yes, establishing network connection with the consensus node in the consensus sub-network as a relay node; if not, establishing network connection with the relay node in the target area sub-network as a common node.

In the present specification, if the network device determines that the network device itself satisfies the condition of becoming a relay node in the target zone, at this time, a network connection may be further established as a relay node with a consensus node in the consensus sub-network; otherwise, the network connection can be established with the relay node in the target zone as a common node.

It should be noted that the number of the consensus nodes or the relay nodes that establish the network connection with the network device may be one or more, and in practical application, the determination may be made based on the robustness requirement on the blockchain network.

For example, if the robustness requirement on the blockchain network is high, the network device can simultaneously establish network connection with a plurality of consensus nodes in the consensus sub-network when the network device is used as a relay node. In this case, the network device may also receive data from other ones of the plurality of consensus nodes once a downtime of one of the consensus nodes occurs. Correspondingly, when the network device is used as a common node, network connection can be respectively established with a plurality of relay nodes in the target zone at the same time. In this case, the network device may also receive data from other consensus nodes of the plurality of relay nodes once a relay node is down.

In practical applications, a blockchain network typically has a maximum number of fault-tolerant nodes; for example, taking the common algorithm adopted by the blockchain network as the Bayesian common algorithm, the maximum fault-tolerant node number is generally the maximum number f of Bayesian nodes that the blockchain network can tolerate.

On the one hand, when one relay node establishes network connection with more than f consensus nodes, in a limit case, even if f consensus nodes are down at the same time (the Bayesian node can be directly regarded as the down node), it can be ensured that at least one consensus node still can be in a normal operation state in the consensus nodes which establish network connection with the relay node, that is, the relay node can still receive data from at least one consensus node. In this case, the relay node may be considered to meet the robustness requirements of the blockchain network.

On the other hand, as described above, the robustness threshold M corresponding to the relay node in the target zone may be calculated in advance. The robustness threshold M reflects the robustness requirements for the target zone. That is, when the number of relay nodes in a target zone is not less than M, the target zone is considered to meet the robustness requirement. In this case, when one common node establishes network connection with not less than M relay nodes, the common node can be considered to meet the robustness requirement of the blockchain network.

Based on this, in one embodiment shown, if the network device determines that it satisfies the condition of becoming a relay node in the target zone, it may establish network connections with at least N consensus nodes in the consensus sub-network as relay nodes, respectively; wherein, the value of N can be larger than the maximum fault-tolerant node number of the blockchain network;

For example, in one example, taking the consensus algorithm adopted by the blockchain network as the bayer consensus algorithm, the number of fault-tolerant nodes (i.e. the number of bayer nodes) of the blockchain network may be denoted as f, and the number of consensus nodes participating in consensus in the blockchain network may be 3f+1; in this case, the above-mentioned range of N may be (f, 3f+1]. That is, N may be a value greater than f and less than or equal to 3f+1.

Correspondingly, if the network equipment determines that the network equipment does not meet the condition of becoming a relay node in the target zone, the network equipment can also be used as a common node to respectively establish network connection with at least M relay nodes in the target zone; wherein, as previously described, the M is a pre-calculated robustness threshold corresponding to the relay node in the target zone.

In practical application, the value of M corresponding to each zone in the blockchain network may be calculated in advance by the blockchain service platform corresponding to the blockchain network based on the actual scale of each zone, or may be calculated autonomously by the non-consensus node in each zone based on the actual scale of the current zone, which is not particularly limited in the present specification.

The calculation process of the value of M will be described in detail below taking the consensus algorithm adopted in the blockchain network as an example of the bayer consensus algorithm.

In practical applications, due to malicious behavior of the bayer node of the non-consensus layer network in the blockchain network, data transmission is usually refused or delayed; therefore, in this embodiment, the node downtime may be regarded as a disfigurement such as refusal to send data or delay to send data of the byesting node in the relay node and the normal node.

When only one zone exists in the network, if all relay nodes in the zone are down (namely all the relay nodes are Bayesian nodes), the nodes in the zone cannot receive data for a long time. In order to ensure the high efficiency of data transmission, at least enough relay nodes in one zone are theoretically ensured, so that the situation that all relay nodes are down can be avoided.

In one embodiment shown, assume that the probability of a honest node downtime over a period of run time is noted as p _honest The probability of the Bayesian node downtime is p _byzantine The method comprises the steps of carrying out a first treatment on the surface of the In this case, the probability of downtime of any one node in the blockchain network can be calculated by the following formula:

Wherein f represents the number of Bayesian nodes tolerated by the blockchain network; t represents the total number of nodes in the blockchain network; p is p _byzantine Representing the probability of downtime of any Bayesian node in the blockchain network; p is p _honest Representing the probability of downtime of any honest node in the blockchain network.

In one embodiment shown, assuming that the robustness threshold of the relay nodes in the target zone is represented by M, the probability of all of the M relay nodes being down may be represented by the following formula:

(p _crash ) ^M ≤p _robust (equation 2)

Since the probability of downtime of any one of the bayer pattern nodes in the blockchain network is the same as the probability of downtime of any one of the bayer pattern nodes in the target zone, p is expressed in the above formula 2 _byzantine The probability of downtime of any one of the bayer pattern nodes in the target zone can be represented. Similarly, p in the above formula 2 _honest And the probability of downtime of any honest node in the target zone can be represented. P is p _crash The probability of downtime of any one of the non-consensus nodes in the target zone can also be represented.

With continued reference to equation 1, since the Bayesian node will be regarded as node down by default, as described above, p is _byzantine =1. Due to the above formula 1

The value of this fraction is usually very small and can be neglected, so if p is to be taken _byzantine When =1 is substituted into equation 1, p is as follows from equation 1 _crash The value of (2) may generally be about equal to +.>

Based on this, in one embodiment shown,above p _crash The value of (2) can be calculated by the following formula:

substituting equation 3 into equation 2, the following calculation equation can be finally obtained:

in summary, the value of M corresponding to the target zone can be calculated using equation 4.

For example, the derivation is performed on the basis of equation 4, and the calculation equation of M can be obtained:

wherein, p is as follows _robust Is generally related to the robustness requirements of each zone and the size of each zone (e.g., total number of nodes), p for different zones _robust May be different. Therefore, in practical application, the robustness threshold p can be flexibly set for each zone based on the robustness requirement of each zone _robust 。

In one embodiment shown, when the network device further establishes network connection with N consensus nodes in the consensus sub-network as relay nodes, the network device may specifically randomly select at least N network addresses from the network addresses of the consensus nodes in the consensus sub-network acquired in the registration phase of the blockchain network, and then establish network connection with the N network addresses randomly selected.

When the network device is used as a common node to establish network connection with M relay nodes in the target zone, the network device may also specifically select M network addresses randomly from the network addresses of the relay nodes in the target zone acquired in the registration stage of the target zone, and establish network connection with the M network addresses randomly selected.

The specific type of the network connection is not particularly limited in the present specification; for example, taking the network address as an IP address as an example, the network connection may specifically be a TCP connection, in which case the network device may perform a TCP three-way handshake based on the TCP protocol with other consensus nodes or relay nodes to create a TCP connection.

It should be noted that, a full connection may be established between each relay node in the target zone; that is, for any relay node in the target zone, a network connection may be established with each of the other relay nodes, respectively.

For example, in practical applications, if the network device satisfies the condition of becoming a relay node, in addition to establishing network connection with the consensus node in the consensus sub-network, network connections may be respectively established with network addresses of other relay nodes in the target zone.

It should be noted that, after the number of the ordinary nodes that establish the network connection with one relay node reaches a certain number, the relay node may face a pressure on a bandwidth when forwarding data to each ordinary node, so in practical application, a cluster topology structure using each relay node as a cluster head may be introduced to limit the number of the ordinary nodes that establish the network connection with the relay node.

For example, in one embodiment shown, a threshold may be set for each relay node that allows for a common node to establish a network connection therewith. For example, the threshold may still be M as described above. In this case, when the network device establishes a network connection as a normal node with any one of M relay nodes in the target zone, if the number of normal nodes with which the target relay node maintains a network connection reaches M, the target relay node may refuse to establish a network connection with the network device, select one target normal node from the normal nodes with which the network connection is established, and then transmit the network address of the target normal node to the network device. After the network device acquires the network address of the target common node, the network device can no longer directly establish network connection with the target relay node, but can be used as a child node of the target common node which has established network connection with the relay node, and establishes network connection with the network address of the target common node.

The specific manner in which the target relay node selects the target normal node from the normal nodes with which the network connection is established is not particularly limited in the present specification; for example, a random selection may be employed, or a common node may be selected that is geographically closer to the network device.

In the illustrated embodiment, after the network device establishes network connection with N consensus nodes in the consensus sub-network as a relay node, the network device may also broadcast and send the above-mentioned relay message in the target zone periodically; the message content of the relay message comprises node information of the network equipment serving as a relay node; correspondingly, the network device, as a relay node, may also receive a relay message periodically broadcast by other relay nodes in the target zone, read node information of other relay nodes included in the message content of the received relay message, and add the read node information to a locally maintained node information set corresponding to the relay nodes in the target zone.

In one embodiment shown, after registration for a target zone, the network device may also determine a neighbor zone corresponding to the target zone from among the various zones in the blockchain network; for example, when implementing, other zones with relatively close geographic locations may be determined as neighbor zones corresponding to the target zone; then, a network connection can be further established with at least part of the relay nodes in the determined neighbor zone. The network connection can be used for data synchronization with neighbor zones.

In this case, when a large-scale node downtime occurs to a non-consensus node in a target zone, and the node in the target zone is not available as a whole, the network device may enable a network connection with a relay node in a neighbor zone, and perform data synchronization from the neighbor zone through the network connection. Of course, if a non-consensus node in a target zone is not unavailable because of extensive node downtime, the network connection may be used only to interact with relay nodes in neighbor zones to maintain the availability of the network connection.

In one embodiment shown, if the network device establishes a network connection with a common node in the common sub-network as a relay node, then the common data sent by the common node can be received through the network connection with the common node in the common sub-network, and then the common data is further forwarded to the common node through the network connection with the common node connected with the common node; in this way, the common node can no longer need to establish network connection with the consensus node and receive data from the consensus node, so that the bandwidth pressure of the consensus node can be relieved.

In addition, the common node that establishes network connection with the network device may send the transaction that needs to be identified to the network device through the network connection with the network device, and the network device may further submit the transaction to the identified node in the identified sub-network through the network connection with the identified node in the identified sub-network after receiving the transaction sent by the common node through the network connection.

In another embodiment shown, if the network device is used as a common node, a network connection is established with a relay node in the target zone, and a subsequent client corresponding to the common node may submit a transaction to be agreed to the network device. And after receiving the transaction sent by the client, the network equipment can send the transaction to the relay node through network connection with the relay node in the target zone, and the relay node further submits the transaction to the consensus node for consensus processing through network connection with the consensus node in the consensus sub-network.

It should be noted that, the client may specifically be a light node that establishes a network connection with the common node. Accordingly, the non-consensus nodes (including the relay node and the common node) in each zone in the blockchain network can be all nodes which do not participate in consensus.

Referring to fig. 3, fig. 3 is a flowchart illustrating a method of data transmission delay detection in a blockchain network according to an exemplary embodiment of the present disclosure; wherein the blockchain network may still employ the networking framework shown in fig. 1; the block chain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network corresponding to different geographic positions respectively; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively; the method can be applied to any target relay node in any target area sub-network, and comprises the following steps:

step 302, receiving a probe message periodically broadcast and sent by a consensus node in the consensus sub-network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first time when the consensus node sends the detection message;

in this specification, the above-mentioned message types supported by the blockchain network for interaction between the nodes may further include messages as shown below:

A latency-detect message (i.e., the probe message described above) that may be broadcast periodically in the blockchain network by the consensus nodes in the consensus sub-network may be used to probe the data transmission delay of the data transmission path between each non-consensus node and the consensus node. By default, the message may include a network address of the consensus node that sent the message and a timestamp corresponding to the time at which the message was sent.

In this case, the consensus node in the consensus sub-network may periodically broadcast the latency-detect message in the blockchain network; the issued latency-detect message may include a network address of the consensus node and a first timestamp corresponding to a first time when the consensus node sends the latency-detect message.

The period duration used by the consensus node to send the latency-detect message is not particularly limited in the present description, and in practical application, flexible specification may be performed based on practical requirements. The time of transmitting the latency-detect message may be the exact time at which the consensus node broadcasts the transmission of the latency-detect message, or may be other time that is not the exact time at which the latency-detect message is transmitted but is specified in advance as the transmission time, and is not particularly limited in the present specification. That is, in practical applications, the exact time of sending the latency-detect message may be included in the latency-detect message, or a time may be designated in advance as the sending time of the latency-detect message and included in the latency-detect message.

And the target relay node can receive the latency-detect message periodically broadcast and sent by the consensus node in the consensus sub-network. In the illustrated embodiment, the latency-detect message received by the target relay node may be a latency-detect message periodically broadcast by a consensus node that establishes a network connection with the target relay node. In this case, the first network address is a network address of a consensus node that establishes a network connection with the target relay node; the first timestamp is a timestamp corresponding to a time when the consensus node establishing the network connection with the target relay node broadcasts and transmits the latency-detect message.

As described above, in order to improve the robustness of the blockchain network, the relay nodes in each zone may respectively establish network connection with at least N consensus nodes in the consensus sub-network; wherein N may be a value greater than the maximum fault-tolerant node number of the blockchain network, and will not be described in detail.

In this case, since the target relay node establishes network connection with the N consensus nodes at the same time, the target relay node may specifically receive the latency-detect messages broadcast by the N consensus nodes when receiving the latency-detect messages broadcast by the consensus nodes.

In practical application, the relay nodes in each zone can also respectively establish full connection with each consensus node in the consensus sub-network; that is, the relay nodes in the respective zones may establish network connections with each of the consensus nodes in the consensus sub-network, respectively. The value of N may be the total number of consensus nodes participating in the distribution of the consensus data in the consensus sub-network.

In this case, since the above-mentioned target relay node establishes network connection with all the consensus nodes in the consensus sub-network at the same time, the number of the received latency-detect messages when the target relay node receives the latency-detect messages broadcast by the consensus nodes may be specifically the same as the total number of the consensus nodes participating in the consensus data distribution in the consensus sub-network. For example, assuming that 3f+1 consensus nodes are included in the consensus sub-network, the target relay node may also receive 3f+1 latency-detect messages.

In another embodiment shown, the latency-detect message received by the target relay node may specifically be a latency-detect message forwarded by another relay node, and the latency-detect message is periodically broadcast by a consensus node that establishes a network connection with the other relay node.

That is, in the present specification, the target relay node may receive a latency-detect message broadcasted by a common node with which a network connection is established, and may also receive a latency-detect message forwarded by another relay node.

In this case, the first network address is a network address of a consensus node that establishes a network connection with the other relay node; the first timestamp is a timestamp corresponding to a time when the other relay node establishes a network connection and the consensus node broadcasts and transmits the latency-detect message.

The other relay nodes may specifically include other relay nodes in the target zone to which the target relay node belongs, and may also include relay nodes in other zones other than the target zone, which establish network connection with the target relay node, which is not particularly limited in the present specification.

And step 304, in response to the probe message, adding a second network address of the target relay node and a second timestamp corresponding to a second time when the target relay node sends the probe message to the probe message, and forwarding the probe message added with the second network address and the second timestamp to other non-consensus nodes which establish network connection with the target relay node, so that a common node in the other non-consensus nodes calculates a data transmission delay of a data transmission path between the first network address and the second network address as a relay based on each timestamp contained in the received probe message.

After receiving the latency-detect message broadcast by the consensus node, the target relay node may continue forwarding the latency-detect message to the common node with which the network connection is established. For example, in practical application, the target relay node may also use a broadcast transmission method in the blockchain network to continuously forward the received latency-detect message.

When the target relay node continues forwarding the latency-detect message, a second network address of the target relay node and a second timestamp corresponding to a second time of sending the latency-detect message may be added to the message content of the latency-detect message, and then the latency-detect message to which the second network address and the second timestamp are added is forwarded to other non-consensus nodes with which the network connection is established; the other non-consensus nodes may include other relay nodes that establish network connection with the target relay node and other common nodes that establish network connection with the target relay node.

After receiving the latency-detect message broadcast by the consensus node that has established a network connection with another relay node in the blockchain network, the other relay node also performs the same action as the target relay node, and further adds the network address of the other relay node and the timestamp corresponding to the time when the probe message is sent by the other relay node, based on the network address of the consensus node that has established a network connection with the other relay node and the timestamp corresponding to the time when the latency-detect message is sent by the consensus node.

In one embodiment shown, as previously described, a full connection may be established between the relay nodes of the individual zones. Moreover, each common node in each zone can also respectively establish network connection with at least M relay nodes in the zone to which the common node belongs; wherein M is a pre-calculated robustness threshold corresponding to a relay node in the regional subnetwork, and a specific calculation process is not described again.

In this case, the non-consensus node, which establishes a network connection with the target relay node, may include a plurality of normal nodes and a plurality of other relay nodes. When the target relay node continues to forward the latency-detect message, the latency-detect message can be forwarded to all the common nodes and other relay nodes which establish network connection with the target relay node in the zone to which the target relay node belongs.

In the illustrated embodiment, each common node in each regional subnetwork may also establish a full connection with each relay node in the zone to which it belongs. That is, each common node in each zone may establish a network connection with each relay node in the zone to which it belongs, respectively. The value of M may be the total number of relay nodes in the zone to which the M belongs.

In this case, since the above-mentioned target relay node establishes network connection with all the ordinary nodes in the zone to which it belongs at the same time, when the target relay node continues to forward the latency-detect message, the target relay node may specifically forward the latency-detect message to all the various ordinary nodes in the zone to which it belongs and other various relay nodes.

In the illustrated embodiment, each common node of each zone may also establish network connection with at least one relay node in a neighboring zone corresponding to the zone to which it belongs, respectively; for example, in one example, each common node of each zone may also establish a full connection with all relay nodes in neighboring zones corresponding to the zone to which it belongs.

In this case, when the target relay node continues forwarding the latency-detect message, the target relay node needs to continue forwarding the latency-detect message to each non-consensus node in the zone to which the target relay node has established a network connection, and forwards the latency-detect message to at least one common node in the neighbor zone corresponding to the zone to which the target relay node has established a network connection; for example, taking each common node of each zone, all relay nodes in the neighboring zone corresponding to the zone to which the common node belongs can be respectively connected as an example, and the target relay node needs to forward the common node to the common node in the neighboring zone, wherein the common node establishes network connection with the common node.

In one embodiment, the target relay node continues to broadcast the transmitted latency-detect message, which may be a latency-detect message transferred by other relay nodes; therefore, the network address of the secondary addition of the plurality of relay nodes possibly included in the latency-detect message. In this case, when the target relay node continues to broadcast the latency-detect message, specifically, the target relay node may first read the network address included in the latency-detect message, and determine other network addresses except the network address included in the probe message among the network addresses of other non-consensus nodes that establish network connection with the target relay node; the latency-detect message may then be broadcast on to the various non-consensus nodes corresponding to the other network addresses.

In this way, it is possible to avoid continuing to broadcast the latency-detect message to the duplicate non-consensus node that has received and forwarded the same latency-detect message, and thus it is possible to avoid wasting bandwidth when sending the latency-detect message.

In the present specification, after the target relay node forwards the latency-detect message to which the second network address and the second timestamp are added, the target relay node may calculate a data transmission delay of a data transmission path between the second network address and the first network address, based on each timestamp included in the received latency-detect message, from among the non-consensus nodes, after forwarding the latency-detect message to other non-consensus nodes to which the network connection is established.

In one embodiment, if the latency-detect message forwarded by the target relay node is a latency-detect message periodically broadcast by a consensus node that establishes a network connection with the target relay node, the first network address is a network address of the consensus node that establishes a network connection with the target relay node; the first timestamp is a timestamp corresponding to a time when the consensus node establishing the network connection with the target relay node broadcasts and transmits the latency-detect message.

In this case, the normal node, which has established a network connection with the target relay node, may calculate a data transmission delay of a data transmission path between the first network address and the second network address as a relay based on each time stamp included in the received latency-detect message.

For example, the common node may first calculate a timestamp corresponding to a time when the latency-detect message is received, and a difference between the timestamp and the second timestamp, to obtain a first transmission delay of the network connection between the common node and the target relay node. And then, calculating the difference value between the first time stamp and the second time stamp to obtain a second transmission delay of the network connection between the target relay node and the consensus node for broadcasting and sending the latency-detect message. And finally, adding the first transmission delay and the second transmission delay to obtain the total transmission delay of the data transmission path between the common node and the common node, wherein the target relay node is used as the transfer.

In another embodiment shown, if the latency-detect message forwarded by the target relay node is a latency-detect message forwarded by another relay node; i.e. a latency-detect message is periodically broadcast by the consensus node that has established a network connection with the other relay nodes described above. The first network address is a network address of a consensus node that establishes network connection with the other relay node; the first timestamp is a timestamp corresponding to a time when the other relay node establishes a network connection and the consensus node broadcasts and transmits the latency-detect message.

Since the latency-detect message is a latency-detect message that has been transferred by another relay node, the latency-detect message further includes a third network address of the other relay node added to the latency-detect message when the other relay node sends the latency-detect message and a third timestamp corresponding to a third time when the other relay node sends the latency-detect message.

In this case, the normal node, which has established a network connection with the target relay node, may calculate a data transmission delay of a data transmission path between the second network address and the third network address as transit (i.e., transit at least twice) and the first network address based on the respective time stamps included in the received latency-detect message.

For example, the common node may first calculate a timestamp corresponding to a time when the latency-detect message is received, and a difference between the timestamp and the second timestamp, to obtain a first transmission delay of the network connection between the common node and the target relay node. And then, calculating a difference value between the second time stamp and the third time stamp to obtain a second transmission delay of the network connection between the target relay node and the other relay nodes. Finally, the difference between the third timestamp and the first timestamp is calculated, so as to obtain a third transmission delay of the network connection between the common node for broadcasting and sending the latency-detect message and the other relay nodes. And finally, adding the first transmission delay, the second transmission delay and the third transmission delay to obtain the total transmission delay of the data transmission path between the common node and the common node, wherein the target relay node and the other relay nodes serve as relays.

Referring to fig. 4, fig. 4 is a flowchart illustrating a method of data transmission delay detection in a blockchain network according to an exemplary embodiment of the present disclosure; wherein the blockchain network may still employ the networking framework shown in fig. 1; the block chain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network corresponding to different geographic positions respectively; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively; at least one common node having network connection with at least one relay node respectively; the method is applied to any target common node in any target area sub-network; the method comprises the following steps:

Step 402, receiving a probe message forwarded by a target relay node which establishes network connection with the target common node; the detection message is received by the target relay node, and the detection message is periodically broadcast and sent by a consensus node in the consensus sub-network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first moment when the consensus node sends the detection message; and adding a second network address of the target relay node in the probe message and a second timestamp corresponding to a second moment of the probe message transmission by the target relay node when the probe message is transmitted by the target relay node;

for implementation details of this step, please refer to the description of the embodiment shown in fig. 3, and detailed description thereof will not be given in this embodiment.

Step 404, calculating a data transmission delay of a data transmission path between the second network address and the first network address as a relay based on each time stamp included in the received probe message. In this specification, after the target normal node receives the latency-detect message forwarded by the target relay node with which the network connection is established, the data transmission delay of the data transmission path between the second network address and the first network address may be calculated based on each time stamp included in the received latency-detect message.

In the illustrated embodiment, as described above, each common node of each zone may also establish network connection with at least one relay node in a neighboring zone corresponding to the zone to which it belongs; for example, in one example, each common node of each zone may also establish a full connection with all relay nodes in neighboring zones corresponding to the zone to which it belongs.

In this case, the target relay node mentioned in the above step 402 may also refer to other relay nodes in the neighboring zone of the zone to which the target normal node belongs, where the latency-detect message received by the target normal node may be a latency-detect message forwarded by the target relay node that establishes a network connection with the target normal node in the neighboring zone of the zone to which the target normal node belongs, and the latency-detect message that is periodically broadcast by the consensus node that establishes a network connection with the target relay node. The target relay node may also calculate a data transmission delay between the target relay node and the consensus node in the neighbor zone based on each timestamp in the latency-detect message, and the target relay node may be used as a data transmission path for transfer.

Through the calculation, the target common node can finally obtain the data transmission delay of the data transmission path between the relay node which establishes network connection with the target common node and each consensus node in the consensus sub-network by taking the network address of each relay node which establishes network connection with the target common node as the transfer.

After the target common node calculates the data delay of each data transmission path between the network address of each relay node with which the network connection is established and the network address of each consensus node in the consensus sub-network as the relay, the target common node can further determine the target data transmission path with the minimum data transmission delay in each data transmission path; then, the consensus data forwarded by the target relay node serving as the relay on the target data transmission path can be subscribed, and the consensus data is received from the target relay node.

For example, in one embodiment shown, the above-described message types supported by the blockchain network for interaction between the various nodes may further include the following messages:

the subscore message (denoted as the fifth message) is used to Subscribe the message receiving node to the data shards.

The relay nodes in the respective zones can Subscribe to the consensus data which the consensus node is responsible for distributing by sending a subscnibe message to the consensus node in the consensus sub-network. After receiving the subscore message sent by the relay node, the consensus node can respond to the subscore message to establish a subscription relationship between the relay node and consensus data which the consensus node is responsible for distributing.

Accordingly, the common node in each zone may Subscribe to the consensus data that the relay node is responsible for distributing by sending a subscore message to the relay node in each zone. After receiving the Subscribe message sent by the common node, the relay node may respond to the Subscribe message to establish a subscription relationship between the common node and the consensus data that the relay node is responsible for distributing.

In this case, the target normal node may specifically send a subscnibe message to the target relay node when subscribing to the consensus data forwarded by the target relay node as the relay on the target data transmission path. After receiving the Subscribe message, the target relay node may respond to the Subscribe message to establish a subscription relationship between the common data forwarded by the target relay node and the target common node. Subsequently, the target relay node may forward the consensus data to the target common node based on the subscription relationship.

In this way, a data transmission path with the smallest data transmission delay can be selected to receive the consensus data of the consensus layer, and the data transmission delay of the consensus node when distributing the consensus data can be effectively reduced.

Corresponding to the embodiments of the foregoing method, the present specification also provides embodiments of a blockchain network, a node device, and a storage medium.

The present specification also provides a blockchain network embodiment that may include a consensus sub-network comprised of a plurality of consensus nodes; and at least one regional subnetwork respectively corresponding to different geographic locations;

wherein the plurality of non-consensus nodes comprise at least one relay node which establishes network connection with at least one consensus node in the consensus sub-network respectively; and at least one common node having established network connection with the at least one relay node, respectively;

The relay node receives the detection message, adds a second network address of the relay node and a second timestamp corresponding to a second moment when the relay node transmits the detection message in response to the received detection message, and continuously broadcasts and transmits the detection message added with the second network address and the second timestamp to other non-consensus nodes which establish network connection with the relay node;

It should be noted that, for implementation details of the above embodiments, reference may be made to the embodiments shown in fig. 2 and 3, and details are not repeated in this embodiment.

Fig. 5 is a schematic structural diagram of an electronic device according to an exemplary embodiment. Referring to fig. 5, at the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, a memory 508, and a nonvolatile memory 510, although other hardware may be included as needed for other services. One or more embodiments of the present description may be implemented in a software-based manner, such as by the processor 502 reading a corresponding computer program from the non-volatile storage 510 into the memory 508 and then running. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic module, but may also be a hardware or logic device.

As shown in fig. 6, fig. 6 is a block diagram of a node device in a blockchain network according to an exemplary embodiment of the present disclosure, and the node device 60 may be applied to the electronic device shown in fig. 5 to implement the technical solution of the present disclosure. The block chain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network corresponding to different geographic positions respectively; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively; the node device 60 includes:

a first receiving module 601, configured to receive a probe message periodically broadcast by a consensus node in the consensus sub-network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first time when the consensus node sends the detection message;

and a sending module 602, in response to the probe message, adding a second network address of the target relay node and a second timestamp corresponding to a second time when the target relay node sends the probe message to the probe message, and forwarding the probe message added with the second network address and the second timestamp to other non-consensus nodes which establish network connection with the target relay node, so that a common node in the other non-consensus nodes calculates a data transmission delay of a data transmission path between the first network address and the second network address as a relay based on each timestamp included in the received probe message.

The specific details of the above-mentioned respective modules of the apparatus 60 are already described in the method flow described above, and thus are not described herein again.

As shown in fig. 7, fig. 7 is a block diagram of a node device in another blockchain network according to an exemplary embodiment of the present disclosure, and the node device 70 may also be applied to the electronic device shown in fig. 6 to implement the technical solution of the present disclosure. The block chain network comprises a consensus sub-network and at least one regional sub-network corresponding to different geographic positions respectively; the consensus sub-network comprises a plurality of consensus nodes for distributing data fragments corresponding to consensus data to non-consensus nodes in the regional sub-network; the non-consensus node in the regional subnetwork comprises at least one relay node; and at least one common node establishing network connection with the relay node; wherein, all the relay nodes in the regional subnetwork are connected; the plurality of consensus nodes respectively establish network connection with at least one relay node in each regional subnetwork; the node device 70 includes:

a second receiving module 701, configured to receive a probe message forwarded by a target relay node that establishes a network connection with the target common node; the detection message is received by the target relay node, and the detection message is periodically broadcast and sent by a consensus node in the consensus sub-network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first moment when the consensus node sends the detection message; and adding a second network address of the target relay node in the probe message and a second timestamp corresponding to a second moment of the probe message transmission by the target relay node when the probe message is transmitted by the target relay node;

The calculation module 702 calculates a data transmission delay of a data transmission path between the second network address and the first network address as a relay based on each time stamp included in the received probe message.

The specific details of the foregoing modules of the apparatus 70 are described in the foregoing method flows, and thus are not repeated herein.

Correspondingly, the specification also provides electronic equipment, which comprises a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement the steps of all of the method flows described previously.

Accordingly, the present specification also provides a computer-readable storage medium having stored thereon executable instructions; wherein the instructions, when executed by the processor, implement the steps of the overall method flow described previously.

For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the modules illustrated as separate components may or may not be physically separate, and the components shown as modules may or may not be physical, i.e., may be located in one place, or may be distributed over a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present description. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

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

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

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

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

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

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

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

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

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

Claims

1. A data transmission delay detection method in a block chain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively; the method is applied to any target relay node in any target area sub-network; comprising the following steps:

2. The method of claim 1, wherein the probe message is a probe message periodically broadcast by a consensus node that has established a network connection with the target relay node; or alternatively, the process may be performed,

and the detection message is forwarded by the other relay nodes, and the detection message is periodically broadcast and sent by the consensus node which establishes network connection with the other relay nodes.

3. The method of claim 2, the other relay nodes comprising other relay nodes in the target area subnetwork; or other relay nodes in the neighbor area sub-network corresponding to the target area sub-network.

4. The method of claim 3, if the probe message is a probe message forwarded by the other relay node, the probe message further includes a third network address of the other relay node added in the probe message when the other relay node sends the probe message and a third timestamp corresponding to a third time when the other relay node sends the probe message;

continuing broadcasting the probe message added with the second network address and the second timestamp to other non-consensus nodes which establish network connection with the target relay node, so that a common node in the other non-consensus nodes calculates data transmission delay of a data transmission path between the second network address serving as a relay and the first network address based on each timestamp contained in the received probe message, wherein the method comprises the following steps:

and continuing broadcasting and sending the probe message added with the second network address and the second timestamp to other non-consensus nodes which establish network connection with the target relay node, so that a common node in the other non-consensus nodes calculates data transmission delay of a data transmission path between the second network address and the third network address serving as a relay and the first network address based on each timestamp contained in the received probe message.

5. The method of claim 1, each relay node in the regional subnetwork respectively establishing a network connection with at least N of the plurality of consensus nodes; wherein, the value of N is larger than the maximum fault-tolerant node number of the blockchain network.

6. The method of claim 5, wherein each relay node in the regional subnetwork establishes a full connection with each of the plurality of consensus nodes; correspondingly, the value of N is the total number of the plurality of consensus nodes.

7. The method of claim 5, wherein a full connection is established between relay nodes in the regional subnetwork; each common node in the regional subnetwork respectively establishes network connection with at least M relay nodes in the regional subnetwork; wherein, M is a pre-calculated robustness threshold corresponding to a relay node in the regional subnetwork.

8. The method of claim 7, wherein each common node in the regional subnetwork establishes a full connection with each relay node in the regional subnetwork; wherein, the value of M is the total number of relay nodes in the regional subnetwork.

9. The method of claim 1, forwarding the probe message on to other respective non-consensus nodes in the target area subnetwork that established a network connection with the target relay node, comprising:

determining other network addresses except the network address contained in the probe message in the network addresses of other non-consensus nodes which establish network connection with the target relay node;

and forwarding the probe message to each non-consensus node corresponding to the other network address.

10. The method according to claim 7,

the value of M is calculated by adopting the following formula:

(p _crash ) ^M ≤p _robust

wherein p is _crash Representing the probability of downtime of any one of the non-consensus nodes in the target area subnetwork; p is p _robust And representing a robustness threshold corresponding to the probability of all the relay nodes in the target area sub-network being down.

11. The method of claim 10, the p _crash The calculation is performed using the following formula:

wherein T represents the total number of nodes in the blockchain network; p is p _byzantine Representing the probability of downtime of any Bayesian node in the target area subnetwork; p is p _honest And representing the probability of downtime of any honest node in the target area subnetwork.

12. The method of claim 11, wherein the probability of downtime of the bayer pattern node in the target area subnetwork is set to 1; the p is _crash The calculation is performed using the following formula:

correspondingly, the value of M is calculated by adopting the following formula:

13. the method of claim 1, the plurality of non-consensus nodes being full nodes that do not participate in consensus.

14. A data transmission delay detection method in a block chain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively; the method is applied to any target common node in any target area sub-network; comprising the following steps:

15. The method of claim 14, wherein the probe message is a probe message periodically broadcast by a consensus node that has established a network connection with the target relay node; or alternatively, the process may be performed,

and the probe message is forwarded by the target relay node, and the probe message is periodically broadcast and sent by a consensus node which establishes network connection with other relay nodes.

16. The method of claim 15, the other relay nodes comprising other relay nodes in the target area subnetwork; or other relay nodes in the neighbor area sub-network corresponding to the target area sub-network.

17. The method of claim 15, wherein if the probe message is forwarded by the target relay node, and a common node having established a network connection with another relay node periodically broadcasts the probe message, the probe message further includes a third network address of the other relay node added to the probe message when the other relay node transmits the probe message and a third timestamp corresponding to a third time when the other relay node transmits the probe message;

Calculating a data transmission delay of a data transmission path between the second network address as a relay and the first network address based on each time stamp contained in the received probe message, comprising:

and calculating data transmission delay of a data transmission path between the second network address and the third network address as transit and the first network address based on each time stamp contained in the received probe message.

18. The method of claim 15, each relay node in the regional subnetwork respectively establishing a network connection with at least N of the plurality of consensus nodes; wherein, the value of N is larger than the maximum fault-tolerant node number of the blockchain network.

19. The method of claim 18, wherein each relay node in the regional subnetwork establishes a full connection with each of the plurality of consensus nodes; correspondingly, the value of N is the total number of the plurality of consensus nodes.

20. The method of claim 18, wherein a full connection is established between relay nodes in the regional subnetwork; each common node in the regional subnetwork respectively establishes network connection with at least M relay nodes in the regional subnetwork; wherein, M is a pre-calculated robustness threshold corresponding to a relay node in the regional subnetwork.

21. The method of claim 20, wherein each common node in the regional subnetwork establishes a full connection with each relay node in the regional subnetwork.

22. The method of claim 17, wherein each common node in the regional subnetwork establishes a network connection with at least one relay node in a neighboring regional subnetwork, respectively, corresponding to the regional subnetwork.

23. The method of claim 22, wherein each common node in the regional subnetwork establishes a full connection with each relay node in a neighboring regional subnetwork corresponding to the regional subnetwork.

24. The method according to claim 20,

the value of M is calculated by adopting the following formula:

(p _crash ) ^M ≤p _robust

25. The method of claim 24, the p _crash The calculation is performed using the following formula:

wherein, the liquid crystal display device comprises a liquid crystal display device,t represents the total number of nodes in the blockchain network; p is p _byzantine Representing the probability of downtime of any Bayesian node in the target area subnetwork; p is p _honest And representing the probability of downtime of any honest node in the target area subnetwork.

26. The method of claim 25, wherein the probability of downtime of the bayer pattern node in the target area subnetwork is set to 1; the p is _crash The calculation is performed using the following formula:

27. the method of claim 14, the method further comprising:

after calculating the data delay of each data transmission path between the network address of each relay node which establishes network connection with the target common node and the network address of each consensus node in the consensus sub-network as transit, determining a target data transmission path with the minimum data transmission delay in each data transmission path;

subscribing the consensus data forwarded by a target relay node serving as a relay on the target data transmission path, and receiving the consensus data from the target relay node; the consensus data is the consensus data which is distributed to the target relay node by the consensus node which establishes network connection with the target relay node and passes through the consensus of all the consensus nodes in the consensus sub-network.

28. The method of claim 27, wherein the messages interacted between the nodes in the blockchain network further comprise a fifth message for subscribing to data slicing with a message-receiving node;

subscribing the consensus data forwarded by the target relay node serving as the transfer on the target data transmission path, including:

and sending the fifth message to a target relay node serving as a relay on the target data transmission path, so that the target relay node responds to the fifth message, and a subscription relationship between the target common node and the consensus data forwarded by the target relay node is established, so that the target relay node forwards the consensus data to the target common node based on the subscription relationship.

29. The method of claim 15, the plurality of non-consensus nodes being full nodes that do not participate in consensus.

30. A blockchain network, comprising: a consensus sub-network composed of a plurality of consensus nodes, and at least one regional sub-network corresponding to different geographic locations respectively; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively;

31. A node device in a blockchain network, wherein the blockchain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively; comprising the following steps:

and the sending module is used for responding to the detection message, adding a second network address of a target relay node and a second timestamp corresponding to a second moment when the target relay node sends the detection message in the detection message, and continuously forwarding the detection message added with the second network address and the second timestamp to other non-consensus nodes which establish network connection with the target relay node, so that a common node in the other non-consensus nodes calculates data transmission delay of a data transmission path between the second network address serving as a relay and the first network address based on the received timestamps in the detection message.

32. A node device in a blockchain network, wherein the blockchain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes comprise at least one relay node which respectively establishes network connection with at least one consensus node in the consensus sub-network; and at least one common node having established network connection with the at least one relay node, respectively; comprising the following steps:

The second receiving module receives the detection message forwarded by the target relay node which establishes network connection with the target common node; the detection message is received by the target relay node, and the detection message is periodically broadcast and sent by a consensus node in the consensus sub-network; the detection message comprises a first network address of the consensus node and a first timestamp corresponding to a first moment when the consensus node sends the detection message; and adding a second network address of the target relay node in the probe message and a second timestamp corresponding to a second moment of the probe message transmission by the target relay node when the probe message is transmitted by the target relay node;

33. An electronic device comprises a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are connected with each other through the bus;

the memory stores machine readable instructions, the processor executing the method of any of claims 1 to 29 by invoking the machine readable instructions.

34. A machine-readable storage medium storing machine-readable instructions which, when invoked and executed by a processor, implement the method of any one of claims 1 to 29.