A consensus data distribution method in a blockchain network and a blockchain network

Abstract

The specification provides a consensus data distribution method in a blockchain network, comprising: determining a target data shard to be distributed by a target consensus node from a specified number of data shards obtained by splitting the consensus data based on an erasure code algorithm; unicasting the target data shard to each target relay node in each regional subnetwork of the blockchain network that establishes a network connection with the target consensus node, so that the target relay node continues to broadcast the target data shard to each other relay node and ordinary node in the regional subnetwork to which the target relay node belongs that establishes a network connection with the target relay node, and each other relay node and the ordinary node performs data recovery on the received data shard corresponding to the consensus data.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a consensus data distribution method, blockchain network, and node device in a blockchain network. Background Technology

[0002] Blockchain is a decentralized, trustless distributed ledger. Blockchain technology features multi-party writing, transparency, and immutability. Based on different access mechanisms, blockchains can be categorized into public chains, consortium chains, and private chains. For public chains, any node can join the network. Consortium chains, however, have access control functions; only authorized nodes can join the network, making them often more secure and efficient than public chains, primarily used for collaboration between enterprises or institutions. However, in practical applications, as the number of blockchain nodes increases, existing blockchain network topologies may lead to low bandwidth utilization and slow data distribution speeds, failing to meet the requirements of efficient data transmission in large-scale blockchain networks. Summary of the Invention

[0003] This specification proposes a consensus data distribution method in a blockchain network, the blockchain network including a consensus subnetwork and at least one regional subnetwork corresponding to different geographical locations; the consensus subnetwork includes multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional subnetwork; the non-consensus nodes in the regional subnetwork include at least one relay node; and at least one ordinary node that has established a network connection with the relay node; wherein, a full connection is established between the relay nodes in the regional subnetwork; the multiple consensus nodes have established network connections with at least one relay node in each regional subnetwork; the method is applied to any target consensus node among the multiple consensus nodes; including: From a specified number of data fragments obtained by segmenting the consensus data based on erasure coding algorithm, the target data fragment to be distributed to the target consensus node is determined; The target data fragments are unicast to the target relay nodes in each regional subnetwork of the blockchain network that have established network connections with the target consensus node. The target relay nodes then broadcast the target data fragments to other relay nodes and ordinary nodes in their respective regional subnetworks that have established network connections with them. The other relay nodes and ordinary nodes then perform data recovery on the received data fragments corresponding to the consensus data.

[0004] This specification also proposes a consensus data distribution method in a blockchain network, wherein the blockchain network includes a consensus subnetwork and at least one regional subnetwork corresponding to different geographical locations; the consensus subnetwork includes multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional subnetwork; the non-consensus nodes in the regional subnetwork include at least one relay node; and at least one ordinary node that has established a network connection with the relay node; wherein, a full connection is established between the relay nodes in the regional subnetwork; the multiple consensus nodes have established network connections with at least one relay node in each regional subnetwork; the method is applied to any target relay node in any target regional subnetwork; including: The system receives a target data fragment unicast from a target consensus node that has established a network connection with the target relay node in the consensus subnetwork; wherein the target data fragment is a data fragment to be distributed corresponding to the target consensus node from a specified number of data fragments obtained by dividing the consensus data based on the erasure coding algorithm. The target data fragments are then broadcast to other relay nodes and ordinary nodes in the target area subnetwork that have established network connections with the target relay node, so that the other relay nodes and ordinary nodes can recover the data fragments corresponding to the consensus data.

[0005] This specification also proposes a blockchain network, comprising: a consensus subnetwork, and at least one regional subnetwork corresponding to different geographical locations; the consensus subnetwork includes multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional subnetworks; the non-consensus nodes in the regional subnetworks include at least one relay node; and at least one ordinary node that has established a network connection with the relay node; full connectivity is established among the relay nodes in the regional subnetworks; and the multiple consensus nodes have established network connections with at least one relay node in each of the regional subnetworks. Among them, any target consensus node among the plurality of consensus nodes determines the 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 the erasure coding algorithm; and unicasts the target data fragments to the target relay nodes that have established network connections with the target consensus node in each regional sub-network of the blockchain network. The target relay node receives the target data fragment unicast by the target consensus node, and continues to broadcast the target data fragment to other relay nodes and ordinary nodes in the target area subnetwork that have established network connections with the target relay node, so that the other relay nodes and ordinary nodes can perform data recovery on the received data fragments corresponding to the consensus data.

[0006] This specification also proposes a node device in a blockchain network, the blockchain network including a consensus subnetwork and at least one regional subnetwork corresponding to different geographical locations; the consensus subnetwork includes multiple consensus nodes for distributing data shards corresponding to the consensus data to non-consensus nodes in the regional subnetworks; the non-consensus nodes in the regional subnetworks include at least one relay node; and at least one ordinary node that has established a network connection with the relay node; wherein, a full connection is established between the relay nodes in the regional subnetworks; the multiple consensus nodes have established network connections with at least one relay node in each of the regional subnetworks; including: The determination module determines the target data fragment to be distributed to the target consensus node from a specified number of data fragments obtained by segmenting the consensus data based on the erasure coding algorithm; The distribution module unicasts the target data fragments to target relay nodes in various regional sub-networks of the blockchain network that have established network connections with the target consensus node. This allows the target relay nodes to broadcast the target data fragments to other relay nodes and ordinary nodes in their respective regional sub-networks that have established network connections with them. The other relay nodes and ordinary nodes then perform data recovery on the received data fragments corresponding to the consensus data.

[0007] This specification also proposes a node device in a blockchain network, the blockchain network including a consensus subnetwork and at least one regional subnetwork corresponding to different geographical locations; the consensus subnetwork includes multiple consensus nodes for distributing data shards corresponding to the consensus data to non-consensus nodes in the regional subnetworks; the non-consensus nodes in the regional subnetworks include at least one relay node; and at least one ordinary node that has established a network connection with the relay node; wherein, a full connection is established between the relay nodes in the regional subnetworks; the multiple consensus nodes have established network connections with at least one relay node in each of the regional subnetworks; including: The receiving module receives a target data fragment unicast from a target consensus node that has established a network connection with the target relay node in the consensus subnetwork; wherein the target data fragment is a data fragment to be distributed corresponding to the target consensus node from a specified number of data fragments obtained by dividing the consensus data based on the erasure coding algorithm; The forwarding module continues to broadcast the target data fragments to other relay nodes and ordinary nodes in the target area subnetwork that have established network connections with the target relay node, so that the other relay nodes and ordinary nodes can recover the data fragments corresponding to the consensus data received.

[0008] In the above embodiments, when each consensus node in the consensus subnetwork distributes consensus data to each regional subnetwork, each consensus node only needs to unicast one consensus data fragment corresponding to itself to the relay node that has established a network connection with it. Then, the relay nodes in each regional subnetwork broadcast the received consensus data fragments in their respective regional subnetworks to complete the distribution of consensus data. Therefore, for the consensus subnetwork, it is only necessary to send one complete set of consensus data to each regional subnetwork, rather than sending a complete set of consensus data to each relay node that has established a network connection with it. This can further reduce the bandwidth load of the consensus layer of the blockchain network when distributing consensus data and improve consensus efficiency. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This specification illustrates a network architecture diagram of a blockchain network according to an exemplary embodiment. Figure 2 This specification is a flowchart illustrating a method for forming a blockchain network according to an exemplary embodiment; Figure 3 This is a flowchart illustrating a consensus data distribution method in a blockchain network according to an exemplary embodiment. Figure 4 This is a flowchart illustrating another consensus data distribution method in a blockchain network according to an exemplary embodiment of this specification; Figure 5This is a schematic diagram illustrating consensus data distribution based on a blockchain network according to an exemplary embodiment of this specification; Figure 6 This is a schematic structural diagram of an electronic device according to an exemplary embodiment of this specification; Figure 7 This specification is a block diagram illustrating a node device in a blockchain network according to an exemplary embodiment; Figure 8 This is a block diagram of a node device in another blockchain network illustrated in this specification according to an exemplary embodiment. Detailed Implementation

[0011] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0012] The current blockchain networks mainly use the following three network topologies and networking methods when building a network.

[0013] 1) Network topology based on direct connection When using a direct-connect network topology for networking, consensus nodes in the consensus layer can be fully connected to each other. Other newly added non-consensus nodes (full nodes) can directly establish network connections with the consensus nodes, and the consensus nodes can then transmit the consensus results to the non-consensus nodes through this network connection.

[0014] This network topology is simple and practical for small-scale networking scenarios. The bandwidth of each consensus node is used not only for data consensus but also for sending consensus results to non-consensus nodes that have established network connections with the consensus node. As the number of new nodes joins the network, the consensus nodes need to maintain more and more network connections, and the amount of data they need to send also increases.

[0015] Furthermore, since the bandwidth consumption of a consensus node when sending data is typically positively correlated with the number of nodes in the blockchain network that have established network connections with the consensus node, the more non-consensus nodes that have established network connections with the consensus node, the greater the uplink bandwidth load on the consensus node. When the number of non-consensus nodes that have established network connections with the consensus node is small, each non-consensus node can quickly receive the latest consensus result.

[0016] However, once the number of nodes that establish network connections with the consensus node reaches its limit and exceeds the bandwidth capacity of the consensus node, the bandwidth load of the consensus layer will also decrease sharply. This may lead to a decrease in data distribution efficiency, an increase in consensus time, a decrease in throughput, and so on, ultimately weakening the consensus capability of the entire system.

[0017] It is evident that this direct-connection network topology typically lacks scalability and is ill-suited for scenarios involving large-scale blockchain networks.

[0018] 2) Randomized networking method When using a random networking approach, consensus nodes in the consensus layer can still maintain full connectivity. Newly added non-consensus nodes can prioritize establishing network connections with consensus nodes. When the number of nodes with established network connections to consensus nodes reaches its limit, newly added nodes can randomly select one node from those already connected to consensus nodes as a relay node and establish a network connection with that relay node to receive consensus data.

[0019] While a randomized networking approach can effectively reduce the bandwidth load on consensus nodes sending data to other non-consensus nodes, the random connections between these nodes do not consider their physical topology. A node's logical neighbors may have significant physical latency. Therefore, this networking method may still increase data transmission latency, leading to larger fluctuations in overall network data transmission delay.

[0020] 3) Network topology based on clustered networks When using a clustered network topology, a consensus node can act as a cluster head node, managing many child nodes. Each consensus node distributes data to its child nodes, and the child nodes then forward data to each other.

[0021] However, this networking approach results in weak network robustness. Each consensus node acts as a cluster head node, and the consensus result is distributed to all child nodes in its cluster through the cluster head. If the cluster head node fails, other nodes in a cluster cannot receive the data in a timely manner and can only obtain the data through other consensus nodes or other full nodes.

[0022] It is evident that adopting a cluster-based network topology will result in poor robustness of the blockchain network and insufficient robustness of the cluster network.

[0023] In summary, considering the requirements for transmission latency, scalability, and robustness, the current networking methods used in blockchain networking cannot meet the data transmission efficiency and performance requirements of large-scale blockchain network deployments.

[0024] Please see Figure 1 , Figure 1 This is a blockchain networking framework proposed in related technologies, suitable for large-scale nodes.

[0025] like Figure 1 As shown, the above network architecture may include the following components: 1: Consensus Subnetwork The consensus subnetwork, also known as the internal network of the consensus layer, can include multiple consensus nodes. These nodes can establish network connections with each other for data exchange during the data consensus process.

[0026] 2: At least one regional subnetwork In the above network architecture, the blockchain network, excluding the consensus layer, can be divided into at least one regional sub-network.

[0027] like Figure 1 As shown, each regional subnetwork can be called a zone, and each zone can contain multiple non-consensus nodes. Non-consensus nodes typically refer to full nodes in the blockchain network that do not participate in consensus. Different zones can correspond to different geographical locations.

[0028] It should be noted that the number of regional sub-networks in a blockchain network is usually determined by the size of the blockchain network, and is unrelated to the number of consensus nodes participating in the consensus layer.

[0029] To reduce the bandwidth pressure on consensus nodes when distributing consensus data to various zones, each consensus node can send data only to a subset of nodes within each zone; these nodes are called relay nodes. The relay nodes then forward the consensus data distributed by the consensus nodes in the consensus layer to other nodes within the zone. These nodes that receive the forwarded consensus data from the relay nodes are called ordinary nodes.

[0030] Please continue reading Figure 1 For each non-consensus node in a regional subnetwork, there may be at least one relay node and at least one ordinary node.

[0031] Among them, the aforementioned relay nodes can establish network connections with the consensus nodes of the consensus layer to receive consensus data from the consensus nodes of the consensus layer.

[0032] The aforementioned ordinary nodes can establish network connections with the aforementioned relay nodes to receive consensus data forwarded by the relay nodes.

[0033] For example, in practical applications, the aforementioned ordinary node can send the transaction sent by the client to the relay node through the network connection between the client and the relay node. Then, the relay node submits the transaction to the consensus node in the consensus layer for consensus processing through the network connection between the relay node and the consensus node in the consensus layer.

[0034] Correspondingly, after the consensus nodes of the consensus layer have reached a consensus on the transactions submitted by each ordinary node, they can generate blocks based on these consensus-reached transactions. Then, through the network connection with the relay node, they can send the block to the relay node, which in turn can send the block to the ordinary node through the network connection with the ordinary node.

[0035] It should be noted that, Figure 1 The connection relationships between the nodes in this document are merely illustrative and are not intended to limit the technical solutions described herein in any way.

[0036] In Adoption Figure 1 When the network framework shown is used for blockchain networking, any network device that is to join the blockchain network can first determine the target area sub-network corresponding to the geographical location of the network device, and then initiate registration for the target area sub-network.

[0037] Once the registration for the target area subnetwork is completed, it can be further determined whether the network device meets the conditions to become a relay node. If so, it can establish a network connection with the consensus node in the consensus subnetwork as a relay node; if not, it can establish a network connection with the relay node in the target area subnetwork as a regular node.

[0038] For example, to improve the robustness of the aforementioned blockchain network, if a network device meets the conditions to become a relay node, it can establish a network connection as a relay node with at least N consensus nodes in the consensus sub-network; where N is greater than the maximum number of fault-tolerant nodes in the blockchain network. If a network device does not meet the conditions to become a relay node, it can establish a network connection as a regular node with at least M relay nodes in the target area sub-network; where M is a pre-calculated robustness threshold corresponding to the relay nodes in the target area sub-network.

[0039] It is evident that adopting Figure 1 The network framework shown can be used for blockchain networking and is applicable to networking scenarios with a large number of nodes.

[0040] For example, by pre-dividing the blockchain network into a consensus subnetwork and at least one regional subnetwork corresponding to different geographical locations, a network device, when joining the blockchain network as a blockchain node, can initiate registration in the nearest target regional subnetwork corresponding to its geographical location and join as a blockchain node in that target regional subnetwork. Since nodes within the same regional subnetwork are physically closer together and have lower data transmission latency, nodes within the same regional subnetwork can transmit data awaiting consensus to the consensus node more quickly and receive consensus data distributed by the consensus node more quickly.

[0041] On the other hand, by further dividing the non-consensus nodes in the regional subnetwork into relay nodes that receive consensus data from the consensus nodes and ordinary nodes that receive consensus data forwarded by the relay nodes, the consensus nodes in the consensus subnetwork can distribute the consensus data to the relay nodes when distributing consensus data to the non-consensus nodes in each regional subnetwork. The relay nodes will then forward the consensus data to each ordinary node, eliminating the need to distribute the consensus data to each non-consensus node separately. This reduces the bandwidth load of the consensus layer of the blockchain network when distributing consensus data and improves consensus efficiency.

[0042] However, based on Figure 1 The network framework shown can be used for blockchain networking, and although it can be applied to networking scenarios with a large number of nodes, when each consensus node in the consensus subnetwork distributes consensus data to the relay node that has established a network connection with it, it usually needs to distribute a complete copy of the consensus data to each relay node that has established a connection with each consensus node. Therefore, the consensus node still faces a very high bandwidth load when distributing consensus data.

[0043] Therefore, in this specification, Figure 1 Based on the network framework shown, a consensus data distribution method in a blockchain network is proposed.

[0044] For consensus data that has been agreed upon by all consensus nodes in the consensus subnetwork, it can be pre-divided into a specified number of data fragments based on erasure coding algorithm. Each consensus node in the consensus subnetwork can be responsible for distributing a portion of the data fragments.

[0045] When distributing consensus data, any target consensus node in the consensus subnetwork can first determine the target data fragment to be distributed from the specified number of data fragments, and then unicast the target data fragment to the target relay nodes in each regional subnetwork that have established network connections with the target consensus node.

[0046] After receiving the target data fragment unicast by the aforementioned target consensus node, the target relay node may, in one scenario, continue to broadcast the target data fragment to other relay nodes and ordinary nodes in its regional subnetwork that have established network connections with it. The other relay nodes and ordinary nodes will then recover the data fragments corresponding to the consensus data they received.

[0047] In another scenario, the target data can be further fragmented and broadcast to other relay nodes in its regional subnetwork that have established network connections with it. These other relay nodes can then recover the data fragments corresponding to the consensus data they receive, and further forward the recovered consensus data to the ordinary nodes that have established network connections with it.

[0048] In the above embodiments, when each consensus node in the consensus subnetwork distributes consensus data to each regional subnetwork, each consensus node only needs to unicast one consensus data fragment corresponding to itself to the relay node that has established a network connection with it. Then, the relay nodes in each regional subnetwork broadcast the received consensus data fragments in their respective regional subnetworks to complete the distribution of consensus data. Therefore, for the consensus subnetwork, it is only necessary to send one complete set of consensus data to each regional subnetwork, rather than sending a complete set of consensus data to each relay node that has established a network connection with it. This can further reduce the bandwidth load of the consensus layer of the blockchain network when distributing consensus data and improve consensus efficiency.

[0049] Please see Figure 2 , Figure 2 This is a flowchart illustrating a blockchain network formation method according to an exemplary embodiment, which can be applied to any blockchain network to be joined. Figure 1 The illustrated network device is part of a blockchain network with a network architecture; the method includes: Step 202: Determine the target area sub-network corresponding to the geographical location of the network device, and initiate registration for the target area sub-network; The aforementioned network devices can specifically be service devices that are waiting to join the blockchain network as blockchain nodes. The specific form of these service devices is not specifically limited in this specification; for example, taking the aforementioned blockchain network as a consortium blockchain, the aforementioned network devices can specifically be server-side devices (such as servers or server clusters) corresponding to consortium members in the consortium blockchain.

[0050] like Figure 1As shown, since the blockchain network is divided into several zones corresponding to different geographical locations, when the network device joins the blockchain network as a blockchain node, it can first determine its own geographical location, and then determine the target zone corresponding to the geographical location of the network device based on its own geographical location.

[0051] The geographical location of the aforementioned network device can be either its precise geographical location or its relative geographical location, and is not specifically limited in this specification.

[0052] For example, the aforementioned precise geographical location could specifically refer to the precise location of the network device, such as GPS coordinates. The aforementioned relative geographical location could specifically refer to the region information pre-configured for the network device; for example, taking the aforementioned network device as a service device, the aforementioned relative geographical location could specifically refer to the service device region of the server cluster to which the service device belongs. This service device region is typically identified according to the administrative region of the data center or other facilities where the server cluster is located.

[0053] After determining the target zone corresponding to its own geographical location, the aforementioned network devices can further initiate a registration process for that target zone.

[0054] It should be noted that the aforementioned network devices typically need to complete the registration for the aforementioned blockchain network before initiating the registration for the aforementioned target zone.

[0055] In one embodiment shown, when registering with the blockchain network, the network device can initiate a registration request for the blockchain network to a blockchain service platform (such as a BaaS platform), so that the blockchain service platform can respond to the registration request and perform registration processing for the network device; the specific details of the registration processing are not described in detail; for example, taking a consortium blockchain as an example, the registration processing can usually include authorization and access processing for the consortium blockchain.

[0056] After the blockchain service platform completes the registration process for the network device, the network device can synchronize service data related to the blockchain network from the blockchain service platform in response to the completion of the registration for the blockchain network. The service data related to the blockchain network can typically include information such as the network addresses (e.g., IP addresses) of various consensus nodes in the blockchain network.

[0057] When the aforementioned network device initiates registration for the aforementioned target zone, it can do so by packaging a registration transaction and submitting the registration transaction to the blockchain network for execution.

[0058] In one embodiment shown, the network device can further construct a registration transaction for the target zone; the registration transaction can include registration information corresponding to the network device; it should be noted that the specific content of the registration information can include the network address corresponding to the network device; of course, in practical applications, in addition to the network address corresponding to the network device, other forms of registration information can also be included; for example, the public key obtained by the network device after successfully registering with the blockchain network, the network identifier (such as the network number) of the target zone to be registered, etc., which will not be listed one by one in this specification.

[0059] Then, the network device can submit the registration transaction to the consensus subnetwork, where the consensus nodes reach a consensus on the transaction. After consensus is reached, the registration transaction is stored on the blockchain to complete the registration for the target zone subnetwork. Other non-consensus nodes in the target zone can discover newly joined non-consensus nodes by retrieving the registration transaction stored on the blockchain.

[0060] It should be noted that the specific type of the aforementioned registered transaction is not specifically limited in this specification. It can be a native transaction type supported by the blockchain network or a smart contract call transaction.

[0061] For example, in one instance, a smart contract for registering and managing the blockchain network can be deployed on the blockchain. In this case, the registration transaction can specifically be a smart contract call transaction corresponding to the smart contract. When the network device initiates registration for the target zone, it can package a smart contract call transaction for the smart contract, which can specifically include registration information as a contract call parameter. Then, the smart contract call transaction containing the registration information can be submitted to the consensus sub-network to trigger the distributed execution of the execution code contained in the smart contract by the consensus nodes in the consensus sub-network to run the registration logic for registering for the target zone and generate a registration event for the target zone by the network device.

[0062] Then, consensus can be reached on the generated registration event, enabling distributed consistency among consensus nodes regarding the smart contract call results; this registration event may contain the aforementioned registration information. After consensus is reached on the registration event, each consensus node can store the registration event on the blockchain to complete the registration for the target sub-network. For example, the generated registration event can be stored as part of the transaction receipt corresponding to the smart contract call transaction in the database corresponding to the blockchain.

[0063] Step 204: In response to the completion of registration for the target area sub-network, determine whether the network device meets the conditions to become the relay node; After the aforementioned network devices complete their registration for the target zone, they can further determine whether they meet the conditions to become the aforementioned relay nodes, and confirm their node role in the target zone based on the determination result.

[0064] In one embodiment shown, before further determining whether it meets the conditions to become a relay node, the network device first needs to obtain the registration transactions submitted by other non-consensus nodes in the target zone stored on the blockchain, and obtain the network addresses corresponding to the other non-consensus nodes in the target zone from the registration transactions, so as to discover the other non-consensus nodes in the target zone.

[0065] For example, if the aforementioned registration transaction is a smart contract call transaction corresponding to the aforementioned smart contract, in this case, the aforementioned network device can listen to the registration events of other non-consensus nodes in the aforementioned target zone generated by the aforementioned smart contract stored on the blockchain; then, in response to the listened registration events, it can obtain the registration information of the aforementioned other non-consensus nodes in the target zone contained in the registration events, and further obtain the network addresses corresponding to the other non-consensus nodes in the target zone from the obtained registration information.

[0066] It should be noted that, since the aforementioned registration event may contain the network identifier of the target zone, when the aforementioned network device is monitoring the registration events of other non-consensus nodes in the target zone generated by the aforementioned smart contract for the target zone stored on the blockchain, it can specifically do so by monitoring the registration events generated by the smart contract that contain the network identifier of the target zone stored on the blockchain.

[0067] After the network device obtains the network addresses corresponding to other non-consensus nodes in the target zone from the above registration transaction, it can randomly select at least one network address from the obtained network addresses corresponding to the non-consensus nodes in the target zone and establish network connections with at least one non-consensus node corresponding to the at least one network address.

[0068] It should be noted that the network connection established by the network device with at least one of the aforementioned non-consensus nodes can specifically serve as an initial transmission channel between the network device and other non-consensus nodes in the target zone after the network device joins the target zone. This initial transmission channel is used for exchanging initialization information with other non-consensus nodes.

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

[0070] Of course, if establishing a network connection with at least one of the reselected non-consensus nodes still fails at this point, at least one network address can be randomly selected from the network addresses of non-consensus nodes in the neighboring zones of the target zone, and then a network connection can be established with at least one non-consensus node in the neighboring zones until the network device successfully establishes a network connection with the target zone or at least one non-consensus node in the neighboring zones of the target zone.

[0071] In this specification, after a network device successfully registers with the aforementioned target zone, it can further determine whether it meets the conditions to become a relay node, and then confirm its node role in the target zone based on the determination result.

[0072] In one embodiment shown, the condition for a network device to become a relay node in the target zone can be whether the target zone has a sufficient number of relay nodes.

[0073] In this scenario, when determining whether a network device meets the conditions to become a relay node, it can first obtain the number of relay nodes in the target area sub-network, and then determine whether the number of relay nodes in the target zone is lower than the threshold M.

[0074] Specifically, the threshold M can be a pre-calculated robustness threshold corresponding to the relay nodes in the target zone. This robustness threshold reflects the robustness requirement for the target zone. That is, if the number of relay nodes in the target zone is not less than M, the target zone is considered to meet the robustness requirement.

[0075] If the number of relay nodes in the target zone is less than the threshold M, it can be determined that the network device meets the conditions to become a relay node; otherwise, it can be determined that the network device does not meet the conditions to become a relay node.

[0076] Specifically, when network devices obtain the number of relay nodes in the target zone, they can do so by exchanging messages with other non-consensus nodes through the aforementioned initialized transmission channel.

[0077] In one embodiment shown, the message types supported by the blockchain network for interaction between nodes may specifically include the messages shown below: The get-relay-nodes message (referred to as the first message) is used to query the node information of the relay nodes in the sub-network of the area corresponding to the message receiving node.

[0078] The relay-nodes message (referred to as the second message) is used to return a set of node information of relay nodes in the subnetwork of the area where the message receiving node is located, which is maintained by the message receiving node, to the message sending node of the get-relay-nodes message.

[0079] In this scenario, when the network device obtains the number of relay nodes in the target zone by exchanging messages with other non-consensus nodes through the aforementioned initialization transmission channel, it can specifically send the aforementioned `get-relay-nodes` message to at least one of the aforementioned non-consensus nodes that have already established a network connection. After receiving the `get-relay-nodes` message, each of the aforementioned non-consensus nodes can return a `relay-nodes` message to the network device. Upon receiving the `relay-nodes` message, the network device can read the node information set of the relay nodes in the target zone maintained by the aforementioned non-consensus nodes, contained in the message content of the `relay-nodes` message, and then determine the number of relay nodes in the target zone based on this node information set; for example, in practical applications, the number of relay nodes in the target zone can be determined by statistically analyzing the node information in this node information set.

[0080] If at least one non-consensus node is multiple non-consensus nodes, the network device can obtain multiple relay-nodes messages returned by these multiple non-consensus nodes. In this case, the network device can read the node information set of the relay nodes in the target zone maintained by these multiple non-consensus nodes in the message content of the relay-nodes messages returned by these multiple non-consensus nodes respectively, then take the union of the read node information sets, and then determine the number of relay nodes in the target zone based on the obtained union.

[0081] In one embodiment shown, the message types supported by the aforementioned blockchain network for interaction between nodes, in addition to including messages such as get-relay-nodes messages and relay-nodes messages, may also include, in practical applications, the following messages: The Relayer message (referred to as the third message) is used to declare that the message sending node is a normally functioning relay node.

[0082] In this scenario, relay nodes in the target zone can periodically broadcast Relayer messages within the zone. The message content of each Relayer message includes the node information of the relay node. Other non-consensus nodes in the target zone (including other relay nodes and other ordinary nodes) can each maintain a set of node information corresponding to the relay nodes in the target zone. Upon receiving a Relayer message, they can read the node information of the relay node contained in the message content and add that information to their locally maintained set of node information.

[0083] The Leave message (referred to as the fourth message) is used to declare that the message sending node is leaving its regional subnetwork as a relay node.

[0084] In this scenario, when a relay node in the target zone receives an instruction to leave its assigned sub-network, it can respond to the instruction by identifying a target ordinary node from among the ordinary nodes that have established network links with the relay node as a candidate relay node, and sending a Leave message to the target ordinary node. This triggers the target ordinary node to take over as the new relay node, establish network links with the consensus node that has already established network links with the relay node, and establish network links with the other ordinary nodes that have already established network links with the relay node.

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

[0086] It should be noted that, in practical applications, the aforementioned command to exit its assigned sub-network can be either a command manually entered by the administrator of the relay node, or a command automatically triggered when the relay node has not responded for an extended period and is suspected of crashing. This specification does not impose any specific limitations on this command.

[0087] The specific method for determining the target ordinary node as a candidate relay node from among the ordinary nodes that have established network links with the relay node can be flexibly customized based on requirements in practical applications, and no specific limitations are made in this specification.

[0088] For example, in one instance, the earliest ordinary node to join the sub-network of the area to which the relay node belongs can be determined based on the time when each ordinary node that has established a network link with the relay node joins the sub-network of the area to which the relay node belongs, and then that ordinary node can be identified as the target ordinary node as a candidate relay node.

[0089] Step 206: If yes, establish a network connection with the consensus node in the consensus sub-network as a relay node; if no, establish a network connection with the relay node in the target area sub-network as a regular node.

[0090] In this specification, if a network device determines that it meets the conditions to become a relay node in the target zone, it can then act as a relay node to further establish a network connection with the consensus nodes in the consensus sub-network; otherwise, it can act as a regular node to establish a network connection with the relay nodes in the target zone.

[0091] It should be noted that the number of consensus nodes or relay nodes that establish network connections with network devices can be one or more. In practical applications, this number can be determined based on the robustness requirements of the aforementioned blockchain network.

[0092] For example, if high robustness is required for the aforementioned blockchain network, a network device acting as a relay node can simultaneously establish network connections with multiple consensus nodes in the consensus subnetwork. In this case, if one consensus node fails, the network device can still receive data from the other consensus nodes. Similarly, when acting as a regular node, a network device can also simultaneously establish network connections with multiple relay nodes in the target zone. In this case, if one relay node fails, the network device can also receive data from the other consensus nodes.

[0093] In practical applications, blockchain networks typically have a maximum number of fault-tolerant nodes. For example, if the consensus algorithm used by the blockchain network is the Byzantine consensus algorithm, the maximum number of fault-tolerant nodes is usually the maximum number f of Byzantine nodes that the blockchain network can tolerate.

[0094] On the one hand, when a relay node establishes network connections with more than f consensus nodes, even in the extreme case where all f consensus nodes fail simultaneously (Byzantine nodes can be directly considered as failed nodes), it can be ensured that at least one consensus node among those connected to the relay node will still be functioning normally. In other words, the relay node can still receive data from at least one consensus node. In this scenario, the relay node can be considered to meet the robustness requirements of a blockchain network.

[0095] On the other hand, as mentioned earlier, a robustness threshold M corresponding to the relay nodes in the target zone can be pre-calculated. This robustness threshold M reflects the robustness requirement for the target zone. That is, when the number of relay nodes in the target zone is not less than M, the target zone is considered to meet the robustness requirement. In this case, when a regular node establishes a network connection with not less than M relay nodes, the regular node can be considered to meet the robustness requirement of the blockchain network.

[0096] Based on this, in one embodiment shown, if a network device determines that it meets the conditions to become a relay node in the target zone, it can establish network connections with at least N consensus nodes in the consensus sub-network as a relay node; wherein, the value of N can be greater than the maximum number of fault-tolerant nodes in the blockchain network. For example, in one scenario, taking the Byzantine consensus algorithm used in the blockchain network as an example, the number of fault-tolerant nodes in the blockchain network (i.e., the number of Byzantine nodes) can be denoted as f, and the number of consensus nodes participating in the consensus in the blockchain network can be 3f+1. In this case, the value of N can be in the range of (f, 3f+1). That is, N can be a value greater than f and less than or equal to 3f+1.

[0097] Correspondingly, if a network device determines that it does not meet the conditions to become a relay node in the target zone, it can also establish network connections as a regular node with at least M relay nodes in the target zone; where, as mentioned above, M is a pre-calculated robustness threshold corresponding to the relay nodes in the target zone.

[0098] It should be noted that, in practical applications, the value of M corresponding to each zone in the blockchain network can be pre-calculated by the blockchain service platform corresponding to the blockchain network based on the actual size of each zone, or it can be calculated autonomously by the non-consensus nodes in each zone based on the actual size of the current zone. This specification does not impose any special restrictions.

[0099] The following describes in detail the calculation process of the value of M, taking the Byzantine consensus algorithm used by the aforementioned blockchain network as an example.

[0100] In practical applications, malicious behavior by Byzantine nodes in non-consensus layer networks of blockchain networks typically involves refusing to send data or delaying data transmission. Therefore, in this embodiment, malicious behavior such as refusing to send data or delaying data transmission by Byzantine nodes in relay nodes and ordinary nodes can be regarded as node downtime.

[0101] When there is only one zone in the network, if all the relay nodes in the zone fail (i.e., all are Byzantine nodes), the nodes in the zone will be unable to receive data for a long time. To ensure efficient data transmission, theoretically, a zone must have at least a sufficient number of relay nodes to prevent the situation where all relay nodes fail.

[0102] In one embodiment shown, the probability of an honest node failing within a certain operating time is denoted as . The probability of a Byzantine node going down is In this scenario, the probability of any node in the blockchain network failing can be calculated using the following formula: (Formula 1) Where f represents the number of Byzantine nodes that the blockchain network can tolerate; T represents the total number of nodes in the blockchain network; This represents the probability that any Byzantine node in the blockchain network will fail. This represents the probability that any honest node in the blockchain network will fail.

[0103] In one embodiment shown, assuming the robustness threshold of the relay nodes in the target zone is represented by M, the probability that all M relay nodes will fail can be expressed by the following formula: (Formula 2) It should be noted that since the probability of any Byzantine node in the blockchain network going down is the same as the probability of any Byzantine node in the target zone going down, therefore in Formula 2 above... This can represent the probability that any Byzantine node in the aforementioned target zone will fail. Similarly, in Equation 2 above... It can also represent the probability that any honest node in the target zone will crash. It can also be used to represent the probability that any non-consensus node in the target zone will fail.

[0104] Please refer to Formula 1 for further details. As mentioned earlier, since Byzantine nodes are considered to be down by default, the above... =1. Because of the above formula 1... The values ​​in this part are usually very small and can be ignored, so if... Substituting 1 into Formula 1, we can conclude from Formula 1 that... The value of can usually be approximately equal to .

[0105] Based on this, in one embodiment shown, the above... The value of can be calculated using the following formula: (Formula 3) Substituting Formula 3 into Formula 2, we obtain the following calculation formula: (Formula 4) In summary, Formula 4 can be used to calculate the value of M corresponding to the target zone.

[0106] For example, by deriving from Formula 4, we can obtain the formula for calculating M: (Formula 5) It should be noted that, The value of is usually related to the robustness requirements of each zone and the size of each zone (such as the total number of nodes). Different zones have different values. The value of may vary. Therefore, in practical applications, the robustness threshold can be flexibly set for each zone based on the robustness requirements of each zone. .

[0107] In one embodiment shown, when the network device, acting as a relay node, further establishes network connections with N consensus nodes in the consensus subnetwork, it can specifically randomly select at least N network addresses from the network addresses of the consensus nodes in the consensus subnetwork obtained during the registration phase of the blockchain network, and then establish network connections with the randomly selected N network addresses.

[0108] When a network device establishes a network connection with M relay nodes in a target zone as a regular node, it can also randomly select M network addresses from the network addresses of the relay nodes in the target zone obtained during the registration phase of the target zone, and establish a network connection with the randomly selected M network addresses.

[0109] The specific type of network connection is not specifically limited in this specification; for example, taking the network address as an IP address, the network connection can be a TCP connection. In this case, the network device can establish a TCP connection by performing a TCP three-way handshake with other consensus nodes or relay nodes based on the TCP protocol.

[0110] It should be noted that full connectivity can be established between the relay nodes in the target zone; that is, any relay node in the target zone can establish network connections with each of the other relay nodes.

[0111] For example, in practical applications, if a network device meets the conditions to become a relay node, in addition to establishing a network connection with the consensus node in the consensus sub-network, it can also establish network connections with the network addresses of other relay nodes in the target zone.

[0112] It should be noted that when the number of ordinary nodes that have established network connections with a relay node reaches a certain number, it may cause bandwidth pressure on the relay node when forwarding data to various ordinary nodes. Therefore, in practical applications, a cluster topology with each relay node as the cluster head can be introduced to limit the number of ordinary nodes that have established network connections with the relay node.

[0113] For example, in one embodiment shown, a threshold can be set for each relay node to allow ordinary nodes to establish network connections with it. For instance, this threshold could still be M as described above. In this case, when a network device, acting as an ordinary node, establishes a network connection with any of the M relay nodes in the target zone, if the number of ordinary nodes maintaining network connections with that target relay node reaches M, the target relay node can refuse to establish a network connection with the network device and select a target ordinary node from among the ordinary nodes with which it has established network connections, then send the network address of that target ordinary node to the network device. After obtaining the network address of the target ordinary node, the network device can then choose not to directly establish a network connection with that target relay node, but instead, as a child node of the target ordinary node with which it has already established a network connection, establish a network connection with the network address of that target ordinary node.

[0114] The specific method by which the target relay node selects the target ordinary node from the ordinary nodes with which it has established a network connection is not specifically limited in this specification; for example, it can be selected randomly, or an ordinary node that is geographically closer to the network device can be selected.

[0115] In one embodiment shown, after the network device establishes a network connection with N consensus nodes in the consensus subnetwork as a relay node, it can also periodically broadcast the aforementioned Relayer message in the target zone. The message content of the Relayer message includes the node information of the network device as a relay node. Correspondingly, the network device, as a relay node, can also receive Relayer messages periodically broadcast by other relay nodes in the target zone, read the node information of other relay nodes contained in the message content of the received Relayer message, and add the read node information to the locally maintained node information set corresponding to the relay nodes in the target zone.

[0116] In one embodiment, after registering with the target zone, the network device can further identify neighboring zones corresponding to the target zone from among the various zones in the blockchain network. For example, in implementation, other zones with relatively close geographical proximity can be identified as neighboring zones corresponding to the target zone. Then, a network connection can be established with at least some of the relay nodes in the identified neighboring zones. Specifically, this network connection can be used for data synchronization with neighboring zones.

[0117] In this scenario, when a large-scale failure of non-consensus nodes in the target zone renders the entire target zone unavailable, the network device can activate a network connection with relay nodes in neighboring zones to synchronize data from those neighboring zones. Conversely, if the unavailability of non-consensus nodes in the target zone is not due to a large-scale failure, this network connection can be used solely for exchanging keep-alive messages with relay nodes in neighboring zones to maintain its availability.

[0118] In one embodiment shown, if a network device establishes a network connection with a consensus node in a consensus subnetwork as a relay node, it can subsequently receive consensus data sent by the consensus node through the network connection with the consensus node in the consensus subnetwork, and then forward the consensus data to the ordinary nodes through the network connection with the ordinary nodes connected to it. In this way, ordinary nodes no longer need to establish a network connection with the consensus node to receive data from the consensus node, thereby alleviating the bandwidth pressure on the consensus node.

[0119] In addition, ordinary nodes that have established a network connection with the network device can also send transactions that require consensus to the network device through the network connection between them. After receiving the transaction sent by the ordinary node through the network connection, the network device can further submit the transaction to the consensus nodes in the consensus subnetwork for consensus processing through the network connection between it and the consensus nodes in the consensus subnetwork.

[0120] In another embodiment shown, if the network device, acting as a regular node, establishes a network connection with a relay node in the target zone, a client corresponding to that regular node can subsequently submit a transaction awaiting consensus to the network device. Upon receiving the transaction from the client, the network device can then forward the transaction to the relay node via its network connection with the relay node in the target zone. The relay node, in turn, will then submit the transaction to the consensus node for further consensus processing via its network connection with the consensus node in the consensus subnetwork.

[0121] It should be noted that the aforementioned client can specifically be a light node that has established a network connection with the aforementioned ordinary nodes. Correspondingly, the non-consensus nodes (including relay nodes and ordinary nodes) in each zone of the aforementioned blockchain network can be full nodes that do not participate in consensus.

[0122] Please see Figure 3 , Figure 3This is a flowchart illustrating a consensus data distribution method in a blockchain network according to an exemplary embodiment of this specification; wherein, the blockchain network may still employ... Figure 1 The network framework shown includes: a consensus subnetwork comprising multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional subnetwork; a non-consensus node in the regional subnetwork comprising at least one relay node; and at least one ordinary node having established a network connection with the relay node; full connectivity being established between the relay nodes in the regional subnetwork; and the multiple consensus nodes having established network connections with at least one relay node in each regional subnetwork; the method can be applied to any target consensus node among the multiple consensus nodes, and the method includes: Step 302: Determine the target data fragment to be distributed to the target consensus node from a specified number of data fragments obtained by segmenting the consensus data based on the erasure coding algorithm; The aforementioned consensus nodes can be pre-designated from the consensus subnetwork, used to distribute data fragments corresponding to the consensus data to non-consensus nodes in each zone. Correspondingly, each consensus node can establish a network connection with at least one relay node in each zone to ensure that each consensus node can successfully send the data fragments it is responsible for distributing to the relay node with which it has a network connection. Relay nodes in each zone can establish full connections with each other. When a data fragment is received from any consensus node, it can be further propagated to other relay nodes through these full connections.

[0123] It should be noted that the aforementioned consensus nodes may include all consensus nodes in the aforementioned consensus subnetwork, or only some consensus nodes in the aforementioned consensus subnetwork; this specification does not impose any specific limitations. That is, in practical applications, all consensus nodes in the aforementioned consensus subnetwork may participate in distributing the data shards corresponding to the consensus data, or only some consensus nodes in the aforementioned consensus subnetwork may participate in distributing the data shards corresponding to the consensus data.

[0124] In cases where only some consensus nodes participate in distributing the data shards corresponding to the consensus data, the other consensus nodes, besides those nodes, may not participate in the distribution of the consensus data or may still be responsible for distributing the complete consensus data to the relay nodes.

[0125] In this specification, consensus data that has been agreed upon by the consensus nodes in the consensus subnetwork can be pre-divided into a specified number of data fragments based on erasure coding algorithms.

[0126] In one embodiment shown, when segmenting consensus data based on erasure coding algorithm, the segmentation can be carried out autonomously by each consensus node in the consensus sub-network.

[0127] In this scenario, the aforementioned consensus nodes can obtain consensus data agreed upon by the consensus nodes in the consensus subnetwork, and then divide the obtained consensus data into a specified number of data fragments based on a supported erasure coding algorithm. It should be noted that when each consensus node autonomously divides the consensus data, the erasure coding algorithm used by each consensus node in dividing the consensus data must remain the same.

[0128] Of course, in practical applications, in addition to the consensus data being divided autonomously by each consensus node based on the same erasure coding algorithm, the above consensus data can also be divided uniformly by the blockchain service platform (such as a BaaS platform) corresponding to the above blockchain network, or a consensus node can be designated from among the consensus nodes to be responsible for the unified division. No special limitations are made in this specification.

[0129] The specific number of data fragments obtained by dividing the consensus data using erasure coding algorithms is typically determined based on the total number of consensus nodes participating in the distribution of these fragments. Accordingly, each of these consensus nodes can be responsible for distributing a portion of the data fragments from the total number of data fragments. The target consensus node can determine the target data fragment it is responsible for distributing from the specified number of data fragments.

[0130] It should be noted that the specific distribution strategy adopted by each consensus node among the above-mentioned consensus nodes when distributing the various data fragments can be flexibly formulated based on actual needs in practical applications, and is not specifically limited in this specification.

[0131] In one embodiment shown, the number of data fragments obtained by dividing the consensus data can be the same as the total number of the aforementioned consensus nodes participating in the distribution of the data fragments.

[0132] For example, in one instance, the number of consensus nodes in the aforementioned consensus subnetwork is 3f+1, where f represents the number of fault-tolerant nodes in the blockchain network. In this case, the consensus data passed by the consensus subnetwork can be encoded using erasure coding algorithms. Copies, and redundancy There are 3f+1 data shards in total.

[0133] If the number of data shards obtained by dividing the consensus data is the same as the total number of consensus nodes participating in distributing the data shards, then each of the aforementioned consensus nodes can be responsible for distributing one of the data shards.

[0134] For example, each node in the consensus subnetwork will be responsible for distributing one of the 3f+1 data shards mentioned above.

[0135] In this scenario, the aforementioned distribution strategy could specifically involve each of the multiple consensus nodes being responsible for distributing data shards whose data shard identifiers match their own node identifiers. For each data shard, a unified encoding can be performed based on the total number of consensus nodes to obtain a data shard identifier (e.g., a data shard number) corresponding to each data shard.

[0136] When the aforementioned target consensus node determines the target data fragment to be distributed from the specified number of data fragments that have been divided, it can specifically match its own node identifier (such as a node number) with the data fragment identifiers of each data fragment; then, the data fragment corresponding to the data fragment identifier that matches its own node identifier is determined as the target data fragment to be distributed by the target consensus node.

[0137] In this way, each of the aforementioned consensus nodes can be responsible for distributing one of the data shards whose data shard identifier matches its own node identifier.

[0138] For example, in one case, taking the above data shard identifier as the data shard number and the above node identifier as the node number, assuming there are a total of N consensus nodes responsible for distributing data shards, and the above consensus data is divided into N data shards, in this case, the consensus node with node number N can be responsible for distributing the data shard with the same data shard number N.

[0139] Of course, in practical applications, besides having each of the aforementioned consensus nodes responsible for distributing one of the data shards, the number of data shards obtained from dividing the consensus data can also be different from the total number of consensus nodes participating in the data shard distribution. In this case, the number of data shards each of the aforementioned consensus nodes is responsible for distributing can also be different; for example, some consensus nodes can be responsible for distributing multiple data shards, while other consensus nodes can be responsible for distributing only one data shard.

[0140] In one embodiment shown, besides the specific number of data fragments obtained by dividing the consensus data, which can be the same as the total number of consensus nodes responsible for distributing data fragments in the aforementioned consensus sub-network, in practical applications, the total number of relay nodes in each zone can also be the same as the total number of consensus nodes. For example, during the network deployment phase, the number of relay nodes in each zone can be planned based on the number of consensus nodes participating in the distribution of data fragments.

[0141] In this scenario, each relay node in a zone can correspond one-to-one with a consensus node in the consensus subnetwork. That is, each consensus node in the consensus subnetwork can establish a network connection with a corresponding relay node in each zone. In this way, each consensus node can distribute the data fragments it is responsible for distributing to its one-to-one corresponding relay node via the established network connection.

[0142] Accordingly, as mentioned earlier, if the total number of relay nodes in each zone is the same as the total number of consensus nodes in the consensus subnetwork, and if the relay nodes in each zone subnetwork correspond one-to-one with the consensus nodes in the consensus subnetwork, then each consensus node will only be responsible for distributing one of the data fragments among all the data fragments and sending that data fragment one-to-one to its corresponding relay node.

[0143] In this scenario, to ensure that each ordinary node can collect enough data fragments to recover the consensus data, any ordinary node in each zone can establish network connections with at least N relay nodes in its zone; where N is the data recovery threshold corresponding to the erasure coding algorithm. This allows each ordinary node to receive at least N data fragments sufficient to recover the consensus data through these at least N network connections.

[0144] For example, taking the consensus data encoded into 3f+1 data fragments based on erasure coding as an example, in this case, 2f+1 data fragments need to be collected to successfully recover the original consensus data based on erasure coding. Therefore, each ordinary node in each zone can establish network connections with at least 2f+1 relay nodes in its zone to ensure that at least 2f+1 data fragments can be collected through these network connections.

[0145] In one embodiment shown, to further enhance the robustness of relay nodes in each zone, each relay node in each zone can establish a full connection with each consensus node in the aforementioned consensus subnetwork. That is, each relay node needs to establish a network connection with its corresponding consensus node, and can also establish network connections with each of the other relay nodes.

[0146] In this way, if the network connection between each relay node and its corresponding consensus node fails, or if the consensus node corresponding to that relay node goes down, data fragments can still be received through network connections between other relay nodes. It should be noted that if each relay node in each zone establishes a full connection with each consensus node in the aforementioned consensus subnetwork, the network connection between each consensus node and its corresponding relay node can be used to transmit data fragments distributed by that consensus node by default. The network connection between each consensus node and other relay nodes besides its corresponding relay node can, by default, be used to transmit heartbeat messages to maintain network connectivity.

[0147] Step 304: The target data fragments are unicast to the target relay nodes in each regional sub-network of the blockchain network that have established network connections with the target consensus node. This allows the target relay nodes to continue broadcasting the target data fragments to other relay nodes and ordinary nodes in their respective regional sub-networks that have established network connections with them. The other relay nodes and ordinary nodes then perform data recovery on the received data fragments corresponding to the consensus data.

[0148] In one embodiment shown, the message types supported by the blockchain network for interaction between nodes may also include the messages shown below: The Subscribe message (referred to as the fifth message) is used to subscribe to data shards from the message receiving node.

[0149] In this scenario, relay nodes in each zone can subscribe to the data shards distributed by a consensus node by sending a Subscribe message to that consensus node in the consensus subnetwork. Upon receiving the Subscribe message from the relay node, the consensus node can respond by establishing a subscription relationship between the relay node and the data shards distributed by that consensus node.

[0150] For example, as mentioned earlier, if the total number of consensus nodes in the consensus subnetwork is the same as the total number of relay nodes in each zone, and each relay node in each zone corresponds one-to-one with each consensus node in the consensus subnetwork, then in this case, each relay node in each zone can send a Subscribe message to its corresponding consensus node in the consensus subnetwork to subscribe to the data shards that the consensus node is responsible for distributing.

[0151] It should be noted that during the networking phase of a blockchain network, the timing of relay nodes joining their respective zones usually follows a certain order. Therefore, for the first relay node to join a zone, it is the only relay node in that zone. This relay node can then subscribe to all data shards distributed by the consensus nodes in the consensus subnetwork by default. When a new relay node joins later, it can select some data shards to subscribe to through load balancing from the data shards subscribed by the already joined relay nodes.

[0152] For example, in one embodiment shown, when a network device performs... Figure 2 The network formation process shown is as follows: when a target relay node in any target zone successfully joins the target zone, the target relay node can respond to the event of successfully joining the target zone and further determine whether there are other relay nodes in the target zone. If it does not exist, it indicates that the target relay node is the only relay node in the target zone. In this case, Subscribe messages can be sent to each of the consensus nodes responsible for distributing data shards in the above consensus subnetwork to subscribe to the data shards distributed by each consensus node.

[0153] If it does not exist, it indicates that the target relay node is not the only relay node in the target zone. In this case, the target relay node can obtain the data shard identifiers of the data shards subscribed to by other relay nodes to clarify the data shards already subscribed to by other relay nodes. Then, it can determine the relay node with the largest number of data shards subscribed to by other relay nodes, randomly select at least one data shard from the data shards subscribed to by that relay node, and send a Subscribe message to at least one consensus node responsible for distributing the at least one data shard to subscribe to the at least one data shard distributed by the at least one consensus node.

[0154] Specifically, when the target relay node obtains the data shard identifier of the data shard subscribed by other relay nodes, it can do so by exchanging messages with other relay nodes.

[0155] For example, in one embodiment shown, the message types supported by the blockchain network for interaction between nodes may also include messages as shown below: The get-relay-stripe message (referred to as the sixth message) is used to query the data shards subscribed to by the message receiving node; The relay-stripe (referred to as the seventh message) is used to return the data fragment identifiers of the data fragments subscribed to by the message receiving node to the message sending node of the get-relay-stripe message. The message content of this relay-stripe may include data fragment identifiers of data fragments subscribed to by other relay nodes.

[0156] In this scenario, when the target relay node obtains the data fragment identifiers of the data fragments subscribed to by other relay nodes, it can send a `get-relay-stripe` message to each of the other relay nodes. Upon receiving the `get-relay-stripe` message from the target relay node, the other relay nodes can return a `relay-stripe` message to the target relay node. The target relay node, upon receiving the `relay-stripe` message returned by the other relay nodes, can read the data fragment identifiers of the data fragments subscribed to by the other relay nodes, which are contained within the message content of the `relay-stripe` message.

[0157] In this specification, in addition to relay nodes being able to subscribe to data shards distributed by consensus nodes by sending Subscribe messages, ordinary nodes that have established a network connection with relay nodes can also subscribe to data shards forwarded by relay nodes by sending Subscribe messages.

[0158] For example, in one embodiment shown, after the target relay node subscribes to the data shard distributed by the consensus node, if it receives a Subscribe message from a regular node with which it has established a network connection, it can also respond to the Subscribe message to establish a subscription relationship between the regular node and the target data shard forwarded by the target relay node.

[0159] In one embodiment, as described above, when the target relay node receives an instruction to leave its regional subnetwork, it can respond to the instruction by identifying a target ordinary node as a candidate relay node from among the ordinary nodes that have established network links with the relay node, and sending a Leave message to the target ordinary node. This triggers the target ordinary node to replace the target relay node as a new relay node, and establish network links with the consensus node that has already established a network link with the target relay node, as well as with the other ordinary nodes that have already established a network link with the target relay node. In this case, after the target ordinary node replaces the target relay node as a new relay node, it can also send a Subscribe message to the target consensus node that has established a network link with the target relay node. This causes the target consensus node to respond to the Subscribe message and establish a subscription relationship between the new relay node and the target data shard to be distributed by the target consensus node, thus completely replacing the target relay node.

[0160] In this specification, after the target consensus node determines the target data fragment to be distributed from the segmented data fragments, it can unicast the target data fragment to the target relay nodes that have established network connections with the target consensus node in each zone network.

[0161] It should be noted that in practical applications, among the relay nodes that have established network connections with the target consensus node, there may be relay nodes that have not subscribed to the target data fragment. Therefore, when the target consensus node unicasts the target data fragment to the relay nodes that have established network connections with it in each zone network, it can identify the target relay node that has subscribed to the target data fragment based on the locally maintained subscription relationship. Then, it can unicast the target data fragment to the target relay nodes that have established network connections with the target consensus node and have subscribed to the target data fragment in each regional subnetwork.

[0162] After receiving the target data fragment unicast by the target consensus node, the target relay node can continue to broadcast the target data fragment in its own zone, thus forwarding the original consensus data to the ordinary nodes that have established a network connection with it.

[0163] In one embodiment shown, the target relay node can continue to broadcast the target data fragments to other relay nodes and ordinary nodes in its target zone that have established network connections with the target relay node. The other relay nodes and ordinary nodes in the target zone 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 to obtain the original consensus data.

[0164] For example, if the consensus data is encoded into 3f+1 data fragments based on the erasure coding algorithm, then the other relay nodes and ordinary nodes can collect 2f+1 data fragments and successfully recover the original consensus data. The implementation details of data recovery based on the erasure coding algorithm for the collected data fragments will not be elaborated in this specification.

[0165] In one embodiment shown, the aforementioned ordinary nodes may not participate in the data recovery of consensus data. In this case, the target relay node may simply broadcast the target data fragment to all other relay nodes in its target zone that have established network connections with it. The target relay node and the other relay nodes can then collect the data fragments corresponding to the original consensus data and perform data recovery on the received data fragments. Once the original consensus data is recovered, the target relay node and the other relay nodes can further forward the recovered consensus data to the ordinary nodes with which they have established network connections.

[0166] Please see Figure 4 , Figure 4 This is a flowchart illustrating, according to an exemplary embodiment, another consensus data distribution method in a blockchain network; wherein, the blockchain network can still employ... Figure 1 The network framework shown includes: a consensus subnetwork comprising multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional subnetwork; a non-consensus node in the regional subnetwork comprising at least one relay node; and at least one ordinary node having established a network connection with the relay node; a full connection being established between the relay nodes in the regional subnetwork; and the multiple consensus nodes respectively establishing network connections with at least one relay node in each regional subnetwork; the method can be applied to any target relay node in any target regional subnetwork, and the method includes: Step 402: Receive the target data fragment unicast by the target consensus node in the consensus sub-network that has established a network connection with the target relay node; wherein, the target data fragment is the data fragment to be distributed corresponding to the target consensus node among a specified number of data fragments obtained by dividing the consensus data based on the erasure coding algorithm; Step 404: Continue to broadcast the target data fragments to other relay nodes and ordinary nodes in the target area sub-network that have established network connections with the target relay node, so that the other relay nodes and ordinary nodes can perform data recovery on the received data fragments corresponding to the consensus data.

[0167] exist Figure 4 The illustrated embodiment is described from the perspective of the relay node. Figure 3 The consensus data distribution method is shown. It's not difficult to understand regarding... Figure 4 The implementation details of the consensus data distribution method shown can be found in [reference]. Figure 3 The implementation details related to the consensus data distribution method shown will not be repeated in this embodiment.

[0168] The following example illustrates each of the above embodiments.

[0169] Please see Figure 5 , Figure 5 This is a schematic diagram illustrating a consensus data distribution based on a blockchain network, as shown in this specification.

[0170] exist Figure 5 The illustrated blockchain network comprises two zones, denoted as zone1 and zone2. The consensus subnetwork contains four consensus nodes (3f+1 in total, where f is 1), denoted as consensus node 1-4. Consensus data agreed upon by the consensus nodes in the consensus subnetwork is encoded into four data shards, each called a stripe, denoted as stripe1-4.

[0171] According to the plan, Figure 5 Zone 1 and Zone 2 will each contain 4 relay nodes, and all relay nodes will maintain full connectivity. For example, Figure 5 As shown, the four relay nodes in zone 1 are denoted as relay nodes 5-8; zone 2 is planned to have four relay nodes, but only three relay nodes have been added so far, denoted as relay nodes 10-12.

[0172] Each consensus node in the consensus sub-network is responsible for sending the stripe whose number in stripe1-4 matches its own number. For example, ... Figure 5As shown, 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.

[0173] Each of the four consensus nodes unicasts its assigned stripe to the relay nodes that have subscribed to that stripe; for example, ... Figure 5 As shown, consensus node 1 unicasts stripe1 to relay node 5 in zone 1 and relay node 10 in zone 2 respectively; consensus node 2 unicasts stripe2 to relay node 6 in zone 1 and relay node 12 in zone 2 respectively; consensus node 3 unicasts stripe3 to relay node 7 in zone 1 and relay node 11 in zone 2 respectively; and consensus node 4 unicasts stripe4 to relay node 8 in zone 1 and relay node 12 in zone 2 respectively.

[0174] After receiving the stripe, the relay nodes in zone1 and zone2 can broadcast the received stripe to other relay nodes in the zone based on the full connectivity between the relay nodes. In the end, each relay node can receive all 4 stripes, and any 3 stripes (i.e., 2f+1) can correctly restore the complete consensus data. The extra stripe is used as a backup. If one relay node fails, the other relay nodes can also restore the complete consensus data normally.

[0175] When node 9 in Zone 1 enters the network, since there are already enough relay nodes in Zone 1, node 9 can establish network connections with relay nodes 5-8 as a regular node. As a child node of relay nodes 5-8, node 9 only needs to receive stripes forwarded by any three relay nodes to correctly recover the complete consensus data. Establishing network connections with four relay nodes (5-8, etc.) simultaneously increases the robustness of its network connections. For example, if one of the relay nodes 5-8 fails, node 9 can still receive three stripes and correctly recover the complete consensus data.

[0176] Since there are only 3 relay nodes in zone 2, one of the relay nodes will receive an extra stripe. For example, Figure 5 Relay node 12 in the middle simultaneously receives stripe2 and stripe4, which are distributed by consensus nodes 2 and 4.

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

[0178] First, after relay node 13 successfully joins zone 2, it discovers that relay node 12 has the most subscribed stripes, namely stripe2 and stripe4. Relay node 13 can load balance the stripes subscribed to by relay node 12, randomly selecting half of the stripes, for example, stripe2. Then, it can send a subscribe message to consensus node 2 to subscribe to stripe2. Subsequently, consensus node 2 can unicast stripe2 to relay node 13.

[0179] Subsequently, when a new node joins the network in Zone 2, it can establish network connections with relay nodes 10-13 as a regular node and act as a child node of relay nodes 10-13. As long as the new node receives stripes forwarded by any 3 relay nodes, it can correctly recover the complete consensus data.

[0180] Corresponding to the embodiments of the aforementioned methods, this specification also provides embodiments of blockchain networks, node devices, and storage media.

[0181] This specification also provides an embodiment of a blockchain network, which may include a consensus subnetwork composed of multiple consensus nodes; and at least one regional subnetwork corresponding to different geographical locations. The aforementioned consensus subnetwork may include multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional subnetwork; the non-consensus nodes in the regional subnetwork include at least one relay node; and at least one ordinary node that has established a network connection with the relay node; and full connectivity is established between the relay nodes in the regional subnetwork.

[0182] Among them, any target consensus node among the plurality of consensus nodes determines the 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 the erasure coding algorithm; and unicasts the target data fragments to the target relay nodes that have established network connections with the target consensus node in each regional sub-network of the blockchain network. The target relay node receives the target data fragment unicast by the target consensus node, and continues to broadcast the target data fragment to other relay nodes and ordinary nodes in the target area subnetwork that have established network connections with the target relay node, so that the other relay nodes and ordinary nodes can perform data recovery on the received data fragments corresponding to the consensus data.

[0183] It should be noted that the implementation details of the above embodiments can be referred to as follows: Figure 2-5 The embodiments shown will not be described in detail in this embodiment.

[0184] Figure 6 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Please refer to... Figure 6 At the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, memory 608, and non-volatile memory 610, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 602 reading the corresponding computer program from the non-volatile memory 710 into memory 608 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic module, but can also be hardware or logic devices.

[0185] like Figure 7 As shown, Figure 7 This specification is a block diagram illustrating a node device in a blockchain network according to an exemplary embodiment. The node device 70 can be applied to, for example... Figure 6 The illustrated electronic device implements the technical solution of this specification. The blockchain network includes a consensus sub-network and at least one regional sub-network corresponding to different geographical locations; the consensus sub-network includes multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional sub-networks; the non-consensus nodes in the regional sub-networks include at least one relay node; and at least one ordinary node has established a network connection with the relay node; wherein, full connectivity is established between the relay nodes in the regional sub-networks; the multiple consensus nodes have established network connections with at least one relay node in each regional sub-network; the node device 70 includes: The determining module 701 determines the target data fragment to be distributed to the target consensus node from a specified number of data fragments obtained by segmenting the consensus data based on the erasure coding algorithm; The distribution module 702 unicasts the target data fragments to target relay nodes in each regional subnetwork of the blockchain network that have established network connections with the target consensus node. This allows the target relay nodes to continue broadcasting the target data fragments to other relay nodes and ordinary nodes in their respective regional subnetworks that have established network connections with them. The other relay nodes and ordinary nodes then perform data recovery on the received data fragments corresponding to the consensus data.

[0186] The specific details of each module of the aforementioned device 70 have been described in detail in the previously described method flow, so they will not be repeated here.

[0187] like Figure 8 As shown, Figure 8 This is a block diagram of a node device in another blockchain network illustrated in this specification according to an exemplary embodiment. The node device 80 can also be applied to, for example... Figure 6 The illustrated electronic device implements the technical solution of this specification. The blockchain network includes a consensus sub-network and at least one regional sub-network corresponding to different geographical locations; the consensus sub-network includes multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional sub-networks; the non-consensus nodes in the regional sub-networks include at least one relay node; and at least one ordinary node has established a network connection with the relay node; wherein, full connectivity is established between the relay nodes in the regional sub-networks; the multiple consensus nodes have established network connections with at least one relay node in each regional sub-network; the node device 80 includes: The receiving module 801 receives a target data fragment unicast from a target consensus node that has established a network connection with the target relay node in the consensus sub-network; wherein the target data fragment is a data fragment to be distributed corresponding to the target consensus node from a specified number of data fragments obtained by dividing the consensus data based on the erasure coding algorithm. The forwarding module 802 continues to broadcast the target data fragments to other relay nodes and ordinary nodes in the target area subnetwork that have established network connections with the target relay node, so that the other relay nodes and ordinary nodes can perform data recovery on the received data fragments corresponding to the consensus data.

[0188] The specific details of each module of the aforementioned device 60 have been described in detail in the previously described method flow, so they will not be repeated here.

[0189] Accordingly, this specification also provides an electronic device including a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement all the steps in the previously described method flow.

[0190] Accordingly, this specification also provides a computer-readable storage medium having executable instructions stored thereon; wherein, when executed by a processor, the instructions implement all the steps in the previously described method flow.

[0191] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0192] The systems, devices, modules, or components described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

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

[0194] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0195] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

[0197] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0198] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0199] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0200] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A consensus data distribution method in a blockchain network, the blockchain network including a consensus sub-network and at least one regional sub-network corresponding to different geographical locations; the consensus sub-network including multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional sub-network; the non-consensus nodes in the regional sub-network including at least one relay node; and at least one ordinary node that has established a network connection with the relay node; wherein, Full connectivity is established between all relay nodes in the regional subnetwork; the multiple consensus nodes establish network connections with at least one relay node in each regional subnetwork; each relay node in the regional subnetwork subscribes to a data shard to be distributed by at least one of the multiple consensus nodes. The method is applied to any target consensus node among the plurality of consensus nodes; including: From a specified number of data fragments obtained by segmenting the consensus data based on erasure coding algorithm, the target data fragment to be distributed to the target consensus node is determined; wherein, the specified number is the total number of the plurality of consensus nodes; The target data fragments are unicast to various regional sub-networks in the blockchain network, establishing network connections with the target consensus node. The target relay nodes subscribe to the target data fragments, enabling them to broadcast the target data fragments to other relay nodes and ordinary nodes in their respective regional sub-networks. These other relay nodes and ordinary nodes then perform data recovery on the received data fragments corresponding to the consensus data.

2. The method as described in claim 1, before determining the target data fragment to be distributed to the target consensus node from a specified number of data fragments obtained by segmenting the consensus data based on erasure coding algorithm, further comprising: Obtain consensus data that has been agreed upon by the consensus nodes in the consensus sub-network; The consensus data is divided into a specified number of data fragments based on the erasure coding algorithm; wherein the erasure coding algorithm used by the multiple consensus nodes when dividing the consensus data is the same.

3. The method as described in claim 2, Determining the target data shard to be distributed from the specified number of data shards, corresponding to the target consensus node, includes: The node identifier of the target consensus node is matched with the data shard identifier of the specified number of data shards; wherein, the data shard identifier is an identifier obtained by uniformly encoding each of the divided data shards based on the total number of the multiple consensus nodes; Multiple consensus nodes identify the data fragments whose data fragment identifiers match the node identifier of the target consensus node as the target data fragments to be distributed by the target consensus node.

4. The method as described in claim 1, wherein the total number of relay nodes in the regional sub-network is the same as the total number of the plurality of consensus nodes; and, the relay nodes in the regional sub-network correspond one-to-one with the plurality of consensus nodes; accordingly, each relay node in the regional sub-network subscribes to the data shards to be distributed by the consensus node corresponding to it among the plurality of consensus nodes.

5. The method as described in claim 4, wherein if the total number of relay nodes in the regional sub-network is the same as the total number of the plurality of consensus nodes; and the relay nodes in the regional sub-network correspond one-to-one with the plurality of consensus nodes, then any ordinary node in the regional sub-network has established a network connection with at least N relay nodes in the regional sub-network; wherein, The value of N is the data recovery threshold corresponding to the erasure coding algorithm.

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

7. The method as described in claim 4, wherein each relay node in the regional sub-network has established a full connection with the plurality of consensus nodes; wherein, The network connection between the multiple consensus nodes and their corresponding relay nodes is used to transmit the data fragments to be distributed by the consensus node; the network connection between the multiple consensus nodes and other relay nodes besides their corresponding relay nodes is used to transmit heartbeat messages to maintain network connectivity.

8. The method of claim 1, wherein the blockchain comprises a consortium blockchain.

9. A consensus data distribution method in a blockchain network, the blockchain network including a consensus sub-network and at least one regional sub-network corresponding to different geographical locations; the consensus sub-network including multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional sub-network; the non-consensus nodes in the regional sub-network including at least one relay node; and at least one ordinary node that has established a network connection with the relay node; wherein, Full connectivity is established between all relay nodes in the regional subnetwork; the multiple consensus nodes establish network connections with at least one relay node in each regional subnetwork; each relay node in the regional subnetwork subscribes to a data shard to be distributed by at least one of the multiple consensus nodes. The method is applied to any target relay node in any target area sub-network; including: The system receives a target data fragment unicast from a target consensus node that has established a network connection with the target relay node in the consensus subnetwork; wherein the target relay node has subscribed to the target data fragment; the target data fragment is a data fragment to be distributed corresponding to the target consensus node from a specified number of data fragments obtained by dividing the consensus data based on the erasure coding algorithm; the specified number is the total number of the multiple consensus nodes; The target data fragments are then broadcast to other relay nodes and ordinary nodes in the target area subnetwork that have established network connections with the target relay node, so that the other relay nodes and ordinary nodes can recover the data fragments corresponding to the consensus data.

10. The method as described in claim 9, comprising multiple consensus nodes; the target data shard is a data shard corresponding to a data shard identifier that matches the node identifier of the target consensus node; wherein, The data shard identifier is an identifier obtained by uniformly encoding the specified number of data shards based on the total number of consensus nodes.

11. The method of claim 9, wherein the total number of relay nodes in the regional sub-network is the same as the total number of the plurality of consensus nodes; and the relay nodes in the regional sub-network correspond one-to-one with the plurality of consensus nodes; accordingly, each relay node in the regional sub-network subscribes to the data shards to be distributed by the consensus node corresponding to it among the plurality of consensus nodes.

12. The method of claim 11, wherein if the total number of relay nodes in the regional sub-network is the same as the total number of the plurality of consensus nodes; and the relay nodes in the regional sub-network correspond one-to-one with the plurality of consensus nodes, then any ordinary node in the regional sub-network has established a network connection with at least N relay nodes in the regional sub-network; wherein, The value of N is the data recovery threshold corresponding to the erasure coding algorithm.

13. The method as described in claim 12, wherein the number of the plurality of consensus nodes is 3f+1; the value of N is not less than 2f+1; and f is the number of fault-tolerant nodes in the blockchain network.

14. The method as described in claim 11, wherein each relay node in the regional sub-network has established a full connection with the plurality of consensus nodes; wherein, The network connection between the multiple consensus nodes and their corresponding relay nodes is used to transmit the data fragments to be distributed by the consensus node; the network connection between the multiple consensus nodes and other relay nodes besides their corresponding relay nodes is used to transmit heartbeat messages to maintain network connectivity.

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

16. The method of claim 9, wherein the messages exchanged between nodes in the blockchain network further include a fifth message for subscribing to data shards from the message receiving node; The method further includes: In response to successfully joining the target area sub-network, determine whether the target area sub-network still includes other relay nodes; If so, obtain the data fragment identifier of the data fragment subscribed by the other relay nodes, determine the relay node with the largest number of data fragments subscribed by the other relay nodes, and randomly select at least one data fragment from the data fragments subscribed by that relay node. And, send the fifth message to at least one consensus node responsible for distributing the at least one data shard, so that the at least one consensus node responds to the fifth message and establishes a subscription relationship between the target relay node and the at least one data shard to be distributed by the at least one consensus node; If not, the fifth message is sent to each of the plurality of consensus nodes, so that each of the plurality of consensus nodes responds to the fifth message and establishes a subscription relationship between the target relay node and the data shards to be distributed by each consensus node.

17. The method of claim 16, further comprising: Receive the fifth message sent by a regular node that has established a network connection with the target relay node; In response to the fifth message, a subscription relationship is established between the ordinary node and the target data fragment that the target relay node is responsible for distributing; The target data is fragmented and broadcast to ordinary nodes in the target area subnetwork that have established network connections with the target relay node, including: The target data fragment is broadcast to the target area subnetwork, a network connection is established with the target relay node, and the ordinary node subscribes to the target data fragment.

18. The method of claim 17, wherein the messages exchanged between the nodes in the blockchain network further include a sixth message for querying the data shards subscribed to by the message receiving node; and a seventh message for returning the data shard identifier of the data shard subscribed to by the message receiving node to the message sending node of the fifth message; Obtain the data fragment identifier of the data fragment subscribed by the other relay nodes, including: Send the sixth message to the other relay nodes; Receive the seventh message returned by the other relay nodes, and read the data fragment identifier of the data fragment subscribed by the other relay nodes contained in the message content of the seventh message.

19. The method of claim 16, wherein the messages exchanged between the nodes in the blockchain network further include a fourth message declaring that the message-sending node has withdrawn from its regional subnetwork as a relay node; The method further includes: In response to the instruction to exit the target area subnetwork, a target ordinary node is determined from the ordinary nodes that have established network links with the target relay node as a candidate relay node, and the fourth message is sent to the target ordinary node to trigger the target ordinary node to act as a new relay node, establish a network connection with the target consensus node, and establish network connections with other ordinary nodes that have already established network connections with the target relay node; and the fifth message is sent 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 shard to be distributed by the target consensus node.

20. The method of claim 19, wherein determining a target ordinary node as a candidate relay node from ordinary nodes that have established a network link with the target relay node comprises: Based on the time when each ordinary node that has established a network link with the target relay node joins the target area sub-network, the ordinary node that joined the target area sub-network earliest is determined, and this ordinary node is identified as the target ordinary node as a candidate relay node.

21. The method of claim 9, wherein the blockchain comprises a consortium blockchain.

22. A blockchain network, comprising: A consensus subnetwork, and at least one regional subnetwork corresponding to different geographical locations; The consensus subnetwork includes multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional subnetwork; the non-consensus nodes in the regional subnetwork include at least one relay node; and at least one ordinary node that has established a network connection with the relay node; full connections are established between the relay nodes in the regional subnetwork; the multiple consensus nodes have respectively established network connections with at least one relay node in each regional subnetwork; and each relay node in the regional subnetwork has subscribed to the data shards to be distributed by at least one of the multiple consensus nodes. In this process, any target consensus node among the plurality of consensus nodes determines the target data fragment to be distributed from a specified number of data fragments obtained by dividing the consensus data based on the erasure coding algorithm; the target data fragment is unicast to each regional subnetwork in the blockchain network to establish a network connection with the target consensus node, and the target relay node of the target data fragment is subscribed to; the specified number is the total number of the plurality of consensus nodes; The target relay node receives the target data fragment unicast by the target consensus node, and continues to broadcast the target data fragment to other relay nodes and ordinary nodes in the target area subnetwork that have established network connections with the target relay node, so that the other relay nodes and ordinary nodes can perform data recovery on the received data fragments corresponding to the consensus data.

23. A node device in a blockchain network, the blockchain network including a consensus subnetwork and at least one regional subnetwork corresponding to different geographical locations; the consensus subnetwork including multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional subnetworks; the non-consensus nodes in the regional subnetworks including at least one relay node; and at least one ordinary node that has established a network connection with the relay node; wherein, Full connectivity is established between all relay nodes in the regional subnetwork; the plurality of consensus nodes have established network connections with at least one relay node in each regional subnetwork; including: The determining module determines the target data fragment to be distributed to the target consensus node from a specified number of data fragments obtained by segmenting the consensus data based on the erasure coding algorithm; wherein, the specified number is the total number of the plurality of consensus nodes; The distribution module unicasts the target data fragments to each regional subnetwork in the blockchain network that has established a network connection with the target consensus node, and subscribes to the target relay node of the target data fragment. This enables the target relay node to continue broadcasting the target data fragments to other relay nodes and ordinary nodes in its regional subnetwork that have established a network connection with it. The other relay nodes and ordinary nodes then perform data recovery on the received data fragments corresponding to the consensus data.

24. A node device in a blockchain network, the blockchain network including a consensus subnetwork and at least one regional subnetwork corresponding to different geographical locations; the consensus subnetwork including multiple consensus nodes for distributing data shards corresponding to consensus data to non-consensus nodes in the regional subnetworks; the non-consensus nodes in the regional subnetworks including at least one relay node; and at least one ordinary node that has established a network connection with the relay node; wherein, Full connectivity is established between all relay nodes in the regional subnetwork; the plurality of consensus nodes establish network connections with at least one relay node in each regional subnetwork; each relay node in the regional subnetwork subscribes to a data shard to be distributed by at least one of the plurality of consensus nodes; including: The receiving module receives a target data fragment unicast from a target consensus node that has established a network connection with the target relay node in the consensus subnetwork; wherein the target relay node has subscribed to the target data fragment; the target data fragment is a data fragment to be distributed corresponding to the target consensus node from a specified number of data fragments obtained by dividing the consensus data based on the erasure coding algorithm; the specified number is the total number of the multiple consensus nodes; The forwarding module continues to broadcast the target data fragments to other relay nodes and ordinary nodes in the target area subnetwork that have established network connections with the target relay node, so that the other relay nodes and ordinary nodes can recover the data fragments corresponding to the consensus data received.

25. An electronic device, comprising a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus; The memory stores machine-readable instructions, and the processor executes the method according to any one of claims 1 to 21 by invoking the machine-readable instructions.

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

Images