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

Abstract

The embodiment of the application provides a networking method of a blockchain network, a blockchain network and a node device. The blockchain network comprises a consensus subnetwork composed of a plurality of consensus nodes and at least one regional subnetwork corresponding to different geographical positions. The regional subnetwork comprises a plurality of non-consensus nodes. The plurality of non-consensus nodes comprises at least one relay node receiving consensus data from the consensus nodes, and at least one ordinary node receiving the consensus data forwarded by the relay node from the relay node. The method comprises the following steps: determining a target regional subnetwork corresponding to a geographical position where a network device is located, and initiating registration for the target regional subnetwork; in response to completion of the registration for the target regional subnetwork, determining whether the network device meets the condition of becoming a relay node; if yes, establishing a network connection with the consensus nodes in the consensus subnetwork as the relay node; and if no, establishing a network connection with the relay nodes in the target regional subnetwork as the ordinary node.

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, a blockchain network, and node devices. 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:

[0004] Identify the target area sub-network corresponding to the geographical location of the network device, and initiate registration for the target area sub-network;

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

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

[0007] The network devices to be joined to the blockchain network join the blockchain network by performing the following registration process:

[0008] Identify the target area sub-network corresponding to the geographical location of the network device, and initiate registration for the target area sub-network;

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

[0010] 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:

[0011] 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;

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

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

[0014] 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. Attached Figure Description

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

[0016] Figure 1 This specification illustrates a network architecture diagram of a blockchain network according to an exemplary embodiment.

[0017] Figure 2 This specification is a flowchart illustrating a method for forming a blockchain network according to an exemplary embodiment;

[0018] Figure 3 This is a schematic structural diagram of an electronic device according to an exemplary embodiment of this specification;

[0019] Figure 4 This specification is a block diagram illustrating a node device in a blockchain network according to an exemplary embodiment. Detailed Implementation

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

[0021] In related technologies, the current blockchain networks mainly adopt the following three network topologies and networking methods when forming a network.

[0022] 1) Network topology based on direct connection

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

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

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

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

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

[0028] 2) Randomized networking method

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

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

[0031] 3) Network topology based on clustered networks

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

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

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

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

[0036] In view of this, this specification proposes a blockchain networking framework suitable for large-scale nodes.

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

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

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

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

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

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

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

[0044] like Figure 1 As shown, the above network architecture may include the following components:

[0045] 1: Consensus Subnetwork

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

[0047] 2: At least one regional subnetwork

[0048] In the above network architecture, the blockchain network, excluding the consensus layer, can be divided into at least one regional sub-network. For example... Figure 1As 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.

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

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

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

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

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

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

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

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

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

[0058] 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:

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

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

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

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

[0063] 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, on the other hand, could refer to the region information pre-configured for the network device. For instance, taking the network device as a service device, the 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.

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

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

[0066] 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 typically include authorization and access processing for the consortium blockchain.

[0067] 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 the various consensus nodes in the blockchain network.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0084] In one embodiment shown, the condition for a network device to become a relay node in the target zone can specifically be whether the target zone has a sufficient number of relay nodes. In this case, when determining whether it meets the condition to become a relay node, the network device can first obtain the number of relay nodes in the target zone, and then determine whether the number of relay nodes in the target zone is lower than a threshold. If so, the network device can be determined to meet the condition to become a relay node; otherwise, the network device can be determined not to meet the condition to become a relay node.

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

[0086] In one embodiment shown, the message types supported by the aforementioned blockchain network for interaction between nodes may specifically include the messages shown below:

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

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

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

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

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

[0092] The Relayer message (referred to as the third message) is used to declare that the message sending node is a normally functioning relay node.

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

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

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

[0096] 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, the number can be determined based on the robustness requirements of the aforementioned blockchain network, and no special limitation is made in this specification.

[0097] For example, in one scenario where 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 within 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, the network device can also simultaneously establish network connections with multiple relay nodes within the target zone. In this case, if one relay node fails, the network device can also receive data from the other consensus nodes.

[0098] In one embodiment shown, when a network device, acting as a relay node, establishes a network connection with a consensus node in a consensus subnetwork, it can specifically establish a network connection with the network address of the consensus node in the consensus subnetwork obtained during the registration phase of the blockchain network. Similarly, when a network device, acting as a regular node, establishes a network connection with a relay node in a target zone, it can specifically establish a network connection with the network address of the relay node in that target zone obtained during the registration phase of the target zone.

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

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

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

[0102] In one embodiment shown, after establishing a network connection with a consensus node in the consensus subnetwork as a relay node, the network device 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 set of node information corresponding to the relay nodes in the target zone.

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

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

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

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

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

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

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

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

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

[0112] The network devices to be joined to the blockchain network join the blockchain network by performing the following registration process:

[0113] Identify the target area sub-network corresponding to the geographical location of the network device, and initiate registration for the target area sub-network;

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

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

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

[0117] 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:

[0118] 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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 3, 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 below a threshold; If yes, determine whether 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 determining whether the network device meets the conditions for becoming the relay node: 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 determine the number of relay nodes in the target area sub-network based on the node information set.

7. The method of 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 determined based on the node information set, comprising: 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, which is maintained by the plurality of non-consensus nodes respectively, contained 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 determine the number of relay nodes in the target area sub-network based on the obtained union.

8. The method as described in claim 7, 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 a network connection with the 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.

9. The method of claim 3, wherein a smart contract for registering and managing the blockchain network is deployed on the blockchain; the registration transaction is a smart contract invocation transaction corresponding to the smart contract; The registration transaction is submitted to the consensus subnetwork, where each consensus node in the consensus subnetwork reaches a consensus on the registration transaction. After the consensus is passed, the registration transaction is stored on the blockchain, including: A smart contract call transaction containing the registration information of the network device for the target area subnetwork is submitted to the consensus subnetwork to trigger distributed execution of the registration logic contained in the smart contract by each consensus node in the consensus subnetwork, generating a registration event for the network device for the target area subnetwork, and reaching consensus on the generated registration event; wherein, the registration event contains the registration information; the registration information contains the network address corresponding to the network device; and, After consensus is reached on the registration event, the registration event is stored on the blockchain.

10. The method of claim 9, wherein obtaining registration transactions submitted by non-consensus nodes in the target area sub-network stored on the blockchain, and obtaining the network address corresponding to the non-consensus node in the target area sub-network from the obtained registration transactions, comprises: Monitor the registration events of non-consensus nodes in the target area sub-network generated by the smart contract, stored on the blockchain, for the target area sub-network; In response to the detected registration event, the registration information of the non-consensus node for the target area sub-network contained in the registration event is obtained, and the network address corresponding to the non-consensus node is obtained from the obtained registration information.

11. The method of claim 10, wherein the registration event further includes the network identifier of the target area sub-network; Monitoring the registration events of non-consensus nodes in the target area sub-network, generated by the smart contract and stored on the blockchain, for the target area sub-network, including: Listen for registration events stored on the blockchain that are generated by the smart contract and contain the network identifier of the target area sub-network.

12. The method as described in claim 1, Establishing network connections as a relay node with consensus nodes in the consensus sub-network includes: As a relay node, it establishes a network connection with the network address of the consensus node in the obtained consensus sub-network; The process of establishing a network connection between a regular node and a relay node in the target area sub-network includes: As a regular node, it establishes a network connection with the network address of the relay node in the target area sub-network.

13. 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 at least some of the relay nodes in the neighboring area subnetwork.

14. 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 connected to it 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.

15. The method of claim 14, 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.

16. The method as described in claim 15, 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.

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

18. A system based on 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 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 yes, it establishes a network connection with the consensus nodes in the consensus sub-network as a relay node; if no, it establishes a network connection with the relay nodes in the target area sub-network as a regular node.

19. A node 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 node 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 node 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.

20. 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 17 by invoking the machine-readable instructions.

21. 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 17.

Images