CN114338676B

CN114338676B - Block synchronization method and device, electronic equipment and storage medium

Info

Publication number: CN114338676B
Application number: CN202111663636.0A
Authority: CN
Inventors: 陶友贤
Original assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-12-31
Filing date: 2021-12-31
Publication date: 2024-05-28
Anticipated expiration: 2041-12-31
Also published as: CN114338676A

Abstract

The present specification provides a block synchronization method, apparatus, electronic device, and storage medium, wherein the method is applied to a first blockchain node in a first blockchain network in a blockchain system, the first blockchain node dynamically maintaining a local block height with a local latest block and a dynamic request period, the dynamic request period being inversely related to a degree of lag between the local block height and a latest block height of an actual latest block of the first blockchain network and a size of a first node weight factor; the method comprises the following steps: periodically sending a block synchronization request for a lagging block to a normal node maintaining an actual latest block in the first blockchain network according to a dynamic request period under the condition that the local block height is behind the latest block height, wherein the block height of the lagging block is between the local block height and the latest block height; and receiving the backward blocks returned by the normal nodes in response to the block synchronization request so as to redetermine the local latest blocks and the dynamic request period.

Description

Block synchronization method and device, electronic equipment and storage medium

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a block synchronization method, a device, electronic equipment and a storage medium.

Background

Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. In the block chain system, the data blocks are combined into a chain data structure in a sequential connection mode according to the time sequence, and the distributed account book which is not tamperable and counterfeit and is ensured in a cryptographic mode is formed. Because the blockchain has the characteristics of decentralization, non-tamperability of information, autonomy and the like, the blockchain is also receiving more and more attention and application. In some blockchain networks, some nodes sometimes have a need to implement small-scale transactions to avoid other nodes from obtaining these transactions and their related data. The blockchain subnetwork can be further built on the basis of the blockchain subnetwork, and both the blockchain subnetwork and the blockchain subnetwork act as independent blockchain networks.

For a blockchain main network or a blockchain sub network, consistency of the respectively maintained distributed account book is ensured among all the included blockchain nodes through a consensus protocol. However, when the blockchain node is down and restarted or a new subnet node is added, the blockdata in the distributed ledger maintained by the blockchain node is caused to lag behind a normal node in the blockchain network, and cannot participate in a normal consensus process, so that the operation of functions and services on the blockchain node is affected.

Disclosure of Invention

The invention aims to provide a block synchronization method, a block synchronization device, electronic equipment and a storage medium.

According to a first aspect of one or more embodiments of the present disclosure, a block synchronization method is provided, which is applied to a first blockchain node in a first blockchain network in a blockchain system, where the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, the first blockchain node dynamically maintains a local block height of a local latest block and a dynamic request period, and the dynamic request period negatively correlates with a degree of lag between the local block height and the latest block height of an actual latest block of the first blockchain network and negatively correlates with a magnitude of a first node weight factor corresponding to the first blockchain node; the method comprises the following steps:

Periodically sending a block synchronization request for a lagging block to a normal node maintaining the actual latest block in a first blockchain network according to the dynamic request period under the condition that the local block height is behind the latest block height, wherein the block height of the lagging block is between the local block height and the latest block height;

And receiving the lagging block returned by the normal node in response to the block synchronization request so as to redetermine the local latest block and the dynamic request period.

According to a second aspect of one or more embodiments of the present disclosure, a block synchronization apparatus is provided, which is applied to a first blockchain node in a first blockchain network in a blockchain system, where the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, the first blockchain node dynamically maintains a local block height of a local latest block and a dynamic request period, and the dynamic request period is negatively related to a degree of lag between the local block height and the latest block height of an actual latest block of the first blockchain network and is negatively related to a size of a first node weight factor corresponding to the first blockchain node; the device comprises:

a request sending unit, configured to periodically send a block synchronization request for a lagging block to a normal node in a first blockchain network, where the normal node maintains the actual latest block in the first blockchain network according to the dynamic request period, where the block height of the lagging block is between the local block height and the latest block height;

And the block receiving unit is used for receiving the lagging block returned by the normal node in response to the block synchronization request so as to redetermine the local latest block and the dynamic request period.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic device comprising:

A processor;

A memory for storing processor-executable instructions;

Wherein the processor implements the method of any of the first aspects by executing the executable instructions.

According to a fourth aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method as in any of the first aspects.

In this embodiment of the present disclosure, the blockchain system includes a blockchain main network and a blockchain sub-network managed by the same, where when a first blockchain node in a first blockchain network in the blockchain system detects that a block maintained by itself is behind, a block synchronization request for a behind block is periodically sent to a normal node in the first blockchain network, where the actual latest block is maintained, according to the dynamic request period, so that the first blockchain node can acquire the behind block corresponding to the behind block, to ensure normal operation of functions and services on the first blockchain node. Meanwhile, the dynamic request period is negatively related to the lag degree between the local block height and the latest block height of the actual latest block of the first block chain network and the size of a first node weight factor corresponding to the first block chain node, so that the effective request times in unit time of the lag node with larger lag degree are more, the lag node with larger lag degree can complete the block tracking process more quickly, and the number of normal nodes and the calculation resources in the first block chain network and the network bandwidth resources of the first block chain network are limited because the calculation resources are required to be consumed when the block synchronization request is responded by the normal node and the network bandwidth resources are also occupied when the lag block is returned, so that the scheme is equivalent to the calculation resources of the lag node with larger lag degree and the network bandwidth resources of the first block chain network which are occupied by the normal node preferentially, namely, the reasonable allocation is carried out on the calculation resources of the normal node and the network bandwidth resources of the first block chain network; in addition, the dynamic request period is also influenced by the weight factor of the first node, so that the scheme can macroscopically regulate and control the block synchronization rates of different block chain nodes, and the hierarchical design of the block synchronization task is realized.

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 schematic diagram of a blockchain subnetwork based on a blockchain main network in accordance with an exemplary embodiment.

Fig. 2 is a flowchart of a block synchronization method according to an exemplary embodiment.

Fig. 3 is a schematic diagram of a network topology according to an exemplary embodiment.

Fig. 4 is a schematic diagram of an apparatus according to an exemplary embodiment.

Fig. 5 is a block diagram of a block synchronization apparatus provided in 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.

Because of the decentralization characteristic of the blockchain network, all blockchain nodes in the blockchain network can maintain the same block data, and the special requirements of part of nodes cannot be met. Taking a blockchain as an example, all the coalition members (i.e., node members in the coalition) can form a blockchain network, all the coalition members respectively have corresponding blockchain nodes in the blockchain network, and all transactions and related data occurring on the blockchain network can be obtained through the corresponding blockchain nodes. In some cases, however, there may be some coalition members desiring to complete transactions with security requirements, which may be desirable to both be able to document on the blockchain or to take advantage of other advantages of blockchain technology, and to avoid other coalition members from viewing such transactions and related data. Although the members of the federation may additionally build a new blockchain network in a manner similar to that described above that includes all of the members of the federation, building a new blockchain network from scratch requires significant resources and is time consuming, either in the process of building the blockchain network or in the process of post-build configuration. The requirements among the alliance members are often temporary or have certain timeliness, so that the new blockchain network quickly loses the meaning of existence due to the disappearance of the requirements, thereby further increasing the chain building cost of the blockchain network. The requirements between the members of the federation often vary, and the members of the federation corresponding to each requirement also often vary, so that a new blockchain network may need to be built whenever the members of the federation change, resulting in a great waste of resources and time.

To this end, the established blockchain network may be used as a blockchain master network, and the blockchain subnetwork may be established based on the blockchain master network. Then, in a federated chain scenario such as that described above, federated members may build the required blockchain subnetwork on the blockchain subnetwork's basis based on their own needs, already participating in the blockchain subnetwork. Because the blockchain subnetwork is built on the basis of the blockchain main network, compared with a completely independent blockchain network, the building process of the blockchain subnetwork has the advantages of greatly reduced consumed resources, time consumption and the like, and extremely high flexibility.

The process of quickly constructing the blockchain sub-network based on the blockchain main network is as follows: each block link point in the block chain main network respectively acquires a transaction for constructing a block chain sub-network, wherein the transaction comprises configuration information of the block chain sub-network, the configuration information comprises identity information of node members participating in constructing the block chain sub-network, each block link point in the block chain main network respectively executes the transaction to permeate out the configuration information, and when the configuration information comprises the identity information of the node member corresponding to the first block link point, node equipment for deploying the first block chain node starts a second block chain node belonging to the block chain sub-network based on the creation block comprising the configuration information.

For example, as shown in fig. 1, the blockchain home network is subnet0, and blockchain nodes included in the subnet0 are nodeA, nodeB, nodeC, nodeD, nodeE, and the like. Assume nodeA, nodeB, nodeC and nodeD wish to build a blockchain subnetwork: if nodeA is an administrator and only allows the administrator to initiate transactions to build the blockchain subnetwork, then the above-described transactions to build the blockchain subnetwork may be initiated by nodeA to subnet 0; if nodeE is an administrator and only the administrator is allowed to initiate transactions to build the blockchain sub-network, then nodeA-nodeD need to request nodeE to cause nodeE to initiate transactions to subnet0 to build the blockchain sub-network as described above; if nodeE is an administrator but allows a common user to initiate transactions to build a blockchain subnet, then nodes A-nodeE may each initiate transactions to subnet0 to build a blockchain subnet as described above. Of course, the blockchain node, whether an administrator or an ordinary user, that initiates the transaction of building the blockchain subnetwork does not necessarily participate in the built blockchain subnetwork, such as, although eventually the blockchain subnetwork is built by nodeA, nodeB, nodeC and nodeD, the transaction of building the blockchain subnetwork may be initiated to subnet0 by nodeE, rather than by nodeA-nodeD.

When the blockchain subnetwork is built on the basis of the blockchain main network, it is easy to understand that a logical hierarchical relationship exists between the blockchain subnetwork and the blockchain main network. For example, when the blockchain subnet1 is built on the subnet0 shown in fig. 1, the subnet0 may be considered to be at the first layer and the subnet1 may be considered to be at the second layer. In one case, the blockchain master network in this specification may be an underlying blockchain network, i.e., a blockchain subnetwork that is not a blockchain subnetwork that is built on the basis of other blockchain networks, such as subnet0 in fig. 1, may be considered a blockchain master network that is of the underlying blockchain network type. In another case, the blockchain main network in the present specification may be a subnet of another blockchain network, for example, another blockchain subnet may be further configured based on the subnet1 in fig. 1, where the subnet1 may be considered as the blockchain main network corresponding to the blockchain subnet, and this does not affect the creation of the blockchain sub network on the subnet0 while the subnet1 belongs to the blockchain sub network. It can be seen that the blockchain master network and the blockchain subnetwork are actually relative concepts, and that the same blockchain network may be a blockchain master network in some cases and a blockchain subnetwork in other cases.

After the transaction for constructing the blockchain sub-network is sent to the blockchain main network, the nodes in the blockchain main network are subjected to consensus, and after the transaction passes through the consensus, the nodes in each main network execute the transaction so as to finish the construction of the blockchain sub-network. The consensus process depends on the consensus mechanism employed, which is not limited by the present description.

By including configuration information in the transactions for constructing the blockchain sub-network, the configuration information may be used to configure the constructed blockchain sub-network so that the constructed blockchain sub-network meets networking requirements. For example, by including node membership information in the configuration information, it may be specified which blockchain nodes are included in the established blockchain subnetwork.

The identity information of the node member may include a public key of the node, or other information capable of characterizing the identity of the node, such as a node ID, which is not limited in this specification. Taking the public key as an example, each blockchain node has one or more public and private key pairs, the private key is held by the blockchain node, and the public key is disclosed and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Thus, for blockchain nodes that are desired to be node members of a blockchain subnetwork, the public keys of those blockchain nodes can be added to the transactions that constitute the blockchain subnetwork as identity information for the node members. The public-private key pair described above may be used in the process of signature verification. For example, in a consensus algorithm with a signature, such as subnet1 described above, where the message is signed with its own maintained private key, the signed message is broadcast in subnet1, and the received message may be signature verified by the public key of subnet1 with subnet1, nodeC, and nodeD1 to confirm that the received message is indeed from subnet1 and has not been tampered with.

The first master network node may be a blockchain node on the blockchain master network that belongs to a node member indicated by the configuration information. When constructing a blockchain subnetwork, instead of the first main network node directly participating in constructing the blockchain subnetwork and becoming its node member, it is necessary that the first subnetwork node be generated by the node device for deploying the first main network node and become the node member in the blockchain subnetwork by the first subnetwork node. The first main network node and the first sub network node correspond to the same blockchain member, for example, in a alliance chain scene, but the first main network node belongs to a blockchain main network and the first sub network node belongs to a blockchain sub network, so that the blockchain member can participate in transactions of the blockchain main network and the blockchain sub network respectively; and because the block chain main network and the block chain sub network belong to two independent block chain networks, the block generated by the first main network node and the block generated by the first sub network node are respectively stored in different storages (the adopted storages can be databases, for example) on the node equipment, so that the mutual isolation between the storages respectively used by the first main network node and the first sub network node is realized, the data generated by the block chain sub network can only be synchronized among the node members of the block chain sub network, the data generated by the block chain sub network can not be obtained by the block chain members only participating in the block chain main network, the data isolation between the block chain main network and the block chain sub network is realized, and the transaction requirement between partial block chain members (namely the block chain members participating in the block chain sub network) is met.

It can be seen that the first main network node and the first sub-network node are logically divided blockchain nodes, and from the aspect of the physical device, the node device where the first main network node and the first sub-network node are deployed is equivalent to the above-mentioned node device which participates in the blockchain main network and the blockchain sub-network at the same time. Because the blockchain main network and the blockchain sub-network are mutually independent, the identity systems of the two blockchain networks are mutually independent, and even if the first main network node and the first sub-network node can adopt identical public keys, the two blockchain main network node and the first sub-network node can still be regarded as different blockchain nodes. For example, in fig. 1, nodeA in subnet0 corresponds to the first main network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to the first sub network node. Therefore, the identity systems are independent, so that even if the public key adopted by the first subnet node is different from the public key adopted by the first main network node, implementation of the scheme of the specification is not affected.

Of course, the node members of the blockchain subnetwork are not necessarily only part of the node members of the blockchain main network. In some cases, node members of the blockchain subnetwork may be completely consistent with node members of the blockchain subnetwork, where all blockchain members may obtain data on the blockchain subnetwork and the blockchain subnetwork, but the data generated by the blockchain subnetwork and the blockchain subnetwork may still be isolated from each other, for example, one type of service may be implemented on the blockchain subnetwork, and another type of service may be implemented on the blockchain subnetwork, so that service data generated by the two types of services may be isolated from each other.

In addition to the identity information of the node members described above, the configuration information may include at least one of: the network identification of the blockchain subnetwork, identity information of an administrator of the blockchain subnetwork, attribute configuration for blockchain platform code, and the like, are not limiting in this description. The network identification is used to uniquely characterize the blockchain subnetwork, and thus the network identification of the blockchain subnetwork should be distinguished from the blockchain main network and other blockchain subnetworks built on the blockchain main network. The identity information of the administrator of the blockchain subnetwork, such as a public key that is a member of the node of the administrator; the administrators of the blockchain main network and the blockchain sub network may be the same or different.

One of the advantages of constructing the blockchain subnetwork through the blockchain main network is that the first main network node is already deployed on the node equipment generating the first subnetwork node, so that the blockchain platform code used by the first main network node can be multiplexed on the first subnetwork node, repeated deployment of the blockchain platform code is avoided, and the construction efficiency of the blockchain subnetwork is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node may multiplex the attribute configuration employed on the first main network node; if the configuration information includes the attribute configuration for the blockchain platform code, the first subnet node may employ the attribute configuration, so that the attribute configuration employed by the first subnet node is not limited to the attribute configuration of the first main network node, and is independent of the first main network node. The attribute configuration for the blockchain platform code may include at least one of: code version number, whether consensus is required, consensus algorithm type, block size, etc., which is not limiting in this description.

The transactions that constitute the blockchain subnetwork include transactions that invoke contracts. The transaction may specify the address of the smart contract that was invoked, the method that was invoked, and the parameters that were entered. For example, the invoked contract may be the aforementioned creation contract or system contract, the invoked method may be a method of building a blockchain subnet, and the incoming parameters may include the configuration information described above. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

Wherein the from field is information of the initiator of the transaction, such as Administrator indicating that the initiator is an administrator; the to field is the address of the called smart contract, e.g., the smart contract may be a Subnet contract, and the to field is specifically the address of the Subnet contract; the method field is a called method, for example, the method for constructing a blockchain Subnet in a Subnet contract may be AddSubnet (string), and string is a parameter in AddSubnet () method, and the value of the parameter is represented by generation in the above example, and the generation is specifically the configuration information described above.

Take as an example the transactions that call AddSubnet () method in the Subnet contract are performed by nodes nodeA-nodeE on the Subnet 0. After the transaction passes the consensus, the nodeA-nodeE respectively execute AddSubnet () method and transmit configuration information to obtain corresponding execution results.

After executing the transaction invoking the smart contract, the node in the blockchain network generates a corresponding receipt (receipt) for recording information related to executing the smart contract. In this way, information about the result of contract execution can be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in a receipt. The messaging mechanism may implement messaging through events in the receipt to trigger the blockchain node to perform the corresponding process. The structure of the event may be, for example:

Event：

[topic][data]

......

In the above examples, the number of events may be one or more; wherein each event includes fields such as a theme (topic) and data (data), respectively. The block link point may perform a preset process by listening to the topic of the event, in case of listening to the predefined topic, or read the related content from the data field of the corresponding event, and may perform the preset process based on the read content.

In the event mechanism described above, the client having the monitoring function is located at the monitoring party (such as the user having the monitoring requirement), for example, the SDK for implementing the monitoring function is running on the client, and the client monitors the event generated by the blockchain node, and the blockchain node only needs to normally generate the receipt. In addition to the event mechanism described above, the transmission of transaction information may be accomplished in other ways. For example, the listening code may be embedded in the blockchain platform code running at the blockchain point such that the listening code may listen to one or more of the transaction content of the blockchain transaction, the contract status of the smart contract, the receipt generated by the contract, etc., and send the monitored data to the predefined listener. Since the snoop code is deployed in the blockchain platform code, rather than at the client of the snooper, such a snoop code-based implementation is relatively more proactive than an event mechanism. The above-mentioned monitoring code may be added into the blockchain platform code by a developer of the blockchain platform in the development process, or may be embedded by a monitoring party based on the own requirement, which is not limited in this specification.

It can be seen that the execution result of the above-mentioned Subnet contract may include the configuration information, and the execution result may be in the receipt described above, and the receipt may include an event related to executing the AddSubnet () method, that is, a networking event. Topic of networking events may contain predefined networking event identifications to distinguish from other events. For example, in an event associated with executing the AddSubnet () method, the content of the topic is the keyword subnet, and the keyword is distinguished from topic in the event generated by other methods. Then, the nodeA-nodeE can determine to monitor the event related to executing the AddSubnet () method, that is, the networking event, by monitoring the topic contained in each event in the generated receipt, in the case of monitoring the topic containing the keyword subnet. For example, the event in the receipt is as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

Then, when nodeA-nodeE monitors item 1, since the content of the topic contained is other, it is determined that the item is irrelevant to AddSubnet () method; and, when the 2 nd event is monitored, the nodes a to nodeE determine that the event is related to the AddSubnet () method because the content of the topic contained is subnet, and further read the data field corresponding to the event, where the data field contains the configuration information described above. Taking the example that the configuration information includes the public key of the node member of the blockchain subnet, the content of the data field may include, for example:

{subnet1；

a public key of nodeA, IP of nodeA, port number … of nodeA;

public key of nodeB, IP of nodeB, port number … of nodeB;

nodeC public key, IP of nodeC, port number … of nodeC;

nodeD public key, IP of nodeD, port number … of nodeD;

}

wherein, subnet1 is the network identification of the blockchain subnet that it is desired to create. Each blockchain node in the blockchain master network may record network identifications of all blockchain subnets that have been created on the blockchain master network, or other information related to the blockchain subnets, which may be maintained in a Subnet contract as described above, for example, and may specifically correspond to the value of one or more contract states contained in the Subnet contract. Then, nodeA-nodeE can determine whether the subnet1 already exists according to the recorded network identifications of all the created blockchain subnets; if not, it is indicated that subnet1 is a new block chain subnet that currently needs to be created, and if so, it is indicated that subnet1 already exists.

In addition to employing network identifications of new blockchain subnets that are desired to be created, predefined new network identifications may also be employed that indicate corresponding networking events for building new blockchain subnets. For example, the subnet1 may be replaced by newsubnet, where newsubnet is a predefined newly created network identifier, and when it is identified that the data field contains newsubnet, the nodes a-nodeE can determine that the event containing newsubnet is a networking event, and a new blockchain subnet needs to be created.

In addition to the network identifier subnet1, the data field also contains identity information of each node member and other contents. The node equipment for deploying the first main network node can monitor the generated receipt, and acquire the configuration information or the creation block contained in the networking event by the node equipment for deploying the first main network node under the condition that the networking event is monitored and the content of the networking event indicates that the first main network node belongs to the node member. Or the first blockchain node may monitor the generated receipt, and trigger node equipment deploying the first blockchain node to acquire the configuration information or the creation block contained in the networking event when the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member.

As previously described, the node device may directly monitor the receipt. Assuming that the nodeA-nodeE are respectively disposed on the node devices 1-5, the node devices 1-5 can monitor receipts respectively generated by the nodeA-nodeE, and if the fact that the subnet1 is a newly constructed blockchain subnet is monitored, the node devices 1-5 further identify identity information of node members contained in the data field to determine a processing mode of the node devices. Taking nodeA and node device 1 as examples: if the node device 1 finds that the data field contains identity information such as a public key, an IP address, a port number and the like of the nodeA, the node device 1 generates an creation block containing the configuration information when obtaining the configuration information from the data field based on the message mechanism, and the node device 1 deploys the nodeA1 locally, so that the created block is loaded by the nodeA1, thereby becoming a subnet node of the subnet 1; similarly, node device 2 may generate nodeB1, node device 3 may generate nodeC1, and node device 4 may generate nodeD1. And the node device 5 finds that the identity information contained in the data field is not matched with the identity information, so that the node device 5 does not generate an creation block according to the configuration information in the data field and does not generate a blockchain node in the subnet 1.

As previously described, a blockchain node in the blockchain master network may monitor receipts and trigger the node device to perform related processing based on the monitoring results. For example, if it is determined that subnet1 is a blockchain subnet that needs to be newly constructed, nodeA-nodeE further identifies the identity information of the node member contained in the data field to determine its own processing mode. For example, nodeA-nodeD may find that the data field contains identity information such as its own public key, IP address and port number, and assume that nodeA-nodeD are deployed on node devices 1-4, respectively, taking nodeA and node device 1 as examples: the nodeA triggers the node device 1, so that the node device 1 obtains configuration information from the data field based on the message mechanism and generates an creation block containing the configuration information, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated creation block, thereby becoming 1 subnet node in the subnet 1; similarly, nodeB would trigger node device 2 to generate nodeB1, nodeC would trigger node device 3 to generate nodeC1, nodeD would trigger node device 4 to generate nodeD1. And nodeE finds that the identity information contained in the data field does not match with the identity information, and if nodeE is deployed on the node device 5, the node device 5 does not generate an creation block according to the configuration information in the data field, and does not generate a node in the subnet 1.

As mentioned above, the first main network node and the first sub network node do not necessarily use the same identity information. Thus, in the above embodiment, the data field may contain identity information generated in advance for the nodeA1 to nodeD1, and is different from the identity information of the nodeA to nodeD. Still taking nodeA and node device 1 as examples: the node device 1 can generate an creation block, deploy the nodeA1, and load the creation block by the nodeA1 if the identity information of the nodeA1 is found in the data field; or nodeA if the identity information of nodeA1 is found in the data field, nodeA triggers the node device 1 to generate an creation block, deploy nodeA1, and load the creation block by nodeA 1. The processing manners of other blockchain nodes or node devices are similar and are not described in detail herein.

In addition to the configuration information, the execution result of the contract may include an creation block. In other words, in addition to the configuration information contained in the data field, the generation block containing the configuration information may be directly generated in the process of executing the contract call, so that the generation block is contained in the data field, and for the nodeA-nodeD described above, the corresponding node device 1-4 may directly obtain the generation block from the data field through the message mechanism, without self-generation, and may improve the deployment efficiency of the nodeA 1-nodeD 1.

The node device enables deployment of a blockchain node on the node device by creating an instance of running blockchain platform code in the process. For a first master network node, creating, by a node device, a first instance in the process and running blockchain platform code from the first instance. Similarly, for a first subnet node, a second instance is created by the node device in the process described above that is distinct from the first instance and formed by the second instance running blockchain platform code. For example, a node device may first create a first instance in a process to form a first blockchain node in a blockchain master network; and when the node member corresponding to the node device wants to participate in the construction of the blockchain sub-network, a second instance can be created in the process, wherein the second instance is different from the first instance, and a second blockchain node in the blockchain sub-network is formed by the second instance. When the first instance and the second instance are located in the same process, because cross-process interaction is not involved, the deployment difficulty of the first subnet node can be reduced, and the deployment efficiency can be improved; of course, the second instance and the first instance may also be in different processes on the node device, which is not limited in this specification; for example, a node device may create a first instance in a first process to form a first blockchain node in a blockchain master network; when the node member corresponding to the node device wishes to participate in the construction of the blockchain sub-network, a second process different from the first process may be started, and a second instance may be created in the second process, where the second instance is different from the first instance, and further the second instance forms a second blockchain node in the blockchain sub-network. In fact, each blockchain node deployed on any node device involved in the embodiments of the present disclosure is a different blockchain instance running on the any node device, the blocks generated by each blockchain node deployed on any node device are respectively stored in different stores (such as databases) on the any node device, and the stores used by each blockchain node deployed on any node device are isolated from each other.

By the method, the blockchain sub-network can be created on the blockchain main network. Taking fig. 1 as an example, subnet0 originally includes nodes a-nodeE, and subnet1 can be built on the basis of subnet0, where subnet1 includes nodes a 1-nodeD 1, and nodes a and a1, nodes b and b1, nodeC and nodeC1, nodeD and nodeD1 are respectively deployed on the same node device. Similarly, a blockchain subnetwork of subnet2 or more can also be built on subnet0, where subnet2 contains nodeA2, nodeB2, nodeC2, and nodeE2, with nodeA and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC1 and nodeC2, nodeD and nodeD, nodeE and nodeE2 deployed on the same node device, respectively. And, subnet1, subnet2, etc. can be used as a new blockchain main network, and a blockchain sub-network is further constructed on the basis, and the process is similar to the construction of subnet1 or subnet2, and is not repeated here. Therefore, in the manner of initiating the transaction selection node member on the blockchain main network to create the blockchain sub-network, the sub-network nodes of the newly created blockchain sub-network can be deployed on the node device where the main network node of the blockchain main network is located, that is, from the perspective of the node device, the node device where the sub-network node of the blockchain sub-network is located belongs to the subset of the node device where the main network node is located, in other words, the node device where the sub-network node of the blockchain sub-network is deployed with the main network node in the blockchain main network.

In addition to creating the blockchain subnetwork by initiating transaction selection node members on the blockchain main network as described above, the blockchain subnetwork may be created by other means and subject to management by the blockchain main network. For example, a blockchain subnetwork may be built on the blockchain main network by a registration method (hereinafter referred to as a registration networking method), and the existing blockchain network may be directly registered to the blockchain main network, so that the newly registered blockchain network is managed by the blockchain main network, and thus the newly registered blockchain network becomes the blockchain subnetwork of the blockchain main network. The subnet information of the to-be-constructed blockchain subnet is directly registered to the blockchain main network in a registration networking mode, so that the blockchain main network obtains the related information of the to-be-constructed blockchain subnet (by receiving and executing the transaction sent by the to-be-constructed blockchain network for carrying out the association and verification of the identity information of the to-be-constructed blockchain subnet and the subnet identification distributed to the to-be-constructed blockchain network), such as the subnet identification and the running state of the to-be-constructed blockchain subnet, wherein the public key and the plug-in configuration information of each node member, the IP address and the port information of each node device and the like are written into the contract state of the system contract corresponding to the blockchain main network, and therefore, the blockchain main network obtains the management right of the to-be-constructed blockchain subnet, and after registration is completed, the blockchain subnet is constructed. Because the registration networking manner does not need to designate node members on the blockchain main network to form a blockchain sub-network through transactions, the sub-network nodes in the blockchain sub-network formed through the registration networking manner may be completely different or partially different from the node devices deployed in each node in the blockchain main network, for example, in fig. 1, the sub-network 0 creates a sub-network 4 (not shown in fig. 1) in the registration networking manner, and assuming that the main network nodes nodeA-nodeE included in the sub-network 0 are respectively deployed on the node devices 1-5, the sub-network nodes corresponding to the sub-network 4 may be deployed on any node device other than the node devices 1-5, or one or more sub-network nodes in the sub-network 4 may be respectively deployed on any node device in the node devices 1-5 (but still it is required to ensure that only one sub-network node in the sub-network 4 is deployed on one node device), and other sub-network nodes in the sub-network 4 are deployed on any device other than the node devices 1-5, and of course, all sub-network nodes in the sub-network 4 may be deployed on any node device 1-5.

As shown in fig. 1, for any blockchain network (called a first blockchain network) in a blockchain system formed by a blockchain main network and a blockchain sub-network managed by the blockchain main network, each blockchain node included in the blockchain network independently maintains a distributed ledger formed by sequentially connecting a plurality of blocks, and each block has a corresponding block height for indicating the relative position of the block in the distributed ledger, for example, the block with the largest current block height maintained by a blockchain node is the block obtained by the latest consensus or synchronization of the blockchain node. And, as transactions in the first blockchain network are initiated, agreed upon and executed, new blocks are continually generated and updated into the distributed ledgers maintained by the blockchain nodes.

Under normal circumstances, each blockchain node in the first blockchain network continuously updates its own maintained distributed ledger according to the consensus protocol, which makes the distributed ledger maintained by each blockchain node strictly consistent, but when the blockchain node is down and restarted or a new blockchain point is added, it will inevitably cause blocks in the distributed ledger maintained by part of the blockchain nodes to lag other blockchain nodes in the first blockchain network, i.e. the block heights of the locally latest blocks maintained by the blockchain nodes lag the block heights of the actually latest blocks in the first blockchain network. In the embodiment of the present disclosure, the block height of the local latest block is referred to as a local block height, the block height of the actual latest block is referred to as a latest block height, the block chain nodes in the first block chain network in which the local block height of the maintained local latest block lags behind the latest block height are referred to as lag nodes, and the block chain nodes in the first block chain network in which the local block height of the maintained local latest block is the same as the latest block height are referred to as normal nodes.

Because the blocks need to be integrated and updated to the distributed ledger in sequence, for the lagging node, the lagging node cannot participate in the consensus and processing of the actual latest block in the first blockchain network as the normal node, namely cannot participate in the normal consensus process, so that the operation of functions and services on the lagging node and even the whole first blockchain network is affected, and therefore, how to enable the lagging node to acquire the lagging block as soon as possible to complete the block following process is a problem to be solved in the scene.

In order to solve the problem, the present disclosure proposes a block synchronization method, by periodically sending, by a lagging node, a block synchronization request for a lagging block to a normal node in a first blockchain network, where the actual latest block is maintained, according to the dynamic request period, where the dynamic request period is negatively related to the lagging degree between the local block height and the latest block height of the actual latest block of the first blockchain network, and is negatively related to the size of a node weight factor corresponding to the lagging node, so as to increase the number of valid requests of the lagging node with more lagging blocks, so that the lagging node with a larger lagging degree can complete the block tracking process more quickly, and meanwhile, the design of the node weight factor can also play a role in macro-regulating the block synchronization rate of each lagging node.

The block synchronization method according to the present specification will be described in detail with reference to fig. 2. Fig. 2 is a flowchart of a block synchronization method according to an exemplary embodiment. The method is applied to a first blockchain node in a first blockchain network in a blockchain system, wherein the blockchain system comprises a blockchain main network and a blockchain sub-network managed by the blockchain main network, the first blockchain node dynamically maintains the local block height of a local latest block and a dynamic request period, and the dynamic request period is negatively related to the degree of lag between the local block height and the latest block height of the actual latest block of the first blockchain network and is negatively related to the size of a first node weight factor corresponding to the first blockchain node; the method comprises the following steps:

S202: and periodically sending a block synchronization request for a lagging block to a normal node maintaining the actual latest block in a first blockchain network according to the dynamic request period under the condition that the local block height is behind the latest block height, wherein the block height of the lagging block is between the local block height and the latest block height.

The first blockchain network according to embodiments of the present disclosure may include the blockchain main network described above or a blockchain subnetwork managed by the blockchain main network, such as the subnet0, the subnet1, or the subnet2 described in fig. 1.

The actual latest block in the first blockchain network according to the embodiments of the present disclosure refers to the block height of the block that the first blockchain network has last passed through the consensus, and since the block consensus is processed (transactions in the block are performed) by all normal nodes and updated to the distributed ledger maintained by the block, the actual latest block in the first blockchain network is also equivalent to the block with the largest block height among the blocks maintained by the blockchain nodes in the first blockchain network.

Since normal nodes also have the possibility of becoming lagging nodes, for any blockchain node in the first blockchain network, the blockheight of the latest block maintained locally by the node is periodically queried from other blockchain nodes, and once the local blockheight maintained by the node is found to be smaller than the blockheight of the latest block maintained by other blockchain nodes, the node is considered to belong to the lagging node, otherwise, if the local blockheight maintained by the node is found to be greater than or equal to the blockheight of the latest block maintained by other blockchain nodes, the node is considered to belong to the normal node.

In this embodiment of the present specification, the first block link point may maintain and update the latest block height by: periodically sending a latest height request to the normal node according to a preset request period, and receiving the latest block height returned by the normal node in response to the latest height request; or receiving the latest block height returned by the normal node in response to the block synchronization request. In this case, the update process of the latest block height is independent from the block synchronization process described in the embodiment of the present specification, and the preset request period may be set as the dynamic request period; or the first blockchain node can integrate the updating process of the latest block height into the block synchronization process described in the embodiment of the present specification, so that after the first blockchain node sends a block synchronization request to the normal node, the first blockchain node obtains the latest block height returned by the normal node in response to the block synchronization request.

The local latest block according to the embodiment of the present disclosure, that is, the latest block obtained by the first blockchain node through consensus or obtained by block synchronization and maintained locally, determines that the local latest block belongs to the lagging node when the first blockchain node detects that the local block height is behind the latest block height (the local block height is smaller than the latest block height), and therefore periodically starts to send a block synchronization request to the normal node in order to acquire the lagging block. The period of periodically sending the block synchronization request, that is, the dynamic request period maintained on the first blockchain node, is negatively related to the lag degree between the local blockheight and the latest blockheight of the actual latest block of the first blockchain network, which means that the dynamic request period can be sent to change along with the change of the local blockheight or the latest blockheight, for example, the first blockchain node sends a change to the local latest block maintained by the first blockchain node every time the first blockchain node gets a new lag block in synchronization, so the lag degree between the local blockheight and the latest blockheight also sends a change, and at this time, the first blockchain node also needs to update the dynamic request period maintained locally synchronously.

Because the dynamic request period minus is related to the degree of lag between the height of the local block and the height of the latest block of the actual latest block of the first blockchain network, the larger the degree of lag of the first blockchain node (namely the degree of lag between the height of the local block of the first blockchain node and the height of the latest block), the shorter the dynamic request period is, which means that the number of times (effective request times) that the first blockchain node sends the block synchronization request to the normal node in unit time when the degree of lag is larger is more frequent, and the effective request times is slowly reduced as the degree of lag of the first blockchain node gradually reduces, and the block request number corresponding to the block synchronization request is often limited, which means that the block synchronization request cannot generally directly finish the block following process. Therefore, the control of the effective request times is equivalent to distinguishing the block synchronization rates of the laggard nodes with different laggard degrees, so that the laggard nodes with larger laggard degrees, namely, the laggard nodes with larger block synchronization requirements, can complete the block synchronization more quickly, the proportion of the laggard nodes with larger laggard degrees in the first block chain network in all the laggard nodes is reduced as a whole, the laggard nodes can complete more balanced synchronization block following, and a more intelligent dynamic block synchronization strategy is realized.

Meanwhile, the dynamic request period is also negatively related to the size of the first node weight factor corresponding to the first block chain link point, so that the block synchronization rate of the first block chain node can be adjusted in weight dimension. For example, the first node weight factor may be recorded in a contract state of an intelligent contract in the first blockchain network, and the intelligent contract may be updated after being invoked by an administrator or other users of the first blockchain network, so that the first blockchain node may dynamically adjust its own dynamic request period by reading the continuously updated first node weight factor on the intelligent contract, which means that the node weight factors corresponding to each blockchain node in the first blockchain network are the same, that is, macroscopic regulation of the dynamic request period at the network level is achieved; for another example, the first node weight factor is provided by the first node device where the first blockchain node is located, in this case, the first node device calculates the first node weight factor corresponding to the first blockchain node by referring to the deployment situation of the local blockchain node, and provides the first node weight factor to the first blockchain node, so that the first blockchain node can dynamically adjust its dynamic request period by continuously updating the size of the first node weight factor by the first node device, that is, macroscopic regulation of the dynamic request period at the node level is realized.

In an embodiment corresponding to macro regulation at the node level, the first node weight factor may be determined as a ratio of a node weight corresponding to the first blockchain node to a sum of node weights of all blockchain nodes deployed on the first node device where the first blockchain node is located. In this embodiment of the present disclosure, the first node device may be configured with other blockchain nodes (for example, a main network node or a subnet node) in addition to the first blockchain node, and the first node device may maintain a node weight list, where the node weight list records the node weight corresponding to each blockchain node locally configured by the first node device, and then when the first node device needs to calculate the node weight factor of any blockchain node locally configured, the node weight corresponding to any blockchain node only needs to be divided by the sum of the node weights of all locally configured blockchain nodes. Taking fig. 1 as an example, if the first blockchain network is subnet1, the first blockchain node is nodeA1 in subnet1, the first node device is node device 1 where nodeA is located, the node weight list maintained by node device 1 includes node weights corresponding to nodeA, nodeA1 and nodeA2 deployed by node device 1, for example, the node weight of nodeA is 1, the node weight of nodeA1 is 2, and the node weight of nodeA2 is 3, and the node weight factor of nodeA1 that can be calculated by node device 1 is 2/(1+2+3) =1/3. Because the computing resources of the node devices are limited, in the embodiment of the present disclosure, it may be ensured that an upper bound exists in the sum of node weight factors of all the blockchain nodes on the first node device, so as to adapt to the upper limit of performance that the first node device can support on the blocksynchronous task, and prevent the phenomenon that the first node device crashes due to sending a large number of blocksynchronous requests and receiving the lagging blocks when the blockchain nodes on the first node device all belong to the lagging nodes.

In another embodiment, the first node weight factor may also be determined as a ratio of a node weight corresponding to the first blockchain node to a sum of node weights of all blockchain nodes in a blocklag state deployed on the first node device where the first blockchain node is located. In the embodiment of the present disclosure, when calculating the first node weight factor corresponding to the first blockchain node, only the node weight of the first blockchain node and the node weights of nodes belonging to the laggard nodes in the respective blockchain networks deployed on the first node device need to be considered. Still taking fig. 1 as an example, if the first blockchain network is subnet1, the first blockchain node is nodeA1 in subnet1, the first node device is node device 1 where nodeA is located, the node weight list maintained by node device 1 includes node weights corresponding to nodeA deployed by node device 1, nodeA1 and nodeA2, if nodeA currently belongs to a normal node in subnet0, no block-following (block synchronization) is needed, and nodeA1 and nodeA2 both belong to a following node in subnet1 and subnet2 where they are located, and the node weight factor of nodeA1 calculated at this time is 2/(2+3) =0.4. In the embodiment of the present disclosure, when there is a blockchain node in the first node device that does not need to perform block tracing, the blocksynchronization rate of the blockchain node in the first blockchain node that needs to perform block tracing may be increased, so as to dynamically maintain the blocksynchronization rate of each blockchain node deployed in the first node device, and utilize the upper performance limit that the first node device can support on the blocksynchronization task as much as possible.

The node weight corresponding to each blockchain node in the node weight list maintained by the first node device may be a network weight corresponding to a blockchain network to which the respective blockchain node belongs, and the network weights may be recorded in a subnet management contract of the blockchain main network and obtained by the first node device reading a locally deployed main network node. Taking fig. 1 as an example, if the first blockchain network is subnet1, the first blockchain node is nodeA1 in subnet1, the first node device is nodeA1, then the node device 1 may obtain the network weights of the blockchain main network and the blockchain subnets managed by the blockchain main network from the locally deployed main network node nodeA, for example, the network weight of subnet0 is 1, the network weight of subnet1 is 2, and the network weight of subnet2 is 3, then the node device 1 further assigns and designates the node weights for the locally deployed blockchain nodes, designates the node weights of nodeA as the network weights of the blockchain network subnet0 to which nodeA belongs, designates the node of nodeA1 as the network weights of the blockchain network subnet1 to which nodeA1 belongs, indicates the node weights of nodeA2 as the network weights of subnet2, and finally records the node weights in a local maintenance weight list. In this way, the combination of the macro regulation of the network level and the macro regulation of the node level is equivalent, so that the maintenance strategy of the dynamic request period of the finally realized blockchain system can realize the unified regulation of a plurality of blockchain nodes on the network level, and can also make differential local optimization on different node devices so as to meet the performance requirements of different node devices. Of course, the network weights of any blockchain network may also be recorded in the intelligent contracts of the any blockchain network, and the first node device obtains the network weights through the blockchain nodes in the any blockchain network deployed locally.

As described above, the local block height of the local latest block maintained by the lagging node is smaller than the latest block height of the actual latest block, which means that the first blockchain node does not maintain the actual latest block in the case that the first blockchain node detects that the first blockchain node itself belongs to the lagging node, and the block that the first blockchain node lacks in comparison with the normal node at the same time is referred to as a lagging block, the allowed block height of which is between the local block height of the latest block (i.e., the local latest block) maintained locally by the lagging node and the latest block height, and the lagging block contains the actual latest block but does not contain the local latest block.

The block synchronization request according to the embodiments of the present disclosure may include the identity information of the first blockchain node, the source communication address, the destination communication address, and the block range of the backward block required to be requested, where the block range is determined by the block height, for example, the block height of the block in the first blockchain node is 1500, and the block range indicated by the block synchronization request in the last instance is 2000, where the upper limit of the number of block requests corresponding to the single blocksynchronization request is 100, then the first blockchain link point sends the block synchronization request of the normal node, the block range of the backward block carried in the block synchronization request of the normal node may be (1500,1600), which indicates that the block height requested by the normal node is 100 blocks from 1501 to 1600, and of course, or (1900,2000), in particular, in the case that the block range of the backward block requested by the first blockchain node does not start continuously from the block height of the block in the first blockchain node, for example, the block range indicated by the block synchronization request in the first instance is 1900,2000, where the first blockchain point will receive the block height of 1901 to 2000, but the first blockchain point is 100 blocks, and then the first blockchain node is a block in the first order of the second blockchain node, and the second blockchain node is a higher order than the first blockchain node (which receives the first blockchain from the first blockchain node and the second blockchain node is normally a second blockchain node, and the normal blockchain is up to the normal, and the first blockchain is up to the normal, and the normal blockchain is up and the normal, and the first blockchain is up and the normal is up to the normal, and the normal blockdown is up and the normal is up and the up to the normal blockdown is up and the normal is up and the processing to the first blockdown is up and the first blockdown, thereby completing the block-chasing process faster by requesting multiple normal nodes.

In this embodiment of the present disclosure, the normal node may first verify the identity information of the first blockchain node, for example, if the identity information included in the blockchain node is signature information obtained by signing, by the first blockchain node, other contents of the blockchain node except the identity information through a private key of the first blockchain node, the normal node may verify the signature information based on the node public key corresponding to the first blockchain node, and confirm that the identity of the first blockchain node is legal if the verification is successful.

S204: and receiving the lagging block returned by the normal node in response to the block synchronization request so as to redetermine the local latest block and the dynamic request period.

As described above, after detecting that the first blockchain node belongs to the laggard node, the first blockchain node periodically sends a blocksynchronization request to the normal node according to the dynamic request period, that is, the first blockchain node sends a blocksynchronization request to the normal node after each waiting for one dynamic request period, for the blocksynchronization request sent by each period of the first blockchain node, the normal node responds and returns the corresponding laggard block, so that the first blockchain node updates the local latest block, and because the dynamic request period negatively correlates with the laggard degree between the height of the local block and the height of the latest block of the actual latest block of the first blockchain network, the first blockchain node can synchronously update the dynamic request period maintained locally, and uses the updated dynamic request period as the period of the next waiting for sending the blocksynchronization request. In the embodiment of the present disclosure, the first blockchain node updates the local latest block and the dynamic request period once every period, so as to intelligently and dynamically adjust the frequency of the request blocks of the first blockchain node itself.

Optionally, the dynamic request period is determined by:

Searching a lagging interval corresponding to the lagging degree, and determining the dynamic request period as the ratio of the numerical value corresponding to the lagging interval to the first node weight factor. In this embodiment of the present disclosure, the dynamic request period may be determined according to the lag interval corresponding to the lag degree and the first node weight factor, and specifically, different lag intervals may be searched to obtain the corresponding standard request period, where the dynamic request period is equal to the ratio of the standard request period to the first node weight factor. For example, when the lag level is specifically the difference between the local block height and the latest block height (i.e. the lag block number), the relationship between the standard request period and the lag block number is shown in table 1:

/>

TABLE 1

As can be seen from table 1, when the number of the backward blocks is within the interval (including both ends) from 0 to 100, the standard request period corresponding to the interval can be found to be 1000ms, and if the value of the first node weight factor is 2, the dynamic request period can be determined to be 500ms; similarly, when the number of the backward blocks is in the interval of 101 to 1000, firstly searching to obtain a standard request period of 500ms, and dividing the standard request period by a first node weight factor to obtain a dynamic request period of 250ms; when the number of the lagging blocks exceeds 1000, the standard request period is found to be 200ms, and then the dynamic request period is further determined to be 100ms.

Or the dynamic request period is determined by: calculating the product of a fixed request period and a lag factor corresponding to the lag degree, and determining the dynamic request period as the ratio of the product to a first node weight factor, wherein the lag factor comprises: dividing the maximum number of blocks allowed by a single block synchronization request by the difference between the local block height and the latest block height; or the ratio of the local block height to the latest block height.

In the embodiment of the present specification, the dynamic request period needs to be obtained by the calculation formula: dynamic request period p=p0×f/d, where P0 represents a fixed request period, the value being specified by the administrator and not changing before being modified as a fixed value, f represents a lag factor, the parameter being directly related to the lag degree, and d represents the first node weight factor.

For example, f=m/(Hn-Hl), where M represents the maximum number of blocks allowed by a single block synchronization request (upper limit of the number of block requests), hn represents the latest block height, hl represents the local block height, and in this embodiment of the present disclosure, the backward extent of the first blockchain node is specifically the difference between the local block height and the latest block height, and obviously, the larger the number of backward blocks (i.e., the larger Hn-Hl), the smaller the backward factor f, and the smaller the dynamic request period P, i.e., the dynamic request period is inversely related to the backward extent.

As another example, f=h1/Hn, in the embodiment of the present disclosure, the degree of the lag of the first blockchain node is specifically the ratio between the local blockheight and the latest blockheight, and it is obvious that the greater the degree of the lag, the smaller the lag factor f, and the smaller the dynamic request period P, and the negative the dynamic request period is related to the degree of the lag.

Optionally, the lag factor is provided with an upper factor bound for redefining the lag factor as the upper factor bound if the lag factor exceeds the upper factor bound and/or a lower factor bound for redefining the lag factor as the lower factor bound if the lag factor is below the lower factor bound. In the embodiment of the present disclosure, the value range of the lag factor is limited, so that the value range of the dynamic request period is indirectly limited, so as to meet the actual requirement of the block synchronization task. For example, in the case of f=m/(Hn-Hl), if the difference between the local block height and the latest block height does not exceed the maximum number of blocks allowed by a single block synchronization request, f determined by the first blockchain node may be too large to cause the final determined dynamic request period P to be too large to normally complete the block tracking process, and in order to avoid this, a factor upper bound of 1 may be set for f, so that when the difference between the local block height and the latest block height does not exceed the maximum number of blocks allowed by a single block synchronization request, f calculated by the first blockchain node is greater than 1, but is redetermined to be 1 due to the factor upper bound, so that a reasonable maximum value exists for the dynamic request period to ensure that the lagging node can normally complete the block tracking process.

Optionally, the dynamic request period is provided with a period upper bound and/or a period lower bound, the period upper bound is used for redefining the dynamic request period as the period upper bound if the dynamic request period exceeds the period upper bound, and the period lower bound is used for redefining the dynamic request period as the period lower bound if the dynamic request period is lower than the period lower bound. As described above, the range of the dynamic request period may be indirectly limited by limiting the range of the lag factor, and in the embodiment of the present disclosure, the range of the dynamic request period may also be directly limited so as to meet the actual requirement of the block synchronization task.

Optionally, the upper period boundary includes a fixed period upper boundary or a dynamic period upper boundary, and the lower period boundary includes a fixed period lower boundary or a dynamic period lower boundary. Wherein the dynamic period upper bound comprises: a ratio of a maximum number of blocks allowed for a single block synchronization request to a block growth rate of a first blockchain network; the dynamic period lower bound includes: the difference between the number of blocks required for the block synchronization request and the maximum number of blocks currently remaining in the local memory is divided by the local block processing speed. In the embodiment of the present disclosure, the upper period boundary and/or the lower period boundary may be set to a fixed value, which is referred to as a fixed period upper boundary and/or a fixed period lower boundary, and may be set to a dynamic value, which is referred to as a dynamic period upper boundary and/or a dynamic period lower boundary.

Since the block synchronization scheme according to the embodiments of the present disclosure does not affect the original block consensus process of the first blockchain network during the implementation process, this means that during the block synchronization process, the first blockchain network will also generate new blocks, and the latest block height corresponding to the first blockchain network will be continuously increased, that is, there is an objective block growth rate of the first blockchain network, where the block growth rate may be obtained by the first blockchain node by detecting the rate of change of the latest block height, and the block growth rate is a dynamically changing value. If the maximum number of blocks allowed by a single block synchronization request is M, if the dynamic request period is too large, it may result in that the number of blocks naturally growing in the first blockchain network in one dynamic request period that is waiting cannot be caught up even if M blocks are requested by each synchronization request, so that any lagging node cannot catch up with the blocks maintained by the normal node, and thus, the lagging block can theoretically complete the block catch-up process by setting the dynamic period upper bound to the ratio of the maximum number of blocks allowed by the single block synchronization request to the block growth speed of the first blockchain network.

In this embodiment of the present disclosure, after receiving the backward blocks returned by the normal node, the first blockchain node needs to process the blocks in order of block height from low to high, that is, the transactions contained in the blocks are self-processed, and then updated to the locally maintained distributed ledger, so that for the first blockchain node, there is an objective local block processing speed, and meanwhile, the first blockchain node also allocates a memory space dedicated to storing unprocessed blocks, the first blockchain node will buffer the received backward blocks in the memory space first, and each time a block is processed, the processed block will be removed from the memory space to make room for storing more blocks. If the dynamic request period is too small, the received late blocks cannot be completely cached in the memory space, so that the phenomena of memory overflow and block loss occur, which is essentially that the number of blocks requested exceeds the limit that can be accommodated by the current memory, and in order to avoid such phenomena, it is theoretically required to ensure that the number of blocks required by a certain block synchronization request does not exceed the maximum number of blocks remaining in the current local memory (obtained by dividing the remaining memory capacity by the average size of a single block), however, since the block synchronization request is already generated at the beginning of waiting for a dynamic request period, a part of blocks are processed and removed from the memory space during waiting for a dynamic request period, which means that assuming that the number of blocks required by a newly determined block synchronization request in a certain period is M1, the maximum number of blocks currently remaining in the local memory determined at the beginning of a new waiting period is Z, and the local block processing speed v is only required to satisfy M1. Gtoreq.z-vP, that is required by the dynamic request required by the current waiting period should satisfy p.gtoreq.m 1/v. Therefore, the dynamic period can be set to be the difference between the number of blocks required by the block synchronization request and the maximum number of blocks currently remaining in the local memory divided by the local block processing speed, so that the phenomena of memory overflow and block loss are prevented, and the memory space vacated by block processing when waiting for one dynamic request period is utilized to the maximum extent.

Optionally, the first block link point maintains a network topology structure between node devices where each main network node in the block chain main network is located and network delay information corresponding to the network topology structure, and a main network node is further deployed on a node device where a sub-network node in the block chain sub-network is deployed; the first blockchain node sending the blocksynchronization request to the normal node, including: and determining a forwarding path with minimum total delay between first node equipment where a first blockchain node is located and target node equipment where a normal node is located from the network topological structure based on the network delay information, and forwarding the blocksynchronous request to the normal node according to the determined forwarding path.

In this embodiment of the present disclosure, any one of the blockchain nodes in the first blockchain network is disposed in a different hardware entity, which is called a node device, and the blockchain node refers to a software process running in the node device, as in the network architecture shown in fig. 1, where different blockchain nodes in any one blockchain network are disposed on different node devices, and the network link between the blockchain nodes is substantially a network link between the corresponding node devices. Therefore, in the case that the first blockchain network is the blockchain main network subnet0, for example, for the first blockchain link point nodeC, it is assumed that it needs to send a message to other main network nodes in the subnet0, for example, nodeE, and only needs to send the message from the node device 3 at nodeC to the node device 5 at nodeE, so that the corresponding message transmission can be completed.

Since the first blockchain point needs to forward the blocksynchronization request to the normal node, the first blockchain point needs to know the routing information from the first node device where the first blockchain node is located to the target node device where the normal node is located. In the embodiment of the present disclosure, the first blockchain node forwards, by using, as route information, a forwarding path with the smallest total delay between the obtained first node device and the located target node device, a blocksynchronous request to a node device serving as a next hop in the forwarding path, and forwards the blocksynchronous request to the target node device step by step.

Because the first node device is configured with the main network node, the first node device can generate a network topology structure between the node devices configured with the main network node by inquiring the network connection relation of the main network nodes in the blockchain main network, and because the blockchain main network manages the subnet information of the blockchain subnets, the network topology structure maintained by the first node device comprises the identity information of each node member in any blockchain subnet, the node device and the like, and besides the network connection relation between the node devices, the network topology structure also comprises the condition of the subnet nodes configured on each node device, namely the network topology structure comprises the whole network structure of the blockchain system formed by the blockchain main network and each blockchain subnet.

The network topology structure according to the embodiment of the present disclosure refers to a connection relationship between node devices where each main network node is located in a blockchain main network, and is generated based on a network connection relationship between each main network node in the blockchain main network, and may be represented in a graphical form. FIG. 3 is a schematic diagram of a network topology for characterizing blockchain node deployment on node devices and network link conditions between node devices, as shown in FIG. 3, in accordance with an exemplary embodiment. Therefore, the connection relationship between the node devices shown in fig. 3 may be regarded as a representation for representing the above-described network topology, and of course, the above-described network topology may be represented in a matrix or table form, without any limitation.

The network delay information corresponding to the network topology structure according to the embodiment of the present disclosure includes: link delays of network links in the network topology and/or node delays of node devices in the network topology when forwarding messages. As shown in fig. 3, the link delay of each network link and the node delay of each node device included in the network topology. Wherein, the link delay of the network link refers to the time delay information required for forwarding the message on the network link, for example, the link delay of the network link between the node device 1 and the node device 2 in fig. 3 is 100; the node delay of the node device refers to delay information required from entering the node device to forwarding from the node device, and specifically includes processes of analyzing, checking a routing table and forwarding the message by the node device, for example, in fig. 3, the node delay of the node device 1 is 3, and the forwarding delay of the node device 4 is 5. In the embodiment of the present disclosure, the values corresponding to the link delay and the node delay may represent specific delay durations, or may represent other delay indexes having relevance to the specific delay durations, where a unified unit is required between the link delay and the node delay. For example, the link delay 100 of the network link between node device 1 and node device 2 may be understood as 100 milliseconds (ms), i.e. the characterization message needs to pass through the network link for 100ms, then the node delay 3 of node device 1 should be understood as 3ms.

The forwarding path with the smallest total delay between the first node device where the first blockchain node is located and the target node device where the normal node is located according to the embodiment of the present disclosure is determined by a network topology structure between node devices where each main network node in the blockchain main network is located and network delay information corresponding to the network topology structure. Specifically, when the first blockchain node needs to send a blocksynchronous request to the normal node, a forwarding path with the minimum total delay between the first node device and the target node device can be determined through the network topology structure and the network delay information which are maintained locally.

In the embodiment of the present disclosure, although the first blockchain node maintains the network delay information, the network delay information is actually maintained in the first node device where the first blockchain node is located, and is updated and maintained by the first node device, and a method for determining and updating the network delay information maintained by the first node device will be described in detail later, where the first blockchain node only reads the network delay information from the first node device where the first blockchain node is located, and similarly, the network delay information maintained by other blockchain nodes is also read from the node devices where the other blockchain nodes are located.

Because the network topology structure maintained by the first blockchain node includes network link connection relations among node devices, the first blockchain node can generate a forwarding path between the first node device and the target node device under the condition of determining the relative network position relation between the first node device and the target node device where the first blockchain node is located in the network topology structure and ensuring accessibility. Taking fig. 3 as an example, assuming nodeC is a first blockchain node, nodeE is a normal node, now nodeC detects that the node belongs to a laggard node and has waited for a dynamic request period, it needs to send a blocksynchronous request to nodeE, nodeC needs to determine, based on the network topology maintained by itself, a forwarding path between node device 3 (first node device) nodeC and node device 5 (target node device) nodeE, it is apparent that, according to the network topology, there is no directly connected network link between node device 3 and node device 5, and in the forwarding path without considering loop and original return, the forwarding path between node device 3 and node device 5 includes two forwarding paths: firstly, the node equipment 3, the node equipment 1, the node equipment 2 and the node equipment 5; the second is node equipment 3, node equipment 1, node equipment 4, node equipment 2 and node equipment 5.nodeC, after determining the two optional forwarding paths, determining a forwarding path with the smallest total delay between the node device 3 and the node device 5 from the two optional forwarding paths based on the network delay information, where the total delay corresponding to the forwarding path is a sum of link delays of at least one section of network link routed from the first node device to the target node device on the forwarding path and/or node delays of at least one node device routed (excluding the first node device and the target node device). Thus, the first blockchain node may calculate only link delays of all network links routed from the first node device to the target node device, may calculate only node delays of all node devices routed from the first node device to the target node device, and may also consider both link delays of all network links routed from the first node device to the target node device and node delays of all node devices of the path when determining the total delay of the forwarding path. For example, taking fig. 3 as an example, since the total delay of all network links and all node devices of the forwarding path of node device 3→node device 1→node device 2→node device 5 is 166, and the total delay of all network links and all node devices of the forwarding path of node device 3→node device 1→node device 4→node device 2→node device 5 is 131, the forwarding path finally determined by nodeC is node device 3→node device 1→node device 4→node device 2→node device 5, so that nodeC can further determine node device 1 as the next hop in the forwarding path, and thus forward the block synchronization request to node device 1.

After the node device 1 receives the block synchronization request, the network topology structure and the network delay information maintained by the nodeA deployed on the node device 1 can determine a forwarding path with the shortest total time delay between the node device 1 and the node device 5 again, the newly determined forwarding path carries out secondary forwarding on the block synchronization request, and the node device which subsequently receives the block synchronization request also determines the new forwarding path firstly and then forwards the block synchronization request according to the newly determined forwarding path according to the same flow; or nodeC when forwarding the block synchronization request to the node device 1, the forwarding path determined by nodeC may also be carried in the block synchronization request, and after the node device 1 receives the block synchronization request, the node device 1 may continue to find the node device of the next hop as the node device 4 based on the forwarding path carried in the block synchronization request, and forward the block synchronization request to the node device 4, where the node device 4 and the subsequent node devices continue to forward the block synchronization request according to the same flow until the block synchronization request is forwarded to the node device 5. After receiving the block synchronization request, the node device 5 further forwards the block synchronization request to the locally deployed nodeE, so as to complete the whole process of sending the block synchronization request to the normal node.

In this embodiment of the present disclosure, the network delay information includes a link delay of a near-end network link in the network topology and/or a link delay of a far-end network link, where the near-end network link is a network link between a first node device and a neighboring node device, and the far-end network link is a network link in the network topology other than the near-end network link. The neighbor node devices of the first node device refer to node devices directly connected with the first node device through a section of network link, taking fig. 3 as an example, the neighbor node devices corresponding to the node device 1 include node device 2, node device 3 and node device 4, and the neighbor node devices of the node device 4 include node device 1 and node device 2.

For the first node device, it maintains two different types of network links, including a near-end network link and a far-end network link. The near-end network link refers to a network link directly connected with the first node device, namely, a network link between the first node device and the neighbor node device; the remote network link refers to a network link that is not directly connected to the first node device, that is, a network link in the network topology except for a near-end network link corresponding to the first node device. Still taking fig. 3 as an example, the near-end network links corresponding to the node device 1 include network links between the near-end network links and the node device 3, the node device 4 and the node device 5, and the far-end network links corresponding to the node device 1 include network links between the node device 1 and the node device 2, between the node device 4 and the node device 2, and between the node device 2 and the node device 5.

The first node device obtains link delay according to different strategies according to different types of network links. The first node equipment determines the link delay of the near-end network link according to the local link delay and/or the opposite link delay; the local link delay is obtained by detecting the near-end network link through a request response mechanism by a first node device, and the opposite link delay is obtained by detecting the near-end network link through a request response mechanism by a neighbor node device of the first node device; and/or receiving the link delay of the remote network link sent by the neighbor node device of the first node device, wherein the link delay of the remote network link is determined by the link delay obtained by detecting the remote network link by at least one end node device of the remote network link through a request response mechanism.

The request response mechanism related to the embodiment of the present specification relates to interaction between a requester and a responder, and considers that an initiator of the request response mechanism is the requester, and the request response mechanism is specifically implemented by the following manner: the request sends a request message carrying a time t1 to the responder, and t1 is the local time of the requester when the requester sends the request message. After receiving the request message, the responder records the local time t2 of the responder when the responder receives the request message, and returns the response message generated in response to the request message to the requester, and simultaneously carries time t2 and time t3 in the response message, wherein t3 is the local time of the responder when the responder returns the response message, which is recorded by the responder. Finally, after the request party acquires the response message, the local time T4 of the request party when the response message is received is recorded, then T2 and T3 are extracted from the acquired response message, and then t0= [ (T4-T1) - (T3-T2) ]/2 is calculated and is determined as the link delay T0 of the network link between the request party and the response party. In order to avoid interference of forwarding delays of the transit devices, no other transit devices exist between the requesting party and the answering party. The request message and the response message involved in the request response mechanism may be dedicated messages dedicated to calculating the link delay, or may be other normal service requests, or heartbeat messages in the network, and since the local processing time t3-t2 of the responder is taken into account when calculating the link delay, any type of request message and response message may be applied to the request response mechanism to enable the requester to measure the related link delay.

In the illustrated embodiment, the first node device may be determined by the request reply mechanism described above when determining the link delay of the near-end network link. For example, the first node device may actively initiate a request reply mechanism to its neighboring node device, thereby determining a link delay of a near-end network link between the first node device and the neighboring node device, where the link delay of the near-end network measured by the first node device through the request reply mechanism is referred to as a local link delay. On the other hand, since for any network link, both end devices included in the network link can measure the link delay of the network link by initiating the request response mechanism, the first node device can also directly obtain the link delay of the near-end network link by receiving the link delay of the near-end network link between the first node device and the neighboring node device, which is measured by the neighboring node device and provided to the first node device, which is called the opposite-end link delay. In summary, the first node device may obtain the link delay of a certain near-end network link by two means, so that it may also select between the two means or comprehensively consider the two means, for example, the link delay of the near-end network link finally determined by the first node device and recorded in the network delay information may include: the home link delay, the peer link delay, or a weighted average of the home link delay and the peer link delay. Wherein the network delay information maintained by the first node device may be made more robust in case the link delay of the near-end network link is determined as a weighted average of the local link delay and the opposite link delay.

Taking fig. 3 as an example, assuming that the local link delay of the near-end network link between the node device 1 and the node device 2 measured by initiating the request response mechanism is 102 and the opposite link delay of the near-end network link measured by initiating the request response mechanism is 98, for the node device 1, it may directly determine the local link delay 102 measured by itself as the link delay of the near-end network link between the node device 2 or determine the opposite link delay 98 measured by the node device 2 received from the node device 2 as the link delay of the near-end network link, and may determine the average value 100 of the local link delay and the opposite link delay as the link delay of the near-end network link according to the weight ratio of 1:1, and record it in the network delay information maintained locally by the node device 1.

Because the first node device can only directly measure the link delay of the near-end network link with the neighboring node device, but cannot measure the link delay of the far-end network link, the link delay sharing message including the link delay of the far-end network link sent or forwarded by the neighboring node device needs to be received, so that the link delay of the far-end network link is directly obtained and recorded to the corresponding far-end network link in the network delay information. In the embodiment of the present disclosure, the first node device receives the link delay of the remote network link sent by the neighboring node device of the first node device, where the link delay of the remote network link is determined by the link delay obtained by detecting, by at least one end node device of the remote network link, the remote network link through a request reply mechanism, for example, the link delay of the remote network link may include: and detecting the obtained link delay by any end node equipment of the far-end network link, or respectively detecting the obtained weighted average value of the link delays by the node equipment at the two ends of the far-end network link. The link delay detected by any one of the end node devices is the link delay of the far-end network link, and the network delay information maintained by the first node device can be more robust under the condition that the link delay of the far-end network link is a weighted average value of the link delays detected by the node devices at the two ends of the far-end network link respectively.

As shown in fig. 3, assuming that the first node device is the node device 1, for the node device 1, the link delay of the remote network link between the node device 2 and the node device 5 cannot be directly measured by the request response mechanism, but the node device 2 and/or the node device 5 need to calculate and determine by initiating the request response mechanism, and the node device 2 encapsulates the link delay of the remote network link obtained by the final determination into a link delay sharing message to send or forward to the node device 1, and the node device 1 updates the network delay information maintained by itself based on the obtained link delay of the remote network link.

The first node device may receive the measured far-end link delay from the neighboring node device, and in one embodiment, further comprises: and receiving a response message sent by the neighbor node equipment of the first node equipment in a request response mechanism, wherein the response message comprises the opposite-end link delay and/or the link delay of the far-end network link. In this embodiment, the opposite-end link delay and/or the link delay of the far-end network link received by the first node device may be directly carried in the response message involved in the process that the first node device initiates the request response mechanism to the neighboring node device, so that the first node device may obtain the opposite-end link delay and/or the link delay of the far-end network link at the same time only by initiating the request response mechanism once, thereby reducing complexity of network internal interaction. In another embodiment, the peer link delay and/or the link delay of the remote network link may also be carried in other messages sent or forwarded by the neighboring node device to the first node device.

As described above, the network delay information includes: link delays of network links in the network topology and/or node delays of node devices in the network topology when forwarding messages. Optionally, the method further comprises: acquiring node delay obtained by detecting any node equipment by at least one neighbor node equipment of the any node equipment in the network topology structure, and determining the node delay of the any node equipment according to the acquired node delay; and/or receiving node delay of any node device shared by other node devices. In the embodiment of the present disclosure, the node delay of any node device needs to be measured by any neighboring node device corresponding to the any node device, specifically, by any neighboring node corresponding to the any node device through a backflow message mechanism.

The reflow message mechanism related in the embodiments of the present specification relates to interaction between a requester and a responder, and considers that an initiator of the reflow message mechanism is the requester, and the reflow message mechanism is specifically implemented by the following manner: the requesting party firstly selects a answering party and sends a reflux message mechanism, firstly the requesting party needs to construct a reflux message with a destination address pointing to the requesting party, and sends the reflux message to the answering party according to a network link directly connected with the answering party, and simultaneously records the local time t5 of the requesting party when the reflux message is sent. After receiving the reflux message, the responder knows that the destination address of the reflux message is the requester through searching a routing table, so that the original route of the reflux message is returned to the requester, after receiving the reflux message, the requester records the local time T6 of the requester, then calculates T1=t6-T5, obtains the forwarding delay T1 corresponding to the whole period from the requester to the return of the reflux message, then the requester searches the link delay T2 of the network link between the requester and the responder from the network delay information maintained by the requester, and then calculates T3=T1-2×T2, thereby finally determining that the node delay corresponding to the responder is T3. The reflow message mechanism requires that no other relay device exists between the requesting party and the responding party, since the object measured by the reflow message mechanism, i.e. the node delay of the forwarding message of the responding party, will increase the other relay device, which will result in that the measurement expectation will not be reached.

In the embodiment of the present disclosure, the detecting, by any neighboring node device of any node device, the any node device includes: and the any neighbor node equipment sends a reflux message to the any node equipment, and the node delay of the any node equipment is determined through the forwarding delay of the reflux message and the link delay of a network link between the any neighbor node equipment and the any node equipment, wherein the reflux message is a message that a destination address sent by the any neighbor node equipment to the any node equipment points to the any neighbor node equipment. As previously described, for the node delay of any node device, any neighbor node device of any node device may initiate a backflow message mechanism to measure.

For the node delay of a certain neighbor node device of the first node device, the first node device may be directly detected by initiating a reflow message mechanism, and of course, since the node device directly connected to the neighbor node device may not only include the first node device, the first node device may also receive the node delay corresponding to the neighbor node device, which is measured by the node devices through the reflow message mechanism, and use the node delay as a reference to finally determine the node delay corresponding to the neighbor node device. Taking fig. 3 as an example, assuming that the node device 1 detects that the node delay of the node device 4 is 3 by initiating the reflux message mechanism to the node device 4, and also receives that the node delay of the node device 4 detected by initiating the reflux message mechanism to the node device 4 is 7, it may determine the node delay 3 measured by itself as the node delay with the node device 4 directly for the node device 1 and record it in the network delay information maintained locally by the node device 1, or determine the node delay 7 measured by the node device 2 received from the node device 2 as the node delay with the node device 4 and record it in the network delay information maintained locally by the node device 1, and may determine the average value 5 of the node delay 3 measured by itself and the node delay 7 measured by the node device 2 as the node delay of the node device 4 according to the weight ratio of 1:1 and record it in the network delay information maintained locally by the node device 1.

For the first node device, the node delays of the node devices except for the neighbor node devices cannot be detected through a backflow message mechanism, so that the first node device can acquire the node delay of any node device in other manners, for example, the first node device can directly receive the node delay of any node device shared by other node devices. Taking fig. 3 as an example, the node device 1 cannot directly detect and obtain the node delay of the node device 5, but the node device 2 can detect, so that the node device 1 can directly receive the node delay sharing message carrying the node delay of the node device 5 sent by the node device 2 to the node device 1, thereby obtaining and determining that the node delay of the node device 5 is 2, and finally recording the node delay in the local network delay information. Of course, the node device 1 does not have to acquire the node delay of the node device 5 from the node device 2, and in fact, by the foregoing manner of acquiring the node delay, the node device 4 maintains the network delay information that also includes the node delay of the node device 5, so that the node device 1 may also receive the node delay sharing message that is sent by the node device 4 and carries the node delay of the node device 5, so as to acquire the node delay of the node device 5.

The node delay of any node device in the network delay information maintained by the first node device includes: and node delay obtained by detecting the node equipment by any neighbor node equipment of any node equipment or a weighted average value of the node delay obtained by detecting the node equipment by at least one neighbor node equipment of any node equipment. As described above, for the node delay of any node device, any neighboring node of the any node device may be detected, so when the first node device determines the node delay of the any node device, the node delay of any neighboring node of the any node device detected for the any node device may be directly recorded in the locally maintained network delay information, or a weighted average of the node delays of one or more neighboring node devices of the any node device detected for the any node device may be determined as the node delay of the any node device, and recorded in the locally maintained network delay information. The network delay information maintained by the first node device may be made more robust in case the node delay of any node device is finally determined as a weighted average of the node delays detected by at least one neighboring node device of the any node device.

Taking fig. 3 as an example, the node device 1 may receive the node delay 1 of the node device 1 detected by the node device 3, the node delay 3 of the node device 1 detected by the node device 2, and the node delay 5 of the node device 1 detected by the node device 4, where the node device 1 may optionally use the node delay of the node device 1 detected by one of the node devices as the node delay of the node device 1 in the locally maintained network delay information, may determine, according to a weight ratio of 3:1, a weighted average 1.5 of the node delay detected by the node device 3 and the node delay detected by the node device 2 as the node delay of the node device 1 in the network delay information, and may determine, according to a weight ratio of 1:1:1, the weighted average 3 of the node delays of the node devices 1 detected by the three node devices as the node delay of the node device 1 in the network delay information.

Fig. 4 is a schematic block diagram of an apparatus according to an exemplary embodiment. Referring to fig. 4, at the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a nonvolatile memory 410, 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 402 reading a corresponding computer program from the non-volatile memory 410 into the memory 408 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 unit, but may also be hardware or a logic device.

As shown in fig. 5, fig. 5 is a block diagram of a block synchronization apparatus provided in the present specification according to an exemplary embodiment, and the apparatus may be applied to the device shown in fig. 4 to implement the technical solution of the present specification; the device is applied to a first blockchain node in a first blockchain network in a blockchain system, wherein the blockchain system comprises a blockchain main network and a blockchain sub-network managed by the blockchain main network, the first blockchain node dynamically maintains the local block height of a local latest block and a dynamic request period, and the dynamic request period is negatively related to the degree of lag between the local block height and the latest block height of the actual latest block of the first blockchain network and is negatively related to the size of a first node weight factor corresponding to the first blockchain node; the device comprises:

A request sending unit 501, configured to periodically send, when the local block height falls behind the latest block height, a block synchronization request for a lagging block to a normal node in a first blockchain network, where the normal node maintains the actual latest block in the first blockchain network according to the dynamic request period, where the block height of the lagging block is between the local block height and the latest block height;

A block receiving unit 502, configured to receive the lagging block returned by the normal node in response to the block synchronization request, so as to redetermine the local latest block and the dynamic request period.

Optionally, the method further comprises:

A latest block height receiving unit 503, configured to periodically send a latest height request to the normal node according to a preset request period, and receive the latest block height returned by the normal node in response to the latest height request; or alternatively

And the method is used for receiving the latest block height returned by the normal node in response to the block synchronization request.

Optionally, the first node weight factor is determined as a ratio of a node weight corresponding to the first blockchain node to a sum of node weights of all blockchain nodes disposed on the first node device where the first blockchain node is located.

Optionally, the dynamic request period is determined by:

searching a lagging interval corresponding to the lagging degree, and determining the dynamic request period as the ratio of a numerical value corresponding to the lagging interval to a first node weight factor; or alternatively

And calculating the product of the fixed request period and the lag factor corresponding to the lag degree, and determining the dynamic request period as the ratio of the product to the first node weight factor.

Optionally, the lag factor includes:

Dividing the maximum number of blocks allowed by a single block synchronization request by the difference between the local block height and the latest block height; or alternatively

The ratio of the local block height to the latest block height.

Optionally, the lag factor is provided with an upper factor bound for redefining the lag factor as the upper factor bound if the lag factor exceeds the upper factor bound and/or a lower factor bound for redefining the lag factor as the lower factor bound if the lag factor is below the lower factor bound.

Optionally, the dynamic request period is provided with a period upper bound and/or a period lower bound, the period upper bound is used for redefining the dynamic request period as the period upper bound if the dynamic request period exceeds the period upper bound, and the period lower bound is used for redefining the dynamic request period as the period lower bound if the dynamic request period is lower than the period lower bound.

Optionally, the upper period boundary includes a fixed period upper boundary or a dynamic period upper boundary, and the lower period boundary includes a fixed period lower boundary or a dynamic period lower boundary; wherein,

The dynamic period upper bound includes: a ratio of a maximum number of blocks allowed for a single block synchronization request to a block growth rate of a first blockchain network;

The dynamic period lower bound includes: the difference between the number of blocks required for the block synchronization request and the maximum number of blocks currently remaining in the local memory is divided by the local block processing speed.

Optionally, the first block link point maintains a network topology structure between node devices where each main network node in the block chain main network is located and network delay information corresponding to the network topology structure, and a main network node is further deployed on a node device where a sub-network node in the block chain sub-network is deployed; the request sending unit 501 is specifically configured to:

And determining a forwarding path with minimum total delay between first node equipment where a first blockchain node is located and target node equipment where a normal node is located from the network topological structure based on the network delay information, and forwarding the blocksynchronous request to the normal node according to the determined forwarding path.

Optionally, the network delay information includes link delay of a near-end network link and/or link delay of a far-end network link in the network topology, where the near-end network link is a network link between a first node device and a neighboring node device, and the far-end network link is a network link except for the near-end network link in the network topology.

Optionally, the method further comprises:

A link delay obtaining unit 504, configured to determine a link delay of the near-end network link according to a local link delay and/or an opposite link delay; the local link delay is obtained by detecting the near-end network link through a request response mechanism by a first node device, and the opposite link delay is obtained by detecting the near-end network link through a request response mechanism by a neighbor node device of the first node device; and/or the number of the groups of groups,

And receiving the link delay of the remote network link sent by the neighbor node equipment of the first node equipment, wherein the link delay of the remote network link is determined by the link delay obtained by detecting the remote network link by at least one end node equipment of the remote network link through a request response mechanism.

Optionally, the method further comprises:

and the reply receiving unit 505 is configured to receive a reply message sent by a neighboring node device of the first node device in a request reply mechanism, where the reply message includes the peer link delay and/or the link delay of the remote network link.

Alternatively to this, the method may comprise,

The link delay of the near-end network link includes: the local link delay, the opposite link delay, or a weighted average of the local link delay and the opposite link delay;

The link delay of the remote network link includes: and detecting the obtained link delay by any end node equipment of the far-end network link, or respectively detecting the obtained weighted average value of the link delays by the node equipment at the two ends of the far-end network link.

Optionally, the network delay information includes: link delays of network links in the network topology and/or node delays of node devices in the network topology when forwarding messages.

Optionally, the method further comprises:

a node delay obtaining unit 506, configured to obtain a node delay obtained by detecting any node device by at least one neighboring node device of the any node device in the network topology, and determine the node delay of the any node device according to the obtained node delay; and/or the number of the groups of groups,

And receiving the node delay of any node equipment shared by other node equipment.

Optionally, the detecting, by any neighboring node device of any node device, the any node device includes:

And the any neighbor node equipment sends a reflux message to the any node equipment, and the node delay of the any node equipment is determined through the forwarding delay of the reflux message and the link delay of a network link between the any neighbor node equipment and the any node equipment, wherein the reflux message is a message that a destination address sent by the any neighbor node equipment to the any node equipment points to the any neighbor node equipment.

Optionally, the node delay of any node device includes:

And node delay obtained by detecting the node equipment by any neighbor node equipment of any node equipment or a weighted average value of the node delay obtained by detecting the node equipment by at least one neighbor node equipment of any node equipment.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable GATE ARRAY, FPGA)) is an integrated circuit whose logic functions are determined by user programming of the device. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented with "logic compiler (logic compiler)" software, which is similar to the software compiler used in program development and writing, and the original code before being compiled is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but HDL is not just one, but a plurality of kinds, such as ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language), and VHDL (Very-High-SPEED INTEGRATED Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application SPECIFIC INTEGRATED Circuits (ASICs), programmable logic controllers, and embedded microcontrollers, examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the invention does not exclude that as future computer technology advances, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. 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, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device 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 tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a 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.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.

Claims

1. A block synchronization method is applied to a first block chain node in a first block chain network in a block chain system, wherein the block chain system comprises a block chain main network and a block chain sub-network managed by the block chain main network, the first block chain node dynamically maintains the local block height of a local latest block and a dynamic request period, the dynamic request period is negatively related to the degree of lag between the local block height and the latest block height of an actual latest block of the first block chain network and is negatively related to the size of a first node weight factor corresponding to the first block chain node, and the first node weight factor is determined as the ratio of the node weight corresponding to the first block chain node to the sum of node weights of all block chain nodes deployed on first node equipment where the first block chain node is located; the method comprises the following steps:

2. The method of claim 1, further comprising:

periodically sending a latest height request to the normal node according to a preset request period, and receiving the latest block height returned by the normal node in response to the latest height request; or alternatively

And receiving the latest block height returned by the normal node in response to the block synchronization request.

3. The method of claim 1, the dynamic request period being determined by:

Searching a lagging interval corresponding to the lagging degree, and determining the dynamic request period as the ratio of a numerical value corresponding to the lagging interval to the first node weight factor; or alternatively

And calculating the product of a fixed request period and a lag factor corresponding to the lag degree, and determining the dynamic request period as the ratio of the product to the first node weight factor.

4. A method according to claim 3, the lag factor comprising:

The ratio of the local block height to the latest block height.

5. A method according to claim 3, the lag factor being provided with an upper factor bound for re-determining the lag factor as the upper factor bound if the lag factor exceeds the upper factor bound and/or a lower factor bound for re-determining the lag factor as the lower factor bound if the lag factor is below the lower factor bound.

6. The method according to claim 1, the dynamic request period being provided with an upper period bound for redefining the dynamic request period as the upper period bound if the dynamic request period exceeds the upper period bound and/or a lower period bound for redefining the dynamic request period as the lower period bound if the dynamic request period falls below the lower period bound.

7. The method of claim 6, the upper period bound comprising a fixed period upper bound or a dynamic period upper bound, the lower period bound comprising a fixed period lower bound or a dynamic period lower bound; wherein,

8. The method of claim 1, wherein a first blockchain node maintains a network topology structure between node devices where each main network node in the blockchain main network is located and network delay information corresponding to the network topology structure, and a main network node is further deployed on a node device where a sub-network node in a blockchain sub-network is deployed; the first blockchain node sending the blocksynchronization request to the normal node, including:

9. The method of claim 8, the network delay information comprising link delays of near-end network links in the network topology and/or link delays of far-end network links between a first node device and its neighbor node devices, the far-end network links being network links in the network topology other than the near-end network links.

10. The method of claim 9, further comprising:

determining the link delay of the near-end network link according to the local link delay and/or the opposite link delay; the local link delay is obtained by detecting the near-end network link through a request response mechanism by a first node device, and the opposite link delay is obtained by detecting the near-end network link through a request response mechanism by a neighbor node device of the first node device; and/or the number of the groups of groups,

11. The method of claim 10, further comprising:

and receiving a response message sent by the neighbor node equipment of the first node equipment in a request response mechanism, wherein the response message comprises the opposite-end link delay and/or the link delay of the far-end network link.

12. The method according to claim 10,

13. The method of any of claims 9-12, the network delay information comprising: link delays of network links in the network topology and/or node delays of node devices in the network topology when forwarding messages.

14. The method of claim 13, further comprising:

Acquiring node delay obtained by detecting any node equipment by at least one neighbor node equipment of the any node equipment in the network topology structure, and determining the node delay of the any node equipment according to the acquired node delay; and/or the number of the groups of groups,

15. The method of claim 14, any neighboring node device of the any node device detecting the any node device, comprising:

16. The method of claim 14, the node delay of any node device, comprising:

17. A block synchronization apparatus applied to a first blockchain node in a first blockchain network in a blockchain system, the blockchain system including a blockchain main network and a blockchain sub-network managed by the blockchain main network, the first blockchain node dynamically maintaining a local block height of a local latest block and a dynamic request period, the dynamic request period negatively correlating to a degree of lag between the local block height and the latest block height of an actual latest block of the first blockchain network and negatively correlating to a magnitude of a first node weight factor corresponding to the first blockchain node, the first node weight factor being determined as a ratio of a node weight corresponding to the first blockchain node to a sum of node weights of all blockchain nodes deployed on a first node device where the first blockchain node is located; the device comprises:

18. An electronic device, comprising:

A processor;

A memory for storing processor-executable instructions;

wherein the processor is configured to implement the method of any one of claims 1-16 by executing the executable instructions.

19. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-16.