CN116032925A

CN116032925A - Networking method of block chain network, block chain network and node equipment

Info

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

Abstract

The embodiment of the application provides a networking method of a block chain network, the block chain network and node equipment, wherein the block chain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes includes at least one relay node that receives consensus data from the consensus node; and at least one common node for receiving the common data forwarded by the relay node from the relay node; the method comprises the following steps: determining a target area sub-network corresponding to the geographic position of the network equipment, and initiating registration for the target area sub-network; determining whether the network device satisfies a condition to become a relay node in response to completion of registration for the target area subnetwork; if so, establishing network connection as a relay node with a consensus node in the consensus sub-network; if not, establishing network connection with the relay node in the target area sub-network as the common node.

Description

Networking method of block chain network, block chain network and node equipment

Technical Field

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

Background

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

Disclosure of Invention

The specification provides a networking method of a blockchain network, wherein the blockchain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes includes at least one relay node that receives consensus data from the consensus node; and at least one common node receiving the common data forwarded by the relay node from the relay node; the method is applied to any network equipment to be added into the blockchain network; comprising the following steps:

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

determining, in response to completion of registration for the target area subnetwork, whether the network device satisfies a condition for becoming the relay node; if so, establishing network connection as a relay node with a consensus node in the consensus sub-network; if not, establishing network connection with the relay node in the target area sub-network as a common node.

The present specification also proposes a blockchain network comprising: a consensus sub-network consisting of a plurality of consensus nodes; and at least one regional subnetwork respectively corresponding to different geographic locations; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes includes at least one relay node that receives consensus data from the consensus node; and at least one common node receiving the common data forwarded by the relay node from the relay node;

wherein a network device to be joined to the blockchain network joins the blockchain network by performing a registration procedure as follows:

The specification also proposes node equipment in a blockchain network, wherein the blockchain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes includes at least one relay node that receives consensus data from the consensus node; and at least one common node receiving the common data forwarded by the relay node from the relay node; the method is applied to any network equipment to be added into the blockchain network; comprising the following steps:

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

A connection module that determines whether the network device satisfies a condition to become the relay node in response to completion of registration for the target area subnetwork; if so, establishing network connection as a relay node with a consensus node in the consensus sub-network; if not, establishing network connection with the relay node in the target area sub-network as a common node.

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

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

Drawings

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

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

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

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

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

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

In the related art, the network topology and the networking mode adopted by the current blockchain network during networking mainly include the following three modes.

1) Networking mode based on direct connection network topology

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

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

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

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

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

2) Networking mode based on random mode

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

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

3) Networking mode based on cluster network topology

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

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

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

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

In view of this, the present specification proposes a blockchain networking framework suitable for large-scale nodes.

Under such networking framework, the blockchain network may be divided into a consensus sub-network composed of a plurality of consensus nodes, and at least one regional sub-network respectively corresponding to different geographic locations;

wherein, the regional subnetwork can comprise a plurality of non-consensus nodes; the plurality of non-consensus nodes may include at least one relay node that receives consensus data from a consensus node; and at least one common node for receiving the common data forwarded by the relay node at the relay node.

When any network device to be added to the blockchain network joins the blockchain network, a target area sub-network corresponding to the geographic location of the network device may be determined first, and then registration for the target area sub-network may be initiated.

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

In the above embodiment, on the one hand, by dividing the blockchain network into the consensus sub-network and at least one regional sub-network corresponding to different geographic locations in advance, when one network device joins the blockchain network as a blockchain link point, registration can be initiated for the nearby target regional sub-network corresponding to the geographic location where the network device is located, and the network device joins the target regional sub-network as a blockchain node. Because the nodes in the same regional subnetwork are closer in physical topology and have lower data transmission delay, the nodes in the same regional subnetwork can transmit the data to be shared to the shared node more quickly, and can also receive the shared data which is distributed by the shared node and is completed by the shared node more quickly.

Referring to fig. 1, fig. 1 is a networking architecture diagram of a blockchain network as illustrated in the present specification according to an exemplary embodiment.

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

1: consensus subnetwork

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

2: at least one regional subnetwork

In the networking architecture described above, the networks other than the consensus layer in the blockchain network may be divided into at least one regional subnetwork. As shown in fig. 1, each regional subnetwork may be referred to as a zone, and each zone may contain multiple non-consensus nodes. Here, the non-consensus node generally refers to a full node in the blockchain network that does not participate in consensus. Different zones may correspond to different geographic locations, respectively.

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

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

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

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

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

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

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

When the block chain networking is performed based on the networking architecture, the common nodes of the common layer are in a full connection mode, and the data interaction process between the common nodes is generally determined by a common protocol; thus, in the present specification, construction of the network topology between the consensus sub-network and each zone, and construction of the network topology within each zone and between each zone will be described in detail, and construction processes of the network topology with respect to the consensus sub-network will not be described in detail in the present specification.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In one embodiment shown, the network device is the condition for the relay nodes in the target zone, specifically, whether there are a sufficient number of relay nodes in the target zone. In this case, when judging whether the network device itself meets the condition of becoming the relay node, the network device may specifically acquire the number of relay nodes in the target zone first, and then determine whether the number of relay nodes in the target zone is lower than a threshold value; if yes, the network equipment can be determined to meet the condition of becoming a relay node; conversely, it may be determined that the network device does not satisfy the condition of becoming a relay node.

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

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

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

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

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

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

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

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

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

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

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

The number of the consensus nodes or the relay nodes that establish network connection with the network device may be one or more, and in practical application, the determination may be performed based on the robustness requirement on the blockchain network, which is not particularly limited in the present specification;

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

In the illustrated embodiment, the network device, when further establishing a network connection as a relay node with a consensus node in the consensus sub-network, may in particular establish a network connection with a network address of the consensus node in the consensus sub-network acquired during a registration phase of the blockchain network. When the network device is used as a common node to establish network connection with the relay node in the target zone, the network device can specifically establish network connection with the network address of the relay node in the target zone, which is acquired in the registration stage of the target zone.

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

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

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

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

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

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

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

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

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

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

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

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

wherein, the regional subnetwork can comprise a plurality of non-consensus nodes; the plurality of non-consensus nodes may include at least one relay node that receives consensus data from the consensus node; and at least one common node for receiving the consensus data forwarded by the relay node at the relay node;

It should be noted that, the details of the registration process described above may refer to the embodiment shown in fig. 2, and will not be described in detail in this embodiment.

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

As shown in fig. 4, fig. 4 is a block diagram of a node device in a blockchain network according to an exemplary embodiment of the present disclosure, and the apparatus may be applied to the electronic device shown in fig. 3 to implement the technical solution of the present disclosure. The blockchain node 40 includes:

A registration module 401, configured to determine a target area subnetwork corresponding to a geographic location where the network device is located, and initiate registration for the target area subnetwork;

a connection module 402, responsive to completion of registration for the target area subnetwork, determining whether the network device satisfies a condition for becoming the relay node; if so, establishing network connection as a relay node with a consensus node in the consensus sub-network; if not, establishing network connection with the relay node in the target area sub-network as a common node.

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A networking method of a blockchain network, wherein the blockchain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes includes at least one relay node that receives consensus data from the consensus node; and at least one common node receiving the common data forwarded by the relay node from the relay node; the method is applied to any network equipment to be added into the blockchain network; comprising the following steps:

2. The method of claim 1, prior to initiating registration for the target area subnetwork, further comprising:

initiating a registration request for the blockchain network to a blockchain service platform to perform registration processing for the network device by the blockchain service platform in response to the registration request;

synchronizing, from the blockchain service platform, blockchain network-related service data in response to completion of registration for the blockchain network; wherein the service data includes a network address of a consensus node in the blockchain network.

3. The method of claim 1, initiating registration for the target area subnetwork, comprising:

constructing a registration transaction for the target area subnetwork; wherein the registration transaction includes a network address corresponding to the network device;

submitting the registered transaction to the consensus sub-network, consensus the registered transaction by each consensus node in the consensus sub-network, and storing the registered transaction on the blockchain after the consensus is passed so as to finish the registration of the target area sub-network.

4. The method of claim 3, determining whether the network device satisfies the condition to be the relay node, comprising:

Acquiring the number of relay nodes in the target area subnetwork:

determining whether the number of relay nodes in the target area subnetwork is below a threshold; if yes, determining whether the network equipment meets the condition of becoming the relay node; and otherwise, determining that the network equipment does not meet the condition of becoming the relay node.

5. The method of claim 4, the determining whether the network device satisfies the condition to be the relay node, further comprising:

acquiring registration transactions stored on the blockchain and submitted by other non-consensus nodes in the target area sub-network, and acquiring network addresses corresponding to the other non-consensus nodes in the target area sub-network from the acquired registration transactions; and randomly selecting at least one network address from the network addresses corresponding to the obtained non-consensus nodes in the target area sub-network, and respectively establishing network connection with at least one non-consensus node corresponding to the at least one network address.

6. The method of claim 5, wherein the messages interacted between the nodes in the blockchain network include a first message for querying node information of relay nodes in a regional subnetwork to which the message receiving node corresponds; and a second message for returning to the message sending node of the first message a set of node information of relay nodes in the regional subnetwork in which it is maintained by the message receiving node;

Obtaining the number of relay nodes in the target area subnetwork includes:

sending the first message to the at least one non-consensus node respectively;

and acquiring the second message returned by the at least one non-consensus node, reading a node information set of the relay nodes in the target area sub-network maintained by the at least one non-consensus node and contained in the message content of the second message, and determining the number of the relay nodes in the target area sub-network based on the node information set.

7. The method of claim 6, if the at least one non-consensus node is a plurality of non-consensus nodes, obtaining the second message returned by the at least one non-consensus node and reading a node information set of relay nodes in the target area subnetwork maintained by the at least one non-consensus node contained in a message content of the second message, and determining a number of relay nodes in the target area subnetwork based on the node information set, comprising:

and acquiring the second messages returned by the plurality of non-consensus nodes, respectively reading node information sets of relay nodes in the target area sub-network respectively maintained by the plurality of non-consensus nodes, which are contained in the message contents of the second messages returned by the plurality of non-consensus nodes, taking a union set of the read node information sets, and determining the number of the relay nodes in the target area sub-network based on the obtained union set.

8. The method of claim 7, the messages interacted between the nodes in the blockchain network further comprising a third message for declaring the messaging node to be a properly functioning relay node;

the method further comprises the steps of:

after establishing a network connection as a relay node with a consensus node in the consensus sub-network, periodically broadcasting and transmitting the third message in the target area sub-network; the message content of the third message contains node information of the network equipment serving as a relay node; the method comprises the steps of,

and receiving the third message periodically broadcast-transmitted by other relay nodes in the target area sub-network, reading node information of the other relay nodes contained in the message content of the third message, and adding the read node information to a maintained node information set corresponding to the relay nodes in the target area sub-network.

9. The method of claim 3, the blockchain having disposed thereon a smart contract for registration management of the blockchain network; the registration transaction is an intelligent contract call transaction corresponding to the intelligent contract;

Submitting the registered transaction to the consensus sub-network, consensus the registered transaction by each consensus node in the consensus sub-network, and storing the registered transaction on the blockchain after the consensus is passed, comprising:

submitting an intelligent contract call transaction containing registration information of the network equipment aiming at the target area sub-network to the consensus sub-network so as to trigger each consensus node in the consensus sub-network to execute the registration logic contained in the intelligent contract in a distributed mode, generate a registration event of the network equipment aiming at the target area sub-network, and perform consensus on the generated registration event; wherein the registration event includes the registration information; the registration information comprises a network address corresponding to the network equipment; the method comprises the steps of,

after consensus for the registration event passes, the registration event is stored on the blockchain.

10. The method of claim 9, obtaining a registration transaction stored on the blockchain submitted by a non-consensus node in the target area subnetwork, obtaining a network address corresponding to the non-consensus node in the target area subnetwork from the obtained registration transaction, comprising:

Monitoring a registration event of a non-consensus node in the target area subnetwork generated by the intelligent contract stored on the blockchain for the target area subnetwork;

and responding to the monitored registration event, acquiring registration information of the non-consensus node contained in the registration event aiming at the target area sub-network, and acquiring a network address corresponding to the non-consensus node from the acquired registration information.

11. The method of claim 10, the registration event further comprising a network identification of the target area subnetwork;

monitoring registration events of non-consensus nodes in the target area subnetwork generated by the intelligent contract stored on the blockchain for the target area subnetwork, including:

monitoring a registration event stored on the blockchain and generated by the intelligent contract and containing the network identification of the target area subnetwork.

12. The method according to claim 1,

establishing network connection as a relay node with a consensus node in the consensus sub-network, comprising:

establishing network connection as a relay node with the acquired network address of the consensus node in the consensus sub-network;

The establishing network connection as a common node with a relay node in the target area sub-network includes:

and establishing network connection as a common node with the acquired network address of the relay node in the target area sub-network.

13. The method of claim 1, the method further comprising:

determining a neighbor region subnetwork corresponding to the target region subnetwork from among the respective network sub-regions in the blockchain network in response to registration completion for the target region subnetwork;

and establishing network connection with at least part of relay nodes in the neighbor area sub-network.

14. The method of claim 1, if the network device establishes a network connection as a relay node with a consensus node in the consensus sub-network, the method further comprising:

receiving the consensus data sent by the consensus nodes through network connection with the consensus nodes in the consensus sub-network, and forwarding the consensus data to the common nodes through network connection between the common nodes connected with the consensus data; the method comprises the steps of,

and receiving the transaction sent by the common node through network connection with the common node in the target area sub-network, and further submitting the transaction to the common node through network connection with the common node in the common sub-network.

15. The method of claim 14, if the network device establishes a network connection as a regular node with a relay node in the target area subnetwork, the method further comprising:

and receiving the transaction sent by the client, and sending the transaction to the relay node through network connection with the relay node in the target area sub-network so that the relay node can further submit the transaction to the consensus node through network connection with the consensus node in the consensus sub-network.

16. The method of claim 15, the plurality of non-consensus nodes being full nodes that do not participate in consensus; the client is a light node which establishes network connection with the common node.

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

18. A blockchain network, comprising: a consensus sub-network consisting of a plurality of consensus nodes; and at least one regional subnetwork respectively corresponding to different geographic locations; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes includes at least one relay node that receives consensus data from the consensus node; and at least one common node receiving the common data forwarded by the relay node from the relay node;

19. A node device in a blockchain network, wherein the blockchain network comprises a consensus sub-network formed by a plurality of consensus nodes and at least one regional sub-network respectively corresponding to different geographic positions; the regional subnetwork includes a plurality of non-consensus nodes; the plurality of non-consensus nodes includes at least one relay node that receives consensus data from the consensus node; and at least one common node receiving the common data forwarded by the relay node from the relay node; comprising the following steps:

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

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

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