CN114338724A

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

Info

Publication number: CN114338724A
Application number: CN202111670006.6A
Authority: CN
Inventors: 陶友贤
Original assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd; Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2021-12-31
Filing date: 2021-12-31
Publication date: 2022-04-12
Anticipated expiration: 2041-12-31
Also published as: CN114338724B; WO2023124743A1

Abstract

The present specification provides a block synchronization method, an apparatus, an electronic device, and a storage medium, where the method is applied to a first node device, where a plurality of block chain nodes belonging to a plurality of block chain networks in a block chain system are deployed on the first node device, the first node device maintains a corresponding block cache space for a block chain link point deployed by the first node device, and a size of the block cache space corresponding to any block chain link point is positively related to a node weight factor of any block chain node; the method comprises the following steps: receiving a laggard block sent by a normal node in a block chain network to which any block chain node belongs; caching the lag block to a block cache space corresponding to any block chain node point, and reading and processing the lag block from the block cache space by any block chain node; and under the condition that the backward block is processed by any block chain node, removing the block cache space of the backward block.

Description

Block synchronization method and device, electronic equipment and storage medium

Technical Field

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

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people. In some blockchain networks, there is sometimes a need for some nodes to implement small-scale transactions to avoid other nodes from obtaining these transactions and their associated 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 used as independent blockchain networks.

For the block chain main network or the block chain sub-network, consistency of distributed accounts maintained by each block chain node is ensured through a consensus protocol. However, when a block link node is down and restarted or a new subnet node is added, block data in the distributed account maintained by the block link node lags behind normal nodes in the block link network, and cannot participate in a normal consensus process, thereby affecting the operation of functions and services on the block link node.

Disclosure of Invention

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

According to a first aspect of one or more embodiments of the present disclosure, a block synchronization method is provided, which is applied to a first node device, where a plurality of block chain nodes belonging to a plurality of block chain networks in a block chain system are deployed on the first node device, and the first node device maintains a corresponding block cache space for a block chain link point deployed by the first node device, where a size of the block cache space corresponding to any block chain link point deployed by the first node device is positively related to a node weight factor of any block chain node; the method comprises the following steps:

receiving a backward block sent by a normal node in a block chain network to which any block chain node belongs to any block chain node, wherein the normal node maintains an 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 block chain node and the latest block height of the actual latest block;

caching the laggard blocks to a block cache space corresponding to any block chain node point, so that the laggard blocks are read from the block cache space and processed by any block chain node;

and under the condition that the backward block is processed by any block chain node, removing the backward block from the block cache space.

According to a second aspect of one or more embodiments of the present disclosure, a block synchronization apparatus is provided, which is applied to a first node device, where a plurality of block chain nodes belonging to a plurality of block chain networks in a block chain system are deployed on the first node device, and the first node device maintains, for the deployed block chain node, a corresponding block cache space, where a size of the block cache space corresponding to any block chain node deployed by the first node device is positively related to a node weight factor of the any block chain node; the device comprises:

a block receiving unit, configured to receive a backward block sent by a normal node in a block chain network to which the any block link point belongs, to the any block chain node, where the normal node maintains an actual latest block, and a block height of the backward block is between a local block height of a latest block locally maintained by the any block link point and a latest block height of the actual latest block;

the block cache unit is used for caching the laggard blocks to a block cache space corresponding to any one block chain node, so that the laggard blocks are read from the block cache space by any one block chain node and processed;

and the block removing unit is used for removing the block cache space from the laggard block under the condition that the laggard block is processed by any block chain node.

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

a processor;

a memory for storing processor-executable instructions;

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

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

In this embodiment of the present specification, the first node device caches the received laggard block sent to any one of the block chain nodes to the block cache space corresponding to any one of the block chain nodes, and reads and processes the laggard block from the block cache space, so that the block chain node deployed on the first node device can obtain the corresponding laggard block, thereby ensuring normal operation of functions and services on the block chain node. Meanwhile, the block cache space positively correlates with the node weight factor of any one block chain node and the storage resource of the first node device is limited, so that the scheme is equivalent to adaptively distributing the storage resource of the first node device, and preferentially enabling the block chain link points with larger node weight factors deployed on the first node device to occupy larger block cache space, thereby performing macro regulation and control on block current limiting strategies corresponding to the block chain link points in different block chain networks in the block chain system formed by a plurality of block chain networks, and realizing the layered design of block synchronization tasks.

Drawings

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

Fig. 1 is a schematic diagram of building a blockchain subnet based on a blockchain master network according to an exemplary embodiment.

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

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

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

Fig. 5 is a block diagram of a block synchronization apparatus according to an exemplary embodiment.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

Due to the decentralized characteristic of the blockchain network, all blockchain nodes in the blockchain network can maintain the same blockchain data, and the special requirements of part of nodes cannot be met. Taking a federation chain as an example, all federation members (i.e., node members in a federation) may form a blockchain network, and all federation members respectively have corresponding blockchain nodes in the blockchain network, and may obtain all transactions and related data occurring on the blockchain network through the corresponding blockchain nodes. In some cases, however, there may be some security-required transactions that some coalition members wish to complete, which may both wish to be able to verify on the blockchain or to take advantage of other advantages of blockchain technology, and avoid other coalition members from viewing the transactions and associated data. Although the federating members can additionally build a new blockchain network in a manner similar to the blockchain network including all federating members described above, the new blockchain network is built from scratch, which consumes a lot of resources and is time-consuming in both the building process and the post-building configuration process. The demand between the members of the federation is often temporary or has a certain timeliness, so that the newly-built blockchain network can quickly lose significance due to the disappearance of the demand, thereby further increasing the link establishment cost of the blockchain network. The demands among the federation members often change, and the federation members corresponding to each demand often differ, so that a new blockchain network may need to be established whenever a change occurs in a federation member, thereby causing a great waste of resources and time.

For this purpose, the established blockchain network may be used as a blockchain master network, and a blockchain sub-network may be established on the basis of the blockchain master network. Then, in a federation chain scenario such as that described above, federation members can build the required blockchain subnets on a blockchain master basis based on their own needs, already participating in the blockchain master. Because the block chain sub-networks are established on the basis of the block chain main network, compared with the process of completely and independently establishing a block chain network, the block chain sub-networks are greatly reduced in consumed resources, required time consumption and the like, and are extremely high in flexibility.

The process of quickly establishing the block chain sub-network based on the block chain main network comprises the following steps: each block link point in a block chain main network respectively acquires a transaction for establishing a block chain sub-network, the transaction comprises configuration information of the block chain sub-network, the configuration information comprises identity information of node members participating in establishing the block chain sub-network, each block link point in the block chain main network respectively executes the transaction to reveal the configuration information, and when the configuration information comprises identity information of a node member corresponding to a first block link point, node equipment for deploying the first block chain node starts a second block chain node belonging to the block chain sub-network based on an innovation block comprising the configuration information.

For example, as shown in fig. 1, the main network of the blockchain is subnet0, and the subnet0 includes blockchain link points nodeA, nodeB, nodeC, nodeD, and nodeE. Assume nodeA, nodeB, nodeC, and nodeD wish to build a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to build a blockchain subnet, the transaction to build the blockchain subnet can be initiated by nodeA to subnet 0; if the nodeb is an administrator and only the administrator is allowed to initiate a transaction for building the blockchain subnet, nodeb a to nodeb d need to make a request to nodeb, so that nodeb initiates the transaction for building the blockchain subnet to subnet 0; if nodeE is an administrator but allows a normal user to initiate a transaction for building a blockchain subnet, nodeA-nodeE can both initiate the above transaction for building the blockchain subnet to subnet 0. Of course, the blockchain link point initiating the transaction for building the blockchain subnet does not necessarily participate in the built blockchain subnet, whether it is an administrator or a general user, for example, although the blockchain subnet is finally built by nodeA, nodeB, nodeC and nodeD, the transaction for building the blockchain subnet may be initiated by nodeE to subnet0, but the transaction for building the blockchain subnet is not necessarily initiated by nodeA to nodeD.

When the blockchain sub-network is constructed on the basis of the blockchain main network, it is easy to understand that a logical hierarchical relationship exists between the blockchain sub-network and the blockchain main network. For example, when building a blockchain subnet1 on subnet0 shown in fig. 1, subnet0 may be considered to be at a first level and subnet1 may be considered to be at a second level. In one case, the blockchain main network in this specification may be an underlying blockchain network, that is, the blockchain main network is not a blockchain sub-network constructed on the basis of other blockchain networks, for example, the subnet0 in fig. 1 may be regarded as a blockchain main network belonging to the underlying blockchain network type. In another case, the blockchain main network in this specification may also be a subnet of another blockchain network, for example, another blockchain subnet may be further configured on the basis of the subnet1 in fig. 1, and at this time, the subnet1 may be considered as the blockchain main network corresponding to the blockchain subnet, and this does not affect that the subnet1 belongs to the blockchain subnet created on the subnet0 at the same time. It can be seen that the blockchain main network and the blockchain sub-network are actually relative concepts, and the same blockchain network may be the blockchain main network in some cases and the blockchain sub-network in other cases.

After the transaction for establishing the blockchain sub-network is sent to the blockchain main network, the consensus nodes in the blockchain main network perform consensus, and after the consensus is passed, each main network node executes the transaction to complete establishment of the blockchain sub-network. The consensus process depends on the consensus mechanism employed, which is not limited by this specification.

The configuration information is included in the transaction of the block chain sub-network, and the configuration information can be used for configuring the block chain sub-network, so that the block chain sub-network meets networking requirements. For example, by including the identity information of the node members in the configuration information, it is possible to specify which blockchain nodes the constructed blockchain subnet includes.

The identity information of the node member may include a public key of the node, or other information capable of representing the node identity, such as a node ID, which is not limited in this specification. Taking a public key as an example, each blockchain node has one or more corresponding sets of public-private key pairs, and the private key is held by the blockchain node and the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Therefore, for blockchain nodes that are desired to be node members of a blockchain subnet, the public keys of these blockchain nodes can be added to the transaction of the building blockchain subnet as the identity information of the node members. The public and private key pair described above may be used in the process of signature verification. For example, in a signed consensus algorithm, such as the sub net1, the above-mentioned nodeA1 signs a message with its own private key, and broadcasts the signed message in the sub net1, while nodeB1, nodeC1 and nodeD1 can verify that the received message is signed with the public key of nodeA1 to confirm that the received message is indeed from nodeA1 and has not been tampered with.

The first master network node may be a blockchain node on the blockchain master network that belongs to a node member indicated by the configuration information. When the blockchain subnet is constructed, the first master network node does not directly participate in the construction of the blockchain subnet and becomes a node member thereof, but the first subnet node needs to be generated by the node device for deploying the first master network node and becomes a node member in the blockchain subnet by the first subnet node. The first main network node and the first sub-network node correspond to the same blockchain member, for example, correspond to the same alliance chain member in an alliance chain scene, but the first main network node belongs to a blockchain main network and the first sub-network node belongs to a blockchain sub-network, so that the blockchain member can participate in the transaction of the blockchain main network and the blockchain sub-network respectively; moreover, because the blockchain main network and the blockchain sub-network belong to two mutually independent blockchain networks, the blocks generated by the first main network node and the blocks generated by the first sub-network node are respectively stored in different storages (the adopted storages can be databases, for example) on the node device, so that mutual isolation between the storages used by the first main network node and the first sub-network node respectively is realized, and thus, data generated by the blockchain sub-network can only be synchronized among the node members of the blockchain sub-network, so that the blockchain members only participating in the blockchain main network cannot obtain the data generated by the blockchain sub-network, the data isolation between the blockchain main network and the blockchain sub-network is realized, and the transaction requirements between partial blockchain members (namely, the blockchain members participating in the blockchain sub-network) are met.

It can be seen that the first master network node and the first sub-network node are logically divided block chain link points, and from the perspective of physical devices, the node devices which are equivalent to the first master network node and the first sub-network node are deployed to participate in both the block chain master network and the block chain sub-network. Since the blockchain main network and the blockchain sub-network are independent from each other, so that the identity systems of the two blockchain networks are also independent from each other, even though the first main network node and the first sub-network node may adopt the same public key, the first main network node and the first sub-network node should be regarded as different blockchain nodes. For example, in fig. 1, the nodeA in subnet0 corresponds to a first master network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to a first sub-network node. It can be seen that, since the identity systems are independent of each other, even if the public key adopted by the first subnet node is different from that of the first master network node, the implementation of the solution in this specification is not affected.

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

In addition to the identity information of the node members described above, the configuration information may include at least one of: the network identifier of the blockchain subnet, the identity information of an administrator of the blockchain subnet, the attribute configuration for the blockchain platform code, and the like, which are not limited in this specification. The network identifier is used to uniquely characterize the blockchain subnet, and thus the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets established on the blockchain main network. Identity information of an administrator of the blockchain subnet, such as a public key of a node member as the administrator; the administrators of the blockchain main network and the blockchain sub-network may be the same or different.

One of the advantages of building the blockchain subnet by using the blockchain master network is that since the first master network node is already deployed on the node device generating the first subnet node, the blockchain platform code used by the first master network node can be multiplexed on the first subnet node, so that repeated deployment of the blockchain platform code is avoided, and the building efficiency of the blockchain subnet is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node may reuse the attribute configuration adopted on the first master network node; if the configuration information includes the attribute configuration for the blockchain platform code, the first subnet node may adopt the attribute configuration, so that the attribute configuration adopted by the first subnet node is not limited by the attribute configuration of the first main network node and is not related to the first main network node. The attribute configuration for blockchain platform code may include at least one of: code version number, whether consensus is required, type of consensus algorithm, block size, etc., which is not limited in this specification.

The transactions that make up the blockchain subnet include transactions that invoke contracts. The address of the invoked smart contract, the method invoked and the incoming parameters may be specified in the transaction. For example, the contract invoked may be the aforementioned startup contract or system contract, the method invoked may be a method that builds a blockchain subnet, and the incoming parameters may include the configuration information described above. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

the from field is information of the initiator of the transaction, such as administeror indicating that the initiator is an Administrator; the to field is the address of the intelligent contract being called, for example, the intelligent contract may be a Subnet contract, and the to field is specifically the address of the Subnet contract; the method field is a called method, for example, the method used in the Subnet contract to build the blockchain Subnet may be AddSubnet (string), and string is a parameter in the AddSubnet () method, and the value of the parameter is represented by the aforementioned example, which is specifically the aforementioned configuration information.

Take the example that nodes nodeA-nodeE on Subnet0 execute a transaction that invokes the AddSubnet () method in the Subnet contract. After the transaction passes the consensus, nodeA-nodeE respectively execute the AddSubnet () method and transmit configuration information to obtain corresponding execution results.

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

Event：

[topic][data]

......

in the above example, the number of events may be one or more; wherein, each event respectively comprises fields of a subject (topic) and data (data). The tile chain node may perform the preset process by listening to topic of the event, in case that predefined topic is listened to, or read the related content from the data field of the corresponding event, and may perform the preset process based on the read content.

In the event mechanism, it is equivalent to that there is a client with a monitoring function at a monitoring party (e.g. a user with a monitoring requirement), for example, an SDK or the like for implementing the monitoring function is run on the client, and the client monitors events generated by the blockchain node, and the blockchain node only needs to generate a receipt normally. The passage of transaction information may be accomplished in other ways than through the event mechanism described above. For example, the monitoring code can be embedded in a blockchain platform code running at blockchain nodes, so that the monitoring code can monitor one or more data of transaction content of blockchain transactions, contract states of intelligent contracts, receipts generated by contracts and the like, and send the monitored data to a predefined monitoring party. Since the snoop code is deployed in the blockchain platform code, rather than at the snooper's client, this implementation based on snoop code is relatively more proactive than the event mechanism. The above monitoring code may be added by a developer of the blockchain platform in the development process, or may be embedded by the monitoring party based on the own requirement, which is not limited in this specification.

It can be seen that the execution result of the Subnet contract may include the configuration information, and the execution result may be in the receipt as described above, and the receipt may contain the event related to the execution of the AddSubnet () method, i.e., the networking event. The topoc of a networking event may contain a predefined networking event identification to distinguish it from other events. For example, in an event related to the execution of the AddSubnet () method, the content of topic is a keyword subnet, and the keyword is distinguished from topic in the event generated by other methods. Then, nodeb to nodeb can determine to listen to an event related to execution of the AddSubnet () method, that is, a networking event, by listening to topic included in each event in the generated receipt, in the case where topic including the keyword subnet is listened to. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

then, when nodeA-nodeE monitor 1 st event, because the contained topoic content is other, it is determined that the event is irrelevant to the AddSubnet () method; and when the 2 nd event is monitored, because the contained topic content is subnet, determining that the event is related to the AddSubnet () method, and further reading the data field corresponding to the event, wherein the data field contains the configuration information. Taking the example that the configuration information includes the public key of the node member of the blockchain subnet, the content of the data field may include, for example:

{subnet1；

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

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

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

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

}

where subnet1 is the network identification of the blockchain subnet that one wishes to create. Each blockchain link point in the blockchain master network may record network identifiers of all blockchain subnets that have been created on the blockchain master network, or other information related to the blockchain subnets, which may be maintained in the Subnet contract, for example, and may specifically correspond to values of one or more contract states included in the Subnet contract. Then, nodeA to nodeE may determine whether the subnet1 already exists according to the recorded network identifiers of all the blockchain subnets that have been created; if not, subnet1 is the new blockchain subnet that needs to be created currently, and if so, subnet1 is already present.

In addition to the network identifier of the new blockchain subnet that is desired to be created, a predefined new network identifier may be used, which indicates that the corresponding networking event is used to create the new blockchain subnet. For example, the subnet1 may be replaced by newsbnet, where newsbnet is a predefined new network identifier, and when the nodeA-nodeE recognizes that the data field includes newsbnet, it may be determined that the event including newsbnet is a networking event and a new blockchain subnet needs to be created.

Besides the network identification subnet1, the data field also contains the identity information of each node member. The node device deploying the first master network node may monitor the generated receipt, and obtain, by the node device deploying the first master network node, configuration information or an innovation block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first master network node belongs to the node member. Or the first block link point may monitor the generated receipt, and trigger the node device deploying the first block link node to acquire the configuration information or the created block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first block link point belongs to the node member.

As previously described, the node device may listen for receipts directly. Assuming that nodeA-nodeE are respectively deployed on the node devices 1-5, and the node devices 1-5 can monitor receipts respectively generated by the nodeA-nodeE, under the condition that the subnet1 is monitored to be a block chain subnet needing to be newly established, the node devices 1-5 further identify the identity information of the node members contained in the data field to determine the processing mode of the node devices. Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as a public key, an IP address, and a port number of nodeA, node device 1 generates a created block containing configuration information when obtaining the configuration information from the data field based on the above-mentioned message mechanism, and node device 1 deploys nodeA1 locally, and further loads the generated created block by nodeA1, thereby becoming a subnet node of subnet 1; similarly, node device 2 may generate nodeB1, node device 3 may generate nodeB c1, and node device 4 may generate nodeB 1. And if the node device 5 finds that the identity information included in the data field does not match with itself, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a block link point in subnet 1.

As mentioned above, the blockchain link point in the blockchain master network can listen for the receipt and trigger the node device to perform the relevant processing according to the listening result. For example, when determining that subnet1 is a blockchain subnet that needs to be newly built, nodeA to nodeE further identify the identity information of the node members included in the data field to determine their own processing methods. For example, nodeA-nodeD may find that the data field includes identity information such as their own public key, IP address, and port number, assuming nodeA-nodeD are respectively deployed on node devices 1-4, taking nodeA and node device 1 as an example: the nodeA triggers the node device 1, so that the node device 1 obtains the configuration information from the data field based on the message mechanism and generates a created block containing the configuration information, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated created block, so that the node device 1 becomes 1 subnet node in the subnet 1; similarly, nodeB will trigger NodeB1 to be generated by node device 2, nodeC will trigger NodeC1 to be generated by node device 3, and nodeD will trigger NodeD1 to be generated by node device 4. And the nodeE finds that the identity information contained in the data field is not matched with the nodeE, and if the nodeE is deployed on the node device 5, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a node in the subnet 1.

As mentioned above, the first master network node and the first subnet node do not necessarily adopt the same identity information. Therefore, in the above embodiment, the data field may include the identity information generated in advance for nodeA 1-nodeD 1, and be distinguished from the identity information of nodeA-nodeD. Taking nodeA and node device 1 as an example: if identity information of nodeA1 is found in the data field, node device 1 may generate a founding block, deploy nodeA1, and load the founding block by nodeA 1; alternatively, nodeA, if identity information of nodeA1 is found in the data field, will trigger node device 1 to generate a foundational block, deploy nodeA1, and load the foundational block by nodeA 1. The processing modes of other blockchain nodes or node devices are similar, and are not described in detail herein.

In addition to configuration information, the execution results of the contract may include a foundational block. In other words, in addition to including the configuration information in the data field, the created block including the configuration information may be generated directly in the process of executing the contract call, so that the created block is included in the data field, and then for the nodeA to nodeD described above, the corresponding node devices 1 to 4 may obtain the created block directly from the data field through a message mechanism without self-generation, and the deployment efficiency of nodeA1 to nodeD1 may be improved.

The node device realizes the deployment of a blockchain node on the node device by creating an instance of running blockchain platform codes in the process. For the first master network node, a first instance is created by the node device in the above process and formed by the first instance running blockchain platform code. Similarly, for the first subnet node, a second instance different from the first instance is created by the node device in the above process, and is formed by the second instance running the blockchain platform code. For example, the node device may first create a first instance in a process to form a first blockchain node in a blockchain master network; when the node member corresponding to the node device wishes to participate in building the blockchain subnet, a second instance may be created in the process, where the second instance is different from the first instance, and forms a second blockchain node in the blockchain subnet. When the first instance and the second instance are located in the same process, the deployment difficulty of the first subnet node can be reduced and the deployment efficiency can be improved because cross-process interaction is not involved; of course, the second instance may also be in a different process on the node device than the first instance, and this specification does not limit this; for example, the node device may create a first instance in a first process to form a first blockchain node in a blockchain master network; when the node member corresponding to the node device wishes to participate in building the blockchain subnet, a second process different from the first process may be started, and a second instance different from the first instance may be created in the second process, so that the second blockchain node in the blockchain subnet is formed by the second instance. In fact, each block link point deployed on any node device referred to in the embodiments of this specification is a different block chain instance running on any node device, blocks generated by each block link point deployed on any node device are respectively stored in different storages (for example, a database) on any node device, and the storages used by each block link point deployed on any node device are isolated from each other.

By the method, the block chain sub-network can be created on the block chain main network. Taking fig. 1 as an example, the subnet0 originally includes nodeA to nodeE, and can construct subnet1 on the basis of subnet0, where subnet1 includes nodeA1 to nodeD1, and nodeA1, nodeB and nodeB1, nodeC and nodeC1, and nodeD1 are respectively deployed on the same node device. Similarly, a subnet2 or more block chain subnets can be constructed on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC1 and nodeC2, nodeD and nodeD1, and nodeE2 are respectively deployed on the same node device. And, subnet1, subnet2, etc. may be used as new blockchain main networks, and a blockchain subnet is further constructed on the basis, which is similar to the construction of subnet1 or subnet2, and is not described herein again. As can be seen, in the manner of initiating a transaction on the blockchain main network to select a node member to create a blockchain subnet, the subnet nodes of the newly created blockchain subnet can all be deployed on the node device where the main network node of the blockchain main network is located, that is, from the perspective of the slave 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, in other words, the main network node in the blockchain main network is deployed on the node device where the subnet node of the blockchain subnet is located.

In addition to the above-mentioned manner of selecting a node member to create a blockchain subnet by initiating a transaction on the blockchain main network, the blockchain subnet may be created by other means and managed by the blockchain main network. For example, a block chain sub-network (hereinafter referred to as a registration networking mode for short) may be established on the block chain main network through a registration mode, and an existing block chain network is directly registered to the block chain main network, so that the newly registered block chain network is managed by the block chain main network, and the newly registered block chain network becomes the block chain sub-network of the block chain main network. By means of the registration networking mode, subnet information of a block chain subnet to be established is directly registered to a block chain main network, so that the block chain main network obtains relevant information of the block chain subnet to be established (by receiving and executing a transaction which is sent by the block chain network to be established and used for carrying out association storage on identity information of the block chain subnet to be established and a subnet identifier distributed to the block chain network to be established), such as a subnet identifier and an operation state of the block chain subnet to be established, wherein public keys and plug-in configuration information of each node member, IP addresses and port information of each node device and the like, the information can be written into a contract state of a system contract corresponding to the block chain main network, and therefore the block chain main network obtains a management right of the block chain subnet to be established, and after the registration is completed, the block chain subnet establishment is completed. Since the registration networking manner does not require designating node members to form a blockchain subnet on the blockchain main network through transactions, subnet nodes in the blockchain subnet constructed through the registration networking manner may be completely or partially different from node devices disposed at each node in the blockchain main network, for example, subnet0 in fig. 1 creates a subnet4 (not shown in fig. 1) in the registration networking manner, and assuming that the main network nodes nodeA to nodeE included in the subnet0 themselves are disposed at the node devices 1 to 5, respectively, the subnet node corresponding to the subnet4 may be disposed at any node device other than the node devices 1 to 5, or one or more subnet nodes in the subnet4 may be disposed at any node device within the node devices 1 to 5, respectively (but it is still required to ensure that only one subnet node in the subnet4 is disposed at one node device), and other subnet nodes 4 are disposed at any node device other than the node devices 1 to 5, of course, the subnet nodes in subnet4 may all be deployed in node devices 1 to 5.

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

Under normal conditions, each blockchain node in the first blockchain network continuously updates the distributed account book maintained by the blockchain node according to a consensus protocol, so that the distributed account book maintained by each blockchain node is strictly consistent, but when the blockchain nodes are down to restart or new blockchain nodes are added, blocks in the distributed account book maintained by some blockchain nodes are inevitably lagged behind other blockchain nodes in the first blockchain network, namely the block height of the local latest block maintained by the blockchain nodes lags behind the block height of the actual latest block in the first blockchain network. In the embodiments of the present disclosure, the block height of the local latest block is referred to as a local block height, the block height of the actual latest block is referred to as a latest block height, the block link point in the first block chain network where the local block height of the maintained local latest block lags behind the latest block height is referred to as a laggard node, and the block link point in the first block chain network where the local block height of the maintained local latest block is the same as the latest block height is referred to as a normal node.

Since the blocks need to be integrated and updated to the distributed account book in sequence, the laggard nodes cannot participate in the consensus and processing of the actual latest block in the first block chain network as the normal nodes, that is, cannot participate in the normal consensus process, which affects the running of functions and services of the laggard nodes and even the entire first block chain network.

In order to solve the problem, the present specification provides a block synchronization method, where a first node device allocates a corresponding block cache space to a block link point deployed by the first node device, and a size of the block cache space corresponding to any block link point deployed by the first node device is positively related to a node weight factor of any block link node, so that in a block link system formed by multiple block link networks, macro regulation and control are performed on block current limiting strategies corresponding to block link points in different block link networks, thereby implementing hierarchical design of a block synchronization task.

The block synchronization method according to the present specification will be described in detail below with reference to fig. 2. Fig. 2 is a flowchart of a block synchronization method according to an exemplary embodiment. The method is applied to first node equipment, wherein the first node equipment is provided with a plurality of block chain nodes which belong to a plurality of block chain networks in a block chain system respectively, and maintains corresponding block cache spaces for the block chain nodes arranged by the first node equipment, wherein the size of the block cache space corresponding to any block chain node arranged by the first node equipment is positively related to a node weight factor of any block chain node; the method comprises the following steps:

s202: and receiving a backward block sent by a normal node in a block chain network to which the any block chain node belongs to the any block chain node, wherein the normal node maintains an actual latest block, and the block height of the backward block is between the local block height of the latest block locally maintained by the any block chain node and the latest block height of the actual latest block.

S204: and caching the laggard blocks to a block cache space corresponding to any block chain point, so that any block chain node reads and processes the laggard blocks from the block cache space.

In the embodiments of the present specification, a node device is a hardware entity for running a blockchain node, and a blockchain node refers to a software process running in the node device. The blockchain system according to the embodiment of the present disclosure refers to a blockchain system formed by a plurality of blockchain networks, for example, the blockchain system formed by the blockchain main network and the blockchain sub-network managed by the blockchain main network, where the blockchain system is characterized in that a phenomenon that a plurality of blockchain nodes are simultaneously deployed exists in the node device involved in the blockchain system, and the blockchain scheme according to the present disclosure is being applied to a first node device deployed with a plurality of blockchain nodes to which a plurality of blockchain networks belong.

Any block chain node related to the embodiment of the present specification belongs to a lagging node, and after receiving a lagging block, the lagging node performs processing according to a sequence of block heights from low to high, where the processing may include: and verifying the validity of the block through the block head of the block, reading the transactions contained in the block body of the block, executing the transactions in sequence, and finally adding the block to the tail of a distributed account book maintained by a laggard node to finish the block uplink process. Therefore, the processing of the received backward blocks by any block link node needs to be performed one by one in a certain order and it takes a certain time to process each block, and if the first node device directly forwards the backward blocks to any block chain node deployed thereon when receiving the backward blocks sent to the block chain node, in the case that the backward blocks contain a plurality of backward blocks or the block chain node is still processing the previous block, the backward blocks forwarded to the block chain node are discarded by the block chain node due to the limitation of the block processing mechanism of the block chain node. Therefore, in this embodiment of the present disclosure, the first node device allocates a corresponding block cache space for each locally deployed block link node, where the block cache space corresponding to any block link node is used to temporarily store a backward block to be forwarded to any block chain node for processing, so that any block chain node can automatically read and process the backward block to be currently executed from the block cache space according to its processing progress for the backward block, thereby preventing the backward block from being discarded due to the fact that the block chain node has no time to process the backward block.

However, no matter what type of storage space is, the storage space included by the first node device as a hardware entity is limited, so that in order to perform a hierarchical design on the block synchronization task of the multiple block chain nodes deployed on the first node device, the present embodiment proposes to maintain block cache spaces of different sizes for the multiple block chain nodes deployed on the first node device according to the node weight factor, 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 implementing adaptive allocation of storage resources of the first node device.

The first node equipment firstly receives the block message, analyzes the block message to obtain that a source communication address and a destination communication address corresponding to the block message are respectively the normal node and any block chain node, and then extracts the laggard block from the block message and caches the laggard block to the block cache space corresponding to any block chain node.

As previously mentioned, the local block height of the local newest block maintained by the laggard node is less than the newest block height of the actual newest block, which means that in case the first block link point detects itself as belonging to a laggard node, the first block link node does not maintain the actual newest block, and the block in which the first block link point is missing compared to the normal node at the same time is called a laggard block, the allowed block height of the laggard block is between the local block height of the newest block maintained locally by the laggard node (i.e. the local newest block) and the latest block height, and the laggard block contains the actual newest block but does not contain the local newest block.

The size of the block cache space corresponding to any block link point deployed by the first node device is positively related to the node weight factor of any block link node, specifically: the first node device determines the size of the block cache space corresponding to any block link point as the product of a fixed storage size (generally referred to as the storage upper limit for storing a block in the first node device) and the node weight factor of any block link node. In an embodiment, if the size of the block cache space of any one of the blockchain nodes determined by the first node device exceeds the product of the number of lagged blocks of any one of the blockchain nodes and the average size of a single block, which means that the size allocation of the block cache space is too large, the size of the block cache space of any one of the blockchain nodes may be re-determined as the product of the number of lagged blocks and the average size of a single block, where the number of lagged blocks of any one of the blockchain nodes is a difference between a latest block height maintained by the blockchain network to which the any one of the blockchain nodes belongs and a local block height of a local latest block maintained by the any one of the blockchain nodes.

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

Optionally, the node weight factor of any blockchain node includes: the node cache weight of any block chain node accounts for the ratio of the sum of the node cache weights of the plurality of block chain nodes.

The first node device may determine the node weight factor for any blockchain node it is deployed in a number of ways. In an embodiment, the node weight factor of any blockchain node may be determined as a ratio of a node cache weight corresponding to the any blockchain node to a sum of node cache weights of all blockchain nodes deployed on the first node device. In this embodiment, the first node device is deployed with the multiple block chain nodes, and the first node device may maintain a node cache weight list, where the node cache weight list records node cache weights corresponding to the multiple block chain link points locally deployed by the first node device, and then when the first node device needs to calculate a node weight factor of any locally deployed block chain node, the node cache weight corresponding to any locally deployed block chain node may be obtained only by dividing the node cache weight by a sum of node cache weights of all locally deployed block chain nodes. Taking fig. 1 as an example, if the first node device is node device 1, the node cache weight list maintained by node device 1 includes node cache weights corresponding to nodeA, nodeA1, and nodeA2 deployed by node device 1, for example, the node cache weight of nodeA is 1, the node cache weight of nodeA1 is 2, and the node cache weight of nodeA2 is 3, so that the node weight factor of nodeA1 that node device 1 can calculate is 2/(1+2+3) ═ 1/3. Because the storage resource of the node device is limited, in this embodiment of the present specification, it may be ensured that the sum of the node weight factors of all the block chain nodes on the first node device exists in the upper bound, so as to adapt to the upper storage limit that the first node device can support on the block synchronization task, and prevent the total size of each allocated block cache space from exceeding the upper storage resource limit of the first block chain node when all the block chain nodes on the first node device belong to the laggard nodes.

In another embodiment, the first node device may further determine a node weight factor corresponding to any one block link point as a ratio of the node cache weight corresponding to the any one block link point to the sum of the node cache weights of all block link points in the block lagging state deployed on the first node device. In this embodiment of the present description, when calculating a node weight factor corresponding to any one block chain node, only the node cache weight of any one block chain node and the node cache weights of laggard nodes in the respective block chain networks deployed on the first node device need to be considered. Still taking fig. 1 as an example, if the first node device is a node device 1, the node cache weight list maintained by the node device 1 includes node cache weights corresponding to nodeA, nodeA1, and nodeA2 deployed by the node device 1, if nodeA currently belongs to a normal node in subnet0, block tracing (block synchronization) is not needed, and both nodeA1 and nodeA2 belong to laggard nodes in subnet1 and subnet2 respectively located, and block tracing is needed, then the node weight factor of nodeA1 calculated at this time is 2/(2+3) ═ 0.4. In this embodiment of the present specification, when there is a block chain node that does not need to perform block chase in the first node device, the block cache space of the block chain node that needs to perform block chase in the first block chain node may be increased, so as to dynamically maintain the size of the block cache space of each block chain node deployed in the first node device, and to use the upper limit of the storage resource that can be supported by the first node device on the block synchronization task as much as possible.

The node cache weight corresponding to each block link point in the node cache weight list maintained by the first node device may be a network weight corresponding to a block chain network to which the respective block link point belongs, and the network weight corresponding to each block chain network may be recorded in a subnet management contract of a block chain master network and obtained by the first node device reading a locally deployed master network node. Taking fig. 1 as an example, if the first node device is a node device 1, the node device 1 may obtain, from a locally deployed master node nodeA, network weights of a blockchain master network and respective blockchain subnets managed by the master node blockchain master network, for example, the network weight of subnet0 is 1, the network weight of subnet1 is 2, and the network weight of subnet2 is 3, the node device 1 further assigns and assigns a node cache weight to a self-deployed blockchain link point, assigns a node cache weight of nodeA to a network weight of blockchain network subnet0 to which nodeA belongs, assigns a node cache weight of nodeA1 to a network weight of blockchain network subnet1 to which nodeA1 belongs, assigns a node cache weight of nodeA2 to a network weight of subnet2, and finally records these node cache weights in a locally maintained node weight list. Therefore, the macro regulation of the network level and the macro regulation of the node level aiming at the block cache space are combined, so that the finally realized maintenance strategy of the block cache space of the block chain system can realize the uniform regulation of a plurality of block chain nodes on the network level, and can also make differential local optimization on different node equipment so as to meet the specific conditions of the storage resources of different node equipment. Of course, the network weight of any blockchain network may also be recorded in the intelligent contract of any blockchain network, and the network weight is obtained by the first node device through the locally deployed blockchain link points in any blockchain network. In an embodiment, the node weight factor corresponding to any block link point may also be directly determined as a network weight of the block chain network to which the any block link point belongs.

S206: and under the condition that the backward block is processed by any block chain node, removing the backward block from the block cache space.

After the first node device caches the received laggard blocks in the block cache space corresponding to any block link point, the first block chain node can read and process the blocks from the block cache space by itself, and after processing one block each time, the first node device is informed to remove the processed block from the block cache space, so as to vacate the space for storing more blocks.

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

For example, the first node device may first multiply a node weight factor of any locally deployed block chain node by a lag degree factor to obtain a comprehensive factor corresponding to any block chain node, calculate a ratio of the comprehensive factor of any block chain node to a sum of the comprehensive factors of all block chain nodes, and finally determine a product of the ratio and a fixed storage size as a size of a block cache space corresponding to any block chain node, where the lag degree factor corresponding to any block chain node is determined as a ratio of a lag block number of any block chain node to a sum of lag block numbers of all block chain nodes deployed on the first node device in a block lag state, where the lag block number of any block chain node is a ratio of a latest block height maintained by a block chain network to which the any block chain node belongs to and a local block height of a local latest block maintained by the any block chain node The difference between them.

Since the size of the block cache space is related to the degree of lag between the local block height and the latest block height of the actual latest block in the blockchain network, the block cache space is larger as the degree of lag of any blockchain node (i.e. the degree of lag between the local block height and the latest block height of any blockchain node) is larger, which means that the block cache space corresponding to any blockchain node is larger when the degree of lag is larger, and the block cache space corresponding to any blockchain node is gradually reduced as the degree of lag of any blockchain node gradually reduces. Therefore, the control of the block cache space by the scheme is equivalent to the distinguishing of the block cache spaces of the lagging nodes with different lagging degrees, the lagging degrees are larger, namely the lagging nodes with larger block synchronization requirements occupy larger block cache spaces, and the limitation of the block current limiting strategy on the lagging nodes is reduced, so that the block tracing process is completed more quickly, and therefore, more balanced synchronous block tracing can be completed by each lagging node, and a more intelligent dynamic block synchronization strategy is realized.

Optionally, the method further includes: receiving a block synchronization request aiming at the laggard block, which is periodically sent by any block chain node according to a dynamic request period under the condition that the local block height laggard than the latest block height, and forwarding the block synchronization request to the normal node; wherein the dynamic request period is inversely related to a degree of lag between the latest block height and the local block height.

In this embodiment of the present specification, any blockchain node deployed on the first node device may detect whether the node itself belongs to a laggard node in the blockchain network to which the node itself belongs, and once detecting that the node itself belongs to the laggard node, the node may periodically send a block synchronization request to a normal node in the blockchain network in which the node itself is located according to a dynamic request period, so as to acquire the laggard block that laggard itself, thereby completing the block tracing process. Therefore, the laggard blocks received by the first node device and sent by the regular node in the blockchain network to any blockchain node are actually determined by the regular node in response to a block synchronization request previously issued by any blockchain node.

Taking a first blockchain node in a first blockchain network deployed on a first node device as an example, a method for periodically sending a block synchronization request by using a blockchain node according to an embodiment of the present disclosure is described below, where the method is applied to the first blockchain node, and the first blockchain node dynamically maintains a local block height of a local latest block and a dynamic request period, where the dynamic request period is negatively related to a degree of lag between the local block height and a latest block height of an actual latest block in the first blockchain network; the method comprises the following steps:

step A: and under the condition that the local block height is later than the latest block height, periodically sending a block synchronization request aiming at the laggard block to a normal node maintained with the actual latest block in the first block chain network according to the dynamic request period, wherein the block height of the laggard block is between the local block height and the latest block height.

And B: receiving the laggard blocks returned by the regular nodes in response to the block synchronization request to re-determine the local latest block and the dynamic request period.

A first block link node according to an embodiment of the present disclosure sends a block synchronization request to a normal node, where the block synchronization request is actually sent to a first node device by a first block link node first, and then forwarded to the normal node by the first node device; similarly, the backward block returned by the normal node received by the first block chain node is also received by the first node device first and cached to the block cache space corresponding to the first block chain node, and then read and received from the block cache space by the first block chain node.

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

Since the normal node has a possibility of becoming a laggard node, for any blockchain node in the first blockchain network, the other blockchain nodes are periodically inquired about the block height of the latest block maintained locally, and once the local block height maintained by the node is found to be smaller than the block height of the latest block maintained by the other blockchain nodes, the node is considered to belong to the laggard node, otherwise, if the local block height maintained by the node is found to be larger than or equal to the block height of the latest block maintained by the other blockchain nodes, the node is considered to belong to the normal node.

In the embodiment of the present disclosure, the local newest block, i.e., the first block link point, is obtained and maintained as the newest block in the local by the last common identification or by the block synchronization, and when the first block link point detects that the local block height is behind the newest block height (the local block height is smaller than the newest block height), it is determined that the first block link point belongs to the behind node, and therefore, the first block link point starts to periodically send a block synchronization request to the normal node in order to acquire the behind block. The period of sending the block synchronization request periodically is a dynamic request period maintained at the first blockchain node, where the dynamic request period is negatively related to a degree of lag between the local block height and a latest block height of an actual latest block of the first blockchain network, which means that the dynamic request period is changed along with the change of the local block height or the latest block height, for example, each time a new lag block is obtained by synchronizing the first blockchain link point, the local latest block maintained by the first blockchain link point is changed, so that the degree of lag between the local block height and the latest block height is also changed, and at this time, the first blockchain link point also needs to update the dynamic request period maintained locally.

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 of the first blockchain network, the dynamic request period is shorter as the degree of lag of the first blockchain node (i.e. the degree of lag between the local block height and the latest block height of the first blockchain node) is larger, which means that the number of times (number of valid requests) for sending block synchronization requests to normal nodes within a unit time when the degree of lag is larger for the first blockchain node is more frequent, and as the degree of lag of the first blockchain node gradually synchronizes the blocks is gradually reduced, the number of valid requests is gradually reduced, and since the number of block requests corresponding to the block synchronization requests often has an upper limit, this means that the block tracing process cannot be directly completed by a single block synchronization request. Therefore, the scheme is equivalent to distinguishing the block synchronization rates of the laggard nodes with different laggard degrees, so that the laggard nodes with larger laggard degrees, namely the laggard nodes with larger block synchronization requirements, can complete block synchronization more quickly, the proportion of the laggard nodes with larger laggard degrees in the first block chain network to all the laggard nodes is integrally reduced, the laggard nodes can complete more balanced synchronous block tracking, and a more intelligent dynamic block synchronization strategy is realized.

Optionally, the dynamic request period further negatively correlates to a node weight factor of any blockchain node. Assuming that any block chain node is a first block chain node, the corresponding node weight factor is a first node weight factor, and since the dynamic request period is also negatively related to the size of the first node weight factor corresponding to the first block chain node, the weight dimension can be adjusted for the block synchronization rate of the first block chain node. For example, the first node weight factor may be recorded in a contract state of an intelligent contract in the first blockchain network, and the intelligent contract may be invoked by an administrator or other users of the first blockchain network and then updates the first node weight factor, so that the first blockchain node may dynamically adjust its dynamic request period by reading the size of the first node weight factor that is continuously updated on the intelligent contract, and since the intelligent contract is deployed on each blockchain node in the first blockchain network, this means that the node weight factors corresponding to each blockchain node in the first blockchain network are the same, that is, macro-control of the dynamic request period at a network level is achieved.

For another example, the first node weight factor is provided by the first node device where the first block link point is located, in this case, the first node device calculates the first node weight factor corresponding to the first block link point by referring to the deployment situation of the first node device locally for the block link node, the calculation process of the first node weight factor is described in the foregoing embodiment, which is not described herein again, and the first node device provides the first node weight factor to the first block link node after calculating the first node weight factor, so that the first block link point can dynamically adjust its own dynamic request period by the size of the first node weight factor continuously updated by the first node device, that is, macro regulation of the dynamic request period on the node level is achieved.

The block synchronization request according to the embodiments of the present disclosure may include the identity information of the first blockchain node, the source address, the destination address, and the block range of the required request lagging blocks, which is determined by the block height, for example, the local block height maintained by the first blockchain node is 1500, the actual latest block height is 2000, the number of block requests corresponding to a single block synchronization request is 100, the block range of the lagging blocks carried in the block synchronization request sent by the first blockchain node to the normal node may be (1500,1600) for indicating that 100 blocks with block heights from 1501 to 1600 are requested to the normal node, and may of course be (1500,1550) or (1900,2000), in particular, in the case that the block range of the lagging blocks requested by the first blockchain node does not start continuously from the local block height, e.g., the block range of (1900,2000) indicated by the block synchronization request in the example above, the first block link point will receive 100 blocks with block heights from 1901 to 2000, however, since the update of the distributed ledger needs to be completed in the order of block height, the first block link point cannot complete the update of the distributed ledger even if the above-mentioned 100 blocks are received, in this case, the first block link point will also request the other normal nodes for the lagging block with the block range of (1500, 1900), so that after the first blockchain node receives 399 blocks with the block height from 1501 to 1900 returned by other normal nodes, the 399 blocks are processed and uplinked first (block uplink is to be a block update to the distributed ledger), the previously received 100 blocks are then processed and uplinked, thereby completing the block chase process more quickly by requesting multiple regular nodes.

In this embodiment of the present description, when a first blockchain node in a first blockchain network detects that a block maintained by the first blockchain node lags behind, a block synchronization request for the laggard block is periodically sent to a normal node in the first blockchain network, where the actual latest block is maintained, according to the dynamic request period, so that a first blockchain link point can acquire the laggard block corresponding to the first blockchain node, thereby ensuring normal operation of functions and services on the first blockchain node. At the same time, since the dynamic request period is inversely related to the lag between the local tile height and the latest tile height of the actual latest tile of the first blockchain network, therefore, the effective request times in unit time are more for the laggard nodes with larger laggard degrees, which enables the laggard nodes with larger laggard degrees to complete the block chasing process more quickly, since the block synchronization request consumes computation resources when being responded by the normal node and occupies network bandwidth resources when returning the backward block, the number and the computing resources of the normal nodes in the first block chain network, and the network bandwidth resources of the first block chain network are limited, therefore, the scheme is equivalent to preferentially letting the lagged nodes with larger lagged degree occupy more computing resources of the normal nodes and network bandwidth resources of the first blockchain network, namely, the computing resources of the normal node and the network bandwidth resources of the first blockchain network are reasonably distributed.

Furthermore, if the dynamic request period is also influenced by the weight factor of the first node, the block synchronization rate of different block chain nodes can be macroscopically regulated, and the layered design of the block synchronization task is realized.

Optionally, the dynamic request period is determined by:

searching a lagging interval corresponding to the lagging degree, and determining the dynamic request period as a numerical value corresponding to the lagging interval; or searching a lagging interval corresponding to the lagging degree, and determining the dynamic request period as the ratio of the value corresponding to the lagging interval to the first node weight factor. In the embodiment of the present specification, the dynamic request period is determined according to the lagging interval corresponding to the lagging degree, specifically, different lagging intervals can be searched to obtain the corresponding standard request period, and the dynamic request period is equal to the standard request period; or, in the case that the dynamic request period is also negatively related to the node weight factor of any block chain node, the dynamic request period is equal to the ratio of the standard request period obtained by searching to the first node weight factor. For example, when the degree of behind is the difference between the local block height and the latest block height (i.e. the number of behind blocks), the relationship between the standard request period and the number of behind blocks is shown in table 1:

standard request period (unit: millisecond)	Number of backward blocks (unit: one)
		1000	0～100
500	101～1000
		200	＞1000

TABLE 1

As can be seen from table 1, when the number of the lagged blocks is within an interval (including two ends) from 0 to 100, the standard request period corresponding to the interval can be found to be 1000ms, and assuming that the influence of the first node weight factor is considered and the value of the first node weight factor is 2, the dynamic request period can be determined to be 500 ms; similarly, when the number of the laggard blocks is in the interval of 101 to 1000, firstly, the standard request period is found to be 500ms, and then the standard request period is divided by the first node weight factor to obtain the dynamic request period to be 250 ms; when the number of the lagging blocks exceeds 1000, the standard request period is found to be 200ms, and then the dynamic request period is further determined to be 100ms., so that the larger the number of the lagging blocks is, the smaller the dynamic request period is, namely, the dynamic request period is negatively related to the lagging degree in the whole view.

Or, the dynamic request period is determined by: determining the dynamic request period as the product of the fixed request period and a lagging factor corresponding to the lagging degree; or, in case the dynamic request period is also negatively related to a node weight factor of any blockchain node, determining the dynamic request period as a ratio of the product to the first node weight factor.

In this embodiment, the dynamic request cycle needs to be obtained by calculating: the dynamic request period P-P0 xf or P0 xf/d, where P0 represents the fixed request period, which is specified by the administrator and does not change until it is not modified as a fixed value, f represents the lag factor, which is being correlated to the degree of lag, and d represents the first node weight factor.

The lag factor includes: the maximum number of blocks requested by the block synchronization request at a single time is divided by the difference between the local block height and the latest block height; or, a ratio of the local block height to the latest block height.

For example, where M represents the maximum number of blocks (block request number upper limit) allowed for a single block synchronization request, Hn represents the latest block height, and Hl represents the local block height, in the embodiment of the present specification, the lagging degree of the first block chain node is specifically the difference between the local block height and the latest block height, and obviously, the larger the lagging block number (i.e., the larger Hn-Hl is), the smaller the lagging factor f is, and the smaller the dynamic request period P is, i.e., the dynamic request period P is negatively related to the lagging degree.

For another example, where f is H1/Hn, in the embodiment of the present specification, the degree of behind of the first blockchain node is specifically the ratio between the local block height and the latest block height, and obviously, the greater the degree of behind, the smaller the behind factor f, and the smaller the dynamic request period P, and the dynamic request period is also negatively correlated to the degree of behind.

Optionally, the lagging factor is provided with an upper factor bound and/or a lower factor bound, the upper factor bound is used for re-determining the lagging factor as the upper factor bound if the lagging factor exceeds the upper factor bound, and the lower factor bound is used for re-determining the lagging factor as the lower factor bound if the lagging factor is lower than the lower factor bound. In the embodiment of the present specification, the value range of the lag factor is limited, so as to indirectly limit the value range of the dynamic request period, so that the actual requirement of the block synchronization task is met. For example, in the case where f is M/(Hn-Hl), if the difference between the local block height and the latest block height does not exceed the maximum number of blocks allowed to be requested in a single time by the block synchronization request, the f determined by the first blockchain node may be too large, which results in too large a finally determined dynamic request period P, and thus the block tracing process cannot be completed normally, and in order to avoid this situation, a factor upper bound with a value of 1 may be set for f, so that when the difference between the local block height and the latest block height does not exceed the maximum number of blocks allowed to be requested in a single time by the block synchronization request, the f calculated by the first blockchain node is greater than 1, but is re-determined to be 1 due to the function of the factor upper bound, which ensures that there is a reasonable maximum value for the dynamic request period, so as to ensure that the laggard nodes can normally complete the block tracking process.

Optionally, the dynamic request period is provided with an upper period limit and/or a lower period limit, the upper period limit is used to re-determine the dynamic request period as the upper period limit if the dynamic request period exceeds the upper period limit, and the lower period limit is used to re-determine the dynamic request period as the lower period limit if the dynamic request period is lower than the lower period limit. As described above, the range of the lag factor may be limited, so that the range of the dynamic request period is indirectly limited, and in the embodiment of the present specification, the range of the dynamic request period may also be directly limited, so as to meet the actual requirement of the block synchronization task.

Optionally, the upper cycle bound includes an upper fixed cycle bound or an upper dynamic cycle bound, and the lower cycle bound includes a lower fixed cycle bound or a lower dynamic cycle bound. Wherein the dynamic period upper bound comprises: the ratio of the maximum number of blocks of the block synchronization request allowed at a time to the block growth rate of the first blockchain network; the dynamic period lower bound includes: and dividing the difference value between the block number required by the block synchronization request and the maximum block number currently remained in the block cache space corresponding to the first block link point by the local block processing speed. In the embodiments of the present disclosure, the upper cycle boundary and/or the lower cycle boundary may be set to a fixed value, referred to as an upper fixed cycle boundary and/or a lower fixed cycle boundary, or may be set to a dynamic value, referred to as an upper dynamic cycle boundary and/or a lower dynamic cycle boundary.

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

In this embodiment, after receiving the backward blocks returned by the normal node, the first blockchain node needs to process the blocks in the order from low to high according to the block heights, that is, self-runs the transactions contained in the blocks, and then updates the backward blocks into the locally maintained distributed account book, so that for the first blockchain node, there is an objective local block processing speed, and at the same time, the first blockchain node also allocates a memory space dedicated to storing unprocessed blocks, that is, the aforementioned block cache space, by the first node device, the first node device will cache the received backward blocks in the block cache space first, the first blockchain node reads and processes the blocks from the block cache space, and after processing one block each time, the first node device will be notified to remove the processed block from the block cache space, to make room for more blocks. If the dynamic request period is too small, it is likely that the received backward block cannot be completely buffered in the block buffer space, and thus a phenomenon of memory overflow and block loss occurs, which is essentially the number of requested blocks exceeding the limit that can be accommodated by the current block buffer space, and in order to avoid this phenomenon, it is theoretically necessary to ensure that the number of requested blocks required for a certain block synchronization request does not exceed the maximum number of blocks (estimated by dividing the remaining memory capacity by the average size of a single block) remaining in the current block buffer space, but since the block synchronization request is generated at the beginning of the waiting dynamic request period, a part of blocks will be processed and removed from the block buffer space during the waiting dynamic request period, which means that, assuming that the number of requested blocks required for a newly determined block synchronization request in a certain period is M1, the maximum number of the currently remaining blocks in the block cache space determined at the initial stage of the new waiting period is Z, and the local block processing speed is v, then the memory overflow and the block loss phenomena are not generated only when M1 is required to be larger than or equal to Z-vP, that is, the dynamic request period required to wait in the current period should be larger than or equal to P (Z-M1)/v. Therefore, the dynamic period can be set as the difference value between the number of requested blocks required by the block synchronization request and the maximum number of currently remaining stored blocks in the block cache space corresponding to the first block link point is divided by the local block processing speed, so that the phenomena of memory overflow and block loss are prevented, and the block cache space vacated by block processing when waiting for one dynamic request period is maximally utilized.

Optionally, the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, and a main network node is also deployed on the node device in which the sub-network nodes in the blockchain sub-network are deployed; maintaining a network topology structure between node devices where each main network node in the block chain main network is respectively located and network delay information corresponding to the network topology structure on the first node device; the forwarding the block synchronization request to the normal node comprises: and determining a forwarding path with the minimum total delay between the first node device and the target node device where the normal node is located from the network topology structure based on the network delay information, and forwarding the block synchronization request to the normal node according to the determined forwarding path.

In the embodiment of the present specification, a node device is a hardware entity for operating a blockchain node, and a blockchain node refers to a software process running in the node device, as in the network architecture shown in fig. 1, different blockchain nodes in any blockchain network are deployed on different node devices, and a network link between each blockchain node substantially corresponds to a network link between node devices where the network link is located. Therefore, in the case that the blockchain network to which any one of the blockchain nodes belongs is a blockchain master network subnet0, for any one of the blockchain nodes, for example, nodeC, it is assumed that it needs to send a message to other master network nodes, for example, nodeE, in the subnet0, and only needs to send the message from the node device 3 where nodeC is located to the node device 5 where nodeE is located, so as to complete the corresponding message transmission.

After receiving a block synchronization request sent by any block chain node, the first node device learns, according to a destination address of the block synchronization request, that the block synchronization request needs to be sent to the normal node, and since the first node device needs to forward the block synchronization request to the normal node, the first node device needs to learn routing information from the first node device to a target node device where the normal node is located. In this embodiment of the present specification, the first node device forwards, as the routing information, the block synchronization request to the node device of the next hop in the forwarding path, and forwards the block synchronization request to the target node device step by using the forwarding path with the minimum total delay between the first node device and the target node device where the first node device is located.

Since the first node device is deployed with the master network node, the first node device may generate a network topology structure between the node devices deployed with the master network node by querying a network connection relationship of each master network node in the block chain master network, and since the block chain master network manages subnet information of each block chain subnet, which includes identity information of each node member in any block chain subnet, a node device where the node device is located, and the like, the network topology structure maintained by the first node device includes, in addition to the network connection relationship between the node devices, a condition of the subnet node deployed on each node device, that is, the network topology structure includes an entire network structure of the block chain system formed by the block chain master network and each block chain subnet.

The network topology structure according to the embodiment of the present specification refers to a connection relationship between node devices where each master network node in a block chain master network is located, and the network topology structure is generated based on the network connection relationship between each master network node in the block chain master network and can be represented in a graph form. Fig. 3 is a schematic diagram of a network topology according to an exemplary embodiment, and the network topology is used to characterize the block link point deployment on each node device and the network link situation between each node device, as shown in fig. 3. Therefore, the connection relationship between the node devices shown in fig. 3 can be regarded as an expression form for representing the network topology, and of course, the network topology can also be represented in a form of a matrix or a table, which is not limited herein.

The network delay information corresponding to the network topology according to the embodiment of the present specification includes: link delay of network links in the network topology, and/or node delay of node devices in the network topology when forwarding messages. As shown in fig. 3, the network topology includes link delays of the network links and node delays of the node devices. The link delay of the network link refers to delay information required for forwarding a message on the network link, for example, the link delay of the network link between the node device 1 and the node device 2 in fig. 3 is 100; the node delay of the node device refers to time delay information required for a message to be forwarded out of the node device after entering the node device, and specifically includes a process of the node device analyzing, looking up a routing table and forwarding the message, for example, the node delay of the node device 1 in fig. 3 is 3, and the forwarding delay of the node device 4 is 5. In this embodiment of the present description, a numerical value corresponding to a link delay and a node delay may represent a specific time delay duration, or may represent other time delay indexes having a correlation with the specific time delay duration, but a uniform unit is required between the link delay and the node delay. For example, if the link delay 100 of the network link between node device 1 and node device 2 is understood to be 100 milliseconds (ms), i.e., 100ms is required to characterize a message passing through the network link, then the node delay 3 of node device 1 is understood to be 3 ms.

A forwarding path with the minimum total delay between the first node device and the target node device where the normal node is located according to the embodiments of the present specification is determined by a network topology structure between node devices where each master network node in a block chain master network is located, and network delay information corresponding to the network topology structure. Specifically, when the first node device needs to send a block synchronization request to the normal node, a forwarding path with the minimum total delay between the first node device and the target node device may be determined through the locally maintained network topology and the network delay information.

Since the network topology maintained by the first node device includes the network link connection relationship between the node devices, the first node device may generate a forwarding path between the first node device and the target node device while determining the relative network location relationship between the first node device and the target node device in the network topology and ensuring reachability. Taking fig. 3 as an example, assuming that the first node device is node device 3, nodeC is any one of the blockchain nodes, nodeE is a normal node, now nodeC detects that it belongs to a laggard node, and having waited for a dynamic request period, the nodeb needs to send a block synchronization request to nodeb, whereupon nodeb sends the block synchronization request to the node device 3 where it is located, and after the node device 3 receives the block synchronization request, firstly, a forwarding path from the node device 3 (first node device) to the node device 5 (target node device) where the node e is located needs to be determined based on the network topology structure maintained by itself, obviously, according to the network topology structure, it can be found that there is no directly connected network link between the node device 3 and the node device 5, and in the forwarding path without considering the loop and the original return, the forwarding path between the node apparatus 3 and the node apparatus 5 includes two paths: first, node device 3 → node device 1 → node device 2 → node device 5; second, node device 3 → node device 1 → node device 4 → node device 2 → node device 5. After determining the two selectable forwarding paths, the node device 3 further determines, based on the network delay information, a forwarding path with a minimum total delay between the node device 3 and the node device 5 from the two selectable forwarding paths, where the total delay corresponding to the forwarding path is a sum of a link delay of at least one network link from the first node device to the target node device on the forwarding path and/or a node delay of at least one node device (excluding the first node device and the target node device) on the forwarding path. Therefore, when determining the total delay of the forwarding path, the first node device may calculate only the link delays of all network links passing from the first node device to the target node device, may also calculate only the node delays of all node devices passing from the first node device to the target node device, and may also consider the link delays of all network links passing from the first node device to the target node device and the node delays of all node devices of the routes at the same time. For example, taking fig. 3 as an example, since the total delay of all network links and all node devices of the forwarding path route of node device 3 → node device 1 → node device 2 → node device 5 is 166, and the total delay of all network links and all node devices of the forwarding path route of node device 3 → node device 1 → node device 4 → node device 2 → node device 5 is 131, 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 receiving the block synchronization request, the node device 1 may determine a forwarding path with the shortest total delay between the node device 1 and the node device 5 again according to the network topology maintained by the node device 1 and the network delay information, and perform secondary forwarding on the block synchronization request by using the newly determined forwarding path, and the node device that subsequently receives the block synchronization request also determines a new forwarding path first and then forwards the block synchronization request according to the newly determined forwarding path according to the same procedure; or when the node device 3 forwards the block synchronization request to the node device 1, the forwarding path determined by the node device 3 may also be carried in the block synchronization request, and then after receiving the block synchronization request, the node device 1 may continue to find the node device of the next hop as the node device 4 based on the forwarding path carried in the block synchronization request, and forward the block synchronization request to the node device 4, and the node device 4 and the subsequent node devices continue to forward the block synchronization request according to the same flow until the block synchronization request is forwarded to the node device 5. After receiving the block synchronization request, the node device 5 further forwards the block synchronization request to a locally deployed nodeb, thereby completing all processes of sending the block synchronization request to a normal node.

In an embodiment of this specification, 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, where the near-end network link is a network link between the first node device and a neighboring node device thereof, and the far-end network link is a network link in the network topology other than the near-end network link. The neighbor node device of the first node device refers to a 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 the node device 1 includes a node device 2, a node device 3, and a node device 4, and the neighbor node device of the node device 4 includes the node device 1 and the node device 2.

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

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

The request response mechanism related to the embodiments of the present specification relates to interaction between a requester and a responder, and an initiator of the request response mechanism is considered to be the requester, and the request response mechanism is specifically implemented by the following means: the requester sends a request message carrying time t1 to the responder, and t1 is the local time of the requester when the requester sends the request message. After receiving the request message, the responder records local time t2 of the responder when the responder receives the request message, and then returns a response message generated in response to the request message to the requester, and simultaneously carries time t2 and time t3 in the response message, wherein t3 is the local time of the responder when the responder returns the response message, which is recorded by the responder. Finally, after the requester acquires the response message, the local time T4 of the requester when the requester receives the response message is recorded, then T2 and T3 are extracted from the acquired response message, then T0 is calculated as [ (T4-T1) - (T3-T2) ]/2, and the T0 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 relay device, no other relay device exists between the requesting party and the answering party. The request messages and response messages involved in the request-response mechanism may be dedicated messages dedicated to calculating the link delay, or may be other normal service requests, or heartbeat messages in the network, and since the local processing time t3-t2 of the responder is taken into account when calculating the link delay, any type of request message and response message may be applied to the request-response mechanism to enable the requester to measure the associated link delay.

In this illustrative embodiment, the first node device may determine the link delay of the near-end network link by the request-reply mechanism described above. For example, the first node device may actively initiate a request-response mechanism to its neighboring node device, so as to determine a link delay of a near-end network link between the first node device and the neighboring node device, where the link delay of the near-end network measured by the first node device through the request-response mechanism is referred to as a local-end link delay. On the other hand, for any network link, the two end devices included in the network link may measure the link delay of the network link by initiating the request-response mechanism, so that the first node device may also directly obtain the link delay of the near-end network link between the first node device and the neighboring node device by receiving the link delay of the near-end network link between the first node device and the neighboring node device measured by the request-response mechanism of the neighboring node device, where the link delay of the near-end network link measured by the neighboring node device and provided to the first node device is referred to as the opposite-end link delay. In summary, the first node device may obtain the link delay of a near-end network link through two means, and therefore, the two means may also be selected or considered comprehensively, for example, the link delay of the near-end network link finally determined and recorded in the network delay information by the first node device may include: the local end link delay, the opposite end link delay, or a weighted average of the local end link delay and the opposite end link delay. When the link delay of the near-end network link is determined to be a weighted average of the local-end link delay and the opposite-end link delay, the network delay information maintained by the first node device can be made more robust.

Taking fig. 3 as an example, assume that the local end link delay of the near-end network link between node device 1 and node device 2 measured by initiating the request-reply mechanism is 102, and node device 2 measures the peer-to-peer link delay of the near-end network link through the origination request response mechanism to be 98, then, for node device 1, it may directly determine its own measured home link delay 102 as the link delay of the near-end network link with node device 2, or the opposite-end link delay 98 measured by the node device 2 and received from the node device 2 is determined as the link delay of the near-end network link, and the average 100 of the local-end link delay and the opposite-end link delay may also be determined as the link delay of the near-end network link according to the weight ratio of 1:1, and recorded in the network delay information locally maintained by the node device 1.

Since the first node device can only directly measure the link delay of the near-end network link between the first node device and the neighboring node device, but cannot measure the link delay of the far-end network link, it is necessary to directly obtain the link delay of the far-end network link by receiving a link delay sharing message containing the link delay of the far-end network link, which is sent or forwarded by the neighboring node device, and record the link delay to the corresponding far-end network link in the network delay information. In this embodiment of the present specification, the first node device receives, from the neighbor node device of the first node device, a link delay of the remote network link, where the link delay of the remote network link is determined by a link delay obtained by at least one end node device of the remote network link detecting the remote network link through a request response mechanism, and for example, the link delay of the remote network link may include: the link delay obtained by detection of any end node device of the far-end network link, or the weighted average of the link delays obtained by detection of the node devices at both ends of the far-end network link. The link delay detected by any end node device is the link delay for the far-end network link, and the network delay information maintained by the first node device can be made more robust under the condition that the link delay of the far-end network link is the weighted average of the link delays detected by the node devices at the two ends of the far-end network link.

As shown in fig. 3, assuming that the first node device is the node device 1, for the node device 1, the link delay of the remote network link between the node device 2 and the node device 5 cannot be directly measured by the request-response mechanism, but the node device 2 and/or the node device 5 need to measure and determine by initiating the request-response mechanism, and the node device 2 encapsulates the link delay of the finally determined remote network link into the link delay sharing message to be 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 measured far-end link delay from the neighboring node device, and in one embodiment, further includes: and receiving a response message sent by the neighbor node equipment of the first node equipment in a request response mechanism, wherein the response message comprises the opposite-end link delay and/or the link delay of the remote network link. In this embodiment, the opposite-end link delay and/or the link delay of the remote network link received by the first node device may be directly carried in a response message involved when the first node device initiates a request response mechanism to the neighboring node device, so that the first node device may obtain the opposite-end link delay and/or the link delay of the remote network link simultaneously under the condition of obtaining the local-end link delay only by initiating the request response mechanism once, thereby reducing the complexity of network internal interaction. In another embodiment, the peer link delay and/or the link delay of the remote network link may also be carried in other messages sent by the neighboring node device or forwarded to the first node device.

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

The backflow message mechanism related to the embodiments of the present specification relates to interaction between a requester and a responder, and an initiator of the backflow message mechanism is considered to be the requester, and the backflow message mechanism is specifically implemented by the following means: the method comprises the steps that a requester firstly selects a responder and initiates a backflow message mechanism, firstly, the requester needs to construct a backflow message with a destination address pointing to the requester, and sends the backflow message to the responder according to a network link directly connected with the responder, and simultaneously records the local time t5 of the requester when the backflow message is sent. After receiving the reflow message, the responder finds out that the destination address of the reflow message is the requester through searching a routing table, so that the reflow message is returned to the requester as it is, after receiving the reflow message, the requester records the local time T6 of the requester, then calculates T1-T6-T5, obtains the forwarding delay T1 corresponding to the whole period from the requester to the requester, then the requester finds out the link delay T2 of the network link between the requester and the responder from the maintained network delay information, then calculates T3-T1-2-T2, and finally determines that the node delay corresponding to the responder is T3. The mechanism of the return message requires that no other transit device exists between the requesting party and the answering party because the mechanism of the return message measures the node delay of the forwarded message of the object, i.e. the answering party, and therefore, the addition of the other transit device will result in the failure of the measurement expectation.

In this embodiment of this specification, the detecting, by any neighbor node device of any node device, of any node device includes: the method comprises the steps that any neighbor node device sends a backflow message to any node device, the node delay of any node device is determined according to the forwarding delay of the backflow message and the link delay of a network link between any neighbor node device and any node device, and the backflow message is a message that a destination address sent to any node device by any neighbor node device points to any neighbor node device. As previously described, for a node delay of any node device, any neighbor node device of the any node device may initiate a backflow message mechanism to measure.

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

For the first node device, it cannot detect the node delay of the node device other than the neighboring node device through the backflow message mechanism, so the first node device may also obtain the node delay of any node device through other manners, for example, the first node device may directly receive the node delay of any node device shared by other node devices. Taking fig. 3 as an example, the node device 1 cannot directly detect the node delay of the node device 5, but the node device 2 can measure the node delay, so that the node device 1 can directly receive the node delay sharing message which is sent to the node device 1 by the node device 2 and carries the node delay of the node device 5, thereby obtaining and determining that the node delay of the node device 5 is 2, and finally recording the node delay in the local network delay information. Certainly, the node device 1 does not need to acquire the node delay of the node device 5 from the node device 2, and in fact, the network delay information maintained by the node device 4 actually includes the node delay of the node device 5 through the aforementioned node delay acquisition manner, so the node device 1 may also receive the node delay sharing message carrying the node delay of the node device 5 and sent by the node device 4, so as to acquire the node delay of the node device 5.

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

Taking fig. 3 as an example, the node device 1 may receive the node delay 1 of the node device 1 detected by the node device 3, the node delay 3 of the node device 1 detected by the node device 2, and the node delay 5 of the node device 1 detected by the node device 4, respectively, at this time, the node device 1 may optionally select the node delay of the node device 1 measured by one of the node devices as the node delay of the node device 1 in the locally maintained network delay information, or determine the weighted average 1.5 of the node delay measured by the node device 3 and the node delay measured by the node device 2 as the node delay of the node device 1 in the network delay information according to the weight ratio of 3:1, the weighted average 3 of the node delays of the node device 1 detected by the three node devices may also be determined as the node delay of the node device 1 in the network delay information according to the weight ratio of 1:1: 1.

FIG. 4 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 4, at the hardware level, the apparatus includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410, but may also include hardware required for other services. One or more embodiments of the present description may be implemented in software, such as by processor 402 reading corresponding computer programs from non-volatile storage 410 into memory 408 and then executing. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Fig. 5 is a block diagram of a block synchronization apparatus provided in this specification according to an exemplary embodiment, which may be applied to the device shown in fig. 4 to implement the technical solution of this specification; the device is applied to first node equipment, wherein a plurality of block chain nodes which respectively belong to a plurality of block chain networks in a block chain system are deployed on the first node equipment, and the first node equipment maintains corresponding block cache spaces for the block chain nodes deployed by the first node equipment, wherein the size of the block cache space corresponding to any block chain node deployed by the first node equipment is positively related to a node weight factor of any block chain node; the device comprises:

a block receiving unit 501, configured to receive a backward block sent by a normal node in a block chain network to which the any block link point belongs to the any block chain node, where the normal node maintains an actual latest block, and a block height of the backward block is between a local block height of a latest block locally maintained by the any block link point and a latest block height of the actual latest block;

a block cache unit 502, configured to cache the backward block in a block cache space corresponding to the any block link point, so that the any block link node reads and processes the backward block from the block cache space;

a block removing unit 503, configured to remove the lagging block from the block cache space when the lagging block is processed by the any blockchain node.

Optionally, the method further includes:

a request forwarding unit 504, configured to receive a block synchronization request, which is periodically sent by any blockchain node according to a dynamic request period and is for the laggard block when the local block height lags behind the latest block height, and forward the block synchronization request to the normal node;

wherein the dynamic request period is inversely related to a degree of lag between the latest block height and the local block height.

Optionally, the dynamic request period further negatively correlates to a node weight factor of any blockchain node.

Optionally, the blockchain system includes a blockchain main network and a blockchain sub-network managed by the blockchain main network, and a main network node is also deployed on the node device in which the sub-network nodes in the blockchain sub-network are deployed; maintaining a network topology structure between node devices where each main network node in the block chain main network is respectively located and network delay information corresponding to the network topology structure on the first node device; the forwarding the block synchronization request to the normal node comprises:

and determining a forwarding path with the minimum total delay between the first node device and the target node device where the normal node is located from the network topology structure based on the network delay information, and forwarding the block synchronization request to the normal node according to the determined forwarding path.

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, where the near-end network link is a network link between the first node device and a neighboring node device thereof, and the far-end network link is a network link in the network topology except for the near-end network link.

Optionally, the method further includes:

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

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

Optionally, the method further includes:

a response receiving unit 506, configured to receive a response message sent by a neighboring node device of the first node device in a request response mechanism, where the response message includes the opposite-end link delay and/or the link delay of the remote network link.

Alternatively to this, the first and second parts may,

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

the link delay of the remote network link includes: the link delay obtained by detection of any end node device of the far-end network link, or the weighted average of the link delays obtained by detection of the node devices at both ends of the far-end network link.

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

Optionally, the method further includes:

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

receiving the node delay of any node device shared by other node devices.

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

the method comprises the steps that any neighbor node device sends a backflow message to any node device, the node delay of any node device is determined according to the forwarding delay of the backflow message and the link delay of a network link between any neighbor node device and any node device, and the backflow message is a message that a destination address sent to any node device by any neighbor node device points to any neighbor node device.

Optionally, the node delay of any node device includes:

the node delay obtained by detecting any node device by any neighbor node device of any node device, or the weighted average of the node delays obtained by detecting any node device by at least one neighbor node device of any node device.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, the present invention does not exclude that as future computer technology develops, the computer implementing the functionality of the above described embodiments may 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, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of multiple sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

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

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

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

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

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

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

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

One or more embodiments of the present description 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 can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

1. A block synchronization method is applied to first node equipment, wherein the first node equipment is provided with a plurality of block chain nodes which belong to a plurality of block chain networks in a block chain system respectively, and maintains corresponding block cache spaces for the block chain nodes arranged by the first node equipment, wherein the size of the block cache space corresponding to any block chain node arranged by the first node equipment is positively related to a node weight factor of any block chain node; the method comprises the following steps:

2. The method of claim 1, the node weight factor for any blockchain node comprising: the node cache weight of any block chain node accounts for the ratio of the sum of the node cache weights of the plurality of block chain nodes.

3. The method of claim 1, the size of the block cache space also positively correlated to a degree of lag between the local block height and the latest block height.

4. The method of claim 1, further comprising:

receiving a block synchronization request aiming at the laggard block, which is periodically sent by any block chain node according to a dynamic request period under the condition that the local block height laggard than the latest block height, and forwarding the block synchronization request to the normal node;

5. The method of claim 4, the dynamic request period further negatively correlated to a node weight factor of the any blockchain node.

6. The method of claim 4, wherein the blockchain system comprises a blockchain main network and a blockchain sub-network managed by the blockchain main network, and a main network node is further deployed on the node device where the sub-network nodes in the blockchain sub-network are deployed; maintaining a network topology structure between node devices where each main network node in the block chain main network is respectively located and network delay information corresponding to the network topology structure on the first node device; the forwarding the block synchronization request to the normal node comprises:

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

8. The method of claim 7, further comprising:

determining 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; the local end link delay is obtained by detecting the near end network link by a first node device through a request response mechanism, and the opposite end link delay is obtained by detecting the near end network link by a neighbor node device of the first node device through the request response mechanism; and/or the presence of a gas in the gas,

9. The method of claim 8, further comprising:

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

10. The method of claim 8, wherein the first and second light sources are selected from the group consisting of,

11. The method of any of claims 6-10, the network delay information comprising: link delay of network links in the network topology, and/or node delay of node devices in the network topology when forwarding messages.

12. The method of claim 11, further comprising:

acquiring node delay obtained by detecting any node device by at least one neighbor node device of any node device in the network topology structure, and determining the node delay of any node device according to the acquired node delay; and/or receiving the node delay of any node device shared by other node devices.

13. The method of claim 12, wherein any neighbor node device of the any node device detects the any node device, and the method comprises:

14. The method of claim 12, the node latency of any node device, comprising:

15. A block synchronization device is applied to first node equipment, wherein the first node equipment is provided with a plurality of block chain nodes which belong to a plurality of block chain networks in a block chain system respectively, and maintains corresponding block cache spaces for the block chain nodes arranged by the first node equipment, wherein the size of the block cache space corresponding to any block chain node arranged by the first node equipment is positively related to a node weight factor of any block chain node; the device comprises:

16. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-14 by executing the executable instructions.

17. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 14.