A networking method of a blockchain network, a blockchain system and a network device

Abstract

A networking method of a blockchain network, comprising: determining a target regional sub-network corresponding to a geographic location where the network device is located, and initiating registration for the target regional sub-network; in response to completion of the registration for the target regional sub-network, determining whether the network device meets the condition of becoming a relay node; if yes, establishing network connections with at least N consensus nodes in the consensus sub-network respectively as a relay node; wherein the value of N is greater than the maximum fault-tolerant node number of the blockchain network; if no, establishing network connections with at least M relay nodes in the target regional sub-network respectively as a normal node; wherein M is a robustness threshold corresponding to the relay nodes in the target regional sub-network calculated in advance.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a blockchain network formation method, blockchain system and network device. 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 method for building a blockchain network, wherein the blockchain network includes a consensus subnetwork composed of multiple consensus nodes, and at least one regional subnetwork corresponding to different geographical locations; the regional subnetwork includes multiple non-consensus nodes; the multiple non-consensus nodes include at least one relay node that receives consensus data from the consensus nodes; and at least one ordinary node that receives consensus data forwarded by the relay nodes; the method is applied to any network device to join the blockchain network; including: Identify the target area sub-network corresponding to the geographical location of the network device, and initiate registration for the target area sub-network; In response to the completion of registration for the target area sub-network, it is determined whether the network device meets the conditions to become the relay node; if yes, it establishes a network connection with the consensus node in the consensus sub-network as a relay node; if no, it establishes a network connection with the relay node in the target area sub-network as a regular node.

[0004] This specification also proposes a blockchain network, comprising: a consensus subnetwork consisting of multiple consensus nodes; and at least one regional subnetwork corresponding to different geographical locations; the regional subnetwork includes multiple non-consensus nodes; the multiple non-consensus nodes include at least one relay node that receives consensus data from the consensus nodes; and at least one ordinary node that receives consensus data forwarded by the relay nodes. The network devices to be joined to the blockchain network join the blockchain network by performing the following registration process: Identify the target area sub-network corresponding to the geographical location of the network device, and initiate registration for the target area sub-network; In response to the completion of registration for the target area sub-network, it is determined whether the network device meets the conditions to become the relay node; if yes, it establishes a network connection with the consensus node in the consensus sub-network as a relay node; if no, it establishes a network connection with the relay node in the target area sub-network as a regular node.

[0005] This specification also proposes a node device in a blockchain network, wherein the blockchain network includes a consensus subnetwork composed of multiple consensus nodes, and at least one regional subnetwork corresponding to different geographical locations; the regional subnetwork includes multiple non-consensus nodes; the multiple non-consensus nodes include at least one relay node that receives consensus data from the consensus nodes; and at least one ordinary node that receives consensus data forwarded by the relay node; the method is applied to any network device to join the blockchain network; including: The registration module determines the target area sub-network corresponding to the geographical location of the network device and initiates registration for the target area sub-network; The connection module, in response to the completion of registration for the target area sub-network, determines whether the network device meets the conditions to become the relay node; if yes, it establishes a network connection with the consensus node in the consensus sub-network as a relay node; if no, it establishes a network connection with the relay node in the target area sub-network as a regular node.

[0006] In the above embodiments, on the one hand, 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 for 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 and have lower data transmission latency, nodes within the same regional subnetwork can transmit data to be consensused to the consensus node more quickly and receive consensus data distributed by the consensus node more quickly.

[0007] 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.

[0008] Thirdly, when a network device meets the conditions to become a relay node, it can establish network connections 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. Furthermore, even when a network device does not meet the conditions to become a relay node, it can still establish network connections 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. Therefore, in this way, whether the network device acts as a relay node or a regular node, the consensus nodes or relay nodes with which it has established network connections have a certain fault tolerance margin in the event of node failure, thereby improving the overall robustness of the network. 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 is a network architecture diagram of a blockchain network illustrated in this specification 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 schematic structural diagram of an electronic device according to an exemplary embodiment of this specification; Figure 4 This specification is a block diagram illustrating a node device in a blockchain network 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] In related technologies, the current blockchain networks mainly adopt the following three network topologies and networking methods when forming 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) Random 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] In view of this, this specification proposes a blockchain networking framework suitable for large-scale nodes.

[0025] Under this networking framework, the blockchain network can be divided into a consensus subnetwork consisting of multiple consensus nodes, and at least one regional subnetwork corresponding to different geographical locations. The aforementioned regional sub-network may include multiple non-consensus nodes; the aforementioned multiple non-consensus nodes may include at least one relay node that receives consensus data from a consensus node; and at least one ordinary node that receives consensus data forwarded by the relay node.

[0026] When any network device is about to join the blockchain network, it can first determine the target sub-network corresponding to the geographical location of the network device, and then initiate registration for the target sub-network.

[0027] Once registration for the target area subnetwork is complete, it can be further determined whether the network device meets the conditions to become a relay node. If so, it can act as a relay node and establish network connections with at least N consensus nodes in the consensus subnetwork, where N is greater than the maximum number of fault-tolerant nodes in the blockchain network. If not, it can act as a regular node and establish network connections with at least M relay nodes in the target area subnetwork, where M is a pre-calculated robustness threshold corresponding to the relay nodes in the target area subnetwork.

[0028] In the above embodiments, on the one hand, 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 to be reached for consensus to the consensus node more quickly, and can also receive consensus data distributed by the consensus node indicating consensus completion more quickly.

[0029] 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.

[0030] Thirdly, when a network device meets the conditions to become a relay node, it can establish network connections 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. Furthermore, even when a network device does not meet the conditions to become a relay node, it can still establish network connections 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. Therefore, in this way, whether the network device acts as a relay node or a regular node, the consensus nodes or relay nodes with which it has established network connections have a certain fault tolerance margin in the event of node failure, thereby improving the overall robustness of the network.

[0031] Please see Figure 1 , Figure 1 This is a network architecture diagram of a blockchain network illustrated in this specification according to an exemplary embodiment.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

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

[0040] 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.

[0041] 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.

[0042] When building a blockchain network based on the above network architecture, since the consensus nodes in the consensus layer usually adopt a fully connected form, and the data interaction process between the consensus nodes is usually determined by the consensus protocol, this specification will describe in detail the construction of the network topology between the consensus subnetwork and each zone, as well as the construction of the network topology within each zone and between each zone. The construction process of the network topology of the consensus subnetwork will not be described in detail in this specification.

[0043] 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.

[0044] 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.

[0045] like Figure 1 As 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] When the aforementioned network devices initiate registration for the aforementioned target zone, this can be achieved by packaging a registration transaction and submitting the registration transaction to the blockchain network for execution.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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 network devices have completed registration for the target zone, they can further determine whether they meet the conditions to become relay nodes and confirm their node role in the target zone based on the determination result.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] In one embodiment shown, the message types supported by the aforementioned 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 subnetwork of the area corresponding to the message receiving node.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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 this specification does not impose specific limitations. For example, in one example, the ordinary node that joined the sub-network to which the relay node belongs earliest can be determined based on the time when each ordinary node that has established network links with the relay node joined the sub-network to which the relay node belongs, and then that ordinary node can be determined as the target ordinary node as a candidate relay node.

[0083] Step 206: If yes, establish network connections as a relay node with at least N consensus nodes in the consensus sub-network; wherein, the value of N is greater than the maximum number of fault-tolerant nodes in the blockchain network; if no, establish network connections as a regular node with at least M relay nodes in the target area sub-network; wherein, M is a pre-calculated robustness threshold corresponding to the relay nodes in the target area sub-network.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] Based on this, in this specification, if a network device determines that it meets the conditions to become a relay node in the target zone, it can act as a relay node and establish network connections with at least N consensus nodes in the consensus sub-network respectively; where 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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 .

[0099] 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.

[0100] 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. .

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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.

[0111] 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.

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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.

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

[0117] 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 regional sub-network may include multiple non-consensus nodes; the multiple non-consensus nodes may include at least one relay node that receives consensus data from a consensus node; and at least one ordinary node that receives consensus data forwarded by the relay node. The network devices to be joined to the blockchain network join the blockchain network by performing the following registration process: Identify the target area sub-network corresponding to the geographical location of the network device, and initiate registration for the target area sub-network; In response to the completion of registration for the target area sub-network, it is determined whether the network device meets the conditions to become the relay node; if so, it establishes network connections 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 not, it establishes network connections 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.

[0118] It should be noted that the implementation details of the registration process described above can be found in, for example... Figure 2 The embodiments shown will not be described in detail in this embodiment.

[0119] Figure 3 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Please refer to... Figure 3 At the hardware level, the device includes a processor 302, an internal bus 304, a network interface 306, memory 308, and non-volatile memory 310, 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 302 reading the corresponding computer program from the non-volatile memory 310 into memory 308 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.

[0120] like Figure 4 As shown, Figure 4 This specification is a block diagram illustrating a node device in a blockchain network according to an exemplary embodiment. This device can be applied to, for example... Figure 3 The electronic device shown implements the technical solution described in this specification. The blockchain node 40 includes: Registration module 401 determines the target area sub-network corresponding to the geographical location of the network device and initiates registration for the target area sub-network; The connection module 402, in response to the completion of registration for the target area sub-network, determines whether the network device meets the conditions to become the relay node; if yes, it establishes network connections 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 no, it establishes network connections 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.

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

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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.

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

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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."

[0133] 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 method for forming a blockchain network, the blockchain network comprising a consensus subnetwork composed of multiple consensus nodes, and at least one regional subnetwork corresponding to different geographical locations; the regional subnetwork comprising multiple non-consensus nodes; the multiple non-consensus nodes comprising at least one relay node receiving consensus data from the consensus nodes; and at least one ordinary node receiving consensus data forwarded by the relay nodes. The method is applied to any network device that needs to join the blockchain network; including: Identify the target area sub-network corresponding to the geographical location of the network device, and initiate registration for the target area sub-network; In response to the completion of registration for the target area sub-network, it is determined whether the network device meets the conditions to become the relay node; If so, it establishes network connections as a relay node with at least N consensus nodes in the consensus sub-network, where the value of N is greater than the maximum number of fault-tolerant nodes in the blockchain network; if not, it establishes network connections 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.

2. The method of claim 1, further comprising, before initiating registration for the target area sub-network: A registration request for the blockchain network is initiated to the blockchain service platform, so that the blockchain service platform responds to the registration request and performs registration processing for the network device; In response to the completion of registration for the blockchain network, service data related to the blockchain network is synchronized from the blockchain service platform; wherein, the service data includes the network addresses of consensus nodes in the blockchain network.

3. The method as described in claim 1, initiating registration for the target area sub-network, includes: Construct a registration transaction for the target area sub-network; wherein the registration transaction includes a network address corresponding to the network device; The registration transaction is submitted to the consensus sub-network, where each consensus node reaches a consensus on the registration transaction. After the consensus is passed, the registration transaction is stored on the blockchain to complete the registration for the target area sub-network.

4. The method of claim 1, wherein determining whether the network device meets the conditions for becoming the relay node, includes: Obtain the number of relay nodes in the target area sub-network: Determine whether the number of relay nodes in the target area sub-network is less than M; If yes, determine that the network device meets the conditions to become the relay node; otherwise, determine that the network device does not meet the conditions to become the relay node.

5. The method of claim 4, further comprising, before obtaining the number of relay nodes in the target area sub-network: Obtain the registration transactions submitted by other non-consensus nodes in the target area sub-network stored on the blockchain, and obtain the network addresses corresponding to the other non-consensus nodes in the target area sub-network from the obtained registration transactions; From the network addresses corresponding to the non-consensus nodes in the target area sub-network, at least one network address is randomly selected, and a network connection is established with at least one non-consensus node corresponding to the at least one network address.

6. The method as described in claim 5, wherein the messages exchanged between the nodes in the blockchain network include a first message for querying the node information of the relay nodes in the regional subnetwork corresponding to the message receiving node; and a second message for returning to the message sending node of the first message a set of node information of the relay nodes in the regional subnetwork to which the message receiving node is located, maintained by the message receiving node. Obtaining the number of relay nodes in the target area sub-network includes: Send the first message to each of the at least one non-consensus nodes; Obtain the second message returned by the at least one non-consensus node, read the node information set of relay nodes in the target area sub-network maintained by the at least one non-consensus node contained in the message content of the second message, and count the number of relay nodes in the target area sub-network based on the node information set.

7. The method as described in claim 6, wherein if the at least one non-consensus node is multiple non-consensus nodes, the second message returned by the at least one non-consensus node is obtained, and the node information set of relay nodes in the target area sub-network maintained by the at least one non-consensus node contained in the message content of the second message is read, and the number of relay nodes in the target area sub-network is counted based on the node information set, including: Obtain the second message returned by the plurality of non-consensus nodes, and read the node information set of the relay nodes in the target area sub-network that is maintained by the plurality of non-consensus nodes respectively in the message content of the second message returned by the plurality of non-consensus nodes. Take the union of the read node information sets, and count the number of relay nodes in the target area sub-network based on the obtained union.

8. The method as described in claim 2, wherein establishing network connections as a relay node with at least N consensus nodes in the consensus sub-network comprises: At least N network addresses are randomly selected from the network addresses of the consensus nodes in the blockchain network; As a relay node, it establishes network connections with the N network addresses respectively.

9. The method of claim 5, wherein establishing network connections as a regular node with at least M relay nodes in the target area sub-network comprises: At least M network addresses are randomly selected from the network addresses of each relay node in the blockchain network; As a regular node, it establishes network connections with the M network addresses.

10. The method of claim 9, further comprising: When a normal node establishes a network connection with any of the M target relay nodes, if the number of normal nodes that have established a network connection with the target relay node reaches the M, then the network address of the target normal node that has established a network connection with the target relay node is obtained, and a network connection is established with the target normal node based on the network address.

11. The method of claim 8, wherein the messages exchanged between the nodes in the blockchain network further include a third message for declaring that the message sending node is a normally functioning relay node; The method further includes: After establishing network connections with at least N consensus nodes in the consensus subnetwork as a relay node, the third message is periodically broadcast in the target area subnetwork; wherein the message content of the third message includes node information of the network device as a relay node; and, The system receives the third message periodically broadcast by other relay nodes in the target area sub-network, reads the node information of the other relay nodes contained in the message content of the third message, and adds the read node information to the maintained set of node information corresponding to the relay nodes in the target area sub-network.

12. The method of claim 11, 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 sub-network, a target ordinary node is determined from the ordinary nodes that have established network links with the network device as a candidate relay node, and the fourth message is sent to the target ordinary node to trigger the target ordinary node to establish a network connection with the at least N consensus nodes as a new relay node; and other ordinary nodes that have already established network connections with the network device establish network connections respectively.

13. The method of claim 12, wherein determining a target ordinary node as a candidate relay node from ordinary nodes that have established a network link with the network device comprises: Based on the time when each ordinary node that has established a network link with the network device 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.

14. The method as described in claim 1, wherein the consensus algorithm used in the blockchain network is the Byzantine consensus algorithm; the number of consensus nodes participating in the consensus in the blockchain network is 3f+1; wherein, The f represents the number of Byzantine nodes that the blockchain network can tolerate; the value of N ranges from (f, 3f+1).

15. The method as described in claim 14, The value of M is calculated using the following formula: in, This represents the probability that any non-consensus node in the target area sub-network will fail. This represents the robustness threshold corresponding to the probability that all relay nodes in the target area sub-network will fail.

16. The method of claim 15, wherein... Calculate using the following formula: in, T represents the total number of nodes in the blockchain network; This represents the probability that any Byzantine node in the target region sub-network will fail. This represents the probability that any honest node in the target region sub-network will crash.

17. The method of claim 16, wherein the probability of a Byzantine node in the target region sub-network failing is set to 1; Calculate using the following formula: Accordingly, the value of M is calculated using the following formula: 。 18. The method of claim 1, further comprising: If the network device meets the conditions to become the relay node, it establishes network connections with the network addresses of each other relay node in the target area sub-network.

19. The method of claim 1, further comprising: In response to the completion of registration for the target area sub-network, neighboring area sub-networks corresponding to the target area sub-network are determined from each network sub-region in the blockchain network; Establish network connections with the network addresses of at least some of the relay nodes in the neighboring area subnetwork.

20. The method of claim 1, wherein if the network device, acting as a relay node, establishes a network connection with a consensus node in the consensus subnetwork, the method further comprises: Through network connections with consensus nodes in the consensus subnetwork, the system receives consensus data sent by the consensus nodes, and further forwards the consensus data to the ordinary nodes in the target area subnetwork through network connections; and... The system receives transactions sent by ordinary nodes in the target area subnetwork through network connections, and further submits the transactions to the consensus nodes in the consensus subnetwork through network connections.

21. The method of claim 20, wherein if the network device, as a regular node, establishes a network connection with a relay node in the target area subnetwork, the method further comprises: The system receives transactions sent by clients and sends the transactions to relay nodes in the target area subnetwork via a network connection. The relay nodes then submit the transactions to the consensus nodes via a network connection with the consensus nodes in the consensus subnetwork.

22. The method as described in claim 21, wherein the plurality of non-consensus nodes are full nodes that do not participate in consensus; and the client is a light node that has established a network connection with the ordinary nodes.

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

24. A blockchain system, comprising: A consensus subnetwork consisting of multiple consensus nodes; and at least one regional subnetwork corresponding to different geographical locations; The regional subnetwork includes multiple non-consensus nodes; The plurality of non-consensus nodes include at least one relay node that receives consensus data from the consensus node; and at least one ordinary node that receives consensus data forwarded by the relay node. The network devices to be joined to the blockchain network join the blockchain network by performing the following registration process: Identify the target area sub-network corresponding to the geographical location of the network device, and initiate registration for the target area sub-network; In response to the completion of registration for the target area sub-network, it is determined whether the network device meets the conditions to become the relay node; If so, it establishes network connections as a relay node with at least N consensus nodes in the consensus sub-network, where the value of N is greater than the maximum number of fault-tolerant nodes in the blockchain network; if not, it establishes network connections 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.

25. A network device in a blockchain network, wherein the blockchain network includes a consensus subnetwork consisting of multiple consensus nodes, and at least one regional subnetwork corresponding to different geographical locations; the regional subnetwork includes multiple non-consensus nodes; the multiple non-consensus nodes include at least one relay node that receives consensus data from the consensus nodes; And, at least one ordinary node that receives consensus data forwarded by the relay node from the relay node; including: The registration module determines the target area sub-network corresponding to the geographical location of the network device and initiates registration for the target area sub-network; The connection module, in response to the completion of registration for the target area sub-network, determines whether the network device meets the conditions to become the relay node; if yes, it establishes network connections 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 no, it establishes network connections 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.

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

27. 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 23.

Images