CN116170464A

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

Info

Publication number: CN116170464A
Application number: CN202211737971.5A
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-26

Abstract

The specification provides a method for distributing consensus data in a blockchain network, which comprises the following steps: determining target data fragments to be distributed by the target consensus node from a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm; and respectively unicast-transmitting the target data fragments to target relay nodes which are connected with the target consensus node in each regional sub-network in the block chain network, so that the target relay nodes continue to broadcast and transmit the target data fragments to other relay nodes and common nodes which are connected with the target relay nodes in the regional sub-network to which the target relay nodes belong, and recovering the data fragments corresponding to the consensus data by the other relay nodes and the common nodes.

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 method for distributing consensus data in a blockchain network, wherein the blockchain network comprises a consensus sub-network and at least one regional sub-network respectively corresponding to different geographic positions; the consensus sub-network comprises a plurality of consensus nodes for distributing data slices 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 method is applied to any target consensus node in the plurality of consensus nodes; comprising the following steps:

Determining target data fragments to be distributed by the target consensus node from a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm;

and respectively unicast-transmitting the target data fragments to target relay nodes which are connected with the target consensus node in each regional sub-network in the block chain network, so that the target relay nodes continue to broadcast and transmit the target data fragments to other relay nodes and common nodes which are connected with the target relay nodes in the regional sub-network to which the target relay nodes belong, and recovering the data fragments corresponding to the consensus data by the other relay nodes and the common nodes.

The specification also provides a consensus data distribution method in a blockchain network, wherein the blockchain 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 slices 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 method is applied to any target relay node in any target area sub-network; comprising the following steps:

Receiving target data fragments sent by a target consensus node unicast which establishes network connection with the target relay node in the consensus sub-network; the target data fragments are data fragments to be distributed, which correspond to the target consensus nodes, in a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm;

and continuing to send the target data fragment broadcast to other relay nodes and common nodes which establish network connection with the target relay node in the target area sub-network, so that the other relay nodes and the common nodes recover the received data fragments corresponding to the consensus data.

The present specification also proposes a blockchain network comprising: a consensus subnetwork, at least one regional subnetwork respectively corresponding to different geographic locations; the consensus sub-network comprises a plurality of consensus nodes for distributing data slices 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; full connection is established among all relay nodes in the regional subnetwork; the plurality of consensus nodes respectively establish network connection with at least one relay node in each regional subnetwork;

Any target consensus node in the plurality of consensus nodes determines target data fragments to be distributed by the target consensus node from a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm; the target data fragments are respectively unicast transmitted to target relay nodes which establish network connection with the target consensus node in each regional subnetwork in the block chain network;

and the target relay node receives the target data fragments sent by the target consensus node in a unicast mode and continuously sends the target data fragments to other relay nodes and common nodes which establish network connection with the target relay node in the target area sub-network in a broadcast mode so that the other relay nodes and the common nodes can recover the received data fragments corresponding to the consensus data.

The specification also proposes node equipment in a blockchain network, wherein the blockchain network comprises a consensus sub-network and at least one regional sub-network respectively corresponding to different geographic positions; the consensus sub-network comprises a plurality of consensus nodes for distributing data slices corresponding to the 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; comprising the following steps:

The determining module is used for determining target data fragments to be distributed by the target consensus node from a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm;

and the distribution module is used for respectively unicast-transmitting the target data fragments to target relay nodes which are in network connection with the target consensus node in each regional sub-network in the blockchain network, so that the target relay nodes continue to broadcast and transmit the target data fragments to other relay nodes and common nodes which are in network connection with the target relay nodes in the regional sub-network to which the target relay nodes belong, and the other relay nodes and the common nodes restore the received data fragments corresponding to the consensus data.

The receiving module is used for receiving target data fragments sent by a target consensus node unicast which establishes network connection with the target relay node in the consensus sub-network; the target data fragments are data fragments to be distributed, which correspond to the target consensus nodes, in a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm;

and the forwarding module continues to send the target data fragment broadcast to other relay nodes and common nodes which establish network connection with the target relay node in the target area sub-network, so that the other relay nodes and the common nodes recover the received data fragments corresponding to the consensus data.

In the above embodiment, when each consensus node in the consensus sub-network distributes the consensus data to each regional sub-network, each consensus node only needs to be responsible for unicast transmitting one consensus data fragment corresponding to itself to the relay node which establishes network connection with itself, and then the relay node in each regional sub-network broadcasts the received consensus data fragment in each regional sub-network respectively, so that the distribution of the consensus data can be completed; therefore, for the consensus sub-network, only one complete consensus data is required to be sent to each regional sub-network, and one complete consensus data is not required to be sent to each relay node which is connected with the relay node, so that the bandwidth load of the consensus layer of the block chain network when the consensus data is distributed can be further reduced, and the consensus efficiency is improved.

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 consensus data distribution in a blockchain network in accordance with an exemplary embodiment of the present description;

FIG. 4 is a flowchart illustrating another method of consensus data distribution in a blockchain network according to an exemplary embodiment of the present description;

FIG. 5 is a schematic diagram illustrating a blockchain-based network for consensus data distribution in accordance with an exemplary embodiment of the present description;

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

FIG. 7 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. 8 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.

However, the blockchain networking is performed based on the networking framework shown in fig. 1, and although the networking framework can be suitable for a networking scenario of large-scale nodes, when each consensus node in the consensus sub-network distributes consensus data to a relay node connected with the consensus node, it is generally required to distribute a complete share of the consensus data to the relay node connected with each consensus node, so that the consensus node still faces a very high bandwidth load when distributing the consensus data.

In view of this, in the present specification, a method for distributing consensus data in a blockchain network is proposed on the basis of the networking framework shown in fig. 1.

For the consensus data which is passed by the consensus nodes in the consensus sub-network, the consensus data can be divided into a specified number of data fragments in advance based on an erasure coding algorithm, and each consensus node in the consensus sub-network can be respectively responsible for distributing part of the data fragments therein.

When any target consensus node in the consensus sub-network distributes consensus data, the target data fragments to be distributed by the target consensus node can be determined from the specified number of data fragments, and then the target data fragments are respectively unicast-transmitted to target relay nodes which establish network connection with the target consensus node in each regional sub-network.

After receiving the target data fragments sent by the target common node in a unicast manner, the target relay node can continuously broadcast and send the target data fragments to other relay nodes and common nodes which establish network connection with the target relay node in the regional sub-network to which the target relay node belongs under one condition, and the other relay nodes and the common nodes recover the data fragments corresponding to the received common data.

In another case, the target data fragment broadcast may be continuously sent to other relay nodes in the regional subnetwork to which the target data fragment broadcast belongs, where the other relay nodes establish network connection with the target data fragment broadcast, the other relay nodes perform data recovery on the received data fragment corresponding to the consensus data, and then the recovered consensus data is further forwarded to a common node with which the network connection is established.

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 =1 substituted into formula1, p is as follows from the above equation 1 _crash The value of (2) may generally be about equal to +.>

Based on this, in one embodiment shown, p is as described above _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 flow chart illustrating a method of consensus data distribution in a blockchain network according to an exemplary embodiment of the present description; wherein the blockchain network may still employ the networking framework shown in fig. 1; the consensus sub-network comprises a plurality of consensus nodes for distributing data slices 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; full connection is established among all relay nodes in the regional subnetwork; the plurality of consensus nodes respectively establish network connection with at least one relay node in each regional subnetwork; the method may be applied to any target consensus node of the plurality of consensus nodes, the method comprising:

step 302, determining a target data fragment to be distributed by the target consensus node from a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm;

the plurality of consensus nodes may be a consensus node which is designated in advance from the consensus sub-network and distributes data fragments corresponding to the consensus data to non-consensus nodes in the respective zones. Correspondingly, each of the plurality of consensus nodes can establish network connection with at least one relay node in each zone respectively, so that each of the plurality of consensus nodes can be ensured to successfully segment data which is responsible for distribution and send the data to the relay node which establishes network connection with the relay node. And the relay nodes in each zone can mutually establish full connection, and when the data fragments distributed by any consensus node are received, the data fragments can be continuously diffused to other relay nodes through the full connection among the relay nodes.

The plurality of common nodes may include all the common nodes in the common sub-network, or may include only part of the common nodes in the common sub-network, and are not particularly limited in this specification. That is, in practical applications, all the consensus nodes in the consensus sub-network may participate in distributing the data fragments corresponding to the consensus data, or only some of the consensus nodes in the consensus sub-network may participate in distributing the data fragments corresponding to the consensus data.

When only part of the consensus nodes participate in distributing the data fragments corresponding to the consensus data, other consensus nodes except the part of the consensus nodes can not participate in distributing the consensus data or can still be responsible for distributing the complete consensus data to the relay nodes.

In this specification, for consensus data that is consensus-passed by each consensus node in the consensus sub-network, the data may be divided into a specified number of data slices in advance based on an erasure coding algorithm.

In one embodiment shown, the partitioning of consensus data based on erasure coding algorithms may be performed from the main by each consensus node in the consensus sub-network.

In this case, the plurality of consensus nodes may acquire consensus data passed by the consensus node consensus in the consensus sub-network, and then may divide the acquired consensus data into a specified number of data slices based on the supported erasure coding algorithm. When the above-mentioned consensus data is divided autonomously by each consensus node, the erasure coding algorithm used when each consensus node divides the consensus data needs to be kept the same.

Of course, in practical applications, the above-mentioned consensus data may be autonomously segmented by each consensus node based on the same erasure coding algorithm, or specifically, may be uniformly segmented by a blockchain service platform (e.g., baaS platform) corresponding to the blockchain network, or one consensus node may be specified from the respective consensus nodes, and the consensus node is responsible for uniform segmentation, which is not particularly limited in the present specification.

The specific number of the data slices obtained by dividing the consensus data based on the erasure coding algorithm can be generally determined based on the total number of the consensus nodes participating in distributing the data slices. Correspondingly, the plurality of consensus nodes can be specifically responsible for distributing part of the data fragments in all the partitioned data fragments respectively. The target consensus node may determine a target data fragment responsible for distribution by itself from among a specified number of data fragments for which the division is completed.

The specific distribution policy adopted by each of the plurality of consensus nodes when distributing each of the partitioned data fragments may be flexibly formulated based on actual requirements in practical applications, and is not particularly limited in the present specification.

In one embodiment, the number of data slices obtained by dividing the shared data may be the same as the total number of the plurality of shared nodes participating in distributing the data slices.

For example, in one example, the number of consensus nodes in the consensus sub-network is 3f+1, where f is denoted as the number of fault-tolerant nodes of the blockchain network, in which case the consensus data that is consensus-passed by the consensus sub-network may be encoded into 2f+1 shares based on an erasure coding algorithm, and the f data are redundant, totaling 3f+1 data slices.

If the number of the data fragments obtained by dividing the consensus data is the same as the total number of the plurality of consensus nodes participating in distributing the data fragments. At this time, each of the plurality of consensus nodes may be responsible for distributing one of the data slices.

For example, each node in the consensus subnetwork will be responsible for distributing one of the above 3f+1 data slices.

In this case, the distribution policy may specifically be that each of the plurality of consensus nodes may be responsible for distributing the data fragments whose data fragment identifiers match the node identifiers of the nodes. For each data slice, unified coding may be performed based on the total number of the plurality of common nodes, so as to obtain a data slice identifier (for example, may be a data slice number) corresponding to each data slice.

When determining the target data fragments responsible for distribution by the target consensus node from the divided specified number of data fragments, the target consensus node can specifically match the node identifiers (such as node numbers) of the target consensus node with the data fragment identifiers of the data fragments respectively; and then, determining the data fragment corresponding to the data fragment identifier matched with the node identifier of the target consensus node as the target data fragment to be distributed.

In this way, each of the plurality of consensus nodes may be responsible for distributing one of the data fragments whose data fragment identifier matches its own node identifier.

For example, in one example, the data slice identifier is a data slice number, the node identifier is a node number, and the total number of N common nodes responsible for distributing the data slices is assumed to be N, where the common data is divided into N data slices, and in this case, the common node with the node number N may be responsible for distributing the data slices with the same data slice number N.

Of course, in practical applications, the number of data fragments obtained by dividing the common-mode data may be different from the total number of the plurality of common-mode nodes participating in the distribution of the data fragments, except that each of the plurality of common-mode nodes may be responsible for distributing one of all the data fragments. In this case, the number of data fragments that each of the plurality of consensus nodes is responsible for distributing may be different; for example, some of the consensus nodes may be responsible for distributing multiple ones of all the data slices, while other consensus nodes may be responsible for distributing one of all the data slices.

In the illustrated embodiment, the specific number of the data slices obtained by dividing the consensus data may be the same as the total number of the consensus nodes responsible for distributing the data slices in the consensus sub-network, or in practical application, the total number of the relay nodes in each zone may be the same as the total number of the consensus nodes. For example, in the networking phase, the number of relay nodes in each zone may be planned based on the number of consensus nodes that participate in distributing the data slices.

In this case, the relay nodes in each zone may correspond one-to-one to the consensus nodes in the consensus sub-network. That is, the consensus nodes in the consensus sub-network can respectively establish network connection with one relay node corresponding to each zone one by one. In this way, each consensus node can segment the data that it is responsible for distributing, and distribute the data to the relay nodes that are in one-to-one correspondence with it through the established network connection.

Accordingly, as previously described, if the total number of relay nodes in each zone is the same as the total number of consensus nodes in the consensus sub-network; and, if the relay nodes in each regional subnetwork are in one-to-one correspondence with each consensus node in the consensus subnetwork, at this time, each consensus node is only responsible for distributing one of all the partitioned data partitions, and sends the data partition one-to-one to the relay node corresponding to the data partition.

In this case, in order to ensure that each common node can collect enough data fragments to recover consensus data, any common node in each zone can respectively establish network connection with at least N relay nodes in the zone to which the common node belongs; wherein, the value of N is the data recovery threshold corresponding to the erasure code algorithm. Therefore, each common node can receive at least N data fragments enough to recover the consensus data through the at least N network connections.

For example, taking the example of encoding the consensus data into 3f+1 data slices based on the erasure coding algorithm, in this case, 2f+1 data slices need to be collected based on the erasure coding algorithm to successfully recover the original consensus data. Thus, each common node in each zone may establish network connections with at least 2f+1 relay nodes in the zone to which it belongs, respectively, to ensure that at least 2f+1 data slices can be collected over these network connections.

In one embodiment, to further improve the robustness of the relay nodes in each zone, each relay node in each zone may establish a full connection with each consensus node in the consensus sub-network. That is, each relay node needs to establish network connection with its corresponding consensus node, and may also establish network connection with other relay nodes respectively.

In this way, when the network connection between each relay node and its corresponding common node is abnormal or the common node corresponding to the relay node is down, the data fragments can be received through the network connection between other relay nodes

It should be noted that if all relay nodes in each zone are respectively connected with all the consensus nodes in the consensus sub-network, in default, network connection between each consensus node and the corresponding relay node can be used for transmitting the data fragments distributed by the consensus node. And network connection between each consensus node and other relay nodes except the corresponding relay node can be used for transmitting heartbeat messages for maintaining the network connection by default.

And 304, unicast-transmitting the target data fragments to target relay nodes which establish network connection with the target consensus node in each regional sub-network in the blockchain network, so that the target relay nodes continue to broadcast and transmit the target data fragments to other relay nodes and common nodes which establish network connection with the target relay nodes in the regional sub-network to which the target relay nodes belong, and recovering the data fragments corresponding to the consensus data by the other relay nodes and the common nodes.

In one embodiment shown, the above-mentioned blockchain network supports message types for interaction between the nodes, and 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.

In this case, the relay node in each zone may Subscribe to the data slice that the consensus node is responsible for distributing by sending a Subscribe message to the consensus node in the consensus sub-network. After receiving the Subscribe message sent by the relay node, the consensus node may establish a subscription relationship between the relay node and the data fragment that the consensus node is responsible for distributing in response to the Subscribe message.

For example, as described above, taking the total number of the consensus nodes in the consensus sub-network as the total number of the relay nodes in each zone, and the relay nodes in each zone are in one-to-one correspondence with each consensus node in the consensus sub-network as an example, in this case, the relay nodes in each zone may respectively send a subscnibe message to the corresponding consensus node in the consensus sub-network to Subscribe to the data slices for which the consensus node is responsible for distribution.

It should be noted that, in the networking stage of the blockchain network, a certain sequence usually exists at the moment when the relay node in each zone joins the zone to which the relay node belongs; therefore, for the first added relay node in each zone, at this time, the relay node is the only relay node in the zone to which the relay node belongs, the relay node may subscribe to all the data fragments responsible for distribution in the consensus sub-network by default, and then there is a newly added relay node, and the newly added relay node may select a part of the data fragments to complete subscription from the data fragments subscribed by the already added relay node by means of load sharing.

For example, in one embodiment shown, when a network device successfully joins a target zone as a target relay node in any of the target zones by performing the networking procedure shown in fig. 2, the target relay node may further determine whether other relay nodes are included in the target zone in response to the event that the target zone is successfully joined;

if the target relay node does not exist, the target relay node is the only relay node in the target zone, and at the moment, a subscore message can be respectively sent to each of the plurality of consensus nodes in the consensus sub-network, which are responsible for distributing the data fragments, so as to respectively Subscribe the data fragments which are responsible for distributing the consensus nodes.

If the data fragment identification is not available, the target relay node is not the only relay node in the target zone, and the target relay node can acquire the data fragment identification of the data fragments subscribed by other relay nodes so as to determine the data fragments already subscribed by other relay nodes; then, a relay node with the largest number of data fragments subscribed by other relay nodes can be determined, at least one data fragment is randomly selected from the data fragments subscribed by the relay node, and a subscription message is sent to at least one consensus node responsible for distributing the at least one data fragment to Subscribe the at least one data fragment distributed by the at least one consensus node.

When the target relay node acquires the data fragment identification of the data fragment subscribed by other relay nodes, the target relay node can be completed by carrying out message interaction with other relay nodes.

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:

a get-relay-strip message (noted as a sixth message) for querying the data fragments subscribed by the message receiving node;

The relay-strip (noted as a seventh message) is configured to return, to the message sending node of the get-relay-strip message, a data fragment identifier of the data fragment subscribed to by the message receiving node. The message content of the relay-strip may include the data fragment identifier of the data fragment subscribed by other relay nodes.

In this case, when the target relay node obtains the data fragment identifier of the data fragment subscribed by the other relay node, the get-relay-strip message may be specifically sent to the other relay node respectively; and after receiving the get-relay-strip message sent by the relay node, the other relay nodes can return the relay-strip message to the target relay node. And after receiving the relay-strip message returned by other relay nodes, the target relay node can read the data fragment identification of the data fragment subscribed by other relay nodes contained in the message content of the relay-strip message.

In the present specification, besides the relay node may Subscribe to the data fragment that the consensus node is responsible for distributing by sending a Subscribe message, the common node that establishes a network connection with the relay node may also Subscribe to the data fragment forwarded by the relay node by sending a Subscribe message.

For example, in one embodiment shown, for the target relay node, after subscribing to the data fragment that the consensus node is responsible for distributing, if a Subscribe message sent by a common node that establishes a network connection with the common node is received, a subscription relationship between the common node and the target data fragment that the target relay node is responsible for forwarding may also be established in response to the Subscribe message.

In one embodiment, as described above, when the target relay node receives an instruction to exit the area sub-network to which the target relay node belongs, the target relay node may determine, in response to the instruction, a target common node that is a candidate relay node from among 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 take over the relay node as a new relay node, and a common node that has established network connections with the target relay node, respectively establish network connections with other common nodes that have established network connections with the target relay node, respectively establish network connections with the other common nodes that have established network connections with the target relay node. In this case, after the target normal node serves as a new relay node to take over the target relay node, a Subscribe message may also be sent to a target consensus node that has established a network connection with the target relay node, so that the target consensus node establishes a subscription relationship between the new relay node and a target data slice to be distributed by the target consensus node in response to the Subscribe message, to completely take over the target relay node.

In this specification, after determining a target data fragment to be distributed by the target consensus node from the partitioned data fragments, the target consensus node may unicast the target data fragments to target relay nodes that establish network connection with the target consensus node in each zone network to which the target data fragment is sent.

In practical application, it should be noted that, in each relay node that establishes network connection with the target consensus node, there may be a relay node that does not subscribe to the target data slice, so when the target consensus node unicast sends the target data slice to each relay node that establishes network connection with the target consensus node in each zone network to which the target data slice is connected, the target relay node that subscribes to the target data slice in all relay nodes that establish network connection with the target consensus node may be determined based on a subscription relationship that is maintained locally, and then the target data slice may unicast send the target data slice to each zone sub-network to establish network connection with the target consensus node, and subscribe to the target relay node of the target data slice.

After receiving the target data fragments sent by the target common node in a unicast manner, the target relay node can forward the original common data to the common node which establishes network connection with the target common node by adopting a mode of continuously broadcasting and sending the target data fragments in the zone to which the target relay node belongs.

In one embodiment, the target relay node may continue to broadcast the target data slice to other relay nodes and common nodes in the target zone to which the target relay node belongs, where the other relay nodes and common nodes in the target zone establish a network connection, and may collect the data slice corresponding to the original consensus data, and then perform data recovery on the received data slice corresponding to the original consensus data to obtain the original consensus data.

For example, the erasure coding algorithm is used to encode the common data into 3f+1 data slices, and in this case, the other relay nodes and the common node collect 2f+1 data slices, so that the original common data can be successfully recovered. The implementation details of the data recovery of the collected data slices based on the erasure coding algorithm are not described in detail in the present specification.

In one embodiment, the common node may not participate in the data recovery of the consensus data; in this case, the target relay node may send only the target data fragment broadcast to other respective relay nodes in the target zone to which it belongs, which establish network connection with the target relay node. The target relay node and other relay nodes can collect the data fragments corresponding to the original consensus data, and then perform data recovery on the received data fragments corresponding to the original consensus data. After the original consensus data is restored, the target relay node and other relay nodes can further forward the restored consensus data to the common node with which the network connection is established.

Referring to fig. 4, fig. 4 is a flow chart illustrating another method of consensus data distribution 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 consensus sub-network comprises a plurality of consensus nodes for distributing data slices 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; full connection is established among all relay nodes in the regional subnetwork; the plurality of consensus nodes respectively establish network connection with at least one relay node in each regional subnetwork; the method can be applied to any target relay node in any target area sub-network, and comprises the following steps:

step 402, receiving a target data fragment sent by a target consensus node unicast in the consensus sub-network, wherein the target consensus node unicast is connected with the target relay node; the target data fragments are data fragments to be distributed, which correspond to the target consensus nodes, in a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm;

And step 404, continuing to send the target data fragment broadcast to other relay nodes and common nodes which establish network connection with the target relay node in the target area sub-network, so that the other relay nodes and the common nodes recover the received data fragments corresponding to the consensus data.

In the embodiment shown in fig. 4, the consensus data distribution method shown in fig. 3 is described from the perspective of a relay node. It will be understood that, regarding the implementation details of the common-knowledge data distribution method shown in fig. 4, reference may be made to the implementation details related to the common-knowledge data distribution method shown in fig. 3, and a detailed description will be omitted in this embodiment.

The above embodiments are illustrated below in conjunction with a specific example.

Referring to fig. 5, fig. 5 is a schematic diagram illustrating a block chain network-based consensus data distribution.

The blockchain network shown in fig. 5 contains two zones, denoted zone1 and zone2, respectively. The consensus sub-network comprises 4 consensus nodes (i.e. 3f+1 in total, and f has a value of 1), which are respectively denoted as consensus nodes 1-4. The consensus data passed by the consensus nodes in the consensus sub-network will be coded into 4 data slices, each referred to as a stripe, denoted as stripes 1-4, respectively.

Zone1 and zone2 in fig. 5 will each contain 4 relay nodes, each of which maintains full connectivity as planned. As shown in fig. 5, 4 relay nodes in zone1 are respectively denoted as relay nodes 5-8; the zone2 is provided with 4 relay nodes according to the design, and only 3 relay nodes are actually added temporarily and are respectively marked as relay nodes 10-12.

Each consensus node in the consensus sub-network is responsible for sending a strip of which the number matches the own number in strips 1-4. For example, as shown in fig. 5, consensus node 1 is responsible for distributing stripe1, consensus node 2 is responsible for distributing stripe2, consensus node 3 is responsible for distributing stripe1, and consensus node 4 is responsible for distributing stripe4.

The 4 consensus nodes respectively send the responsible strip to the relay node subscribed to the strip in a unicast mode; for example, as shown in fig. 5, the consensus node 1 unicast-transmits the strip 1 to the relay node 5 in the zone1 and the relay node 10 in the zone2 respectively; the consensus node 2 unicast-transmits the strip 2 to the relay node 6 in the zone1 and the relay node 12 in the zone2 respectively, the consensus node 3 unicast-transmits the strip 3 to the relay node 7 in the zone1 and the relay node 11 in the zone2 respectively, and the consensus node 4 unicast-transmits the strip 4 to the relay node 8 in the zone1 and the relay node 12 in the zone2 respectively.

After receiving the strips, the relay nodes in the zone1 and the zone2 can broadcast and send the received strips to other relay nodes in the zone based on the full connection between the relay nodes respectively, and finally each relay node can receive complete 4 strips, and any 3 strips (namely 2f+1) can correctly recover complete consensus data, and an extra strip is used as backup, so that once one relay node is down, the other relay nodes can normally recover the complete consensus data.

When the No. 9 node in the Zone1 enters the whole network, the No. 9 node can be used as a common node to establish network connection with the relay nodes 5-8 respectively as child nodes of the relay nodes 5-8, the common node 9 can correctly recover complete consensus data as long as receiving the strip forwarded by any 3 relay nodes, and meanwhile, network connection is established with 4 relay nodes such as the relay nodes 5-8, so that the robustness of network connection can be improved. If, for example, one of the relay nodes 5-8 is down, the common node 9 can still receive 3 strips, and the complete consensus data can be correctly recovered.

Since there are only 3 relay nodes in zone2, one relay node will receive one more strip. For example, relay node 12 in fig. 5 receives both strip 2 and strip 4, which common nodes 2 and 4 are responsible for distribution.

Assuming that node 13 in zone2 successfully joins zone2, node 13 will join zone2 as a relay node 13 since there are not enough relay nodes for the entire zone2.

Firstly, after the relay node 13 successfully joins the zone2, it is found that the number of the strips subscribed by the relay node 12 is the largest, and the strips subscribed by the relay node 12 are the strips 2 and the strips 4, and the relay node 13 may perform load sharing on the strips subscribed by the relay node 12, and randomly select half of the strips, for example, select the strip 2. The sub-multiplex message subscription strip 2 may then be sent to the consensus node 2, and the consensus node 2 may then unicast the strip 2 to the relay node 13.

Subsequently, when a new joining node in the Zone2 enters the whole network, network connection can be established with the relay nodes 10-13 as common nodes respectively, and the new joining node can correctly recover complete consensus data as a child node of the relay nodes 10-13 as long as the new joining node receives the strip forwarded by any 3 relay nodes.

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 consensus sub-network may include a plurality of consensus nodes for distributing data slices corresponding to the 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; full connection is established between the relay nodes in the regional subnetwork.

and the target relay node receives the target data fragments sent by the target consensus node in a unicast mode and continuously sends the target data fragments to other relay nodes and common nodes which establish network connection with the target relay node in the target area sub-network, so that the other relay nodes and the common nodes recover the received data fragments corresponding to the consensus data.

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

Fig. 6 is a schematic structural diagram of an electronic device according to an exemplary embodiment. Referring to fig. 6, at the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile storage 610, although other hardware required by other services is possible. One or more embodiments of the present description may be implemented in a software-based manner, such as by the processor 602 reading a corresponding computer program from the non-volatile storage 710 into the memory 608 and then running. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following process flows is not limited to each logic module, but may also be a hardware or logic device.

As shown in fig. 7, fig. 7 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 70 may 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 slices 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 determining module 701, configured to determine, from a specified number of data slices obtained by dividing the consensus data based on an erasure coding algorithm, a target data slice to be distributed by the target consensus node;

and the distribution module 702 is configured to unicast and send the target data fragments to target relay nodes in each regional subnetwork in the blockchain network, where the target relay nodes establish network connection with the target consensus node, so that the target relay nodes continue to send the target data fragments to other relay nodes and common nodes in the regional subnetwork to which the target relay nodes establish network connection, and perform data recovery on the received data fragments corresponding to the consensus data by the other relay nodes and the common nodes.

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

As shown in fig. 8, fig. 8 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 80 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 slices 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 apparatus 80 includes:

A receiving module 801, configured to receive a target data fragment sent by a target consensus node unicast in the consensus sub-network, where the target consensus node establishes a network connection with the target relay node; the target data fragments are data fragments to be distributed, which correspond to the target consensus nodes, in a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm;

and the forwarding module 802 continues to send the target data fragment broadcast to other relay nodes and common nodes in the target area sub-network, which establish network connection with the target relay node, so that the other relay nodes and the common nodes perform data recovery on the received data fragments corresponding to the consensus data.

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.

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 method for distributing consensus data in a blockchain network, wherein the blockchain network comprises a consensus sub-network and at least one regional sub-network respectively corresponding to different geographic positions; the consensus sub-network comprises a plurality of consensus nodes for distributing data slices 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 method is applied to any target consensus node in the plurality of consensus nodes; comprising the following steps:

2. The method of claim 1, prior to determining the target data slice to be distributed by the target consensus node from a specified number of data slices partitioned for the consensus data based on an erasure coding algorithm, further comprising:

acquiring consensus data passed by a consensus node consensus in the consensus sub-network;

dividing the consensus data into a specified number of data fragments based on an erasure coding algorithm; wherein the erasure coding algorithm adopted when the plurality of consensus nodes divide the consensus data is the same.

3. The method of claim 2, the specified number being a total number of the plurality of consensus nodes;

determining the target data fragments to be distributed corresponding to the target consensus node from the specified number of data fragments, wherein the method comprises the following steps:

respectively matching the node identification of the target consensus node with the data slicing identifications of the specified number of data slices; the data fragment identifier is an identifier obtained by respectively carrying out unified coding on each data fragment based on the total number of the plurality of common nodes;

and the plurality of consensus nodes determine the data fragments corresponding to the data fragment identifiers matched with the node identifiers of the target consensus nodes as target data fragments to be distributed by the target consensus nodes.

4. A method as claimed in claim 3, wherein each relay node in the regional subnetwork is respectively subscribed to a data shard to be distributed by at least one of the plurality of consensus nodes;

the target data fragments are respectively unicast transmitted to target relay nodes which establish network connection with the target consensus nodes in all regional subnetworks in the block chain network, and the target relay nodes comprise:

And the target data fragments are respectively unicast transmitted to target relay nodes which are connected with the target consensus nodes in all regional subnetworks in the block chain network and subscribe the target data fragments to be distributed by the target consensus nodes.

5. The method of claim 4, wherein a total number of relay nodes in the regional subnetwork is the same as a total number of the plurality of consensus nodes; and the relay nodes in the regional subnetwork are in one-to-one correspondence with the plurality of consensus nodes; correspondingly, each relay node in the regional subnetwork subscribes to the data fragments to be distributed by the corresponding consensus node in the plurality of consensus nodes respectively.

6. The method of claim 5, if the total number of relay nodes in the regional subnetwork is the same as the total number of the plurality of consensus nodes; and the relay nodes in the regional subnetwork are in one-to-one correspondence with the plurality of consensus nodes, so that any common node in the regional subnetwork is connected with at least N relay nodes in the regional subnetwork in a network manner; and the value of N is a data recovery threshold corresponding to the erasure coding algorithm.

7. The method of claim 6, the number of the plurality of consensus nodes being 3f+1; the value of N is not less than 2f+1; and f is the number of fault-tolerant nodes of the blockchain network.

8. 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; the network connection between the plurality of consensus nodes and the relay nodes corresponding to the consensus nodes is used for transmitting the data fragments to be distributed by the consensus nodes; and the network connection between the plurality of consensus nodes and other relay nodes except the corresponding relay nodes is used for transmitting heartbeat messages for maintaining the network connection.

9. The method of claim 1, the blockchain comprising a coalition chain.

10. A method for distributing consensus data in a blockchain network, wherein the blockchain network comprises a consensus sub-network and at least one regional sub-network respectively corresponding to different geographic positions; the consensus sub-network comprises a plurality of consensus nodes for distributing data slices 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 method is applied to any target relay node in any target area sub-network; comprising the following steps:

11. The method of claim 10, the specified number being a total number of the plurality of consensus nodes; a plurality of consensus nodes; the target data slicing is the data slicing corresponding to the data slicing identification matched with the node identification of the target consensus node; the data slicing identifiers are identifiers obtained by respectively carrying out unified coding on the specified number of data slices based on the total number of the plurality of common nodes.

12. The method of claim 11, wherein each relay node in the regional subnetwork is respectively subscribed to a data shard to be distributed by at least one of the plurality of consensus nodes;

receiving the target data fragment sent by the target consensus node unicast which establishes network connection with the target relay node in the consensus sub-network, comprising:

and receiving a target consensus node which establishes network connection with the target relay node in the consensus sub-network, and unicasting the transmitted target data fragment when confirming that the target relay node subscribes to the target data fragment to be distributed by the target consensus node.

13. The method of claim 12, the total number of relay nodes in the regional subnetwork being the same as the total number of the plurality of consensus nodes; and the relay nodes in the regional subnetwork are in one-to-one correspondence with the plurality of consensus nodes; correspondingly, each relay node in the regional subnetwork subscribes to the data fragments to be distributed by the corresponding consensus node in the plurality of consensus nodes respectively.

14. The method of claim 13, if the total number of relay nodes in the regional subnetwork is the same as the total number of the plurality of consensus nodes; and the relay nodes in the regional subnetwork are in one-to-one correspondence with the plurality of consensus nodes, so that any common node in the regional subnetwork is connected with at least N relay nodes in the regional subnetwork in a network manner; and the value of N is a data recovery threshold corresponding to the erasure coding algorithm.

15. The method of claim 14, the number of the plurality of consensus nodes being 3f+1; the value of N is not less than 2f+1; and f is the number of fault-tolerant nodes of the blockchain network.

16. The method of claim 13, wherein each relay node in the regional subnetwork establishes a full connection with each of the plurality of consensus nodes; the network connection between the plurality of consensus nodes and the relay nodes corresponding to the consensus nodes is used for transmitting the data fragments to be distributed by the consensus nodes; and the network connection between the plurality of consensus nodes and other relay nodes except the corresponding relay nodes is used for transmitting heartbeat messages for maintaining the network connection.

17. The method of claim 16, the number of the plurality of consensus nodes being 3f+1; the value of N is not less than 2f+1; and f is the number of fault-tolerant nodes of the blockchain network.

18. The method of claim 12, 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;

the method further comprises the steps of:

determining whether other relay nodes are included in the target area sub-network or not in response to successful joining of the target area sub-network;

If yes, acquiring the data fragment identification of the data fragments subscribed by the other relay nodes, determining the relay node with the largest number of the data fragments subscribed by the other relay nodes, and randomly selecting at least one data fragment from the data fragments subscribed by the relay node; and sending the fifth message to at least one consensus node responsible for distributing the at least one data fragment, so that the at least one consensus node responds to the fifth message to establish a subscription relationship between the target relay node and the at least one data fragment to be distributed by the at least one consensus node;

and if not, respectively sending the fifth message to each of the plurality of consensus nodes, so that each of the plurality of consensus nodes responds to the fifth message, and establishing a subscription relationship between the target relay node and the data fragments to be distributed by each of the plurality of consensus nodes.

19. The method of claim 18, the method further comprising:

receiving the fifth message sent by a common node which establishes network connection with the target relay node;

responding to the fifth message, and establishing a subscription relation between the common node and the target data fragments which are responsible for distribution by the target relay node;

The method for transmitting the target data fragment broadcast to the common node which establishes network connection with the target relay node in the target area sub-network comprises the following steps:

and sending the target data fragment broadcast to a common node which establishes network connection with the target relay node in the target area sub-network and subscribes to the target data fragment.

20. The method of claim 19, wherein the messages interacted between the nodes in the blockchain network further comprise a sixth message for querying a data shard subscribed to by the message receiving node; and a seventh message for returning, to the message sending node of the fifth message, a data fragment identifier of the data fragment subscribed by the message receiving node;

the obtaining the data slicing identification of the data slicing subscribed by the other relay nodes comprises the following steps:

transmitting the sixth message to the other relay node;

and receiving the seventh message returned by the other relay nodes, and reading the data fragment identification of the data fragment subscribed by the other relay nodes contained in the message content of the seventh message.

21. The method of claim 19, the messages interacted between the nodes in the blockchain network further comprising a fourth message for declaring that the messaging node exits the regional subnetwork to which it belongs with the identity of the relay node;

The method further comprises the steps of:

in response to an instruction of exiting the target area sub-network, determining a target common node serving as a candidate relay node from common nodes which establish network links with the target relay node, and sending the fourth message to the target common node to trigger the target common node to serve as a new relay node, establish network connections with the target consensus node, and respectively establish network connections with other common nodes which have established network connections with the target relay node; and sending the fifth message to the target consensus node, so that the target consensus node responds to the fifth message to establish a subscription relationship between the new relay node and the target data fragment to be distributed by the target consensus node.

22. The method of claim 21, determining a target normal node as a candidate relay node from among normal nodes having network links established with the target relay node, comprising:

and determining the common node which is added to the target area sub-network earliest by each common node based on the moment that each common node which establishes network link with the target relay node joins the target area sub-network, and determining the common node as the target common node serving as the candidate relay node.

23. The method of claim 10, the blockchain comprising a coalition chain.

24. A blockchain network, comprising: a consensus subnetwork, at least one regional subnetwork respectively corresponding to different geographic locations; the consensus sub-network comprises a plurality of consensus nodes for distributing data slices 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; full connection is established among all relay nodes in the regional subnetwork; the plurality of consensus nodes respectively establish network connection with at least one relay node in each regional subnetwork;

25. A node device in a blockchain network, the blockchain network comprising a consensus subnetwork and at least one regional subnetwork respectively corresponding to different geographic locations; the consensus sub-network comprises a plurality of consensus nodes for distributing data slices 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; comprising the following steps:

The determining module is used for determining target data fragments to be distributed by a target consensus node from a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm;

26. A node device in a blockchain network, the blockchain network comprising a consensus subnetwork and at least one regional subnetwork respectively corresponding to different geographic locations; the consensus sub-network comprises a plurality of consensus nodes for distributing data slices 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; comprising the following steps:

The receiving module is used for receiving target data fragments sent by a target consensus node which establishes network connection with a target relay node in the consensus sub-network in a unicast way; the target data fragments are data fragments to be distributed, which correspond to the target consensus nodes, in a specified number of data fragments obtained by dividing the consensus data based on an erasure coding algorithm;

27. 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 23 by invoking the machine readable instructions.

28. 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 19.