WO2023124743A1

WO2023124743A1 - Block synchronization

Info

Publication number: WO2023124743A1
Application number: PCT/CN2022/135825
Authority: WO
Inventors: 陶友贤
Original assignee: 支付宝(杭州)信息技术有限公司; 蚂蚁区块链科技(上海)有限公司
Priority date: 2021-12-31
Filing date: 2022-12-01
Publication date: 2023-07-06
Also published as: CN114338724A

Abstract

Provided in the present specification are a block synchronization method and apparatus, an electronic device and a storage medium. The method is applied to a first node device. A plurality of blockchain nodes belonging to a plurality of blockchain networks in a blockchain system are deployed on the first node device, and the first node device maintains corresponding block cache spaces for the deployed blockchain nodes, the size of the block cache space corresponding to any blockchain node being positively correlated with a node weighting factor of the blockchain node. The method comprises: receiving a lagging block sent by a normal node in a blockchain network to which any blockchain node belongs; caching the lagging block to a block cache space corresponding to any blockchain node, so that the blockchain node reads the lagging block from the block cache space and processes same; and when the lagging block is processed by the blockchain node, removing the lagging block from the block cache space.

Description

block synchronization

technical field

The embodiments of this specification belong to the technical field of block chains, and in particular relate to a block synchronization method, device, electronic equipment, and storage medium.

Background technique

Blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, the data blocks are combined into a chained data structure in a sequentially connected manner in chronological order, and a non-tamperable and unforgeable distributed ledger is cryptographically guaranteed. Due to the characteristics of decentralization, non-tamperable information, and autonomy, the blockchain has also received more and more attention and application. In some blockchain networks, some nodes sometimes need to implement small-scale transactions to prevent other nodes from obtaining these transactions and their related data. Therefore, a blockchain subnet can be further established on the basis of the blockchain main network, and the blockchain main network and the blockchain subnet are both independent blockchain networks.

For the blockchain main network or blockchain subnet, the various blockchain nodes contained in it use consensus agreements to ensure the consistency of the distributed ledgers maintained by them. However, when the blockchain node restarts or a new subnet node joins, the block data in the distributed ledger maintained by the blockchain node will lag behind the normal nodes in the blockchain network and cannot participate To the normal consensus process, affecting the operation of functions and services on blockchain nodes.

Contents of the invention

The object of the present invention is to provide a block synchronization method, device, electronic equipment and storage medium.

According to the first aspect of one or more embodiments of this specification, a block synchronization method is proposed, which is applied to a first node device, and the first node device is deployed with a block chain system belonging to multiple block chain networks multiple blockchain nodes, the first node device maintains a corresponding block cache space for its deployed blockchain nodes, wherein, the block cache space corresponding to any blockchain node deployed by the first node device The size is positively related to the node weight factor of any of the blockchain nodes; the method includes: receiving the normal node in the blockchain network to which any of the blockchain nodes belongs sends to the any of the blockchain nodes The backward block, wherein, the normal node maintains the actual latest block, and the block height of the backward block is between the local block height of the latest block locally maintained by any blockchain node and the Between the latest block heights of the actual latest block; cache the lagging block to the block cache space corresponding to any blockchain node, so that any blockchain node can retrieve data from the block Reading and processing the backward block in the block cache space; when the backward block has been processed by any blockchain node, removing the backward block from the block cache space.

According to the second aspect of one or more embodiments of this specification, a block synchronization device is proposed, which is applied to a first node device, and the first node device is deployed with a block chain system belonging to multiple block chain networks multiple blockchain nodes, the first node device maintains a corresponding block cache space for its deployed blockchain nodes, wherein, the block cache space corresponding to any blockchain node deployed by the first node device The size is positively related to the node weight factor of any of the blockchain nodes; the device includes: a block receiving unit, used to receive the normal nodes in the blockchain network to which any of the blockchain nodes belong The backward block of any blockchain node, wherein the normal node maintains the actual latest block, and the block height of the backward block is the latest block locally maintained by any blockchain node Between the local block height of the local block height and the latest block height of the actual latest block; the block cache unit is used to cache the backward block to the block cache space corresponding to any one of the blockchain nodes, To read and process the backward block from the block cache space by the any blockchain node; the block removal unit is used to be used by the any blockchain node in the backward block When the node finishes processing, remove the outdated block from the block cache space.

According to a third aspect of one or more embodiments of the present specification, an electronic device is provided, including: a processor; a memory for storing processor-executable instructions; wherein, the processor executes the executable instructions To realize the method as described in any one of the first aspect.

According to a fourth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided, on which computer instructions are stored, and when the instructions are executed by a processor, the method as described in any one of the first aspect is implemented. A step of.

In the embodiment of this specification, the first node device caches the received outdated block sent to any blockchain node in the block cache space corresponding to any blockchain node, and the Any one of the above-mentioned blockchain nodes reads and processes the backward block, so that the blockchain node deployed on the first node device can obtain its corresponding backward block, so as to ensure that the functions on the blockchain node are consistent with normal operation of the service. At the same time, since the block cache space is positively related to the node weight factor of any blockchain node and the storage resources of the first node device are limited, this solution is equivalent to adaptively allocating the storage resources of the first node device , giving priority to the block chain nodes with larger node weight factors deployed on the first node device to occupy a larger block cache space, so that in the block chain system composed of multiple block chain networks, different blocks The block current-limiting strategy corresponding to the block chain nodes in the chain network is macro-regulated, and the hierarchical design of block synchronization tasks is realized.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following will briefly introduce the drawings that need to be used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in this specification. , for those skilled in the art, other drawings can also be obtained according to these drawings without paying creative labor.

Fig. 1 is a schematic diagram of building a blockchain subnet based on the blockchain main network provided by an exemplary embodiment.

Fig. 2 is a flowchart of a block synchronization method provided by an exemplary embodiment.

Fig. 3 is a schematic diagram of a network topology provided by an exemplary embodiment.

Fig. 4 is a schematic structural diagram of a device provided by an exemplary embodiment.

Fig. 5 is a block diagram of a block synchronization device provided by an exemplary embodiment.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described The embodiments are only some of the embodiments in this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by persons of ordinary skill in the art without creative efforts shall fall within the protection scope of this specification.

Due to the decentralized nature of the blockchain network, all blockchain nodes in the blockchain network will maintain the same block data, which cannot meet the special needs of some nodes. Taking the consortium chain as an example, all consortium members (that is, node members in the consortium) can form a blockchain network, and all consortium members have corresponding blockchain nodes in the blockchain network, and can pass the corresponding zone Block chain nodes obtain all transactions and related data that occur on the block chain network. However, in some cases, there may be some alliance members who want to complete some transactions that require confidentiality. These alliance members hope that these transactions can be stored on the blockchain or take advantage of other advantages of blockchain technology, and can avoid other transactions. Affiliate members see these transactions and related data. Although these alliance members can additionally form a new blockchain network, the establishment method is similar to the above-mentioned blockchain network that includes all alliance members, but building a new blockchain network from scratch requires a lot of resources, and regardless of The establishment process of the blockchain network or the configuration process after completion is very time-consuming. The needs among alliance members are often temporary or have a certain timeliness, so that the newly built blockchain network will soon lose the meaning of existence due to the disappearance of demand, thus further increasing the chain construction cost of the above-mentioned blockchain network . However, the needs of alliance members often change, and the alliance members corresponding to each demand are often different. Therefore, whenever the alliance members change, it may be necessary to form a new blockchain network, resulting in resource and time constraints. A lot of waste.

To this end, the established blockchain network can be used as the blockchain main network, and a blockchain subnet can be formed on the basis of the blockchain main network. Then, in the consortium chain scenario such as the one mentioned above, the consortium members can build the required blockchain subnet based on their own needs while already participating in the blockchain main network. Since the blockchain subnet is established on the basis of the blockchain main network, the construction process of the blockchain subnet is compared to the completely independent establishment of a blockchain network, the resources consumed and the time required, etc. Both are greatly reduced, and the flexibility is extremely high.

The process of quickly establishing a blockchain subnet based on the blockchain main network is as follows: each blockchain node in the blockchain main network obtains a transaction for establishing a blockchain subnet, and the transaction includes the configuration information of the blockchain subnet , the configuration information includes the identity information of the node members participating in the formation of the block chain subnet, each block chain node in the block chain main network respectively executes the transaction to disclose the configuration information, when the When the configuration information includes the identity information of the node members corresponding to the first block chain node, the node device deploying the first block chain node starts the first block belonging to the block chain subnet based on the genesis block containing the configuration information. Two blockchain nodes.

Taking Figure 1 as an example, the blockchain main network is subnet0, and the blockchain nodes contained in subnet0 are nodeA, nodeB, nodeC, nodeD, and nodeE. Assume that nodeA, nodeB, nodeC and nodeD want to form a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to form a blockchain subnet, then nodeA can initiate the above-mentioned transaction to form a blockchain subnet to subnet0; If nodeE is an administrator and only allows the administrator to initiate the transaction of establishing a blockchain subnet, then nodeA~nodeD needs to make a request to nodeE, so that nodeE initiates the above transaction of establishing a blockchain subnet to subnet0; if nodeE is an administrator but allows Ordinary users initiate a transaction to establish a blockchain subnet, then nodeA～nodeE can initiate the above transaction to subnet0 to establish a blockchain subnet. Of course, whether it is an administrator or an ordinary user, the blockchain node that initiates the transaction to form a blockchain subnet does not necessarily participate in the established blockchain subnet. network, but nodeE can initiate the above-mentioned transaction of establishing a blockchain subnet to subnet0, and nodeA~nodeD may not necessarily initiate the transaction of establishing a blockchain subnet.

When a blockchain subnet is established on the basis of the blockchain main network, it is easy to understand that there will be a logical hierarchical relationship between the blockchain subnet and the blockchain main network. For example, when a blockchain subnet subnet1 is established on subnet0 shown in Figure 1, it can be considered that subnet0 is at the first layer and subnet1 is at the second layer. In one case, the blockchain main network in this specification can be the underlying blockchain network, that is, the blockchain main network is not a blockchain subnet formed on the basis of other blockchain networks, such as the subnet0 can be regarded as the blockchain mainnet belonging to the underlying blockchain network type. In another case, the blockchain main network in this specification can also be a subnet of other blockchain networks. For example, another blockchain subnet can be further established on the basis of subnet1 in Figure 1. At this time, it can be considered subnet1 is the blockchain main network corresponding to the blockchain subnet, and this does not affect that subnet1 also belongs to the blockchain subnet created on subnet0. It can be seen that the blockchain main network and the blockchain subnet are actually relative concepts. The same blockchain network can be the blockchain main network in some cases and the blockchain subnet in other cases.

After the above-mentioned transaction for establishing a blockchain subnet is sent to the blockchain main network, the consensus nodes in the blockchain main network will conduct a consensus, and after the consensus is passed, each main network node will execute the transaction to complete the block The formation of the chain subnet. The consensus process depends on the adopted consensus mechanism, which is not limited in this specification.

By including the configuration information in the above-mentioned transaction of establishing the blockchain subnet, the configuration information can be used to configure the established blockchain subnet so that the established blockchain subnet meets the networking requirements. For example, by including the identity information of node members in the configuration information, it is possible to specify which blockchain nodes are included in the established blockchain subnet.

The identity information of the node members may include the public key of the node, or other information that can represent the identity of the node such as the node ID, which is not limited in this description. Taking the public key as an example, each blockchain node has one or more sets of corresponding public-private key pairs. The blockchain node holds the private key and the public key is public and uniquely corresponds to the private key. Therefore, it can be passed The public key is used to represent the identity of the corresponding blockchain node. Therefore, for blockchain nodes that want to be node members of the blockchain subnet, the public keys of these blockchain nodes can be added to the above-mentioned transaction of forming the blockchain subnet as the identity information of the above-mentioned node members. The above-mentioned public-private key pair can be used in the process of signature verification. For example, in a consensus algorithm with a signature, for example, nodeA1 in subnet1 uses its own private key to sign the message, and then broadcasts the signed message in subnet1, while nodeB1, nodeC1 and nodeD1 can use the public key of nodeA1 Signature verification is performed on the received message to confirm that the message received by itself is indeed from nodeA1 and has not been tampered with.

The first main network node may be a blockchain node on the blockchain main network that is a node member indicated by the configuration information. When building a blockchain subnet, instead of the first main network node directly participating in the establishment of the blockchain subnet and becoming its node member, the first subnet node needs to be generated by the node device used to deploy the first main network node , and the first subnetwork node becomes a node member in the blockchain subnetwork. The first main network node and the first subnet node correspond to the same blockchain member, for example, in the alliance chain scenario, they correspond to the same alliance chain member, but the first main network node The node belongs to the blockchain subnet, so that the blockchain members can participate in the transactions of the blockchain main network and the blockchain subnet respectively; and, since the blockchain main network and the blockchain subnet belong to two independent Blockchain network, so that the blocks generated by the first main network node and the blocks generated by the first subnet node are respectively stored in different storages on the node device (the storage used can be a database, for example), realizing the first The storage used by the main network node and the first subnet node is isolated from each other, so the data generated by the blockchain subnet will only be synchronized among the node members of the blockchain subnet, so that only those who participate in the blockchain main The blockchain members of the network cannot obtain the data generated on the blockchain subnet, which realizes the data isolation between the blockchain main network and the blockchain subnet, and satisfies the requirements of some blockchain members (that is, the districts participating in the blockchain subnet). Transaction requirements between blockchain members).

It can be seen that the first main network node and the first subnet node are logically divided blockchain nodes, and from the perspective of physical equipment, it is equivalent to deploying the first main network node and the first subnet node The node devices participate in the blockchain main network and the blockchain subnet at the same time. Since the blockchain main network and the blockchain subnet are independent of each other, the identity systems of the two blockchain networks are also independent of each other, so even if the first main network node and the first subnet node can use exactly the same public key, the two should still be considered as different blockchain nodes. For example, in FIG. 1 , nodeA in subnet0 is equivalent to the first main network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 is equivalent to the first subnet node. It can be seen that since the identity systems are independent of each other, even if the public key used by the first subnet node is different from that of the first main network node, it will not affect the implementation of the scheme in this specification.

Of course, the node members of the blockchain subnet are not necessarily only part of the node members of the blockchain main network. In some cases, the node members of the blockchain subnet can be completely consistent with the node members of the blockchain main network. At this time, all blockchain members can obtain the data on the blockchain main network and the blockchain subnet, but The data generated by the blockchain main network and the blockchain subnet can still be isolated from each other. For example, by implementing one type of business on the blockchain main network and another type of business on the blockchain subnet, the two types of The business data generated by the business are isolated from each other.

In addition to the above-mentioned identity information of node members, the configuration information may also include at least one of the following: the network identifier of the blockchain subnet, the identity information of the administrator of the blockchain subnet, the The attribute configuration of the code, etc., is not limited in this specification. The network identifier is used to uniquely represent the blockchain subnet, so the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets formed on the blockchain main network. The identity information of the administrator of the blockchain subnet can be, for example, the public key of the node member who is the administrator; the administrators of the blockchain main network and the blockchain subnet can be the same or different.

One of the advantages of building a blockchain subnet through the blockchain mainnet is that since the first mainnet node has already been deployed on the node device that generates the first subnetwork node, the area used by the first mainnet node can be The block chain platform code is reused on the first subnet node, which eliminates the repeated deployment of the block chain platform code and greatly improves the efficiency of the block chain subnet. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node can reuse the attribute configuration adopted on the first main network node; if the configuration information includes the attribute configuration for the blockchain platform code attribute configuration, the first subnetwork node can adopt the attribute configuration, so that the attribute configuration adopted by the first subnetwork node is not limited to the attribute configuration of the first main network node, and has nothing to do with the first main network node. The attribute configuration for the blockchain platform code can include at least one of the following: code version number, whether consensus is required, consensus algorithm type, block size, etc., which are not limited in this specification.

Transactions that form blockchain subnets include transactions that call contracts. The transaction can specify the address of the called smart contract, the method called and the parameters passed in. For example, the invoked contract can be the aforementioned genesis contract or system contract, the invoked method can be a method for building a blockchain subnet, and the incoming parameters can include the above-mentioned configuration information. In one embodiment, the transaction may contain the following information:

from: Administrator

to: Subnet

method: AddSubnet(string)

string: genesis

Among them, the from field is the information of the initiator of the transaction. For example, Administrator indicates that the initiator is an administrator; the to field is the address of the called smart contract. For example, the smart contract can be a Subnet contract, and the to field is specifically the Subnet The address of the contract; the method field is the calling method. For example, the method used to build a blockchain subnet in the Subnet contract can be AddSubnet(string), and string is the parameter in the AddSubnet() method. In the above example, genesis is used to represent the The value of the parameter, the genesis is specifically the aforementioned configuration information.

Take nodes nodeA~nodeE on Subnet0 executing a transaction calling the AddSubnet() method in the Subnet contract as an example. After the transaction passes the consensus, nodeA～nodeE respectively execute the AddSubnet() method and pass in the configuration information to obtain the corresponding execution results.

After the nodes in the blockchain network execute the transaction that invokes the smart contract, they will generate a corresponding receipt (receipt), which is used to record information related to the execution of the smart contract. In this way, information about the contract execution result can be obtained by querying the receipt of the transaction. Contract execution results can be expressed as events in receipts. The message mechanism can implement message delivery through events in the receipt to trigger blockchain nodes to perform corresponding processing. The structure of an event can be, for example:

Event:

[topic][data]

…

In the above example, there may be one or more events; each event includes fields such as topic and data. Blockchain nodes can listen to the topic of the event to perform preset processing when listening to a predefined topic, or read relevant content from the data field of the corresponding event, and can execute preset based on the read content deal with.

In the above event mechanism, it is equivalent to the presence of a client with monitoring function at the listening party (such as a user with a monitoring requirement). The events generated by the block chain nodes are monitored, and the block chain nodes only need to generate receipts normally. In addition to the above-mentioned event mechanism, transaction information disclosure can also be realized in other ways. For example, the monitoring code can be embedded in the blockchain platform code running on the blockchain node, so that the monitoring code can monitor the transaction content of the blockchain transaction, the contract status of the smart contract, the receipt generated by the contract, etc. or multiple types of data, and send the monitored data to a predefined listener. Since the monitoring code is deployed in the blockchain platform code instead of the client of the listening party, this implementation based on the monitoring code is relatively more active than the event mechanism. Among them, the above monitoring code can be added to the blockchain platform code by the developers of the blockchain platform during the development process, or can be embedded by the monitoring party based on its own needs, which is not limited in this manual.

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 included in the above-mentioned receipt, and the receipt may include an event related to the execution of the AddSubnet() method, that is, a networking event. The topic of networking events can contain predefined networking event identifiers to distinguish them from other events. For example, in the event related to the execution of the AddSubnet() method, the content of the topic is the keyword subnet, and this keyword is different from the topic in the event generated by other methods. Then, by monitoring the topics contained in each event in the generated receipt, nodeA~nodeE can determine to monitor the event related to the execution of the AddSubnet() method, that is, the networking event, when the topic containing the keyword subnet is monitored. For example, the event in the receipt is as follows:

Event:

[topic:other][data]

[topic:subnet][data]

…

Then, when nodeA~nodeE listens to the first event, because the content of the included topic is other, it is determined that the event has nothing to do with the AddSubnet() method; and, when nodeA~nodeE listens to the second event, because the content of the included The content of the topic is subnet, determine that the event is related to the AddSubnet() method, and then read the data field corresponding to the event, which contains the above configuration information. Taking the configuration information including the public key of the node member of the blockchain subnet as an example, the content of the data field may include, for example:

{subnet1;

The public key of nodeA, the IP of nodeA, the port number of nodeA...;

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

The public key of nodeC, the IP of nodeC, the port number of nodeC...;

The public key of nodeD, the IP of nodeD, the port number of nodeD...;

}

Among them, subnet1 is the network identifier of the blockchain subnet you want to create. Each blockchain node in the blockchain main network can record the network identifiers of all blockchain subnets that have been created on the blockchain main network, or other information related to these blockchain subnets, such information can be maintained in In the above-mentioned Subnet contract, it may specifically correspond to the values of one or more contract states included in the Subnet contract. Then, nodeA～nodeE can determine whether the above-mentioned subnet1 already exists according to the recorded network identifiers of all blockchain subnets that have been created; if it does not exist, it means that subnet1 is a new blockchain subnet that needs to be created currently, and if it exists, it means that subnet1 already exists.

In addition to adopting the network identifier of the new blockchain subnet you want to create, you can also use a predefined new network identifier, which indicates that the corresponding networking event is used to form a new blockchain subnet. For example, the above subnet1 can be replaced with newsubnet, which is a predefined new network identifier. When nodeA~nodeE recognizes that the data field contains newsubnet, they can determine that the event containing this newsubnet is a networking event, and a new one needs to be created. Blockchain subnet.

In addition to the network identifier subnet1, the above data field also includes identity information of each node member and so on. The node device deploying the first main network node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first main network node belongs to the node member, the deployment second A node device of a main network node obtains the configuration information or the genesis block included in the networking event. Alternatively, the first blockchain node can monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member, trigger the deployment of the first blockchain node. A node device of a blockchain node obtains the configuration information or the genesis block included in the networking event.

As mentioned earlier, node devices can listen for receipts directly. Assuming that nodeA～nodeE are respectively deployed on node devices 1～5, and node devices 1～5 can monitor the receipts generated by nodeA～nodeE respectively, then when it is detected that subnet1 is a blockchain subnet that needs to be newly established, node device 1 ~5 will further identify the identity information of the node members contained in the data field to determine its own processing method. Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as nodeA's public key, IP address, and port number, then node device 1 obtains configuration information from the data field based on the above message mechanism , generate a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and then nodeA1 will load the generated genesis block, thus becoming a subnet node of subnet1; similarly, node device 2 can generate nodeB1, node Device 3 can generate nodeC1, and node device 4 can generate nodeD1. And, node device 5 will find that the identity information contained in the data field does not match itself, then the node device 5 will not generate a genesis block according to the configuration information in the data field, nor will it generate a blockchain node in subnet1.

As mentioned above, the blockchain nodes in the blockchain main network can monitor receipts and trigger node devices to perform related processing according to the monitoring results. For example, nodeA～nodeE will further identify the identity information of the node members contained in the data field in order to determine their own processing methods when they determine that subnet1 is a blockchain subnet that needs to be newly established. For example, nodeA~nodeD will find that the data field contains their own identity information such as their public key, IP address, and port number. Assume that nodeA~nodeD are deployed on node devices 1~4 respectively. Taking nodeA and node device 1 as an example: nodeA will Trigger node device 1, so that node device 1 obtains configuration information from the data field based on the above-mentioned message mechanism and generates a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and nodeA1 will load the generated genesis block, Thus, it becomes a subnet node in subnet1; similarly, nodeB will trigger node device 2 to generate nodeB1, nodeC will trigger node device 3 to generate nodeC1, and nodeD will trigger node device 4 to generate nodeD1. And, nodeE will find that the identity information contained in the data field does not match itself, assuming that nodeE is deployed on node device 5, then the node device 5 will not generate a genesis block based on the configuration information in the data field, nor will it generate subnet1 nodes in .

As mentioned above, the first main network node and the first subnet node do not necessarily use the same identity information. Therefore, in the above embodiment, the data field may contain identity information generated in advance for nodeA1-nodeD1, which is different from the identity information of nodeA-nodeD. Still take nodeA and node device 1 as an example: if node device 1 finds the identity information of nodeA1 in the data field, it can generate a genesis block, deploy nodeA1, and nodeA1 loads the genesis block; or, if nodeA is in the data field If the identity information of nodeA1 is found in , then nodeA will trigger node device 1 to generate a genesis block, deploy nodeA1, and nodeA1 will load the genesis block. The processing methods of other blockchain nodes or node devices are similar and will not be repeated here.

In addition to configuration information, the execution result of the contract can include the genesis block. In other words, in addition to including configuration information in the data field, you can also directly generate a genesis block containing configuration information in the process of executing the contract call, so that the genesis block is included in the data field, then for the above nodeA ~ nodeD and In other words, the corresponding node devices 1-4 can directly obtain the genesis block from the data field through the message mechanism without generating it by themselves, which can improve the deployment efficiency of nodeA1-nodeD1.

The node device implements the deployment of a blockchain node on the node device by creating an instance of running the blockchain platform code in the process. For the first main network node, the node device creates the first instance in the above process, and the first instance runs the blockchain platform code to form. Similarly, for the first subnetwork node, the node device creates a second instance different from the first instance in the above process, and the second instance runs the blockchain platform code to form. For example, the node device can first create the first instance in the process to form the first blockchain node in the blockchain main network; In the above process, a second instance is created, which is different from the above-mentioned first instance, and the second instance forms a second blockchain node in the blockchain subnet. When the first instance and the second instance are in the same process, because no cross-process interaction is involved, the difficulty of deploying the first subnet node can be reduced and the deployment efficiency can be improved; of course, the second instance may also be in separate nodes from the first instance In different processes on the device, this specification does not limit this; for example, the node device can create the first instance in the first process to form the first blockchain node in the blockchain main network; and when the node When the node member corresponding to the device wants to participate in the establishment of a blockchain subnet, it can start a second process different from the first process, and create a second instance in the second process, which is different from the first instance above. Furthermore, the second instance forms a second blockchain node in the blockchain subnet. In fact, each blockchain node deployed on any node device involved in the embodiments of this specification is a different blockchain instance running on any node device, and each blockchain node deployed on any node device The blocks generated by the nodes are respectively stored in different storages (such as databases) on any node device, and the storages used by each blockchain node deployed by any node device are isolated from each other.

Through the above method, a blockchain subnet can be created on the blockchain mainnet. Taking Figure 1 as an example, subnet0 originally included nodeA~nodeE, and subnet1 can be built on the basis of subnet0. This subnet1 includes nodeA1~nodeD1, and nodeA and nodeA1, nodeB and nodeB1, nodeC and nodeC1, nodeD and nodeD1 are respectively deployed in on the same node device. Similarly, subnet2 or more blockchain subnets can also be established on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC, nodeC1 and nodeC2, nodeD and nodeD1, nodeE and nodeE2 are respectively deployed on the same node device. And, subnet1, subnet2, etc. can be used as the new blockchain main network, and a blockchain subnet can be further formed on this basis. The process is similar to the formation of subnet1 or subnet2, and will not be repeated here. It can be seen that the above-mentioned method of initiating transactions on the blockchain main network to select node members to create a blockchain subnet can make the subnet nodes of the newly created blockchain subnet all deployed on the main network nodes of the blockchain main network. On the node device, that is, from the point of view of the node device, the node device where the subnet node of the blockchain subnet is located belongs to the subset of the node device where the main network node is located. The main network node in the blockchain main network is deployed on the node device at .

In addition to the above method of initiating transactions on the blockchain main network to select node members to create a blockchain subnet, other means can also be used to create a blockchain subnet and make it subject to the management of the blockchain main network. For example, a blockchain subnet can be established on the blockchain main network through registration (subsequently referred to as the registration network method), and the existing blockchain network can be directly registered to the blockchain main network, so that the newly registered blockchain network Managed by the blockchain main network, the newly registered blockchain network becomes a blockchain subnet of the blockchain main network. Through the registration network method, the subnet information of the block chain subnet to be formed is directly registered to the block chain main network, so that the block chain main network can obtain the relevant information of the block chain subnet to be formed (by receiving and executing the A transaction issued by the block chain network for associating its identity information with the subnet identification assigned to the block chain network to be formed), such as the subnet identification and operating status of the block chain subnet to be formed, where The public key and plug-in configuration information of each node member, the IP address and port information of each node device, etc., will be written into the contract state of the system contract corresponding to the blockchain main network, so that the blockchain main network will Obtain the management right of the blockchain subnet to be formed. After the registration is completed, it means that the blockchain subnet has been established. Since the registration networking method does not need to specify node members on the blockchain main network through transactions to form a blockchain subnet, the subnet nodes in the blockchain subnet formed through the registration networking method can be deployed on the blockchain main network. The node devices of each node in the network are completely different or partly different. For example, in Figure 1, subnet0 creates a subnet4 (not shown in Figure 1) in the form of registration and networking. It is assumed that the main network nodes nodeA～nodeE contained in subnet0 itself are deployed separately For node devices 1 to 5, the subnet nodes corresponding to subnet4 can be deployed on any other node devices except node devices 1 to 5, or one or more subnet nodes in subnet4 are respectively deployed on node devices 1 to 5 Any node device within 5 (but it is still necessary to ensure that only one subnet node in subnet4 is deployed on a node device), and other subnet nodes in subnet4 are deployed on any other node device except node devices 1 to 5 , of course, the subnet nodes in subnet4 may also be deployed in node devices 1-5.

As shown in Figure 1, for any blockchain network (referred to as the first blockchain network) in the blockchain system composed of the blockchain main network and its managed blockchain subnetworks, its Each block chain node of the network independently maintains a distributed ledger composed of several blocks connected in sequence. Each block will have a corresponding block height to indicate the block's position in the distributed ledger. Relative position, 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. Moreover, with the initiation, consensus and execution of transactions in the first blockchain network, new blocks will continue to be generated and updated to the distributed ledgers maintained by these blockchain nodes.

Under normal circumstances, each blockchain node in the first blockchain network will continuously update the distributed ledger maintained by itself in accordance with the consensus protocol, which makes the distributed ledger maintained by each blockchain node strictly consistent , but when the blockchain node restarts or a new blockchain node joins, it will inevitably cause the blocks in the distributed ledger maintained by some blockchain nodes to lag behind those in the first blockchain network other blockchain nodes, that is, the block height of the latest local block maintained by these blockchain nodes is behind the block height of the actual latest block in the first blockchain network. In the embodiment of this specification, the block height of the latest local block is called the local block height, and the block height of the actual latest block is called the latest block height, and the local block height of the latest local block maintained lags behind The blockchain node in the first blockchain network with the latest block height is called a backward node, and the local block height of the local latest block that will be maintained is the same as the latest block height in the first blockchain network Blockchain nodes are called normal nodes.

Since the blocks need to be integrated and updated to the distributed ledger in order, for backward nodes, they cannot participate in the consensus and processing of the actual latest block in the first blockchain network like normal nodes, that is, they cannot participate in the normal The consensus process affects the operation of functions and services on the lagging nodes and even the entire first blockchain network. Therefore, how to make the lagging nodes obtain the blocks they lag behind as soon as possible to complete the block chasing process is an urgent problem to be solved in this scenario .

In order to solve this problem, this specification proposes a block synchronization method. The first node device allocates the corresponding block cache space to the blockchain nodes deployed by it, and any blockchain node deployed by the first node device The size of the corresponding block cache space is positively related to the node weight factor of any blockchain node, so that in a blockchain system composed of multiple blockchain networks, the blocks in different blockchain networks The block current-limiting strategy corresponding to the block chain node is macro-regulated, and the hierarchical design of the block synchronization task is realized.

The block synchronization method involved in this specification will be described in detail below with reference to FIG. 2 . Fig. 2 is a flowchart of a block synchronization method provided by an exemplary embodiment. The method is applied to the first node device, where multiple blockchain nodes belonging to multiple blockchain networks in the blockchain system are deployed on the first node device, and the first node device maintains There is a corresponding block cache space, wherein the size of the block cache space corresponding to any blockchain node deployed by the first node device is positively related to the node weight factor of any blockchain node; the method includes : S202: Receive the outdated block sent to the any blockchain node by the normal node in the blockchain network to which the any blockchain node belongs, wherein the normal node maintains the actual latest block, and The block height of the backward block is between the local block height of the latest block locally maintained by any blockchain node and the latest block height of the actual latest block.

S204: Cache the backward block to the block cache space corresponding to any blockchain node, so that any blockchain node can read and process the backward block from the block cache space blocks.

In the embodiment of this specification, a node device is a hardware entity used to run a blockchain node, and a blockchain node refers to a software process running on a node device. The blockchain system involved in the embodiments of this specification refers to a blockchain system composed of multiple blockchain networks, such as the aforementioned block composed of the blockchain main network and its managed blockchain subnets. The block chain system, the feature of the block chain system is that there are multiple block chain nodes deployed at the same time in the node equipment involved, and the block synchronization scheme involved in this specification is being applied to the deployment of multiple block chain nodes. The first node device of multiple blockchain nodes to which the blockchain network belongs.

Any blockchain node involved in the embodiment of this specification belongs to a backward node, and after receiving a backward block, the backward node will process it in the order of block height from low to high, and the processing here may include: Verify the legitimacy of the block through the block header of the block, read the transactions contained in the block body of the block and execute these transactions in order, and finally add the block to the end of the distributed ledger maintained by the backward node to complete Block on-chain process. Therefore, any blockchain node needs to process the received backward blocks one by one in a certain order and it will take a certain amount of time to process each block. When the lagging block of any blockchain node is behind, the lagging block is directly forwarded to the any blockchain node, then if the lagging block contains multiple or the In the case of processing the previous block, these backward blocks forwarded to any blockchain node will be blocked by any blockchain node due to the limitation of the block processing mechanism of any blockchain node. Node dropped. Therefore, in the embodiment of this specification, the first node device will allocate a corresponding block cache space for each blockchain node deployed locally, wherein the block cache space corresponding to any blockchain node is used for temporary Storing the outdated blocks to be forwarded to any one of the blockchain nodes for processing, so that any one of the blockchain nodes can read from the block cache space and Process the backward blocks that need to be executed at present, so as to prevent the backward blocks from being discarded due to the lack of time for the blockchain nodes to process them.

The storage space corresponding to the block cache space involved in the embodiment of this specification may include memory space and/or hard disk space. However, no matter what type of storage space it is, the storage space contained in the first node device as a hardware entity Therefore, in order to perform hierarchical design on the block synchronization tasks of multiple blockchain nodes deployed on the first node device, the embodiment of this specification proposes to assign multiple block chain nodes deployed on the first node device according to the node weight factor. Block chain nodes maintain block cache spaces of different sizes, so that the size of the block cache space corresponding to any block chain node is positively related to the node weight factor of any block chain node, thereby realizing the first node Adaptive allocation of device storage resources.

The first node device first receives the block message, parses and obtains that the source communication address and the destination communication address corresponding to the block message are the normal node and the arbitrary block chain node respectively, and then obtains from the block message Extract the backward block and cache it in the block cache space corresponding to any blockchain node.

As mentioned above, the local block height of the latest local block maintained by the lagging node is smaller than the latest block height of the actual latest block, which means that when the first blockchain node detects that it belongs to the lagging node, The first block chain node does not maintain the actual latest block, and the block that the first block chain node lacks compared with the normal nodes of the same period is called a lagging block, and the lagging block is The allowable block height is between the local block height of the latest block locally maintained by the backward node (ie, the local latest block) and the latest block height, and the backward block includes the actual latest block block but does not contain said local latest block.

The size of the block cache space corresponding to any block chain node deployed by the first node device is positively related to the node weight factor of any block chain node. The size of the block cache space corresponding to the block chain node is determined as the product of a fixed storage size (usually referring to the storage upper limit for storing blocks in the first node device) and the node weight factor of any block chain node. In one embodiment, if the size of the block cache space of any blockchain node determined by the first node device exceeds the number of backward blocks and the average size of a single block of any blockchain node The product of , it means that the size allocation of the block cache space is too large. At this time, the size of the block cache space of any blockchain node can be re-determined as the number of backward blocks and the average value of a single block. The product of size, wherein, the number of backward blocks of any blockchain node is the latest block height maintained by the blockchain network to which any blockchain node belongs and the height of the latest block maintained by any blockchain node. The difference between the local block heights of the local latest block.

In addition, the size of the block cache space may be set with upper and lower bounds, so as to constrain the size of the block cache space within a reasonable range.

Optionally, the node weight factor of any blockchain node includes: the ratio of the node cache weight of any blockchain node to the sum of the node cache weights of the plurality of blockchain nodes.

The first node device can determine the node weight factor of any blockchain node it deploys in various ways. In an embodiment, the node weight factor of any blockchain node can be determined as the node cache weight corresponding to any blockchain node and the node cache weights of all blockchain nodes deployed on the first node device The ratio of the sum. In the embodiment of this specification, the first node device is deployed with the plurality of blockchain nodes, and the first node device maintains a node cache weight list, and the node cache weight list records all the locally deployed nodes of the first node device. The node cache weights corresponding to the multiple blockchain nodes respectively, and then when the first node device needs to calculate the node weight factor of any blockchain node deployed locally, it only needs to set the node weight factor corresponding to any blockchain node It can be obtained by dividing the node cache weight by the sum of the node cache weights of all blockchain nodes deployed locally. Taking Figure 1 as an example, the first node device is node device 1, then the node cache weight list maintained by node device 1 includes the node cache weights corresponding to nodeA, nodeA1 and nodeA2 deployed by node device 1, for example, the node of nodeA The cache weight of nodeA1 is 1, the node cache weight of nodeA1 is 2, and the node cache weight of nodeA2 is 3, then the node weight factor of nodeA1 calculated by node device 1 is 2/(1+2+3)=1/3. Since the storage resources of the node device are limited, in the embodiment of this specification, it can be ensured that the sum of the node weight factors of all blockchain nodes on the first node device has an upper bound, so as to adapt the block synchronization task of the first node device The upper limit of storage that can be supported above prevents the total size of the allocated cache space of each block from exceeding the upper limit of storage resources of the first blockchain node when the blockchain nodes on the first node device are all backward nodes.

In another embodiment, the first node device can also determine the node weight factor corresponding to any blockchain node as the node cache weight corresponding to any blockchain node and all nodes deployed on the first node device. The ratio of the sum of the node cache weights of the blockchain nodes in the backward state of the block. In the embodiment of this specification, when calculating the node weight factor corresponding to any blockchain node, it is only necessary to consider the node cache weight of any blockchain node, as well as the node cache weight deployed on the first node device in the respective block Node cache weights belonging to lagging nodes in the chain network. Still taking Figure 1 as an example, if the first node device is node device 1, then the node cache weight list maintained by node device 1 includes the node cache weights corresponding to nodeA, nodeA1 and nodeA2 deployed by node device 1, if nodeA It is currently a normal node in subnet0 and does not need to chase blocks (block synchronization), while nodeA1 and nodeA2 belong to the backward nodes in their respective subnet1 and subnet2, and needs to chase blocks, then the calculated nodeA1 at this time The node weight factor of is 2/(2+3)=0.4. In the embodiment of this specification, when there are blockchain nodes that do not need to track blocks in the first node device, the block cache space of the blockchain nodes that need to track blocks in the first blockchain node can be increased, so that The size of the block cache space of each blockchain node deployed in the first node device is dynamically maintained, and the upper limit of storage resources that the first node device can support in the block synchronization task is utilized as much as possible.

The node cache weight corresponding to each blockchain node in the node cache weight list maintained by the above-mentioned first node device may be the network weight corresponding to the blockchain network to which the respective blockchain node belongs, and the corresponding network weight of each blockchain network The network weight can be recorded in the subnet management contract of the blockchain main network, and obtained by the first node device reading the locally deployed main network nodes. Taking Figure 1 as an example, if the first node device is node device 1, then node device 1 can obtain the network weight of the blockchain main network and its managed blockchain subnets from the locally deployed main network node nodeA, such as subnet0 The network weight of subnet1 is 1, the network weight of subnet1 is 2, and the network weight of subnet2 is 3, then node device 1 will further allocate and specify the node cache weight for the blockchain nodes deployed by itself, and specify the node cache weight of nodeA as The network weight of the blockchain network subnet0 to which nodeA belongs, the node cache weight of nodeA1 is designated as the network weight of the blockchain network subnet1 to which nodeA1 belongs, the node cache weight of nodeA2 is indicated as the network weight of subnet2, and finally these node cache weights are recorded List of node cache weights maintained locally. In this way, it is equivalent to combining the macro-control at the network level of the block cache space with the macro-control at the node level, so that the maintenance strategy of the block cache space of the blockchain system that is finally realized can be implemented on the network. At the same level, it can realize the unified control of multiple blockchain nodes, and can also make differentiated local optimizations on different node devices to meet the specific conditions of the storage resources of different node devices. Of course, the network weight of any blockchain network can also be recorded in the smart contract of any blockchain network, and the block in any blockchain network deployed locally by the first node device Chain nodes get this network weight. In an embodiment, the node weight factor corresponding to any blockchain node may also be directly determined as the network weight of the blockchain network to which any blockchain node belongs.

S206: When the lagging block has been processed by any of the blockchain nodes, remove the lagging block from the block cache space.

After the first node device caches the received backward block into the block cache space corresponding to any blockchain node, the first blockchain node will read and process the block from the block cache space by itself. Each time a block is processed, the first node device will be notified to remove the processed block from the block cache space to make room for more blocks.

Optionally, the size of the block cache space is also positively related to the degree of lag between the local block height and the latest block height.

For example, the first node device may first multiply the node weight factor of any blockchain node deployed locally by the lagging degree factor to obtain the comprehensive factor corresponding to any blockchain node, and calculate any block The ratio of the comprehensive factor of the chain node to the sum of the comprehensive factors of all blockchain nodes, and finally the product of the ratio and the fixed storage size is determined as the size of the block cache space corresponding to any blockchain node, Wherein, the backward degree factor corresponding to any blockchain node is determined as the number of backward blocks of any blockchain node accounts for all blockchain nodes deployed on the first node device that are in a backward state. The ratio of the sum of the number of backward blocks, wherein, the number of backward blocks of any blockchain node is the latest block height maintained by the blockchain network to which any blockchain node belongs and the height of any block chain The difference between the local block heights of the latest local blocks maintained by blockchain nodes.

Since the size of the block cache space is positively related to the degree of lag between the local block height and the latest block height of the actual latest block of any blockchain network, in any blockchain node The greater the degree of backwardness (that is, the degree of backwardness between the local block height and the latest block height of any blockchain node), the larger the block cache space, which means that any block When a chain node lags far behind, its corresponding block cache space is also large, and as any blockchain node slowly synchronizes blocks, its lagging degree gradually shrinks, and its corresponding block cache space It will also gradually shrink. Therefore, the control of the block cache space in this scheme is equivalent to distinguishing the size of the block cache space of the backward nodes with different degrees of backwardness, so that the backward nodes with a greater degree of backwardness, that is, with a greater demand for block synchronization, occupy a larger space. The block cache space reduces the restriction of the block current limiting strategy to complete the block tracking process faster, so that each lagging node can complete a more balanced synchronous block tracking, realizing a more intelligent dynamic Block synchronization strategy.

Optionally, it also includes: receiving the information for the backward block that is sent periodically according to the dynamic request period when the local block height is behind the latest block height by any blockchain node. block synchronization request, and forward the block synchronization request to the normal node; wherein, the dynamic request period is negatively related to the degree of lag between the latest block height and the local block height.

In the embodiment of this specification, any blockchain node deployed on the first node device will detect whether it belongs to a backward node in the blockchain network to which it belongs. Once it detects that it belongs to a backward node, it will follow the dynamic request cycle Periodically send a block synchronization request to the normal node in the blockchain network where any of the blockchain nodes is located, in order to obtain lagging blocks behind itself and complete the block chasing process. Therefore, the backward block sent by the normal node in the blockchain network of any blockchain node to the blockchain node received by the first node device is actually sent by the blockchain node The normal node is determined in response to the block synchronization request previously sent by any blockchain node.

The following takes the first blockchain node in the first blockchain network deployed on the first node device as an example to illustrate the method for periodically sending a block synchronization request by the blockchain node involved in the embodiment of this specification. The method is applied to the first blockchain node, and the first blockchain node dynamically maintains the local block height of the latest local block and the dynamic request period, and the dynamic request period is negatively related to the local block height and the first The degree of lag between the latest block heights of the actual latest block in the blockchain network; the method includes: Step A: In the case that the local block height is behind the latest block height, according to the dynamic The request cycle periodically sends a block synchronization request for the backward block to the normal node in the first blockchain network that maintains the actual latest block, wherein the block height of the backward block is in the local area between the block height and the latest block height.

Step B: receiving the backward block returned by the normal node in response to the block synchronization request, so as to re-determine the local latest block and the dynamic request period.

The first block chain node involved in the embodiment of this specification sends a block synchronization request to the normal node, which is essentially sent by the first block chain node to the first node device, and then forwarded by the first node device to normal nodes; similarly, the backward block received by the first blockchain node and returned by the normal node is actually first received by the first node device and first cached to the block corresponding to the first blockchain node cache space, and then read and receive from the block cache space by the first blockchain node.

The actual latest block in the first blockchain network involved in the embodiment of this specification refers to the block height of the block that passed the consensus last time in the first blockchain network. The nodes process (execute the transactions in the block) and update it to the distributed ledger it maintains, so the actual latest block in the first blockchain network is also equivalent to each block in the first blockchain network The block with the largest block height among the blocks maintained by the chain node.

Since normal nodes also have the possibility of becoming backward nodes, any blockchain node in the first blockchain network will periodically ask other blockchain nodes for the status of the latest block maintained locally. Block height, once it finds that the local block height maintained by itself is less than the block height of the latest block maintained by other blockchain nodes, it considers itself to be a lagging node. On the contrary, if it finds that the local block height maintained by itself If it is greater than or equal to the block height of the latest block maintained by other blockchain nodes, it is considered to be a normal node.

The latest local block involved in the embodiment of this specification refers to the latest local block obtained by the first blockchain node through consensus or block synchronization and maintained locally. When the first blockchain node detects the local block When the height falls behind the latest block height (the local block height is less than the latest block height), it is determined that it belongs to a backward node, so it will start to periodically send block synchronization requests to normal nodes in order to obtain backward blocks. The cycle of periodically sending the block synchronization request is the dynamic request cycle maintained on the first block chain node, and the dynamic request cycle is negatively related to the height of the local block and the actual latest block of the first block chain network. The degree of lag between the latest block heights, which means that the dynamic request cycle will send changes as the local block height or the latest block height changes, for example, the first blockchain node gets a new lagging block every time it is synchronized , the latest local block maintained by it will send changes, so the lag between the local block height and the latest block height will also send changes. At this time, the first blockchain node also needs to update the dynamic The request cycle is updated synchronously.

Since the dynamic request cycle 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, the lagging degree of the first blockchain node (ie, the first The greater the lag between the local block height of the blockchain node and the latest block height), the shorter its dynamic request cycle is, which means that the first blockchain node moves to the normal unit time when the lagging degree is large The number of times the node sends block synchronization requests (the number of effective requests) will be more frequent, and as the first blockchain node slowly synchronizes the block, its lagging behind will gradually decrease, and the number of effective requests will gradually decrease. The number of block requests corresponding to a block synchronization request often has an upper limit, which means that a single block synchronization request generally cannot directly complete the block chasing process. Therefore, the control of the number of effective requests in this scheme is equivalent to distinguishing the block synchronization rate of lagging nodes with different degrees of lagging behind, so that lagging nodes with a greater degree of lagging behind, that is, a greater need for block synchronization, can complete block synchronization faster , so as to reduce the proportion of lagging nodes with a relatively large degree of lagging behind in all lagging nodes in the first blockchain network as a whole, so that lagging nodes can complete a more balanced synchronous block pursuit and realize a more intelligent dynamic Block synchronization strategy.

Optionally, the dynamic request period is also negatively related to the node weight factor of any blockchain node. Assume that any blockchain node is the first blockchain node, and its corresponding node weight factor is the first node weight factor. Since the dynamic request cycle is also negatively related to the first node weight corresponding to the first blockchain node The size of the factor, so it is also possible to adjust the weight dimension of the block synchronization rate of the first blockchain node. For example, the first node weight factor can be recorded in the contract state of the smart contract in the first blockchain network, and the smart contract can be invoked by the administrator or other users of the first blockchain network to update the first The node weight factor is updated, which enables the first blockchain node to dynamically adjust its own dynamic request cycle by reading the continuously updated first node weight factor on the smart contract. Since the smart contract will be deployed in the first block On each blockchain node in the blockchain network, this means that the node weight factors corresponding to each blockchain node in the first blockchain network are the same, which realizes the macro-control of the dynamic request cycle at the network level .

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 second The calculation process of the first node weight factor corresponding to the first blockchain node corresponding to a blockchain node has been introduced in the foregoing embodiments, and will not be repeated here. After the first node device calculates the first node weight factor It is provided to the first blockchain node, so that the first blockchain node can dynamically adjust its own dynamic request period through the first node weight factor continuously updated by the first node device, that is, the dynamic request period is realized. Macro-control at the node level.

The block synchronization request involved in the embodiment of this specification may include the identity information of the first blockchain node, the source communication address, the destination communication address, and the block range of the required backward block. The block range is defined by the block The height is determined. For example, the local block height maintained by the first blockchain node is 1500, but the actual latest block height is 2000. The upper limit of the number of block requests corresponding to a single block synchronization request is 100. Then the first block The block range of the backward block carried in the block synchronization request sent by the block chain node to the normal node can be (1500,1600], which is used to indicate that the normal node requests 100 blocks with block heights from 1501 to 1600 Block, of course, can also be (1500,1550] or (1900,2000]. In particular, when the block range of the backward block requested by the first blockchain node does not start continuously from the local block height, For example, in the block synchronization request in the above example, the block range of (1900,2000] is indicated. At this time, the first blockchain node will receive 100 blocks with a block height from 1901 to 2000, but due to the distributed ledger Updates need to be completed in the order of block heights, so even if the first blockchain node receives the above 100 blocks, it cannot complete the update of the distributed ledger. In this case, the first blockchain node will often send to Multiple other normal nodes request backward blocks with a block range of (1500,1900], so that the first blockchain node receives 399 blocks with block heights from 1501 to 1900 returned by other normal nodes Afterwards, the 399 blocks are processed and uploaded to the chain first (block chaining is to update the block to the distributed ledger), and then the previously received 100 blocks are processed and uploaded to the chain, so that by requesting more normal nodes complete the block chasing process faster.

In the embodiment of this specification, when the first blockchain node in the first blockchain network detects that the block maintained by itself is behind The normal node of the actual latest block periodically sends a block synchronization request for the backward block, so that the first blockchain node can obtain its corresponding backward block, so as to ensure that the functions on the first blockchain node are consistent with normal operation of the service. At the same time, since 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 in the first blockchain network, the unit time for lagging nodes with a large degree of lag The number of effective requests is more, which enables the lagging nodes with the greater degree of lagging behind to complete the block chasing process faster, because the block synchronization request needs to consume computing resources when it is responded by a normal node, and it will also occupy the network when returning the lagging block Bandwidth resources, and the number of normal nodes and computing resources in the first blockchain network, as well as the network bandwidth resources of the first blockchain network are limited, so this solution is equivalent to giving priority to the backward nodes with a greater degree of backwardness to occupy more There are many normal node computing resources and the network bandwidth resources of the first blockchain network, that is, the computing resources of normal nodes and the network bandwidth resources of the first blockchain network are reasonably allocated.

Furthermore, if the dynamic request cycle is also affected by the weight factor of the first node, then the block synchronization rate of different blockchain nodes can also be macro-regulated, realizing the hierarchical design of block synchronization tasks.

Optionally, the dynamic request period is determined in the following manner: searching for the backward interval corresponding to the backward degree, and determining the dynamic request period as a value corresponding to the backward interval; or, searching for the backward interval corresponding to the backward degree lag interval, and determine the dynamic request period as the ratio of the numerical value corresponding to the lag interval to the first node weight factor. In the embodiment of this specification, the dynamic request period will be determined according to the backward interval corresponding to the backwardness degree. Specifically, different backward intervals can be found to obtain the corresponding standard request period, and the dynamic request period is equal to the standard request period; or, in In the case that the dynamic request period is also negatively related to the node weight factor of any blockchain node, the dynamic request period is equal to the ratio of the standard request period obtained from the search to the first node weight factor. For example, when the degree of backwardness is specifically the difference between the local block height and the latest block height (that is, the number of backward blocks), the relationship between the standard request cycle and the number of backward blocks is shown in Table 1.

标准请求周期(单位：毫秒)Standard request cycle (unit: milliseconds)	落后区块数(单位：个)Number of lagging blocks (unit: piece)
10001000	0～1000～100
500500	101～1000101～1000
200200	＞1000>1000

Table 1

It can be seen from Table 1 that when the number of lagging blocks is in the interval from 0 to 100 (both ends included), it can be found that the standard request cycle corresponding to this interval is 1000ms, assuming that the influence of the weight factor of the first node is considered and the first node The value of the weight factor is 2, then the dynamic request period can be determined as 500ms; similarly, when the number of backward blocks is in the range of 101 to 1000, first find the standard request period as 500ms, and then compare it with the first node The dynamic request period is 250ms by dividing the weight factor; when the number of backward blocks exceeds 1000, the standard request period is found to be 200ms, and then the dynamic request period is further determined as 100ms. It can be seen that, on the whole, the backward block The larger the number, the smaller the dynamic request period, that is, the dynamic request period is negatively related to the degree of lag, and at the same time.

Alternatively, the dynamic request period is determined in the following manner: the dynamic request period is determined as the product of a fixed request period and a lagging factor corresponding to the lagging degree; or, the dynamic requesting period is also negatively correlated with the any In the case of a node weight factor of a blockchain node, the dynamic request period is determined as the ratio of the product to the first node weight factor.

In the embodiment of this specification, the dynamic request period needs to be obtained through the calculation formula: dynamic request period P=P0×f or P=P0×f/d, where P0 represents a fixed request period, which is specified by the administrator, and in As a fixed value, it will not change until it is modified, f represents the backwardness factor, and this parameter is positively related to the backwardness degree, and d represents the weight factor of the first node.

The lagging factor includes: the maximum number of blocks allowed for a single block synchronization request divided by the difference between the local block height and the latest block height; or, the local block The ratio of the height to the latest block height.

For example, f=M/(Hn-Hl), where M represents the maximum number of blocks allowed for a single block synchronization request (the upper limit of block requests), Hn represents the latest block height, and H1 represents the local block Height, in the embodiment of this description, the degree of backwardness of the first blockchain node is specifically the difference between the height of the local block and the height of the latest block. Obviously, the greater the number of backward blocks (that is, the greater the number of Hn-H1 ), the smaller the lag factor f is, the smaller the dynamic request period P is, that is, the dynamic request period is negatively related to the lagging degree.

Another example, f=H1/Hn, in the embodiment of this specification, the degree of backwardness of the first blockchain node is specifically the ratio between the height of the local block and the height of the latest block. Obviously, the greater the degree of backwardness, the greater the backwardness The smaller the factor f is, the smaller the dynamic request period P is, and the dynamic request period is also negatively related to the degree of lag.

Optionally, the lag factor is set with a factor upper bound and/or a factor lower bound, and the factor upper bound is used to re-determine the lag factor as the The factor upper bound, the factor lower bound is used to re-determine the lagging factor as the factor lower bound if the lagging factor is lower than the factor lower bound. In the embodiment of this specification, the value range of the aforementioned lagging factor is limited, thereby indirectly restricting the value range of the dynamic request period so as to meet the actual requirements of the block synchronization task. For example, in the case of f=M/(Hn-H1), if the difference between the local block height and the latest block height does not exceed the maximum number of blocks allowed for a single block synchronization request, then the first The f determined by a blockchain node may be too large, resulting in the final dynamic request period P being too large, so that the block chasing process cannot be completed normally. In order to avoid this situation, a value can be set for f The upper bound of the factor with a value of 1, so that when the difference between the local block height and the latest block height does not exceed the maximum number of blocks allowed for a single block synchronization request, the first blockchain Although the f calculated by the node is greater than 1, it will be re-determined as 1 due to the effect of the upper bound of the factor, so as to ensure that there is a reasonable maximum value of the dynamic request period, so as to ensure that the lagging nodes can normally complete the block chasing process.

Optionally, the dynamic request period is set with a period upper bound and/or a period lower bound, and the period upper bound is used to re-determine the dynamic request period when the dynamic request period exceeds the period upper bound is the upper bound of the period, and the lower bound of the period is used to re-determine the dynamic request period as the lower bound of the period when the dynamic request period is lower than the lower bound of the period. As mentioned above, the value range of the lagging factor can be limited, thereby indirectly restricting the range of the dynamic request period, and in the embodiment of this specification, the value range of the dynamic request period can also be directly limited , so that it meets the actual requirements of the block synchronization task.

Optionally, the upper bound of the period includes an upper bound of a fixed period or an upper bound of a dynamic period, and the lower bound of a period includes a lower bound of a fixed period or a lower bound of a dynamic period. Wherein, the upper bound of the dynamic period includes: the ratio of the maximum number of blocks allowed for a single block synchronization request to the block growth rate of the first blockchain network; the lower bound of the dynamic period includes: the The difference between the number of blocks requested by the block synchronization request and the maximum number of blocks currently stored in the block cache space corresponding to the first blockchain node is divided by the local block processing speed. In the embodiment of this specification, the cycle upper bound and/or the cycle lower bound can be set to a fixed value, called the fixed cycle upper bound and/or the fixed cycle lower bound, or can be set to a dynamic value, called the dynamic cycle upper bound and/or or dynamic period lower bound.

Since the block synchronization scheme involved in the embodiment of this specification will not affect the original block consensus process of the first block chain network during the implementation process, it means that during the block synchronization process, the first block The chain network will also generate new blocks, and the latest block height corresponding to the first blockchain network will continue to increase, that is, the first blockchain network has an objective block growth rate, and the block growth rate It can be obtained by the first blockchain node by detecting the change rate of the latest block height, and the block growth rate is a dynamically changing value. If the maximum number of blocks allowed for a single block synchronization request is M, then if the dynamic request cycle is too large, it may cause that even if each synchronization request requests M blocks, it will not be able to catch up with a waiting dynamic request The number of blocks that the first blockchain network naturally grows in the cycle, so that any lagging node cannot catch up with the blocks maintained by the normal nodes. Therefore, by setting the upper bound of the dynamic cycle to the block The ratio of the maximum number of blocks allowed for a single synchronous request to the block growth rate of the first blockchain network, so that lagging blocks can theoretically complete the block chasing process.

In the embodiment of this specification, after the first block chain node receives the backward blocks returned by the normal nodes, it needs to process these blocks in the order of block height from low to high, that is, to process these blocks by itself. The included transactions are then updated to the locally maintained distributed ledger, so for the first blockchain node, there is an objective local block processing speed, and at the same time, the first blockchain node will also The first node device allocates a memory space dedicated to storing unprocessed blocks, that is, the aforementioned block cache space, and the first node device will first cache the received backward blocks in this block cache space, The first blockchain node reads and processes blocks from the block cache space, and every time a block is processed, it will notify the first node device to remove the processed block from the block cache space , to make room for more blocks. If the dynamic request cycle is too small, it is likely that the received outdated blocks cannot be fully cached in the block cache space, resulting in memory overflow and block loss. In essence, the number of requested blocks exceeds the current The limit that the block cache space can accommodate, and in order to avoid this phenomenon, it is theoretically necessary to ensure that the number of blocks requested for a block synchronization request does not exceed the maximum number of blocks remaining in the current block cache space ( It is estimated by dividing the remaining memory capacity by the average size of a single block), but since the block synchronization request is generated at the beginning of the waiting dynamic request cycle, there will still be some Blocks are processed and removed from the block cache space, which means that assuming that the number of blocks required for a newly determined block synchronization request in a certain period is M1, the area determined at the beginning of the new waiting period The maximum number of blocks currently stored in the block cache space is Z, and the local block processing speed is v, so it only needs to satisfy M1≥Z-vP, that is, the dynamic request period to be waited in this cycle should satisfy P≥(Z-M1 )/v, the above memory overflow and block loss will not occur. Therefore, the dynamic period can be set as the difference between the number of blocks requested by the block synchronization request and the maximum number of blocks currently stored in the block cache space corresponding to the first blockchain node divided by At local block processing speed, thereby preventing memory overflow and block loss, while maximizing the use of block cache space vacated by block processing while waiting for a dynamic request cycle.

Optionally, the blockchain system includes a blockchain main network and a blockchain subnet managed by it, and the node devices deployed with subnetwork nodes in the blockchain subnet are also deployed with main network nodes; the first The node device maintains the network topology between the node devices where each main network node in the blockchain main network is located and the network delay information corresponding to the network topology; the block synchronization request Forwarding to the normal node includes: determining the forwarding path with the smallest total delay between the first node device and the target node device where the normal node is located from the network topology based on the network delay information, and transferring the The block synchronization request is forwarded to the normal node according to the determined forwarding path.

In the embodiment of this specification, a node device is a hardware entity used to run a blockchain node, and a blockchain node refers to a software process running in a node device, just like the network architecture shown in Figure 1, any area Different blockchain nodes in the blockchain network are deployed on different node devices, and the network links between the blockchain nodes are essentially the network links between corresponding node devices. Therefore, in the case that the blockchain network to which any blockchain node belongs is the blockchain main network subnet0, for any blockchain node such as nodeC, it is assumed that it needs to send a message to subnet0 Other main network nodes such as nodeE, only need to send the message from the node device 3 where nodeC is located to the node device 5 where nodeE is located to complete the corresponding message transmission.

After receiving the block synchronization request sent by any of the blockchain nodes, the first node device learns that the block synchronization request needs to be sent to the normal node according to the destination communication address of the block synchronization request, and Since the first node device needs to forward the block synchronization request to the normal node, the first node device needs to obtain routing information from the first node device to the target node device where the normal node is located. In the embodiment of this specification, the first node device forwards the block synchronization request to the forwarding path by using the acquired forwarding path with the smallest total delay between the first node device and the target node device as routing information. The node device of the next hop, and gradually forwards to the target node device.

Since the first node device is deployed with main network nodes, the first node device can generate the network topology among the node devices deployed with main network nodes by querying the network connection relationship of each main network node in the blockchain main network, And because the blockchain main network manages the subnet information of each blockchain subnet, which includes the identity information of each node member in any blockchain subnet, the node device where it is located, etc. Therefore, the first node device maintains In the network topology, in addition to the network connection relationship between each node device, it also includes the situation of the subnet nodes deployed on each node device, that is, the network topology includes the blockchain main network and each blockchain subnet. The overall network structure of the blockchain system formed.

The network topology involved in the embodiments of this specification refers to the connection relationship between the node devices where each main network node in the blockchain main network is located. The network topology is based on the main network nodes in the blockchain main network. It is generated by the network connection relationship between them, which can be represented graphically. Fig. 3 is a schematic diagram of a network topology provided by an exemplary embodiment. As shown in Fig. 3, the network topology is used to characterize the deployment of blockchain nodes on each node device, and the network topology between each node device Network link condition. Therefore, the connection relationship between the node devices shown in FIG. 3 can be regarded as a form of representation for representing the above-mentioned network topology structure. Of course, the above-mentioned network topology structure can also be represented in the form of a matrix or a table. Here Do not make any restrictions.

The network delay information corresponding to the network topology involved in the embodiment of this specification includes: the link delay of the network link in the network topology, and/or the node device in the network topology is forwarding the message The node delay at time. As shown in FIG. 3 , the link delay of each network link included in the network topology structure and the node delay of each node device. Wherein, the link delay of the network link refers to the delay information required for message forwarding on the network link, for example, the link delay of the network link between node device 1 and node device 2 in Figure 3 is 100; The node delay of a node device refers to the delay information required for a message to enter the node device and be forwarded from the node device, specifically including the process of the node device parsing the message, checking the routing table, and forwarding the message, such as the node device in Figure 3 The node delay of 1 is 3, and the forwarding delay of node device 4 is 5. In the embodiment of this specification, the values corresponding to the link delay and the node delay may represent the specific delay length, and may also represent other delay indicators related to the specific delay length, but the link delay and node delay Units need to be unified. For example, the link delay 100 of the network link between node device 1 and node device 2 can be understood as 100 milliseconds (ms), that is, it takes 100 ms for a message to pass through the network link, then the node delay 3 of node device 1 should be It is understood as 3ms.

The forwarding path with the smallest total delay between the first node device involved in the embodiment of this specification and the target node device where the normal node is located is through the node devices where each main network node in the blockchain main network is respectively located. The network topology and the network delay information corresponding to the network topology are determined. Specifically, when the first node device needs to send a block synchronization request to the normal node, it can determine the distance between the first node device and the target node device through the locally maintained network topology structure and the network delay information. The forwarding path with the least total delay.

Since the network topology maintained by the first node device includes the network link connection relationship between each node device, the first node device can determine the relative relationship between the first node device and the target node device in the network topology. In a case where the network location relationship is ensured and reachability is ensured, a forwarding path between the first node device and the target node device is generated. Taking Figure 3 as an example, assume that the first node device is node device 3, nodeC is any one of the blockchain nodes, and nodeE is a normal node. Now nodeC detects that it belongs to a lagging node and has waited for a dynamic request period. nodeC needs to send a block synchronization request to nodeE, so nodeC sends the block synchronization request to the node device 3 where it is located. After receiving the block synchronization request, node device 3 first needs to base on the network topology maintained by itself The structure determines the forwarding path between the node device 3 (the first node device) and the node device 5 (the target node device) where nodeE is located. Obviously, according to the network topology, it can be found that there is no Directly connected network links, and in the forwarding path without considering the loop and the original path return, the forwarding path between node device 3 and node device 5 includes two: one is node device 3 → node device 1 → Node device 2→node device 5; secondly, node device 3→node device 1→node device 4→node device 2→node device 5. After the node device 3 determines the two optional forwarding paths, it further determines the 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, wherein the forwarding path The corresponding total delay is the link delay of at least one section of the network link from the first node device to the target node device on the forwarding path and/or at least one node device (excluding the first node device and the target node device) device) node delay sum. Therefore, when the first node device determines the total delay of the forwarding path, it may only calculate the link delay of all network links from the first node device to the target node device, or it may only calculate the link delay from the first node device to the target node device. The node delays of all node devices passed by the target node device may also consider the link delays of all network links passed from the first node device to the target node device and the node delays of all the node devices passed by. For example, taking Figure 3 as an example, since the total delay of all network links and all node devices in the forwarding path of node device 3→node device 1→node device 2→node device 5 is 166, and node device 3→node Device 1→Node Device 4→Node Device 2→Node Device 5 The total delay of all network links and all node devices in this forwarding link path is 131, so the forwarding path finally determined by Node Device 3 is Node Device 3→Node Device 1→node device 4→node device 2→node device 5, so that node device 3 can further determine node device 1 as the next hop in the forwarding path, and then forward the block synchronization request to node device 1.

After node device 1 receives the block synchronization request, it can again determine the node with the shortest total delay between node device 1 and node device 5 based on the network topology structure maintained by node device 1 and the network delay information. Forwarding path, and the newly determined forwarding path forwards the block synchronization request for a second time, and the node device that subsequently receives the block synchronization request also follows the same process as above, first determines the new forwarding path and then follows The newly determined forwarding path forwards the block synchronization request; or, when the node device 3 forwards the block synchronization request to the node device 1, it may also carry the forwarding path determined by the node device 3 in the block synchronization request , then after receiving the block synchronization request, node device 1 can continue to find out that the next-hop node device is node device 4 based on the forwarding path carried in the block synchronization request, and The block synchronization request is forwarded to the node device 4, and the node device 4 and subsequent node devices continue to forward the block synchronization request according to the same process until the block synchronization request is forwarded to the node device 5. After receiving the block synchronization request, the node device 5 will further forward the block synchronization request to the locally deployed nodeE, thereby completing the entire process of sending the block synchronization request to normal nodes.

In the embodiment of this specification, the network delay information includes the link delay of the near-end network link and/or the link delay of the far-end network link in the network topology, and the near-end network link is A network link between the first node device and its neighbor node device, the remote network link is a network link in the network topology except the near-end network link. The neighbor node device of the first node device refers to the node device directly connected to the first node device through a network link. Taking FIG. 3 as an example, the neighbor node device corresponding to node device 1 includes node device 2, node device 3 and Node device 4 , and the neighbor node devices of 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. Among them, the near-end network link refers to the network link directly connected to the first node device, that is, the network link between the first node device and its neighbor node device; the remote network link refers to the network link not connected to the first node device. The network link directly connected to the node device is a network link in the network topology except the near-end network link corresponding to the first node device. Still taking Figure 3 as an example, the near-end network link corresponding to node device 1 includes the network links between it and node device 3, node device 4, and node device 5 respectively, and the remote network link corresponding to node device 1 is It includes network links between node device 1 and node device 2 , between node device 4 and node device 2 , and between node device 2 and node device 5 .

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

The request-response mechanism involved in the embodiment of this specification involves the interaction between the requester and the responder, and it is considered that the initiator of the request-response mechanism is the above-mentioned requester. The request-response mechanism is specifically implemented in the following way: the requester sends a The request message carries the time t1, and t1 is the requester's local time recorded by the requester when sending the request message. After receiving the request message, the responder will record the responder’s local time t2 when it receives the request message, and then return the response message generated in response to the request message to the requester, and carry the time in the response message t2 and time t3, where t3 is the local time of the responding party recorded by the responding party when returning the response message. Finally, after obtaining the response message, the requester records the requester’s local time t4 when the response message is received, then extracts t2 and t3 from the obtained response message, and then calculates T0=[(t4-t1) -(t3-t2)]/2, which is determined as the link delay T0 of the network link between the requester and the responder. In order to avoid the interference of the forwarding delay of the transit device, there is no other transit device between the requester and the responder. The request message and response message involved in the request-response mechanism can be dedicated messages dedicated to calculating link delays, or other ordinary normal service requests, or heartbeat messages in the network, because when calculating link delays, the response The local processing time t3-t2 of the party is taken into account, so no matter what type of request message and reply message can be applied to the above request-response mechanism to make the requester measure the relative link delay.

In this illustrative embodiment, when the first node device determines the link delay of the near-end network link, it can be determined through the above request response mechanism. For example, the first node device may actively initiate a request response mechanism to its neighbor node device, so as to determine the link delay of the near-end network link between the first node device and the neighbor node device, which is determined by the first node device The link delay of the near-end network measured through the request-response mechanism is called the local-end link delay. On the other hand, since for any network link, the devices at both ends of it can measure the link delay of the network link by initiating a request response mechanism, so the first node device can also receive the link delay of its neighbors The link delay of the near-end network link between the first node device and the neighbor node device measured by the node device through the request response mechanism directly obtains the link delay of the near-end network link, which is determined by the neighbor The link delay of the near-end network link measured and provided by the node device to the first node device is referred to as the opposite-end link delay. To sum up, the first node device can obtain the link delay of a certain near-end network link through two means, so it can also choose between these two means or consider comprehensively, for example, the final result obtained by the first node device The link delay of the near-end network link determined and recorded in the network delay information may include: the local link delay, the peer link delay, or the difference between the local link delay and the peer link delay. Weighted average of link delays. Wherein, when the link delay of the near-end network link is determined as the weighted average value of the local link delay and the peer link delay, the network delay information maintained by the first node device can be more robust.

Taking Figure 3 as an example, suppose that the local link delay of the near-end network link between node device 1 and node device 2 measured by the mechanism of initiating a request response is 102, and the delay measured by node device 2 through the mechanism of initiating a request response is 102. The measured opposite-end link delay of the near-end network link is 98, then, for the node device 1, it can directly determine the local-end link delay 102 measured by itself as the distance between the node device 2 and the node device 2. The link delay of the near-end network link, or the peer link delay 98 measured by the node device 2 received from the node device 2 is determined as the link delay of the near-end network link, and can also be determined according to 1 The weight ratio of :1 determines the average value 100 of the local link delay and the peer link delay as the link delay of the near-end network link, and records it in the network delay information locally maintained by node device 1.

Since the first node device can only directly measure the link delay of the near-end network link between its neighbor node device, but cannot measure the link delay with the far-end network link, it is necessary to receive the Or the forwarded link delay sharing message containing the link delay of the remote network link, so as to directly obtain the link delay of the remote network link, and record it to the corresponding remote network link in the network delay information place. In the embodiment of this specification, the first node device receives the link delay of the remote network link sent by the neighbor node device of the first node device, and the link delay of the remote network link is determined by the remote At least one end node device of the end network link is determined by the link delay obtained by detecting the remote network link through the request response mechanism. For example, the link delay of the remote network link may include: the remote The link delay detected by any end node device of the end network link, or the weighted average of the link delays detected by the node devices at both ends of the remote network link. Wherein, the link delay detected by any end node device is the link delay for the remote network link, and the link delay of the remote network link is respectively detected by the node devices at both ends of the remote network link. In the case of the obtained weighted average of link delays, the network delay information maintained by the first node device can be made more robust.

As shown in Figure 3, assuming that the first node device is node device 1, then for node device 1, the link delay of the remote network link between node device 2 and node device 5 cannot be directly Instead, it needs to be calculated and determined by node device 2 and/or node device 5 through the initiation request response mechanism, and node device 2 will encapsulate the final determined link delay of the remote network link into the link delay The sharing message is sent or forwarded to the node device 1, and the node device 1 updates the network delay information maintained by itself based on the acquired link delay of the remote network link.

The first node device may receive the remote link delay measured from the neighbor node device, and in an embodiment, it also includes: receiving the response message sent by the neighbor node device of the first node device in the request response mechanism, the response The message includes the peer link delay and/or the link delay of the remote network link. In this embodiment, the peer link delay and/or the link delay of the remote network link received by the first node device can be directly carried when the first node device initiates the request response mechanism to the neighbor node device. In the response message, the first node device only needs to initiate a request response mechanism once to obtain the link delay of the peer end and/or the link delay of the remote network link while obtaining the link delay of the local end , thereby reducing the complexity of the interaction within the network. 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 neighbor node device to the first node device.

As mentioned 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, it also includes: obtaining a node delay obtained by detecting any node device from at least one neighbor node device of any node device in the network topology, and determining the node delay of any node device according to the obtained node delay The node delay of the device; and/or, receiving the node delay of any node device shared by other node devices. In the embodiment of this specification, the node delay of any node device needs to be measured by any neighbor node device corresponding to any node device, specifically, it is measured by any neighbor node corresponding to any node device through backflow The message mechanism is measured.

The backflow message mechanism involved in the embodiment of this specification involves the interaction between the requester and the responder, and it is considered that the initiator of the backflow message mechanism is the above-mentioned requester. The backflow message mechanism is specifically implemented in the following way: the requester first selects a The responder initiates a return message mechanism. First, the requester needs to construct a return message whose destination address points to the requester itself, and send the return message to the responder according to the network link directly connected to the responder, and record the return message sent at the same time. The requester's local time t5 at the time of the message. After receiving the backflow message, the responder knows that the destination address of the backflow message is the requester by looking up the routing table, so it will return the backflow message to the requester through the original route. After receiving the backflow message, the requester will record Lower the local time t6 of the requester, and then calculate T1=t6-t5 to obtain the forwarding delay T1 corresponding to the entire cycle of the return message from the requester to the return to the requester, and then the requester delays the information from the network it maintains Find the link delay T2 of the network link between the requester and the responder, and then calculate T3=T1-2*T2, so as to finally determine that the node delay corresponding to the responder is T3. The backflow message mechanism requires that there are no other transit devices between the requester and the responder. This is because the object measured by the backflow message mechanism is the node delay of the responder's forwarded message. Therefore, adding other transit devices will result in failure to meet measurement expectations.

In the embodiment of this specification, any neighbor node device of the any node device detects the any node device, including: the any neighbor node device sends a backflow message to the any node device, and through the The forwarding delay of the reflux message, the link delay of the network link between the any neighbor node device and the any node device, determine the node delay of the any node device, and the reflux message is the A message sent by a neighbor node device to the any node device with a destination address pointing to the any neighbor node device. As mentioned above, for the node delay of any node device, any neighbor node device of the any node device can initiate a backflow message mechanism to measure it.

For the node delay of a neighbor node device of the first node device, the first node device can directly detect and obtain it by initiating a backflow message mechanism. Of course, since the node devices directly connected to the neighbor node device may not only include the first node device, Therefore, the first node device can also receive the node delay corresponding to the neighbor node device measured by these node devices through the backflow message mechanism, and use it as a reference to finally determine the node delay corresponding to the neighbor node device. Taking Figure 3 as an example, it is assumed that node device 1 detects that the node delay of node device 4 is 3 by initiating a return message mechanism to node device 4, and at the same time, it also receives that node device 2 initiates a return message mechanism to node device 4 to detect The obtained node delay of node device 4 is 7, then for node device 1, it can directly determine the node delay 3 measured by itself as the node delay with node device 4, and record it in the local maintenance of node device 1 In the network delay information of the node device 2, or determine the node delay 7 received from the node device 2 and measured by the node device 2 as the node delay of the node device 4, and record it in the network delay information locally maintained by the node device 1, and also The average value 5 of the node delay 3 measured by itself and the node delay 7 measured by the node device 2 can be determined as the node delay of the node device 4 according to the weight ratio of 1:1, and it is recorded in the local maintenance of the node device 1. In the network delay information.

For the first node device, it cannot detect the node delay of node devices other than its neighbor node devices through the backflow message mechanism. Therefore, the first node device can also obtain the node delay of any node device in other ways, for example, the first node device A node device may directly receive the node delay of any node device shared by other node devices. Taking Figure 3 as an example, node device 1 cannot directly detect the node delay of node device 5, but node device 2 can measure it, so node device 1 can directly receive the node delay of node device 5 sent by node device 2 to node device 1. The delayed node delays sharing the message, thereby obtaining and determining that the node delay of the node device 5 is 2, and finally recording it in the local network delay information. Of course, node device 1 does not necessarily need to obtain the node delay of node device 5 from node device 2. In fact, through the aforementioned method of obtaining node delay, the network delay information maintained by node device 4 actually includes the information of node device 5. The node delay, therefore, the node device 1 may also receive the node delay sharing message carrying the node delay of the node device 5 sent by the node device 4, so as to obtain 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: the node delay obtained by detecting any node device by any neighbor node device of the any node device, or the A weighted average of node delays obtained by detecting any node device by at least one neighbor node device of the above node device. As mentioned above, any neighbor node of any node device can detect the node delay of any node device, so when the first node device finally determines the node delay of any node device, it can directly use The node delay for any node device detected by any neighbor node of any node device is recorded in the locally maintained network delay information, or one or more neighbor node devices of any node device can be The weighted average of the node delays detected by any node device is determined as the node delay of the any node device, and is recorded in the locally maintained network delay information. In the case where the node delay of any node device is finally determined as the weighted average of the node delays obtained by detecting any node device by at least one neighbor node device of the any node device, the first The network delay information maintained by node devices is more robust.

Taking Figure 3 as an example, the node device 1 can respectively 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 3 of the node device 1 detected by the node device 4. Node delay 5, at this time, node device 1 can choose the node delay of node device 1 measured by one of the node devices as the node delay of node device 1 in the locally maintained network delay information, or according to the weight ratio of 3:1 The weighted average value 1.5 of the node delay measured by node device 3 and the node delay measured by node device 2 is determined as the node delay of node device 1 in the network delay information. The weighted average 3 of the node delays of the node device 1 detected by the number of node devices is determined as the node delay of the node device 1 in the network delay information.

Fig. 4 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer 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 non-volatile memory 410 , and of course may include hardware required by other services. One or more embodiments of this specification may be implemented based on software, for example, the processor 402 reads a corresponding computer program from the non-volatile memory 410 into the memory 408 and then executes it. Of course, in addition to software implementations, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each A logic unit, which can also be a hardware or logic device.

As shown in FIG. 5, FIG. 5 is a block diagram of a block synchronization device provided in this specification according to an exemplary embodiment. The device can be applied to the device shown in FIG. 4 to implement the technical solution of this specification; The device is applied to the first node device, where multiple blockchain nodes belonging to multiple blockchain networks in the blockchain system are deployed on the first node device, and the first node device maintains There is a corresponding block cache space, wherein the size of the block cache space corresponding to any blockchain node deployed by the first node device is positively related to the node weight factor of any blockchain node.

The device includes: a block receiving unit 501, configured to receive a backward block sent to any blockchain node by a normal node in the blockchain network to which any blockchain node belongs, wherein the The normal node maintains the actual latest block, and the block height of the backward block is between the local block height of the latest block locally maintained by any blockchain node and the latest block of the actual latest block between heights; the block cache unit 502 is used to cache the lagging block to the block cache space corresponding to any blockchain node, so that any blockchain node can retrieve the data from the block Read and process the lagging block in the buffer space; the block removal unit 503 is used to remove the lagging block when the lagging block has been processed by any of the blockchain nodes Remove the block cache space.

Optionally, it also includes: a request forwarding unit 504, configured to receive the periodic sending by any blockchain node according to the dynamic request cycle when the local block height is behind the latest block height. The block synchronization request for the backward block, and forward the block synchronization request to the normal node; wherein, the dynamic request cycle is negatively related to the latest block height and the local block The degree of lag between heights.

Optionally, the dynamic request period is also negatively related to the node weight factor of any blockchain node.

Optionally, the network delay information includes a link delay of a near-end network link and/or a link delay of a far-end network link in the network topology, and the near-end network link is the first node A network link between a device and its neighbor node device, the remote network link is a network link in the network topology other than the near-end network link.

Optionally, it also includes: a link delay obtaining unit 505, configured to determine the link delay of the near-end network link according to the local-end link delay and/or the peer-end link delay; wherein, the local-end link The path delay is obtained by the first node device detecting the near-end network link through the request-response mechanism, and the opposite-end link delay is detected by the neighbor node device of the first node device through the request-response mechanism on the near-end network link. and/or, receive the link delay of the remote network link sent by the neighbor node device of the first node device, and the link delay of the remote network link is determined by the remote network link It is determined by the link delay obtained by detecting the remote network link through at least one end node device of the path through the request response mechanism.

Optionally, it also includes: a response receiving unit 506, configured to receive a response message sent by a neighbor node device of the first node device in the request response mechanism, the response message including the peer link delay and/or all The link delay of the remote network link.

Optionally, the link delay of the near-end network link includes: the local-end link delay, the peer-end link delay, or the local-end link delay and the peer-end link delay The weighted average value of the remote network link; the link delay of the remote network link, including: the link delay detected by any end node device of the remote network link, or the node device at both ends of the remote network link A weighted average of the link delays obtained from the respective detections.

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, it also includes: a node delay obtaining unit 507, configured to obtain the node delay obtained by detecting any node device by at least one neighbor node device of any node device in the network topology, and according to the obtained The node delay determines the node delay of any node device; and/or receives the node delay of any node device shared by other node devices.

Optionally, any neighbor node device of the any node device detecting the any node device includes: the any neighbor node device sends a backflow message to the any node device, and the backflow message is used to The forwarding delay of any neighbor node device, the link delay of the network link between the any neighbor node device and the any node device, determine the node delay of the any node device, and the return message is the The message sent by the device to any node device with a destination address pointing to any neighbor node device.

Optionally, the node delay of any node device includes: a node delay obtained by detecting any node device by any neighbor node device of the any node device, or at least A weighted average of node delays obtained by a neighbor node device detecting any node device.

In the 1990s, the improvement of a technology can be clearly distinguished as an improvement in hardware (for example, improvements in circuit structures such as diodes, transistors, and switches) or improvements in software (improvement in method flow). However, with the development of technology, the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules. For example, a programmable logic device (Programmable Logic Device, PLD) (such as a field programmable gate array (Field Programmable Gate Array, FPGA)) is such an integrated circuit, the logic function of which is determined by the user's programming of the device. It is programmed by the designer to "integrate" a digital system on a PLD, instead of asking a chip manufacturer to design and make a dedicated integrated circuit chip. Moreover, nowadays, instead of making integrated circuit chips by hand, this kind of programming is mostly realized by "logic compiler (logic compiler)" software, which is similar to the software compiler used when program development and writing, but before compiling The original code of the computer must also be written in a specific programming language, which is called a hardware description language (Hardware Description Language, HDL), and there is not only one kind of HDL, but many 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), etc., are currently the most commonly used The most popular are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logical programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain a hardware circuit for realizing the logic method flow.

The controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), 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 can also be implemented as part of the control logic of the memory. Those skilled in the art also know that, in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present invention does not exclude that with the development of computer technology in the future, the computer that realizes the functions of the above embodiments can be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant , media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

Although one or more embodiments of the present specification provide the operation steps of the method described in the embodiment or the flowchart, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps enumerated in the embodiments is only one of the execution sequences of many steps, and does not represent the only execution sequence. When an actual device or terminal product is executed, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (such as a parallel processor or multi-thread processing environment, or even a distributed data processing environment). The term "comprising", "comprising" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, product, or apparatus comprising a set of elements includes not only those elements, but also other elements not expressly listed elements, or also elements inherent in such a process, method, product, or apparatus. Without further limitations, it is not excluded that there are additional identical or equivalent elements in a process, method, product or device comprising said elements. For example, if the words first, second, etc. are used, they are used to indicate names and do not indicate any specific order.

For the convenience of description, when describing the above devices, functions are divided into various modules and described separately. Of course, when implementing one or more of the present specification, the functions of each module can be realized in the same or more software and/or hardware, and the modules that realize the same function can also be realized by a combination of multiple submodules or subunits, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated. to another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

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 should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

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

Memory may include non-permanent storage in computer readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (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 that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

Those skilled in the art should understand that one or more embodiments of this specification 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. Furthermore, one or more embodiments of the present description may employ a computer program embodied 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. The form of the product.

One or more embodiments of this 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 storage devices.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, refer to part of the description of the method embodiment. In the description of this specification, descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific examples", or "some examples" mean that specific features described in connection with the embodiment or example , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the described specific features, structures, materials or characteristics may be combined in any suitable manner in any one or more embodiments or examples. In addition, those skilled in the art can combine and combine different embodiments or examples and features of different embodiments or examples described in this specification without conflicting with each other.

The above description is only an example of one or more embodiments of this specification, and is not intended to limit one or more embodiments of this specification. For those skilled in the art, various modifications and changes may occur in one or more embodiments of this description. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims

A block synchronization method, applied to a first node device, where multiple blockchain nodes in the blockchain system respectively belonging to multiple blockchain networks are deployed on the first node device, and the first node device is deployed for its The blockchain node maintains a corresponding block cache space, wherein the size of the block cache space corresponding to any blockchain node deployed by the first node device is positively related to the node weight factor of any blockchain node ; the method comprising:

Receive the backward block sent to the arbitrary blockchain node by the normal node in the blockchain network to which the arbitrary blockchain node belongs, wherein the normal node maintains the actual latest block, and the backward The block height of the block is between the local block height of the latest block locally maintained by any blockchain node and the latest block height of the actual latest block;

Cache the backward block to the block cache space corresponding to any blockchain node, so that any blockchain node can read and process the backward block from the block cache space ;

In the case that the lagging block has been processed by any of the blockchain nodes, the lagging block is removed from the block cache space.
The method according to claim 1, the node weight factor of any blockchain node includes: the node cache weight of any blockchain node accounts for the sum of the node cache weights of the multiple blockchain nodes ratio.
According to the method of claim 1, the size of the block cache space is also positively related to the degree of lag between the local block height and the latest block height.
The method according to claim 1, further comprising:

receiving a block synchronization request for the backward block periodically sent by any blockchain node according to the dynamic request cycle when the local block height is behind the latest block height, and Forwarding the block synchronization request to the normal node;

Wherein, the dynamic request period is negatively correlated with the degree of lag between the latest block height and the local block height.
According to the method of claim 4, the dynamic request period is also negatively related to the node weight factor of any blockchain node.
According to the method described in claim 4, the block chain system includes a block chain main network and a block chain subnet managed by the block chain, and the node device deployed with the subnet node in the block chain subnet is also deployed with a main network node; the first node device maintains the network topology between the node devices where each main network node in the block chain main network is respectively located and the network delay information corresponding to the network topology; The block synchronization request is forwarded to the normal node, including:

Determine the forwarding path with the smallest total delay between the first node device and the target node device where the normal node is located from the network topology based on the network delay information, and forward the block synchronization request according to the determined forwarding path Forward to the normal node.
The method according to claim 6, the network delay information comprises the link delay of the near-end network link and/or the link delay of the far-end network link in the network topology, the near-end network link A path is a network link between the first node device and its neighboring node devices, and the remote network link is a network link in the network topology except the near-end network link.
The method according to claim 7, further comprising:

Determine the link delay of the near-end network link according to the link delay of the local end and/or the link delay of the opposite end; wherein, the link delay of the local end is provided by the first node device to the near-end through a request response mechanism The network link is detected, and the peer link delay is obtained by the neighbor node device of the first node device detecting the near-end network link through a request response mechanism; and/or,

Receive the link delay of the remote network link sent by the neighbor node device of the first node device, and the link delay of the remote network link is responded by at least one end node device of the remote network link through a request The mechanism determines the link delay obtained by detecting the remote network link.
The method of claim 8, further comprising:

Receive a response message sent by a neighbor node device of the first node device in the request response mechanism, where the response message includes the peer link delay and/or the link delay of the remote network link.
The method of claim 8,

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

The link delay of the remote network link includes: the link delay detected by any end node device of the remote network link, or the link delay detected by the node devices at both ends of the remote network link. The weighted average of the path delay.
According to the method according to any one of claims 6-10, the network delay information includes: link delays of network links in the network topology, and/or node devices in the network topology Node latency when forwarding messages.
The method of claim 11, further comprising:

Obtaining a node delay obtained by detecting any node device from at least one neighbor node device of any node device in the network topology, and determining the node delay of any node device according to the obtained node delay; and/ or,

receiving the node delay of any node device shared by other node devices.
According to the method according to claim 12, any neighbor node device of said any node device detects any node device, comprising:

The any neighbor node device sends a return message to the any node device, through the forwarding delay of the return message, the link delay of the network link between the any neighbor node device and the any node device , to determine the node delay of the any node device, the return message is a message sent by the any neighbor node device to the any node device with a destination address pointing to the any neighbor node device.
The method according to claim 12, the node delay of any node device comprising:

The node delay obtained by any neighbor node device of any node device detecting the any node device, or the node delay obtained by detecting any node device by at least one neighbor node device of the any node device weighted average of .
A block synchronization device, applied to a first node device, where multiple blockchain nodes in the blockchain system respectively belonging to multiple blockchain networks are deployed on the first node device, and the first node device is deployed for the The blockchain node maintains a corresponding block cache space, wherein the size of the block cache space corresponding to any blockchain node deployed by the first node device is positively related to the node weight factor of any blockchain node ; the device comprises:

A block receiving unit, configured to receive a backward block sent to any of the blockchain nodes by a normal node in the blockchain network to which any of the blockchain nodes belongs, wherein the normal node maintains the actual latest block, and the block height of the backward block is between the local block height of the latest block locally maintained by any blockchain node and the latest block height of the actual latest block;

A block cache unit, configured to cache the backward block into the block cache space corresponding to any blockchain node, so that any blockchain node can read from the block cache space and process the lagging block;

A block removal unit, configured to remove the lagging block from the block cache space when the lagging block has been processed by any of the blockchain nodes.
An electronic device comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to any one of claims 1-14 by running the executable instructions.
A computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1-14 are implemented.